Как правильно управлять SSH-ключами в Linux

Принцип работы SSH-ключей

SSH-ключ представляет собой пару файлов: закрытый ключ, который остается на вашем устройстве, и открытый ключ, который вы копируете на каждый сервер, к которому хотите получить доступ. При подключении сервер использует открытый ключ для отправки запроса-вызова, на который может ответить только соответствующий закрытый ключ. Закрытый ключ никогда не покидает ваше устройство, поэтому никакие секретные данные не передаются по сети, а скомпрометированный сервер не содержит ничего, что можно было бы украсть. Именно поэтому ключи надежнее паролей. Эффективное управление SSH-ключами сводится к четырем правилам: один ключ на устройство, соблюдение прав доступа к файлам, требуемых sshd, использование файла ~/.ssh/config, чтобы не вводить параметры вручную, и знание процедуры удаления ключа в случае утери ноутбука.

В этом руководстве рассматривается каждое из этих правил для Ubuntu 24.04, хотя почти все описанное применимо к любому Linux-серверу и любой современной версии OpenSSH.

Перед началом уточним один термин, чтобы избежать серьезных ошибок. Открытый ключ не является секретным. Вы можете вставить его в тикет, отправить по электронной почте или опубликовать, и никто не сможет войти в систему с его помощью. Секретным является именно закрытый ключ. Любой, кто скопирует этот файл и узнает его парольную фразу (если она установлена), получит полный доступ к вашим серверам от вашего имени.

Создание ключа: ed25519 — оптимальный выбор по умолчанию

На локальном компьютере, а не на сервере, выполните:

ssh-keygen -t ed25519 -C "laptop"

Флаг -t ed25519 задает тип ключа. Ed25519 — современный стандарт: такие ключи короткие, быстрые и поддерживаются всеми версиями OpenSSH, начиная с 2014 года. Используйте ssh-keygen -t rsa -b 4096 только в том случае, если необходимо взаимодействовать с устаревшим оборудованием, которое не поддерживает ed25519. Флаг -C "laptop" добавляет комментарий. Он не влияет на криптографические свойства, но поможет вам опознать этот ключ в файле authorized_keys на сервере спустя годы, поэтому укажите в нем название устройства, на котором хранится ключ.

Команда ssh-keygen запрашивает путь для сохранения ключа. Оставьте значение по умолчанию — ~/.ssh/id_ed25519. Затем система предложит ввести парольную фразу. Установите её; в разделе о парольных фразах ниже объясняется, почему это не создает неудобств при ежедневном использовании. В результате вы получите два файла: ~/.ssh/id_ed25519 — закрытый ключ, и ~/.ssh/id_ed25519.pub — открытый ключ. Просмотрите содержимое открытого ключа:

cat ~/.ssh/id_ed25519.pub

ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop

Это одна строка: тип ключа, тело ключа и ваш комментарий. Именно эту строку нужно будет разместить на ваших серверах.

Один ключ на устройство, а не на сервер

Первый вопрос, который задают все: нужен ли новый ключ для каждого сервера? Нет. Создайте один ключ для каждого устройства, с которого вы работаете, и добавьте этот открытый ключ на все серверы, к которым устройство должно иметь доступ. Ключ идентифицирует устройство. Файл authorized_keys на каждом сервере — это список устройств, которым разрешён вход.

Эта модель масштабируется, а альтернативные подходы предсказуемо приводят к проблемам. Ключ для каждого сервера означает, что на ноутбуке с двадцатью серверами будет храниться двадцать закрытых ключей, и вы быстро запутаетесь, какой из них для чего. Использование одного ключа на всех устройствах ещё хуже: если ноутбук украдут, вы не сможете отозвать доступ для него, не заблокировав при этом стационарный компьютер, так как у них один и тот же закрытый ключ. В результате вам придётся менять ключ везде и заново распространять его на все устройства.

