SSH Permission denied (publickey) Hatası ve Çözümü

Permission denied (publickey) hatasının gerçek anlamı

Permission denied (publickey) hatası, istemcinizin bir veya daha fazla açık anahtar gönderdiği ancak sunucunun bunların hiçbirini kabul etmediği anlamına gelir. Ağ bağlantısı düzgündür ve sshd çalışmaktadır: reddedilme işlemi kimlik doğrulamanın son adımında gerçekleşir. Çözüm tahmin yürütmek değildir, çünkü ssh -v size beş olası nedenden hangisiyle karşı karşıya olduğunuzu söyler.

Parantez içindeki ifadeler, sunucunun kabul etmeye istekli olduğu yöntemlerdir. Permission denied (publickey) tek başına, o sunucuda parola ile girişin kapalı olduğu ve bu nedenle geri dönülebilecek bir parola seçeneği bulunmadığı anlamına gelir. Permission denied (publickey,password) ise parolaların sunulduğunu ancak sizin bu yöntemde de başarısız olduğunuzu belirtir.

Tek bir mesaj beş farklı hatayı kapsar ve bu kasıtlı olarak belirsiz tutulmuştur. "Böyle bir kullanıcı yok" veya "bu anahtar yüklü değil" şeklinde yanıt veren bir sunucu, geçerli hesapları tarayan kişilere yardımcı olurdu. Bu nedenle anahtarları değiştirmeye veya yapılandırma dosyalarını düzenlemeye hemen başlamayın. Tek bir komut çalıştırın, üç satırlık çıktıyı okuyun; böylece beş olası neden bire iner.

ssh -v komutunu çalıştırın ve üç satırı inceleyin

Başarısız olan komutu, -v eklenmiş haliyle tekrarlayın:

ssh -v deploy@203.0.113.10

Kırpılmış ancak gerçekçi bir çıktı şu şekildedir:

OpenSSH_9.6p1 Ubuntu-3ubuntu13, OpenSSL 3.0.13 30 Jan 2024
debug1: Connecting to 203.0.113.10 [203.0.113.10] port 22.
debug1: Connection established.
debug1: Authenticating to 203.0.113.10:22 as 'deploy'
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Will attempt key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Offering public key: /home/you/.ssh/id_ed25519 ED25519 SHA256:0eL/8sBw... agent
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
deploy@203.0.113.10: Permission denied (publickey).

İhtiyacınız olan her şey üç satırda yer alır.

Authenticating to 203.0.113.10:22 as 'deploy', aslında kullanılacak olan kullanıcı adıdır. Kastettiğiniz kullanıcı adı değil; ssh'in komut satırından, ~/.ssh/config dosyasından veya yerel oturum açma adınızdan çıkardığı kullanıcı adıdır.

Authentications that can continue: publickey, herhangi bir anahtar denenmeden önce sunucu tarafından gönderilen kabul edilen yöntemler listesidir. Eğer publickey bu ilk listede yoksa, sunucuda açık anahtar ile oturum açma özelliği kapalıdır; dolayısıyla hiçbir anahtar çalışmayacaktır.

Offering public key: ..., istemcinizin gerçekten gönderdiği her bir anahtar için bir satırdır; anahtarın geldiği dosyayı ve SHA256 parmak izini belirtir. Offering satırı olmayan bir anahtar, sunucuya hiç gönderilmemiştir.

Şimdi sorunu ikiye ayırın:

• Beklediğiniz anahtar için bir Offering public key satırı yok. Hata sizin makinenizdedir, çünkü sunucu anahtarınızı hiç görmemiştir.
• Anahtar sunuluyor ve Authentications that can continue: publickey tekrar geri dönüyor. Sunucu anahtarı almış ancak reddetmiştir, bu durumda hata sunucu tarafındadır.

Aşağıdaki nedenler, en sık karşılaşılan durumdan başlayarak sıralanmıştır.

Neden 1: Yanlış kullanıcı adıyla bağlanıyorsunuz

