VPS’te SSH Güvenliği Nasıl Sağlamlaşır? FIDO2 Anahtarları, SSH CA ve Rotasyonun Sıcacık Yolculuğu

Gece Yarısı Bir Girişim ve İçime Düşen O Küçük Şüphe

Hiç kapının kilidini kontrol etmek için geri döndüğünüz oldu mu?

Bir gece, herkesin uyuduğu o sakin saatlerde, monitörün sol alt köşesinde bir bildirim belirdi. Üzerine tıklayınca tanıdık bir tablo: birkaç başarısız SSH denemesi, bir port taraması, araya karışmış normal bir deploy. Bir an durup düşündüm; şifre yok, anahtarlar var, fail2ban var, güvenlik duvarı da haliyle işini yapıyor. Yine de içimde o küçük ses, kapıyı iki kez kontrol ettiren ses, “Peki ya anahtarların kendisi?” diye fısıldıyordu. Laptopta, Yedek klasöründe, eski bir sunucuda unutulmuş bir authorized_keys satırı… Hepsi birer kapı anahtarı sonuçta. Kaybolursa? Kopyalanırsa?

Ertesi gün kahvemi alıp notlarıma döndüm. Amacım, SSH güvenliğini yalnızca bugünkü saldırılara değil, yarınki sürprizlere de dayanıklı kılmaktı. Yol haritası kendini gösterdi: FIDO2 donanım anahtarlarıyla dokunmadan açılmayan bir kapı, SSH CA ile kimliği sertifikaya bağlayan bir düzen ve rotasyonla anahtarların canlı bir döngüde tutulması. Bu yazıda tam da bunu konuşacağız. Hikaye gibi, adım adım, tıpkı bir evi baştan aşağı toparlar gibi.

Anahtarın Hikayesi: Parola Biter, Peki Anahtarın Sonu Gelir mi?

Şifreden anahtara, anahtardan donanıma

Parolalarla vedalaştığımız günü hatırlıyorum. SSH anahtarlarına geçtiğimizde içim gerçekten rahatlamıştı. Sunucuya sırf tahminle girilemeyeceğini bilmek güzel. Ama sonra şu gerçekle barıştım: dijital anahtar da bir dosya nihayetinde. Bir yerde duruyor, yedekleniyor, bazen paylaşımı kolay olsun diye bir klasöre atılıyor. İyi korumazsanız, tıpkı çiziksiz bir kopya anahtar gibi cebine giriveren birine dönüşebilir. Passphrase elbette şart, ama yine de bilgisayardaki anahtarın çalınması ihtimali akılda bir gölge gibi kalıyor.

İşte burada donanım anahtarları devreye giriyor. FIDO2 destekli bir güvenlik anahtarı, anahtar işlemini bilgisayarın dışına taşıyor. Özetle, zarf kasanın içine giriyor. Kimlik doğrulama için fiziksel bir dokunuş istiyor, hatta PIN ile koruyor. Birinin anahtar dosyasını kopyalaması yetmiyor; elinizdeki o küçük cihaz olmadan giriş olmuyor. Bu, zihnimdeki o küçük şüpheyi susturan ilk adım oldu.

Mesela şöyle düşünün…

Laptopunuzu bir kafede unuttunuz. Disk şifreli, iyi güzel. Ama biri cihazı açtıysa, içindeki SSH anahtarını da alabilir. Donanım anahtarıyla kurulan düzende ise, anahtar dışarıda; fiziksel dokunma olmadan, belirlediğiniz PIN olmadan işlem yapmıyor. Üstüne bir de anahtarın sunucuda nasıl kullanılacağını sınırlarsanız, örneğin yalnızca belirli bir kullanıcı ve belirli IP’ler için kabul edilecek şekilde kayıt düşerseniz, el sıkışmanın alanını iyice daraltırsınız. Böylece anahtar artık sadece bir dosya değil, sizinle nefes alan bir varlık gibi çalışır.

FIDO2 ile SSH: Dokunmadan Geçiş Yok

Önce temel soruyu soralım: Uyumlu muyuz?

FIDO2’yi SSH ile kullanmak için OpenSSH’nin FIDO/U2F destekleyen bir sürümü gerekiyor. Bu destek uzun süredir var, yine de sunucularınızda ve yerel makinenizdeki sürümü hızlıca kontrol etmek iyi fikir. Terminalde ssh -V çıktısına bir bakın; yeterince güncelse, ssh-keygen size -t ed25519-sk gibi sihirli bir kapı aralayacaktır. Ayrıntılara meraklıysanız ssh-keygen seçenekleri üzerinden ilerlemek keyifli oluyor. Bir de üretici notlarına göz atmak güzel; örneğin Yubico’nun SSH ile FIDO2 kullanımı notları pratik ipuçları veriyor.

