Checking error authentication method locked перевод

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

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

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

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

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

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

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

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

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

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

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

1. Откройте файл конфигурации на сервере. Он находится по пути /etc/ssh/sshd_config.
2. Найдите строку PasswordAuthentication. По умолчанию у неё значение `yes`. Это значит, что проверка по паролю разрешена.
3. Если в вашем файле конфигурации параметр 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 использует для проверки подлинности пользователей.

Источник

API Spec Proposal #59

Constants

(taken from Open Smart Card Development Platform (www.openscdp.org))
(Implementation of ISO 7816-4 APDU processing )

Process completed, more data available

Warning: Part of data corrupted

Warning: Verify fail, no try left

Warning: Verify fail, 1 try left

Warning: Verify fail, 2 tries left

Warning: Verify fail, 3 tries left

Checking error: Function in CLA byte not supported

Checking error: Logical channel not supported

Checking error: Secure Messaging not supported

Checking error: Last command of the chain expected

Checking error: Command chaining not supported

Checking error: Command not allowed

Checking error: Command incompatible with file structure

Checking error: Security condition not satisfied

Checking error: Authentication method locked

Checking error: Reference data not usable

Checking error: Condition of use not satisfied

Checking error: Command not allowed (no current EF)

Checking error: Expected secure messaging object missing

Checking error: Incorrect secure messaging data object

Checking error: Wrong parameter P1-P2

Checking error: Incorrect parameter in the command data field

Checking error: Function not supported

Checking error: File not found

Checking error: File not found

Checking error: Record not found

Checking error: Not enough memory space in the file

Checking error: Nc inconsistent with TLV structure

Checking error: Lc inconsistent with P1-P2

Checking error: Reference data not found

Checking error: File already exists

Checking error: DF name already exists

Checking error: Wrong parameter P1-P2

Checking error: Wrong instruction

Checking error: Class not supported

Access conditions not satisfied

Checking error: No precise diagnosis

Methods/Functions

public setPin(int pin)

Should return true or false

public setPuk(int puk)

Should return true or false

public isVerified(string context)

Should accept PIN or PUK as valid contextes.

Should return true or false

public getRetriesAvail(string context)

Check how many retries are available for a given context

Should accept PIN or PUK as valid contextes.

Should return true or false

public setCardType(string type)

Sets a SmartCard type ( EID, Credit Card, etc. )

Gets all card contents for external storage. This method does imply legal issues for many cases like EID, Credit Cards, but for the sake of caching the data, I have added this method.

Gets the file system structure on the card.

This method should be ajusted for some spec for some CardTypes, since they may have different structs.

private sendAPDU(byte_array buffer)

private decode(string data, string from, string to)

decode a Hex to Ascii for example

private encode(string data, string from, string to)

SubClass — EID

This describes an object to interact with a eID card.

Note: This was built on information I can read from the eID using my country’s own middleware. Each country object should be able to provide more information, but I think these are most common

Methods/Functions

public setCountry(string country-code, string iso=’DEFAUL_ISO’)

sets a eID card profile for a given country and their card’s ISO

gets Public key certificate for Authentication purproses

gets Document Signing certificate.

public getID(string context);

Allowed values should be : Citizen, VAT, Voter, SocialSec, HealthCare

Get the free text field available on the card

Sets the free text field available on the card

The text was updated successfully, but these errors were encountered:

Here is a preliminary API spec.
This may have to change in the future, but I think as a draft its makes the base class a simple one and I have added an eID child class in the proposal as well, due to my own needs

@jarodium You should first read ISO 7816-4 document.

@LudovicRousseau
Thank you for pointing me out the spec. I already had taken a look on the Spec, when I was researching APDU. Please refer to #58 in which I «complain» about how hard is for me to build apdu’s. I come from a web environment and I am slowy making incursions on the physical world.

The intent of the API, is to have node-pcsclite handle higher level functions, without having developers like myself, bashing around to get APDU’s working properly.

I believe node-pcslite will become more powerful in the future and will provide a solid base for IOT and specialized devices.

