Password free remote login and other SSH tips
Linux, Security August 6th, 2007 - 11,394 viewsI typically have four or five terminal windows open, and I’m almost always logged in to at least three servers (my dev box, production box, and database server). It’s a huge pain to log back into all these sessions whenever my connection is dropped. To keep myself sane, I use a couple of tricks to keep timeouts from occurring, and to streamline the login process when they do.
Keep connections alive
My home network consists of a cheap NAT firewall/wireless access point connected to a cable modem. In order to route incoming traffic properly, NAT devices keep a table of active connections in memory. As a result, NAT firewalls have a nasty habit of timing out idle sessions to keep their state tables clean. Thankfully, SSH has a built in keepalive mechanism that solves the problem.
You can turn SSH keepalives on at the system level, or on a per user basis. Single user configuration options are stored in ~/.ssh/config. The system wide configuration options are typically found in /etc/ssh_config (on Debian systems, it’s /etc/ssh/ssh_config). To enable keepalives, open the config file in your favorite text editor and add the following lines:
Host * ServerAliveInterval 60
The numeric argument specifies the number of seconds between keepalive requests on idle connections. The Host line lets you restrict declarations to a particular host, or group of hosts. A single ‘*’ is a wildcard pattern that matches any host, so keepalive requests will be sent for all sessions.
Password free login
Even with keepalive requests turned on, your session will time out occasionally (e.g., when you lose your internet connection). You can save yourself a bit of time by adding your workstation’s SSH key to the authorized_keys file on each remote system you login to.
First, generate an SSH public/private key pair on your local system (if you already have a key pair you can skip this step). When prompted for a passphrase, leave it blank.
local$ ssh-keygen -t rsa Generating public/private rsa key pair. Enter file in which to save the key (/Users/mmalone/.ssh/id_rsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /Users/mmalone/.ssh/id_rsa. Your public key has been saved in /Users/mmalone/.ssh/id_rsa.pub. The key fingerprint is: 4d:d0:f4:f2:6c:3a:ac:b4:dc:c7:71:2b:b8:b7:5a:7c mmalone@michael-malones-computer.local
Next, copy the public key from your local system to the system you’re logging into (if the ~/.ssh directory does not exist on the remote system, you may have to create it: mkdir ~/.ssh).
local$ cat ~/.ssh/id_rsa.pub | ssh mmalone@immike.net \\ > 'cat >> .ssh/authorized_keys' Password:
All done. Now you can log into your remote system without a password:
local$ ssh mmalone@immike.net Linux www 2.6.18-3-686 #1 SMP Sun Dec 10 19:37:06 UTC 2006 i686 mmalone@www:~$
The same public key can be used on any number of remote servers, so you can repeat steps two and three on any other servers you regularly use.

August 7th, 2007 at 1:35 am
An easier way to copy the pub key to the remote machine is to use ssh-copy-id.
ssh-copy-id -i @
i.e.
ssh-copy-id -i .ssh/id_rsa.pub root@123.123.123.123
Dzamir Says:August 7th, 2007 at 4:19 am
I’m using ssh with my little debian home server and your tip was very usefull! :D
sumit Says:August 7th, 2007 at 7:56 am
thank you for the tip. it really does help..
AdamG Says:August 8th, 2007 at 4:02 am
Your situation sounds like the *ideal* use case for GNU Screen. Screen will do two things:
1. It will allow you to consolidate your 4-5 terminal windows into one (it’s really very convenient - you won’t know how you managed without it)
2. More importantly, by running screen sessions on the remote servers, even with only a single shell within them, you can simply reattach to your running session if your connection is dropped.
I’ve been meaning to write about my SSH setup with screen for a while… I guess I’ll go finish that up.
I’m surprised at the relatively small number of people who use authorized_keys; most people seem to use ssh-agent. I’ve always used authorized_keys, because connecting on different ports from the Internet to my home network will route my SSH connection to different computers, and the OpenSSH client will disable password auth (AKA, ssh-agent) if the host key of an IP addy changes. Since I’m connecting to different computers depending on the port, it changes a lot, making ssh-agent pretty much useless.
mike Says:August 9th, 2007 at 5:42 pm
@AdamG:
Yea, screen is an awesome utility. I actually use it quite a bit. The problem is I’m connecting to multiple machines (at least three), and screen multiplexes on a single host (as far as I know?).
I still use screen for certain applications (e.g., long-running daemons that I want to monitor from time to time). But I do a lot of development work that requires switching quickly between DB server and VI on my dev box, for example. Then another quick switch from svn ci on my dev box to svn update on my production server. Rather than constantly switching terms with screen, I just open multiple terminal windows.
hvm Says:August 20th, 2007 at 6:06 am
thanks, I never thought this was possible. This just shows how beginner i am :-(
Your blog is so informative and detail explanation.