Настройка облачной виртуальной машины для доступа нескольких пользователей

Я профессор колледжа CS. Я хочу иметь удаленный сервер, к которому могут подключиться все мои ученики. Это невероятно легко сделать, когда у меня есть оборудование. Просто создайте учетные записи пользователей на моем сервере с разрешениями, которые я хочу, чтобы они имели (доступ для чтения/записи к файлам в одной папке, подключение к базе данных), предоставьте студентам учетные данные. Легкий. Так просто.

Кажется, это невозможно сделать ни на одной из основных облачных платформ. Я пробовал GCP, AWS и Azure. Я прочитал так много документации, и я не могу найти ничего близкого к моему варианту использования. Все функции «для образования» вынуждают вас иметь по одной машине на каждого учащегося, а не по одной машине, к которой могут получить доступ все учащиеся. Я пытался использовать только обычные виртуальные машины в облаке (не «для обучения»), и это также не настраивается так, как я хочу. Я просто хочу добавить учетные записи пользователей на виртуальную машину и позволить учащимся входить в них. Но чтобы фактически предоставить доступ для входа в виртуальную машину, кажется, что учащиеся должны иметь учетную запись в этой облачной службе, и я должен предоставить их учетной записи административный доступ к созданной мной виртуальной машине, чего я не хочу делать. Что мне не хватает?

Облачные виртуальные машины во многом аналогичны локальным серверам. Linux-сервер — это Linux-сервер, Windows — это Windows. Просто войдите на свой сервер и настройте его так же, как и на любом другом сервере. Я сделал именно это с моим сервером Ubuntu Linux на AWS.

Если вам нужна дополнительная помощь, предложите вам написать более подробный и точный вопрос, указав, что вы пробовали и что не сработало, тогда мы можем помочь с отдельными проблемами.

Допустим, SSH, другие протоколы будут другими. Пользователи предоставляют вам открытый ключ SSH. (Вам не нужно видеть их закрытый ключ.) Настройте это как учетные данные для личного, непривилегированного (не root, не sudo) пользователя.

Способы реализации сильно различаются в зависимости от системы идентификации пользователей, доступной в вашей организации. Что может не быть услугой вашего облачного провайдера, вы можете авторизоваться на чем угодно.

Ручным решением может быть создание локальных пользователей на сервере и загрузка их ~/.ssh/authorized_keys. Утомительно поддерживать, у пользователей нет возможности самообслуживания.

Облако Google имеет Вход в ОС где вы можете предоставить любой учетной записи Google (личной или управляемой) доступ к экземплярам с их личным ключом ssh. Пользователи предоставили роли /compute.osЛогин роли не являются привилегированными, поэтому у них не будет sudo. Вероятно, это имеет смысл только в том случае, если ваша организация уже предоставляет учетные записи Google, домен Workspace или Cloud Identity.

Или у вас может быть система идентификации не от вашего облачного провайдера. Например, FreeIPA может хранить ключи ssh и интегрировать их с аутентификацией ssh ​​на хостах. Опять же, требуется немного работы для развертывания системы идентификации, если она еще не существует.