2

I recently read somewhere that:

SSH keys are for for encryption, while SFTP keys are for authentication.

Consider, we have a client machine C, and an SFTP server S. To establish a SSH connection (using public/private keys), the client creates the key pair PUc and PRc. The public key PUc is added to the authorized_keys file in the server S, and the client C uses their private key PRc to establish the connection.

However, I have read that for SFTP, the key pair is created in the server against a user and the private key is shared to the client for them to authenticate the SFTP connection. That is, server S creates PUs and PRs and the private key PRs is given to the client C to authenticate his SFTP connection. Is this understanding correct?

If yes, I understand that setting up SSH connection takes place in 3 stages:

  1. Verification of the server by the client (Host key checking).
  2. Generation of a session key to encrypt all the communication.
  3. Authentication of the client.

How does the client authenticate their SFTP session (with the private key they got before hand from server) in step 3?

Improve this question
1
  • 3
    SFTP runs over SSH. SFTP itself does not use any keys at all, nor does it do any encryption on its own. It completely relies on the underlying SSH for both encryption and authentication. So your question is based on wrong assumptions.
    – Martin Prikryl
    Commented Jun 24, 2021 at 6:28

1 Answer 1

Reset to default
8

There is no such thing as "SFTP key authentication", nor is there an "SFTP key" at all.

SFTP always uses standard SSH as the transport – the differences only begin after you've suc­cess­ful­ly au­then­ti­cat­ed (the client then requests either an interactive session, or an 'sftp' subsystem session). In other words, SFTP works exactly the same way as Git-over-SSH or Rsync-over-SSH.

Finally, SSH keys are not used for encryption; all of them are used for authentication only (in both directions). So the sentence that you've read and quoted is bogus in every possible way.

There are however two key pairs used for authentication – one belonging to the server (created during install) whose public key is verified by the client, and one belonging to the client, whose public key is verified by the server.

The overall process for both SFTP and interactive SSH is:

  1. Session key exchange: The client and server use (usually) Diffie-Hellman to negotiate the symmetric encryption keys.
  2. Host key checking: The server authenticates itself by using its private key to sign some data, which the client verifies against its known_hosts. (The signed data includes the previously negotiated session key and other parameters, preventing MitM attacks.)
  3. User authentication: The client authenticates itself by using its private key to sign some data, which the server verifies against its authorized_keys. (In this stage, the data is just a random challenge.)
  4. Session setup: The client opens several channels to interact with the server (such as an "agent forwarding" channel, a "TCP forwarding" channel, an "interactive shell session" channel, a "non-interactive shell command" channel, or an "sftp subsystem" channel).

The client can even open multiple sessions over the same connection – clients which support multiplexing such as OpenSSH or Tunnelier will allow you to authenticate just once, then run several interactive shells and/or SFTP transfers all over the same connection.

(Also, I'm very likely to be mixing up the relative order of SSH 'sessions' vs 'channels', but at least you get a rough idea.)

Note that the client in step 3 can authenticate itself in other ways (such as Kerberos or a simple password) instead of being required to use a keypair. This is still exactly the same for both SFTP and interactive SSH.

Improve this answer
9
  • For a client who uses a username and password for SFTP authentication, would that check also happen in step 3 (instead of the key based check)?
    – c_anirudh
    Commented Jun 24, 2021 at 7:00
  • 1
    Regarding the keypair being created on the server – it is a possible way of doing it, but it is entirely an administrative decision, completely unrelated to the protocol itself. It is true that some SSH servers may be managed in such a way that the system automatically creates keypairs and the user downloads their own private key (Amazon's AWS is one such example), while most servers prefer the opposite way (where the client generates their own keypair and uploads the public key), but it makes no difference to SFTP.
    – grawity_u1686
    Commented Jun 24, 2021 at 7:00
  • 1
    Regarding username and password – yes, it would also happen in step 3. The SSH server offers a list of mechanisms, the SSH client performs one of them. (Usually the client will try the 'publickey' mechanism with all keypairs first, and if nothing works it will try 'password' instead.) Using ssh -v or ssh -vv would show you some of the steps happening.
    – grawity_u1686
    Commented Jun 24, 2021 at 7:02
  • Thanks for the clarification :), I had deleted the original comment as @MartinPrikryl had cleared it in the question comments
    – c_anirudh
    Commented Jun 24, 2021 at 7:02
  • Incidentally if private key auth is used, the stock clients will rekey the connection using the user's key resulting in no MITM against ssh private keys with the host key in hand.
    – Joshua
    Commented Jun 24, 2021 at 17:50

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .