Haruskah saya menghapus kata sandi pengguna setelah saya mengatur otentikasi kunci publik untuk SSH?

Yang terbaik adalah menggunakan kunci publik untuk SSH. Jadi saya sshd_configpunya PasswordAuthentication no.

Beberapa pengguna tidak pernah masuk, misalnya pengguna sftp dengan shell /usr/sbin/nologin. Atau akun sistem.

Jadi saya bisa membuat pengguna seperti itu tanpa kata sandi dengan adduser gary --shell /usr/sbin/nologin --disabled-password.

Apakah itu ide yang baik / buruk? Apakah ada konsekuensi yang belum saya pertimbangkan?

— lonix
sumber

Selama ini bukan akun pengguna sungguhan, atau mereka tidak memerlukan kata sandi untuk sudoakses (baik karena tidak memiliki izin sudo sama sekali, atau dengan memiliki izin sudo dengan NOPASSWD), jawaban yang Anda pilih harus sesuai. Saya telah mengirimkan suntingan pada jawaban itu untuk memasukkan masalah sudo tetapi saya pikir saya akan memberitahukannya kepada Anda di sini sementara itu.

— Doktor J

Jawaban:

Jika Anda memiliki akses root ke server dan dapat membuat ulang kunci ssh untuk pengguna Anda jika mereka kehilangan mereka

DAN

Anda yakin pengguna (sebagai pribadi) tidak akan memiliki beberapa akun pengguna dan mereka perlu beralih di antara mereka yang ada di sesi SSH (well, mereka juga dapat membuka beberapa sesi SSH jika diperlukan)

DAN

mereka tidak akan memerlukan akses "fisik" (melalui keyboard + monitor atau melalui konsol jarak jauh untuk VM) ke server

DAN

tidak ada pengguna yang memiliki sudoakses gated-password (yaitu mereka tidak memiliki akses sudo sama sekali, atau memiliki akses sudo dengan NOPASSWD)

Saya pikir kamu akan baik-baik saja.

Kami memiliki banyak server yang sedang dikonfigurasikan seperti ini (hanya beberapa akun yang membutuhkan akses ke VM melalui konsol jarak jauh vmware, yang lain hanya terhubung melalui SSH dengan pubkey auth).

— Tuan Shunz
sumber

Saya juga menambahkan "Anda tahu pengguna tidak akan pernah harus mengakses sistem dari sistem jarak jauh yang tidak memiliki kunci SSH pribadi mereka". Dan "Anda bersedia berurusan dengan pengguna yang mengalami situasi yang tidak Anda pikirkan."

— Andrew Henle

Syarat pertama adalah IMO tidak perlu. Pengguna Anda harus membuat kunci sendiri. Anda hanya mengotorisasi kunci publik mereka saat mereka memberikannya kepada Anda. Jika mereka kehilangan kunci, mereka hanya akan menghasilkan yang lain dan Anda akan mengganti yang lama di server.

— Christophe Drevet-Droguet

@AndrewHenle Itu adalah poin yang bagus, namun jika sshd memiliki PasswordAuthentication nomasalah yang berbeda (pengguna tetap tidak dapat login).

— Lonix

"Tidak pernah" begitu lama. Admin dapat dengan mudah menambahkan otentikasi kata sandi kembali, jika perlu.

— hyde

Nah, pertanyaannya jelas berkaitan dengan akun yang pasti tidak (dan mungkin seharusnya tidak) masuk, seperti akun sistem yang digunakan oleh layanan khusus atau pengguna khusus sftp. Pertanyaannya juga menyatakan bahwa pengguna tidak memiliki shell login. Untuk tipe pengguna ini, saya pikir disarankan untuk menonaktifkan login melalui kata sandi secara eksplisit.

— Christian Gawron

Pertanyaan ini awalnya disebutkan passwd --delete <username> yang tidak aman : dengan itu, bidang kata sandi terenkripsi di /etc/shadowakan benar-benar kosong.

username::...

Jika Anda telah mengonfigurasikan Anda sshduntuk menolak otentikasi kata sandi, maka itu aman dengan SSH ... Tetapi jika ada layanan lain di sistem Anda menggunakan otentikasi kata sandi dan tidak dikonfigurasi untuk menolak kata sandi nol, ini memungkinkan akses tanpa kata sandi! Anda tidak menginginkan ini.

adduser --disabled-passwdakan menghasilkan /etc/shadowentri di mana bidang kata sandi terenkripsi hanyalah tanda bintang, yaitu

