SSH Too Many Authentication Failures Hatası Çözümü

"Too many authentication failures" hatasının anlamı

"Too many authentication failures" hatası, SSH istemcinizin sunucuya, sunucunun kontrol etmeye istekli olduğundan daha fazla anahtar sunduğu ve sunucunun doğru anahtarınız denenmeden önce bağlantıyı kapattığı anlamına gelir. Bu durum neredeyse her zaman bir istemci sorunudur. Anahtar diskinizde bulunur, sunucu ise anahtarı authorized_keys içinde tutar; ancak bağlantı çok erken sonlandığı için bu gerçeklerin bir faydası olmaz.

Süreç şu şekilde işler: ssh-agent, içine yüklediğiniz tüm özel anahtarları tutar. İstemciniz, hesabın hangisini kabul ettiğini bilmediği için bu anahtarları sunucuya tek tek sunar. Sunucu, authorized_keys içinde bulunmayan her anahtarı reddeder ve her reddetme işlemini başarısız bir kimlik doğrulama girişimi olarak sayar. sshd_config içindeki MaxAuthTries, tek bir bağlantının kaç başarısızlığa izin verileceğini sınırlar. Varsayılan değer 6'dır. Eğer agent'ınızda on anahtar varsa ve doğru olan sekizinci sıradaysa, sunucu o anahtara ulaşılmadan bağlantıyı keser.

Bu nedenle çözüm, istemcinin yalnızca bir anahtar sunmasını sağlamaktır: o da doğru olan anahtardır.

Sunucunun neleri saydığı ve MaxAuthTries parametresinin işlevi

Açık anahtar kimlik doğrulaması, bir tahmin oyunu olarak başlar. İstemci bir açık anahtar gönderir ve sunucunun bu anahtarla oluşturulmuş bir imzayı kabul edip etmeyeceğini sorar. Sunucu ise evet veya hayır yanıtını verir. "Hayır" yanıtı, tıpkı yanlış bir parola gibi başarısız bir deneme sayılır.

sshd_config(5) kılavuz sayfası bu sınırı şu şekilde tanımlar: "Bağlantı başına izin verilen maksimum kimlik doğrulama denemesi sayısını belirtir. Başarısızlık sayısı bu değerin yarısına ulaştığında, ek başarısızlıklar günlüğe kaydedilir. Varsayılan değer 6'dır."

Altı deneme, parola yazan bir insan için yeterlidir. Ancak on anahtar tutan bir SSH ajanı için bu sayı oldukça düşüktür. Başarısızlık sayısı sınırı aştığında, sshd bağlantıyı keser ve sistem günlüğüne şu satırı yazar:

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

İstemciniz ise aynı olayın diğer yarısını şu şekilde görüntüler:

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

Bu durum, SSH permission denied (publickey) hatasından farklı bir başarısızlık türüdür. Orada sunucu sunduğunuz her şeyi incelemiş ve hiçbirini kabul etmemiştir. Burada ise sunucu incelemeyi durdurmuştur. İki durumu birbiriyle karıştırmak, insanların zaten doğru olan bir anahtarı tekrar kopyalamakla bir öğleden sonralarını harcamalarına neden olur.

Aynı anahtarın iş arkadaşınızın dizüstü bilgisayarında neden çalıştığı

Anahtar veya sunucu tarafında hiçbir fark yoktur. İş arkadaşınızın aracısı iki anahtar tutarken, sizinki on iki anahtar tutmaktadır. Onlar için ilk sırada gelen teklif, sizin için dokuzuncu sırada gelir ve o zamana kadar bağlantı sona ermiş olur.

Sayı sessizce artar. AddKeysToAgent yes içindeki ~/.ssh/config, kullandığınız her anahtarı aracıya ekler ve orada bırakır. Linux üzerinde GNOME Keyring veya macOS üzerinde login keychain gibi masaüstü anahtarlık aracıları, anahtarları oturum açma sırasında sormadan yükler. Bir yıl boyunca bir istemci anahtarı, bir git sunucusu anahtarı ve bir laboratuvar cihazı anahtarı eklediğinizde, bir gün her zaman çalışan bir sunucu sizi reddetmeye başlar. Sunucuda hiçbir şey değişmemiştir. Aracınız dolmuştur.

ssh -v ile teklifleri görme

