Linux sunucuların uzaktan yönetiminde en yaygın kullanılan protokollerden biri SSH (Secure Shell)‘dir. SSH sayesinde sistem yöneticileri fiziksel olarak sunucunun başında bulunmadan güvenli bir bağlantı üzerinden komut çalıştırabilir, sistem yönetebilir ve scp veya sftp gibi araçlarla dosya transferi gerçekleştirebilir.

SSH bağlantısında taşınan veriler şifrelenir. Bu sayede kullanıcı bilgileri, komutlar ve transfer edilen verilerin ağ trafiğini dinleyen kişiler tarafından doğrudan okunması engellenir. Ancak SSH protokolünün şifreli olması, varsayılan SSH yapılandırmasının her ortam için yeterince güvenli olduğu anlamına gelmez.

Özellikle internete veya geniş yönetim ağlarına açık sunucularda;

• parola tabanlı SSH erişimi,
• doğrudan root kullanıcısıyla bağlantı,
• eski kriptografik algoritmalar,
• kontrolsüz kullanıcı erişimi,
• korunmayan private key’ler

önemli güvenlik riskleri oluşturabilir.

Bu nedenle SSH servisinin yalnızca çalışıyor olması değil, güvenli şekilde yapılandırılması gerekir. Bu işleme genel olarak SSH Hardening adı verilir.

Bu makalede SSH servisinin güvenliğini adım adım artıracağız.

1. SSH Hardening Nedir?

SSH Hardening, SSH servisinin saldırı yüzeyini azaltmak amacıyla yapılan güvenlik yapılandırmalarının tamamıdır.

Temel amaç, SSH sunucusuna yalnızca gerçekten yetkili kullanıcıların, güvenli kimlik doğrulama yöntemleri ve güçlü kriptografik algoritmalar kullanarak bağlanabilmesini sağlamaktır.

SSH hardening sürecinde özellikle şu konular değerlendirilmelidir:

• Eski SSH protokollerinin kullanılmaması
• SSH key authentication kullanılması
• Private key’lerin korunması
• Root kullanıcısının SSH erişiminin kapatılması
• Kullanıcı adı ve parola ile girişin devre dışı bırakılması
• Güçlü şifreleme algoritmalarının kullanılması
• Güvenli Key Exchange algoritmalarının tercih edilmesi
• Güvenli MAC algoritmalarının kullanılması
• SSH yapılandırmasının uygulanmadan önce test edilmesi
• Etkin SSH ayarlarının doğrulanması

Kaynak içerikte de SSH hardening kapsamında root erişiminin kapatılması, parola ile girişin devre dışı bırakılması, güçlü şifreleme algoritmaları, erişim kontrolleri, loglama ve kullanıcı bazlı yapılandırmalar gibi konuların birlikte ele alınması gerektiği belirtilmektedir.

2. SSH Yapılandırma Dosyası

OpenSSH sunucu tarafındaki temel yapılandırma dosyası genellikle:

/etc/ssh/sshd_config

dosyasıdır.

Dosyayı düzenlemek için örneğin:

sudo nano /etc/ssh/sshd_config

veya:

sudo vi /etc/ssh/sshd_config

kullanılabilir.

Bazı modern Linux dağıtımlarında ek SSH yapılandırmaları:

/etc/ssh/sshd_config.d/

dizini altında da bulunabilir.

Bu nedenle yalnızca ana yapılandırma dosyasına bakmak yerine etkin SSH yapılandırmasının ayrıca kontrol edilmesi önemlidir.

Bunun için ilerleyen bölümlerde kullanacağımız en önemli komutlardan biri:

sudo sshd -T

olacaktır.

3. SSH Hardening Yaparken Kendinizi Sunucudan Kilitlemeyin

SSH güvenliğini artırırken yapılabilecek en kritik hatalardan biri, yeni authentication yönteminin çalıştığı doğrulanmadan parola veya root erişiminin kapatılmasıdır.

Örneğin doğrudan:

