SSH İzin reddedildi (publickey)

74

Önceki soruları sorduğum soruları yanıtlamaya çalıştım ama daha önce önerilen yanıtların hepsi benim için çalışmadı.

Yerel makinemden bir ubuntu (12.04 LTS çalıştıran) bağlamaya çalışıyorum (ayrıca 12.04 LTS çalıştıran ubnutu)

Yerel makinemde özel ve genel bir anahtar oluşturdum ve genel anahtarımı linode'ın yetkili_ahtarları dosyasına kopyaladım. Ancak, ne zaman benim linode için ssh denerim, "İzin reddedildi (publickey)" hata mesajını alıyorum.

Linux'un ssh'inin nasıl kurulduğuna dair bir sorun değil, çünkü Windows kimlik makinemden anahtar kimlik doğrulaması kullanarak ssh yapabiliyorum.

Yerel ubuntu makinemdeki .ssh dizininde, id_rsa ve id_rsa.pub dosyam var. Yerel makinemde bir yetkili_keys dosyası oluşturmam gerekiyor mu?

DÜZENLEME: Ssh -vvv -i id_rsa [youruser] @ [yourLinode] çalıştırdığımda aldığım budur

debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).
    
sordu Pattle 22.06.2013 23:20

17 cevap

66

PubKeyAuthentication

Müşterinizi ayarlayın

  1. Anahtarınızı oluşturun
    • ssh-keygen
  2. Anahtarı kullanmak için ssh'i yapılandırma
    • vim ~/.ssh/config
  3. Anahtarınızı sunucunuza kopyalayın
    • ssh-copy-id -i /path/to/key.pub SERVERNAME

2. adım adresindeki yapılandırma dosyanızın aşağıdakine benzer bir şeye sahip olması gerekir:

Host SERVERNAME
Hostname ip-or-domain-of-server
User USERNAME
PubKeyAuthentication yes
IdentityFile ./path/to/key

Sorun giderme

  1. "-vvv" seçeneğini kullan
  2. Sunucunuzun KAMU anahtarının (.pub) olduğundan emin olun.
  3. IdentiyFile öğenizin PRIVATE anahtarınıza işaret ettiğinden emin olun.
  4. .ssh dizininizin 700 olduğundan ve dosyalarınızın 700 izin (rwx ------) olduğundan emin olun.
  5. Giriş yapmaya çalıştığınızda tail -f /var/log/auth.log (sunucuda) ve hataları izleyin
verilen cevap earthmeLon 23.06.2013 23:04
39

Bazen sorun, izinlerden ve sahiplikten geliyor. Örneğin, root olarak giriş yapmak istiyorsanız, /root , .ssh ve authorized_keys köküne ait olmalıdır. Aksi takdirde, sshd onları okuyamayacaktır ve bu nedenle kullanıcının giriş yapmaya yetkili olup olmadığını anlayamayacaktır.

Ev dizininizde:

chown -R your_user:your_user .ssh

Haklar için, .ssh ve 700 için authorized_keys

için 700 ile devam edin

chmod 700 .ssh
chmod 600 .ssh/authorized_keys
    
verilen cevap Buzut 15.03.2016 12:50
12

Müşterinizde authorized_keys değerine ihtiyacınız yok.

Ssh istemcisini, oluşturduğunuz anahtarı gerçekten kullanmasını söylemelisiniz. Bunu yapmanın birkaç yolu var. Sadece ssh -vvv -i .ssh/id_rsa [youruser]@[yourLinode] türünü test etmek için. Sunucuya bağlanmak istediğinizde parolanızı belirtmeniz gerekir.

Eğer bu işe yaradıysa, anahtarı ssh-agent ile ssh-add .ssh/id_rsa 'ye ekleyebilirsiniz (bunun için parolanızı yalnızca bir kez girmeniz ve oturumu kapatma / yeniden başlatmadığınız sürece çalışması gerekir)

    
verilen cevap guntbert 22.06.2013 23:42
7

Ayrıca, kullanıcının giriş dizininin (sunucuda) kullanıcının ssh'ing'inin içerisine ait olduğundan emin olun (köküme ayarlanmıştı).

Olmalıydı:

sudo chown username:username /home/username;
    
verilen cevap canoodle 20.04.2015 21:07
6