En yaygın neden aynı zamanda en az ilgi çekici olanıdır. SSH (secure shell) sunucu daemon'ı olan sshd, bir hesabın mevcut olmadığını size asla söylemez. Uydurma bir kullanıcı adı için tüm süreci yürütür ve sonunda aynı mesajla reddeder; çünkü geçerli hesap adlarının sızdırılması bir saldırgana yardımcı olur. Kullanıcı adındaki bir yazım hatası, bozuk bir anahtarla tamamen aynı görünür.

Başka hiçbir şeye bakmadan önce Authenticating to ... as satırını kontrol edin. Eğer bu satır sunucu hesabı yerine dizüstü bilgisayarınızın kullanıcı adını belirtiyorsa, komutta kullanıcı adını belirtmeyi unutmuşsunuz demektir.

ssh -v deploy@203.0.113.10
ssh -v root@203.0.113.10

Varsayılan hesap, sağlayıcınızın oluşturduğu imaja bağlıdır. Ağustos 2026 itibarıyla, Ubuntu bulut imajları genellikle ubuntu hesabıyla gelir, Debian imajları debian veya admin ile gelir, Rocky Linux ve AlmaLinux rocky ve almalinux ile gelir ve birçok VPS sağlayıcısı bunun yerine anahtarınızı doğrudan root içine kurar. Sağlayıcınızın kontrol paneli hangi hesabı oluşturduğunu kaydeder. Sunucu dışından çalıştırılan hiçbir komut bunu sorgulayamaz.

~/.ssh/config içindeki bir Host bloğu da kullanıcı adını belirler ve bu ayar yerel kullanıcı adınızdan daha baskındır:

Host vps-prod
  HostName 203.0.113.10
  User deploy

Hesabı kendiniz oluşturduysanız ve ardından bu hesapla giriş yapamadıysanız, anahtar muhtemelen imajın varsayılan kullanıcısı için kurulmuş ve hiç kopyalanmamıştır. Bu adım yeni bir VPS üzerindeki ilk on dakika rehberinin bir parçasıdır ve atlanması kolaydır.

Neden 2: gönderdiğinizi sandığınız anahtar, gönderilen anahtar değildir

Varsayılan olarak ssh, yalnızca ssh-agent içinde tutulan anahtarları ve ~/.ssh dizinindeki belirli dosya adlarını sunar: id_ed25519, id_ecdsa, id_rsa ve bu isimlerin donanım ile DSA varyantları. ~/.ssh/vps-prod olarak kaydedilen bir anahtar, siz onu isimlendirene kadar ssh tarafından görülmez; bu nedenle ayrıntılı (verbose) çıktıda bunun için herhangi bir Offering public key satırı görünmez.

Dosyayı isimlendirin ve agent anahtarlarının onun yerine geçmesini engelleyin:

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

Agent anahtarları tuttuğunda tek başına -i yeterli değildir; çünkü ssh, agent'ın anahtarlarını önce, isimlendirilmiş dosyayı ise en son sunar. Bu durum önemlidir çünkü sunucu, reddedilen her anahtarı MaxAuthTries limitine dahil eder; bu değer varsayılan olarak 6'dır. Yedi anahtar tutan bir agent, doğru anahtarınıza ulaşılmadan önce limiti doldurabilir ve mesaj şu şekilde değişir:

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

IdentitiesOnly=yes, denemeyi yalnızca belirttiğiniz dosya ile sınırlar. Agent'ın neleri tuttuğunu ssh-add -l ile listeleyin ve yıllar içinde birikmiş eski anahtarlar varsa ssh-add -D ile temizleyin. Ardından, bir sonraki girişin bayrakları hatırlamaya bağlı kalmaması için ayarları kaydedin:

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

İstemci tarafında bir tuzak daha vardır. ssh, kendi makinenizdeki diğer hesapların okuyabildiği bir özel anahtarı kullanmayı reddeder. Bir uyarı yazdırır ve ardından anahtarı yok sayar; bu nedenle anahtar asla sunulmaz ve sunucu onu asla görmez:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/you/.ssh/vps-prod' are too open.

