SSH StrictModes, agent forwarding (ssh -A) ve ssh -a açıklaması

Kısaca: `StrictModes yes` (OpenSSH varsayılanı), sshd'nin bir anahtarı kabul etmeden önce home dizininizin, `~/.ssh`'ın ve `~/.ssh/authorized_keys`'in sahipliğini ve izinlerini kontrol etmesini sağlar; bunlardan herhangi biri grup veya diğerleri tarafından yazılabiliyorsa ya da başka bir kullanıcıya aitse "Authentication refused: bad ownership or modes" ile girişi reddeder. Kontrolü devre dışı bırakmak yerine izinleri düzeltin. `ssh -A` ile agent forwarding, siz bağlıyken uzak hostun yerel anahtarlarınızı kullanmasına izin verir; bu yüzden tam olarak güvenmediğiniz hostlarda bundan kaçının ve onun yerine `ssh -J` (ProxyJump) kullanın; küçük harfli `ssh -a` agent forwarding'i açıkça devre dışı bırakır.

Bu rehber SSH sıkılaştırma rehberini tamamlar ve Debian 12/13, Ubuntu 24.04 ile AlmaLinux 9 ve Rocky 9 gibi RHEL ailesi sistemler için geçerlidir.

SSH StrictModes neleri kontrol eder

StrictModes, `/etc/ssh/sshd_config` içindeki sunucu tarafı bir ayardır. Amacı basittir: başka bir kullanıcı `authorized_keys` dosyanıza yazabiliyorsa kendi anahtarını ekleyip sizin olarak giriş yapabilir. Bu yüzden sshd, yolun tamamı korunmadıkça dosyaya güvenmeyi reddeder. Dosyayı ve üstündeki dizinleri, home dizini dahil, kontrol eder.

Geçerli değeri `sshd -T | grep -i strictmodes` ile doğrulayın. Ubuntu 24.04 ve Debian 13'te `/etc/ssh/sshd_config.d/` içindeki drop-in dosyalarını da kontrol edin.

"Authentication refused: bad ownership or modes" hatasını düzeltin

İstemci yalnızca genel bir `Permission denied (publickey)` gösterir. Gerçek neden, tam yolu belirten sunucu logundadır; örneğin `Authentication refused: bad ownership or modes for directory /home/alice` veya `... for file /home/alice/.ssh/authorized_keys`. Düzeltmek için VPS konsolunuzu veya başka bir oturumu kullanın.

1. 01.Logu okuyun: Debian ve Ubuntu'da `journalctl -u ssh -n 50`, AlmaLinux ve Rocky'de `journalctl -u sshd -n 50`.
2. 02.Kullanıcının SSH dizininin sahipliğini düzeltin: `chown -R alice:alice /home/alice/.ssh`.
3. 03.Modları düzeltin: `chmod 700 /home/alice/.ssh` ve `chmod 600 /home/alice/.ssh/authorized_keys`.
4. 04.Home dizininden grup ve herkes için yazma iznini kaldırın: `chmod go-w /home/alice`.
5. 05.SELinux sistemlerinde (AlmaLinux, Rocky, Fedora) etiketleri geri yükleyin: `restorecon -Rv /home/alice/.ssh`.
6. 06.Çalışan oturumu açık tutarak yeni bir terminalden `ssh -v alice@server` ile test edin.

# all-in-one, run as root on the server
chown -R alice:alice /home/alice/.ssh
chmod go-w /home/alice
chmod 700 /home/alice/.ssh
chmod 600 /home/alice/.ssh/authorized_keys
namei -l /home/alice/.ssh/authorized_keys   # shows owner and mode of every path component

Note · Hatayı ortadan kaldırmak için `StrictModes no` ayarlamayın. Bu gerçek bir korumayı kaldırır ve yanlış yapılandırmayı düzeltmek yerine gizler.

StrictModes ve StrictHostKeyChecking