The problem is that the APDU commands understood by a smart card is not standard. Each smart card family (EMV card, SIM card, etc.) have its own set of commands and parameters.

I see, but with the setCardType method one can set one of those types and load their own set of APDU commands. Maybe I should remove the APDU constants and let the methods stay.
I think the methods are abstract enough for most card types.
What do you think @LudovicRousseau ?

I think node-pcsclite is a low level API.
You should create another (or more) library to provide a higher level API.

I think node-pcsclite is a low level API.
You should create another (or more) library to provide a higher level API.

@jarodium I agree with @LudovicRousseau.
I see node-pcsclite as a building block to create more complex API’s. For example, I created node-pcsclite because I needed to operate with SLE4442 cards, but I don’t use it directly. I have created a module on top of it with a higher level API specific for this kind of cards: read_main_memory() , read_security_memory() , read_protection_memory() , etc. In fact, I have created multiple modules that implement this interface because different card reader models sometimes access the same kind of cards using different commands.

Now I have understood the goal of this module.
I thought i could evolve into a higher level api, from the current status, but if the goal is to keep it low level, I will no longer pursue this matter, but I will try to build a higher level api, but like I said in #58 , that will consume a lot of my time, since I should do lots of trial and error with the ptEID cards.
@santigimeno is it possible to share those modules into repos?

Thank you for your time
Regards

@jarodium Sorry, at the moment they’re private 🙁

I’m closing this for the moment. Feel free to reopen though.

© 2023 GitHub, Inc.

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

Источник

Proposal v.0.01 — Base Class

Constants

(taken from Open Smart Card Development Platform (www.openscdp.org))
(Implementation of ISO 7816-4 APDU processing )

APDU.INS_DEACTIVATE = 0x04;

APDU.INS_VERIFY = 0x20;

APDU.INS_MANAGE_SE = 0x22;

APDU.INS_CHANGE_REFERENCE_DATA = 0x24;

APDU.INS_PSO = 0x2A;

APDU.INS_RESET_RETRY_COUNTER = 0x2C;

APDU.INS_ACTIVATE = 0x44;

APDU.INS_GENERATE_KEY_PAIR = 0x46;

APDU.INS_EXTERNAL_AUTHENTICATE = 0x82;

APDU.INS_GET_CHALLENGE = 0x84;

APDU.INS_GENERAL_AUTHENTICATE = 0x86;

APDU.INS_COMPUTE_DIGITAL_SIGN = 0x9E;

APDU.INS_SELECT = 0xA4;

APDU.INS_READBINARY = 0xB0;

APDU.INS_READ_BINARY = 0xB0;

APDU.INS_READ_RECORD = 0xB2;

APDU.INS_VERIFY_CERTIFICATE = 0xBE;

APDU.INS_UPDATE_BINARY = 0xD6;

APDU.INS_TERMINATE = 0xE6;

APDU.SW_OK = 0x9000;

Process completed

APDU.SW_TIMEOUT = 0x6401;

Exec error: Command timeout

APDU.SW_OKMOREDATA = 0x6100;

Process completed, more data available

APDU.SW_WARNING = 0x6200;

Warning: NV-Ram not changed

APDU.SW_WARNING1 = 0x6201;

Warning: NV-Ram not changed 1

APDU.SW_DATAINV = 0x6281;

Warning: Part of data corrupted

APDU.SW_EOF = 0x6282;

Warning: End of file reached

APDU.SW_INVFILE = 0x6283;

Warning: Invalidated file

APDU.SW_INVFORMAT = 0x6284;

Warning: Invalid file control

APDU.SW_WARNINGNVCHG = 0x6300;

Warning: NV-Ram changed

APDU.SW_WARNINGCOUNT = 0x63C0;

Warning: Warning with counter

APDU.SW_WARNING0LEFT = 0x63C0;

Warning: Verify fail, no try left

APDU.SW_WARNING1LEFT = 0x63C1;

Warning: Verify fail, 1 try left

APDU.SW_WARNING2LEFT = 0x63C2;

Warning: Verify fail, 2 tries left

APDU.SW_WARNING3LEFT = 0x63C3;

