Latest: Genstatic, my first sip of coffee

Content with Style

Web Technique

4 ssh config tips for faster remote working

by Matthias Willerich on April 17 2009, 12:00

With the vast majority of web developers deploying their own code, and ssh playing a central role in the toolbox, I felt that tweaking this part of my work saves me some time, and if not, definitely some frustration over mistyping passwords and host names.

So, for myself as much as everyone out there, here is my collected useful knowledge that has helped me ease the pain of remote work.

1. Execute commands remotely as one-liners

This is what some deployment tools such as vlad use, but for a quick look at something, it cuts out valuable seconds you could look at web comics instead.

Let's try a simple example:

matthias:~ matthias$ ssh ls -l's password: 
total 804
lrwxrwxrwx   1 remoteuser remoteuser      31 Nov 10  2007 access-logs -> /links/to/my/access-logs
drwxr-xr-x   2 remoteuser remoteuser    2048 Apr  6  2008 cgi-bin
-rw-r--r--   1 remoteuser remoteuser  808417 Jul 17  2007 error_log_dump
drwxr-x---   3 remoteuser mail     2048 Oct  1  2007 etc
drwxrwx---   7 remoteuser remoteuser    2048 Apr  4 02:33 mail
drwxr-x---   3 remoteuser remoteuser    2048 May 23  2008 public_ftp
drwxr-x---  30 remoteuser nobody   2048 Dec  4 06:33 public_html
drwxr-xr-x   7 remoteuser remoteuser    2048 Sep 24  2008 tmp
lrwxrwxrwx   1 remoteuser remoteuser      11 Apr  1  2006 www -> public_html
matthias:~ matthias$

You can even pipe through to a remote command. Here's an example taken from Look Here First, where the content of a local file is concatenated to a remote file.

matthias:~ matthias$ cat localfile.txt | ssh "cat - >> remotefile.txt"

2. Add your public key to your remote server

Next let's see how we can get around typing our password all the time. One way of doing this is to add your public key to your remote server.

# first, upload public key from client to server
client$ scp ~/.ssh/

# next, setup the public key on server
server$ mkdir ~/.ssh
server$ chmod 700 ~/.ssh
server$ cat ~/ >> ~/.ssh/authorized_keys
server$ chmod 600 ~/.ssh/authorized_keys
server$ rm ~/

Of course, we can combine with the previous example and run it like this:

matthias:~ matthias$ cat ~/.ssh/ | ssh "cat - >> ~/.ssh/authorized_keys2"

Windows users fear not, you can do this too, with PuTTY and PuTTYgen.

3. Let the ControlMaster handle your sessions

Sadly this might not always possible, maybe your key management on your server is different, or you don't have permissions to the file.

Luckily you can get around this by letting your first ssh connection act as ControlMaster. By adding the following to ~/.ssh/config, you only need to enter your password once, and all parallel sessions won't ask for a password

Host *
    ControlMaster auto
    ControlPath ~/.ssh/master-%r@%h:%p

4. Set your user and hostname for your host

Finally, more often than not your username won't be the same on your local machine and on whatever server you'd like to connect to, or your server might not use the default ssh port. Or maybe you're just tired of typing that superlong domain name, and look for a less challenging typing task. ~/.ssh/config to the rescue.

As final example:

Host myserver
    User remoteuser
    Port 22022

Most likely you won't need the Port instruction in there, because your server runs ssh on the default port 22, so just drop the line.

All this allows us something as compact as:

matthias:~ matthias$ ssh myserver mycommand

Have fun, and let's hope this got you into your weekend early!


  • Ahh... very nice. The bit about the config file is perfect. I'm going to use it for the IdentityFile variable, myself. +karma for you :)

    by MacDork on April 17 2009, 16:36 - #

  • Great tips Matthias. Thanks!

    by Alistair Holt on April 17 2009, 20:53 - #

  • @MacDork: IdentityFile is a good way of handling multiple, well, identities; perfect for someone who likes to keep business and private (or in case of many freelancers/contractors business, business, business and private) separate. Use one identity for work, and another for personal projects, etc.

    Thanks for the reminder. There's of course much more configuration options, here's a link to the man pages

    by Matthias Willerich on April 18 2009, 08:48 - #

  • The most simple way to copy your public key is ssh_copy_id

    by Arnaud on April 25 2009, 18:36 - #

  • @Arnaud: I had to look up this one first; it is indeed a great way of adding your public key to a server. This is part of OpenSSH, but sadly not of the default OS X installation (I guess linux folks are fine).

    To get a more elegant solution for #2 on a Mac, download the latest portable OpenSSH and find the ssh-copy-id script in /contrib folder. Copy it, err, somewhere where your system finds it, and you're good to go. Thanks for the tip!

    by Matthias Willerich on April 26 2009, 01:32 - #

  • Nice tips, I already use three of them. Using a public key is fundamental to speed up connection process.

    by Giorgio Sironi on April 26 2009, 13:15 - #

  • This is an interesting post. I wasn't aware of the ControlMaster. I'm going to look into that more.

    re: #2 (Add your public key to your remote server), @Matthias as you said, ssh_copy_id isn't available for the OS X people in the crowd. For the subset of that crowd that isn't offended by Ruby, I wrote a tool called Rye for doing all kinds of remote SSH stuff (including executing commands on multiple machines in parallel). It comes with a command-line utility that can copy keys too:

    $ rye authorize HOST1 [HOST 2 ... HOST N]

    It can be installed with the command:

    $ sudo gem install rye

    by Delano Mandelbaum on April 30 2009, 15:21 - #

  • Nice tips, I already use three of them. Using a public key is fundamental to speed up connection process. cheers

    by amber jewellery on June 25 2009, 22:42 - #

  • This is what I was looking for. Thanks for saving my time.

    by fotowoltaika on August 1 2010, 11:14 - #

Comments for this article are closed.