Re: ssh - password control or key control?

"C. J. Clegg" <reply.in.group@xxxxxxxxx> (06-11-01 09:44:43):

It seems there are two general ways... each user has his/her login
account with password, or each user's computer has a key file that's
matched up with key files stored on the host.

In the latter case, no login or password is necessary, apparently
... the computer connects, the host and the computer exchange keys,
and if everything matches up, the user is presented with a shell
prompt (or other access e.g. svn+ssh, etc.).

You have a wrong concept of a key. Don't think of files, rather think
of keys like in your pocket. In general, you would copy the (encrypted)
key file onto a USB stick or a floppy disk and take it with you. You
will still require to enter a passphrase then, but read on.


My question is, if you practice proper password discipline (big "if",
I know...), what do you gain by establishing key files rather than
just depending on the username/password exchange?

The advantage lies in the cryptographic technique used to establish such
a cryptosystem. Normal password-based systems are still attackable.
Using the MITM (Man In The Middle) attack, you can fully compromise a
password-based system. Using keys makes this attack impossible.

From an administrative perspective it's also much easier to use, because
you would create one 'general key' for all things you need SSH access
to, not necessarily only your server. You can safely access even
hostile systems with your key. The advantage is obvious: one key for
everything.

Last but not least, using authentication for both sides, you can be
assured that you're talking to the server you were expecting to talk to,
so it's good not to just take your id_rsa with you, but also the
known_hosts file.


Using key files would restrict access to specific client computers,
not just specific users, and that's the only advantage I can see. We
are not sure at this point whether that will work. There will be
times when employees have to visit customer sites and access our
server via the customer's computers (for one thing, not many of our
customers would allow "foreign" laptops to connect to their networks).

That's not true, and it wouldn't be anything of an advantage. As said
above, just take your key with you, because ...


So, even if we used key files for access, we'd have to allow ssh to
fall back to userid/password if the key files don't match.

.... password authentication would totally destroy the security of the
key-based system. You also shouldn't connect from hosts you don't
trust, as this is always a security hazard. Somebody willing to hurt
you just needs to become your customer in that case.

One very good solution to that problem is using an S/Key system, which
enables you to use one-time-passwords. Generate a list of passwords,
print it out and take it with you.


Yes, I'm aware of the existence of keystroke loggers and other spyware
that can run in the background and collect all sorts of information on
what a user is doing, and we would have no way of knowing if any of
that stuff is running on our customers' computers.

With S/Key you wouldn't care, although one possible attack is that the
user hijacks your connection in the background. Probably the most
secure method is still not to login from an untrusted host.


I guess we can require employees to change their passwords whenever
they return from a customer's site using the customer's computers.
Fortunately we are small enough that that's {barely} a viable option.

S/Key. =)


Regards,
E.S.
.