Sıklıkla Karşılaştığım SSH Hatalarının Çözümü

tarihinde gönderilmiş tarafından

Sistemlerimizi yönetmek için bir nevi elimiz ayağımız olan SSH (Secure Shell) protokolünü kullanırken, bazı problemlerle karşılaşabiliyoruz. Bu problemler – hele ki işlerin en hararetli anlarında – başımıza geldiğinde de saç baş yolduracak etkiye sahip olabiliyor. Bu yazıda, sıklıkla karşılaştığım SSH hatalarının çözümlerini anlatacağım.

Başlamadan önce şunu belirtmekte yarar var. Şayet “network” katmanında bir erişim probleminiz varsa, bu dokümanda yazılanlar hiçbir işinize yaramayacaktır. Burada ağ bağlantısı sağlıklı şekilde yapılmış, SSH portuna erişimde herhangi bir sorun yaşamayan, herhangi bir firewall kuralına takılmayan bir yapı için troubleshoot adımları bulacaksınız.

Hatalı Kullanıcı Adı/Makine

Özellikle bir sistemden diğerine geçerken, dalgınlıkla yapılan bir hata. SSH için verilen kullanıcı adının ve/veya makinenin hatalı olması durumunda, yapılacak en iyi şey derin bir nefes almak olabilir 🙂

ali@ubuntu:~$ ssh gereklidetay@ol9
ssh: Could not resolve hostname ol9: Temporary failure in name resolution
ali@ubuntu:~$ ssh gereklidetay@ol8
gereklidetay@ol8's password:
Permission denied, please try again.
gereklidetay@ol8's password:
Permission denied, please try again.
gereklidetay@ol8's password:
gereklidetay@ol8: Permission denied (publickey,gssapi-keyex,gssapi-with-mic,password).

Burada dikkat edilmesi gereken en önemli noktalardan biri, “ssh” komutuna herhangi bir kullanıcı adı vermezseniz; karşı cihaza, komutu çalıştıran kullanıcı adıyla gideceğidir.

root@ubuntu:~# ssh ol8
root@ol8's password:

root@ubuntu:~# ssh ali@ol8
ali@ol8's password:

root Erişiminin Kapalı Olması

SSH servisi yapılandırmanızda, root kullanıcısının SSH erişimi tamamen kapatılmış olabilir. Bu durumda, karşı sunucuya root olarak SSH yapamazsınız.

[root@ol8 ~]# grep -i permitrootlogin /etc/ssh/sshd_config
PermitRootLogin no
# the setting of "PermitRootLogin without-password".

Client tarafındaki durumu incelemek adına, “ssh -v” kullanacağım. Sunucu tarafını takip etmek için ise “tail -f /var/log/audit/audit.log” ile log’ları takip edeceğim.

root'a Kapalı SSH Örneği
root’a Kapalı SSH Örneği

Client tarafına baktığımızda, pek bir şey göremiyoruz. Sunucunun doğruluğu/bilinirliği teyit edilmiş. root için anahtar aranmış, bulunamamış. Devamında parola sorulmuş.

Server (bağlanılmak istenen cihaz) tarafına baktığımızda ise, bizi pek çok yararlı log bekliyor:

type=USER_AUTH msg=audit(1706116180.572:554): pid=6330 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=pubkey acct="root" exe="/usr/sbin/sshd" hostname=? addr=10.0.0.10 terminal=ssh res=failed'UID="root" AUID="unset"

Üst üste gelen ve CRYPTO_SESSION’ın başarılı olduğunu gösteren log’ların devamında, “msg= op=pubkey” ifadesinin geçtiği satırı görüyoruz. Ve aslında ben daha parola girmeden, bu girişimin başarısız olduğu/olacağı bilgisi sunucu tarafından çoktan verilmiş. Parola ile deneme yapıldıktan sonra da yine bir fail log’u görüyoruz. Devamında ise zaten CTRL+C ile client tarafında erişim denemesini kesiyorum.

