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

I have a small LAN at home with nine or ten systems on it running
various varieties of Linux.  I 'do things' on the LAN either from my
dekstop machine or from my laptop, both run Xubuntu 24.04 at the
moment. 

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.

Obviously public-key is more secure as regards the actual login
process but it seems to me that's not really where the vulnerabilities
are.  If someone 'breaks in' (in the physical or computer sense) to my
desktop then how might they attack another system on the LAN?  It's
not physically accessible to them (it's quite a big LAN, one system in
particular is in another building).  So they can try and guess my
key's passphrase if I'm using public-key, or they can try and guess my
password if I'm using password.

It **is** possible to brute force a key passphrase, all the bits you
need are almost certainly to hand in ~/.ssh.  However I don't think it's
possible to brute force a password on a remote system, each login will
take several seconds and you'll get thrown off after very few retries.

My public-key passphrases are going to be similar length and
complexity to my passwords, they have to be if I'm going to be able to
remember them.  They are mostly 11 or more characters long with all
the 'good things' like special characters, mixed case, etc.  Thus I
suppose they'll be difficult to guess (or brute force). However
password login can have the same, complex, password strings so I don't
see how using public-key helps and (as I said above) it seems slightly
more breakable.

It's also **much** more dificult to keep all those keys etc. well
organised.  What has brought me to this question is the mixed
collection of RSA and ed25519 keys all over lots of systems getting
very difficult to keep under control, and thus error prone (=insecure).
If I went back to all passwords life would be so much easier!

So, is this right?  It goes against a lot of advice one sees.  Please,
if I'm talking rubbish please tell me! :-)

-- 
Chris Green

There is room for differences of opinion here.

other factors
do you reuse the password elsewhere (or use a passwork close enough, most people
tend to use a static prefix and have a cycling value at the end)

do people use a password manager

do you always start from the same system? or do you use different systems at 
different times. If you use different systems, how do you manage your certs and 
have them in the right place? (can you use a hardware fob to store them, what do
you do when you forget/lose it, etc)?

is your key passphrase similar to your password?

A cert is a single factor, so is a password. Cert authentication is only two 
factor if you trust that the password is not stored along with the cert (which 
is on the untrusted client)

This is why I push for challenge/response tokens, not simply cert 
authentication, and really wish that FIDO (such as yubikey) was an option, but 
the discussions I've seen about suporting that have not been encouraging.

David Lang

On Mon, 21 Oct 2024, Chris Green wrote:
> I have a small LAN at home with nine or ten systems on it running
> various varieties of Linux.  I 'do things' on the LAN either from
my
> dekstop machine or from my laptop, both run Xubuntu 24.04 at the
> moment.
>
> 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.
>
> Obviously public-key is more secure as regards the actual login
> process but it seems to me that's not really where the vulnerabilities
> are.  If someone 'breaks in' (in the physical or computer sense) to
my
> desktop then how might they attack another system on the LAN?  It's
> not physically accessible to them (it's quite a big LAN, one system in
> particular is in another building).  So they can try and guess my
> key's passphrase if I'm using public-key, or they can try and guess
my
> password if I'm using password.
>
> It **is** possible to brute force a key passphrase, all the bits you
> need are almost certainly to hand in ~/.ssh.  However I don't think
it's
> possible to brute force a password on a remote system, each login will
> take several seconds and you'll get thrown off after very few retries.
>
> My public-key passphrases are going to be similar length and
> complexity to my passwords, they have to be if I'm going to be able to
> remember them.  They are mostly 11 or more characters long with all
> the 'good things' like special characters, mixed case, etc.  Thus I
> suppose they'll be difficult to guess (or brute force). However
> password login can have the same, complex, password strings so I don't
> see how using public-key helps and (as I said above) it seems slightly
> more breakable.
>
> It's also **much** more dificult to keep all those keys etc. well
> organised.  What has brought me to this question is the mixed
> collection of RSA and ed25519 keys all over lots of systems getting
> very difficult to keep under control, and thus error prone (=insecure).
> If I went back to all passwords life would be so much easier!
>
> So, is this right?  It goes against a lot of advice one sees.  Please,
> if I'm talking rubbish please tell me! :-)
>
>

On Mon, Oct 21, 2024 at 07:26:21PM +0100, Chris Green
wrote:
> It **is** possible to brute force a key passphrase, all the bits you
> need are almost certainly to hand in ~/.ssh.  However I don't think
it's
> possible to brute force a password on a remote system, each login will
> take several seconds and you'll get thrown off after very few retries.
Unlike a password, tho, ssh-keygen support "-a rounds" to increase the
number of hashing rounds during key derivation, so you can set an
absurdly high number of rounds and make each key decription attempt take
one minute (or one hour, or one day. Whatever floats your boat.)

Also, with the addition of -sk keys into OpenSSH, you can make so not
all the bits are present in ~/.ssh . The "private key" is actually a
key
handle which is useless without the U2F hardware.
> My public-key passphrases are going to be similar length and
> complexity to my passwords, they have to be if I'm going to be able to
> remember them.  They are mostly 11 or more characters long with all
> the 'good things' like special characters, mixed case, etc.  Thus I
> suppose they'll be difficult to guess (or brute force). However
> password login can have the same, complex, password strings so I don't
> see how using public-key helps and (as I said above) it seems slightly
> more breakable.
You could use a password manager for your SSH keys passwords.
> It's also **much** more dificult to keep all those keys etc. well
> organised.  What has brought me to this question is the mixed
> collection of RSA and ed25519 keys all over lots of systems getting
> very difficult to keep under control, and thus error prone (=insecure).
> If I went back to all passwords life would be so much easier!
I really don't get what part is difficult about this.

