ssh

Contents:

Introduction

The traditional methods of connecting to remote computers, telnet and ftp, require you to transmit your password in "plain text." This exposes it to anyone who intercepts your network traffic. One way to avoid this is to use an encrypted network connection as provided by SSH.

SSH is a widely-used suite of remote access programs which provides authentication (to protect your password) and encryption (to protect your data). The versions implemented at LEPP do not use Kerberos, although some recent versions include this as an option. For general information on SSH, see the SSH Home Page. The official SSH FAQ is available at http://www.onsight.com/faq/ssh/ssh-faq.html. Information about the SSH mailing list can be found at http://www.cs.hut.fi/ssh-archive/.

This document is primarily intended to help people using TeraTerm Pro SSH (TTSSH), an SSHv1 client for Windows, but includes some comments on other implementations. Additional usage tips for SSH on Windows systems are available at John Fitzgibbon's "Tips" Web page.

At LEPP, all of the Alpha/Tru64, Alpha/Linux, PC/Linux and Sun/Solaris systems have both SSHv1 and SSHv2 services and clients installed. They are not yet available on the Windows servers. The primary Alpha/VMS and VAX/VMS systems also have both SSHv1 and SSHv2 clients and services. This includes LNS61, LNS62, CESR10, and CESR67. SSHv1 and v2 clients are in the process of being made available on desktop PCs and Macs. (See the description of OpenSSH and Cygwin below.)

A serious security flaw exists in most implementations of SSH v1 servers. Rather than install the necessary patches, many sites running Unix have decided to permit access using only SSHv2. This flaw does not exist in the VMS SSH v1 server.

Whenever possible, please use SSH to login directly to the systems you'll be using. Avoid using SSH from within a previous SSH session: SSH encryption is very CPU intensive. Too often people have reported poor network response which turned out to be due to multiple SSH connections (ssh to a, ssh from a to b, ssh from b to c, etc.).

PuTTY

  1. PuTTY has superseeded TTSSH for most Windows users. We recommend using PuTTY as it is installed on all LEPP Windows machines. You can obtain PuTTY from \\pc140\Distribution\putty.exe or from their website http://www.chiark.greenend.org.uk/~sgtatham/putty/
  2. Additional support for using PuTTY on Windows machines to forward X is available here: https://wiki.lepp.cornell.edu/lepp/bin/view/Computing/ConnectingToALinuxMachineFromWindows

TTSSH (SSHv1) for Windows

  1. Official TTssh Documentation
  2. Install TeraTermPro SSH on your Windows PC.
  3. Configure port forwarding (tunneling)
  4. Configure local network clients
  5. Configure local X authentication
  6. Initialize your SSHD tunnel: connect to an SSHD server

1. Official TTssh Documentation

Some preliminary tests seem to indicate that X forwarding using OpenSSH is somewhat faster and more robust than what is provided by TTssh.

2. Install TeraTermPro SSH on your Windows PC.

