Apakah benar-benar aman untuk terhubung ke server oleh SSH dari hotel selama perjalanan?


13

Apakah benar-benar aman untuk terhubung ke server menggunakan SSH dari hotel selama perjalanan?

Server :
- CentOS 7
- Otorisasi hanya dengan kunci RSA - sandi auth ditolak
- Port non-standar

Workstation :
- Ubuntu 14
- kata sandi pengguna
- kata sandi untuk menggunakan kunci RSA (metode standar)

Mungkin itu ide yang baik untuk menjaga setengah dari kunci RSA pribadi pada USB stick, dan secara otomatis (dengan script) tambahkan setengah ini ke ~ / .ssh / private_key sebelum menghubungkan?

Internet akan melalui WIFI di hotel, atau kabel di apartemen sewaan.

UPD
Maaf karena tidak jelas pada awalnya. Maksud saya keamanan dalam dua aspek di sini:

  1. Keamanan hanya koneksi SSH melalui jaringan yang tidak terpercaya.
  2. Keamanan komputer dengan kunci yang diperlukan untuk koneksi SSH - jika dicuri, cara melindungi server ...

Apa setengah kunci RSA? Bagian publik dari kunci host ssh? Setengah dari bagian pribadi dari kunci ssh pengguna Anda?
andol

setengah dari kunci RSA pribadi saya, tentu saja :) dan secara otomatis dengan skrip untuk menambahkan setengah ini ke ~ / .ssh / private_key sebelum terhubung ke server.
Sergey Serov

Anda sudah lebih aman daripada kebanyakan orang karena Anda menjalankan Linux. Karena Anda menjalankan versi terbaru Anda harus memiliki versi baru OpenSSH yang mendukung crypto yang lebih kuat. Setelah mengikuti tecmint.com/5-best-practices-to-secure-and-protect-ssh-server Anda dapat bermain dengan membatasi diri Anda pada crypto yang lebih kuat seperti stribika.github.io/2015/01/04/secure-secure- shell.html
anak ayam

3
@chicks "lebih aman daripada kebanyakan orang karena Anda menjalankan Linux" adalah hal yang konyol untuk dikatakan. SSH adalah SSH, terlepas dari apakah itu berjalan di Linux, Unix (Mac) atau Windows. Dan kita bisa menunjukkan banyak kelemahan keamanan yang sangat serius di Linux dalam sejarah baru-baru ini (Heartbleed, ada orang?). Hanya mengatakan, mari kita tinggalkan perang api OS konyol di sela-sela tempat mereka berada karena mengalihkan perhatian dari pertanyaan dan masalah yang sebenarnya. Terima kasih! ;-)
Craig

2
@cicks Saya kira itulah yang ingin saya sampaikan. Banyak masalah keamanan di semua OS, dan Microsoft telah membuat langkah besar sejak memulai inisiatif "komputasi yang dapat dipercaya * mereka beberapa tahun yang lalu. Saya hanya berpikir hal" Anda lebih aman karena Linux "mengalihkan pembicaraan dari masalah aktual yang ada ( hormat). ;-)
Craig

Jawaban:


25

Jadi, tentang membuat koneksi ssh melalui koneksi yang secara eksplisit tidak dipercaya.

Dengan asumsi Anda sudah memiliki entri ~ / .ssh / known_hosts dari koneksi sebelumnya, ya Anda harus dapat terhubung tanpa khawatir tentang apa pun jaringan yang aman atau tidak. Hal yang sama berlaku jika Anda memiliki beberapa cara lain untuk memverifikasi kunci host ssh.

Jika Anda belum pernah terhubung ke server sebelumnya, atau memiliki cara lain untuk memverifikasi kunci host ssh, maka Anda mungkin ingin lebih berhati-hati mengenai jaringan yang Anda gunakan untuk terhubung.


Terima kasih!! Jadi aman terhubung ke server oleh SSH bahkan melalui wi-fi publik?
Sergey Serov

7
Sebenarnya, jawaban ini berlaku untuk setiap situasi di mana Anda ingin ssh ke server jauh dan setiap bagian dari jalan tidak di bawah kendali penuh Anda (jadi praktis apa pun selain ssh-ing ke localhost yang baru diinstal atau melalui kabel cross-link )
Hagen von Eitzen

