Ssh Agent Password



  1. If the key is not registered with ssh-agent, it must be specified on the command line to login: ssh -i.idrsa DefaultAccount@host If the private key is registered with ssh-agent, then you only need to specify DefaultAccount@host: ssh DefaultAccount@host The first time you connect you see a.
  2. Furthermore SSH key authentication can be more convenient than the more traditional password authentication. When used with a program known as an SSH agent, SSH keys can allow you to connect to a server, or multiple servers, without having to remember or enter your password for each system.

Using an ssh-agent, or how to type your ssh password once, safely. This will create two files: a public key (normally.pub), and a private key. The private key is. Your agent friend. So you have read this much of the article, and still we have not solved the problem of having to.

I run the dev channel of ChromeOS. This crashes occasionally. While my chrometabs are generally recovered, it also resets the crostini containers. Everytime this happens, I’ve to launch 1Password (the android app), unlock it,search for my SSH key, copy the password and finally paste it in the terminal.This was starting to get old.

Ssh agent forwarding password

A couple of days ago I spent about an hour short circuiting this. I’ve setthings up so that ssh-agent directly asks for my 1Password master password,uses it to unlock the vault, grab the SSH key password and add the identity tossh-agent! Read on to know how it works!

I want to call out that this kind of tinkering is only possiblebecause unix tools are customizable and 1Password publishes the full details ofits opvault file format. Keep supporting these kind of companies!

We need a couple of things for this setup to work.

  1. Some way to convince ssh-agent to use this mechanism instead of the defaultpassword prompt.
  2. Some way to get the SSH key password from 1Password, given the masterpassword.

Customizing ssh-add

While part 2 is the slightly harder part, it is worth spending a few minutesfiguring out if 1 is even possible. I certainly am not feeling up to actuallyhacking on the SSH code. So let’s look at the ssh-add man page:

OK, seems like this is possible. It isn’t clear yet how the entered password isread from ssh-askpass. Moremansplaining:

Very unix-y. The program just needs to write the password to stdout. OK. Let’scome back to this once we have a script doing exactly that.

Extracting passwords from 1Password

The opvault file format is open and well documented. Thismeans we don’t have to figure out some complicated IPC schemes orreverse-engineering. There are already libraries out there that support parsingthese files. While writing one in Rust would be the cool thing to do, I’mtrying not to fall too deep in the XKCD trap. I picked theopvault python package. I did a quick read of the code to make sure thiswasn’t secretly uploading all my passwords to the Internet. I also usedvirtualenv and some extra customizations to not pollute my system python, butI’m going to elide that. The code presented here assumes your system python hasopvault installed. Remember, the script also needs to be executable.

This is a fairly simple script. It hard-codes the location to my vault and thetitle under which my key is stored in 1Password (one less thing to worry aboutpassing around on the command line). It uses the getpass module to retrievemy password in the unix-style, without echoing it on screen. We load the vault,load all the items and retrieve the details. Then we print the SSH keypassword!

Plugging this into ssh-add

This may vary slightly based on how you’ve set up ssh-add to execute atstartup. I use zprezto, and I’ve the ssh module enabled. Ielected to put the customization in my .zshrc, right before initializingzprezto.

I’m not entirely happy with this, but it will do for now. First, it changesthese variables at the zprezto level, instead of just at the module level. Thismeans other modules and zsh setup can be influenced by this. However, puttingthese links right before loading ssh did not seem to work and I don’t careenough. Second, I’m not resetting the variables properly, they now end up asempty strings instead of being unset if they were not set before. Again, Idon’t care.

That’s it! Use ssh-add -d to disassociate the existing identity, then start ashell to see if this works, as I did several times while figuring this out.

A note on the vault storage.

Jenkins Ssh Agent Password

This deals only with local vaults. If you use the 1Password web service, I’d behappy to know how you would hook that up. If you use Dropbox to sync your1Password vaults, the easiest way to get this to work is by installing Dropboxon your linux machine and just syncing the files. I thought this was a lot ofresource use just to access this SSH key. In particular, the SSH key passwordis never going to change, so the syncing aspect is not very useful. Instead, Ijust downloaded a current version of the opvault file (which is actually adirectory). I also pruned the contents to leave only the profile and the bandwith the ssh key on-disk, as those are the only pieces required.

Linux Start Ssh Agent

Many webservices generate ssh keys to access their service. With the amount of services the number of SSH keys grows. To avoid dealing with the keys in the command line and the ssh_config(5), you can simply add the ssh-key to the local ssh-agent(1) to manage them.

The ssh-agent(1) is a program used to hold ssh private keys used to authenticate to remote systems via ssh public key authentication. ssh clients use it to authenticate to the remote via the keys in the ssh-agent.

When the ssh-agent is started, the output does not show output meant to be read by humans

The output are shell commands (-s for bash shell) that should be executed. To do this in one command, the eval command can be used.