Warning: Verify fail, 3 tries left

APDU.SW_EXECERR = 0x6400;

Exec error: NV-Ram not changed

APDU.SW_MEMERR = 0x6501;

Exec error: Memory failure

APDU.SW_MEMERRWRITE = 0x6581;

Exec error: Memory failure

APDU.SW_WRONGLENGTH = 0x6700;

Checking error: Wrong length

APDU.SW_CLANOTSUPPORTED = 0x6800;

Checking error: Function in CLA byte not supported

APDU.SW_LCNOTSUPPORTED = 0x6881;

Checking error: Logical channel not supported

APDU.SW_SMNOTSUPPORTED = 0x6882;

Checking error: Secure Messaging not supported

APDU.SW_LASTCMDEXPECTED = 0x6883;

Checking error: Last command of the chain expected

APDU.SW_CHAINNOTSUPPORTED = 0x6884;

Checking error: Command chaining not supported

APDU.SW_COMNOTALLOWED = 0x6900;

Checking error: Command not allowed

APDU.SW_COMINCOMPATIBLE = 0x6981;

Checking error: Command incompatible with file structure

APDU.SW_SECSTATNOTSAT = 0x6982;

Checking error: Security condition not satisfied

APDU.SW_AUTHMETHLOCKED = 0x6983;

Checking error: Authentication method locked

APDU.SW_REFDATANOTUSABLE = 0x6984;

Checking error: Reference data not usable

APDU.SW_CONDOFUSENOTSAT = 0x6985;

Checking error: Condition of use not satisfied

APDU.SW_COMNOTALLOWNOEF = 0x6986;

Checking error: Command not allowed (no current EF)

APDU.SW_SMOBJMISSING = 0x6987;

Checking error: Expected secure messaging object missing

APDU.SW_INCSMDATAOBJECT = 0x6988;

Checking error: Incorrect secure messaging data object

APDU.SW_INVPARA = 0x6A00;

Checking error: Wrong parameter P1-P2

APDU.SW_INVDATA = 0x6A80;

Checking error: Incorrect parameter in the command data field

APDU.SW_FUNCNOTSUPPORTED = 0x6A81;

Checking error: Function not supported

APDU.SW_NOAPPL = 0x6A82;

Checking error: File not found

APDU.SW_FILENOTFOUND = 0x6A82;

Checking error: File not found

APDU.SW_RECORDNOTFOUND = 0x6A83;

Checking error: Record not found

APDU.SW_OUTOFMEMORY = 0x6A84;

Checking error: Not enough memory space in the file

APDU.SW_INVLCTLV = 0x6A85;

Checking error: Nc inconsistent with TLV structure

APDU.SW_INVACC = 0x6A85;

Checking error: Access cond. n/f

APDU.SW_INCP1P2 = 0x6A86;

Checking error: Incorrect P1-P2

APDU.SW_INVLC = 0x6A87;

Checking error: Lc inconsistent with P1-P2

APDU.SW_RDNOTFOUND = 0x6A88;

Checking error: Reference data not found

APDU.SW_FILEEXISTS = 0x6A89;

Checking error: File already exists

APDU.SW_DFNAMEEXISTS = 0x6A8A;

Checking error: DF name already exists

APDU.SW_INVP1P2 = 0x6B00;

Checking error: Wrong parameter P1-P2

APDU.SW_INVLE = 0x6C00;

Checking error: Invalid Le

APDU.SW_INVINS = 0x6D00;

Checking error: Wrong instruction

APDU.SW_INVCLA = 0x6E00;

Checking error: Class not supported

APDU.SW_ACNOTSATISFIED = 0x9804;

Access conditions not satisfied

APDU.SW_NOMORESTORAGE = 0x9210;

No more storage available

APDU.SW_GENERALERROR = 0x6F00;

Checking error: No precise diagnosis

Methods/Functions

public setPin(int pin)

Send PIN for validation

Should return true or false

public setPuk(int puk)

Send PUK for validation

Should return true or false

public isVerified(string context)

Check if context is verified.

Should accept PIN or PUK as valid contextes.

Should return true or false