6
Perlu diperhatikan bahwa jika klien tidak mengetahui kunci host, maka serangan MITM penuh akan dimungkinkan jika otentikasi kata sandi digunakan. Tetapi jika otentikasi berbasis kunci digunakan, penyerang hanya akan dapat menyamar sebagai server. Penyerang tidak akan dapat juga mengotentikasi ke server sebenarnya. Sulit bagi penyerang untuk memberikan peniruan yang meyakinkan dari server dalam kasus itu, sehingga Anda mungkin dapat melihat bahwa ada sesuatu yang salah sebelum terlambat. Singkatnya: otentikasi kunci publik jauh lebih aman daripada otentikasi kata sandi .
kasperd

2
@kasperd: Ya, jika klien terhubung mengaktifkan penerusan agen bahkan otentikasi kunci publik dapat memberikan pengalaman MITM lengkap. Tapi ya, otentikasi kunci publik jelas lebih disukai daripada kata sandi reguler, kapan saja.
andol

1
@kasperd: Ya, saya dapat dengan mudah membayangkan seseorang yang baru saja menemukan penerusan agen, tetapi tidak sepenuhnya memahaminya, meletakkan sesuatu seperti "Host * \ n \ tForwardAgent ya" di ~ / .ssh / config mereka. Orang-orang melakukan semua hal gila :-)
andol

11

Pada bagian kedua dari pertanyaan Anda, Anda sepertinya khawatir tentang notebook Anda dicuri dan, dengan itu, kunci pribadi Anda untuk login SSH-kurang-sandi ke server Anda.

Harap dicatat bahwa ini dapat dengan mudah diselesaikan (masalah kunci privat) dengan menyimpan kunci privat "terenkripsi" dengan "frasa sandi": mereka dapat dienkripsi pada awalnya, sambil menghasilkan dengan utilitas ssh-keygen , dengan memberikan frasa sandi di akhir proses pembuatan atau, jika Anda sudah membuatnya tidak diuraikan, gunakan utilitas ssh-keygen dengan -popsi. Setelah kunci dienkripsi, pada setiap login Anda diminta untuk memasukkan frasa sandi terkait dan .... jika benar, semuanya akan berjalan normal.

Juga, jika Anda tidak ingin memasukkan frasa sandi setiap kali meluncurkan klien ssh, Anda dapat menggunakan ssh-agent : ia dapat melacak, dalam memori, dari kunci pribadi yang tidak dienkripsi. Anda cukup menjalankan ssh-add yang menunjuk ke file yang menahan kunci terenkripsi dan, setelah meminta frasa sandi, kunci ditambahkan ke set yang dikelola oleh ssh-agent. Setelah itu, setiap kali klien SSH memerlukan kunci yang dilindungi frasa sandi, agen ssh secara transparan memberikan kunci pribadi yang tidak dienkripsi terkait kepada klien ssh. Jadi, bagi Anda, tidak perlu memasukkannya secara interaktif.

Harap dicatat bahwa ssh-agent dapat mengelola banyak kunci, dan jelas Anda dapat "menyetel" notebook / desktop Anda untuk meluncurkan ssh-addutilitas (untuk mengisi set kunci ssh-agent) pada saat login / waktu mulai.

Juga, jika seseorang mencuri laptop Anda, kunci pribadi Anda mungkin bukan satu-satunya konten "sensitif" yang akan Anda berikan: harap dicatat bahwa dengan distribusi desktop Linux hari ini, SANGAT mudah untuk mengatur notebook yang mengandalkan "terenkripsi". "sistem file ( /homesebagai starter, tetapi keseluruhan /jika diperlukan). Jadi, tolong, pertimbangkan ini juga.

Semua hal di atas, jelas, TIDAK berlaku jika Anda TIDAK mengandalkan notebook ANDA SENDIRI .


PS: mengenai kemungkinan Anda untuk menyimpan dua bagian kunci pribadi yang tidak dienkripsi pada media yang berbeda: Saya sangat menyarankan Anda untuk tidak melakukan ini, karena menjaga dua potong konten sensitif dalam bentuk yang tidak terenkripsi jauh, jauh lebih buruk, daripada menyimpan dua salinan lengkap dari seluruh konten, dienkripsi!


5

Bagian pertama dari pertanyaan Anda sudah dijawab oleh respons sebelumnya. Sesuai bagian kedua Anda, saya akan merekomendasikan untuk menambahkan faktor kedua ke login ssh Anda menggunakan pam_google_authenticator. Ini adalah pengaturan yang cukup mudah dan konfigurasi pada distro apa pun. Dalam kasus di mana kunci pribadi yang Anda bawa dicuri, mereka tidak dapat masuk ke server Anda tanpa password TOTP satu kali dari google-authenticator.

https://www.howtoforge.com/tutorial/secure-ssh-with-google-authenticator-on-centos-7

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.