Internet error the remote host did not pass authentication

&AtServer
Функция СтруктураURI(Знач СтрокаURI) Экспорт
   
   СтрокаURI = СокрЛП(СтрокаURI);
   
   // вообще говоря, не надо учитывать символы после #
   // но для упрощения примера игнорируем такие случаи
   
   // схема
   Схема = "";
   Позиция = Найти(СтрокаURI, "://");
   Если Позиция > 0 Тогда
      Схема = НРег(Лев(СтрокаURI, Позиция - 1));
      СтрокаURI = Сред(СтрокаURI, Позиция + 3);
   КонецЕсли;

   // строка соединения и путь на сервере
   СтрокаСоединения = СтрокаURI;
   ПутьНаСервере = "";
   Позиция = Найти(СтрокаСоединения, "/");
   Если Позиция > 0 Тогда
      ПутьНаСервере = Сред(СтрокаСоединения, Позиция + 1);
      СтрокаСоединения = Лев(СтрокаСоединения, Позиция - 1);
   КонецЕсли;
      
   // информация пользователя и имя сервера
   СтрокаАвторизации = "";
   ИмяСервера = СтрокаСоединения;
   Позиция = Найти(СтрокаСоединения, "@");
   Если Позиция > 0 Тогда
      СтрокаАвторизации = Лев(СтрокаСоединения, Позиция - 1);
      ИмяСервера = Сред(СтрокаСоединения, Позиция + 1);
   КонецЕсли;
   
   // логин и пароль
   Логин = СтрокаАвторизации;
   Пароль = "";
   Позиция = Найти(СтрокаАвторизации, ":");
   Если Позиция > 0 Тогда
      Логин = Лев(СтрокаАвторизации, Позиция - 1);
      Пароль = Сред(СтрокаАвторизации, Позиция + 1);
   КонецЕсли;
   
   // хост и порт
   Хост = ИмяСервера;
   Порт = "";
   Позиция = Найти(ИмяСервера, ":");
   Если Позиция > 0 Тогда
      Хост = Лев(ИмяСервера, Позиция - 1);
      Порт = Сред(ИмяСервера, Позиция + 1);
   КонецЕсли;
   
   Результат = Новый Структура;
   Результат.Вставить("Схема", Схема);
   Результат.Вставить("Логин", Логин);
   Результат.Вставить("Пароль", Пароль);
   Результат.Вставить("ИмяСервера", ИмяСервера);
   Результат.Вставить("Хост", Хост);
   Результат.Вставить("Порт", ?(Порт <> "", Число(Порт), Неопределено));
   Результат.Вставить("ПутьНаСервере", ПутьНаСервере);
   
   Возврат Результат;
   
КонецФункции

