Saya sedang membaca artikel di Master Linux Now 2013 disebut OpenSSH: Easy Logins dan menggunakan ssh-agent untuk memungkinkan Anda memasukkan frasa sandi untuk kunci Anda sekali, dan kemudian Anda dapat terhubung ke mesin jarak jauh dengan bebas tanpa mengetiknya lagi saat ssh-agent sedang berjalan.
Alasan saya tertarik pada artikel ini sejak awal, selain karena tidak harus mengetik ulang kata sandi saya jutaan kali; adalah agar saya dapat melakukan pencadangan tanpa pengawasan dari /ke mesin jarak jauh dengan memanggil rsync dari cron pada mesin jarak jauh ke server melalui ssh;
Saya melihat artikel lain di mana seseorang baru saja melewatkan frasa sandi sehingga cron dapat dengan mudah menggunakan kunci untuk masuk, rasanya tidak benar, tetapi apakah ini boleh dilakukan dalam praktik? Maksud saya, jika seseorang mendapatkan file kunci itu, mereka dapat membuat kerusakan pada mesin untuk dicadangkan.
Menurut saya akan lebih aman untuk memastikan pengguna masuk saat reboot dan meminta mereka memasukkan frasa sandi satu kali, ketika mereka masuk untuk menjalankan agen dan kemudian hanya menunggu pekerjaan cron berjalan dengan layar terkunci; tapi sepertinya saya melewatkan sesuatu di sini, seperti tentang apa yang dijalankan oleh pengguna atau pengguna yang menjalankan tugas cron.
Jawaban yang Diterima:
Batasi perintah yang dapat dipanggil oleh kunci
Jika kunci SSH akan digunakan oleh segala jenis tugas otomatis atau tanpa pengawasan, Anda harus membatasi perintah apa yang dapat dijalankannya pada mesin jarak jauh, apa pun keputusan yang Anda buat tentang bagaimana dan di mana menyimpan kunci.
Gunakan sesuatu seperti ini di ~/.ssh/authorized_keys :
command="/usr/sbin/the-backup-daemon" ssh-rsa AAAAAAAAAAAABBBBBXXXXXX.....
Dengan begitu, setidaknya kuncinya tidak boleh, seperti yang Anda katakan, mendatangkan malapetaka. Itu hanya dapat mengakses apa yang seharusnya diaksesnya, dll… Kemungkinan besar masih dapat merusak, tetapi seharusnya memiliki akses kurang dari penuh ke sistem jarak jauh.
Anda juga dapat membatasi alamat IP yang diizinkan untuk terhubung menggunakan kunci tersebut dan menonaktifkan banyak fitur SSH lainnya seperti penerusan porta untuk koneksi yang menggunakan kunci tersebut:
from="10.1.2.3",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty,command="/usr/sbin/the-backup-daemon" ssh-rsa AAAAAAAAAAAAXXXXXX.....
Semua itu harus dilakukan dalam satu baris di ~/.ssh/authorized_keys .
Melindungi kunci
Itu tergantung pada model ancaman Anda.
Jika Anda khawatir tentang kunci yang dicuri saat "dingin", misalnya, komputer tempat penyimpanannya dicuri secara fisik, maka Anda tidak akan ingin menyimpannya tanpa frasa sandi di lokasi tersebut.
Anda bisa mulai semacam agen SSH latar belakang secara manual setelah server melakukan boot, tambahkan kunci ke agen itu, dan catat $SSH_AUTH_SOCK agen untuk digunakan di masa depan oleh pekerjaan cron, tapi sejujurnya itu terdengar seperti lebih banyak masalah daripada nilainya. Anda sebaiknya menyimpan kunci yang tidak terenkripsi di tmpfs filesystem dan minta cron job mengaksesnya dari sana. Bagaimanapun kuncinya hanya tinggal di memori (jika Anda tidak memiliki swap atau swap terenkripsi). Tentu saja Anda harus chown dan chmod file tersebut sehingga hanya pengguna target yang dapat mengaksesnya.
Kemudian lagi, jika Anda khawatir tentang itu, Anda mungkin telah menyiapkan komputer ini dengan sistem file root terenkripsi dan swap (mis. luks) sehingga Anda mungkin tidak perlu mengkhawatirkannya.
Jika Anda khawatir tentang kunci yang dicuri saat "panas" (dimuat dalam memori) maka tidak banyak yang dapat Anda lakukan tentang itu. Jika pekerjaan cron dapat mengaksesnya, maka hal lain yang telah berhasil mendapatkan akses yang sama juga dapat dilakukan. Itu saja, atau menyerah pada kenyamanan pelaksanaan pekerjaan tanpa pengawasan.
Kesimpulannya, Anda harus memperlakukan server cadangan sebagai sistem yang sangat istimewa karena, karena kebutuhan, akan diberikan akses baca-saja ke sistem file lengkap dari semua komputer yang dicadangkannya. Server cadangan Anda seharusnya tidak dapat diakses dari Internet, misalnya.