Le transfert d'environnement SSH peut-il fuir le contexte local ?

Le transfert d'environnement SSH peut divulguer bien plus de contexte local qu'une tâche distante n'en a besoin. Le canal est chiffré, mais le chiffrement ne protège que le trajet. Il ne rend pas AWS_PROFILE, GIT_AUTHOR_EMAIL, un nom de locataire ou un indicateur interne appropriés pour un processus exécuté ailleurs.

Je traite chaque variable transférée comme un argument de la commande distante. Elle doit donc avoir un nom, une raison, un propriétaire et un test. Un joker repris d'une configuration pratique pour un portable échoue à ce contrôle, car sa portée change dès qu'une nouvelle variable locale correspond.

L'objectif n'est pas un environnement distant vide. sshd, le compte, le shell et les enveloppes créent leur propre base. Le client doit seulement contribuer les variables inscrites dans un contrat, le serveur ne doit rien accepter de plus large et un test doit prouver l'arrivée des valeurs requises comme le rejet des leurres.

Le transfert exige l'accord des deux extrémités SSH

OpenSSH place deux portes sur ce mécanisme. Côté client, SendEnv choisit des noms dans l'environnement local et SetEnv fournit des paires littérales NOM=VALEUR. Côté serveur, AcceptEnv décide quels noms entrent dans la session. En règle générale, un nom ne passe que si le client le propose et le serveur l'accepte.

RFC 4254 décrit la requête de canal env, envoyée avant le lancement du shell ou de la commande avec un nom et une valeur. Le texte avertit que modifier sans contrôle l'environnement d'un processus privilégié est dangereux et recommande une liste d'autorisation ou l'abaissement préalable des privilèges. Cet avertissement appartient au protocole lui-même.

Les manuels OpenSSH précisent une exception : lorsqu'un pseudo-terminal est demandé, TERM est toujours envoyé et accepté car le protocole en a besoin. Utilisez ssh -T pour une automatisation sans terminal. Vous retirez ainsi de ce chemin TERM, le comportement interactif et les surprises des fichiers de démarrage.

Quatre conséquences méritent d'être retenues.

• Un SendEnv large reste dormant tant que le serveur n'accepte rien, puis s'active dès qu'un administrateur élargit AcceptEnv.
• Un AcceptEnv large reste dormant avec un client prudent, mais un utilisateur autorisé peut employer une autre configuration.
• Aucun côté ne peut faire respecter seul tout le contrat quand plusieurs personnes contrôlent les fichiers.
• Une commande réussie ne révèle pas les requêtes d'environnement que le serveur a ignorées.

OpenSSH peut en effet refuser une variable et poursuivre la session. Si le shell distant définit déjà le même nom, un test limité à la valeur finale peut attribuer au transfert une valeur qui n'a jamais traversé le canal. Le test doit donc employer une valeur de contrôle absente du serveur, faute de quoi il vérifie seulement que le processus final possède un nom, sans en établir la provenance.

Les jokers transforment l'état local futur en entrée distante

SendEnv WORKFLOW_* ne signifie pas « les variables examinées aujourd'hui ». Il désigne tous les noms correspondants présents dans les futurs processus SSH. Quelques semaines plus tard, WORKFLOW_DEBUG_DUMP, WORKFLOW_CUSTOMER ou WORKFLOW_TOKEN_FILE peut apparaître dans un profil et donner un nouveau comportement à l'ancienne règle.

Les paramètres régionaux montrent bien le problème. Beaucoup de postes envoient LANG et LC_* pour afficher correctement une session interactive. Ce choix peut convenir à un humain sans convenir à une compilation ou un déploiement. Ces valeurs changent le tri, les classes de caractères, les dates et les diagnostics. Une tâche qui analyse la sortie peut échouer sans fuite de secret.

Les espaces de noms pratiques sont souvent les plus risqués :

