Pertanyaan ssh-agent forwarding dan sudo ke pengguna lain


Jika saya memiliki server A yang dapat saya masuki dengan kunci ssh saya dan saya memiliki kemampuan untuk "sudo su - otheruser", saya kehilangan penerusan kunci, karena variabel env dihapus dan soket hanya dapat dibaca oleh pengguna asli saya. Apakah ada cara saya dapat menjembatani kunci forwarding melalui "sudo su - otheruser", sehingga saya bisa melakukan hal-hal di server B dengan kunci saya diteruskan (git clone dan rsync dalam kasus saya)?

Satu-satunya cara yang dapat saya pikirkan adalah menambahkan kunci saya ke authorized_keys dari pengguna lain dan "ssh otheruser @ localhost", tapi itu tidak praktis untuk setiap pengguna dan kombinasi server yang mungkin saya miliki.

Pendeknya:

$ sudo -HE ssh user@host
(success)
$ sudo -HE -u otheruser ssh user@host
Permission denied (publickey). 

144
2018-01-28 13:52






Jawaban:


Seperti yang Anda sebutkan, variabel lingkungan dihapus oleh sudo, untuk alasan keamanan.

Tapi untungnya sudo cukup dapat dikonfigurasi: Anda dapat memberi tahu dengan tepat variabel lingkungan mana yang ingin Anda teruskan berkat env_keep opsi konfigurasi di /etc/sudoers.

Untuk penerusan agen, Anda harus menyimpannya SSH_AUTH_SOCK variabel lingkungan. Untuk melakukannya, cukup edit /etc/sudoers file konfigurasi (selalu menggunakan visudo) dan mengatur env_keep pilihan untuk pengguna yang sesuai. Jika Anda ingin opsi ini ditetapkan untuk semua pengguna, gunakan Defaults baris seperti ini:

Defaults    env_keep+=SSH_AUTH_SOCK

man sudoers untuk lebih jelasnya.

Anda sekarang seharusnya bisa melakukan sesuatu seperti ini (disediakan user1kunci publik hadir di ~/.ssh/authorized_keys di user1@serverA dan user2@serverB, dan serverA's /etc/sudoers file diatur seperti yang ditunjukkan di atas):

user1@mymachine> eval `ssh-agent`  # starts ssh-agent
user1@mymachine> ssh-add           # add user1's key to agent (requires pwd)
user1@mymachine> ssh -A serverA    # no pwd required + agent forwarding activated
user1@serverA> sudo su - user2     # sudo keeps agent forwarding active :-)
user2@serverA> ssh serverB         # goto user2@serverB w/o typing pwd again...
user2@serverB>                     # ...because forwarding still works

168
2018-03-03 21:24



Ini adalah jawaban yang benar, harus ditandai. - Xealot
Ini hanya bekerja, jika user2 di atas adalah root! Jika tidak, user2 akan memiliki SSH_AUTH_SOCK diatur dengan benar, tetapi user2 tidak akan dapat mengakses mis. / tmp / ssh-GjglIJ9337 /. root memang memiliki akses itu. Jadi ini bisa memecahkan sebagian masalah, tapi bukan OP: "dan soket hanya dapat dibaca oleh pengguna asli saya " - Peter V. Mørch
Defaults>root env_keep+=SSH_AUTH_SOCK Sebaiknya pastikan hanya ke depan saat sudoing untuk akar. Anda tidak ingin melakukan itu kepada pengguna lain untuk alasan keamanan. Lebih baik jalankan ssh-agent terpisah untuk otherother, dan tambahkan kunci yang sesuai. - Paul Schyska
sudo su - tidak bekerja untuk saya, mungkin itu tidak dapat menjaga lingkungan karena tidak sudo pada waktu startup shell. sudo su sepertinya berhasil. - Alex Fortuna
Saya tidak pernah mengerti mengapa orang menggunakan sudo su bagaimanapun. Jika Anda membutuhkan cangkang akar, itulah yang terjadi sudo -s atau sudo -i adalah untuk. - eaj


sudo -E -s
  • -E akan melestarikan lingkungan
  • -s menjalankan perintah, default ke shell

Ini akan memberi Anda shell root dengan kunci asli masih dimuat.


54
2018-01-01 15:31



Seperti halnya komentar di atas, ini hanya menjawab pertanyaan jika Anda menjadi root, karena dalam kasus itu root bisa mendapatkan izin akses yang biasa pada $ SSH_AUTH_SOCK. - doshea


Mengizinkan pengguna lain untuk mengakses $SSH_AUTH_SOCK file dan direktori itu, misalnya dengan ACL yang benar, sebelum beralih ke mereka. Contoh ini mengasumsikan Defaults:user env_keep += SSH_AUTH_SOCK di /etc/sudoers di mesin host:

$ ssh -A user@host
user@host$ setfacl -m otheruser:x   $(dirname "$SSH_AUTH_SOCK")
user@host$ setfacl -m otheruser:rwx "$SSH_AUTH_SOCK"
user@host$ sudo su - otheruser
otheruser@host$ ssh server
otheruser@server$

Lebih aman dan berfungsi untuk pengguna non-root juga ;-)


33
2017-11-15 10:58



