38,760
edits
Using SSH keys in Linux/en: Difference between revisions
Jump to navigation
Jump to search
Updating to match new version of source page
(Updating to match new version of source page) |
(Updating to match new version of source page) |
||
| Line 8: | Line 8: | ||
<!--T:14--> | <!--T:14--> | ||
Key pairs are typically located in the <code>.ssh/</code> directory in your home directory. By default, a key is named with an "id_" prefix, followed by the key type ("rsa", "dsa", "ed25519"), and the public key also has a ".pub" suffix. So a common example is <code>id_rsa</code> and <code>id_rsa.pub</code>. A good practice is to give it a name that is meaningful to you and identify on which system the key is used. | Key pairs are typically located in the <code>.ssh/</code> directory in your /home directory. By default, a key is named with an "id_" prefix, followed by the key type ("rsa", "dsa", "ed25519"), and the public key also has a ".pub" suffix. So a common example is <code>id_rsa</code> and <code>id_rsa.pub</code>. A good practice is to give it a name that is meaningful to you and identify on which system the key is used. | ||
<!--T:11--> | <!--T:11--> | ||
| Line 21: | Line 21: | ||
[name@yourLaptop]$ ssh-keygen -b 4096 -t rsa | [name@yourLaptop]$ ssh-keygen -b 4096 -t rsa | ||
</source> | </source> | ||
( | (This example explicitly asks for a 4-kbit RSA key, which is a reasonable choice.) | ||
<!--T:3--> | <!--T:3--> | ||
| Line 52: | Line 52: | ||
<!--T:5--> | <!--T:5--> | ||
When prompted, enter a passphrase. If you already have key pairs saved with the default names, you should enter a different file name for the new keys to avoid overwriting existing key pairs. | When prompted, enter a passphrase. If you already have key pairs saved with the default names, you should enter a different file name for the new keys to avoid overwriting existing key pairs. | ||
More details on best practices can be found [[SSH_Keys#Best_practices_for_key_pairs| here]] | More details on best practices can be found [[SSH_Keys#Best_practices_for_key_pairs| here]]. | ||
==Creating a key pair backed by a hardware security key== | ==Creating a key pair backed by a hardware security key== | ||
Some sites now support the use of SSH keys backed by a hardware security key (e.g. | Some sites now support the use of SSH keys backed by a hardware security key (e.g. YubiKey). If you need one of these keys, you can generate it with the <code>ssh-keygen</code> command: | ||
<source lang="console"> | <source lang="console"> | ||
| Line 96: | Line 96: | ||
==Installing via CCDB== <!--T:22--> | ==Installing via CCDB== <!--T:22--> | ||
We encourage all users to leverage the new CCDB feature to install their SSH public key. This will make the key available to all our clusters. | We encourage all users to leverage the new CCDB feature to install their SSH public key. This will make the key available to all our clusters. | ||
Grab the content of your public key (called id_rsa.pub in the above case) and upload it to CCDB as per | Grab the content of your public key (called ''id_rsa.pub'' in the above case) and upload it to CCDB as per step 3 of [[SSH_Keys#Using_CCDB|these instructions]]. | ||
==Installing locally== <!--T:16--> | ==Installing locally== <!--T:16--> | ||
The method below is still available, but we encourage all users to [[Using_SSH_keys_in_Linux#Installing via CCDB|install keys via CCDB]]. | |||
If for some reasons you still want to upload the public key locally on a specific cluster, the steps are described below. | If for some reasons you still want to upload the public key locally on a specific cluster, the steps are described below. | ||
<!--T:23--> | <!--T:23--> | ||
The simplest, safest way to install a key to a remote system is using the ssh-copy-id command: | The simplest, safest way to install a key to a remote system is by using the <tt>ssh-copy-id</tt> command: | ||
<source lang="console"> | <source lang="console"> | ||
ssh-copy-id -i ~/.ssh/mynewkey.pub graham.computecanada.ca | ssh-copy-id -i ~/.ssh/mynewkey.pub graham.computecanada.ca | ||
| Line 111: | Line 111: | ||
<!--T:17--> | <!--T:17--> | ||
If necessary, you can do this "manually" - in fact, ssh-copy-id isn't doing anything very | If necessary, you can do this "manually" - in fact, <tt>ssh-copy-id</tt> isn't doing anything very magical. It's simply connecting to the remote machine, and placing the public key into <code>.ssh/authorized_keys</code> in your /home directory there. The main benefit from using <code>ssh-copy-id</code> is that it will create files and directories if necessary, and will ensure that the permissions on them are correct. You can do it entirely yourself by copying the public key file to the remote server, then: | ||
<source lang="bash"> | <source lang="bash"> | ||
mkdir ~/.ssh | mkdir ~/.ssh | ||
| Line 121: | Line 121: | ||
<ul> | <ul> | ||
<li>The private key file must not be accessible to others. <code> chmod go-rwx id_rsa </code> | <li>The private key file must not be accessible to others. <code> chmod go-rwx id_rsa </code> | ||
<li>Your remote home directory must not be writable by others <code> chmod go-w ~ </code> | <li>Your remote /home directory must not be writable by others. <code> chmod go-w ~ </code> | ||
<li>Same for your remote ~/.ssh and ~/.ssh/authorized_keys <code> chmod --recursive go-rwx ~/.ssh </code> | <li>Same for your remote ~/.ssh and ~/.ssh/authorized_keys <code> chmod --recursive go-rwx ~/.ssh </code>. | ||
</ul> | </ul> | ||
Note that debugging the remote conditions may not be obvious without the help of the remote machine's system administrators. | Note that debugging the remote conditions may not be obvious without the help of the remote machine's system administrators. | ||
=Connecting using a key pair= <!--T:6--> | =Connecting using a key pair= <!--T:6--> | ||
<li>Finally test the new key by sshing to the remote machine from the local machine with | <li>Finally, test the new key by sshing to the remote machine from the local machine with | ||
<source lang="console">[name@yourLaptop]$ ssh -i /path/to/your/privatekey USERNAME@ADDRESS</source> | <source lang="console">[name@yourLaptop]$ ssh -i /path/to/your/privatekey USERNAME@ADDRESS</source> | ||
where | where | ||
| Line 140: | Line 140: | ||
=Using ssh-agent= <!--T:18--> | =Using ssh-agent= <!--T:18--> | ||
Having successfully created a key pair and installed the public key on a | Having successfully created a key pair and installed the public key on a cluster, you can now log in using the key pair. While this is a better solution than using a password to connect to our clusters, it still requires you to type in a passphrase, needed to unlock your private key, every time that you want to log in to a cluster. There is however the <tt>ssh-agent</tt> program, which stores your private key in memory on your local computer and provides it whenever another program on this computer needs it for authentification. This means that you only need to unlock the private key once, after which you can log in to a remote cluster many times without having to type in the passphrase again. | ||
<!--T:19--> | <!--T:19--> | ||
| Line 164: | Line 164: | ||
<!--T:20--> | <!--T:20--> | ||
Note that many contemporary Linux distributions as well as macOS now offer graphical "keychain managers" that can easily be configured to also manage your SSH key pair, so that logging in on your local computer is enough to store the private key in memory and have the operating system automatically provide it to the SSH client during login on a remote cluster. You will | Note that many contemporary Linux distributions as well as macOS now offer graphical "keychain managers" that can easily be configured to also manage your SSH key pair, so that logging in on your local computer is enough to store the private key in memory and have the operating system automatically provide it to the SSH client during login on a remote cluster. You will | ||
then be able to | then be able to log in to our clusters without ever typing in any kind of passphrase. | ||
[[Category:Connecting]] | [[Category:Connecting]] | ||