Başarısız olan bağlantıyı -v ile çalıştırın ve izleme çıktısını okuyun.

ssh -v deploy@203.0.113.10

İki tür satır önemlidir. Will attempt key:, istemcinin bir araya getirdiği kimlikleri, kullanacağı sırayla listeler. Offering public key:, sunucuya gönderilen her anahtar için bir kez görünür.

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

Yollarınız, anahtar türleriniz ve parmak izleriniz farklı olacaktır. Bağlantı kesilmeden önce saymanız gereken şey Offering public key: satırlarının sayısıdır. Teklifler akıp gidiyor ve oturum, hedeflediğiniz anahtar hiç görünmeden sona eriyorsa, teşhis konulmuş demektir. Satırın sonundaki agent ifadesi, o kimliğin ssh-agent kaynağından geldiği anlamına gelir. explicit ifadesi ise kimliğin bir IdentityFile satırından veya komut satırındaki -i parametresinden geldiğini belirtir.

Ardından, aracıya (agent) hangi anahtarları tuttuğunu sorun:

ssh-add -l

Çıktıdaki her satır, yüklenmiş bir anahtarı temsil eder. Eğer The agent has no identities. çıktısını alıyorsanız, sorun aracıda değildir; bu durumda ~/.ssh/config içindeki IdentityFile satırlarını incelemelisiniz. Eğer Could not open a connection to your authentication agent. çıktısını alıyorsanız, hiçbir aracı çalışmıyordur ve teklifler varsayılan anahtar dosyalarınızdan geliyordur.

Çözüm 1: Her ana bilgisayar için tek anahtar ile IdentitiesOnly

IdentitiesOnly yes, ssh'e yalnızca yapılandırdığınız kimlikleri sunmasını ve aracın (agent) kendiliğinden sunduğu fazladan kimlikleri yok saymasını söyler. Bunu bir IdentityFile satırı ile eşleştirdiğinizde, istemci tek bir teklif gönderir.

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

Bunu ~/.ssh/config içine kaydedin ve ardından chmod 600 ~/.ssh/config komutunu çalıştırın. Grup tarafından yazılabilir veya herkes tarafından yazılabilir bir dosya, ssh'in Bad owner or permissions on /home/you/.ssh/config hatası vererek çalışmayı reddetmesine neden olur. Artık ssh vps tek bir anahtar sunar ve ssh -v vps tam olarak bir Offering public key: satırı göstermelidir.

Burada iki detay kullanıcıları şaşırtır.

• IdentitiesOnly yes tek başına "tek anahtar" anlamına gelmez. Varsayılan kimlik dosyaları yapılandırılmış kimlikler olarak sayılır, bu nedenle ssh hala ~/.ssh/id_ed25519, ~/.ssh/id_rsa ve bulduğu diğer varsayılanları denemeye devam eder. Ayrıca IdentityFile satırına da ihtiyacınız vardır.
• İmzalama işlemini hala aracı yapar. IdentitiesOnly hangi anahtarların sunulacağını kontrol eder, kimin imzalayacağını değil. Eğer IdentityFile tarafından belirtilen özel anahtar (private key) araçta yüklüyse, aracı imzayı oluşturur ve size hiçbir zaman parola sorulmaz. Hatta IdentityFile değerini eşleşen .pub dosyasına yönlendirebilirsiniz; özel anahtar yalnızca araçta veya bir donanım belirtecinde (hardware token) bulunduğunda yapmanız gereken budur.

~/.ssh/config içindeki bir tuzak, bu düzeltmeyi sessizce geçersiz kılar. Çoğu anahtar kelime bulunan ilk değeri alır, bu yüzden belirli Host blokları Host * satırının üzerinde yer almalıdır. IdentityFile bu kurala uymaz. Kılavuz şunu belirtir: "Yapılandırma dosyalarında birden fazla kimlik dosyası belirtmek mümkündür; tüm bu kimlikler sırayla denenecektir." Host * altındaki bir IdentityFile, ana bilgisayara özel olanın yerine geçmez, ona eklenir; bu nedenle unutulmuş bir genel satır, her bağlantıya fazladan bir teklif ekler.

Genel bir güvenlik ağı istiyorsanız, bayrağı yalnızca dosyanın en altına ekleyin:

Host *
  IdentitiesOnly yes

