SSH: подлинность хоста <host> не может быть установлена


83

Что означает это сообщение? Это потенциальная проблема? Канал не защищен?

Или это просто сообщение по умолчанию, которое всегда отображается при подключении к новому серверу?

Я привык видеть это сообщение при использовании SSH в прошлом: я всегда вводил свой логин с паролем обычным способом, и я чувствовал себя хорошо, потому что я не использовал закрытые / открытые ключи (что гораздо более безопасно чем короткий пароль). Но на этот раз я установил открытый ключ с ssh для подключения к bitbucket, но я все еще получил сообщение. Мне известно, что запрос пароля в конце является другой дополнительной мерой безопасности для расшифровки закрытого ключа.

Я надеюсь, что кто-нибудь может дать хорошее объяснение тому, что подразумевается под этим сообщением «подлинность не может быть установлена».

The authenticity of host 'bitbucket.org (207.223.240.181)' can't be established.

RSA key fingerprint is 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'bitbucket.org,207.223.240.181' (RSA) to the list of
known hosts.
Enter passphrase for key '/c/Users/Steven/.ssh/id_rsa':

2
Это действительно одно из тех сообщений "означает именно то, что он говорит". Это значит, sshчто нет никакой возможности сказать, что вы действительно разговариваете bitbucket.org. Если вы настроили какой-то способ, чтобы он знал, то это не работает. Если вы этого не сделали, то это говорит вам, что вы этого не сделали.
Дэвид Шварц

Ответы:


71

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

Если вы ранее подключались к этому серверу после этой установки ssh, то либо сервер был перенастроен с новым ключом, либо кто-то подделывает идентификацию сервера. Из-за серьезности атаки «человек посередине» она предупреждает вас о возможности.

В любом случае, у вас есть безопасный зашифрованный канал для кого-то . Никто без закрытого ключа, соответствующего отпечатку пальца, не 97:8c:1b:f2:6f:14:6b:5c:3b:ec:aa:46:46:74:7c:40сможет расшифровать то, что вы отправляете.

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


Таким образом, даже если существует злонамеренная третья сторона, и я отклоняю сообщение, все, что я собираюсь сделать, это отправить ему свой открытый ключ, и он все равно не сможет расшифровать мои данные? Так что теперь единственные способы, которыми мои данные могут быть скомпрометированы, - это если (1) скомпрометирован мой личный ключ или (2) скомпрометированы серверы bitbucket или (3) скомпрометирована моя учетная запись bitbucket. Пока они ограничивают попытки входа в систему (что я бы очень удивился, если бы они этого не сделали), на самом деле не так уж много причин быть параноиком на данный момент, а?
Стивен Лу

10
@ Стивен: Вы не отправляете ему свой открытый ключ, у него это уже есть. То, что вы делаете, - это используете свой личный ключ для аутентификации вызова ... если он подключился к настоящему bitbucket.org, претендующему на то, чтобы быть вами, получил настоящий вызов и использовал этот вызов при вызове, он мог бы затем обмануть вас отправив ему действительный ответ, который он затем использует, чтобы получить доступ к вашей учетной записи на реальном bitbucket.org. У него все еще нет вашего личного ключа, поэтому он не может войти в систему в любое время или в любой другой ресурс, который разблокирует ключ, но у него есть один сеанс входа.
Бен Фойгт

Вот что я имел в виду в своем ответе, когда сказал, что «вы не захотите отправлять аутентификационную информацию на мошеннический сервер».
Бен Фойгт

2
«Если вы параноик, проверьте контрольную сумму / отпечаток пальца ключа, используя альтернативный канал». Для параноика (и для записи) отпечаток github находится на help.github.com/articles/generating-ssh-keys, а битбакет упоминается в confluence.atlassian.com/display/BITBUCKET/…
sundar

1
@BenVoigt Да, я понимаю, что действительно параноик, конечно, попадет на эти страницы через другую, не связанную сеть, или, возможно, полетит в штаб-квартиру github и получит отпечатки пальцев лично :)
sundar

21

Допустим, вы встретили кого-то, чтобы обменяться секретами бизнеса. Ваш консультант говорит вам, что вы никогда не встречали этого человека раньше, и что он может быть самозванцем. Более того, на следующих встречах с ним ваш советник больше не будет вас предупреждать. Вот что означает сообщение. Этот человек является удаленным сервером, а ваш консультант - клиентом ssh.

Я не думаю, что параноидально перепроверять личность человека, прежде чем делиться с ней секретами. Например, вы можете открыть веб-страницу с ее изображением и сравнить ее с лицом перед вами. Или проверьте ее удостоверение личности.

Для сервера bitbucket вы можете использовать другой, более надежный компьютер, получить на нем изображение его лица , а затем сравнить его с тем, который вы получаете на компьютере, который вы сейчас используете. Использование:

 ssh-keyscan -t rsa bitbucket.org | ssh-keygen -lv -f -

Если лица совпадают, вы можете добавить ключ в файл, например ~/.ssh/known_hosts(стандартное расположение во многих дистрибутивах Linux) с помощью:

ssh-keyscan -t rsa -H bitbucket.org >> ~/.ssh/known_hosts

и клиент ssh не предупредит вас, поскольку он уже знает ее лицо . Он будет сравнивать лица каждый раз, когда вы подключаетесь. Это очень важно. В случае самозванца (например, атака «человек посередине») клиент ssh отклонит соединение, потому что лицо изменится.


