Как ключи попадают в папку .ssh

Механизм попадания ключей в ~/.ssh

Папка ~/.ssh (полный путь /home/ваш_пользователь/.ssh) — это стандартное расположение для SSH-ключей и конфигурационных файлов в Unix-подобных системах. Ключи попадают туда несколькими основными способами, каждый из которых имеет свои особенности использования в DevOps-практике.

1. Генерация ключей с помощью ssh-keygen

Самый частый способ — локальная генерация пары ключей (приватного и публичного) утилитой ssh-keygen. Приватный ключ (id_rsa) остается в ~/.ssh, публичный (id_rsa.pub) передается на удаленные серверы.

# Базовая генерация RSA-ключа (4096 бит)
ssh-keygen -t rsa -b 4096 -C "your_email@example.com"

# Генерация Ed25519 (современный, рекомендуется)
ssh-keygen -t ed25519 -C "devops@company.com"

# Генерация с указанием нестандартного имени файла
ssh-keygen -f ~/.ssh/github_key -t ed25519

После выполнения команды:

• Приватный ключ сохраняется в ~/.ssh/id_rsa (или указанном файле)
• Публичный ключ — в ~/.ssh/id_rsa.pub
• Важно: Права доступа к ~/.ssh должны быть 700, к приватному ключу — 600

2. Копирование существующих ключей

В DevOps-сценариях часто используются предварительно сгенерированные ключи (например, для сервисных аккаунтов, CI/CD):

# Ручное копирование ключей в папку .ssh
cp /mnt/secure/backend_key ~/.ssh/
cp /mnt/secure/backend_key.pub ~/.ssh/

# Установка корректных прав
chmod 600 ~/.ssh/backend_key
chmod 644 ~/.ssh/backend_key.pub

3. Использование SSH-агента и ssh-add

SSH-агент управляет ключами в памяти, но ключи должны быть сначала добавлены:

# Запуск агента (если не запущен)
eval "$(ssh-agent -s)"

# Добавление ключа в агент
ssh-add ~/.ssh/special_deploy_key

# Просмотр добавленных ключей
ssh-add -L

4. Автоматическая настройка через инструменты управления

В инфраструктуре как код (IaC) используются инструменты для автоматического развертывания ключей:

• Ansible:

- name: Deploy SSH key
  ansible.builtin.copy:
    src: files/production_key
    dest: "{{ ansible_user_dir }}/.ssh/id_ed25519"
    mode: '0600'

• Terraform с cloud-init:

resource "aws_instance" "server" {
  user_data = <<-EOF
    #!/bin/bash
    mkdir -p /home/ubuntu/.ssh
    echo "${var.ssh_public_key}" > /home/ubuntu/.ssh/authorized_keys
    chmod 700 /home/ubuntu/.ssh
    chmod 600 /home/ubuntu/.ssh/authorized_keys
  EOF
}

5. Копирование публичных ключей на серверы

Для аутентификации публичный ключ должен попасть в ~/.ssh/authorized_keys на целевом сервере:

# Стандартный способ через ssh-copy-id
ssh-copy-id -i ~/.ssh/id_ed25519.pub user@remote-server

# Ручное добавление
cat ~/.ssh/id_ed25519.pub | ssh user@server "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"

6. Конфигурация в ~/.ssh/config

Для управления множеством ключей создается конфигурационный файл:

# ~/.ssh/config
Host github.com
    HostName github.com
    User git
    IdentityFile ~/.ssh/github_key
    IdentitiesOnly yes

Host production-server
    HostName 192.168.1.100
    User deploy
    IdentityFile ~/.ssh/deploy_key
    Port 2222

7. Безопасность и best practices

• Никогда не храните приватные ключи в репозиториях — используйте секреты в HashiCorp Vault, AWS Secrets Manager, или переменные окружения CI/CD
• Используйте passphrase для дополнительной защиты
• Регулярно ротируйте ключи (особенно в production)
• Для сервисных аккаунтов создавайте отдельные ключи с ограниченными правами

Типичный DevOps пайплайн работы с ключами:

1. Генерация ключа в защищенной среде
2. Добавление публичного ключа в целевые системы (GitHub, GitLab, серверы)
3. Безопасная передача приватного ключа в CI/CD систему через secrets
4. Использование ключа в пайплайне для деплоя
5. Мониторинг использования и своевременная ротация

Правильное управление SSH-ключами — критически важный аспект безопасности инфраструктуры в DevOps, требующий как автоматизации процессов, так и соблюдения принципа минимальных привилегий.