OpenSSH Clients


This section covers setting up and using the ssh, scp, and sftp clients.

Prerequisites

Install the following packages:

  • openssh

  • openssh-clients

There are no startup commands for OpenSSH clients.

JumpStart: Using ssh and scp

The ssh and scp clients do not require setup beyond installing the requisite packages, although you can create and edit files that facilitate their use. To run a secure shell on or securely copy a file to/from a remote system, the following criteria must be met: The remote system must be running the OpenSSH daemon (sshd), you must have an account on the remote system, and the server must positively identify itself to the client. The following example shows a user logging in on grape as zach and then giving an exit command to return to the shell on the local system:

$ ssh zach@grape zach@grape's password: [zach@grape zach]$ exit Connection to grape closed. $


You can omit user@ (zach@ in the preceding example) from the command line if you want to log in as yourself and you have the same username on both systems. The first time you connect to a remote OpenSSH server, ssh or scp asks you to confirm that you are connected to the right system. Refer to "First-time authentication" on page 584.

The following example copies ty1 from the working directory on the local system to Zach's home directory on grape:

$ scp ty1 zach@grape: zach@grape's password: ty1                 100% |*****************************|  1311     00:00


Setup

This section describes how to set up OpenSSH on the client side.

Recommended Settings

X11 forwarding


The configuration files provided by Red Hat establish a mostly secure system and may or may not meet your needs. The important OpenSSH default value that the Red Hat configuration files override is ForwardX11Trusted, which is set to yes in the Red Hat /etc/ssh/ssh_config configuration file (page 595). See page 596 for more information on X11 forwarding.

Server Authentication/Known Hosts

known_hosts, ssh_known_hosts


Two files list the hosts the local system has connected to and positively identified: ~/.ssh/known_hosts (user) and /etc/ssh/ssh_known_hosts (global). No one except the owner (root in the case of the second file) should be able to write to either of these files. No one except the owner should have any access to a ~/.ssh directory.

First-time authentication


When you connect to an OpenSSH server for the first time, the OpenSSH client prompts you to confirm that you are connected to the right system. This checking can help prevent a man-in-the-middle attack (footnote 3 on page 992):

The authenticity of host 'grape (192.168.0.3)' can't be established. RSA key fingerprint is c9:03:c1:9d:c2:91:55:50:e8:19:2b:f4:36:ef:73:78. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'grape,192.168.0.3' (RSA) to the list of known hosts.


Before you respond to the preceding query, make sure you are logging in on the correct system and not on an imposter. If you are not sure, a telephone call to someone who logs in on that system locally can help verify that you are on the intended system. When you answer yes (you must spell it out), the client appends the server's public host key (the single line in the /etc/ssh/ssh_host_rsa_key.pub or /etc/ssh/ssh_host_dsa_key.pub file on the server) to the user's ~/.ssh/known_hosts file on the local client, creating the ~/.ssh directory if necessary. So that it can keep track of which line in known_hosts applies to which server, OpenSSH prepends the name of the server and the server's IP address (by default) to the line.

When you subsequently use OpenSSH to connect to that server, the client verifies that it is connected to the correct server by comparing this key to the one the server supplies.

known_hosts file


The known_hosts file uses one very long line to identify each host it keeps track of. Each line starts with the hostname and IP address of the system the line corresponds to, followed by the type of encryption being used and the server's public host key. The following line (it is one logical line wrapped on to four physical lines) from known_hosts is used to connect to grape at 192.168.0.3 using RSA (page 1053) encryption:

$ cat ~/.ssh/known_hosts grape,192.168.0.3  ssh-rsa  AAAAB3NzaC1yc2EAAAABIwAAAIEArinPGsaLUtnSL4V7b T51ksF7KoScsIk7wqm+2sJEC43rxVNS5+MO/O64UXp5qQOHBmeLCCFCsIJg8xseuVkg9iwO BKKOdlZdBNVqFS7tnJdBQTFf+ofPIDDip8w6ftHOdM8hZ/diQq5gXqMH+Mpac31pQXAxXgY SP8NYIgb3X18=


