SSH key ব্যবস্থাপনা: নিরাপদে তৈরি, ব্যবহার ও বাতিল

SSH key কীভাবে কাজ করে

একটি SSH key হলো দুটি ফাইলের জোড়া: একটি private key, যা আপনার ডিভাইসেই থাকে, এবং একটি public key, যা আপনি যেসব server-এ লগ ইন করতে চান সেগুলোর প্রতিটিতে কপি করেন। আপনি সংযোগ করলে server public key ব্যবহার করে একটি challenge পাঠায়, যার উত্তর শুধু সংশ্লিষ্ট private key দিয়েই দেওয়া যায়। private key কখনো আপনার ডিভাইস ছেড়ে যায় না। তাই network-এর মাধ্যমে কোনো secret পাঠানো হয় না, এবং কোনো breached server থেকেও চুরি করার মতো উপযোগী তথ্য থাকে না। এ কারণেই key, password-এর চেয়ে নিরাপদ। SSH key সঠিকভাবে পরিচালনার মূল বিষয় চারটি অভ্যাস: প্রতি ডিভাইসের জন্য একটি করে key ব্যবহার করা, sshd যে file permission দাবি করে তা রাখা, একটি ~/.ssh/config file ব্যবহার করা যাতে বারবার option টাইপ করতে না হয়, এবং কোনো laptop হারিয়ে গেলে সেদিনই কীভাবে একটি key সরাতে হয় তা জানা।

এই গাইডে Ubuntu 24.04 ব্যবহার করে প্রতিটি অভ্যাস দেখানো হয়েছে। তবে এখানে বর্ণিত প্রায় সবকিছু যেকোনো Linux server এবং সাম্প্রতিক যেকোনো OpenSSH-এর ক্ষেত্রেই প্রযোজ্য।

শুরু করার আগে একটি পরিভাষা পরিষ্কার করা দরকার, কারণ এটি বাস্তব ভুল প্রতিরোধ করে। public key গোপন নয়। আপনি এটি কোনো ticket-এ paste করতে, email-এ পাঠাতে বা প্রকাশ করতে পারেন; এটি ব্যবহার করে কেউ লগ ইন করতে পারবে না। private key-ই secret। কেউ যদি সেই ফাইল কপি করে এবং এতে passphrase থাকলে সেটিও জানে, তাহলে আপনার serverগুলোর দৃষ্টিতে সে-ই আপনি।

একটি key তৈরি করুন: ed25519 হলো সঠিক default

সার্ভারে নয়, নিজের কম্পিউটারে নিচের command চালান:

ssh-keygen -t ed25519 -C "laptop"

-t ed25519 key-এর type নির্ধারণ করে। Ed25519 হলো আধুনিক default: key-গুলো ছোট, দ্রুত এবং 2014 সালের পর প্রকাশিত প্রতিটি OpenSSH release-এ সমর্থিত। ed25519 বোঝে না—এমন পুরোনো device-এর সঙ্গে যোগাযোগ করা বাধ্যতামূলক হলেই শুধু ssh-keygen -t rsa -b 4096 ব্যবহার করুন। -C "laptop" একটি comment নির্ধারণ করে। এই comment-এর cryptographic কোনো কাজ নেই। তবে দুই বছর পরে server-এর authorized_keys file-এ এই key শনাক্ত করার জন্য এটিই ব্যবহার করবেন। তাই key-টি যে device-এ সংরক্ষিত, তার নাম দিন।

ssh-keygen key কোথায় সংরক্ষণ করতে হবে তা জানতে চায়। default, ~/.ssh/id_ed25519 গ্রহণ করুন। এরপর একটি passphrase দিতে বলবে। একটি passphrase সেট করুন। নিচের passphrase section-এ ব্যাখ্যা করা হয়েছে, প্রতিদিনের ব্যবহারে এর জন্য আপনার অতিরিক্ত কোনো ঝামেলা হবে না। শেষে দুটি file পাবেন: ~/.ssh/id_ed25519 হলো private key এবং ~/.ssh/id_ed25519.pub হলো public key। public অংশটি দেখুন:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

এটি একটি মাত্র line: key type, key material এবং আপনার comment। এই line-ই server-গুলোতে সংরক্ষিত হবে।

প্রতি ডিভাইসের জন্য একটি key, প্রতি server-এর জন্য নয়

