SSH - Secure SHell

SSH is a Secure SHell which can be used in the place of telnet to connect to a remote machine. The advantage of using ssh over telnet is that communication and data transfer between the local machine and the remote machine occurs in a secure encrypted tunnel. So no one will be able to snoop on your data.These are a few tips in using this program.

Connect to remotehost and tunnel all X traffic over the encrypted connection.

To see how this works, run the command as follows :

$ ssh -X remotehost

...and then run xeyes when you get your shell prompt on the other machine. Notice how it automatically displays on your own X server.

Tunnelling an entire X Session over SSH

This is the method used to tunnel an entire X session from a remote host.

$ ssh -X remotehost

$ gdmXnest &

$ export DISPLAY=:20 // DISPLAY=:20 should be the same thing that gdmXnest just printed.

$ gnome-session

Note that if you aren't on the same LAN, you'll probably want to use a lightweight window manager like fluxbox instead of heavy desktops like gnome and kde.

Copying an entire directory to a remote host using SSH

Let us say you want to copy entire contents of the current directory to the directory tree /tmp/dir on the remotehost. This can be done with a combination of tar and ssh as follows:

$ tar cf . | ssh remotehost "cd /tmp/dir ; tar xf -"

Finally, some helpful information for troubleshooting SSH connections and their keys.

If you are having problems connecting to an SSH server , then the steps given below should help you in tracking down your problem as well as prevent future problems. Follow the steps given below while testing your connection after every step.

• Check your logs.

  # less /var/log/secure

  This will contain the logs related to the ssh authentication. It is also a good idea to turn on debugging in /etc/ssh/sshd_config to better clarify the problem. Add the following line to /etc/ssh/sshd_config file.

  LogLevel DEBUG3

• After making changes to the sshd_config file, restart the service.

  # service sshd restart

  You can now view the connection attempts in the console by issuing:

  # tail -f /var/log/secure

  To exit, just do a [Control + C]
• Verify the keypair.

  # ssh-keygen -y

  This can be used to generate the public key for a known private key. By comparing the output of this command to what you believe to be the public key, you can determine if the key's match. For Example:

  [user@linux .ssh]$ ssh-keygen -y
  
  Enter file in which the key is (/home/user/.ssh/id_rsa): /home/user/.ssh/id_dsa
  
  [KEY Here......................................
  
  .
  
  .................................. ]
  
  [user@linux .ssh]$ cat /home/user/.ssh/id_dsa.pub
  
  [KEY Here......................................
  
  .
  
  .
  
  .................................. ]
  
  [user@linux .ssh]$

  Verify that most of the numbers look ok. The odds of two keys being off by only a few numbers are very small. The error would be blatant. If the key's do not match (or do not exist), generate new key's (See the end of this post).
• Check your permissions. SSH is very picky about permissions, so be sure that your user has the correct rights to the files. The most important files are located in ~/.ssh . Do these as root. This assumes that your user's name is user, so you should change the name accordingly.

  # chown user:user /home/user/.ssh
  
  # chmod 700 /home/user/.ssh
  
  # chown user:user /home/user/.ssh/*
  
  # chmod 640 /home/user/.ssh/*
  
  // The following files may not exist
  
  # chmod 600 /home/user/.ssh/identity
  
  # chmod 600 /home/user/.ssh/id_dsa
  
  # chmod 600 /home/user/.ssh/id_rsa

• Check the Settings in sshd_config .

  # vi /etc/ssh/sshd_config

  This file contains the settings used by the SSH Daemon. Any line preceded by a "#" is commented out and shows the default setting. For Example:

  # Port 22

  Means that no change has been made from the default, and the default is Port 22 for SSH connections. Look through the file for the following settings, and note their values. The defaults are listed here.

  #AuthorizedKeysFile .ssh/authorized_keys2
  
  #PasswordAuthentication yes

  For troubleshooting purposes you should comment out the above lines. Also look for:

  AllowUsers

  If that line is present, make sure that your user's name is listed. (If its not listed, you can add it for extra security.) For Example:

  AllowUsers user user1 user2

  Remember to restart the service:

  # service sshd restart

These steps should help you get an SSH session up and running using key authentication. You should be able to track any further problems from the log file, but if you follow these directions, most problems you could face should be mitigated.

Generating New Keys

Note: This is to be done as a normal user. I'm using DSA keypairs for an example.

$ ssh-keygen -t DSA

This will create two files: ~/.ssh/id_dsa and ~/.ssh/id_dsa.pub . You can optionally create a passphrase for the keys, as an added level of security.

Copy the public key to your authorized_keys2 file.

$ cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys2

Copy the id_dsa to your client machine and change its permissions to read/write for the user and none for the group and others.

$ mv id_dsa .ssh/id_dsa

$ chmod 600 .ssh/id_dsa