OpenSSH is
the open source version of SSH, or Secure Shell. Connectivity tools such as
Telnet and FTP are well-known, but they send data in plain text format, which
can be intercepted by someone using another system on the same network,
including the Internet. On the other hand, all data transferred using OpenSSH
tools is encrypted, making it inherently more secure. The OpenSSH suite of
tools includes ssh for securely logging in to a remote system and executing remote
commands, scp for encrypting files while transferring them to a remote system,
and sftp for secure FTP transfers. OpenSSH uses a server-client relationship.
The system being connected to is referred to as the server. The system requesting
the connection is referred to as the client. A system can be both an SSH server
and a client. OpenSSH also has the added benefits of X11 forwarding and port
forwarding. X11 forwarding, if enabled on both the server and client, allows
users to display a graphical application from the system they are logged in to
on the system they are logged in from. Port forwarding allows a connection
request to be sent to one server but be forwarded to another server that
actually accepts the request. This section discusses how to use OpenSSH, both
from the server-side and the client-side.
Configuring the Server
The
openssh-server RPM package is required to configure a Red Hat Enterprise Linux system
as an OpenSSH server. If it is not already installed, install it with Red Hat
Network “Operating System Updates.”
After it is
installed, start the service as root with the command service sshd start. The system is now an SSH server and can accept
connections if the server allows connections on port 22. To configure the
server to automatically start the service at boot time, execute the command chkconfig sshd on as root. To stop the
server, execute the command service sshd
stop. To verify that the server is running, use the command service sshd status.
Retaining Keys After Reinstalling
When the
OpenSSH server package is installed, server authentication keys are generated. The
keys are generated when the OpenSSH server package is installed and are unique
to the server. They are used to verify that the server being connected to is
the intended server. The first time a client connects to an OpenSSH server, it
must accept the public key. If accepted, the client stores the public key and
uses it to verify the identity of the server with each connection.
When a system
acting as an OpenSSH server is reinstalled, the files storing the OpenSSH identification
keys are re-created as well. Because the SSH clients use these keys to identify
the server before connecting to it, they will see the warning message in
Listing after the operating system reinstallation, which generates new keys.
LISTING Warning About Keys Not Matching
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ 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
66:50:c5:dc:ba:36:d4:3f:ea:93:1d:d8:56:e3:38:56.
Please
contact your system administrator.
Add correct
host key in /home/tfox/.ssh/known_hosts to get rid of this message.
Offending key
in /home/tfox/.ssh/known_hosts:73
RSA host key
for 172.31.0.1 has changed and you have requested strict checking.
Host key
verification failed.
After the
message is displayed, the program exits. If you are sure that the key on the server
changed, edit the known_hosts file in the .ssh directory of your home directory
such as /home/tfox/.ssh/known_hosts. The warning message gives the line number
that contains the stored key for the server, or you can search for the hostname
or IP address of the server, whichever one you use to connect to it. Delete the
line, save the file, and exit the text editor. The next time you try to connect
to the server via SSH, you will need to accept the new RSA server key.
Instead of
communicating a new key to users every time a server is reinstalled, an administrator
can retain the host keys generated for the system before reinstalling. To save
the keys before reinstalling, save the /etc/ssh/ssh_host*key* files on another
system or backup media. After reinstalling, restore these files to their
original locations on the server to retain the system’s identification keys. If
this process is used, clients will not receive the warning message when trying
to connect to the system after it is reinstalled.
Connecting from the Client
This section
discusses how to connect to an SSH server from a Red Hat Enterprise Linux system.
The SSH server can be any server running an SSH daemon, including a Red Hat Enterprise
Linux system running OpenSSH. To connect to an SSH server, the openssh-clients
RPM package must be installed. Install it via Red Hat Network if it is not
already installed. This package provides the SSH utilities discussed in this
section and summarized in Table.
TABLE OpenSSH
Client Utilities
OpenSSH Utility
Description
ssh Securely
log in to a remote system or execute a command on a remote system
slogin Alias to the ssh command
scp Copy files from one computer to
another while encrypting the data
sftp Securely transfer files from one
system to another
ssh-add Add RSA or DSA identities to the
authentication agent
ssh-agent Remember private keys for public key
authentication
ssh-keyscan Gather public SSH keys
Logging In to a Remote System
The most
common OpenSSH utility is ssh, a secure replacement for rlogin, rsh, and telnet.
The ssh command allows users to remotely log in to a system from another system
using an encrypted transfer protocol. Every transfer starting with the username
and password sent for authentication is encrypted so it can’t be easily read if
intercepted. The system being connected to is considered the server. The system
being connected from is called the client. To log in to a system with ssh, use
the following command, where <hostname> is the hostname, fully qualified
domain name, or IP address of the remote system:
ssh <hostname>
If the
hostname or fully qualified domain name is used, the client must be able to
resolve it to a valid IP address. The first time a user tries to connect via
ssh to another system, the message in Listing is displayed.
LISTING Connecting to an SSH Server for the First
Time
The authenticity of host ‘172.31.0.1 (172.31.0.1)’ can’t be
established.
RSA key fingerprint is
66:50:c5:dc:ba:36:d4:3f:ea:93:1d:d8:56:e3:38:56.
Are you sure you want to continue connecting (yes/no)?
If the user
types yes, the client saves the server’s public RSA key, and the server
responds by requesting the user’s password. If the correct password is entered,
the server accepts the request, and the user receives a shell prompt to the
remote system. The server’s public key is added to the .ssh/known_hosts file in
the user’s home directory. After this public key is written to this file, the message
in Listed is no longer displayed when a connection is requested.
When the ssh
command is executed, the username of the user currently logged in to the client
is sent to the remote server as the username requesting connection. To use a
different username on the remote server, use the command ssh username@<hostname>.
Executing a Command Remotely
The ssh
utility also allows users to execute commands remotely using the following syntax:
ssh <hostname> <command>
If the
command contains any wildcards, redirects, or pipes, it must be in quotation
marks such as the following:
ssh
myserver.example.com “cat /proc/cpuinfo | grep flags”
After
authenticating with a password or passphrase, the results of <command>
are displayed to the client.
Transferring Files Securely
The scp
utility provides the ability to transfer files from one system to another
system running an SSH server such as OpenSSH. The command has many variations,
but the basic syntax is as follows:
scp <local-file> <username>@remote.example.com:<remote-file>
Like ssh, if
a username is not specified for the remote server, the current username is assumed.
If only a directory path is given for <remote-file>, the same filename is
used to transfer the file to the specified directory on the remote server. The
wildcard character * can be used to specify multiple files for
<local-file> and <remote-file>.
The scp
command can also be used to transfer remote files to the local system. Just reverse
the syntax:
scp <username>@remote.example.com:<remote-file>
<local-file>
A few
command-line options to scp, such as -l, limit the amount of bandwidth it is allowed
to use. Refer to its man page with the man scp command for a full list with descriptions.
The sftp
utility can also be used to transfer files via an encrypted connection. It
differs from scp and is similar to ftp in that it uses an interactive shell. To
connect via sftp to a remote system, use the command sftp username@<remote-system>.
Again, if no username is specified, the username of the current user on the
client is assumed for the remote system. After authenticating correctly, the
sftp> prompt is displayed, giving the user an interactive session to the
remote system (see Listing). The interactive commands are similar to ftp. Table
lists common sftp commands.
LISTING sftp Session
Connecting to
fileserver.example.com...
tfox@fileserver’s
password:
sftp>
TABLE Common sftp Commands
sftp command Description
pwd Display current remote directory
lpwd Display current local directory
cd
<directory_name> Change to
remote directory
lcd
<directory_name> Change current
local directory
get
<file> Retrieve <file> from current
remote directory to current
local directory
mget
<files> Retrieve
multiple files
put
<file> Upload local file to the current
remote directory
mput <files> Upload
multiple local files to the current remote directory
ls List files in current remote
directory
exit Close connection to SSH server and
exit
As you can
tell, the commands are similar to ftp with a few exceptions, such as the user
is not prompted to confirm actions by default—there is no need to disable
prompting with the prompt command before using mget and mput. Hash marks can’t
be displayed to show progress, but progress in terms of percentage of total transfer,
total kilobytes already transferred, transfer rate, and time remaining is
automatically displayed, as in the following:
/tmp/samplefile
100% 1888KB 1.8MB/s 00:01
It is also
possible to connect to an FTP server using sftp from the Nautilus file browser.
Select Places, Connect to Server from the desktop menu, and select SSH as the
service type. Type the IP address or full hostname of the FTP server in the
Server field as shown in Figure.
An icon will
appear on the desktop using the name of the server or, if provided, the name in
the Name To Use For The Connection field. A shortcut is also listed under the
Places menu item in the desktop menu. Double-clicking on the desktop icon or
selecting the shortcut item in the Places menu will open a file browser window
with the files from the FTP server. Depending on your file permissions from the
server, you can open, copy, delete, rename files and directories, and more. To
unmount the share, right-click on its desktop icon and select Unmount Volume.
If the share is not unmounted, it will remain in the Places menu on reboot, but
you must reauthenticate to access the share after rebooting.
Creating a Passphrase
Instead of
using a password to authenticate, OpenSSH allows the use of a passphrase. Why use
a passphrase? Unlike a password, a passphrase can contain spaces and tabs and
is usually much longer than a password, hence the word phrase in the name. The
added length along with the spaces and tabs makes a passphrase more secure and
harder to guess. Passphrases are unique per user and must be created by each
user while logged in with the corresponding username. Red Hat Enterprise Linux
5 uses SSH Protocol 2 and RSA keys by default. To generate an RSA key pair for
SSH version 2, use the following command:
ssh-keygen -t rsa
As
demonstrated in Listing, press Enter to accept the default location of $HOME/.ssh/id_rsa
after the key pair is generated. When prompted for a passphrase, type a
passphrase to use and type it again to confirm. The passphrase should be different
from the user’s password and should contain a combination of numbers and
letters to make it more secure. Remember it can contain spaces and tabs. The
RSA public key is then written to $HOME/.ssh/id_rsa.pub while the private key
is written to $HOME/.ssh/id_rsa.
LISTING Generating
a Passphrase
Generating public/private rsa key pair.
Enter file in which to save the key (/home/tfox/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/tfox/.ssh/id_rsa.
Your public key has been saved in /home/tfox/.ssh/id_rsa.pub.
The key fingerprint is:
ed:09:c2:a8:31:1f:11:85:0a:5e:c0:ab:16:b6:f1:98 tfox@rhel5
After
successfully generating the key pair, copy the contents of the public key file
$HOME/.ssh/id_rsa.pub
to $HOME/.ssh/authorized_keys on all the systems you want to connect to with
the SSH tools. If the authorized_keys file already exists, append it with the
contents of $HOME/.ssh/id_rsa.pub. If the .ssh/ directory does not exist in
your home directory on the remote systems, it must be created so that only you,
the owner, can access it. To change the permissions for it, execute the command
chmod 0700 $HOME/.ssh on the remote system. The $HOME/.ssh/authorized_keys file
on each remote system must have the same permissions as the
$HOME/.ssh/id_rsa.pub file created by ssh-keygen. Change its permissions with
the chmod 644 $HOME/.ssh/authorized_keys command on each remote system to which
you will be connecting.
After
creating an RSA key pair and distributing the public key to the remote systems,
when the ssh <hostname> command is executed, the user will be prompted
for the passphrase used to create the key pair instead of being prompted for a
password for authentication.
Logging Connections
By default,
the OpenSSH daemon (sshd) uses syslog to write messages to /var/log/ messages
when sessions are opened and closed for users as well as when an authentication
attempt has failed.
To modify the
type of messages logged, set the LogLevel directive in the /etc/ssh/
sshd_config
file. By default, it is set to INFO. The possible values in order of verbosity
are QUIET, FATAL, ERROR, INFO, VERBOSE, DEBUG, DEBUG1, DEBUG2, and DEBUG3.
DEBUG and DEBUG1 are the same. Logging with any of the DEBUG levels violates
user privacy and is not recommended.
0 comments:
Post a Comment