SSH Too Many Authentication Failures ঠিক করার উপায়

“Too many authentication failures” বলতে কী বোঝায়

“Too many authentication failures” বলতে বোঝায়, আপনার SSH client সার্ভার যতগুলো key পরীক্ষা করতে রাজি ছিল তার চেয়ে বেশি key পাঠিয়েছে। সঠিক key পরীক্ষা করার আগেই সার্ভার connection বন্ধ করে দিয়েছে। এটি প্রায় সবসময় client-এর সমস্যা। key আপনার disk-এ আছে, সার্ভারে সেটি authorized_keys-এ আছে, কিন্তু connection খুব তাড়াতাড়ি শেষ হয়ে যাওয়ায় এই দুটি তথ্য কোনো কাজে আসে না।

ক্রমটি এভাবে ঘটে। ssh-agent-এ আপনি load করা সব private key থাকে। আপনার client একবারে একটি করে key সার্ভারে পাঠায়, কারণ account কোন key গ্রহণ করবে তা client জানে না। সার্ভার authorized_keys-এ নেই এমন প্রতিটি key প্রত্যাখ্যান করে এবং প্রতিটি প্রত্যাখ্যানকে একটি ব্যর্থ authentication attempt হিসেবে গণনা করে। sshd_config-এর MaxAuthTries নির্ধারণ করে, একটি connection-এ সর্বোচ্চ কতটি ব্যর্থতা অনুমোদিত। Default হলো 6। আপনার agent-এ যদি দশটি key থাকে এবং সঠিক key-টি ধারাবাহিকতায় অষ্টম হয়, তাহলে সেটি পরীক্ষা করার আগেই সার্ভার connection বন্ধ করে দেবে।

তাই সমাধান হলো client-কে একটি মাত্র key পাঠাতে দেওয়া: সঠিক key-টি।

সার্ভার কী গণনা করে এবং MaxAuthTries কোথায় প্রযোজ্য

Public key authentication শুরু হয় অনুমানভিত্তিক যাচাই দিয়ে। client একটি public key পাঠায় এবং জানতে চায়, server এই key দিয়ে তৈরি signature গ্রহণ করবে কি না। server হ্যাঁ বা না উত্তর দেয়। “না” একটি ব্যর্থ প্রচেষ্টা হিসেবে গণ্য হয়, ভুল password-এর মতোই।

sshd_config(5) manual page-এ এই সীমা বর্ণনা করা হয়েছে: “প্রতি connection-এ অনুমোদিত authentication প্রচেষ্টার সর্বোচ্চ সংখ্যা নির্ধারণ করে। ব্যর্থতার সংখ্যা এই মানের অর্ধেকে পৌঁছালে অতিরিক্ত ব্যর্থতাগুলো log করা হয়। ডিফল্ট মান 6।”

কেউ password টাইপ করলে 6টি প্রচেষ্টা যথেষ্ট। কিন্তু 10টি key থাকা কোনো agent-এর জন্য এটি বেশি নয়। ব্যর্থতার সংখ্যা সীমায় পৌঁছালে sshd connection বিচ্ছিন্ন করে এবং system log-এ এই ধরনের একটি লাইন লেখে:

error: maximum authentication attempts exceeded for deploy from 203.0.113.10 port 51292 ssh2

আপনার client একই ঘটনার অন্য অংশটি দেখায়:

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

এটি SSH permission denied (publickey) error-এর থেকে আলাদা ব্যর্থতা। ওই ক্ষেত্রে server আপনার পাঠানো সবকিছু পরীক্ষা করে কোনোটিই গ্রহণ করেনি। এখানে server পরীক্ষা করা বন্ধ করে দিয়েছে। দুটিকে একই ধরনের ব্যর্থতা মনে করলেই মানুষ সঠিক থাকা key আবার কপি করতে করতে পুরো একটি বিকেল কাটায়।

আপনার সহকর্মীর laptop থেকে একই key কেন কাজ করে

