SSH-তে Permission denied (publickey) ঠিক করার উপায়

Permission denied (publickey) আসলে কী বোঝায়

Permission denied (publickey) বার্তার অর্থ হলো, আপনার client এক বা একাধিক public key পাঠিয়েছে, কিন্তু server কোনো key গ্রহণ করেনি। Network ঠিক আছে এবং sshd চলছে; authentication-এর শেষ ধাপে প্রত্যাখ্যান করা হয়েছে। এর আগেই যদি আপনার session বন্ধ হয়ে যায়, তাহলে আপনি connection refused বা connection timed out পরিস্থিতি দেখছেন। এটি ভিন্ন diagnosis এবং এর test-ও আলাদা। সমাধান অনুমান করে নির্ধারণ করতে হয় না, কারণ ssh -v দেখায় যে পাঁচটি কারণের কোনটি ঘটেছে।

বন্ধনীর ভেতরের শব্দগুলো server যে authentication method গ্রহণ করতে প্রস্তুত ছিল, তা নির্দেশ করে। শুধু Permission denied (publickey) থাকলে বোঝায়, ওই server-এ password login বন্ধ আছে। তাই password দিয়ে fallback করার সুযোগ নেই। Permission denied (publickey,password) থাকলে বোঝায়, password ব্যবহারের সুযোগ ছিল, কিন্তু সেই চেষ্টাতেও authentication ব্যর্থ হয়েছে।

একটি message পাঁচটি পৃথক fault নির্দেশ করে এবং এটি ইচ্ছাকৃতভাবেই অস্পষ্ট। কোনো server যদি "no such user" বা "that key is not installed" উত্তর দিত, তাহলে valid account খুঁজে বের করা সহজ হয়ে যেত। তাই সঙ্গে সঙ্গে key বদলানো বা config file সম্পাদনা শুরু করবেন না। একটি command চালান, output-এর তিনটি line পড়ুন, এবং পাঁচটি সম্ভাব্য কারণের মধ্যে একটি নির্দিষ্ট কারণ চিহ্নিত করুন।

প্রথমে ssh -v চালান এবং তিনটি লাইন পড়ুন

-v যোগ করে যে কমান্ডটি ব্যর্থ হয়েছে, সেটি আবার চালান:

ssh -v deploy@203.0.113.10

বাস্তবসম্মত, সংক্ষিপ্ত একটি আউটপুট এমন হতে পারে:

OpenSSH_9.6p1 Ubuntu-3ubuntu13, OpenSSL 3.0.13 30 Jan 2024
debug1: Connecting to 203.0.113.10 [203.0.113.10] port 22.
debug1: Connection established.
debug1: Authenticating to 203.0.113.10:22 as 'deploy'
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Will attempt key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Offering public key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
deploy@203.0.113.10: Permission denied (publickey).

আপনার প্রয়োজনীয় সব তথ্য এই তিনটি লাইনে থাকে।

Authenticating to 203.0.113.10:22 as 'deploy' হলো বাস্তবে ব্যবহৃত username। আপনি যে username ব্যবহার করতে চেয়েছিলেন, সেটি নয়; কমান্ড লাইন, ~/.ssh/config অথবা আপনার local login name থেকে ssh যে username নির্ধারণ করেছে, সেটি।

Authentications that can continue: publickey হলো server-এর গ্রহণযোগ্য method-এর তালিকা, কোনো key পরীক্ষা করার আগেই যা পাঠানো হয়। প্রথম তালিকায় publickey না থাকলে server-এ public key login বন্ধ আছে। তাই কোনো key-ই কাজ করবে না।

Offering public key: ... হলো client সত্যিই পাঠানো প্রতিটি key-এর জন্য একটি করে লাইন। এতে key-টি কোন file থেকে এসেছে এবং তার SHA256 fingerprint উল্লেখ থাকে। কোনো key-এর জন্য Offering লাইন না থাকলে সেটি server-এ পাঠানো হয়নি।