Bu durumda her ana bilgisayarın kendi IdentityFile değerine ihtiyacı olur ki bu zaten ulaşmak istediğiniz sonuçtur. Her sunucu için bir anahtar belirlemek, daha sonra her şeyi yeniden oluşturmadan tek bir makinenin erişimini iptal etmeyi mümkün kılar ve bu alışkanlığı erkenden edinmek faydalıdır: bkz. makine bazında SSH anahtarları nasıl yönetilir.

Çözüm 2: ajanı temizleyin veya yeniden başlatın

Yapılandırmayı henüz düzenleyemiyorsanız, ajanı boşaltın ve yalnızca ihtiyacınız olanları yükleyin.

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

Bağlantı ssh-add -D komutundan hemen sonra çalışıyorsa, sorun ajandan kaynaklanıyordu. Bunu bir onarım değil, bir test olarak değerlendirin. Masaüstü anahtarlık ajanı (keyring agent), anahtarlarını bir sonraki oturum açışınızda yeniden yükler, bu nedenle sorun yarın tekrar ortaya çıkar. ~/.ssh/config içindeki bir IdentitiesOnly satırı yeniden başlatma sonrasında da kalıcıdır. Boş bir ajan ise kalıcı değildir.

Ayrıca bir anahtara yaşam süresi atayarak ajanın onu sizin yerinize temizlemesini sağlayabilirsiniz:

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

Anahtar, eklendikten 1800 saniye sonra silinir. Ajanı yeniden başlatmak da işe yarar; bunu nasıl yapacağınız, ajanı neyin başlattığına bağlıdır. Kendi başlattığınız bir ssh-agent, ssh-agent -k ile durdurulur. Eğer ajanı kendi yazdığınız bir systemd kullanıcı birimi üzerinden çalıştırıyorsanız, o birimi systemctl --user restart <unit> ile yeniden başlatın. Bir anahtarlık ajanı, masaüstü oturumunuzla birlikte yeniden başlar.

Çözüm 3: Tek seferlik erişim sağlayacağınız sunucular için komut satırı kullanımı

Yapılandırma dosyanıza eklemeyeceğiniz bir sunucu için aynı ayarları komut satırı üzerinden uygulayın:

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

-i komutunu tek başına kullanmak, en sık yapılan hatalı düzeltmedir. -i, kimlik listesine yalnızca bir anahtar ekler. Agent üzerindeki mevcut anahtarları listeden kaldırmaz; bu nedenle diğer tüm anahtarlar sizinkinden önce sunulmaya devam eder ve bağlantı limit nedeniyle sonlanır. ssh -v -i ~/.ssh/id_ed25519_vps deploy@203.0.113.10 komutunu IdentitiesOnly olmadan çalıştırırsanız, agent anahtarlarının ilk sırada sunulduğunu görebilirsiniz. -i kullanımı, yanında -o IdentitiesOnly=yes parametresini gerektirir.

Agent'ı tek bir bağlantı için tamamen devre dışı bırakmak isterseniz:

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

Bu durumda ssh, özel anahtarı diskten okur ve varsa parolasını sorar.

ssh tabanlı araçlar da aynı seçeneği kabul eder:

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

Hata neden ikinci atlamada ortaya çıkıyor

ForwardAgent yes ile, bağlandığınız sunucuda bir aracı soketi (agent socket) erişilebilir hale getirilir. O sunucuda çalıştırılan bir ssh komutu, tüm anahtarlarınızla birlikte iletilen soket üzerinden yerel aracınızı kullanır. Hatanın, ilk atlama sorunsuz çalışırken atlama sunucusundan (jump host) hedef sunucuya geçişte ortaya çıkmasının nedeni budur. Orta makinede echo $SSH_AUTH_SOCK komutunu çalıştırın: bir soket yolu, iletilen bir aracın erişilebilir olduğu anlamına gelir; boş çıktı ise hiçbir aracın olmadığını gösterir.

Aracı iletiminin (agent forwarding) ikinci bir maliyeti daha vardır. Orta makinede root yetkisine sahip herhangi biri, oturumunuz açık kaldığı sürece sizin adınıza kimlik doğrulaması yapmak için aracınızı kullanabilir. ProxyJump her iki sorunu da önler:

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

