Un account proxy SSH può funzionare senza shell

L'impostazione allettante è AllowTcpForwarding no. Sfortunatamente, disattiva anche l'inoltro che serve a un proxy SSH SOCKS locale. L'inoltro dinamico non è una scappatoia alla politica del server.

Per un account dedicato, OpenSSH separa diverse capacità. Un frammento di policy può consentire l'inoltro locale impedendo le sessioni shell e di sottosistema:

Match User proxyuser
    AllowTcpForwarding local
    MaxSessions 0
    PermitTTY no
    X11Forwarding no
    AllowAgentForwarding no

Il manuale del server descrive MaxSessions 0 come impostazione che impedisce le sessioni shell, di accesso e di sottosistema consentendo l'inoltro. Integrala in un account autenticato esistente; non è una configurazione di sicurezza SSH completa.

Solo inoltro non è solo SOCKS

Un inoltro locale fisso e una richiesta SOCKS possono alla fine chiedere al server lo stesso tipo di connessione di destinazione. Consentire l'inoltro locale non garantisce che un client abbia usato una particolare interfaccia SOCKS. Non descrivere l'account come impositore di un uso solo SOCKS.

PermitOpen può limitare coppie host e porta di destinazione quando un elenco specifico soddisfa il requisito. Non è un divieto generale consapevole della risoluzione dei nomi su ogni rete privata. Restrizioni di indirizzo più ampie possono richiedere un'adeguata policy di rete dell'host.

Le impostazioni di account, chiave e server incluso possono limitare ulteriormente l'inoltro. Un divieto generale di inoltro altrove può rimuovere una capacità che questo frammento sembra consentire.

Usa la normale procedura di amministrazione del server con un percorso di ripristino, poi valuta separatamente le capacità consentite e negate. Il risultato voluto sono permessi di inoltro espliciti, non un accesso interattivo lasciato disponibile per errore né un proxy disattivato dalla propria restrizione.