Git permission denied (publickey) hatası nasıl çözülür? Adım adım rehber

Kısa yanıt

Git permission denied (publickey) hatası, Git’in SSH üzerinden depoya bağlanırken sunucuya gösterdiği hiçbir genel anahtarın kabul edilmediği anlamına gelir. Bağlantı sunucu tarafında reddedilir çünkü ya bilgisayarınızda hiç SSH anahtarı yok, ya anahtar GitHub/GitLab hesabınıza hiç eklenmemiş, ya da doğru anahtar ssh-agent’a yüklenmemiş.

Çözüm genellikle üç adımdan oluşur: anahtarın var olduğunu doğrulamak, genel anahtarı hesaba eklemek ve özel anahtarı ajana yüklemek.

Git permission denied (publickey) hatası neden oluşur?

SSH protokolü, parola yerine bir anahtar çiftiyle çalışır: bilgisayarınızda kalan gizli bir özel anahtar ve sunucuya/hesaba yüklediğiniz bir genel anahtar. Git bir uzak depoya [email protected]:kullanici/depo.git gibi bir SSH adresiyle bağlanmaya çalıştığında, sunucu sizden kimliğinizi kanıtlamanızı ister ve bilgisayarınız sırayla elindeki anahtarları dener. Sunucu bu anahtarlardan hiçbirini tanımıyorsa veya hiç anahtar sunulmadıysa bağlantıyı tamamen keser; terminalde gördüğünüz [email protected]: Permission denied (publickey) satırı tam olarak bu reddi bildirir.

Bu durumun ortaya çıktığı en yaygın senaryo, yeni bir bilgisayarda veya yeni bir sunucu/CI ortamında ilk kez git clone ya da git push denemektir. Yeni makinede SSH anahtar çifti hiç üretilmemiştir ya da üretilmiş ama genel anahtar henüz GitHub, GitLab veya Bitbucket hesabına kaydedilmemiştir. İkinci yaygın senaryo, anahtar mevcut olsa da ssh-agent yeniden başlatıldığında (bilgisayar kapatılıp açıldığında) anahtarın ajana tekrar yüklenmemiş olmasıdır. Üçüncü senaryo ise birden fazla proje için birden fazla SSH anahtarı kullanan geliştiricilerde görülür: Git, hangi anahtarı deneyeceğini bilmediği için varsayılan anahtarı sunar ve bu anahtar o depo için tanımlı değilse bağlantı reddedilir.

Terminaldeki tam hata mesajını okumak

Hatanın tam metni genellikle şuna benzer:

[email protected]: Permission denied (publickey).
Fatal: Could not read from remote repository.

Please make sure you have the correct access rights
And the repository exists.

Bu mesaj iki farklı olasılığı aynı anda kapsar: ya kimlik doğrulama başarısızdır (anahtar sorunu) ya da depo adresi/izinleri hatalıdır. Pratikte vakaların büyük çoğunluğu anahtar sorunudur, çünkü depo var olmayan bir adrese yönlendirildiğinde SSH genellikle farklı bir hata verir. ssh -vT [email protected] komutunu çalıştırarak bağlantının hangi aşamada ve hangi anahtarla başarısız olduğunu ayrıntılı biçimde görebilirsiniz; -v bayrağı denenen her anahtarı sırayla terminale yazdırır.

Sık görülen git permission denied (publickey) senaryoları

Durum	Tipik neden	İlk çözüm
Yeni bilgisayarda ilk git clone denemesi	Hiç SSH anahtarı üretilmemiş	ssh-keygen -t ed25519 ile anahtar oluşturun
Anahtar var ama hesaba eklenmemiş	Genel anahtar (.pub) GitHub/GitLab’a kaydedilmemiş	Anahtarı hesap ayarlarından SSH bölümüne ekleyin
ssh-add -l boş liste döndürüyor	Özel anahtar ssh-agent’a yüklenmemiş	ssh-add ~/.ssh/id_ed25519 çalıştırın
Birden fazla proje, birden fazla anahtar	Git yanlış anahtarı deniyor	~/.ssh/config dosyasında host başına IdentityFile tanımlayın
CI/CD iş akışında (GitHub Actions vb.)	Deploy key veya secret eksik/yanlış tanımlı	İlgili SSH özel anahtarını güvenli bir secret olarak ekleyin
Kendi sunucunuzda (self-hosted Git)	authorized_keys eksik veya izinler hatalı	.ssh dizini 700, authorized_keys 600 olmalı

