SSH Permission denied (publickey) hatası nasıl çözülür?

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ı sorunsuzdur ve sshd çalışmaktadır: reddedilme işlemi kimlik doğrulamanın son adımında gerçekleşir. Eğer oturumunuz bu noktadan önce sonlanıyorsa, connection refused veya connection timed out ile karşı karşıyasınız demektir; bu farklı bir teşhis gerektiren farklı bir durumdur. Çözüm asla tahmin yürütmek değildir, çünkü ssh -v size beş olası nedenden hangisinin geçerli olduğunu söyler.

Parantez içindeki ifadeler, sunucunun kabul etmeye istekli olduğu yöntemlerdir. Permission denied (publickey) tek başına, 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 gösterir.

Tek bir mesaj beş farklı hatayı kapsar ve bu durum 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 inecektir.

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

Başarısız olan komutu, -v eklenmiş şekilde 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).

Üç satır, ihtiyacınız olan her bilgiyi içerir.

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 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çbir zaman 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 karşılığında tekrar Authentications that can continue: publickey alı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 sunucu daemon'ı olan sshd, bir hesabın mevcut olmadığını size asla söylemez. Uydurma bir kullanıcı adı için tüm değişim sürecini yürütür ve sonunda aynı mesajla reddeder; çünkü geçerli hesap adlarını sızdırmak 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 bir şey yapmadan ö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ı 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 giriş adınızdan daha önceliklidir:

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 diğer hesaba 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 düşündüğünüz anahtar, gönderilen anahtar değildir

Varsayılan olarak ssh, yalnızca ssh-agent içinde tutulan anahtarları ve ~/.ssh içindeki sabit dosya adı kümesini sunar: id_ed25519, id_ecdsa, id_rsa ve bu isimlerin donanım ve DSA varyantları. ~/.ssh/vps-prod olarak kaydedilen bir anahtar, siz onu isimlendirene kadar ssh için görünmezdir; bu nedenle ayrıntılı çıktı (verbose output), bunun için herhangi bir Offering public key satırı göstermez.

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 hala önce agent anahtarlarını, en son ise isimlendirilmiş dosyayı sunar. Bu önemlidir, çünkü sunucu reddedilen her anahtarı, varsayılan değeri 6 olan MaxAuthTries limitine karşı sayar. 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

Bunun yerine gördüğünüz ileti buysa sunucu, doğru key denenmeden önce oturumu sonlandırmıştır. Bu durum çok fazla kimlik doğrulama hatası konusunun kapsamındadır. IdentitiesOnly=yes denemeyi belirttiğiniz dosyayla sınırlar. Agent’ın elinde bulunanları ssh-add -l ile listeleyin. Yıllar içinde birikmiş eski key’ler varsa ssh-add -D ile temizleyin. Ardından ayarları bir dosyaya yazın. Böylece sonraki login işlemi flag’leri hatırlamaya bağlı olmaz:

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

İstemci tarafında bir tuzak daha. 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 hiçbir zaman 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 durduğu 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, servis sağlayıcınızın konsolunu açarak bunu doğrulayın.

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

authorized_keys dosyası üzerinde ssh-keygen -lf komutunu çalıştırmak, her girdi 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.

Hatalı sonuçlanmanın dört yaygın yolu ş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ırma işlemi sırasında satır kaymaları oluştu. Her girdi tam olarak tek bir satırda yer almalıdır; bu nedenle kaymış bir anahtar, birden fazla bozuk girdi olarak okunur ve hiçbir şeyle eşleşmez.
• Siz deploy olarak giriş yapmaya çalışırken anahtar /root/.ssh/authorized_keys içine eklendi veya tam tersi gerçekleşti. Dosya hesaba özeldir ve ortak bir dosya bulunmaz.
• Servis 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 anahtar eklemenin güvenli yolu şö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ş yapılabilen bir makineden, ssh-copy-id -i ~/.ssh/vps-prod.pub deploy@203.0.113.10 aynı işlemi gerçekleştirir ve izinleri sizin için doğru şekilde ayarlar.

Neden 4: sshd, izinler çok açık olduğunda authorized_keys dosyasını neden yok sayar?

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 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 veya herkes tarafından yazılabilir olmamalıdır. 755, 750 ve 700 izinleri geçerlidir. 775 ve 777 izinleri ise başarısız olur.
• ~/.ssh: 700 modu.
• ~/.ssh/authorized_keys: 600 modu.
• Sahiplik: her üç öğe 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 vermeyi unuttuğunuzda yaşanır. 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ı, .ssh için ise drwx------ izinlerini hedeflemelisiniz. Eğer bu dizgeler henüz net değilse, canlı bir sunucuda mod değişikliği yapmadan önce drwxr-xr-x gibi bir izin dizgesi nasıl okunur konusunu okuyun.