TTSSH works with Win95, 98, 98se, Me, NT and W2K.
  1. Get TeraTermPro (an excellent VT emulator)
    Tera Term Pro ver. 2.3 for Windows 95/NT
    By T. Teranishi (teranishi@rikaxp.riken.go.jp)
    http://hp.vector.co.jp/authors/VA002416/teraterm.html
  2. Get TTSSH
    TTSSH: An SSH Extension to Teraterm
    By Robert O'Callahan (roc+tt@cs.cmu.edu)
    http://www.math.umd.edu/department/computer/pc/howto/ssh/Software/ttssh154.zip
  3. Install TTPro using its SETUP.EXE
    • You must have administrative privileges to do this.
    • No reboot is required.
  4. Unzip (expand) the TTSSH archive into the directory where TTPro was installed (usually it's C:\Program Files\TTERMPRO ) Do not overwrite the file "readme.txt".
  5. Create a shortcut on your desktop and/or in your Start menu to
    C:\Program Files\TTERMPRO\TTSSH.exe. For details, see the section below on "Initial multi-user considerations".
  6. Unprotect the file C:\Program Files\TTERMPRO\TTERMPRO.INI. Otherwise you won't be able to set your defaults.

Note: the above procedure assumes that your PC is a single-user system. If several people use your computer, then the location of the TTssh databases will have to be changed to be in a directory in your personal profile. Details have not yet been worked out.

Initial multi-user considerations for NT & W2K

  1. Move TeraTermPro menu from installer's Start Menu\Program Files\ to the "All-Users" Start Menu\Program Files\
    • Right select "Start" menu
    • Select "Explore All Users"
    • Select "Program Files" (list of program folders appears in right pane)
    • Right select "Start" menu
    • Select "Explore"
    • Select "Program Files" (list of program folders appears in right pane)
    • Right-Drag the folder "Tera Term Pro" from "Explore" window to "All Users" window. Select "Move Here"
    • Delete the "Explore" Window
  2. Create a shortcut to TTSSH in the "All-Users" TeraTermPro menu
    • In the "Explore All Users" window, select (open) the "Tera Term Pro" menu.
    • Select the desktop icon "My Computer" and navigate to the folder "C:\Program Files\TTERMPRO\" (assuming installation defaults were used)
    • Right-Drag the icon for "ttssh.exe" from the TTERMPRO folder to the "Tera Term Pro" menu. Select "Create Shortcut Here"
  3. Create a shortcut to TTSSH on the "All-Users" Desktop
    • In the "Explore All Users" window, scroll up to the "Desktop" and select (open) it.
    • Right-Drag the icon for "ttssh.exe" from the TTERMPRO folder to the "Desktop" folder. Select "Create Shortcut Here"
    • Close windows. "Shortcut to ttssh.exe" should be on the desktop.
  4. specify location of writable SSH Known Hosts file
    ttssh | setup | SSH... | c:\winnt\profile\%username%\ssh\ssh_known_hosts
  5. Specify location of RSA Authentication private key file
    ttssh | setup | SSH Authentication... | c:\winnt\profile\%username%\ssh\identity

3. Configure port forwarding (tunneling)

Once you have configured TTSSH to tunnel network connections, your computer's network applications access your local system as if it were the one providing the services you need. Those local network ports are actually being intercepted by your TTSSH job. It encrypts your data and forwards it to the remote SSHD server. To a remote system, the connections from your PC's network jobs seem to be coming from the SSHD server.

  1. Make sure your computer is not already running services like ftp on the TCP/IP ports you'll be using for SSH forwarding. Norton Anti-Virus software will block access to several ports when it is configured to scan e-mail messages. In a Command (or DOS) Window, type the command netstat -an to see what ports are in use.
  2. Double click its icon to start TTSSH. Two windows will pop up: a "[disconnected] VT" terminal window and a "New connection" window. Cancel the window called "New connection".

    The following process configures a forwarded service port. In Tera Term's task bar,
    1. select the "Setup" menu.
    2. select "SSH Forwarding..."
    3. select "Add..." in the window "TTSSH: Forwarding Setup".
    4. select "Forward local port" in the window "SSH Port Forwarding"
    5. choose the appropriate local port from the menu (e.g. smtp). Or you can type it in.
      Windows systems will let you use any local port number so long as a service is not already running on that port.
      Unlike Unix, NT and W2K, Windows 95/98/Me does not protect access to the privileged ports.
      [need to check NT/W2K from non-priv'd account to see if this is true.]
    6. type in the name of the host you want the port to be forwarded to, i.e. the computer that actually will be providing the service.
    7. from the dropdown menu, choose the appropriate service port on that remote host (or you can type it in).
      E.g.
      smtp smtp.lepp.cornell.edu   smtp
    8. Click "OK".
      You will then see a line added to the window "TTSSH: Fowarding Setup"
      Local 25 (smtp) to remote "smtp.lepp.cornell.edu" port 25 (smtp)
    9. Do the same for IMAP, POP, FTP or whatever other services you want sent through SSH's encrypted channel.
  3. If you'll be using SSH to forward X, check the box at the bottom of the window "TTSSH: Fowarding Setup".
  4. Don't forget to save the parameters you've set:
    In Tera Term's task bar,
    1. select the "Setup" menu.
    2. select the item "Save setup..."
    3. use the default or specify a new .INI file
    4. select "Save"

4. Configure local network clients

  • Make sure your system connects to itself when localhost is specified as an address. In a command (or DOS) window, type the command ping localhost. If this fails, you will have to consult the network documentation for your system. Something is badly broken.
  • Configure all of your network clients which will be using tunneling (mail, news readers, X) so that they connect to localhost and not to a remote server. SSH will intercept those local connections and forward them to remote systems. Your mail reader should not be configured to connect directly to LNS61 or MAIL.LEPP.CORNELL.EDU, for example. Connecting to localhost forwards their connections through SSH. Your mail messages and passwords will be encrypted by SSH, reducing the possibility of someone else reading your mail while it's in transit.
  • See the note below on mail client configuration. Unfortunately, the complete details of configuring appropriate profiles in the various mail and other clients is beyond the scope of this document. Consult the help files for the mail and news software that you use for how to define a "profile" or "personality".

5. Configure local X authentication

  • Be sure to enable host authentication in the X server on your PC and configure it to accept only connections from localhost. Local X clients as well as any X clients connecting to your virtual X server defined on your SSHD server will be the only ones allowed to connect to your PC's local X display. You do not want anyone else to be able to monitor your keystrokes.
  • The details of configuring your X display server are beyond the scope of this document.

6. Initialize your SSHD tunnel: connect to an SSHD server

  • Make sure you have a valid account on the system you'll be using as your SSHD server.
  • Double click the icon to start TTSSH. Two windows will pop up: a terminal window and a "New connection" window.
    • In the new connection window, supply (or select) the name of the host system you want to connect to and the login method, TELNET or SSH.
    • TTSSH will automatically change the port number to 22 if you select SSH.
    • Then click on "OK"
  • The first time you connect to a particular SSHD server you'll get a popup window titled "SECURITY WARNING".
    • Check the box for "add this machine and its key to the known hosts list" and then click on "Continue".
    • The very first time you use TTSSH it will also complain that it couldn't find the file SSH_KNOWN_HOSTS. It'll create the file automatically.
  • In the "SSH Authentication" window, supply your User name and the "Passphrase". If you use the default "Use plain password to login" then the "Passphrase" is your usual interactive password. SSH encrypts your password so it can't be easily decoded by someone who intercepts it.
    Unfortunately, some older releases of SSH don't try to hide the length of your password from snoopers. The length of the passwords you type through SSH to other systems can also be determined. Knowing their length makes it slightly easier for people to try to guess them. Current releases of SSH hide this information by padding the password packet.
  • You can configure SSH to use an RSA key instead of your interactive password. Unfortunately, TTSSH does not include a key generator. You can use SSHKEYGEN or the equivalent on your SSHD server to create appropriate "identity" pairs. You can then copy the newly generated private key file identity to your local PC and add the corresponding public key (usually written to the file identity.pub) to the file authorized_keys on your SSHD servers.
    Please read the SSH documentation on your SSHD server(s) for more details.
    • For Tru64 Unix, type the command man ssh on LNS123.
    • For VMS, visit the Web page Multinet User's Guide, Chapter 8 "Accessing Remote SupportedHardware with the Secure Shell (SSH) Utilities" (This Web page can only be read from systems within the LEPP network.)

OpenSSH (SSHv2) for Windows

  1. Official OpenSSH & Cygwin Documentation
  2. Install Cygwin and OpenSSH on your Windows PC.
  3. Configure local network clients
  4. Configure local X authentication
  5. Configure port forwarding (tunneling)
  6. Initialize your SSHD tunnel: connect to an SSHD server

1. Official OpenSSH & Cygwin Documentation

OpenSSH client software is freely available for all Windows platforms. It implements the SSH v2 protocol. See the OpenSSH Web site for details.

OpenSSH is included with Cygwin. Cygwin is a freely available open-source implementation of the Unix environment for Windows. It also includes an extensive collection of GNU software development tools. The XFree86 implementation of X windows is available as part of the Cygwin software distribution, too. See the Cygwin home page for details.

Some preliminary tests seem to indicate that X forwarding using OpenSSH is somewhat faster and more robust than what is provided by TTssh.

2. Install Cygwin and OpenSSH on your Windows PC.

Installation details are beyond the scope of this document, but see Cygwin for more information.

Cygwin is quite large. A locally produced CD containing recent versions of Cygwin and XFree86 can be made available upon request.

3. Configure local network clients

  • Make sure your system connects to itself when localhost is specified as an address. In a command window, type the command
ping localhost If this fails, you will have to consult the network documentation for your system. Something is badly broken.
  • Configure all of your network clients which will be using tunneling (mail, news readers, X) so that they connect to localhost and not to a remote server. SSH will intercept those local connections and forward them to remote systems. Your mail reader should not be configured to connect directly to LNS61 or MAIL.LEPP.CORNELL.EDU, for example. Connecting to localhost forwards their connections through SSH. Your mail messages and passwords will be encrypted by SSH, reducing the possibility of someone else reading your mail while it's in transit.
  • See the note below on mail client configuration. Unfortunately, the complete details of configuring appropriate profiles in the various mail and other clients is beyond the scope of this document. Consult the help files for the mail and news software that you use for how to define a "profile" or "personality".

4. Configure local X authentication

  • Be sure to enable host authentication in the X server on your PC and configure it to accept only connections from localhost. Local X clients as well as any X clients connecting to your virtual X server defined on your SSHD server will be the only ones allowed to connect to your PC's local X display. You do not want anyone else to be able to monitor your keystrokes.
  • The details of configuring your X display server are beyond the scope of this document.

5. Configure port forwarding (tunneling)

Port forwarding, including X forwarding, is declared as part of the SSH command itself. For example, If you're using IMAP and you want to use LNS61 as both your inbound and outbound mail servers, you could use the following OpenSSH command:
ssh -L 25:LNS61:25 -L 143:LNS61:143 -X loginname@LNS61.lns.cornell.edu
Where "loginname" should be replaced your actual VMS username.

Initialize your SSHD tunnel: connect to an SSHD server

ssh -L 25:LNS61:25 -L 143:LNS61:143 -X loginname@LNS61.lns.cornell.edu

While this command is running, connections to ports 25 and 143 (the SMTP and IMAP server ports) on your Windows system will be intercepted by ssh and forwarded to LNS61. Connections to the X service on LNS61 will be forwarded to your PC.

NEWIN Setup

  • Please use the following procedure to use NEWIN with SSH. In this example, cesr202 is used as the SSHD server. If you are outside the lab, log in to lnx201 first and then use the following command.
    1. ssh -X username@cesr202 /nfs/cesr/online/acc_control/bin/newin

MacSSH (SSHv2) for MacOS

  • MacSSH is a freeware implementation of SSHv2 for MacOS systems prior to MacOS X.
    No local documentation is currently available for MacSSH, but information about MacSSH is available on the Web at http://www.macssh.com/. Also see the MacSSH FAQ for information about X forwarding, for example.
    MacSFTP is available as shareware. See the MacSSH web page for details.
    (NiftyTelnet (SSHv1) can be used when you need only a secure terminal emulator, but it does no port forwarding. As a result, it's useless for forwarding X windows, for example.)
  • For MacOS X, install XFree86, then follow the instructions for using OpenSSH above. See also the Unix instructions below.

OpenSSH for Unix or Linux

1. Installation of an SSH client

  • Install the current release of OpenSSH if necessary.
  • Verify that there is an entry for localhost with an IP address of 127.0.0.1 in your system';s file /etc/hosts
  • Verify that you have access to a login account on the SSHD server

2. Running the SSH client

  • Make sure no network client applications are running on your local Unix box.
  • Use the SSH command to activate your tunneling session. For example:
    ssh  -L 25:SMTP:25  -L 80:WWW:80 -L 143:POP:143 -l loginname LNS123.lns.cornell.edu
    In this example, LNS123.lns.cornell.edu is being used as the SSHD server.
    SMTP connections (port 25) will be forwarded to SMTP.lepp.cornell.edu,
    If your browser tries to connect to a Web server on your local PC (port 80), those connections will be forwarded to WWW.lepp.cornell.edu
    and IMAP connections (port 143) will be forwarded to POP.lepp.cornell.edu. loginname should be replaced by your actual username.
    Note: If your local PC is running Unix (or Linux) you'll have to be logged in as (or su'd to) root in order to be able to specify a local privileged port (less than 1024). Otherwise, you'll have to specify appropriate non-privileged local ports (greater than 1024) and configure your network clients to use them instead.
  • Start your network applications on your local Unix (Linux) system. (The appropriate network applications all should be configured to connnect to "localhost", not to some remote system. See item 3 below.)
  • If the DISPLAY environment variable is set in your command window on your local PC, then ssh will automatically create a proxy X server on the SSHD server.
    NOTE: Do *NOT* set the DISPLAY environment variable on the remote system. ssh must set it for you automatically so that X I/O gets directed to the correct proxy X server on the SSH server. If you set DISPLAY in any of your Unix "dot" files then you must remove those commands.
  • Before shutting down your SSH session, exit from all of your network applications.
  • Type the command man ssh on an LEPP Unix system for more information.

3. Configuring network clients (e.g. mail)

  • Make sure the sendmail daemon is not running on your local system. Verify this with the command ps -ef | grep sendmail and kill it if necessary. You can configure Unix not to start sendmail at boot time.
  • On your local computer, make sure your mail client is configured for a mail server type of POP3 or IMAP.
  • Set your incoming and outgoing mail servers to be localhost.
    Although your mail client thus tries to connect to the POP or IMAP and SMTP ports on your local PC, SSH intercepts the connections and forwards the data to your remote mail server.

Notes:

1. Forwarding is *NOT* encrypted

SSH only encrypts data transferred between your local system and the SSHD server. The data forwarded from the SSHD server to a remote system is not encrypted. You need to be able to trust the security of the connection between the SSHD server and the remote server. You'll have less exposure if you can use TTSSH to login on the remote server instead of forwarding the connection.

Pictorially:

[PC]*<===encrypted===>*[SSHD server]*<---unencrypted--->*[MAIL server]

The same is true for your local network if you're using TTSSH to forward connections locally:

[PC#2]*<---unencrypted--->*[PC/TTSSH]*<===encrypted===>*[SSHD server]

2. FTP

Do not use FTP if you can avoid it. It transmits your password in plain text. I've never been able to get port forwarding to work with FTP.

Use OpenSSH's SFTP or SCP instead (man scp for more information).

On Windows, WinSCP is available for install on request.

3. Mail

  • Configure a mail profile which uses localhost as its Mail servers. This is so that connections to both incoming (IMAP or POP) and outbound (SMTP) servers will be intercepted by your SSH client.
  • make sure your mail reader (Eudora, Outlook Express, Netscape, etc) is not running before you configure SSH.
  • Configure SSH to forward the appropriate local mail (IMAP,POP,SMTP) server ports to the corresponding ports on the remote mail server.
    For example, If you're using IMAP and you want to use Wilson Lab's Unix mail system, you could use the following OpenSSH command:
    ssh -L 25:SMTP.lepp.cornell.edu:25  -L 143:POP.lepp.cornell.edu:143  -X loginname@LNS123.lns.cornell.edu
    Where "loginname" should be replaced your Unix userid.
    As another example, If you're using POP and you want to use Wilson Lab's VMS mail system, you could use the following OpenSSH command:
    ssh -L 25:LNS61.lepp.cornell.edu:25  -L 110:LNS61.lepp.cornell.edu:110  -X loginname@LNS61.lns.cornell.edu
    Where "loginname" should be replaced your VMS username.
    In these examples above:
    • port 25 (the SMTP mail server port) on your local system is to be intercepted by SSH and forwarded to port 25 on the remote mail service system (SMTP.lepp.cornell.edu or LNS61.lepp.cornell.edu).
    • port 143 (the IMAP mail server port) on your local system is to be intercepted by SSH and forwarded to port 143 on the remote mail service system (POP.lepp.cornell.edu). Despite its name, the Unix mail server named POP handles both POP and IMAP clients.
    • port 110 (the POP mail server port) on your local system is to be intercepted by SSH and forwarded to port 110 on the remote mail service system (LNS61.lepp.cornell.edu).
    • a virtual X display is to be created on the remote SSH server system (LNS123.lns.cornell.edu or LNS61.lns.cornell.edu) and X traffic is to be forwarded to the X display on your local system.
    • You can leave off the ".lepp.cornell.edu" domain suffix for the forwarded ports. It's included here for clarity. It'll probably be required for the name of the remote SSH server, depending on how your local system is configured.

4. X

  • Start your local X11 server before running SSH, and shut it down after logging out your SSH session.
    Remember that an "X Server" is the software that runs on your local computer to provide an X display window. The X programs that run on a remote system (like xclock) are X clients.
    For example, see the Web page http://cygwin.com/xfree/docs/ug/using.html#using-starting for instructions on how to start XFree86 with Cygwin. (The last time I checked, however, this page was obsolete. XFree86 is now integrated with Cygwin. All of the XFree86 subsets that you select during the Cygwin Setup are automatically downloaded and extracted to the appropriate directories. You only need to copy the appropriate X startup script to your Cygwin home directory and run it.)
  • Be sure to enable host authentication in the X server on your PC. Configure it to accept only connections from localhost. This will ensure that X clients running on your PC and X clients connecting to the virtual X server on your SSHD server will be the only ones allowed to connect to your PC's local X display. You do not want all and sundry to be able to interact with your X server. You need to protect against someone monitoring all of your keystrokes, for example.
  • If you are going to be using SSH to forward X sessions from a VMS system (e.g. CESR29) you must also use a VMS SSH server (e.g. CESR10). This is because the native proprietary OpenVMS X windowing software does not include the Xauthority authentication protocol required by SSH. Multinet's SSH server supplies Xauthority for VMS X programs. Unix SSH servers do not. (Multinet is a 3rd party TCP/IP network package which is used at LEPP on all of our OpenVMS systems.)
  • Do not try to define your X display environment on the SSHD server. SSH will set the X display environment for you automatically. Be sure to remove any entries in scripts on remote systems which define the X display (the environment variable DISPLAY under Unix). The X display will change from one session to another, depending on how many other people are using the same SSHD server.
  • If you are using X from a remote system other than your SSHD server, be sure to set the DISPLAY variable on the remote system to point to the virtual X display on your SSHD server. DISPLAY must not be defined as the X display on the system you're sitting in front of.
See also:
Contents:

This topic: Computing > WebHome > SecureShellDocumentation
Topic revision: 11 Mar 2020, MichaelForster
This site is powered by FoswikiCopyright © by the contributing authors. All material on this collaboration platform is the property of the contributing authors.
Ideas, requests, problems regarding CLASSE Wiki? Send feedback