Действительно ли безопасно подключаться к серверу по SSH из отелей во время путешествия?

Действительно ли безопасно подключаться к серверу с помощью SSH из отелей во время путешествия?

Сервер :
- CentOS 7
- авторизация только по ключу RSA - авторизация пароля запрещена
- нестандартный порт

Рабочая станция :
- Ubuntu 14
- пароль пользователя
- пароль для использования ключа RSA (стандартный метод)

Может быть, будет хорошей идеей сохранить половину закрытого ключа RSA на USB-накопителе и автоматически (по сценарию) добавить эту половину в ~ / .ssh / private_key перед подключением?

Интернет будет через WIFI в отелях или по кабелю в съемной квартире.

UPD
Извините за непонятность. Я имею в виду безопасность в двух аспектах:

Безопасность только соединения SSH через ненадежную сеть.
Безопасность компьютера с ключом, необходимым для соединения SSH - если он украден, как защитить сервер ...

security physical-security

— Сергей Серов
источник

Какая половина RSA-ключа? Открытая часть ключа хоста ssh? Половина приватной части вашего ssh-ключа пользователя?

— Андол

конечно, половина моего личного ключа RSA :) и автоматически по сценарию добавить эту половину в ~ / .ssh / private_key перед подключением к серверу.

— Сергей Серов

Вы уже в большей безопасности, чем большинство людей, потому что вы используете Linux. Поскольку вы используете последние версии, у вас должны быть новые версии OpenSSH, которые поддерживают более надежную криптографию. После следования tecmint.com/5-best-practices-to-secure-and-protect-ssh-server вы можете поиграть с ограничением себя до более сильного крипто, такого как stribika.github.io/2015/01/04/secure-secure- shell.html

— цыплята

@ chicks «более безопасный, чем большинство людей, потому что вы используете Linux» - глупая вещь. SSH - это SSH, независимо от того, работает ли он в Linux, Unix (Mac) или Windows. И мы могли бы указать на множество чрезвычайно серьезных недостатков безопасности в Linux в недавней истории (Heartbleed, кто-нибудь?). Просто скажем, давайте оставим глупые войны пламени ОС в стороне, где они принадлежат, потому что это отвлекает от реальных вопросов и проблем. Благодарность! ;-)

— Крейг

@ Чикс, я думаю, это то, что я пытался передать. Множество проблем с безопасностью во всех ОС, и Microsoft добилась огромных успехов с тех пор, как несколько лет назад начала свою инициативу «надежных вычислений». Я просто думаю, что «вы более защищены, потому что Linux» отвлекает разговор от реальной проблемы ( с уважением). ;-)

— Крейг

Ответы:

Итак, что касается создания ssh-соединения по явно недоверенному соединению.

Предполагая, что у вас уже есть запись ~ / .ssh / known_hosts из предыдущего соединения, да, вы должны иметь возможность подключаться, не беспокоясь о том, безопасна ли сеть или нет. То же самое происходит, если у вас есть другие способы проверки ключа хоста ssh.

Если вы никогда ранее не подключались к серверу и не имели никакого другого способа проверки ключа хоста ssh, вы можете быть более осторожны в отношении сети, которую вы используете для подключения.

— andol
источник

Спасибо!! Так что это безопасно для подключения к серверу по SSH даже через любой публичный Wi-Fi?

— Сергей Серов

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

— Хаген фон Айцен

Стоит заметить, что если клиент не знает ключ хоста, то при использовании аутентификации по паролю будет возможна полная MITM-атака. Но если используется аутентификация на основе ключей, злоумышленник сможет только выдать себя за сервер. Злоумышленник также не сможет пройти аутентификацию на реальном сервере. В этом случае злоумышленнику сложно убедительно выдать себя за сервер, поэтому вы можете заметить, что что-то не так, пока не стало слишком поздно. Вкратце: аутентификация с открытым ключом намного безопаснее, чем аутентификация по паролю .

— Касперд

@kasperd: Хорошо, если на подключающемся клиенте включена переадресация агента, даже аутентификация с открытым ключом может обеспечить полную поддержку MITM. Но да, аутентификация с открытым ключом определенно предпочтительнее обычных паролей, в любой день.

— Андол

@kasperd: Ну, я могу легко представить, что кто-то просто обнаружил переадресацию агента, но не полностью понял это, поместив что-то вроде «Host * \ n \ tForwardAgent yes» в их ~ / .ssh / config. Люди делают разные сумасшедшие вещи :-)

— andol

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

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

Кроме того, если вы не хотите вводить фразу-пароль при каждом запуске клиента ssh, вы можете использовать ssh-agent : он может отслеживать в памяти незашифрованные закрытые ключи. Вы можете просто запустить ssh-add, указывая на файл, содержащий зашифрованный ключ, и, после запроса пароля, ключ добавляется в набор, управляемый ssh-agent. После этого каждый раз, когда клиенту SSH требуется ключ, защищенный парольной фразой, ssh-agent прозрачно предоставляет связанный незашифрованный закрытый ключ клиенту ssh. Таким образом, вам не нужно вводить его в интерактивном режиме.

Обратите внимание, что ssh-agent может управлять множеством ключей, и, очевидно, вы можете «настроить» свой ноутбук / рабочий стол для запуска ssh-addутилиты (для заполнения набора ключей ssh-agent) во время входа в систему / запуска.

Кроме того, если кто-то украдет ваш ноутбук, ваши личные ключи, вероятно, будут не единственным «конфиденциальным» контентом, который вы собираетесь выдавать: обратите внимание, что в современных дистрибутивах Linux для настольных компьютеров ОЧЕНЬ легко настроить ноутбук, опирающийся на «зашифрованный» msgstr "файловая система ( /homeкак стартовая, но вся /при необходимости). Поэтому, пожалуйста, учтите это тоже.

Все вышесказанное, очевидно, это НЕ применяется , если вы НЕ полагаться на СВОЙ ноутбук.

PS: что касается вашей возможности хранить две половины незашифрованного закрытого ключа на разных носителях: я настоятельно советую вам не делать этого, поскольку сохранение двух частей конфиденциального содержимого в незашифрованном виде намного, намного хуже, чем хранение двух полные копии всего контента в зашифрованном виде!

— Дамиано Верзулли
источник

На первую часть вашего вопроса уже ответил предыдущий ответ. Что касается вашей второй части, я бы порекомендовал добавить второй фактор к вашей учетной записи SSH с помощью pam_google_authenticator. Это довольно простая установка и настройка на любом дистрибутиве. В случае кражи закрытого ключа, который вы носите с собой, они не смогут войти на ваш сервер без одноразового пароля TOTP от google-authenticator.

https://www.howtoforge.com/tutorial/secure-ssh-with-google-authenticator-on-centos-7

— Арул Сельван
источник