SSH কী: পাসওয়ার্ড ছাড়া সার্ভারে লগইন সেটআপ

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

কী-ভিত্তিক প্রমাণীকরণ কীভাবে কাজ করে

কী-গুলো অসমমিত। পাবলিক কী (id_ed25519.pub) যে কাউকে দেখানো যায় — এর থেকে প্রাইভেট কী ফিরিয়ে আনা যায় না। প্রাইভেট কী (id_ed25519) কখনো আপনার কম্পিউটার ছাড়ে না এবং নেটওয়ার্কে পাঠানো হয় না।

লগইনের সময় ক্লায়েন্ট সার্ভারকে জানায় কোন কী দিয়ে ঢুকতে চায়। সার্ভার ব্যবহারকারীর ~/.ssh/authorized_keys-এ সেই পাবলিক কী খোঁজে, এবং পেলে ক্লায়েন্টকে সেশন ডেটায় প্রাইভেট কী দিয়ে স্বাক্ষর করতে বলে। স্বাক্ষর পাবলিক কী দিয়ে যাচাই হয় এবং লগইন অনুমোদিত হয়। পাসওয়ার্ড কখনো পাঠানো হয় না।

ধাপ ১. কী তৈরি: ssh-keygen

আপনার কম্পিউটারে (Linux, macOS, অথবা অন্তর্নির্মিত OpenSSH-সহ Windows 10/11) চালান:

ssh-keygen -t ed25519 -C "alena@laptop"

-t অ্যালগরিদম ঠিক করে, -C একটি মন্তব্য, যা পাবলিক কী-এর শেষে লেখা হয় এবং পরে কার কী চিনতে সাহায্য করে। Ed25519 হলো প্রস্তাবিত আধুনিক অ্যালগরিদম: কী ছোট, দ্রুত ও শক্তিশালী। সার্ভার খুব পুরোনো হলে এবং Ed25519 সমর্থন না করলে কমপক্ষে ৩০৭২ বিট দৈর্ঘ্যের RSA ব্যবহার করুন: ssh-keygen -t rsa -b 4096।

Generating public/private ed25519 key pair.
Enter file in which to save the key (/home/alena/.ssh/id_ed25519):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/alena/.ssh/id_ed25519
Your public key has been saved in /home/alena/.ssh/id_ed25519.pub
The key fingerprint is:
SHA256:Xq3v0m6c1y2pVv8m3N0uYv9yQm0e6dFv5gH2rZt1aBc alena@laptop

পাসফ্রেজ কি লাগবে

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

eval "$(ssh-agent -s)"
ssh-add ~/.ssh/id_ed25519
ssh-add -l      # লোড করা কীগুলোর তালিকা

পাসফ্রেজ ছাড়া কী স্বয়ংক্রিয় কাজের জন্য গ্রহণযোগ্য — যেমন CI বা ব্যাকআপ স্ক্রিপ্ট। এমন কী সার্ভারের দিকে সীমিত রাখা ভালো (নিচে বলা হয়েছে)।

ধাপ ২. পাবলিক কী সার্ভারে কপি: ssh-copy-id

সবচেয়ে সহজ উপায় ssh-copy-id। এটি একবার পাসওয়ার্ড দিয়ে সংযুক্ত হয়, আপনার পাবলিক কী সার্ভারের ~/.ssh/authorized_keys-এ যোগ করে এবং সঠিক অধিকার সেট করে।

ssh-copy-id -i ~/.ssh/id_ed25519.pub deploy@203.0.113.10

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: "/home/alena/.ssh/id_ed25519.pub"
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys
deploy@203.0.113.10's password:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'deploy@203.0.113.10'"
and check to make sure that only the key(s) you wanted were added.

সার্ভার যদি অস্বাভাবিক পোর্টে শোনে, -p 2222 যোগ করুন।

ssh-copy-id না থাকলে

Windows-এ ssh-copy-id নেই। এক কমান্ডে হাতে কী পাঠানো যায়:

cat ~/.ssh/id_ed25519.pub | ssh deploy@203.0.113.10 "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

ক্লাউড প্রদানকারীরা সাধারণত সার্ভার তৈরির সময়ই পাবলিক কী জিজ্ঞাসা করে — cloud-init-এর মাধ্যমে সেটি authorized_keys-এ যায়।

ধাপ ৩. লগইন যাচাই

ssh deploy@203.0.113.10

পাসওয়ার্ড আর না চাইলে (অথবা শুধু কীর পাসফ্রেজ চাইলে), সবকিছু ঠিক আছে। নতুন সার্ভারে প্রথমবার সংযোগে SSH সার্ভার কীর ফিঙ্গারপ্রিন্ট দেখায় এবং বিশ্বাস করেন কি না জিজ্ঞেস করে। yes দিলে ফিঙ্গারপ্রিন্ট ~/.ssh/known_hosts-এ সংরক্ষিত হয়, এবং পরে সার্ভারের কী বদলালে SSH সতর্ক করে।

