Çoklu Hesap İçin SSH Passphrase ve Git Kimlik Yönetimi

Tek bilgisayarda kişisel projeler, kurumsal depolar, müşteri çalışmaları ve açık kaynak katkıları arasında geçiş yapıyorsanız, Git tarafındaki kimlik yönetimi kısa sürede kafa karıştırıcı hâle gelebilir. Yanlış SSH anahtarının seçilmesi, kurumsal projeye kişisel e-posta ile commit atılması veya GitHub hesabının beklenmedik biçimde başka bir anahtarla doğrulanması sık karşılaşılan sorunlardır. Çoklu Hesap İçin SSH Passphrase ve Git Kimlik Yönetimi konusunu doğru ele aldığınızda bu problemleri manuel hesap değiştirerek değil, birbirinden ayrılmış ve öngörülebilir kimlik kuralları oluşturarak çözebilirsiniz. Bu rehberde birden fazla Git hesabı için SSH key nasıl yönetilir, çoklu GitHub GitLab hesaplarında SSH config nasıl yapılandırılır ve SSH passphrase ssh-agent ve keychain ile Git anahtar yönetimi nasıl uygulanır sorularını gerçek kullanım senaryolarıyla ele alacağım. Amacımız, kişisel kullanımda rahat çalışan fakat kurumsal ölçekte de denetlenebilir, sürdürülebilir ve güvenli bir yapı kurmaktır.

Çoklu Git Hesabı Yönetimi Nedir?

Çoklu Git hesabı yönetimi, aynı bilgisayardan veya geliştirme ortamından birden fazla Git kimliğiyle güvenli biçimde çalışmayı ifade eder. Buradaki temel mesele yalnızca iki farklı kullanıcı hesabıyla oturum açmak değildir; SSH doğrulaması, commit yazarı, imzalama anahtarı ve web oturumu gibi birbirinden bağımsız kimlik katmanlarını doğru projeyle eşleştirmektir. Örneğin kişisel GitHub hesabınız için bir SSH anahtarı, iş hesabınız için başka bir anahtar ve müşteriye ait GitLab hesabı için üçüncü bir anahtar kullanabilirsiniz. Bunun yanında her depo kendi user.name, user.email ve gerekirse user.signingKey değerini kullanmalıdır. Başlangıçta birkaç satır yapılandırma gerektirse de bu ayrım, ilerleyen dönemde yanlış hesaptan push yapma veya yanlış e-posta ile commit oluşturma riskini ciddi biçimde azaltır.

Neden Aynı Bilgisayarda Birden Fazla Git Hesabı Kullanılır?

Yazılım geliştiricilerin tek cihazda birden fazla Git hesabı kullanması oldukça doğal bir çalışma biçimidir. Gündüz kurumsal projelerde çalışırken akşam kişisel uygulamanıza commit atabilir, aynı hafta içinde farklı müşterilerin GitLab depolarına erişebilir veya açık kaynak projelerine katkıda bulunabilirsiniz. Her ortamın erişim politikası, e-posta adresi ve SSH anahtarı farklı olabilir. Bu nedenle hesabı yalnızca tarayıcıdaki profil seçimi gibi düşünmek doğru değildir. Sağlıklı bir yapı, hangi klasörde ve hangi remote üzerinde çalışıyorsanız ilgili kimliği otomatik veya açık bir kuralla seçmelidir.

Kişisel GitHub Hesabı

Kişisel GitHub hesabı genellikle özel projeler, öğrenme çalışmaları, portföy depoları ve açık kaynak katkıları için kullanılır. Bu hesapta kullanılan SSH anahtarının iş hesabından ayrı tutulması, hem erişim sınırlarını netleştirir hem de anahtar iptalini kolaylaştırır. Kişisel projelerde kullandığınız e-posta adresinin de kurumsal depolara taşınmaması gerekir. Ben çoklu hesap düzenlerinde kişisel kimliğin ayrı bir Git config dosyasında tutulmasını tercih ediyorum. Böylece kişisel klasör altındaki depolar otomatik olarak doğru kullanıcı adı, e-posta ve gerekirse signing key değerini kullanabiliyor.

İş GitHub Hesabı

İş GitHub hesabı çoğunlukla kurumun erişim politikaları, SSO gereksinimleri ve güvenlik kurallarıyla birlikte değerlendirilmelidir. Kurumsal hesaba ait SSH anahtarını kişisel anahtarla paylaşmak yerine ayrı üretmek, cihaz kaybı veya işten ayrılma gibi durumlarda yönetimi kolaylaştırır. İş depoları için kurumsal e-posta adresini Git kimliği olarak açık biçimde tanımlamak da önemlidir. Bu düzeni includeIf, SSH host alias ve IdentitiesOnly yes ile desteklediğinizde yanlış hesabın devreye girme ihtimali azalır. Kurumsal Git SSH anahtar ve geliştirici kimlik yönetimi hizmeti tasarlanırken de aynı ayrıştırma prensibi temel alınmalıdır.

Müşteri Hesapları

Ajans, danışmanlık veya freelance çalışma modelinde müşteri hesapları çoklu kimlik düzeninin en hassas alanlarından biridir. Bir müşterinin SSH anahtarının başka müşterinin deposuna sunulması teknik olarak başarısız olabilir, fakat güvenlik ve operasyon açısından yine de istemediğimiz bir davranıştır. Her müşteri için ayrı host alias ve ayrı SSH key kullanmak bu sınırı görünür hâle getirir. Git commit kimliklerini de müşteri dizinine göre koşullu olarak yüklemek yanlış e-posta kullanımını önlemeye yardımcı olur. Özellikle uzun süreli müşteri projelerinde hesap, cihaz ve erişim kapsamını belgelendirmek ileride anahtar rotasyonu ve offboarding işlemlerini kolaylaştırır.

GitLab

GitLab tarafında da temel mantık GitHub ile aynıdır: uzak sunucu public key üzerinden sizi tanır, yerel sistem ise hangi private key'in sunulacağını belirler. Birden fazla GitLab hesabı aynı hostname üzerinde bulunuyorsa host alias kullanmak oldukça etkili bir çözümdür. Örneğin gitlab-personal ve gitlab-work adlarını gerçek GitLab hostname'ine yönlendirebilirsiniz. Böylece her alias farklı IdentityFile kullanır ve remote URL hangi anahtarın seçileceğini belirler. Bu yöntem özellikle çoklu GitHub GitLab hesaplarında SSH config nasıl yapılandırılır sorusuna en anlaşılır cevaplardan biridir.

GitHub Enterprise

GitHub Enterprise kullanan kurumlarda çoğu zaman github.com dışında ayrı bir kurumsal hostname bulunur. Ayrı hostname kullanılması SSH anahtar seçimini bir ölçüde kolaylaştırsa da commit kimliği ve signing key yönetimi yine ayrıca ele alınmalıdır. Enterprise Managed User gibi modellerde kurum politikaları kişisel hesap kullanımından daha sınırlayıcı olabilir. Bu nedenle kurumsal SSH key'i ayrı üretmek, gerekli SSO veya güvenlik politikalarına uymak ve config dosyasını açık biçimde ayırmak önemlidir. Şirket içi süreç tasarlarken erişim, imzalama, rotasyon ve iptal adımlarının birlikte belgelenmesi de faydalıdır.

Açık Kaynak Katkıları

Açık kaynak katkılarında hangi kimliği kullanacağınızı önceden belirlemek önemlidir çünkü commit e-postası çoğu projede herkese açık geçmişin bir parçası olur. Kurumsal e-posta adresinin farkında olmadan açık kaynak deposuna yazılması gizlilik veya şirket politikası açısından sorun oluşturabilir. Kişisel noreply adresi, kişisel signing key ve kişisel SSH kimliği bu kullanım için daha uygun olabilir. Bununla birlikte katkı yaptığınız proje işinizin bir parçasıysa kurum politikasını ayrıca dikkate almalısınız. Kimlik ayrımını klasör ve remote tabanlı kurduğunuzda açık kaynak ile kurumsal çalışma arasında geçiş yapmak daha güvenli hâle gelir.

Çoklu Hesap Kullanımında En Sık Yaşanan Problemler

Çoklu hesaplarda sorunların büyük kısmı Git'in veya SSH'ın çalışmamasından değil, yanlış kimliğin doğru çalışan bir mekanizma tarafından seçilmesinden kaynaklanır. Bir SSH agent içinde çok sayıda anahtar bulunması, global user.email kullanılması veya remote adresinin yanlış alias ile tanımlanması buna örnektir. Bu sorunlar bazen doğrudan hata mesajı üretir, bazen ise işlem başarıyla gerçekleştiği için daha geç fark edilir. Yanlış e-posta ile oluşturulan commit bunun iyi bir örneğidir. Bu nedenle yalnızca bağlantı kurulup kurulmadığını değil, hangi kimlikle kurulduğunu da doğrulamak gerekir.

Yanlış SSH Key

SSH istemcisi beklediğiniz private key yerine agent içindeki başka bir anahtarı sunabilir. Aynı sunucuda iki hesabınız varsa bu durum yanlış hesabın doğrulanmasına veya erişimin reddedilmesine yol açabilir. IdentityFile ve IdentitiesOnly yes birlikte kullanıldığında anahtar seçimini daha öngörülebilir hâle getirebilirsiniz. ssh -vT çıktısı hangi public key'in sunulduğunu görmek için oldukça yararlıdır. Sorunu yalnızca key dosyasını yeniden oluşturarak çözmeye çalışmak yerine SSH'ın gerçek seçim sürecini incelemek daha doğru sonuç verir.

Yanlış Commit E-postası

Git authentication hesabı ile commit yazarı aynı kimlik değildir. SSH ile iş hesabınız üzerinden push yaparken commit içine kişisel e-posta adresiniz yazılmış olabilir. Bunun temel nedeni çoğu zaman global user.email değeridir. Repository bazlı config veya includeIf ile farklı çalışma dizinlerine farklı e-postalar tanımlamak bu problemi önler. Ayrıca user.useConfigOnly=true kullanılması, kimlik belirlenmemiş bir ortamda Git'in tahminde bulunup yanlış commit üretmesini engelleyebilir.

Permission Denied

Permission denied (publickey) mesajı tek başına anahtarınızın bozuk olduğunu göstermez. Remote URL yanlış host alias kullanıyor olabilir, public key doğru hesaba eklenmemiş olabilir veya SSH farklı bir identity seçiyor olabilir. Private key dosya izinleri de bağlantının reddedilmesine neden olabilir. Sorunu çözerken önce remote URL'yi, ardından ssh -T ve ssh -vT çıktısını kontrol etmek iyi bir yöntemdir. Böylece tahmin yürütmek yerine authentication akışının hangi aşamada koptuğunu görebilirsiniz.

Yanlış Commit Signing Key

Commit signing için kullanılan anahtar, ağ üzerinden Git sunucusuna bağlanmak için kullanılan authentication anahtarından kavramsal olarak farklıdır. Çoklu hesap düzeninde user.signingKey global tanımlanırsa kişisel projede kurumsal signing key kullanılması gibi durumlar ortaya çıkabilir. Signing key'i de includeIf ile kimlik dosyasına bağlamak daha güvenli bir yaklaşımdır. Commit sonrasında imzanın beklenen hesapta Verified olarak görünüp görünmediğini kontrol etmek gerekir. Özellikle kurumsal depolarda imzalama zorunluysa bu ayrım çalışma standardının bir parçası olmalıdır.

Sürekli Passphrase İstenmesi

Passphrase kullanmak private key güvenliğini artırır, fakat her git fetch veya git push işleminde yeniden girilmesi kullanıcı deneyimini zorlaştırabilir. Bu problemi passphrase'i kaldırarak çözmek yerine ssh-agent, macOS Keychain veya işletim sistemine uygun agent mekanizması kullanılmalıdır. Agent anahtarı açtıktan sonra belirli bir oturum boyunca bellekte erişilebilir tutar. Böylece private key diskte şifreli kalırken günlük kullanım daha rahat olur. Agent yaşam süresi, workstation kilidi ve socket erişimi de güvenlik politikasına uygun biçimde yapılandırılmalıdır.

Önce Üç Farklı “Kimliği” Birbirinden Ayırmak

Çoklu Git hesabı yönetiminin en önemli noktası authentication, commit ve signing kimliklerinin aynı şey olmadığını anlamaktır. SSH anahtarınız sunucuya hangi hesap olarak bağlanabileceğinizi belirlerken user.name ve user.email commit metadata'sını belirler. user.signingKey ise commit'in hangi kriptografik anahtarla imzalandığını kontrol eder. Bunlara ek olarak tarayıcıdaki GitHub veya GitLab oturumu tamamen farklı bir kimlik katmanıdır. Bu ayrımı baştan netleştirirseniz yanlış hesabın nerede devreye girdiğini teşhis etmek çok daha kolay olur.

SSH Authentication Identity

SSH authentication identity, uzak Git sunucusuna bağlanırken kullanılan anahtar çiftidir. Sunucu private key'inizi görmez; istemcinin ilgili private key'e sahip olduğunu kriptografik olarak kanıtlamasını ister. Hangi anahtarın kullanılacağını ~/.ssh/config, komut satırı seçenekleri, agent ve SSH varsayılanları etkileyebilir. Çoklu hesaplarda host alias kullanmak bu seçim sürecini açık hâle getirir. Böylece remote URL aynı fiziksel sunucuya gitse bile farklı alias'lar farklı anahtarları kullanabilir.

Git Commit Identity

Git commit identity, commit içine yazılan kullanıcı adı ve e-posta bilgisidir. Bu değer SSH ile bağlandığınız hesap tarafından otomatik belirlenmez. Dolayısıyla iş hesabının SSH key'iyle push yaptığınız bir commit'in author alanında kişisel e-posta bulunabilir. Git kimliği repository, worktree, global veya koşullu config üzerinden belirlenebilir. Çoklu hesaplarda global tek kimlik yerine bağlama göre değişen config kullanmak daha sağlıklı sonuç verir.

user.name

user.name commit üzerinde görünen yazar adını belirleyen Git ayarıdır. Bu değer GitHub veya GitLab kullanıcı adınız olmak zorunda değildir. İsim biçiminizin kurumsal projelerde belirli bir standarda uyması gerekiyorsa work config içinde ayrıca tanımlanabilir. Kişisel depolarda ise farklı bir gösterim tercih edebilirsiniz. Önemli olan değerin hangi scope'tan geldiğini bilmek ve projenin beklentisine göre otomatik seçilmesini sağlamaktır.

user.email

user.email çoklu hesap yönetiminde en fazla dikkat edilmesi gereken Git değerlerinden biridir. Commit attribution sistemleri çoğu zaman bu adres üzerinden hesabınızla ilişki kurar. Kurumsal adresin kişisel veya açık kaynak projelerine taşınması gizlilik problemi yaratabilir. Kişisel adresin iş deposunda kullanılması ise kurumsal raporlama veya Verified süreçlerini etkileyebilir. git config --show-origin user.email komutu değerin hangi config dosyasından geldiğini anlamak için kullanılabilir.

Commit Signing Identity

Commit signing identity, commit'in gerçekten belirli bir anahtara sahip kullanıcı tarafından imzalandığını doğrulamaya yarar. GPG veya SSH signing kullanılması mümkündür. Çoklu hesaplarda signing key'in de kişisel ve kurumsal bağlama göre ayrılması önerilir. Özellikle kurum Verified commit politikası uyguluyorsa yanlış signing key kullanılması push başarılı olsa bile politika ihlaline dönüşebilir. Kimlik dosyasına user.signingKey ve commit.gpgsign eklemek bu süreci otomatikleştirebilir.

user.signingKey

user.signingKey, Git'in commit veya tag imzalarken hangi anahtarı kullanacağını tanımlar. SSH signing kullanıyorsanız anahtar dosyasına veya desteklenen anahtar gösterimine göre yapılandırma yapılabilir. Bu değeri global tanımlamak çoklu hesaplarda her proje için aynı imzalama anahtarının kullanılmasına neden olabilir. Work ve personal config dosyalarında ayrı değer kullanmak daha kontrollüdür. Commit oluşturduktan sonra imzanın platform tarafında beklenen hesaba bağlandığını da kontrol etmek gerekir.

GitHub/GitLab Web Session Identity

Tarayıcıda açık olan GitHub veya GitLab hesabı SSH bağlantınızdan bağımsızdır. Web arayüzünde iş hesabıyla oturum açmış olmanız terminalde Git'in aynı hesapla push yapacağını garanti etmez. Benzer şekilde GitHub CLI'daki aktif kullanıcı da SSH host alias seçimini otomatik olarak değiştirmez. Pull request oluşturma, issue açma veya web tabanlı işlem yaparken bu katman ayrıca kontrol edilmelidir. Çoklu hesap sistemini tasarlarken terminal, CLI ve web oturumlarını ayrı kimlik kaynakları olarak görmek yararlıdır.

Neden Bu Kimlikler Aynı Şey Değildir?

Git dağıtık bir sürüm kontrol sistemi olduğu için commit üretme işlemi ağ bağlantısı olmadan da gerçekleşebilir. Bu nedenle commit author bilgisi, sunucu authentication işlemine bağlı değildir. Signing ise commit içeriğinin bütünlüğünü ve imzalayan anahtarı doğrulamaya yönelik ayrı bir mekanizmadır. Web session ise tarayıcı veya platform istemcisinin oturum yönetimidir. Bu dört katmanın ayrılması sayesinde geliştirici çevrimdışı commit oluşturabilir, daha sonra farklı bir bağlantı mekanizmasıyla sunucuya gönderebilir.

SSH Key Nasıl Çalışır?

SSH anahtarları public ve private olmak üzere iki parçadan oluşur. Public key sunucu tarafındaki hesabınıza kaydedilirken private key yalnızca sizin cihazınızda kalmalıdır. Bağlantı sırasında sunucu, istemcinin kayıtlı public key'e karşılık gelen private key'e gerçekten sahip olduğunu doğrular. Bu işlem private key'in sunucuya gönderilmesini gerektirmez. Çoklu hesaplarda hangi public key'in hangi hesaba kayıtlı olduğu ve istemcinin hangi private key'i sunduğu doğru eşleştirilmelidir.

Public Key

Public key paylaşılmak üzere tasarlanmış anahtar parçasıdır ve genellikle .pub uzantılı dosyada bulunur. Git hosting platformundaki hesap ayarlarına bu içerik eklenir. Public key'in ele geçirilmesi private key'in elde edildiği anlamına gelmez. Yine de anahtar başlıklarını ve fingerprint bilgilerini düzenli tutmak hangi cihazın hangi erişime sahip olduğunu anlamayı kolaylaştırır. Kurumsal ortamlarda key title içinde cihaz ve kullanım amacı bilgisinin bulunması denetim açısından faydalıdır.

Private Key

Private key cihazınızdan çıkmaması gereken hassas anahtar parçasıdır. Dosyanın bulut klasörüne, Git deposuna veya paylaşılan bir dizine kopyalanması ciddi güvenlik riski oluşturur. Passphrase kullanılması private key dosyasının ele geçirilmesi durumunda ek koruma sağlar. Dosya izinlerinin yalnızca gerekli kullanıcı tarafından okunabilir olması da önemlidir. Yeni cihaz aldığınızda eski private key'i kopyalamak yerine yeni anahtar üretmek çoğu durumda daha iyi bir cihaz bazlı iptal modeli sağlar.

Authentication Akışı

SSH bağlantısı başlatıldığında istemci hedef host için geçerli yapılandırmayı hesaplar ve kullanılabilecek kimlikleri belirler. Sunucu kabul ettiği authentication yöntemlerini bildirir ve istemci uygun public key'leri teklif eder. Sunucu kayıtlı bir public key ile eşleşme bulduğunda istemciden private key sahipliğini kanıtlayan kriptografik işlem ister. Private key passphrase ile korunuyorsa anahtarın kullanılması için önce yerelde açılması gerekir. Başarılı doğrulamanın ardından Git protokolü ilgili repository erişim izinleri çerçevesinde devam eder.

Private Key Sunucuya Gönderilir mi?

Hayır, normal SSH public key authentication sürecinde private key sunucuya gönderilmez. İstemci private key'i yerelde kullanarak sunucunun doğrulayabileceği bir imza üretir. Bu tasarım, private anahtarın uzak sisteme taşınmadan kimliğin kanıtlanmasını sağlar. Bu nedenle private key'in güvenliği büyük ölçüde yerel cihaz, dosya izinleri, passphrase ve agent güvenliğiyle ilgilidir. Bir hizmet sizden private key içeriğinizi yüklemenizi istiyorsa işlemin amacını çok dikkatli değerlendirmelisiniz.

Git Hosting Platformu Hesabı Nasıl Belirler?

Git hosting platformu, kendisine eklediğiniz public key ile hesabınız arasında bir ilişki tutar. SSH bağlantısı sırasında kabul edilen key hangi hesaba kayıtlıysa authentication o hesap bağlamında gerçekleşir. Bu nedenle aynı github.com adresine farklı kullanıcılarla bağlanmak istediğinizde istemcinin doğru anahtarı seçmesi kritik hâle gelir. Host alias yapısı bu noktada oldukça kullanışlıdır. Remote URL'deki alias, SSH config içinde hangi IdentityFile değerinin kullanılacağını belirleyerek hesap seçimini açık hâle getirir.

SSH Passphrase Nedir?

SSH passphrase, private key dosyasını yerelde koruyan paroladır ve GitHub veya GitLab hesabınızın giriş parolası değildir. Anahtar oluştururken passphrase belirlediğinizde private key diskte şifreli biçimde saklanır. Anahtarı kullanmak isteyen süreç önce doğru passphrase ile anahtarın kilidini açmalıdır. Bu koruma özellikle cihaz veya yedek dosyasının ele geçirilmesi durumunda önemlidir. Kullanım kolaylığını korumak için passphrase'i kaldırmak yerine güvenilir bir agent mekanizması kullanılabilir.

Passphrase ile Hesap Parolası Arasındaki Fark

Hesap parolası web hizmetindeki oturum açma mekanizmasına aittir, SSH passphrase ise yerel private key dosyasını korur. GitHub hesabınızın parolasını değiştirmeniz SSH private key passphrase'ini değiştirmez. Benzer şekilde SSH passphrase değiştirmek platformdaki web şifrenizi etkilemez. Çoklu hesap ortamında her bir SSH anahtarının kendi passphrase'i olabilir. Bu ayrımı bilmek özellikle erişim problemi yaşandığında yanlış kimlik katmanını düzeltmeye çalışmanızı önler.

Passphrase Neyi Korur?

Passphrase temel olarak private key dosyasının doğrudan kullanılmasını zorlaştırır. Bir saldırgan yalnızca şifreli private key dosyanızı kopyalarsa, anahtarı kullanmadan önce passphrase'i aşması gerekir. Elbette güvenlik yalnızca passphrase'e bağlı değildir; güçlü cihaz parolası, disk şifreleme, güncel sistem ve doğru dosya izinleri de önem taşır. Agent içinde açılmış anahtarın güvenliği ise farklı bir risk alanıdır. Bu nedenle workstation lock ve agent lifetime politikaları da beraber düşünülmelidir.

Passphrase GitHub'a Gönderilir mi?

SSH private key passphrase'i GitHub veya GitLab'a gönderilmez. Passphrase, yerel private key'in kilidini açmak için cihazınızda kullanılır. Uzak hizmet yalnızca public key tabanlı authentication sürecini görür. Bu nedenle platform hesabındaki SSH key ayarlarında passphrase bilgisi bulunmaz. Passphrase'i herhangi bir Git hosting hesabına kaydetmek veya paylaşmak gerekmez.

Private Key Çalınırsa Passphrase Neden Önemlidir?

Passphrase kullanılmayan private key dosyası ele geçirildiğinde saldırganın anahtarı doğrudan kullanma ihtimali daha yüksektir. Güçlü bir passphrase, dosyanın tek başına yeterli bir kimlik bilgisi olmasını engelleyen ek bir bariyer oluşturur. Bununla birlikte anahtarın çalındığını fark ettiğinizde yalnızca passphrase'e güvenmemelisiniz. İlgili public key'i Git hosting hesabından revoke etmek gerekir. Kurumsal ortamda bu olay access token, oturum ve audit log kontrolleriyle birlikte ele alınmalıdır.

Passphrase Kullanmak Zorunlu mu?

Teknik olarak bazı SSH anahtarları passphrase olmadan oluşturulabilir, fakat geliştirici cihazlarında uzun ömürlü kullanıcı anahtarları için passphrase kullanılması güçlü bir güvenlik uygulamasıdır. Otomasyon sistemlerinde ise insan etkileşimine dayalı passphrase yerine repository kapsamlı deploy key veya service account gibi farklı credential modelleri daha uygun olabilir. Kullanım kolaylığı problemi agent ile çözülebilir. Bu nedenle “her push işleminde parola yazmamak” passphrase'i kaldırmak için iyi bir gerekçe değildir. Kullanım modeline göre güvenlik ve operasyon gereksinimleri birlikte değerlendirilmelidir.

Güçlü SSH Passphrase Nasıl Seçilir?

Güçlü bir SSH passphrase yalnızca özel karakter sayısına odaklanan kısa bir parola olmamalıdır. Uzun, tahmin edilmesi zor ve başka hesaplarda kullanılmayan bir ifade tercih etmek daha sağlıklıdır. Password manager kullanmak özellikle birden fazla anahtarla çalışırken pratiklik sağlar. Passphrase'i shell script, dotfile veya Git deposunda düz metin olarak saklamamak gerekir. Bir anahtarın passphrase'i ifşa olursa o anahtar için yeni bir güvenlik değerlendirmesi yapmak ve gerekirse rotasyon uygulamak daha güvenlidir.

Uzunluk

Passphrase uzunluğu brute-force ve tahmin saldırılarına karşı önemli bir etkendir. Çok kısa fakat karmaşık görünen bir parola yerine daha uzun ve rastgele oluşturulmuş bir ifade tercih etmek genellikle daha güçlüdür. Password manager tarafından üretilen uzun değerler bu iş için kullanılabilir. İnsan tarafından hatırlanacak ifade kullanıyorsanız kolay tahmin edilen alıntılar veya kişisel bilgilerden kaçınmalısınız. Amaç yalnızca politika gereğini karşılamak değil, private key dosyası ele geçirilse bile çevrimdışı tahmini zorlaştırmaktır.

Entropy

Entropy, bir secret değerinin ne kadar tahmin edilemez olduğunu anlamamıza yardımcı olan bir kavramdır. Aynı kalıbı izleyen ve kişisel bilgi içeren uzun bir passphrase her zaman güçlü sayılmaz. Rastgelelik arttıkça saldırganın olası kombinasyon alanı genişler. Bu nedenle password manager üretimi secret değerler pratik bir seçenek olabilir. İnsan tarafından oluşturulan passphrase'lerde ise tahmin edilebilir kelime dizilerini ve tekrar kullanılan şablonları azaltmak önemlidir.

Password Manager Kullanımı

Password manager, birden fazla SSH key için ayrı passphrase kullanmayı daha yönetilebilir hâle getirir. Böylece aynı passphrase'i bütün anahtarlarda tekrar kullanma ihtiyacı azalır. Password manager kasasının kendisi de güçlü ana parola ve mümkünse çok faktörlü doğrulama ile korunmalıdır. Passphrase'i terminal geçmişine veya script dosyasına yazmaktan kaçınmak gerekir. Agent ile birlikte kullanıldığında password manager yalnızca gerektiğinde secret değerini almanızı sağlar ve günlük Git kullanımını daha rahat hâle getirir.

Her Key İçin Ayrı Passphrase Gerekli mi?

Her key için ayrı passphrase kullanmak, bir secret değerinin açığa çıkması durumunda diğer anahtarların doğrudan etkilenmesini azaltır. Bunun operasyonel yükü password manager ile önemli ölçüde düşürülebilir. Çok sayıda geçici anahtar kullanıyorsanız kurum politikasına göre farklı modeller belirlenebilir. Kritik nokta, tek passphrase'in bütün kişisel ve kurumsal erişimleri aynı anda koruyan tek başarısızlık noktası hâline gelmemesidir. Özellikle müşteri ve iş hesaplarını kişisel hesaplardan ayırıyorsanız passphrase ayrımı da bu izolasyonu destekler.

Passphrase'i Shell Script İçinde Tutmamak

Passphrase'i shell script içine düz metin olarak yazmak private key şifrelemesinin sağladığı korumanın önemli kısmını etkisizleştirebilir. Script dosyaları yanlışlıkla Git deposuna eklenebilir, yedeklenebilir veya başka kullanıcılar tarafından okunabilir. Environment variable kullanımı da her durumda güvenli değildir çünkü süreç ortamı farklı mekanizmalarla görüntülenebilir. Secret yönetimi için işletim sisteminin güvenli saklama mekanizmaları veya password manager tercih edilmelidir. Otomasyonda insan passphrase'i yerine amaca uygun service credential kullanılması çoğu zaman daha iyi bir tasarımdır.

Çoklu Hesap İçin SSH Key Stratejisi

Çoklu hesaplarda anahtar stratejisini en başta belirlemek daha sonra yapılacak config işini büyük ölçüde kolaylaştırır. En basit yaklaşım tek key'i her yerde kullanmaktır, fakat bu yöntem erişim alanlarını birbirine bağlar ve iptal işlemlerini zorlaştırır. Hesap başına veya hesap ve cihaz başına ayrı key üretmek daha iyi izolasyon sağlar. Bir cihaz kaybolduğunda yalnızca o cihaza ait anahtarların kaldırılabilmesi önemli bir avantajdır. Kurumsal ortamda kullanılan model, erişim politikası ve cihaz yönetimi süreçleriyle birlikte tasarlanmalıdır.

Tek SSH Key'i Tüm Hesaplarda Kullanmak Doğru mu?

Tek SSH key'i her hesapta kullanmak ilk bakışta kolay görünür çünkü daha az dosya ve daha az config vardır. Ancak aynı private key kişisel, kurumsal ve müşteri hesaplarına erişebiliyorsa anahtarın ele geçirilmesi durumunda etki alanı genişler. Ayrıca bir iş ilişkisinin sona ermesi veya cihazın değiştirilmesi sırasında hangi erişimin kaldırılması gerektiğini ayırmak zorlaşır. Bazı platform veya kurum politikaları aynı key'in farklı hesaplarda kullanılmasına izin vermeyebilir. Bu nedenle çoklu hesap düzeninde ayrı anahtarlar genellikle daha anlaşılır ve yönetilebilir bir çözüm sunar.

Hesap Başına Ayrı Key

Hesap başına ayrı SSH key kullanmak kişisel, iş ve müşteri erişimlerini birbirinden ayırır. Bu modelde her platform hesabı kendi public key'iyle eşleşir. SSH config içindeki host alias sayesinde doğru remote doğru key'e yönlendirilir. Bir hesabın erişimini kaldırmak gerektiğinde yalnızca ilgili key revoke edilir. Cihaz sayısı arttığında ise cihaz bazlı iptal ihtiyacı nedeniyle hesap ve cihaz başına ayrı key modeline geçmek daha faydalı olabilir.

Cihaz Başına Ayrı Key

Cihaz başına ayrı key kullanmak laptop, masaüstü ve geliştirme sunucusu gibi cihazların erişimini bağımsız yönetmenizi sağlar. Laptop kaybolursa diğer cihazların key'lerini değiştirmeden yalnızca laptop key'i revoke edilebilir. Ancak aynı cihaz anahtarı farklı hesaplarda tekrar kullanılıyorsa hesap izolasyonu zayıflar. Bu nedenle cihaz bazlı yaklaşım çoğu çoklu hesap senaryosunda hesap bilgisiyle birlikte düşünülmelidir. Key title içinde cihaz adının yer alması hangi anahtarın hangi fiziksel cihaza ait olduğunu anlamayı kolaylaştırır.

Hesap + Cihaz Başına Ayrı Key

Hesap ve cihaz başına ayrı key yaklaşımı güçlü bir izolasyon sağlar. Örneğin iş laptopundaki kişisel GitHub hesabı ile aynı cihazdaki kurumsal GitHub hesabı farklı private key kullanabilir. İkinci bir cihaz devreye girdiğinde onun için de yeni anahtarlar oluşturulur. Bu modelde anahtar sayısı artar, ancak isimlendirme standardı ve SSH config sayesinde yönetim zorluğu kontrol altında tutulabilir. Cihaz kaybı veya hesap erişiminin sonlandırılması durumunda hangi key'in revoke edileceği açıkça bellidir.

Kurumsal Ortam İçin Önerilen Model

Kurumsal kullanımda hesap ve cihaz bazlı ayrı SSH key modeli çoğu durumda güçlü bir başlangıç noktasıdır. Private key'lerin passphrase ile korunması, merkezi cihaz politikaları ve düzenli key rotasyonu bu modele eklenebilir. Yüksek güvenlik gerektiren ortamlarda hardware-backed anahtarlar değerlendirilebilir. CI/CD süreçlerinde geliştirici kişisel anahtarlarının kullanılmaması ve amaca özel deploy key veya service account tercih edilmesi gerekir. Kurumsal politika, geliştirici deneyimini tamamen bozmayacak fakat erişim iptalini, audit işlemlerini ve cihaz kaybı müdahalesini kolaylaştıracak biçimde tasarlanmalıdır.

SSH Key İsimlendirme Standardı

Anahtar sayısı arttıkça dosya isimleri ve platform üzerindeki key title değerleri düzenli olmalıdır. Varsayılan id_ed25519 adı yalnızca tek anahtar kullanılan sistemlerde yeterli olabilir. Çoklu hesaplarda platform, hesap amacı ve gerekirse cihaz bilgisini dosya adına eklemek yönetimi kolaylaştırır. İsimlerin private key dosyasında hassas müşteri bilgilerini gereksiz biçimde ifşa etmemesine de dikkat edilmelidir. Basit ve tutarlı bir standart, SSH config yazarken ve anahtar rotasyonu yaparken hata ihtimalini azaltır.

Personal Key

Kişisel anahtar için dosya adında personal ifadesi kullanmak hangi kimliğe ait olduğunu açık biçimde gösterir. Örneğin id_ed25519_github_personal anlaşılır bir seçimdir. Birden fazla cihazınız varsa sonuna cihaz etiketi ekleyebilirsiniz. Platform hesabındaki key title değerinde de cihaz ve oluşturma amacı belirtilmesi faydalıdır. Böylece hesabınızın SSH key listesini incelerken hangi erişimin aktif olduğunu hızlıca anlayabilirsiniz.

Work Key

İş hesabı anahtarını kişisel anahtardan dosya adı seviyesinde ayırmak operasyonel hataları azaltır. id_ed25519_github_work gibi bir isim SSH config içinde açık biçimde okunur. Kurum birden fazla Git hosting sistemi kullanıyorsa platform adını da tutmak yararlı olabilir. Cihaz etiketinin eklenmesi rotasyon ve kayıp cihaz müdahalesinde avantaj sağlar. Dosya isminde şirketin hassas iç proje adlarını kullanmaktan kaçınmak ise iyi bir gizlilik uygulamasıdır.

Client Key

Müşteri anahtarlarında genel ve tutarlı bir isimlendirme kullanmak özellikle çok sayıda proje yöneten geliştiriciler için önemlidir. Örneğin id_ed25519_gitlab_client_a gibi bir ad, hangi platform ve bağlam için oluşturulduğunu gösterir. Müşterinin gerçek adını yerel dosya sisteminde kullanmanın uygun olup olmadığı gizlilik politikasına göre değerlendirilmelidir. Anahtar ayrımı müşteriler arası erişim sınırlarını da güçlendirir. Proje sona erdiğinde ilgili key'i hem yerelden hem platform hesabından kontrollü biçimde kaldırmak kolaylaşır.

Device Bilgisini Key Adına Eklemek

Cihaz bilgisini key adına eklemek birden fazla laptop veya geliştirme ortamı kullanan kişiler için oldukça yararlıdır. id_ed25519_github_work_laptop gibi bir ad hangi private key'in hangi cihazda üretildiğini gösterir. Platform üzerindeki key title değerinde de aynı mantık sürdürülebilir. Cihaz değiştirildiğinde eski anahtarı hızlıca bulup revoke etmek kolaylaşır. Bu yaklaşım anahtar yaşam döngüsünü kullanıcı hesabından bağımsız olarak cihaz seviyesinde yönetmenize yardımcı olur.

Örnek İsimlendirme

İsimlendirme standardı ekip içinde anlaşılır ve tekrar uygulanabilir olmalıdır. Dosya isimlerinin platform, kullanım amacı ve gerekirse cihaz bilgisini içermesi çoğu ekip için yeterlidir. Çok uzun veya anlaşılması zor kodlar kullanmak günlük kullanımda hataya neden olabilir. Anahtar yorum alanına e-posta yerine kullanım amacını veya cihazı yazmak da yönetimi destekleyebilir. Aşağıdaki örnekler kişisel, iş ve müşteri anahtarlarını açık biçimde birbirinden ayırır.

