SSH

Материал из Xgu.ru

Перейти к: навигация, поиск
Автор: Игорь Чубин

Содержание

[править] Протокол SSH

[править] Что такое SSH

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

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

[править] Основные функции SSH

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

  • Безопасные команды доступа к хосту. SSH дает возможность выполнять безопасные команды доступа к хосту, такие как ssh (удаленная оболочка), slogin (удаленный вход в систему), scp (удаленное копирование);
  • X11 Forwarding. SSH предоставляет встроенный механизм для выполнения удаленных клиентов X Window.
  • Port forwarding. SSH может выполнять переадресацию портов, передавая трафик c одного порта одной машины на другой порт другой машины. При этом передаваемый трафик шифруется;


[править] Обеспечение безопасности SSH

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

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

[править] Аутентификация сервера

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

Note-icon.gif

Аутентификация сервера по протоколу SSH выполняется при помощи инфраструктуры открытых ключей. Открытый ключ сервера клиент получает при первом соединении с ним.

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

ssh защищает от

  • Подмены IP-адресов (IP-spoofing), когда удаленный хост посылает пакеты от имени другого хоста;
  • Подмены DNS-записей (DNS-spoofing), когда изменяется запись на сервере DNS и в результате соединение устанавливается не с желаемым хостом, а с тем, на который указывает новая запись;
  • Перехвата открытых паролей и прочих данных, которые передаются в открытом виде и любой, кто имеет физический доступ к каналу, может их узнать.


[править] Аутентификация клиента SSH

Методы аутентификации клиентов, которые использует SSH:

По хостам. Метод аналогичный используемому в r-командах. В том случае, если соединение устанавливается с привилегированного порта, и файл .rhosts позволяет вход в систему, он разрешается. Этот метод является потенциально небезопасным, рекомендуется не использовать его. Для повышения уровня своей безопасности метод может быть дополнен RSA-аутентификацией клиентского хоста.

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

Керберос. Аутентификация проводится по схеме v5 Kerberos.

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

[править] OpenSSH

[править] Сервер sshd

Как и в любом сетевом взаимодействии, в SSH-соединении участвуют две стороны: клиент и сервер. Сервер SSH реализован в виде программы sshd.

Сервер sshd является независимой программой, поэтому его запуск нужно производить во время загрузки компьютера стартовыми скриптами. То есть, вызов sshd либо должен осуществляться явно одним из rc-скриптов, либо ссылки на скрипт запуска следует включить в иерархию /etc/rc?.d/.

Note-icon.gif

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

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

[править] Настройка сервера sshd

Конфигурация демона определяется файлом /etc/ssh/sshd_config. Он представляет собой набор действующих строк, пустых строк и строк-комментариев. Действующие строки файла содержат название параметра и его значение. Например, строка

Port 22

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

  • Адреса. Интерфейс и порт, к которым привязан демон;
  • Журнализация. Опции, определяющие то, какая именно информация о работе демона должна регистрироваться и заноситься в журналы системы;
  • Управление ключами. Информация о том, в каких файлах находятся ключи, участвующие в аутентификации.
  • Аутентификация. Допустимые схемы аутентификации.
  • Дополнительные параметры. Опции, управляющие дополнительными функциями SSH, такими как переадресация портов, переадресация X11 и другие

Некоторые конфигурационные параметры могут быть переопределены опциями командной строки при вызове sshd.

Конфигурационный файл /etc/ssh/sshd_config.

