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

SSH через stunnel с секретным публичным (клиентским) ssl-сертификатом

Я нахожусь в ситуации, когда у меня не может быть входа без пароля для ssh, и сервер ssh не может быть запущен через любой другой порт, кроме порта по умолчанию. Итак, я решил использовать stunnel для туннелирования ssh. На моем персональном компьютере я использую stunnel в клиентском режиме и использую его для входа на сервер следующим образом: ssh -p 8888 user@localhost. Проблема в том, что сертификат клиента ssl является общедоступным, поэтому любой может легко настроить туннель ssl на мой сервер. Если кто-то запрашивает https://myserver.com он показывает, что openssh 2.0 работает на ssl-порту. Таким образом, это стало самым простым способом взлома, гораздо более простым, чем запуск ssl-сервера на порту, отличном от порта по умолчанию. Итак, я хотел бы знать, можно ли сделать сертификат клиента ssl приватным, чтобы он не предлагался никому, кто выполняет https-запрос на моем сервере. И я должен иметь возможность сохранить его в секрете, как закрытый ключ ssl.

Итак, чтобы уточнить: вы хотите, чтобы пароли были разрешены из офисной сети, но не откуда-либо еще. Однако вы должны иметь возможность подключаться откуда угодно.

В моей сети ключи SSH требуются при входе в систему извне, но при подключении с другого хоста изнутри можно использовать ключи или пароли.

Вот как это работает:

/ и т.д. / SSH / sshd_config

RSAAuthentication yes
PasswordAuthentication no

Match Address 192.168.0.*
    PasswordAuthentication yes

Если вы замените 192.168.0. * Своей офисной подсетью, пользователи смогут использовать пароли для подключения, но только из офисной подсети. Однако вы сможете использовать свою пару ключей SSH для подключения из любого места.

Когда ssh-клиент подключается к серверу, ему предоставляется список механизмов аутентификации, которые он может попробовать. Обычно это список «открытый ключ, пароль». В этом случае, когда кто-то подключается извне, ему предоставляется только «открытый ключ», так что его клиент даже не будет пытаться отправить пароль. Если они попытаются аутентифицироваться с помощью любого механизма, отличного от открытого ключа SSH, соединение немедленно отключается сервером. Таким образом, нет возможности для подбора паролей.

Никснотвин, это настоящая проблема, но я совершенно не понимаю, как вы думаете, что то, о чем вы просите, поможет вам. Позвольте мне сформулировать проблему еще раз, чтобы мы могли убедиться, правильно ли я ее понял.

У вас есть ssh-сервер с множеством ненадежных паролей пользователей. Вы хотите иметь возможность входить в систему удаленно с внешнего сайта, но не хотите позволять своим глупым пользователям делать это, поскольку это подвергнет все эти слабые пароли пользователей перебору подбора паролей, который постоянно происходит против незащищенных sshdс. Если ты бежишь sshd вообще, он должен работать на порту 22.

Как у меня дела?

У вас явно есть две сетевые карты и, следовательно, два адреса на этом сервере, потому что вы имеете в виду «интерфейс, обращенный к локальной сети» и «сторону WAN». Как насчет настройки двух sshds, оба работают на порту 22. Один из них привязывается только к внутреннему адресу сетевой карты (ListenAddress 10.3.4.5) и в остальном не ограничен для использования всеми теми локальными пользователями, которые не могут подбирать хорошие пароли. Второй sshd использует другой файл конфигурации, который привязывается только к порту 22 внешнего интерфейса (ListenAddress 2.3.4.5), и который либо запрещает аутентификацию на основе пароля (PasswordAuthentication no) или разрешает вход в систему только пользователям, которые являются членами определенной группы (AllowGroups nixnotwin)?

Решит ли кто-нибудь из них вашу проблему?