ssh-агент і екран


8

Нещодавно повернувшись на StackOverflow, я задав це питання щодо ssh-агента та crontab . У мене зараз подібне питання щодо ssh-агента та екрана в системах Linux.

Отже, на моєму Mac, ssh-агент запускається при запуску системи, тому мені це завжди доступно. Я думаю, це було б правдою під моїм Linux (redhat el5 / fedora), якби я використовував X-Windows. Однак це віддалена серверна машина, і я завжди входжу через ssh.

Я хотів би, щоб ssh-ключі були налаштовані належним чином, тому мені не довелося вводити свій пароль кілька разів під час оновлення або фіксації svn. Я радий вводити свою парольну фразу один раз на сеанс, і я заважаю нашій команді мати шш-ключі без пароля.

На короткий блискучий момент, здавалося, що "eval` ssh-agent -s` "у моєму .bash_profile, поєднаному з командою вбити ssh-агент, коли я вийшов, спрацює. Однак ми широко використовуємо екран , щоб керувати тривалими інтерактивними програмами та середовищами розробки. Якщо ви запускаєте та зупиняєте ssh-агент, як я щойно описав, він загине, коли ви виходите з терміналу, і підсеанси екрану, які раніше посилалися на цей екземпляр ssh-агента, залишаються.

Отже ... як я можу бути користувачем консолі, який використовує екран, який використовує пароль зі своїми ssh-ключами, якому не потрібно постійно вводити парольну фразу?

Відповіді:


4

При наступному налаштуванні вам не знадобиться жодна обгортка для виклику screen. Більше того, він уникає використання /tmp(з ризиками безпеки).

  1. Переконайтесь, що у вас є каталог ~ / tmp:

    mkdir ~/tmp
    
  2. Додати до .screenrcнаступного рядка:

    setenv SSH_AUTH_SOCK "$HOME/tmp/ssh-agent-screen"
    
    • Це гарантує , що всередині screen, sshвиглядає для сокета завжди в тому ж місці, а не змінний шляху.
    • Ви повинні використовувати setenvбудь-яку оболонку, яку ви використовуєте, оскільки це екран, а не команда оболонки.
  3. Додати до .bash_profileнаступного рядка:

    [ -n "$SSH_AUTH_SOCK" ] && [ "$SSH_AUTH_SOCK"!="$HOME/tmp/ssh-agent-screen" ] && ln -sf "$SSH_AUTH_SOCK" "$HOME/tmp/ssh-agent-screen"
    
    • Це пов'язуватиметься з фіксованого місця (де sshвиглядає) до реального та має з’явитися після запуску ssh-agent.
    • Використання [ -n "$SSH_AUTH_SOCK" ]дозволить правильно запобігти помилкам, коли SSH_AUTH_SOCKне встановлено.
    • [ "$SSH_AUTH_SOCK"!="$HOME/tmp/ssh-agent-screen" ]не дозволить сеансам екрана пов'язувати $ HOME / tmp / ssh-agent-screen із самим собою, якщо джерела екрана .bash_profile.
  4. Замість того щоб почати ssh-agentв .bash_profile, ви можете розглянути можливість з'єднання з ssh -A(з використанням форвардного агента і зробити використання віддаленої машини вашого агента).

Після цього налаштування ви можете просто використовувати стандартну команду екрана. Вам потрібно буде лише відтворити наявні сеанси або вручну встановити SSH_AUTH_SOCK всередині них у фіксованому місці кроку 2.

Подяки на цей веб-сайт за ідею; Я уникав використання /tmp. Ця відповідь схожа, але використовується додаткові псевдоніми.


2

Чи можете ви запустити ssh-агент із initscript замість .bash_profile? Наприклад, я можу сказати

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

у відповідній частині /etc/conf.d/local, хоча RHEL / Fedora, ймовірно, використовує іншу систему. Як ви вказали у своєму коментарі, термінальні сеанси повинні мати можливість підключитися до агента, і саме тому ця команда створює файл .ssh_agent_envу домашній директорії користувача. Потім ви можете додати

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