Port 22                                 #[ssh.1]
HostKey /etc/ssh/ssh_host_key           #[ssh.2]  
HostKey /etc/ssh/ssh_host_rsa_key       
HostKey /etc/ssh/ssh_host_dsa_key       
KeyRegenerationInterval 3600             
ServerKeyBits 768                       #[ssh.3]
SyslogFacility AUTHPRIV                 #[ssh.4]
LogLevel INFO
LoginGraceTime 600                      #[ssh.5]
PermitRootLogin yes
StrictModes yes
RSAAuthentication yes                   #[ssh.6]
PubkeyAuthentication yes
RhostsAuthentication no                 
IgnoreRhosts yes
RhostsRSAAuthentication yes 
HostbasedAuthentication yes 
PasswordAuthentication yes              #[ssh.7]
PermitEmptyPasswords no
  • [ssh.1] Номер порта на котором демон sshd будет вести прослушивание. Стандартный порт -- 22.
  • [ssh.2] Файлы с закрытыми ключами, использующимися для аутентификации хоста.
  • [ssh.3] Длина ключа сервера. Минимальная 512. По умолчанию 768
  • [ssh.4] Информация о том, с каким приоритетом и с каким средством данные записываются в системный журнал Syslog.
  • [ssh.5] Разрывать соединение, если пользователь не вошел в систему в течение 600 секунд. Разрешать суперпользователю root удаленно регистрироваться в системе. Разрешать вход в систему, даже если права доступа к каталогу пользователя, разрешают всеобщий доступ на чтение и запись.
  • [ssh.6] Все виды аутентификации разрешены. Аутентификация, основывающаяся на .rhost запрещена.
  • [ssh.7] Пустые пароли запрещены.

[править] Клиент ssh

Программа ssh предназначена для регистрации на удаленном хосте с использование протокола ssh и удаленного выполнения команд. Кроме того ssh позволяет выполнять туннелирование любых TCP-соединений внутри ssh-канала (port forwarding).

Синтаксис программы ssh:

ssh опции хост пользователь@хост команда

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

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

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

Некоторые опции командной строки программы ssh

  • -v -- Выводить отладочную информацию о ходе процесса установки соединения. Настоятельно рекомендуется использовать ключ во время настройки службы.
  • -f -- Перейти в фоновый режим, сразу же после того, как пройден этап регистрации
  • -l пользователь -- Регистрироваться на удаленной системе как пользователь. Вместо ключа -l имяможно указывать перед именем хоста в форме пользователь@хост
  • -p порт -- Порт удаленного хоста, на котором доступен сервис SSH. По умолчанию используется порт 22.
  • -L порт:хост:хостпорт -- Перенаправить порт локального хоста на хостпорт удаленного хоста.
  • -R порт:хост:хостпорт -- Перенаправить порт удаленного локального хоста на хостпорт локального хоста.
  • -o опции -- Явно указать опции, которые перекрывают опции, заданные в конфигурационных файлах ssh.

[править] Пример использования клиента ssh

Для удаленной регистрации на компьютере green.lampoid.com нужно использовать команду:

user$ ssh green.lampoid.com 

Следует обратить внимание на то, что для входа на green.lampoid.com будет использоваться локальное имя пользователя user.

Если имя пользователя на удаленном хосте не совпадает с локальным именем, его нужно указать явно:

user$ ssh -l master green.lampoid.com 
user$ ssh master@green.lampoid.com 

Зарегистрироваться на удаленном компьютере green.lampoid.com под именем пользователя master. Обе команды эквивалентны.

Более сложный пример использования ssh, который может быть полезен для удаленного резервного копирования. Команда выполняет резервное копирование каталога /var компьютера cpu на компьютер hold в файл /backup/cpu.дата. Здесь дата -- текущая дата, выдаваемая командой date +"%d%m%Y".

$ssh backuper@cpu 'find /var -newer /var/.last.backup | \
 cpio -o -O backuper@hold:/backup/cpu.`date +"%d%m%Y"` ; 
 touch /var/.last.backup'

С текущего компьютера на компьютере cpu от имени пользователя backuper выполняется команда

find /var -newer /var/.last.backup | \
cpio -o -O backuper@hold:/backup/cpu.`date +"%d%m%Y"` ; 
touch /var/.last.backup

find выдает список файлов, которые изменились со времени создания последней резервной копии (времени модификации /var/.last.bakup). Все эти файлы программой cpio помещаются в один файл, который записывается на удаленную машину hold в каталог /backup/cpu. Программа cpio для передачи файла также использует ssh, хотя это и не указывается явно. После того, как резервное копирование выполнено, обновляется время модификации файла /var/.last.backup

[править] Аутентификация в SSH с помощью открытых ключей

[править] Создание и установка асимметричных ключей SSH

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

