Protocol error auth failed closing connection

Moderator: Project members

---

---

---

---

---

---

---

---

---

---

---

---

---

---

Помогите настроить rsync

Имеются 2 сервера: serv1 — ip 111.111.111.111 serv2 — ip 222.222.222.222

на serv1 запущен демон rsyncd

в конфиге прописан модуль copy

# rsyncd.conf — Example file, see rsyncd.conf(5) # # Set this if you want to stop rsync daemon with rc.d scripts

pid file = /var/run/rsyncd.pid

log file = /var/log/rsyncd.log

max connections = 1

use chroot = yes

comment = Copy files domen.name

hosts allow = 222.222.222.222

auth users = backup

secrets file = /root/rsycnd.scrt

в файле /root/rsycnd.scrt (root:wheel 0600)

с serv2 пытаюсь запустить синхронизацию

serv2# rsync backup@111.111.111.111::copy

@ERROR: auth failed on module copy

rsync error: error starting client-server protocol (code 5) at main.c(1506) [Receiver=3.0.7]

serv2# rsync 111.111.111.111::

copy Copy files domen.name

тоесть модуль видит, но почему то не проходит авторизация.

Подскажите чайнику.. что я сделал не так.. или чего не сделал ? Всячески пробовал изменять конфиг.. но все равно авторизация не проходит. Даже root пользователя пробовал прописывать в конфиг, но результат тот же.

rsync -zrtlhv —chmod=u=rw,Du+x,go= —progress —ignore-errors —delete —progress /home/server2/ rsync://backup@111.111.111.111/copy/

демон rsync не может попасть в каталог /root
перенеси секретный файл в другое место.

положил секретный файл в каталог /usr/local/etc/rsyncd.scrt

serv2# rsync -uvroght —password-file=/usr/local/etc/rsyncd.scrt backup@111.111.111.111::copy /home/domen/domen.name/

password file must not be other-accessible

continuing without password file

@ERROR: auth failed on module copy

rsync error: error starting client-server protocol (code 5) at main.c(1506) [Receiver=3.0.7]

Аналогично. Авторизация не проходит.

password file must not be other-accessible
[code]
ls -la /usr/local/etc/
[/code]
проверяй права и доступ

Источник

Устранение неполадок SSH: ошибки аутентификации

В первой статье этой серии вы узнали о том, как и в каких ситуациях вы можете попробовать исправить ошибки SSH. Остальные статьи расскажут, как определить и устранить ошибки:

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

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

Требования

• Убедитесь, что можете подключиться к виртуальному серверу через консоль.
• Проверьте панель на предмет текущих проблем, влияющих на работу и состояние сервера и гипервизора.

Основные ошибки

Отказ в доступе (парольная аутентификация)

Примечание: Если вы настроили на сервере SSH-ключи и отключили PasswordAuthentication, сервер не поддерживает паролей. Используйте SSH-ключ, чтобы подключиться к серверу.

Клиенты PuTTY и OpenSSH выдают такое сообщение:

root@111.111.111.111’s password:
Permission denied (publickey,password).
PuTTY Error output
root@111.111.111.111’s password:
Access denied
Server sent disconnect message
type 2 (protocol error):
«Too many authentication failures for root»

Это значит, что аутентификация прошла неудачно. Ошибка может быть вызвана рядом проблем. Вот несколько советов по устранению этой ошибки:

• Убедитесь, что вы используете правильное имя пользователя. В CoreOS используйте пользователя core. В FreeBSD используйте аккаунт пользователя freebsd.
• Парольная аутентификация пользователя может быть нарушена. Проверьте, поддерживает ли парольную аутентификацию веб-консоль сервера. Если она не поддерживает пароли, вам придется попытаться сбросить пароль или обратиться за помощью к службе поддержки, чтобы восстановить доступ.
• Убедитесь, что сервер поддерживает парольную аутентификацию.

Отказ в доступе (аутентификация на основе SSH-ключей)

Этот метод использует криптографические ключи для аутентификации пользователя.

Читайте также:

Вы можете получить такую ошибку:

Permission denied (publickey).
PuTTY Error output
Disconnected: No supported authentication methods available (server sent: publickey)

Многие наиболее распространенные проблемы, связанные с аутентификацией на основе ключей, вызваны неправильными правами доступа к файлам или правами собственности. Чтобы устранить проблему, попробуйте сделать следующее:

• Убедитесь, что файл authorized_keys и сам закрытый ключ имеют правильные права доступа и собственности.
• Убедитесь, что сервер поддерживает аутентификацию на основе ключей SSH.
• Убедитесь, что клиент SSH может получить закрытый ключ. Если вы используете PuTTY, убедитесь, что ключи SSH правильно настроены в сессии. Если вы используете OpenSSH, убедитесь, что у закрытого ключа SSH есть соответствующие привилегии.
• Убедитесь, что файл authorized_keys содержит правильный открытый ключ, и что открытый ключ добавлен на сервер.
• Возможно, вы используете закрытый ключ, который больше не поддерживается сервисом OpenSSH. Эта ошибка обычно затрагивает серверы OpenSSH 7+ при использовании закрытого DSA-ключа SSH. Обновите конфигурацию сервера.

Консоль не поддерживает пароли

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

В консоли появляется форма аутентификации:

Ubuntu 14.04.4 LTS server tty1
server Login:
Password:

Но после ввода пароля появляется ошибка:

После сброса пароля вы получите:

You are required to change your password immediately (root enforced)
Changing password for root.
(Current) UNIX Password:

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

При успешном завершении вам будет предложено дважды ввести новый пароль:

Enter new UNIX password:
Retype new UNIX password:

Однако если после повторного ввода правильного нового пароля сессия перезапустится (т.е. снова вернется форма для входа в систему) или появится сообщение об ошибке, это означает, что проблема в одном из файлов, в котором хранятся данные аутентификации.

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

Устранение неполадок

Проверка доступных методов аутентификации

Если вы используете подробный вывод или следите за логами SSH-клиента, убедитесь, что в сообщении, описывающем методы аутентификации, указаны password и/или publickey.

debug1: Authentications that can continue: publickey,password

Если вы не нашли в списке метод аутентификации, который хотите использовать, откройте файл /etc/ssh/sshd_config. В нём часто допускается ошибка: PasswordAuthentication имеет значение yes, а PermitRootLogin – no или without-password для пользователя root.

Исправьте эту ошибку, перезапустите сервис.

Настройка прав доступа и собственности

Сервер и клиент OpenSSH имеют строгие требования к привилегиям и правам собственности на файлы ключей.

Сервер и клиент OpenSSH должны иметь следующие права:

./ssh должен принадлежать текущему аккаунту.

/.ssh/authorized_keys должен принадлежать текущему аккаунту.

Кроме того, клиент должен также иметь такие права:

/ .ssh / config – 600.

Эти изменения можно внести с помощью консоли.

Проверка открытого и закрытого ключа

Если вы забыли, какой закрытый ключ соответствует тому или иному открытому ключу, инструменты OpenSSH и PuTTY помогут вам сгенерировать открытый ключ на основе зарытого ключа. Полученный результат вы можете сравнить с файлом

Чтобы восстановить открытый ключ на основе закрытого ключа в среде OpenSSH, используйте ssh-keygen и укажите путь к закрытому ключу.

/.ssh/id_rsa
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfBiMwCU1xoVVp0VbSYV3gTDV/jB57IHdILQ8kJ2622//Lmi4gDPlxA6HXVKq8odkGD/5MjqUw85X2rwEbhoBul74+LCToYJvvvBaDPCgg5z1icCKIJ1m/LJBrGNqPKCgqFWu0EH4/EFP2XIQqWqX1BZtJu/2YWrTr+xFOE/umoYmOd+t3dzQqMsv/2Aw+WmA/x/B9h+41WrobDgCExYNLPYcD0PO7fpsa8CcrZCo+TUWCe7MgQQCSM6WD4+PuYFpUWGw3ILTT51bOxoUhAo19U8B2QqxbMwZomzL1vIBhbUlbzyP/xgePTUhEXROTiTFx8W9yetDYLkfrQI8Q05+f

В среде PuTTY команда PuTTYgen.exe загружает интерфейс, в котором можно использовать опцию Load и импортировать закрытый ключ. PuTTY хранит такие файлы в формате .ppk (нужно знать место хранения файла).

