SSH Permission denied (publickey): gerçek çözüm

Saat 02:10’da bir deploy, bin kez yazdığım bir satırda öldü: ssh deploy@staging → Permission denied (publickey). Anahtar sağlamdı. Sorun teklifteydi.

TL;DR: Permission denied (publickey), istemcinin sunduğu her anahtarın sunucu tarafından reddedildiği anlamına gelir — bu bir pazarlık kararıdır, parola yazım hatası değil. Teşhis için ssh -vvv (hangi anahtarlar sunuldu) ve sunucu günlüğü journalctl -u ssh (hangileri reddedildi, neden) kullanın. Sonra dört nedenin birini düzeltin: yanlış kullanıcı, anahtarın authorized_keys içinde olmaması, çok açık izinler ya da OpenSSH 8.8+‘ın reddettiği ssh-rsa bir anahtar. ssh-copy-id tekrarların çoğunu önler.

$ ssh -T [email protected]
[email protected]: Permission denied (publickey).

Hata bir ipucu değil, hükümdür: teklifteki her şey reddedildi.

SSH neden “Permission denied (publickey)” diyor?

Herkese açık anahtarlı kimlik doğrulama, teklif–red pazarlığıdır. İstemci bulabildiği her anahtarı önerir — ajanınızdaki kimlikler, ~/.ssh/config, varsayılan dosya adları (id_ed25519, id_rsa) ve -i ile verdiğiniz her şey. Sunucu her teklifi hedef hesabın ~/.ssh/authorized_keys ile karşılaştırır. Hiçbiri eşleşmezse ve parolayla giriş devre dışı ya da tükenmişse, istemci her devops mühendisinin ezberinde olan o satırı basar.

Hata ayıklamak için iki gerçek önemli. Birincisi: ileti hangi kullanıcıya vurduğunuzu söylemez — yarım vakada kusursuz sağlam bir anahtar yanlış hesabın authorized_keys dosyasında oturur. İkincisi: sunucu nedeni çoktan söyledi; sshd her reddedilen teklifi günlüğe yazar. Kimsenin istemediği, herkesin ihtiyaç duyduğu yığın izi ise -vvv‘dir.

SSH gerçekten hangi anahtarı sunuyor, nasıl görürüm?

ssh -vvv deploy@staging 2>&1 | grep -iE "offering|identity|denied|authentications"
# debug1: Offering public key: /home/you/.ssh/id_ed25519 RSA-SHA256 (explicit)
# debug1: Authentications that can continue: publickey
# deploy@staging: Permission denied (publickey).

Üç satır okuyun: Offering public key (istemcinin önerdiği), Authentications that can continue (sunucunun hâlâ kabul ettiği — password yoksa parola sorusu asla gelmez) ve son hüküm. Doğru anahtarınız teklif listesinde hiç görünmüyorsa sorun istemci taraflıdır: yanlış -i yolu, ~/.ssh/config içinde unutulmuş bir IdentityFile ya da önce yanıt veren bayat bir kimliğe sahip bir ajan (ssh-add -l).

Dört gerçek neden hangileri?