chmod 600 ~/.ssh/vps-prod bunu düzeltir. Bir anahtarı USB bellek veya Windows paylaşımı üzerinden taşımak, dosya modunun kaybolmasının yaygın yoludur. Anahtarların nerede tutulacağı ve nasıl adlandırılacağı SSH anahtar yönetimi temelleri bölümünde ele alınmıştır.

Neden 3: public key authorized_keys dosyasına ulaşmadı

Eğer ssh -v anahtarın gönderildiğini gösteriyor ancak sunucu hala erişimi reddediyorsa, bir sonraki soru anahtarın hesabın authorized_keys dosyasında bulunup bulunmadığıdır. SSH üzerinden giriş yapıp kontrol edemeyeceğiniz için sağlayıcınızın konsolunu açarak durumu denetleyin.

sudo ls -l /home/deploy/.ssh/
sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys

authorized_keys dosyası üzerinde çalıştırılan ssh-keygen -lf komutu, her giriş için bir parmak izi (fingerprint) yazdırır:

256 SHA256:0eL/8sBw... you@laptop (ED25519)
3072 SHA256:9Tq2yZk... old-laptop (RSA)

Bunları Offering public key satırınızdaki parmak izi ile karşılaştırın. Eğer listede yoksa, ne hatırlarsanız hatırlayın, anahtar o hesaba yüklenmemiş demektir.

İşlerin yanlış gitmesine neden olan dört yaygın durum şunlardır:

• .pub dosyası yerine private key içeriğini yapıştırdınız. Bir public key satırı ssh-ed25519 veya ssh-rsa ile başlar. Private key ise -----BEGIN OPENSSH PRIVATE KEY----- ile başlar.
• Yapıştırılan metin birden fazla satıra bölündü. Her giriş tam olarak tek bir satırda yer almalıdır; bu nedenle satır sonu karakteriyle bölünmüş bir anahtar, birden fazla hatalı giriş olarak okunur ve hiçbir şeyle eşleşmez.
• Siz deploy olarak giriş yapmaya çalışırken anahtar /root/.ssh/authorized_keys dosyasına eklendi veya tam tersi oldu. Bu dosya hesaba özeldir ve ortak bir dosya bulunmaz.
• Sağlayıcının "anahtarımı ekle" kutusu, anahtarı yalnızca imajın varsayılan kullanıcısına yazdı; bu nedenle daha sonra oluşturduğunuz hesabın .ssh dizini boş kaldı.

Konsol üzerinden root yetkisiyle güvenli bir şekilde anahtar ekleme yöntemi şöyledir:

sudo install -d -m 700 -o deploy -g deploy /home/deploy/.ssh
sudo tee -a /home/deploy/.ssh/authorized_keys >/dev/null <<'EOF'
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIExampleKeyDataHere you@laptop
EOF
sudo chown deploy:deploy /home/deploy/.ssh/authorized_keys
sudo chmod 600 /home/deploy/.ssh/authorized_keys

Ardından sudo ssh-keygen -lf /home/deploy/.ssh/authorized_keys komutunu tekrar çalıştırın. Yeni parmak izi artık listede görünmelidir. Hala parola ile giriş yapabildiğiniz bir makineden, ssh-copy-id -i ~/.ssh/vps-prod.pub deploy@203.0.113.10 komutu aynı işlemi gerçekleştirir ve izinleri sizin için doğru şekilde ayarlar.

Neden 4: sshd, izinler çok geniş olduğunda authorized_keys dosyasını neden görmezden gelir

StrictModes yes, sshd varsayılanıdır. Bu ayar altında sshd; authorized_keys dosyasının, .ssh dizininin veya kullanıcının ev dizininin sahibi dışında herhangi biri tarafından yazılabilir olması durumunda bu dosyayı okumayı reddeder. Bunun nedeni açıktır: Eğer grup veya diğer kullanıcılar ev dizininize yazabiliyorsa, bu erişime sahip herhangi bir hesap authorized_keys dosyasını değiştirerek oturum açma işlemini ele geçirebilir. sshd, güvenilmeyen bir yolu hiç anahtar yokmuş gibi değerlendirir.

