VPS-এ SSH hardening: root ও password login বন্ধ করুন

SSH প্রথমে শক্ত সুরক্ষিত করার কারণ

SSH ব্যবহার করেই আপনি সার্ভার নিয়ন্ত্রণ করেন। তাই এটি এমন একটি প্রবেশপথ, যেটি আক্রমণকারীরা প্রথমে পরীক্ষা করে। VPS অনলাইনে আসার সঙ্গে সঙ্গে scanner-গুলো port 22-এ username ও password অনুমান করতে শুরু করে। কয়েক মিনিটের মধ্যেই আপনার log-এ এই কার্যকলাপ দেখতে পারবেন। SSH hardening-এর উদ্দেশ্য হলো আক্রমণকারীরা যে বিষয়গুলো অনুমান করতে পারে, সেগুলো সরিয়ে দেওয়া: password login সম্পূর্ণ বন্ধ করুন, root login বন্ধ করুন এবং শুধু cryptographic key দিয়ে login-এর অনুমতি দিন। এটি করার পর অবিরাম password অনুমান সফল হতে পারে না, কারণ খুঁজে পাওয়ার মতো কোনো password থাকে না।

এখানে ধরে নেওয়া হচ্ছে যে আপনার SSH ইতিমধ্যে কাজ করছে। আপনি login করতে পারলে এটি harden করতে পারবেন। ধাপগুলো ক্রমানুসারে সম্পন্ন করুন। নতুন session কাজ করছে নিশ্চিত না হওয়া পর্যন্ত বর্তমান session খোলা রাখুন, যাতে কোনো ভুলের কারণে আপনি সার্ভার থেকে বিচ্ছিন্ন হয়ে না পড়েন।

ধাপ 1: প্রথমে নিশ্চিত করুন যে key authentication কাজ করছে

Key authentication একটি password-এর পরিবর্তে key pair ব্যবহার করে: একটি private key আপনার কম্পিউটারে থাকে এবং একটি public key আপনি সার্ভারে রাখেন। আপনার private key কখনো কম্পিউটার ছেড়ে না গেলেও সার্ভার নিশ্চিত করে যে private key আপনার কাছে আছে। Password নিষ্ক্রিয় করার আগে key কাজ করছে কি না নিশ্চিত করুন। তা না হলে আপনি নিজেই সার্ভারে প্রবেশের সুযোগ হারাবেন।

নিজের কম্পিউটারে key না থাকলে একটি তৈরি করুন:

ssh-keygen -t ed25519

Public অংশটি সার্ভারে কপি করুন:

ssh-copy-id user@your-server

এরপর একটি নতুন SSH session খুলুন। Password না চাইতেই প্রবেশ করতে দিলে আপনার key কাজ করছে এবং password নিষ্ক্রিয় করা নিরাপদ। Permission denied (publickey) দিয়ে সংযোগ আটকে গেলে এই একটি error-এর আড়ালে পাঁচটি ভিন্ন সমস্যা থাকতে পারে, আর অন্য কিছু পরিবর্তন করার আগে ssh -v output বলে দেবে আপনার ক্ষেত্রে কোনটি ঘটেছে। Key আপনার কাছে নতুন হলে, অথবা একাধিক কম্পিউটার ব্যবহার করলে, SSH key management-এর মৌলিক বিষয় পুরো মডেলটি ব্যাখ্যা করে: প্রতিটি device-এর জন্য একটি key, sshd যে permissions দাবি করে, এবং laptop হারিয়ে গেলে কীভাবে একটি key revoke করতে হয়।

ধাপ 2: drop-in ফাইল দিয়ে sshd শক্তিশালী করুন

/etc/ssh/sshd_config সরাসরি সম্পাদনা করবেন না। Ubuntu 24.04 /etc/ssh/sshd_config.d/ থেকে drop-in ফাইল পড়ে। সেখানে একটি ছোট ফাইল রাখা বেশি পরিচ্ছন্ন, package upgrade-এর পরেও সেটি অক্ষত থাকে, এবং কোনো সমস্যা হলে সহজে সরিয়ে ফেলা যায়। নামটি গুরুত্বপূর্ণ: sshd প্রতিটি setting-এর জন্য যে প্রথম value পড়ে, সেটিই ধরে রাখে। Ubuntu cloud image-গুলো এই directory-তে PasswordAuthentication yes-সহ 50-cloud-init.conf পাঠায়। আপনার ফাইলের নাম 00- দিন, যাতে সেটি ওই ফাইলের আগে sort হয় এবং কার্যকর হয়; 99- ফাইল নীরবে অকার্যকর হয়ে যায়। একটি ফাইল তৈরি করুন:

sudo nano /etc/ssh/sshd_config.d/00-hardening.conf

এটি এখানে রাখুন:

# Key-only login: no passwords to guess.
PasswordAuthentication no
KbdInteractiveAuthentication no

