Secure Shell

Secure Shell

From Consultancy.EdVoncken.NET

Jump to: navigation, search

Contents

[edit] What is Secure Shell?

Secure Shell (SSH) is a secure replacement for Telnet, FTP and the r* protocols (rsh, rcp, rlogin). All communications are encrypted, and there are several options for user authentication. Secure Shell uses the SSH2 protocol for data transfer.

Furthermore, you can use SSH to tunnel any TCP-based application securely across the Internet or company network.

On Unix, SSH is part of the standard installation. SSH can also be installed for Windows; it is built on a Cygwin environment.

See OpenSSH for Windows for more information.

[edit] SSH Authentication Options

Secure Shell offers many authentication options. The most popular ones are described below.

[edit] Password Authentication

Secure Shell first establishes an encrypted connection between the client and the server. Then, the user types his/her password. Hence, passwords are never transmitted in "cleartext", however you are sharing the "secret" with the server. A better and more comfortable solution is to use Public Key Authentication.

[edit] Public Key Authentication

Public Key Authentication makes use of complex mathematics, where a "Key Pair" is constructed. A Key Pair consists of a "Public key" and a "Private key". You can share the Public key with anyone. The Private key must be kept secret.

The trick is, that you don't actually share your secret (like with passwords) but you only prove (mathematically) that you are in possession of the Private key. The other party verifies this using their copy of your Public key.

Don't worry - you don't need to understand the mathematics to be able to use it ;-)

[edit] Creating your Key Pair 

 ssh-keygen -t dsa

This will prompt you to set a pass phrase. Always set a strong pass phrase on your private key! If you use the Authentication Agent, you'll only need to type your pass phrase once.

[edit] Authorized_keys

OK, so now you have your Key Pair. Next step is to "authorize" your key on the destination host (the server). Typically, there is a file /home/username/.ssh/authorized_keys that contains one or more public keys. The example below is for root access: 

 $ cat /root/.ssh/authorized_keys
 environment="LOGNAME=edvoncken" ssh-dss AAAAa1kcCP3ml ... eA5s+SeuTk4/A edvoncken@laptop
 environment="LOGNAME=edvoncken" ssh-dss AAAAB3Nza1kc ... mQs4Yg== edvoncken@workstation

The public keys are actually very long lines of text; I shortened them significantly here.

Each line looks like this: 

 options key-type key comment

Apparently, I am using two different key pairs: one is called "edvoncken@laptop", the other one is "edvoncken@workstation". I keep my private key on my laptop. If my laptop was ever stolen, I can simply remove all lines referring to the laptop-key so the thieves cannot gain access to my accounts.

The "environment" option ensures that LOGNAME gets set to "edvoncken" if I log on using that key. I use that for RCS and CVS mostly. Otherwise, every change would appear to be from "root". If you manage hosts with a team, it is vital to identify individual admins.

[edit] Authentication Agent

The nicest feature with Public Key Authentication, is the use of an Authentication Agent. It is a piece of software that runs on your computer, and answers all "authentication requests" for you. In other words, it will present your SSH Public Key to the SSH Server.

In practice, this works as follows. In the morning, you:

  • start the Agent
  • load your Private Key into the Agent, and supply your pass phrase

The rest of the day, you only need to:

  • open a connection to the server; authentication is performed automatically - no passwords or pass phrases to type!

[edit] Forced Commands

[edit] SSH Bouncing

Sometimes you need to get past a bastion host to reach your target host. This can be accomplished in several ways; you can log on to the bastion host, then set up a new SSH connection to the target host. This has the disadvantage that automatic logins and file transfer (scp) become very cumbersome.

A transparent method is preferred. Two strategies can be used. The obvious one uses a forced command to set up an SSH connection within the SSH connection. However, this introduces a lot of overhead. A simpler solution can be achieved using netcat (nc):

1. On your Unix workstation, add a section to your ~/.ssh/config for each target host you need to access: 

   Host dbs101
     Hostname dbs101
     ProxyCommand $HOME/bin/netcat-proxy-command 192.168.1.1 192.168.15.101
   
   Host dbs102
     Hostname dbs102
     ProxyCommand $HOME/bin/netcat-proxy-command 192.168.1.1 192.168.15.102

Note: there is a generator script that will output these entries for you; just put the entries in your ~/.ssh/config file.

2. On the bastion host (192.168.1.1 in this example), add the following forced command to the appropriate SSH key in your ~/.ssh/authorized_keys: 

 command="/usr/local/bin/ncssh" ssh-dss AAA[...] me@laptop