İlk anahtar: Komut, dokunuş ve küçük bir gülümseme

Kurulum aslında düşündüğünüzden daha sakin. Terminalde ssh-keygen -t ed25519-sk -C "ad@sunucu" komutunu çalıştırınca, cihazınız sizden bir dokunuş bekler. PIN belirlemek isterseniz süreçte sorulur. Ortaya iki dosya çıkar: özel anahtarınız ve .pub uzantılı açık anahtarınız. Açık anahtarı sunucudaki ~/.ssh/authorized_keys içine tanıdık şekilde ekliyorsunuz. Bir farkla: dokunma zorunluluğu artık devrede. Bu küçük jest, hem güven hissi veriyor hem de davranışsal açıdan dikkat kazandırıyor. Bir yerde beklenmedik bir oturum açma varsa, siz dokunmadan işlem ilerlemeyecek.

Yetkiyi daraltmak: Sınırlar, huzur verir

Açık anahtarı authorized_keys’e eklerken, başına küçük ama etkisi büyük kurallar koyabilirsiniz. from="IP_aralığı" diyerek yalnızca belirli ağlardan kabul ettirebilir, command="..." ile oturuma özel bir açılış komutu çalıştırabilir, no-agent-forwarding gibi kısıtlarla vekaletin suistimalini engelleyebilirsiniz. Hepsini her yerde kullanmaya gerek yok; ama kritik makinelerde yürüdüğünüz yolun taşlarını sıkılaştırmak iyi hissettiriyor.

Sunucu tarafı: Şifrenin devre dışı kalışı

Gün gelir şifresiz yaşamın tadı daha çok çıkar. Sunucuda sshd_config içinde PasswordAuthentication no ve PubkeyAuthentication yes satırlarını görmeyi seviyorum. Kapanan bir kapı, açılan sağlam bir kapının yanında hiç fena durmuyor. Burada bir uyarı: kendinizi kilitlememek için önce yeni anahtarınızla giriş yapabildiğinizden emin olun, sonra şifreyi kapatın. Küçük bir not daha: bağlandığınız sunucunun adını ve anahtar türünü terminal prompt’unuzda gösteren basit bir dokunuş, yanlış makineye komut gönderme ihtimalini azaltır. Küçük ama kalbi ısıtan bir alışkanlık.

SSH CA: Kimliği Sertifikaya Bağlayınca Ortalık Sakinleşiyor

Neden CA? Çünkü tek tek anahtar dağıtmak yoruyor

FIDO2 anahtarlarıyla yol alırken, bir noktada şu soru beliriyor: “Peki yüzlerce sunucu, onlarca ekip arkadaşı olunca kim bu işin düzenini tutacak?” SSH’nin güzel sürprizlerinden biri, sertifika yetkilisi mantığını da sunması. Yani kendi küçük CA’nızı kurup, kullanıcı anahtarlarını tek tek değil, imzalanmış sertifikalarla yönetebiliyorsunuz. Sunuculara tek tek açık anahtar kopyalamak yerine, “Bu CA’nın imzaladığı kullanıcılar kabul görecek” diyorsunuz ve gerisini tutarlı bir kurala bağlıyorsunuz.

Temel akış: Bir ana CA, bir satır güven ve hızlı imzalar

Kurgu basit: Güvenli bir yerde bir CA anahtar çifti oluşturuyorsunuz. Sunuculara yalnızca CA’nın .pub kısmını gönderip /etc/ssh/trusted_user_ca_keys içine koyuyorsunuz. Sonra kullanıcıların FIDO2 açık anahtarlarını bir sertifikaya bağlıyorsunuz. Bunun için ssh-keygen -s ca_ozel -I etiket -n kullanici -V +52w kullanici.pub gibi bir komut yeterli. Süreyi, adı ve rolü kendiniz belirlersiniz. İmza tamamlanınca, kullanıcı tarafında anahtarın yanına bir -cert.pub dosyası oluşur; SSH bunu otomatik görür ve sertifikayla giriş yapar. Bu düzen, ekip büyüdükçe daha çok huzur verir, çünkü yetkiyi artık tek bir yerde yönetiyorsunuz.

Prensipler: Kim hangi şapkayı takıyor?

