Client Access Standards to Production Servers Using the SSH Protocol

By: Craig Borysowich Chief Technology Architect Imagination Edge Inc. www.imedge.net Revision: 2.7

Client Access Standards to Production Facilities

Overview

This document describes and provides information on the tools and standards for access by clients to production facilities. The two most common technologies in use today for secure access to machines and networks are Virtual Private Networking (VPN) and/or Secure SHell (SSH).

Note:

• Information on SSH and VPN is available at www.ietf.org as a series of RFC documents in different categories (standard, informational, memorandum). • Information on TCP/UDP port assignment is available at www.iana.org. • The open standards initiative is supported by www.openssh.org.

IP-based remote access to secure servers should standardize on SSH as a secure and effective method of providing client access to their production facilities at any datacenter. SSH was chosen over VPN technology for client access for the following reasons:

• SSH like VPN provides encrypted, secure communications • SSH like VPN allows for tunneling • SSH provides end to end encryption, VPN encryption demarcates at the VPN appliance output, from that point forwards transmission is ‘in the clear’ • Unlike VPN, SSH does not appear as a member node of a network • Unlike VPN, SSH does not exchange full network information such as routing tables and broadcasts • SSH requires a lower overhead on computing resources than VPN; no need for a dedicated appliance

Note: The use of VPN facilities should be limited to production support and key staff.

This document covers:

• Technical details of SSH • Use of SSH • Client installation

In the appendix of the document there is a further in depth technical discussion on the SSH protocol and a FAQ.

www.imedge.net Page 2 10/14/2004 Client Access Standards to Production Facilities

SSH use in Datacenters

Secure communications in any computing environment is a necessity either in all or portions of the enterprise.

The security of systems in the infrastructure is usually guided by the corporate security department for establishing best practices. This document provides the guideline for the application of industry standards in securing systems, their data and communications using SSH.

There is a need for clients to be able to access their systems for the following purposes:

• Remote administration and maintenance of applications • GUI based management interfaces • Data movement

The standard utilities and services like telnet and ftp have well documented, known and exploitable vulnerabilities. Allowing access to these and other services on a host machine is contrary to industry security best practices and hardening standards.

Another consideration is securing the transmission data, an environment where usernames and passwords, or sensitive data is ‘in the clear’ could severely compromise systems and business applications.

The use of SSH allows for:

• encryption of usernames and passwords while communicating • secure and encrypted telnet and ftp • a pseudo VPN that allows protocol forwarding

SSH is an encrypted protocol client/server application. Administrators configure and maintain the server side of the installation and management of the infrastructure on behalf of their users. The SSH server provides access control, authentication, encryption and auditing of sessions established on the server by external administrators and other power users that require direct access to the server for application or data maintenance.

The client is configurable and can be either private label or public domain; the client communicates on port 22 in an encrypted and secure fashion.

Note: The entire session between server and client is torn down when the client disconnects, it is good practice to terminate your session when not in use. There will also be disconnects of a session when preset idle timers have been exceeded in the network path.

www.imedge.net Page 3 10/14/2004 Client Access Standards to Production Facilities

Towards these goals the F-Secure SSH server has become defacto in its use to serve encrypted secure services from host to end node.

Imagination Edge recommends the use of the F-Secure SSH Client for those who want a graphical interface for ftp transfers and as a qualified client for telnet, ftp, xwindows, tunneling and encryption (www.fsecure.com).

It should also be pointed out that there is public domain SSH clients’ available dependant on your personal needs. The following are a couple of popular public domain clients:

• PuTTY - http://www.chiark.greenend.org.uk/~sgtatham/putty/ • TerraTerm - http://hp.vector.co.jp/authors/VA002416/teraterm.html • TerraTerm (SSH module) - http://www.columbia.edu/acis/software/teraterm/teraterm.pdf

F-Secure SSH Client Installation

The following is general description of the F-Secure client installation with annotations for install specific configuration settings and deployment best practices.

1. Once you insert the CD in your drive the following splash screen appears:

www.imedge.net Page 4 10/14/2004 Client Access Standards to Production Facilities

At this screen you would select install, please make sure you have your CD key ready the installation will request this.

2. Once you have entered you key you will be provided with the selection to continue with the installation of the client. Accept the defaults when queried unless you wish to set your own installation setting where appropriate.

