Goo Truther 
ssh practice
The latest standard for remote access should NOT be a *public* ssh port. I don't care about what method of authentication is in place, or what obfuscation is available. Honestly ssh ports should be LAN-only and behind strict firewalls. If you want remote access, setup a modern point to point VPN which gives you the modern cryptographic security as a default, then ssh from within the VPN on the relevant LAN.
now @why [☎4236]
ssh practice
@thufie hmm, why?
no like, seriously question.
publicly ssh confed with modern crypto + enforcing pubkey use has the one big advantage of not creating a "internal" network feeling with lowered security.
If your internal behind the vpn" network is secured as if it was the internet, with hostfirewall and propper segmentation, then why do the vpn in the first place?
so cut out the middle section and put them the ssh on the internet direclty
re: ssh practice
@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.
re: ssh practice
@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