SSH Primer

When you ask how you can make your BSD box more secure, the first thing people will tell you is to use SSH if you aren't already. If you are new to BSD or Unix in general, you might still be mastering the art of logging in to the console and not have given a thought to logging in remotely. If you are using Mac OS X, you may not have even realized that you can log in remotely.

When you login to the console, BSD gives you a login: prompt and asks for your user name. You are then prompted for your password. If you successfully give both, it logs you in and presents you with a shell prompt. The alternative situation is if you are using a GUI login such as xdm, kdm, or Mac OS X. The login process will be the same; however, you will be presented with a windowing system upon login instead of the shell. To get to a shell from this point, you will need to run an xterm or the Terminal App in Mac OS X, which is found in the utilities folder.

From the shell prompt, you can use the ssh utility. In its most basic form, ssh gives you secure, console access to another computer. All the traffic that goes between the two computers is encrypted so it can't be intercepted in transit. Previously a utility called telnet handled the same duties, however it did so using unencrypted protocols. It became very easy for hackers to intercept telnet sessions and discover passwords used to remotely manage systems.

OpenBSD, NetBSD, FreeBSD, Mac OS X, and Darwin all come with OpenSSH installed as part of the base installation. OpenSSH was developed by the OpenBSD project and has quickly become the de facto standard for ssh. If you don't like using ssh as a command line, people have developed GUI front ends to ssh, but I'm not covering that in this article.

SSH is a client to server application. A user invokes the client application and tells it to connect to a computer running the ssh serrver application or the ssh daemon. The ssh daemon running on the host computer listens for incoming ssh requests and establishes a connection, then grants the user a shell if the username and authentication are successful. The client must connect to a computer running the ssh daemon, or the request to connect will be unanswered. An ssh daemon cannot make requests - it just accepts them. An ssh client cannot connect to another ssh client. That would be peer-to-peer, not the client-server model. The client application is called ssh and the server application is called sshd (ssh daemon).

Connecting to a host

To connect to a server that is running ssh, simply type ssh hostname at the command line and it will initiate the connection.

> ssh sourceforge.net

  The authenticity of host 'sourceforge.net (216.136.171.196)' can't be established.
  RSA key fingerprint is bc:a2:3f:a3:b7:8f:95:ad:e4:ad:45:e8:8b:0f:23:b1.
  Are you sure you want to continue connecting (yes/no)?

Once you initiate the connection, you will be asked to verify the authenticity of the remote host. The RSA fingerprint given will be used each time you connect to verify that it is the same one you connected to last time. If this fingerprint changes, you will know someone is trying to tamper with your connection. After accepting the RSA key fingerprint, the server will attempt to authenticate who you are. There several methods of authentication. The most common method is using your username and password.

Warning: Permanently added 'sourceforge.net,216.136.171.196' (RSA) to the list of known hosts.
  root@sourceforge.net's password: 

After typing in your password successfully, you will be granted a shell on the server you connected to. From there, all the commands you enter will be executed on the remote server. It will be as though you physically logged into the console of the computer you are connecting to. It's very handy for remote administration.

User Names

What if the username on the machine you are currently using doesn't match your username on the computer you want to connect to? You have two options. You can pass the -l option to ssh and give your user name.

> ssh -l someone sourceforge.net 

someone@sourceforge.net's password: 

Or you can put the username in front of the hostname using an @ symbol.

> ssh someone@sourceforge.net
  someone@sourceforge.net's password: 

The result is the same. The syntax for connecting is extremely simple and you can substitute IP addresses for hostnames if necessary.

Turning on SSH

On most BSD computers, turning on ssh will be as simple as editing the /etc/rd.conf file.

> vi /etc/rc.conf

Then add or edit this line to look as follows:

sshd_enable="YES"                # Enable sshd

This will enable sshd to start at boot up. However, starting ssh could be as simple as typing sshd as root.

> su root
  Password:
  # sshd

However the ssh keys will need to be present in /etc/ before that will work. The rc scripts will automatically create them the first time you boot. Or you can create them yourself with these commands.