key বা server—কোনোটিরই পার্থক্য নেই। তাঁর agent-এ দুটি key আছে, আর আপনার agent-এ আছে বারোটি। তাঁর ক্ষেত্রে যে key offer প্রথমে পাঠানো হয়, আপনার ক্ষেত্রে সেটি নবমে আসে। ততক্ষণে connection বন্ধ হয়ে যায়।

এই সংখ্যা নীরবে বাড়ে। AddKeysToAgent yes-এর ~/.ssh/config আপনার ব্যবহার করা প্রতিটি key agent-এ যোগ করে এবং সেখানেই রেখে দেয়। Linux-এর GNOME Keyring বা macOS-এর login keychain-এর মতো desktop keyring agent login-এর সময় অনুমতি না নিয়েই key load করে। এক বছরে একটি client key, একটি git host key এবং একটি lab box key যোগ করুন। একদিন এমন server, যা সব সময় কাজ করেছে, আপনাকে প্রত্যাখ্যান করতে শুরু করবে। Server-এ কিছুই পরিবর্তন হয়নি। আপনার agent-এ key বেশি জমেছে।

ssh -v দিয়ে অফারগুলো কীভাবে দেখবেন

-v ব্যবহার করে ব্যর্থ সংযোগটি চালান এবং trace পড়ুন।

ssh -v deploy@203.0.113.10

দুই ধরনের লাইন গুরুত্বপূর্ণ। Will attempt key: ক্লায়েন্ট যে identity-গুলো প্রস্তুত করেছে, সেগুলো যে ক্রমে ব্যবহার করবে সেই ক্রমে তালিকাভুক্ত করে। Offering public key: সার্ভারে বাস্তবে পাঠানো প্রতিটি key-এর জন্য একবার দেখা যায়।

debug1: Will attempt key: /home/you/.ssh/id_ed25519 ED25519 SHA256:AAAA... agent
debug1: Will attempt key: /home/you/.ssh/id_rsa RSA SHA256:BBBB... agent
debug1: Offering public key: /home/you/.ssh/id_ed25519 ED25519 SHA256:AAAA... agent
debug1: Authentications that can continue: publickey,password
debug1: Offering public key: /home/you/.ssh/id_rsa RSA SHA256:BBBB... agent

আপনার path, key type এবং fingerprint আলাদা হবে। আপনি যে বিষয়টি গুনছেন তা হলো সংযোগ বিচ্ছিন্ন হওয়ার আগে কতগুলো Offering public key: line দেখা যায়। অফারগুলো একের পর এক চলে যাওয়ার পরও যদি আপনার নির্ধারিত key কখনো দেখা না যায় এবং session শেষ হয়ে যায়, তাহলে সমস্যার কারণ নিশ্চিত। কোনো লাইনের শেষে agent থাকলে বোঝায়, সেই identity এসেছে ssh-agent থেকে। explicit থাকলে বোঝায়, এটি কোনো IdentityFile line থেকে অথবা কমান্ড লাইনের -i থেকে এসেছে।

এরপর agent-কে জিজ্ঞাসা করুন, এটি কী ধরে রেখেছে:

ssh-add -l

Output-এর প্রতিটি line একটি loaded key নির্দেশ করে। যদি The agent has no identities. মুদ্রিত হয়, তাহলে agent সমস্যার কারণ নয়; পরিবর্তে ~/.ssh/config-এর IdentityFile line-গুলো পরীক্ষা করুন। যদি Could not open a connection to your authentication agent. মুদ্রিত হয়, তাহলে কোনো agent চলছে না এবং অফারগুলো আপনার default key file থেকে আসছে।

Fix 1: প্রতিটি host-এর জন্য একটি key-সহ IdentitiesOnly

IdentitiesOnly yes ssh-কে শুধু আপনার configured identities offer করতে বলে এবং agent স্বেচ্ছায় যে অতিরিক্ত identity-গুলো দেয়, সেগুলো উপেক্ষা করতে বলে। এটি একটি IdentityFile line-এর সঙ্গে ব্যবহার করলে client শুধু একটি offer পাঠায়।

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

