Ssh anahtarı ana bilgisayar tarafından kabul edildi, ancak istemci bağlantısı kesildi

Helo,

Fedora 23 kurulumundan sonra SSH ile ilgili bir sorunum var.

Özel anahtarla uzak ana makineme bağlanmak istemediğimde, ana bilgisayar anahtarı bulur:

debug1: matching key found: file /home/theo/.ssh/authorized_keys, line 1 RSA {REDACTED}
debug1: restore_uid: 0/0
Postponed publickey for theo from {REDACTED} port 60351 ssh2 [preauth]
Connection closed by {REDACTED} [preauth]
debug1: do_cleanup [preauth]
debug1: monitor_read_log: child log fd closed

Ama gördüğünüz gibi, müşterim kendisiyle bağlantıyı kesti

debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /home/tbouge/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey).

Aynı özel anahtarı kullanarak pencerelerdeki macunla ev sahibime bağlanabiliyorum ve farklı bir özel anahtar kullanarak telefonuma bağlanabiliyorum.

Herhangi bir fikrin var mı ?

/ Etc / SSH / ssh_conf

Host *
        GSSAPIAuthentication yes
# If this option is set to yes then remote X11 clients will have full access
# to the original X11 display. As virtually no X11 client supports the untrusted
# mode correctly we set this to yes.
        ForwardX11Trusted yes
# Send locale-related environment variables
        SendEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
        SendEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
        SendEnv LC_IDENTIFICATION LC_ALL LANGUAGE
        SendEnv XMODIFIERS

teşekkür ederim

Edit: Bir şifre ile bağlanabilirim

Her şeyden önce, ortak anahtar tabanlı kimlik doğrulamanın nasıl ayarlanacağı veya yapılandırılacağı hakkında çok sayıda, çok iyi yazılmış, ayrıntılı belgesel çevrimiçi olarak mevcuttur. Lütfen bunlardan birine bir göz atın ve her şeyi doğru bir şekilde izleyip izlemediğinizi görün. İşte bir tane. Bu yüzden tekrar etmeyeceğim.

En temel kavram ( buradan kopyalanır ):

Anahtar tabanlı kimlik doğrulama, biri herkesin görmesine izin verilen bir "ortak" anahtar ve yalnızca sahibinin görmesine izin verilen başka bir "özel" anahtar olmak üzere iki anahtar kullanır. Anahtar tabanlı kimlik doğrulamayı kullanarak güvenli bir şekilde iletişim kurmak için, bir anahtar çifti oluşturmanız, özel anahtarı oturum açmak istediğiniz bilgisayarda güvenli bir şekilde saklamanız ve ortak anahtarı oturum açmak istediğiniz bilgisayarda depolamanız gerekir.

Şimdi gönderdiğiniz hata ayıklama günlüğünden:

• İki farklı kullanıcının dahil olduğu görülüyor. /home/theo/.ssh/authorized_keysve /home/tbouge/.ssh/id_rsa. Bir kullanıcı olarak başka bir kullanıcının ana dizininde oturum açmaya mı çalışıyorsunuz?
• Hata Postponed publickey for theo.., publick key yönteminden önce istenmeyen kimlik doğrulama yönteminin denendiği anlamına gelir. SSH, yapılandırmada etkinleştirilen her kimlik doğrulama yöntemini birbiri ardına deneyecektir. Sizin durumunuzda GSSAPIAuthentication yeskullanmadığınız şeyleri etkinleştirdiniz. Bunu yaparak güvenli bir şekilde devre dışı bırakabilirsiniz GSSAPIAuthentication no.
• debug2: we did not send a packet, disable methodbüyük olasılıkla özel anahtar dosyasını (dosya izni veya ad sorunu) işleyememesidir. SSH, hem yerel hem de uzak bilgisayarlardaki dizin ve dosya izinleri konusunda çok hassastır. ( chown user_name:user_group -R /home/user, chmod 700 /home/.ssh, chmod 600 /home/.ssh/authorized_keys). Bu nedenle, doğru ayarlandığından emin olun. Şuna bakın: /unix/131886/ssh-public-key-wont-send-to-server

• Üçüncü hataya gelince: Permission denied (public key).kontrol edilecek birkaç şey var.

  • Yanlış kullanıcı adı
  • Yanlış anahtar çifti

  • Yanlış hedef ana bilgisayar

    • Daha fazla ayrıntı: /programming/18551556/permission-denied-publickey-when-ssh-access-to-amazon-ec2-instance .

Aşağıdaki bölüm biraz kafa karıştırıcı:

debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 1047
debug2: input_userauth_pk_ok: fp SHA256:{REDACTED}
debug3: sign_and_send_pubkey: RSA SHA256:{REDACTED}
debug2: we did not send a packet, disable method

Daha iyi anlamak için, digitalocean'da açıklandığı gibi kimlik doğrulama sürecini adım adım izleyelim :

1. İstemci, sunucuya kimlik doğrulaması yapmak istediği anahtar çifti için bir kimlik göndererek başlar.
2. Sunucu denetimi, istemcinin anahtar kimliği için oturum açmaya çalıştığı hesabın yetkili_anahtarlar dosyasıdır.
3. Dosyada eşleşen kimliğe sahip bir ortak anahtar bulunursa, sunucu rasgele bir sayı oluşturur ve numarayı şifrelemek için ortak anahtarı kullanır.
4. Sunucu istemciye bu şifreli iletiyi gönderir.
5. İstemci aslında ilişkilendirilmiş özel anahtara sahipse, o numarayı kullanarak iletinin şifresini çözebilir ve orijinal numarayı gösterebilir.
6. İstemci, şifresi çözülen sayıyı iletişimi şifrelemek için kullanılan paylaşılan oturum anahtarıyla birleştirir ve bu değerin MD5 karmasını hesaplar.
7. Istemci daha sonra bu MD5 karma sunucuya şifreli sayı iletisi yanıt olarak geri gönderir.
8. Sunucu, MD5 değerini kendi başına hesaplamak için aynı paylaşılan oturum anahtarını ve istemciye gönderdiği özgün sayıyı kullanır. Kendi hesaplamasını, müşterinin geri gönderdiği hesaplamayla karşılaştırır. Bu iki değer eşleşirse, istemcinin özel anahtara sahip olduğunu ve istemcinin kimliğinin doğrulandığını kanıtlar.

Sizin durumunuzda, görebileceğiniz gibi, uzak bilgisayar yalnızca kabul etti public key, paketi o anahtarla şifreledi ve istemci bilgisayara geri gönderdi. Şimdi istemci bilgisayarın doğru olduğunu kanıtlaması gerekiyor private key. Sadece sağ private_key ile alınan mesajın şifresini çözebilir ve geri cevap gönderebilir. Bu durumda, istemci bunu yapamaz ve kimlik doğrulama işlemi başarıyla sonuçlandırılır.

Umarım bu, sorunları anlamanıza yardımcı olur ve çözer.

Ssh dosyalarınızdaki ayrıcalıklar doğru mu?

.ssh Klasörü -> 700

genel anahtar -> 644

özel anahtar -> 600

Kullanıcı ve grubu da kontrol et

Bir Windows makinesinde aynı anahtarın olduğunu söylüyorsunuz; Linux makinenizdeki özel anahtar dosyasının doğru olduğundan emin misiniz? Belki de özel anahtar ssh'ın kolay anlayamayacağı bir macun biçimindedir. Her durumda, yanlış veya geçersiz bir özel anahtar dosyası koyarsam, sahip olduğunuz hatayla tam olarak aynı hatayı alıyorum.

Sorunu gidermek için, başka bir makineden bir anahtarı yeniden kullanmak yerine Linux makinesinde yeni bir anahtar oluşturmak daha uygun olacaktır. Yeni ortak anahtarı ana bilgisayardaki yetkili_anahtarlar dosyasına ekleyebilir ve ardından hem Windows'tan Windows anahtarını hem de Fedora'dan yeni Linux anahtarını kullanabilirsiniz.

senin sorunun oldukça yaygın ve aynı zamanda açık söylüyorum.

 Permission denied (publickey).

bu senin için bir şey ifade ediyor mu? benim için bu çok önemli.

pls tarafında selinux runnin varsa sunucu tarafında kontrol edebilirsiniz? değilse bana hangi modun çalıştığını söyle.

Ayrıca, bir deneme daha yapabilir ve bu girişimin denetim günlüklerini yakalayabilir ve buraya gönderirseniz, bize nedenini kesinlikle söyleyecektir:

  tail -f /var/log/audit/audit.log  (and try to attempt)

Açık olan ancak dosya izni olmayan izin sorunudur :-)

Sorun (benim durumumda ...) anahtar türünden kaynaklanıyor gibi görünüyor.

Şimdi yerel ~/.ssh/configdosyaya (Fedora 23 istemci makinesi) aşağıdakileri ekleyerek çözdüm:

PubkeyAcceptedKeyTypes=+ssh-dss

