Nano Hash - криптовалюты, майнинг, программирование

когда я подключаюсь по ssh к экземпляру RHEL7 AWS-EC2, я получаю «Отказано в доступе (publickey, gssapi-keex, gssapi-with-mic)»

Итак, я знаю, что этот вопрос задавался раньше. Я пробовал все, что было опубликовано в ближайшем связанном вопросе, и ничего из этого не сработало. Раньше мог зайти, а сейчас не могу. - Я пробовал ssh-соединение как с root@ipadress, так и с ec2-user@ipaddress, и это не сработало. Когда я использую root, он говорит мне использовать ec2-user. Я использую ssh из Ubuntu 16.04 — у меня есть правильные права доступа к моему файлу pem. - Кроме того, у меня нет файла /etc/sshd_special_user, и я не уверен, что его добавление что-то даст, но, похоже, он пытается аутентифицироваться против моего локального пользователя после первой неудачной попытки.
- Когда я ssh-keygen -f " ~/.ssh/known_hosts" -R xx.xx.xxx.xxx, я получаю mkstemp: No such file or directory. Я получаю это, даже если файл есть, и я могу открыть его в vim. Я действительно смущен тем, что здесь происходит, и я собираюсь включить в этот вопрос дополнительный подробный файл журнала. Я прочитал его и не уверен, почему он делает то, что делает.

вывод из ssh -vvv

-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1, OpenSSL 1.0.2g 1 марта 2016 г.

-debug1: Чтение данных конфигурации /etc/ssh/ssh_config

-debug1: /etc/ssh/ssh_config строка 19: Применение параметров для *

-debug2: разрешение порта 22 "52.53.159.22"

-debug2: ssh_connect_direct: нужно 0

-debug1: подключение к порту 22 52.53.159.22 [52.53.159.22].

-debug1: соединение установлено.

-debug1: key_load_public: нет такого файла или каталога

-debug1: файл идентификации .ssh/RH17-06-11.pem тип -1

-debug1: key_load_public: нет такого файла или каталога

-debug1: файл идентификации .ssh/RH17-06-11.pem-cert type -1

-debug1: включение режима совместимости для протокола 2.0

-debug1: строка локальной версии SSH-2.0-OpenSSH_7.2p2 Ubuntu-4ubuntu2.1

-debug1: удаленный протокол версии 2.0, удаленная версия программного обеспечения OpenSSH_6.6.1

-debug1: соответствие: OpenSSH_6.6.1 соответствует OpenSSH_6.6.1*, совместимость 0x04000000

-debug2: параметр fd 3 O_NONBLOCK

-debug1: Аутентификация на 52.53.159.22:22 как «пользователь ec2»

-debug3: hostkeys_foreach: чтение файла "/home/dingofarmers/.ssh/known_hosts"

-debug3: record_hostkey: найден тип ключа ECDSA в файле /home/dingofarmers/.ssh/known_hosts:21

-debug3: load_hostkeys: загружен 1 ключ с 52.53.159.22

-debug3: order_hostkeyalgs: предпочитать hostkeyalgs: [email protected], [email protected], [email protected], ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521

-debug3: отправить пакет: тип 20

-debug1: SSH2_MSG_KEXINIT отправлен

-debug3: получить пакет: тип 20

-debug1: SSH2_MSG_KEXINIT получен

-debug2: предложение KEXINIT локального клиента

-debug2: алгоритмы KEX: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange- sha1, диффи-хеллман-группа14-sha1, доб-информация-с

-debug2: алгоритмы ключа хоста: [email protected],[email protected],[email protected],ecdsa -sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,[email protected],[email protected],ssh-ed25519,rsa-sha2-512 ,rsa-sha2-256,ssh-rsa

-debug2: шифры ctos: [email protected], aes128-ctr, aes192-ctr, aes256-ctr, [email protected], [email protected], aes128-cbc, aes192-cbc, aes256-cbc, 3des-cbc

-debug2: исходный код шифров: [email protected],aes128-ctr,aes192-ctr,aes256-ctr,[email protected],[email protected],aes128-cbc,aes192-cbc, aes256-cbc, 3des-cbc

