Pangolin SSH : accès SSH privé, RDP, bastion et provisioning

Pangolin commence souvent comme un reverse proxy Zero Trust pour des interfaces web.

Mais son intérêt ne s’arrête pas aux dashboards HTTP. L’accès SSH est probablement l’un des cas d’usage les plus intéressants, parce qu’il touche à une surface sensible : l’administration système.

Le mauvais réflexe classique reste d’ouvrir 22/tcp sur Internet, de limiter par firewall, puis d’espérer que Fail2ban, CrowdSec ou une configuration OpenSSH correcte suffisent. Ça peut fonctionner. Mais ce n’est pas toujours le modèle le plus propre, surtout quand plusieurs personnes doivent accéder à plusieurs machines.

Pangolin SSH propose une autre approche :

• ne pas exposer directement SSH sur Internet ;
• contrôler l’accès par identité, rôle et machine ;
• utiliser un tunnel Pangolin vers le réseau cible ;
• garder des ressources limitées, au lieu de donner accès à tout un LAN ;
• offrir soit un terminal web, soit un accès CLI classique.

Point important avant d’aller plus loin : d’après la documentation Pangolin consultée le 2 juillet 2026, les fonctionnalités SSH décrites ici sont disponibles avec Pangolin Cloud et Pangolin Enterprise Edition. En self-hosted Community Edition, il faut donc vérifier ce que votre instance expose réellement dans l’interface.

C’est la suite logique des deux premiers articles de la série :

• installation de Pangolin et premiers sites Newt ;
• exposition d’une interface sensible derrière le SSO ;
• puis maintenant : accès shell, bastion, OpenSSH et provisioning.

L’objectif n’est pas de refaire la documentation Pangolin. L’objectif est de poser une architecture exploitable, avec les choix qui évitent de transformer un bon outil d’accès en nouveau point faible.

En bref

#

• Pangolin SSH sert à donner accès à des shells distants sans publier directement 22/tcp.
• Il existe deux familles : SSH public dans le navigateur et SSH privé via pangolin ssh.
• Pangolin peut aussi exposer du RDP public dans le navigateur, utile pour Windows mais à traiter comme une console d’administration.
• L’accès privé nécessite un client Pangolin connecté sur le poste utilisateur.
• L’accès public expose un FQDN, mais l’utilisateur passe d’abord par l’authentification Pangolin.
• Deux modes existent côté ressource : Pangolin SSH et Standard SSH Server.
• Le mode Pangolin SSH est le plus simple, mais Newt doit tourner en binaire sur l’hôte cible, avec les droits root.
• Le mode Standard SSH Server route vers OpenSSH, avec ou sans provisioning automatisé.
• Pour une ressource privée SSH, il faut autoriser TCP 22 dans les restrictions de ports.
• Le provisioning automatisé repose sur des certificats SSH temporaires et un auth daemon.
• Ce n’est pas un remplacement complet d’un accès d’urgence hors bande.

Prérequis réalistes

#

Avant de configurer SSH ou RDP dans Pangolin, il faut déjà avoir une base saine :

• une instance Pangolin fonctionnelle ;
• au moins un site Newt connecté ;
• un nom de domaine si vous utilisez une ressource SSH publique ;
• un client Pangolin pour les accès privés ;
• une politique MFA claire pour les comptes administrateurs ;
• une méthode d’accès de secours hors Pangolin.

Pour les exemples, je pars sur cette topologie :

Pangolin public: https://pangolin.example.com
Site Newt: homelab
Bastion interne: 10.10.10.10
Serveur applicatif: 10.10.20.11
Serveur base de données: 10.10.30.21
Domaine d'alias: infra.internal

Le domaine infra.internal est volontairement utilisé comme alias privé Pangolin. Il n’a pas besoin d’exister dans le DNS public.

Décider vite

#

Le choix dépend moins de Pangolin que de votre modèle d’exploitation.

Mon choix par défaut pour une infra perso ou une petite équipe : ressources privées SSH en Standard SSH Server avec authentification manuelle, puis passage au provisioning automatisé seulement quand le besoin est réel.

Ce n’est pas le modèle le plus sophistiqué. C’est souvent le plus fiable pour commencer.

Mon choix recommandé

#

Si je devais déployer ça proprement demain sur une petite infra, je partirais sur ce modèle :

Pangolin
  -> site Newt sur un bastion interne
  -> ressources privées par hôte
  -> TCP 22 pour Linux
  -> TCP 3389 pour Windows
  -> accès par groupes
  -> MFA pour les comptes admin

Concrètement :

• SSH Linux : Standard SSH Server + authentification manuelle au départ ;
• RDP Windows : ressource privée TCP 3389, client RDP local côté admin ;
• accès navigateur : uniquement pour les besoins ponctuels ou support ;
• provisioning automatisé : seulement après un pilote réussi ;
• port SSH/RDP public : fermé, sauf exception temporaire documentée.

Là où Pangolin m’intéresse, ce n’est pas de remplacer SSH ou RDP. C’est de retirer SSH et RDP d’Internet sans retomber dans un VPN plat où tout le monde voit tout.

Pangolin remplace quoi ?

#

La réponse courte : ça dépend de ce que vous appelez bastion, Guacamole ou PAM.

Pangolin peut remplacer un bastion SSH classique dans beaucoup de scénarios. Il peut aussi couvrir une partie des usages d’Apache Guacamole, notamment l’accès SSH/RDP depuis un navigateur. Par contre, il ne remplace pas une plateforme PAM complète comme CyberArk.

La formulation saine est donc :

Pangolin peut remplacer un bastion SSH classique et couvrir certains usages de Guacamole pour SSH/RDP. Il ne remplace pas une plateforme PAM complète comme CyberArk.

Cette nuance est importante. Un bastion répond surtout à la question : “par où passe l’accès ?”. Un PAM répond à une question plus large : “qui possède quel privilège, pendant combien de temps, avec quels secrets, quelle rotation, quelle approbation, quelle traçabilité et quelle révocation ?”.

Pangolin se place très bien dans la première catégorie, et commence à toucher certains usages de la seconde avec l’identité, les règles d’accès et le provisioning. Mais il ne couvre pas à lui seul toute la gouvernance des privilèges.

Le problème opérationnel

#

SSH est rarement un simple service applicatif.

Un accès SSH donne souvent accès à :

• des fichiers de configuration ;
• des secrets applicatifs ;
• des sockets locaux ;
• des volumes Docker ;
• des clés de déploiement ;
• parfois sudo, directement ou indirectement.

Publier OpenSSH sur Internet n’est pas automatiquement une erreur. Avec une configuration sérieuse, des clés robustes, PasswordAuthentication no, des logs surveillés et un firewall propre, c’est exploitable.

Mais en pratique, le sujet devient pénible quand :

