Lorsqu’on administre plusieurs serveurs Linux, hyperviseurs ou équipements réseau, il est souvent nécessaire de centraliser les accès d’administration. Plusieurs solutions existent : VPN, ouverture de ports sur les machines concernées ou mise en place d’un bastion d’accès.

C’est cette dernière approche que propose Warpgate, un bastion open source permettant de centraliser et de contrôler les accès aux services d’administration, notamment SSH et les interfaces Web accessibles en HTTPS.

Dans ce mémo, nous allons installer Warpgate sur Debian 13 à partir du binaire officiel, sans Docker. Nous configurerons ensuite deux accès vers un serveur Proxmox VE : une connexion SSH et un accès à l’interface Web d’administration.

L’objectif est de découvrir le fonctionnement de Warpgate avec une installation simple, reproductible et facile à maintenir.

Architecture utilisée

Pour les besoins de ce mémo, nous utiliserons le réseau de laboratoire suivant :

Les deux machines sont ici sur le même réseau afin de simplifier les premiers tests.

Attention : cette architecture est volontairement simplifiée. Dans un environnement de production, le bastion doit être placé dans une zone réseau dédiée, idéalement une DMZ. Le pare-feu doit autoriser uniquement les flux nécessaires entre Warpgate et les serveurs d’administration. L’exposition à Internet ne doit pas donner un accès direct aux interfaces d’administration de Proxmox ou des autres machines.

1. Présentation de Warpgate

1.1. Qu’est-ce que Warpgate ?

Warpgate est un bastion d’accès et un proxy destiné à sécuriser l’administration d’infrastructures. Il permet de centraliser les accès vers des systèmes internes sans imposer l’installation d’un client spécifique pour les usages pris en charge.

Il prend notamment en charge les accès SSH et HTTP/HTTPS, ainsi que d’autres protocoles comme RDP, VNC, PostgreSQL, MySQL et Kubernetes.

Depuis son interface Web, l’administrateur peut déclarer des cibles, gérer les utilisateurs et leurs permissions, puis suivre les sessions. Selon le protocole et la configuration, les sessions peuvent également être enregistrées.

Warpgate ne remplace donc ni un hyperviseur, ni un VPN, ni un pare-feu : il ajoute une couche de contrôle et de traçabilité aux accès d’administration.

1.2. Warpgate ou Apache Guacamole ?

Warpgate et Apache Guacamole répondent à des besoins proches, mais leur approche diffère.

Guacamole est particulièrement intéressant lorsqu’on souhaite proposer un portail de connexions distantes accessibles depuis un navigateur, notamment pour les postes de travail RDP et VNC.

Warpgate se distingue par son approche de bastion et de proxy d’accès, avec une gestion centralisée des cibles et des permissions, ainsi que des connexions natives pour plusieurs protocoles.

Le choix dépend donc du besoin. Pour centraliser des accès d’administration à des serveurs et interfaces techniques, Warpgate est une solution à étudier. Pour proposer un portail d’accès distant à des postes de travail, Guacamole reste une référence pertinente.

2. Installation de Warpgate sur Debian 13

2.1. Pourquoi une installation native plutôt que Docker ?

Warpgate peut être installé à partir d’une image de conteneur ou directement à l’aide de son binaire. Pour ce mémo, nous retenons la seconde méthode.

Le choix d’une installation native s’explique par plusieurs raisons :

• Simplicité d’exploitation : un binaire, un fichier de configuration et un service systemd.
• Intégration à Debian : gestion du démarrage, des journaux et des redémarrages avec les outils habituels du système.
• Moins de couches à maintenir : pas de moteur Docker ni de fichiers Compose pour cette installation.
• Maîtrise de la configuration : les chemins, les droits et les ports sont gérés directement sur le système.

Cette préférence ne signifie pas que Docker est une mauvaise solution. Les conteneurs ont leurs avantages, notamment pour les déploiements reproductibles et les environnements orchestrés. Ici, l’objectif est de privilégier une installation classique, facile à comprendre et à dépanner sur un serveur Debian.

2.2. Préparer Debian 13

Connectez-vous au serveur destiné à héberger Warpgate et mettez à jour le système :

