5 SSH Hardening Tips

5 SSH Hardening Tips | Linux.com | The source ...
https://www.linux.com/learn/5-ssh-hardening-tips
LOGIN / CREATE ACCOUN T
News for the Open Source Professional
BROUGHT
T O YO U
BY
CA R LA S CH RODE R
(/USERS/CSCHRODER)
(/USERS/CSCHRODER)
J U N E 29, 2016
5 SSH Hardening Tips
Make your OpenSSH sessions more secure with these simple tips.
Creative Commons Zero (/licenses/category/creative-commons-zero)
1 de 8
14-07-2016 15:48
When you look at your SSH server logs, chances are they are full of
attempted logins from entities of ill intent. Here are 5 general ways (along
with several specic tactics) to make your OpenSSH sessions more secure.
1. Make Password Auth Stronger

Password logins are convenient, because you can log in from any machine
anywhere. But they are vulnerable to brute-force attacks. Try these tactics
for strengthening your password logins.
Use a password generator, such as pwgen. pwgen takes several options;
the most useful is password length (e.g., pwgen 12 generates a
12-character password).
Never reuse a password. Ignore all the bad advice about not writing
down your passwords, and keep a notebook with your logins written in
it. If you don't believe me that this is a good idea, then believe security
guru Bruce Schneier (https://www.schneier.com/blog/archives/2005/06
/write_down_your.html). If you're reasonably careful, nobody will ever
nd your notebook, and it is immune from online attacks.
You can add extra protection to your login notebook by obscuring the
logins recorded in your notebook with character substitution or
padding. Use a simple, easily-memorable convention such as padding
your passwords with two extra random characters, or use a single
simple character substitution such as # for *.
Use a non-standard listening port on your SSH server. Yes, this is old
advice, and it's still good. Examine your logs; chances are that port 22
is the standard attack point, with few attacks on other ports.
Use Fail2ban (http://www.fail2ban.org/wiki/index.php/Main_Page) to
2 de 8
14-07-2016 15:48
dynamically protect your server from brute force attacks.

Create non-standard usernames. Never ever enable a remote root login,
and avoid "admin".
2. Fix Too Many Authentication Failures

When my ssh logins fail with "Too many authentication failures for carla"
error messages, it makes me feel bad. I know I shouldn't take it personally,
but it still stings. But, as my wise granny used to say, hurt feelings don't x
the problem. The cure for this is to force a password-based login in your
~/.ssh/cong le. If this le does not exist, rst create the ~/.ssh/ directory:
$ mkdir ~/.ssh
$ chmod 700 ~/.ssh
Then create the ~/.ssh/cong le in a text editor and enter these lines, using
your own remote HostName address:
HostName remote.site.com
PubkeyAuthentication=no
3. Use Public Key Authentication

Public Key authentication is much stronger than password authentication,
because it is immune to brute-force password attacks, but its less
convenient because it relies on RSA key pairs. To begin, you create a
public/private key pair. Next, the private key goes on your client computer,
and you copy the public key to the remote server that you want to log into.
You can log in to the remote server only from computers that have your
private key. Your private key is just as sensitive as your house key; anyone
who has possession of it can access your accounts. You can add a strong
layer of protection by putting a passphrase on your private key.
Using RSA key pairs is a great tool for managing multiple users. When a user
leaves, disable their login by deleting their public key from the server.
3 de 8
14-07-2016 15:48
This example creates a new key pair of 3072 bits strength, which is stronger
than the default 2048 bits, and gives it a unique name so you know what
server it belongs to:
$ ssh-keygen -t rsa -b 3072 -f id_mailserver
This creates two new keys, id_mailserver and id_mailserver.pub. id_mailserver
is your private key -- do not share this! Now securely copy your public key
to your remote server with the ssh-copy-id command. You must already
have a working SSH login on the remote server:
$ ssh-copy-id -i id_rsa.pub user@remoteserver

/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to
user@remoteserver's password:
Number of key(s) added: 1
Now try logging into the machine, with:
"ssh 'user@remoteserver'"
and check to make sure that only the key(s) you wanted were added.
ssh-copy-id ensures that you will not accidentally copy your private key.
Test your new key login by copying the example from your command output,
with single quotes:
$ ssh 'user@remoteserver'
It should log you in using your new key, and if you set a password on your
private key, it will prompt you for it.
4. Disable Password Logins

Once you have tested and veried your public key login, disable password
logins so that your remote server is not vulnerable to brute force password
attacks. Do this in the /etc/sshd_cong le on your remote server with this
line:
PasswordAuthentication no
Then restart your SSH daemon.
4 de 8
14-07-2016 15:48
5. Set Up Aliases -- Theyre Fast and Cool

You can set up aliases for remote logins that you use a lot, so instead of
logging in with something like "ssh -u username -p 2222
remote.site.with.long-name", you can use "ssh remote1". Set it up like this
in your ~/.ssh/cong le:
Host remote1
HostName remote.site.with.long-name
Port 2222
User username
PubkeyAuthentication no
If you are using public key authentication, it looks like this:
Host remote1
HostName remote.site.with.long-name
Port 2222
User username
IdentityFile ~/.ssh/id_remoteserver
The OpenSSH documentation (http://www.openssh.com/) is long and
detailed, but after you have mastered basic SSH use, you'll nd it's very
useful and contains a trove of cool things you can do with OpenSSH.
5 Comments
Comments
G RU N CH
(/USERS/GRUNCH)
Permalink
| JU LY 5, 2016
(/comment/14610#comment-14610)
Thanks for this great

set of tips Carla! Here's a related one: some people need to log in
5 de 8
14-07-2016 15:48
to their remote systems as user 'root' (though I discourage it). In

this case, edit the le /etc/ssh/sshd_cong (or /etc/sshd_cong),
as in tip #4 and add (or uncomment) the line:
PermitRootLogin without-password
And restart the SSH daemon.
Then, in order to log in as root@your (mailto:root@your)-server
remote users will need to have a copy of their SSH public key in
the le ~root/.ssh/authorized_keys.
~David Klann
I A N _ M ART I N
(/USERS/IANMARTIN)
Permalink
| JU NE 30, 2016
I could be wrong,
but haven't you missed a rename?
$ ssh-copy-id -i id_rsa.pub user@remoteserver
(mailto:user@remoteserver)
will copy the id_rsa.pub le, which I believe is the default le
created by ssh-keygen; however in the paragraph before you've
changed the default lename:
ssh-keygen -t rsa -b 3072 -f id_mailserver
so one instruction or other needs to be amended.
C S CH RO D E R
(/USERS/CSCHRODER)
Permalink
| JU LY 12, 2016
Yes Ian, thanks! I
6 de 8
14-07-2016 15:48
shall pester my editor to x it.
E L D ER - G E E K
(/USERS/ELDER- GEEK)
Permalink
| JU NE 29, 2016
Typically I have
changed the port ssh is on and run fail2ban and disable password
logins.
Is there really any more security to be gained at this point by
disabling root logins?
KU S T O D I A N
(/USERS/KUSTODIAN)
Permalink
| JU NE 29, 2016
If you are suggesting

passwords, at least suggest a longer password than 12 and at
least mention to use a very long password. But if you want to
harden SSH auth, password login should be disabled. It's better
to teach your users to always be prepared to authenticate using
public keys, than to use passwords. Also, if they are going to use
a password from pwgen, that means they will need to keep it
somewhere, since they are not going to remember it, which
means they could instead keep their encrypted private key
somewhere avaliable at all times.
#5 is not really about hardening SSH, it's more a tip for the SSH
client.
7 de 8
14-07-2016 15:48
8 de 8
14-07-2016 15:48

5 SSH Hardening Tips

Diunggah oleh

Informasi Dokumen

Judul Asli

Hak Cipta

Format Tersedia

Bagikan dokumen Ini

Bagikan atau Tanam Dokumen

Opsi Berbagi

Apakah menurut Anda dokumen ini bermanfaat?

Apakah konten ini tidak pantas?

Hak Cipta:

Format Tersedia

5 SSH Hardening Tips

Diunggah oleh

Hak Cipta:

Format Tersedia

5 SSH Hardening Tips | Linux.com | The source ...

LOGIN / CREATE ACCOUN T

News for the Open Source Professional