ការកំណត់ដែលទាក់ទាញគឺ AllowTcpForwarding no។ ជាអកុសល វាក៏បិទ forwarding ដែល SSH SOCKS proxy មូលដ្ឋានត្រូវការ។ Dynamic forwarding មិនមែនជាចន្លោះដើម្បីគេចពីគោលនយោបាយម៉ាស៊ីនមេទេ។

សម្រាប់គណនីជាក់លាក់ OpenSSH បំបែកសមត្ថភាពជាច្រើន។ បំណែកគោលនយោបាយអាចអនុញ្ញាត forwarding មូលដ្ឋាន ខណៈទប់ស្កាត់សម័យ shell និង subsystem:

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

សៀវភៅណែនាំម៉ាស៊ីនមេ ពិពណ៌នា MaxSessions 0 ថាជាការកំណត់ដែលទប់ស្កាត់សម័យ shell ចូល និង subsystem ខណៈអនុញ្ញាត forwarding។ បញ្ចូលវាទៅក្នុងគណនីដែលបានផ្ទៀងផ្ទាត់រួច; នេះមិនមែនជាការកំណត់សុវត្ថិភាព SSH ពេញលេញទេ។

តែ forwarding មិនមែនតែ SOCKS

Forwarding មូលដ្ឋានថេរ និងសំណើ SOCKS អាចសុំការតភ្ជាប់គោលដៅប្រភេទដូចគ្នាពីម៉ាស៊ីនមេជាចុងក្រោយ។ ការអនុញ្ញាត forwarding មូលដ្ឋានមិនធានាថាអតិថិជនបានប្រើចំណុចប្រទាក់ SOCKS ជាក់លាក់ទេ។ កុំពិពណ៌នាគណនីថាជាការបង្ខំប្រើ SOCKS តែមួយ។

PermitOpen អាចកំណត់ គូ host និង port គោលដៅ នៅពេលបញ្ជីជាក់លាក់ត្រូវនឹងតម្រូវការ។ នេះមិនមែនជាការហាមឃាត់ទូទៅដែលដឹងពីការដោះស្រាយឈ្មោះ host សម្រាប់គ្រប់បណ្តាញឯកជនទេ។ ការកំណត់អាសយដ្ឋានធំទូលាយជាងអាចត្រូវការគោលនយោបាយបណ្តាញ host សមស្រប។

ការកំណត់គណនី សោ និងម៉ាស៊ីនមេដែលរួមបញ្ចូលអាចកំណត់ forwarding បន្ថែម។ ការហាមឃាត់ forwarding ជាសកលនៅកន្លែងផ្សេងអាចដកសមត្ថភាពដែលបំណែកនេះហាក់អនុញ្ញាត។

ប្រើនីតិវិធីគ្រប់គ្រងម៉ាស៊ីនមេធម្មតាជាមួយផ្លូវសង្គ្រោះ បន្ទាប់មកវាយតម្លៃសមត្ថភាពដែលអនុញ្ញាត និងដែលបដិសេធដោយឡែក។ លទ្ធផលដែលចង់បានគឺការអនុញ្ញាត forwarding ច្បាស់លាស់ មិនមែនការចូលអន្តរកម្មដែលបានបើកដោយអចេតនា ឬ proxy ដែលត្រូវបានបិទដោយដែនកំណត់របស់វាផ្ទាល់។

អត្ថបទពាក់ព័ន្ធ