Во-первых, возможно ли такое? Рассмотрим следующую схему:
Один публичный "SSH Bounce Box"
bouncer.mydomain.tld
Четыре частных системы * nix
host1.mynet.local
host2.mynet.local
host3.mynet.local
host4.mynet.local
Все работают с Open-SSH на порту 22. Каждая частная система имеет свой уникальный пароль root и уникальных пользователей.
Я хочу иметь возможность войти в host1.mynet.local как root с помощью этой единственной команды:
ssh host1@bouncer.mydomain.tld
Вышеупомянутое подпишет меня на host1.mynet.local SSH как root, используя поле отказов SSH, без необходимости вручную настраивать туннели.
Также рассмотрите следующую возможность:
ssh janet_host3@bouncer.mydomain.tld
Это должно подключиться к host3.mynet.local как пользователь janet. Последний знак «_» отделял имя пользователя от идентификатора хоста.
Проблема в том, что это должно быть полностью прозрачно для конечного пользователя. Это означает, что работа выполняется на стороне сервера, а не на стороне клиента. Конечному пользователю не нужно редактировать файлы конфигурации, настраивать туннели или редактировать файлы .ssh / config, чтобы он работал там.
Сначала я опишу [неудачное, хакерское, но простое в установке] решение. Затем я опишу, почему я так не думаю именно то, что вы описали, было бы легко.
На машине bouncer.mydomain.ltd будет один пользователь для каждого кортежа пользователь / хост. У каждого пользователя на машине-вышибале будет .bashrc:
ssh user@hostn.mynet.local exit
Кроме того, открытые ключи от машины-вышибалы для каждого пользователя могут быть помещены в authorized_keys каталог для предполагаемого пользователя соответствующего хоста.
Ошибка в том, что информация является избыточной, и любые изменения на определенных хостах не будут распространяться (если вы не введете какие-либо хакерские сценарии)
Предыдущее решение - это действительно ssh-соединение, открытое из оболочки ssh-соединения. Я думаю, вы действительно представляли себе нечто большее, чем обратный прокси-сервер, который маршрутизируется на основе того, что вы помещаете в пользовательскую область.
К сожалению, эту информацию о пользовательской области сложно извлечь. (И я не знаю ни одного программного обеспечения, которое бы это уже делало).
ssh janet_host3@bouncer.mydomain.tld
ssh не сразу просто извлекает janet_host3 и отправьте его на сервер. Скорее..
Только тогда может произойти аутентификация. По зашифрованному каналу.
Важно отметить, что ваш сервер не может знать, на какой машине проксировать информацию о подключении, пока не будет завершена часть связи.
Для справки ниже приведен пример некоторых из первых частей информации, которые получает сервер (я запустил ssh на свой локальный хост).
SSH-2.0-OpenSSH_6.0p1 Debian-3ubuntu1
......%{A.Q..3....*~\.....ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-ex
Итак, чтобы решить это:
В зависимости от того, почему вы хотите это настроить, возможно, я смогу предложить несколько альтернативных решений:
Если вам просто нужны псевдонимы, чтобы пользователи запоминали различную информацию, используйте DNS и cnames, чтобы hostn.bouncer.mydomain.tld отправляет пользователей на машину, которую они намереваются.
Если вы хотите иметь возможность отслеживать трафик с помощью машины-вышибалы ... вам нужно сделать одно из описанных выше действий. Чтобы перехватить зашифрованный трафик, вы должны быть посредником, чтобы расшифровать информацию, а затем снова зашифровать ее перед отправкой.
Я не уверен, но не могли бы вы взглянуть на sshuttle https://github.com/apenwarr/sshuttle/ возможно, одно из наиболее распространенных применений может удовлетворить ваши требования.
Поиск в Google предоставил это решение:
http://blog.gidley.co.uk/2009/03/tunnelling-ssh-over-socks-proxy.html
Я считаю это простым и умным, но, к сожалению, он не отвечает последнему требованию ...
Но использование NC может быть ответом.