Невозможно войти без пароля даже с ключом SSH

В файле /etc/ssh/sshd _config на хосте должен быть параметр аутентификации с открытым ключом. Раскомментируйте и установите «да»

Убедитесь, что вы редактируете конфигурацию /etc/ssh/sshd _на хосте, а не конфигурацию /etc/ssh/ssh _. Вторые файлы предназначены только для клиентов

При необходимости обратитесь к администратору хоста A

Вам нужен только закрытый ключ на Bдля входа в A. Не генерируйте ключ в удаленной системе A. Удаленной системе не нужно знать вашу личную личность.

Вы хотите войти в систему Aиз B. Это означает, что~/.ssh/authorized_keysв системе Aдолжен содержать открытый ключ (, чтобы вы могли ввести ). Системе Bэтот файл не нужен локально, чтобы вы могли войти в систему A.

Обратите внимание, что вам необходимо убедиться, что ~/.sshна обоих хостах имеет разрешения 700и что файлы внутри имеют 600разрешения (, включая ~/.ssh/authorized_keysнаA).

Кроме того, чтобы на самом деле использовать ключ в файле ~/.ssh/server-B.comна Bдля входа в A, вам нужно будет использовать sshкак

ssh -i ~/.ssh/server-B.com  a-user@server-A.com

Либо запустите ssh-agentи добавьте к нему ключ:

eval "$( ssh-agent )"
ssh-add ~/.ssh/server-B.com

ssh a-user@A-system.com

И/или добавьте запись в ~/.ssh/configна Bдля системы A, например

Host A
    User a-user
    Hostname server-A.com
    IdentityFile %d/.ssh/server-B.com

, а затем используйте

ssh A

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

Ну, вы не все перепутали, только часть.

Для использования аутентификации клиента с помощью открытого ключа (криптографии )в SSH:

• у вас должен быть файл приватного ключа на клиенте--вашем Б.

  Лучше всего сгенерировать ключ на клиенте. Что ты сделал, генерировать на сервере и копировать, не рекомендуется, но будет работать.

  Наилучшей практикой является использование стандартных имен файлов (в зависимости от «типа» алгоритма )на клиенте--~/.ssh/id_rsaдля RSA (в v2 ), ~/.ssh/id_ecdsaдля ECDSA и т. д. ssh-keygenсделает это по умолчанию, если запустится на клиенте. Использование другого имени, как вы сделали, означает, что вы должны указывать имя файла каждый раз, когда запускаете ssh, например ssh -i ~/.ssh/server-B.com user@host [command...], или в противном случае настройте свой файл конфигурации, чтобы указать это как вашеIdentityFile(либо глобально, либо для конкретного хоста ).

  Файл закрытого ключа должен быть недоступен для других пользователей. AFAICS ваш chmodправильно понял.

• вы поместили публичный ключ в ~/.ssh/authorized_keysНА СЕРВЕР--ваш А.

  Использование cat >>, как правило, хорошо, так как оно сохраняет все существующее содержимое и добавляет новую строку. Если существуют строки, которые (вы уверены )в устаревших --для ключей или пользователей, которые больше не используются или не авторизованы --, вы можете удалить их, чтобы сохранить порядок, но это не нужно.

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

• удаление записи для сервера (A )из файла known_hostsна клиенте (B )требуется только в том случае, если ключ сервера изменен или устарел. Это не связано с аутентификацией клиента. Делая это без необходимости, если вы не позаботитесь о том, чтобы вручную проверить отпечаток ключа сервера при следующем запросе, может дать злоумышленнику возможность перехватить, украсть,и изменить свои данные.

Таким образом, если вы исправите authorized_keysна сервере (A )и запустите ssh -i ~/.ssh/server-B.com user@serveranameна клиенте (B ), и если вас попросят проверить отпечаток сервера, это должно сработать. Если это не так, запустите несколько опций -v, как прокомментировал Haxiel, чтобы получить подробности. В частности, если он не видит указанный ключевой файл (, также известный как identityfile ), перепроверьте разрешения с помощью ls -l.