Хотя мы написали это руководство с Linux в виду, это также может применяться к OpenSSH в Mac OS X и Windows 7 через Cygwin.
Почему это безопасно
Мы много раз упоминали, как SSH - отличный способ безопасного подключения и туннелирования данных из одной точки в другую. Давайте кратко рассмотрим, как все работает, чтобы вы лучше поняли, почему иногда бывает странно.
Если мы думаем о нашем процессе подключения как о почте, то использование FTP и Telnet и тому подобное не похоже на использование стандартных почтовых конвертов. Это больше похоже на использование открыток. Если кто-то оказывается в середине, они могут видеть всю информацию, включая адреса обоих корреспондентов, а также имя пользователя и пароль. Затем они могут изменять сообщение, сохраняя информацию одинаково и выдавать себя за одного корреспондента или другого. Это называется атакой «человек в середине», и это не только ставит под угрозу вашу учетную запись, но и ставит под сомнение каждое отправленное сообщение и полученный файл. Вы не можете быть уверены, если вы разговариваете с отправителем или нет, и даже если это так, вы не можете быть уверены, что никто не смотрит на все, что находится между ними.
Теперь давайте посмотрим на шифрование SSL, что делает HTTP более безопасным. Здесь у нас есть почтовое отделение, которое обрабатывает корреспонденцию, которая проверяет, является ли ваш получатель тем, кем он или она является, и имеет законы, защищающие вашу почту от просмотра. Это более безопасно в целом, а центральный орган - Verisign - один, для нашего примера HTTPS - убедитесь, что человек, которого вы отправляете почту, проверяет. Они делают это, не допуская открыток (незашифрованные учетные данные); вместо этого они предоставляют реальные конверты.
С объяснением до тех пор, пока это так, мы думаем, что мы его разрежем. Если у вас есть более глубокое понимание, вы можете свободно общаться в комментариях, конечно. Пока же, давайте рассмотрим наиболее релевантную функцию SSH, аутентификацию хоста.
Ключи хоста
Аутентификация хоста по сути является той частью, в которой кто-то, кому вы доверяете, берет конверт (запечатанный магической математикой) и подтверждает адрес вашего получателя. Это довольно подробное описание адреса, и оно основано на некоторой сложной математике, которую мы просто пропустим. Есть несколько важных вещей, чтобы убрать это, хотя:
- Поскольку нет центральной власти, реальная безопасность заключается в ключе хоста, открытых ключах и закрытых ключах. (Эти последние два ключа настроены, когда вам предоставляется доступ к системе.)
- Обычно, когда вы подключаетесь к другому компьютеру через SSH, ключ хоста сохраняется. Это делает будущие действия более быстрыми (или менее подробными).
- Если ключ хоста изменится, вы, скорее всего, будете предупреждены, и вы должны быть осторожны!
Поскольку ключ-ключ используется до аутентификации для установления идентификатора SSH-сервера, вы должны обязательно проверить ключ перед подключением. Появится диалоговое окно подтверждения, как показано ниже.
Проверка ключа хоста вашей системы
Существует четыре типа алгоритмов шифрования, используемых для создания ключей, но по умолчанию для OpenSSH по состоянию на начало этого года ECDSA (с некоторыми хорошими причинами). Сегодня мы сосредоточимся на этом.Вот команда, которую вы можете запустить на сервере SSH, к которому у вас есть доступ:
ssh-keygen -f /etc/ssh/ssh_host_ecdsa_key.pub -l
Ваш результат должен возвращать что-то вроде этого:
256 ca:62:ea:7c:e4:9e:2e:a6:94:20:11:db:9c:78:c3:4c /etc/ssh/ssh_host_ecdsa_key.pub
Первое число - это длина бит ключа, затем сам ключ, и, наконец, у вас есть файл, в котором он хранится. Сравните эту среднюю часть с тем, что вы видите, когда вам будет предложено войти в систему удаленно. Он должен соответствовать, и вы все настроены. Если это не так, то может произойти что-то еще.
Вы можете просмотреть все хосты, к которым вы подключились, через SSH, просмотрев файл known_hosts. Он обычно расположен по адресу:
~/.ssh/known_hosts
Вы можете открыть это в любом текстовом редакторе. Если вы посмотрите, постарайтесь обратить внимание на то, как хранятся ключи. Они хранятся с именем хоста (или веб-адресом) и его IP-адресом.
Изменение хост-ключей и проблем
Существует несколько причин, по которым ключи хоста меняются или они не соответствуют тому, что зарегистрировано в вашем файле known_hosts.
- Система была повторно установлена / повторно настроена.
- Клавиши хоста были изменены вручную из-за протоколов безопасности.
- Сервер OpenSSH обновлен и использует разные стандарты из-за проблем с безопасностью.
- Смена IP или DNS изменилась. Это часто означает, что вы пытаетесь получить доступ к другому компьютеру.
- Система каким-то образом была скомпрометирована таким образом, что ключ хоста изменился.
Скорее всего, проблема одна из первых трех, и вы можете игнорировать изменения. Если аренда IP / DNS изменилась, тогда может возникнуть проблема с сервером, и вы можете быть перенаправлены на другую машину. Если вы не знаете, в чем причина изменения, вы должны, вероятно, предположить, что это последний в списке.
Как OpenSSH обрабатывает неизвестные хосты
В зависимости от вашей конфигурации соединения SSH с неизвестными хостами (ключи которых еще не находятся в вашем файле known_hosts) могут идти тремя способами.
- У StrictHostKeyChecking установлено значение no; OpenSSH автоматически подключается к любому SSH-серверу независимо от состояния ключа хоста. Это небезопасно и не рекомендуется, за исключением случаев, когда вы добавляете кучу хостов после переустановки вашей ОС, после чего вы ее измените.
- StrictHostKeyChecking настроен на запрос; OpenSSH покажет вам новые ключи хоста и попросит подтверждения, прежде чем добавлять их. Это предотвратит переход соединений с измененных ключей хоста. Это значение по умолчанию.
- У StrictHostKeyChecking установлено значение yes; Противоположность «нет», это не позволит вам подключиться к любому хосту, который еще не присутствует в вашем файле known_hosts.
Вы легко можете легко изменить эту переменную в командной строке, используя следующую парадигму:
ssh -o 'StrictHostKeyChecking [option]' user@host
Замените [option] на «no», «ask» или «yes». Имейте в виду, что существуют одиночные прямые кавычки, окружающие эту переменную и ее настройку. Также замените user @ host именем пользователя и имени хоста сервера, к которому вы подключаетесь. Например:
ssh -o 'StrictHostKeyChecking ask' [email protected]
Заблокированные хосты из-за измененных ключей
Если у вас есть сервер, к которому вы пытаетесь получить доступ, если его ключ уже был изменен, конфигурация OpenSSH по умолчанию не позволит вам получить к нему доступ. Вы можете изменить значение StrictHostKeyChecking для этого хоста, но это не будет полностью, полностью, параноидально безопасным, не так ли? Вместо этого мы можем просто удалить оскорбительное значение из нашего файла known_hosts.
Теперь вместо этого получим хорошее приглашение, на которое мы можем просто ответить «да».
Создание новых ключей хоста
Для записи действительно нет слишком большой причины для изменения вашего ключа хоста, но если вы когда-нибудь найдете это, вы можете сделать это легко.
Сначала перейдите в соответствующий системный каталог:
cd /etc/ssh/
Обычно это где глобальные ключи хоста, хотя некоторые дистрибутивы их размещают в другом месте. Если у вас есть сомнения, проверьте свою документацию!
Затем мы удалим все старые ключи.
sudo rm /etc/ssh/ssh_host_*
Кроме того, вы можете переместить их в безопасный каталог резервного копирования. Просто мысль!
Затем мы можем сказать, что сервер OpenSSH может перенастроить себя:
sudo dpkg-reconfigure openssh-server
Вы увидите подсказку, когда компьютер создает новые ключи. Та-да!
Теперь, когда вы знаете, как SSH работает немного лучше, вы должны быть в состоянии выйти из жестких мест. Предупреждение / ошибка «Удаленный хост-идентификатор изменен» - это то, что отбрасывает много пользователей, даже тех, кто знаком с командной строкой.
Для бонусных очков вы можете проверить, как удаленно копировать файлы через SSH без ввода пароля. Там вы узнаете немного больше о других видах алгоритмов шифрования и о том, как использовать ключевые файлы для дополнительной безопасности.
