Learn about Linux
Download Linux
Get Linux helpSpecial Offers
Feature
CLI Magic: OpenSSH
Share
Print
Commentstelnet. 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.
- 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.
Comments
on CLI Magic: OpenSSHNote: Comments are owned by the poster. We are not responsible for their content.
BTW, I never knew about FISH until I read this, thanks!<nobr> <wbr></nobr>:) It is very cool, and probably more secure / easier than samba shares.
It is more secure (and easier) than samba shares, but is it still limited in that it doesn't really create a true mounted drive. Only kde apps that can use the fish:// protocol (like konqueror) can really 'see' the files.
fish:// is more of a hyper-easy secure ftp that looks like the files are local in the konqueror window (and any other kde app that uses kde-parts). But the directory is not actually mounted anywhere on your system. That would be nifty. Hmm, I feel a patch coming on<nobr> <wbr></nobr>;)
runa@malditainternet.com
For example, if you just want to copy something from "here" to "there", you can do something like:
<tt>me@here:~$ scp file there:.</tt>
This is easier than:
<tt>me@here:~$ scp file me@there:/home/me/file</tt>
Regarding sftp, it has no notion of ASCII/binary transfer modes. This is one of the major flaws of FTP in my mind; I don't know how many archives I've transferred via FTP, only to find out it was corrupted by ASCII mode. There is no such risk with sftp, which assumes all file data is relevant.
But the directory is not actually mounted anywhere on your system. That would be nifty. Hmm, I feel a patch coming on<nobr> <wbr></nobr>;)You mean like <A HREF="http://fuse.sourceforge.net/sshfs.html" title="sourceforge.net">SSH Filesystem (sshfs)?</a sourceforge.net>
I checked out sshfs (and the FUSE library it is built on, and its predecessor, the sshfs filesystem distributed with LUFS), and it seems like a good tool, but I have some reservations.
Keep in mind, I have not actually tried to use sshfs yet, so take this with a grain of salt.
It appears that sshfs is an implementation of the sftp protocol that appears to be a mounted filesystem on your pc (documentation on the website is non-existant, maybe they have more in the tarball, I'll look into that). While this is a good interim idea, and probably extremely useful in some situations, I have to wonder about the efficiency of that methodology.
<rant>
NFS, AFS, and other real networked filesystems are custom built to provide caching, locking, security, transfer-modifications-only, and other services specifically designed to make a remote filesystem appear (and perform as if it were) local. I can't imagine that sshfs (or any other sftp based filesystem) implements this type of interactivity, being designed to upload/download whole files at a time, possibly with restartable uploads/downloads.
In short, while sshfs is probably an excellent package written by a good programmer that serves a needed purpose, what I was talking about in my previous post is a truly secure, networked filesystem capable of supporting multiple simultaneous users, with all the bells and whistles we have come to expect from things like NFS/AFS/etc...
I have seen some info about CODA being encryptable, but I can't tell what the exactly means, is it encrypting the files on disk and then you access them remotely? Or is it encrypting the connection?
But to use CODA you have to change the on disk filesystem, as well as the network access, which I don't want. I want to use whatever fs on disk (ext3, jfs, xfs, reiserfs, etc.) and be able to access it through an encrypted channel that offers the performance of a true network filesystem. Unfortunately, it may not be practical to separate the on disk fs from the network fs because of ACL, permissioning, journalling, or some other technical reason, but since this is just my wish list, I'm going to wish BIG<nobr> <wbr></nobr>;) And since I'm not looking for a distributed filesystem, just an encrypted-when-on-the-wire one, something like NFS over SSL, or SSL-enabled NFS (there is a difference) is probably all I really want. The sad part is it probably already exists, I'm just too dense to find it (or the config options to turn it on)<nobr> <wbr></nobr>:(
</rant>It appears that sshfs is an implementation of the sftp protocol that appears to be a mounted filesystem on your pcThis is correct. So you don't have to do anything special to the server, which is the primary advantage of using SSH as a file system. I meant to propose using it instead of using fish:// if your apps didn't support fish:// & required a local mount. It would certainly beat patching fish or sshd (which is what it sounded like you were proposing). I didn't mean to imply that it was the most efficient network file system. But then if I misunderstood you, I think that current network file systems are already quite good & don't know what patch you are proposing....
NFS, AFS, and other real networked filesystems are custom built to provide caching, locking, security, transfer-modifications-only, and other services specifically designed to make a remote filesystem appear (and perform as if it were) local.NFS & many other network filesystems often aren't scaleable and have very poor security. Kerberized NFS addresses some of this. A universal implementation of NFS that addressed security concerns & worked on all platforms never really took off.
I will be the first to praise AFS. The encryption it uses is "good enough" (similar to DES). I would probably choose it or CODA when I had a choice of what clients were connecting to the server. The support for these in the 2.6 kernel is a huge plus. But it hasn't yet been adopted heavily. And many need to transfer multi-gig datafiles, which isn't a strongpoint of AFS. (Disclaimer: I have usually ended up running samba and/or netatalk accessible only to the local subnet so that I woukdn't have to provide support to clients.)
I have seen some info about CODA being encryptable, but I can't tell what the exactly means, is it encrypting the files on disk and then you access them remotely? Or is it encrypting the connection?CODA is nice & it is a shame that development seems to be largely abandoned. Traffic is not by default encrypted. Like AFS, you may want to use it with a VPN. Or, if encryption without configuration & without a VPN/stunnel is a primary concern, <A HREF="http://www.fs.net/sfswww/" title="fs.net">SFS</a fs.net> might be a good bet. (CFS TCFS, a different SFS, and VS3FS, mentioned in the Filesystems HOWTO appear to have become stagnant, so I don't know if you'd be embracing something with a long lifetime....)
If it were me, I'd use one of the options already in wide deployment, even if I had to take a hit somewhere (performance or encryption strength being the most likely places).
I think we are actually agreeing on all points, just looking at the problem from two different angles.<nobr> <wbr></nobr>;)
sftp/scp/rsync-over-ssh/sshfs/etc are good for the 'one-off', "I need to grab this file, right now" type of thing. Especially remotely across a WAN link of some kind. Especially since they are dead-simple to use compared to setting up a VPN and/or tunneling everywhere, etc.
What I'm more interested in is LAN network filesystems. Especially in large installations, you cannot trust the wire to not be sniffed. What is the point of using secure access token generators, strong passwords for user accounts, and heavy duty physical access restrictions, when a janitor can pop a sniffer on the wire, and reconstruct your files from network packets? Or what about wi-fi networks? Any 12 year old with a laptop can listen in on those (not all have WPA/EAP/LEAP).
I was wondering if sshfs, or anything like it, would be usable 24x7 for remote home dirs, roaming user accounts, etc. The patch I was proposing was to something (I haven't thought hard about what yet) that would transparently strongly encrypt sensitive information before putting it on a wire.
I saw a few of the other fs types you mentioned, but the did look like abandonware, for the most part. I'm really not proposing radical new software, just an extension to the existing standard so that I could, maybe use ssh certs to encrypt an NFS session? Access control and everything else stay the same, but when I xfer a file, the pipe is secure. Maybe a way to link NFS with OpenSSL?
I would like to know more about that other NFS standard you mentioned, the one that never really took off... And you can bet I'll check out SFS<nobr> <wbr></nobr>;)
Unfortunately, I believe this thread, which started off-topic, has gone horribly awry<nobr> <wbr></nobr>;)
I know it is a little contrary to the whole CLI theme of this series of articles, but kde's fish:// protocol is (IMHO) one of the coolest things around. It is also one of the few reasons I fire up Konqueror at all.
Fish (FIles over sSH, I think) can load a remote compter's files into a konqueror window using ssh, allowing you to drag and drop files between computers graphically.
try this:
- Open a konqueror window
- in the "Location" bar type in something like "fish://mylogin@some.remotemachine.com" (no quotes)
- enter your password (or ssh cert passphrase, depending on your setup) when asked
You should very soon get a listing of files in your home directory on the remote machine, that you can treat exactly like local files! The best part is that the entire exchange is run over SSH, so it is secure, and a whole lot less messy than sftp or scp, especially if you are moving a bunch of files, but not everything in the dir.
BTW, I still use sftp/scp for one by one file transfers. But if I need to grab 20 files in a dir, and not get the other 15, fish:// rocks!
And lets not forget tunneling!
Posted by: Anonymous Coward on February 07, 2005 11:01 PM#