-debug2: главные администраторы MAC: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], hmac-sha2-256, hmac-sha2-512, hmac-sha1

-debug2: MAC-адреса: [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], [email protected], hmac-sha2-256, hmac-sha2-512, hmac-sha1

-debug2: технический директор по сжатию: нет, [email protected], zlib

-debug2: источник сжатия: нет, [email protected], zlib

-debug2: языки CTOS:

-debug2: языки сток:

-debug2: first_kex_follows 0

-debug2: зарезервировано 0

-debug2: предложение KEXINIT однорангового сервера

-debug2: алгоритмы KEX: [email protected],ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange- ша1, диффи-хеллман-группа14-ша1, диффи-хеллман-группа1-ша1

-debug2: алгоритмы ключа хоста: ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519

-debug2: шифры ctos: aes128-ctr, aes192-ctr, aes256-ctr, arcfour256, arcfour128, [email protected], [email protected], [email protected], aes128-cbc, 3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]

-debug2: исходный код шифров: aes128-ctr, aes192-ctr, aes256-ctr, arcfour256, arcfour128, [email protected], [email protected], [email protected], aes128-cbc, 3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,[email protected]

-debug2: главные администраторы MAC: [email protected],[email protected],[email protected],[email protected],hmac-sha2- [email protected],[email protected],[email protected],[email protected],hmac-md5-96-etm@ openssh.com,hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh. com, hmac-sha1-96, hmac-md5-96

-debug2: MAC-адреса: [email protected],[email protected],[email protected],[email protected],hmac-sha2- [email protected],[email protected],[email protected],[email protected],hmac-md5-96-etm@ openssh.com,hmac-md5,hmac-sha1,[email protected],[email protected],hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@openssh. com, hmac-sha1-96, hmac-md5-96

-debug2: технический директор по сжатию: нет, [email protected]

-debug2: источник сжатия: нет, [email protected]

-debug2: языки CTOS:

-debug2: языки сток:

-debug2: first_kex_follows 0

-debug2: зарезервировано 0

-debug1: kex: алгоритм: [email protected]

-debug1: kex: алгоритм ключа хоста: ecdsa-sha2-nistp256

-debug1: kex: server->client шифр: [email protected] MAC: сжатие: нет

-debug1: kex: клиент-> сервер шифр: [email protected] MAC: сжатие: нет

-debug3: отправить пакет: тип 30

-debug1: ожидается SSH2_MSG_KEX_ECDH_REPLY

-debug3: получить пакет: тип 31

-debug1: Ключ хоста сервера: ecdsa-sha2-nistp256 SHA256:qaPtcCft8A+sNZTbFvAsKBPQVvKRqdBYEV93An/SY+w

-debug3: hostkeys_foreach: чтение файла "/home/dingofarmers/.ssh/known_hosts"

-debug3: record_hostkey: найден тип ключа ECDSA в файле /home/dingofarmers/.ssh/known_hosts:21

-debug3: load_hostkeys: загружен 1 ключ с 52.53.159.22

-debug1: Хост «52.53.159.22» известен и соответствует ключу хоста ECDSA.

-debug1: найден ключ в /home/dingofarmers/.ssh/known_hosts:21

-debug3: отправить пакет: тип 21

-debug2: set_newkeys: режим 1

-debug1: сменить ключ после 134217728 блоков

-debug1: SSH2_MSG_NEWKEYS отправлено

-debug1: ожидается SSH2_MSG_NEWKEYS

-debug3: получить пакет: тип 21

-debug2: set_newkeys: режим 0

-debug1: сменить ключ после 134217728 блоков

-debug1: SSH2_MSG_NEWKEYS получен

-debug2: ключ: dingofarmers@ubuntu (0x55ce58f7d660), агент

-debug2: ключ: dingofarmers@ubuntu (0x55ce58f7e920), агент

-debug2: ключ: .ssh/RH17-06-11.pem ((ноль)), явный

-debug3: отправить пакет: тип 5

-debug3: получить пакет: тип 6

-debug2: service_accept: ssh-userauth

-debug1: SSH2_MSG_SERVICE_ACCEPT получен

-debug3: отправить пакет: введите 50

-debug3: получить пакет: введите 51