• AWS_* peut réunir profils, régions, valeurs liées aux identifiants et chemins de configuration.
• GIT_* peut transporter identité, traces, répertoires d'objets alternatifs ou comportement askpass.
• CI_* mélange souvent étiquettes anodines, contexte du fournisseur et chemins temporaires.
• LC_* paraît cosmétique jusqu'à ce qu'un script dépende d'un tri ou de messages stables.
• APP_* grandit avec l'application et a rarement un sens de sécurité unique.

Classez chaque nom, pas tout le préfixe. DEPLOY_REGION peut être nécessaire alors que AWS_PROFILE décrit le poste. BUILD_REF peut être nécessaire tandis que GIT_CONFIG_COUNT modifie Git. Un préfixe organise les noms, il ne crée pas une frontière de confiance.

Une valeur non secrète peut tout de même divulguer un utilisateur, la structure d'un dépôt, un compte ou un client. Un indicateur de trace peut aussi écrire les commandes dans un journal partagé. Un agent qui voit ce contexte peut s'en servir lors d'une action ultérieure, même si la première commande ne faisait que l'afficher. La fuite couvre la divulgation et l'influence non prévues, pas seulement les jetons ou les mots de passe.

Une exception anodine peut s'élargir des mois plus tard

La dérive assemble souvent deux changements qui semblaient sûrs séparément. Un développeur ajoute SendEnv APP_* pour transmettre APP_COLOR=0; le serveur refuse alors la requête. Plus tard, un administrateur ajoute AcceptEnv APP_* pour une autre équipe sur le même hôte. Chaque revue ne voit que la moitié de l'accord.

La connexion suivante réveille les deux règles. Le shell contient désormais APP_CUSTOMER=acme-lab, APP_TRACE=1 et APP_CONFIG=/Users/lee/work/private/config. Le client les propose, le démon les accepte et une enveloppe de diagnostic exécute env après un échec. Identité locale, client, chemin et trace se retrouvent dans un journal partagé sans qu'aucun jeton ait été copié.

Supprimer le joker corrige les sessions futures, pas l'ancien journal. Traitez la découverte comme un petit incident :

1. Arrêtez l'acceptation large et validez la configuration du démon.
2. Identifiez comptes, clients et période où les deux motifs coexistaient.
3. Cherchez les noms exposés dans les journaux autorisés, jamais leurs valeurs sensibles.
4. Déterminez si chaque valeur a modifié la commande ou divulgué du contexte.
5. Remplacez le joker par des noms exacts et ajoutez des leurres.

Dire que le serveur refuse actuellement la règle ne justifie donc pas un client large. Supprimez les offres inutiles même face à un serveur strict, et les acceptations inutiles même face aux clients prudents.

La dérive inverse existe aussi : un serveur accepte depuis longtemps LC_* pour les humains, puis une image d'automatisation commence à l'envoyer. Le déploiement hérite de LC_COLLATE choisi par un développeur et change l'ordre des fichiers produits. Ce n'est peut-être pas une divulgation à traiter comme un incident, mais c'est bien une atteinte à l'intégrité issue du même accord entre client et serveur. Confidentialité et comportement de commande doivent donc être examinés ensemble.

Inspectez la configuration réellement utilisée par SSH

Lisez la configuration évaluée avant de modifier un fichier. ssh -G applique Host, Match, les inclusions et les fichiers utilisateur et système, puis affiche le résultat du destinataire. Un fichier apparemment autoritaire peut perdre face à une valeur antérieure ou recevoir des règles d'une inclusion.

Exécutez ceci avec le même compte et le même lanceur que le flux :

ssh -G deploy-prod |
  awk '$1 == "sendenv" || $1 == "setenv" { print }'

Un résultat dangereux typique ressemble à ceci :

sendenv LANG
sendenv LC_*
sendenv AWS_*
setenv WORKFLOW_KIND=deploy

ssh -G montre les règles, pas les valeurs courantes sélectionnées par SendEnv, et évite donc de déverser des identifiants. Cette propriété rend la sortie adaptée à une revue de configuration, mais elle ne suffit pas à conclure. Il faut encore comparer les noms et motifs avec l'environnement du processus qui lance réellement SSH, car une règle sans valeur locale ne transmet rien lors de cette exécution.