id_ed25519_github_personal

id_ed25519_github_personal kişisel GitHub hesabı için kullanılan ED25519 private key dosyasını açık biçimde tanımlar. Public key karşılığı genellikle aynı adın sonuna .pub eklenerek oluşur. SSH config içindeki github-personal host alias bu dosyayı IdentityFile olarak kullanabilir. Anahtarın passphrase ile korunması önerilir. Birden fazla cihaz varsa dosya adına cihaz etiketi eklemek daha ayrıntılı iptal ve rotasyon yönetimi sağlar.

id_ed25519_github_work

id_ed25519_github_work kurumsal GitHub hesabına ayrılmış bir ED25519 anahtarı için uygun bir isimdir. Kişisel anahtardan farklı dosyada tutulması yanlış key seçimini teşhis etmeyi kolaylaştırır. SSH config içinde github-work alias'ına bağlanabilir. Public key yalnızca ilgili iş hesabına veya kurum politikasının izin verdiği bağlama kaydedilmelidir. İş ilişkisi sona erdiğinde bu anahtarın revoke edilmesi, signing key ve diğer credential'larla birlikte offboarding sürecinin parçası olmalıdır.

id_ed25519_gitlab_client_a

id_ed25519_gitlab_client_a belirli bir müşteri bağlamındaki GitLab erişimini diğer hesaplardan ayırır. Aynı GitLab hostname'inde farklı müşteri hesapları varsa host alias kullanımı özellikle önemlidir. Örneğin gitlab-client-a yalnızca bu private key'i sunacak şekilde yapılandırılabilir. Remote URL de gerçek hostname yerine bu alias'ı kullanır. Böylece Git işlemi sırasında hangi anahtarın seçileceği yalnızca agent sırasına bırakılmaz.

ED25519 ile Ayrı SSH Key'ler Oluşturmak

Modern geliştirici ortamlarında ED25519, desteklenen sistemlerde güçlü ve kullanışlı bir SSH key seçeneğidir. Çoklu hesaplar için her kimliğe ayrı dosya adı vererek ssh-keygen ile anahtar oluşturabilirsiniz. Key comment alanı hangi hesabın veya cihazın anahtarı olduğunu anlamayı kolaylaştırabilir. Anahtar üretirken private key'e passphrase vermek yerel dosyanın güvenliğini artırır. Oluşturma işleminden sonra public key içeriğini kontrol edip doğru Git hosting hesabına eklemek gerekir.

Personal Key Oluşturma

Kişisel anahtar için özel dosya adı belirlemek varsayılan key'in üzerine yazılmasını önler. Örneğin ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_github_personal komutu kişisel kullanım için ayrı bir dosya oluşturabilir. Komut sırasında anlamlı bir comment ve güçlü passphrase girebilirsiniz. Oluşan private key'i paylaşmamalı, yalnızca .pub dosyasını platform hesabınıza eklemelisiniz. Ardından SSH config içinde bu dosyayı kişisel host alias'a bağlayabilirsiniz.

Work Key Oluşturma

İş hesabı için ikinci bir ED25519 anahtarı üretmek kişisel key'den bağımsız erişim sağlar. Örneğin ssh-keygen -t ed25519 -f ~/.ssh/id_ed25519_github_work biçiminde ayrı filename kullanılabilir. Kurumunuz key algoritması veya passphrase konusunda özel politika uyguluyorsa önce bu gereksinimlere uymalısınız. Public key yalnızca doğru kurumsal hesaba eklenmelidir. Bağlantı testini ssh -T ile yaparken gerçek hostname yerine tanımladığınız work alias'ını kullanmak anahtar eşleşmesini doğrular.

Key Comment Kullanımı

SSH public key'in sonundaki comment alanı kriptografik kimliğin kendisi değildir, fakat yönetim açısından faydalı bir etikettir. Buraya kullanım amacı, cihaz veya hesap bağlamı yazabilirsiniz. Kurumsal ortamda kişisel e-posta adresi yazmak her zaman gerekli değildir. Comment değeri daha sonra anahtarın nerede üretildiğini hatırlamanıza yardımcı olabilir. Güvenlik kararlarını comment yerine fingerprint ve platformdaki kayıt bilgilerine dayandırmak daha doğrudur.

Custom Filename Kullanımı

Custom filename çoklu hesap yönetiminde neredeyse zorunlu hâle gelir çünkü varsayılan isimler hangi key'in hangi hesaba ait olduğunu anlatmaz. Dosya adını açık belirlediğinizde SSH config ve rotasyon işlemleri daha anlaşılır olur. Aynı zamanda mevcut id_ed25519 dosyasının yanlışlıkla üzerine yazılması önlenir. Dosya yolunu IdentityFile içinde açık biçimde belirtmelisiniz. İsimlendirmeyi ekip standardı hâline getirmek yeni cihaz kurulumlarını da kolaylaştırır.

Passphrase Belirlemek

ssh-keygen anahtar oluştururken sizden passphrase isteyebilir. Bu değeri boş bırakmak yerine güçlü ve benzersiz bir passphrase kullanmak geliştirici cihazlarında genellikle daha güvenlidir. Günlük kullanımda sürekli giriş yapmamak için agent kullanılabilir. Passphrase'i script veya düz metin config içinde saklamak doğru değildir. Anahtarın passphrase'i kaybolursa private key'i kurtarmak yerine yeni anahtar oluşturup public key'i yeniden kaydetmeniz gerekebilir.

Public Key'i Kontrol Etmek

Platforma eklemeden önce doğru public key dosyasını açtığınızdan emin olun. cat ~/.ssh/id_ed25519_github_personal.pub gibi bir komut yalnızca public key içeriğini gösterir. Dosya adında .pub bulunmayan private key'i kopyalamamak çok önemlidir. Fingerprint değerini ssh-keygen -lf ile kontrol etmek de hangi anahtarla çalıştığınızı doğrulamaya yardımcı olabilir. Hesaba ekledikten sonra platformdaki fingerprint ile yerel fingerprint'i karşılaştırmak güvenli bir kayıt süreci oluşturur.

ED25519, RSA ve Hardware-Backed SSH Keys

SSH key algoritması seçimi işletim sistemi, sunucu desteği ve kurum politikasına göre değişebilir. ED25519 modern sistemlerde kısa anahtar boyutu ve güçlü güvenlik özellikleri nedeniyle yaygın bir tercihtir. RSA ise daha eski altyapılarla uyumluluk gerektiğinde hâlâ kullanılabilir, ancak key boyutu ve policy gereksinimleri dikkatle seçilmelidir. FIDO2 destekli security key modelleri private key materyalinin donanım cihazıyla ilişkilendirilmesini sağlayabilir. Kurumsal risk seviyesi yükseldikçe hardware-backed seçenekler değerlendirilmeye değer hâle gelir.

ED25519

ED25519 geliştirici SSH anahtarları için pratik bir algoritmadır ve modern OpenSSH sürümlerinde yaygın biçimde desteklenir. Anahtar dosyaları RSA'ya kıyasla daha kompakt olabilir ve oluşturma süreci oldukça basittir. Çoklu hesaplarda algoritmadan bağımsız olarak asıl önemli konu her kimlik için doğru anahtar izolasyonunun kurulmasıdır. Kurumunuz ED25519 kullanımına izin veriyorsa kişisel ve iş anahtarlarını bu algoritmayla ayrı oluşturabilirsiniz. Eski cihaz veya sunucularla uyumluluk gerekiyorsa destek durumu ayrıca doğrulanmalıdır.

RSA

RSA uzun süredir SSH ekosisteminde kullanılan bir anahtar türüdür ve eski sistemlerle uyumluluk gerektiğinde karşınıza çıkabilir. Modern kullanımda yeterli key boyutu ve güncel imza algoritmalarının desteklenmesi önemlidir. Yalnızca “her yerde çalışır” düşüncesiyle eski politika veya küçük key boyutu kullanmak doğru değildir. Yeni bir ortam kuruyorsanız mevcut sistemlerin ED25519 desteğini kontrol etmek faydalıdır. Kurum politikası RSA gerektiriyorsa key üretimi ve rotasyonu bu standarda göre yapılmalıdır.

FIDO2 Security Key

FIDO2 tabanlı SSH anahtarları authentication işlemini fiziksel bir güvenlik anahtarına bağlayabilir. Bu modelde kritik private key materyalinin donanım sınırları içinde korunması önemli bir güvenlik avantajı sağlayabilir. Bazı senaryolarda kullanıcı dokunuşu veya PIN gibi ek doğrulama adımları bulunabilir. Geliştirici deneyimi, yedek security key planı ve cihaz desteği önceden değerlendirilmelidir. Özellikle yüksek ayrıcalıklı kurumsal hesaplarda hardware-backed SSH key kullanımı güçlü bir seçenek olabilir.

ed25519-sk

ed25519-sk security key destekli SSH anahtar türlerinden biridir. Buradaki -sk eki anahtarın güvenlik anahtarıyla ilişkili olduğunu gösterir. Kullanılabilirlik işletim sistemi, OpenSSH sürümü ve fiziksel cihaz desteğine bağlıdır. Çoklu hesaplarda her hesap için ayrı resident veya non-resident credential planı kurum politikasına göre tasarlanabilir. Fiziksel anahtar kaybına karşı yedek donanım ve revoke prosedürü önceden hazırlanmalıdır.

ecdsa-sk

ecdsa-sk FIDO2 uyumlu security key'lerle kullanılabilen diğer SSH key türlerinden biridir. Destek durumu kullanılan donanım ve yazılım ortamına göre farklılık gösterebilir. Hardware-backed key kullanırken yalnızca algoritmayı değil, fiziksel güvenlik anahtarının saklama ve yedek politikasını da düşünmek gerekir. Cihaz kaybolduğunda ilgili public key kayıtları hızlıca revoke edilmelidir. Kurumsal ekiplerde security key envanteri ve erişim sahipliği takibi bu süreci daha yönetilebilir hâle getirir.

Kurumsal Kullanımda Hardware Key Ne Zaman Tercih Edilmeli?

Hardware-backed SSH key özellikle yüksek ayrıcalıklı hesaplar, üretim erişimi veya hassas kaynak kod depoları için değerlendirilebilir. Fiziksel cihaz zorunluluğu, yalnızca diskteki key dosyasının ele geçirilmesiyle erişim sağlanmasını zorlaştırır. Bunun karşılığında kayıp cihaz, yedek anahtar ve uzaktan çalışan ekiplerin destek süreci planlanmalıdır. Her geliştirici iş akışına aynı seviyede zorunluluk koymak yerine risk tabanlı bir model uygulanabilir. Kurumun kimlik sağlayıcısı, endpoint yönetimi ve Git hosting politikasıyla birlikte değerlendirilmesi en sağlıklı yaklaşımdır.

Public Key'leri GitHub ve GitLab Hesaplarına Eklemek

Public key üretildikten sonra doğru hesaba kaydedilmesi çoklu hesap düzeninin kritik adımlarından biridir. Personal key'i iş hesabına veya work key'i kişisel hesaba eklemek SSH config doğru olsa bile beklenmedik authentication sonuçları üretir. Platform üzerindeki key title alanını cihaz ve amaç bilgisiyle doldurmak daha sonra yapılacak denetimi kolaylaştırır. Authentication key ve signing key kullanım türleri desteklenen platform özelliklerine göre ayrıca değerlendirilmelidir. Kayıt sonrasında fingerprint ve ssh -T testiyle eşleşmeyi doğrulamak iyi bir alışkanlıktır.

Personal Account

Kişisel hesaba yalnızca kişisel kullanım için üretilmiş public key'i eklemek erişim sınırlarını net tutar. Key title içinde cihaz adı veya üretim tarihi gibi bilgi bulunması daha sonra eski cihazları tanımayı kolaylaştırır. Birden fazla cihaz kullanıyorsanız her cihazın ayrı public key'i olabilir. Böylece bir cihaz kaybolduğunda diğer cihazların erişimi etkilenmez. Platformda uzun süredir kullanılmayan key'leri belirli aralıklarla gözden geçirmek de güvenli bir yaşam döngüsü yönetimi sağlar.

Work Account

Work account için oluşturulan public key kurumun izin verdiği hesap veya enterprise ortamına eklenmelidir. Kurum SSO authorization gibi ek adımlar istiyorsa key kaydı tek başına yeterli olmayabilir. Key title standardının ekip genelinde uygulanması güvenlik ekiplerinin erişimleri yorumlamasını kolaylaştırır. Kişisel cihazdan kurumsal hesaba erişim izni olup olmadığını şirket politikasına göre kontrol etmek gerekir. İşten ayrılma veya cihaz değişimi sırasında bu kayıtların revoke edilmesi erişim kapatma sürecinin temel parçalarından biridir.

Key Title Standardı

Key title değeri anahtarın hangi cihazda ve hangi amaçla kullanıldığını hızlıca anlatmalıdır. Örneğin “work-laptop-2026” benzeri bir etiket basit ve açıklayıcıdır. Çok ayrıntılı proje veya müşteri bilgilerini title içine koymak her zaman gerekli değildir. Aynı standardın tüm geliştiricilerde kullanılması audit ve offboarding işlemlerini kolaylaştırır. Fingerprint her zaman asıl teknik doğrulama noktası olarak kullanılmalı, title ise insan tarafından okunabilir yönetim etiketi olarak görülmelidir.

Authentication Key

Authentication key Git işlemleri sırasında SSH bağlantısını doğrulamak için kullanılan public key kaydıdır. Bu anahtar repository erişimine bağlı kullanıcı hesabınızı belirlemeye yardımcı olur. Authentication key'in signing amacıyla kullanılması desteklense bile iki kullanımın anlamı birbirinden farklıdır. Kurumsal politika iki ayrı anahtar gerektiriyorsa bu ayrımı korumak gerekir. Hangi key'in hangi kullanım türünde kayıtlı olduğunu platform ayarlarında düzenli olarak kontrol etmek faydalıdır.

Signing Key

Signing key commit veya tag imzalarının platform tarafından doğrulanmasına yardımcı olan anahtar kaydıdır. SSH signing kullanıldığında public key'in signing amacıyla ayrıca kaydedilmesi gerekebilir. Authentication başarılı olsa bile signing kaydı yoksa commit Verified görünmeyebilir. Çoklu hesaplarda kişisel ve iş signing key'lerini ayrı yönetmek commit kimliğinin bağlama uygun kalmasını sağlar. Conditional Git config bu seçim işlemini otomatikleştirmek için kullanılabilir.

Fingerprint ile Doğrulama

Fingerprint anahtarın kısa ve güvenilir bir tanımlayıcısıdır. Dosya adı veya comment değişse bile aynı anahtar materyalinin fingerprint'i karşılaştırma için kullanılabilir. ssh-keygen -lf ~/.ssh/id_ed25519_github_work.pub gibi bir komut yerel public key fingerprint'ini gösterir. Platform tarafında görüntülenen değerle eşleştirme yaparak yanlış key yükleme riskini azaltabilirsiniz. Rotasyon sırasında eski ve yeni anahtarları ayırmak için de fingerprint kaydı oldukça yararlıdır.

SSH File Permission'ları

OpenSSH private key ve config dosyalarının erişim izinlerine dikkat eder. Çok geniş izinler private key'in güvenlik nedeniyle reddedilmesine yol açabilir. Unix benzeri sistemlerde ~/.ssh dizini ve private key dosyaları yalnızca gerekli kullanıcıya açık tutulmalıdır. Public key dosyaları gizli değildir, fakat yine de düzenli izin modeli tercih edilir. Permission hatası gördüğünüzde dosya sahipliğini ve izinleri kontrol etmek authentication sorununu hızla çözebilir.

~/.ssh Directory Permission

~/.ssh dizini genellikle yalnızca kullanıcı tarafından erişilebilir olacak biçimde korunmalıdır. Unix sistemlerde chmod 700 ~/.ssh yaygın kullanılan bir ayardır. Ancak sisteminizin güvenlik modeli ve dosya sistemi özellikleri farklı olabilir. Dizin başka kullanıcılar tarafından yazılabilir durumdaysa SSH bunu güvenlik riski olarak görebilir. Ayrıca dosyanın sahibi yanlış kullanıcıysa yalnızca chmod uygulamak yeterli olmayabilir.

Private Key Permission

Private key dosyasının yalnızca sahibi tarafından okunabilir veya yazılabilir olması beklenir. Unix benzeri sistemlerde chmod 600 ~/.ssh/id_ed25519_github_work yaygın bir örnektir. Çok geniş izinler OpenSSH tarafından “bad permissions” veya benzeri mesajlarla reddedilebilir. Dosyanın gerçekten private key olduğundan emin olmak da önemlidir. Windows tarafında izin modeli farklı olduğundan ACL ve OpenSSH davranışı işletim sistemine göre değerlendirilmelidir.

Public Key Permission

Public key gizli bilgi değildir ve dağıtılmak üzere tasarlanmıştır. Buna rağmen ~/.ssh klasörü içinde düzenli ve sahibi belli bir izin modeli kullanmak iyi bir pratiktir. Çoğu Unix sisteminde 644 gibi izinler public key için yeterlidir. Authentication işlemi esas olarak private key'in güvenliği ve sahipliğiyle ilgilidir. Public key dosyasını yanlışlıkla private key sanıp platforma yüklememek için dosya adlarını açık tutmak önemlidir.

config Permission

~/.ssh/config dosyası hangi host için hangi kullanıcı, key ve agent ayarının kullanılacağını içerir. Bu nedenle başka kullanıcılar tarafından değiştirilememesi önemlidir. Unix ortamında chmod 600 ~/.ssh/config veya sistem politikasına uygun benzer bir ayar kullanılabilir. Dosya içinde secret tutulmaması gerekir, ancak yapılandırmanın değiştirilmesi bağlantı yönünü etkileyebilir. İzin sorunlarında SSH'ın config dosyasını görmezden gelip görmediğini debug çıktısından kontrol edebilirsiniz.

Permission Hatalarını Teşhis Etmek

Permission problemi yaşadığınızda yalnızca private key'i değil, üst dizinleri ve dosya sahipliğini de incelemek gerekir. ls -la ~/.ssh gibi komutlar Unix sistemlerde hızlı bir genel görünüm sağlar. SSH debug çıktısı bazen hangi dosyanın reddedildiğine dair açık mesaj verir. Windows'ta ACL yapısı için PowerShell ve dosya güvenlik ayarları kullanılabilir. Sorunu çözmek için internetten rastgele geniş chmod değerleri uygulamak yerine minimum gerekli izinleri korumak daha güvenlidir.

~/.ssh/config ile Çoklu Hesap Yönetimi

~/.ssh/config, birden fazla Git hesabı için SSH key nasıl yönetilir sorusunun en kullanışlı cevaplarından biridir. Host alias kullanarak aynı gerçek hostname'i birden fazla mantıksal kimliğe bölebilirsiniz. Her alias kendi IdentityFile ve IdentitiesOnly ayarına sahip olur. Git remote URL'sinde gerçek hostname yerine alias kullanıldığında SSH doğru private key'i seçer. Bu yöntem IDE, Git CLI ve submodule gibi farklı araçlarla çalışırken merkezi bir SSH kimlik yönlendirme katmanı sağlar.

SSH Config Nedir?

SSH config, bağlantı hedeflerine göre istemci davranışını tanımlayan yapılandırma dosyasıdır. Burada hostname, kullanıcı adı, port, identity file ve agent gibi birçok seçenek ayarlanabilir. Çoklu Git hesabında en önemli kullanım şekillerinden biri aynı sunucu için farklı host alias'lar oluşturmaktır. Böylece github-personal ve github-work aynı github.com adresine giderken farklı key kullanabilir. Config dosyası büyüdükçe blok sırası ve eşleşme kurallarını ssh -G ile doğrulamak yararlıdır.

Host Alias Nedir?

Host alias, gerçek sunucu adına yerelde verdiğiniz mantıksal isimdir. Örneğin github-work adlı alias'ın HostName github.com değerine gitmesini sağlayabilirsiniz. Git remote adresi git@github-work:organization/repository.git olduğunda SSH bu alias bloğunu kullanır. Böylece gerçek sunucu değişmeden hesap seçimi remote URL üzerinden yapılır. Çoklu hesaplarda bu yöntem hem okunaklı hem de debug edilmesi kolay bir yapı sunar.

HostName

HostName alias'ın gerçekte bağlanacağı sunucuyu belirler. Host github-work bloğunda HostName github.com kullanıldığında kullanıcı yalnızca alias ile çalışır, fakat ağ bağlantısı github.com adresine gider. Aynı gerçek hostname birden fazla alias tarafından kullanılabilir. Farklı alias'lar farklı IdentityFile değerlerine sahip olabilir. Bu ayrım SSH authentication kimliğini remote URL üzerinden yönetmenizi sağlar.

User

GitHub ve benzeri SSH tabanlı Git hizmetlerinde SSH kullanıcı adı çoğunlukla git şeklindedir. Bu değer platform hesabınızın kullanıcı adı değildir. Hesap eşleşmesi public key üzerinden yapılır. Dolayısıyla personal ve work alias bloklarında User git aynı kalırken IdentityFile değişebilir. Kullanıcı adını yanlış biçimde platform username'i yapmaya çalışmak bağlantı sorunlarına yol açabilir.

IdentityFile

IdentityFile belirli host bloğunda kullanılacak private key dosyasının yolunu tanımlar. Personal alias için kişisel, work alias için iş key'inin yolu verilmelidir. Dosya adlarını açık seçmek config dosyasının okunmasını kolaylaştırır. Agent kullanıyor olsanız bile IdentityFile hangi kimliğin hedeflendiğini açıkça belirtir. IdentitiesOnly yes ile birlikte kullanıldığında agent içindeki ilgisiz key'lerin sunulmasını sınırlandırabilirsiniz.

IdentitiesOnly

IdentitiesOnly yes, SSH'ın özellikle tanımlanan identity'leri kullanmasını sağlamaya yardımcı olur. Çok sayıda key yüklenmiş bir agent ortamında bu ayar oldukça değerlidir. Aksi durumda agent içindeki anahtarların sırayla sunulması yanlış hesap veya “too many authentication failures” problemi oluşturabilir. Host alias ve IdentityFile ile birlikte kullanıldığında authentication davranışı daha belirgin hâle gelir. Çoklu hesap düzenlerinde ben bu ayarı temel güvenlik ve hata önleme kontrollerinden biri olarak görüyorum.

Personal ve Work GitHub İçin Host Alias Yapısı

Personal ve work GitHub hesaplarını ayırmanın pratik yolu aynı github.com host'una iki farklı alias tanımlamaktır. Örneğin kişisel hesap için github-personal, iş hesabı için github-work kullanılabilir. Her blokta HostName github.com, User git, ilgili IdentityFile ve IdentitiesOnly yes bulunur. Repository remote adresi hangi alias'ı içeriyorsa o key devreye girer. Bu yapı yalnızca bağlantıyı değil, debug ve yeni geliştirici onboarding sürecini de kolaylaştırır.

github-personal

github-personal kişisel GitHub authentication kimliğini temsil eden yerel SSH alias olabilir. Bu alias gerçek github.com hostname'ine yönlendirilir ve yalnızca kişisel private key'i kullanacak şekilde yapılandırılır. Kişisel repository clone ederken git@github-personal:kullanici/repo.git benzeri remote kullanılabilir. ssh -T git@github-personal testi dönen kullanıcı bilgisini doğrulamanıza yardımcı olur. Böylece kişisel ve kurumsal hesap seçiminde agent'ın tesadüfi sırasına güvenmezsiniz.

github-work

github-work alias iş GitHub hesabına ait SSH key'i seçmek için kullanılabilir. HostName github.com aynı kalırken IdentityFile work key dosyasını gösterir. Kurumsal repository'lerin remote URL'leri bu alias'a göre ayarlanmalıdır. Bağlantı testi sırasında platformun hangi kullanıcıyla authentication yaptığını kontrol etmek önemlidir. Bu yöntem farklı Git hesapları için user name email ve SSH identity nasıl ayarlanır sürecinin SSH tarafını açık biçimde çözer.

İki Alias'ın Aynı github.com Host'una Gitmesi

Alias'ların farklı olması gerçek sunucuların farklı olduğu anlamına gelmez. Her iki host bloğu HostName github.com kullanabilir. SSH config, alias üzerinden hangi seçeneklerin uygulanacağını belirler ve ardından gerçek hostname'e bağlanır. Böylece DNS veya platform tarafında herhangi bir değişiklik yapmanız gerekmez. Ayrım tamamen yerel SSH istemcisinde gerçekleşir.

Her Alias'ın Farklı Key Kullanması

Çoklu hesap tasarımının temel amacı her alias'ı belirli bir identity'ye bağlamaktır. Personal alias kişisel private key'i, work alias ise kurumsal private key'i kullanır. IdentitiesOnly yes bu ayrımın agent tarafından bozulmasını önlemeye yardımcı olur. Remote URL alias'ı açık biçimde taşıdığı için repository'nin hangi hesaba yönlendirildiğini görmek de kolaydır. Bir problem çıktığında ssh -G alias ile effective config kontrol edilebilir.

IdentitiesOnly yes Neden Kritik?

IdentitiesOnly yes, özellikle birden fazla private key'in ssh-agent içinde yüklü olduğu geliştirme bilgisayarlarında önemli bir kontrol mekanizmasıdır. SSH normal davranışta agent tarafından sunulan farklı identity'leri deneyebilir. Bu durum aynı host üzerinde birden fazla hesabınız olduğunda yanlış key'in önce sunulmasına yol açabilir. Bazı sunucular belirli sayıda başarısız denemeden sonra bağlantıyı sonlandırabilir. Hedef host için açıkça tanımlanan identity'yi kullanmak authentication sürecini daha deterministik hâle getirir.

ssh-agent'ın Birden Fazla Key Sunması

ssh-agent aynı anda birden fazla private key'i açık durumda tutabilir. SSH istemcisi bağlantı sırasında agent içindeki identity'lerden yararlanabilir. Çoklu hesaplarda bu özellik kullanışlı olmakla birlikte hangi key'in sunulduğunun kontrol edilmemesi sorun yaratır. Özellikle yıllar içinde agent'a birçok key ekleyen kullanıcılar beklenmedik authentication davranışı görebilir. ssh-add -l ile agent'daki key'leri düzenli olarak kontrol etmek faydalıdır.

Yanlış Key'in Önce Sunulması

Sunucuya ilk sunulan anahtar hedef hesap için doğru olmayabilir. Bazı platformlar yanlış public key'i başka bir hesabınızla eşleştirirse authentication beklemediğiniz kullanıcıyla başarılı bile olabilir. Bu durumda işlem hata vermediği için sorunu fark etmek daha zorlaşır. Host alias, IdentityFile ve IdentitiesOnly yes üçlüsü bu riski azaltır. Bağlantı sonrası dönen kullanıcı adını test etmek yalnızca “başarılı” mesajına bakmaktan daha güvenlidir.

GitHub'ın Hesabı SSH Key'den Tanıması

GitHub SSH bağlantısında platform kullanıcı adınızı SSH komutundaki kullanıcı adından çıkarmaz. Genellikle SSH kullanıcısı git olarak kalır ve hesabınız kabul edilen public key üzerinden belirlenir. Bu nedenle yanlış key'in kabul edilmesi yanlış hesapla authentication anlamına gelebilir. Remote repository erişiminiz iki hesapta da varsa hata hemen görünmeyebilir. ssh -T çıktısındaki hesabı kontrol etmek bu nedenle önemlidir.

Too Many Authentication Failures

Bir SSH istemcisi sunucuya art arda çok fazla uygun olmayan identity sunarsa sunucu authentication denemelerini sınırlandırabilir. Sonuçta doğru key sırada daha sonra olsa bile bağlantı kesilebilir. Bu durum agent içinde çok sayıda key bulunan sistemlerde görülebilir. IdentitiesOnly yes ve doğru IdentityFile kullanımı sunulan key listesini daraltır. Debug için ssh -vT hangi key'lerin sırayla offer edildiğini gösterir.

Deterministic SSH Authentication

Deterministic authentication, aynı remote ve aynı config ile her seferinde beklenen key'in kullanılması anlamına gelir. Çoklu hesaplarda güvenilir geliştirici deneyimi için bu özellik önemlidir. Host alias remote URL'ye kimlik bağlamı ekler, IdentityFile key'i seçer ve IdentitiesOnly yes gereksiz agent identity'lerini sınırlar. Böylece “hangi key önce denk gelirse” yaklaşımından uzaklaşırsınız. Sistem büyüdükçe bu öngörülebilirlik debug ve güvenlik açısından daha değerli hâle gelir.

SSH Bağlantısını Nasıl Test Ederiz?

SSH config yazdıktan sonra doğrudan repository push etmeye geçmek yerine bağlantıyı ayrı olarak test etmek daha güvenlidir. ssh -T hedef alias için authentication işlemini gerçekleştirir ve çoğu Git hosting platformu hangi hesapla doğrulandığınızı belirten bir yanıt verir. Personal ve work alias ayrı ayrı test edilmelidir. Bağlantının başarılı olması repository erişiminin otomatik olarak var olduğu anlamına gelmez. Önce SSH kimliğini, ardından repository authorization durumunu ayrı aşamalar olarak değerlendirmek debug sürecini kolaylaştırır.

ssh -T

ssh -T komutu interaktif terminal tahsis etmeden SSH authentication test etmek için kullanılabilir. Git hosting platformları çoğu zaman shell erişimi vermediği için başarılı bağlantının ardından özel bir bilgilendirme mesajı döndürür. Testi gerçek hostname yerine config alias ile yapmak çoklu hesap seçim mantığını da doğrular. Beklenmeyen kullanıcı adı görürseniz repository işlemlerine geçmeden önce config'i düzeltmelisiniz. Daha ayrıntılı inceleme gerektiğinde -v seçenekleri eklenebilir.

Personal Alias Testi

Kişisel alias için ssh -T git@github-personal benzeri bir komut çalıştırılabilir. Dönen mesajın kişisel hesabınızı tanımladığından emin olun. Yanlış hesap görünüyorsa ssh -G github-personal ve ssh -vT ile kullanılan identity'yi inceleyin. Public key'in doğru kişisel hesapta kayıtlı olup olmadığını da kontrol edin. Test başarılı olduktan sonra kişisel repository remote URL'sini aynı alias ile tanımlayabilirsiniz.

Work Alias Testi

Work alias için benzer şekilde ssh -T git@github-work kullanılabilir. Burada platformun kurumsal hesabı tanıması gerekir. Personal kullanıcı adı dönüyorsa iş repository'sine push etmeden önce sorunu çözmek önemlidir. IdentityFile, agent içeriği ve platformdaki public key kayıtları karşılaştırılmalıdır. Kurumsal SSO gerekiyorsa key'in ilgili organization için yetkilendirilmiş olması da gerekebilir.

Dönen Username'i Kontrol Etmek

Bağlantı testinin en değerli çıktılarından biri platformun sizi hangi hesap olarak tanıdığını göstermesidir. Yalnızca exit durumuna veya “authenticated” ifadesine bakmak yeterli değildir. Personal alias personal username, work alias work username döndürmelidir. Beklenmeyen sonuç çoğu zaman yanlış public key kaydı veya yanlış identity seçiminden kaynaklanır. Bu kontrolü yeni key ekleme ve rotasyon işlemlerinden sonra tekrar yapmak iyi bir alışkanlıktır.

Başarılı Authentication ile Shell Access Arasındaki Fark

Git hosting hizmetleri SSH üzerinden Git protokolüne erişim verirken genel shell erişimi sağlamayabilir. Bu nedenle ssh -T başarılı authentication sonrasında “shell access is not provided” benzeri bir mesaj döndürebilir. Bu durum tek başına hata değildir. Önemli olan authentication'ın doğru kullanıcıyla başarılı olduğunu doğrulamaktır. Repository erişimi daha sonra Git clone, fetch veya push işlemi üzerinden ayrı olarak test edilir.

SSH Debugging

SSH sorunlarını çözerken debug çıktısı tahmin yürütmekten çok daha güvenilir bilgi sağlar. -v, -vv ve -vvv seviyeleri giderek daha ayrıntılı bağlantı bilgisi gösterir. Hangi config dosyasının okunduğu, hangi identity'nin offer edildiği ve sunucunun hangi anahtarı kabul ettiği bu çıktıda görülebilir. Çoklu hesaplarda özellikle agent ile IdentityFile etkileşimini anlamak için bu bilgiler değerlidir. Debug çıktısını paylaşmanız gerektiğinde kullanıcı adı, path veya diğer hassas bilgileri kontrol etmeyi unutmayın.

ssh -vT

ssh -vT çoğu authentication probleminde ilk debug seviyesidir. Çıktı config eşleşmeleri, bağlantı hedefi ve anahtar teklifleri hakkında yeterli ayrıntı verir. Hangi identity file'ın yüklendiğini ve hangi public key'in offer edildiğini takip edebilirsiniz. Personal alias için work key görülüyorsa config bloğu veya eşleşme sırası incelenmelidir. Sorunu çözdükten sonra normal ssh -T testiyle sonucu doğrulamak yeterlidir.

ssh -vvT

ssh -vvT birinci debug seviyesinin yeterli olmadığı durumlarda daha ayrıntılı protokol bilgisi sağlar. Agent iletişimi, algoritma seçimi ve authentication adımları daha geniş biçimde görülebilir. Çoklu hesap probleminde çoğu zaman gerekli olmayabilir, fakat karmaşık config veya proxy kullanımı varsa yardımcı olur. Çıktı oldukça uzun olabileceği için anahtar kelimeler üzerinden incelemek daha pratiktir. Özellikle identity file, Offering public key ve Server accepts key satırları önemlidir.

ssh -vvvT

ssh -vvvT en ayrıntılı standart debug seviyelerinden biridir. Basit yanlış key probleminde doğrudan bu seviyeye çıkmak gereksiz bilgi oluşturabilir. ProxyJump, agent socket, host key veya algoritma uyuşmazlığı gibi daha karmaşık sorunlarda faydalıdır. Çıktıyı başka biriyle paylaşmadan önce dosya yolları ve ortam bilgileri açısından gözden geçirmek gerekir. Sistematik debug için önce -v, gerekirse daha yüksek seviyeler kullanmak daha okunabilir bir süreç sağlar.

Hangi IdentityFile Kullanılıyor?

Hangi private key dosyasının hedef host için tanımlandığını görmek çoklu hesap sorunlarının temel kontrolüdür. ssh -G github-work effective config içindeki identityfile değerlerini gösterebilir. Debug çıktısı da dosyanın gerçekten kullanılmaya çalışılıp çalışılmadığını gösterir. Birden fazla eşleşen host bloğu varsa beklemediğiniz ek identity değerleri görülebilir. Config dosyasındaki wildcard blokları bu nedenle dikkatle incelenmelidir.

Hangi Public Key Offer Ediliyor?

SSH debug çıktısında Offering public key satırları istemcinin sunucuya hangi key'leri teklif ettiğini gösterir. Bu bilgi agent içindeki key'lerin beklenmedik biçimde devreye girip girmediğini anlamak için önemlidir. Work alias bağlantısında personal key offer ediliyorsa IdentitiesOnly veya config eşleşmesini kontrol etmelisiniz. Key fingerprint'lerini yerel dosyalarla karşılaştırmak hangi anahtarın sunulduğunu kesinleştirir. Böylece yalnızca dosya adlarına güvenmeden gerçek authentication akışını izleyebilirsiniz.

Server Hangi Key'i Kabul Ediyor?

Debug çıktısı sunucunun hangi public key'i kabul ettiğini de gösterebilir. Bu satır, authentication'ın beklediğiniz key üzerinden gerçekleşip gerçekleşmediğini doğrulamak için değerlidir. Yanlış key kabul ediliyorsa aynı public key'in başka hesapta kayıtlı olup olmadığını veya alias'ın yanlış identity kullandığını inceleyin. Platformun döndürdüğü username ile birlikte değerlendirildiğinde sorun daha kolay anlaşılır. Rotasyon sonrasında eski key'in artık kabul edilmediğini test etmek için de bu yöntem kullanılabilir.

Effective SSH Config Nasıl Görülür?

SSH config dosyası büyüdükçe yalnızca dosyayı okumak hedef host için hangi seçeneklerin gerçekten geçerli olduğunu anlamaya yetmeyebilir. ssh -G eşleşen config bloklarını değerlendirerek effective ayarları gösterir. IdentityFile, HostName, User ve IdentityAgent gibi değerleri burada inceleyebilirsiniz. Wildcard host bloklarının beklenmedik etkisini bulmak için bu komut oldukça yararlıdır. Çoklu hesap problemi yaşadığımda debug çıktısından önce kontrol ettiğim araçlardan biri genellikle effective config görünümüdür.

ssh -G

ssh -G github-work komutu belirtilen hedef için hesaplanan SSH istemci ayarlarını listeler. Ağ bağlantısı kurmadan config çözümlemesini görmenizi sağlar. Bu nedenle yanlış HostName veya IdentityFile gibi sorunları hızlıca fark edebilirsiniz. Birden fazla config dosyası veya Include kullanıyorsanız sonuç daha da değerlidir. Çıktıda beklenmeyen identity'ler varsa hangi host bloklarının eşleştiğini config sırasına göre incelemek gerekir.

IdentityFile

Effective config çıktısındaki identityfile satırları hedef alias için kullanılabilecek key dosyalarını gösterir. Work alias altında yalnızca work key bekliyorsanız personal key görülmesi yapılandırma probleminin işaretidir. Genel Host * blokları ilave identity tanımlıyor olabilir. IdentitiesOnly yes kullanımı da bu davranışı kontrol altına almaya yardımcı olur. Key dosyasının gerçekten mevcut ve doğru izinlere sahip olduğunu ayrıca kontrol etmek gerekir.

IdentityAgent

IdentityAgent SSH istemcisinin hangi agent socket üzerinden anahtarlara erişeceğini etkileyebilir. Özellikle macOS, WSL, desktop agent veya özel agent araçları kullanılan sistemlerde bu değer önem kazanır. Yanlış socket'e bağlanmak “agent'da key var ama SSH görmüyor” türü sorunlara yol açabilir. SSH_AUTH_SOCK ortam değişkeniyle birlikte değerlendirilmelidir. Birden fazla agent problemi yaşıyorsanız effective config ve shell ortamını aynı anda kontrol etmek gerekir.

HostName

Effective config içindeki hostname değeri alias'ın gerçekten hangi sunucuya gittiğini doğrular. Yanlış yazılmış alias veya başka bir host bloğundan gelen override beklenmedik sunucuya bağlantı oluşturabilir. Personal ve work alias'ların aynı github.com değerine gitmesi normaldir. Ayrım diğer seçeneklerde, özellikle IdentityFile üzerinde gerçekleşir. Enterprise kullanıyorsanız hostname değerinin kurumun gerçek domain'ine yöneldiğinden emin olun.

User

user değeri SSH protokolünde kullanılan uzak kullanıcı adını gösterir. Git hosting platformlarında çoğu zaman git kullanılır. Bu değer platformdaki account username'inizle karıştırılmamalıdır. Personal ve work alias aynı SSH user değerine sahip olabilir. Hesap seçimi kabul edilen public key üzerinden gerçekleşir.

Birbiriyle Çakışan Host Bloklarını Bulmak

SSH config içinde Host *, wildcard desenleri ve özel alias blokları birlikte kullanıldığında beklenmedik eşleşmeler oluşabilir. Effective config çıktısı bu çakışmaları sonuç seviyesinde görmenizi sağlar. Aynı option birden fazla blokta tanımlanıyorsa OpenSSH config değerlendirme kurallarını dikkate almak gerekir. Özel alias bloklarını açık ve anlaşılır tutmak debug sürecini kolaylaştırır. Büyük config dosyalarında amaç bazlı Include kullanımı da bakım maliyetini azaltabilir.

ssh-agent Nedir?

ssh-agent, private key dosyasını diskten silmeden veya passphrase korumasını kaldırmadan günlük SSH kullanımını kolaylaştırır. Kullanıcı bir key'i passphrase ile açıp agent'a eklediğinde ilgili key belirli bir agent oturumu boyunca kullanılabilir. Böylece her push işleminde passphrase tekrar yazmak gerekmez. Agent private key dosyanızın güvenlik gereksinimini ortadan kaldırmaz; aksine açık key'in bellekte tutulması yeni güvenlik sorumlulukları getirir. Socket erişimi, oturum yaşam süresi ve workstation kilidi bu nedenle önemlidir.

Private Key'i Diskten Silmeden Ne Sağlar?

ssh-agent private key dosyasını kalıcı olarak başka formata dönüştürmez veya diskten kaldırmaz. Anahtar dosyası passphrase ile korunmaya devam eder. Agent, kilidi açılmış identity'yi belirli bir oturum süresince kullanıma hazır tutar. Böylece Git ve SSH süreçleri gerekli imzalama işlemlerini agent üzerinden gerçekleştirebilir. Anahtar dosyası ve agent güvenliği ayrı katmanlar olarak değerlendirilmelidir.

Unlocked Key'i Bellekte Tutmak

Agent'a eklenen key, kullanım için bellekte erişilebilir bir state içinde tutulur. Bu davranış passphrase tekrarını azaltır, fakat çalışan kullanıcı oturumunun güvenliğini daha önemli hâle getirir. Zararlı bir süreç veya agent socket'e erişebilen başka bir süreç anahtarı kullanmaya çalışabilir. Bu nedenle cihaz kilidi ve malware koruması önemlidir. Yüksek riskli ortamlarda agent lifetime veya onay gerektiren hardware key modelleri değerlendirilebilir.

Passphrase'i Her Push'ta Yazmamak

Passphrase kullanımının en sık dile getirilen dezavantajı tekrar tekrar giriş yapma gereksinimidir. Agent bu problemi private key'in passphrase korumasını kaldırmadan çözer. Anahtarı oturum başında bir kez açıp belirli süre boyunca kullanabilirsiniz. macOS gibi sistemlerde Keychain entegrasyonu yeniden başlatma sonrası deneyimi daha da kolaylaştırabilir. Güvenlik açısından süresiz açık agent yerine kullanım bağlamına uygun bir yaşam süresi seçmek daha kontrollüdür.

SSH_AUTH_SOCK

SSH_AUTH_SOCK ortam değişkeni çalışan shell'in hangi SSH agent socket'iyle iletişim kuracağını gösterir. Birden fazla agent çalışan sistemlerde yanlış socket'e işaret etmek beklenmedik key listelerine neden olabilir. echo $SSH_AUTH_SOCK Unix benzeri ortamlarda mevcut değeri görmenizi sağlar. WSL, container veya remote development senaryolarında socket forwarding yapısı ayrıca önem kazanır. Agent problemi araştırırken yalnızca ssh-add -l değil, hangi socket'in kullanıldığını da kontrol etmek gerekir.

ssh-agent ile Passphrase Yönetimi

SSH passphrase ssh-agent ve keychain ile Git anahtar yönetimi kurulurken amaç private key'i korumak ve geliştirici deneyimini sürdürülebilir tutmaktır. Agent başlatıldıktan sonra gerekli key'ler ssh-add ile yüklenebilir. Hangi key'lerin açık olduğunu düzenli kontrol etmek özellikle çoklu hesaplarda önemlidir. Gereksiz key'ler agent'dan kaldırılabilir ve kritik ortamlarda yaşam süresi sınırı kullanılabilir. Agent davranışı işletim sistemi ve masaüstü oturum yöneticisine göre değişebileceği için kalıcı yapılandırma platforma özel ele alınmalıdır.

Agent Başlatma

Unix benzeri sistemlerde agent eval "$(ssh-agent -s)" benzeri yöntemlerle shell oturumu için başlatılabilir. Masaüstü ortamları çoğu zaman kendi agent'ını zaten başlatabilir. Aynı anda ikinci agent oluşturmak farklı shell'lerin farklı key listeleri görmesine neden olabilir. Bu nedenle yeni agent başlatmadan önce SSH_AUTH_SOCK değerini ve ssh-add -l çıktısını kontrol etmek faydalıdır. Kalıcı kullanım için işletim sisteminin önerdiği session veya service yöntemi tercih edilmelidir.

Key Ekleme

Bir private key'i agent'a eklemek için ssh-add ~/.ssh/id_ed25519_github_work kullanılabilir. Anahtar passphrase ile korunuyorsa komut sizden passphrase ister. Başarılı işlemden sonra key agent oturumu boyunca kullanılabilir. Personal ve work key'leri ayrı ayrı eklemek mümkündür. Buna rağmen host config tarafında IdentitiesOnly kullanmak hangi bağlantının hangi key'i seçeceğini kontrol altında tutar.

Yüklü Key'leri Listeleme

ssh-add -l agent tarafından bilinen key'lerin fingerprint listesini gösterir. Çoklu hesap sorunlarında bu komut hangi anahtarların agent'da açık olduğunu hızlıca anlamanızı sağlar. Fingerprint'leri yerel public key dosyalarıyla karşılaştırabilirsiniz. Beklemediğiniz eski veya müşteri anahtarları görüyorsanız ihtiyaç yoksa agent'dan kaldırmak iyi bir uygulamadır. Liste boşsa doğru agent socket'e bağlı olup olmadığınızı da kontrol etmelisiniz.

Tek Bir Key'i Kaldırma

Belirli bir key'i agent'dan kaldırmak tüm diğer identity'leri etkilemeden erişimi kapatmanızı sağlar. ssh-add -d ~/.ssh/id_ed25519_github_work gibi bir komut kullanılabilir. Anahtar dosyası diskten silinmez, yalnızca agent oturumundaki açık identity kaldırılır. Yeniden kullanmak istediğinizde ssh-add ile tekrar ekleyebilirsiniz. Paylaşılan veya hassas çalışma ortamında iş bitiminde kritik key'leri agent'dan çıkarmak faydalı olabilir.

Tüm Key'leri Agent'dan Temizleme

ssh-add -D agent içinde tutulan tüm identity'leri kaldırmak için kullanılabilir. Çok sayıda eski key nedeniyle authentication sırası karıştıysa temiz bir başlangıç yapmak yararlı olabilir. Sonrasında yalnızca gerekli personal ve work key'leri yeniden ekleyebilirsiniz. Bu işlem disk üzerindeki private key dosyalarını silmez. Agent'da anahtar kalmaması, ilgili platform kayıtlarını revoke ettiği anlamına da gelmez.

Agent Oturumu Ne Zaman Sona Erer?

Agent yaşam süresi nasıl başlatıldığına ve işletim sistemi entegrasyonuna bağlıdır. Basit shell agent süreçleri terminal veya kullanıcı oturumu kapanınca sona erebilir. Desktop session agent ise oturum boyunca açık kalabilir. macOS Keychain gibi entegrasyonlar reboot sonrasında key yükleme davranışını değiştirebilir. Güvenlik politikanız için hangi koşulda key'in yeniden passphrase istemesi gerektiğini açık biçimde belirlemek faydalıdır.

macOS'ta SSH Passphrase Yönetimi

macOS, OpenSSH ile sistem Keychain entegrasyonunu birlikte kullanarak passphrase deneyimini kolaylaştırabilir. AddKeysToAgent ve UseKeychain seçenekleri uygun config yapısında kullanılabilir. Modern macOS sürümlerinde ssh-add --apple-use-keychain komutu key'in passphrase bilgisini Keychain ile ilişkilendirmeye yardımcı olur. Yapılandırma yaparken kullanılan OpenSSH sürümü ve Apple'a özgü seçeneklerin destek durumunu kontrol etmek gerekir. Çoklu hesaplarda her host alias kendi IdentityFile değerini korumalıdır.

Keychain

macOS Keychain, SSH private key passphrase'inin güvenli işletim sistemi mekanizması içinde saklanmasına yardımcı olabilir. Bu sayede reboot sonrasında her key için sürekli manuel giriş yapma ihtiyacı azalabilir. Keychain kullanımı private key dosyasının korunması gerekliliğini ortadan kaldırmaz. Cihaz parolası, FileVault ve kullanıcı oturum güvenliği hâlâ önemlidir. Kurumsal cihazlarda Keychain politikası MDM veya güvenlik standardıyla birlikte değerlendirilmelidir.

AddKeysToAgent

AddKeysToAgent yes SSH'ın kullanılan key'leri agent'a ekleme davranışını yönetmek için config içinde kullanılabilir. Çoklu hesaplarda bu ayarı host bazında uygulamak hangi anahtarların agent'a girdiğini daha anlaşılır kılabilir. Buna rağmen agent'da çok sayıda key bulunması durumunda IdentitiesOnly yes kullanılmalıdır. Effective config'i ssh -G ile kontrol etmek option'ın beklediğiniz host için uygulanıp uygulanmadığını gösterir. Sistem sürümüne göre OpenSSH davranışını doğrulamak faydalıdır.

UseKeychain

UseKeychain yes Apple OpenSSH entegrasyonunda passphrase'in Keychain'den alınmasına yardımcı olabilir. Config dosyasındaki kullanım, işletim sistemi ve SSH binary'sine bağlıdır. Başka bir OpenSSH kurulumu kullanıyorsanız bu seçeneğin desteklenmediği durumlar olabilir. Personal ve work alias bloklarında aynı Keychain mekanizması kullanılırken IdentityFile'ların ayrı kalması gerekir. Hata alırsanız hangi ssh binary'sinin çalıştığını kontrol etmek önemlidir.

ssh-add --apple-use-keychain

ssh-add --apple-use-keychain ~/.ssh/id_ed25519_github_work macOS üzerinde passphrase'i Keychain ile kullanmaya yönelik yaygın bir yöntemdir. Komutun destek durumu sisteminizdeki OpenSSH sürümüne bağlıdır. Personal key için de aynı işlemi ilgili dosya yoluyla uygulayabilirsiniz. Key'leri ekledikten sonra ssh-add -l ile agent durumunu kontrol edin. Ardından her alias'ı ssh -T ile ayrı test etmek kimlik eşleşmesini doğrular.

macOS Reboot Sonrası Davranış

Reboot sonrası SSH key davranışı Keychain entegrasyonu ve config ayarlarına göre değişebilir. Bazı sistemlerde agent yeniden başlar ve gerekli key'ler kullanım sırasında Keychain aracılığıyla yüklenebilir. Her reboot sonrasında otomatik olarak tüm key'leri sınırsız süre açmanın güvenlik etkisini değerlendirmek gerekir. Kurumsal güvenlik politikası kullanıcıdan belirli aralıklarla tekrar onay veya giriş isteyebilir. Sistemi yeniden başlattıktan sonra ssh-add -l ve ssh -T ile durumu doğrulamak iyi bir testtir.

Linux'ta SSH Agent Yönetimi

Linux sistemlerde ssh-agent yönetimi dağıtım, masaüstü ortamı ve kullanıcı oturum servislerine göre farklılık gösterebilir. Bazı desktop ortamları agent'ı otomatik başlatırken minimal shell sistemlerinde manuel başlatma gerekebilir. Birden fazla terminalde ayrı agent süreçleri oluşturmak farklı key listeleri ve karışık SSH_AUTH_SOCK değerleri doğurabilir. Kalıcı kullanımda desktop session veya systemd user service gibi merkezi yaklaşım daha düzenlidir. Reboot sonrası hangi key'lerin otomatik yüklendiğini ve ne zaman passphrase istendiğini güvenlik politikasına göre belirlemek gerekir.

Shell Session Agent

Shell session agent yalnızca belirli terminal oturumu için başlatılabilir. Bu yöntem basittir, fakat her yeni terminalde yeni agent oluşturursanız birden fazla socket ve process ortaya çıkar. Key'leri tekrar tekrar eklemek kullanıcı deneyimini kötüleştirebilir. Mevcut agent'ı paylaşmak için login session seviyesinde bir mekanizma kullanmak daha uygun olabilir. Debug sırasında SSH_AUTH_SOCK ve process listesini birlikte kontrol etmek hangi agent'ın aktif olduğunu anlamanıza yardım eder.

Desktop Session Agent

GNOME, KDE veya başka desktop ortamları kullanıcı oturumu sırasında SSH agent benzeri credential hizmetleri sağlayabilir. Terminal uygulamaları aynı session environment'ını aldığı için tek agent paylaşımı mümkün olur. Ancak üçüncü taraf password manager veya gnome-keyring gibi bileşenler devreye girerse hangi agent'ın kullanıldığı karışabilir. ssh-add -l ve SSH_AUTH_SOCK kontrolü burada önemlidir. Sisteminizin varsayılan entegrasyonunu anlamadan her shell başlangıcında yeni agent başlatmak çoğu zaman gereksizdir.

systemd User Service

systemd user service ile ssh-agent kullanıcı oturumu seviyesinde yönetilebilir. Bu yaklaşım agent process'inin yaşam döngüsünü merkezi hâle getirebilir. Socket environment'ının shell'lere doğru aktarılması için uygun yapılandırma gerekir. Dağıtımların varsayılanları farklı olduğundan hazır snippet'leri doğrudan kopyalamadan önce sisteminizde test etmelisiniz. Çoklu hesaplarda agent merkezi olsa bile key seçimini yine SSH host config üzerinden kontrol etmek gerekir.

Birden Fazla Agent Problemi

Aynı kullanıcı oturumunda birden fazla ssh-agent çalışması en sık rastlanan kafa karışıklıklarından biridir. Bir terminalde key görünürken başka terminalde görünmemesi çoğu zaman farklı SSH_AUTH_SOCK değerlerinden kaynaklanır. IDE veya GUI Git istemcisi de shell'inizden farklı agent kullanabilir. Sorunu çözmek için her ortamın socket değerini karşılaştırın. Tek oturum agent'ı kullanmak mümkünse davranışı sadeleştirir.

Reboot Sonrası Key Loading

Linux'ta reboot sonrası agent genellikle yeni bir süreç olarak başlar ve açık key state'i kaybolur. Key'lerin nasıl yeniden yükleneceği desktop keyring, user service veya manuel ssh-add yöntemine bağlıdır. Passphrase'i otomatik script içine koymak çözüm değildir. Bunun yerine güvenli secret saklama veya kullanıcı girişine bağlı keyring mekanizması tercih edilmelidir. Reboot sonrasında test komutlarıyla doğru agent ve key listesini doğrulamak faydalıdır.

Windows'ta SSH Key ve Passphrase Yönetimi

Windows ortamında Microsoft OpenSSH, Git for Windows ve bazı IDE'lerin kendi SSH istemcileri aynı makinede bulunabilir. Çoklu hesap sorunlarının önemli kısmı hangi ssh.exe binary'sinin ve hangi agent'ın gerçekten kullanıldığının bilinmemesinden kaynaklanır. Windows OpenSSH Authentication Agent service merkezi bir agent görevi görebilir. PowerShell üzerinden service durumu ve key listesi kontrol edilebilir. Git Credential Manager ise ağırlıklı olarak HTTPS credential yönetimiyle ilgilidir ve SSH private key passphrase yönetimiyle aynı mekanizma değildir.

Windows OpenSSH

Modern Windows sürümlerinde OpenSSH Client isteğe bağlı veya varsayılan bileşen olarak bulunabilir. ssh, ssh-keygen ve ssh-add araçlarıyla benzer çoklu hesap yapısı kurulabilir. Config dosyası kullanıcı profilindeki .ssh dizininde bulunur. Dosya izinleri Unix chmod mantığından farklı olarak Windows ACL sistemiyle yönetilir. Git for Windows başka bir SSH binary kullanıyorsa config ve agent davranışını ayrıca doğrulamak gerekir.

OpenSSH Authentication Agent Service

Windows'taki OpenSSH Authentication Agent service private key'lerin agent üzerinden kullanılmasını sağlar. Service başlangıç türü ve çalışma durumu PowerShell ile yönetilebilir. Key eklemek için Windows OpenSSH ssh-add komutu kullanılabilir. Birden fazla key olduğunda host config tarafında yine IdentitiesOnly yes ve IdentityFile kullanmak önemlidir. IDE'nin aynı agent'a bağlanıp bağlanmadığını ayrıca test etmelisiniz.

Git for Windows

Git for Windows kendi paketlediği OpenSSH araçlarını kullanabilir ve PATH sırasına göre Windows OpenSSH'den farklı binary devreye girebilir. where ssh veya Git'in SSH ayarlarını kontrol etmek hangi istemcinin çalıştığını anlamaya yardımcı olur. İki farklı SSH istemcisi aynı config'i okuyabilir, fakat agent entegrasyonu farklı davranabilir. Çoklu hesap problemi yaşadığınızda terminal ve IDE içindeki SSH binary yolunu karşılaştırın. Tek ve bilinçli bir SSH toolchain kullanmak yönetimi sadeleştirir.

PowerShell

PowerShell Windows OpenSSH servislerini, environment variable değerlerini ve Git komutlarını yönetmek için kullanışlıdır. Get-Service ssh-agent ile agent service durumu görülebilir. Key ekleme ve listeleme için normal OpenSSH komutları PowerShell içinde çalıştırılabilir. Profil script'ine secret veya passphrase yazmak doğru değildir. Otomatik başlangıç yapılandırması yapılacaksa yalnızca agent service'i yönetmeli, private key secret değerleri güvenli mekanizmada kalmalıdır.

Windows Credential Manager ile Fark

Windows Credential Manager genellikle kullanıcı adı, parola veya token benzeri credential'ları saklamak için kullanılır. Git Credential Manager HTTPS Git erişiminde bu mekanizmayla entegre olabilir. SSH private key authentication ise farklı bir protokol ve agent modeli kullanır. Bu nedenle Credential Manager'da GitHub hesabı görünmesi SSH key'in oradan seçildiği anlamına gelmez. Çoklu hesap sorununu çözerken önce remote URL'nin SSH mı HTTPS mi olduğunu belirlemek gerekir.

WSL Kullanırken SSH Agent

WSL ortamında Windows ve Linux tarafı iki ayrı SSH dünyası gibi davranabilir. WSL içinde ayrı ssh-agent başlatabilir veya Windows agent socket'ini çeşitli entegrasyon yöntemleriyle WSL'ye aktarabilirsiniz. İki tarafta farklı key setleri olması “PowerShell'de çalışan repo WSL'de neden çalışmıyor?” sorusuna sıkça neden olur. VS Code Remote WSL da komutları WSL ortamında çalıştırdığı için hangi agent'ın kullanıldığını bilmek önemlidir. Tek bir yaklaşımı bilinçli seçmek debug maliyetini azaltır.

WSL İçindeki Agent

WSL Linux dağıtımı kendi ssh-agent sürecini çalıştırabilir. Bu durumda key'ler WSL içindeki agent'a ayrıca eklenir. Windows OpenSSH agent'daki identity'ler otomatik olarak görünmez. SSH_AUTH_SOCK WSL içindeki Unix socket'i gösterir. Bu model izolasyon sağlar, fakat Windows ve WSL arasında çift key yönetimi oluşturabilir.

Windows Agent

Windows agent'ı WSL içinde kullanmak için arada socket köprüsü sağlayan bir entegrasyon gerekir. Böylece private key'leri iki ayrı agent'a yüklemek yerine merkezi Windows agent kullanılabilir. Ancak kullanılan köprü aracının güvenliği ve bakım durumu değerlendirilmelidir. Kurumsal cihazlarda yetkisiz üçüncü taraf araç kullanımı politika ihlali olabilir. Bağlantı kurulduktan sonra ssh-add -l çıktısının beklenen Windows key'lerini gösterdiğini kontrol etmek gerekir.

İki Ayrı SSH Ortamının Oluşturduğu Sorunlar

Windows ve WSL farklı SSH config, known_hosts ve agent listelerine sahip olduğunda davranışlar kolayca ayrışır. Aynı remote PowerShell'de doğru work key'i kullanırken WSL içinde personal key sunabilir. Kullanıcı çoğu zaman tek bilgisayar kullandığı için iki ayrı konfigürasyon olduğunu fark etmez. Hangi ortamda Git komutunun çalıştığını belirlemek ilk adımdır. Daha sonra o ortamın ssh -G, ssh-add -l ve ssh -vT sonuçları incelenmelidir.

VS Code Remote WSL

VS Code Remote WSL ile açılan workspace'in Git işlemleri çoğunlukla WSL ortamındaki Git ve SSH yapılandırmasını kullanır. Windows tarafındaki GUI oturumuyla karıştırıldığında authentication farkları ortaya çıkabilir. VS Code terminalinde which git, which ssh ve echo $SSH_AUTH_SOCK gibi kontroller yapabilirsiniz. IDE hesap girişi ile Git CLI authentication'ın ayrı olabileceğini unutmayın. Workspace bazlı test yapmak problemi masaüstü genelinden daha hızlı izole eder.

Hangi Agent'ın Kullanıldığını Kontrol Etmek

Agent tespitinde ilk kontrol SSH_AUTH_SOCK değeridir. Ardından ssh-add -l ile o socket üzerinden görülen key'ler listelenebilir. Windows tarafında service ve kullanılan SSH binary'sini ayrıca incelemek gerekir. WSL içinde socket bir bridge'e gidiyorsa bridge sürecinin aktif olduğunu kontrol edin. Aynı testi IDE terminalinde yapmak uygulamanın shell'den farklı ortam kullanıp kullanmadığını ortaya çıkarır.

SSH Agent Kullanmanın Güvenlik Riskleri

ssh-agent geliştirici deneyimini iyileştirir, fakat açılmış private key'i kullanılabilir durumda tuttuğu için güvenlik modeli dikkatle anlaşılmalıdır. Kullanıcı hesabınız altında çalışan zararlı bir süreç agent socket'e erişebiliyorsa anahtarı doğrudan kopyalamasa bile imzalama işlemlerini kötüye kullanmaya çalışabilir. Paylaşılan makinelerde risk daha da büyür. Agent lifetime, workstation lock ve minimum gerekli key prensibi bu riski azaltır. Kritik erişimlerde fiziksel onay isteyen hardware key yaklaşımı da değerlendirilebilir.

Unlocked Agent

Unlocked agent, passphrase'i daha önce girilmiş bir key'in yeniden parola istenmeden kullanılabilmesi anlamına gelir. Bu kullanım kolaylığı aynı zamanda açık kullanıcı oturumunun korunmasını önemli hâle getirir. Ekranı kilitlemeden cihazı bırakmak saldırı yüzeyini artırır. Gereksiz key'leri agent'da uzun süre açık tutmamak iyi bir pratiktir. Özellikle müşteri veya üretim erişimi gibi hassas anahtarlar için daha kısa agent lifetime düşünülebilir.

Malware Riski

Bir cihaz zararlı yazılımla ele geçirilmişse yalnızca private key dosyasının şifreli olması tam koruma sağlamaz. Kullanıcı oturumundaki agent'a erişebilen malware, açık identity üzerinden işlem yaptırmaya çalışabilir. Bu nedenle endpoint güvenliği, güncel işletim sistemi ve uygulama izinleri SSH güvenlik modelinin bir parçasıdır. Security key üzerinde kullanıcı dokunuşu gerektiren modeller bazı saldırıları zorlaştırabilir. Anahtar güvenliğini yalnızca passphrase özelliğine indirgememek gerekir.

Shared Machine Riski

Birden fazla kişinin kullandığı makinelerde SSH agent ve private key yönetimi ekstra dikkat ister. Kullanıcı hesapları birbirinden güçlü biçimde ayrılmalıdır. Ortak Unix hesabı üzerinden kişisel SSH key kullanmak attribution ve erişim güvenliği açısından uygun değildir. Geçici sistemlerde kalıcı private key bırakmamak gerekir. Mümkünse her geliştirici kendi yönetilen cihazı ve kişisel kimlik bilgileriyle çalışmalıdır.

Agent Socket Erişimi

Agent socket, SSH istemcisinin agent ile iletişim kurduğu kanaldır. Socket'e erişebilen süreçler agent'ın sunduğu identity'lerden yararlanabilir. Dosya sistemi ve process izinleri bu nedenle önemlidir. Container veya remote ortamına agent socket forward ederken güven sınırını genişlettiğinizi unutmayın. Yalnızca güvendiğiniz ortamlara ve gerçekten ihtiyaç olduğunda forwarding uygulamak daha güvenlidir.

Workstation Lock Politikası

Workstation lock, açık agent kullanılan geliştirme cihazlarında temel fiziksel ve oturum güvenliği kontrolüdür. Kullanıcı masadan ayrıldığında cihazın kısa süre içinde otomatik kilitlenmesi riski azaltır. Kurumsal cihazlarda MDM ile ekran kilidi süresi ve güçlü login politikaları uygulanabilir. Disk şifreleme de cihaz kapalıyken private key dosyalarını korumaya yardımcı olur. Agent güvenliği cihaz oturum güvenliğinden bağımsız düşünülemez.

Agent Lifetime Sınırı

Agent'a key eklerken belirli bir yaşam süresi tanımlamak açık identity'nin süresiz kullanılmasını önleyebilir. OpenSSH ssh-add bazı ortamlarda lifetime seçeneği sunar. Süre dolduğunda key'in yeniden passphrase ile eklenmesi gerekir. Bu model yüksek güvenlikli anahtarlar için kullanım kolaylığı ile risk arasında iyi bir denge sağlayabilir. Ekip politikası belirlenirken geliştiricilerin çalışma akışı ve erişim hassasiyeti birlikte değerlendirilmelidir.

SSH Agent Forwarding Nedir?

SSH agent forwarding, yerel agent'ınızı bağlandığınız uzak makine üzerinden başka SSH hedeflerine erişmek için kullanılabilir hâle getirir. Bastion host üzerinden iç Git sunucusuna bağlanma gibi senaryolarda faydalı olabilir. Ancak uzak host güvenilir değilse agent socket'in kötüye kullanılması riski oluşur. Günlük GitHub veya GitLab clone ve push işlemlerinde forwarding çoğunlukla gerekli değildir. Bu nedenle ForwardAgent ayarını varsayılan olarak açık tutmak yerine yalnızca belirli güvenilir host'larda etkinleştirmek daha güvenlidir.

ForwardAgent

ForwardAgent yes SSH config içinde agent forwarding'i etkinleştirebilir. Bu ayarı Host * altında açmak tüm SSH bağlantılarına agent erişimi taşımak anlamına gelebilir. Böyle geniş bir kapsam genellikle önerilmez. Gerçekten ihtiyaç olan bastion host için özel blokta tanımlamak daha kontrollüdür. Forwarding açıkken private key dosyası uzak makineye kopyalanmasa da agent kullanım yetkisi geçici olarak genişletilmiş olur.

Bastion Host Senaryosu

Bastion host, dış ağdan doğrudan erişilemeyen sistemlere ara nokta üzerinden ulaşmak için kullanılır. Uzak iç Git sunucusuna bastion üzerinden bağlanmanız gerekiyorsa agent forwarding bir çözüm olabilir. Bununla birlikte ProxyJump gibi bağlantı yöntemlerinin forwarding gereksinimini azaltıp azaltmadığı ayrıca değerlendirilmelidir. Bastion host güvenliği kritik hâle gelir çünkü açık agent bağlantısı burada kullanılabilir. Kurumsal mimaride hangi host'ların agent forwarding kullanabileceği açık politika ile sınırlandırılmalıdır.

Agent Forwarding'in Güvenlik Riski

Agent forwarding sırasında private key dosyası uzak host'a gitmez, fakat uzak host agent aracılığıyla imza işlemi yaptırabilir. Uzak host ele geçirilmişse bağlantı süresince bu yetki kötüye kullanılabilir. Bu nedenle forwarding yalnızca güvendiğiniz sistemlerde açılmalıdır. Hardware-backed key ve kullanıcı onayı gibi mekanizmalar bazı riskleri azaltabilir. Yine de en iyi kontrol gereksiz forwarding'i hiç etkinleştirmemektir.

Git İçin Ne Zaman Gereksizdir?

Yerel bilgisayarınızdan doğrudan GitHub, GitLab veya Enterprise Git sunucusuna bağlanıyorsanız agent forwarding genellikle gereksizdir. Normal ssh-agent zaten yerel Git işlemleri için yeterlidir. Forwarding yalnızca SSH ile başka bir makineye bağlandıktan sonra o makineden üçüncü bir SSH servisine erişmeniz gerektiğinde anlamlı olur. Günlük laptop Git akışında bu senaryo yoksa ayarı kapalı tutabilirsiniz. Böylece gereksiz güven sınırı genişlemesini önlersiniz.

Varsayılan Olarak Kapalı Tutmak

Agent forwarding için güvenli varsayılan kapalı durumdur. Gerektiğinde yalnızca belirli host bloğunda açıkça etkinleştirmek daha kontrollü bir yaklaşımdır. Host * altında ForwardAgent yes kullanmak yerine ihtiyaç tabanlı config tercih edilmelidir. Mevcut config'inizde forwarding durumunu ssh -G ile kontrol edebilirsiniz. Eski dotfiles dosyalarındaki genel forwarding ayarlarını da zaman zaman gözden geçirmek faydalıdır.

Git Commit Kimliği Nasıl Belirlenir?

Git commit oluştururken yazar ve committer bilgilerini Git config üzerinden belirler. SSH ile hangi hesap üzerinden bağlandığınız bu bilgileri otomatik olarak seçmez. user.name ve user.email değerleri farklı config scope'larından gelebilir. Repository bazlı veya conditional config kullanılması çoklu hesaplarda yanlış identity riskini azaltır. Commit oluşturmadan önce git config user.email ve git config --show-origin user.email ile effective değeri kontrol edebilirsiniz.

user.name

user.name commit metadata'sındaki insan tarafından okunabilir yazar adını belirler. Bunun platform username'iyle aynı olması gerekmez. Kurumsal projelerde İK veya geliştirme politikası belirli bir isim formatı isteyebilir. Personal ve work config dosyalarında farklı değerler tanımlanabilir. Commit attribution problemi yaşandığında e-posta kadar isim değerini de kontrol etmek faydalıdır.

user.email

user.email commit kimliğinin platform hesabıyla ilişkilendirilmesinde önemli rol oynar. Yanlış scope'tan gelen global adres çoklu hesaplarda en yaygın problemlerdendir. Work repository için kurumsal e-posta, personal repository için kişisel veya noreply e-posta kullanılabilir. includeIf ile klasöre göre otomatik seçim yapılabilir. user.useConfigOnly=true ise tanımsız ortamda Git'in otomatik e-posta üretmesini önleyebilir.

Commit Author

Commit author, değişikliği orijinal olarak oluşturan kişiyi ifade eder. Normal commit akışında author ve committer çoğu zaman aynı kişidir. Patch uygulama, cherry-pick veya yeniden yazma gibi işlemlerde farklı olabilirler. Platformdaki görüntüleme ve contribution eşleşmesi author e-posta bilgisine bağlı olabilir. Geçmişi düzeltirken author ile committer alanlarının ne anlama geldiğini bilmek önemlidir.

Committer

Committer, commit nesnesini mevcut biçimiyle oluşturan veya yeniden yazan kimliği temsil eder. Rebase veya cherry-pick sonrasında committer bilgisi değişebilir. Çoklu hesap yapılandırmasında yanlış user.email hem author hem committer alanlarında istenmeyen sonuç üretebilir. Geçmişi incelerken git log --format=fuller gibi formatlar iki bilgiyi ayrı göstermeye yardımcı olur. Kurumsal denetimde bu ayrım bazı workflow'lar için önemli olabilir.

GitHub Authentication Hesabı Commit Author'ını Belirler mi?

Hayır, SSH ile hangi GitHub hesabının doğrulandığı commit author bilgisini otomatik belirlemez. Commit yerelde, çoğu zaman push işleminden çok önce oluşturulur. Git author bilgisi config veya commit komutuna sağlanan environment değerlerinden gelir. Bu nedenle work SSH key ile push edilen commit personal e-posta taşıyabilir. Çoklu hesap yapısında SSH ve Git identity katmanlarını ayrı yapılandırmanın temel nedeni budur.

Git Configuration Scope'ları

Git config değerleri system, global, local repository, worktree ve komut satırı gibi farklı scope'lardan gelebilir. Aynı ayar birden fazla yerde tanımlandığında daha özel veya daha yüksek öncelikli değer geçerli olur. Çoklu hesaplarda global user.email kullanmak yerine conditional ve local scope'ları bilinçli yönetmek gerekir. git config --show-origin --show-scope --list desteklenen sürümlerde değerlerin kaynağını anlamaya yardımcı olur. Config sorunlarını çözerken yalnızca ~/.gitconfig dosyasına bakmak yeterli değildir.

System

System config makinedeki tüm kullanıcıları etkileyen Git ayarlarını içerir. Genellikle işletim sistemi veya kurumsal cihaz yönetimi tarafından tanımlanabilir. Kullanıcı kimliği gibi kişisel değerleri system scope'ta tutmak çoklu hesap açısından uygun değildir. Proxy, güvenlik veya temel davranış ayarları burada bulunabilir. Bir değerin system config'ten geldiğini --show-origin ile görmek beklenmeyen davranışı açıklayabilir.

Global

Global config mevcut kullanıcı hesabı altındaki tüm Git repository'lerini etkiler. Tek kimlik kullanan geliştiriciler için user.name ve user.email burada tutulabilir. Çoklu hesaplarda ise global identity yanlış projede devreye girebilir. Bunun yerine global dosyada user.useConfigOnly=true ve includeIf kuralları tanımlamak daha güvenli olabilir. Böylece gerçek kimlik personal veya work config dosyasından gelir.

Local Repository

Local repository config yalnızca ilgili Git deposunu etkiler ve .git/config içinde tutulur. Belirli bir müşteri veya istisna repository için identity ayarlamak açısından oldukça kullanışlıdır. git config user.email ... komutu varsayılan olarak local scope'ta çalışabilir. Bu ayar repository taşındığında .git metadata ile birlikte korunur. Ancak çok sayıda repository için elle local config yapmak bakım maliyetini artırabilir.

Worktree

Git worktree yapılarında bazı config değerleri worktree bazında ayrılabilir. Bu özellik daha gelişmiş kullanım senaryolarında aynı repository'nin farklı çalışma ağaçlarında farklı davranış istemenizi sağlar. Çoklu hesap yönetiminde çoğu kullanıcı için conditional config veya local config daha basittir. Worktree-specific config kullanıyorsanız ilgili Git sürümünün davranışını ve extension ayarlarını doğrulamak gerekir. Debug sırasında config scope'unu görmek hangi worktree değerinin aktif olduğunu anlamaya yardımcı olur.

Command-Line Override

Git komutlarında -c key=value ile tek işlem için config override yapılabilir. Örneğin geçici bir testte farklı SSH command veya kimlik değeri uygulanabilir. Bu değişiklik kalıcı config dosyasına yazılmaz. Acil veya tek seferlik operasyonlar için kullanışlıdır, fakat günlük kimlik seçimini sürekli komut satırı override'larına bırakmak hata riskini artırır. Kalıcı çoklu hesap düzeni için conditional config veya repository config daha uygundur.

Hangi Config Kazanır?

Git config önceliği kaynağın scope'una ve bazı durumlarda komut satırı veya environment override'larına bağlıdır. Daha özel local değerler global değerlerin üzerine çıkabilir. Conditional include dosyaları da include edildikleri konuma göre config akışına katılır. Beklenen değeri tahmin etmek yerine git config --show-origin kullanmak daha güvenlidir. Kimlik sorunu yaşadığınızda her value'nun kaynağını görmek birkaç dakikada problemi ortaya çıkarabilir.

Effective Git Config Nasıl Kontrol Edilir?

Git kimlik problemlerinde ilk yapılması gereken, repository içinde gerçekten hangi config değerlerinin aktif olduğunu görmektir. git config --list genel görünüm sağlar. git config user.name ve git config user.email doğrudan kimlik değerlerini gösterir. --show-origin ile değerin hangi dosyadan geldiğini bulabilirsiniz. Conditional include kullanan çoklu hesap yapısında bu kontroller config'in gerçekten eşleşip eşleşmediğini anlamak için önemlidir.

git config --list

git config --list mevcut repository bağlamında görülen config değerlerini listeler. Çıktıda duplicate anahtarlar bulunabilir çünkü aynı key farklı scope'larda tanımlanmış olabilir. Kimlik problemi araştırırken yalnızca değeri değil, kaynağı da görmek gerektiğinden --show-origin eklemek daha faydalıdır. SSH command, signing ve user ayarlarını aynı listede inceleyebilirsiniz. Hassas token veya URL bilgileri olabileceği için çıktıyı paylaşmadan önce kontrol etmelisiniz.

git config user.name

git config user.name mevcut repository için effective kullanıcı adını verir. Değer boşsa ve user.useConfigOnly=true aktifse commit işlemi kimlik hatasıyla durabilir. Bu davranış çoklu hesaplarda güvenli varsayılan oluşturur. Beklenmeyen isim görürseniz --show-origin ile kaynağını bulun. Work ve personal klasörlerinde komutu ayrı çalıştırarak conditional config'i hızlıca test edebilirsiniz.

git config user.email

git config user.email commitlerde kullanılacak effective e-posta değerini gösterir. Çoklu hesaplarda commit öncesi yapılabilecek en basit güvenlik kontrollerinden biridir. Work repository'de personal adres veya tersi görünüyorsa commit oluşturmadan config'i düzeltin. Otomatik kontrol için shell prompt veya pre-commit/pre-push policy çözümleri de kullanılabilir. Özellikle açık kaynak deposunda kurumsal e-posta görünmesi gizlilik açısından önemlidir.

git config --show-origin

git config --show-origin --list her config değerinin hangi dosyadan geldiğini gösterir. Conditional include kurallarının beklediğiniz dosyayı yükleyip yüklemediğini buradan görebilirsiniz. Local repository config'in global değeri override ettiğini de kolayca fark edersiniz. Debug sırasında dosyayı tek tek açmaktan daha hızlıdır. Çoklu kimlik yönetiminde bu komutu temel teşhis araçlarından biri olarak kullanmak faydalıdır.

Config Değerinin Hangi Dosyadan Geldiğini Bulmak

Belirli bir değer için git config --show-origin user.email doğrudan kaynağı gösterebilir. Yanlış e-posta sorununun global, include veya local config'ten geldiğini birkaç saniyede anlayabilirsiniz. Signing key için aynı yöntemi user.signingKey üzerinde uygulayabilirsiniz. Repository'nin beklenmedik local override içerip içermediğini de kontrol etmek gerekir. Kaynağı belirlemeden config dosyalarını rastgele değiştirmek yeni çakışmalar oluşturabilir.

Global user.email Çoklu Hesaplarda Neden Risklidir?

Global user.email tek kimlik kullanan geliştiricilerde pratik olabilir, fakat çoklu hesaplarda yanlış commit'in sessizce oluşmasına neden olabilir. Git bir repository için özel identity bulamazsa global adresi kullanır ve işlem başarılı olur. Bu nedenle hatayı push sonrasında veya web arayüzünde fark edebilirsiniz. Personal, work ve müşteri kimliklerini conditional config'e taşımak daha güvenlidir. Global seviyede user.useConfigOnly=true kullanmak ise tanımlanmamış kimlikle commit oluşturulmasını engelleyebilir.

Work Repository'de Personal Email

Kurumsal repository'de personal e-posta kullanılması commit attribution ve şirket politikaları açısından sorun oluşturabilir. Platform commit'i doğru çalışan hesabına bağlamayabilir. Kurumsal e-posta alan adı gerektiren otomasyonlar veya imza politikaları da başarısız olabilir. İş klasörüne özel Git config dosyası kullanmak bu riski azaltır. Commit öncesi git config user.email kontrolü basit fakat etkili bir doğrulamadır.

Personal Repository'de Corporate Email

Kişisel repository'de kurumsal e-posta kullanılması özellikle repository public ise istenmeyen bilgi paylaşımına yol açabilir. Commit history uzun süre public kalabileceği için daha sonra düzeltmek history rewrite gerektirebilir. Personal config içinde kişisel veya noreply adres kullanmak daha kontrollüdür. Açık kaynak katkıları da personal identity kapsamına alınabilir. İş e-postasını global tanımlamamak bu tür sızıntıları büyük ölçüde önler.

Açık Kaynak Repository'de Kurumsal E-posta Sızıntısı

Public bir açık kaynak projesindeki commit e-postası Git nesnesinin parçası olur ve kolayca görüntülenebilir. Kurumsal adresinizin burada görünmesi spam, gizlilik veya şirket politikası açısından istenmeyebilir. Kişisel noreply adresi kullanmak platform destekliyorsa iyi bir seçenek olabilir. Conditional config ile open source projelerini personal klasör altında tutmak kimlik seçimini otomatikleştirir. Commit'i push etmeden önce author bilgisini kontrol etmek düzeltmeyi çok daha kolay hâle getirir.

Commit Attribution Problemi

Git hosting platformları commitleri kullanıcı hesabıyla ilişkilendirmek için commit e-postasını kullanabilir. Hesabınıza eklenmemiş bir e-posta ile commit atıldığında contribution veya kullanıcı bağlantısı beklediğiniz gibi görünmeyebilir. Bu problem SSH authentication doğru olsa bile oluşabilir. E-posta adresini doğru config scope'unda tanımlamak temel çözümdür. Eski commitlerde düzeltme gerekiyorsa history rewrite etkisini özellikle paylaşılan branch'lerde dikkatle değerlendirmek gerekir.

user.useConfigOnly=true ile Yanlış Commit'i Engellemek

user.useConfigOnly=true, çoklu hesap düzeninde fail-safe davranış oluşturmak için son derece kullanışlı bir Git ayarıdır. Git normalde açık kullanıcı adı veya e-posta tanımı olmadığında sistem bilgisinden bir kimlik tahmin etmeye çalışabilir. Bu ayar aktif olduğunda açık kimlik yoksa commit işlemi durur. Böylece yanlış e-posta ile sessizce commit oluşturmak yerine problemi commit anında görürsünüz. Personal ve work identity'leri conditional include ile sağladığınız bir yapıda güçlü bir güvenlik ağı oluşturur.

Git'in Name/E-mail Tahmini Yapmasını Önlemek

Git bazı ortamlarda işletim sistemi kullanıcı adı ve hostname gibi bilgilerden otomatik identity oluşturabilir. Tek hesaplı basit sistemlerde bu davranış yardımcı olabilir. Çoklu hesaplarda ise tahmin edilen kimlik kurumsal veya kişisel politika ile uyuşmayabilir. user.useConfigOnly=true açık tanım yoksa Git'in bu fallback davranışına güvenmesini engeller. Böylece kimlik yapılandırması eksik repository hemen fark edilir.

Default Identity Kullanmamak

Çoklu hesaplarda tek bir default identity her repository için güvenli olmayabilir. Özellikle personal, work ve client projeleri arasında geçiş yapıyorsanız yanlış fallback kullanımı sessiz hata üretir. Kimlik tanımlanmayan durumda commit'in durması daha güvenli bir varsayımdır. Conditional include kuralları doğru klasörde doğru identity'yi sağlar. İstisna repository varsa local config ile açıkça tanımlanabilir.

Identity Tanımlı Değilse Commit'i Durdurmak

Fail-closed yaklaşımın amacı eksik konfigürasyonu başarıyla devam ettirmek yerine erken hata üretmektir. user.useConfigOnly=true bunun Git identity tarafındaki basit uygulamasıdır. Yeni clone edilen repository beklenen klasörde değilse identity bulunmayabilir ve commit durur. Bu davranış kullanıcıya “yanlış kimlikle devam etme” yerine “önce yapılandırmayı düzelt” mesajı verir. Kurumsal çoklu hesap ortamlarında bu tür güvenli varsayılanlar manuel kontrole olan bağımlılığı azaltır.

Fail-Safe Multi-Account Git Yapısı

Fail-safe yapı yalnızca tek bir ayardan oluşmaz. SSH tarafında host alias ve IdentitiesOnly, Git tarafında conditional include ve user.useConfigOnly, signing tarafında ayrı key seçimi birlikte çalışır. Her katman yanlış kimliğin sessizce devreye girmesini zorlaştırır. Clone sonrası kimlik ve remote doğrulaması bu yapıyı tamamlar. Böylece çoklu hesap yönetimi sürekli manuel hesap değiştirmek yerine kurallarla çalışan bir kimlik izolasyonu sistemine dönüşür.

Git includeIf Nedir?

includeIf, Git config dosyasının belirli koşullar altında başka config dosyalarını yüklemesini sağlar. Çoklu hesaplarda personal, work ve client identity'leri ayrı dosyalara bölmek için oldukça uygundur. En yaygın koşul repository'nin bulunduğu dizine göre çalışan gitdir: eşleşmesidir. Daha yeni Git sürümlerinde remote URL içeriğine dayalı hasconfig:remote.*.url: koşulu da kullanılabilir. Hangi yöntemi seçerseniz seçin effective config'i --show-origin ile doğrulamak önemlidir.

Conditional Git Configuration

Conditional Git configuration, her repository için aynı global identity'yi kullanmak yerine bağlama göre config seçmenizi sağlar. Örneğin ~/work/ altındaki tüm depolar kurumsal config'i yükleyebilir. ~/personal/ altındaki depolar kişisel config kullanabilir. Bu yöntem yeni repository clone edildiğinde local user.email ayarını elle tekrar etmeyi azaltır. Klasör disiplini korunuyorsa oldukça anlaşılır ve güvenilir bir çözüm sunar.

Config Dosyalarını Kimliğe Göre Bölmek

Tek büyük ~/.gitconfig yerine ~/.gitconfig-personal, ~/.gitconfig-work ve müşteri dosyaları kullanabilirsiniz. Her dosya kendi user.name, user.email ve signing ayarlarını içerir. Ana global dosya yalnızca koşullu include kurallarını ve ortak davranışları tutar. Bu ayrım yanlış değişiklik yapma riskini azaltır ve config'i daha okunabilir kılar. Dotfiles versionlanıyorsa hassas e-posta veya kurumsal değerleri public repository'ye koymamaya dikkat etmelisiniz.

Personal Config

Personal config kişisel kullanıcı adı, e-posta ve kişisel signing key değerlerini içerebilir. Bu dosya yalnızca personal klasör altındaki repository'lerde include edilmelidir. Kişisel GitHub SSH authentication seçimi ise ayrı olarak remote host alias üzerinden yapılır. Böylece Git commit identity ve SSH identity aynı bağlamı izler ama teknik olarak birbirine bağımlı olmaz. Açık kaynak depolarını da kişisel kimlik altında tutmak isterseniz dizin yapısını buna göre düzenleyebilirsiniz.

Work Config

Work config kurumsal e-posta, iş için kullanılan isim formatı ve work signing key gibi değerleri taşır. ~/work/ altındaki repository'lerde otomatik include edilebilir. SSH remote'ların github-work veya uygun Enterprise alias kullanması authentication katmanını eşleştirir. Kurum policy gerektiriyorsa commit signing burada zorunlu hâle getirilebilir. İş kimliği dosyasını personal projelerde hiçbir koşulda global fallback olarak kullanmamak daha güvenlidir.

Client Config

Her müşteri için ayrı config dosyası kullanmak danışmanlık ve ajans çalışmalarında yararlı olabilir. Müşteri e-postası veya belirli signing key yalnızca ilgili proje dizininde etkinleşir. Remote URL de müşteriye ayrılmış SSH host alias'ı kullanabilir. Böylece yanlış müşteri hesabıyla commit veya push yapma riski azalır. Proje sona erdiğinde config include kuralı, SSH key ve platform erişimi birlikte kaldırılabilir.

includeIf gitdir ile Directory Bazlı Kimlik

includeIf "gitdir:..." repository konumuna göre kimlik seçmenin en anlaşılır yöntemlerinden biridir. Personal, work ve client projelerini ayrı üst klasörlerde tutuyorsanız config otomatik olarak doğru profile geçebilir. Buradaki önemli noktalardan biri path eşleşmesinin doğru yazılması ve trailing slash davranışının anlaşılmasıdır. Nested repository'ler de ilgili dizin koşuluyla eşleşebilir. Clone edilen repository yanlış klasöre konursa kimlik de yanlış veya tanımsız olabileceği için user.useConfigOnly iyi bir güvenlik ağıdır.

~/personal/

~/personal/ altındaki repository'ler için personal config include edilebilir. Bu klasör kişisel GitHub projeleri ve açık kaynak fork'ları için kullanılabilir. Clone komutunu bu dizin altında çalıştırdığınızda Git repository path'i personal koşulla eşleşir. SSH authentication yine remote URL'deki personal host alias üzerinden seçilir. Böylece klasör commit identity'yi, remote ise network identity'yi kontrol eder.

~/work/

~/work/ kurumsal repository'lerin merkezi çalışma dizini olabilir. Git includeIf bu path altında work config'i yükler. Böylece kurumsal e-posta, signing key ve diğer politikalar otomatik uygulanır. Remote adreslerinde work host alias kullanılması SSH tarafındaki eşleşmeyi tamamlar. Repository yanlışlıkla personal klasöre taşınırsa effective config değişebileceği için taşımadan sonra kimliği kontrol etmek gerekir.

~/clients/client-a/

Müşteri bazlı klasör yapısı daha ayrıntılı conditional identity yönetimi sağlar. ~/clients/client-a/ altındaki depolar yalnızca Client A config dosyasını yükleyebilir. Diğer müşteri klasörü farklı e-posta ve signing key kullanabilir. SSH config içinde de gitlab-client-a gibi ayrı alias tercih edilebilir. Bu yapı hem commit hem authentication seviyesinde müşteri izolasyonunu güçlendirir.

Trailing Slash'ın Önemi

gitdir koşullarında path yazım biçimi eşleşmenin kapsamını etkileyebilir. Üst klasör ve altındaki repository'lerin eşleşmesi isteniyorsa trailing slash kullanımını Git dokümantasyonundaki semantiğe göre yapılandırmak gerekir. Path'i yanlış yazmak include dosyasının hiç yüklenmemesine veya beklenmeyen kapsamda yüklenmesine yol açabilir. git config --show-origin user.email gerçek eşleşmeyi test etmenin en basit yoludur. Kuralları ekledikten sonra hem üst dizindeki hem nested repository'deki davranışı test etmek faydalıdır.

Nested Repository'ler

Üst klasör altında daha derin dizinlerde bulunan repository'ler directory koşuluyla eşleşebilir. Örneğin ~/work/team/project/repo work kimliğini kullanabilir. Ancak nested Git repository veya submodule yapısında her repository kendi config bağlamına sahiptir. Submodule remote URL'sinin de doğru SSH alias kullanması gerekir. Büyük monorepo ve worktree yapılarını kullanıyorsanız path koşullarını gerçek directory düzeniniz üzerinde test etmek önemlidir.

gitdir/i Ne Zaman Kullanılır?

gitdir/i, directory eşleşmesini büyük ve küçük harf duyarsız yapmak istediğiniz durumlarda kullanılabilir. Özellikle Windows veya case-insensitive filesystem kullanılan ortamlarda path harf farklarının config eşleşmesini bozmasını önleyebilir. Her sistemde buna ihtiyaç yoktur. Path standardınız sabitse normal gitdir daha açık bir seçim olabilir. Cross-platform dotfiles kullanıyorsanız filesystem davranışlarını test ederek hangi koşulun daha güvenilir olduğunu belirlemelisiniz.

Case-Insensitive Matching

Case-insensitive matching dizin yolundaki büyük ve küçük harf farklarını eşleşme dışında bırakır. Örneğin Work ve work aynı mantıksal dizin olarak değerlendirilebilir. Bu özellik farklı dosya sistemleri arasında config taşırken faydalı olabilir. Ancak istemeden çok geniş eşleşme yapmamak için path desenini yine açık yazmalısınız. Effective config testi her platformda sonuçları doğrulamanıza yardımcı olur.

Windows

Windows dosya sistemleri çoğu yaygın kurulumda path büyük küçük harf kullanımına karşı duyarsız davranabilir. Git Bash, PowerShell veya WSL kullanımı path gösterimini ayrıca etkileyebilir. Conditional config dosyasında kullanılan path formatını gerçek Git ortamınızda test etmek gerekir. gitdir/i bu çeşitliliği daha toleranslı hâle getirebilir. WSL içindeki Linux filesystem ise farklı davranabileceği için Windows ve WSL config'leri ayrı değerlendirilmelidir.

Case-Insensitive Filesystem

macOS ve Windows'taki bazı varsayılan filesystem yapılandırmaları dosya adı harf farklarını ayırt etmeyebilir. Conditional include ise path eşleştirme kurallarına göre çalışır ve yazım farkları beklenmeyen sonuç üretebilir. gitdir/i bu durumda daha dayanıklı bir eşleşme sağlayabilir. Bununla birlikte klasör standardını tutarlı kullanmak yine de önemlidir. Cross-platform ekiplerde örnek config'in her işletim sistemi üzerinde test edilmesi iyi bir uygulamadır.

Remote URL Bazlı Git Kimlik Yönetimi

Directory yapısına güvenmek istemediğiniz durumlarda Git'in remote URL'sine göre conditional config seçmek daha uygun olabilir. hasconfig:remote.*.url koşulu belirli URL desenlerinin varlığına göre config include edilmesini sağlar. Böylece repository diskte nereye taşınırsa taşınsın remote belirli organization veya host'u gösterdiği sürece kimlik korunabilir. Bu özellik kullanılan Git sürümüne bağlı olduğu için ekipteki minimum sürümü doğrulamak gerekir. Çoklu organization kullanan ekiplerde remote tabanlı kimlik seçimi directory disiplinine güçlü bir alternatif sunabilir.

hasconfig:remote.*.url

hasconfig:remote.*.url Git config koşulu repository remote URL değerlerini inceleyerek belirli config dosyasını include edebilir. Örneğin work organization URL kalıbı eşleştiğinde kurumsal user.email ve signing key yüklenebilir. Repository başka klasöre taşınsa bile remote aynı kaldığı sürece eşleşme korunur. Özelliğin desteklendiği Git sürümlerini ekip standardı olarak doğrulamak gerekir. Config zinciri oluştururken karşılıklı include veya karmaşık eşleşmelerden kaçınmak okunabilirliği artırır.

Organization Bazlı Kimlik

Remote URL'de organization adı belirginse o organization için özel identity seçebilirsiniz. Bu yaklaşım aynı GitHub hesabında veya farklı kurumsal hesaplarda organization bazlı politikalar uygulamak için kullanışlıdır. Örneğin belirli kurumsal organization remote'u work config'i etkinleştirebilir. Açık kaynak organization'ları ise personal config'e bırakılabilir. URL desenlerini çok geniş yazmamak public repository'lerde istenmeyen kimlik seçimlerini önler.

Repository'nin Diskte Nerede Olduğundan Bağımsız Kimlik

Remote tabanlı koşulun en büyük avantajlarından biri repository'nin klasör konumundan bağımsız olmasıdır. Work repository geçici olarak Desktop altına taşınsa bile remote URL kurumsal deseni taşıyorsa work identity seçilebilir. Bu davranış directory tabanlı yöntemde bulunmaz. Buna karşılık clone işleminden hemen sonra remote yapılandırmasının beklenen biçimde olduğundan emin olmak gerekir. Kullanılan Git sürümü özelliği desteklemiyorsa fallback planı bulunmalıdır.

GitHub ve GitLab'ı Remote URL ile Ayırmak

Remote URL host kısmı GitHub ve GitLab projelerini ayırmak için kullanılabilir. Ancak aynı platformda hem personal hem work hesap varsa yalnızca hostname yeterli değildir. Host alias veya organization path'i gibi daha ayırt edici URL kalıpları kullanmak gerekir. Örneğin github-work alias remote URL içinde görünüyorsa work config koşuluna sinyal olabilir. Bu yöntem SSH ve Git identity yönlendirmesini aynı URL üzerinden daha tutarlı hâle getirebilir.

gitdir vs hasconfig:remote.*.url

Directory tabanlı ve remote URL tabanlı conditional config aynı problemi farklı sinyallerle çözer. gitdir daha uzun süredir kullanılan, anlaşılması kolay ve klasör disiplinine dayalı bir yöntemdir. hasconfig:remote.*.url repository taşınsa bile remote bilgisini takip ettiği için daha esnek olabilir. Buna karşılık daha yeni Git sürümü gereksinimi ve daha karmaşık eşleşme kuralları dikkate alınmalıdır. Ekip alışkanlıklarına göre birini ana yöntem, diğerini belirli istisnalarda tamamlayıcı olarak kullanabilirsiniz.

Kullanım Kolaylığı

gitdir yaklaşımı kullanıcı açısından “work projeleri work klasöründe” gibi basit bir zihinsel modele sahiptir. Remote URL yöntemi ise klasör düzeni gerektirmez ve repository özgürce taşınabilir. Küçük ekiplerde directory disiplini yeterli olabilir. Çok sayıda organization ve geçici çalışma dizini kullanan ekiplerde remote koşulu daha az manuel hata üretebilir. Hangi yöntem seçilirse seçilsin debug komutlarının ekibe öğretilmesi önemlidir.

Git Version Gereksinimi

gitdir uzun süredir Git ekosisteminde bulunduğu için geniş sürüm uyumluluğuna sahiptir. Remote URL tabanlı conditional include daha yeni Git sürümlerinde kullanılabilir. Kurumsal filoda eski Linux dağıtımları veya build makineleri varsa destek durumu kontrol edilmelidir. Sadece geliştirici laptop'ında çalışan config CI ortamında çalışmayabilir. Minimum Git sürümünü dokümante etmek deployment ve onboarding sorunlarını azaltır.

Directory Disiplini

Directory tabanlı modelin başarısı repository'lerin doğru üst klasör altında tutulmasına bağlıdır. Kullanıcı work repo'yu personal klasöre clone ederse yanlış identity seçilebilir. user.useConfigOnly bazı hatalarda koruma sağlar, fakat yanlış klasörde farklı bir geçerli identity varsa commit yine oluşabilir. Remote tabanlı model bu bağımlılığı azaltır. Ekip klasör standardını zaten kullanıyorsa gitdir oldukça sade ve etkili olabilir.

Repository Taşıma

Repository başka dizine taşındığında gitdir koşulu değişebilir. Bu nedenle taşıma sonrası git config user.email kontrol edilmelidir. Remote URL tabanlı modelde path değişimi kimliği genellikle etkilemez. Ancak remote URL değiştirilirse kimlik koşulu da değişebilir. Her iki yaklaşımda da kritik değişikliklerden sonra effective config kontrolü iyi bir alışkanlıktır.

Çoklu Organization

Aynı platformda birden fazla organization ile çalışan geliştiriciler için remote URL desenleri güçlü bir ayrım noktası sağlayabilir. Personal GitHub hesabı, iş organization'ı ve müşteri organization'ı farklı config'lere yönlendirilebilir. Directory yöntemi de aynı ayrımı klasörlerle yapabilir. Remote yönteminde organization adının URL içinde güvenilir biçimde bulunduğundan emin olmak gerekir. URL rewrite kullanıyorsanız conditional pattern'in rewrite sonrası mı önce mi beklenen değeri gördüğünü test etmelisiniz.

Hangi Yöntem Ne Zaman Kullanılmalı?

Basit personal ve work ayrımı için düzenli klasör yapınız varsa gitdir genellikle yeterlidir. Repository'leri sık taşıyor veya organization bazlı otomatik kimlik istiyorsanız remote URL koşulu daha uygun olabilir. Eski Git sürümleri bulunan ekiplerde compatibility nedeniyle directory yaklaşımı daha güvenli seçimdir. Karma model de uygulanabilir, ancak config'i gereksiz biçimde anlaşılmaz hâle getirmemek gerekir. En iyi yöntem, ekip üyelerinin debug edebildiği ve yanlış kimlikte fail-safe davranan yöntemdir.

Repository Bazlı core.sshCommand

core.sshCommand, belirli repository'nin Git işlemlerinde kullanılacak SSH komutunu doğrudan tanımlamanızı sağlar. Bu yöntem SSH config host alias kullanmadan private key seçmek için kullanılabilir. Örneğin ssh -i ~/.ssh/id_ed25519_client -o IdentitiesOnly=yes benzeri bir komut repository config'e yazılabilir. Ayar yalnızca ilgili repository için geçerli olduğundan özel müşteri projelerinde kullanışlıdır. Buna karşılık private key path'inin makineye özgü olması repository portability açısından dezavantaj oluşturabilir.

SSH Config Kullanmadan Key Seçmek

core.sshCommand SSH config dosyasına host alias eklemek istemediğiniz durumlarda doğrudan key seçebilir. Repository local config içinde tanımlandığında diğer depoları etkilemez. Bu, tek bir istisna repo veya hızlı migration senaryosu için pratiktir. Ancak birçok repository'de aynı ayarı tekrar etmek bakım maliyetini artırır. Merkezi çoklu hesap düzeninde host alias çoğu zaman daha okunabilir bir yapı sunar.

-i ile IdentityFile

SSH komutundaki -i seçeneği kullanılacak identity file yolunu belirtir. core.sshCommand içinde bu seçenekle repository'ye özel private key seçilebilir. Agent içinde farklı key'ler varsa -o IdentitiesOnly=yes eklemek seçimi netleştirir. Dosya yolunun farklı işletim sistemlerinde değişebileceğini unutmayın. Dotfiles veya ekip dokümantasyonunda kullanıcı home path'ine bağlı taşınabilir ifade kullanmak daha uygundur.

IdentitiesOnly=yes

core.sshCommand içinde -o IdentitiesOnly=yes kullanmak agent'ın ilgisiz key'leri sunmasını sınırlandırır. Yalnızca -i vermek bazı SSH davranışlarında agent identity'lerini tamamen devre dışı bırakmayabilir. Bu nedenle ikisini birlikte kullanmak daha belirgin authentication sağlar. Debug için GIT_TRACE ve SSH verbose seçeneklerinden yararlanabilirsiniz. Repository bazlı yöntem seçtiyseniz aynı prensibi host alias yaklaşımındaki kadar ciddiye almak gerekir.

Repo-Local Configuration

git config core.sshCommand "..." komutu varsayılan olarak repository local config'e yazılabilir. Böylece ayar yalnızca o repository için uygulanır. Hassas private key içeriği config'e yazılmaz, yalnızca dosya yolu bulunur. Yine de config paylaşımı veya support log'larında yerel path bilgisi görünebilir. Repository silindiğinde ayar da onunla birlikte kaybolur.

Avantaj ve Dezavantajları

Repository bazlı SSH command açık ve güçlüdür çünkü hangi key'in kullanılacağı doğrudan repo config'inde bellidir. Buna karşılık her repository için tekrar yapılandırma gerektirir ve cihazlar arasında path farkları oluşturabilir. Host alias ise merkezi config ile çok sayıda repository'yi aynı kimliğe bağlayabilir. Debug açısından iki yöntem de anlaşılır olabilir, fakat ekip standardının tek yöntem üzerinde yoğunlaşması support maliyetini düşürür. Özel veya geçici repository'lerde core.sshCommand, yaygın multi-account kullanımında host alias daha iyi bir denge sağlayabilir.

GIT_SSH_COMMAND Nedir?

GIT_SSH_COMMAND, belirli Git işlemi sırasında kullanılacak SSH komutunu environment variable üzerinden override eder. Kalıcı config yazmadan tek seferlik farklı key seçmek için kullanışlıdır. Özellikle clone işlemi sırasında repository local config henüz oluşmadığı için doğru key'i geçirmek açısından fayda sağlar. Environment variable yalnızca ilgili shell veya komut scope'unda tutulabilir. Günlük kalıcı multi-account çözümü olarak değil, geçici override ve otomasyon aracı olarak değerlendirmek daha doğrudur.

Tek Komutluk SSH Key Override

GIT_SSH_COMMAND='ssh -i ... -o IdentitiesOnly=yes' git fetch benzeri kullanım tek Git komutunda özel key seçebilir. Mevcut SSH config'i değiştirmeden test yapmak için yararlıdır. Komut shell history içinde dosya yolunu gösterebilir, ancak passphrase'i komut satırına yazmamak gerekir. Key seçimi yalnızca ilgili process'e uygulanır. Sorun çözüldükten sonra kalıcı yapı gerekiyorsa host alias veya core.sshCommand tercih edilmelidir.

Clone Sırasında Key Belirlemek

Yeni repository clone edilirken local Git config henüz bulunmaz. Bu nedenle core.sshCommand daha sonra ayarlanacaksa ilk erişim için GIT_SSH_COMMAND kullanılabilir. Host alias kullanıyorsanız buna gerek kalmadan alias içeren URL ile clone yapabilirsiniz. Tek seferlik müşteri erişiminde environment override faydalı olabilir. Clone tamamlandıktan sonra remote ve Git identity mutlaka doğrulanmalıdır.

Environment Variable Scope

GIT_SSH_COMMAND environment variable shell session boyunca export edilebilir veya yalnızca tek komutun başında tanımlanabilir. Session genelinde export etmek sonraki Git komutlarının da aynı key'i kullanmasına neden olabilir. Çoklu hesaplarda bu durum yanlış repository'de beklenmeyen authentication oluşturabilir. Tek komutluk scope daha güvenli ve açık bir kullanım sunar. İşiniz bitince environment değerini kaldırmak veya yeni shell kullanmak faydalıdır.

core.sshCommand ile Farkı

core.sshCommand Git config içinde kalıcı veya scope'a bağlı bir ayardır. GIT_SSH_COMMAND ise environment üzerinden geçici override sağlar. Tek bir repository'nin sürekli özel key kullanması gerekiyorsa core.sshCommand daha uygundur. Clone veya debug sırasında geçici key seçmek için environment variable pratik olabilir. İki mekanizma birlikte tanımlandığında öncelik davranışını Git dokümantasyonu ve gerçek komutla doğrulamak gerekir.

Ne Zaman Kullanılmalı?

GIT_SSH_COMMAND en çok geçici test, tek seferlik clone veya automation script'inde kontrollü SSH option uygulama için uygundur. Geliştiricinin her push öncesi elle environment variable yazması sürdürülebilir değildir. Çoklu hesap düzeninin asıl çözümü otomatik ve öngörülebilir kimlik seçimidir. Host alias veya conditional config günlük kullanımı daha güvenli hâle getirir. Environment override ise ihtiyaç olduğunda escape hatch olarak tutulabilir.

SSH Host Alias mı core.sshCommand mı?

SSH host alias ve core.sshCommand aynı temel sorunu farklı seviyelerde çözer. Host alias SSH config'te merkezi bir kimlik yönlendirme sağlar ve remote URL üzerinden hangi hesabın kullanılacağını gösterir. core.sshCommand ise repository bazında doğrudan SSH komutunu sabitler. Çok sayıda repository ve IDE kullanan kişiler için host alias genellikle daha taşınabilir ve görünür bir modeldir. Tekil veya özel repository ihtiyaçlarında core.sshCommand oldukça pratik olabilir.

Host Alias Avantajları

Host alias tek SSH config üzerinden çok sayıda repository'nin aynı identity'yi kullanmasını sağlar. Remote URL'ye baktığınızda personal veya work alias'ı hemen görebilirsiniz. Clone işlemi sırasında ekstra environment variable gerekmez. IDE'ler system SSH kullanıyorsa aynı config'ten yararlanabilir. Rotasyon sırasında yalnızca alias bloğundaki IdentityFile güncellenerek birçok repository etkilenebilir.

core.sshCommand Avantajları

core.sshCommand repository'nin hangi SSH command'i kullanacağını kendi config'inde açık biçimde belirler. Global SSH config'e dokunmak istemediğiniz geçici veya müşteri ortamlarında faydalıdır. Aynı hostname üzerinde çok özel parametreler gerektiğinde repository bazlı kontrol sağlar. Buna karşılık her repository'nin ayrı ayarlanması gerekir. Key path'inin cihazlar arasında değişmesi portability sorununa dönüşebilir.

IDE Uyumluluğu

System Git ve system SSH kullanan IDE'ler host alias yöntemini genellikle doğal biçimde takip eder. IDE kendi built-in SSH client'ını kullanıyorsa ~/.ssh/config davranışı farklı olabilir. core.sshCommand da IDE'nin Git işlemlerini gerçekten system Git ile yapmasına bağlıdır. Bu nedenle hangi Git ve SSH implementation'ın aktif olduğunu kontrol etmek gerekir. CLI'da çalışan yapı IDE'de çalışmıyorsa ilk bakılması gereken nokta toolchain farkıdır.

Clone Experience

Host alias ile clone URL doğrudan doğru identity'yi taşır. Örneğin work repository git@github-work:org/repo.git biçiminde clone edilebilir. core.sshCommand repository oluşmadan önce local config'e yazılamadığı için ilk clone sırasında başka yöntem gerekir. Bu nedenle onboarding ve günlük clone işlemlerinde host alias daha pürüzsüz bir deneyim sağlar. URL rewrite ile birlikte kullanıldığında organization bazlı otomasyon da yapılabilir.

Repository Portability

Host alias remote URL içinde yerel bir isim taşır ve başka cihazda aynı alias config'i bulunmazsa bağlantı çalışmaz. Ancak bu config dotfiles veya onboarding adımlarıyla kolayca yeniden oluşturulabilir. core.sshCommand içindeki mutlak private key path'i de başka cihazda farklı olabilir. Her iki yaklaşımın portability gereksinimi vardır. Ekip standardında alias isimlerini ve key path şablonlarını aynı tutmak geçişi kolaylaştırır.

Debugging Kolaylığı

Host alias debugging için ssh -G alias ve ssh -vT alias gibi doğrudan araçlar sunar. core.sshCommand sorununda repository config ve Git'in çalıştırdığı gerçek SSH command incelenmelidir. İki yöntem de debug edilebilir, fakat host alias network identity'yi Git'ten bağımsız test etmeyi kolaylaştırır. Ekipte herkes aynı yöntemi kullanıyorsa support dokümantasyonu da sadeleşir. Karma kullanım yalnızca gerçekten gerektiğinde tercih edilmelidir.

url.insteadOf ile Otomatik Account Routing