OpenSSH automatically stores keys from servers it has connected to in user-private files (~/.ssh/known_hosts). These files work only for the user whose directory they appear in. Working as root and using a text editor, you can copy lines from a user's private list of known hosts to the public list in /etc/ssh/ssh_known_hosts to make a server known globally on the local system.

If, after a remote system's public key is stored in one of the known hosts files, the remote system supplies a different fingerprint when the systems connect, OpenSSH displays the following message and does not complete the connection:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @    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 f1:6f:ea:87:bb:1b:df:cd:e3:45:24:60:d3:25:b1:0a. Please contact your system administrator. Add correct host key in /home/sam/.ssh/known_hosts to get rid of this message. Offending key in /home/sam/.ssh/known_hosts:1 RSA host key for grape has changed and you have requested strict checking. Host key verification failed.


If you see this message, you may be the subject of a man-in-the-middle attack. It is more likely, however, that something on the remote system has changed, causing it to supply a new fingerprint. Check with the remote system's administrator. If all is well, remove the offending key from the specified file (the third line from the bottom in the preceding example points to the line you need to remove) and try connecting again. You will see the first-time authentication (page 584) again as OpenSSH verifies that you are connecting to the correct system. Follow the same steps as when you initially connected to the remote host.

ssh: Connects to or Executes Commands on a Remote System

The format of an ssh command line is


ssh [options] [user@]host[command]

where host, the name of the OpenSSH server you want to connect to, is the only required argument. The host can be a local system name, an FQDN of a system on the Internet, or an IP address. Give the command ssh host to log in on the remote system host with the same username that you are using on the local system. Include user@ when you want to log in with a username other than the one you are using on the local system. Depending on how things are set up, you may need to supply your password.

Opening a remote shell


Without command, ssh logs you in on host. The remote system displays a shell prompt and you can run commands on host. Give the command exit to close the connection to host and return to the local system's prompt:

[bravo]$ ssh speedy alex@speedy's password: Last login: Sat Sep 16 06:51:59 from bravo Have a lot of fun... You have new mail. [speedy]$ ... [speedy]$ exit Connection to speedy closed. [bravo]$


Running a remote command


When you include command, ssh logs in on host, executes command, closes the connection to host, and returns control to the local system. The remote system never displays a prompt.

The following example runs ls in the memos directory on the remote system speedy. The example assumes that the user running the command (Alex) has a login on speedy and that the memos directory is in Alex's home directory on speedy:

[bravo]$ ssh speedy ls memos alex@speedy's password: memo.0921 memo.draft [bravo]$


For the next example, assume a file named memo.new is in the working directory on the local system (bravo). You cannot remember whether this file contains certain changes or whether you made these changes to the file named memo.draft on speedy. You could copy memo.draft to the local system and run diff (page 135) on the two files, but then you would have three similar copies of the file spread across two systems. If you are not careful about removing the old copies when you are done, you may just become confused again in a few days. Instead of copying the file, you can use ssh:

[bravo]$ ssh speedy cat memos/memo.draft | diff memos.new 


When you run ssh, standard output of the command run on the remote system is passed to the local shell as though the command had been run in place on the local system. As with all shell commands, you must quote special characters that you do not want the local system to interpret. In the preceding example, the output of the cat command on speedy is sent through a pipe on bravo to diff (running on bravo), which compares the local file memos.new to standard input (). The following command line has the same effect but causes diff to run on the remote system:

[bravo]$ cat memos.new | ssh speedy diff  memos/memo.draft


Standard output from diff on the remote system is sent to the local shell, which displays it on the screen (because it is not redirected).

Options

This section describes some of the options you can use with ssh.

C


(compression) Enables compression. (In the commercial version of ssh, C disables compression and +C enables compression.)

f


(not foreground) Sends ssh to the background after asking for a password and before executing the command. Useful when you want to run the command in the background but must supply a password. Implies n.

L


Forwards a port on the local client to a remote system. For more information refer to "Tunneling/Port Forwarding" on page 596.

l user


(login) Attempts to log in as user.

n


