OpenSSH

What is SSH?

So what is SSH and why should I care? Well, SSH stands for secure shell and is a way to connect to a remote machine. SSH is popular amongst nix users because it both reliable, secure, and adaptable. SSH is also easy to install and fairly straight forward.

-Why SSH?
Unlike FTP and other protocols SSH is secure, all transactions are encrypted so they cannot be sniffed. Unlike FTP SSH username/password combinations are not sent in clear text. SSH is encrypted from the very beginning. This is important as many web developers will often use FTP to transfer files to their server not knowing that someone could easily sniff the network for their password. Using SSH with programs like scp and sshfs are much safer ways of transferring files to remote machines.

Getting/Installing

Many distributions will come with an SSH client installed by default. To get the server on a Debian based distro you can do:

sudo apt-get install openssh-server

Arch users can install the server/client with:

sudo pacman -S openssh

Configuring the SSH Server

Many times the distro’s default configuration for SSH will work, but I suggest you make some changes. Normally the config file is in: ‘/etc/ssh/sshd_config

Making SSH More secure

Like all services listening on open ports. there is risk. Here are some configuration changes you can make to mitigate some of risk:

Disable SSH protocol 1

The first change I would make is to disable the obsolete SSH 1 protocol from connecting to the server. This protocol is almost never used in modern SSH clients anymore as it is vulnerable to man in the middle attacks. To ensure that none of the SSH clients you use fall back to this protocol it is best we disable it.

Make sure you have this line in your config:

Protocol 2

Add the AllowUsers Tag

By default the SSH server is often set to allow all users to access remotely. It is more secure to specify which users we are going to allow access to this system. This is especially useful for multiuser machines; however, even single user machines can benefit from this tag as generic user accounts can accidentally be created.

Just add this to your config:

AllowUsers user1 user2

Where user1 and user2 are the usernames that you wish to allow remote SSH access.

Disable Root Login

SSH brute force attacks often rely on the username ‘root’. By not disabling root logins you are giving the attacker half the information they need to gain access. They already know the username all they need to do is guess the correct password. It is better to keep them guessing.

What if I need to do something as root? Disabling root logins only prevent the initial login from being root. You can still switch user to root or use sudo once authenticated with a normal user.

To disable root logins make sure you have this set:

PermitRootLogin no

Key based authentication

The first step is to create a key on the local machine.

To create an RSA key do (you can also do DSA):

ssh-keygen -t rsa

Then you need to copy your public key to the remote server by doing:

ssh-copy-id user@remotebox

Or you can do it the ol’ fashioned way:

scp ~/.ssh/id_rsa.pub user@remotebox:.ssh/authorized_keys

Disable password authentication

Once you have successfully tested your key based authentication you can turn off password based authentication. This ensures that all SSH access attempts must authenticate with a key instead of a password. This all but eliminates automated script attacks against SSH.

Turn off password authentication with:

PasswordAuthentication no

Changing the default port

The first line of defense to thwart automated scripts is to simply change the default port of your SSH server. This is security through obscurity. There are ways to detect SSH on any port but moving the port of your ssh server can drastically reduce denied login spam in your logs.

Just change the port to something else like:

Port 223

Port knocking

I talked about the benefits of port knocking in, 9 Ways to Make Linux More Secure and wrote an extensive port knocking how to on my other blog. Port knocking is a great way to open ports remotely by sending a specified sequence or “knock” to the remote server. Once the correct knock is sent, the server will open up the port to the that specific IP address.

hosts.deny/allow

Here are some general rules for denying/allowing SSH access using the hosts files.
Let everyone connect to you

sshd: ALL

OR you can restrict it to a certain ip

sshd: 192.168.0.1

OR restrict for an IP range

sshd: 10.0.0.0/255.255.255.0

OR restrict for an IP match

sshd: 192.168.1.

To learn more about securing SSH check out, Defending against brute force ssh attacks

Personalizing SSH