PermitRootLogin no
PasswordAuthentication no

ayarlarını uyguladığınızı düşünelim.

Eğer normal yönetici kullanıcınızın SSH public key yapılandırması doğru değilse sunucuya yeniden bağlanamayabilirsiniz.

Bu nedenle işlemler şu sırayla gerçekleştirilmelidir:

1. Root dışında normal bir yönetici hesabının bulunduğundan emin olun.
2. Kullanıcının gerektiğinde sudo kullanabildiğini kontrol edin.
3. Kullanıcı için SSH key oluşturun.
4. Public key’i sunucuya aktarın.
5. SSH key kullanarak yeni bir terminalden bağlantıyı test edin.
6. Root SSH erişimini kapatın.
7. Password Authentication’ı kapatın.
8. SSH yapılandırmasını syntax açısından kontrol edin.
9. SSH servisini reload edin.
10. Mevcut bağlantıyı kapatmadan yeni bir SSH oturumu açarak tekrar test edin.

Yeni bağlantının başarılı olduğunu doğrulamadan mevcut SSH oturumunuzu kapatmayın.

4. SSH Protocol Version 1 Kullanılmamalıdır

SSH’nin eski protokolü olan SSH Version 1, ciddi güvenlik problemlerine sahip olduğundan kullanılmamalıdır.

Eski sistemlerde aşağıdaki gibi yapılandırmalarla karşılaşılabilir:

Protocol 1

veya:

Protocol 1,2

Bu tarz bir yapılandırma görülüyorsa sistemin gözden geçirilmesi gerekir.

Modern OpenSSH sürümlerinde SSH Version 1 desteği zaten kaldırılmış veya devre dışı bırakılmış durumdadır. Ancak özellikle eski sistemlerin bulunduğu ortamlarda bu kontrol önemlidir. Kaynak doküman da SSH Version 1’in ciddi güvenlik kusurları nedeniyle kullanılmaması gerektiğine dikkat çekmektedir.

5. Parola Yerine SSH Key Authentication Kullanmak

SSH bağlantılarında klasik yöntem kullanıcı adı ve parola kullanmaktır.

Örneğin:

ssh sysadmin@192.168.1.100

Bağlantı sırasında:

sysadmin@192.168.1.100's password:

şeklinde parola istenir.

SSH parolayı şifreli kanal içerisinde iletir. Ancak güvenlik problemi, parolanın ağ üzerinde açık gönderilmesi değil, saldırganlar tarafından tahmin edilebilir olmasıdır.

SSH servisi internete açıksa otomatik botlar sürekli olarak;

• kullanıcı adları,
• yaygın parolalar,
• ele geçirilmiş parola listeleri,
• brute-force kombinasyonları

deneyebilir.

Kaynak dokümanda da SSH kullanıcı adı/parola erişiminin botnet ve brute-force saldırılarının hedefi olabileceği, özellikle root hesabına parola ile erişimin ciddi risk oluşturduğu belirtilmektedir.

Bu nedenle SSH erişiminde mümkün olduğunda public/private key authentication kullanılmalıdır.

6. SSH Public Key Authentication Nasıl Çalışır?

SSH key authentication iki temel dosyaya dayanır:

Private Key

Private key istemci bilgisayarında bulunur.

Örneğin:

~/.ssh/id_ed25519

veya:

~/.ssh/id_rsa

Private key gizli tutulmalıdır.

Başka kişilerle paylaşılmamalı ve mümkünse güçlü bir passphrase ile korunmalıdır.

Public Key

Public key bağlantı gerçekleştirilecek SSH sunucusuna aktarılır.

Örneğin:

~/.ssh/id_ed25519.pub

Public key’in uzak sunucuda bulunması güvenlik problemi oluşturmaz.

Önemli kural oldukça basittir:

Private key kullanıcıda kalır. Public key sunucuya aktarılır.

Kaynak dokümanda da private key dosyasının yalnızca sahibi tarafından okunması, public key’in ise uzak sunuculara authentication amacıyla aktarılması gerektiği gösterilmektedir.

