Public keys in SSH
This page attempts to explain public keys, as used in SSH, to readers unfamiliar with the concept.
The following concepts need to be understood by everyone, including beginner users:
A private key is a very large, pseudo-randomly generated number, that contains your secret information in any operation involving public keys. You generate the private key on your computer, using one of a variety of programs, and store it securely. You need to keep your private key secure; you never send it to anyone.
A public key is a very large number, mathematically derived from your private key. It is derived in such a way that the two numbers are linked, but so that the private key cannot be discovered by anyone who only knows the public key. The public key is what you send to other parties, to whom you want to authenticate yourself, or to whom you want to send encrypted messages. The public key is not sensitive, and does not need to be protected. It is public.
A signature is a result of a cryptographic calculation that can be performed only by a person who holds a private key, and can be verified by anyone who knows the corresponding public key. If a person is able to produce a valid signature of random data on demand, this proves that they have access to the private key associated with a particular public key.
A keypair is the combination of the private key and the public key. A keypair by necessity includes the private key, so a full keypair ought to be protected just like a private key.
A fingerprint is a cryptographic digest that can be used to uniquely identify a public key. Fingerprints are used for practical purposes, to compare keys which would otherwise be too large and unwieldy to compare manually. The most common fingerprint formats used in SSH are the SHA-256 format (example - "C+VpXsf..."), the MD5 format (example - "43:71:be:ab:d3:..."), and the Bubble-Babble format (example - "xubem-kiloc-getad-ponyh-..."). Like a public key, the fingerprint is not sensitive information, and can be disclosed indiscriminately.
A certificate is a public key, cryptographically signed by a certification authority (CA) in a public key infrastructure (PKI). The most widely used certificate standard is X.509. In the way SSH is most commonly used, it does not support certificates. Certificates are used primarily in TLS (SSL), which is a different protocol from SSH that serves a similar purpose. Most common SSH implementations only use raw public keys and private keys.
SSH sessions use public keys for two main purposes: server authentication, and client authentication. Both processes work very similarly, but they involve separate sets of keys. When discussing a specific public key in the context of SSH, it is important to be aware whether the key is intended to authenticate the server, or a client.
In Bitvise SSH Server
In Bitvise SSH Server:
Keys that are used for server authentication in SSH are displayed in the Host keys section of the Bitvise SSH Server Control Panel, and can be configured through the link Manage host keys. This section manages private keys, which are stored by the SSH server so it can authenticate itself to clients that connect to it.
In Keypair management, you can use the Export feature to export the public key associated with each host authentication keypair. You can send such a public key to an SSH client, so it will be able to authenticate the SSH server when it connects to it. If you do not send the client the whole public key, you should at least provide the user with your server's host key fingerprint, so that the user can confirm the server's public key is correct when they see it. The server's host key fingerprints can be viewed and copied from the main screen of the Bitvise SSH Server Control Panel.
Keys that are used for client authentication are managed through individual account settings entries. To view or configure these keys, open Easy or Advanced SSH server settings, and open a specific Windows or virtual account entry. Within this entry, find the link named "Public keys". This link opens a dialog which can be used to import, export, or remove public keys that the client can use to log into the server.
The SSH server will allow a client to add or remove keys themselves if "Allow public key management" is enabled in the user's account or group settings entry in Advanced SSH server settings, or if "Synchronize with authorized_keys" is enabled in Advanced settings > Access control.
If you are trying to configure public key authentication for a client connecting to Bitvise SSH Server, check also the Public Key Authentication section of our Bitvise SSH Server Usage FAQ.
Since versions 8.xx, the SSH Server also supports FTPS. FTPS is a file transfer protocol which uses TLS, not SSH; and TLS does use X.509 certificates. The SSH Server Control Panel includes a Manage certificates interface which allows you to generate a self-signed certificate or a certificate signing request (CSR) to obtain an X.509 certificate from an issuer (a CA). The SSH Server uses a certificate only for FTPS, where it is used to authenticate the server to the FTPS client.
In Bitvise SSH Client
In Bitvise SSH Client:
Public keys of hosts you have connected to can be viewed in Host key manager. When you connect to an SSH server for the first time, and the client has no record of the server's host key, the client will display the server's host key fingerprint, and will ask you to verify the key. It is very important to verify the server's host key fingerprint at this point, which should be done against a fingerprint you received through other means from the server's administrator. If you verify that the key is correct, the client will save it, and trust it for further connections to the server.
If you do not verify the server's host key, then the client cannot verify that the server you are connecting to is in fact the server you think you are connecting to. Not verifying the server's host key enables a man-in-the-middle attack - a situation where you aren't actually connecting to the server you think you are connecting to, but rather to another server that impersonates you to the destination server, and the destination server to you. Such a man-in-the-middle is able to observe all data sent over the SSH session, as well as modify what's being sent in real time. The only way to defend against such an attack is to make sure to verify the server's host key.
Private keys used for client authentication can be generated, imported and exported in User keypair manager. This interface allows you to generate a keypair for client authentication; you should keep the private key that's part of this keypair private. You can use the Export function to export the public key portion of a keypair, and send it to a server administrator, who can import it to allow you to authenticate using that key. The only thing you need to send to the server administrator is the public key; you should never send the private key, or the whole keypair.