Содержание


Первые шаги по настройке и использованию SSH

Практическое руководство

Comments

Что такое SSH? Краткое описание

Протокол Secure Shell (SSH) был разработан для максимальной защиты сетевых взаимодействий с удаленными узлами сети. Этот протокол шифрует сетевой трафик при помощи улучшенных возможностей аутентификации, а также функций, направленной на защиту других незащищенных протоколов – таких как защищенное копирование (Secure Copy, SCP), защищенный протокол передачи файлов (Secure File Transfer Protocol, SFTP), перенаправление X-сеансов и перенаправление портов. Поддерживается несколько типов шифрования (начиная от 512-битного и заканчивая 32768-битным) с использованием различных криптографических алгоритмов – Blowfish, Triple DES, CAST-128, Advanced Encryption Scheme (AES) и ARCFOUR. Чем выше разрядность шифрования, тем больший объем трафика генерируется в сети. Из рисунка 1 видно, как любой пользователь сети может с легкостью просмотреть трафик telnet-подключения с помощью анализатора сетевых пакетов (например, Wireshark).

Рисунок 1. Подключения с использованием протокола telnet не зашифрованы
Рисунок 1. Подключения с использованием протокола telnet не зашифрованы
Рисунок 1. Подключения с использованием протокола telnet не зашифрованы

Если вы используете незащищенный "открытый" протокол (например, telnet), то любой пользователь сети может подсмотреть ваши пароли и другую секретную информацию. На рисунке 1 изображена схема подключения пользователя fsmythe к удаленному узлу с использованием telnet. Пользователь вводит свое имя fsmythe и пароль r@m$20!0, которые может видеть любой пользователь, находящийся в той же сети, что и наш ничего не подозревающий пользователь telnet.

Рисунок 2. Подключения с использованием протокола SSH зашифрованы
Рисунок 2. Подключения с использованием протокола SSH зашифрованы
Рисунок 2. Подключения с использованием протокола SSH зашифрованы

На рисунке 2 изображена типовая схема SSH-подключения, и мы видим, что никакой пользователь сети не может просматривать зашифрованный трафик. Пакеты SSH (как правило, это Open Source-пакет OpenSSH) по умолчанию установлены во всех распространенных дистрибутивах Linux® и UNIX®, поэтому вам вряд ли придется загружать и компилировать их из исходного кода. Если вы не работаете в Linux или UNIX, то существует множество поддерживаемых бесплатных SSH-инструментов, например, WinSCP, Putty, FileZilla, TTSSH и Cygwin (программное обеспечение POSIX, устанавливаемое в операционной системе Windows®). Эти инструменты работают под управлением операционной системы Windows и имеют интерфейс командной оболочки UNIX или Linux.

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

Архитектура SSH

В документах IETF RFC 4251-4256 дается следующее определение SSH: "Протокол SSH используется для организации безопасного входа в удаленную систему и организации иных безопасных служб через сети, не обеспечивающие безопасности". Протокол включает три основных компонента (рисунок 3):

  • Протокол транспортного уровня: обеспечивает аутентификацию серверов, конфиденциальность и целостность. Этот протокол может также обеспечивать сжатие информации и работает в основном с использованием соединений TCP/IP, но может быть реализован и на базе иных потоков данных с гарантированной доставкой.
  • Протокол аутентификации пользователей: используется на серверах для проверки подлинности клиентов и работает на основе протокола транспортного уровня.
  • Протокол соединений: обеспечивает мультиплексирование шифрованного туннеля в несколько логических каналов и работает поверх протокола аутентификации пользователей.
Рисунок 3. Логические уровни протокола SSH
Рисунок 3. Логические уровни протокола SSH

Транспортный уровень отвечает за обмен ключами и аутентификацию серверов. На этом уровне обеспечивается поддержка шифрования, проверки целостности и сжатия данных (при необходимости), после чего на верхний уровень передается API-интерфейс для отправки и получения нешифрованных текстовых пакетов. Уровень аутентификации пользователей обеспечивает проверку подлинности клиентов при помощи различных методов. Наиболее распространенные методы аутентификации включают в себя использование паролей и открытых ключей, ввод данных с клавиатуры, интерфейс GSSAPI, технологию SecureID, а также различные подключаемые модули аутентификации (PAM).

На уровне соединений определяются каналы, глобальные запросы, а также запросы на предоставление каналов, через которые предоставляются службы SSH. Одно SSH-соединение может одновременно включать в себя несколько каналов, в каждом из которых происходит двунаправленная передача данных. Запросы на предоставление каналов используют такую информацию, как код завершения процесса на стороне сервера. SSH-клиент инициирует запрос для пересылки в порт на стороне сервера.