type=USER_AUTH msg=audit(1706116194.532:555): pid=6330 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:authentication grantors=? acct="root" exe="/usr/sbin/sshd" hostname=10.0.0.10 addr=10.0.0.10 terminal=ssh res=failed'UID="root" AUID="unset"

Parola ile Erişimin Kapalı Olması

Sunucu, parola ile oturum açılmasını istemiyorsa, bunu client tarafında rahatlıkla tespit edebiliriz:

ali@ubuntu:~$ ssh ali@ol8
ali@ol8: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Görüldüğü üzere, permission denied ifadesinin yanında; sunucunun hangi yöntemleri bize sunduğu ifade edilmiş. Biz, bu yöntemlerin hiçbirini kullanamadığımız için, sunucuya SSH ile gidemedik. SSH anahtarı oluşturup kullanma konusunda ilgili yazımı inceleyebilirsiniz.

Server’ın audit log’larına ise şunlar yansıdı:

type=USER_ERR msg=audit(1706116716.075:586): pid=6346 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:bad_ident grantors=? acct="?" exe="/usr/sbin/sshd" hostname=10.0.0.10 addr=10.0.0.10 terminal=ssh res=failed'UID="root" AUID="unset"

Mesaj kısmındaki “bad_ident” ifadesi, fikir edinme noktasında yardımcı olabilir. Özetle sunucu, istemcinin kendini ifade etme/tanıtma şeklinden memnun olmadığını dile getiriyor.

SSH Anahtarıyla Erişimde Yaşanan Problemler

Parola ile erişim yok. root kullanıcısına erişim yok. Buraya kadar tamamız. Peki anahtarım da olmasına rağmen neden SSH yapamıyorum?

PubKeyAuthentication Kapalı Olabilir

İlk olarak, client tarafındaki çıktıya bakmak gerekebilir:

ali@ubuntu:~$ ssh ali@ol8
ali@ol8: Permission denied (gssapi-keyex,gssapi-with-mic).

Yukarıdaki çıktıya bakıldığında, server’ın aslında “publickey” de kabul etmediğini görüyorsunuz. SSH server yapılandırmasında, tıpkı parola ile erişimin iptal edilebileceği gibi, anahtar ile erişimin de iptal edilebileceğini unutmamalıyız.

Key İsminiz Hatalı Olabilir

Farklı bir deneme yapmak adına bu yapılandırmayı düzenleyip tekrar deneyeceğim.

Yanlış Anahtar ile SSH Denemesi
Yanlış Anahtar ile SSH Denemesi

Sunucu tarafındaki log’lara baktığımızda, yine bir bad_ident durumu görüyoruz. Client tarafında SSH talebimizi “verbose” edip durumu tekrar inceleyelim. Verbosity seviyesini arttırmak için daha fazla “v” ekleyebilirsiniz (“ssh -vvv” gibi). Aralarda bazı satırları sildiğimi baştan belirteyim:

ali@ubuntu:~$ ssh -v ali@ol8
OpenSSH_8.9p1 Ubuntu-3ubuntu0.6, OpenSSL 3.0.2 15 Mar 2022
debug1: Connecting to ol8 [10.0.0.30] port 22.
debug1: Connection established.
debug1: Authenticating to ol8:22 as 'ali'
debug1: Host 'ol8' is known and matches the ED25519 host key.
debug1: Found key in /home/ali/.ssh/known_hosts:4
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Next authentication method: gssapi-with-mic
debug1: No credentials were supplied, or the credentials were unavailable or inaccessible
No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1000)
debug1: No credentials were supplied, or the credentials were unavailable or inaccessible
No Kerberos credentials available (default cache: FILE:/tmp/krb5cc_1000)
debug1: Next authentication method: publickey
debug1: Offering public key: /home/ali/.ssh/id_rsa RSA SHA256:TqFXFJxvckB7x38WmpljLsNkkox0PCKtQXxlxMOkIsk
debug1: Server accepts key: /home/ali/.ssh/id_rsa RSA SHA256:TqFXFJxvckB7x38WmpljLsNkkox0PCKtQXxlxMOkIsk
debug1: Trying private key: /home/ali/.ssh/id_ecdsa
debug1: Trying private key: /home/ali/.ssh/id_ecdsa_sk
debug1: Trying private key: /home/ali/.ssh/id_ed25519
debug1: Trying private key: /home/ali/.ssh/id_ed25519_sk
debug1: Trying private key: /home/ali/.ssh/id_xmss
debug1: Trying private key: /home/ali/.ssh/id_dsa
debug1: No more authentication methods to try.
ali@ol8: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Yukarıdaki çıktılara bakıldığında, her şey yolunda görünüyor. IP doğru, port doğru, kullanıcı adı doğru. Daha önce bu cihaza başarıyla bağlanılmış da. Desteklenen authentication yöntemlerinin listesi verilmiş. “gssap-with-mic” pas geçilmiş çünkü ortamda herhangi bir Kerberos credendial’ı yok.

