Bagaimana cara menyimpan kunci SSH?


67

Saya sudah mulai menggunakan kunci SSH alih-alih kata sandi baru-baru ini (tentu saja terima kasih kepada GitHub), jadi harap diingat bahwa saya cukup baru dalam keseluruhan konsep ini. Saat ini kunci saya terletak di bawah ~ / .ssh, tapi saya tidak yakin apakah ini praktik yang baik. Misalnya jika saya memiliki beberapa mesin, saya perlu menduplikasi kunci pribadi saya, yang saya pikir tidak diinginkan. Atau, jika HDD saya menjadi kaput, maka saya akan kehilangan kunci-kunci itu, yang (saya kira) juga tidak diinginkan.

Jadi, apa praktik terbaik untuk menyimpan kunci SSH dengan aman, nyaman, dan andal?

Sepertinya menggunakan smartcard adalah sebuah opsi (lihat Smartcard untuk menyimpan kunci gpg / ssh (Linux) - apa yang saya butuhkan? ), Apakah ini yang terbaik?

Pembaruan: Alasan pertanyaannya adalah bahwa banyak layanan (seperti GitHub, AWS EC2) memberikan panduan tentang cara mengatur kunci SSH untuk menggunakan layanan, tetapi sedikit atau tidak ada latar belakang (seperti, apa yang harus dilakukan jika Anda telah memiliki kunci yang dibuat oleh ssh-keygen[1], langkah keamanan apa yang disarankan). Dan tidak jelas apakah info itu sebenarnya tidak penting, atau Anda diharapkan mengetahuinya 'secara default'.

Untuk meringkas jawaban hingga titik ini (tapi tolong bacalah, dan jika Anda memiliki sesuatu untuk ditambahkan — tolong lakukan): sepertinya dalam kasus ini tidak apa-apa jika Anda membiarkan kunci pribadi Anda di ~ / .ssh, selama Anda jauhkan dari orang lain; tetapi pastikan bahwa Anda memiliki cara lain untuk mengakses layanan untuk mengunggah atau membuat kunci baru jika Anda kehilangan satu (yang biasanya terjadi).

[1] GitHub digunakan untuk memberikan bantuan tentang cara mengelola beberapa kunci .


Tautan itu tampaknya rusak help.github.com/multiple-ssh-keys
KJ Price

@KJ Price, terima kasih kepada Internet Archive's Wayback Machine , halaman ini masih tersedia online, meskipun tidak pada tautan aslinya. Salinan halaman yang diarsipkan pada 2 September 2011 dapat ditemukan di beberapa kunci SSH .
moonpoint

Jawaban:


41

Misalnya jika saya memiliki beberapa mesin, saya perlu menduplikasi kunci privat, yang saya pikir tidak diinginkan.

Tidak, sebenarnya tidak. Jika Anda memiliki beberapa mesin, Anda cukup membuat kunci pribadi yang terpisah pada masing-masing mesin. Untuk setiap kunci pribadi, cukup unggah kunci publik yang sesuai ke GitHub menggunakan proses yang sama.

Juga, jika HDD saya menjadi kaput, saya akan kehilangan kunci pribadi saya, yang (saya kira) juga tidak diinginkan.

Tidak juga; jika Anda kehilangan kunci pribadi, cukup buat yang baru dan unggah kunci publik yang sesuai.

Untuk apa nilainya, Anda benar bahwa menduplikasi kunci pribadi sangat tidak diinginkan. Idealnya, kunci pribadi harus dibuat dalam satu file ( ~/.ssh/id_rsamisalnya) dan tidak boleh meninggalkan file itu - yaitu, itu tidak boleh disalin, dipindahkan, dan terutama tidak ditransfer melalui jaringan. (misalnya saya mengecualikan mereka dari cadangan) Karena sifat protokol otentikasi asimetris, Anda hanya perlu khawatir tentang menjaga kunci pribadi Anda dari tangan orang lain. Jika Anda sedikit berlebihan dan Anda kehilangan jejaknya sendiri, itu biasanya bukan masalah besar. (Ini jangan dikacaukan dengan kunci privat enkripsi asimetris , mis. Kunci GPG, yang mungkin ingin Anda pertahankan.)


14
Ini hanya berfungsi jika Anda memiliki beberapa metode lain untuk mengakses server yang disediakan kunci privat itu. Anda dapat mengunggah kunci publik baru hanya jika Anda memiliki akses cadangan itu.
POHON

2
@ TREE: benar, tetapi dalam pengalaman saya sangat jarang menemukan server yang tidak menyediakan beberapa metode alternatif akses (atau setidaknya menambahkan kunci publik tambahan tanpa melalui SSH).
David Z

