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 (public key) kimlik doğrulaması, bir tahmin oyunu gibi başlar. İstemci bir açık anahtar gönderir ve sunucuya, bu anahtarla oluşturulmuş bir imzayı kabul edip etmeyeceğini sorar. Sunucu evet veya hayır yanıtını verir. "Hayır" yanıtı, tıpkı yanlış bir parola gibi başarısız bir deneme olarak 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 giren bir kullanıcı için fazlasıyla yeterlidir. Ancak on farklı anahtar tutan bir SSH ajanı için bu sayı oldukça düşüktür. Başarısızlık sayısı sınıra ulaş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. O hatada sunucu sunduğunuz tüm anahtarları incelemiş ve hiçbirini kabul etmemiştir. Burada ise sunucu incelemeyi durdurmuştur. İki durumu birbiriyle karıştırmak, kullanıcıların zaten doğru olan bir anahtarı tekrar kopyalamaya çalışarak zaman kaybetmesine 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 kullanımı

IdentitiesOnly yes, ssh istemcisine yalnızca yapılandırdığınız kimlikleri sunmasını ve ssh-agent tarafından otomatik sağlanan diğer anahtarları göz ardı etmesini söyler. Bunu bir IdentityFile satırı ile eşleştirdiğinizde, istemci sunucuya yalnızca tek bir anahtar teklifi gönderir.

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

Bu yapılandırmayı ~/.ssh/config dosyasına kaydedin ve ardından chmod 600 ~/.ssh/config komutunu çalıştırın. Grup veya diğer kullanıcılar 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 komutu tek bir anahtar sunar ve ssh -v vps çıktısı tam olarak bir adet Offering public key: satırı göstermelidir.

Bu noktada iki detay kullanıcıları şaşırtmaktadır.

• IdentitiesOnly yes tek başına "tek anahtar" anlamına gelmez. Bir IdentityFile satırı belirtilmediğinde, 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: bu ayar yapıldığında ssh varsayılanları eklemeyi durdurur.
• İmzalama işlemini hala ssh-agent yapar. IdentitiesOnly hangi anahtarların sunulacağını kontrol eder, kimin imzalayacağını değil. Eğer IdentityFile ile belirtilen özel anahtar (private key) agent içinde yüklüyse, agent imzayı oluşturur ve sizden hiçbir zaman parola istenmez. Hatta IdentityFile değerini eşleşen .pub dosyasına yönlendirebilirsiniz; özel anahtarın yalnızca agent içinde veya bir donanım anahtarında (hardware token) bulunduğu durumlarda yapılan işlem budur.

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

Eğer genel bir güvenlik ağı istiyorsanız, bayrağı dosyanın en altına yalnızca şu şekilde 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 tek bir anahtar belirlemek, daha sonra her şeyi yeniden oluşturmaya gerek kalmadan tek bir makinenin erişimini iptal etmeyi mümkün kılar. 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, agent soketi bağlandığınız sunucuda erişilebilir hale getirilir. O sunucuda çalıştırılan bir ssh komutu, iletilen soket üzerinden tüm anahtarlarınızla birlikte yerel agent'ınızı kullanır. İlk atlama sorunsuz çalışırken, atlama sunucusundan (jump host) nihai sunucuya geçişte hatanın ortaya çıkmasının nedeni budur. Ara makinede echo $SSH_AUTH_SOCK komutunu çalıştırın: boş çıktı, erişilebilir bir agent olmadığını gösterir. Bir soket yolu, bir agent'ın var olduğunu ancak bunun mutlaka sizinki olmadığını gösterir; çünkü o makinede başlatılan bir agent aynı değişkeni ayarlar. Orada ssh-add -l komutunu da çalıştırın: eğer kendi makinenizdeki anahtarları listeliyorsa, iletme (forwarding) aktiftir.

Agent iletmenin ikinci bir maliyeti daha vardır. Ara makinede root yetkisine sahip olan herkes, oturumunuz açık kaldığı sürece sizin adınıza kimlik doğrulaması yapmak için agent'ı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 nihai sunucuya doğrudan kendi makinenizden 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, dar anlamda, hatalı davranan bir istemciye daha fazla alan tanıdığı için işe yarar:

MaxAuthTries 20

