Préparer mon VPS pour Lifeline

Avant une intervention Lifeline, deux conditions doivent être réunies sur votre VPS : l’agent QEMU doit être actif et notre clé publique SSH doit être installée. Cette préparation permet à nos administrateurs d’accéder au serveur lorsque vous leur demandez d’intervenir.

Deux méthodes sont proposées :

Méthode automatique (recommandée) : un script vérifie et prépare tout en une commande, puis affiche un récapitulatif à joindre à votre ticket.
Méthode manuelle : vous exécutez vous-même chaque étape, si vous préférez garder la main sur chaque commande.

L’agent QEMU est déjà installé sur les VPS livrés par PulseHeberg : il suffit normalement de vérifier qu’il est actif. La clé SSH, elle, doit être ajoutée si elle n’est pas déjà présente.

Avant de commencer#

Lifeline concerne les VPS sous Linux. Connectez-vous à votre VPS en SSH avec un compte administrateur. Effectuez cette préparation tant que vous disposez encore de l’accès au serveur et gardez votre session ouverte pendant les manipulations.

Les commandes ci-dessous utilisent le compte root. Si vous utilisez un autre compte avec sudo, ouvrez d’abord une session administrateur :

sudo -i

Si vous êtes déjà connecté en root, cette commande n’est pas nécessaire.

Autoriser l'accès SSH dans votre pare-feu#

Le script Lifeline ne modifie jamais votre pare-feu. Si vous utilisez un pare-feu sur votre VPS ou en amont, vous devez autoriser les connexions SSH entrantes depuis les deux adresses IP sources suivantes :

185.157.244.42
89.234.180.180

Ajoutez ces autorisations sur le port TCP utilisé par votre serveur SSH : 22 par défaut, ou votre port personnalisé. Ces règles sont à configurer vous-même avant l'intervention, dans chaque pare-feu qui filtre l'accès à votre VPS.

Méthode automatique (recommandée)#

Systèmes pris en charge#

Famille	Distributions
Debian	Debian, Ubuntu
Red Hat	AlmaLinux, Rocky Linux, CentOS, RHEL, Oracle Linux, CloudLinux, Fedora
SUSE	openSUSE, SLES
Arch	Arch Linux, Manjaro
Alpine	Alpine Linux
Gentoo	Gentoo

Sur une autre distribution Linux, le script ajoute la clé et vérifie la configuration SSH ; si l’agent QEMU est absent, installez-le avec votre gestionnaire de paquets puis relancez le script.

Lancer le script#

Depuis votre session root, exécutez :

curl -fsSL https://lifeline.pulseheberg.com/setup.sh | sh

Si curl n’est pas installé (cas fréquent sur Alpine), utilisez wget :

wget -qO- https://lifeline.pulseheberg.com/setup.sh | sh

Vous préférez lire le script avant de l’exécuter ? Téléchargez-le, consultez-le, puis lancez-le :

curl -fsSLo lifeline-setup.sh https://lifeline.pulseheberg.com/setup.sh
less lifeline-setup.sh
sh lifeline-setup.sh

Ce que fait le script#

Agent QEMU : il vérifie que le canal de communication avec notre infrastructure est présent, installe le paquet qemu-guest-agent s’il manque, l’active au démarrage et le démarre.
Clé SSH Lifeline : il ajoute notre clé publique à /root/.ssh/authorized_keys sans toucher à vos clés et sans jamais l’ajouter deux fois, applique les permissions attendues et, si SELinux est actif, les contextes de sécurité. Il contrôle aussi que la clé qu’il contient correspond bien à l’empreinte publiée ci-dessous.
Configuration SSH : il lit la configuration effective du serveur SSH (connexion de root, fichier de clés, port, restrictions d’accès) et signale tout ce qui empêcherait notre accès.

Le script ne modifie jamais la configuration du serveur SSH, votre pare-feu, vos mots de passe ni vos propres clés. Il ne réactive pas un service que vous avez masqué et ne touche pas aux paramètres de virtualisation. Il ne déclenche aucune intervention.

Lire le résultat#

Chaque vérification est précédée d’un repère :

Repère	Signification
`[ OK ]`	Le point est conforme.
`[INFO]`	Information à mentionner dans votre ticket (port SSH personnalisé, par exemple).
`[ATTN]`	Point à traiter avant une intervention. Une explication suit la ligne.
`[ERR ]`	Le script n’a pas pu terminer une étape.

Le script se termine par un récapitulatif. Copiez-le tel quel dans votre ticket : il donne à notre équipe l’état de votre VPS sans échange supplémentaire.

