Управління ключами в openssh, частина 2

Переклад статті Деніела Робінса (Daniel Robbins) OpenSSH key management, Part 2

Багато розробники використовують чудову програму OpenSSH як захищеної шифрованого заміни архаїчних команд telnet і rsh. Однією з найбільш захоплюючих особливостей OpenSSH є її здатність аутентифицировать користувачів за допомогою протоколів аутентифікації RSA і DSA, в основі яких лежить пара комплементарних числових «ключів». Однією з найпривабливіших сторін RSA- і DSA-аутентифікації є їх потенційна здатність встановлювати з'єднання з віддаленими системами без вказівки пароля. У цій другій статті Деніел представляє вашій увазі ssh-agent (кеш особистого ключа) і keychain - спеціальний скрипт bash, розроблений для того, щоб зробити засновану на ключах аутентифікацію виключно зручною і маневреної.

Знайомство з ssh-agent.

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

У ssh включені вбудовані засоби підтримки, що дозволяють йому спілкуватися з ssh-agent 'ом, а ssh-agent' у - отримувати ваші дешифровані особисті ключі не пропонуючи вас вводити пароль при встановленні кожного нового з'єднання. При роботі з ssh-agent 'ом ви просто використовуєте ssh-add. щоб додати ваш особистий ключ в кеш ssh-agent 'а. Це робиться один раз; після використання ssh-add. ssh буде витягувати ваш особистий ключ з ssh-agent 'а, замість того щоб видавати вам запрошення ввести ключову фразу.

Використання ssh-agent.

Давайте розглянемо, як працює вся система кешування ssh-agent 'а. Коли запускається ssh-agent. то перед тим як відокремитися від shell і продовжити фонову роботу, він видає на гора кілька важливих змінних середовища. Ось приклад того, що може вивести ssh-agent при запуску:

Як ви бачите, що виводиться ssh-agent 'ом інформація насправді є серією команд bash; якщо ці команди будуть виконані, то вони встановлять дві змінні середовища: SSH_AUTH_SOCK і SSH_AGENT_PID. Завдяки включеним в перелік командам експорту доступ до цих змінним середовища можуть отримати будь-які додаткові команди, запущені пізніше. Загалом, все буде відбуватися саме так в тому випадку, якщо shell дійсно вирахує дані в рядках, але в даному випадку вони просто виведені в stdout. Щоб виправити ситуацію ми можемо викликати ssh-agent нижченаведеними способом:

Ця команда вказує bash запустити ssh-agent і обчислити виведені ним дані. Викликані таким чином (з back-quotes, а не звичайними єдиними квотами) змінні SSH_AGENT_PID і SSH_AUTH_SOCK будуть встановлені і експортовані вашої shell, що зробить ці змінні доступними для будь-яких нових процесів, які ви, можливо, запустіть в процесі роботи.

Кращий спосіб запустити ssh-agent - додати рядок в самий верх вашого файлу

/.bash_profile. В цьому випадку всі програми, що запускаються в вашому login shell, будуть бачити змінні середовища, зможуть визначити місцезнаходження ssh-agent 'а й, якщо знадобиться, запросити у нього ключі. Винятково важливою змінною середовища є SSH_AUTH_SOCK. SSH_AUTH_SOCK містить маршрут до UNIX domain socket, який ssh ​​і scp можуть використовувати для встановлення діалогу з ssh-agent 'ом.

Використання ssh-add.

Але, звичайно ж, при запуску ssh-agent 'а його кеш не містить дешифрованих особистих ключів. Перш, ніж ми зможемо реально використовувати ssh-agent. нам необхідно додати наш особистий ключ (і) в кеш ssh-agent 'а за допомогою команди ssh-add. У наведеному нижче прикладі я використовую команду ssh-add щоб додати мій особистий RSA-ключ

/.ssh/identity в кеш ssh-agent.

Як ви бачите, ssh-add запросила у мене ключову фразу для того щоб розшифрувати особистий ключ, який після цього буде готовий до використання і буде зберігатися в кеші ssh-agent. Тепер, коли ви використовували команду ssh-add щоб додати ваш особистий ключ (або ключі) в кеш ssh-agent. а у вашій поточної shell визначена змінна SSH_AUTH_SOCK (а вона повинна бути визначена, якщо ви запускали ssh-agent з

/.bash_profile), ви можете використовувати scp і ssh для встановлення з'єднань з віддаленими системами без вказівки вашої ключової фрази.

Обмеження ssh-agent.

ssh-agent - дійсно класна штука, але його налаштування за замовчуванням як і раніше мають деякі невеликі незручності. Давайте їх розглянемо.

В одному випадку, пов'язаному з eval `ssh-agent` в

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

Інша проблема, пов'язана з настройками ssh-agent за замовчуванням, полягає в тому, що він не сумісний з cron jobs. Після того як cron jobs запускаються процесом cron, вони не успадковують з-поміж себе змінну SSH_AUTH_SOCK, і тому не знають ні того, що процес ssh-agent запущений, ні як з ним зв'язатися. Як виявилося, ця проблема теж вирішувана.

Введення keychain.

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

Ось короткий огляд принципів роботи keychain. Коли він запускається з файлу