Dosyayı doğrulayın, servisi yeniden yükleyin ve bu işlemi 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. Ubuntu'nun ssh.socket servisi, her bağlantı için yeni bir daemon başlatmaz: ilk bağlantı geldiğinde ssh.service servisini başlatır; bu servis çalışmaya devam eder ve sonraki bağlantıları yönetir. Yukarıdaki yeniden yükleme işlemi, değişikliği uygulayan yöntemdir. Eğer ssh.service henüz aktif değilse, yeniden yüklenecek bir şey yoktur ve bir sonraki bağlantı, yeni dosya ile servisi başlatır.

Ş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şlemesini söyler. 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. Agent'ınıza on üçüncü bir anahtar eklerseniz, başladığınız noktaya geri döner 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 sizi neden bu durum için engelleyebilir

sshd, reddedilen her anahtarı günlük kaydına almaz. Varsayılan LogLevel INFO değerinde, gerçek bir hesap için reddedilen bir anahtar, bağlantı hata sayısı MaxAuthTries değerinin yarısına ulaştığında günlüğe yazılır; kılavuzdaki "Hata sayısı bu değerin yarısına ulaştığında, sonraki hatalar günlüğe kaydedilir" ifadesi bunu kasteder. 6 olan varsayılan değerde, reddedilen ilk üç deneme günlüğe yazılmaz. Son üç deneme ise aşağıdaki gibi satırlar halinde görünür ve ardından maximum authentication attempts exceeded satırı gelir:

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

Bu satırlar bir hata yığını gibi görünse de, fail2ban sshd filtresi bunları bu şekilde saymaz. Varsayılan olarak gelen publickey = nofail, geçerli bir kullanıcı için yalnızca adres ve kullanıcı adını almak üzere Failed publickey satırını okur. Sayılan satır maximum authentication attempts exceeded satırıdır, dolayısıyla sınıra ulaşan tek bir bağlantı birden fazla değil, tek bir hata ekler. Jail, findtime süresi içinde maxretry hata gerçekleştiğinde kaynak adresi engeller ve fail2ban'in kendi jail.conf ayarları bunları sırasıyla 5 ve 10 dakika olarak belirler. On dakika içinde yaklaşık beş başarısız bağlantı kendi adresinizi engellemeniz için yeterlidir; döngü içinde yeniden deneme yapan bir betik veya araç bu sınıra hızla ulaşır.

Bu noktada belirtiler değişir ve insanları 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: bağlantı yanıt vermek yerine paketlerinizi düşüren güvenlik duvarı nedeniyle askıda kalır ve sonunda zaman aşımına uğrar. 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 açıklanmış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 çözerken kendi adresinizi jail.local içindeki ignoreip kısmına ekleyin, işiniz bittiğinde ise tekrar çıkarın. Jail yapılandırması Ubuntu 24.04 için fail2ban rehberi içerisinde anlatı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üzeltirim?

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

Neden ssh -i komutu 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 komutunu yalnızca belirttiğiniz kimliklerle sınırlayan seçenektir. -i ve -o IdentitiesOnly=yes seçeneklerini 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; daha yüksek bir sınır, sunucunun her bağlantı ve her kaba kuvvet denemesi için daha fazla reddedilen anahtarı değerlendirmesine neden olur. 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ını düzeltin.

Neden geçen ay sorunsuz çalışan bir sunucuda bu durum başladı?

Aracınız büyüdü. ~/.ssh/config içindeki AddKeysToAgent yes, kullandığınız her anahtarı yüklü tutar; masaüstü anahtarlık araçları da giriş sırasında anahtarları otomatik yükler. Yüklü anahtar sayısı sunucunun MaxAuthTries sınırını aştığında, anahtarı sunulma sırasında geride kalan 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 sınırla karşılaştırın.

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

Evet, ancak sunucu günlüğünün gösterdiğinden daha yavaş gerçekleşir. Varsayılan fail2ban sshd filtresi, geçerli bir kullanıcı için Failed publickey satırlarını saymaz. maximum authentication attempts exceeded satırını sayar, bu nedenle sınıra ulaşan her bağlantı bir başarısızlık olarak kaydedilir. maxretry = 5 ve findtime = 10m varsayılan ayarlarıyla, on dakika içinde bu tür beş bağlantı adresinizin yasaklanmasına neden olur. 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 istemciyi düzeltin.