# No direct root login. Log in as your user, then use sudo.
PermitRootLogin no

প্রতিটি line একটি access path বন্ধ করে। PasswordAuthentication no সবচেয়ে গুরুত্বপূর্ণ: password বন্ধ থাকলে brute-force attack করার মতো কোনো password থাকে না। KbdInteractiveAuthentication no দ্বিতীয় একটি password-ভিত্তিক path বন্ধ করে। PermitRootLogin no-এর অর্থ হলো, attacker-কে শুধু প্রতিটি server-এ থাকা একমাত্র account, root, লক্ষ্য করলেই হবে না; তাকে আপনার username জানতে হবে এবং আপনার key-ও থাকতে হবে।

ধাপ 3: কনফিগারেশন পরীক্ষা করুন, তারপর reload করুন

কনফিগারেশন প্রয়োগ করার আগে ভুল আছে কি না পরীক্ষা করুন, যাতে কোনো টাইপো service-টি অচল করে না দেয়:

sudo sshd -t

কোনো output না দেখালে কনফিগারেশন সঠিক। SSH reload করুন:

sudo systemctl reload ssh

এরপর sshd প্রকৃতপক্ষে যে settings ব্যবহার করছে সেগুলো পরীক্ষা করুন, যাতে অন্য কোনো file-এর কারণে drop-in কনফিগারেশন কার্যকর না হওয়ার বিষয়টি ধরা পড়ে:

sudo sshd -T | grep -Ei 'passwordauthentication|permitrootlogin'

উভয় ক্ষেত্রেই no দেখানোর কথা। এখন বর্তমান session বন্ধ না করে অন্য একটি terminal থেকে একেবারে নতুন session খুলুন। key ব্যবহার করে login করতে পারলে কাজ শেষ। কোনো সমস্যা হলে ঠিক করার জন্য আপনার প্রথম session এখনও খোলা থাকবে। এই একই সময়ে দুটি session খোলা রাখাই নিরাপত্তার ব্যবস্থা, তাই এটি কখনো বাদ দেবেন না।

ধাপ 4: ঐচ্ছিক অ-মানক port

SSH-কে port 22 থেকে 2222-এর মতো অন্য port-এ সরালে বাস্তবে নিরাপত্তা বাড়ে না, কারণ দৃঢ়প্রতিজ্ঞ আক্রমণকারী সব port স্ক্যান করে। এতে যা হয়, তা হলো log-এর অপ্রয়োজনীয় শব্দ কমে, কারণ অধিকাংশ automated scanner শুধু 22-এ চেষ্টা করে। এটি করতে চাইলে drop-in file-এ Port 2222 যোগ করুন, আগে firewall-এ নতুন port অনুমোদন করুন, তারপর sudo systemctl daemon-reload && sudo systemctl restart ssh.socket চালিয়ে ssh -p 2222 দিয়ে সংযোগ করুন। Ubuntu 24.04-এ listening port-এর মালিক হলো ssh.socket, তাই সাধারণ reload ssh চালালে sshd 22-এই থাকে; নতুন port কার্যকর করতে socket restart করতে হয়। এটিকে সুরক্ষা নয়, বরং পরিপাট্য হিসেবে বিবেচনা করুন।

ধাপ 5: অতিরিক্ত প্রতিরক্ষা স্তর যোগ করুন

শক্তিশালী SSH key হলো ভিত্তি। এর ওপর আরও দুটি স্তর যোগ করা যায়।

Fail2ban আপনার log monitor করে এবং বারবার ব্যর্থ হওয়া address ban করে। এতে scanner-এর অপ্রয়োজনীয় traffic কমে এবং সেগুলো দ্রুত সরিয়ে দেওয়া যায়। এটি key-only authentication-এর সঙ্গে স্বাভাবিকভাবেই ভালোভাবে কাজ করে: SSH আক্রমণ বন্ধ করতে Ubuntu-তে Fail2ban ব্যবহার করুন দেখুন।

আরও শক্তিশালী ব্যবস্থা হলো SSH-কে সম্পূর্ণভাবে public Internet থেকে সরিয়ে রাখা। আপনি যদি WireGuard VPN-এর মাধ্যমে SSH চালান এবং port 22-কে tunnel-এ সীমাবদ্ধ করেন, তাহলে VPN-এর বাইরে থাকা কেউ SSH-তে পৌঁছাতেই পারবে না। ফলে brute-force অনুমান করা শুধু কঠিন নয়, অসম্ভব হয়ে যায়। এর জন্য ভিত্তি হিসেবে default-deny firewall থাকা ধরে নেওয়া হয়েছে। VPS-এ UFW সেট আপ করুন।

