Вопрос или проблема
Я нахожусь за HTTP-прокси и пытаюсь подключиться к удаленной машине с моего ноутбука под управлением Ubuntu через ssh. Если я настраиваю свой .ssh/config так:
Host test
HostName 55.66.77.88
ProxyCommand nc -X connect -x proxy.corp.com:8080 %h %p
User test_user
Я могу подключиться к удаленной машине. Есть другие пользователи в моей сети (использующие OSX), которые могут подключаться к той же машине, добавляя IP-адрес машины в переменную no_proxy, без nc в ssh/config. Если я добавляю машину в свою переменную no_proxy в zshenv:
no_proxy="localhost,127.0.0.1,55.66.77.88"
NO_PROXY=$no_proxy
и проверяю свой терминал, переменная установлена (после экспорта):
no_proxy=localhost,127.0.0.1,55.66.77.88
но теперь я не могу подключиться к машине. Что может быть не так? Я полагаю, что переменная no_proxy игнорируется, но я не могу это проверить.
ИСПРАВЛЕНИЕ Добавление ssh-сессии без строки nc в конфигурационном файле:
ssh 55.66.77.88 -v
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Чтение конфигурационных данных /home/user/.ssh/config
debug1: /home/user/.ssh/config строка 1: Применение опций для *
debug1: /home/user/.ssh/config строка 16: Применение опций для 55.66.77.88
debug1: Чтение конфигурационных данных /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config строка 19: Применение опций для *
debug1: Подключение к 55.66.77.88 [55.66.77.88] порт 22.
и с nc в config файле:
OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014
debug1: Чтение конфигурационных данных /home/user/.ssh/config
debug1: /home/user/.ssh/config строка 1: Применение опций для *
debug1: /home/user/.ssh/config строка 16: Применение опций для 55.66.77.88
debug1: Чтение конфигурационных данных /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config строка 19: Применение опций для *
debug1: Выполнение прокси-команды: exec nc -X connect -x proxy.corporation.br:8080 55.66.77.88 22
debug1: permanently_drop_suid: 1000
debug1: Файл идентификации /home/user/.ssh/id_rsa типа 1
debug1: Файл идентификации /home/user/.ssh/id_rsa-cert типа -1
debug1: Файл идентификации /home/user/.ssh/id_dsa типа -1
debug1: Файл идентификации /home/user/.ssh/id_dsa-cert типа -1
debug1: Файл идентификации /home/user/.ssh/id_ecdsa типа -1
debug1: Файл идентификации /home/user/.ssh/id_ecdsa-cert типа -1
debug1: Файл идентификации /home/user/.ssh/id_ed25519 типа -1
debug1: Файл идентификации /home/user/.ssh/id_ed25519-cert типа -1
debug1: Включение режима совместимости для протокола 2.0
debug1: Строка локальной версии SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2.3
debug1: Удаленная версия протокола 2.0, удаленная версия программного обеспечения OpenSSH_6.0p1 Debian-4+deb7u2
debug1: match: OpenSSH_6.0p1 Debian-4+deb7u2 паттерн OpenSSH* совместимость 0x04000000
debug1: SSH2_MSG_KEXINIT отправлено
debug1: SSH2_MSG_KEXINIT получено
debug1: kex: server->client aes128-ctr hmac-md5 none
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: отправка SSH2_MSG_KEX_ECDH_INIT
debug1: ожидаем SSH2_MSG_KEX_ECDH_REPLY
debug1: Узел '[55.66.77.88]:22' известен и соответствует ключу хоста ECDSA.
debug1: Найден ключ в /home/user/.ssh/known_hosts:7
debug1: ssh_ecdsa_verify: подпись корректна
debug1: SSH2_MSG_NEWKEYS отправлено
debug1: ожидаем SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS получено
debug1: Путешествия не разрешены сервером
debug1: SSH2_MSG_SERVICE_REQUEST отправлено
debug1: SSH2_MSG_SERVICE_ACCEPT получено
debug1: Аутентификации, которые могут продолжаться: publickey,password
debug1: Следующий метод аутентификации: publickey
debug1: Предоставление RSA открытого ключа: /home/user/.ssh/id_rsa
debug1: Аутентификации, которые могут продолжаться: publickey,password
debug1: Попытка частного ключа: /home/user/.ssh/id_dsa
debug1: Попытка частного ключа: /home/user/.ssh/id_ecdsa
debug1: Попытка частного ключа: /home/user/.ssh/id_ed25519
debug1: Следующий метод аутентификации: password
[email protected]'s пароль:
debug1: Аутентификация прошла успешно (пароль).
Аутентифицировано к 55.66.77.88 (через прокси).
debug1: канал 0: новый [client-session]
debug1: Запрос [email protected]
debug1: Вход в интерактивную сессию.
debug1: Отправка окружения.
debug1: Отправка env LC_PAPER = pt_BR.UTF-8
debug1: Отправка env LC_MONETARY = pt_BR.UTF-8
debug1: Отправка env LC_TELEPHONE = pt_BR.UTF-8
debug1: Отправка env LC_NAME = pt_BR.UTF-8
debug1: Отправка env LANG = pt_BR.UTF-8
debug1: Отправка env LC_NUMERIC = pt_BR.UTF-8
debug1: Отправка env LC_MEASUREMENT = pt_BR.UTF-8
debug1: Отправка env LC_TIME = pt_BR.UTF-8
debug1: Отправка env LC_IDENTIFICATION = pt_BR.UTF-8
debug1: Отправка env LC_ADDRESS = pt_BR.UTF-
Спасибо
Я думаю, что вы неправильно понимаете использование переменной окружения NO_PROXY. Это означает, что вы не должны использовать HTTP-прокси-сервер при подключении к хостам/доменам/IP-адресам, указанным в переменной. В случае вашего удаленного хоста с 55.66.77.88, я полагаю, что вам нужен прокси, по крайней мере, когда вы находитесь внутри ограниченной сети.
Когда вы проводили свой эксперимент и он не удалось подключиться с IP в NO_PROXY, у вас все еще была строка ProxyCommand в вашем .ssh/config файле? Если да, удалите IP и попробуйте снова.
В качестве альтернативы, если вы пытаетесь избежать изменения вашего ssh конфигурационного файла для каждого хоста, которому нужен прокси, вы можете добавить директиву в запись Host *, которая будет проксировать через пользовательский скрипт. Этот скрипт мог бы подключаться через прокси только к хостам, к которым он не может подключиться непосредственно. У меня есть скрипт на моем github (называется ssh-proxy), который делает это и больше.
Ответ или решение
Для подключения к удаленной машине по SSH через HTTP-прокси с использованием переменной окружения no_proxy, нужно понимать, как эти элементы взаимодействуют и как правильно настроить конфигурацию SSH. Давайте подробно рассмотрим вашу ситуацию.
Проблема: подключение по SSH через прокси
Вы находитесь за HTTP-прокси и пытаетесь подключиться к удаленному серверу с IP-адресом 55.66.77.88 с помощью команды SSH. Ваша конфигурация файла .ssh/config, содержащая прокси-команду, уже позволяет вам успешно подключаться к серверу:
Host test
HostName 55.66.77.88
ProxyCommand nc -X connect -x proxy.corp.com:8080 %h %p
User test_userИспользование переменной no_proxy
Переменная no_proxy определяет хосты, для которых не следует использовать прокси-сервер. Это значит, что если вы добавляете 55.66.77.88 в no_proxy, ваше SSH-подключение попытается соединиться напрямую, обходя прокси.
no_proxy="localhost,127.0.0.1,55.66.77.88"
NO_PROXY=$no_proxyЕсли вы установите эту переменную и попытаетесь подключиться к 55.66.77.88 без указания прокси (т.е. убрав строку ProxyCommand в конфигурации или не использовав ее), ваше соединение не пройдет через прокси, и, скорее всего, завершится ошибкой, если сетевые настройки вашей инфраструктуры требуют обязательного использования прокси.
Что идет не так?
-
Понимание
no_proxy: Если вы хотите подключиться к55.66.77.88, используя прокси, вам не следует добавлять этот адрес вno_proxy. Вместо этого для вашего SSH-запроса необходимо сохранить строкуProxyCommand, чтобы обеспечить связь через прокси-сервер. -
Конфигурирование SSH: Попробуйте временно убрать адрес
55.66.77.88из переменнойno_proxyи оставитьProxyCommandв конфигурации SSH. Это позволит увидеть, будет ли работать подключение. -
Логи и отладка: Следите за выводом отладки, используя флаг
-vкоманды SSH (как вы уже сделали). Это поможет понять, доходит ли запрос до прокси и как обрабатывается подключение.
Альтернативные варианты
Если вы хотите избежать ежедневного редактирования конфигурации SSH, вы можете написать скрипт или использовать существующие решения для более гибкого подключения через прокси. Например, скрипт может использовать прокси для всех хостов, кроме тех, которые вы специально указали для прямого доступа.
Вы также можете воспользоваться инструментами, такими как autossh, которые могут автоматически управлять SSH-соединениями и поддерживать их активными.
Заключение
Подводя итоги, как правило, любая попытка устранить прокси через no_proxy, когда он необходим, приведет к сбою подключения. Рекомендуется использовать прокси для всех соединений, которые требуют этого, и исключать его только для тех хостов, которые явно настроены на прямое подключение. Настройка .ssh/config с правильными параметрами и использованием переменной no_proxy может значительно упростить процесс работы с удаленными машинами.