apt update && apt full-upgrade -y

Installez les outils utiles :

apt install ca-certificates curl wget -y

2.3. Télécharger le binaire officiel

La page officielle des versions est disponible à l’adresse suivante :

https://github.com/warp-tech/warpgate/releases

Au moment de la rédaction, la version stable retenue est v0.30.0. Avant publication, vérifiez à nouveau la dernière version stable ainsi que les fichiers disponibles.

Sur un serveur x86-64 classique, l’architecture Debian est généralement AMD64. Vérifiez toutefois le nom exact des artefacts proposés par la version choisie :

dpkg --print-architecture
#ou
uname -m

Téléchargez le binaire correspondant depuis la page officielle des versions. Évitez de récupérer un exécutable depuis un miroir non vérifié ou un dépôt tiers.

wget https://github.com/warp-tech/warpgate/releases/download/v0.30.0/warpgate-v0.30.0-x86_64-linux -O warpgate

chmod +x warpgate

Après téléchargement et vérification du fichier, installez-le dans /usr/bin/warpgate. Dans l’exemple suivant, le fichier téléchargé se trouve dans le répertoire courant et porte le nom warpgate :

install -o root -g root -m 0755 \
  ./warpgate /usr/bin/warpgate

Vérifiez que le binaire est exécutable :

/usr/bin/warpgate --help

Si la commande affiche l’aide de Warpgate, le binaire est accessible. Si elle échoue, vérifiez l’architecture du fichier, ses permissions et son intégrité.

Sécurité : si le projet fournit une somme de contrôle ou une signature pour la version choisie, vérifiez-la avant l’installation. Un téléchargement HTTPS ne suffit pas, à lui seul, à vérifier l’intégrité du fichier par rapport à la publication officielle.

2.4. Initialiser Warpgate

Warpgate fournit une commande interactive de configuration initiale :

/usr/bin/warpgate setup

L’assistant pose plusieurs questions. Les choix exacts dépendent de la version, mais il faudra notamment définir :

• Le répertoire de données.
• Le port d’écoute de l’interface Web.
• Le port d’écoute SSH du bastion.
• Les protocoles à activer.
• L’enregistrement éventuel des sessions.
• Le mot de passe initial du compte administrateur.

Pour ce laboratoire, nous retiendrons les valeurs suivantes, sous réserve de confirmation par l’assistant de la version installée :

Ces ports sont ceux du service Warpgate, pas ceux de Proxmox.

L’assistant peut générer un certificat TLS pour l’interface Web. Pour un laboratoire, ce certificat permet de démarrer rapidement. En production, prévoyez une gestion adaptée des certificats et du nom DNS utilisé par les utilisateurs.

Conservez le mot de passe administrateur dans un gestionnaire de mots de passe. Il sera nécessaire pour accéder à l’interface de gestion.

Dans mon cas, j’ai dû créer le répertoire /var/lib/warpgate avant d’éxécuter /usr/bin/warpgate setup sinon, je me retrouvais avec cette erreur : ERROR Fatal error error=No such file or directory (os error 2).

mkdir -p /var/lib/warpgate

puis on éxécute le setup :

/usr/bin/warpgate setup

root@warpgate:~# /usr/bin/warpgate setup
10:32:56  INFO Welcome to Warpgate v0.30.0
10:32:56  INFO Let's do some basic setup first.
10:32:56  INFO The new config will be written in /etc/warpgate.yaml.
10:32:56  INFO * Paths can be either absolute or relative to /etc.
✔ Directory to store app data (up to a few MB) in · /var/lib/warpgate
✔ Endpoint to listen for HTTP connections on · [::]:8888
10:32:59  INFO You will now choose specific protocol listeners to be enabled.
10:32:59  INFO 
10:32:59  INFO NB: Nothing will be exposed by default -
10:32:59  INFO     you'll choose target hosts in the UI later.
✔ Accept SSH connections? · yes
✔ Endpoint to listen for SSH connections on · [::]:2222
✔ Accept MySQL connections? · yes
✔ Endpoint to listen for MySQL connections on · [::]:33306
✔ Accept PostgreSQL connections? · yes
✔ Endpoint to listen for PostgreSQL connections on · [::]:55432
✔ Accept Kubernetes connections? · yes
✔ Endpoint to listen for Kubernetes connections on · [::]:8443
✔ Accept VNC connections? · yes
✔ Endpoint to listen for VNC connections on · [::]:5900
✔ Accept RDP connections? · yes
✔ Endpoint to listen for RDP connections on · [::]:3389
✔ Do you want to record user sessions? · yes
✔ Set a password for the Warpgate admin user · ********
10:33:44  INFO Generated configuration:

Si tout est Ok :

10:33:44  INFO Saved into /etc/warpgate.yaml
10:33:44  INFO Using config: "/etc/warpgate.yaml"
10:33:44  INFO Generating root CA certificate
10:33:44  INFO Using config: "/etc/warpgate.yaml"
10:33:44  INFO Generating SSH host key (Ed25519)
10:33:44  INFO Generating SSH host key (Rsa)
10:33:50  INFO Generating SSH client key (Ed25519)
10:33:50  INFO Generating SSH client key (Rsa { hash: Some(Sha512) })
10:33:58  INFO Generating a TLS certificate
10:33:58  INFO 
10:33:58  INFO Admin user credentials:
10:33:58  INFO   * Username: admin
10:33:58  INFO   * Password: 
10:33:58  INFO 
10:33:58  INFO You can now start Warpgate with:
10:33:58  INFO   /usr/bin/warpgate --config /etc/warpgate.yaml run

Une fois la configuration créée, vérifiez les fichiers :

ls -l /usr/bin/warpgate
ls -l /etc/warpgate.yaml

2.5. Créer le service systemd

Pour que Warpgate démarre automatiquement après un redémarrage, nous allons créer un service systemd.

Créez le fichier suivant :

nano /etc/systemd/system/warpgate.service

Ajoutez la définition suivante, après avoir vérifié les paramètres de lancement prévus par la version installée :

[Unit]
Description=Warpgate
After=network.target
StartLimitIntervalSec=0

[Service]
Type=notify
Restart=always
RestartSec=5
ExecStart=/usr/bin/warpgate --config /etc/warpgate.yaml run

[Install]
WantedBy=multi-user.target

Cette unité utilise le fichier /etc/warpgate.yaml et demande à systemd de redémarrer le service en cas d’arrêt. Le type de service et les options de lancement doivent correspondre au modèle fourni par la documentation officielle de la version installée.

Rechargez la configuration systemd puis activez le service :

systemctl daemon-reload
systemctl enable --now warpgate

Vérifiez son état :

systemctl status warpgate

Consultez les journaux en cas de problème :

journalctl -u warpgate -b --no-pager

Pour suivre les événements en direct :

journalctl -u warpgate -f

Enfin, vérifiez les ports d’écoute :

ss -lntp

Vous devez retrouver les ports configurés pour l’interface Web et le service SSH de Warpgate.

2.6. Première connexion à l’interface Web

Depuis un navigateur, ouvrez l’adresse suivante :

https://192.168.10.248:8888

Le navigateur peut afficher un avertissement si le certificat TLS généré n’est pas reconnu par votre système. Dans un laboratoire isolé, cela peut être attendu ; pour une installation de production, utilisez un certificat correctement validé.

Connectez-vous avec le compte administrateur créé pendant l’initialisation.

Vous pouvez alors accéder aux fonctions de gestion des utilisateurs, des rôles, des cibles et des paramètres.

À ce stade, Warpgate est installé et fonctionne. Il reste à déclarer le serveur Proxmox comme cible.

3. Premier exemple : accéder à Proxmox en SSH

3.1. Principe

Le premier objectif est de passer par Warpgate pour ouvrir une session SSH vers le serveur pve-nuc.home.lan, dont l’adresse IP est 192.168.10.250.

Le port 2222 est le point d’entrée SSH de Warpgate. Le port 22 reste celui du serveur Proxmox.

3.2. Vérifier la connectivité réseau

Depuis le serveur Warpgate, vérifiez la résolution DNS :

getent hosts pve-nuc.home.lan

