SSH ProxyCommand et authentification basée sur l'hôte : quel hôte signe ?

Une cible voit une connexion TCP venant du bastion tandis que le client SSH qui effectue l'authentification s'exécute toujours sur le poste de travail.

Host behind-bastion
    ProxyCommand ssh -W %h:%p bastion

Ici, l'auxiliaire se connecte au bastion et demande à son serveur SSH une connexion transférée vers la cible. Le client SSH externe du poste échange le protocole SSH de la cible à travers ce flux. Le bastion assure le transport ; il n'a pas lancé le client SSH tourné vers la cible.

Cette distinction compte pour l'authentification basée sur l'hôte. L'auxiliaire ssh-keysign d'OpenSSH accède aux clés d'hôte locales pour produire la signature requise. Une adresse source réseau appartenant au bastion ne fait pas signer le poste avec la clé d'hôte du bastion.

Comparez avec :

ssh -t bastion ssh target

Ceci lance un autre programme SSH sur le bastion. Sa configuration locale et ses clés d'hôte disponibles appartiennent à cette machine, il peut donc participer à un dispositif de confiance basé sur l'hôte déjà configuré entre le bastion et la cible. Il a toujours besoin de l'autorisation correspondante et des contrôles de nom de la cible.

La seconde forme change aussi le fonctionnement de la session : elle exécute une commande distante et utilise un terminal. Ce n'est pas un remplacement transparent de tout transfert de fichiers SSH ou transport d'automatisation. Choisissez le dispositif selon la machine qui doit s'authentifier auprès de la cible, plutôt que d'affaiblir les contrôles de confiance du serveur pour que l'adresse source paraisse suffisante.