SSH Permission Denied (publickey) Hatası Nasıl Çözülür?

SSH permission denied publickey hatası ne demek, hemen ne yapmalısınız?

SSH permission denied publickey hatası, sunucunun sizin gönderdiğiniz anahtarlardan hiçbirini kabul etmediği anlamına gelir. İlk iş olarak ssh -v kullanici@sunucu komutunu çalıştırın, hangi anahtarın denendiğine bakın ve public anahtarın sunucuda ya da GitHub hesabınızda kayıtlı olduğunu doğrulayın.

Panik gerekmez. Bu hata genellikle parola ya da sunucu çökmesi değil, küçük bir eşleşme sorunudur. Ekibimizin sahada gördüğü teşhis sırasını burada en olası nedenden en az olasıya doğru veriyoruz, çünkü rastgele denemek sizi yalnızca yorar.

Hızlı çözüm: ilk beş dakikada hangi adımları izlemelisiniz?

Aşağıdaki liste, ssh permission denied publickey hatasının büyük kısmını çözen sırayı verir. Her adımdan sonra bağlantıyı yeniden deneyin ve çalıştığı anda durun.

1. Kullanıcı adını ve sunucu adresini kontrol edin. GitHub için kullanıcı adı her zaman git olur.
2. ssh -v ile bağlanın ve "Offering public key" satırlarında doğru anahtarın denendiğini görün.
3. Public anahtarınızın sunucudaki authorized_keys dosyasında ya da GitHub hesabınızda kayıtlı olduğunu doğrulayın.
4. ssh-add -l ile anahtarın ssh-agent içinde yüklü olup olmadığına bakın, değilse ssh-add ile ekleyin.
5. ~/.ssh klasörünün ve anahtar dosyalarının izinlerini daraltın.
6. Gerekirse ~/.ssh/config içinde IdentityFile satırı tanımlayın.
7. GitHub için ssh -T git@github.com ile bağlantıyı test edin.

Her adımı aşağıda ayrı bir bölümde anlatıyoruz. Önce hatanın neden çıktığını kısaca anlayalım.

SSH permission denied publickey hatası neden çıkar?

SSH, açık anahtar kimlik doğrulamasında iki parça kullanır. Özel anahtarı kendi bilgisayarınızda tutarsınız, public anahtarı ise sunucuya tanıtırsınız. Sunucu, size bir sınav sorar ve yalnızca doğru özel anahtarın çözebileceği cevabı bekler.

Hata, bu sınavın hiçbir anahtarla geçilemediğini söyler. Yani sunucu ya sizin anahtarınızı hiç tanımıyor ya da anahtarınızı hiç görmüyor. Dolayısıyla sorunun yeri üç noktadan biridir: istemci yanlış anahtarı sunuyor, sunucu doğru anahtarı kayıtlarında bulamıyor ya da dosya izinleri nedeniyle sunucu kaydı okumayı reddediyor.

Ayrıca sunucu parola girişine kapalıysa, yedek bir yol da kalmaz. Hata mesajındaki parantez içi "publickey" ifadesi bu yüzden önemlidir: sunucunun hâlâ kabul ettiği tek yöntemi gösterir.

Kullanıcı adı ve sunucu adresi doğru mu?

En sık neden en basit olanıdır. Örneğin Ubuntu görüntülerinde varsayılan kullanıcı genellikle ubuntu, bazı görüntülerde root ya da admin olabilir. Yanlış kullanıcıyla bağlandığınızda anahtarınız doğru olsa bile sunucu o kullanıcının kayıtlarına bakar ve anahtarı bulamaz.

• Hosting ya da bulut panelinde gösterilen varsayılan kullanıcı adını okuyun.
• Komutta kullanici@sunucu biçimini açıkça yazın, çünkü yazmazsanız istemci yerel kullanıcı adınızı gönderir.
• Birden fazla sunucunuz varsa adresin doğru makineye çözüldüğünü DNS sorgulama aracımızla kontrol edin.
• Port farklıysa -p ile belirtin, aksi halde başka bir servise bağlanıyor olabilirsiniz.