3. Once you have completed the installation you will be requested to restart your machine.

4. Upon restarting your machine there will be an F-Secure SSH client icon on your desktop or in your Start menu.

Double click on the icon and start the program for the first time, at this time and only at this time a random seed is generated for your client, this is used to encrypt and decrypt your communications.

When presented with the following screen you must continue to move your mouse around until there is sufficient randomness to generate your seed.

www.imedge.net Page 5 10/14/2004 Client Access Standards to Production Facilities

5. On completion of the random seed generation you will be presented with the SSH client screen and you will now configure the software with the specifics for connecting to your production environments.

6. From the Edit dropdown menu select Settings to begin configuring your software as in the following screen.

www.imedge.net Page 6 10/14/2004 Client Access Standards to Production Facilities

Here you will enter:

• Fully qualified host name • Your assigned username, this is provided to you by an administrator • Port 22 remains the same • Default authentication method stays as password

The settings for Ciphers and Firewall are left at the default value.

7. Once you have completed your connection information you will now proceed to configuring your terminal, this also includes some X11 specific settings. At this screen continue to select the defaults or your preference for terminal emulation and any X11 specific settings.

www.imedge.net Page 7 10/14/2004 Client Access Standards to Production Facilities

8. Now you will proceed to the configuration of your file transfer, generally the default values will be sufficient unless there are specifics you wish to change such as the missing file association application.

www.imedge.net Page 8 10/14/2004 Client Access Standards to Production Facilities

If you require X11 support then the next step is to configure tunneling of the SSH client software by selecting the ‘Tunnel X11 connections’ check box.

The final item to configure if necessary is the Security option, again the default values are valid for connectivity.

www.imedge.net Page 9 10/14/2004 Client Access Standards to Production Facilities

APPENDIX

www.imedge.net Page 10 10/14/2004 Client Access Standards to Production Facilities

A Primer on the SSH Protocol By Craig Borysowich

DESCRIPTION

ssh (SSH client) is a program for logging into a remote machine and for executing commands on a remote machine. It is intended to replace rlogin and rsh, and provide secure encrypted communications between two untrusted hosts over an insecure network.

X11 connections and arbitrary TCP/IP ports can also be forwarded over the secure channel. ssh connects and logs into the specified hostname. The user must prove his/her identity to the remote machine using one of several methods depending on the protocol version used.

What is Secure Shell?

To paraphrase the README file:

Secure Shell is a program to log into another computer over a network, to execute commands in a remote machine, and to move files from one machine to another. It provides strong authentication and secure communications over unsecured channels. It is intended as a replacement for telnet, rlogin, rsh, and rcp.

For SSH2, there is a replacement for FTP: sftp. Additionally, Secure Shell provides secure X connections and secure forwarding of arbitrary TCP connections. You can also use Secure Shell as a tool for things like rsync and secure network backups.

The traditional BSD 'r' - commands (rsh, rlogin, rcp) are vulnerable to different kinds of attacks. Somebody who has root access to machines on the network, or physical access to the wire, can gain unauthorized access to systems in a variety of ways. It is also possible for such a person to log all the traffic to and from your system, including passwords (which ssh never sends in the clear).

The X Window System also has a number of severe vulnerabilities. With ssh, you can create secure remote X sessions which are transparent to the user. As a side effect, using remote X clients with ssh is more convenient for users.

There are two versions of Secure Shell available: SSH1 and SSH2. This FAQ does its best to distinguish when the situation calls for the difference between the two.

How widespread is its use?

www.imedge.net Page 11 10/14/2004 Client Access Standards to Production Facilities

The most current figures available are over 2 million Secure Shell users in over 60 countries. This is not an accurate amount, but an estimate. It also does not necessarily include the different implementations of Secure Shell for different operating systems.

Note that this includes both SSH1 and SSH2 implementations.

SSH protocol version 1

First, if the machine the user logs in from is listed in /etc/hosts.equiv or /etc/shosts.equiv on the remote machine, and the user names are the same on both sides, the user is immediately permitted to log in.

Second, if .rhosts or .shosts exists in the user's home directory on the remote machine and contains a line containing the name of the client machine and the name of the user on that machine, the user is permitted to log in. This form of authentication alone is normally not allowed by the server because it is not secure.

