Сетевая служба SSH в ОС Linux

Служба W:[SSH] предназначена для организации безопасного (secure) доступа к сеансу командного интерпретатора (shell) удаленных сетевых узлов. Изначально разрабатывалась как замена небезопасным R-утилитам W:[Rlogin], W:[Rsh] и протоколу сетевого алфавитно-цифрового терминала W: [telnet].

При сетевом взаимодействии в «открытой» публичной сети, такой как Интернет, «безопасность» обычно понимают как конфиденциальность (плюс целостность) передаваемых данных и аутентичность (подлинность) взаимодействующих сторон.

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

Сеансовый ключ устанавливается обеими взаимодействующими сторонами при помощи асимметричного алгоритма открытого согласования ключей (W:[протокол Диффи —Хеллмана]), использующего две пары дополнительных ключей. Обе стороны взаимодействия случайным образом выбирают закрытые ключи и на их основе вычисляют парные открытые ключи, которыми публично обмениваются. Общий (сеансовый) ключ вычисляется каждой стороной на основе своего закрытого ключа и чужого открытого ключа, что не может повторить третья сторона, т. к. может подслушать только передачу открытых ключей и не владеет закрытыми ключами участников взаимодействия. Обратная задача вычисления закрытых ключей на основе открытых ключей практически не решаема, на чем и основывается вся асимметричная криптография.

При активном вмешательстве третьей, стороны во взаимодействие путем перехвата и подмены сообщений согласования ключей, злоумышленник может выдавать себя за другую сторону каждому из участников взаимодействия, став посредником, см. W:[MITM] (man in the middle).

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

Обеспечение подлинности (аутентичности) взаимодействующих сторон в протоколе SSH основывается на аутентификации сервера клиентом при помощи асимметричных алгоритмов цифровой подписи с использованием закрытого и открытого ключей сервера. Закрытый ключ используется для подписывания сообщений, а парный ему открытый ключ — для проверки подписи, корректность которой удостоверяет в том, что сообщение было сгенерировано подлинным владельцем закрытого ключа.

В сообщение протокола Диффи — Хеллмана сервер добавляет свой открытый ключ цифровой подписи (так называемый host key), а само сообщение подписывает закрытым ключом. Клиент извлекает этот открытый ключ Из сообщения и с помощью проверки корректности его цифровой подписи удостоверяется в  подлинности владельца вложенного ключа. Остается только убедиться, что владельцем вложенного ключа и является целевой сервер.

В примере из листинга ниже иллюстрируется первое присоединение к SSH-серверу grex.org (162.202.67.158), в результате чего был получен открытый ключ алгоритма W:[ECDSA], который, возможно, действительно принадлежит этому серверу, а не злоумышленнику посередине соединения.

Единственный способ это проверить — заранее знать действительный открытый ключ SSH-сервера grex.org и побитно сверить его с присланным ключом, что достаточно затруднительно сделать человеку. Поэтому на практике сверяют короткие хэш-суммы действительного и присланного ключей, называемые «отпечатками пальца» (fingerprint), совпадение которых гарантирует совпадение ключей. При этом подобрать другой ключ с такой же хэш-суммой практически невозможно.

Хэш-суммы открытых ключей SSH-серверов заранее известны и открыто публикуются, например для grex.org — на Web-странице http://grex.cyberspace.org/faq.xhtnl#sshfinger. После ручной сверки ключа О при первом подключении он сохраняется в файле ~/.ssh/known_hosts для автоматической сверки при последующих подключениях.

Первое присоединение к SSH-серверу

lunpy@ubuntu:~$ ssh [email protected]

The authenticity of host ‘grex.org (162.262.67.158)’ can’t be established.

ECDSA key fingerprint is 30:82:50:ba:6c:26:68:01:52:64:dc:54:83:8e:95:7e.

Are you sure you want to continue connecting (yes/nо)? yes ↵

Warning: Permanently added ‘grex.org,162.202.67.158’ (ECDSA) to the list of known hosts.

[email protected]’s password: P@s$wOrd 

grex$ uname -а ↵

OpenBSD grex.org 5.0 GENERIC.MP#0 1386

grex$ whoami 

jake

grex$ w ↵

8:40AM    up 86 days,     8:33,     15 users,    load averages: 1.41, 1.17, 1.03

USER         TTY  FROM                           LOGIN     IDLE   WHAT

cross            p4    spitfire.i.gajen            23Dec15           0   -bash

jake               pf    95-55-86-216. dyn    8:37AM            0     w

pbbl              q6   192.94.73.30           Mon05AM          0    alpine

ilk                 q8    99-194-162-175.d        1:34AM     7:05    screen-r

grex$ tty

