Mastering SSH: Strong Password-less Logins
Connecting For the First Time
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
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:
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
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.
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:
Last login: Tue Dec 30 06:36:20 2008 from dink
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.
Solid state disks (SSDs) made a splash in consumer technology, and now the technology has its eyes on the enterprise storage market. Download this eBook to see what SSDs can do for your infrastructure and review the pros and cons of this potentially game-changing storage technology.