• plusieurs administrateurs doivent accéder à plusieurs hôtes ;
• les clés SSH traînent longtemps ;
• les comptes locaux ne sont plus alignés avec les départs et arrivées ;
• les machines sont derrière des NAT ou des liens résidentiels ;
• on veut auditer les accès par identité humaine plutôt que par clé copiée il y a deux ans.

Pangolin SSH répond à ce problème par une couche d’accès contrôlée avant la session shell.

Mais il faut garder une nuance : Pangolin ne rend pas un mauvais modèle SSH automatiquement propre.

Si les comptes locaux sont partagés, si root reste accessible partout, si les groupes sudo sont trop larges, ou si tout le LAN est exposé en ressource privée, on déplace le problème. On ne le corrige pas.

Architecture générale

#

Le modèle ressemble à ceci :

Utilisateur
  -> Pangolin client ou navigateur
  -> contrôle d'accès Pangolin
  -> tunnel vers un site Newt
  -> hôte SSH cible

Une version plus proche du terrain :

Admin avec client Pangolin
  -> accès privé
  -> Pangolin
  -> site Newt
  -> serveur Linux:22, poste Windows:3389 ou interface interne HTTPS

Navigateur web
  -> accès public
  -> Pangolin
  -> site Newt
  -> serveur Linux:22, poste Windows:3389 ou interface interne HTTPS

Le chemin privé sert aux administrateurs qui travaillent depuis leur poste outillé.

Le chemin public sert plutôt aux accès ponctuels dans le navigateur : SSH public, RDP public, interface web interne. Les deux chemins peuvent coexister, mais ils ne doivent pas donner les mêmes droits par défaut.

Le point important est la séparation entre :

• le serveur Pangolin, qui porte le contrôle d’accès ;
• le site Newt, qui donne un chemin vers le réseau ou l’hôte cible ;
• la ressource, qui décrit précisément ce que l’utilisateur peut atteindre.

Dans une configuration propre, on ne donne pas accès à 10.0.0.0/24 juste pour administrer app-01. On crée une ressource ciblée, avec un alias lisible et uniquement le port nécessaire.

Exemple :

Resource: app-01
Destination: 10.10.20.11
Alias: app-01.infra.internal
TCP: 22 uniquement
UDP: bloqué
ICMP: selon besoin

La cible déclarée dans Pangolin doit être joignable depuis le site sélectionné. C’est un détail qui explique beaucoup de pannes :

• si Newt tourne sur le même hôte que le service, 127.0.0.1:22 peut avoir du sens ;
• si Newt tourne sur un bastion, il faut utiliser l’IP ou le FQDN joignable depuis ce bastion ;
• si deux sites ont les mêmes plages RFC1918, les alias deviennent indispensables pour éviter les ambiguïtés.

SSH public, SSH privé, et le cas RDP

#

Pangolin distingue deux usages.

SSH public

#

Avec une ressource SSH publique, l’utilisateur ouvre un FQDN dans son navigateur.

Exemple :

https://ssh-app-01.example.com

Animation officielle Pangolin montrant une session SSH publique dans le navigateur.

Le flux est généralement :

1. l’utilisateur ouvre l’URL ;
2. Pangolin applique l’authentification publique : login, SSO, MFA, règles d’accès ;
3. selon le mode choisi, l’utilisateur fournit ses identifiants SSH ou Pangolin provisionne l’accès ;
4. le terminal est rendu dans le navigateur.

C’est pratique pour des accès ponctuels, des environnements support, ou des utilisateurs qui n’ont pas de client SSH correctement configuré.

Mais c’est aussi une interface d’administration accessible par URL. Elle doit donc être traitée comme une ressource sensible :

• MFA obligatoire ;
• accès limité à un groupe réduit ;
• pas de règle publique trop large ;
• journalisation activée ;
• nom de domaine discret, sans compter uniquement sur l’obscurité.

SSH privé

#

Avec une ressource SSH privée, l’utilisateur passe par le client Pangolin puis lance une commande locale :

pangolin ssh app-01.infra.internal

Le flux est différent :

1. le client Pangolin est connecté sur le poste utilisateur ;
2. l’alias est résolu dans l’environnement Pangolin ;
3. Pangolin vérifie les règles d’accès privées ;
4. la session SSH passe dans le tunnel ;
5. le shell s’ouvre depuis le terminal local.

C’est généralement le modèle le plus naturel pour des administrateurs système ou des développeurs qui travaillent déjà dans un terminal.

À retenir : pour une ressource SSH privée, l’alias est important. Il évite de manipuler des IP internes, il aide avec les réseaux qui se chevauchent, et il permet de cibler proprement une machine.

Et RDP dans tout ça ?

#

RDP mérite d’être mentionné ici, même si ce n’est pas SSH.

Le problème opérationnel est proche : on parle d’un accès d’administration interactif, souvent très privilégié, qui ne devrait pas être exposé directement sur Internet.

Pangolin documente les ressources RDP publiques : l’utilisateur ouvre un FQDN dans son navigateur, passe l’authentification Pangolin, puis obtient une session Remote Desktop rendue dans le navigateur. Les identifiants Windows sont saisis ensuite dans le client RDP web.

Exemple :

https://rdp-admin-01.example.com

Animation officielle Pangolin montrant une session RDP publique dans le navigateur.

Le flux ressemble à ceci :

Navigateur
  -> authentification Pangolin
  -> ressource RDP publique
  -> site Newt
  -> hôte Windows:3389

C’est pratique pour accéder à une machine Windows sans installer de client RDP local. Mais le niveau de risque est comparable à une console d’administration :

• MFA obligatoire ;
• accès par rôle strict ;
• ressource dédiée par machine sensible ;
• pas de compte Windows partagé ;
• journalisation côté Pangolin et côté Windows ;
• désactivation de la ressource si elle n’est plus utilisée.

Pour un accès RDP privé, je raisonnerais différemment : créer une ressource privée TCP vers l’hôte Windows, autoriser uniquement 3389/tcp, puis utiliser un client RDP natif depuis un poste connecté au client Pangolin.

Exemple de ressource privée :

Resource: win-admin-01
Destination: 10.10.40.15
Alias: win-admin-01.infra.internal
TCP: 3389 uniquement
UDP: bloqué, sauf besoin RDP explicite et testé

Connexion depuis un poste Linux avec FreeRDP, une fois le client Pangolin connecté :

xfreerdp /v:win-admin-01.infra.internal /u:administrateur

Depuis Windows ou macOS, le principe est le même : le client RDP local cible l’alias privé Pangolin, pas une IP publique.

La règle reste la même que pour SSH : éviter de transformer Pangolin en VPN plat. Une ressource RDP doit pointer vers une machine précise, avec le minimum de ports nécessaires.

Les deux modes SSH

