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.
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.
Many distributions will come with an SSH client installed by default. To get the server on a Debian based distro you can do:
Arch users can install the server/client with:
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:
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:
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:
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):
Then you need to copy your public key to the remote server by doing:
Or you can do it the ol’ fashioned way:
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:
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:
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.
Here are some general rules for denying/allowing SSH access using the hosts files.
Let everyone connect to you
OR you can restrict it to a certain ip
OR restrict for an IP range
OR restrict for an IP match
To learn more about securing SSH check out, Defending against brute force ssh attacks
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.
_ _ _ _ __ (_)_ _| |_ _ _| |_ ___ _ __ | '_ \| \ \/ / __| | | | __/ _ \| '__| | | | | |> <| |_| |_| | || (_) | | |_| |_|_/_/\_\\__|\__,_|\__\___/|_|
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
Was this information useful?
Please tell us why you didn't find this useful. Thanks!
Thanks! Your feedback will help NixTutor improve.