Many years ago, people used telnet to connect to their machines, but the whole communication between their computers and the remote machine was sent in clear text (unencrypted), making sensitive information available to anyone who knew how to monitor their traffic. They had to find a way to prevent this. So SSH was born.

OpenSSH originally, was created as an open source alternative to the proprietary SSH offered by the Finish company SSH Communications Security but it became very fast a de-facto standard in remote server management in access. Unlike telnet, the whole communication is encrypted, making the process of finding sensitive information by unauthorized people (almost) impossible. Even if someone is able to decrypt the information, that will take a very long period of time (and I'm talking about years and tens of years), making the information useless when the decryption is done.

OpenSSH has many configuration options and authorization mechanisms. What I'll do next is to propose you a more secure way for running a SSH server.

• Change the default port number

The default port number is 22. I suggest you to change to to something randomly and higher than 1023, and also make sure that port is not a standard port for another service. You can do this by looking at IANA's Port Assignments. This will prevent most scriptkiddies from attacking your SSH server and/or generating extra traffic.

• Use only the version 2 of the protocol

On some Linux distros, OpenSSH is still configured to use the 1st version of the protocol. Make sure you change this behavior!

• Do not allow root login

Every attacker will want to gain root access into your box. Disabling root access will make the attacker's life harder, because he first has to find an authorized user, crack into the box, then he has to make smth to gain root access.

• Use Authentication based on public-keys

Passwords are good. Having a complex password, makes your server secure. But public-keys are better. Using public-keys is like speaking the same language with your server. You have a private key/public key pair. You hold the private one just for yourself. Do NOT share that! It's like a password! The pubic key has to be on the server. When you are using your private key to access your machines, the machines know that your private key makes a pair with the public one. Now you are talking the same language. If someone tries to access your server with another private key, the server will deny the access because those 2 keys are not making a pair. It's like 2 people speaking different languages, but none of them understands what the other one is saying.

If you're using pubkeys don't forget to disable the other authentication mechanisms.

• Forward X11 _only _ if needed

By default, the X11Forwarding directive is set to yes. If you don't need this, set it to no. If you are not sure if you need it, set it to no until you find out that you really need this feature.

• Make use of Allow/Deny Users/Groups

In most cases, not everyone should access your server remotely. AllowUsers, AllowGroups, DenyUsers and DenyGroups directives helps you to control better who's going to have remote access to that box.

• Allow access only from known hosts

You should restrict the access for remote logins only from known/trusted hosts. You can do this in a number of ways. First, you can use TCP_WRAPPERS, which means you have to add your known hosts in /etc/hosts.allow (eg: sshd: 10.1.1.0/255.255.255.0), the and the line "sshd: ALL" in the /etc/hosts.deny. Another option is to use iptables. Grant access to any known host, then reject access to all others (0.0.0.0/0). Why am I saying reject? Because REJECT should be the iptables target you should use, not DROP. Using DROP, will be easier for your attacker to find that your ssh port is filtered. Using REJECT with --reject-with tcp-reset will make the attacker's life a little bit harder on finding the port you are blocking, but keep in mind that "little bit harder" because it's not impossible.

There are cases when you will not know from where you'll have to login, or maybe your home ISP is giving your IP through DHCP. You can grant remote access to anyone, which is not the best option, or you can use Port Knocking. As I said a couple of days ago, knockd is one of the best implementations, but right now is limited to Linux. The maintainer is trying to get it running on BSDs also, but he's asking for some help, so if you are a programmer, you are using a flavor of BSD and you have some time to give a hand, please do so.

I hope that's enough to get started with a more secure OpenSSH server, and don't forget: OpenSSH is an open source project, anyone can help, and if you can, I encourage you to do so. If you can't help with programming but you have some financial power, I'm sure Theo De Raadt will be happy to see a donation for his efforts as well as his team's efforts on developing OpenSSH