Чи справді безпечно підключитися до сервера SSH від готелів під час подорожі?

Чи справді безпечно підключитися до сервера за допомогою SSH від готелів під час подорожі?

Сервер :
- CentOS 7
- Авторизація лише ключем RSA - авторизація пароля відхилена
- Нестандартний порт

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

Можливо, буде гарною ідеєю зберегти половину приватного ключа RSA на USB-накопичувачі та автоматично (за сценарієм) додати цю половину до ~ / .ssh / private_key перед підключенням?

Інтернет буде здійснюватися або через WIFI в готелях, або через кабель в орендованій квартирі.

UPD
Вибачте, що спочатку було незрозуміло. Я маю на увазі безпеку у двох аспектах:

Захист лише SSH-з'єднання через ненадійну мережу.
Захист комп'ютера з ключем, необхідним для з'єднання SSH - якщо його вкрадуть, як захистити сервер ...

security physical-security

— Сергій Сєров
джерело

Яка половина RSA-ключа? Загальнодоступна частина хосту ключа ssh? Половина приватної частини вашого ключа ssh?

— andol

половина мого приватного ключа 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, хтось?). Просто кажучи, давайте залишимо дурні війни з полум'ями в кулуарах, де вони належать, тому що це відволікає від реальних питань і проблем. Спасибі! ;-)

— Крейг

@chicks Я думаю, що саме це я намагався передати. Дуже багато проблем із безпекою у всіх ОС, і Microsoft досягла величезних успіхів з моменту початку своєї ініціативи "надійних обчислень * кілька років тому. Я просто думаю, що" ви більш безпечні, тому що Linux "відволікає розмову від фактичної проблеми ( шанобливо). ;-)

— Крейг

Відповіді:

Отже, щодо встановлення ssh-з'єднання через явно ненадійне з'єднання.

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

Якщо ви ніколи раніше не підключалися до сервера і не маєте жодного іншого способу підтвердження ключа ssh, то ви можете бути обережнішими щодо мережі, яку ви використовуєте для підключення.

— andol
джерело

Дякую!! Тож безпечно підключатися до сервера через SSH навіть через будь-який публічний wi-fi?

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

Насправді ця відповідь стосується будь-якої ситуації, коли ви хочете перенести ssh на віддалений сервер, і будь-яка частина шляху не знаходиться під вашим повним контролем (тому практично нічого, крім ssh-ing до щойно встановленого localhost або через кабель перехресної посилання )

— Хаген фон Ейтцен

Варто зауважити, що якщо клієнт не знає хост-ключ, тоді, якщо використовується автентифікація пароля, буде можлива повна MITM-атака. Але якщо використовувати автентифікацію на основі ключів, зловмисник зможе представити себе лише сервером. Зловмисник також не зможе пройти автентифікацію на справжньому сервері. Зловмиснику важко надати переконливе видання себе в цьому випадку, тому, можливо, ви зможете помітити, що щось не так, поки не пізно. Коротше кажучи: автентифікація відкритого ключа набагато безпечніша, ніж автентифікація пароля .

— kasperd

@kasperd: Добре, якщо у підключеного клієнта ввімкнено переадресацію агента, навіть аутентифікація відкритого ключа може забезпечити повний досвід роботи з MITM. Але так, аутентифікація відкритих ключів, безумовно, краща перед звичайними паролями, будь-який день.

— andol

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

— усілякі

У другій частині запитання ви, мабуть, турбуєтесь про те, що ваш ноутбук буде викрадений, а разом з цим і вашими приватними ключами для входу в SSH без пароля на ваших серверах.

Зауважте, що це можна легко вирішити (проблема з приватними ключами), зберігаючи приватні ключі, "зашифровані" "парольною фразою": вони можуть бути зашифровані спочатку, одночасно створюючи утиліту ssh-keygen , надаючи парольну фразу в кінці процес генерації або, якщо у вас їх уже не записано, використовуйте утиліту ssh-keygen з -pопцією. Після того, як ключ зашифрований, при кожному вході вам потрібно буде ввести відповідну парольну фразу і .... якщо це правильно, все пройде нормально.

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

Зверніть увагу, що ssh-агент може керувати великою кількістю клавіш, і, очевидно, ви можете "настроїти" ваш ноутбук / робочий стіл, щоб запустити ssh-addутиліту (для заповнення набору ключів ssh-агента) під час входу / запуску.

Крім того, якщо хтось вкраде ваш ноутбук, ваші приватні ключі, мабуть, не єдиний "чутливий" вміст, який ви збираєтеся видавати: будь ласка, зауважте, що з сьогоднішніми дистрибутивами на робочому столі Linux ДУЖЕ легко налаштувати ноутбук, покладаючись на "зашифровані "файлова система ( /homeяк запуск, але вся, /якщо потрібно). Тож, будь ласка, врахуйте і це.

Все вищезазначене, очевидно, НЕ застосовується, якщо ви НЕ покладаєтесь на власний ноутбук.

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

— Даміано Верзуллі
джерело

Перша частина вашого питання вже відповідає попередньою відповіддю. Згідно з вашою другою частиною, я б рекомендував додати другий фактор до вашого входу в ssh за допомогою pam_google_authenticator. Це досить проста настройка та налаштування на будь-який дистрибутив. У випадку, коли приватний ключ, який ви носите з собою, викрадений, він не може увійти на ваш сервер, коли не вийде одноразовий пароль TOTP від google-автентифікатора.

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

— Аруль Сельван
джерело