ProxyJump, atlama sunucusu üzerinden bir bağlantı açar ve kendi makinenizden hedef sunucuya kimlik doğrulaması yapar; böylece yerel ~/.ssh/config ayarlarınız, IdentitiesOnly dahil olmak üzere her atlamada geçerli olur. ForwardAgent özelliğini kapatmak, SSH güvenliğini sıkılaştırma sürecinde standart bir adımdır.

Sunucuda MaxAuthTries değerini artırmalı mısınız?

Genellikle hayır. Öncelikle mevcut değeri kontrol edin:

sudo sshd -T | grep -i maxauthtries

sshd -T, varsayılanlar dahil olmak üzere geçerli yapılandırmayı yazdırır; bu nedenle sshd_config dosyasında hiçbir şey belirtilmemiş olsa bile gerçek değeri raporlar. Eğer Match blokları kullanıyorsanız -C user=deploy,host=example.com,addr=203.0.113.10 ekleyin, çünkü bu bloklar bağlantı başına değerlendirilir ve aksi takdirde atlanır.

Limiti artırmak, hatalı davranan bir istemciye daha fazla alan tanıması anlamında dar bir çerçevede işe yarar:

MaxAuthTries 20

Dosyayı doğrulayın, servisi yeniden yükleyin ve bunu yaparken ikinci bir oturumu açık tutun:

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

Eğer systemctl is-enabled ssh.socket, Ubuntu 24.04 üzerinde enabled rapor ediyorsa, sshd soket ile etkinleştirilmiştir: her bağlantı için yeni bir süreç başlar ve sshd_config dosyasını tekrar okur, bu nedenle yeni bağlantılar değişikliği kendiliğinden algılar.

Şimdi bu değişikliğin ne yaptığına bakın. İstemci, bu sunucunun asla kabul etmeyeceği anahtarlar sunuyor. Tavanı yükseltmek, sunucuya her bağlantı için ve internetteki her parola tahmincisi için altı yerine yirmi reddedilen teklifi işleme talimatı verir. Her teklif, sunucuya authorized_keys içinde bir arama maliyeti getirir. Doğru anahtar hala sırada en sonda olduğu için kendi girişiniz yavaş kalmaya devam eder. Ajanınıza on üçüncü bir anahtar eklediğinizde başladığınız noktaya geri dönersiniz ve tekrar daha büyük bir sayı istersiniz.

Sadece meşru bir istemcinin gerçekten birden fazla kimlik sunması gerektiğinde bu değeri artırın. Diğer tüm durumlarda istemciyi düzeltin. Her kullanıcı yapılandırılmış bir anahtarla giriş yaptığında değeri düşürmek makul bir sıkılaştırma yöntemidir, çünkü daha küçük bir sayı tahminciye bağlantı başına daha az deneme hakkı verir.

fail2ban neden sizi bu durum için engelleyebilir

Varsayılan günlük kaydı seviyesinde sshd, reddedilen her public key bilgisini kaydeder:

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

Dolu bir agent üzerinden gelen tek bir bağlantı, bir veya iki saniye içinde aynı adresten bu satırlardan birkaçını üretir. fail2ban sshd jail yapısı, sshd hata satırlarını sayar ve findtime süresi içinde maxretry değerine ulaşıldığında kaynak adresi engeller. Bu pencereler varsayılan olarak küçük tutulduğu için, hatalı bir bağlantının iki kez denenmesi kendi adresinizin engellenmesi için yeterli olabilir.

Bu noktada belirtiler değişir ve insanların kafasını karıştıran kısım da budur. "Too many authentication failures" mesajını görmeyi bırakırsınız ve hiçbir şey görmemeye başlarsınız: güvenlik duvarı artık paketlerinize yanıt vermek yerine onları düşürdüğü için bağlantı askıda kalır ve sonunda zaman aşımına uğrar. Eskiden hata mesajı aldığınız bir durumda zaman aşımı yaşanması bir işarettir; bu ayrım SSH bağlantısının reddedilmesi ile zaman aşımına uğraması bölümünde ele alınmıştır.

Sağlayıcınızın konsolundan veya farklı bir adresten jail durumunu kontrol edin ve engeli kaldırın:

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

İstemci tarafındaki sorunu çözene kadar kendi adresinizi jail.local içindeki ignoreip kısmına ekleyin, işiniz bittiğinde ise tekrar çıkarın. Jail yapısının kendisi Ubuntu 24.04 için fail2ban rehberi içerisinde yapılandırılmıştır.

