Safe Connection

This article presents advanced Secure Shell (SSH) functionality and SSH-based tools for use on Windows. It does not question the fact that both Linux (vsftpd, proftpd) and Windows (IIS) let you operate a secure FTP server with standard tools and that there are countless secure and powerful FTP clients. The charm of SSH consists above all in being able to use remote logins, file transfers, port forwarding, VPN, and other functions ad hoc without extensive preparatory measures. For SSH, you only need to run the SSH daemon, sshd, on the (Linux) server.

SSH offers maximum security thanks to these three properties:

• Encryption of transferred data, including login information.
• Protection against manipulation of the transferred data (data integrity).
• Authentication of the communication partner.

SSH always uses transmission encryption; it can use the default host key to ensure the integrity of the connection or the hosts, and it supports peer authentication. Although SSH "only" works by default with usernames and passwords, it also optionally supports asymmetric DSA and RSA key pairs.

SSH Basics

The free Linux SSH Version, OpenSSH, is a spin-off of the classic SSH from 1999. The popular Windows SSH client PuTTY, developed by Simon Tatham, is also a free SSH implementation. It is subject to the MIT license and is currently at version 0.62 from 2011. All versions of SSH are largely compatible.

The term Secure Shell is the umbrella for a bunch of remote access tools. The entire SSH suite contains the following tools:

• ssh – Replaces rsh, rlogin, and telnet.
• scp – Replaces rcp.
• sftp – Replaces ftp.
• sshd – The SSH server daemon.
• ssh-keygen – Generates asymmetric public keys for authentication or manages or converts keys.
• ssh keyscan – Searches for existing SSH public keys.
• ssh-agent – Keeps the private key in memory until the user logs out.
• ssh-add – Loads a private key into ssh-agent.

The PuTTY Suite [1] offers the same variety of tools. To begin, admins must download the complete zip archive with all the PuTTY SSH tools and not just run the .exe installer, which only downloads and installs the PuTTY SSH client. However, the respective tools have slightly different names in PuTTY, such as puttygen or psftp. In addition to the popular PuTTY, Windows admins have options for using SSH on Windows, such as the Cygwin Windows X server-based MobaXterm [2] [3] or direct use of the Cygwin API compatibility layer [4].

Enabling SSH

Setting up the SSH server on the Linux side – the SSH client generally is installed by default – is not the subject of this article, but you can do this by installing the openssh-server (RHEL, Fedora) or openssh packages (the SUSE package contains the server and client) with the preferred package management tool.

To enable the service, you need to start the sshd daemon and possibly add it permanently to the system boot configuration. You can do this, depending on your choice of distribution, with /etc/init.d/sshd start (SysV), service sshd start (Upstart), or systemctl start sshd.service.

Additionally, the service – if so desired – must be permanently added to the system boot configuration. For this step, you could use systemd (openSUSE, Fedora) by typing systemctl enable sshd.service or chkconfig sshd on (RHEL/SysVinit). On Fedora and Red Hat, you need to stop the firewall, which runs by default, by typing systemctl stop iptables.service, or create a rule for port 22 (SSH).

Administrators typically do not need to make any adjustments to the main configuration file – usually /etc/ssh/sshd_config – with one exception. The exception is that many OpenSSH implementations prevent root access by default; uncommenting the following line:

PermitRootLogin yes

lets you enable it.

Dealing with Host Keys

For Linux admins, dealing with the SSH host key is part of everyday life. Because a successful SSH connection requires a user account on the remote host, all SSH tools perform an authentication process. On Linux, typing

ssh -l <username> <remote IP address>

is sufficient to open a connection to the remote server, which then asks for the password to match the specified username and transfers the usernames and passwords in encrypted format. The process is the same for PuTTY, but you might not immediately notice, because the login takes place behind the graphical interface (Figure 1). For PuTTY, you only need to enter the desired target host in the Host Name field of the default Session tab.

Host Keys

SSH works with host keys by default to ensure integrity. For this reason, any SSH client will show its automatically transferred host key the first time it opens a connection (or the fingerprint belonging to the key); it then uses permanently add 'IP address' (RSA) to the list of known hosts to indicate that it did not know this key, and thus wants to add the key to its local $HOME/.ssh/known_hosts file. You must then decide whether to trust this server, that is, determine whether it is the server it claims to be. After all, an attacker could theoretically have hijacked an Internet connection.

Integrity could be ensured, for example, by retrieving the fingerprint of the remote server, which you could then compare with the key sent to you. The process is no different when using PuTTY as the SSH client, but PuTTY shows the dialog with the RSA fingerprint graphically (Figure 2) and offers to save the host key in the Windows registry format. At the same time PuTTY, keeps the host key in its cache until the next connection with the same server is opened.

The PuTTY developers provide a script (kh2reg) on the project site with which the admin can convert existing host keys from the classical (Linux) known hosts format to a Windows *.reg file, if required. On the server side, the host key is stored in the /etc/ssh directory and is named ssh_host_dsa_key by default. Once connected, PuTTY also shows a classic login window for the server, and the admin can log in with a username and password. The server host key's fingerprint can be found by entering