প্রথমেই সবাই যে প্রশ্নটি করে: প্রতিটি server-এর জন্য কি আমার নতুন key দরকার? না। আপনি যে প্রতিটি device-এ টাইপ করেন, তার জন্য একটি করে key তৈরি করুন। এরপর device-টির যে যে server-এ পৌঁছানো দরকার, প্রতিটি server-এ সেই একটি public key রাখুন। key-টি device-টিকে শনাক্ত করে। প্রতিটি server-এর authorized_keys file-এ অনুমোদিত device-গুলোর তালিকা থাকে।

এই মডেলটি বড় পরিসরে কার্যকর থাকে। বিকল্প পদ্ধতিগুলোও অনুমানযোগ্য সমস্যায় ব্যর্থ হয়। প্রতি server-এর জন্য একটি key রাখলে বিশটি server-এ ব্যবহৃত একটি laptop-এ বিশটি private key থাকবে। কোন key কোন server-এর জন্য, তা পরে গুলিয়ে যাবে। আপনার সব device-এর মধ্যে একই key ভাগ করে নেওয়া আরও খারাপ। laptop চুরি হলে একই private key থাকার কারণে desktop-এর access বন্ধ না করে শুধু laptop-এর access বাতিল করতে পারবেন না। তাই প্রতিটি server-এ key বদলাতে হবে এবং একই সময়ে প্রতিটি device-এ নতুন key বিতরণ করতে হবে।

প্রতি device-এর জন্য একটি key থাকলে হারানো laptop-এর ক্ষেত্রে প্রতিটি server-এ শুধু একটি line মুছতে হবে: authorized_keys থেকে laptop-এর line মুছে দিন। অন্য সব device কাজ করতে থাকবে। -C দিয়ে সেট করা comment-ই ওই line সহজে খুঁজে পেতে সাহায্য করে।

এই মডেলের মূল নিয়ম হলো: একটি private key কোনো device-এ তৈরি হয় এবং সেই device-এর সঙ্গেই তার ব্যবহার শেষ হয়। কখনো কোনো private key দ্বিতীয় machine-এ copy করবেন না এবং কোনো server-এ upload করবেন না। নতুন কোনো device-এর access দরকার হলে সেই device-এই নতুন key তৈরি করুন।

সার্ভারে public key রাখুন

সহজ পদ্ধতি হলো ssh-copy-id ব্যবহার করা, যা OpenSSH-এর সঙ্গে সরবরাহ করা হয়:

ssh-copy-id matt@10.0.0.10

এটি যে authentication পদ্ধতি এখনও কাজ করছে, সাধারণত password, তা ব্যবহার করে লগইন করে। এরপর সার্ভারের ~/.ssh/authorized_keys ফাইলে আপনার public key যোগ করে। Directory বা file না থাকলে সঠিক permission-সহ সেগুলো তৈরি করে। একটি নতুন SSH session খুলে পরীক্ষা করুন। সার্ভার account password না চেয়েই আপনাকে লগইন করতে দেবে। আপনার key-তে passphrase থাকলে আপনার নিজের machine সেটি চাইতে পারে। ওই prompt local machine-এর এবং এটি server password নয়।

Password login আগে থেকেই disabled থাকলে ssh-copy-id লগইন করতে পারবে না। তাই line-টি হাতে যোগ করতে হবে। যে session এখনও কাজ করছে সেটি দিয়ে, অথবা আপনার provider-এর web console ব্যবহার করে, সার্ভারে এটি চালান:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Quotes-এর মধ্যে আপনার আসল public key বসান। id_ed25519.pub থেকে নেওয়া সম্পূর্ণ single line ব্যবহার করুন। authorized_keys-এ প্রতি line-এ একটি public key থাকে। এটিই সম্পূর্ণ access database। কোনো device যোগ করতে একটি line append করতে হয়, আর কোনো device-এর access বাতিল করতে সেই line delete করতে হয়। নতুন server-এ password login বন্ধ করার ঠিক আগে, নতুন VPS-এ প্রথম 10 মিনিটের মধ্যে এই ধাপটি সম্পন্ন করুন।

কী-ভিত্তিক লগইন যে permissions-এর কারণে ব্যর্থ হয়