При использовании одного ключа на устройство потеря ноутбука обойдётся вам в одну строку на каждом сервере: удалите строку с ключом ноутбука из authorized_keys, и все остальные устройства продолжат работать. Комментарий, который вы добавляете с помощью -C, позволяет легко найти нужную строку.

Правило этой модели: закрытый ключ создаётся на устройстве и «умирает» вместе с ним. Никогда не копируйте закрытый ключ на другую машину и никогда не загружайте его на сервер. Когда новому устройству нужен доступ, сгенерируйте на нём новый ключ.

Размещение открытого ключа на сервере

Самый простой способ — использовать ssh-copy-id, который поставляется вместе с OpenSSH:

ssh-copy-id matt@10.0.0.10

Эта утилита выполняет вход с использованием доступного метода (обычно пароля), добавляет ваш открытый ключ в ~/.ssh/authorized_keys на сервере, а также создаёт каталог и файл с корректными правами доступа, если они отсутствуют. Проверьте результат, открыв новую SSH-сессию: сервер должен предоставить доступ без запроса пароля учётной записи. Если ваш ключ защищён парольной фразой, её может запросить ваша локальная машина; этот запрос является локальным и не относится к паролю сервера.

Если вход по паролю уже отключён, ssh-copy-id не сможет подключиться, поэтому добавьте строку вручную. Войдите через активную сессию или используйте веб-консоль вашего провайдера и выполните на сервере следующую команду:

mkdir -p ~/.ssh && chmod 700 ~/.ssh
echo "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIF3k2s0vQx7GdKQhX1yBz... laptop" >> ~/.ssh/authorized_keys
chmod 600 ~/.ssh/authorized_keys

Вставьте ваш реальный открытый ключ внутри кавычек — это должна быть полная строка из id_ed25519.pub. В authorized_keys на каждой строке размещается один открытый ключ; это и есть вся база данных доступа: добавление устройства выполняется добавлением строки, а отзыв доступа — её удалением. На новом сервере этот шаг следует выполнять в рамках первых 10 минут работы с новым VPS, непосредственно перед отключением входа по паролю.

Права доступа, нарушающие вход по ключу

Это самая частая причина сбоя входа по ключу, при этом на стороне клиента ошибка никак не отображается. По умолчанию sshd работает с StrictModes yes в Ubuntu 24.04, поэтому он отказывается использовать файл authorized_keys, если его могут редактировать другие пользователи. Если файл, каталог ~/.ssh или ваш домашний каталог доступны для записи кому-либо, кроме вас, sshd игнорирует ваш ключ и переходит к запросу пароля без пояснений на стороне клиента. (OpenSSH в Ubuntu допускает лишь один частный случай: файл, доступный для записи группой, в которую не входит никто, кроме вас. Не полагайтесь на это; придерживайтесь указанных ниже режимов.) Причина ошибки видна только в логе сервера:

sudo grep 'Authentication refused' /var/log/auth.log

В минимальных образах без rsyslog файл auth.log отсутствует; та же строка находится в журнале: sudo journalctl -u ssh | grep 'Authentication refused'.

Authentication refused: bad ownership or modes for file /home/matt/.ssh/authorized_keys

Для исправления необходимо изменить права доступа и проверить владельца, выполнив следующие команды на сервере от имени соответствующего пользователя:

chmod 700 ~/.ssh
chmod 600 ~/.ssh/authorized_keys
chown -R matt:matt ~/.ssh

Правило, которое нужно запомнить: 700 для каталога .ssh, 600 для всего, что находится внутри. Те же значения применяются и на вашем компьютере, так как клиент также выполняет проверку. Если закрытый ключ доступен для чтения другим пользователям, ssh сразу отклонит ключ, и в этот раз ошибка будет явной:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0644 for '/home/matt/.ssh/id_ed25519' are too open.

chmod 600 ~/.ssh/id_ed25519 исправляет эту проблему.

~/.ssh/config: избавьтесь от ввода опций

