Ошибки ssh в ubuntu

About SSH key generation

If you don’t already have an SSH key, you must generate a new SSH key to use for authentication. If you’re unsure whether you already have an SSH key, you can check for existing keys. For more information, see «Checking for existing SSH keys.»

If you want to use a hardware security key to authenticate to GitHub, you must generate a new SSH key for your hardware security key. You must connect your hardware security key to your computer when you authenticate with the key pair. For more information, see the OpenSSH 8.2 release notes.

If you don’t want to reenter your passphrase every time you use your SSH key, you can add your key to the SSH agent, which manages your SSH keys and remembers your passphrase.

ssh-copy-id

Я предпочитаю использовать с флагом -i и задавать путь до нужного ключа

sudo ssh-copy-id -i ~/.ssh/andrei-key.pub [email protected]

/usr/bin/ssh-copy-id: INFO: Source of key(s) to be installed: «/home/andrei/.ssh/andrei-key.pub»
The authenticity of host ‘192.168.0.2 (192.168.0.2)’ can’t be established.
ECDSA key fingerprint is SHA256:abcdefgh1234567890abcdefgh1234567890abc+def.
Are you sure you want to continue connecting (yes/no/)?

Введите yes

Are you sure you want to continue connecting (yes/no/)? yes
/usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed
/usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed — if you are prompted now it is to install the new keys
[email protected]’s password:

Введите пароль

Number of key(s) added: 1

Now try logging into the machine, with: «ssh ‘[email protected]′»
and check to make sure that only the key(s) you wanted were added.

Теперь на хосте 192.168.0.2 в файле
/home/andrei/.ssh/authorized_keys
появилась новая запись вида

ssh-rsa AAAAB3NzaC1y … lseP/jXcq … Uydr/2CwQ &hellip ++TpY19pHqD/AnhL … Az62T/Ipyx … 8U2T [email protected]

Знак … заменяет длинные последовательности случайных символов для экономии места.

Проверить ключ можно командой

ssh -i ~/.ssh/mykey user@host

В нашем случае

ssh -i ~/.ssh/andrei-key [email protected]

Если вы не задавали пароль для ключа, то попадёте на удалённый хост без лишних движений

Last login: Sun Jan 10 16:48:27 2021 from 192.168.0.1

Конвертация сертификатов

Рассмотрим простой пример: вы достали из

базы данных

сертификат
MIIC4jCCAc … A7A6Rpt8V9Q==
, но он не отформатирован и не проходит валидацию

Сертификат, конечно, длиннее, я поставил троеточие для экономии места и вашего времени.

Выполните

echo ‘MIIC4jC … 7A6Rpt8V9Q==’ | base64 -d | openssl x509 -inform der

Либо, если вам нужно работать с файлами — сохраните исходный сертифика в фай

raw_cert

echo MIIC4jC … 7A6Rpt8V9Q== > raw_cert

cat raw_cert | base64 -d | openssl x509 -inform der > cert

cat cert

——BEGIN CERTIFICATE——
MIIC4jC … 7A6Rpt8V9Q==
——END CERTIFICATE——

Такого же результата можно было добиться аккуратно добавив ——BEGIN CERTIFICATE—— в начало
и ——END CERTIFICATE—— в конец файла, но не всегда всё так просто.

Невозможность проверки ключа хоста

При создании SSH-соединения протокол требует, чтобы стороны идентифицировали себя. Бывает так, что от сервера поступает следующая ошибка:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:doBAKL304WyMd8hnFc9a29r3nX9okS9BlrBJcHtuyNk.
Please contact your system administrator.
Add correct host key in /root/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in /root/.ssh/known_hosts:14
ECDSA host key for 212.45.27.201 has changed and you have requested strict checking.
Host key verification failed.

Эта ошибка может возникать по нескольким причинам:

переустановка SSH-сервера и неполная его конфигурация;
восстановление сервера из резервной копии;
изменение IP-адреса сервера.

Очистка ключей хостов помогает решить эту проблему. Сами эти ключи хранятся на стороне клиента в файле . Для очистки можно удалить все записи вручную. Либо можно использовать команду:

$ ssh-keygen -R host_ip

Эта команда попытается очистить соответствующую информацию о ключе хоста в файле known_hosts:

Host 123.123.123.123 found: line 14
/home/john/.ssh/known_hosts updated.
Original contents retained as /home/john/.ssh/known_hosts.old

После этих действий можно попробовать снова выполнить подключение к серверу SSH.

Generating a new SSH key for a hardware security key

If you are using macOS or Linux, you may need to update your SSH client or install a new SSH client prior to generating a new SSH key. For more information, see «Error: Unknown key type.»