কী-ভিত্তিক লগইন ব্যর্থ হওয়ার সবচেয়ে সাধারণ কারণ এটি। ক্লায়েন্টের দিক থেকে ব্যর্থতাটি নীরবে ঘটে। Ubuntu 24.04-এ StrictModes yes ডিফল্টভাবে চালু থাকে। তাই অন্য ব্যবহারকারীরা সম্পাদনা করতে পারে এমন authorized_keys ফাইল এটি ব্যবহার করতে অস্বীকার করে। ফাইলটি, ~/.ssh directory, অথবা আপনার home directory আপনি ছাড়া অন্য কেউ লিখতে পারলে, sshd আপনার key উপেক্ষা করে এবং কোনো ব্যাখ্যা ছাড়াই password চাওয়ায় ফিরে যায়। (Ubuntu-এর OpenSSH ঠিক একটি সীমিত পরিস্থিতি গ্রহণ করে: ফাইলটি আপনার নিজের private group-এর জন্য group-writable, এবং সেই group-এ অন্য কেউ নেই। এই ব্যতিক্রমের ওপর নির্ভর করবেন না; নিচের modes ব্যবহার করুন।) কারণটি শুধু server-এর log-এ দেখা যায়:

sudo grep 'Authentication refused' /var/log/auth.log

rsyslog ছাড়া minimal image-এ auth.log থাকে না। একই line journal-এ থাকে: sudo journalctl -u ssh | grep 'Authentication refused'।

Authentication refused: bad ownership or modes for file /home/matt/.ssh/authorized_keys

সমাধানের জন্য server-এ প্রভাবিত user হিসেবে দুটি permission পরিবর্তন এবং ownership পরীক্ষা চালান:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R matt:matt ~/.ssh

মনে রাখার নিয়ম: .ssh directory-তে 700, এবং এর ভেতরের সবকিছুর জন্য 600। আপনার নিজের computer-এও একই সংখ্যাগুলো প্রযোজ্য, কারণ client-ও পরীক্ষা করে। অন্য ব্যবহারকারীরা পড়তে পারে এমন private key থাকলে ssh সরাসরি key প্রত্যাখ্যান করে। এবার error স্পষ্টভাবে দেখা যায়:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/matt/.ssh/id_ed25519' are too open.

chmod 600 ~/.ssh/id_ed25519 এটি ঠিক করে।

~/.ssh/config: অপশন বারবার লেখা বন্ধ করুন

আপনার নিজের কম্পিউটারের একটি ~/.ssh/config ফাইল প্রতিটি সার্ভারের জন্য সংক্ষিপ্ত নাম নির্ধারণ করে এবং আপনি বারবার যে অপশনগুলো লিখতেন, সেগুলো সংরক্ষণ করে। 600 permission দিয়ে ফাইলটি তৈরি করুন এবং প্রতিটি সার্ভারের জন্য একটি করে Host ব্লক যোগ করুন:

Host web1
    HostName 10.0.0.10
    User matt
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host db1
    HostName 10.0.0.11
    User matt
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

এখন ssh web1, ssh -p 22 matt@10.0.0.10-এর পরিবর্তে কাজ করবে। একই সংক্ষিপ্ত নাম scp, rsync এবং git-এও ব্যবহার করা যাবে, কারণ এগুলো সবাই এই ফাইল পড়ে। HostName প্রকৃত address নির্ধারণ করে, User account name বারবার লেখা এড়ায়, এবং IdentityFile কোন key ব্যবহার করা হবে তা নির্দিষ্ট করে।

IdentitiesOnly yes নিয়ে আলাদা করে বলা দরকার, কারণ এটি একটি বিভ্রান্তিকর সমস্যা সমাধান করে। আপনার agent-এ একাধিক key থাকলে client একটির পর একটি key পাঠায়, এবং server প্রতিটি প্রস্তাবকে একটি failed attempt হিসেবে গণনা করে। পর্যাপ্ত সংখ্যক key loaded থাকলে সঠিক key চেষ্টা করার আগেই Received disconnect: Too many authentication failures দেখা যায়। IdentitiesOnly yes client-কে IdentityFile-এ নির্দিষ্ট key-টিই পাঠাতে বাধ্য করে, ফলে এই সমস্যা আর হয় না।

Passphrase এবং ssh-agent

একটি passphrase ডিস্কে থাকা private key file-কে encrypt করে। এটি না থাকলে যে কেউ file-টি কপি করে সঙ্গে সঙ্গে ব্যবহার করতে পারে; passphrase থাকলে passphrase অনুমান না করা পর্যন্ত চুরি করা file কোনো কাজে লাগে না। Laptop-এ থাকা key-এর জন্য এটিই প্রয়োজনীয় সুরক্ষা, কারণ laptop চুরি হতে পারে এবং laptop-এর backup ফাঁস হতে পারে।

