Key-Based Authentication (Public Key Authentication)

Key-based authentication is a kind of authentication that may be used as an alternative to password authentication. Instead of requiring a user's password, it is possible to confirm the client's identity by using asymmetric cryptography algorithms, with public and private keys.

Nowadays, password authentication is more popular than public key authentication. It does not require much preparation (at least, from the client's point of view), and perhaps is generally more intuitive. In order to log into a server, users have to provide their secret passwords, which are verified by the server. A disadvantage of this method is that, when a server is publicly available, it may be targeted by various types of brute force and dictionary attacks, and the password may eventually be broken and revealed. Moreover, this method requires the users to remember their (ideally difficult and complex) passwords.

Public key authentication offers a solution to these problems. The idea is to assign a pair of asymmetric keys to every user. Users would store their public keys in each system they want to use, while at the some time their private keys would be kept secure on the computers, the users want to use to connect with those secured systems. During establishing the connection, the server would use the public key to authenticate the client, for example by encrypting some number and asking the client to decrypt it, by using his corresponding private key.

Of course, the brute force attacks may still be performed by an attacker, but the complexity of long and unreadable keys is much larger, and such attacks would have significantly smaller chance of success. The asymmetric keys using at present consist of thousand of bits (as for year 2016, the recommended lengths are 2048 and 4096 bits).

The most popular algorithm used for key-based authentication is RSA.

Public key authentication on Linux

Most Linux releases provide native support for SSH (Secure Shell) cryptographic network protocol (most commonly for OpenSSH). Users are able to easily create and configure pairs of asymmetric keys. After that, they can log into servers that support key-based authentication automatically. During establishing the connection, SSH processes running on the server use the proper public keys to challenge and authenticate the client processes, that are located on the client machine.

Generating RSA keys

In order to benefit from all the advantages of key-based authentication that are described above, first the user has to create a pair of asymmetric keys. On Linux this can be achieved by using the SSH command:

ssh-keygen -t rsa -b 4096 -C ""

The user will be then asked for a few configuration parameters, like the desired location to save the keys and, optionally, a passphrase which will be used to protect the private key. Usually the keys are created in ~/.ssh directory, in the home folder. The public key is stored in file, whereas the private key can be found in id_rsa.

The private key can be stored on an external memory stick. The users will be able to authenticate themselves on any computer they happen to use, as long as they are able to present the proper memory card.

Private key passphrase

If during key pair generation, a password was entered by the user, then the private key will be stored in an encrypted file. The user will be asked to authenticate himself, before the private key is released and ready to use for establishing a connection. Usually, operating systems cache the decrypted key in memory and release it automatically, until the end of local login session. On Linux, the process responsible for that is called ssh-agent.

Because the private key is stored locally, on a trusted computer, it is not possible for an intruder to start attacking it online. Usually, the private-key file permissions should be restricted, and only the owner should be able to read it.

The encrypted private key can by attacked, only when the attacker got full access to the computer (for example, by stealing it). By the time the cipher is broken, the user has time to remove his old public key from servers, that he was using, and to create a new secure pair of asymmetric keys.

Such an approach is much more secure that normal, password-based authentication, where an attacker can start attacking the user's password online.

Transfer a public key

In order to be able to log into a server, the user has to send there the public key. The SSH tool can by used for that:

ssh-copy-id <username>@<host>

The user may be warned that the host is unknown, and will be asked for the proper password, but apart from that the command automatically transfers the public key to the specified server.

An alternative method is to manually append the contents of file to ~/.ssh/authorized_keys located on the server (in the root user's account).

The results of both methods are the same: the public key is added to the authorized_keys file, which is then used by the server when someone tries to connect by using the SSH protocol.

Using SSH connection

The SSH connection to the server can be tested by using the command:

ssh <username>@<host>

If succeeded (that means if the key-based authentication is correctly configured), this command will establish a secure connection to the server, without the need of providing the remote account's password. If the private key is encrypted, then the user will be asked for the password which protects it.

After enabling the key-based authentication on the server, the password authentication could be disabled, to prevent brute-force attacks. It can be done by changing the flag PasswordAuthentication in /etc/ssh/sshd_config, and restarting the SSH service. It is also possible to specify the IP addresses which would be allowed to use the password authentication, and block the functionality for the others.

The configuration file mentioned above is also a place where you can enable or disable the key-based authentication on the server altogether. The flags are called PubkeyAuthentication and RSAAuthentication, and they both should be enabled.

Public key authentication on Windows

Using key-based authentication on Windows machines is also a relatively easy task but one has to equip himself with an application that provides such capabilities.

The programs described below can be used to generate the pair of keys. After that, the public key needs to be manually provided to Linux, to the file .ssh/authorized_keys mentioned above.

Git Bash

Git Bash is a terminal client which (as one may guess) provides bash functionalities to Windows machines. It is quite similar to CygWin but faster and less complex. For the purposes of generating asymmetric keys, it is just enough.

The web address of the Git project is, and its Windows version can be downloaded from there.

The pair of keys can be generated using the same commands, like on Linux (ssh-keygen, and so on).


PuTTY is an SSH and telnet client, an open source application available for Windows platforms. It consists of several components, PuTTY, PSCP, PSFTP, PuTTYtel, Plink, Pageant, PuTTYgen, pterm. All of them are quite useful. The project home page is

To generate the keys, one should use PuTTYgen tool, which can be found in PuTTY installation directory. The user should just press the 'Generate' button. The application requires enough random data to generate random byte streams used for key-generation, so the user will be asked to make some random mouse movements.


Bitvise is a company that specializes in SSH server and client applications development. It provides a few various services that are not as free as both tools described above, however they can be used freely for personal purposes. The website of the project is

To generate the pair of keys, one should use User Keypair Manager tool, which can be found on the front page. After clicking 'Generate New' button, the user will be asked for the type of the key and for the optional password, similarly like during generating the keys on Linux.

User Keypair Manager allows to export the created keys. One has to select the format of output (which is, usually, OpenSSL).