Настройка облачной виртуальной машины для доступа нескольких пользователей
Я профессор компьютерных наук в колледже. Я хочу иметь удаленный сервер, к которому могут подключаться все мои ученики. Это невероятно легко сделать, когда у меня есть оборудование.Просто создайте учетные записи пользователей на моем сервере с разрешениями, которые я хочу, чтобы они имели (доступ для чтения / записи к файлам в одной папке, подключение к базе данных), дайте учащимся учетные данные. Легко. Так просто.
Это невозможно сделать ни на одной из основных облачных платформ. Я пробовал GCP, AWS и Azure. Я прочитал так много документации и не могу найти ничего отдаленно близкого к моему варианту использования. Все функции «для обучения» вынуждают вас, по сути, иметь одну машину на каждого ученика, а не одну машину, к которой все ученики могут получить доступ. Я пробовал использовать только обычные виртуальные машины в облаке (не «для образования»), и это тоже, похоже, не настраивается так, как я хочу. Я просто хочу добавить учетные записи пользователей в виртуальную машину и позволить студентам входить в них. Но чтобы на самом деле предоставить доступ для входа в виртуальную машину, кажется, что студентам необходимо иметь учетную запись в этой облачной службе, и я должен предоставить их учетным записям административный доступ к виртуальной машине, которую я создал, чего я не хочу делать. Что мне не хватает?
Облачные виртуальные машины во многом совпадают с локальными серверами. Сервер Linux — это сервер Linux, Windows — это Windows. Просто войдите в свой сервер и настройте его так, как вы это делаете с любым другим сервером. Я сделал именно это с моим сервером Ubuntu Linux на AWS.
Если вам нужна дополнительная помощь, предложите вам написать более подробный, точный вопрос, сказав, что вы пробовали, а что нет, то мы можем помочь с отдельными проблемами.
Предположим SSH, другие протоколы будут отличаться. Пользователи предоставляют вам открытый ключ SSH. (Вам не нужно видеть их закрытый ключ.) Настройте это как учетные данные для личного, непривилегированного (не root, не sudo) пользователя.
Как это реализовать, во многом зависит от системы идентификации пользователей, доступной в вашей организации. Это может быть не услуга вашего облачного провайдера, вы можете аутентифицироваться на основании чего угодно.
Ручным решением может быть создание локальных пользователей на сервере и загрузка их ~/.ssh/authorized_keys. Утомительно в обслуживании, пользователи не имеют возможности самообслуживания.
Google Cloud имеет OS Login, где вы можете предоставить любой учетной записи Google (персональной или управляемой) доступ к экземплярам с их персональным ssh-ключом. Пользователи, получившие роль roles/compute.osLogin, не имеют привилегий, поэтому у них не будет sudo. Возможно, это имеет смысл, только если ваша организация уже предоставляет учетные записи Google, домен Workspace или Cloud Identity.
Или у вас может быть система идентификации, не принадлежащая вашему облачному провайдеру. Например, FreeIPA может хранить ключи ssh и интегрировать их с ssh auth на хостах. Опять же, требуется немного работы для развертывания системы идентификации, если она еще не существует.