Relevez uniquement les noms :

env | sed 's/=.*//' | LC_ALL=C sort > local-env.names
grep -E '^(LANG|LC_|AWS_|WORKFLOW_)' local-env.names

L'expression régulière n'est qu'un outil d'inspection, pas une politique à copier dans la configuration. Adaptez-la à tous les motifs affichés par ssh -G. Si un superviseur, un IDE, un agent ou une tâche planifiée lance SSH, inspectez ce processus plutôt que votre shell interactif. L'héritage suit l'arbre des processus, si bien qu'un test effectué depuis le mauvais parent peut produire un résultat propre mais sans rapport avec la production.

Contrôlez le serveur séparément. sshd -T valide et affiche les réglages effectifs; ajoutez les critères de connexion lorsque des blocs Match interviennent :

sudo sshd -T \
  -C user=deploybot,host=deploy.example,addr=192.0.2.44 |
  grep '^acceptenv'

Remplacez les valeurs d'exemple par l'utilisateur, l'hôte et l'adresse réels. Exécutez aussi sudo sshd -t avant le rechargement. Un durcissement de l'environnement ne doit pas couper l'accès distant.

Un fichier client dédié rend l'autorisation lisible

Pour l'automatisation, passez un petit fichier dédié avec -F. Le manuel indique qu'il remplace le fichier utilisateur normal et fait ignorer le fichier client système. Une mise à jour du poste ne peut alors ajouter un joker de locale au flux.

Host deploy-prod
    HostName deploy.example
    User deploybot
    IdentityFile ~/.ssh/deploy_ed25519
    IdentitiesOnly yes
    RequestTTY no
    SendEnv DEPLOY_REGION
    SendEnv BUILD_REF
    SetEnv WORKFLOW_KIND=deploy

Appelez-le explicitement :

ssh -F ./deploy-ssh.conf deploy-prod /usr/local/bin/release

SendEnv lit la valeur dans le processus ssh local et convient aux entrées qui changent légitimement à chaque exécution. SetEnv inscrit une valeur littérale dans la configuration; réservez-le à une étiquette constante non secrète, jamais à un identifiant. Une valeur que les opérateurs doivent modifier à la main finira aussi par devenir périmée, ce qui en fait un mauvais usage de SetEnv.

Un motif SendEnv préfixé par - efface des sélections antérieures :

Host deploy-prod
    SendEnv -*
    SendEnv DEPLOY_REGION BUILD_REF

Il n'efface que ce qui a déjà été accumulé à cet endroit de l'analyse. Une inclusion ou une règle système rencontrée plus tard peut ajouter les noms à nouveau. Voilà pourquoi je n'emploie pas la soustraction comme limite finale d'une automatisation. Un fichier dédié avec -F comporte moins de pièces, exclut les valeurs générales du poste et produit une configuration effective qu'un collègue peut comprendre sur un seul écran.

N'y placez aucune information d'identification. Une fois livrée, elle devient l'état ordinaire d'un processus distant et peut atteindre enfants, traces, rapports de panne, /proc ou une sortie env. SSH protège le transport, pas la vie de la valeur après réception.

Le serveur doit accepter des noms exacts pour un compte limité

Le serveur est le dernier point de rejet avant le démarrage de la session. OpenSSH n'accepte rien par défaut, hormis le cas TERM avec pseudo-terminal. Conservez ce défaut global et ajoutez uniquement les noms du compte de travail.

Match User deploybot
    AcceptEnv DEPLOY_REGION
    AcceptEnv BUILD_REF
    AcceptEnv WORKFLOW_KIND

N'utilisez pas AcceptEnv APP_*, AcceptEnv AWS_* ni un joker nu. Le manuel sshd_config avertit que certaines variables peuvent contourner un environnement restreint. Un joker autorise aussi les futurs noms sans nouveau changement serveur.