7. SSH Key Oluşturma

SSH key oluşturmak için:

ssh-keygen

komutu kullanılır.

Ancak kullanılacak algoritmayı ayrıca belirlemek daha kontrollü bir yöntemdir.

Günümüzde yaygın olarak:

• Ed25519
• RSA
• bazı ortamlarda ECDSA

kullanılmaktadır.

8. Ed25519 SSH Key Oluşturma

Modern sistemlerde kullanılabilecek seçeneklerden biri Ed25519’dur.

Anahtar oluşturmak için:

ssh-keygen -t ed25519

komutu çalıştırılır.

Örneğin:

Generating public/private ed25519 key pair.

Enter file in which to save the key:
/home/sysadmin/.ssh/id_ed25519

Enter passphrase:

Anahtar oluşturulduğunda:

ls -la ~/.ssh/

ile dosyalar görüntülenebilir.

Genellikle:

id_ed25519
id_ed25519.pub

oluşur.

Burada:

id_ed25519

private key,

id_ed25519.pub

ise public key’dir.

Kaynak içerikte de Ed25519 anahtarlarının ssh-keygen -t ed25519 komutuyla oluşturulabileceği gösterilmektedir.

9. RSA SSH Key Oluşturma

Uyumluluk veya kurumsal güvenlik politikaları nedeniyle RSA kullanılması gerekiyorsa örneğin 3072-bit RSA anahtarı oluşturulabilir:

ssh-keygen -t rsa -b 3072

Burada:

-t rsa

anahtar algoritmasını,

-b 3072

ise RSA anahtar uzunluğunu belirtir.

Kaynak dokümanda da 3072-bit RSA anahtarı aynı yöntemle oluşturulmaktadır.

10. Private Key İçin Passphrase Kullanılmalı mı?

Evet, özellikle kullanıcı cihazlarında tutulan SSH private key’lerinin passphrase ile korunması iyi bir güvenlik uygulamasıdır.

Anahtar oluşturulurken:

Enter passphrase:
Enter same passphrase again:

soruları görüntülenir.

Passphrase kullanıldığında saldırgan private key dosyasını ele geçirse bile anahtarı doğrudan kullanması zorlaşır.

Private key’in dosya izinleri de kontrol edilmelidir.

Örneğin:

ls -l ~/.ssh/id_ed25519

çıktısı:

-rw------- 1 sysadmin sysadmin ... id_ed25519

şeklinde olabilir.

Bu izin:

600

olarak ifade edilebilir.

Gerekirse:

chmod 600 ~/.ssh/id_ed25519

uygulanabilir.

11. Public Key’i Uzak Sunucuya Aktarmak

Public key’i Linux sunucuya aktarmanın en kolay yöntemlerinden biri:

ssh-copy-id

komutudur.

Örneğin:

ssh-copy-id sysadmin@192.168.1.100

İlk bağlantıda sunucunun fingerprint bilgisi sorulabilir:

The authenticity of host '192.168.1.100' can't be established.
Are you sure you want to continue connecting (yes/no)?

Sunucunun doğru sistem olduğundan emin olduktan sonra bağlantı onaylanabilir.

Public key uzak sunucudaki ilgili kullanıcının:

~/.ssh/authorized_keys

dosyasına eklenir.

Kaynak dokümanda da public key transferi için ssh-copy-id kullanılmış ve anahtarlar uzak CentOS sunucusuna aktarılmıştır.

12. SSH Key ile Bağlantıyı Test Etmek

Anahtar aktarıldıktan sonra:

ssh sysadmin@192.168.1.100

komutuyla bağlantıyı test edin.

Özel bir key kullanılacaksa:

ssh -i ~/.ssh/id_ed25519 sysadmin@192.168.1.100

kullanılabilir.

Kaynak dokümanda da belirli bir private key’i seçmek için -i parametresinin kullanılabileceği gösterilmektedir.

