SSH genel anahtar kimlik doğrulamasının çalışması sağlanamıyor
Sunucum CentOS 5.3 çalıştırıyor. Leopard çalıştıran bir Mac'deyim. Hangisinin bundan sorumlu olduğunu bilmiyorum:
Parola kimlik doğrulaması ile sunucumda oturum açabiliyorum. PKA'yı kurmak için tüm adımları geçtim ( http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-ssh-beyondshell.html adresinde açıklandığı gibi) ), ancak SSH kullandığımda publickey doğrulaması denemeyi bile reddediyor. Komutu kullanma
ssh -vvv [email protected]
(nerede -vvv ayrıntı düzeyini maksimum düzeye çıkarır) Aşağıdaki ilgili çıktıyı alıyorum:
debug2: key: /Users/me/.ssh/id_dsa (0x123456)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred keyboard-interactive,password
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password
ardından şifremi sor. Eğer sorunu zorlamaya çalışırsam
ssh -vvv -o PreferredAuthentications=publickey [email protected]
Alırım
debug2: key: /Users/me/.ssh/id_dsa (0x123456)
debug1: Authentications that can continue: publickey,gssapi-with-mic,password
debug3: start over, passed a different list publickey,gssapi-with-mic,password
debug3: preferred publickey
debug3: authmethod_lookup publickey
debug3: No more authentication methods to try.
Yani, sunucu publickey kimlik doğrulama yöntemini kabul ettiğini söylese ve SSH istemcim ısrar ediyor olsa da, çürütüyorum. (Yukarıdaki "Ortak anahtar sunuluyor:" satırının göze çarpan yokluğuna dikkat edin.) Herhangi bir öneriniz var mı?
Centos makinenizde şunların olup olmadığını kontrol edin:
RSAAuthentication yes
PubkeyAuthentication yes
sshd_config içinde
ve centos makinesinin ~/.ssh/dizininde uygun izne sahip olduğunuzdan emin olun.
chmod 700 ~/.ssh/
chmod 600 ~/.ssh/*
hile yapmalı.
Benzer bir sorunum vardı - uzak PC, CentOs 6 sunucusunda oturum açmak için ortak anahtar kimlik doğrulamasını kullanamadı. Benim durumumdaki problem SELinux ile ilgiliydi - giriş yapmaya çalışan kullanıcının ana dizini güvenlik bağlamlarını mesajladı. Bunu restorecon aracını kullanarak bu şekilde çözdüm:
restorecon -Rv /home
1-/etc/ssh/sshd_config'nizi kontrol edin,
RSAAuthentication yes PubkeyAuthentication evet
2- Uzak makineden güvenli günlüğü kontrol edin, detay sshd arka plan programı hata günlüğüne bakın. Örneğin. Ubuntu'mda
# grep 'sshd'/var/log/secure | grep 'Kimlik doğrulama reddedildi' | kuyruk -5 4 Ağu 06:20:22 xxx sshd [16860]: Kimlik doğrulama reddedildi: kötü sahiplik veya /home/xxx[.____. dizini için hatalı sahiplik veya modlar ]: Kimlik doğrulama reddedildi: /home/xxx[.____. dizini için hatalı sahiplik veya modlar. ] Ağu 4 06:21:21 xxx sshd [17028]: Kimlik doğrulama reddedildi: kötü sahiplik veya dizin /home/xxx[.____. için hatalı sahiplik veya modlar veya /home/xxx dizini için modlar
Sonra dizin/home/xxx için sahiplik ve modları kontrol edin, belki de bunu çalıştırmanız gerekir
chmod 755 /home/xxx
Hem yerel hem de uzak makineler için izinlerinizin doğru ve dosya yapısının (özellikle yazım denetimi) doğru olup olmadığını bir kez daha kontrol edin. Başvurduğunuz URL hepsini belirtir, ancak eşleşmelerinizin eşleştiğini kontrol etmeye değer. Normalde izinler ilgili bir hata verir.
CentOS 5.3 kutunuzdaki sshd_config dosyasının PubkeyAuthentication veya RSAAuthentication'a izin verecek şekilde ayarlandığını kontrol ettiniz mi?
CentOS sistemindeki SSH sunucu günlüklerini kontrol edin - daha fazla bilgi sağlayabilir. CentOS'un kara listeye alınan ssh anahtarını debian'ın yaptığını kontrol edip etmediğinden emin değilim, ancak -vvv çıkışı gittikçe nispeten sessiz olan ssh publickey reddetmelerini gördüm, ancak günlükler neler olduğunu açıkladı
Anladım! Bunun müşteri tarafında bir sorun olduğu ortaya çıktı. (Herhangi bir sunucu tarafı sorunun daha yararlı hata ayıklama çıktısı vereceğini düşünüyorum.) Benim bilinmeyen nedenlerden ötürü, Mac bilgisayarımda/etc/ssh_config dosyasının satırı vardı
PubkeyAuthentication = no
Ben bir satır yorum ve şimdi her şey iyi çalışıyor.
Dosya/dizin modlarının yanı sıra, sahipliğin doğru olduğundan emin olun! Bir kullanıcının kendi ana dizini, .ssh/ve içindeki dosyaları olması gerekir.
Çalıştırmak zorunda kaldım chown -R $user:$user /home/$user ssh hatalarımı aşmak için.
Bana bir yapılandırma sorunu gibi geliyor. Daniel'in önerdiği gibi kontrol edilmesi gereken iki şey var:
$HOME/.ssh/authorized_keysokunabilir; ve- SSHd, ortak anahtar oturum açmaya izin verecek şekilde yapılandırıldı.
Oturum açmaya çalıştığınız kullanıcı adını kontrol edin. Varsayılan olarak, yerel makinedeki kullanıcı adınız.
Ayrıca otomatik olarak bir anahtar sağlayıp sağlayamayacağını kontrol edin, eğer değilse veya sadece test etmek için -i yolunu/to/tuşunu kullanın
ben sadece aynı sorun Fedora çekirdek 16 sent 5 erişim ile tuzağa düştü
günlükler ve ayrıntılı aynı görünüyordu
sorun ortak anahtardı, bazı sahte veriler aldı, yeniden oluşturdu ve sshd_server'da yayınladı, sshd_client anahtar bilgileri gönderiyor ancak sunucu tarafından tanınmıyor (yetkili_anahtarlardaki anahtarların herhangi biriyle eşleşmiyor)
ssh -v protokolde belirli bir adımda bir sorun olduğunu ortaya çıkaracaktır, ancak sunucuda bir şey nedeniyle istemci neden haberdar edilmeyecektir. Neyin yanlış olduğunu bulmak için sunucu günlük dosyalarına bakın. İzinleri alabilmek için büyük olasılıkla root olmanız gerekir. Örneğin, syslog'da oturum açmak üzere yapılandırılmış bir sshd için /var/log/secure. Bunlar gibi:
Authentication refused: bad ownership or modes for directory /home/you/.ssh
Authentication refused: bad ownership or modes for file /home/you/.ssh/authorized_keys
Bu durumda bunun nedeni (aptal) varsayılan default/0002. Bu, grup için yazma erişimi anlamına gelir. (Grup adı = kullanıcı adı, ancak yine de.) SSH arka plan programı, kullanıcıdan başkaları tarafından değiştirilebilen dosyalara güvenmeyecektir (elbette ve root). Sorunu chmod kullanarak çözebilirsiniz.
chmod 700 ~/.ssh # solve the issue
chmod 720 ~/.ssh # reproduce the issue
# or similar for a file