public getRetriesAvail(string context)

Check how many retries are available for a given context

Should accept PIN or PUK as valid contextes.

Should return true or false

public setCardType(string type)

Sets a SmartCard type ( EID, Credit Card, etc… )

public getCardType()

self explaining

Public getCardContents()

Gets all card contents for external storage. This method does imply legal issues for many cases like EID, Credit Cards, but for the sake of caching the data, I have added this method.

public getFS()

Gets the file system structure on the card.

This method should be ajusted for some spec for some CardTypes, since they may have different structs.

private sendAPDU(byte_array buffer)

self explaining

private decode(string data, string from, string to)

self explaining

decode a Hex to Ascii for example

private encode(string data, string from, string to)

self explaining

SubClass — EID

This describes an object to interact with a eID card.

Note: This was built on information I can read from the eID using my country’s own middleware. Each country object should be able to provide more information, but I think these are most common

Methods/Functions

public setCountry(string country-code, string iso=’DEFAUL_ISO’)

sets a eID card profile for a given country and their card’s ISO

public getPkiCert()

gets Public key certificate for Authentication purproses

public getSignCert()

gets Document Signing certificate.

public getName()

gets Name field

public getAddress()

gets Address field

public getID(string context);

get ID from a given context

Allowed values should be : Citizen, VAT, Voter, SocialSec, HealthCare

public getParentage();

get Mother and Father’s names.

public getDateofBirth()

get date of birth

public getFingerPrints()

get fingerprint data

public getPhoto()

get photo

public getFreeField

Get the free text field available on the card

public setFreeField

Sets the free text field available on the card

• Главная

• Инструкции

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

Содержание

Составили подробный классификатор кодов состояния HTTP. Добавляйте в закладки, чтобы был под рукой, когда понадобится.

Что такое код ответа HTTP

Когда посетитель переходит по ссылке на сайт или вбивает её в поисковую строку вручную, отправляется запрос на сервер. Сервер обрабатывает этот запрос и выдаёт ответ — трехзначный цифровой код HTTP от 100 до 510. По коду ответа можно понять реакцию сервера на запрос. 

Первая цифра в ответе обозначает класс состояния, другие две — причину, по которой мог появиться такой ответ.

Как проверить код состояния страницы

Проверить коды ответа сервера можно вручную с помощью браузера и в панелях веб‑мастеров: Яндекс.Вебмастер и Google Search Console.

В браузере

Для примера возьмём Google Chrome.

1. Откройте панель разработчика в браузере клавишей F12, комбинацией клавиш Ctrl + Shift + I или в меню браузера → «Дополнительные инструменты» → «Инструменты разработчика». Подробнее об этом рассказывали в статье «Как открыть исходный код страницы». 

2. Переключитесь на вкладку «Сеть» в Инструментах разработчика и обновите страницу: 

В Яндекс.Вебмастере

Откройте инструмент «Проверка ответа сервера» в Вебмастере. Введите URL в специальное поле и нажмите кнопку «Проверить»:

Как добавить сайт в Яндекс.Вебмастер и другие сервисы Яндекса

В Google Search Console

Чтобы посмотреть код ответа сервера в GSC, перейдите в инструмент проверки URL — он находится в самом верху панели:

Введите ссылку на страницу, которую хотите проверить, и нажмите Enter. В результатах проверки нажмите на «Изучить просканированную страницу» в блоке «URL есть в индексе Google».

А затем в открывшемся окне перейдите на вкладку «Подробнее»:

Теперь расскажем подробнее про все классы кодов состояния HTTP.

1* класс кодов (информационные сообщения)

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

100 Continue

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

101 Switching Protocols

Сервер одобрил переключение типа протокола, которое запросил пользователь, и в настоящий момент выполняет действие.

102 Processing

Запрос принят — он находится в обработке, и на это понадобится чуть больше времени.

103 Checkpoint

Контрольная точка — используется в запросах для возобновления после прерывания запросов POST или PUT.

105 Name Not Resolved

Не удается преобразовать DNS‑адрес сервера — это  означает ошибку в службе DNS. Эта служба преобразует IP‑адреса в знакомые нам доменные имена.

