Cette fiche opérationnelle décrit le paramétrage des serveurs (connexions rentrantes) et des clients (connexions sortantes) SSH selon la « politique de la maison ».
Nous supposons que les paquets logiciels ssh* sont déjà installés de façon standard, comme sur toute distribution Linux.
Il s'agit essentiellement de modifier les fichiers qui se trouvent sous /etc/ssh/, soit sshd_config pour la partie serveur et ssh_config pour la partie cliente.
Voici les points caractéristiques de la politique maison
SSH, donc pas de mot de passe à cette étape. Il peut être nécessaire de centraliser les fichiers de clefs des utilisateurs par AuthorizedKeysFile=/chemin/central/%u plutôt que des les laisser dans leurs répertoires personnels avec le risque de modifications involontaires —ou non— ; l'administrateur peut ainsi gérer globalement les connections distantes ;
sudo. Ainsi, le ou les administrateurs devront ensuite fournir un mot de passe pour passer sudo ;
RSA,
ecdsa de 521 bits et ed25519 pour les clients,
ed25519 pour le serveur. Note : le fichier /etc/ssh/moduli qui comporte un risque de modules trop faibles ne sera donc plus utilisé ;
DNS via l'enregistrement SSHFP que les clients devraient contrôler ;
ssh qui ne doit écouter aucune autre adresse. l'IPv4 est alors généralement aussi exclue ;
AllowUsers et ses variantes. Sur un serveur les rôles sont peu nombreux, cette gestion n'est donc guère gênante ni pesante, même pour le cas notable du serveur web multi sites avec des login multiples.
En conséquence de ces choix, il est possible que les clients sortants ne puissent pas se connecter à d'autres serveurs plus anciens (Protocol 1 ou clef laxistes en Protocol 2), ce qui semble d'ailleurs souhaitable. Symétriquement, les clients entrants avec des clefs de type refusé devront en générer une nouvelle par ssh-keygen -t ed25519 -a 100 et/ou ssh-keygen -t ecdsa -b 521 -a 100
Sur le serveur, à partir d'une connexion déjà ouverte en mode super-utilisateur root
F=/etc/ssh/ssh_config
cat >> $F <<EOD..........
VerifyHostKeyDNS yes
Ciphers chacha20-poly1305@openssh.com
MACs hmac-sha2-512-etm@openssh.com
KexAlgorithms curve25519-sha256@libssh.org
EOD..........
la première ligne demande une vérification par les enregistrements SSHFP du DNS de la clef du serveur appelé ; celle-ci reste informative et non bloquante.
ed25519 que l'on régénère.
cd /etc/ssh rm ssh_host_dsa_key* ssh_host_ecdsa_key* ssh_host_rsa_key* echo y | ssh-keygen -f /etc/ssh/ssh_host_ed25519_key -N '' -t ed25519
SSHFP à remonter dans le DNS comme support de la directive VerifyHostKeyDNS éventuellement présente dans la configuration client ssh_config d'autres serveur.
ssh-keygen -r info.scalaire.frIl convient de dupliquer cette entrée en l'ajustant pour chacun des noms de domaines associés à ce serveur. L'absence ou la non concordance deinfo.scalaire.fr IN SSHFP 4 1 9673dc1413284483ca273e1c9ffbff8dcd67a8a9 info.scalaire.fr IN SSHFP 4 2 6a9bcbfa2b4ebb18ccf842b454e1524216fb5f4eabd2eb8e5b2da648ee0664ce
SSHFP conduit à un message d'avertissement au client précautionneux mais n'est pas bloquante.
ssh entrants des clefs uniquement ed25519 ou ecdsa 512 bits,
AllowUsers. Voir aussi AllowGroups, DenyUsers et DenyGroups,
2a01:e0b:182:e032:21c4:407d:2f15:40e3 et locale (« Link » non routable) fe80::82ee:73ff:fee3:b4b5%enp1s0 — on notera la syntaxe finale %interface ainsi que le fe80 caractéristique au début,
192.168.169.007,
ip a
(...)
2: enp1s: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
link/ether 5c:e0:c5:d4:6f:f7 brd ff:ff:ff:ff:ff:ff
inet 192.168.169.7/24 brd 192.168.169.255 scope global dynamic noprefixroute enp1s
valid_lft 28813sec preferred_lft 28813sec
inet6 2a01:e0b:182:e032:21c4:407d:2f15:40e3/64 scope global dynamic mngtmpaddr noprefixroute
valid_lft 86288sec preferred_lft 86288sec
inet6 fe80::82ee:73ff:fee3:b4b5/64 scope link noprefixroute
valid_lft forever preferred_lft forever
le nom d'interface, ici enp1s, varie. On trouve eth0 si PIN (predictable interface name) n'est pas en service,
F="/etc/ssh/sshd_config"
sed -i -e "/^\s*UsePAM/s/^/#/" "$F"
cat >> "$F" <<EOD..........
StrictModes yes
HostKey /etc/ssh/ssh_host_ed25519_key
# ListenAddress 192.168.169.007
# ListenAddress [2a01:e0b:182:e032:21c4:407d:2f15:40e3]
# ListenAddress [fe80::82ee:73ff:fee3:b4b5%enp1s0]
UsePAM no
PasswordAuthentication no
PubkeyAcceptedKeyTypes ssh-ed25519,ecdsa-sha2-nistp521
# AuthorizedKeysFile /etc/ssh/keys/authorized_key/%u
# AuthenticationMethods publickey,password # both required first key then passwd
# AuthenticationMethods publickey,publickey # two different keys required
Ciphers chacha20-poly1305@openssh.com
MACs hmac-sha2-512-etm@openssh.com
KexAlgorithms curve25519-sha256@libssh.org,ecdh-sha2-nistp521
MaxAuthTries 60
AllowUsers sysman dewplik foocked
EOD..........
(Décommenter et adapter les lignes en # à convenance)
systemctl restart ssh journalctl -xeu ssh ss -tapine |grep -F sshDepuis une machine distante
ssh foocked@info.scalaire.frla première connexion signalera un risque tout à fait normal vu la nouvelle clef du serveur, les messages varieront selon que ce serveur aura déjà été visité et que l'information
SSHFP sera accessible et à jour ou non
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the ED25519 key sent by the remote host is SHA256:JoUJ7+I+hfcLEictCbMQWg2SSBdQhn709UzoCcN0Dqk. Please contact your system administrator. Update the SSHFP RR in DNS with the new host key to get rid of this message. The authenticity of host 'info.scalaire.com (2a01:e0b:182:e032:21c4:407d:2f15:40e3)' can't be established. ED25519 key fingerprint is SHA256:JoUJ7+I+hfcLEictCbMQWg2SSBdQhn709UzoCcN0Dqk. No matching host key fingerprint found in DNS. Are you sure you want to continue connecting (yes/no)?Ici l'avant-dernière ligne indique que l'empreinte SSHFP ne correspond plus du fait de la regénération.
... Add correct host key in /home/xxx/.ssh/known_hosts to get rid of this message. Offending ED25519 key in /home/xxx/.ssh/known_hosts:3 remove with: ssh-keygen -f "/home/xxx/.ssh/known_hosts" -R "info.scalaire.fr" ED25519 host key for info.scalaire.fr has changed and you have requested strict checking. Host key verification failed.Ici la fin du message lorsqu'une visite avait eu lieu. Exécuter la commande proposée
ssh-keygen -f "/home/xxx/.ssh/known_hosts" -R "info.scalaire.fr"Autre cas
... Offending key for IP in /home/xxx/.ssh/known_hosts:3 Matching host key in /home/xxx/.ssh/known_hosts:6 Are you sure you want to continue connecting (yes/no)? no Host key verification failed.Corriger en adaptant le numéro de ligne indiqué, ici 3
sed -i -e 3d /home/xxx/.ssh/known_hosts
... Please contact your system administrator. Update the SSHFP RR in DNS with the new host key to get rid of this message.Une connexion réussie, mais avec systématiquement cette partie de message, correspond à la vérification
SSHFP par le client qui ne correspond pas. Vérifier que le DNS a bien été mis à jour — attention au délai de propagation !
Lorsque la nouvelle clef serveur et l'enregistrement SSHFP sont en phase, la partie du message est
... ED25519 key fingerprint is SHA256:IR9BOEmDpAoNEKNaK19aaPZpm1MRn04BbxvJp9dUGmo. Matching host key fingerprint found in DNS.