একটি 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 নির্দিষ্ট তালিকা প্রয়োজন মেটালে গন্তব্য হোস্ট ও পোর্ট জোড়া সীমিত করতে পারে। এটি প্রতিটি ব্যক্তিগত নেটওয়ার্কে হোস্টনেম-রিজলিউশন সচেতন সাধারণ নিষেধ নয়। বিস্তৃত ঠিকানা নিষেধাজ্ঞার জন্য উপযুক্ত হোস্ট নেটওয়ার্ক নীতি প্রয়োজন হতে পারে।

অ্যাকাউন্ট, কী এবং অন্তর্ভুক্ত সার্ভার সেটিংস ফরওয়ার্ডিং আরও সীমিত করতে পারে। অন্যত্র সর্বব্যাপী ফরওয়ার্ডিং নিষেধ এই অংশ যেটি অনুমোদন করে বলে মনে হয় সেই সক্ষমতা সরিয়ে দিতে পারে।

পুনরুদ্ধার পথসহ স্বাভাবিক সার্ভার প্রশাসন পদ্ধতি ব্যবহার করুন, তারপর অনুমোদিত ও নিষিদ্ধ সক্ষমতা আলাদাভাবে মূল্যায়ন করুন। অভীষ্ট ফল হলো স্পষ্ট ফরওয়ার্ডিং অনুমতি, আকস্মিকভাবে খোলা রাখা ইন্টারঅ্যাকটিভ লগইন বা নিজের নিষেধাজ্ঞায় নিষ্ক্রিয় হওয়া প্রক্সি নয়।