All About SSH - Part I/II
Replacing telnet/rlogin/rsh with SSH
Denial of Service Research Center
By SeáÏ Boran
Feb 14, 2000. This article presents an overview of SSH,
the Secure SHell. This is the first part of a two part series, introducing SSH and the
major implementations - except OpenSSH.
Part2 will focus on the new OpenSSH.
SSH is so useful, easy to use and so much more secure than the archaic
telnet/rlogin/rsh, that no UNIX system should be installed without it. Ideally all OS
vendors would follow the example of OpenBSD & Suse, and bundle SSH with the OS.
We welcome your feedback on this article.
- SSH Overview
Why SSH?
Features
Licensing & cost
U.S. Export and Patent Restrictions
Advantages
Disadvantages
- Implementations
- Compiling & Configuring
- Doing even more with SSH
- References
Secure Shell (SSH) was originally authored by Tatu Ylen, Finland, is a secure
replacement for Telnet, rlogin, rcp, rsh and provides secured TCP tunnels. Optional
compression of traffic is provided and can also be used together with many Authentication
schemes such as SecurID, Kerberos, S/KEY to provide a highly secure remote access point to
UNIX servers.
SSH1 was the the first version (protocol v1.2 and v1.5) that was free in the earlier
days, but licensing has become more restrictive and SSH Communications
and DataFellows are trying to get people
to move to the newer SSH2 (which is commercial). However SSH1 is destined for a long life
as freeware, now that OpenSSH has been produced by the OpenBSD team and community.
The Telnet, rlogin, rcp, rsh commands have a number of security weakness: all
communications are in clear text and no machine authentication takes place. These commands
are open to eavesdropping and tcp/ip address spoofing. A second key UNIX tool, the X11
windows system, also communicates in clear text, uses dynamic ports (making packet
filtering difficult) and has a difficult-to-use access control mechanism
"xhosts" and "xauth", that few users understand and hence X11 access
control is often insecure on UNIX desktops.
SSH uses public/private key RSA authentication to check the identity of communicating
peer machines, encryption of all data exchanged (with strong algorithms such as blowfish,
3DES, IDEA etc.). Backwards compatibility to rlogin/rsh and their trust files (rhosts,
hosts.equiv) is provided to allow communication with non SSH servers. Optionally, an
encrypted tunnel for X11 communications can be automatically setup by SSH (using the xauth
access control and DISPLAY environment variable).
So SSH protects against:
- Eavesdropping of data transmitted over the network.
- Manipulation of data at intermediate elements in the network (e.g. routers).
- IP address spoofing where an attack hosts pretends to be a trusted host by sending
packets with the source address of the trusted host.
- DNS spoofing of trusted host names/IP addresses.
- IP source routing
SSH does not protect against:
- Incorrect configuration or usage (see disadvantages below).
- A compromised root account. If you login from a host to a server and an attacker has
control of root on either side, he/she can listen to your session by reading from the
pseudo-terminal device, even though SSH is encrypted on the network, it must communicate
in clear text with the terminal device.
- Insecure home directories: if an attacker can modify files in your home directory (e.g.
via NFS) he may be able to fool SSH.
SSH can be used to log-in securely into another computer over a network, execute
commands on a remote machine, and copy files from one machine to another. SSH provides
strong authentication and secure communications over insecure channels. It is intended as
a replacement for rlogin, rsh, and rcp. Additionally, SSH provides secure X11 connections
and secure forwarding of arbitrary TCP connections.
- Supports strong, proven authentication systems such as RSA, SecurID, S/Key, Kerberos and
TIS (as well as the usual UNIX username/password authentication).
- Three types of trust exist: shosts, rhosts compatible and RSA. RSA trust is stronger
(using a private/public key system to identify peers), but bypasses the username/password
authentication of UNIX.
- The SSH Server runs on UNIX, Linux and VAX.
Client runs on the above, plus Windows and many other platforms.
- Data compression can be enabled to improve performance over slow network links.
- SSH Internet Proxies:
- I don't know of any real working SSH proxies: Magosanyi Arpad started working on one
based on OpenSSH (see the OpenSSH developers list, message dated 2000-01-13
17:10:05), but hasn't time to finish it.
- SSH can be compiled so that it can traverse SOCKS proxies. SOCKS is a general proxy protocol, originally sponsored
by NEC, but now available from several vendors.
SSH2 is the new protocol version, submitted to the IETF for approval by SSH Communications. It is rewritten (improved cryptography)
and is designed for more general purpose VPNs. SSH2:
- Includes sftp, an SSH2 tunneled ftp.
- Uses separate config files to SSH1 (e.g. /etc/ssh2/ssh2_config), but can call SSH1 if a
client requests SSH1 protocols and SSH1 is available.
- Compatible with SSH1, when ssh1 has been installed prior to ssh2.
- DSA and Diffie-Hellman key exchange are supported.
- Because of the commercialisation (see licencing below), acceptance of SSH2 has been
slow.
Today there are many versions of SSH, some implement client only, some both client and
server. Commercial, freeware and "restricted freeware" licensing is in use. The
original SSH (SSH1) implemented by Tatu Ylen was free, but versions later than 1.2.12
have restrictive licensing. The current SSH1 v1.2.27 indicates that it may only be used
for non-commercial purposes only, but it would seem that most situations would allow free
usage:
For commercial licensing please contact Data Fellows, Ltd. Data Fellows has
exclusive licensing rights for the technology for commercial purposes.....
You may use the program for non-commercial purposes only, meaning that the program must
not be sold commercially as a separate product, as part of a bigger product or project, or
otherwise used for financial gain without a separate license...
Use by individuals and non-profit organizations is always allowed...
Companies are permitted to use this program as long as it is not used for
revenue-generating purposes..
SSH2 has a more restrictive licensing, basically meaning it is only free for non-profit
organisations:
NON-COMMERCIAL: any use that takes place in commercial,
governmental, military, or similar organizations and where a salary or similar monetary
compensation is paid, unless the use can be considered to be EDUCATIONAL USE or is purely
for charity.
Commercial versions are produced by DataFellows and cost about $99 for clients and $500
for servers.
SSH contains strong cryptography (no weak versions exist), which make it a no-no to
export from the U.S., under the current regulations (which will hopefully change in the
coming months). Luckily, SSH1 was developed in Finland meaning export to the U.S. and the
rest of the world is no problem.
The RSA algorithm is patented in the U.S., so U.S. users of SSH have to use RSAREF, an
official RSA library and pay royalties to RSA. This patent expires in September 2000
however.
Both of these issues make is very difficult for U.S. Operating System vendors to bundle
SSH with their product. OpenBSD (based in Canada) and S.u.s.e Linux (Germany) both bundle
SSH.
The IDEA algorithm is patented by Ascom in Switzerland (and only free for
non-commercial use), is used by SSH, but it can be disabled when compiling the SSH server.
- Proven technology - I've been using SSH for 4 years and find it to be robust and
reliable.
- Strong international encryption - and no watered down, weak versions exist.
- Both free and commercial versions exist.
- SSH client runs of most platforms, the server runs on UNIX, Linux and VMS.
- Tunneling of static TCP ports works well and can be automated to use for simple VPNs.
- Many authentication methods including Kerberos, TIS, SecurID and RSA.
- SOCKS5 proxy aware.
- Port ranges & dynamic ports can't be forwarded.
- Few Windows versions implement secure file copy or key generation.
- SSH1 daemon:
- Cannot restrict what ports may or may not be forwarded, per user.
- When a user is authenticated by password, the client's RSA identity is not verified
(against ssh_known_hosts). The verification only takes place when .[sr]hosts trust is
used.
- Performance can be a problem on old machines (e.g. Sun SPARC1 with 16MB of ram, but how
many of these are still around?)
- The standard SSH1 distribution's defaults include a clear text option and patented
algorithms such as IDEA. However, these can be switched off (see configuration section
below).
- Licensing of the original source has become very restrictive (see above).
SSH1 for UNIX is available as a free or commercial product (from DataFellows). It is the "original"
SSH, but is not being further developed at the moment (except for fixes). The emphasis is
now on the commercial SSH2.
- The author has been running the free versions V1.2.13 - 1.2.27 on the following
platforms for since late 1995: Solaris 2.4, 2.5, 2.6, 2.7, SunOS 4.1.3, OSF1.3, IRIX 5.3.
Works very well on Solaris, with some problems on IRIX.
- POP, SMTP, FTP authentication and other TCP socket sessions can be tunneled, e.g.
for SMTP:
ssh -L 25:mailhost.target.domain:25 target &
- V1.2.17 (and later) work with SOCKS5 proxies and SecurID authentication is also
supported (the author has used both since 1996).
- See the main FTP site: ftp.cs.hut.fi/pub/ssh
or one if it's mirrors such as ftp.cert.dfn.de/pub/tools/net/ssh
.
SSH2 from DataFellows is a commercial product for UNIX, Windows or Mac. There is a free version
for non-commercial use, but licensing is pretty restrictive. The SSH2 home page is www.ssh.fi.
LSH: Efforts are underway to develop LSH, a free
version of SSH2 www.net.lut.ac.uk/psst. It has
not yet reached a stable release status.
Mindterm is a free (GPL) SSH client written in 100% pure Java. It can be run as a
stand-alone program or as an applet in a webpage. It can be run with or without a GUI. It
has other useful features: scp - file copying and a special ftp-tunnel which works with
"ordinary" ftpd's "behind" the sshd.
The current version is v1.1.5, see
http://www.onlineitdegree.net/mindterm/ .
Mindterm SSH has been tested by the author for several months as a standalone application
(not an applet) on NT4, Win95 and Solaris 2.5:
- Multi-platform: should run wherever a JVM exists?
- Stable, pretty, flexible terminal emulation, saves properties per server, can generate
RSA keys, session can be logged to file, can be used as GUI or command line, X11 and port
forwarding works. Brilliant!
Some nifty extras: "clone terminal", "copy on select", capture to
file.
- It has scp (file copy) and ftp tunneling (in PASV
mode).
Example ftp tunnel instructions:
1) On Mindterm client: Go to menu Tunnels -> Basic... Enter a local port of your
choice.. Select protocol ftp... Give host-name of ftp-server behind sshd... Click Add
button
2) On the FTP client (e.g. ws_ftp): Define a new "site" with address
localhost... go to "Site properties"... in "folder" advanced set
"Remote Port:" to local port selected above... enable "Passive
transfers"
- Problems: no serious ones, but....
scp will only copy files to the connected server and does not understand target
syntax like john@server3:/mydir or ~john for home directories.
There's no online help (but the readme is good).
I've also had occasional blocked tunnels and had to restart.
The encryption algorithm can be set to none (not at all desirable!).
- TTSSH (TeraTerm SSH) -
free
- TTSSH is a SSH add on (DLL) to TeraTerm Pro (a free terminal emulation package) .
TTSSH www.zip.com.au/~roca/ttssh.html
TeraTerm hp.vector.co.jp/authors/VA002416/teraterm.html
- Version 1.4 of TTSSH (Dec'98) includes the following features: Compatible with SSH
protocol version 1.5 Ciphers: 3DES, IDEA, Blowfish, DES, RC4 Server authentication using
the ssh_known_hosts database (including the option of adding a server's key to the
database) Authentication using password, RSA, rhosts and rhosts+RSA. Compression support.
Connection forwarding, including full support for X connection forwarding.
- Note that the older V1.2 did not have X11 or port forwarding.
- I've tested V1.4 and am impressed, but it doesn't have the ftp tunneling or scp of
MindTerm. TeraTerm is a nice terminal emulation too, offering a good GUI and features such
as session logging and custom key mapping.
Tip: set TERATERM_EXTENSIONS=1 in your environment (so that Teraterm enables
extensions and presents SSH by default) and edit teraterm.ini
to change a few defaults.
- Other free Win32 implementations. Most of the following use the Cygnus Win32 libraries,
you'll need usertools.exe from sourceware.cygnus.com/cygwin/download.html
- F-Secure SSH for Windows (16 and 32 bit) from Datafellows (www.datafellows.com/f-secure) is
commercial.
- Well integrated into the Windows environment. Easy to use. Stable.
- Strong encryption: the DES, 3DES and Blowfish algorithms may be selected. This offers
military grade encryption strength (assuming the algorithms have been correctly
implemented!).
- Can forward encrypted TCP sockets for created simple VPN tunnels. Works with SMTP, POP3,
telnet etc. (where known static ports are used).
- Although only a 16 bit version is currently available (V1.1), it works fine with Win95
& NT4.
- Problems: There is no "secure file copy" feature, or ftp tunneling. Make sure
you use v1.1 rather than v1.0, which is a bit unstable.
- VanDyke SSH for Win32 (U.S. users
only). VanDyke offer a commercial 32bit client
that is user friendly, but obviously is U.S. export restricted. It has a worrying option:
it allows users to save passwords to allow "easier" login. See www.vandyke.com/products/securecrt/index.html
- An install tool for Linux RPMs was available at ftp.yellowdoglinux.com/pub/yellowdog/install-ssh.
- Compiling SSH1 for UNIX (the following examples are for Solaris) is straight forward.
Assuming we want the standard options, but want to disable clear text, the old RSH/rlogin
and avoid the IDEA algorithm:
gzcat ssh-1.2.27.tar.gz | tar xf -
cd ssh-1.2.27; ./configure --prefix=/usr --without-none --without-rsh --without-idea
make
make install
The SSH daemon will have to be added to one of the system startup files, it is not done by
"make install". An example for Solaris would be to create a startup file /etc/rc2.d/S10sshd.
- useful compilation options:
--without-idea Don't use the patented IDEA algorithm
--without-none: never allow clear text (unencrypted) communication if one of the
servers has no key.
--without-rsh: never allow rsh rhosts as an option when a server
has no key.
--prefix=/usr/bsd --sbindir=/usr/bsd --bindir=/usr/bsd : Installation in non standard
locations.
--with-securid=../ace
Add SecurID
authentication support (you need the ACE libs)
--with-socks5=/usr/local/lib Socks5 proxing support
- Preparing a binary install package: To make life easier, compile on (say) one machine as
above, then create a tar file of the binaries (in the C-Shell). The following also assume
that you have copied some SSH documents such as the FQ to /usr/localssh-docs.
tar cvf
ssh_bin.tar /usr/local/bin/{ssh,ssh1,scp,scp1,slogin}
tar uvf ssh_bin.tar /usr/local/bin/{ssh-keygen1,ssh-keygen,ssh-agent1,ssh-agent}
tar uvf ssh_bin.tar /usr/local/bin/{ssh-add1,ssh-add,ssh-askpass1,ssh-askpass}
tar uvf ssh_bin.tar /usr/local/bin/{make-ssh-known-hosts1,make-ssh-known-hosts}
tar uvf ssh_bin.tar /etc/{sshd_config,ssh_config}
tar uvf ssh_bin.tar /etc/rc2.d/{S10sshd,K10sshd} /etc/init.d/sshd
tar uvf ssh_bin.tar /usr/local/sbin/{sshd,sshd1}
tar uvf ssh_bin.tar
/usr/local/man/man1/{ssh-keygen.1,ssh-agent.1,ssh-add.1,ssh.1,ssh1.1,slogin.1,slogin1.1,scp.1,scp1.1,make-ssh-known-hosts.1}
/usr/local/man/man8/{sshd.8,sshd1.8}
tar uvf ssh_bin.tar /usr/local/ssh-docs
compress ssh_bin.tar
- Installing on a number of machines:
Copy ssh_bin.tar.Z (created in the last step) to the new target system,
backup any existing config files,
extract in root, "rehash" (if using csh) and then generate a host key:
ssh-keygen -b 1024 -f /etc/ssh_host_key -N '';
Add the ssh service, by adding the following to /etc/services:
ssh 22/tcp
# Secure Shell
Start the ssh daemon:
sh /etc/rc2.d/S10sshd start
- On OpenBSD 2.6, OpenSSH is already installed, but let's say you want to install SSH1 or
have an older version of OpenBSD and are not resident in the U.S., then either
1. Install the binary package for the appropriate OS version and architecture
pkg_add ftp.openbsd.org/pub/OpenBSD/2.6/packages/sparc/ssh-intl-1.2.27.tgz
2. Or get the sources and compile:
a) Update your ports listing if needed, but be aware that this takes time and you should
select your CVS target server carefully (see www.openbsd.org/anoncvs.html
):
setenv CVSROOT anoncvs@anoncvs.ca.openbsd.org:/cvs
For a new ports listing:
cd
/usr; cvs -q get ports
To update an existing version: cd /usr; cvs -q update ports
b) See what ssh versions are available:
cd /usr/ports; make search key=ssh
This reports that ssh-1.2.27 is available (for example) in
/usr/ports/security/ssh
c) cd /usr/ports/security/ssh;
make all install USA_RESIDENT=no;
This should download the source, plus a patch and compile it. If there
are are make problems, update the ports listing (above) and rebuild.
Use "pkg_info" to verify that it is registered as being installed on the system,
it can later be deleted with "pkg_delete".
- Configuration files: The server has a configuration file /etc/sshd_config,
the client reads a configuration file /etc/ssh_config, which gives site-wide defaults for
various options. Options in this file can be overridden by per-user configuration files
(in ~user/.ssh directory).
- Server: Configure the ssh daemon so that access is restricted to named hosts with known
public keys (/etc/ssh_known_hosts) and rhosts authentication is disabled. See
commented example /etc/sshd_config, In particular, look at
options such as:
- The StrictHostKeyChecking option can be used to
prevent logins to machines whose host key is not known or has changed. If this flag is set
to "yes", ssh will never automatically add host keys to the /etc/ssh_known_host
or $HOME/.ssh/known_hosts file, and refuses to connect hosts whose host key has changed.
This provides maximum protection against trojan horse attacks. For many Administrator
situations setting this flag to "ask" to prompt the user about whether to add
the key to the known list of hosts is ideal.
- RhostsRSAAuthentication when set to yes, allows ~/.shosts to define trust
relationships. It may be set to "yes", "nopwd", or "no". The
"nopwd" value disables password-authenticated root logins, unless there is an
.shosts allowing access without a password.
Root login with RSA authentication when the "command" option has been specified
will be allowed regardless of the value of this setting (which may be useful for taking
remote backups even if root login is normally not allowed.
- An empty config file can be placed in the users home directory owned by root and
writeable only by root. This will force the system wide settings for all users.
- Use at least v1.2.26 to ensure forward compatibility with SSH2.
- Logging in without passwords:
- Avoid if possible, but if necessary, setup carefully. Use .shosts rather than .rhosts.
Make sure trust files have mode 400. Don't use trust on NFS shared home directories.
- Setting up /.shosts root trust from host A to host B: Add hostA to /.shosts and
/etc/hosts on hostB, add the Public Key of HostA to /etc/ssh_known_hosts or
~/.ssh/known_hosts.
- Setting up RSA trust from host A to host B: The .ssh/Identity.pub (public key) of the
host A needs to be appended to the list of keys in .ssh/authorized_keys on the destination
machine.
- Client configuration: Configure the system wide defaults for the SSH client. See
commented example /etc/ssh_config
- SSH and SUID root security:
SSH installs two programs that need special privileges. Ssh is the client program, and it
is by default installed as suid root, because it needs to create a privileged port in
order to use .rhosts files for authentication. If it is not installed as suid root, it
will still be usable, but .rhosts authentication will not be available. Also, the private
host key file is readable by root only.
Sshd is the daemon that listens for connections. It should preferably be run as root,
because it is by normally listening on a privileged port (22), and it needs to be able to
do setuid(), update utmp, chown ptys etc. when a user logs in. If it is not run as root,
explicit "-p port" option must be given to specify an alternate port (same port
must also be specified for clients), "-h host_key_file_path" must be given to
specify an alternate host key file, and it cannot be used to log in as any other user than
the user running it (because it cannot call setuid()). Also, if your system uses shadow
passwords, password authentication will not work when running as someone else than root.
Both the server and the client have been carefully screened for possible security
problems, and are believed to be secure. However, there can be no guarantee.
- Installation on Windows (tested with v1.1.2, current version is v1.1.5):
Get it from www.mindbright.se/mindterm
and install a Java Runtime v1.1 from Sun,
Or, download mindterm_install.zip (2MB
file with Java runtime v118 and Mindterm V1.1.5), extract to C:\Progra~1, then setup a
shortcut on your desktop to c:\Progra~1\mindterm\mindterm.bat . This will work with
English, French, German and Italian (hence the use of the short name).
- Installation on Solaris:
- An example startup script for Solaris is mindterm.sh. Copy
this along with mindterm.zip to /usr/local/bin .
- InstallJava(already installed on newer Solaris, make sure you have v118 or
later).
- Make sure /usr/local/bin is in your path and then just type mindterm.sh.
- SSH1:
- SSH1 can easily forward single sockets (POP3, SMTP, etc..) out of the box, with either a
PC or UNIX client, e.g. ssh -L 25:mailhost.target.domain:25 target &
SSH cannot tunnel dynamic ports or ranges. Mindterm SSH include an option for FTP
tunneling.
- If PPP is redirected over an SSH socket, SSH can be used as a general purpose VPN. A
practical example using Linux as a gateway on both sides is described the O'Reilly book "Virtual Private networks, 2nd Edition", chapter7 and more information is
at sunsite.unc.edu/LDP/HOWTO/mini/VPN.html.
You'll need Linux on both sides and it's a bit tricky (dated 1997). I've not yet tried
this.
- Try also sites.inka.de/sites/bigred/sw/ssh-ppp-new.txt
(dated 1996)
- Rdist 6.1.2 (public domain version) runs over SSH (tested on Solaris 2 &
SunOS) and can be used o synchronise file between two hosts, or report on differing files.
- Fsh is an add-on to keep an SSH tunnel open to allow several commands to be
remotely executed without reopening the tunnel each time www.lysator.liu.se/fsh. I've not yet tried this.
- Using SSH with RPC/keyserv/NFS/NIS+ : see fy.chalmers.se/~appro/ssh_beyond.html
- Jean Chouanard has produced SecurID/ACE patches for SSH1 that add support for the
"New Pin" and "Next Token", but which only work if both SSH server and
client are modified accordingly. There is no sign of these patches being integrated into
OpenSSH of Mindterm SSH just yet. See ftp.parc.xerox.com:/pub/jean/sshsdi/README
- Virtual Network Computing is a
"remote control" program that allows you to see and use the desktop of another
machine (NT, Win95, UNIX) over the network. It could also be used for teleworking over
insecure networks such as the internet. Or SSH can be used to encrypt the VNC
communications and hence increase it's security.
- Install an NT VNC server on the intranet, one which is part of the usual NT domain and
has accounts for those who need to logon. [It could also be UNIX, I'm just using NT as an
example].
Secure this machine by choosing a strong VNC password, enabling exclusive VNC
access, by enabling a screen saver with password after 5 minutes of inactivity and by not
putting it in a public area. Regularly monitor the event log.
- Install an Intranet UNIX SSH server.
- Install a SSH internet gateway, which allows SSH connections from the Internet.
Successful logins are presented directly to the Intranet SSH server.
Security: Put this host in the DMZ between two secure firewall filters. Harden.
Disable all services except SSH. Allow no protocols except SSH from the Internet.
Configure SSH to refuse root logins and disable trust mechanisms and RSA authentication.
Configure all user accounts to use a strong authentication mechanism such as
SecurID. Configure user shell to automatically login use to the Intranet UNIX server
(don't allow local logins to this server). Be paranoid, monitor logs carefully and run
integrity checks (such as tripwire) frequently.
- Install an SSH client such as Mindterm on the VNC client (somewhere on the
Internet).
- SSH Client configuration: Connect to SSH gateway and authenticate with SecurID (or
whatever). Login to UNIX Intranet server. Setup tunnel from local port 5902 to NT_VNC_server
port 5900.
- VNC Client: Start local VNC client, connect to localhost:2, enter the VNC password and
voila, the desktop should appear. Now login to NT as usual.
- Security: I suggest you use you own machine (not one in an Internet Cafe), with
an up-to-date Virus checker, File shares disabled, and a personal firewall such as BlackICE installed (and set
protection level to Paranoid, no file sharing). This machine should be physically
protected and possibly fitted with encrypted disks (e.g. PGPdisk).
- Security Portal Research Centre
- Documentation:
SSH FAQ www.employees.org/~satch/ssh/faq
Getting Started with SSH by Kimmo Suominen www.tac.nyc.ny.us/~kim/ssh
- Getting SSH
See the links in the Implementation section above.
- Search for SSH pages on the net: www.links2go.com/topic/SSH
SeáÏ Boran is an IT security consultant based
in Switzerland and the author of the online IT Security Cookbook.
Last
Update: 03 February, 2000
Ž© Copyright 2000, SecurityPortal Inc., All Rights Reserved
|
