Я получил Ubuntu 16.06 Rootserver и у меня есть еще несколько человек, которым может потребоваться войти в систему как специальный пользователь.
Я не хочу отправлять пароли или даже личные ключи.
Можно ли генерировать ключи, срок действия которых истекает через +3 дня после генерации, не затрагивая ничего на сервере?
Т.е. с корневым сертификатом, который знает Сервер, и я попал в безопасное место, которое я могу использовать для генерации этих Ключей с датой истечения срока действия?
или даже частные ключи.
Почему бы вам когда - нибудь отправить личные ключи? Попросите пользователя создать свою собственную пару ключей и попросить его отправить вам открытый ключ.
Можно ли генерировать ключи, срок действия которых истекает через +3 дня после генерации,
Предполагая, что сервер использует OpenSSH, есть два способа:
Сертификаты: поддерживается OpenSSH 5.4 или более поздней версии, но все пользователи также должны использовать OpenSSH - сгенерированные сертификаты не работают с PuTTY или другими клиентами.
Сначала с помощью ssh-keygen сгенерируйте "SSH" ключ "полномочий" и укажите его в конфигурации сервера (используя опцию TrustedUserCAKeys ), а затем используйте его для выдачи пользовательских сертификатов.
Чтобы выдать сертификат: Когда пользователь отправляет вам свой файл id_rsa.pub , подпишите его с помощью ключа CA. После подписания отправьте новый id_rsa.pub-cert обратно пользователю.
ssh-keygen -s ~/private/user_ca -I user_fred -n fred -V +3d fred_id_rsa.pub
Здесь -n указывает, кто может войти в систему с использованием сертификата, а -V устанавливает время его истечения. (Опция -I просто устанавливает произвольное имя для самого сертификата.)
authorized_keys: поддерживается OpenSSH 7.7 или более поздней версии, без каких-либо требований клиента. Информация об истечении срока хранения хранится не в самом ключе, а в файле author_keys сервера:
expiry-time="20180704" ssh-ed25519 AAAAC3NzaC1lZDI1NTE...
На странице руководства sshd (8) допустимыми форматами времени являются YYYYMMDD и YYYYMMDDHHMM[SS] в основном часовом поясе сервера.
Обратите внимание, что этот метод безопасен только в том случае, если пользователь не может редактировать свой файл author_keys, иначе он может просто продлить срок действия!