CA tarafında en sevdiğim detay, “principal” mantığıdır. Sertifikaya “bu kullanıcı şu rol altında girer” diyebiliyorsunuz. Üretim sunucusuna başka, staging’e başka bir şapka takabilirsiniz. Sunucu tarafında da “Şu rolde imzalanmış kullanıcılar kabul edilir” şeklinde bir eşleştirme kurulur. Bu, ekipler için gerçek bir hayat kurtarıcı. Bir arkadaşınız ekipten ayrıldığında, sunuculardan tek tek anahtar silme derdi yerine, onun sertifikasını imzalamayı bırakmanız yeterli olur. Ek olarak, sertifika formatının detaylarına meraklıysanız OpenSSH sertifika formatı ayrıntıları gayet anlaşılır bir rehber niteliğinde.

Host CA ile “kime bağlandım” sorusu da netleşiyor

Kullanıcı tarafı kadar önemli bir konu da sunucu kimliği. İlk bağlantıda “Bu sunucuya güveniyor musun?” sorusuna refleksle yes demişliğimiz vardır. Host CA bu refleksi düzenli bir alışkanlığa çeviriyor. Sunucu anahtarlarını da CA ile imzalayıp, istemcilere “Bu CA’nın imzaladığı sunucular güvenilirdir” derseniz, o ilk tanışmadaki belirsizlik ortadan kalkar. Deploy sırasında yeni bir sunucu geldiğinde, imzayı verirsiniz, istemciler huzurla bağlanır. Hem güven hem konfor, tek hamlede.

Anahtar Rotasyonu: Yenile, Sadeleştir, Rahat Uyu

Rotasyon neden bu kadar kritik? Çünkü hiçbir şey sonsuz yaşamaz

Bir gün bile anahtar değiştirmekle uğraşmadıysanız, ilk rotasyon biraz baş ağrısı gibi gelebilir. Ama düzen kurulduğunda gerçekten nefes aldırıyor. Temel mantık şu: hiçbir anahtar sonsuza dek geçerli değil, sertifikaların belirli bir vadesi var ve her yenilemede gizli bir tat var. Yeni anahtar oluşturulur, CA imzası alınır, sunucular güvenen CA’yı zaten bildiği için hiçbir yere tek tek dokunmadan girişler devam eder. Eski sertifika ise göz göre göre süresi dolup düşer. Bu ritim, güvenliği canlı tutar.

Pratik akış: Yan yana yürüyen iki anahtarın kısa hikayesi

Benim sevdiğim pratik, yeniyi devreye almadan önce kısa bir süre ikisini birlikte yaşatmaktır. Yeni FIDO2 anahtarınızla ssh-keygen -t ed25519-sk komutu ile çifti üretiyorsunuz, CA’dan yeni sertifikayı alıyorsunuz. Ardından birkaç gün yeni anahtarı aktif kullanıp bağlantıların sorunsuz olduğunu görüyorsunuz. Bu arada eski anahtar hâlâ geçerli. Her şey yolunda ise eskiyi sahneden alıyorsunuz. Arada bir özel durumu, örneğin bir bastion sunucusu veya otomasyon hesabını, sessizce ayrı bir gözle kontrol etmek iyi hissettiriyor.

Acil durumlar: Bir sahne kapanışı kadar net olmalı

Rotasyon sadece yenilemek değildir; gerektiğinde hızla kapatabilmek demektir. CA düzeninde bu çok daha kolay. Kullanıcı sertifikasını kısa vade ile imzalarsınız, erken iptal gerekirse yeni imza vermezsiniz. Gerektiğinde RevokedKeys dosyasına bir kayıt düşerek bir anahtarı anında dışarıda bırakabilirsiniz. Sunucu tarafında bu dosyayı takip eden bir ayar koymak, panik anında ayağınızı yere sağlam basmanızı sağlar. Bir de küçük hatırlatma: iki fiziksel donanım anahtarı taşımak paha biçilemez; biri çekmecede, diğeri yanınızda. Böylece kayıp bir hikayeye dönüşmez.

Dağıtımı sarsmadan yürütmek

Rotasyon sürecinde en çok korktuğumuz şey kesinti olur. İyi haber, bu süreci dağıtımın doğal akışına yedirebilirsiniz. Örneğin yeni anahtar devreye alındıktan sonra konfigürasyon yönetimine CA ayarlarını ekleyip, host sertifikalarını imzalayarak ortama yayarsınız. Sıfır kesinti yaklaşımı hoşunuza gidiyorsa, anahtar ve sertifika dağıtımını sürümlerle yönetmek güzel oluyor; bu konuya benzer bir bakış açısı için VPS’e sıfır kesinti CI/CD kurulumunu adım adım anlatan rehber aklın bir köşesinde dursun.