I like to add a personal touch to the SSH message of the day, (MOTD). I usually will add the server’s name and some other details. This helps distinguish which server I am connecting as I find myself connecting to all kinds of servers throughout the day.

Usually I use a program called, ‘figlet‘ to display my server’s name. Figlet is a application that will convert text to ascii art in various different fonts.

For example:

       _      _         _             
 _ __ (_)_  _| |_ _   _| |_ ___  _ __ 
| '_ \| \ \/ / __| | | | __/ _ \| '__|
| | | | |>  <| |_| |_| | || (_) | |   
|_| |_|_/_/\_\\__|\__,_|\__\___/|_|   
                                    

Accessing SSH from the Outside World

Now that you have your SSH up and running and you can successfully connect to it from another computer in your house it is time to get it connected to the Internet for remote access. If you are not behind a NAT you are probably already set and this section doesn't apply to you; however, most people are now behind some sort of NAT firewall which restricts incoming traffic to a specified port unless you do port forwarding.

As there are many different types of routers I cannot give you the specifics on how you go about forwarding ports; however, there is a website that has almost every router imaginable with the instructions on how to setup port forwarding, portforward.com.

Many of you will also have IP addresses that change. This makes connecting to a remote server very difficult as you need to know what the IP address is. Fortunately, there are free services like dyndns that will give you a static domain name that is updated each time the IP is changed.

What if I am stuck behind a corporate/university firewall and can't forward ports? Have no fear, you can bypass it with a reverse SSH tunnel, but in order to do this you will need a middle computer that has SSH running to the public. This is also how services like, "Go to my pc" work behind a firewall.

Neat things you can do with SSH

Subscribe via Email

Subscribe to Nixtutor via Email

Enter your email address:

Was this information useful?

6 Responses

  1. Ross

    6-3-2009

    Good, stuff, couple suggestions.

    1. Mention restarting ssh after configuration changes
    ‘sudo /etc/init.d/ssh restart’ As I think its necessary to reflect changes, I could be wrong.

    2. You mention changing motd but don’t tell how.

    3. You could use apt:urls for packages

    Good post

  2. The Dozy Kraut

    6-3-2009

    If I remember correctly the RSA key-length defaults to 2048 which some consider inadequate in the face of GPU assisted cracks. You can set the length with -b switch in keygen. 4096 is a fairly good length until NVIDIA comes up with even faster GPUs.

    It is also a good idea to disable password authentication altogether and eschew PAM (it has the nasty habit of keeping password login active, overriding sshd settings)

  3. Mark Sanborn

    6-4-2009

    @Ross
    1. Ahh, yes to restart SSH on a debian based system you use: ‘sudo /etc/init.d/ssh restart’ For BSD type init systems like ones found in Arch Linux use, ‘/etc/rc.d/ssh restart’

    I will add these to the post.

    2. Opps, I’ll add this as well

    3. Yeah, usually I do,

    Thanks for the input :)

  4. Harel Malka

    6-5-2009

    I usually keep SSH servers running on port 443 when its free (i.e., when not serving https). That’s obscurity in obscurity, and its web-filter/firewall proof ensuring you can ssh into your box even when in very restrictive environments.
    Harel

  5. Eric Wendelin

    6-25-2009

    Just setup my SSH server with this post. Very helpful!

    You can personalize the MOTD by:
    figlet “message” > /etc/motd

  6. Yang

    9-6-2009

    That’s absolutely some great security tips in here. I’m going to give the port knocking a try because it seems like a cool idea to keep out port scans. Also I’m thinking about allowing only 1 ip to have access to my server as I have a fixed IP from my home PC. I figure I can do it with hosts.deny/allow except I can’t find them on my server. Does that come with denyhosts the failure logins detector package?

    I don’t quite like the idea of private/public key authentication because what if I lost my keys(the files containing the keys) and I have prohibited authentication by password? How am I supposed to reach into my server and get things back?