-
Search Results
-
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 licenseTopic: FAQ Problems
SSH-Conduit
Menu→Help→antiX→antiX FAQ→SSH-Conduit404 Not Found No such file or directoryCause
/usr/share/antiX/FAQ/ssh-conduit.html is missing.
Note: It works OK in te online FAQ.Connectshares
Menu→Help→antiX→antiX FAQ→Connectshares
In the following sections- Setting Up Connectshares,
- Shares on Multiple Remote Systems.
The icon image used in the main menu is not displayed for connectshares-config.png in either Dillo or Firefox.
It is also not displayed in the online FAQ for antiX-17.
http://download.tuxfamily.org/antix/docs-antiX-17/FAQ/connectshares.htmlIt is correctly displayed in the online FAQ for antiX-15.
http://download.tuxfamily.org/antix/docs-antiX-15/FAQ/connectshares.htmlCause
Unknown as the same file is used in both 15 and 17.