@ Карта сайта News Автора!

Bog BOS: SSH и OpenSSH: принципы работы, установка и настройка

apache inn MySQL nntpcache Cyrus IMAP exim Squid ssh syslog tacacs ProFTPD wu-ftpd xntpd

Последние изменения:
2024.03.28: sysadmin: Файловая система zfs под Linux для архива (обновление от 0.6 до 2.2)

Последнее изменение файла: 2024.03.26
Скопировано с www.bog.pp.ru: 2024.04.27

Bog BOS: SSH и OpenSSH: принципы работы, установка и настройка

SSH обеспечивает в небезопасной среде (Интернет) безопасную возможность удаленного входа и удалённого выполнения команд (вместо telnet, rsh, rlogin, rexec и всего, что над ним построено - rsync, rdist и т.д.) и копирования файлов (вместо rcp, ftp) с аутентификацией и клиента и сервера, с шифрованием (и, возможно, сжатием) передаваемых данных. Для аутентификации и согласования ключей используется алгоритм ассиметричной криптографии RSA (патент истёк), DSA/DH. Защищает от атак с подделкой (spoof) IP-адресов (включая source routing), DNS-сервера и маршрутизации, от подслушивания паролей и X аутентификации, от подслушивания и манипуляции данными на промежуточных хостах или локальной сети. Образованный безопасный канал можно использовать для других протоколов (встроена поддержка X11 Server). Можно использовать для организации VPN (PPP поверх SSH). SSH не защищает, если атакующий получил права суперпользователя на вашем хосте (подмена клиента) или доступ к домашнему каталогу (можно защититься шифрованием приватных ключей парольной фразой). Необходимо самостоятельно следить за соответствием публичного ключа сервера реальному серверу (в будущем, предполагается использовать систему сертификатов PKI).

SSH1 (SSH 1.3, SSH 1.5, 1995) и SSH2 (1996) - совершенно разные протоколы, использование SSH1 не рекомендуется:

Рекомендуется предварительное знакомство с обзором алгоритмов шифрования.

Остатки текста касательно SSH1 скрыты в комментариях.

Принципы работы SSH

Используемые порты: 22/tcp (22/udp - это ошибка в /etc/services).

Определены протоколы транспортного уровня, аутентификации [клиента] (поверх транспортного протокола) и соединения (поверх протокола аутентификации, мультиплексирует каналы данных). Имена алгоритмов и протоколов записываются в US-ASCII. Имена пользователей - в ISO-10646 UTF-8.

Протокол транспортного уровня работает поверх TCP, обеспечивает аутентификацию сервера, конфиденциальность и целостность передачи. В начале сессии клиент и сервер обмениваются версиями (1.99 - это 2.0, совместимая с 1.3 и 1.5).

Аутентификация сервера производится с использованием ассиметричного шифрования с открытым ключом. Алгоритм обмена ключами согласуется между клиентом и сервером (приоритет задаётся клиентским списком):

NSA не рекомендует (2017) эллиптические кривые 256 и менее, AES-128, SHA-256 и менее, RSA 2048 и менее, DH 2048 и менее. Готовится обновление RFC, в котором единственным обязательным алгоритмом обмена ключей указан diffie-hellman-group14-sha256.

В качестве ключа сессии используется случайная строка, которую клиент генерирует, шифрует с помощью открытого ключа сервера и передаёт серверу (сервер знает свой частный ключ и дешифрует строку, затем передаёт её клиенту, если строка дешифрована правильно, значит сервер настоящий). DH позволяет обеспечить PFS (perfect forward secrecy) - знание текущего сессионного ключа или приватного ключа не позволяет дешифровать предыдущие сеансы. Каждая сессия получает уникальный случайный идентификатор, что не позволяет повторно "проигрывать" данные других сессий.

Формат (алгоритм) открытого ключа (сертификата) сервера согласуется между клиентом и сервером (приоритет задаётся клиентским списком):

База открытых ключей серверов ведётся клиентом (его надо откуда-то получить и проверять в дальнейшем) или получается от сервера и заверяется корневым сертификатом (certification authority (CA)). В любой момент клиент или сервер могут запросить повторный обмен ключами, при этом заново согласуются алгоритм обмена ключами, формат открытого ключа, ключ сервера, алгоритмы хеширования, шифрования и сжатия, но идентификатор сессии не изменяется. RFC-4344 рекомендует повторно обмениваться ключами после 2^32 пакетов в любую сторону или каждый гигабайт.

После обмена ключами клиент запрашивает сервис:

Симметричное шифрование начинается после аутентификации сервера, но до аутентификации клиента, т.е. паролей в открытом виде не передаётся вовсе. Доступ злоумышленника к приватному ключу сервера позволяет ему имитировать сервер. Фальшивый сервер тихо установив соединение может запрашивать пароль или парольную фразу приватного ключа пользователя.. Алгоритм шифрования в каждую сторону согласуется между клиентом и сервером (приоритет задаётся клиентским списком):

Алгоритм проверки целостности (MAC) согласуется между клиентом и сервером отдельно для каждого направления (приоритет задаётся клиентским списком), при вычислении хеша (передаётся без шифрования) используется ключ (?), номер пакета и его содержимое до шифрования:

Предусматривается возможность сжатия перед шифрованием. Алгоритм сжатия в каждую сторону согласуется между клиентом и сервером (приоритет задаётся клиентским списком), начальный список SSH2: none, zlib. Предприняты героические попытки отложить начало сжатия до аутентификации клиента.

Каждый хост (сервер) должен иметь не менее одной пары ключей (м.б. общими для нескольких хостов) для каждого формата ассиметричного шифрования (DSA/RSA/ecdsa/ed25519). Ключ сервера не генерируется. При наличии нескольких серверов их ключи придётся различать по номеру прослушиваемого порта.

RFC-4255, RFC-6594, RFC-7479 определяют возможность проверить отпечаток (fingerprint) публичного ключа сервера с помощью DNSSEC (запись ресурса SSHFP (44) - номер алгоритма (1 - RSA, 2 - DSA, 3 - ECDSA, 4 - Ed25519), тип отпечатка (1 - SHA-1, 2 - SHA-256), отпечаток).

Протокол аутентификации [клиента] (сервис ssh-userauth) работает поверх протокола транспортного уровня, обеспечивает аутентификацию клиента для сервера. Клиент отправляет имя пользователя (нормализованные (RFC-4013) в ISO-10646 UTF-8) и имя сервиса (ssh-connection). Допустимые методы аутентификации определяются сервером, для одного сеанса может требоваться несколько методов, метод может зависеть от имени пользователя, сервиса, местонахождения клиента. Также сервер может передать текст сообщения для пользователя (banner).

