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

SSH обеспечивает возможность удаленного выполнения команд (вместо telnet, rsh и всего, что над ним построено - rsync, rdist и т.д.) и копирования файлов (вместо rcp, ftp) с аутентификацией клиента и сервера и шифрованием (и сжатием) передаваемых данных (пароли также шифруются). Дополнительно обеспечивается шифрование данных X Windows и перенаправление любых TCP-соединений (а это уже ухудшает безопасность, т.к. позволяет делать туннели в обход firewall). Защищает от атак с подделкой (spoof) IP-адресов (включая source routing), DNS-сервера и маршрутизации, от подслушивания паролей и X аутентификации, от подслушивания и манипуляции данными на промежуточных хостах или локальной сети. SSH не защищает, если атакующий получил права root на вашем хосте или права к домашней директории.

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

Используемые порты: 22/tcp, 22/udp.

Представляет собой протоколы транспортного уровня, аутентификации и соединения (предполагается стандартизация IETF) и программные средства безопасного доступа к компьютерам по небезопасным каналам связи (telnet, X11, rsh, ftp). Аутентификация производится с использованием ассиметричного шифрования с открытым ключом (SSH1 - RSA, SSH2 - RSA/DSA, благо патент на RSA уже истек). Обмен данными - симметричное шифрование (IDEA - патентованный, DES, triple DES, ARCFOUR - вроде найдена дырка, BLOWFISH - быстрый, CAST128, AES/Rijndael). Целостность переданных данных проверяется с помощью CRC32 в SSH1 (подделывается при атаке типа "man in the middle") или HMAC-SHA1/HMAC-MD5 в SSH2. Протокол транспортного уровня работает поверх TCP, обеспечивает аутентификацию сервера. В качестве ключа используется случайная строка, которую генерирует клиент, шифрует с помощью открытого ключа сервера - его надо откуда-то получить - и передаёт ему (сервер знает свой частный ключ и дешифрует строку, затем передаёт её клиенту, если строка дешифрована правильно, значит сервер настоящий). Протокол аутентификации работает поверх протокола транспортного уровня, обеспечивает аутентификацию клиента для сервера. Протокол соединения - поверх протокола аутентификации, мультиплексирует безопасный канал. Шифрование начинается после аутентификации сервера, но до аутентификации клиента, т.е. паролей в открытом виде не передаётся вовсе. Автоматически производится X11 forwarding (по наличию переменной DISPLAY). Возможно соединение произвольных портов TCP по защищенным каналам. Предусматривается возможность сжатия.

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

Каждый хост должен иметь не менее одного ключа (м.б. общий для нескольких хостов). Предполагается возможность работы с несколькими алгоритмами с открытым ключом, но пока он один - DSS (Digital Signature Standard).

SSH1: каждый хост имеет RSA ключ хоста (обычно 1024 бит), при запуске sshd генерирует временный (1 час, на диск не записывается) RSA ключ сервера (обычно 768 бит). После соединения клиента, сервер передает ему публичный ключ хоста и публичный ключ сервера. Клиент сверяет публичный ключ хоста со своей базой ключей, затем генерирует случайное число (256 бит) и шифрует его публичными ключами хоста и сервера, после чего отсылает серверу. В дальнейшем это случайное число используется как ключ сессии - с его помощью шифруются все сообщения. Алгоритм шифрования предлагается сервером и выбирается клиентом - 3DES (по умолчанию) или Blowfish (быстрее). Клиент пытается аутентифицировать себя с помощью .rhosts или др. механизма (см. ниже).

SSH2: Каждый хост имеет DSA/RSA ключ хоста. Ключ сервера не генерируется. Аутентификация сервера и ключ сессии обеспечивается с помощью алгоритма Diffie-Hellman. Остаток сессии шифруется симметричым алгоритмом шифрования: Blowfish, 3DES, CAST128, Arcfour, AES (128, 192, 256 бит). Целостность сессии обеспечивается hmac-sha1 или hmac-md5. Аутентификация клиента происходит с помощью публичных ключей или "обычных" паролей или интерактивного обмена с помощью дополнительных средств.

Модели аутентификации сервера:

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

Если запустить sshd из-под обычного пользователя, то можно будет заходить только под этим пользователем (используя -p для непривилегированного порта).

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

OpenSSH