Göz Kulak Olmak: Loglar, Uyarılar ve Sakin Bir Zihin

Log dünyası: Kabul edilen bir anahtar, reddedilen bir deneme ve küçük sinyaller

Güvenlikte beni en çok rahatlatan şeylerden biri, öngörülebilir bir log. SSH, kabul edilen ve reddedilen bağlantılar, hangi kullanıcıyla ve hangi anahtarla geldiği gibi sinyaller verir. Bu sinyalleri toplayıp anlamlandırınca, gecenin bir yarısı gelen bildirim bana “Şu IP’den, şu kullanıcıyla, sertifikası şu tarihe kadar geçerli bir giriş oldu” diyor. O an içim rahatlıyor. Bu düzeni kurmak için merkezi loglamayı sevmek gerekiyor. Eğer hâlâ dağınık loglarla yaşıyorsanız, grafiği ve alarmı bir araya getiren Grafana ile sakin kalan bir zihin için merkezi loglama rehberi güzel bir yoldaş.

Alarm kuralları: Zamanı geldiğinde kapıyı çalar

Bir süre logları izleyince, “normal” dediğiniz bir ritim ortaya çıkar. Bu normalin dışına çıkan bir şey olduğunda, küçük ama anlaşılır bir alarm hayat kurtarır. Mesela başarısız denemelerin birden artması, beklenmedik bir ülkeden gelen bağlantı, sertifikası yakında bitecek bir kullanıcının hâlâ aktif olması. Tüm bunları sakin ve nazik bir uyarıyla hatırlatmak için iyi araçlar var. Birlikte bir yapı kurmak isterseniz, log yönetimini rayına oturtan pratik rehber sağlam bir referans olabilir.

Ağzın tadı: Güvenlik ayarları bir bütün

SSH güvenliği, tabakta tek başına bir yemek değil. Ağ, TLS, servis ayarları, hepsi bir sofra. Uçtan uca zihniyet, küçük sürprizleri büyümeden yakalamanızı sağlar. Örneğin web katmanında modern şifreler ve HSTS gibi ayarlar, standartları yüksek bir ortamda yaşadığınızı hatırlatır. İsterseniz bu tarafa bakarken TLS 1.3 ve modern şifrelerin sıcacık mutfağı keyifli bir okuma olur. Sonuçta amaç belli: parçaları bir araya getirip, her katmanda tutarlı bir güvenlik dili konuşmak.

Adım Adım Uygulama: Bir Akşamüstü Planı

Önce cihazı elinize alın, sonra notları

Ben uygulamaya hep küçük bir kontrol listesiyle başlarım, ama listeyi yazıya dökmek yerine şöyle anlatayım. Önce elinizde bir FIDO2 destekli güvenlik anahtarı olsun. Yerel makinenizde ssh -V ile sürümü kontrol edin. Gerekirse güncelleyin. Ardından ssh-keygen -t ed25519-sk -C "etiket" diyerek anahtar çiftinizi oluşturun. Dokunmanızı isteyecek, belki PIN soracak. Açık anahtarı sunucuda authorized_keys içine ekleyin, ama eklemeden önce “Burada hangi kısıtlar değer katar?” diye kendinize sorun. O an, from=, no-agent-forwarding, belki bir command= eklemek anlamlı geliyorsa yazın. Sonra bağlantıyı test edin ve kullanıcı parolasını kapatma adımına cesur bir adımla geçin.

CA’yı devreye alırken acele etmeyin

CA kurulumunda dikkat edilmesi gereken şey, onu da bir “ana anahtar” gibi görmektir. Güvenli bir yerde oluşturun, yedeklemesini doğru yapın. Sunuculara trusted_user_ca_keys içine yalnızca CA’nın açık anahtarını dağıtın. Kullanıcı tarafında ise imza sürecini bir küçük araç veya kısa script ile kolaylaştırın. Bir isimlendirme standardı oturtmak, altı ay sonra teşekkür edeceğiniz bir hediye gibi. “Hangi sertifika kime aitti, ne zamana kadar geçerliydi” sorularının cevabını dosya adında görebilmek, yorgun bir geceyi güzel bir sabaha bağlar.

Host CA’yı unutmayın