Секретные ключи хранятся в файлах identity, id_dsa и id_rsa в локальном каталоге ~/.ssh (разные файлы для разных алгоритмов шифрования). Открытые ключи должны быть в файлах authorized_keys и authorized_keys2 в каталоге ~/.ssh на удаленном компьютере, на котором производится регистрация. В качестве домашнего рассматривается каталог пользователя, под именем которого выполняется регистрация. Файл authorized_keys используется для хранения открытых ключей для SSH1, а в authorized_keys2 — для SSH2.

ssh дает возможность использования одного из трех различных алгоритмов асимметричного шифрования RSA или DSA.

Типы ключей

  • rsa1 -- Тип ключа RSA1, используемый в SSH версии 1
  • rsa -- Тип ключа RSA, используемый в SSH версии 2
  • dsa -- Тип ключа DSA, используемый в SSH версии 2


Для создания, преобразования и управления ключами аутентификации используется утилита ssh-keygen. Синтаксис программы:

ssh-keygen опции

Программа генерирует пару открытый ключ - секретный ключ. При этом она спрашивает, в какие файлы нужно записать ключи. По умолчанию секретный ключ записывается в ~/.ssh/identity (или ~/.ssh/id_rsa, ~/.ssh/id_dsa), а открытый в ~/.ssh/identity.pub.

Сгенерированный секретный ключ защищается при помощи парольной фразы (passphrase), которую нужно обязательно знать, для того чтобы воспользоваться ключом. Секретная фраза вводится в момент генерирования ключей. Она может быть затем изменена, без повторного копирования ключей.

Icon-caution.gif

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

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

$ cat ~/.ssh/identity.pub |  ssh user@host 'cat >> ~/.ssh/authorized_keys'
user@host's password:

Аналогично для второй версии SSH:

$ cat ~/.ssh/id_dsa.pub |  ssh user@host 'cat >> ~/.ssh/authorized_keys2'
user@host's password:

или воспользоваться утилитой ssh-copy-id

~/.ssh$ ssh-copy-id -i identity.pub user@host
user@host's password:

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

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

$ ssh user@host
Enter passphrase for key '/home/user/.ssh/id_rsa':

Некоторые опции командной строки программы ssh-keygen

  • -t тип -- Тип генерируемого ключа. Допустимые типы: rsa, rsa1 и dsa.
  • -p -- Изменить парольную фразу
  • -l -- Показать отпечаток (fingerprint) секретного ключа

[править] Опции ключа в ~/.ssh/authorized_keys

Для каждого открытого ключа в файлах ~/.ssh/authorized_keys можно выставить опции, ограничивающие возможности клиента, аутентифицировавшегося по данному ключу. Опции находятся перед ключем,

  • from="список-шаблонов-через-запятую" - разрешает принимать соединения только с хостов, удовлетворяющих одному из шаблонов. В качестве шаблонов поддерживаются символы - ?, * и !
  • command="команда" - при аутентификации по данному ключу разрешается запускать только указанную команду, а не то что указано пользователем - например, "echo this key disabled" или "dump -params" и обязательно использовать опцию no-pty для бинарной передачи данных
  • no-port-forwarding - запретить port-forwarding
  • no-X11-forwarding - запретить X11
  • no-user-rc - Запрещает выполнение файла ~/.ssh/rc после аутентификации (в RHEL не работает)
  • environment="NAME=VALUE" - Принудительная установка переменных среды окружения. (в RHEL не работает)
  • no-agent-forwarding - запретить использование agent-forwarding
  • no-pty - запретить интерактивную оболочку
  • permitopen="host:port" - (ограничить переназначение локального порта: ssh -L)

Пара примеров: первый - разрешается логин по ключу только с определенной подсети, за исключением хоста 192.168.1.2. второй - при логине выполняется дамп домашнего каталога, для примера указано как выставлять несколько опций одновременно (через запятую)

from="192.168.1.0/24,!192.168.1.2" ssh-rsa AAAAB2...AA== only for my network except !192.168.1.2
command="dump /home",no-pty,no-port-forwarding ssh-rsa AAAAC3...BF== key-for-dump home

[править] Управление ключами с помощью агента

Основная страница: Управление ключами SSH с помощью агента

[править] Удаленное копирование файлов

[править] scp

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

Синтаксис программы scp:

scp опции пользователь@хост1:файл1... пользователь@хост2:файл2