2* класс кодов (успешно обработанные запросы)

Эти коды информируют об успешности принятия и обработки запроса. Также сервер может передать заголовки или тело сообщений. 

200 ОК

Все хорошо — HTTP‑запрос успешно обработан (не ошибка).

201 Created

Создано — транзакция успешна, сформирован новый ресурс или документ.

202 Accepted

Принято — запрос принят, но ещё не обработан.

203 Non‑Authoritative Information

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

204 No Content

Нет содержимого — запрос успешно обработан, однако в ответе только заголовки без контента сообщения. Не нужно обновлять содержимое документа, но можно применить к нему полученные метаданные.

205 Reset Content

Сбросить содержимое. Запрос успешно обработан — но нужно сбросить введенные данные. Страницу можно не обновлять.

206 Partial Content

Частичное содержимое. Сервер успешно обработал часть GET‑запроса, а другую часть вернул.

При работе с подобными ответами следует уделить внимание кэшированию.

207 Multi‑Status

Успешно выполнено несколько операций — сервер передал результаты выполнения нескольких независимых операций. Они появятся в виде XML‑документа с объектом multistatus. 

226 IM Used

Успешно обработан IM‑заголовок (специальный заголовок, который отправляется клиентом и используется для передачи состояния HTTP).

3* класс кодов (перенаправление на другой адрес)

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

300 Multiple Choices

Множественный выбор — сервер выдает список нескольких возможных вариантов перенаправления (максимум — 5). Можно выбрать один из них.

301 Moved Permanently

Окончательно перемещено — страница перемещена на другой URL, который указан в поле Location.

302 Found/Moved 

Временно перемещено — страница временно перенесена на другой URL,  который указан в поле Location.

303 See Other

Ищите другую страницу — страница не найдена по данному URL, поэтому смотрите страницу по другому URL, используя метод GET.

304 Not Modified

Модификаций не было — с момента последнего визита клиента изменений не было.

305 Use Proxy

Используйте прокси — запрос к нужному ресурсу можно сделать только через прокси‑сервер, URL которого указан в поле Location заголовка.

306 Unused

Зарезервировано. Код в настоящий момент не используется.

307 Temporary Redirect

Временное перенаправление — запрашиваемый ресурс временно доступен по другому URL.

Этот код имеет ту же семантику, что код ответа 302 Found, за исключением того, что агент пользователя не должен изменять используемый метод HTTP: если в первом запросе использовался POST, то во втором запросе также должен использоваться POST.

308 Resume Incomplete

Перемещено полностью (навсегда) — запрашиваемая страница была перенесена на новый URL, указанный в поле Location заголовка. Метод запроса (GET/POST) менять не разрешается.

4* класс кодов (ошибки на стороне клиента)

Эти коды указывают на ошибки со стороны клиентов. 

400 Bad Request

Неверный запрос — запрос клиента не может быть обработан, так как есть синтаксическая ошибка (возможно, опечатка).

401 Unauthorized

Не пройдена авторизация — запрос ещё в обработке, но доступа нет, так как пользователь не авторизован.

Для доступа к запрашиваемому ресурсу клиент должен представиться, послав запрос, включив при этом в заголовок сообщения поле Authorization.

402 Payment Required

Требуется оплата — зарезервировано для использования в будущем. Код предусмотрен для платных пользовательских сервисов, а не для хостинговых компаний.

403 Forbidden

Запрещено — запрос принят, но не будет обработан, так как у клиента недостаточно прав. Может возникнуть, когда пользователь хочет открыть системные файлы (robots, htaccess) или не прошёл авторизацию.

404 Not Found

Не найдено — запрашиваемая страница не обнаружена. Сервер принял запрос, но не нашёл ресурса по указанному URL (возможно, была ошибка в URL или страница была перемещена).

405 Method Not Allowed

Метод не разрешён — запрос был сделан методом, который не поддерживается данным ресурсом. Сервер должен предложить доступные методы решения в заголовке Allow.

406 Not Acceptable

