Passwords
The Debian System Administrators decided, apparently, that disabling password logons is a good thing that warrants a 'Good News' post.
Allow me to politely disagree, for two reasons:
First, an SSH key is a password that is stored on the hard disk, while a 'regular' password is only stored inside someone's brain. While torturing someone to get at their password is arguably possible, it is not possible to do so without this person noticing. The same cannot be said about someone secretly stealing a file from someone else's hard disk; and while it is certainly possible to protect an SSH key with a password, it is not at all required to do so in order to use such keys. As such, on the server end you have no way to know whether a remote client is in fact the person whom they claim to be, just because they happen to have a SSH key that just happens to match the original.
Second, security is not accomplished by forcing people to use things they do not want to use. If you do that, they will find ways to work around your security—leaving you with no security at all.
But oh well, it's not my call to make, so whatever.
Isn't the workaround just to have a ssh-key with the password as passphrase? (so while I agree that too much security implies bad security, I do not so much see the point with this one).
Also while it is true that keys are not inherently more secure than passwords, there are bots there trying passwords currently in reality but not keys. (because even a good password could be a lame too easily obfuscated wort in another language you do no know, so the existance of bad passwords makes allowing passwords an additional thread).
But I guess the most important point is that the majority of people already uses a gpg-key, as using passwords is just annoying to login. And having two ways in are two ways that can be broken. (I personally have not set a password in Debian DB for that reason, because what is not there can not cause harm).
A password can be "something you know"; an ssh key is "something you have".
I think the more realistic security concern at the moment is script kiddies with dictionary attacks. In that sense, this is an improvement in security.
It would seem reasonable to require both. Then you can be a bit less paranoid about storing your ssh keys, and use a weaker password. I don't think SSH does that though.
Exercise for the reader: If a server requires both an SSH key and a password for login, state one disadvantage of encrypting the SSH key using the login password.
Most people have remote accounts on more than one system. If those systems are password-based, that means more than one password, and human minds can't actually remember too many terribly complicated things. Sadly, this suggests that password-based authentication will be likely to produce one or more of the following:
None of these situations are better than the problems you describe with public keys, and some are demonstrably worse. For example, sharing a password across two accounts basically guarantees that there is at least one third party capable of breaking into either account: the administrator of the other account.
Asymmetric crypto raises the bar for brute-force attacks (modulo things like the OpenSSL debacle, that is
) and demands no shared-secret arrangements.
Ultimately, you can't trust anyone to keep a password secret any more than you can trust them to keep a key secret. I think the DSA no-password decision was a good one.
All good points Wouter, but I would say: a password is no more a guarantee to the server that the person is who they say they are than a key. You can steal a key, you can steal a password.
I agree that forcing people to use something they don't want to is bad too. But I don't know for sure that the majority of users of Debian systems are resistant to this idea. For all I know, the DSAs have seen such a small number of password logins vs. key logins that turning it off is prudent.
An SSH key is very much not just "a password written down". Passwords are sent in the clear (inside the tunnel) and are therefore more subject to MITM attacks, keyloggers, etc. SSH keys, because of the asymmetric crypto, if you do manage an MITM attack using an SSH key does not reveal anything which could be used to authenticate another time.
This is not to say they are a panacea, but they do have definite advantages.
On the flip side, it's also possible to get some of the same advantages without keys, for example using SRP for the passwords (which SSH doesn't currently do) or using a one-time-password scheme (OTPW would be what I recommend. The University of Cambridge Computer Lab recently moved to requiring keys or OTPW after a keylogger in an internet cafe compromised a bunch of machines and Marcus Khun of the security department there wrote OTPW to fix a few security problems in existing schemes like OPIE)
Matt