HorlogeSkynet
/
blog
1
0
Fork 0
Code Issues Pull Requests Releases Activity
blog/_posts/2017-11-20-hardening-openss...

4.7 KiB
Raw Permalink Blame History

title date url layout category image description
Hardening OpenSSH, all in one place 2017-11-20 hardening-openssh-all-in-one-place post Security /img/blog/hardening-openssh-all-in-one-place.png An unified guide to secure OpenSSH server

A missing blog post image

After having hardened Apache during the [previous post over here]({% post_url 2017-11-14-hardening-apache-all-in-one-place %}), we'll take a look at OpenSSH.

Why ? 🤔

'Cause if you secure your web server, it's good to enforce some "good" rules on your SSH server too, unless securing your web server would be pointless 😀

Content

In order to set up a "hardened" OpenSSH, just edit your /etc/ssh/sshd_config, after having backup'ed your current configuration (cp /etc/ssh/sshd_config /etc/ssh/sshd_config.backup), and paste the following (please, do adapt it to what you actually need / want) :

{% highlight config %}

You should set another port here

Port 22 Protocol 2

HostKey /etc/ssh/ssh_host_ed25519_key

UsePrivilegeSeparation yes

If you run a Debian distribution...

DebianBanner no

SyslogFacility AUTH LogLevel INFO

LoginGraceTime 120 PermitRootLogin no StrictModes yes MaxAuthTries 3

RSAAuthentication no PubkeyAuthentication yes

Should be set to no

PasswordAuthentication yes

IgnoreRhosts yes HostbasedAuthentication no

PermitEmptyPasswords no ChallengeResponseAuthentication no

X11Forwarding no AllowTcpForwarding no

PrintMotd no PrintLastLog yes TCPKeepAlive yes

PermitUserEnvironment no AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

UseDNS yes UsePAM yes

If you want to limit the connection to specific users (or groups) from specific networks...

AllowUsers root@192.168.0/24 AllowGroups ssh@192.168.0/24

KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group-exchange-sha256 Ciphers chacha20-poly1305@openssh.com,aes256-gcm@openssh.com,aes128-gcm@openssh.com,aes256-ctr,aes192-ctr,aes128-ctr MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512,hmac-sha2-256,umac-128@openssh.com {% endhighlight %}

Once you have adapted and paste the content above, you'll have to get rid of the moduli the less secure.
In order to achieve this, please copy / paste the BASH snippet below (taken and one-line'd from here) :

{% highlight bash %} cd /etc/ssh/ if -e ./moduli ; then cp moduli moduli.backup && awk '$5 > 2000' moduli > moduli.tmp; if $(wc -l moduli.tmp ; then mv moduli.tmp moduli; else echo "No secure Moduli available..."; fi; else ssh-keygen -G moduli.all -b 4096 && ssh-keygen -T moduli.safe -f moduli.all && mv moduli.safe moduli && rm moduli.all; fi {% endhighlight %}

Let's do the same with your keys (⚠️ DANGEROUS OPERATION ⚠️) :

{% highlight bash %} rm ssh_host_key ssh-keygen -t ed25519 -f ssh_host_ed25519_key -N "" < /dev/null {% endhighlight %}

Now, you have to manually add the sessions that will have the right to connect through SSH :

(# addgroup ssh)
# usermod -G ssh <yourSession>

Only if you went through all the previous actions correctly, you can check your OpenSSH configuration with :

# sshd -t

If it's okay too, you may now reload the SSH daemon :

(# service ssh reload)
# systemctl reload ssh

Now DON'T CLOSE YOUR CURRENT REMOTE SESSION, and try to open a new one 😉

Also, if everything is still okay, you can delete the old backups !

# rm {sshd_config,moduli}.backup

EDIT 2017-11-26 : I've done the same thing for my OpenSSH Client, you should take a look at it over here ! 👌

Sources