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

এতে ভয়ের ব্যাপার একটাই: পাসওয়ার্ড বন্ধ করে বাইরে থেকে যাওয়া। নিচে সেই ক্রম যাতে এটা ঘটতে পারে না।

কি

নিজের যন্ত্রে তৈরি হয়, সার্ভারে নয়:

ssh-keygen -t ed25519 -C "work laptop"

RSA নয়, ed25519: ছোট, দ্রুত, আর দৈর্ঘ্য নিয়ে প্রশ্নমুক্ত। RSA কেবল তখনই দরকার যখন খুব পুরনো কিছুতে পৌঁছাতে হয়; তখন -t rsa -b 4096।

কি-তে পাসফ্রেজ বসানো ভালো: কি ফাইল ল্যাপটপ থেকে চুরি হতে পারে, আর পাসফ্রেজ ছাড়া সেটি সঙ্গে সঙ্গে কাজ করে। প্রতিবার টাইপ করতে হবে না — সেটা ssh-agent সামলায়, আর macOS ও বেশিরভাগ ডেস্কটপ Linux-এ সেটি আগে থেকেই চলছে।

সার্ভারে অনুলিপি করতে একটা কমান্ড লাগে, যতক্ষণ পাসওয়ার্ড এখনও কাজ করছে:

ssh-copy-id -i ~/.ssh/id_ed25519.pub user@203.0.113.25

ssh-copy-id না থাকলে .pub ফাইলের বিষয়বস্তু সার্ভারে ~/.ssh/authorized_keys-এ একটি লাইন হিসেবে যোগ করা হয়। অনুমতি গুরুত্বপূর্ণ: .ssh ডিরেক্টরি 700, ফাইল 600, ব্যবহারকারীর মালিকানায়। অন্য কিছু হলে sshd নীরবে ফাইলটি পড়তে অস্বীকার করে, আর এটাই «কি কাজ করে না»-র সবচেয়ে প্রচলিত কারণ।

যে যাচাই সব ঠিক করে দেয়

কিছু বন্ধ করার আগে, প্রথম সংযোগ বন্ধ না করে দ্বিতীয় একটা খুলুন:

ssh -o PasswordAuthentication=no user@203.0.113.25

বিকল্পটি ক্লায়েন্টকে পাসওয়ার্ডে ফিরে যেতে নিষেধ করে — অর্থাৎ লগইন হলে কি দিয়েই হয়েছে। এই কমান্ড কাজ না করা পর্যন্ত এগোবেন না। আর প্রথম সংযোগটি একেবারে শেষ পর্যন্ত খোলা রাখুন: আপনি যা ভাঙতে পারেন তা এটিই ঠিক করে।

পাসওয়ার্ড বন্ধ করা আর একটা অস্পষ্ট ফাঁদ

সেটিংস আলাদা ফাইলে যায় যাতে প্যাকেজ হালনাগাদ সেগুলো উপর দিয়ে লিখতে না পারে। তবে ফাইলের নাম গুরুত্বপূর্ণ:

sudo tee /etc/ssh/sshd_config.d/10-hardening.conf <<'EOF'
PasswordAuthentication no
PermitRootLogin no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
MaxAuthTries 3
LogLevel VERBOSE
EOF

ব্যাপারটা হলো OpenSSH কোনো প্যারামিটারের জন্য পাওয়া প্রথম মানটি নেয়, শেষটি নয়, যেমনটা প্রায় সর্বত্র হয়। sshd_config.d-এর ফাইল বর্ণানুক্রমে পড়া হয়, আর Ubuntu-র ক্লাউড ইমেজ সেখানে 50-cloud-init.conf রাখে, যাতে প্রায়ই PasswordAuthentication yes থাকে। এমন অবস্থায় 90 নম্বরের আপনার ফাইল কিছুই করবে না: সেটিংস বসানো বলে মনে হবে আর পাসওয়ার্ড কাজ করতেই থাকবে। সেজন্যই সংখ্যা 10 — সেটি আগে পড়া হয়।

