яка мета ssh-агента?


70

Я прочитав офіційне визначення:

ssh-agent - це програма для зберігання приватних ключів, що використовуються для аутентифікації відкритих ключів (RSA, DSA, ECDSA). Ідея полягає в тому, що ssh-агент запускається на початку X-сесії або сеансу входу, а всі інші вікна або програми запускаються як клієнти програми ssh-agent. Завдяки використанню змінних середовища агент може бути знайдений і автоматично використаний для аутентифікації під час входу в інші машини за допомогою ssh (1).

"..програма для утримання приватних ключів .." - IMHO - ключі ssh генеруються користувачем з командою ssh-keygen і просто & прямо зберігаються в ~ / .ssh - навіщо мені потрібен демон, щоб утримувати ці ключі? Як саме він утримує їх у будь-якому випадку - чи не просто вони зберігаються в .ssh?

"запускаються як клієнти програми ssh-agent" - я не розумію. Де б це було потрібно? Зазвичай я просто використовую ssh як таке:

 ssh -i ~/.ssh/private_key_name username@hostname

Що саме означає посібник під "клієнтами" - які клієнти? Ви не просто запускаєте команду ssh з терміналу для підключення - які ще клієнти є, і чому вони не можуть просто використовувати шлях до приватного файлу ssh, як команда ssh?

Відповіді:


75

Агент SSH обробляє підписання даних аутентифікації для вас. Під час автентифікації на сервері ви повинні підписати деякі дані за допомогою свого приватного ключа, щоб довести, що ви, ну, ви.

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

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

Ще одна перевага агента SSH полягає в тому, що він може пересилатися через SSH. Отже, коли ви ssh для хосту A, пересилаючи свого агента, ви можете передати ssh з A на інший хост B, не потребуючи присутнім ключ (навіть у зашифрованому вигляді) на хості A.


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

3
@Patrick, що також може бути його недоліком - спробуйте занадто багато недійсних ключів на сервері, і він закриє з'єднання, перш ніж ви дійшли до дійсного ключа. Звичайно, це те, що ~/.ssh/config«s IdentityFileваріант хороший для, з або без агента
Tobias Kienzler

@ Патрік, що здається однаково можливим без агента
Андрій Федоров

@AndreyFedorov Так, ви можете мати кілька ключів без агента, але ви також можете вказати в своєму ~/.ssh/configключі, який використовувати для віддаленого хоста, щоб він точно знав, який саме вам потрібен.
Патрік

3
тож можна припустити, що ssh-agentце не потрібно, якщо приватний ключ не захищений парольною фразою?
пкарамол

16

Перевага ssh-agentполягає в тому, що вам потрібно ввести свою парольну фразу лише один раз. Якщо ваш приватний ключ RSA не зашифрований парольною фразою, ssh-агент не потрібен. sshКоманда буде прикладом клієнта.


7

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

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

1 Ви можете встановити lifeчас утримування ключів в агенті.


6

Стаття у Вікіпедії, мабуть, має найкращий опис:

Перевірка на сервері заснована на автентифікації виклику-відповіді. ssh підключається до сервера з ім'ям користувача та запитом ключа. Демон ssh отримує запит і повертає виклик на основі відкритого ключа, що зберігається у файлі аутентифікації. ssh використовує приватний ключ для побудови відповіді ключа та надсилає його на очікуючий sshd на іншому кінці з'єднання. Він не надсилає приватний ключ сам. Демон ssh перевіряє ключову відповідь, і якщо вона дійсна, надає доступ до системи. ssh-agent спрощує це, створивши сокет, який прослуховує з'єднання SSH. Користувач просто запускає ssh-агент, повідомляючи йому, як знайти їхні ключі (якщо вони не знаходяться за замовчуванням), одноразово вводить парольну фразу для кожного ключа, який буде використовуватися,

Знову дословно із статті wikipedia:

... ssh-agent створює сокет, а потім перевіряє з'єднання з ssh. Кожен, хто може підключитися до цього сокету, також має доступ до ssh-агента. Дозволи встановлюються як у звичайній системі Linux або Unix. Коли агент запускається, він створює новий каталог в / tmp з обмежуючими правами. Розетка знаходиться в папці.

Зазвичай він розміщується в системних або користувальницьких файлах rc, таких як $HOME/.bashrcабо $HOME/.profile(для оболонок bash), щоб встановлені змінні ssh-agentсередовища повністю включалися у ваше середовище.

У моїй системі Fedora 14 вона запускається досить рано як частина підсистеми X11. У цьому файлі /etc/X11/xinit/xinitrc-common:

# Prefix launch of session with ssh-agent if available and not already running.
SSH_AGENT=
if [ -z "$SSH_AGENT_PID" ] && [ -x /usr/bin/ssh-agent ]; then
    if [ "x$TMPDIR" != "x" ]; then
        SSH_AGENT="/usr/bin/ssh-agent /bin/env TMPDIR=$TMPDIR"
    else
        SSH_AGENT="/usr/bin/ssh-agent"
  fi
fi

Потім змінна $SSH_AGENTвикористовується в інших сценаріях запуску X11, таких як тут /etc/X11/xinit/Xclients:

exec -l $SHELL -c "$SSH_AGENT $XCLIENTS_D/Xclients.$1.sh"

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

SSH_AUTH_SOCK=/tmp/ssh-PspRF18958/agent.18958; export SSH_AUTH_SOCK;
SSH_AGENT_PID=18959; export SSH_AGENT_PID;

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

Наприклад, у GNOME, ssh-agentце фактично запуск для кожного користувача як програма для запуску:

                     ss програми запуску

TL; DR

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


1

"запускаються як клієнти програми ssh-agent" відноситься до ідеї, що ssh-агент запускається під час (локальної) сеансу ініціалізації сеансу входу, щоб усі програми отримували змінні середовища $SSH_AGENT_PIDта $SSH_AUTH_SOCKнеобхідні для підключення агента.

Ще одна перевага усунення керування приватним ключем з ssh полягає в тому, що ssh-агент може бути замінений gpg-агентом. Таким чином, ви можете використовувати ключі OpenPGP (з можливістю аутентифікації) для SSH. Це приємне рішення для ключів OpenPGP на смарт-картці.

Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.