En SSH-proxykonto kan fungere uden en shell

Den fristende indstilling er AllowTcpForwarding no. Uheldigvis deaktiverer den også den videresendelse, som en lokal SSH SOCKS-proxy har brug for. Dynamisk videresendelse er ikke et smuthul uden om serverpolitikken.

For en dedikeret konto adskiller OpenSSH flere egenskaber. Et politikfragment kan tillade lokal videresendelse og samtidig forhindre shell- og undersystemssessioner:

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

Servermanualen beskriver MaxSessions 0 som en indstilling, der forhindrer shell-, login- og undersystemssessioner og samtidig tillader videresendelse. Integrer den i en eksisterende godkendt konto; den er ikke en fuldstændig SSH-sikkerhedskonfiguration.

Kun videresendelse er ikke kun SOCKS

En fast lokal videresendelse og en SOCKS-anmodning kan i sidste ende bede serveren om den samme slags destinationsforbindelse. Tilladelse af lokal videresendelse garanterer ikke, at en klient brugte en bestemt SOCKS-grænseflade. Beskriv ikke kontoen som håndhævende kun-SOCKS-brug.

PermitOpen kan begrænse destinationsvært- og portpar, når en bestemt liste passer til kravet. Det er ikke et generelt forbud, der tager højde for værtsnavnsopløsning, mod ethvert privat netværk. Bredere adressebegrænsninger kan kræve en passende værtsnetværkspolitik.

Konto-, nøgle- og inkluderede serverindstillinger kan begrænse videresendelse yderligere. Et generelt videresendelsesforbud andetsteds kan fjerne en egenskab, som dette fragment ser ud til at tillade.

Brug den normale serveradministrationsprocedure med en gendannelsesvej, og vurder derefter tilladte og afviste egenskaber hver for sig. Det tilsigtede resultat er udtrykkelige videresendelsestilladelser, ikke et interaktivt login, der ved et uheld er ladt tilgængeligt, eller en proxy, der er deaktiveret af sin egen begrænsning.