বাস্তবে passphrase ব্যবহারে কোনো অতিরিক্ত অসুবিধা হয় না, কারণ ssh-agent। Agent আপনার decrypted key memory-তে রাখে। তাই প্রতিটি login session-এ একবার passphrase দিতে হয়, এবং পরবর্তী প্রতিটি connection সঙ্গে সঙ্গে তৈরি হয়। অধিকাংশ desktop Linux distribution এবং macOS আপনার জন্য আগে থেকেই একটি agent চালায়। এতে আপনার key load করতে চালান:

ssh-add ~/.ssh/id_ed25519

ssh-add -l agent বর্তমানে যে key-গুলো ধরে রেখেছে, সেগুলোর তালিকা দেখায়। একটি সতর্কতা: agent forwarding (ssh -A) চালু থাকলে আপনি connected থাকা অবস্থায় remote server আপনার agent ব্যবহার করে পরবর্তী server-এ authentication করতে পারে। তাই এটি শুধু সম্পূর্ণ বিশ্বস্ত server-এর দিকে চালু করুন এবং default হিসেবে বন্ধ রাখুন।

রোটেশন ও প্রত্যাহার: হারিয়ে যাওয়া ল্যাপটপের অনুশীলন

একটি সাধারণ SSH key প্রত্যাহার করতে যে সার্ভারগুলোতে এটি আছে, সেগুলোর প্রতিটিতে authorized_keys থেকে সংশ্লিষ্ট লাইন মুছে ফেলাই যথেষ্ট। কোনো certificate authority-কে জানাতে হয় না এবং expiry date-এর জন্য অপেক্ষা করতে হয় না। লাইনটি মুছে যাওয়ার সঙ্গে সঙ্গে ওই key দিয়ে নতুন login ব্যর্থ হবে।

এখনই এই অনুশীলন করুন, যখন এটি জরুরি পরিস্থিতি নয়। একটি server বেছে নিয়ে ~/.ssh/authorized_keys খুলুন এবং comment দেখে key-টি খুঁজে নিন। কোনো editor দিয়ে লাইনটি মুছুন, অথবা comment অনুযায়ী সেটি বাদ দিন:

grep -v ' laptop$' ~/.ssh/authorized_keys > ~/.ssh/authorized_keys.tmp
mv ~/.ssh/authorized_keys.tmp ~/.ssh/authorized_keys

এরপর যে device থেকে key-টি প্রত্যাহার করেছেন, সেখান থেকে পরীক্ষা করে নিশ্চিত করুন যে login এখন ব্যর্থ হচ্ছে। অন্য একটি device থেকে পরীক্ষা করে নিশ্চিত করুন যে login এখনও কাজ করছে। একটি বিষয় মনে রাখুন: কোনো key মুছে ফেললে ইতিমধ্যে খোলা session বন্ধ হয় না, কারণ key কেবল login-এর সময় যাচাই করা হয়। কোনো চুরি হওয়া device-এর key প্রত্যাহার করলে server-এর who-ও পরীক্ষা করুন এবং যে session আপনি শনাক্ত করতে পারছেন না, তা বন্ধ করুন।

Rotation একই কাজ, তবে ভিন্ন ক্রমে: device-এ একটি নতুন key তৈরি করুন, ssh-copy-id দিয়ে সেটি install করুন, নতুন key দিয়ে login হচ্ছে কি না নিশ্চিত করুন, তারপর পুরোনো লাইনটি মুছে ফেলুন। কোনো device-এর মালিকানা পরিবর্তন হলে, কোনো key প্রকাশ পেয়ে থাকতে পারে বলে সন্দেহ হলে, অথবা কেউ team ছেড়ে গেলে এটি করুন। দুইটি server-এ হাতে করে করা ঠিক আছে। কিন্তু বিশটি server-এ এটি automation-এর কাজ। একাধিক Linux server পরিচালনা-এ দেখানো হয়েছে কীভাবে একই authorized_keys state একটি সম্পূর্ণ fleet-এ প্রয়োগ করা যায়।

যা করবেন না

• সব ডিভাইসে একই private key ব্যবহার করবেন না। এতে একটি চুরি যাওয়া ডিভাইসের access বাতিল করা সম্ভব হয় না, যদি না সর্বত্র key প্রতিস্থাপন করা হয়।

• কোনো git repository-তে private key commit করবেন না, এমনকি repository-টি private হলেও। Automated scanner-গুলো public repository পর্যবেক্ষণ করে এবং push করার কয়েক মিনিটের মধ্যেই ফাঁস হওয়া key দিয়ে চেষ্টা করে। পরে কোনো repository public করলে তার সম্পূর্ণ history ফাঁস হয়ে যায়।