url.insteadOf, Git remote URL'lerini belirli prefix kurallarına göre otomatik yeniden yazabilir. Çoklu hesaplarda organization URL'sini personal veya work SSH host alias'a yönlendirmek için kullanılabilir. Bu yaklaşım standart GitHub clone URL'sini kopyalayıp yapıştırırken bile doğru alias'a geçiş sağlayabilir. Ancak çok geniş prefix kuralları public repository veya başka organization'larda istenmeyen yönlendirme oluşturabilir. Rewrite kurallarını sınırlı, açık ve test edilmiş tutmak önemlidir.

URL Rewrite Nedir?

URL rewrite Git'in bir remote adresini bağlantı öncesinde başka bir prefix ile değiştirmesidir. Kullanıcı normal URL'yi yazsa bile Git yapılandırmadaki insteadOf kuralını uygular. Bu özellik HTTPS'ten SSH'ye veya gerçek hostname'den host alias'a dönüşüm için kullanılabilir. Çoklu hesaplarda manuel URL düzenleme ihtiyacını azaltır. Yanlış kuralın geniş etkisi olabileceği için effective remote davranışını test etmek gerekir.

GitHub Organization'a Göre Host Alias Seçmek

Belirli bir organization prefix'i work alias'a rewrite edilebilir. Böylece o organization altındaki repository'ler otomatik olarak github-work üzerinden bağlanır. Personal repository'ler normal github.com veya personal alias kullanmaya devam edebilir. Kuralın yalnızca hedef organization URL'sine eşleştiğinden emin olmak gerekir. Aynı organization hem personal hem work erişim senaryosuna sahipse bu otomasyon uygun olmayabilir.

HTTPS URL'yi SSH'ye Dönüştürmek

url.insteadOf ile kopyalanan HTTPS clone URL'si SSH alias URL'sine çevrilebilir. Bu kullanım kullanıcıların web arayüzünden hangi clone seçeneğini kopyaladığına bağımlılığı azaltır. Ancak ekipte HTTPS kullanan kişiler varsa global rewrite beklenmedik davranış yaratabilir. SSH ve HTTPS credential politikalarını netleştirmeden geniş dönüşüm kuralı eklememelisiniz. Lokal kullanıcı bazında uygulanması çoğu durumda daha güvenlidir.

Longest Prefix Matching

Birden fazla insteadOf kuralı eşleştiğinde Git en uzun eşleşen prefix'e göre seçim yapabilir. Bu özellik genel GitHub kuralı ile özel organization kuralını birlikte tasarlamanıza olanak sağlar. Ancak kuralların birbirini gölgelemesi debug sürecini zorlaştırabilir. git remote -v her zaman rewrite sonrası gerçek bağlantı davranışını tam olarak göstermeyebileceği için trace çıktısı gerekebilir. Kuralları az ve açık tutmak en güvenli yaklaşımdır.

Public Repository'lerde Yan Etki Riski

Çok geniş URL rewrite kuralı tüm github.com repository'lerini work alias'a yönlendirebilir. Bu durumda public open source clone işlemleri bile kurumsal SSH key ile yapılmaya çalışılır. Her public repository için authentication gerekmese de yanlış kimlik kullanımı kafa karışıklığı yaratır. Organization bazlı dar prefix bu riski azaltır. Yeni kural ekledikten sonra hem work hem personal hem de public repository örnekleriyle test yapmak gerekir.

Yeni Repository Clone Ederken Doğru Kimlik Nasıl Seçilir?

Yeni clone işlemi multi-account yapının en kritik anlarından biridir çünkü repository local config henüz oluşmamıştır. Host alias kullanıyorsanız doğru alias içeren SSH URL'siyle clone etmek en açık yöntemdir. Directory-based identity kullanıyorsanız clone hedefini baştan personal veya work klasörü altında seçmelisiniz. Gerekirse GIT_SSH_COMMAND ile tek seferlik key override yapılabilir. Clone tamamlanınca remote URL, Git user.email, signing key ve SSH authentication kimliği birlikte doğrulanmalıdır.

Host Alias ile Clone

Work repository için git clone git@github-work:organization/repository.git biçiminde alias içeren URL kullanabilirsiniz. SSH config doğruysa work key otomatik seçilir. Personal repo için aynı mantık github-personal alias ile uygulanır. Bu yöntem clone anında hangi hesabın kullanılacağını URL üzerinde görünür kılar. Ekip onboarding dokümantasyonunda alias isimlerini standartlaştırmak yanlış clone riskini azaltır.

Directory-Based Config Sorunu

Directory-based config repository'nin bulunduğu path'e göre çalıştığı için clone hedef dizini önemlidir. Work repo yanlışlıkla ~/personal/ altına clone edilirse personal identity seçilebilir. Host alias doğru olsa bile commit kimliği yanlış olabilir. Bu nedenle SSH authentication ve Git identity'nin iki ayrı kontrol olduğunu tekrar hatırlamak gerekir. Clone sonrası git config --show-origin user.email çalıştırmak bu hatayı erkenden yakalar.

GIT_SSH_COMMAND ile Clone

Host alias kullanamadığınız tek seferlik durumda GIT_SSH_COMMAND clone komutuna doğru key'i verebilir. IdentitiesOnly=yes eklemek agent içindeki diğer key'lerin devreye girmesini sınırlar. Clone tamamlandıktan sonra kalıcı erişim yöntemi belirlenmelidir. Environment override'ı unutup sonraki repository'lerde kullanmamak için scope'u tek komutla sınırlamak daha güvenlidir. Git identity'nin yine ayrıca yapılandırılması gerekir.

URL Rewrite ile Clone

URL rewrite doğru yapılandırılmışsa kullanıcı standart organization URL'sini clone ederken Git bunu otomatik work alias'a çevirebilir. Bu yöntem onboarding sırasında URL formatı hatalarını azaltabilir. Ancak rule yanlışsa kullanıcı neden farklı account kullanıldığını anlamakta zorlanabilir. insteadOf kurallarını ekibin kolayca görebileceği biçimde belgelemek önemlidir. Debug sırasında global Git config içindeki rewrite değerleri de kontrol edilmelidir.

Clone Sonrası Doğrulama

Clone bittikten sonra git remote -v, git config user.email ve gerekiyorsa git config user.signingKey kontrol edilmelidir. SSH alias için ssh -T testi yapılabilir. İlk commit öncesinde git status kadar identity kontrolünü de alışkanlık hâline getirmek faydalıdır. Kurumsal repository'de yanlış kullanıcı görünüyorsa daha commit oluşturmadan problemi çözebilirsiniz. Bu kısa doğrulama ileride history rewrite ihtiyacını önemli ölçüde azaltır.

Mevcut Repository'leri Çoklu Hesap Yapısına Geçirmek

Mevcut repository'leri yeni multi-account düzene taşımak için repository'yi yeniden clone etmek şart değildir. Önce mevcut remote URL'yi kontrol edin ve gerekiyorsa doğru SSH host alias'a değiştirin. Ardından effective Git identity ve signing config'i doğrulayın. SSH authentication testini ayrı çalıştırmak remote değişikliğinin doğru account'a gittiğini gösterir. Son olarak güvenli bir test branch veya izin verilen küçük commit ile uçtan uca akışı kontrol edebilirsiniz.

Current Remote'u Kontrol Etmek

Migration öncesinde repository'nin gerçekten hangi remote'a bağlı olduğunu bilmek gerekir. Bazı depolarda birden fazla remote veya farklı push URL bulunabilir. git remote -v fetch ve push adreslerini birlikte gösterir. Remote HTTPS ise SSH yapısına geçerken credential modelinin de değişeceğini unutmayın. Submodule varsa onların URL'leri de ayrı kontrol edilmelidir.

git remote -v

git remote -v repository'deki remote adlarını ve fetch/push URL'lerini listeler. Multi-account sorununda remote'un real hostname mi yoksa doğru alias mı kullandığını hızlıca gösterir. origin dışında upstream veya başka remote'lar bulunabilir. Her remote farklı account gerektiriyorsa URL'leri buna göre ayırmanız gerekir. Pushurl tanımlıysa fetch ve push kimlikleri farklı olabilir.

git remote set-url

git remote set-url origin git@github-work:org/repo.git benzeri komut mevcut origin adresini work alias'a geçirebilir. Repository geçmişi veya çalışma dosyaları değişmez. Değişiklikten sonra git remote -v ile sonucu doğrulayın. Ardından ssh -T ve git fetch testleri yapılabilir. Yanlış organization veya repository path yazımında “repository not found” hatası alabileceğiniz için URL'yi dikkatle kontrol edin.

Git Identity Kontrolü

Remote'u değiştirmek commit identity'yi otomatik düzeltmez. Repository doğru work alias'a bağlansa bile local veya global user.email personal olabilir. Migration sırasında git config --show-origin user.name ve user.email değerlerini kontrol edin. Signing kullanıyorsanız user.signingKey kaynağını da doğrulayın. Gerekirse repository'yi doğru work klasörüne taşıyın veya local config uygulayın.

SSH Authentication Testi

Yeni remote alias için ssh -T testi hangi account'un authentication yaptığını gösterir. Bağlantının başarılı olmasına ek olarak dönen username'in beklenen hesap olması gerekir. Yanlış kullanıcı görünüyorsa push işlemi yapmadan önce SSH config ve public key kayıtlarını düzeltin. ssh -vT hangi key'in kabul edildiğini gösterir. Migration sonrası bu test güvenli geçişin en önemli kontrollerinden biridir.

Test Commit

Kimlik ayarını doğrulamak için yeni bir test commit oluşturmak faydalı olabilir. Commit'i push etmeden önce git show --format=fuller ile author ve committer bilgilerini kontrol edin. Signing aktifse imzanın yerelde geçerli olduğunu ve platformda Verified göründüğünü doğrulayın. Paylaşılan ana branch üzerinde gereksiz test commit oluşturmamak gerekir. Uygun bir feature branch veya gerçek küçük değişiklik üzerinden kontrol yapmak daha temizdir.

Bir Repository'de Birden Fazla Remote

Bir repository aynı anda personal fork, corporate upstream ve başka mirror remote'larına sahip olabilir. Her remote farklı SSH host alias kullanarak farklı authentication identity seçebilir. Bu durum fork tabanlı çalışma modellerinde oldukça kullanışlıdır. Commit identity repository seviyesinde aynı kalabilir veya workflow'a göre ayrıca yönetilebilir. Fetch ve push adreslerinin farklı hesaplara gitmesi gerekiyorsa pushurl seçeneği de kullanılabilir.

origin

origin genellikle clone edilen ana remote için kullanılan varsayılan addır. Fork workflow'da origin kişisel fork'unuzu gösterebilir. Remote URL personal host alias kullanıyorsa push personal SSH key ile gerçekleşir. Work repository clone'larında origin kurumsal organization'ı gösterebilir. Remote adının kendisi hesap seçmez; hesap seçimini URL ve SSH config belirler.

upstream

upstream çoğu fork workflow'da orijinal repository'yi temsil eder. Personal fork origin iken corporate veya public ana proje upstream olabilir. Upstream için farklı host alias kullanılması mümkündür. Sadece fetch yapıyorsanız push izni gerekmeyebilir. Hangi remote'un hangi account ve erişim türünü kullandığını ekip dokümantasyonunda belirtmek yanlış push riskini azaltır.

Personal Fork

Personal fork kendi hesabınızdaki repository kopyasıdır ve çoğu açık kaynak katkısında origin olarak kullanılır. SSH URL'si personal host alias'a bağlanabilir. Commit e-postasının personal veya noreply identity olması beklenir. Pull request platform üzerinde personal web session veya CLI hesabıyla oluşturulabilir. Authentication, commit identity ve web PR identity'nin yine ayrı katmanlar olduğunu unutmamak gerekir.

Corporate Upstream

Corporate upstream kuruma ait ana repository olabilir ve work SSH identity gerektirebilir. Personal fork ile aynı çalışma ağacında bulunuyorsa iki remote farklı host alias kullanabilir. Commit identity kurumsal policy'ye göre work e-posta olabilir. Upstream'e push yetkiniz yoksa remote yalnızca fetch için kullanılabilir. Bu yapı açık kaynak ve kurumsal katkı süreçlerinde erişim sınırlarını görünür tutar.

Fetch ve Push İçin Farklı Hesaplar

Bazı özel senaryolarda repository aynı remote adından farklı URL ile fetch ve push yapabilir. Public kaynakları anonymous veya farklı credential ile fetch ederken push için özel account kullanmak mümkündür. Bu modeli gereksiz yere kullanmak debug sürecini zorlaştırabilir. git remote -v iki yön için gerçek URL'leri gösterir. Güvenlik ve okunabilirlik açısından her davranışı açık belgelemek önemlidir.

pushurl

pushurl bir remote'un push sırasında kullanacağı adresi fetch URL'sinden ayrı tanımlamanızı sağlar. Örneğin fetch public URL'den, push personal SSH alias üzerinden yapılabilir. Birden fazla pushurl tanımlandığında Git davranışını iyi anlamak gerekir. Çoklu hesaplarda yanlış push hedefini önlemek için URL'leri test edin. Normal personal/work ayrımında ayrı remote isimleri çoğu zaman daha anlaşılır olabilir.

Fork Workflow'da Çoklu Kimlik Yönetimi

Fork workflow çoklu kimlik kavramlarını aynı repository içinde görünür hâle getirir. Personal fork'a push ederken personal SSH key kullanabilir, corporate upstream'den fetch ederken farklı host alias kullanabilirsiniz. Commit e-postası katkının hangi kimlik altında görünmesini istediğinize göre seçilmelidir. Pull request'i hangi web veya CLI hesabıyla açtığınız authentication key'den bağımsızdır. Bu nedenle fork akışında remote, commit ve platform session kimliklerini ayrı kontrol etmek özellikle önemlidir.

Personal Fork

Personal fork remote'u personal host alias kullanmalıdır. Böylece push işlemleri doğru SSH key üzerinden kişisel hesaba gider. Repository work klasöründe bulunuyorsa conditional Git identity work e-posta seçebilir, bu nedenle path ve commit policy ayrıca değerlendirilmelidir. Açık kaynak katkısı kişisel kimlikle yapılacaksa repository'yi personal çalışma alanında tutmak daha kolaydır. Clone sonrası effective identity kontrolü bu kararı görünür hâle getirir.

Corporate Upstream

Corporate upstream work alias veya enterprise hostname kullanabilir. Fetch için authentication gerekiyorsa kurumsal key devreye girer. Upstream'e doğrudan push engellenmişse branch protection ve permission politikaları ek koruma sağlar. Personal fork'tan pull request açarken commit kimliğinin kurum politikasına uygun olması gerekebilir. Bu ayrımı ekip katkı rehberinde açıkça tanımlamak faydalıdır.

Open Source Contribution

Açık kaynak katkısı yaparken public commit history nedeniyle e-posta gizliliği özellikle önemlidir. Personal noreply e-posta tercih edilebilir. SSH push personal fork'a gidebilirken upstream yalnızca fetch için kullanılabilir. Commit signing personal key ile yapılabilir. Platformdaki pull request hesabının doğru olduğundan da web veya GitHub CLI tarafında emin olmalısınız.

Commit E-postası

Fork workflow'da push hesabı commit e-postasını belirlemez. Personal fork'a iş SSH key'iyle erişebilseniz bile commit e-postası Git config'ten gelir. Contribution'ın hangi hesapla ilişkileneceğini ve hangi e-posta politikasını izlemesi gerektiğini önceden belirleyin. git config user.email kontrolü commit öncesinde yapılabilir. Yanlış commit push edilmediyse düzeltmek çok daha kolaydır.

Push Authentication

Push authentication remote URL'deki host alias ve ilgili SSH key üzerinden belirlenebilir. Origin personal alias kullanıyorsa personal key sunulur. Upstream work alias kullanıyorsa work key seçilir. Agent'da iki key de açık olsa bile IdentitiesOnly yes ayrımı korur. git remote -v hangi push URL'sinin aktif olduğunu gösterir.

Pull Request Identity

Pull request kimliği web oturumu veya GitHub CLI gibi platform istemcisinin aktif hesabına bağlıdır. SSH key'in personal olması PR'ın otomatik olarak personal web hesabıyla açılacağı anlamına gelmez. gh auth status ve gerekirse gh auth switch CLI tarafını kontrol etmeye yardımcı olur. Tarayıcıda da aktif hesap doğrulanmalıdır. Çoklu hesap hatalarının bir kısmı Git doğru çalışırken yalnızca web session'ın yanlış olmasından kaynaklanır.

GitHub + GitLab + Bitbucket Aynı Bilgisayarda

Bir geliştirici aynı cihazda farklı Git hosting platformlarına aynı anda erişebilir. Platform hostname'leri farklı olduğunda SSH key ayrımı daha kolay görünür, fakat her platformda birden fazla account varsa yine host alias gerekir. Anahtarları platform ve account bazında ayırmak düzenli bir model oluşturur. Git commit identity ise hosting platformundan bağımsız olduğu için conditional config ile ayrıca yönetilmelidir. Unified bir naming ve config standardı üç platformdaki çalışma deneyimini tutarlı hâle getirir.

Hosting Platformu Bazlı Key

En basit model her hosting platformu için ayrı SSH key kullanmaktır. GitHub, GitLab ve Bitbucket farklı key'lere sahip olur. Bu yaklaşım bir platformdaki key revoke işlemini diğerlerinden ayırır. Ancak aynı platformda personal ve work hesap varsa account ayrımı için daha fazla key gerekir. Kurumsal kullanımda platform yerine hesap ve cihaz bazlı model daha güçlü izolasyon sağlayabilir.

Hesap Bazlı Key

Hesap bazlı key modeli her platform account'unu bağımsız credential ile ilişkilendirir. Personal GitHub, work GitHub ve client GitLab ayrı key kullanabilir. Hostname zaten farklıysa bazı alias'lara gerek olmayabilir, fakat tutarlı isimlendirme yine faydalıdır. Aynı hostname altında birden fazla account olduğunda alias zorunlu hâle gelir. Platform üzerindeki key title ve fingerprint kayıtları düzenli tutulmalıdır.

Host Alias Standardı

Alias isimlerinde platform ve bağlamı birlikte kullanmak okunabilirliği artırır. github-personal, github-work, gitlab-client-a gibi adlar remote URL üzerinde hesabı açıkça gösterir. Aynı standardı ekip genelinde kullanmak dokümantasyonu sadeleştirir. Alias'ların hangi gerçek hostname ve key'e gittiği ssh -G ile doğrulanabilir. Çok uzun veya belirsiz isimler yerine kısa ve anlamlı bir şema tercih edilmelidir.

Unified Git Config

Unified Git config ortak ayarları global dosyada, identity değerlerini ise conditional include dosyalarında tutabilir. Hosting platformu fark etmeksizin personal klasör personal identity, work klasör work identity kullanır. Platforma özgü davranış gerekiyorsa remote URL tabanlı koşullar eklenebilir. Bu yapı SSH alias katmanından bağımsız fakat onunla uyumlu çalışır. Amaç bütün hesapları tek dosyaya doldurmak değil, ortak ve kimliğe özgü ayarları doğru sınırlarla ayırmaktır.

Platforma Göre Conditional Include

Remote URL koşulları GitHub, GitLab veya belirli Enterprise host'larına göre config seçmek için kullanılabilir. Bu yöntem aynı dizinde farklı platform repository'leri tutan kullanıcılar için faydalıdır. Ancak platform tek başına personal ve work ayrımı için yeterli olmayabilir. Host alias veya organization path'i koşula eklemek daha kesin eşleşme sağlar. Kullanılan Git sürümünün remote URL conditional include özelliğini desteklediğini doğrulamak gerekir.

Aynı GitLab Instance'ında Birden Fazla Hesap

Aynı GitLab hostname üzerinde iki veya daha fazla account kullanmak GitHub çoklu hesap senaryosuyla aynı temel problemi oluşturur. DNS ve gerçek hostname aynı olduğu için SSH'ın hangi key'i sunacağını açık biçimde belirlemek gerekir. Host alias kullanmak en anlaşılır yöntemlerden biridir. Her alias farklı IdentityFile ve IdentitiesOnly yes kullanabilir. Remote URL'deki alias doğrudan hangi GitLab hesabının hedeflendiğini gösterir.

Aynı Hostname Problemi

İki account da gitlab.example.com adresini kullanıyorsa yalnızca hostname'e bakarak identity seçilemez. Agent içindeki anahtarların sırası güvenilir bir hesap seçme yöntemi değildir. Aynı public key'in iki account'ta kullanılmasına platform veya politika izin vermeyebilir. Host alias ile aynı hostname'i iki mantıksal hedefe ayırabilirsiniz. Böylece her remote hangi key'i kullanacağını açıkça belirtir.

Host Alias

gitlab-personal ve gitlab-work gibi alias'lar gerçek GitLab instance'ına yönlendirilebilir. Her blokta HostName aynı kalır. IdentityFile personal veya work private key'i seçer. IdentitiesOnly yes agent içindeki diğer key'leri sınırlar. Clone ve remote URL'lerde bu alias'lar kullanılarak hesap yönlendirmesi yapılır.

Farklı IdentityFile

Her GitLab alias'ı farklı private key dosyasına bağlanmalıdır. Dosya isimlerinde platform ve account bağlamını belirtmek yönetimi kolaylaştırır. Public key karşılıkları doğru GitLab account'una eklenmelidir. Yanlış kayıt varsa SSH config doğru olmasına rağmen farklı username ile authentication gerçekleşebilir. Fingerprint ve ssh -T testleri eşleşmeyi doğrulamaya yardımcı olur.

Remote URL

Repository remote URL hesabın seçildiği görünür kontrol noktasıdır. git@gitlab-work:group/repository.git work alias'ını, personal alias ise kişisel key'i kullanır. URL'yi değiştirmek için git remote set-url kullanılabilir. Aynı repository'de birden fazla remote varsa her biri farklı alias kullanabilir. Remote kontrolü çoklu hesap debugging sırasında ilk adımlardan biri olmalıdır.

Repository Bazlı SSH Command

Host alias kullanmak istemediğiniz belirli GitLab repository'lerinde core.sshCommand kullanılabilir. Bu ayar doğrudan -i ile doğru private key'i seçer. IdentitiesOnly=yes eklemek agent kaynaklı karışıklığı azaltır. Çok sayıda repository'de tekrar gerektiği için merkezi alias yaklaşımına göre daha fazla bakım ister. Özel müşteri ortamlarında veya geçici geçiş dönemlerinde yine de faydalı bir araçtır.

GitHub Enterprise ve GitHub.com Birlikte Kullanımı

GitHub Enterprise ile github.com birlikte kullanıldığında hostname'ler farklıysa SSH kimliği ayrımı doğal olarak daha kolaydır. Buna rağmen personal github.com hesabı ve kurumsal Enterprise hesabı için ayrı key kullanmak gerekir. Enterprise Managed User veya SSO politikaları ek erişim kısıtları getirebilir. Git commit identity ve signing key yine ayrıca yönetilmelidir. Kurumun cihaz, key algoritması, signing ve rotasyon politikaları kişisel GitHub ayarlarından bağımsız tutulmalıdır.

Ayrı Hostname

Enterprise sunucusu çoğu zaman github.company.example gibi ayrı hostname kullanır. Bu durumda normal github.com personal hesapla çakışmaz. Yine de SSH config içinde her hostname için explicit IdentityFile tanımlamak davranışı daha öngörülebilir hâle getirir. Agent'da çok key varsa IdentitiesOnly yes kullanılabilir. Enterprise hostname değişikliği veya migration durumunda merkezi config güncellemesi yapmak kolaydır.

Enterprise Managed User

Enterprise Managed User modeli kullanıcı yaşam döngüsünü kurumun kimlik sistemiyle daha sıkı ilişkilendirebilir. Personal hesap ve kurumsal managed account farklı erişim politikalarına sahip olabilir. SSH key kaydı, SSO ve organization erişimi kurumun yönettiği kurallara tabidir. Bu nedenle kişisel çoklu hesap yöntemini doğrudan kurumsal modele uygulamadan önce policy'yi kontrol etmek gerekir. Offboarding sürecinde identity provider, GitHub membership ve cihaz credential'ları birlikte ele alınmalıdır.

Personal Account

Personal github.com account kurumsal Enterprise kimliğinden ayrı tutulmalıdır. Personal SSH key, personal commit e-posta ve personal signing key kendi config bağlamında kullanılabilir. Kurum kişisel cihaz veya kişisel GitHub account kullanımını sınırlıyorsa bu kurala uyulmalıdır. Aynı tarayıcıda iki hesap açık olsa bile terminal authentication bundan bağımsızdır. Personal repository'lerin work config altında kalmaması için directory veya remote based identity kullanabilirsiniz.

Ayrı SSH Keys

Personal github.com ve Enterprise account için ayrı SSH keys kullanmak revoke ve incident response süreçlerini ayırır. Work cihaz kaybolursa yalnızca kurumsal device key revoke edilebilir. Personal key'in work Enterprise hesabına kaydedilmemesi erişim sınırını korur. İsimlendirme standardı hangi key'in hangi hostname'e ait olduğunu gösterir. Hardware-backed key policy varsa kurumsal key bu modele göre üretilebilir.

Corporate Policy

Kurumsal Git kullanımı yalnızca geliştiricinin teknik tercihi değildir. SSO, key rotation, hardware key, commit signing, cihaz compliance ve erişim review gibi policy'ler uygulanabilir. Kişisel workflow'u kolaylaştıran bir ayar kurumsal ortamda yasak olabilir. Bu nedenle şirketin resmi geliştirme güvenliği standardı önceliklidir. Eksik politika varsa ekip için açık bir Git SSH ve geliştirici kimlik yönetimi standardı oluşturmak uzun vadede hata sayısını azaltır.

HTTPS ile Çoklu Git Hesabı Kullanımı

SSH çoklu hesap yönetimi için güçlü bir yöntem olsa da HTTPS de geçerli bir alternatiftir. HTTPS tarafında SSH key yerine token ve credential helper mekanizmaları devreye girer. Git Credential Manager birden fazla account credential'ını host ve path bağlamına göre yönetmeye yardımcı olabilir. Aynı hostname'de farklı account kullanırken URL ve credential helper yapılandırmasının doğru ayrımı yapması gerekir. Kurum politikası SSO veya token rotation nedeniyle HTTPS kullanımını tercih edebilir.

SSH Yerine HTTPS

HTTPS remote URL'leri firewall ve proxy bulunan bazı kurumsal ortamlarda daha kolay çalışabilir. Authentication çoğunlukla password yerine personal access token veya OAuth tabanlı credential manager üzerinden yapılır. Çoklu hesaplarda credential helper'ın hangi URL için hangi account'u seçtiği önemlidir. SSH host alias modelinin karşılığı burada URL ve credential context ayrımıdır. Ekip mevcut toolchain ve güvenlik politikası üzerinden iki yöntemi değerlendirmelidir.

Personal Access Token

Personal access token Git hosting platformunda belirli scope ve sürelerle oluşturulabilen credential türüdür. Token'ı düz metin shell script veya remote URL içinde tutmak güvenli değildir. Credential helper veya güvenli secret store kullanmak gerekir. Çoklu hesaplarda personal ve work token'ları ayrı oluşturulmalı ve minimum gerekli scope prensibi uygulanmalıdır. Token rotation ve revoke işlemleri SSH key lifecycle'dan farklı süreçlere sahiptir.

Credential Helper

Git credential helper HTTPS authentication sırasında credential saklama ve alma işlemlerini yönetir. Farklı işletim sistemlerinde farklı helper seçenekleri bulunur. Çoklu hesaplarda helper'ın host ile birlikte path bilgisini dikkate alıp almadığı önemlidir. Yanlış yapılandırma bir hesabın token'ını başka repository için sunabilir. credential.useHttpPath gibi ayarlar ihtiyaç halinde değerlendirilmelidir.

Git Credential Manager

Git Credential Manager modern HTTPS Git authentication deneyimini kolaylaştıran araçlardan biridir. Desteklenen platformlarda browser tabanlı giriş, token yenileme ve hesap seçimi gibi işlemleri yönetebilir. Çoklu hesaplarda active credential ve remote URL eşleşmesini doğru anlamak gerekir. GitHub CLI identity ile Git Credential Manager credential'ı da aynı şey olmayabilir. SSH kullanmıyorsanız credential debugging için helper config ve stored account durumunu kontrol etmelisiniz.

Full Remote URL Bazlı Credential Ayrımı

Aynı hostname altında farklı organization veya account kullanıyorsanız yalnızca host bazlı credential eşleşmesi yeterli olmayabilir. Path bilgisinin credential lookup'a dahil edilmesi daha kesin ayrım sağlayabilir. Böyle bir yapıda remote URL'lerin tutarlı formatta olması önemlidir. Credential helper'ın desteklediği davranışı işletim sistemi üzerinde test etmelisiniz. Kurumsal dokümantasyonda örnek URL ve account eşleşmelerini açıkça göstermek onboarding hatalarını azaltır.

SSH ve HTTPS Karşılaştırması

SSH anahtar tabanlı authentication, host alias ve agent ile güçlü bir geliştirici deneyimi sunar. HTTPS ise token veya OAuth credential manager sayesinde kurumsal SSO ve proxy altyapılarıyla daha rahat bütünleşebilir. SSH'ta key rotation, HTTPS'te token rotation yönetilir. Her iki modelde de commit identity bağımsızdır. En doğru tercih ekip politikası, otomasyon ihtiyacı, cihaz yönetimi ve geliştiricilerin kullandığı araçlara göre yapılmalıdır.

SSH mi HTTPS mi?

SSH ve HTTPS arasında tek bir evrensel doğru yoktur. SSH, çoklu hesaplarda host alias ve ayrı private key'lerle açık bir identity routing modeli sağlar. HTTPS, Git Credential Manager ve modern OAuth akışlarıyla hesap girişini kullanıcı dostu hâle getirebilir. Kurumsal SSO, token rotation, ağ politikası ve CI/CD modeli seçim üzerinde etkili olur. Kişisel geliştirici deneyimi ile kurumsal erişim yönetimini birlikte değerlendirerek ekip standardı belirlemek en sağlıklı yaklaşımdır.

Credential Management

SSH credential yönetimi private/public key çiftleri ve agent üzerinden çalışır. HTTPS tarafında token veya credential manager kullanılır. SSH private key'i diskte korunurken HTTPS credential güvenli işletim sistemi kasasında tutulabilir. İki yöntemin incident response adımları farklıdır. Ekip hangi credential tipini kullandığını envanterde açıkça izlemelidir.

Passphrase

SSH private key passphrase ile şifrelenebilir ve agent günlük kullanımı kolaylaştırır. HTTPS token'ında SSH passphrase kavramı yoktur. Token'ın kendisi secret olduğu için güvenli credential store içinde tutulmalıdır. Passphrase yanlışlıkla platform hesabı şifresiyle karıştırılmamalıdır. Güvenlik değerlendirmesi credential tipinin çalışma şekline göre yapılmalıdır.

Token Rotation

HTTPS kullanımında token expiration ve rotation önemli operasyonel konulardır. Fine-grained veya kısa ömürlü token modeli kurum politikasına göre tercih edilebilir. SSH key rotasyonu ise yeni public key kayıt, bağlantı testi ve eski key revoke sürecini içerir. İki modelde de eski credential'ı gereksiz yere aktif tutmamak gerekir. Otomasyon credential'ları geliştirici kişisel token'larından ayrı yönetilmelidir.

SSO

Kurumsal SSO hem SSH key authorization hem HTTPS token akışlarında etkili olabilir. Platform ve organization politikası key veya token'ın ayrıca SSO ile authorize edilmesini isteyebilir. SSO oturumunun süresi dolduğunda credential teknik olarak mevcut olsa bile erişim engellenebilir. Bu nedenle authentication hatasını yalnızca local key problemine bağlamamak gerekir. Kurumsal erişim troubleshooting rehberinde SSO durumunu ayrı kontrol olarak eklemek faydalıdır.

Kurumsal Policy

Bazı kurumlar yalnızca HTTPS veya yalnızca yönetilen SSH key yöntemine izin verebilir. Seçim geliştiricinin kişisel tercihini aşan güvenlik ve denetim gerekçelerine dayanabilir. Donanım anahtarı, token süresi, signing zorunluluğu ve cihaz compliance gereksinimleri birlikte uygulanabilir. Ekip standart dışı yöntem kullanmadan önce resmi policy'yi kontrol etmelidir. Güvenli süreç geliştirici deneyimini mümkün olduğunca az sürtünmeyle desteklemelidir.

Developer Experience

SSH agent doğru yapılandırıldığında push ve fetch işlemleri oldukça akıcı çalışır. HTTPS credential manager da browser tabanlı login sayesinde kullanıcı dostu olabilir. Çoklu hesaplarda asıl deneyim farkını hangi yöntemin account switching'i daha öngörülebilir yaptığı belirler. Host alias SSH tarafında çok güçlü bir görünürlük sağlar. HTTPS tarafında credential context iyi yapılandırılmazsa aynı hostname üzerinde hesap karışıklığı yaşanabilir.

Automation

CI/CD içinde geliştirici kişisel SSH key veya personal token kullanılmamalıdır. SSH seçiliyorsa deploy key veya service account anahtarı, HTTPS seçiliyorsa repository-scoped token veya platforma özel kısa ömürlü credential tercih edilebilir. Secret'lar pipeline log'una yazılmamalıdır. Rotation ve revoke otomasyon tasarımının parçası olmalıdır. İnsan kullanıcı credential'ı ile makine credential'ını ayırmak çoklu kimlik yönetiminin temel güvenlik prensiplerinden biridir.

GitHub CLI ile Çoklu Hesap Yönetimi

GitHub CLI, web API ve platform işlemleri için kendi authentication durumuna sahiptir. Bu kimlik SSH key seçiminizden bağımsızdır. Terminalde work SSH alias ile push yaparken gh personal account ile aktif olabilir. Pull request veya issue komutları bu durumda beklenmeyen hesap üzerinden çalışabilir. gh auth status ve gh auth switch aktif CLI hesabını kontrol etmek için kullanılabilir.

Birden Fazla Hesapla Login

GitHub CLI desteklenen sürümlerde aynı host için birden fazla account credential'ını yönetebilir. Hesaplar arasında geçiş yapılabilmesi web ve API workflow'larını kolaylaştırır. Bunun SSH host alias'larıyla otomatik senkronize olmadığını unutmamak gerekir. Repository work remote kullanıyor diye gh otomatik work account'a geçmeyebilir. CLI işlemi öncesinde aktif account'u kontrol etmek güvenli bir alışkanlıktır.

gh auth status

gh auth status GitHub CLI'ın hangi host ve account'larla authenticated olduğunu gösterir. Yanlış hesapla PR açma problemi yaşadığınızda ilk bakılacak komutlardan biridir. Birden fazla account kayıtlıysa aktif durum hakkında bilgi verir. Çıktıyı paylaşırken token veya hassas ayrıntı bulunmadığını yine de kontrol etmelisiniz. SSH authentication testiyle birlikte kullanıldığında iki ayrı kimlik katmanı net biçimde görünür.

gh auth switch

gh auth switch desteklenen GitHub CLI sürümlerinde aynı host üzerindeki kayıtlı account'lar arasında aktif hesabı değiştirmeye yardımcı olur. Work ve personal CLI işlemleri arasında geçişte kullanılabilir. Bu değişiklik Git remote URL'sini veya SSH key seçimini değiştirmez. Dolayısıyla push hesabı ile gh hesabı ayrı ayrı kontrol edilmelidir. Scriptlerde aktif account'a güvenmek yerine gerekiyorsa host ve repository context açık biçimde verilmelidir.

Git SSH Identity ile CLI Identity'nin Farkı

Git SSH identity remote'a network authentication yapan key üzerinden belirlenir. GitHub CLI identity ise CLI'ın API çağrılarında kullandığı token veya login bilgisidir. İki mekanizma farklı credential store kullanabilir. Bu nedenle biri doğru çalışırken diğeri yanlış hesapta olabilir. Çoklu hesap dokümantasyonunda bu ayrımı özellikle belirtmek kullanıcı hatalarını ciddi biçimde azaltır.

Yanlış Web/CLI Hesabı Problemi

Yanlış web veya CLI hesabıyla PR açılması kodun yanlış SSH account ile push edildiği anlamına gelmez. Kullanıcı bazen terminal tarafını defalarca debug ederken sorun yalnızca gh veya browser session'dadır. Önce işlemin hangi katmanda başarısız olduğunu belirlemek gerekir. PR, issue ve release gibi platform operasyonlarında CLI/web account kontrolü yapılmalıdır. Git fetch ve push probleminde ise SSH veya HTTPS credential katmanına bakılmalıdır.

Commit Signing Nedir?

Commit signing bir commit'in belirli bir kriptografik anahtar tarafından imzalandığını doğrulama imkânı sağlar. Commit author alanı yalnızca metinsel isim ve e-posta bilgisidir, signature ise ayrı bir doğrulama katmanıdır. Git GPG, SSH ve desteklenen diğer signing yöntemleriyle çalışabilir. Platform doğru public signing key'i hesabınızla eşleştirdiğinde commit Verified olarak gösterilebilir. Kurumsal repository'lerde branch veya policy seviyesinde signed commit zorunluluğu uygulanabilir.

Commit Author ile Signature Arasındaki Fark

Commit author, commit metadata'sında yazan isim ve e-postadır. Signature ise commit içeriğine bağlı kriptografik kanıttır. Bir kişi herhangi bir user.name yazabilir, fakat geçerli private signing key olmadan o anahtara ait imzayı oluşturamaz. Çoklu hesaplarda doğru author ve doğru signing key'in birlikte seçilmesi gerekir. Conditional config iki değeri aynı kimlik profili altında yönetmeye yardımcı olur.

Verified Commit

Git hosting platformundaki Verified işareti commit imzasının platformun tanıdığı signing key ile doğrulandığını gösterir. Authentication için kullandığınız SSH key'in kayıtlı olması tek başına commit'in Verified görünmesini sağlamaz. Signing key'in uygun kullanım türüyle hesabınıza eklenmesi gerekebilir. Commit'in e-posta ve hesap ilişkilendirmesi de platform davranışına göre önem taşıyabilir. Yanlış hesabın signing key'i kullanılırsa signature teknik olarak geçerli olsa bile beklenen identity sonucu oluşmayabilir.

GPG Signing

GPG uzun süredir Git commit signing için kullanılan yöntemlerden biridir. Private GPG key ve public key dağıtımı SSH authentication'dan ayrı yönetilir. Çoklu hesaplarda personal ve work GPG key'leri conditional config ile seçilebilir. Key expiration, revocation ve agent yönetimi ayrıca planlanmalıdır. Kurum mevcut GPG altyapısı kullanıyorsa SSH signing'e geçmeden önce policy ve uyumluluk gereksinimleri değerlendirilmelidir.

SSH Signing

Git modern sürümlerde SSH key tabanlı commit signing desteği sunar. gpg.format=ssh ayarı signing backend olarak SSH'ı seçebilir. user.signingKey ilgili public veya private key bağlamını belirtir. Authentication key ile aynı key teknik olarak kullanılabilse de güvenlik ve yaşam döngüsü nedeniyle ayrı signing key tercih edilebilir. Çoklu hesaplarda personal ve work signing key'lerini conditional config ile ayırmak en temiz yapılardan biridir.

Kurumsal Repository'lerde Neden Kullanılır?

Signed commit politikası commit'in belirli bir geliştirici anahtarından geldiğini doğrulamak için ek güven sağlar. Özellikle yüksek güvenlikli kod tabanlarında supply chain kontrollerinin bir parçası olabilir. Branch protection yalnızca Verified commit kabul edecek biçimde ayarlanabilir. Bununla birlikte signing tek başına kod incelemesi, CI veya erişim kontrolünün yerine geçmez. Kurumsal süreçte key issuance, revoke ve offboarding ile birlikte ele alınmalıdır.

SSH ile Commit Signing

SSH signing, mevcut SSH anahtar ekosistemini commit imzalama için de kullanabilmenizi sağlar. Git config içinde signing formatını SSH olarak belirleyip uygun user.signingKey tanımlanır. commit.gpgsign=true ile commitlerin varsayılan olarak imzalanması sağlanabilir. Çoklu hesaplarda bu ayar personal ve work config dosyalarında ayrı signing key'lerle birlikte tutulmalıdır. Platform tarafında public key'in signing amacıyla doğru hesapta kayıtlı olduğundan emin olmak gerekir.

gpg.format=ssh

gpg.format=ssh Git'e signing işlemlerinde SSH formatını kullanmasını söyler. Ayarın adı GPG içerse de değer SSH signing backend'ini seçer. Kullanılan Git sürümünün SSH signing desteğine sahip olması gerekir. Conditional config ile yalnızca belirli identity profillerinde uygulanabilir. Sistem genelinde açmadan önce mevcut GPG workflow'larını etkileyip etkilemediğini kontrol etmek faydalıdır.

user.signingKey

user.signingKey commit imzalamada kullanılacak anahtarı belirler. Work config kurumsal signing key'i, personal config ise kişisel signing key'i gösterebilir. Path veya supported key identifier kullanımını Git sürümünüze göre doğrulamalısınız. Yanlış signing key kullanılması authentication'ı bozmaz, ancak commit verification beklenenden farklı olabilir. git config --show-origin user.signingKey değer kaynağını hızlıca gösterir.

commit.gpgsign

commit.gpgsign=true oluşturulan commitlerin varsayılan olarak imzalanmasını sağlar. Kurumsal policy signed commit gerektiriyorsa work config içinde etkinleştirilebilir. Personal projelerde de aynı güvenlik alışkanlığını sürdürmek mümkündür. Signing key veya agent erişimi hazır değilse commit işlemi hata verebilir. Bu nedenle onboarding sırasında signing setup ve troubleshooting adımları birlikte verilmelidir.

Public Key ile Signing Key Tanımlama

SSH signing modelinde platformun imzayı doğrulayabilmesi için public signing key bilgisine ihtiyacı vardır. Authentication public key kaydından farklı bir usage type söz konusu olabilir. Aynı key materyalini signing için kullanıyorsanız platformun signing kaydı ayrıca yapılmalıdır. Daha iyi ayrım isteniyorsa ayrı signing key üretilebilir. Key fingerprint ve title standardı authentication ve signing kayıtlarını kolayca ayırmanıza yardımcı olur.

Authentication Key ile Aynı Key Kullanılabilir mi?

Teknik destek ve platform kurallarına bağlı olarak aynı SSH key hem authentication hem signing amacıyla kullanılabilir. Buna rağmen iki kullanımın güvenlik anlamı farklıdır. Authentication key network erişimini, signing key ise commit authenticity'yi temsil eder. Ayrı key kullanmak revoke ve audit işlemlerini daha esnek hâle getirir. Kurumsal policy varsa hangi modelin zorunlu olduğunu kurum standardı belirlemelidir.

Çoklu Hesap İçin Ayrı Signing Keys

Personal ve work hesaplar için ayrı signing keys kullanmak authentication key ayrımını commit doğrulama katmanına da taşır. Kişisel commitler kişisel signing key, kurumsal commitler iş signing key ile imzalanır. includeIf bu seçimi klasör veya remote bağlamına göre otomatikleştirebilir. Platformda her public signing key doğru hesaba kaydedilmelidir. Offboarding veya cihaz kaybında yalnızca etkilenen signing key revoke edilebilir.

Personal Signing Key

Personal signing key kişisel ve açık kaynak commitlerinizi imzalamak için kullanılabilir. Authentication key ile aynı dosyayı kullanmak mümkün olsa da ayrı key daha belirgin yaşam döngüsü sunar. Personal Git config içinde user.signingKey bu key'e yönlendirilebilir. Platform hesabına signing kullanım türüyle eklenmesi gerekir. Commit sonrası Verified durumunu test etmek ilk kurulumda önemlidir.

Work Signing Key

Work signing key kurumsal repository'lerde policy uyumlu commit üretmek için kullanılabilir. Key algoritması ve hardware-backed gereksinimi şirket standardına göre belirlenebilir. Work Git config yalnızca bu key'i kullanmalıdır. Anahtarın kişisel repository'de devreye girmemesi conditional include ile sağlanabilir. İşten ayrılma sürecinde signing key kaydı da authentication key ile birlikte revoke edilmelidir.

includeIf ile Otomatik Signing Key

Conditional config yalnızca user.email değil, user.signingKey ve commit.gpgsign değerlerini de profile göre yükleyebilir. Bu sayede work klasöründeki commitler otomatik work key ile imzalanır. Personal klasörde personal signing key seçilir. Kullanıcı her repository'de elle key değiştirmek zorunda kalmaz. Effective config'i kontrol ederek doğru key'in seçildiğini düzenli olarak doğrulamak gerekir.

Kurumsal Signing Policy

Kurum signed commit zorunluluğu getiriyorsa hangi signing formatının kabul edildiği açıkça belgelenmelidir. GPG, SSH veya platforma özgü yöntemlerden biri tercih edilebilir. Signing key issuance, rotation ve revoke işlemleri erişim lifecycle ile birlikte tasarlanmalıdır. Yalnızca Verified etiketi görmek yeterli bir güvenlik programı değildir. Branch protection, code review ve CI kontrolleri signing politikasını tamamlamalıdır.

Verified Durumunu Kontrol Etmek

İlk signed commit sonrasında platformdaki commit detayında verification durumunu kontrol edin. Verified görünmüyorsa key'in doğru hesapta signing olarak kayıtlı olup olmadığını inceleyin. Local git log --show-signature veya ilgili doğrulama komutları imza durumunu gösterebilir. Yanlış user.signingKey kaynağını --show-origin ile bulabilirsiniz. Authentication'ın başarılı olması signing setup'ın doğru olduğunu garanti etmez.

Authentication Key ve Signing Key Neden Karıştırılmamalı?

Authentication ve signing aynı SSH algoritmasını kullanabilse de farklı güvenlik amaçlarına hizmet eder. Authentication key uzak Git sunucusuna erişim sağlar. Signing key commit veya tag'in belirli bir private key tarafından imzalandığını kanıtlar. Aynı key materyalinin iki rolde kullanılması mümkün olsa bile platform kayıtları ve revoke etkileri farklı olabilir. Çoklu hesap tasarımında bu iki kimliği kavramsal olarak ayrı tutmak hata çözümünü ve audit süreçlerini kolaylaştırır.

Network Authentication

Network authentication clone, fetch ve push sırasında sunucunun sizi hangi account olarak tanıdığını belirler. Remote URL ve SSH config bu süreçte önemlidir. Commit içeriği veya user.email authentication key seçimini değiştirmez. ssh -T network identity testidir. Signing sorununu çözmek için network authentication debug etmek çoğu durumda yanlış katmana bakmak olur.

Commit Authenticity

Commit authenticity bir commit'in belirli signing key ile imzalandığını doğrulamaya odaklanır. Bu işlem network bağlantısından bağımsız olarak yerelde yapılabilir. Commit daha sonra HTTPS üzerinden push edilse bile signature commit nesnesinde kalır. Bu nedenle SSH signing kullanmak Git remote'un da SSH olması gerektiği anlamına gelmez. Çoklu kimlikte signing key ve authentication yöntemini ayrı tasarlayabilirsiniz.

GitHub'da Key Usage Type

GitHub SSH key kaydı sırasında desteklenen kullanım türleri authentication ve signing amaçlarını ayırabilir. Public key'in platformda hangi role kaydedildiğini kontrol etmek önemlidir. Yalnız authentication olarak eklenen key'in commit signature doğrulamasında beklediğiniz sonucu vermemesi mümkündür. Aynı key materyali iki rol için kullanılacaksa ilgili platform yönergelerine göre ayrıca kayıt gerekebilir. Kurumsal policy iki rol için farklı key zorunlu kılabilir.

Aynı Public Key'in Signing İçin Ayrıca Tanımlanması

Aynı SSH key hem authentication hem signing için kullanılacaksa public key'in signing bağlamında platform hesabına ayrıca tanıtılması gerekebilir. Bu ayrım platformun key'i hangi amaçla değerlendireceğini belirler. Kullanıcı “SSH push çalışıyor, neden commit Verified değil?” dediğinde en sık gözden kaçan noktalardan biri budur. Platform key ayarlarını ve user.signingKey değerini birlikte kontrol etmek gerekir. Uzun vadede ayrı signing key kullanmak rolleri daha açık hâle getirebilir.

Git E-posta Gizliliği

Git commit e-postası repository geçmişinin bir parçasıdır ve public repository'de herkes tarafından görülebilir. Bu nedenle kişisel ve kurumsal e-posta kullanımını bilinçli ayırmak önemlidir. GitHub gibi platformların sunduğu noreply adresleri kişisel adresinizi açık etmeme konusunda yardımcı olabilir. Kurumsal e-posta açık kaynak katkısına yanlışlıkla eklenirse history içinde kalabilir. Conditional config ve user.useConfigOnly bu tür hataları commit oluşmadan önce azaltır.

Commit E-postasının Public Olması

Public Git repository'sindeki commit nesneleri author ve committer e-posta bilgisini içerir. Repository clone edildiğinde bu metadata yerel olarak da görülebilir. Web arayüzü e-postayı gizlese bile Git history farklı araçlarla incelenebilir. Bu nedenle commit atarken kullandığınız adresi gizli bilgi gibi değerlendirmek gerekir. Public paylaşılmasını istemediğiniz corporate veya personal adresleri uygun config ile koruyun.

GitHub Noreply Address

GitHub hesaplara noreply e-posta seçeneği sunarak gerçek e-posta adresinin commitlerde görünmesini azaltabilir. Adres formatı hesap ayarlarına göre değişebileceği için platformdaki güncel değeri kullanmalısınız. Personal config'e bu adres eklenebilir. Commit attribution için noreply adresin hesabınızla doğru ilişkilendiğini doğrulayın. Kurumsal repository'de şirket policy gerçek corporate e-posta isteyebilir, bu nedenle her bağlamda aynı adres kullanılmamalıdır.

Corporate E-mail'in Open Source Repository'ye Sızması

Corporate e-posta public open source repository'ye girdiğinde geçmişten tamamen kaldırmak kolay olmayabilir. Push edilmemiş commitlerde author düzeltmek basittir, fakat yayınlanmış geçmiş history rewrite gerektirebilir. Shared branch'lerde force push ek problemlere neden olur. En iyi çözüm hatayı daha commit oluşmadan engellemektir. Personal open source workspace için ayrı conditional identity bu konuda güçlü koruma sağlar.

Personal ve Work E-postalarının Ayrılması

Personal ve work e-posta ayrımı en iyi otomatik config ile yapılır. Klasör veya remote tabanlı includeIf farklı user.email değerlerini yükleyebilir. Global fallback kullanmamak yanlış adresin sessizce devreye girmesini önler. user.useConfigOnly=true kimlik yoksa commit'i durdurur. Böylece kullanıcı sürekli hangi hesabın aktif olduğunu manuel takip etmek zorunda kalmaz.

Yanlış Kimlikle Commit Atılırsa Ne Yapılmalı?

Yanlış user.name veya user.email ile commit oluşturduğunuzda yapılacak işlem commit'in push edilip edilmediğine göre değişir. Henüz paylaşılmamış son commit genellikle kolayca amend edilebilir. Birden fazla yerel commit rebase ile yeniden yazılabilir. Push edilmiş history ise diğer geliştiricileri etkileyebileceği için daha dikkatli ele alınmalıdır. Özellikle shared branch üzerinde force push uygulamadan önce ekip süreci ve repository policy kontrol edilmelidir.

Push Edilmemiş Son Commit

Son commit henüz remote'a push edilmediyse düzeltme en kolay aşamadadır. Önce doğru user.name ve user.email config'i ayarlayın. Ardından git commit --amend --reset-author gibi uygun yöntemle author bilgisini güncelleyebilirsiniz. Commit imzalıysa yeni commit yeniden imzalanmalıdır çünkü commit hash değişir. Sonucu git show --format=fuller ile kontrol etmek iyi bir uygulamadır.

Commit Author Düzeltme

Author düzeltmesi commit nesnesini değiştirdiği için yeni commit hash'i oluşur. Yanlış e-posta sadece metadata gibi görünse de Git için commit içeriğinin bir parçasıdır. Son committe amend, eski commitlerde interactive rebase kullanılabilir. Düzeltme sonrasında signature da yeniden oluşturulmalıdır. Push edilmemiş geçmişte bu işlem genellikle düşük risklidir.

Birden Fazla Commit'i Düzeltmek

Birden fazla geçmiş commit yanlış kimlikle oluşturulduysa interactive rebase veya history rewrite araçları gerekebilir. Hangi commitlerin değiştirileceğini dikkatle belirlemek gerekir. Her değişiklik sonraki commit hash'lerini etkileyebilir. Repository henüz paylaşılmadıysa işlem daha güvenlidir. Remote'a yayınlanmış branch için ekip koordinasyonu olmadan history rewrite yapmak önerilmez.

Push Edilmiş History

Push edilmiş commitleri değiştirmek remote history'nin yeniden yazılması anlamına gelir. Diğer geliştiricilerin local branch'leri eski commit hash'lerine dayanıyor olabilir. Pull request, tag veya CI kayıtları da etkilenebilir. E-posta gizliliği gibi güçlü gerekçe varsa repository yöneticisiyle koordineli plan yapılmalıdır. Bazı durumlarda history rewrite yerine hatayı kabul edip gelecekte doğru identity kullanmak daha az riskli olabilir.

History Rewrite Riski

History rewrite commit hash'lerini değiştirir ve branch'in mevcut ortak geçmişinden farklılaşmasına neden olur. Downstream clone'lar, fork'lar ve açık pull requestler etkilenebilir. Büyük public repository'de yalnızca e-posta düzeltmek için geniş rewrite ciddi operasyonel maliyet yaratabilir. Karar vermeden önce etkinin kapsamını değerlendirin. Preventive config kullanmak bu nedenle düzeltme araçlarından daha değerlidir.

Shared Branch'lerde Force Push Riski

Shared branch'e force push başka geliştiricilerin commitlerini kaybetme veya history'yi karıştırma riski taşır. Branch protection çoğu kurumsal repository'de force push'u zaten engeller. Rewrite zorunluysa ekip koordinasyonu, backup ve doğru force-with-lease stratejisi değerlendirilmelidir. Ana branch üzerinde ani force push yapılmamalıdır. Yanlış identity problemi için gelecekte fail-safe config kurmak daha güvenli çözüm sunar.

Yanlış Kimliği Commit'ten Önce Engellemek

Yanlış commit'i sonradan düzeltmek yerine commit oluşmadan engellemek çok daha güvenlidir. user.useConfigOnly açık identity yoksa commit'i durdurabilir. Pre-commit veya commit-msg hook gibi kontroller expected e-mail domain'i doğrulayabilir. Repository remote organization ile user.email arasında uyum kontrolü yapılabilir. Kurumsal ortamlarda fail-closed yaklaşım kullanıcıya hatayı erken gösterir ve history rewrite ihtiyacını azaltır.

user.useConfigOnly

user.useConfigOnly=true temel fail-closed kimlik kontrolüdür. Explicit user.name ve user.email bulunmadığında Git'in sistemden tahmin üretmesini önler. Conditional include çalışmıyorsa commit hata verir ve kullanıcı config'i düzeltir. Bu davranış özellikle yeni repository clone işlemlerinde değerlidir. Tek global kimliği silmek başlangıçta birkaç hata mesajı yaratabilir, fakat uzun vadede yanlış commit riskini önemli ölçüde azaltır.

Pre-Commit Hook

Pre-commit hook commit oluşturulmadan önce ek kontroller çalıştırabilir. Work repository'de user.email domain'inin şirket alan adıyla eşleştiğini kontrol etmek mümkündür. Hook'ların geliştirici cihazlarında nasıl dağıtılacağı ve bypass edilip edilemeyeceği ayrıca düşünülmelidir. Güvenlik açısından yalnız local hook'a güvenmek yeterli değildir; server-side veya CI kontrolleriyle desteklenebilir. Yine de kullanıcıya erken geri bildirim vermek açısından oldukça faydalıdır.

Expected E-mail Domain Kontrolü

Kurumsal repository'ler için @company.example gibi beklenen domain kontrolü uygulanabilir. Bu kontrol personal e-posta ile commit atılmasını engeller. Ancak contractor veya bot account gibi istisnalar varsa kural bu gerçekliği desteklemelidir. Noreply veya privacy adreslerinin kabul edilip edilmediği policy'de açık olmalıdır. Kontrolün hem local geliştirici deneyiminde hem CI tarafında tutarlı olması yararlıdır.

Repository Organization Kontrolü

Remote URL'deki organization veya hostname Git identity doğrulaması için ek sinyal olabilir. Work organization remote'u tespit edildiğinde expected corporate email zorunlu tutulabilir. Bu yöntem klasör yapısına bağımlılığı azaltır. URL rewrite veya multiple remote kullanılan repository'lerde hangi remote'un referans alınacağı açıkça belirlenmelidir. Yanlış pozitifleri azaltmak için kural geniş değil, hedefe özel yazılmalıdır.

Fail-Closed Yaklaşımı

Fail-closed yaklaşım eksik veya şüpheli kimlik durumunda işlemin devam etmemesini tercih eder. Kullanıcı birkaç saniye config düzeltmek zorunda kalır, fakat yanlış kimlikle kalıcı history üretmez. SSH tarafında explicit identity, Git tarafında explicit user.email ve signing tarafında doğru key bu yaklaşımın parçalarıdır. CI politikaları da aynı modeli server-side doğrulamayla tamamlayabilir. Çoklu hesap yönetiminde güvenli varsayılanların amacı kullanıcıya sürekli yük bindirmek değil, hatalı sessiz başarıyı azaltmaktır.

IDE'lerde Çoklu Git Hesabı

IDE'ler Git ve SSH işlemlerini her zaman terminalinizle aynı binary veya agent üzerinden çalıştırmayabilir. VS Code çoğunlukla system Git ile iyi bütünleşirken bazı JetBrains ürünlerinde built-in SSH seçeneği bulunabilir. IDE'nin platform hesabıyla login olması Git CLI authentication hesabını otomatik değiştirmez. Aynı repository terminalde çalışıp IDE'de hata veriyorsa kullanılan Git, SSH client ve environment değerlerini karşılaştırmak gerekir. Çoklu hesap config'inizi mümkün olduğunca system Git ve standard SSH üzerinde merkezileştirmek araçlar arası farkı azaltır.

VS Code

VS Code Git işlemlerinde genellikle sistemdeki Git binary'sini kullanır. Entegre terminalde doğru çalışan git config ve SSH host alias yapısı çoğu durumda Source Control tarafında da çalışır. Remote WSL, Dev Container veya Remote SSH kullanıldığında Git işlemlerinin başka ortamda gerçekleşebileceğini unutmayın. VS Code'daki GitHub account login'i extension ve settings sync gibi işlemler için ayrı olabilir. Sorun yaşandığında Output panelindeki Git log'ları hangi komutların çalıştırıldığını gösterir.

JetBrains IDE'leri

JetBrains IDE'lerinde Git binary yolu ve SSH executable seçimi ayarlanabilir. Native veya built-in SSH client seçenekleri farklı config ve agent davranışı gösterebilir. Terminalde çalışan alias IDE'de çalışmıyorsa IDE'nin system OpenSSH kullanıp kullanmadığını kontrol edin. Git account integration ile repository network authentication aynı katman değildir. Ekip standardı belirlerken IDE ayarlarını da onboarding dokümantasyonuna eklemek faydalıdır.

IDE'nin System Git Kullanması

System Git kullanılması CLI ve IDE arasında config davranışını daha tutarlı hâle getirir. Conditional include, local config ve core.sshCommand aynı Git implementation tarafından değerlendirilir. Ancak environment variable değerleri GUI uygulaması tarafından terminalden farklı alınabilir. Özellikle SSH_AUTH_SOCK farkı agent problemlerine neden olabilir. IDE'yi terminalden başlatmak ile launcher üzerinden açmak farklı environment yaratıyorsa bunu test etmek gerekir.

Built-In SSH Client

Built-in SSH client bazı IDE'lerde OpenSSH config seçeneklerinin tamamını aynı şekilde desteklemeyebilir. Host alias veya agent forwarding davranışı farklı olabilir. Bu durumda IDE'yi native/system OpenSSH kullanacak şekilde değiştirmek çözüm olabilir. Kurumsal policy de hangi client'ın kullanılacağını belirleyebilir. Debug sırasında IDE log'larından hangi key ve host'un seçildiğini kontrol etmek gerekir.

IDE Authentication ile Git CLI Authentication Farkı

IDE marketplace, GitHub extension veya issue integration hesabı Git CLI push hesabından bağımsız olabilir. Kullanıcı work account ile Git push yaparken IDE extension personal account ile API isteği gönderebilir. Bu durum özellikle pull request oluşturma ekranlarında kafa karıştırır. Her entegrasyonun hangi credential store kullandığını ayrı düşünmek gerekir. Çoklu hesap troubleshooting sırasında “hangi işlem hangi protokolle yapılıyor?” sorusu doğru katmanı bulmayı kolaylaştırır.

VS Code'da Çoklu Kimlik Yönetimi

VS Code için en sağlam yaklaşım Git CLI config ve system SSH yapısını doğru kurmak, editor hesaplarını bunlardan ayrı değerlendirmektir. Personal ve work workspace'leri farklı profillerle açmak görsel ayrım sağlayabilir. Farklı renk teması veya profil adı kullanmak yanlış workspace'te işlem yapma riskini azaltır. Remote WSL ve Dev Container kullanıldığında config'in hangi ortamda bulunduğunu kontrol etmek gerekir. IDE görünümü destekleyici olmalı, gerçek kimlik kontrolü Git ve SSH config tarafından sağlanmalıdır.

Git CLI Config

VS Code Source Control çoğu durumda repository'nin normal Git config değerlerini kullanır. Bu nedenle includeIf, user.useConfigOnly ve local config ayarları editörden bağımsız çalışır. Integrated terminalde git config --show-origin user.email ile değer doğrulanabilir. Yanlış sonuç varsa IDE ayarını değil önce Git config'i düzeltmek gerekir. Source Control işlemleri de aynı repository context'inde doğru identity'yi kullanacaktır.

Profiles

VS Code Profiles personal ve work development ortamlarını görsel ve extension seviyesinde ayırmanıza yardımcı olabilir. Farklı GitHub extension account'ları veya settings grupları için faydalıdır. Ancak profile geçişi SSH key veya user.email'i otomatik değiştiren güvenlik mekanizması değildir. Gerçek identity conditional Git config ve remote URL tarafından seçilmelidir. Profile yalnızca kullanıcıya bağlam farkını daha görünür hâle getiren yardımcı katman olarak düşünülmelidir.

Work ve Personal Workspace

Work ve personal projeleri ayrı üst klasörlerde tutmak includeIf düzeniyle doğal biçimde birleşir. VS Code workspace dosyaları da bu klasörlere göre ayrı olabilir. Kullanıcı iş projesini personal workspace içine yanlışlıkla eklese bile repository path'i gerçek identity seçiminde belirleyici olur. Remote URL'nin doğru alias kullandığını ayrıca doğrulamak gerekir. Workspace açılışında terminal prompt'a current user.email göstermek ekstra görsel güvenlik sağlayabilir.

Visual Separation

Farklı tema, pencere başlığı veya profil ikonu personal ve work bağlamlarını görsel olarak ayırabilir. Bu kontrol teknik authentication yerine geçmez, ancak insan hatasını azaltır. Özellikle aynı isimli repository'lerin iki account'ta bulunduğu durumlarda faydalıdır. Work profile'da kurumsal extension ve settings, personal profile'da kişisel ayarlar tutulabilir. Yine de commit identity'nin git config ile doğrulandığından emin olun.

Remote SSH ve WSL

VS Code Remote SSH veya WSL kullanıldığında Git ve SSH işlemleri uzak veya WSL ortamında gerçekleşebilir. Yerel laptop'taki ~/.ssh/config her zaman remote environment tarafından kullanılmaz. Agent forwarding veya socket bridge varsa güvenlik sınırı genişler. Her ortamda which git, which ssh, git config ve SSH_AUTH_SOCK değerleri kontrol edilmelidir. Çoklu hesap düzenini hangi ortamın gerçekten komut çalıştırdığına göre kurmalısınız.

Docker ve Dev Container İçinde Git SSH Kimliği

Container içine private key kopyalamak geliştirici credential'ını image layer veya container filesystem içinde bırakma riski taşır. Bunun yerine gerektiğinde SSH agent socket forwarding veya BuildKit SSH mount gibi mekanizmalar tercih edilebilir. Dev Container kullanıcı deneyiminde host agent'ın kontrollü biçimde container'a aktarılması mümkündür. Ancak container artık agent'ı kullanabildiği için güven sınırını iyi değerlendirmek gerekir. Production image içinde geliştirici private key veya kalıcı credential bulunmamalıdır.

Private Key'i Container'a Kopyalamamak

Dockerfile içinde private key COPY etmek ciddi bir güvenlik hatasıdır. Key daha sonra layer silinse bile image history veya build cache içinde kalabilir. Repository clone işlemi için BuildKit SSH mount gibi geçici credential aktarımı kullanılabilir. Development container'da host agent socket'i paylaşılabilir. Secret'ın image artifact'e hiç girmemesi temel hedef olmalıdır.

SSH Agent Socket Forwarding

Host ssh-agent socket'i container içine mount edilirse container içindeki SSH istemcisi host agent key'lerini kullanabilir. Private key dosyasının container'a kopyalanmasına gerek kalmaz. Buna rağmen container içindeki process'ler agent socket'e erişebileceği için yalnızca güvendiğiniz development image'larında kullanmalısınız. SSH_AUTH_SOCK container içinde doğru mount path'e yönlendirilmelidir. Key seçimi yine SSH config veya explicit identity politikasına göre kontrol edilmelidir.

Dev Container

Dev Container workflow'unda Git komutlarının host'ta mı container içinde mi çalıştığını belirlemek önemlidir. Container içinde çalışıyorsa Git config ve SSH config'in nasıl sağlandığı planlanmalıdır. Personal ve work e-posta değerlerini image içine sabitlemek yerine host veya runtime config üzerinden geçirmek daha güvenlidir. Private key image'a kopyalanmamalıdır. Agent forwarding kullanılıyorsa container kaynak koduna ve extension'lara duyulan güven de değerlendirilmelidir.

BuildKit SSH Mount

Docker BuildKit SSH mount build sırasında geçici olarak SSH agent erişimi sağlayabilir. Private key build arg veya layer içine yazılmadan private dependency clone etmek için faydalıdır. Dockerfile içindeki ilgili RUN adımı dışında credential erişimi sınırlanabilir. Build server'da hangi agent veya deploy credential'ın kullanıldığı açıkça yönetilmelidir. Geliştirici personal key'ini production build pipeline'a bağlamak doğru değildir.

Container İçinde Credential Sızıntısını Önlemek

Environment variable, image layer, volume ve build log credential sızıntısı açısından gözden geçirilmelidir. Private key, passphrase veya token hiçbir zaman log'a yazılmamalıdır. Temporary mount'lar build adımı bittikten sonra erişilemez olmalıdır. Container image registry'ye gönderilmeden önce secret scanning yapılabilir. Geliştirici credential'ı ile CI service credential'ını tamamen ayrı tutmak en güçlü önlemlerden biridir.

Git Submodule'larda Çoklu Kimlik Problemi

Submodule kullanan repository'lerde ana repository doğru account ile çalışırken alt repository farklı remote URL nedeniyle authentication hatası verebilir. .gitmodules içindeki URL'ler hangi host alias'ın kullanılacağını belirler. Kişiye özel alias'ların shared repository dosyasına yazılması ekip uyumluluğunu bozabilir. URL rewrite bu noktada yerel kullanıcı bazında account routing sağlamak için alternatif olabilir. CI/CD'nin de submodule URL'lerini çözebilmesi gerektiği için tasarımı yalnız geliştirici laptop'ına göre yapmamak önemlidir.

Submodule Remote URL

Her submodule kendi Git repository'si olduğu için ayrı remote URL'ye sahiptir. Ana repository work alias kullanırken submodule standart github.com veya başka GitLab host'u kullanabilir. Authentication problemi yalnız submodule güncellemesinde ortaya çıkabilir. git submodule status ve .gitmodules içeriği ilk kontrol noktalarıdır. Yerel sync işleminden sonra gerçek submodule config'ini de doğrulamak gerekir.

.gitmodules

.gitmodules repository içinde versionlanan submodule tanımlarını içerir. Buraya yalnız sizin laptop'ınızda var olan personal SSH alias yazmak diğer geliştiriciler ve CI için sorun yaratabilir. Takım standardı alias kullanıyorsa bu kabul edilebilir, ancak herkes aynı config'e sahip olmalıdır. Alternatif olarak canonical URL tutulup kullanıcı tarafında url.insteadOf rewrite uygulanabilir. Security açısından submodule host'larının güvenilir olduğundan emin olunmalıdır.

Host Alias

Submodule URL'sinde host alias kullanmak hangi SSH key'in seçileceğini netleştirir. Aynı alias'ın tüm ekip ve CI environment'larında tanımlı olması gerekir. Personal alias'ın shared enterprise repository'ye gömülmesi uygun olmayabilir. Ekip bazlı work alias standardı kullanılabilir. Submodule update öncesinde SSH testini doğrudan alias üzerinde yapmak debug süresini azaltır.

URL Rewrite

URL rewrite canonical submodule URL'sini local kullanıcı için gerekli host alias'a dönüştürebilir. Böylece .gitmodules ortak ve taşınabilir kalırken personal/work routing yerel config'te yapılır. Rewrite kurallarını organization bazında dar tutmak önemlidir. CI tarafında kendi service credential yöntemi kullanılabilir. Developer rewrite'larını pipeline config'e kopyalamak yerine CI için ayrı authentication tasarlamak daha doğrudur.

CI/CD Uyumluluğu

Submodule'ların CI/CD içinde clone edilmesi geliştirici personal SSH key'ine bağlı olmamalıdır. Deploy key, machine user veya platform token gibi service credential kullanılmalıdır. .gitmodules URL'si pipeline ortamında erişilebilir olmalıdır. Private submodule için repository kapsamlı en düşük yetki tercih edilmelidir. Developer ve CI identity'lerini ayırmak güvenlik ve offboarding süreçlerini kolaylaştırır.

CI/CD'de Çoklu Git Kimliği

CI/CD sistemi insan geliştiriciden farklı bir kimlik sınıfı olarak ele alınmalıdır. Personal SSH key veya geliştirici token'ını pipeline secret olarak kullanmak erişim sahipliğini ve offboarding'i zorlaştırır. Deploy key, machine user veya service account gibi amaca özel credential tercih edilmelidir. Yetki mümkün olduğunca repository ve ihtiyaç duyulan operasyonla sınırlandırılmalıdır. Rotation, expiration ve audit kayıtları otomasyon credential'larının yaşam döngüsüne dahil edilmelidir.

Developer Personal Key Kullanmamak

Pipeline içinde developer personal key kullanıldığında iş akışı tek kişinin account durumuna bağımlı hâle gelir. Çalışan işten ayrıldığında build aniden bozulabilir. Anahtarın scope'u pipeline ihtiyacından daha geniş olabilir. Audit log'da makine işlemleri insan kullanıcı gibi görünür. Service identity kullanmak sahiplik ve revoke süreçlerini çok daha açık hâle getirir.

Deploy Key

Deploy key belirli bir repository'ye SSH erişimi vermek için kullanılabilir. Salt okunur gereksinim varsa write yetkisi açmamak en düşük yetki prensibine uyar. Her platformun deploy key kullanım kuralları farklı olabilir. Key CI secret store içinde güvenli biçimde tutulmalıdır. Rotasyon sırasında yeni key test edilip eski key kontrollü biçimde revoke edilmelidir.

Machine User

Machine user otomasyon amaçlı ayrılmış platform hesabıdır. Birden fazla repository erişimi gerektiğinde deploy key'e alternatif olabilir. Hesabın sahipliği bir bireye değil kuruma ait olmalıdır. MFA, token ve SSH key yönetimi platformun service account politikalarına göre yapılmalıdır. Gereksiz organization permission verilmemelidir.

Service Account

Service account makine işlemlerini insan geliştirici kimliğinden ayırır. CI, deployment veya repository synchronization gibi görevler için kullanılabilir. Hesabın permission kapsamı göreve göre sınırlandırılmalıdır. Credential rotation ve audit süreçleri otomatik veya düzenli takvimle yürütülmelidir. Kullanılmayan service account'lar aktif bırakılmamalıdır.

Read-Only Key

Pipeline yalnız dependency veya source checkout yapıyorsa write yetkisine ihtiyaç duymayabilir. Read-only deploy key saldırı durumunda değişiklik push edilmesi riskini azaltır. Permission her repository'nin gerçek ihtiyacına göre verilmelidir. Build ile release görevleri farklı credential kullanabilir. Böylece ayrıcalık seviyeleri pipeline stage'lerine göre bölünür.

Repository-Scoped Credential

Credential'ın yalnızca gerekli repository veya organization kapsamına sahip olması blast radius'u sınırlar. Global personal token veya tüm organization'a erişen SSH key yerine dar yetkili credential tercih edilmelidir. Pipeline sayısı arttıkça credential envanteri ve rotasyon otomasyonu önem kazanır. Secret owner ve son kullanım tarihi izlenebilir. Kurumsal güvenlik ekibi düzenli access review yaparak eski credential'ları kaldırmalıdır.

SSH Key Lifecycle Yönetimi

SSH key güvenliği anahtar üretildiği anda bitmez. Generation, registration, usage, rotation, revocation ve deletion aşamaları birlikte yönetilmelidir. Bir key'in hangi hesap, cihaz ve amaç için üretildiği bilinmelidir. Platformdaki public key kayıtları ile yerel private key envanteri zaman içinde senkron tutulmalıdır. Eski cihaz anahtarlarını süresiz aktif bırakmamak lifecycle yönetiminin en önemli kazanımlarındandır.

Key Generation

Generation aşamasında uygun algoritma, dosya adı, comment ve passphrase seçilir. Kurumsal policy varsa hardware-backed key gereksinimi uygulanabilir. Key doğrudan kullanılacağı cihazda üretilmelidir. Private key başka cihazdan kopyalanmamalıdır. Fingerprint ilk anda kayıt altına alınırsa sonraki lifecycle adımları kolaylaşır.

Registration

Public key doğru Git hosting account'una kaydedilir. Key title cihaz ve kullanım amacını açık biçimde göstermelidir. SSO authorization gerekiyorsa aynı aşamada tamamlanır. Authentication ve signing kullanım türleri doğru seçilmelidir. Kayıt sonrasında ssh -T ve fingerprint kontrolü yapılmalıdır.

Usage

Usage aşamasında key yalnızca tasarlandığı account ve cihaz bağlamında kullanılmalıdır. SSH host alias yanlış hesap kullanımını önler. Agent içinde gereksiz identity'ler açık bırakılmamalıdır. Workstation lock ve malware koruması açık key güvenliği için önemlidir. Audit log veya platform key last-used bilgisi destekleniyorsa düzenli review yapılabilir.

Rotation

Rotation eski credential'ı yenisiyle kontrollü biçimde değiştirme sürecidir. Önce yeni key oluşturulur ve public key kaydedilir. Local config yeni key'e yönlendirilir ve bağlantı testi yapılır. Yeni key çalıştığı doğrulandıktan sonra eski key revoke edilir. Böylece kesinti riskini azaltan güvenli bir geçiş sağlanır.

Revocation

Revocation platform hesabındaki public key kaydının erişimden kaldırılmasıdır. Cihaz kaybı, çalışan ayrılığı veya şüpheli erişim durumunda hızlı yapılmalıdır. Yerel private key silmek tek başına yeterli değildir çünkü kopyası başka yerde bulunabilir. Platform revoke işlemi server tarafında erişimi kapatır. Incident durumunda token ve session credential'ları da ayrıca değerlendirilmelidir.

Deletion

Key artık kullanılmıyorsa private key yerel sistemden kontrollü biçimde kaldırılabilir. Önce platform kaydının revoke edildiğinden emin olmak gerekir. Backup veya cloud sync içinde kopya bulunup bulunmadığı da değerlendirilmelidir. SSD ve modern filesystem'lerde güvenli silme tekniklerinin sınırları bulunduğu için disk şifreleme önemli koruma sağlar. En iyi politika gereksiz private key kopyaları oluşturmamaktır.

SSH Key Rotation Nasıl Yapılır?

SSH key rotation erişimi kesmeden eski key'i yenisiyle değiştirecek sıralı bir süreç olmalıdır. İlk olarak yeni key üretip passphrase ile koruyun. Public key'i hesabınıza ekleyin ve local SSH config'i yeni IdentityFile'a yönlendirin. Bağlantıyı ve repository erişimini test ettikten sonra eski key'i revoke edin. Sorun yaşanması hâlinde kısa süreli rollback için eski key'i revoke etmeden önce yeni key'in gerçekten çalıştığından emin olmak en önemli adımdır.

Yeni Key Oluşturmak

Yeni key eski dosyanın üzerine yazılmadan farklı filename ile oluşturulmalıdır. Böylece geçiş sırasında iki key aynı anda kontrollü biçimde test edilebilir. Algoritma ve passphrase kurum standardına göre seçilir. Cihaz bilgisini key adına veya comment'e eklemek envanteri kolaylaştırır. Yeni fingerprint kaydedilmelidir.

Yeni Public Key'i Hesaba Eklemek

Yeni private key yalnız cihazda kalırken .pub dosyası doğru platform hesabına eklenir. Key title yeni cihaz veya rotation tarihini belirtmelidir. Authentication ve signing rolleri ayrıysa doğru kullanım türü seçilir. SSO authorization gerekiyorsa tamamlanır. Eski key henüz kaldırılmadan yeni key test için hazır hâle gelir.

Local Config'i Güncellemek

~/.ssh/config içindeki IdentityFile yeni private key yoluna çevrilir. Alias isimlerini değiştirmek zorunda değilsiniz, böylece repository remote URL'leri aynı kalabilir. Agent eski key'i hâlâ tutuyorsa yeni key'i ayrıca ekleyin ve IdentitiesOnly davranışını doğrulayın. Effective config ssh -G ile kontrol edilmelidir. Signing key ayrı rotate ediliyorsa Git config de ayrıca güncellenir.

Connection Testi

Yeni key aktifken ssh -T doğru account'u göstermelidir. ssh -vT yeni fingerprint'in offer ve accepted olduğunu doğrulayabilir. Sonrasında gerçek repository üzerinde fetch veya izin verilen push testi yapılabilir. Enterprise SSO varsa organization erişimini ayrıca kontrol edin. Tüm testler tamamlanmadan eski key'i revoke etmek kesinti yaratabilir.

Eski Key'i Revoke Etmek

Yeni key doğrulandıktan sonra eski public key platform hesabından kaldırılmalıdır. Yalnız agent'dan silmek server erişimini iptal etmez. Aynı eski key başka hesaplarda kayıtlıysa tüm kullanım yerleri envanter üzerinden incelenmelidir. Eski private key dosyası artık gerekmediğinde yerelden kaldırılabilir. Audit kaydında rotation tarihi ve yeni fingerprint tutulması kurumsal takip için faydalıdır.

Rollback Planı

Rotation sırasında yeni key'in çalışmaması durumunda eski erişimin kısa süreli korunması rollback imkânı sağlar. Bu nedenle eski key'i yeni bağlantı testi tamamlanmadan revoke etmemek önemlidir. Kritik üretim erişimlerinde ikinci yönetici account veya break-glass mekanizması bulunabilir. Rollback planı eski key'i süresiz açık tutma bahanesine dönüşmemelidir. Başarılı migration sonrası eski credential hemen kaldırılmalıdır.

Bilgisayar Kaybolursa veya Çalınırsa Ne Yapılmalı?

Geliştirici bilgisayarı kaybolduğunda yalnız SSH key'i düşünmek yeterli değildir. Cihazdaki Git hosting sessions, personal access token, browser login ve kurumsal identity provider session'ları da risk altında olabilir. İlgili SSH public key'ler mümkün olan en kısa sürede revoke edilmelidir. Kurumsal MDM varsa cihaz remote lock veya wipe süreci çalıştırılabilir. Audit log kontrolü kayıp sonrası şüpheli repository erişimi olup olmadığını anlamaya yardımcı olur.

SSH Keys Revoke

Kayıp cihazda bulunan tüm SSH private key'lerin public karşılıkları platformlardan kaldırılmalıdır. Hesap ve cihaz başına ayrı key kullanmak bu işlemi çok daha kolaylaştırır. Aynı key'i başka cihazlarda da kullanıyorsanız revoke tüm cihazları etkiler. Bu da device-specific key modelinin önemli avantajını gösterir. Yeni cihaz için eski key'i geri yüklemek yerine yeni key üretmek daha güvenlidir.

Git Hosting Sessions Revoke

Tarayıcı veya desktop uygulamadaki aktif Git hosting session'ları kayıp cihaz üzerinde hâlâ geçerli olabilir. Platform hesabının security settings bölümünden ilgili sessions sonlandırılmalıdır. Tüm sessions revoke etmek gerekebilir. MFA cihazı da kayıpsa recovery süreci ayrıca başlatılmalıdır. SSH key revoke web session'ı otomatik olarak kapatmaz.

Access Token Revoke

Cihazda Git Credential Manager, CLI veya script'lerde access token bulunabilir. Kayıp cihazla ilişkilendirilen token'lar platformdan revoke edilmelidir. Token inventory ve expiration politikası incident response süresini kısaltır. CI token'ları geliştirici cihazından ayrı tutuluyorsa gereksiz service kesintisi yaşanmaz. Yeni token üretirken eski token'ın permission scope'u da gözden geçirilebilir.

Corporate Identity Provider Session Revoke

Kurumsal SSO session'ı Git hosting dışındaki birçok servise erişim sağlayabilir. Kayıp cihaz durumunda identity provider üzerinden session revoke veya password reset işlemi gerekebilir. Endpoint security ekibi cihaz sertifikalarını da iptal edebilir. Git erişimi kurum kimliğinin yalnızca bir parçasıdır. Olay müdahalesi merkezi kurumsal prosedür üzerinden yürütülmelidir.

Audit Log Kontrolü

Audit log cihaz kaybından sonra yetkisiz clone, key ekleme veya hesap değişikliği olup olmadığını incelemek için kullanılabilir. Son başarılı SSH key kullanım zamanı destekleniyorsa ilgili fingerprint ile karşılaştırılabilir. Şüpheli etkinlik varsa credential revoke kapsamı genişletilmelidir. Repository içeriği sızmış olabileceği için incident response yalnız account erişimiyle sınırlı kalmamalıdır. Kurum olay kayıtlarını gerekli süre boyunca saklamalıdır.

İşten Ayrılma ve Offboarding

Offboarding, çoklu Git kimlik yönetiminin planlı revoke senaryosudur. Çalışanın kurumsal SSH key'leri, signing key kayıtları, personal access token'ları ve organization membership'leri kaldırılmalıdır. Cihaz teslimi ve local corporate repository yönetimi de sürece dahil edilmelidir. Personal account'a yanlışlıkla kurumsal key eklenmişse bu erişim ayrıca kontrol edilmelidir. İyi tasarlanmış hesap ve cihaz bazlı identity modeli offboarding işlemini hızlı ve ölçülebilir hâle getirir.

Kurumsal SSH Key'leri Kaldırmak

Çalışanın work SSH public key'leri organization veya enterprise account'tan revoke edilmelidir. Shared team key kullanılıyorsa hangi kişinin erişiminin kaldırıldığı netleşmez, bu nedenle kullanıcı bazlı key modeli daha güvenlidir. Key inventory çalışan ve cihaz bilgisiyle tutulmalıdır. Offboarding tamamlandığında artık kullanılmayan key platformda görünmemelidir. Audit log üzerinden son erişim tarihi kontrol edilebilir.

Signing Key

Kurumsal signing key'in platform hesabındaki kaydı da offboarding kapsamında değerlendirilmelidir. Eski commitlerin signature verification'ı için public key kaydının kaldırılmasının platform davranışına etkisi göz önünde bulundurulmalıdır. Yeni commit üretme yetkisi artık olmamalıdır. Hardware key kuruma aitse fiziksel cihaz teslim alınmalıdır. Signing ve authentication key rolleri ayrı envanterde tutulursa bu süreç daha açık yürütülür.

Personal Access Token

Çalışana ait work personal access token'ları revoke edilmelidir. Token'ların CI pipeline'da kullanılması kötü bir tasarım olduğu için offboarding build sistemlerini etkilememelidir. Service automation ayrı service account credential kullanmalıdır. Token scope ve son kullanım zamanı audit için kontrol edilebilir. Kullanılmayan eski token'ları düzenli review etmek yalnız offboarding değil sürekli güvenlik açısından da önemlidir.

GitHub/GitLab Membership

Kullanıcı organization, group ve repository membership'lerinden çıkarılmalıdır. SSO veya SCIM kullanılıyorsa merkezi identity provider üzerinden otomatik deprovisioning uygulanabilir. Direct repository collaborator erişimleri ayrıca kontrol edilmelidir. Team membership kaldırmak her external collaboration erişimini otomatik kapatmayabilir. Offboarding checklist'i tüm erişim yollarını kapsamalıdır.

Device Credentials

Kurumsal cihaz sertifikaları, VPN credential'ları ve endpoint identity'leri Git SSH key'lerden ayrı olsa da aynı offboarding sürecinde ele alınmalıdır. Cihaz yeniden atanacaksa kullanıcı profile ve private key dosyaları temizlenmelidir. Full disk encryption key escrow süreçleri kurum politikasına göre yönetilir. Personal cihazda work credential bulunmasına izin veriliyorsa remote revoke özellikle önemlidir. Kurum mümkünse work credential'ları yönetilen cihazlarla sınırlandırmalıdır.

Local Corporate Repository'leri Yönetmek

Çalışanın cihazındaki corporate source code repository'leri işten ayrılma sonrasında kurum politikası kapsamında ele alınmalıdır. Kurumsal laptop teslim ediliyorsa cihaz wipe veya yeniden image işlemi yapılabilir. Personal cihaz kullanımı varsa kaynak kodun nasıl kaldırılacağı sözleşme ve güvenlik politikasıyla belirlenmelidir. SSH key revoke etmek mevcut local source code kopyasını silmez. Bu nedenle erişim kapatma ile veri yönetimi iki ayrı kontrol alanıdır.

SSH Key'leri Yeni Bilgisayara Taşımak Doğru mu?

Eski private key dosyasını yeni bilgisayara kopyalamak kısa vadede kolaydır, fakat cihaz bazlı revoke avantajını ortadan kaldırır. Yeni cihazda yeni SSH key üretmek daha temiz bir yaşam döngüsü sağlar. Platform hesabında her cihaz ayrı public key ile temsil edilir. Eski cihaz emekliye ayrıldığında yalnız eski key revoke edilir. Kurumsal ortamda yeni cihaz provisioning sürecine key üretimi ve registration adımını eklemek bu modeli sürdürülebilir hâle getirir.

Private Key Kopyalamanın Riski

Private key kopyalandıkça kaç yerde bulunduğunu takip etmek zorlaşır. Cloud drive, USB veya mesajlaşma aracı üzerinden transfer etmek credential sızıntısı riskini artırır. Aynı key iki cihazda kullanılırsa audit log yalnız fingerprint gösterdiğinde hangi cihazın eriştiğini ayırmak zorlaşabilir. Bir cihaz kaybolduğunda key revoke diğer cihazı da etkiler. Yeni key üretmek bu problemleri büyük ölçüde ortadan kaldırır.

Yeni Cihazda Yeni Key Oluşturmak

Yeni laptop ilk kurulumunda her gerekli account için yeni key üretilebilir. Key title içine cihaz adı eklenir ve public key doğru hesaplara kaydedilir. Conditional Git config ve SSH alias dotfiles üzerinden kurulabilir. Private key ise hiçbir zaman dotfiles repository'sinden gelmez. Eski cihaz kullanımdan kalktığında ona ait key'ler revoke edilir.

Device-Level Revocation Avantajı

Her cihaz farklı fingerprint kullandığında erişim iptalini fiziksel cihaz seviyesinde yapabilirsiniz. Laptop kaybolursa masaüstü bilgisayarın Git erişimi çalışmaya devam eder. Audit log'daki key fingerprint'i hangi cihazla ilişkilendirildiğini gösterebilir. Cihaz inventory ile key inventory birbirine bağlanabilir. Bu model incident response ve offboarding işlemlerini belirgin biçimde kolaylaştırır.

Kurumsal Best Practice

Kurumsal ortamda private key migration yerine her yönetilen cihazda yeni key üretmek güçlü bir standarttır. Hardware-backed key kullanılıyorsa cihaz veya security key provisioning ayrıca yönetilebilir. Key'lerin belirli aralıklarla rotasyonu ve eski cihaz key'lerinin hızlı revoke edilmesi süreçleştirilmelidir. Dotfiles yalnız config şablonlarını taşımalı, secret materyal taşımamalıdır. Bu yapı geliştirici onboarding'ini güvenliği zayıflatmadan otomatikleştirmeye yardımcı olur.

Dotfiles ile Git/SSH Config Yönetimi

Dotfiles repository'si Git ve SSH config şablonlarını yeni cihazlara taşımak için kullanışlıdır. Ancak private key, passphrase, token veya hassas müşteri bilgisi kesinlikle versionlanmamalıdır. .gitconfig ortak ayarları ve conditional include kurallarını içerebilir. .ssh/config için template kullanmak host alias standardını korur. Makineye özgü key path veya kurumsal e-posta gibi bilgiler private local dosyalara ayrılabilir.

.gitconfig Versionlamak

Global Git config'in güvenli bölümleri dotfiles repository'sinde tutulabilir. Alias'lar, diff ayarları, user.useConfigOnly ve includeIf kuralları buna örnektir. Personal e-posta veya şirket domain bilgisi public dotfiles'ta görünmesini istemediğiniz veri olabilir. Bu değerleri local untracked include dosyalarına taşımak daha güvenlidir. Repository'yi public yapmadan önce secret scanning ve manuel review yapmak gerekir.

.ssh/config Template

SSH config'in host alias yapısı template olarak versionlanabilir. IdentityFile path'leri standart dosya isimlerine dayanıyorsa yeni cihaz kurulumu kolaylaşır. Private key dosyalarının kendisi repository'de bulunmamalıdır. Müşteri hostname veya özel ağ bilgisi hassas kabul ediliyorsa public dotfiles'tan çıkarılmalıdır. Kurumsal template ayrı private configuration management sistemi üzerinden dağıtılabilir.

Private Key'i Asla Versionlamamak

Private SSH key Git repository'ye commit edilmemelidir. Repository private olsa bile erişim kapsamı ve backup sistemi secret saklama için uygun olmayabilir. Commit history'den sonradan silmek de her clone'daki kopyayı ortadan kaldırmaz. Yanlışlıkla commit edilen key derhal compromised kabul edilip revoke edilmelidir. Yeni key oluşturup eski credential'ı rotasyonla kaldırmak en güvenli yaklaşımdır.

E-posta ve Kurumsal Bilgi Gizliliği

Dotfiles kullanıcı kimliği ve çalıştığı kurum hakkında beklenenden fazla bilgi sızdırabilir. Git e-posta adresleri, internal hostname'ler ve müşteri adları public repository'de görünmemelidir. Public template içinde placeholder kullanabilirsiniz. Gerçek değerler private local config dosyasından include edilebilir. Bu ayrım config portability sağlarken kişisel ve kurumsal bilgileri korur.

Makineye Özgü Config

Bazı SSH ayarları yalnız belirli laptop veya işletim sistemi için geçerli olabilir. IdentityAgent path'i, Keychain entegrasyonu veya corporate proxy buna örnektir. Ana template'ten machine-local bir config dosyasını include etmek esnek çözüm sağlar. Bu dosya dotfiles repository'sinde tutulmayabilir. Yeni cihaz provisioning script'i gerekli local şablonu oluşturabilir.

Çoklu Hesap İçin Önerilen Production-Grade Yapı

Production-grade çoklu Git kimlik düzeninde amaç yalnızca “çalışıyor” demek değil, hatalı kimliği zorlaştırmak ve erişim yaşam döngüsünü yönetilebilir kılmaktır. Hesap ve cihaz başına ayrı SSH key, tüm private key'lerde passphrase, kontrollü ssh-agent, IdentitiesOnly yes, conditional Git config ve user.useConfigOnly güçlü bir temel oluşturur. Kurumsal depolarda SSH commit signing ve düzenli key rotation ek güvenlik sağlar. Developer, CI ve service account credential'ları birbirinden ayrılmalıdır. Çoklu Hesap İçin SSH Passphrase ve Git Kimlik Yönetimi bu bileşenler birlikte ele alındığında sürdürülebilir hâle gelir.

Hesap/Cihaz Başına Ayrı Key

Her account ve device kombinasyonu farklı SSH fingerprint kullanmalıdır. Bu model erişim sızıntısının etki alanını sınırlar. Cihaz kaybında yalnız o cihaz key'i revoke edilir. Hesap kapatıldığında başka account key'leri etkilenmez. Key title standardı envanteri kolaylaştırır.

Tüm Private Key'lerde Passphrase

Geliştirici cihazındaki uzun ömürlü private key'ler güçlü passphrase ile korunmalıdır. Password manager secret tekrarını önlemeye yardımcı olur. Günlük kullanım kolaylığı ssh-agent ile sağlanır. Passphrase shell script veya dotfiles içinde tutulmaz. Hardware-backed key kullanılan modellerde cihazın kendi PIN ve user presence mekanizmaları ayrıca uygulanabilir.

ssh-agent

ssh-agent private key passphrase korumasını kaldırmadan günlük Git kullanımını kolaylaştırır. Agent'a yalnız gerekli key'leri yüklemek daha iyi güvenlik sağlar. Agent lifetime hassas erişimlerde sınırlandırılabilir. Workstation lock ve endpoint güvenliği açık agent riskini azaltır. Birden fazla agent socket problemini önlemek için merkezi session agent tercih edilmelidir.

IdentitiesOnly

Her multi-account host alias bloğunda IdentitiesOnly yes kullanmak key seçimini daha belirgin hâle getirir. Agent içindeki ilgisiz identity'lerin sunulması önlenir. “Too many authentication failures” riski azalır. Yanlış account'un key'iyle başarılı authentication olma ihtimali de düşer. Effective config ssh -G ile düzenli olarak kontrol edilebilir.

Conditional Git Config

Personal, work ve client identity dosyaları conditional include ile otomatik seçilmelidir. Directory veya remote URL yöntemi ekip workflow'una göre tercih edilebilir. user.name, user.email ve signing key aynı profile dahil edilebilir. Global fallback identity kullanılmaması daha güvenlidir. Clone sonrası effective config kontrolü onboarding adımına eklenmelidir.

user.useConfigOnly

user.useConfigOnly=true explicit Git identity olmayan repository'de commit'i durdurur. Bu davranış yanlış fallback e-posta kullanımını engeller. Conditional include kuralı bozulduğunda hata hemen görünür. Kullanıcı doğru config'i tanımladıktan sonra commit devam eder. Çoklu hesap sisteminin en düşük maliyetli fakat etkili fail-safe kontrollerinden biridir.

SSH Commit Signing

Kurumsal veya hassas repository'lerde SSH signing commit authenticity için ek doğrulama sağlar. Work ve personal signing key'leri ayrı tutulabilir. Conditional config doğru signing key'i otomatik seçer. Platform public key'i signing kullanım türünde tanımalıdır. Verified commit politikası code review ve branch protection ile birlikte uygulanmalıdır.

Düzenli Key Rotation

SSH key'ler süresiz bırakılmak yerine risk ve kurum politikasına göre düzenli review edilmelidir. Rotation yeni key oluşturma, kayıt, test ve eski key revoke adımlarını içerir. Kullanılmayan cihaz key'leri takvim beklenmeden kaldırılmalıdır. Fingerprint ve key title kayıtları bu süreci kolaylaştırır. Otomatik hatırlatma ve erişim review sistemleri büyük ekiplerde faydalı olabilir.

Örnek Personal + Work Git Akışı

Pratik bir personal ve work workflow oluştururken işlemleri belirli bir sırada yapmak hataları azaltır. Önce iki ayrı SSH key oluşturulur, ardından public key'ler doğru platform hesaplarına eklenir. ssh-agent ve host alias config tamamlandıktan sonra authentication test edilir. Git identity dosyaları ve conditional include kuralları daha sonra eklenir. Son aşamada signing, clone ve commit öncesi doğrulama ile uçtan uca sistem kontrol edilir.

1. İki Ayrı SSH Key Oluştur

Personal ve work için iki farklı ED25519 key üretin. Dosya isimlerini id_ed25519_github_personal ve id_ed25519_github_work gibi açık seçin. Private key'leri aynı dosyanın üzerine yazmayın. Her key için fingerprint kaydedin. Cihaz değiştiğinde yeni key üretmeyi planlayın.

2. Her Key'e Passphrase Ekle

Anahtar oluşturma sırasında güçlü ve benzersiz passphrase kullanın. Aynı passphrase'i iki key'de tekrar kullanmamak izolasyonu artırır. Password manager bu bilgileri güvenli biçimde saklamaya yardımcı olabilir. Passphrase'i script içine yazmayın. Günlük kullanım kolaylığını agent ile çözün.

3. Public Key'leri Doğru Hesaba Kaydet

Personal .pub dosyasını personal account'a, work public key'i work account'a ekleyin. Private key dosyasını asla platforma yüklemeyin. Key title içine cihaz ve amaç bilgisi yazın. Fingerprint karşılaştırması yapın. SSO authorization gerekiyorsa tamamlayın.

4. ssh-agent'a Key'leri Ekle

İki private key'i ssh-add ile agent'a ekleyebilirsiniz. Passphrase ilk ekleme sırasında girilir. ssh-add -l ile iki fingerprint'i kontrol edin. Gereksiz eski key'leri agent'dan kaldırın. Agent yaşam süresini güvenlik politikanıza göre yönetin.

5. SSH Host Alias'larını Tanımla

github-personal ve github-work host bloklarını oluşturun. İkisinin HostName değeri github.com olabilir. Personal blok personal key'i, work blok work key'i göstermelidir. Her blokta IdentitiesOnly yes kullanın. Config sonucunu ssh -G ile doğrulayın.

6. Bağlantıları ssh -T ile Test Et

İki alias için ayrı ssh -T testi çalıştırın. Personal alias personal username, work alias work username göstermelidir. Yanlış sonuçta ssh -vT ile offered key'i kontrol edin. Public key kayıtlarını fingerprint üzerinden doğrulayın. İki test de doğru olmadan repository migration yapmayın.

7. Work/Personal Git Config Dosyalarını Oluştur

Personal ve work identity'leri ayrı Git config dosyalarına koyun. Her dosyada doğru user.name ve user.email bulunmalıdır. Signing kullanıyorsanız ilgili user.signingKey de eklenebilir. Global dosyada gerçek identity yerine include kuralları bulunabilir. Hassas değerleri public dotfiles repository'sine koymayın.

8. includeIf ile Otomatik Kimlik Seç

~/personal/ ve ~/work/ dizinlerini conditional include ile ilgili config dosyalarına bağlayın. İki dizinde örnek repository üzerinde user.email kontrolü yapın. Taşınabilirlik gerekiyorsa remote URL tabanlı koşulu değerlendirin. Kural eşleşmesini --show-origin ile doğrulayın. Dizin standardını ekip içinde belgeleyin.

9. user.useConfigOnly Aktif Et

Global config içinde user.useConfigOnly=true aktif edin. Identity bulunmayan test repository'sinde commit'in durduğunu kontrol edin. Doğru personal ve work dizinlerinde commit normal çalışmalıdır. Böylece config dışındaki repository'ler yanlış fallback identity kullanamaz. Bu kontrol yeni clone hatalarını erken yakalar.

10. Signing Key'leri Ayır

Personal ve work için ayrı signing key kullanmayı değerlendirin. Work config iş signing key'ini, personal config kişisel key'i göstermelidir. Platformda public signing key'leri doğru hesaplara kaydedin. Test commitlerin Verified durumunu kontrol edin. Kurum policy signed commit zorunluysa bu adımı onboarding'in zorunlu parçası hâline getirin.

11. Repository'leri Doğru Remote ile Clone Et

Personal repository'leri personal klasöre ve personal SSH alias ile clone edin. Work repository'leri work klasöre ve work alias ile clone edin. Böylece hem Git identity hem SSH authentication aynı bağlama yerleşir. Clone sonrası remote URL'yi kontrol edin. Existing repository'lerde git remote set-url ile migration yapabilirsiniz.

12. Commit ve Push Öncesi Kimliği Doğrula

İlk commit öncesinde git config user.email ve signing key kontrolü yapın. İlk push öncesinde remote URL ve SSH alias'ı doğrulayın. git show --format=fuller commit author bilgisini gösterebilir. Platformda commit attribution ve Verified durumunu kontrol edin. Bu kısa doğrulama yeni yapılandırmanın uçtan uca doğru çalıştığını gösterir.

Çoklu Hesap İçin Güvenlik Kontrol Listesi

Çoklu hesap sistemi bir kez kurulup unutulmamalıdır. Yeni cihaz, yeni müşteri, organization değişikliği veya key rotasyonu mevcut config'i etkileyebilir. Belirli aralıklarla SSH key, agent, Git identity ve signing durumunu kontrol etmek faydalıdır. Aşağıdaki sorular kendi ortamınız için hızlı güvenlik review noktaları sunar. Bir sorunun cevabı “hayır” ise önce risk seviyesini değerlendirin ve ardından ilgili yapılandırmayı düzeltin.

Her Hesabın Ayrı SSH Key'i Var mı?

Personal, work ve müşteri hesaplarının ayrı key kullanması erişim alanını sınırlar. Aynı key birden fazla hesapta kayıtlıysa revoke işlemi daha geniş etki yaratır. Platform key listelerini fingerprint üzerinden karşılaştırın. Cihaz bazlı ayrım gerekiyorsa her cihaz için de yeni key üretin. Shared user key kullanımından mümkün olduğunca kaçının.

Private Key'lerde Passphrase Var mı?

Geliştirici cihazındaki private key'ler passphrase ile korunmalıdır. Passphrase bulunmayan eski key'ler için yeni key üretip rotasyon yapmak değerlendirilebilir. Agent kullanımı günlük giriş yükünü azaltır. Passphrase secret'larını script veya plain text dosyada tutmayın. Hardware key kullanıyorsanız cihaz PIN ve user presence politikasını kontrol edin.

IdentitiesOnly Aktif mi?

Multi-account host alias bloklarında IdentitiesOnly yes olup olmadığını kontrol edin. Effective config için ssh -G alias kullanabilirsiniz. Agent içinde çok key varsa bu ayar özellikle önemlidir. Yanlış key'in önce sunulmasını önlemeye yardımcı olur. Yeni alias eklerken standard template kullanmak unutma riskini azaltır.

Agent'da Gereksiz Key Var mı?

ssh-add -l mevcut agent identity'lerini gösterir. Uzun süredir kullanılmayan client veya eski cihaz key'lerini agent'dan kaldırın. Agent'dan kaldırmak platform erişimini revoke etmez, bunu ayrıca yapmanız gerekir. Kritik key'ler için lifetime sınırı kullanmayı değerlendirin. Birden fazla agent varsa doğru socket'i kontrol edin.

Agent Forwarding Kapalı mı?

Forwarding gerçekten gerekmiyorsa varsayılan olarak kapalı tutulmalıdır. ssh -G host çıktısında forwardagent değerini kontrol edebilirsiniz. Host * altında yanlışlıkla açık bir ayar bulunmamalıdır. Gerekli bastion host'larda yalnız o block için açılabilir. Uzak host güvenliği forwarding kararının temel parçasıdır.

File Permission'ları Doğru mu?

~/.ssh dizini ve private key dosyalarının izinlerini kontrol edin. Unix sistemlerde private key'in diğer kullanıcılara açık olmaması gerekir. Windows'ta ACL yapısı uygun kullanıcıyla sınırlandırılmalıdır. Config dosyasının başka kullanıcılar tarafından değiştirilememesi önemlidir. Permission hataları yalnız güvenlik değil bağlantı sorunları da oluşturabilir.

Work ve Personal E-posta Ayrı mı?

Work repository'de corporate, personal repository'de kişisel veya noreply e-posta kullanıldığından emin olun. Global user.email bu ayrımı bozabilir. Conditional config ve --show-origin ile gerçek kaynağı kontrol edin. Public open source repository'de corporate adresin görünmediğini doğrulayın. Kimlik politikasını onboarding dokümantasyonuna ekleyin.

user.useConfigOnly Aktif mi?

user.useConfigOnly=true açık identity bulunmadığında commit'in durmasını sağlar. Global config'te değeri kontrol edin. Yeni ve identity'siz test repository'sinde davranışı doğrulayabilirsiniz. Bu ayar yanlış fallback commitlerini azaltır. Conditional include yapısıyla birlikte özellikle güçlüdür.

Commit Signing Kullanılıyor mu?

Kurumsal policy signed commit gerektiriyorsa commit.gpgsign ve signing key değerlerini kontrol edin. Platformdaki public signing key kaydı doğru hesaba ait olmalıdır. Test commit Verified görünmelidir. Personal ve work key ayrımı varsa conditional config'i doğrulayın. Signing key rotasyonunu authentication lifecycle'dan ayrı ama koordineli yürütün.

Eski SSH Key'ler Silindi mi?

Platform hesaplarında yıllardır kullanılmayan key'leri bırakmak gereksiz erişim yüzeyi oluşturur. Key title ve last-used bilgisi varsa review sırasında kullanın. Eski cihazlara ait public key'leri revoke edin. Private key'in local veya backup kopyalarını da değerlendirin. Belirsiz sahipliğe sahip key'i aktif bırakmak yerine yeniden registration yapmak daha güvenli olabilir.

Key Rotation Politikası Var mı?

Rotation yalnız incident sonrası yapılan acil işlem olmamalıdır. Kurum risk seviyesine göre periyodik review veya maksimum key age belirleyebilir. Yeni key test edilmeden eski key revoke edilmemelidir. Cihaz kaybı veya çalışan ayrılığında normal takvim beklenmeden revoke yapılmalıdır. Rotation süreci dokümante edildiğinde geliştiriciler erişim kesintisi yaşamadan daha güvenli geçiş yapabilir.

Sık Karşılaşılan Hatalar

Çoklu Git hesabı sorunları genellikle birkaç tekrar eden hata mesajı etrafında toplanır. “Permission denied”, “repository not found”, “too many authentication failures” ve yanlış e-posta problemleri farklı katmanlardan kaynaklanabilir. Hata mesajını gördüğünüz anda key'i silip yeniden üretmek çoğu zaman gereksizdir. Önce remote URL, effective SSH config, agent key listesi ve Git identity kaynağı kontrol edilmelidir. Sistematik teşhis hatayı daha hızlı çözer ve mevcut çalışan credential'ları bozmamanızı sağlar.

Permission denied (publickey)

Bu hata sunucunun sunduğunuz SSH key'lerden hiçbirini kabul etmediğini gösterir. Remote yanlış alias kullanıyor olabilir. IdentityFile bulunamayabilir veya public key hesapta kayıtlı olmayabilir. ssh -vT offered key listesini gösterir. File permission ve SSO authorization gibi ek kontroller de yapılmalıdır.

Too many authentication failures

Agent içindeki çok sayıda key sunucuya sırayla sunulduğunda deneme limiti dolabilir. Doğru key daha sonra gelse bile sunucu bağlantıyı keser. Host alias içinde IdentitiesOnly yes ve doğru IdentityFile kullanmak temel çözümdür. ssh-add -l gereksiz key sayısını gösterir. Debug çıktısından hangi key'lerin offer edildiğini kontrol edin.

Repository not found

Bu hata repository gerçekten yoksa veya authenticated account'un repository erişimi yoksa görülebilir. Yanlış SSH key ile farklı hesaba bağlanmak sık nedenlerden biridir. ssh -T dönen username'i kontrol edin. Remote URL'deki organization ve repository path'ini doğrulayın. Enterprise SSO veya membership durumunu da inceleyin.

Yanlış GitHub Hesabıyla Authentication

SSH bağlantısı başarılı olup yanlış username dönüyorsa key seçimi veya public key kaydı hatalıdır. ssh -G alias IdentityFile değerini kontrol edin. ssh -vT sunucunun hangi key'i kabul ettiğini gösterir. Aynı public key'in beklenmedik account'ta kayıtlı olup olmadığını inceleyin. Remote URL'nin doğru personal veya work alias kullandığından emin olun.

Yanlış user.email

Yanlış user.email SSH authentication probleminden bağımsızdır. git config --show-origin user.email değerin kaynağını gösterir. Global fallback yerine conditional config kullanın. Push edilmemiş commit varsa author'ı düzeltin. Gelecekte aynı hatayı önlemek için user.useConfigOnly=true etkinleştirin.

Commit Verified Görünmüyor

Commit signature doğru signing key ile oluşturulmamış olabilir. Platform public key'i signing amacıyla tanımıyor olabilir. user.signingKey ve gpg.format effective değerlerini kontrol edin. Local signature doğrulamasını yapın. Authentication key'in çalışması signing setup'ın doğru olduğu anlamına gelmez.

Passphrase Her Push'ta Tekrar Soruluyor

Anahtar agent'a eklenmemiş veya shell yanlış agent socket kullanıyor olabilir. ssh-add -l key'in açık olup olmadığını gösterir. macOS'ta Keychain entegrasyonu, Linux'ta session agent ve Windows'ta OpenSSH agent service kontrol edilebilir. Passphrase'i kaldırmak yerine agent problemini çözmek daha güvenlidir. Reboot sonrası key loading davranışını ayrıca yapılandırmanız gerekebilir.

ssh-agent Key'i Görmüyor

Yanlış SSH_AUTH_SOCK değerine bağlı olabilirsiniz. Birden fazla agent process çalışıyor olabilir. Key hiç eklenmemiş veya başka kullanıcı hesabının agent'ında olabilir. IDE ve terminal farklı environment kullanabilir. Socket, process ve ssh-add -l sonuçlarını aynı ortamda kontrol edin.