Bu satırı hem sunucuya hem de istemci yapılandırma dosyasına eklemiş olmama rağmen, yalnızca istemci tarafı fark yarattı. 600Yapılandırma dosyasının okunabilmesi için izinlerin olması gerektiğini unutmayın .

Başkasının hala bu sorunu olup olmadığını bilmiyorum, ama sonunda sorunu yaşayan bir makinem (bir dizüstü bilgisayar) için çözdüm. Ben inanıyorum Sonunda bunu dizildi biliyorum ve bunu herkesten hala bu karşılaşmadan olabilir yardımcı olacaktır umuduyla burada bilgi bırakacağım - ve aynı zamanda bu yüzden birisi umarım benim çözüm ve onaylamak kontrol edebilirsiniz aslında ne olduğunu sorunu çözdü.

Sorun, ortaya çıktığı gibi, SSH ile (benim için) hiç değil, PAM'ın anahtarlarımı nasıl yapılandırdığıydı. Konfigürasyon /etc/pam.dgüncel değil (Fedora 22 aracılığıyla düzgün çalışmasına rağmen) ve sonuç olarak anahtarlarımı almak için [artık] girişte doğru şeyler yapılmadı $HOME/.ssh/. Bu komutu çalıştırmak:

# sudo authconfig --updateall

/etc/pam.d yapılandırmasını düzgün bir şekilde yeniden oluşturun. Bir sonraki yeniden başlatmada, oturum açtıktan sonra sunucuma ilk kez ssh denemeye çalıştığımda, bir iletişim kutusu benden ssh anahtarım ( $HOME/.ssh/id_rsa) için parolamı girmemi istedi . Bunu yaptım, "Girişte otomatik olarak kilidini aç" kutusunu işaretledim ve voila! Dizüstü bilgisayardan ssh yeteneğim geri yüklendi.

Arka fon

Bu sorunu çözmeme neden olan ipucu, harici bir kaynaktan bir RSA anahtarı içe aktardığımda ortaya çıktı. (Ben taşımak USB anahtar, benim ev ağı için "uzaktan erişim" tuşuyla. Ben önce sisteme girilmiş sonra benim dışa bakan sunucu yıllara PasswordAuth kapatmış.) Sonra ssh-add-ing OLDUĞUNU RSA anahtarını oturan biri aksine $HOME/.ssh/id_rsa, uzak sunucu tarafından sorunsuz kabul edildi.

Sonra işten ssh-addçıkarmak için gereksiz olması gerekeni yaptım $HOME/.ssh/id_rsa. Bunu yaptıktan sonra , aynı anahtar için iki giriş ssh-add -liçerdiğini fark ettim :

% ssh-add -l
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX id_rsa (RSA)
2048 SHA256:XXXXXXXXXXXXXXXXXXXXXX me@host (RSA)
2048 SHA256:YYYYYYYYYYYYYYYYYYYYYY imported@usbkey (RSA)

İki girişten birinin anahtar tanımlayıcısını nasıl göstermediğine, yalnızca genel imzasıyla eşleşen özel anahtar dosya adına dikkat edin. Özel anahtar gerçekten anahtar yöneticisi tarafından açılmamış gibi.

Tam olarak olanın bu olduğuna inanıyorum ve PAM, parola ile kilidi açılmamış olan SSH ajanına "kötü anahtarlar" geçiriyordu. Bu nedenle, ssh anahtarla kimlik doğrulaması yapmaya çalıştığında, anahtar çiftinin (kilidi açılmış) özel yarısına sahip değildi ve bu nedenle kimlik doğrulama başarısız oldu.

Bu son bit varsayımdır, ancak herhangi biri F24'e yükselttikten sonra uzak ana bilgisayarlar tarafından kabul edilmeyen ssh anahtarları ile ilgili sorun yaşıyorsa, F23'e yükselttikten sonra, /etc/pam.d/dizini yeniden oluşturmak authconfigbir çözüm olarak denemeye değer.

Kullanıcı giriş dizini izinlerini kontrol edin. Bu önemli. 755 olmalı. 700 veya 770 çalışmayacak.

Gözlerinde farklı ssh_config, uncommenting ve / veya ekleme / çıkarma / ya eklemeden deneyin Cipher, Ciphersya da MACshat (lar).

Bana öyle geliyor ki sshd, isteğinize dahil edilmeyen bir tür belirli bir şifre arıyor ssh_config.

... ve hiçbir şekilde uzak sunucuda PubkeyAuthenticationayarlamadığınızı varsayıyorum no, çünkü bu kesinlikle başarısız olmasına neden olur.