“publickey” yöntemi ile karşıya gidilmiş. “/home/ali/.ssh/id_rsa” açık anahtarı, sunucuya önerilmiş. Hatta sunucu bunu kabul de etmiş. Devamında ise birkaç private key denenmiş ve denemeler sonuç vermemiş.

Burada “Offering public key” ve “Server accepts key” ifadeleri kilit rol oynuyor. Sunulan bir public anahtar, sunucu tarafından kabul edilmiş zaten. Bizim private key’imiz ile bir problemimiz var. Denenen private key isimleri (bunlar varsayılan olarak denenen isimler) ile, benim private key ismimim bir ilgisi yok. Benim private key’imin adı “id“:

ali@ubuntu:~$ ls -la .ssh
total 28
drwx------ 2 ali ali 4096 Jan 24 17:23 .
drwxr-x--- 4 ali ali 4096 Jan 24 16:55 ..
-rw------- 1 ali ali  736 Jan 24 16:08 authorized_keys
-rw------- 1 ali ali 3369 Jan 24 15:46 id
-rw-r--r-- 1 ali ali  736 Jan 24 15:46 id_rsa.pub
-rw------- 1 ali ali 2934 Jan 24 16:08 known_hosts
-rw------- 1 ali ali 2098 Jan 24 16:08 known_hosts.old

Dolayısıyla sunduğum açık anahtar başka, elimdeki özel anahtar başka. Sağlıklı bir anahtar çifti sunamadığım için de, SSH yapamıyorum. Böyle durumlarda, hangi özel anahtar ile karşıya gideceğinizi belirtmeniz gerekir. Bunun için de “ssh -i” kullanabilirsiniz:

ali@ubuntu:~$ ssh -i .ssh/id ali@ol8
Activate the web console with: systemctl enable --now cockpit.socket

Last login: Wed Jan 24 19:55:49 2024 from 10.0.0.10
[ali@ol8 ~]$

Key İzinleriniz Hatalı Olabilir

Key dosyanız ve bu dosyanın bulunduğu dizinin izin ve sahiplikleri de çok önemlidir. Aşağıdaki örnekleri inceleyelim:

SSH Unprotected Private Key
SSH Unprotected Private Key

Şanslıysanız, bu mesajı görebilirsiniz. Çünkü bazı dağıtımlar bu mesajı göstermiyor 🙂 Tabii ki “ssh -v” ile problemi client tarafında analiz edebilirsiniz. Ancak bu mesajın bize açıkça ifade ettiği nokta şu. Private key dosyanızın izinleri, yeterince sağlıklı değil. Private key, sadece ve sadece sizin erişiminizde olmalıdır. Dolayısıyla diğer kullanıcıların okuma, yazma gibi izinleri bulunmamalıdır. Private key dosyanız için verebileceğiniz en temiz izin, “600” (arasıra açar değiştiririm derseniz) veya “400” (hiç elimi sürmem derseniz) olacaktır.

Bu durum, private key’iniz için geçerli. Public key’inizi isterseniz gazeteye ilan verin. Zaten onun olayı, public olması.