Vérifiez ensuite que le port SSH de Proxmox est joignable :

nc -vz 192.168.10.250 22

Si nc n’est pas installé, vous pouvez installer le paquet netcat-openbsd ou utiliser un autre outil de test TCP disponible.

Cette vérification permet de distinguer un problème de connectivité d’un problème de configuration Warpgate.

3.3. Ajouter la cible SSH

Dans l’interface d’administration Warpgate, ouvrez la section de gestion des cibles et ajoutez une cible de type SSH.

Les autres champs dépendent du mode d’authentification SSH proposé par la version utilisée.

Pour l’authentification sur le serveur Proxmox, privilégiez une clé SSH dédiée et un compte adapté aux tâches d’administration. Si vous devez utiliser un compte privilégié, limitez autant que possible ses droits et conservez une traçabilité des opérations.

Warpgate utilise ses propres mécanismes d’authentification et de gestion des clés pour les connexions vers les cibles. Suivez les indications affichées lors de la création de la cible afin d’autoriser la clé publique attendue sur le compte distant.

N’utilisez pas un mot de passe réutilisé entre Warpgate et le serveur Proxmox.

Enregistrez la cible, puis vérifiez qu’elle apparaît dans l’interface Warpgate.

3.4. Autoriser les utilisateurs

La création d’une cible ne signifie pas nécessairement que tous les utilisateurs peuvent y accéder.

Vérifiez les rôles et les permissions dans Warpgate. Associez la cible au groupe ou au rôle approprié, puis attribuez cet accès à un compte utilisateur de test.

Cette étape est essentielle : le but d’un bastion est justement de contrôler qui peut accéder à quelle machine.

• Ajout d’un compte utilisateur :



• Définir ses droits (ici je laisse tout cocher pour les tests et je lui donne les droits admin mais à ne pas faire dans la vraie vie) :



3.5. Tester l’accès SSH

La connexion SSH à Warpgate utilise le compte Warpgate et le nom de la cible, séparés par deux-points. Depuis un poste client, essayez la commande suivante en adaptant le compte :

ssh -p 2222 'fred:pve-nuc-ssh'@192.168.10.248



4. Deuxième exemple : accéder à l’interface Web Proxmox en HTTPS

4.1. Principe

Proxmox VE propose son interface d’administration Web en HTTPS, généralement sur le port 8006.

Nous allons déclarer cette interface comme une cible HTTP/HTTPS dans Warpgate. Le navigateur accédera à Warpgate, qui transmettra les requêtes vers le serveur Proxmox.

Étape	Source	Destination	Port
1	Navigateur Web	Warpgate — 192.168.10.248	TCP 8888
2	Warpgate	Proxmox — 192.168.10.250	TCP 8006

Le navigateur n’a donc pas besoin d’accéder directement au port 8006 du serveur Proxmox si le réseau est correctement cloisonné et si l’accès est exclusivement fourni par Warpgate.

4.2. Vérifier l’accès HTTPS depuis Warpgate

Depuis le serveur Warpgate, testez la connexion :

curl -kI https://pve-nuc.home.lan:8006/

L’option -k désactive la vérification du certificat TLS pour ce test uniquement. Elle permet de vérifier la connectivité même si Proxmox utilise un certificat autosigné ou une autorité interne non reconnue.

N’utilisez pas -k comme solution permanente de sécurité. La configuration de la cible Warpgate devra, de préférence, vérifier le certificat présenté par Proxmox.

Si la commande ne parvient pas à se connecter, vérifiez la résolution DNS, le pare-feu et l’état du service Web Proxmox.

4.3. Ajouter la cible HTTPS

Dans l’interface d’administration Warpgate, ouvrez la section de gestion des cibles et ajoutez une cible de type HTTP.



Paramètre	Valeur
Nom de la cible	pve-nuc-web
URL cible	https://pve-nuc.home.lan:8006
Mode TLS	Exiger TLS, si ce choix est disponible
Vérification du certificat	Activée si le certificat est reconnu par Warpgate

La documentation Warpgate prévoit un champ pour l’URL de destination, un réglage TLS et une option de vérification du certificat.