ssh-keygen -f /etc/ssh/ssh_host_rsa_key.pub -l

in the SSH remote shell.

Key Issues

Windows admins and users can use secure public key authentication with PuTTY. The password prompt, which is enabled by default for SSH, is just one of the ways you can handle authentication with SSH. The function is no different from that on Linux, but PuTTY uses different tools and configuration files. Just to remind you: On Linux, the admin uses ssh-keygen -t rsa (optionally, ssh-keygen -t dsa) to generate a new RSA or DSA key pair of public and private keys (Figure 3).

SSH saves the key files under the name id_rsa/id_dsa and id_rsa.pub in the .ssh subdirectory in the user's home directory. In contrast, the public key is appended to the user's $HOME/.ssh/authorized_keys file. In the opposite direction, you need to copy your own public key to the appropriate user directory on the server, as follows:

ssh-copy-id -i ~/.ssh/id_rsa.pub <remote username>@<Remote IP Address>

PuTTY uses the puttygen.exe (PuTTY Key Generator) tool (instead of ssh-keygen) to generate RSA (default) or DSA key pairs (Figure 4). Although you will find this tool on the PuTTY download page, make sure you have previously downloaded the full install zip file; puttygen should also be available below Putty in the Windows Start menu.

To generate an RSA key pair, press the Generate button. Admins who need SSH1 RSA or DSA keys can select the appropriate type directly below the dialog. You can ensure the necessary randomness yourself here, by moving the mouse back and forth in the free area of the dialog box while generating the key. Then, you enter the desired key passphrase for Key passphrase, as with ssh-keygen in Linux.

You can use the appropriate buttons for saving the public and private keys on the client, and you can freely choose the name and path in the file browser. The typical PuTTY key extension is *.ppk, which indicates the deviation from the standard Linux format. PuTTY RSA keys are therefore not compatible with OpenSSH keys. However, you can use Conversions on the menubar to import existing OpenSSH keys or export PuTTY keys.

To transfer your own public key to the server, you can theoretically use WinSCP or psftp (PuTTY SFTP), but it is easier and faster to select the entire key shown in the key field and press Ctrl+C to copy it to the clipboard. Then, you can log in again normally on the remote server using PuTTY, launch any Linux editor (e.g., nano) against the /$HOME/.ssh/authorized_keys file, and paste your key from the clipboard.

Public Key Authentication with PuTTY

If you want to change to public key authentication the next time you log in, enter the address of the desired host on the client-side PuTTY Session page, then – under the Category menu – click on SSH/Auth and enter the file name of your authentication key below Private key file for authentication. You can press Browse to select the file in the file browser (Figure 5).

Optionally, you can store the credentials for each session in a profile. The authentication sequence is identical on Linux and Unix. When you connect to the remote server, it asks for proof that the user has one of the public keys stored in the authorized_keys file for this user on the server. SSH thus prompts you for the passphrase for enabling the private key stored in the local id_rsa.ppk file. The connection will work only if the two keys match.

SSH Agent

The public-key authentication shown here may be more secure, but admins have not gained much if they need to enter a passphrase now, instead of the original password. To automate this process, Linux comes with the ssh-agent tool, in which you can store your private key. The SSH agent autonomously takes care of the authentication process, with the advantage that you only need to enter your passphrase once. The agent retains the key in memory until the user logs out. SSH-Agent is automatically started in the background on most Linux distributions.

Linux has the ssh-add command for interacting with ssh-agent; the -l option lists the currently stored keys. With the Windows MobaXterm SSH client, you can easily enable the SSH agent, for example, in the program settings (Figure 6). The PuTTY Suite has the pagent (putty agent) tool for this.

The MobaXterm SSH client is an interesting alternative to the popular PuTTY. Because MobaXterm is based on the Cygwin compatibility layer, the tool thinks it is running in a real Linux environment on the client side. This approach means that use of the Linux tools ssh-keygen and ssh-copy-id is possible, including the typical Linux configuration files in the .ssh subdirectory.

A pleasant side effect is that the key files are compatible with standard OpenSSH. You only have to know that the relative home directory of the Linux environment corresponds to C:\Users\User\Documents\MobaXterm

\home. Windows physical drives can be found below /drives in the MobaXterm environment.

WinSCP

SSH is useful not only for secure remote logins but also for secure file transfers. This task will also be the most common use for an SSH client for Windows. Although PuTTY is the most popular Windows SSH client, it is not very convenient in terms of file transfer. For example, PuTTY's Secure FTP client psftp is a classic CLI client; in principle, it behaves no differently from a Linux CLI client. In MobaXterm, however, you can enable a graphical SFTP browser in the settings, and it automatically pops up in the sidebar when a SSH connection is established (Figure 7).

