securing SSH and disabling direct root

Question

In these instructions below what appears on my terminal is different so not sure what I should change. After port 22 mine says #AddressFamily any and further down for protocol it has longer line saying #activation of protocol 1 then on line below uncommented Protocol 2. Also if you disable direct root login do you use sudo instead with same password you created for root?

Scroll down to the section of the file that looks like this:

#Port 22
#Protocol 2, 1
#ListenAddress 0.0.0.0
#ListenAddress ::

Uncomment and change

#Port 22 
to look like 
Port 5678 (choose your own 4 to 5 digit port number (49151 is the highest port number AND do not use 5678  lol )

Uncomment and change 
#Protocol 2, 1
to look like 
Protocol 2

Uncomment and change 
#ListenAddress 0.0.0.0
to look like 
ListenAddress 123.123.123.15 (use one of your own IP Addresses that has been assigned to your server)

Note 1: If you would like to disable direct Root Login, scroll down until you find

#PermitRootLogin yes
and uncomment it and make it look like 
PermitRootLogin no

whereas mine is this:

#Port 22
#AddressFamily any
#ListenAddress 0.0.0.0
#ListenAddress ::

# Disable legacy (protocol version 1) support in the server for new
# installations. In future the default will change to require explicit
# activation of protocol 1
Protocol 2

argh you have to do an online course just to work this forum :/

Answer 1

OpenSSH follows the "commented out defaults" policy. This means that the (system wide) configuration file contains most available options which - if not commented out - would have the same value as the application defaults that are hard-wired into the actual executable binaries. Since some time ago, the default Protocol setting value was changed from 2, 1 to 2 only. Hence instructions based on older releases do not apply literally today. Another thing to consider is, how a particular distribution changes the file in their package.

As for the settings:

• unless you are using ancient applications, keep Protocol set to just 2 - as often, unless you know what it means, keep the defaults;

• changing port doesn't make much sense, unless you only have some ports available due to restrictions placed upon you by the network you are on. It definitely is not a security hardening measure.

• preventing direct root access is a good idea. You may also want to disable password logins and use only private key authentication, since it is much more difficult (read impossible) to break by brute-force. It can also effectively create a two level authentication for root access (first the private key to log in and then password to su or sudo). On the other hand, you wouldn't be able to log in without the key (which can pose a serious problem in some situations).

• binding to a specific address doesn't make much sense, unless you really want to serve it only one network interface. Again - if you are not sure, don't change it. On a machine that has dynamic IP address, it could even cause temporary unavailability of the service.

Answer 2

I'm not sure if I really understood your question, nevertheless here's the key points I got:

• The order of the configuration entries in the config file is irrelevant. That's why you file might have a different layout then the one in the instructions you have. You should just make sure you only use each parameter once in the file.
• As @Mark stated, it's a matter of your environment whether you can go with protocol 2 only. If you want to enable version 1 and 2, the line should read Protocol 1,2
• Changing the port is a matter of taste (or convention, in some cases) and does not increase security: An attacker can easily do a portscan to figure out which port your SSHD is running on. (Well, you can prevent portscanning in some ways, but it's just a matter of time and resources for a skilled attacker to find out.)
• Allowing root logins is a security issue: You're not just permitting a username everyone knows (so an attacker can focus on brute-forcing the password for that valid username), but also to the one account which is most permissive. Unless there's good reasons, I'd suggest PermitRootLogin no and then either su or sudo, depending on your policy.
• sudo requires the user to enter her own password again, while su asks for root's password. The difference is that su actually opens a root shell for the user where he is root. sudo allows the user to run certain commands as root. A secure sudo configuration is a matter of experience (e.g. if you're allowing users to run bash as root, you're basically allowing root access to every sudoer), so sudo does not increase security by simply enabling it.
• Binding SSHD to a specific IP address via ListenAddress is only useful on hosts that are connected to multiple networks. On such systems, there's a security gain if you limit SSH access to those networks that you require SSH access from.

Answer 3

Only have partial answers and suggestions.

From the comments and my own sshd config file on ubuntu 10.04 I would suggest that you go with Protocol 2. Unless you have legacy/slighly older ssh clients.

The ListenAddress binds the ssh daemon to a specific interface(corresponding to the ip). Leaving it as 0.0.0.0 will bind to all interfaces (not just external but also localhost/loopback) whereas specifying an IP address will bind it to that single interface.

PermitRootLogin no will mean you cannot use root to login over ssh. While you are logged in you can still switch to the root user, although I would think that best practice is to use sudo.

Changing the Port will obviously change the port ssh listens on. Im not sure where you got the range of available ports from. Some ports are reserved see http://en.wikipedia.org/wiki/List_of_TCP_and_UDP_port_numbers for an extensive list. port numbers can go up to 65535 and really ports above 1024 are fair game as long as you know you arent clobbering anything.

Hope that helps!

Mark

Answer 4

The order of lines in sshd_config is irrelevant, except for one thing: each line that begins with the word Match starts a new section, and the arrangement of these sections is important.

Lines that begin with # are commented out: they are ignored. You may see them in the default configuration file as examples of things you could write if you wanted. You don't have to comment out the line to change a setting, you can write extra lines as you wish.

For example, #Port 22 is there because the default port is 22. If you remove the # character, you'll explicitly set the port to 22, which doesn't actually change anything. If you remove the # and change the number, this will cause the SSH server to listen on a different port. You can also leave the commented-out line alone (if it's present at all) and write Port 1234 on a separate line.

Listening on a different port is not very useful: attackers know how to find servers listening on any port, the risk is only marginally reduced. The only benefit to changing the port is that you'll get fewer automated attempts (hunting weak passwords) in your logs. That's not worth it: changing the port will make your server unreachable behind some firewalls that only allow encrypted traffic on certain ports.

Having Protocol 2 is a good idea unless you know you want to be able to use extremely old clients.

ListenAddress is only useful for certain configurations where you want the SSH server to listen only on one network card. You don't need it.

PermitRootLogin no is usually a good idea, but it's not the absolute no-brainer some people make it out to be. It only provides a direct security benefit if your root password is weak or leaked (not a good idea) or if you allow root to log in with a weak or leaked key (ditto). If root can't log in directly, it means users have to first log in with their own account. This is good for accountability, to know what happened after the fact when legitimate users have logged in. In most setups, malicious users can alter the logs after the fact, so the extra step they took won't be visible.

Another common hardening setting is to require users to use key pairs instead of passwords for authentication, i.e. disable password authentication:

PasswordAuthentication no

You should only leave password authentication allowed if:

• all your users can be trusted to pick strong passwords; and
• all your users can be trusted never to log in from trusted machines (where they are sure there is no keylogger or the like).