includeIf Çalışmıyor

Directory path yanlış yazılmış veya trailing slash beklendiği gibi kullanılmamış olabilir. Repository düşündüğünüz dizin altında olmayabilir. Git sürümü kullandığınız conditional feature'ı desteklemeyebilir. git config --show-origin user.email include dosyasının yüklenip yüklenmediğini gösterir. Path'i gerçek pwd ve repository gitdir değeriyle karşılaştırın.

Remote Alias Yanlış

Remote URL standart github.com kullanıyorsa personal/work host alias config'i hiç devreye girmeyebilir. git remote -v gerçek URL'yi kontrol eder. Gerekirse git remote set-url ile doğru alias'a geçin. Alias'ın ssh -T testi doğru account'u göstermelidir. URL rewrite kullanıyorsanız onun da beklenen dönüşümü yaptığını kontrol edin.

Permission Denied (Publickey) Nasıl Çözülür?

Permission denied (publickey) hatasını çözmenin en hızlı yolu katmanları belirli sırayla kontrol etmektir. Önce Git remote URL'sine bakın ve doğru host alias kullanılıp kullanılmadığını doğrulayın. Sonra ssh -vT ile hangi key'in offer edildiğini inceleyin. Effective config, public key platform kaydı ve dosya izinlerini karşılaştırın. Bu yöntem key'i rastgele yeniden oluşturmaktan daha güvenli ve daha öğreticidir.

Remote URL'yi Kontrol Et

git remote -v repository'nin hangi SSH host'una bağlandığını gösterir. Work repository standart github.com kullanıyorsa work alias config'i uygulanmayabilir. URL'de yazım hatası veya yanlış organization path'i de olabilir. Fetch ve push URL'lerini ayrı kontrol edin. Submodule varsa onların remote'larını da unutmayın.

Host Alias'ı Kontrol Et

SSH config içinde remote URL'deki alias için gerçekten bir Host bloğu bulunmalıdır. Alias adının birebir eşleştiğini kontrol edin. HostName doğru gerçek sunucuya gitmelidir. Work ve personal bloklarının IdentityFile değerleri farklı olmalıdır. ssh -G alias effective sonucu hızlıca gösterir.

ssh -vT Çalıştır

Verbose test hangi key'lerin offer edildiğini ve server'ın hangi aşamada bağlantıyı reddettiğini gösterir. “Offering public key” satırlarını inceleyin. Beklenen fingerprint hiç görünmüyorsa IdentityFile veya agent problemi vardır. Server key'i kabul edip sonra authorization hatası veriyorsa repository veya account izni ayrı incelenmelidir. Debug çıktısındaki hassas bilgileri paylaşmadan önce temizleyin.

IdentityFile'ı Kontrol Et

IdentityFile path doğru olmalı ve private key dosyası gerçekten mevcut olmalıdır. Dosya adı yanlış veya eski key'e işaret ediyor olabilir. Effective config bunu doğrulamaya yardımcı olur. Public key fingerprint'i platformdaki kayıtla karşılaştırın. Rotation sonrası config'in eski key'de kalması sık karşılaşılan bir problemdir.

IdentitiesOnly'yi Kontrol Et

Host bloğunda IdentitiesOnly yes bulunduğundan emin olun. Agent içindeki farklı key'ler aksi durumda authentication denemelerine katılabilir. Çok sayıda key “too many authentication failures” hatasına da yol açabilir. Effective config bu option'ın gerçekten aktif olup olmadığını gösterir. Wildcard Host bloklarının değerini override edip etmediğini kontrol edin.

Public Key'in Doğru Hesapta Olduğunu Kontrol Et

Yerel private key'e karşılık gelen public key doğru platform account'una kayıtlı olmalıdır. Fingerprint üzerinden karşılaştırma yapmak en güvenilir yöntemdir. Work key personal hesapta kayıtlıysa yanlış username ile authentication gerçekleşebilir veya erişim reddedilebilir. Eski key revoke edilmiş olabilir. SSO organization authorization gerekiyorsa key'in bu yetkiye sahip olduğunu da kontrol edin.

File Permission'ları Kontrol Et

Private key dosyasının izinleri çok genişse OpenSSH anahtarı kullanmayı reddedebilir. Unix sistemlerde owner ve mode değerlerini kontrol edin. ~/.ssh dizini ve config dosyası da uygun izinlere sahip olmalıdır. Windows'ta ACL kontrolü yapılmalıdır. Permission düzeltirken dosyayı herkes tarafından okunabilir hâle getirmek yerine minimum gerekli erişimi koruyun.

Yanlış SSH Key Kullanıldığını Nasıl Anlarız?

Yanlış SSH key şüphesinde agent listesini, effective config'i ve gerçek bağlantı debug çıktısını birlikte incelemek gerekir. ssh-add -l hangi identity'lerin agent'da bulunduğunu gösterir. ssh -G hedef alias'ın hangi IdentityFile değerlerini aldığını açıklar. ssh -vT ise hangi public key'in gerçekten offer ve accepted edildiğini gösterir. Authentication sonrası dönen username bu üç bilginin doğru account'a bağlanıp bağlanmadığını doğrular.

ssh-add -l

Agent'daki fingerprint listesini görmek ilk hızlı kontroldür. Beklenen work key yoksa önce onu eklemeniz gerekebilir. Çok sayıda eski key varsa gereksiz olanları kaldırabilirsiniz. Fingerprint'i local .pub dosyasıyla eşleştirin. Agent listesi tek başına hangi key'in kullanılacağını söylemez, bu nedenle config ve debug kontrolü de gereklidir.

ssh -G

ssh -G alias hedef alias için effective IdentityFile ve diğer SSH option'larını gösterir. Work alias altında personal key görünmesi config problemidir. Genel Host blokları ek identity oluşturabilir. IdentityAgent değeri doğru agent socket'e işaret etmelidir. Bağlantı kurmadan config sorununu tespit etmenin hızlı yoludur.

ssh -vT

Verbose bağlantı testi gerçek authentication akışını gösterir. Hangi key'in offer edildiğini ve server'ın hangisini kabul ettiğini fingerprint üzerinden takip edebilirsiniz. Yanlış key kabul edilirse platform kullanıcı adı da beklenenden farklı çıkar. Config doğru görünse bile agent veya başka option davranışı burada ortaya çıkar. Sorun çözüldükten sonra sade ssh -T testi yeterlidir.

Authentication Sonrası Dönen Username

Git hosting platformunun bağlantı sonrası verdiği username, hangi account'un key'iyle authenticated olduğunuzu gösterir. Personal alias personal account dönmelidir. Work alias personal account döndürüyorsa bağlantı teknik olarak başarılı olsa bile multi-account config yanlıştır. Bu kontrolü rotation ve yeni cihaz kurulumundan sonra uygulamak faydalıdır. Repository erişimini test etmeden önce identity doğrulaması yapılmalıdır.

Agent'daki Key'leri Temizlemek

Debug sırasında ssh-add -D ile agent'ı tamamen temizlemek kontrollü test ortamı oluşturabilir. Ardından yalnız hedef key'i ekleyerek tekrar bağlantı deneyebilirsiniz. Sorun ortadan kalkarsa agent key sırası veya gereksiz identity'ler etkili olmuş olabilir. Kalıcı çözüm olarak IdentitiesOnly yes kullanılmalıdır. Temizleme işleminin yalnız agent state'ini etkilediğini, platform key kayıtlarını silmediğini unutmayın.

Yanlış Git Identity Kullanıldığını Nasıl Anlarız?

Git identity problemini SSH debug komutlarıyla çözmeye çalışmak gereksizdir çünkü commit kimliği Git config'ten gelir. Önce repository içinde effective user.name ve user.email değerlerini kontrol edin. --show-origin hangi config dosyasının değeri sağladığını gösterir. Son commit'in author ve committer alanlarını inceleyerek hatanın gerçekten commit'e yansıyıp yansımadığını anlayabilirsiniz. Conditional include kullanıyorsanız repository path veya remote koşulunun eşleştiğini ayrıca doğrulayın.

git config user.name

Bu komut mevcut repository'nin kullanacağı name değerini gösterir. Beklenen work veya personal isim formatıyla eşleşmelidir. Değer yanlışsa kaynağını --show-origin ile bulun. Global, local veya conditional config override'ı olabilir. Commit oluşturmadan düzeltmek history rewrite ihtiyacını önler.

git config user.email

Mevcut repository için effective e-posta değerini doğrudan gösterir. Work repository'de corporate adres, personal repository'de kişisel veya noreply adres beklenebilir. Boş değer user.useConfigOnly ile commit'in durmasına neden olabilir. Bu durum yanlış identity'den daha güvenlidir. Yeni clone sonrası bu kontrol birkaç saniyelik faydalı bir adımdır.

git config --show-origin user.email

Bu komut e-posta değerinin hangi dosyadan geldiğini açıkça gösterir. Global identity'nin local dosyayı gölgelemesi veya includeIf'in çalışmaması burada hemen fark edilir. Dosya yolunu gördükten sonra yalnız doğru kaynağı düzeltin. Çoklu config dosyalarını rastgele değiştirmek yeni çakışmalar yaratabilir. Work ve personal repository'lerde ayrı test ederek kuralları doğrulayın.

Son Commit Author'ını Kontrol Etmek

git log -1 --format=fuller veya benzer format son commit'in author ve committer bilgisini gösterir. Config'i düzeltmiş olmanız eski commit'in metadata'sını değiştirmez. Yanlış son commit push edilmediyse amend ile düzeltilebilir. Signed commit ise yeniden imzalama gerekir. Push edilmiş history için rewrite riskini ayrıca değerlendirin.

Conditional Include Eşleşmesini Kontrol Etmek

Repository'nin gerçek path'i includeIf kuralıyla eşleşiyor mu kontrol edin. git rev-parse --show-toplevel ve config origin bilgisi yardımcı olabilir. Remote URL tabanlı koşul kullanıyorsanız remote değerini doğrulayın. Git sürümünün özelliği desteklediğinden emin olun. Kural bozulduğunda user.useConfigOnly commit'i durduruyorsa sistem beklenen fail-safe davranışı gösteriyor demektir.

Sık Yapılan Çoklu Hesap Yönetimi Hataları

Çoklu hesap yapılandırmalarında tekrar eden hatalar genellikle kolaylık adına izolasyondan vazgeçmekten kaynaklanır. Tek key'i her yerde kullanmak, passphrase kaldırmak veya tek global e-posta tanımlamak ilk gün işleri hızlandırabilir. Zamanla account sayısı, cihazlar ve müşteri erişimleri arttığında bu kararlar hata ve güvenlik maliyetine dönüşür. Agent, IDE ve signing gibi katmanların birbirinden farklı olduğunu anlamak da önemlidir. Aşağıdaki hatalar production-grade bir kimlik modelinde özellikle kaçınılması gereken davranışlardır.

Tüm Hesaplar İçin Tek SSH Key Kullanmak

Tek SSH key bütün hesaplara erişebiliyorsa key compromise geniş etki yaratır. Hesap veya cihaz bazlı revoke işlemi yapılamaz. Platform policy aynı key'in birden fazla account'ta kullanımını sınırlayabilir. Ayrı key dosyaları host alias ile kolayca yönetilebilir. Anahtar sayısını azaltmak yerine yönetim standardını iyileştirmek daha güvenli çözümdür.

Passphrase Kullanmamak

Passphrase olmayan private key dosyası ele geçirildiğinde doğrudan kullanılabilir. Kullanım kolaylığı gerekçesiyle passphrase'i kaldırmak yerine ssh-agent kullanılmalıdır. Disk şifreleme ek koruma sağlasa da key seviyesinde passphrase hâlâ değerlidir. Otomasyon credential'ları için farklı service key modeli kullanılabilir. Geliştirici uzun ömürlü key'lerinde passphrase iyi bir güvenlik standardıdır.

Tüm Hesaplar İçin Global user.email Kullanmak

Tek global e-posta work ve personal commitlerin karışmasına neden olur. Hata çoğu zaman commit başarılı olduğu için geç fark edilir. Conditional config kimliği directory veya remote'a göre otomatik seçebilir. Global fallback identity'yi kaldırıp user.useConfigOnly kullanmak daha güvenlidir. Public repository'de corporate e-posta sızıntısı bu hatanın en görünür sonuçlarından biridir.

IdentitiesOnly Eklememek

Agent'da birden fazla key olduğunda SSH ilgisiz identity'leri de sunabilir. Yanlış account authentication veya “too many authentication failures” ortaya çıkabilir. IdentityFile tek başına her durumda yeterli sınırlama olmayabilir. IdentitiesOnly yes host alias tasarımını daha deterministik yapar. Effective config ile gerçekten aktif olduğunu kontrol edin.

Agent'a Kontrolsüz Çok Fazla Key Eklemek

Yıllar içinde tüm eski key'leri agent'a eklemek debugging ve güvenlik sorunları yaratır. Yalnız aktif çalışmada gerekli identity'leri tutmak daha iyidir. ssh-add -l düzenli review için kullanılabilir. Eski key'i agent'dan kaldırmak platformda revoke etmekle aynı değildir. İki yaşam döngüsü adımı ayrı yönetilmelidir.

Private Key'i Cloud Drive'a Kopyalamak

Cloud drive senkronizasyonu private key'in farkında olmadan başka cihazlara veya backup sistemlerine çoğalmasına neden olabilir. Sharing ayarı yanlışsa credential daha geniş kitleye açılabilir. Yeni cihazda yeni key üretmek daha güvenlidir. Dotfiles repository'si de private key taşımamalıdır. Private key sayısını minimumda tutmak envanter ve revoke yönetimini kolaylaştırır.

Work Private Key'i Kişisel Cihaza Taşımak

Kurum kişisel cihaz kullanımına izin vermiyorsa work key'in personal laptop'a kopyalanması policy ihlalidir. İzin verilse bile cihaz security posture kurumsal standarda uygun olmalıdır. Better model her yetkili cihazda ayrı work key üretmektir. Shared private key kopyalanmamalıdır. Kurumsal hesap ve cihaz ilişkisi inventory içinde görünür tutulmalıdır.

Commit Signing ile Authentication'ı Karıştırmak

Push'ın çalışması commit'in signed olduğu anlamına gelmez. Verified commit görünmemesi de SSH authentication key'in bozuk olduğunu göstermez. İki mekanizma farklı config ve platform kayıtları kullanır. ssh -T authentication, user.signingKey ve signature doğrulaması signing tarafını test eder. Sorunu doğru katmanda debug etmek zaman kazandırır.

IDE'nin Farklı SSH Client Kullandığını Fark Etmemek

Terminalde çalışan repository IDE'de çalışmıyorsa farklı SSH implementation veya agent kullanılabilir. Built-in client system config'i aynı biçimde okumayabilir. IDE Git binary ve SSH seçeneklerini kontrol edin. GUI uygulamasının environment variable değerleri terminalden farklı olabilir. Toolchain'i standardlaştırmak bu sorunları azaltır.

Eski Key'leri Revoke Etmemek

Eski laptop veya proje key'lerini platform hesabında süresiz tutmak gereksiz erişim yüzeyi oluşturur. Key title ve fingerprint envanteri düzenli review yapılmasını kolaylaştırır. Kullanılmayan key'leri revoke edin. Cihaz değişiminde eski key kaldırma adımını provisioning checklist'e ekleyin. Incident beklemeden erişim hijyenini korumak daha güvenlidir.

Sık Sorulan Sorular

Çoklu Git kimlik yönetiminde aynı sorular farklı ekiplerde tekrar tekrar karşımıza çıkar. Bunun nedeni SSH authentication, Git commit identity, signing ve web oturumunun kullanıcı açısından tek “hesap” gibi görünmesidir. Teknik olarak bu katmanlar birbirinden farklıdır ve her biri farklı araçlarla kontrol edilir. Aşağıdaki yanıtlar günlük kullanımda en sık ihtiyaç duyulan kararları kısa ve uygulanabilir biçimde özetler. Daha kapsamlı bir kurulumda önce ortamınızdaki işletim sistemi, Git sürümü, hosting platformu ve kurum politikalarını doğrulamanız gerekir.

Aynı bilgisayarda iki GitHub hesabı nasıl kullanılır?

Her hesap için ayrı SSH key oluşturun ve GitHub hesaplarına ilgili public key'i ekleyin. ~/.ssh/config içinde github-personal ve github-work gibi iki host alias tanımlayın. Her alias farklı IdentityFile ve IdentitiesOnly yes kullanmalıdır. Repository remote URL'sinde doğru alias'ı seçin. Commit e-postalarını da includeIf ile personal ve work config dosyalarına ayırın.

Her GitHub hesabı için ayrı SSH key gerekli mi?

Teknik olarak her durumda zorunlu olduğu söylenemez, ancak çoklu account ve güvenlik yönetimi için ayrı key güçlü bir pratiktir. Ayrı key revoke, audit ve cihaz bazlı erişim yönetimini kolaylaştırır. Aynı private key'in birçok hesapta kullanılması compromise etki alanını büyütür. Kurumsal policy ayrıca ayrı key zorunluluğu getirebilir. Hesap ve cihaz başına ayrı key modeli çoğu profesyonel ortamda daha yönetilebilirdir.

Aynı SSH key iki GitHub hesabında kullanılabilir mi?

Platformun güncel kayıt politikası aynı public key'in birden fazla hesapta kullanılmasını sınırlayabilir. Bunun mümkün olduğu başka sistemlerde bile güvenlik ve account izolasyonu açısından önerilen yaklaşım ayrı key kullanmaktır. Ayrı key hangi hesabın authentication yaptığını daha açık hâle getirir. Bir hesabın erişimini kaldırmak diğer hesabı etkilemez. Çoklu hesap sistemini key tekrarına değil, explicit routing'e dayandırmak daha sağlıklıdır.

SSH passphrase nedir?

SSH passphrase private key dosyasını yerelde şifreleyen secret değerdir. GitHub veya GitLab hesap parolası değildir. Passphrase platforma gönderilmez. Anahtar kullanılırken local sistemde kilidin açılması için gerekir. ssh-agent kullanıldığında her push işleminde tekrar girmeniz gerekmez.

SSH passphrase'i her push'ta girmek gerekir mi?

Hayır, doğru yapılandırılmış ssh-agent veya işletim sistemi keychain mekanizması passphrase tekrarını azaltabilir. Key bir kez agent'a açıldığında agent oturumu boyunca kullanılabilir. Güvenlik gereksinimine göre agent lifetime sınırlanabilir. Passphrase'i kaldırmak yerine agent kullanmak daha güvenlidir. Reboot sonrası davranış macOS, Linux ve Windows ortamına göre farklılık gösterebilir.

ssh-agent nedir?

ssh-agent açık private key'leri belirli bir kullanıcı oturumunda kullanılabilir tutan süreçtir. Private key dosyasını platforma yüklemez. Git ve SSH işlemleri gerekli kriptografik işlemi agent üzerinden yapabilir. Böylece passphrase sürekli tekrar edilmez. Agent socket güvenliği ve açık key süresi ayrıca yönetilmelidir.

IdentitiesOnly yes ne işe yarar?

IdentitiesOnly yes SSH'ın hedef host için açıkça tanımlanan identity'leri kullanmasına yardımcı olur. Agent içindeki tüm key'lerin sırayla sunulmasını sınırlar. Çoklu hesaplarda yanlış key'in önce kullanılmasını önler. “Too many authentication failures” riskini azaltabilir. Host alias ve IdentityFile ile birlikte kullanılması en etkili modeldir.

Git neden yanlış SSH key'i kullanıyor?

Remote URL yanlış host alias kullanıyor olabilir. ssh-agent'da birden fazla key bulunabilir ve IdentitiesOnly aktif olmayabilir. SSH config'te wildcard Host blokları beklenmedik IdentityFile ekliyor olabilir. ssh -G ve ssh -vT gerçek key seçim sürecini gösterir. Agent fingerprint listesini ssh-add -l ile kontrol etmek de faydalıdır.

Git neden yanlış e-posta ile commit atıyor?

Commit e-postası SSH hesabından değil Git config'ten gelir. Global user.email yanlış repository'de devreye giriyor olabilir. git config --show-origin user.email kaynağı gösterir. Conditional include ile personal ve work e-postaları ayrılabilir. user.useConfigOnly=true tanımsız identity'de commit'i durdurur.

Git account otomatik nasıl değiştirilir?

Tek bir “Git account switch” düğmesi yerine kimlik katmanlarını otomatik yönlendirmek daha doğrudur. SSH account host alias ile, commit identity includeIf ile, signing key conditional config ile seçilebilir. GitHub CLI hesabı gerekiyorsa gh auth switch ayrıca kullanılabilir. Directory veya remote URL tabanlı kurallar manuel hesap değiştirme ihtiyacını azaltır. Böylece repository bağlamı doğru kimliği kendisi seçer.

Git includeIf nedir?

includeIf belirli koşul gerçekleştiğinde başka Git config dosyasını yükleyen mekanizmadır. Personal ve work kimliklerini farklı dosyalara bölmek için kullanılabilir. gitdir: repository konumuna göre eşleşir. Desteklenen Git sürümlerinde remote URL tabanlı koşullar da kullanılabilir. Effective config'i --show-origin ile doğrulamak gerekir.

gitdir ile hasconfig arasındaki fark nedir?

gitdir repository'nin filesystem konumuna göre conditional config seçer. hasconfig:remote.*.url ise remote URL desenine göre seçim yapabilir. Repository taşındığında gitdir eşleşmesi değişebilir, remote tabanlı yöntem aynı kalabilir. Remote tabanlı özellik daha yeni Git sürümü gerektirebilir. Klasör disiplini güçlü ekiplerde gitdir, organization bazlı routing gereken ortamlarda remote yöntemi avantajlıdır.

core.sshCommand ne işe yarar?

core.sshCommand Git'in belirli config scope'unda hangi SSH komutunu çalıştıracağını belirler. Repository bazında -i ile özel private key seçebilirsiniz. IdentitiesOnly=yes eklemek agent key karışıklığını azaltır. Host alias kullanmadan repo-specific authentication sağlar. Çok sayıda repository'de tekrar gerektirdiği için merkezi multi-account yapıda host alias daha pratik olabilir.

GIT_SSH_COMMAND ne işe yarar?

GIT_SSH_COMMAND environment variable tek Git işlemi veya shell scope'u için SSH command override sağlar. Clone sırasında belirli key kullanmak için faydalıdır. Kalıcı config oluşturmaz. Passphrase'i environment variable içine yazmamak gerekir. Günlük kullanımda host alias veya core.sshCommand daha sürdürülebilir olabilir.

GitHub ve GitLab aynı SSH key ile kullanılabilir mi?

Teknik olarak public key birden fazla hizmete kaydedilebilir, ancak ayrı platform veya account key'leri daha iyi izolasyon sağlar. Bir platformdaki erişimi revoke ederken diğerini etkilemezsiniz. Fingerprint ve key title envanteri daha açıklayıcı olur. Kurumsal policy ayrı key gerektirebilir. Key sayısını yönetmek için tutarlı filename ve host alias standardı kullanabilirsiniz.

Git commit SSH key ile imzalanabilir mi?

Evet, desteklenen Git sürümlerinde SSH formatında commit signing kullanılabilir. gpg.format=ssh, user.signingKey ve isteğe bağlı commit.gpgsign=true yapılandırılır. Public signing key platform hesabına uygun kullanım türünde eklenir. Authentication key ile aynı key kullanılabilir, fakat rolleri ayrı düşünmek gerekir. Personal ve work signing key'leri conditional config ile otomatik seçilebilir.

Authentication key ile signing key aynı olabilir mi?

Teknik olarak desteklenen sistemlerde aynı SSH key iki amaç için kullanılabilir. Ancak authentication network erişimini, signing commit authenticity'yi temsil eder. Ayrı key kullanmak revoke ve audit işlemlerini daha esnek hâle getirir. Platformda aynı public key'in signing amacıyla ayrıca kaydı gerekebilir. Kurumsal policy hangi modelin kullanılacağını belirlemelidir.

GitHub CLI birden fazla hesap destekler mi?

Modern GitHub CLI sürümleri aynı host için birden fazla hesapla authentication ve hesaplar arasında switch işlemlerini destekleyebilir. gh auth status mevcut account durumunu gösterir. gh auth switch aktif account'u değiştirmeye yardımcı olur. Bu işlem SSH host alias'ınızı veya Git commit identity'nizi değiştirmez. CLI, SSH ve web kimliklerini ayrı kontrol etmelisiniz.

SSH mi HTTPS mi çoklu hesap için daha uygundur?

İki yöntem de doğru yapılandırıldığında kullanılabilir. SSH host alias ve ayrı key'lerle güçlü account routing sağlar. HTTPS Git Credential Manager ve token/OAuth akışlarıyla kurumsal SSO açısından avantajlı olabilir. Ağ politikası, CI modeli ve geliştirici araçları seçimde belirleyicidir. Commit identity her iki durumda da Git config üzerinden ayrı yönetilir.

Windows'ta birden fazla GitHub hesabı nasıl yönetilir?

Her account için ayrı SSH key üretip Windows OpenSSH config içinde farklı host alias tanımlayabilirsiniz. OpenSSH Authentication Agent service key'lerin kullanımını kolaylaştırır. Git for Windows'un hangi SSH binary'yi kullandığını kontrol etmek önemlidir. Her alias farklı IdentityFile ve IdentitiesOnly yes kullanmalıdır. Git commit e-postaları conditional config ile ayrıca ayrılmalıdır.

WSL'de SSH agent nasıl yönetilir?

WSL içinde ayrı ssh-agent kullanabilir veya Windows agent'ı uygun bir bridge aracılığıyla WSL'ye aktarabilirsiniz. İki yaklaşımı aynı anda kontrolsüz kullanmak farklı key listeleri oluşturabilir. SSH_AUTH_SOCK ve ssh-add -l aktif agent'ı gösterir. VS Code Remote WSL de WSL ortamındaki agent'ı kullanabilir. Hangi model seçilirse seçilsin tek ve belgelenmiş yaklaşım debug süresini azaltır.

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

Önce remote URL ve host alias'ı kontrol edin. Ardından ssh -vT ile hangi public key'in offer edildiğini inceleyin. IdentityFile, IdentitiesOnly, agent key listesi ve file permission değerlerini doğrulayın. Public key'in doğru Git hosting account'una kayıtlı olduğundan emin olun. Enterprise veya organization SSO gerekiyorsa key authorization durumunu da kontrol edin.

Çoklu Git hesabı için SSH anahtarları ve passphrase yönetimi nasıl yapılır?

Her hesap ve tercihen her cihaz için ayrı SSH anahtarı oluşturmak güçlü bir başlangıçtır. Private key'leri passphrase ile koruyun ve kullanım kolaylığını ssh-agent, macOS Keychain veya işletim sistemine uygun agent servisiyle sağlayın. Anahtar dosyalarını platform ve kullanım amacını belli edecek biçimde isimlendirin. SSH host alias, IdentityFile ve IdentitiesOnly yes kombinasyonu hangi hesabın hangi anahtarı kullanacağını açık biçimde belirler. Böylece Çoklu Hesap İçin SSH Passphrase ve Git Kimlik Yönetimi manuel key değiştirmek yerine öngörülebilir kurallarla çalışır.

GitHub veya GitLab’da birden fazla hesap için farklı SSH anahtarları nasıl yapılandırılır?

Personal ve work hesaplar için ayrı key üretin, ardından her public key'i yalnız ilgili GitHub veya GitLab hesabına kaydedin. ~/.ssh/config içinde her account için ayrı Host alias oluşturun ve gerçek HostName değerini platform hostname'ine yönlendirin. Her alias'a farklı IdentityFile ve IdentitiesOnly yes ekleyin. Repository clone ve remote URL'lerinde gerçek hostname yerine doğru alias'ı kullanın. Son olarak ssh -T ile her alias'ın beklenen username'i döndürdüğünü doğrulayın.

SSH config dosyası kullanılarak kişisel ve kurumsal Git hesapları nasıl ayrıştırılır?

SSH config içindeki personal ve work host alias'lar aynı gerçek Git sunucusuna yönlenebilir, fakat farklı private key kullanır. Örneğin github-personal kişisel key'e, github-work kurumsal key'e bağlanır. Remote URL hangi alias'ı içeriyorsa network authentication o kimlikle yapılır. Git commit e-posta ve signing key ayrımı için ayrıca conditional Git config uygulanmalıdır. Bu sayede kişisel ve kurumsal identity aynı cihazda bulunur, fakat birbirlerinin credential'ına bağımlı olmaz.

Git kullanıcı adı e-posta bilgileri ve SSH kimlikleri proje bazında nasıl yönetilir?

SSH identity'yi remote URL ve host alias üzerinden, Git user.name ve user.email değerlerini ise local veya conditional config üzerinden yönetebilirsiniz. Work ve personal projeleri ayrı klasörlerde tutuyorsanız includeIf gitdir oldukça pratiktir. Repository klasörden bağımsız identity seçsin istiyorsanız desteklenen Git sürümlerinde remote URL tabanlı conditional config değerlendirilebilir. user.useConfigOnly=true tanımsız kimlikle commit oluşturulmasını engeller. Signing kullanıyorsanız user.signingKey değerini de aynı personal veya work profile içine koyabilirsiniz.

Çoklu Git hesabı SSH anahtarı ve kimlik yönetimi konusunda yakınımda danışmanlık veya eğitim nerede bulabilirim?

Git SSH ve DevOps danışmanlığı yakınımda şeklinde çözüm ararken yalnız SSH key oluşturmayı değil, geliştirici kimliği, commit signing, CI/CD credential'ları, rotation ve offboarding süreçlerini birlikte ele alan bir çalışma tercih etmek daha faydalıdır. Diyarbakır Yazılım Topluluğu tarafından paylaşılan teknik içeriklere ve topluluk çalışmalarına https://www.diyarbakiryazilim.com.tr/about üzerinden ulaşabilirsiniz. Uygulamalı proje çalışmalarını görmek için https://www.diyarbakiryazilim.com.tr/projects adresini inceleyebilirsiniz. Git süreçlerinde merge ve pull request yönetimi üzerine ek içerik için https://www.diyarbakiryazilim.com.tr/posts/gitlab-ve-github-uzerinde-merge-pull-request-yonetimi sayfası da yararlı bir devam kaynağıdır. Kurumsal Git SSH anahtar ve geliştirici kimlik yönetimi hizmeti değerlendirirken kendi repository yapınız, işletim sistemleriniz ve erişim politikalarınız üzerinden örnek senaryo hazırlanması daha kalıcı sonuç verir.

Sonuç: Güvenli ve Hatasız Çoklu Git Kimlik Yönetimi Nasıl Kurulur?

Çoklu hesap yönetimini tek bir SSH key seçme problemi olarak görmek eksik kalır. Sağlam bir yapı authentication identity, commit identity, signing identity ve platform session identity katmanlarını ayrı yönetir. Çoklu Hesap İçin SSH Passphrase ve Git Kimlik Yönetimi doğru kurulduğunda geliştiricinin her işlem öncesinde “şu an hangi hesap aktif?” diye düşünmesine gerek kalmaz. Sistem repository'nin konumu, remote URL ve açık config kuralları üzerinden doğru kimliği otomatik seçer. Güvenliği artırırken günlük kullanım sürtünmesini azaltmak için passphrase, ssh-agent, host alias, conditional config ve signing mekanizmalarını birlikte düşünmek gerekir.

Authentication, Commit ve Signing Kimliklerini Ayrı Düşünün

SSH authentication uzak sunucunun sizi hangi hesap olarak tanıdığını belirler. Git commit identity author ve committer metadata'sını belirler. Signing identity commit'in hangi key ile imzalandığını gösterir. Web ve CLI session'ları da ayrı account state taşır. Problemi doğru katmana ayırmak troubleshooting süresini ciddi biçimde azaltır.

Her Hesap ve Cihaz İçin Ayrı SSH Key Kullanmayı Değerlendirin

Ayrı key kullanmak revoke ve audit işlemlerini kolaylaştırır. Cihaz kaybolduğunda yalnız o cihaza ait key kaldırılabilir. Account kapatıldığında diğer kimlikler etkilenmez. Naming ve fingerprint standardı anahtar sayısı artsa bile yönetimi kolaylaştırır. Kurumsal risk seviyesi yüksekse hardware-backed key seçeneğini de değerlendirebilirsiniz.

Private Key'leri Passphrase ile Koruyun

Passphrase private key dosyasının ele geçirilmesi durumunda ek güvenlik katmanı sağlar. Passphrase'i platforma göndermeniz veya hesabınıza kaydetmeniz gerekmez. Güçlü ve benzersiz değerleri password manager ile saklayabilirsiniz. Script ve dotfiles içinde düz metin kullanmaktan kaçının. Kullanım kolaylığını passphrase'i kaldırarak değil agent mekanizmasıyla sağlayın.

Passphrase Kullanılabilirliğini ssh-agent ile Çözün

ssh-agent key'i bir kez açtıktan sonra belirli süre boyunca yeniden passphrase istemeden kullanılmasına yardımcı olur. macOS Keychain, Linux session agent ve Windows OpenSSH agent service işletim sistemine özel seçenekler sunar. Agent'da gereksiz key bırakmamak önemlidir. Workstation lock ve agent lifetime güvenlik politikasına dahil edilmelidir. Agent forwarding yalnız gerçekten ihtiyaç olan güvenilir host'larda kullanılmalıdır.

IdentitiesOnly ile SSH Key Seçimini Deterministik Hale Getirin

IdentitiesOnly yes agent'daki ilgisiz key'lerin SSH authentication denemesine katılmasını sınırlar. Personal ve work host alias'ları explicit IdentityFile kullanmalıdır. Böylece yanlış key'in önce sunulması veya fazla authentication denemesi problemi azalır. ssh -G ve ssh -vT davranışı doğrulamak için kullanılabilir. Doğru account'u ssh -T çıktısındaki username üzerinden kontrol edin.

includeIf ile Git Kimliğini Otomatikleştirin

Personal, work ve client Git identity'lerini farklı config dosyalarına ayırın. Directory veya remote URL tabanlı conditional include doğru repository'de doğru user.email değerini otomatik yükler. Signing key aynı profile dahil edilebilir. Böylece global tek identity kullanımından kaynaklanan yanlış commit riski azalır. Config kaynağını düzenli olarak git config --show-origin ile doğrulayın.

user.useConfigOnly ile Yanlış Kimlikle Commit'i Fail-Closed Hale Getirin

user.useConfigOnly=true açık user.name veya user.email bulunmadığında commit'i durdurur. Git'in sistem bilgisine göre tahmini identity üretmesini engeller. Conditional include bozulduğunda kullanıcı hatayı commit anında görür. Bu davranış yanlış e-posta içeren commit'i sonradan history rewrite ile düzeltme ihtiyacını azaltır. Güvenli multi-account sistemlerinde küçük fakat çok etkili bir kontroldür.

Kurumsal Repository'lerde Commit Signing Kullanın

Commit signing author metadata'sına ek kriptografik doğrulama sağlar. SSH signing kullanıyorsanız work signing key'i personal key'den ayırabilirsiniz. Platformda public signing key doğru hesaba kaydedilmelidir. Branch protection ve CI kontrolleri signing politikasını desteklemelidir. Authentication key ve signing key aynı algoritmayı kullansa bile iki farklı güvenlik rolünü temsil ettiğini unutmayın.

Key Rotation ve Revocation'ı Yaşam Döngüsünün Parçası Yapın

Key güvenliği yalnız oluşturma aşamasından ibaret değildir. Registration, usage, rotation, revocation ve deletion süreçlerinin tamamı yönetilmelidir. Yeni cihaz için yeni key oluşturmak device-level revoke avantajı sağlar. Çalışan ayrılığı veya cihaz kaybında erişimler beklemeden kaldırılmalıdır. Düzenli key review eski ve kullanılmayan credential'ların platformda unutulmasını önler.

Çoklu Hesap Yönetimini Manuel Hesap Değiştirme Değil Kimlik İzolasyonu Problemi Olarak Ele Alın

En iyi çoklu Git hesabı düzeni geliştiricinin sürekli manuel switch komutu çalıştırmasını gerektirmez. Repository'nin remote'u SSH identity'yi, conditional config commit identity'yi ve signing profile imzalama key'ini otomatik seçer. Yanlış veya eksik kimlik durumunda sistem sessizce devam etmek yerine hata üretir. Bu yaklaşım hem kişisel projelerde hem ekip ve müşteri çalışmalarında daha güvenli, anlaşılır ve ölçeklenebilir bir çalışma düzeni sağlar. Git, SSH ve DevOps süreçlerinizi bu model üzerinden geliştirmek veya toplulukla birlikte ilerlemek için https://www.diyarbakiryazilim.com.tr adresini ziyaret edebilirsiniz.