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