What you see
The session opens normally. The message appears when something uses the tunnel, not when you connect, and it appears in the terminal running ssh:
channel 3: open failed: administratively prohibited: open failedThe program using the tunnel fails separately, with its own message. An SSH client going through it, for example, prints kex_exchange_identification: read: Connection reset by peer.
Related forms from the same settings:
| You ran | Output |
|---|---|
ssh -L or ssh -D | channel 3: open failed: administratively prohibited: open failed |
ssh -W or ssh -J | channel 0: open failed: administratively prohibited: open failed, then stdio forwarding failed |
ssh -R | Warning: remote port forwarding failed for listen port 8080 |
A different ending means a different problem. open failed: connect failed: Connection refused means the forward was allowed, but nothing is listening on the target host and port. Fix the target, not the configuration.
Which setting does it
| Where | Setting | Blocks |
|---|---|---|
sshd_config | AllowTcpForwarding no | -L, -D, -W, -J and -R |
sshd_config | AllowTcpForwarding remote | -L, -D, -W and -J |
sshd_config | AllowTcpForwarding local | -R |
sshd_config | DisableForwarding yes | All forwarding, overriding the other settings |
sshd_config | PermitOpen 127.0.0.1:5432 | -L to any target not on the list |
sshd_config | PermitListen 9000 | -R on any port not on the list |
authorized_keys | restrict or no-port-forwarding | Forwarding when logging in with that key |
authorized_keys | permitopen="127.0.0.1:5432" | -L with that key to any other target |
Key options such as restrict and permitopen are explained line by line in the authorized_keys file explained.
Find which one applies to you
You need admin rights on the server. Ask sshd what it would apply to your user. Plain sshd -T ignores Match blocks, so include the connection details. In a test, the plain form said yes while the user's real value was no:
sudo sshd -T -C user=name,host=server,addr=203.0.113.10 | grep -iE '^(allowtcpforwarding|disableforwarding|permitopen|permitlisten)'Also look at the options before the key in that user's file:
sudo cut -c1-60 ~name/.ssh/authorized_keysThe server's log names the refused target:
refused local port forward: originator 127.0.0.1 port 65535, target 127.0.0.1 port 22Fix it
If it is not your server, ask its administrator. The block is usually deliberate, because a tunnel lets a user reach internal systems from outside. Explain which host and port you need so that they can allow only that.
If it is your server, prefer a narrow rule over turning forwarding on for everyone. Put this at the end of sshd_config:
Match User name
AllowTcpForwarding local
PermitOpen 127.0.0.1:5432Then validate and reload. The service is ssh on Debian and Ubuntu and sshd on Red Hat style systems:
sudo sshd -t && sudo systemctl reload sshKeep in mind that for most keywords, sshd uses the first value it reads. If a line near the top says AllowTcpForwarding no, a yes further down does nothing. On Debian and Ubuntu, files in /etc/ssh/sshd_config.d/ are read first, so check there too. Run sshd -T again after the change to see the result.
For a restricted key, change the options on its line in authorized_keys. This takes effect on the next login, with no reload. For example, a key with restrict can get one tunnel back:
restrict,port-forwarding,permitopen="127.0.0.1:5432" ssh-ed25519 AAAA... user@laptopSee how to restrict an SSH key.
Questions
Does administratively prohibited mean my password or key is wrong?
No. You logged in successfully. The server's configuration refuses this particular forward, so only its settings or the options on your key can change the result.
How do I allow port forwarding for one user only?
Add a Match User name block at the end of sshd_config with AllowTcpForwarding local and a PermitOpen line for the target, then run sshd -t and reload the service.
Why does ssh -J fail with administratively prohibited?
A jump host needs TCP forwarding to pass your connection on. If it has AllowTcpForwarding no or remote, or your key has restrict, the -J connection fails the same way.