When the ssh-agent is started, it prints out the environment variables that need to be set. These environment variables are required so the client programs, like ssh, know how to connect to the ssh-agent. To directly set these environment variables, the output of the ssh-agent is passed as parameter to the eval command. The “eval” command will execute the parameters passed to it as if they were directly entered into the shell. In this case, the output of the ssh-agent is directly executed.

With the ssh-agent now running, there are not yet any keys added to the agent. Adding an ssh-key to the ssh-agent is done via the ssh-add(1) command. As a parameter, ssh-add takes the filename of the ssh private-key. If the default location and file name is used for the key (~/.ssh/id_rsa), the filename parameter can be omitted.

When the private key is secured by a password (which is suggested), ssh-add will ask for it to add the key to the agent.

With the ssh-agent running and the key added to the agent, any ssh session can now be authenticated with that key. Additional ssh-keys, if needed, can be added using ssh-add as described above. Instead of entering the ssh-key password each time, the agent manages the keys and only asks once for the password of the keys.

To list the ssh-keys currently available in the ssh-agent, the -l option can be used. The fingerprints of the keys in the agent are shown, like in the example below.

With the -L option, the keys in the ssh-agent can be listed as well. While the -l option shows the fingerprint for each key, the -L option shows the public key part of each key. This can be especially helpful if the ssh-key should be added to a remote server for authentication. The output lines can directly be used to add the key to the authorized_keys file.

Ssh Agent Password

(The above output has been shortened as the public key sections are quite long and really relevant to this example).

To remove a key from the ssh-agent, the -d option can be used as the example below shows. The parameter given is the file name as it is shown in the list of keys. This identifies the key to be removed.

Removing all private keys from the ssh-agent can be achieved with the -D option as shown below. In this case it is not necessary to add identifiers for the individual keys.

Keeping the private keys secure is important. It is suggested that the ssh-agent is terminated or locked when it is not needed anymore. To terminate the ssh-agent the following command can be executed.

Ssh agent store password

This command – like starting the agent – uses the eval command. In this case not to set environment variables but to unset them as the agent has been stopped.

Automate the ssh-agent start

With all the above in mind, it seems to be a lot of commands to remember and enter every time. There has to be a way to automate at least some of this, and there is.

The ssh-agent should be started when a Shell session is started and the default key should be added to the ssh-agent, but with this approach, every shell opened and every session started gets its own ssh-agent and the password is asked for adding the key to the ssh-agent. To share the ssh-agent between the sessions, the following can be added to the “~/.bashrc”.

The command in the if statement is constructed in a way to list all ssh-agents running in the context of the user shells/session’s user. If the user has no ssh-agent running yet, the ssh-agent is started. For the purpose of reusing the ssh-agent for any parallel sessions, the output of the ssh-agent is not directly passed to the “eval” command but stored into a file. This file is then loaded in the second step. As final step the keys are loaded via ssh-add. The ssh-add command will cause the session to immediately ask for the ssh-key passphrases.

If the user already has an ssh-agent running (from a parallel session/shell) the else part is executed which simply loads the environment variables needed. Those where stored in a file when the agent was started.

This way, the agent is started with the first login and used for every further session started.

Automate the ssh-agent termination

To secure the ssh-keys after all sessions for a user are ended, the ssh-agent should be stopped when the user exits the sessions.

Setup Ssh Agent

bash(1) supports a script to be executed on logout from a session. The file that is executed on logout is called ~/.bash_logout.

The same way as the section in the .bashrc, the script in the .bash_logout needs to be aware of the logged in sessions as the ssh-agent is shared between the sessions.

The script above placed in the .bash_logout file will be executed when the user will logout from a session. The command in the if statement will list all logged in sessions (who(1)) and reduces them to only sessions of the current user (grep). The “wc -l” as last part of this command will count the resulting lines which makes it easier to compare. The comparison checks if there are less or equal to one session (at this point, the current session is still active so “1” session active will be considered the last session. When this condition is met, all ssh-keys are removed from (ssh-add -D) the and the agent is stopped (ssh-agent -s -k). To cleanup properly, the file where the ssh-agent output was stored is deleted as well.

Terminate ssh-agent when no logout was performed

The ssh session might be disrupted by a timeout or when the network connection drops. In such cases the shell does not receive the logout command and the ssh-agent is not terminated by the script in the .bash_logout script. To ensure that the ssh-agent is ended and the ssh-keys are secure, the following can be done.

Create a script which can be executed as a cron job. This script looks similar to the script in the .bash_logout. It differs only by the amount of sessions that should be active before it terminates the ssh-agent. The cron script starts its action when no session is active any more for that user.

The script (in this example “~/.cron_ssh-agent”) can now be added to the cron jobs. To do so, open the crontab in edit mode (-e).

The cron job can now be added. Depending on the configuration of your system, the crontab is opened in vim or whatever editor is configured for it. Add the following line to execute the script every 5 minutes.

With the .bash_logout script in place and the cron job configured, the ssh-agent will be immediately stopped when you logout. In case of a connection drop, the ssh-agent will be automatically stopped at the latest 5 minutes after the connection was lost.

Read more of my posts on my blog at https://blog.tinned-software.net/.

Related posts:





Comments are closed.