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

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

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

Последние изменения:
2009.09.30: sysadmin: Zabbix - распределённая система мониторинга

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

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

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

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

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

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

Представляет собой протоколы транспортного уровня, аутентификации и соединения (предполагается стандартизация 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 (приложение на сервере общается с виртуальным X сервером, созданным ssh; ssh передаёт данные X протокола по защищённому каналу на клиентскую машину, где и передаёт настоящему X серверу; данные X авторизации подменяются). Возможно соединение произвольных портов 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 для OpenBSD. Портирован под другие OS (версии с буквой "p"). В частности, удалось запустить его под Solaris 2.5 (чего не удалось сделать с оригинальной версией SSH) и Linux 2.2/2.4/2.6. Поддерживает протоколы 1.3, 1.5 и 2.0 (1.99). При желании поддерживает источники псевдослучайных чмсел Entropy Gathering Daemon (egd) или PRNGd, если отсутствует /dev/random; PAM и Gnome passphrase. Для установки требуется zlib 1.1.4 и OpenSSL 0.9.6b. Вывод сообщений на syslog.

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

Установка 4.2p1 в Red Hat 5.2 (экзотика)
  1. обновить zlib
  2. установить OpenSSL 0.9.6h
    3. ./configure --with-pam --with-tcp-wrappers --with-md5-passwords --without-zlib-version-check
  3. make
  4. make install (при обновлении не заменяются старые ssh_config, sshd_config)
  5. налаживание инфраструктуры

Установка 3.9p1 в Fedora Core 3

Установка из штатных пакетов: openssh-3.9p1-7, openssh-clients-3.9p1-7, openssh-server-3.9p1-7, openssh-askpass-3.9p1-7, openssh-askpass-gnome-3.9p1-7:

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

Ключи 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 (/etc/ssh/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, /etc/ssh/sshrc (/usr/local/etc/sshrc) - выполняется /bin/sh при входе после чтения окружения, но до запуска shell или команды (при перенаправлении X должен обрабатывать куки со стандартного ввода и вызывать xauth).

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

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

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

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

Ключи хоста

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

/etc/ssh/ssh_host_key.pub (/usr/local/etc/ssh_host_key.pub), /etc/ssh/ssh_host_rsa_key.pub (ssh//usr/local/etc/ssh_host_rsa_key.pub), /etc/ssh/ssh_host_dsa_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) и установил ForwardX11 (или указал ключи -x, -X), то все запросы удаленных программ к X11 серверу перенаправляются по шифруемому каналу и осуществляются с локального хоста к локальному X11 серверу (при этом DISPLAY=удаленный-хост:10.0, а ssh создает proxy-сервер и модифицирует Xauthority так, чтобы реальные куки X11-сервера не были известны ssh-серверу, даже виртуальные куки передаются по сети зашифрованными).

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

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

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

При входе на удаленный сервер устанавливаются переменные: 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, SSH_TTY, TZ, USER, строки из ~/.ssh/environment. Передаются значения переменных, указанных в 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 создается unix сокет для общения других программ из пакета ssh с ssh-agent (его имя записывается в SSH_AUTH_SOCK). root может общаться с вашим агентом аутентификации (интересно, что он может сделать?)!

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

Опции ssh-agent:

Опции ssh-add:

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

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

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

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

sftp

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

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

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

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

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

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

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

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

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

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

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

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

Сбор ключей (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 работает).

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

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

Формат файла с публичным ключом (600) 

---- BEGIN SSH2 PUBLIC KEY ----
Subject: имя-пользователя
Comment: "rsa, описание-ключа, дата"
содержимое-ключа
---- END SSH2 PUBLIC KEY ----

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

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

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

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

Последние изменения:
2009.09.30: sysadmin: Zabbix - распределённая система мониторинга
TopList
система гарант. унитазы ideal standard из европы
Copyright © 1996-2009 Sergey E. Bogomolov; www.bog.pp.ru (КГБ знает все, даже то что у Вас на диске ;)