/dev/ttypf

grex$ logout↵

Connection to grex.org closed.

lunpy@ubuntu:-*$

После успешного установления соединения SSH пользовательский сеанс аутентифицируется одним из способов, например с помощью пароля в, а затем в интерактивном режиме запускается начальный командный интерпретатор аутентифицированного пользователя.

При этом на стороне сервера используется псевдотерминал  и эмулируется терминальный вход в систему, считающийся сетевым.

Выполнение отдельной команды

lumpy@ubuntu:~$ ssh [email protected] uptime

[email protected]’s password: P@s$W0fd ↵

8:44AM up 86 days, 8:37, 15 users, load averages: 1.33, 1.19, 1.06

lumpy@ubuntu:~$

Кроме интерактивного сетевого входа, SSH позволяет удаленно выполнять отдельные команды, при этом псевдотерминал не используется, а терминальный вход не эмулируется. Вместо этого стандартные потоки ввода-вывода STDIN, STDOUT и STDERR выполняемой команды просто перенаправляются через сетевое соединение ssh-клиенту.

Это зачастую используется для удаленного копирования файлов. Например, в листинге ниже при помощи архиватора tar создается сжатый архив каталога /usr/src/sys на удаленном узле grex.org, а результат перенаправляется в локальный файл openbsd-kernel-source.tgz.

Копирование при помощи ssh

lumpy@ubuntu:~$ ssh [email protected] tar сzf — /usr/src/sys > openbsd-kernel-source.tgz

[email protected]’s’password: P@s$W0fd ↵

tar: Removing leading / from absolute path names in the archive

lumpy@ubuntu:~$

Аутентификация пользовательского сеанса по паролю имеет некоторое неудобство — необходимость вводить пароль заново при; каждом новом соединении SSH. Кроме того, пароль передается внутри соединения SSH, поэтому существует угроза подбора пароля злоумышленником.

Более прогрессивный способ аутентификации пользователя основан на использовании асимметричных алгоритмов цифровой подписи (аналогично аутентификации сервера в протоколе Дйффи — Хеллмана) и ключей пользователя.

Для этого открытый ключ пользователя единожды регистрируется на сервере, а при аутентификации подписывается его закрытым ключом и высылается серверу повторно. Сервер в свою очередь проверяет цифровую подпись присланного ключа и удостоверяется в подлинности его владельца, а побитное сравнение с заранее зарегистрированным ключом пользователя указывает на то, что владелец присланного ключа и есть целевой пользователь.

В листинге ниже иллюстрируется процедура применения ключей аутентификации пользователя. Сначала при помощи команды ssh-keygen генерируется закрытый (private) W:[RSA]-icni04 в локальном файле ~/.ssh/td_rsa и парный ему открытый (public) ключ в локальном файле ~/.ssh/id_rsa.pub.

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

Затем при помощи команды ssh-copy-id открытый ключ регистрируется на удаленном сервере grex.org в файле ~/.ssh/authortzed_keys, что происходит с предъявлением пароля. Последующие SSH-соединения аутентифицируются парой ключей, в результате отпадает необходимость вводить пароль. Появляется необходимость вводить парольную фразу, но в примере она (непозволительно) пустая.

Доступ по ключу

lumpy@ubuntu:~$ ssh-keygen

Generating public/private rsa key pair.

Enter file in which to save the key (/home/lumpy/. ssh/id_rsa): ↵

Enter passphrase (empty for no passphrase):  ↵

Enter same passphrase again:  ↵

Your identification has been saved in /hone/lunpy/. ssb/id_rsa.

Your public key has been saved in /hone/lunpy/.ssh/id_rsa.pub.

The key fingerprint is:

b5:27:3a:cc:6c:bl:70:lf:90:cc:a4:dc:le:c8:26:d4 lumpy@ubuntu

lumpy@ubuntu:~$ ssh-copy-id [email protected]

[email protected]*s password: P@s$w0rd  ↵

Now try logging into the machine, with «ssh ‘[email protected]'», and check in:

~/.ssh/authorized_keys

to make sure we haven’t added extra keys that you weren’t expecting.

lumpy@ubuntu:~$ ssh [email protected] ls

OPENME.txz

README.gz

lumpy@ubuntu:~$ ssh [email protected] zcat README.gz

А в файле OPENME.txz находится кое-что полезное 😉

lunpy@ubuntu:~$ ssh [email protected] file OPENME.txz

OPENME.txz: data

Использовать зашифрованные парольными фразами ключи и одновременно не вводить парольную фразу при каждом подключении позволяет SSH-агент ssh—agent, который удерживает в оперативной памяти расшифрованные единожды закрытые ключи пользователя и генерирует с их помощью цифровые подписи по запросу.

