I am learning about SSH and how to use it to secure file transfers and commands between a windows machine and a Linux server. Everything that I have read so far indicates that I need to use an SFTP client (like WinSCP) to connect to my server and transfer files. Gettin gin a little deeper, the docs for WinSCP never tell me to set up a public or private key pair on my client and server. I thought that the public and private keys were a fundamental element of how SSH worked. How is SFTP (which I have read is based on SSH) able to function without a public and private key pair (or is it defaulting to an insecure mode like FTP in the situation?)

Originally, I thought that I needed to create these pairs for each individual that wanted to connect to the server and manually copy the public key file to the clients machine.

EDIT =============================

I did not understand that there are two sets of public/private keys in use, one that is created by the server and one that could possibly be created by the client. Initially, I though that they were the same public/private key pair.

3 Answers 3


Short answer: there is necessarily a public/private key pair on the server. There may be a public/private key pair on the client, but the server may elect to authenticate clients with passwords instead,

SSH is a generic tunnel mechanism, in which some "application data" is transferred. One such application is the "remote shell" which is used to obtain an open "terminal" on a server, in which terminal applications can be run. Another, distinct application is the file transfer protocol known as SFTP. From the SSH point of view, which application is used is irrelevant. This means that any authentication concept applies equally to SSH (the "remote shell" part) and SFTP.

The server MUST have a public/private key pair. That key is used for the tunnel part, so a server will use the same key pair for all applicative protocols. Most Unix-like operating systems (e.g. Linux) create a SSH key pair when first installed, and will use it thereafter. This means that you don't have to "create a key" when you configure your SSH server to also be used as SFTP: the server already has a key.

A client may have a public/private key pair if it wishes to be authenticated based on that key; this is all about client authentication, i.e. about how the server will make sure that it is talking to the right client. Password-based authentication and key-based authentication are the two most common methods (some servers are configured to require both). By definition, only the key-based authentication requires that the client stores and uses a key pair of its own.

  • 1
    @MartinPrikryl "There's always (automatically generated) client-side key pair, even with password authentication." - No there isn't. Asymmetric crypto keypairs are only used for authentication, not establishing a secure channel._"How else would then the server be able to encrypt the information sent to the client, ..."_ - By using a Key Exchange method (such as Diffie-Hellman) to established a shared key (not keypair!) that is used by a symmetric cipher (typically something like chacha or AES). No client-side keypair involved.
    – marcelm
    Commented Feb 15, 2018 at 16:49

It's able to function because the keypair already exists on the server. The SSH server has the keys necessary to protect the information in transit. SSH server will use a public key, that client device uses the public key to encrypt information sent to the server. The server then uses its private key to decrypt that information and process.

See http://www.slashroot.in/secure-shell-how-does-ssh-work

  • 1
    Is that to say that the server has a generic Public/Private key pair which is used in I don't specifically create a pair? In this case does it send the public key to the SFTP client when it attempts to connect? Originally, I thought that I needed to create these pairs for each individual that wanted to connect to the server and manually copy the public key file to the clients machine.
    – Hoytman
    Commented Apr 16, 2014 at 14:39
  • Yes, if you look at the link I provided Step 3.1 explains: "The server will disclose its identity to the client. This identity is a rsa public key of the server." Commented Apr 16, 2014 at 14:44
  • If you want to use keys to authenticate your clients (instead of username/password) that requires your copying your public key of said client to the server, but thats only if you're not using password authentication. Commented Apr 16, 2014 at 14:48
  • This answer (as most here) is just wrong. The host key is not used to encrypt information. It's used only to identify the server. Commented Jun 7, 2017 at 14:05

In SSH, you have two sets of key pairs: one for the server and one for the users.

The server key pair is mandatory but it is typically generated during the installation of the server: all you have to do is validate the server public key fingerprint (a simple hash) and, as long as the key is unchanged, your client will silently connect.

The key pair you use for authenticating, however, can be optional (or disallowed) depending on what authentication method you've decided to allow or require on the server.

The Wiki article on SSH has plenty of juicy details but, to summarise, there are 4 supported authentication mechanism:

  • Password requires a username and password combination
  • Public key requires acess to the private part of the public key you use for authentication (typically, you setup the key pair on the client and just update the server configuration with your public key).
  • Keyboard interactive is mostly used for one-time passwords and similar.
  • GSSAPI, a framework used for implementing other authentication scheme, usually to implement single sign-on (most notably Kerberos)
  • This answer (as all here) is just wrong. The host key and client key are not used for encryption. They are used only to identify one party to the other. For encryption ephemeral/temporary keys are used, which exists on both sides, no matter what authentication is used. Commented Jun 7, 2017 at 14:06
  • 3
    Please read my answer again. Nowhere do I make any assumption or comment about how the encryption key is negotiated. It's all about authentication.
    – Stephane
    Commented Jun 8, 2017 at 7:14
  • Sure, but my understanding of the question is that it's about encryption. While not stated explicitly, its wording suggests so (e.g. the reference to "defaulting to an insecure mode"). Commented Jun 8, 2017 at 7:28

You must log in to answer this question.

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