SSH

Содержание статьи
Подключение по SSH
Генерация пары ключей
Какой ключ куда
Передать ключ на удалённый хост
ssh-copy-id
Проверить ключ
Узнать версию OpenSSH в Linux
Выполнить команду из скрипта на удалённом компьютере
known_hosts
Создать SSH туннель
Демонстрация работы туннеля
Список всех открытых SSH туннелей
SSH_MSG_USERAUTH_BANNER
WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!
The authenticity of host X can't be established.

Подключение по SSH

Подключение происходит с помощью команды ssh + имя_пользователя + хост

Например

ssh andrei@192.168.0.2

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

The authenticity of host '192.168.56.101 (192.168.56.101)' can't be established. ECDSA key fingerprint is SHA256:db8az/qbrWOJWvNRv2d9UHaDBnnUHanJ9Svca9vFx7c. Are you sure you want to continue connecting (yes/no/[fingerprint])?

Если выбрать yes то в файл ~/.ssh/known_hosts добавится похожая строка:

|1|abcdef+abcdefghijklmnopqrst=|abcdefghijklmnopqrstuvwxyz1= ssh-rsa abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrst/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz12345/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzB1234567

Обычно файл known_hosts имеет следующий формат (записи идут через пробел)

{server-id} ssh-rsa {public-key-string} {comment}

Таким образом

abcdef+abcdefghijklmnopqrst=|abcdefghijklmnopqrstuvwxyz1=

Это хэш от имени сервера.

Здесь через пробел записаны три элемента: хэш от имени сервера, название используемого ассиметричного алгоритма и публичный ключ сервера. Разберём их по очереди.

Сгенерировать пару ключей

Первый шаг - это генерация пары ключей. Обычно это делается на клиентской машине. Например, на вашем ноутбуке.

Основная команда ssh-keygen создаст 2048-битную пару RSA ключей. Для большей надёжности можно добавить флаг -b 4096

Выполните

ssh-keygen -b 4096

Чтобы сгенерировать ключ в /home/$(whoami)/.ssh

или

sudo ssh-keygen -b 4096

Чтобы сгенерировать ключ в /home/root/.ssh

Generating public/private rsa key pair. Enter file in which to save the key (/root/.ssh/id_rsa):

Нужно придумать имя ключа.

Я назову ключ andrei-key101 а сохранять буду в текущую директорию.

Enter file in which to save the key (/root/.ssh/id_rsa): andrei-key101 Enter passphrase (empty for no passphrase): Enter same passphrase again:

Нужно два раза ввести пароль. Если он вам нужен. Обычно нет.

Your identification has been saved in andrei-key101 Your public key has been saved in andrei-key101.pub The key fingerprint is: SHA256:abcd/abcdefghijklmnopqrstuvwxyz1234567890ab root@urn-su The key's randomart image is: +---[RSA 4096]----+ |=o oo++ | |= oo o. = o | |+ | |Oo=o . . | |B+.o S . | |+o.o | |+.0. . | |o+= . E | |+=oo. . . | +----[SHA256]-----+

Ключи готовы. Я сохранил их в текущую директорию поэтому увижу их сделав ls

ls

andrei-key101 andrei-key101.pub

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

Какой ключ куда?

.pub ключ отправляйте на удалённую машину

приватный ключ храните на своём клиенте

Передать ключ на удалённый хост

После того, как ключи созданы нужно передать .pub ключ на удалённый хост.

Сделать это можно несколькими способами начнём с утилиты ssh-copy-id

ssh-copy-id

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

sudo ssh-copy-id -i ~/.ssh/andrei-key.pub andrei@192.168.0.2

/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/[fingerprint])?

Введите yes

Are you sure you want to continue connecting (yes/no/[fingerprint])? 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 andrei@192.168.0.2's password:

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

Number of key(s) added: 1 Now try logging into the machine, with: "ssh 'andrei@192.168.0.2'" and check to make sure that only the key(s) you wanted were added.

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

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

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

ssh -i ~/.ssh/andrei-key andrei@192.168.0.2

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

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

Ошибки

/usr/bin/ssh-copy-id: ERROR: No identities found

Скорее всего не найдет путь до ключа. Укажите его явно с помощью флага -i

Пример

Узнать версию OpenSSH в Linux

