SSH anahtarı yönetimi ve temel prensipler

SSH anahtarları nasıl çalışır

SSH anahtarı iki dosyadan oluşur: cihazınızda kalan bir private key ve giriş yapmak istediğiniz her sunucuya kopyaladığınız bir public key. Bağlantı kurulduğunda sunucu, public key kullanarak yalnızca eşleşen private key ile yanıtlanabilen bir challenge gönderir. Private key cihazınızdan asla ayrılmaz; bu nedenle ağ üzerinden hiçbir gizli veri iletilmez ve ele geçirilen bir sunucarda çalınacak yararlı bir veri bulunmaz. Bu sebeple anahtarlar şifrelerden daha güvenlidir. SSH anahtarlarını doğru yönetmek dört alışkanlığa dayanır: her cihaz için bir anahtar, sshd tarafından talep edilen dosya izinleri, seçenekleri yazmayı bırakmak için bir ~/.ssh/config dosyası ve bir dizüstü bilgisayar kaybolduğunda bir anahtarın nasıl kaldırılacağını bilmek.

Bu kılavuz, buradaki hemen hemen her şey herhangi bir Linux sunucusu ve güncel bir OpenSSH sürümü için geçerli olsa da, her bir alışkanlığı Ubuntu 24.04 üzerinde ele almaktadır.

Başlamadan önce, hataları önlemek adına bir terminoloji notu: Public key gizli değildir. Onu bir destek talebine yapıştırabilir, e-posta ile gönderebilir veya yayınlayabilirsiniz; kimse bu anahtarla giriş yapamaz. Private key ise gizli olan kısımdır. Bu dosyayı kopyalayan ve eğer varsa passphrase bilgisini bilen herhangi biri, sunucularınız için sizdir.

Bir anahtar oluşturun: ed25519 doğru varsayılan değerdir

Sunucu üzerinde değil, kendi bilgisayarınızda şu komutu çalıştırın:

ssh-keygen -t ed25519 -C "laptop"

-t ed25519 anahtar türünü belirler. Ed25519 modern varsayılan değerdir: anahtarlar kısa ve hızlıdır; 2014'ten beri tüm OpenSSH sürümleri tarafından desteklenmektedir. Yalnızca ed25519 formatını tanımayan eski bir cihazla bağlantı kurmanız gerekiyorsa ssh-keygen -t rsa -b 4096 seçeneğine dönün. -C "laptop" bir açıklama (comment) ekler. Açıklama kriptografik bir işlem yapmaz; ancak iki yıl sonra bir sunucunun authorized_keys dosyasında bu anahtarı tanımanızı sağlar. Bu nedenle anahtarın bulunduğu cihazın adını verin.

ssh-keygen anahtarın nereye kaydedileceğini sorar. Varsayılan değer olan ~/.ssh/id_ed25519 seçeneğini kabul edin. Ardından bir parola (passphrase) istenir. Bir parola belirleyin; aşağıdaki parola bölümü bunun günlük kullanımda neden bir maliyeti olmadığını açıklamaktadır. Sonuçta iki dosya elde edersiniz: ~/.ssh/id_ed25519 özel (private) anahtar, ~/.ssh/id_ed25519.pub ise genel (public) anahtardır. Genel anahtar kısmına bakın:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

Bu tek bir satırdan oluşur: anahtar türü, anahtar içeriği ve açıklamanız. Sunucularınıza eklenecek olan satır budur.

Sunucu başına değil, cihaz başına bir anahtar

Herkesin sorduğu ilk soru: her sunucu için yeni bir anahtar gerekiyor mu? Hayır. Yazı yazdığınız her cihaz için bir anahtar oluşturun ve bu tek genel anahtarı (public key), cihazın erişmesi gereken tüm sunuculara ekleyin. Anahtar, cihazı tanımlar. Her sunucudaki authorized_keys dosyası, erişime izin verilen cihazların listesidir.

Ölçeklenebilir model budur; alternatif yöntemler ise öngörülebilir hatalar verir. Sunucu başına anahtar modeli, yirmi sunucusu olan bir dizüstü bilgisayarın yirmi adet özel anahtar (private key) taşıması anlamına gelir ve hangi anahtarın hangisi olduğu karışır. Tüm cihazlar tarafından paylaşılan tek bir anahtar ise daha kötüdür: dizüstü bilgisayar çalındığında, aynı özel anahtarı kullandıkları için masaüstü bilgisayarın erişimini de kapatmadan dizüstü bilgisayarın yetkisini iptal edemezsiniz. Bu durumda anahtarı her yerde değiştirmeniz ve tüm cihazlara aynı anda yeniden dağıtmanız gerekir.

