Using SSH Clients

In Linux, the primary SSH client is called, naturally enough, ssh. In its simplest form, you type the program name followed by the system to which you want to connect. Ordinarily, the remote server then prompts you for a password. The first time you connect, the system also informs you that it can't verify the authenticity of the remote site. Overall, your connection request will look something like this:

[email protected]:~$ ssh blueox.luna.edu

The authenticity of host 'blueox.luna.edu (192.168.1.6)' can't be established. RSA key fingerprint is 4b:68:c1:a8:75:5e:b4:76:7b:a6:a2:0d:3a:8b:5f:48. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'blueox.luna.edu,192.168.1.6' (RSA) to the list of *known hosts.

[email protected]'s password: [[email protected] paul]$

Some configurations automatically add previously unknown sites to the key file, so you may not have to authorize a connection. Either way, subsequent connections to the same system will lack the prompt and need to type yes to authorize a connection. You will have to type a password, though, unless you modify the configuration as described shortly. (The password doesn't echo to the screen.)

Linux's ssh client passes the current username as part of the connection protocol. If your username on the server system is different from your username on the client system, you must pass this information. You can do so by preceding the hostname with the username and an at sign (@) or by using the -I parameter. For instance, both of the following two commands log you onto the jack account on blueox.luna.edu:

$ ssh [email protected] $ ssh -I jack blueox.luna.edu

If you want to access a Linux system from a non-Linux system, you can do so. OpenSSH is available for many Unix-like systems, so you can use it from them. For other platforms, consult http://www.freessh.org. This site provides information about free SSH clients on a variety of platforms. Many commercial and shareware network access tools also support SSH.

In addition to remote login tools, SSH ships with clients to perform file transfers. The scp program works much like Linux's standard cp, but it operates over an encrypted SSH link. You can use a colon (:) to separate a hostname from the filename, and you can use an at sign (@) to separate a username from a hostname. For instance, to copy somefile.txt to the jack account on blueox.luna.edu, you might type:

$ scp somefile.txt [email protected]:somefile.txt

You can omit parts of this command. For instance, you can omit somefile.txt from the destination, because the filename is identical to the source filename. (You must still include the colon, though.) You can omit the username and at sign if the remote username is the same as your username on the client system. A more sophisticated file-transfer tool is sftp, which works much like a text-mode File Transfer Protocol (FTP) client, but using the encrypted SSH connection. Using sftp, you can view a list of files available on the server system, transfer multiple files, and so on.

In a default configuration, SSH prompts for a password when making a connection. You can use alternative authentication tools, though; several such options are summarized in Table 26.1. When you activate these methods, they're tried before a password prompt. As an example, consider using public key authentication. As described here, this method will enable you to log into the remote system without typing a password. Instead, SSH will use private and public keys stored on the client and server. As a result, an interloper won't be able to masquerade as you without breaking into your computer and stealing your public key. You can use a similar approach, but with some modifications, to require use of an SSH-specific passphrase rather than the client's normal password for logins. To implement a public key system that requires no password, follow these steps:

1. Log into the SSH client system (say, bunyan.luna.edu).

2. Type the following command to generate public and private keys for the client system:

$ ssh-keygen -q -t rsa -f ~/.ssh/id_rsa -C " -N "

Note Omitting the -N " parameter from this command causes the program to prompt for a passphrase. You will then need to use the passphrase instead of a password when you connect to the server. If you press the Enter key twice when prompted for the password, the effect is the same as including -N ".

3. Copy the ~/.ssh/id_rsa.pub file from the client computer to the server computer. You can transfer this file via floppy disk, using scp, or by any other means you choose. If you use scp, you'll have to enter a password.

4. Log into the SSH server system (say, blueox.luna.edu). You may use SSH to do this, but at this point you'll still have to use a password.

Ensure that the ~/.ssh directory exists and has 0700 (-rwx------) permissions. If necessary, type mkdir~/.ssh to create the directory orchmod 0700 ~/.ssh to set appropriate permissions on the directory

6. Add the id_rsa.pub file you've transferred from the client to the ~/.ssh/authorized_keys file on the server. (This filename may differ; check the AuthorizedKeysFile option in your SSH server configuration.) If this is the first client you've added, this file may not exist. Whether or not this is the first client, the following command should do the job (you may need to adjust paths or filenames for the public key file):

7. Ensure that the keys file has the correct ownership and permissions.

Permissions should be no more than 0600 (-rw-------). If necessary, type chmod 0600 ~/.ssh/authorized_keys to set these permissions.

Once you've completed these steps, you should be able to log in from the client (bunyan) to the server (blueox) without typing a password. Depending on the order in which the protocol levels are listed in your/etc/ssh/ssh_config file's Protocol line, though, you may have to specify that you want to use level 2 of the SSH protocol:

$ ssh -2 blueox.luna.edu

0 0

Post a comment