Un AcceptEnv global affaiblit tous les comptes correspondants. Un bloc Match User plus étroit n'efface pas les noms globaux déjà accumulés, car les entrées d'acceptation peuvent s'ajouter. Si les utilisateurs interactifs ont besoin des locales et que le compte de déploiement ne doit pas les recevoir, ne partez pas d'une autorisation globale. Limitez l'exception aux utilisateurs ou groupes concernés et vérifiez chaque cas réel avec sshd -T -C.

Le SetEnv serveur fixe des constantes dans les sessions enfants et remplace les valeurs par défaut ou reçues via AcceptEnv et PermitUserEnvironment. Si le serveur possède la valeur, fixez-la là au lieu de la recevoir.

PermitUserEnvironment contrôle ~/.ssh/environment et les options environment= des clés autorisées; OpenSSH le désactive par défaut. Gardez-le désactivé sauf besoin précis et incluez ses motifs dans la même revue.

Une liste de noms ne valide pas les valeurs. DEPLOY_REGION peut contenir espaces, métacaractères, nouvelle ligne ou région interdite. Le protocole le transporte comme donnée, mais le programme récepteur peut ensuite le transformer en syntaxe avec eval, une expansion non citée, une configuration générée ou une chaîne de commande. L'autorisation du nom et la validation de son contenu sont deux contrôles distincts; il faut les deux.

Validez chaque valeur à l'entrée distante :

case ${DEPLOY_REGION-} in
    us-east-1|us-west-2) ;;
    *)
        printf 'invalid DEPLOY_REGION\n' >&2
        exit 64
        ;;
esac

case ${BUILD_REF-} in
    [0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]*)
        ;;
    *)
        printf 'invalid BUILD_REF\n' >&2
        exit 64
        ;;
esac

Adaptez le contrôle au contrat réel. Pour une référence complète, imposez la longueur et vérifiez son existence dans le dépôt. Un validateur qui rejette seulement la chaîne vide ne protège rien.

Inspectez ensuite le résultat effectif :

sudo sshd -t
sudo sshd -T \
  -C user=deploybot,host=deploy.example,addr=192.0.2.44 |
  grep -E '^(acceptenv|permituserenvironment|setenv)'

Conservez cette sortie avec la revue. Elle montre ce que le démon a réellement interprété pour la connexion, mieux qu'une capture d'un fragment parmi plusieurs inclusions.

Prouvez à distance l'arrivée des valeurs et le rejet des leurres

Un bon test vérifie le positif et le négatif dans le processus distant. Attribuez des marqueurs uniques aux valeurs requises, créez des leurres qui auraient correspondu aux anciens jokers, utilisez le fichier dédié et faites échouer le shell si le contrat est violé.

Cette séquence n'attend que DEPLOY_REGION, BUILD_REF et le constant WORKFLOW_KIND :

export DEPLOY_REGION='env-audit-region'
export BUILD_REF='env-audit-ref'
export AWS_PROFILE='must-not-cross'
export LC_AUDIT_CANARY='must-not-cross'
export APP_PRIVATE_PATH='must-not-cross'

ssh -F ./deploy-ssh.conf -T deploy-prod 'sh -s' <<'REMOTE'
set -eu

test "$(printenv DEPLOY_REGION)" = 'env-audit-region'
test "$(printenv BUILD_REF)" = 'env-audit-ref'
test "$(printenv WORKFLOW_KIND)" = 'deploy'

for name in AWS_PROFILE LC_AUDIT_CANARY APP_PRIVATE_PATH; do
    if printenv "$name" >/dev/null 2>&1; then
        printf 'unexpected forwarded variable: %s\n' "$name" >&2
        exit 1
    fi
done

printf '%s\n' 'SSH environment contract passed'
REMOTE

La sortie attendue tient sur une ligne :

SSH environment contract passed

Supprimez ensuite une valeur locale requise. SendEnv ne peut envoyer un nom absent, donc l'assertion distante doit échouer :