এখন সমস্যাটিকে দুটি ভাগে বিভক্ত করুন:

• প্রত্যাশিত key-এর জন্য কোনো Offering public key লাইন নেই। ত্রুটিটি আপনার machine-এ, কারণ server আপনার key একেবারেই পায়নি।
• Key পাঠানো হয়েছে এবং আবার Authentications that can continue: publickey দেখা যাচ্ছে। Server ওই key পেয়েছে, কিন্তু প্রত্যাখ্যান করেছে। তাই ত্রুটিটি server-এ।

নিচের কারণগুলোতে কোনটি সমাধান হিসেবে পাওয়া যায়, সেই অনুযায়ী এগুলো সাজানো হয়েছে।

কারণ 1: আপনি ভুল username দিয়ে সংযোগ করছেন

সবচেয়ে সাধারণ কারণটি একই সঙ্গে সবচেয়ে কম গুরুত্বপূর্ণ। SSH (secure shell) server daemon sshd কোনো account নেই—এ কথা কখনো জানায় না। এটি তৈরি করা username ব্যবহার করে পুরো সংযোগ প্রক্রিয়া চালায় এবং শেষে একই বার্তা দেখিয়ে সংযোগ প্রত্যাখ্যান করে, কারণ বৈধ account name প্রকাশ হলে আক্রমণকারীর সুবিধা হয়। username-এ একটি typo থাকলেও ফলাফলটি নষ্ট key-এর মতোই দেখায়।

অন্য কিছু করার আগে Authenticating to ... as line পরীক্ষা করুন। সেখানে server account-এর পরিবর্তে আপনার laptop login-এর নাম থাকলে, আপনি command-এ username দেননি।

ssh -v deploy@203.0.113.10
ssh -v root@203.0.113.10

আপনার provider যে image তৈরি করে, তার ওপর default account নির্ভর করে। August 2026 অনুযায়ী, Ubuntu cloud image-এ সাধারণত ubuntu account, Debian image-এ debian বা admin, Rocky Linux এবং AlmaLinux-এ rocky ও almalinux account থাকে। আবার অনেক VPS provider সরাসরি root-এ আপনার key ইনস্টল করে। আপনার provider-এর control panel-এ তৈরি করা account-এর নাম উল্লেখ থাকে। Server-এর বাইরে থেকে চালানো কোনো command এই তথ্য জানতে পারে না।

~/.ssh/config-এর একটি Host block-এও username নির্ধারণ করা যায়। এটি আপনার local login name-এর ওপর অগ্রাধিকার পায়:

Host vps-prod
  HostName 203.0.113.10
  User deploy

আপনি নিজে account তৈরি করার পর সেটি দিয়ে login করতে না পারলে, সম্ভবত key-টি image-এর default user-এর জন্য ইনস্টল করা হয়েছিল এবং নতুন account-এ কপি করা হয়নি। এটি নতুন VPS-এর প্রথম দশ মিনিটের কাজের অংশ, এবং এই ধাপটি সহজেই বাদ পড়ে।

Cause 2: আপনি যে key পাঠাচ্ছেন বলে মনে করছেন, আসলে সেটি পাঠানো হচ্ছে না

ডিফল্টভাবে ssh শুধু ssh-agent-এ থাকা key এবং ~/.ssh-এ থাকা নির্দিষ্ট কিছু filename ব্যবহার করে: id_ed25519, id_ecdsa, id_rsa এবং ওই নামগুলোর hardware ও DSA variant। ~/.ssh/vps-prod নামে সংরক্ষিত key-এর নাম নির্দিষ্ট না করা পর্যন্ত ssh সেটি দেখতে পায় না। তাই verbose output-এ এর জন্য কোনো Offering public key line দেখা যায় না।

File-এর নাম নির্দিষ্ট করুন এবং agent-এর key-গুলোকে সেটির জায়গা নিতে বাধা দিন:

ssh -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@203.0.113.10