Rocky Linux ve AlmaLinux üzerinde, şüpheliler listesine SELinux'u (security-enhanced Linux) ekleyin. 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 dosyayı okuması engellenir. 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 dosya (drop-in file) ö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üzenleme doğru görünmesine rağmen hiçbir şeyi değiştirmemesinin nedeni budur.

sshd'den 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 şunlara dikkat edin:

• pubkeyauthentication no. Hiçbir anahtar kabul edilmeyecektir. Bu durum ssh -v içinde de içinde publickey bulunmayan bir Authentications that can continue: listesi olarak görünür.
• authorizedkeysfile başka bir yeri işaret ediyorsa, örneğin /etc/ssh/authorized_keys/%u. Bu durumda ev dizininizdeki dosyanız tamamen göz ardı edilir ve 4. nedendeki izin kuralları yeni yol için geçerli olur.
• allowusers veya allowgroups mevcutsa. Listelenmeyen her hesap, hiçbir açıklama yapılmaksızın tam olarak bu hata ile reddedilir. denyusers ve denygroups ise bunun tersini yapar.
• root olarak giriş yapmaya çalışırken permitrootlogin no. prohibit-password kullanışlı bir orta ayardır: root bir 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

Bir ayar daha eski anahtarları etkiler. OpenSSH 8.8, varsayılan olarak SHA-1 imzalarını (ssh-rsa) kabul etmeyi bıraktı; 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 çalıştırın ve ardından .pub dosyasını yukarıda gösterildiği gibi yükleyin. Sunucuda PubkeyAcceptedAlgorithms +ssh-rsa ayarını yapmak eski imzaları yeniden etkinleştirir ve bugün sisteme girmenizi sağlar; ancak bunu işin sonu olarak değil, sunucuya erişim sağlamak için bir yöntem olarak görün. 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 bakın.

Ö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ı hala 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 yer alan parmak izi, .pub dosyanızın parmak izi, sunucunun authorized_keys dosyasındaki ssh-keygen -lf içinde bulunan parmak izleri ve sunucu günlüğündeki parmak izi. Eşleşmenin bozulduğu nokta, hatanın kaynağıdır.

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

İstemciye kasıtlı olarak yararlı bir bilgi verilmez. Sunucu, gerçek nedeni günlük dosyası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 bulunmayabilir. 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 aslında 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 bildirir. Tanıdığınız bir parmak izi, anahtarınızın ulaştığını ancak sunucu tarafından reddedildiğini gösterir; bu durumda 3, 4 ve 5 numaralı nedenlere bakın. Tanımadığınız bir parmak izi, 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 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 eder, 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 reddin tam nedenini belirtir. Yanıtınızı aldığınızda Ctrl+C tuşlarına basın. 22 numaralı porttaki gerçek sshd, işlem boyunca etkilenmez.

Sunucuya erişimi kaybetmemek için yapılması gerekenler

Sunucu yapılandırmasını değiştiren her adım, SSH'e bağımlı olmayan bir geri dönüş yolu gerektirir. Bu hazırlığı SSH bağlantınız 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 komutundan etkilenmez, bu nedenle yeni yapılandırma hatalı olsa bile sisteme geri dönmenizi sağlar.
4. Yeniden başlatmadan önce sözdizimini kontrol edin: sudo sshd -t komutu dosya geçerliyse hiçbir çıktı vermez, geçersizse 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şlatma yapın. Ubuntu 24.04 sürümünde sshd bir socket birimi üzerinden başlatılır, bu nedenle Port veya ListenAddress dosyalarında yapılan bir değişikliğin geçerli olması için sudo systemctl restart ssh.socket komutunun da çalıştırılması gerekir.

FAQ

Aynı anahtar başka bir sunucuda çalışırken neden Permission denied (publickey) hatası alıyorum?

Çünkü anahtarınızda bir sorun yoktur, ancak anahtarı çevreleyen 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 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. Eğer anahtar listeleniyor ancak sunucu yine de reddediyorsa, bu 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 dosyasını 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 yer alması 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 herkes tarafından yazılabilir durumdadır veya yanlış kullanıcıya aittir. sshd, başkalarının değiştirebileceği bir yola güvenmez, bu yüzden hiç anahtar yokmuş gibi davranır. Ev dizinini 755 veya daha kısıtlayıcı bir izinle ayarlayın, .ssh dizinini 700, authorized_keys dosyasını ise 600 izinlerine getirin 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.

Anahtarım bir sunucu yükseltmesinden hemen sonra ç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 bir anahtar artık reddedilir. Ayrıntılı istemci çı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ı yapmak 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 dönebilirim?

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/ içindeki bir dosyanın ana yapılandırmayı geçersiz kılıp kılmadığını anlamak için sudo sshd -T komutuyla çalışan değerleri doğrulayın. Eğer yerel bir parolanız yoksa, önce konsoldan root parolasını sıfırlayın, ardından dosyayı onarın.