SSH Agent ve Anahtar Yönetimi

SSH anahtarlarını doğru kurduysanız artık sunucularınıza parola yerine kriptografik anahtar çiftiyle bağlanıyorsunuz. Ancak güvenliğin bir sonraki adımı, özel anahtarınızı bir parola (passphrase) ile korumaktır. Bunu yaptığınız anda pratik bir sorun ortaya çıkar: her git push, her ssh sunucu, her rsync komutunda o uzun parolayı yeniden yazmak zorunda kalırsınız. Günde onlarca bağlantı açan bir geliştirici veya sistem yöneticisi için bu, kısa sürede dayanılmaz bir hale gelir ve insanları anahtarlarını parolasız bırakmaya iter — ki bu da güvenliği baltalar.

İşte ssh-agent tam da bu ikilemi çözmek için vardır. Parolalı anahtarınızın kilidini oturum başına yalnızca bir kez açar, çözülmüş anahtarı bellekte güvenle tutar ve sonraki tüm bağlantılarda parola sormadan kimlik doğrulamayı sizin adınıza halleder. Bu rehberde ajanı başlatmayı, ssh-add ile anahtar yüklemeyi, birden çok anahtarı ~/.ssh/config üzerinden düzenlemeyi, agent forwarding'in ne zaman güvenli olduğunu ve GitHub/GitLab ile günlük pratiği baştan sona ele alacağız. Anahtar oluşturma ve temel bağlantı güvenliğini henüz gözden geçirmediyseniz, önce SSH bağlantısı ve güvenliği yazısına göz atmanızı öneririm.

SSH Agent Nedir ve Nasıl Çalışır#

ssh-agent, arka planda çalışan küçük bir programdır. Görevi, çözülmüş (kilidi açılmış) özel anahtarlarınızı bellekte tutmak ve bir SSH bağlantısı gerektiğinde kimlik doğrulamayı vekaleten yapmaktır. Kritik nokta şudur: ajan, özel anahtarınızın kendisini asla ağa veya ssh istemcisine kopyalamaz. Bunun yerine, sunucunun gönderdiği kimlik doğrulama "meydan okumasını" (challenge) bellekteki anahtarla imzalar ve yalnızca imzayı geri döndürür. Anahtar materyali sürecin belleğinden hiç çıkmaz.

Bu tasarım iki büyük fayda sağlar. Birincisi, parolanızı oturum boyunca yalnızca bir kez girersiniz; ajan çözülmüş anahtarı tuttuğu sürece tüm komutlar sessizce çalışır. İkincisi, agent forwarding sayesinde uzak bir sunucuya bağlıyken oradan başka bir sunucuya, özel anahtarınızı o aracı makineye hiç kopyalamadan, atlayarak bağlanabilirsiniz. Ajanla istemci arasındaki iletişim, SSH_AUTH_SOCK ortam değişkeninin işaret ettiği bir Unix soketi üzerinden yürür — bu soketin yolunu bilmek ve okuma iznine sahip olmak, ajanın tuttuğu anahtarları kullanabilmek demektir. Bu ayrıntıyı agent forwarding bölümünde tekrar ele alacağız, çünkü güvenlik açısından merkezî bir noktadır.

ssh-agent'ı Başlatma#

Çoğu masaüstü ortamı (GNOME, KDE, macOS) oturum açtığınızda sizin için bir ssh-agent örneğini otomatik başlatır ve SSH_AUTH_SOCK değişkenini sizin adınıza ayarlar. Ajanın çalışıp çalışmadığını hızlıca kontrol edebilirsiniz:

# Ajanın soketine işaret eden değişkeni yazdır
echo "$SSH_AUTH_SOCK"

# Ajan çalışıyor ve boşsa, "The agent has no identities." döner
ssh-add -l

Eğer SSH_AUTH_SOCK boşsa veya ssh-add -l "Could not open a connection to your authentication agent" hatası veriyorsa, ajanı elle başlatmanız gerekir. Sunucularda, konteynerlerde veya sade bir SSH oturumunda genellikle durum budur:

# Ajanı başlat ve gerekli ortam değişkenlerini geçerli kabuğa aktar
eval "$(ssh-agent -s)"
# Örnek çıktı:
# Agent pid 48213

Buradaki eval önemlidir: ssh-agent -s komutu ajanı başlatır ve SSH_AUTH_SOCK ile SSH_AGENT_PID değişkenlerini ayarlayan kabuk komutlarını metin olarak basar. eval bu metni geçerli kabukta çalıştırır; onsuz değişkenler yalnızca ekrana yazılır ama kabuğunuza işlenmez.

Her yeni terminal oturumunda elle başlatmak istemiyorsanız, kabuk yapılandırma dosyanıza (~/.bashrc veya ~/.zshrc) çalışan bir örneği yeniden kullanan küçük bir parça ekleyebilirsiniz:

# ~/.bashrc — ajanı yalnızca çalışmıyorsa başlat, çalışıyorsa yeniden bağlan
if [ -z "$SSH_AUTH_SOCK" ] || ! ssh-add -l >/dev/null 2>&1; then
  eval "$(ssh-agent -s)" >/dev/null
fi

macOS kullanıyorsanız işletim sistemi Anahtar Zinciri (Keychain) ile entegre bir ajan sunar; parolanızı bir kez girip Anahtar Zincirine kaydettirebilir, sonra her açılışta otomatik yüklenmesini sağlayabilirsiniz. Linux'ta keychain adında benzer bir yardımcı paket vardır; oturumlar arasında tek bir ajanı paylaşarak her terminalde yeniden parola sorulmasını önler.

ssh-add ile Anahtar Yükleme#

Ajan çalışır durumdayken sıradaki adım, ona bir anahtar tanıtmaktır. Bunu ssh-add yapar. Argümansız çağrıldığında, ~/.ssh altındaki varsayılan isimli anahtarları (id_ed25519, id_rsa, id_ecdsa gibi) ekler:

# Varsayılan anahtarları yükle (parolalıysa bir kez parola sorar)
ssh-add
# Enter passphrase for /home/kullanici/.ssh/id_ed25519:
# Identity added: /home/kullanici/.ssh/id_ed25519 (kullanici@makine)

Belirli bir anahtarı yüklemek için yolunu doğrudan verirsiniz — özellikle standart dışı isim kullandığınızda gereklidir:

# Özel isimli bir anahtarı yükle
ssh-add ~/.ssh/is_sunucusu_ed25519

Ajandaki yüklü anahtarları listelemek, silmek ve yönetmek için sık kullanacağınız komutlar şunlardır:

ssh-add -l          # Yüklü anahtarların parmak izlerini (fingerprint) listele
ssh-add -L          # Yüklü anahtarların açık kısımlarını tam olarak yazdır
ssh-add -d ~/.ssh/id_ed25519   # Tek bir anahtarı ajandan çıkar
ssh-add -D          # Tüm anahtarları ajandan boşalt

Güvenlik açısından iki değerli seçenek daha vardır. -t ile bir anahtara zaman aşımı (TTL) atarsınız; süre dolunca ajan anahtarı otomatik boşaltır — dizüstü bilgisayarını ortalıkta bırakma riskine karşı iyi bir önlemdir. -c ise anahtar her kullanılmadan önce bir onay istemi (grafik ortamda) tetikler; kritik anahtarlar için "sessizce imzalama" davranışını kapatır:

# Anahtarı 1 saat (3600 sn) sonra otomatik unut
ssh-add -t 3600 ~/.ssh/id_ed25519

# Her kullanımda onay iste
ssh-add -c ~/.ssh/prod_ed25519

Bir noktayı vurgulamakta fayda var: ssh-add, parolalı bir anahtarın çözülmüş halini bellekte tutar. Bu yüzden anahtarınızın parolasını sağlam tutmak hâlâ önemlidir — parola, diskteki anahtar dosyası çalınırsa devreye giren ikinci savunma hattıdır, ajan ise yalnızca çalışma anındaki rahatlığı sağlar.