username:*:...

Ini adalah "kata sandi terenkripsi yang tidak pernah berhasil dimasukkan", artinya ini berarti akun itu sah dan secara teknis memungkinkan masuk, tetapi itu membuat otentikasi dengan kata sandi tidak mungkin berhasil . Jadi, jika Anda memiliki layanan berbasis otentikasi kata sandi lain di server Anda, pengguna ini diblokir dari mereka.

Hanya metode otentikasi yang menggunakan sesuatu selain kata sandi akun standar (misalnya kunci SSH) yang akan berfungsi untuk pengguna ini, untuk layanan apa pun yang menggunakan file kata sandi sistem dalam sistem ini. Saat Anda membutuhkan pengguna yang hanya bisa masuk dengan kunci SSH, inilah yang Anda inginkan.

Jika Anda perlu mengatur akun yang ada ke negara ini, Anda dapat menggunakan perintah ini:

echo 'username:*' | chpasswd -e

Ada nilai khusus ketiga untuk bidang kata sandi terenkripsi:, adduser --disabled-loginmaka bidang tersebut hanya akan berisi tanda seru.

username:!:...

Seperti asterisk, ini membuat otentikasi kata sandi mustahil untuk berhasil, tetapi juga memiliki makna tambahan: ini menandai kata sandi sebagai "terkunci" untuk beberapa alat administrasi. passwd -lmemiliki banyak efek yang sama dengan mengawali hash kata sandi yang ada dengan tanda seru, yang sekali lagi membuat otentikasi kata sandi tidak mungkin untuk digunakan.

Tapi ini jebakan bagi yang tidak waspada: di tahun 2008, versi passwdperintah yang berasal dari shadowpaket lama diubah untuk mendefinisikan kembali passwd -ldari "mengunci akun" menjadi hanya "mengunci kata sandi". Alasan yang disebutkan adalah "untuk kompatibilitas dengan versi passwd lainnya".

Jika Anda (seperti saya) mengetahui ini sejak lama, itu mungkin akan mengejutkan. Ini tidak membantu hal-hal yang adduser(8)tampaknya belum menyadari perbedaan ini juga.

Bagian yang menonaktifkan akun untuk semua metode otentikasi sebenarnya menetapkan nilai tanggal berakhirnya 1 untuk account: usermod --expiredate 1 <username>. Sebelum tahun 2008, passwd -litu berasal dari shadowsource kit yang digunakan untuk melakukan ini selain untuk awalan kata sandi dengan tanda seru - tetapi tidak lagi melakukannya.

Changelog paket Debian mengatakan:

debian / patches / 494_passwd_lock-no_account_lock: Kembalikan perilaku passwd -l sebelumnya (yang berubah di # 389183): hanya mengunci kata sandi pengguna, bukan akun pengguna. Juga mendokumentasikan perbedaan secara eksplisit. Ini mengembalikan perilaku umum dengan versi passwd sebelumnya dan dengan implementasi lainnya. Tutup: # 492307

Riwayat bug untuk bug Debian 492307 dan bug 389183 dapat membantu dalam memahami pemikiran di balik ini.

— telcoM
sumber

Terima kasih atas peringatannya ... Saya akan mengedit pertanyaannya sehingga tidak ada yang membuat kesalahan itu!

— lonix

Apakah peringatan Anda juga berlaku untuk kasus di mana saya menggunakan adduser --disabled-passwd- jadi jika beberapa layanan lain mengizinkan otentikasi kata sandi, maka pengguna dapat masuk tanpa kata sandi?

— lonix

Tidak, adduser --disabled-passwordsecara khusus membuat otentikasi kata sandi tidak mungkin berhasil untuk akun itu.

— telcoM

Karena menghapus kata sandi tampaknya tidak bersalah tetapi sangat berbahaya, saya sarankan untuk mengganti paragraf dengan paragraf tentang penggunaan *sehingga ini adalah hal pertama yang dibaca orang.

— Kapten Man

Wow, itu kejutan yang tidak enak menunggu untuk terjadi ... dan seperti biasa, tampaknya ada masalah kompatibilitas yang harus disalahkan untuk itu. Itu muncul dalam passwdkode sumber pada tahun 2008. Tidakkah Anda menyukainya ketika sesuatu yang pernah Anda pelajari dan kemudian andalkan ternyata tidak lagi?

— telcoM