Penerusan ssh-agent dan sudo ke pengguna lain

Jika saya memiliki server A di mana saya dapat login 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 penerusan kunci melalui "sudo su - otheruser", sehingga saya dapat melakukan hal-hal pada server B dengan kunci penerusan saya (git clone dan rsync dalam kasus saya)?

Satu-satunya cara yang bisa saya pikirkan adalah menambahkan kunci saya ke otor_keys dari pengguna lain dan "ssh otheruser @ localhost", tapi itu rumit untuk dilakukan untuk setiap kombinasi pengguna dan server yang mungkin saya miliki.

Pendeknya:

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

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

Tetapi untungnya sudocukup dapat dikonfigurasi: Anda dapat menentukan dengan tepat variabel lingkungan mana yang ingin Anda pertahankan berkat env_keepopsi konfigurasi di /etc/sudoers.

Untuk penerusan agen, Anda perlu menjaga SSH_AUTH_SOCKvariabel lingkungan. Untuk melakukannya, cukup edit /etc/sudoersfile konfigurasi Anda (selalu menggunakan visudo) dan atur env_keepopsi ke pengguna yang sesuai. Jika Anda ingin opsi ini disetel untuk semua pengguna, gunakan Defaultsbaris seperti ini:

Defaults    env_keep+=SSH_AUTH_SOCK

man sudoers untuk lebih jelasnya.

Sekarang Anda harus dapat melakukan sesuatu seperti ini (yang disediakan user1's kunci publik hadir di ~/.ssh/authorized_keysdalam user1@serverAdan user2@serverB, dan serverA' s /etc/sudoersfile setup 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

sudo -E -s

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

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

Izinkan pengguna lain mengakses $SSH_AUTH_SOCKfile dan direktori itu, misalnya dengan ACL yang benar, sebelum beralih ke file tersebut. Contoh mengasumsikan Defaults:user env_keep += SSH_AUTH_SOCKdi /etc/sudoersatas 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 bekerja untuk pengguna non-root juga ;-)

Saya telah menemukan bahwa ini juga berfungsi.

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

Seperti yang telah dicatat orang lain, ini tidak akan berfungsi jika pengguna yang Anda pindahkan tidak memiliki izin baca di $ SSH_AUTH_SOCK (yang mana hampir semua pengguna selain root). Anda dapat menyiasatinya dengan menetapkan $ SSH_AUTH_SOCK dan direktori yang ada di dalamnya 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 sekalipun. Anda pada dasarnya memberi setiap pengguna lain izin sistem untuk menggunakan Agen SSH Anda (sampai Anda keluar). Anda juga dapat mengatur grup dan mengubah izin menjadi 770, yang bisa lebih aman. Namun, ketika saya mencoba mengubah grup, saya mendapat "Operasi tidak diizinkan".

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

Anda selalu dapat ssh ke localhost dengan penerusan agen alih-alih 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 (tentu saja) akan rusak lagi . Jadi itu tidak ideal jika Anda tidak dapat menjaga layar / sesi tmux Anda terbuka setiap saat (namun, Anda dapat secara manual memperbarui SSH_AUTH_SOCKenv var Anda jika Anda keren).

Perhatikan juga bahwa ketika menggunakan penerusan ssh, root selalu dapat mengakses soket Anda dan menggunakan otentikasi ssh Anda (selama Anda masuk dengan penerusan ssh). Jadi pastikan Anda bisa memercayai root.

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

Menggabungkan informasi dari jawaban lain saya datang dengan ini:

user=app
setfacl -m $user:x $(dirname "$SSH_AUTH_SOCK")
setfacl -m $user:rwx "$SSH_AUTH_SOCK"
sudo SSH_AUTH_SOCK="$SSH_AUTH_SOCK" -u $user -i

Saya suka ini karena saya tidak perlu mengedit sudoersfile.

Diuji pada Ubuntu 14.04 (harus menginstal aclpaket).

Saya pikir ada masalah dengan opsi -(dash) setelah sudi perintah Anda:

sudo su - otheruser

Jika Anda membaca halaman manual su , Anda mungkin menemukan bahwa opsi -, -l, --loginmemulai lingkungan shell sebagai shell login. Ini akan menjadi lingkungan untuk otheruserterlepas dari variabel env tempat Anda menjalankan su.

Sederhananya, tanda hubung akan merusak apa pun yang Anda lewati sudo.

Sebagai gantinya, Anda harus mencoba perintah ini:

sudo -E su otheruser

Seperti yang ditunjukkan @ joao-costa, -Eakan mempertahankan semua variabel di lingkungan tempat Anda berlari sudo. Kemudian tanpa tanda hubung, suakan menggunakan lingkungan itu secara langsung.

Sayangnya ketika Anda su ke pengguna lain (atau bahkan menggunakan sudo) Anda akan kehilangan kemampuan untuk menggunakan kunci yang diteruskan Anda. Ini adalah fitur keamanan: Anda tidak ingin pengguna acak terhubung ke ssh-agent Anda dan menggunakan kunci Anda :)

Metode "ssh -Ay $ {USER} @localhost" sedikit rumit (dan seperti yang tercantum dalam komentar saya pada jawaban David yang cenderung rusak), tetapi mungkin itu yang terbaik yang dapat Anda lakukan.