Insert your hardware security key into your computer.
Open .
Note: If the command fails and you receive the error or you may be using a hardware security key that does not support the Ed25519 algorithm. Enter the following command instead.
When you are prompted, touch the button on your hardware security key.
When you are prompted to «Enter a file in which to save the key,» press Enter to accept the default file location.
When you are prompted to type a passphrase, press Enter.
Add the SSH key to your account on GitHub. For more information, see «Adding a new SSH key to your GitHub account.»

Ssh-copy-id on Mac

While MacOS includes SSH, it does not include out of the port. However, according to some sources MacOS 10.12.4 includes it, and presumably newever versions include it as well.

You can test whether your Mac has it by opening a terminal window (Finder / Go / Utilities / Terminal) and typing .

If your system does not have it, there are many ways to install ssh-copy-id Mac version.

Installation using Curl

The following command can be used to install a Mac version directly. Note that as a general rule we do not recommend piping any commands from the network to the shell, like this does. Only use this method if you fully trust the source. The advantage of this method is that it does not need any special software — comes preinstalled.

10 ответов

-1

Проблема заключалась в том, что RSAAuthentication была отключена в /etc /ssh /ssh_config

9/10 раз это потому, что ~ /.ssh /authorized_keys не находится в правильном режиме.

Завершите /etc /ssh /sshd_config, чтобы разрешить аутентификацию с помощью ключа. У вас должно быть что-то в этом роде и убедитесь, что строки не комментируются:

PS: не забудьте перезапустить sshd после изменения файла (перезапуск /etc/init.d/sshd)

Я не эксперт здесь, но столкнулся с такой проблемой, вот мои два цента дополнительно ко всем остальным предложениям.

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

Вот цитата из справочных страниц :

Итак, в основном вы хотите проверить, что:

Ваш агент аутентификации системы (обычно ssh-agent) видит ключи, которые вы собираетесь использовать (проверьте вывод)
скопировал тот же ключ на удаленном компьютере (просто войдите на удаленный сервер с помощью пароля и проверьте содержимое —- +: = 3 = + —-)

Надеюсь, что это поможет.

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

Если это не проблема, запустите и посмотрите на представление клиента о разговоре. В частности, проверьте, что клиент пытается использовать ключ с сервером.

Я обнаружил, что в моей системе проблема заключалась в том, что каталог пользователя (/home /username) был оснащен неправильным набором разрешений. Это был , и ему нужно было (с разрешением на запись только для владельца). Решение заключалось в использовании chmod:

В дополнение ко всему вышесказанному всегда можно проверить файл журнала sshd:

в моем случае /etc /ssh /sshd_config содержал следующий параметр:

Но ssh-copy-id создал файл с именем authorized_keys, поэтому мне пришлось изменить запись на новое имя. подробнее о устаревшие authorized_keys2

Я пробовал другие исправления, но обнаружил, что мне пришлось изменить домашний каталог, чтобы другие записи не были доступны для записи.
Домашний каталог был 777.
Я изменил его на 755, и он сработал.

В качестве дополнения к Omer Dagan ответьте на новый CentOS 7, используйте:

для просмотра журналов sshd на сервере.

Choosing a good passphrase

You need to change all your locks if your RSA key is stolen. Otherwise the thief could impersonate you wherever you authenticate with that key.

An SSH key passphrase is a secondary form of security that gives you a little time when your keys are stolen. If your RSA key has a strong passphrase, it might take your attacker a few hours to guess by brute force. That extra time should be enough to log in to any computers you have an account on, delete your old key from the .ssh/authorized_keys file, and add a new key.

Your SSH key passphrase is only used to protect your private key from thieves. It’s never transmitted over the Internet, and the strength of your key has nothing to do with the strength of your passphrase.

The decision to protect your key with a passphrase involves convenience x security. Note that if you protect your key with a passphrase, then when you type the passphrase to unlock it, your local computer will generally leave the key unlocked for a time. So if you use the key multiple times without logging out of your local account in the meantime, you will probably only have to type the passphrase once.

If you do adopt a passphrase, pick a strong one and store it securely in a password manager. You may also write it down on a piece of paper and keep it in a secure place. If you choose not to protect the key with a passphrase, then just press the return when ssh-keygen asks.

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

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

ssh [email protected]