#

La partie qui prête le plus à confusion est le choix du mode.

Pangolin propose deux modes principaux.

Mode Pangolin SSH

#

Le mode Pangolin SSH exécute la session directement via le connecteur de site.

Dans ce mode :

• on ne configure pas un backend host:port ;
• Newt doit tourner sur la machine à administrer ;
• Newt doit tourner en root ;
• l’installation Newt en conteneur n’est pas adaptée à ce cas.

La raison est simple : si Newt tourne dans Docker, une session shell risque de tomber dans le conteneur, pas sur l’hôte.

Ce mode est intéressant pour un petit serveur, un VPS ou une machine isolée où l’on accepte d’exécuter Newt comme service système.

Je ne l’utiliserais pas comme modèle unique pour toute une flotte. Dès qu’il y a plusieurs serveurs derrière un même réseau, un bastion Newt qui route vers OpenSSH est généralement plus lisible.

Mode Standard SSH Server

#

Le mode Standard SSH Server route vers un serveur SSH existant, souvent OpenSSH.

Dans ce mode, Pangolin agit comme une couche d’accès et de routage, mais la cible reste un service SSH réseau.

Exemples :

127.0.0.1:22
10.10.20.11:22
app-01.internal:22

C’est le mode le plus flexible dès qu’on a :

• un bastion Newt ;
• plusieurs hôtes derrière le même site ;
• une configuration OpenSSH déjà en place ;
• des serveurs où l’on ne veut pas installer Newt directement.

Il a aussi un avantage de rollback : si Pangolin est indisponible, OpenSSH reste OpenSSH. On peut conserver un accès d’urgence contrôlé par VPN classique, console provider, IP allowlist temporaire, ou bastion séparé.

Authentification manuelle ou provisioning automatisé

#

Deux modèles d’authentification existent.

Authentification manuelle

#

L’authentification manuelle garde les comptes SSH existants.

Pour une ressource publique, l’utilisateur passe d’abord l’auth Pangolin, puis saisit un identifiant SSH ou fournit une clé dans le navigateur.

Pour une ressource privée, l’utilisateur peut faire :

pangolin ssh admin@app-01.infra.internal

Ou utiliser une clé privée :

pangolin ssh admin@app-01.infra.internal -i ~/.ssh/id_ed25519

Ce modèle est simple et peu intrusif. Il ne demande pas de modifier PAM ou OpenSSH si l’authentification locale existe déjà.

En contrepartie, il ne règle pas tout :

• les comptes locaux restent à maintenir ;
• les clés SSH longues durées existent toujours ;
• les droits sudo restent gérés côté système ;
• le départ d’un utilisateur doit être traité dans Pangolin et sur les hôtes.

Provisioning automatisé

#

Le provisioning automatisé est plus ambitieux.

L’idée est de partir de l’identité Pangolin et de créer l’accès local juste à temps. Pangolin peut signer une clé temporaire, créer ou préparer le compte local, gérer les groupes et éventuellement des droits sudo selon la configuration.

Dans le mode Standard SSH Server, ce mécanisme repose sur :

• une autorité de certification SSH côté organisation Pangolin ;
• un certificat SSH temporaire ;
• une configuration OpenSSH qui fait confiance à cette CA ;
• un auth daemon capable de résoudre les principals autorisés.

La documentation Pangolin indique que le certificat temporaire est valable 5 minutes pour démarrer la connexion. Une fois la session ouverte, elle peut continuer.

Ce modèle réduit fortement la gestion de clés statiques, mais il ajoute de la complexité. Il faut tester calmement avant de le mettre sur des serveurs de production.

La bonne question n’est donc pas “est-ce plus moderne ?”. La bonne question est :

• combien d’utilisateurs doivent être révoqués proprement ?
• combien de serveurs portent des clés longues durées ?
• qui maintient les comptes locaux ?
• combien de temps faut-il pour retirer un accès aujourd’hui ?
• les logs permettent-ils de relier une session SSH à une identité humaine ?

Si ces réponses sont mauvaises, le provisioning automatisé mérite d’être étudié.

Exemple 1 : accès privé simple vers un serveur OpenSSH

#

Objectif :

• ne pas exposer 22/tcp sur Internet ;
• garder les comptes SSH existants ;
• se connecter depuis son terminal ;
• utiliser Newt comme chemin réseau vers le serveur.

Hypothèse :

Pangolin: https://pangolin.example.com
Site Newt: homelab
Serveur SSH: 10.10.20.11
Alias: app-01.infra.internal
Port SSH: 22

Dans Pangolin :

1. créer une ressource privée ;
2. destination : 10.10.20.11 ;
3. alias : app-01.infra.internal ;
4. site : homelab ;
5. TCP : mode custom, port 22 ;
6. UDP : bloqué ;
7. SSH mode : Standard SSH Server ;
8. backend : 10.10.20.11:22 ;
9. authentication : Manual Authentication ;
10. accès : groupe admins ou utilisateurs explicites.

Côté poste administrateur :

pangolin login
pangolin up
pangolin ssh admin@app-01.infra.internal

Avec une clé dédiée :

pangolin ssh admin@app-01.infra.internal -i ~/.ssh/id_ed25519_pangolin

Vérifications utiles côté serveur cible :

sudo systemctl status ssh
sudo ss -tulpn | grep ':22'
sudo journalctl -u ssh --since "10 minutes ago"

Vérification côté exposition Internet :

nc -vz app-01.example.com 22

Dans ce modèle, ce test doit échouer si app-01.example.com pointe vers une adresse publique où SSH n’est pas publié. L’accès attendu passe par Pangolin, pas par un port SSH exposé.

Variante avec alias par environnement

#

Les alias deviennent vite utiles quand on sépare les environnements :

app-01.dev.infra.internal
app-01.staging.infra.internal
app-01.prod.infra.internal

Ça évite les commandes ambiguës et ça rend les logs plus lisibles. Une session vers app-01.prod.infra.internal ne raconte pas la même chose qu’une session vers app-01.dev.infra.internal.

Dans Pangolin, je préfère aussi séparer les ressources plutôt que de créer un seul CIDR large :

Ce découpage demande quelques minutes de plus, mais il évite de donner la production à tous ceux qui avaient seulement besoin du staging.

Exemple 2 : terminal SSH dans le navigateur

#

Objectif :

• donner un accès ponctuel via navigateur ;
• ne pas demander au poste utilisateur d’avoir un client Pangolin ;
• garder l’authentification Pangolin devant le terminal.

Hypothèse :

FQDN public: ssh-app-01.example.com
Site Newt: homelab
Backend SSH: 10.10.20.11:22
Mode: Standard SSH Server
Authentification: Manual Authentication

Dans Pangolin :

