SSD Nodes Learn 🎉 VPS $5.50/মাস থেকে
নির্দেশিকা Matt Connorদ্বারা Matt Connor · আপডেট করা হয়েছে 2026-08-13

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

Permission denied (publickey) পাঁচটি আলাদা সমস্যার ইঙ্গিত দিতে পারে। ssh -v-এর তিনটি line পড়ে আপনার কারণটি শনাক্ত করুন এবং lock out না হয়ে সমাধান করুন।

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

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

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

একটি message পাঁচটি আলাদা সমস্যাকে নির্দেশ করতে পারে এবং এটি ইচ্ছাকৃতভাবেই অস্পষ্ট। কোনো server যদি "no such user" বা "that key is not installed" জানাত, তাহলে valid account খুঁজে বের করতে থাকা ব্যক্তিদের সহায়তা করত। তাই সঙ্গে সঙ্গে key বদলানো বা configuration 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 ব্যবহার করতে চেয়েছিলেন, সেটি নয়; command line, ~/.ssh/config অথবা আপনার local login name থেকে ssh যে username নির্ধারণ করেছে, সেটি।

Authentications that can continue: publickey হলো server-এর গ্রহণযোগ্য method-এর তালিকা। কোনো key পরীক্ষা করার আগে server এই তালিকা পাঠায়। প্রথম তালিকায় 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 ব্যবহার করে সম্পূর্ণ authentication exchange চালায় এবং শেষে একই message দিয়ে সংযোগ প্রত্যাখ্যান করে, কারণ বৈধ account name প্রকাশ পেলে attacker উপকৃত হয়। 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 account থাকে, Rocky Linux এবং AlmaLinux-এ rocky ও almalinux account থাকে, আর অনেক VPS provider আপনার key সরাসরি root-এ install করে। আপনার 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 করতে না পারলে, সম্ভবত image-এর default user-এর জন্য key install করা হয়েছিল এবং পরে আপনার তৈরি account-এ তা copy করা হয়নি। এটি নতুন VPS-এ প্রথম দশ মিনিটের কাজের অংশ, এবং এটি সহজেই বাদ পড়তে পারে।

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

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

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

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

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

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

IdentitiesOnly=yes ব্যবহার করলে আপনি যে file দিয়েছেন, শুধু সেটি দিয়ে চেষ্টা সীমাবদ্ধ থাকে। agent-এ কী কী আছে তা ssh-add -l দিয়ে দেখুন। বহু বছরের পুরোনো 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 কখনো offer করা হয় না এবং 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-এর সঙ্গে এগুলো মিলিয়ে দেখুন। 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-এ থাকতে হবে। তাই line ভেঙে যাওয়া key-কে একাধিক নষ্ট entry হিসেবে পড়া হয় এবং কোনো কিছুর সঙ্গে মেলে না।
  • আপনি `/root/.ssh/authorized_keys-এ key রেখেছেন, কিন্তু deploy` হিসেবে লগ ইন করছেন, অথবা উল্টোটি হয়েছে। এই file প্রতিটি account-এর জন্য আলাদা; কোনো shared file নেই।
  • Provider-এর "add my key" box শুধু image-এর default user-এর জন্য key লিখেছে। তাই পরে তৈরি করা 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-এর ডিফল্ট আচরণ। এই অবস্থায়, .ssh directory, অথবা account-এর home directory owner ছাড়া অন্য কেউ লিখতে পারলে sshd authorized_keys পড়তে অস্বীকার করে। কারণটি সরাসরি: group বা world যদি আপনার home directory-তে লিখতে পারে, সেই access থাকা যেকোনো account authorized_keys প্রতিস্থাপন করে login দখল করতে পারে। অবিশ্বস্ত path-কে sshd এমনভাবে বিবেচনা করে, যেন কোনো 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 সবগুলো গ্রহণযোগ্য। 775 এবং 777 ব্যর্থ হবে।
  • ~/.ssh: mode 700।
  • ~/.ssh/authorized_keys: mode 600।
  • Ownership: তিনটিই যে account দিয়ে login করছেন, সেই account-এর মালিকানাধীন হতে হবে; root-এর নয়।

Mode-এর মতো ownership-ও গুরুত্বপূর্ণ। /home/deploy/.ssh-এর ভেতরের কোনো file root-এর মালিকানাধীন হলে একই check ব্যর্থ হবে। 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 আপনাকে প্রত্যাখ্যান করার জন্য configured

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

sshd বাস্তবে যে configuration ব্যবহার করছে, তা দেখতে চালান:

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