ERROR: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ERROR: @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
ERROR: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
ERROR: IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
ERROR: Someone could be eavesdropping on you right now (man-in-the-middle attack)!
ERROR: It is also possible that a host key has just been changed.
ERROR: The fingerprint for the ECDSA key sent by the remote host is
ERROR: SHA256:abcde/accdefghijkld9UNaDBnnUHanJ9Svca9vFx7c.
ERROR: Please contact your system administrator.
ERROR: Add correct host key in /home/user/.ssh/known_hosts to get rid of this message.
ERROR: Offending ECDSA key in /home/user/.ssh/known_hosts:3
ERROR: remove with:
ERROR: ssh-keygen -f «/home/user/.ssh/known_hosts» -R «192.168.1.2»
ERROR: ECDSA host key for 192.168.1.2 has changed and you have requested strict checking.
ERROR: Host key verification failed.

Из строки

ERROR: Offending ECDSA key in /home/user/.ssh/known_hosts:3

Можно понять, что проблема вызвана третьей строкой файла

/home/user/.ssh/known_hosts

Если вы уверены в надёжности хоста к которому подключаетесь, то
можете просто удалить эту строку и подключиться снова

sed -i 3d /home/$(whoami)/.ssh/known_hosts

ssh-keygen -R 192.168.1.2

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

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ED25519 key sent by the remote host is
SHA256:nN5D5mBv00vkinsOmKbaKN1o2dEVZj5BidWaKBY1LpA.
Please contact your system administrator.
Add correct host key in /home/username/.ssh/known_hosts to get rid of this message.
Offending ED25519 key in /home/username/.ssh/known_hosts:14
remove with:
ssh-keygen -f «/home/username/.ssh/known_hosts» -R «:1234»
ED25519 host key for :1234 has changed and you have requested strict checking.
Host key verification failed.

В этом случае подсказка по-прежнему содержится в предупреждении (выделил её зелёным).

Выполните

ssh-keygen -f «/home/username/.ssh/known_hosts» -R «:1234»

# Host :1234 found: line 14
/home/username/.ssh/known_hosts updated.
Original contents retained as /home/username/.ssh/known_hosts.old

Как установить команду ssh-copy-id

Инструмент ssh-copy-id, часть пакета OpenSSH, доступен во всех основных репозиториях дистрибутива Linux, и вы можете использовать свой менеджер пакетов для установки этой команды.

Чтобы установить инструмент ssh-copy-id в Debian, используйте следующую команду:

sudo apt-get update && sudo apt-get install openssh-client

После установки OpenSSH вы можете использовать инструмент ssh-copy-id в командной строке.

$ ssh-copy-id

Usage: /usr/bin/ssh-copy-id  ]   ...] hostname         -f: force mode -- copy keys without trying to check if they are already installed         -n: dry run    -- no keys are actually copied         -h|-?: print this help

Использовать ssh-copy-id просто, потому что сценарий делает процесс аутентификации с открытым ключом более простым и эффективным. Прежде чем мы углубимся в то, как использовать инструмент, мы сначала обсудим, как работает аутентификация с открытым ключом SSH.

Примечание
Если вы уже знаете, как работает аутентификация с открытым ключом SSH, можете пропустить эту часть и подробнее узнать, как сразу же использовать команду ssh-copy-id.

Создать SSH туннель

Туннели обычно создают для перенаправления траффика. SSH tunnel это то же самое что и SSH port forwarding.

Допустим вы хотите направить траффик со своего localhost (127.0.0.1) на
удалённый
хост 192.168.0.2.

На

удалённом

хосте у вас есть пользователь с именем andrei и вы знаете его пароль.

Сперва нужно определиться с портами на локальном хосте и на удалённом.

Предположим, вы выбрали 9119 для локального и
9200 для

удаленного
хостов.

То есть вы хотите, чтобы всё, что идёт на localhost:9119 было перенаправлено на
192.168.0.2:9200

Выполните

ssh -L 9119:192.168.0.2:9200 [email protected]

The authenticity of host ‘192.168.0.2 (192.168.0.2)’ can’t be established.

ECDA …

…

[email protected]’s password:

Last login: Sun Jan 31 13:23:00 2021

Проверьте ip выполнив

ip a

Если вам нужен туннель с поддержкой графического интерфейса

X Window System

используйте флаг -X

ssh -X -L 9119:192.168.0.2:9200 [email protected]

Запустить SSH в фоновом режиме

Существует несколько способов запустить ssh соединение в фоновом режиме — то есть освободим текущий терминал.

-L, screen, tmux, nohup

Мне запустить ssh фоном из скрипта помог nohup, поэтому начнём с него

nohup ssh user@host «cd scripts;python3 my_script.py $ARG1 $ARG2; exit» &

Для чего это было нужно: Python скрипт сначала
открывал одно ssh соединение из
subprocess
там выполнялась команда для запуска

мониторинга потребления памяти

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

Чтобы уйдя из первого подключения не оборвать мониторинг потребления памяти
перед ssh нужно было добавить nohup, а в самом конце поставить &