steps toward improving SSH security on your system

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.
Viewing 4 posts - 1 through 4 (of 4 total)
  • Author
    Posts
  • #5170
    Member
    Avatarskidoo

    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 security

    The 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_config

    Add, 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 anne

    You can also use DenyUsers to specifically stop some usernames from logging in:
    DenyUsers planetdude burntwaffle

    After 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_keys

    Alternatively, 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_keys

    Finally, we need to disable password logins, so that all authentication is done by the key pairs.
    sudo nano /etc/ssh/sshd_config

    There are three lines that need to be changed to no, if they are not set that way already:

    ChallengeResponseAuthentication no
    PasswordAuthentication no
    UsePAM no

    Save 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 license

    #5171
    Member
    Avatarskidoo

    Please review the above for accuracy, and post here to suggest any corrections or additions (additional text and/or SeeAlso reference links)

    #5172
    Member
    Avatarskidoo

    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.

    #5388
    Member
    capreacaprea

    Very interesting and comprehensible,I really appreciate,didn’t know much about this. Thanks!

Viewing 4 posts - 1 through 4 (of 4 total)
  • You must be logged in to reply to this topic.