Bağlantı başarılı oluyorsa artık parola tabanlı SSH erişimini kapatmaya geçebiliriz.

13. ssh-agent Kullanımı

Private key passphrase ile korunuyorsa her SSH bağlantısında passphrase girilmesi gerekebilir.

Bunu kolaylaştırmak için ssh-agent kullanılabilir.

Örneğin:

eval "$(ssh-agent -s)"

ardından:

ssh-add ~/.ssh/id_ed25519

çalıştırılabilir.

Private key passphrase girildikten sonra anahtar mevcut kullanıcı oturumu için agent’a eklenir.

Agent içerisindeki anahtarları görmek için:

ssh-add -l

kullanılabilir.

Anahtarları agent’dan kaldırmak için:

ssh-add -D

kullanılabilir.

Kaynak dokümanda da ssh-agent ve ssh-add kullanılarak private key’lerin kullanıcı oturumunda yönetilebileceği gösterilmektedir.

14. Root Kullanıcısının SSH Erişimini Kapatmak

Linux sistemlerde root, sistem üzerindeki en yetkili kullanıcıdır.

Saldırgan açısından root hesabının avantajı kullanıcı adının zaten bilinmesidir.

Saldırganın:

root

kullanıcı adını keşfetmesine gerek yoktur.

Bu nedenle sistem yöneticilerinin doğrudan root kullanıcısıyla SSH bağlantısı kurması yerine:

Normal kullanıcı
      ↓
     SSH
      ↓
     sudo
      ↓
     root

modelinin kullanılması daha güvenli ve yönetilebilir bir yaklaşımdır.

Öncelikle normal kullanıcının sudo yetkisini test edin:

sudo whoami

Beklenen çıktı:

root

olmalıdır.

Yetkileri görmek için:

sudo -l

kullanılabilir.

15. PermitRootLogin Yapılandırması

SSH yapılandırmasını açın:

sudo nano /etc/ssh/sshd_config

Aşağıdaki satırı bulun veya ekleyin:

PermitRootLogin no

Bu yapılandırmayla:

ssh root@192.168.1.100

üzerinden doğrudan root bağlantısı engellenir.

Temel öneri:

PermitRootLogin no

şeklindedir.

Ancak bazı özel otomasyon sistemlerinde root hesabıyla public key tabanlı kontrollü erişim gerekebilir. Böyle durumlarda ilgili güvenlik politikası ayrıca değerlendirilmelidir.

Genel amaçlı sunucularda ise normal kullanıcı + sudo modeli tercih edilmelidir.

16. Password Authentication’ı Devre Dışı Bırakmak

SSH key authentication’ın başarılı şekilde çalıştığını doğruladıktan sonra parola tabanlı SSH bağlantısını kapatabiliriz.

sshd_config içerisinde:

PasswordAuthentication no

olarak yapılandırın.

Public key authentication’ın etkin olduğundan emin olmak için:

PubkeyAuthentication yes

kullanılabilir.

Temel yapılandırma şu şekilde olur:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no

Bu yapılandırmayla normal kullanıcılar SSH public key ile giriş yapabilir ancak klasik SSH kullanıcı parolasıyla bağlantı gerçekleştiremez.

17. Keyboard Interactive Authentication

SSH farklı authentication mekanizmalarını destekleyebilir.

Parola authentication kapalı olsa bile bazı yapılarda keyboard-interactive authentication kullanılabilir.

Key-only bir yapı hedefleniyorsa ve MFA, OTP veya PAM tabanlı özel bir authentication mekanizması kullanılmıyorsa:

KbdInteractiveAuthentication no

değerlendirilebilir.

Örneğin:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no

Ancak önemli bir nokta vardır:

Eğer sistemde;

• OTP,
• MFA,
• PAM authentication,
• Google Authenticator benzeri ikinci faktör sistemleri

kullanılıyorsa KbdInteractiveAuthentication gerekli olabilir.

Bu nedenle bu parametre körlemesine kapatılmamalıdır.

