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 подвержен атаке типа "man in the middle"
• SSH1 поддерживает аутентификацию по .rhosts/hosts.equiv (пользоваться этим не надо)

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

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

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

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

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

• начальный список SSH2: diffie-hellman-group1-sha1 (RFC 2409, 1024 бит, простые числа, Oakley Group 2), diffie-hellman-group14-sha1 (RFC 3526, 2048 бит, Oakley Group 14)
• RFC-4419 добавил в список diffie-hellman-group-exchange-sha1 (SHA-1) и diffie-hellman-group-exchange-sha256 (SHA-256), которые предусматривают согласование группы (дополнительная точка атаки)
• RFC-4432 добавил в список rsa1024-sha1 и rsa2048-sha256 (быстр; имеет проблемы; приватный ключ сервера генериуется на время сеанса, это не ключ хоста)
• RFC-8270 увеличил минимальный размер модуля DH при согласовании с 1024 до 2048 (для предусмотрительных - 3072)
• RFC-8268 добавил в список групп: diffie-hellman-group14-sha256 (2048 бит), diffie-hellman-group15-sha512 (3072 бита), diffie-hellman-group16-sha512 (4096 бит), diffie-hellman-group17-sha512 (6144 бита), diffie-hellman-group18-sha512 (8192 бита)
• RFC-4462 добавил в список (использование вместо ключей сервера Generic Security Service Application Program Interface (GSS-API)): gss-group1-sha1-* (1024 бит, SHA-1), gss-group14-sha1-* (2048 бит, SHA-1), gss-gex-sha1-* (согласование группы, SHA-1). Вместо '*' подставляется кодированный BASE64 хеш MD5 от DER кодировки OID используемого GSS-API
• Готовится дополнение/замена RFC-4462 добавляющее: gss-group14-sha256-*, gss-group15-sha512-*, gss-group16-sha512-*, gss-group17-sha512-*, gss-group18-sha512-*, gss-nistp256-sha256-*, gss-nistp384-sha384-*, gss-nistp521-sha512-*, gss-curve25519-sha256-*, gss-curve448-sha512-* и объявляет устаревшим все предыдущие
• RFC-5656 добавил в список обязательные: ecdh-sha2-nistp256 (Elliptic Curve Diffie-Hellman; длина ключа - 256; требует меньшей длины ключа, чем RSA/DSA; SHA-256), ecdh-sha2-nistp384 (SHA-384), ecdh-sha2-nistp521 (SHA-512), рекомендуется также множество других вариантов ECC вида ecdh-sha2-1.3.132.0.1 и т.п.; ecmqv-sha2 (Elliptic Curve Menezes-Qu-Vanstone, 2 пары ключей, неявная аутентификация сервера, параметры кривой берутся из ключа сервера)
• Готовится дополнение (curdle): curve25519-sha256 (эквивалент curve25519-sha256@libssh.org; 128 бит безопасности; публичный ключ 32 байта; DH с использованием X25519), curve448-sha512 (224 бит безопасности; публичный ключ 56 байт; DH с использованием X448)

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

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

• начальный список SSH2: ssh-dss (DSA (1024?), SHA-1), ssh-rsa (RSA, SHA-1), pgp-sign-rsa (реализация неизвестна), pgp-sign-dss (реализация неизвестна)
• RFC-4462 добавил в список null, т.к. для аутентификации сервера с помощью GSS-API ключи не нужны
• RFC-5656 добавил в список: ecdsa-sha2-nistp256 (Elliptic Curve Digital Signature Algorithm; длина ключа - 256; требует меньшей длины ключа, чем RSA/DSA; SHA-256), ecdsa-sha2-nistp384 (SHA-384), ecdsa-sha2-nistp521 (SHA-512), рекомендуется также множество других вариантов ECC вида ecdsa-sha2-1.3.132.0.1 и т.п.
• RFC-8332 добавил в список алгоритмов ( формат остался ssh-rsa ): rsa-sha2-256 (RFC-8017), rsa-sha2-512
• Готовится дополнение (curdle): ssh-ed25519 (только подписи (64 байта), нет шифрования), ssh-ed448 (только подписи (114 байт), нет шифрования)

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

• начальный список SSH2: 3des-cbc (обязателен, 168 бит, сводим к 112 бит?), blowfish-cbc, twofish256-cbc, twofish-cbc, twofish192-cbc, twofish128-cbc, aes256-cbc (Rijndael), aes192-cbc, aes128-cbc (рекомендуем), serpent256-cbc, serpent192-cbc, serpent128-cbc, arcfour (RC4, слабый), idea-cbc, cast128-cbc, none (для отладки), des-cbc (56 бит, слабый)
• RFC-4344 дополнительно вводит алгоритмы шифрования в режиме SDCTR (stateful-decryption counter, обеспечивает устойчивость к атакам с выбранным текстом): aes128-ctr, aes192-ctr, aes256-ctr, 3des-ctr и др
• RFC-5647 иследовалась возможность использования AES в режиме CGM для одновременного шифрования и проверки целостности (официально не добавлен - размер пакета не шифруется, реализованы в OpenSSH: aes128-gcm@openssh.com, aes256-gcm@openssh.com)
• В OpenSSH реализован chacha20-poly1305@openssh.com (ChaCha20 - потоковый шифр, Poly1305 - MAC (128 бит, разделяемый секрет 256 бит); размер пакета и сам пакет шифруются отдельными ключами)

• SSH1: CRC32 (подделывается при атаке типа "man in the middle")
• начальный список SSH2: hmac-sha1, hmac-sha1-96, hmac-md5, hmac-md5-96, none
• RFC-6668 добавил в список: hmac-sha2-256, hmac-sha2-512
• готовится дополнение на базе UMAC (RFC-4418, быстрый, разделяемый секрет, AES, предлагается как альтернатива HMAC ): umac-32, umac-64 (umac-64@openssh.com), umac-96, umac-128 (umac-128@openssh.com)
• hmac-ripemd160, hmac-ripemd160@openssh.com
• в OpenSSH реализованы дополнительные MAC серии ETM: hmac-sha1-etm@openssh.com, hmac-sha1-96-etm@openssh.com, hmac-sha2-256-etm@openssh.com, hmac-sha2-512-etm@openssh.com, hmac-md5-etm@openssh.com, hmac-md5-96-etm@openssh.com, hmac-ripemd160-etm@openssh.com, umac-64-etm@openssh.com, umac-128-etm@openssh.com