--- Récapitulatif à copier dans votre ticket Lifeline ---
lifeline-setup : 1.0.0, mode install, 2026-10-25 14:33 UTC
hôte           : mon-vps
système        : Debian GNU/Linux 12 (bookworm), noyau 6.1.0-26-amd64, init systemd
agent QEMU     : actif, canal présent
clé Lifeline   : présente, permissions conformes
fichier        : /root/.ssh/authorized_keys
SSH            : PermitRootLogin prohibit-password, PubkeyAuthentication yes, port 22
SELinux        : absent
statut         : prêt
---------------------------------------------------------

Le message final résume la situation :

Votre VPS est prêt pour Lifeline : aucune action supplémentaire n’est nécessaire.
Préparation incomplète : traitez les lignes [ATTN] en suivant les explications affichées, puis relancez le script. Si vous ne pouvez pas les corriger vous-même, ouvrez un ticket en y joignant le récapitulatif.
La préparation a échoué : ouvrez un ticket en y joignant le récapitulatif.

Le script peut être relancé autant de fois que nécessaire : il ne refait que ce qui manque.

Options#

Option	Effet
`--check`	Diagnostic seul : le script vérifie tout sans rien modifier.
`--remove`	Retire la clé Lifeline, et uniquement elle.
`--help`	Affiche l’aide.

Avec la commande en une ligne, ajoutez l’option après sh -s -- :

curl -fsSL https://lifeline.pulseheberg.com/setup.sh | sh -s -- --check

Si vous lancez le script depuis un outil d’automatisation, ses codes de sortie sont : 0 VPS prêt, 1 échec, 2 au moins un point à traiter.

Méthode manuelle#

1. Vérifier que l’agent QEMU est actif#

L’agent QEMU permet à notre infrastructure de communiquer avec le système de votre VPS, notamment pour certaines opérations d’administration et la préparation des snapshots.

Exécutez :

systemctl is-active qemu-guest-agent

Le résultat attendu est :

active

Vous pouvez consulter le détail avec :

systemctl status qemu-guest-agent --no-pager

La ligne Active: doit indiquer active (running).

Sur Alpine Linux, qui n’utilise pas systemd, la vérification se fait avec :

rc-service qemu-guest-agent status

Le résultat attendu contient status: started.

Si l’agent est arrêté

Démarrez-le, puis vérifiez de nouveau son état :

systemctl start qemu-guest-agent
systemctl is-active qemu-guest-agent

Sur Alpine Linux :

rc-update add qemu-guest-agent default
rc-service qemu-guest-agent start

Si l’agent est introuvable

Le paquet a peut-être été supprimé ou votre système a été réinstallé. Réinstallez-le selon votre distribution :

Debian / Ubuntu :

apt update
apt install qemu-guest-agent
systemctl start qemu-guest-agent

AlmaLinux / Rocky Linux / CentOS / RHEL / Fedora :

dnf install qemu-guest-agent
systemctl enable --now qemu-guest-agent

Sur CentOS 7, remplacez dnf par yum.

openSUSE / SLES :

zypper install qemu-guest-agent
systemctl enable --now qemu-guest-agent

Arch Linux / Manjaro :

pacman -S qemu-guest-agent
systemctl enable --now qemu-guest-agent

Alpine Linux :

apk add qemu-guest-agent
rc-update add qemu-guest-agent default
rc-service qemu-guest-agent start

Gentoo :

emerge app-emulation/qemu-guest-agent

Puis, selon votre système d’initialisation, systemctl enable --now qemu-guest-agent ou rc-update add qemu-guest-agent default && rc-service qemu-guest-agent start.

Vérifiez ensuite que l’agent est bien actif avec la commande de vérification ci-dessus.

Si l’agent ne démarre pas

L’agent a besoin d’un canal de communication fourni par notre infrastructure. Vérifiez sa présence :

ls -l /dev/virtio-ports/

La liste doit contenir org.qemu.guest_agent.0. Sur Alpine Linux, ce lien peut être absent alors que le canal existe : dans ce cas, utilisez la méthode automatique, qui configure l’agent avec le bon chemin.

Si le service reste en échec, est masqué (masked) ou signale un périphérique de communication absent, ouvrez un ticket en joignant le message d’erreur. Ne modifiez pas les paramètres de virtualisation pour tenter de contourner le problème. Un service actif confirme son fonctionnement dans le VPS ; la communication avec l’infrastructure peut également nécessiter une vérification par notre équipe.

2. Ajouter la clé SSH Lifeline#

Voici la clé publique utilisée par notre équipe :

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHc/36ifmXENTDGHuWYHU2KN0e/kad5UfkvAjdgMmpSc [email protected]

Son empreinte SHA256 est :

