SSH anahtarı yönetimi ve güvenli kullanım rehberi

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

SSH anahtarı bir çift dosyadan oluşur: cihazınızda tuttuğunuz özel (private) anahtar ve giriş yapmak istediğiniz her sunucuya kopyaladığınız açık (public) anahtar. Bağlantı kurduğunuzda sunucu, açık anahtarı kullanarak yalnızca eşleşen özel anahtarın yanıtlayabileceği bir sınama gönderir. Özel anahtar cihazınızdan asla ayrılmaz; bu sayede ağ üzerinden hiçbir gizli veri iletilmez ve ele geçirilen bir sunucuda çalınabilecek değerli bir bilgi bulunmaz. Anahtarların parolalardan daha güvenli olmasının nedeni budur. SSH anahtarlarını doğru yönetmek dört alışkanlığa dayanır: cihaz başına bir anahtar, sshd tarafından zorunlu tutulan dosya izinleri, seçenekleri tekrar tekrar yazmanızı engelleyen bir ~/.ssh/config dosyası ve bir dizüstü bilgisayar kaybolduğunda anahtarın nasıl kaldırılacağını bilmek.

Bu kılavuz, Ubuntu 24.04 üzerinde her bir alışkanlığı ele almaktadır; ancak buradaki bilgilerin neredeyse tamamı tüm Linux sunucuları ve güncel OpenSSH sürümleri için geçerlidir.

Başlamadan önce, ciddi hataların önüne geçmek adına bir terim açıklamasında bulunalım. Açık anahtar gizli değildir. Onu bir destek talebine yapıştırabilir, e-posta ile gönderebilir veya yayınlayabilirsiniz; kimse bu anahtarla giriş yapamaz. Gizli olan, özel anahtardır. Bu dosyayı kopyalayan ve (eğer varsa) parolasını bilen herkes, sunucularınız nezdinde sizsiniz demektir.

Bir anahtar oluşturun: ed25519 doğru varsayılandır

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

ssh-keygen -t ed25519 -C "laptop"

-t ed25519, anahtar türünü seçer. Ed25519 modern varsayılandır: anahtarlar kısa ve hızlıdır; 2014'ten bu yana tüm OpenSSH sürümleri tarafından desteklenir. Yalnızca ed25519 desteklemeyen eski bir cihazla iletişim kurmanız gerektiğinde veya FIPS modu etkinleştirilmiş RHEL 8 ve 9 gibi politikası bunu yasaklayan bir sistemde ssh-keygen -t rsa -b 4096 seçeneğine geri dönün; bu sistemler Ed25519 anahtarlarını Ed25519 keys are not allowed in FIPS mode ile reddeder. -C "laptop" bir açıklama belirler. Açıklamanın kriptografik bir işlevi yoktur, ancak iki yıl sonra sunucunun authorized_keys dosyasında bu anahtarı nasıl tanıyacağınızı belirler; bu nedenle anahtarın bulunduğu cihazı isimlendirin.

ssh-keygen, anahtarın nereye kaydedileceğini sorar. Varsayılan olan ~/.ssh/id_ed25519 seçeneğini kabul edin. Ardından bir parola (passphrase) ister. Bir parola belirleyin; aşağıdaki parola bölümü bunun günlük kullanımda size neden bir maliyet getirmediğini açıklar. Sonuçta iki dosyanız olur: ~/.ssh/id_ed25519 özel anahtardır, ~/.ssh/id_ed25519.pub ise genel anahtardır. Genel anahtarın içeriğine bakın:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

Bu tek bir satırdır: anahtar türü, anahtar verisi ve açıklamanız. Sunucularınıza eklenecek olan satır budur.

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

Herkesin ilk sorduğu soru şudur: Her sunucu için yeni bir anahtar mı oluşturmalıyım? Hayır. Üzerinde işlem yaptığınız her cihaz için bir anahtar oluşturun ve bu genel anahtarı (public key), cihazın erişmesi gereken her sunucuya ekleyin. Anahtar, cihazı tanımlar. Her sunucudaki authorized_keys dosyası, içeri girmesine izin verilen cihazların listesidir.

Bu model ölçeklenebilir olanıdır; alternatifleri ise öngörülebilir şekillerde başarısız olur. Sunucu başına bir anahtar kullanmak, yirmi sunucusu olan bir dizüstü bilgisayarın yirmi farklı özel anahtar (private key) taşıması anlamına gelir ve hangisinin hangisi olduğunu takip edemezsiniz. Tüm cihazlarınız tarafından paylaşılan tek bir anahtar ise daha kötüdür: Dizüstü bilgisayar çalındığında, masaüstü bilgisayarınızın da erişimini kesmeden dizüstü bilgisayarın yetkisini kaldıramazsınız; çünkü her ikisi de aynı özel anahtarı tutar. Bu durumda anahtarı her yerden değiştirmeniz ve aynı anda tüm cihazlara yeniden dağıtmanız gerekir.

Cihaz başına bir anahtar modelinde, kaybolan dizüstü bilgisayarın size maliyeti sunucu başına tek bir satırdır: Dizüstü bilgisayara ait satırı authorized_keys dosyasından silin; diğer tüm cihazlar çalışmaya devam edecektir. -C ile ayarladığınız açıklama, o satırı kolayca bulmanızı sağlar.

Modelin temelindeki kural şudur: Özel anahtar bir cihazda oluşturulur ve o cihazla birlikte ömrünü tamamlar. Özel bir 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.

Public anahtarı sunucuya yerleştirme

En kolay yol, OpenSSH ile birlikte gelen ssh-copy-id aracını kullanmaktır:

ssh-copy-id matt@10.0.0.10

Bu araç, o an çalışan herhangi bir yöntemle (genellikle parola ile) giriş yapar, public anahtarınızı sunucudaki ~/.ssh/authorized_keys dosyasına ekler ve dizin ile dosya mevcut değilse bunları doğru izinlerle oluşturur. Yeni bir SSH oturumu açarak test edin: sunucu, hesap parolasını sormadan sizi içeri almalıdır. Anahtarınızın bir parola (passphrase) koruması varsa, kendi makineniz bunu sorabilir; bu istem yereldir ve sunucu parolası değildir.

Parola ile giriş zaten devre dışı bırakılmışsa, ssh-copy-id sunucuya erişemez; bu durumda satırı manuel olarak eklemeniz gerekir. Hâlâ çalışan bir oturum veya sağlayıcınızın web konsolu üzerinden 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

Gerçek public anahtarınızı tırnak işaretlerinin içine, id_ed25519.pub dosyasındaki tam tek satırlık ifadeyi yapıştırın. authorized_keys dosyası her satırda bir public anahtar tutar ve tüm erişim veritabanı budur: yeni bir cihaz eklemek bir satır eklemek, bir cihazın erişimini iptal etmek ise ilgili satırı silmek anlamına gelir. Yeni bir sunucuda bu adım, parola ile girişi kapatmadan hemen önce, yeni bir VPS üzerindeki ilk 10 dakika rehberinde yer almalıdır.

Anahtar ile girişi engelleyen izinler

Bu, anahtar ile girişin başarısız olmasının en yaygın nedenidir ve istemci tarafında sessizce başarısız olur. sshd, Ubuntu 24.04 üzerinde varsayılan olarak StrictModes yes ile çalışır; bu, başka kullanıcıların düzenleyebileceği bir authorized_keys dosyasını kullanmayı reddettiği anlamına gelir. Eğer dosya, ~/.ssh dizini veya ev dizininiz sizden başka herhangi biri tarafından yazılabilir durumdaysa, sshd anahtarınızı görmezden gelir ve istemcide hiçbir açıklama yapmadan parola sormaya geri döner. (Ubuntu'nun OpenSSH'i yalnızca tek bir istisnai durumu tolere eder: yalnızca sizin özel grubunuzun yazabildiği ve başka kimsenin bulunmadığı bir dosya grubu. Buna güvenmeyin; aşağıdaki modları koruyun.) Nedeni yalnızca sunucunun günlüğünde görünür:

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

rsyslog içermeyen minimal bir imajda auth.log bulunmaz; aynı satır sudo journalctl -u ssh | grep 'Authentication refused' günlüğünde yer alır.

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

Çözüm, sunucuda ilgili kullanıcı olarak çalıştırılacak 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, içindeki her şey için 600. İstemci de kontrol ettiği için aynı sayılar kendi bilgisayarınızda da geçerlidir. Diğer kullanıcılar tarafından okunabilen bir özel anahtar, ssh'nin anahtarı doğrudan reddetmesine neden olur ve bu sefer hata belirgindir:

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

chmod 600 ~/.ssh/id_ed25519 bunu düzeltir.

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