Импортировав ключ, вы увидите окно с разделом Public key for pasting into OpenSSH authorized_keys file. В нём и будет искомый открытый ключ. Выделите текст и вставьте его в файл. Он сгенерирует открытый ключ.

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCfBiMwCU1xoVVp0VbSYV3gTDV/jB57IHdILQ8kJ2622//Lmi4gDPlxA6HXVKq8odkGD/5MjqUw85X2rwEbhoBul74+LCToYJvvvBaDPCgg5z1icCKIJ1m/LJBrGNqPKCgqFWu0EH4/EFP2XIQqWqX1BZtJu/2YWrTr+xFOE/umoYmOd+t3dzQqMsv/2Aw+WmA/x/B9h+41WrobDgCExYNLPYcD0PO7fpsa8CcrZCo+TUWCe7MgQQCSM6WD4+PuYFpUWGw3ILTT51bOxoUhAo19U8B2QqxbMwZomzL1vIBhbUlbzyP/xgePTUhEXROTiTFx8W9yetDYLkfrQI8Q05+f imported-openssh-key

Можно проигнорировать комментарий после открытого ключа (imported-openssh-key).

В любом случае этот открытый ключ нужно добавить в файл

OpenSSH 7 и устаревшие ключевые алгоритмы

В системах с OpenSSH 7 (FreeBSD и CoreOS по умолчанию) старые ключи DSA не поддерживаются.

Ключи ssh-dss считаются слабыми, вместо них рекомендуют использовать более надёжные современные алгоритмы.

Следовательно, в данном случае лучшим решением будет создать новые ключи и добавить их на хосты.

Однако в качестве обходного пути вы можете установить в PubkeyAcceptedKeyTypes значение +ssh-dss в файле /etc/ssh/sshd_config.

Заключение

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

Источник

FileZilla Forums

Welcome to the official discussion forums for FileZilla

Server restart — «Protocol error: Auth failed»

Server restart — «Protocol error: Auth failed»

#1 Post by JeremyP99 » 2010-03-08 21:11

Thanks to assistance from Peregate I was at last able to add a user login and password, and give them access to a folder. Transfer by a friend across the pond worked just fine. Restarted the server just now and got this message

Protocol error: Auth failed, closing connection.
Connection to server closed.

Shut it down, restarted the server service, restarted the server, and the same happens.

What happened? How do I fix this one?!

Re: Server restart — «Protocol error: Auth failed»

#2 Post by botg » 2010-03-08 22:38

Re: Server restart — «Protocol error: Auth failed»

#3 Post by JeremyP99 » 2010-03-09 08:47

I haven’t changed the password, and it was all working. Simply restarted the server. Now I can’t edit the settings, as the options are disabled, and the error message just repeats itself.

What to do? Start all over, again?!

Re: Server restart — «Protocol error: Auth failed»

#4 Post by botg » 2010-03-09 19:06

Re: Server restart — «Protocol error: Auth failed»

#5 Post by JeremyP99 » 2010-03-09 21:36

Yes, working again, seem to be flying on a wing and a prayer at the moment, but am sure it will all become clear
in the fullness of time. Success in that I’ve had some uploads.

Is there any guidance on what needs to be done in the Advanced Settings for the W7 firewall? I’m thinking of
the incoming rules. I have some set for Inbound Rules, have no idea whether they are necessary, but am loath
to fix something that isn’t broke.

Thanks a lot for your assistance, it’s much appreciated. This is a project I have been meaning to do for a few
years, but, life kept getting in the way, as it does.

Re: Server restart — «Protocol error: Auth failed»

#6 Post by botg » 2010-03-09 23:00

Re: Server restart — «Protocol error: Auth failed»

#7 Post by JeremyP99 » 2010-03-10 11:11

Yes — however, nothing is stated as to whether you need to create inbound rules for custom ports defined for passive transfers, and the info re adding a program is for XP, not the Windows 7 firewall; so it is rather hit and miss. For example, in order to make available my network shares, which I can’t make visible on the machine I am referring to here, I have replicated all settings onto the other machine, using port 21212 for ftp, and cannot make a connection at all! The Port Forward checker program tells me the port is open, but I just get a timeout from ftptest.net, and indeed, when invoked by a browser on the «main» machine.

The advanced setting for the Windows 7 firewall allows you to define from Program or Port; there is no indication as to which of these should be used; similarly, using Port, should this be bound to the Filezilla Server? I’m familiar with basic firewall config stuff for Unix boxes, but it is not clear to me how the Server Program should be added as a new Inbound rule to make things work.

Re: Server restart — «Protocol error: Auth failed»

#8 Post by Cypress » 2010-03-10 11:59

Re: Server restart — «Protocol error: Auth failed»

#9 Post by JeremyP99 » 2010-03-10 12:15

Re: Server restart — «Protocol error: Auth failed»

#10 Post by Cypress » 2010-03-10 12:39

