Re: [Comm] неправильный KVM?

[Sergey Vlasov <vsu@altlinux.ru>]

[-- Attachment #1: Type: text/plain, Size: 2567 bytes --]

On Mon, Apr 02, 2012 at 01:53:20PM +0300, Dmitriy Kruglikov wrote:
> Устанавливается некотороый сервер, который находится глубоко внутри
> локальной сети(клиента), доступ к которой возможен только через
> пограничный сервер(клиента), к которому по SSH можно достучаться
> только с некоторого сервера (support) в Инете, к которому можно
> добраться по SSH со своей рабочей станции(типа я сотрудник support).
> Последовательно, войдя на каждый из серверов в цепочке и выполнив там
> в консоли ssh userN@hostN...
> Это не самое увлекательное занятие...

Более того, это не лучший способ с точки зрения безопасности - при
такой схеме, когда устанавливаются отдельные соединения между узлами в
цепочке, в случае компрометации одного из промежуточных серверов
окажутся скомпрометированными и все последующие (поскольку данные,
передаваемые между процессами sshd и ssh, не будут защищены и могут
быть модифицированы).

Более безопасный вариант — использование перенаправления портов, когда
при установке соединения с промежуточным сервером выполняется
перенаправление локального порта рабочей станции через это соединение
на порт sshd следующего сервера, и последующее соединение ssh
устанавливается как бы напрямую между рабочей станцией и очередным
сервером в цепочке.  В этом случае на промежуточном сервере невозможно
скрытно модифицировать данные, передаваемые между рабочей станцией и
следующим сервером, поскольку они передаются через промежуточный
сервер только в виде, защищённом средствами протокола SSH (защита от
подмены сервера, как обычно, обеспечивается проверкой ключа сервера
при установлении соединения).  Также для защиты от возможной
компрометации промежуточных серверов необходимо использовать на них
аутентификацию по ключу, а не по паролю (поскольку на
скомпрометированном сервере sshd может быть модифицирован с целью
кражи паролей).

См., например, рекомендации Openwall (для промежуточных серверов, если
на них не требуется выполнять какие-либо команды, можно ещё добавить
опцию -n, а также явно указать ForwardAgent no, если значение по
умолчанию было изменено):

  http://openwall.info/wiki/internal/ssh#How-to-access-intranet-servers

Сейчас есть альтернативный вариант, не требующий предварительного
запуска ssh для перенаправления портов:

Host final
	ProxyCommand ssh -W %h:%p intermediate
	
Хотя соединение таким способом будет устанавливаться дольше, и пароли
(либо запросы разрешения на использование ключей) будут запрашиваться
несколько раз подряд при каждой установке такого соединения.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]