18. Empty Password Kullanımını Engellemek

Boş parolalı kullanıcıların SSH authentication gerçekleştirmesine izin verilmemelidir.

Bunun için:

PermitEmptyPasswords no

kullanılabilir.

Authentication bölümünün tamamı örneğin:

# SSH Authentication Hardening

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no

şeklinde olabilir.

19. SSH Güvenliği Yalnızca Authentication’dan İbaret Değildir

SSH bağlantısında authentication dışında kullanılan kriptografik algoritmalar da önemlidir.

Başlıca üç kategori bulunur:

Ciphers
KexAlgorithms
MACs

Bunların görevleri birbirinden farklıdır.

Ciphers

SSH bağlantısı içerisindeki verilerin şifrelenmesini sağlar.

KexAlgorithms

İstemci ve sunucunun oturum anahtarlarını güvenli biçimde oluşturmasını sağlayan Key Exchange algoritmalarıdır.

MACs

Aktarılan verilerin bütünlüğünü kontrol etmek için kullanılan Message Authentication Code algoritmalarıdır.

20. Desteklenen Cipher Algoritmalarını Görmek

SSH istemcisinin desteklediği cipher algoritmaları:

ssh -Q cipher

komutuyla görüntülenebilir.

Örneğin:

aes128-ctr
aes192-ctr
aes256-ctr
aes128-gcm@openssh.com
aes256-gcm@openssh.com
chacha20-poly1305@openssh.com

gibi algoritmalar görülebilir.

Ancak burada önemli bir ayrım vardır.

ssh -Q cipher

sistemin destekleyebildiği algoritmaları gösterir.

Sunucunun gerçekten aktif olarak kullandığı cipher listesini görmek için:

sudo sshd -T | grep ciphers

kullanılmalıdır.

21. Key Exchange Algoritmalarını Görmek

Desteklenen Key Exchange algoritmalarını görmek için:

ssh -Q kex

veya kullanılan OpenSSH sürümüne göre:

ssh -Q KexAlgorithms

kullanılabilir.

Sunucunun etkin KEX yapılandırmasını görmek için:

sudo sshd -T | grep kexalgorithms

kullanılır.

Eski sistemlerde:

diffie-hellman-group1-sha1

gibi legacy algoritmalarla karşılaşılabilir.

Yeni sistemlerde gerekmiyorsa bu tür eski algoritmaları yeniden etkinleştirmekten kaçınılmalıdır.

22. MAC Algoritmalarını Kontrol Etmek

Desteklenen MAC algoritmaları:

ssh -Q mac

ile görüntülenebilir.

Sunucunun kullandığı MAC yapılandırması:

sudo sshd -T | grep macs

ile kontrol edilebilir.

Örneğin modern sistemlerde:

hmac-sha2-256-etm@openssh.com
hmac-sha2-512-etm@openssh.com

gibi algoritmalar görülebilir.

23. Cipher Listesini Manuel Tanımlamak Gerekli mi?

Eski SSH hardening rehberlerinde sık sık uzun Ciphers, MACs ve KexAlgorithms listeleri görülür.

Örneğin:

Ciphers aes256-gcm@openssh.com,aes128-gcm@openssh.com,chacha20-poly1305@openssh.com

gibi.

Teknik olarak algoritmaları açıkça sınırlandırmak mümkündür.

Ancak burada dikkat edilmesi gereken önemli bir nokta vardır.

Modern OpenSSH sürümleri güvenli algoritma listelerini güncellemelerle birlikte geliştirmektedir. Algoritmaların elle sabitlenmesi durumunda gelecekte OpenSSH tarafından eklenen daha güvenli algoritmalar otomatik olarak kullanılamayabilir.

Bu nedenle özel bir;

• CIS Benchmark,
• STIG,
• PCI DSS,
• FIPS,
• kurum güvenlik politikası

gereksinimi yoksa öncelikle sistemin güncel OpenSSH varsayılanlarının incelenmesi daha sağlıklı bir yaklaşımdır.

