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

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 12:02:00PM -0700, David Lang via openssh-unix-dev
wrote:
> 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)
> 
I use several password 'bases' (and try and invent new ones every so
often) so at one time will have more than one 'family' of passwords in
use.

> do people use a password manager
> 
Not for passwords, I remember all the ones I use a lot.

> 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)?
> 
I start nearly always from either my desktop or my laptop, i.e. two
systems.  A USB FOB to store keys/passwords would be hopeless, I'd
lose it all the time/

> is your key passphrase similar to your password?
> 
Probably/possibly, when I decide which method I'm going to use there
will only be one of the other, but fundamentally they're going to be
similar as I'll use the same methods to generate and remember them.

> 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)
> 
No passwords stored anywhere except in my head.

> 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! :-)
> >
> >
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 
-- 
Chris Green

On 2024/10/21 12:02, David Lang via openssh-unix-dev
wrote:
> 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)
You can tell sshd to require *both* password and public key.
> 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.
hmm? That works pretty well in OpenSSH.