openssh unix dev - Oct 2024 - Security of ssh across a LAN, public key versus password

Hi Chris,
> There's a couple of headless systems on the LAN where login security
> is important to me and I've been thinking about the relative merits of
> password and public-key authentication.
> <snip>
At home, I have a smaller LAN than you, but at $DAYJOB I work with much bigger
fleets. Whether at home or work, everything is Linux-based, and OpenSSH is the
primary form of remote access. I say these things to let you know that I
appreciate your concerns, and although I've seen a variety of approaches,
there is a surprising amount of commonality to "good enough" practice
(I don't say "best practice" because I know cybersecurity wonks
like to go to town as though we're all working for the NSA).

Firstly, I've seen a lot of security incidents affecting customer virtual
machines, and some of these incidents involved the OpenSSH service on the
customers' virtual machines. However, every single time when the incident
was attributable to unauthorized ssh access, it was because the customer changed
the default settings. The images we provided were configured to only offer
keypair authentication by default; some customers deliberately change the
default setting to permit passphrase authentication, and that's when they
get hacked. Note that the keypairs they did use were typically generated via the
openstack dashboard, which doesn't even add a passphrase to the private key.
So, I've seen plenty of evidence that keypairs are much, much better than
password auth, even in the very relaxed situation where the keypair is
unencrypted by default.

Furthermore, for our compute host fleets and control plane nodes, I've never
seen password auth enabled anywhere I've worked. Instead all engineers have
been expected to use keypair authentication for everything. There wasn't
even much rigor about this, eg I'm sure some operators I've worked with
at various points through history have kept unencrypted private keys on their
local storage. And yet, even with a sometimes relaxed approach, I've never
seen a security incident arise due to unauthenticated ssh access to the
infrastructures.

tl;dr In my experience, you get a lot of bang for your buck simply by denying
all password authentication, and only permitting keypair authentication. If
you're already doing this much, then you're on the right track.

Yes, you can and should take extra steps to harden your private key. Put a
passphrase on it and keep the passphrase in a password store; use FIDO2 keys
such as ed25519-sk; back the key with GPG; and this list isn't exhaustive.
Personally I use a mix of the first two approaches: often preferring ed25519-sk
(or certificates backed by ed25519-sk), but falling back to encrypting the key
with a random passphrase when some combination or sk keys or certs is
contra-indicated (eg old systems which don't yet understand sk.)

On your own LAN, where you presumably control everything and don't need to
compromize with anyone, you could consider my favorite approach, which is
configure everything to accept certificate authentication, and only permit
certificates which have been signed by an sk key. This gives you seamless
time-limited access that is backed by 2FA. It does, however, require buying at
least one hardware key such as a Yubikey. It also assumes that all your copies
of OpenSSH are on version >= 8.2. And if you haven't used certs or sk
keys before, there is a bit of a learning curve when you set either of these up
for the first time.

There is another benefit to keypairs, which is you don't need to keep
entering your passphrase. Using either proxyjumping or agent forwarding,
keypairs allow much more seamless access. They are just so much more convenient
that I would still prefer keypairs even if the security wasn't any better.

There is also much to be said for preventing anyone from even attempting
unauthorized access in the first place. If no one from outside your LAN needs to
get in, then simply deny port 22 at the level of your outward-facing firewall.
If some external access is required, then see if you can generate an allowlist.
I've had good experiences using a cron job to generate ipsets based on whois
data for specific ISPs. Then whoever is with that ISP can get access, but no one
else. I found this 100% killed botnet noise from my logs.

And, putting the most important bit last, always consider your cybersecurity
threat model before deciding what are the best measures to implement. If you
need to worry about sophisticated and well-resourced threats who are strongly
motivated to get into your LAN for some reason, then it's a whole different
ballpark to just needing to stop some random botnets. If you're only worried
about getting hacked by random botnets, then almost 100% of what you need is
covered by just avoiding passphrase authentication, preferably with a firewall
allowlist. Whereas, if you're on the hitlist of a nation-state, then you
also need to think a lot more about physical security and supply chains, in
addition to whatever worries you have about configuring OpenSSH.

tl;dr Disable password auth, preferably put 2FA on your keypair auth, and
preferably deny access before it even has a chance to try authenticating, and
you should be fine for a typical mom-and-pop LAN.

Cheers,

Tim

On Mon, Oct 21, 2024 at 08:24:46PM +0000, Tim Rice via openssh-unix-dev
wrote:
> Hi Chris,
> 
> 
> tl;dr In my experience, you get a lot of bang for your buck simply by
denying
> all password authentication, and only permitting keypair authentication. 
> If you're already doing this much, then you're on the right track. 
> 
What do you mean by "keypair authentication"?

-- 
Chris Green