Методы аутентификации клиента SSH2:

Протокол соединения (сервис ssh-connection) работает поверх протокола аутентификации, мультиплексирует несколько каналов (потоков) поверх безопасного SSH-туннеля. Обеспечивает интерактивную работу, выполнение удалённых комманд, удалённое выполнение сессий X11, передачу соединений TCP. Канал может быть открыт с любой стороны, канал нумеруется сторонами независимо, канал может иметь подканалы (например, stderr в дополнение к stdout).

Типы глобальных запросов:

Типы каналов:

Типы запросов в канале (в канале м.б. только 1 запрос shell, exec и subsystem):

При компрометации сервера все терминальные сессии, перенаправленные порты становятся тоже компрометированы. При компрометации клиента аналогично, если администратор не предусмотрел ограничения доступа.

Публичный ключ представляет собой текстовый файл, разделённый на строки не длиннее 72 байт символом CR или символом LF или символами CR и LF. Первой строкой должна быть строка "---- BEGIN SSH2 PUBLIC KEY ----", за которой идут строки заголовка как в RFC-822: имя-заголовка (US-ASCII, не более 64 байт), ": ", содержимое заголовка (UTF-8, не более 1024 байт). Каждый заголовок может быть разделён на строки не более 72 байт, признак продолжения - символ "\" в конце строки. Имена заголока могут быть "Subject" (входное имя) и "Comment" (желательно входное-имя@домен, обрамляющие кавычки опускаются). За заголовком идёт тело ключа (BASE64), состоящее из имени формата ключа (например, ssh-rsa) и значения. Тело может быть разделёно на строки не более 72 байт, признак продолжения - символ "\" в конце строки. Последней строкой должна быть строка "---- END SSH2 PUBLIC KEY ----".

Для простоты узнавания ключа используется его отпечаток - MD5 от непреобразованного тела ключа в шестнадцатеричном виде через ":".

RFC-8308 позволяет клиенту и серверу согласовать расширения протоколов после обмена ключей под видом алгоритмов обмена ключей ext-info-s и ext-info-с. Сервер может раскрыть свой список расширений до и/или после аутентификации клиента. Предопределённые расширения:

Готовится стандарт на ssh-agent - протокол работы с агентом ключей (ssh-agent/ssh-add в OpenSSH, Pagent в Putty). Агент ключей хранит публичные и дешифрованные приватные ключи пользователя и обеспечивает выполнение операций с ними, которые требуются ssh клиенту. Это избавляет от необходимости дешифровать приватный ключ при каждом обращении к клиенту ssh. Протокол бинарный синхронный. Добавлять можно приватные ключи типа ssh-dss, ecdsa-sha2-*, ssh-ed25519, ssh-rsa, идентификатор аппаратного токена (указывается PIN-код). При добавлении ключа можно указать ограничения на использование: время действия, подтверждение для каждой операции. Ключи можно отзывать, смотреть список ключей, смотреть публичные ключи, подписывать с использованием приватного ключа, можно заблокировать агента (указывается пароль, передаётся в открытом виде), разблокировать. Операций по извлечению приватного ключа нет, но и подписи может хватить. Канал к агенту ключей может быть перенаправлен аналогично каналу к X11 серверу.

RFC-6187 (PKIX-SSH, AsyncSSH, SecureCRT) обеспечивает возможность проверки публичных ключей с помощью системы сертификатов X.509v3 (RFC-5280) с учётом OCSP (Online Certificate Status Protocol, могут встраиваться в цепочку, чтобы избежать запросов в интернет из приватной сети): алгоритмы публичных ключей x509v3-ssh-dss, x509v3-ssh-rsa, x509v3-rsa2048-sha256, x509v3-ecdsa-sha2-* (алгоритм обмена ключей ecmqv-sha2). Возникает проблема с использованием в сертификатах неподдерживаемых алгоритмов (и не входящих в стандарты SSH). Задание корня (корней) на совести разработчика. Определение соответствия между сертификатами пользователей и их именами обеспечивается разработчиком и администратором. Рекомендуемый метод определения соответствия между сертификатами и именами хостов - использование поля subjectAlternativeName. Предусмотрено расширенное поле сертификата ExtendedKeyUsage: id-kp-secureShellClient, id-kp-secureShellServer.

Оригинальный SSH (Secure Shell, 1995)

Был бесплатен только для некоммерческого использования или опробации (1.2.12 был совсем бесплатен). Windows-версия только для опробации. Поставить версии 1.2.30 и 2.3.0 в Solaris мне не удалось, так что разбираться не стал. Хотя SSH 3.0 под W98 оказался вполне совместим с сервером OpenSSH 2.9/3.0 (даже sftp работает). В настоящее время поддерживается SSH Communications Security (подразделение Tectia).

Для входа по ключу клиента openssh на сервер SSH Secure Shell 3.2.2 необходимо создать каталог .ssh2 (права - 0700), создать файл .ssh2/authorization (права - 0600), содержащий строку 

Key имя-файла-с-публичным-ключом

Формат файла с публичным ключом стандартный, права обязательно "rw-------" (0600).

OpenSSH

Открытая и бесплатная реализация протоколов SSH для OpenBSD (смесь лицензий). Первоначальная версия (1999) была взята из SSH 1.2.12. Портирован под другие ОС (версии с буквой "p"). В частности, удалось запустить его под Solaris 2.5 и Linux 2.2/2.4/2.6. Поддерживает протоколы 1.3, 1.5 и 2.0. Вывод сообщений на syslog.

Возможно использование агентов аутентификации на локальном хосте, которые обеспечивают аутентификацию, не передавая наружу расшифрованные ключи. Дополнительно обеспечивается шифрование данных X Windows (автоматическая установка DISPLAY и генерация фальшивого Xauthority, реальный Xauthority не уходит с локального хоста). Перенаправление любых TCP-соединений с обоих концов через шифрованный канал (ухудшает безопасность, т.к. позволяет делать туннели в обход сетевого экрана).

При желании поддерживает источники псевдослучайных чисел Entropy Gathering Daemon (egd) или PRNGd, если отсутствует /dev/random; PAM и Gnome passphrase.

Для сборки требуется zlib (сжатие) и OpenSSL (шифрование, кроме самых базовых).