Re: Server restart — «Protocol error: Auth failed»

#11 Post by JeremyP99 » 2010-03-10 12:47

Excellent, will try with just the automated server entry. As an side, I’m using ftptest.net to test access — and am being asked to log in every time I change directory. Is that normal? An option?

Many thanks for your advice!

Re: Server restart — «Protocol error: Auth failed»

#12 Post by JeremyP99 » 2010-03-10 12:47

Источник

• Главная

• Инструкции

• 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 использует для проверки подлинности пользователей.

API categories | API index

Network error

These constants are defined in the main cefpython module. They are for use with:

• LoadHandler.OnLoadError()
• WebRequestClient.OnError()
• RequestHandler.OnCertificateError()

For an up-to-date list of error codes see net_error_list.h in Chromium.

Table of contents:

• Constants
  • ERR_NONE
  • ERR_ABORTED
  • ERR_ACCESS_DENIED
  • ERR_ADDRESS_INVALID
  • ERR_ADDRESS_UNREACHABLE
  • ERR_CACHE_MISS
  • ERR_CERT_AUTHORITY_INVALID
  • ERR_CERT_COMMON_NAME_INVALID
  • ERR_CERT_CONTAINS_ERRORS
  • ERR_CERT_DATE_INVALID
  • ERR_CERT_END
  • ERR_CERT_INVALID
  • ERR_CERT_NO_REVOCATION_MECHANISM
  • ERR_CERT_REVOKED
  • ERR_CERT_UNABLE_TO_CHECK_REVOCATION
  • ERR_CONNECTION_ABORTED
  • ERR_CONNECTION_CLOSED
  • ERR_CONNECTION_FAILED
  • ERR_CONNECTION_REFUSED
  • ERR_CONNECTION_RESET
  • ERR_DISALLOWED_URL_SCHEME
  • ERR_EMPTY_RESPONSE
  • ERR_FAILED
  • ERR_FILE_NOT_FOUND
  • ERR_FILE_TOO_BIG
  • ERR_INSECURE_RESPONSE
  • ERR_INTERNET_DISCONNECTED
  • ERR_INVALID_ARGUMENT
  • ERR_INVALID_CHUNKED_ENCODING
  • ERR_INVALID_HANDLE
  • ERR_INVALID_RESPONSE
  • ERR_INVALID_URL
  • ERR_METHOD_NOT_SUPPORTED
  • ERR_NAME_NOT_RESOLVED
  • ERR_NO_SSL_VERSIONS_ENABLED
  • ERR_NOT_IMPLEMENTED
  • ERR_RESPONSE_HEADERS_TOO_BIG
  • ERR_SSL_CLIENT_AUTH_CERT_NEEDED
  • ERR_SSL_PROTOCOL_ERROR
  • ERR_SSL_RENEGOTIATION_REQUESTED
  • ERR_SSL_VERSION_OR_CIPHER_MISMATCH
  • ERR_TIMED_OUT
  • ERR_TOO_MANY_REDIRECTS
  • ERR_TUNNEL_CONNECTION_FAILED
  • ERR_UNEXPECTED
  • ERR_UNEXPECTED_PROXY_AUTH
  • ERR_UNKNOWN_URL_SCHEME
  • ERR_UNSAFE_PORT
  • ERR_UNSAFE_REDIRECT

Constants

ERR_NONE

No error.

ERR_ABORTED

An operation was aborted (due to user action).

ERR_ACCESS_DENIED

Permission to access a resource, other than the network, was denied.

ERR_ADDRESS_INVALID

The IP address or port number is invalid (e.g., cannot connect to the IP address 0 or the port 0).

ERR_ADDRESS_UNREACHABLE

The IP address is unreachable. This usually means that there is no route to the specified host or network.

ERR_CACHE_MISS

The cache does not have the requested entry.

ERR_CERT_AUTHORITY_INVALID

The server responded with a certificate that is signed by an authority
we don’t trust. That could mean:

1. An attacker has substituted the real certificate for a cert that contains his public key and is signed by his cousin.
2. The server operator has a legitimate certificate from a CA we don’t know about, but should trust.
3. The server is presenting a self-signed certificate, providing no defense against active attackers (but foiling passive attackers).

ERR_CERT_COMMON_NAME_INVALID

The server responded with a certificate whose common name did not match
the host name. This could mean:

1. An attacker has redirected our traffic to his server and is presenting a certificate for which he knows the private key.
2. The server is misconfigured and responding with the wrong cert.
3. The user is on a wireless network and is being redirected to the network’s login page.
4. The OS has used a DNS search suffix and the server doesn’t have a certificate for the abbreviated name in the address bar.

ERR_CERT_CONTAINS_ERRORS

The server responded with a certificate that contains errors.
This error is not recoverable. MSDN describes this error as follows:
«The SSL certificate contains errors.»
NOTE: It’s unclear how this differs from ERR_CERT_INVALID. For consistency,
use that code instead of this one from now on.

ERR_CERT_DATE_INVALID

The server responded with a certificate that, by our clock, appears to
either not yet be valid or to have expired. This could mean:

1. An attacker is presenting an old certificate for which he has managed to obtain the private key.
2. The server is misconfigured and is not presenting a valid cert.
3. Our clock is wrong.

ERR_CERT_END

The value immediately past the last certificate error code.

ERR_CERT_INVALID

The server responded with a certificate that is invalid.
This error is not recoverable.
MSDN describes this error as follows:
«The SSL certificate is invalid.»

ERR_CERT_NO_REVOCATION_MECHANISM

The certificate has no mechanism for determining if it is revoked. In
effect, this certificate cannot be revoked.

ERR_CERT_REVOKED

The server responded with a certificate has been revoked.
We have the capability to ignore this error, but it is probably not the
thing to do.

ERR_CERT_UNABLE_TO_CHECK_REVOCATION

Revocation information for the security certificate for this site is not
available. This could mean:

1. An attacker has compromised the private key in the certificate and is blocking our attempt to find out that the cert was revoked.
2. The certificate is unrevoked, but the revocation server is busy or unavailable.

ERR_CONNECTION_ABORTED

A connection timed out as a result of not receiving an ACK for data sent.
This can include a FIN packet that did not get ACK’d.

ERR_CONNECTION_CLOSED

A connection was closed (corresponding to a TCP FIN).

ERR_CONNECTION_FAILED

A connection attempt failed.

ERR_CONNECTION_REFUSED

A connection attempt was refused.

ERR_CONNECTION_RESET

A connection was reset (corresponding to a TCP RST).

ERR_DISALLOWED_URL_SCHEME

The scheme of the URL is disallowed.

ERR_EMPTY_RESPONSE

The server closed the connection without sending any data.

ERR_FAILED

A generic failure occurred.

ERR_FILE_NOT_FOUND

The file or directory cannot be found.

ERR_FILE_TOO_BIG

The file is too large.

ERR_INSECURE_RESPONSE

The server’s response was insecure (e.g. there was a cert error).

ERR_INTERNET_DISCONNECTED

The Internet connection has been lost.

ERR_INVALID_ARGUMENT

An argument to the function is incorrect.

ERR_INVALID_CHUNKED_ENCODING

Error in chunked transfer encoding.

ERR_INVALID_HANDLE

The handle or file descriptor is invalid.

ERR_INVALID_RESPONSE

The server’s response was invalid.

ERR_INVALID_URL

The URL is invalid.

ERR_METHOD_NOT_SUPPORTED

The server did not support the request method.

ERR_NAME_NOT_RESOLVED

The host name could not be resolved.

ERR_NO_SSL_VERSIONS_ENABLED

No SSL protocol versions are enabled.

ERR_NOT_IMPLEMENTED

The operation failed because of unimplemented functionality.

ERR_RESPONSE_HEADERS_TOO_BIG

The headers section of the response is too large.

ERR_SSL_CLIENT_AUTH_CERT_NEEDED

The server requested a client certificate for SSL client authentication.

ERR_SSL_PROTOCOL_ERROR

An SSL protocol error occurred.

ERR_SSL_RENEGOTIATION_REQUESTED

The server requested a renegotiation (rehandshake).

ERR_SSL_VERSION_OR_CIPHER_MISMATCH

The client and server don’t support a common SSL protocol version or
cipher suite.

ERR_TIMED_OUT

An operation timed out.

ERR_TOO_MANY_REDIRECTS

Attempting to load an URL resulted in too many redirects.

ERR_TUNNEL_CONNECTION_FAILED

A tunnel connection through the proxy could not be established.

ERR_UNEXPECTED

An unexpected error. This may be caused by a programming mistake or an
invalid assumption.

ERR_UNEXPECTED_PROXY_AUTH

The response was 407 (Proxy Authentication Required), yet we did not send
the request to a proxy.

