Ce que vous voyez
La session s'ouvre normalement. Le message apparaît quand quelque chose utilise le tunnel, pas à la connexion, et il s'affiche dans le terminal où tourne ssh :
channel 3: open failed: administratively prohibited: open failedLe programme qui utilise le tunnel échoue séparément, avec son propre message. Un client SSH qui passe par le tunnel affiche par exemple kex_exchange_identification: read: Connection reset by peer.
Formes voisines produites par les mêmes réglages :
| Commande lancée | Sortie |
|---|---|
ssh -L ou ssh -D | channel 3: open failed: administratively prohibited: open failed |
ssh -W ou ssh -J | channel 0: open failed: administratively prohibited: open failed, puis stdio forwarding failed |
ssh -R | Warning: remote port forwarding failed for listen port 8080 |
Une fin de message différente indique un autre problème. open failed: connect failed: Connection refused signifie que la redirection était autorisée, mais que rien n'écoute sur l'hôte et le port cibles. Corrigez la cible, pas la configuration.
Quel réglage en est la cause
| Où | Réglage | Bloque |
|---|---|---|
sshd_config | AllowTcpForwarding no | -L, -D, -W, -J et -R |
sshd_config | AllowTcpForwarding remote | -L, -D, -W et -J |
sshd_config | AllowTcpForwarding local | -R |
sshd_config | DisableForwarding yes | Toute redirection, et prime sur les autres réglages |
sshd_config | PermitOpen 127.0.0.1:5432 | -L vers toute cible absente de la liste |
sshd_config | PermitListen 9000 | -R sur tout port absent de la liste |
authorized_keys | restrict ou no-port-forwarding | Les redirections lors d'une connexion avec cette clé |
authorized_keys | permitopen="127.0.0.1:5432" | -L avec cette clé vers toute autre cible |
Les options de clé comme restrict et permitopen sont expliquées ligne par ligne dans le fichier authorized_keys expliqué.
Trouver celui qui s'applique à vous
Il faut des droits d'administrateur sur le serveur. Demandez à sshd ce qu'il appliquerait à votre utilisateur. Un simple sshd -T ignore les blocs Match : ajoutez donc les détails de la connexion. Lors d'un test, la forme simple affichait yes alors que la vraie valeur de l'utilisateur était no :
sudo sshd -T -C user=name,host=server,addr=203.0.113.10 | grep -iE '^(allowtcpforwarding|disableforwarding|permitopen|permitlisten)'Regardez aussi les options placées avant la clé dans le fichier de cet utilisateur :
sudo cut -c1-60 ~name/.ssh/authorized_keysLe journal du serveur nomme la cible refusée :
refused local port forward: originator 127.0.0.1 port 65535, target 127.0.0.1 port 22Corriger
Si ce n'est pas votre serveur, demandez à son administrateur. Le blocage est le plus souvent voulu, car un tunnel permet d'atteindre des systèmes internes depuis l'extérieur. Expliquez quels hôte et port il vous faut, afin qu'il n'autorise que ceux-là.
Si c'est votre serveur, préférez une règle étroite plutôt que d'activer les redirections pour tout le monde. Placez ceci à la fin de sshd_config :
Match User name
AllowTcpForwarding local
PermitOpen 127.0.0.1:5432Puis validez et rechargez. Le service s'appelle ssh sur Debian et Ubuntu, et sshd sur les systèmes de type Red Hat :
sudo sshd -t && sudo systemctl reload sshGardez en tête que, pour la plupart des mots-clés, sshd utilise la première valeur qu'il lit. Si une ligne en haut du fichier dit AllowTcpForwarding no, un yes plus bas ne change rien. Sur Debian et Ubuntu, les fichiers de /etc/ssh/sshd_config.d/ sont lus en premier : regardez-y aussi. Relancez sshd -T après la modification pour voir le résultat.
Pour une clé restreinte, modifiez les options sur sa ligne dans authorized_keys. Cela prend effet à la connexion suivante, sans rechargement. Par exemple, une clé avec restrict peut récupérer un seul tunnel :
restrict,port-forwarding,permitopen="127.0.0.1:5432" ssh-ed25519 AAAA... user@laptopVoir comment restreindre une clé SSH.
Questions
Administratively prohibited signifie-t-il que mon mot de passe ou ma clé est faux ?
Non. La connexion a réussi. C'est la configuration du serveur qui refuse cette redirection : seuls ses réglages ou les options de votre clé peuvent changer le résultat.
Comment autoriser la redirection de port pour un seul utilisateur ?
Ajoutez à la fin de sshd_config un bloc Match User nom avec AllowTcpForwarding local et une ligne PermitOpen pour la cible, puis lancez sshd -t et rechargez le service.
Pourquoi ssh -J échoue-t-il avec administratively prohibited ?
Un hôte de rebond doit relayer du TCP pour faire passer votre connexion. S'il a AllowTcpForwarding no ou remote, ou si votre clé porte restrict, la connexion -J échoue de la même façon.
Sources
- sshd_config(5), AllowTcpForwarding, PermitOpen, DisableForwarding
- sshd(8), options de authorized_keys