Installation pour Debian 9

Si le serveur SSH n’est pas déjà installé, voici comment procéder.

#Installation du serveur SSH
sudo apt-get install openssh-server

Configuration

Création d’un groupe

Afin de gérer au mieux les utilisateurs qui peuvent se connecter en ssh, nous allons restreindre la connection aux utilisateurs d’un groupe.

#Création du groupe pour les utilisateurs de ssh
sudo addgroup ssh_users

Ajout d’un utilisateur au groupe

#Ajout au groupe ssh_users
sudo adduser nomUtilisateur ssh_users

Dans une note technique l’ANSSI recommande toute une série de modifications afin de désactiver des options non fiables et renforcer la sécurité du service.
Il est recommandé entre autres de :

• changer de port,
• de limiter la durée d’authentification,
• de limiter le nombre d’échec d’authentification,
• de n’utiliser que l’authentification par certificats

Ce que nous souhaitons in fine :

• interdire tous les moyens d’authentification sauf via certificats,
• changer de port d’écoute afin d’éviter une partie des attaques,
• identifier avec certitude le serveur lors de la connexion, donc éviter la faille « man in the middle »

Options : on peut aussi n’écouter que sur une IP particulière, qui ne servirait qu’à l’administration par exemple.

Recommandations

L’ANSSI déconseille fortement de générer des certificats sur un serveur fraîchement installé ou pire sur une machine virtuelle, car il n’y a pas suffisamment d’entropie. cf p8/21 Anssi – Note technique Recommandations pour un usage sécurisé d’OpenSSH

Quelques règles permettent de s’assurer que le réservoir d’entropie est correctement rempli :

• la machine de génération de clés doit être une machine physique ;
• elle doit disposer de plusieurs sources d’entropie indépendantes ;
• l’aléa ne doit être obtenu qu’après une période d’activité suffisamment importante (plusieurs minutes voire heures).

Il parait donc nécessaire de générer les clefs et certificats sur son poste de travail, qui a de nombreuses applications en service, générant de l’entropie.

Génération des clefs

Dans un premier temps, nous allons devoir générer les jeux de clefs.

Nous le ferrons depuis le client, via la commande :

$ ssh-keygen

Par défaut il s’agit de RSA en 2048 bits.
Elles seront stockées sous ~/.ssh/

La clef privée sera nommée : id_rsa
La clef publique sera nommée : id_rsa.pub

Pour une utilisation du certificat sans passphrase, il ne faut pas en saisir lors de la génération des clefs.
Ceci n’est pas recommandé !

Maintenant que nous avons les clefs, il faut communiquer la clef publique au serveur, via une commande dédiée :

$ ssh-copy-id -i ~/.ssh/id_rsa.pub <username>@<serveur>

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/username/.ssh/id_rsa.pub"
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
username@serveur's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'username@serveur'"
and check to make sure that only the key(s) you wanted were added.

Il faudra saisir le mot de passe pour établir une connexion ssh pour la copie de la clef.
La commande permet d’ajouter la clef publique dans le bon repertoire : ~/.ssh
dans le fichier : authorized_keys
ainsi que les droits d’accès en 600.

Normalement dans la configuration de base sur serveur ssh, l’utilisation des clefs est permise :

PubkeyAuthentication yes

On peut donc tester que cela fonctionne bien avant de modifier la configuration du serveur.
Pour ce faire on peut relancer une nouvelle connexion ssh.

#En mode verbeux
$ ssh -v username@serveur
OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g  1 Mar 2016
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to serveur [xx.xx.xx.xx] port 22.
debug1: Connection established.
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.2p2 Ubuntu-4ubuntu2.1
debug1: match: OpenSSH_7.2p2 Ubuntu-4ubuntu2.1 pat OpenSSH* compat 0x04000000
#Authentification de l'utilisateur sur le serveur au port 22
debug1: Authenticating to serveur:22 as 'username'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256@libssh.org
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20-poly1305@openssh.com MAC:  compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC:  compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
#Le serveur est connu par le poste local, sa signature est dans mon fichier d'host key en ligne 17
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:XXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
debug1: Host 'serveur' is known and matches the ECDSA host key.
debug1: Found key in /home/username/.ssh/known_hosts:17
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS received
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
#Authentification possible avec le certificat
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
#Utilisation de la clef privée contenue en local
debug1: Offering RSA public key: /home/username/.ssh/id_rsa
debug1: Server accepts key: pkalg rsa-sha2-512 blen 279
#Authentification réussie via le certificat
debug1: Authentication succeeded (publickey).
#Authentification sur le serveur avec son adresse IP et son port
Authenticated to serveur ([xx.xx.xx.xx]:22).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-sessions@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostkeys-00@openssh.com want_reply 0
debug1: Sending environment.