Бесплатная реализация протокола SSH для BSD. Портирован под другие OS (версии с буквой "p"). В частности, удалось запустить его под Solaris 2.5 (чего не удалось сделать с оригинальной системой) и Linux 2.2/2.4. Поддерживает протоколы 1.3, 1.5 и 2.0. При желании поддерживает Entropy Gathering Daemon (egd) или PRNGd, PAM и Gnome passphrase. Для установки требуется zlib 1.1.3 и OpenSSL 0.9.5a/0.9.6b. Вывод сообщений на syslog.

Изменения в версиях OpenSSH

Установка 3.0.2p1 в Red Hat 7.2/7.1/7.0/6.2

  1. zlib и OpenSSL в Linux Red Hat 7.2/7.1/7.0 штатные (хотя OpenSSL какой-то медленный), для Linux Red Hat 6.2 надо предварительно установить OpenSSL 0.9.6b, должны быть установлены пакеты pam и pam-devel
  2. получить дистрибутив и разархивировать его
  3. ./configure --with-ipv4-default --with-pam --with-tcp-wrappers --with-md5-passwords --disable-suid-ssh --with-default-path=...
  4. make
  5. make install (при обновлении не заменяются старые ssh_config, sshd_config)
    1. /usr/local/bin
      1. ssh (AKA slogin)
      2. scp
      3. ssh-add (добавление ключей в хранитель - ssh-agent)
      4. ssh-agent (хранитель ключей)
      5. ssh-keygen
      6. ssh-keyscan
      7. sftp
    2. /usr/local/sbin/sshd
    3. /usr/local/libexec/sftp-server
    4. /usr/local/man/man1 (ssh.1, scp.1, ssh-add.1, ssh-agent.1, ssh-keygen.1, ssh-keyscan.1, sftp.1)
    5. /usr/local/man/man8 (sshd.8, sftp-server.8)
    6. /usr/local/etc
      1. ssh_config
      2. sshd_config
      3. moduli
      4. ssh_host_key и ssh_host_key.pub (приватная и публичная части RSA ключа хоста длиной 1024 bit для [email protected]полное-имя-хоста; SSH1; при обновлении версии сохраняются старые ключи)
      5. ssh_host_rsa_key и ssh_host_rsa_key.pub (приватная и публичная части RSA ключа хоста длиной 1024 bit для [email protected]полное-имя-хоста; SSH2; при обновлении версии сохраняются старые ключи)
      6. ssh_host_dsa_key и ssh_host_dsa_key.pub (приватная и публичная части DSA ключа хоста для [email protected]полное-имя-хоста; SSH2; при обновлении версии сохраняются старые ключи)
      7. при обновлении версии в связи с изменениями внести исправления в ssh_config, sshd_config; слить ssh_known_hosts и ssh_known_hosts2; слить authorized_keys и authorized_keys2; перезапустить sshd
  6. налаживание инфраструктуры
  7. остановить все лишние сервера (telnet, rsh, ftp)

Установка 3.0.2p1 в Solaris 2.5

  1. поставить zlib и OpenSSL 0.9.6b
  2. получить дистрибутив и разархивировать его
  3. добавить /usr/ccs/bin в PATH
  4. ./configure --with-ipv4-default --without-pam --disable-suid-ssh --with-default-path=...
  5. make (20 MB)
  6. make install (при обновлении не заменяются старые ssh_config, sshd_config)
    1. /usr/local/bin
      1. ssh (AKA slogin)
      2. scp
      3. ssh-add (добавление ключей в хранитель - ssh-agent)
      4. ssh-agent (хранитель ключей)
      5. ssh-keygen
      6. ssh-keyscan
      7. sftp
    2. /usr/local/sbin/sshd
    3. /usr/local/libexec/sftp-server
    4. /usr/local/man/man1 (ssh.1, scp.1, ssh-add.1, ssh-agent.1, ssh-keygen.1, ssh-keyscan.1, sftp.1)
    5. /usr/local/man/man8 (sshd.8, sftp-server.8)
    6. /usr/local/etc
      1. ssh_config
      2. sshd_config
      3. ssh_prng_cmds (как собирается энтропия для встроенного генератора случайных чисел, при обновлении версии сохраняется старая программа)
      4. moduli
      5. ssh_host_key и ssh_host_key.pub (приватная и публичная части RSA ключа хоста длиной 1024 bit для [email protected]просто-имя-хоста; SSH1; при обновлении версии сохраняются старые ключи)
      6. ssh_host_rsa_key и ssh_host_rsa_key.pub (приватная и публичная части RSA ключа хоста длиной 1024 bit для [email protected]просто-имя-хоста; SSH2; при обновлении версии сохраняются старые ключи)
      7. ssh_host_dsa_key и ssh_host_dsa_key.pub (приватная и публичная части DSA ключа хоста для [email protected]просто-имя-хоста; SSH2; при обновлении версии сохраняются старые ключи)
      8. при обновлении версии в связи с изменениями внести исправления в ssh_config, sshd_config; слить ssh_known_hosts и ssh_known_hosts2; слить authorized_keys и authorized_keys2; перезапустить sshd
  7. налаживание инфраструктуры
  8. остановить все лишние сервера (telnet, rsh, ftp)

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

