Протокол SSH для чайников: что это и как работает простыми словами | CoderNet

Аутентификация на основе ssh2 rsa-ключей

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

PubkeyAuthentication yes

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

# Коментарии записываются только с новой строки
# общий вид записей в файле authorized_keys
# [опции] тип_ключа(ssh-rsa или ssh-dss) очень_длинная_строка_непонятная_простому_человеку [логин@хост]
ssh-rsa AAAAB3Nza...LiPk== user@example.net
from="*.sales.example.net,!pc.sales.example.net" ssh-rsa AAAAB2...19Q== john@example.net
command="dump /home",no-pty,no-port-forwarding ssh-dss AAAAC3...51R== example.net
permitopen="192.0.2.1:80",permitopen="192.0.2.2:25" ssh-dss AAAAB5...21S==
tunnel="0",command="sh /etc/netstart tun0" ssh-rsa AAAA...== jane@example.net

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

AuthorizedKeysFile %h/.ssh/my_keys

для схемы пользователь — файл
или

AuthorizedKeysFile /etc/ssh/authorized_keys

для схемы с общим файлом. По умолчанию SSH-клиент ищет ключи в файле ~/.ssh/authorized_keys .

Bog bos: ssh и openssh: принципы работы, установка и настройка

Протокол SSH для чайников: что это и как работает простыми словами | CoderNet

Последнее изменение файла: 2020.04.16

Скопировано с www.vhod-v-lichnyj-kabinet.ru: 2022.08.07

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 подвержен атаке типа “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 не рекомендует (2022) эллиптические кривые 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 бит);
    размер пакета и сам пакет шифруются отдельными ключами)

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

  • 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).

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

  • 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 адрес и порт источника;
    клиенту рекомендуется не принимать запросов от сервера

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

  • 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
  • window-change: изменение ширины и высоты в символах и пикселах
  • xon-xoff: разрешать ли инициатору сессии управлять потоком
  • signal: послать сигнал (ABRT, ALRM, FPE, HUP, ILL, INT, KILL, PIPE, QUIT, SEGV, TERM, USR1, USR2)
  • exit-status: вернуть код возврата инициатору сессии от завершившейся оболочки, программы или подсистемы
  • exit-signal: сигнал, если оболочка, программа или подсистема была завершена сигналом (ABRT и т.д.)
  • break: физический сигнал BREAK, передаётся длительность в милисекундах (RFC-4335)

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

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

  • 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), содержащий строку

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

Формат файла с публичным ключом стандартный, права обязательно “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 (надо бы подлинее)

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

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

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

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

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

  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
    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. скопировать сервис 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. ключ пользователя
    сделать ключи на клиентских компьютерах или сделать их самому и разослать (больше уверенности в наличии шифрования ключей):
    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-ИмяПользователя
    
  20. настройка клиента (.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
    
  21. тестирование простого входа: ssh хост
  22. тестирование VNC (через X11 и без):
    • ssh хост vncserver -geometry 1600×1200 -depth 24
    • запомнить номер сеанса VNC (например, :2)
    • ssh -L 5902:localhost:5902 хост vncviewer localhost:2 # через X11
    • без X11
      ssh -4 -f -L 5902:localhost:5902 хост sleep 180
      vncviewer localhost:2
      

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

Похожее:  Веб-интерфейс роутера. Что это? Как войти?

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

  • -v[v]
  • -b размер (от 512)
  • -S начальная-точка

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

  • -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 (по умолчанию, устойчивое шифрование, комментарии к приватному ключу).

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

  • 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)

Генерация ключей производится утилитой 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

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

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

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

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

  • 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 публичный ключ
  • использовать для получения ключей хостов утилиту ,
    в качестве параметраов указываются списки (через запятую) имён и/или адресов хостов, опрос производится параллельно, опции:

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

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

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

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

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

  • 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 (по умолчанию, устойчивое шифрование, комментарии к приватному ключу).

Генерация ключей производится утилитой 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. комментарий (имя-пользователя@имя-клиентского-хоста)

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

  • -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 опции # пока только для сертификатов пользователя
  • -V дата-завершения # дата может быть в формате YYYYMMDD, YYYYMMDDHHMM[SS], относительное время (“-52w”, ” 5y”), always, forever
  • -V дата-начала:дата-завершения
  • -z последовательный-номер # можно всегда 0

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

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