Bu kontrol yalnızca bir dakika sürer. Ancak atlanırsa sonraki tüm adımlar boşa gider.

ssh -v ile hangi anahtarın denendiğini nasıl görürsünüz?

Ayrıntılı mod, tahmin yürütmeyi bırakıp gerçeği görmenizi sağlar. OpenSSH belgesinde -v bayrağı hata ayıklama çıktısını açar, birden fazla -v ayrıntıyı artırır. Bağlantıyı şöyle başlatın:

ssh -v kullanici@example.com

Çıktıda şu satırları arayın:

• Offering public key: istemcinin hangi anahtar dosyasını sunduğunu gösterir. Beklediğiniz dosya yoksa istemci o anahtarı hiç bulamıyor demektir.
• Authentications that can continue: sunucunun hangi yöntemleri kabul ettiğini listeler. Yalnızca publickey görüyorsanız parola girişi kapalıdır.
• No more authentication methods to try: tüm denemelerin bittiğini ve başarısız olduğunu söyler.
• Will attempt key: yüklü anahtarların sırasını gösterir, ssh-agent sorunlarını burada yakalarsınız.

Böylece sorunun istemci tarafında mı, sunucu tarafında mı olduğunu hızla ayırırsınız. Hiçbir anahtar sunulmuyorsa sorun sizin bilgisayarınızdadır. Doğru anahtarı sunuyor ama sunucu reddediyorsa sorun sunucu tarafındadır.

Public anahtar sunucudaki authorized_keys dosyasında mı?

Sunucu, hangi anahtarlara izin vereceğini kullanıcının ev dizinindeki ~/.ssh/authorized_keys dosyasından okur. OpenSSH belgesine göre bu dosyada her satır bir public anahtardır. Satırı eksik, yarım ya da başka bir kullanıcının dosyasında bırakmış olabilirsiniz.

Kontrol için kendi bilgisayarınızda public anahtarı yazdırın, sunucuda da dosyadaki satırla karşılaştırın:

cat ~/.ssh/id_ed25519.pub
cat ~/.ssh/authorized_keys

• Anahtar tek satır olmalıdır. Kopyalarken satır sonu bölünmüşse anahtar geçersiz olur.
• Dosya yalnızca .pub uzantılı public anahtarı içermelidir, özel anahtarı değil.
• Anahtarı doğru kullanıcının ev dizinine eklediğinizden emin olun. Root için eklenen anahtar, başka kullanıcıya bağlanırken işe yaramaz.
• Anahtarı eklemenin en güvenli yolu, hâlâ erişiminiz varken ssh-copy-id komutunu kullanmaktır.

Sunucuya hiçbir şekilde giremiyorsanız hosting ya da bulut panelindeki konsol erişimi veya kurtarma modu yardımcı olur. Bu yolu kullanmadan önce sağlayıcınızın resmi belgesini okuyun.

GitHub'da ssh permission denied publickey hatası neden çıkar?

GitHub bağlantılarında hata mesajı aynıdır, ancak nedenler biraz farklıdır. GitHub Docs bu hatanın sorun giderme sayfasında önce uzak adresin doğru biçimde olduğunu, kullanıcı adının git olduğunu ve public anahtarın hesaba eklendiğini kontrol etmenizi önerir.

1. Uzak adres SSH biçiminde olmalıdır. Bunu git remote -v ile görürsünüz. HTTPS adresi kullanıyorsanız SSH anahtarınızın hiçbir rolü yoktur.
2. Adres git@github.com:hesap/depo.git biçimindeyse kullanıcı adı doğrudur. Kendi kullanıcı adınızı yazmak hataya yol açar.
3. Public anahtarı GitHub hesap ayarlarındaki SSH anahtarları bölümüne eklediğinizden emin olun. Menü adı değişebilir, bu yüzden resmi yardım sayfasındaki güncel yolu izleyin.
4. Kurumsal hesapta depo bir organizasyona aitse, organizasyonun SSH erişim kurallarını da gözden geçirin.
5. Anahtarı başka bir hesaba eklediyseniz, GitHub aynı anahtarı iki hesapta kabul etmez. Bu durumda her hesap için ayrı anahtar üretin.