Налаживание инфраструктуры

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

  1. устанавливаем OpenSSH на все хосты как было описано выше (здесь же создаются RSA/DSA ключи хостов)
  2. конфигурируем /usr/local/etc/sshd_config (права 600) на серверах (я опускаю несущественные параметры)
    1. AllowUsers список-допущенных-пользователей
    2. ClientAliveInterval 20
    3. GatewayPorts no
    4. HostbasedAuthentication no
    5. HostKey /usr/local/etc/ssh_host_dsa_key
    6. IgnoreRhosts yes
    7. IgnoreUserKnownHosts yes
    8. KeepAlive yes
    9. #Port 22
    10. #ListenAddress 0.0.0.0
    11. LogLevel INFO
    12. PasswordAuthentication no
    13. PermitEmptyPasswords no
    14. PermitRootLogin no
    15. PrintMotd no
    16. Protocol 2
    17. ReverseMappingCheck yes
    18. RhostsAuthentication no
    19. RhostsRSAAuthentication no
    20. RSAAuthentication no
    21. StrictModes yes
    22. Subsystem sftp /usr/local/libexec/sftp-server
    23. SyslogFacility AUTH
    24. X11Forwarding yes (если на хосте есть X Windows)
    25. X11DisplayOffset 10 (если на хосте есть X Windows)
  3. обеспечение запуска "sshd -u0 -4" при загрузке
    1. Solaris: /etc/init.d/sshd и линк на него из /etc/rc2.d/S99sshd
    2. Linux Red Hat: /etc/rc.d/init.d/sshd и линк на него из /etc/rc.d/rc2.d/S98sshd (и rc3.d)
  4. собираем все ssh_host_dsa_key.pub, формируем из них /usr/local/etc/ssh_known_hosts и копируем на все хосты
  5. открыть дырки в сетевых экранах для TCP/22
  6. чтобы PAM в RedHat был счастлив - скопировать /etc/pam.d/login в /etc/pam.d/sshd (убрать nullok, тем более что начиная с RH 7.0 его нет)
  7. конфигурация клиента /usr/local/etc/ssh_config
    1. Host *
    2. Cipher blowfish (самый быстрый)
    3. Ciphers blowfish-cbc,3des-cbc
    4. Compression yes (для Fast Ethernet выключить)
    5. FallBackToRsh no
    6. ForwardAgent yes
    7. ForwardX11 yes
    8. GatewayPorts no
    9. HostbasedAuthentication no
    10. IdentityFile ~/.ssh/id_dsa (нет у меня id_rsa)
    11. KeepAlive yes (клиент не завершается)
    12. LogLevel INFO
    13. PasswordAuthentication no
    14. PreferredAuthentications publickey
    15. Protocol 2
    16. RhostsAuthentication no
    17. RhostsRSAAuthentication no
    18. RSAAuthentication no
    19. StrictHostKeyChecking yes
    20. UsePrivilegedPort no
    21. UseRsh no
  8. настройка для интерактивной работы. Т.к. в этом режиме возможно выполнение любых команд, то вход на другой хост без запроса пароля нежелателен, иначе взлом одного хоста автоматически ведет к взлому всех остальных. Но и вводить пароль каждый раз утомительно.
    1. на клиентском хосте (с вводом парольной фразы подлиннее): ssh-keygen -t dsa -f ~/.ssh/id_dsa
    2. на сервере в ~/.ssh/authorized_keys (права 600) добавить содержимое файла ~/.ssh/id_dsa.pub с клиентского хоста
    3. в процедуру начала сеанса на клиентском хосте (.bashrc или .bash_profile или .profile; только с учетом, что мы сюда попали тоже с помощью ssh) или вручную
      1. eval `ssh-agent`
      2. ssh-add ~/.ssh/id_dsa (здесь будет запрошена парольная фраза, но один раз за сеанс)
    4. теперь при выдаче ssh парольная фраза (и пароль серверного хоста запрашиваться не будет)
    5. в конце сеанса (только не .bash_logout) надо выдать "ssh-agent -k"
  9. Выполнение удаленных команд в пакетном режиме (backup, из cron). Здесь некому будет вводить пароль или парольную фразу. Но и разрешать выполнять любую команду с одного хоста на другом тоже не хочется (вскрытие первого хоста автоматически открывает второй). Для каждой команды, которую надо выполнять в пакетном режиме с одного хоста на втором (backup) делаем:
    1. на первом хосте выполнить: ssh-keygen -t dsa -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_AGENT_PID не должны быть установлены): ssh -i ~/.ssh/обозначение-команды второй-хост
  10. избавиться от всех telnet, ftp и rsh