Чтобы узнать версию OpenSSH в вашем дистрибутиве Linux выполните

ssh -V

OpenSSH_7.4p1, OpenSSL 1.0.2k-fips 26 Jan 2017

Выполнить команду из скрипта на удалённом компьютере

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

#!/bin/bash ssh andrei@192.168.0.2 "ls;cd /home/andrei/bash_scripts;ls;ip a;cal"

Если нужно выполнить команду, требующую sudo попробуйте флаг -t

#!/bin/bash ssh -t andrei@192.168.0.2 "sudo apt upgrade"

known_hosts

Список известных хостов находится в файле known_hosts

Полный путь:

/home/$(whoami)/.ssh/known_hosts

Обычно файл known_hosts имеет следующий формат (записи идут через пробел) ( подробнее )

{server-id} алгоритм {public-key-string} {comment}

Примеры алгоритмов: ssh-rsa, ssh-dss, ssh-ed25519, ecdsa-sha2-nistp256

Пример строки:

|1|abcdef+abcdefghijklmnopqrst=|abcdefghijklmnopqrstuvwxyz1= ssh-rsa abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrst/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz12345/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzB1234567

Таким образом

abcdef+abcdefghijklmnopqrst=|abcdefghijklmnopqrstuvwxyz1=

Это хэш от имени сервера.

ssh-rsa

Это алгоритм шифрования

abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrst/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyz12345/abcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzabcdefghijklmnopqrstuvwxyzB1234567

Это публичный ключ хоста

Ошибки и предупреждения

WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!

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

ssh user@192.168.1.2

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 "[192.168.56.103]:1234" ED25519 host key for [192.168.56.103]:1234 has changed and you have requested strict checking. Host key verification failed.

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

Выполните

ssh-keygen -f "/home/username/.ssh/known_hosts" -R "[192.168.56.103]:1234"

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

Создать 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 andrei@192.168.0.2

The authenticity of host '192.168.0.2 (192.168.0.2)' can't be established.
ECDA …

andrei@192.168.0.2'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 andrei@192.168.0.2

Демонстрация

Туннель создан, не закрывайте терминал. Откройте два новых терминала или две новые вкладки в старом.

У вас два пустых терминала, оба на локальном хосте. Назовём их 1 и 2.

Из терминала 2 подключимся к удалённому хосту 192.168.0.2 по ssh и будем слушать на порту 9200 с помощью nmap

ssh andrei@192.168.0.2
nmap -l 9200

На терминале 1 с помощью nmap отправим сообщение на порт 9119 локального хоста. Это тот порт, который мы настроили на проброс.

nmap localhost 9119

Введём любой текст

heihei.ru

Откройте терминал 2 там дожен появиться тот же текст

heihei.ru

Список всех открытых SSH туннелей

Чтобы получить список туннелей открытых именно ssh выполните

sudo lsof -i -n | egrep '\<ssh\>'

ssh 14695 andrei 3u IPv4 230080 0t0 TCP 192.168.0.1:46356->192.168.0.2:ssh (ESTABLISHED) ssh 14695 andrei 4u IPv6 230103 0t0 TCP [::1]:9119 (LISTEN) ssh 14695 andrei 5u IPv4 230104 0t0 TCP 127.0.0.1:9119 (LISTEN)

Вывод этой команды при практически идентичных условиях почему-то разный.

Ниже пример второго варианта. Если вы знаете почему так получается - напишите в комментариях.

ssh 15151 andrei 3u IPv4 239364 0t0 TCP 192.168.0.1:46464->192.168.0.2:ssh (ESTABLISHED) ssh 15151 andrei 4u IPv6 239380 0t0 TCP [::1]:mxit (LISTEN) ssh 15151 andrei 5u IPv4 239381 0t0 TCP 127.0.0.1:mxit (LISTEN) ssh 15151 andrei 9u IPv6 239428 0t0 TCP [::1]:mxit->[::1]:54306 (ESTABLISHED)

Закрыть все SSH туннели

Чтобы закрыть всё, что связано с ssh можно выполнить

sudo killall ssh sshd

Этот метод хорош только если вы работаете один, например на какой-то виртуальной машине.

Запустить 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, а в самом конце поставить &

SSH_MSG_USERAUTH_BANNER

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