Git komutlarının temelini hatırlamak isterseniz Git ve GitHub kullanım rehberimize göz atabilirsiniz.

ssh-agent anahtarınızı neden görmez?

Parola korumalı bir anahtar kullanıyorsanız ya da anahtar varsayılan dosya adında değilse, istemci anahtarı kendiliğinden bulamayabilir. ssh-agent, açılmış anahtarları bellekte tutan yardımcı bir programdır. Böylece her bağlantıda parola yazmazsınız.

Önce agent içinde hangi anahtarların yüklü olduğuna bakın:

ssh-add -l
ssh-add ~/.ssh/id_ed25519

• İlk komut yüklü anahtarların parmak izlerini listeler. "The agent has no identities" benzeri bir cevap alıyorsanız agent boştur.
• İkinci komut anahtarı agent'a ekler. Parola sorarsa anahtarı oluştururken belirlediğiniz parolayı yazın.
• Agent çok fazla anahtar yüklüyse sunucu, doğru anahtara sıra gelmeden deneme sınırını doldurabilir. Bu durumda yalnızca belirli anahtarı kullandırmak gerekir, bunu config bölümünde anlatıyoruz.
• Terminali kapatıp açtığınızda agent boşalıyorsa, işletim sisteminizin anahtar zinciri entegrasyonunu resmi belgelerden inceleyin.

Agent sorununu özellikle yeni bir bilgisayara geçtikten sonra yaşarsınız. Çünkü anahtar dosyası taşınmıştır, ama agent hâlâ eski oturumun boş durumundadır.

~/.ssh izinleri neden SSH bağlantısını bozar?

OpenSSH güvenlik için dosya izinlerine bakar. Özel anahtarınız başkaları tarafından okunabiliyorsa istemci onu kullanmayı reddeder ve "UNPROTECTED PRIVATE KEY FILE" benzeri bir uyarı verir. Sunucu tarafında da ev dizini ya da .ssh klasörü herkese yazılabilir durumdaysa sshd, kaydı güvenli saymayabilir.

sshd_config belgesindeki StrictModes seçeneği tam olarak bu denetimi yapar. Yaygın olarak önerilen değerler şunlardır:

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

Sunucuda da aynı işlemi, ilgili kullanıcının ev dizininde yapın. Kesin değerleri kendi sisteminizin OpenSSH belgesinden de doğrulayın.

~/.ssh/config içinde IdentityFile nasıl ayarlanır?

Birden fazla anahtarınız varsa ya da anahtar varsayılan dışı bir adla duruyorsa istemciye hangisini kullanacağını söylemeniz gerekir. ssh_config belgesi bunun için IdentityFile ve IdentitiesOnly seçeneklerini tanımlar.

Host github.com
  User git
  IdentityFile ~/.ssh/id_ed25519_github
  IdentitiesOnly yes

• Host: bu kuralın hangi sunucu için geçerli olduğunu belirler.
• User: varsayılan kullanıcı adını sabitler, böylece her komutta yazmazsınız.
• IdentityFile: özel anahtarın yolunu gösterir.
• IdentitiesOnly yes: yalnızca belirtilen anahtarın sunulmasını sağlar, agent içindeki diğer anahtarları göndermez.

Birden fazla GitHub hesabı kullanan geliştiriciler için bu ayar hayat kurtarır. Örnek senaryo: iş ve kişisel hesap için iki ayrı anahtar üretir, her birine ayrı bir Host adı verirsiniz. Böylece yanlış hesabın anahtarını göndermezsiniz.

GitHub bağlantısını ssh -T ile nasıl test edersiniz?

Bir depoyu çekmeye çalışmadan önce bağlantıyı tek komutla doğrulayabilirsiniz. GitHub Docs, SSH bağlantısını test etmek için şu komutu önerir:

ssh -T git@github.com

Başarılı olursa GitHub, kimliğinizin doğrulandığını belirten bir karşılama mesajı döner. İlk bağlantıda ssh sizden sunucunun parmak izini onaylamanızı ister. Bu parmak izini GitHub Docs sayfasında yayımlanan değerlerle karşılaştırın, ardından onaylayın.