Эта открытая архитектура обладает большой гибкостью. Транспортный уровень совместим с протоколом Transport Layer Security (TLS), и вы можете реализовывать собственные методы проверки подлинности, расширяя уровень аутентификации пользователей. Уровень соединений позволяет объединять в одном SSH-подключении несколько сеансов (рисунок 4).

Рисунок 4. SSH в 7-уровневой модели OSI
Рисунок 4. SSH в 7-уровневой модели OSI
Рисунок 4. SSH в 7-уровневой модели OSI

Примеры типового использования SSH в операционных системах UNIX и Linux

Как правило, SSH используется для того, чтобы пользователи могли подключаться к удаленным компьютерам и выполнять на них различные команды. Однако SSH также поддерживает туннелирование и X11-соединения и даже позволяет передавать файлы с помощью SFTP и SCP. SSH можно использовать во множестве приложений для различных платформ, включая Linux, UNIX, Windows и Apple® OS X (для запуска некоторых приложений могут потребоваться дополнительные возможности, доступные либо совместимые только с определенными SSH-клиентами или SSH-серверами).

Рассмотрим несколько общих примеров синтаксиса SSH:

  • Доступ к командной оболочке удаленного компьютера (вместо использования незащищенных протоколов telnet и rlogin):
    # ssh fsmythe@example.com
    [fsmythe@example.com] ~
  • Выполнение отдельной команды на удаленном компьютере (вместо использования rsh)
    # ssh root@example.com reboot 
    root@example.com's password: ******
  • Копирование файлов с локального сервера на удаленный компьютер посредством команды SCP:
    root@edb-01.example.com's password: ******
    file1.txt      100%    0     0.0KB/s   00:00
    file2.txt      100%    0     0.0KB/s   00:00
  • Защищенная передача файлов посредством SFTP (вместо использования FTP):
    sftp fsmythe@example.com 
    Connecting to example.com...
    fsmythe@example.com's password: *******
    sftp>
  • Эффективные и безопасные процедуры резервного копирования, синхронизации и зеркалирования файлов на локальный или удаленный компьютер при помощи rsync:
    # rsync -avul --rsh=ssh /opt/edbdata/ root@example.com:/root/backup/
    root@example.com's password: ******
    building file list ... done
    ./
    file1.txt
    file2.txt
    file3.txt
    file4.txt
    dir1/file5.txt
    dir2/file6.txt
    
    sent 982813 bytes  received 2116 bytes  1374860.38 bytes/sec
    total size is 982138  speedup is 1.00
  • Перенаправление или туннелирование порта (не путайте с VPN):
    ssh -L 8000:mailserver:110 example.com    fsmythe@example.com's password: ********
  • Перенаправление X-сеансов с удаленного компьютера (может осуществляться через несколько промежуточных узлов):
    Edit /etc/ssh/sshd_config and change 2 keywords : 
    AllowTcpForwarding yes
    X11Forwarding yes
    # service sshd restart 
    $ export DISPLAY 
    $ ssh -X fsmythe@example.com
  • Конфигурация с перенаправлением X11, используемая совместно с клиентом X Windows, в котором настроено SSH-туннелирование X11. Это позволяет использовать графическую подсистему UNIX или Linux через защищенное SSH-соединение на локальном компьютере с Windows, подключенном через SSH к удаленному узлу Linux или UNIX:
    ssh -ND 8000 fsmythe@example.com
    Browser Settings, goto 'Manual Proxy Configuration' set "SOCKS Host" to example.com,
    the 'Port to 8000' , Enable SOCKS v5, and lastly set 'No Proxy for' field
    to 'localhost, 127.0.0.1'
  • Безопасное монтирование директории удаленного сервера в качестве файловой системы локального компьютера с помощью sshfs:
    # yum install sshfs fuse-utils (Install sshfs and fuse-utils)
    $sshfs example.com:/remote_dir /mnt/local_dir
  • Автоматизированное наблюдение и управление удаленными серверами при помощи различных средств:
    (Report number of apache processes running on the remote server example.com):
    $ ssh example.com ps -ef | grep httpd | wc -l
    root@example.com's password: *****

