Как использовать PEM‑файл для SSH и macOS Keychain

Быстрые ссылки

• Как использовать PEM‑файл
• Хранение SSH‑ключей в macOS Keychain
• Замена id_rsa на новый ключ

Как использовать PEM‑файл

Когда вы создаёте новый EC2‑инстанс, AWS выдаёт PEM‑файл — это ваш приватный ключ для доступа по SSH. Чтобы подключиться, можно передать файл явно флагом -i:

ssh -i keyfile.pem user@host

Это неудобно вводить каждый раз. Ниже — несколько подходов, чтобы упростить работу.

Добавление вашего публичного ключа на сервер

Если вы предпочитаете управлять собственными ключами, скопируйте содержимое вашего публичного ключа (~/.ssh/id_rsa.pub) в ~/.ssh/authorized_keys на сервере. Тогда PEM‑файл можно проигнорировать для будущих подключений.

• Плюсы: вы полностью контролируете ключи, меньше зависимостей от PEM.
• Минусы: нужно повторять при каждом создании нового инстанса, если вы не автоматизируете это.

Использование ssh‑agent

Команда ssh-add добавляет PEM‑файл в SSH‑агент до выхода из сессии:

ssh-add ~/keyfile.pem

Минус: после перезагрузки агент пуст, придётся запускать опять. Решение — автоматически добавлять ключ при старте терминала, например в ~/.bashrc или ~/.bash_profile:

ssh-add ~/keyfile.pem >/dev/null 2>&1

Перенаправление в /dev/null подавляет сообщение “Identity added” при каждом открытии терминала.

Хранение SSH‑ключей в macOS Keychain

Если вы используете macOS, удобно хранить PEM‑файлы в системном брелоке (Keychain). Откройте или создайте ~/.ssh/config и добавьте опцию для хоста или глобально:

Host *
  UseKeychain yes
  AddKeysToAgent yes

После этого можно поместить ключ в Keychain командой:

ssh-add -K ~/keyfile.pem

Ключи будут храниться в Keychain и автоматически загружаться при входе в систему, как ~/.ssh/id_rsa.

Советы для macOS:

• Для новых macOS может потребоваться -K или --apple-use-keychain зависимо от версии OpenSSH; проверьте ssh-add --help и man ssh_config.
• Если ключ не загружается автоматически, проверьте разрешения на ~/.ssh и файлы ключей: chmod 700 ~/.ssh && chmod 600 ~/.ssh/*.

Замена id_rsa на новый ключ

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

Важно: перед заменой обязательно сделать резервную копию текущих ключей. Даже если вы уверены, что текущий ключ не используется, сделайте бэкап:

mv ~/.ssh/id_rsa ~/.ssh/id_rsa_old
mv ~/.ssh/id_rsa.pub ~/.ssh/id_rsa_old.pub

Чтобы конвертировать AWS PEM в PKCS#8 и получить приватный ключ в формате OpenSSH:

openssl pkey < keyfile.pem > keyfile.pkcs8

Сгенерировать соответствующий публичный ключ:

openssl rsa -in keyfile.pkcs8 -pubout > keyfile.pub

Затем замените локальные файлы (после резервного копирования):

mv keyfile.pkcs8 ~/.ssh/id_rsa
mv keyfile.pub ~/.ssh/id_rsa.pub
chmod 600 ~/.ssh/id_rsa
chmod 644 ~/.ssh/id_rsa.pub

Проверьте доступ к серверам и сервисам (GitHub, GitLab и т.д.) — если старый ключ использовался где‑то ещё, вы можете потерять доступ.

Когда не стоит заменять id_rsa

• Если ваш текущий ключ используется для доступа к другим серверам или сервисам (Git, CI): не заменяйте без тщательной проверки.
• Если команда состоит из нескольких людей и у каждого свой ключ — лучше добавить публичный ключ PEM в authorized_keys, а не менять общий id_rsa.

Рекомендации по безопасности

• Никогда не передавайте приватный PEM‑файл по открытым каналам (электронная почта, мессенджеры). Используйте защищённые хранилища.
• Дайте минимально необходимые права на файлы: chmod 600 для приватных ключей.
• Для совместной работы лучше создавать отдельные ключи для каждого пользователя и помещать публичные ключи в authorized_keys.
• Ограничьте доступ в sshd_config, например AllowUsers или Match Address для повышения безопасности.

Важно: если приватный ключ скомпрометирован, отзывайте его на стороне сервисов и создавайте новый ключ.

Мини‑методика для безопасного подключения и управления PEM

1. Скачайте PEM при создании инстанса — сохраните в защищённой директории, права 600.
2. Решите стратегию: краткосрочно — ssh -i или ssh-add; долгосрочно — добавить публичный ключ в authorized_keys или хранить в Keychain.
3. Если используете macOS — настройте ~/.ssh/config и добавьте ключ в Keychain.
4. Всегда делайте резервные копии существующих ключей перед заменой.
5. Протестируйте доступ после изменений, до выключения старого доступа.

Чек‑лист по ролям

• Разработчик:
  • Убедиться, что локальные ключи не будут потеряны при замене.
  • Проверить доступ к репозиториям после изменений.
• Системный администратор:
  • Настроить authorized_keys или Keychain для администраторов.
  • Прописать правила в sshd_config и аудит логов.
• Менеджер безопасности:
  • Убедиться, что приватные ключи хранятся безопасно и доступны по необходимости для инвентаризации.

Критерии приёмки

• Вы можете успешно подключиться к EC2 через SSH без флага -i (если выбран подход автозагрузки).
• Приватные ключи имеют права 600 и не доступны другим пользователям.
• Резервные копии старых ключей сохранены и проверены.
• Для командной работы каждый пользователь имеет отдельный ключ в authorized_keys.

Примеры альтернативных подходов

• Автоматизированное развертывание: при создании инстанса через cloud‑init или Terraform автоматически добавляйте публичные ключи нужных пользователей в authorized_keys.
• Vault‑ориентированная модель: хранение приватных ключей в секретном хранилище (HashiCorp Vault, AWS Secrets Manager) с динамическими или короткоживущими учетными данными.

Краткое резюме

PEM‑файлы удобны для первичного доступа к EC2 и могут храниться в SSH‑агенте или macOS Keychain для удобства. Для долгосрочной безопасности лучше использовать отдельные пользовательские ключи и добавлять их в authorized_keys, либо хранить ключи в централизованном менеджере секретов. Перед заменой id_rsa обязательно создайте резервную копию и проверьте зависимости.

Важно: соблюдайте базовые правила безопасности при работе с приватными ключами и документируйте изменения для команды.