SSH Permission Denied (publickey): আসল সমাধান

রাত 02:10-এ একটা ডিপ্লয় মারা গেল হাজারবার টাইপ করা লাইনে: ssh deploy@staging → Permission denied (publickey)। কী ঠিকই ছিল। ভাঙা ছিল অফারটা।

TL;DR: Permission denied (publickey) মানে ক্লায়েন্টের দেওয়া প্রতিটা কী সার্ভার প্রত্যাখ্যান করেছে — নেগোসিয়েশনের রায়, password ভুল টাইপ নয়। ডায়াগনোজ করুন ssh -vvv দিয়ে (কোন কোন কী অফার হলো) আর সার্ভার লগ journalctl -u ssh দিয়ে (কোন কী প্রত্যাখ্যাত হলো, কেন)। তারপর চার কারণের একটা ঠিক করুন: ভুল ইউজার, authorized_keys-এ কী নেই, permission বেশি খোলা, নয়তো ssh-rsa কী যেটা OpenSSH 8.8+ প্রত্যাখ্যান করে। ssh-copy-id বেশিরভাগ পুনরাবৃত্তি আগেই আটকে দেয়।

$ ssh -T [email protected]
[email protected]: Permission denied (publickey).

এররটা রায়, ইঙ্গিত নয়: অফারের সবটাই প্রত্যাখ্যাত।

SSH “Permission denied (publickey)” কেন বলে?

পাবলিক-কী auth প্রস্তাব-প্রত্যাখ্যানের এক নেগোসিয়েশন। ক্লায়েন্ট খুঁজে পাওয়া প্রতিটা কী পেশ করে — এজেন্টের আইডেন্টিটি, আপনার ~/.ssh/config, ডিফল্ট ফাইলনাম (id_ed25519, id_rsa) আর -i দিয়ে পাঠানো যা-কিছু। সার্ভার প্রতিটা অফার মেলায় টার্গেট অ্যাকাউন্টের ~/.ssh/authorized_keys-এর সঙ্গে। কোনোটাই না মিললে, আর password auth বন্ধ বা শেষ হয়ে গেলে, ক্লায়েন্ট সেই এক লাইন ছাপে যেটা প্রত্যেক devops ইঞ্জিনিয়ার মুখস্থ।

ডিবাগিংয়ে দুটো সত্য কাজে লাগে। এক, মেসেজ বলে না কোন ইউজারে ধাক্কা লাগল — সব কেসের অর্ধেকেই নিখুঁত ভালো একটা কী ভুল অ্যাকাউন্টের authorized_keys-এ বসে আছে। দুই, কেন-এর উত্তর সার্ভার আগেই বলে দিয়েছে: sshd প্রতিটা প্রত্যাখ্যাত অফার লগ করে। কেউ চায়নি অথচ সবার দরকার এমন ক্লায়েন্ট-সাইড স্ট্যাক ট্রেসটা হলো -vvv।

SSH আসলে কোন কী অফার করছে তা কীভাবে জানবেন?

ssh -vvv deploy@staging 2>&1 | grep -iE "offering|identity|denied|authentications"
# debug1: Offering public key: /home/you/.ssh/id_ed25519 RSA-SHA256 (explicit)
# debug1: Authentications that can continue: publickey
# deploy@staging: Permission denied (publickey).

তিনটা লাইন পড়ুন: Offering public key (ক্লায়েন্ট কী পেশ করল), Authentications that can continue (সার্ভার এখনো কী গ্রহণ করবে — password না থাকলে password প্রম্পট আর আসবেই না), আর শেষ রায়। কাঙ্ক্ষিত কী অফার তালিকায় কোথাও না দেখালে সমস্যা ক্লায়েন্ট-সাইডে: ভুল -i পাথ, ~/.ssh/config-এ ভুলে যাওয়া কোনো IdentityFile, নয়তো এজেন্ট (ssh-add -l) বসিয়ে রেখেছে এমন একটা বাসি আইডেন্টিটি যেটা আগে সাড়া দেয়।

চারটে আসল কারণ কী কী?