1. créer une ressource publique de type SSH ;
2. FQDN : ssh-app-01.example.com ;
3. site : homelab ;
4. mode SSH : Standard SSH Server ;
5. backend : 10.10.20.11:22 ;
6. authentication : Manual Authentication ;
7. imposer MFA sur la ressource ou sur le groupe ;
8. limiter l’accès à un rôle précis.

L’utilisateur ouvre ensuite :

https://ssh-app-01.example.com

Puis :

• il s’authentifie auprès de Pangolin ;
• il saisit son compte SSH local ou fournit sa clé ;
• le terminal s’affiche dans le navigateur.

Ce mode est pratique, mais il ne doit pas devenir une console d’administration générale exposée à tout le monde. Il faut regarder les logs et les règles d’accès avec la même rigueur que pour un bastion SSH.

Pour un accès de support temporaire, je préfère créer une ressource dédiée plutôt que de réutiliser une ressource admin permanente.

Exemple :

ssh-support-app-01.example.com

Puis :

• accès accordé uniquement au groupe support-temp ;
• MFA obligatoire ;
• durée documentée dans un ticket ;
• suppression ou désactivation de la ressource après intervention.

Le point important : un terminal web est confortable. Justement pour cette raison, il ne faut pas le laisser traîner comme raccourci permanent.

Exemple 3 : Newt sur l’hôte, mode Pangolin SSH

#

Objectif :

• accéder à un serveur unique ;
• éviter une configuration OpenSSH spécifique ;
• utiliser le mode Pangolin SSH recommandé par Pangolin pour ce cas.

Dans ce scénario, Newt doit être installé comme binaire sur l’hôte.

Installation rapide de Newt :

curl -fsSL https://static.pangolin.net/get-newt.sh | bash

Créer un fichier d’environnement :

sudo install -d -m 0755 /etc/newt
sudo editor /etc/newt/newt.env
sudo chmod 600 /etc/newt/newt.env

Exemple de contenu :

NEWT_ID=remplacer_par_id
NEWT_SECRET=remplacer_par_secret
PANGOLIN_ENDPOINT=https://pangolin.example.com

Service systemd :

[Unit]
Description=Newt
Wants=network-online.target
After=network-online.target

[Service]
Type=simple
User=root
Group=root
EnvironmentFile=/etc/newt/newt.env
ExecStart=/usr/local/bin/newt
Restart=always
RestartSec=2
UMask=0077
PrivateTmp=true

[Install]
WantedBy=multi-user.target

Activation :

sudo systemctl daemon-reload
sudo systemctl enable --now newt
sudo systemctl status newt

Dans Pangolin :

1. créer une ressource SSH ;
2. choisir le site correspondant ;
3. mode : Pangolin SSH ;
4. authentication : Manual Authentication ou Automated Provisioning ;
5. accorder l’accès uniquement aux utilisateurs ou rôles nécessaires.

Connexion privée :

pangolin ssh admin@server-01.infra.internal

Ce modèle est simple, mais il a une contrainte forte : Newt tourne en root sur l’hôte. C’est acceptable dans certains contextes, moins dans d’autres. Il faut l’assumer comme un composant d’accès privilégié.

Vérifications utiles :

which newt
sudo systemctl status newt
sudo journalctl -u newt --since "30 minutes ago"

Si la ressource apparaît hors ligne côté Pangolin, commencez par vérifier Newt avant de modifier la ressource SSH. Dans la majorité des pannes, le problème vient du site, du secret, de l’endpoint ou de la connectivité sortante.

Exemple 4 : bastion Newt et plusieurs serveurs SSH

#

Objectif :

• installer Newt sur un bastion interne ;
• accéder à plusieurs serveurs via OpenSSH ;
• éviter d’installer Newt sur chaque hôte ;
• centraliser le chemin d’accès.

Architecture :

Poste admin
  -> Pangolin client
  -> site Newt sur bastion
  -> app-01:22
  -> app-02:22
  -> db-01:22

Dans ce scénario, Newt peut tourner dans Docker, parce qu’on n’utilise pas le mode Pangolin SSH pour exécuter une session sur l’hôte du connecteur. Newt sert ici de chemin réseau vers des serveurs OpenSSH.

Exemple de Compose minimal :

services:
  newt:
    image: fosrl/newt:latest
    container_name: newt
    restart: unless-stopped
    environment:
      - PANGOLIN_ENDPOINT=${PANGOLIN_ENDPOINT}
      - NEWT_ID=${NEWT_ID}
      - NEWT_SECRET=${NEWT_SECRET}

Le fichier .env correspondant :

PANGOLIN_ENDPOINT=https://pangolin.example.com
NEWT_ID=remplacer_par_id
NEWT_SECRET=remplacer_par_secret

Pour un déploiement durable, je recommande de remplacer latest par un tag explicite dès que vous avez validé la version. Le secret Newt ne doit pas être commité dans Git.

Ressources privées :

Connexion :

pangolin ssh admin@app-01.infra.internal
pangolin ssh admin@app-02.infra.internal
pangolin ssh admin@db-01.infra.internal

Dans ce modèle, le bastion doit pouvoir joindre les hôtes cibles sur 22/tcp, mais ces hôtes n’ont pas besoin d’exposer SSH vers Internet.

Vérifier depuis le bastion :

nc -vz 10.10.20.11 22
nc -vz 10.10.20.12 22
nc -vz 10.10.30.21 22

Vérifier les routes et l’écoute SSH :

ip route
sudo ss -tulpn | grep ':22'

Vérifier que le conteneur Newt ne publie pas de port inutile :

docker ps --format "table {{.Names}}\t{{.Ports}}"

Dans ce cas précis, l’absence de mapping ports: est attendue. Newt établit une connexion sortante vers Pangolin, il n’a pas besoin d’exposer un port d’administration sur l’hôte.

Exemple 5 : provisioning automatisé avec OpenSSH

#

Ce scénario est plus avancé.

Objectif :

• éviter la distribution de clés SSH longues durées ;
• mapper l’identité Pangolin vers des comptes locaux ;
• utiliser des certificats SSH temporaires ;
• garder OpenSSH comme serveur SSH.

Il faut modifier la configuration SSH des hôtes cibles. Avant de faire ça sur un serveur distant, gardez toujours une session de secours ouverte. Une erreur dans sshd_config peut couper l’accès.

Exemple de configuration OpenSSH avec auth daemon local via Newt :

TrustedUserCAKeys /etc/ssh/ca.pem
AuthorizedPrincipalsCommand /usr/local/bin/newt auth-daemon principals --username %u
AuthorizedPrincipalsCommandUser root

Exemple avec auth daemon séparé sur l’hôte cible :

TrustedUserCAKeys /etc/ssh/ca.pem
AuthorizedPrincipalsCommand /usr/local/bin/pangolin auth-daemon principals --username %u
AuthorizedPrincipalsCommandUser root