Спецификация rfc4252

Выполните

sudo vi /etc/issue.net

И отредактируйте файл добавив свой баннер

\S Kernel \r on an \m ######################################################### # ANDREYOLEGOVICH.RU and URN.SU # #########################################################

Откройте sshd_config и укажите путь до баннера

sudo vi /etc/ssh/sshd_config
/banner

# no default banner path #Banner none

Этот баннер будет показан ДО авторизации, то есть во время ввода пароля

Чтобы создать баннер, который будет показан после успешного входа выполните

sudo vi /etc/motd

######################################################### # YOU ARE HERE: urn.su/linux/ssh.php # #########################################################

После редактирования файлов перезапустите sshd

sudo systemctl restart sshd.service

The authenticity of host X can't be established.

Если вы видите в логах подключения следующую ошибку

The authenticity of host '192.168.56.103 (192.168.56.103)' can't be established.

Первым делом перейдите в ~/.ssh и проверьте наличие и содержание файла known_hosts а также права на него.

cd ~/.ssh
ls -la
vi known_hosts

Существующие версии OpenSSH

OpenSSH 8.2 FEATURE: Add FIDO/U2F Support OpenSSH 8.1, released in October 2019 ssh, sshd, ssh-agent: add protection for private keys at rest in RAM against speculation and memory side-channel attacks like Spectre, Meltdown and Rambleed. OpenSSH 8.0, released in April 2019 SECURITY: CVE-2019-6111 related to scp tool and protocol allowing to overwrite arbitrary files in the scp client target directory OpenSSH 7.9, released in October 2018 allow key revocation lists (KRLs) to revoke keys specified by SHA256 hash OpenSSH 7.8, released in August 2018 Incompatible changes: ssh-keygen write OpenSSH format private keys by default instead of using OpenSSL's PEM format. OpenSSH 7.7, released in February 2018 FEATURE: Add "expiry-time" option in sshd for authorized_keys files to allow for expiring keys. OpenSSH 7.6, released in October 2017 FEATURE: Add RemoteCommand option FEATURE: Add SyslogFacility option to ssh matching the equivalent option in sshd FEATURE: ssh client reverse dynamic forwarding -R OpenSSH 7.5, released in March 2017 BUGFIX: This is a mainly a bugfix release. OpenSSH 7.4, released Template:Release date and age sshd(8): Add a sshd_config DisableForwarding option OpenSSH 7.3, released August 01, 2016 FEATURE: Adds ProxyJump option (-J) FEATURE: Add an Include directive for ssh_config(5) files OpenSSH 7.1: August 20, 2015 This is a bugfix release. OpenSSH 7.0: August 11, 2015 The focus of this release is primarily to deprecate weak, legacy and unsafe cryptography. OpenSSH 6.9: July 1, 2015 BUGFIX: This is primarily a bugfix release. OpenSSH 6.8: March 18, 2015 Added new hostkeys@openssh.com extension to facilitate public key discovery and rotation for trusted hosts (for transition from DSA to Ed25519 public host keys) AuthenticationMethods=publickey,publickey to require that users authenticate using two different public keys OpenSSH 6.7: October 6, 2014 The default set of ciphers and MACs has been altered to remove unsafe algorithms. In particular, CBC ciphers and arcfour* are disabled by default. Compile-time option to not depend on OpenSSL Add support for Unix domain socket forwarding OpenSSH 6.6: March 16, 2014 This is primarily a bugfix release. OpenSSH 6.5: January 30, 2014 Added new ssh-ed25519 and ssh-ed25519-cert-v01@openssh.com public key types (available since 2005 but more popular since some suspicious that NSA had chosen values that gave them an advantage in factoring public-keys) Added new chacha20-poly1305@openssh.com transport cipher Added curve25519-sha256@libssh.org key exchange FEATURE: ssh, added Match keyword for ssh_config that allows conditional configuration to be applied FEATURE: client-side hostname canonicalisation: CanonicalDomains, CanonicalizeFallbackLocal, CanonicalizeHostname, CanonicalizeMaxDots and CanonicalizePermittedCNAMEs. Add a new private key format that uses a bcrypt KDF OpenSSH 6.4: November 8, 2013 This release fixes a security bug with AES-GCM OpenSSH 6.3: September 13, 2013 This release is predominantly a bugfix release OpenSSH 6.2: March 22, 2013 Add a GCM-mode for the AES cipher, similar to RFC 5647 Added support for encrypt-then-mac MAC modes Added support for multiple required authentication methods Added support for Key Revocation Lists (KRL) OpenSSH 6.1: August 29, 2012 This is primarily a bugfix release. Enables pre-auth sandboxing by default Finds ECDSA keys in ssh-keyscan and SSHFP DNS records by default now OpenSSH 6.0: April 22, 2012 This is primarily a bugfix release. OpenSSH 5.9: September 6, 2011 Introduce sandboxing of the pre-auth privilege separated child OpenSSH 5.8: February 4, 2011 OpenSSH 5.7: January 24, 2011 Added support for elliptic curve cryptography for key exchange as well as host/user keys, per RFC 5656 OpenSSH 5.6: August 23, 2010 Added a ControlPersistoption to ssh_config OpenSSH 5.5: April 16, 2010 OpenSSH 5.4: March 8, 2010 Disabled SSH protocol 1 default support. Clients and servers must now explicitly enable it. Added PKCS11 authentication support for ssh(1) (-I pkcs11) Added Certificate based authentication Added "Netcat mode" for ssh(1) (-W host:port). Similar to "-L tunnel", but forwards instead stdin and stdout. This allows, for example, using ssh(1) itself as a ssh(1) ProxyCommand to route connections via intermediate servers, without the need for nc(1) on the server machine. Added the ability to revoke public keys in sshd(8) and ssh(1). While it was already possible to remove the keys from authorised lists, revoked keys will now trigger a warning if used. OpenSSH 5.3: October 1, 2009 OpenSSH 5.2: February 23, 2009 OpenSSH 5.1: July 21, 2008 Added a MaxSessions option to sshd_config OpenSSH 5.0: April 3, 2008 OpenSSH 4.9: March 30, 2008 Added chroot support for sshd(8) Create an internal SFTP server for easier use of the chroot functionality OpenSSH 4.7: September 4, 2007 - Ubuntu 8.04 OpenSSH 4.6: March 9, 2007 OpenSSH 4.5: November 7, 2006 OpenSSH 4.4: September 27, 2006 OpenSSH 4.3: February 1, 2006 Added OSI layer 2/3 tun-based VPN (-w option on ssh(1)) OpenSSH 4.2: September 1, 2005 OpenSSH 4.1: May 26, 2005 OpenSSH 4.0: March 9, 2005 OpenSSH 3.9: August 18, 2004 Implement session multiplexing. ControlMaster option Added a MaxAuthTries option to sshd, allowing control over the maximum number of authentication attempts permitted per connection Added IdentitiesOnly option to ssh which specifies that it should use keys specified in ssh_config, rather than any keys in ssh-agent Re-introduce support for PAM password authentication OpenSSH 3.8: February 24, 2004 OpenSSH 3.7.1: September 16, 2003 OpenSSH 3.7: September 16, 2003 rhosts authentication has been removed in ssh(1) and sshd(8). OpenSSH 3.6.1: April 1, 2003 OpenSSH 3.6: March 31, 2003 OpenSSH 3.5: October 14, 2002 OpenSSH 3.4: June 26, 2002 OpenSSH 3.0: Improved Kerberos support in protocol v1 (KerbIV and KerbV) OpenSSH 2.9.9: OpenSSH 2.5.1p1: February 19, 2001 SkeyAuthentication absoleted, use ChallengeResponseAuthentication instead. OpenSSH 1.2.2p1: March 5, 2000

Поиск по сайту

Контакты и сотрудничество:
Рекомендую наш хостинг beget.ru
Пишите на info@urn.su если Вы:
1. Хотите написать статью для нашего сайта или перевести статью на свой родной язык.
2. Хотите разместить на сайте рекламу, подходящуюю по тематике.
3. Реклама на моём сайте имеет максимальный уровень цензуры. Если Вы увидели рекламный блок недопустимый для просмотра детьми школьного возраста, вызывающий шок или вводящий в заблуждение - пожалуйста свяжитесь с нами по электронной почте
4. Нашли на сайте ошибку, неточности, баг и т.д. ... .......
5. Статьи можно расшарить в соцсетях, нажав на иконку сети: