ssh-agent dan layar


8

Beberapa waktu lalu di StackOverflow, saya menanyakan pertanyaan ini tentang ssh-agent dan crontab . Saya punya pertanyaan serupa sekarang tentang ssh-agent dan layar pada sistem linux.

Jadi, di Mac saya, ssh-agent diluncurkan saat startup sistem, jadi selalu tersedia untuk saya. Saya pikir itu akan benar di linux saya (redhat el5 / fedora) jika saya menggunakan X-Windows. Namun, ini adalah mesin server jarak jauh dan saya selalu masuk melalui ssh.

Saya ingin mengatur ssh-key dengan benar sehingga saya tidak perlu memasukkan kata sandi beberapa kali selama pembaruan atau komit svn. Saya senang mengetikkan frasa sandi saya sekali per sesi, dan saya mencegah tim kami untuk tidak memiliki kata sandi ssh-key.

Untuk sesaat yang bersinar, sepertinya melakukan "eval` ssh-agent -s` "di .bash_profile saya, dipasangkan dengan perintah untuk membunuh ssh-agent ketika saya logout, akan berhasil. Namun, kami sangat memanfaatkan layar untuk mengelola program interaktif yang sudah berjalan lama dan lingkungan pengembangan. Jika Anda memulai & menghentikan ssh-agent seperti yang saya jelaskan, maka ia terbunuh ketika Anda keluar dari terminal, dan sub-sesi layar yang dulu merujuk pada instance ssh-agent ditinggalkan.

Jadi ... bagaimana saya bisa menjadi pengguna konsol, yang menggunakan layar, yang menggunakan kata sandi dengan kunci ssh-nya, yang tidak harus mengetikkan kata sandi secara konstan?

Jawaban:


4

Dengan pengaturan berikut, Anda tidak perlu pembungkus apa pun untuk memohon screen. Selain itu, ia menghindari penggunaan /tmp(dengan konsekuensi risiko keamanan).

  1. Pastikan Anda memiliki direktori ~ / tmp:

    mkdir ~/tmp
    
  2. Tambahkan ke .screenrcbaris berikut:

    setenv SSH_AUTH_SOCK "$HOME/tmp/ssh-agent-screen"
    
    • Ini memastikan bahwa di dalam screen, sshmencari soket selalu di lokasi yang sama, bukan jalur yang berubah.
    • Anda harus menggunakan setenvshell mana pun yang Anda gunakan, karena itu layar dan bukan perintah shell.
  3. Tambahkan ke .bash_profilebaris berikut:

    [ -n "$SSH_AUTH_SOCK" ] && [ "$SSH_AUTH_SOCK"!="$HOME/tmp/ssh-agent-screen" ] && ln -sf "$SSH_AUTH_SOCK" "$HOME/tmp/ssh-agent-screen"
    
    • Ini akan menghubungkan dari lokasi tetap (di mana sshterlihat) ke yang asli, dan harus muncul setelah memulai ssh-agent.
    • Menggunakan [ -n "$SSH_AUTH_SOCK" ]dengan benar akan mencegah kesalahan saat SSH_AUTH_SOCKtidak diatur.
    • [ "$SSH_AUTH_SOCK"!="$HOME/tmp/ssh-agent-screen" ]akan mencegah sesi layar yang menghubungkan $ HOME / tmp / ssh-agent-screen dengan dirinya sendiri, jika sumber layar .bash_profile.
  4. Alih-alih mulai ssh-agentdi .bash_profile, Anda dapat mempertimbangkan menghubungkan dengan ssh -A(dengan penggunaan agen forwarding dan membuat penggunaan mesin remote agen Anda).

Setelah pengaturan ini, Anda bisa menggunakan perintah layar standar. Anda hanya perlu membuat ulang sesi yang ada atau secara manual mengatur SSH_AUTH_SOCK di dalamnya untuk lokasi tetap langkah 2.

Kredit ke situs web ini untuk ide tersebut; Saya menghindari penggunaan /tmp. Jawaban ini serupa tetapi menggunakan alias tambahan.


2

Bisakah Anda meluncurkan ssh-agent dari skrip init bukan .bash_profile? Sebagai contoh, saya bisa katakan

su -c 'ssh-agent -s > ~/.ssh_agent_env' myusername

di bagian yang sesuai /etc/conf.d/local, meskipun RHEL / Fedora mungkin menggunakan sistem yang berbeda. Seperti yang Anda tunjukkan dalam komentar Anda, sesi terminal harus dapat terhubung ke agen, itulah sebabnya perintah itu membuat file .ssh_agent_envdi direktori home pengguna. Maka Anda bisa menambahkan

[ -f ~/.ssh_agent_env ] && source ~/.ssh_agent_env >/dev/null

di .bash_profile.

Hal lain yang bisa Anda lakukan adalah memasukkan yang berikut .bash_profile

ps -U myusername | grep -q ssh-agent || ssh-agent -s > ~/.ssh_agent_env
source ~/.ssh_agent_env >/dev/null

yang akan mulai ssh-agenthanya jika belum berjalan. Maka Anda tidak perlu membunuhnya.