Клиент OpenSSH включён в состав MS Windows 10. Для MS Windows 7 можно самостоятельно установить почти официальную сборку OpenSSH.

Поддерживаемые современные алгоритмы обмена ключами:

Поддерживаемые современные форматы открытого ключа:

Поддерживаемые современные MAC

Поддерживаемые современные алгоритмы симметричного шифрования:

SSH в Cisco IOS

Текст прошлого века - давно не работаю с Cisco.

Протокол SSH поддерживается в стабильной версии Cisco IOS начиная с версии 12.2 причем не во всех моделях (популярные у нас Cisco 1600 и Cisco 2500 не поддерживаются по явно надуманным причинам - IP Plus IPsec 56, c2500-ik8s-l; IP/FW Plus IPSec 56, c2500-ik8os-l; Flash 16 MB; DRAM - 10 MB), только протоколы версий 1 и 1.5 (имеющие "дырку" в дизайне против атак типа "man in the middle"), только в прошивках с шифровкой, имеется множество ограничений на методы аутентификации клиента. Плюс к этому ограничения на экспорт сильной криптографии в США. В общем, вы меня поняли ;)

SSH в Dell PowerConnect

 

ip ssh server

SSH в D-Link

 

crypto key generate {rsa | dsa}
ip ssh server
ssh user имя-пользователя authentication-method password
line ssh
login local
session-timeout 10
exit

SSH в Huawei Cloud Engine

(настройка доступа по stelnet)

Ключи configure OpenSSH

Установка OpenSSH 7.9p1 в Fedora 10 (экзотика)
  1. zlib 1.2.3 кажется достаточным
  2. установить OpenSSL 1.0.2q (OpenSSL 1.1.0 и менее 1.0.1 не поддерживается)
  3. для использования режима разделения привилегий (UsePrivilegeSeparation) требуется правильный /var/empty и пользователь sshd (README.privsep)
  4. обеспечить поддержку PAM (/etc/pam.d/sshd, contrib/sshd.pam.generic или contrib/redhat/sshd.pam)
  5. скачать и развернуть
  6. ./configure --prefix=/usr/local/openssh79 --sysconfdir=/usr/local/openssh79/etc --with-ssl-dir=... --with-pam [--with-md5-passwords] --without-pie (иначе нужно собрать OpenSSL с -fPIC)
  7. make
  8. make install

Установка OpenSSH 8.1p1 в CentOS 7.7 дополнительным
  1. родной zlib 1.2.7 кажется достаточным
  2. -установить OpenSSL 1.0.2q (OpenSSL 1.1.0 и менее 1.0.1 не поддерживается)
  3. родной OpenSSL 1.0.2k-fips кажется достаточным
  4. для использования режима разделения привилегий (UsePrivilegeSeparation) требуется правильный /var/empty и пользователь sshd (README.privsep) - он есть от родного sshd
  5. обеспечить поддержку PAM (/etc/pam.d/sshd) - он есть от родного sshd
  6. если нет, то доложить libedit-devel.x86_64, zlib-devel.x86_64, openssl-devel.x86_64
  7. скачать и развернуть
  8. ./configure --prefix=/usr/local/openssh81 --sysconfdir=/usr/local/openssh81/etc --with-pam --with-selinux --with-libedit
  9. make
  10. make install
  11. на всякий случай проверка простых чисел: /usr/local/openssh81/bin/ssh-keygen -f /usr/local/openssh81/etc/moduli -v -T /tmp/moduli
  12. борьба с SELinux за право запустить нестандартный sshd сервер
  13. ключи хоста для TOP SECRET 
    rm /usr/local/openssh81/etc/ssh_host_dsa_key
rm /usr/local/openssh81/etc/ssh_host_dsa_key.pub
/usr/local/openssh81/bin/ssh-keygen -t rsa -b 3072 -N "" -f /usr/local/openssh81/etc/ssh_host_rsa_key
/usr/local/openssh81/bin/ssh-keygen -t ecdsa -b 384 -N "" -f /usr/local/openssh81/etc/ssh_host_ecdsa_key
rm /usr/local/openssh81/etc/ssh_host_ed25519_key
rm /usr/local/openssh81/etc/ssh_host_ed25519_key.pub
  14. попытался сделать права доступа к приватным ключам как в базовой системе (группа ssh_keys имеет право чтения) - сервер при запуске ругается
  15. жёсткая настройка sshd (оригинальные сохранить в /usr/local/openssh81/etc/sshd_config.orig) 
    ListenAddress адрес:порт
ListenAddress 127.0.0.1:порт

AcceptEnv LANG TERM COLORTERM LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE
AcceptEnv XMODIFIERS
AddressFamily inet
AllowAgentForwarding no
AllowStreamLocalForwarding no
AllowTcpForwarding local
AllowUsers ...
AuthenticationMethods publickey
# пользователь может стереть .ssh, поэтому собираем пользовательские ключи
AuthorizedKeysFile /usr/local/openssh81/etc/keys/authorized_keys-%u
# Any unauthorized use is strictly prohibited!
Banner /usr/local/openssh81/etc/banner
CASignatureAlgorithms ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,rsa-sha2-512
ChallengeResponseAuthentication no
Ciphers aes192-ctr,aes256-ctr
ClientAliveInterval 20
Compression no
GatewayPorts no
#GSSAPIAuthentication no
HostbasedAuthentication no
HostKey /usr/local/openssh81/etc/ssh_host_rsa_key
HostKey /usr/local/openssh81/etc/ssh_host_ecdsa_key
HostKeyAlgorithms ecdsa-sha2-nistp521,rsa-sha2-512,ecdsa-sha2-nistp384
IgnoreRhosts yes
IgnoreUserKnownHosts yes
KexAlgorithms ecdh-sha2-nistp521,ecdh-sha2-nistp384,diffie-hellman-group18-sha512,diffie-hellman-group16-sha512
LogLevel INFO
MACs hmac-sha2-512-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512,hmac-sha2-256
MaxSessions 1
PasswordAuthentication no
# никаких обратных каналов
PermitListen none
# никаких прямых каналов, кроме VNC
PermitOpen localhost:5901 ...
# по ключу можно понять, кто это был (запрещены ChallengeResponseAuthentication, GSSAPIAuthentication, HostbasedAuthentication)
PermitRootLogin prohibit-password
PidFile /var/run/sshd81.pid
PubkeyAcceptedKeyTypes ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,rsa-sha2-512
SyslogFacility AUTHPRIV
TCPKeepAlive no
UseDNS yes
UsePAM yes
# стандартный 10 пересекается с VNC
X11DisplayOffset 550
X11Forwarding yes
  16. отредактировать /usr/local/openssh81/etc/banner
  17. скопировать сервис sshd в sshd81:
  18. если пользователей и серверов много,то использовать упрощённые сертификаты
  19. для доступа только по публичному ключу пароль в /etc/shadow не нужен (правда, перестаёт работать команда su)
  20. ключ пользователя 
    сделать ключи на клиентских компьютерах или сделать их самому и разослать (больше уверенности в наличии шифрования ключей):
