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! :-) > >
Chris Green
2024-Oct-21 19:41 UTC
Security of ssh across a LAN, public key versus password
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
Stuart Henderson
2024-Oct-21 21:40 UTC
Security of ssh across a LAN, public key versus password
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.