Avant de redémarrer SSH, tester la configuration :

sudo sshd -t

Puis seulement si le test est bon :

sudo systemctl restart ssh

Pour un auth daemon externe, exemple de service systemd :

[Unit]
Description=Pangolin SSH auth daemon
After=network.target

[Service]
ExecStart=/usr/local/bin/pangolin auth-daemon --pre-shared-key remplacer_par_un_secret_fort
Restart=always
User=root

[Install]
WantedBy=multi-user.target

Activation :

sudo systemctl daemon-reload
sudo systemctl enable --now pangolin-auth-daemon
sudo systemctl status pangolin-auth-daemon

Le port par défaut de l’auth daemon externe est 22123/tcp. Il doit être joignable entre Newt et les hôtes cibles, pas depuis Internet.

Vérification depuis le bastion Newt :

nc -vz 10.10.20.11 22123

Ce modèle est puissant, mais il mérite une phase de test sur une machine non critique. On touche à SSH, PAM, aux comptes locaux et potentiellement à sudo.

Points à vérifier avant production

#

Avant d’étendre ce modèle, je vérifierais au minimum :

• le nom exact des utilisateurs créés ;
• les groupes attribués ;
• les droits sudo ;
• la durée de validité des certificats ;
• la révocation d’un utilisateur côté Pangolin ;
• le comportement si l’auth daemon est arrêté ;
• les logs produits côté Pangolin et côté sshd.

Scénario de test simple :

1. créer un utilisateur Pangolin de test ;
2. lui accorder l’accès à une seule ressource non critique ;
3. ouvrir une session SSH ;
4. vérifier le compte local créé ;
5. retirer l’accès dans Pangolin ;
6. retenter une nouvelle session ;
7. inspecter les logs.

Commandes utiles côté hôte :

id utilisateur_test
getent passwd utilisateur_test
groups utilisateur_test
sudo journalctl -u ssh --since "15 minutes ago"
sudo journalctl -u pangolin-auth-daemon --since "15 minutes ago"

Si ce test n’est pas compris et reproductible, il est trop tôt pour activer le provisioning sur des machines sensibles.

Exemple 6 : RDP privé vers une machine Windows

#

Objectif :

• accéder à une machine Windows sans exposer 3389/tcp sur Internet ;
• garder un client RDP natif côté administrateur ;
• passer par Pangolin pour l’identité, le tunnel et les règles d’accès ;
• limiter la ressource à une seule machine.

Hypothèse :

Machine Windows: 10.10.40.15
Alias Pangolin: win-admin-01.infra.internal
Port RDP: 3389/tcp
Site Newt: homelab
Groupe Pangolin: windows-admins

Dans Pangolin :

1. créer une ressource privée ;
2. destination : 10.10.40.15 ;
3. alias : win-admin-01.infra.internal ;
4. site : homelab ;
5. TCP : mode custom, port 3389 ;
6. UDP : bloqué au départ ;
7. accès : groupe windows-admins.

Pourquoi bloquer UDP au départ ? RDP peut utiliser UDP dans certains cas pour améliorer l’expérience, mais TCP suffit pour valider le chemin et réduire la surface initiale. Si l’expérience utilisateur impose UDP, il faut l’ouvrir explicitement, tester, et le documenter.

Côté Windows, vérifier que RDP est activé et que l’utilisateur est autorisé. Microsoft rappelle que Remote Desktop ouvre un port sur la machine et que seuls les comptes autorisés peuvent se connecter. En pratique, je veux voir des comptes nominatifs, pas un compte partagé.

Vérifier l’état RDP :

Get-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server' -Name fDenyTSConnections

Valeur attendue :

fDenyTSConnections : 0

Vérifier le service :

Get-Service TermService

Vérifier le port local :

Get-NetTCPConnection -LocalPort 3389 -State Listen

Vérifier les utilisateurs autorisés :

Get-LocalGroupMember "Remote Desktop Users"
Get-LocalGroupMember "Administrators"

Ajouter un utilisateur au groupe RDP si nécessaire :

Add-LocalGroupMember -Group "Remote Desktop Users" -Member "EXAMPLE\alice"

Cette commande modifie les droits locaux. Elle doit être utilisée volontairement, idéalement avec un compte de domaine ou un compte local nominatif.

Vérifier Network Level Authentication :

Get-ItemProperty -Path 'HKLM:\System\CurrentControlSet\Control\Terminal Server\WinStations\RDP-Tcp' -Name UserAuthentication

Valeur attendue :

UserAuthentication : 1

Microsoft recommande de garder NLA activé dans la plupart des environnements, car l’utilisateur doit s’authentifier avant l’établissement complet de la session distante.

Depuis le bastion Newt, vérifier la connectivité interne :

nc -vz 10.10.40.15 3389

Depuis le poste administrateur connecté à Pangolin, utiliser ensuite le client RDP local :

xfreerdp /v:win-admin-01.infra.internal /u:EXAMPLE\\alice

Sur Windows, la même logique s’applique avec le client Remote Desktop : ciblez win-admin-01.infra.internal, pas une IP publique.

Après connexion, regarder les événements côté Windows :

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=(Get-Date).AddHours(-2)} |
  Select-Object TimeCreated, Id, ProviderName, Message -First 10

Et les échecs :

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-2)} |
  Select-Object TimeCreated, Id, ProviderName, Message -First 10

Le point clé : Pangolin contrôle le chemin et l’accès à la ressource, mais Windows garde sa propre sécurité locale. Les deux doivent être cohérents.

Durcir OpenSSH derrière Pangolin

#

Pangolin réduit l’exposition réseau, mais OpenSSH reste un composant critique.

Si vous gardez une authentification SSH manuelle par clé, une base raisonnable ressemble à ceci :

PermitRootLogin no
PasswordAuthentication no
PubkeyAuthentication yes
KbdInteractiveAuthentication no
X11Forwarding no
AllowTcpForwarding no
AllowAgentForwarding no
AllowGroups ssh-admins

Ce bloc n’est pas universel.

Par exemple :

• si vous utilisez encore des mots de passe SSH, PasswordAuthentication no va les bloquer ;
• si certains utilisateurs ont besoin de tunnels SSH, AllowTcpForwarding no va les casser ;
• si vous utilisez SFTP pour un workflow précis, il faut tester le comportement attendu.

La règle pratique : durcir en fonction des usages réels, pas copier une configuration sans comprendre.

Avant redémarrage :

sudo sshd -t

Puis :

sudo systemctl reload ssh

Selon la distribution, le service peut s’appeler ssh ou sshd :

systemctl status ssh
systemctl status sshd

Pour les certificats SSH, les directives importantes sont :