Некорректный запрос — неподдерживаемый поисковиком формат запроса (поисковый робот не поддерживает кодировку или язык).

407 Proxy Authentication Required

Нужно пройти аутентификацию прокси — ответ аналогичен коду 401, только нужно аутентифицировать прокси‑сервер.

408 Request Timeout

Тайм‑аут запроса — запрос клиента занял слишком много времени. На каждом сайте существует свое время тайм‑аута — проверьте интернет‑соединение  и просто обновите страницу.

409 Conflict

Конфликт (что‑то пошло не так) — запрос не может быть выполнен из‑за конфликтного обращения к ресурсу (несовместимость двух запросов).

410 Gone

Недоступно — ресурс раньше был размещён по указанному URL, но сейчас удалён и  недоступен (серверу неизвестно месторасположение).

411 Length Required

Добавьте длины — сервер отклоняет отправляемый запрос, так как длина заголовка не определена, и он не находит значение Content‑Length. 

Нужно исправить заголовки на сервере, и в следующий раз робот сможет проиндексировать страницу.

412 Precondition Failed

Предварительное условие не выполнено — стоит проверить правильность HTTP‑заголовков данного запроса.

413 Request Entity Too Large

Превышен размер запроса — перелимит максимального размера запроса, принимаемого сервером. Браузеры поддерживают запросы от 2 до 8 килобайт.

414 Request‑URI Too Long

Превышена длина запроса — сервер не может обработать запрос из‑за длинного URL. Такая ошибка может возникнуть, например, когда клиент пытается передать чересчур длинные параметры через метод GET, а не POST.

415 Unsupported Media Type

Формат не поддерживается —  сервер не может принять запрос, так как  данные подгружаются в некорректном формате, и сервер разрывает соединение.

416 Requested Range Not Satisfiable

Диапазон не поддерживается — ошибка возникает в случаях, когда в самом HTTP‑заголовке прописывается некорректный байтовый диапазон.

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

417 Expectation Failed

Ожидания не оправдались — прокси некорректно идентифицировал содержимое поля «Expect: 100‑Continue».

418 I’m a teapot

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

422 Unprocessable Entity

Объект не обработан — сервер принял запрос, но в нём  есть логическая ошибка. Стоит посмотреть в сторону семантики сайта.

423 Locked

Закрыто — ресурс заблокирован для выбранного HTTP‑метода. Можно перезагрузить роутер и компьютер. А также использовать только статистический IP.

424 Failed Dependency

Неуспешная зависимость — сервер не может обработать запрос, так как  один из зависимых ресурсов заблокирован.

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

425 Unordered Collection

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

426 Upgrade Required

Нужно обновление — в заголовке ответа нужно корректно сформировать поля Upgrade и Connection. 

Этот ответ возникает, когда серверу требуется обновление до SSL‑протокола, но клиент не имеет его поддержки.

428 Precondition Required

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

429 Too Many Requests

Слишком много запросов — отправлено слишком много запросов за короткое время. Это может указывать, например, на попытку DDoS‑атаки, для защиты от которой запросы блокируются.

431 Request Header Fields Too Large

Превышена длина заголовков — сервер может и не отвечать этим кодом, вместо этого он может просто сбросить соединение.

Исправляется это с помощью сокращения заголовков и повторной отправки запроса.

434 Requested Host Unavailable

Адрес запрашиваемой страницы недоступен.

444 No Response

Нет ответа — код отображается в лог‑файлах, чтобы подтвердить, что сервер никак не отреагировал на запрос пользователя и прервал соединение. Возвращается только сервером nginx.

Nginx — программное обеспечение с открытым исходным кодом. Его используют для создания веб‑серверов, а также  в качестве почтового или обратного прокси‑сервера. Nginx решает проблему падения производительности из‑за роста трафика. 

449 Retry With

Повторите попытку — ошибка говорит о необходимости скорректировать запрос и повторить его снова. Причиной становятся неверно указанные параметры (возможно, недостаточно данных).

450 Blocked by Windows Parental Controls

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

451 Unavailable For Legal Reasons

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

456 Unrecoverable Error