Git permission denied (publickey) hatası nasıl çözülür?

Ki sıra, hatanın en sık görülen nedenlerini en basitten en karmaşığa doğru eler; her adımdan sonra bağlantıyı yeniden test ederseniz sorunu hangi aşamada çözdüğünüzü net biçimde görürsünüz.

1. Önce bağlantıyı Git’ten bağımsız test edin

ssh -T [email protected] komutu, herhangi bir depo işlemine girmeden doğrudan kimlik doğrulamayı dener. Yanıt “Hi kullaniciadi! You’ve successfully authenticated” şeklindeyse anahtarınız zaten çalışıyor demektir ve asıl sorun depo adresinde veya erişim izinlerinde aranmalıdır. Yanıt hâlâ Permission denied (publickey) ise sorun kesinlikle kimlik doğrulama tarafındadır ve aşağıdaki adımlarla devam edilmelidir.

2. SSH anahtarınızın var olup olmadığını kontrol edin

ls -al ~/.ssh komutuyla id_ed25519/id_ed25519.pub veya eski id_rsa/id_rsa.pub dosyalarını arayın. Hiçbiri yoksa ssh-keygen -t ed25519 -C "[email protected]" komutuyla modern ve güvenli bir anahtar çifti oluşturabilirsiniz; istenirse bir parola eklenebilir, boş bırakmak da mümkündür. Eski sistemlerde ed25519 desteklenmiyorsa -t rsa -b 4096 parametresiyle RSA anahtarı üretilebilir.

3. Genel anahtarı hesabınıza ekleyin

.pub uzantılı dosyanın içeriği (özel anahtar değil, genel anahtar) kopyalanıp platformun SSH ayarları sayfasına yapıştırılır. GitHub’da bu adres Settings → SSH and GPG keys → New SSH key’dir; GitLab ve Bitbucket’ta karşılığı benzer bir menüdür. Bu adım atlanırsa bilgisayarınızda ne kadar geçerli bir anahtar olursa olsun sunucu onu hiç tanımaz ve hata tekrar eder.

4. Özel anahtarı ssh-agent’a yükleyin

Anahtar diskte bulunması, otomatik olarak kullanılacağı anlamına gelmez. ssh-add -l komutuyla ajana hangi anahtarların yüklü olduğunu görebilirsiniz; liste boşsa veya “Could not open a connection to your authentication agent” hatası alırsanız önce eval "$(ssh-agent -s)" ile ajanı başlatıp ardından ssh-add ~/.ssh/id_ed25519 komutuyla anahtarı yükleyin. Bilgisayar her yeniden başlatıldığında bu adımın tekrarlanması gerekebilir; macOS’ta ~/.ssh/config içine UseKeychain yes eklemek bu tekrarı ortadan kaldırır.

5. Birden fazla anahtarınız varsa doğru olanı zorlayın

Birden fazla depo veya hesap için ayrı SSH anahtarları kullanan geliştiriciler, hangi anahtarın hangi host için kullanılacağını açıkça belirtmelidir. ~/.ssh/config dosyasına şuna benzer bir blok eklemek sorunu kalıcı çözer:

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

IdentitiesOnly yes satırı, SSH’ın belirtilen anahtar dışında ajandaki diğer anahtarları denemesini engeller; bu da yanlış anahtarın sunucu tarafından art arda reddedilip bağlantının tamamen kesilmesini önler.

6. Dosya izinlerini doğrulayın

OpenSSH, çok geniş izinlere sahip anahtar dosyalarını güvenlik gerekçesiyle tamamen görmezden gelir ve sessizce atlar. chmod 700 ~/.ssh ve chmod 600 ~/.ssh/id_ed25519 komutları, dizin ve özel anahtar dosyasının izinlerini beklenen değerlere getirir. Kendi sunucunuza bağlanıyorsanız sunucu tarafındaki ~/.ssh/authorized_keys dosyasının da 600, ~/.ssh dizininin ise 700 olması ve her ikisinin de bağlanan kullanıcıya ait olması gerekir; aksi halde sunucu, dosya doğru olsa da izin hatasından dolayı anahtarı okumayı reddeder.

Deploy key ve CI/CD ortamlarında bu hata neden çıkar?