Yine "Permission denied (publickey)" görüyorsanız, çıktıyı ssh -vT git@github.com ile ayrıntılandırın. Sunulan anahtarın GitHub hesabına eklediğiniz anahtarla aynı olup olmadığına bakın. Burada hâlâ yanlış anahtar sunuluyorsa config bölümüne dönün.

Sunucuda parola girişi kapalıysa ne değişir?

Sertleştirilmiş sunucularda genellikle PasswordAuthentication no ayarı bulunur. sshd_config belgesine göre bu ayar parola ile girişi kapatır, yalnızca anahtar tabanlı yöntemler kalır. Güvenlik açısından doğru bir tercihtir, ancak anahtarınız çalışmadığında sizi kapıda bırakır.

Bu durumda yapabileceğiniz üç güvenli yol vardır:

• Hosting ya da bulut panelindeki web konsolu veya kurtarma erişimi ile sunucuya girin ve anahtarı düzeltin.
• Başka bir yönetici hesabınız varsa onunla bağlanıp authorized_keys dosyasını güncelleyin.
• Sağlayıcı desteğine başvurun; kimlik doğrulaması sonrası erişim yöntemlerini onlar yönlendirir.

Kuralları aşmanın bir yolu olarak başkasının hesabını ya da tanımadığınız kişilerin "erişim geri verme" hizmetlerini kullanmayın. Bu yöntemler hem güvenlik hem hukuk açısından risklidir ve çoğu zaman başka bir sorun yaratır.

Kendinizi sunucudan dışarıda bırakmamak için ne yapmalısınız?

Anahtar ya da sshd ayarı değiştirirken en büyük risk, çalışan oturumu kapatıp geri dönememektir. Kural basit: yeni ayarı test etmeden eski oturumu kapatmayın.

1. Mevcut oturumu açık bırakın.
2. Ayarı ya da yeni anahtarı ekleyin.
3. Yeni bir terminal penceresi açın ve yeni anahtarla ayrı bir bağlantı kurun.
4. Yeni bağlantı çalışıyorsa eski oturumu kapatın.
5. Çalışmıyorsa eski oturum üzerinden değişikliği geri alın.

Ayrıca sshd yapılandırmasını değiştirdikten sonra servisi yeniden başlatmadan önce sözdizimini denetleyin. sshd belgesi bunun için test modunu (-t bayrağı) tanımlar. Böylece hatalı bir satır yüzünden servis ayağa kalkmamaz.

Sunucu sertleştirme adımlarının tamamı için Linux swap ve SSH güvenliği yazımıza bakabilirsiniz. Yeni bir uygulamayı canlıya alıyorsanız VPS üzerinde Next.js yayınlama rehberimiz de aynı bağlantı mantığını kullanır.

Hangi SSH anahtar türünü seçmelisiniz?

Yeni bir anahtar üretiyorsanız ed25519 türü günümüzde yaygın ve önerilen tercihtir. OpenSSH belgesi bu türü modern bir imza algoritması olarak listeler, GitHub Docs da yeni anahtar üretme adımlarında ed25519 örneği verir. Eski sistemlerle uyum gerekiyorsa RSA kullanılabilir, ancak anahtar uzunluğu için güncel öneriyi resmi belgeden kontrol edin.

ssh-keygen -t ed25519 -C "isim@example.com"

• Komut, anahtar çiftini varsayılan klasörde oluşturur ve sizden bir parola belirlemenizi ister.
• Parola koymak, laptop çalınsa bile anahtarın tek başına kullanılmasını zorlaştırır.
• Yorum kısmına (-C) e-posta ya da makine adı yazmak, ileride anahtarları ayırt etmenizi sağlar.
• Çok eski bir sunucu ed25519 anahtarını tanımıyorsa önce sunucunun OpenSSH sürümünü güncellemeyi düşünün.

Hangi neden hangi belirtiye ve çözüme denk gelir?

Aşağıdaki tablo ssh permission denied publickey hatası için teşhis sırasını özetler. En olası neden üstte, en az olası neden altta yer alır.

