Bastion server: gunakan penerusan TCP VS menempatkan kunci pribadi di server


10

Kami memiliki server benteng B. Kita perlu SSH dari A hingga B ke C, menggunakan kunci pribadi.

Apa pilihan yang lebih baik:

  • Letakkan kunci SSH pribadi di server B. Kita membaca bahwa itu ide yang buruk untuk melakukannya di lingkungan produksi.

    Dari sini :

    Jangan pernah tempatkan kunci pribadi SSH Anda pada instance benteng. Sebagai gantinya, gunakan penerusan agen SSH untuk terhubung pertama kali ke bastion dan dari sana ke instance lain dalam subnet pribadi. Ini memungkinkan Anda menyimpan kunci pribadi SSH hanya di komputer Anda.

  • Gunakan penerusan agen SSH . Untuk mengatur penerusan agen, saya perlu mengizinkan TCP Forwarding. Saat mengatur penerusan agen, file soket dibuat pada host penerusan, yang merupakan mekanisme dimana kunci dapat diteruskan ke tujuan. Dalam pengaturan Bastion di AWS:

    Penerusan TCP: Mengatur nilai ini ke true akan mengaktifkan penerusan TCP (penerowongan SSH). Ini bisa sangat berguna tetapi juga merupakan risiko keamanan, jadi kami sarankan Anda menjaga pengaturan default (dinonaktifkan) kecuali diminta

    Juga dari sini :

    Penerusan Agen SSH dianggap berbahaya

Apa yang lebih baik Bagaimana dengan alternatif dari tautan kedua: ProxyCommand , saya memahaminya membantu dengan masalah file socket, tapi tetap saya pikir saya harus mengaktifkan penerusan TCP, jadi apakah cukup aman?


2
Dengan ProxyCommand Anda tidak perlu mengaktifkan penerusan TCP. Penerusan dilakukan oleh ssh pada host perantara.
Wurtel

Terima kasih. Apakah file konfigurasi seharusnya? di komputer saya atau di Bastion?
user2503775

Pada sistem lokal Anda, di mana Anda akan memasukkan ssh hostbperintah, sehingga dapat mencari hostb di konfigurasi lokal dan tahu bahwa itu perlu terhubung melalui hosta. Tidak bisa melakukan itu jika Anda meletakkan konfigurasi pada hosta ...
wurtel

Di mana kunci pribadi server C akan disimpan? juga di comp saya? Saya menggunakan keepass dengan keeAgent
user2503775

2
Saya khawatir Anda membingungkan penerusan TCP dengan penerusan Agen . Mereka adalah hal yang berbeda.
MLu

Jawaban:


13

Gunakan ProxyCommand atau ProxyJump

Saya akan merekomendasikan untuk menggunakan ProxyCommand(atau bahkan lebih baik ProxyJumpkarena sintaks lebih mudah tetapi memerlukan openssh 7.3+ saya pikir di sisi klien), dan Anda tidak perlu menggunakan kunci pribadi di Bastion, semuanya tetap lokal.

Contoh dengan ProxyJump

Di komputer klien Anda, Anda menulis file di bawah ~/.ssh/configdengan konten yang mirip dengan di bawah ini:

Host bastion
  HostName bastion.example.com
  User bastion-user
  Port 22
  IdentityFile ~/.ssh/id_bastion

Host srvC
  HostName srvC.local
  User server-user
  IdentityFile ~/.ssh/id_protected_lan
  ProxyJump bastion

Kemudian lakukan ssh srvCakan menghubungkan Anda ke C melalui B (bastion) tanpa Agen Forwarding atau menggunakan kunci pribadi ke bastion.

Dalam contoh di atas, "bastion" adalah alias untuk host Bastion Anda dan srvC adalah alias untuk server Anda C. Di dalam HostNameAnda perlu memasukkan IP atau nama domain yang benar-benar berkualifikasi untuk host Anda. Untuk pengguna, Anda perlu memperbarui Useruntuk nama login yang benar di Bastion dan server C. Akhirnya IdentityFileadalah opsional jika Anda menggunakan agen lokal (mis. KeeAgent atau ssh-agent), tetapi jika tidak berjalan maka itu juga akan bekerja dan minta Anda untuk setiap frasa sandi utama.

