Saya terutama bekerja pada mac dan ssh/tmux dilampirkan ke mesin Linux untuk melakukan pekerjaan saya. Saya memiliki ssh-agent yang berjalan di mesin Linux. saya punya
set -g update-environment "SSH_AUTH_SOCK SSH_ASKPASS WINDOWID SSH_CONNECTION XAUTHORITY"
di .tmux.conf saya . Namun, setiap kali saya melampirkan kembali ke sesi ini, saya harus menjalankan
tmux setenv SSH_AUTH_SOCK $SSH_AUTH_SOCK
agar jendela tmux baru memiliki $SSH_AUTH_SOCK diatur dengan benar. Saya lebih suka tidak harus melakukan ini. Ada ide?
Perbarui
Saya pikir saya tidak menjelaskan ini dengan baik. Inilah fungsi shell saya untuk membuka shell pada mesin jarak jauh:
sshh () {
tmux -u neww -n ${host} "ssh -Xt ${host} $*"
}
Ketika tmux menjalankan perintah ssh ini, $SSH_AUTH_SOCK adalah tidak ditetapkan, meskipun adalah diatur di lingkungan lokal saya. Jika saya meletakkan ini di lingkungan tmux dengan setenv perintah di atas, semuanya bekerja dengan baik. Pertanyaan saya, mengapa saya harus menjalankan perintah setenv sama sekali?
Perbarui 2
Informasi lebih lanjut:
Saat saya melampirkan ke sesi yang ada, $SSH_AUTH_SOCK tidak diatur di lingkungan tmux (atau lingkungan global).
% tmux showenv | grep -i auth_sock
-SSH_AUTH_SOCK
Jika saya mengaturnya secara manual, semuanya berfungsi:
% tmux setenv SSH_AUTH_SOCK $SSH_AUTH_SOCK
Jika saya melepas dan memasang kembali, $SSH_AUTH_SOCK kembali ke tidak disetel.
Jawaban yang Diterima:
Sejak saya menerima Bounty, saya akan memposting ulang komentar kunci saya demi kelengkapan – dan untuk menghindari pengaturan pengunjung dengan masalah yang sama di jalur yang salah:
Tmux akan menghapus Variabel Lingkungan
Halaman manual Tmux menyatakan bahwa update-environment akan menghapus variabel “yang tidak ada di lingkungan sumber […] seolah-olah -r diberikan ke perintah set-environment”.
Rupanya itu yang menyebabkan masalah. Lihat tanggapan Chris di bawah ini. Namun, saya masih tidak bisa membayangkan bagaimana variabel bisa tidak ada di "lingkungan sumber" dan tetap valid di jendela tmux yang baru dibuat…
Jawaban Sebelumnya:
Cara kerja penerusan SSH
Pada mesin jarak jauh, lihat lingkungan shell Anda setelah membuat koneksi SSH:
[email protected]:~$ env | grep SSH
SSH_CLIENT=68.38.123.35 45926 22
SSH_TTY=/dev/pts/0
SSH_CONNECTION=68.38.123.35 48926 10.1.35.23 22
SSH_AUTH_SOCK=/tmp/ssh-hRNwjA1342/agent.1342
Yang penting di sini adalah SSH_AUTH_SOCK yang saat ini disetel ke beberapa file di /tmp. Jika Anda memeriksa file ini, Anda akan melihat bahwa itu adalah soket domain Unix — dan terhubung ke instance ssh tertentu yang Anda hubungkan. Yang penting, ini berubah setiap kali Anda terhubung.
Segera setelah Anda keluar, file soket tertentu itu hilang. Sekarang, jika Anda pergi dan memasang kembali sesi tmux Anda, Anda akan melihat masalahnya. Ini memiliki lingkungan sejak tmux diluncurkan — yang bisa saja beberapa minggu yang lalu. Soket khusus itu sudah lama mati.
Terkait:uji shell apakah beberapa baris string berisi pola yang ditentukan di baris terakhir?Solusi
Karena kita tahu masalahnya berkaitan dengan mengetahui di mana soket otentikasi SSH yang aktif saat ini, mari kita letakkan di tempat yang dapat diprediksi!
Di file .bashrc atau .zshrc Anda di mesin jarak jauh, tambahkan berikut ini:
# Predictable SSH authentication socket location.
SOCK="/tmp/ssh-agent-$USER-screen"
if test $SSH_AUTH_SOCK && [ $SSH_AUTH_SOCK != $SOCK ]
then
rm -f /tmp/ssh-agent-$USER-screen
ln -sf $SSH_AUTH_SOCK $SOCK
export SSH_AUTH_SOCK=$SOCK
fi
Saya tidak berpikir Anda bahkan harus meletakkan 'perbarui-perintah lingkungan' di tmux.conf Anda. Menurut halaman manual, SSH_AUTH_SOCK sudah tercakup secara default.
Kredit
Tanggapan saya adalah kutipan dari posting blog ini oleh Mark 'xb95' Smith yang menjelaskan masalah yang sama untuk layar.