Cihaz başına bir anahtar kullanıldığında, kaybolan bir dizüstü bilgisayarın maliyeti her sunucu için sadece bir satırdır: authorized_keys dosyasından dizüstü bilgisayara ait satırı silin, diğer tüm cihazlar çalışmaya devam eder. -C ile belirlediğiniz açıklama (comment), o satırı kolayca bulmanızı sağlar.

Bu modelin temel kuralı şudur: özel anahtar bir cihaz üzerinde oluşturulur ve o cihazla birlikte yok olur. Bir özel anahtarı asla ikinci bir makineye kopyalamayın ve asla bir sunucuya yüklemeyin. Yeni bir cihazın erişime ihtiyacı olduğunda, o cihaz üzerinde yeni bir anahtar oluşturun.

Kamu anahtarını sunucuya ekleyin

En kolay yöntem, OpenSSH ile birlikte gelen ssh-copy-id kullanımıdır:

ssh-copy-id matt@10.0.0.10

Bu araç, mevcut olan yöntemle (genellikle şifre ile) oturum açar, kamu anahtarınızı sunucudaki ~/.ssh/authorized_keys dosyasına ekler; dizin veya dosya eksikse uygun izinlarla birlikte bunları oluşturur. Yeni bir SSH oturumu açarak test edin: Sunucu, hesap şifresini sormadan girişe izin vermelidir. Eğer anahtarınız bir passphrase içeriyorsa, kendi makineniz bunu sorabilir; bu istem yereldir ve sunucu şifresi değildir.

Şifre ile giriş zaten devre dışı bırakılmışsa, ssh-copy-id giriş yapamaz; bu durumda satırı manuel olarak eklemelisiniz. Hala çalışan bir oturumla veya sağlayıcınızın web konsoluyla giriş yapın ve sunucuda şu komutu çalıştırın:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Tırnak işaretleri arasına, id_ed25519.pub dosyasından alınan tam satırı ve gerçek kamu anahtarınızı yapıştırın. authorized_keys formatında her satırda bir kamu anahtarı bulunur ve erişim veritabanının tamamı budur: Bir cihaz eklemek yeni bir satır eklemek, bir cihazın yetkisini kaldırmak ise bir satırı silmek demektir. Yeni bir sunucuda bu adım, şifre ile girişi kapatmadan hemen önce, yeni bir VPS üzerindeki ilk 10 dakika içerisinde yapılmalıdır.

Anahtar ile girişi engelleyen izinler

