OpenSSH is a set of network connectivity tools used to provide secure access to remote machines. Additionally, TCP/IP connections can be tunneled or forwarded securely through SSH connections. OpenSSH encrypts all traffic to effectively eliminate eavesdropping, connection hijacking, and other network-level attacks.
OpenSSH is maintained by the OpenBSD project and is installed by default in FreeBSD. It is compatible with both SSH version 1 and 2 protocols.
When data is sent over the network in an unencrypted form, network sniffers anywhere in between the client and server can steal user/password information or data transferred during the session. OpenSSH offers a variety of authentication and encryption methods to prevent this from happening. More information about OpenSSH is available from http://www.openssh.com/.
This section provides an overview of the built-in client utilities to securely access other systems and securely transfer files from a FreeBSD system. It then describes how to configure a SSH server on a FreeBSD system. More information is available in the man pages mentioned in this chapter.
To log into a SSH server, use
ssh and specify a username that exists on
that server and the IP address or hostname
of the server. If this is the first time a connection has
been made to the specified server, the user will be prompted
to first verify the server's fingerprint:
#sshThe authenticity of host 'example.com (10.0.0.1)' can't be established. ECDSA key fingerprint is 25:cc:73:b5:b3:96:75:3d:56:19:49:d2:5c:1f:91:3b. Are you sure you want to continue connecting (yes/no)?user@example.comyesPermanently added 'example.com' (ECDSA) to the list of known hosts. Password for user@example.com:user_password
SSH utilizes a key fingerprint system
to verify the authenticity of the server when the client
connects. When the user accepts the key's fingerprint by
typing yes when connecting for the first
time, a copy of the key is saved to
.ssh/known_hosts in the user's home
directory. Future attempts to login are verified against the
saved key and ssh will display an alert if
the server's key does not match the saved key. If this
occurs, the user should first verify why the key has changed
before continuing with the connection.
By default, recent versions of
OpenSSH only accept
SSHv2 connections. By default, the client
will use version 2 if possible and will fall back to version 1
if the server does not support version 2. To force
ssh to only use the specified protocol,
include -1 or -2.
Additional options are described in ssh(1).
Use scp(1) to securely copy a file to or from a
remote machine. This example copies
COPYRIGHT on the remote system to a file
of the same name in the current directory of the local
system:
#scpPassword for user@example.com:user@example.com:/COPYRIGHT COPYRIGHTCOPYRIGHT 100% |*****************************| 4735 00:00*******#
Since the fingerprint was already verified for this host, the server's key is automatically checked before prompting for the user's password.
The arguments passed to scp are similar
to cp. The file or files to copy is the
first argument and the destination to copy to is the second.
Since the file is fetched over the network, one or more of the
file arguments takes the form
user@host:<path_to_remote_file>. Be
aware when copying directories recursively that
scp uses -r, whereas
cp uses -R.
To open an interactive session for copying files, use
sftp. Refer to sftp(1) for a list of
available commands while in an sftp
session.
Instead of using passwords, a client can be configured
to connect to the remote machine using keys. To generate
RSA
authentication keys, use ssh-keygen. To
generate a public and private key pair, specify the type of
key and follow the prompts. It is recommended to protect
the keys with a memorable, but hard to guess
passphrase.
%ssh-keygen -t rsaGenerating public/private rsa key pair. Enter file in which to save the key (/home/user/.ssh/id_rsa): Enter passphrase (empty for no passphrase):Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa. Your public key has been saved in /home/user/.ssh/id_rsa.pub. The key fingerprint is: SHA256:54Xm9Uvtv6H4NOo6yjP/YCfODryvUU7yWHzMqeXwhq8 user@host.example.com The key's randomart image is: +---[RSA 2048]----+ | | | | | | | . o.. | | .S*+*o | | . O=Oo . . | | = Oo= oo..| | .oB.* +.oo.| | =OE**.o..=| +----[SHA256]-----+
| Type a passphrase here. It can contain spaces and symbols. |
| Retype the passphrase to verify it. |
The private key
is stored in ~/.ssh/id_rsa
and the public key
is stored in ~/.ssh/id_rsa.pub.
The
public key must be copied to
~/.ssh/authorized_keys on the remote
machine for key-based authentication to
work.
Warning:
Many users believe that keys are secure by design and
will use a key without a passphrase. This is
dangerous behavior. An
administrator can verify that a key pair is protected by a
passphrase by viewing the private key manually. If the
private key file contains the word
ENCRYPTED, the key owner is using a
passphrase. In addition, to better secure end users,
from may be placed in the public key
file. For example, adding
from="192.168.10.5" in front of the
ssh-rsa
prefix will only allow that specific user to log in from
that IP address.
The options and files vary with different versions of OpenSSH. To avoid problems, consult ssh-keygen(1).
If a passphrase is used, the user is prompted for the passphrase each time a connection is made to the server. To load SSH keys into memory and remove the need to type the passphrase each time, use ssh-agent(1) and ssh-add(1).
Authentication is handled by
ssh-agent, using the private keys that
are loaded into it. ssh-agent
can be used to launch another application like a
shell or a window manager.
To use ssh-agent in a shell, start it
with a shell as an argument. Add the identity by
running ssh-add and entering the
passphrase for the private key.
The user will then be able to ssh
to any host that has the corresponding public key installed.
For example:
%ssh-agentcsh%ssh-addEnter passphrase for key '/usr/home/user/.ssh/id_rsa':%
| Enter the passphrase for the key. |
To use ssh-agent in
Xorg, add an entry for it in
~/.xinitrc. This provides the
ssh-agent services to all programs
launched in Xorg. An example
~/.xinitrc might look like this:
exec ssh-agent startxfce4This launches ssh-agent, which in
turn launches XFCE, every time
Xorg starts. Once
Xorg has been restarted so that
the changes can take effect, run ssh-add
to load all of the SSH keys.
OpenSSH has the ability to create a tunnel to encapsulate another protocol in an encrypted session.
The following command tells ssh to
create a tunnel for
telnet:
%ssh -2 -N -f -L5023:localhost:23 user@foo.example.com%
This example uses the following options:
-2Forces
sshto use version 2 to connect to the server.-NIndicates no command, or tunnel only. If omitted,
sshinitiates a normal session.-fForces
sshto run in the background.-LIndicates a local tunnel in
localport:remotehost:remoteportformat.user@foo.example.comThe login name to use on the specified remote SSH server.
An SSH tunnel works by creating a
listen socket on localhost on the
specified localport. It then forwards
any connections received on localport via
the SSH connection to the specified
remotehost:remoteport. In the example,
port 5023 on the client is forwarded to
port 23 on the remote machine. Since
port 23 is used by telnet, this
creates an encrypted telnet
session through an SSH tunnel.
This method can be used to wrap any number of insecure TCP protocols such as SMTP, POP3, and FTP, as seen in the following examples.
%ssh -2 -N -f -Luser@mailserver.example.com's password:5025:localhost:25 user@mailserver.example.com*****%telnet localhost 5025Trying 127.0.0.1... Connected to localhost. Escape character is '^]'. 220 mailserver.example.com ESMTP
This can be used in conjunction with
ssh-keygen and additional user accounts
to create a more seamless SSH tunneling
environment. Keys can be used in place of typing a
password, and the tunnels can be run as a separate
user.
In this example, there is an SSH server that accepts connections from the outside. On the same network resides a mail server running a POP3 server. To check email in a secure manner, create an SSH connection to the SSH server and tunnel through to the mail server:
%ssh -2 -N -f -Luser@ssh-server.example.com's password:2110:mail.example.com:110 user@ssh-server.example.com******
Once the tunnel is up and running, point the email
client to send POP3 requests to
localhost on port 2110. This
connection will be forwarded securely across the tunnel to
mail.example.com.
Some firewalls filter both incoming and outgoing connections. For example, a firewall might limit access from remote machines to ports 22 and 80 to only allow SSH and web surfing. This prevents access to any other service which uses a port other than 22 or 80.
The solution is to create an SSH connection to a machine outside of the network's firewall and use it to tunnel to the desired service:
%ssh -2 -N -f -Luser@unfirewalled-system.example.org's password:8888:music.example.com:8000 user@unfirewalled-system.example.org*******
In this example, a streaming Ogg Vorbis client can now
be pointed to localhost port
8888, which will be forwarded over to
music.example.com on port 8000,
successfully bypassing the firewall.
In addition to providing built-in SSH client utilities, a FreeBSD system can be configured as an SSH server, accepting connections from other SSH clients.
To see if sshd is operating, use the service(8) command:
#service sshd status
If the service is not running, add the following line to
/etc/rc.conf.
sshd_enable="YES"
This will start sshd, the daemon program for OpenSSH, the next time the system boots. To start it now:
#service sshd start
The first time sshd starts on a FreeBSD system, the system's host keys will be automatically created and the fingerprint will be displayed on the console. Provide users with the fingerprint so that they can verify it the first time they connect to the server.
Refer to sshd(8) for the list of available options when starting sshd and a more complete discussion about authentication, the login process, and the various configuration files.
At this point, the sshd should be available to all users with a username and password on the system.
While sshd is the most widely used remote administration facility for FreeBSD, brute force and drive by attacks are common to any system exposed to public networks. Several additional parameters are available to prevent the success of these attacks and will be described in this section.
It is a good idea to limit which users can log into the
SSH server and from where using the
AllowUsers keyword in the
OpenSSH server configuration file.
For example, to only allow root to log in from
192.168.1.32, add
this line to /etc/ssh/sshd_config:
AllowUsers root@192.168.1.32
To allow admin
to log in from anywhere, list that user without specifying an
IP address:
AllowUsers admin
Multiple users should be listed on the same line, like so:
AllowUsers root@192.168.1.32 admin
After making changes to
/etc/ssh/sshd_config,
tell sshd to reload its
configuration file by running:
#service sshd reload
Note:
When this keyword is used, it is important to list each user that needs to log into this machine. Any user that is not specified in that line will be locked out. Also, the keywords used in the OpenSSH server configuration file are case-sensitive. If the keyword is not spelled correctly, including its case, it will be ignored. Always test changes to this file to make sure that the edits are working as expected. Refer to sshd_config(5) to verify the spelling and use of the available keywords.
In addition, users may be forced to use two factor
authentication via the use of a public and private key. When
required, the user may generate a key pair through the use
of ssh-keygen(1) and send the administrator the public
key. This key file will be placed in the
authorized_keys as described above in
the client section. To force the users to use keys only,
the following option may be configured:
AuthenticationMethods publickey
Tip:
Do not confuse /etc/ssh/sshd_config
with /etc/ssh/ssh_config (note the
extra d in the first filename). The
first file configures the server and the second file
configures the client. Refer to ssh_config(5) for a
listing of the available client settings.