SSH proxy kontu bat shellik gabe lan egin dezake
Mantendu SSH birbidalketa eskuragarri shell saioak desgaituta eta ulertu SOCKS soilik derrigortzearen mugak.
Ezarpen tentagarria AllowTcpForwarding no da. Zoritxarrez, SSH SOCKS proxy lokal batek behar duen birbidalketa ere desgaitzen du. Birbidalketa dinamikoa ez da zerbitzariaren politika saihesteko zirrikitu bat.
Kontu dedikatu baterako, OpenSSH-k hainbat gaitasun bereizten ditu. Politika-zati batek birbidalketa lokala baimendu dezake shell eta azpisistema saioak eragotziz:
Match User proxyuser
AllowTcpForwarding local
MaxSessions 0
PermitTTY no
X11Forwarding no
AllowAgentForwarding no
Zerbitzariaren eskuliburuak MaxSessions 0 shell, saioa hasteko eta azpisistema saioak eragozten dituen eta birbidalketa baimentzen duen ezarpen gisa deskribatzen du. Integra ezazu lehendik dagoen kontu autentifikatu batean; ez da SSH segurtasun konfigurazio oso bat.
Birbidalketa soilik ez da SOCKS soilik
Birbidalketa lokal finko batek eta SOCKS eskaera batek azkenean helmugako konexio mota bera eska diezaiokete zerbitzariari. Birbidalketa lokala baimentzeak ez du bermatzen bezeroak SOCKS interfaze jakin bat erabili duenik. Ez deskribatu kontua SOCKS soilik erabiltzea derrigortzen duen gisa.
PermitOpen-k helmugako ostalari eta portu bikoteak mugatu ditzake zerrenda zehatz bat baldintzara egokitzen denean. Ez da host-izen ebazpena kontuan hartzen duen debeku orokor bat sare pribatu bakoitzerako. Helbide-murrizketa zabalagoek ostalari-sare politika egokia behar dezakete.
Kontu, gako eta sartutako zerbitzari ezarpenek birbidalketa gehiago murrizten dezakete. Beste leku bateko birbidalketa debeku orokor batek zati honek baimentzen duen gaitasun bat ken dezake.
Erabili zerbitzariaren administrazio prozedura arrunta berreskuratze-bide batekin, eta gero ebaluatu baimendutako eta ukatutako gaitasunak bereizita. Nahi den emaitza birbidalketa-baimen esplizituak dira, ez ustekabean eskuragarri utzitako saio-hasiera interaktiboa ezta bere murrizketak desgaitu duen proxy bat ere.