Kunci ssh diterima oleh host tetapi klien terputus

Halo,

Saya memiliki masalah dengan SSH setelah instalasi fedora 23.

Ketika saya tidak ingin terhubung ke host jarak jauh dengan kunci pribadi, host saya menemukan kunci:

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

Tetapi ketika Anda melihat klien saya memutuskan sendiri

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

Saya dapat terhubung ke host saya dengan dempul di windows menggunakan kunci pribadi yang sama dan saya dapat terhubung dengan ponsel saya menggunakan kunci pribadi yang berbeda.

Apakah kamu punya ide ?

/ 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

Terima kasih

Sunting: Saya dapat terhubung dengan kata sandi

Pertama-tama, ada banyak dokumen yang ditulis dengan sangat baik dan terperinci tentang cara mengatur atau mengkonfigurasi otentikasi berbasis kunci publik yang tersedia secara online. Silakan lihat salah satunya dan lihat apakah Anda telah mengikuti semuanya dengan benar. Ini satu. Jadi saya tidak akan mengulanginya lagi.

Konsep yang sangat mendasar adalah (disalin dari sini ):

Otentikasi berbasis kunci menggunakan dua kunci, satu kunci "publik" yang dapat dilihat siapa saja, dan kunci "pribadi" lain yang hanya dapat dilihat oleh pemiliknya. Untuk berkomunikasi secara aman menggunakan otentikasi berbasis kunci, seseorang perlu membuat pasangan kunci, menyimpan kunci privat dengan aman di komputer yang ingin diajak masuk, dan menyimpan kunci publik di komputer yang ingin di-login.

Sekarang dari log debug yang telah Anda posting:

• Tampaknya ada dua pengguna berbeda yang terlibat. /home/theo/.ssh/authorized_keysdan /home/tbouge/.ssh/id_rsa. Apakah Anda mencoba masuk sebagai satu pengguna ke direktori home pengguna lain?
• Kesalahan tersebut Postponed publickey for theo..berarti metode otentikasi yang tidak diinginkan telah dicoba sebelum metode kunci publick. SSH akan mencoba setiap metode authetikasi yang diaktifkan di konfigurasi, satu demi satu. Dalam kasus Anda, Anda telah GSSAPIAuthentication yesmengaktifkan apa yang tidak Anda gunakan. Anda dapat dengan aman menonaktifkannya dengan melakukan GSSAPIAuthentication no.
• debug2: we did not send a packet, disable methodkemungkinan besar itu tidak dapat memproses file kunci pribadi (baik izin file atau masalah nama). SSH sangat sensitif tentang izin direktori dan file di komputer lokal dan jarak jauh. ( chown user_name:user_group -R /home/user, chmod 700 /home/.ssh, chmod 600 /home/.ssh/authorized_keys). Jadi, pastikan milik Anda diatur dengan benar. Lihat ini: /unix/131886/ssh-public-key-wont-send-to-server

• Adapun kesalahan ketiga:, Permission denied (public key).ada beberapa hal yang perlu diperiksa.

  • Nama pengguna salah
  • Pasangan kunci salah

  • Host target salah

    • Berikut ini rincian lebih lanjut: /programming/18551556/permission-denied-publickey-when-ssh-access-to-amazon-ec2-instance .

Bagian berikut sedikit membingungkan:

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

Untuk memahaminya dengan lebih baik, mari kita pergi melalui proses otentikasi langkah demi langkah seperti yang dijelaskan di sini di digitalocean :

1. Klien mulai dengan mengirimkan ID untuk pasangan kunci yang ingin diautentikasi ke server.
2. Server memeriksa file otor_keys dari akun yang sedang dicoba klien untuk masuk ke ID kunci.
3. Jika kunci publik dengan ID yang cocok ditemukan dalam file, server menghasilkan nomor acak dan menggunakan kunci publik untuk mengenkripsi nomor tersebut.
4. Server mengirimkan pesan terenkripsi kepada klien ini.
5. Jika klien benar-benar memiliki kunci pribadi terkait, itu akan dapat mendekripsi pesan menggunakan kunci itu, mengungkapkan nomor aslinya.
6. Klien menggabungkan angka yang didekripsi dengan kunci sesi bersama yang digunakan untuk mengenkripsi komunikasi, dan menghitung hash MD5 dari nilai ini.
7. Klien kemudian mengirimkan hash MD5 ini kembali ke server sebagai jawaban untuk pesan nomor terenkripsi.
8. Server menggunakan kunci sesi bersama yang sama dan nomor asli yang dikirim ke klien untuk menghitung nilai MD5 sendiri. Ini membandingkan perhitungannya sendiri dengan yang dikirim kembali oleh klien. Jika kedua nilai ini cocok, itu membuktikan bahwa klien memiliki kunci pribadi dan klien diautentikasi.

Dalam kasus Anda, seperti yang Anda lihat, komputer jarak jauh hanya menerima Anda public key, mengenkripsi paket dengan kunci itu dan mengirimkannya kembali ke komputer klien. Sekarang komputer klien perlu membuktikan bahwa ia memiliki hak private key. Dengan hanya private_key yang tepat itu dapat mendekripsi pesan yang diterima dan mengirim jawaban kembali. Dalam hal ini, klien gagal melakukan itu dan proses otentikasi berakhir tanpa hasil.

Saya harap ini membantu Anda untuk memahami masalah dan menyelesaikannya.

Apakah hak istimewa pada file ssh Anda benar?

Folder .ssh -> 700

kunci publik -> 644

kunci pribadi -> 600

Periksa juga pengguna & grup

