All About SSH - Part I/II

Replacing telnet/rlogin/rsh with SSH
See also Part II (OpenSSH)

By Sean Boran
www.boran.com/security/sp/ssh-part1.html 

This article presents an overview of SSH, the Secure SHell. This is the first in a two part series, introducing SSH and implementations, except OpenSSH & OSSH which are presented in an accompanying Part2.

SSH is useful, easy to use and so much more secure than the archaic telnet/rlogin/rsh, that no UNIX/Linux system should be installed without it. 

Dec. 2002 (3 years after this page was first published) it's great that most Linux / Unix vendors have followed the example of OpenBSD & SuSE and bundled SSH with the OS. SSH has become the standard workhose for many sysadmin tasks, but has also had security bugs, possibly making your system more insecure than if using a simple telnet! Even SSH is not immune to the tiring vulnerability-patch-update cycle. So keep your SSH servers up to date.....

Italian Readers: Please note that an earlier version of this article has been translated into Italian [9].

1. SSH Overview

   • Why SSH? | Features | Licensing & cost
   • U.S. Export and Patent Restrictions
   • Advantages | Disadvantages | Security Vulnerabilities
    
2. Implementations
   • SSH for UNIX/Linux :  SSH1, SSH2 , LSH, FreSSH, sftp
   • Mindterm SSH (Java SSH client)
   • Windows SSH clients | SSHD servers
   • Mac
   • Other architectures: Mac, Palm Pilot, VAX
     
3. Compiling & Configuring
   • SSH1 Compiling | Configuration
   • Mindterm SSH client installation
     
4. Doing even more with SSH: VPNs, VNC, PCAnywhere, SecurID, rdist, fsh, Citrix
5. References

SSH Overview

Secure Shell (SSH) was originally authored by Tatu Ylönen, 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 and S/KEY to provide a highly secure remote access point to UNIX servers.

SSH1 was the first implementation (protocol v1.2 and v1.5) that was free in the earlier days, but licensing has become very restrictive, SSH Communications and DataFellows [3] are trying to get people to move to the newer commercial SSH2. OpenSSH (a free alternative discussed in [1]) supports both v1 and v2 protocols.

Why SSH?

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, SSH 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.

Features

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 [0] proxies. SOCKS is a general proxy protocol, originally sponsored by NEC, but now available from several vendors.

SSH2 is the newer protocol version, submitted to the IETF for approval by SSH Communications [3]. It is rewritten (improved cryptography) and is designed for more general purpose VPNs. SSH2:

• Includes sftp, an SSH2 tunnelled 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. (OpenSSH supports both, seamlessly).
• DSA and Diffie-Hellman key exchange are supported.

Licencing and Cost

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 Ylönen was free, but versions later than 1.2.12 have restrictive licensing. The last more-or-less free 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..

The latest SSH1, v1.2.31 has the same restrictive licensing as SSH2, 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.

These means that for most of use SSH1 and SSH2 cannot be used freely, which explains why OpenSSH is becoming the predominant SSH server in use. [1]

Commercial versions are produced by DataFellows/SSH Communications and cost about $99 for clients and $500 for servers (the NT server is a shocking $850).

U.S. Export and Patent Restrictions

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., but the patent expired in September 2000, so U.S. users of SSH no longer have to use RSAREF, the official RSA library or pay royalties to RSA.

Hopefully, more U.S. Operating System vendors will bundle SSH with their products soon. OpenBSD, RedHat and SUSE. Linux all bundle OpenSSH.

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.

Advantages

• Proven technology - I've been using SSH since about the mid nineties 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.
• Tunnelling of static TCP ports works well and can be automated to use for simple VPNs.
• Many authentication methods including Kerberos, TIS, SecurID and RSA.
• Can be SOCKS5 proxy aware.

Disadvantages

• Port ranges & dynamic ports can't be forwarded.
• SSH server 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).
• Port forwarding can also introduce security problems, is not used correctly. The SSH server doesn't allow detailed configuration of what forwarding is allowed from what client to what server etc.
  In addition, a client on the Internet that uses SSH to access the Intranet, can expose the Intranet by port forwarding, which is why I recommend PCs directly on the Internet to install a personal Firewall such as BlackICE.

Security Vulnerabilities

The following is a list of vulnerabilities found in different SSH implementations, see [2] for links to more detailed discussions of this issues on SecurityFocus.