(null) Redirects standard input to ssh to come from /dev/null. Required when running ssh in the background.

o option


(option) Specifies option in the format used in configuration files (page 589).

p


(port) Specifies the port on the remote host that the connection is made to. Using the host declaration (page 590) in the configuration file, you can specify a different port for each system you connect to.

R


Forwards a port on the remote system to the local client. For more information refer to "Tunneling/Port Forwarding" on page 596.

t


(tty) Allocates a pseudo-tty to the ssh process on the remote system. Without this option, when you run a command on a remote system, ssh does not allocate a tty (terminal) to the process. Instead, ssh attaches standard input and standard output of the remote process to the ssh sessionthat is normally, but not always, what you want. This option forces ssh to allocate a tty on the remote system so programs that require a tty will work.

v


(verbose) Displays debugging messages about the connection and transfer. Useful if things are not going as expected.

X


(X11) Turns on nontrusted X11 forwarding. This option is not necessary if you turn on X11 nontrusted forwarding in the configuration file. For more information refer to "Forwarding X11" on page 596.

x


(X11) Turns off X11 forwarding.

Y


(X11trusted) Turns on trusted X11 forwarding. This option is not necessary if you turn on trusted X11 forwarding in the configuration file. For more information refer to "Forwarding X11" on page 596.

scp: Copies Files from/to a Remote System

The scp (secure copy) utility copies an ordinary or directory file from one system to another on a network. This utility uses ssh to transfer files and employs the same authentication mechanism as ssh; thus it provides the same security as ssh. The scp utility asks you for a password when one is required. The format of an scp command is


scp [[user@]from-host:]source-file[[user@]to-host:][destination-file]

where from-host is the name of the system you are copying files from and to-host is the system you are copying to. The from-host and to-host arguments can be local system names, FQDNs (page 1032) of systems on the Internet, or IP addresses. When you do not specify a host, scp assumes the local system. The user on either system defaults to the user on the local system who is giving the command; you can specify a different user with user@. The scp utility can copy between two remote systems.

