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 করা হয়। Default হলো 6।”

Password টাইপ করা একজন মানুষের জন্য ছয়টি প্রচেষ্টা যথেষ্ট। কিন্তু দশটি key থাকা কোনো agent-এর জন্য এটি বেশি নয়। ব্যর্থতার সংখ্যা সীমা অতিক্রম করলে sshd connection বিচ্ছিন্ন করে এবং system log-এ এ ধরনের একটি line লেখে:

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 আবার copy করতে গিয়ে অযথা অনেক সময় নষ্ট হয়।

আপনার সহকর্মীর 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 থেকে আসছে।

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

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

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

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

Host *
  IdentitiesOnly yes

এরপর প্রতিটি host-এর নিজস্ব IdentityFile থাকা দরকার। আপনি যেটি চান, ফলাফল সেটিই। প্রতি server-এর জন্য একটি নির্দিষ্ট key-এর নাম ব্যবহার করলে পরে কোনো একটি machine-এর access বাতিল করা যায়, সবকিছুর জন্য নতুন key তৈরি করতে হয় না। এই অভ্যাসটি শুরুতেই গড়ে তোলা ভালো: দেখুন প্রতি 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 উপলভ্য করা হয়। ওই server-এ চালানো ssh command forwarded socket-এর মাধ্যমে আপনার local agent ব্যবহার করে এবং আপনার সব key পায়। তাই jump host থেকে final server-এ যাওয়ার hop-এ error দেখা দিতে পারে, যদিও প্রথম hop সফল হয়েছিল। মধ্যবর্তী machine-এ echo $SSH_AUTH_SOCK চালান: socket path দেখা গেলে বোঝা যায় forwarded agent reachable, আর output খালি হলে সেখানে কোনো forwarded agent নেই।

Agent forwarding-এর আরেকটি security ঝুঁকি আছে। ওই মধ্যবর্তী machine-এ root access থাকা যে কেউ আপনার session চালু থাকা পর্যন্ত আপনাকে পরিচয় হিসেবে ব্যবহার করে authenticate করতে পারে। ProxyJump উভয় সমস্যাই এড়ায়:

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

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

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

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

sudo sshd -T | grep -i maxauthtries

sshd -T কার্যকর configuration এবং default-সহ মান দেখায়। তাই 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 অবস্থায় চলছে। প্রতিটি connection-এর জন্য নতুন process চালু হয় এবং আবার sshd_config পড়ে। তাই নতুন connection-গুলো নিজে থেকেই পরিবর্তিত configuration ব্যবহার করবে।

এবার পরিবর্তনটির ফল দেখুন। Client এমন key পাঠাচ্ছে, যা এই server কখনো গ্রহণ করবে না। সীমা বাড়ালে server প্রতিটি connection-এ ছয়টির বদলে বিশটি প্রত্যাখ্যাত 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 করতে পারে

ডিফল্ট log level-এ sshd প্রতিটি প্রত্যাখ্যাত public key রেকর্ড করে:

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

একটি পূর্ণ agent থেকে তৈরি একটি connection এক বা দুই সেকেন্ডের মধ্যে একই address থেকে এই ধরনের একাধিক line তৈরি করে। fail2ban-এর sshd jail sshd-এর failure line গুনে এবং findtime-এর মধ্যে maxretry-এ পৌঁছালে source address ban করে। এই window-গুলো ডিফল্টভাবে ছোট থাকে। তাই ভাঙা connection-এ দুইবার retry করাই আপনার নিজের address ban করার জন্য যথেষ্ট হতে পারে।

এরপর symptom পরিবর্তিত হয়। এখানেই সাধারণত বিভ্রান্তি তৈরি হয়। আপনি আর "Too many authentication failures" দেখতে পান না। তার বদলে কিছুই দেখা যায় না। Connection hang করে এবং শেষে timeout হয়, কারণ firewall এখন আপনার packet-এর উত্তর না দিয়ে সেগুলো drop করছে। আগে যেখানে error message পেতেন, সেখানে timeout পাওয়াই এখানে গুরুত্বপূর্ণ signal। এই পার্থক্য 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-এ আপনার নিজের address ignoreip-এ বসিয়ে রাখুন। কাজ শেষ হলে সেটি আবার সরিয়ে দিন। 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-টির path উল্লেখ করুন, এবং IdentitiesOnly yes যোগ করুন। এরপর chmod 600 ~/.ssh/config চালান। ssh -v দিয়ে বিষয়টি নিশ্চিত করুন। ওই host-এর জন্য একটি Offering public key: line দেখা উচিত।

ssh -i ব্যবহার করলেও কেন অন্য key-গুলো পাঠানো হয়?

কারণ -i একটি identity তালিকায় যোগ করে, তালিকাটি সীমাবদ্ধ করে না। ssh-agent-এ loaded key-গুলো তালিকায় থেকেই যায় এবং সেগুলোও পাঠানো হয়। অনেক সময় আপনার key-এর আগেই সেগুলো পাঠানো হয়। ফলে আপনার 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 প্রচেষ্টার ক্ষেত্রেও একই ঘটনা ঘটবে। আপনার agent-এ আরও একটি key যুক্ত হলেই সমস্যাটি আবার দেখা দেবে। কার্যকর value জানতে sudo sshd -T | grep -i maxauthtries পরীক্ষা করতে পারেন। তবে client-এ IdentitiesOnly ব্যবহার করেই সমস্যাটি ঠিক করুন।

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

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

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

হ্যাঁ। প্রতিটি প্রত্যাখ্যাত key server log-এ একটি Failed publickey for ... line তৈরি করে। তাই কয়েক সেকেন্ডের মধ্যে একটি connection আপনার address থেকে একাধিক failure তৈরি করতে পারে। fail2ban-এর sshd jail-এ findtime সময়ের মধ্যে maxretry পৌঁছালে address-টি ban হয়ে যায়। এর লক্ষণ হলো error প্রথমে hang এবং পরে timeout-এ পরিবর্তিত হয়। কারণ packet-এর উত্তর না দিয়ে সেগুলো drop করা হচ্ছে। sudo fail2ban-client set sshd unbanip <your address> দিয়ে console থেকে ban সরান। Reconnect করার আগে client-এর সমস্যা ঠিক করুন।