GitHub Actions, GitLab CI veya başka bir otomasyon aracı bir depoya SSH üzerinden erişmeye çalıştığında aynı hata farklı bir sebeple ortaya çıkar: ortamın kendi SSH anahtarı yoktur, çünkü her çalıştırmada temiz bir konteyner başlatılır. Çözüm, depoya özel bir “deploy key” üretip bunu depo ayarlarına salt okunur veya yazma izniyle eklemek, özel anahtarı ise CI aracının güvenli secret deposuna (örneğin GitHub Actions’ta secrets.DEPLOY_KEY) kaydetmektir. İş akışı dosyasında bu secret, çalışma anında ~/.ssh/id_ed25519 konumuna yazılıp izinleri 600 olarak ayarlanmalıdır; aksi halde aynı izin kısıtı burada da devreye girer ve anahtar sessizce reddedilir.

Kendi sunucunuzda (self-hosted Git) özel durum

GitHub veya GitLab gibi barındırılan platformlardan farklı olarak, kendi sunucunuzda çalışan bir Git deposuna bağlanırken hatanın kökeni genellikle sizin tarafınızdadır. Bu senaryoda sunucudaki ilgili kullanıcının ev dizininde ~/.ssh/authorized_keys dosyasının bulunması ve bağlanmak istediğiniz genel anahtarın bu dosyaya eklenmiş olması gerekir. Dosya hiç yoksa oluşturulmalı, izinleri 600 olmalı ve üst dizin olan ~/.ssh 700 olmalıdır; SELinux etkin sunucularda güvenlik bağlamının (security context) doğru olması da gerekebilir. Sunucu günlüklerinde (/var/log/auth.log veya /var/log/secure) “Authentication refused: bad ownership or modes” gibi bir satır görürseniz sorun kesinlikle izin veya sahiplik hatasıdır.

Sık yapılan hatalar

En sık yapılan hata, genel anahtar (.pub uzantılı) yerine yanlışlıkla özel anahtarın içeriğini hesaba yapıştırmaya çalışmaktır; platformlar bunu kabul etmez ve kafa karıştırıcı bir hata döndürür. İkinci yaygın hata, SSH adresi yerine HTTPS adresiyle klonlanmış bir depoda SSH anahtarı sorunlarını çözmeye çalışmaktır; bu durumda git remote -v ile adresi kontrol etmek ve gerekirse git remote set-url origin [email protected]:kullanici/depo.git ile SSH’a geçmek gerekir. Üçüncü hata, sudo ile Git komutlarını çalıştırmaktır; sudo farklı bir kullanıcının ev dizinini ve dolayısıyla farklı bir ~/.ssh klasörünü kullanır, bu da anahtarın “bulunamamasına” yol açar.

Kontrol listesi

Önce ssh -T [email protected] ile kimlik doğrulamayı Git’ten bağımsız test edin. Ardından ls -al ~/.ssh ile bir anahtar çiftinin var olduğunu doğrulayın; yoksa ssh-keygen ile oluşturun. Genel anahtarın platform hesabınıza eklendiğini ve ssh-add -l çıktısında özel anahtarın ajana yüklü olduğunu kontrol edin. Birden fazla anahtarınız varsa ~/.ssh/config içinde host başına IdentityFile tanımlayın. Son olarak ~/.ssh dizininin 700, özel anahtar dosyasının 600 izinli olduğunu ve sudo kullanmadığınızı teyit edin.

Sonraki adım

Git permission denied (publickey) hatası korkutucu görünse de temelde basit bir kimlik doğrulama eksikliğidir ve yukarıdaki adımlar izlendiğinde çoğu durumda birkaç dakika içinde çözülür. Ekibinizin geliştirme ortamlarını, SSH anahtar yönetimini ve CI/CD boru hatlarını daha güvenli ve sürdürülebilir bir temele oturtmak isterseniz, grup şirketimiz Web Tasarım Ofisi yazılım altyapısı ve kod yönetimi süreçlerinde uçtan uca destek sağlıyor.

Sürüm kontrolü ve otomasyon süreçlerinizi kapsayan projeleri profesyonel bir ekiple hayata geçirmek için özel yazılım hizmetimizi inceleyebilir ya da bizimle iletişime geçebilirsiniz. Bu hatayı aştıktan sonra push işlemi sırasında karşılaşabileceğiniz farklı bir engeli ise git push rejected hatası nasıl çözülür rehberimizde ele alıyoruz; günlük sunucu ve SSH kullanımına dair temel komutlara SSH ve temel Linux komutları rehberimizden ulaşabilirsiniz.

Kaynaklar

• GitHub Docs, Error: Permission denied (publickey), hatanın resmî açıklaması ve GitHub’ın önerdiği adım adım çözüm yolu