Birden Çok Anahtarı ve ~/.ssh/config'i Yönetmek#

Gerçek hayatta çoğunlukla tek bir anahtar yetmez. İş sunucularınız için bir anahtar, kişisel projeleriniz için başka bir anahtar, GitHub için ayrı, bir müşterinin altyapısı için bir başkası... Hepsini ajana yükleyebilirsiniz, ancak asıl düzen ~/.ssh/config dosyasında kurulur. Bu dosya, hangi hedefe bağlanırken hangi anahtarın kullanılacağını IdentityFile ile netleştirir ve size kısa takma adlar (Host alias) verir.

# ~/.ssh/config

# Kişisel VDS sunucunuz — kısa "vds" takma adıyla bağlanın
Host vds
    HostName 203.0.113.10
    User root
    IdentityFile ~/.ssh/kisisel_ed25519
    IdentitiesOnly yes

# İş sunucusu — farklı kullanıcı ve anahtar
Host is-web
    HostName web01.sirket.local
    User deploy
    Port 2222
    IdentityFile ~/.ssh/is_sunucusu_ed25519
    IdentitiesOnly yes

# GitHub — kendi anahtarıyla
Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/github_ed25519
    IdentitiesOnly yes

Buradaki en kritik satır IdentitiesOnly yes ifadesidir. Bu satır olmadan SSH istemcisi, ajanınızdaki tüm anahtarları sırayla sunucuya sunmaya çalışır. Sunucuların çoğunda ard arda başarısız kimlik doğrulama denemelerinde bir üst sınır (MaxAuthTries, genellikle 6) vardır; ajanınızda çok sayıda anahtar varsa, hedefin beklediği anahtara sıra gelmeden "Too many authentication failures" hatasıyla bağlantı kesilebilir. IdentitiesOnly yes, istemciye "bu Host için yalnızca burada belirttiğim IdentityFile'ı kullan" der ve bu sorunu tümden ortadan kaldırır.

Aşağıdaki tablo, yaygın senaryolarda hangi yaklaşımın uygun olduğunu özetliyor:

Bu düzeni bir kez kurduğunuzda ssh vds, ssh is-web gibi kısa komutlar yeterli olur; uzun IP'leri, port numaralarını ve -i anahtar_yolu bayraklarını her seferinde yazmaktan kurtulursunuz. Bu yaklaşım aynı zamanda birden çok sunucu yönettiğiniz sunucu yönetimi süreçlerinde hataları da azaltır — yanlış anahtarla yanlış sunucuya bağlanma ihtimali düşer.

Aynı Sağlayıcıda Birden Çok Hesap#

Sık karşılaşılan özel bir durum, aynı Git sağlayıcısında (örneğin GitHub) hem iş hem kişisel hesabınızın olmasıdır. GitHub bir SSH anahtarını tek bir hesaba bağlar, dolayısıyla iki hesap için iki farklı anahtar kullanmanız ve istemciye hangisini ne zaman kullanacağını bildirmeniz gerekir. Çözüm, ~/.ssh/config içinde aynı HostName'e işaret eden iki farklı takma ad tanımlamaktır:

# Kişisel GitHub hesabı
Host github-kisisel
    HostName github.com
    User git
    IdentityFile ~/.ssh/github_kisisel_ed25519
    IdentitiesOnly yes

# İş GitHub hesabı
Host github-is
    HostName github.com
    User git
    IdentityFile ~/.ssh/github_is_ed25519
    IdentitiesOnly yes

Artık depoyu klonlarken veya remote ayarlarken gerçek github.com yerine takma adı kullanırsınız:

# Kişisel hesapla klonla
git clone git@github-kisisel:kullaniciadi/kisisel-proje.git

# Var olan bir deponun remote'unu iş takma adına çevir
git remote set-url origin git@github-is:sirket/urun.git

Böylece her depo, remote URL'sindeki takma ada göre otomatik olarak doğru anahtarı kullanır. Bu ayrımın Git tarafındaki karşılığını ve user.name/user.email gibi depo-bazlı ayarları Git temelleri yazısında daha ayrıntılı bulabilirsiniz.

