Running sshd to allow remote system access is a necessity for many of us. Because pwned *nix boxes are highly prized possessions, you'll want to take extra care in keeping nasty folks out.

What follows is a brief list of beginner-oriented tips on hardening sshd. (Note that some of this advice may already be implemented by your OS by default.) All directive examples will of course apply to your /etc/ssh/sshd_config file, and changes to that file only take effect after sshd is reloaded/restarted. The manpages for sshd(8) and sshd_config(5) are available on your system with plenty of additional info.

-----------------------------------------

Disable Protocol 1
Unless it is absolutely required, you should disable it such that your config reads "Protocol 2" (not "Protocol 1" or "Protocol 2,1"). Why? Protocol 1 has known exploits.

Do not allow direct root logins
Simply put: everyone knows root exists on the system, so it will be a popular target for brute force attacks. The config directive should read "PermitRootLogin no".

Utilize the AllowUsers or AllowGroups directives
It's likely that not all users (shell users or otherwise) on your system require ssh access. By using one of these directives, you take advantage of a 'deny by default' policy by only letting those you specifically allow to ssh in.

Example: "AllowUsers tom jerry bill"

Implement a strategy to restrict access at the IP level
It is usually (not always) unnecessary to have your sshd daemon available to connections from all over the world. If you have clients who require ssh access only from Los Angeles, then it would be silly to be also accepting connections from, e.g., China.

Restricting access at the IP level can be achieved in (at least!) three ways:

Using a packet filtering firewall (examples: PF, IPFW).

Using hosts.allow (the tcp wrappers access list).

Using sshd's AllowUsers directive with the form user@host.

Consider locking down authentication mechanisms
The idea here is that if you are not going to be using an authentication method, it wouldn't hurt to shut it off. (See the sshd_config(5) manpages, and your /etc/ssh/sshd_config file; search for 'Authentication' to see its various forms.)

Do you require only password authentication? Then, in most cases, you should probably use the directives "UsePAM yes" and "ChallengeResponseAuthentication yes". For all other authentication methods, use "no".

If you require a higher level of security, and circumstances allow its implementation, also consider using only PubkeyAuthentication. (Don't forget to turn the other authentications methods off once it's set up properly.) This will render brute force / password guessing attempts over ssh useless.

Consider listening on only relevant interfaces, for relevant traffic
By default on many OSes, sshd will listen on all active interfaces for both IPv4 and IPv6 traffic. You might consider limiting this if you really only require ssh access on a certain interface. If you will not be using IPv6 in the foreseeable future, it probably wouldn't hurt to turn that access off as well.

Example: "ListenAddress 10.0.20.55"
Example: "AddressFamily inet"

Consider implementing a usage banner
Directly from the sshd_config(5) manpages:

Quote:

In some jurisdictions, sending a warning message before authenti- cation may be relevant for getting legal protection.

The key here is understanding the laws and policies that apply to you, your organization, your country, etc. The banner text, which we'll put in an example file called /etc/ssh-banner, might read something like: "Unauthorized use of this computer and its resources is prohibited. By logging in to this computer, you agree that... etc." (But that is for you to determine.)

Example: "Banner /etc/ssh-banner"

Monitor and react to problems
Security is an ongoing process. It's crucial that you:

Review your logs regularly.

Review your system email regularly.

Stay current with security updates to OpenSSH.

-----------------------------------------

Hopefully these tips will be helpful in getting you on your way to a more secure sshd environment. Stay safe and stay happy.

__________________religions, worst damnation of mankind"If 386BSD had been available when I started on Linux, Linux would probably never had happened." Linus TorvaldsLinux is not UNIX! Face it! It is not an insult. It is fact: GNU is a recursive acronym for “GNU's Not UNIX”.vermaden's:linksresourcesdeviantartspreadbsd

Yes, I agree with vermaden. It really helps if you change the default ssh port number. Since almost anyone trying to brute force the machine, will be trying the default port, but if that person doesn't know your ssh port number, then there's not much left to do.

Yes, I agree with vermaden. It really helps if you change the default ssh port number. Since almost anyone trying to brute force the machine, will be trying the default port, but if that person doesn't know your ssh port number, then there's not much left to do.

You can also use nmap to scan all 1-65536 ports of any server, which will tell you what you run on what port.

__________________religions, worst damnation of mankind"If 386BSD had been available when I started on Linux, Linux would probably never had happened." Linus TorvaldsLinux is not UNIX! Face it! It is not an insult. It is fact: GNU is a recursive acronym for “GNU's Not UNIX”.vermaden's:linksresourcesdeviantartspreadbsd

I'm sure that poster was aware of this, but, scanning all the ports on a host takes a lot of time... most "brute force" script kiddies that search for SSH on a rage.. typically only attempt port 22.

Yeah, port other then 22 makes a lot less useless junk in ssh logs

__________________religions, worst damnation of mankind"If 386BSD had been available when I started on Linux, Linux would probably never had happened." Linus TorvaldsLinux is not UNIX! Face it! It is not an insult. It is fact: GNU is a recursive acronym for “GNU's Not UNIX”.vermaden's:linksresourcesdeviantartspreadbsd

Correct me if I'm wrong. But you can use the firewall to block scans and pings to your computer.

Yes, it is possible to block only nmap packets with specific SYN or ACK flags, if you google for that you will find whole howtos how to do that.

__________________religions, worst damnation of mankind"If 386BSD had been available when I started on Linux, Linux would probably never had happened." Linus TorvaldsLinux is not UNIX! Face it! It is not an insult. It is fact: GNU is a recursive acronym for “GNU's Not UNIX”.vermaden's:linksresourcesdeviantartspreadbsd