Tidak bisa mendapatkan otentikasi kunci publik SSH bekerja [ditutup]


41

Server saya menjalankan CentOS 5.3. Saya menggunakan Mac yang menjalankan Leopard. Saya tidak tahu yang bertanggung jawab untuk ini:

Saya dapat masuk ke server saya dengan baik melalui otentikasi kata sandi. Saya telah melalui semua langkah untuk menyiapkan PKA (seperti yang dijelaskan di http://www.centos.org/docs/5/html/Deployment_Guide-en-US/s1-ssh-beyondshell.html ), tetapi ketika Saya menggunakan SSH, bahkan menolak untuk mencoba verifikasi publickey. Menggunakan perintah

ssh -vvv user@host

(di mana -vvv mengangkat verbosity ke level maksimum) Saya mendapatkan output yang relevan berikut:

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

diikuti oleh prompt untuk kata sandi saya. Jika saya mencoba untuk memaksa masalah ini

ssh -vvv -o PreferredAuthentications=publickey user@host

saya mendapat

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.

Jadi, meskipun server mengatakan menerima metode otentikasi publickey, dan klien SSH saya bersikeras, saya ditolak. (Perhatikan tidak adanya garis "Penawaran kunci publik:" di atas.) Ada saran?

ssh 

cukup gunakan "ssh -v" Anda tidak perlu lebih banyak verbositas dan termasuk seluruh output tidak hanya garis yang Anda anggap penting
cstamas

Pertanyaan ini sedang ditutup karena tidak lagi dapat dijawab, dan menarik jawaban berkualitas rendah.
Putus

Jawaban:


44

Periksa apakah mesin Centos Anda memiliki:

RSAAuthentication yes
PubkeyAuthentication yes

di sshd_config

dan pastikan bahwa Anda memiliki izin yang tepat pada direktori ~ / .ssh / direktori mesin centos.

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

harus melakukan trik.


1
hak dan nama file yang benar (kadang-kadang disahkan_keys2, terkadang tanpa 2) sangat penting!
brandstaetter

4
Izin file berwenang_kunci adalah petunjuk yang sangat penting. Terima kasih.
Kane

7
Anda mungkin juga perlu melakukannya chmod go-w ~/jika belum.
tylerl

1
Juga periksa apakah dir rumah Anda di server jarak jauh memiliki izin 755(seperti yang dikatakan Jinyu Liu di bawah ini)
Attila Fulop

1
Dalam sistem operasi lain file konfigurasi SSH juga bisa hidup di bawah:/etc/ssh/ssh_config
Yoshua Wuyts

17

Saya memiliki masalah serupa - PC jarak jauh tidak dapat menggunakan otentikasi kunci publik untuk masuk ke server CentOs 6. Masalah dalam kasus saya terkait SELinux - direktori home pengguna yang mencoba masuk memiliki pesan tentang konteks keamanan. Saya menyelesaikan ini dengan menggunakan restoreconalat sebagai berikut:

restorecon -Rv /home

2
Terima kasih, Gareth! "restorecon -Rv /root/.ssh" melakukan trik dengan baik.
tbroberg

Untuk menjelaskan lebih lanjut: perintah ini memberitahu SELinux untuk mereset tag SELinux untuk file di bawah /homeapa pun yang biasanya ada dalam tata letak direktori /home.
rakslice

Jika Anda masuk sebagai root, itu seharusnyarestorecon -Rv /root
youfu

13

1- periksa / etc / ssh / sshd_config Anda, pastikan sudah

RSAAtentikasi ya
PubkeyAuthentication ya

2 - periksa log aman dari mesin jarak jauh, lihat detail daemon sshd error log. misalnya di Ubuntu saya

# grep 'sshd' / var / log / secure | grep 'Otentikasi ditolak' | ekor -5
4 Agustus 06:20:22 xxx sshd [16860]: Otentikasi ditolak: kepemilikan buruk atau mode untuk direktori / home / xxx
4 Agustus 06:20:22 xxx sshd [16860]: Otentikasi ditolak: kepemilikan buruk atau mode untuk direktori / home / xxx
4 Agustus 06:21:21 xxx sshd [17028]: Otentikasi ditolak: kepemilikan buruk atau mode untuk direktori / home / xxx
4 Agustus 06:21:21 xxx sshd [17028]: Otentikasi ditolak: kepemilikan buruk atau mode untuk direktori / home / xxx
4 Agustus 06:27:39 xxx sshd [20362]: Otentikasi ditolak: kepemilikan buruk atau mode untuk direktori / home / xxx

Kemudian periksa kepemilikan dan mode untuk direktori / home / xxx, mungkin Anda perlu menjalankan ini

chmod 755 / home / xxx

1
Periksa log file sistem adalah petunjuk yang sangat penting.
Kane

1
Perm direktori home 755 membantu saya - pasti diperlukan!
Ben

11

Periksa kembali apakah izin Anda benar dan struktur file (khususnya ejaan) sudah benar, baik untuk mesin lokal maupun jarak jauh. URL yang Anda referensikan menyatakan semuanya, tetapi ada baiknya memeriksa apa yang Anda cocokkan. Biasanya izin akan menimbulkan kesalahan yang relevan.

Sudahkah Anda memeriksa bahwa sshd_config pada kotak CentOS 5.3 Anda diatur untuk mengizinkan PubkeyAuthentication atau RSAAuthentication?

Periksa log server SSH pada sistem CentOS - mungkin memberikan informasi lebih lanjut. Saya tidak yakin apakah CentOS melakukan kunci ssh blacklist memeriksa apakah debian melakukannya, tetapi saya telah melihat penolakan ssh publickey yang relatif diam sejauh keluaran -vvv berjalan, tetapi log cukup jelas menjelaskan apa yang sedang terjadi


7

Oke! Ternyata itu adalah masalah sisi klien. (Saya pikir setiap masalah sisi server akan menghasilkan keluaran debug yang lebih berguna.) Untuk alasan yang tidak diketahui oleh saya, pada Mac saya, file / etc / ssh_config memiliki baris

PubkeyAuthentication = no

Saya berkomentar satu baris, dan sekarang semuanya berfungsi dengan baik.


4

Selain mode file / direktori, pastikan kepemilikannya benar! Seorang pengguna harus memiliki direktori home sendiri, .ssh /, dan file di dalamnya.

Saya harus berlari chown -R $user:$user /home/$useruntuk melewati kegagalan ssh saya.


+1, di salah satu sistem saya, izin pada .ssh benar tetapi seseorang telah membuat direktori home akun 777.
GargantuChet

2

Juga periksa apakah ia dapat memasok kunci secara otomatis atau tidak, gunakan jalur -i / ke / kunci jika tidak atau hanya untuk menguji


2

Kedengarannya seperti masalah konfigurasi bagi saya. Seperti yang disarankan Daniel, ada dua hal yang perlu diperiksa:

  1. Kunci SSH di $HOME/.ssh/authorized_keysdapat dibaca; dan
  2. SSHd dikonfigurasi untuk memungkinkan masuknya kunci publik.

2

Periksa nama pengguna dengan yang Anda coba masuk. Secara default itu adalah nama pengguna Anda di mesin lokal.


1

Keluaran klien seperti pada ssh -vakan mengungkapkan bahwa ada masalah pada langkah tertentu dalam protokol, tetapi ketika itu karena sesuatu di server klien tidak akan diberitahu penyebabnya. Periksa file log server untuk mencari tahu apa yang salah. Anda mungkin harus rootmemiliki izin untuk melakukannya. Misalnya, untuk yang sshddikonfigurasi untuk masuk ke syslog, Anda mungkin menemukan pesan di /var/log/secure. Seperti yang ini:

Authentication refused: bad ownership or modes for directory /home/you/.ssh
Authentication refused: bad ownership or modes for file /home/you/.ssh/authorized_keys

Alasan dalam kasus ini adalah default (bodoh) defaultdari 0002. Itu artinya, tulis akses untuk grup. (Groupname = nama pengguna, tapi tetap saja.) Daemon SSH tidak akan mempercayai file yang dapat dirusak oleh orang lain selain pengguna (well, dan root, tentu saja). Anda dapat memecahkan masalah menggunakan chmod.

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

1

Saya baru saja terjebak dalam masalah yang sama mengakses dengan fedora core 16 hingga 5,5 sen

log dan verbose tampak persis sama

masalahnya adalah kunci publik, ia mendapatkan beberapa data palsu, memperbaruinya dan mempostingnya di sshd_server, Anda sshd_client mengirim informasi kunci tetapi tidak dikenali oleh server (itu tidak cocok dengan salah satu kunci di otor_keys)


-2

Lain digigit oleh ini. Setelah pencarian panjang ternyata saya secara eksplisit memberi makan ssh kunci publik (dengan opsi -i) alih-alih kunci pribadi. Doh!

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.