Activation de SSH sur les hôtes d’ Satellite

Dans les scénarios de dépannage et de débogage, un accès SSH à vos hôtes Satellite est requis, soit avant, soit après leur affectation à votre plan de contrôle ou à un cluster.

Par exemple, si vous rencontrez des problèmes lors de l'attribution des hôtes, vous pouvez autoriser un utilisateur non root à accéder à un hôte via SSH avant de l'attribuer à un cluster.

Consultez les sections suivantes pour connaître les étapes à suivre pour activer l'accès SSH à vos hôtes.

Activation de SSH non root sur les hôtes RHCOS avant l'affectation

RHCOS

Étant donné que l'accès SSH root est généralement désactivé sur les hôtes d' CoreOS, et que l'accès SSH est désactivé à la fois sur root et core dans le cadre de l'attribution d'hôte, vous pouvez accorder l'accès SSH en ajoutant un nouvel utilisateur non root qui n'est pas l'utilisateur par défaut d' core.

Ces instructions décrivent comment activer l'accès SSH pour un nouvel utilisateur sur un hôte Red Hat CoreOS avant de l'affecter à un cluster ou au plan de contrôle.

Annulez ces étapes et désactivez l'accès SSH une fois le dépannage terminé.

  1. Créez un nouvel utilisateur satellite dans le fichier host attach ignition que vous avez utilisé lors de la création de l'hôte CoreOS. Modifiez la section « Edit passwd » du fichier d'initialisation comme suit.

        "passwd": {
        "users": [
            {
                "name": "core",
                "sshAuthorizedKeys": [
                    ""
                ]
            },
            {
                "name": "satellite",
                "sshAuthorizedKeys": [
                    "ssh-rsa AAA... KEYNAME"
                ],
                "groups": [
                    "sudo"
                ]
            }
        ]
    },

  2. Ajouter une clé publique SSH. Pour créer une paire de clés SSH, vous pouvez exécuter la commande ssh-keygen.

    ssh-keygen -f ~/.ssh/sat-host-access -t rsa -b 4096 -C sat-host-access -P ''

  3. Le fichier sat-host-access.pub contient la clé à ajouter au fichier d'amorçage. Ajoutez l'intégralité du contenu du fichier au script d'amorçage en remplaçant ssh-rsa AAA... KEYNAME dans l'exemple ci-dessus. La clé privée sat-host-access est celle que vous utilisez pour vous connecter à l'hôte via SSH.

    Toute personne disposant de la clé privée correspondant à la clé publique que vous venez d'ajouter à cet hôte et d'un accès réseau aux nœuds peut accéder à ce système par SSH.

  4. Facultatif: Exécutez les commandes journalctl suivantes pour rassembler les journaux à des fins de débogage.

    journalctl -u ibm-host-attach --no-pager

    journalctl -u ibm-host-agent --no-pager

    journalctl -u ibm-firstboot-ignition --no-pager

Activation de SSH non root sur les hôtes RHEL avant l'affectation

RHEL

Ces instructions décrivent comment activer temporairement l'accès SSH non racine à un nœud de travail du cluster RHEL.

Annulez ces étapes et désactivez l'accès SSH une fois le dépannage terminé.

Avant de commencer, assurez-vous que vous disposez d'un accès SSH root à l'hôte non attribué.

  1. Si vous souhaitez utiliser la même clé SSH pour ce nouvel utilisateur que l'utilisateur root sur cet hôte, vous n'avez pas besoin d'une autre clé. Cependant, si vous souhaitez utiliser une autre paire de clés SSH pour ce nouvel utilisateur, vous devez soit avoir cette paire de clés à portée de main, soit créer une nouvelle paire de clés publiques/privées SSH sur le système que vous utilisez pour vous connecter à l'hôte via SSH. Ne communiquez la clé privée à personne. Ces instructions supposent que vous avez créé cette nouvelle paire de clés.
    ssh-keygen -f ~/.ssh/sat-host-access -t rsa -b 4096 -C sat-host-access -P ''`

Exécutez les étapes restantes sur l'hôte lui-même, donc connectez-vous à l'hôte avec les droits root avant de continuer.

  1. Créez un utilisateur et configurez-le pour qu'il dispose d'un accès sudo complet sans mot de passe.

    useradd -U -m -s /bin/bash satellite && mkdir -p /home/satellite/.ssh && chown -R satellite:satellite /home/satellite/

  2. Ajoutez votre clé SSH au nouvel utilisateur.

    • Si vous souhaitez utiliser la ou les mêmes clés SSH pour cet utilisateur que pour l'utilisateur root, exécutez la commande suivante.
        cp -r /root/.ssh/authorized_keys /home/satellite/.ssh/
    ```
