SSH Anahtarı ile Giriş ve Sunucuda Şifreyi Tamamen Kapatma

auth.log'u açtınız ve üç farklı kıtadan 22 numaralı porta giriş denemeleri yapıldığını görüyorsunuz. Ya da daha kötüsü: Failed password yığınının ortasında bir Accepted password for root oturuyor. Hâlâ şifreyle giriş yapıyorsanız, sorun "eğer" değil, "ne zaman"dır. SSH anahtarı ile giriş bu saldırı yüzeyini neredeyse sıfıra indirir, yeter ki doğru yapın ve şifreyi kapatmadan önce kendinize bir kaçış yolu açın.

Her şeyden önce: yedek bir oturum açık tutun

Bunu ciddiye alın. İkinci bir SSH terminali açın, giriş yapın ve iş bitene kadar kapatmayın. sshd_config'i bozarsanız ve mevcut oturumunuz kesilirse, hostingin KVM konsolu dışında geri dönüş yolunuz kalmaz. Sunucu yöneticisinin systemctl restart sshd sonrası kendini dışarı attığını ve sabaha kadar ticket yanıtı beklediğini defalarca gördüm.

Herhangi bir değişiklikten önce yapılandırma dosyasının yedeğini alın:

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak-$(date +%F)

SSH anahtarı oluşturma: hangi algoritma ve neden

Sunucuda değil, kendi sisteminizde çalıştırın:

ssh-keygen -t ed25519 -a 100 -C "ali@laptop-1403"

-a 100 seçeneği, özel anahtarın passphrase'ini korumak için KDF tur sayısını artırır. ed25519'u desteklemeyen eski bir sisteminiz varsa, -t rsa -b 4096 kullanın. Artık RSA 2048 oluşturmayın; pratikte henüz kırılmadı, ancak güvenlik marjı o kadar azaldı ki risk almaya değmez.

Özel anahtarın passphrase'i konusunda ısrarcıyım. Passphrase'siz anahtar, ~/.ssh/id_ed25519 dosyasını alan herkesin tam olarak sizin erişiminize sahip olması demektir. ssh-agent ile günde bir kez girersiniz ve günün geri kalanında rahatça çalışırsınız.

Açık anahtarı sunucuya aktarma

En basit yol:

ssh-copy-id -i ~/.ssh/id_ed25519.pub ali@server-ip

Sunucu varsayılan olmayan bir porttaysa, -p 2222 ekleyin. ssh-copy-id yoksa, manuel yapın:

cat ~/.ssh/id_ed25519.pub | ssh ali@server-ip "mkdir -p ~/.ssh && chmod 700 ~/.ssh && cat >> ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys"

İzinler burada hayatidir. ~/.ssh 755 iznine sahipse veya authorized_keys group tarafından yazılabilirse, sshd anahtarı sessizce reddeder. Sessizce. Yani logda Authentication refused: bad ownership or modes dışında bir şey görmezsiniz ki çoğu kişi bunu gözden kaçırır.

Yalnızca SSH anahtarı ile giriş için sshd_config yapılandırması

Şimdi ana dosyaya geçin. Bu satırları /etc/ssh/sshd_config içinde ayarlayın:

PubkeyAuthentication yes
PasswordAuthentication no
PermitRootLogin prohibit-password
ChallengeResponseAuthentication no
UsePAM yes
AllowUsers ali deploy
MaxAuthTries 3
LoginGraceTime 20

Çoğu kişinin yanlış anladığı nokta: PermitRootLogin no ile prohibit-password karıştırılır. Birincisi root girişini tamamen kapatır, ikincisi yalnızca root şifresini kapatır ve anahtara izin verir. Root anahtarınız varsa ve onu kullanmak istiyorsanız, prohibit-password koyun. Yoksa, no koyun ve sudo ile normal bir kullanıcıdan çalışın.

AllowUsers'ı hafife almayın. O olmadan, geçerli shell'e sahip her sistem kullanıcısı giriş denemesi yapabilir. Onunla, yalnızca yazdığınız iki isim izinlidir.

Restart'tan önce yapılandırmayı test edin

sshd -t

Çıktı boşsa, yapılandırma sağlıklıdır. Hata verirse, orada düzeltin. Sonra:

systemctl reload sshd

restart değil reload kullanın. reload aktif oturumları kesmez. Şimdi açık tuttuğunuz o ikinci terminalde yeni bir oturum açın. Anahtarla girdiyseniz, ilk terminali kapatın ve sonraki işe geçin.

Burada hata yapıyorlar: anahtarı test etmeden şifreyi kapatmak

Tekrarlayan kalıp şudur: yönetici PasswordAuthentication no ayarlar, reload yapar, mevcut oturumu kesilmez, rahatlar ve gider. Ertesi sabah bağlanmak istediğinde Permission denied (publickey) alır. Nedeni genellikle şu üçünden biridir: anahtar yanlış kullanıcının authorized_keys dosyasındadır, dosya izinleri bozuktur veya AllowUsers kullanıcı adını atlamıştır. Her üç durumda da hata mesajı aynıdır ve yardımcı olmaz.

Teşhis yolu: sunucuda journalctl -u ssh -f açın ve başka bir sistemden bağlanın. userauth_pubkey: key type ssh-ed25519 not in PubkeyAcceptedAlgorithms veya Authentication refused: bad ownership or modes satırı tam olarak nereyi düzeltmeniz gerektiğini söyler.

Kaçış yolu: kendinizi dışarı attıysanız