কোন কী ক্লায়েন্ট চেষ্টা করছে এবং সার্ভার কেন প্রত্যাখ্যান করছে তা দেখতে বিস্তারিত আউটপুটসহ সংযোগ করুন:

ssh -v deploy@203.0.113.10

~/.ssh/config ফাইল: সার্ভারের ছোট নাম

একাধিক সার্ভার থাকলে প্রতিবার ব্যবহারকারী, IP, পোর্ট ও কী-এর পাথ লেখা ক্লান্তিকর। এসব ~/.ssh/config-এ লেখা যায়:

Host prod
    HostName 203.0.113.10
    User deploy
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host bastion
    HostName bastion.example.com
    User alena

Host db-internal
    HostName 10.0.0.15
    User admin
    ProxyJump bastion

Host *
    ServerAliveInterval 60
    AddKeysToAgent yes

এখন শুধু ssh prod লিখলেই হয়, আর scp, rsync ও Git-ও এই নামগুলো বোঝে: rsync -av ./site/ prod:/var/www/।

• IdentitiesOnly yes — শুধু নির্দিষ্ট কী ব্যবহার করে। এই লাইন না থাকলে ক্লায়েন্ট এজেন্টের সব কী চেষ্টা করে, আর সঠিক কীতে পৌঁছানোর আগেই সার্ভার চেষ্টার সীমা পেরিয়ে সংযোগ বন্ধ করতে পারে।
• ProxyJump — মধ্যবর্তী সার্ভার (বাস্টন) দিয়ে ভেতরের সার্ভারে এক কমান্ডে যুক্ত হওয়া।
• ServerAliveInterval — প্রতি ৬০ সেকেন্ডে "পিং" পাঠায়, যাতে নিষ্ক্রিয় অবস্থায় সংযোগ না কাটে।

ফাইলের অধিকার হতে হবে 600, নইলে SSH এটি পড়তে অস্বীকার করতে পারে: chmod 600 ~/.ssh/config।

Agent forwarding: কখন দরকার ও কেন ঝুঁকিপূর্ণ

কখনো সার্ভার থেকে আরও দূরে সংযোগ দরকার হয় — যেমন ব্যক্তিগত রিপোজিটরি থেকে git pull। সেখানে প্রাইভেট কী কপি করা উচিত নয়। বরং ssh -A বা ForwardAgent yes ব্যবহৃত হয়: সেশন চলাকালীন সার্ভার আপনার এজেন্টে প্রবেশ পায়। কিন্তু ওই সার্ভারের root-ও আপনি সংযুক্ত থাকা অবস্থায় আপনার এজেন্ট ব্যবহার করতে পারে। তাই শুধু বিশ্বস্ত হোস্টে forwarding চালু করুন, আর মধ্যবর্তী সার্ভারের জন্য ProxyJump বেছে নিন — এটি এজেন্ট খোলে না।

ধাপ ৪. পাসওয়ার্ড লগইন বন্ধ

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

/etc/ssh/sshd_config খুলুন (অথবা মূল কনফিগ যদি Include নির্দেশে /etc/ssh/sshd_config.d/ লোড করে, সেখানে একটি ফাইল তৈরি করুন), তারপর লিখুন:

PasswordAuthentication no
KbdInteractiveAuthentication no
PubkeyAuthentication yes
PermitRootLogin no

PermitRootLogin no root হিসেবে লগইন সম্পূর্ণ নিষিদ্ধ করে: অ্যাডমিনরা নিজেদের ব্যবহারকারীর নামে ঢোকে এবং sudo দিয়ে অধিকার বাড়ায়। root লগইন অপরিহার্য হলে PermitRootLogin prohibit-password ব্যবহার করুন — শুধু কী দিয়ে।

সিনট্যাক্স যাচাই করে সার্ভিস পুনরায় লোড করুন:

sudo sshd -t
sudo systemctl reload ssh      # Debian/Ubuntu-তে; RHEL-ভিত্তিকে — sshd

কনফিগ ঠিক থাকলে sshd -t কিছুই দেখায় না। এখন নতুন টার্মিনালে নিশ্চিত হোন যে কী দিয়ে লগইন কাজ করছে, আর পাসওয়ার্ড দিয়ে সার্ভার প্রত্যাখ্যান করছে:

$ ssh -o PubkeyAuthentication=no deploy@203.0.113.10
deploy@203.0.113.10: Permission denied (publickey).