Файл ~/.ssh/config на вашем компьютере позволяет присвоить каждому серверу короткое имя и сохранить опции, которые вы постоянно вводите вручную. Создайте его с правами доступа 600 и добавьте блок Host для каждого сервера:

Host web1
    HostName 10.0.0.10
    User matt
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Host db1
    HostName 10.0.0.11
    User matt
    Port 2222
    IdentityFile ~/.ssh/id_ed25519
    IdentitiesOnly yes

Теперь ssh web1 заменяет ssh -p 22 matt@10.0.0.10, а короткое имя работает в scp, rsync и git, так как все они считывают этот файл. HostName — это реальный адрес, User избавляет от ввода имени пользователя, а IdentityFile указывает, какой именно ключ использовать.

IdentitiesOnly yes заслуживает отдельного упоминания, так как эта опция устраняет одну неочевидную проблему. Когда в вашем агенте хранится несколько ключей, клиент предлагает их серверу по очереди, и сервер засчитывает каждую попытку как неудачную. Если загружено достаточно много ключей, вы получите Received disconnect: Too many authentication failures до того, как будет предложен нужный ключ. IdentitiesOnly yes заставляет клиент предлагать только ключ, указанный в IdentityFile, поэтому ошибка не возникнет.

Парольные фразы и ssh-agent

Парольная фраза шифрует файл закрытого ключа на диске. Без неё любой, кто скопирует файл, сможет немедленно его использовать. С ней украденный файл бесполезен, пока парольная фраза не будет подобрана. Для ключа на ноутбуке это именно та защита, которая необходима, так как ноутбуки крадут, а их резервные копии могут попасть в чужие руки.

Причина, по которой парольная фраза практически не доставляет неудобств, заключается в ssh-agent. Агент хранит расшифрованный ключ в оперативной памяти, поэтому вы вводите парольную фразу один раз за сеанс входа, а все последующие подключения происходят мгновенно. Большинство дистрибутивов Linux для настольных ПК и macOS уже запускают агент автоматически. Добавьте в него свой ключ с помощью команды:

ssh-add ~/.ssh/id_ed25519

ssh-add -l выводит список ключей, которые в данный момент хранятся в агенте. Одно предостережение: перенаправление агента (ssh -A) позволяет удалённому серверу использовать ваш агент для дальнейшей аутентификации, пока вы подключены. Поэтому включайте эту функцию только для серверов, которым вы полностью доверяете, а по умолчанию оставляйте её выключенной.

Ротация и отзыв ключей: действия при потере ноутбука

Отзыв обычного SSH-ключа сводится к удалению соответствующей строки из файла authorized_keys на каждом сервере, где этот ключ был прописан. Здесь нет центра сертификации, который нужно уведомлять, и не нужно ждать истечения срока действия. Как только строка удалена, новые попытки входа с этим ключом завершаются ошибкой.

Проведите тренировку сейчас, пока ситуация не стала критической. Выберите сервер, откройте ~/.ssh/authorized_keys и найдите ключ по его комментарию. Удалите строку в текстовом редакторе или отфильтруйте её по комментарию:

grep -v ' laptop$' ~/.ssh/authorized_keys > ~/.ssh/authorized_keys.tmp
mv ~/.ssh/authorized_keys.tmp ~/.ssh/authorized_keys

Затем убедитесь с устройства, для которого вы только что отозвали доступ, что вход больше невозможен, а с другого устройства вход по-прежнему работает. Учтите одну деталь: удаление ключа не завершает уже открытые сессии, так как проверка ключа происходит только в момент входа. Если вы отзываете доступ для украденного устройства, также проверьте who на сервере и завершите все сессии, которые вы не узнаёте.

Ротация — это та же операция, но в другом порядке: создайте новый ключ на устройстве, установите его с помощью ssh-copy-id, убедитесь, что вход с новым ключом работает, а затем удалите старую строку. Выполняйте это при смене владельца устройства, при подозрении на компрометацию ключа или при уходе сотрудника из команды. Делать это вручную на двух серверах допустимо; для двадцати серверов это задача для автоматизации, и в управлении множеством серверов Linux показано, как распространять одинаковое состояние authorized_keys на весь парк машин.