Appropriate Windows alternatives such as WinSCP [5] also are available for the classic SSH tools sftp and scp, as cryptographically secure alternatives to ftp and rcp. The current version 5.1.5 of the GPL tool has just been released, and it is available on the project website [6]. Installing the executable file is trivial. However, administrators should choose the custom installation, because then the pagent and puttygen tools and the new drag-and-drop shell extension are also conveniently installed.

WinSCP also offers direct downloads via drag and drop and supports the standard SSH protocols sftp and scp via SSH1 and SSH2. Additionally, it has a GUI interface as well as a command-line interface and can process batch scripts [7]. WinSCP can also optionally handle authentication via the SSH password or public key method, and it supports Kerberos (GSS) identification [8].

To open the connection, enter the desired host in the Session section of the Host name field, select the desired Protocol, and enter the user credentials and password. Assuming that you ran puttygen previously to create a public/private key pair and copied the public key to the server, you can optionally specify a password instead of the file containing the private RSA key.

Trust Me

Because scp and sftp are based on SSH, WinSCP, like PuTTY, points out the unknown host key the first time you connect to a new server. If you trust the target host, you are taken to a Windows Explorer-like interface; its use is self-explanatory.

Copying files to the destination host, or in the opposite direction, is an easy process using either by drag and drop, function keys, or Norton Commander-like menus (Figure 8). In the confirmation dialog, admins can change the transmission options or run a transfer in the background for large amounts of data. Additionally, you can also use the integrated editor to edit text files directly on the server.

Swish

The most elegant method of accessing remote files via SSH on Linux is undoubtedly the use of sshfs [9]. Sshfs is a FUSE (Filesystem in Userspace) module [10] that lets admins bind remote Linux machines to the local filesystem of the Linux client via SSH. The use of sshfs does not question the usefulness and functionality of Samba, but using Samba involves some installation and configuration overhead on the server and the client, whereas sshfs can be leveraged with little effort.

On the server, you need only a SFTP program, which is ensured by OpenSSH. To bind remote filesystems via SSH, you also need the small GPL'd SFTP tool Swish [11] on Windows. This open source tool is available from SourceForge [12], and the current version is 0.74 (see also the "WinSSH" box). Installing the executable binary needs no explanation; no launcher is needed because Swish simply appears as a new network drive called Swish.

When you click, you first see an empty drive with two buttons, Add SFTP Connection and Launch key agent, at the top. Clicking on the former displays a dialog where you can specify the connection settings. You again need to enter the destination host, the desired username, and the directory path that is a relative root for the new connection. Also, the connection still needs a name under which to Create the configuration as a profile or network drive.

Additionally, with Swish, you may need to confirm the RSA key for the unknown host the first time you connect to it (Figure 9).

If you trust the fingerprint displayed, you can press I trust this key, enter your password and, depending on the chosen path, start work directly in the filesystem of the remote host as a normal network drive, that is, use drag and drop to copy data, or use Copy and Send to in the context menu (Figure 10).

Key management is the front end for pagent; it displays the cached key or helps admins add new keys.

Port Forwarding

SSH can also secure any other protocol, such as FTP, with its port forwarding function. SSH port forwarding redirects the specified ports via a secure SSH connection, and SSH itself takes the role of a proxy. It accepts connections on one side of the tunnel and connects them at the other end with the specified server as the connection endpoint.

SSH tunnel has two operating modes: Local port forwarding and remote port forwarding (outbound/inbound tunnel), where typically local port forwarding is used. The parameters -L or -R indicate the direction. In local port forwarding, SSH routes an inbound port on a local client through a secure SSH channel to a port on the remote SSH server. The SSH syntax looks like this on a Linux client, for example:

ssh root@www.thomas-drilling.de -L 555:www.thomas-drilling.de:21

The command redirects the insecure FTP connection via a secure SSH connection to the server www.thomas-drilling.de with a default port of 21. If an SSH server is running on the server and the client, the ws1-fed client opens a secure SSH connection. The local SSH server then listens to all requests received on the local port 555 of ws1-fed, and forwards them to port 21 on the remote host, www.thomas-drilling.de.

Any further communication then takes place exclusively via the previously established SSH connection. The admin can now enter

ftp localhost 555

on the local host ws1-fed to start the FTP client in a second terminal session (basically opening a session to itself) to access the FTP server automatically at the other end. The difference now is that the channel is secure. The best thing about using the Cygwin-based tool, MobaXterm, is that you can point and click in the Tools | MobaSSHTunnel menu to put together the whole port forwarding configuration graphically.

Although FTP is not the best example, given the SFTP alternatives shown, this approach works with any other port or service as well. Regardless of whether the particular service is regarded to be inherently secure or insecure, admins will always benefit from the encrypted connection in SSH port forwarding.

Conclusions

In 14 years of its existence, SSH has not lost any of its usefulness, particularly for managing hosts or user interfaces. The word has spread, and Windows administrators can now turn to many graphical tools, such as PuTTY and MobaXterm, as clients.