Полезные советы по настройке и использованию SSH

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

  • Запретите удаленные подключения пользователям с привилегиями root:
    # vi /etc/ssh/sshd_config
    PermitRootLogin no
  • Создавайте пары ключей (открытый/закрытый) с использованием стойких идентификационных фраз и защищайте закрытый ключ паролем (никогда не генерируйте пары ключей или идентификационные фразы без использования паролей):
    (Use a higher bit rate for the encryption for more security)
    ssh-keygen -t rsa -b 4096
  • Настраивайте обработчики TCP (TCP wrappers) таким образом, чтобы разрешать подключаться только определенным удаленным компьютерам, а всем остальным – запрещать:
    # vi /etc/hosts.deny
    ALL: 192.168.200.09		# IP Address of badguy
  • Отключайте функциональность SSH-сервера на рабочих станциях и ноутбуках – для этого отключите службу SSH, а затем удалите пакет SSH-сервера:
    # chkconfig sshd off 
    # yum erase openssh-server
  • Управляйте разрешениями на SSH-подключение с помощью учетных записей:
    # vi /etc/ssh/sshd_config 
    AllowUsers fsmythe bnice swilson
    DenyUsers jhacker joebadguy jripper
  • Используйте только протокол SSH версии 2:
    # vi /etc/ssh/sshd_config
    Protocol 2
  • Закрывайте неактивные подключения, указав время простоя:
    # vi /etc/ssh/sshd_config
    ClientAliveInterval 600		# (Set to 600 seconds = 10 minutes)
    ClientAliveCountMax 0
  • Запрещайте аутентификацию на основе хоста:
    # vi /etc/ssh/sshd_config
    HostbasedAuthentication no
  • Отключайте пользовательские файлы .rhosts:
    # vi /etc/ssh/sshd_config
    IgnoreRhosts yes
  • Настраивайте брандмауэр таким образом, чтобы разрешать входящие SSH-подключения только из доверенных сетей:
    Update /etc/sysconfig/iptables (Redhat specific file) to accept connection only 
    from 192.168.100.0/24 and 209.64.100.5/27, enter:
    
    -A RH-FW-1-INPUT -s 192.168.100.0/24 -m state --state NEW -p tcp --dport 22 -j ACCEPT
    -A RH-FW-1-INPUT -s 209.64.100.5/27 -m state --state NEW -p tcp --dport 22 -j ACCEPT
  • Явно указывайте сетевые интерфейсы, которые должны принимать входящие SSH-подключения:
    # vi /etc/ssh/sshd_config
    ListenAddress 192.168.100.17
    ListenAddress 209.64.100.15
  • Настраивайте политики пользователей на использование стойких паролей, обеспечивающих защиту от атак с помощью полного перебора, социальной инженерии и подбора по словарям:
    # < /dev/urandom tr -dc A-Za-z0-9_ | head -c8
    oP0FNAUt[
  • Ограничивайте доступ SFTP-пользователей их домашними директориями с помощью параметра Chroot SSHD:
    # vi /etc/ssh/sshd_config 
    ChrootDirectory /data01/home/%u
    X11Forwarding no
    AllowTcpForwarding no
  • Запрещайте использование пустых паролей:
    # vi /etc/ssh/sshd_config
    PermitEmptyPasswords no
  • Ограничивайте количество входящих соединений на порт 2022 в определенный интервал времени:
    Redhat iptables example (Update /etc/sysconfig/iptables): 
    
    -A INPUT  -i eth0 -p tcp --dport 2022 -m state --state NEW -m limit --limit 3/min
    --limit-burst 3 -j ACCEPT
    
    -A INPUT  -i eth0 -p tcp --dport 2022 -m state --state ESTABLISHED -j ACCEPT
    -A OUTPUT -o eth0 -p tcp --sport 2022 -m state --state ESTABLISHED -j ACCEPT
  • Настраивайте iptables таким образом, чтобы в течение 30 секунд разрешать не более трех попыток подключения к порту 2022:
    Redhat iptables example (Update /etc/sysconfig/iptables): 
    -I INPUT -p tcp --dport 2022 -i eth0 -m state --state NEW -m recent --set
    
    -I INPUT -p tcp --dport 2022 -i eth0 -m state --state NEW -m recent --update 
    --seconds 30 --hitcount 3 -j DR
  • Используйте анализатор log-файлов (например, logcheck, loggrep, splunk или logwatch) для более тщательного анализа и создания отчетов. Настройте также само SSH-приложение на более подробное журналирование событий:
    Installation of the logwatch package on Redhat Linux 
    # yum install logwatch
  • Устанавливайте наиболее подробный уровень журналирования SSH:
    # vi /etc/ssh/sshd_config
    LogLevel DEBUG
  • Всегда обновляйте пакеты SSH и необходимые библиотеки до последних версий:
    # yum update openssh-server openssh openssh-clients -y
  • Скрывайте версию OpenSSH в исходном коде, после чего компилируйте приложение заново. После этого вносите следующие изменения:
    # vi /etc/ssh/sshd_config
    VerifyReverseMapping yes	# Turn on  reverse name checking
    UsePrivilegeSeparation yes	# Turn on privilege separation
    StrictModes yes			# Prevent the use of insecure home directory    
    				# and key file permissions
    AllowTcpForwarding no		# Turn off , if at all possible 
    X11Forwarding no		# Turn off , if at all possible
    PasswordAuthentication no	# Specifies whether password authentication is 
    				# allowed.  The default is yes. Users must have 
    				# another authentication method available .
  • Удаляйте исполняемые файлы rlogin и rsh из системы и замещайте их symlink -ссылками на SSH:
    # find /usr -name rsh
    /usr/bin/rsh
    # rm -f /usr/bin/rsh
    # ln -s /usr/bin/ssh /usr/bin/rsh

SSH поддерживает множество разнообразных методов и способов аутентификации, которые можно включать и отключать. Этим можно управлять в конфигурационном файле /etc/ssh/sshd_config, указывая ключевое слово, относящееся к тому или иному методу аутентификации, с последующим указанием параметра yes или no. В следующем примере показаны наиболее распространенные параметры:

# RSAAuthentication yes		
# PubkeyAuthentication yes		
# RhostsRSAAuthentication no
# HostbasedAuthentication no
# RhostsRSAAuthentication and HostbasedAuthentication
PasswordAuthentication yes
ChallengeResponseAuthentication no
# KerberosAuthentication no
GSSAPIAuthentication yes

Ключевые слова AllowedAuthentications и RequiredAuthentications в файле sshd_config определяют, какие конфигурации и методы аутентификации используются только с протоколом SSH версии 2. Синтаксис, разрешающий аутентификацию с помощью паролей и открытых ключей, выглядит следующим образом:

# vi /etc/ssh/sshd_config
AllowedAuthentications publickey, password
RequiredAuthentications publickey, password

Открытые и закрытые ключи SSH

Вспомогательными инструментами проверки подлинности SSH являются средства управления ключами и связанные с ними агенты. Если настроена аутентификация с использованием открытого ключа, то ваш ключ подтверждает вашу подлинность удаленному узлу SSH. Подлинность на основе SSH определяется на основе двух компонентов: открытого и закрытого ключей. Закрытый ключ SSH подтверждает подлинность пользователя при исходящем SSH-подключении и должен храниться в секрете. Когда пользователь инициирует SSH- или SCP-подключение к удаленному компьютеру или серверу, он является SSH-клиентом. При помощи математических алгоритмов ваш закрытый ключ становится вашей персональной электронной картой доступа, а открытый ключ – замком, к которому подходит ваша электронная карта. Ваш закрытый ключ говорит: "Это действительно я, Фред Смит"; открытый ключ отвечает: "Да, вы действительно Фред Смит, ваша личность установлена, пожалуйста, входите".

Открытый ключ определяет, кому разрешено открывать замок и получать право на вход. Открытые ключи не нужно держать в секрете, поскольку их невозможно использовать для компрометации системы или для несанкционированного доступа. В операционных системах Linux и UNIX открытые и закрытые ключи хранятся в виде текстовых ASCII-файлов; в системах под управлением Windows пары ключей могут храниться как в текстовых файлах, так и в реестре Windows.

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

Рисунок 5. Диаграмма взаимодействий открытых и закрытых SSH-ключей согласно архитектуре SSH
Рисунок 5. Диаграмма взаимодействий открытых и закрытых SSH-ключей согласно архитектуре SSH
Рисунок 5. Диаграмма взаимодействий открытых и закрытых SSH-ключей согласно архитектуре SSH

Пошаговая настройка закрытого и открытого ключей SSH

В листинге 1 с помощью утилиты ssh-keygen создается пара SSH-ключей (открытый и закрытый) для пользователя fsmythe; эти ключи имеют тип dsa (значение атрибута type).

Листинг 1. Генерация пары SSH-ключей
[fsmythe@example.com ~]$ /usr/bin/ssh-keygen -t dsa
Generating public/private dsa key pair.
Enter file in which to save the key (/home/fsmythe/.ssh/id_dsa):
Enter passphrase (empty for no passphrase): ******    (Enter 'mypassword')
Enter same passphrase again: ******	(Enter 'mypassword')
Your identification has been saved in /home/fsmythe/.ssh/id_dsa.
Your public key has been saved in /home/fsmythe/.ssh/id_dsa.pub.
The key fingerprint is:
33:af:35:cd:58:9c:11:91:0f:4a:0c:3a:d8:1f:0e:e6 fsmythe@example.com
[fsmythe@example.com ~]$

В листинге 2 выполняется копирование открытого ключа в файл authorized_keys, расположенный в поддиректории .ssh домашней директории нужного пользователя на целевом компьютере.

Листинг 2. Копирование открытого ключа с компьютера-источника в файл authorized_keys на целевом компьютере
[fsmythe@example.com ~]$ scp -p /home/fsmythe/.ssh/id_dsa.pub 
fsmythe@thor01.com:/home/fsmythe/.ssh/authorized_keys
fsmythe@ thor01.com's password:
id_dsa.pub       100%  	624   	0.6KB/s    	00:00

В листинге 3 выполняется первое удаленное SSH-обращение (запуск команды ls -d /tmp) к серверу, вследствие чего ключ кэшируется на сервере в файле .ssh/known_hosts. Пользователь вводит парольную фразу, заданную на этапе генерации SSH-ключей, а вывод команды, запущенной на удаленном сервере, передается на экран локального компьютера.

Листинг 3. Проверка SSH-доступа посредством запуска команды на удаленном компьютере
[fsmythe@example.com ~]$ ssh root@thor01.com ls -d /tmp
The authenticity of host 'thor01.com (10.12.53.118)' can't be established.
RSA key fingerprint is 84:4f:e5:99:0b:7d:54:d0:1b:3e:2b:96:02:34:41:25.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'thor01.com,10.12.53.118' (RSA) to the list of known hosts.
Enter passphrase for key '/root/.ssh/id_dsa': ******  (Enter 'mypassword') 
/tmp
file1.txt
file2.txt
dir3_5432

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

Конфигурирование и использование утилиты ssh-agent

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

[root@example01.com ~]# ssh root@example02.com
Enter passphrase for key '/root/.ssh/id_dsa':******	(User must type password)
Last login: Sat May  8 06:37:26 2010 from 10.12.53.118

Далее с помощью ssh-agent сгенерируйте на устройство stdout команды интерпретатора bash:

[root@example01.com ~]# ssh-agent -s
SSH_AUTH_SOCK=/tmp/ssh-vxZIxF1845/agent.1845; export SSH_AUTH_SOCK;
SSH_AGENT_PID=1849; export SSH_AGENT_PID;
echo Agent pid 1849;

На третьем шаге задайте значения вышеупомянутых переменных среды для текущего сеанса командной оболочки:

[root@example01 ~]# SSH_AUTH_SOCK=/tmp/ssh-vxZIxF1845/agent.1845;export SSH_AUTH_SOCK
SSH_AGENT_PID=1849; export SSH_AGENT_PID;echo Agent pid 1849
Agent pid 1849

Убедитесь, что утилита ssh-agent запущена:

[root@example01.com ~]# ps -fp $SSH_AGENT_PID
UID        PID  PPID  C STIME TTY          TIME CMD
root      1849     1  0 06:14 ?        00:00:00 ssh-agent -s

Получите список текущих элементов, загруженных внутри ssh-agent:

[root@example01.com ~]# ssh-add -l
The agent has no identities.

На следующем шаге добавьте требуемые SSH-элементы (выполнив их предварительную аутентификацию с использованием парольной фразы SSH-ключей):

[root@example01.com ~]# ssh-add
Enter passphrase for /root/.ssh/id_dsa:
Identity added: /root/.ssh/id_dsa (/root/.ssh/id_dsa)	****** (Entered 'mypassword')

Убедитесь, что указанные элементы были загружены в запущенную оболочку ssh-agent:

[root@example01.com ~]# ssh-add -l
1024 33:af:35:cd:58:9c:11:91:0f:4a:0c:3a:d8:1f:0e:e6 /root/.ssh/id_dsa (DSA)

Наконец, можно проверить работу ssh-agent с использованием синтаксиса SSH. Обратите внимание на отсутствие запроса на ввод парольной фразы:

# Assuming target remote host has correct authorized key for private key from example01
[root@example01.com ~]# ssh -A root@example02.com	
Last login: Sat May  8 06:36:27 2010 from 10.12.53.118
[root@example02 ~]#

# Assuming target remote host has correct authorized key for private key from example03
[root@example01.com ~]# ssh -A root@example03.com		
Last login: Sat May  8 07:04:05 2010 from 10.12.53.119
[root@example03 ~]#

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

Другой инструмент, SSH-утилита ssh-keyscan из листинга 4, позволяет собирать открытые SSH-ключи хостов с удаленных компьютеров. Эта чрезвычайно быстрая и эффективная утилита полезна при наполнении файлов /etc/ssh_known_hosts. В первую очередь она предназначена для использования в командных сценариях, помогающих автоматизировать процессы.

Листинг 4. Пример использования ssh-keyscan
[root@example01 ~]# /usr/bin/ssh-keyscan -t rsa,dsa example02.com
# example02.comSSH-2.0-OpenSSH_4.3
example02.comssh-dss AAAAB3NzaC1kc3MAAACBALd5/TGn7jCL1DWWzYMw96jw3QOZGBXJgP4m9LACViyM0QHs
ewHGo841JdInfE825mVe0nB/UT15iylLOsI/jFCac+ljQRlO+h2q7WOwGveOUN7TxyKlejM+G1pg5DndGt05iYn+2
dDfn5CmEsI+K0F2vk/+mpoSOk9HKq9VgwNzAAAAFQDPeLAth62TRUcN/nTYoqENBmW3SwAAAIEAryoKa+VaG5LQNj
wBujAuA7hGl+DIWVb1aZ8xAHkcyL5XgrOWEKNnK9mDmEN66oMLfTMO3w8/OvbJUmcXcU3jnL3zguz2E2OIv6t6vAa
F6niL7A/VhxGGxy4CJZnceufStrzZ3UKXRzjwlm0Bwu/LruVF2m3XLvR5XVwUgyWvw+AAAACAaK12k3uC/OOokBgi
eu/SuD5wCSBsf9rqG9ZFa32ujZwRZmA/AwPrZd6q3ASxmjtMp6zGQSzxPczUvLH9D9WIJo713bw8wCPo/7pqiQNRs
OZXqlQyaXyrDout6CI683b1/rxsZKPrJpFNehrZwjWrwpYhK7VaTuzxvWtrDyDxWec=
# example03.comSSH-2.0-OpenSSH_4.3
example03.comssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq5So5VBeH4gPX1A1VEeQkGsb/miiWsWnNTW8ZWYj
2IvU7rKpk/dBIp64WecYYYgDqTK5u0Q+yTijF8wEEI9rRyoh9p5QraM8qy9NxcHzyGqU4vSzfVrblIQrDI8iv7iwz
7PxQAY76NmweaUyGEDfIErty4gCn/ksy85IgffATa9nt36a4iUhiDNifnE8dm1ZrKkvz3lIg0w+Cu0T9MY77AqLWj
Moo0WoQArIvYa0soS3VhzgD/Biwu/sh3eHJtFUxTVxnATdkWkHKUI1wxma3j7jF0saTRKEQSvG6492W+U1FhEjFGN
r7KeZXH99uFpuUWFA7xO7uaG/MLWSjPJMxw==
# example04.comSSH-2.0-OpenSSH_4.3
example04.comssh-dss AAAAB3NzaC1kc3MAAACBALd5/TGn7jCL1DWWzYMw96jw3QOZGBXJgP4m9LACViyM0QHs
ewHGo841JdInfE825mVe0nB/UT15iylLOsI/jFCac+ljQRlO+h2q7WOwGveOUN7TxyKlejM+G1pg5DndGt05iYn+2
dDfn5CmEsI+K0F2vk/+mpoSOk9HKq9VgwNzAAAAFQDPeLAth62TRUcN/nTYoqENBmW3SwAAAIEAryoKa+VaG5LQNj
wBujAuA7hGl+DIWVb1aZ8xAHkcyL5XgrOWEKNnK9mDmEN66oMLfTMO3w8/OvbJUmcXcU3jnL3zguz2E2OIv6t6vAa
F6niL7A/VhxGGxy4CJZnceufStrzZ3UKXRzjwlm0Bwu/LruVF2m3XLvR5XVwUgyWvw+AAAACAaK12k3uC/OOokBgi
eu/SuD5wCSBsf9rqG9ZFa32ujZwRZmA/AwPrZd6q3ASxmjtMp6zGQSzxPczUvLH9D9WIJo713bw8wCPo/7pqiQNRs
OZXqlQyaXyrDout6CI683b1/rxsZKPrJpFNehrZwjWrwpYhK7VaTuzxvWtrDyDxWec=
# example05.comSSH-2.0-OpenSSH_4.3
example05.comssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAq5So5VBeH4gPX1A1VEeQkGsb/miiWsWnNTW8ZWYj
2IvU7rKpk/dBIp64WecYYYgDqTK5u0Q+yTijF8wEEI9rRyoh9p5QraM8qy9NxcHzyGqU4vSzfVrblIQrDI8iv7iwz
7PxQAY76NmweaUyGEDfIErty4gCn/ksy85IgffATa9nt36a4iUhiDNifnE8dm1ZrKkvz3lIg0w+Cu0T9MY77AqLWj
Moo0WoQArIvYa0soS3VhzgD/Biwu/sh3eHJtFUxTVxnATdkWkHKUI1wxma3j7jF0saTRKEQSvG6492W+U1FhEjFGN
r7KeZXH99uFpuUWFA7xO7uaG/MLWSjPJMxw==

Использование SSH в приложениях и сценариях UNIX

SSH-доступ из удаленных командных сценариев и удаленных инструментов администрирования (обслуживание системы, удаленное резервное копирование и архивация) чрезвычайно удобен, но этот вопрос всегда является предметом горячих дебатов с точки зрения безопасности серверов. Многие командные сценарии, которые могут быть запущены пользователями, например:

$ ssh fsmythe@example.com /usr/local/bin/dangerous_script.pl

не могут обрабатывать вводимые пользователями парольные фразы SSH и прекращают работу, если заранее не была настроена беспарольная конфигурация SSH-ключей, конфигурация с использованием ssh-agent или механизм доверенной сети – т. е. один из методов, не требующий ввода SSH-паролей. Это происходит потому, что SSH ожидает ввода парольной фразы с терминала, связанного с текущим сеансом командной оболочки. Эту проблему можно обойти, используя сценарии, написанных при помощи expect, либо при помощи Perl-сценариев (рассмотрите возможности CPAN-модуля Net::SSH::Perl); к ним можно также обращаться из вашего собственного сценария:

#!/usr/local/bin/expect
spawn sftp $argv
expect "password:"
send "mysshpassowrd\r"

Некоторые системные администраторы считают предоставление обычным пользователям беспарольного SSH-доступа к удаленным хостам достаточной причиной для линчевания. Однако существуют альтернативные меры безопасности, оправдывающие беспарольные механизмы SSH-доступа к удаленным хостам, например, когда пользователь использует на удаленном компьютере ограниченную командную оболочку korn (rksh – restricted korn shell) или shell (rssh – restricted shell) вместо полнофункциональной Bash. Также с помощью авторизованных ключей можно ограничить список команд, которые разрешено запускать пользователям на удаленном компьютере, в результате чего пользователи не смогут случайно запустить команду, способную нанести вред системе. Пример такого ограничения представлен в листинге 5.

Листинг 5. Пример настройки ограничений с использованием файла authorized_keys на удаленном компьютере
[fsmythe@example02 .ssh]$ more authorized_keys
command="/usr/local/bin/secureScript.sh",no-port-forwarding,no-X11-forwarding,no-agent-fo
rwarding,no-pty ssh-dss AAAAB3NzaC1kc3MAAACBAOFsC6C7cJUGOZG4Ur9W0J6mxTTk5+MYTu5XfRESPLVwQ
A7HlUxhsXsxgmb1L1RgvR/g0JZnipDS+fGOrN2/IerSpgyzegTVxYLPrOovvuyCn5TA0+rmyrkV27so6yRDkdqTJc
YzWNJOyDndnTrDc/LNmqLFKoGMQ33aur6RNv4VAAAAFQD4leC5Fc1VJqjvXCNsvazBhi84vQAAAIAWbshT80cTESg
dX/srxX4KVNAzY1uhBz5V0UYR4FGP+aoe6laxRj+gQvFIvAKIrpikvBjgyW6cdT8+k0t8HGIQp20MzSBdY9sH8xdj
05AG97Nb/L8xzkceB78qfXhV6txaM1CzssUtiOtaAygrywNPBDEN9MbEbwpVVVyd6iqZNgAAAIAmV0SUZoUr8dHdC
tagRye4bGOQjoztpb4C0RbXQw+w7Jpzr6cZISdZsK4DTBjODvv2+/OWPm7NEzzWyLzHPBNul8hAHOUCOpp+mYWbXX
F78BTk2Ess0SZu8dwpOtasTNEp+xPcsOvQx2Kdr17gTp+28SfpREuLudOr6R3KeTb+hw== fsmythe@example01

В этом примере пользователю fsmythe разрешено выполнять на компьютере example01 единственную команду: /usr/local/bin/secureScript.sh.

Создание среды доверенных узлов с помощью SSH

Наконец, следует упомянуть о среде доверенных узлов, являющейся заменой использованию открытых и закрытых ключей SSH. В средах с использованием командных сценариев (или если стоит задача автоматизировать определенные процедуры), в которых необходимо использовать эти типы обращений, среда доверенных узлов имеет определенные преимущества по сравнению с использованием SSH-ключей (хотя при этом остаются риски, связанные с нарушением безопасности). Среда доверенных узлов (или аутентификация на основе доверенных узлов) по большей части реализуется с помощью заранее сконфигурированных файлов, содержащих списки пользователей и хостов, которым разрешен доступ. Существует два типа аутентификации на основе доверенных узлов. В первом, более старом и менее защищенном методе (например, OpenSSH и SSH1) используются команды открытого протокола (rsh, rcp и rlogin), проверяется два файла и устанавливается одно ключевое слово в файле sshd_config:

/etc/hosts.equiv
~/.rhosts

Протокол SSH версии 2 не поддерживает этот метод. Вместо этого для лучшей защиты сети измените файл /etc/ssh/sshd_config (можно указывать как имена хостов, так и IP-адреса), а также сконфигурируйте файлы shosts.equiv и/или .shosts следующим образом:

/etc/shosts.equiv
~/.shosts

Чтобы разрешить использование среды доверенных узлов, задайте в файле the /etc/ssh/sshd_config следующие параметры для протокола SSH версии 2:

PermitEmptyPasswords yes
AllowSHosts remoteclient.com
DenySHosts

Например, если файл /etc/shosts.equiv настроен на сервере example.com следующим образом:

+remoteclient.com fsmythe
+secureserver.net sallyh
+192.168.100.12 fsmythe
-hackers.org james

то пользователю fsmythe разрешено выполнять аутентификацию на основе доверенных узлов, если он работает за удаленными компьютерами remoteclient.com, 192.168.100.12 и secureserver.net, пользователю sallyh разрешен доступ с компьютера secureserver.net, а пользователю james запрещен доступ с удаленного компьютера hackers.org.

Методы аутентификации на основе доверенных хостов и на основе SSH-ключей похожи и, в конечном счете, обеспечивают один и тот же результат. В таблице 1 приводится сравнение этих двух методов.

Таблица 1. Сравнение возможностей аутентификации на основе SSH-ключей и на основе доверенных узлов
Возможности SSHДоверенные узлыПубличный и открытый ключи
Аутентификация по IP-адресуДаДа
Аутентификация по имени хостаДаДа
Использование других возможностей открытого ключаНетДа
Аутентификация по имени удаленного пользователяДаНет
Использование групповых символов в именах хостов и IP-адресахНетДа
Необходимость использования парольной фразы для получения доступаНетНет
Сбои в случае изменения IP-адреса или имени хостаВ некоторых случаяхДа
Необходимость выполнения настроек как на сервере, так и на клиентеНетДа
Возможность использования для автоматизации задач, а также в командных сценарияхДаДа

Если вы являетесь одним из тех системных администраторов, у которых мысль о предоставлении беспарольного удаленного SSH-доступа в среде доверенных узлов вызывает усмешку, то обратите внимание на следующие недостатки использования ключей SSH в удалено выполняемых сценариях:

  • При изменении имени или IP-адреса хоста пара SSH-ключей перестанет работать, поскольку информация об известных хостах находится в кэше. В этом случае необходимо удалить из файла .ssh/known_hosts старую запись о хосте и заново поместить обновленную информацию в кэш. При возникновении такой ситуации все сценарии, использующие SSH-ключи, перестанут работать.
  • Аутентификация с использованием SSH-ключей требует настройки как на стороне клиента, так и на стороне сервера. Каждый раз при изменении открытого ключа или генерации новой пары ключей необходимо передавать новый открытый ключ на все удаленные компьютеры и обновлять файл authorized_keys.
  • При изменении прав доступа к папке .ssh/ (а также к файлам открытого или закрытого ключа) беспарольный SSH-доступ может перестать работать. Для отключения строгой проверки прав доступа к файлам и директориям отредактируйте файл /etc/ssh/sshd_config, задав для параметра StrictModes значение no.
  • Не существует централизованного способа отозвать ключ после того, как пара ключей была сгенерирована; также невозможно точно узнать, кому был передан ключ.

Заключение

SSH – это мощный и защищенный сетевой инструмент, используемый по всему миру для самых различных задач. SSH является безопасной, защищенной заменой таким открытым протоколам, как telnet, и командам группы r*, кроме того, существует ряд бесплатных клиентских и серверных SSH-приложений, что делает протокол SSH непревзойденным помощником. SSH широко используется в самых различных сетях для удаленного мониторинга, обслуживания и аудита систем, создания отчетов и автоматизации задач с помощью сценариев, из чего можно сделать вывод, что он останется с нами надолго, продолжая развиваться.


Ресурсы для скачивания


Похожие темы

  • Оригинал статьи: Getting started with SSH security and configuration (EN).
  • Ознакомьтесь с информацией о протоколе SSH, прочитав статью об SSH на страницах Википедии.
  • Загрузите OpenSSH (EN) – бесплатный пакет инструментов, заслуживший доверие технических специалистов, работающих в Интернете.
  • Узнайте об архитектуре протокола SSH из документа RFC 4251.
  • Узнайте обо всех подробностях OpenSSH, прочитав статью Гириша Венкатачалама (Girish Venkatachalam) The OpenSSH Protocol under the Hood (EN) (Linux Journal, апрель 2007 г.)
  • Дополнительную информацию о том, как защитить ваши серверы при помощи SSH, вы можете узнать из статьи Камерона Лэйрда (Cameron Laird) Server clinic: Connect securely with ssh (EN) (developerWorks, июль 2003 г.).
  • Прочитайте статью SSH and ssh-agent (EN), содержащую информацию и ссылки на загрузку инструментария компании Symantec.
  • Для получения дополнительной информации о рисках, связанных с использованием открытых ключей, ознакомьтесь с темой SSH public keys (EN) на Web-сайте serverfault.com.
  • В руководстве SSH tutorial for Linux (EN) Web-сайта suso.com описаны начальные шаги по работе с SSH в Linux-окружении.
  • В статье Five SSH tricks (EN) описаны пять приемов работы с SSH, о которых должен знать каждый.
  • В статье Top 20 OpenSSH Server Best Security Practices (EN) описаны 20 лучших приемов для защиты сервера.
  • Раздел AIX и UNIX портала developerWorks содержит большое количество материалов, посвященных администрированию AIX, которые помогут улучшить ваши навыки работы с UNIX.

Комментарии

Войдите или зарегистрируйтесь для того чтобы оставлять комментарии или подписаться на них.

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=AIX и UNIX
ArticleID=985044
ArticleTitle=Первые шаги по настройке и использованию SSH
publish-date=05092014