• অন্য server-এ পৌঁছানোর জন্য আপনার laptop-এর private key কোনো server-এ upload করবেন না। server-টির নিজেই একটি আলাদা key generate করুন এবং যেখানে প্রয়োজন ঠিক সেখানেই সেই key অনুমোদন করুন।

• private key chat, email বা ticket-এ paste করবেন না। Public key, অর্থাৎ .pub file, একমাত্র অংশ যা কখনো share করা হয়।

আপনার key নির্ভরযোগ্যভাবে login করাতে পারলে পরবর্তী ধাপে password authentication বন্ধ করুন। এতে আপনার server-এ চলমান অবিরাম অনুমানভিত্তিক login চেষ্টা সফল হতে পারবে না। এর drop-in configuration VPS-এ SSH hardening-এ রয়েছে।

FAQ

SSH key পাসওয়ার্ড না পাঠিয়েও কীভাবে কাজ করে?

সার্ভার আপনার public key ~/.ssh/authorized_keys-এ সংরক্ষণ করে। লগইনের সময় সার্ভার একটি challenge পাঠায়, আপনার client private key দিয়ে সেই challenge sign করে, এবং সার্ভার public key দিয়ে signature যাচাই করে। private key কখনও আপনার device ছেড়ে যায় না। তাই transit অবস্থায় এটি intercept করার মতো কিছু থাকে না, এবং সার্ভার থেকে চুরি করার মতো পুনর্ব্যবহারযোগ্য গোপন তথ্যও থাকে না। breached server থেকে শুধু public key ফাঁস হতে পারে, যা দিয়ে কোথাও লগইন করা যায় না।

সব সার্ভারের জন্য কি একই SSH key ব্যবহার করা উচিত?

একটি key একাধিক সার্ভারে ব্যবহার করা সঠিক, যদি সেই key একটি মাত্র device-এ থাকে। নিয়ম হলো প্রতি device-এ একটি key, প্রতি server-এ একটি নয়: আপনার laptop-এর public key সেই laptop-এর প্রয়োজনীয় প্রতিটি সার্ভারে থাকবে, আর আপনার desktop-এর নিজস্ব key থাকবে। এতে key প্রত্যাহার সহজ হয়। কোনো device হারালে প্রতিটি সার্ভার থেকে শনাক্ত করা যায় এমন একটি line সরালেই হয়, এবং অন্য device-গুলো কাজ করতে থাকে।

.ssh directory এবং authorized_keys-এর কী permissions থাকা উচিত?

~/.ssh-এ 700 এবং authorized_keys-এ 600 সেট করুন। একই permissions প্রতিটি private key-তেও সেট করুন। এগুলোর owner সেই account হওয়া উচিত যে account এগুলো ব্যবহার করে। sshd ডিফল্টভাবে StrictModes yes নিয়ে চলে। তাই আপনি ছাড়া অন্য কেউ কোনো file বা home directory-তে write করতে পারলে এটি নীরবে আপনার key উপেক্ষা করবে। তখন একমাত্র চিহ্ন থাকবে সার্ভারের auth log বা journal-এ Authentication refused: bad ownership or modes।

কোনো সার্ভার থেকে SSH key কীভাবে সরাব?

যে account-এর জন্য key-টি authorised করা হয়েছিল, সেই account-এর ~/.ssh/authorized_keys থেকে key-টির line মুছে দিন। key material-এর পরের label, অর্থাৎ comment দেখে সঠিক line শনাক্ত করুন। ওই key দিয়ে নতুন login সঙ্গে সঙ্গে ব্যর্থ হবে। তবে ইতিমধ্যে খোলা session চালু থাকবে। তাই device-টি চুরি হয়ে থাকলে সেই device-এর সক্রিয় session-ও বন্ধ করুন। key-টি যেসব সার্ভারে কপি করা হয়েছিল, প্রতিটি সার্ভারে একই কাজ করুন।

আমার SSH key-তে কি passphrase প্রয়োজন?

laptop বা desktop-এ থাকা key-এর জন্য হ্যাঁ। passphrase key file-টি encrypt করে। তাই চুরি হওয়া বা ফাঁস হওয়া copy একা কোনো কাজে আসে না। আর ssh-agent ব্যবহার করলে প্রতি connection-এ নয়, প্রতি session-এ একবার passphrase দিতে হয়। সার্ভারে unattended automation-এর জন্য ব্যবহৃত key-তে সাধারণত passphrase থাকে না, কারণ সেটি দেওয়ার মতো কোনো মানুষ উপস্থিত থাকে না। এসব key সুরক্ষিত রাখতে target account কী কী কাজ করতে পারবে, তা সীমিত করুন।