Menyebarkan kunci publik

Tentu saja Anda perlu menggunakan kunci publik untuk kedua bastion dan srvC. Anda dapat menggunakan (tanda $ hanya untuk menggambarkan prompt, jangan mengetiknya):

$ ssh-copy-id -i ~/.ssh/id_bastion.pub \
   -o PreferredAuthentications=password \
   -o PubkeyAuthentication=no \
   bastion
$ ssh-copy-id -i ~/.ssh/id_protected_lan.pub \
   -o PreferredAuthentications=password \
   -o PubkeyAuthentication=no \
   srvC

Catatan: di atas hanya akan berfungsi jika otentikasi kata sandi masih diizinkan. Setelah penyebaran di atas dan memverifikasi bahwa semuanya berfungsi sebagaimana mestinya, Anda harus melarang otentikasi kata sandi pada 2 server.

Contoh dengan ProxyCommand bukan ProxyJump

Jika Anda memiliki versi OpenSSH yang lebih lama yang tidak mendukung ProxyJump(di sisi klien), maka ganti:

ProxyJump bastion

oleh

ProxyCommand ssh -q -W %h:%p bastion

Sejauh yang saya mengerti, ini mirip.


Terima kasih! Saya bekerja dengan linux, tetapi kami memiliki beberapa anggota tim yang bekerja di windows. Seharusnya juga bekerja di sana, bukan?
user2503775

Klien SSH mana yang akan mereka gunakan? OpenSSH (via WSL, atau cygwin atau dll.) Atau Putty (atau alat lain berdasarkan Putty) seperti MobaXterm?
Huygens

Beberapa dari mereka menggunakan Putty dan yang lain menggunakan ssh via Git Shell.
user2503775

@ user2503775 Saya belum pernah mencobanya dengan Putty, tetapi tampaknya mungkin menggunakan pendekatan ProxyCommand, lihat di sini: stackoverflow.com/a/28937185
Huygens

1
Terima kasih banyak atas jawaban terperinci!
user2503775

5

Saya melihat jawaban tentang ProxyJump. Mari kita bicara tentang ProxyCommand .

Tapi tunggu, tunggu! Saya dapat menulis kepada Anda cara meretas server yang menggunakan penerusan Agen, yang akan jauh lebih mudah untuk memahami perbedaannya!

Ayo kembali!

Untuk langkah-langkah dasar: Anda dapat membaca posting saya di sini

Langkah-langkah dasar adalah sebagai berikut:

  1. Buat pengguna benteng
  2. Nonaktifkan login root
  3. Blokir upaya peretasan
  4. Ubah port
  5. Konfigurasikan firewall
  6. Konfigurasikan SELinux

Cara menggunakan AgentForwarding

-Buat konfigurasi di ~ / .ssh / config

  Host bast
        Hostname BASTION_IP
        ForwardAgent yes
        User bastion

-Tambahkan kunci otentikasi Anda ke ssh-agent

ssh-add ~/.ssh/name_rsa

-Sambungkan ke rumah benteng

ssh bast

-Hubungkan server aplikasi dari benteng

 ssh app@IP -p PORT

Peretasan!

Anda mungkin, mengajukan pertanyaan kepada saya:

  • Apakah server saya aman? Dan jawabannya cukup sederhana:

    • TIDAK!
  • Mengapa?

    • Karena Anda menggunakan penerusan Agen SSH!
  • Dan di mana masalahnya?

    • Karena penerusan agen berbahaya dan itu dianggap berbahaya.
  • Mengapa?

    • Mari kita jelaskan semuanya dari dalam ke luar: Ketika Anda menghubungkan host bastion, ssh-agent agung Anda diteruskan. Ini berarti bahwa soket akan diatur sehingga seseorang dapat menggunakan data soket ini untuk mengakses server Anda. Bayangkan server benteng Anda dikompromikan, Jika seseorang memiliki izin yang memadai di server Linux Anda, ia hanya akan menggunakan informasi soket Anda. Akibatnya, semua server Anda dapat diakses. Saya tahu jendela kompromi sangat kecil karena itu tergantung pada berapa banyak waktu Anda terhubung ke host benteng. Tetapi apakah Anda benar-benar ingin mengambil risiko ketika Anda memiliki opsi lain seperti ProxyCommand? Karenanya, cukup gunakan ProxyCommand!

