[prev in list] [next in list] [prev in thread] [next in thread] 

List:       focus-sun
Subject:    Re: Explanation of ssh (and a tie-in with the "which shell"
From:       Jan Grant <Jan.Grant () BRISTOL ! AC ! UK>
Date:       2000-06-30 8:42:03
[Download RAW message or body]

On Fri, 30 Jun 2000, Mark Grant wrote:

> Can somebody give me a bit of an explanation of ssh and ssh2.
> I've managed to get them up and working but I'm a bit hazy on how they
> are intedened to be used.

ssh and ssh2 provide a secure end-to-end connection over which you can
channel stuff like, for instance, a shell session (the normal use).

To do this they use a whole host of crypto cleverness. However, a
session must still be initiated. This means the first time client C
contacts server S, S will transmit its host key; the user on C is asked
if he trusts this transmission (which could, in theory, be forged - but
the forger only gets one chance to convince C that he is S).

This can be improved on by, for example, pre-installing a known-hosts
file on the client machine C. Alternatively, a site administrator can
email out the current public key of S in a signed email; the user can
verify the email's authenticity by checking the digital
signature. Sooner or later down this chain there has to be a leap of
faith and someone has to ake on trust that, for instance, the
fingerprint he has of the site admin is accurate. But I digress.

Ssh uses this to create a secure link between two endpoints. You _can_
limit sshd to only accept connections from machines it knows about
(using public-key identity verification or the much weaker IP
'verification' if you must).

> I'd like to be able to set it up so that you can ssh and scp between machines
> and not get
> asked for a password but I'd like this process to be secure.

Users can be authenticated using a number of different
techniques. There's the basic unix-password check (as you've
seen). There's also an option for _users_ (not just hosts) to
authenticate using public-key techniques.

This requires you to set up a user's private and public keypair. The
public key lives on the Server; the private key is stored on the client.

Now, it is possible to encrypt the private keyfile. This is, in fact, a
good idea. This means that when you try to make a connection from C to
S, the user on C is prompted for their passphrase to unencrypt the
private key file; the contents of this are used for secure
authentication.

How does this get better than password prompting? Well, you _could_ just
leave the private key file unencrypted (see below). Alternatively, you
could look at ssh-agent. This is a small daemon that runs on the client
and stores authentication details. You still have to supply a passphrase
to ssh-agent when it's running, but it remembers it; so you only have to
supply the passphrase once. This is secure _and_ convenient. Obviously,
with convenience comes a drop in security: can you trust that a user
won't leave their workstation unattended? etc.

> I also noticed that I get can it to trust joe@elvis but not root@elvis. Can I
> get it to trust root to or is that
> just to dangerous. ??

You can get it to; but a much better route would just be to su from a
normal authenticated session.

Regarding shells and password entries.

By default, sshd will fall back to unix authentication if public-key
user authentication is not available. Ssh also supports the "locking" of
a user account (if the account is locked, ssh won't let the user in).

We have a situation here where we had a single trusted machine that
needed to make connections to each of a set of servers and pull back
information on a regular basis.

We decided to use scp for this. However, scp needs a valid shell to
work*. So we set up the user accounts on each server that we needed to
contact with an "X" in the password field (so nobody can
unix-authenticate to the account. This means misconfigurations of, say,
ftpd won't let people in to the account because ftpd uses unix
authentication. Defense in depth) and a valid shell. This means root can
su to that user quite happily on the remote machines. Our trusted host
can make connections out to those machines (but not vice-versa: the
authentication is one-way only) and we get to use scp when we need it.

Obviously, a compromise of the trusted host leads to automatic
user-level shell accounts on each remote machine (we
leave the private key unencrypted on the trusted machine
because it operates completely autonomously). Consequently, this machine
is hardened and monitored carefully.

At least, this is the way we did it. There may be better ways to go
about this sort of stuff, but that was our experience with ssh. It's
pretty good, frankly.

Hope this helps - if any of the advice I've offered smacks of huge holes
please let me know!

always ready to learn -
jan

* This appeared to be true for 2.0.13, which we were using at the time.

--
jan grant, ILRT, University of Bristol. http://www.ilrt.bris.ac.uk/
Tel +44(0)117 9287163 Fax +44 (0)117 9287112 RFC822 jan.grant@bris.ac.uk
Donate a signature: http://tribble.ilrt.bris.ac.uk/~cmjg/sig-submit

[prev in list] [next in list] [prev in thread] [next in thread]