Forum › Forums › antiX-development › Documentation › steps toward improving SSH security on your system
- This topic has 3 replies, 2 voices, and was last updated Jan 17-1:09 am by caprea.
-
AuthorPosts
-
January 14, 2018 at 12:44 am #5170
Anonymous
Improving SSH security
SSH is a common way of accessing a computer remotely. By default, logging in with SSH requires a username/password pair, and there are ways to make this more secure. An even more secure method is to use key based authentication.
.
Improving username/password securityThe most important thing to do is ensure you have a very robust password. If your computer is exposed to the internet, the password needs to be very secure. This will help to avoid dictionary attacks or the like.
You can also allow or deny specific users by altering the sshd configuration.
sudo nano /etc/ssh/sshd_configAdd, edit, or append to the end of the file the following line, which contains the usernames you wish to allow to log in:
AllowUsers shawna andrew charles anneYou can also use DenyUsers to specifically stop some usernames from logging in:
DenyUsers planetdude burntwaffleAfter the change you will need to restart the sshd service using sudo service ssh restart or reboot so the changes take effect.
.
Using key-based authentication.Key pairs are two cryptographically secure keys. One is private, and one is public. They can be used to authenticate a client to an SSH server (in this case, your computer _is_ the server).
The client generates two keys, which are cryptographically linked to each other. The private key should never be released, but the public key can be freely shared. The SSH server takes a copy of the public key, and, when a link is requested, uses this key to send the client a challenge message, which the client will encrypt using the private key. If the server can use the public key to decrypt this message back to the original challenge message, then the identity of the client can be confirmed.
Generating a key pair in Linux is done using the ssh-keygen command on the client; the keys are stored by default in the .ssh folder in the user’s home directly. The private key will be called id_rsa and the associated public key will be called id_rsa.pub. The key will be 2048 bits long: breaking the encryption on a key of that length would take an extremely long time, so is very secure. You can make longer keys if the situation demands it. Note that you should only do the generation process once: if repeated, it will overwrite any previous generated keys. Anything relying on those old keys will need to be updated to the new keys.
You will be prompted for a passphrase during key generation: this is an extra level of security. For the moment, leave this blank.
The public key now needs to be moved on to the server. This can be done by email, or cut and paste, or file copying. Once on the server it needs to be added to the SSH systems authorised keys. It should be emphasised that the id_rsa file is the private key and SHOULD NOT LEAVE THE CLIENT, whilst the public key file is id_rsa.pub.
Add the new public key to the authorisation file as follows:
cat id_rsa.pub >> ~/.ssh/authorized_keysAlternatively, you can edit the file sudo nano ~/.ssh/authorized_keys and copy/paste the key in. It is perfectly acceptable to have multiple entries in the authorized_keys file, so SSH can support multiple clients.
Note that the authorized_keys file needs the correct permissions to be read correctly by the ssh system.
sudo chmod 644 ~/.ssh/authorized_keysFinally, we need to disable password logins, so that all authentication is done by the key pairs.
sudo nano /etc/ssh/sshd_configThere are three lines that need to be changed to no, if they are not set that way already:
ChallengeResponseAuthentication no PasswordAuthentication no UsePAM noSave the file and either restart the ssh system with sudo service ssh reload or reboot.
.
_________________
the above is derived from documentation published by the Raspberry Pi Foundation
and distributed under the CC BY-CA licenseJanuary 14, 2018 at 12:50 am #5171Anonymous
::Please review the above for accuracy, and post here to suggest any corrections or additions (additional text and/or SeeAlso reference links)
January 14, 2018 at 1:12 am #5172Anonymous
::paraphrased excerpt from a prior discusison:
.
I checked my system using rkhunter, and it found a vulnerability in SSH configuration: The ability to login as root without password.
How can I remove this ability to login as root without password?- – – – – – – – – – – – –
The antiX as-shipped default setting does not represent a vulnerability. To understand why, See: what-does-without-password-mean-in-sshd-config-file
You are free to disable SSH root login by editing /etc/ssh/sshd_config and specifying PermitRootLogin no
Further steps, toward “hardening”:
• install the fail2ban package
• if you expect to never login via SSH, consider disabling autostart of the ssh service. To do so, launch sudo sysv-rc-conf and untick ssh, across all runlevels.January 17, 2018 at 1:09 am #5388Moderator
caprea
::Very interesting and comprehensible,I really appreciate,didn’t know much about this. Thanks!
-
AuthorPosts
- You must be logged in to reply to this topic.