Önce mevcut yapılandırmayı görün:

sudo sshd -T | grep ciphers

sudo sshd -T | grep macs

sudo sshd -T | grep kexalgorithms

Daha sonra gerçekten zayıf veya kurum politikasına aykırı algoritmalar bulunuyorsa müdahale edin.

24. OpenSSH Sürümünü Kontrol Etmek

Kullanılan OpenSSH sürümünü görmek için:

ssh -V

çalıştırılabilir.

Örneğin:

OpenSSH_9.x

gibi bir çıktı alınabilir.

Sunucu paket bilgisi dağıtıma göre ayrıca kontrol edilebilir.

RHEL/Rocky/AlmaLinux:

rpm -qa | grep openssh

Ubuntu/Debian:

dpkg -l | grep openssh

Güçlü cipher yapılandırması kadar OpenSSH paketlerinin güncel tutulması da önemlidir.

25. SSH Yapılandırmasını Uygulamadan Önce Test Etmek

SSH servisinde değişiklik yaptıktan sonra doğrudan restart yapmak yerine önce syntax kontrolü gerçekleştirilmelidir.

Bunun için:

sudo sshd -t

komutu kullanılır.

Komut herhangi bir çıktı üretmezse genellikle syntax hatası bulunmamaktadır.

Hata varsa örneğin:

/etc/ssh/sshd_config line 45: Bad configuration option

şeklinde bir mesaj alınabilir.

Bu durumda SSH servisini reload veya restart etmeden önce hata düzeltilmelidir.

26. Gerçekte Hangi SSH Ayarlarının Kullanıldığını Görmek

En kullanışlı OpenSSH kontrol komutlarından biri:

sudo sshd -T

komutudur.

Bu komut efektif SSH sunucu yapılandırmasını gösterir.

Root erişimini kontrol etmek için:

sudo sshd -T | grep permitrootlogin

Beklenen:

permitrootlogin no

Password Authentication:

sudo sshd -T | grep passwordauthentication

Beklenen:

passwordauthentication no

Public Key Authentication:

sudo sshd -T | grep pubkeyauthentication

Beklenen:

pubkeyauthentication yes

Keyboard Interactive:

sudo sshd -T | grep kbdinteractiveauthentication

Cipher:

sudo sshd -T | grep ciphers

MAC:

sudo sshd -T | grep macs

Key Exchange:

sudo sshd -T | grep kexalgorithms

Bu kontroller özellikle /etc/ssh/sshd_config.d/ altında ek yapılandırmalar bulunan sunucularda oldukça önemlidir.

27. SSH Servisini Güvenli Şekilde Reload Etmek

Yapılandırma kontrolünden sonra SSH servisinin reload edilmesi tercih edilebilir.

RHEL, Rocky Linux, AlmaLinux gibi sistemlerde:

sudo systemctl reload sshd

Ubuntu/Debian sistemlerinde:

sudo systemctl reload ssh

kullanılabilir.

Servisin durumunu görmek için:

sudo systemctl status sshd

veya:

sudo systemctl status ssh

kullanılabilir.

28. Yeni Yapılandırmayı Mutlaka Ayrı Terminalden Test Edin

Mevcut SSH bağlantınızı açık bırakın.

İkinci bir terminal açarak:

ssh sysadmin@192.168.1.100

bağlantısını deneyin.

Public key authentication başarılı olmalıdır.

Daha detaylı SSH bağlantı çıktısı görmek için:

ssh -v sysadmin@192.168.1.100

kullanılabilir.

Daha fazla debug bilgisi için:

ssh -vvv sysadmin@192.168.1.100

çalıştırılabilir.

29. Password Authentication’ın Gerçekten Kapandığını Test Etmek

İstemci tarafında public key authentication’ı devre dışı bırakarak test yapılabilir:

ssh -o PubkeyAuthentication=no sysadmin@192.168.1.100

Eğer:

PasswordAuthentication no