-debug1: Аутентификации, которые могут продолжаться: publickey, gssapi-keyex, gssapi-with-mic

-debug3: начать сначала, передать другой список publickey,gssapi-keyex,gssapi-with-mic

-debug3: предпочтительный gssapi-keyex, gssapi-with-mic, publickey, интерактивная клавиатура, пароль

-debug3: authmethod_lookup gssapi-keyex

-debug3: остальные предпочтительные: gssapi-with-mic,publickey,keyboard-interactive,password

-debug3: authmethod_is_enabled gssapi-keyex

-debug1: следующий метод аутентификации: gssapi-keyex

-debug1: нет допустимого контекста обмена ключами

-debug2: мы не отправляли пакет, отключить метод

-debug3: authmethod_lookup gssapi-с-микрофоном

-debug3: остальные предпочтительные: открытый ключ, интерактивная клавиатура, пароль

-debug3: authmethod_is_enabled gssapi-с-микрофоном

-debug1: следующий метод аутентификации: gssapi-with-mic

-debug1: Неизвестный сбой GSS. Вспомогательный код может предоставить дополнительную информацию Нет доступных учетных данных Kerberos

-debug1: Неизвестный сбой GSS. Вспомогательный код может предоставить дополнительную информацию Нет доступных учетных данных Kerberos

-debug1: Неизвестный сбой GSS. Второстепенный код может предоставить дополнительную информацию

-debug1: Неизвестный сбой GSS. Вспомогательный код может предоставить дополнительную информацию Нет доступных учетных данных Kerberos

-debug2: мы не отправляли пакет, отключить метод

-debug3: открытый ключ authmethod_lookup

-debug3: остальные предпочтительные: интерактивная клавиатура, пароль

-debug3: открытый ключ authmethod_is_enabled

-debug1: следующий метод аутентификации: открытый ключ

-debug1: Предложение открытого ключа RSA: dingofarmers@ubuntu

-debug3: send_pubkey_test

-debug3: отправить пакет: введите 50

-debug2: мы отправили пакет с открытым ключом, ждем ответа

-debug3: получить пакет: тип 51

-debug1: Аутентификации, которые могут продолжаться: publickey, gssapi-keyex, gssapi-with-mic

-debug1: Предложение открытого ключа RSA: dingofarmers@ubuntu

-debug3: send_pubkey_test

-debug3: отправить пакет: введите 50

-debug2: мы отправили пакет с открытым ключом, ждем ответа

-debug3: получить пакет: тип 51

-debug1: Аутентификации, которые могут продолжаться: publickey, gssapi-keyex, gssapi-with-mic

-debug1: Попытка закрытого ключа: .ssh/RH17-06-11.pem

-debug3: sign_and_send_pubkey: RSA SHA256:gwWpJTQxOFvICvYC7ILZ8rTnS9F/TjWaYCmxj6toatY

-debug3: отправить пакет: введите 50

-debug2: мы отправили пакет с открытым ключом, ждем ответа

-debug3: получить пакет: тип 51

-debug1: Аутентификации, которые могут продолжаться: publickey, gssapi-keyex, gssapi-with-mic

-debug2: мы не отправляли пакет, отключить метод

-debug1: больше не нужно пробовать методы аутентификации.

Отказано в доступе (publickey,gssapi-keyex,gssapi-with-mic).

ssh amazon-ec2 rhel7
31.08.2017

  • у вас есть файл key.pem, когда вы создали экземпляр в aws 31.08.2017
  • да у меня правильный файл key.pem и все статусы в aws зеленые. 31.08.2017
  • пожалуйста, проверьте ответ ниже 31.08.2017
  • Создайте AMI из этого экземпляра, запустите новый экземпляр из этого AMI (со свежим ключом), затем войдите в систему и проверьте журналы. Если запускать другой такой экземпляр небезопасно (например, из-за запущенных служб), просто присоедините этот том образа к другому пустому экземпляру и просмотрите журналы оттуда. 31.08.2017
  • попробовал новый экземпляр со старым ключом и другой экземпляр с новым ключом, и ни один из них не работал. 01.09.2017
  • Чтобы избавиться от побочных эффектов Kerberos, см. stackoverflow .com/questions/45130952/ › даже если это не решит проблему, вы получите чистый журнал. 02.09.2017
  • Я пробовал это также и ничего не получил. 09.09.2017

