Abstract SSH is the name of a protocol and a collection of associated programs for secure remote login to execute commands on a remote machine, to securely move files from one machine to another, and other secure network services over an insecure network such as the Internet. This article points out the weaknesses of telnet and FTP, describes how SSH and SCP overcome these weaknesses, attempts to persuade the reader to switch over to SSH and SCP, describes the free versions available and discusses the past exploits of SSH.
This article is part of Internet Security Lectures
SSH stands for Secure Shell. Its functionality is similar to that of telnet and rlogin in that you use ssh to connect to a remote machine that is running an SSH-server. There are three primary advantages in using ssh.
The main disadvantages are the following.
Just as telnet, rlogin and
ftp are client programs
talking to their respective server programs using application level
protocols, ssh uses the application protocol defined in RFC TBD.
There are a few things that you must understand even if you are interested in "just" using ssh in the simplest manner. This being a minimal background section, a few things are so simplified that they are "lies."
The Cryptography article listed below is a prerequisite to this article. It explains computational infeasibility, encryption, public and private keys, session keys, RSA, DSA, Triple-DES (3DES), "blowfish", "idea", etc.
The SSH suite of programs includes the following. All but
sshd run on the local machine. (Note that the actual programs
are named using lower case letters.)
In this article, we focus on the ssh
client program. Specific port numbers, etc. that we mention below are the
defaults.
The ssh program is invoked by the user. It establishes a TCP connection to port 22 on the server machine. This program/process is often called the ssh client.
The service process sshd
on the remote machine will be listening on the port 22. This process is
often called the ssh server. The user does not explicitly start this process.
This process is started either when the remote machine booted or on-demand.
Even though its name includes the word "shell", the ssh does not include the functionality of the shells such as bash, csh, or ksh. Once login is completed, the user is interacting with the usual shell, but with all his key strokes and output from the shell on the remote end going through the ssh encryption tunnel.
SSH involves the following.
The public and private keys for the remote machine must have been generated when an OS
got installed on it as a new machine. (The simplest of the ssh usages does not require items 1 and 2.
) Upon connection, the sshd
presents the public host key of the server machine.
The client checks that this key matches the key it has in its own database for that server machine. If not, it alerts the user and asks if the user wishes to continue anyway, with or without replacing the conflicting host key it has.
If this is the first connection being made to the server from this local host, there are two possibilities:
The two machines (local and remote) now negotiate a so-called session key (see Cryptography article). All traffic between the two from this moment on is encrypted with the session key. Note that the session key lasts only for one session. The public/private keys are "forever."
An ssh client can chose the encryption algorithm from among several it has: Triple-DES (3DES), "blowfish", "idea", etc.
After establishing the encrypted tunnel, the ssh client asks for user id and password. So, even someone eavesdrops on this, the captured user id and password will be in a form encrypted by the session key, and considered "computationally infeasible" to decipher into clear text.
Here is an example login.
The user pmateti is currently logged in on a machine named milner.osis.cs.wright.edu,
with prompt string PS1 set to '\h:\w%
'. He wishes to
login into the machine named Minsky.
milner:~ % ssh minsky.osis.cs.wright.edu -l pmateti
login as: pmateti
pmateti@minsky's password:
minsky:~ %
If the user's name on Milner is also pmateti,
there is no need to specify the -l
pmateti in the invocation of
ssh. It so happens that the prompt string on Minsky is also
set to '\h:\w% '.
Currently there are two versions, SSH1 (old) and SSH2 (current), of the SSH protocol in use. Depending on this and a few other issues, the above may look slightly different. Instead of the -l option, it is also possible to use the command line: milner:~ % ssh pmateti@minsky.osis.cs.wright.edu.
The program named ssh that you invoked is the ssh-client running on the local machine. It is the client which collects the user's password and delivers it securely to the remote machine. But even before it attempted to collect the password, ssh-client verified the authenticity of the remote host, minsky.osis.cs.wright.edu. This is further explained in SSH internals below.
The system wide ssh related files are located in /etc/ssh. User's ssh
files are in ~/.ssh.
Here is an ls -l listing of my ~/.ssh/.
-rw-r--r-- 1 pmateti pmateti 605 Jan 13 20:08 authorized_keys
-rw------- 1 pmateti pmateti 668 Jan 13 20:07 id_dsa
-rw-r--r-- 1 pmateti pmateti 605 Jan 13 20:07 id_dsa.pub
-rw-r--r-- 1 pmateti pmateti 3236 Jan 10 21:30 known_hosts
My private key (id_dsa) is shown below; normally, you must never
reveal the private key to any one. Note the rw-------
permissions on this file above.
-----BEGIN DSA PRIVATE KEY----- MIIDPwIBAAKCAQEAyrQ7RLxzOyw103CnzpcDlQQHiZZ2IduSNid3YXdqoOb+hSdS BnVRAzDYTNDM2AWpxHuODpltc+C/43YKOMixkyCr/K7wYL8tiqF8UatoW0L7l8xS xNwUprxLPD9vDcrjIZcj+KBGsa5OGpfRBuv25nqSxSDwkj3ueeXLB6NKegOzoYf1 CtyyQgDh7mNS2oli9iLX10vhFer1+BgLlaFF+H+Aw/6Vkf2u+Sw1B6XwekNeISBx JKoJAcFsYTdI+s9APm/XY1XcyIGIrApAM3XMbjTxYVi5rR1ZJFfjIC8RnAZ0qqCl aa6UCNlrufvibjiehjaHxnQVpiTUsSD63ghVBwIVAJVPI22DCqUcLtBJaxxVrfnK ZvQ7AoIBAQCFjDB6k2gzmusDaplJLgZm7Fk7IiQNMnX1IKEohwlxjjyocuFV+BJ1 tJRGFRsomhxq9ag31N6+F2ifB+aQQiUU39+BH7XZbcXqU+iDS3PIPwuLjgxF3+vd rrMnBlfTIHsiheDzdRLUdwFcA+JrWir0qyCEH/Re79SISl3tMJ+L3bt8r7i8FoeJ nCRtsF0C1lSbSDf+SPxxxucd3ZrMU8wYE5JXuC3yPSsZgKwPio8F+rEB9cohS3gk bg8NPCs/16IPFULKP4gE1rd3+c8eYk83lrbjWNAheTg3Na2eYdhGVMXssOqThTTb JcxxP2bVP0JYU6P2BgPxC9f9Wf9d9TnPAoIBAB2qNpd4BYGYlTUVLMSddcs0KlNU i2MG8F1at2j1y9vT2We5WdNbl34vGI0ARia3MZLP+xSCzaq0wzS7S0l96DoCJ/9z Hg9gbEs3O2fDTOYAPFY7C7B8lG05RnJO5KllnkiSDmdd5R5vpQ568UR1QadppgOH dpvdXDevw1+FJ0LbEqMx0Sp3Ylxbys1HWKInPUd8XxwTOudkA3YnxljObUrEjFrx jPsWCCGeaKGfhR+PJ1Vk2kncFhz5KyatFL2jkVi/j+Q1OB97Pb7MB/p+fRyOBQ3t GLmxSbZYGSRw2T3QOEVvIOlzgZPdA7RdJoIivWCT9b5kEva5ApCLoeaiVpQCFQCU 3LTLbRG2Seg7GTG3mUovBXW7Rw== -----END DSA PRIVATE KEY-----
My public key (id_dsa.pub) that "matches" the above private key is shown below. This should be published in ~/.ssh/authorized_keys of the remote machine (in our example: Minsky). You should not keep on Minsky the private key that you generated on Milner. The ssh client running on Milner presents your private key to the sshd on Minsky instead of the usual password.
The content of id_dsa.pub file is just one long line, but is shown below with inserted line breaks.
ssh-dss AAAAB3NzaC1kc3MAAAEBAMq0O0S8czssNdNwp86XA5UEB4mWdiHbkjYn d2F3aqDm/oUnUgZ1UQMw2EzQzNgFqcR7jg6ZbXPgv+N2CjjIsZMgq/yu8GC/LYqh fFGraFtC+5fMUsTcFKa8Szw/bw3K4yGXI/igRrGuThqX0Qbr9uZ6ksUg8JI97nnl ywejSnoDs6GH9QrcskIA4e5jUtqJYvYi19dL4RXq9fgYC5WhRfh/gMP+lZH9rvks NQel8HpDXiEgcSSqCQHBbGE3SPrPQD5v12NV3MiBiKwKQDN1zG408WFYua0dWSRX 4yAvEZwGdKqgpWmulAjZa7n74m44noY2h8Z0FaYk1LEg+t4IVQcAAAAVAJVPI22D CqUcLtBJaxxVrfnKZvQ7AAABAQCFjDB6k2gzmusDaplJLgZm7Fk7IiQNMnX1IKEo hwlxjjyocuFV+BJ1tJRGFRsomhxq9ag31N6+F2ifB+aQQiUU39+BH7XZbcXqU+iD S3PIPwuLjgxF3+vdrrMnBlfTIHsiheDzdRLUdwFcA+JrWir0qyCEH/Re79SISl3t MJ+L3bt8r7i8FoeJnCRtsF0C1lSbSDf+SPxxxucd3ZrMU8wYE5JXuC3yPSsZgKwP io8F+rEB9cohS3gkbg8NPCs/16IPFULKP4gE1rd3+c8eYk83lrbjWNAheTg3Na2e YdhGVMXssOqThTTbJcxxP2bVP0JYU6P2BgPxC9f9Wf9d9TnPAAABAB2qNpd4BYGY lTUVLMSddcs0KlNUi2MG8F1at2j1y9vT2We5WdNbl34vGI0ARia3MZLP+xSCzaq0 wzS7S0l96DoCJ/9zHg9gbEs3O2fDTOYAPFY7C7B8lG05RnJO5KllnkiSDmdd5R5v pQ568UR1QadppgOHdpvdXDevw1+FJ0LbEqMx0Sp3Ylxbys1HWKInPUd8XxwTOudk A3YnxljObUrEjFrxjPsWCCGeaKGfhR+PJ1Vk2kncFhz5KyatFL2jkVi/j+Q1OB97 Pb7MB/p+fRyOBQ3tGLmxSbZYGSRw2T3QOEVvIOlzgZPdA7RdJoIivWCT9b5kEva5 ApCLoeaiVpQ= pmateti@milnerIf your private key is exposed (like I did), you can ssh-keygen again. Obviously, you need to update all the corresponding public keys.
Port forwarding is the act of sending TCP packets addressed to one port on one machine to another machine + port. Say, you are logged in on Milner via X11, and if you were to ssh login to gamma (a machine located on a different subnet/floor from OSIS lab), and invoke an X client program, the X11 traffic generated by that client on gamma will be sent to the X11 server on Milner via the ssh tunnel.
More TBD.
TBD
TBD
SSH protocol uses the public key system for encryption. The SSH Protocol Architecture article listed below is the official description of the protocol. In the next few paragraphs, we summarize these details.
Currently there are two versions, SSH1 and SSH2, of the SSH protocol in use.
putty
ttermpro
openssh
If you wish to avoid typing your password every time a remote login or file transfer is attempted, you must generate a public + private key pair for yourself using either DSA or RSA. In this example, we use DSA.
% ssh-keygen -t dsa -b 1024
This generates a public + private DSA key pair. It will ask where to
store the keys. Accept the supplied default
pathnames. Just type Return so that you are not
using a "passphrase". The dialog
with ssh-keygen will look like this:
Enter file in which to save the key (~/.ssh/id_dsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in id_dsa. Your public key has been saved in id_dsa.pub. The key fingerprint is: ad:a3:7f:39:28:22:f8:42:7f:ac:10:83:c7:61:01:ba pmateti@milner
Append the newly generated key to other authorized keys you
may have collected so far.
% cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys
Copy this file (~/.ssh/authorized_keys (the _ is an underscore, not a hyphen)) to your home directory on Minsky's (unless Milner and Minsky share the home directories, as in our OSIS Lab). All the machines in this lab have a shared /home directory server from osisServer.osis.cs.wright.edu.
Now you (except root) should be able to log in to Minsky without typing the password.
milner:~ % ssh minsky.osis.cs.wright.edu
minsky:~ %
All work should be carried out in the Operating Systems and Internet Security (OSIS) Lab, 429 Russ. Use any of the PCs numbered 192.168.17.19 to .30. No other WSU facilities are allowed.
| Copyright © 2005 pmateti@cs.wright.edu | 09/29/08 05:03:19 PM |