Этот ответ очень полезен
010110110101

4
Это должен быть принятый ответ: ssh-keyscan -t rsa -H bitbucket.org >> ~/.ssh/known_hosts Спасибо, Иван!
Род

1
@Rod: Вы выбрали бы принятый ответ, основываясь на команде, которая совершенно не нужна (вы можете изменить known_hostsее, просто введя «да» к исходному предупреждению, как уже показано в вопросе) и опасную (ключ, который вы добавили к своему файл не обязательно тот, на который вы смотрели, потому что вы загрузили его дважды!)?
Бен Фойгт

@BenVoigt, что это решение обеспечивает, что ввод «да» не означает, что это решение полностью сценарием. Я предполагаю, что большинство людей могут понять, как реагировать на «(да / нет)?» незамедлительный. Я столкнулся с этими вопросами и ответами, пытаясь выяснить, как решить эту проблему без участия человека (для сценария настройки сервера). В моем волнении, я думаю, я не заметил, что вопрос ОП немного отличается от моего, но ИМО, это все еще самый полезный / неочевидный ответ в ветке.
Род

1
@ Род: Нет, это не полезно. Понижение вашей безопасности - это плохо. Поиск более быстрых способов понижения вашей безопасности является полной противоположностью полезного.
Бен Фойгт

5

Я просто должен был создать known_hostsтекстовый файл в~/.ssh

sudo vim ~/.ssh/known_hosts
sudo chmod 777 ~/.ssh/known_hosts

После этого он добавил хост, и я больше никогда не видел сообщения.


Я не думаю, что это действительно что-то меняет. Предупреждение отображается, когда сам сервер изменился. Например, если вы предоставляете новую виртуальную машину, к которой вы подключаетесь в первый раз. Независимо от того, есть ли у вас known_hostsфайл (с правильными разрешениями), он не мешает спрашивать вас о подлинности нового сервера ... Если вы каким-то образом уже не получили подпись ключа pub для этого сервера и не поместили его в свой файл known_hosts, что является единственным нормальным способом пропустить проверку (хотя просто сказать «да» проверке часто быстрее, чтобы достичь того же)
Стивен Лу

Благодарю. Я знал_хостов, но получал предупреждение. Мне просто нужно было изменить разрешения для known_hosts, чтобы предупреждения прекратились.
ArcaneDominion

6
Пожалуйста, не делай этого. Может быть серьезной угрозой безопасности. Ваш хост-файл должен быть доступен для записи только вам. Вторая команда в основном позволяет любому на вашем компьютере подделывать идентификационные данные сервера.
Штольц,

«Предупреждение отображается при изменении самого сервера». Или когда сервер никогда не посещался раньше.
Род

2

Есть еще один простой способ. Просто дотроньтесь до файла «config» в /root/.ssh и добавьте параметр StrictHostKeyChecking no. В следующий раз, когда вы войдете на сервер, ключ rsa будет добавлен к known_hosts и не будет спрашивать «да». для подтверждения подлинности


3
Это не рекомендуется. Это простой, но не правильный способ справиться с ситуацией.
Викас

1

Это сообщение является всего лишь SSH, сообщающим вам, что он никогда не видел этот конкретный ключ хоста, поэтому он не может по-настоящему проверить, что вы подключаетесь к хосту, который, как вы думаете, вы используете. Когда вы говорите «Да», он помещает ключ ssh в ваш файл known_hosts, а затем при последующих подключениях сравнивает ключ, который он получает от хоста, с ключом в файле known_hosts.

Была опубликована соответствующая статья о переполнении стека, показывающая, как отключить это предупреждение, https://stackoverflow.com/questions/3663895/ssh-the-authenticity-of-host-hostname-cant-be-established .


10
Но отключать предупреждение не рекомендуется - оно предназначено для предоставления очень полезной информации о безопасности.
Рори Олсоп

0

Помимо ответов, которые уже даны (ранее вы никогда не подключались к этому хосту), существует также явная вероятность того, что вы никогда ранее не подключались к текущему хосту (к этому хосту); это только психологически отличается; вы думаете, что подключаетесь с хоста A (к B), в то время как на самом деле вы пытаетесь подключиться с хоста X (к B). Это может произойти, например, когда вы сначала ssh-ed от A до X, а затем с того же терминала пытаетесь ssh-B, думая, что вы все еще на A.


Интересно, может ли использование пересылки агента ssh также подавить предупреждение, если хост A знает о B, а X нет, но переадресация агента происходит между A и X. Большинство сред (которые предоставляют ssh) и терминальные приложения поддерживают переадресацию агентов, это помогает Сократите количество ключей SSH, которыми вы должны управлять только для ваших конечных устройств.
Стивен Лу

0

В моем случае пароль без логина не работал из-за разрешений моего домашнего каталога, потому что я изменил настройки по умолчанию. Наконец, вот что сработало для меня. мой домашний каталог разрешений

/ Главная / имя пользователя

drwxr----x. 18 username     groupname  4096 May 11 11:52 username

/home/username/.ssh

268823097 drwx------   2 username groupname     29 May 11 11:53 .ssh

/home/username/.ssh/authorized_keys

-rw-r----- 1 username groupname 402 May 11 11:53 authorized_keys
Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.