ʼn SSH-proxyrekening kan sonder ʼn dop werk

Hou SSH-deurvoer beskikbaar terwyl dop-sessies gedeaktiveer word en verstaan die perke van slegs-SOCKS-afdwinging.

Die aanloklike instelling is AllowTcpForwarding no. Ongelukkig skakel dit ook die deurvoer uit wat ʼn plaaslike SSH-SOCKS-volmagwaarnemer nodig het. Dinamiese deurvoer is nie ʼn sluipweg om bedienerbeleid nie.

Vir ʼn toegewyde rekening skei OpenSSH verskeie vermoëns. ʼn Beleidsfragment kan plaaslike deurvoer toelaat terwyl dop- en substelselsessies verhoed word:

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

Die bedienerhandleiding beskryf MaxSessions 0 as ʼn instelling wat dop-, aanmeld- en substelselsessies verhoed terwyl deurvoer toegelaat word. Integreer dit in ʼn bestaande geoutentiseerde rekening; dit is nie ʼn volledige SSH-veiligheidskonfigurasie nie.

Slegs deurvoer is nie slegs SOCKS nie

ʼn Vaste plaaslike deurvoer en ʼn SOCKS-versoek kan uiteindelik dieselfde soort bestemmingsverbinding by die bediener aanvra. Om plaaslike deurvoer toe te laat, waarborg nie dat ʼn kliënt ʼn bepaalde SOCKS-koppelvlak gebruik het nie. Moenie die rekening beskryf asof dit slegs-SOCKS-gebruik afdwing nie.

PermitOpen kan bestemming-gasheer-en-poortpare beperk wanneer ʼn spesifieke lys by die vereiste pas. Dit is nie ʼn algemene verbod, bewus van gasheernaamoplossing, op elke private netwerk nie. Breër adresbeperkings mag ʼn gepaste gasheernetwerkbeleid nodig hê.

Rekening-, sleutel- en ingeslote bedienerinstellings kan deurvoer verder beperk. ʼn Algehele deurvoerverbod elders kan ʼn vermoë verwyder wat hierdie fragment blykbaar toelaat.

Gebruik die normale bedieneradministrasieprosedure met ʼn herstelpad, en beoordeel dan toegelate en geweierde vermoëns afsonderlik. Die beoogde uitkoms is eksplisiete deurvoertoestemmings, nie ʼn interaktiewe aanmelding wat per ongeluk beskikbaar gelaat is of ʼn volmagwaarnemer wat deur sy eie beperking gedeaktiveer is nie.

Verwante artikels