otentikasi kunci publik gagal SAJA ketika sshd adalah daemon

33

Saya tidak tahu bagaimana ini terjadi. Distro adalah Scientific Linux 6.1 dan semuanya diatur untuk melakukan otentikasi melalui kunci publik. Namun, ketika sshd berjalan sebagai daemon (service sshd start), sshd tidak menerima kunci publik. (Untuk mendapatkan potongan log ini, saya telah mengubah skrip sshd untuk menambahkan opsi -ddd)

debug1: trying public key file /root/.ssh/authorized_keys
debug1: restore_uid: 0/0
debug1: temporarily_use_uid: 0/0 (e=0/0)
debug1: trying public key file /root/.ssh/authorized_keys2
debug1: restore_uid: 0/0
Failed publickey for root from xxx.xxx.xxx.xxx port xxxxx ssh2
debug3: mm_answer_keyallowed: key 0x7f266e1a8840 is not allowed
debug3: mm_request_send entering: type 22
debug3: mm_request_receive entering
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
debug3: Wrote 64 bytes for a total of 1853
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 1

Jika sshd dijalankan dalam mode debug /usr/sbin/sshd -ddd, otentikasi berfungsi seperti mantra:

debug1: trying public key file /root/.ssh/authorized_keys
debug1: fd 4 clearing O_NONBLOCK
debug1: matching key found: file /root/.ssh/authorized_keys, line 1
Found matching RSA key: d7:3a:08:39:f7:28:dc:ea:f3:71:7c:23:92:02:02:d8
debug1: restore_uid: 0/0
debug3: mm_answer_keyallowed: key 0x7f85527ef230 is allowed
debug3: mm_request_send entering: type 22
debug3: mm_request_receive entering
debug3: Wrote 320 bytes for a total of 2109
debug2: userauth_pubkey: authenticated 0 pkalg ssh-rsa
Postponed publickey for root from xxx.xxx.xxx.xxx port xxxxx ssh2
debug1: userauth-request for user root service ssh-connection method publickey
debug1: attempt 2 failures 0

Ada ide ?? Adakah yang melihat sesuatu seperti ini?

Catatan:

Izin file telah diperiksa dua kali:

# ll -d .ssh
drwx------. 2 root root 4096 Oct 14 10:05 .ssh
# ll .ssh
total 16
-rw-------. 1 root root  786 Oct 14 09:35 authorized_keys
-rw-------. 1 root root 1675 Oct 13 08:24 id_rsa
-rw-r--r--. 1 root root  393 Oct 13 08:24 id_rsa.pub
-rw-r--r--. 1 root root  448 Oct 13 12:51 known_hosts

Saya ditanya apakah sshd dapat mengakses file root dalam "mode daemon". Jawaban terdekat yang saya dapatkan untuk pertanyaan ini adalah:

# netstat -ntap | grep 22
tcp        0      0 0.0.0.0:22                  0.0.0.0:*                   LISTEN      19847/sshd 
# ps -ef | grep 19847
root     19847     1  0 09:58 ?        00:00:00 /usr/sbin/sshd

Jika sshd berjalan sebagai root, saya tidak tahu bagaimana tidak mungkin mengakses file sendiri. Mungkinkah SELinux menjadi penyebabnya?

— pengguna666412
sumber

1

Apakah skrip init sshd melakukan sesuatu yang menarik? (Seharusnya /etc/init.d/sshd?) Yang tidak Anda lakukan di baris perintah? Alih-alih 'service sshd start' coba 'sh -x /etc/init.d/ssh start'.

— PT

42

Ya, SELinux kemungkinan penyebabnya. The .sshdir mungkin disalahartikan. Lihatlah /var/log/audit/audit.log. Itu harus diberi label ssh_home_t. Periksa dengan ls -laZ. Jalankan restorecon -r -vv /root/.sshjika perlu.

— Mark Wagner
sumber

1

Yap, SELinux adalah penyebabnya: type = AVC msg = audit (1318597097.413: 5447): avc: ditolak {read} for pid = 19849 comm = "sshd" name = "resmi_keys" dev = dm-0 ino = 262398 scontext = unconfined_u : system_r: sshd_t: s0-s0: c0.c1023 tcontext = unconfined_u: object_r: admin_home_t: s0 tclass = file Ia berfungsi setelah menjalankan "restorecon -r -vv /root/.ssh". Terima kasih banyak.

