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