কারণ	চেনার উপায়	সমাধান
ভুল ইউজার	root@host-এ কী কাজ করে, deploy@host-এ ব্যর্থ	কী থাকতে হবে ওই ইউজারের ~/.ssh/authorized_keys-এ
কী ইনস্টল নেই	সার্ভার লগে প্রতিটা অফারে Failed publickey	ssh-copy-id user@host
Permission বেশি খোলা	ক্লায়েন্ট: WARNING: UNPROTECTED PRIVATE KEY FILE — কী বাদ পড়ে, অফারই হয় না	chmod 700 ~/.ssh; chmod 600 ~/.ssh/*
পুরনো ssh-rsa কী	সার্ভারে OpenSSH 8.8+; পুরনো RSA কী কখনো গৃহীত হয় না	ed25519 দিয়ে নতুন করে বানান, বা কী আপগ্রেড করুন

Permission-জাত কারণটা আলাদা নোট দাবি করে, কারণ OpenSSH এটা কঠোরভাবে মানায়: গ্রুপ বা বাকি সবাই যে প্রাইভেট কী পড়তে পারে, সেটাকে ক্লায়েন্ট নিজেই প্রত্যাখ্যান করে আর চুপচাপ অফার থেকে বাদ পড়ে। সমাধান দুই কমান্ড:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519 ~/.ssh/authorized_keys

ssh-rsa কারণটা পুরনো CI ইমেজ আর Raspberry Pi-তে ধরা দেয়: OpenSSH 8.8 (প্রকাশ 2021-10-01, openssh.com/txt/release-8.8) ssh-rsa সিগনেচার — SHA-1-ভিত্তিক রূপটা — ডিফল্টে বন্ধ করে দিয়েছে। রিলিজ নোটের ভাষায়, “the ssh-rsa signature scheme is … disabled by default”। 2018-এ বানানো একটা RSA কী ভাঙা নয়; ওর সিগনেচার ফরম্যাট আর কেউ বলে না শুধু। ed25519 কী বানানো (ssh-keygen -t ed25519) টেকসই উত্তর, আর ঠিক করতে গিয়ে নিজেকে বাইরে ফেলে রাখলে ক্লাউড কনসোল সিরিয়াল কনসোল দেয়।

সার্ভার কী কেন প্রত্যাখ্যান করল তা কীভাবে দেখবেন?

সার্ভার-সাইড লগই সৎ সাক্ষী। Ubuntu-তে (systemd), sshd প্রতি-অফার রায় লগ করে:

journalctl -u ssh -n 50 --no-pager | grep -iE "publickey|denied|accepted"
# sshd[4421]: Failed publickey for deploy from 203.0.113.7 port 51422 ssh2: RSA SHA256:...
# sshd[4421]: Accepted publickey for deploy from 203.0.113.7 port 51422 ssh2: ED25519 SHA256:...

অপ্রত্যাশিত ফিঙ্গারপ্রিন্টসহ Failed publickey মানে ক্লায়েন্ট আপনার ভাবা কী-র বদলে অন্যটা অফার করেছে — ফিরে যান -vvv-তে। আপনার ফিঙ্গারপ্রিন্টসহ Failed publickey মানে কী ঠিকই আছে কিন্তু ওই অ্যাকাউন্টে ইনস্টল নেই, নয়তো সার্ভার-সাইডে হোম ডিরেক্টরির permission ভুল (একই 700/600 নিয়ম সার্ভারের ~/.ssh আর ~/.ssh/authorized_keys-এও খাটে)। কনফিগ এডিটের মাঝে sshd যদি স্টার্টই না হয়, সেটা অন্য শিকার — দেখুন systemd service not starting।

নিজের কী সঠিকভাবে কীভাবে ইনস্টল করবেন?

ssh-copy-id deploy@staging
# Number of key(s) added: 1
ssh -o BatchMode=yes deploy@staging 'echo ok'   # নন-ইন্টারঅ্যাকটিভ প্রমাণ

ssh-copy-id আপনার পাবলিক কী টার্গেট অ্যাকাউন্টের authorized_keys-এ জোড়া লাগায় আর সুস্থ permission বসিয়ে দেয় — টুলটা আছেই কারণ হাতে authorized_keys-এ পেস্ট করা ঠিক এই ঘনঘন ব্যর্থ হয়: ট্রেইলিং নিউলাইন বা অনুপস্থিত ডিরেক্টরি। BatchMode চেকটাই আসল পরীক্ষা: এটা সব প্রম্পট বন্ধ রাখে, তাই সফল হলে বোঝা যায় লগইনটা কী-ই বহন করেছে। কী একবার চললে scp আর rsync একই auth বিনামূল্যে পেয়ে যায় — দুটোর বাছাই ব্যান্ডউইথের প্রশ্ন, ক্রেডেনশিয়ালের নয় (rsync vs scp)।

30 সেকেন্ডের ট্রায়াজ

ssh -vvv user@host 2>&1 | grep -i offering      # 1. কোন কোন কী অফার হলো?
journalctl -u ssh -n 50 | grep -i publickey     # 2. কেন প্রত্যাখ্যাত?
ls -ld ~/.ssh ~/.ssh/authorized_keys            # 3. 700 / 600?
ssh-copy-id user@host                           # 4. ইনস্টল করুন, তারপর BatchMode দিয়ে যাচাই

Permission denied (publickey) নেগোসিয়েশনের ফল, password প্রম্পট নয় — সার্ভার অফারের প্রতিটা কী প্রত্যাখ্যান করেছে, আর কেন জানে তার নিজের লগই।

চারটা কমান্ড ক্রমে চালান, ব্যর্থতা আর রহস্য থাকবে না: একটা না একটা প্রতিবারই অপরাধীর নাম ধরে। আমারটা ছিল বাসি এজেন্ট আইডেন্টিটি যেটা সঠিক কী-র আগে সাড়া দিচ্ছিল — ssh-add -d, আর 02:31-এ ডিপ্লয় সবুজ হলো।