Anyone who manages a server knows that managing it remotely is something that always poses some security threats. In most cases though it seems that using SSH they will be able to do this, but they’ll get to end up with defaults and this means there are risks in terms of security.
It’s something that needs to urgently be changed, because after all, no one wants to leave any doors open for hackers and various attacks that would compromise their server in any way. Even if some people would like to resort to using data center staff, they will have to pay a lot for these services and it’s certainly not something many can afford.
Generation and use of key pair authentication
Among the defaults is the ability of having logins protected using passwords, but this is certainly not a safe method. Passwords can easily be tracked by using special software like keyloggers and this would immediately compromise security. To ensure that such scenarios will never be the case, people should think about replacing password protected logins with private/public key pair logins.
The former is going to be carried by the individual all the time and it’s best if they don’t share it with anyone else. It’s been used to authenticate or 'match’ the public key stored on a remote computer the individual needs to gain access to.
However, it’s important to note that using keys only will not have a great impact on improving security, in the event third parties can have access to them. In this case, a third party will be granted access to someone’s server and it won’t even have to bother typing passwords. Inputting a username may also not be the case, because usernames can be guessed fairly easily and protecting them is not really a priority in general.
The truth is that still there are many individuals who are convinced that they can easily gain access to a computer remotely, by just using a SSH key pair and not having to be bothered by entering any passwords. It sound kind of lazy though and it’s the main reason to why passphrases should be used in order to protect these keys when they want to use a SSH connection to access their server. This method though should be perceived as a 2 factor authentication that can be used to access various web apps (example: http://pentagogy.blogspot.com/2012/10/google-authenticator-with-facebook.html
). It’s also good to remember that nothing can be guaranteed on the internet and it’s hard to have a guaranteed 100 percent security over anything, but when a user fortifies his or her server and gets ready for any hacking attacks, they will surely save themselves from a lot of frustration and even from the danger of being fired.
To generate a good key pair, the command below can be used. “acoolpassword” can be substituted with any other pass code, but it needs to be at least comprised of four characters.
ssh-keygen -t rsa -b 4096 -N 'acoolpassword' -f openssh.key
Individuals should be aware that using a few other key types, like RSA, ECDSA and DSA is also possible and some of them are more secure/better performing than others. For this purpose, i’ll chose to go with the RSA. Limiting the number of key bits is advisable, because if they’re too long, performance will suffer.
In the working directory used, (openssh.key.pub and openssh.key) people will be able to see 2 key files. They are the public and the private keys.
Next, people will have to think about strengthening the key permissions, because it’s vital only a single user (original user) can access them and not others. In general, this aspect is going to be taken more in consideration in a multi user environment.
chmod go-rwx openssh.key*
When this will finally get out of the way, the new public key will be ready so that users can finally start to copy it on their server. It’s something that can be done in multiple ways, by either using SCP, FTP or other similar methods. In our example, the SSH’s identity copy will be used.
ssh-copy-id -i openssh.key.pub email@example.com
(change 111's to to your server IP)
Setting Restrictive Access Policy
When the enabling of the ssh key authentication is complete, it’s best if users will fully disable password authentication, because this way the server will only be possible to gain access to by using the keys.
To achieve this, fire up your text editor to edit a SSH server config file:
Look for 'PasswordAuthentication' and 'PermitEmptyPasswords' sections, (uncomment if needed) and change their values to 'no':
PasswordAuthentication noPermitEmptyPasswords no
Additionally, to tighten the configuration even more apply these settings to sshd config file same as above.
Before accepting the login, this option will specify whether ssh should check the permissions of the user in their rhosts files or home directory. It’s an option that users should always leave on “yes”, because there are cases when users may have their files left to be world writable.
This is a command that will specify the amount of time in seconds the server will have to wait after a connection request, before the user will be disconnected if they didn’t log in.
This command specifies whether it’s possible for the root to log in by using ssh. It’s recommend that users will never say yes to this command.
Changing Default Ports
An important aspect regarding SSH is that it will always listen on its default port, 22 and it’s usually left this way because it actually feels convenient for the user to connect to it instead of entering other, less familiar one. The bad news about it is that it is very easily predictable and it can be used in order to further exploit the server’s setup.
To add another security layer though, users are advised to change this port to a non-standard, high port, say 20002. To be clear on this matter, the port can be find regardless of which one the user will go with, but if it’s changed from 22 to another, it will be a bit harder to find. In many cases, it seems that attackers who find it hard to detect server defaults will eventually leave the machine alone and go “play“ with another server which is less secure.
After the changes have been made and saved to the /etc/ssh/sshd_config configuration file, the next step would be to have the ssh service restarted. For those who are on Debian, they will need to use the command:
service ssh restart
Enjoy a bit secure server connection session.
This is just one of attack vectors closed, imagine what security world’s most popular institutions like Google use. Same goes for mission critical government data centres
service providers which spend top dollar on securing their data and access for their clients.
Interesting read on data center security:http://www.informationweek.com/government/security/next-steps-in-data-center-security/240150897
Blog has been viewed (1871) times.