The second authentication method is the rhosts or hosts.equiv method combined with RSA-based host authentication. It means that if the login would be permitted by $HOME/.rhosts, $HOME/.shosts, /etc/hosts.equiv, or /etc/shosts.equiv, and if additionally the server can verify the client's host key (see /etc/ssh/ssh_known_hosts and $HOME/.ssh/known_hosts in the FILES section), only then login is permitted. This authentication method closes security holes due to IP spoofing, DNS spoofing and routing spoofing.

[Note to the administrator: /etc/hosts.equiv, $HOME/.rhosts, and the rlogin/rsh protocol in general, are inherently insecure and should be disabled if security is desired.]

As a third authentication method, ssh supports RSA based authentication. RSA authentication is a scheme based on public-key cryptography. There are cryptosystems where encryption and decryption are done using separate keys, and it is not possible to derive the decryption key from the encryption key. RSA is one such system. The idea is that each user creates a public/private key pair for authentication purposes. The server knows the public key, and only the user knows the private key.

The file $HOME/.ssh/authorized_keys lists the public keys that are permitted for logging in. When the user logs in, the ssh program tells the server which key pair it would like to use for authentication. The server checks if this key is permitted, and if so, sends the user (actually the ssh program running on behalf of the user) a challenge, a random number, encrypted by the user's public key.

The challenge can only be decrypted using the proper private key. The user's client then decrypts the challenge using the private key, proving that he/she knows the private key but without disclosing it to the server. ssh implements the RSA authentication protocol automatically. The user creates his/her RSA key pair by running ssh-keygen(1). This

www.imedge.net Page 12 10/14/2004 Client Access Standards to Production Facilities

stores the private key in $HOME/.ssh/identity and the public key in $HOME/.ssh/identity.pub in the user's home directory.

The user should then copy the identity.pub to $HOME/.ssh/authorized_keys in his/her home directory on the remote machine (the authorized_keys file corresponds to the conventional $HOME/.rhosts file, and has one key per line, though the lines can be very long). After this, the user can log in without giving the password. RSA authentication is much more secure than rhosts authentication.

The most convenient way to use RSA authentication may be with an authentication agent. See ssh-agent(1) for more information. If other authentication methods fail, ssh prompts the user for a password. The password is sent to the remote host for checking; however, since all communications are encrypted, someone listening on the network cannot see the password.

SSH protocol version 2

When a user connects using protocol version 2 similar authentication methods are available.

Using the default values for PreferredAuthentications, the client will try to authenticate first using the host based method; if this method fails public key authentication is attempted, and finally if this method fails keyboard-interactive and password authentication are tried.

The public key method is similar to RSA authentication described in the previous section and allows the RSA or DSA algorithm to be used. The client uses his private key, $HOME/.ssh/id_dsa or $HOME/.ssh/id_rsa, to sign the session identifier and sends the result to the server. The server checks whether the matching public key is listed in $HOME/.ssh/authorized_keys and grants access if both the key is found and the signature is correct.

The session identifier is derived from a shared Diffie-Hellman value and is only known to the client and the server. If public key authentication fails or is not available a password can be sent encrypted to the remote host for proving the user's identity.

Additionally, ssh supports hostbased or challenge response authentication. Protocol 2 provides additional mechanisms for confidentiality (the traffic is encrypted using 3DES, Blowfish, CAST128 or Arcfour) and integrity (hmac-md5, hmac-sha1).

Note: Protocol 1 lacks a strong mechanism for ensuring the integrity of the connection.

www.imedge.net Page 13 10/14/2004 Client Access Standards to Production Facilities

When the user's identity has been accepted by the server, the server either executes the given command, or logs into the machine and gives the user a normal shell on the remote machine.

All communication with the remote command or shell will be automatically encrypted. If a pseudo-terminal has been allocated (normal login session), the user may use the escape characters noted below. If no pseudo tty has been allocated, the session is transparent and can be used to reliably transfer binary data.

On most systems, setting the escape character to ``none'' will also make the session transparent even if a tty is used. The session terminates when the command or shell on the remote machine exits and all X11 and TCP/IP connections have been closed. The exit status of the remote program is returned as the exit status of ssh.

Authorizing access

To allow access to a system for a given identity place the public key in your ~/.ssh/authorized_keys file on that system. All keys listed in that file are allowed access.

