Définissez la clé d'hôte ssh spécifique au client sur plusieurs clients sans disque qui utilisent exactement le même système de fichiers racine

Avant-propos: ciblez les lecteurs de cet article

• Les personnes qui souhaitent créer une sorte de cluster sur plusieurs Linux sans disque
• Lors de la construction d'un cluster avec 10 à 20 nœuds ou plus, il est extrêmement plus facile de gérer les utilisateurs / hôtes en configurant un serveur LDAP, donc les personnes qui n'ont pas le nombre de nœuds jusqu'à la configuration d'un serveur LDAP
• Les personnes qui ne veulent pas submerger le disque du serveur NFS et qui souhaitent utiliser une image de système d'exploitation sur le même partage NFS sur tous les nœuds
• Les personnes qui souhaitent démarrer un serveur SSH sur tous les nœuds mais ne souhaitent pas utiliser une clé d'hôte SSH commune sur tous les nœuds (= veulent utiliser une clé d'hôte unique pour chaque nœud)

Il s'agit d'informations destinées aux personnes qui répondent à toutes les exigences.

L'essence du problème

1. Étant donné que plusieurs machines utilisent le même système de fichiers racine, l'utilisation du fichier sshd_config par défaut oblige sshd sur toutes les machines à lire et à démarrer le même fichier de clé d'hôte (/ etc / ssh / ssh_host_ * _key).
2. Il est impossible pour Linux de séparer / etc de la racine et d'une autre partition.
3. Il est presque impossible d'utiliser overlayfs avec un client sans disque qui utilise NFS (overlayfs ne prend pas en charge NFSv3).
4. Si vous modifiez la clé d'hôte sous / etc / ssh avant de démarrer sshd, les clés des autres hôtes changeront également. Puisqu'il s'agit d'un client sans disque en premier lieu, c'est impossible car les fichiers sous / etc ne peuvent pas être modifiés.

Solution

Vous pouvez résoudre le problème ci-dessus par les méthodes suivantes.

1. L'endroit où vous le sauvegardez n'a pas d'importance, alors enregistrez à l'avance toutes les clés d'hôte spécifiques au nœud (créez un sous-répertoire avec le nom d'hôte du nœud et mettez-les toutes).
2. Préparez un répertoire accessible en écriture (par exemple, créez / var / lib / sshd et montez-le en tant que tmpfs dans / etc / fstab)
3. Définissez sshd_config pour lire la clé d'hôte sous le répertoire créé en 2.
4. Au démarrage, après avoir acquis l'IP (lorsque le nom d'hôte local est connu) et juste avant le démarrage de sshd, modifiez la clé d'hôte stockée dans le sous-répertoire de l'hôte local de 1. vers le répertoire 2. copie

Cette technique peut être utilisée non seulement pour sshd, mais aussi pour démarrer d'autres démons qui utilisent des informations spécifiques à l'hôte. (Cependant, vous pouvez tout faire avec DNS ou DHCP pour l'IP et le nom d'hôte.)

Méthode spécifique

Tout le travail est effectué sur le serveur NFS, chrooté sur l'image du système d'exploitation distribuée aux nœuds. Par la suite, on suppose que le nom d'hôte du nœud sans disque est host1 à host4.

1. Comment générer une clé d'hôte individuelle

Pour plus de sécurité, conservez toutes les clés dans / root / host_keys.

# mkdir /root/host_keys; cd /root/host_keys
# for N in `seq 1 4`; do HN="host${N}"; mkdir ${HN}; for T in rsa ecdsa ed25519; do ssh-keygen -h -t ${T} -C ${HN} -N '' -f ${HN}/ssh_host_${T}_key; done; done

2. Créez un répertoire accessible en écriture même avec un client sans disque

# mkdir /var/lib/sshd
# vim /etc/fstab
(Les changements sont les suivants)
#

Ajoutez la ligne suivante à / etc / fstab

tmfps /var/lib/sshd tmpfs defaults,mode=700 0 0

3. Modifiez le fichier sshd_config

# vi /etc/ssh/sshd_config
(Les changements sont les suivants)
#

Modifications (activer et modifier l'entrée HostKey mise en commentaire par défaut)

(réduction)
HostKey /var/lib/sshd/ssh_host_rsa_key
HostKey /var/lib/sshd/ssh_host_ecdsa_key
HostKey /var/lib/sshd/ssh_host_ed25519_key
(réduction)

4. Créez un processus pour copier le fichier de clé spécifique à l'hôte au bon moment

Afin de gérer correctement la synchronisation, créez un nouveau fichier d'unité de systemd et formatez-le pour appeler un script dédié à partir d'ici.

4.1 Créer un script shell dédié

Le nom du fichier peut être n'importe quoi, mais il doit être / usr / local / sbin / copy_sshkeys.

# vim /usr/local/sbin/copy_sshkeys
# chmod 700 /usr/local/sbin/copy_sshkeys

Le contenu du script est le suivant. Définissez la valeur de retour afin que systemd puisse déterminer l'erreur.

#!/bin/bash
HN=`hostname`
RETVAL=0

if [ "${HN}" != "" ]
then
  cp -pf /root/host_keys/${HN}/ssh_host* /var/lib/sshd/
  RETVAL=$?
else
  #Impossible d'obtenir le nom d'hôte
  RETVAL=2
fi

exit $RETVAL

4.2. Création d'un fichier d'unité systemd

Créez un nouveau fichier Unit sous / etc / systemd / system. Le nom de ce fichier peut être n'importe quoi, tant que vous suivez les règles de l'extension .service, mais par souci de clarté, nommez-le ssh_hostkey_copy.service.

# vi /etc/systemd/system/ssh_hostkey_copy.service
(Le contenu est le suivant)
# systemctl enable ssh_hostkey_copy.service
(Résultat de sortie omis)
#

Le contenu du fichier Unit est le suivant.

[Unit]
Description=SSH Hostkey copy process for diskless clients
After=network.target local-fs.target
#Sshd selon la distribution.Cela peut être un service
Before=ssh.service

[Service]
ExecStart=/usr/local/sbin/copy_sshkeys
Type=oneshot

[Install]
WantedBy=multi-user.target
RequiredBy=ssh.service

Cela permettra aux clients sans disque de démarrer sshd avec une clé d'hôte unique.