Служба 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в могут быть смонтированы в дерево каталогов так, что вообще любые программы смогут ими воспользоваться.
Уведомление: Сетевые интерфейсы, протоколы и сетевые сокеты Linux | Debian GNU/Linux