0

So far on Windows 10 I used mainly the PuTTy bundle (PuTTygen, Pageant and PuTTy, etc) to SSH into remote Linux machines.

I use Pageant as a private key holder to hold to private key (and possible passphrase) in memory as long as the PC isn't rebooted.

I'd like to use WSLs OpenSSH as client more often as with this command:

ssh USER@IP -vvv -L 22:localhost:22 # Or USER@DOMAIN.TLD;

Yet I didn't find a Pageant like behavior on WSL OpenSSH:

Holding the SSH key in memory for all possible WSL shells (even in shell termination) until the machine itself is rebooted from whatever reason

How could I have a Pageant-like behavior in WSL OpenSSH?

  • ssh-agent in linux. But beware WSL is not your linux kernel – Rui F Ribeiro Mar 3 at 11:15
  • For the 99% of users here, that don't know what pageant is: Pageant is a part of putty (ssh for microsoft's windows). It is the equivalent of ssh-agent, and ssh-add (but graphical). It also puts an icon in the tray. – ctrl-alt-delor Mar 3 at 15:34
  • @RuiFRibeiro, but WSL is their Linux (kernel) replacement (like an understudy in acting, it is used when the better one is not available). – ctrl-alt-delor Mar 4 at 20:02
1

You need ssh-agent, and ssh-add.

ssh-agent may be already started (it is on Debian), when you login. To test it, run ssh-add -l. You should see no keys, if the agent is working. If it is not running then you should get an error-message, saying something like can not connect to agent.

To add the key. If is is a default name, then you just have to do ssh-add, else you do ssh-add «path/to/your/key/key-name», then you are prompted for the pass-phrase.

0

On U*nix ssh-agent would be run ideally very early at session login. That's usually what is done on a GUI (X11 etc.) login. Beside deamonizing, this command leaves conveniently as output shell commands which export variables needed to contact the newly spawned daemon, ready for shell evaluation:

$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-TO9z33k5zo6t/agent.25671; export SSH_AUTH_SOCK;
SSH_AGENT_PID=25673; export SSH_AGENT_PID;
echo Agent pid 25673;

run again as intended from a posix sh shell:

$ eval $(ssh-agent)
Agent pid 25965
$ printenv SSH_AUTH_SOCK SSH_AGENT_PID
/tmp/ssh-XgTqsra2Pok2/agent.25964
25965

If this is run by a common ancestor process during login setup, all further processes will inherit these variables, making the running ssh-agent available for use anywhere in the session.

Also to be noted that (part of) those variables can be inherited via a remote ssh using the agent forwarding option (-A), without then requiring a local ssh-agent.


Now, for the case where the same user wants to reuse ssh-agent, but from an other unrelated access (other terminal, session, be it remote or local etc.) which didn't inherit the two previous exported variables because there's no mechanism in place. That user can just retrieve their value from wherever needed: an other terminal running a shell having them already exported, some file at a fixed position created by a script designed to save those variables (or better the commands above before evaluation) for this specific purpose, etc.) and export them again:

SSH_AUTH_SOCK=/tmp/ssh-XgTqsra2Pok2/agent.25964; export SSH_AUTH_SOCK;
SSH_AGENT_PID=25965; export SSH_AGENT_PID;

So if on some terminal one ran instead of eval $(ssh-agent) something like this:

$ mkdir -m 700 -p ~/.ssh-agent-info
$ ssh-agent > ~/.ssh-agent-info/variables
$ . ~/.ssh-agent-info/variables
Agent pid 25965

then started adding some keys:

$ ssh-add /tmp/demokey
Enter passphrase for /tmp/demokey: 
Identity added: /tmp/demokey
$ ssh-add -l
256 SHA256:Ayd3PCiSkVVV09IqwEXz2Fn3nuXF70FDPMlNtZiuTtY user@host (ED25519)

and that user on others terminals on the same system sourced again the same variables, should get the expected result:

$ . ~/.ssh-agent-info/variables
Agent pid 25965
$ ssh-add -l
256 SHA256:Ayd3PCiSkVVV09IqwEXz2Fn3nuXF70FDPMlNtZiuTtY user@host (ED25519)

Meaning that there's no need to give anymore the passphrase until ssh-agent is killed or asked to forget its keys.

This should be working about the same on any platform with a port of openssh and ssh-agent, so I believe the same should work on WSL.

Ideally you should put those commands in a shell startup script (like .profile), crafted in such a way that it will first detect if (the correct) ssh-agent is already running before attempting to spawn a new one, else you will leak processes and will have to give again a passphrase.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.