Security of ssh across a LAN, public key versus password

[Chris Green]

On Mon, Oct 21, 2024 at 10:14:40PM +0000, Tim Rice via openssh-unix-dev wrote:
> Hi David,
> 
> > hmm, what I'm finding doesn't seem to use the FIDO challenge/response to the
> > server, instead it looks like a public/private key that's unlocked with a touch,
> > possibly storing the private key on the hardware dongle (but it seems like
> > there's still a key you need to put on the client system)
> > 
> > Quoting from the yubikey website:
> > OpenSSH version 8.2p1 added support for FIDO hardware authenticators. FIDO
> > devices are supported by the public key types “ecdsa-sk” and “ed25519-sk", along
> > with corresponding certificate types.
> > 
> > It then goes on to talk about generating the key with ssh-keygen
> > 
> > I could easily be missing something about this.
> 
> Perhaps I'm misunderstanding the nature of your misunderstanding :)
> 
> I can say that I've been using certs backed by sk keys ever since OpenSSH 
> 8.3 dropped, four years ago. Not only on my personal machines, but I also 
> implemented it in my previous job, both because I like doing it this way, 
> and because I wanted to show them a proof-of-concept. 
> 
> I typically keep at least two yubikeys with separate sk keys on them. This 
> provides redundancy: I can retain access to any infrastructure so long 
> as at least one key is available. Each yubikey can also hold multiple sk 
> keys, eg you might want a different key per job. 
> 
> You do need to export part of the private key onto the client node: `ssh-keygen -K` covers this.
> 
> Then a typical workflow for me involves signing some other key which will 
> be used for certificate authentication: 
> 
> ```
> ssh-keygen -s ~/.ssh/sk/work_ed25519_sk -I tim@<localhost> -n work -V -5m:+8h 
> ~/.ssh/certkeys/work_ed25519 
> ```
> 
> That creates a cert which will be valid for eight hours. The remote servers 
> are configured to accept certs signed by my yubikey together with the principal 
> name of "work". 
> 
> The benefit of this approach is the certificate is time-limited and backed 
> by 2FA, but you can go ahead and use the certificate without demonstrating 
> user presence (i.e. touching yubikey) at every point in a chain of proxyjumps. 
> It provides what I consider to be a nice balance between security and convenience. 
> 
> 
Yes, I know how public/private keys work.  That's not the issue.

I'm simply asking what is the risk/lack of security (compared with
public key) of using password authentication.


I.e. a straight comparison of:-

    Public/private key authentication where I force entry of the
    passphrase every time I log in (IdentityAgent=none).

    Password authentication

Using the same string of characters (well, the same complexity) for
the passphrase or password.

Yes, the password gets sent across a network whereas the key based
system is less vulnerable from that point of view, but what is the
**real world** chance of the password somehow getting decrypted on its
way between 'me' and the remote system?  On my home LAN the chance is
essentially zero so I can see little argument for using key based
authentication rather than password.  Is there any evidence that
passwords sent across the internet (which ssh encrypts) have any
chance of being intercepted and broken?

Yes, if MI5 or Russian criminals are interested in my data I should
maybe be more concerned but none of my systems have data with monetary
value or state secrets.  It just data that I don't want to lose, like
old photographs, old E-Mails, etc.

-- 
Chris Green