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 ચોક્કસ યાદી જરૂરિયાતને અનુરૂપ હોય ત્યારે ગંતવ્ય હોસ્ટ અને પોર્ટ જોડીઓ મર્યાદિત કરી શકે છે. તે દરેક ખાનગી નેટવર્ક પર હોસ્ટનામ-રિઝોલ્યુશનને ધ્યાનમાં લેતું સામાન્ય પ્રતિબંધ નથી. વિશાળ સરનામા પ્રતિબંધો માટે યોગ્ય હોસ્ટ નેટવર્ક નીતિની જરૂર પડી શકે છે.

ખાતા, કી અને સમાવિષ્ટ સર્વર સેટિંગ્સ ફોરવર્ડિંગને વધુ મર્યાદિત કરી શકે છે. અન્યત્ર સર્વવ્યાપી ફોરવર્ડિંગ પ્રતિબંધ આ અંશ મંજૂરી આપતો લાગતો ક્ષમતા દૂર કરી શકે છે.

પુનઃપ્રાપ્તિ માર્ગ સાથે સામાન્ય સર્વર વ્યવસ્થાપન પ્રક્રિયા વાપરો, પછી મંજૂર અને નકારેલ ક્ષમતાઓનું અલગથી મૂલ્યાંકન કરો. ઇચ્છિત પરિણામ સ્પષ્ટ ફોરવર્ડિંગ પરવાનગીઓ છે, આકસ્મિક રીતે ખુલ્લું રહી ગયેલું ઇન્ટરેક્ટિવ લોગિન કે પોતાની મર્યાદાથી નિષ્ક્રિય થયેલી પ્રોક્સી નહીં.