Simplify your SSH workflow

For system and network administrators or other users who frequently deal with sessions on multiple machines, SSH ends up being one of the most oft-used Unix tools. SSH usually works so well that until you use it for something slightly more complex than starting a terminal session on a remote machine, you tend to use it fairly automatically. However, the ~/.ssh/config file bears mentioning for a few ways it can make using the ssh a client a little easier.

Screen Shot 2014-09-23 at 2.39.53 PM

Let’s take a common question for all of us. Are you tired of constantly searching for the username and/or password of your remote server? If your answer to these questions is yes then read on. You’ll definitely find it interesting.

Getting started with SSH config

The first thing you need to do is check if you have your private and public keys set up. If you don’t have them set up or you’re not sure just write the following command :

It will automatically generate private and public keys for you. The next step is to use command ssh-copy-id.

If you find yourself using mac machine you have to first install ssh-copy-id or you will get “Command not found” error.

Or you could use brew and install it like this:

You can use ssh-copy-id like this:

This command will copy your public key to the remote server and once you try to connect via ssh command next time it won’t ask you for a password.

Now you can connect to your server without a password and that’s great. But it can be a drag to remember username or port or even domain name so let’s dumb it down a little bit more.

First step is to position yourself to .ssh directory


If you were to type in the “ls” command you’d see that directory is populated with generated private and public keys. To move to the next step we have to create a config file. You can do it with vim, nano or something else. There are numerous ways to do it. Use whichever editor you’re most comfortable with.

Fill the config file with following lines:


I propose you fill out the first line with some easy to remember name. In this example I’ve named it myServer but that can be anything you want. HostName can be written as yourserver.com or you can put whole IP address of the server. IdentifyFile part is used for defining where your generated key is located.

There are also other configuration options. For example if your server’s secure port isn’t default 22 but some else you can just add “Port XXXX” to your config file.

After you’ve made all the changes now you can simply write:


And that’s it! You should be logged in now if there is no errors in your config.

There are even more customisation that you could do to your SSH config file.

SSH proxies

If you have an SSH server that’s only accessible to you via an SSH session on an intermediate machine, which is a very common situation when dealing with remote networks using private RFC1918 addresses through network address translation, you can automate that in .ssh/config too. Say you can’t reach the hostnathost directly, but you can reach some other SSH server on the same private subnet that is publically accessible, publichost.example.com:

This will allow you to just type:

Plain-text Password

You’ll probably want to add a Password field and specify that password that should be used in order to connect to that server. No, you can’t add a plain-text password. And that’s not recommended to do either.

Understanding the SSH config entries

  • Host : Defines for which host or hosts the configuration section applies. The section ends with a new Host section or the end of the file. A single * as a pattern can be used to provide global defaults for all hosts.
  • HostName : Specifies the real host name to log into. Numeric IP addresses are also permitted.
  • User : Defines the username for the SSH connection.
  • IdentityFile : Specifies a file from which the user’s DSA, ECDSA or DSA authentication identity is read. The default is ~/.ssh/identity for protocol version 1, and ~/.ssh/id_dsa, ~/.ssh/id_ecdsa and ~/.ssh/id_rsa for protocol version 2.
    ProxyCommand : Specifies the command to use to connect to the server. The command string extends to the end of the line, and is executed with the user’s shell. In the command string, any occurrence of %h will be substituted by the host name to connect, %p by the port, and %r by the remote user name. The command can be basically anything, and should read from its standard input and write to its standard output. This directive is useful in conjunction with nc and its proxy support. For example, the following directive would connect via an HTTP proxy at 192.1.0.253:
  • LocalForward : Specifies that a TCP port on the local machine be forwarded over the secure channel to the specified host and port from the remote machine. The first argument must be [bind_address:]port and the second argument must be host:hostport.
  • Port : Specifies the port number to connect on the remote host.
  • Protocol : Specifies the protocol versions ssh should support in order of preference. The possible values are 1 and 2.
  • ServerAliveInterval : Sets a timeout interval in seconds after which if no data has been received from the server, ssh will send a message through the encrypted channel to request a response from the server.
  • ServerAliveCountMax : Sets the number of server alive messages which may be sent without ssh receiving any messages back from the server. If this threshold is reached while server alive messages are being sent, ssh will disconnect from the server, terminating the session.

So there you have it. This configuration might take you a while to complete the first time but the benefits it adds are enormous. No more searching where is password for serverA or username for serverB and so on.