এটি ~/.ssh/config-এ সংরক্ষণ করুন, তারপর chmod 600 ~/.ssh/config চালান। group-writable বা world-writable file থাকলে ssh চলতে অস্বীকার করে এবং Bad owner or permissions on /home/you/.ssh/config দেখায়। এখন ssh vps একটি key offer করে, এবং ssh -v vps-এ ঠিক একটি Offering public key: line দেখা উচিত।

এখানে দুটি বিষয় অনেককে অবাক করে।

• শুধু IdentitiesOnly yes থাকলেই "একটি key" বোঝায় না। কোনো IdentityFile line না থাকলে default identity file-গুলো configured identity হিসেবে গণনা হয়। তাই ssh এখনও ~/.ssh/id_ed25519, ~/.ssh/id_rsa এবং পাওয়া অন্য default file-গুলো চেষ্টা করে। আপনাকে IdentityFile line-ও দিতে হবে। এটি একবার সেট হলে ssh default identity যোগ করা বন্ধ করে।
• Signing এখনও agent-ই করে। IdentitiesOnly কোন key offer করা হবে তা নিয়ন্ত্রণ করে, কে signing করবে তা নয়। IdentityFile-এ উল্লেখ করা private key agent-এ loaded থাকলে agent signature তৈরি করে এবং আপনাকে passphrase দিতে বলা হয় না। আপনি IdentityFile-কে matching .pub file-এও নির্দেশ করতে পারেন। Private key শুধু agent বা hardware token-এ থাকলে এটাই ব্যবহার করবেন।

~/.ssh/config-এর একটি ভুল এই fix-কে নীরবে অকার্যকর করে। বেশিরভাগ keyword-এর ক্ষেত্রে প্রথম পাওয়া value কার্যকর হয়। এ কারণেই নির্দিষ্ট Host block-গুলো Host *-এর উপরে রাখা উচিত। IdentityFile এই নিয়ম অনুসরণ করে না। Manual-এ বলা আছে: "Configuration file-এ একাধিক identity file নির্দিষ্ট করা যায়; সব identity ধারাবাহিকভাবে চেষ্টা করা হবে।" Host *-এর অধীনে থাকা একটি IdentityFile আপনার per-host value-র সঙ্গে যোগ হয়, সেটি প্রতিস্থাপন করে না। ফলে ভুলে রাখা একটি global line প্রতিটি connection-এ আবার অতিরিক্ত offer যোগ করে।

আপনি যদি global safety net চান, file-এর শেষে শুধু flag-টি সেট করুন:

Host *
  IdentitiesOnly yes

এরপর প্রতিটি host-এর নিজস্ব IdentityFile প্রয়োজন হবে, যা আপনি যেকোনো ক্ষেত্রেই চান। প্রতিটি server-এর জন্য একটি key-এর নাম নির্দিষ্ট করলেই পরে কোনো একটি machine-এর access প্রত্যাহার করা সম্ভব হয়, সবকিছু নতুন করে issue করতে হয় না। এই অভ্যাস শুরুতেই গড়ে তোলা ভালো: দেখুন প্রতিটি machine-এর জন্য SSH key কীভাবে পরিচালনা করবেন।

সমাধান 2: agent পরিষ্কার করুন বা পুনরায় চালু করুন

আপনি এখনো configuration সম্পাদনা করতে না পারলে agent খালি করুন এবং শুধু প্রয়োজনীয় জিনিস লোড করুন।

ssh-add -l                    # list what is loaded
ssh-add -d ~/.ssh/id_rsa      # remove one key
ssh-add -D                    # remove every key
ssh-add ~/.ssh/id_ed25519_vps # load the one you need

ssh-add -D-এর ঠিক পরে connection কাজ করলে agent-ই কারণ ছিল। এটিকে repair নয়, test হিসেবে বিবেচনা করুন। Desktop keyring agent আপনার পরবর্তী login-এর সময় আবার key লোড করে। তাই সমস্যাটি আগামীকাল আবার দেখা দেবে। ~/.ssh/config-এ থাকা IdentitiesOnly line reboot-এর পরেও থেকে যায়। খালি agent থেকে যায় না।