в .bash_profile.

Ще одна річ, яку ви можете зробити, - це поставити наступне .bash_profile

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

яка почнеться ssh-agentлише в тому випадку, якщо вона вже не працює. Тоді не потрібно вбивати це.

Як трохи інша альтернатива другій пропозиції, замість того, щоб перевіряти наявність ssh-agentпроцесу, ви можете перевірити наявність файлу ~/.ssh_agent_env,

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

Якщо все працює належним чином, між двома способами не повинно бути суттєвої різниці.


Ідея initscript цікава - в основному, просто запустити її при запуску системи для всіх користувачів, які хочуть її? Це могло б спрацювати. У нас не так багато користувачів, які б піклувалися. Незалежно від того, чи це набагато краще, ніж взагалі не мати парольну фразу, адже я підозрюю, що це означає, що вам доведеться вводити її лише один раз під час перезавантаження машини. Хм. І те, і друге пропозиція покладаються на те, що нові термінальні сеанси зможуть підключитися до ssh-агента, якщо він вже працює. Я не зовсім впевнений, що це так просто, але я ще не намагався. Дякую за ідеї!
Майкл Х.

@khedron: Так, але вам доведеться ввести один рядок /etc/conf.d/local(або його еквівалент) для кожного користувача, який використовує агент, щоб запустити окремий ssh-agentпроцес на кожного користувача. Якщо, як ви кажете, у вас немає величезної кількості користувачів, це було б не дуже погано. Ви піднімаєте хорошу думку (яку я забув розглянути) щодо термінальних сеансів, пов’язаних із агентом; дивіться мою редакцію відповіді.
David Z


2

Кращий підхід - використовувати переадресацію ssh-агента ( -Aопція). Це дозволяє людині, яка використовує ssh, використовувати ключі від агента ssh, який працює на машині, з якої вони приїжджають, імовірно, на робочу станцію, на якій вони насправді сидять.


Це також дозволяє зловмиснику, який компрометує ваш обліковий запис, компрометувати облікові записи на інших машинах, до яких цей агент може отримати доступ. Тому я намагаюся мінімізувати перенаправлення ssh-агента до мінімуму.
Пол Ціна

2

щоб продовжити переадресацію агента ssh, ви побачите, що за замовчуванням переадресовані облікові дані ssh не будуть доступні для вашого екранного сеансу, коли ви вийдете з системи, увійдіть назад та повторно приєднайтеся до свого сеансу.

Ви можете це обійти, встановивши екран змінної середовища SSH_AUTH_SOCK на щось добре відоме, а оновлене розташування оновити до вашого поточного розширення.

Я використовую цю функцію оболонки для повторного входу в екран і виправлення ssh auth шкарпетки:

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
}

і я маю це у своєму .screenrc:

setenv SSH_AUTH_SOCK /tmp/screenssh/socket

Сподіваюсь, це допомагає.


Використання / tmp означає, що будь-хто інший на апараті може зупинити будь-які ваші файли, якщо він знає їх шлях.
Blaisorblade

1

Якщо я правильно зрозумів, ви просто хочете екранне сеанс, який ви від'єднуєте та повторно додаєте, але ніколи більше не хочете повторно вводити паролі для ssh-агента (пароль вашого приватного ключа).

Я думаю, що найпростіший спосіб - запустити екран, ніж запустити ssh-агент із допоміжною оболонкою, а потім залишитися в цій підкошті. Тобто

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

Це по суті те, що я роблю. Я використовую екран, щоб позначити одну з "вкладок" всередині як функцію ssh-агента, і використовую її для роботи з svn, і т. Д. Є додаткова зморшка, де я змушую ssh-агент повторно авторизуватися через кілька годин, але так, це в основному там, де я перебуваю.
Майкл Х.
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.