doğru şekilde uygulanmışsa klasik kullanıcı parolasıyla bağlantının başarılı olmaması gerekir.

Root bağlantısı da:

ssh root@192.168.1.100

ile test edilebilir.

PermitRootLogin no uygulanmışsa root kullanıcısının SSH bağlantısı reddedilmelidir.

30. Örnek SSH Hardening Yapılandırması

Temel bir SSH authentication hardening bölümü aşağıdaki gibi hazırlanabilir:

# =====================================================
# SSH Authentication Hardening
# =====================================================

# Root kullanıcısının SSH erişimini kapat
PermitRootLogin no

# Public Key Authentication kullan
PubkeyAuthentication yes

# Parola ile SSH bağlantısını kapat
PasswordAuthentication no

# MFA/PAM kullanılmıyorsa değerlendirilebilir
KbdInteractiveAuthentication no

# Boş parolalara izin verme
PermitEmptyPasswords no

Buna temel bağlantı güvenliği ayarları da eklenebilir:

# =====================================================
# SSH Connection Security
# =====================================================

LoginGraceTime 60
MaxAuthTries 3

Böylece authentication için verilen süre ve başarısız giriş denemeleri de sınırlandırılabilir.

Örneğin tüm bölüm:

# =====================================================
# SSH HARDENING
# =====================================================

PermitRootLogin no

PubkeyAuthentication yes

PasswordAuthentication no

KbdInteractiveAuthentication no

PermitEmptyPasswords no

LoginGraceTime 60

MaxAuthTries 3

şeklinde düzenlenebilir.

Kriptografik algoritmalar ise kurumun OpenSSH sürümü ve güvenlik politikası doğrulandıktan sonra ayrıca tanımlanmalıdır.

31. SSH Hardening Sonrası Hızlı Kontrol

Sunucuda aşağıdaki komutlar sırasıyla kullanılabilir.

OpenSSH sürümü

ssh -V

Konfigürasyon syntax kontrolü

sudo sshd -t

Root login durumu

sudo sshd -T | grep permitrootlogin

Password Authentication

sudo sshd -T | grep passwordauthentication

Public Key Authentication

sudo sshd -T | grep pubkeyauthentication

Keyboard Interactive

sudo sshd -T | grep kbdinteractiveauthentication

Cipher listesi

sudo sshd -T | grep ciphers

MAC listesi

sudo sshd -T | grep macs

Key Exchange listesi

sudo sshd -T | grep kexalgorithms

SSH servisi

RHEL tabanlı sistemlerde:

sudo systemctl status sshd

Ubuntu/Debian’da:

sudo systemctl status ssh

32. SSH Hardening İçin Önerilen Uygulama Sırası

Gerçek bir production sunucuda aşağıdaki sıra kullanılabilir:

Adım 1 – Kullanıcıyı kontrol edin

id sysadmin

Adım 2 – Sudo yetkisini kontrol edin

sudo -l

Adım 3 – İstemcide SSH key oluşturun

ssh-keygen -t ed25519

Adım 4 – Public key’i sunucuya aktarın

ssh-copy-id sysadmin@192.168.1.100

Adım 5 – Key authentication’ı test edin

ssh sysadmin@192.168.1.100

Adım 6 – SSH yapılandırmasını düzenleyin

sudo nano /etc/ssh/sshd_config

Aşağıdaki değerleri uygulayın:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no

MFA/PAM kullanılmıyorsa:

KbdInteractiveAuthentication no

da değerlendirilebilir.

Adım 7 – Syntax kontrolü yapın

sudo sshd -t

Adım 8 – Efektif konfigürasyonu doğrulayın

sudo sshd -T

Adım 9 – SSH servisini reload edin

RHEL:

sudo systemctl reload sshd

Ubuntu:

sudo systemctl reload ssh

Adım 10 – Mevcut bağlantıyı kapatmadan yeni bağlantı açın

ssh sysadmin@192.168.1.100

Adım 11 – Root erişimini test edin

ssh root@192.168.1.100

