17 Secure Shell

By:

Stephen Carville

Rev:

04/26/2004

17.1 Connecting with no Password

Secure Shell allows publickey authentication to bypass the need for a password.

17.1.1 Server Side

1. Log onto the server
2. To turn on Public Key authentication on the server, add the following to /etc/ssh/sshd_config. This is usually enabled by default
   RSAAuthentication yes
3. The sshd server will check permissions on the user's home directory and will not normally allow a connection if the permissions are greater than 700. If it is necessary to allow users other than the owner to access a home directory, then strict modes must be disabled on the server side. In /etc/ssh/sshd_config, add the following lne:
   StrictModes no
4. If any changes were made, restart the server.
   # service sshd restart

17.1.1.1 Passwords

Version 2.7 and above of openssh will check if an account has been locked and will not allow login. If it is necessary to login to a locked account using RSA/DSA authentication, change the password field from ``!!'' to something else such as ``**''.
$ sudo usermod -p '**' <username>

17.1.2 Client Side

1. If necessary create an .ssh directory. This directory will contain private keys so it is important that it only be readable by the owner.
   $ mkdir .ssh 
   $ chmod .700 .ssh
2. Create an RSA and, if desired, a DSA keypair. Do not use an empty passphrase.
   $ ssh-keygen -t rsa 
   $ ssh-keygen -t dsa
3. IF necessary, create an .ssh dorectory on the target
   $ ssh congo mkdir ~/.ssh 
   $ ssh congo chmod 700 ~/.ssh
4. Add the public keys created above to the proper files on the target. Be certain you add the public keys. (If using an older versio of openssh see: 6)
   $ scp .ssh/id_rsa.pub congo 
   $ ssh congo "cat id_rsa.pub >>.ssh/authorized_keys"  
   $ ssh congo rm id_rsa.pub
5. If you were clever then you noticed on the last command you were asked for your passphrase instead of your password. This means that the key was successfully added and the authentication works.
6. On older versions of openssh - probably any before 3.0 - ssh2 keys must be added to authorized_keys2 file
   $ ssh congo "cat id_rsa.pub >>.ssh/authorized_keys2"

17.1.3 Making it work

The authors of openssh have provided a really neat utility called ssh-agent. This program allows you to enter your passphrase once and ssh can validate any future connection without asking you for a passphrase each time. The authentication agent can even be forwarded thru multiple connections allowing ssh connections to be chained.

Redhat and KRUD now seem to start all window managers as children of ssh-agent so the following may be unecessary.

1. For X-windows, start your X session as a child process of ssh-agent. Find where your desktop is started. If you use xdm then the file is /etc/X11/xdm/Xsession. Edit this to start ssh-agent before Gnome or KDE (This step is no longer necessary for Redhat 8.0. and above) 
    
   # now, we see if xdm/gdm/kdm has asked for a specific environment 
   case $# in 
   1) 
      case $1 in 
      failsafe) 
        exec xterm -geometry 80x24-0-0 
        ;; 
      gnome) 
        exec /usr/bin/ssh-agent gnome-session 
        ;; 
      kde|kde1|kde2) 
        exec /usr/bin/ssh-agent     /usr/share/apps/switchdesk/Xclients.kde 
        ;; 
      twm) 
        # fall back to twm 
        exec /usr/share/apps/switchdesk/Xclients.twm 
        ;; 
      esac 
   esac 
   

2. Execute ssh-add from a terminal or a shortcut and enter your passprase.

17.2 Port Forwarding

Even though there is no direct network address translation to most of our internal servers you can use the port forwarding capability of secure shell to connect thru one of the machines that are seen on the Internet.

For example, to forward a secure connection from the outside to tigris via congo:

Gateway:

www.totalflood.com

Internal Target:

tigris

1. Connect to an available machine running secure shell and forward a local port to another machine
   # ssh -L 40022:tigris:22 www.totalflood.com
   This instructs the connection software to forward all TCP traffic to port 40022 on your local machine to port 22 on tigris.
2. From another window, connect to local port 40022
   # ssh -p 40022 localhost
3. You now have a cryptographically secure connection from your local machine to tigris.

Another trick is to use netcat on the relay machine.

1. In $HOME/.ssh/config add a line like:
   Host tigris  
       ProxyCommand ssh www.totalflood.com nc %h 22  
   Host

If you are running a local X-Server and the remote ssh server allows X11 forwarding, you can now start X applications on the remote host and the display will be forwarded back to your local server via the encrypted channel. If you need to run an X Window application as a user other than the login user, you may need tell your local X-Server to permit the connection.

$ xhost + local: 
or 
$ xhost +

The first is preferred because it only allows local clients to connect.