ERR_UNKNOWN_URL_SCHEME

The scheme of the URL is unknown.

ERR_UNSAFE_PORT

Attempting to load an URL with an unsafe port number. These are port
numbers that correspond to services, which are not robust to spurious input
that may be constructed as a result of an allowed web construct (e.g., HTTP
looks a lot like SMTP, so form submission to port 25 is denied).

ERR_UNSAFE_REDIRECT

Attempting to load an URL resulted in an unsafe redirect (e.g., a redirect
to file:// is considered unsafe).

My company needs to upgrade an application to integrate two-legged OAuth 2.0 for POP3. I’m testing with an outlook online account and trying to authenticate on outlook.office365.com.

I registered for an Exchange Online trial using my test outlook account and I have tried testing with the Exchange email address as well (gives the same error).

I’ve registered my app on Azure and have enabled API Application Permissions for MS Graph (Mail.ReadWrite, Mail.Send) and Exchange (full_access_as_app). The same outlook account I used for the Exchange registration is the Global Admin of the Azure tenant.

I’m able to request a valid OAuth token from both the Graph and Exchange endpoints. However, when I use the token and try to log into the POP server, I get the following error:

<PopCmdResp>-ERR Protocol error. Connection is closed. 10</PopCmdResp>

Followed by:

<error>POP3 authentication failed</error>

I’m not sure what this error means. Does my mail component need to be set up to use a different protocol (not sure if this is possible)? Could this be an issue with the way my application is registered/authenticated or with the Exchange security settings?

The login works fine if I use Basic Auth instead of OAuth.

I’m not sure how to troubleshoot this. Any info or suggestions would be much appreciated!

EDIT

I recently stumbled across this Microsoft article that references the same error, but it’s related to Exchange Server 2007. The article says the solution is to increase the «MaxCommandSize» setting on the Exchange server from the default 40kb.

This is literally the only other place I’ve seen this error referenced online:

https://support.microsoft.com/en-ca/help/945552/error-message-when-you-try-to-connect-to-a-pop3-mailbox-on-exchange-se

I wonder if this is relevant for Exchange Online/Outlook? I’m unable to find a similar setting on my Exchange Online trial or Outlook mail settings

EDIT 2

{

"aud": "https://graph.microsoft.com",

"iss": "https://sts.windows.net/04669076-130f-49aa-b6b8-171a9e74b324/",

"iat": 1585688162,

"nbf": 1585688162,

"exp": 1585692062,

"aio": "42cAAh59R94bYs4Je0Kn290+uwUA",

"app_displayname": "Remindex",

"appid": "ad2ead7c-edb9-476f-8209-ecb29e1b7355",

"appidacr": "1",

"idp": "https://sts.windows.net/04669076-130f-49aa-b6b8-171a9e74b324/",

"oid": "0f7a5174-fcce-4752-ae07-ba8e64de467f",

"roles": [

"Mail.ReadWrite",

"Mail.Send"

],

"sub": "0f7a5174-fcce-4752-ae07-ba8e64de467f",

"tid": "04669076-130f-49aa-b6b8-171a9e74b324",

"uti": "gpIYvaSYikuDnd6CFQAnAA",

"ver": "1.0",

"xms_tcdt": 1585156686

}

Exchange Endpoint:

{

"aud": "https://outlook.office365.com",

"iss": "https://sts.windows.net/04669076-130f-49aa-b6b8-171a9e74b324/",

"iat": 1585688002,

"nbf": 1585688002,

"exp": 1585691902,

"aio": "42dgYNjxvn/mtBN+7zm3/vu4L0yyAgA=",

"app_displayname": "Remindex",

"appid": "ad2ead7c-edb9-476f-8209-ecb29e1b7355",

"appidacr": "1",

"idp": "https://sts.windows.net/04669076-130f-49aa-b6b8-171a9e74b324/",

"oid": "0f7a5174-fcce-4752-ae07-ba8e64de467f",

"roles": [

"full_access_as_app",

"Mail.ReadWrite",

"MailboxSettings.ReadWrite",

"Mail.Read",

"Mail.Send",

"MailboxSettings.Read"

],

"sid": "f4596631-bebc-4308-8b46-8ea14b842739",

"sub": "0f7a5174-fcce-4752-ae07-ba8e64de467f",

"tid": "04669076-130f-49aa-b6b8-171a9e74b324",

"uti": "0lyqmDTwPEqSeXwQYHUlAA",

"ver": "1.0"

}