Неустранимая ошибка — при обработке запроса возникла ошибка, которая вызывает некорректируемые сбои в таблицах баз данных.

499 Client Closed Request

Запрос закрыт клиентом — нестандартный код, используемый nginx в ситуациях, когда клиент закрыл соединение, пока nginx обрабатывал запрос.

5* класс кодов (ошибки на стороне сервера)

Эти коды указывают на ошибки со стороны серверов. 

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

500 Internal Server Error

Внутренняя ошибка сервера — сервер столкнулся с неким условием, из‑за которого не может выполнить запрос. 

Проверяйте, корректно ли указаны директивы в системных файлах (особенно htaccess) и нет ли ошибки прав доступа к файлам. Обратите внимание на ошибки внутри скриптов и их медленную работу.

501 Not Implemented

Не выполнено —  код отдается, когда сам сервер не может идентифицировать метод запроса. 

Сами вы эту ошибку не исправите. Устранить её может только сервер.

502 Bad Gateway

Ошибка шлюза — появляется, когда сервер, выступая в роли шлюза или прокси‑сервера, получил ответное сообщение от вышестоящего сервера о несоответствии протоколов.

Актуально исключительно для прокси и шлюзовых конфигураций.

503 Service Unavailable

Временно не доступен — сервер временно не имеет возможности обрабатывать запросы по техническим причинам (обслуживание, перегрузка и прочее). 

В поле Retry‑After заголовка сервер укажет время, через которое  можно повторить запрос.

504 Gateway Timeout

Тайм‑аут шлюза —  сервер, выступая в роли шлюза или прокси‑сервера, не получил ответа от вышестоящего сервера в нужное время.

Исправить эту ошибку самостоятельно не получится. Здесь дело в прокси, часто — в веб‑сервере. 

Первым делом просто обновите веб‑страницу. Если это не помогло, нужно почистить DNS‑кэш. Для этого  нажмите горячие клавиши Windows+R и введите команду cmd (Control+пробел). В открывшемся окне укажите команду ipconfig / flushdns и подтвердите её нажатием Enter.

505 HTTP Version Not Supported

Сервер не поддерживает версию протокола — отсутствует поддержка текущей версии HTTP‑протокола. Нужно обеспечить клиента и сервер одинаковой версией.

506 Variant Also Negotiates

Неуспешные переговоры — с такой ошибкой сталкиваются, если сервер изначально настроен неправильно. По причине ошибочной конфигурации выбранный вариант указывает сам на себя, из‑за чего процесс и прерывается.

507 Insufficient Storage

Не хватает места для хранения — серверу недостаточно места в хранилище. Нужно либо расчистить место, либо увеличить доступное пространство.

508 Loop Detected

Обнаружен цикл — ошибка означает провал запроса и выполняемой операции в целом.

509 Bandwidth Limit Exceeded

Превышена пропускная способность —  используется при чрезмерном потреблении трафика. Владельцу площадки следует обратиться к своему хостинг‑провайдеру. 

510 Not Extended

Не продлён — ошибка говорит, что на сервере отсутствует нужное для клиента расширение. Чтобы исправить проблему, надо убрать часть неподдерживаемого расширения из запроса или добавить поддержку на сервер.

511 Network Authentication Required

Требуется аутентификация — ошибка генерируется сервером‑посредником, к примеру, сервером интернет‑провайдера, если нужно ввести пароль для получения доступа к сети через платную точку доступа.

psql -U postgres -h localhost -W

Password for user postgres: 

psql: FATAL:  password authentication failed for user "postgres"

FATAL:  password authentication failed for user "postgres"

12 ответов:

Частая проблема при подключении Android устройства к Wi-Fi сети — ошибка аутентификации. Также встречается уведомление: «Произошла ошибка проверки подлинности«, «Сохранено, Защищенная» или «Сохранено, защита WPA/WPA2«. В этой статье я хочу рассказать: что такое процедура аутентификации, почему возникает такая ошибка при подключении к Wi-Fi и какие есть способы ее устранения.

Содержание

1. Процедура аутентификации
2. Причины ошибки
3. Устранение неисправности
   1. В Android-устройстве
   2. В настройках роутера