Host CA, ilk bağlantıda yaşanan “Acaba bu o mu?” şüphesini ortadan kaldırır. Yeni makineyi imzalayıp, istemci tarafında CA’yı tanımladığınızda, komut satırında güvenle enter’a basarsınız. Bu konuların teorik tarafı da merak uyandırıyorsa, OpenSSH’nin süslü detayları arasında kısa bir gezinti yapmak hoş olabilir. FIDO ve sertifika dünyasının pratik yönleri için Yubico’nun notları tekrar işinize yarar; teknik detay merakında ssh-keygen belgesi tatlı bir referans olarak kenarda kalsın.

Kurtarma Planı: Kötü Günde En İyi Arkadaşınız

İki donanım anahtarıyla gelen huzur

Bir gün çantanızın fermuarı yırtılır ve anahtarın biri kaybolur. O günün panik olmaması için yedek bir anahtarı önceden hazırlamak gerekir. İki farklı cihazda anahtarınızı üretip CA’dan sertifika imzası almak, sonra ikisini de test etmek, uzun vadede stresinizi düşürür. Birini evde saklamak, diğerini her gün yanınızda taşımak, basit ama etkili bir düzen. PIN’i güvenli bir yerde, aklınızın rahat edeceği şekilde not aldığınızdan da emin olun.

Geri alma ve iptal

Kurtarma sadece yedekle sınırlı değil. Sertifika vadesini kısa tutmak, risk penceresini küçültür. Bir anahtarı iptal etme mekanizmasını önceden denemek de önemlidir. RevokedKeys dosyasını yapılandırıp kısa bir simülasyon yapmak, kritik bir anda nasıl davranacağınızı prova ettirir. Bu provalar küçük zaman alır ama büyük huzur verir. Tıpkı yangın tatbikatı gibi; dilerim hiç gerekmez, ama varsa iyi ki var dersiniz.

İşin gözlem tarafını diri tutmak

Son bir dokunuş olarak, loglarınızda SSH oturumlarını ve sertifika bitiş tarihlerini gösterecek küçük paneller hazırlayın. Modern gözlemlenebilirlik araçlarıyla bu görünümleri kurmak artık zor değil. İlham için, log dünyasının içinde gezdiren o detaylı anlatımı seviyorsanız, merkezi loglama rehberine ve pratikte alarm kurallarıyla işini rayına koyan log yönetimi yazısına tekrar göz atabilirsiniz. Oradaki fikirleri SSH özelinde uyarlamak çok kolay.

Kapanış: Güvenliği Bir Günlüğüne Değil, Hayatınıza Katın

Bugünün işi, yarının rahat uykusu

Bu yolculukta gördüğüm şey şu oldu: SSH güvenliği bir özelliği açıp kapamaktan ibaret değil. FIDO2 donanım anahtarlarıyla kimliği cihazınıza, parmak dokunuşunuza bağlayınca “benden habersiz olmaz” hissi çok güçlü geliyor. SSH CA ile kimliği sertifikalara emanet edince, ekip büyüse de kurallar değişse de düzen bozulmuyor. Rotasyonla anahtarların vadesini yönetince, dün atılmış bir anahtarın bugün sürprizlere sebep olmasının önüne geçiyorsunuz. Tüm bunları da loglar ve küçük alarmlarla bir ritme oturtunca, gece yarısı gelen bildirimler panik değil, iyi planlanmış bir düzenin hatırlatması oluyor.

Pratik bir akşam planı öneriyorum: bir FIDO2 anahtarı alın, ilk anahtarınızı üretin, sunucuda şifreyi kapatmadan önce yeni anahtarla rahatça girebildiğinizi test edin. Ardından CA fikrini küçük bir pilotla deneyin; bir iki sunucuda kullanıcı ve host sertifikasını yürütüp, nasıl hissettirdiğine bakın. Ritim oturunca rotasyonu takvime bağlayın; vade bitmeden bir hafta önce yeni sertifikayı devreye alıp eskisini saygıyla uğurlayın. Güvenlik böylece günlük işlerinizin doğal parçası olur. Eğer ağ ve uygulama katmanını da aynı sevgiyle ele almak isterseniz, web tarafındaki sert ve sıcak ayarları bir arada anlatan TLS 1.3 rehberine göz atmak da iyi gelir. Umarım bu yazı size yoldaş olmuştur. Bir dahaki yazıda görüşmek üzere, anahtarlarınızın her zaman doğru kapıları açtığı günler dilerim.