Author: Joe Barr
telnet. But those days are gone. The Internet today is a hostile and insecure environment. Snap out of your GUI-induced haze for a few minutes, and come with me to the CLI. Let’s explore OpenSSH, which replaces telnet and does a whole lot more.OpenSSH includes several programs:
- ssh remote login client
- sshd remote login server
- scp secure file copy
- sftp secure file transfer
As you may remember when we discussed tcpdump, programs like telnet, rlogin, and ftp actually send your user ID and password as plain text, unencrypted, across the network. OpenSSH provides the missing security for that risk, plus a few other really nifty things.
You’ve probably guessed that the remote machine needs to be running sshd before you can log in using the SSH client. Here’s what you might see if the other end is not living up to its end of the deal:
$>ssh warthawg@192.168.0.101$>ssh: connect to host 192.168.0.101 port 22: Connection refused
If sshd — the server — is running at the remote end, but you haven’t made the connection before to that machine, you’ll see something like this:
The authenticity of host '192.168.0.101 (192.168.0.101)' can't be established. RSA key fingerprint is f0:68:f0:af:3c:75:cd:2a:7f:ae:61:af:a3:fb:7d:79. Are you sure you want to continue connecting (yes/no)?
Replying in the affirmative records the RSA key fingerprint. And you’ll see a message to that effect: “Warning: Permanently added ‘192.168.0.101’ (RSA) to the list of known hosts.” The server has made a record of the contact as well, and added your machine to its list of known hosts.
That’s the first hurdle. Let’s call it authentication. It will come into play later. But we’re not logged on yet. That requires a password for the account you’re signing in on, whether that is root or a normal user. If you’ve signed on to the machine before, you’ll see a message indicating the date, time, and IP address of your last sign-on.
At this point, you’re able to do anything at the command line that a local shell user can do, with the only restrictions being the permissions available to that user. If you have the root password, you can invoke su and get full privileges. To end the connection, just type exit (or Ctrl-D if your shell is Bash) and you’re done. Safely done, too, since all traffic between your machine and the remote was encrypted during the session.
OK, the next problem is this. Say you have a bunch of digital photographs on your eMac, which is connected to your LAN. A friend wants them on her machine. You’re sitting at your Linux desktop, also on the LAN. What to do? Nothing to it. Use scp — Secure Copy — to copy directly from the eMac in the next room to your friend’s machine in the next county.
Here’s the format to do that:
scp file1 file2
OK, I admit I condensed things a little bit in that example. Both file1 and file2 expand somewhat in the real-life example. Expanding file1 a little bit, we see that we have our familiar user@host joined by a colon to a filepath. It’s pretty simple, really. Completely expanded, file1 looks like this:
warthawg@192.168.0.101:/home/warthawg/lotsofpix.tgz
So much for file1, a.k.a. the file to be copied. It’s good to note that your initial path defaults to your home directory so it isn’t required that you type it out if you’re just copying between your home directories. We’ll type it out for this example just to be clear. And file2, the resulting file, is made up in exactly the same way. It looks like this:
friend@192.168.0.92:/home/friend/lotsofpix.tgz
So the complete command, that probably would have looked way too geeky for you in the beginning, looks like this:
scp warthawg@192.168.0.101:/home/warthawg/lotsofpix.tgz friend@192.168.0.92:/home/friend/lotsofpix.tgz
Yes, it gets to be a pretty long command when it’s all together on the same line, but it’s not complicated, and once you grok the pattern you won’t think twice about it.
Let’s not forget sftp, the Secure FTP client. Basically, it provides a secure, fully equivalent FTP client. Just like its sibling clients, it requires sshd to be running at the remote end.
More on authentication
I mentioned earlier a hurdle called authentication. Authentication is a means of verifying that a connection is being made with a “known” host, not just somebody who through chance or treachery has the same IP address as one of the remotes you connect to. OpenSSH lets you know immediately if the RSA host key for an IP address doesn’t match the one it knows for that address. Like this:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ 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 19:76:59:5a:7a:2e:85:95:07:76:dc:32:37:c6:92:0b. Please contact your system administrator. Add correct host key in /home/warthawg/.ssh/known_hosts to get rid of this message. Offending key in /home/warthawg/.ssh/known_hosts:8 RSA host key for 192.168.0.101 has changed and you have requested strict checking. Host key verification failed.
Of course, this doesn’t always mean someone is trying to make all of you data are belong to them. I triggered the warning above by installing Turbolinux on my laptop, and the RSA key it generated when sshd was run for the first time didn’t match the key generated by the previous installation.
As always, we’ve just scratched the surface, and I most heartily recommend you to the man. Hopefully, however, you will have learned enough to stop using insecure shell and file transfer programs.