Процедура аутентификации

Аутентификация Wi-Fi — это проверка ключа безопасности. После введения данных (в данном случае пароля от точки доступа Wi-Fi) проверяется идентификатор. Если он соответствует заданному, то устройство подключается к беспроводному интернету.

Эта процедура необходима, чтобы предотвратить несанкционированный доступ к частной Wi-Fi сети.

Причины ошибки

Активация точки доступа выглядит так: Подключение — Проверка подлинности (Аутентификация) — «Сохранено, Защищенная».

Чуть позже статус меняется на «Произошла ошибка проверки подлинности» или «Ошибка аутентификации» и подключение естественно не происходит.

Основных причин, из-за которых возникает «Ошибка аутентификации» при подключении к Wi-Fi на Android, всего две.

1. Первая связана с неверным идентификатором. Это значит, что пароль для точки доступа был неверно введен. Также ошибка возможна после смена пароля Wi-Fi в самом роутере — когда при автоматическом подключении к точке, подтягивается старый пароль.
2. Вторая связана с несоответствием типа шифрования данных. В данном случае проблема в настройках безопасности в самом роутере. Также ошибка может возникать из-за нестабильной работы самого устройства (которые особенно встречаются в дешевых моделях, например при подключении большого количества устройств к Wi-Fi).

Устранение неисправности

Для справки! В качестве примера используются смартфон Samsung Galaxy S4 под управлением Android 5.0.1 и роутер TP — Link TL-WR740N. Интерфейс ваших устройств может отличаться, но по аналогии вы легко найдете нужную информацию.

В Android-устройстве

Для начала:

• зайдите в «Настройки» — Сетевые подключения — Wi-Fi;
• нажмите на точку, к которой хотите подключиться и введите пароль;

  

• проверьте визуально активировав «Показывать пароль»: правильно ли соблюден регистр букв, не используется ли кирилица;

  

• если по нажатию на точку W-Fi происходит автоматическое подключение без возможности ввода нового пароля, нужно удалить сохраненные данные и ввести их заново;
• нажмите на сеть Wi-Fi и удерживайте некоторое время пока не появится всплывающее меню с функцией «Забыть сеть»;

  

• нажмите «Забыть» и введите пароль заново.

Совет! Если вы уверены, что вводимый вами пароль для точки доступа правильный и вы не ошибаетесь при его написании, вероятно, проблема в шифровании данных роутером. В таком случае в планшете никаких манипуляций делать не нужно.

В настройках роутера

Важно! Невозможность подключения Android к Wi-Fi сети и как следствие «Ошибка аутентификации», могут быть связаны с нестабильной работой самого роутера. Из-за перегрузки, сбоев на линии у провайдера, перепадов напряжения и т.д. роутер может работать со сбоями. Это лечится простой перезагрузкой устройства.

Подключите роутер к компьютеру/ноутбуку через тот же Wi-Fi или LAN-кабель:

• зайдите в любой браузер и в строке введите 192.168.1.1. или 192.168.0.1. (вход в панель управления роутером);
• по умолчанию, логин и пароль для входа «admin», если конечно, другое не указано в инструкции к роутеру или вы их не изменили;

  

• зайдите в «Беспроводной режим»;

  

• перейдите во вкладку «Защита беспроводного режима». Здесь вы можете сверить и изменить ваш пароль для Wi-Fi;

  

• для защиты домашнего Wi-Fi используйте только метод проверки подлинности WPA/WPA-2;

  

• для старых моделей смартфонов и планшетов желательно использовать смешанный режим 802.11 b/g вместо n, b/g/n или авто. Ищите этот пункт в настройках беспроводного режима. В редких случаях может помочь изменение региона.

  

Совет! Не забудьте после каждой манипуляции в настройках перезагружать роутер, чтобы изменения вступили в силу. После каждого изменения в настройках, пробуйте заново подключится к сети на Android.

Также обратите внимание на версию проверки подлинности. Попробуйте вместо WPA выставить только WPA-2 и наоборот. При этом используйте шифрование — AES.