Ограничения доступа пользователей с парой ключей: .pem головоломка

Question

Вот мой вопрос

У меня есть экземпляр ес-2 на AWS, работающий под управлением Ubuntu Server. Во время первого запуска экземпляра я сгенерировал пару ключей, перейдя в консоль AWS -> Key Pairs -> Create key pair. Он сгенерировал ключ abcxxxx.pem, и я сохранил его.

Вот где проблема начинается

• я возглавляю проект, где несколько разработчиков приходят и выключаться. Без слишком много думал, я распространил мой файл .pem до 2-3 разработчиков. Они покинули проект с тех пор, и я хочу ограничить доступ AWS только активными разработчиками. В принципе, я не хочу, чтобы 2-3 разработчики (с файлом .pem) получили доступ к моей машине.

• Для всех новых разработчиков (я больше не распространять .pem файл), я даю доступ к AWS машины, вставив там public key в /home/ubuntu/.ssh/authorized_keys. Это дает им доступ к машине.

Мои два вопроса являются

1. Как я могу ограничить доступ к людям, которые уже .pem файла? Удалит их открытый ключ от /home/ubuntu/.ssh/authorized_keys. ПРИМЕЧАНИЕ: У меня все еще есть ключ, и у меня есть доступ к консоли AWS.
2. Как новые разработчики могут получить доступ к машине AWS без файла .pem? (Единственное, что я делаю, это вставить их открытый ключ в authorized_keys на AWS)
3. Как я могу реализовать систему, в которой у меня есть единственный доступ, и я имею дело с разработчиками, входящими/выключенными в проекте?
4. Все пользователи (включая меня), которые являются открытым ключом, находятся в авторизованных ключах на машине AWS, могут войти без файла .pem. Как это возможно? Не все ли нужны файлы .pem для ssh?

Я действительно запутался в этом бизнесе с ключевыми парами (в чем роль файла .pem?) И других сообщений в Интернете, похоже, не помогает (даже поддержка AWS). Большинство почтовых сценариев онлайн-адресов, где вы теряете ключ, и вы запускаете новый экземпляр и т. Д. И т. Д. Я связался с поддержкой AWS, и они просто отправили мне это link. Я не понимаю, как это помогает.

Любое решение/сложный ответ будет действительно полезным.

Answer 1

По большей части, ваш вопрос на самом деле о том, как administrate users и SSH на Ubuntu. Ключевая пара, созданная с помощью консоли, используется только тогда, когда экземпляр запускается первым. Он всегда доступен через instance metadata; Вы можете видеть, что, выполнив следующую команду из командной строки на экземпляре EC2:

$ локон http://169.254.169.254/latest/meta-data/public-keys/0/openssh-key

, который выводит:

SSH-RSA ... бла-бла-бла ...

Когда ваш экземпляр EC2 впервые был запущен, этот ключ был скопирован в /home/ubuntu/.ssh/authorized_keys, потому что Ubuntu AMI вы используете для этого. Но это всего лишь конвенция. Это единственный момент, когда ключ будет автоматически копироваться в любом месте, поэтому оттуда вы можете управлять файлом authorized_keys, как вам нравится.

Что касается ваших конкретных вопросов,

1. Если первоначальный открытый ключ, созданный на консоли еще в authorized_keys, то любой, кто имеет соответствующий PEM файл все еще может войти в систему. Чтобы это исправить, вам нужно будет для осторожного удаления этого ключа из файла authorized_keys (например, сначала сделайте абсолютно уверенным, что вы можете войти в систему с помощью другого ключа).
2. Хотя у них может не быть файла PEM, загруженного с консоли AWS, они должны каким-то образом получить файл PEM (или некоторый приблизительный эквивалент) для одного из открытых ключей, добавленных вами в authorized_keys.
3. Есть много разных способов. Как уже упоминалось выше, это больше зависит от того, как вы хотите administrate users под Ubuntu. Поскольку вы, похоже, хотите сохранить контроль над машиной, вы можете создать учетные записи пользователей для каждого из разработчиков, чтобы войти в систему, а затем предоставить им ограниченные права на использование sudo в некоторых случаях (при условии, что они вообще этого нужны). Затем вы можете отменить эти учетные записи, когда захотите.
4. Мое понимание заключается в том, что существует только много разных способов предоставить эквивалент файла PEM для ssh, и каким-то образом вы (и ваши разработчики) должны это делать. Я бы рекомендовал ознакомиться с документацией ssh.

Надеюсь, это поможет!

Answer 2

Принимая следующие меры:
1) Вы не можете удалить ключ из authorized_keys, не теряя при этом доступ к серверу. Открытый ключ там доказывает серверу, что вы - тот, кого вы говорите, когда вы авторизуетесь на сервере через SSH, используя пем.

2) Для новых разработчиков они передают ключ, когда ssh на машине. Это всего лишь их ключ, и он неявно передается, и ключ, который вы использовали, чтобы развернуть машину. Наличие их открытого ключа в authorized_keys сигнализирует серверу, что им разрешен доступ к компьютеру, как только их клиент ssh докажет, что у него есть закрытый ключ, который соответствует открытому ключу в авторизованном файле.

3) Я бы просто создал дополнительных пользователей на этом поле и настроил их для входа в систему без пароля, установив /home/newusername/.ssh/authorized_keys почти так же, как вы установили его для пользователя ubuntu сегодня. когда они покидают проект, просто отключить и/или удалить учетные записи

4) Можно войти в систему без указания пэра, но вы все равно укажете ключ. Чтобы увидеть обмен ключами и как выполняется аут, сделайте «ssh -vvv user @ machinename», и вы увидите весь диалог ssh. Когда вы не укажете ключ, клиент ssh будет искать один в нескольких предопределенных местах. вы увидите, что клиент пытается использовать каждый из этих ключей (вы, вероятно, выбираете что-то от ~/.ssh/id_ *). Пем не волшебный файл. Это просто ключи (он может содержать открытый ключ, открытый и закрытый ключ или открытый ключ и целую цепочку сертификатов).

Я бы порекомендовал вам прочитать общедоступный/закрытый ключ crypto, чтобы понять, как он работает.

https://en.wikipedia.org/wiki/Public-key_cryptography

https://www.youtube.com/watch?v=svRWcx7dT8g

https://staff.washington.edu/dittrich/misc/ssh/