ssh with password authentication
 

I seem to have encountered a moronic sysadmin who believes ssh is made more secure by turning off public-key authentication. Sure, people could make passowordless public-keys, but people could also make expect scripts.

Now the security of this guys box is not all that important really in the grand scheme of things, so I'm perfectly happy to have an expect script log myself into it. In fact, I'm using this script already. My problem is that I do not really want to type issh and iscp (standing for idiot ssh and idiot scp). There are three possible solutions:

Worst: Call the expect scripts ssh and scp and make them smart enough so that they do not try to enter a password when this guys system is not involved.

Bad: Hack, ssh to suppose a Password config option next to the User config option on a per hosts basis.

Better: Hack ssh itself to use ssh-askpass for password authentication. Then have ssh-askpass be a script which returns my password on this guys system when needed.. and runs the real ssh-askpass otherwise.

Best: Add a full blown encrypted password authentication mechanism to ssh-agent and ssh. That way ssh-agent would happily pass my password on this guys system off to anyone who wanted it, but the password would not be stored on disk. Instead, I would just type the password into the agent with ssh-add..

Anyone seen any of these systems implemented? I think ssh really needs to support something like this to prevent stupid sysadmins like this guy from shutting down PKI for no good reason. They could keep it off be default, but you really should not need to go to an expect script to get around one of these idiots.

Jeff

BTW> I type this stupid passwords in front of students every day, its more secure to have the password on disk then transfered from my fingers to the keyboard in front of people who might want to try to change their grades.. not that their grades are on that server.. but they do not know that.

The administrator may not be such an idiot (depending on the reasons he/she has for banning public keys).

I feel the public key/password decision is a balance and I can see why a sysadmin might decide not to allow them.

1. As you say, people can avoid having a passphrase. They can also have trivial passphrases and there is no easy way to prevent this. As you say, people can use expect scripts, but doing this requires knowledge whereas having bad passphrases is something everyone can do.

2. Without a PKI, how do you remove someone's access to a computer? If someone has ever had root access, they could have added a key to any account and the odds are no-one will ever notice. Without public keys it is a bit easier to do this (nothing's perfect of course).

Its always a trade-off. I've always gone with allowing public keys so far, but I can think of some cases where I wouldn't.

Iain.

Passwords suck
 

Revoking public key access is trivial, just delete the key from the server. If you have suffered serious compramise, you should tell users to revoke all the private keys on the server, especially the passwordless ones. As to people slipping keys onto your server when they hacked it, you should be able to just run a script to make changes to veryone's .ssh/authorized_keys2 file. In fact, grep can easily give you a summery of all keys which can connect from systems which are "off campus." (Your ssh configuration does actually pay attention to what system each key claims to be known from right?) I'd just use an awk script to email everyone a summery of their authorized_keys2 file and ask them to verify it.

No matter what negitive things you have to say about other authentication systems, passwords are inherently easy to "socially enginear." Most people have only a few passwords and an observentt person can easily figure out what the password is based on keystrokes (even from surprisingly far away). Beyond mearly knowing the password, once you know a persons password, you usually know something about how they make up passwords.. never mind that they are very likely to return to their old password eventually.

Anyway, its just a fact that people use better passphrases when they only need to type them rarely. As I said, the best method would be to hand the password off to the agent.

The only time I can imagine passwords ever being better then PKI is for a system which is incredibly infrequently used.. and even then you will use the system in bursts so you should styill be able to add a password to the agent.

I don't disagree with you; maybe I'm talking about a different situation.

I work in companies where multiple administrators manage each server (necessary when you have hundreds of servers and high uptime requirements). The problem that comes up is, if someone leaves the company or moves departments, how do you remove their access to the server. With passwords its reasonably simple - you delete their account, delete dormant accounts and make sure everyone changes passwords on a regular basis.

With public keys its much more difficult. Sure I can delete user a's public key, but what if user a had root access and has installed a different key in another user account. Am I going to check every account for keys? If I did, would I know what I was looking for? I can assume that the user can get access to a company PC one way or the other, so looking for remote keys is no good either.

Iain

Ah..
 

Yes, you point that the ex-user could hack a company PC is reasonable. I had kinda been ignoring that. The solutions to this problem are not as painless as I had claimed.

The simplest solution I can imagine is centralizing key managment somewhat. For example, you could have the users home directories NSF mounted accrost all servers (as you would most likely do anyway), but restrict each user to only having one public key in their authorized_keys2 file. The private key for that public key would be kept on their desktopp machine (encrypted) or even on a card. When the user wanted to use the seervers, tehy would load this key into the agent. They would even be able to ssh between servers if tehy turnned on forwarding of the authentication agent (risky in a diffrent way).

Of course, if each machine only has like two users who can login (root and some generic non-root), you can just managed the keys for those two users just as you would manage a password file, but I think you wanted every user to have their own account.