&AtServer
Function GetDataFromGoogle()
      
   Try
      ИмяСервера = "https://maps.googleapis.com/maps/api/directions/json?units=metric&origin=Hanoi,%20viet%20nam&destination=Thai%20binh,%20viet%20nam&waypoints=optimize:true|20.665111,%20105.916432&key=AIzaSyCkd8UTXHe7YDb-BUFQjQdtNBTT6TlWOv8";
      
      СтруктураURI = СтруктураURI(ИмяСервера);   
      HTTP = Новый HTTPСоединение(СтруктураURI.Хост,,,,,True);
      
      // Получим временный файл для передачи в теле POST запроса
      ФайлТелаЗапроса = ПолучитьИмяВременногоФайла();   
      ТекстФайл = Новый ТекстовыйДокумент;
      
      ////ТекстФайл.УстановитьТекст(Text);
      ТекстФайл.Записать(ФайлТелаЗапроса, КодировкаТекста.ANSI);
      
      // Получим размер данных для передачи в заголовок
      ФайлНаОтправку = Новый Файл(ФайлТелаЗапроса);
      РазмерФайлаНаОтправку = XMLСтрока(ФайлНаОтправку.Размер());
      
      // Получим временный файл — тело ответа POST запроса
      ФайлРезультат = ПолучитьИмяВременногоФайла();
      
      // Заголовок создадим в виде соответствия
      ЗаголовокЗапросаHTTP = Новый Соответствие();
      
      // Передаем в заголовках размер и тип данных на отправку
      ЗаголовокЗапросаHTTP.Вставить("Content-Length", РазмерФайлаНаОтправку);
      ЗаголовокЗапросаHTTP.Вставить("Content-Type", "application/json; charset=utf-8");
      // Отсылаем POST запрос на обработку.
      // СсылкаНаРесурс — ссылка на веб-сервер (страницу), к которой посылается POST запрос
      СсылкаНаРесурс = СтруктураURI.ПутьНаСервере;
      try
      HTTP.ОтправитьДляОбработки(ФайлТелаЗапроса, СсылкаНаРесурс, ФайлРезультат, ЗаголовокЗапросаHTTP);
      except
          Message(ErrorDescription());
      endtry;
      
      // Получим ответ
      ТекстовыйФайлОтвета = Новый ТекстовыйДокумент;
      ТекстовыйФайлОтвета.Прочитать(ФайлРезультат, КодировкаТекста.UTF8);
      СтрокаОтветаСервера = ТекстовыйФайлОтвета.ПолучитьТекст();
      
      чтениеJSON = Новый ЧтениеJSON;
      чтениеJSON.ОткрытьФайл(ФайлРезультат);
      массивСтруктур = ПрочитатьJSON(чтениеJSON);
   
      If массивСтруктур.status = "OK" AND массивСтруктур.rows[0].elements[0].status = "OK" Then
         Message("Distnace = " + массивСтруктур.rows[0].elements[0].distance.value/1000 + " km"); 
      EndIf;
   Except
      Message("Cannot connection with Google Map API services!");
   EndTry;           
   
EndFunction

A secure internet connection is not just the ideal — it’s essential. In fact, we’re going to go as far as saying it’s the number one priority for your website. The “Warning: Remote host identification has changed” error protects your connection from certain malicious attacks, although in some cases, you can inadvertently cause the error too.

The error is related to your Secure Shell (SSH) keys and the server “fingerprint” a client will check for. If Secure Shell thinks there’s an issue, it will block access to your server and throw an error. But you can fix this in a few steps.

Over the next few minutes, we’re going to show you how to fix the “Warning: Remote host identification has changed” error for both Windows and Mac. First, though, let’s give you some more details on the error message itself.

A secure internet connection is not just the ideal — it’s essential 💪 While it may be annoying, this error protects your connection from attacks. 🙅‍♀️ Learn more ⬇️Click to Tweet

What the “Warning: Remote Host Identification Has Changed” Error Is

One of the most secure ways to connect to a web server is to use SSH. It’s a command-line tool that lets you access an insecure network securely. Consider it like a “super-SFTP” type of setup, although it’s not a 1:1 comparison in practice.

You can access your site from almost anywhere you can use the internet, as long as you have the right login credentials. What’s more, most macOS and Linux machines have an SSH client built into the Operating System (OS). For Windows, you’ll use a dedicated interface (and we’ll talk about this in more detail later).

As for the “Warning: Remote host identification has changed” error, it relates to the security checks your client will do. An SSH connection uses dedicated “keys” — small files stored on your computer — as authentication. It’s sort of like a Secure Sockets Layers (SSL) handshake, and in fact, there are some high-level similarities between SSH and SSL.

One aspect the keys help with is to provide a permanent fingerprint of its host server. This will make sure the connection is accurate and that you’re not subject to a “machine-in-the-middle” attack.

If the client thinks those fingerprints differ from what it understands to be correct, you’ll get the “Warning: Remote host identification has changed” error at the point of login:

[[email protected] ~]$ ssh [email protected]

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!

Someone could be eavesdropping on you right now (man-in-the-middle attack)!

It is also possible that a host key has just been changed.

The fingerprint for the RSA key sent by the remote host is

xx:xx:xx.

Please contact your system administrator.