Команда устанавливает защищенное соединение между хостом1 и хостом2 и копирует файл1 хоста1 в файл2 хоста2. Любой из хостов может быть локальным. Если имя хоста не указано, подразумевается локальный хост.

Синтаксис использования команды scp напоминает синтаксис cp. Она так же обрабатывает большое количество аргументов, использует аналогичные ключи для рекурсивного копирования, для копирования атрибутов и т.д.

Опции программы scp

  • -r -- Выполнить рекурсивное копирование каталогов
  • -p -- Сохранить по возможности атрибуты файлов (права доступа, время модификации, время доступа) при копировании
  • -C -- Выполнять сжатие файлов при передаче
  • -P порт -- Соединяться с удаленным компьютером по порту порт
  • -v -- Сообщать отладочную информацию о ходе SSH-соединения
  • -q -- Не выдавать индикатор прогресса

Например с удаленного хоста source на локальный хост dest нужно скопировать домашний каталог пользователя batman. Команда выполняющая копирование будет выглядеть так:

dest$ scp -rp source:/home/batman /home
.login               100% |*****************************|   255       00:00    
.login_conf          100% |*****************************|   160       00:00    
.mailrc              100% |*****************************|   331       00:00    
.profile             100% |*****************************|   789       00:00    
.shrc                100% |*****************************|   852       00:00    
.mail_aliases        100% |*****************************|   371       00:00    
.cshrc               100% |*****************************|   771       00:00    

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

[править] rsync

Основная страница: rsync

[править] SFTP

WinSCP — один из клиентов SFTP под Windows
Основная страница: SFTP

SFTP (SSH File Transfer Protocol) — SSH-протокол для передачи файлов. Он предназначен для копирования и выполнения других операций с файлами поверх надёжного и безопасного соединения. Как правило, в качестве базового протокола, обеспечивающего соединение, и используется протокол SSH2, но это не обязательно.

SFTP-сервер встроен в OpenSSH. Он реализуется с помощью программы sftp-server. SFTP-клиент sftp встроен в пакет OpenSSH. В качестве SFTP-клиента для Windows может использоваться WinSCP или PSFTP из пакета PuTTY.

[править] Ограничение доступа только для копирования (rssh)

[править] Туннели SSH

[править] Перенаправление TCP-портов (port forwarding)

У SSH есть возможность, известная как перенаправление портов (port forwarding), которая позволяет передавать по SSH-соединению данные других протоколов. Перенаправление портов позволяет передать подключение, сделанное на одном конце SSH-соединения передать на другой конец и продолжить сеанс связи оттуда.

Другими словами, перенаправление портов SSH можно рассматривать как особую форму туннелирования TCP-соединений, когда SSH-клиент (или сервер; в зависимости от направления туннелирования; об этом ниже) прослушивает на одном хосте порт, и полученные на него соединения передаёт на вторую сторону, SSH-серверу (или клиенту, соответственно) внутри установленного SSH-соединения; вторая сторона инициирует соединение к серверу назначения уже от своего имени, и передаёт в нём полученные по туннелю данные.