"ssh strictmode" aramaları çoğu zaman birbiriyle ilgisiz iki seçeneği karıştırır. `StrictModes` sunucudaki `sshd_config` içinde yaşar ve dosya izinlerini kontrol eder. `StrictHostKeyChecking` ise istemcideki `ssh_config` veya `~/.ssh/config` içinde yaşar ve bir sunucunun host anahtarı bilinmediğinde veya değiştiğinde ne olacağını kontrol eder. İstemcinin de kendi izin kontrolü vardır: diğer kullanıcıların okuyabildiği bir özel anahtarı korumasız özel anahtar dosyası uyarısıyla kullanmayı reddeder; `chmod 600 ~/.ssh/id_ed25519` bunu düzeltir.

ssh -A ile agent forwarding: risk

`ssh -A` (veya `ForwardAgent yes`), uzak hostta `$SSH_AUTH_SOCK` ile referans verilen ve imzalama isteklerini makinenizdeki ssh-agent'a geri ileten bir socket oluşturur. Özel anahtarınız makinenizden asla çıkmaz, ancak o socket'e erişebilen herkes siz bağlıyken anahtarınızı kullanabilir. Uzak hostta buna root ve sizin kullanıcınız olarak çalışan her süreç dahildir.

Sunucu ele geçirilmişse veya başka biri tarafından yönetiliyorsa, bir saldırgan anahtarınızın açtığı diğer tüm hostlara — Git hosting ve production sunucuları dahil — sessizce giriş yapabilir. OpenSSH istemcisinin varsayılan olarak `ForwardAgent no` kullanmasının nedeni budur.

• ▹Agent'ınızı asla paylaşımlı, üçüncü taraf veya sıkılaştırmadığınız yeni kurulmuş hostlara iletmeyin.
• ▹İletmek zorundaysanız, anahtarın her kullanımı yerel onay gerektirsin diye `ssh-add -c` kullanın.
• ▹OpenSSH 8.9 ve sonrası `ssh-add -h` ile hedef kısıtlamalarını destekler; böylece iletilen bir anahtarın hangi hostlar için kullanılabileceği sınırlanır.
• ▹Sunucu tarafında `sshd_config` içindeki `AllowAgentForwarding no` bunu devre dışı bırakır, ancak shell erişimi olan kullanıcılar yine de kendi forwarder'larını kurabilir.

Bastion'lar için ProxyJump'ı (ssh -J) tercih edin

Agent forwarding'in çoğu, bir bastion üzerinden dahili bir makineye atlamak için kullanılır. `ssh -J` bunu agent'ınızı açığa çıkarmadan yapar: bastion yalnızca şifreli bir TCP akışını iletir ve dahili hosta kimlik doğrulama dizüstü bilgisayarınızdan uçtan uca gerçekleşir. Yalnızca özel bir ağ üzerinden erişilebilen sunucular için WireGuard tüneli başka bir seçenektir; bkz. WireGuard VPN rehberi veya WireGuard mesh rehberi, keepalive ve PSK ayarları için de bu WireGuard ayar rehberi.

Bir NoctisNode VPS'inde KVM makine üzerinde SSH ile tam root alırsınız; böylece küçük bir Wisp planı, üzerinde başka hiçbir şey çalışmayan özel bir jump host olarak hizmet verebilir; bkz. VPS planları.

# one-off
ssh -J [email protected] [email protected]

# ~/.ssh/config
Host bastion
    HostName bastion.example.com
    User alice
    ForwardAgent no

Host db1
    HostName 10.88.0.3
    User alice
    ProxyJump bastion

ssh -a (küçük harf) ne yapar

Küçük harfli `ssh -a`, o bağlantı için agent forwarding'i devre dışı bırakır; `-A`'nın tersidir. `~/.ssh/config` dosyanız wildcard bir host için `ForwardAgent`'ı etkinleştirdiğinde ve belirli bir bağlantının iletmediğinden emin olmak istediğinizde yararlıdır, örneğin `ssh -a admin@untrusted-host`. Agent'ın socket yolunu belirleyen `ssh-agent -a` ile veya anahtarları agent'a yükleyen `ssh-add` ile karıştırmayın.

SSS