Cosa vedi
La sessione si apre normalmente. Il messaggio compare quando qualcosa usa il tunnel, non quando ti connetti, e compare nel terminale dove gira ssh:
channel 3: open failed: administratively prohibited: open failedIl programma che usa il tunnel fallisce separatamente, con un suo messaggio. Un client SSH che passa dal tunnel, per esempio, stampa kex_exchange_identification: read: Connection reset by peer.
Forme correlate generate dalle stesse impostazioni:
| Cosa hai eseguito | Output |
|---|---|
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, poi stdio forwarding failed |
ssh -R | Warning: remote port forwarding failed for listen port 8080 |
Un finale diverso indica un problema diverso. open failed: connect failed: Connection refused significa che l'inoltro era permesso, ma sull'host e sulla porta di destinazione non c'è nulla in ascolto. Correggi la destinazione, non la configurazione.
Quale impostazione lo causa
| Dove | Impostazione | Blocca |
|---|---|---|
sshd_config | AllowTcpForwarding no | -L, -D, -W, -J e -R |
sshd_config | AllowTcpForwarding remote | -L, -D, -W e -J |
sshd_config | AllowTcpForwarding local | -R |
sshd_config | DisableForwarding yes | Ogni inoltro, prevalendo sulle altre impostazioni |
sshd_config | PermitOpen 127.0.0.1:5432 | -L verso qualsiasi destinazione non in elenco |
sshd_config | PermitListen 9000 | -R su qualsiasi porta non in elenco |
authorized_keys | restrict o no-port-forwarding | L'inoltro quando accedi con quella chiave |
authorized_keys | permitopen="127.0.0.1:5432" | -L con quella chiave verso qualsiasi altra destinazione |
Le opzioni delle chiavi come restrict e permitopen sono spiegate riga per riga in il file authorized_keys spiegato.
Trovare quale si applica a te
Servono i diritti di amministratore sul server. Chiedi a sshd cosa applicherebbe al tuo utente. Il semplice sshd -T ignora i blocchi Match, quindi includi i dettagli della connessione. In una prova, la forma semplice indicava yes mentre il valore reale dell'utente era no:
sudo sshd -T -C user=name,host=server,addr=203.0.113.10 | grep -iE '^(allowtcpforwarding|disableforwarding|permitopen|permitlisten)'Guarda anche le opzioni prima della chiave nel file di quell'utente:
sudo cut -c1-60 ~name/.ssh/authorized_keysIl log del server indica la destinazione rifiutata:
refused local port forward: originator 127.0.0.1 port 65535, target 127.0.0.1 port 22Come risolvere
Se il server non è tuo, chiedi all'amministratore. Il blocco di solito è voluto, perché un tunnel permette a un utente di raggiungere dall'esterno sistemi interni. Spiega quale host e quale porta ti servono, così potrà permettere solo quelli.
Se il server è tuo, preferisci una regola stretta ad abilitare l'inoltro per tutti. Metti questo in fondo a sshd_config:
Match User name
AllowTcpForwarding local
PermitOpen 127.0.0.1:5432Poi verifica e ricarica. Il servizio si chiama ssh su Debian e Ubuntu e sshd sui sistemi in stile Red Hat:
sudo sshd -t && sudo systemctl reload sshTieni presente che per la maggior parte delle parole chiave sshd usa il primo valore che legge. Se una riga in alto dice AllowTcpForwarding no, un yes più in basso non ha effetto. Su Debian e Ubuntu i file in /etc/ssh/sshd_config.d/ vengono letti per primi, quindi controlla anche lì. Esegui di nuovo sshd -T dopo la modifica per vedere il risultato.
Per una chiave con restrizioni, cambia le opzioni sulla sua riga in authorized_keys. Ha effetto al login successivo, senza ricaricare nulla. Per esempio, una chiave con restrict può riavere un solo tunnel:
restrict,port-forwarding,permitopen="127.0.0.1:5432" ssh-ed25519 AAAA... user@laptopVedi come limitare una chiave SSH.
Domande
Administratively prohibited vuol dire che password o chiave sono sbagliate?
No. L'accesso è riuscito. È la configurazione del server a rifiutare questo inoltro, quindi solo le sue impostazioni o le opzioni della tua chiave possono cambiare il risultato.
Come consento il port forwarding a un solo utente?
Aggiungi in fondo a sshd_config un blocco Match User nome con AllowTcpForwarding local e una riga PermitOpen per la destinazione, poi esegui sshd -t e ricarica il servizio.
Perché ssh -J fallisce con administratively prohibited?
Un jump host deve inoltrare TCP per far passare la tua connessione. Se ha AllowTcpForwarding no o remote, o la tua chiave ha restrict, la connessione con -J fallisce allo stesso modo.
Fonti
- sshd_config(5), AllowTcpForwarding, PermitOpen, DisableForwarding
- sshd(8), opzioni di authorized_keys