it-swarm.asia

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ı?

41
Trey Parkman

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ı.

44
pyhimys

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
17
Gareth

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
13
Jinyu Liu

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ı

11
Daniel Lawson

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.

7
Trey Parkman

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.

4
Visser

Bana bir yapılandırma sorunu gibi geliyor. Daniel'in önerdiği gibi kontrol edilmesi gereken iki şey var:

  1. $HOME/.ssh/authorized_keys okunabilir; ve
  2. SSHd, ortak anahtar oturum açmaya izin verecek şekilde yapılandırıldı.
2
sybreon

Oturum açmaya çalıştığınız kullanıcı adını kontrol edin. Varsayılan olarak, yerel makinedeki kullanıcı adınız.

2
Creotiv

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

2
Jimsmithkka

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)

1
Freaktor

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
1
Lumi