Erişim reddedilmelidir.

Adım 12 – Password Authentication’ı test edin

ssh -o PubkeyAuthentication=no sysadmin@192.168.1.100

Parola tabanlı SSH bağlantısı başarılı olmamalıdır.

SSH Hardening Kontrol Listesi

Production sistemlerde aşağıdaki liste hızlı kontrol amacıyla kullanılabilir:

• SSH Version 1 kullanılmıyor.
• OpenSSH güncel tutuluyor.
• Root SSH erişimi kapalı.
• Normal kullanıcı + sudo modeli kullanılıyor.
• Public Key Authentication aktif.
• Password Authentication kapalı.
• Private key’ler başka kişilerle paylaşılmıyor.
• Private key’lerde doğru dosya izinleri kullanılıyor.
• Private key’ler mümkünse passphrase ile korunuyor.
• Kullanılmayan public key’ler authorized_keys dosyalarından kaldırılıyor.
• Empty Password erişimine izin verilmiyor.
• Kullanılan cipher algoritmaları kontrol ediliyor.
• KEX algoritmaları kontrol ediliyor.
• MAC algoritmaları kontrol ediliyor.
• Legacy algoritmalar gereksiz yere etkinleştirilmiyor.
• SSH yapılandırması sshd -t ile test ediliyor.
• Efektif yapılandırma sshd -T ile doğrulanıyor.
• Değişikliklerden sonra yeni SSH bağlantısı ayrı terminalden test ediliyor.
• Yeni bağlantı doğrulanmadan mevcut yönetim oturumu kapatılmıyor.

SSH, Linux sistem yönetiminin temel bileşenlerinden biridir. Ancak SSH’nin güvenli bir protokol olması, servisin hiçbir ek yapılandırmaya ihtiyaç duymadığı anlamına gelmez.

Güvenli bir SSH altyapısı oluşturmak için ilk olarak klasik kullanıcı adı ve parola modelinden SSH public key authentication modeline geçilmesi değerlendirilmelidir.

Örneğin kullanıcı tarafında:

ssh-keygen -t ed25519

ile SSH anahtarı oluşturulabilir ve:

ssh-copy-id sysadmin@192.168.1.100

ile public key sunucuya aktarılabilir.

Key authentication başarıyla doğrulandıktan sonra sunucu tarafında:

PermitRootLogin no
PubkeyAuthentication yes
PasswordAuthentication no
PermitEmptyPasswords no

gibi temel güvenlik ayarları uygulanabilir.

Bunun yanında SSH bağlantısının kriptografik tarafı da ihmal edilmemelidir.

Sunucunun aktif cipher, MAC ve Key Exchange algoritmaları:

sudo sshd -T | grep ciphers

sudo sshd -T | grep macs

sudo sshd -T | grep kexalgorithms

komutlarıyla incelenebilir.

Burada temel yaklaşım mümkün olan en uzun manuel cipher listesini oluşturmak değil; güncel OpenSSH sürümü kullanmak, legacy algoritmaları gereksiz yere etkinleştirmemek ve kurumun güvenlik politikasına uygun kriptografik standartları uygulamaktır.

Son olarak yapılan her SSH değişikliğinden sonra:

sudo sshd -t

ile yapılandırma doğrulanmalı ve mevcut SSH oturumu kapatılmadan yeni bir bağlantıyla test gerçekleştirilmelidir.

Başarılı bir SSH Hardening sürecinin temel mantığı özetle şöyledir:

Önce güvenli authentication yöntemini hazırla → bağlantıyı test et → gereksiz erişim yöntemlerini kapat → kriptografik yapılandırmayı kontrol et → değişiklikleri doğrula → yeniden test et.

Bu yaklaşım uygulandığında Linux sunucuların SSH üzerinden maruz kaldığı saldırı yüzeyi önemli ölçüde azaltılabilir ve daha kontrollü, sürdürülebilir ve güvenli bir uzaktan yönetim altyapısı oluşturulabilir.