ssh-keygen -t ecdsa -b 521 -f .ssh/id_ecdsa

обеспечить запуск ssh-agent в начале сеанса и "ssh-add ~/.ssh/id_ecdsa"

разложить .ssh/id_ecdsa.pub в /usr/local/openssh81/etc/keys/authorized_keys-ИмяПользователя
  21. настройка клиента (.ssh/config) 
    Host краткое-имя-сервера
HostName имя-хоста
Port номер-порта
User имя-пользователя
AddKeysToAgent yes
AddressFamily inet
ChallengeResponseAuthentication no
Ciphers aes192-ctr,aes256-ctr
ExitOnForwardFailure yes
ForwardX11Trusted no
GSSAPIAuthentication no
HostKeyAlgorithms ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,rsa-sha2-512
PasswordAuthentication no
PreferredAuthentications publickey
SendEnv LANG COLORTERM
  22. тестирование простого входа: ssh хост
  23. тестирование VNC (через X11 и без):

Установка старых версий

Модули для Diffie-Hellman

Для алгоритма обмена ключами Diffie-Hellman необходим набор "хороших" простых чисел, которые генерируются и проверяются заранее и хранятся в случае OpenSSH в /etc/ssh/moduli (/usr/local/etc/ssh/moduli, /usr/local/openssh81/etc/moduli), в старых версиях хранились в файле /etc/primes. Описание формата хранения - moduli(5). При установке в файл записываются тщательно подобранные модули от изготовителя ПО.

Генерация набора: "ssh-keygen -G имя-файла", дополнительные ключи:

Проверка набора (приблизительная): "ssh-keygen -f имя-файла -T файл-с-результатом", дополнительные ключи:

Ключи хоста (сервера) в OpenSSH

Аутентификация сервера клиентом производится с помощью алгоритмов ассиметричной криптографии с публичным ключом для чего администратор сервера генерирует пару ключей - приватный и публичный ключи сервера. Приватный ключ сервера должен храниться в тайне (root:ssh_keys 640) иначе возможна подмена сервера, что позволяет производить атаки посредника (man in the middle) или прямое получение паролей при использовании аутентификации пользователей по паролям. Имя файла для хранения публичного ключа образуется из имени файла для частного ключа добавлением суффикса ".pub". Публичный ключ может быть доступен всем (root:root 644), при работе сервера не используется, передаётся открыто для использования в ssh_known_hosts, но требует защиты от подделки.

Ключи могут храниться в стандартном формате (RFC-4716), формате PKCS#8 (бинарный, ASN.1, устойчивое к подбору парольной фразы шифрование), PEM (текстовый, Privacy Enhanced Mail, плохое шифрование) и в формате OpenSSH (по умолчанию, устойчивое шифрование, комментарии к приватному ключу).

Для каждого типа ассиметричной криптографии (алгоритма, формата) создаётся своя пара ключей, форматы (по умолчанию RSA):

Генерация ключей производится утилитой ssh-keygen, ключи ("ssh-keygen -A" создаёт все возможные ключи с параметрами по умолчанию)

Пример (нужны только ключи rsa-sha2-256 (3072 бит), ecdsa-sha2-nistp384): 

rm /usr/local/openssh81/etc/ssh_host_dsa_key
rm /usr/local/openssh81/etc/ssh_host_dsa_key.pub
/usr/local/openssh81/bin/ssh-keygen -t rsa -b 3072 -N "" -f /usr/local/openssh81/etc/ssh_host_rsa_key
/usr/local/openssh81/bin/ssh-keygen -t ecdsa -b 384 -N "" -f /usr/local/openssh81/etc/ssh_host_ecdsa_key
rm /usr/local/openssh81/etc/ssh_host_ed25519_key
rm /usr/local/openssh81/etc/ssh_host_ed25519_key.pub

Преобразования ключа:

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

Для упрощения сравнения ключей предлагается сравнивать отпечатки (fingerprint) ключей вместо самих ключей, или автоматически сравнивать отпечатки ключей с информацией из DSN (SSHFP, требуется действующая DNSSEC) или использовать графическую визуализацию отпечатков:

Связка публичных ключей известных хостов

Связка публичных ключей известных хостов (/etc/ssh/known_hosts, /usr/local/etc/ssh/known_hosts, /usr/local/openssh81/etc/known_hosts, ~/.ssh/known_hosts) используется клиентом для проверки подлинности сервера (сервер должен доказать, что владеет приватным ключом, соответствующим публичному ключу). Клиент проверяет наличие в одной из связок предъявленного сервером публичного ключа или публичного ключа CA, которым подписан его ключ (должен быть помечен маркером @cert-authority в связке). Публичный ключ может быть отозван указанием для него маркера @revoked в связке. Право на запись должно быть только у суперпользователя (для общего файла) или владельца (личный файл ~/.ssh/known_hosts). Общий файл (/etc/ssh/ssh_known_hosts, /usr/local/etc/ssh/known_hosts, /usr/local/openssh81/etc/known_hosts) должен быть доступным на чтение всем.

Файл разделён на строки, отдельная строка для каждого публичного ключа. Может быть несколько строк с ключами различных типов для одного хоста. Комментариями являются пустые строки и строки, начинающиеся с '#'. Нельзя иметь несколько ключей одного типа для одного хоста и порта. Описание ключа содержит разделенные пробелами поля:

  1. маркеры (не обязательно): @cert-authority (это ключ CA), @revoked (ключ отозван)
  2. список через запятую шаблонов (спец. символы - ?, * и !) имен хостов; при аутентификации клиента (HostbasedAuthentication) шаблон сравнивается с каноническим именем хоста клиента; при аутентификации сервера - с именем, указанным клиентом или из HostkeyAlias или каноническое имя при использовании CanonicalizeHostname; вместо имён можно использовать адреса; можно указывать номер порта в виде "[имя-хоста]:номер-порта" (квадратные скобки здесь - это символы); вместо имён или адресов хостов можно использовать хеши (ssh-keygen -H) после символа '|'
  3. тип ключа (берётся из файла с публичным ключом)
  4. кодированный в base64 публичный ключ хоста (берётся из файла с публичным ключом)
  5. комментарий

