Bag of tricks: Securing SSH done right!
SSH? Unneccessary – I've got Telnet...
This notion might be feasible in a secure environment (i. e. a private
network without direct access from the outside), but when a connection
across the 'Net becomes necessary, it is extremely dangerous.
The problem with Telnet is that it establishes an insecure connection that
can be inspected at any time. Problems arise any time one of the boxes on
the path to your destination is off its rocker and, for example, records the
data traffic.
One could argue that that box doesn't have the correct network address
and therefore cannot be the recipient – but there exists a possibility to
set up a network card in such a fashion that it reacts on
every data packet arriving, no
matter whether or not it is the intended recipient: It's the
promiscuous mode. Though this mode of operation has its
qualification (various networking functions wouldn't be possible
without it), but unfortunately it offers an opportunity for abuse.
Security hazard cleartext
As the name indicates: The entire data stream between any two computers can
be inspected at any time without appropriate measures. Although they
don't react on this data stream, but problems arise whenever any of the
intermediate boxes records the data traffic.
This may turn out to be harmless, because someone is attempting to track
down faults or other problems, but chances are that someone is searching for
confidential data (some possibilities to be mentioned are authentication
information, that is, user ID and password, or account data or other
confidential data) – and the intention behind that are not good at all.
To avoid bad surprises here it is necessary to garble the data stream. When
nothing can be recognized, nobody is going to snoop.
Security hazard connection endpoint
You might wonder why this would
constitute a problem. After all, there is an explicit association of IP
addresses and connection endpoint...
But the devil is, like is all too often, in the details.
As mentioned before there is a way to redirect any data traffic to another
box (the promiscuous mode of a network card), not to mention address
spoofing.
In order not to get out of the frying pan into the fire, something is
necessary to confirm the authenticity of a destination. Because when you are
certain that you are connected with the correct destination, you don't
have to worry about anything strange that could happen.
Why all the fuss?
That can be simply put: This concerns the security on the 'Net. In
order to be able to work securely via the Internet, care has to be taken
that at first the intended destination is reached, and secondly nobody can
spy on what is happening on that connection.
Only this way a secure operation on the 'Net can be guaranteed in the
long run.
This is where SSH is coming in. This way you open a connection that allows
not only the authentification of a user, but also checks a
destination's authenticity and also takes care of screening the data
stream between a user and the destination box from overly prying eyes.
Encrypted, but...
As we have seen before, SSH provides some powerful means to establish a safe environment to work with, but a drop of bitterness still remains: The authentification of a user. Usually a combination of a user ID and a password comes into play here, however, possible attackers quite often attempt to figure out the password – unfortunately a fruitful event in some cases...
to the topSecurity hazard password
Far too often the password proves to be a problem. Unfortunately words are
used that can easily be figured out by a dictionary-based attack, which
quickly grants an attacker access to the system. In other cases passwords
are chosen that can easily be figured out (name of a pet, birth name, name
of one's parents, etc.).
Alas, the best security schemes implemented by SSH are useless when the
interface to the user, that is the authentication, turns out to be the
weak spot. This way you didn't gain anything, plus you are going to
have the attacker on your box quite soon as well.
Therefore some other means is necessary to improve the security of the
authentication process, but fortunately SSH comes to our aid once again.
Preparations
In order to counter dictionary-based attacks and most
brute-force attacks, we need something that cannot be
spoofed that easily. All you have to do for this is generate a pair of RSA
keys which you can use as a means of authentication with SSH.
Open a shell for this purpose and enter the following command:
ssh-keygen -t rsa -f id_rsa
You may as well generate the keys here.
The program is subsequently going to ask you for a passphrase for securing
the private key. In case nobody else is using your computer as well, you can
simply press RETURN here. Otherwise
you may enter anything here (this can be of an arbitrary length, however,
make sure you can remember what you are entering here!) and confirm the
passphrase. ssh-keygen now generates
the pair of keys. This way you are going to obtain two files:
id_rsa and
id_rsa.pub.
id_rsa contains your secret key and
is to remain on your local machine. Copy the file to
~/.ssh.
The other file, id_rsa.pub, is to be
placed on your remote machine. To do this, execute the following command:
scp id_rsa.pub root@<hostname>:/root/.ssh/authorized_keys
(make sure to replace <hostname> with the actual name of your remote
box)
Confirm with root's password
on the remote box to transmit the public key.
In case you want to import another RSA key on your machine after you already have installed some, you must not, under any circumstances copy it to ~/.ssh/authorized_keys, because that is going to overwrite the old keys!
Instead, copy it to /root first and then manually transfer it to the other file!
Please also note that you may only have one key per line to avoid trouble.
Now you have taken care of all preparations necessary to further tighten up
SSH's security.
In case you already have activated RSA authentication you are unable to
authenticate yourself by user ID and password, but it is
mandatory that you enter the
passphrase associated with the old key in order to transfer files or log in!
Otherwise SSH refuses its cooperation and rejects the login attempt.
The proper configuation
After generating your RSA keys and transferring them to their appropriate
locations, all that remains is to properly reconfigure SSH. For this you
need to adjust both the local as well as the remote configuration files.
First of all have a look at the configuration file for the SSH client on
your local machine:
- First of all, open a shell with root privileges.
- Switch to the directory /etc/ssh.
- Load the file ssh_config into your editor.
- Look for lines containing the term IdentityFile.
- If not done so already, uncomment the line (remove the # for this).
- If you so desire, you may also set the line containing VisualHostKey to yes. This way SSH displays the key on the remote machine, allowing you to discover whether or not anything is amiss.
- Finally save the file.
Afterwards the SSH client takes the registered key file into account upon
its next invocation. By the way, you can register a number of keys with your
client this way, for example when you are managing more than one remote
machine (e. g. some servers). For each additional key you need to insert one
more line containing IdentityFile.
Afterwards some adjustments are necessary on your remote machine.
- Log in to your remote machine as root (initially you need to provide the associated password).
- Switch to the directory /etc/ssh.
- Load the file sshd_config into your editor.
- Afterwards search for the lines mentioned in the following table and adjust them accordingly. If necessary, you need to remove any leading #.
- Save the file and leave your editor.
- Afterwards cause the SSH daemon to apply the changes you have made.
Now you are done, and any possible attackers are going to have a much harder time sneaking into your remote machine.
Settings necessary for working safely with SSH | ||
---|---|---|
Parameter | Value | Explanation |
Protocol | 2 | Specifies the version of the protocol used. Protocol version 2 (the default) is the much more secure variant. |
PubkeyAuthentication | yes | permits authentication by generated pairs of keys. Since this method is much more secure than authentication by user ID and password, please make sure to enable this. |
AuthorizedKeysFile | .ssh/authorized_keys | Specifies the file that contains the authorized keys for logging in. For
best security you should leave the default setting as it is since this also
allows any other users (if present) to install their own keys. IMPORTANT: In case you change this setting, you also must make sure to move the file authorized_keys to its new location as well and (in case you also specified a different name) rename it if applicable. Otherwise you are going to neatly lock yourself out! |
HostbasedAuthentication | no | Like PubkeyAuthentication except that the files ~/.ssh/rhosts, or /etc/hosts.equiv respectively, are queried as well. Since you normally are accessing the 'Net from a dynamic (assigned by your provider with each new connection attempt) IP address, you are likely to lock yourself out, therefore enabling this option doesn't really make sense. |
PasswordAuthentication | no | Since you want a secure authentication scheme, more insecure methods are to be disabled completely. Therefore set this option to no (the default would be yes). |
ChallengeResponseAuthentication | no | Usually based on authentication by user ID and password as well. Should therefore be disabled, too, just like PasswordAuthentication. |
UsePAM | yes | Even though you have disabled authentication by password and challenge-response, the PAM module can still be of use, because it can perform some checks on a login attempt. |
After having applied these changes you need to prompt the SSH daemon to apply them. For this, execute one of the following commands:
- With System V init (the default up to openSuSE 11.4): rcsshd reload
- With systemd (the default beginning with openSuSE 12.1): systemctl reload sshd.service
By all means, back up your private key! Should you ever lose it, you don't have a chance to access your remote machine any more!
You alternatively should have another means of logging in available (for example Telnet within an IPsec tunnel or – providing it is offered by your provider – a remote console) that grants you access in case other options fail!
to the top
Attackers – locked out!
By adjusting the configuration of SSH you have provided for improved
security on your machine. In combination with
SuSEfirewall2 you can give any possible attackers a
really hard time!
You only have to properly add to the file
/etc/sysconfig/scripts/SuSEfirewall2-custom. I have described the
necessary modifications exhaustively
under the topic firewall.
Anyone attempting a brute-force attack on your remote machine is quickly
going to find himself locked out, and overdoing it causes him to be locked
out even longer before he gets a reaction. In any case the SSH daemon
won't be bothered temporarily with these invalid connection
attempts.
And in case you fall victim to your own security measures, there's no
need to panic. Just wait for the blockade to time out and try again – or
establish another way of logging in (e. g. via Telnet within an IPsec tunnel).