Agent Forwarding Ne Zaman Güvenli#

Agent forwarding, bir sunucuya SSH ile bağlıyken o sunucudan başka bir hedefe, yerel ajanınızın anahtarlarını kullanarak bağlanmanızı sağlar. Özel anahtar aracı sunucuya hiç kopyalanmaz; imzalama istekleri, forward edilen soket üzerinden sizin bilgisayarınızdaki ajana geri iletilir. Kâğıt üzerinde çok kullanışlıdır — örneğin bir sıçrama (bastion/jump) sunucusuna bağlanıp oradan iç ağdaki makinelere geçmek istediğinizde.

Ancak burada ciddi bir güvenlik uyarısı var. Forwarding'i açtığınızda (ssh -A veya config'de ForwardAgent yes), bağlandığınız sunucuda ajan soketinize erişim doğar. O sunucuda root yetkisine sahip biri — kötü niyetli bir yönetici ya da sunucuyu ele geçirmiş bir saldırgan — siz bağlı olduğunuz sürece SSH_AUTH_SOCK soketini kullanıp sizin adınıza erişebildiğiniz tüm sistemlere kimlik doğrulaması yapabilir. Anahtarınızı çalamaz ama siz bağlıyken onu kullanabilir. Bu yüzden altın kural nettir: agent forwarding'i yalnızca tam olarak güvendiğiniz sunuculara açın, paylaşımlı hosting ya da güvenmediğiniz üçüncü taraf makineler için asla açmayın.

Forwarding'i her zaman değil, yalnızca gerektiğinde açmak için config'de belirli bir Host'a bağlayın; global ssh -A alışkanlığından kaçının:

# Yalnızca bu güvenilir sıçrama sunucusu için forwarding aç
Host bastion
    HostName bastion.sirket.local
    User jump
    ForwardAgent yes

# Diğer tüm hedefler için forwarding kapalı kalır (varsayılan)

Çoğu durumda agent forwarding'e hiç ihtiyacınız olmadan aynı sonucu daha güvenli biçimde ProxyJump ile alabilirsiniz. ProxyJump, aracı sunucuyu yalnızca bir tünel olarak kullanır; kimlik doğrulama uçtan uca sizin makinenizle nihai hedef arasında olur ve ajan soketi aracı makineye hiç açılmaz:

# Bastion üzerinden iç sunucuya, forwarding gerektirmeden atla
ssh -J [email protected] [email protected]ç.local

# Kalıcı hale getir
Host web01
    HostName web01.ic.local
    User deploy
    ProxyJump bastion

Pratik öneri: Mümkün olan her yerde ProxyJump'ı tercih edin, agent forwarding'i yalnızca ProxyJump'ın çözmediği (örneğin uzak sunucudan git işlemleri yapmanız gereken) durumlarda ve yalnızca güvenilir makinelerde kullanın.

GitHub ve GitLab ile Pratik Kullanım#

Ajan kurulumunun günlük hayatta en görünür faydası Git iş akışlarında ortaya çıkar. Parolalı bir anahtarınız varsa ve ajan çalışıyorsa, gün boyunca yaptığınız onlarca git push ve git pull işlemi parola sormadan akıp gider. Kurulumun doğru olduğunu doğrulamak için sağlayıcının test komutunu kullanın:

# GitHub bağlantısını doğrula
ssh -T [email protected]
# Hi kullaniciadi! You've successfully authenticated, ...

# GitLab için
ssh -T [email protected]

Yeni bir anahtar üretip sağlayıcıya eklemek isterseniz akış şu şekildedir. Modern öneri, RSA yerine daha kısa ve hızlı olan Ed25519'dur:

# Parolalı Ed25519 anahtarı üret (parola sorar — mutlaka bir parola girin)
ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/github_ed25519

# Açık anahtarı panoya kopyalayıp GitHub/GitLab > Settings > SSH Keys'e yapıştırın
cat ~/.ssh/github_ed25519.pub

# Ajana ekleyin ki her push'ta parola sormasın
ssh-add ~/.ssh/github_ed25519