Usually you will want to authorize access to the local system using the local key (especially in an environment where multiple systems share the same home directory e.g. using NFS). Thus a good start is to copy the public key for your default identity into the ~/.ssh/authorized_keys file.

beowulf% cd ~/.ssh beowulf% cp identity.pub authorized_keys

You could now copy the ~/.ssh/authorized_keys file to other systems to allow access from the local system. One way to copy the file is to use the ftp command.

Use a text editor to add more keys to the file. If you use cut and paste to copy the key make sure each key entry is a single line in the file. The keys to add are always the public keys (from files with the .pub extension).

NOTE: To gain access to restricted systems you might need to send your public key in electronic mail to the administrator of the system. Just include the contents of the ~/.ssh/identity.pub file in the message.

Directory and file permissions

If access to the remote system is still denied you should check the permissions of the following files on it:

• the home directory itself

www.imedge.net Page 14 10/14/2004 Client Access Standards to Production Facilities

• the ~/.ssh directory • the ~/.ssh/authorized_keys file

The permissions should allow writing only by you (the owner). This example shows the most relaxed permissions you could use.

hrothgar% cd hrothgar% ls -ld . .ssh .ssh/authorized_keys drwxr-xr-x 36 kim kim 4096 Jul 25 02:24 . drwxr-xr-x 2 kim kim 512 Apr 10 02:30 .ssh -rw-r--r-- 1 kim kim 1674 Apr 10 02:29 .ssh/authorized_keys

To make the remote system allow access you must change the permissions to disallow writing by others than the owner.

hrothgar% cd hrothgar% chmod go-w . .ssh .ssh/authorized_keys

Remember to do this on all the systems you want to have access to.

Logging into remote systems

To establish an interactive connection to a remote system you would use either the slogin or the ssh command. The only parameter is the name of the remote system. The pass- phrase is not echoed back to you when you type it.

beowulf% slogin hrothgar Enter passphrase for RSA key '[email protected]': litt1e 1amp jumb3d Last login: Wed Oct 16 20:37:00 1996 from idefix [more output from the remote machine] hrothgar%

You can avoid the pass-phrase prompts by keeping the authentication keys in memory. You only need to type the pass-phrase when you add a key into memory.

If your account name on the remote system differs from the one on the local system (the system you are connecting from) you can use the -l switch to specify the remote account name.

beowulf% slogin -l suominen panix.com Last login: Sun Oct 13 14:55:17 1996 from idefix.gw.com [more output from the remote machine] panix%

You can change the default remote account name by creating a configuration file entry for the host.

www.imedge.net Page 15 10/14/2004 Client Access Standards to Production Facilities

Keeping authentication keys in memory

If you frequently open connections to remote systems you can run your session under the ssh-agent. The agent will provide decrypted authentication keys to all the commands when new connections are created.

When you start ssh-agent you need to provide it a command to spawn. This is usually either your shell or a command to start a windowing environment. When you exit the command all keys will be removed from memory.

beowulf% ssh-agent $SHELL beowulf%

You will now need to add keys into memory to have them available for other commands.

Running X on a local display

If you have workstation where you start the X window system after logging in you can have the whole windowing environment benefit from the keys in memory. The X window system is normally started with startx and the initial clients are in your ~/.xinitrc file.

beowulf% ssh-agent startx &

If your workstation has virtual consoles it is good to put the X window system in the background so the current virtual console can still be used for more commands if necessary. It won't hurt to background the command even without virtual consoles.

NOTE: Your system might have a non-standard way of starting the X window system. Replace startx with the appropriate command if necessary. Please ask your system administrator for the exact command to use.

Running X with an xdm session

If you use an X-terminal or your workstation is running xdm you need to arrange for the clients to run under ssh-agent. The easiest way (which is conveniently compatible with the method used without xdm) is to put all initial clients into the ~/.xinitrc file which in turn is called from the ~/.xsession file.

An example ~/.xsession file is below. It runs ssh-agent only if you have a ~/.ssh directory.

#!/bin/sh if [ -d $HOME/.ssh ] then EXEC="exec ssh-agent" else EXEC="exec" fi if [ -x $HOME/.xinitrc ]

www.imedge.net Page 16 10/14/2004 Client Access Standards to Production Facilities

