SSH Agent Forwarding: VPS’te Güvenli Git Erişimi

VPS üzerinde çalışan bir deploy betiği özel Git deposundan kod çekemiyor olabilir. İlk akla gelen çözüm, yerel özel SSH anahtarını sunucuya kopyalamaktır. Bu yaklaşım çalışsa bile anahtarın yedeği, izinleri, rotasyonu ve sunucu ele geçirilirse oluşturacağı risk sizin sorumluluğunuzda kalır.

SSH agent forwarding farklı bir yol sunar: SSH istemciniz, yerel makinede çalışan agent’a ait soketi oturum üzerinden VPS’e yönlendirir. VPS, özel anahtarın içeriğini görmeden imzalama isteğini bu agent’a iletebilir. Bu yöntem anahtarı kopyalamama hedefini karşılar; VPS’i otomatik olarak güvenilir hale getirmez.

SSH agent forwarding nasıl çalışır?

SSH agent, özel anahtar dosyasını doğrudan kullanan değil, bu anahtarla yapılacak kriptografik imzalama işlemlerini yöneten bir arka plan sürecidir. Anahtarınız yerel bilgisayarınızdaki agent’a eklendiğinde SSH istemcisi, uzak bağlantı için gereken imzalama taleplerini agent’a gönderir.

Forwarding etkin olduğunda uzak oturumda genellikle SSH_AUTH_SOCK adlı ortam değişkeni görünür. Bu değişken, uzak sistemdeki geçici bir Unix soketini gösterir. Soket üzerinden gönderilen imzalama talebi SSH bağlantısı aracılığıyla yerel agent’a taşınır; imzalı yanıt VPS’e döner.

Bu akışta özel anahtarın kendisi VPS’e kopyalanmaz. Ancak ele geçirilmiş veya kötü amaçlı bir VPS, açık SSH oturumu boyunca agent’a imzalama talepleri gönderebilir. Anahtarı okuyamasa bile anahtarınızın yetkili olduğu Git hesabı ya da başka bir servis adına bazı işlemleri tetiklemeye çalışabilir.

Hangi erişim modelini seçmelisiniz?

Karar, Git işleminin nerede çalışacağına bağlıdır. VPS yalnızca bağlantı için bir sıçrama noktasıysa ProxyJump çoğu zaman daha dar bir modeldir. Git komutunu kendi bilgisayarınızda çalıştırırsınız; SSH bağlantısı VPS üzerinden hedef Git sunucusuna ulaşır. VPS’e agent soketi açılmaz ve VPS’in Git hesabınız adına imza istemesi gerekmez.

Git komutu gerçekten VPS üzerinde çalışacaksa, örneğin sunucudaki bir deploy betiği git fetch veya git clone çalıştırıyorsa, iki yaygın seçenek vardır:

• Agent forwarding: Yerel agent geçici olarak kullanılır. Özel anahtar VPS’e konmaz; buna karşılık açık oturum süresince forwarding tehdidi kabul edilir.
• Deploy key veya ayrı makine kimliği: VPS için ayrı ve sınırlı yetkili bir anahtar oluşturulur. Kimlik sunucuda saklanır; erişim kapsamı ve rotasyonu ayrıca yönetilir.

Tek seferlik bakım veya kontrollü bir dağıtım oturumunda agent forwarding pratik olabilir. Sürekli çalışan otomasyonlarda ise kişisel anahtarınızı yönlendirmek yerine yalnızca ilgili depo için sınırlandırılmış bir makine kimliği daha öngörülebilir bir modeldir. Kullanacağınız Git hizmetinin salt okunur veya depo kapsamlı anahtar seçeneklerini kendi belgelerinden doğrulayın.

Ekipte birden fazla kişinin eriştiği sistemlerde SSH Anahtar Yönetimi ve Yetki Paylaşımı yaklaşımını ayrıca değerlendirin. Buradaki anahtar yönetimi ve yetki paylaşımı yaklaşımı, erişimin kişisel anahtarlar ve paylaşılan hesaplar yerine kimlik, kapsam ve rotasyon kurallarıyla tasarlanmasına yardımcı olur.

ProxyJump ne zaman daha uygundur?

Yerel bilgisayarınızdaki Git istemcisi hedef depoya bağlanabiliyorsa, SSH yapılandırmasında ProxyJump kullanarak VPS’i yalnızca ağ geçidi yapabilirsiniz. ProxyJump, OpenSSH istemcisinin desteklediği bir özelliktir; istemci sürümünüzü ssh -V ile kontrol edin. Örnek olarak yerel ~/.ssh/config dosyanızda şu yapı bulunabilir:

Host vps-bastion
    HostName vps.example.net
    User deploy
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host git-through-vps
    HostName git.example.com
    User git
    ProxyJump vps-bastion
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Burada git-through-vps takma adı yerel Git istemcisi tarafından kullanılabilir. Git işlemi VPS üzerinde değil, sizin bilgisayarınızda gerçekleşir. ProxyJump bağlantı yolunu değiştirir; tek başına uzak VPS shell’ine agent soketi sunmaz.

Bu yöntemi kullanırken hedef Git sunucusunun host anahtarını yerel known_hosts dosyanızda doğrulayın. Aracı VPS’in host anahtarını doğrulamak, hedef Git sunucusunun kimliğini doğruladığınız anlamına gelmez.

Agent forwarding için ön koşullar

Kuruluma başlamadan önce üç noktayı kontrol edin: yerel agent çalışıyor mu, doğru anahtar agent’a ekli mi ve SSH istemcisi yalnızca hedef VPS için forwarding yapıyor mu? OpenSSH istemcisi ile sunucusunun sürümünü de kontrol edin; desteklenen yapılandırma seçenekleri dağıtıma ve sürüme göre değişebilir.

Yerel agent ve anahtar kontrolü

Linux veya macOS üzerinde mevcut agent soketini ve yüklü kimlikleri şu komutlarla kontrol edebilirsiniz:

ssh -V
echo "$SSH_AUTH_SOCK"
ssh-add -l

ssh-add -l bir anahtar listesi döndürüyorsa agent’a en az bir kimlik yüklenmiştir. Liste boşsa, kullanacağınız anahtarı agent’a ekleyin:

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

Dosya adını kendi anahtarınızla değiştirin. Komut özel anahtarın içeriğini ekrana yazdırmaz; işletim sisteminiz veya anahtarınız parola korumalıysa sizden bu parolayı isteyebilir. Windows’ta OpenSSH agent, WSL veya kullandığınız SSH istemcisinin agent uygulaması farklı çalışabilir. Aynı kontrolün karşılığını kullandığınız ortamın terminalinde yapın.

Agent’ta çok sayıda kimlik varsa SSH sunucusu gereğinden fazla anahtar deneyebilir ve Git hizmetinin kimlik doğrulama sınırlarına takılabilir. Bu durumda SSH yapılandırmasında IdentitiesOnly yes kullanmak, ilgili bağlantıdaki kimlik seçimini daraltır; agent forwarding’i kapatmaz.

Yalnızca hedef VPS için yapılandırma

Forwarding’i tüm SSH bağlantılarına açmak yerine belirli bir host takma adına bağlayın:

Host git-deploy-vps
    HostName vps.example.net
    User deploy
    ForwardAgent yes
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Bu örnekte git-deploy-vps yalnızca bir SSH takma adıdır. Host * altında ForwardAgent yes tanımlamak, yanlışlıkla bağlandığınız her sunucuya agent soketini açabilir. Mevcut ayarların hangi sırayla uygulandığını görmek için yerel bilgisayarınızda şu teşhis komutunu kullanın:

ssh -G git-deploy-vps | grep -Ei 'forwardagent|hostname|user|identityfile|identitiesonly'

Çıktıda forwardagent yes, beklediğiniz host adı, kullanıcı ve kimlik ayarlarını görmelisiniz. Bu komut bağlantı kurmaz ve ayarları değiştirmez.

VPS üzerinde teşhis ve dar kapsamlı çözüm

Ön koşullar sağlandıktan sonra VPS’e takma ad üzerinden bağlanın:

ssh git-deploy-vps

İlk teşhis, uzak oturumda agent soketinin görünüp görünmediğini kontrol etmektir:

printf '%s\n' "$SSH_AUTH_SOCK"
ssh-add -l

SSH_AUTH_SOCK boşsa veya ssh-add -l agent’a bağlanamadığını bildiriyorsa forwarding etkin değildir, SSH bağlantısı forwarding’i kabul etmemiştir ya da uzak oturumun ortamı soketi taşımamıştır. Bu aşamada sunucuya anahtar kopyalamayın. Önce yerel yapılandırmayı ve sunucunun SSH daemon ayarını kontrol edin.

Sunucuda SSH daemon yapılandırmasında AllowAgentForwarding değerinin forwarding’i engellemediğini yetkili yönetici kontrol etmelidir. Değişiklik yapmanız gerekiyorsa önce mevcut dosyanın yedeğini alın ve geri dönüş komutunu belirleyin. Örneğin Linux sistemlerde değişiklikten sonra, dağıtımınızın kullandığı dosyayı belirterek yapılandırmayı test edebilirsiniz:

sudo sshd -t -f /etc/ssh/sshd_config

Test başarılı olmadan SSH servisini yeniden yüklemeyin. Yeniden yükleme yöntemi dağıtıma ve servis yöneticisine göre değişebileceği için sisteminizin belgelenen komutunu kullanın. Değişiklik bağlantıyı bozarsa mevcut dosyayı yedeğinden geri yükleyip servis yapılandırmasını yeniden test edin. İhtiyaç yoksa başka kimlik doğrulama veya ağ ayarlarını aynı değişiklikte değiştirmeyin.

Forwarding sunucuda görünür hale geldikten sonra Git kimlik doğrulamasını SSH katmanında test edin. Örneğin hedef Git hizmetinizin SSH kullanıcı adı git ve host adı git.example.com ise:

ssh -T git@git.example.com

İlk bağlantıda host anahtarı doğrulaması istenebilir. Parmak izini bağımsız ve güvenilir bir kanaldan doğrulamadan kabul etmeyin. Başarılı kimlik doğrulama mesajı servis sağlayıcıya göre değişir; shell açılmaması tek başına başarısızlık anlamına gelmeyebilir.

Sonra belirli bir deponun erişimini, veri indirmeden metadata sorgulayarak test edin:

git ls-remote git@git.example.com:ekip/proje.git

Bu komut referansları listeler. Başarılı olursa SSH kimliği, depo yolu ve erişim yetkisi birlikte çalışıyor demektir. Permission denied (publickey) alırsanız önce hangi anahtarların denendiğini ayrıntılı SSH çıktısıyla inceleyin:

ssh -vT git@git.example.com

Çıktıda özel anahtar içeriği görünmez; fakat sunucunun agent kullanıp kullanmadığı ve kimlik doğrulama adımları hakkında bilgi bulunabilir. Sorun çözüldükten sonra ayrıntılı günlükleri paylaşırken kullanıcı adlarını, host adlarını ve yol bilgilerini gereksiz yere açık etmeyin.

Git’in farklı SSH ayarı kullanmasını engelleme

Shell üzerinde ssh komutu başarılıyken Git başarısızsa Git’in farklı bir istemci veya yapılandırma kullandığını kontrol edin. Bu kontrolü git komutunun çalıştığı ortamda, yani örneğin VPS üzerindeki depo dizininde yapın:

git config --show-origin --get core.sshCommand
env | grep '^GIT_SSH'

Tanımlı bir core.sshCommand varsa forwarding’i devre dışı bırakan ayrı bir ayar kullanıyor olabilir. En dar düzeltme, yalnızca ilgili depo için doğru SSH komutunu seçmektir. Örneğin Git işlemi VPS üzerinde çalışıyorsa, VPS üzerindeki depo dizininde şu ayar kullanılabilir:

git config core.sshCommand "ssh -F ~/.ssh/config"

Bu komut, Git’in ilgili ortamda kullanılan standart SSH yapılandırma dosyasını seçmesini sağlar. Kurumunuzda farklı bir SSH istemcisi gerekiyorsa bu değeri rastgele silmek yerine mevcut standarda göre düzenleyin. Değişiklikten sonra aynı depo içinde git ls-remote komutunu yeniden çalıştırarak sonucu doğrulayın.

Güvenlik sınırları ve risk azaltma

Agent forwarding’in temel riski, özel anahtarın okunması değil, agent’ın imza yetkisinin oturum süresince kullanılabilmesidir. Kötü amaçlı bir süreç, VPS’teki SSH_AUTH_SOCK değerini kullanarak agent’a imza talepleri gönderebilir. Bunun etkisi anahtarın yetkilerine, Git hesabının erişim kapsamına ve bağlantının açık kaldığı süreye bağlıdır.

Bu nedenle kişisel, geniş yetkili veya birden fazla üretim sistemine erişen anahtarları forwarding ile kullanmayın. İş için ayrı bir anahtar oluşturun, mümkünse yalnızca gerekli depo veya ortama yetki verin ve iş bittiğinde agent’tan kaldırın:

ssh-add -d ~/.ssh/id_ed25519_work
ssh-add -l

Agent’taki tüm kimlikleri kaldırmak gerekiyorsa ssh-add -D komutu kullanılabilir; bu komut diğer projelerin kimliklerini de kaldırır. Bu yüzden paylaşılan çalışma ortamlarında komutu uygulamadan önce aktif oturumların etkilenip etkilenmeyeceğini kontrol edin.

Yeni OpenSSH sürümleri, desteklenen agent uygulamalarında hedef kısıtlamaları gibi daha gelişmiş kontroller sunabilir. Bu özelliklerin istemci, agent ve anahtar türü tarafından desteklendiğini doğrulamadan güvenlik sınırı olarak kabul etmeyin. Daha temel ve taşınabilir önlem, forwarding’i tek host ile sınırlamak ve ayrı, düşük yetkili bir anahtar kullanmaktır.

SSH anahtarlarının rotasyonu, dosya izinleri ve ekip erişimleri için VPS SSH güvenliği başlığındaki FIDO2, SSH CA ve rotasyon seçeneklerini de inceleyebilirsiniz. Agent forwarding, anahtar yönetiminin yerini tutmaz; yalnızca özel anahtarı belirli bir bağlantıda sunucuya kopyalamadan kullanma yöntemidir.

Agent forwarding çalışmadığında kontrol sırası

1. Yereli kontrol edin: ssh-add -l ile doğru anahtarın agent’ta olduğunu ve echo "$SSH_AUTH_SOCK" ile yerel soketin bulunduğunu doğrulayın.
2. SSH ayarını kontrol edin: ssh -G git-deploy-vps çıktısında ForwardAgent yes, doğru kullanıcı ve doğru host adını arayın.
3. Uzak soketi kontrol edin: VPS oturumunda SSH_AUTH_SOCK boş mu, ssh-add -l agent’a erişebiliyor mu bakın.
4. Host anahtarını ayırın: Git hizmetinin host anahtarı known_hosts içinde doğrulanmış mı kontrol edin.
5. SSH katmanını test edin: ssh -vT ile kimlik doğrulama akışını inceleyin; ardından git ls-remote ile depo yetkisini sınayın.
6. Git ayarını inceleyin: core.sshCommand veya GIT_SSH değişkeninin beklenmeyen bir istemci ve config kullanmadığından emin olun.

Sunucuda agent soketi görünmüyorsa ve sunucu yapılandırmasını değiştirme yetkiniz yoksa forwarding’i zorlamak yerine sistem yöneticisinden AllowAgentForwarding politikasını doğrulamasını isteyin. Başarısız denemeler sırasında anahtarı sunucuya kopyalamak, teşhis edilmemiş yapılandırma sorununu kalıcı bir gizli anahtar riskine dönüştürür.

Sık Sorulan Sorular

SSH agent forwarding özel anahtarı VPS’te saklar mı?

Hayır. Normal akışta özel anahtar dosyası VPS’e aktarılmaz. Ancak VPS, açık forwarding oturumu sırasında agent’a imza isteği gönderebilir; bu yüzden yöntem güvenilmeyen sunucular için uygun değildir.

ForwardAgent yes ayarı tüm sunucular için mi geçerlidir?

Yalnızca tanımlandığı host kapsamına uygulanır. Host * altında kullanırsanız kapsam genişler. Daha güvenli tercih, forwarding’i belirli bir takma adın altında tanımlamaktır.

VPS üzerinde çalışan cron agent forwarding kullanabilir mi?

Genellikle hayır. Cron, etkileşimli SSH oturumunun ortamını ve agent soketini kendiliğinden devralmaz. Ayrıca cron ile çalışan CLI işi, PHP-FPM web işçilerinden ayrı bir süreçtir; agent soketi açık oturumdan ayrıca aktarılmadıkça bu işin forwarding’e erişimi olmaz. Sürekli bir iş için yerel bilgisayarın açık oturumuna bağımlı olmak da güvenilir değildir. Otomasyon için ayrı bir makine kimliği tasarlayın.

ProxyJump kullanırsam VPS üzerinde git clone çalışır mı?

Hayır. ProxyJump, yerel SSH istemcinizin hedefe VPS üzerinden ulaşmasını sağlar. git clone komutunu VPS üzerinde çalıştırmak istiyorsanız VPS’in kendi kimlik doğrulama yöntemine ihtiyaç duyarsınız.

Uygulanabilir kontrol listesi

• Git işleminin yerelde mi, VPS üzerinde mi çalışacağına karar verin.
• Yalnızca aracı bağlantı gerekiyorsa ProxyJump‘ı agent forwarding’e tercih edin.
• Forwarding gerekiyorsa ayrı ve düşük yetkili bir SSH anahtarı kullanın.
• ForwardAgent yes ayarını yalnızca tek bir VPS host takma adına yazın.
• Yerel agent, uzak SSH_AUTH_SOCK, SSH kimlik doğrulaması ve git ls-remote adımlarını sırayla doğrulayın.
• İş bittikten sonra geçici kimliği agent’tan kaldırın.
• Kalıcı deploy akışında kişisel agent yerine depo kapsamlı makine kimliği veya CI/CD secret modeli planlayın.

Bir sonraki adımınız, mevcut deploy komutunun nerede çalıştığını netleştirmek olmalı. Komut VPS’te çalışıyorsa forwarding’i kısa süreli ve dar kapsamlı bir çözüm olarak uygulayın; düzenli otomasyonsa anahtar kapsamını ve rotasyonunu ayrı bir makine kimliğiyle tasarlayın.