3
Terima kasih, itu sangat membantu. Sungguh, kehilangan kunci SSH pribadi tidak terlihat seperti masalah, karena untuk semua layanan yang saya gunakan sepertinya selalu ada cara lain untuk mengakses layanan untuk mengunggah yang baru.
Anton Strogonoff

3
AWS tidak menyediakan bentuk akses apa pun selain kunci pribadi. Anda harus memutuskan koneksi drive dan main-main dengan itu untuk mendapatkan akses setelah Anda kehilangan kunci pribadi Anda.
Asad Saeeduddin

1
Perhatikan bahwa Anda dapat memasukkan kata sandi pada kunci pribadi Anda jika Anda menginginkan lapisan keamanan lain.
sudo

8

Saya ingin menambahkan bahwa ~ / .ssh / dapat dibaca oleh browser Anda jika Anda menggunakan akun pengguna yang sama untuk menjalankan keduanya.

Cobalah! Arahkan browser Anda ke kunci pribadi Anda di direktori home Anda. Itu menyenangkan.

Jadi saya akan merekomendasikan menyimpan ssh-keys di direktori home dari akun pengguna lain.

sebuah kata pada kunci-kunci pelindung frasa sandi

  • Saat ini, meretas kata sandi non-acak sangat cepat. Lihat kucing hash
    • (Meskipun 12+ kata sandi acak dan panjang masih membutuhkan waktu yang cukup lama untuk memaksa)
    • Jadi kunci ssh terenkripsi AES tidak dapat dipecahkan untuk masa yang akan datang selama Anda menggunakan kata sandi yang panjang dan bagus. Lihat rekomendasi github
  • Jadi beberapa situs web dapat menebak-ambil kunci Anda tanpa JavaScript. Dan kemudian paksa kunci secara offline.
  • Dan browser dapat melihat ke Clipboard Anda dengan JS juga. Jadi menyalin kata sandi yang sangat panjang juga menempatkan Anda pada risiko dari serangan javascript yang lebih canggih.

look_at_keys.html

 9 <HTML>
10 <HEAD>
11 <TITLE>look at keys</TITLE>
12 </HEAD>
13 <FRAMESET cols="20%, 80%">
14   <FRAMESET rows="100, 200">
15       <FRAME src="/Users/yourname/.ssh/stuff.pem">
16       <FRAME src="blah.html">
17   </FRAMESET>
18   <FRAME src="contents_of_frame3.html">
19 </FRAMESET>
20 </HTML>

17
Agar lebih jelas, hanya karena browser dapat membaca kunci pribadi Anda, itu tidak berarti situs web yang berjalan di browser dapat.
Ajedi32

6
Tapi, jika Anda menyuntikkan proses dalam proses browser. Kemudian Anda dapat mengendalikan browser juga. Jadi argumen ini sangat valid.
BigSack

Tetapi kemudian Anda harus meretas proses yang menyuntikkan proses dalam register proses unit peramban Anda.
Skid Kadda

8

