SSH: что лучший способ состоит в том, чтобы достигнуть безопасного соединения с динамическим IP?
Так как SSH не знает что-то как Host заголовок в HTTP/1.1, Вы не можете отрицать, что определенный пользователь входит в Ваш сервер. Демон SSH не может знать, на каком домене, первоначально разрешенном к IP-адресу, это слушает.
Вы могли только получить другой IP-адрес, установить его как ресурсную запись для subdomain.example.com и позвольте пользователю только входить в систему на том определенном IP-адресе.
Если вы используете SSH, это делает его безопасным. Тот факт, что ваши клиентские машины имеют разные (и динамические) адреса, не имеет большого значения.
Рассмотрим нестандартный порт, используйте что-то вроде отбрасывания порта , если можете, и используйте только аутентификацию с открытым ключом. Если у вас включена аутентификация по паролю, установите fail2ban .
Чего вы пытаетесь достичь? Насколько сильно вы собираетесь контролировать те машины, которые будут ssh-клиентами?
В идеале вы будете использовать аутентификацию на основе ключей, когда у вас будет свой закрытый ключ ssh на машине при подключении к серверу.
Если это невозможно, убедитесь, что у вас есть хороший пароль.
На сервере ограничьте количество пользователей, которые могут использовать ssh в поле. Исключите пользователей, таких как root и т. Д., Из возможности использовать ssh. Это параметр AllowGroups или AllowUsers в /etc/ssh/sshd_config.
Отключить вход в систему root. Настройте свои ключи и отключите вход по паролю, установите fail2ban или denyhosts.
Похоже, этого достаточно из того, что я видел.
Вы можете пойти дальше. Альтернативой является наличие одного или двух промежуточных серверов в другом месте, которые не являются критически важными, и ssh через один из них, тогда вы можете ограничить доступ к ssh на своем важном сервере только с этих IP-адресов в iptables.
Перенос sshd на другой порт может звучать как защита от неизвестности, и вы можете найти статьи, в которых говорится, что это неэффективно. Это может иметь место, если злоумышленник нацелен на ваш сервер. В реальной жизни вы видите, как ssh-атаки просто бьют по порту 22, перемещаясь по вашим серверам. Переход на другой порт снижает шум в файлах журнала, как минимум.