Ключи configure

Демон sshd

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

/var/run/sshd.pid - идентификатор головного процесса sshd.

/usr/local/etc/moduli - Diffie-Hellman группы, используемые для аутентификации.

Обеспечение запуска sshd при начальной загрузке: /etc/init.d/sshd в Solaris 2.5 (и ссылка на него /etc/rc2.d/S99sshd) - сделать из соседнего скрипта, /etc/rc.d/init.d/sshd в Linux Red Hat 6.2/7.0/7.1/7.2 (и ссылка на него /etc/rc.d/rc2.d/S98sshd, /etc/rc.d/rc3.d/S98sshd) - взять из rpm.

Конфигурация демона /usr/local/etc/sshd_config

Права на чтение и запись должны быть только для root. Пустые строки и строки, начинающиеся с "#", считаются комментариями.

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

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

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

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

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

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

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

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

~/.ssh/rc, /usr/local/etc/sshrc - выполняется /bin/sh при входе после чтения окружения, но до запуска shell или команды.

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

~/.ssh/authorized_keys (публичные RSA-ключи для SSH1 и публичные RSA/DSA ключи для SSH2) - публичные ключи, разрешенные для RSA аутентификации (SSH1) и аутентификации с помощью публичных ключей (SSH2, PubkeyAuthentication) при использовании данной учетной записи. Чтение и запись только для владельца. На каждой строке - описание одного ключа в виде разделенных пробелами полей (несколько сотен байт!):

  1. опции (через запятую)
    1. from="список-шаблонов-через-запятую" (принимать соединения только с хостов, удовлетворяющих одному из шаблонов; спец. символы - ?, * и !)
    2. command="команда" (при аутентификации по данному ключу запускать только указанную команду, а не то что указано пользователем - например, backup; TCP/IP и X11 надо запрещать дополнительно; обязательно использовать опцию no-pty для бинарной передачи данных)
    3. no-port-forwarding (запретить TCP/IP forwarding)
    4. no-X11-forwarding
    5. environment="имя=значение" (может быть несколько)
    6. no-agent-forwarding (запретить передачу функции аутентификации внешнему агенту)
    7. no-pty (запретить запрос pty - интерактивную обработку)
    8. permitopen="host:port" (ограничить переназначение локального порта: ssh -L)
  2. ключ
    1. SSH1: RSA bits, exponent, modulus
    2. SSH2: тип ключа (ssh-dss или ssh-rsa), кодированный (base64) ключ
  3. комментарий (имя-пользователя@имя-клиентского-хоста)

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

/usr/local/etc/ssh_known_hosts, ~/.ssh/known_hosts, - публичные ключи (SSH1/SSH2) для известных хостов. Если пользователь пытается соединиться с незнакомым хостом, публичный ключ хоста добавляется в соответствующий личный файл (у пользователя спрашивается разрешение). Эти же файлы используются при RSA аутентификации по имени хоста. Право на запись только у root (общий файл) или владельца (личный файл). /usr/local/etc/ssh_known_hosts должен быть читаем всеми. Может быть несколько строк с различными ключами для одного хоста. Содержит разделенные пробелами поля:

  1. список шаблонов (через запятую) имен хостов (при аутентификации клиента шаблон сравнивается с каноническим именем хоста клиента, при аутентификации сервера - с именем, указанным клиентом; спец. символы - ?, * и !)
  2. RSA bits, exponent, modulus или ssh-dss/ssh-rsa и кодированный в base64 ключ (копируется из /usr/local/etc/ssh_host_[dsa_]key.pub)
  3. комментарий