İlk yapacağınız şey, hostingin acil konsolundan giriş yapmaktır. O da yoksa, hâlâ erişimi olan başka bir kullanıcıdan yararlanın. Hiçbiri yoksa, sunucunun rescue veya acil önyükleme modunu kullanıp diski mount etmeniz gerekir.

Geri döndüğünüzde, şu sırayı izleyin:

1. PasswordAuthentication yes'i geçici olarak geri alın ve reload yapın.
2. Şifreyle giriş yapın ve anahtar sorununu kökten çözün.
3. Şifreyi tekrar kapatın ve bu sefer başka bir sistemden test edin.

Pratik bir not: şifreyi kapatmadan önce, her zaman ayrı anahtarla ikinci bir kullanıcı oluşturun. Ana anahtarınız kaybolursa veya passphrase'i unutursanız, o ikinci kullanıcı sizi kurtarır. Bu beş dakika sürer ve bir uykusuz geceyi ortadan kaldırır.

Sonraki katmanlar: fail2ban ve port kısıtlaması

Şifreyi kapatmak brute-force saldırılarını etkisiz kılar ama logları doldurur ve bant genişliği tüketir. SSH güvenliği; port değiştirmekten fail2ban ve açık anahtara bakın ve sshd için basit bir jail kurun:

[sshd]
enabled = true
port = 22
maxretry = 3
bantime = 3600

Portu değiştirmek tek başına güvenlik değildir, yalnızca gürültüyü azaltır. Sunucuyu hedef alan kişi portu bulur. Ancak loglarınız giriş denemeleriyle doluysa ve sinyali gürültüden ayırmak istiyorsanız, buna değer.

Sunucu yoğun kötü niyetli trafik arkasındaysa, herhangi bir ayardan önce ağ katmanının da kapsandığından emin olun. DDoS koruması ServerNet bu katmanı bulut hizmetleri için kapsar ve kesinti olmadan SSH ayarlarını uygulamanıza izin verir.

Anahtarı nerede tutmamalıyız

Özel anahtar sunucuda kalmaz. Ne /root/.ssh içinde, ne proje klasöründe, ne de Git deposunda. Sunucudan sunucuya deploy için bağlanıyorsanız, anahtarı aynı kaynakta tutun ve ssh-agent forwarding ile çalışın. Ekibiniz varsa, Ekiplerde şifre yönetimi; sohbette paylaşım neden yasaktır? okuyun; aynı mantık anahtarlar için de geçerlidir.

Kimin, ne zaman ve nereden girdiğini anlamak için logları dokunulmamış halde tutun. Denetim günlüğü nedir ve nasıl dokunulmamış halde tutarız? tam olarak bu konuyu açıyor ve "bunu kim yaptı" sorusunu yanıtlamak için hayatidir.

Şifreyi kapatmadan önce son kontrol listesi

Tüm satırlar yeşilse, PasswordAuthentication no ayarlayın, sshd -t çalıştırın, reload yapın ve başka bir sistemden test edin. Test başarılıysa, yedek terminali kapatın ve fail2ban'a geçin.

Sık sorulan sorular

Şifreyi kapattıktan sonra neden hâlâ Permission denied (publickey) mesajı alıyorum?

Vakaların yüzde doksanında sorun anahtarın kendisi değil, dosya izinleridir. sshd, ~/.ssh 700 iznine sahip değilse veya authorized_keys başkaları tarafından yazılabilirse, anahtarı sessizce reddeder. Giriş denemesiyle eşzamanlı olarak journalctl -u ssh -f ile tam mesajı görün.

İkinci durum, anahtarın yanlış kullanıcının authorized_keys dosyasına yerleşmiş olmasıdır. ssh ali@server ile bağlanıyorsanız, anahtar /home/ali/.ssh/authorized_keys içinde olmalıdır, /root/.ssh içinde değil.

SSH portunu değiştirmek tek başına güvenliği artırır mı?

Hayır. Portu değiştirmek yalnızca otomatik taramaların hacmini azaltır ve logları okunabilir tutar. Sunucuyu hedef alan kişi basit bir tarama ile yeni portu bulur. Gerçek güvenlik açık anahtardan, şifreyi kapatmaktan ve izinli kullanıcıları kısıtlamaktan gelir.

Portu değiştirdiyseniz, güvenlik duvarında ve fail2ban içinde de aynı portu ayarlamayı unutmayın, yoksa yeniden başlatma sonrası erişiminiz kesilir.

Özel anahtarı güvenli kalması için nerede tutmalıyım?

Kendi sisteminizde, ~/.ssh içinde 600 izniyle ve her zaman passphrase ile. Özel anahtarın şifrelenmiş bir yedeğini alın ve dizüstü bilgisayardan ayrı tutun. Özel anahtar asla hedef sunucuda kalmaz ve asla Git deposuna konmaz.

Anahtar sızdıysa, onu authorized_keys'den silmek yeterli değildir; yeni bir anahtar oluşturmalı ve eski anahtarı erişimi olan tüm sunuculardan kaldırmalısınız.

Birinin benim anahtarımla sunucuya girdiğini nasıl anlarım?

/var/log/auth.log içinde veya journalctl -u ssh çıktısında Accepted publickey for satırını arayın. Her satır kullanıcı adını, anahtar parmak izini ve kaynak IP'yi içerir. Bilinmeyen bir IP görürseniz, anahtarı derhal authorized_keys'den kaldırın.

Bu logların sonradan delil olarak kullanılabilmesi için dokunulmamış ve sunucudan ayrı olarak saklanması gerekir. Sunucuyu kaybederseniz, o sunucudaki loglar da kaybolur.