Обший файл заполняется вручную, ключи можно передать клиенту заранее по другому каналу связи

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

Аналогичная связка используется сервером при аутентификации пользователя по имени хоста (HostbasedAuthentication,).

Обслуживание связки публичных ключей известных хостов:

Ключи пользователя

Аутентификация пользователя может производиться сервером по публичному ключу с помощью алгоритмов ассиметричной криптографии для чего пользователь генерирует пару ключей - приватный и публичный ключи пользователя. Приватный ключ пользователя должен храниться в тайне, обычно, в каталоге ~/.ssh с правами доступа rwx------ (700) с именами id_алгоритм с правами rw------- (600). Имя файла для хранения публичного ключа образуется из имени файла для частного ключа добавлением суффикса ".pub". Публичный ключ может быть доступен всем, при работе клиента не используется, передаётся открыто для использования в authorized_keys на сервере, но требует защиты от подделки. Форматы (по умолчанию RSA):

Ключи могут храниться в стандартном формате (RFC-4716), формате PKCS#8 (бинарный, ASN.1, устойчивое к подбору парольной фразы шифрование), PEM (текстовый, Privacy Enhanced Mail, плохое шифрование) и в формате OpenSSH (по умолчанию, устойчивое шифрование, комментарии к приватному ключу).

Генерация ключей производится утилитой ssh-keygen, ключи:

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

Связка авторизованных публичных ключей пользователя на сервере

Для аутентификации пользователя по публичному ключу сервером публичный ключ предварительно созданной пары ключей пользователя должен быть помещён в одну из связок авторизованных публичных ключей пользователя Сервер проверяет наличие в одной из связок предъявленного клиентом публичного ключа или публичного ключа CA, которым подписан предъявленный ключ (должен быть помечен маркером @cert-authority в связке). Обычно каждый пользователь имеет свою связку на сервере в ~/.ssh/authorized_keys. Чтение и запись только для владельца. Комментариями являются пустые строки и строки, начинающиеся с '#'. На каждой строке - описание одного ключа в виде разделенных пробелами полей (несколько сотен байт!):

  1. опции (необязательное поле) через запятую, пробелы только внутри кавычек
  2. тип ключа (ssh-dss, ssh-rsa, ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521, ssh-ed25519)
  3. кодированный (base64) ключ, копируется из публичного ключа пользователя (файл id_тип.pub)
  4. комментарий (имя-пользователя@имя-клиентского-хоста)

Упрощённые сертификаты в OpenSSH

В стандарте предусмотрена автоматическая проверка публичных ключей с использованием системы сертификации PKI (X.509v3), но в OpenSSH вместо сертификатов X.509v3 используются упрощённые сертификаты в собственном формате. Реализованы с помощью нестандартных алгоритмов (форматов) публичных ключей: ssh-rsa-cert-v01@openssh.com (не рекомендуется), ssh-dss-cert-v01@openssh.com (не рекомендуется), ssh-ed25519-cert-v01@openssh.com (не рекомендуется), ecdsa-sha2-nistp256-cert-v01@openssh.com (не рекомендуется), ecdsa-sha2-nistp384-cert-v01@openssh.com, ecdsa-sha2-nistp521-cert-v01@openssh.com, rsa-sha2-256-cert-v01@openssh.com. Никаких цепочек и неизвестных алгоритмов подписи (прощай проблемы с совместимостью и развёрнутая PKI). Используя механизм упрощённых сертификатов клиент может ограничиться доверием только одному публичному ключу вместо многих: он проверяет наличие в одной из связок известных публичных ключей хостов публичного ключа CA, которым подписан предъявленный сервером публичного ключа. Аналогично поступает и сервер при аутентификации пользователя или хоста клиента.

Упрощённый сертификат содержит подписанные ключом CA:

Создание упрощённых сертификатов (подписываем публичный ключ приватным ключом CA; результат в файле публичный-ключ-cert.pub; идентификатор записывается в журнал): ssh-keygen -I идентификатор публичный-ключ, опции:

Чтобы клиент доверял подписи CA при аутентификации сервера, публичный ключ CA должен быть внесён в связку известных публичных ключей хостов с маркером cert-authority.

Чтобы сервер доверял подписи CA при аутентификации пользователя по ключу, публичный ключ CA должен быть внесён в связку авторизованных публичных ключей пользователя с опцией cert-authority.

Процедура:

Можно вывести содержимое сертификата: ssh-keygen -L [-f имя-файла].

Отзыв упрощённых сертификатов осуществляется с использованием собственного протокола отзыва ключей и сертификатов - KRL.

Спецификация KRL состоит из строк, каждая описывает условие отзыва:

Побочные утилиты

Сервис и сервер sshd в OpenSSH

Сервер sshd должен быть запущен на сервере (компьютере, на который мы хотим зайти). Для каждого входного соединения порождается новый процесс. Текущая версия поддерживает только SSH версии 2. Параметры передаются либо в управляющем файле (перечитывается по SIGHUP), либо опциями командной строки (имеют приоритет):

Если запустить sshd из-под обычного пользователя, то можно будет заходить только под этим пользователем (используя -p для непривилегированного порта). Для аутентификации клиента по хосту ssh должен использовать привилегированный порт (номер порта менее 1024). Для привязки к привилегированному порту ssh должен иметь права setuid root. Если аутентификация клиента по хосту не предполагается, то эти права можно снять. Чтобы использовать обычный порт надо задать опцию "UsePrivilegedPort no" в конфигурационном файле или командной строке.

По умолчанию идентификатор головного процесса sshd записывается в /var/run/sshd.pid.

Обеспечение запуска sshd при начальной загрузке (сервис):

Конфигурация сервера OpenSSH (/etc/ssh/sshd_config, /usr/local/openssh81/etc/sshd_config, /usr/local/etc/sshd_config)

Права на чтение и запись должны быть только для root. Пустые строки и строки, начинающиеся с "#", считаются комментариями. Файл разбит на строки, каждая строка содержит имя директивы, пробел, значение. Пробелы в значениях заключаются в двойные кавычки. Используется первое встреченное значение директивы, если в описании не указано иное. При описании первым указано значеие по умолчанию. Порядок обработки директив доступа: DenyUsers, AllowUsers, DenyGroups, AllowGroups.

