@4censord @thufie
See: the cheese slice model. You want at least two peaces of software from two different vendors on two seperate machines guarding things like root access, in case one has a security critical bug.

@ranja @thufie oh, i hadnt heard of that model before, i'll look into it

@ranja @thufie though i am wondering at what point simplicity wins out over complexity (because it lowers the chance of missconfigurations and similar errors)

@ranja @thufie oh, its basically defense in depth with some more visualisation

@4censord @ranja yeah I'd agree with all this while also adding that preconfigured point to point VPNs with wireguard for example come with a secure configuration out of the box for LAN access, and I would expect configuration mistakes in ssh from most sysadmins (bad packaged defaults, changed incorrectly or incompletely). This is both defense in depth, reducing attack surface of open ports, and an attempt to minimize chances of human misconfiguration.

Also the benefit of both initially allowing access to, and then revoking access to all 'internal' (LAN infrastructure) at once by revoking an individual's VPN access.

I don't think I am alone in this, since I've seen more enterprise org products targeting this approach, by integrating an organization's auth system, and VPN infrastructure connecting to a shared bridged LAN for easier, more secure development or shared operations. Just look at enterprise software built on Wireguard for some examples of how far you can take this approach. I prefer things less tightly integrated for personal stuff of course, but there is a serious draw based on scaling secure access to shared infra as well.

@thufie @ranja i think in the end it depends on scale and threat model.
(at work) for a bank customer of ours, we have like 3 layers (access to our internal VPN, access to their VPN for externals via ours, and then a PAM system based on teleport)
at a healthcare customer it's a bunch of jump hosts with ssh keys (and config management to i can just roll out a revocation to everything), and just SSO federation for web stuff

both of which passed their respective audits and security teams

@4censord @thufie
In practice you have your network people that take care of segmentation, firewalls, VPNs, etc. and your server admins that do their own security with host level firewalls, fail2ban, 2fa, x509, etc. both teams should not trust each other’s security measures and treat the other one as unsafe.

@4censord @thufie
Zero trust is a base principle in IT Infrastructure engineering. Because everything has bugs, they just surface at different times.

@ranja @thufie hmm, at that size that sounds like it makes sense. I've only ever did stuff in small scales, were the difference between the network team and the server team are the hats the individual people wear at that time.
and at that scale, "we do it once but correctly" is usually better than "we did multiple things badly"

@4censord @thufie
I did both, from small hobby systems to ISP grade critical infrastructure and yeah, there’s a difference in what you can reasonably do as well as in threat level.
I usually have at least one ssh port on a jumpserver exposed for my home stuff in case my janky vpn dies and it’s on a non standard port with fail2ban and an endlessh trap on port 22. But my home stuff also isn’t the main target of advanced adversaries.