Özel anahtarınızı neden kimseyle paylaşmamalısınız?

Public anahtar kapı kilidi gibidir; istediğiniz kadar kişiye verebilirsiniz. Özel anahtar ise o kilidi açan fiziksel anahtardır. Birine özel anahtarı gönderirseniz, o kişi sizin adınıza sunucuya girebilir.

• Destek yazışmalarında, sohbet pencerelerinde ya da yapay zeka araçlarında özel anahtar içeriğini yapıştırmayın.
• Hata çıktısı paylaşırken ssh -v satırlarında anahtar içeriği olmadığını kontrol edin. Dosya yolu paylaşmak sorun değildir, dosya içeriği sorundur.
• Anahtarın sızdığından şüphelenirseniz yeni bir çift üretin, sunucudan ve GitHub'dan eskisini kaldırın.
• Anahtarları depo içine commit etmeyin; yanlışlıkla yaptıysanız anahtarı değiştirmeniz gerekir.

Kısacası özel anahtarı parola gibi koruyun. Parola yöneticisi kullanmıyorsanız ücretsiz şifre oluşturucu aracımızla anahtar parolanız için güçlü bir değer üretebilirsiniz.

ssh-copy-id ile anahtarı sunucuya güvenle nasıl eklersiniz?

Public anahtarı elle kopyalamak hata kaynağıdır. Bu nedenle erişiminiz hâlâ varsa ssh-copy-id aracını kullanın. OpenSSH ile birlikte gelen bu araç, anahtarı doğru dosyaya ve doğru izinlerle ekler.

ssh-copy-id -i ~/.ssh/id_ed25519.pub kullanici@example.com

• -i bayrağı hangi public anahtarın ekleneceğini söyler.
• Araç, sunucuda yoksa .ssh klasörünü ve authorized_keys dosyasını oluşturur.
• Komut sonrası yeni bir terminalde bağlantıyı deneyin, eski oturumu henüz kapatmayın.
• Aracı kullanamıyorsanız anahtarı tek satır halinde dosyanın sonuna ekleyin. Satır sonunun bozulmadığını kontrol edin.

Böylece elle yapılan izin ve satır hataları ortadan kalkar. Ayrıca aracın çıktısı, kaç anahtarın eklendiğini de gösterir.

Yeni bir bilgisayarda bu hata neden sık görülür?

Örnek senaryo: bir geliştirici laptopunu değiştirir, projeleri kopyalar ve ilk git pull komutunda hatayı görür. Eski bilgisayardaki özel anahtar yeni makinede yoktur. GitHub hesabında yalnızca eski cihazın public anahtarı kayıtlıdır.

Bu durumda iki seçeneğiniz var. Birincisi, eski anahtarı güvenli bir yolla taşımak. İkincisi, yeni cihazda yeni bir anahtar çifti üretip public kısmı hesaba eklemek. İkinci yol genellikle daha temizdir, çünkü her cihazın kendi anahtarı olur ve kaybolan bir cihazın anahtarını tek başına kaldırabilirsiniz.

1. Yeni cihazda ssh-keygen -t ed25519 ile anahtar üretin.
2. Public dosyanın içeriğini GitHub hesabınıza ya da sunucudaki authorized_keys dosyasına ekleyin.
3. Anahtarı ssh-add ile agent içine yükleyin.
4. ssh -T git@github.com ile test edin.
5. Eski cihaz artık kullanılmıyorsa onun anahtarını hesaptan silin.

CI/CD hattında ya da otomatik dağıtımda hata neden çıkar?

Otomasyon araçları ayrı bir bilgisayar gibi çalışır ve sizin anahtarınıza erişemez. Bu nedenle dağıtım hattında aynı hatayla sık karşılaşırsınız. Çoğu zaman anahtar hattın gizli değişkenlerine eklenmemiştir ya da yanlış biçimde eklenmiştir.

