Adding an SSH Key

Rationale: Create a new private SSH key, or not?

To follow these steps, people who do not have an existing private SSH key will need to create one. If this computer system is being created as part of a new project, people may wish to create a new SSH key that will be used for the machines related to this project. In other circumstances, people who have an existing private SSH key may wish to use that.

Creating an SSH key

Make a key.

Choosing a computer/device

Note: if you have easy access to make a key on a system other than the machine that will be logged into, then using such a system is generally preferred. That way, the machine that will be logged into doesn't have an unnecessary extra copy of the private key (possibly stored in a section on the disk that is retaining deleted data). So, if this SSH key is being made to log into a virtual machine, creating the key on the physical machine may be preferable. The best machine to do this is generally whatever machine will be running the SSH client software that is used to log into the SSH server.

Just make sure that the computer being used doesn't fit the description of generators of bad SSL key files.

  • A choice needs to be made, regarding which computer to use to generate the key.
    • The (“physical”) computer, which is the computer that is being used to run the “virtual machine” software, may be a perfectly good choice of a computer to run the software that generates the SSH keys.
Using PuTTY for Microsoft Windows

This is an option. (This is not considered to be a particularly “better” option than using OpenSSH, but if the machine that you want to generate SSH keys is a computer running Microsoft Windows, this might be an option that people are interested in using.

The Generating the key files has a section about “Generating the key files with PuTTYGen (for Microsoft Windows)”. However, for the rest of this guide, the key needs to be created in a way that is compatible with OpenSSH. The PuTTY software suite comes with some software (e.g., PuTTYGen with the Microsoft Windows software) that can be used to create a private key. However, be careful to export the file into OpenSSH format. (Use the Conversions menu, and choose “Export OpenSSH key”.) A *.ppk file will not work (although the data in that file can be used; a *.ppk file has the necessary data which can be converted into a workable file).

Determine where the key will go

A great location might be where documentation is stored. However, if that system does not have an easy way to directly access virtual machines via SSH, then another machine (such as the physical machine) might be a more prudent location.

After generating the key, it may be good to keep the key in a very accessible spot. While a remote system, such as a NAS, might be a sensible spot for lots of data (as long as sensitive/confidential data, like credentials such as these keys, are sufficiently secured), such a remote location might not work as well if networking becomes non-functional. Having a copy on the physical machine's local hard drive might be more practical when trying to troubleshoot problems. (Having an unnecessary copy on a local system might also be less secure. Which approach is the better approach might be a detail that varies between different systems, and which different network administrators may have different levels of comfort/preference for.)

Anyway, decide where the key will go.

Performing the creation

To create a key:

  • Don't use one of the generators of bad SSL key files.
  • (As noted above, the “physical” machine that runs the “virtual machine” software may be a good choice; probably preferred more than doing this on the actual “virtual machine”.)
pwd

(These instructions do not try to preserve the present directory. If knowledge of the present directory is something you wish to retain for some reason, then make a note of it.)

mkdir ~/newkey/
cd ~/newkey/

This guide doesn't go into great details about creating an SSH key, except to point out that details are part of another guide that is being referenced from here. Just remember to return to this guide once the keys are made.

Ideally, the creation of the key will be on the same device that will be storing the key. Minimizing the times that the file is copied to different systems can help to minimize the ability of a scenario where somebody accesses the data from another device, possibly by using data recovery tools that may be able to access data that has been deleted (Disaster recovery: undelete)

Comment in OpenSSH format
Deploy the public key

The public key will get deployed to the “virtual machine”, so that the key pair can be used to log into the “virtual machine”.

On the machine that will be logged into, make a directory called “.ssh” under the home directory of the user that will be logging in with this key.

echo ~
mkdir ~/.ssh

The public key file's contents needs to make it into the .ssh/authorized_keys file under the user's home directory. First, let's look at how NOT to do this:

Avoid putting secrets on command lines

Note: Do NOT do this:

echo mykey | tee -a ~/.ssh/authorized_keys

The key should generally get into a file on the system by using one of these methods:

  • using a “copy and paste” feature, and placing the pasted text into a file (by using a text editor, or redirecting cat which is also viable, but probably not usually easier for beginners)
  • using a file transfer protocol

There are two threats to be avoided here. First, some systems may record what happens on a command line. (That could be due to a HISTFILE variable, or sudo placing data in the /var/log/secure file: details of possibilities may be mentioned in the section about logs of (other) user activity.)

The other possibility is that any user on the system, without permission to view any restricted log files, could potentially see the credentials by running ps at just the right time. Although the chances of that seem to be extremely small, particularly on a system where no other users will be having access to the system, the general consensus is that the risk is not worth taking. Instead, take the time to figure out how to avoid placing credentials directly on the command line.

It is generally (more) acceptable to have a command line include a reference to a file that contains credentials, because then filesystem security can be used to protect the actual credentials. However, don't just place credentials that should be secret, like a password, directly on the command line.

An alternative may be:

cat | tee -a ~/.ssh/authorized_keys

Then type whatever credentials need to be secret, and then press the EOF character.

So, if you used a file transfer protocol to get the public key onto the system, then use a command like this to add the public key's contents to the necessary file.

cat mykey.pub | tee -a ~/.ssh/authorized_keys

placing the needed contents into the authorized_keys* file

The information from the public key should contain a comment that identifies the key, as noted by: Recommended further modification: public key file's comment If that hasn't been done already, please proceed to take care of that.

Finally, handle permissions:

[#osshprmw]: OpenSSH permissions for writing

Then, handle permissions.

If you're logged in as the user:
chmod go-w ~/ ~/.ssh/ ~/.ssh/authorized_keys*
Otherwise...

Otherwise... customize the username:

export USRTOCFG=someuser
  • Customize that username as needed. (These instructions needn't be done if the terminal session is logged in as the user who will be using the key.)
export HOMTOCFG=$(eval echo \~${USRTOCFG})

(If you are logged in as the user that will be getting adjusted, then you could just use ~ as the value for ${HOMTOCFG}.)

sudo ${SHELL} -c "chmod go-w ${HOMTOCFG}/ ${HOMTOCFG}/.ssh/ ${HOMTOCFG}/.ssh/authorized_keys* "
unset HOMTOCFG USRTOCFG
Additional related reading

This information is also referenced at this location, from this guide: Permissions required for the authorized_keys* file

Test it

On a system with the private key file:

ssh -p 22 -i keyfile -l username remotesys