Kendi bilgisayarınızdaki bir ~/.ssh/config dosyası, her sunucuya kısa bir ad vermenizi sağlar ve sürekli yazdığınız seçenekleri hatırlar. 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 yerine ssh -p 22 matt@10.0.0.10 kullanabilirsiniz; aynı kısa ad SSH üzerinden scp, rsync ve git komutlarında da çalışır. Bu araçlar dosyayı doğrudan okumazlar; bağlantıyı OpenSSH'in ssh aracını çalıştırarak kurarlar ve ssh bu dosyayı okur. Git veya rsync gibi araçları, örneğin Git'in GIT_SSH_COMMAND değişkeni aracılığıyla farklı bir SSH programına yönlendirirseniz, takma ad yalnızca o program da ~/.ssh/config dosyasını okuyorsa çalışır. HostName gerçek adrestir, User hesap adını yazma zahmetinden kurtarır ve IdentityFile hangi anahtarın sunulacağını sabitler.

IdentitiesOnly yes, kafa karıştırıcı bir hatayı düzelttiği için özel bir ilgiyi hak eder. Agent'ınızda birden fazla anahtar olduğ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ırsınız. IdentitiesOnly yes, istemcinin yalnızca IdentityFile içinde belirtilen anahtarı sunmasını sağlar, böylece bu hata oluşmaz.

Parolalar ve ssh-agent

Parola, disk üzerindeki özel anahtar dosyasını şifreler. Parola kullanılmadığında, dosyayı kopyalayan herkes anahtarı hemen kullanabilir; parola kullanıldığında ise çalınan dosya, parola tahmin edilene kadar işlevsiz kalır. Dizüstü bilgisayarlar çalınabildiği ve yedekleri sızdırılabildiği için, bu tür cihazlardaki anahtarlar için tam olarak ihtiyaç duyulan koruma budur.

Parolanın pratikte hiçbir maliyetinin olmamasının nedeni ssh-agent aracıdır. Agent, şifresi çözülmüş anahtarınızı bellekte tutar; böylece parolayı her oturum açılışında bir kez girersiniz 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 komutu, agent içinde o an yüklü olan anahtarları listeler. Bir uyarı: agent yönlendirme (ssh -A) özelliği, uzak sunucunun siz bağlıyken kimlik doğrulaması yapmak için agent'ınızı kullanmasına izin verir. Bu nedenle, bu özelliği yalnızca tamamen güvendiğiniz sunucular için etkinleştirin ve varsayılan olarak kapalı tutun.

Anahtar rotasyonu ve iptali: kayıp dizüstü bilgisayar senaryosu

Düz bir SSH anahtarını iptal etmek, anahtarın bulunduğu her sunucuda authorized_keys dosyasındaki ilgili satırı silmekten ibarettir. Bildirilmesi gereken bir sertifika yetkilisi veya beklenmesi gereken bir son kullanma tarihi yoktur. Satır silindiği anda, o anahtarla yapılan yeni oturum açma girişimleri başarısız olur.

Bu tatbikatı acil bir durum yokken şimdi gerçekleştirin. Bir sunucu seçin, ~/.ssh/authorized_keys dosyasını açın ve anahtarı yorum satırındaki açıklamasından bulun. Satırı bir metin düzenleyici ile silin veya açıklama kısmına göre filtreleyerek kaldırın:

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

Ardından, erişimini iptal ettiğiniz cihazdan oturum açmanın başarısız olduğunu ve başka bir cihazdan oturum açmanın hâlâ çalıştığını doğrulayın. Şu detaya dikkat edin: bir anahtarı silmek, hâlihazırda açık olan oturumları sonlandırmaz; çünkü anahtar kontrolü yalnızca oturum açma sırasında yapılır. Eğer çalınan bir cihazın erişimini iptal ediyorsanız, sunucuda who komutunu çalıştırarak kontrol edin ve tanımadığınız tüm oturumları sonlandırın.

Rotasyon, 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 oturum açabildiğini doğrulayın ve ardından eski satırı silin. Bu işlemi bir cihaz el değiştirdiğinde, bir anahtarın ifşa olmuş olabileceği durumlarda veya bir ekip üyesi ayrıldığında gerçekleştirin. Bu işlemi iki sunucuda elle yapmak sorun değildir; ancak yirmi sunucuda bu bir otomasyon işidir ve birden fazla Linux sunucusunu yönetme rehberi, aynı authorized_keys durumunu tüm bir sunucu filosuna nasıl dağıtacağınızı gösterir.

Yapılmaması gerekenler

• Tek bir özel anahtarı tüm cihazlarınızda paylaşmayın. Bu durum, çalınan tek bir cihazın anahtarını, her yerden değiştirmeden iptal etmeyi imkansız hale getirir.

