If you’ve ever tried to use SSH port forwarding and hit the error:
channel 3: open failed: administratively prohibited: open failed
you’re not alone.
This error usually means the SSH server rejected your request to open a new channel — most commonly because port forwarding is disabled or restricted by policy.
Below is a complete guide to understanding what this error means, what causes it, and how to fix it step by step.
🔍 What the Error Actually Means
When you run an SSH command like:
ssh -L 8080:localhost:80 user@remote-serveryour SSH client asks the server to create a new “channel” to forward traffic.
If the server refuses — for example, if AllowTcpForwarding or DisableForwarding settings block it — you’ll see:
channel N: open failed: administratively prohibited: open failed
Here’s what’s happening under the hood:
- “channel N” — a logical connection over the SSH tunnel.
- “administratively prohibited” — the SSH daemon (
sshd) is explicitly configured to deny the operation.
Table of Contents
🧰 Step 1: Check Server-Side Configuration
On the remote server, edit /etc/ssh/sshd_config:
See also: Mastering the Linux Command Line — Your Complete Free Training Guide
sudo vi /etc/ssh/sshd_config
Look for or add the following lines:
AllowTcpForwarding yes
PermitTunnel yes
DisableForwarding no
Here’s what each does:
- AllowTcpForwarding yes → enables port forwarding (both local and remote).
- PermitTunnel yes → allows tunneling (e.g., VPN-style connections via tun devices).
- DisableForwarding no → ensures that even users with restricted configurations can use forwarding.
Then reload SSH:
sudo systemctl restart sshd
💡 Step 2: Confirm Client Command Syntax
Make sure your SSH command is correct.
Common forwarding modes include:
Local port forwarding
ssh -L 8080:localhost:80 user@server
→ Connects to your local 8080 and forwards traffic to port 80 on the remote.
Remote port forwarding
ssh -R 9090:localhost:22 user@server
→ Makes port 9090 on the remote machine connect back to local port 22.
Dynamic (SOCKS) forwarding
ssh -D 1080 user@server
→ Creates a local SOCKS5 proxy on port 1080.
🔒 Step 3: Review SSH User Restrictions
Even if forwarding is enabled globally, it can still be blocked per user.
Check the Match blocks in /etc/ssh/sshd_config.
For example:
Match User limiteduser
DisableForwarding yes
This overrides global settings.
If present, remove or modify these lines, then restart SSH.
🔥 Step 4: Check Firewalls and Network Rules
SSH forwarding depends on multiple ports being reachable:
- The SSH port (usually 22)
- The forwarded destination port
On RHEL-based systems, check with:
sudo firewall-cmd --list-all
On Debian-based systems:
sudo ufw status verbose
Make sure the required ports are open or not blocked by corporate firewalls, cloud security groups, or network ACLs.
📜 Step 5: Examine Server Logs
Server logs reveal exactly why the channel failed.
Check:
- RHEL/CentOS →
/var/log/secure - Debian/Ubuntu →
/var/log/auth.log
Search for lines like:
sshd[xxxx]: error: open request denied due to administrative prohibition
These log messages often point to a specific policy (e.g., DenyUsers, Match blocks, or SELinux).
⚙️ Step 6: Review MaxStartups and Connection Limits
If you’re making many concurrent SSH connections (for automation or batch jobs), the daemon might refuse new channels due to the MaxStartups limit.
In /etc/ssh/sshd_config, check:
MaxStartups 50
This setting controls how many unauthenticated connections SSHD allows before dropping requests.
Restart SSH afterward:
sudo systemctl restart sshd
🧱 Step 7: Check SELinux or AppArmor Policies
In hardened systems (like corporate environments or cloud images), tools like SELinux or AppArmor might block SSH forwarding silently.
Check SELinux status:
getenforce
If it returns Enforcing, check for denials:
sudo ausearch -m avc -ts recent | grep sshd
For AppArmor (Ubuntu):
sudo aa-status
If sshd is confined, look for a profile that restricts forwarding.
🧩 Step 8: Client-Side Debugging
Finally, if it still fails, use verbose SSH logging:
ssh -vvv -L 8080:localhost:80 user@server
This will print detailed negotiation logs including:
- Which algorithms are used
- Whether port forwarding requests are sent and accepted
- Any channel creation failures
✅ Summary
| Possible Cause | Fix |
|---|---|
AllowTcpForwarding disabled | Enable it in /etc/ssh/sshd_config |
DisableForwarding set to yes | Change it to no |
User-specific Match block | Remove or edit it |
| Firewall blocking ports | Open necessary ports |
| Too many connections | Increase MaxStartups |
| SELinux/AppArmor restrictions | Adjust or disable temporarily |
🚀 Example: Automated Fix Script
If you have sudo access, you can apply the core fixes automatically:
sudo sed -i '/^AllowTcpForwarding/d' /etc/ssh/sshd_config
sudo sed -i '/^DisableForwarding/d' /etc/ssh/sshd_config
sudo bash -c 'echo "AllowTcpForwarding yes" >> /etc/ssh/sshd_config'
sudo bash -c 'echo "DisableForwarding no" >> /etc/ssh/sshd_config'
sudo systemctl restart sshd