Bu, anahtar ile giriş işleminin başarısız olmasının en yaygın yoludur ve istemci tarafında sessizce gerçekleşir. Ubuntu 24.04 üzerinde sshd varsayılan olarak StrictModes yes ile çalışır; bu, diğer kullanıcıların düzenleyebileceği bir authorized_keys dosyasının kullanımını reddettiği anlamına gelir. Eğer dosya, ~/.ssh dizini veya ana dizininiz sizden başka biri tarafından yazılabilir durumdaysa, sshd anahtarınızı görmezden gelir ve istemciye herhangi bir açıklama yapmadan şifre sorma aşamasına geçer. (Ubuntu'nun OpenSSH sürümü yalnızca tek bir özel duruma izin verir: sadece sizin dahil olduğunuz ve başka kimsenin bulunmadığı bir özel grup tarafından yazılabilir olan bir dosya grubu. Buna güvenmeyin; aşağıdaki izin modlarını kullanın.) Hata nedeni yalnızca sunucu günlüğünde görünür:

sudo grep 'Authentication refused' /var/log/auth.log

rsyslog bulunmayan minimal bir imajda auth.log bulunmaz; aynı satır journal içinde yer alır: sudo journalctl -u ssh | grep 'Authentication refused'.

Authentication refused: bad ownership or modes for file /home/matt/.ssh/authorized_keys

Çözüm, sunucuda etkilenen kullanıcı olarak çalıştırılması gereken iki izin değişikliği ve bir sahiplik kontrolüdür:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R matt:matt ~/.ssh

Unutulmaması gereken kural: .ssh dizini için 700, dizin içindeki her şey için 600. Aynı değerler kendi bilgisayarınız için de geçerlidir, çünkü istemci de kontrol eder. Diğer kullanıcılar tarafından okunabilen bir özel anahtar, ssh tarafından anahtarın doğrudan reddedilmesine neden olur ve bu durumda hata açıkça belirtilir:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/matt/.ssh/id_ed25519' are too open.

chmod 600 ~/.ssh/id_ed25519 bu sorunu düzeltir.

~/.ssh/config: seçenekleri yazmayı bırakın

Kendi bilgisayarınızdaki bir ~/.ssh/config dosyası, her sunucuya kısa bir isim atar ve sürekli yazdığınız seçenekleri hatırlar. Bu dosyayı 600 izinleriyle oluşturun ve her sunucu için bir Host bloğu ekleyin:

Host web1
    HostName 10.0.0.10
    User matt
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host db1
    HostName 10.0.0.11
    User matt
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Artık ssh web1, ssh -p 22 matt@10.0.0.10 yerine geçer; aynı kısa isim scp, rsync ve git içinde de çalışır, çünkü hepsi bu dosyayı okur. HostName gerçek adrestir, User kullanıcı adını yazma zahmetinden kurtarır ve IdentityFile hangi anahtarın sunulacağını belirler.

IdentitiesOnly yes konusu özel bir açıklama gerektirir, çünkü kafa karıştırıcı bir hatayı düzeltir. Agent birden fazla anahtar tuttuğunda, istemci bunları sırayla sunar ve sunucu her sunumu başarısız bir deneme olarak sayar. Yeterince anahtar yüklendiğinde, doğru anahtar denenmeden önce Received disconnect: Too many authentication failures hatası alınır. IdentitiesOnly yes, istemcinin yalnızca IdentityFile içinde belirtilen anahtarı sunmasını sağlar, böylece bu hata oluşmaz.

Passphrases ve ssh-agent

Passphrase, disk üzerindeki private key dosyasını şifreler. Passphrase kullanılmadığında, dosyayı kopyalayan herkes anahtarı hemen kullanabilir; kullanıldığında ise dosya, passphrase tahmin edilene kadar işlevsiz kalır. Dizüstü bilgisayarlar için gereken koruma tam olarak budur; çünkü dizüstü bilgisayarlar çalınabilir ve yedekleri sızdırılabilir.

Passphrase kullanımının pratikte herhangi bir maliyeti olmamasının nedeni ssh-agent'dir. Agent, çözülmüş anahtarı bellekte tutar; bu sayede her oturum açılışında passphrase bir kez yazılır ve sonraki tüm bağlantılar anında gerçekleşir. Çoğu masaüstü Linux dağıtımı ve macOS, sizin için halihazırda bir agent çalıştırır. Anahtarınızı şu komutla agent içine yükleyin:

ssh-add ~/.ssh/id_ed25519

ssh-add -l, agent'ın o an tuttuğu anahtarları listeler. Bir uyarı: Agent forwarding (ssh -A), bağlantınız sürerken uzak sunucunun kimlik doğrulaması için sizin agent'ınızı kullanmasına izin verir. Bu nedenle, bu özelliği yalnızca tam olarak güvendiğiniz sunucular için etkinleştirin ve varsayılan olarak kapalı bırakın.

Döndürme ve iptal etme: kayıp dizüstü bilgisayar tatbikatı

Sıradan bir SSH anahtarını iptal etmek, o anahtarın bulunduğu her sunucudaki authorized_keys dosyasından ilgili satırı silmekten ibarettir. Bildirilecek bir sertifika otoritesi veya beklenecek bir son kullanma tarihi yoktur. Satır silindiği anda, o anahtar ile yapılan yeni girişler başarısız olur.

Bu tatbikatı acil bir durum oluşmadan önce gerçekleştirin. Bir sunucu seçin, ~/.ssh/authorized_keys dosyasını açın ve anahtarı yorum (comment) kısmından bulun. Satırı bir editör ile silin veya yorum kısmına göre filtreleyin:

grep -v ' laptop$' ~/.ssh/authorized_keys > ~/.ssh/authorized_keys.tmp
mv ~/.ssh/authorized_keys.tmp ~/.ssh/authorized_keys

Ardından, iptal ettiğiniz cihazdan giriş işleminin artık başarısız olduğunu, başka bir cihazdan ise giriş işleminin hâlâ çalıştığını doğrulayın. Bir detaya dikkat edin: Anahtarı silmek, halihazırda açık olan oturumları kapatmaz; çünkü anahtar sadece giriş anında kontrol edilir. Eğer çalınan bir cihazın yetkisini iptal ediyorsanız, sunucudaki who dosyasını da kontrol edin ve tanımadığınız tüm oturumları sonlandırın.

Anahtar döndürme işlemi, aynı işlemin farklı bir sırayla yapılmasıdır: Cihaz üzerinde yeni bir anahtar oluşturun, ssh-copy-id ile yükleyin, yeni anahtarın giriş yaptığını doğrulayın ve ardından eski satırı silin. Bu işlemi cihaz el değiştirdiğinde, anahtar ifşa olduğunda veya bir ekip üyesi ayrıldığında yapın. Bu işlemi iki sunucu üzerinde manuel olarak yapmak uygundur; ancak yirmi sunucu için otomasyon gereklidir. birden fazla Linux sunucusunu yönetmek içeriği, aynı authorized_keys durumunu tüm bir filoya nasıl aktaracağınızı göstermektedir.

Yapılmaması gerekenler

• Tek bir private key'i tüm cihazlarda kullanmayın. Bu durum, çalınan tek bir cihaz için anahtarın her yerde değiştirilmesini gerektirir ve anahtarın iptal edilmesini imkansız kılar.

• Private key'i bir git repository'sine commit etmeyin; bu repository private olsa bile geçerlidir. Otomatik tarayıcılar public repository'leri izler ve bir push işleminden dakikalar sonra sızan anahtarları dener; ayrıca daha sonra public hale getirilen bir repository tüm geçmişini sızdırır.

• Bir sunucunun başka bir sunucuya erişebilmesi için laptop'ınızın private key'ini o sunucuya yüklemeyin. Sunucunun kendisinde ayrı bir key oluşturun ve bu key'e sadece ihtiyaç duyulan yerde yetki verin.

• Private key'i chat, e-posta veya ticket içerisine yapıştırmayın. Paylaşılan tek kısım public key olan .pub dosyasıdır.

Anahtarınız güvenilir bir şekilde giriş yapmaya başladığında, bir sonraki adım olarak password authentication özelliğini kapatın; böylece sunucunuza yönelik sürekli deneme yanılma saldırıları tamamen engellenir. Bu işlem için gerekli yapılandırma SSH hardening on a VPS içeriğinde yer almaktadır.

FAQ

SSH anahtarları şifre gönderilmeden nasıl çalışır?

Sunucu, kamuya açık anahtarınızı ~/.ssh/authorized_keys içerisinde tutar. Giriş sırasında sunucu bir meydan okuma (challenge) gönderir, istemciniz bu meydan okumayı özel anahtar ile imzalar ve sunucu imzayı kamuya açık anahtar ile doğrular. Özel anahtar cihazınızdan asla ayrılmaz; bu nedenle iletim sırasında ele geçirilecek bir veri veya sunucudan çalınacak yeniden kullanılabilir bir bilgi yoktur. Ele geçirilen bir sunucu yalnızca kamuya açık anahtarları sızdırır, bunlar başka bir yere giriş yapmak için kullanılamaz.

Tüm sunucularım için aynı SSH anahtarını mı kullanmalıyım?

Eğer anahtar tek bir cihazda kalıyorsa, birçok sunucuda aynı anahtarı kullanmak doğrudur. Kural, sunucu başına değil, cihaz başına bir anahtar şeklindedir: dizüstü bilgisayarınızın kamuya açık anahtarı, dizüstü bilgisayarın erişmesi gereken her sunucuya eklenir ve masaüstü bilgisayarınızın kendi anahtarı bulunur. Bu yöntem iptal etme işlemini basitleştirir; bir cihazın kaybı, her sunucudan yalnızca tek bir tanımlanabilir satırın kaldırılması anlamına gelir ve diğer cihazlar çalışmaya devam eder.

.ssh dizini ve authorized_keys dosyası hangi izinlere sahip olmalıdır?

~/.ssh üzerinde 700, authorized_keys üzerinde ise 600 izinlerini ayarlayın; bu izinler tüm özel anahtarlar için de geçerli olmalı ve dosyalar ilgili hesaba ait olmalıdır. sshd varsayılan olarak StrictModes yes ile çalışır; bu nedenle sizden başka birinin yazma yetkisi olduğu bir dosya veya ana dizin, anahtarınızın sessizce görmezden gelinmesine neden olur. Bu durumun tek izi, sunucunun auth log veya journal dosyasındaki Authentication refused: bad ownership or modes kaydıdır.

Bir sunucudan SSH anahtarı nasıl kaldırılır?

Anahtarın yetkilendirildiği hesaptaki ~/.ssh/authorized_keys dosyasından ilgili satırı silin. Doğru satırı, anahtar verisinden sonra gelen açıklama (comment) kısmından bulun. O anahtar ile yapılan yeni girişler anında başarısız olur, ancak halihazırda açık olan oturumlar açık kalmaya devam eder; bu nedenle cihaz çalındıysa aktif oturumları da sonlandırın. Bu işlemi anahtarın kopyalandığı tüm sunucularda tekrarlayın.

SSH anahtarım için bir passphrase (parola) kullanmam gerekir mi?

Bir dizüstü veya masaüstü bilgisayardaki anahtar için evet. Parola, anahtar dosyasını şifreler; böylece çalınan veya sızdırılan bir kopya tek başına işlevsiz kalır. Ayrıca ssh-agent kullanımı, her bağlantıda değil, oturum başına bir kez parola yazacağınız anlamına gelir. Sunucularda otonom otomasyon tarafından kullanılan anahtarlar genellikle parolaya sahip değildir çünkü yazacak bir kullanıcı yoktur; bu anahtarları, hedef hesabın yetkilerini kısıtlayarak koruyun.