SSH
Our UNIX systems provide access via the Secure Shell Protocol. SSH performs two roles. First, it encrypts the connection between the client, and server. This prevents people from "snooping" or capturing the network traffic that is traveling back and forth between your computer, and the server. You are probably used to this happening when you visit secure web sites. The other primary role that SSH performs occurs when you first log in. Each time you contact a SSH server, the server will send you it's key which your client will then use to bootstrap the encryption process. The first time your client logs in to a server, it will ask you to confirm that you have gotten the right key. When you confirm that the key is correct, it will be recorded for future use as a validation tool that you have indeed contacted the correct server. Secure web sites do this also, but the infrastructure is a bit more sophisticated, and a whole industry of key-signers has sprung up. These key-signers sign the server keys, and if your browser accepts the validity of the signer, then it will accept that it has received the final. Otherwise, your web browser will stop the connection, and ask for permission to continue connecting. If you receive such a warning, and you actually need to log in, then you should weigh need for logging in, versus the consequences of the fact that someone may be listening in on the connection. This is because any large corporation, University, or other institution should be using a widely accepted key-signer, so as to ensure that it's keys will be acceptable to as many clients as possible.
Back to ssh. When the client does warn you about the key you'll need to respond as appropriate. If you are using a GUI client, then you should just be able to easily point and click to approve the key. If you are using a terminal based SSH client (ie, from another UNIX system, or from a MacOS X system), you should see something this:
The authenticity of host 'host.ccbb.utexas.edu (192.168.7.101)' can't be established. RSA key fingerprint is da:bc:72:76:15:51:46:dd:3b:d9:97:50:db:e7:74:42. Are you sure you want to continue connecting (yes/no)?
To be extra safe, you should confirm that this is indeeed the correct key by contacting the admin of the server. As a practical matter, most people just say "yes". When the key is actually accepted you see this:
Warning: Permanently added 'host.ccbb.utexas.edu' (RSA) to the list of known hosts.
If you see this when you log in
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: POSSIBLE DNS SPOOFING DETECTED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ The RSA host key for host.ccbb.utexas.edu has changed, and the key for the according IP address 192.168.7.100 is unchanged. This could either mean that DNS SPOOFING is happening or the IP address for the host and its host key have changed at the same time. Offending key for IP in /root/.ssh/known_hosts:37 @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that the RSA host key has just been changed. The fingerprint for the RSA key sent by the remote host is da:bc:72:76:15:51:46:dd:3b:d9:97:50:db:e7:74:42 Please contact your system administrator. Add correct host key in /root/.ssh/known_hosts to get rid of this message. Offending key in /root/.ssh/known_hosts:53 RSA host key for host.ccbb.utexas.edu has changed and you have requested strict checking. Host key verification failed.
or something similar DO NOT LOGIN. Instead, you need to ask for further guidance.
Once you have logged in via SSH, you will have the normal UNIX terminal environment, and you can begin issuing commands.
Alternate Port
Because of the efforts of the Secure Shell programmers, the most common attach against systems that use secure shell is a dictionary attack. Hackers attempt to break in to the system by trying lists of usernames and passwords. Having EID based usernames help protect servers because they are not likely to be used elsewhere. Still it does make monitoring the system for security problems difficult because log files will be full of failed login attempts, and in one access to a system is failing even for legitimate users.
When the client contacts the server, it indicates that it wants to use the SSH service by specifying the well-known port number for the SSH protocol. This is port 22. Every Internet service has a well-known port number, but there is nothing says a service has to be made available at it's well-known port. By moving SSH to an alternate port, we can prevent these dictionary accounts. They would be required to scan the entire range of port numbers until they found the SSH service.