SSH վստահված հաշիվը կարող է աշխատել առանց shell-ի

Գայթակղիչ կարգավորումը AllowTcpForwarding no-ն է։ Ցավոք, այն անջատում է նաև այն փոխանցումը, որը անհրաժեշտ է տեղական SSH SOCKS վստահվածին։ Դինամիկ փոխանցումը սերվերի քաղաքականությունը շրջանցող բացվածք չէ։

Նվիրված հաշվի համար OpenSSH-ը բաժանում է մի քանի հնարավորություններ։ Քաղաքականության հատվածը կարող է թույլատրել տեղական փոխանցումը՝ միաժամանակ արգելելով shell և ենթահամակարգային նստաշրջանները.

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

Սերվերի ձեռնարկը MaxSessions 0-ը նկարագրում է որպես կարգավորում, որն արգելում է shell, մուտքի և ենթահամակարգային նստաշրջանները՝ թույլատրելով փոխանցումը։ Ներառեք այն գոյություն ունեցող նույնականացված հաշվում. սա ամբողջական SSH անվտանգության կոնֆիգուրացիա չէ։

Միայն փոխանցումը միայն SOCKS չէ

Հաստատուն տեղական փոխանցումը և SOCKS հարցումը ի վերջո կարող են սերվերից պահանջել նույն տիպի նպատակային կապ։ Տեղական փոխանցման թույլտվությունը չի երաշխավորում, որ հաճախորդն օգտագործել է որոշակի SOCKS ինտերֆեյս։ Մի նկարագրեք հաշիվը որպես միայն SOCKS օգտագործում պարտադրող։

PermitOpen-ը կարող է սահմանափակել նպատակակետի հոսթի և պորտի զույգերը, երբ կոնկրետ ցանկը համապատասխանում է պահանջին։ Սա ընդհանուր արգելք չէ, որը հաշվի է առնում հոսթանունների լուծումը յուրաքանչյուր մասնավոր ցանցի համար։ Ավելի լայն հասցեային սահմանափակումները կարող են պահանջել համապատասխան հոսթային ցանցի քաղաքականություն։

Հաշվի, բանալու և ներառված սերվերի կարգավորումները կարող են ավելի սահմանափակել փոխանցումը։ Այլ տեղում գործող համատարած փոխանցման արգելքը կարող է հեռացնել հնարավորություն, որը այս հատվածը կարծես թույլատրում է։

Օգտագործեք սովորական սերվերի կառավարման ընթացակարգը՝ վերականգնման ուղով, ապա առանձին գնահատեք թույլատրված և արգելված հնարավորությունները։ Նպատակային արդյունքը բացահայտ փոխանցման թույլտվություններն են, ոչ թե պատահաբար հասանելի թողնված ինտերակտիվ մուտքը կամ սեփական սահմանափակումով անջատված վստահվածը։