Bagaimana cara meretas server jika Anda mengompromikan bastion host?

Lacak Target

Dalam direktori / tmp Anda mungkin melihat sesuatu seperti itu:

[root@localhost tmp]# ll
total 12
drwx------  2 bastion bastion 4096 Sep  7 17:35 ssh-mKX88v0Vlo

Mari kita buka file sementara

[root@localhost tmp]# cd ssh-mKX88v0Vlo/
[root@localhost ssh-mKX88v0Vlo]# ll
total 0
srwxr-xr-x 1 bastion bastion 0 Sep  7 17:35 agent.10507

Mari kita lihat koneksi ke id proses ini.

netstat -nxp | grep  10507

hasil:

unix  [ ]   STREAM     CONNECTED     501384   10507/sshd: bastion

dan siapa yang terhubung?

lsof -i -a -p 10507

hasil:

COMMAND  PID   USER  FD  TYPE DEVICE SIZE/OFF NODE NAME
sshd    10507 bastion  3u  IPv4 501301  0t0  TCP *IP*:ssh->*IP*:8279 (ESTABLISHED)

Kita juga dapat melihat file socket:

cd /proc/10507/fd/
ls

hasil:

lrwx------ 1 root root 64 Sep  7 17:46 0 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 1 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 10 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 14 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 15 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 2 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 3 -> socket:[501994]
lrwx------ 1 root root 64 Sep  7 17:46 4 -> socket:[502069]
lrwx------ 1 root root 64 Sep  7 17:46 5 -> socket:[502072]
l-wx------ 1 root root 64 Sep  7 17:46 6 -> /run/systemd/sessions/1836.ref
lr-x------ 1 root root 64 Sep  7 17:46 7 -> pipe:[502079]
l-wx------ 1 root root 64 Sep  7 17:46 8 -> pipe:[502079]
lrwx------ 1 root root 64 Sep  7 17:46 9 -> socket:[502080]

Dan apa yang terjadi ketika klien akan terhubung ke server jauh? Ayo lihat:

lrwx------ 1 root root 64 Sep  7 17:46 0 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 1 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 10 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:48 11 -> socket:[502267]
lrwx------ 1 root root 64 Sep  7 17:46 14 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 15 -> /dev/ptmx
lrwx------ 1 root root 64 Sep  7 17:46 2 -> /dev/null
lrwx------ 1 root root 64 Sep  7 17:46 3 -> socket:[501994]
lrwx------ 1 root root 64 Sep  7 17:46 4 -> socket:[502069]
lrwx------ 1 root root 64 Sep  7 17:46 5 -> socket:[502072]
l-wx------ 1 root root 64 Sep  7 17:46 6 -> /run/systemd/sessions/1836.ref
lr-x------ 1 root root 64 Sep  7 17:46 7 -> pipe:[502079]
l-wx------ 1 root root 64 Sep  7 17:46 8 -> pipe:[502079]
lrwx------ 1 root root 64 Sep  7 17:46 9 -> socket:[502080]

Kita bahkan dapat melihat apakah file socket digunakan menggunakan netstat:

unix  3 [ ]  STREAM  CONNECTED  502267  10561/sshd: 
                     bastion  /tmp/ssh-oVoMXC6vb8/agent.10561
unix  3  [ ] STREAM     CONNECTED     502072   10561/sshd:  bastion 

Mencuri info Socket dan alamat IP

Sekarang kita perlu mencuri informasi soket saat sesi bastion host terbuka . Oh, kita juga perlu IP server tujuan , jadi gunakan saja netstat:

netstat -tn

Langkah terakhir untuk menggunakan file socket yang diteruskan

