SSH Anahtar Yönetimi ve Yetki Paylaşımı: Küçük Ekipler İçin Güvenli VPS Erişimi

Küçük Ekiplerde SSH Erişimini Neden Ciddiye Almalıyız?

Küçük bir ekibiniz, birkaç VPS sunucunuz ve üretimde çalışan projeleriniz varsa, SSH erişimini yönetmek çoğu zaman “sonra bakarız” kategorisine düşer. Ortak bir root şifresi belirlenir, ekiptekilere gönderilir, işler bir süre sorunsuz gider… Ta ki bir çalışan ayrılana, bir freelancer ile yollar ayrılana veya sunuculardan birine izinsiz bir giriş denemesi raporlanana kadar.

DCHost tarafında gördüğümüz en yaygın risklerden biri, parola tabanlı, paylaşımlı ve izlenmesi zor SSH erişimi. Özellikle 3–10 kişilik ekiplerde “zaten az kişiyiz” rahatlığı, güvenlik olayları yaşandığında ciddi baş ağrısına dönüşebiliyor. Oysa doğru kurgulanmış bir SSH anahtar yönetimi ve yetki paylaşımı mimarisi ile:

• Her geliştiricinin bireysel, izlenebilir bir hesabı olur.
• Ortak root şifresi kullanma ihtiyacı ortadan kalkar.
• Birinin ekibe katılması veya ekipten ayrılması dakikalar içinde yönetilir.
• Üretim, staging ve test ortamlarının yetkileri net bir şekilde ayrılır.

Bu yazıda, küçük ekipler için pratik ve gerçekçi bir güvenli VPS erişim mimarisi nasıl kurulur, SSH anahtarları nasıl yönetilir, yetkiler nasıl paylaşılır ve döndürülür; tüm bunları DCHost altyapısında kullanabileceğiniz somut örneklerle adım adım ele alacağız.

SSH Anahtar Tabanlı Erişimin Temelleri

Önce temel kavramları netleştirelim. SSH anahtar tabanlı kimlik doğrulama, parola ile girişe göre hem daha güvenli hem de ekip yönetimine çok daha uygun bir yöntemdir.

SSH anahtar çifti nedir?

SSH anahtar sistemi iki parçadan oluşur:

• Özel anahtar (private key): Sadece sizde bulunur, kimseyle paylaşılmaz. Giriş yaparken sizin kim olduğunuzu ispatlar.
• Açık anahtar (public key): Sunucuya kopyalanır. Sunucu, elindeki açık anahtar ile sizdeki özel anahtarın eşleşip eşleşmediğini kontrol eder.

Böylece sunucuya bağlanırken parola girmezsiniz; özel anahtarınız, arka planda kimliğinizi doğrular. Özel anahtarınız ele geçirilmedikçe ve sunucudaki açık anahtarlar kontrol altında oldukça, brute-force parola denemeleri büyük ölçüde anlamsız hale gelir.

Neden paroladan daha güvenli?

• Parola tahmin edilmeye veya kaba kuvvetle kırılmaya çalışılabilir; güçlü bir anahtar çifti ise pratikte kırılamaz.
• SSH üzerinde parola girişini tamamen kapatarak, botların otomatik denemelerini boşa çıkarabilirsiniz.
• Her geliştiricinin kendi anahtarı olduğu için, bir anahtarı iptal etmek diğerlerini etkilemez.

Genel VPS güvenliği tarafında daha kapsamlı bir fotoğraf görmek isterseniz, VPS sunucu güvenliği için pratik, ölçeklenebilir ve doğrulanabilir yaklaşımlar yazımıza da mutlaka göz atın.

Hangi anahtar türünü kullanmalı?

Güncel öneriler şunlar:

• ed25519: Güncel, güvenli ve kısadır; çoğu senaryoda ilk tercih.
• rsa (en az 3072 bit): Eski sistemlerle uyumluluk gerekiyorsa kullanılabilir.

Örneğin yerel bilgisayarınızda şu komutla bir ed25519 anahtar çifti oluşturabilirsiniz:

ssh-keygen -t ed25519 -C "[email protected]"

Buradaki -C etiketi, anahtarınızı etiketlemenizi sağlar; ileride anahtarları ayırt etmek için çok işe yarar.

Küçük Ekipler İçin Örnek VPS Erişim Mimarisi

Teori güzel ama asıl soru şu: 3–10 kişilik bir ekipte, bir veya birkaç VPS üzerinde erişimi nasıl bölmeli ve yönetmeliyiz? DCHost müşterilerinde sıkça uyguladığımız örnek bir mimariyi adım adım anlatalım.

1. Ortak root şifresini tamamen hayatınızdan çıkarın

İlk kural: Root hesabıyla direkt SSH erişimi yasak. Bunun yerine:

• Her ekip üyesi için ayrı bir Linux kullanıcısı açın (ör: ahmet, ayse).
• Bu kullanıcıları bir sudo grubuna ekleyin (ör: deploy veya sudo).
• Root yetkisi gerektiğinde sudo ile komut bazlı yükseliş kullanılsın.

Bu modelde kim ne yaptı, hangi kullanıcıdan hangi komutlar çalıştı; hepsini loglardan izlemek çok daha kolaydır. Yeni bir VPS kurarken bu yapıların atlanmaması için, Yeni VPS’te ilk 24 saatte yapılması gereken güncelleme, güvenlik duvarı ve kullanıcı hesapları rehberimiz iyi bir kontrol listesi sunuyor.

2. Roller ve ortamlara göre erişim seviyeleri

Küçük ekiplerde bile şu ayrımı koymak kritik:

• Üretim (production) sunucuları
• Staging / test sunucuları
• Geliştirme / kişisel ortamlar

Önerdiğimiz minimum politika:

• Her geliştiricinin staging/test sunucularına tam SSH erişimi olabilir.
• Üretim sunucularına erişim, sadece gerçekten ihtiyaç duyan çekirdek ekiple sınırlı olmalıdır.
• Freelancer veya dönemsel çalışanlar için sadece ilgili sunucuya ve sadece gerektiği süre boyunca erişim verin.

Bu ayrımı Linux grupları ve AllowGroups / AllowUsers direktifleriyle teknik olarak da netleştirebilirsiniz; birazdan sshd yapılandırmasında buna geri döneceğiz.

3. Tek giriş noktası (bastion) kullanmak mantıklı mı?

Birkaç VPS’iniz varsa, hepsine doğrudan internetten SSH açmak yerine, küçük bir ekipte bile şu modeli düşünebilirsiniz:

• Dış dünyaya açık tek bir bastion (jump) sunucusu olsun.
• Ekip üyeleri önce bu bastion’a SSH ile bağlansın.
• Sonrasında bastion üzerinden içteki diğer VPS’lere erişsin.

Böylece:

• Giriş log’larınız tek bir yerde toplanır.
• İnternete açık SSH portu sayısını azaltırsınız.
• IP kısıtlama, 2FA veya FIDO2 gibi ek katmanları sadece bastion üzerinde uygularsınız.

Daha ileri seviye senaryolarda, bastion üzerinde FIDO2 anahtarları ve SSH sertifika otoritesi kullanmaya kadar giden mimariler de var; bu konuyu detaylı işlediğimiz VPS’te SSH güvenliğini FIDO2 anahtarları ve SSH CA ile sağlamlaştırma yazısına göz atabilirsiniz.

SSH Anahtar Üretimi, Saklama ve Ekipte Standartlaştırma

Şimdi işin operasyonel tarafına bakalım: Ekip çapında tutarlı ve güvenli bir SSH anahtar politikası nasıl belirlenir?

1. Anahtar tipi ve uzunluğu için ekip standardı belirleyin

Tavsiye ettiğimiz basit ve uygulanabilir standart:

• Tüm ekip için ed25519 anahtarları varsayılan olsun.
• Çok eski istemciler veya donanımlar dışında RSA’ya ihtiyaç kalmasın.
• Etiket formatını standartlaştırın: Örneğin [email protected] veya ad-soyad-cihaz.

Böylece sunucudaki authorized_keys dosyasına baktığınızda, “Bu anahtar kimindi?” sorusunu dakikalarca düşünmek zorunda kalmazsınız.

2. Özel anahtarlar mutlaka parola ile korunmalı

SSH anahtarı oluştururken, istemci sizden bir parola (passphrase) isteyecektir. Bu parolayı boş bırakmak, pratikte o anahtarı korumasız hale getirmek demektir. Küçük bir ekstra adım ama şu avantajları sağlar:

• Dizüstü bilgisayarınız çalınsa bile, tek başına anahtar dosyası iş görmez.
• SSH agent kullanarak, oturum başına sadece bir kez parola girmeniz yeterli olur.

Ekip politikanıza “SSH özel anahtarları parolasız oluşturulmaz” maddesini açıkça yazmanızı öneririz.

3. Anahtarların saklanması ve yedeklenmesi

Özel anahtarlar:

• Sadece kullanıcının cihazında tutulmalı, e-posta ile çevreye saçılmamalı.
• Mümkünse güvenli bir parola kasası (password manager) veya şifreli disk üzerinde saklanmalı.
• Yedeklenirken de mutlaka şifreli biçimde yedeklenmeli.

Sunucu tarafındaki açık anahtarların yedeği ise, altyapı konfigürasyonunuzun parçası halinde (örneğin Ansible repo’ları içinde) tutulabilir; çünkü açık anahtarlar zaten halka açıktır.

Yetki Paylaşımı: authorized_keys, Ortak Kullanıcılar ve Deploy Süreçleri

Bir ekip üyesinin anahtarını nasıl paylaşacağı, hangi kullanıcıya ekleyeceği ve hangi yetkilerle çalışacağı kritik bir konudur. Burada hem güvenliği hem de operasyonel kolaylığı dengede tutmak gerekiyor.

1. Herkese ayrı kullanıcı hesabı açmak

En temiz ve şeffaf yöntem şudur:

• Her geliştirici için sunucuda ayrı bir kullanıcı (ör: ahmet, ayse) oluşturun.
• İlgili kullanıcının ~/.ssh/authorized_keys dosyasına sadece o kişiye ait açık anahtarları ekleyin.
• Root yetkisi gerekiyorsa kullanıcıyı sudo grubuna alın ve sudo log’larını düzenli inceleyin.

Böylece birisi ekipten ayrıldığında, sadece kendi kullanıcısını veya anahtarını silmeniz yeterli olur; başkalarını etkilemez.

2. Ortak kullanıcı (ör: deploy) kullanıyorsanız

Gerçek hayatta, özellikle CI/CD veya otomatik dağıtımlar için deploy gibi ortak kullanıcılar da ihtiyaç oluyor. Bu durumda dikkat etmeniz gerekenler:

• deploy kullanıcısının authorized_keys dosyasındaki her satır etiketli ve kime ait olduğu belli olmalı.
• Gerekirse command= gibi kısıtlayıcı SSH seçenekleri ile belirli anahtarlara sadece belirli komutları çalıştırma izni verilebilir (ör: sadece deploy script’i).
• Ortak kullanıcıya manuel login yerine, mümkün olduğunca otomatik süreçler (CI/CD) üzerinden erişim verin.

Örneğin Git tabanlı dağıtım yapıyorsanız, VPS üzerinde Git ile otomatik deploy kurulumu rehberimizdeki yöntemleri, bu deploy kullanıcısıyla birleştirerek güvenli ve tekrarlanabilir bir dağıtım hattı kurabilirsiniz.

3. Yetki paylaşımında “asgari yetki” prensibi

Hangi ekip üyesi, hangi sunucuda ne kadar yetkiye sahip olmalı? Basit bir çerçeve:

• Stajyer veya junior geliştirici: Test/staging üzerinde tam yetki, üretim üzerinde yalnızca log okuma veya hiç erişim.
• Senior geliştirici: İlgili projelerin staging ve üretim ortamlarında sudo yetkisi.
• DevOps/Sistem yöneticisi: Tüm VPS’lerde geniş yetki, ancak yine kişisel kullanıcı hesabı üzerinden.

Bu mantığı, sadece SSH değil, panel ve DNS erişimlerinde de uygulamak için ajanslar için hosting paneli erişim yönetimi rehberinde paylaştığımız prensiplerden de faydalanabilirsiniz.

sshd_config ile Erişimi Sertleştirmek

Anahtar yönetimini düzgün kurmak kadar, SSH sunucusunun yapılandırmasını da sertleştirmek gerekiyor. Aşağıdaki ayarlar, küçük ekipler için hem güvenli hem de uygulanabilir bir temel sunar.

1. Parola ile girişi kapatın

/etc/ssh/sshd_config dosyasında:

• PasswordAuthentication no
• ChallengeResponseAuthentication no

Bu ayarla SSH üzerinden parola ile giriş tamamen kapanır, sadece anahtar tabanlı girişe izin verilir. Bu değişikliği yapmadan önce en az bir kullanıcı için anahtar girişinin çalıştığından mutlaka emin olun.

2. Root ile direkt girişi kapatın

Aynı dosyada aşağıdakini ayarlayın:

• PermitRootLogin no

Böylece hiç kimse doğrudan root olarak SSH bağlantısı kuramaz; önce kendi kullanıcısıyla giriş yapar, sonra gerektiğinde sudo ile yetki yükseltir.

3. Sadece belirli kullanıcı ve gruplara izin verin

Küçük ekipler için çok işe yarayan başka bir yöntem de AllowUsers ve AllowGroups direktifleridir:

• AllowUsers ahmet ayse deploy
• veya
• AllowGroups devops developers

Böylece yanlışlıkla oluşturulmuş kullanıcılar veya sistem hesapları üzerinden SSH erişimi tamamen engellenmiş olur.

4. Güvenlik duvarı ve rate limit

SSH portunu (genellikle 22) doğrudan tüm dünyaya açmak yerine:

• Gerekliyse portu değiştirin (ör: 2222) – bu tek başına güvenlik çözümü değildir ama gürültüyü azaltır.
• Güvenlik duvarıyla (ufw, firewalld, iptables) SSH’a sadece belirli IP’lerden izin verin.
• Fail2ban gibi araçlarla brute-force denemelerini otomatik engelleyin.

Bu konuyu daha teknik olarak ele aldığımız VPS sunucularda güvenlik duvarı yapılandırma rehberi, SSH portunu da kapsayan detaylı örnekler sunuyor.

Anahtar Rotasyonu, Ekipten Ayrılanlar ve Denetim

İyi bir SSH mimarisi, sadece ilk kurulumda değil; değişim anlarında da sizi yormamalı. Özellikle biri ekibe katıldığında veya ekipten ayrıldığında atılacak adımlar net olmalı.

1. Yeni biri ekibe katıldığında

Adımları standartlaştırmak işleri çok kolaylaştırır:

1. Geliştirici kendi cihazında ekip standardına uygun bir SSH anahtar çifti üretir.
2. Açık anahtarını size iletir (mümkünse güvenli bir kanal veya ticket sistemi üzerinden).
3. İlgili VPS’lerde onun için kullanıcı oluşturulur ve authorized_keys dosyasına anahtar eklenir.
4. Gerekli gruplara (developers, sudo vb.) dahil edilir.
5. Erişim verdiğiniz sunucular ve yetki seviyesi bir dokümana işlenir.

Bunu bir “onboarding checklist” haline getirirseniz, ileride kimde hangi yetki var sorusunun cevabını dokümantasyondan hızlıca görebilirsiniz.

2. Biri ekipten ayrıldığında

Burada hız ve netlik çok önemli. Önerilen adımlar:

• İlgili kullanıcının tüm VPS’lerdeki hesaplarını anında kilitleyin veya silin.
• Ortak kullanıcıların (deploy vb.) authorized_keys dosyasından o kişiye ait satırları kaldırın.
• Gerekiyorsa root ve kritik hesaplarda kullanılan ortak anahtarları döndürün (yeniden oluşturup dağıtın).
• Sunucu loglarından son dönem aktivitelerini kısaca gözden geçirin.

Bu süreçleri düzgün işletmek, sadece güvenlik için değil; KVKK ve benzeri regülasyonlarda erişim yönetimi konusunda sorumluluklarınızı yerine getirmeniz açısından da önemli.

3. Anahtarların periyodik rotasyonu

Özel bir olay olmasa bile, kritik hesaplarda kullanılan anahtarların belirli aralıklarla yenilenmesi iyi bir pratiktir. Örneğin:

• Üretim sunucularına erişen anahtarlar için yılda bir rotasyon.
• CI/CD sistemlerinin kullandığı deploy anahtarları için 1–2 yılda bir rotasyon.

Yeni anahtarı devreye alırken eskisini bir süre daha paralel tutup, sorunsuz çalıştığından emin olduktan sonra eskisini kaldırmak, kesinti riskini azaltır.

4. Loglama ve denetlenebilirlik

İyi bir SSH mimarisinin görünmeyen ama kritik kısmı loglamadır. Öneriler:

• SSH log’larının merkezi bir yere (örneğin rsyslog veya merkezi log sunucusu) akmasını sağlayın.
• LogLevel VERBOSE ile kim hangi anahtarla bağlanmış görebilirsiniz.
• Önemli VPS’ler için başarısız giriş denemelerine alarm kurun.

Birden fazla sunucuda log yönetimini sistematik hale getirmek için, ELK ve Loki Stack ile merkezi hosting loglama rehberimizde anlattığımız yöntemleri, SSH erişim olaylarınızı izlemek için de rahatlıkla kullanabilirsiniz.

DCHost Üzerinde Güvenli SSH Mimarisi Nasıl Konumlanır?

SSH anahtar yönetimi ve yetki paylaşımını doğru kurguladığınızda, altyapı tarafında da işleriniz oldukça sadeleşiyor. DCHost olarak sunduğumuz VPS, dedicated sunucu ve colocation çözümlerinde bu mimariyi şu şekilde konumlandırmanızı öneririz:

• Her VPS veya dedicated sunucuda kişiye özel kullanıcılar ve sudo tabanlı yetki yükseltme kullanın.
• SSH üzerinde parola girişini kapatıp, sadece anahtar tabanlı kimlik doğrulamaya izin verin.
• Güvenlik duvarı, Fail2ban, HTTP güvenlik başlıkları gibi katmanları da dahil ederek uçtan uca güvenlik tasarlayın.
• Üretim, staging ve test ortamlarını farklı VPS’lere ayırın; erişim haklarını da bu ayrım üzerinden düzenleyin.

Daha bütünsel bir bakış açısı için, VPS sunucu güvenliğini kapıyı açık bırakmadan sağlama rehberimiz, SSH konusunu da içine alan geniş bir güvenlik kontrol listesi sunuyor.

Bugün basit görünen bir “SSH anahtarını ekleyelim, sonra bakarız” kararı, yarın bir güvenlik olayı yaşandığında dakikalarla değil saatlerle ölçülen kurtarma ve analiz süreçlerine dönüşebiliyor. Küçük bir ekip olmanız, güvenli ve denetlenebilir bir SSH erişim mimarisi kuramayacağınız anlamına gelmiyor; tam tersine, kullanıcı sayısı az olduğu için bunu doğru kurgulamak çok daha kolay.

Eğer mevcut VPS veya dedicated sunucu yapınızda SSH erişimlerini nasıl sadeleştireceğinizi, bastion mimarisi kurup kurmamanız gerektiğini veya ekip yetkilerini nasıl bölmeniz gerektiğini netleştirmek istiyorsanız, DCHost ekibi olarak bu mimariyi birlikte tasarlamaktan memnuniyet duyarız.