Si vous obtenez bien un succès d’authentification via certificat, nous pouvons poursuivre avec la configuration du serveur.
Une fois le fichier de conf ci-dessous activé, il ne sera plus possible de se connecter en SSH avec login/passwd !

Réalisation d’une copie du fichier de conf de base

sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.default

Contenu du fichier de conf /etc/ssh/sshd_config modifié

# See the sshd_config(5) manpage for details

# What ports, IPs and protocols we listen for
Port 30
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
# Communique l'empreinte du serveur lors de la connexion ssh
HostKey /etc/ssh/ssh_host_ed25519_key
HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key

HostKeyAlgorithms ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-rsa,ssh-dss,ssh-ed25519

#Change Default Ciphers and Algorithms
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group16-sha512

#Choix des algorithmes symétriques
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

#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 3600
#ServerKeyBits 1024

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
#Temps pour s'authentifier en secondes
LoginGraceTime 5
#Nombre d'essais pour s'authentifier
MaxAuthTries 2
#Nombre de connexions ssh simultannées non authentifiées
MaxStartups 2
#Interdire le logging de root
PermitRootLogin no
#Vérification strict des droits sur les certificats
StrictModes yes

#Interdire l'authentification RSA
RSAAuthentication no
#Activation de l'authetification via clefs
PubkeyAuthentication yes
AuthorizedKeysFile     %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
PasswordAuthentication no

# Kerberos options
KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

#Désactivation de X11Forwarding
X11Forwarding no
#X11DisplayOffset 10
#PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

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

# Set this to 'yes' to enable PAM authentication, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication.  Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM yes

#Restriction des utilisateurs via un groupe ssh_users
AllowGroups ssh_users

La configuration ayant été modifiée, il faut relancer le service ssh afin d’appliquer les modifications pour les nouvelles connexions.
Afin d’anticiper toute problématique, il me semble intéressant (mais pas suffisant) de garder notre session ssh ouverte dans notre terminal et d’en ouvrir un autre pour tester la connexion. En effet, le redémarrage du service n’impactera pas notre connexion en cours qui est un processus système différent.

Donc dans notre premier terminal

#Redémarrage du service ssh
sudo service ssh restart

Dans un nouveau terminal

#Instanciation d'une connexion SSH en verbeux pour vérifier ce qu'il se passe.
ssh -v username@serveur

Si la connexion est établie, alors c’est parfait, et c’est en fini pour ce service.

Log

#Visualiser le fichier de log des authentifications
sudo more /var/log/auth.log
#Visualiser seulement ce qui concerne sshd
sudo more /var/log/auth.log | grep sshd
#Visualiser seulement ce qui concerne sshd et les Failed
sudo more /var/log/auth.log | grep sshd | grep Failed

Outils d’audit

Un site web qui effectue des vérifications du serveur sshd Rebex SSH Check
Un script python qui effectue des vérifications ssh-audit

Allez plus loin

Nous avons sécurisé l’utilisation de ssh, comme n’est permise que l’authentification par certificat, les attaques par force brute seront inopérantes.
Dans le cas où nous aurions permis l’usage du login/passwd, il faudrait s’en prémunir. Pour ce faire il existe un service très pratique et assez simple à configurer : Fail2Ban qui va éditer des règles de filtrage, permettant de protéger quantité de protocoles, nous procéderons à son installation.
Installation et configuration de Fail2ban

Sources :
Anssi – Note technique Recommandations pour un usage sécurisé d’OpenSSH
securiteinfo.com – Renforcer le cryptage de SSH
Korben – Sécuriser un serveur SSH
Medium – Hardening SSH by Jason Rigden