İstemci tarafında basit bir Permission denied mesajı görülür. Sunucu günlüğü ise gerçek nedeni kaydeder:

Authentication refused: bad ownership or modes for directory /home/deploy/.ssh

veya dosyanın kendisi sorunlu olduğunda:

Authentication refused: bad ownership or modes for file /home/deploy/.ssh/authorized_keys

sshd tarafından kabul edilen yapılandırma:

• Ev dizini: Grup tarafından yazılabilir olmamalı ve diğer kullanıcılar tarafından yazılabilir olmamalıdır. 755, 750 ve 700 izinleri geçerlidir. 775 ve 777 izinleri başarısız olur.
• ~/.ssh: 700 modu.
• ~/.ssh/authorized_keys: 600 modu.
• Sahiplik: Üçü de root tarafından değil, oturum açtığınız hesap tarafından sahiplenilmelidir.

Sahiplik, mod kadar önemlidir. /home/deploy/.ssh içindeki bir dosya root tarafından sahiplenilmişse aynı denetim başarısız olur; bu durum genellikle dosya sudo nano ile oluşturulup sahipliği geri devretmeyi unuttuğunuzda gerçekleşir. Her ikisini de aynı anda düzeltin:

sudo chown -R deploy:deploy /home/deploy/.ssh
sudo chmod 700 /home/deploy/.ssh
sudo chmod 600 /home/deploy/.ssh/authorized_keys
sudo chmod go-w /home/deploy
ls -ld /home/deploy /home/deploy/.ssh

Son komut sonucu gösterir. Ev dizini için drwxr-xr-x veya daha kısıtlayıcı bir izin, .ssh için ise drwx------ izni gereklidir. Bu dizgeler henüz net değilse, canlı bir sunucuda modları değiştirmeden önce drwxr-xr-x gibi bir izin dizgesi nasıl okunur konusunu okuyun.

Rocky Linux ve AlmaLinux üzerinde, şüpheliler listesine SELinux (security-enhanced Linux) eklenmelidir. Olağan dışı bir yolla oluşturulan .ssh dizini yanlış dosya etiketine sahip olabilir; bu durumda izinler doğru görünse bile sshd'nin okuma erişimi reddedilir. sudo restorecon -Rv /home/deploy/.ssh etiketleri düzeltir, sudo ausearch -m avc -ts recent ise reddeden bileşenin SELinux olup olmadığını gösterir.

Neden 5: sshd sizi reddedecek şekilde yapılandırılmış