При указании интервалов времени можно использовать суффиксы s, m, h, d, w. По умолчанию - в секундах. Можно использовать несколько суффиксов - "1h30m".

Макросы:

Файлы на сервере с OpenSSH, используемые при входе ssh

Нижеизложенное дано с точки зрения OpenBSD. В современном Linux с PAM и systemd могут быть нюансы.

/etc/nologin - при наличии этого файла запрещается вход пользователей, кроме root. Содержимое файла выдается в качестве сообщения о причине.

~/.ssh/environment - содержит пары вида имя=значение, которые помещаются в окружение при входе (PermitUserEnvironment).

Если пользователю разрешено (PermitUserRC), то выполняется ~/.ssh/rc, иначе если имеется, то выполняется системный /etc/ssh/sshrc (/usr/local/openssh81/etc/sshrc, /usr/local/etc/sshrc), иначе xauth. Выполняются при входе после чтения окружения, но до запуска оболочки или запрошенной команды. Ничего не должны выводить на stdout. При перенаправлении X11 (установлен DISPLAY) должен обрабатывать куки со стандартного ввода и вызывать xauth.

~/.hushlogin - не извещать о времени предыдущего входа и пр. (PrintLastLog, PrintMotd).

~/.rhosts (устарело) - на каждой строке пара: хост - пользователь, разделенные пробелом. Данному пользователю с данного хоста разрешается заходить без указания пароля при использовании RhostsAuthentication и RhostsRSAAuthentication (этот же файл используется rlogind и rshd). Чтение и запись только для владельца.

~/.shosts (устарело) - то же самое, но не используется командами rlogind и rshd.

/etc/hosts.allow, /etc/hosts.deny (устарело) - при компиляции с libwrap используется для контроля доступа как описано в hosts_access(5).

/etc/hosts.equiv - список хостов, пользователи с которых могут заходить, не указывая паролей под теми же самыми именами. За именем хоста можно указывать имя конкретного пользователя. Право на запись только для root. Отрицание обозначается знаком "-". Обычно используется в сочетании с RSA аутентификацией хоста. Очень не рекомендуется.

/etc/shosts.equiv - аналогично, но не используется командами rsh/rlogin.

Каталог /var/empty/sshd используется для временного chroot до аутентификации. Владельцем д.б. root. Права - 111.

Клиент OpenSSH

ssh - замена telnet, rsh, rlogin,безопасное соединение с X11-сервером и шифровка произвольного TCP/IP соединения. Поддерживает протокол версии 2 (версия 1 небезопасна), методы аутентификации - GSSAPI, по хосту (проверяется публичный ключ хоста клиента /usr/local/openssh81/etc/ssh_known_hosts и ~/.ssh/known_hosts, /usr/local/openssh81/etc/shosts.equiv, ~/.shosts), по публичному ключу, challenge-response, по паролю. В качестве параметров указывается сервер и выполняемая команда. Сервер может быть указан в форматах: имя-пользователя@сервер или ssh://[имя-пользователя@]имя-хоста[:порт]. В настройках клиента адрес, порт и имя пользователя могут быть переопределены по имени сервера. Если команда не указана, то запускается командная оболочка (указывается в настройках пользователя на сервере). Настройки сервера могут навязать исполняемую прграмму (forced-command).

Если сервер выделил псевдо-терминал (для интерактивной сессии или с ключом -t), то клиент может использовать управляющие последовательности (только сразу после <nl>):

Вместо тильды можно установить другой escape-символ ключом "-e" или директивой EscapeChar.

Если псевдо-терминал не выделен (notty, -T) или в качестве excape-символа указали none, то передача данных происходит в "прозрачном" режиме - бинарные данные передаются без искажений.

Если при запуске ssh пользователь использовал X11 (определяется по установленной переменной DISPLAY) и установил в настройках клиента ForwardX11 (или указал ключи -x, -X, -Y), то слушается порт 6xxx на удалённом хосте (только на интерфейсе localhost, если в настройках сервера указано X11UseLocalhost - по умолчанию, иначе на всех интерфейсах), номер порта определяется как первый свободный порт после 6000+X11DisplayOffset из настроек сервера sshd, перед запуском программы или оболочки на удалённом хосте устанавливается переменная окружения DISPLAY в localhost:xxx.0, запросы удалённых графических программ на localhost:6xxx перенаправляются по защищённому каналу к локальному X11 серверу (работает на клиентском хосте) от имени клиентского хоста, клиент ssh делает магию с куками авторизации Xauthority на сервере sshd (реальные куки сервера X11 не передаются на сервер sshd совсем, даже виртуальные куки от клиента X11 передаются по защищённому каналу).

Сессия завершается по завершению выполнения команды или выходе из оболочки, а также закрытию всех проброшенных соединений TCP и X11.

Ключи (имеют приоритет над файлами конфигурации):