Процедура:

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

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

  • ssh-keygen -k -f KRL-файл имя-файла … # создание или расширение списка отозванных сертификатов,
    файлы содержитат публичные ключи по одному на строке или спецификацию KRL, опции:

    • -s публичный-ключ-CA # для отзыва сертификатов по серийному номеру, идентификатору
    • -z версия-KRL
    • -u # расширение списка вместо создания
  • ssh-keygen -Q -f KRL-файл ключ … # тестирование ключа на вхождение в KRL

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

  • 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 или простой список (?))
  • ssh-keygen -Y check-novalidate # проверка подписи на синтаксическую корректность (подписанный текст поступает на stdin), опции:
    • -n область-действия # что подписываем (file, email и т.д.)
    • -s файл-подпись

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

  • -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.

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

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

  • AcceptEnv имена-переменных-окружения-через-пробел (какие из переданных
    переменных окружения (SendEnv и SetEnv на клиентской стороне) принимать;
    можно использовать шаблоны с * и ?; переменная TERM принимается всегда при выделении псевдотерминала (положено по протоколу);
    директиву можно использовать несколько раз;
    по умолчанию – ни одной)
  • AddressFamily {any | inet |inet6}
  • AllowAgentForwarding {yes | no} (при наличии комадной оболочки пользователь может запустить свой посредник)
  • AllowGroups список-имен-групп-через-пробел (вход разрешен только пользователям, чья первичная и вторичная группа входит в этот список;
    шаблоны с использованием ‘?’ и ‘*’ и ‘!’; по умолчанию – всем)
  • AllowStreamLocalForwarding {yes | no | all | local | remote} (разрешение перенаправлять Unix сокеты, локальность относительно коиента;
    при наличии комадной оболочки пользователь может запустить свой посредник)
  • AllowTcpForwarding {yes | no | all | local | remote} (разрешение перенаправлять 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 {none | имя-файла } (сообщение перед аутентификацией; рекомендуется выдавать предупреждение о незаконности
    неавторизованного входа – говорят, что помогает в суде 😉
  • 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 {no | yes} (запретить все перенапрвления – X11, ssh-agent(1), TCP и StreamLocal)
  • ExposeAuthInfo { no | yes } (информацию об аутентификации записать во временный файл; его имя поместить в SSH_USER_AUTH)
  • FingerprintHash {sha256 | md5} … (какой MAC использовать при выводе отпечатков)
  • ForceCommand {none | имя-команды} (указанная команда вызывается после аутентификации вместо ~/.ssh/rc и указанной пользователем;
    команда вызывается в виде “оболочка-пользователя -c команда”; указанная пользователем команда помещается в SSH_ORIGINAL_COMMAND;
    internal-sftp – встроенный sftp-сервер)
  • GatewayPorts { no | yes | clientspecified }(разрешать ли удаленным хостам доступ к перенаправленным портам клиента;
    no – слушать порт для перенаправления только на localhost:, yes – на *:)
  • GSSAPIAuthentication {no | yes} (разрешить аутентификацию типа gssapi)
  • GSSAPICleanupCredentials {yes | no} (очищать кеш кредитов при выходе)
  • GSSAPIStrictAcceptorCheck {yes | no}
  • HostbasedAcceptedKeyTypes ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
    (форматы ключей клиентских хостов, принимаемые при аутентификации hostbased; полный список можно посмотреть по “ssh -Q key”;
    список можно заменять, дополнять в начало (‘^’), дополнять в конец ‘( ‘) и удалять из списка ‘-‘)
  • HostbasedAuthentication { no | yes} (разрешить аутентификацию типа hostbased; также см. hosts.equiv(5); не рекомендуется)
  • HostbasedUsesNameFromPacketOnly { no | yes } (использовать имя хоста, полученное от клиента, или делать DNS запрос по IP адресу
    перед поиском в ~/.shosts, ~/.rhosts и /etc/hosts.equiv)
  • HostCertificate имя-файл (файл должен содержать сертификат, соответствующий приватному ключу хоста в HostKey;
    по умолчанию – нет сертификата)
  • HostKey имя-файла-содержащего-приватный-ключ (может быть несколько штук;
    файл должен быть недоступен никому, кроме root;
    формат файла ограничен алгоритмами из HostKeyAlgorithms;
    можно указать публичный клич, в этом случае приватный ключ обеспечивает ssh-agent;
    по умолчанию: /etc/ssh/ssh_host_key, /etc/ssh/ssh_host_dsa_key, /etc/ssh/ssh_host_rsa_key,
    /usr/local/openssh81/etc/ssh_host_ecdsa_key, /usr/local/openssh81/etc/ssh_host_ed25519_key, /usr/local/openssh81/etc/ssh_host_rsa_key)
  • HostKeyAgent сокет (имя сокета для связи с ssh-agent; если указать SSH_AUTH_SOCK, то имя соекта будет взято из переменной окружения)
  • HostKeyAlgorithms ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa (форматы ключей хостов, который сервер предлагает клиентам;
    список можно заменять, дополнять в начало (‘^’), дополнять в конец ‘( ‘) и удалять из списка ‘-‘;
    полный список можно посмотреть по “ssh -Q key”)
  • IgnoreRhosts { yes | no } (не использовать .rhosts и .shosts для Hostbased аутентификации;
    /etc/hosts.equiv и /etc/shosts.equiv (/usr/local/openssh81/etc/shosts.equiv) будут использоваться все равно)
  • IgnoreUserKnownHosts { no | yes } (игнорировать ~/.ssh/known_hosts во время Hostbased аутентификации;
    использовать только /etc/ssh/known_hosts, /usr/local/openssh81/etc/known_hosts)
  • IPQoS af21,cs1 (уровень сервиса для интерактивных и неинтерактивных сессий)
  • KbdInteractiveAuthentication {yes | no} (разрешить аутентификацию типа keyboard-interactive;
    по умолчанию взять из ChallengeResponseAuthentication)
  • KeepAlive yes (использовать механизм регулярных сообщений для проверки разрыва связи; по открытому каналу; удалён в 3.9? см. TCPKeepAlive)
  • KerberosAuthentication { no | yes} (использовать введённый пользователем пароль для валидации через Kerberos KDC)
  • KerberosGetAFSToken { no | yes }
  • KerberosOrLocalPasswd { yes | no } (если аутентификация через Kerberos не прошла, то использовать /etc/passwd)
  • KerberosTicketCleanup { yes | no } (очищать кеш билетов при выходе)
  • KexAlgorithms curve25519-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1
    (список алгоритмов обмена ключами; полный список можно посмотреть по “ssh -Q kex”;
    список можно заменять, дополнять в начало (‘^’), дополнять в конец ‘( ‘) и удалять из списка ‘-‘)
  • ListenAddress { имя-хоста | адрес-хоста}[:порт] (к каким адресам прислушиваться;
    если порт не указан, то брать номер порта из директивы Port;
    директива Port д.б. раньше по тексту;
    по умолчанию (0.0.0.0) слушать все адреса;
    директива может быть использована несколько раз)
  • LoginGraceTime 120 (сколько секунд давать пользователю, чтобы вспомнить пароль; 0 – бесконечность)
  • LogLevel { INFO | QUIET | FATAL | ERROR | INFO | VERBOSE | DEBUG[ 1 | 2 | 3] (DEBUG нарушает приватность пользователей)
  • MACs umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
    (алгоритмы проверки целостности данных; полный список можно посмотреть по “ssh -Q mac”;
    список можно заменять, дополнять в начало (‘^’), дополнять в конец ‘( ‘) и удалять из списка ‘-‘)
  • Match { All | {User | Group | Host | LocalAddress | LocalPort | RDomain | Address} шаблон[,…] … }
    (условный раздел до следующего Match; шаблоны с использованием ‘?’ и ‘*’ и ‘!’)
  • MaxAuthTries 6 (завершать соединение после указанного числа неудачных попыток аутентификации;
    после половины указанного числа начинается запись в журнал)
  • MaxSessions 10 (максимальное количество сессий на соединение; 1 – запрещение мультиплексирования;
    при 0 возможен только проброс соединений)
  • MaxStartups 10:30:100 (максимальное число соединений, ожидающих аутентификации;
    алгоритм раннего предупреждения перегрузки – 10:30:60, отвергать соединение
    с вероятностью 30%, если уже есть 10 еще неаутентифицированных соединений,
    вероятность постепенно возрастает до 100% при 60 соединениях)
  • PAMAuthenticationViaKbdInt no/yes (заодно разрешает аутентификацию по паролю; удалён)
  • PasswordAuthentication yes (разрешить аутентификацию по паролю; дается рекомендация – закрыть)
  • PermitEmptyPasswords no
  • PermitListen { any | none | [хост:]порт } … (какой порт можно пробрасывать с дальней стороны; если хост не указан, то localhost;
    можно использовать шаблоны с использованием ‘?’ и ‘*’ и ‘!’;
    any – любой порт; none – никакой порт)
  • PermitOpen { any | none | хост:порт } … (на какой порт можно пробрасывать; можно использовать ‘*’)
  • PermitRootLogin { prohibit-password | yes | no | without-password | forced-commands-only }
    (prohibit-password (старое название – without-password) запрещает аутентификацию по паролю;
    forced-commands-only – разрешать аутентификацию по тем ключам, для которых указана исполняемая команда)
  • PermitTTY { yes | no }
  • PermitTunnel { no | point-to-point | ethernet | yes } (point-to-point – L3, ethernet – L2, yes – оба)
  • PermitUserEnvironment { no | yes | список-шаблонов }
    (разрешать ли обработку ~/.ssh/environment и опции environment= в ~/.ssh/authorized_keys для передачи параметров;
    не рекомендуется – будут играть с LD_PRELOAD)
  • PermitUserRC { yes | no } (разрешить выполнение ~/.ssh/rc при входе)
  • PidFile /var/run/sshd.pid (имя файла для записи номера головного процесса sshd; none – не писать никуда)
  • Port 22 (может быть несколько директив; лучше пользоваться Listen)
  • PrintLastLog { yes | no } (выводить время предыдущего входа – рекомендуется проверять, не входил ли кто под Вашим именем
  • PrintMotd { yes | no } (выдавать /etc/motd при входе)
  • Protocol 1 (1, 2 или 1,2 – поддерживаемые версии протокола; удалено)
  • PubkeyAcceptedKeyTypes ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,ssh-ed25519-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-rsa-cert-v01@openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa
    (форматы ключей клиентов, принимаемые при аутентификации publickey; полный список можно посмотреть по “ssh -Q key”;
    список можно заменять, дополнять в начало (‘^’), дополнять в конец ‘( ‘) и удалять из списка ‘-‘)
  • PubkeyAuthentication { yes | no }
  • RDomain домен-маршрутизации
  • RekeyLimit байт [секунд] (интервал в байтах (множители K, M и G) и секундах между созданием сессионых ключей;
    умолчания зависят от алгоритма шифрования)
  • ReverseMappingCheck no (после определения адреса по имени хоста
    проверять, что обратная зона для этого адреса указывает на тот же самый хост; удалён – см. UseDNS)
  • RevokedKeys { none | имя-файла } (файл должен содержать отозванные ключи (по одному на строку) или KRL)
  • RhostsAuthentication no (разрешить аутентификацию только по .rhosts или /etc/hosts.equiv; удалён)
  • RhostsRSAAuthentication no (разрешить аутентификацию по .rhosts и RSA аутентификации – требует заполнения ssh_known_hosts; удалён)
  • RSAAuthentication yes (только SSH1; удалён)
  • ServerKeyBits 768 (для SSH1; удалён)
  • SetEnv имя=значение … (позволяет установить переменные окружения для запускаемых команд или команднх оболочек)
  • SkeyAuthentication { yes | no } (требует установки PasswordAuthentication; удалён)
  • StreamLocalBindMask 0177 (umask для пробрасываемых сокетов)
  • StreamLocalBindUnlink { no | yes } (удалять имеющийся сокет при пробрасывании)
  • StrictModes { yes | no } (проверять владельца и права доступа к файлам и каталогу ~/.ssh после аутентификации пользователя)
  • Subsystem имя-подсистемы команда параметр … (для sftp указать “Subsystem sftp /usr/local/openssh81/libexec/sftp-server”;
    команда internal-sftp – встроенный sftp сервер)
  • SyslogFacility AUTH (тип сообщений syslog: DAEMON, USER, AUTH, AUTHPRIV, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7)
  • TCPKeepAlive { yes | no } (раньше называлась KeepAlive; использовать возможности TCP keepalive для обнаружения проблем на другой стороне;
    отключение приведёт к образованию навечно зависших сессий; см. ClientAliveInterval для проверки по защищённому каналу)
  • TrustedUserCAKeys { none | имя-файла } (файл должен содержать публичные ключи CA, которым доверено подписывать упрощённые сертификаты пользователей –
    по одному ключу на строку; упрощённый сертификат должен иметь список пользователей (principals), которых им разрешено удостоверять)
  • UseDNS { no | yes } (раньше назывался ReverseMappingCheck; получать имя клиентского хоста по IP адресу и проверять, что имя хоста разрешается в тот же IP адрес;
    если установить no, то в authorized_keys и директивах sshd_config Match можно использовать только IP адреса)
  • UseLogin { no | yes } (использовать login для интерактивных сессий; для выполнения удаленных команд не используется в любом случае; удалён)
  • UsePAM { no | yes } (использовать PAM для аутентификации типа ChallengeResponseAuthentication и PasswordAuthentication,
    а также учёта и организации сессий для аутентификации любого типа; при включении нельзя будет запускать sshd без прав суперпользователя)
  • UsePrivilegeSeparation yes (после успешной аутентификации порождается отдельный
    процесс для обработки дальнейшего потока с правами пользователя; удалён, т.к. всегда используется)
  • VersionAddendum none (указанный текст добавляется к строке с номером протокола)
  • X11DisplayOffset 10 (первый доступный номер дисплея при пробросе X11; это умолчание пересекается с Xvnc)
  • X11Forwarding { no | yes } (пробрасывать X11; подвергает клиента дополнительному риску прослушивания (X11UseLocalhost блокирует это по умолчанию);
    пользователь всегда может установить собственный прокси)
  • X11UseLocalhost { yes | no } (при пробросе привязывать X11 сервер клиента к loopback и устанавливать переменную DISPLAY в “localhost:10”;
    старые программы так работать не могут – хотят реального адреса;
    если установить no, то при пробросе привязывать X11 сервер клиента ко всем адресам – к ним могут подключаться посторонние)
  • XAuthLocation адрес-xauth (/usr/X11R6/bin/xauth, /bin/xauth)
Похожее:  Идеальный корпоративный почтовый клиент / Habr

При указании интервалов времени можно использовать суффиксы 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 и ~/.ssh/known_hosts, /usr/local/openssh81/etc/shosts.equiv, ~/.shosts),
по публичному ключу, challenge-response, по паролю.
В качестве параметров указывается сервер и выполняемая команда.
Сервер может быть указан в форматах: имя-пользователя@сервер или ssh://[имя-пользователя@]имя-хоста[:порт].
В настройках клиента адрес, порт и имя пользователя могут быть переопределены по имени сервера.
Если команда не указана, то запускается командная оболочка (указывается в настройках пользователя на сервере).
Настройки сервера могут навязать исполняемую прграмму (forced-command).

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

  • “~~” – передача символа “тильда”
  • “~?” – help
  • “~.” – разорвать соединение
  • “~^Z” – перевести ssh в фоновый режим
  • “~#” – посмотреть список перенаправленнных соединений (шифрограммой!)
  • “~&” – перевести ssh в фоновый режим до завершения проброшенных TCP/IP и/или X11 соединений
  • “~B” – послать BREAK
  • “~C” – перейти в режим командной строки, позволяет добавить перенаправление
    порта (-L, -R, -D) или прекратить перенаправление (-KL, -KR, -KD), помощь (-h), !команда (выполнить команду на клиенте – реализовано?)
  • “~R” – запрос на смену ключа сессии
  • “~V” – уменьшить уровень отладочной печати
  • “~v” – увеличить уровень отладочной печати

Вместо тильды можно установить другой 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/config; при явном указании общий файл конфигурации (/usr/local/openssh81/etc/ssh_config) игнорируется
  • -f # перейти в фоновый режим после запроса пароля или парольной фразы и установления пробросов (см. ExitOnForwardFailure) перед выполнением команды;
    stdin назначается на /dev/null (фактически отключён ввод)
  • -G # разобрать и вывести конфигурацию для указанных параметров и опций; к серверу не соединяться и команду не выполнять
  • -g # разрешать другим хостам подсоединяться к локальным перенаправленным портам
  • -I библиотека # использовать разделяемую библиотеку для доступа к ключам в устройстве PKCS#11
  • -i имя-файла # файл, хранящий приватный ключ;
    по умолчанию – ~/.ssh/id_rsa и ~/.ssh/id_dsa и ~/.ssh/id_ecdsa и ~/.ssh/id_ed25519 и в старых версиях ~/.ssh/identity;
    можно использовать опцию несколько раз
  • -J список-хостов-подскока # использовать указанные хосты подскока (jump) по очереди (см. ProxyJump в настройках)
  • -K # использовать аутентификацию GSSAPI и передать (делегировать) кредиты GSSAPI серверу
  • -k # запретить передачу (делегированию) кредитов GSSAPI серверу
  • -L { [локальный-IP-адрес:]локальный-порт:удалённый-IP-адрес:удаленный-порт | [локальный-IP-адрес:]локальный-порт:удалённый-сокет |
    локальный-сокет:удалённый-IP-адрес:удаленный-порт | локальный-сокет:удалённый-сокет } #
    слушается указанный локальный порт или сокет и если происходит соединение на него, то пакеты пробрасываются по защищенному
    каналу на удаленный порт указанного хоста или удалённый сокет;
    настройки локального IP-адреса по умолчанию берутся из GatewayPorts;
    localhost – только локальные пользователи смогут подключаться;
    пусто или ‘*’ – порт будет доступен из сети;
    для перенаправления привилегированных портов надо иметь права суперпользователя;
    например, проброс VNC через X11 и без

    ssh -L 5902:localhost:5902 хост vncviewer localhost:2
    
    ssh -4 -f -L 5902:localhost:5902 хост sleep 180
    vncviewer localhost:2
    
  • -l имя-пользователя # на удалённом хосте
  • -M # данное соединение является управляющим при мультиплексировании
  • -m список-алгоритмов-обеспечения-целостности-соединения # алгоритм в начале списка имеет наибольший приоритет; см. MACs;
    по умолчанию: umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
  • -N # не выполнять удаленную команду – только пробросить порт
  • -n # stdin назначается на /dev/null (фактически отключён ввод); см. -f
  • -O { check | forward | cancel | exit | stop } # управление мультиплексированием
  • -o опция # см. описание файла конфигурации
  • -P # использовать непривилегированный порт для исходящего соединения,
    чтобы обойти ограничения сетевого экрана; несовместим с RhostsAuthentication
    и RhostsRSAAuthentication; удалён
  • -p порт # соединиться с указанным хостом на удаленном хосте; по умолчанию – 22
  • -Q тип-запроса # возможности реализации:
    • help
    • cipher – симметричные алгоритмы шифрования
    • cipher-auth – симметричные алгоритмы шифрования с аутентификацией
    • mac – алгоритмы хеширования
    • kex – алгоритмы обмена ключами
    • key – типы ключей
    • key-cert – типы ключей с сертификатами
    • key-plain – типы ключей без сертификатов
    • protocol-version – версии протокола SSH
    • sig – алгоритмы цифровой подписи
  • -q # меньше сообщений
  • -R { [удалённый-IP-адрес:]удалённый-порт:локальный-IP-адрес:локальный-порт | [удалённый-IP-адрес:]удалённый-порт:локальный-сокет |
    удалённый-сокет:локальный-IP-адрес:локальный-порт | удалённый-сокет:локальный-сокет | удалённый-IP-адрес:]удалённый-порт } #
    слушается указанный удалённый порт или сокет и если происходит соединение на него, то пакеты пробрасываются по защищенному
    каналу на локальный порт указанного хоста или локальный сокет;
    для перенаправления привилегированных портов надо иметь права суперпользователя;
    если локальный порт не указан, то ssh работает как сервер SOCKS по протоколу SOCKS4 или SOCKS5 для определения куда подключаться;
    настройки удалённого IP-адреса по умолчанию берутся из GatewayPorts;
    localhost – только локальные пользователи смогут подключаться;
    пусто или ‘*’ – порт будет доступен из сети;
    если в качестве удалённого порта указан 0, то порт выделяется динамически и сообщается клиенту
  • -S { none | имя-сокета } # имя сокета, управляющего мультиплексированиемм соединения; см. ControlPath и ControlMaster
  • -s # запуск подсистемы на сервере (например, sftp); имя подсистемы задается вместо имени команды
  • -T # не выделять псевдо-tty
  • -t # требовать выделения псевдо-tty; иногда требуется использовать ключ -t дважды)
  • -V # вывести номер версии и завершить работу
  • -v | -v -v | -v -v -v] # больше сообщений
  • -W имя-хоста:порт # пробросить stdin и stdout на указанный порт; подразумевает -N, -T, ExitOnForwardFailure, ClearAllForwardings
  • -w локальный-туннель[:удалённый-туннель] # пробросить туннель (интерфейс tun); можно указывать имя устройства или “any”
  • -X # пробросить X11; удалённый суперпользователь может эксплуатировать локальный X11 сервер (например, отслеживать ввод) – X11 SECURITY
  • -x # запретить перенаправление X11
  • -Y # пробросить X11; удалённый суперпользователь может эксплуатировать локальный X11 сервер (например, отслеживать ввод) – без X11 SECURITY
    (см. ForwardX11Trusted)
  • -y # посылать сообщения на syslog вместо stderr

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

  • Host шаблоны-через-пробел # следующие параметры применимы к хостам, подходящим под один из шаблонов;
    имя хоста берется из командной строки (т.е. неканоническое); в шаблонах используются символы ‘*’, ‘!’ и ‘?’)
  • Match критерии-через-пробел # следующие параметры применимы к вызовам, удовлетворяющим всем критериям, можно использовать отрицание (‘!’)
  • AddKeysToAgent {no | yes | ask | confirm } # при загрузке приватного ключа из файла и запроса парольной фразы добавить ключ к ssh-agent;
    ask – запросить пользователя, confirm – при каждом использовани ключа будет запрашиваться подтверждение
  • AddressFamily { any | inet | inet6 } # inet – это IPv4
  • BatchMode { no | yes } # не запрашивать пароль и парольную фразу
  • BindAddress исходящий-адрес
  • BindInterface исходящий-интерфейс
  • CanonicalDomains “” # список доменов через запятую, используется при канонизации имени хоста назначения
  • CanonicalizeFallbackLocal { yes | no } # при неудаче канонизации попробовать локальный список поиска (/etc/resolv.conf)
  • CanonicalizeHostname { no | yes | always} # канонизировать имя хоста назначения самостоятельно; always – в т.ч. имя прокси;
    после канонизации конфигурационный файл разбирается повторно
  • CanonicalizeMaxDots 1 # если в исходном имени больше точек, то канонизация не производится
  • CanonicalizePermittedCNAMEs правила-обработки-CNAME
  • CASignatureAlgorithms ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa #
    допустимые алгоритмы подписи сертификатов хостов
  • CertificateFile сертификат-пользователя # можно использовать ‘~’ и макросы; опцию можно использовать много раз – сертификаты опробуются по очереди
  • ChallengeResponseAuthentication { yes | no }
  • CheckHostIP { yes | no } # записывать IP адрес сервера в known_hosts и проверять его в дальнейшем
  • Cipher { 3des | blowfish } # алгоритмы шифрования для SSH1; удалено
  • 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”
  • ClearAllForwardings { no | yes } # сбросить все перенаправления портов, заданные -D, -L или -R или в конфигурационном файле; используется scp и sftp
  • Compression { no | yes }
  • CompressionLevel уровень-сжатия # только для SSH1: как в gzip/zlib – от 1/быстрый до 9/лучший; по умолчанию – 6; удалено (не до конца)
  • ConnectionAttempts 1 # число попыток соединения; раз в секунду
  • ConnectTimeout секунд # по умолчанию задаётся правилами TCP
  • ControlMaster { no | yes | ask | auto |autoask } # yes – слушать управляющий сокет ControlPath и
    позволять дополнительным сессиям использовать то же соединение,
    если у них выставлено “no”; ask – запрашивать через SSH_ASKPASS;
    auto – если сокет неработоспособен, то соединяться без мультиплекстрования
  • ControlPath { none | имя-сокета } # можно использовать макросы
  • ControlPersist { no | yes | секунд } # управляющее соединение мультиплексирование уходит в фоновый режим
    и ждёт вечно (yes или 0; выход по “ssh -O exit”) или простаивает указанное количество секунд
  • DynamicForward IP-адрес:]локальный-порт # слушается указанный локальный порт;
    настройки IP-адреса по умолчанию берутся из GatewayPorts;
    localhost – только локальные пользователи смогут подключаться;
    пусто или ‘*’ – порт будет доступен из сети;
    приходящее на него соединение пробрасывается по защищенному каналу;
    при этом ssh работает как сервер SOCKS по протоколу SOCKS4 или SOCKS5 для определения куда подключаться на удалённом конце;
    привилегированные порты может перенаправлять только суперпользователь;
    опция может быть использована несколько раз
  • EnableSSHKeysign { no | yes } только в общей секции общесистемных настроек (/etc/ssh/ssh_config, /usr/local/openssh81/etc/ssh_config);
    использовать ssh-keysign для аутентификации по HostbasedAuthentication)
  • EscapeChar { символ | ^символ | none } # символ для использования вместо тильды; none – прозрачный режим
  • ExitOnForwardFailure { no | yes } # прерывать соединение, если не удалось установить все локальные, удалённые, динамические пробросы
  • FingerprintHash {sha256 | md5} … # какой MAC использовать при выводе отпечатков
  • FallBackToRsh { no | yes } # использовать rsh, если сервер не имеет ssh; удалена
  • ForwardAgent { no | yes } # пробрасывать ли соединение к агенту аутентификации на удаленный хост;
    не рекомендуется перенаправлять соединение на хост, где злоумышленник имеет достаточно прав для к сокету Unix-domain –
    через него он сможет получить доступ к локальному агенту достаточного уровня,
    чтобы аутентифицироваться с его ключевым материалом (сами ключи он извлечь не сможет)
  • ForwardX11 { no | yes } # пробросить X11; не рекомендуется включать при входе на компьютеры,
    где кто-то кроме вас имеет права суперпользователя;
    злоумышленник, имеющий возможность манипулировать базой данных авторизации X11 сервера сможет воспользоваться вашим сервером X11;
    может читать данные других недоверенных клиентов X11 сервера (экран, ввод) и даже доверенных клиентов, если включено ForwardX11Trusted
  • ForwardX11Timeout 20m # недоверенные соединения (см. ForwardX11Trusted) будут отвергаться через указанное время
  • ForwardX11Trusted { no | yes } #
    удалённые клиенты X11 сервера считаются доверенными (могут читать изображения других доверенных клиентов и отслеживать события ввода);
    более того – токены xauth протухнут через указанное в ForwardX11Trusted время (требуется версия 6.9 или новее);
    не все программы соглашаются работать в недоверенном режиме (например, хотят получить информацию о темах);
    см. X11 SECURITY extension
  • GatewayPorts { no | yes } # разрешать ли другим хостам соединяться на проброшенные локальные порты или привязывать их к loopback
  • GlobalKnownHostsFile имя-файла … # общесистемное хранилище публичных ключей хостов, по умолчанию /etc/ssh/ssh_known_hosts и /etc/ssh/ssh_known_hosts2
  • GSSAPIAuthentication { no | yes} # использовать аутентификацию GSSAPI
  • GSSAPIDelegateCredentials { no | yes } # передать (делегировать) кредиты GSSAPI серверу
  • HashKnownHosts { no | yes } # хешировать имена и адреса хостов при добавлении в список публичных ключей хостов;
    имеющиеся записи не преобразуются
  • HostbasedAuthentication { no | yes }
  • HostbasedKeyTypes список-шаблонов-форматов-ключей-через-запятую #
    форматы (алгоритмы) ключей для аутентификации клиента типа hostbased;
    полный список форматов, используемых при аутентификации hostbased можно посмотреть по “ssh -Q key”;
    список можно заменять, дополнять в начало (‘^’), дополнять в конец ‘( ‘) и удалять из списка ‘-‘
  • HostKeyAlgorithms список-шаблонов-форматов-ключей-через-запятую #
    форматы (алгоритмы) ключей для аутентификации хостов;
    полный список форматов, используемых при аутентификации [jcnjd можно посмотреть по “ssh -Q key”;
    список можно заменять, дополнять в начало (‘^’), дополнять в конец ‘( ‘) и удалять из списка ‘-‘
  • HostKeyAlias имя # использовать вместо имени хоста при работе с публичными ключами хоста;
    при туннелировании (NAT) или когда используется несколько серверов на одном хосте
  • HostName имя-хоста | IP-адрес # настоящее имя хоста, на который надо зайти; можно использовать макросы;
    по умолчанию берётся из командной строки
  • IdentitiesOnly # { no | yes } # не использовать ключи от агента аутентификации
  • IdentityAgent { SSH_AUTH_SOCK | имя-сокета | none } # имя сокета для связи с агентом;
    по умолчанию берётся из переменной окружения SSH_AUTH_SOCK;
    если имя начинается с ‘$’, то дальше идёт имя переменной окружения, содержащей имя сокета;
    можно использовать макросы
  • IdentityFile имя-файла # по умолчанию: ~/.ssh/id_dsa,~/.ssh/id_ecdsa,~/.ssh/id_ed25519,~/.ssh/id_rsa;
    файл, хранящий приватный ключ; может быть несколько; используются также ключи от агента аутентификации;
    можно использовать макросы; для получения имёни файла с сертификаторами в конец имени файла добавляется -cert.pub
  • IgnoreUnknown список-шаблонов # список игнорируемых опций настройки; использовать до использования игнорируемых опций
  • Include имя-файла … # содержимое указанных файлов обрабатывается как часть настроек; можно использовать шаблоны;
    при использовании относительных имён файлы ищутся в ~/.ssh или /etc/ssh
  • IPQoS af21,cs1 #
    уровень сервиса для интерактивных и неинтерактивных сессий: lowdelay, throughput, reliability, none и др.;
    none – системные настройки; af21 – низкие задержки; cs1 – наименьшие усилия
  • KbdInteractiveAuthentication { yes | no }
  • KbdInteractiveDevices список-методов # pam или bsdauth
  • KeepAlive { yes | no } # позволяет заметить разрыв связи или аварийное завершение на дальнем конце; опция переименована в TCPKeepAlive
  • KerberosAuthentication { yes | no } # опция удалена
  • KerberosTgtPassing { yes | no } # опция удалена
  • KexAlgorithms curve25519-sha256,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1 #
    список алгоритмов обмена ключами; полный список можно посмотреть по “ssh -Q kex”;
    список можно заменять, дополнять в начало (‘^’), дополнять в конец ‘( ‘) и удалять из списка (‘-‘)
  • LocalCommand команда … # указанная команда с аргументами выполняется после соединения на клиенте от имени пользователя и с его оболочкой;
    см. PermitLocalCommand; не может быть интерактивной; в описании можно использовать макросы
  • LocalForward [локальный-IP-адрес:]локальный-порт удалённый-IP-адрес:удаленный-порт #
    слушается указанный локальный порт или сокет (?) и если происходит соединение на него, то пакеты пробрасываются по защищенному
    каналу на удаленный порт указанного хоста или удалённый сокет (?);
    настройки локального IP-адреса по умолчанию берутся из GatewayPorts;
    localhost – только локальные пользователи смогут подключаться;
    пусто или ‘*’ – порт будет доступен из сети;
    для перенаправления привилегированных портов надо иметь права суперпользователя;
    может быть несколько
  • LogLevel { INFO | QUIET | FATAL | ERROR | INFO | VERBOSE | DEBUG[ 1 | 2 | 3] } # DEBUG нарушает приватность пользователей
  • MACs umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-256-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
    # список алгоритмов обеспечения целостности соединения (MAC, message authentication code); алгоритм в начале списка имеет наибольший приоритет;
    список можно заменять, дополнять в начало (‘^’), дополнять в конец ‘( ‘) и удалять из списка (‘-‘);
    полный список алгоритмов MAC можно посмотреть по “ssh -Q mac”;
    etm – это MAC после шифрования, авторы OpenSSH считают это более надёжным
  • NoHostAuthenticationForLocalhost { no | yes } # запретить аутентификацию по хосту для локального хоста (localhost)
  • NumberOfPasswordPrompts 3
  • PasswordAuthentication {yes | no}
  • PermitLocalCommand {no | yes} # разрешить выполнение на клиенте команды, указанной в LocalCommand или в !команда после ~C (реализовано?)
  • PKCS11Provider {none | путь} # путь к модулю, работающему с токенами PKCS11
  • Port 22
  • PreferredAuthentications gssapi-with-mic,hostbased,publickey,keyboard-interactive,password # приоритет методов аутентификации клиента
  • Protocol список-версий-протокола-в-порядке-предпочтения # 2,1; удалена
  • ProxyCommand { none | программа … } # позволяет использовать программу для соединения с сервером;
    можно использовать макросы, например %h заменяется на имя хоста, %p заменяется на номер порта;
    используется команда exec оболочки;
    например, для использования HTTP прокси можно использовать nc

    ProxyCommand /usr/bin/nc -X connect -x 192.0.2.0:8080 %h %p # --proxy-type http --proxy 192.0.2.0:8080
    
  • ProxyJump
  • ProxyUseFdpass
  • PubkeyAcceptedKeyTypes
  • PubkeyAuthentication yes | no (SSH2)
  • RekeyLimit
  • RemoteCommand
  • RemoteForward порт хост:порт (см. -R; может быть несколько)
  • RequestTTY
  • RevokedHostKeys
  • RhostsAuthentication yes | no (SSH1; опция удалена)
  • RhostsRSAAuthentication no | yes (SSH1; опция удалена)
  • RSAAuthentication yes | no (SSH1; опция удалена)
  • SendEnv список-переменых-окружения-через-пробел (значения каких переменных
    окружения передавать; по умолчанию – не передавать ничего)
  • ServerAliveCountMax 3 (после какого числа неудачных проверок разрывать
    соединение; не подделывается в отличие от TCPKeepAlive)
  • ServerAliveInterval секунд (0; через какое время бездействия проверять связь)
  • SkeyAuthentication no | yes # переименован в ChallengeResponseAuthentication
  • SmartcardDevice # удалена
  • StreamLocalBindMask
  • StreamLocalBindUnlink
  • StrictHostKeyChecking ask | no | yes (не добавлять незнакомые или
    изменившиеся хосты в know_hosts)
  • SyslogFacility
  • TCPKeepAlive yes | no (проверять иногда есть ли ответ от сервера; см. лучше
    ServerAliveInterval)
  • Tunnel
  • TunnelDevice
  • UpdateHostKeys
  • UsePrivilegedPort no | yes # удалена (-P)
  • User имя-пользователя
  • UserKnownHostsFile файл-known_hosts
  • UseRsh no | yes (опция удалена; если ssh на хосте нет вовсе)
  • VerifyHostKeyDNS no | yes | ask (использовать DNS (SSHFP) для проверки ключа удалённого хоста)
  • VisualHostKey
  • XAuthLocation расположение-xauth
Похожее:  PyCharm Integration with GitHub. Setting up Version Management for… | by Akshay Sinha | Medium

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

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

Опции ssh-add:

  • имя файла с приватным ключом (по-умолчанию – ~/.ssh/identity)
  • -l (выдать fingerprint приватных ключей, хранящихся в ssh-add)
  • -L (выдать публичные ключи, хранящиеся в ssh-add)
  • -d (удалить указанный приватный ключ)
  • -D (удалить все ключи)
  • -x (заблокировать агента с указанием пароля)
  • -X (разблокировать агента)
  • -t максимальное-время-хранения (в секундах)
  • -c (требовать подтверждения при каждом использовании ключа)

Таким образом можно вставить
в .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

Текст 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
    
  4. обеспечение запуска “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″
  5. собираем все ssh_host_dsa_key.pub, формируем из них /usr/local/etc/ssh_known_hosts (/etc/ssh/ssh_known_hosts) и копируем на все хосты
  6. открыть дырки в сетевых экранах для TCP/22
  7. чтобы PAM в RedHat был счастлив – скопировать /etc/pam.d/login в
    /etc/pam.d/sshd (убрать nullok, тем более что начиная с RH 7.0 его нет), см. также
    contrib/
  8. общая настройка новых клиентов (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
      
  9. добавления в настройки конкретных соединений (до “Host *”!) или
    в ~/.ssh/config

      Host удалённый-хост-с-медленным-каналом
        Compression yes
      Host хост-где-у-меня-другое-имя
        User имя
      Host где-точно-есть-ключ-входа
        PasswordAuthentication no
        PreferredAuthentications publickey
      Host где-никого-кроме-меня-нет
        ForwardAgent yes
        ForwardX11 yes
      
  10. дополнительная настройка старых клиентов /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
  11. настройка для интерактивной работы. Т.к. в этом режиме
    возможно выполнение любых команд, то вход на другой хост без запроса пароля
    нежелателен, иначе взлом одного хоста автоматически ведет к взлому всех
    остальных. Но и вводить пароль каждый раз утомительно.

    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”
  12. Выполнение удаленных команд в пакетном режиме (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/обозначение-командывторой-хост
  13. избавиться от всех telnet, ftp и rsh

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

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

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

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

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

  • bye
  • cd путь
  • lcd путь
  • chgrp gid имя-файла
  • chmod mode имя-файла
  • chown uid имя-файла
  • exit
  • get [-P] имя-удаленного-файла [имя-локального-файла] (ключ -P позволяет
    сохранить права и времена)
  • help
  • lls [опции-ls [имя-файла]]
  • lmkdir имя-файла
  • ln старое-имя новое-имя
  • lpwd
  • ls [имя-файла]
  • lumask umask
  • mkdir имя-файла
  • put [-P] имя-локального-файла [имя-удаленного-файла] (ключ -P позволяет
    сохранить права и времена)
  • pwd
  • quit
  • rename старое-имя новое-имя
  • rmdir имя-файла
  • rm имя-файла
  • symlink старое-имя новое-имя
  • ! команда-shell
  • ! (выход в shell)
  • ?

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

  • -c алгоритм-шифрования (передается ssh)
  • -i имя-файла (файл с приватным ключом, передается в ssh)
  • -o опция (передается ssh)
  • -p (сохраняет время модификации, использования и права доступа)
  • -r (рекурсивно копировать всю директорию)
  • -v
  • -B (пакетный режим – не запрашивать пароль или парольную фразу)
  • -q
  • -C (сжатие)
  • -F конфигурационный-файл
  • -P port (задает порт сервера, стало быть ключа непривилегированных портов нет?)
  • -S программа (использовать вместо ssh)
  • -4 (IPv4)
  • -6 (IPv6)

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

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

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

  • Отличия 2.3.0p1 от 2.2.0p1:
    • SFTP-сервер (Subsystem sftp /usr/local/libexec/sftp-server в sshd_config)
    • scp -o (передача опций в ssh)
    • алгоритм шифрования rijndael/aes
  • Отличия 2.5.1p2 от 2.3.0p1:
    • заработал ForwardAgent для SSH2 (ключ -R)
    • добавлена поддержка RSA в SSH2 (патент истек)
    • ssh-keyscan
    • HostKeyAlias для ssh (позволяет запустить несколько sshd на одном хосте)
    • переименованы приоритеты для syslog (ERR в CRIT)
    • ssh -s (sftp)
    • клиент sftp
    • ssh -m (или ключа MAC в ssh[d]_config – алгоритмы обеспечения целостности сессии
    • добавлены алгоритмы hmac-md5-96 и hmac-sha1-96)
    • sshd_config не совместим с предыдущей версией (добавить HostKey, убрать DSAAuthentication, HostDSAKey)
    • убрать DSAAuthentication из конфигурации клиента
  • Отличия 2.5.2p1 от 2.5.1p2:
    • удален make-ssh-known-hosts.pl (используйте ssh-keyscan)
    • ssh -i поддерживает DSA
    • пакетный режим sftp
    • aes128-cbc/hmac-md5 по умолчанию для SSH2 (быстрее)
    • шаблоны имен в sftp; опция PreferredAuthentications для клиента
  • Отличия 2.9p1 от 2.5.2p1:
    • SSH2 по умолчанию
    • использование ssh в качестве SOCKS4 (ssh -D локальный-порт)
    • session rekeying (смена ключа сессии через определенные интервалы)
    • опции ClientAliveInterval и ClientAliveCountMax
    • HostKeyAlgorithms
  • Отличия 2.9p2 от 2.9p1 (20010617):
    • добавили ключ -b для ssh (задание ip-адреса клиента)
    • добавили возможность задавать имя файлов вместо authorized_keys и authorized_keys2 (опция AuthorizedKeysFile в sshd_config)
    • заделана дырка с /tmp
  • Отличия 2.9.9p2 от 2.9p2 (20010925):
    • вместо /etc/primes используется /etc/moduli
    • слиты authorized_keys и authorized_keys2
    • слиты known_hosts и known_hosts2
    • закрыта дырка с удалением pid-файла
    • приоритеты методов аутентификации: hostbased, publickey, keyboard-interactive, password
    • ключ -t в sshd (проверка конфигурационных файлов и ключей)
    • добавлена поддержка SSH2 в ssh-keyscan
    • убран CheckMail
    • ключ -F команд ssh/scp/sftp позволяет задать конфигурационный файл
    • ключ -D и опция DynamicForward для ssh
    • ключи -1, -s и -S для sftp
    • опция ClearAllForwardings для ssh (для scp и sftp включена всегда)
  • Отличия 3.0.1p1 от 2.9.9p2 (20011115):
    • опция NoHostAuthenticationForLocalhost для ssh
    • ключи -4 и -6 для ssh-keyscan
  • Отличия 3.0.2p1 от 3.0.1p1 (20011201): заделана дырка с UseLogin
  • Отличия 3.2.3p1 от 3.0.2p1 (20020522):
  • Отличия 3.6.1p2 от 3.2.3p1.
  • Отличия 3.9p1 от 3.6.1p2.
    • Убрана аутентификация Rhosts
    • Поддержка SOCKS5
    • Опция UseDNS вместо VerifyReverseMapping для sshd
    • Поддержка tty BREAK
    • Опция AddressFamily для ssh (IP4, IP6)
    • Использование aes128-ctr, aes192-ctr, aes256-ctr
    • Опция UsePAM
    • Запрещение доступа к заблокированным учётным записям
    • Возможность менять пароли с истекшим сроком действия
    • При пробросе X11 теперь используются untrusted cookies (опция ForwardX11Trusted для ssh)
    • Опция ServerAliveInterval для ssh
    • Опция KerberosGetAFSToken для sshd
    • Ключи хостов могут браться из DNS (draft-ietf-secsh-dns-xx.txt, README.dns)
    • Опция IdentitiesOnly для ssh (использовать ключи только из ssh_config, не от openssh-agent
    • Передача избранных переменных окружения: AcceptEnv для sshd и SendEnv для ssh
    • Опция MaxAuthTries для sshd (максимальное число попыток аутентификации)
    • Прерывание сессии port forward по нажатию “~C”
    • Мультиплексирование нескольких сессий в одном соединении (опции ControlMaster и ControlPath)
  • Отличия 4.2p1 от 3.9p1.
    • Возможность привязки передаваемого порта к определённому адресу (ключи -L и -R
      и опции LocalForward и RemoteForward ssh_config, опция GatewayPorts sshd_config)
    • Опция HashKnownHosts позволяет сохранять в known_hosts хеши вместо имён хостов (приватность),
      у ssh-keygen появились функции поиска в known_hosts с хешами
    • sshd предупреждает при истечении времени действия учётной записи и пароля
    • Опция AddressFamily (IP4/IP6) для sshd_config
    • Значение delayed опции Compression для sshd_config
    • Размер создаваемых ключей по умолчанию равен 2048 бит
    • Улучшения в мультиплексировании соединения (ControlMaster=auto/autoask, ControlPath=none)
  • Отличия 4.3p2 (RHEL/CentOS 5) от 4.2p1:
    • VPN с использованием виртуального интерфейса tun
    • DSA урезан до 1024 бита (так в стандарте FIPS 186-2!)
  • Отличия 5.3p1 (RHEL/CentOS 6) от 4.3p2:
    • условные (пользователь, группа, хост, адрес – шаблон и маска) настройки с помощью директивы Match:
      методы аутентификации, PermitRootLogin, Banner=none, MaxAuthTries, PermitEmptyPasswords, AllowAgentForwarding
    • DH с использованием SHA256
    • Директива ForceCommand для Match (аналог ~/.ssh/authorized_keys, не выполняется ~/.ssh/rc, no-user-rc)
    • Директива PermitOpen (аналог permitopen= для ~/.ssh/authorized_keys)
    • Журнал для sftp
    • Опция ExitOnForwardFailure для ssh
    • Директива SubSystem позволяет задавать ключи
    • Поддержка SELinux (–with-selinux)
    • Поддержка аппаратных ускорителей (–with-ssl-engine)
    • Размер окна увеличен и растёт более агрессивно
    • Добавлен UMAC-64
    • Директива ChrootDirectory
    • Встроенная реализация SFTP (internal-sftp, для chroot)
    • Визуализация отпечатка ключа (VisualHostKey)
    • Тестирование настройки sshd (-T, позволяет проверить Match, выводит настройки)
    • Команда df для sftp клиента
    • Директива MaxSessions ограничивает число мультиплексируемых соединений (раньше было 10; 1 – без мультиплексирования;
      0 – без login/shell/subsystem)
    • ssh-keyscan по умолчанию теперь выдаёт RSA2 вместо RSA1
    • Директива AllowAgentForwarding (клиент может подставить свой)
    • Предпочтение отдаётся алгоритмам шифрования CTR
    • Ключ “ssh -y” переносит вывод с stderr на syslog
    • С помощью последовательности ~C можно создавать динамическое перенаправление портов
    • Поддержка SOCKS4A при динамическом перенаправлении портов
    • Можно указать 0 при перенаправлении удалённого порта, сервер сам выберет порт и сообщит его номер
  • Отличия 6.6p1 (RHEL/CentOS 7 до 7.3, отзывается как 6.6.1p1) от 5.3p1:
    • по умолчанию отключён SSH1
    • libsectok (OpenSC) заменён на поддержку PKCS#11
    • Поддержка самодельных “сертификатов” для проверки публичных ключей (TrustedUserCAKeys, authorized_keys, known_hosts), в т.ч. при аутентификации по хосту
    • Режим netcat: “ssh -W хост:порт …”
    • Отзыв ключей (RevokedKeys, known_hosts)
    • SFTP может работать только на чтение
    • umask в SFTP
    • Клиент SFTP стал краше
    • Контекст SELinux для SFTP – sftpd_t
    • Изменена генерация ключей RSA
    • Приватные ключи шифруются AES-128 вместо 3DES
    • Запрет на OOM-Killer для sshd
    • Директива ControlPersist настройки ssh (запуск мастера мультиплексирования при входе)
    • Макро %h расширяется в имя хоста в настройках ssh
    • ssh-keygen может экспортировать и импортировать в форматах PEM и PKCS#8
    • AuthorizedPrincipalsFile позволяет задать (можно none) соответствия имён в сертификатах и настоящих (principals=”имя,…” в ~/.ssh/authorized_keys)
    • В Match можно использовать: AuthorizedKeysFile, AuthorizedPrincipalsFile, HostbasedUsesNameFromPacketOnly, PermitTunnel, LocalAddress, LocalPort,
      AcceptEnv, {Allow,Deny}{Users,Groups}
    • Реализация ECDH/ECDSA (сразу сделали предпочтительными), включая “сертификаты” и отпечатки в DNS
    • Создание жёстких ссылок в SFTP (ln)
    • Опция “-3” для scp: копирование между удалёнными хостами через локальный хост (по умолчанию – напрямую)
    • Директива IPQoS для sshd и ssh позволяет задать биты TOS/DSCP/QoS
    • Директива KexAlgorithms для sshd и ssh позволяет задть алгоритмы обмена ключами и предпочтения
    • Новый режим песочницы UsePrivilegeSeparation=sandbox (ограничения на системные вызовы до аутентификации реализуется с помощью
      systrace или seatbelt или rlimit (0 процессов, 0 fd) или seccomp (Linux))
    • Новые MAC: hmac-sha2-256, hmac-sha2-512
    • AuthorizedKeysFile, UserKnownHostsFile, GlobalKnownHostsFile позволяет задать несколько файлов через пробел
      (устарели AuthorizedKeysFile2, UserKnownHostsFile2, GlobalKnownHostsFile2)
    • Опция RequestTTY настройки ssh
    • Ключ “-A” для ssh-keygen – генерация недостающих ключей хоста с параметрами по умолчанию
    • Аккуратное отключение при использовании мультиплексирования: “ssh -O stop”. ssh-add принимает ключи со стандартного ввода (ключ “-“)
    • Удалён ssh-rand-helper
    • Опция “-k” в ssh-add позволяет загрузить ключи, игнорируя “сертификаты”
    • В PermitOpen (разрешение перенаправления) можно использовать шаблоны и none
    • Можно закрыть передачу локального и удалённого портов через мультиплексирование (“ssh -O cancel -L xx:xx:xx -R yy:yy:yy user@host”) или “~C”
    • Директива VersionAddendum позволяет вывести текст перед стандартным приветствием
    • Реализация AES-GCM (aes128-gcm@openssh.com, aes256-gcm@openssh.com), немного нестандартная
    • Реализация режима EtM (encrypt-then-mac, hmac-sha2-256-etm@openssh.com и др., MAC не от исходного текста, а от зашифрованного) – по умолчанию
    • AuthenticationMethods позволяет задать обязательную последовательность методов ауентификации
    • Директива RevokedKeys позволяет указывать RKL (Key Revocation Lists, создаётся с помощью ssh-keygen)
    • IdentitiesOnly (IdentityFile?)
    • В AllowTcpForwarding можно задавать local и remote в дополнение к yes и no
    • AuthorizedKeysCommand и AuthorizedKeysCommandUser позволяют задать команду, результат выполнения которой используется как authorized_keys
    • Опция “-d” команды sftp-server позволяет задать начальный каталог
    • Последовательности ~v и ~V позволяют поднять и опустить уровень журналирования
    • поддержка ssh-agent для sshd (позволяет использовать зашифрованные ключи сервера)
    • RekeyLimit для ssh и sshd, возможность задать интервал времени
    • возможность получить список поддерживаемых алгоритмов (“ssh -Q тип”)
    • ProxyCommand=-
    • IdentityFile=none
    • опция “-E” позволяет добавить отладочную печать к файлу вместо syslog или stderr
    • sftp поддерживает возобновление чтения файла (reget или “get -a”)
    • IgnoreUnknown позволяет игнорировать неизвестные директивы
    • поддержка Curve25519, Ed25519
    • новый формат шифрования приватных ключей в стиле bcrypt KDF
    • поддержка шифрования chacha20-poly1305@openssh.com (ChaCha20 и Poly1305)
    • больше не соединяется с клиентами и серверами с ключами в формате RSA MD5
    • опция Match настройки ssh позволяет условную настройку по имени хоста, имени пользователя и результату выполнения программы
    • ssh канонизирует имя хоста
    • директива PermitTTY (аналог no-pty)
    • опция ProxyUseFDPass позволяет передать дескриптор файла ssh и завершить программу ProxyCommand
  • Отличия 7.4p1 (RHEL/CentOS 7 от 7.4) от 6.6p1:
    • изменён список алгоритмов по умолчанию, в частности отключены алгоритмы cbc
    • удалена поддержка tcpwrappers
    • требуется openssl 0.9.8f и выше
    • можно перенаправлять сокеты (в обе стороны)
    • SSHFP DNS ED25519
    • sftp поддерживает возобновление записи файла
    • PermitUserRC позволяет контролировать выполнение ~/.ssh/rc
    • по умолчанию UseDNS выключен
    • добавлена директива FingerprintHash, по умолчанию SHA256 и base64 (было MD5 и hex)
    • опция UpdateHostkeys для ssh позволяет узнать все ключи сервера при первом подключении
    • опция HostbasedKeyType для ssh
    • AuthenticationMethods=publickey,publickey – пользователь должен предъявить 2 ключа
    • директивы HostbasedAcceptedKeyTypes и PubkeyAcceptedKeyTypes
    • опция RevokedHostKeys для ssh
    • опция ssh “Match canonical” как Match, но после канонизации имени хоста
    • “ssh -G” – разбор конфигурации
    • отрицательные шаблоны для Match
    • опция сборки –without-openssl
    • опция сборки –without-ssh1
    • по умолчанию “PermitRootLogin prohibit-password” (prohibit-password как синоним without-password)
    • сборка по умолчанию без SSH1
    • по умолчанию отключёны diffie-hellman-group1-sha1, ssh-dss, ssh-dss-cert-*
    • по умолчанию отключены blowfish-cbc, cast128-cbc, arcfour
    • по умолчанию отключены HMAC с использованием md5
    • минимальный размер модуля для diffie-hellman-group-exchange поднят до 2048
    • аргументы для AuthorizedKeysCommand
    • директива AuthorizedPrincipalsCommand позволяют задать команду, результат выполнения которой используется как имя пользователя (principal)
    • поддержка устройств PKCS#11 с внешним вводом PIN
    • директива GSSAPIStrictAcceptorCheck
    • опция ssh PubkeyAcceptedKeyTypes
    • директива HostKeyAlgorithms
    • можно добавлять в список по умолчанию новые алгоритмы и пр. ( перед списком) в директивах sshd и опциях ssh:
      Ciphers, MACs, KexAlgorithms, HostKeyAlgorithms, PubkeyAcceptedKeyTypes, HostbasedKeyTypes
    • до 7.1.p2 необходимо использовать ssh опцию “UseRoaming no”, чтобы избежать утечки приватных ключей к злому серверу
    • добавлены алгоритмы RSA с SHA-256/512
    • опция AddKeysToAgent (по умолчанию no) позволяет добавить ключ к ssh-agent при использовании (yes, ask, confirm)
    • опция restrict в authorized_keys позволяет добавить все нынешние и будущие запреты (no-*), добавлены позитивные опции типа pty
    • опция ssh CertificateFile
    • аргумент none для Foreground и ChrootDirectory (для Match)
    • чтение сертификатов: “ssh-keyscan -c”
    • удаление завершающей точки при канонизации имён хостов
    • опция ProxyJump и ключ “-J” для ssh для прыжков через промежуточный ssh сервер
    • опция IdentityAgent для ssh позволяет указать сокет ssh-agent вместо использования переменной окружения
    • опции ssh ExitOnForwardFailure и ClearAllForwardings могут быть перекрыты ключом “-W”
    • поддержка терминального режима IUTF8
    • поддержка длинных DH групп (gss-group15-sha512-* и т.д.?)
    • опция Include для ssh
    • нельзя включить поддержку SSH1 на сервере
    • по умолчанию клиент не предлагает 3des-cbc
    • на сервере удалена возможность сжатия до аутентификации
    • ssh-agent загружает модули PKCS#11 только из белого списка каталогов
    • удалена директива UseLogin
    • “ssh -O proxy …”
    • директива DisableForwarding запрещает перенаправление X11, ssh-agent, TCP, tunnel, Unix domain socket и любых новых видов
    • curve25519-sha256 как синоним curve25519-sha256@libssh.org
    • в Match можно использовать: ClientAliveInterval, ClientAliveCountMax
    • gnome-ssh-askpass3 для GTK 3 (отсутствует в пакете)
  • Отличия 7.8p1 (RHEL/CentOS 8) от 7.4p1:
    • не принимаются ключи RSA короче 1024
    • окончательное отключение (удаление кода) SSH1
    • удаление кода Blowfish, CAST, arcfour (RC4), HMAC RIPE-MD160
    • ожидается отказ без режима разделения привилегий (UsePrivilegeSeparation)
    • отказ от поддержки OpenSSL ниже 1.0.1
    • удаление алгоритмов из списка (“-” перед удаляемым списком): Ciphers, MACs, KexAlgorithms, HostKeyAlgorithms, PubkeyAcceptedKeyTypes, HostbasedKeyTypes
    • алгоритмы cbc не предлагаются клиентом по умолчанию
    • ssh опция RemoteCommand
    • директива ExposeAuthInfo позволяет передавать информацию (публичный ключ) в переменную окружения SSH_USER_AUTH
    • ssh поддерживает обратное динамическое перенаправление (используется удалённым клиентом SOCKS)
    • в Match можно использовать: LogLevel
    • ssh-keygen может использовать содержащийся в ssh-agent ключ для подписи сертификатов
    • IPQoS=none
    • “ssh-add -q” – без сообщений
    • опция ssh StrictHostKeyChecking может иметь значения: accept-new (принимать невиданные ключи, но отвергать противоречащие сохранённым),
      off (принимать невиданные ключи и противоречащие сохранённым); в дальнейшем, no будет действовать как accept-new
    • ssh опция SyslogFacility
    • шифрование приватных ключей с помощью aes256-ctr вместо aes256-cbc
    • условная конфигурация Match rdomain (домен маршрутизации), ListenAddress rdomain
    • задание срока годности ключей – expiry-time в authorized_keys
    • ssh опция BindInterface в дополнение к BindAddress
    • использование URI: sftp://user@host/path
    • вывод в формате SSHFP: “ssh-keyscan -D”
    • в сессии scp отключены RemoteCommand и RequestTTY
    • ssh-keygen пишет приватные ключи в формате OpenSSH вместо OpenSSL PEM (для PEM используйте ключ “-m PEM”)
    • ~/.ssh/environment и environment= в authorized_keys больше не перекрывают значения переменных SSH_*
    • изменены значения по умолчанию для IPQoS
    • алгоритмы rsa-sha2-256-cert-v01@openssh.com и rsa-sha2-512-cert-v01@openssh.com
    • с помощью директивы PermitUserEnvironment можно разрещать список переменных, а не только yes и no
    • директива PermitListen и опция permitlisten= в authorized_keys для указания разрешённых адресов и портов при передаче (ssh -R)
    • директива SetEnv в sshd и ssh для прямой установки значения переменной
    • возможность очистки переменных окружения (SendEnv -шаблон)
    • ProxyJump=none
  • Отличия 8.0p1 от 7.8p1 (RHEL/CentOS 8.1):
    • можно использовать имена портов вместо номеров (/etc/services)
    • в опции ssh IdentityAgent можно использовать переменные окружения
    • запрос возможностей: “ssh -Q sig” и “ssh -Q help”
    • директива sshd и ssh CASignatureAlgorithms
    • клиент scp не проверял имя возвращаемого файла (на шаблоны (wildcard) расширяются на стороне сервера,
      что может вызывать чрезмерную фильтрацию, “-T” для её отключения)
    • из ListenAddress и PermitOpen удалён синтаксис вида “хост/порт” (используйте “хост:порт”)
    • по умолчанию ключ RSA длиной 3072 бит
    • PKCS11Provider=none
    • при запросе на подтверждение ключа хоста вместо yes можно ввести отпечаток ключа
    • опция -J (ProxyJump) для scp и sftp
    • тестирование ключей в ssh-agent (ssh-add -T)
    • “Match final” почти “Match canonical”, но не требует включения канонизации
  • Отличия 8.1p1 от 8.0p1:
    • по умолчанию сертификаты подписываются rsa-sha2-512 (для совместимости с OpenSSH 7.2 надо использовать “ssh-keygen -t ssh-rsa -s …”)
    • добавление алгоритма в начало списка (“^” перед списком): Ciphers, MACs, KexAlgorithms, HostKeyAlgorithms, PubkeyAcceptedKeyTypes, HostbasedKeyTypes
    • приватные ключи можно хранить в формате PKCS8 (по умолчанию по прежнему в формате OpenSSH)
    • ssh-keyscan опрашивает сервера без ssh-rsa (с SHA1)


Copyright © 1996-2022 Sergey E. Bogomolov; www.bog.pp.ru
(КГБ знает все, даже то что у Вас на диске 😉

1 Звезда2 Звезды3 Звезды4 Звезды5 Звезд (1 оценок, среднее: 4,00 из 5)
Загрузка...

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

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Adblock
detector