সুস্থ configuration-এর output দেখতে এমন হবে:

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 অন্য কোথাও নির্দেশ করছে, যেমন /etc/ssh/authorized_keys/%u। তখন home directory-এর আপনার file সম্পূর্ণ উপেক্ষিত হয়, এবং কারণ 4-এর mode rule নতুন path-এর ক্ষেত্রে প্রযোজ্য হয়।
  • allowusers বা allowgroups উপস্থিত আছে। list-এ থাকা কোনো account ছাড়া অন্য সব account-কে ঠিক এই error দিয়ে, কোনো ব্যাখ্যা ছাড়াই প্রত্যাখ্যান করা হবে। denyusers এবং denygroups বিপরীতভাবে একই কাজ করে।
  • root হিসেবে login করার সময় permitrootlogin no। prohibit-password হলো কার্যকর মধ্যবর্তী setting: root key ব্যবহার করতে পারবে, কিন্তু password ব্যবহার করতে পারবে না।

কার সঙ্গে connection তৈরি হচ্ছে, তার ওপর ফল নির্ভর করে বলে plain sshd -T output-এ Match block দেখা যায় না। নির্দিষ্ট একটি connection সম্পর্কে জানতে চালান:

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

আরেকটি setting পুরোনো key-কে প্রভাবিত করে। OpenSSH 8.8 থেকে default হিসেবে 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 install করুন। server-এ PubkeyAcceptedAlgorithms +ssh-rsa setting করলে পুরোনো signature আবার চালু হয় এবং আজ server-এ প্রবেশ করা যায়। তাই এটিকে server-এ পৌঁছানোর অস্থায়ী উপায় হিসেবে দেখুন, চূড়ান্ত সমাধান হিসেবে নয়। server-side review করার মতো বাকি setting-গুলো VPS-এ SSH server hardening-এ দেওয়া আছে।

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

এই error-এর ক্ষেত্রে অধিকাংশ অনুমানের কারণ হলো, দুটি file একই pair কি না তা জানা যায় না। একটি command-এর মাধ্যমেই এটি যাচাই করা যায়:

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

এটি private key থেকে উৎপন্ন public key প্রদর্শন করে। এটি পাশের .pub file কখনো পড়ে না। তাই পুরোনো .pub file কী দাবি করছে তা নয়, 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। যে অবস্থানে এগুলো আর মেলে না, সমস্যাটি সেখানেই।

ব্যর্থ login-এর সময় server log দেখুন

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

sudo journalctl -u ssh -f

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

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

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

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

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

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

একই server-এর 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 এই test-এর বাইরে থাকে। 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) ব্যবহার করে, এবং সেখানে login করতে পারছেন কি না নিশ্চিত করুন।
  2. sudo-সহ কোনো account-এর জন্য কার্যকর local password আপনার জানা আছে কি না নিশ্চিত করুন। না থাকলে আগে provider console থেকে root password reset করুন।
  3. বর্তমান SSH session খোলা রাখুন। একটি খোলা session systemctl restart ssh টিকে থাকে, তাই নতুন configuration ভুল হলেও এটি ফিরে প্রবেশের একটি উপায় হিসেবে কাজ করবে।
  4. restart করার আগে syntax পরীক্ষা করুন: file বৈধ হলে sudo sshd -t কোনো output দেয় না; বৈধ না হলে file এবং line number দেখায়।
  5. প্রথম terminal বন্ধ করার আগে দ্বিতীয় terminal খুলে নতুন করে login করুন। ভুল configuration নতুন login বন্ধ করে, কিন্তু বিদ্যমান session-গুলো চালু রাখে। তাই যে session-এ আপনি ইতিমধ্যে আছেন, সেটি পরিবর্তনটি কাজ করেছে কি না জানাতে পারে না।

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

FAQ

একই key অন্য সার্ভারে কাজ করলেও আমি কেন Permission denied (publickey) পাই?

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

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

ssh -v host প্রতি key-এর জন্য একটি debug1: Offering public key: লাইন দেখায়। প্রতিটি লাইনে 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 লাইনের fingerprint-টিও সার্ভারের 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 চালু থাকলে সার্ভার 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 প্রয়োজন হলে সার্ভারে PubkeyAcceptedAlgorithms +ssh-rsa যোগ করলে পুরোনো signature আবার চালু হবে। নতুন key কাজ করার পর ওই line সরিয়ে ফেলুন।

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

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

#ssh#openssh#troubleshooting#permissions#vps