• Hat için ayrı bir anahtar çifti üretin; kişisel anahtarınızı hatta yüklemeyin.
• Özel anahtar metninin satır sonlarını koruyun. Tek satıra sıkıştırdığınız anahtar geçersiz olur.
• Public kısmı sunucuya ya da depoya salt okunur erişimle ekleyin. GitHub Docs bu amaç için depo bazlı dağıtım anahtarlarını (deploy key) anlatır.
• İlk bağlantıda ssh parmak izi onayı bekler; bu bekleme hattı kilitleyebilir.

Yayın sürecinizi otomatikleştirmek zorlaştıysa, yapay zeka otomasyon hizmetlerimiz iş akışlarınızı sadeleştirmeniz için bir seçenek olabilir.

Anahtar parolasını unutursanız ne olur?

Parola, özel anahtar dosyasını şifreler. Parolayı unutursanız o dosyayı geri açmanın bir yolu yoktur; bu bilinçli bir güvenlik özelliğidir. Parolayı denemek için kaba kuvvet araçlarına yönelmek zaman kaybıdır ve sistemleri zorlamak sayılabilir.

Doğru yol yeni bir anahtar çifti üretmektir. Sonra yeni public anahtarı sunucuya ya da GitHub hesabına ekler, eskisini kaldırırsınız. Bunu yapmak için sunucuya başka bir yoldan, örneğin panel konsolu üzerinden erişiminiz olması gerekir.

Teşhis sırası neden en olası nedenden başlar?

Rastgele denemek iki sorun yaratır. Birincisi zaman kaybettirir. İkincisi, her denemede ayarı biraz daha bozarak asıl nedeni gizler. Bu yüzden önce geri alınabilir kontrolleri yapın, sonra ayar değiştirin.

Kullanıcı adı kontrolü hiçbir şeyi değiştirmez. ssh -v yalnızca okur. ssh-add -l yalnızca listeler. Bu üç adım nedenlerin büyük kısmını gösterir. Dosya izinlerini değiştirmek ya da sshd ayarlarına dokunmak ise daha sonraya kalır, çünkü bu adımlar riskli olabilir.

Bu sıra aynı zamanda öğrenmeyi de kolaylaştırır. Her adımda bir sonraki adıma geçmeden önce bir soruya net cevap alırsınız: anahtar sunuluyor mu, sunucu anahtarı tanıyor mu, izinler uygun mu. Böylece hata mesajı sizi korkutmaz, yol gösteren bir ipucuna dönüşür.

Bu hatada en sık yapılan yanlışlar neler?

Sahada gördüğümüz tekrarlayan yanlışlar şunlardır. Her birini bilmek, teşhisi belirgin biçimde hızlandırır.

• Özel anahtarı sunucuya, public anahtarı kendi bilgisayarına koymak. Dosyaları ters yerleştirirsiniz ve hiçbir şey çalışmaz.
• Dosya adını değiştirip config içinde tanımlamayı unutmak.
• GitHub'da HTTPS adresini kullanıp SSH anahtarını suçlamak.
• Anahtarı root hesabına ekleyip başka kullanıcıyla bağlanmak.
• Hatayı tekrar tekrar denemek yerine ssh -v çıktısını okumamak.
• Çalışan oturumu kapatıp yeni ayarı sonradan test etmek.

Bu hataların çoğu dikkatle bakınca birkaç dakikada çözülür. Ancak acele ederken göz ardı edilirler. Bu nedenle sakin kalıp teşhis sırasını izlemek, deneme yanılmadan daha hızlı sonuç verir.

Sunucu tarafında reddin gerçek nedenini nasıl okursunuz?

İstemci çıktısı yalnızca "reddedildi" der, nedenini söylemez. Sebep ise sunucunun kayıt dosyasındadır. Sunucuya başka bir yoldan girebiliyorsanız, kimlik doğrulama kayıtlarını okuyun; birçok Linux dağıtımında bu kayıt auth.log ya da journalctl çıktısında durur.

Kayıtta tipik olarak şu cümlelerin benzerlerini görürsünüz:

• Kullanıcının bilinmediğini söyleyen bir satır, yani yanlış kullanıcı adı demektir.
• Yetkilendirme dosyasının izinlerine işaret eden bir satır, yani StrictModes kaydı reddetmiştir.
• Anahtarın kabul edilmediğini söyleyen bir satır, yani public anahtar dosyada yoktur ya da biçimi bozuktur.
• Kullanıcı hesabının kilitli olduğunu söyleyen bir satır, yani hesabı önce açmanız gerekir.