Sunucularınızda otomatik dağıtım (deploy) yapan CI süreçleri veya cron görevleri için ise farklı bir yaklaşım gerekir: bunlarda insan olmadığı için ajan parolayı interaktif soramaz. Bu tür otomasyonlarda ya parolasız ama yetkisi dar bir "deploy key" (yalnızca ilgili depoya, yalnızca okuma iznine sahip) kullanılır ya da CI platformunun kendi güvenli sır (secret) deposu ile anahtar sağlanır. Kişisel, geniş yetkili parolalı anahtarınızı asla bir sunucuya veya CI ortamına parolasız kopyalamayın — o anahtar orada sızarsa erişebildiğiniz her yer risk altına girer.

Güvenli Anahtar Saklama ve Parolalı Anahtar Önerisi#

Bu rehber boyunca tekrarladığımız ilkeyi burada netleştirelim: özel anahtarlarınız her zaman parolalı olsun. ssh-agent, parolayı oturumda bir kez girip sonra hiç sormamayı sağladığı için, "rahatlık uğruna parolasız anahtar" bahanesi artık geçerli değildir. Ajan sayesinde hem güvenliği hem de konforu aynı anda elde edersiniz. Var olan parolasız bir anahtara sonradan parola eklemek de mümkündür:

# Var olan bir anahtara parola ekle veya değiştir
ssh-keygen -p -f ~/.ssh/id_ed25519

Anahtar dosyalarınızın disk izinleri de en az parola kadar önemlidir. SSH istemcisi, izinleri fazla açık olan özel anahtarları güvenlik gereği reddeder. Doğru izinler şöyle olmalıdır:

chmod 700 ~/.ssh              # Dizini yalnızca siz görün
chmod 600 ~/.ssh/id_ed25519   # Özel anahtar yalnızca sizde okuma/yazma
chmod 644 ~/.ssh/id_ed25519.pub   # Açık anahtar herkese okunabilir olabilir
chmod 600 ~/.ssh/config       # Yapılandırma da yalnızca sizde

Anahtar hijyeni için birkaç ek öneri: özel anahtarınızın yedeğini yalnızca şifreli bir kasada (parola yöneticisi, şifreli disk) tutun ve asla e-posta/sohbet/bulut senkronizasyonu ile düz metin taşımayın; bir çalışanın ayrılması ya da bir cihazın kaybolması gibi durumlarda ilgili açık anahtarları sunuculardan ve Git sağlayıcılarından hemen kaldırın (anahtar rotasyonu); ve yüksek riskli erişimler için donanım güvenlik anahtarı (FIDO2/ed25519-sk) veya -t ile TTL'li ajan yüklemesini değerlendirin. Anahtarlarınızın bulunduğu sunucuların kendisini de düzenli yedeklemeyi ihmal etmeyin — yedekleme çözümleri bir anahtar veya konfigürasyon kaybında sizi büyük dertten kurtarır.

Sıkça Sorulan Sorular#

ssh-agent ile parolalı anahtar arasındaki fark nedir?#

Parola, diskteki özel anahtar dosyanızı koruyan şifredir; dosya çalınsa bile parolayı bilmeyen biri anahtarı kullanamaz. ssh-agent ise bu parolayı oturumda bir kez girdikten sonra çözülmüş anahtarı bellekte tutan yardımcı programdır. İkisi rakip değil, birbirini tamamlayan katmanlardır: parola diskteki savunmadır, ajan ise çalışma anındaki konforu sağlar. En doğru kurulum, parolalı bir anahtarı ajana yüklemektir.

Her terminal açtığımda neden yeniden parola soruluyor?#

Büyük olasılıkla her terminal kendi ayrı ssh-agent örneğini başlatıyor ya da hiç ajan çalışmıyor ve anahtar her seferinde sıfırdan yükleniyordur. Çözüm, tüm terminallerin ortak tek bir ajanı paylaşmasını sağlamaktır; bunu masaüstü ortamının otomatik ajanı, macOS Anahtar Zinciri entegrasyonu veya Linux'ta keychain yardımcısı ile yaparsınız. ~/.bashrc içine çalışan bir örneği yeniden kullanan bir kontrol eklemek de bu tekrarı ortadan kaldırır.

