ওপেনএসএসএইচ/ক্লায়েন্ট কনফিগারেশন ফাইল

ক্লায়েন্ট কনফিগারেশন ফাইলগুলো ব্যবহারকারী-ভিত্তিক বা সিস্টেম-ভিত্তিক হতে পারে, যেখানে প্রথমটি দ্বিতীয়টির উপর অগ্রাধিকার পায় এবং শেলের কাজ করার সময় বা রান-টাইম আর্গুমেন্ট উভয়কেই ওভাররাইড করে। এই কনফিগারেশন ফাইলগুলোতে, প্রতি লাইনে একটি পরিমিতি ব্যবহারের অনুমতি আছে। এর বাক্যতত্ত্ব হলো পরিমিতি নামের পরে তার মান বা মানগুলো। খালি লাইন এবং হ্যাশ (#) চিহ্ন দিয়ে শুরু হওয়া লাইন উপেক্ষা করা হয়। পরিমিতির নাম এবং মানগুলোর মধ্যে স্পেসের পরিবর্তে একটি সমান চিহ্ন (=) ব্যবহার করা যেতে পারে। মানগুলো কেস-সেনসিটিভ বা অক্ষর-সংবেদনশীল, কিন্তু পরিমিতির নাম অক্ষর-সংবেদনশীল নয়। প্রথমে যে মানটি নির্ধারিত করা করা হয়, সেটিই ব্যবহৃত হয়। প্রধান ফাইলের ক্ষেত্রে বিন্যাসটি ভিন্ন।

উভয় ধরণের ফাইলের ক্ষেত্রেই, সংশ্লিষ্ট যন্ত্রগুলোর প্রাসঙ্গিক নির্দেশিকা পাতাগুলো পড়ার কোনো বিকল্প নেই, বিশেষ করে কারণ সেগুলো ব্যবহৃত নির্দিষ্ট সংস্করণগুলোর সাথে মেলে।

সিস্টেম-ভিত্তিক ক্লায়েন্ট কনফিগারেশন ফাইল

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

1. শেলের মাধ্যমে রানটাইম আর্গুমেন্ট
2. ব্যবহারকারীর নিজস্ব কনফিগারেশন
3. সিস্টেম-ভিত্তিক কনফিগারেশন

প্রাপ্ত প্রথম মানটিই ব্যবহৃত হয়। ব্যবহারকারীর নিজস্ব কনফিগারেশন ফাইল এবং সিস্টেম-ব্যাপী কনফিগারেশন ফাইলও ওপেনএসএসএইচ ৭.৩ থেকে শুরু করে ইনক্লুড নির্দেশিকা ব্যবহার করে অন্তর্ভুক্ত করার জন্য অতিরিক্ত কনফিগারেশন ফাইল নির্দেশ করতে পারে। ইনক্লুড নির্দেশিকা কনফিগারেশন ফাইলের যেকোনো জায়গায়, এমনকি ম্যাচ বা হোস্ট ব্লকের ভিতরেও নির্দিষ্ট করা যেতে পারে। কনফিগারেশন নেস্টিং করার সময় সতর্কতা অবলম্বন করা উচিত।

/etc/ssh/ssh_config

এই ফাইলটি সেই সিস্টেমের সকল ব্যবহারকারীর জন্য ক্লায়েন্ট ইউটিলিটিগুলির সমস্ত পূর্বনির্ধারিত বিকল্প নির্ধারণ করে। এটি অবশ্যই সকল ব্যবহারকারীর দ্বারা পাঠযোগ্য হতে হবে। কনফিগারেশন বিকল্পগুলি ssh_config(5) এ বিস্তারিতভাবে বর্ণনা করা হয়েছে।

নিচে arc.example.org-এ সংযোগ করার জন্য একটি শর্টকাট দেওয়া হলো ।

Host arc
        Port 2022
        HostName arc.example.org
        User fred
        IdentityFile ~/.ssh/id_rsa_arc

সুতরাং, এই কনফিগারেশনটি থাকলে শুধু তথ্য প্রবেশ করালেই ssh arc ও বাকি তথ্যগুলো স্বয়ংক্রিয়ভাবে পূরণ হয়ে যায়।

/etc/ssh/ssh_known_hosts

এতে রিমোট হোস্টের পরিচয় যাচাই করতে এবং এর মাধ্যমে ছদ্মবেশ ধারণ বা আড়িপাতা প্রতিরোধ করতে ব্যবহৃত পরিচিত হোস্ট কী-গুলোর সিস্টেম-ভিত্তিক তালিকা থাকে। এই ফাইলটি সিস্টেম প্রশাসক দ্বারা প্রস্তুত করা উচিত, যাতে সমস্ত প্রয়োজনীয় হোস্টের পাবলিক হোস্ট কী-গুলো অন্তর্ভুক্ত থাকে। এটি সর্বসাধারণের পাঠযোগ্য হওয়া উচিত।

আরও ব্যাখ্যার জন্য নিচে ~/.ssh/known_hosts দেখুন অথবা এই ফাইলের বিন্যাস সম্পর্কে আরও বিস্তারিত জানতে এসএসএইচডি(৮) দেখুন।

/etc/ssh/sshrc

এই ফাইলটি সার্ভারে থাকে এবং ব্যবহারকারী প্রবেশ করার সময়, তার শেল বা নির্ধারিত প্রোগ্রাম শুরু হওয়ার ঠিক আগে, এসএসএইচ(১) এর মাধ্যমে এই ফাইলের প্রোগ্রামগুলি সেখানে চালানো হয়। এটি রুট হিসেবে চলে না, বরং যে ব্যবহারকারী প্রবেশ করছেন, তার হিসেবেই চলে। আরও তথ্যের জন্য এসএসএইচডি(৮) নির্দেশিকা পাতার "SSHRC" বিভাগটি দেখুন। যদি এটি stdout এ কিছু পাঠায়, তবে তা অন্যান্যদের মধ্যে এসএফটিপি সেশনে হস্তক্ষেপ করবে। তাই যদি কোনো আউটপুট তৈরি হয়, তবে তা stderr বা একটি লগ ফাইলে পাঠানো উচিত।

ব্যবহারকারী-ভিত্তিক ক্লায়েন্ট কনফিগারেশন ফাইল

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

ক্লায়েন্ট-সাইড ফাইল

এই ফাইলগুলো ক্লায়েন্ট মেশিনে থাকে।

~/.ssh/config

ব্যবহারকারীর নিজস্ব কনফিগারেশন ফাইল যা, প্রযোজ্য ক্ষেত্রে, বৈশ্বিক ক্লায়েন্ট কনফিগারেশন ফাইল, /etc/ssh/ssh_config এর সেটিংসকে ওভাররাইড করে। কনফিগারেশন বিকল্পগুলি এসএসএইচ_কনফিগ(৫) এ বিস্তারিতভাবে বর্ণনা করা হয়েছে।

এই ফাইলটি অন্য ব্যবহারকারীদের কাছে কোনোভাবেই প্রবেশযোগ্য হবে না। কঠোর অনুমতি নির্ধারণ করা: ব্যবহারকারীর জন্য পঠন/লিখন অনুমতি থাকবে এবং অন্য কেউ এটিতে প্রবেশ করতে পারবে না। যদি শুধুমাত্র সেই ব্যবহারকারীই উক্ত দলের একমাত্র সদস্য হন, তবেই এটি দল-লিখনযোগ্য হতে পারে।

ক্লায়েন্টের পূর্বনির্ধারিতগুলোর স্থানীয় ওভাররাইড

ফাইলটির নাম সাধারণত ~/.ssh/config হয়। তবে, -F বিকল্প ব্যবহার করে চলতি সময়ে একটি ভিন্ন কনফিগারেশন ফাইল নির্দিষ্ট করা যেতে পারে। সমস্ত হোস্টের জন্য প্রযোজ্য সাধারণ বিকল্পগুলো সব হোস্টকে সদৃশ করার মাধ্যমে সেট করা যায় এবং এটি কনফিগারেশন ফাইলের শেষে করা উচিত। প্রথম সদৃশটি অগ্রাধিকার পায়, তাই আরও সুনির্দিষ্ট সংজ্ঞাগুলো প্রথমে এবং আরও সাধারণ ওভাররাইডগুলো ফাইলের শেষে রাখতে হবে।

Host server1
        ServerAliveInterval	200
        HostName	203.0.113.76

Host *
        ExitOnForwardFailure	yes
        Protocol	2
        ServerAliveInterval	400

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

~/.ssh/known_hosts

এই ফাইলটি ব্যবহারকারী অ্যাকাউন্টের জন্য স্থানীয় এবং এতে রিমোট হোস্টের জন্য পরিচিত কী থাকে। প্রায়শই প্রথমবার সংযোগ করার সময় হোস্ট থেকে এগুলি সংগ্রহ করা হয়, তবে এগুলি ম্যানুয়ালিও যোগ করা যেতে পারে। বৈশ্বিক ফাইল, /etc/ssh/ssh_known_hosts-এ সংরক্ষিত কীগুলির মতোই, এই কীগুলি রিমোট হোস্টের পরিচয় যাচাই করতে ব্যবহৃত হয়, যার ফলে ছদ্মবেশ ধারণ বা ম্যান-ইন-দ্য-মিডল আক্রমণ থেকে সুরক্ষা পাওয়া যায়। পরবর্তী প্রতিটি সংযোগের সময়, এই কী-টি রিমোট সার্ভার দ্বারা প্রদত্ত কী-এর সাথে তুলনা করা হবে। যদি মিল পাওয়া যায়, তবে সংযোগটি এগিয়ে যাবে। যদি মিল না পাওয়া যায়, এসএসএইচ(১) একটি ত্রুটি বার্তা সহ ব্যর্থ হবে। যদি সেই রিমোট হোস্টের জন্য কোনও কী তালিকাভুক্ত না থাকে, তবে কী-এর ফিঙ্গারপ্রিন্ট প্রদর্শিত হবে এবং ফাইলটিতে স্বয়ংক্রিয়ভাবে কী যোগ করার বিকল্প থাকবে। এই ফাইলটি ম্যানুয়ালি তৈরি এবং সম্পাদনা করা যেতে পারে, তবে যদি এটি বিদ্যমান না থাকে তবে এসএসএইচ(১) যখন প্রথমবার কোনও রিমোট হোস্টে সংযোগ করে তখন এটি স্বয়ংক্রিয়ভাবে তৈরি করবে।

~/.ssh/known_hosts ফাইলে হ্যাশ করা বা সাধারণ টেক্সট হোস্ট নাম উভয়ই ব্যবহার করা যেতে পারে। এমনকি হ্যাশ করা নাম দিয়েও এসএসএইচ-কীজেন(১) এর -F অপশন ব্যবহার করে এটি অনুসন্ধান করা সম্ভব।

$ ssh-keygen -F server3.example.com

পূর্বনির্ধারিতভাবে যে ফাইলটি খোঁজা হবে তা হলো ~/.ssh/known_hosts এবং কী-টি খুঁজে পাওয়া গেলে তা প্রিন্ট করা হয়। -f বিকল্প ব্যবহার করে অন্য কোনো ফাইল খোঁজা যেতে পারে। যদি ফাইল থেকে কোনো কী মুছে ফেলার প্রয়োজন হয়, তবে -R অপশনটি একইভাবে কাজ করে; এটি হোস্ট দ্বারা অনুসন্ধান করে এবং হোস্টের নাম হ্যাশ করা থাকলেও খুঁজে পেলে তা মুছে ফেলে।

$ ssh-keygen -R server4.example.com -f ~/.ssh/known_hosts

যখন কোনো কী মুছে ফেলা হয়, তখন পরবর্তীতে প্রয়োজনের ক্ষেত্রে ব্যবহারের জন্য এটি ~/.ssh/known_hosts.old ফাইলে যুক্ত করা হবে। এই known_host ফাইলগুলির বিন্যাসের জন্য এসএসএইচডি(৮) এর নির্দেশিকা পাতাটি দেখুন।

যদি -F বা -R এর সাথে কোনো অ-পূর্বনির্ধারিত বা নন-ডিফল্ট ফাইল ব্যবহার করা হয়, তাহলে পথ সহ নামটি অবশ্যই -f ব্যবহার করে উল্লেখ করতে হবে। কিন্তু পূর্বনির্ধারিত ফাইল ব্যবহার করতে চাইলে -f ব্যবহার ঐচ্ছিক।

যদি /etc/ssh/ssh_known_hosts বৈশ্বিক ফাইলটি ব্যবহার করা হয়, তবে সিস্টেম প্রশাসককে অবশ্যই ফাইলটি প্রস্তুত করতে হবে যাতে এতে সমস্ত প্রয়োজনীয় হোস্টের পাবলিক হোস্ট কী থাকে এবং এটি যেন বৈশ্বিক পাঠযোগ্য হয়।

~/.ssh/known_hosts-এ ম্যানুয়ালি পাবলিক কী যোগ করা

known_hosts ফাইলে ম্যানুয়ালি পাবলিক হোস্ট কী যোগ করার জন্য, প্রতিটি কী-এর জন্য একটি করে অবিচ্ছিন্ন লাইন যোগ করতে হয়। কী-টি কীভাবে সংগ্রহ করা হয়েছে তা গুরুত্বপূর্ণ নয়, যতক্ষণ পর্যন্ত এটি সম্পূর্ণ, বৈধ এবং আসল কী হওয়ার ও নকল না হওয়ার নিশ্চয়তা থাকে। এসএসএইচ-কীস্ক্যান(১) ইউটিলিটি দিয়ে একটি কী সংগ্রহ করা যায় এবং এসএসএইচ-কীজেন(১) দিয়ে যাচাইয়ের জন্য ফিঙ্গারপ্রিন্ট দেখানো যায়। যাচাইয়ের পদ্ধতি জানতে কুকবুকের পাবলিক কী প্রমাণীকরণ অধ্যায়ের উদাহরণগুলো দেখুন। আবার, এর সংশ্লিষ্ট সিস্টেম-ভিত্তিক ফাইলটি হলো /etc/ssh/ssh_known_hosts

known_hosts ফাইলগুলির বিষয়বস্তু সম্পর্কে

known_hosts ফাইলটি অন্যান্য সিস্টেমের পরিচয় যাচাই করার জন্য ব্যবহৃত হয়। এসএসএইচ(১) স্বয়ংক্রিয়ভাবে ব্যবহারকারীর ফাইলে কী যোগ করতে পারে, তবে সেগুলি ম্যানুয়ালিও যোগ করা যায়। ফাইলটিতে সেই সমস্ত হোস্টের পাবলিক কী-এর একটি তালিকা থাকে যেগুলিতে ব্যবহারকারী সংযোগ স্থাপন করেছে। এতে সেই সমস্ত হোস্টের পাবলিক কী-ও অন্তর্ভুক্ত থাকতে পারে যেগুলিতে ব্যবহারকারী প্রবেশ করার পরিকল্পনা করছে কিন্তু যেগুলি ইতিমধ্যে সিস্টেম-ভিত্তিক পরিচিত হোস্ট কী-এর তালিকায় নেই। সাধারণত, প্রথমবারের মতো কোনো হোস্টে সংযোগ করার সময়, এসএসএইচ(১) রিমোট হোস্টের পাবলিক কী ব্যবহারকারীর known_hosts ফাইলে যোগ করে, কিন্তু এই আচরণটি পরিবর্তন করা যেতে পারে।

বিন্যাসটি হলো প্রতি অবিচ্ছিন্ন লাইনে একটি করে পাবলিক কী বা সনদপত্র। প্রতিটি লাইনে একটি হোস্ট নাম, বিটের সংখ্যা, সূচক এবং মডুলাস থাকে। বাক্যের শুরুতে হয় হোস্ট নাম অথবা হোস্ট ন্মকে প্রতিনিধিত্বকারী একটি হ্যাশ থাকে। বাক্যের শেষে একটি ঐচ্ছিক মন্তব্য থাকতে পারে। যদি এসএসএইচ কী-এর পরিবর্তে একটি এসএসএইচ সার্টিফিকেট ব্যবহার করা হয়, তবে সার্টিফিকেট অথরিটি নির্দেশ করার জন্য এগুলোর আগে একটি ঐচ্ছিক মার্কার থাকতে পারে। এই স্থানগুলো স্পেস দ্বারা পৃথক করা হয়। যদি কোনো হোস্টের একাধিক নাম থাকে অথবা একটি সার্ভার পুলে একাধিক মেশিনে একই কী ব্যবহার করা হয়, তবে হোস্ট নাম স্থানে হোস্টগুলোর একটি কমা-দ্বারা-পৃথক করা তালিকা ব্যবহার করা সম্ভব। এখানে সাধারণ হোস্ট নামসহ দুটি হোস্টের উদাহরণ দেওয়া হলো:

anoncvs.fr.openbsd.org,93.184.34.123 ssh-rsa AAAA...njvPw==	
anoncvs.eu.openbsd.org ssh-rsa AAAAB3Nz...cTqGvaDhgtAhw==

হোস্টের নাম বর্গাকার বন্ধনীতে রেখে, এরপর একটি কোলন এবং পোর্ট নম্বর উল্লেখ করে নন-স্ট্যান্ডার্ড পোর্ট নির্দেশ করা যায়। এখানে নন-স্ট্যান্ডার্ড পোর্টে এসএসএইচ-এর জন্য লিসেনিংরত হোস্টের তিনটি উদাহরণ দেওয়া হলো:

	
[ssh.example.org]:2222 ssh-rsa AAAAB3Nz...AKy2R2OE=	
[127.0.0.2]:4922 ssh-rsa AAAAB4mV...1d6j=	
[anga.funkfeuer.at]:2022,[78.41.115.130]:2022 ssh-rsa AAAAB...fgTHaojQ==	

হোস্ট নামের ধরণ তৈরি করার জন্য ওয়াইল্ডকার্ড হিসেবে "*" ও "?" এবং নেগেশন বা না-বোধক বোঝাতে "!" ব্যবহার করা যেতে পারে।

প্রতি বাক্যে সর্বোচ্চ একটি ঐচ্ছিক মার্কার ব্যবহার করা যাবে। যদি তা থাকে, তবে সেটি অবশ্যই @cert-authority অথবা @revoked হতে হবে। প্রথমটি নির্দেশ করে যে কী-টি একটি সার্টিফিকেট অথরিটি কী, এবং দ্বিতীয়টি কী-টিকে বাতিল হিসেবে চিহ্নিত করে যা ব্যবহারের জন্য গ্রহণযোগ্য নয়।

এই ফাইলের বিন্যাস সম্পর্কে আরও বিস্তারিত জানতে এসএসএইডি(৮) এবং কীগুলি পরিচালনা করতে এসএসএইচ-কীজেন(১) দেখুন।

সার্ভার-সাইড ক্লায়েন্ট ফাইল

এই ক্লায়েন্ট ফাইলগুলো সার্ভারে থাকে। পূর্বনির্ধারিতরূপে এগুলো ব্যবহারকারীর ডিরেক্টরিতে রাখা হয়। তবে, প্রয়োজনে সার্ভারকে অন্য স্থানেও এগুলো খোঁজার জন্য কনফিগার করা যেতে পারে।

~/.ssh/authorized_keys

authorized_keys হলো পাবলিক ইসিডিএসএ, আরএসএ, এবং ইডি২৫৫১৯ কী-গুলোর একটি নিবন্ধন, যেখানে প্রতি লাইনে একটি করে কী থাকে এবং এই অ্যাকাউন্টটি প্রবেশ করার জন্য এটি ব্যবহার করতে পারে। ফাইলটির বিষয়বস্তু খুব বেশি সংবেদনশীল নয়, তবে ব্যবহারকারীর জন্য পাঠ্য/লিখন অনুমতি সুপারিশ করা হয় যাতে এটি যেন অন্য কারো জন্য প্রবেশযোগ্য না হয়। বরাবরের মতোই, বিকল্প এবং মন্তব্যসহ সম্পূর্ণ কী-টি অবশ্যই একটি একক, অবিচ্ছিন্ন লাইনে থাকতে হবে।

ssh-rsa AAAAB3NzaC1yc2EAAA...41Ev521Ei2hvz7S2QNr1zAiVaOFy5Lwc8Lo+Jk=

হ্যাশ (#) দিয়ে শুরু হওয়া লাইনগুলো উপেক্ষা করা হয় এবং মন্তব্য হিসেবে ব্যবহার করা যেতে পারে। স্পেস দিয়ে কী-এর স্থানগুলো আলাদা করা হয়, যেগুলো ক্রমানুসারে হলো: প্রবেশ বিকল্পের একটি ঐচ্ছিক তালিকা, কী-এর ধরন (সাধারণত এসএসএইচ-আরএসএ অথবা আরও ভালো যেমন ইসিডিএসএ-এসএইচএ২-এনআইএসটিপি২৫৬), বেস৬৪-এ এনকোড করা মূল কী, এবং একটি ঐচ্ছিক মন্তব্য।

যদি কোনো কী-এর পরে একটি টীকা থাকে, তাহলে মন্তব্যটিকে উদ্ধারচিহ্নের মধ্যে রাখার প্রয়োজন নেই। কী-টি কী করে বা কীভাবে কাজ করে তার উপর এর কোনো প্রভাব নেই। এখানে একটি টীকাযুক্ত কী দেওয়া হল, মন্তব্যটি এসএসএইচ-কীজেন(১) এর -C বিকল্প দিয়ে তৈরি করা হয়েছে:

ssh-rsa AAAAB3NzaC1yc2EAAA...zAiVaOFy5Lwc8Lo+Jk=  Fred @ Project FOOBAR

সফল প্রবেশের পর কী ঘটবে তা প্রভাবিত করার জন্য, কী-গুলোর আগে কমা দিয়ে আলাদা করা বিকল্পের একটি তালিকা রাখা যেতে পারে। নিচের প্রথম কী-টি সেশনটিকে স্বয়ংক্রিয়ভাবে tinyfugue চালু করতে বাধ্য করে, এবং দ্বিতীয়টি জোরপূর্বক পথ এনভায়রনমেন্ট ভেরিয়েবল সেট করে:

command="/usr/bin/tinyfugue" ssh-rsa AAAAB3NzaC1yc2EAAA...OFy5Lwc8Lo+Jk=
environment="PATH=/bin:/usr/bin/:/opt/gtm/bin" ssh-rsa AAAAB3N...4Y2t1j=

authorized_keys-এর ফরম্যাট এসএসএইচডি(৮) নির্দেশিকা পাতায় বর্ণনা করা আছে। পুরোনো কী-গুলো যখন আর প্রয়োজন হবে না, তখন ফাইল থেকে মুছে ফেলা উচিত। সার্ভার authorized_keys-এর জন্য একাধিক অবস্থান নির্দিষ্ট করতে পারে। বিস্তারিত জানার জন্য পরবর্তী বিভাগ, সার্ভার-সাইড ক্লায়েন্ট কী প্রবেশ বিকল্প, দেখুন।

~/.ssh/authorized_principals

পূর্বনির্ধারিতরূপে এই ফাইলটি বিদ্যমান থাকে না। যদি এটি এসএসএইচডি_কনফিগ(৫) এ নির্দিষ্ট করা থাকে, তবে এতে এমন নামের একটি তালিকা থাকে যা একটি সার্টিফিকেট অনুমোদন করার সময় ব্যবহারকারীর নামের পরিবর্তে ব্যবহার করা যেতে পারে। এই বিকল্পটি রোল অ্যাকাউন্ট, বিচ্ছিন্ন অ্যাকাউন্ট নামস্থান এবং সার্টিফিকেটে "user@realm"-শৈলীর নামকরণের নীতির জন্য উপযোগী। প্রিন্সিপালগুলি authorized_keys-এও নির্দিষ্ট করা যেতে পারে।

~/.ssh/environment

যদি সার্ভারটি প্রবেশ প্রক্রিয়ার অংশ হিসেবে ব্যবহারকারীর দেওয়া এনভায়রনমেন্ট ভেরিয়েবলের স্বয়ংক্রিয় পরিবর্তন গ্রহণ করার জন্য কনফিগার করা থাকে, তাহলে এই পরিবর্তনগুলো এই ফাইলে সেট করা যেতে পারে।

যদি সার্ভার, এনভায়রনমেন্ট ফাইল এবং একটি অথরাইজেশন কী সবাই একই ভেরিয়েবল পরিবর্তন করার চেষ্টা করে, তাহলে কী-তে যা থাকতে পারে তার চেয়ে ফাইল এনভায়রনমেন্টের অগ্রাধিকার থাকবে। এদের যেকোনো একটি এসএসএইচ(১) দ্বারা SendEnv ব্যবহার করে পাঠানো যেকোনো এনভায়রনমেন্ট ভেরিয়েবলকে ওভাররাইড করবে।

authorized_keys- এ সংরক্ষিত প্রমাণীকরণ কীগুলি ভেরিয়েবল সেট করতেও ব্যবহার করা যেতে পারে। এসএসএইচডি_কনফিগ(৫)- এর নির্দেশিকা পাতায় AcceptEnv এবং PermitUserEnvironment নির্দেশিকাগুলিও দেখুন।

~/.ssh/rc

এটি একটি স্ক্রিপ্ট যা ব্যবহারকারীর শেল বা কমান্ড শুরু হওয়ার ঠিক আগে এসএইচ(১) দ্বারা চালানো হয়। ForceCommand ব্যবহার করা হলে এটি চালানো হয় না। এনভায়রনমেন্ট ভেরিয়েবলগুলো পড়ার পরে স্ক্রিপ্টটি চালানো হয়। ব্যবহারকারীর rc স্ক্রিপ্ট বিদ্যমান থাকলে সংশ্লিষ্ট বৈশ্বিক ফাইল, /etc/ssh/sshrc, চালানো হয় না।

স্থানীয় অ্যাকাউন্টের পাবলিক/প্রাইভেট কী জোড়া

ফাইল সিস্টেমে ব্যবহারকারীদের বিভিন্ন ধরণের ইসিডিএসএ, ইডি২৫৫১৯, এবং আরএসএ কী সংরক্ষিত থাকতে পারে। সংস্করণ ৮.২ থেকে, এফআইডিও/ইউ২এফ টোকেনের সাথে যুক্ত কীগুলির জন্য দুটি নতুন কী টাইপ ইসিডিএসএ-এসকে এবং ইডি২৫৫১৯-এসকে, এবং সংশ্লিষ্ট সার্টিফিকেট ধরণ উপলব্ধ হয়েছে। যদিও স্বতন্ত্র অ্যাকাউন্টগুলি প্রমাণীকরণের জন্য বা রিমোট হোস্টের পরিচয় যাচাই করার জন্য যেকোনো ডিরেক্টরিতে তাদের নিজস্ব কী বা সার্টিফিকেটের তালিকা রাখতে পারে, তবে সবচেয়ে সাধারণ অবস্থান হল ~/.ssh/ ডিরেক্টরি। কীগুলির নামকরণের নিয়মটি কেবল একটি প্রথা, তবে এটি অনুসরণ করার পরামর্শ দেওয়া হয়। পাবলিক কীগুলির নাম সাধারণত প্রাইভেট কী-এর নামের মতোই হয়, তবে নামের শেষে .pub যুক্ত থাকে। পাবলিক এবং প্রাইভেট কীগুলির নাম এক না হলে সমস্যা দেখা দিতে পারে। যদি একাধিক কী জোড়া থাকে, তাহলে এসএসএইচ-কীজেন(১) কী তৈরি করার সময় একটি কার্যকর নাম তৈরি করতে -f অপশন এবং কী জোড়ার ভিতরে একটি প্রাসঙ্গিক মন্তব্য যুক্ত করতে -C বিকল্প ব্যবহার করতে পারে।

ব্যক্তি, প্রোগ্রাম এবং স্ক্রিপ্ট সিস্টেমে সংরক্ষিত একটি প্রাইভেট কী, অথবা এমনকি স্মার্টকার্ড থেকে প্রাপ্ত একটি প্রাইভেট কী ব্যবহার করে প্রমাণীকরণ করতে পারে, যদি সংশ্লিষ্ট পাবলিক কীটি রিমোট সিস্টেমের authorized_keys ফাইলে সংরক্ষিত থাকে। authorized_keys ফাইলটি খুব বেশি সংবেদনশীল নয়, তবে ব্যবহারকারীর জন্য পাঠ্য/লিখন অনুমতি সুপারিশ করা হয় এবং এটি যেন অন্যদের দ্বারা প্রবেশযোগ্য না হয়। তবে, প্রাইভেট কীগুলো অত্যন্ত সংবেদনশীল এবং অন্য অ্যাকাউন্টগুলোর কাছে এগুলো পাঠযোগ্য বা এমনকি দৃশ্যমানও হওয়া উচিত নয়। এগুলো কখনোই ক্লায়েন্ট থেকে বাইরে নিয়ে যাওয়া উচিত নয় এবং অবশ্যই সার্ভারে রাখা উচিত নয়। আরও আলোচনা এবং উদাহরণের জন্য পাবলিক কী অথেন্টিকেশন অধ্যায়টি দেখুন।

কী-গুলোর আগে কমা দিয়ে আলাদা করা অপশনের একটি তালিকা থাকতে পারে। সম্পূর্ণ কী-টি অবশ্যই একটি একক, অবিচ্ছিন্ন লাইনে থাকতে হবে। ডাবল উদ্ধারচিহ্নের ভেতরের অংশ ছাড়া কোনো স্পেস অনুমোদিত নয়। কী-টির পরে যেকোনো লেখাকে মন্তব্য হিসেবে গণ্য করা হয়। authorized_keys ফাইলটি হলো পাবলিক আরএসএ, ইডি২৫৫১৯, ইসিডিএসএ, ইডি২৫৫১৯-এসকে, এবং ইসিডিএসএ-এসকে কী-গুলোর একটি নিবন্ধন, যেখানে প্রতি লাইনে একটি করে কী থাকে এবং যা একটি নির্দিষ্ট অ্যাকাউন্টে প্রবেশ করতে ব্যবহার করা যেতে পারে। আরও আলোচনার জন্য authorized_keys ফাইল সম্পর্কিত উপরের অংশটি দেখুন।

২০২৫ সাল থেকে ওপেনএসএসএইচ-এর ১০.০ সংস্করণ থেকে ডিএসএ সমর্থন সরিয়ে ফেলা হয়েছে এবং ২০১৫ সাল থেকেই এটিকে অপ্রচলিত বলে গণ্য করা হতো। সুতরাং, ডিএসএ কী ব্যবহারের দিন শেষ হয়ে গেছে। এগুলোকে আর নিরাপদ বলে মনে করা হয় না এবং এর পরিবর্তে আরও উন্নত কী ব্যবহার করা উচিত।

~/.shosts, ~/.rhosts, ~/.ssh/environment, এবং ~/.ssh/rc ফাইলগুলো ব্যবহার করে প্রতিটি অ্যাকাউন্টের জন্য হোস্ট-ভিত্তিক প্রমাণীকরণ কনফিগারেশনও করা সম্ভব।

ক্লায়েন্ট পাবলিক কী

এগুলো পাবলিক কী-গুলোর জন্য শুধুমাত্র পূর্বনির্ধারিত নাম। প্রকৃত ফাইলের নাম যেকোনো কিছু হতে পারে এবং এর অবস্থান যেকোনো ডিরেক্টরি হতে পারে।

~/.ssh/id_ecdsa ~/.ssh/id_ed25519 ~/.ssh/id_rsa ~/.ssh/id_ecdsa-sk ~/.ssh/id_ed25519-sk ~/.ssh/id_ecdsa-sk_rk ~/.ssh/id_ed25519-sk_rk

আবার, কী-গুলোকে আরও প্রাসঙ্গিক নাম দেওয়া একটি ভালো উপায় হতে পারে। *-sk.pub কী-গুলো একটি হার্ডওয়্যার সিকিউরিটি টোকেনের সাথে আবদ্ধ থাকে এবং *-sk_rk.pub কী-গুলো হার্ডওয়্যার সিকিউরিটি টোকেনের মধ্যে সংরক্ষিত আবাসিক কী-গুলো থেকে তৈরি হয়।

পাবলিক কী প্রধানত রিমোট সার্ভারে কী-ভিত্তিক প্রমাণীকরণের জন্য ব্যবহৃত হয়। প্রাইভেট কী-এর মতো নয়, পাবলিক কী সংবেদনশীল নয় এবং যে কেউ এটি পড়তে পারে, যদিও এর কোনো বাধ্যবাধকতা নেই। কোনো প্রাইভেট কী হারিয়ে গেলে, মন্তব্য এবং সীমাবদ্ধতা বিকল্পগুলো ছাড়া পাবলিক কী পুনরায় তৈরি করা যায়। তাই পাবলিক কী-এর ব্যাকআপ রাখা উপকারী হলেও, প্রাইভেট কী-এর মতো এটি অপরিহার্য নয়।

ক্লায়েন্ট প্রাইভেট কী

ক্লায়েন্ট পাবলিক কী-গুলোর মতোই প্রাইভেট কী-গুলোর আসল ফাইলের নাম যেকোনো কিছু হতে পারে এবং সেগুলোর অবস্থান যেকোনো ডিরেক্টরিতে হতে পারে। নিচে ক্লায়েন্ট প্রাইভেট কী-গুলোর পূর্বনির্ধারিত নামগুলো দেওয়া হলো।

~/.ssh/id_ecdsa ~/.ssh/id_ed25519 ~/.ssh/id_rsa ~/.ssh/id_ecdsa-sk ~/.ssh/id_ed25519-sk ~/.ssh/id_ecdsa-sk_rk ~/.ssh/id_ed25519-sk_rk

প্রাইভেট কী সর্বদা সংবেদনশীল ডেটা হিসাবে বিবেচিত হয় এবং এটি কেবল ব্যবহারকারীর দ্বারাই পাঠযোগ্য হওয়া উচিত, অন্যদের দ্বারা প্রবেশযোগ্য নয়। অন্য কথায়, এগুলি ০৬০০ মোড ব্যবহার করে। যে ডিরেক্টরিতে এগুলি থাকে, সেটিরও ০৭০০ বা ০৫০০ মোড থাকা উচিত। যদি একটি প্রাইভেট কী ফাইল অন্যদের দ্বারা প্রবেশযোগ্য হয়, এসএসএইচ(১) এটিকে উপেক্ষা করবে।

এইএস১২৮ ব্যবহার করে এই ফাইলের সংবেদনশীল অংশ এনক্রিপ্ট করার জন্য ব্যবহৃত কী তৈরি করার সময় একটি পাসফ্রেজ নির্দিষ্ট করা সম্ভব। সংস্করণ ৫.৩ পর্যন্ত, পাসফ্রেজটি এনক্রিপ্ট করার জন্য ৩ডিইএস সাইফার ব্যবহার করা হতো। ৩ডিইএস ব্যবহার করা পুরোনো কী-গুলোতে নতুন পাসফ্রেজ যোগ করা হলে, সেগুলো পরিবর্তিত হওয়ার পর এইএস১২৮ ব্যবহার করবে।

হার্ডওয়্যার টোকেনে রেসিডেন্ট কী হিসাবে সংরক্ষিত প্রাইভেট কীগুলি এসএসএইচ-কীজেন(১) -K বিকল্প ব্যবহার করে এক্সট্র্যাক্ট করা যায় এবং স্বয়ংক্রিয়ভাবে তাদের সংশ্লিষ্ট পাবলিক কী তৈরি করতে ব্যবহার করা যায়। কী-এর প্রকারের উপর নির্ভর করে এই ধরনের কীগুলির পূর্বনির্ধারিত নাম হবে id_ecdsa-sk_rk অথবা id_ed25519-sk_rk, যদিও এক্সট্র্যাকশনের পরে ফাইলের নাম পরিবর্তন করা যেতে পারে। টোকেন থেকে ফাইলে প্রাইভেট কী এক্সট্র্যাক্ট করার সময় একটি পাসফ্রেজ নির্ধারণ করা যেতে পারে।

যদিও প্রাইভেট কী থেকে পাবলিক কী তৈরি করা যায়, কিন্তু প্রাইভেট কী হারিয়ে গেলে তা থেকে নতুন প্রাইভেট কী পুনরায় তৈরি করা যায় না। একইভাবে, বর্তমান পাসফ্রেজ ভুলে গেলে নতুন পাসফ্রেজও সেট করা যায় না। একবার হারিয়ে গেলে তা আর ফিরে আসে না; পাবলিক কী-এর ক্ষেত্রে এমনটা হয় না, কারণ প্রাইভেট কী হারিয়ে গেলে বা ভুলে গেলে তা বিদ্যমান প্রাইভেট কী থেকে পুনরায় তৈরি করা যায়, সেক্ষেত্রে সম্পূর্ণ নতুন একটি কী জোড়া তৈরি করে স্থাপন করতে হয়।

লিগ্যাসি ফাইল

এই ফাইলগুলো খুব পুরোনো বা সেকেলে সিস্টেমে পাওয়া যেতে পারে, কিন্তু হালনাগাদ সিস্টেমে নয়।

~/.rhosts

.rhosts হলো আরএসএইচ-এর একটি পুরোনো ফাইল, যেখানে প্রবেশ করার অনুমতিপ্রাপ্ত বিশ্বস্ত হোস্ট-ব্যবহারকারী জোড়াগুলোর একটি স্থানীয় তালিকা থাকে। কোনো এন্ট্রির সাথে মিলে যাওয়া প্রবেশ অনুরোধগুলোকে প্রবেশাধিকার দেওয়া হতো।

বিশ্বস্ত হোস্ট-ব্যবহারকারী জোড়াগুলোর বৈশ্বিক তালিকা, /etc/hosts.equiv-ও দেখুন।

হোস্ট-ভিত্তিক প্রমাণীকরণের অংশ হিসেবে rhosts ব্যবহার করা যেতে পারে। অন্যথায়, প্রমাণীকরণের জন্য rhosts ব্যবহার না করার পরামর্শ দেওয়া হয়, কারণ .rhosts ফাইলটি ভুলভাবে কনফিগার করার অনেক উপায় রয়েছে ।

লিগ্যাসি ডিএসএ কী ~/.ssh/id_dsa ~/.ssh/id_dsa.pub

অপ্রচলিত ডিএসএ কী id_dsa এবং id_dsa.pub নামে পাওয়া যেতে পারে, কিন্তু নাম নির্বিশেষে এর যেকোনো ব্যবহার খুঁজে বের করা উচিত। ওপেনএসএসএইচ ৭.০-এ সার্ভার এবং ক্লায়েন্ট উভয় ক্ষেত্রেই ডিএসএ-এর সমর্থন বন্ধ করে দেওয়া হয়েছিল এবং ওপেনএসএসএইচ ১০.০-এ এটি সম্পূর্ণরূপে সরিয়ে ফেলা হয়েছে। যদি ডিএসএ কী পাওয়া যায়, তবে কী-জোড়াটি সরিয়ে আরও উন্নত ধরনের কী দিয়ে প্রতিস্থাপন করা উচিত।

লিগ্যাসি এসএসএইচ১ প্রোটোকল কী ~/.ssh/identity ~/.ssh/identity.pub

identity এবং identity.pub ফাইলগুলো এসএসএইচ প্রোটোকল সংস্করণ ১-এর জন্য তৈরি হয়েছিল এবং তাই এগুলো এখন অপ্রচলিত। যদি এগুলো খুঁজে পাওয়া যায়, তবে তদন্ত করে দেখা উচিত যে, কোনো কিছু এগুলো ব্যবহার করে কি না এবং কেন। এরপর, অবশিষ্ট ব্যবহারগুলোর সমাধান হয়ে গেলে, এগুলো সরিয়ে দিয়ে নতুন ধরনের কী দিয়ে প্রতিস্থাপন করা উচিত।

ক্লায়েন্ট বিকল্প এবং কনফিগারেশন নির্দেশাবলী ম্যাপিং

এসএসএইচ ক্লায়েন্টের অনেক রান-টাইম বিকল্পের সংশ্লিষ্ট কনফিগারেশন নির্দেশিকা রয়েছে এবং এর বিপরীতটিও সত্য। নিম্নলিখিতটি একটি সংক্ষিপ্ত বিবরণ। এটি প্রাসঙ্গিক নির্দেশিকা পাতা, এসএসএইচ(১) এবং এসএসএইচ_কনফিগ(৫) এর সাথে পরিচিত হওয়ার বিকল্প নয়, যেগুলি এই বিষয়ে প্রাসঙ্গিক, প্রামাণিক এবং হালনাগাদ উৎস।

ওপেনএসএসএইচ ক্লায়েন্ট অপশন বনাম কনফিগারেশন নির্দেশাবলীর অনুসন্ধান টেবিল

নির্দেশিকা	বিকল্প	বর্ণনা
AddressFamily	-4 / -6	সংযোগ শুধুমাত্র IPv4 বা IPv6-এ সীমাবদ্ধ রাখে।
ForwardAgent	-A / -a	প্রমাণীকরণ এজেন্ট থেকে ফরওয়ার্ড করা অথবা ফরওয়ার্ডিং বাধা দেয়।
BindInterface	-B	বহির্গামী সংযোগটিকে এই নেটওয়ার্ক ইন্টারফেসের সাথে সংযুক্ত করে।
BindAddress	-b	বহির্গামী সংযোগটিকে এই নেটওয়ার্ক অ্যাড্রেসের সাথে সংযুক্ত করে।
Compression	-C	ডেটা জিজিপ(১) ব্যবহার করে সংকুচিত করা হবে কিনা তা নির্দিষ্ট করে।
Ciphers	-c	কোন চিপারটি ব্যবহার করতে হবে তা নির্দিষ্ট করে।
DynamicForward	-D	ফরওয়ার্ড করার জন্য একটি স্থানীয় পোর্ট নির্দিষ্ট করে, যেমন সকস৫-এর জন্য।
EscapeChar	-e	পিটিওয়াই সেশনের জন্য একটি এস্কেপ ক্যারেক্টার নির্দিষ্ট করে।
ForkAfterAuthentication	-f	কমান্ড কার্যকর করার ঠিক আগে ক্লায়েন্টকে ব্যাকগ্রাউন্ডে পাঠিয়ে দেয়।
GatewayPorts	-g	অন্যান্য হোস্টগুলোকে স্থানীয় ফরওয়ার্ড করা পোর্টগুলোতে সংযোগ করার অনুমতি দেওয়া হবে কিনা।
PKCS11Provider	-I	শেয়ারকৃত PKCS#11 লাইব্রেরির পথ নির্দিষ্ট করে।
IdentityFile	-i	প্রমাণীকরণে ব্যবহার করার জন্য একটি নির্দিষ্ট সার্টিফিকেট বা প্রাইভেট কী উল্লেখ করে।
ProxyJump	-J	প্রথমে এই হোস্ট বা হোস্টগুলোর মাধ্যমে গন্তব্যে সংযোগ করে।
GSSAPIAuthentication	-K / -k	জেনেরিক সিকিউরিটি সার্ভিসেস অ্যাপ্লিকেশন প্রোগ্রাম ইন্টারফেস (GSSAPI) প্রমাণীকরণ সক্ষম বা নিষ্ক্রিয় করে।
LocalForward	-L	নির্দিষ্ট রিমোট সিস্টেমে কোন লোকাল পোর্ট বা সকেট ফরওয়ার্ড করতে হবে তা নির্দিষ্ট করে।
User	-l	রিমোট সিস্টেমে কোন অ্যাকাউন্টটি চেষ্টা করা হবে তা নির্দিষ্ট করে।
ControlMaster	-M	একটিমাত্র টিসিপি সংযোগের মাধ্যমে একাধিক এসএসএইচ সেশন চালানোর অনুমতি দেয়।
MACs	-m	কোন মেসেজ অথেন্টিকেশন কোড (MAC) অ্যালগরিদমগুলো চেষ্টা করা হবে তা নির্ধারণ করে।
SessionType	-N / -s	একটি নির্দিষ্ট সাবসিস্টেম চালু করুন অথবা যেকোনো কমান্ড কার্যকর করা পুরোপুরি বন্ধ করে দেয়।
StdinNull	-n	stdin থেকে পড়া প্রতিরোধ করুন।
Tag	-P	Match-এর মধ্যে ব্যবহারের জন্য ট্যাগ।
Port	-p	রিমোট সিস্টেমের এই পোর্টে সংযোগ করে।
LogLevel	-q / -v	ক্লায়েন্ট থেকে আসা লগিং মেসেজের বিশদ বিবরণ সামঞ্জস্য করে।
RemoteForward	-R	নির্দিষ্ট স্থানীয় সিস্টেমে কোন রিমোট পোর্ট বা সকেট ফরওয়ার্ড করতে হবে তা নির্দিষ্ট করে।
ControlPath	-S	এই সংযোগের মাধ্যমে মাল্টিপ্লেক্সিংয়ের জন্য কন্ট্রোল সকেটটি নির্দিষ্ট করে।
RequestTTY	-T / -t	সেশনের জন্য একটি ছদ্ম-টিটিওয়াই সংযোগ নিষিদ্ধ করে বা অনুরোধ করে।
ForwardX11	-X / -x	X11 ফরওয়ার্ডিং সক্ষম বা নিষিদ্ধ করে।

সংস্করণ ৮.৭ থেকে -f, -N, এবং -n বিকল্পগুলোর এসএসএইচ_কনফিগ(৫)-এ সংশ্লিষ্ট ক্লায়েন্ট কনফিগারেশন নির্দেশিকাও রয়েছে। ওয়ার্নউইকক্রিপ্টো এর মতো অন্যান্য নির্দেশিকাগুলির কোনও রান টাইম বিকল্প নেই।

সার্ভার-সাইড ক্লায়েন্ট কী প্রবেশ বিকল্প

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

cert-authority

এটি নির্দিষ্ট করে যে তালিকাভুক্ত কী-টি একটি সার্টিফিকেশন অথরিটি (CA), যা ব্যবহারকারীর প্রমাণীকরণের জন্য স্বাক্ষরিত সার্টিফিকেট যাচাই করতে বিশ্বস্ত। সার্টিফিকেটগুলোতে কী অপশনের অনুরূপ প্রবেশাধিকার সীমাবদ্ধতা অন্তর্ভুক্ত থাকতে পারে। যদি সার্টিফিকেট সীমাবদ্ধতা এবং কী সীমাবদ্ধতা উভয়ই উপস্থিত থাকে, তাহলে উভয়ের মধ্যে সবচেয়ে কঠোর সমন্বয়টি প্রয়োগ করা হয়।

command="program"

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

ক্লায়েন্ট অনুরোধ করলে প্রোগ্রামটি PTY-তে চালানো হয়, অন্যথায় পূর্বনির্ধারিত হিসেবে এটি TTY ছাড়াই চলে। ডিফল্ট হিসেবে TTY ছাড়া চললে একটি ৮-বিট ক্লিন চ্যানেল পাওয়া যায়। যদি পূর্বনির্ধারিতগুলো পরিবর্তন করা হয়ে থাকে, তবে ৮-বিট ক্লিন চ্যানেল পেতে no-pty উল্লেখ করুন। যদি কোনো প্রোগ্রাম চালানোর অনুমতি না থাকে, তবে কিছু চালানো বন্ধ করতে একটি খালি স্ট্রিং "" ব্যবহার করুন।

no-pty,command="" ssh-rsa AAAAB3NzaC1yc2EAAA...OFy5Lwc8Lo+Jk=

যদি নির্দিষ্ট বিকল্পসহ কেবল একটি প্রোগ্রামের অনুমতি থাকে, তবে তা সুস্পষ্টভাবে উল্লেখ করা যেতে পারে।

restrict,command="/usr/bin/svnserve -t --tunnel-user=fred" ssh-ed25519 AAAAC3NzaC1lZDI1NT...skSUlrRPoLyUq

প্রোগ্রামের বিকল্পে দেওয়া উদ্ধৃতি চিহ্নগুলোকে ব্যাকস্ল্যাশ ('\') ব্যবহার করে এড়াতে হবে।

command="sh -c \"mysqldump db1 -u fred1 -p\"" ssh-rsa AAAAB3NzaC1yc...Lwc8OFy5Lo+kU=

এই বিকল্পটি শেল, অন্য কোনো প্রোগ্রাম বা সাবসিস্টেম চালানোর ক্ষেত্রে প্রযোজ্য। ফলে, যখন command উপস্থিত থাকে, তখন ব্যবহারকারী কর্তৃক নির্দিষ্ট করা অন্য যেকোনো প্রোগ্রাম উপেক্ষা করা হয়। তবে, ক্লায়েন্ট কর্তৃক প্রাথমিকভাবে নির্দিষ্ট করা প্রোগ্রামটি SSH_ORIGINAL_COMMAND এনভায়রনমেন্ট ভেরিয়েবল হিসেবে উপলব্ধ থাকে। উদাহরণস্বরূপ, কোনো স্ক্রিপ্ট এটিকে একটি মাল্টিপল-চয়েস কেস স্টেটমেন্টে ব্যবহার করে অ্যাকাউন্টটিকে সীমিত পরিসরের অ্যাকশন থেকে বেছে নেওয়ার সুযোগ দিতে পারে।

environment="NAME=value"

যখন এই কী ব্যবহার করে লগ ইন করা হয়, তখন এটি একটি এনভায়রনমেন্ট ভেরিয়েবলের মান নির্ধারণ করে। যদি ভেরিয়েবলটির পূর্বনির্ধারিত মান বিদ্যমান থাকে, তবে এটি সেগুলোকে ওভাররাইড করে। ১০২৪টি পর্যন্ত স্বতন্ত্র নাম দিয়ে একাধিক ভেরিয়েবল সেট করার জন্য এই বিকল্পটি পুনরাবৃত্তি করা যেতে পারে। পুনরাবৃত্তির ক্ষেত্রে, প্রথমে যেটি মিলবে সেটিই কার্যকর হবে। এই বিকল্পটি শুধুমাত্র তখনই ব্যবহার করা যাবে, যদি এসএসএইচ সার্ভারের কনফিগারেশনে PermitUserEnvironment বিকল্পটি সেট করা থাকে। পূর্বনির্ধারিতভাবে এটি নিষ্ক্রিয় থাকে। আগে UseLogin সক্রিয় থাকলে এই বিকল্পটি স্বয়ংক্রিয়ভাবে নিষ্ক্রিয় হয়ে যেত, কিন্তু UseLogin এখন আর ব্যবহার করা হয় না।

expiry-time="timespec"

একটি তারিখ বা তারিখ-সময় নির্ধারণ করে, যা YYYYMMDD তারিখ অথবা YYYYMMDDHHMM[SS] বিন্যাসে হতে পারে। এর পরে কী-টি দিয়ে প্রমাণীকরণ করা যাবে না। অন্যথায় কী-টি অনির্দিষ্টকালের জন্য বৈধ বলে বিবেচিত হবে। এক্ষেত্রে সিস্টেম সময় অঞ্চল ব্যবহৃত হয়।

from="pattern-list"

কী-এর পাশাপাশি রিমোট হোস্টের প্রামাণিক নাম অথবা তার আইপি ঠিকানা প্রয়োজন। ঠিকানা এবং হোস্ট নামগুলি কমা-বিভক্ত প্যাটার্নের তালিকা ব্যবহার করে তালিকাভুক্ত করা যেতে পারে, প্যাটার্ন সম্পর্কে আরও তথ্যের জন্য এসএসএইচ_কনফিগ(৫)-এর PATTERNS দেখুন, অথবা সিআইডিআর ঠিকানা/ছদ্ম সংকেত ব্যবহার করুন।

no-agent-forwarding / agent-forwarding

এই বিকল্পটি প্রমাণীকরণের জন্য ব্যবহৃত হলে প্রমাণীকরণ এজেন্টকে কী ফরওয়ার্ড করতে নিষেধ করে। বিকল্পভাবে, এটি এজেন্ট ফরওয়ার্ডিংয়ের অনুমতি দেয়, এমনকি যদি restrict বিকল্প দ্বারা পূর্বে তা নিষ্ক্রিয় করা হয়ে থাকে।

no-port-forwarding / port-forwarding

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

no-pty / pty

TTY বরাদ্দ নিষিদ্ধ এবং PTY বরাদ্দের যেকোনো অনুরোধ ব্যর্থ হবে। বিকল্পভাবে, TTY বরাদ্দের অনুমতি রয়েছে, এমনকি যদি পূর্বে restrict বিকল্প দ্বারা এটি নিষ্ক্রিয় করা হয়ে থাকে।

no-touch-required

যেসব FIDO কী -O no-touch-required বিকল্প দিয়ে তৈরি করা হয়েছে, সেগুলো এই পদ্ধতিটি ব্যবহার করতে পারে, যা ক্লায়েন্টকে ব্যবহারকারীর উপস্থিতি যাচাই করা এড়িয়ে যেতে সাহায্য করে।

no-user-rc / user-rc

~/.ssh/rc ফাইলের কার্যোদ্ধার নিষ্ক্রিয় করতে authorized_keys-এ no-user-rc বিকল্পটি ব্যবহার করুন। অন্যথায়, restrict বিকল্পটি ওভাররাইড করতে user-rc ব্যবহার করুন।

no-X11-forwarding / x11-forwarding

যখন এই কী-টি প্রমাণীকরণের জন্য ব্যবহৃত হয় তখন X11 ফরওয়ার্ডিং প্রতিরোধ করে এবং X11 ফরওয়ার্ড করার অনুরোধে একটি ত্রুটি দেখাবে। বিকল্পভাবে, রেস্ট্রিক্ট বিকল্পটি ওভাররাইড করে X11 ফরওয়ার্ডিংয়ের অনুমতি দিন।

permitlisten="[host:]port"

permitopen="host:port"

permitlisten সেটিং রিমোট পোর্ট ফরওয়ার্ডিং (ssh -R) শুধুমাত্র নির্দিষ্ট পোর্ট এবং ঐচ্ছিকভাবে হোস্টে সীমাবদ্ধ করে। এর বিপরীতে, permitopen লোকাল পোর্ট ফরওয়ার্ডিং (ssh -L) শুধুমাত্র নির্দিষ্ট হোস্ট এবং পোর্টে সীমাবদ্ধ করে। IPv6 ঠিকানা একটি বিকল্প সিনট্যাক্স ব্যবহার করে নির্দিষ্ট করা যেতে পারে: host/port। একাধিক permitopen বা permitlisten বিকল্প ব্যবহার করা যেতে পারে এবং সেগুলোকে অবশ্যই কমা দিয়ে আলাদা করতে হবে। নির্দিষ্ট হোস্ট নামগুলোর উপর কোনো প্যাটার্ন ম্যাচিং করা হয় না, সেগুলোকে অবশ্যই আক্ষরিক হোস্ট নাম বা আইপি ঠিকানা হতে হবে। এটি agent-forwarding-এর সাথে একত্রে ব্যবহার করা যেতে পারে।

principals="name1[,name2,...]"

এসএসএইচডি_কনফিগ(৫)-এ বর্ণিত TrustedCAKeys বিকল্পের মাধ্যমে বিশ্বস্ত একটি সার্টিফিকেট অনুমোদন করার সময় ব্যবহারকারী নামের পরিবর্তে ব্যবহার করা যেতে পারে এমন নামগুলির একটি তালিকা নির্দিষ্ট করুন।

restrict

TTY allocation, port forwarding, agent forwarding, user-rc, এবং X11 forwarding-এর মতো সমস্ত বিকল্প একবারে নিষ্ক্রিয় করুন। এরপর নির্দিষ্ট বিকল্পগুলো পৃথকভাবে স্পষ্টভাবে অনুমতি দেওয়া যেতে পারে।

tunnel="n"

সার্ভারে একটি নির্দিষ্ট টান(৪) যন্ত্র নির্বাচন করুন। অন্যথায়, এই বিকল্পটি ছাড়া যখন একটি টানেল যন্ত্রের জন্য অনুরোধ করা হয় তখন পরবর্তী উপলব্ধ যন্ত্রটি ব্যবহার করা হবে।

verify-required

FIDO কী ব্যবহার করে পিনের মাধ্যমে ব্যবহারকারী যাচাইকরণ আবশ্যক।

কী ব্যবস্থাপনা

কী নিয়ে কাজ করার সময় সমস্যা এড়ানোর জন্য কিছু সাধারণ, এবং আশা করা যায় সাধারণ জ্ঞানসম্মত, পদক্ষেপ নেওয়া উচিত। সবচেয়ে উপকারী দুটি পদ্ধতি হলো কী ফাইলগুলির জন্য বোধগম্য নাম ব্যবহার করা এবং মন্তব্য যুক্ত করা। এসএসএইচ-কীজেন(১)-এর -f বিকল্পটি একটি কাস্টম নাম সেট করার সুযোগ দেয়। -C বিকল্পটি পাবলিক এবং প্রাইভেট উভয় কী-তেই মন্তব্য যুক্ত করার সুযোগ দেয়। প্রাইভেট কী-এর ভিতরে মন্তব্য থাকলে, -y বিকল্পটি ব্যবহার করে কোনো প্রতিস্থাপিত পাবলিক কী তৈরি করা হলে এটি স্বয়ংক্রিয়ভাবে পুনরায় তৈরি করা যেতে পারে।

এ ছাড়া, কী ব্যবস্থাপনার জন্য তিনটি প্রধান সাধারণ নিয়ম রয়েছে:

1. কী-গুলিতে শক্তিশালী পাসফ্রেজ ব্যবহার করা উচিত। যদি স্বাধীন প্রবেশের প্রয়োজন হয়, তাহলে কী-গুলি প্রথমে একটি এজেন্টে লোড করে সেখান থেকে ব্যবহার করতে হবে। এটি শুরু করার জন্য এসএসএইচ-এড(১) দেখুন। এটি এসএসএইচ-এজেন্ট(১) ব্যবহার করে, যা অনেক সিস্টেমে ইনস্টল করা থাকে এবং কিছু সিস্টেমে পূর্বনির্ধারিতরূপে চালু থাকে।
2. কী সবসময় সুরক্ষিত স্থানে সংরক্ষণ করা উচিত, এমনকি ক্লায়েন্ট সাইডেও। প্রাইভেট কী-এর ক্ষেত্রে এটি বিশেষভাবে গুরুত্বপূর্ণ। প্রাইভেট কী-এর মালিক ছাড়া অন্য কোনো ব্যবহারকারী বা দলের সেটিতে পাঠ্য অনুমতি থাকা উচিত নয়। ঝুঁকি সীমিত করার জন্য, এগুলো এমন একটি ডিরেক্টরিতে রাখা উচিত যেখানে মালিক ছাড়া অন্য কেউ প্রবেশ করতে পারে না।
3. সার্ভার থেকে পুরোনো এবং অব্যবহৃত কীগুলো সরিয়ে ফেলা উচিত। বিশেষ করে, যেসব কী-এর কোনো জ্ঞাত ও বৈধ উদ্দেশ্য নেই, সেগুলো সরিয়ে ফেলা উচিত এবং জমা হতে দেওয়া উচিত নয়। কিছু সময় অতিবাহিত হওয়ার পর, পাবলিক কী-এর মন্তব্য স্থানে টীকা যোগ করলে এর উদ্দেশ্য এবং মালিক সম্পর্কিত কিছু বিভ্রান্তি দূর করতে সাহায্য হতে পারে। এই সূত্র ধরে, নির্দিষ্ট বিরতিতে কীগুলো রোটেশন করা উচিত। রোটেশন বলতে বোঝায় নতুন কী জোড়া তৈরি করা এবং পুরোনো জোড়াগুলো সরিয়ে ফেলা। এর মাধ্যমে পুরোনো এবং অব্যবহৃত কীগুলো সরিয়ে ফেলার সুযোগ পাওয়া যায়। এটি প্রবেশাধিকারের প্রয়োজনীয়তা পর্যালোচনা করারও একটি সুযোগ, যেমন প্রবেশাধিকারের প্রয়োজন আছে কিনা এবং যদি থাকে, তবে কোন স্তরে।

ন্যূনতম বিশেষাধিকারের নীতি অনুসরণ করলে দুর্ঘটনা বা অপব্যবহারের সম্ভাবনা সীমিত করা যায়। যদি কোনো কী শুধুমাত্র একটি নির্দিষ্ট অ্যাপ্লিকেশন বা স্ক্রিপ্ট চালানোর জন্য প্রয়োজন হয়, তাহলে এর প্রবেশ বিকল্পগুলি কেবল প্রয়োজনীয় বিষয়গুলির মধ্যেই সীমাবদ্ধ রাখা উচিত। কী লগইন বিকল্পগুলির জন্য এসএসএইচ(৮)-এর "AUTHORIZED_KEYS FILE FORMAT" বিভাগটি দেখুন। রুট স্তরের প্রবেশাধিকারের জন্য, /etc/sudoers অথবা /etc/doas.conf যথাযথভাবে কনফিগার করা গুরুত্বপূর্ণ। সেখানে একটি নির্দিষ্ট অ্যাপ্লিকেশনকে অ্যাক্সেস দেওয়া যেতে পারে এবং এমনকি সেই অ্যাপ্লিকেশনটিকে নির্দিষ্ট বিকল্পগুলিতে সীমাবদ্ধও করা যেতে পারে।

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