Using the Secure Shell Protocol (ssh)
Introduction
The Secure Shell Protocol allows a user to connect to a UNIX machine from
another UNIX machine or personal computer via an encrypted connection.
Using ssh, the Penn State Access Account userid and password pair are transmitted via an encrypted connection to prevent network snooping (or "sniffing") of passwords
via traditional, non-secure network connections. Once a login session
has been established, the network packets between the local PC or UNIX
workstation and the remote UNIX workstation are also encrypted.
Why use the Secure Shell Protocol?
The secure shell protocol prevents network eavesdropping by unscrupulous
individuals in search of userids and passwords to gain unauthorized
access to systems. Because telnet, rlogin, and ftp present passwords
"in the clear" over a non-secure network, they are vulnerable to this form of
eavesdropping. The secure shell protocol encrypts (via public key encryption)
userid and password interchange between two machines and then encrypts
(via faster, symmetric encryption algorithms) the network traffic between
the two machines. Both the password exchange and the data
passing between the two machines is encrypted with strong encryption.
Using ssh to Connect to a Remote Host
In its simplest form, ssh is used from a user's PC or workstation (called
"localhost" and indicated by the "localhost%" UNIX prompt in the examples below).
It replaces telnet, rlogin, and rsh to connect to a remote machine (called "remotehost" in the examples below):
localhost% ssh remotehost.aset.psu.edu
Then, the user is prompted for his/her Penn State Access Account password. Upon
successful completion of the login process an encrypted session will be set
up between the local machine and remote machine. In the case of UNIX to
UNIX connections, any traffic using the X protocol for remote display is
also encrypted.
Many of the networks on campus, such as departmental servers, do not use Penn State Access Accounts as a means of authentication; therefore, user IDs (called "localid") might be different. If this is the case, then ssh connections
must indicate the user ID on the remote system (called "accessid").
localid@localhost% ssh -l accessid remotehost.aset.psu.edu
When the user is prompted for a password, the Penn State Access Account password must be entered.
Using scp in Place of ftp
The scp program accompanies ssh and allows for a file to be copied securely
from a remote machine to a local machine (or vice versa). The syntax is
similar to the Berkeley UNIX rcp program. If scp is used, then it is unnecessary to use ftp to transfer files from a local UNIX machine to a remote UNIX machine.
To use scp, a user refers to a local file similar to how he/she would with the "cp" command and the remote file as remotehost:/path/to/remotefile as shown in the following example:
localhost% scp remotehost: /path/to/remotefile localfile
Again, like ssh, scp has a mechanism which allows for different accounts on
different machines, as shown in the following example:
localid@localhost% scp accessid@remotehost:/path/to/remotefile localfile
The scp program can also be used to send a local file to a remote system, as shown in the following example:
localhost% scp localfile remotehost:/path/to/remotefile
Return to the UNIX Cluster page
Return to SSH page