Authenticating users with SSH keys (PKI)

The SSH host key of a server proves the server's identity to the clients. This article is about the other direction: using a key pair to authenticate a user in Syncplify Server!, which is what SSH calls public key authentication, or PKI.

Unlike host keys, a user's key pair is not used for encryption: it serves only and exclusively to authenticate the user, that is, to verify their identity and decide whether to let them in. Authenticating with a key pair is a great deal stronger than a password, and it is the recommended method.

TIP

Generate Ed25519 keys. RSA keys are not recommended, and the legacy ssh-rsa signature algorithm is disabled by default; see Unsupported public key algorithm ssh-rsa.

Step 1: the user generates the key pair

To ensure the highest degree of protection, and to avoid the private key ever traveling over a network, the user generates the key pair (private and public key) and sends only the public key to the server operator.

On Linux, macOS and current Windows, that is one command:

ssh-keygen -t ed25519 -C "your name or email"

It writes the private key to ~/.ssh/id_ed25519 and the public key to ~/.ssh/id_ed25519.pub.

On Windows you can also use PuTTYgen: choose the EdDSA key type with the Ed25519 curve, generate the key, then save the private key (a .ppk file) and copy the public key from the text box at the top of the window.

Whatever the tool, the user must:

• keep the private key, which the SFTP client uses to connect, and never share it;
• send the public key to the Syncplify Server! administrator.

Step 2: the administrator imports the public key

In the Admin UI of the virtual site, open Access, then Users, edit the user and go to the Authentication tab. Under SSH public keys, add the key with a name and its value (the single line starting with ssh-ed25519), and make sure the PKI method is selected among the Authentication methods. Save the profile.

That is it: the user can now authenticate with their own key pair. If you want the key and a password, select both methods and turn on Require more than one method over SSH, which makes the SSH service demand both before it lets the user in.

What about keys generated on the server?

Earlier versions offered a second way, in which the administrator generated the key pair on the server and handed the private key to the user. It was never recommended, because the private key had to travel to the user somehow. The v8 Admin UI does not offer it anymore; the REST API keeps an endpoint that generates a key pair for a user, for automation that needs it, but the procedure above is the one to follow.