• 2000-07-05: SSH 1.2.27 Kerberos Ticket Cache Exposure Vulnerability
  A vulnerability exists in SSH 1.2.27, when compiled with Kerberos support. When logging in, the sshd process sets the KRB5CCNAME to 'none'. This environment variable is used by Kerberos to set the location of the credential cache. Normally, the cache is created in /tmp, or somewhere on the local filesystem, to prevent Kerberos credentials from being passed over the network through NFS, or some other insecure protocol. As the environment variable does not explicitly set a path, it is always ".". As such, if a user uses Kerberos at any point during their ssh session (from the machine they ssh'd in to), a file named 'none' will be created in whatever directory they are in, containing their Kerberos credentials. This may lead to this data residing on an NFS volume, which could allow others to read it, or may create it in a location where other users have access to it.
  
• 2000-06-12: FreeBSD Alpha Port Lack Of /dev/random and /dev/urandom Vulnerability
  Distributions of FreeBSD for the Alpha architecture shipped without the /dev/random and /dev/urandom devices. These devices can be used by products and tools to gather entropy for generating cryptographically strong random numbers. Software that does not detect whether opening and reading from the devices fails or not before generating these random numbers may be vulnerable to simplified cryptanalysis against the weakened keys that would be produced. OpenSSL version 0.9.4 and OpenSSH both lacked checks and were vulnerable to this problem.
  
• 2000-06-08: OpenSSH UseLogin Vulnerability
  An option can be set to use the login program (the option is 'UseLogin') - this is set to 'no' by default in most distributions. When UseLogin is turned on, sshd doesn't set the uid of the person logging in to what it should be, it remains running as root. This can be exploited if a command is specified (to be executed) on the target host running sshd via the ssh client. Since instead of logging in, a command is being run, "login" is not used and therefore cannot set the correct userid. Any command executed remotely via ssh where "UseLogin" is on will execute as root, leading to a trivial compromise.
  OpenSSH 2.1.1 is fixed and is not vulnerable to this attack.
  
• 2000-06-07: FreeBSD SSH Port Extra Network Port Listening Vulnerability
  A vulnerability exists in the FreeBSD 'ports' version of SSH. A patch was added to allow sshd to listen on multiple ports. At the same time, the configuration file was inadvertently altered to make sshd listen on both port 22, which is normal, and port 722. This could affect users who are firewalling off services, and do not realize sshd is running on port 722.
  This does not represent a vulnerability in sshd. It is a misconfiguration only. In addition, this vulnerability is unlikely to have any real impact in normal scenarios, as the sshd listening to port 722 behaves as normal; authentication is still required.
  
• 2000-05-10: Zedz Consultants ssh-1.2.27-8i.src.rpm Access Verification Vulnerability
  A flaw exists in the RedHat Linux RPM distributed by Zedz Consulting, version 1.2.27-8i. This is NOT a flaw in ssh, or sshd, but rather in the patch applied in the RPM distributed.
  
• 2000-02-24: SSH xauth Vulnerability
  A vulnerability exists in the default configuration of SSH that could be used to compromise the security of a client machine. By default, ssh will negotiate to forward X connections, using the xauth program to place cookies in the authorization cache of the remote machine for the user logging in. If the xauth program on the remote host is compromised, or the superuser on the remote host cannot be trusted, the xauth key can be compromised, and used to connect to the client machine. This can result in a wide range of compromises on the client host.
  Risk: local+remote weakness, no exploits known.
  Vulnerable: SSH 1.2.27 or earlier, SSH2.0.12 or earlier. OpenSSH 1.2 is not vulnerable.
  Fix (workaround): disable X forwarding.
  
• 1999-12-01: RSAREF Buffer Overflow Vulnerability
  Some versions of sshd are vulnerable to a buffer overflow that can allow an intruder to influence certain variables internal to the program. This vulnerability alone does not allow an intruder to execute code. However, a vulnerability in RSAREF2, which was discovered and researched by Core SDI, can be used in conjunction with the vulnerability in sshd to allow a remote intruder to execute arbitrary code.
  Risk: local+remote weakness, no exploits known.
  Vulnerable: SSH 1.2.27 linked against RSAREF, F-Secure SSH versions prior 1.3.7 are vulnerable but F-Secure SSH 2.x and above are not.  OpenSSH 1.4 & OpenSSL 0.9.4   are not vulnerable.
  Fix: Install patch or use International RSA libraries. CORE SDI has developed a fix for RSAREF.
  
• 1999-09-17: SSH Authentication Socket File Creation Vulnerability: A vulnerability in SSH's creation of the authentication agent UNIX domain socket allows local users to create a UNIX domain socket with an arbitrary file name in the system....
  Vulnerable: SSH 1.2.27. Linux 2.0.x, Solaris 2.5.1 and IRIX 6.5.2 do not follow symbolic links (=> not affected) during bind(2). Linux 2.1.x does.
  Risk: local weakness, no exploits known.
  
• 1999-05-13: Secure Shell Password Brute Force Vulnerability (SSH2).
  
• Marc SCHAEFER [4] reports the following vulnerability, there is no official bulletin, since it's not actually a SSH weakness, but an effect of using special shells on non-blocked accounts.
  If you have a UNIX machine running ssh where you have legitimate shell users but also POP-only or FTP-only users with an account and a correct password and those users are refused connection because their shell is /bin/false or /bin/passwd or whatever, those users can use ssh to open connections coming from YOUR machine (and with a wrong IDENT, but that's a general SSH issue). In no case will those users be able to run a shell on the server.
  Workaround: change /etc/sshd_config or equivalent to deny SSH access for those users (DenyGroups guests), or only grant access to specific groups (AllowGroups).

Implementations

SSH server & client for UNIX/Linux

SSH1 for UNIX is available as a free [5] or commercial product [3]. 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.30 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 for versions prior to 1.2.27.
  
• POP, SMTP,  FTP authentication and other TCP socket sessions can be tunnelled, 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).
  
• The License has become increasingly restrictive and the last version I checked v1.2.31 is no longer free in any meaningful way. 

SSH2 [3] is a commercial product for UNIX, Windows or Mac. There is a free SSH2 version for non-commercial use, but licensing is pretty restrictive.

LSH: Efforts are underway to develop LSH, a free version of SSH2 - see http://www.net.lut.ac.uk/psst.

FreSSH: Unlike various other SSH implementations already available for Unix, it does not trace its ancestry to the original SSH code written by Tatu Ylonen. FreSSH currently implements SSH protocol version 1.5, with extensions which offer enhanced security when both sides of a connection are running FreSSH. The current version is v0.81 (15.Feb.01), a pre-release. It only runs on UNIX systems with a /dev/random. See http://www.fressh.org

sftp: is an ftp client and server that runs over an SSH tunnel. Currently at v0.7, it runs on Linux and NetBSD. http://www.xbill.org/sftp  

Mindterm SSH (Free Java SSH client)

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.
Mindterm is my 2nd favourite SSH client after pscp/putty (see pscp) - it would be my favourite if the latest version was completely free...

There are several versions, see www.appgate.com/mindterm which the author has been using for since December 1999 months as a standalone application.

• V2.3.1 is the current version, free for "up to 100 users". Works fine.
  
• V2 is stable,  licensing is free except for "multi-user corporate usage". SSH2 protocol is well supported, terminal handling of International keyboard works correctly, but there are problems with the '!' character.
• v1.21 does not handle characters like \@[] properly on international keyboards. 'scp' works better than v1.15, but it still buggy.
• v1.15 is older, but special characters like \@[] work correctly on international keyboards. However scp is buggier and I often get spurious tildes "~" when typing quickly.
• v2.0 rc2 has a faulty SCP, still has problems with the '!' character and 'clone' does not always work. Otherwise it's very good indeed.

  			Tip for Windows users: I have a zip that includes mindterm, java, putty, pscp, ixplorer, winscp. However I don't update it that often, so check the versions used.. mindterm_install.zip

  
  

Advantages:

• 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 - secure file copy and can do recursive copies of directories. A "low priority" option to transfers files in the background without hogging all the bandwidth is available (very useful when working over isdn or dialup).
  
• Mindterm allows ftp tunnelling (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"
     
• Both RSA and RSA-Rhost authentication can be used (by generating an RSA key with "Create RSA Identity" and copying it to either known_hosts or authorized_keys on the server side).
  
• Optional compression of traffic.
• SSH2 protocol in 1.99 and later.
• SecurID authentication is supported.

Problems:

• scp: When 100% is reached during file copy, Mindterm blocks for a while before saying "done" (basically the progress bar isn't quite accurate).
• There's no online help (but the readme is useful).
• I've also had occasional blocked tunnels and had to restart (versions <1.2.1)
• scp refuses to copy files occasionally  with "permission denied", although file permissions are fine. This is a difficult one to reproduce, but annoying (versions <1.2.1).
• Long files with spaces on Windows are badly supported.
• The encryption algorithm can be set to none (not at all desirable!).
• 'Clone terminal' does not always work (versions <1.2.1).

Suggested Improvements:

• Mindterm Security tip: In versions prior to ~V2.1 there seems to have been a default of "local-bind=0.0.0.0", which made local tunnels visible on your Workstation to remote machines. Remove this entry from your configuration files, and if you use tunnels extensively, do a scan on your workstation now and again to make sure the tunnels are limited to "localhost" only.
• scp:
  - Remember scp source and destinations (in the server properties files).
  - Allow copying of several files (multiple control-clicking on source files).
  - Support syntax such as  bob@server3, ~john, dir/{file1,file2,file3}.
  - Add an arrow to the scp dialog to show transfer direction (so user will make fewer mistakes).
  - Consider listing local files on the left, remote on the right, like in ftp programs.
  - Improve handling of long file names, spaces, Windows drive letters.
• Terminal: Paste buffer with right click (as well at Shift-Insert).
• Allow editing of security properties when connected, even if they won't be active until the next connection. Allow editing of a hosts security properties before a connection is established.
• Online help & faq.

Windows SSH clients

Aside: the OpenSSH crew have started keeping track of various Windows implementations, see http://www.openssh.org/windows.html

• PUTTY: http://www.chiark.greenend.org.uk/~sgtatham/putty.html v0.53b [Recommended]
  Simon Tatham has developed PuTTY and pscp, a free Win32 SSH/Telnet client. It is stable, fast, quite small, but comprehensive.
  Putty has a useful GUI (makes configuration easy), whereas pscp and sftp are pure command-line file copy (but nice) secure copy tools. Plink is the command line equivalent to putty (terminal login). TIS, password and certificate authentication is supported as is compression and the SSH2 protocol. The product has evolved quickly since 2000 and now is one one of the best SSH clients around.
  v0.51 includes fixes for Security problems noted on Bugtraq in 2000.
  Problems:
  • pscp does not set %ERRORLEVEL% correctly if username or password are wrong.
    
    
• Winscp A great windows tool that will allow you to replace FTPD with SSHD, is Winscp by Martin Prikryl http://winscp.vse.cz/eng, it's GUI is good enough that non techie users can find their way around it.
  
  
• TTSSH (TeraTerm SSH) - free
  • TTSSH is a SSH add on (DLL) to TeraTerm Pro (a free terminal emulation package) .
    TTSSH http://www.zip.com.au/~roca/ttssh.html
    TeraTerm http://hp.vector.co.jp/authors/VA002416/teraterm.html  
  • Version 1.5.3 disables IDEA and RC4 algorithms to avoid SSH1 protocol problems.
  • Version 1.4 of TTSSH (Dec'99) 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 RhostsRSA. 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 tunnelling 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. It is faster than Mindterm.
    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.
    
    
• iXplorer by Lars Gunnarsson is another GUI front end for scp. Is uses putt's pscp as the backend, see http://www.i-tree.org.   I had some difficulty getting it to work.
  
  
• Other free Win32 implementations. Most of the following use the Cygnus Win32 libraries, you'll need usertools.exe from http://sourceware.cygnus.com/cygwin/download.html . See also http://cygwin.com .
  • Gorden Chaffee's command line port of ssh1 & scp1 http://bmrc.berkeley.edu/people/chaffee/winntutil.html
  • Raju Mathur/Gordon Chaffee wrote a Win32 patch for ssh-1.2.14, the binaries are in ftp.cs.hut.fi/pub/ssh/contrib. There's also a ssh-1_2_22-Win32-Beta1.
    Installation notes:
    Create a c:\ssh\etc directory to ssh_config, ssh_host_key, and ssh_host_key.pub. Generate keys on Unix with ssh-keygen (ssh-keygen doesn't work on NT). 
    Set the your HOME environment variable (via Control Panel->System).
    Create a <HOME>\.ssh directory and copy in your identity and identity.pub files (generated above by ssh-keygen)
  • A version based on 1.2.20 that hasn't been further developed, is at http://guardian.htu.tuwien.ac.at/therapy/ssh
  • Cedomir Igaly offers a free 16 and 32 bit version without sources It uses Peter Gutmann's cryptographic library on Garbo. See http://ns.cronet.com/ssh or http://www.doc.ic.ac.uk/~ci2/ssh. There have been no updates since 1998.
  • Sergey Okhapkin's SSH1 & SSH2 32bit servers/clients http://www.lexa.ru/sos
  • FiSSH is a free 32-bit SSH1 client http://www.massconfusion.com/ssh soon to be released. 
  • Cygnus Win32 port of SSH 1.2.2 by Raju Mathur  http://reality.sgi.com/raju/software.html or
    http://www.hirmke.de/software/develop/gnuwin32/cygwin/porters/various/ssh-1.2.22-win32-beta1.README
  • Cygnus Win32 port of SSH V1.2.26 from Francis Chang http://www.hirmke.de/software/develop/gnuwin32/cygwin/porters/Chang_Francis/B20/ssh-1.2.26-cygwin-b20.README
    
    
• Absolute Telnet from Brian Pence is a pretty complete commercial solution with integrated SFTP file transfer http://www.celestialsoftware.net. There are some interesting features in the myriad of options like multiple tear-off tabs, as well as integrated telnet and serial terminal support.
  Support for importing putty configs and using putty keys would have been nice.
  
• F-Secure SSH for Windows (16 and 32 bit) from Datafellows [3] 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 tunnelling. Make sure you use v1.1 rather than v1.0, which is a bit unstable.
    
• SSH Communications [3] have release a beta version of an SSH2 Windows Client that contains a tunnelled ftp GUI.
  
• 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  http://www.vandyke.com/products/securecrt/index.html   
  
• SSHTools is a new suite of open source Java based SSH2 components. According to www.sshtools.com the tools are in early alpha release, but look very interesting:
  • J2SSH is SSH2 library designed in such a way that simplifies the development of plug-in extensions which may include additional ciphers, authentication mechanisms and so forth.
  • SSHTerm is a terminal client application allowing remote connections to any RFC compliant SSH server.
  • Windows SSH Server is an implementation of a Windows SSH server achieved through the extension mechanism of the J2SSH library.
  • Additionally, there is also an SFTP client currently under development.
• ZOC Telnet/SSH (Shareware) http://www.emtec.com/zoc/index.html
  • Windows Telnet and SSH (Telnet, Rlogin, SSH V1 and V2)
  • 3des, blowfish, arcfour, cast128 encryption, RSA and DSA keys
  • Username/Password, Public/Private Key and Keyboard Interactive authentification
  • SSH Tunneling

Windows SSHD servers

Recently a few NT SSH servers have popped up. These new beasts are interesting, but either difficult to setup or no so easy to use.

SSH daemon for NT #1
http://www.shebeen.com/files/sshdnt.zip

This is the first SSH server I've come across for NT and looks interesting. It is without source code, but seems to be UNIX SSH 1.2.26 ported used the Cygnus libraries and uses UNIX-like configuration files.

• The install.bat script installs scp, ssh-keygen and sshd in %systemroot%\system32, configuration files in c:\etc, a Bourne shell (sh.exe) in c:\bin, generates an SSH host key and starts SSHD as a proper service. It also stops and starts VNC (if you have it).
  
• If not installing as Administrator, try the modified install.bat that (ignores VNC and) works for Users other than Administrator (but with admin rights). http://www.boran.com/security/sp/ssh/sshd_nt_install.bat
  Also, put your user name in \etc\passwd (all NT users allowed to receive SSH requests must be listed), then regenerate the HOST key and start sshd:
  ssh-keygen -b 1024 -f /usr/local/etc/ssh_host_key -N ''
sshd

• Advantages
  • Although it requires a bit of effort to get going, this is an excellent tool for securely transferring files from a UNIX to an NT box.
  • NT account authentication is used rather than separate passwords.
  • The default configuration in sshd_config is quite tight.
  • The NT Application event log is also used (by default debug messages are sent).
  • Everything is in c:\winnt. No /etc or /usr directories are needed.
    
• Disadvantages:
  • Sources code not available.
  • More documentation of the exact sources used and modifications would be welcome.
  • The scp included is basic and no ssh client is included. So, you'll still need your favourite SSH client (putty, Mindterm, etc.)
  • No ssh client.
  • No deinstallation script.
    
• Tests
  • Using putty's command-line SSH plink, an SSH login to localhost was tested (an entry in /etc/passwd for the test account was created first).  Using vim or edit remotely to edit a file did not work, but browsing around the directories did.
  • Using putty's command-line SSH pscp, a file was download c:\cmd.exe. Note that the root directory seems to be drive C by default.
    pscp -v joe_bloggs@localhost:/cmd.exe
  • Further extensive tests with access control, trusts, RSA authentication etc. are really required....

SSH daemon for NT #2
http://marvin.criadvantage.com/caspian/Software/SSHD-NT/default.php
http://www.lexa.ru/sos

An NT SSH server, with a slightly different focus. It is based on Sergey Okhapkin's SSH1.2.26 port, which uses the Cygnus libraries and UNIX-like configuration files. Diffs are available from the original SSH sources. Below we test v1.02.

• The account used to run the SSHD service has to be setup. The account's rights required are "Act as part of operation system", "Replace a process level token", "Increase quotas" and "Logon as a service".
  
  Note: the "Administrator" account does NOT have the necessary rights by default. Re-login if you added these rights to the account you are currently logged in.
  
• The setup.bat script installs sshd, ssh-keygen, sshd_config in %systemroot% (C:\winnt), generates an SSH host key and starts SSHD as a proper service.
  
• Advantages
  • NT account authentication is used rather than separate passwords.
  • The default configuration in sshd_config is quite tight.
  • The NT Application event log is also used.
    
• Disadvantages
  • Sources code not available.
  • More documentation of the exact sources used and modifications would be welcome.
  • no scp or ssh client.
  • No deinstallation script.
    
• Tests
• Using putty's command-line SSH plink, an SSH login to localhost didn't want to work, it hung at the prompt.

  plink -v joe_bloggs@localhost

• Using putty's command-line SCP pscp, a file was downloaded "c:\cmd.exe" successfully. Note that the root directory seems to be drive C by default.

  pscp -v joe_bloggs@localhost:/cmd.exe

• Further extensive tests with access control, trusts, RSA authentication etc. are really required....

SSH daemon for NT #3: OpenSSH + Cygnus

OpenSSH can also be persuaded to run as a server on Windows. This is discussed in Part II of this article.

SSH daemon for NT #4: Bitvise

I've not tried this product but it looks promising. http://www.bitvise.com/winsshd.html 

"WinSSHD is a Windows NT4/2000/XP SSH Secure Shell 2 server that supports the following SSH2 services:
- secure remote login with console (VT100 and xterm with colour support out of the box, as well as many other terminal emulations); secure remote login with GUI (see Using WinSSHD with WinVNC); 
- secure file transfer using the SFTP protocol - WinSSHD's integrated SFTP server replaces FTP seamlessly with clients such as ssh.com's SSH2 client, or CuteFTP Pro; 
- secure file transfer using the SCP protocol; 
- secure TCP/IP port forwarding: most TCP/IP connections can be secured with SSH2. 
Also, WinSSHD is:
- well-integrated with the Windows NT/2000/XP platform; compatible with Windows domains - works well with local as well as domain users; 
- easy to install: it uses the standard Windows Installer installation mechanism; 
- simple to configure and maintain  
- available for a free 30-day evaluation period. The cost of a WinSSHD license is USD 29.95 for personal use, and USD 99.95 for business use."

SSH daemon for NT #5: F-Secure & SSH Communications

Commercial product exist from F-Secure and from SSH communications [3]. They cost $850.-  and $595.-per seat. A brief test of the SSH communications versions worked just OK for remote terminal access. The default configuration is quite permissive and I have problems getting scp (file copy to work), interactions with OpenSSH is very bad. Test it before you buy.
See also a review at: http://www.networkcomputing.com/1206/1206sp3.html

 

Further reading on NT SSH servers:
http://www.certaintysolutions.com/tech-advice/ssh_on_nt.html

 

Macintosh SSH Versions

1. NiftyTelnet SSH is a free ssh client for MacOS. It is an enhanced version of NiftyTelnet.
   Datafellows produce  a commercial Mac client: http://www.datafellows.com/f-secure.
   
2. Another is MacSSH www.macssh.com
   
3. dataComet-Secure, www.databeast.com 
   This commercial packages costing around $60 provides terminal emulation over SSH, Telnet, and dialup connections, supporting both SSH1 and SSH2. Telnet sessions offer Kerberos 5 and SOCKS v4 security options. (NOTE: SSH port forwarding is not yet supported.) dataComet-Secure emulates colour VT100 - VT320, PC-ANSI, SCO-ANSI, and IBM-3279 terminals, with file transfer support for SCP, X/Y/ZModem, and IBM IND$FILE. Sessions can be scripted using AppleScript and built-in macro support, with automatic macro recording and an easy-to-use key re-mapping dialog.

 Other Architectures

• Matthias L. Jugel and Marcus Meißner have developed a Java Telnet Application/Applet. http://www.mud.de/se/jta
  
• Cédric Gourio also developed a Java based SSH, java-ssh,  for his diploma  - http://www.cl.cam.ac.uk/~fapp2/software/java-ssh

• Based java-ssh, Rob Pitman has developed JSSH, which is not a complete GUI client, but a Java "component" designed to allow a developer to embed SSH functionality into a larger application.
  http://www.pitman.co.za/projects/jssh/index.html 
  
• Palm Pilot
  Top Gun ssh 1.2 at www.isaac.cs.berkeley.edu/pilot or ftp.zedz.net/pub/crypto  outside the US.
  
• Windows CE: Mov Software has released sshCE. www.movsoftware.com/sshce.htm
  
• BeOS: The  BeOS R4 port of SSH1 for Intel and PowerPC is available from www.be.com/beware/Network/ssh.html
  
• OS/2: See ftp://hobbes.nmsu.edu/pub/os2/apps/internet/telnet/client/ssh-1.2.27-b1.zip for OS/2 Warp 3+.
  
• VAX/OpenVMS
  David Jones has created an OpenVMS SSH1 server http://www.er6.eng.ohio-state.edu/~jonesd/ssh.
  Christer Weinigel and Richard Levitte have created an OpenVMS SSH1 client http://www.free.lp.se/fish.
  
• Nokia firewalls (based on Firewall-1 and a hardened FreeBSD) have an SSH option - use it and disable telnet/ftp!
  
• "LADON, A Distributed Authentication System for SSH using DNSSEC"
  http://www.cs.jhu.edu/~smang/sshproject.html
  
• ScanSSH: What SSH servers are installed on your network?
  Provos - http://www.monkey.org/~provos/scanssh
  ScanSSH scans a list of addresses and networks for running SSH servers and their version numbers.
  
• Windows CE: PockeTTY provides Telnet, SSH and Serial access on PDAs.
  http://www.dejavusoftware.com/pocketty/index.html 

---

Compiling & Configuration

SSH1 Compilation

Note this section is old: you really should not be using SSH1. Move to OpenSSH, which is discussed in Part II of this article.

• SSH1 comes preinstalled on SuSE Linux 6.3 and OpenBSD 2.6.
  
• 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.30.tar.gz | tar xf - 
  cd ssh-1.2.30; ./configure --prefix=/usr --without-none --without-rsh --without-idea
  make
  make install
  
  Note: There were problems compiling 1.2.30 on Solaris Intel, but v1.2.27 works fine (but it has security problems when used with Kerberos).
  
• SSH startup files: 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.
  • For Red Hat Startup, copy a startup file (example sshd) to /etc/rc.d/init.d/ssh and setup links:
    chkconfig --add ssh
    
• 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 FAQ to /usr/local/ssh-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

• BSD (OpenBSD, FreeBSD):
  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:
     
  1. 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
     
  2. 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
     
  3. cd /usr/ports/security/ssh;
       make all install USA_RESIDENT=no;
  3. This should download the source, plus a patch and compile it. If there 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".

SSH1 configuration

• 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 (well, the user could still move the file, he won't do it accidentally).
    
  • /etc/ssh_known_hosts format: "hostname(s) bits exponent modulus  comment", e.g.
    host1,host1.mydomain.com,localhost 1024 37 8745374658736578563745632786 70932641542043272345452372372979237842723040482329039649090525590 78525058815952993236732229527290793573967323290331586355947509385
    68764576378465346783687563487634875638947894678934053640346834787 root@host1
    
  • 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. There are two methods of trust I can recommend: using /.shosts or using .ssh/authorized_keys. Both have advantages and disadvantages.
      
    • RhostsRSA Authentication: For example, to set up /.shosts root trust from host A to host B:
      - Add "hostA root" to /.shosts on host B and the IP address of host A to /etc/hosts on hostB
      - add the Public Key of hostA to /etc/ssh_known_hosts or ~/.ssh/known_hosts on host B
      - make sure /.shosts is mode 600 or 400.
      
    • RSA Authentication: Setting up RSA trust from host A to host B for user 'jim': 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. 
      - the user creates his RSA key pair using ssh-keygen on host A. The private key is stored in ~jim/.ssh/identity and the public key in ~jim/.ssh/identity.pub.
      - copy the identity.pub to ~jim/.ssh/authorized_keys on host B.
      - make sure ~jim/.ssh/authorized_keys has mode 600 or 400
      
    • Which is best?
      - RSA is better for users who may work from several machines, because the machine is not authenticated, logon is allowed from ANY machine that has a copy of the correct private key.
      - In RhostsRSA, the key of the machine is checked and logon is only allowed from the trusted machine. In addition SSH provides additional restrictions "AllowShosts" that can restrict .shosts usage even further. Hence this is my recommended method for trusts for backup automated sysadmin etc.
      
• 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.

Mindterm SSH installation

• Installation on Windows (tested with v1.1.5):
  Get it and install [6] a Java Runtime,
  Or, download mindterm_install.zip (3.5MB) and extract to C:\Progra~1, then setup a shortcut on your desktop to c:\Progra~1\mindterm\mindterm.bat. This includes a v118 Java run time and will work with English, French, German, Italian NT (hence the use of the short file names).

  This bundle includes lots of goodies: 4 Mindterm versions- v1.15, 1.21, 1.99 pre5 and 1.2. Also included is: putty (and pscp, plink) and winscp: A nice SSH file transfer GUI (to replace your ftp client)

• Installation on Solaris:
  
  • An example startup script for Solaris is mindterm.sh. Copy this along with mindterm.zip to /usr/local/bin .
  • Install Java (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.

---

Doing even more with SSH

• 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 tunnelling.
  
• SSH VPNs:
  
  • 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 http://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 http://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  http://www.lysator.liu.se/fsh. I've not yet tried this.
  
• Using SSH with RPC/keyserv/NFS/NIS+ : see http://fy.chalmers.se/~appro/ssh_beyond.html
  
• SSH1 & SecurID:

  SecurID does work with SSH1, but with the limitation that "New Pin" and "Next Token" modes are not supported (that would require a change in the client-server authentication protocol).

  Installation notes (see also the README.SECURID that comes with SSH1):
  Copy the ACE client software to the UNIX host (e.g. /usr/ace on Solaris with ACE V3.3), copy sdconf.rec to /usr/ace/data and sychronise the node secret.
  Compile SSH1 as above, but add --with-securid=/usr/ace/example.
  With sdamin, activate the unix host for the users who will be allowed to login.
  Create user accounts for those who will use SecurID, set the password to blocked and add the user names to /etc/securid.users.
  Test - check syslog for entries like:
  Dec 1 07:58:10 server1 sshd[20483]: log: Connection from 176.17.17.100 port 38528
  Dec 1 07:58:24 server1 sshd[20483]: log: SecurID authentication for bob required.
  Dec 1 07:58:26 server1 sshd[20483]: log: SecurID authentication for bob accepted.
  and check the ACE log for authentication accepted /refused messages.

  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 or Mindterm SSH, just yet. See ftp.parc.xerox.com:/pub/jean/sshsdi/README .

• Virtual Network Computing (VNC) 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, if SSH is 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 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). Note also that VNC does not encrypt it's password very well, see advisory from securiteam.
      
      
• PCAnywhere over SSH: PCAnywhere is another remote control program like VNC above, except it's limited to PCs.
  
  • Configure SSH to forward port 5631 and 5632. Verify - telnet to the local side emits packets on the remote side.
  • Modify the Windows registry to add a key: It's a DWORD key called TCPIPConnectIfUnknown in HKEY_LOCAL_MACHINE\Software\Symantec\PCAnywhere\Current Version\System. Set to 1 (the key doesn't exist by default). The pc_any.reg script does this.
  • Now it should be possible to forward PCAnywhere from the local-side to a remote-side gateway and from there, on to the "real" PCAnywhere host.

  More information on the PCAnywhere TCP/IP Registry settings can be found at: http://service1.symantec.com/SUPPORT/pca.nsf/docid/1997471006?OpenDocument&ExpandSection=2#_Section2
  For example, the data and status ports numbers are defined at the above registry branch, as are the default folder names for sending and receiving files.
  

• Citrix over SSH
  Assuming you want to connect to the Citrix server 176.17.17.2 via the SSH server gateway1, then try:
  ssh -L 1494:176.17.17.2:1494 YourName@gateway1
  And connect to "localhost" with Citrix
  See also: www.tc.cornell.edu/Services/Docs/HotTips/2000/tunneling.asp

---

References

[0] Socks http://www.socks5.com  

[1] Part II of this Article, which covers OpenSSH.

[2] BugTraq list of all SSH vulnerabilities:

2001-02-05: SSH1 SSH Daemon Brute Force Authentication Logging Failure Vulnerability
2001-01-16: SSH Secure-RPC Weak Encrypted Authentication Vulnerability

2000-11-13: OpenSSH Client Unauthorized Remote Forwarding Vulnerability
2000-09-30: scp File Create/Overwrite Vulnerability
2000-06-08: OpenSSH UseLogin Vulnerability
2000-07-05: SSH 1.2.27 Kerberos Ticket Cache Exposure Vulnerability
2000-02-24: SSH xauth Vulnerability

1999-12-01: RSAREF Buffer Overflow Vulnerability
1999-11-13: Sshd RSAREF Buffer Overflow Vulnerability
1999-09-17: SSH Authentication Socket File Creation Vulnerability
1999-05-13: Secure Shell Password Brute Force Vulnerability

1998-01-20: ssh-agent Vulnerability

[3] SSH Communications (also http://www.ssh.fi) and
DataFellows (also http://www.datafellows.com/f-secure)

[4] Marc Schaefer [schaefer@alphanet.ch]
     2000-01-11-Thread: sshd and popftponly users incorrect configuration

[5] Getting SSH1: See the main FTP site ftp.ssh.com/pub/ssh or one if it's mirrors such as ftp.cert.dfn.de/pub/tools/net/ssh. For RedHat RPMs (sparc and x86) see ftp.zedz.net/pub/crypto/linux/redhat

[6] Mindterm: http://www.mindbright.se/mindterm
Java Run time from Sun: http://www.javasoft.com/products/jdk/1.1/jre/download-jre-windows.html

[7] Explanation of SSH: Discussion thread on FOCUS-SUN

[8] Stupid, Stupid Protocols: Telnet, FTP, rsh/rcp/rlogin, by Jay Beale, explains why ssh is useful and explains how user RSA authentication works with ssh-agent. http://securityportal.com/cover/coverstory20000814.html

[9] This article has been translated into Italian:
Tutto su SSH - Parte I/II, Sostituire telnet/rlogin/rsh con SSH
http://www.ziobudda.net/Recensioni/ssh-part1.php

Other links:

• SSH FAQ http://www.employees.org/~satch/ssh/faq
  Getting Started with SSH by Kimmo Suominen  http://www.tac.nyc.ny.us/~kim/ssh
  Search for SSH pages on the net: http://www.links2go.com/topic/SSH
  
• Top Ten Secure Shell FAQs by Richard Silverman (RECOMMENDED)
  http://sysadmin.oreilly.com/news/sshtips_0101.html
  
• BOOK: SSH, The Secure Shell: The Definitive Guide, by Richard Silverman (haven't read it yet)
  http://www.oreilly.com/catalog/sshtdg   (published Jan'2001)
  
• SSH2 IETF Proposal
  http://www.ietf.org/html.charters/secsh-charter.html
  
• SSH and beyond, by Andy Polyakov 
  http://fy.chalmers.se/~appro/ssh_beyond.html
  
• Statistics on SSH usage:
  http://ssh-research.ucs.ualberta.ca/ssh-stats.html
  
• What's in a Name? by Kurt Seifried
  http://securityportal.com/articles/ssh20010214.html
  

---

About the Author

Seán Boran is an IT security consultant based in Switzerland and the author of the online IT Security Cookbook

---

Changes to this article
2000:
14.Feb.'00 First Publication https://admin.securityportal.com/research/ssh-part1.html  
25.Feb.'00 V1.1 New:sftp, SSH2 for Windows. Update: putty, Mindterm, SSH1 1.2.27 does work OK on IRIX, port forwarding.
08.Mar'00  New: Security Vulnerabilities Update: links
04.Apr'00  Update: Mindterm: add suggestions list. Add RedHat6 startup files. Doing even more with SSH.
30.Jun'00  New: add link to Java Telnet Application/Applet, Add [7]
22.Aug'00 Update: ssh1 v1.2.30, link to article from J.Beale. VNC password weakness.
11.Sep'00 Update: pscp/putty v0.49. Spelling.
09.Oct'00 Update: compression & other mindterm/putty issues, Ladon link. Links to Italian translation.
23.Nov'00 Update: Mindterm v1.99 pre1, putty v0.50
06.Dec.00 New: Windows SSHD servers
2001:
22.Feb.01 Refresh links & references. Add FreSSH, Update Mindterm, putty 0.51, ScanSSH
08.Mar.01 Add Winscp, Minor VNC tweaks.
10.May.01 Update: Licensing, Windows SSHD servers. New: OpenSSH + Cygnus, iXplorer
29.May.01 Update: Mindterm 2.0rc2, Add Tip for Windows users, move Cygwin to OpenSSH/part II article.
18.Jun.01 Sync security portal version.
21.Aug.01 General cleanup, improve example on automatic trusts, Citrix tunnelling
21.Nov.01 Added dataComet-Secure for the Mac.
2002:
25.Feb.02  Update putty 0.52
27.Mar.02 Add Bitvise.
05.Jun.02 Add JSSH
12.Sep.02 Add PockTTY
18.Nov.02 Mindterm Security tip, putty v0.53b, Mindterm 2.3.1
14.Dec.02 New Opensource Java SSH: SSHtools
22.Jul.04 Add Zoc

04.Nov.09 Add Absolute telnet

© Copyright 2004, Seán Boran, All Rights Reserved     Last Update: 22 Juli, 2004