Add correct host key in /home/hostname /.ssh/known_hosts to get rid of this message.

Offending RSA key in /var/lib/sss/pubconf/known_hosts:4

RSA host key for user has changed and you have requested strict checking.

Host key verification failed.

As errors go, this is detailed and clear — it tells you what’s happened, a potential reason for why, and how you might fix it.

However, there’s one aspect we can touch on a little further before showing you how to fix the “Warning: Remote host identification has changed” error.

How the known_hosts File Helps SSH Authentication

You’ll notice that the error message references a known_hosts file. The name should give you a clue as to what it contains, but for clarity, it’s a list of SSH remote hosts known to the computer. It’s used as a reference client file for the authentication process.

When you first connect to a server, you’ll often get a confirmation request through your interface, asking whether you want to connect. If so, this fingerprint will become part of your known_hosts file.

Of course, if the fingerprint differs from what is in the known_hosts file, this could indicate a malicious user is targeting you. In other cases, you may already know why there’s a difference, although it pays to be vigilant regardless.

How To Fix the “Warning: Remote Host Identification Has Changed” Error (on Windows and Mac)

You can work to fix the “Warning: Remote host identification has changed” error for both Windows and macOS. However, you have more flexibility for doing so on Mac.

We’ll cover lots of the ways you can make things right again, starting with Windows.

1. Windows

It’s important to note that Windows machines might not have a known_hosts file. However, if you use the OpenSSH client, there is a file. To find it, open the Windows search bar, and navigate to your user folder with the %USERPROFILE% command.

This will open the directory within the File Explorer. There will also be a .ssh folder within:

The file we want in this folder is known_hosts. You can open this with Notepad (or your favorite text editor). Inside will be a list of keys:

Here, you can delete the key that’s causing the problem, then resave the file.

Some users may prefer the PuTTY client. The keys sit in the Registry, although they perform the same purpose as OpenSSH.

You’ll want to open the Windows Registry Editor (otherwise known as “regedit”). You can do this in whatever way you’re comfortable, but the quickest way is to type the app’s name into Window’s search bar:

Here, look for the following destination within regedit:

HKEY_CURRENT_USER/Software/SimonTatham/PuTTY/SshHostKeys/

You’ll see a list of entries here relating to the saved connections on your computer. Your job is to delete whichever one is causing an issue:

Once you click on the Delete button, you’ll also need to confirm that you want to remove the key:

Clicking Yes here means the key will be gone for good, and you shouldn’t get the “Warning: Remote host identification has changed” error any longer.

2. Mac

The Mac has a couple of ways to fix the “Warning: Remote host identification has changed” error — either through a premium app such as SSH Config Editor or the Terminal. The results will be the same, so we advise you to choose whichever option is more comfortable (and budget-friendly).

Our preferred approach is to access the file within a Terminal window (or iTerm2 if you use that app), and also open it with a dedicated Nano or Vim editor. This is because it’s accessible to everyone and straightforward to use regardless of your experience level.

Here, we’re going to use Nano. First, open your Terminal using whatever process is most comfortable:

From here, run the nano ~/.ssh/known_hosts command in your window. This will open a new Nano instance and display the keys within your known_hosts file:

You should delete the key causing the “Warning: Remote host identification has changed” error, then save your changes.

You might also want to delete the entire known_hosts file, especially if you only use SSH for one or two sites. To do this, you can run rm .ssh/known_hosts in a Terminal window.

There’s one more method to alter the known_hosts file on Mac: using the ssh-keygen utility from the command line. This is great if you don’t want to dig into the file itself, or if you want to work with only one site or key.

To achieve this, open a Terminal window and run ssh-keygen, followed by your server hostname. For example:

ssh-keygen -R server.example.com

This won’t ask you if you want to delete the specified lines, so make sure you’re removing the right ones before proceeding:

Once this is done, you shouldn’t get the “Warning: Remote host identification has changed” error from there on out.