Agent-এ key থাকলে শুধু -i ব্যবহার করা যথেষ্ট নয়। কারণ ssh প্রথমে agent-এর key-গুলো এবং শেষে নির্দিষ্ট file-টি পাঠায়। এটি গুরুত্বপূর্ণ, কারণ server প্রতিটি প্রত্যাখ্যাত key-কে MaxAuthTries-এর বিপরীতে গণনা করে, যার default মান 6। কোনো agent-এ সাতটি key থাকলে সঠিক key-তে পৌঁছানোর আগেই limit শেষ হয়ে যেতে পারে। তখন message পরিবর্তিত হয়ে হয়:

Received disconnect from 203.0.113.10 port 22:2: Too many authentication failures

আপনি যদি এর বদলে এই বার্তাটি দেখে থাকেন, তাহলে সঠিক key ব্যবহার করার পালা আসার আগেই সার্ভার session বিচ্ছিন্ন করেছে। এই বিষয়টি অতিরিক্ত authentication failure-এ ব্যাখ্যা করা হয়েছে। IdentitiesOnly=yes প্রচেষ্টাকে আপনার নির্দিষ্ট করা file-এ সীমাবদ্ধ করে। agent বর্তমানে কোন key ধরে রেখেছে তা ssh-add -l দিয়ে তালিকাভুক্ত করুন। agent-এ বহু বছরের পুরোনো key জমে থাকলে ssh-add -D দিয়ে সেগুলো সরিয়ে দিন। এরপর settings লিখে রাখুন, যাতে পরবর্তী login-এ flag মনে রাখার ওপর নির্ভর করতে না হয়:

Host vps-prod
  HostName 203.0.113.10
  User deploy
  IdentityFile ~/.ssh/vps-prod
  IdentitiesOnly yes

Client-side আরও একটি সমস্যা আছে। আপনার নিজের machine-এর অন্য account-গুলো কোনো private key পড়তে পারলে ssh সেটি ব্যবহার করতে অস্বীকার করে। এটি warning দেখিয়ে key-টি উপেক্ষা করে। ফলে key কখনো পাঠানো হয় না এবং server-ও সেটি দেখতে পায় না:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/you/.ssh/vps-prod' are too open.

chmod 600 ~/.ssh/vps-prod এটি ঠিক করে। USB stick বা Windows share-এর মাধ্যমে key স্থানান্তর করলে সাধারণত mode পরিবর্তিত হয়ে যায়। Key কোথায় রাখা উচিত এবং কী নাম দেওয়া উচিত, তা SSH key management-এর প্রাথমিক বিষয়-এ ব্যাখ্যা করা হয়েছে।

কারণ 3: public key কখনো authorized_keys-এ পৌঁছায়নি

`ssh -v-এ key পাঠানো হচ্ছে দেখা গেলেও server যদি তবু প্রত্যাখ্যান করে, পরের প্রশ্ন হলো সেই key account-এর authorized_keys` file-এ আছে কি না। পরীক্ষা করতে provider-এর console খুলুন, কারণ SSH দিয়ে লগ ইন করে এটি দেখা সম্ভব নয়।

sudo ls -l /home/deploy/.ssh/
sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys

একটি `authorized_keys file-এ ssh-keygen -lf` চালালে প্রতিটি entry-এর জন্য একটি করে fingerprint দেখায়:

256 SHA256:0eL/8sBw... you@laptop (ED25519)
3072 SHA256:9Tq2yZk... old-laptop (RSA)

আপনার `Offering public key` line-এ থাকা fingerprint-এর সঙ্গে এগুলো মিলিয়ে দেখুন। এটি তালিকায় না থাকলে, আপনি যা করার কথা মনে করছেন তা করলেও key ওই account-এ install করা নেই।

এটি ভুল হওয়ার চারটি সাধারণ উপায়:

• আপনি `.pub file-এর পরিবর্তে private key paste করেছেন। একটি public key line ssh-ed25519 বা ssh-rsa দিয়ে শুরু হয়। একটি private key -----BEGIN OPENSSH PRIVATE KEY-----` দিয়ে শুরু হয়।
• Paste করার সময় line কয়েকটি অংশে ভেঙে গেছে। প্রতিটি entry অবশ্যই ঠিক একটি line-এ থাকতে হবে। তাই ভেঙে যাওয়া key কয়েকটি অসম্পূর্ণ entry হিসেবে পড়া হয় এবং কোনো কিছুর সঙ্গে মেলে না।
• আপনি key `/root/.ssh/authorized_keys-এ রেখেছেন, কিন্তু লগ ইন করছেন deploy` হিসেবে, অথবা উল্টোটি। এই file প্রতিটি account-এর জন্য আলাদা; কোনো shared file নেই।
• Provider-এর “add my key” box এটি শুধু image-এর default user-এর জন্য লিখেছে। ফলে পরে তৈরি করা account-এর `.ssh` directory খালি রয়েছে।

Console থেকে root হিসেবে key যোগ করার নিরাপদ পদ্ধতি:

sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo tee -a /home/deploy/.ssh/authorized_keys >/dev/null <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyDataHere you@laptop
EOF
sudo chown deploy:deploy /home/deploy/.ssh/authorized_keys
sudo chmod 600 /home/deploy/.ssh/authorized_keys

এরপর আবার `sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys চালান। নতুন fingerprint এখন তালিকায় থাকা উচিত। যে machine থেকে এখনো password দিয়ে লগ ইন করা যায়, সেখানে ssh-copy-id -i ~/.ssh/vps-prod.pub deploy@203.0.113.10` একই কাজ করে এবং mode-গুলোও সঠিকভাবে সেট করে।

কারণ 4: permissions অতিরিক্ত উন্মুক্ত হলে sshd কেন authorized_keys উপেক্ষা করে

StrictModes yes হলো sshd-এর default আচরণ। এই আচরণে, .ssh ফাইল, authorized_keys directory অথবা account-এর home directory owner ছাড়া অন্য কারও দ্বারা write করা গেলে sshd authorized_keys পড়তে অস্বীকার করে। কারণটি সরাসরি: group বা world যদি আপনার home directory-তে write করতে পারে, সেই access থাকা যেকোনো account authorized_keys প্রতিস্থাপন করে login দখল করতে পারে। sshd অবিশ্বস্ত path-কে এমনভাবে বিবেচনা করে, যেন কোনো key-ই নেই।

Client শুধু সাধারণ Permission denied message দেখে। Server log-এ প্রকৃত কারণ লেখা থাকে:

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh

অথবা সমস্যা file-টিতেই হলে:

Authentication refused: bad ownership or modes for file /home/deploy/.ssh/authorized_keys

sshd যা গ্রহণ করবে:

• Home directory: group-writable এবং world-writable কোনোটিই হবে না। 755, 750 এবং 700 pass করে। 775 এবং 777 fail করে।
• ~/.ssh: mode 700।
• ~/.ssh/authorized_keys: mode 600।
• Ownership: তিনটিই যে account দিয়ে আপনি login করছেন, সেই account-এর মালিকানাধীন হবে; root-এর নয়।

Mode-এর মতো ownership-ও গুরুত্বপূর্ণ। /home/deploy/.ssh-এর ভেতরের কোনো file root-এর মালিকানাধীন হলে একই check fail করে। sudo nano দিয়ে file তৈরি করে পরে ownership ফিরিয়ে দিতে ভুললে এমনটি হয়। দুটিই একসঙ্গে ঠিক করুন:

sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chmod go-w /home/deploy
ls -ld /home/deploy /home/deploy/.ssh

শেষ command-টি ফলাফল দেখায়। Home directory-তে drwxr-xr-x বা তার চেয়ে কঠোর permission এবং .ssh-এ drwx------ থাকা উচিত। এই string-গুলোর অর্থ এখনও স্পষ্ট না হলে, live server-এ mode পরিবর্তনের আগে drwxr-xr-x-এর মতো permission string কীভাবে পড়বেন পড়ুন।