Ayrıca PasswordAuthentication değerindeki co_de% değerini ve /etc/ssh/sshd_config değerini no olarak değiştirin. Bundan sonra ssh hizmetini yeniden başlatmayı unutmayın.

    
verilen cevap iman 09.02.2017 11:11
5

Sahip olduğum problem, müşterinin yanlış anahtarlarını kullanıyordu. Ben id_rsa ve id_rsa.pub başka bir şeye yeniden isim vermiştim. Onları varsayılan değerlerine yeniden adlandırabilir veya ssh komutunu verdiğinizde, bu şekilde kullanabilirsiniz

ssh -i ~/.ssh/private_key [email protected]
    
verilen cevap Todd 04.02.2017 23:28
2

Son zamanlarda web sunucumla bu konuya girdim.

Genellikle, tüm sunucularda yetkilendirilmiş anahtarların bir listesini ~/.ssh/authorized_keys2 dizininde tutuyorum. Deneyimden sshd , varsayılan olarak ~/.ssh/authorized_keys veya ~/.ssh/authorized_keys2 değerini arayacak.

Web sunucumda, /etc/ssh/sshd_config bu satıra sahipti

AuthorizedKeysFile    %h/.ssh/authorized_keys

yerine

AuthorizedKeysFile    %h/.ssh/authorized_keys2

Sonrakini uyguladım, ssh daemon'umu yeniden başlattım ve pubkey'i kullanarak ssh ile giriş yaptığım sorunu çözdüm.

    
verilen cevap Justin C 24.11.2013 06:55
1

Benim durumum, müşteri 14.04 lts, ​​sunucu 2012 cygwin çalıştıran win 2012 oldu. Cygwin'deki 2012 sunucu dizini / home / Administrator olduğunda 'ssh [email protected]' kullanıyordum. Bu yüzden, 'ssh [email protected]' (Yönetici A başlığını not edin) denediğimde durum hassastı, o zaman iyi çalıştı.

'Kullanıcı bulunamadı' gibi bir hata mesajı, çözümü 'İzin reddedildi (publickey, klavye-etkileşimli)' den çok daha hızlı bir şekilde bana yönlendirirdi.

    
verilen cevap Kent 12.07.2016 04:41
1

Düzenli bir kullanıcının (ör. johndoe) genel anahtarı bir cPanel Centos sisteminden AWS'deki bir Ubuntu sunucusuna kopyalanırken aynı sorunla karşılaştım. Yukarıdaki gertvdijk tarafından önerildiği gibi /var/log/auth.log işaretledim ve% co_de dediğinden emin oldum %. Tersine, Authentication refused: bad ownership or modes for directory /home/johndoe değerini apache2 için varsayılan virtualhost Document Root olarak ayarlamaya çalışırken /home/johndoe co_de% yanlış girdim (bu görev için de gerekli değildir).

Ayrıca bkz. buradaki ve here

Sunucunun yalnızca /home/johndoe/public_html 'de ortak anahtar olması ve istemci (üzerinde çalıştığınız bilgisayarın) özel anahtarının olması gerekir (.pem veya SFTP with Filezilla, .ppk kullanılıyorsa)

    
verilen cevap site80443 07.01.2017 22:54
1

Bu konuya gelen benim gibi Putty kullanıcıları için, kullanıcı @ Ip! 'i eklemeyi unuttuysanız, bu hatayı da alabilirsiniz!

Diğerleri, 600 chmod anahtar dosyasında izin alıyor)

ssh 1.1.1.1 -i /path/to/.pem file 
Permission denied (publickey).'

ssh [email protected] -i /path/to/.pem file 
    
verilen cevap Alex Punnen 28.03.2017 13:06
1

Bu benim için işe yaradı, düzeltme benim değil ama başka birinin de aynı sorunu olması durumunda yazmayı tercih ederim.

Orijinal yazar buraya gönderdi: dijital okyanus -kamu-access-anahtar reddedildi

sudo nano /etc/ssh/sshd_config

Bunu değiştirin

UsePAM yes
IgnoreUserKnownHosts no
PasswordAuthentication no

Bununla

UsePAM no
IgnoreUserKnownHosts no
PasswordAuthentication yes

Dosyayı kaydedin ve ssh'i yeniden başlatın

reload ssh