আপনি key-এর lifetime-ও নির্ধারণ করতে পারেন, যাতে agent নিজেই সেটি সরিয়ে দেয়:

ssh-add -t 1800 ~/.ssh/id_ed25519_vps

Key যোগ করার 1800 seconds পরে সেটি সরিয়ে দেওয়া হবে। Agent পুনরায় চালু করলেও কাজ হয়। তবে কীভাবে চালু করা হয়েছিল, তার ওপর পদ্ধতিটি নির্ভর করে। আপনি নিজে চালু করা ssh-agent, ssh-agent -k দিয়ে বন্ধ হয়। আপনার লেখা systemd user unit থেকে এটি চালালে systemctl --user restart <unit> দিয়ে সেই unit পুনরায় চালু করুন। Keyring agent আপনার desktop session-এর সঙ্গে পুনরায় চালু হয়।

সমাধান 3: একবার ব্যবহার করা সার্ভারের জন্য এককালীন কমান্ড

যে host-টি আপনি configuration-এ যোগ করবেন না, তার জন্য একই settings command line-এ দিন:

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

শুধু -i ব্যবহার করা সবচেয়ে সাধারণ ভুল সমাধান। -i identities-এর তালিকায় একটি key যোগ করে। এটি সেই তালিকা থেকে agent-এর key সরায় না। তাই অন্য সব key আপনার key-এর আগে offer হতে থাকে এবং limit-এ পৌঁছালে connection আবার ব্যর্থ হয়। IdentitiesOnly ছাড়া ssh -v -i ~/.ssh/id_ed25519_vps deploy@203.0.113.10 চালালে agent-এর key আগে offer হতে দেখবেন। -i-এর পাশে -o IdentitiesOnly=yes-ও থাকতে হবে।

একটি connection-এর ক্ষেত্রে agent-কে সম্পূর্ণভাবে বাদ দিতে:

ssh -o IdentityAgent=none -i ~/.ssh/id_ed25519_vps deploy@203.0.113.10

এরপর ssh disk থেকে private key পড়ে এবং key-টির passphrase থাকলে তা জানতে চায়।

ssh-এর ওপর নির্মিত tools-ও একই option গ্রহণ করে:

scp -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_vps report.tar.gz deploy@203.0.113.10:/tmp/
rsync -av -e "ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_vps" ./site/ deploy@203.0.113.10:/srv/site/
GIT_SSH_COMMAND="ssh -o IdentitiesOnly=yes -i ~/.ssh/id_ed25519_vps" git clone git@example.com:team/repo.git

দ্বিতীয় hop-এ error কেন দেখা যায়

ForwardAgent yes ব্যবহার করলে আপনি যে server-এ connect করেন, সেখানে agent socket available হয়। সেই server-এ চালানো ssh command forwarded socket-এর মাধ্যমে আপনার local agent ব্যবহার করে এবং আপনার সব key-তে access পায়। তাই jump host থেকে final server-এ যাওয়ার hop-এ error দেখা দিতে পারে, যদিও প্রথম hop ঠিকমতো কাজ করেছে। মাঝের machine-এ echo $SSH_AUTH_SOCK চালান: output খালি হলে সেখানে কোনো agent reachable নেই। একটি socket path দেখালে কোনো agent আছে, তবে সেটি আপনার agent নাও হতে পারে, কারণ ওই machine-এ চালু করা agent একই variable সেট করে। সেখানেই ssh-add -l চালান: আপনার নিজের machine-এর key তালিকাভুক্ত হলে forwarding active।

Agent forwarding-এর আরেকটি security risk আছে। ওই middle machine-এ root access থাকা যে কেউ আপনার session open থাকা পর্যন্ত আপনার agent ব্যবহার করে আপনার পরিচয়ে authenticate করতে পারে। ProxyJump উভয় সমস্যা এড়ায়:

ssh -J deploy@jump.example.com deploy@10.0.0.5

ProxyJump jump host-এর মাধ্যমে connection তৈরি করে এবং আপনার নিজের machine থেকে final server-এ authenticate করে। তাই প্রতিটি hop-এ আপনার local ~/.ssh/config কার্যকর থাকে, IdentitiesOnly-সহ। ForwardAgent বন্ধ করা একটি VPS-এ SSH hardening করার standard ধাপ।

সার্ভারে MaxAuthTries বাড়ানো উচিত কি?

সাধারণত নয়। আগে বর্তমান মান পরীক্ষা করুন:

sudo sshd -T | grep -i maxauthtries

sshd -T default-সহ কার্যকর configuration দেখায়। তাই sshd_config-এ কোনো তথ্য না থাকলেও এটি প্রকৃত মান দেখায়। আপনি যদি Match block ব্যবহার করেন, তাহলে -C user=deploy,host=example.com,addr=203.0.113.10 যোগ করুন। কারণ এগুলো প্রতিটি connection অনুযায়ী মূল্যায়ন করা হয় এবং তা না হলে বাদ পড়ে।

সীমা বাড়ালে সংকীর্ণ অর্থে কাজ হয়। বড় মান দিলে সমস্যাযুক্ত client-এর জন্য আরও বেশি authentication চেষ্টা করার সুযোগ থাকে:

MaxAuthTries 20

ফাইলটি validate করে service reload করুন। এই কাজের সময় একটি দ্বিতীয় session খোলা রাখুন:

sudo sshd -t
sudo systemctl reload ssh      # Debian and Ubuntu
sudo systemctl reload sshd     # RHEL family

Ubuntu 24.04-এ systemctl is-enabled ssh.socket যদি enabled দেখায়, তাহলে sshd socket activated। Ubuntu-এর ssh.socket প্রতিটি connection-এর জন্য নতুন daemon চালু করে না। প্রথম connection এলে এটি ssh.service চালু করে। সেই service চলতে থাকে এবং পরবর্তী connection-গুলো পরিচালনা করে। পরিবর্তন কার্যকর করার জন্য উপরের reload-ই যথেষ্ট। ssh.service এখনও active না থাকলে reload করার মতো কিছু নেই। পরবর্তী connection নতুন file-সহ এটি চালু করবে।

এখন দেখুন পরিবর্তনটি কী করেছে। client এমন key পাঠাচ্ছে, যা এই server কখনো গ্রহণ করবে না। সীমা বাড়ালে server প্রতিটি connection-এ ছয়টির পরিবর্তে বিশটি প্রত্যাখ্যাত key offer পরীক্ষা করবে। এটি প্রতিটি client-এর জন্য প্রযোজ্য। Internet-এর প্রতিটি password guesser-এর ক্ষেত্রেও একইভাবে প্রযোজ্য। প্রতিটি offer-এর জন্য server-কে authorized_keys-এ lookup করতে হয়। আপনার নিজের login ধীরই থাকবে, কারণ সঠিক key-টি এখনও তালিকার শেষে আছে। আপনার agent-এ ত্রয়োদশ key যোগ করলে আবার আগের অবস্থায় ফিরে যাবেন এবং আরও বড় মান চাইবেন।

শুধু তখনই সীমা বাড়ান, যখন কোনো বৈধ client-এর সত্যিই একাধিক identity উপস্থাপন করা প্রয়োজন। অন্য সব ক্ষেত্রে client-এর configuration ঠিক করুন। প্রতিটি user configured key দিয়ে login করতে পারলে সীমা কমানো যুক্তিসঙ্গত hardening ব্যবস্থা। এতে প্রতি connection-এ কোনো guesser-এর জন্য চেষ্টা করার সুযোগ কমে।

fail2ban কীভাবে আপনাকে এর জন্য ban করতে পারে