Предусматривается возможность сжатия перед шифрованием. Алгоритм сжатия в каждую сторону согласуется между клиентом и сервером (приоритет задаётся клиентским списком), начальный список 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).

• none (для отладки?)
• publickey: клиент передаёт имя алгоритма публичных ключей и открытый ключ (можно несколько предложений, не обязательно ограничиваться списком из обмена ключами транспортного протокола); сервер выбирает подходящую пару (публичный ключ пользователя хранится на сервере); клиент подписывает пакет (идентификатор сессии, имя пользователя, имя сервиса и т.д.) с помощью приватного ключа (возможно зашифрованного, требуется ввод пароля пользователем); сервер проверяет подпись с помощью публичного ключа
• password: нормализованные (RFC-4013) пароли в ISO-10646 UTF-8 ( шифруются при пересылке, но доступны серверу, бойтесь поддельных серверов ); сервер может потребовать заменить пароль с истёкшим сроком действия; клиент может послать запрос на изменение пароля
• hostbased: сервер доверяет аутентификацию клиенту (не рекомендуется); сервер требует от клиента способности подписать пакет приватным ключом хоста клиента и проверяет имеющимся у него публичным ключом клиента
• keyboard-interactive: интерактивный обмен с помощью дополнительных средств (Challenge-response, One Time Password, чтение карточек и т.д.) - RFC-4256; клиент и сервер должны согласовать конкретный метод; сервер посылает инструкцию и последовательность запросов, на которые пользователь через клиента должен ответить
• gssapi-with-mic (RFC-4462): клиент и сервер договариваются о OID используемого механизма GSS-API, затем клиент аутентифицируется этим механизмом
• gssapi-keyex (RFC-4462): имя пользователя было определено во время обмена ключами
• gssapi (RFC-4462): заменён на gssapi-with-mic
• external-keyx (RFC-4462): заменён на gssapi-keyex

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

• tcpip-forward: инициатор указывает IP адрес ("0.0.0.0" - все адреса IPv4; "::" - все адреса IPv6; "" - все адреса; "localhost"; "127.0.0.1", "::1") и TCP порт (0 - первый свободный непривилегированный порт), который сервер будет слушать на своей стороне; клиенту рекомендуется не принимать запросы от сервера
• cancel-tcpip-forward: прекратить перенаправление

• session: удалённое выполнение программы (с терминалом и без - pty-req, с перенаправлением X11 и без - x11-req), может быть несколько активных сессий; клиенту рекомендуется не принимать сессий от сервера
• x11: независимое от сессий перенаправление X11; параметры: IP адрес и порт; рекомендуется не обслуживать каналы x11 без x11-req
• forwarded-tcpip: на запрошенный в tcpip-forward порт сервера пришло соединение, передаётся IP адрес и порт сервера, IP адрес и порт источника; канал не закрывается при завершении сессии
• direct-tcpip: на локально перенаправленный порт (?) пришло соединение, серверу передаются требуемые IP адрес и порт, IP адрес и порт источника; клиенту рекомендуется не принимать запросов от сервера

