Present your SSH key
Present your SSH key for an SSH connection
There are 2 main ways to present your SSH key when connecting via SSH-based methods:
ssh-agent, which stores the key ready for any subsequent connections you want to make (sometimes, this works for other applications too).| Method | pros/cons |
|---|---|
| 1. Specify the location of your SSH private key |
simple no admin permissions needed works for all platforms if you update your key to ECDSA |
| 2. Use your key stored in a local ssh-agent |
useful if you use many applications which use SSH (e.g. NX, VSCode) may need admin permissions for 1st-time agent setup careful editing of config file required in some cases |
This simply involves including the -i option in the SSH command to specify the location of your private key:
(You would type this command in a terminal window on your local computer i.e. desktop/laptop). This might be:
Note: the “standard” location to store your key is the .ssh directory within your home directory. Storing it elsewhere, particularly on Windows, can cause permissions problems.
ssh -i path_to/my_private_key user@remotehostWe’ll demonstrate the following methods:
cmd windowIn all cases, you should now check that the key is loaded and ready to use
ssh-add -l
521 SHA256:ZeddNKK5U3am1vyCaUCq4CgMRpvoyv+cJiviqz3zvfw ~/.ssh/id_ecdsa_jasmin (ECDSA)If you see output similar to the above, your key is now ready to be used in an SSH connection.
Sometimes the last part of this output shows your email address, but it is just a comment field, which can be ignored. The fact that it’s returned something which looks like a key “fingerprint”, shows that your key is loaded successfully into the agent.
If you don’t see your key listed in output similar to the above, please try again: perhaps you entered the wrong passphrase? But you will need to succeed in loading your key before you can use it to make an SSH connection.
Once the key is loaded, it can be used in an SSH connection, but whether this persists between different sessions may be dependent on your system configuration.
Sometimes the SSH agent or application will refuse to load the private key from the file if the file’s permissions are set too loosely: some SSH clients insist that you and only you (no other users or services on the same machine) can access the file.
To overcome this you have 3 options:
(Solves most Windows cases) Move the key files (id_edcsa_jasmin and id_edcsa_jasmin.pub: keep them together) to the .ssh directory which is inside your home directory. This is the “standard” location, helps to manage all
your keys in one place. Windows also applies different permissions rules to files in this location, so
this usually solves the problem
(Next simplest) Another option is to send just the contents of the file to the ssh-add command:
In your terminal where you give the ssh-add command, try this instead:
cat ~/.ssh/id_ecdsa_jasmin | ssh-add -id_ecdsa_jasmin with the path to and/or name of your private key file)
The cat command simply “streams” the contents of the file to standard output (stdout), while the trailing hyphen tells the ssh-add command to accept this streamed input (stdin) instead of from a file.
(Windows: while the cat command is available in PowerShell and MobaXterm terminal environments, it is not in the Windows cmd environment).
You should be asked for your passphrase in the normal way and can check that the key has loaded correctly with:
ssh-add -lor (perhaps for a more permanent solution), and/or if you are getting similar errors mentioning the ~/.ssh/config file, might need to change the permissions permanently on these file(s).
change the permisisons on the file