Secure Shell Replacements for Unix Remote Commands

Introduction

The traditional Unix "remote" commands have been superseded by more secure commands. The methods for achieving passwordless remote access have also changed.

Remote Access Commands

The old "remote" commands operate in clear text over the network, potentially exposing your userid, password, and file contents to capture. The new "remote" commands are based on the Secure Shell technologies which encrypt all communications for security.

to log on to another system: ssh or slogin replace the rlogin and telnet commands
to copy a file to another system: scp replaces rcp; sftp replaces ftp
to execute a command on another system: ssh replaces rsh

Refer to the "man" pages for details of command line options.

Passwordless Remote Access

It is convenient to be able to log in remotely from your usual initial login host to various others without being challenged for a password. With the old remote commands, this was accomplished by setting up a .rhosts file. With the SSH-based commands, it was accomplished with a .shosts file. More recently, both of these are deprecated in favour of SSH keys, as described below.

Note that this is a trade-off between convenience and security. If you set up passwordless access for convenience, then you reduce security. If someone can break into your first login host, they can then log in to any other machines where you have installed your SSH key.

Setting up Remote Access Permissions using Keys

The preferred method of setting up permissions to access other hosts from your favourite host is to use private/public key pairs. Your favourite host (typically where you first log in) will contain your private key. Your public key is distributed to the hosts to which you log in remotely. When you issue a command to a remote host, it responds with a message that is encrypted using your public key. Your favourite host is able to decrypt the message using your private key.

Here are two ways to do this. First, do-it-yourself, so you can see what's happening; second, one command that does it all for you.

Do-It-Yourself

There are two steps: generate your key pair, then copy the public key to remote hosts.

Step 1. Generate your private/public key pair

On your favourite Unix host, use the ssh-keygen command to generate the key pairs. Enter a passphrase when prompted:

% ssh-keygen -t rsa

(The RSA key format is the default, so the "-t rsa" option isn't necessary, but perhaps makes things more obvious.) Sample output:

Enter file in which the key is (/u/myuserid/.ssh/id_rsa):
Key has comment '/u/myuserid/.ssh/id_rsa'
Enter new passphrase (empty for no passphrase): 
Enter same passphrase again: 
Your identification has been saved in /u/myuserid/.ssh/id_rsa.
Your public key has been saved in /u/myuserid/.ssh/id_rsa.pub.
The key fingerprint is:
3d:70:8d:22:14:bf:67:d7:37:6f:71:fa:12:6d:92:b2 myuserid@myhost.uwaterloo.ca

This command creates the following files in your .ssh directory:

id_rsa

this is your private key, also referred to as an identifier (keep it private!)

id_rsa.pub

this is your public key; it can be copied to other hosts and added to the authorized keys file

Step 2. Copy your keys to hosts that you access from your favourite host

Copy your public key (.ssh/id_rsa.pub in above example) to any machine that you want to issue commands to, or log into. For example:
```
% scp id_rsa.pub myuserid@remotehost:id_rsa.pub
```
Log in to the remote machine and create a .ssh directory if it does not already exist.
```
% ssh remotehost
% mkdir .ssh
```
On the remote machine, add your public key to the set of authorized keys:
```
% cat id_rsa.pub >> .ssh/authorized_keys
```
Then set safe permissions on the authorized_keys file:
```
% chmod 600 .ssh/authorized_keys
```

If you have other hosts similar to your favouritehost that you issue commands from, repeat this procedure there. See the ssh-keygen(1) man page for details.

One Command

Some operating systems may provide a ssh-copy-id command that does most or all of it for you. The version on xhiered Solaris, if present, generates both RSA and DSA keys if you don't have them, creates a .ssh directory on the remote machine if it isn't already there, copies the public key over and adds it to your authorized_keys file, and fixes the permissions on all the files involved. The version on Linux, if present, requires you to create the key pair yourself first. Sample output on a Solaris 10 system with xhiered ssh, for a remote machine called "remotehost":

% ssh-copy-id remotehost
Generating RSA key
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Generating DSA key
Enter passphrase (empty for no passphrase): 
Enter same passphrase again: 
Password: 
Now try logging into the machine, with "ssh 'remotehost'", and check in:

  .ssh/authorized_keys
  .ssh/authorized_keys2

to make sure we haven't added extra keys that you weren't expecting.

See the ssh-copy-id(1) man page for details.

Final Notes and References

Sometimes when hosts are upgraded, their keys are not always preserved. In that case, you may see a message saying that the host key has changed. The keys you generated for yourself will still work.
See also How to get, install, configure and use the Windows SSH client.

Last updated by Robyn Landers, MFCF and Jeff Voskamp, IST on December 16, 2011.