/usr/bin/ssh-keygen -N "" -f /etc/ssh/ssh_host_key
  /usr/bin/ssh-keygen -d -N "" -f /etc/ssh/ssh_host_dsa_key

For Mac OS X users, all you have to do is go to the system preferences and under the sharing tab, select Application and check the allow remote login box. SSH has been the default for remote login since Mac OS X 10.0.1. It came in the first patch to Mac OS X.

Once sshd is running, you should be able to verify it using ps or top.

> ps -ax | grep sshd
  1004  ??  Ss     0:00.37 /usr/sbin/sshd

Now your computer is set up as a host that you should be able to connect to with an ssh client. When connecting to the computer, be sure to use a username and password that exist on that computer, or you will not be able to login.

The username/password scheme isn't the most secure method. You can authenticate to the remote server using ssh keys. However this method requires some setup beforehand.

First, you need to create a set of ssh keys on your client computer.

> ssh-keygen -t dsa -f ~/.ssh/identity
  Generating public/private dsa key pair.
  Created directory '/Users/maxh/.ssh'.
  Enter passphrase (empty for no passphrase): 
  Enter same passphrase again: 
  Your identification has been saved in /Users/maxh/.ssh/identity.
  Your public key has been saved in /Users/maxh/.ssh/identity.pub.
  The key fingerprint is:
  1e:6e:63:c1:f7:31:6c:6f:1b:65:eb:44:1f:fb:7f:c3 maxh@localhost

This will create two files in ~/.ssh

> ls -l ~/.ssh
  -rw-------   1 maxh  staff  668 May  1 23:19 identity
  -rw-r--r--   1 maxh  staff  606 May  1 23:19 identity.pub

The identity file is your private key. You should keep that safe. The identity.pub key is your public key and you can freely give that to your friends.

To use these keys as authentication, you will need to put the identity.pub file on the remote computer that you want to connect to. The may require help from that computes system administrator.

On the remote computer, create ~/.ssh/authorized_keys and ~/.ssh/authorized_keys2. The RSA keys go into the authorized_keys file and the DSA keys go into the authorized_keys2 file. Each key goes on a single line.

> vi authorized_keys2

  ssh-dss AAAAB3NzaC1kc3MAAACBAO+zfz6bszuIGTYgEHLhQHql4+3A+rusWMsF2MA84dzCtHNkVjAn04J4F5GKb9ma4mhu
  9loLk31oXxrvBYgLGMeJDIN59BvPflJjGlzRbc79sftd8Ww/R6t8xt1LKz8TV2tivDjXViwo7U+b/B0693BzM1TjtLD/EDhK
  UPu8GjPzAAAAFQCVi03quuEthmzmGrAA6g+tWnX4UwAAAIBGv+iOwq8B9AQPrvG+IdShLTh6t/N9O/biX+z8bve8ESTQtu/U
  hf0hFYhXE5AyrN5I7pci9Jghhj2zZ5chKQqTvRDLAV+e7acU70trGPN4dlFs8XxshppO/Fl1AX9nMoKNEJmOIHYf9rfGO6kW
  0YqmGejzY0f/yAFFL0ewwmRnNAAAAIBJjSUN/g34slaezhf39JX2rkcAYRyuECn2faRlZrwpLFHguK9LVMCyDEqPnTgT0BzH
  Se3JjLgXFSVqJvBrhQpwLuIK0ht1sdbcBC2pAQM9+jtq9bMpLDWIk/hCWxZEnqaGhS+L/7MwSAQSQkAt97xWhS+MjPhtsVNg
  DLP8wizJJQ== maxh@localhost

You want to keep these files secure, because any public key that goes into an authorized_keys file allows the owner of the private key access to your computer!

Once this key is in place, you will be able to ssh, using the normal syntax, to this remote computer and it will attempt to authenticate you first by your ssh key.

When it does authenticate you, you will be asked for the password to unlock your local private ssh key. This is the password that you used when you generated the ssh key pair. If you didn't use a password, it won't prompt you for one. The only danger with using a blank password on a key is that if your key gets stolen they can access your remote servers.

With this information, you should be able to use ssh to connect and get a console style login to any remote computer that you have an account on, using both password and ssh key authentication.