Ingat ketika menggunakan metode ini, orang lain masuk sebagai otheruser bisa juga menggunakan otentikasi ssh Anda. - gitaarik
Ini berfungsi untuk saya kecuali saya harus mengubah "sudo su - otheruser" menjadi "sudo su otheruser" (menghapus -). - Charles Finkel
Mengapa rwx dan tidak rw (atau r sama sekali)? - anatoly techtonik
@anatolytechtonik Dari man 7 unix - pada Linux yang menghubungkan ke soket membutuhkan izin baca dan tulis pada soket itu. Anda juga perlu mencari (mengeksekusi) dan menulis izin pada direktori tempat Anda membuat soket atau hanya mencari (mengeksekusi) izin ketika Anda terhubung ke soket ini. Jadi dalam jawaban di atas, jalankan izin pada soket adalah berlebihan. - mixel


Saya telah menemukan bahwa ini juga berfungsi.

sudo su -l -c "export SSH_AUTH_SOCK=$SSH_AUTH_SOCK; bash"

Seperti yang orang lain telah catat, ini tidak akan berfungsi jika pengguna yang Anda gunakan tidak memiliki izin baca di $ SSH_AUTH_SOCK (yang cukup banyak pengguna selain root). Anda bisa mendapatkan ini dengan mengatur $ SSH_AUTH_SOCK dan direktori yang dimilikinya untuk memiliki izin 777.

chmod 777 -R `dirname $SSH_AUTH_SOCK`
sudo su otheruser -l -c "export SSH_AUTH_SOCK=$SSH_AUTH_SOCK; bash"

Ini cukup berisiko. Anda pada dasarnya memberikan setiap pengguna lain pada izin sistem untuk menggunakan Agen SSH Anda (sampai Anda logout). Anda juga dapat mengatur grup dan mengubah izin ke 770, yang bisa lebih aman. Namun, ketika saya mencoba mengubah grup, saya mendapat "Operasi tidak diizinkan".


16
2018-03-21 00:01



Ini sangat berisiko. Memberikan setiap izin pengguna lain untuk menggunakan agen SSH Anda setara dengan memberi mereka semua kredensial Anda (dan jika Anda pernah menggunakan sudo atau su, memberi mereka kekuatan root atas semua pengguna lain pada sistem, serta semua sistem lain yang Anda sembunyikan!) . Ini TIDAK PERNAH PERNAH dilakukan! - Matija Nalis
Saya tidak setuju dengan pernyataan bahwa "Ini TIDAK PERNAH PERNAH DILAKUKAN!" Ada banyak kasus di mana risiko ini dapat diterima. Misalnya, tim kecil di mana setiap orang memiliki izin yang sama dan Anda mempercayai semua pengguna lain. Itu tidak boleh dilakukan tanpa memahami risiko yang ditimbulkannya. Namun begitu risiko tersebut dipahami, ada saatnya risiko itu dapat diterima. - phylae


Jika Anda berwenang untuk sudo su - $USER, maka Anda mungkin akan memiliki argumen yang baik untuk diizinkan melakukan ssh -AY $USER@localhost sebagai gantinya, dengan kunci publik Anda yang valid di direktori home $ USER. Kemudian penerusan autentikasi Anda akan dilakukan bersama Anda.


6
2018-01-28 14:08



Dia menyebutkan bahwa di bagian bawah pertanyaannya, dan mengatakan itu akan sulit dilakukan. - Fahad Sadah
Ini mungkin solusi terbaik tetapi menjadi berbulu jika $ USER adalah Real Person (tm) - mereka mungkin menghapus kunci SA dari authorized_keys atau mengubah kata sandinya ... - voretaq7
Anda dapat menghapus akses tulis mereka ke authorized_keys (meskipun jika mereka benar-benar disangkal menolak akses Florian, mereka dapat menghapus dan membuatnya kembali, itu berada di direktori yang mereka miliki) - Fahad Sadah


Anda selalu bisa hanya ssh ke localhost dengan agen forwarding daripada menggunakan sudo:

ssh -A otheruser@localhost

Kerugiannya adalah Anda harus masuk lagi, tetapi jika Anda menggunakannya di tab layar / tmux, itu hanya upaya satu kali, namun, jika Anda memutuskan sambungan dari server, soket akan (tentu saja) rusak lagi . Jadi itu tidak ideal jika Anda tidak dapat menjaga layar / sesi tmux terbuka setiap saat (namun, Anda dapat memperbarui secara manual SSH_AUTH_SOCKenv var jika kamu keren).

Juga perhatikan bahwa ketika menggunakan ssh forwarding, root selalu dapat mengakses soket Anda dan menggunakan otentikasi ssh Anda (selama Anda masuk dengan ssh forwarding). Jadi, pastikan Anda dapat mempercayai root.


4
2017-11-27 14:56





Jangan gunakan sudo su - USER, melainkan sudo -i -u USER. Bekerja untukku!


3
2018-01-28 16:51



Versi sudo apa yang Anda miliki? Tambang (1.6.7p5, CentOS 4.8) tidak memiliki -i di halaman manualnya. - David Mackintosh
Sudo version 1.6.9p17 berjalan di Debian Lenny. Mencoba sudo -s? - Fahad Sadah
Tidak bekerja untukku.
Pada Ubuntu, menggunakan Sudo 1.8.9p5, keduanya sudo -s maupun sudo -i bekerja untukku ... - Jon L.