• Hartley Conference Center
• Room Resources
• Computing Resources
  • News
  • New Users
  • Policies
  • Sesfs File Server
  • Web Server
  • Computer Labs
  • CEES Computational Clusters
  • Get Help
  • Net Connections
  • Your Macintosh
  • Your Windows PC
  • Your Unix/Linux System
  • Other School Resources
  • Using Unix
    • Overview
    • Documentation
    • Using the Shell
    • Using X-Windows
    • File Manipulation
    • Net Commands
    • Editing Text
    • Formatting Text
    • Printing
    • Filters & Utilities
    • Programming
• Health and Safety

ssh for remote login

Copyright Phillip Farrell. Last revision August 3, 2004

Use this syntax to make a remote login from one Unix system to another:
     
ssh [-l username] remotehost

Here, you substitute the IP name or address of the remote computer for remotehost. If your account name on the remote computer is not the same as your account name on the local computer, then use the -l option (letter "ell", not the numeral one) to provide the correct account name for the remote computer. Substitute your remote account name for username in the syntax shown above Do not type the brackets ([ and ]), which are used only to show that the enclosed items are optional.

The ssh program will prompt you for your password on the remote system, unless you have configured the private cryptographic key authentication described below. Please remember that ssh does not use any central authentication database, such as your SUNet ID. It requires the actual password that you have set for your specific account on the remote system. If you use ssh to connect to pangea, for example, you must supply your local pangea password, not your SUNet password. See the note on computer accounts for more information on the differences between your SUNet ID and your pangea account.

The password and all subsequent data transferred between the computers will be encrypted first with a very strong cipher before it is sent on the network. To make this encryption work, the client computer (the one where you issue the ssh command) must know the unique cryptographic "host key" created by the server computer (the one you log into with ssh). For utmost security, the server "host key" should be copied to the client computer in advance by some encrypted method. Often, in a system of computers under single management (such as the Sweet Hall workstations), the managers will create the host keys and transfer them to all the systems.

Or, you can obtain the host key and store it on your local computer. If your "local computer" (the one where you type the ssh command) is a Unix system like pangea, then you can store host keys for remote computers in the file known_hosts in the subdirectory .ssh (the leading dot character is part of the name) of your home directory. This .ssh subdirectory is also used to store private cryptographic keys (see below) and should be configured so that only your personal account has permission to access the directory (remove all permissions for "group" and "others").

Fortunately, you don't have to actually create and configure the .ssh subdirectory and copy host keys into the known_hosts file yourself. You can let the ssh program do this for you with only a very slight loss of security.

The first time you use ssh on a Unix system like pangea to connect to another computer, if you do not already have the .ssh subdirectory and the remote system's host key in the known_hosts file, then ssh will prompt you for permission to get the host key itself (and create the necessary directory and file to store it). If a determined hacker was targeting you and trying to intercept your communications, he could in principle "pretend" to be the remote host you are seeking and provide his own host key, and then route your connection to the real remote system through his computer. This is likely to be a rather rare occurrence in ordinary use.

ssh does provide some protection against the danger of "man in the middle" attacks by hackers (trying to force your connection to route through their machine). Once you have the host key for a remote system, either by manual transfer or automatic transfer when you first connect, ssh will warn you in the future if this key appears to have changed on the remote system. If you receive such a warning, you should verify that the change was deliberate on the remote system before proceeding to login.

You can "suspend" your remote ssh login session just like any other program if you are using the "csh" shell on the local system! Instead of plain CTRL-Z, however, which means to suspend whatever program you are running on the remote machine, type:
      ~CTRL-Z
that is, the tilde character ~, followed by the CTRL-Z character. Now you have "escaped" back to your local system. To resume your remote session, just give the normal "fg" command. This allows you to toggle back and forth between a local and remote session from the same terminal window.

Macintosh and Windows PC graphical ssh clients must also obtain and store the hosts keys for remote servers. They will generally do this "automatically" in a manner similar to that described for Unix systems, above.