unset BUILD_REF
if ssh -F ./deploy-ssh.conf -T deploy-prod 'test -n "$BUILD_REF"'; then
    printf '%s\n' 'test failed: BUILD_REF appeared unexpectedly' >&2
    exit 1
fi

Si BUILD_REF est obligatoire, faites aussi échouer le lanceur avec ${BUILD_REF:?BUILD_REF is required} avant d'ouvrir la connexion. Ce premier arrêt donne une erreur claire à l'opérateur. La vérification distante reste nécessaire, car elle exerce le transport lui-même et détecte un refus silencieux du serveur que la validation locale ne peut pas voir.

Les leurres doivent couvrir chaque ancien joker et rester manifestement faux. N'utilisez jamais un véritable secret : l'échec pourrait l'écrire dans les journaux.

Un passage réussi ne prouve pas l'absence de toute variable imaginable. Il prouve les cas négatifs nommés pour une configuration et un environnement de processus donnés. Combinez-le avec ssh -G, qui ne doit montrer que des noms exacts, et sshd -T -C, qui ne doit montrer que les AcceptEnv prévus. La présence de * ou ? rend les futurs noms impossibles à énumérer dans une matrice de tests.

Exécutez le test depuis chaque lanceur distinct. Shell, CI, tâche d'éditeur et agent peuvent invoquer le même binaire avec des environnements et chemins différents. Inscrivez -F dans le lanceur plutôt que dans un alias interactif.

Une valeur finale ne prouve pas la contribution SSH. Si /etc/profile définit déjà DEPLOY_REGION=us-east-1 et que le client envoie la même valeur, l'assertion peut passer malgré le rejet de la requête. Employez un marqueur unique que la base distante ne peut pas contenir, puis exécutez aussi le test d'entrée absente. Ensemble, ces deux cas distinguent un transfert réel d'une valeur de repli créée sur le serveur.

Le test n'affirme pas que l'environnement total contient trois variables. sshd ajoute notamment HOME, USER, SHELL, PATH et des métadonnées SSH; d'autres couches peuvent en ajouter. Il prouve seulement que la contribution du client respecte le contrat.

La construction de commande peut contourner SendEnv

Vider SendEnv n'empêche pas le shell local de développer des variables dans la commande distante :

ssh deploy-prod "release '$TENANT' '$TOKEN'"

Le shell remplace les valeurs avant le lancement de ssh. Elles voyagent dans la requête de commande chiffrée, pas dans une requête env; AcceptEnv ne peut donc pas les refuser. Elles peuvent aussi apparaître dans les processus, l'historique, la CI ou les erreurs.

Ce préfixe modifie l'environnement du client, mais ne traverse que si la règle choisit le nom :

DEPLOY_REGION=west ssh -F ./deploy-ssh.conf deploy-prod /usr/local/bin/release

Les équipes confondent souvent les deux chemins. La présence locale au lancement ne prouve pas un transfert, et la désactivation de SendEnv ne prouve pas qu'une enveloppe n'a rien interpolé dans les arguments ou l'entrée standard.

Les couches distantes peuvent encore supprimer, remplacer ou ajouter des valeurs : shell, /etc/environment, PAM, commande forcée, sudo, gestionnaire de service ou conteneur. Si un marqueur manque, inspectez avec ssh -vvv la décision d'envoi du client, consultez les journaux autorisés du serveur et placez une commande minimale avant l'enveloppe applicative. N'élargissez pas aussitôt AcceptEnv, car cela masque souvent la couche qui a réellement changé le contenu.

sudo ne constitue pas un contrôle SSH. Sa politique peut nettoyer ou conserver l'environnement du processus privilégié, mais la valeur a déjà atteint la session non privilégiée, où le shell, les crochets d'audit et les enveloppes ont pu l'observer. Réglez sudoers pour les besoins de sa commande tout en gardant la liste SSH étroite avant cette couche. Un filtrage tardif ne retire pas une divulgation déjà survenue.