Вместо ключей можно использовать файлы конфигурации - личный (~/.ssh/config; рекомендуется делать недоступным для всех, кроме владельца), и общесистемный (/usr/local/openssh81/etc/ssh_config, (/etc/ssh/ssh_config; должен быть доступен на чтение всем). Личный приоритетнее, ключи командной строки ещё приоритетнее. Строки, начинающиеся с #, являются комментариями. Каждая строка содержит один параметр: имя параметра и значение разделяются пробелом или знаком равенства, значение может быть заключено в двойные кавычки. Файл разделен на секции директивами Host и Match, секция применяется при работе с хостом, удовлетворяющем шаблону секции, для каждого параметра используется первое подходящее значение, первыми указаны значения по умолчанию:

При входе на удаленный сервер устанавливаются переменные: DISPLAY, HOME, LOGNAME, MAIL, PATH (определяется при компиляции ssh - на какой стороне?), SSH_ASK_PASS (имя программы, которая будет вызываться при необходимости ввести парольную фразу в отсутствии терминала, но наличии переменной DISPLAY), SSH_AUTH_SOCK (unix socket для взаимодействия с агентом аутентификации), SSH_CLIENT (ip-адрес клиента, порт клиента, порт сервера; не описано в документации), SSH_CONNECTION (ip-адрес клиента, порт клиента, ip-адрес сервера, порт сервера), SSH_ORIGINAL_COMMAND (указанное клиентом имя команды, если использовалось forced-command), SSH_TTY (путь к устройству), SSH_TUNNEL (имя интерфейса), SSH_USER_AUTH (опционально; имя файла, содержащего успешно использованные методы аутентификации и публичные ключи), TZ (наследуется от сервера sshd), USER, строки из ~/.ssh/environment (если разрешено), переменные из SetEnv. Наследуются значения переменных клиента, указанных в SendEnv/AcceptEnv.

Агент аутентификации

ssh-agent, ssh-add. ssh-agent - держатель приватных ключей для RSA/DSA аутентификации. Запускается в начале сессии и устанавливает переменные окружения (SSH_AGENT_PID, SSH_AUTH_SOCK), с помощью которых остальные программы используют его для автоматической аутентификации ssh. Параметром является имя команды и ее аргументы (например, bash), ssh-agent завершается при завершении команды. Если имя команды не указано, то ssh-agent запускается в фоновом режиме, а на stdout выдаются команды экспортирования необходимых переменных окружения (позволяет избежать порождения лишнего shell). Формат команд экспорта определяется из переменной окружения SHELL (csh или sh). В директории /tmp (в RHEL7/CentOS7 в /run/user/идентификатор-пользователя/keyring/ssh, один и тот же для всех ssh-agent) создается unix сокет для общения других программ из пакета ssh с ssh-agent (его имя записывается в SSH_AUTH_SOCK). root может общаться с вашим агентом аутентификации (интересно, что он может сделать?)!

Приватные ключи добавляются программой ssh-add, которая запрашивает парольную фразу, расшифровывает приватный ключ и посылает его ssh-agent. Если терминал недоступен, но определена переменная DISPLAY, то для ввода парольной фразы используется программа, определенная переменной SSH_ASKPASS. Если необходимо расшифровать несколько приватных ключей, то ssh-add пытается использовать предыдущую парольную фразу. Таким образом парольная фраза запрашивается только один раз за сеанс, а не при каждом вызове ssh/scp/sftp. Т.к, ssh-agent выполняется на персональном компьютере пользователя и может обслуживать запросы при переходе с одного удаленного хоста на другой, то он позволяет избежать необходимости хранить приватный ключ на удаленном компьютере и пересылать парольную фразу по сети. ssh-agent не передаёт приватный ключ своему клиенту, а выполняет необходимые действия от его имени.

Опции ssh-agent:

Опции ssh-add:

Таким образом можно вставить в .profile (Solaris) или .bash_profile (Linux) следующие строки (с предварительной проверкой отсутствия переменных окружения SSH_AUTH_SOCK (означает, что ssh-agent запущен ранее) и SSH_CLIENT (означает, что мы попали на этот хост по ssh с хоста, на котором скорее всего уже запущен ssh-agent)): 

if [ -z "$SSH_CLIENT" -a -z "$SSH_AUTH_SOCK" ]
then
  eval `ssh-agent`
# здесь будет запрошена парольная фраза, но один раз за сеанс
  ssh-add ~/.ssh/id_dsa
fi

При возможности лучше положить в /etc/profile.d/ssh-agent.sh и вызывать ssh-add перед первым вызовом ssh: 

if [ -z "$SSH_CLIENT" -a -z "$SSH_AUTH_SOCK" ]
then
  eval `ssh-agent`
fi

В CentOS 7.7 и mate вмешивается Gnome keyring и при отсутствии ключа у ssh-agent образуется такой лес процессов (т.е. парольная фраза и ключ перехватываются и где-то хранятся): 

/usr/bin/gnome-keyring-daemon --daemonize --login
    /usr/bin/ssh-add /home/имя/.ssh/id_dsa
        /usr/libexec/gcr-ssh-askpass Enter passphrase for /home/имя/.ssh/id_dsa: 
    /usr/bin/ssh-agent -D -a /run/user/ид/keyring/.ssh
/usr/libexec/gcr-prompter
ssh grid0037

В CentOS 7.9 вмешательство приводит к неработоспособности схемы. Не смог найти кто запускает /usr/bin/gnome-keyring-daemon и переименовал его. После запуска сессии надо обязательно его запустить, иначе многие программы зависают в попытке достучаться до пустого хранилища паролей.

Наладка инфраструктуры

Текст 1999 года.

Обеспечение безопасности вообще и установка ssh, в частности, - это не просто запуск одной программы, а наладка инфраструктуры взаимодействия различных компонент. Инфраструктура будет различаться в зависимости от поставленных задач, внешних обстоятельств и личных предпочтений. Например, у меня нет необходимости обеспечивать совместимость с SSH1, поэтому при установке всякая возможность работы в режиме SSH1 была намерено обрезана. Также были обрезаны возможности работы с .rhosts, kerberos.

  1. устанавливаем OpenSSH на все хосты как было описано выше (здесь же создаются RSA/DSA ключи хостов)
  2. конфигурируем /usr/local/etc/sshd_config (/etc/ssh/sshd_config, права 600) на серверах (я опускаю несущественные параметры)
    3. Port 22
ListenAddress адрес-разрешённого-интерфейса
AcceptEnv LANG TERM COLORTERM
AllowUsers список-допущенных-пользователей
  или
AllowGroups список-групп-пользователей
AllowTcpForwarding yes
ChallengeResponseAuthentication no
ClientAliveInterval 20
Compression yes
GatewayPorts no
HostbasedAuthentication no
IgnoreRhosts yes
IgnoreUserKnownHosts yes
KeepAlive yes
  или
TCPKeepAlive yes
LogLevel INFO
PasswordAuthentication no # по возможности
PermitEmptyPasswords no
PermitRootLogin forced-commands-only
PermitUserEnvironment no
PrintMotd no
Protocol 2
PubkeyAuthentication yes
ReverseMappingCheck yes
  или
UseDNS yes
RhostsAuthentication no # для старых версий
RhostsRSAAuthentication no
RSAAuthentication no
SkeyAuthentication no
StrictModes yes
Subsystem sftp /usr/libexec/openssh/sftp-server
SyslogFacility AUTHPRIV
UsePAM no
X11Forwarding yes (если на хосте есть X Windows и игнорируем риск перехвата)
X11UseLocalhost yes
  3. обеспечение запуска "sshd -u0 -4" при загрузке
    1. Solaris: /etc/init.d/sshd и линк на него из /etc/rc2.d/S99sshd
    2. Linux Red Hat: /etc/rc.d/init.d/sshd и линк на него из /etc/rc.d/rc2.d/S98sshd (и rc3.d)
    3. в /etc/sysconfig/sshd: OPTIONS="-u0 -4"
  4. собираем все ssh_host_dsa_key.pub, формируем из них /usr/local/etc/ssh_known_hosts (/etc/ssh/ssh_known_hosts) и копируем на все хосты
  5. открыть дырки в сетевых экранах для TCP/22
  6. чтобы PAM в RedHat был счастлив - скопировать /etc/pam.d/login в /etc/pam.d/sshd (убрать nullok, тем более что начиная с RH 7.0 его нет), см. также contrib/
  7. общая настройка новых клиентов (3.9p1) /etc/ssh/ssh_config 
    Host *
AddressFamily inet
# компьютер с несколькими интерфейсами или алиасами
BindAddress исходящий-адрес
ChallengeResponseAuthentication no
HostKeyAlgorithms ssh-dss
PreferredAuthentications publickey,password
Protocol 2
RSAAuthentication no
SendEnv LANG TERM COLORTERM
ServerAliveInterval 60
StrictHostKeyChecking yes
  8. добавления в настройки конкретных соединений (до "Host *"!) или в ~/.ssh/config 
      Host удалённый-хост-с-медленным-каналом
    Compression yes
  Host хост-где-у-меня-другое-имя
    User имя
  Host где-точно-есть-ключ-входа
    PasswordAuthentication no
    PreferredAuthentications publickey
  Host где-никого-кроме-меня-нет
    ForwardAgent yes
    ForwardX11 yes
  9. дополнительная настройка старых клиентов /usr/local/etc/ssh_config (неправильные умолчания)
    1. Host *
    2. FallBackToRsh no
    3. GatewayPorts no
    4. HostbasedAuthentication no
    5. IdentityFile ~/.ssh/id_dsa
    6. KeepAlive yes (клиент не завершается)
    7. LogLevel INFO
    8. RhostsAuthentication no
    9. RhostsRSAAuthentication no
    10. RSAAuthentication no
    11. UsePrivilegedPort no
    12. UseRsh no
  10. настройка для интерактивной работы. Т.к. в этом режиме возможно выполнение любых команд, то вход на другой хост без запроса пароля нежелателен, иначе взлом одного хоста автоматически ведет к взлому всех остальных. Но и вводить пароль каждый раз утомительно.
    1. на клиентском хосте (с вводом парольной фразы подлиннее): ssh-keygen -t dsa -b 2048 -f ~/.ssh/id_dsa
    2. на сервере в ~/.ssh/authorized_keys (права 600) добавить содержимое файла ~/.ssh/id_dsa.pub с клиентского хоста
    3. в процедуру начала сеанса на клиентском хосте (.bash_profile или .profile; с учетом, что сюда можно попасть тоже с помощью ssh) или вручную 
      if [ -z "$SSH_CLIENT" -a -z "$SSH_AUTH_SOCK" ]
then
  eval `ssh-agent`
# здесь будет запрошена парольная фраза, но один раз за сеанс
  ssh-add ~/.ssh/id_dsa
fi
    4. при возможности лучше положить в /etc/profile.d/ssh-agent.sh (chmod +x) и вызывать ssh-add перед первым вызовом ssh: 
      if [ `id -u` -ne 0 ]
then
  if [ -z "$SSH_CLIENT" -a -z "$SSH_AUTH_SOCK" ]
  then
    eval `ssh-agent`
  fi
fi
    5. теперь при запуске ssh парольная фраза (и пароль сервера) запрашиваться не будет
    6. в конце сеанса (только не .bash_logout) надо выдать "ssh-agent -k"
  11. Выполнение удаленных команд в пакетном режиме (backup, из cron). Здесь некому будет вводить пароль или парольную фразу. Но и разрешать выполнять любую команду с одного хоста на другом тоже не хочется (вскрытие первого хоста автоматически открывает второй). Для каждой команды, которую надо выполнять в пакетном режиме с одного хоста на втором (backup) делаем:
    1. на первом хосте выполнить: ssh-keygen -t dsa -b 2048 -N "" -f ~/.ssh/обозначение-команды
    2. на втором хосте в ~/.ssh/authorized_keys (права 600) добавить строку (учитывать значение PATH): command="текст команды",no-X11-forwarding,no-port-forwarding,no-pty,no-agent-forwarding <содержимое файла ~/.ssh/обозначение-команды.pub на первом хосте>
    3. в командный файл (или cron) на первом хосте вставлять команду удаленного выполнения (на stderr выдается ненужное в данном случае сообщение о закрытии соединения; переменные окружения SSH_AUTH_SOCK, SSH_CLIENT и SSH_AGENT_PID не должны быть установлены!): ssh -T -i ~/.ssh/обозначение-команды второй-хост
  12. избавиться от всех telnet, ftp и rsh

sftp

Сервер sftp (sftp-server) должен быть описан в опции Subsystem в конфигурационном файле sshd.

Клиентская программа sftp позволяет пересылать файлы в интерактивном режиме подобно FTP однако осуществляет все операции поверх защищенного транспорта ssh, который, собственно, и вызывается. Опции:

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

     sftp [user@]host[:file [file]]

Интерактивные команды (аналогично FTP):

Копирование файлов (scp)

scp - копирование файлов между хостами (оба могут быть удаленными). Способы аутентификации аналогичны ssh (может запрашивать пароль или парольную фразу). В действительности, вызывает ssh для организации канала передачи данных. Имя файла записывается в виде: [[user@]host:]file. Опции:

"Оконные" клиенты

mc имеет виртуальную файловую систему для работы с ssh-сервером (fish): 

   cd /#sh:[пользователь@]хост[/директория]

gFTP - графический клиент (GTK+) для FTP, HTTP и SSH в версии 2.0.10 научился работать с sftp от OpenSSH: надо в параметрах SSH указать использование SFTP subsys и нажать Enter в поле пароля для соединения

Основные изменения в версиях OpenSSH

Ссылки
@ Карта сайта News Автора!

Bog BOS: SSH и OpenSSH: принципы работы, установка и настройка

apache inn MySQL nntpcache Cyrus IMAP exim Squid ssh syslog tacacs ProFTPD wu-ftpd xntpd

Последние изменения:
2024.03.28: sysadmin: Файловая система zfs под Linux для архива (обновление от 0.6 до 2.2)
Copyright © 1996-2024 Sergey E. Bogomolov; www.bog.pp.ru