eval "$(ssh-agent -s)"
SSH_AUTH_SOCK=/tmp/ssh-EAKxOdL4fl/agent.10507

Periksa apakah kunci sudah dimuat .

ssh-add -l

Hasilnya harus seperti itu :

2048 SHA256:2Psdl..B5KQ /home/usr/.ssh/name_rsa (RSA)

Server diretas, bagaimana cara memperbaiki masalah keamanan?

Perintah proxy

Host app
    Hostname *.*.*.*
    IdentityFile ~/.ssh/your_rsa
    User *******
    Port ****
    ProxyCommand ssh -W %h:%p bast

Host bast
     Hostname *.*.*.*
     ForwardAgent no
     User ******

Untuk operasi dasar: cara mentransfer file melalui server (dari klien ke server, server ke klien), Anda dapat membaca posting saya di sini

Kesimpulan

  • Jika Anda menggunakan bastion host, jangan gunakan AgentForwarding tetapi gunakan ProxyCommand
  • Selalu gunakan pengguna non-root untuk otentikasi
  • Gunakan firewall dan blokir semua koneksi yang tidak perlu.
  • Gunakan SELinux (Secara umum)
  • Blokir alamat IP yang mencoba masuk beberapa kali dengan kredensial yang salah
  • Jika tidak perlu, jangan berikan sudo izin kepada pengguna
  • Monitor server Anda
  • Perbarui server Anda untuk patch keamanan

Informasi lebih lanjut, lihat blog saya . Selain itu saya punya beberapa screeenshots, jadi mungkin bermanfaat untuk Anda.


Terima kasih banyak! sebenarnya, kami juga menggunakan autentikator google saat login.
user2503775

Saya mendapatkan pesan kesalahan saat mencoba untuk memanggil aplikasi ssh: channel 0: open failed: administratively prohibited: open failed. stdio forwarding failed. . Apakah Anda punya ide mengapa? Di log yang aman saya melihat:refused local port forward: originator 127.0.0.1 port 65535, target *app-ip* port 22
user2503775

Info keren Saran kecil untuk meningkatkan keterbacaan jawaban Anda. Jangan menyalin / menempelkan konten blog Anda di sini. Berikan tautan dan hanya ringkasan. Kemudian sorot bagian jawaban yang sebenarnya (yang bagi Anda menggunakan ProxyCommand). Saya melihat Anda agak mencobanya di awal tetapi mengingat bagian copy / paste itu agak membingungkan. Pokoknya +1
Huygens

@ user2503775 Seharusnya masalah yang berbeda, tidak terkait ssh-agent forwarding / perintah proxy. Mari kita buka pertanyaan baru dengan log.
grep


4

Cukup gunakan penerusan agen SSH seperti kebanyakan orang lain lakukan.

  • Kunci akan berada di ssh agent di laptop Anda.
  • Anda masuk ke benteng, diautentikasi melalui agen.
  • Dari sana login ke host target Anda, dengan permintaan otentikasi diteruskan kembali ke laptop Anda .

Keuntungan: tidak ada kunci yang disimpan di benteng yang dapat disalahgunakan.

Semoga itu bisa membantu :)


Hai, pada dasarnya itulah yang dijelaskan OP dalam peluru keduanya. Saya menyarankan Anda memeriksa tautan kedua yang disediakan dalam pertanyaan.
Huygens

@ Huygens benar saya perhatikan sekarang. Saya overloked bahwa ketika ia menggabungkan TCP forwarding dengan Agent forwarding.
MLu

Memang ini campur aduk :-)
Huygens

Itu tidak tercampur. Saya mengerti perbedaannya. Saya mengedit pertanyaan untuk membuatnya jelas.
user2503775

Saya menulis jawaban, bagaimana meretas forwarding agen (Tidak ada kunci tetapi ada soket terbuka). Umumnya, penerusan agen tidak apa-apa karena kemungkinan untuk mencuri kunci sangat rendah - pertama-tama, Anda harus meretas bastion host. Pokoknya Anda dapat melihat jawaban saya: serverfault.com/a/958466/476642
grep
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.