Чего делать не следует

• Не используйте один и тот же закрытый ключ на всех своих устройствах. Это делает невозможным отзыв доступа для одного украденного устройства без замены ключа везде.

• Не добавляйте закрытый ключ в репозиторий git, даже в приватный. Автоматизированные сканеры отслеживают публичные репозитории и проверяют утекшие ключи через несколько минут после push, а репозиторий, ставший публичным позже, раскрывает всю свою историю.

• Не загружайте закрытый ключ со своего ноутбука на сервер для того, чтобы этот сервер мог подключиться к другому. Сгенерируйте отдельный ключ непосредственно на сервере и авторизуйте его только там, где это необходимо.

• Не вставляйте закрытый ключ в чаты, электронную почту или тикеты. Публичный ключ, файл .pub, — это единственная часть, которой можно делиться.

Как только ключ начнет стабильно обеспечивать вход, переходите к следующему шагу и отключите аутентификацию по паролю. Это полностью исключит возможность успешного подбора пароля к вашему серверу. Готовая конфигурация для этого приведена в укреплении безопасности SSH на VPS.

FAQ

Как работают SSH-ключи без передачи пароля?

Сервер хранит ваш открытый ключ в ~/.ssh/authorized_keys. При входе в систему сервер отправляет запрос (challenge), ваш клиент подписывает его закрытым ключом, а сервер проверяет подпись с помощью открытого ключа. Закрытый ключ никогда не покидает ваше устройство, поэтому его невозможно перехватить при передаче или украсть с сервера в виде, пригодном для повторного использования. В случае взлома сервера утекают только открытые ключи, которые нельзя использовать для входа куда-либо.

Стоит ли использовать один и тот же SSH-ключ для всех серверов?

Использование одного ключа на множестве серверов — это правильный подход, при условии, что ключ хранится только на одном устройстве. Правило звучит так: один ключ на одно устройство, а не один ключ на один сервер. Открытый ключ вашего ноутбука размещается на всех серверах, к которым нужен доступ с ноутбука, а у стационарного компьютера должен быть свой собственный ключ. Это упрощает отзыв доступа: при потере устройства достаточно удалить одну идентифицируемую строку с каждого сервера, при этом остальные устройства продолжат работать.

Какие права доступа должны быть у каталога .ssh и файла authorized_keys?

Установите 700 для ~/.ssh и 600 для authorized_keys, а также для любого закрытого ключа; владельцем должна быть учетная запись, которая их использует. По умолчанию sshd работает с StrictModes yes, поэтому если файл или домашний каталог доступны для записи кому-либо, кроме вас, сервер будет молча игнорировать ваш ключ. Единственным следом этого действия будет запись Authentication refused: bad ownership or modes в журнале аутентификации или системном журнале сервера.

Как удалить SSH-ключ с сервера?

Удалите строку с ключом из файла ~/.ssh/authorized_keys в той учетной записи, для которой он был авторизован. Найдите нужную строку по комментарию — метке, которая идет после данных ключа. Новые попытки входа с этим ключом будут сразу отклоняться, однако уже открытые сессии останутся активными. Если устройство было украдено, принудительно завершите все текущие сессии для этого ключа. Повторите процедуру на каждом сервере, куда был скопирован ключ.

Нужна ли кодовая фраза (passphrase) для SSH-ключа?

Для ключа на ноутбуке или стационарном компьютере — да. Кодовая фраза шифрует файл ключа, поэтому украденная или утекшая копия сама по себе будет бесполезна. Использование ssh-agent позволяет вводить её один раз за сессию, а не при каждом подключении. Ключи, используемые автоматизированными процессами на сервере, обычно не имеют кодовой фразы, так как при запуске нет человека, который мог бы её ввести. В таких случаях защищайте ключи, ограничивая права доступа учетной записи, на которой они используются.