SHA256:/IT7ML5kryCTcjLRAKS/RfTxmIZeHKMPXqRsVwvUhVI

Ajoutez cette clé au fichier /root/.ssh/authorized_keys, sur une seule ligne. Le bloc suivant crée le dossier et le fichier si nécessaire, conserve vos clés existantes et évite d’ajouter deux fois la même ligne :

install -d -m 700 -o root -g root /root/.ssh
touch /root/.ssh/authorized_keys
chown root:root /root/.ssh/authorized_keys
chmod 600 /root/.ssh/authorized_keys

lifeline_key='ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHc/36ifmXENTDGHuWYHU2KN0e/kad5UfkvAjdgMmpSc [email protected]'
if ! grep -qxF "$lifeline_key" /root/.ssh/authorized_keys; then
    printf '\n%s\n' "$lifeline_key" >> /root/.ssh/authorized_keys
fi
unset lifeline_key

L’ajout de la clé ne nécessite pas de redémarrer SSH ou le VPS. Ne remplacez pas le contenu d’authorized_keys : vos propres clés doivent rester présentes.

Si SELinux est actif (AlmaLinux, Rocky Linux, RHEL, Fedora…), appliquez également les contextes attendus :

restorecon -RF /root/.ssh

Si votre configuration SSH est personnalisée

Cette procédure suppose que SSH autorise la connexion de root par clé et utilise le fichier /root/.ssh/authorized_keys. Vous pouvez consulter les réglages effectifs avec :

sshd -T | grep -Ei '^(permitrootlogin|pubkeyauthentication|authorizedkeysfile|port) '

permitrootlogin doit valoir prohibit-password, without-password ou yes, et pubkeyauthentication doit valoir yes.

Si vous avez désactivé cet accès, changé le port SSH, limité les adresses autorisées par le pare-feu ou configuré un autre fichier de clés, précisez-le dans votre ticket. Notre équipe vous indiquera comment adapter l’accès. N’activez pas l’authentification par mot de passe et ne désactivez pas votre pare-feu pour appliquer ce tutoriel.

3. Vérifier la présence de la clé#

Toujours depuis la session administrateur, exécutez :

ssh-keygen -lf /root/.ssh/authorized_keys

La liste doit contenir cette empreinte :

256 SHA256:/IT7ML5kryCTcjLRAKS/RfTxmIZeHKMPXqRsVwvUhVI [email protected] (ED25519)

Vérifiez aussi les permissions :

ls -ld /root/.ssh
ls -l /root/.ssh/authorized_keys

Le dossier doit appartenir à root avec les permissions drwx------ et le fichier à root avec les permissions -rw-------.

Cette vérification confirme que la clé est installée ; seul un contrôle de connexion par notre équipe permet de confirmer que l’accès fonctionne de bout en bout. Vous ne pouvez pas tester une connexion avec notre clé publique seule.

Demander une intervention#

Votre VPS est prêt lorsque :

L’agent qemu-guest-agent est actif.
La clé publique Lifeline est présente dans le compte prévu pour l’intervention.
Votre configuration SSH autorise l’accès convenu avec notre équipe et, si vous utilisez un pare-feu, celui-ci autorise les connexions SSH depuis 185.157.244.42 et 89.234.180.180.

Si Lifeline n’est pas encore activée, rendez-vous dans le panneau de gestion de votre VPS, une fois celui-ci en service.

Pour demander de l’aide, ouvrez un ticket Lifeline, sélectionnez le VPS concerné et décrivez votre besoin. Indiquez les erreurs rencontrées, les actions déjà tentées et vos éventuelles contraintes de production. Si vous avez utilisé la méthode automatique, joignez le récapitulatif affiché par le script.

Ne communiquez jamais de mot de passe ni de clé privée dans le ticket. Nous utilisons la clé publique installée pour nous authentifier avec notre clé privée.

L’installation de la clé ne déclenche aucune intervention et ne vaut pas autorisation permanente d’accès. Les actions prévues, le crédit utilisé et le montant éventuel sont validés dans le ticket avant l’intervention.

Retirer la clé Lifeline#

Vous pouvez retirer la clé Lifeline à tout moment. Seule sa ligne est supprimée : vos autres clés sont conservées.

Avec le script :

curl -fsSL https://lifeline.pulseheberg.com/setup.sh | sh -s -- --remove

Manuellement :

sed -i '\#AAAAC3NzaC1lZDI1NTE5AAAAIHc/36ifmXENTDGHuWYHU2KN0e/kad5UfkvAjdgMmpSc#d' /root/.ssh/authorized_keys

Le retrait de la clé ne résilie pas l’abonnement, mais l’accès nécessaire aux interventions devra être rétabli avant toute demande.