* Si vous avez créé une nouvelle paire de clés ou si vous disposez déjà d'une clé SSH publique, ajoutez-la à l'utilisateur `satellite` en exécutant la commande suivante.
```sh {: pre}
    echo "<CONTENTS OF ~/.ssh/sat-host-access.pub OR YOUR OWN PUBLIC KEY>" >> /home/satellite/.ssh/authorized_keys && chmod 600 /home/satellite/.ssh/authorized_keys
    ```

  3. Exécutez la commande suivante.

    chown -R satellite:satellite /home/satellite/.ssh/authorized_keys

  4. Pour donner à ce nouvel utilisateur d' satellite s un accès sudo complet sans mot de passe, exécutez la commande suivante.

    echo "satellite ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers

    Vous pouvez également configurer l'utilisateur pour qu'il ait des droits plus limités, configurez-le plutôt sur l'hôte. Nous vous recommandons, à des fins de dépannage, de donner à cet utilisateur un accès sudo complet. Une fois le dépannage terminé, vous pouvez supprimer l'utilisateur ou limiter ses droits.

    Désormais, toute personne possédant la clé privée correspondant à la clé publique que vous venez d'ajouter à cet hôte et ayant accès au réseau des nœuds peut se connecter à ce système par SSH avec les droits d'administrateur.

  5. Connectez-vous au nœud en tant que nouvel utilisateur pour vérifier qu'il fonctionne.

    ssh -i ~/.ssh/sat-host-access satellite@NODE-IP

  6. Exécutez ensuite la commande suivante pour vérifier que vous pouvez obtenir les droits d'administrateur de cet utilisateur.

    sudo su - root

  7. Facultatif : vérifiez les différents fichiers de journaux générés lors des processus d'enregistrement et de démarrage de l'hôte. Remplacez par <filepath> les fichiers suivants, dans l'ordre indiqué. Selon le problème rencontré, certains fichiers journaux peuvent ne pas être présents sur l'hôte si le processus correspondant n'a pas été exécuté.

    1. Journaux nohup.out issus de la tentative d'enregistrement de l'hôte.
    2. Fichier /var/log/firstboot.log issu de la première tentative d'amorçage. Si l'enregistrement de l'hôte a échoué, vous ne disposez pas de ce fichier.
    3. Fichier /tmp/bootstrap/bootstrap_base.log pour le processus d'amorçage de base, si le premier amorçage a échoué. Si l'enregistrement de l'hôte a échoué, vous ne disposez pas de ce fichier.
        tail <filepath>
    ```
1. Exécutez les commandes `journalctl` pour collecter les journaux pour le débogage.

```sh {: pre}
    journalctl -u ibm-host-agent --no-pager
    ```
    ```sh {: pre}
    journalctl -u ibm-firstboot --no-pager
    ```
    ```sh {: pre}
    journalctl -u ibm-host-attach --no-pager
    ```

Activation du SSH root sur les hôtes après l'affectation

RHCOS RHEL

Dans certains cas de dépannage, un accès SSH est nécessaire directement sur un hôte déjà affecté en tant que nœud de travail au sein d'un cluster — par exemple, lorsque les nœuds de travail du cluster perdent la connexion avec le nœud maître du cluster. Ces instructions décrivent comment activer temporairement l'accès SSH en tant qu'utilisateur root à un nœud de travail de cluster Red Hat CoreOS ou RHEL au sein d'un cluster Satellite.

Annulez ces étapes et désactivez l'accès SSH une fois le dépannage terminé.

Avant de commencer, assurez-vous de disposer des éléments suivants.

  • Accès à un système qui a un accès direct aux travailleurs du cluster, à utiliser comme système client SSH.
  • Accès administrateur à ce cluster pour que vous puissiez exécuter oc debug node/NODE-NAME.

  1. Créez une paire de clés publique/privée SSH sur votre client SSH. Ne donnez la clé privée à personne.

    ssh-keygen -f ~/.ssh/sat-host-access -t rsa -b 4096 -C sat-host-access -P ''

  2. Vérifier que la clé publique a bien été créée.

    cat ~/.ssh/sat-host-access.pub

  3. À partir d'un système qui a accès au maître de cluster et qui dispose de l'accès d' kubeconfig s d'administration, exécutez la commande suivante.

    oc debug node/NODE-NAME

  4. Exécutez les commandes suivantes à partir du shell sur NODE-NAME pour activer le SSH root.

    chroot /host

    echo "<CONTENTS OF ~/.ssh/sat-host-access.pub>" >> /root/.ssh/authorized_keys

    chmod 600 /root/.ssh/authorized_keys

  5. Définissez une variable d'environnement pour votre SSHD_CONFIG_FILE en utilisant l'une des commandes suivantes. L'emplacement du fichier de configuration varie selon la version du worker. Si aucun des chemins d'accès indiqués ne correspond à votre hôte, définissez la variable d'environnement SSHD_CONFIG_FILE sur le chemin d'accès complet du fichier de configuration sshd avant de continuer.

    Exemple de commande pour les travailleurs d' CoreOS.

    export SSHD_CONFIG_FILE="/etc/ssh/sshd_config.d/40-rhcos-defaults.conf"

    Exemple de commande pour les travailleurs RHEL 9.

    export SSHD_CONFIG_FILE="/etc/ssh/sshd_config"

  6. Vérifiez le paramètre PermitRootLogin.

    grep ^PermitRootLogin $SSHD_CONFIG_FILE

  7. Définissez PermitRootLogin sur yes.

    sed -i "s/PermitRootLogin no/PermitRootLogin yes/g" $SSHD_CONFIG_FILE

  8. Vérifiez le réglage.

    grep ^PermitRootLogin $SSHD_CONFIG_FILE

  9. Exécutez les commandes suivantes pour redémarrer et quitter.

    systemctl restart sshd

    exit && exit

À ce stade, l'accès SSH root depuis le système client SSH est activé à l'aide de la clé privée que vous avez créée précédemment. Notez que toute personne possédant cette clé privée et ayant accès aux nœuds peut se connecter à ce système en tant que root via SSH. Utilisez la commande suivante pour vous connecter au nœud via SSH : ssh -i ~/.ssh/sat-host-access root@NODE-IP.