অতিরিক্ত সুরক্ষা

পাসওয়ার্ড বন্ধ করা মূল পদক্ষেপ। এরপর সাধারণত ফায়ারওয়াল দিয়ে ২২ নম্বর পোর্টের প্রবেশাধিকার সীমিত করা হয় (ufw allow from 198.51.100.0/24 to any port 22), এবং fail2ban বসানো হয়, যা কয়েকটি ব্যর্থ চেষ্টার পর IP ব্লক করে। SSH সুরক্ষার অবস্থা দেখায় sudo fail2ban-client status sshd।

স্বয়ংক্রিয় কাজের কী authorized_keys-এ কী-এর আগে অপশন দিয়ে সীমিত করা যায়: যেমন from="198.51.100.7",no-port-forwarding,no-pty ssh-ed25519 AAAA... backup শুধু একটি ঠিকানা থেকে এবং ইন্টারঅ্যাকটিভ শেল ছাড়া লগইনের অনুমতি দেয়।

সাধারণ ভুল ও সমাধান

Permission denied (publickey)

এটি সবচেয়ে সাধারণ ত্রুটি। কারণগুলো, সাধারণ থেকে বিরল ক্রমে:

1. সার্ভারে ভুল অধিকার। ডিরেক্টরি বা ফাইল অন্যদের লেখার যোগ্য হলে sshd authorized_keys উপেক্ষা করে। সমাধান: chmod 700 ~/.ssh, chmod 600 ~/.ssh/authorized_keys, এবং হোম ডিরেক্টরি গ্রুপ বা অন্যদের লেখার যোগ্য হবে না।
2. ভুল মালিক। ফাইল sudo দিয়ে তৈরি হলে সেগুলোর মালিক root। সমাধান: sudo chown -R deploy:deploy /home/deploy/.ssh।
3. কী ভুল ব্যবহারকারীর জন্য রাখা। আপনি root-এর জন্য কী কপি করেছেন, অথচ লগইন করছেন deploy হিসেবে, বা উল্টো।
4. ক্লায়েন্ট ভুল কী দিচ্ছে। ssh -v দেখুন: Offering public key লাইনে কোন কীগুলো চেষ্টা হচ্ছে তা দেখা যায়। -i বা IdentityFile দিয়ে সঠিক কী নির্দিষ্ট করুন।
5. কপি করার সময় কী নষ্ট। পাবলিক কী এক লাইনে থাকতে হবে। ক্লিপবোর্ড থেকে লাইন ভেঙে গেলে কী নষ্ট হয়।

সার্ভারের দিক থেকে কারণ দেখায় লগ: sudo journalctl -u ssh -n 30 (RHEL-এ -u sshd)। সেখানে এমন লাইন দেখা যায়: Authentication refused: bad ownership or modes for directory /home/deploy/.ssh।

UNPROTECTED PRIVATE KEY FILE

ক্লায়েন্ট এমন প্রাইভেট কী ব্যবহার করতে অস্বীকার করে যা অন্য ব্যবহারকারীরা পড়তে পারে। সমাধান: chmod 600 ~/.ssh/id_ed25519।

REMOTE HOST IDENTIFICATION HAS CHANGED

হোস্টের কী known_hosts-এ সংরক্ষিত কীর সঙ্গে মেলে না। সার্ভার নতুন করে ইনস্টল করা হলে বা IP বদলালে এমন হয়, কিন্তু একই দৃশ্য "man-in-the-middle" আক্রমণেও দেখা যায়। নিশ্চিত হোন যে সার্ভারটি সত্যিই নতুন করা হয়েছে, তারপর পুরোনো এন্ট্রি মুছুন: ssh-keygen -R 203.0.113.10।

Too many authentication failures

এজেন্ট সার্ভারের কাছে অনেক বেশি কী পাঠিয়েছে, আর MaxAuthTries-এর কারণে সার্ভার সংযোগ বন্ধ করেছে। সমাধান: IdentitiesOnly yes এবং ~/.ssh/config-এ স্পষ্ট IdentityFile।

সংক্ষেপে

SSH কী সেটআপ পাঁচ মিনিটের কাজ: ssh-keygen -t ed25519, ssh-copy-id, লগইন যাচাই, তারপর PasswordAuthentication no এবং দ্বিতীয় সেশন খোলা রেখে sshd পুনরায় লোড। ~/.ssh/config লম্বা কমান্ড কমায়, আর 700/600 অধিকার বেশিরভাগ "Permission denied" সমস্যার সমাধান। SSH, rsync এবং ফায়ারওয়াল ও fail2ban দিয়ে সার্ভার সুরক্ষা লিনাক্স কোর্সে হাতে-কলমে শেখানো হয়।