Too many authentication failures hatası neden oluşuyor?#

Bu hata, istemcinizin sunucuya çok fazla yanlış anahtar sunmasından kaynaklanır. Ajanınızda birden çok anahtar varsa SSH bunları sırayla dener; hedefin beklediği anahtara gelmeden sunucunun MaxAuthTries sınırı dolar ve bağlantı reddedilir. Çözüm, ~/.ssh/config içinde ilgili Host için IdentityFile belirtip IdentitiesOnly yes eklemektir; böylece istemci yalnızca doğru anahtarı sunar.

Agent forwarding kullanmak güvenli mi?#

Yalnızca tam olarak güvendiğiniz sunucular için güvenlidir. Forwarding açıkken, bağlandığınız sunucuda root yetkisine sahip biri, siz bağlı olduğunuz sürece ajan soketinizi kullanıp sizin adınıza erişebildiğiniz sistemlere kimlik doğrulaması yapabilir. Bu nedenle paylaşımlı veya güvenmediğiniz makineler için asla açmayın; çoğu senaryoda daha güvenli olan ProxyJump (ssh -J) alternatifini tercih edin.

GitHub'da iki farklı hesabı aynı bilgisayarda nasıl kullanırım?#

Her hesap için ayrı bir SSH anahtarı üretip GitHub'da ilgili hesaba ekleyin, ardından ~/.ssh/config içinde aynı HostName github.com'a işaret eden iki farklı takma ad (örneğin github-is ve github-kisisel) tanımlayın; her birine ilgili IdentityFile'ı verin. Depoları klonlarken veya remote ayarlarken [email protected] yerine bu takma adları kullanırsınız, böylece her depo otomatik olarak doğru anahtarı kullanır.

ssh-add -l çıktısı boş görünüyorsa ne yapmalıyım?#

ssh-add -l "The agent has no identities" diyorsa ajan çalışıyor ama içinde yüklü anahtar yoktur; bu durumda ssh-add ~/.ssh/anahtar_adi ile anahtarınızı yükleyin. Eğer "Could not open a connection to your authentication agent" hatası alıyorsanız ajan hiç çalışmıyordur; eval "$(ssh-agent -s)" komutuyla başlatıp ardından anahtarı ekleyin. echo "$SSH_AUTH_SOCK" çıktısının boş olması da ajanın çalışmadığının işaretidir.

Kapanış#

ssh-agent ve ssh-add, güvenlik ile konfor arasındaki o eski gerilimi ortadan kaldırır: anahtarlarınızı parolalı tutarak diskte güvende bırakır, ama gün boyunca tek tek parola girmenin sıkıntısını yaşamazsınız. Buna ~/.ssh/config üzerinden düzenli bir çoklu-anahtar yönetimi, IdentitiesOnly yes disiplini ve gerektiğinde ProxyJump tercihini eklediğinizde, hem çok sayıda sunucuyu hem de birden çok Git hesabını temiz ve hatasız yönetebilirsiniz. Anahtar hijyenini, doğru dosya izinlerini ve düzenli anahtar rotasyonunu da alışkanlık haline getirin; bunlar küçük ama telafisi zor hataların önüne geçer.

Bu düzeni gerçek altyapı üzerinde kurmaya hazırsanız, Clou.TR'nin tam yetkili kök erişimi sunan sanal ve fiziksel sunucu çözümleriyle başlayabilir, tek tıkla dağıtım için VDS paketlerine göz atabilirsiniz. Birden çok sunucuyu profesyonelce yönetmek isterseniz sunucu yönetimi hizmetimiz, yükünüzü uzman ekibimize devretmenizi sağlar. Kurulumu tamamladıktan sonra temel bağlantı sertleştirmesini gözden geçirmek için SSH bağlantısı ve güvenliği rehberine, Git tarafını derinleştirmek içinse Git temelleri yazısına geçebilirsiniz.