• TrustedUserCAKeys, qui indique à OpenSSH quelle CA utilisateur accepter ;
• AuthorizedPrincipalsCommand, qui génère la liste des principals autorisés ;
• AuthorizedPrincipalsCommandUser, obligatoire quand un command est configuré.

La documentation OpenSSH précise aussi que ces commandes doivent être appelées via un chemin absolu, être possédées par root et ne pas être modifiables par groupe ou autres. C’est un détail important : si ce binaire ou son chemin est modifiable par un utilisateur non privilégié, vous affaiblissez l’authentification.

Vérifier les permissions :

ls -l /usr/local/bin/newt /usr/local/bin/pangolin
ls -ld /usr/local/bin
ls -l /etc/ssh/ca.pem

Plan de migration sans se couper l’accès

#

La migration vers Pangolin SSH doit être progressive.

Je ferais dans cet ordre :

1. garder l’accès SSH actuel ;
2. installer ou vérifier Newt ;
3. créer une ressource privée pour un seul hôte non critique ;
4. tester pangolin ssh avec un compte existant ;
5. valider les logs Pangolin et sshd ;
6. limiter le firewall public de l’hôte ;
7. tester une nouvelle connexion depuis l’extérieur ;
8. documenter l’accès de secours ;
9. répéter hôte par hôte.

Exemple de vérification avant fermeture du port public :

pangolin ssh admin@app-01.infra.internal
sudo journalctl -u ssh --since "5 minutes ago"

Ensuite seulement, limiter l’exposition.

Avec UFW, par exemple, il faut adapter à votre contexte avant d’appliquer :

sudo ufw status numbered

Je n’inclus pas de commande de suppression de règle volontairement. Fermer SSH à distance sans console de secours est une façon classique de perdre l’accès à une machine.

Limites à connaître

#

Pangolin apporte une couche d’accès très utile, mais il faut rester clair sur ses limites.

Ce que Pangolin fait bien

#

• publier des ressources web derrière une authentification ;
• donner un accès SSH/RDP sans exposer directement les ports ;
• relier des réseaux privés via Newt ;
• appliquer des règles par utilisateur, rôle et machine ;
• éviter le VPN plat pour beaucoup d’usages ;
• fournir une expérience navigateur pour certains accès.

Ce que Pangolin ne remplace pas seul

#

• un coffre-fort de secrets ;
• la rotation automatique des mots de passe locaux ;
• une politique PAM complète ;
• une gouvernance d’identités complète ;
• la revue périodique des droits ;
• la journalisation système côté Linux et Windows ;
• un accès d’urgence hors bande.

Les points de dépendance

#

Il faut aussi accepter quelques dépendances :

• le serveur Pangolin doit être disponible ;
• le site Newt doit être connecté ;
• le client Pangolin est nécessaire pour les ressources privées ;
• les alias privés dépendent de la résolution côté client ;
• les ressources publiques doivent être protégées comme des interfaces d’administration ;
• le provisioning automatisé ajoute une dépendance à l’auth daemon et à la configuration OpenSSH.

Ce n’est pas bloquant. C’est simplement de l’exploitation normale : chaque brique critique doit être surveillée, documentée et testée.

Installer le client Pangolin

#

Pour les accès privés, l’utilisateur doit disposer du client Pangolin.

Sur Linux ou macOS, la documentation propose l’installation rapide de la CLI :

curl -fsSL https://static.pangolin.net/get-cli.sh | bash

Connexion :

pangolin login
pangolin up

Puis session SSH :

pangolin ssh app-01.infra.internal

Sur Windows, la CLI peut être utilisée pour SSH, mais la fonctionnalité VPN CLI n’est pas supportée de la même manière. Le cas courant consiste à utiliser le client graphique Windows pour le tunnel et la CLI pour la commande SSH.

Règles d’accès recommandées

#

Pour SSH et RDP, je partirais sur une politique stricte :

• accès par rôles, pas par utilisateurs isolés quand l’organisation grandit ;
• MFA obligatoire pour tout accès public ;
• pas d’accès SSH public pour les comptes sans besoin réel ;
• pas d’accès RDP public permanent sans justification ;
• ressources privées séparées par machine ou par rôle ;
• port 22/tcp pour SSH, 3389/tcp pour RDP, pas All TCP par confort ;
• UDP bloqué sauf besoin explicite ;
• alias lisibles, avec un domaine interne cohérent ;
• logs Pangolin conservés assez longtemps pour investiguer ;
• comptes de secours hors Pangolin documentés et protégés.

Exemple de découpage :

Le piège serait de recréer un VPN plat sous une autre forme. Si tout le monde peut atteindre tous les ports de tous les serveurs, Pangolin n’apporte pas grand-chose côté segmentation.

Vérifier son exposition

#

Depuis Internet, les ports SSH et RDP des serveurs internes ne doivent normalement pas répondre.

Depuis une machine externe :

nc -vz server.example.com 22
nc -vz win-admin-01.example.com 3389

Depuis le serveur Pangolin ou le bastion Newt, vérifier uniquement ce qui doit être joignable :

nc -vz 10.10.20.11 22
nc -vz 10.10.40.15 3389

Vérifier les ports publiés par Docker si Newt est conteneurisé pour d’autres usages :

docker ps --format "table {{.Names}}\t{{.Ports}}"

Vérifier les sockets locaux :

sudo ss -tulpn

Vérifier le firewall :

sudo nft list ruleset

Ou sur une machine encore basée sur UFW :

sudo ufw status verbose

L’objectif est simple : SSH et RDP doivent être accessibles depuis le bon chemin, pas depuis partout.

Détection et audit

#

Pangolin ajoute une couche d’audit utile, mais il ne remplace pas les logs système.

Côté Pangolin, il faut regarder :

• les logs d’authentification ;
• les logs réseau pour les ressources privées ;
• les événements d’administration ;
• les changements de règles d’accès ;
• les connexions refusées.

Côté hôte Linux :

sudo journalctl -u ssh --since "24 hours ago"

Sur Debian et Ubuntu, selon la configuration :

sudo grep sshd /var/log/auth.log

Lister les connexions en cours :

w
who

Afficher les dernières connexions :

last -a | head -30

Contrôler les comptes locaux créés ou utilisés :

getent passwd
getent group sudo

Si le provisioning automatisé est activé, il faut surveiller la création de comptes et les droits associés. Un accès SSH qui marche techniquement mais donne trop de privilèges reste un problème.

Pour RDP, il faut aussi regarder côté Windows. Quelques commandes PowerShell utiles :

Get-LocalUser
Get-LocalGroupMember "Remote Desktop Users"
Get-LocalGroupMember "Administrators"

Derniers événements de logon :

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4624; StartTime=(Get-Date).AddHours(-24)} |
  Select-Object TimeCreated, Id, ProviderName, Message -First 20

