Difference between revisions of "SSH keys"

From SciNet Users Documentation
Jump to: navigation, search
(Multiple ssh private keys)
(Copying the Public Key to SciNet)
 
(3 intermediate revisions by 2 users not shown)
Line 5: Line 5:
 
In addition to using passwords to [http://en.wikipedia.org/wiki/Authentication authenticate] users, one can use cryptographically secure keys to guarantee that a login request is coming from a trusted account on a remote machine, and automatically allow such requests.  Done properly, this is as secure as requiring a password, but can be more convenient, and is necessary for some operations.   
 
In addition to using passwords to [http://en.wikipedia.org/wiki/Authentication authenticate] users, one can use cryptographically secure keys to guarantee that a login request is coming from a trusted account on a remote machine, and automatically allow such requests.  Done properly, this is as secure as requiring a password, but can be more convenient, and is necessary for some operations.   
  
You can read about setting up SSH keys for use on Niagara at [[SSH_keys|this page]].
+
==Using SSH keys==
  
==Using SSH keys==
 
 
===How SSH keys work===
 
===How SSH keys work===
  
 
SSH relies on [http://en.wikipedia.org/wiki/Public-key_cryptography public key cryptography] for its encryption.  These cryptosystems have a private key, which must be kept secret, and a public key, which may be disseminated freely.  In these systems, anyone may use the public key to encode a message; but only the owner of the private key can decode the message.  This can also be used to verify identities; if someone is claiming to be Alice, the owner of some private key, Bob can send Alice a message encoded with Alice's well-known public key.  If the person claiming to be Alice can then tell Bob what the message really was, then that person at the very least has access to Alice's private key.
 
SSH relies on [http://en.wikipedia.org/wiki/Public-key_cryptography public key cryptography] for its encryption.  These cryptosystems have a private key, which must be kept secret, and a public key, which may be disseminated freely.  In these systems, anyone may use the public key to encode a message; but only the owner of the private key can decode the message.  This can also be used to verify identities; if someone is claiming to be Alice, the owner of some private key, Bob can send Alice a message encoded with Alice's well-known public key.  If the person claiming to be Alice can then tell Bob what the message really was, then that person at the very least has access to Alice's private key.
  
To use keys for authentication, we:
+
To use keys for authentication, you need to:
* Generate a key pair (Private and Public)
+
 
* Copy the public keys to remote sites we wish to be able to login to, and mark it as an authorized key for that system
+
* Generate a key pair (private and public)
 +
* Copy the public key to a remote site, and add it to the list of authorized keys
 
* Ensure permissions are set properly
 
* Ensure permissions are set properly
* Test.
+
* Test to make sure it works
  
 
===Generating an SSH key pair===
 
===Generating an SSH key pair===
  
{|border="1"
+
The first stage is to create an SSH key pair. On Linux & MacOS, this is done using the <tt>ssh-keygen</tt> command:
|
 
Note: This describes creating ssh key pairs on '''your''' machine, not on SciNet. On SciNet, you already have key pairs generated, sitting in <tt>${HOME}/.ssh/</tt>, and modifying them is likely to cause problems.
 
|}
 
  
 +
ssh-keygen -t ed25519
  
The first stage is to create an SSH key pair.  On most systems, this is done using the command
+
If that doesn't work, try:
  
  ssh-keygen
+
  ssh-keygen -t rsa -b 4096
  
 
This will prompt you for two pieces of information: where to save the key, and a passphrase for the key.  The passphrase is like a password, but rather than letting you in to some particular account, it allows you to use the key you've generated to log into other systems.   
 
This will prompt you for two pieces of information: where to save the key, and a passphrase for the key.  The passphrase is like a password, but rather than letting you in to some particular account, it allows you to use the key you've generated to log into other systems.   
  
There are a series of possible options to <tt>ssh-keygen</tt> which allow increasingly cryptographically secure keys (by increasing the number of bits used in the key), or by choosing different encryption systems.  The defaults are fine, and we won't discuss other options here.
+
The default location to save the private key is in <tt>${HOME}/.ssh/id_<i>type</i></tt> (where <tt><i>type</i></tt> is <tt> ed25519</tt> for an Ed25519 key or <tt>rsa</tt> for an RSA key); unless you have some specific reason for placing it elsewhere, use this option. The public key will be <tt>id_<i>type</i>.pub</tt> in the same directory.
 
 
The default location to save the private key is in <tt>${HOME}/.ssh/id_rsa</tt> (for an RSA key); unless you have some specific reason for placing it elsewhere, use this option. The public key will be <tt>id_rsa.pub</tt> in the same directory.
 
  
 
Your passphrase can be any string, and of any length.  It is best not to make it the same as any of your passwords.
 
Your passphrase can be any string, and of any length.  It is best not to make it the same as any of your passwords.
Line 40: Line 36:
 
A sample session of generating a key would go like this:
 
A sample session of generating a key would go like this:
  
  $ ssh-keygen
+
  $ ssh-keygen -t ed25519
  Generating public/private rsa key pair.
+
  Generating public/private ed25519 key pair.
  Enter file in which to save the key (${HOME}/.ssh/id_rsa):  
+
  Enter file in which to save the key (/home/USERNAME/.ssh/id_ed25519):  
 
  Enter passphrase (empty for no passphrase):  
 
  Enter passphrase (empty for no passphrase):  
 
  Enter same passphrase again:  
 
  Enter same passphrase again:  
  Your identification has been saved in ${HOME}/.ssh/id_rsa.
+
  Your identification has been saved in /home/USERNAME/.ssh/id_ed25519.
  Your public key has been saved in ${HOME}/.ssh/id_rsa.pub.
+
  Your public key has been saved in /home/USERNAME/.ssh/id_ed25519.pub.
 
  The key fingerprint is:
 
  The key fingerprint is:
  79:8e:36:6a:78:7d:cf:80:94:90:92:0e:74:0b:f1:b7 USERNAME@YOURMACHINE
+
  SHA256:EajOndriRmLpl1qKg03FDhnc0EzRaApdBTygEbpQZrA USERNAME@HOSTNAME
 +
The key's randomart image is:
 +
+--[ED25519 256]--+
 +
|+=*X=*...        |
 +
|oB+ O o  .      |
 +
|E. * o  .        |
 +
|..+ +    .      |
 +
|.  B . .S        |
 +
|  = = o          |
 +
|.= o.+          |
 +
|o.oo* .          |
 +
|..o=..          |
 +
+----[SHA256]-----+
 +
 
  
 
====Don't Use Passphraseless Keys!====
 
====Don't Use Passphraseless Keys!====
Line 54: Line 63:
 
If you do not specify a passphrase, you will have a completely "exposed" private key.  '''This is a terrible idea.'''  If you then use this key for anything it means that anyone who sits down at your desk, or anyone who borrows or steals your laptop, can login to anywhere you use that key (good guesses could come from just looking at your history) without needing any password, and could do anything they wanted with your account or data.  Don't use passphraseless keys.
 
If you do not specify a passphrase, you will have a completely "exposed" private key.  '''This is a terrible idea.'''  If you then use this key for anything it means that anyone who sits down at your desk, or anyone who borrows or steals your laptop, can login to anywhere you use that key (good guesses could come from just looking at your history) without needing any password, and could do anything they wanted with your account or data.  Don't use passphraseless keys.
  
We should note that we do, in fact, have one necessary and reasonable exception here -- the keys used within SciNet itself.  The SciNet key used for within-scinet operations (you already have one in your account in <tt>~/.ssh/id_rsa</tt>) is passphraseless, for two good reasons.  One is that, once you are on one SciNet machine (like the login node), you already have read/write access to all your data; all the nodes mount the same file systems.  So there is little to be gained in protecting the SciNet nodes from each other.  The second is practical; ssh is used to login to compute nodes to start your compute jobs.  You obviously can't be asked to type in a passphrase every time one of your jobs starts; you may not be at your computer at that moment.  So passphraseless keys are ok ''within'' a controlled environment; but don't use them for remote access.
+
===Copying the Public Key to SciNet===
  
===Copying the Public Key to SciNet (and elsewhere)===
+
Now that you have this SSH "identity", you use the public (''not'' the private) key for access to remote machines.  The public key must added (as a single line) to your <tt>$HOME/.ssh/authorized_keys</tt> file on Niagara.
  
Now that you have this SSH "identity", you use the public (''not'' the private) key for access to remote machines.  The public key must be put as one line in the file <tt>/home/USERNAME/.ssh/authorized_keys</tt>.  Do not delete the lines already there, or you may end up with strange problems using SciNet machines.
+
Many Linux and MacOS systems that have ssh installed, have a utility for copying over public keys, called <tt>ssh-copy-id</tt>, which you would use as follows:
  
You can copy your new public key to the SciNet systems
+
$ ssh-copy-id SCINET_USERNAME@niagara.scinet.utoronto.ca
<pre>
+
 
scp /home/LOCAL_USERNAME/.ssh/id_rsa.pub SCINET_USERNAME@niagara.scinet.utoronto.ca:newkey
+
You will be asked for your password once. After running this command successfully, you can ssh into Niagara using the ssh key.
</pre>
+
 
Then login to SciNet and copy&paste the contents from <tt>~/newkey</tt> into <tt>~/.ssh/authorized_keys</tt>.
+
If the <tt>ssh-copy-id</tt> utility is not available on the computer from which you connect, the alternative is to first copy your public key to SciNet:
<pre>
+
 
cat ~/newkey >> ~/.ssh/authorized_keys
+
scp ~/.ssh/id_ed25519.pub SCINET_USERNAME@niagara.scinet.utoronto.ca:newkey
</pre>
+
 
 +
Then login to SciNet and append the contents of <tt>~/newkey</tt> to <tt>~/.ssh/authorized_keys</tt>:
 +
 
 +
$ ssh SCINET_USERNAME@niagara.scinet.utoronto.ca
 +
...
 +
$ cat ~/newkey >> ~/.ssh/authorized_keys
  
===<tt>.ssh</tt> Permissions===
+
===<tt>~/.ssh</tt> Directory Permissions===
  
Note that <tt>SSH</tt> is very fussy about file permissions; your <tt>~/.ssh</tt> directory must only be accessible by you, and your various key files must not be writable (or in some cases, readable) by anyone else.  Sometimes users accidentally reset file permissions while editing these files, and problems happen.  If you look at the <tt>~/.ssh</tt> directory itself, it should not be readable at all by anyone else:
+
Note that <tt>SSH</tt> is very fussy about file permissions; your <tt>~/.ssh</tt> directory must only be accessible by you, and your various key files must not be writable (or in some cases, readable) by anyone else.  Sometimes users accidentally reset file permissions while editing these files, and problems happen.  If you look at the <tt>~/.ssh</tt> directory itself, it should not be accessible by anyone else:
  
  ls -ld ~/.ssh
+
  $ ls -ld ~/.ssh
  drwx------ 2 USERNAME GROUPNAME 7 Aug  9 15:43 /home/USERNAME/.ssh
+
  drwx------ 2 USERNAME GROUPNAME 7 Aug  9 15:43 /home/.../.ssh
  
 
and <tt>authorized_keys</tt> must not be writable:
 
and <tt>authorized_keys</tt> must not be writable:
  
 
  $ ls -l ~/.ssh/authorized_keys  
 
  $ ls -l ~/.ssh/authorized_keys  
  -rw-r--r-- 1 USERNAME GROUPNAME 1213 May 29  2009 /home/USERNAME/.ssh/authorized_keys
+
  -rw------- 1 USERNAME GROUPNAME 1213 May 29  2009 /home/.../.ssh/authorized_keys
 +
 
 +
To fix your permissions, use the following command:
 +
 
 +
chmod -R go= ~/.ssh/
  
 
===Testing Your Key===
 
===Testing Your Key===
Line 86: Line 104:
  
 
  $ ssh USERNAME@niagara.scinet.utoronto.ca
 
  $ ssh USERNAME@niagara.scinet.utoronto.ca
  Enter passphrase for key '/home/USERNAME/.ssh/id_rsa':  
+
  Enter passphrase for key '/home/USERNAME/.ssh/id_ed25519':  
  Last login: Tue Aug 17 11:24:48 2010 from HOMEMACHINE
+
  Last login: Tue Aug 17 11:24:48 2010 from HOSTNAME
 
  [...]
 
  [...]
 
  nia-login07-$
 
  nia-login07-$
  
If this doesn't work, you should be able to login using your password, and investigate the problem. For example, if during a login session you get an message similar to the one below, just follow the instruction and delete the offending key on line 3 (you can use vi to jump to that line with ESC plus : plus 3). That only means that you may have logged in from your home computer to SciNet in the past, and that key is obsolete.
+
If this doesn't work, you should be able to login using your password, and investigate the problem.
<pre>
 
$ ssh USERNAME@niagara.scinet.utoronto.ca
 
 
 
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@**@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!    @
 
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@**@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
 
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
 
Someone could be eavesdropping on you right now (man-in-the-middle
 
attack)!
 
It is also possible that the RSA host key has just been changed.
 
The fingerprint for the RSA key sent by the remote host is
 
53:f9:60:71:a8:0b:5d:74:83:52:**fe:ea:1a:9e:cc:d3.
 
Please contact your system administrator.
 
Add correct host key in /home/<user>/.ssh/known_hosts to get rid of
 
this message.
 
Offending key in /home/<user>/.ssh/known_hosts:3
 
RSA host key for niagara.scinet.utoronto.ca
 
<http://niagara.scinet.utoronto.ca <http://niagara.scinet.utoronto.ca>> has
 
changed and you have requested
 
</pre>
 
  
* If you get the message below you may need to logout of your gnome session and log back in since the ssh-agent needs to be
+
If you get the message below you may need to logout of your gnome session and log back in since <tt>ssh-agent</tt> needs to be restarted with the new passphrase ssh key.
restarted with the new passphrase ssh key.
 
<pre>
 
$ ssh USERNAME@niagara.scinet.utoronto.ca
 
  
 +
$ ssh USERNAME@niagara.scinet.utoronto.ca
 +
Agent admitted failure to sign using the key.
  
Agent admitted failure to sign using the key.
+
===(Optional) Using <tt>ssh-agent</tt> to Remember Your Key===
</pre>
 
 
 
===(Optional) Using <tt>ssh-agent</tt> to Remember Your Passphrase===
 
  
 
But now you've just replaced having to type a password for login with having to type a passphrase for your key; what have you gained?   
 
But now you've just replaced having to type a password for login with having to type a passphrase for your key; what have you gained?   
  
It turns out that there's an automated way to manage ssh "identities", using the <tt>ssh-agent</tt> command, which should automatically be running on newer Linux or Mac&nbsp;OS&nbsp;X machines.  You can add keys to this agent for the duration of your login using the <tt>ssh-add</tt> command:
+
It turns out that there's an automated way to manage ssh "identities", using the <tt>ssh-agent</tt> command, which should automatically be running on newer Linux or macOS machines.  You can add keys to this agent for the duration of your login using the <tt>ssh-add</tt> command:
  
 
  $ ssh-add
 
  $ ssh-add
  Enter passphrase for /home/USERNAME/.ssh/id_rsa:  
+
  Enter passphrase for /home/USERNAME/.ssh/id_ed25519:  
  Identity added: /home/USERNAME/.ssh/id_rsa (/home/USERNAME/.ssh/id_rsa)
+
  Identity added: /home/USERNAME/.ssh/id_ed25519 (/home/USERNAME/.ssh/id_ed25519)
  
 
and then logins will not require the passphrase, as <tt>ssh-agent</tt> will provide access to the key.
 
and then logins will not require the passphrase, as <tt>ssh-agent</tt> will provide access to the key.
Line 137: Line 131:
  
  
=== Multiple ssh private keys ===
+
=== Multiple SSH keys ===
In quite a few situations its preferred to have ssh keys dedicated to each service, specific role or domain.
+
 
<pre>
+
It's recommended to have different ssh keys for each service, specific role, or domain. For example, to have separate keys for niagara and graham, first generate two new keys:
ssh-keygen -t rsa -f ~/.ssh/id_rsa.SciNet  -C "Key for SciNet"
 
ssh-keygen -t rsa -f ~/.ssh/id_rsa.SHARCNET -C "Key for SHARCNET"
 
ssh-keygen -t rsa -f ~/.ssh/id_rsa.DCS      -C "Key for Dept. Of Computer Science"
 
ssh-keygen -t rsa -f ~/.ssh/id_rsa.CITA    -C "Key for CITA"
 
</pre>
 
  
Use different file names for each key. Lets assume that there are 2 keys, ~/.ssh/id_rsa.SciNet and ~/.ssh/id_rsa.SHARCNET. The simple way of making sure each of the keys works all the time is to now create config file for ssh:
+
$ ssh-keygen -t ed25519 -f ~/.ssh/id_niagara  -C "Key for Niagara"
<pre>
+
...
touch ~/.ssh/config
+
$ ssh-keygen -t ed25519 -f ~/.ssh/id_graham  -C "Key for Graham"
chmod 600 ~/.ssh/config
+
...
echo "IdentityFile ~/.ssh/id_rsa.SciNet"   >> ~/.ssh/config
 
echo "IdentityFile ~/.ssh/id_rsa.SHARCNET" >> ~/.ssh/config
 
</pre>
 
  
This would make sure that both keys are always used whenever ssh makes a connection. However, ssh config lets you get down to a much finer level of control on keys and other per-connection setups. The recommendation is to use a key selection based on the Hostname. For example, a ~/.ssh/config that looks like this :
+
Make sure to use different file names for each key. Next, modify your <tt>~/.ssh/config</tt> file, adding <tt>IdentityFile</tt> directives:
  
 
<pre>
 
<pre>
Host SciNet
+
Host niagara
 +
  User myusername
 
   Hostname niagara.scinet.utoronto.ca
 
   Hostname niagara.scinet.utoronto.ca
   IdentityFile ~/.ssh/id_dsa.SciNet
+
   IdentityFile ~/.ssh/id_niagara
  User pinto
 
  
Host SHARCNET
+
Host graham
   Hostname sharcnet.ca
+
  User myusername
   IdentityFile ~/.ssh/id_rsa.SHARCNET
+
   Hostname graham.computecanada.ca
  User jchong
+
   IdentityFile ~/.ssh/id_graham
  Port 44787
 
 
</pre>
 
</pre>
  
And just login with the shortcut:
+
Now when you login with the shortcuts
<pre>
+
 
$ ssh SciNet
+
$ ssh niagara
</pre>
+
 
 +
or
 +
 
 +
$ ssh graham
 +
 
 +
different keys will be used.

Latest revision as of 14:09, 29 April 2020

SSH has an alternative to passwords to authenticate your login; you can generate a key file on a trusted machine and tell a remote machine to trust logins from a machine that presents that key. This can be both convenient and secure, and may be necessary for some tasks (such as connecting directly to compute nodes to use some visualization packages). Here we describe how to setup keys for logging into SciNet.

SSH Keys and SciNet

In addition to using passwords to authenticate users, one can use cryptographically secure keys to guarantee that a login request is coming from a trusted account on a remote machine, and automatically allow such requests. Done properly, this is as secure as requiring a password, but can be more convenient, and is necessary for some operations.

Using SSH keys

How SSH keys work

SSH relies on public key cryptography for its encryption. These cryptosystems have a private key, which must be kept secret, and a public key, which may be disseminated freely. In these systems, anyone may use the public key to encode a message; but only the owner of the private key can decode the message. This can also be used to verify identities; if someone is claiming to be Alice, the owner of some private key, Bob can send Alice a message encoded with Alice's well-known public key. If the person claiming to be Alice can then tell Bob what the message really was, then that person at the very least has access to Alice's private key.

To use keys for authentication, you need to:

  • Generate a key pair (private and public)
  • Copy the public key to a remote site, and add it to the list of authorized keys
  • Ensure permissions are set properly
  • Test to make sure it works

Generating an SSH key pair

The first stage is to create an SSH key pair. On Linux & MacOS, this is done using the ssh-keygen command:

ssh-keygen -t ed25519

If that doesn't work, try:

ssh-keygen -t rsa -b 4096

This will prompt you for two pieces of information: where to save the key, and a passphrase for the key. The passphrase is like a password, but rather than letting you in to some particular account, it allows you to use the key you've generated to log into other systems.

The default location to save the private key is in ${HOME}/.ssh/id_type (where type is ed25519 for an Ed25519 key or rsa for an RSA key); unless you have some specific reason for placing it elsewhere, use this option. The public key will be id_type.pub in the same directory.

Your passphrase can be any string, and of any length. It is best not to make it the same as any of your passwords.

A sample session of generating a key would go like this:

$ ssh-keygen -t ed25519
Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/USERNAME/.ssh/id_ed25519): 
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /home/USERNAME/.ssh/id_ed25519.
Your public key has been saved in /home/USERNAME/.ssh/id_ed25519.pub.
The key fingerprint is:
SHA256:EajOndriRmLpl1qKg03FDhnc0EzRaApdBTygEbpQZrA USERNAME@HOSTNAME
The key's randomart image is:
+--[ED25519 256]--+
|+=*X=*...        |
|oB+ O o  .       |
|E. * o  .        |
|..+ +    .       |
|.  B . .S        |
|  = = o          |
|.= o.+           |
|o.oo* .          |
|..o=..           |
+----[SHA256]-----+


Don't Use Passphraseless Keys!

If you do not specify a passphrase, you will have a completely "exposed" private key. This is a terrible idea. If you then use this key for anything it means that anyone who sits down at your desk, or anyone who borrows or steals your laptop, can login to anywhere you use that key (good guesses could come from just looking at your history) without needing any password, and could do anything they wanted with your account or data. Don't use passphraseless keys.

Copying the Public Key to SciNet

Now that you have this SSH "identity", you use the public (not the private) key for access to remote machines. The public key must added (as a single line) to your $HOME/.ssh/authorized_keys file on Niagara.

Many Linux and MacOS systems that have ssh installed, have a utility for copying over public keys, called ssh-copy-id, which you would use as follows:

$ ssh-copy-id SCINET_USERNAME@niagara.scinet.utoronto.ca

You will be asked for your password once. After running this command successfully, you can ssh into Niagara using the ssh key.

If the ssh-copy-id utility is not available on the computer from which you connect, the alternative is to first copy your public key to SciNet:

scp ~/.ssh/id_ed25519.pub SCINET_USERNAME@niagara.scinet.utoronto.ca:newkey

Then login to SciNet and append the contents of ~/newkey to ~/.ssh/authorized_keys:

$ ssh SCINET_USERNAME@niagara.scinet.utoronto.ca
...
$ cat ~/newkey >> ~/.ssh/authorized_keys

~/.ssh Directory Permissions

Note that SSH is very fussy about file permissions; your ~/.ssh directory must only be accessible by you, and your various key files must not be writable (or in some cases, readable) by anyone else. Sometimes users accidentally reset file permissions while editing these files, and problems happen. If you look at the ~/.ssh directory itself, it should not be accessible by anyone else:

$ ls -ld ~/.ssh
drwx------ 2 USERNAME GROUPNAME 7 Aug  9 15:43 /home/.../.ssh

and authorized_keys must not be writable:

$ ls -l ~/.ssh/authorized_keys 
-rw------- 1 USERNAME GROUPNAME 1213 May 29  2009 /home/.../.ssh/authorized_keys

To fix your permissions, use the following command:

chmod -R go= ~/.ssh/

Testing Your Key

Now you should be able to login to the remote system (say, SciNet):

$ ssh USERNAME@niagara.scinet.utoronto.ca
Enter passphrase for key '/home/USERNAME/.ssh/id_ed25519': 
Last login: Tue Aug 17 11:24:48 2010 from HOSTNAME
[...]
nia-login07-$

If this doesn't work, you should be able to login using your password, and investigate the problem.

If you get the message below you may need to logout of your gnome session and log back in since ssh-agent needs to be restarted with the new passphrase ssh key.

$ ssh USERNAME@niagara.scinet.utoronto.ca
Agent admitted failure to sign using the key.

(Optional) Using ssh-agent to Remember Your Key

But now you've just replaced having to type a password for login with having to type a passphrase for your key; what have you gained?

It turns out that there's an automated way to manage ssh "identities", using the ssh-agent command, which should automatically be running on newer Linux or macOS machines. You can add keys to this agent for the duration of your login using the ssh-add command:

$ ssh-add
Enter passphrase for /home/USERNAME/.ssh/id_ed25519: 
Identity added: /home/USERNAME/.ssh/id_ed25519 (/home/USERNAME/.ssh/id_ed25519)

and then logins will not require the passphrase, as ssh-agent will provide access to the key.

When you log out of your home computer, the ssh agent will close, and next time you log in, you will have to ssh-add your key. You can also set a timeout of (say) an hour by using ssh-add -t 3600. This minimizes the number of times you have to type your passphrase, while still maintaining some degree of key security.


Multiple SSH keys

It's recommended to have different ssh keys for each service, specific role, or domain. For example, to have separate keys for niagara and graham, first generate two new keys:

$ ssh-keygen -t ed25519 -f ~/.ssh/id_niagara  -C "Key for Niagara"
...
$ ssh-keygen -t ed25519 -f ~/.ssh/id_graham   -C "Key for Graham"
...

Make sure to use different file names for each key. Next, modify your ~/.ssh/config file, adding IdentityFile directives:

Host niagara
  User myusername
  Hostname niagara.scinet.utoronto.ca
  IdentityFile ~/.ssh/id_niagara

Host graham
  User myusername
  Hostname graham.computecanada.ca
  IdentityFile ~/.ssh/id_graham

Now when you login with the shortcuts

$ ssh niagara

or

$ ssh graham

different keys will be used.