ssh artık genel anahtar kimlik doğrulamasına izin vermiyor


22

Makinem kısa süre önce gelen ortak anahtar kimlik doğrulamasını kabul etmeyi bıraktı. Windows makineden ssh yaptığım ubuntu 11.04 masaüstüm var. Macunlukla macun kullanıyorum. Bağlanabiliyorum ancak yalnızca etkileşimli parola doğrulamayla kurdum, rsa anahtarım değil.

Anahtarın ~ / .ssh / yetkili_keys içinde listelendiğini zaten doğruladım. Bunu nasıl düzeltebilirim ve neyi kontrol edebilirim?


2
Öncelikle ~, üçünün hepsinin ~/.sshve ~/.ssh/authorized_keyssadece sizin tarafınızdan yazılabilir olduğundan emin olun (özellikle grup yazma izni yoktur). /var/log/auth.logGiriş girişiminiz sırasında oluşturulan günlük girişlerine bakın . Onları kopyalayıp sorunuza yapıştırın (isterseniz gizlilik için isimler düzenleyin). Ayrıca sorunun tamamen sunucu tarafında olup olmadığını da kontrol edin: özel anahtarı Linux makinesine kopyalayın (PuTTY'nin özel anahtar dosyasını OpenSSH formatına dönüştürmeniz gerekir) ve çalışıp ssh localhostçalışmadığını kontrol edin.
Gilles 'SO- kötülük' dur

Ana dizini nedense yazılabilir oldu. Bu düzeltti. Bunu bir cevap olarak koy ki kabul etmeliyim.
Andrew Redd

Yanıtlar:


28

Genel anahtar kimlik doğrulaması işe yaramazsa: sunucu tarafında, giriş dizininizin ( ~), ~/.sshdizinin ve ~/.ssh/authorized_keysdosyanın yalnızca sahiplerinin yazabildiğinden emin olun . Özellikle, bunların hiçbiri grup tarafından yazılabilir olmamalıdır (kullanıcı grupta yalnız olsa bile). chmod 755ya chmod 700da tamam, chmod 770değil.

Bir şeyler yanlış olduğunda kontrol edilecekler:

  • ssh -vvvÇok sayıda hata ayıklama çıktısı görmek için çalıştırın . Neden ssh ile bağlantı kuramadığınızı soran bir soru yazarsanız, bu çıktıyı ekleyin (ana makine ve kullanıcı adlarını anonimleştirmek isteyebilirsiniz).
  • Yapabiliyorsanız, sunucu girişlerini kontrol edin /var/log/auth.log.
  • Genel anahtar kimlik doğrulaması çalışmıyorsa, izinleri tekrar kontrol edin, özellikle de grup biti (yukarıya bakın).


1
Güzel cevap! Homedir'imi unuttum: o
RobAu

Eğer ssh (ya da sshd) 'nin son sürümünü kullanıyorsanız, DSA anahtarları güvenlik sorunları nedeniyle varsayılan olarak artık desteklenmemektedir. Tek gerçek düzeltme, RSA'ya veya daha iyi anahtarlara yükseltmektir.
Mikko Rantalainen

Klasörümün izinlerini değiştirdim ve ne? SSH'den kapatıldım! Ssh anahtarlarını değiştirdim, hayır, sunucu hala bağlantıyı reddediyor! Bir çözüm bulmaya çalışırken deli oldum ve chmod 700'ün cevabını ana klasörüme verdim, ssh çalışmaya başladı !!!!!!! Teşekkürler! Çözümü bulmaya çalışırken terminal bağlantım koparsa, sunucudan tamamen kilitlenirdim. Bu yüzden ana klasör izinlerinizle oynamamaya dikkat edin! (Ben sadece ev klasörü izinlerimi değiştirdim, .ssh klasörü değil ama hala SSH dışında kilitliyim)
Tarik


5

Dizinlerdeki izinleri kontrol ederseniz ve bir "." Var. bunlardan hemen sonra, selinux etkin olabilir; bu, anahtar değişimi ile karıştıracak ve varsayılan olarak manuel şifre tanımlamasına izin verebilir.

Buradaki talimatları izleyerek sorun gidermek için SELinux'u devre dışı bırakabilirsiniz: http://www.centos.org/docs/5/html/5.1/Deployment_Guide/sec-sel-enable-disable-enforcement.html veya / etc dosyasını düzenleyin. / selinux / config dosyası ve "zorlama" dan "devre dışı" olarak değiştirin.

Bu yardımcı olur umarım.


Selinux’u etkinleştirmiştim, ancak devre dışı bırakmak sorunu çözmedi. Benim için püf noktası neydi chmod 600 ~/.ssh/authorized_keys- dosya grup halinde yazılabilirdi. (via pyrosoft.co.uk/blog/2013/01/12/… )
David Carboni

Bu bana yardımcı oldu! Teşekkür ederim!
907

Doğru SELinux bağlamlarını ayarlayarak, SSin kimlik doğrulamasını SELinux ile birlikte çalıştırabilmelisiniz. Sistem tarafından yapılandırılmış içerikleri ana dizininizde ( restorecon ~ -R) geri yüklemek iyi bir başlangıç ​​noktasıdır.
Josh Kelley

4

Ayarlarınızı / etc / ssh / sshd_config dosyasında doğru yaptığınızdan emin olabilirim.

Yalnızca PKI kullanımına zorlamak ve şifrelere izin vermemek için

#PasswordAuthentication yes 

Dosyanızda uncomment yapın ve

PasswordAuthenticate no

Ayrıca, mantıklı olmalarını sağlamak için ayarların dengesini de okurdum. Özellikle, DSA'nın tehlikeye girdiğini bildiğinden RSA anahtarlarını kullandığınızdan emin olun.


11
Parola doğrulamanın nasıl devre dışı bırakılacağını açıklıyorsunuz. Bu, ortak anahtar kimlik doğrulamasının çalışmasına yardımcı olmaz (önce genel anahtar denenir). Andrew: Genel anahtar doğrulamanın çalıştığından emin olana kadar şifre doğrulamayı devre dışı bırakmayın!
Gilles 'SO- kötülük' dur

2

Sorunun olası bir nedeni, DSA anahtarlarına sahip olmanızdır, ancak şimdi SSA (görünüşe göre) varsayılan olarak RSA anahtarlarına ihtiyaç duymaktadır. 16.04'e yükseltirken sorun yaşadım. Burada daha fazlasını görebilirsiniz, ancak kısa cevap aşağıdakileri ekleyin ~/.ssh/config:

PubkeyAcceptedKeyTypes ssh-dss

1

Bu sorunu / etc / ssh / sshd_config içindeki "PasswordAuthentication yes" ifadesinin yorumunu kaldırarak düzelttim.


1

İki farklı makine arasındaki haberleşmede sorun gidermeye olan ihtiyaç nedeniyle ~/.ssh, müşteri tarafında iki özel anahtarım vardı .

Her sunucu ana bilgisayarını, ~/.ssh/identityyapmam gereken şekilde özel anahtarla yapılandırmak yerine, tüm ana bilgisayarlar için yapılandırılmış ikincil (ve bu durumda yanlış) anahtarını kullandım:

Host *
IdentityFile ~/.ssh/identity_b

Düzeltme ~/.ssh/identitysorunu çözdü:

Host a
IdentityFile ~/.ssh/identity_a
Host b
IdentityFile ~/.ssh/identity_b

0

Ben de aynı sorunu yaşadım, ancak izinleri değiştirmek chmodişe yaramadı, çünkü ~/.ssh/authorized_keysdosya sahibine sahip değildim . .sshDizinin sahipliğini şu şekilde değiştirebilirsiniz :

sudo chown -R "$USER" ~/.ssh

-1

Her nasılsa bu benim için çalıştı:

root @ kaiser: ~ # vim / etc / ssh / sshd_config

Bu satırı evet 'den hayır' a değiştirin. 28 StrictModes no

Tekrar deneyin

sysadmin @ suselinux1: ~> con sysadmin kaiser Ubuntu 12.04.1 LTS'ye hoş geldiniz (GNU / Linux 3.2.0-25-jenerik i686)

Son giriş: Cuma 9 Kas 15:40:11 2012 10.1.3.25 tarihinden itibaren sysadmin @ kaiser: ~ $ 9 yıl 17:53:11 CST 2012 sysadmin @ kaiser: ~ $


3
Ne yaptığını ve neden işe yaradığını bilmeden bir şeyler yapmak kabul edilebilir olabilir, ancak aynı şeyi söylemek kötüdür ve bir güvenlik sistemiyle uğraşırsa daha kötüdür.
Mahesh

2
kabul. Bunun sshdtam olarak "güzel cumartesi okumaları" kategorisine girmeyen daha iyi dokümanlar yaratmaya teşvik edilmesine izin verin
code_monk
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.