Ответы:


1

Переместите файл ключа в каталог .ssh

mv path/to/key.pem ~/.ssh/.

Затем убедитесь, что вы дали правильные разрешения на файл

chmod 600 ~/.ssh/key.pem

И подключиться к серверу по ssh

ssh -i ~/.ssh/key.pem ec2-user@instance_ip_address

31.08.2017
  • попробуй это sudo ssh -i ~/.ssh/key.pem ec2-user@instance_ip_address 31.08.2017
  • если добавление sudo работает, проверьте право собственности на файл key.pem 31.08.2017

    • 2

    Файл known_hosts обычно используется для записи ssh-ключей системного уровня серверов, к которым вы подключаетесь, а не для хранения закрытых ключей. Есть ли особая причина, по которой вы кладете туда свой закрытый ключ? Я бы, вероятно, полностью очистил каталоги ~/.ssh на клиенте и сервере (сначала сделав резервные копии) и начал бы с нуля, чтобы все было просто.

    На клиентском компьютере у вас обычно есть каталог ~/.ssh (разрешения 0700), ~/.ssh/id_rsa и ~/.ssh/id_rsa.pub (разрешения 0600) и файл известных хостов, который должен быть заполнен автоматически. каждый раз, когда вы подключаетесь по ssh к новой системе. Фактические имена файлов id_rsa, конечно, не критичны, если клиент ssh может их найти и проанализировать, но я никогда не пытался поместить их содержимое в файл, который уже что-то значит для ssh.

    На серверной машине у вас также будет каталог .ssh (снова разрешения 0700) и файл author_keys (разрешения 0600), который содержит текст ключа id_rsa.pub (или эквивалентного) из окна клиента.

    На клиенте и сервере:

    mkdir -p ~/.ssh
chmod 0700 ~/.ssh

    На клиенте:

    ssh-keygen -f ~/.ssh/id_rsa
scp ~/.ssh/id_rsa.pub [email protected]:~/.ssh/authorized_keys

    На сервере:

    chmod 0600 ~/.ssh/authorized_keys

    Затем попробуйте еще раз ssh -vvv. Если это не сработает, выполните следующую команду как на клиенте, так и на сервере и опубликуйте результаты:

    sudo grep -i key /etc/ssh/ssh*_config
    13.12.2017
    Новые материалы
    Кластеризация: более глубокий взгляд
    Кластеризация — это метод обучения без учителя, в котором мы пытаемся найти группы в наборе данных на основе некоторых известных или неизвестных свойств, которые могут существовать. Независимо от..
    Как написать эффективное резюме
    Предложения по дизайну и макету, чтобы представить себя профессионально Вам не позвонили на собеседование после того, как вы несколько раз подали заявку на работу своей мечты? У вас может..
    Частный метод Python: улучшение инкапсуляции и безопасности
    Введение Python — универсальный и мощный язык программирования, известный своей простотой и удобством использования. Одной из ключевых особенностей, отличающих Python от других языков, является..
    Как я автоматизирую тестирование с помощью Jest
    Шутка для победы, когда дело касается автоматизации тестирования Одной очень важной частью разработки программного обеспечения является автоматизация тестирования, поскольку она создает..
    Работа с векторными символическими архитектурами, часть 4 (искусственный интеллект)
    Hyperseed: неконтролируемое обучение с векторными символическими архитектурами (arXiv) Автор: Евгений Осипов , Сачин Кахавала , Диланта Хапутантри , Тимал Кемпития , Дасвин Де Сильва ,..
    Понимание расстояния Вассерштейна: мощная метрика в машинном обучении
    В обширной области машинного обучения часто возникает необходимость сравнивать и измерять различия между распределениями вероятностей. Традиционные метрики расстояния, такие как евклидово..
    Обеспечение масштабируемости LLM: облачный анализ с помощью AWS Fargate и Copilot
    В динамичной области искусственного интеллекта все большее распространение получают модели больших языков (LLM). Они жизненно важны для различных приложений, таких как интеллектуальные..