Rocky Linux এবং AlmaLinux-এ সন্দেহের তালিকায় SELinux (security-enhanced Linux)-কেও রাখুন। অস্বাভাবিক পদ্ধতিতে তৈরি করা .ssh directory-তে ভুল file label থাকতে পারে। ফলে mode সঠিক দেখালেও sshd read access পায় না। sudo restorecon -Rv /home/deploy/.ssh label পুনরায় সঠিকভাবে বসায়, আর sudo ausearch -m avc -ts recent দেখায় SELinux access প্রত্যাখ্যান করছিল কি না।

কারণ 5: sshd আপনাকে প্রত্যাখ্যান করার জন্য কনফিগার করা আছে

বর্তমান Ubuntu বা Debian সিস্টেমে /etc/ssh/sshd_config পড়াই যথেষ্ট নয়। ওই ফাইলটি Include /etc/ssh/sshd_config.d/*.conf দিয়ে শুরু হয়, এবং OpenSSH প্রতিটি সেটিংয়ের জন্য যে প্রথম মানটি পায়, সেটিই ব্যবহার করে। তাই 50-cloud-init.conf-এর মতো একটি drop-in ফাইল আগে পড়া হয় এবং মূল ফাইলের নিচের অংশে আপনি যা সম্পাদনা করেন, তার ওপর সেটির অগ্রাধিকার থাকে। এ কারণেই কোনো সম্পাদনা সঠিক দেখালেও কার্যত কিছুই পরিবর্তন নাও হতে পারে।

sshd বাস্তবে যে কনফিগারেশন ব্যবহার করছে, তা দেখতে চালান:

sudo sshd -T | grep -Ei 'pubkeyauth|authorizedkeysfile|permitrootlogin|allowusers|allowgroups|denyusers'

সুস্থ কনফিগারেশনে ফলাফলটি এমন দেখাবে:

permitrootlogin prohibit-password
pubkeyauthentication yes
authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2

আপনার নিজের output-এ নিচের বিষয়গুলো খুঁজুন:

• pubkeyauthentication no। কোনো key কখনো গ্রহণ করা হবে না। ssh -v-এও এটি প্রথম Authentications that can continue: list হিসেবে দেখা যায়, যেখানে কোনো publickey নেই।
• authorizedkeysfile অন্য কোনো path নির্দেশ করছে, যেমন /etc/ssh/authorized_keys/%u। সে ক্ষেত্রে home directory-র আপনার ফাইল সম্পূর্ণ উপেক্ষা করা হবে, এবং কারণ 4-এর mode rule নতুন path-এর ক্ষেত্রে প্রযোজ্য হবে।
• allowusers বা allowgroups উপস্থিত আছে। তালিকায় নেই এমন যেকোনো account-কে ঠিক এই error দিয়ে এবং কোনো ব্যাখ্যা ছাড়াই প্রত্যাখ্যান করা হবে। denyusers এবং denygroups বিপরীতভাবে একই কাজ করে।
• root হিসেবে login করার সময় permitrootlogin no। prohibit-password হলো কার্যকর মধ্যবর্তী সেটিং: root key ব্যবহার করতে পারবে, কিন্তু password ব্যবহার করতে পারবে না।

সাধারণ sshd -T-এ Match block দেখা যায় না, কারণ এর ফলাফল কে সংযোগ করছে তার ওপর নির্ভর করে। একটি নির্দিষ্ট সংযোগ সম্পর্কে জানতে চালান:

sudo sshd -T -C user=deploy,host=vps.example.com,addr=198.51.100.7

আরেকটি setting পুরোনো key-কে প্রভাবিত করে। OpenSSH 8.8 ডিফল্টভাবে SHA-1 signature (ssh-rsa) গ্রহণ করা বন্ধ করে দেয়। তাই বছরের পর বছর কাজ করা একটি RSA key server upgrade-এর পরপরই কাজ করা বন্ধ করতে পারে। client এটি স্পষ্টভাবে জানায়:

debug1: send_pubkey_test: no mutual signature algorithm

সঠিক সমাধান হলো নতুন key তৈরি করা: ssh-keygen -t ed25519 -C "deploy@vps-prod", তারপর উপরে দেখানো পদ্ধতিতে .pub file ইনস্টল করুন। server-এ PubkeyAcceptedAlgorithms +ssh-rsa সেট করলে পুরোনো signature আবার চালু হয় এবং আজই আপনাকে server-এ প্রবেশ করতে দেয়। তাই এটিকে server-এ পৌঁছানোর অস্থায়ী উপায় হিসেবে দেখুন, কাজের চূড়ান্ত সমাধান হিসেবে নয়। server-side পর্যালোচনার উপযোগী বাকি setting-গুলো VPS-এ SSH server hardening-এ রয়েছে।

ইনস্টল করা public key-এর সঙ্গে private key মেলে কি না কীভাবে প্রমাণ করবেন

এই ত্রুটির ক্ষেত্রে বেশিরভাগ অনিশ্চয়তা তৈরি হয় দুটি ফাইল পরস্পরের জোড়া কি না জানা না থাকায়। একটি command-ই এর উত্তর দেয়:

ssh-keygen -y -f ~/.ssh/vps-prod

এটি private key থেকে তৈরি public key প্রদর্শন করে। এটি পাশের .pub ফাইলটি কখনও পড়ে না। তাই পুরোনো .pub ফাইলটি কী দাবি করছে তা নয়, private key-টি আসলে কী তা জানা যায়। key-তে passphrase থাকলে command সেটি চাইবে। এতে আপনি এখনও passphrase জানেন কি না, সেটিও প্রমাণিত হয়।

ssh-keygen -lf ~/.ssh/vps-prod.pub
ssh-add -l

প্রথম command-টি একটি public key file-এর fingerprint প্রদর্শন করে। দ্বিতীয়টি আপনার agent-এ সংরক্ষিত key-গুলোর fingerprint প্রদর্শন করে। এখন একই string-এর চারটি দৃষ্টান্ত মিলিয়ে দেখুন: ssh -v-এর Offering public key line-এ থাকা fingerprint, আপনার .pub file-এর fingerprint, server-এর authorized_keys-এ থাকা ssh-keygen -lf-এর fingerprint এবং server log-এ থাকা fingerprint। যেখানে এগুলোর মিল বন্ধ হয়ে যায়, সমস্যার কারণ সেখানেই।

লগইন ব্যর্থ হওয়ার সময় সার্ভারের লগ দেখুন

ক্লায়েন্টকে ইচ্ছাকৃতভাবে কোনো কার্যকর তথ্য জানানো হয় না। সার্ভার প্রকৃত কারণটি লগে লেখে। console session-এ একটি log follower চালু করুন। এরপর আপনার laptop থেকে ব্যর্থ হওয়া ssh command চালান।

sudo journalctl -u ssh -f

Ubuntu 24.04-এ ডিফল্টভাবে rsyslog ইনস্টল থাকে না। তাই সেখানে /var/log/auth.log নাও থাকতে পারে। Rocky Linux এবং AlmaLinux-এ unit-এর নাম sshd। একই record-গুলো /var/log/secure-এও লেখা হয়।

sshd configuration-এ LogLevel VERBOSE সেট করুন। এরপর service reload করুন। প্রতিটি প্রচেষ্টায় সার্ভার আসলে যে fingerprint পেয়েছে, তা লগে লেখা হবে:

Failed publickey for deploy from 198.51.100.7 port 49812 ssh2: ED25519 SHA256:0eL/8sBw...

এই line-টি fault কোন পাশে তা জানায়। আপনি চেনেন এমন fingerprint-এর অর্থ হলো আপনার key সার্ভারে পৌঁছেছে, কিন্তু সার্ভার সেটি প্রত্যাখ্যান করেছে। তাই কারণ 3, 4 এবং 5 পরীক্ষা করুন। আপনি চেনেন না এমন fingerprint-এর অর্থ হলো আপনার client অনিচ্ছাকৃত একটি key পাঠিয়েছে। তাই কারণ 2-এ ফিরে যান।

লগ এখনও পরিষ্কার না হলে অন্য একটি port-এ debug mode-এ দ্বিতীয় sshd চালান। এটি foreground-এ থাকে, একটি connection গ্রহণ করে, নিজের সিদ্ধান্তের কারণ দেখায়, তারপর বন্ধ হয়ে যায়:

sudo /usr/sbin/sshd -ddd -p 2222

একই সার্ভারের console session থেকে loopback address ব্যবহার করে এতে connect করুন:

ssh -p 2222 -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@127.0.0.1

127.0.0.1 ব্যবহার করলে firewall এই পরীক্ষায় প্রভাব ফেলবে না। Debug output-এ খোলা file, তুলনা করা fingerprint এবং প্রত্যাখ্যানের সঠিক কারণ দেখা যাবে। এর মধ্যে Authentication refused: bad ownership or modes for directory /home/deploy-এর মতো line-ও থাকতে পারে। উত্তর পেয়ে গেলে Ctrl+C চাপুন। পুরো সময় port 22-এ চলমান প্রকৃত sshd-এর কোনো পরিবর্তন হবে না।

নিজেকে সার্ভার থেকে বিচ্ছিন্ন হওয়া এড়ানোর উপায়

সার্ভারের configuration সম্পাদন করে এমন প্রতিটি ধাপে SSH-এর ওপর নির্ভর না করে পুনরায় প্রবেশের একটি উপায় থাকতে হবে। SSH কাজ করার সময়ই এটি প্রস্তুত করুন; SSH নষ্ট হওয়ার পরে নয়।

1. আপনার provider-এর console খুলুন, serial বা VNC (virtual network computing) ব্যবহার করে, এবং সেখানে লগ ইন করতে পারছেন কি না নিশ্চিত করুন।
2. sudo-সহ কোনো account-এর কার্যকর local password আপনার জানা আছে কি না নিশ্চিত করুন। এমন password না থাকলে আগে provider console থেকে root password reset করুন।
3. বর্তমান SSH session খোলা রাখুন। একটি খোলা session systemctl restart ssh-এর পরেও টিকে থাকে। তাই নতুন configuration ভুল হলেও এটি পুনরায় প্রবেশের একটি উপায় হিসেবে থাকবে।
4. restart করার আগে syntax পরীক্ষা করুন: file সঠিক হলে sudo sshd -t কিছুই দেখায় না। ভুল থাকলে এটি file এবং line number দেখায়।
5. প্রথম terminal বন্ধ করার আগে দ্বিতীয় terminal খুলে নতুন করে লগ ইন করুন। ভুল configuration নতুন login বন্ধ করে, কিন্তু বিদ্যমান session-এ প্রভাব ফেলে না। তাই আপনি যে session-এ কাজ করছেন, সেটি পরিবর্তনটি কার্যকর হয়েছে কি না জানাতে পারে না।

Debian এবং Ubuntu-তে sudo systemctl restart ssh দিয়ে restart করুন। Rocky Linux এবং AlmaLinux-এ sudo systemctl restart sshd ব্যবহার করুন। Ubuntu 24.04-এ sshd একটি socket unit থেকে চালু হয়। তাই Port বা ListenAddress পরিবর্তন করলে কার্যকর হওয়ার আগে sudo systemctl restart ssh.socket-ও চালাতে হবে।

FAQ

একই key অন্য সার্ভারে কাজ করলেও কেন Permission denied (publickey) দেখায়?

কারণ key-টি ঠিক আছে, কিন্তু এর আশপাশের কোনো configuration ঠিক নেই। ssh -v চালিয়ে Offering public key line খুঁজুন। আপনার key তালিকায় না থাকলে ssh সেটি পাঠায়নি: file-টি default name-এ ~/.ssh-এ নেই এবং agent-এও loaded নয়। তাই -i /path/to/key -o IdentitiesOnly=yes যোগ করুন। key তালিকায় থাকলেও server প্রত্যাখ্যান করলে, সেই key account-এর authorized_keys-এ নেই, key-এর path group-writable, অথবা sshd config user-টিকে block করছে। Server log থেকে এই কারণগুলো আলাদা করা যায়।

SSH আসলে কোন key পাঠাচ্ছে তা কীভাবে দেখব?

ssh -v host প্রতি key-এর জন্য একটি debug1: Offering public key: line দেখায়। প্রতিটি line-এ source file এবং SHA256 fingerprint থাকে। Agent-এ থাকা fingerprint দেখতে ssh-add -l চালান। একটি নির্দিষ্ট key file-এর fingerprint দেখায় ssh-keygen -lf ~/.ssh/id_ed25519.pub। একটি private key থেকে বাস্তবে যে public key তৈরি হয়, তা দেখায় ssh-keygen -y -f ~/.ssh/id_ed25519। Login সফল হতে Offering line-এর fingerprint-টি server-এর authorized_keys-এর বিরুদ্ধে চালানো ssh-keygen -lf output-এও থাকতে হবে।

sshd কেন আমার authorized_keys file উপেক্ষা করে?

কারণ StrictModes default-ভাবে চালু থাকে। File, .ssh directory অথবা home directory group বা world-এর জন্য writable হতে পারে, অথবা ভুল account-এর মালিকানাধীন হতে পারে। অন্য কেউ পরিবর্তন করতে পারে এমন path-কে sshd বিশ্বাস করে না। তাই কোনো key না থাকার মতো আচরণ করে। Home directory-এর permission 755 বা তার চেয়ে কঠোর করুন, .ssh-কে 700 করুন, authorized_keys-কে 600 করুন, এবং তিনটির মালিক login account করুন। LogLevel VERBOSE ব্যবহার করলে server Authentication refused: bad ownership or modes for directory /home/deploy/.ssh রেকর্ড করে।

Server upgrade-এর পরপরই আমার key কাজ করা বন্ধ করেছে। কী পরিবর্তন হয়েছে?

এটি RSA key হলে সবচেয়ে সম্ভাব্য কারণ SHA-1 পরিবর্তন। OpenSSH 8.8 default-ভাবে ssh-rsa SHA-1 signature বন্ধ করেছে। তাই শুধু ওই পদ্ধতিতে sign করতে পারে এমন key এখন প্রত্যাখ্যাত হয়। Verbose client output-এ debug1: send_pubkey_test: no mutual signature algorithm দেখা যায়। ssh-keygen -t ed25519 ব্যবহার করে একটি আধুনিক key তৈরি করুন এবং এর .pub file install করুন। অবিলম্বে access প্রয়োজন হলে server-এ PubkeyAcceptedAlgorithms +ssh-rsa যোগ করলে পুরোনো signature আবার চালু হবে। নতুন key কাজ করলে ওই line সরিয়ে দিন।

sshd_config সম্পাদনা করার পর এখন কোনোভাবেই login করতে পারছি না। কীভাবে আবার access পাব?

আপনার provider-এর console ব্যবহার করুন। এটি SSH-এর মাধ্যমে সংযোগ করে না। সেখানে local password দিয়ে login করুন। Syntax error এবং তার line number দেখতে sudo sshd -t চালান। পরিবর্তনটি বাতিল করে service restart করুন। এরপর sudo sshd -T পরীক্ষা করে running values নিশ্চিত করুন। কারণ /etc/ssh/sshd_config.d/-এর কোনো file মূল config-কে override করতে পারে। Local password না থাকলে আগে console থেকে root password reset করুন। তারপর file-টি ঠিক করুন।