Soru SSH genel anahtar kimlik doğrulaması çalışamıyor [kapalı]


Sunucum CentOS 5.3 çalışıyor. Leopard’ı çalıştıran bir Mac’dayım. Bunun sorumlu olduğunu bilmiyorum:

Parola kimlik doğrulamasıyla sunucumda oturum açabilirim. PKA'yı kurmak için tüm adımları atlattım. http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-ssh-beyondshell.html), ancak SSH kullandığımda, publickey doğrulamayı denemeyi bile reddediyor. Komutu kullanarak

ssh -vvv user@host

(-vvv, maksimum seviyeye kadar ayrıntıyı açar) Aşağıdaki ilgili çıktıyı 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 keyboard-interactive,password
debug3: authmethod_lookup password
debug3: remaining preferred: ,password
debug3: authmethod_is_enabled password
debug1: Next authentication method: password

şifrem için bir uyarı geldi. Bu sorunu zorlamaya çalışırsam

ssh -vvv -o PreferredAuthentications=publickey user@host

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 ve SSH istemcimin bunun üzerinde ısrar ettiğini söylese de, çürütülüyorum. (Yukarıdaki "Genel anahtar sunma" satırının dikkat çekmeyen bir eksikliğine dikkat edin.) Herhangi bir öneriniz var mı?


39
2017-08-18 04:18


Menşei


sadece "ssh -v" yi kullanın, daha fazla ayrıntıya ihtiyaç duymazsınız ve tüm çıktıyı sadece önemli olduğunu düşündüğünüz satırları içermez - cstamas
Bu soru kapanıyor çünkü artık yanıt vermiyor ve düşük kaliteli cevaplar çekiyor. - HopelessN00b


Cevaplar:


Centos makinenizin şunları kontrol edin:

RSAAuthentication yes
PubkeyAuthentication yes

sshd_config içinde

ve centos makinesinin ~ / .ssh / dizininde uygun izinlere sahip olduğunuzdan emin olun.