L'hôte distant n'est pas un tuyau passif. Le propriétaire du compte peut généralement lire son environnement, et l'administrateur contrôle la machine. Si l'hôte ne doit jamais apprendre une valeur, ne l'envoyez sous aucune forme avec SSH.

Évitez les sorties complètes de env dans les journaux courants. Pendant un audit autorisé, relevez les noms et ne révélez que les faux marqueurs.

Le SSH lancé par un agent exige une frontière de processus réduite

Un agent autonome hérite souvent du terminal, de l'éditeur ou de l'orchestrateur qui l'a lancé. Cet environnement a été conçu pour une personne travaillant sur plusieurs dépôts et comptes, pas pour une seule action distante. Le transfert de ses espaces de noms donne à l'agent du contexte supplémentaire et fournit à l'hôte des entrées que personne n'a approuvées lors de la revue de l'action.

Lancez le flux avec un environnement local et un fichier SSH explicites. Une enveloppe minimale peut exiger les deux valeurs, éliminer le reste et restaurer seulement ce dont le client a besoin :

#!/bin/sh
set -eu
: "${DEPLOY_REGION:?DEPLOY_REGION is required}"
: "${BUILD_REF:?BUILD_REF is required}"

exec env -i \
  HOME="$HOME" \
  PATH='/usr/bin:/bin:/usr/sbin:/sbin' \
  DEPLOY_REGION="$DEPLOY_REGION" \
  BUILD_REF="$BUILD_REF" \
  ssh -F ./deploy-ssh.conf deploy-prod /usr/local/bin/release

Adaptez PATH au système d'exploitation et gardez la liste explicite. HOME reste ici parce qu'OpenSSH peut chercher les hôtes connus et le fichier d'identité indiqué dans l'exemple. Si un exécuteur géré fournit ces chemins par d'autres options, supprimez également HOME; toute valeur conservée doit avoir une raison liée au fonctionnement du client.

Sur Mac, Sallyport peut conserver la clé SSH dans son coffre chiffré et exécuter l'action avec sp-ssh, sans remettre la clé à l'agent. Cette garde des identifiants ne remplace pas le contrat d'environnement exact autour de la commande autorisée.

Ne transférez pas des identifiants cloud locaux pour simplifier l'accès distant. Donnez au travail distant sa propre identité limitée ou passez par une passerelle qui détient l'identifiant. Copier l'identité ambiante mélange deux frontières et complique la révocation.

Gardez le contrat exécutable après chaque changement

Les paquets ajoutent des valeurs par défaut, les administrateurs regroupent des fragments et les flux gagnent des entrées. Une règle en prose ne détecte pas cette dérive. Examinez ensemble le fichier dédié, le compte serveur et l'assertion.

Relancez le test après toute modification de :

• paquets client SSH ou système d'exploitation ;
• inclusions utilisateur ou système ;
• sshd_config, PAM, démarrage du shell ou commandes forcées ;
• lanceur d'agent, CI, gestionnaire de service ou image ;
• liste des entrées requises.

Traitez chaque nouvelle variable comme un changement d'interface. Documentez pourquoi la commande distante en a besoin, si le client ou le serveur possède sa valeur, si elle contient un contexte sensible et quel test démontre son absence ailleurs. Si personne ne sait répondre, passez plutôt une entrée de commande validée ou repensez l'action distante au lieu d'élargir un joker pour faire disparaître l'erreur.

Rendez l'échec net. Un déploiement qui retombe silencieusement sur une valeur distante est plus difficile à diagnostiquer et plus facile à détourner qu'un arrêt sur valeur manquante. Le lanceur local et l'entrée distante doivent tous deux refuser l'absence.

Enfin, contrôlez le compte depuis le côté distant. Une liste parfaite ne protège pas un compte capable de lancer n'importe quel shell, lire les environnements d'autres utilisateurs ou réécrire ses propres fichiers de démarrage. La transmission de variables n'est qu'un canal d'entrée. Rendez ce canal exact, prouvez son comportement et limitez assez l'autorité de la commande pour qu'une valeur inattendue ne permette pas une action sans rapport.