Існує кілька коротких дискусій про існуючу ssh-agent -tфункцію в [1], і там була публікація ще в 2001 році про debian-devel [2], що бажає функцію очікування бездіяльності. Тут є аналогічна дискусія в SE [3] щодо конкурсу.
Мені потрібно задуматися, як решта планети захищає ssh-ключі - я пропускаю щось очевидне, щоб це було такою больовою точкою для мене, і, мабуть, ніхто інший? Зокрема, я думаю про сценарії ssh-взаємодії, наприклад, з ansible. Схоже, сьогодні ваш вибір:
- Встановіть термін служби вашого ключа в агенті на тривожний тривалий період часу, наприклад. 1 год або будь-який максимальний час роботи ваших сценаріїв може статися (я сумніваюся, багато людей дозволяють їх повторному авторизованому прослуховуванню судо так довго розтягнутись!) - але
seahorse/gnome-keyring-daemonледве навіть це дуже підтримують [4] - Няньте свої давні сценарії та продовжуйте повторно вводити свою парольну фразу кожні 5/10/15 хвилин: тепер ви можете легко спостерігати, як вводити свою парольну фразу 20 разів на день
- Зламіть власне рішення для домашнього приготування, щоб імітувати цю відсутність функції, можливо, у поєднанні з
TMOUTваром оболонки вашої оболонки (дякую людям на freenode #openssh IRC за цю пропозицію) - У вас взагалі не встановлено термін служби ключа, тобто ваш агент зберігає ваш ключ завантажений назавжди або до того моменту, коли ви не вб'єте / перезавантажите
Якщо ви використовуєте короткі тайм-аути агента ssh, чіткі паролі та різні ключові файли для кожного типу ролей, які ви автентифікуєте як: це призводить до дуже неприємного дня!
Я експериментував з gpgkey2ssh та смарт-картами, але це насправді не вирішує цю конкретну проблему: я все-таки хочу функціонувати ssh-агент, і мені не хочеться повторно авторизуватися кожні 5 хвилин, щоб запобігти відкриттю моїх приватних ключів в пам'яті, поки мій комп'ютер не працює.
Чи я це роблю неправильно?
[1] Налаштування тайм-ауту для агента SSH за замовчуванням
[2] https://lists.debian.org/debian-devel/2001/09/msg00851.html
[3] /server/518312/putty-pageant-forget-keys-after-period-of-inactivity
[4] https://bugs.launchpad.net/ubuntu/+source/gnome-keyring/+bug/129231
ssh-agentзнати, коли сеанс неактивний, але принаймні запускати час очікування з моменту, коли відбулася остання операція підписання, а не з кожного разу, коли ssh-agentбуло запущено. Крім того, я вже використовую окремі облікові записи та файли ключів для кожної ролі сценарію, sudoers дозволяє лише 1 чи 2 команди, якщо потрібно, sudo'd, і я роздивився, lshellщоб далі зафіксувати речі. Але все, що все ще не звільняє мене від необхідності захищати свої файли ключів: тільки тому sudo zfs send, що для даного ключа дозволена єдина команда, це досить потужна команда для того, хто має цей ключ!
ControlMaster/ ControlPath/ ControlPersist(див. man ssh_config) Для свого сценарію. Принаймні, якщо його підключення лише до одного хоста.
ssh-agentтримати ключі, завантажені до перезавантаження (що може бути тижнями).
ssh-agentє агресивним для типу сеансу, до якого він входить (наприклад, сеанс tty, сесія X11 або щось інше). Я хотів би сказати одне, якщо, можливо, ваші автоматизовані сценарії не повинні залежати від ключа, завантаженого у вашому агенті. Мабуть, кожен з них повинен мати свій приватний ключ, який має право через примусові команди на відповідних серверах виконувати лише певні віддалені команди, які потрібно виконувати кожному сценарію. Це, звичайно, дозволить вам запустити їх із крону тощо ...