Sebagai alternatif yang sedikit berbeda dengan saran kedua, alih-alih memeriksa keberadaan suatu ssh-agentproses, Anda dapat memeriksa keberadaan file ~/.ssh_agent_env,

[ -f ~/.ssh_agent_env ] || ssh-agent -s > ~/.ssh_agent_env
source ~/.ssh_agent_env >/dev/null

Jika semuanya bekerja dengan baik, seharusnya tidak ada perbedaan yang signifikan antara kedua cara.


Gagasan skrip init menarik - pada dasarnya, mulai saja di startup sistem untuk semua pengguna yang menginginkannya? Itu bisa berhasil. Kami tidak memiliki banyak pengguna yang peduli. Apakah itu secara signifikan lebih baik daripada tidak memiliki kata sandi sama sekali adalah pertanyaan yang menarik, karena saya kira itu berarti Anda hanya perlu memasukkannya sekali per restart mesin. Hmm. Baik itu maupun saran kedua bergantung pada sesi terminal baru untuk dapat terhubung ke ssh-agent jika sudah berjalan. Saya tidak sepenuhnya yakin itu mudah, tetapi saya belum mencoba. Terima kasih atas ide-idenya!
Michael H.

@khedron: Ya, tetapi Anda harus memasukkan satu baris /etc/conf.d/local(atau yang setara) untuk setiap pengguna yang menggunakan agen, untuk meluncurkan ssh-agentproses terpisah per pengguna. Jika, seperti yang Anda katakan, Anda tidak memiliki banyak pengguna, itu tidak akan terlalu buruk. Anda mengajukan poin yang baik (yang saya lupa pertimbangkan) tentang sesi terminal yang dilampirkan pada agen; lihat edit saya untuk jawabannya.
David Z


2

Pendekatan yang lebih baik adalah dengan menggunakan penerusan ssh agent ( -Aopsi). Hal ini memungkinkan orang yang menggunakan ssh untuk menggunakan kunci dari ssh-agent yang berjalan pada mesin asal mereka, mungkin workstation tempat mereka sebenarnya duduk.


Ini juga memungkinkan penyerang yang berkompromi dengan akun Anda untuk berkompromi dengan akun di mesin lain yang dapat diakses oleh agen itu. Karena itu saya mencoba untuk menjaga agar ssh agent forwarding seminimal mungkin.
Paul Price

2

untuk menindaklanjuti penerusan ssh agent, Anda akan menemukan bahwa secara default kredensial ssh yang diteruskan tidak akan tersedia untuk sesi layar Anda setelah Anda keluar, masuk kembali, dan melampirkan kembali sesssion Anda.

Namun, Anda dapat menyiasatinya, dengan membuat layar mengatur variabel lingkungan SSH_AUTH_SOCK menjadi sesuatu yang terkenal, dan membuat lokasi yang terkenal itu diperbarui ke soket auth Anda saat ini.

Saya menggunakan fungsi shell ini untuk masuk kembali ke layar dan memperbaiki ssh auth sock:

function sr () { 
    if [ ${+STY} = 1 ] ;then 
            echo already in screen\!
    else
            if [ "${SSH_AUTH_SOCK}x" != "x" ]; then
                    if [ ! -d /tmp/screenssh ]; then
                            mkdir /tmp/screenssh 
                    fi
                    rm -f /tmp/screenssh/socket
                    ln -s $SSH_AUTH_SOCK /tmp/screenssh/socket
                    echo $REMIP > /tmp/screenssh/remip
            fi                
            screen -DR
    fi
}

dan saya memilikinya di .screenrc saya:

setenv SSH_AUTH_SOCK /tmp/screenssh/socket

Semoga ini membantu.


Menggunakan / tmp berarti bahwa orang lain di mesin dapat mengalahkan semua file Anda, jika dia tahu jalannya.
Blaisorblade

1

Jika saya mengerti Anda benar, Anda hanya ingin sesi layar, yang Anda lepaskan dan pasang kembali kadang-kadang tetapi tidak pernah lagi ingin memasukkan kembali kata sandi untuk ssh-agent (kata sandi kunci pribadi Anda).

Saya pikir cara termudah adalah mulai layar, daripada mulai ssh-agent dengan sub shell dan kemudian tetap di sub shell itu. Yaitu

screen
ssh-agent bash
ssh-add   # enter your password once

# some commands, some logins and logouts to remote servers via ssh public key

# <ctrl>+<a>, <ctrl>+<d> to detach screen
# you can now logout from this computer
# login again

# reattach to your screen
screen -r
# ssh-agent is still running

Pada dasarnya itulah yang saya lakukan. Saya menggunakan layar untuk melabeli salah satu "tab" di dalamnya sebagai memiliki kekuatan ssh-agent, dan menggunakannya untuk pekerjaan svn, dll. Ada kerutan tambahan di mana saya memaksa ssh-agent untuk mengotorisasi ulang setelah beberapa jam, tapi ya, ini pada dasarnya di mana saya berada.
Michael H.
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.