SSH Mastery: Connection, Remote Commands, and Keys

Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

The ssh command line utility is a staple for people who work on remote systems. ssh stands for “secure shell,” so as you may expect one of its most common uses is as a remote shell. While that is perhaps its most common use, it isn’t the only, or most interesting, thing you can do with ssh.

Creating a Connection
Password Authentication
Authorized Keys
Executing Remote Commands
Conclusion
RELATED NEWS AND ANALYSIS

Creating a Connection

In order to do anything over ssh, you first need to establish a connection to a remote server. There are a number of command line arguments that you can use with the ssh command line utility, but I’ll leave it to man ssh to discuss the majority of them. The most basic commandline arguments are ssh address where “address” is the hostname or IP address of the server you want to connect to. Here is an example of connecting to a remote system for the first time:

dink:~ jmjones$ ssh 192.168.1.20
The authenticity of host '192.168.1.20 (192.168.1.20)' can't be established.
RSA key fingerprint is 24:1e:2e:7c:3d:a5:cd:a3:3d:71:1f:6d:08:3b:8c:93.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.20' (RSA) to the list of known hosts.

Earlier I said that “ssh” stands for “secure shell.” ssh is very concerned about security. The message “The authenticity of host ‘192.168.1.20 (192.168.1.20)’ can’t be established” shows this security focus. This message just means my ssh client doesn’t know the remote server. I use the word “client” here and throughout this article because the ssh command line utility initiates the network connection and that makes it, by definition, a network client.

After informing me that it didn’t know the remote server, the utility then asked me if I wanted to continue connecting. I answered “yes” because I knew that the server I was connecting to was the server I really intended to connect to. Typically, it is safe to answer “yes” to this question. The danger, though, is that some bad person with questionable motives might be impersonating the server you are attempting to connect to. After I answered “yes” to continue connecting, my ssh client updated the file $HOME/.ssh/known_hosts with the following text:

192.168.1.20 ssh-rsa ^4rsa5jmjones6cd7jmjones8^/^9cd10^+9^11yc12yc13rsa14AAAAB15^+^16rsa17

AAAAB18^99u2^19oT20oT21^7N7^22AAAAB23^+^24cd25^5f+^26ykuwQcXI27

EAAAABIwAAAQEAvb28jmjones29oT30commandline31

^2Ax3J88^32commandline33yc34^+rOB+gOdRaD+NTkuzrB

/^38oT39^50L6^40oT41AAAAB42^61rq+9v+4^44AAAAB45rsa46ykuwQcXI47^5q1P11^48AAAAB49gcgPr50^==

The next time I connect to the same server, my ssh client will check the “known_hosts” file to see if this really is the same server. If the information that the server passes back to my client doesn’t match what is in the “known_hosts” file, I will see error like this:

dink:~ jmjones$ ssh 192.168.1.20
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that the RSA host key has just been changed.
The fingerprint for the RSA key sent by the remote host is
24:1e:2e:7c:3d:a5:cd:a3:3d:71:1f:6d:08:3b:8c:93.
Please contact your system administrator.
Add correct host key in /Users/jmjones/.ssh/known_hosts to get rid of this message.
Offending key in /Users/jmjones/.ssh/known_hosts:1
RSA host key for 192.168.1.20 has changed and you have requested strict checking.
Host key verification failed.

Password Authentication

I’ll pick back up with the prior example, the one in which I answered “yes” to continue. After answering “yes,” I was prompted for a password. Here is the remainder of that interaction:

jmjones@192.168.1.20's password:
Be careful.
No mail.
Last login: Tue Dec 30 06:36:20 2008 from dink
jmjones@ezr:~$

I typed in the password and my ssh client dropped me into an interactive shell on the remote server. You can see the tell-tale signs of logging into a Linux server: the “message of the day” (aka MOTD), a message regarding having no waiting email, a message of when I logged in last, and a shell prompt. At this point, it was as if I were logged in locally to the server.

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  staff400 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 AAAAB3NzaC1yc2EAAAABIwAAAQEAw4DTUeLXZbjjNhR+AaW9^102rsa103^+

Pg2+Q8M+gK/IGDbPjsAV4KwulqDWS+ChlIiq0wXj/bQKQwZacbghXud/YBI7FfYOkF1R9pFZ7O9B7zJGAnAtcOEDLfyDhYF2Cl5/1HFolIUuUSCGPJy3bbIK5s6yNwQV6cW6yEFUuqE8DHlGKf9jwDF
giXrhtuThH2EFGBCxELaumworegMD39Jb9^123rsa124^1
zWFqP2qHX/
SzItHm1JrKJdnbsOn5h+KMTeztpn1AExOx1lxSFLk9lp4JAMk8
NTURYmBcAE6yASaQA
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.)
tcp0  0 127.0.0.1:250.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.

This article was first published on EnterpriseITPlanet.com.