VPS-এ SSH সুরক্ষিত করার নিয়ম

কেন SSH সবার আগে সুরক্ষিত করা প্রয়োজন

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

এটি ধরে নেওয়া হচ্ছে যে আপনার SSH ইতিমধ্যে সঠিকভাবে কাজ করছে। আপনি যদি log in করতে পারেন, তবে আপনি এটি harden করতে পারবেন। ধাপগুলো ক্রমানুসারে অনুসরণ করুন এবং নতুন session কাজ না করা পর্যন্ত বর্তমান session টি খোলা রাখুন, যাতে কোনো ভুলবশত আপনি system থেকে lock out না হয়ে যান।

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

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

আপনার নিজের কম্পিউটারে, যদি আপনার কাছে key না থাকে তবে একটি তৈরি করুন:

ssh-keygen -t ed25519

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

ssh-copy-id user@your-server

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

Step 2: একটি drop-in file দিয়ে sshd harden করুন

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

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 একটি প্রবেশপথ বন্ধ করে দেয়। PasswordAuthentication no হলো সবচেয়ে গুরুত্বপূর্ণ: password বন্ধ থাকলে, brute-force attack করার মতো কিছু থাকে না। KbdInteractiveAuthentication no পাসওয়ার্ড-ভিত্তিক দ্বিতীয় একটি পথ বন্ধ করে দেয়। PermitRootLogin no এর অর্থ হলো আক্রমণকারীকে অবশ্যই আপনার username জানতে হবে এবং আপনার key ধারণ করতে হবে; শুধুমাত্র root অ্যাকাউন্টটি টার্গেট করা যাবে না যা প্রতিটি সিস্টেমে থাকে।

Step 3: কনফিগারেশন পরীক্ষা করুন, তারপর রিলোড করুন

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

sudo sshd -t

যদি কোনো আউটপুট না আসে, তবে কনফিগারেশনটি সঠিক আছে। SSH রিলোড করুন:

sudo systemctl reload ssh

এরপর sshd আসলে কোন সেটিংসগুলো ব্যবহার করছে তা পরীক্ষা করুন, যাতে অন্য কোনো ফাইলের কারণে কোনো সেটিংস ওভাররাইট হয়ে গেছে কিনা তা বোঝা যায়:

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

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

Step 4: ঐচ্ছিক নন-স্ট্যান্ডার্ড পোর্ট

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

Step 5: অতিরিক্ত সুরক্ষা স্তর যুক্ত করা

Hardened SSH keys হলো ভিত্তি, এবং এর উপরে আরও দুটি সুরক্ষা স্তর কাজ করে।

Fail2ban আপনার logs পর্যবেক্ষণ করে এবং বারবার ব্যর্থ হওয়া IP address গুলোকে ban করে দেয়। এটি scanner noise কমায় এবং আক্রমণকারীকে দ্রুত বের করে দেয়। এটি key-only authentication এর সাথে খুব ভালো কাজ করে: দেখুন Fail2ban on Ubuntu to stop SSH attacks।

আরও শক্তিশালী সুরক্ষা হলো SSH কে সম্পূর্ণভাবে public internet থেকে সরিয়ে রাখা। আপনি যদি put SSH behind a WireGuard VPN করেন এবং firewall দিয়ে port 22 কে শুধুমাত্র tunnel এর জন্য সীমাবদ্ধ করেন, তবে VPN এর বাইরে থাকা কেউ এটি অ্যাক্সেস করতে পারবে না। এতে brute-force attack করা প্রায় অসম্ভব হয়ে পড়ে। এই পদ্ধতিটি একটি default-deny firewall এর ওপর নির্ভর করে, যেমন UFW set up on the VPS।

SSH হলো একটি বড় checklist এর মাত্র একটি অংশ: the first 10 minutes on a new VPS আপনাকে ধাপগুলো ক্রমানুসারে জানাবে, এবং automatic security updates on Ubuntu আপনার সার্ভারকে সবসময় patched রাখবে।

FAQ

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

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

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

হ্যাঁ। PermitRootLogin no সেট করুন যাতে কেউ সরাসরি root হিসেবে লগ ইন করতে না পারে। আপনার সাধারণ user হিসেবে লগ ইন করুন এবং admin কাজের জন্য sudo ব্যবহার করুন। প্রতিটি Linux system-এ root থাকে, তাই এটি উন্মুক্ত রাখলে আক্রমণকারী একটি পরিচিত username পেয়ে যায়। এটি বন্ধ করার অর্থ হলো আক্রমণকারীকে অবশ্যই আপনার account name এবং আপনার key জানতে হবে।

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

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

আমি যদি SSH keys ব্যবহার করি, তবে কি Fail2ban প্রয়োজন?

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

SSH থেকে নিজেকে লক আউট করে ফেললে কীভাবে রিকভার করব?

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