Managing multiple SSH agents
This describes a method for maintaining a separate ssh-agent to hold your ssh key for connecting to Toolforge/CloudVPS.
You use an ssh-agent to connect to your personal or company systems. You want to connect to Toolforge/CloudVPS using an agent and you created a separate ssh key to connect to Toolforge/CloudVPS, but you don't want to forward your personal key to Toolforge/CloudVPS systems. If you just add both keys to your existing agent, they both get forwarded to Toolforge/CloudVPS. It's a pain to constantly remove your personal key from your agent each time you want to connect to Toolforge/CloudVPS. Additionally, you might be connected to both your personal system and Toolforge/CloudVPS simultaneously, so just removing the key is insufficent; you must run a separate ssh-agent. You don't want to run one agent per connection because then you have to type your passphrase on every connection (and you have a nice long secure passphrase on your key).
This page describes a method for getting your shell to maintain two agents, your primary agent and your Toolforge/CloudVPS agent. When you connect to Toolforge/CloudVPS you connect to the existing Toolforge/CloudVPS agent (or create one if it doesn't exist) and the rest of the time you use your default agent.
OS X solution
Using multiple agents via launchd (better)
This has been tested on Mac OS X Catalina. It should work on older releases, please update this text if it works with later versions of OSX.
You can start multiple ssh-agents through launchd user LaunchAgents.
To make this work write the following plist to
<?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"> <dict> <key>Label</key> <string>org.wmflabs.ssh-agent</string> <key>ProgramArguments</key> <array> <string>/usr/bin/ssh-agent</string> <string>-l</string> </array> <key>ServiceIPC</key> <true/> <key>Sockets</key> <dict> <key>Listeners</key> <dict> <key>SockPathName</key> <string>/private/tmp/.ssh-agent-cloud</string> </dict> </dict> <key>RunAtLoad</key><true/> <key>EnableTransactions</key> <true/> </dict> </plist>
Then load the agent:
launchctl load ~/Library/LaunchAgents/org.wmflabs.ssh-agent.plist
and if you want, start it
launchctl start org.wmflabs.ssh-agent.
This will start an ssh agent instance every time you login that will be reachable at
Repeat the process for every domain you're connecting to.
You can then proceed as suggested in the Linux section below in order to configure ssh. Please note that openssh 7.3 is only available via homebrew at the time of writing. However, do NOT use homebrew's ssh-agent in the launch agent as it's not interacting well with launchd.
Run one agent per terminal
The default terminal application can be modified in how it runs to have every tab run its own ssh-agent.
- Open Terminal
- Open Terminal preferences
- Select the terminal style and settings on the left for the one in use (usually already defaulted to this choice)
- Select the 'Shell' Tab.
- Check the box to run the command on startup, and populate the command eval `ssh-agent` in the field.
- Also ensure 'Run in Shell' is checked.
- New tabs you open will now use this setting.
Using multiple agents via systemd
This requires the use of a Linux distribution using systemd as the init system which is the norm these days.
You can start multiple ssh-agents through systemd user units. The following unit would e.g. connect to Toolforge/CloudVPS, copy it to /etc/systemd/user/ssh-cloud.service (and similar to wherever you else want to connect):
[Unit] Description=SSH authentication agent for Toolforge/CloudVPS Before=default.target [Service] Type=forking Environment=SSH_AUTH_SOCK=%t/ssh-cloud.socket ExecStart=/usr/bin/ssh-agent -a $SSH_AUTH_SOCK [Install] WantedBy=default.target
Then run the following command as your regular user (and similar for the other agent(s)):
systemctl --user enable ssh-cloud
This will create the agent socket ssh-cloud.socket inside the $XDG_RUNTIME_DIR directory (which is automatically created and usually refers to /run/user/1000/, so the effective SSH agent socket would be /run/user/1000/ssh-cloud.socket).
Start the agent as follows to check if the systemd user unit works properly. There is no need to do this afterwards, later on the unit will be started during your first login.
systemctl --user start ssh-cloud.service
Finally whenever you want to connect to either Toolforge/CloudVPS or production via SSH, you need to point your SSH client to the respective agent socket:
If you're using openssh 7.3 (available in Debian unstable since 7th August 2016), this is really simple: You can use the new IdentityAgent directive, so wherever you configure the IdentityFile, simply add the respective SSH agent socket created by the systemd user units above. Here's an example for configuring access for Toolforge/CloudVPS:
Host *.wmflabs gerrit.wikimedia.org *.wmflabs.org User foo IdentityFile /home/foo/.ssh/id_cloud IdentityAgent /run/user/1000/ssh-cloud.socket IdentitiesOnly yes ForwardAgent no # once identity is used for the first time, add it to the agent AddKeysToAgent yes
If you don't have openssh 7.3 yet, you need to set the set the environment variable SSH_AUTH_SOCK to the respective socket before connecting, e.g.