Güncel bir Ubuntu veya Debian sisteminde sadece /etc/ssh/sshd_config dosyasını okumak yeterli değildir. Bu dosya Include /etc/ssh/sshd_config.d/*.conf ile başlar ve OpenSSH, herhangi bir ayar için bulduğu ilk değeri esas alır. Bu nedenle, 50-cloud-init.conf gibi bir ek yapılandırma dosyası önce okunur ve ana dosyanın alt kısımlarında yaptığınız tüm değişiklikleri geçersiz kılar. Bir düzenlemenin doğru görünmesine rağmen hiçbir şeyi değiştirmemesinin nedeni budur.

sshd servisinden gerçekten kullandığı yapılandırmayı isteyin:

sudo sshd -T | grep -Ei 'pubkeyauth|authorizedkeysfile|permitrootlogin|allowusers|allowgroups|denyusers'

Sağlıklı bir çıktı şu şekilde görünür:

permitrootlogin prohibit-password
pubkeyauthentication yes
authorizedkeysfile .ssh/authorized_keys .ssh/authorized_keys2

Kendi çıktınızda aramanız gerekenler:

• pubkeyauthentication no. Hiçbir anahtar kabul edilmeyecektir. Bu durum ssh -v içerisinde de içinde publickey bulunmayan bir Authentications that can continue: listesi olarak görünür.
• authorizedkeysfile değerinin başka bir yeri işaret etmesi, örneğin /etc/ssh/authorized_keys/%u. Bu durumda ev dizininizdeki dosya tamamen göz ardı edilir ve 4. nedendeki izin kuralları yeni yol için geçerli olur.
• allowusers veya allowgroups ayarlarının varlığı. Listelenmeyen her hesap, hiçbir açıklama yapılmaksızın tam olarak bu hata ile reddedilir. denyusers ve denygroups ayarları ise bunun tersini yapar.
• root olarak giriş yapmaya çalışırken permitrootlogin no ayarının aktif olması. prohibit-password kullanışlı bir orta yoldur: root kullanıcısı anahtar kullanabilir ancak parola kullanamaz.

Match blokları düz bir sshd -T çıktısında görünmez, çünkü sonuçları kimin bağlandığına bağlıdır. Belirli bir bağlantı için sorgulama yapın:

sudo sshd -T -C user=deploy,host=vps.example.com,addr=198.51.100.7

Eski anahtarları etkileyen bir ayar daha mevcuttur. OpenSSH 8.8 sürümü ile birlikte SHA-1 imzaları (ssh-rsa) varsayılan olarak kabul edilmemeye başlanmıştır; bu nedenle yıllardır çalışan bir RSA anahtarı, sunucu yükseltmesinden hemen sonra çalışmayı durdurabilir. İstemci bunu açıkça belirtir:

debug1: send_pubkey_test: no mutual signature algorithm

Doğru çözüm yeni bir anahtardır: ssh-keygen -t ed25519 -C "deploy@vps-prod" komutunu kullanın ve ardından yukarıda gösterildiği gibi .pub dosyasını yükleyin. Sunucuda PubkeyAcceptedAlgorithms +ssh-rsa ayarını yapmak eski imzaları yeniden etkinleştirir ve sisteme giriş yapmanızı sağlar; ancak bunu işin sonu olarak değil, sunucuya erişim sağlamak için bir yöntem olarak değerlendirin. Gözden geçirilmesi gereken diğer sunucu tarafı ayarları için VPS üzerinde SSH sunucusunu sıkılaştırma bölümüne bakabilirsiniz.

Özel anahtarın yüklü genel anahtarla eşleştiği nasıl doğrulanır

Bu hatadaki belirsizliklerin çoğu, iki dosyanın bir çift olup olmadığının bilinmemesinden kaynaklanır. Tek bir komut bunu yanıtlar:

ssh-keygen -y -f ~/.ssh/vps-prod

Bu komut, özel anahtardan türetilen genel anahtarı yazdırır. Yanındaki .pub dosyasını asla okumaz; bu nedenle eski bir .pub dosyasının iddia ettiğinden ziyade, özel anahtarın gerçekte ne olduğunu size söyler. Anahtarın bir parola koruması varsa komut bunu sorar; bu da parolayı hâlâ bildiğinizi kanıtlar.

ssh-keygen -lf ~/.ssh/vps-prod.pub
ssh-add -l

Birincisi, bir genel anahtar dosyasının parmak izini yazdırır. İkincisi, ajanınızın tuttuğu parmak izlerini yazdırır. Şimdi aynı dizenin dört görünümünü hizalayın: ssh -v içindeki Offering public key satırında bulunan parmak izi, .pub dosyanızın parmak izi, sunucunun authorized_keys dosyasındaki ssh-keygen -lf içinde yer alan parmak izleri ve sunucu günlüğündeki parmak izi. Eşleşmenin bozulduğu nokta sizin hatanızdır.

Giriş başarısız olduğunda sunucu günlüğünü okuma

İstemciye güvenlik nedeniyle anlamlı bir hata mesajı verilmez. Sunucu, gerçek nedeni günlük kayıtlarına yazar. Konsol oturumunda bir günlük izleyici başlatın, ardından dizüstü bilgisayarınızdan başarısız olan ssh komutunu çalıştırın.

sudo journalctl -u ssh -f

Ubuntu 24.04 varsayılan olarak rsyslog kurmaz, bu nedenle /var/log/auth.log orada mevcut olmayabilir. Rocky Linux ve AlmaLinux üzerinde birim adı sshd şeklindedir ve aynı kayıtlar /var/log/secure dosyasına da düşer.

sshd yapılandırmasında LogLevel VERBOSE ayarını yapın ve servisi yeniden yükleyin. Her deneme, sunucunun gerçekten aldığı parmak izini günlüğe kaydeder:

Failed publickey for deploy from 198.51.100.7 port 49812 ssh2: ED25519 SHA256:0eL/8sBw...

Bu satır, hatanın hangi tarafta olduğunu size söyler. Tanıdığınız bir parmak izi, anahtarınızın sunucuya ulaştığı ancak reddedildiği anlamına gelir; bu durumda 3, 4 ve 5 numaralı nedenleri inceleyin. Tanımadığınız bir parmak izi ise istemcinizin amaçlamadığınız bir anahtar gönderdiği anlamına gelir; bu durumda 2 numaralı nedene geri dönün.

Günlük kayıtları hala net değilse, başka bir port üzerinde hata ayıklama (debug) modunda ikinci bir sshd çalıştırın. Bu süreç ön planda kalır, tek bir bağlantıya hizmet verir, gerekçesini yazdırır ve ardından sonlanır:

sudo /usr/sbin/sshd -ddd -p 2222

Aynı sunucudaki konsol oturumundan, loopback adresi üzerinden bağlantı kurun:

ssh -p 2222 -i ~/.ssh/vps-prod -o IdentitiesOnly=yes deploy@127.0.0.1

127.0.0.1 üzerinden ilerlemek, güvenlik duvarını testin dışında tutar. Hata ayıklama çıktısı, açılan dosyayı, karşılaştırılan parmak izini ve Authentication refused: bad ownership or modes for directory /home/deploy gibi satırlar dahil olmak üzere reddedilmenin tam nedenini belirtir. Yanıtınızı aldığınızda Ctrl+C tuşlarına basın. 22 numaralı porttaki gerçek sshd süreci bu işlem boyunca etkilenmez.

Sistem dışı kalmaktan nasıl kaçınılır

Sunucu yapılandırmasını değiştiren her adım, SSH'ye bağımlı olmayan bir geri dönüş yolu gerektirir. Bu hazırlığı SSH bağlantısı henüz çalışıyorken yapın; bağlantı koptuktan sonra değil.

1. Sağlayıcınızın konsolunu seri bağlantı veya VNC (virtual network computing) üzerinden açın ve giriş yapabildiğinizi doğrulayın.
2. sudo yetkisine sahip bir hesap için çalışan bir yerel parolanız olduğundan emin olun. Eğer yoksa, önce sağlayıcı konsolundan root parolasını sıfırlayın.
3. Mevcut SSH oturumunuzu açık tutun. Açık bir oturum systemctl restart ssh işleminden etkilenmez; bu nedenle yeni yapılandırma hatalı olsa bile sisteme geri dönmenizi sağlar.
4. Yeniden başlatmadan önce söz dizimini kontrol edin: sudo sshd -t dosyada hata yoksa hiçbir çıktı vermez, hata varsa dosya adını ve satır numarasını gösterir.
5. İlk terminali kapatmadan önce ikinci bir terminal açın ve yeni bir oturum başlatın. Hatalı yapılandırma yeni girişleri engeller ancak mevcut oturumları sonlandırmaz; bu nedenle üzerinde çalıştığınız oturum, değişikliğin başarılı olup olmadığını size söyleyemez.

Debian ve Ubuntu üzerinde sudo systemctl restart ssh, Rocky Linux ve AlmaLinux üzerinde ise sudo systemctl restart sshd komutuyla yeniden başlatın. Ubuntu 24.04 sürümünde sshd bir socket birimi üzerinden başlatılır; bu nedenle Port veya ListenAddress üzerinde yapılan bir değişikliğin geçerli olması için sudo systemctl restart ssh.socket komutu da gereklidir.

FAQ

Neden aynı anahtar başka bir sunucuda çalışırken burada Permission denied (publickey) hatası alıyorum?

Çünkü anahtarınızda bir sorun yoktur, ancak çevresindeki yapılandırmada bir sorun vardır. ssh -v komutunu çalıştırın ve Offering public key satırını bulun. Anahtarınız burada listelenmiyorsa, ssh onu hiç göndermemiştir: dosya ~/.ssh dizininde varsayılan bir isimle bulunmuyor veya agent içinde yüklü değildir; bu durumda -i /path/to/key -o IdentitiesOnly=yes komutunu kullanın. Anahtar listeleniyor ancak sunucu yine de reddediyorsa, anahtar hesabın authorized_keys dosyasında eksiktir, anahtarın bulunduğu dizin grup tarafından yazılabilir durumdadır veya sshd yapılandırması kullanıcının girişini engelliyordur. Sunucu günlükleri bu durumları birbirinden ayırır.

SSH'in gerçekte hangi anahtarı gönderdiğini nasıl görebilirim?

ssh -v host her anahtar için bir debug1: Offering public key: satırı yazdırır; her satır kaynak dosyayı ve bir SHA256 parmak izini belirtir. ssh-add -l, agent içinde tutulan parmak izlerini listeler. ssh-keygen -lf ~/.ssh/id_ed25519.pub tek bir anahtar dosyasının parmak izini yazdırır, ssh-keygen -y -f ~/.ssh/id_ed25519 ise özel bir anahtardan türetilen genel anahtarı görüntüler. Girişin başarılı olması için, Offering satırındaki parmak izinin, sunucunun authorized_keys dosyası üzerinde çalıştırılan ssh-keygen -lf çıktısında da görünmesi gerekir.

sshd neden authorized_keys dosyamı görmezden geliyor?

Çünkü StrictModes varsayılan olarak etkindir ve dosyanın kendisi, .ssh dizini veya ev dizini grup ya da diğer kullanıcılar tarafından yazılabilir durumdadır ya da yanlış kullanıcıya aittir. sshd, başkalarının değiştirebileceği bir yola güvenmeyeceği için hiç anahtar yokmuş gibi davranır. Ev dizinini 755 veya daha kısıtlayıcı bir izinle, .ssh dizinini 700 ile, authorized_keys dosyasını ise 600 ile ayarlayın ve her üçünün de giriş yapılan hesaba ait olduğundan emin olun. LogLevel VERBOSE ile sunucu Authentication refused: bad ownership or modes for directory /home/deploy/.ssh kayıtlarını tutar.

Sunucu yükseltmesinden hemen sonra anahtarım çalışmayı durdurdu. Ne değişti?

Eğer bu bir RSA anahtarıysa, sorun büyük olasılıkla SHA-1 değişikliğidir. OpenSSH 8.8, ssh-rsa SHA-1 imzalarını varsayılan olarak devre dışı bırakmıştır; bu nedenle yalnızca bu yöntemle imzalayabilen anahtarlar reddedilir. İstemcinin ayrıntılı çıktısı debug1: send_pubkey_test: no mutual signature algorithm mesajını gösterir. ssh-keygen -t ed25519 ile modern bir anahtar oluşturun ve .pub dosyasını yükleyin. Acil erişime ihtiyacınız varsa, sunucuda PubkeyAcceptedAlgorithms +ssh-rsa ayarını eklemek eski imzaları yeniden etkinleştirir; yeni anahtar çalışır çalışmaz bu satırı kaldırmalısınız.

sshd_config dosyasını düzenledim ve artık hiçbir şekilde giriş yapamıyorum. Nasıl geri girebilirim?

SSH üzerinden geçmeyen, sağlayıcınızın sağladığı konsolu kullanın. Oradan yerel bir parola ile giriş yapın, sözdizimi hatasını ve satır numarasını görmek için sudo sshd -t komutunu çalıştırın, değişikliği geri alın ve servisi yeniden başlatın. Ardından, /etc/ssh/sshd_config.d/ dizinindeki bir dosyanın ana yapılandırmayı geçersiz kılıp kılmadığını anlamak için sudo sshd -T ile çalışan değerleri kontrol edin. Eğer yerel bir parolanız yoksa, önce konsoldan root parolasını sıfırlayın, ardından dosyayı onarın.