then $EXEC $HOME/.xinitrc else $EXEC xterm -geometry 80x24+0-60 -ls fi

Make sure the files are executable. The following command will change the permissions suitably.

beowulf% chmod a+x ~/.xinitrc ~/.xsession

NOTE: If you are using an X-terminal keep in mind that your session is most likely not secure. Usually anything you type can be captured on the local area network you are connected to.

Running commands on remote systems

The ssh command can also be used to run commands on remote systems without logging in. The output of the command is displayed and control returns to the local system. Here is an example which will display all the users logged in on the remote system.

beowulf% ssh hrothgar who christos ttyp8 Oct 17 20:42 (milou) beowulf%

If you are using the X Window System you can use this capability to start a terminal window to start an interactive session on the remote system.

beowulf% ssh -n hrothgar xterm & [1] 15866 beowulf%

Use the -n to prevent the remote system from trying to read from the terminal starting the xterm and put the process in the background. A new window from the remote system should appear shortly on your display.

Copying files between systems

You can copy files from the local system to a remote system or vice versa, or even between two remote systems using the scp command. To specify a file on a remote system simply prefix it with the name of the remote host followed by a colon.

If you leave off the filename of the copy or specify a directory only the name of the source file will be used. An easy way of retrieving a copy of a remote file into the current directory while keeping the name of the source file is to use a single dot as the destination.

beowulf% scp -p hrothgar:aliases . beowulf% www.imedge.net Page 17 10/14/2004 Client Access Standards to Production Facilities

The -p option is not required. It indicates that the modification and access times as well as modes of the source file should be preserved on the copy. This is usually desirable. You can copy several files in a single command if the destination is a directory.

beowulf% scp -p hrothgar:.login hrothgar:.logout panix.com:. beowulf%

Relative filenames resolve differently on the local system than on the remote system. On the local system the current directory is assumed (as usual with all commands). On the remote system the command runs in the home directory! Thus relative filenames will be relative to the home directory of the remote account.

NOTE: When you specify remote machines in both the source and the destination the connection to copy the files is made directly between those hosts. The files are not copied through the local system. Sometimes this makes a difference in a firewalled or otherwise restricted environment.

Changing default settings

The defaults for the ssh-related commands can be altered for each account in a configuration file ~/.ssh/config (there is also a system-wide file, usually /etc/ssh_config). Each entry starts with a Host keyword. You can use wildcards to match all the appropriate systems:

• ? matches any single character • * matches any sequence zero or more characters

Usual keywords include (defaults in parenthesis): Compression yes/no (no) Controls whether compression is used on the connection.

CompressionLevel 1-9 (6) Level of compression: 1 is fastest, 9 is slowest (achieves best compression). Compression is good for slow links (saves bandwidth) and fast machines.

FallBackToRsh yes/no (yes) If a secure connection to the remote system cannot be established the commands can try unsecure connections (a warning will be displayed if this happens). On highly secure systems this could be disabled in the system-wide configuration.

KeepAlive yes/no (yes)

www.imedge.net Page 18 10/14/2004 Client Access Standards to Production Facilities

Controls whether TCP keepalive messages are used. When enabled it is possible to detect network outages and automatically close your connections (which is good). However, if you are connected over a dialup link that automatically dials when there is traffic, you will want to turn this off to avoid unnecessarily bringing up the line.

User account (local account) Specify the remote account name. Add this to avoid having to use the -l option when issuing commands. Here is an example ~/.ssh/config file.

Host *panix.com User suominen Compression no

Host *gw.com FallBackToRsh no

Host * Compression yes CompressionLevel 9 FallBackToRsh yes KeepAlive no

Options are accumulated over entries, but a more specific entry will override a less specific one. E.g. in the above compression will not be used for hosts that match *panix.com but will be used for hosts that match *gw.com (and all other hosts since the * entry matches all hosts).

Can I run backups over ssh?

Yes. The easiest possible way to do this is:

# tar cvf - | ssh user@host "dd of=/dev/tape"

Since ssh is a drop-in replacement for rsh, backup scripts should continue to work. You can use datbkr by David Cinege, which uses Secure Shell to do backups over an Secure Shell connection. You can get datbkr at http://www.psychosis.com/datbkr. You can also use rdist and rsync, which there is more information at below.

Can I use ssh to communicate across a firewall?

