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.

To see if sshd(8) is enabled, check /etc/rc.conf for this line:

This will start sshd(8), the daemon program for OpenSSH, the next time the system initializes. Alternatively, it is possible to use service(8) to start OpenSSH now:

To use ssh(1) to connect to a system running sshd(8), specify the username and host to log into:

SSH utilizes a key fingerprint system to verify the authenticity of the server when the client connects. The user is prompted to type yes when connecting for the first time. Future attempts to login are verified against the saved fingerprint key and the ssh(1) client will display an alert if the saved fingerprint differs from the received fingerprint on future login attempts. The fingerprints are saved in ~/.ssh/known_hosts.

By default, recent versions of sshd(8) 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.

Use scp(1) to copy a file to or from a remote machine in a secure fashion.

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 to copy in the first argument, and the destination in the second. Since the file is fetched over the network, through an SSH, connection, one or more of the file arguments takes the form user@host:<path_to_remote_file>.

The system-wide configuration files for both the OpenSSH daemon and client reside in /etc/ssh.

ssh_config configures the client settings, while sshd_config configures the daemon. Each file has its own manual page which describes the available configuration options.

Instead of using passwords, ssh-keygen(1) can be used to generate DSA or RSA keys to authenticate a user:

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 the DSA and RSA key types. The public key must be placed in ~/.ssh/authorized_keys on the remote machine for both RSA or DSA keys in order for the setup to work.

This setup allows connections 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 the passphrase 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 Section 15.10.7, “Using SSH Agent to Cache Keys”.

To load SSH keys into memory for use, without needing to type the passphrase each time, use ssh-agent(1) and ssh-add(1).

Authentication is handled by ssh-agent(1), using the private key(s) that are loaded into it. Then, ssh-agent(1) should be used to launch another application. At the most basic level, it could spawn a shell or a window manager.

To use ssh-agent(1) in a shell, start it with a shell as an argument. Next, add the identity 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:

To use ssh-agent(1) in Xorg, a call to ssh-agent(1) needs to be placed in ~/.xinitrc. This provides the ssh-agent(1) services to all programs launched in Xorg. An example ~/.xinitrc might look like this:

This launches ssh-agent(1), which in turn launches XFCE, every time Xorg starts. Once Xorg has been restarted so that the changes can take effect, run ssh-add(1) 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(1) to create a tunnel for telnet(1):

This example uses the following options:

An SSH tunnel works by creating a listen socket on localhost on the specified port. It then forwards any connections 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 forwarded to port 23 on localhost of the remote machine. Since 23 is used by telnet(1), this creates an encrypted telnet(1) session through an SSH tunnel.

This can be used to wrap any number of insecure TCP protocols such as SMTP, POP3, and FTP.

It is often a good idea to limit which users can log in and from where using AllowUsers. For example, to only allow root to log in from 192.168.1.32, add this line to /etc/ssh/sshd_config:

To allow admin to log in from anywhere, list that username by itself:

Multiple users should be listed on the same line, like so:

After making changes to /etc/ssh/sshd_config, tell sshd(8) to reload its configuration file by running:

The OpenSSH website.

ssh(1), scp(1), ssh-keygen(1), ssh-agent(1), ssh-add(1), and ssh_config(5) for client options.

sshd(8), sftp-server(8), and sshd_config(5) for server options.