Si Proxmox utilise un certificat autosigné, il faudra soit faire reconnaître l’autorité de certification correspondante par le système et le mécanisme de vérification de Warpgate, soit adopter une configuration de certificat adaptée à votre environnement. Évitez de désactiver durablement la vérification TLS sans nécessité.

Enregistrez la cible.



4.4. Tester l’accès Web

Vérifiez que la cible apparaît dans l’accueil Warpgate et que le compte utilisé dispose de la permission correspondante.

Cliquez sur la cible Web depuis l’interface Warpgate. Le portail doit ouvrir l’interface Proxmox à travers le proxy Web.



Vous devriez retrouver l’écran de connexion habituel de Proxmox VE. L’authentification à Proxmox reste distincte de celle de Warpgate : l’accès au bastion ne remplace pas les comptes ni les permissions Proxmox.



Si l’interface ne s’affiche pas correctement, vérifiez :

• Que Warpgate atteint bien le port 8006.
• Que l’URL de destination utilise https://.
• Que le certificat présenté par Proxmox est accepté par la configuration TLS.
• Que la cible est accessible au compte Warpgate.
• Les journaux Warpgate, en recherchant l’erreur associée à la session.

4.5. Pourquoi conserver l’authentification Proxmox ?

Warpgate contrôle l’accès à la cible, mais ne doit pas être considéré comme un remplacement de l’authentification propre à Proxmox.

Il est recommandé de conserver les mécanismes de connexion Proxmox ou avec un système SSO comme Authelia et de limiter les privilèges des comptes utilisés. On obtient ainsi deux niveaux complémentaires : le contrôle d’accès au bastion, puis l’authentification et l’autorisation sur la plateforme d’administration.

5. Quelques bonnes pratiques de sécurité

Une fois les deux exemples fonctionnels, quelques précautions s’imposent :

• Ne pas exposer directement Proxmox sur Internet. Seul le point d’entrée prévu pour Warpgate doit être accessible depuis les réseaux autorisés.
• Placer Warpgate dans une DMZ ou une zone dédiée, avec des règles de pare-feu limitant les connexions vers les serveurs internes.
• Limiter les ports entrants aux seuls services nécessaires : interface Web et, si nécessaire, port SSH de Warpgate.
• Restreindre les flux sortants de Warpgate aux cibles et ports explicitement autorisés.
• Utiliser des comptes nominatifs et attribuer les permissions minimales nécessaires.
• Protéger les secrets et préférer les clés SSH lorsque cela convient.
• Sécuriser les certificats TLS, en particulier pour l’interface de Warpgate et les cibles HTTPS.
• Maintenir Warpgate et Debian à jour, en suivant les versions stables et les avis de sécurité officiels.
• Sauvegarder la configuration et les données de Warpgate, et tester la restauration.
• Examiner les journaux et les enregistrements de sessions selon les besoins d’audit et les règles de confidentialité applicables.

Un bastion améliore le contrôle des accès, mais il devient lui-même un composant critique. Il doit donc être surveillé, maintenu et sauvegardé comme tout autre service d’administration.

Conclusion

Warpgate permet de centraliser les accès à des systèmes internes tout en conservant une administration relativement simple. Son installation native sur Debian 13 est adaptée à ceux qui préfèrent gérer leurs services avec systemd plutôt que d’ajouter une couche de conteneurisation.

Avec ces deux premiers exemples, nous avons vu comment déclarer une cible SSH et une cible HTTPS vers Proxmox VE. Il reste ensuite à affiner les rôles, les permissions, la gestion des certificats et les règles réseau pour adapter le bastion à un environnement de production.

Pour aller plus loin, il sera intéressant d’étudier l’authentification multifacteur, les possibilités de fédération d’identité, la journalisation et les mécanismes de sauvegarde et de mise à jour.

Sources officielles

• Warpgate — site du projet
• Warpgate — installation et premiers pas
• Warpgate — service systemd
• Warpgate — cibles HTTP
• Warpgate — versions et notes de publication
• Apache Guacamole — documentation officielle

nb : merci à Jérémy pour la découverte de Warpgate ;-)