Een SSH-proxyaccount kan werken zonder shell

De verleidelijke instelling is AllowTcpForwarding no. Helaas schakelt die ook het doorsturen uit dat een lokale SSH SOCKS-proxy nodig heeft. Dynamisch doorsturen is geen achterdeur om het serverbeleid heen.

Voor een speciaal account scheidt OpenSSH verschillende mogelijkheden. Een beleidsfragment kan lokaal doorsturen toestaan en tegelijk shell- en subsysteemsessies voorkomen:

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

De serverhandleiding beschrijft MaxSessions 0 als een instelling die shell-, login- en subsysteemsessies voorkomt en tegelijk doorsturen toestaat. Integreer dit in een bestaand geauthenticeerd account; het is geen volledige SSH-beveiligingsconfiguratie.

Alleen doorsturen is niet alleen SOCKS

Een vaste lokale doorsturing en een SOCKS-verzoek kunnen de server uiteindelijk om hetzelfde soort bestemmingsverbinding vragen. Lokaal doorsturen toestaan garandeert niet dat een client een bepaalde SOCKS-interface heeft gebruikt. Beschrijf het account niet als een dat alleen-SOCKS-gebruik afdwingt.

PermitOpen kan bestemmingshost- en poortparen beperken wanneer een specifieke lijst aan de eis voldoet. Het is geen algemeen verbod dat rekening houdt met hostnaamresolutie voor elk particulier netwerk. Ruimere adresbeperkingen kunnen een passend hostnetwerkbeleid vereisen.

Account-, sleutel- en inbegrepen serverinstellingen kunnen het doorsturen verder beperken. Een algemeen doorstuurverbod elders kan een mogelijkheid wegnemen die dit fragment lijkt toe te staan.

Gebruik de normale serverbeheerprocedure met een herstelpad en beoordeel daarna toegestane en geweigerde mogelijkheden afzonderlijk. Het beoogde resultaat is expliciete doorstuurmachtigingen, niet een interactieve login die per ongeluk beschikbaar bleef of een proxy die door zijn eigen beperking is uitgeschakeld.