Sunucu tarafında ise şu log sizi bekliyor olacaktır:

Jan 24 20:38:05 ol8 sshd[6456]: Connection closed by authenticating user ali 10.0.0.10 port 44938 [preauth]

Buradaki “preauth” ifadesi, günümüzü güzelleştirir. Çünkü client tarafı, henüz authentication sürecine girişmeden bağlantıyı kendisi kesmiş. Sorun kesinlikle client tarafında ki zaten bunu görmüştük.

Karşı Sunucudaki İzin ve Sahiplikleriniz Doğru Olmayabilir

SSH anahtar çifti oluşturma yazımızda, public key’in sunucu tarafında nereye atıldığını belirtmiştik. Bu örnekte, “ali” kullanıcısının public key’i, “/home/ali/.ssh/authorized_keys” dizini altında olmalı. Ancak ona rağmen SSH yapamıyoruz. Peki neden?

Sunucu Tarafında Hatalı İzin ve Sahiplikler
Sunucu Tarafında Hatalı İzin ve Sahiplikler

Client tarafına baktığımızda, her şeyin doğru gittiğini görüyoruz:

debug1: Next authentication method: publickey
debug1: Offering public key: /home/ali/.ssh/id_rsa RSA SHA256:TqFXFJxvckB7x38WmpljLsNkkox0PCKtQXxlxMOkIsk
debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic
debug1: Trying private key: /home/ali/.ssh/id_ecdsa
debug1: Trying private key: /home/ali/.ssh/id_ecdsa_sk
debug1: Trying private key: /home/ali/.ssh/id_ed25519
debug1: Trying private key: /home/ali/.ssh/id_ed25519_sk
debug1: Trying private key: /home/ali/.ssh/id_xmss
debug1: Trying private key: /home/ali/.ssh/id_dsa
debug1: No more authentication methods to try.

Sunucu tarafında ise bazı satırlar dikkatimizi çekiyor:

.....
type=USER_AUTH msg=audit(1706118443.819:797): pid=6511 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=pubkey acct="ali" exe="/usr/sbin/sshd" hostname=? addr=10.0.0.10 terminal=ssh res=failed'UID="root" AUID="unset"
.....
type=USER_ERR msg=audit(1706118443.825:800): pid=6511 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=PAM:bad_ident grantors=? acct="?" exe="/usr/sbin/sshd" hostname=10.0.0.10 addr=10.0.0.10 terminal=ssh res=failed'UID="root" AUID="unset"
.....
type=USER_LOGIN msg=audit(1706118443.826:804): pid=6511 uid=0 auid=4294967295 ses=4294967295 subj=system_u:system_r:sshd_t:s0-s0:c0.c1023 msg='op=login acct="ali" exe="/usr/sbin/sshd" hostname=? addr=10.0.0.10 terminal=ssh res=failed'UID="root" AUID="unset"

Yine public key ile deneme yapıldığını ancak bad_ident düşüncesi ile bu denemenin reddedildiğini görüyoruz.

Sistem log’larına ise şu ifadeler düşmüş:

Jan 24 20:54:20 ol8 sshd[6541]: Authentication refused: bad ownership or modes for directory /home/ali/.ssh
Jan 24 20:54:20 ol8 sshd[6541]: Connection closed by authenticating user ali 10.0.0.10 port 59788 [preauth]

Sunucu tarafında, “authorized_key” dosyasının olması gereken yere bakarsak, bu sorunun sebebini görebiliriz:

[root@ol8 ali]# pwd
/home/ali
[root@ol8 ali]# ls -la
total 16
drwx------. 3 ali  ali   95 Jan 24 19:04 .
drwxr-xr-x. 3 root root  17 Jan 23 17:07 ..
-rw-------. 1 ali  ali  108 Jan 24 19:07 .bash_history
-rw-r--r--. 1 ali  ali   18 Aug  2  2022 .bash_logout
-rw-r--r--. 1 ali  ali  141 Aug  2  2022 .bash_profile
-rw-r--r--. 1 ali  ali  376 Aug  2  2022 .bashrc
drwxrwxrwx. 2 ali  ali   29 Jan 24 19:04 .ssh