Листинг ниже иллюстрирует аутентификацию пользователя по ключу, защищенному парольной фразой, а затем передачу этого расшифрованного ключа агенту при помощи команды ssh-add, что позволяет избавиться от необходимости ввода парольной фразы ключа все время, пока запущен процесс ssh-agent (обычно — до окончания сеанса).

Наличие SSH-агента, запущенного в сеансе пользователя, обнаруживают две переменные окружения — SSH_AGENT_PID и SSH_AUTH_SOCK, содержащие соответственно PID агента и имя локального сокета для связи с ним.

SSH-агент

lumpy@ubuntu:~$ ssh [email protected] file /usr/bin/ssh

Enter passphrase for key  ‘/home/lumpy/.ssh/id_rsa’: …    …    …   …   …   …. ↵

/usr/bin/ssh: ELF 32-bit LSB executable, Intel 80386, version 1, for OpenBSD, dynamically

linked (uses shared libs), stripped

lumpy@ubuntu:~$ ssh-add 

Enter passphrase for /home/lumpy/.ssh/id_rsa: …    …    …   …   …   …. ↵

Identity added: /home/lumpy/.ssh/id_rsa (/home/lumpy/.ssh/id_rsa)

lumpy@ubuntu:~$ ssh [email protected] Idd /usr/bin/ssh

/usr/bin/ssh:

Start     End             Type  Open  Ref  GrpRef  Name

1c000000     3C017000  exe     1          0      0            /usr/bin/ssh .

0dbc0000     2dbc4000 rlib     0          1      0           /usr/lib/libgssapi.so.5.0

01cc6000      2lcd3000   rlib    0          1       0          /usr/lib/libkrb5. so. 18.0

0098a000    209c7000   rlib    0         1        0         /usr/lib/libcrypto.so.19.0

0al48000      2al4f000    rlib     0         1       0         /usr/lib/libz.so.4.1

0b61a000     2b648000   rlib     0        1        0        /usr/lib/libc.so.60.1

0890e000     0890e000  rtld     0        1       0        /usr/libexec/ld.so

lunpy@ubuntu:~$ env | grep SSH

SSH_AGENT_PID=21655

SSH_AUTH_S0CK=/tinp/ssh-Eehhsbx21654/agent. 21654

lumpy@ubuntu:~$ ls -l /tmp/ssh-Eehhsbx21654/agent.21654

srw——— 1  lumpy lumpy 0 марта 28 23:07 /tmp/ssh-Eehhsbx21654/agent.21654

Протокол SSH получил широкое распространение далеко за рамками своего изначального предназначения. Кроме непосредственного удаленного доступа, он используется другими командами для своих нужд. Например, команды scp и sftp используют ssh для безопасного сетевого копирования файлов, команда rsync — для сетевой синхронизации (копирование изменившихся) файлов.

Все эти (и другие, подобные им) команды используют ssh для запуска некоторой «серверной» программы на удаленном узле (в частности scp и rsync запускают сами себя, a sftp запускает sftp-server)л с которой и взаимодействуют через защищенное соединение.

Копирование файлов поверх SSH

lumpy@ubuntu:~$ scp *.pdf [email protected]:
tcpdump.pdf ,                                                               100%       37KB      37.3KB/s     00:00
Wireshark_Display_Filters.pdf                               100%       38KB      38.0KB/s    00:06
lumpy@ubuntu:~$ sftp [email protected]

Connected to grex.org.

sftp> is
OPENME.txz                                                           README.gz
Wtreshark_Display_Filters.pdf                          linuxperftools.png
tcpdump.pdf

sftp> exit

lumpy@ubuntu:~$ rsync -avrz [email protected]:/usr/share/man/man1 .
receiving incremental file list
man1/
man1/Mail.1

man1/sparc64/mksuncd.1
man1/vax/
man1/zaurus/
sent 10646 bytes        received 4796404 bytes          27081.97,bytes/sec

total size is 14861868    speedup is 3.09

Как оказывается на практике, использование «файловой» надстройки sftp-server для безопасного доступа к дереву каталогов удаленных узлов имеет достаточно широкое распространение. В частности, терминальный файловый менеджер mc, W:[MidnightCommander], тоже является SSH:sftp-клиентом.

Более того, при помощи FUSE-файловых систем sshfs или gvfs, файлы SSHisftp-cepвepoв могут быть смонтированы в дерево каталогов так, что вообще любые программы смогут ими воспользоваться.

Сетевая служба SSH в ОС Linux: 1 комментарий

  1. Уведомление: Сетевые интерфейсы, протоколы и сетевые сокеты Linux | Debian GNU/Linux

Добавить комментарий