Neden	Belirti	Çözüm
Yanlış kullanıcı	Anahtar root@host için çalışır, deploy@host için başarısız olur	Anahtar, o kullanıcının ~/.ssh/authorized_keys dosyasında olmalı
Anahtar kurulmamış	Sunucu günlüğü her teklif için Failed publickey gösterir	ssh-copy-id user@host
İzinler çok açık	İstemci: WARNING: UNPROTECTED PRIVATE KEY FILE — anahtar atlanır, hiç sunulmaz	chmod 700 ~/.ssh; chmod 600 ~/.ssh/*
Eski ssh-rsa anahtarı	Sunucu OpenSSH 8.8+; eski RSA anahtarı asla kabul edilmez	ed25519 olarak yeniden üretin ya da anahtarı yükseltin

İzin nedeni kendi notunu hak eder, çünkü OpenSSH bunu katı uygular: grup ya da diğerleri tarafından okunabilen bir özel anahtar, istemcinin kendisi tarafından reddedilir ve tekliften sessizce düşer. Çözüm iki komut:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/id_ed25519 ~/.ssh/authorized_keys

ssh-rsa nedeni eski CI imajlarını ve Raspberry Pi’leri yakalar: OpenSSH 8.8 (2021-10-01 tarihli, openssh.com/txt/release-8.8) ssh-rsa imzalarını — SHA-1 tabanlı türü — varsayılan olarak devre dışı bıraktı. Sürüm notlarından: “the ssh-rsa signature scheme is … disabled by default”. 2018’de üretilmiş bir RSA anahtarı bozuk değil; sadece imza biçimi artık konuşulmuyor. Kalıcı çözüm bir ed25519 anahtarı üretmek (ssh-keygen -t ed25519) ve bulut konsolları, tamirin ortasında kendinizi kilitlediğinizde size seri konsol verir.

Config’ini düzenlerken sshd başlamayı reddediyorsa, o başka bir av — bakınız systemd service not starting.

Sunucu anahtarı neden reddetti, nasıl görürüm?

Sunucu tarafındaki günlük dürüst tanıktır. Ubuntu’da (systemd) sshd her teklifin hükmünü günlüğe yazar:

journalctl -u ssh -n 50 --no-pager | grep -iE "publickey|denied|accepted"
# sshd[4421]: Failed publickey for deploy from 203.0.113.7 port 51422 ssh2: RSA SHA256:...
# sshd[4421]: Accepted publickey for deploy from 203.0.113.7 port 51422 ssh2: ED25519 SHA256:...

Beklenmedik bir parmak iziyle gelen Failed publickey, istemcinin sandığınızdan başka bir anahtar sunduğu anlamına gelir — geri dönün -vvv‘ye. Sizin parmak izinizle gelen Failed publickey, anahtarın doğru olduğu ama o hesap için kurulmadığı ya da sunucu tarafında ev dizini izinlerinin yanlış olduğu anlamına gelir (aynı 700/600 kuralı sunucunun ~/.ssh ve ~/.ssh/authorized_keys için de geçerlidir).

Anahtarımı doğru şekilde nasıl kurarım?

ssh-copy-id deploy@staging
# Number of key(s) added: 1
ssh -o BatchMode=yes deploy@staging 'echo ok'   # etkileşimsiz kanıt

ssh-copy-id, herkese açık anahtarınızı hedef hesabın authorized_keys dosyasına sağlıklı izinlerle ekler — bu komut var, çünkü authorized_keys‘e elle yapıştırmak tam yeterince sık başarısız olur: sonda kalan bir satır sonu ya da olmayan bir dizin. Gerçek test BatchMode denetimidir: tüm soruları kapatır; başarı, girişi yalnızca anahtarın taşıdığı anlamına gelir. Anahtar çalıştığında scp ve rsync aynı kimlik doğrulamayı bedavaya devralır — aralarındaki seçim bant genişliği meselesidir, kimlik bilgisi değil (rsync vs scp).

30 saniyelik triyaj

ssh -vvv user@host 2>&1 | grep -i offering      # 1. hangi anahtarlar sunuldu?
journalctl -u ssh -n 50 | grep -i publickey     # 2. neden reddedildi?
ls -ld ~/.ssh ~/.ssh/authorized_keys            # 3. 700 / 600 mü?
ssh-copy-id user@host                           # 4. kur, BatchMode ile doğrula

Permission denied (publickey) bir parola istemi değil, bir pazarlık sonucudur — sunucu teklifteki her anahtarı reddetti ve günlüğü nedenini çoktan biliyor.

Dört komutu sırayla çalıştırın ve arıza gizem olmaktan çıkar: her seferinde biri suçluyu adlandırır. Benimki, doğru anahtardan önce yanıt veren bayat bir ajan kimliğiydi — ssh-add -d ve deploy saat 02:31’de yeniden yeşile döndü.