Échecs d’authentification :

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4625; StartTime=(Get-Date).AddHours(-24)} |
  Select-Object TimeCreated, Id, ProviderName, Message -First 20

Ces commandes peuvent être verbeuses. L’objectif n’est pas de lire tout le journal à la main, mais de vérifier qu’une session RDP correspond bien à un utilisateur attendu et à une fenêtre d’intervention connue.

Runbook de dépannage

#

Quand un accès SSH ou RDP via Pangolin ne fonctionne pas, il faut éviter de tout modifier au hasard. Le chemin est assez logique.

1. Le client est-il connecté ?

#

Sur le poste utilisateur :

pangolin up

Si vous utilisez une ressource privée, vérifiez d’abord que le client Pangolin est connecté. Pour SSH, cela peut être la CLI. Pour RDP privé, cela peut être le client graphique qui fournit le tunnel pendant que le client RDP natif ouvre la session.

2. L’alias existe-t-il et pointe-t-il vers la bonne ressource ?

#

Dans Pangolin, vérifier :

• ressource privée active ;
• alias correct ;
• site associé ;
• utilisateur ou rôle autorisé ;
• machine autorisée si des règles device sont utilisées.

Évitez les alias trop proches comme :

app.internal
apps.internal
app-01.internal

Sous stress, ce genre de nom finit par produire des erreurs humaines.

3. Le bon port est-il autorisé sur la ressource ?

#

Pour une ressource privée, la règle TCP doit permettre uniquement le port attendu.

Pour SSH :

TCP: Custom -> 22
UDP: Bloqué

Pour RDP :

TCP: Custom -> 3389
UDP: Bloqué au départ

Si TCP est bloqué, les droits utilisateur peuvent être corrects et la connexion échouera quand même.

4. Le site Newt voit-il la cible ?

#

Depuis le bastion ou l’hôte Newt :

nc -vz 10.10.20.11 22
nc -vz 10.10.40.15 3389

Si ce test échoue, Pangolin n’est probablement pas le problème. Regardez plutôt :

• routage interne ;
• firewall local ;
• VLAN ;
• service SSH ou RDP arrêté ;
• mauvaise IP ;
• résolution DNS interne.

5. OpenSSH accepte-t-il la connexion ?

#

Sur l’hôte cible :

sudo systemctl status ssh
sudo sshd -t
sudo journalctl -u ssh --since "15 minutes ago"

Selon la distribution :

sudo journalctl -u sshd --since "15 minutes ago"

Pour RDP, vérifier côté Windows :

Get-Service TermService
Get-NetTCPConnection -LocalPort 3389 -State Listen
Get-LocalGroupMember "Remote Desktop Users"

6. L’authentification locale est-elle cohérente ?

#

Pour une authentification manuelle :

getent passwd admin
sudo grep -i "Failed\\|Accepted" /var/log/auth.log

Pour une authentification par clé :

sudo ls -la /home/admin/.ssh
sudo sed -n '1,5p' /home/admin/.ssh/authorized_keys

La seconde commande affiche des clés publiques. Ne l’utilisez pas sur une sortie destinée à être partagée publiquement sans relecture.

Pour RDP, vérifier que l’utilisateur est autorisé localement ou via domaine, et qu’il n’utilise pas un compte partagé :

Get-LocalUser
Get-LocalGroupMember "Remote Desktop Users"
Get-LocalGroupMember "Administrators"

7. L’auth daemon répond-il ?

#

Si vous utilisez le provisioning automatisé avec auth daemon externe :

sudo systemctl status pangolin-auth-daemon
sudo journalctl -u pangolin-auth-daemon --since "15 minutes ago"
nc -vz 10.10.20.11 22123

Le port 22123/tcp doit être joignable depuis Newt vers l’hôte cible, pas depuis Internet.

8. Les logs Pangolin racontent quoi ?

#

Dans Pangolin, regardez dans cet ordre :

• logs d’authentification ;
• logs réseau ;
• statut du site ;
• événements d’administration récents ;
• changements sur la ressource.

Une modification de règle d’accès faite cinq minutes avant une panne est rarement une coïncidence.

Ce que je ne ferais pas

#

Quelques mauvaises idées reviennent souvent.

Exposer SSH ou RDP public en parallèle sans raison

#

Pendant une migration, c’est normal.

À long terme, garder 22/tcp ou 3389/tcp ouvert à Internet et ajouter Pangolin au-dessus n’apporte pas grand-chose. On garde l’ancienne surface d’attaque, plus une nouvelle couche à maintenir.

Créer une ressource privée trop large

#

Une ressource 10.10.0.0/16 avec All TCP ressemble à un VPN traditionnel. Ce n’est pas forcément interdit, mais ce n’est plus un modèle Zero Trust fin.

Pour SSH, commencez par hôte :

app-01.infra.internal -> 10.10.20.11:22
app-02.infra.internal -> 10.10.20.12:22
db-01.infra.internal  -> 10.10.30.21:22

Utiliser un compte Linux partagé

#

Un compte admin partagé par toute l’équipe casse l’audit.

Même si Pangolin sait qui a ouvert l’accès, l’hôte Linux voit surtout le même utilisateur local. Pour une petite infra, ça peut être toléré temporairement. Pour une équipe, il faut aller vers des comptes nominatifs, ou vers du provisioning automatisé.

Dépendre uniquement de Pangolin pour les urgences

#

Gardez un accès de secours.

Ça peut être :

• console VPS ;
• console IPMI/iDRAC/iLO ;
• VPN d’administration séparé ;
• règle firewall temporaire documentée ;
• bastion de secours avec journalisation.

Pangolin est une brique d’accès. Ce n’est pas une excuse pour supprimer tout chemin de récupération.

Pièges fréquents

#

Oublier le port sur une ressource privée

#

Pour une ressource privée, les restrictions de ports s’appliquent vraiment. Si 22/tcp pour SSH ou 3389/tcp pour RDP n’est pas autorisé, la session ne s’ouvrira pas, même si l’alias, le site et les droits utilisateur semblent corrects.

Utiliser Newt en conteneur pour le mode Pangolin SSH

#

Pour le mode Pangolin SSH, Newt doit tourner comme binaire sur l’hôte, en root. En conteneur, on risque d’obtenir un shell dans le conteneur, ce qui n’est généralement pas l’objectif.

Docker reste très bien pour un site Newt qui route vers des services web ou vers un OpenSSH standard. Le problème concerne spécifiquement le mode Pangolin SSH qui exécute sur l’hôte du connecteur.

Confondre alias Pangolin et DNS public

#

Un alias privé Pangolin n’a pas besoin d’un enregistrement DNS public. Il est résolu via le client Pangolin.

Évitez les alias en .local, souvent perturbés par mDNS. Préférez par exemple :

