ловушка "ctrl -c", чтобы убить фоновую оболочку

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

Для использования аутентификации клиента с помощью открытого ключа (криптографии )в 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.