আসলে কী দাঁড়াল তা অনুমান না করেই দেখা যায়:

sudo sshd -T | grep -Ei 'passwordauth|permitrootlogin|pubkeyauth'

এই কমান্ড সব include-এর পরের কার্যকর কনফিগারেশন ছাপে। এটিতেই ভরসা করুন, ফাইলের বিষয়বস্তুতে নয়।

তারপর বাক্যরীতির যাচাই আর সেবার নরম পুনঃলোড:

sudo sshd -t && sudo systemctl reload ssh

sshd -t বাধ্যতামূলক: restart-সহ কনফিগে টাইপো সেবাকে বন্ধ আর আপনাকে বাইরে রেখে দেয়। reload খোলা সেশনও ভাঙে না।

Ubuntu 24.04: পোর্ট সেখানে নয় যেখানে আপনি ভাবছেন

সাম্প্রতিক Ubuntu-তে আলাদা একটা ফাঁদ: সেখানে sshd চালু হয় systemd সকেটের মাধ্যমে। এই মোডে sshd_config-এর Port লাইন কিছুই করে না — শোনে সকেট, ডেমন নয়। পোর্ট বদলাতে চাইলে সম্পাদনা করতে হবে এটিই:

sudo systemctl edit ssh.socket

আর ListenStream=-এ (ফাঁকা মান আগেরটি রিসেট করে) নতুন পোর্ট বলতে হবে। যে লক্ষণ এটি ধরিয়ে দেয়: কনফিগ বদলানো, সেবা পুনরায় চালু, আর সার্ভার এখনও 22-তে উত্তর দেয়।

পোর্ট বদলানোর প্রসঙ্গে: সুরক্ষা হিসেবে এটি কাজ করে না — স্ক্যানার যেকোনো পোর্টে সেবা মিনিটের মধ্যে খুঁজে পায়। এর একমাত্র প্রভাব শান্ত লগ, কারণ ব্যাপক অনুমান কেবল 22-তে যায়। এটা সুবিধাজনক, কিন্তু নিরাপত্তার সঙ্গে গুলিয়ে ফেলবেন না।

কে আদৌ ঢুকতে পারবে

কাজের একটা সংযোজন হলো স্পষ্ট তালিকা:

AllowUsers deploy admin

তালিকায় নেই এমন সবাই কি যাচাই হওয়ার আগেই কেটে যায়। এতে সেই ক্ষেত্রটিও ঢাকা পড়ে যখন কোনো প্যাকেজ শেল ও হোম ডিরেক্টরিসহ একটা সিস্টেম ব্যবহারকারী বানিয়ে ফেলে।

ভেতরে ঢোকার বাড়তি পথ

একটা ল্যাপটপে একটা কি হলো বিফলতার একক বিন্দু। ডিস্ক মরে যায়, ল্যাপটপ হারায়, আর সার্ভার চিরতরে অগম্য হয়ে পড়ে। যুক্তিসঙ্গত ন্যূনতম:

  • authorized_keys-এ অন্য একটি যন্ত্র থেকে দ্বিতীয় কি;
  • ব্যক্তিগত কি-র অনুলিপি পাসওয়ার্ড ব্যবস্থাপকে বা এনক্রিপ্ট করা স্টিকে;
  • প্রদানকারীর পরীক্ষিত কনসোল প্রবেশাধিকার — VNC বা serial। পরীক্ষিত মানে আপনি অন্তত একবার তা দিয়ে ঢুকেছেন, «প্যানেলে কোথাও একটা বোতাম আছে» নয়।

এই সুযোগে দেখে নিন authorized_keys-এ আগে থেকে কী আছে — নিজের ব্যবহারকারীরও, root-এরও। সেখানে থাকা পরের কি যেকোনো পাসওয়ার্ড পরিবর্তন টিকে যায় আর কর্মক্ষম প্রবেশাধিকার হয়ে থাকে।

এরপরে

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