How to create a ssh private/public keypair containing an embedded passphrase
-
- ssh uses encrypted keys as part of the protocol for setting up a connection between one system and another - one such pair of keys (the host keys) are part of the operating system configuration for each system and are not normally of concern to users of the systems. But ssh has an optional feature where you can create your own pair of keys, known as the private and public keys, stored in your ~/.ssh folder. When you make a connection using ssh , scp or sftp to a remote system, ssh will detect if you are using your own ssh keypair and if so, will not use the system's normal login password (that is, the password you type in when sat in front of a computer and using the keyboard and screen) for authenticating your login credentials. Instead it will use the encrypted information embedded inside your ssh keypair.
- Although you can choose to create two different types of private/public keypairs, one that contains an embedded passphrase and one that does not, here we will describe only the former since this type of keypair is mandatory with the new Maths ssh gateways; they will no longer accept a keypair that does not contain a passphrase, a mis-matched private/public keypair (with or without an embedded passphrase) or no keypair at all.
- So the first step is to think of a passphrase - this is like a login password and you can even make it the same as your current login password for the remote system if you wish although it is better to choose a different one; the reason for this is if your login password becomes known to others who then access your remote system, and go on to change the password to something else, thereby locking you out from using a password to access the remote system, you can still use the passphrase in your ssh keypair to get into the system remotely and do whatever you need to do to deal with the intrusion, such as setting a new login password. This gives you a back-up route into the remote system that's well worth having.
- Creating the key pair is easy using the ssh-keygen utility - there are quite a lot of options to this (see the man page) but by default when invoked with no options, modern versions of this utility will create keys suitable for most users (a 3072 bit SHA256 RSA key pair for use with ssh protocol 2 connections). So in the example ssh-keygen session shown below, type in your chosen passphrase when prompted, as shown in this example:
- This will create two keys in your ~/.ssh folder named id_rsa, which is your private key and id_rsa.pub, your public_key as you can see in the directory listing in the screenshot immediately after creating the keys. The id_rsa key you should look after and never give to anyone else; note that its permissions are such that only yourself can read it or change it and if you relax these permissions in any way, the key becomes insecure. Most ssh clients will warn or even prevent you from using the key until the permissions have been set correctly. Happily, ssh-keygen sets the permissions correctly for you when it finishes creating the key. On the other hand, the public key must be readable by all - this is intentional otherwise the remote system will not be able to use your public key - but it must not be capable of being altered for deleted by others; again ssh-keygen will set the permissions for you.
- When using ssh private/public keys to connect to other systems, the private key, id_rsa, needs to be in your ~/.ssh folder on the computer you are making the ssh connection from while the id_rsa.pub public key must be in a file called authorized_keys in your ~/.ssh folder on the computer you want to connect to.
- Once you have created your ssh keypair you will need to add your id_rsa.pub public key to your authorized_keys file in your ~/.ssh folder on the remote ssh server. There are various ways of getting the key over to the remote ssh server including using scp or sftp, cutting & pasting the key's content into a a file using an editor on the remote system and saving the file as 'id_rsa.pub' or if you have physical access to the remote system, copying the key onto a USB pendrive, plugging this into the remote system and then copying it into your ~/.ssh folder on the system that way. Note: if getting your public key onto a Maths system is going to be a problem for you for any reason, you can always send the key to Maths Research Computing as an email attachment and we can put it in place for you.
- If you already have an id_rsa.pub key in your remote ~/.ssh folder from another system that you still need to use, it's a good idea to rename it to indicate what system it was from and to avoid it from being confused or overwritten with other id_rsa.pub keys. ssh doesn't care what the key is called on the remote system but what it does care about is that it is present in the authorized_keys file.
- This is a text file containing the contents of all the id_rsa.pub keys you want to use with the remote system, with one key to each line like this example (below), which shows two keys have already been added to the authorized_keys file - the public keys created by ssh-keygen append the username of the person who created it along with the hostname of the computer it was created on at the end of the keyfile, as you can see, so it should be easy to keep track of them if you have more than one key.
- The easiest way to add your new id_rsa.pub file to your authorized_keys file is to simply append it to your ~/ssh/authorized_keys file:
-
cat id_rsa.pub_from_my_computer >> ~/.ssh/authorized_keys
- This will add your new public key, renamed here as 'id_rsa.pub_from_my_computer', to your ~/.ssh/authorized keys file, creating this file if it does not already exist.
- With your public key now correctly installed on the remote ssh server and your private key in place on your local system, when you next connect to the remote system, you will then be prompted for your ssh passphrase instead of the remote system's login password for your account.
Andy Thomas
Research Computing Manager,
Department of Mathematics
last updated: 5.5.2026