ShareWiz Security

Further documentation about SSH can be found at: Ubuntu SSH help.

Issue the command man sshd_config for further details about the server configuration file.

Default SSH Config Files and SSH Port:

Once you have finished editing the /etc/ssh/sshd_config file, make sure to save your changes before restarting your SSH daemon.

SSH protocol version 1 (SSH-1) has man-in-the-middle attacks problems and security vulnerabilities. SSH-1 is obsolete and should be avoided at all cost.

This defines the number of bits in the ephemeral protocol version 1 server key.

NOTE: The file /etc/ssh/moduli file contains a list of all keys supported.

A recommendation is to remove the smaller groups from the /etc/ssh/moduli file on the server.

When the client asks for a Diffie-Hellman group, sshd searches the moduli file for groups and picks one at random from the set at least as large as what the client requested. If there are no small (eg 1k, 1.5k) keys, then sshd will always use larger ones.

Allowing connections from only certain IP addresses makes a system a lot more secure.

It's recommended to change the listening address.

By default, the SSH daemon ships with remote root logins enabled. Normally Ubuntu does not allow direct access to the root user, so this setting is unimportant. If you have set a password on the root account, this setting can be a potential security risk, and should be disabled.

It is safer to login as another user and use sudo.

NOTE: Sometimes it is necessary to allow root logins when doing automated tasks such as backups. To disallow normal logins but allow forced commands, you can use:

You need to explicitly disallow remote login from accounts with empty passwords.

By default, the OpenSSH server logs to the AUTH facility of syslog, at the INFO level. To record more information - such as failed login attempts - increase the logging level to VERBOSE.

Now all the details of ssh login attempts will be saved in your /var/log/auth.log file.

If you have started using a different port, or if you think your server is well-enough hidden not to need much security, you should increase your logging level and examine your /var/log/auth.log file every so often. If you find a significant number of spurious login attempts, then your computer is under attack and you need more security.

Whatever security precautions you've taken, you might want to set the logging level to VERBOSE for a week, and see how much spurious traffic you get. It can be a sobering experience to see just how much your computer gets attacked.

It's recommended to log more information if you're curious about malicious SSH traffic.

You are setting an idle timeout interval in seconds (900 secs = 15 minutes). After this interval has passed, the idle user will be automatically logged out.

PCI-DSS requires that there be a maximum of 1 concurrent SSH session per user.

SSH can emulate the behavior of the obsolete rsh command. Therefore disable access via rsh. To ensure that SSH does not read the user's ~/.rhosts and ~/.shosts files.

It's recommended to disable rsh access.

Specifically limit traffic to IPv4. This will limit attack vectors.

The options that can be used for this line are:

• inet = IPv4
• inet6 = IPv6
• any = both

It's recommended to limit the system to IPV4 if IPV6 is not used on the system.

The SSH daemon will allow a message to be displayed to users attempting to log in to the SSH server.

To enable login messages, remove the hash sign # from the Banner line.

For legal reasons, it can be useful to display a banner informing people about their legal rights with regards to your server.

This will obviously not dissuade automated SSH attacks, and will potentially worsen Denial-of-Service (DoS) effects, but it may tip off a human attacker that the system is being looked after closely, and that they should move on to some other system on the network.

Alternatively edit the /etc/group file:

...and edit the sshusers line as follows:

NOTE: Besides groups, individual users can also be allowed to access SSH.

As can be seen from the above example, the last few usernames show Active Directory logins. Information on Active Directory can be found elsewhere on this site.

By default, SSH will permit every user with a UNIX account to be able to log in.

You can explicitly allow or deny access for certain users or groups.

An alternative to using AllowGroups is to use the AllowUsers and DenyUsers directives to modify the access rights of these users.

Examples:

To allow access to users username1 and username2, add the following:

To limit access to a specific user from a specific IP address, use something like:

To deny access to specific users, add the following:

IMPORTANT: If using Active Directory logins, remember to add in these users to the sshusers group as well. So in /etc/group, add in users such as:

This can be re-enabled at a later stage once DNS is configured.

By default, OpenSSH gives you two minutes to type a password in once you've connected. You might want to change this if you are worried about attackers, but need to allow passwords.

This doesn't add much security, but also doesn't make it much harder to legitimately use SSH.

Suppose you want to give some users the ability to upload and download files from their home directories (or ~/public_html), but not a full shell account. This is simple to achieve with OpenSSH's SFTP component.

Now peter can use SFTP to read from and write to his ~/public_html/ directory, but can't use OpenSSH to get a shell, nor even to read files outside of ~/public_html.

If you have many such users, you can change User peter to `Group sftponly, and add users to the sftponly group using usermod(8)`. For FTP on such systems, consider vsftpd: it is more security-conscious than other FTP implementations.

The 0.0.0.0 in the first line indictes that SSH is listing on all ports.

The 2nd line can be ignored. This is simply the current connection.

Similarly, the :::in the 3rd line indicates that SSH is listing on all ports with IPV6.

Alternatively use the old-fashioned method to restart the service:

This now shows that SSH is listening on 192.168.0.11 which is out external WAN address.

If there is more than one line, then your SSH daemon is listening on more than one port - you might want to go back and delete some Port lines in your sshd_config file.

If there are no lines, your SSH daemon isn't listening on any ports, so you need to add at least one Port line. If the line specifies something other than "0.0.0.0:22", then your SSH daemon is listening on a non-standard port or address, which you might want to fix.

Notice that the connection was refused. This is due to the earlier config that limited access only from 192.168.0.11. In this case, that allowed IP address was not used, and an attempt was made to login using localhost instead.

This will print a lot of debugging information, and will then prompt whether you want to connect.

The Write failed: Broken pipe message is caused by a timeout issue.

You may recall that the login time was limited in the earlier config.

NOTE:This has however added our WAN IP address into the list of known hosts.

Remember that the password will only be accepted if the corresponding user is allowed access in by SSH.

In this case this would not work, as root was not an allowed user.

If nothing happens, you might need to tell your computer's firewall to allow connections on port 22 (See the FireWall Security section).