Уліковы запіс SSH-проксі можа працаваць без абалонкі
Захоўвайце перанакіраванне SSH даступным, адключаючы сеансы абалонкі і разумеючы межы прымусовага выкарыстання толькі SOCKS.
Спакунлівая налада — AllowTcpForwarding no. На жаль, яна таксама адключае перанакіраванне, патрэбнае лакальнаму SSH SOCKS-проксі. Дынамічнае перанакіраванне не ёсць лазейкай вакол палітыкі сервера.
Для выдзеленага ўліковага запісу OpenSSH раздзяляе некалькі магчымасцей. Фрагмент палітыкі можа дазволіць лакальнае перанакіраванне, забараняючы сеансы абалонкі і падсістэм:
Match User proxyuser
AllowTcpForwarding local
MaxSessions 0
PermitTTY no
X11Forwarding no
AllowAgentForwarding no
Кіраўніцтва сервера апісвае MaxSessions 0 як наладу, што забараняе сеансы абалонкі, уваходу і падсістэм, дазваляючы перанакіраванне. Убудуйце гэта ў існуючы аўтэнтыфікаваны ўліковы запіс; гэта не поўная канфігурацыя бяспекі SSH.
Толькі перанакіраванне — не толькі SOCKS
Фіксаванае лакальнае перанакіраванне і запыт SOCKS у рэшце рэшт могуць папрасіць у сервера злучэнне да адрасата таго ж тыпу. Дазвол лакальнага перанакіравання не гарантуе, што кліент выкарыстаў пэўны інтэрфейс SOCKS. Не апісвайце ўліковы запіс як такі, што прымушае выкарыстоўваць толькі SOCKS.
PermitOpen можа абмежаваць пары хаста і порта прызначэння, калі пэўны спіс адпавядае патрабаванню. Гэта не агульная забарона, якая ўлічвае развязанне імён хастоў, на кожную прыватную сетку. Шырэйшыя абмежаванні адрасоў могуць патрабаваць адпаведнай сеткавай палітыкі хаста.
Налады ўліковага запісу, ключа і ўключаныя налады сервера могуць дадаткова абмежаваць перанакіраванне. Агульная забарона перанакіравання ў іншым месцы можа выдаліць магчымасць, якую гэты фрагмент, здаецца, дазваляе.
Выкарыстайце звычайную працэдуру адміністравання сервера з шляхам аднаўлення, затым асобна ацаніце дазволеныя і забароненыя магчымасці. Мэтавы вынік — яўныя дазволы на перанакіраванне, а не інтэрактыўны ўваход, выпадкова пакінуты даступным, і не проксі, адключаны ўласным абмежаваннем.