SSH একটি বড় checklist-এর মাত্র একটি ধাপ। নতুন VPS-এ প্রথম 10 মিনিটের কাজগুলো ধাপগুলো সঠিক ক্রমে সাজায়। এরপর Ubuntu-তে স্বয়ংক্রিয় security update সিস্টেমকে patch করা রাখে। SSH সুরক্ষিত করলেও এর পেছনে চলা service-গুলো সুরক্ষিত হয় না। তাই একই VPS-এ password vault চললে Vaultwarden শক্তিশালী করার প্রাথমিক পরীক্ষা করুন। এতে key authentication যে দুটি বিষয় সামলায় না, সেই admin token এবং backup file সুরক্ষিত হবে।

FAQ

Ubuntu 24.04-এ SSH-এর জন্য password login কীভাবে নিষ্ক্রিয় করব?

/etc/ssh/sshd_config.d/00-hardening.conf-এ একটি drop-in file তৈরি করুন। 00 prefix-এর কারণে এটি 50-cloud-init.conf-এর আগে সাজানো হবে। PasswordAuthentication yes-এর মান অন্যথায় কার্যকর হতো, কারণ sshd যে মানটি আগে পড়ে সেটিই ধরে রাখে। ফাইলটিতে PasswordAuthentication no এবং KbdInteractiveAuthentication no রাখুন। configuration যাচাই করতে sudo sshd -t চালান। এরপর sudo systemctl reload ssh চালান। এর ওপর নির্ভর করার আগে একটি নতুন session-এ key login কাজ করছে কি না নিশ্চিত করুন। sshd_config সম্পাদনা করার বদলে drop-in সম্পাদনা করলে package upgrade-এর পরও পরিবর্তনটি থাকে এবং সহজে আগের অবস্থায় ফেরানো যায়।

SSH-এর মাধ্যমে root login কি নিষ্ক্রিয় করা উচিত?

হ্যাঁ। PermitRootLogin no সেট করুন, যাতে কেউ সরাসরি root হিসেবে login করতে না পারে। আপনার স্বাভাবিক user হিসেবে login করুন এবং administrative কাজের জন্য sudo ব্যবহার করুন। প্রতিটি Linux box-এ root account থাকে। এটি সক্রিয় রাখলে আক্রমণকারী লক্ষ্য করার জন্য একটি জানা username পেয়ে যায়। এটি নিষ্ক্রিয় করলে আক্রমণকারীকে আপনার account name জানতে হবে এবং আপনার cryptographic key দখলে রাখতে হবে।

SSH port পরিবর্তন করলে কি server আরও নিরাপদ হয়?

উল্লেখযোগ্যভাবে নয়। Port 22 থেকে সরে গেলে শুধু সেইসব অসতর্ক scanner আপনাকে এড়িয়ে যায়, যারা কেবল 22 নম্বর port পরীক্ষা করে। এতে log-এর অপ্রয়োজনীয় noise কমে। কিন্তু প্রকৃত আক্রমণকারী সব port scan করে এবং নতুন port-টিও খুঁজে পায়। Break-in ঠেকাতে আসল কার্যকর ব্যবস্থা হলো key-only authentication। Port পরিবর্তন করলে আগে firewall-এ নতুন port খুলুন। এরপর sudo systemctl daemon-reload && sudo systemctl restart ssh.socket চালান। Ubuntu 24.04-এ listener-এর দায়িত্ব socket-এর। সাধারণ reload করলে sshd port 22-এই চালু থাকে।

SSH keys ব্যবহার করলে কি Fail2ban দরকার?

এটি ঐচ্ছিক, তবে এখনও উপকারী। Key-only authentication থাকলে password guessing সফল হতে পারে না। তাই আক্রমণকারীকে দূরে রাখার প্রধান ব্যবস্থা Fail2ban নয়। এটি একটি address থেকে বারবার হওয়া ব্যর্থ প্রচেষ্টার rate limit করে। ফলে log-এ scanner-এর noise কমে এবং বারবার আক্রমণকারীকে দ্রুত বাদ দেওয়া যায়। তবে ধীরগতির distributed attack তার ban threshold-এর নিচেই থাকতে পারে। Key authentication-এর ওপর Fail2ban চালান। সম্ভব হলে SSH-কে VPN-এর পেছনে রাখুন।

SSH থেকে নিজেকেই access থেকে বিচ্ছিন্ন করে ফেললে কীভাবে পুনরুদ্ধার করব?

আপনার provider-এর web console ব্যবহার করুন। এটি serial বা VNC connection-এর মাধ্যমে server-এ পৌঁছায়, যা SSH-এর মধ্য দিয়ে যায় না। সেখান থেকে login করে sshd drop-in file ঠিক করতে এবং service reload করতে পারবেন। নতুন SSH config পরীক্ষা করার সময় প্রথম session বন্ধ করার আগে দ্বিতীয় terminal-এ পরীক্ষা করার কারণ এটাই। Password নিষ্ক্রিয় করার আগেই key authentication কাজ করছে কি না নিশ্চিত করাও জরুরি।