• pty-req: сессии нужен терминал, при запросе терминала передаётся значение TERM, ширина и высота в символах и пикселах, режим работы (VINTR, VQUIT, ISIG, ICANON и т.д.; IUTF8 добавлен в RFC-8160)
• x11-req: сессии требуется перенаправление X11, параметры: единственное соединение, номер экрана, протокол аутентификации (MIT-MAGIC-COOKIE-1), кука; приложение на сервере общается с виртуальным X сервером, созданным ssh; ssh передаёт данные X протокола по защищённому каналу на клиентскую машину, где и передаёт настоящему X серверу; данные X авторизации подменяются, локальные данные X авторизации не передаются на сервер; рекомендуется разрешать подключения к X серверу только локально;
• env: передать имя и значение переменной окружения; рекомендуется фильтрация
• shell: запуск стандартной оболочки пользователя (из /etc/passwd); ввод и вывод перенаправляются через защищённый канал
• exec: запуск указанной программы (можно указать полный путь или не указать)
• subsystem: (использование SSH как транспорта):
  • sftp (более 10 лет ожидается стандартизация secsh-filexfer, поддерживается в OpenSSH (sftp) и Putty (PSFTP)): доступ к удалённой файловой системе, двоичный, асинхронный, текущая версия 6, поддерживаются различные атрибуты файлов (тип (POSIZ), размер, выделенный размер, владелец (как в NFSv4 с '@', UTF-8), группа, права (POSIX), atime, ctime (время изменения атрибутов) и creationtime, mtime, acl (как в NFSv4), биты атрибутов, тип MIME, линки, расширенные атрибуты), блокировку чтения и записи, различные дипы ACL (ALLOW, DENY, AUDIT, ALARM), имена файлов в стиле POSIX (UTF-8); в общем, перетяжелённый стандарт
  • rpki-rtr (RFC-6810): надёжное получение Resource Public Key Infrastructure (RFC-6480) для анонсов BGP AS, не читал
  • netconf (RFC-6242, перекрывает RFC-4742): выполнение NETCONF (Network Configuration Protocol, RFC-6241, установка, изменение и удаление конфигураций сетевых устройств; RPC на XML) внутри сессии SSH; использование подсистемы вместо обычного ssh избавляет от необходимости обработки промпта и дурацких начальных сообщений; используется порт 830/tcp
  • snmp (RFC-5592): передача SNMP по SSH (чтобы не развёртывать ещё одну систему управления ключами как в SNMPv3), кеширование сессий
  • publickey (RFC-4819): позволяет клиенту добавлять, удалять и смотреть свои публичные ключи на сервере; атрибуты ключа: comment (UTF-8), comment-language, command-override, subsystem, x11, shell, exec, agent, env, from, port-forward, reverse-forward

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

  Публичный ключ представляет собой текстовый файл, разделённый на строки не длиннее 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 от непреобразованного тела ключа в шестнадцатеричном виде через ":".

  • server-sig-algs: сервер сообщает какие алгоритмы публичного ключа он готов использовать при аутентификации клиента (клиент может сразу использовать подходящий алгоритм вместо перебора)
  • delay-compression (списки допустимых алгоритмов для каждого направления): начать сжатие со следующего собщения после аутентификации клиента (от сервера) или запроса клиента (от клиента); ошибка реализации в OpenSSH 7.5 и ранее
  • no-flow-control: буфер сообщений (window) бесконечен; действует, если одна из сторон настаивает (preferred); выгоден при одноканальной передаче файлов
  • elevation: в Windows - поднятие прав пользователя после соединения

  Готовится стандарт на 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.

  Был бесплатен только для некоммерческого использования или опробации (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), содержащий строку

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

  Открытая и бесплатная реализация протоколов 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.

  • diffie-hellman-group1-sha1 (считается слабым, короткий, SHA1)
  • diffie-hellman-group14-sha1 (считается слабым из-за SHA1, надо бы подлинее)
  • diffie-hellman-group-exchange-sha1 (считается слабым из-за SHA1, надо ставить ограничения снизу на размер)
  • diffie-hellman-group-exchange-sha256 (надо ставить ограничения снизу на размер - 2048, а лучше 3072)
  • diffie-hellman-group14-sha256 (надо бы подлинее)
  • diffie-hellman-group16-sha512
  • diffie-hellman-group18-sha512
  • ecdh-sha2-nistp256 (надо бы подлинее)
  • ecdh-sha2-nistp384
  • ecdh-sha2-nistp521
  • curve25519-sha256 (надо бы подлинее)
  • ssh-dss (где-то тут засада с 1024 бит и SHA1)
  • rsa-sha2-256
  • ssh-ed25519 (надо бы подлинее)
  • ecdsa-sha2-nistp256 (надо бы подлинее)
  • ecdsa-sha2-nistp384
  • ecdsa-sha2-nistp521
  • 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 (псевдосертификат)
  • ssh-dss-cert-v01@openssh.com (псевдосертификат, где-то тут засада с 1024 бит)
  • ssh-rsa-cert-v01@openssh.com (псевдосертификат, где-то тут засада с SHA2)
  • rsa-sha2-256-cert-v01@openssh.com (псевдосертификат)
  • hmac-sha2-256
  • hmac-sha2-512
  • aes128-ctr (надо бы подлинее)
  • aes192-ctr
  • aes256-ctr

  Текст прошлого века - давно не работаю с 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"), только в прошивках с шифровкой, имеется множество ограничений на методы аутентификации клиента. Плюс к этому ограничения на экспорт сильной криптографии в США. В общем, вы меня поняли ;)

  Специфические ключи:
  • --help
  • --prefix=куда-устанавливать (/usr/local)
  • --without-openssl
  • --without-stackprotect
  • --without-hardening
  • --with-rsh=имя-файла (до ?)
  • --with-pam (с 2.5.1p1)
  • --with-pam-service=имя
  • --without-pam (до 2.5.1p1)
  • --with-privsep-user=имя-пользователя
  • --with-privsep-path=/var/empty (куда chroot)
  • --with-sandbox= (метод разделения привилегий)
  • --with-selinux
  • --with-xauth=путь
  • --with-maildir=путь
  • --with-mantype=
  • --without-lastlog (до ?)
  • --with-lastlog=каталог
  • --with-kerberos4=путь (до ?)
  • --with-kerberos5=путь
  • --with-skey (до ?)
  • --with-tcp-wrappers (libwrap.a есть? до ?)
  • --with-md5-passwords (пароли MD5 используются, а PAM - нет)
  • --without-shadow
  • --with-ipaddr-display (указывать IP в DISPLAY вместо имени)
  • --with-default-path=PATH (устанавливает переменную PATH для сессии)
  • --with-superuser-path (?)
  • --with-4in6
  • --with-ipv4-default (использовать IPv4 по умолчанию вместо IPv6, до ?)
  • --with-bsd-auth
  • --with-pid-dir=каталог
  • --with-egd-pool (до 2.5.2p1)
  • --with-prngd-socket=файл (с 2.5.2p1)
  • --with-prngd-port=порт (с 2.5.2p1)
  • --with-solaris-contracts
  • --with-solaris-projects
  • --with-solaris-privs
  • --with-zlib=путь
  • --without-zlib-version-check
  • --with-ldns (ldns для DNSSEC)
  • --with-libedit (для sftp)
  • --with-audit=модуль
  • --with-ssl-dir=путь-к-OpenSSL
  • --without-openssl-header-check
  • --with-ssl-engine (аппаратная поддержка)
  • --disable-suid-ssh (с 3.0, до ?)
  • --disable-largefile
  • --disable-pkcs11
  • --disable-lastlog
  • --disable-utmp
  • --disable-utmpx
  • --disable-wtmp
  • --disable-wtmpx
  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
  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
      • /usr/local/openssh81/bin: ssh, scp, ssh-add, ssh-agent, ssh-keygen, ssh-keyscan, sftp
      • /usr/local/openssh81/sbin: sshd
      • /usr/local/openssh81/share/man/man1: ssh.1, scp.1, ssh-add.1, ssh-agent.1, ssh-keygen.1, ssh-keyscan.1, sftp.1
      • /usr/local/openssh81/share/man/man5: moduli.5, sshd_config.5, ssh_config.5
      • /usr/local/openssh81/share/man/man8: sshd.8, sftp-server.8, ssh-keysign.8, ssh-pkcs11-helper.8
      • /usr/local/openssh81/libexec: ssh-keysign, ssh-pkcs11-helper, sftp-server
      • /var/empty
      • ssh-keygen: generating new host keys: RSA DSA ECDSA ED25519 # в /usr/local/openssh81/etc
        • moduli # для обмена ключей DH Group Exchange, размеры 2047, 3071, 4095, 6143, 7679, 8191
        • ssh_host_dsa_key[.pub]
        • ssh_host_rsa_key[.pub]
        • ssh_host_ecdsa_key[.pub]
        • ssh_host_ed25519_key[.pub]
      • /usr/local/openssh81/sbin/sshd -t -f /usr/local/openssh81/etc/sshd_config
  11. на всякий случай проверка простых чисел: /usr/local/openssh81/bin/ssh-keygen -f /usr/local/openssh81/etc/moduli -v -T /tmp/moduli
  12. борьба с SELinux за право запустить нестандартный sshd сервер
  13. ключи хоста для TOP SECRET
  14. попытался сделать права доступа к приватным ключам как в базовой системе (группа ssh_keys имеет право чтения) - сервер при запуске ругается
  15. жёсткая настройка sshd (оригинальные сохранить в /usr/local/openssh81/etc/sshd_config.orig)
  16. скопировать сервис sshd в sshd81:
      • cp -a /lib/systemd/system/sshd.service /etc/systemd/system/sshd81.service # и улучшить его
        • не нужен sshd-keygen.service
        • поменять /etc/sysconfig/sshd на /etc/sysconfig/sshd81
        • поменять /usr/sbin/sshd на /usr/local/openssh81/sbin/sshd
        • "настоящий" openssh ничего не знает про systemd: заменить notify на simple, убрать "-D"
        • закоментировать Restart*
      • /etc/sysconfig/sshd81 # убрать автогенерацию ключей
      • cp -a /lib/systemd/system/sshd.socket /etc/systemd/system/sshd81.socket # поменять порт и конфликты
      • systemctl daemon-reload
      • systemctl start sshd81
      • systemctl enable sshd81
  17. если пользователей и серверов много,то использовать упрощённые сертификаты
  18. для доступа только по публичному ключу пароль в /etc/shadow не нужен (правда, перестаёт работать команда su)
  19. ключ пользователя
  20. настройка клиента (.ssh/config)
  21. тестирование простого входа: ssh хост
  22. тестирование VNC (через X11 и без):
      • ssh хост vncserver -geometry 1600x1200 -depth 24
      • запомнить номер сеанса VNC (например, :2)
      • ssh -L 5902:localhost:5902 хост vncviewer localhost:2 # через X11
      • без X11

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

  • -v[v]
  • -b размер (от 512)
  • -S начальная-точка
  • -v[v]
  • -j номер # с какого кандидата начать
  • -J строка # каким кандидатом закончить
  • -a количество-проверок

  Аутентификация сервера клиентом производится с помощью алгоритмов ассиметричной криптографии с публичным ключом для чего администратор сервера генерирует пару ключей - приватный и публичный ключи сервера. Приватный ключ сервера должен храниться в тайне (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 (по умолчанию, устойчивое шифрование, комментарии к приватному ключу).

  • dsa - по умолчанию 1024 бит, SHA256, в файлы /usr/local/openssh81/etc/ssh_host_dsa_key и /usr/local/openssh81/etc/ssh_host_dsa_key (/etc/ssh/ssh_host_dsa_key и /etc/ssh/ssh_host_dsa_key)
  • rsa - по умолчанию 3072 бит (версия 8.1), SHA256, в файлы /usr/local/openssh81/etc/ssh_host_rsa_key и /usr/local/openssh81/etc/ssh_host_rsa_key (/etc/ssh/ssh_host_rsa_key и /etc/ssh/ssh_host_rsa_key)
  • ecdsa - по умолчанию 256 бит, SHA256, в файлы /usr/local/openssh81/etc/ssh_host_ecdsa_key и /usr/local/openssh81/etc/ssh_host_ecdsa_key (/etc/ssh/ssh_host_ecdsa_key и /etc/ssh/ssh_host_ecdsa_key)
  • ed25519 - по умолчанию 256 бит, SHA256, в файлы /usr/local/openssh81/etc/ssh_host_ed25519_key и /usr/local/openssh81/etc/ssh_host_ed25519_key (/etc/ssh/ssh_host_ed25519_key и /etc/ssh/ssh_host_ed25519_key)
  • -t тип # dsa, rsa, ecdsa, ed25519
  • -m формат # RFC4716, PKCS8, PEM; по умолчанию, в своём собственном
  • -b число-бит
  • -N парольная-фраза # приватные ключи могут быть зашифрованы; ключ хоста должен иметь пустую парольную фразу, т.к. её некому вводить; восстановления нет; по умолчанию парольная фраза запрашивается с терминала; алгоритм шифрования меняется от версии к версии
  • -C комментарий # по умолчанию - имя-пользователя@имя-хоста
  • -f имя-файла-записи
  • -q # не болтать
  • -a кругов # количество циклов KDF при шифровании парольной фразы (см. PKCS#5)

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

  • ssh-keygen -p # изменение парольной фразы, ключи
    • -P старая-парольная-фраза
    • -N новая-парольная-фраза
    • -f файлы-с-ключами
    • -m формат # RFC4716, PKCS8, PEM; по умолчанию, в своём собственном
    • -a кругов # количество циклов KDF при шифровании парольной фразы (см. PKCS#5)
    • -P парольная-фраза
    • -C комментарий
    • -f файл-с-ключами
    • -f файл-с-ключами
    • -m формат # RFC4716, PKCS8, PEM; по умолчанию, RFC4716
    • -f файл-с-ключами
    • -m формат # RFC4716, PKCS8, PEM; по умолчанию, RFC4716

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

    • ssh-keygen -l [-f файл-с-ключами] [-E md5 | sha256] [-v] # показать отпечатки в формате md5 или sha256; -v - показать визуальный образ
    • ssh-keygen -B [-f файл-с-ключами] # показать отпечатки в виде bubblebabble digest
    • ssh-keygen -r доменное-имя [-f файл-с-ключами] # вывести запись ресурса DNS SSHFP (fingerprint RR) для настройки DNSSEC; -g - полный текст

    Связка публичных ключей известных хостов (/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. комментарий
    • вывести файл с публичным ключом любым удобным способом
    • ssh-keygen -y [-f файл-с-ключами] # читает приватный OpenSSH ключ и выдает OpenSSH публичный ключ
    • использовать для получения ключей хостов утилиту ssh-keyscan, в качестве параметраов указываются списки (через запятую) имён и/или адресов хостов, опрос производится параллельно, опции:
      • -t список-типов-ключей-через-запятую # dsa, ecdsa, ed25519, rsa; по умолчанию - ecdsa,ed25519,rsa; в разных версиях путаница с rsa-sha1 и rsa-sha-256
      • -T секунд # время ожидания; по умолчанию - 5
      • -f имя-файла # каждая строка содержит список (через запятую) имён и/или адресов хоста); файл с именем "-" представлят stdin
      • -4 # IPv4
      • -6 # IPv6
      • -p порт
      • -c # запрашивать вместо ключей упрощённые сертификаты
      • -D # выводить в формате для SSHFP DNS
      • -H # выводить хеши вместо имён хостов; OpenSSH умеет работать с ключами по хешам, а посторонним не надо видеть имена хостов
      • -v

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

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

      • ssh-keygen -F [имя-или-адрес-хоста][:порт] [-lv] [-f имя-файла-связки] # искать ключ хоста в связке
      • ssh-keygen -R [имя-или-адрес-хоста][:порт] [-f имя-файла-связки] # удаление записи о сервере из связки
      • ssh-keygen -H [-f имя-файла-связки] # заменить имена и адреса хостов на хеши, старая версия помещается в файл с суффиксом .old; OpenSSH умеет работать с ключами по хешам, а посторонним не надо видеть имена хостов

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

      • id_dsa - по умолчанию 1024 бит, SHA256
      • id_rsa - по умолчанию 3072 бит (версия 8.1), SHA256
      • id_ecdsa - по умолчанию 256 бит, SHA256
      • id_ed25519 - по умолчанию 256 бит, SHA256

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

      • -t тип # dsa, rsa, ecdsa, ed25519
      • -m формат # RFC4716, PKCS8, PEM; по умолчанию, в своём собственном
      • -b число-бит
      • -N парольная-фраза # приватные ключи могут быть зашифрованы; ключ хоста должен иметь пустую парольную фразу, т.к. её некому вводить; восстановления нет; по умолчанию парольная фраза запрашивается с терминала; алгоритм шифрования меняется от версии к версии
      • -C комментарий # по умолчанию - имя-пользователя@имя-хоста
      • -f имя-файла-записи
      • -q # не болтать
      • -a кругов # количество циклов KDF при шифровании парольной фразы (см. PKCS#5)

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

      Для аутентификации пользователя по публичному ключу сервером публичный ключ предварительно созданной пары ключей пользователя должен быть помещён в одну из связок авторизованных публичных ключей пользователя Сервер проверяет наличие в одной из связок предъявленного клиентом публичного ключа или публичного ключа CA, которым подписан предъявленный ключ (должен быть помечен маркером @cert-authority в связке). Обычно каждый пользователь имеет свою связку на сервере в

      1. опции (необязательное поле) через запятую, пробелы только внутри кавычек
         • agent-forwarding (разрешить перенаправление запросов к агенту на агента клиентского хоста)
         • no-agent-forwarding
         • cert-authority (ключ является публичным ключом CA, приватным ключом которого могут быть подписаны публичные ключи пользователей); где revoked?
         • command="команда" (при аутентификации по данному ключу запускать только указанную команду, а не то что указано пользователем (помещается в SSH_ORIGINAL_COMMAND); TCP/IP и X11 надо запрещать дополнительно; обязательно использовать опцию no-pty для бинарной передачи данных)
         • environment="имя=значение" (может быть несколько; по умолчанию запрещено, см. PermitUserEnvironment)
         • expiry-time="время" (в формате YYYYMMDD или YYYYMMDDHHMMSS)
         • from="список-шаблонов-через-запятую" (принимать соединения только с хостов, удовлетворяющих одному из шаблонов по имени или IP адресу или адрес/длина-маски; проверки производятся слева направо; спец. символы - ?, * и !)
         • permitlisten="[хост:]порт" (ограничить переназначение удалённого порта: ssh -R; можно использовать несколько раз; при указании хоста и/или порта можно использовать шаблоны; по умолчанию - localhost)
         • permitopen="хост:порт" (ограничить переназначение локального порта: ssh -L; можно использовать несколько раз; шаблоны хоста не обрабатываются; в качестве порта можно указывать *)
         • port-forwarding (разрешить перенаправление портов)
         • no-port-forwarding
         • principals="список-имён-через-запятую" (только для публичного ключа: предъявляемый сертификат должен иметь имя из этого списка)
         • pty (разрешить запрос терминала tty - интерактивную обработку)
         • no-pty (запретить запрос терминала tty - интерактивную обработку)
         • restrict (всё запретить)
         • tunnel=номер-устройства
         • user-rc (разрешить выполнение

      В стандарте предусмотрена автоматическая проверка публичных ключей с использованием системы сертификации 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, которым подписан предъявленный сервером публичного ключа. Аналогично поступает и сервер при аутентификации пользователя или хоста клиента.

      • номер сертификата (необязателен, можно указать 0)
      • тип (хост или пользователь)
      • публичный ключ
      • идентификатор (для комментариев)
      • имя (имена) пользователя или хоста
      • время начала и конца действия
      • для сертификатов пользователей обязательные опции: force-command, source-address (описание см. authorized_keys)
      • для сертификатов пользователей дополнительные опции: permit-X11-forwarding, permit-agent-forwarding, permit-port-forwarding, permit-pty, permit-user-rc (описание см. authorized_keys)
      • -h # это сертификат хоста, а не пользователя
      • -s приватный-ключ-CA
      • -U # ключ CA доступен через ssh-agent; в -s указывается публичный ключ CA
      • -D pkcs11 [-s] # загрузить ключ (сертификат) из устройства PKCS#11; в -s указывается публичный ключ CA
      • -n список-имён-хостов-или-пользователей # если не указать, то сертификат действует для любого хоста или имени пользователя
      • -t тип-подписи # ssh-rsa, rsa-sha2-256, rsa-sha2-512
      • -O опции # пока только для сертификатов пользователя
        • clear # удалить опции по умолчанию
        • critical:имя[=значение] # строки оформляются в кавычках
          • force-command=команда # после аутентификации выполнять указанную команду вместо запуска оболочки или команды, указанной пользователем
          • source-address=список # адреса/маски через запятую, откуда принимается сертификат

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

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

          • создание ключей CA
          • внесение публичного ключа CA в связку известных публичных ключей на клиенте [и сервере]
          • создание ключей серверов
          • подпись публичных ключей серверов ключём CA (rsa-sha2-256-cert-v01@openssh.com (3072 бит), ecdsa-sha2-nistp384-cert-v01@openssh.com)
          • создание ключей пользователей
          • подпись публичных ключей пользователей ключём CA
          • внесение публичного ключа CA в общесистемную связку авторизованных публичных ключей

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

          • ssh-keygen -k -f KRL-файл имя-файла . # создание или расширение списка отозванных сертификатов, файлы содержитат публичные ключи по одному на строке или спецификацию KRL, опции:
            • -s публичный-ключ-CA # для отзыва сертификатов по серийному номеру, идентификатору
            • -z версия-KRL
            • -u # расширение списка вместо создания
            • serial: серийный_номер[-серийный_номер]
            • id: идентификатор_ключа
            • key: публичный_ключ
            • sha1: публичный_ключ # отзыв по хешу SHA1
            • sha256: публичный_ключ # отзыв по хешу SHA256
            • hash: отпечаток-SHA256
            • ssh-keygen -Y sign -f приватный-ключ [имя-файла] . # подписать файл; если имя файла не указано, то stdin; подпись сохраняется в имя-файл.sig; можно указывать публичный ключ, если приватная часть доступна через ssh-agent; опция "-n область-действия" позволяет указать, что подписываем (file, email и т.д.)
            • ssh-keygen -Y verify # проверить подпись данных с stdin, опции
              • -n область-действия # что подписываем (file, email и т.д.)
              • -s файл-подпись
              • -I имя-подписанта
              • -f файл-со-списком-потенциальных-подписантов # allowed signers
              • -r файл-с-отозванными ключами (KRL или простой список (?))
              • -n область-действия # что подписываем (file, email и т.д.)
              • -s файл-подпись
              • -4 (IPv4)
              • -6 (IPv6)
              • -c файл-сертификата (для ключей хоста, задаваемых опцией -h или HostKey)
              • -D (не отсоединяться от терминала при запуске)
              • -d (отладочный режим, использование опции несколько раз увеличивает количество отладочной печати; только 1 соединение; не отсоединяется от терминала и не уходит в фоновый режим)
              • -E имя-файла (отладочная печать дописывается в указанный файл)
              • -e (выводить отладочную печать на stderr вместо syslog)
              • -f имя-конфигурационного-файла (умолчание указывается при сборке: /etc/ssh/sshd_config, /usr/local/etc/sshd_config, /usr/local/openssh81/etc/sshd_config, )
              • -g секунд (сколько ждать пока пользователь вспомнит пароль; по умолчанию - 120 секунд; 0 - вечность)
              • -h файл-ключей-хоста (можно указать несколько ключей)
              • -i (если запущен из inetd)
              • -o опция (см. sshd_config)
              • -p порт (по умолчанию - 22; можно указать несколько ключей)
              • -q (ничего не посылать на syslog)
              • -T (тестирование конфигурации; опции -C позволяет задать предполагаемые параметры соединения для тестирования Match: addr (исходящий адрес), user, host (имя исходящего хоста), laddr (локальный адрес), lport (локальный порт), rdomain (домен маршрутизации)
              • -t (проверка на отсутствие ошибок в конфигурационном файле и ключах)
              • -u число (вместо имен хостов, превышающих эту длину, в utmp будет записываться IP-адрес: -u0 вызывает безусловную запись IP-адресов)

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

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

              • /etc/init.d/sshd в Solaris 2.5 (и ссылка на него /etc/rc2.d/S99sshd) - сделать из соседнего скрипта
              • initd в Linux: скрипт /etc/rc.d/init.d/sshd (и ссылка на него /etc/rc.d/rc2.d/S98sshd, /etc/rc.d/rc3.d/S98sshd) берётся из rpm; опции сервера берутся из /etc/sysconfig/sshd
              • systemd (опции сервера берутся из /etc/sysconfig/sshd), юниты
                • /lib/systemd/system/sshd.service
                  • для RHEL/CentOS
                  • для неадаптированного

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

                  • AcceptEnv имена-переменных-окружения-через-пробел (какие из переданных переменных окружения (SendEnv и SetEnv на клиентской стороне) принимать; можно использовать шаблоны с * и ?; переменная TERM принимается всегда при выделении псевдотерминала (положено по протоколу); директиву можно использовать несколько раз; по умолчанию - ни одной)
                  • AddressFamily
                  • AllowAgentForwarding (при наличии комадной оболочки пользователь может запустить свой посредник)
                  • AllowGroups список-имен-групп-через-пробел (вход разрешен только пользователям, чья первичная и вторичная группа входит в этот список; шаблоны с использованием '?' и '*' и '!'; по умолчанию - всем)
                  • AllowStreamLocalForwarding (разрешение перенаправлять Unix сокеты, локальность относительно коиента; при наличии комадной оболочки пользователь может запустить свой посредник)
                  • AllowTcpForwarding (разрешение перенаправлять TCP порты, локальность относительно коиента; при наличии комадной оболочки пользователь может запустить свой посредник)
                  • AllowUsers список-имен-через-пробел (можно в форме имя-пользователя@хост; вход разрешён только указанным пользователям; в качестве хоста можно использовать имена, шаблоны, адреса и адрес/длина-маски-сети; шаблоны с использованием '?' и '*' и '!'; по умолчанию - всем)
                  • AuthenticationMethods список-имён-методов-через-запятую . (по умолчанию - any; для успешного входа все методы одного из списков должны быть удовлетворены по порядку; возможные методы: gssapi-with-mic, hostbased, keyboard-interactive, none (PermitEmptyPasswords), password, publickey; для списка "publickey,publickey" должны быть использованы различные ключи)
                  • AuthorizedKeysCommand абсолютный-путь-к-программе параметр . (программа должна вернуть строки в формате authorized_keys; параметр по умолчанию - имя пользователя; при задании параметров можно использовать макросы; владельцем программы должен быть root; если программа не указана или результат неприемлем, то используется AuthorizedKeysFile)
                  • AuthorizedKeysCommandUser имя-пользователя (указанная в AuthorizedKeysCommand программа исполняется от имени этого пользователя; обязательно указывать; рекомендуется иметь отдельного пользователя для данной роли)
                  • AuthorizedKeysFile имя-файла . (файл с публичными ключами пользователя; можно использовать макросы; имя файла - абсолютное или относительно домашнего каталога пользователя; none - не использовать; по умолчанию - ".ssh/authorized_keys .ssh/authorized_keys2")
                  • AuthorizedPrincipalsCommand абсолютный-путь-к-программе параметр . (программа должна вернуть строки в формате списка имён пользователей (см. AuthorizedPrincipalsFile); параметр по умолчанию - имя пользователя; при задании параметров можно использовать макросы; владельцем программы должен быть root; если программа не указана или результат неприемлем, то используется AuthorizedPrincipalsFile
                  • AuthorizedPrincipalsCommandUser имя-пользователя (указанная в AuthorizedPrincipalsCommand программа исполняется от имени этого пользователя; обязательно указывать; рекомендуется иметь отдельного пользователя для данной роли)
                  • AuthorizedPrincipalsFile имя-файла . (файл с именами, допустимыми при аутентификации с помощью упрощённых сертификатов (см. TrustedUserCAKeys); можно использовать макросы; имя файла - абсолютное или относительно домашнего каталога пользователя; none - не использовать (допустимые имена берутся из сертификата); пустые строки и строки, начинающиеся с '#' являются комментариями; по одному имени на строку; опции как в authorized_keys)
                  • Banner (сообщение перед аутентификацией; рекомендуется выдавать предупреждение о незаконности неавторизованного входа - говорят, что помогает в суде ;)
                  • CASignatureAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa (алгоритмы, допускаемые при подписи сертификатов)
                  • ChallengeResponseAuthentication < yes | no >(разрешить аутентификацию типа запрос-ответ через PAM или login)
                  • ChrootDirectory < none | каталог >(делать chroot в указанный каталог после аутентификации пользователя, после чего переход в домашний каталог; владельцем должен быть root; при задании имени каталога можно использовать макросы)
                  • Ciphers chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com (список алгоритмов симметричного шифрования; также поддерживаются 3des-cbc, aes128-cbc, aes192-cbc, aes256-cbc; список можно заменять, дополнять в начало ('^'), дополнять в конец '(+') и удалять из списка '-'); актуальный список можно получить по команде "ssh -Q cipher")
                  • ClientAliveCountMax 3 (число неудачных проверок связи после которых сессия разрывается; проверки производятся по защищённому каналу)
                  • ClientAliveInterval 0 (интервал проверки в секундах не отвалился ли клиент; проверки производятся по защищённому каналу; 0 - не посылать)
                  • Compression < yes | no | delayed >(включить сжатие после аутентификации; delayed - синоним yes)
                  • DenyGroups список-имен-групп-через-пробел (вход запрещён пользователям, чья первичная или вторичная группа входит в этот список; шаблоны с использованием '?' и '*' и '!'; по умолчанию - разрешено всем)
                  • DenyUsers список-имен-через-пробел (можно в форме имя-пользователя@хост; вход запрещён указанным пользователям; в качестве хоста можно использовать имена, шаблоны, адреса и адрес/длина-маски-сети; шаблоны с использованием '?' и '*' и '!'; по умолчанию - разрешено всем
                  • DisableForwarding (запретить все перенапрвления - X11, ssh-agent(1), TCP и StreamLocal)
                  • ExposeAuthInfo < no | yes >(информацию об аутентификации записать во временный файл; его имя поместить в SSH_USER_AUTH)
                  • FingerprintHash . (какой MAC использовать при выводе отпечатков)
                  • ForceCommand (указанная команда вызывается после аутентификации вместо

                  /.ssh/environment и опции environment= в

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

                  • %% - %
                  • %D - домен маршрутизации
                  • %F - отпечаток ключа CA
                  • %f - отпечаток ключа или сертификата
                  • %h - домашний каталог пользователя
                  • %i - идентификатор ключа в сертификате
                  • %K - ключ CA в base64
                  • %k - ключ или сертификат в base64
                  • %s - серийный номер сертификата
                  • %T - тип ключа CA
                  • %t - тип ключа или сертификата
                  • %U - uid
                  • %u - имя пользователя

                  Нижеизложенное дано с точки зрения 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.

                  ssh - замена telnet, rsh, rlogin,безопасное соединение с X11-сервером и шифровка произвольного TCP/IP соединения. Поддерживает протокол версии 2 (версия 1 небезопасна), методы аутентификации - GSSAPI, по хосту (проверяется публичный ключ хоста клиента /usr/local/openssh81/etc/ssh_known_hosts и

                  /.shosts), по публичному ключу, challenge-response, по паролю. В качестве параметров указывается сервер и выполняемая команда. Сервер может быть указан в форматах: имя-пользователя@сервер или ssh://[имя-пользователя@]имя-хоста[:порт]. В настройках клиента адрес, порт и имя пользователя могут быть переопределены по имени сервера. Если команда не указана, то запускается командная оболочка (указывается в настройках пользователя на сервере). Настройки сервера могут навязать исполняемую прграмму (forced-command).

                  Вместо тильды можно установить другой 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.

                  • -1 # только SSH1; удалено
                  • -2 # только SSH2; удалено
                  • -4 # только IPv4
                  • -6 # только IPv6
                  • -A # разрешить проброс имеющегося соединения агента аутентификации; может быть запрещено в настройках клиента или сервера; не рекомендуется перенаправлять соединение на хост, где злоумышленник имеет достаточно прав для к сокету Unix-domain - через него он сможет получить доступ к локальному агенту достаточного уровня, чтобы аутентифицироваться с его ключевым материалом (сами ключи он извлечь не сможет)
                  • -a # запретить проброс имеющегося соединения агента аутентификации
                  • -B интерфейс # использовать указанный интерфейс для исходящего соединения
                  • -b IP-адрес # использовать указанный IP-адрес для исходящего соединения
                  • -C # сжатие stdin, stdout, stderr, X11, TCP/IP порты - zlib; не рекомендуется на быстрых каналах
                  • -c список-алгоритмов-шифрования-через-запятую # алгоритм в начале списка имеет наибольший приоритет; см. Ciphers; по умолчанию: chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm@openssh.com,aes256-gcm@openssh.com
                  • -D [IP-адрес:]локальный-порт # слушается указанный локальный порт; настройки IP-адреса по умолчанию берутся из GatewayPorts; localhost - только локальные пользователи смогут подключаться; пусто или '*' - порт будет доступен из сети; приходящее на него соединение пробрасывается по защищенному каналу; при этом ssh работает как сервер SOCKS по протоколу SOCKS4 или SOCKS5 для определения куда подключаться на удалённом конце; привилегированные порты может перенаправлять только суперпользователь; опция может быть использована несколько раз
                  • -E # отладочная печать будет добавляться к файлу вместо вывода в syslog
                  • -e < символ | none ># escape-символ вместо тильды; none обеспечивает прозрачную передачу данных
                  • -F имя-конфигурационного-файла # по-умолчанию -

                  /.ssh/id_ed25519 и в старых версиях

                  • help
                  • cipher - симметричные алгоритмы шифрования
                  • cipher-auth - симметричные алгоритмы шифрования с аутентификацией
                  • mac - алгоритмы хеширования
                  • kex - алгоритмы обмена ключами
                  • key - типы ключей
                  • key-cert - типы ключей с сертификатами
                  • key-plain - типы ключей без сертификатов
                  • protocol-version - версии протокола SSH
                  • sig - алгоритмы цифровой подписи

                  Вместо ключей можно использовать файлы конфигурации - личный (

                  • Host шаблоны-через-пробел # следующие параметры применимы к хостам, подходящим под один из шаблонов; имя хоста берется из командной строки (т.е. неканоническое); в шаблонах используются символы '*', '!' и '?')
                  • Match критерии-через-пробел # следующие параметры применимы к вызовам, удовлетворяющим всем критериям, можно использовать отрицание ('!')
                    • all # всегда удовлетворён; можно использовать после canonical и final
                    • canonical # эта секция параметров действует после повторного разбора конфигурационого файла при канонизации имён хостов (см. CanonicalizeHostname)
                    • final # эта секция параметров действует после повторного разбора конфигурационого файла
                    • exec "команда параметр . " # параметры применяются, если команда возвращает 0; можно использовать макросы
                    • host имя-хоста[. ] # имя хоста после замен Hostname и CanonicalizeHostname; в шаблонах используются символы '*', '!' и '?'
                    • originalhost # имя хоста до замен Hostname и CanonicalizeHostname; в шаблонах используются символы '*', '!' и '?'
                    • user имя-пользователя-на сервере[. ]
                    • localuser имя-локального-пользователя[. ]

                    При входе на удаленный сервер устанавливаются переменные: 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-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 не передаёт приватный ключ своему клиенту, а выполняет необходимые действия от его имени.

                    • -b имя-сокета
                    • -c (выдавать на stdout команды в стиле csh)
                    • -s (выдавать на stdout команды в стиле sh)
                    • -t максимальное-время-хранения-идентификаций (в секундах)
                    • -k (завершить работу агента - по переменной SSH_AGENT_PID)
                    имя файла с приватным ключом (по-умолчанию -

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

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

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

                    Текст 1999 года.

                    1. устанавливаем OpenSSH на все хосты как было описано выше (здесь же создаются RSA/DSA ключи хостов)
                    2. конфигурируем /usr/local/etc/sshd_config (/etc/ssh/sshd_config, права 600) на серверах (я опускаю несущественные параметры)
                    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"
                       1. Host *
                       2. FallBackToRsh no
                       3. GatewayPorts no
                       4. HostbasedAuthentication no
                       5. IdentityFile

                       /.ssh/authorized_keys (права 600) добавить содержимое файла

                       /.ssh/authorized_keys (права 600) добавить строку (учитывать значение PATH): command ,no-X11-forwarding,no-port-forwarding,no-pty,no-agent-forwarding <содержимое файла

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

                       • [user@]имя-хоста[:dir/]
                       • -b имя-файла (читает команды из файла вместо stdin)
                       • -C (сжатие)
                       • -F имя-конфигурационного-файла-ssh
                       • -o опция (передается ssh)
                       • -v

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

                       📎📎📎📎📎📎📎📎📎📎