Может ли приложение Cloud Foundry подключаться к самому себе по протоколу SSH с аутентификацией по ключу?

Question

У меня есть приложение CF, которому требуется доступ к sftp-серверу для интеграционного тестирования, и я хотел бы воспользоваться преимуществом настройки локального контейнера, чтобы он мог действовать как единое целое.

Я понимаю, что, как описано в документации , приложение может подключиться к самому себе через прокси-сервер, но получить пароль для использования сcf:<application-guid>имя пользователя — это осложнение, которого я бы хотел избежать, если это возможно.

Если я подключусь к контейнеру приложения по SSH, я действительно смогу подключиться через прокси-сервер, но если я попытаюсь подключиться по SSH кlocalhost:2222, я получаю сообщение об ошибке «отказ в открытом ключе», предполагающее, что он будет поддерживать аутентификацию по ключу.

Доступен ли в контейнере приложения закрытый ключ, который приложение может использовать для подключения к ssh/sftp самому себе?

Answer 1

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

Как только вы использовалиcf sshЧтобы получить сеанс оболочки внутри контейнера приложения, вот быстрый способ извлечь значение закрытого ключа, закодированного в PEM, в файл, а затем использовать его для аутентификации на сервере:

      $ strings /proc/$(pidof diego-sshd)/environ | awk '/-----BEGIN/,/-----END/' | sed 's/SSHD_HOSTKEY=//g' > sshdkey
$ chmod 0600 sshdkey
$ ssh -i sshdkey -p 2222 localhost

Вам нужноchmodкоманда, позволяющая ограничить права доступа к файлу закрытого ключа толькоvcapпользователя в контейнере приложения, иначе SSH-клиент будет жаловаться, что разрешения слишком открыты.

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

      $ pstree -pT $(pidof diego-sshd)
diego-sshd(8)───bash(259)───pstree(323)

$ echo $$
259

$ ssh -i sshdkey -p 2222 localhost

$ pstree -pT $(pidof diego-sshd)
diego-sshd(8)─┬─bash(259)───ssh(341)
              └─bash(342)───pstree(353)

$ echo $$
342

В этом случае,

• 259PID процесса, запущенного начальным сеансом CF SSH,
• 341это PIDsshпроцесс запуска вложенного сеанса SSH,
• 342это PIDbashпроцесс, запущенный сеансом этого клиента.

Немного информации о том, что происходит с внутренними компонентами CF:

• Когда Cloud Foundry создает новое приложение с включенным доступом по SSH, оно генерирует частный ключ хоста для конкретного приложения и сохраняет его в информации о маршрутизации приложения в системе Diego CF.Прокси-компонент Diego SSH использует этот закрытый ключ для аутентификации на SSH-серверах diego-sshd экземпляров приложения при передаче сеанса CF SSH разработчика приложения в один из экземпляров приложения.
• Cloud Foundry также настраивает боковой сервер diego-sshd приложения с помощью этого частного ключа хоста в-hostKeyфлаг, чтобы он соответствовал ключевой информации, которую будет использовать прокси-сервер SSH.
• Этот ключ, конечно, является конфиденциальным, поэтому, чтобы предотвратить его случайное раскрытие, при запускеdiego-sshdсервер хранит значение ключа в этом SSHD_HOSTKEYenv var , а затем повторно запускает себя, чтобы удалить значение ключа из командной строки . Но ключевое значение все еще находится в своей среде, поэтому мы можем извлечь его значение изprocфайловая система внутри контейнера.