Gördüğünüz gibi, “.ssh” dizinine 777 izni verilmiş. Bu dizine herkes yazar, bu dizini herkes okur. İsteyen istediğini yapar. Bu durumda; farklı bir kullanıcı gelip, “ali”nin authorized_keys dosyasını silip erişimini ortadan kaldırabilir. Ya da daha kötüsü, dosyanın içerisine kendi public key’ini yazıp, kendi de “ali” gibi erişim kazanabilir. Dolayısıyla “sshd (Secure Shell Daemon)” bu problemli durum çözülmeden, “ali” kullanıcısının SSH yapmasına izin vermeyecektir. Benzer şekilde “.ssh” dizini altındaki “authorized_keys” dosyasına da yalnızca ilgili kullanıcı yazabilir durumda olmalıdır. Aksi durumda, server tarafında aşağıdaki hata görülür:

Jan 24 20:53:10 ol8 sshd[6531]: Authentication refused: bad ownership or modes for file /home/ali/.ssh/authorized_keys
Jan 24 20:53:10 ol8 sshd[6531]: Connection closed by authenticating user ali 10.0.0.10 port 53972 [preauth]

Açık bir şekilde, sunucu bu bağlantıyı reddediyor ve sebep olarak da authorized_keys dosyasının sahiplik ve izinlerini gösteriyor.

Genel Kontroller

Bu listedeki adımlar; neyi, neden, nasıl yapmamız gerektiği ve sorunu nerede aramamız gerektiğine dair bazı ipuçları sunabilir. Burada verilen dosya ve dizin isimleri, pek çok dağıtım için varsayılan olarak belirlenmiş değerlerdir. Sizin ortamınızda farklılık gösterebilir:

  • Doğru kullanıcı adı ve makine adını yazdığınızdan emin olun.
  • Sunucunun kabul ettiği yöntemlere dikkat edin.
    • Parola ile oturum açmayı desteklemeyen bir cihazda, parola ile oturum açmayı denemek anlamsız olacaktır.
  • root musunuz? root kullanıcının SSH yapılandırması, diğer kullanıcılardan farklı olabilir. “ali”nin parola ile SSH yapabilmesi, root’un da yapabileceği anlamına gelmes.
    • root ile SSH erişimi tamamen kapatılabilir.
  • Anahtarınız, varsayılan olarak “~/.ssh/” dizininde aranır. Bu dizinin izinlerinin “700”, sahibinin ise kendi kullanıcınız olduğuna emin olun.
    • Ayrıca özel anahtarınızın da (private key) sahibinin kendi kullanıcınız olduğuna emin olun. İznini ise “600” veya “400” olarak belirleyebilirsiniz.
  • Sunucu tarafında da açık anahtarınız, yine “~/.ssh/” dizini altında “authorized_keys” dosyasında yer alır. Bu dizinin ve dosyanın sahibi de, sizin kullanıcınız (SSH ile oturum açacak kullanıcı) olmalı. Ayrıca, “.ssh” dizini için 700, “authorized_keys” dosyası için ise 600 izni verildiğinden emin olun. (Bu dosyalar, daha açık izinleri de destekliyor olabilir ama ne gerek var?)
  • Doğru anahtarı kullandığınızdan emin olun.
  • Client tarafında “ssh -v (-vv veya -vvv şeklinde arttırılabilir)” ile daha detaylı çıktılar görebilirsiniz.
  • Server tarafında “journalctl” ile sistem loglarını takip edebilir veya “/var/log/audit/audit.log” altından audit log’larını takip edebilirsiniz.
  • Çok sıkıştığınız noktada, SSH server yapılandırmasında (/etc/ssh/sshd_config) “LogLevel INFO” satırını ekleyin ve servisi yeniden başlatın. Ortalık biraz kalabalık hâle gelecektir. Ancak sshd servisi ile ilgili çok daha detaylı log’lar görmeye başlayacaksınız.