Yes. All you need is an open port on the firewall and the sshd or sshd2 listening on the other side.

Most people do this on port 22 (the standard port for Secure Shell), but if you have a BOFH, you can also tunnel through another open port through the firewall (I'm sure all

www.imedge.net Page 19 10/14/2004 Client Access Standards to Production Facilities

those system admins love me now :-) by running a daemon on the remote side on a port that's allowed through a firewall, like SSL (port 443).

Set up the remote daemon running sshd on port 443:

# sshd -p 443

Then, on your local system, open a connection on port 443:

$ ssh -p 443 remotehost.example.org

You can also use Secure Shell to tunnel insecure traffic like POP, IMAP, and others through the firewall as well.

Can I use rdist or rsync with ssh?

Yes.

If you use rdist, don't forget to compile the path to ssh into it. Alternatively, you may specify the -P option so rdist uses ssh, and not rsh.

If you use password authentication with rdist 6.1.2 through 6.1.5, you will need to apply the following patch to rdist to make it work:

--- src/rshrcmd.c.orig Tue Jun 11 16:51:21 1996 +++ src/rshrcmd.c Tue Jun 11 16:52:05 1996 @@ -63,7 +63,7 @@ /* child. we use sp[1] to be stdin/stdout, and close sp[0]. */ (void) close(sp[0]); - if (dup2(sp[1], 0) < 0 || dup2(0,1) < 0 || dup2(0, 2) < 0) { + if (dup2(sp[1], 0) < 0 || dup2(0,1) < 0) { error("dup2 failed: %s.", SYSERR); _exit(255); }

This also applies if you get a "Warning: Denied agent forwarding because the other end has too old version." error (which occurs if your client is 1.2.17 or later, and it connects to an older server).

Another alternative would be to use rsync, a rdist replacement, which was designed to work with ssh, and makes better use of bandwidth. More information can be found at http://rsync.samba.org/rsync. You can use the --rsh=/usr/local/bin/ssh option to use Secure Shell as a transport.

Can I use ssh to securely connect two subnets across the Internet?

www.imedge.net Page 20 10/14/2004 Client Access Standards to Production Facilities

You can run PPP over a regular ssh connection. See http://www.inka.de/~bigred/sw/ssh- ppp-new.txt for a working solution. It's a good idea to enable compression for this. Another implementation of this is available at http://www.linuxdoc.org/HOWTO/mini/VPN.html.

However, this may cause problems for forwarding TCP connections, because both the TCP connection over which ssh runs and a TCP connection forwarded over the PPP/ssh tunnel may retransmit at the same time. In this case, it is better to use encrypted IP tunneling via UDP. A possible implementation of this is http://www.inka.de/~bigred/devel/cipe.html .

Also look into Magnus Lundström's replacement for ssh-ppp in C for Linux, which is now being ported to other OS's. See http://detached.net/vpnstarter. The vpnstarter is more reliable (and easier to set up) than ssh-ppp.

Can I use ssh to securely forward UDP-based services, such as NFS or NIS?

This is not currently implemented in SSH1 or SSH2.

However, there is a general working solution for RPC-based services. This project uses Secure Shell to increase the security of RPC-based services; so far this has been implemented for NIS and NFS.

You can download the latest version of this software from http://www.math.ualberta.ca/imaging/snfs/.

More information is available at ftp://ftp.tu- chemnitz.de/pub/Local/informatik/sec_rpc/README.RPC

Can I use ssh to protect services like FTP or POP?

If you want to avoid sending FTP passwords in cleartext over the net, you can use ssh to encrypt your command channel. This will still leave your data channel open to all attacks on TCP, and will not work through a firewall.

You can either use ftpsshd by Per-Erik Martin at http://www.docs.uu.se/~pem/hacks/ for SSH1, or you can do this by hand.

SSH1: Suppose you are on a host called myhost and want to initiate a ftp connection to ftphost. On myhost, you do:

myhost$ ssh -L 1234:ftphost.example.com:21 ssh-server

This logs you on to ftphost and also forwards connections to 1234 on myhost to ftphost.

www.imedge.net Page 21 10/14/2004 Client Access Standards to Production Facilities

Note: You need to use -g if you're forwarding to localhost (SSH1 only).

Then, in another window, you do: myhost$ ftp localhost 1234 220 ftphost FTP server (Foonix 08/15) ready. Name: (myhost:yourname): 331 Password required for yourname Password: 230 User yourname logged in.

This works if the remote ftp daemon accepts PORT commands which specify a different host from the one the command channel appears to come from, and if the ftp client always uses PORT. This is true for vanilla UNIX ftp client and ftpd servers; it may not work for more advanced ftpds, such as wu-ftpd.

For servers which do not accept this, you can see wether you ftp client supports passive mode, and wether the ftp server accepts PASV.

Note, however, that unencrypted ftp data connections are still vulnerable to session hijacking and snooping.

SSH2: Just use sftp instead.

For POP, Stephane Bortzmeyer ([email protected]) has written a script which protects the mail transfer and passwords ussing ssh. It requires no modification to existing POP servers or clients, and is available from: ftp://ftp.internatif.org/pub/unix/gwpop/ .

Or, you can use similar means for secure POP: myhost$ ssh -L 1234:popserver.example.com:110 ssh-server

Other services could be secured by similar means.

Can I use ssh across a Socks firewall?

Socks 4 and 5 support should work in 1.2.16 or later. Socks support in version 2.0.11 and later should work.

Can I use TCP wrappers for added security on Secure Shell?

Yes, the Secure Shell daemon can use TCP wrappers. Unlike other tcpwrapped services, the Secure Shell daemon is NOT run via inetd and tcpd (doing that will give "packet too long" errors). TCP wrapper support (also called "libwrap support") is compiled into the sshd binary and the sshd runs as a standalone daemon.

www.imedge.net Page 22 10/14/2004 Client Access Standards to Production Facilities

To build Secure Shell with libwrap support, run ./configure with the --with- libwrap=PATH flag, where PATH is the full pathname to the libwrap.a file that you installed when you built the TCP wrappers. For example:

./configure --with-libwrap=/usr/local/lib/libwrap.a

When you installed TCP wrappers, you should have kept the tcpd.h and libwrap.a files. Usually tcpd.h goes in /usr/local/include and libwrap.a goes in /usr/local/lib.

By default, installing TCP wrappers doesn't install these two files, so you may need to grab the TCP wrappers source and recompile it, then install those two files.

In the /etc/hosts.allow and /etc/hosts.deny files, make an entry for the Secure Shell daemon. Be sure that the name of the service matches the name of the sshd binary you're running. e.g. If you run the daemon as "sshd2" then the service must be named "sshd2", and if you run it as "sshd" then the service name must be "sshd"

Here are some example hosts.allow entries. For more examples, check the hosts_access(5) man page that came with the TCP wrapper distribution.

# Example 1 - Allow Secure Shell from this one subnet # Secure Shell daemon is started as /usr/local/sbin/sshd sshd: 192.168.1.0/255.255.255.0

# Example 2 - Allow Secure Shell access from two subnets # Secure Shell is started as /usr/sbin/sshd2 sshd2: 192.168.1.0/255.255.255.0 10.0.0.0/255.0.0.0

# Example 3 - Won't work because service name is wrong, unless # you really start your daemon as ssh instead of sshd! ssh: 10.0.0.0/255.0.0.0

See the TCP Wrappers documentation for more details.

How do I tunnel X through Secure Shell?

To configure the sources and create an Secure Shell build that supports X forwarding: # ./configure --with-x

Run make and make install normally. You'll also want to make sure your configuration file is set properly. Note that this is the default, and you really do not need --with-w defined.

Basic configuration:

For SSH1:

www.imedge.net Page 23 10/14/2004 Client Access Standards to Production Facilities

In /etc/ssh_config: ForwardX11 yes

In /etc/sshd_config: X11Forwarding yes

For SSH2:

In /etc/ssh2/sshd2_config:ForwardX11 yes

Note that you do not have to change the /etc/ssh2/ssh2_config file. If you are running TCP Wrappers along with X forwarding, you need to make sure you add the necessary sshdfwd-X11: line in the /etc/hosts.allow file. This should not contain the host you are coming from.

You also do not need to open any additional ports. Everything is sent through port 22.

Does Secure Shell support digital certificates?

No, not currently. As digital certificates become more popular, Secure Shell will probably support digital certificates in the future.

Does Secure Shell work with PGP keys?

Only in SSH2. It's supported in release 2.0.13 or later.