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, any other 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. OpenSSH has been in the base system
since FreeBSD 4.0.
Normally, when using telnet(1) or rlogin(1), data is
sent over the network in an 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.
Be sure to make the following addition to your rc.conf
file:
sshd_enable="YES"
This will load sshd(8), the daemon
program for OpenSSH, the next time your system initializes.
Alternatively, you can simply run directly the sshd daemon by
typing sshd on the command line.
The ssh(1) utility works
similarly to rlogin(1).
# ssh user@example.com
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.
user@example.com'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, OpenSSH servers are configured to accept both
SSH v1 and SSH v2 connections. The client, however, can choose between the two. Version 2
is known to be more robust and secure than its predecessor.
The ssh(1) command can be
forced to use either protocol by passing it the -1 or -2 argument for v1 and v2, respectively.
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 user@example.com:/COPYRIGHT COPYRIGHT
user@example.com'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 RSA keys to authenticate a user:
% ssh-keygen -t rsa1
Initializing random number generator...
Generating p: .++ (distance 66)
Generating q: ..............................++ (distance 498)
Computing the keys...
Key generation complete.
Enter file in which to save the key (/home/user/.ssh/identity):
Enter passphrase:
Enter the same passphrase again:
Your identification has been saved in /home/user/.ssh/identity.
...
ssh-keygen(1) will
create a public and private key pair for use in authentication. The private key is stored
in ~/.ssh/identity, whereas the public key is stored in ~/.ssh/identity.pub. The public key must be placed in ~/.ssh/authorized_keys of the remote machine in order for the setup
to work.
This will allow connection to the remote machine based upon RSA authentication instead
of passwords.
Note: The -t rsa1 option will create RSA keys for use
by SSH protocol version 1. If you want to use RSA keys with the SSH protocol version 2,
you have to use the command ssh-keygen -t rsa.
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.
A SSH protocol version 2 DSA key can be created for the same purpose by using the ssh-keygen -t dsa command. This will create a public/private DSA key
for use in SSH protocol version 2 sessions only. The public key is stored in ~/.ssh/id_dsa.pub, while the private key is in ~/.ssh/id_dsa.
DSA public keys are also placed in ~/.ssh/authorized_keys on
the remote machine.
ssh-agent(1) and ssh-add(1) are
utilities used in managing multiple passworded private keys.
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.
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 user@foo.example.com
%
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.
- user@foo.example.com
-
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 10-1. Using SSH to Create a Secure Tunnel for SMTP
% ssh -2 -N -f -L 5025:localhost:25 user@mailserver.example.com
user@mailserver.example.com'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 user@ssh-server.example.com
user@ssh-server.example.com'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 user@unfirewalled-system.example.org
user@unfirewalled-system.example.org'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.
OpenSSH
ssh(1) scp(1) ssh-keygen(1) ssh-agent(1) ssh-add(1)
sshd(8)
sftp-server(8)