Tam metinler dağıtıma ve sürüme göre değişebilir, bu yüzden birebir cümleye yaslanmayın. Önemli olan, kaydın size istemci tarafında göremediğiniz kesin nedeni vermesidir. Ayrıca sunucuyu geçici olarak daha ayrıntılı kayıt moduna almak gerekirse sshd_config belgesindeki LogLevel seçeneğini inceleyin.

Hata sürüyorsa hangi son kontrolleri yapmalısınız?

Yukarıdaki adımları sırayla uyguladıysanız ve hata devam ediyorsa birkaç az görülen nedene bakın. Bunlar nadirdir, ama bu yüzden gözden kaçar.

• Sunucuda PubkeyAuthentication seçeneğini kapatmış olabilirsiniz. sshd_config belgesi bu seçeneği tanımlar.
• AuthorizedKeysFile seçeneğini varsayılan dışı bir yola çevirmiş olabilirsiniz, bu durumda anahtarınız yanlış dosyada kalır.
• Kullanıcının hesabı kilitli ya da kabuğu (shell) geçersiz olabilir.
• Sistem saati veya SELinux gibi ek güvenlik katmanları ev dizini bağlamını bozmuş olabilir.
• Sunucuda kayıt (log) dosyasını okuyabiliyorsanız, sshd'nin neden reddettiğini orada net görürsünüz.

Sunucu loglarına erişiminiz varsa en hızlı yol budur. Çünkü sshd çoğu zaman reddin gerçek nedenini yazar; izin sorunu mu, anahtar bulunamadı mı, kullanıcı mı kilitli, hepsi ayrı mesajla görünür.

Kalıcı önlem için hangi kontrol listesini kullanabilirsiniz?

Aynı hatayı tekrar yaşamamak için küçük bir alışkanlık seti yeterlidir. Ekip içinde de aynı listeyi paylaşabilirsiniz.

• Her cihaz için ayrı anahtar üretin ve anahtara anlamlı bir yorum ekleyin.
• Anahtarlara parola koyun ve ssh-agent kullanın.
• ~/.ssh/config dosyasında her sunucu için Host, User ve IdentityFile tanımlayın.
• Sunucuda parola girişini kapatmadan önce anahtarla girişi ikinci bir oturumda test edin.
• Kullanılmayan ve eski anahtarları authorized_keys ve GitHub hesabından düzenli olarak temizleyin.
• Çalışan ayrıldığında ya da cihaz kaybolduğunda ilgili anahtarı hemen kaldırın.

Bu liste küçük bir ekip için bile fark yaratır. Ayrıca yazılım projelerinde yaşanan komşu sorunlar için Git merge conflict yazımıza ve Python ModuleNotFoundError rehberimize bakabilirsiniz.

Bu konuda profesyonel destek ne zaman gerekir?

Tek bir sunucuda anahtar eklemek birkaç dakikalık iştir. Ancak onlarca sunucu, birden fazla ekip üyesi ve dağıtım hattı (CI/CD) olduğunda anahtar yönetimi ayrı bir iş haline gelir. Bu noktada yetkilendirme düzeni, anahtar rotasyonu ve erişim kaydı gibi konular önem kazanır.

Böyle bir altyapıyı kurmak veya mevcut düzeni sadeleştirmek istiyorsanız özel yazılım geliştirme hizmetimiz kapsamında teklif isteyebilirsiniz. Önce ihtiyacınızı dinler, ardından uygun kapsamı yazılı olarak sunarız.

Tek seferlik bir hata için bu yazıdaki teşhis sırası çoğu zaman yeterlidir. Çözemediğiniz bir durumda ise çıktıyı paylaşırken özel anahtar içeriğini ve sunucu adresini gizlemeyi unutmayın. Resmi kaynaklar için GitHub Docs sorun giderme sayfasını, OpenSSH ssh belgesini, sshd_config belgesini ve ssh_config belgesini inceleyin.