Назад | Перейти на главную страницу

Пользователи "переопределяют" друг друга при попытке подключения к SFTP на экземпляре виртуальной машины Google Compute Engine

Со мной происходит странная вещь. Я установил экземпляр виртуальной машины Compute Engine в gCloud. Я настроил все, включая SFTP, как описано на https://devtidbits.com/2011/06/29/implement-a-sftp-service-for-ubuntudebian-with-a-chrooted-isolated-file-directory/.

Я создал двух разных пользователей с разными идентификаторами пользователей, которые принадлежат к одной группе (для целей использования SFTP). Затем я создал пару открытых / закрытых ключей SSH для каждого пользователя (как описано на https://cloud.google.com/compute/docs/instances/adding-removing-ssh-keys).

Затем я пробовал два точно таких же сценария с одинаковыми настройками, только на двух разных уровнях - с установкой метаданных на уровне проекта (https://console.cloud.google.com/compute/metadata/sshKeys?project=PROJECT_ID) и с ключами экземпляра ВМ на странице редактирования экземпляра (уровень экземпляра) (https://console.cloud.google.com/compute/instancesDetail/zones/europe-west1-b/instances/[INSTANCE_NAME ]?project=[PROJECT_ID ]&graph=GCE_CPU&duration=PT1H). Любой из них должен работать.

С метаданными на уровне проекта:

  1. Я добавил первый открытый ключ (скажем, User1) для метаданных проекта и попытался подключиться к FileZilla, используя имя пользователя и закрытый ключ User1. Все нормально работало.
  2. Я добавил второй открытый ключ (скажем, User2) и попытался подключиться к FileZilla, используя имя пользователя и закрытый ключ User2. Все нормально работало.
  3. Я снова попытался подключиться к FileZilla, используя имя пользователя и закрытый ключ User1. Нет подключения (ошибка: отключено: недоступны поддерживаемые методы аутентификации (сервер отправлен: открытый ключ). Ошибка: не удалось подключиться к серверу)
  4. Удалил оба публичных ключа в настройках gCloud.

С помощью ключей экземпляра виртуальной машины на странице редактирования экземпляра: - тот же сценарий без везения

  1. Я добавил первый открытый ключ (скажем, User1) в настройки экземпляра и попытался подключиться к FileZilla, используя имя пользователя и закрытый ключ User1. Все нормально работало.
  2. Я добавил второй открытый ключ (скажем, User2) и попытался подключиться к FileZilla, используя имя пользователя и закрытый ключ User2. Все нормально работало.
  3. Я снова попытался подключиться к FileZilla, используя имя пользователя и закрытый ключ User1. Нет подключения (ошибка: отключено: недоступны поддерживаемые методы аутентификации (сервер отправлен: открытый ключ). Ошибка: не удалось подключиться к серверу)
  4. Удалил оба публичных ключа в настройках gCloud.

У меня FileZilla был открыт все время (также пытался перезапустить FileZilla между шагами 2 и 3), но проблема все еще остается. Поскольку каждый раз, когда я мог подключиться к SFTP с пользователем, я настраивал открытый ключ последний, Я не вижу, что проблема в FileZilla.

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

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

Мы заключили через эту группу Google обсуждение, и после неудачной попытки воспроизвести это поведение, а затем проверки вашего варианта использования, это поведение скорее связано с вашей настраиваемой конфигурацией, которую вы реализовали в своем экземпляре Linux специально, следуя этой третьей стороне ссылка на сайт для обеспечения доступа по протоколу SFTP без оболочки (SSH) с «изолированным каталогом файлов с изолированным корневым каталогом».

За это документ, поскольку гостевая среда не изменяет учетные записи пользователей, не управляемых Google, использование Google Compute Engine для управления ключами SSH и одновременное добавление пользователей к экземпляру вручную не рекомендуется и может вызвать конфликты. Более того, изменение настроек демона SSH и домашних каталогов пользователей добавляет ему еще одной сложности. Полное резюме обсуждения можно проверить Вот.