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 ssh-keygen -t rsa -b 4096 seçeneğine dönün. -C "laptop" bir açıklama belirler. Açıklamanın kriptografik bir işlevi yoktur, ancak iki yıl sonra bir sunucunun authorized_keys dosyasında bu anahtarı nasıl tanıyacağınızı belirler; bu nedenle anahtarın bulunduğu cihaza bir isim verin.

ssh-keygen anahtarın nereye kaydedileceğini sorar. Varsayılan olan ~/.ssh/id_ed25519 değerini 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 kısmına bakın:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

Bu tek bir satırdır: 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 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 isim atamanızı 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 komutu ssh -p 22 matt@10.0.0.10 yerine kullanılabilir; aynı kısa isim scp, rsync ve git içerisinde de çalışır çünkü bu araçların hepsi aynı dosyayı okur. HostName gerçek adresi belirtir, User kullanıcı adını yazma zahmetinden kurtarır ve IdentityFile hangi anahtarın sunulacağını sabitler.

IdentitiesOnly yes seçeneği ayrı bir açıklamayı hak eder çünkü kafa karıştırıcı bir hatayı düzeltir. Agent içerisinde birden fazla anahtar yüklü olduğunda, istemci bunları sırayla sunar ve sunucu her denemeyi başarısız bir girişim olarak sayar. Yeterince anahtar yüklüyse, doğru anahtar denenmeden önce Received disconnect: Too many authentication failures hatası alırsınız. IdentitiesOnly yes, istemcinin yalnızca IdentityFile içerisinde 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 tatbikatı

Standart bir SSH anahtarını iptal etmek, anahtarın bulunduğu her sunucudaki authorized_keys dosyasından ilgili satırı silmekten ibarettir. Bildirimde bulunulacak bir sertifika otoritesi veya beklenmesi gereken bir son kullanma tarihi yoktur. Satır silindiği anda, bu anahtarla yapılan yeni giriş denemeleri 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ından bulun. Satırı bir metin düzenleyici ile silin veya yorum satırı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 girişin başarısız olduğunu, başka bir cihazdan ise girişin hala çalıştığını doğrulayın. Önemli bir detayı unutmayın: bir anahtarı silmek halihazırda açık olan oturumları sonlandırmaz, çünkü anahtar kontrolü yalnızca giriş sırasında yapılır. Eğer çalınan bir cihazın erişimini iptal ediyorsanız, sunucudaki who dosyasını da kontrol edin ve tanımadığınız tüm oturumları sonlandırın.

Anahtar rotasyonu, 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ş yapabildiğini doğrulayın ve ardından eski satırı silin. Bu işlemi cihaz el değiştirdiğinde, anahtarın açığa çıkmış olabileceği durumlarda veya bir ekip üyesi ayrıldığında yapın. İki sunucu için bu işlemi manuel yapmak uygundur; yirmi sunucu için ise bu bir otomasyon işidir ve birden fazla Linux sunucusunu yönetme rehberi, aynı authorized_keys durumunu tüm 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.