Типичная задача, которая может решаться с помощью перенаправление TCP, это доступ к внутреннему серверу сети снаружи, через шлюз. Представьте, что у вас есть сеть, которая находится за UNIX-шлюзом, смотрящим в Интернет. У вас есть доступ к этому шлюзу по SSH. Вы находитесь в Интернете и хотите попасть на один из внутренних серверов сети, не имеет значения по какому протоколу, но пусть, например, по протоколу RDP. Возможности открыть порт при помощи трансляции адресов у вас на сервере нет (например, потому что у вас там нет прав root'а, а есть только доступ к оболочке).

Для решения такой задачи прекрасно подойдёт перенаправление TCP-порта с помощью SSH. Вы создаёте SSH-соединение на шлюз, внутри которого будет передавать трафик будущего соединения. Вы просите ssh выполнить перенаправление портов, в результате чего он открывает на прослушивание какой-либо локальный порт, обращение на который передаётся SSH-серверу на шлюз, который в свою очередь передаёт его серверу-получателю, то есть на RDP-сервер (причём делает это от своего имени; обратный адрес IP-пакетов будет адресом сервера).

Трафик внутри SSH-туннеля шифруется, поэтому перенапраление портов может быть очень полезным для шифрования данных незащищённых протоколов, например, POP3, или создания небольших виртуальных сетей. С другой стороны, нужно иметь в виду, что с помощью перенаправления портов легко организовать доступ изнутри сети наружу или наоборот, и не забывать об этом особенно при выделении учётных записей с доступом к облочке (по-русски говоря, шелла) на шлюзе (по сути, это равносильно предоставлению доступа ко внутренней сети снаружи).

Tip-icon.gif

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

Различают два вида перенаправления портов:

  • Локальное. Клиент принимает подключение и посылает запрос на инициирование соединения SSH-серверу, который в свою очередь устанавливает незащищённое соединение с адресатом;
  • Удаленное. Сервер принимает подключение и посылает запрос на инициирование соединения SSH-клиенту.

Фактически два этих режима отличаются только тем, с какой стороны будет инициироваться соединение: со стороны клиента или со стороны сервера.

Главным опциями, переводящими ssh в режим перенаправления портов являются -L (локальное перенаправление) и -R (удаленное перенаправление). Кроме того могут быть дополнительно полезны некоторые другие ключи.

Ключи ssh полезные при перенаправлении портов.

  • -L порт:хост:хостпорт — Выполнить локальное перенаправление портов. При обращении на порт локальной машины будет создан туннель на порт хостпорт указанного хоста.
  • -R порт:хост:хостпорт — Выполнить удалённое перенаправление. При обращении на порт удаленной машины будет создан SSH-туннель и соединение будет переадресовано на хостпорт указанного хоста.
  • -N — Не выполнять команду удалённо. Используется только при перенаправлении портов.
  • -f — Перейти в фоновый режим работы, сразу же после регистрации на удалённой системе.

Пример использования перенаправления TCP-портов средствами SSH для организации безопасного использования POP3.

Для того чтобы при использовании протокола POP3 пароль не передавался в открытом виде можно настроить перенаправление портов. Для этого нужно запустить ssh с дополнительными ключами:

$ ssh -N -f -L 1100:mailserver.example.com:110 you@mailserver.example.com

При этом будет создано безопасное SSH соединение с сервером mailserve.example.com. Данные поступающие на 1100 порт локального хоста будут передаваться на 110 порт хоста mailserver.example.com.

Для создания соединения используется учетная запись you на хосте mailserver.example.com, так что нужно иметь такое имя регистрации на нем.

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

При работе в PuTTY также можно настроить перенаправление. Для этого нужно зайти в ветку SSH -> Tunnels и ПЕРЕД установлением соединения добавить необходимые параметры. Неплохое описание есть здесь, и подробное во встроенной помощи самого PuTTY.

[править] Создание IP-каналов (PPP поверх SSH)

[править] SSH через HTTP-прокси

Для этого необходимо чтобы на прокси-сервере был разрешён метод CONNECT. Обычно он разрешён как минимум на 443 порт. Если SSH-сервер с той стороны прокси работает на 443 порту, то обратиться на него через SSH не составит никакого труда. Существует несколько программ для этого, самая популярная — corkskrew.

После того как программа установлена, можно добавить в ~/.ssh/config такие строки:

Host *
  ProxyCommand corkscrew http-proxy.example.com 8080 %h %p

Обращения на все хосты будут выполняться теперь через прокси http-proxy.example.com (порт 8080).

[править] SSH в Windows

[править] SSH-клиенты для Windows

[править] putty

[править] securecrt

[править] telneat

[править] SSH-серверы для Windows

[править] Интересные вопросы использования SSH

[править] SSH и обратное преобразование DNS

Hey! When I haven't logged on to a Xen VM for a while the login process by SSH is strangely slow - the login prompt appears fast but the password prompt is dalayed for around a minute... Can that issue be related to some Xen setting somehow? The same behavior shows when trying to connect to the VM on any other port...

Itamar Reis Peixoto wrote:                                                                                                                   
>try to edit /etc/ssh/sshd_config                                                                                                            
>                                                                                                                                            
>and change UseDNS to NO                                                                                                                     
>                                                                                                                                            
>restart ssh server                                                                                                                          
>                                                                                                                                            
>--------------------                                                                                                                        
>                                                                                                                                            
>Itamar Reis Peixoto                                                                                                                         
>                                                                                                                                            
Unfortunately, that argument doesn't do what you think it does.  And it                                                                      
confuses a lot of people!                                                                                                                    

Here's the situation at least up through OpenSSH 3.9p1.

OpenSSH, for logging purposes, does a reverse DNS on any contacting IP address. The UseDNS option says whether to verify that the reverse DNS matches a valid forward DNS for that host. But disabling UseDNS does

  • NOT, NOT, NOT* turn off the reverse DNS lookup! Any number of us have

submitted patches for this over the years: I submitted some when I dealt with large remotely deployed networks. (When you manage thousands of machines deployed in data centers all over the world, you can be absolutely certain a lot of them will not have valid reverse DNS, or even have DNS working properly, and you need to be able to log in quickly in a crunch.)

The option you need is in your sshd init script. You need to use the additional options "-u 0", to set the namelength of the recorded DNS entry to 0 so that the reverse DNS isn't actually done. (Why the SSH authors think setting an arglength to 0 should cause undocumented behavior and not throw an error, instead of obeying the UseDNS option in the configuraton file more correctly, I leave to people who think the "chroot" option of OpenSSH actually means a chroot cage for SSH users to protect them from accessing the filesystem outside their home directory. It doesn.t.)

I like OpenSSH, I use it a lot, but I've disagreed volubly with the authors on a few points over the years. This is one of them.

[править] Приглашение парольной аутентификации

http://marc.info/?l=secure-shell&m=113029399310577&w=2

[править] Хранение открытых ключей в SSH

«иногда сложно пояснить человеку, что нужно написать yes»

http://www.debian-administration.org/articles/503


[править] Удаление скомпрометированных ключей

Удалить скомпрометированные ключи (допустим, для хоста 192.168.15.1):

ssh-keygen -R 192.168.15.1

[править] Автоматическое подключение к запущенном агенту

В ~/.bash_profile добавить:

load_agent()
{
  ssh-agent > ~/.ssh-agent
  eval `< ~/.ssh-agent`
  ssh-add 
}

if [ -e ~/.ssh-agent ] 
then 
 eval `cat ~/.ssh-agent` 
 grep -q ssh-agent /proc/$SSH_AGENT_PID/cmdline >& /dev/null || load_agent
else
 load_agent 
fi

l3-agent
. ~/.bashrc

[править] Как автоматизировать ввод пароля при подключении по SSH?

Используем pxssh из pexpect:

import pxssh
s = pxssh.pxssh()
if not s.login ('localhost', 'myusername', 'mypassword'):
    print "SSH session failed on login."
    print str(s)
else:
    print "SSH session login successful"
    s.sendline ('ls -l')
    s.prompt()         # match the prompt
    print s.before     # print everything before the prompt.
    s.logout()

(спасибо [1] Stackoverflow.png).

[править] Как разрешить выполнение только одной команды при подключении по SSH?

Для этого в ~/.ssh/authorized_keys нужно указать команду перед ключом, разрешающим подключение:

command="path/to/hg-wrapper",no-pty ssh-rsa SSH-KEY-HERE....

В этом примере разрешается только выполняется скрипта hg-wrapper. Это может быть нужно для того чтобы ограничить пользователя только возможностью доступа к репозиторию по SSH, но не к программной оболочке сервера.

Сам скрипт в данном случае выглядит так:

#!/usr/bin/env python
import os
import re
r = re.compile('^hg -R (S%2B) serve --stdio$')
match = re.search(r, os.environ['SSH_ORIGINAL_COMMAND'])
if match:
    repo_path = match.groups()[0]
    if os.path.exists(repo_path):
        os.execvp('hg', ['hg', '-R', repo_path, 'serve', '--stdio'])

Источник: Restrict SSH access to use only mercurial (англ.)

Естественно, что таким образом можно ограничивать доступ к любым программам.

[править] Дополнительная информация

  • RFC4251 Архитектура протокола SSH (перевод)
  • SSHMenu — апплет для панели Gnome
  • SSH Programming with Paramiko (англ.) --- Использование реализации SSH в Python

[править] Материалы по SSH на xgu.ru

Источник — «http://xgu.ru/wiki/SSH»