Содержание
- Как исправить ошибку аутентификации SSH
- В чем суть ошибки
- Ошибка при использовании пароля
- Ошибка при использовании ключей
- Восстановление открытого ключа
- На что еще обратить внимание
- Неправильная конфигурация клиента
- Противоречия в файле конфигурации
- Настройка прав доступа
- Использование устаревших алгоритмов
- Ошибки на сторонних сервисах
- Заключение
- Как исправить ошибку cURL 28: время ожидания соединения истекло
Как исправить ошибку аутентификации SSH
Основные механизмы аутентификации пользователей при подключении через SSH — проверка пароля и сверка ключей. Их можно применять вместе или по отдельности, это настраивается в файле конфигурации SSH. Оба способа надежные, но иногда при их использовании можно столкнуться с ошибкой authentication failed. В этой статье разберемся, какие у этого сбоя могут быть причины и как их устранить.
В чем суть ошибки
У сообщения «authentication failed» перевод на русский предельно простой. Этот вывод в терминале говорит о том, что аутентификация пользователя не удалась.
Аутентификация — это проверка подлинности. Например, у вас есть сервер на cloud.timeweb.com . Вы настроили SSH для удаленного подключения. Чтобы система защиты вас пропустила, нужно пройти процедуру аутентификации – подтвердить, что это действительно вы.
Метод проверки подлинности закреплен в конфигурационном файле SSH. По умолчанию это аутентификация по паролю.
Другой вариант — использование пары SSH-ключей для проверки подлинности. В таком случае у пользователя на компьютере хранится закрытая часть ключа. На сервере располагается открытая часть. При попытке установить соединение эти части сравниваются. При совпадении доступ открывается. Если совпадения нет, появляется сообщение об ошибке — например, следующая ошибка SSH:
Но причины появления ошибки не ограничиваются только неправильным паролем или не теми ключами. Сбой может возникать также из-за повреждения системных файлов или неверно выставленных прав доступа.
Ниже разберемся с наиболее частыми ситуациями.
Ошибка при использовании пароля
Обычно проблемы возникают из-за неверного имени пользователя или пароля. Также стоит обратить внимание на конфигурацию сервера — может стоять запрет на аутентификацию через пароль. Как это проверить:
- Откройте файл конфигурации на сервере. Он находится по пути /etc/ssh/sshd_config.
- Найдите строку PasswordAuthentication. По умолчанию у неё значение `yes`. Это значит, что проверка по паролю разрешена.
- Если в вашем файле конфигурации параметр PasswordAuthentication имеет значение `no`, то подключиться по паролю не получится. Чтобы исправить ситуацию, измените значение на `yes`.
С паролем связано и появление ошибки su authentication failure. Вернее, с отсутствием парольной проверки у пользователя root. Если при такой конфигурации выполнить команду `su` без параметров, то вернется ошибка. Чтобы ее устранить, достаточно назначить пользователю root парольную защиту.
Ошибка при использовании ключей
Одна из самых распространенных проблем — использование не тех ключей при установке соединения. Часто это происходит, если с одного компьютера приходится подключаться к разным хостам. Самый простой способ не запутаться — давать понятные названия с указанием на то, для каких целей вы используете файлы аутентификации.
Использование большого количества ключей без явного указания нужного приводит еще к одной ошибке:
Причина сбоя — превышение числа попыток. Это случается из-за того, что SSH-клиент пытается подключиться к хосту, используя все доступные ключи. Исправить ситуацию можно с помощью опций IdentitiesOnly и IdentityFile. Пример запроса на подключение:
Чтобы каждый раз не прописывать это в командной строке при подключении, можно указать необходимую настройку в конфигурационном файле SSH
/.ssh/config. Пример такой настройки:
В этом случае SSH будет использовать только идентификаторы, указанные в файлах ssh_config, плюс идентификатор, указанный в командной строке. Идентификаторы, предоставленные агентом, будут игнорироваться.
При использовании ssh-ключей может возникнуть еще одна ошибка:
Ее причиной может быть ввод неверной ключевой фразы.
Если вы потеряете ключевую фразу, восстановить ее будет невозможно. Вам нужно будет сгенерировать новую пару значений для Secure Shell.
Восстановление открытого ключа
Если у вас есть закрытый ключ, но вы потеряли открытую часть, то эту проблему можно решить стандартными средствами OpenSSH.
Самый просто способ — использовать утилиту ssh-keygen.
Запустите терминал и выполните команду:
/.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 принадлежит текущему аккаунту.
/.ssh/authorized_keys принадлежит текущему аккаунту.
На клиенте также проверьте разрешения следующих файлов:
/ .ssh / config – 600.
Почему важен владелец? Например, вы настраивали доступ через Secure Shell от имени одного пользователя, а затем пытаетесь подключиться под другим аккаунтом, у которого нет прав даже на чтение содержимого защищенных директорий с аутентификационными данными.
Использование устаревших алгоритмов
В OpenSSH начиная с седьмой версии не поддерживаются старые ключи, которые используют алгоритм цифровой подписи — DSA. Ключи ssh-dss считаются слишком слабыми для того, чтобы можно было доверять им защиту подключения к серверу.
Если у вас старые ключи, оптимальное решение — сгенерировать и добавить на хосты новые, которые основаны на более стойких алгоритмах.
Есть и альтернатива, но пользоваться ей придется на свой страх и риск. Речь идет об изменении файла конфигурации /etc/ssh/sshd_config. Если установить параметру PubkeyAcceptedKeyTypes значение `+ssh-dss`, то можно будет использовать ключи, сгенерированные с помощью устаревшего алгоритма цифровой подписи.
Дополнительные опции могут понадобиться и на SSH-клиенте. Например, при подключении к серверу с ПО, которое давно не обновлялось. В частности, такие проблемы возникают при подключении к хостам на CentOS 6, поддержка которой прекращена в конце 2020 года. Чтобы исправить эту ошибку, необходимо добавить опцию `-oHostKeyAlgorithms=+ssh-dss`:
Ошибки на сторонних сервисах
Проблемы аутентификации могут возникать и при использовании сторонних сервисов. Например, при подключении к VK API пользователи сталкиваются с сообщением user authorization failed invalid session . Устранить такой сбой самостоятельно не получится — нужно обращаться в поддержку.
Заключение
Причина ошибки аутентификации может быть как на стороне клиента, так и на стороне сервера. Начинайте диагностику с самого простого: проверьте правильность имени пользователя и пароля, если он используется, выбор SSH-ключа в агенте. Если это не помогает устранить сбой, проверьте конфигурацию подключения и права доступа к файлам, которые OpenSSH использует для проверки подлинности пользователей.
Источник
Как исправить ошибку cURL 28: время ожидания соединения истекло
Приветствуем вас! Вы видите ошибку cURL 28: Превышено время ожидания соединения на вашем сайте WordPress? Ошибка cURL 28 — распространенная проблема WordPress REST API, которая может повлиять на производительность вашего веб-сайта и привести к его непредсказуемому поведению.
В этой статье мы покажем вам, как легко исправить проблему cURL error 28 на вашем веб-сайте WordPress.
Что такое cURL в WordPress?
CURL — это программная утилита, используемая WordPress и многими другими веб-приложениями для отправки и получения запросов данных с использованием URL-адресов.
WordPress использует cURL для обработки нескольких запросов API. Он доступен как расширение языка программирования PHP, и ваша хостинговая компания WordPress позаботится об этом.
Библиотека cURL играет решающую роль в том, как WordPress работает за кулисами. Если он не настроен должным образом, ваш веб-сайт не будет работать должным образом.
Что вызывает ошибку cURL 28 в WordPress?
Неспособность своевременно ответить на запросы данных сервера вызывает ошибку 28 cURL в WordPress.
WordPress использует REST API (метод программирования) для отправки и получения запросов данных. Если время ожидания этих запросов истекло, вы увидите это как критическую проблему в отчете о работоспособности сайта с заголовком «Ошибка REST API» .
Расширение ошибки покажет вам дополнительную информацию, включая сообщение об ошибке:
Error: cURL error 28: Operation timed out after x milliseconds with x bytes received (http_request_failed)
Вы также можете увидеть другую связанную проблему с заголовком «Ваш сайт не может выполнить запрос обратной связи» . В нем будет аналогичное сообщение об ошибке со следующим описанием.
«Запрос обратной связи к вашему сайту не удался, это означает, что функции, использующие их, в настоящее время не работают должным образом».
Что может вызвать тайм-аут cURL?
Ряд сценариев может вызвать тайм-аут cURL в WordPress:
- Например, плагин брандмауэра WordPress может блокировать запрос REST API, считая его подозрительным действием.
- Если ваш DNS-сервер работает некорректно, это также может вызвать сбой HTTP-запросов и вызвать ошибку тайм-аута cURL в WordPress.
- Плохо настроенный хостинг-сервер может просто иметь очень низкий порог тайм-аута, что может помешать правильной работе определенных процессов WordPress.
Давайте посмотрим, как устранить и исправить данную проблему.
1. Временно отключите брандмауэр WordPress
Если вы используете брандмауэр WordPress или плагин безопасности, временно отключите его.
После этого вам нужно посетить страницу отчета о работоспособности сайта WordPress, чтобы узнать, решена ли ваша проблема.
Если да, то вам нужно проверить журналы брандмауэра WordPress, чтобы узнать, какие запросы API были заблокированы. Это либо определит источник проблемы, либо вы можете настроить параметры брандмауэра, чтобы не блокировать законные запросы API.
2. Отключите все плагины WordPress
Плагины WordPress создают собственные запросы API для отправки и получения данных. Если эти вызовы слишком часты или для выполнения требуется слишком много времени, это может вызвать ошибку cURL в отчете о работоспособности вашего сайта.
Самый простой способ выяснить это — отключить все плагины WordPress. Просто перейдите на страницу «Плагины»-«Установленные» и выберите все плагины.
После этого щелкните раскрывающееся меню «Массовые действия» , чтобы выбрать «Деактивировать» , а затем нажмите кнопку «Применить» .
Теперь вы можете посетить отчет о работоспособности сайта, чтобы узнать, исчезла ли проблема. Если это устранило проблему, вы можете активировать свои плагины один за другим, пока проблема не появится снова.
Это поможет вам найти плагин, который может вызывать проблему.
3. Убедитесь, что ваш хостинг-сервер использует новейшее программное обеспечение
Следующий шаг — убедиться, что ваш хостинг-сервер WordPress использует последние версии PHP, библиотеки cURL и OpenSSL.
Вы можете проверить это, просмотрев вкладку системной информации на странице «Инструменты»-«Здоровье сайта» .
Просто перейдите на вкладку «Информация» и разверните раздел «Сервер» . Отсюда вы можете получить информацию о программном обеспечении, установленном на вашем хостинг-сервере WordPress.
В идеале ваш сервер должен использовать PHP 7.4.13 или выше, curl 7.74.0 или выше и OpenSSL 1.1.1 или выше.
Если это не так, вам необходимо связаться с вашей хостинговой компанией и попросить их обновить программное обеспечение для вашей учетной записи хостинга.
4. Устранение проблем с небезопасным контентом SSL
Если ваш сайт использует HTTPS / SSL, но он не настроен должным образом, это также может привести к тому, что ваш веб-сервер заблокирует небезопасные запросы cURL.
Точно так же, если ваш веб-сайт не использует HTTPS / SSL, но он сделал вызов API с использованием URL-адреса HTTP, то эти запросы тоже не будут выполнены, и вместо этого вы можете увидеть следующую ошибку cURL:
Ошибка: ошибка cURL 7: не удалось подключиться к порту localhost 443: в соединении отказано (http_request_failed)
Чтобы исправить это, вы можете попросить своего хостинг-провайдера переустановить сертификат SSL для вашего сайта.
5. Обратитесь за помощью к поставщику услуг хостинга
Если описанные выше действия не помогли устранить ошибку cURL 28 то, проблема, скорее всего, связана с средой хостинга.
Есть много факторов, которые могут контролироваться и исправляться только вашей хостинговой компанией. Например, если их DNS-серверы не могут своевременно разрешать запросы, это приведет к тайм-ауту запросов cURL.
Другой сценарий может заключаться в более медленном подключении или сетевых проблемах с вашим хост-сервером.
Просто отправьте им запрос в службу поддержки с подробными сведениями об ошибке, и их технический персонал сможет устранить неполадки и применить исправление для ее решения. Ну что, у нас на этом все. Всем пока!
Источник
-
Главная
-
Инструкции
-
Linux
-
Как исправить ошибку аутентификации SSH
Основные механизмы аутентификации пользователей при подключении через SSH — проверка пароля и сверка ключей. Их можно применять вместе или по отдельности, это настраивается в файле конфигурации SSH. Оба способа надежные, но иногда при их использовании можно столкнуться с ошибкой authentication failed. В этой статье разберемся, какие у этого сбоя могут быть причины и как их устранить.
В чем суть ошибки
У сообщения «authentication failed» перевод на русский предельно простой. Этот вывод в терминале говорит о том, что аутентификация пользователя не удалась.
Аутентификация — это проверка подлинности. Например, у вас есть сервер на cloud.timeweb.com. Вы настроили SSH для удаленного подключения. Чтобы система защиты вас пропустила, нужно пройти процедуру аутентификации – подтвердить, что это действительно вы.
Метод проверки подлинности закреплен в конфигурационном файле SSH. По умолчанию это аутентификация по паролю.
Другой вариант — использование пары SSH-ключей для проверки подлинности. В таком случае у пользователя на компьютере хранится закрытая часть ключа. На сервере располагается открытая часть. При попытке установить соединение эти части сравниваются. При совпадении доступ открывается. Если совпадения нет, появляется сообщение об ошибке — например, следующая ошибка SSH:
Permission denied (publickey)Но причины появления ошибки не ограничиваются только неправильным паролем или не теми ключами. Сбой может возникать также из-за повреждения системных файлов или неверно выставленных прав доступа.
Ниже разберемся с наиболее частыми ситуациями.
Ошибка при использовании пароля
Обычно проблемы возникают из-за неверного имени пользователя или пароля. Также стоит обратить внимание на конфигурацию сервера — может стоять запрет на аутентификацию через пароль. Как это проверить:
- Откройте файл конфигурации на сервере. Он находится по пути /etc/ssh/sshd_config.
- Найдите строку PasswordAuthentication. По умолчанию у неё значение `yes`. Это значит, что проверка по паролю разрешена.
- Если в вашем файле конфигурации параметр 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 использует для проверки подлинности пользователей.
IPsec VPN через Strongswan: ошибка авторизации
Пробую поднять IPsec IKEv2 VPN, на обоих концах Strongswan, авторизация через сертификаты X.509. При подключении приходит отлуп с AUTH_FAILED на IKE_AUTH request 1. Со стороны сервера CA сертификат подгружается нормально, в логах нет явных сообщений про неизвестные сертификаты.
Как это всё пофиксить? IPsec настраиваю второй раз, мб что-то простое пропустил.
Ниже 1.2.3.4 – внешний IP сервера, 5.6.7.8 – внешний IP клиента, 192.168.0.2 – внутренний IP клиента, 192.168.0.100 – внутренний IP сервера.
edit: добавил лог с сервера
Хм, а так можно было оказывается.
Покажите лог с сервера.
Хм, а так можно было оказывается.
Забыл сразу добавить, отредактировал пост.
Та я как-то привык к ipsec.conf
От оно:
server charon[994]: 15[CFG] no matching peer config found
Не совсем понял, это для клиента указать? А куда тогда адрес сервера вбивать?
Если для клиента, то это вроде дефолт для swanctl-стиля (я так понимаю, что left и right соответствуют connections. .local_addrs и connections. .remote_addrs ). Я практически без изменений брал конфиг с официальной вики (Roadwarrior scenario → swanctl.conf).
Я предполагал, что это в порядке вещей, т.к. айпи клиента неизвестен, так что конфиг пира генерируется. Видимо, это не так. Как тогда быть? Получается, надо каким-то образом на сервере указать, чтобы принимался ID типа CN=client ?
Почти. Ему надо на основании «чего-то» решить, что вот этот кусок конфига относиться к этому клиенту. Но наискосок в мане чего-то аналогичного leftid | rightid в ipsec.conf и keyexchange не обнаружил. 🙁
Это для сервера.
В swanctl.conf можно указать connections. .remote.id , похоже, он работает как rightid для ipsec.conf . Пробовал указывать конкретный id клиента, но увы, всё та же ошибка.
Видимо, попробую переписать серверный конфиг в ipsec.conf-стиле: я как раз думал, что все уже много лет назад пересели на swanctl, а вот оно что.
попробую переписать серверный конфиг в ipsec.conf-стиле
На всякий случай кусок из моего ipsec.conf
я как раз думал, что все уже много лет назад пересели на swanctl
Точно не все 🙂 Я последний раз правил ipsec.conf всего два дня назад 🙂 И пока его не выпилят окончательно, менять конфиги желания ровно ноль. У меня там достаточно секций под разные соединения, пусть не всё уже нужно, но мало ли.
Спасибо! Правда, мне по идее смысла матчить так нет: CA тестовый, поэтому я заполнил только CN и SAN. А для продакшена, конечно, полезно по OU фильтровать.
Кроме того, я переписал почти один в один серверный конфиг:
И, о чудо, авторизация заработала. Видимо, этот swanctl это какая-то сырая (несмотря на заверения в официальных доках) штука.
А для продакшена, конечно, полезно по OU фильтровать.
Для себя любимого тоже полезно. Я в OU фильтрую по разным реализациям клиентов. Например для blackbery одно, для mac os x другое и т.д.
Видимо, этот swanctl это какая-то сырая (несмотря на заверения в официальных доках) штука.
Может и так. А может документацию не дописали. 😉
Я в OU фильтрую по разным реализациям клиентов.
Отличная идея, не думал о таком варианте.
Ага. Сама проблема в том, что это в лебеде вы можете настроить усе что угодно, а готовые реализации клиентов зачастую содержат захардкоженные наборы параметров. macOS одно, офтопик другое и т.д. Вот и приходиться под них подстраиваться.
Как оказалось, я просто невнимательно читал доки, а решение вполне есть. Разгадка в том, что при ipsec.conf-стиле с обоих сторон клиент отправляет ID сервера по дефолту в виде его IP, а сервер принимает всё. В случае с swanctl, сервер ожидает ID в виде DN его сертификата, что в чем-то более логично. swanctl-клиент также отправит ID сервера как DN серверного сертификата, полученного в результате предыдущего запроса.
Таким образом, если хочется оставить swanctl на сервере и ipsec.conf на клиенте (оригинальная задача), то достаточно на клиенте добавить rightid=»CN=1.2.3.4″ ( 1.2.3.4 – IP сервера). Или можно воспользоваться недокументированной особенностью и прописать local.id = %any на сервере. При использовании swanctl с обоих сторон специально прописывать local.id и remote.id не нужно.
Со своей стороны я решил использовать ipsec.conf с обоих сторон, т.к. swanctl выглядит гибче (мне это пока ненужно), но геморнее (например, убунтовый AppArmor по дефолту режет swanctl так, что он не загружает никаких соединений на старте системы, нужно руками делать —load-all ).
anc если вдруг интересно
Источник
Как исправить ошибку cURL 28: время ожидания соединения истекло
Приветствуем вас! Вы видите ошибку cURL 28: Превышено время ожидания соединения на вашем сайте WordPress? Ошибка cURL 28 — распространенная проблема WordPress REST API, которая может повлиять на производительность вашего веб-сайта и привести к его непредсказуемому поведению.
В этой статье мы покажем вам, как легко исправить проблему cURL error 28 на вашем веб-сайте WordPress.
Что такое cURL в WordPress?
CURL — это программная утилита, используемая WordPress и многими другими веб-приложениями для отправки и получения запросов данных с использованием URL-адресов.
WordPress использует cURL для обработки нескольких запросов API. Он доступен как расширение языка программирования PHP, и ваша хостинговая компания WordPress позаботится об этом.
Библиотека cURL играет решающую роль в том, как WordPress работает за кулисами. Если он не настроен должным образом, ваш веб-сайт не будет работать должным образом.
Что вызывает ошибку cURL 28 в WordPress?
Неспособность своевременно ответить на запросы данных сервера вызывает ошибку 28 cURL в WordPress.
WordPress использует REST API (метод программирования) для отправки и получения запросов данных. Если время ожидания этих запросов истекло, вы увидите это как критическую проблему в отчете о работоспособности сайта с заголовком «Ошибка REST API» .
Расширение ошибки покажет вам дополнительную информацию, включая сообщение об ошибке:
Error: cURL error 28: Operation timed out after x milliseconds with x bytes received (http_request_failed)
Вы также можете увидеть другую связанную проблему с заголовком «Ваш сайт не может выполнить запрос обратной связи» . В нем будет аналогичное сообщение об ошибке со следующим описанием.
«Запрос обратной связи к вашему сайту не удался, это означает, что функции, использующие их, в настоящее время не работают должным образом».
Что может вызвать тайм-аут cURL?
Ряд сценариев может вызвать тайм-аут cURL в WordPress:
- Например, плагин брандмауэра WordPress может блокировать запрос REST API, считая его подозрительным действием.
- Если ваш DNS-сервер работает некорректно, это также может вызвать сбой HTTP-запросов и вызвать ошибку тайм-аута cURL в WordPress.
- Плохо настроенный хостинг-сервер может просто иметь очень низкий порог тайм-аута, что может помешать правильной работе определенных процессов WordPress.
Давайте посмотрим, как устранить и исправить данную проблему.
1. Временно отключите брандмауэр WordPress
Если вы используете брандмауэр WordPress или плагин безопасности, временно отключите его.
После этого вам нужно посетить страницу отчета о работоспособности сайта WordPress, чтобы узнать, решена ли ваша проблема.
Если да, то вам нужно проверить журналы брандмауэра WordPress, чтобы узнать, какие запросы API были заблокированы. Это либо определит источник проблемы, либо вы можете настроить параметры брандмауэра, чтобы не блокировать законные запросы API.
2. Отключите все плагины WordPress
Плагины WordPress создают собственные запросы API для отправки и получения данных. Если эти вызовы слишком часты или для выполнения требуется слишком много времени, это может вызвать ошибку cURL в отчете о работоспособности вашего сайта.
Самый простой способ выяснить это — отключить все плагины WordPress. Просто перейдите на страницу «Плагины»-«Установленные» и выберите все плагины.
После этого щелкните раскрывающееся меню «Массовые действия» , чтобы выбрать «Деактивировать» , а затем нажмите кнопку «Применить» .
Теперь вы можете посетить отчет о работоспособности сайта, чтобы узнать, исчезла ли проблема. Если это устранило проблему, вы можете активировать свои плагины один за другим, пока проблема не появится снова.
Это поможет вам найти плагин, который может вызывать проблему.
3. Убедитесь, что ваш хостинг-сервер использует новейшее программное обеспечение
Следующий шаг — убедиться, что ваш хостинг-сервер WordPress использует последние версии PHP, библиотеки cURL и OpenSSL.
Вы можете проверить это, просмотрев вкладку системной информации на странице «Инструменты»-«Здоровье сайта» .
Просто перейдите на вкладку «Информация» и разверните раздел «Сервер» . Отсюда вы можете получить информацию о программном обеспечении, установленном на вашем хостинг-сервере WordPress.
В идеале ваш сервер должен использовать PHP 7.4.13 или выше, curl 7.74.0 или выше и OpenSSL 1.1.1 или выше.
Если это не так, вам необходимо связаться с вашей хостинговой компанией и попросить их обновить программное обеспечение для вашей учетной записи хостинга.
4. Устранение проблем с небезопасным контентом SSL
Если ваш сайт использует HTTPS / SSL, но он не настроен должным образом, это также может привести к тому, что ваш веб-сервер заблокирует небезопасные запросы cURL.
Точно так же, если ваш веб-сайт не использует HTTPS / SSL, но он сделал вызов API с использованием URL-адреса HTTP, то эти запросы тоже не будут выполнены, и вместо этого вы можете увидеть следующую ошибку cURL:
Ошибка: ошибка cURL 7: не удалось подключиться к порту localhost 443: в соединении отказано (http_request_failed)
Чтобы исправить это, вы можете попросить своего хостинг-провайдера переустановить сертификат SSL для вашего сайта.
5. Обратитесь за помощью к поставщику услуг хостинга
Если описанные выше действия не помогли устранить ошибку cURL 28 то, проблема, скорее всего, связана с средой хостинга.
Есть много факторов, которые могут контролироваться и исправляться только вашей хостинговой компанией. Например, если их DNS-серверы не могут своевременно разрешать запросы, это приведет к тайм-ауту запросов cURL.
Другой сценарий может заключаться в более медленном подключении или сетевых проблемах с вашим хост-сервером.
Просто отправьте им запрос в службу поддержки с подробными сведениями об ошибке, и их технический персонал сможет устранить неполадки и применить исправление для ее решения. Ну что, у нас на этом все. Всем пока!
Источник
Как исправить ошибку аутентификации SSH
Основные механизмы аутентификации пользователей при подключении через SSH — проверка пароля и сверка ключей. Их можно применять вместе или по отдельности, это настраивается в файле конфигурации SSH. Оба способа надежные, но иногда при их использовании можно столкнуться с ошибкой authentication failed. В этой статье разберемся, какие у этого сбоя могут быть причины и как их устранить.
В чем суть ошибки
У сообщения «authentication failed» перевод на русский предельно простой. Этот вывод в терминале говорит о том, что аутентификация пользователя не удалась.
Аутентификация — это проверка подлинности. Например, у вас есть сервер на cloud.timeweb.com . Вы настроили SSH для удаленного подключения. Чтобы система защиты вас пропустила, нужно пройти процедуру аутентификации – подтвердить, что это действительно вы.
Метод проверки подлинности закреплен в конфигурационном файле SSH. По умолчанию это аутентификация по паролю.
Другой вариант — использование пары SSH-ключей для проверки подлинности. В таком случае у пользователя на компьютере хранится закрытая часть ключа. На сервере располагается открытая часть. При попытке установить соединение эти части сравниваются. При совпадении доступ открывается. Если совпадения нет, появляется сообщение об ошибке — например, следующая ошибка SSH:
Но причины появления ошибки не ограничиваются только неправильным паролем или не теми ключами. Сбой может возникать также из-за повреждения системных файлов или неверно выставленных прав доступа.
Ниже разберемся с наиболее частыми ситуациями.
Ошибка при использовании пароля
Обычно проблемы возникают из-за неверного имени пользователя или пароля. Также стоит обратить внимание на конфигурацию сервера — может стоять запрет на аутентификацию через пароль. Как это проверить:
- Откройте файл конфигурации на сервере. Он находится по пути /etc/ssh/sshd_config.
- Найдите строку PasswordAuthentication. По умолчанию у неё значение `yes`. Это значит, что проверка по паролю разрешена.
- Если в вашем файле конфигурации параметр PasswordAuthentication имеет значение `no`, то подключиться по паролю не получится. Чтобы исправить ситуацию, измените значение на `yes`.
С паролем связано и появление ошибки su authentication failure. Вернее, с отсутствием парольной проверки у пользователя root. Если при такой конфигурации выполнить команду `su` без параметров, то вернется ошибка. Чтобы ее устранить, достаточно назначить пользователю root парольную защиту.
Ошибка при использовании ключей
Одна из самых распространенных проблем — использование не тех ключей при установке соединения. Часто это происходит, если с одного компьютера приходится подключаться к разным хостам. Самый простой способ не запутаться — давать понятные названия с указанием на то, для каких целей вы используете файлы аутентификации.
Использование большого количества ключей без явного указания нужного приводит еще к одной ошибке:
Причина сбоя — превышение числа попыток. Это случается из-за того, что SSH-клиент пытается подключиться к хосту, используя все доступные ключи. Исправить ситуацию можно с помощью опций IdentitiesOnly и IdentityFile. Пример запроса на подключение:
Чтобы каждый раз не прописывать это в командной строке при подключении, можно указать необходимую настройку в конфигурационном файле SSH
/.ssh/config. Пример такой настройки:
В этом случае SSH будет использовать только идентификаторы, указанные в файлах ssh_config, плюс идентификатор, указанный в командной строке. Идентификаторы, предоставленные агентом, будут игнорироваться.
При использовании ssh-ключей может возникнуть еще одна ошибка:
Ее причиной может быть ввод неверной ключевой фразы.
Если вы потеряете ключевую фразу, восстановить ее будет невозможно. Вам нужно будет сгенерировать новую пару значений для Secure Shell.
Восстановление открытого ключа
Если у вас есть закрытый ключ, но вы потеряли открытую часть, то эту проблему можно решить стандартными средствами OpenSSH.
Самый просто способ — использовать утилиту ssh-keygen.
Запустите терминал и выполните команду:
/.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 принадлежит текущему аккаунту.
/.ssh/authorized_keys принадлежит текущему аккаунту.
На клиенте также проверьте разрешения следующих файлов:
/ .ssh / config – 600.
Почему важен владелец? Например, вы настраивали доступ через Secure Shell от имени одного пользователя, а затем пытаетесь подключиться под другим аккаунтом, у которого нет прав даже на чтение содержимого защищенных директорий с аутентификационными данными.
Использование устаревших алгоритмов
В OpenSSH начиная с седьмой версии не поддерживаются старые ключи, которые используют алгоритм цифровой подписи — DSA. Ключи ssh-dss считаются слишком слабыми для того, чтобы можно было доверять им защиту подключения к серверу.
Если у вас старые ключи, оптимальное решение — сгенерировать и добавить на хосты новые, которые основаны на более стойких алгоритмах.
Есть и альтернатива, но пользоваться ей придется на свой страх и риск. Речь идет об изменении файла конфигурации /etc/ssh/sshd_config. Если установить параметру PubkeyAcceptedKeyTypes значение `+ssh-dss`, то можно будет использовать ключи, сгенерированные с помощью устаревшего алгоритма цифровой подписи.
Дополнительные опции могут понадобиться и на SSH-клиенте. Например, при подключении к серверу с ПО, которое давно не обновлялось. В частности, такие проблемы возникают при подключении к хостам на CentOS 6, поддержка которой прекращена в конце 2020 года. Чтобы исправить эту ошибку, необходимо добавить опцию `-oHostKeyAlgorithms=+ssh-dss`:
Ошибки на сторонних сервисах
Проблемы аутентификации могут возникать и при использовании сторонних сервисов. Например, при подключении к VK API пользователи сталкиваются с сообщением user authorization failed invalid session . Устранить такой сбой самостоятельно не получится — нужно обращаться в поддержку.
Заключение
Причина ошибки аутентификации может быть как на стороне клиента, так и на стороне сервера. Начинайте диагностику с самого простого: проверьте правильность имени пользователя и пароля, если он используется, выбор SSH-ключа в агенте. Если это не помогает устранить сбой, проверьте конфигурацию подключения и права доступа к файлам, которые OpenSSH использует для проверки подлинности пользователей.
Источник
What is the maximum amount of files that can be sent via ChatApp messengers?
For WhatsApp Chat API, WhatsApp Business API and Telegram Personal, the maximum file size is 60Mb.
For Viber bot, Telegram bot, Avito and Vkontakte, the maximum file size is 50Mb.
CRM doesn’t receive any messages
If you use Chat-api provider:
To solve the issue:
1) Make sure the phone screen is always on and WhatsApp is opened.
2) To find out where is the problem – with provider or with phone –check the status history in the provider control panel:
If you see statuses «loading», «activation» or substatuses «phone», «offline» then the phone settings are poor.
Substatus «computer» — WhatsApp account was opened on another device.
If statuses are stable, then we contact a provider. Please send a screenshot of status history to tech support.
How to use Bitrix24 chat for communication with a group in WhatsApp?
See “Group chats in WhatsApp”.
Why robot duplicates the messages?
Most likely CRM card includes duplicated numbers or duplicated numbers are sent to the robot.
Will the CRM have the copy of communications if I answer to messages in mobile WhatsApp application?
Yes, messages sent from WhatsApp in your phone are synchronized and displayed in the CRM as a message sent from the phone.
How to arrange bulk messaging to clients in WhatsApp?
- For details see «Messaging via WhatsApp». Send out only business messengers, such as the official WhatsApp.
- «Smart sending ChatApp via WhatsApp». The distribution can be done with any messenger, such as a personal Telegram account, because the smart mailing sets pauses and does not send all messages at once.
May I attach images to messages?
Unfortunately no, but you may send images via robot or business-process (in business processes editor you may find ChatApp activities which may send files).
How to hide sender name in Bitrix24?
- In Bitrix24 menu go to “Contact center” and click to ChatApp settings.
- In a dropdown list select “Open line”.
- Press Set up button
- In the “Queue” tab in a dropdown list Information on operators in a queue select Hide information on operators.
Save changes.
How to find out whether a client uses Messenger?
ChatApp dialog box shows information whether the client has messanger or not. When sending by robots use “detector” robot of ChatApp. It checks whether the client uses WhatsApp or not.
How to remove messages sent by a robot from opened lines of Bitrix24 “Sent by the robot”?
In robot settings in the dropdown list Show in opened lines select value No. When On, messages sent by robots will be visible in Open lines chats. If this option is Off, messages will be visible only in Contact. Lead or Transaction card in the Comments section.
Why ChatApp tab isn’t visible in Contact, Lead or Transaction card?
An employee has no rights in ChatApp application. For details see “Access rights”.
Error “rest”: {“error”:”authorization_error”,”error_description”:”unable to authorize user”}
Solution 1. Usually, this error occurs if the employee who installed ChatApp at the portal had been deleted from the Bitrix24 portal, for example because of discharge. To solve the issue reinstall the application from the account of the employee who has administrator right.
Solution 2. Grant the employee access rights to leads, transactions and contacts of CRM module.
For details see “Access rights”.
Solution 3. Grant the employee access rights to the application.
For details see “Access rights”.
Solution 4. Install the application under Admin, reinstall after Integrator.
Error “curl”: Operation timed out after 2500 milliseconds with 0 out of -1 bytes received
Error occurs when ChatApp server may not connect to the phone. To fix the error:
- Check the phone is on, charged and has access to the Internet. If the phone was off, after switching on wait for 15–20 minutes. Within this time the application status in API WhatsApp will be updated and integration with Bitrix24 will be established.
- Check phone settings. Turn off battery saver.
Error “Curl”: Failed connect to <PORTAL>; 443, no route to host
Reinstall ChatApp application.
Why I see message “You cannot send a message because the communication channel is not set up” when sending a message?
Check Open lines settings and connection.
0
1
Решение: IPsec VPN через Strongswan: ошибка авторизации (комментарий)
Решение, часть 2: IPsec VPN через Strongswan: ошибка авторизации (комментарий)
Пробую поднять IPsec IKEv2 VPN, на обоих концах Strongswan, авторизация через сертификаты X.509. При подключении приходит отлуп с AUTH_FAILED на IKE_AUTH request 1. Со стороны сервера CA сертификат подгружается нормально, в логах нет явных сообщений про неизвестные сертификаты.
Как это всё пофиксить? IPsec настраиваю второй раз, мб что-то простое пропустил.
Ниже 1.2.3.4 – внешний IP сервера, 5.6.7.8 – внешний IP клиента, 192.168.0.2 – внутренний IP клиента, 192.168.0.100 – внутренний IP сервера.
Конфиг сервера:
connections {
client {
version = 2
proposals = aes256gcm16-aes256gcm16-prfsha256-ecp256-ecp521,aes192-sha256-modp3072,default
rekey_time = 0s
pools = vpnpool
fragmentation = yes
dpd_delay = 30s
local {
certs = server.crt
}
remote {
}
children {
client {
local_ts = 0.0.0.0/0
rekey_time = 0s
dpd_action = clear
esp_proposals = aes256gcm16-aes256gcm16-prfsha256-ecp256-modp3072,aes192-sha256-ecp256-modp3072,default
}
}
}
}
pools {
vpnpool {
addrs = 10.1.1.0/30
dns = 8.8.8.8
}
}
secrets {
private {
file = server.key
}
}
Конфиг клиента:
conn server
keyexchange=ikev2
rekey=no
leftsourceip=%modeconfig
leftauth=rsa
leftcert=/etc/ipsec.d/client.crt
leftfirewall=yes
right=1.2.3.4
rightsubnet=0.0.0.0/0
auto=add
ca server-ca
auto=add
cacert=/etc/ipsec.d/ca.crt
Лог на клиенте:
% sudo ipsec up server
initiating IKE_SA server[2] to 1.2.3.4
generating IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
sending packet: from 192.168.0.2[500] to 1.2.3.4[500] (972 bytes)
received packet: from 1.2.3.4[500] to 192.168.0.2[500] (317 bytes)
parsed IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
selected proposal: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_256
local host is behind NAT, sending keep alives
remote host is behind NAT
received cert request for "CN=VPN CA"
received 1 cert requests for an unknown ca
sending cert request for "CN=VPN CA"
authentication of 'CN=client' (myself) with RSA_EMSA_PKCS1_SHA2_384 successful
sending end entity cert "CN=client"
establishing CHILD_SA server{2}
generating IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr AUTH CPRQ(ADDR DNS) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
splitting IKE message (2131 bytes) into 2 fragments
generating IKE_AUTH request 1 [ EF(1/2) ]
generating IKE_AUTH request 1 [ EF(2/2) ]
sending packet: from 192.168.0.2[4500] to 1.2.3.4[4500] (1248 bytes)
sending packet: from 192.168.0.2[4500] to 1.2.3.4[4500] (948 bytes)
received packet: from 1.2.3.4[4500] to 192.168.0.2[4500] (65 bytes)
parsed IKE_AUTH response 1 [ N(AUTH_FAILED) ]
received AUTHENTICATION_FAILED notify error
establishing connection 'server' failed
Лог с сервера:
server charon[994]: 08[CFG] loaded certificate 'CN=1.2.3.4'
server charon[994]: 13[CFG] loaded certificate 'CN=VPN CA'
server charon[994]: 15[CFG] loaded RSA private key
server charon[994]: 12[CFG] added vici pool client: 10.1.1.0, 2 entries
server charon[994]: 13[CFG] id not specified, defaulting to cert subject 'CN=1.2.3.4'
server charon[994]: 13[CFG] added vici connection: client
server charon[994]: 11[NET] received packet: from 5.6.7.8[500] to 192.168.0.100[500] (972 bytes)
server charon[994]: 11[ENC] parsed IKE_SA_INIT request 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) N(FRAG_SUP) N(HASH_ALG) N(REDIR_SUP) ]
server charon[994]: 11[IKE] 5.6.7.8 is initiating an IKE_SA
server charon[994]: 11[IKE] 5.6.7.8 is initiating an IKE_SA
server charon[994]: 11[CFG] selected proposal: IKE:AES_GCM_16_256/PRF_HMAC_SHA2_256/ECP_256
server charon[994]: 11[IKE] local host is behind NAT, sending keep alives
server charon[994]: 11[IKE] remote host is behind NAT
server charon[994]: 11[IKE] sending cert request for "CN=VPN CA"
server charon[994]: 11[ENC] generating IKE_SA_INIT response 0 [ SA KE No N(NATD_S_IP) N(NATD_D_IP) CERTREQ N(FRAG_SUP) N(HASH_ALG) N(CHDLESS_SUP) N(MULT_AUTH) ]
server charon[994]: 11[NET] sending packet: from 192.168.0.100[500] to 5.6.7.8[500] (297 bytes)
server charon[994]: 12[NET] received packet: from 5.6.7.8[4500] to 192.168.0.100[4500] (1248 bytes)
server charon[994]: 12[ENC] parsed IKE_AUTH request 1 [ EF(1/2) ]
server charon[994]: 12[ENC] received fragment #1 of 2, waiting for complete IKE message
server charon[994]: 15[NET] received packet: from 5.6.7.8[4500] to 192.168.0.100[4500] (948 bytes)
server charon[994]: 15[ENC] parsed IKE_AUTH request 1 [ EF(2/2) ]
server charon[994]: 15[ENC] received fragment #2 of 2, reassembled fragmented IKE message (2131 bytes)
server charon[994]: 15[ENC] parsed IKE_AUTH request 1 [ IDi CERT N(INIT_CONTACT) CERTREQ IDr AUTH CPRQ(ADDR DNS) SA TSi TSr N(MOBIKE_SUP) N(NO_ADD_ADDR) N(MULT_AUTH) N(EAP_ONLY) N(MSG_ID_SYN_SUP) ]
server charon[994]: 15[IKE] received cert request for "CN=VPN CA"
server charon[994]: 15[IKE] received end entity cert "CN=client"
server charon[994]: 15[CFG] looking for peer configs matching 192.168.0.100[1.2.3.4]...5.6.7.8[CN=client]
server charon[994]: 15[CFG] no matching peer config found
server charon[994]: 15[IKE] peer supports MOBIKE
server charon[994]: 15[ENC] generating IKE_AUTH response 1 [ N(AUTH_FAILED) ]
server charon[994]: 15[NET] sending packet: from 192.168.0.100[4500] to 5.6.7.8[4500] (65 bytes)
edit: добавил лог с сервера
Приветствуем вас! Вы видите ошибку cURL 28: Превышено время ожидания соединения на вашем сайте WordPress? Ошибка cURL 28 — распространенная проблема WordPress REST API, которая может повлиять на производительность вашего веб-сайта и привести к его непредсказуемому поведению.
В этой статье мы покажем вам, как легко исправить проблему cURL error 28 на вашем веб-сайте WordPress.
Что такое cURL в WordPress?
CURL — это программная утилита, используемая WordPress и многими другими веб-приложениями для отправки и получения запросов данных с использованием URL-адресов.
WordPress использует cURL для обработки нескольких запросов API. Он доступен как расширение языка программирования PHP, и ваша хостинговая компания WordPress позаботится об этом.
Библиотека cURL играет решающую роль в том, как WordPress работает за кулисами. Если он не настроен должным образом, ваш веб-сайт не будет работать должным образом.
Что вызывает ошибку cURL 28 в WordPress?
Неспособность своевременно ответить на запросы данных сервера вызывает ошибку 28 cURL в WordPress.
WordPress использует REST API (метод программирования) для отправки и получения запросов данных. Если время ожидания этих запросов истекло, вы увидите это как критическую проблему в отчете о работоспособности сайта с заголовком «Ошибка REST API».
Расширение ошибки покажет вам дополнительную информацию, включая сообщение об ошибке:
Error: cURL error 28: Operation timed out after x milliseconds with x bytes received (http_request_failed)
Вы также можете увидеть другую связанную проблему с заголовком «Ваш сайт не может выполнить запрос обратной связи». В нем будет аналогичное сообщение об ошибке со следующим описанием.
«Запрос обратной связи к вашему сайту не удался, это означает, что функции, использующие их, в настоящее время не работают должным образом».
Что может вызвать тайм-аут cURL?
Ряд сценариев может вызвать тайм-аут cURL в WordPress:
- Например, плагин брандмауэра WordPress может блокировать запрос REST API, считая его подозрительным действием.
- Если ваш DNS-сервер работает некорректно, это также может вызвать сбой HTTP-запросов и вызвать ошибку тайм-аута cURL в WordPress.
- Плохо настроенный хостинг-сервер может просто иметь очень низкий порог тайм-аута, что может помешать правильной работе определенных процессов WordPress.
Давайте посмотрим, как устранить и исправить данную проблему.
1. Временно отключите брандмауэр WordPress
Если вы используете брандмауэр WordPress или плагин безопасности, временно отключите его.
После этого вам нужно посетить страницу отчета о работоспособности сайта WordPress, чтобы узнать, решена ли ваша проблема.
Если да, то вам нужно проверить журналы брандмауэра WordPress, чтобы узнать, какие запросы API были заблокированы. Это либо определит источник проблемы, либо вы можете настроить параметры брандмауэра, чтобы не блокировать законные запросы API.
2. Отключите все плагины WordPress
Плагины WordPress создают собственные запросы API для отправки и получения данных. Если эти вызовы слишком часты или для выполнения требуется слишком много времени, это может вызвать ошибку cURL в отчете о работоспособности вашего сайта.
Самый простой способ выяснить это — отключить все плагины WordPress. Просто перейдите на страницу «Плагины»-«Установленные» и выберите все плагины.
После этого щелкните раскрывающееся меню «Массовые действия», чтобы выбрать «Деактивировать», а затем нажмите кнопку «Применить».
Теперь вы можете посетить отчет о работоспособности сайта, чтобы узнать, исчезла ли проблема. Если это устранило проблему, вы можете активировать свои плагины один за другим, пока проблема не появится снова.
Это поможет вам найти плагин, который может вызывать проблему.
3. Убедитесь, что ваш хостинг-сервер использует новейшее программное обеспечение
Следующий шаг — убедиться, что ваш хостинг-сервер WordPress использует последние версии PHP, библиотеки cURL и OpenSSL.
Вы можете проверить это, просмотрев вкладку системной информации на странице «Инструменты»-«Здоровье сайта».
Просто перейдите на вкладку «Информация» и разверните раздел «Сервер». Отсюда вы можете получить информацию о программном обеспечении, установленном на вашем хостинг-сервере WordPress.
В идеале ваш сервер должен использовать PHP 7.4.13 или выше, curl 7.74.0 или выше и OpenSSL 1.1.1 или выше.
Если это не так, вам необходимо связаться с вашей хостинговой компанией и попросить их обновить программное обеспечение для вашей учетной записи хостинга.
4. Устранение проблем с небезопасным контентом SSL
Если ваш сайт использует HTTPS / SSL, но он не настроен должным образом, это также может привести к тому, что ваш веб-сервер заблокирует небезопасные запросы cURL.
Точно так же, если ваш веб-сайт не использует HTTPS / SSL, но он сделал вызов API с использованием URL-адреса HTTP, то эти запросы тоже не будут выполнены, и вместо этого вы можете увидеть следующую ошибку cURL:
Ошибка: ошибка cURL 7: не удалось подключиться к порту localhost 443: в соединении отказано (http_request_failed)
Чтобы исправить это, вы можете попросить своего хостинг-провайдера переустановить сертификат SSL для вашего сайта.
5. Обратитесь за помощью к поставщику услуг хостинга
Если описанные выше действия не помогли устранить ошибку cURL 28 то, проблема, скорее всего, связана с средой хостинга.
Есть много факторов, которые могут контролироваться и исправляться только вашей хостинговой компанией. Например, если их DNS-серверы не могут своевременно разрешать запросы, это приведет к тайм-ауту запросов cURL.
Другой сценарий может заключаться в более медленном подключении или сетевых проблемах с вашим хост-сервером.
Просто отправьте им запрос в службу поддержки с подробными сведениями об ошибке, и их технический персонал сможет устранить неполадки и применить исправление для ее решения. Ну что, у нас на этом все. Всем пока!
С уважением Вячеслав и Валерия!
Понравился материал? Поделитесь с друзьями!
Интересное на блоге
AUTHINFO(SYSTEM.DEFAULT.AUTHINFO.IDPWOS) AUTHTYPE(IDPWOS) CHCKCLNT(OPTIONAL) will require that if a password is sent that it is a valid password.
The AMQ8077 error you are getting is because the user does not have permissions to connect to the queue manager.
You must grant OAM permission to allow clientadmin to connect to the queue manager.
By default on Linux you can grant MQ OAM permissions only against a group that a user is a member of, in your case a group that clientadmin is a member of. In MQ v8.0 and later if the following setting has been added to the qm.ini you can also grant OAM permission against the user itself:
Service:
SecurityPolicy=user
The above setting is not required, it just allows two different ways to grant OAM permissions. This is documented in the IBM MQ v8.0 Knowledge center page «Principals and groups». This page states:
UNIX and Linux systems
ACLs are based on both user IDs and groups and you can use either for authorization.
With Version 8.0, you can use the user-based model for authorization, and this allows you to use both users and groups. However, when you specify a user in the setmqaut command, the new permissions apply to that user alone, and not any groups to which that user belongs.
See Installable services for more information.
When you are using the group-based model for authorization, the primary group to which the user ID belongs is included in the ACL.
The individual user ID is not included and authority is granted to all members of that group. Because of this, be aware that you can inadvertently change the authority of a principal by changing the authority of another principal in the same group.
This is documented in the IBM MQ v8.0 Knowledge center page «Installable services». This page states:
SecurityPolicy=user|group|default
On UNIX and Linux systems the value specifies whether the queue manager uses user-based or group-based authorization. Values are not case sensitive.
If you do not include this attribute, default is used, which uses group-based authorization. Restart the queue manager for changes to become effective.
To grant OAM permission to connect to the queue manager against a group you can do it either with a MQSC command SET AUTHREC:
SET AUTHREC PROFILE('self') GROUP('groupname') OBJTYPE(QMGR) AUTHADD(CONNECT,DSP,INQ)
The same can be accomplished with a command line tool setmqaut:
setmqaut -m <queue_manager_name> -t qmgr -g groupname +connect +dsp +inq
To grant OAM permission to connect to the queue manager against the user itself you can do it either with a MQSC command SET AUTHREC:
SET AUTHREC PROFILE('self') PRINCIPAL('clientadmin') OBJTYPE(QMGR) AUTHADD(CONNECT,DSP,INQ)
The same can be accomplished with a command line tool setmqaut:
setmqaut -m <queue_manager_name> -t qmgr -p clientadmin +connect +dsp +inq
You would need to also grant PUT or GET access to the queue you want to access. The following example using a MQSC command SET AUTHREC is using the principal but you can change it to use a group if required:
SET AUTHREC PROFILE('QUEUE.NAME') PRINCIPAL('clientadmin') OBJTYPE(QUEUE) AUTHADD(PUT,GET,BROWSE,DSP,INQ)
The same can be accomplished with a command line tool setmqaut:
setmqaut -m <queue_manager_name> -t queue -p clientadmin +put +get +browse +dsp +inq
Update 2017/02/21
Setting permission on Linux using -p without having SecurityPolicy=user is not recommended. This is because this action does NOT set the permission against the user specified with -p, it instead sets it against the primary group of that user at the time you run the command.
This can cause various situations, a few examples I can think of are below:
- If you have two users with the same primary group and you provide them different access levels, they both end up with the same level of access that resulted from the last setmqaut command that you ran.
- Even if you provided them both the same level of access to begin with you may want to remove access from one of the two users and issue a similar command with the permission
-removespecified. The result would not be that you removed the access from one of the two users, but you instead removed it from both users. - It is not uncommon for the primary group of a unix account to change. If the user is not also a member of that same group as a secondary group after the change they will loose access to MQ.
It is also not recommended to provide a non-administrative user with +all, if you do this you might as well add the user to the mqm group and provide them with full MQ administrative authority.
You should instead provide the user with the specific permissions that are required. I provided in my example a limited set of permissions that should work for most applications.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 |
app_id = 'ваш app_id' access_token = 'ваш_ token' user_id = 'user_id вашей vk страницы ' def vk(method, **params): url = 'https://api.vk.com/method/%s' % method data = { 'users.get' : {'user_ids':''}, 'users.search' : {'q':''}, 'users.getFollowers': {'user_id':''}, 'friends.get' : {'user_id':''}, 'friends.getOnline' : {'user_id':''}, 'friends.search' : {'user_id':'','q':''}, 'groups.get' : {'user_id':''}, 'groups.search' : {'q':''}, 'groups.getMembers' : {'group_id':''}, 'groups.getById' : {'group_id':'','fields':'contacts,description,members_count'}, 'photos.get' : {'owner_id':''}, 'video.get' : {'owner_id':''}, 'video.search' : {'q':''}, 'wall.get' : {'count':'100'}, 'wall.search' : {'owner_id':'', 'query':''}, 'wall.getById' : {'posts':''}, 'status.get' : {'user_id':''}, 'messages.get' : {'count':'200'}, 'messages.getById' : {'message_ids':''}, 'stats.get' : {'date_from':'','data_to':''}, }.get(method,{}) data.update(params) data.update({'access_token':access_token}) resp = requests.post(url,data=data) answer = resp.json() if 'error' in answer: print('error:',answer ) return [] return answer ['response'] if __name__ == "__main__": print(vk('users.get')) print(vk('users.search',q="Вася Пупкин")) print(vk('users.getFollowers')) print(vk('friends.get')) print(vk('friends.search',user_id=user_id, q='Вася')) time.sleep(2) print(vk('groups.get')) print(vk('groups.search',q='python')) print(vk('groups.getById',group_id='python_community')) print(vk('groups.getMembers',group_id='python_community')) time.sleep(2) print(vk('photos.get',owner_id=user_id,album_id='profile')) print(vk('status.get',user_id=user_id)) print(vk('wall.get', count=1)) print(vk('wall.getById', posts=user_id + '_' + '8')) print(vk('wall.search', owner_id=user_id, query='статья')) time.sleep(2) print(vk('video.get',owner_id=user_id,album_id='0')) print(vk('messages.get',count="10")) print(vk('stats.get',app_id=app_id,date_from='2018-01-01',date_to='2018-02-19')) |
Появление сообщения об ошибке 401 Unauthorized Error («отказ в доступе») при открытии страницы сайта означает неверную авторизацию или аутентификацию пользователя на стороне сервера при обращении к определенному url-адресу. Чаще всего она возникает при ошибочном вводе имени и/или пароля посетителем ресурса при входе в свой аккаунт. Другой причиной являются неправильные настройки, допущенные при администрировании web-ресурса. Данная ошибка отображается в браузере в виде отдельной страницы с соответствующим описанием. Некоторые разработчики интернет-ресурсов, в особенности крупных порталов, вводят собственную дополнительную кодировку данного сбоя:
- 401 Unauthorized;
- Authorization Required;
- HTTP Error 401 – Ошибка авторизации.
Попробуем разобраться с наиболее распространенными причинами возникновения данной ошибки кода HTTP-соединения и обсудим способы их решения.
Причины появления ошибки сервера 401 и способы ее устранения на стороне пользователя
При доступе к некоторым сайтам (или отдельным страницам этих сайтов), посетитель должен пройти определенные этапы получения прав:
- Идентификация – получение вашей учетной записи («identity») по username/login или email.
- Аутентификация («authentic») – проверка того, что вы знаете пароль от этой учетной записи.
- Авторизация – проверка вашей роли (статуса) в системе и решение о предоставлении доступа к запрошенной странице или ресурсу на определенных условиях.
Большинство пользователей сохраняют свои данные по умолчанию в истории браузеров, что позволяет быстро идентифицироваться на наиболее часто посещаемых страницах и синхронизировать настройки между устройствами. Данный способ удобен для серфинга в интернете, но может привести к проблемам с безопасностью доступа к конфиденциальной информации. При наличии большого количества авторизованных регистрационных данных к различным сайтам используйте надежный мастер-пароль, который закрывает доступ к сохраненной в браузере информации.
Наиболее распространенной причиной появления ошибки с кодом 401 для рядового пользователя является ввод неверных данных при посещении определенного ресурса. В этом и других случаях нужно попробовать сделать следующее:
- Проверьте в адресной строке правильность написания URL. Особенно это касается перехода на подстраницы сайта, требующие авторизации. Введите правильный адрес. Если переход на страницу осуществлялся после входа в аккаунт, разлогинитесь, вернитесь на главную страницу и произведите повторный вход с правильными учетными данными.
- При осуществлении входа с сохраненными данными пользователя и появлении ошибки сервера 401 проверьте их корректность в соответствующих настройках данного браузера. Возможно, авторизационные данные были вами изменены в другом браузере. Также можно очистить кэш, удалить cookies и повторить попытку входа. При удалении истории браузера или очистке кэша потребуется ручное введение логина и пароля для получения доступа. Если вы не помните пароль, пройдите процедуру восстановления, следуя инструкциям.
- Если вы считаете, что вводите правильные регистрационные данные, но не можете получить доступ к сайту, обратитесь к администратору ресурса. В этом случае лучше всего сделать скриншот проблемной страницы.
- Иногда блокировка происходит на стороне провайдера, что тоже приводит к отказу в доступе и появлению сообщения с кодировкой 401. Для проверки можно попробовать авторизоваться на том же ресурсе с альтернативного ip-адреса (например, используя VPN). При подтверждении блокировки трафика свяжитесь с провайдером и следуйте его инструкциям.
Некоторые крупные интернет-ресурсы с большим количеством подписчиков используют дополнительные настройки для обеспечения безопасности доступа. К примеру, ваш аккаунт может быть заблокирован при многократных попытках неудачной авторизации. Слишком частые попытки законнектиться могут быть восприняты как действия бота. В этом случае вы увидите соответствующее сообщение, но можете быть просто переадресованы на страницу с кодом 401. Свяжитесь с администратором сайта и решите проблему.
Иногда простая перезагрузка проблемной страницы, выход из текущей сессии или использование другого веб-браузера полностью решают проблему с 401 ошибкой авторизации.
Устранение ошибки 401 администратором веб-ресурса
Для владельцев сайтов, столкнувшихся с появлением ошибки отказа доступа 401, решить ее порою намного сложнее, чем обычному посетителю ресурса. Есть несколько рекомендаций, которые помогут в этом:
- Обращение в службу поддержки хостинга сайта. Как и в случае возникновения проблем с провайдером, лучше всего подробно описать последовательность действий, приведших к появлению ошибки 401, приложить скриншот.
- При отсутствии проблем на стороне хостинг-провайдера можно внести следующие изменения в настройки сайта с помощью строки Disallow:/адрес проблемной страницы. Запретить индексацию страницам с ошибкой в «rоbоts.txt», после чего добавить в файл «.htассеss» строку такого типа:
Redirect 301 /oldpage.html http://site.com/newpage.html.
Где в поле /oldpage.html прописывается адрес проблемной страницы, а в http://site.com/newpage.html адрес страницы авторизации.
Таким образом вы перенаправите пользователей со всех страниц, которые выдают ошибку 401, на страницу начальной авторизации.
- Если после выполнения предыдущих рекомендаций пользователи при попытках авторизации все равно видят ошибку 401, то найдите на сервере файл «php.ini» и увеличьте время жизни сессии, изменив значения следующих параметров: «session.gc_maxlifetime» и «session.cookie_lifetime» на 1440 и 0 соответственно.
- Разработчики веб-ресурсов могут использовать более сложные методы авторизации и аутентификации доступа для создания дополнительной защиты по протоколу HTTP. Если устранить сбой простыми методами администрирования не удается, следует обратиться к специалистам, создававшим сайт, для внесения соответствующих изменений в код.
Хотя ошибка 401 и является проблемой на стороне клиента, ошибка пользователя на стороне сервера может привести к ложному требованию входа в систему. К примеру, сетевой администратор разрешит аутентификацию входа в систему всем пользователям, даже если это не требуется. В таком случае сообщение о несанкционированном доступе будет отображаться для всех, кто посещает сайт. Баг устраняется внесением соответствующих изменений в настройки.
Дополнительная информация об ошибке с кодом 401
Веб-серверы под управлением Microsoft IIS могут предоставить дополнительные данные об ошибке 401 Unauthorized в виде второго ряда цифр:
- 401, 1 – войти не удалось;
- 401, 2 – ошибка входа в систему из-за конфигурации сервера;
- 401, 3 – несанкционированный доступ из-за ACL на ресурс;
- 401, 501 – доступ запрещен: слишком много запросов с одного и того же клиентского IP; ограничение динамического IP-адреса – достигнут предел одновременных запросов и т.д.
Более подробную информацию об ошибке сервера 401 при использовании обычной проверки подлинности для подключения к веб-узлу, который размещен в службе MS IIS, смотрите здесь.
Следующие сообщения также являются ошибками на стороне клиента и относятся к 401 ошибке:
- 400 Bad Request;
- 403 Forbidden;
- 404 Not Found;
- 408 Request Timeout.
Как видим, появление ошибки авторизации 401 Unauthorized не является критичным для рядового посетителя сайта и чаще всего устраняется самыми простыми способами. В более сложной ситуации оказываются администраторы и владельцы интернет-ресурсов, но и они в 100% случаев разберутся с данным багом путем изменения настроек или корректировки html-кода с привлечением разработчика сайта.