Bu durumun tekrarlanmaması için yapılması gerekenler

Her sunucuya ~/.ssh/config içerisinde kendi Host bloğunu atayın; bu blokta HostName, User, IdentityFile ve IdentitiesOnly yes tanımlayın. Bu işlemden sonra ssh vps komutunu yazmak kısa sürer, tam olarak tek bir anahtar sunar ve aracı (agent) ne kadar dolu olursa olsun MaxAuthTries hatasına yol açmaz. Ayrıca, başka bir sorun yaşandığında ssh -v çıktısının okunabilir düzeyde kısa kalmasını sağlar.

FAQ

"Too many authentication failures" hatasını hemen nasıl düzeltebilirim?

Tüm anahtarlar yerine tek bir anahtar sunun. Anlık bir bağlantı için ssh -o IdentitiesOnly=yes -i ~/.ssh/your_key user@host komutunu çalıştırın. Kalıcı bir çözüm için ~/.ssh/config dosyasına, ilgili anahtarı işaret eden HostName, User, IdentityFile parametrelerini içeren bir blok ekleyin ve IdentitiesOnly yes ile chmod 600 ~/.ssh/config ayarlarını yapın. ssh -v ile doğrulamayı yapın: ilgili sunucu için tek bir Offering public key: satırı görmelisiniz.

Neden ssh -i hala diğer anahtarlarımı sunuyor?

Çünkü -i listeye bir kimlik ekler, mevcut listeyi kısıtlamaz. ssh-agent içinde yüklü olan anahtarlar listede kalmaya devam eder ve genellikle sizinkinden önce sunulur; bu nedenle sunucu, sizin anahtarınıza ulaşmadan önce MaxAuthTries sınırına takılabilir. -o IdentitiesOnly=yes, ssh bağlantısını belirttiğiniz kimliklerle sınırlayan seçenektir. -i ve -o IdentitiesOnly=yes parametrelerini birlikte kullanın veya o bağlantı için aracı tamamen devre dışı bırakmak adına -o IdentityAgent=none seçeneğini tercih edin.

Bunu düzeltmek için sunucudaki MaxAuthTries değerini artırmalı mıyım?

Hayır, neredeyse hiçbir durumda artırmamalısınız. İstemci, sunucunun asla kabul etmeyeceği anahtarlar gönderiyordur; limiti artırmak, sunucunun her bağlantı için daha fazla reddedilen teklifi değerlendirmesine neden olur. Bu durum, her istemci ve sunucuya ulaşan her kaba kuvvet (brute force) denemesi için geçerlidir. Ayrıca, aracınıza bir anahtar daha eklendiğinde sorun tekrar ortaya çıkar. Merak ediyorsanız sudo sshd -T | grep -i maxauthtries ile mevcut değeri kontrol edin, ardından IdentitiesOnly ile istemci tarafında düzeltme yapın.

Geçen ay sorunsuz çalışan bir sunucuda bu neden şimdi başladı?

Aracınız büyüdü. ~/.ssh/config içindeki AddKeysToAgent yes, kullandığınız her anahtarı yüklü tutar ve masaüstü anahtarlık (keyring) araçları, giriş sırasında anahtarları otomatik olarak yükler. Yüklü anahtar sayısı sunucunun MaxAuthTries değerini aştığında, anahtarı teklif sırasında geç sırada yer alan her sunucu bağlantısı başarısız olmaya başlar. ssh-add -l komutunu çalıştırın ve anahtar sayısını sunucudaki limit ile karşılaştırın.

Bu durum IP adresimin fail2ban tarafından yasaklanmasına neden olabilir mi?

Evet. Reddedilen her anahtar, sunucu günlüğünde bir Failed publickey for ... satırı oluşturur; bu nedenle tek bir bağlantı, saniyeler içinde adresinizden birkaç başarısızlık kaydı üretebilir. fail2ban sshd jail'i, findtime süresi içinde maxretry değerine ulaşıldığında adresi yasaklar. Belirtisi, hatanın bir takılmaya ve ardından zaman aşımına dönüşmesidir; çünkü paketler yanıtlanmak yerine düşürülmektedir. Konsol üzerinden sudo fail2ban-client set sshd unbanip <your address> ile yasağı kaldırın ve yeniden bağlanmadan önce istemci tarafındaki sorunu giderin.