app-01.infra.internal
db-01.infra.internal
bastion.infra.internal

Donner accès à un CIDR entier pour SSH ou RDP

#

Créer une ressource 10.10.20.0/24 avec tous les ports ouverts est confortable, mais c’est rarement le bon premier choix.

Pour SSH et RDP, mieux vaut créer des ressources par hôte, au moins pour les machines sensibles.

Traiter RDP comme un simple confort graphique

#

RDP donne souvent accès à une session complète, parfois avec presse-papiers, transfert de fichiers et droits élevés. Ce n’est pas une “vue web” anodine.

Pour une ressource RDP publique, il faut au minimum :

• un groupe d’accès dédié ;
• MFA ;
• des comptes Windows nominatifs ;
• une revue des membres du groupe Remote Desktop Users ;
• une surveillance des échecs de connexion.

Si le besoin est régulier, une ressource privée 3389/tcp avec client Pangolin est généralement plus saine qu’un bureau Windows exposé en permanence via un FQDN public.

Modifier OpenSSH sans filet

#

Quand on touche à sshd_config, on teste avant :

sudo sshd -t

Et on garde une session déjà ouverte jusqu’à validation d’une nouvelle connexion.

Quand utiliser quoi ?

#

Pour un homelab ou un petit VPS :

• Pangolin SSH + manual auth peut suffire ;
• Newt doit tourner en root sur l’hôte ;
• garder un accès SSH classique de secours est raisonnable.

Pour plusieurs serveurs derrière un réseau privé :

• Standard SSH Server + manual auth est souvent le meilleur compromis de départ ;
• Newt sert de chemin réseau ;
• OpenSSH reste inchangé ;
• les droits locaux restent maîtrisés par les mécanismes habituels.

Pour une équipe avec rotation d’utilisateurs :

• regarder Standard SSH Server + automated provisioning ;
• tester sur un serveur pilote ;
• documenter la création de comptes, les groupes et les droits sudo ;
• surveiller les logs Pangolin et système.

Pour du support ponctuel :

• SSH public dans le navigateur peut être utile ;
• limiter fortement les utilisateurs autorisés ;
• imposer MFA ;
• désactiver ou archiver la ressource quand elle n’est plus nécessaire.

Pour une machine Windows administrée ponctuellement :

• RDP public dans le navigateur peut dépanner ;
• réserver ce modèle aux cas où l’absence de client RDP local est un vrai besoin ;
• imposer MFA côté Pangolin ;
• garder des comptes Windows nominatifs ;
• vérifier les journaux Windows après usage.

Pour une administration Windows régulière :

• préférer une ressource privée TCP 3389 ;
• utiliser le client Pangolin sur le poste admin ;
• ouvrir le client RDP natif vers l’alias privé ;
• éviter d’exposer RDP publiquement, même derrière un nom discret.

Checklist finale

#

Version courte avant mise en production :

1. Les ports 22 et 3389 ne sont pas exposés directement sur Internet.
2. Chaque ressource Pangolin cible un hôte précis, pas un réseau entier par confort.
3. Les ports sont en mode custom : 22/tcp pour SSH, 3389/tcp pour RDP.
4. Les accès sont accordés par groupes, avec MFA pour les administrateurs.
5. Les comptes Linux/Windows sont nominatifs ou clairement assumés comme dette technique.
6. Les logs Pangolin, Linux et Windows sont consultables.
7. La révocation d’un utilisateur a été testée.
8. Le chemin de secours est documenté.
9. Les ressources publiques SSH/RDP sont rares et justifiées.
10. Quelqu’un d’autre peut relire la configuration et comprendre pourquoi elle existe.

Checklist détaillée :

• l’article de runbook interne indique comment accéder à chaque ressource ;
• chaque serveur critique a un alias Pangolin explicite ;
• chaque ressource SSH privée limite TCP à 22 ;
• chaque ressource RDP privée limite TCP à 3389 si RDP est utilisé ;
• UDP est bloqué sauf besoin documenté ;
• les ressources publiques SSH sont rares et justifiées ;
• les ressources publiques RDP sont rares, justifiées et suivies ;
• MFA est activé pour les comptes concernés ;
• les groupes Pangolin correspondent aux responsabilités réelles ;
• les comptes Linux partagés sont évités ou assumés comme dette technique ;
• OpenSSH est testé avec sshd -t après modification ;
• les logs Pangolin et système sont consultables ;
• l’accès de secours est documenté ;
• la révocation d’un utilisateur a été testée au moins une fois.

Une configuration d’accès Pangolin correcte doit être compréhensible six mois plus tard. Si personne ne sait pourquoi une ressource existe, qui l’utilise et ce qu’elle autorise, elle doit être revue.

Conclusion

#

Pangolin est intéressant ici parce qu’il traite SSH et RDP comme des ressources d’accès, pas comme de simples ports à publier.

Le gain principal n’est pas magique. Il vient de décisions assez concrètes :

• ne pas exposer OpenSSH directement ;
• ne pas exposer RDP directement ;
• limiter chaque ressource à un hôte et un port ;
• faire passer l’accès par une identité Pangolin ;
• garder des logs exploitables ;
• éviter les clés permanentes quand le provisioning automatisé est pertinent.

Le modèle le plus raisonnable pour commencer reste souvent une ressource SSH privée en mode Standard SSH Server, avec authentification manuelle. C’est simple, ça ne casse pas OpenSSH, et ça permet déjà de retirer 22/tcp d’Internet.

Pour Windows, le parallèle est assez direct : une ressource privée 3389/tcp, un alias propre, des comptes Windows nominatifs, NLA activé, et un client RDP local depuis un poste connecté à Pangolin.

Le provisioning automatisé est une étape suivante, pas une case à cocher par réflexe. Il devient intéressant quand la gestion des comptes locaux et des clés SSH devient plus risquée que la complexité ajoutée par Pangolin.

Pangolin peut donc remplacer un bastion classique dans beaucoup de cas, et couvrir certains usages de Guacamole. Il ne faut simplement pas le vendre comme un PAM complet. Sa valeur est plus précise : réduire l’exposition, segmenter les accès, et rendre les chemins d’administration plus lisibles.

Sources

#

• Pangolin Docs - SSH Access
• Pangolin Docs - Private SSH resources
• Pangolin Docs - Public SSH resources
• Pangolin Docs - Install Sites / Newt
• Pangolin Docs - Install Clients
• Pangolin Docs - Private resource ports and ICMP
• Pangolin Docs - Private resource aliases
• Pangolin Docs - Public RDP resources
• Pangolin Docs - Enterprise Edition
• OpenSSH manual - sshd_config
• Apache Guacamole
• CyberArk - Privileged Access Management
• Microsoft Learn - Enable Remote Desktop on your PC
• Microsoft Learn - Local accounts