sshd প্রতিটি প্রত্যাখ্যাত key-এর জন্য log লেখে না। ডিফল্ট LogLevel INFO-এ, কোনো প্রকৃত account-এর প্রত্যাখ্যাত key তখনই log-এ লেখা হয়, যখন connection-এর failure count, MaxAuthTries-এর অর্ধেকে পৌঁছায়। Manual-এ “Once the number of failures reaches half this value, additional failures are logged.” কথাটির অর্থ এটাই। ডিফল্ট মান 6 হলে, প্রথম তিনটি প্রত্যাখ্যাত offer log-এ লেখা হয় না। পরের তিনটি এ ধরনের line হিসেবে দেখা যায়, যার পরে maximum authentication attempts exceeded line থাকে:

Failed publickey for deploy from 203.0.113.10 port 51292 ssh2: ED25519 SHA256:AAAA...

এই line-গুলো দেখতে একগুচ্ছ failure-এর মতো হলেও fail2ban-এর sshd filter এগুলো গোনে না। সরবরাহ করা ডিফল্ট publickey = nofail valid user-এর জন্য একটি Failed publickey line পড়ে শুধু address এবং user name সংগ্রহ করে। যে line-টি গণনা করা হয়, সেটি হলো maximum authentication attempts exceeded। তাই limit-এ পৌঁছানো একটি connection একটিই failure যোগ করে, একাধিক নয়। findtime সময়সীমার মধ্যে maxretry failure হলে jail source address ban করে। fail2ban-এর নিজস্ব jail.conf এই মানগুলো 5 এবং 10 মিনিট নির্ধারণ করে। দশ মিনিটে প্রায় পাঁচটি ব্যর্থ connection হলেই আপনার নিজের address ban হওয়ার জন্য যথেষ্ট। কোনো script বা tool loop-এ retry করলে দ্রুতই এই অবস্থায় পৌঁছায়।

এরপর লক্ষণটি বদলে যায়। এখানেই অনেকে বিভ্রান্ত হন। আপনি “Too many authentication failures” আর দেখতে পান না; বরং কিছুই দেখা যায় না। Connection hang করে এবং শেষে timeout হয়, কারণ firewall এখন আপনার packet-এর উত্তর না দিয়ে সেগুলো drop করছে। আগে যেখানে error message পেতেন, সেখানে timeout পাওয়াই সংকেত। এই পার্থক্যটি SSH connection refused বনাম connection timed out-এ ব্যাখ্যা করা হয়েছে।

আপনার provider-এর console থেকে, অথবা অন্য কোনো address ব্যবহার করে, jail পরীক্ষা করুন এবং ban তুলে দিন:

sudo fail2ban-client status sshd
sudo fail2ban-client set sshd unbanip 203.0.113.10

Client ঠিক করার সময় jail.local-এর মধ্যে ignoreip-এ আপনার নিজের address রাখুন। কাজ শেষ হলে সেটি আবার সরিয়ে নিন। Jail-টি Ubuntu 24.04-এর fail2ban guide-এ সেট আপ করা হয়েছে।

একবার কী করবেন, যাতে এই সমস্যা বারবার না আসে

প্রতিটি server-এর জন্য ~/.ssh/config-এ আলাদা Host block তৈরি করুন, সঙ্গে HostName, User, IdentityFile এবং IdentitiesOnly yes রাখুন। এরপর ssh vps টাইপ করা সংক্ষিপ্ত হবে, এটি ঠিক একটি key দেয়, এবং আপনার agent যতই বড় হোক, এটি MaxAuthTries সক্রিয় করতে পারবে না। একই সঙ্গে অন্য কোনো সমস্যা দেখা দিলে সেদিন পড়ার মতো সংক্ষিপ্ত ssh -v output-ও এটি বজায় রাখে।

FAQ

“Too many authentication failures” এখনই কীভাবে ঠিক করব?