chmod 700 ~/.ssh/
chmod 600 ~/.ssh/*

hile yapmalı.


41
2017-08-18 11:25



Doğru hak ve dosya isimleri (bazen 2'siz yetkili_keys2) çok önemlidir! - brandstaetter
Dosya izni authorized_keys çok önemli bir ipucu. Teşekkürler. - Kane
Ayrıca gerekebilir chmod go-w ~/ eğer çok da değilse. - tylerl
Ayrıca uzak sunucudaki ana dirinizin izinleri olup olmadığını kontrol edin 755 (Jinyu Liu'nun da belirttiği gibi) - Attila Fulop
Diğer işletim sistemlerinde SSH yapılandırma dosyası şu şekilde de yaşayabilir: /etc/ssh/ssh_config - Yoshua Wuyts


Benzer bir sorunum vardı - uzak PC, CentOs 6 sunucusuna giriş yapmak için ortak anahtar kimlik doğrulamasını kullanamadı. Benim durumumda sorun SELinux ile ilişkiliydi - giriş yapmaya çalışan kullanıcının giriş dizininde güvenlik bağlamında mesajlar vardı. Bunu kullanarak çözdüm restorecon aracı bu şekilde:

restorecon -Rv /home

16
2018-02-20 23:02



Sağol Gareth! "restorecon -Rv /root/.ssh" iyi hile yaptı. - tbroberg
Daha fazla açıklamak gerekirse: Bu komut, SELinux’un altındaki dosyalar için SELinux etiketlerini sıfırlamasını /home Genelde dizin düzeninde ne olursa olsun /home. - rakslice
Kök olarak giriş yapıyorsanız, restorecon -Rv /root - zhangyoufu


1- / etc / ssh / sshd_config dosyanızı kontrol edin, elinizde olduğundan emin olun

RSAAuthentication evet
PubkeyAuthentication evet

2- Güvenli makineyi uzaktaki makineden kontrol edin, sshd daemon hata günlüğüne bakın. Örneğin. Ubuntu'mda

# grep 'sshd' / var / log / güvenli | grep 'Kimlik doğrulaması reddedildi' | kuyruk -5
4 Ağustos 06:20:22 xxx sshd [16860]: Kimlik doğrulaması reddedildi: dizin / ev / xxx için kötü sahiplik veya modlar
4 Ağustos 06:20:22 xxx sshd [16860]: Kimlik doğrulaması reddedildi: dizin / ev / xxx için kötü sahiplik veya modlar
4 Ağustos 06:21:21 xxx sshd [17028]: Kimlik doğrulaması reddedildi: dizin / ev / xxx için kötü sahiplik veya modlar
4 Ağustos 06:21:21 xxx sshd [17028]: Kimlik doğrulaması reddedildi: dizin / ev / xxx için kötü sahiplik veya modlar
4 Ağustos 06:27:39 xxx sshd [20362]: Kimlik doğrulaması reddedildi: dizin / ev / xxx için kötü sahiplik veya modlar

Sonra dizin / home / xxx için sahiplik ve modları kontrol edin, belki bunu çalıştırmanız gerekiyor

chmod 755 / home / xxx

11
2017-08-04 13:53



Sistemin günlük dosyasını kontrol et, çok önemli bir ipucu. - Kane
755 ev dizin izinleri bana yardımcı oldu - kesinlikle gerekli! - Ben


Yerel ve uzak makineler için izinlerinizin doğru olduğunu ve dosya yapısının (özellikle yazım) doğru olduğunu iki kez kontrol edin. Atıfta bulunduğunuz URL, hepsini belirtir, ancak eşleştiklerini kontrol etmeye değer. Normalde izinler ilgili bir hatayı atar.

CentOS 5.3 kutunuzdaki sshd_config öğesinin 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ınmış ssh anahtarının debianın kontrolünü yapıp yapmadığından emin değilim, ama -vvv çıkışı gittikçe sessiz kalan ssh publickey reddelerini görmüştüm, ancak günlükler neler olduğunu açık bir şekilde açıkladı.


10
2017-08-18 04:26





Anladım! Bir istemci tarafı sorunu çıktı. (Bence sunucu tarafındaki herhangi bir sorunun daha kullanışlı hata ayıklama çıktısı alacağını düşünüyorum.) Benim için bilinmeyen nedenlerle, Mac'imde / etc / ssh_config dosyası vardı.

PubkeyAuthentication = no

Bir çizgiyi yorumladım ve şimdi her şey yolunda gidiyor.


6
2017-08-18 16:16





Dosya / dizin modlarının yanı sıra, sahipliğin doğru olduğundan emin olun! Bir kullanıcının kendi ana dizininin, .ssh / ve dosyalarının bulunması gerekir.

Koşmak zorundaydım chown -R $user:$user /home/$user ssh hatalarımdan kurtulmak için.


3
2017-08-23 22:34



+1, sistemlerimden birinde .ssh üzerindeki izinler haklıydı ancak birisi hesabın ana dizini 777 yaptı. - GargantuChet


Ayrıca, bir anahtarın otomatik olarak sağlanıp sağlanmadığını kontrol edin, değilse -i yol / to / anahtarını veya sadece test etmek için


1
2017-08-18 13:17





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

  1. SSH anahtarları $HOME/.ssh/authorized_keys okunabilir; ve
  2. SSHd, genel anahtar girişine izin verecek şekilde yapılandırılmıştır.

1
2017-08-18 06:46





Müşterinin çıktı olarak ssh -v Protokolde belirli bir adımda bir sorun olduğunu ortaya çıkaracaktır, ancak sunucuda bir şeyden kaynaklandığı zaman müşteriye neden bildirilmeyecektir. Neyin yanlış olduğunu öğrenmek için sunucu günlük dosyalarını kontrol edin. Muhtemelen olması gerek root Bunu yapmak için izinlere sahip olmak. Örneğin, bir sshd syslog'a giriş yapacak şekilde yapılandırılmış /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 neden bir (aptal) varsayılan oldu default arasında 0002. Bu, grup için yazma erişimi anlamına gelir. (Grup adı = kullanıcı adı, ama yine de.) SSH arka planı, başkaları tarafından kullanıcı tarafından değiştirilebilecek dosyalara güvenmiyor (iyi ve root, tabii ki). Kullanarak sorunu çözebilirsiniz chmod.

chmod 700 ~/.ssh # solve the issue
chmod 720 ~/.ssh # reproduce the issue
# or similar for a file

0
2018-02-14 18:52





ben sadece feribot çekirdeği 16 ila 5.5 ile aynı problemle karşılaştım.

Günlükler ve verbose tam olarak aynı görünüyordu

Sorun açık anahtardı, bazı sahte veriler aldı, yeniden oluşturup sshd_server'de yayınladıysanız, sshd_client anahtar bilgilerini gönderiyor ancak sunucu tarafından tanınmıyor (yetkilendirilmiş anahtarlarda herhangi bir tuşa uymuyor)


0
2018-03-31 02:26