Ever seen this error? 😅 It’s not always a bad thing (it’s protecting your connection from malicious attacks!), but it can be accidentally caused by your own activity. 😬 Learn more in this guide ⬇️Click to Tweet

Summary

Web security isn’t just about installing plugins and creating a strong password. The connections you use to log into servers need your utmost attention. If you don’t want to be subject to a machine-in-the-middle attack, you’ll want to use SSH access when you log in.

However, the system works almost too well. You may get the “Warning: Remote host identification has changed” error for a few reasons, and some are innocent.

Regardless, you can fix the error in no time through a Command Prompt or Terminal, using just a handful of commands.

Перейти к содержанию

$ ssh itsecforu@192.168.225.52

@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @ @
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:K/jEKNQCYYOilJxOZc7qAWlu4xu0nW+MD09DfJL7+gc.
Please contact your system administrator.
Add correct host key in /home/itsec/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /home/itsec/.ssh/known_hosts:11
  remove with:
  ssh-keygen -f "/home/itsec/.ssh/known_hosts" -R "192.168.225.52"
ECDSA host key for 192.168.225.52 has changed and you have requested strict checking.
Host key verification failed.

$ ssh-keygen -R 192.168.225.52

# Host 192.168.225.52 found: line 11
/home/itsec/.ssh/known_hosts updated.
Original contents retained as /home/itsec/.ssh/known_hosts.old

$ ssh-keygen -f "/home/itsec/.ssh/known_hosts" -R "192.168.225.52"

$ ssh-keygen -R 192.168.225.52:1234

$ ssh itsecforu@192.168.225.52

The authenticity of host '192.168.225.52 (192.168.225.52)' can't be established.
ECDSA key fingerprint is SHA256:K/jEKNQCYYOilJxOZc7qAWlu4xu0nW+MD09DfJL7+gc.
Are you sure you want to continue connecting (yes/no/[fingerprint])? yes
Warning: Permanently added '192.168.225.52' (ECDSA) to the list of known hosts.
itsecforu@192.168.225.52's password:

Я понимаю, конечно, что тут не жалобная книга, но я

представляю сколько админов, бухов и 1С-ников сейчас рвут волосы в самых разных местах и судорожно настраивают всякие костыли на серверах. А все банально из-за невнимательности, лени, и несоблюдения собственных стандартов разработки вендором.

Итак, имеем ошибку подключения к keydisk.ru вида «Не удалось получить обновления». Подорвали админов — мол сертификаты и все такое, поменяли — все равно не работает. Описывать дальнейшие танцы с бубном смысла нет — результат все тот же.

В итоге, нашли проблему, локализовали. Что ж, выполнение ЛЮБОГО из трех разных косяков не привело бы к таким печальным последствиям:

1. Разработчики Документооборота с контролирующими органами — огромный вам минус в карму за игнор требования п.3.4 #std499 Перехват исключений в коде в методе Обработка.ДокументооборотСКонтролирующимиОрганами.МодульОбъекта.ОбменССерверомСкачатьОбновление. Что мешает просто выкинуть текст исключения в ЖР?

2. Ответственные за адреса подключений к сервисам. Вы зачем указываете адрес схемы в http, а сам сервис при этом работает в https? Обработка.ДокументооборотСКонтролирующимиОрганами.Макет.ПараметрыСпецоператоровСвязи — колонка №5 Неужели добавление одной буквы в строку подключения настолько трудоемкая задача? Какая модель безопасности в 2022 вам позволяет скачивать контракт с сервисом через небезопасное соединение?

3. Разработчики БСП — в методе РегистрыСведений.КэшПрограммныхИнтерфейсов.ВнутренняяWSПрокси презюмируется, что адрес WSПрокси находится в той же схеме (http/https) что и WSОпределения (что по п.2 мы видим не всегда так). В итоге вызов любого метода WSПрокси падает с исключением «Internet error: The remote host did not pass authentication», а п.1 успешно прячет это исключение от пользователя и администратора.

russian

software

1c

• Главная

• Инструкции

• Linux

• Как исправить ошибку аутентификации SSH