ssh şimdi bir şifre sormaya çalışmalı

    
verilen cevap mau 08.04.2017 03:25
1

Soruda açıklananla aynı sorunu yaşadım. İstemci makinede ssh -vvv -i id_rsa [youruser]@[yourLinode] yürütme çıktısı, soruda anlatılana benzer çıktı. Diğer dosyalarda tavsiye edilen tüm dosya ve dizin izinlerini kontrol ettim ve doğruydular.

Oluşturulan dosya id_rsa.pub 'yi sunucu makinesine kopyalarken, ~username/.ssh/authorized_keys dosyası olarak, ssh-rsa kelimesini yanlışlıkla göndermeyi ihmal ettim. Bunu ekledikten sonra çözüldü. sorun.

    
verilen cevap Teemu Leisti 16.05.2017 11:41
0

Tüm diğerleri başarısız olursa, giriş kullanıcınızın ssh'in AllowedGroup'a ait olduğunu doğrulayın. Diğer bir deyişle, kullanıcılarınız, aşağıdaki satırda gösterilen grubun bir üyesidir: sunucudaki /etc/ssh/sshd_config :

AllowGroups ssh #Here only users of 'ssh' group can login
    
verilen cevap biocyberman 17.10.2014 08:21
0

Başka bir olası neden, AllowedUsers dizinindeki /etc/ssh/sshd_conf yapılandırmasıyla olabilir. NOT: liste, zor yoldan öğrendiğim için boşluk sınırlandırılmıştır (virgülle sınırlandırılmamış).

AllowUsers user1 user2 user3
    
verilen cevap cmbind55 03.09.2015 19:07
0

Benim durumumda, sorun, daha eski bir makineden .ssh dizininin kopyalanmasıyla gerçekleşti. Eski SSH yapılandırmamın, o zamandan beri kullanımdan kaldırılmış olan DSA anahtarlarını kullandığı ortaya çıkıyor. RSA tabanlı bu sefer yeni bir tuşa geçmek benim için problemi çözdü.

    
verilen cevap Glutanimate 01.10.2017 22:16
0

machineA ve machineB'ye bağımsız olarak (örn., makine C'den) erişebiliyorsanız, aşağıdaki yöntem işe yarayabilir.

ssh-copy-id çalışmıyorsa, parola doğrulaması devre dışı bırakılabilir. Aşağıdaki bir geçici çözümdür .

machineB'nin makinenin genel anahtarında machineB'nin yetkili tuşları (yani ~ / .ssh / authorized_keys) makinenizi A'dan ssh yapmanıza izin verir. Bu aynı zamanda scp için de geçerlidir.

Anahtar çiftleri oluşturduktan sonra: ssh-keygen

MakinedeA , cat ~/.ssh/id_rsa.pub

komutunu çalıştırın

Örnek çıktı:

  

ssh-rsa AAAAB3NzaSGMFZW7yB [email protected]

Yazdırılan anahtarı ( ⌘ Komutu + C veya CRTL + C ) kopyalayın ve ardından machineB adresindeki ~ / .ssh / authorized_keys dosyası.

Örneğin, machineB 'de aşağıdakileri uygulayın:

  

echo 'ssh-rsa AAAAB3NzaSGMFZW7yB [email protected]' >> ~/.ssh/authorized_keys

    
verilen cevap anask 25.03.2018 07:11
0

Ubuntu 16.04 üzerinde de çalışır.

Sorun sshd_config dosyasında

İşte ULTIMATE çözümü:

Ubuntu sunucusuna kök olarak giriş yapın

vi /etc/ssh/sshd_config

Şimdi çok alçaltın ve değeri "hayır" dan "evet" e değiştirin.

Şunun gibi görünmelidir:

Tünel açık metin şifrelerini devre dışı bırakmak için no'ya geçin

PasswordAuthentication yes
service sshd reload

etkilenmek için.

Artık LOCAL makinenizden aşağıdaki komutu kullanarak bir tuşa basabilirsiniz (dizüstü bilgisayar vb.)

Yeni terminal penceresini aç ve sunucuya giriş yap, sadece şu komutu yaz:

ssh-copy-id john @ serverIPAddress

(john'u kullanıcı adınızla değiştirin).

gitmelisin

    
verilen cevap Galapagos 18.07.2018 22:22

Etiketlerdeki diğer soruları oku