EC2: несколько ключей SSH для экземпляра?

Можно ли создать более одного закрытого ключа для SSH в экземпляре EC2? Какова общая лучшая практика для этого? У нас есть несколько пользователей, которым нужен SSH на серверы, и распространение одного ключа просто не работает. Это не позволяет нам лишать пользователей возможности использовать SSH на сервере, если мы не изменим ключ и не перераспределим.

Абсолютно; Вы просто помещаете все соответствующие открытые ключи в изображение, и вы должны быть в порядке. Я предпочитаю использовать систему управления конфигурацией для управления ключами SSH; таким образом, довольно просто отозвать доступ пользователя даже на работающих системах. Существует также гораздо больше ... скажем, «творческих» ... способов обработки этого, таких как хранение всех ваших ключей SSH в LDAP, которые централизуют ключи SSH, как и любые другие учетные данные.

Вы также можете использовать стандартные механизмы SSH. Наилучшим подходом было бы, если бы пользователь запустил на своей машине ssh-keygenсгенерированную пару ключей. Затем они отправляют вам ~/.ssh/id_rsa.pub(или id_dsa.pub, в зависимости от выбранного алгоритма), и вы добавляете его содержимое .ssh/authorized_keysна целевой хост в домашнем каталоге учетной записи, к которой они должны иметь доступ. В файле может быть несколько ключей. Один на линию. И это все! Один и тот же открытый ключ (id_rsa.pub) можно использовать на любом количестве хостов - он всегда будет идентифицировать пользователя.

Вы также можете сделать это иначе - вы запускаете ssh-keygen и отправляете пользователю ~ / .ssh / id_rsa (или id_dsa). И пользователь сохраняет файл в ~ / .ssh / id_rsa. Просто нужно помнить, чтобы изменить разрешения на 600 (-rw -------) этого файла, иначе ssh не примет это. Это, очевидно, менее безопасно, поскольку, вероятно, закрытый ключ распространяется по электронной почте.

Это также можно сделать в PuTTY с PuTTYgen.

Более простой способ, как показано ниже.

Для пользователей Linux / Mac:

1. Для создания открытых и закрытых ключей используйте следующую команду: $ ssh-keygen -t rsa -b 4096

2. Загрузите открытый ключ в папку в вашей корзине S3. Например: S3> MyBucket> Keypair

3. Сохраните и защитите свой закрытый ключ.

Для пользователей Windows:

1. Используйте puttygen для генерации ключей.
2. Следуйте DigitalOcean для создания ключей SSH.
3. Загрузите открытый ключ в S3> MyBucket> Keypair
4. Сохраните и защитите свой закрытый ключ.

Следующие шаги важны при запуске любого Linux AMI.

1. Убедитесь, что роль IAM имеет роль, созданную с помощью политики AmazonS3FullAccess. Это позволяет экземпляру взять на себя роль для доступа к сегментам S3. Это необходимо для чтения открытых ключей из S3 и их копирования в профиль пользователя.

2. Добавьте следующий код в раздел пользовательских данных в разделе Настройка сведений об экземпляре> Дополнительные сведения (в виде текста):

   #!/bin/bash
   usermod user 1
   usermod -aG wheel user1
   mkdir /home/user1/.ssh/
   aws s3 cp s3://MyBucket    /Keypair/user1-pub.pub /home/user1/.ssh/authorized_keys
   
   useradd user2
   usermod -aG wheel user2
   mkdir /home/user2/.ssh/
   aws s3 cp s3://MyBucket   /Keypair/user2-pub.pub /home/user2/.ssh/authorized_keys
   
   sudo -i 
   echo “user1 ALL=(ALL) NOPASSWD:ALL” >> /etc/sudoers
   echo “user2 ALL=(ALL) NOPASSWD:ALL” >> /etc/sudoers
   
   yum update -y
   

Эта настройка создает User1 и User2 и добавляет их пользователям sudo . Команда aws s3 cp копирует открытые ключи пользователей из папки S3 в их .ssh/authorized_keys path. Последний раздел - запускать команды от имени администратора без необходимости ввода паролей.

Есть много улучшений безопасности, которые можно рекомендовать здесь. Хотя это явно не используется в этом примере, ограничение доступа к сегменту S3 определенным сегментом и знание последствий для безопасности при отключении использования пароля в sudo, - это несколько вещей, которые можно выделить. Используйте их с умом, исходя из ваших конкретных потребностей.