Основные механизмы аутентификации пользователей при подключении через SSH — проверка пароля и сверка ключей. Их можно применять вместе или по отдельности, это настраивается в файле конфигурации SSH. Оба способа надежные, но иногда при их использовании можно столкнуться с ошибкой authentication failed. В этой статье разберемся, какие у этого сбоя могут быть причины и как их устранить.

В чем суть ошибки

У сообщения «authentication failed» перевод на русский предельно простой. Этот вывод в терминале говорит о том, что аутентификация пользователя не удалась.

Аутентификация — это проверка подлинности. Например, у вас есть сервер на cloud.timeweb.com. Вы настроили SSH для удаленного подключения. Чтобы система защиты вас пропустила, нужно пройти процедуру аутентификации – подтвердить, что это действительно вы. 

Метод проверки подлинности закреплен в конфигурационном файле SSH. По умолчанию это аутентификация по паролю. 

Другой вариант — использование пары SSH-ключей для проверки подлинности. В таком случае у пользователя на компьютере хранится закрытая часть ключа. На сервере располагается открытая часть. При попытке установить соединение эти части сравниваются. При совпадении доступ открывается. Если совпадения нет, появляется сообщение об ошибке — например, следующая ошибка SSH:

Permission denied (publickey)

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

Ниже разберемся с наиболее частыми ситуациями. 

Ошибка при использовании пароля

Обычно проблемы возникают из-за неверного имени пользователя или пароля. Также стоит обратить внимание на конфигурацию сервера — может стоять запрет на аутентификацию через пароль. Как это проверить:

1. Откройте файл конфигурации на сервере. Он находится по пути /etc/ssh/sshd_config.
2. Найдите строку PasswordAuthentication. По умолчанию у неё значение `yes`. Это значит, что проверка по паролю разрешена.
3. Если в вашем файле конфигурации параметр PasswordAuthentication имеет значение `no`, то подключиться по паролю не получится. Чтобы исправить ситуацию, измените значение на `yes`.

С паролем связано и появление ошибки su authentication failure. Вернее, с отсутствием парольной проверки у пользователя root. Если при такой конфигурации выполнить команду `su` без параметров, то вернется ошибка. Чтобы ее устранить, достаточно назначить пользователю root парольную защиту.

Ошибка при использовании ключей

Одна из самых распространенных проблем — использование не тех ключей при установке соединения. Часто это происходит, если с одного компьютера приходится подключаться к разным хостам. Самый простой способ не запутаться — давать понятные названия с указанием на то, для каких целей вы используете файлы аутентификации.

Использование большого количества ключей без явного указания нужного приводит еще к одной ошибке: 

Too many authentication failures for user

Причина сбоя — превышение числа попыток. Это случается из-за того, что SSH-клиент пытается подключиться к хосту, используя все доступные ключи. Исправить ситуацию можно с помощью опций IdentitiesOnly и IdentityFile. Пример запроса на подключение:

ssh -o IdentitiesOnly=yes 
    -o IdentityFile=id1.key 
    user@example.com

Чтобы каждый раз не прописывать это в командной строке при подключении, можно указать необходимую настройку в конфигурационном файле SSH ~/.ssh/config. Пример такой настройки:

Host 192.168.3.44
    IdentityFile ~/.ssh/id_rsa
Host *
    IdentitiesOnly=yes

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

При использовании ssh-ключей может возникнуть еще одна ошибка:

Permission denied (publickey, password)

Ее причиной может быть ввод неверной ключевой фразы. 

Если вы потеряете ключевую фразу, восстановить ее будет невозможно. Вам нужно будет сгенерировать новую пару значений для Secure Shell.

Восстановление открытого ключа

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

Самый просто способ — использовать утилиту ssh-keygen.

Запустите терминал и выполните команду:

ssh-keygen -y -f ~/.ssh/id_rsa

Здесь ~/.ssh/id_rsa — это путь к закрытому части, которая хранится на компьютере. В ответ вы получите последовательность символов. Это и есть открытая часть, которую необходимо добавить на сервер.

