Making ssh better

If you use ssh to work on remote systems, you may find yourself doing a lot of repetitive typing and password-entering. Fortunately there are some easy steps you can take to avoid these problems and make ssh really, really easy to use. Not that it’s too difficult in the first place—but if you use it often enough, this is worth it.

(Thanks to Matt Woodruff for figuring this out!)

1. Set up a ~/.ssh/config file

A normal ssh login would look something like this:


If you’re like me, at some point you will lose track of your username, host address, or both. You can set up shortcuts for these addresses by creating a file ~/.ssh/config that looks something like the following:

Host foo
  User my_name
Host bar
  User my_name

Now instead of typing ssh, you can just type ssh foo to log in. This is especially useful with commands other than ssh that use remote addresses. For example with this config file set up, you can do things like:

scp ./local/path/to/file foo:/remote/path/to/file

You might also consider adding GitHub to your ~/.ssh/config file like so:

Host gh
  User git

Usually you would run, for example, git pull But now you can just do git pull gh:/my/repository.git. Pretty cool. One last thing to note, make sure the permissions on ~/.ssh/config are set to 700 (only you have r/w/x permission). Some systems will refuse to use the file otherwise.

2. Use ssh keys to log in

There are a few reasons to switch from password login to key-based login. One is security, since someone would need your private key file to log in, which (should) only exist on your computer. The second is to avoid typing passwords all the time, which you’ll see in the next step. To create a public/private key pair in your ~/.ssh/ directory, run:

ssh-keygen -t rsa

By default this will create files id_rsa (your private key) and (public key). Never, ever copy your private key anywhere else. If you want to create these files with a name other than the default, use the -f flag to specify a name. When you create your key, you will be prompted to enter a password. If you leave it blank, there will be no password for the key, but it’s a good idea to stick a password on it anyway.

Now that your key pair exists, you can copy your public key to any remote systems that you want to access:

ssh-copy-id -i ~/.ssh/ remote_user@remote_host

The public key will be appended to the file ~/.ssh/authorized_keys on the remote host. Note that you can append multiple public keys to this same file. For example, you may have one key for your home computer, one for your work computer, etc.

If you want, you can also set up ssh keys on GitHub. Go to Account Settings -> SSH Keys and click “Add SSH Key”. Choose a name for the key, and copy the contents of into the box. (You can run cat to view the contents of the file). Once you start using key-based login for GitHub, it will stop letting you log in with a password, so you may want to wait until you have ssh keys set up on all of your systems before making this switch.

3. Run ssh-agent for password-less login

So we have a key-based login set up, but we still need to type the key password every time we use ssh. This can be very annoying if you’re using a lot of git commands, for example. One way to avoid this is to enter the password once at the beginning of your session, and have ssh-agent manage the password for you:

ssh-agent && ssh-add

You will be prompted to enter your password once when you run this command. But, in all subsequent ssh commands, you will not need to enter your password at all. Note if you’re using screen to spawn multiple shell instances, you will have to run ssh-agent in all screens separately. Personally, I have this command aliased like so in my ~/.bashrc file:

alias key='eval `ssh-agent` && ssh-add'

That way I can just type “key” once, enter my password, and have ssh-agent manage my password for the rest of the session.

You may not need to do these things if you’re an infrequent ssh user, but at some point, the time saved with this setup will be well worth it.

4 thoughts on “Making ssh better

  1. Pingback: Water Programming Blog Guide (Part I) – Water Programming: A Collaborative Research Blog

  2. Pingback: Enhance your (Windows) remote terminal experience with MobaXterm – Water Programming: A Collaborative Research Blog

  3. Pingback: Guide to Your First Year in the Reed Research Group – Water Programming: A Collaborative Research Blog

  4. Pingback: More Terminal Schooling – Water Programming: A Collaborative Research Blog

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s