সবগুলো key না দিয়ে একটি key ব্যবহার করুন। তাৎক্ষণিক সংযোগের জন্য ssh -o IdentitiesOnly=yes -i ~/.ssh/your_key user@host চালান। স্থায়ী সমাধানের জন্য ~/.ssh/config-এ একটি block যোগ করুন, যেখানে HostName, User, IdentityFile ওই key-টির দিকে নির্দেশ করবে এবং IdentitiesOnly yes থাকবে; এরপর chmod 600 ~/.ssh/config চালান। ssh -v দিয়ে নিশ্চিত করুন: ওই host-এর জন্য একটি Offering public key: line দেখতে পাবেন।

ssh -i ব্যবহার করলেও অন্য key-গুলো কেন offer হচ্ছে?

কারণ -i একটি identity তালিকায় যোগ করে, তালিকাটি সীমাবদ্ধ করে না। ssh-agent-এ loaded key-গুলো তালিকায় থেকেই যায় এবং এখনও offer হয়। এগুলো প্রায়ই আপনার key-এর আগে offer হয়। ফলে আপনার key-তে পৌঁছানোর আগেই server MaxAuthTries-এ পৌঁছে যেতে পারে। ssh-কে শুধু আপনার নির্দিষ্ট identity-গুলোতে সীমাবদ্ধ করার option হলো -o IdentitiesOnly=yes। -i এবং -o IdentitiesOnly=yes একসঙ্গে ব্যবহার করুন, অথবা ওই একটি connection-এর জন্য agent সম্পূর্ণ উপেক্ষা করতে -o IdentityAgent=none ব্যবহার করুন।

এটি ঠিক করতে server-এ MaxAuthTries বাড়ানো উচিত কি?

না, প্রায় সব ক্ষেত্রেই নয়। client এমন key পাঠাচ্ছে যেগুলো server কখনও গ্রহণ করবে না। limit বাড়ালে server প্রতিটি connection-এর জন্য আরও বেশি প্রত্যাখ্যাত offer পরীক্ষা করবে। server-এ পৌঁছানো প্রতিটি client এবং brute force attempt-এর ক্ষেত্রেও একই ঘটনা ঘটবে। আপনার agent-এ আরও একটি key যুক্ত হলেই সমস্যাটি আবার দেখা দেবে। কৌতূহল থাকলে sudo sshd -T | grep -i maxauthtries দিয়ে কার্যকর value দেখুন। এরপর IdentitiesOnly দিয়ে client ঠিক করুন।

গত মাসে ঠিকভাবে কাজ করা server-এ এটি এখন শুরু হলো কেন?

আপনার agent-এ key-এর সংখ্যা বেড়েছে। AddKeysToAgent yes-এর ~/.ssh/config প্রতিটি ব্যবহৃত key loaded রাখে। Desktop keyring agent-গুলোও login-এর সময় নিজে থেকেই key load করে। Loaded key-এর সংখ্যা server-এর MaxAuthTries অতিক্রম করলে offer order-এ পরে থাকা key-যুক্ত যেকোনো server-এ ব্যর্থতা শুরু হয়। ssh-add -l চালান এবং server-এর limit-এর সঙ্গে count তুলনা করুন।

এর ফলে fail2ban কি আমার IP address ban করতে পারে?

হ্যাঁ, তবে server log-এর ইঙ্গিতের তুলনায় ধীরে। Default fail2ban sshd filter কোনো valid user-এর Failed publickey line গণনা করে না। এটি maximum authentication attempts exceeded line গণনা করে। তাই limit-এ পৌঁছানো প্রতিটি connection একটি failure হিসেবে গণ্য হয়। Shipped default maxretry = 5 এবং findtime = 10m থাকলে দশ মিনিটে প্রায় পাঁচটি এমন connection আপনার address ban করে। এর লক্ষণ হলো error বদলে hang এবং পরে timeout হয়। কারণ packet-এর উত্তর না দিয়ে সেগুলো drop করা হচ্ছে। sudo fail2ban-client set sshd unbanip <your address> দিয়ে console থেকে ban সরান এবং পুনরায় সংযোগের আগে client ঠিক করুন।