Solusi 1:
Saya suka ide mengakses server melalui kunci, sehingga saya tidak perlu mengetik kata sandi saya setiap kali saya ssh ke dalam kotak, saya bahkan mengunci kata sandi pengguna (bukan root) saya (passwd -l nama pengguna) jadi tidak mungkin untuk login intanpa kunci...Apakah Anda merekomendasikan/tidak merekomendasikan melakukan ini untuk akun pengguna di server?
Anda akan menonaktifkan login berbasis kata sandi dengan cara yang salah. Alih-alih mengunci akun pengguna, tetapkan PasswordAuthentication no di /etc/ssh/sshd_config Anda .
Dengan set itu, autentikasi kata sandi dinonaktifkan untuk ssh, tetapi Anda masih dapat menggunakan kata sandi untuk sudo.
Satu-satunya kali saya merekomendasikan pengaturan NOPASSWD di sudo adalah untuk akun layanan, di mana proses harus dapat menjalankan perintah melalui sudo secara terprogram. Dalam keadaan tersebut, pastikan Anda hanya mengizinkan yang spesifik secara eksplisit perintah yang perlu dijalankan oleh akun. Untuk akun interaktif, Anda harus selalu biarkan kata sandi diaktifkan.
Tanggapan atas pertanyaan tindak lanjut Anda:
Tapi saya kira jika saya menonaktifkan otentikasi kata sandi di/etc/ssh/sshd_config sehingga Anda masih harus memiliki kunci untuk masuk, saya dapat menggunakan kata sandi yang lebih sederhana hanya untuk sudo yang lebih mudah untuk diketik? Apakah itu strategi yang valid?
Ya, itu benar. Saya tetap merekomendasikan menggunakan kata sandi akun lokal yang relatif kuat, tetapi tidak terlalu kuat. ~8 karakter, cukup dibuat secara acak.
Jika saya juga memiliki kunci untuk masuk sebagai root melalui ssh, jika seseorang mendapatkan akses ke komputer saya dan mencuri kunci saya (mereka masih dilindungi oleh kata sandi keyring OS!), Mereka mungkin juga mendapatkan akses langsung ke akun root, melewati jalur sudo.
Akses root melalui ssh harus dinonaktifkan. Periode. Tetapkan PermitRootLogin no di sshd_config Anda .
Apa yang seharusnya menjadi kebijakan untuk mengakses akun root?
Anda harus selalu memiliki cara untuk mendapatkan akses out-of-band ke konsol server Anda. Beberapa vendor VPS menyediakan ini, seperti halnya vendor perangkat keras khusus. Jika penyedia Anda tidak memberikan akses konsol yang sebenarnya (katakanlah, EC2 misalnya), Anda biasanya masih dapat memulihkan akses menggunakan proses seperti yang saya uraikan dalam jawaban ini.
Solusi 2:
Saya biasanya membatasi penggunaan NOPASSWORD ke perintah yang dijalankan oleh proses otomatis. Lebih baik memiliki akun layanan untuk perintah ini, dan batasi penggunaan sudo hanya untuk perintah yang diperlukan.
Mengizinkan NOPASSWORD untuk perintah umum, memungkinkan siapa saja yang mendapat akses ke userid Anda untuk menjalankan perintah apa pun. Ini bisa terjadi akibat kompromi kredensial Anda, tetapi bisa sesederhana seseorang duduk di meja Anda saat Anda menjauh sebentar.
Saya merasa saya tidak perlu memasukkan kata sandi sesering itu. Setelah Anda memasukkan kata sandi, Anda dapat menjalankan beberapa perintah jika Anda tidak menunggu terlalu lama di antara perintah tersebut. Batas waktu dapat dikonfigurasi.
Solusi 3:
Anda dapat memiliki yang terbaik dari kedua dunia:autentikasi SSH untuk login dan sudo. Jika Anda mengintegrasikan modul pam_ssh_agent_auth Anda dapat menggunakan kunci SSH untuk mengautentikasi tanpa memberikan kata sandi saat Anda sudo.
Saya telah menggunakan ini dalam produksi selama lebih dari lima tahun.
Untuk mengonfigurasinya, instal modul PAM, lalu tambahkan baris ke /etc/pam.d/sudo atau yang setara dengan sistem Anda:
auth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys
Jika Anda melakukan ini, pastikan untuk melindungi kunci Anda di komputer dengan frasa sandi. Dengan begitu, seseorang harus membobol komputer Anda dan mencuri kunci untuk masuk. Mereka dapat melakukannya dengan menariknya dari memori saat mereka tidak terkunci jika mereka memiliki akses ke akun Anda, dengan meretas frasa sandi Anda, atau mencuri frasa sandi Anda melalui keylogger atau bahu menjelajahinya saat Anda mengetiknya (lihat ke belakang!).
Anda dapat menggunakan kunci SSH yang sama seperti yang Anda lakukan untuk masuk, atau Anda dapat menyiapkan kunci terpisah yang hanya Anda tambahkan ke agen Anda saat sudo. Jadi, jika Anda ingin ekstra hati-hati, Anda dapat menyimpan file authorized_keys terpisah yang memiliki kunci SSH terpisah yang hanya Anda tambahkan ke agen saat Anda perlu sudo:
auth sufficient pam_ssh_agent_auth.so file=~/.ssh/authorized_keys_sudo
Solusi 4:
Saya hanya akan menggunakan ini dalam dua keadaan:
- Ketika itu benar-benar diperlukan untuk skrip otomatis yang berjalan sebagai pengguna tertentu
- Untuk tugas admin tertentu (hanya baca tugas admin, bukan tugas yang mengambil tindakan untuk mengubah sistem) dan kemudian hanya untuk pengguna tertentu tentunya
Secara default sebagian besar sudo konfigurasi tidak akan meminta Anda lagi untuk sementara waktu di sesi yang sama (jika Anda membuka shell baru yang tidak berpengaruh apa pun). Anda dapat mengontrol perilaku ini sampai batas tertentu dengan timestamp_timeout pengaturan.
sudo tanpa kata sandi hampir tidak berbahaya seperti ssh tanpa frasa sandi kunci, karena penyerang jarak jauh memerlukan kredensial Anda untuk masuk sejak awal, tetapi jika mereka masuk dengan entah bagaimana mengorbankan kunci pribadi Anda (atau jika mereka secara fisik lokal untuk Anda dan Anda membiarkan diri Anda masuk dan tidak terkunci saat pergi dari mesin) maka permintaan kata sandi adalah pertahanan ekstra yang berharga antara mereka dan akses istimewa.
Mengenai tindak lanjut 2:
Jika saya juga memiliki kunci untuk masuk sebagai root melalui ssh
Ini sebaiknya dihindari juga, karena alasan yang Anda jelaskan. Jika koneksi jarak jauh harus memiliki akses istimewa, buatlah login melalui akun layanan dan berikan kontrol yang cukup untuk melakukan tugasnya melalui sudo. Ini lebih faf untuk dikonfigurasi tentu saja sehingga banyak yang tidak repot (yang menguntungkan Anda jika Anda melakukannya, karena ada banyak buah gantung yang lebih rendah daripada yang Anda habiskan untuk penyerang menghabiskan waktu di sana!), Jadi turun ke kompromi kuno antara keamanan dan kenyamanan (tip pro:pilih keamanan!).
Solusi 5:
Karena Anda bertanya, inilah saran umum saya tentang cara menangani sudo masalah.
Sudo tidak dirancang untuk memberikan keamanan lebih (walaupun bisa dalam beberapa hal)... melainkan memberikan jejak audit yang baik tentang siapa yang melakukan apa pada sistem Anda dengan hak istimewa apa.
Pengaturan Sudo yang benar tidak akan menggunakan ALL=(ALL) ALL pengaturan, melainkan sesuatu yang lebih terbatas pada apa pun yang secara khusus dibutuhkan pengguna. Misalnya, jika Anda memerlukan pengguna untuk dapat masuk dan memulai ulang layanan yang macet, mereka mungkin tidak memerlukan kemampuan untuk memasang perangkat lunak baru atau mematikan server Anda, mengubah aturan firewall, dll.
Kadang-kadang umum bagi orang untuk menggunakan sudo untuk mengangkat diri mereka sendiri ke akun root, yaitu. sudo su - . Setelah mereka melakukan itu, Anda berhenti melihat siapa yang melakukan apa dari akun root (root dapat masuk beberapa kali secara bersamaan). Jadi terkadang orang ingin menonaktifkan sudo su - perintah juga. Namun, untuk alasan praktis, jika Anda benar-benar memerlukan akun dengan hak akses root sepenuhnya untuk administrasi, paling tidak meminta seseorang menerbitkan sudo su - perintah akan mencatat siapa yang mengangkat ke root dan kapan.
Bagaimana saya mengamankan kotak saya:
Ubah port SSH ke sesuatu selain default. Ini untuk menghindari bot-bodoh yang mencari nomor port lalu pergi sampai mereka masuk (atau tidak).
Larang login Root melalui SSH menggunakan AllowRootLogin no pengaturan di sshd_config Anda. Ini mencegah seseorang dari kekerasan memaksa masuk ke akun root Anda. Secara umum merupakan praktik yang baik untuk tidak pernah mengizinkan seseorang masuk langsung ke akun root/administrator untuk alasan audit dan juga keamanan. Jika Anda mengizinkan login root secara langsung, Anda tidak tahu siapa yang login, dari siapa mereka mendapatkan kata sandi, dll. Namun, jika seseorang login ke akun Jimmy, lalu meningkatkan izin mereka untuk melakukan root, Anda memiliki ide yang lebih baik dari mana harus memulai. audit penelusuran (dan akun siapa yang akan disetel ulang).
Hanya izinkan pengguna ke SSH yang memerlukannya Gunakan AllowUsers pengaturan dan kejelasan menentukan akun mana yang membutuhkan akses SSH. Secara default, ini akan memblokir semua akun lain dari SSH.
Edit Sudoers melalui visudo dan hanya izinkan perintah yang dibutuhkan pengguna. Ada banyak panduan mendalam tentang cara melakukan ini, jadi saya tidak akan menjelaskannya di sini. Ini permulaannya:http://ubuntuforums.org/showthread.php?t=1132821
Inti dari ini adalah untuk mencegah akun yang disusupi membahayakan mesin Anda. yaitu. jika akun Sally dibobol, dan Sally hanya dapat menggunakan sudo untuk me-restart server web, penyerang mungkin bersenang-senang me-restart server web Anda dalam satu lingkaran, tetapi setidaknya mereka tidak dapat rm -rf /your/webserver/directory atau buka semua port firewall Anda, dll.
Siapkan aturan firewall yang baik yang hanya mengizinkan port yang diperlukan agar komputer Anda dapat beroperasi. Umumnya Anda ingin meninggalkan semuanya dan hanya mengizinkan secara eksplisit apa yang Anda butuhkan. Ada banyak iptables yang layak dan firewall lain mulai online, ini yang saya gunakan (ini adalah starter dasar):
# Generated by iptables-save v1.4.7 on Mon Mar 3 17:55:02 2014
*filter
:INPUT DROP [4528:192078]
:FORWARD DROP [0:0]
:OUTPUT ACCEPT [39845:27914520]
-A INPUT -i lo -j ACCEPT
-A INPUT -p tcp -m tcp ! --tcp-flags FIN,SYN,RST,ACK SYN -m state --state NEW -j DROP
-A INPUT -m state --state RELATED,ESTABLISHED -j ACCEPT
-A INPUT -p tcp -m tcp --dport 4254 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8080 -m state --state NEW -j ACCEPT
-A INPUT -p tcp -m tcp --dport 8443 -m state --state NEW -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 8 -j ACCEPT
-A INPUT -p icmp -m icmp --icmp-type 11 -j ACCEPT
-A OUTPUT -o lo -j ACCEPT
COMMIT
# Completed on Mon Mar 3 17:55:02 2014
Juga kata sandi yang kuat adalah kuncinya. Bahkan jika Anda menggunakan kunci SSH untuk akses jarak jauh, Anda tetap memerlukan kata sandi untuk penggunaan Sudo. Ini adalah kasus di mana sudo dapat memberikan keamanan lebih. Jika seseorang mencuri kunci ssh Anda, mereka masih akan dicegah melakukan sesuatu yang signifikan pada kotak Anda jika mereka masih harus memaksa kata sandi akun Anda untuk menggunakan sudo. Kata sandi tidak boleh berupa kata, melainkan Pass Phrase. Pikirkan sebuah kalimat, dan gunakan itu. Ini umumnya akan memberi Anda sesuatu yang lebih dari 8 karakter, memberikan banyak entropi, tetapi juga lebih mudah diingat daripada kata sandi acak. Tentu saja, praktik kata sandi yang baik mengatakan untuk menggunakan kata sandi acak yang dihasilkan mesin untuk mengelabui alat peretas seperti John the Ripper, yang akan merobek sebagian besar frasa sandi dan kata sandi. Tidak, mengubah E dengan 3 tidak berhasil, John juga mendapatkan permutasi tersebut.