Continued from Page 1.
Authorized Keys
What if I don't want to type in my password each time I login? Or, what if I'm a sysadmin and I want my server harder to crack than guessing a password? You can use a public/private key pair to make logging into a server both more secure and easier.
In order to use a public/private key pair, you have to create it. You can do so from a command line by using the ssh-keygen utility. There are many options that you can pass to ssh-keygen including the type of key, the filename you want it to create, and a comment for the key file, but you can also just roll with the defaults. Here is the result of calling ssh-keygen with no arguments:
dink:~ jmjones$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/jmjones/.ssh/id_rsa):
Created directory '/Users/jmjones/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/jmjones/.ssh/id_rsa.
Your public key has been saved in /Users/jmjones/.ssh/id_rsa.pub.
The key fingerprint is:
fe:e9:fa:f5:e2:4e:a1:6c:9e:9e:20:a4:cc:ec:4f:62 jmjones@dink
The key's randomart image is:
+--[ RSA 2048]----+
| |
| |
| |
| |
| . S . |
| + o . . . . |
| E o o + o |
| o o . = *.. |
| ... .=Xoo.. |
+-----------------+
I accepted the default "id_rsa" as my key file. I also accepted the default of not putting a passphrase on the file. If I had chosen to add a passphrase to the file, I would be prompted for the password each time I used it. Two files were created in $HOME/.ssh as a result of running ssh-keygen:
dink:~ jmjones$ ls -l ~/.ssh/
total 16
-rw------- 1 jmjones staff 1675 Dec 30 17:37 id_rsa
-rw-r--r-- 1 jmjones staff 400 Dec 30 17:37 id_rsa.pub
"id_rsa" is my private key. I don't want anyone to get access to this file, otherwise they could pretend that they are me. Notice that the permissions are more restrictive on "id_rsa" than on "id_rsa.pub." "id_rsa.pub" is my public key. I can circulate this file to anyone that I am interested in connecting to. Don't worry; no one can reverse it and determine what your private key is.
If I want to use this key with the server in the previous examples, I would place the contents of my public key ("id_rsa.pub") into the file "$HOME/.ssh/authorized_keys" on the remote server. In order to set this up, I typically ssh to the remote server and copy/paste the contents of my local "id_rsa.pub" file to the remote "authorized_keys" like this:
jmjones@ezr:~$ echo "ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAw4DTU
eLXZbjjNhR+AaW9^102rsa103^+Pg2+Q8M+gK/
IGDbPjsAV4KwulqDWS+ChlIiq0wXj/bQKQwZacbghX
ud/YBI7FfYOkF1R9pFZ7O9B7zJGAnAtcOEDLfyDhYF2
Cl5/1HFolIUuUSCGPJy3bbIK5s6yNwQV6cW6yEFUuqE
8DHlGKf9jwDFgiXrhtuThH2EFGBCxELaumworegMD39J
b9^123rsa124^1zWFqP2qHX/SzItHm1JrKJdnbsOn5h+KM
Teztpn1AExOx1lxSFLk9lp4JAMk8NTURYmBcAE6yASaQA
pw5jDw/JpSAdFaQR/Vl6Kpzf9MD1KAEpyd8RaxLa+
RQ== jmjones@dink" > ~/.ssh/authorized_keys
jmjones@ezr:~$ ls -l ~/.ssh/
total 4
-rw-r--r-- 1 jmjones jmjones 400 2008-12-30 17:48 authorized_keys
jmjones@ezr:~$
After which, I am no longer prompted for a password to login. Here, I log out of the server, then ssh back in:
jmjones@ezr:~$ logout
Connection to 192.168.1.20 closed.
dink:~ jmjones$ ssh 192.168.1.20
Be careful.
No mail.
Last login: Tue Dec 30 17:50:26 2008 from dink
Notice that my ssh client didn't prompt me for a password. Now, anytime I want to connect to this server, I just ssh in and I will be instantly connected.
Executing Remote Commands
I mentioned earlier that after sshing to a remote server, you are dropped into a shell. This is the default behavior, but it isn't the only thing you can do. Another useful way of using an ssh client is to execute commands on a remote server without typing it into an interactive shell on the remote server. To state it another way, you can specify what command you want to run on the remote system when you execute the ssh utility on your local system. For example, if I wanted to see if a process is listening on port 25 on the remote system, I could do it like this:
dink:~ jmjones$ ssh 192.168.1.20 netstat -ltpn | grep 25
(Not all processes could be identified, non-owned process info
will not be shown, you would have to be root to see it all.)
tcp 0 0 127.0.0.1:25 0.0.0.0:* LISTEN -
The syntax is "ssh address command." I could do the same thing to check disk usage, see which processes are running, or copy files around. And since I setup authorized_keys, it's not much more overhead to execute commands remotely than to execute them locally.
Why not just log in and run the commands interactively? Because you would lose the benefit of scriptability. Executing commands on a remote system can now become part of a shell script. And those shell scripts can run under cron. Now the possibilities for getting work done on remotes systems is an open horizon.
Conclusion
ssh is an essential tool. In its most common use, it allows you to interactively manipulate a shell on a remote server. This is certainly indispensable for remote system administration. It also lets you simplify and increase the security of the authentication process by using authorized keys. Finally, it allows you to execute shell commands on the remote system without being in the interactive shell.