Anda mengatakan Anda memiliki kunci yang sama pada mesin windows; apakah Anda yakin file kunci pribadi yang Anda miliki di mesin Linux Anda benar? Mungkin kunci pribadi dalam format dempul yang ssh tidak mengerti dengan mudah. Bagaimanapun, jika saya meletakkan file kunci pribadi yang salah atau tidak valid, saya mendapatkan kesalahan yang sama persis dengan yang Anda miliki.

Untuk memperbaiki masalah, akan lebih tepat untuk membuat kunci baru pada mesin Linux daripada menggunakan kembali kunci dari mesin lain. Anda bisa menambahkan kunci publik baru ke file Authorized_key di host, dan kemudian Anda dapat menggunakan kunci Windows dari Windows dan kunci Linux baru dari Fedora.

masalah Anda tampaknya sangat umum dan juga jelas saya katakan.

 Permission denied (publickey).

apakah itu berarti bagi Anda? bagi saya itu sangat berarti bagi saya.

dapatkah Anda memeriksa sisi server jika Anda memiliki selinux runnin dalam mode yang dipaksakan, pls? jika tidak beri tahu saya mode apa yang dijalankan selinux.

Juga, jika Anda dapat melakukan satu upaya lagi dan menangkap log audit dari upaya itu dan memposting di sini, itu pasti akan memberi tahu kami alasannya:

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

Ini adalah masalah izin yang jelas tetapi tidak mengajukan izin :-)

Tampaknya masalah (dalam kasus saya ...) disebabkan oleh jenis kunci.

Saya baru saja menyelesaikannya dengan menambahkan yang berikut ke ~/.ssh/configfile lokal (mesin klien Fedora 23):

PubkeyAcceptedKeyTypes=+ssh-dss

Meskipun saya telah menambahkan baris itu ke server dan file konfigurasi klien, hanya sisi klien yang membuat perbedaan. Perhatikan bahwa izin harus untuk 600file konfigurasi untuk dibaca.

Saya tidak tahu apakah ada orang lain yang masih mengalami masalah ini, tetapi saya akhirnya menyelesaikannya untuk satu mesin saya (laptop) yang mengalami masalah. Saya percaya saya tahu apa yang akhirnya beres, dan saya akan meninggalkan info di sini dengan harapan itu akan membantu orang lain yang mungkin masih menghadapi ini - dan juga agar seseorang dapat dengan mudah memeriksa solusi saya dan mengkonfirmasi bahwa sebenarnya itulah yang memecahkan masalah.

Masalahnya, ternyata, bukan (bagi saya) dengan SSH sama sekali, tetapi dengan bagaimana PAM mengkonfigurasi kunci saya. Konfigurasi di /etc/pam.dsudah ketinggalan zaman (meskipun itu berfungsi dengan baik melalui Fedora 22), dan sebagai hasilnya hal yang benar tidak dilakukan pada login [lagi] untuk mengambil kunci saya dari $HOME/.ssh/. Menjalankan perintah ini:

# sudo authconfig --updateall

membangun kembali konfigurasi /etc/pam.d dengan benar. Pada reboot berikutnya, setelah saya login, pertama kali saya mencoba ssh ke server saya, sebuah kotak dialog meminta saya untuk memasukkan kata sandi saya untuk kunci ssh saya ( $HOME/.ssh/id_rsa). Saya melakukannya, centang kotak "Secara otomatis membuka kunci masuk", dan voila! Kemampuan saya untuk keluar dari laptop telah dipulihkan.

Latar Belakang

Petunjuk yang mengarahkan saya untuk memecahkan masalah ini datang ketika saya mengimpor kunci RSA dari sumber eksternal. (Kunci USB saya membawa sekitar, dengan saya kunci "akses remote" untuk jaringan rumah saya. Aku mematikan PasswordAuth untuk saya menghadap ke luar server yang tahun lalu setelah intrusi.) Setelah ssh-add-ing YANG kunci RSA, tidak seperti yang duduk di $HOME/.ssh/id_rsa, itu diterima oleh server jauh tanpa masalah.

Lalu saya akhirnya melakukan apa yang seharusnya menjadi berlebihan ssh-add, untuk dijemput $HOME/.ssh/id_rsa. Saya perhatikan bahwa setelah saya melakukannya, ssh-add -lberisi dua entri untuk kunci yang sama:

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

Perhatikan bagaimana salah satu dari dua entri tidak menunjukkan pengidentifikasi kunci, hanya nama file kunci pribadi yang cocok dengan tanda tangan publik. Seolah kunci pribadi tidak benar - benar dibuka oleh manajer kunci.

Saya percaya itulah yang terjadi, dan PAM memberikan "kunci buruk" kepada agen SSH yang tidak dikunci dengan frasa sandi. Jadi, ketika ssh mencoba untuk mengotentikasi dengan kunci, itu sebenarnya tidak memiliki (membuka) setengah pribadi dari pasangan kunci, dan gagal otentikasi.

Bit terakhir itu adalah dugaan, tetapi terlepas dari apakah ada yang mengalami masalah dengan kunci ssh yang tidak diterima oleh host jarak jauh (di mana mereka dulu) setelah memutakhirkan ke F23, membangun kembali /etc/pam.d/direktori menggunakan authconfigpatut dicoba sebagai solusi.

Periksa izin direktori home user. Ini penting. Harus 755. 700 atau 770 tidak akan berfungsi.

Dalam Anda ssh_config, cobalah uncommenting dan / atau menambahkan / menghapus / menambahkan ke salah satu Cipher, Ciphersatau MACsline (s).

Tampaknya bagi saya yang sshdsedang mencari sandi tertentu dari beberapa jenis yang tidak termasuk dalam permintaan, yang dapat ditambahkan dengan mengonfigurasikannya di email Anda ssh_config.

... dan saya berasumsi Anda tidak PubkeyAuthenticationsengaja mengaktifkan noserver jauh, karena itu pasti akan menyebabkan ini gagal.