Inside SSH, Part 4
Pages: 1, 2, 3
Using scp
Many times during the completion of the steps outlined in this article, we have relied on a program that often goes along SSH, called "scp." Much like the "cp" command, it allows you to copy files. However, scp allows you to copy files between hosts and, what's more, in a secure fashion.
If you are already comfortable with cp, scp's syntax should not be too surprising. Essentially, it boils down to:
scp name-of-source name-of-destination
Name-of-source will be one or more files while name-of-destination can be either a file (to copy a file between hosts) or a directory (to place multiple files into directories). Copying multiple files into one file is theoretically possible but the file will be overwritten as the various copying operations take place -- in other words, it's not really something you want to do.
Both name-of-source and name-of-destination should follow the same structure: username@hostname:/path/to/directory. Be careful, though, since scp's syntax is quite flexible; entering a wrong character can cause the program to behave in unexpected and sometimes unwanted ways. For example "cooking@tips.example.com" is a file while "cooking@tips.example.com:" represents the default folder (home) of account "cooking" on the server tips.example.com. I have no idea if these servers or accounts exist, BTW.
A complete scp command would look like this:
scp usernameone@hostone:/path/to/file usernametwo@hosttwo:path/to/file
scp allows you to omit some elements in the command, such as the directory or the user name if you use standard or expected values. However, when getting used to scp, I would recommend that you always enter the full command. This will allow you to learn about SSH more quickly and avoid mistakes -- overwriting a file, for example. However, to download a file, you don't need to enter the full "username@hostname" address in the second part of the command -- simply have a look at the scp commands we used earlier in the article.
By using the "-r" flag, you can instruct scp to copy whole directories as well. Be careful, though. Links, aliases, and directories that loop back to themselves are not good candidates and can cause issues during or after the transfer. What you can do instead is compress the directory in Terminal and then send it as a file over the network.
The "-p" flag will allow you to retain the permissions of the files you copy. However, as a general rule, it's always a good idea to use a command such as "ls -l" to check the permissions of the resulting files on the remote machine.
Going One Step Further: Creating SSH Tunnels
The concept of SSH tunnels is a fun, powerful, and interesting one. Let's imagine what happens when you use a VNC client to connect to a remote computer through a graphical interface. When you establish a connection, a big glass pipe is run between your Mac and the remote computer you are controlling.
This glass pipe is transparent; anybody can see what is going on inside of it and read the information it contains. It is also fragile. Anybody with readily available tools can smash the glass wall and add things to the pipe, right in the middle of the stream.
As you can see, this is far from a secure connection. However, since the material the pipe is made of is decided by the protocol you are using, your only option to secure it is to put this big pipe into another, more robust one. I like to think of it as stainless steel but pick your metal of choice. That way, the outside pipe will protect the inside, fragile one from prying eyes and intrusion tools, while being designed for easy plumbing. Best of all, since both pipes are well-designed, you do not need to modify the inside one. It simply slides right into the metal shell.
This is exactly what SSH can do. If you have to use insecure protocols (glass pipes), you can instruct them to pass through a secure SSH connection that will be wrapped around them (the metal pipe), effectively securing them. The good news is that SSH is, like our metal pipe, entirely transparent to the insecure application and is therefore extremely unlikely to disrupt anything.
SSH tunneling is out of the scope of our discussion, directly at least. There are, however, some great tunneling-related articles on the O'Reilly Network that provide you with step-by-step tutorials. Secure Mail Reading on Mac OS X by Jason McIntosh is an excellent starting point.
Final Thoughts
SSH is a flexible and powerful protocol. Thanks to the Mac OS X engineers, it is also incredibly easy to use on a Mac. By learning a bit about it and practicing in your Terminal, you can bring your computing and networking experience to the next level.
Ben Lindstrom from the OpenSSH group was kind enough to provide me with information regarding some detailed SSH configuration settings. May he find here the expression of my gratitude. Needless to say, any errors or inaccuracies in the preceding pages remain entirely my responsibility.
FJ de Kermadec is an author, stylist and entrepreneur in Paris, France.
Return to MacDevCenter.com.
You must be logged in to the O'Reilly Network to post a talkback.
Showing messages 1 through 6 of 6.
-
I return often . . .
2006-05-27 05:05:07 rbannon@mac.com [Reply | View]
-
I return often . . .
2006-05-29 03:48:41 FJ de Kermadec |
[Reply | View]
Rbannon,
Thank you for your kind words, they are much appreciated! I am glad the article is of interest to you.
The article you link to is indeed most interesting. It is true that the advice I endeavored to outline here, while good for a start, certainly should not be considered as the ultimate in security for state secrets and it would be dangerous to enable SSH on all secure servers, even by using a strong key-based authentication mechanism.
The article you mention however mostly mention misuse of SSH tunnels by users who forget that, even though SSH encrypts the connection between two machines, it does create a connection. In this regard, linking a secure server to an insecure server, no matter how strong the channel is still opens up ways for an attacker already "owning" the insecure server to crawl its way up into the secure zone of your network (if I am permitted to use such an image).
The advice outlined there certainly is not to be downplayed. It remains however (at least in this part of the series) focused on one problem that has much to do with carefree port forwarding.
FJ -
I return often . . .
2009-02-12 04:41:59 rbannon@mac.com [Reply | View]
Yes, I'm back once again. This time however, I am trying to reconfigure my five year old machine to accept ssh (sftp) traffic after updating to Mac OS X 10.5. All seems well, but this time I am seeing some strange entires in my appfirewall.log, and it reads, "Feb 11 08:21:12 beelzebub Firewall[57]: Allow sshd-keygen-wrapper connecting from 220.225.110.237:39098 uid = 0 proto=6". Not just one entry, but repeated and persistent entries coming from multiple IPs. Yikes!
I don't recall this happening under 10.4 and I believe it's the same configuration as outlined in this tutorial.
Should I be concerned? I've turned off ssh for now, but would like to turn it back on. Any advice? -
I return often . . .
2007-01-21 20:23:15 rbannon@mac.com [Reply | View]
Alright, /. has a new (01/20/2007) piece on SHA-1 data encryption scheme and how a Chinese researcher has cracked the method wide open. Maybe old news, but is anyone willing to share their thoughts with regards to Apple's use of Openssh and how it might be improved?
http://it.slashdot.org/article.pl?sid=07/01/20/1936257
-
Less use for Timbuktu
2004-08-07 13:42:36 MSchienle [Reply | View]
Thanks for passing along the info about softwareupdate and installer. That will help curtail some of my use of Timbuktu to do the same things from the GUI. My server is 1000 miles away from home and I'm comfortable on the command line (UNIX geek for 15 years), but didn't know about Apple's addition of these utilites. -
Less use for Timbuktu
2004-08-07 14:05:23 FJ de Kermadec |
[Reply | View]
Hi!
Thank you very much for your kind words, they mean a lot to me! :-)
F.J.






Recently, a slashdot post about ssh vulnerabilities has me concerned that my implementation, following your advice may be easily compromised. Of course much of the slashdot audience downplay the informIT , but I'd really like your expert opinion on this one. Maybe even a part five of this series that would further tighten our Mac OS X ssh servers. (http://www.informit.com/articles/printerfriendly.asp?p=471099)