[РЕШЕНО] ssh авторизация по ключу
Стоит проверить конфиг sshd ( /etc/ssh/sshd_config)на предмет :
RSAAuthentication yes
PubkeyAuthentication yes
Также в var/log/auth.log может осядут попытки неудачных авторизаций
Еще странно, что «No more authentication methods to try.» Пароль-то почему не спрашивает, по дефолту всяко должен. что в конфиге менялось еще?
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug3: start over, passed a different list publickey,password,keyboard-interactive
debug3: preferred publickey
debug3: authmethod_lookup publickey
debug3: remaining preferred:
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /Users/user/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Trying private key: /Users/user/.ssh/id_dsa
debug3: no such identity: /Users/user/.ssh/id_dsa: No such file or directory
debug1: Trying private key: /Users/user/.ssh/id_ecdsa
debug3: no such identity: /Users/user/.ssh/id_ecdsa: No such file or directory
debug1: Trying private key: /Users/user/.ssh/id_ed25519
debug3: no such identity: /Users/user/.ssh/id_ed25519: No such file or directory
debug2: we did not send a packet, disable method
debug1: No more authentication methods to try.
Permission denied (publickey,password,keyboard-interactive).
/home папка зашифрована, расшифровывается она когда запущена сессия. Есть какой-то принятый флоу для хранения ключей?
Как решить ошибку Invalid API Key provided pyowm?
простенький скрипт чтоб узнать погоду
решил дописать в него прогноз, полез в документацию и начал тестить,беру код оттуда, вставил свой апи ключ, и мне пишет что он не валиден.
Создал еще раз ключ, снова та же проблема
код из документации :
ну проверю еще раз сейчас, может и правда
проверил, не работает всеравно.
Да что ж такое, что ему все не так
Насколько понимаю, для бесплатных ключей не все способы доступны. Например forecast нужно делать через OneCall API
вставил просто эту переменную и оно не пашет, как ее туда впихнуть?
тут видимо без id города надо как-то обойтись, или что?
за ответ спасибо большое, проверил все работает, но вот собственно проблема сверху
o5a, тогда другой вопрос, оно на русском или нет?
с каких пор Москва а конкретно «М» это не буква)
оно не на русском, это да
Алексей Фобиус, по поводу Киева оно наверное хочет Kyiv
Я за модулем не слежу, но по описанию видно, что при работе через OneCall запрос города понимает только английский, т.к. там по факту идет запрос к базе данных.
Но насколько вижу, можно это обойти через некие костыли: получить данные города через weather_at_place, которая понимает русские названия, а затем уже их использовать для OneCall.
o5a, ахахахахахха, костыли наше все
кстати да, сработало, ахаххаха
Invalid identity public key майнкрафт
неверный идентификационный ключ общественной сети может..
Символ показывает уровень знания интересующего вас языка и вашу подготовку. Выбирая ваш уровень знания языка, вы говорите пользователям как им нужно писать, чтобы вы могли их понять.
Мне трудно понимать даже короткие ответы на данном языке.
Могу задавать простые вопросы и понимаю простые ответы.
Могу формулировать все виды общих вопросов. Понимаю ответы средней длины и сложности.
Понимаю ответы любой длины и сложности.
Решайте свои проблемы проще в приложении!
( 30 698 )
Аутентификация на сетевом оборудовании через SSH с помощью публичных ключей
По умолчанию инженеры подключаются к сетевому оборудованию с помощью имени пользователя и пароля. По протоколу Telnet учетные данные пользователя передаются в открытом виде, а по протоколу SSH в зашифрованном. Чтобы не передавать секретную часть по сети, используется аутентификация по публичным ключам. При такой аутентификации публичный ключ пользователя заранее прописывается пользователю на оборудовании. Секретный ключ по сети не передается.
Это руководство поможет вам быстро начать использовать публичные ключи для аутентификации при подключении к сетевому оборудованию по протоколу SSH. Руководство применимо как для Windows, так и для Mac OS X. Я постарался сделать его максимально простым и информативным. Оно не перегружено, но отвечает на основные вопросы:
Содержание
Введение
Кроме стандартной аутентификации по паролю (password/keyboard) в протоколе SSH существует также аутентификация по публичному ключу (RSA).
Аутентификация с помощью RSA-ключей состоит из нескольких этапов:
Документ Secure Shell Configuration Guide, Cisco IOS Release 15E:
Secure Shell Configuration Guide, Cisco IOS Release 15E
Restrictions for Secure Shell Version 2 Support
Rivest, Shamir, and Adleman (RSA) key generation is an SSH server-side requirement. Devices that act as SSH clients need not generate RSA keys.
Попытка ввести данные DSA-ключа:
Создание публичного RSA-ключа
Пару RSA-ключей можно создать с помощью различных утилит: SecureCRT, PuTTYgen или любым другим ПО. При создании ключа можно задать Passphrase (защита ключа с помощью пароля).
Генерирование RSA-пары в SecureCRT
SecureCRT → Tools → Create Public Key…:
Чуть-чуть теории → кнопка “Next >”:
Тип сертификата RSA/DSA → Выбираем RSA → кнопка “Next >”:
Пароль шифрования для секретного ключа (необязательно, можно оставить пустым и не шифровать) + Комментарий → кнопка “Next >”:
Выбираем длину ключа (в версии SecureCRT 6.1.0 максимальная длина ключа равна 2048 бит, в версии 8.5.4 — 16 384 бит):
Генерирование ключа → кнопка “Next >”:
Для генерирования случайных чисел нужно просит поводить мышкой в рамках окна.
Сохранение пары ключей → Выбор места хранения → Выбор формата сохраняемого ключа (VanDuke Private format, OpenSSH legacy, OpenSSH new) → кнопка “Finish”:
SecureCRT спрашивает, делать ли данный ключ ключом по умолчанию для SecureCRT:
Генерирование RSA-пары в PuTTYgen
Выбираем параметры (тип пары: RSA; битная размерность ключа: 2048; по желанию задаём Passphrase (защита ключа с помощью пароля)) → Generate:
Для гарантирования случайных чисел просит поводить мышкой в рамках окна. Это защита от псевдослучайных чисел.
Сохраняем RSA-ключи → Кнопка «Save private key»:
Обратите внимание: RSA-ключи, сохраненные в частном формате в одном ПО, нельзя использовать в ПО другого производителя. То есть пара RSA-ключей, созданных в PuTTYgen и сохраненных в формате Putty Private Key, не подходит для использования в SecureCRT, и наоборот. PuTTY поддерживает только формат Putty Private Key. Универсальным решением для распространения ключей является конвертирование ключей в формат OpenSSH (Смотри ссылку 2: “Conversion from Putty to SecureCRT with auth. keys”). Т. к. SecureCRT свободно работает с форматом OpenSSH. А ПО PuTTYgen преобразует формат OpenSSH в формат Putty Private Key.
Конвертирование RSA-ключа из формата Putty Private Key (PuTTY) в формат OpenSSH (SecureCRT)
Чтобы использовать в SecureCRT RSA-ключи, которые сгенерированы в PuTTYgen и сохранены в формате Putty Private Key (*.ppk), экспортируем их с помощью PuTTYgen в формат OpenSSH:
Конвертирование RSA-ключа из формата VanDyke Private Key (SecureCRT) в формат Putty Private Key (PuTTY)
Чтобы использовать в PuTTY RSA-ключи, которые сгенерированы в SecureCRT и сохранены в формате VanDyke Private Key (файл публичного ключа — *.pub, файл секретного ключа *. (без расширения)), экспортируем их с помощью SecureCRT в формат OpenSSH, а затем с помощью PuTTYgen экспортируем в формат Putty Private Key (*.ppk):
Генерирование публичных ключей на MAC OS X средствами операционной системы
Будем использовать встроенную утилиту ssh-keygen (man ssh-keygen).
Генерируем RSA-ключ с длиной 2048 бит с указанием имени ключа, путем к папке с местом хранения ключа:
Во время выполнения программа спросит пароль для защиты RSA-ключа:
Генерируем RSA-ключ с длиной 4096 бит в с указанием имени ключа, путем к папке с местом хранения ключа, пароль задаем в явном виде в параметрах генерации ключа (-N «cisco»):
Не рекомендуемые параметры генерации ключей: ненадёжный ключ длиной 1024 бита, с указанием имени ключа, путем к папке с местом хранения ключа, пароль задаем в явном виде в параметрах генерации ключа (-N «» – без пароля):
Итак, мы создали три ключа в с указанием имен ключей и указанием места хранения ключей (по умолчанию все ключи сохраняются в /Users/[Username]/.ssh).
По умолчанию, при подключении по SSH с аутентификацией по публичному ключу, происходит последовательный перебор всех публичных ключей, которые хранятся в папке /Users/[Username]/.ssh.
Ключ R6: переименуем ключ в “id_rsa” (по умолчанию имя файла генерируемого ключа “id_rsa”) и перенесем в папку с SSH-ключами (
/.ssh/) (Т. е. выполним все действия, чтобы ключ R6 использовался как основной ключ для подключений по SSH по умолчанию):
Преобразуем публичный OpenSSH-ключ в формат RFC4716 (экспорт в Cisco IOS):
Применение публичного ключа на оборудовании
Как на различном оборудовании привязать открытый ключ к пользователю?
Процесс привязки публичного ключа к пользователю не стандартный и меняется от оборудования к оборудованию, поэтому приведены примеры для каждого типа оборудования, которое чаще всего применяется в сети.
Cisco IOS XE, Catalyst (с версии 15.1 и выше), IOS
Cisco ASA
Весь ключ вставляем в одну строчку (OpenSSH формат).
Маршрутизаторы и коммутаторы Huawei
Типы форматов ключей, импортируемых на Huawei:
“The SecureCRT and PuTTY generate RSA keys in PEM format.”
“The OpenSSH generates RSA keys in OpenSSH format.”
“The OpenSSL generates RSA keys in DER format.”
По умолчанию — в шестнадцатеричном виде:
Примечание: оборудование Huawei поддерживает не только ключи в формате RSA, но и другие форматы:
Можно жестко задать тип аутентификации для пользователя по SSH:
То есть мы разрешаем доступ с помощью либо пароля, либо публичных и приватных ключей, либо и того, и другого.
Huawei USG (6000)
Конфигурация полностью аналогична настройкам на маршрутизаторе, но имеет некоторые особенности.
По умолчанию уровень привилегий после журналирования с использованием сертификатов равен 0 и повышению не поддается. Поэтому уровень приоритета задается с помощью
Cisco Nexus 9.3
Вариант 1: предустанавливаем файл публичного ключа на устройство и привязываем файл публичного ключа к пользователю.
Вариант 2: копируем публичный ключ пользователю:
Использование секретного ключа для подключения по SSH
Этот раздел посвящен настройке SSH-клиентов для аутентификации по RSA-ключам на сетевом оборудовании (или другом оборудовании, при условии, что оборудование и ПО поддерживает аутентификацию по публичным ключам).
Мы рассмотрим настройку использования публичного ключа в самых популярных программах: SecureCRT и PuTTY.
SecureCRT
В окне настроек SSH есть список Authentication. В нём необходимо увеличить приоритет PublicKey до самого высокого — сделать верхним в списке.
Затем перейдите в параметры PublicKey и выберите файл приватного ключа. Самый верхний переключатель позволяет использовать глобальные настройки секретного ключа или сеансовые настройки — другой секретный ключ (ключ не по умолчанию) — только для этого подключения.
Настраиваем глобальный публичный ключ: в меню Options → Global options → Категория SSH2.
PuTTY
В настройках SSH (Connection → SSH → Auth) в поле “Private key file for authentication” укажите файл Putty Private Key (*.ppk):
MAC OS X
Настройка стандартного клиента для использования публичных ключей:
Как упростить работу с SSH на MAC OS X:
Заполняется таким образом:
Примечание: у меня некорректно настроено подключение по умолчанию (как правильно, я не знаю), потому что подключение к хосту R6 (10.31.73.31) выполняется очень долго. Рекомендуется указать сразу указать путь к ключу по умолчанию.
Пример подключения по ssh используя публичные ключи и файл config:
Заключение
RSA-ключи могут использоваться для замены аутентификации по паролю, но не во всех случаях:
На некотором оборудовании одному пользователю может соответствовать несколько пар публичных ключей, на другом оборудовании одному пользователю соответствует только один публичный ключ.
Также разнятся форматы, в которых хранится пара из публичного и секретного ключа. Но это руководство поможет вам экспортировать ключи в разные форматы.
Сегодня оптимально использовать ключи длиной 2048 бит, но для некоторого оборудования это максимально возможная длина ключа (быть может, в новых прошивках это исправят). Например:
Рекомендуется использовать публичные ключи для замены паролей, если пароли вводятся с помощью скриптов (пример: autologon в SecureCRT).
Рекомендуется использовать публичные ключи для защиты от передачи пароля по сети.
Некоторое ПО по умолчанию использует публичные ключи для аутентификации по SSH вместо пароля (пример: Ansible).
Binance Futures Invalid API-key, IP, or permissions for action #7263
Comments
cadmufasa commented Jul 13, 2020
I am trying to connect to the Futures servers on Binance (and access the contents in the Futures Wallet)
I had created the API key several times on Binance.
When attempting to connect, I get:
MESSAGE : ERR-52D073683
So, I CHANGED the WORKING API KEY so that it would process FUTUREs request too. I REMOVED the NEW key
I still got the same error:
When attempting to connect, I get:
MESSAGE : ERR-52D073683
I used to have a white-listed IP Address but I have removed that option (in an effort to figrue out what is going wrong).
I was not sure if it had something to do with the API servers being used.
What other things can I try to figure out what the problem is. Why is it taking place?
Any help, hints or advice would be greatly appreciated.
I have the following code below :
— initialize the connection
def initialize_connection( in_futures = False):
— getting the balances:
def get_bank_balances(in_futures = False, in_symbol = », print_info = False):
try :
— error message
The text was updated successfully, but these errors were encountered:
We are unable to convert the task to an issue at this time. Please try again.
The issue was successfully created but we are unable to update the comment at this time.