В среде Windows решить ту же задачу можно с помощью утилиты PuTTYgen, которая входит в набор PuTTY. В ней есть кнопка Load, через которую вы можете загрузить закрытый ключ. Для этого нужно лишь знать директорию, в которой он хранится на компьютере.

После импорта вы увидите окно с полем `Public key for…`. В нём отобразится открытая часть, которую можно скопировать и отправить на сервер.

Восстановить закрытую часть по открытой нельзя — это противоречит основам безопасности.

На что еще обратить внимание

У понятия «authentication failed» перевод дает весьма общее представление о причине сбоя. Проблема может крыться не только в пароле или ключах. Значение имеют также выставленные права доступа и алгоритмы шифрования.

Неправильная конфигурация клиента 

Распространенная ошибка — использование клиента SSH/SFTP (SSH, PuTTY, Filezilla) без правильной настройки всех необходимых параметров, таких как хост, порт, имя пользователя или закрытый ключ. 

Другая частая проблема возникает, когда вы используете неподдерживаемый сертификат. Например, пытаетесь добавить в PuTTY файл ключа *.pem вместо файла ключа *.ppk.

Противоречия в файле конфигурации

Убедитесь, что в файле /etc/ssh/sshd_config установлены параметры, которые не противоречат друг другу. Такое может быть, например, при отключении парольной проверки или запрете на подключение для пользователя root.

Распространенный пример конфликта: у параметра PasswordAuthentication установлено значение `yes`, а у параметра PermitRootLogin — значение `no` или `without-password`. Из-за этого сервер не понимает, как проверять пользователей, и не пускает никого.

Настройка прав доступа

У OpenSSH строгие правила к тому, кто должен быть владельцем файлов и какие на них должны быть выставлены права доступа.

Убедитесь, что на сервере выставлены следующие доступы:

• ~./ssh – 700.
• ~./ssh принадлежит текущему аккаунту.
• ~/.ssh/authorized_keys – 600.
• ~/.ssh/authorized_keys принадлежит текущему аккаунту.

На клиенте также проверьте разрешения следующих файлов:

• ~ / .ssh / config – 600.
• ~ / .ssh / id_ * – 600.

Почему важен владелец? Например, вы настраивали доступ через Secure Shell от имени одного пользователя, а затем пытаетесь подключиться под другим аккаунтом, у которого нет прав даже на чтение содержимого защищенных директорий с аутентификационными данными.

Использование устаревших алгоритмов

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

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

Есть и альтернатива, но пользоваться ей придется на свой страх и риск. Речь идет об изменении файла конфигурации /etc/ssh/sshd_config. Если установить параметру PubkeyAcceptedKeyTypes значение `+ssh-dss`, то можно будет использовать ключи, сгенерированные с помощью устаревшего алгоритма цифровой подписи.

Дополнительные опции могут понадобиться и на SSH-клиенте. Например, при подключении к серверу с ПО, которое давно не обновлялось. В частности, такие проблемы возникают при подключении к хостам на CentOS 6, поддержка которой прекращена в конце 2020 года. Чтобы исправить эту ошибку, необходимо добавить опцию `-oHostKeyAlgorithms=+ssh-dss`:

 ssh -oHostKeyAlgorithms=+ssh-dss user@legacyhost

Ошибки на сторонних сервисах

Проблемы аутентификации могут возникать и при использовании сторонних сервисов. Например, при подключении к VK API пользователи сталкиваются с сообщением user authorization failed invalid session. Устранить такой сбой самостоятельно не получится — нужно обращаться в поддержку.

Заключение

Причина ошибки аутентификации может быть как на стороне клиента, так и на стороне сервера. Начинайте диагностику с самого простого: проверьте правильность имени пользователя и пароля, если он используется, выбор SSH-ключа в агенте. Если это не помогает устранить сбой, проверьте конфигурацию подключения и права доступа к файлам, которые OpenSSH использует для проверки подлинности пользователей.