• Özel bir anahtarı, gizli olsa bile bir git deposuna işlemeyin. Otomatik tarayıcılar herkese açık depoları izler ve sızdırılan anahtarları push işleminden dakikalar sonra dener; daha sonra herkese açık hale getirilen bir depo ise tüm geçmişini sızdırır.

• Bir sunucunun başka bir sunucuya erişebilmesi için dizüstü bilgisayarınızın özel anahtarını sunucuya yüklemeyin. Sunucunun üzerinde ayrı bir anahtar oluşturun ve bu anahtarı yalnızca gerekli olduğu yerde yetkilendirin.

• Özel bir anahtarı sohbet uygulamalarına, e-postalara veya destek taleplerine yapıştırmayın. Paylaşılabilecek tek kısım, .pub dosyası olan açık anahtardır.

Anahtarınız sizi güvenilir bir şekilde sisteme giriş yaptırdığında, bir sonraki adımı atın ve parola kimlik doğrulamasını kapatın; böylece sunucunuza yönelik sürekli tahmin denemeleri hiçbir şekilde başarılı olamaz. Bunun için gereken yapılandırma VPS üzerinde SSH sıkılaştırma bölümünde yer almaktadır.

FAQ

SSH anahtarları parola göndermeden nasıl çalışır?

Sunucu, açık anahtarınızı ~/.ssh/authorized_keys dosyasında tutar. Giriş sırasında sunucu bir sınama (challenge) gönderir, istemciniz bu sınamayı özel anahtar ile imzalar ve sunucu imzayı açık anahtar ile doğrular. Özel anahtar cihazınızdan asla ayrılmaz, bu nedenle iletim sırasında ele geçirilecek veya sunucudan çalınarak tekrar kullanılabilecek bir veri yoktur. Güvenliği ihlal edilmiş bir sunucu yalnızca açık anahtarları sızdırır; bu anahtarlar ise herhangi bir yere giriş yapmak için kullanılamaz.

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

Tek bir anahtarın tek bir cihazda kalması koşuluyla, birçok sunucuda aynı anahtarı kullanmak doğrudur. Kural sunucu başına bir anahtar değil, cihaz başına bir anahtardır: dizüstü bilgisayarınızın açık anahtarı, dizüstü bilgisayarın erişmesi gereken her sunucuya eklenir; masaüstü bilgisayarınızın ise kendi anahtarı olur. Bu yöntem iptal işlemlerini basitleştirir; bir cihaz kaybedildiğinde her sunucudan ilgili tek bir satırı silmek yeterlidir ve diğer cihazlar çalışmaya devam eder.

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

~/.ssh dizini için 700, authorized_keys dosyası ve tüm özel anahtarlar için 600 izinlerini ayarlayın ve bu dosyaların sahibi olarak ilgili kullanıcı hesabını atayın. sshd varsayılan olarak StrictModes yes ile çalışır; bu nedenle sizden başka birinin yazma yetkisi olan bir dosya veya ev dizini, anahtarınızın sessizce göz ardı edilmesine neden olur. Bunun tek izi, sunucunun kimlik doğrulama günlüğünde veya journal kayıtlarında bulunan Authentication refused: bad ownership or modes hatasıdır.

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

Anahtarın yetkilendirildiği hesaptaki ~/.ssh/authorized_keys dosyasından ilgili satırı silin. Doğru satırı bulmak için anahtar verisinden sonra gelen etiket olan açıklamayı kullanın. Bu anahtarla yapılan yeni giriş denemeleri derhal başarısız olur, ancak halihazırda açık olan oturumlar açık kalmaya devam eder; bu nedenle cihaz çalındıysa mevcut oturumları da sonlandırın. İşlemi anahtarın kopyalandığı her sunucuda tekrarlayın.

SSH anahtarımda bir parola (passphrase) kullanmalı mıyım?

Dizüstü veya masaüstü bilgisayardaki bir anahtar için evet. Parola, anahtar dosyasını şifreler; böylece çalınan veya sızdırılan bir kopya tek başına işe yaramaz hale gelir. ssh-agent kullanımı sayesinde parolayı her bağlantıda değil, oturum başına bir kez girersiniz. Sunucuda gözetimsiz otomasyon tarafından kullanılan anahtarlar genellikle parola içermez, çünkü parolayı girecek bir insan yoktur; bu tür anahtarları hedef hesabın yetkilerini kısıtlayarak koruyun.