Mengapa saya mendapatkan "Izin ditolak (publickey)" ketika mencoba SSH dari Ubuntu lokal ke server Amazon EC2?

Saya memiliki instance aplikasi yang berjalan di cloud pada instance Amazon EC2, dan saya harus menghubungkannya dari Ubuntu lokal saya. Ini berfungsi dengan baik di salah satu ubuntu lokal dan juga laptop. Saya mendapat pesan "Izin ditolak (publickey)" ketika mencoba mengakses SSH ke EC2 di Ubuntu lokal lain. Sangat aneh bagi saya.

Saya sedang memikirkan beberapa masalah dengan pengaturan keamanan di Amazon EC2 yang memiliki akses IP terbatas ke satu contoh atau sertifikat mungkin perlu dibuat ulang.

Adakah yang tahu solusi?

Hal pertama yang harus dilakukan dalam situasi ini adalah menggunakan -vopsi untuk ssh, sehingga Anda dapat melihat jenis otentikasi apa yang dicoba dan apa hasilnya. Apakah itu membantu mencerahkan situasi?

Dalam pembaruan Anda untuk pertanyaan Anda, Anda menyebutkan "di Ubuntu lokal lain". Sudahkah Anda menyalin kunci pribadi ssh ke mesin lain?

Seperti yang belum disebutkan secara eksplisit, sshd secara default sangat ketat pada izin untuk authorized_keysfile. Jadi, jika authorized_keysini ditulis bagi siapa pun selain pengguna atau dapat dibuat dapat ditulis oleh siapa pun selain pengguna, itu akan menolak untuk mengotentikasi (kecuali sshd dikonfigurasi dengan StrictModes no)

Apa yang saya maksud dengan "dapat dibuat dapat ditulis" adalah bahwa jika salah satu direktori induk dapat ditulisi untuk siapa pun selain pengguna, pengguna yang diizinkan untuk mengubah direktori tersebut dapat mulai memodifikasi izin sedemikian rupa sehingga mereka dapat memodifikasi / mengganti otor_keys.

Lebih jauh, jika /home/username/.sshdirektori tidak dimiliki oleh pengguna, dan dengan demikian pengguna tidak memiliki izin untuk membaca kunci Anda dapat mengalami masalah:

drwxr-xr-x 7 jane jane 4096 Jan 22 02:10 /home/jane
drwx------ 2 root root 4096 Jan 22 03:28 /home/jane/.ssh

Perhatikan bahwa jane tidak memiliki .sshfile. Perbaiki ini melalui

chown -R jane:jane /home/jane/.ssh

Masalah izin sistem file semacam ini tidak akan muncul ssh -v, dan mereka bahkan tidak akan muncul di sshd log (!) Sampai Anda mengatur level log ke DEBUG.

• Edit /etc/ssh/sshd_config. Anda ingin baris yang berbunyi LogLevel DEBUGdi sana di suatu tempat. Muat ulang server SSH menggunakan mekanisme yang disediakan oleh distro. ( service sshd reloaddi RHEL / CentOS / Scientific.) Muat ulang dengan anggun tidak akan membatalkan sesi yang ada.
• Coba autentikasi lagi.
• Cari tahu kemana perginya fasilitas autentikasi Anda dan bacalah. (IIRC, /var/log/auth.logpada distro berbasis Debian; /var/log/securepada RHEL / CentOS / Scientific.)

Jauh lebih mudah untuk mengetahui apa yang salah dengan output debug yang mencakup kesalahan izin sistem file. Ingatlah untuk mengembalikan perubahan ke /etc/ssh/sshd_configsaat selesai!

Saya menerima kesalahan ini, karena saya lupa menambahkan -lopsi. Nama pengguna lokal saya tidak sama dengan pada sistem jarak jauh.

Ini tidak menjawab pertanyaan Anda, tetapi saya sampai di sini mencari jawaban untuk masalah saya.

Saya mendapat pesan ini pada instance baru yang didasarkan pada AMI Ubuntu. Saya menggunakan opsi -i untuk menyediakan PEM tetapi masih menunjukkan "Izin ditolak (publickey)".

Masalah saya adalah saya tidak menggunakan pengguna yang benar. Dengan menjalankan ssh dengan ubuntu @ ec2 ... itu berfungsi seperti biasa.

Sesuatu yang lebih mudah dibaca daripada ssh -v(menurut saya tentu saja), adalah tail -f /var/log/auth.log. Itu harus dijalankan di server yang Anda coba sambungkan, saat mencoba menyambung. Ini akan menampilkan kesalahan dalam teks biasa.

Ini membantu saya memecahkan masalah saya:

Pengguna [nama pengguna] dari xx.yy.com tidak diizinkan karena tidak ada grup pengguna yang terdaftar di AllowGroups

Periksa file / etc / ssh / sshd_config Anda . Di sana, temukan garis yang mengatakan

PasswordAuthentication no

Baris itu perlu dimodifikasi untuk mengatakan ya alih-alih tidak. Juga, restart server sshd sesudahnya.

sudo /etc/init.d/ssh restart

Mungkin tidak relevan dengan poster saat ini, tetapi mungkin membantu orang lain yang menemukan ini ketika mencari jawaban untuk situasi yang sama. Alih-alih membiarkan Amazon menghasilkan ssh keypair, saya sarankan mengunggah kunci ssh publik standar Anda sendiri ke Amazon dan menetapkannya saat Anda menjalankan instance EC2.

Ini memungkinkan Anda menjatuhkan sintaks tipe "-i" di ssh, menggunakan rsync dengan opsi standar, dan juga memungkinkan Anda menggunakan kunci ssh yang sama di semua wilayah EC2.

Saya menulis artikel tentang proses ini di sini:

Mengunggah Kunci ssh Pribadi ke Amazon EC2
http://alestic.com/2010/10/ec2-ssh-keys

Anehnya, masalah saya ternyata server telah dihidupkan ulang dan dikeluarkan nama DNS baru. Saya menggunakan nama DNS lama. Saya tahu ini kedengarannya bodoh tetapi butuh beberapa saat untuk mencari tahu.

Jika Anda mencoba menyambungkan ke telepon CyanogenMod yang menjalankan Dropbear, Anda harus menjalankan baris berikut untuk memastikan semuanya baik-baik saja:

chmod 600 /data/dropbear/.ssh/authorized_keys

atau

chmod 700 /data/dropbear/.ssh/authorized_keys # In case of MacOS X 10.6-10.8

dan

chmod 755 /data/dropbear/ /data/dropbear/.ssh

Ini memperbaikinya bagi saya, jika tidak, tidak ada yang dapat terhubung.

Jika Anda menggunakan CentOS 5, Anda mungkin ingin mengatur StrictModes nodi /etc/ssh/sshd_config. Saya berbagi / direktori home menggunakan NIS / NFS, dan saya mengatur semua izin dengan benar, tetapi selalu meminta saya dengan kata sandi. Setelah saya atur StrictModes no, masalahnya hilang!

Jawaban Greg menjelaskan cara mengatasi masalah dengan lebih baik, namun masalah sebenarnya adalah Anda memiliki kunci ssh yang ditetapkan di satu sisi transaksi (klien), yang mencoba otentikasi kunci publik daripada otentikasi berbasis kata sandi. Karena Anda tidak memiliki kunci publik yang sesuai pada instance EC2, ini tidak akan berfungsi.

Saya memiliki masalah yang sama, dan setelah mencoba banyak solusi yang gagal, saya membuka port SSH di firewall router saya (panel kontrol firewall router saya berantakan, jadi sulit untuk mengatakan apa yang terjadi). Bagaimanapun, itu memperbaikinya :)

Sangat berdarah menjengkelkan bahwa kesalahan yang Anda dapatkan adalah Izin Ditolak, menyiratkan bahwa ada semacam koneksi, grr.

Saya mengalami masalah yang sama meskipun saya seharusnya mengikuti semua langkah termasuk

$ ec2-authorize default -p 22

Namun, saya telah memulai contoh saya di wilayah kami-barat-1. Jadi perintah di atas juga harus menentukan itu.

$ ec2-authorize default -p 22 --region us-west-1

Setelah perintah ini saya bisa ssh ke instance. Saya menghabiskan sedikit waktu sebelum saya menyadari masalah ini dan berharap posting ini membantu orang lain.

Ini adalah kasus yang jarang terjadi, tetapi jika Anda memiliki selinux diaktifkan dan Anda menggunakan nfs untuk direktori dengan otor_keys (misalnya direktori home yang dibagikan), Anda harus menonaktifkan selinux (tidak disarankan karena alasan keamanan, tetapi Anda dapat menonaktifkannya untuk sementara) untuk melihat apakah ini yang menyebabkan masalah) atau izinkan selinux untuk menggunakan direktori home nfs. Saya tidak jelas detailnya, tetapi ini berhasil untuk saya setsebool -P use_nfs_home_dirs 1

Saya baru saja mengalami masalah yang sama setelah secara tidak sengaja menambahkan izin menulis grup ke direktori home pengguna.

Saya menemukan ini adalah penyebabnya dengan menjalankan tail -f /var/log/securemesin dan melihat kesalahannya Authentication refused: bad ownership or modes for directory /home/<username>.