Using ssh, Syncing Laptops and Desktops

I've been given an account on a server that has disallowed telnet and ftp access in favor of ssh. What is ssh, and how can I use it? Why have they disabled telnet?


I’ve been given an account on a server that has disallowed telnet and ftp access in favor of ssh. What is ssh, and how can I use it? Why have they disabled telnet?

Ssh stands for “secure shell” and it is a total replacement for telnet. It also comes with a file copying command called scp (secure copy) that can be used instead of ftp for moving files around between machines.

Many administrators choose to disable telnet and ftp because of insecurities in their design. When logging in using these protocols, your password is sent to the server in plain text. It might be possible for a malicious person to “sniff” packets and obtain your login information. While this is unlikely, it can be completely prevented by using a protocol such as ssh.

Ssh is very similar to telnet in use. However, it encrypts not only the login and password, but also the entire transmission. This keeps anyone between you and your server from seeing the contents of your communication.

A popular free implementation of the ssh protocol is part of the OpenBSD system, but also works well with Linux. OpenSSH can be downloaded from http://ftp.openbsd.org/pub/OpenBSD/OpenSSH. If your system is rpm- package-based, you can find rpms in the portable/rpm directory. On Debian systems, the package ssh is available on the non-US servers. (Until recently, there were patent restrictions on one of the encryption algorithms used by OpenSSH. This is no longer the case. Take a look at http://www.rsasecurity.com/developers/total-solution.)

Once installed, using ssh to obtain a shell on the remote box is easy. To access my SourceForge account for the trove project, I use the following:

I am prompted for my system password, after which I am granted a shell on the machine. From here, my session is similar to a telnet session, except that I am ensured all data between me and my server is encrypted.

If you are at all familiar with rsh and its flags, you will be right at home. Ssh was designed to be functionally equivalent to rsh. Programs that can use rsh as a transport will generally allow ssh to be dropped in instead (as is the case with rsync, which we’ll discuss in the next question).

The secure copy command can also be very simple to use. Its syntax is very similar to the cp command.

To copy an index.php file into a directory on my server at dtype.org, I issue the following command on my local machine:

# scp index.php dtype@dtype.org:/usr/local/apache/htdocs/

I will be prompted for my password (as with ssh). Next, the file index.php in the current directory of my local machine will be copied to the /usr/local/ apache/htdocs/ directory on dtype.org, using my login as dtype.

More information about OpenSSH can be found at http://www.openssh.com. There is excellent documentation and more information and justification for secure protocols here.


I use a laptop and would like to ensure that I have the most recent data files on both it and my desktop. What do you suggest?

There is a great tool called rsync that can be used for this. Rsync provides a way to keep two sets of files identical. It is based on an innovative algorithm created by Andrew Tridgell (founder of the SAMBA project) that allows only the changes to files to be transferred.

Rsync is probably already installed on your system, as it is generally considered a standard system utility. If it is not already installed, a package should be available from your distribution, or you can find the original source code at http://rsync.samba.org. You can test for the availability of rsync by simply entering rsync at your shell, which will provide a usage summary of the command.

Rsync must be installed on both machines (in this case, both your laptop and your desktop). The machines must also be able to see each other over a network.

I highly recommend using ssh as a communication mechanism between the machines. There are other ways to set up rsync transfers, including rsh and rsync daemon mode, which are described in the rsync documentation. See the previous question in this column for more about ssh.

The syntax for rsync is very similar to the cp command. Essentially, you will be copying files from one location to the other with some fancy options not available using the copy command. The main difference is that you will now have to specify a non-local machine (your desktop).

You should probably think carefully about which files you want to sync between machines. You will very likely want to place these in a specific directory on your desktop. You should avoid unnecessarily syncing blocks of files that you don’t need. For instance, your home directory probably has several megabytes of browser cache that you probably don’t want to transfer.

I’ve created a directory on my desktop called /home/drew/data where I store all of my data files. To keep things simple, I’ve kept the same directory structure on my laptop as well.

In order to rsync from my desktop to my laptop, I type the following command on my laptop:

# rsync -vazu -e ssh –delete drew@desktopname:/home/drew/data/ /home/drew/data/

This tells rsync to copy files from my desktop’s /home/drew/data/ directory to the same directory on my laptop using ssh. For this to work, I must be able to ssh to drew@desktopname independently of rsync. If you can’t do this, check to ensure that ssh is properly installed and working.

The command line is broken down as follows: The -v flag tells rsync to be verbose and output more information. The -a flag requires that rsync operate in “archive” mode, which copies directory structures, symlinks, and more. The -z flag is used to compress the data along the way. The -u flag is an option I use to “update only,” which prevents rsync from overwriting files that are newer to my laptop than to my desktop. For this flag to work, the system clocks on both machines must be in sync.

I use the -e ssh option to force ssh as the transport mechanism. By default, rsync will try to use rsh instead. The –delete option can be dangerous but tells rsync to delete any files on my laptop that are not present on the desktop. When first testing the rsync commands, I highly recommend leaving this part out until you are comfortable with your syntax and the effects that this flag will have.

When I want to sync files from my laptop back to my desktop, I use a very similar command from my laptop:

# rsync -vazu -e ssh /home/drew/data/ drew@desktop

Note that I left out the –delete flag. I prefer to avoid automating deletes on my desktop. This requires me to manually delete items on my desktop instead. You may wish to keep this flag, but consider yourself warned.

There are many more options for the rsync command, which are available in the man pages or in the documentation at http://rsync.samba.org.


Is there an easy way to ensure that all the system clocks on my machines are the same?

The program ntpdate was designed for just this purpose and is very easy to use. It uses a protocol to speak to one or more machines designated as time servers, and derive a correct system time for your machine.

You will first have to determine which time servers you would like to use. While it is possible to setup one of your own servers as a time server, and sync the others from it, this is not my preferred method. It requires additional administration on your part, and still requires that you keep the time server accurate.

I prefer instead to sync all of my machines from several well known time servers. There are several good ones to choose from, but I like to use the official time servers for the US Naval Observatory. A list of these servers can be found at http://tycho.usno.navy.mil/ntp.html.

The syntax for ntpdate is very simple, and it must be run as the root user. You may specify one or more time servers on the command line. I’ll be using the first three servers listed in the USNO list. Ntpdate will then have the option of picking the best time server for the sync.

The server in Figure One (192.5.41. 40) was already fairly accurate. It was only adjusted by 0.017 seconds.

Figure One: The NTP Date Command

# ntpdate ntp2.usno.navy.mil tock.usno.navy.mil tick.usno.navy.mil
14 Nov 17:19:04 ntpdate[16015]: adjust time server offset -0.017641 sec

To keep this clock accurate, I may choose to place the ntpdate command line in the crontab. However, on a machine that will not be always on (like a laptop), the line is more appropriate in a startup script, or run manually.

I should note that while ntpdate sets the time for your system clock, it does not set your hardware (battery backed) clock. To force your hardware clock to reflect the system time, use the following command line:

# hwclock -systohc>

This will ensure that upon reboot, your hardware clock will accurately set your system time.

If ntpdate is not already installed on your system, it should be available for installation from your distribution install disks. More information about ntpdate can be found in the man pages for the command.

Drew Streib is a coder, admin, and writer with VA Linux Systems. He can be reached at tech@linux-mag.com.

Comments are closed.