Skip to content


Created: 2016-02-29 11:15:20 -0800 Modified: 2023-12-07 08:48:14 -0800

If you’re sick of doing “ssh-agent bash” followed by “ssh-add” (which you need to redo every time you start a new shell), then you should use ~/.ssh/config.

In short, you just need to do these steps:

  • vim ~/.ssh/config
  • Type this in



User <your user account>

IdentityFile ~/.ssh/path_to_priv_key


  • “Host” is what you would use to SSH. So, for example, if you set “Host chickens” at the top, then you could log into bitbucket by typing “ssh chickens”. If HostName isn’t set, then “Host” is the address of the remote. It accepts patterns, so if you want to use a “localvms” keypair to log in to 192.168 addresses, then type “192.168.._“.
  • You don’t have to specify a username if you’ll be logging in with the same one that you’re already using.
  • Even on Windows, if you modify /.ssh/config, you’re allowed to use "" to represent %userprofile%.

Note: on macOS, to not have to type passwords, follow these instructions.

Starting manually:

eval ”$(ssh-agent -s)“

ssh-add ~/.ssh/id_rsa

Starting from bash_profile:

function ensure_ssh_agent_running() {
agent_load_env () { test -f "$env" && . "$env" >| /dev/null ; }
agent_start () {
(umask 077; ssh-agent >| "$env")
. "$env" >| /dev/null ; }
# agent_run_state: 0=agent running w/ key; 1=agent w/o key; 2= agent not running
agent_run_state=$(ssh-add -l >| /dev/null 2>&1; echo $?)
if [ ! "$SSH_AUTH_SOCK" ] || [ $agent_run_state = 2 ]; then
elif [ "$SSH_AUTH_SOCK" ] && [ $agent_run_state = 1 ]; then
unset env

Using multiple instances of the same HostName in ~/.ssh/config

Section titled Using multiple instances of the same HostName in ~/.ssh/config

Note: if you’re doing this for GitHub, consider looking at [[gh#Using gh as a credential manager]].

User onaimada
IdentityFile ~/.ssh/bitbucket_botlandinfra_deploy_key
Host test
User onaimada
IdentityFile ~/.ssh/bitbucket_botlandacctsrv_deploy_key

Then, when you’re cloning a repo, you can type out this command:

git clone git@test:onaimada/botlandrestserver.git

After you’ve cloned the repo, git pull should work normally. If you ever change the name of test, make sure to reflect that in your .git/config file.

To test this setup, you can use ssh -T, e.g.:

ssh -T

Hi AdamLearns! You’ve successfully authenticated, but GitHub does not provide shell access.

ssh -T

Hi Adam13531! You’ve successfully authenticated, but GitHub does not provide shell access.

Make sure that your remote uses the host that you have set, e.g.

git remote -v

origin (fetch)

If either identity is wrong on macOS, then run these commands (and possibly add them to your shell’s start-up script):

  • ssh-add --apple-use-keychain ~/.ssh/github_adam13531
  • ssh-add --apple-use-keychain ~/.ssh/github_adamlearns

When working with pull requests, the pushremote will need to be changed (e.g. here, I’m changing git config branch.smu-readme.pushremote

I kept getting “No such file or directory”. Turns out it was a quotation marks issue.

I had:

ssh -i %keyLocation% admin@%overseerIp% ‘/usr/bin/mysqldump -u root -h —password=%dbPassword% botland ^> %dumpFileName%‘

I needed it to be:

ssh -i %keyLocation% admin@%overseerIp% “/usr/bin/mysqldump -u root -h —password=%dbPassword% botland > %dumpFileName%“

(notice: the ”>” is no longer escaped)

ssh: connect to host <IP_ADDRESS_REMOVED> port 22: Connection timed out

Section titled ssh: connect to host &lt;IP_ADDRESS_REMOVED&gt; port 22: Connection timed out

This is just a generic SSH message that usually indicates that the IP address is wrong or the host is offline, but this happened to me when trying to SSH from a Windows machine to my Raspberry Pi when my Pi was definitely online (because I could access the service it provided from outside of my home network) and the IP address that I was using internally was the same one that my router reported.

I tried a bunch of stuff with pinging and nmap and eventually figured out that it was a Windows Firewall problem from my PC. I only figured this out after ruling out a million other possibilities. Turning the firewall off and on again seemingly fixed everything (this is because the firewall is stateful, so restarting it cleared the state, although I never figured out how the rule got set in the first place).