Ada alat yang sangat bagus bernama KeePass2 ( http://keepass.info/ ) dengan ekstensi ( http://lechnology.com/software/keeagent/ )

Anda dapat menyimpan Kata Sandi, Kunci SSH, dan banyak lagi di sana (pada halaman resmi KeePass ada ekstensi yang jauh lebih berguna)
Jika Anda ingin masuk secara otomatis dengan Kunci SSH Anda, Anda hanya perlu menginstal PutTY, Pageant dan KeePass dengan KeeAgent. Jika Anda mengonfigurasinya dengan benar, Anda tidak perlu mengatur Kunci di Putty, Pageant atau FileZilla.

Saya menggunakannya sendiri dan saya cukup senang tentang hal itu. Saya memiliki lebih dari 30 VPS dan Root Server dengan sejumlah Kunci SSH yang berbeda dan satu-satunya yang harus saya lakukan adalah membuka KeePass (Ini bukan Kata Sandi Utama saya) dan kemudian saya hanya perlu mengetikkan di konsol frasa sandi saya.


3

Saya akan merekomendasikan menyimpan kunci pribadi:

  • offline (bukan di cloud)
  • di lebih dari satu tempat
  • terlepas dari apa pun yang terkait dengannya, misalnya kunci untuk data terenkripsi Anda, simpan di tempat yang terpisah dari data

Menurut saya, tempat terbaik adalah:

  • hard drive eksternal
  • tombol flash
  • komputer tidak terhubung ke internet

Bahkan lebih baik, cukup cetak saja, dan letakkan di brankas tahan api.


4
Keamanan / praktik terbaik berjalan seiring dengan kepraktisan. Jika strategi keamanan melumpuhkan kemampuan untuk menggunakan sistem, itu akan dilewati oleh pengguna daripada penyerang.
zaTricky

1

Saya memiliki file tar yang memiliki pengaturan dir pengguna saya (.bashrc, .ssh / dan file konfigurasi lainnya) yang saya simpan di tempat yang aman. Ketika saya mendapatkan akun shell baru di mana saja, saya unzip file tar ke dalamnya.

Anda hanya harus meletakkan kunci pribadi ke server yang Anda percayai, jika tidak, Anda harus membuat kunci pribadi baru di server hanya untuk server itu, dan mengizinkannya mengakses ke hal-hal yang Anda ingin akses.

Secara pribadi, saya nyaman hanya menyalin .ssh / barang-barang saya di mana-mana (itu juga berarti dengan kunci ssh biasa mendapat akses ssh langsung, karena sudah ada dalam file Authorized_key).


Saya kira, setelah terenkripsi ~ / .ssh nongkrong di usb stick akan menghemat dari kebutuhan untuk menghasilkan dan mengunggah kunci baru jika terjadi kegagalan perangkat keras. Namun, karena ada sangat sedikit server yang saya gunakan kunci SSH untuk mengakses (dan sangat sedikit mesin yang saya hubungkan), membuat kunci baru tidak akan menyebabkan banyak overhead.
Anton Strogonoff

2
Ini kuda untuk kursus dan tergantung pada mengapa Anda menggunakan kunci. Saya tidak melihat masalah menyalin kunci pribadi ssh di atas tautan SSH yang sudah dienkripsi. Tetapi jika Anda tidak mempercayai mesin target dan tidak tahu siapa yang memiliki akses root, Anda seharusnya tidak meletakkan apa pun di server yang tidak mampu Anda hilangkan.
EightBitTony

Anda tidak ingin meletakkan kunci pribadi Anda di server orang lain. Siapa pun yang memiliki akses Root pada server itu dapat membaca kunci pribadi Anda dan kemudian mereka dapat menyamar sebagai Anda pada sistem yang Anda akses dengan kunci pribadi itu. Anda hanya harus meletakkan kunci publik Anda untuk akses ke server. Dan jangan berpikir frasa sandi sangat membantu jika Anda menggunakannya pada mesin jarak jauh untuk mendekripsi kunci pribadi.
Codeguy007

Anda dapat meneruskan ssh-agent melalui ssh. Dengan begitu Anda tidak perlu menyimpan kunci pribadi di server atau mengirim frasa sandi Anda melalui internet. stackoverflow.com/questions/12257968/…
Codeguy007

1

Anda dapat menyimpan kunci ssh di direktori terpisah di dalam partisi terenkripsi. Kemudian Anda dapat menggunakan ssh menunjuk ke direktori itu dengan -i:

ssh -i identity_file me@example.com

Deskripsi lengkap ( man ssh):

-i identity_file

Memilih file dari mana identitas (kunci pribadi) untuk otentikasi kunci publik dibaca. Standarnya adalah ~ / .ssh / identitas untuk protokol versi 1, dan ~ / .ssh / id_dsa, ~ / .ssh / id_ecdsa, ~ / .ssh / id_ed25519 dan ~ / .ssh / id_rsa untuk versi protokol 2. File identitas mungkin juga ditentukan berdasarkan per-host dalam file konfigurasi.
Dimungkinkan untuk memiliki beberapa opsi -i (dan banyak identitas yang ditentukan dalam file konfigurasi). Jika tidak ada sertifikat yang secara eksplisit ditentukan oleh arahan CertificateFile, ssh juga akan mencoba memuat informasi sertifikat dari nama file yang diperoleh dengan menambahkan -cert.pub ke nama file identitas.

Pendekatan saya terhadap keamanan adalah bahwa saya membagi informasi menjadi pribadi dan umum. Saya tidak ingin mengenkripsi seluruh partisi rumah saya, itu sebabnya saya menyalin file rahasia (seperti yang ada di dalamnya ~/.ssh) ke partisi yang dienkripsi.

Saya pikir ini memberikan keamanan yang agak efisien, karena malware tidak akan menemukan apa pun di ~ / .ssh, dan mungkin itu tidak akan memindai seluruh sistem atau profil shell Anda untuk menemukan lokasi itu.

-F configfile 

setel path ke file konfigurasi.

PS Saya akan membuat alias alias ssh='ssh -i ... -F ...'dan memasukkannya ke profil Anda.

PPS Saya belum memeriksa ini, dan saya tidak tahu bagaimana program lain (seperti git) akan bekerja dengan pengaturan ssh ini.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.