3. There is no step 3 ;-)


[edit] netcat-proxy-command

Install the following script on your Unix workstation: 

   #!/bin/sh
   #
   # Purpose:
   #  Connect to destination host through a bouncing host,
   #  a.k.a. stepping stone or bastion host
   #
   # Notes:
   #  Use this command in your ~/.ssh/config on the source host
   #
   # Source:
   #  http://www.mail-archive.com/isn@attrition.org/msg03284.html
   #
   # File $Id:$
   
   BOUNCEUSER=evoncken
   BOUNCEHOST=$1
   TARGET=$2
   
   # Solaris and Linux have SSH in different locations
   # Try Solaris CSW package in /opt/csw first
   SSH=/opt/csw/bin/ssh
   if [ ! -x $SSH ]; then
     # Linux, or use Sun SSH on Solaris
     SSH=/usr/bin/ssh
   fi
   
   $SSH ${BOUNCEUSER}@${BOUNCEHOST} nc -w 1 $TARGET 22
   
   # EOF


Remember to change BOUNCEUSER to your own username on the bouncing host (for DCS Andover, this is your local account on the bastion host (192.168.1.1 in this example).

[edit] ncssh

Install the following script on your bouncing host as /usr/local/bin/ncssh - remember that netcat (nc) has to be available: 

   #!/usr/bin/perl
   #
   # Server-side program to allow clients to run ncssh-proxy
   # or simply 'ssh ... nc -w 1 ipaddr 22' and 'bounce' off
   # this host.
   #
   # BUGS:
   #   Only allows IP addresses.  If that annoys you,
   #   change $IPADDR pattern below.
   #
   #   Ditto for the destination port.
   #
   # Copyright 2003,2004 Brian Hatch
   #
   # Source: http://www.datastronghold.com/content/view/141/29/
   #
   # File $Id: ncssh,v 1.1 2006/12/15 10:56:23 evoncken Exp evoncken $
   #
   # Released under the GPL
   
   # Likely paths for netcat - let's be paranoid and not
   # fall back on just any old thing we find.
   # Bonus points to anyone who knows why /usr/local/lib/pingers is in there.
   my @nc = qw( /usr/bin/nc /usr/local/bin/nc /opt/csw/bin/nc /usr/local/lib/pingers/nc );
   my $nc;
   for my $bin ( @nc ) {
    $nc = $bin if -x $bin
   }
   
   my $IPADDR = '\d+\.\d+\.\d+\.\d+';
   
   my $SSHPORT = '22';
   # Change '22' to '\d+' if you want to allow any
   # destination port, not just port 22.
   
   # The original command (nc -w 1 ip.ad.dr.es 22) is stored by
   # the SSH server in the environment variable SSH_ORIGINAL_COMMAND.
   my $orig = $ENV{SSH_ORIGINAL_COMMAND};
   
   # If command is just the IP address to which it should connect
   if ( $orig =~ /^ \s* $IPADDR \s* $/x ) {
    $ipaddr = $orig;
   
   # If command is a 'nc -w ... host 22' style command
   } elsif ( $orig =~ /^ \S* (netcat|nc) \s .*? ($IPADDR) \s $SSHPORT \s* $/x ) {
    $ipaddr = $2;
   }
   
   # Time to actually run netcat
   if ( $ipaddr ) {
    $nc or print STDERR "No netcat found\n" and exit 1;
    exec $nc, '-w', '1' , $ipaddr, 22;
    die "Unable to exec netcat '$nc': $? $!";
   }
   print STDERR "You're not allowed to execute '$orig'\n";
   exit 1;
   
   # EOF

[edit] See Also

[edit] Tips and Tricks

[edit] Server Configuration

Stop people from guessing the root password 
Set "PermitRootLogin without-password" in /etc/ssh/sshd_config.
Disable the old protocol versions
Set "Protocol 2" in /etc/ssh/sshd_config.

[edit] Removing outdated host keys

Say, you SSH into a re-installed host 'newhost' that now has a new fingerprint, and SSH complains about line 46 containing the offending key. What to do? Just this: 

 sed -i "46 d" ~/.ssh/known_hosts

There's also a nicer way to achieve the same: 

 ssh-keygen -R newhost

[edit] Software Links

Several SSH clients and servers exist. The most popular are PuTTY (Windows client) and OpenSSH (multi-platform server). All software mentioned here is available under an Open Source license.

[edit] Other reading

Retrieved from "http://consultancy.edvoncken.net/index.php/Secure_Shell"