Sécurisation-SSH.md 24 KB
Sécurisation SSH
Je vais baser cette partie sur plusieurs tutoriels auxquels vous voudrez bien vous référer pour avoir des explications plus poussées que celles que je vais donner.
Références
Vous pouvez trouver plein d'autres références en français ou anglais en utilisant votre moteur de recherche préféré.
Création d'une clef personnalisée
Nous allons créer une clef spécifique à notre mini serveur.
Auparavant, nous allons vérifier le hostname de notre machine. Si vous l'avez configuré avec raspi-config, il y a de grandes chances que le résultat ne soit pas bon.
Sous Debian, le hostname est composé de 2 parties situées dans 2 fichiers différents.
- /etc/hosts (contient le nom complet, FQDN)
- /etc/hostname (ne contient que le petit nom de la machine, sans le domaine)
Test du hostname (sur notre raspi)
pi@piras:~ $ hostname -f
piras.yojik.net
pi@piras:~ $ hostname
piras
pi@piras:~ $
Le fichier /etc/hostname ne doit contenir que le nom de la machine, pas le domaine : ici, piras, et c'est ce que renvoie la commande hostname.
pi@piras:~ $ cat /etc/hostname
piras
pi@piras:~ $
hostname -f renvoie le "fqdn", ou nom complet de la machine, ici, piras.yojik.net.
La référence complète du nom se trouve dans le fichier /etc/hosts.
pi@piras:~ $ cat /etc/hosts
127.0.0.1 localhost
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
127.0.1.1 piras.yojik.net piras
pi@piras:~ $
Pour l'instant, c'est l'adresse 127.0.1.1 qui est utilisée comme référence du nom, mais nous changerons ça dès que nous aurons configuré une adresse IPV4 et IPV6 fixe.
Création de notre clef personnalisée (sur le desktop, pas sur le raspi!)
Nous utiliserons la commande :
sh-keygen -o -a 100 -t ed25519 -f ~/.ssh/piras_ed25519 -C "clef SSH de l'utilisateur pi du Raspi"
- -o : Sauvegarde votre clé dans le nouveau format openssh au lieu de l’ancien format PEM
- -C : insertion d'un commentaire (ce que vous voulez, votre adresse émail ...).
- -f : nom du fichier à produire
-a : le nombre de tours de la clef de dérivation (plus il est élevé, plus il est difficile de la craquer en force brute, mais aussi plus c'est lent)
eric@aldebaran:~$ ssh-keygen -o -a 100 -t ed25519 -f ~/.ssh/piras_ed25519 -C "eric@yojik.eu" Generating public/private ed25519 key pair. Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in /home/eric/.ssh/piras_ed25519 Your public key has been saved in /home/eric/.ssh/piras_ed25519.pub The key fingerprint is: SHA256:yyDsyczL9W1QTTn9d5o0hwZ5A0bdMnCJgK9cniCeR0c eric@yojik.eu The key's randomart image is: +--[ED25519 256]--+ | ..o=O.o | | . E.B.O .| | o o + * | | . . o = . = =| | o..=SB . o =o| | = ooo=.o o | | * ..o. | | . o . .. | | o ... | +----[SHA256]-----+
Si vous allez dans ./.ssh, vous trouverez ceci :
eric@aldebaran:~/.ssh$ ls -l
total 44
-rw------- 1 eric eric 751 7 avril 2011 id_dsa
-rw-r--r-- 1 eric eric 604 7 avril 2011 id_dsa.pub
-rw------- 1 eric eric 1766 1 avril 2013 id_rsa
-rw-r--r-- 1 eric eric 396 1 avril 2013 id_rsa.pub
-rw-r--r-- 1 eric eric 3728 29 nov. 12:20 known_hosts
-rw------- 1 eric eric 444 11 déc. 18:17 piras_ed25519
-rw-r--r-- 1 eric eric 95 11 déc. 18:17 piras_ed25519.pub
eric@aldebaran:~/.ssh$
Nous voyons les clefs privées et publiques que nous avons créées. (ainsi que d'anciennes clefs ...) Vérifiez les permissions, mais normalement les commandes ci-dessus les attribuent comme attendu (voir plus bas).
Copie de la clef sur le serveur
Nous utiliserons la commande : ssh-copy-id
eric@aldebaran:~$ ssh-copy-id -i ~/.ssh/piras_ed25519.pub pi@192.168.111.32
/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/eric/.ssh/piras_ed25519.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
pi@192.168.111.32's password:
Number of key(s) added: 1
Now try logging into the machine, with: "ssh 'pi@192.168.111.32'"
and check to make sure that only the key(s) you wanted were added.
eric@aldebaran:~$
Vérifions la présence de notre clef sur notre raspi, dans le fichier authorized_keys :
pi@piras:~/.ssh $ cat authorized_keys
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIAdDDO3ni4DHIxqfRaNZ4SBudrSlRoQjLm/fd2SSjxtM eric@yojik.eu
pi@piras:~/.ssh $
C'est bon, elle est là !
Essai de connexion avec notre nouvelle clef
eric@aldebaran:~$ ssh -i ~/.ssh/piras_ed25519 'pi@192.168.111.32'
Linux piras 5.4.51+ #1333 Mon Aug 10 16:38:02 BST 2020 armv6l
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Dec 11 18:46:55 2020 from 192.168.111.150
pi@piras:~ $
ça marche ... j'ai précisé la clef SSH à utiliser avec l'option -i nom_de_la_clef.
Configuration de ssh sur la machine de travail
Je possède plusieurs clefs qui sont spécifiques à certains serveurs (ceux dans ma cave, et ceux sur internet). Nous allons rajouter une configuration pour permettre la sélection automatique de la bonne clef pour chaque serveur.
Cela se fait dans le fichier ~/.ssh/config
Le schéma à utiliser est le suivant :
eric@aldebaran:~$ cat ./.ssh/config
Host piras piras.yojik.net
HostName 192.168.111.32
IdentityFile ~/.ssh/piras_ed25519
User pi
Host adara adara.yojik.eu
HostName adara.yojik.eu
IdentityFile ~/.ssh/id_rsa
User ericadmin
eric@aldebaran:~$
Cela me permet de me connecter avec la commande :
ssh piras
Voilà à quoi ressemble mon répertoire ~/.ssh :
eric@aldebaran:~$ tree .ssh
.ssh
├── adara
│ ├── adara_ed25519
│ └── adara_ed25519.pub
├── aijan
│ ├── aijan_ed25519
│ └── aijan_ed25519.pub
├── alya
│ ├── alya_ed25519
│ └── alya_ed25519.pub
├── atom
│ ├── atom_ed25519
│ └── atom_ed25519.pub
├── config
├── id_dsa
├── id_dsa.pub
├── id_ed25519
├── id_ed25519.pub
├── id_rsa
├── id_rsa.pub
├── known_hosts
├── mynas2
│ ├── mynas2_ed25519
│ └── mynas2_ed25519.pub
├── mynas3
│ ├── mynas3_ed25519
│ └── mynas3_ed25519.pub
├── ns1
│ ├── ns1_ed25519
│ └── ns1_ed25519.pub
├── ns2
│ ├── ns2_ed25519
│ └── ns2_ed25519.pub
├── piras
│ ├── piras_ed25519
│ └── piras_ed25519.pub
└── polis
├── polis_ed25519
└── polis_ed25519.pub
J'ai mis l'adresse IP ; j'aurai pu mettre le nom FQDN du serveur, mais je le ferai une fois les adresses IP fixées.
Modifions les permissions pour qu'elles soient conformes à ce que demande SSH. (en fait, les bonnes permissions étaient déjà appliquées par la commande ssh-keygen). Si vous organisez votre structure de répertoires comme ci-dessus, ajustez les permissions comme ceci :
Si vous créez un répertoire nommé ~/.ssh/piras ajustez les droits du répertoire comme suit :
chmod 700 ~/.ssh/piras
Et pour les clefs privées/publiques :
chmod 600 ~/.ssh/config
chmod 600 ~/.ssh/piras/piras_ed25519
chmod 600 ~/.ssh/piras/piras_ed25519.pub
Test de connexion
eric@aldebaran:~$ ssh piras
Linux piras 5.4.51+ #1333 Mon Aug 10 16:38:02 BST 2020 armv6l
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Dec 11 18:49:37 2020 from 192.168.111.150
pi@piras:~ $
Ça marche ;)
Amélioration
Nous allons modifier temporairement (et le re-modifierons une fois les adresses fixées) notre fichier /etc/hosts sur notre machine de travail pour pouvoir utiliser la méthode par nom plutôt que par adresse IP. Ajoutons la référence à notre raspi :
eric@aldebaran:~$ cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 aldebaran.yojik.net aldebaran
192.168.111.32 piras.yojik.net piras
# The following lines are desirable for IPv6 capable hosts
::1 localhost ip6-localhost ip6-loopback
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters
eric@aldebaran:~$
Modification de ./.ssh/config :
eric@aldebaran:~$ cat ./.ssh/config
Host piras piras.yojik.net
HostName piras.yojik.net
IdentityFile ~/.ssh/piras_ed25519
User pi
Host adara adara.yojik.eu
HostName adara.yojik.eu
IdentityFile ~/.ssh/id_rsa
User ericadmin
eric@aldebaran:~$
Test :
eric@aldebaran:~$ ssh piras
The authenticity of host 'piras.yojik.net (192.168.111.32)' can't be established.
ECDSA key fingerprint is SHA256:DjB1teyxsYAZzGBV8BIXiG5+UAb3JU5SHp7vu/xArG8.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'piras.yojik.net' (ECDSA) to the list of known hosts.
Linux piras 5.4.51+ #1333 Mon Aug 10 16:38:02 BST 2020 armv6l
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Fri Dec 11 19:17:50 2020 from 192.168.111.150
pi@piras:~ $
L'adresse de notre raspi a été ajoutée au fichier ./.ssh/known_hosts
Modification du fichier /etc/ssh/sshd_config
Nous allons modifier ce fichier pour plus de sécurité :
- pas de connexion de l'utilisateur root
- connexion uniquement par clef (pas par login/mot de passe)
- suppression du support des protocoles non sûrs
- autorisation de connexion sur liste blanche
- connexion en IPV4 et IPV6
Tout d'abord, sauvegarde du répertoire /etc/ssh :
pi@raspberrypi:/etc $ sudo cp -R ssh ssh.orig
pi@raspberrypi:/etc $
Ensuite, création du nouveau fichier (après installation de vim, mais vous pouvez prendre l'éditeur de votre choix, nano par exemple qui est installé par défaut):
Pour installer vim, tapez : sudo apt install vim
Voilà une copie du fichier de conf du site troxyworld dont j'ai déjà donné les références :
# Interface & Port
Port 61022
AddressFamily any
ListenAddress 0.0.0.0
ListenAddress ::
HostKey /etc/ssh/ssh_host_ed25519_key
Protocol 2
SyslogFacility AUTHPRIV
LogLevel VERBOSE
# Authentication restriction
LoginGraceTime 30s
PermitRootLogin no
StrictModes yes
MaxAuthTries 3
MaxSessions 5
PubkeyAuthentication yes
AllowUsers hmichael
AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2
HostbasedAuthentication no
IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
PermitEmptyPasswords no
PasswordAuthentication no
# Change to no to disable s/key passwords
ChallengeResponseAuthentication no
UsePAM yes
AllowAgentForwarding no
AllowTcpForwarding no
GatewayPorts no
X11Forwarding no
PermitTTY yes
PermitUserEnvironment no
PrintMotd no
PrintLastLog no
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#ShowPatchLevel no
UseDNS yes
PidFile /var/run/sshd.pid
MaxStartups 10:30:100
PermitTunnel no
#ChrootDirectory none
VersionAddendum none
# no default banner path
Banner none
# Accept locale-related environment variables
AcceptEnv LANG LC_*
# override default of no subsystems
Subsystem sftp /usr/libexec/openssh/sftp-server
Et voici une version par Synthic:
# Utilisation de la version 2 du protocole SSH
Protocol 2
# Utilisation du port 22. Il est possible de le modifier
Port 22
# Interdit à root de s'identifier
PermitRootLogin no
PermitEmptyPasswords no
# On indique ici la liste des utilisateurs ayant la permission d'utiliser SSH
AllowUsers utilisateur
# Nombre d'essais avant fermeture de la connexion
MaxAuthTries 3
UsePAM no
# Authentification par clés
PubkeyAuthentication yes
# Lieux où sont stockées les clés publiques --> /home/user/.ssh/authorized_keys
AuthorizedKeysFile .ssh/authorized_keys
ChallengeResponseAuthentication yes
# Désactivation de l'authentification par mot de passe
PasswordAuthentication no
IgnoreRhosts yes
HostbasedAuthentication no
AcceptEnv LANG LC_*
Subsystem sftp /usr/lib/openssh/sftp-server
PrintMotd no
Ciphers aes256-ctr,aes192-ctr,aes128-ctr
X11Forwarding no
Voilà mon fichier de configuration, à adapter suivant vos préférences (surtout n'oubliez pas d'ajuster le user dans l'option AllowUsers à votre cas particulier)
Pour ma part, je vais garder le port 22 ; je le changerai peut-être plus tard.
Protocol 2
Port 22
Blocage de root
PermitRootLogin no
Pas de mot de passe vide
PermitEmptyPasswords no
Seul l'utilisateur pi est autorisé
AllowUsers pi
Connexion uniquement pas clef
PubkeyAuthentication yes
Modification et limite des tentatives de connexion
LoginGraceTime 30s
PermitRootLogin no
StrictModes yes
MaxAuthTries 3
MaxSessions 5
Les fichiers de clef autorisés
AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2
Voici la copie du fichier complet :
pi@raspberrypi:~ $ cat /etc/ssh/sshd_config
# $OpenBSD: sshd_config,v 1.103 2018/04/09 20:41:22 tj Exp $
# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.
# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin
# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options override the
# default value.
Port 22
#AddressFamily any
# A décommenter après test sur sur site d'audit, car nos réglages ne permettent
# que de se connecter à partir de notre réseau local
# Si vous voulez que votre serveur soit accessible à partir de l'extérieur
# gardez les valeurs par défaut (ou les options commentées)
#ListenAddress 0.0.0.0
#ListenAddress ::
# Nouveaux réglages
# ListenAddress 192.168.111.0
# ListenAddress 2a01:e0a:d0:3c20::0
# On ne permet que la connexion avec une clef forte
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
HostKey /etc/ssh/ssh_host_ed25519_key
# Ciphers and keying
#RekeyLimit default none
# Logging
# Modification du niveau de logging pour plus de détails
#SyslogFacility AUTH
SysLogFacility AUTHPRIV
#LogLevel INFO
LogLevel VERBOSE
# Authentication:
# C'est ici que l'on va ne permettre que l'accès par clef partagée
# et interdire l'accès par mot de passe
# De plus on configure le nombre d'essais et le délai de connexion
# à des valeurs plus courtes
LoginGraceTime 30s
PermitRootLogin no
StrictModes yes
MaxAuthTries 3
MaxSessions 5
PubkeyAuthentication yes
# Ajout d'une liste blanche d'utilisateurs autorisés à se connecter
# ici, seulement l'utilisateur pi
AllowUsers pi
# Expect .ssh/authorized_keys2 to be disregarded by default in future.
AuthorizedKeysFile .ssh/authorized_keys .ssh/authorized_keys2
#AuthorizedPrincipalsFile none
#AuthorizedKeysCommand none
#AuthorizedKeysCommandUser nobody
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
# Interdiction de connexion pas login/mot de passe
PasswordAuthentication no
# Interdiction de mot de passe vides
PermitEmptyPasswords no
# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
#GSSAPIStrictAcceptorCheck yes
#GSSAPIKeyExchange no
# 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
# On va interdire le forwarding
AllowAgentForwarding no
AllowTcpForwarding no
GatewayPorts no
X11Forwarding no
#X11DisplayOffset 10
#X11UseLocalhost yes
#PermitTTY yes
# Pas de message d'acceuil de SSHD
PrintMotd no
#PrintLastLog yes
#TCPKeepAlive yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
# Utilisation du DNS
UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10:30:100
#PermitTunnel no
#ChrootDirectory none
#VersionAddendum none
# no default banner path
Banner none
# Allow client to pass locale environment variables
AcceptEnv LANG LC_*
# override default of no subsystems
Subsystem sftp /usr/lib/openssh/sftp-server
# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# PermitTTY no
# ForceCommand cvs server
pi@raspberrypi:~ $
On redémarre sshd
sudo systemctl restart sshd.service
On teste si le service a bien redémarré sans erreurs :
pi@raspberrypi:~ $ sudo systemctl status sshd.service
● ssh.service - OpenBSD Secure Shell server
Loaded: loaded (/lib/systemd/system/ssh.service; enabled; vendor preset: enabled)
Active: active (running) since Sun 2021-02-14 14:59:47 CET; 7s ago
Docs: man:sshd(8)
man:sshd_config(5)
Process: 523 ExecStartPre=/usr/sbin/sshd -t (code=exited, status=0/SUCCESS)
Main PID: 524 (sshd)
Tasks: 1 (limit: 269)
CGroup: /system.slice/ssh.service
└─524 /usr/sbin/sshd -D
févr. 14 14:59:46 raspberrypi systemd[1]: Starting OpenBSD Secure Shell server...
févr. 14 14:59:46 raspberrypi sshd[524]: Server listening on 0.0.0.0 port 22.
févr. 14 14:59:47 raspberrypi sshd[524]: Server listening on :: port 22.
févr. 14 14:59:47 raspberrypi systemd[1]: Started OpenBSD Secure Shell server.
pi@raspberrypi:~ $
C'est bon.
Essai de connexion :
eric@aldebaran:~$ ssh piras
The authenticity of host 'piras.yojik.net (192.168.111.170)' can't be established.
ED25519 key fingerprint is SHA256:NW70QB3uNQ1cnrTQyfXG1Lu1iTDubEv6Oak4PK+DR1k.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added 'piras.yojik.net,192.168.111.170' (ED25519) to the list of known hosts.
Enter passphrase for key '/home/eric/.ssh/piras/piras_ed25519':
Linux raspberrypi 5.10.11+ #1399 Thu Jan 28 12:02:28 GMT 2021 armv6l
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sun Feb 14 15:02:55 2021 from 192.168.111.150
pi@raspberrypi:~ $
C'est bon.
Test sur le site d'audit :
Bien, après avoir effacé toutes les données personnelles de mon navigateur (données qui entraînent une erreur «The csrf token is invalid »), le test revient toujours avec une mauvaise note. D'où la suite. Les instructions pour améliorer sont également sur le site SSH-Audit.com recommendations
On va sécuriser les échanges en jouant sur 3 options supplémentaires :
- Ciphers : Le chiffrement utilisé.
- KexAlgorithms : Les algorithmes utilisés pour l’échange de clés.
- MACs : Message Authentication code, c’est le code qui accompagnent les données échangées dans le but d’assurer leur intégrité pour être certain qu’elles n’ont subies aucune altération pendant/après la transmission.
Voilà les étapes à suivre (reprises quasi texto des sites déjà cités) :
Régénération de la clé ED25519 du serveur :
sudo rm -f /etc/ssh/ssh_host_* sudo ssh-keygen -t ed25519 -f /etc/ssh/ssh_host_ed25519_key -N ""Retrait des moduli Diffie-Hellman faible :
sudo awk '$5 >= 3071' /etc/ssh/moduli > /home/pi/moduli.safe sudo mv -f /home/pi/moduli.safe /etc/ssh/moduliDésactivation des clés DSA/ECDSA & RSA si ce n’est pas déjà fait :
sudo sed -i 's/^HostKey \/etc\/ssh\/ssh_host_\(dsa\|ecdsa\|rsa\)_key$/\#HostKey \/etc\/ssh\/ssh_host_\1_key/g' /etc/ssh/sshd_configRestriction des ciphers, clés d’échange et des codes d’authentification :
Ajoutez ceci à la fin du fichier /etc/sshd_config:
KexAlgorithms curve25519-sha256@libssh.org,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512 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.comRedémarrage de sshd
sudo systemctl restart sshd.service
Test sur le site ssh audit
Tout est OK ... nous sommes passés d'une note F à A+.
