Saturday, June 19, 2010

Smart ssh tricks

I want my computers to talk to one another.

More specifically, I want to be able to remotely log in to one of my computers from another one, and I want to be able to easily copy files from one computer to another. The easiest, most secure, way to do that these days is to use the Secure Shell protocol, aka ssh.

Examples: I have an account on a computer called grumpy (sleepy and doc were already taken). To log onto grumpy from hal, I open up a terminal window and type:

$ ssh rcjhawk@grumpy

The program then logs me onto grumpy, where I can access the system just as I can for any desktop machine.

Or, say, I have a file at /home/rcjhawk/Documents/strasburg_pictures.ppt on grumpy. To copy it over to Hal, I use the secure copy program, scp:

$ scp rcjhawk@grumpy:Documents/strasburg_pictures.ppt .

which, obviously, works pretty much like the regular copy program except that I have to specify the machine and account name right up front.

And, finally, I can send files the other way:

$ scp The_Hard_Times_of_Zach_Greinke.txt rcjhawk@grumpy:Documents

which sends that regrettable file into the Documents folder on grumpy.

Except:

You will probably find that this doesn't work out of the box in your Ubuntu setup. You'll get a message that looks something like this:

ssh: connect to host grumpy port 22: Connection refused

That's because Ubuntu ships ssh in two parts:

  • openssh-client: this lets you use ssh and scp from your machine to log onto another machine. This is installed with the standard Ubuntu installation, and is all you need if, for example, you want to log onto your work computer from home.
  • openssh-server, on the other hand, allows other machines to log onto your personal desktop machine. This is not installed by default in Ubuntu because it's an obvious security hole unless you know what you're doing. If you do know, or assume that you will learn, install the package with

    $ sudo apt-get install openssh-client

    Once you do that, sshd, the daemon that controls remote access, will automatically start up, and will start up every time you reboot the machine. Then you're good to go.

In the example above, grumpy needs to have openssh-server installed and running, but hal does not.

Note for Mac Users: You get the equivalent of openssh-server by going to System Preferences => Sharing and clicking Remote Login.

Security

ssh encrypts the transmissions between machines, but it also has other security features. The first time you try to log onto a machine, for example, you'll get a message that looks something like this:

$ ssh rcjhawk@grumpy
The authenticity of host 'grumpy (192.168.54.42)' can't be established.
RSA key fingerprint is xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx.
Are you sure you want to continue connecting (yes/no)?

If you answer yes, then you'll get the message:

Warning: Permanently added 'grumpy,192.168.54.42' (RSA) to the list of known hosts.

After that you'll be able to log onto grumpy without the warning message. If you want to start over, i.e. not recognize any computer as being previously visited, erase the file $HOME/.ssh/known_hosts

You can also limit access to the machine by editing your /etc/hosts.deny and /etc/hosts.allow files. As I've noted before, if you don't want ever Tom, Dick, and Susie to have a chance to access your machine, your /etc/hosts.deny file should read:

ALL: ALL

after which only addresses listed in your /etc/hosts.allow file will have access to the machine. In my /etc/hosts.allow file I currently have

ALL: 192.168.1.0/255.255.255.0 ,

which allows all machines on our local network to access grumpy.

OK, everything is good, right? Well, not quite. As things are set up right now, every time you ssh or scp to grumpy you must enter a password. This isn't a big annoyance with ssh, because presumably you will keep the remote login running for a relatively long time. However, it is an annoyance with scp, if you want to copy a large number of files from different places, requiring a large number of scp commands.

The solution is to use ssh-keygen to generate a a key. Here's how it works:

Start the program:

$ssh-keygen -t dsa Generating public/private dsa key pair.
Enter file in which to save the key (/home/rcjhawk/.ssh/id_dsa):


We'll use the default directory location, so just hit return here.

Enter passphrase (empty for no passphrase):

Frankly, I don't know anyone who does use a passphrase. It does protect your key against someone who's gotten access to your account, but at that point you're probably hosed anyway. So for now we'll just hit return.

Enter same passphrase again:
Your identification has been saved in /home/rcjhawk/.ssh/id_dsa.
Your public key has been saved in /home/rcjhawk/.ssh/id_dsa.pub.

Now let's take a look at the .ssh directory:

$ ls -la $HOME.ssh
total 16
drwx------  2 rcjhawk rcjhawk  4096 2010-06-19 13:04 .
drwxr-xr-x 34 rcjhawk rcjhawk  4096 2010-06-19 13:01 ..
-rw-------  1 rcjhawk rcjhawk   672 2010-06-19 13:04 id_dsa
-rw-r--r--  1 rcjhawk rcjhawk   599 2010-06-19 13:04 id_dsa.pub

Here you'll notice two files. One, id_dsa, is your private key. The second, id_dsa.pub, is your public key. Key the private key private. Don't let anyone have access to it. Don't copy it over into the .ssh folder of another account, or to another computer. You'll note that both the .ssh directory and id_dsa are set so you are the only person who can read those files. Keep it that way.

The public key, now, that's another matter. If you place id_dsa.pub into the file $HOME/.ssh/authorized_keys on another computer, you'll be able to access that computer from your home computer. Here's one way to to it (I'm leaving out all the password prompts):

$ ssh rcjhawk@grumpy
Welcome to grumpy!
rcjhawk:~ $ cd .ssh
rcjhawk:~/.ssh $ scp rcjhawk@hal:.ssh/id_dsa.pub tempid
rcjhawk:~/.ssh $ cat tempid >> authorized_keys
rcjhawk:~/.ssh $ rm tempid
rcjhawk:~/.ssh $ exit

What did we do? We logged into grumpy, copied hal's public key over to grumpy's .ssh directory, and added it to the end of the authorized_keys file. I renamed the file during the copy so as not to write over grumpy's own id_dsa.pub file, if one was there. Notice that scp was able to get that file even though Hal's .ssh directory is copy protected, because you gave the system the right password.

The next time you try to ssh or scp from hal to grumpy, ssh will find the public key on grumpy, compare it to the private key on hal, and conclude that you are, indeed, allowed to log in or transfer files.

The discerning reader will note that I'm only applying this to my local network, which all sits behind a router and firewall. How, you may ask, can I use ssh to log onto my local machine from outside my home?

Well, I wish I could tell you, but at the moment I can't. It's something to be researched in the future. If you're reading this, and you know how to do it, post a link to the procedure in the comments.

0 comments: