Understanding SSH | Apple Training Series: Mac OS X System Administration Reference, Volume 1

In its simplest sense, SSH (Secure Shell), is a secure login replacement for rlogin, ensuring that the remote connection is completely encrypted, and that the password used for authentication is not sent in clear text.

However, SSH is much more than a replacement for Telnet, although it does not duplicate the non-SSL socket access tests, for which Telnet is still very useful.

On Mac OS X and Mac OS X Server, SSH is implemented using the open-source implementation OpenSSH.

Enabling the sshd Daemon

The daemon that enables SSH functionality is sshd, which must be running on the remote host that you would like to log in to. The sshd daemon listens on port 22, so this port must be available (not blocked by a firewall) for those clients that wish to connect.

The current protocol version for SSH is version 2. Version 1 has some known security holes and should be avoided. Note that, by default, an SSH client attempting to connect to an sshd remote host will attempt to use version 2, but if it is unsuccessful (because the remote host does not support version 1), the client will then attempt a connection using protocol version 1. As a result, for best security, you should force SSH to only use version 2. (See "Advanced SSH" in this lesson.).

To enable sshd on Mac OS X (it is automatically enabled when you install Mac OS X Server) using System Preferences, follow these steps:

In System Preferences, open the Sharing pane.

If the padlock is locked, click it and authenticate.

Verify that Remote Login is selected.

Note that if you have a firewall enabled, Mac OS X automatically will open port 22 through the firewall, but this is not the case on Mac OS X Server.

On Mac OS X Server, you can also enable sshd through the Server Admin application:

1.	Launch Server Admin.
2.	In the Computers & Services list on the left, click the hostname of the server.
3.	Click the Settings button.
4.	Click the General button.
5.	Select the SSH checkbox in the Protocols section and click Save.

Note that there is no way to enable Telnet access into a Mac OS X or Mac OS X Server machine using the GUI. This is intentional, because Telnet access into your machine should not be enabled.

Using SSH in Place of Telnet

When used as a replacement for the remote login capabilities of Telnet, SSH has a very similar syntax, requiring a remote hostname or IP address, and an optional user name. With Telnet syntax, which is very straightforward, a user can specify the remote hostname that he or she wishes to log in to, and optionally the remote user name:

Telnet remotehost

Telnet remotehost l username

If the user name is omitted, you will be prompted to enter a user name.

If you authenticate successfully, you will then have a login shell on the remote machine. However, as mentioned earlier, not only is your entire session unencrypted and easily snooped, both the user name and the password are sent across the network to remotehost in clear text!

Now compare this with SSH syntax:

ssh remotehost

With this syntax, the user name is not explicitly specified, and unlike Telnet, you will not be prompted for a user name. SSH will assume you want to log in to the remote computer using the same login name that is currently used for your local login (which may or may not be a correct assumption).

To specify the user name explicitly, use the following syntax:

ssh remotehost -l username

ssh username@remotehost

Both syntax versions are equivalent in functionality; you may use whichever syntax you prefer: "Telnet-style" with the -l, or "email-style" with the @.

Let's assume that you have SSH access to a remote host called host.pretendco.com as the user scott for the following exercise:

1.	Enter a command-line shell and type the following: ssh scott@host.pretendco.com
2.	Enter the password (it will not be echoed to the screen).

Upon initial installation of SSH, or upon your first usage of it, a hidden folder is created in your home folder called .ssh. This folder is used by your client SSH process to access information it needs, which you will learn later in this section.

When you attempt to log in to a remote computer with SSH for the first time, a warning appears:

The authenticity of host 'host.pretendco.com (10.1.0.1)' can't be established. RSA key fingerprint is aa:06:48:3d:d3:d3:1a:c2:d3:de:de:72:97:d3:90:d3. Are you sure you want to continue connecting (yes/no)?

This indicates that your client has never connected to the remote host before. If you answer "yes," a copy of the remote host's public key is placed into ~/.ssh/known_hosts.

At your next login attempt using SSH, you won't be asked this question again because SSH sees that host key in the known_hosts file.

At a later time, when connecting to a familiar host (a host you've previously used with its host key previously placed into the known_hosts file ~/.ssh/known_hosts), you may see a warning that they keys are different.

This indicates that the host key returned by the remote host is not the same as the one that is stored in your known_hosts file. Ordinarily, this could simply mean that the remote host now has a different property (such as a new IP address). In the worst case, you may be the victim of a "sshmitm" or "ettercap" man-in-the-middle attack, and this warning should be taken very seriously.

powerbook:~ local$ ssh scott@host.pretendco.com @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!@ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is 34:84:47:e9:8d:1d:43:1e:dc:4c:e1:14:61:15:2a:1a. Please contact your system administrator. Add correct host key in /Users/local/.ssh/known_hosts to get rid of this message. Offending key in /Users/local/.ssh/known_hosts:1 RSA host key for host.pretendco.com has changed and you have requested strict checking. Host key verification failed. powerbook:~ local$

The SSH protocol comes in two versions, ssh1 and ssh2. ssh1 has known cryptographic weaknesses: Tools like Cain & Abel or Ettercap can decrypt ssh1 connections in real time, so you should use ssh2 only when connecting to another computer. However, by default, OpenSSH uses ssh2 but falls back on ssh1 if the client or server understands only ssh1. Attack tools can conduct a protocol downgrade attack and trick a client into thinking a server understands only ssh1, thus opening up the connection to snooping.

There are several ways to force OpenSSH to use only ssh2, depending on how much control you have over the target computer.

For a Mac OS X Server where you have admin privileges:

In the file /etc/sshd_config, uncomment (or add) the line
```
#Protocol 2,1 to read Protocol 2
```
and restart ssh. This will force any computers to connect using the ssh2 protocol. The server will not accept ssh1-based connections.

On a Mac OS X computer where you have admin privileges:

In the file /etc/ssh_config, uncomment (or add) the line
```
#Protocol 2,1 to read Protocol 2
```
This will make any connections from the Mac OS X computer use the ssh2 protocol only. If the server does not understand the ssh2 protocol, the Mac OS X computer will not make a connection.

On a Mac OS X computer where you do not have admin privileges but can change your own SSH preferences:

In the file ~/.ssh/ssh_config, uncomment (or add) the line
```
#Protocol 2,1 to read Protocol 2
```
This will make any connections from the Mac OS X computer initiated by the current user ssh2 only. If the server does not understand the ssh2 protocol, the Mac OS X computer will not make a connection.

On a Mac OS X computer where you cannot or should not make changes to the user's SSH preferences (perhaps because you are using someone else's system):

When you type in the ssh command line, add the -2 flag
```
ssh -2 ...other arguments to ssh
```
This will make this connection attempt ssh2 only. It will not affect other connections by this user or those from other users.
Note

You can ssh into Mac OS X Server from any SSH client on any type of operating system. These steps can be applied to any configuration file of OpenSSH to disable ssh1 and use only ssh2.

Using SCP

With the Secure Copy (SCP) program, a replacement for RCP, a user can copy any file from a local host to a remote one, or vice versa, over a secure, encrypted SSH connection.

For instance, to copy a file from our local machine to a remote host that has SSH enabled, use the following syntax:

scp local_filename user@hostname:remote_path

where local_filename is the name of the local file you wish to copy, user@hostname is the SSH syntax for logging in to a remote host, and remote_path is the path on the remote server where you want to place the file.

If a connection is allowed, you will be prompted for your password (unless you have enabled public/private key authentication, discussed later).

Try this out with the following exercise:

Enter a command-line shell and navigate to your home folder:

cd ~

Create a file using a text editor called myfile.txt:

vi myfile.txt

Securely copy myfile.txt to the remote server host.pretendco.com as the user scott to scott's desktop:

scp myfile.txt scott@host.pretendco.com:~/Desktop

Using sftp

Quite a bit of Internet file transfer is done using FTP, which has been around for a long time. FTP is available on just about every Internet-connected host, but since the authentication password is sent in clear text, you should avoid using FTP. (This is not such an issue for public FTP sites, where the password may be nonexistent or known by many users. However, any clear text password is insecure, and publicly-known passwords are worse.)

To allow sftp access, a host must be running only the sshd daemon, and port 22 (SSH) must be accessible through any firewall to the clients.

Fugu is an application from the University of Michigan that permits only SCP and sftp connections to be made to remote servers.

Advanced SSH

The ability to log in to a remote host over a secure connection using a login/password isn't only one way to use SSH. In this section, you will see advanced SSH techniques.

More Info

See the man page for SSH for more information or clarification.

Forcing SSH to Use Only Version 2 of the Protocol

In order to force SSH to connect using only protocol version 2, include the 2 argument by entering

ssh -2 username@remotehost

You can also choose Connect to Server from the File menu in the Terminal application to discover local computers that can be connected to via the following:

SSH
SFTP
FTP
Telnet

The only secure connections, of course, would be SSH and SFTP.

Using SSH Authentication with Public/Private Keys

In addition to standard login/password authentication, you can set up a public/private (also known as asymmetric) key authentication mechanism with SSH that allows a user to create a SSH connection without entering his or her password for each login. Through the .rhost file, Telnet and rlogin users are able to semi-automate their login processes, but there are major security risks in using that method, because it is host-based, not public/ private key-based (see man hosts.equiv).

One of the main benefits of using the command-line interface is the ability to automate tasks through scripting. Often, it is desirable to have a script log in remotely to a system and perform a task (such as installing software or software updates, or performing security audits). If you want to use SSH, you need a means for the script to log in to a remote host without providing a password, because SSH does not allow scripts to send passwords via a command-line argument. (This is a good feature because you should not store passwords in scripts unless it is otherwise unavoidable.)

With public/private key authentication with SSH, users and scripts (which all run as users) can remotely access a computer without having to enter a password. In order to use public/private key authentication, you must create a public/private key pair. This is done with the OpenSSH ssh-keygen program. Once the keys are generated, you need to move them to the correct places.

Move your private key into the location where SSH needs to find it, but only on your local machine. Never share your private keyif someone obtains a copy of your private key, he or she can log in to the remote machine with your matching public key without having to enter a password!

When you think of encryption, you usually think of encrypting a message with a key, and then using that same key to decrypt a message, kind of like putting messages in a diary with a lock on it, mailing the diary, and having someone else unlock it with a copy of the key. So to send encrypted messages to a friend, each person has to have a copy of the same key. But how do you get that key to the other person without a third person making a copy of the key and also using it to decrypt messages?

Through the miracle of mathematics, it is possible to generate two differentbut relatedkeys: one that can encrypt and one that can decrypt. It is not possible to use the same key to both encrypt and decrypt a messagein other words, if one person locks the diary with one key, the same key cannot be used to unlock itonly the other key can be used. This may be counterintuitive, but the fact that this type of technology exists is very important.

In public/private key encryption, as the title states, two keys are generatedone shared with the public and one kept private. To send a person an encrypted message, lock it up with his or her public key, and send the message. Since only his or her private key, and not the public key, can unlock the message, it is safeonly the recipient of the message has the private key.

More Info

For more information on Public/Private key encryption, see http://www.webopedia.com/TERM/P/public_key_cryptography.html.

The first part of this exercise involves generating the two keys:

1.	Enter a command-line shell and type ssh-keygen t dsa
2.	When asked where to save the file, press Return. This will save the two generated keys in ~/.ssh.
3.	Enter a passphrase, which can further help prevent users from gaining access to your computer: Even if they get the private key, they will need your passphrase. Two files are generated: ~/.ssh/id_dsa.pub (your public key) and ~/.ssh/id_dsa (your private key).

The next thing to do is copy your public key to the account and host you want to be able to log in to. An easy and secure way to do this is to use the SCP command:

1.	Move the public key to the home directory of the user (scott, in this example) on the server you want to be able to log in to using SCP (place it on the desktop for now, and then move it into the right place later): scp ~/.ssh/id_dsa.pub scott@host.pretendco.com:~/Desktop/local_dsakey.pub Make sure you are copying the public key (ending in .pub), not the private key (with no file extension).
2.	Log in to the remote server: ssh scott@host.pretendco.com
3.	Make sure that the .ssh folder exists in the user's home folder. If not, create an empty one.
4.	Append the key just copied up into the user's ~/.ssh/ authorized_keys files (or create it if it doesn't exist): cat ~/Desktop/ local_dsakey.pub >> ~/.ssh/authorized_keys
5.	Log out of the remote server: exit If all went well, you will now be able to log in to the remote account without having to enter a password; however, if you used a passphrase, you will still need to enter that passphrase.

Disabling Root SSH Logins

By default, if SSH is enabled on Mac OS X or Mac OS X Server, root SSH login is also enabled. Many consider this to be a huge security risk. In this exercise, you will learn how to disable root logins from an SSH-enabled machine:

1.	Using a text editor, open the file /etc/sshd_config.
2.	Find the following line: #PermitRootLogin yes
3.	Uncomment the line by removing the `#` sign.
4.	Replace the word `yes` with `no`.
5.	Save the file.
6.	Restart `sshd`.

Note that certain services in Mac OS X and Mac OS X Server, such as Open Directory Replication, require root SSH login access, so you may want to consider whether or not you want to do this on your host.

Using SSH Tunneling

In addition to superceding the abilities and security of Telnet, SSH also has the ability to create an SSH tunnel, which is a way of forwarding information from one port to another, on different hosts, over a secure, encrypted SSH connection.

One limitation of SSH tunneling is that only the TCP protocol is supported. Other protocols, such as UDP, ICMP, and so on, are not.

Local-to-Remote SSH Tunneling

Sending email outside of your normal network is a common use of an SSH tunnel. For example, a frequent traveler, concerned that the local ISP connection is not trustworthy, may not want to risk using his or her SMTP server for outgoing mail. He or she may have a trustworthy SMTP server on the home office network, but may not wish to expose that SMTP server to the world (port 25 is blocked by a firewall rule). If sshd is running on the home office server, he or she can create an SSH tunnel to utilize that SMTP service, even if it is not externally available, by linking a local port (which a local service can easily communicate with) to a remote port through an encrypted SSH connection.

This type of tunnel is referred to as a local-to-remote tunnel, since you are creating a port on your local computer, which will be forwarding requests (and responses) to (and from) a remote port on another computer. You then configure your local applications to communicate not with a remote port directly, but with the local port that has been assigned a connection to the remote port via the SSH tunnel.

Because you are creating a local port connection to a remote port, you need to ensure that the local port you decide to use is not already assigned for local services. (Refer to /etc/services for a list of well-known ports, or use the netstat an command to see what ports are currently being used on your machine.)

In the following exercise, you will set up a local-to-remote SSH tunnel between your machine and a remote mail server in order to use the remote mail server's SMTP services.

The remote mail server hostname is mail.pretendco.com, and its SMTP service is not accessible via the public Internet because a firewall is blocking port 25. In fact, it is an internal server and has no connection to the public Internetit is not running sshd.

A gateway server exists, which has access to the public Internet and also to the internal network. This gateway host, named gateway.pretendco.com, is running sshd and is accessible through the firewall since port 22 is open. You have a login account on the gateway host called scott. (Any account can be used.)

First create the SSH tunnel connecting your local host's port 2525 (currently unused) to the remote mail server host's port 25 (where it is listening for SMTP requests).

Then configure your mail client application to not use SMTP service from a remote host as you normally would, but to instead link to local port 2525 by using the hostname localhost (which always refers to your local machine) and specify the local port that you used when creating the SSH tunnel.

Refer to the following figure for an illustration of this exercise. (The exercise steps do not correlate directly to the steps in the diagram.)

Open a command-line shell on the local machine and execute the following command:

ssh L 2525:mail.pretendco.com:25 scott@gateway.pretendco.com

This will create the SSH tunnel, as shown in step 1 of the figure.

L creates a local-to-remote tunnel.

2525 refers to the local port you wish to assign to the remote host port:

mail.pretendco.com:25.

scott@gateway.pretendco.com is the machine that will be used to create the SSH tunnel; it is running an sshd that you have access to from the external network, and it has access to the host mail.pretendco.com internally.

Note

You can make this tunnel persistent and work in the background. (See the man page for SSH, specifically the f option.)

Configure your email program to use port 2525 on localhost for SMTP services (step 2 in the figure).

Steps 3 and 4 in the figure illustrate the flow of information once the tunnel has been created.

By merely substituting some port numbers, you can apply the preceding exercise to not only other mail services such as POP (on port 110) or IMAP (port 143), but to any service that is running on a port on an internal host. And remember, even though your local applications believe they are communicating with a local port, each request/response is actually sent to/from a remote host over an encrypted connection.

Remote-to-Local SSH Tunneling

In addition to creating a tunnel from your Mac to another computer, you can also create a tunnel in reverse. You can forward information intended for a remote socket over a secure SSH connection to your local system.

Why might it be useful to create a tunnel in reverse? Perhaps your consulting company is working on a top-secret website for PretendCo, and you wish to share your latest version with them. They are unable to visit you, and for security reasons, you do not want to open up a connection through your firewall to allow them access (since you would also be allowing access to others, and there will be upcoming product announcements that you do not want to leak to the press). No problema remote-to-local SSH tunnel is just what you need to allow them access remotely to your local site through an encrypted SSH tunnel.

In the following exercise, you will create a tunnel at your consulting firm, which shares the internal Web host internal.vendor.com with the remote host gateway.pretendco.com. Upon execution of the remote-to-local SSH command, port 8080 on gateway.pretendco.com (the remote host) will actually be a reference to an SSH tunnel to port 80 on internal.vendor.com (the local host), utilizing the SSH process running on your local machine and the sshd process running on gateway.pretendco.com.

Open a command-line shell on the local machine and execute the following command:
```
ssh R 8080:internal.vendor.com:80 scott@gateway.pretendco.com
```
This will create the SSH tunnel, as shown in step 1 of the figure.
```
R creates a remote-to-local tunnel.
```
8080 refers to the remote port you want to assign to the local host port:
```
internal.vendor.com:80.
```
scott@gateway.pretendco.com is the machine that will be used to create the SSH tunnelit is running an sshd that the local machine's SSH process has access to from the external network, and it can be accessed by internal hosts at PretendCo.
Note

You can make this tunnel persistent and work in the background. (See the man page for SSH, specifically the f option.)

Any internal client on the PretendCo network can now access gateway.pretendco. com:8080 to send requests (and get responses) from internal.vendor.com:80 through an encrypted SSH tunnel (step 2 in the figure).
Steps 3 and 4 in the figure illustrate the flow of information once the tunnel has been created.

As in a local-to-remote tunnel, you can apply the technique shown in this exercise to other ports for similar results.

SSH Tunneling of AFP

The Mac OS X Finder supports creating SSH tunnels for Apple Filing Protocol (AFP), ensuring that your AFP traffic is sent encrypted over the network.

When making a connection to an AFP server using the Finder's Connect To Server menu option, a request can be made to create an SSH tunnel for that connection using the Options pane, as shown in the following exercise:

1.	From the Finder, choose Go > Connect To Server.
2.	Select an AFP site to connect to.
3.	When presented with the Authentication dialog, instead of immediately authenticating, click Options.
4.	Select the "Allow secure connections using SSH" checkbox to use an SSH tunnel.

If the remote server supports an AFP SSH tunnel, you will be connected automatically. If the tunnel cannot be created for some reason, a dialog will appear asking you if you would like to use a non-SSH tunnel.

Note

There isn't really an slogin program; it is a symbolic link to the standard SSH command, for those who are migrating from using rlogin and prefer to use the name slogin.