Qué ves
La sesión se abre con normalidad. El mensaje aparece cuando algo usa el túnel, no al conectarte, y lo ves en la terminal donde corre ssh:
channel 3: open failed: administratively prohibited: open failedEl programa que usa el túnel falla por separado, con su propio mensaje. Un cliente SSH que pase por él, por ejemplo, muestra kex_exchange_identification: read: Connection reset by peer.
Formas relacionadas que provienen de los mismos ajustes:
| Lo que ejecutaste | Salida |
|---|---|
ssh -L o ssh -D | channel 3: open failed: administratively prohibited: open failed |
ssh -W o ssh -J | channel 0: open failed: administratively prohibited: open failed, y después stdio forwarding failed |
ssh -R | Warning: remote port forwarding failed for listen port 8080 |
Un final distinto indica otro problema. open failed: connect failed: Connection refused significa que el reenvío estaba permitido, pero nada escucha en el host y puerto de destino. Corrige el destino, no la configuración.
Qué ajuste lo causa
| Dónde | Ajuste | Bloquea |
|---|---|---|
sshd_config | AllowTcpForwarding no | -L, -D, -W, -J y -R |
sshd_config | AllowTcpForwarding remote | -L, -D, -W y -J |
sshd_config | AllowTcpForwarding local | -R |
sshd_config | DisableForwarding yes | Todo reenvío, por encima de los demás ajustes |
sshd_config | PermitOpen 127.0.0.1:5432 | -L hacia cualquier destino que no esté en la lista |
sshd_config | PermitListen 9000 | -R en cualquier puerto que no esté en la lista |
authorized_keys | restrict o no-port-forwarding | El reenvío al iniciar sesión con esa clave |
authorized_keys | permitopen="127.0.0.1:5432" | -L con esa clave hacia cualquier otro destino |
Las opciones de clave como restrict y permitopen se explican línea a línea en el archivo authorized_keys explicado.
Averigua cuál se aplica a ti
Necesitas permisos de administrador en el servidor. Pregunta a sshd qué aplicaría a tu usuario. El simple sshd -T ignora los bloques Match, así que incluye los datos de la conexión. En una prueba, la forma simple dijo yes mientras que el valor real del usuario era no:
sudo sshd -T -C user=name,host=server,addr=203.0.113.10 | grep -iE '^(allowtcpforwarding|disableforwarding|permitopen|permitlisten)'Mira también las opciones que preceden a la clave en el archivo de ese usuario:
sudo cut -c1-60 ~name/.ssh/authorized_keysEl log del servidor nombra el destino rechazado:
refused local port forward: originator 127.0.0.1 port 65535, target 127.0.0.1 port 22Cómo arreglarlo
Si el servidor no es tuyo, pregunta a su administrador. El bloqueo suele ser deliberado, porque un túnel permite a un usuario llegar a sistemas internos desde fuera. Explica qué host y puerto necesitas para que pueda permitir solo eso.
Si el servidor es tuyo, es mejor una regla estrecha que activar el reenvío para todos. Pon esto al final de sshd_config:
Match User name
AllowTcpForwarding local
PermitOpen 127.0.0.1:5432Después valida y recarga. El servicio se llama ssh en Debian y Ubuntu, y sshd en los sistemas de tipo Red Hat:
sudo sshd -t && sudo systemctl reload sshTen en cuenta que, para la mayoría de las palabras clave, sshd usa el primer valor que lee. Si una línea cerca del principio dice AllowTcpForwarding no, un yes más abajo no sirve de nada. En Debian y Ubuntu, los archivos de /etc/ssh/sshd_config.d/ se leen primero, así que revisa también ahí. Ejecuta sshd -T de nuevo tras el cambio para ver el resultado.
Si la restricción está en una clave, cambia las opciones de su línea en authorized_keys. Surte efecto en el siguiente inicio de sesión, sin recargar nada. Por ejemplo, a una clave con restrict se le puede devolver un único túnel:
restrict,port-forwarding,permitopen="127.0.0.1:5432" ssh-ed25519 AAAA... user@laptopConsulta cómo restringir una clave SSH.
Preguntas
¿Administratively prohibited significa que mi contraseña o mi clave están mal?
No. El inicio de sesión funcionó. Es la configuración del servidor la que rechaza esta redirección, así que solo sus ajustes o las opciones de tu clave pueden cambiar el resultado.
¿Cómo permito la redirección de puertos a un solo usuario?
Añade al final de sshd_config un bloque Match User nombre con AllowTcpForwarding local y una línea PermitOpen para el destino, luego ejecuta sshd -t y recarga el servicio.
¿Por qué ssh -J falla con administratively prohibited?
Un host de salto necesita reenviar TCP para dejar pasar tu conexión. Si tiene AllowTcpForwarding no o remote, o tu clave lleva restrict, la conexión con -J falla igual.
Fuentes
- sshd_config(5), AllowTcpForwarding, PermitOpen, DisableForwarding
- sshd(8), opciones de authorized_keys