|
SSH Notes |
The secure shell protocol (SSH) is rather similar to the more familiar telnet protocol from an user's point of view. Both are simply means of logging in and getting a shell prompt on a remote (usually Unix) machine. However, as the name implies, the SSH protocol strives to eliminate a number of security issues with the older telnet protocol. In particular, SSH connections are entirely encrypted, so that if someone "eavesdrops" on your session, they will not be able to get any useful information. Telnet, in contrast, passed all information over the net as plaintext, including your password.
The telnet protocol is more widely supported on host machines than the SSH protocol, i.e. if you are trying to connect to a remote machine, it is more likely that it will allow you to telnet in than to SSH in. In addition, telnet clients are more readily available (e.g., Microsoft includes a telnet client with recent versions of their operating system). However, more and more systems have SSH clients, and more and more systems are restricting if not eliminating telnet access in favor of SSH access for security reasons. This trend is likely to become much more common due to a recent serious security hole in the telnet daemon code on many flavors of Unix.
PCS strongly recommends that all of our users use SSH over telnet where possible. All PNCE-Unix/Glue and NSCP machines will allow authorized users to SSH into them. They also have ssh clients for accessing other machines via SSH protocol.
All Unix hosts maintained by PCS have both SSH client and server software running. This means that if you are logged into one of the PNCE-Unix machines, you can use the SSH protocol to connect to another machine. It also means that if you are on any machine with an SSH client (e.g. another Unix box, or a PC with TeraTerm/SSH installed), you can use that client to remotely log into the PNCE-Unix box.
This section discusses how to use the SSH client programs available on PNCE-Unix machines. If you are trying to connect to a PNCE-Unix box from a PC, you may wish to read the page on using the Teraterm/SSH program. From other unix boxes, the following may be helpful, but PCS cannot guarantee that this information will work on systems we do not maintain, and you should consult with the systems administrator for that system if you have questions.
The main client program is ssh. From an user standpoint, ssh
works much the same way as the older telnet
command did. For example, to connect to the machine remote.host, you
would simply type
local prompt> ssh remote.host
The biggest difference is that it NEVER asks for your username.
By default, it assumes that your username on the remote system is the same as
your username on the system your are running ssh on. Although this is often
the case, sometimes it is not. In those cases, simple modify the ssh command
by adding a -l option followed by your username on the remote system.
E.g.,
myusername@remote.host's password:
Welcome to remote.host
remote prompt>
local prompt> ssh -l newusername remote.host
newusername@remote.host's password:
Every time you connect to a machine, SSH stores the remote machine's public
key (for public key encryption) in a configuration file (unless you chose to
continue connecting without adding the host to the known hosts list). It uses
this information as a check that you are connecting to the machine you thought
you were connecting to. This warning means that the host you were trying to
connect to was not in your database, and so SSH could not verify that it was the
right host. This will certainly be the case if it is the first time you use
SSH to connect to a particular machine from a particular machine. Unless you
have very stringent security needs, this should not be a concern. Connect, let
SSH add the host to your list, and you should not see the warning next time you
connect to that host. Note that the name on the command line must match
exactly with an entry in the file, so even though
ssh login and
ssh login.physics.umd.edu
both get you to the same machine, SSH will add them both to the file as
distinct hosts. This could cause some seeming repetition of this warning.
As mentioned in the previous question, SSH keeps a list of the public keys presented by machines that you connect to. This warning occurs when you try to connect to a machine, and the public key it presents is different than the key it presented the last time you connected to it (or more precisely, the last key stored for that machine in the file). The danger is that this could be an indication of a hacker trying to bypass the security of SSH using a man-in-the-middle attack, but the likelihood of that is small, and the security risks of such are still no more than if you used plain telnet instead of SSH. A more likely cause is that a system administrator was doing serious maintenance work on the host and changed the machines public and private key in doing such.
If you are concerned about the security of your session, do not continue when you see such a message until you have contacted PCS. If PCS informs you that there was maintenance work on the system in question and the public key would have changed recently, you can ignore the warning with reasonable confidence.
If you are not concerned with security, e.g. you would have connected to the machine with telnet except PCS told you to use ssh, you can ignore the warning and it still is probably OK.
If you wish to stop getting these warnings on a particular machine, in
Teraterm you can simply check the box saying to add the new key to your known
hosts list. On Unix systems, the program will generally not automatically
update the known hosts list. In such cases, the easiest solution is remove the
entry for this machine from the known hosts list, and when you next connect
you will get the "Host unknown" warning, and it will add the host to the list
if you desire. To remove the entry for host HOST, you can issue
the following commands:
cp ~/.ssh/known_hosts ~/.ssh/known_hosts.old
grep -v HOST ~/.ssh/known_hosts.old > ~/.ssh/known_hosts
|
Physics Home |
PNCE Info |
UNIX Info |
PC Info |
System Info |
POWL Firstaider |
E-Mail
This page is maintained by the Physics Web Managers: |