Storing the files on disk? Use good names.
Managing authorized_keys in remote servers? Use an OpenSSH CA and call
it a day. Bonus point: you can rotate private keys for leaves damn
quickly.



Finally, if somebody would get access to my laptop or desktop, I'd be
way more concerned about my browsers' directory than lateral movement
in my LAN.

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

OK, I think I have realised what has been confusing me (and, maybe
you, in the plural).

I have been looking at this security question with a sort of 'tunnel
vision', I'm concerned with login security of remote systems **when
viewed from my desktop**.  For this specific case, i.e. when someone
is sitting at my desk, or has my laptop in front of them, there is
little to choose between password and public-key authentication. To
break either, all the intruder has to do is guess/break my password or
the passphrase protecting my public-key.

**However** from the point of view of a system 'out there' on the
public accessible internet, open to connections from anywhere,
key-based authentication is much more secure because an attacker has
to guess/break a very long (400 or 500 character) key rather than a 10
or 20 character password.


So, for systems on my LAN which don't have 'internet facing' ssh
access I'm now fairly convinced that password based security is fine. 
My desktop, which *does* have (limited) accessibility from the
internet should probably allow only key-based ssh access from outside. 

Any system which is open (even if limited by means such as allowing
access only from certain IP ranges etc.) to internet access should
preferably allow only key-based ssh authentication so that (relatively
short) password guessing isn't possible.

On the other hand, for systems on my LAN and/or any other system which
isn't open to anyone to attack, password based authentication is quite
OK.


Thanks for all the help and useful discussion everyone. :-)

-- 
Chris Green

On 22/10/24 04:26, Chris Green wrote:
> It's also **much** more dificult to keep all those keys etc. well
> organised.  What has brought me to this question is the mixed
> collection of RSA and ed25519 keys all over lots of systems getting
> very difficult to keep under control, and thus error prone (=insecure).
> If I went back to all passwords life would be so much easier!
Life for me actually became a lot easier when I bought myself an 
OpenPGP-enabled security token and learned to use the SSH agent support 
built into GnuPG.

If I take the token with me when I go out, someone who breaks in does 
not have access to my private key, because it's not stored on the computer.

If I forget to take the token with me, they get 3 guesses at correctly 
entering the passphrase to unlock it before the device locks itself. 
The only real vulnerability is if I leave it plugged-in and unlocked, 
but then the moment they unplug the device or power off the host it's 
plugged into: game over.
-- 
Stuart Longland (aka Redhatter, VK4MSL)

I haven't lost my mind...
   ...it's backed up on a tape somewhere.

> I have a small LAN at home with nine or ten systems on it running
> various varieties of Linux.  I 'do things' on the LAN either from
my
> dekstop machine or from my laptop, both run Xubuntu 24.04 at the
> moment.
If you only ever log in from a limited set of hosts, you can further 
tighten security by enabling hostbased authentication in addition to 
publickey auth.

On 21.10.24 20:26, Chris Green wrote:
> I have a small LAN at home with nine or ten systems on it running
> various varieties of Linux.  I 'do things' on the LAN either from
my
> dekstop machine or from my laptop, both run Xubuntu 24.04 at the
> moment.
> 
> 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.
> 
> [...] If someone 'breaks in' (in the physical or computer sense) to
my
> desktop then how might they attack another system on the LAN? [...]
> 
> [...] If I went back to all passwords life would be so much easier!
As has already been pointed out, if someone manages to break into your 
workplace machine, the (past) security of the rest of the network is 
usually not the most pressing concern, much less your only one. But 
let's stick to that, for the sake of the argument.

Subverting your workplace machine - the same account you log in as, or 
even a superuser - gives the attacker a lot of possibilities, 
essentially getting his hands on all data that passes through that 
computer, from keystrokes to (before-/after-encryption) network 
communication to the contents of your screen. If that's a scenario 
probable enough to make it a concern, and the consequences for the other 
hosts in your LAN important enough to consider, the question to answer 
is not "which auth protocol spoken *by the subverted machine* is a bit 
harder to catch as well" but "how do get I get the relevant secrets 
*off* that machine and into an *actually* secure location".

Thanks to Yubikeys and similar devices, that is actually feasible, but 
it also makes it quite clear why *then* using keypair auth is vastly 
preferable: A password still needs to travel through the insufficiently 
secure machine whenever you use it, and can get snarfed there; a private 
key, on the other hand, never leaves the extra device and the worst the 
attacker can achieve is to *somehow* piggyback onto *your* activity 
(which will definitely not be as easy as copy-pasting a password out of 
a data stream recorded way-back-when).
>> do people use a password manager
> Not for passwords, I remember all the ones I use a lot.
Then I have a thought experiment for you: Let's assume that you found 
your workplace machine to be hacked and are now busy setting up a new 
one from scratch. Which of these two subtasks sounds easier to do:

a) Create new keypairs, possibly reusing the old passphrases for them 
(because either you succeeded in making the new setup more secure, then 
reusing the passphrases won't matter, or you didn't, then the attacker 
would likely eavesdrop new ones soon-ish, anyway)

b) Replace *every* password and *memorize* them all, preferably from one 
day to the next

Kind regards,
-- 
Jochen Bern
Systemingenieur

Binect GmbH
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4336 bytes
Desc: S/MIME Cryptographic Signature
URL:
<http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20241023/64acff86/attachment.p7s>