The source-file is the file you are copying, and the destination-file is the resulting copy. Make sure that you have read permission for the file you are copying and write permission for the directory you are copying it into. You can specify plain or directory files as relative or absolute pathnames. (A relative pathname is relative to the specified or implicit user's home directory.) When the source-file is a directory, you must use the r option to copy its contents. When the destination-file is a directory, each of the source files maintains its simple filename. When the destination-file is missing, scp assumes the user's home directory.

Sam has an alternate username, sls, on grape. In the following example, Sam uses scp to copy memo.txt from the home directory of his sls account on grape to the allmemos directory in the working directory on the local system. If allmemos was not the name of a directory, memo.txt would be copied to a file named allmemos in the working directory.

$ scp sls@grape:memo.txt allmemos sls@grape's password: memo.txt          100% |*****************************| 14664       00:00


As the transfer progresses, the percent and number of bytes transferred increase and the time remaining decreases. The asterisks provide a visual representation of the progress of the transfer.

In the next example, Sam, while working from peach, copies the same file as in the previous example to the directory named old in Sam's home directory on speedy. For this example to work, Sam must be able to use ssh to log in on speedy from grape without using a password. For more information refer to "Authorized Keys: Automatic Login" on page 592.

$ [sam@peach] scp sls@grape:memo.txt speedy:old sam@grape's password:


Options

This section describes some of the options you can use with scp.

C


(compression) Enables compression.

o option


(option) Specifies option in the format used in configuration files (discussed shortly).

P port


(port) Connects to port port on the remote host.

p


(preserve) Preserves the modification and access times as well as the modes of the original file.

q


(quiet) Does not display the progress meter.

r


(recursive) Recursively copies a directory hierarchy.

v


(verbose) Displays debugging messages about the connection and transfer. Useful if things are not going as expected.

sftp: A Secure FTP Client

As part of OpenSSH, Red Hat Linux provides sftp, a secure alternative to ftp (page 601). Functionally the same as ftp, sftp maps ftp commands into OpenSSH commands. You can replace ftp with sftp when you are logging in on a server that is running the OpenSSH daemon, sshd. Once you are connected to a system with sftp, give the command ? to display a list of commands. For secure communication, use sftp or scp to perform all file transfers requiring authentication. Refer to the sftp man page for more information.

~/.ssh/config and /etc/ssh/ssh_config Configuration Files

It is rarely necessary to modify OpenSSH client configuration files. For a given user there may be two configuration files: ~/.ssh/config (user) and /etc/ssh/ssh_config (global). These files are read in this order and, for a given parameter, the first one found is the one that is used. A user can override a global parameter setting by setting the same parameter in his user configuration file. Parameters given on the ssh or scp command line take precedence over parameters set in either of these files.

A user's ~/.ssh/config file must be owned by the user (the owner of the ~/ directory) and must not be writable by anyone except the owner; if it is, the client will exit with an error message. This file is typically set to mode 600 as there is no reason for anyone except its owner to be able to read it.

Lines in the configuration files contain declarations that start with a keyword, which is not case sensitive, followed by whitespace, and end with case-sensitive arguments.

You can use the Host keyword to cause declarations to apply to a specific system. A Host declaration applies to all the lines between it and the next Host declaration. You can use * and ? wildcards within a hostname.

Host hostnames


Specifies that the following declarations, until the next Host declaration, apply to hostnames only. The hostnames should be in the same form you would use on a command line and can contain ? and * wildcards. A single * specifies all hosts.

CheckHostIP yes | no


Uses an IP address in addition to a hostname to identify a system in the known_hosts file when set to yes (default). Set to no to use a hostname only.

ForwardX11 yes | no


When set to yes, automatically forwards X11 connections over a secure channel in nontrusted mode and sets the DISPLAY shell variable. Alternatively, you can use X on the command line to redirect X11 connections in nontrusted mode. The default value for this parameter is no. For X11 forwarding to work, X11Forwarding must also be set to yes in the /etc/sshd_config file on the server (page 595). For more information refer to "Forwarding X11" on page 596.

ForwardX11Trusted yes | no


When set to yes, automatically forwards X11 connections over a secure channel in trusted mode and sets the DISPLAY shell variable. Alternatively, you can use Y on the command line to redirect X11 connections in trusted mode. The default value for this parameter is no but Red Hat Linux sets it to yes. For X11 forwarding to work, X11Forwarding must also be set to yes in the /etc/sshd_config file on the server (page 595). For more information refer to "Forwarding X11" on page 596.

HostbasedAuthentication yes | no


Tries rhosts authentication when set to yes. For a more secure system, set to no (default).

HostKeyAlgorithms algorithms


The algorithms is a comma-separated list of algorithms that the client uses in order of preference. Choose algorithms from ssh-rsa or ssh-dss (default is ssh-rsa, ssh-dss).

TCPKeepAlive yes | no


Periodically checks whether a connection is alive when set to yes (default). This checking causes the ssh or scp connection to be dropped when the server crashes or the connection dies for another reason, even if it is only temporary. Setting this parameter to no causes the client not to check whether the connection is alive.

This declaration uses the TCP keepalive option, which is not encrypted and is susceptible to IP spoofing (page 1038). Refer to "ClientAliveInterval" on page 594 for a server-based nonspoofable alternative.

StrictHostKeyChecking yes | no | ask


Determines whether and how OpenSSH adds host keys to a user's known_hosts file. Set to ask (default) to ask whether to add a host key when connecting to a new system, set to no to add a host key automatically, and set to yes to require that host keys be added manually. The yes and ask arguments cause OpenSSH to refuse to connect to a system whose host key has changed. For a more secure system, set to yes or ask.

User name


Specifies a username to use when logging in on a system. Specify systems with the Host declaration. This option means that you do not have to enter a username on the command line when you are using a username that differs from your username on the local system.




A Practical Guide to Red Hat Linux
A Practical Guide to Red HatВ® LinuxВ®: Fedoraв„ў Core and Red Hat Enterprise Linux (3rd Edition)
ISBN: 0132280272
EAN: 2147483647
Year: 2006
Pages: 383

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net