Leroy Tennison writes:

> The latter site states
> 'SFTP uses keys rather than certificates. [snip]
> SFTP clients must install keys on the server.'
> If sftp uses keys instead of certificates, what kind of keys are used
> and why can't they take advantage of chains of trust? If this
> statement isn't true please explain what's wrong with it.

In public key cryptography (which is the underlying principle in both
cases), you must somehow get hold of the other party's public key in a
secure manner - you must have the _correct_ public key, and not a key
belonging to an impostor.

In the ssh/sftp world this is largely left to the user - when you
first connect to a server you are presented with the fingerprint of
the server's public key and asked whether you want to accept it.

In the PKI/ftps world, public keys are cryptographically signed by a
certificate authority (CA), after the CA has verified the key holder's
identity. The public key and CA signature together form a
_certificate_. When you connect to a server and receive the server's
certificate, your client can verify the CA signature and thus verify
that the contained public key indeed belongs to the server you
intended to connect to.

For this to actually work, you need to a) somehow get hold of the
_CA's_ public key in a secure manner, since you need it to verify the
signature on the certificates, and b) be able to trust the CA.

> The other question concerns "SFTP clients must install keys on the
> server". (Again, if this is true) What are they talking about?

If you want to use your own keypair to _authenticate_ yourself to the
server, you must preinstall your public key on the server (I.e. put it
in ~/.ssh/authorized_keys, in the OpenSSH case). Note that all this is
about _authentication_, not transport encryption.

Leif Nixon - Systems expert
National Supercomputer Centre - Linkoping University