/.bash_profile, він перш за все перевірить, запустився чи ні ssh-agent. Якщо немає, то він запустить ssh-agent і запише важливі змінні SSH_AUTH_SOCK і SSH_AGENT_PID в файл

/.ssh-agent для збереження і подальшого використання. Тут наведено кращий спосіб запуску keychain; як при використанні доброго старого ssh-agent виконаємо необхідні настройки в

Як ви могли помітити, для keychain ми використовуємо в якості вихідного файл source the

/.ssh-agent, замість того щоб обчислювати виведені дані, як при безпосередньому використанні ssh-agent. Хоча результат такий же: надзвичайно важлива змінна SSH_AUTH_SOCK визначена, ssh-agent запущений і готовий до роботи. А оскільки SSH_AUTH_SOCK записана в файл

/.ssh-agent, то скрипти нашого власного shell і cron jobs можуть без праці зв'язатися з ssh-agent просто використовуючи інформацію з файлу

/.ssh-agent. Сам keychain також використовує переваги цього файлу. Згадайте, що при запуску keychain перевіряє, чи запущений ssh-agent. Якщо запущено, то тоді keychain скористається файлом

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

/.ssh-agent є застарілим (посилається на вже не існуючий ssh-agent) або якщо сам цей файл не існує.

Установка keychain.

Встановити keychain просто. Спочатку рушайте на keychain project page і скачайте з архіву найсвіжішу версію keychain. Потім встановіть його про таке чином:

Тепер коли keychain знаходиться у вашій директорії / usr / bin /, додайте його в ваш файл

/.bash_profile, вказуючи в якості аргументів шлях до вашим особистим ключам. Ось непоганий зразок

/.bash_profile до чинного keychain (keychain-enabled

/.bash_profile до чинного keychain

Keychain в дії.

Тепер ви налаштували

/.bash_profile викликати keychain при кожному вході в систему, вихід з неї і повернення. Коли це буде відбуватися, keychain буде запускати ssh-agent і записувати установчі характеристики змінної середовища agent 'а в файл

/.ssh-agent, а потім запросить вас ввести ключові фрази для кожного особистого ключа, зазначеного в командному рядку keychain в файлі

Keychain запускається в перший раз.

Після того як ви введете ваші ключові фрази, ваші особисті ключі будуть кешованими і keychain сам згорнеться. Потім буде задіяний

/.ssh-agent, який ініціалізує вашу сесію з ssh-agent. Тепер, якщо ви вийдете з системи і ввійдете знову, то побачите, що keychain виявить вже діючий процес ssh-agent (він не завершується при вашому виході з системи). На додаток до всього keychain підтвердить наявність в кеш ssh-agent 'а вже зазначених вами особистих ключів. В іншому випадку ви отримаєте запрошення вести відповідні ключові фрази, хоча якщо все буде в порядку, то чинний ssh-agent повинен як і раніше містити додані раніше особисті ключі (це означає, що вас не попросять ввести пароль):

Keychain виявляє діючий ssh-agent

Мої вітання: ви тільки що увійшли в систему і тепер зможете використовувати ssh і scp для віддалених систем. Вам не доведеться відразу ж після входу застосовувати ssh-add і ні ssh ні scp не попросить вас ввести ключову фразу. Фактично, поки працює ваш вихідний процес ssh-agent 'а, ви зможете входити в систему і встановлювати з'єднання ssh без введення пароля. І цілком ймовірно, що процес ssh-agent 'а буде продовжувати працювати до перезавантаження машини. З огляду на той факт, що ви найімовірніше встановили ці програми в системі Linux, то, можливо, пароль вам не знадобиться протягом декількох місяців! Ласкаво просимо в світ захищених беспарольному з'єднання за допомогою RSA- і DSA-аутентифікацію.

Продовжуйте в тому ж дусі і створіть кілька нових сесій і ви помітите, що keychain кожен раз буде робити «прив'язку» до одного й того ж процесу ssh-agent. Не забудьте, що ви можете так само «прив'язати» до вже запущеного процесу ssh-agent свої скрипти і cron jobs. Щоб користуватися командами ssh і scp з скриптів shell і cron jobs, для початку просто переконайтеся, що вони використовують в якості джерела інформації в першу чергу ваш файл

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

Опції keychain.

Після того як ви налаштували і запустили keychain потрудіться викликати keychain --help щоб ознайомитися з усіма опціями командного рядка keychain. Ми зараз розглянемо одну особливу: опцію --clear.

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

Опція --clear дає вам можливість вказати для keychain. що вона повинна розглядати кожне нове підключення до вашого профілю як потенційну діру в захисті, до тих пір поки протилежне не буде доведено. При запуску keychain з опцією -clear. то як тільки ви входите в систему, перш ніж приступити до виконання своїх звичайних обов'язків, keychain негайно скидає всі ваші особисті ключі з кешу ssh-agent. Таким чином, якщо ви зломщик, то keychain попросить вас ввести ключові фрази, перш ніж надати доступ до ваших тих установок Кешована ключів. Хоча це і дозволяє підвищити ступінь захисту, але робить роботу трохи більше незручною і дуже схожою на роботу безпосередньо ssh-agent 'ом без keychain. І в цьому випадку, як це найчастіше буває, хтось може зробити вибір на користь більшої безпеки, а хтось на користь зручності, але ніяк не разом.

Схожі статті