— user666412

1

terima kasih TERIMA KASIH atas perbaikan baris perintah selinux Saya sudah berusaha mencari sejak lama mengapa saya bisa ssh sebagai root ke redhat enterprise 6.2 server saya menggunakan otentikasi kunci ssh, tapi saya tidak bisa ssh sebagai pengguna non-root tanpa harus memasukkan kata sandi. "ssh -v" tidak menunjukkan sesuatu yang tidak biasa sama sekali. Saya telah memeriksa dan mengecek ulang file perlindungan di /home/example/.ssh Tidak sampai saya menjalankan "/ usr / sbin / sshd -d" dan untuk beberapa alasan yang bekerja secara normal saya menyadari sesuatu yang lain sedang terjadi, dan mencoba pencarian google yang berbeda dan menemukan ini. Jadi, gejalanya adalah saya bisa ssh as ro

— Paul M

1

Saya harus melakukan ini pada keseluruhan filesystem, yaitu restorecon -r /, YMMV.

— Irfy

1

Saya mencoba ini - tetapi masih tidak berhasil. dalam log audit saya punya

type=AVC msg=audit(1434642809.455:94717): avc:  denied  { search } for  pid=27032 comm="sshd" name="/" dev=dm-2 ino=2 scontext=unconfined_u:system_r:sshd_t:s0-s0:c0.c1023 tcontext=system_u:object_r:file_t:s0 tclass=dir

- tidak yakin apa artinya

— Yehosef

1

Jawabannya ada di name="/"- Saya harus menjalankan restorecon -r /seperti yang disarankan @Irfy.

— Yehosef

3

Saya memiliki masalah yang sama. Dalam kasus saya, restorecon dan chcon tidak berfungsi.

Saya tidak ingin menonaktifkan selinux. Setelah banyak penelitian, saya akhirnya menemukan itu karena direktori rumah saya di-mount dari tempat lain (NFS). Saya menemukan laporan bug ini yang memberi saya petunjuk.

Saya berlari:

> getsebool use_nfs_home_dirs
use_nfs_home_dirs --> off

untuk mengonfirmasi use_nfs_home_dirs tidak aktif lalu:

sudo setsebool -P use_nfs_home_dirs 1

untuk menyalakannya.

Sekarang saya bisa ssh ke mesin saya menggunakan kunci saya dan tanpa memasukkan kata sandi. Beralih boolean use_home_nfs_dirs adalah apa yang diperlukan untuk saya.

— Gerard
sumber

1

Untuk menambah jawaban Mark Wagner, jika Anda menggunakan jalur direktori home khusus (yaitu tidak /home), Anda perlu memastikan bahwa Anda telah mengatur konteks keamanan SELinux. Untuk melakukannya, jika Anda memiliki direktori home pengguna di, misalnya /myhome,, jalankan:

semanage fcontext -a -e /home /myhome
restorecon -vR /myhome

— DavidArndt
sumber

Jika Anda menggunakan CentOS, Anda harus menjalankan ini untuk mendapatkan semanage:sudo yum install policycoreutils-python

— sm4rk0

0

Sepertinya Anda menggunakan tombol yang berbeda saat menguji koneksi, 0x7f266e1a8840 vs 0x7f85527ef230. Coba sambung menggunakan 'ssh -v example.com' ke sshd yang berjalan sebagai daemon dan dalam mode debug dan cari kunci yang digunakan oleh ssh di sekitar string "Menawarkan kunci publik RSA".

— Johan Nilsson
sumber

Ya, ada id_rsa dan id_dsa. Kunci DSA hilang dan saya akan mengulang tes.

— user666412

Nilai yang disebutkan dalam debug3: mm_answer_keyallowed: key 0xFFFFFFFFFFakan berubah setiap kali sshd menerima koneksi baru. Untuk mengonfigurasi ini, cari server tempat SSH berfungsi, engkol sshd LOGLEVEL ke debug3, restart sshd, jalankan tail -f /var/log/secure |grep mm_answer_keyalloweddan kemudian login beberapa kali, tunggu beberapa detik (atau menit) antara setiap koneksi. Anda akan melihat bahwa nilainya berubah setiap kali. Dan sebenarnya itu terlihat seperti counter bagi saya.

— Stefan Lasiewski