Ключи хоста

/usr/local/etc/ssh_host_key, /usr/local/etc/ssh_host_rsa_key, /usr/local/etc/ssh_host_dsa_key - приватные ключи хоста (право на чтение только для root, иначе sshd не запускается).

/usr/local/etc/ssh_host_key.pub, /usr/local/etc/ssh_host_rsa_key.pub, /usr/local/etc/ssh_host_dsa_key.pub - публичные ключи хоста (чтение для всех, запись только для root). При работе не используются и предназначены для копирования в ssh_known_hosts на удаленный хост.

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

~/.ssh/identity, ~/.ssh/id_dsa, ~/.ssh/id_rsa - приватный RSA1/DSA2/RSA2 ключ пользователя. Чтение и запись только владельцу. М.б. зашифрован парольной фразой по 3DES.

~/.ssh/identity.pub, ~/.ssh/id_dsa.pub, ~/.ssh/id_rsa.pub - публичный RSA1/DSA2/RSA2 ключ пользователя. Необходимо добавить в ~/.ssh/authorized_keys на все хосты, на которые предполагается заходить с использованием RSA/DSA аутентификации.

Генерация и преобразование ключей

ssh-keygen - генерация, преобразование и управление ключами. По умолчанию генерирует RSA ключ (ключ -t позволяет задать тип ключа). При генерации запрашивается парольная фраза для 3DES (рекомендуется 10-30 символов). Забытую парольную фразу восстановить невозможно. Число бит по умолчанию - 1024 (минимум - 512 бит, увеличение длины ключа замедляет работу). Комментарий по умолчанию - имя-пользователя@имя-хоста. Имя файла для хранения публичного ключа образуется из имени файла для частного ключа добавлением суффикса ".pub". Ключ хоста должен иметь пустую парольную фразу.

Клиент SSH

ssh - telnet, rsh, rlogin в одном флаконе, безопасное соединение с X11-сервером и шифровка произвольного TCP/IP соединения.

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

Вместо тильды можно установить другой escape-символ ключом "-e" или директивой EscapeChar. Если псевдо-терминал не выделен (notty), то передача данных происходит в "прозрачном" режиме.

Если при запуске ssh пользователь использовал X11 (определяется по установленной переменной DISPLAY), то все запросы удаленных программ к X11 серверу перенаправляются по шифруемому каналу и осуществляются с локального хоста к локальному X11 серверу (при этом DISPLAY=удаленный-хост:10.0, а ssh создает proxy-сервер и модифицирует Xauthority так, чтобы реальные куки X11-сервера не были известны ssh-серверу, даже виртуальные куки передаются по сети зашифрованными).

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

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

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

При входе на удаленный сервер устанавливаются переменные: DISPLAY, HOME, LOGNAME, MAIL, PATH (определяется при компиляции ssh), SSH_AUTH_SOCK (unix socket для взаимодействия с агентом аутентификации), SSH_CLIENT (ip-адрес клиента, порт клиента, порт сервера), SSH_ORIGINAL_COMMAND, SSH_TTY, TZ, USER, строки из ~/.ssh/environment.

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

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

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

Опции ssh-agent:

Опции ssh-add:

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

   eval `ssh-agent`
   ssh-add ~/.ssh/id_dsa

sftp

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

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

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

     sftp [[email protected]]host[:file [file]]

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

Мда... Это не wu-ftpd :( Слишком много возможностей и никаких средств для их ограничения со стороны системного администратора. Клиентам это давать нельзя.

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

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

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

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

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

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

Сбор ключей (ssh-keyscan)

ssh-keyscan позволяет собрать публичные ключи хостов, имена хостов задаются в качестве параметров или в файле. Опрос производится параллельно. Опции:

По умолчанию собирает ключи rsa1, а если сервер не поддерживает SSH1, то определяет номер версии протокола и номер версии софта, но не выдает публичный ключ хоста (хочет 1.3 GB памяти ;).

Оригинальный SSH

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

SSH в Cisco IOS

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

Sergey E. Bogomolov