Contributed by Chern Lee.
OpenSSH is a set of network connectivity tools used to
access remote machines securely. It can be used as a direct replacement for rlogin, rsh, rcp,
and telnet. Additionally, TCP/IP connections can be
tunneled/forwarded securely through SSH. OpenSSH encrypts all
traffic to effectively eliminate eavesdropping, connection hijacking, and other
network-level attacks.
OpenSSH is maintained by the OpenBSD project, and is based
upon SSH v1.2.12 with all the recent bug fixes and updates. It is compatible with both
SSH protocols 1 and 2.
Normally, when using telnet(1) or rlogin(1), data is
sent over the network in a clear, un-encrypted form. Network sniffers anywhere in between
the client and server can steal your user/password information or data transferred in
your session. OpenSSH offers a variety of authentication and
encryption methods to prevent this from happening.
The sshd is an option presented during a Standard install of FreeBSD. To see if sshd is enabled, check the rc.conf file
for:
sshd_enable="YES"
This will load sshd(8), the daemon
program for OpenSSH, the next time your system initializes.
Alternatively, it is possible to use /etc/rc.d/sshd rc(8) script to start
OpenSSH:
/etc/rc.d/sshd start
The ssh(1) utility works
similarly to rlogin(1).
# ssh [email protected]
Host key not found from the list of known hosts.
Are you sure you want to continue connecting (yes/no)? yes
Host 'example.com' added to the list of known hosts.
[email protected]'s password: *******
The login will continue just as it would have if a session was created using rlogin or telnet. SSH utilizes a key
fingerprint system for verifying the authenticity of the server when the client connects.
The user is prompted to enter yes only when connecting for the
first time. Future attempts to login are all verified against the saved fingerprint key.
The SSH client will alert you if the saved fingerprint differs from the received
fingerprint on future login attempts. The fingerprints are saved in ~/.ssh/known_hosts, or ~/.ssh/known_hosts2 for SSH v2 fingerprints.
By default, recent versions of the OpenSSH servers only
accept SSH v2 connections. The client will use version 2 if possible and will fall back
to version 1. The client can also be forced to use one or the other by passing it the
-1 or -2 for version 1 or version
2, respectively. The version 1 compatibility is maintained in the client for backwards
compatibility with older versions.
The scp(1) command works
similarly to rcp(1); it copies a
file to or from a remote machine, except in a secure fashion.
# scp [email protected]:/COPYRIGHT COPYRIGHT
[email protected]'s password: *******
COPYRIGHT 100% |*****************************| 4735
00:00
#
Since the fingerprint was already saved for this host in the previous example, it is
verified when using scp(1) here.
The arguments passed to scp(1) are similar to
cp(1), with the file
or files in the first argument, and the destination in the second. Since the file is
fetched over the network, through SSH, one or more of the file arguments takes on the
form user@host:<path_to_remote_file>.
The system-wide configuration files for both the OpenSSH
daemon and client reside within the /etc/ssh directory.
ssh_config configures the client settings, while sshd_config configures the daemon.
Additionally, the sshd_program (/usr/sbin/sshd by default), and sshd_flags rc.conf options can provide
more levels of configuration.
Instead of using passwords, ssh-keygen(1) can be
used to generate DSA or RSA keys to authenticate a user:
% ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_dsa):
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_dsa.
Your public key has been saved in /home/user/.ssh/id_dsa.pub.
The key fingerprint is:
bb:48:db:f2:93:57:80:b6:aa:bc:f5:d5:ba:8f:79:17 [email protected]
ssh-keygen(1) will
create a public and private key pair for use in authentication. The private key is stored
in ~/.ssh/id_dsa or ~/.ssh/id_rsa,
whereas the public key is stored in ~/.ssh/id_dsa.pub or ~/.ssh/id_rsa.pub, respectively for DSA and RSA key types. The
public key must be placed in the ~/.ssh/authorized_keys file of
the remote machine for both RSA or DSA keys in order for the setup to work.
This will allow connection to the remote machine based upon SSH keys instead of
passwords.
If a passphrase is used in ssh-keygen(1), the
user will be prompted for a password each time in order to use the private key. ssh-agent(1) can
alleviate the strain of repeatedly entering long passphrases, and is explored in the Section 14.11.7 section below.
Warning: The various options and files can be different according to the OpenSSH version you have on your system; to avoid problems you
should consult the ssh-keygen(1) manual
page.
The ssh-agent(1) and ssh-add(1) utilities
provide methods for SSH keys to be loaded into memory for use,
without needing to type the passphrase each time.
The ssh-agent(1) utility
will handle the authentication using the private key(s) that are loaded into it. ssh-agent(1) should be
used to launch another application. At the most basic level, it could spawn a shell or at
a more advanced level, a window manager.
To use ssh-agent(1) in a
shell, first it will need to be spawned with a shell as an argument. Secondly, the
identity needs to be added by running ssh-add(1) and
providing it the passphrase for the private key. Once these steps have been completed the
user will be able to ssh(1) to any host
that has the corresponding public key installed. For example:
% ssh-agent csh
% ssh-add
Enter passphrase for /home/user/.ssh/id_dsa:
Identity added: /home/user/.ssh/id_dsa (/home/user/.ssh/id_dsa)
%
To use ssh-agent(1) in X11, a
call to ssh-agent(1) will need
to be placed in ~/.xinitrc. This will provide the ssh-agent(1) services
to all programs launched in X11. An example ~/.xinitrc file
might look like this:
exec ssh-agent startxfce4
This would launch ssh-agent(1), which
would in turn launch XFCE, every time X11 starts. Then once
that is done and X11 has been restarted so that the changes can take effect, simply run
ssh-add(1) to load all
of your SSH keys.
OpenSSH has the ability to create a tunnel to encapsulate
another protocol in an encrypted session.
The following command tells ssh(1) to create a
tunnel for telnet:
% ssh -2 -N -f -L 5023:localhost:23 [email protected]
%
The ssh command is used with the following options:
-2-
Forces ssh to use version 2 of the protocol. (Do not use if
you are working with older SSH servers)
-N-
Indicates no command, or tunnel only. If omitted, ssh would
initiate a normal session.
-f-
Forces ssh to run in the background.
-L-
Indicates a local tunnel in localport:remotehost:remoteport fashion.
[email protected]-
The remote SSH server.
An SSH tunnel works by creating a listen socket on localhost
on the specified port. It then forwards any connection received on the local host/port
via the SSH connection to the specified remote host and port.
In the example, port 5023 on localhost is being forwarded to port 23 on localhost of the remote
machine. Since 23 is telnet, this would create a secure telnet session through an SSH tunnel.
This can be used to wrap any number of insecure TCP protocols such as SMTP, POP3, FTP,
etc.
Example 14-1. Using SSH to Create a Secure Tunnel for SMTP
% ssh -2 -N -f -L 5025:localhost:25 [email protected]
[email protected]'s password: *****
% telnet localhost 5025
Trying 127.0.0.1...
Connected to localhost.
Escape character is '^]'.
220 mailserver.example.com ESMTP
This can be used in conjunction with an ssh-keygen(1) and
additional user accounts to create a more seamless/hassle-free SSH tunneling environment.
Keys can be used in place of typing a password, and the tunnels can be run as a separate
user.
At work, there is an SSH server that accepts connections from the outside. On the same
office network resides a mail server running a POP3 server. The network, or network path
between your home and office may or may not be completely trustable. Because of this, you
need to check your e-mail in a secure manner. The solution is to create an SSH connection
to your office's SSH server, and tunnel through to the mail server.
% ssh -2 -N -f -L 2110:mail.example.com:110 [email protected]
[email protected]'s password: ******
When the tunnel is up and running, you can point your mail client to send POP3
requests to localhost port 2110. A connection here will be
forwarded securely across the tunnel to mail.example.com.
Some network administrators impose extremely draconian firewall rules, filtering not
only incoming connections, but outgoing connections. You may be only given access to
contact remote machines on ports 22 and 80 for SSH and web surfing.
You may wish to access another (perhaps non-work related) service, such as an Ogg
Vorbis server to stream music. If this Ogg Vorbis server is streaming on some other port
than 22 or 80, you will not be able to access it.
The solution is to create an SSH connection to a machine outside of your network's
firewall, and use it to tunnel to the Ogg Vorbis server.
% ssh -2 -N -f -L 8888:music.example.com:8000 [email protected]
[email protected]'s password: *******
Your streaming client can now be pointed to localhost port
8888, which will be forwarded over to music.example.com port
8000, successfully evading the firewall.
It is often a good idea to limit which users can log in and from where. The AllowUsers option is a good way to accomplish this. For example, to
only allow the root user to log in from 192.168.1.32, something like this would be appropriate in the /etc/ssh/sshd_config file:
AllowUsers [email protected]
To allow the user admin to log in from anywhere, just list
the username by itself:
AllowUsers admin
Multiple users should be listed on the same line, like so:
AllowUsers [email protected] admin
Note: It is important that you list each user that needs to log in to this
machine; otherwise they will be locked out.
After making changes to /etc/ssh/sshd_config you must tell
sshd(8) to reload its
config files, by running:
# /etc/rc.d/sshd reload
