ssh — клиент удаленного входа OpenSSH
СИНТАКСИС
ssh [-46AaCfGgKkMNnqsTtVvXxYy] [-B bind_interface] [-b bind_address] [-c cipher_spec]
[-D [bind_address:]port] [-E log_file] [-e escape_char] [-F configfile] [-I pkcs11]
[-i identity_file] [-J destination] [-L address] [-l login_name] [-m mac_spec] [-O ctl_cmd]
[-o option] [-P tag] [-p port] [-R address] [-S ctl_path] [-W host:port]
[-w local_tun[:remote_tun]] destination [command [argument ...]]
ssh [-Q query_option]
ОПИСАНИЕ
ssh (клиент SSH) — это программа для входа на удаленную машину и выполнения команд на удаленной машине. Она предназначена для обеспечения безопасной зашифрованной связи между двумя недоверенными хостами по незащищенной сети. X11-соединения и произвольные TCP-порты и сокеты Unix также могут передаваться по защищенному каналу.
ssh подключается и входит в указанное место назначения, которое может быть указано либо как [user@]hostname, либо в виде URI в форме ssh://[user@]hostname[:port]. Пользователь должен подтвердить свою личность на удаленной машине, используя один из нескольких методов (см. ниже).
Если указана команда, она будет выполнена на удаленном хосте вместо входной оболочки. Полная командная строка может быть указана как команда, или она может иметь дополнительные аргументы. Если указаны, аргументы будут добавлены к команде, разделенные пробелами, прежде чем она будет отправлена на сервер для выполнения.
Параметры следующие:
-4 Принудительно использует только IPv4-адреса.
-6 Принудительно использует только IPv6-адреса.
-A Включает перенаправление соединений из агента аутентификации, такого как ssh-agent(1).
Это также можно указать для каждого хоста в файле конфигурации.
Перенаправление агента следует включать с осторожностью. Пользователи, имеющие возможность обходить разрешения файлов на удаленном хосте (для Unix-доменного сокета агента), могут получить доступ к локальному агенту через перенаправленное соединение. Злоумышленник не может получить исходный материал ключа из агента, однако он может выполнять операции с ключами, которые позволяют ему проходить аутентификацию, используя учетные данные, загруженные в агент. Более безопасной альтернативой может быть использование промежуточного хоста (см. -J).
-a Отключает перенаправление соединения агента аутентификации.
-B bind_interface
Привязывается к адресу bind_interface, прежде чем пытаться подключиться к хосту назначения. Это полезно только в системах с более чем одним адресом.
-b bind_address
Использует bind_address в локальной машине в качестве исходного адреса соединения. Это полезно только в системах с более чем одним адресом.
-C Запрашивает сжатие всех данных (включая stdin, stdout, stderr и данные для перенаправленных
X11, TCP и Unix-domain соединений). Алгоритм сжатия тот же, что и в [gzip]({filename}../../gzip)(1). Сжатие желательно для модемных соединений и других медленных сетей, но замедлит работу в быстрых сетях. Значение по умолчанию можно установить для каждого хоста в файлах конфигурации; см. опцию «Compression» в ssh_config(5).
-c cipher_spec
Выбирает спецификацию шифра для шифрования сеанса. cipher_spec — это список шифров, разделенных запятыми, в порядке предпочтения. См. ключевое слово «Ciphers» в ssh_config(5) для получения дополнительной информации.
-D [bind_address:]port
Указывает локальный «динамический» порт перенаправления на уровне приложений. Это работает путем выделения сокета для прослушивания порта на локальной стороне, опционально привязанного к указанному адресу bind_address. Когда к этому порту устанавливается соединение, соединение перенаправляется через защищенный канал, и затем протокол приложения используется для определения того, к чему подключаться на удаленной машине. В настоящее время поддерживаются протоколы SOCKS4 и SOCKS5, и ssh будет действовать как SOCKS-сервер. Только root может перенаправлять привилегированные порты. Динамические перенаправления портов также могут быть указаны в файле конфигурации.
IPv6-адреса можно указывать, заключая адрес в квадратные скобки. Только пользователь с правами суперпользователя может перенаправлять привилегированные порты. По умолчанию локальный порт привязывается в соответствии с настройкой «GatewayPorts». Однако можно использовать явный адрес bind_address, чтобы привязать соединение к определенному адресу. Адрес bind_address «localhost» указывает, что порт прослушивания должен быть привязан только для локального использования, в то время как пустой адрес или «*» указывает, что порт должен быть доступен со всех интерфейсов.
-E log_file
Добавляет отладочные сообщения в файл log_file вместо стандартного вывода ошибок.
-e escape_char
Задает символ экранирования для сеансов с псевдотерминалом (по умолчанию: «\~»). Символ экранирования распознается только в начале строки. Символ экранирования, за которым следует точка («.»), закрывает соединение; за которым следует Control-Z, приостанавливает соединение; а за которым следует сам символ экранирования, отправляет символ экранирования один раз. Установка символа на «none» отключает все экранирования и делает сеанс полностью прозрачным.
-F configfile
Указывает альтернативный файл конфигурации для каждого пользователя. Если файл конфигурации указан в командной строке, системный файл конфигурации (/etc/ssh/ssh_config) игнорируется. По умолчанию для файла конфигурации для каждого пользователя используется ~/.ssh/config. Если установлено значение «none», файлы конфигурации не будут считываться.
-f Запускает ssh в фоновом режиме непосредственно перед выполнением команды. Это полезно, если ssh собирается запрашивать пароли или фразы, но пользователь хочет, чтобы он работал в фоновом режиме. Это подразумевает -n. Рекомендуемый способ запуска программ X11 на удаленном сайте — это что-то вроде ssh -f host xterm.
Если параметр конфигурации ExitOnForwardFailure установлен в значение «yes», то клиент, запущенный с флагом -f, будет ждать, пока все удаленные перенаправления портов не будут успешно установлены, прежде чем переходить в фоновый режим. Обратитесь к описанию ForkAfterAuthentication в ssh_config(5) для получения подробной информации.
-G Заставляет ssh вывести свою конфигурацию после оценки блоков `Host` и `Match` и завершить работу.
-g Разрешает удаленным хостам подключаться к локальным перенаправленным портам. Если используется на мультиплексированном соединении, этот параметр должен быть указан в основном процессе.
-I pkcs11
Указывает, какую общую библиотеку PKCS#11 следует использовать ssh для связи с токеном PKCS#11, предоставляющим ключи для аутентификации пользователя.
-i identity_file
Выбирает файл, из которого считывается идентификатор (приватный ключ) для аутентификации по открытому ключу. Также можно указать файл открытого ключа, чтобы использовать соответствующий приватный ключ, загруженный в ssh-agent(1), когда файл приватного ключа отсутствует локально. По умолчанию используются ~/.ssh/id_rsa, ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsa_sk, ~/.ssh/id_ed25519 и ~/.ssh/id_ed25519_sk. Файлы идентификаторов также могут быть указаны для каждого хоста в файле конфигурации. Возможно указать несколько параметров -i (и несколько идентификаторов в файлах конфигурации). Если сертификаты не были явно указаны директивой CertificateFile, ssh также попытается загрузить информацию о сертификате из файла, имя которого получается путем добавления -cert.pub к именам файлов идентификаторов.
-J destination
Подключается к целевому хосту, сначала устанавливая соединение ssh с промежуточным хостом, указанным в destination, а затем устанавливая TCP-туннель к конечному пункту назначения оттуда. Можно указать несколько промежуточных хопов, разделенных запятыми. IPv6-адреса можно указывать, заключая адрес в квадратные скобки. Это сокращенный способ указать директиву конфигурации ProxyJump. Обратите внимание, что директивы конфигурации, указанные в командной строке, обычно применяются к конечному хосту, а не к указанным промежуточным хостам. Используйте ~/.ssh/config для указания конфигурации для промежуточных хостов.
-K Включает GSSAPI-аутентификацию и пересылку (делегирование) учетных данных GSSAPI на сервер.
-k Отключает пересылку (делегирование) учетных данных GSSAPI на сервер.
-L [bind_address:]port:host:hostport
-L [bind_address:]port:remote_socket
-L local_socket:host:hostport
-L local_socket:remote_socket
Указывает, что соединения с указанным TCP-портом или Unix-соккетом на локальном (клиентском) хосте должны быть перенаправлены на указанный хост и порт или Unix-сокет на удаленной стороне. Это работает путем выделения сокета для прослушивания либо TCP-порта на локальной стороне, опционально привязанного к указанному адресу bind_address, либо Unix-сокета. Каждый раз, когда соединение устанавливается с локальным портом или сокетом, соединение перенаправляется по защищенному каналу, и соединение устанавливается либо с хостом и портом host:hostport, либо с Unix-соккетом remote_socket на удаленной машине.
Перенаправление портов также можно указать в файле конфигурации. Только суперпользователь может перенаправлять привилегированные порты. IPv6-адреса можно указывать, заключая адрес в квадратные скобки.
По умолчанию локальный порт привязывается в соответствии с настройкой GatewayPorts. Однако можно использовать явный bind_address, чтобы привязать соединение к определенному адресу. bind_address со значением «localhost» указывает, что прослушивающий порт должен быть привязан только для локального использования, в то время как пустой адрес или «*» указывает, что порт должен быть доступен со всех интерфейсов.
-l `login_name`
Указывает имя пользователя, под которым следует войти в систему на удаленной машине. Это также можно указать для каждой отдельной машины в файле конфигурации.
-M Помещает клиент ssh в «главный» режим для совместного использования соединений. Несколько опций -M помещают ssh в «главный» режим, но требуют подтверждения с помощью `ssh-askpass(1)` перед каждой операцией, изменяющей состояние мультиплексирования (например, при открытии нового сеанса). См. описание `ControlMaster` в `ssh_config(5)` для получения подробной информации.
-m `mac_spec`
Список алгоритмов MAC (кода аутентификации сообщений), разделенных запятыми, указанный в порядке предпочтения. См. ключевое слово `MACs` в `ssh_config(5)` для получения дополнительной информации.
-N Не выполнять удаленную команду. Это полезно только для перенаправления портов. См. описание `SessionType` в `ssh_config(5)` для получения подробной информации.
-n Перенаправляет стандартный ввод из `/dev/null` (фактически предотвращает чтение из стандартного ввода). Это необходимо при запуске ssh в фоновом режиме. Распространенный прием — использовать это для запуска программ X11 на удаленной машине. Например, `ssh -n shadows.cs.hut.fi emacs &` запустит emacs на `shadows.cs.hut.fi`, и соединение X11 будет автоматически перенаправлено по зашифрованному каналу. Программа ssh будет помещена в фоновый режим. (Это не работает, если ssh необходимо запросить пароль или парольную фразу; см. также опцию -f.) См. описание `StdinNull` в `ssh_config(5)` для получения подробной информации.
-O `ctl_cmd`
Управляет активным процессом мультиплексирования соединения. При указании опции -O аргумент `ctl_cmd` интерпретируется и передается главному процессу. Допустимые команды: «check» (проверить, работает ли главный процесс), «forward» (запросить перенаправление без выполнения команды), «cancel» (отменить перенаправление), «proxy» (подключиться к работающему главному процессу мультиплексирования в режиме прокси), «exit» (запросить у главного процесса выход) и «stop» (запросить у главного процесса прекращение приема дальнейших запросов на мультиплексирование).
-o `option`
Может использоваться для передачи опций в формате, используемом в файле конфигурации. Это полезно для указания опций, для которых нет отдельного флага командной строки. Для получения полной информации об опциях, перечисленных ниже, и их возможных значениях см. `ssh_config(5)`.
AddKeysToAgent
AddressFamily
BatchMode
BindAddress
BindInterface
CASignatureAlgorithms
CanonicalDomains
CanonicalizeFallbackLocal
CanonicalizeHostname
CanonicalizeMaxDots
CanonicalizePermittedCNAMEs
CertificateFile
ChannelTimeout
CheckHostIP
Ciphers
ClearAllForwardings
Compression
ConnectTimeout
ConnectionAttempts
ControlMaster
ControlPath
ControlPersist
DynamicForward
EnableEscapeCommandline
EnableSSHKeysign
EscapeChar
ExitOnForwardFailure
FingerprintHash
ForkAfterAuthentication
ForwardAgent
ForwardX11
ForwardX11Timeout
ForwardX11Trusted
GSSAPIAuthentication
GSSAPIKeyExchange
GSSAPIClientIdentity
GSSAPIDelegateCredentials
GSSAPIKexAlgorithms
GSSAPIRenewalForcesRekey
GSSAPIServerIdentity
GSSAPITrustDns
GatewayPorts
GlobalKnownHostsFile
HashKnownHosts
Host
HostKeyAlgorithms
HostKeyAlias
HostbasedAcceptedAlgorithms
HostbasedAuthentication
Hostname
IPQoS
IdentitiesOnly
IdentityAgent
IdentityFile
IgnoreUnknown
Include
KbdInteractiveAuthentication
KbdInteractiveDevices
KexAlgorithms
KnownHostsCommand
LocalCommand
LocalForward
LogLevel
LogVerbose
MACs
NoHostAuthenticationForLocalhost
NumberOfPasswordPrompts
ObscureKeystrokeTiming
PKCS11Provider
PasswordAuthentication
PermitLocalCommand
PermitRemoteOpen
Port
PreferredAuthentications
ProxyCommand
ProxyJump
ProxyUseFdpass
PubkeyAcceptedAlgorithms
PubkeyAuthentication
RekeyLimit
RemoteCommand
RemoteForward
RequestTTY
RequiredRSASize
RevokedHostKeys
SecurityKeyProvider
SendEnv
ServerAliveCountMax
ServerAliveInterval
SessionType
SetEnv
StdinNull
StreamLocalBindMask
StreamLocalBindUnlink
StrictHostKeyChecking
SyslogFacility
TCPKeepAlive
Tag
Tunnel
TunnelDevice
UpdateHostKeys
User
UserKnownHostsFile
VerifyHostKeyDNS
VisualHostKey
XAuthLocation
-P tag Укажите имя тега, который можно использовать для выбора конфигурации в ssh_config(5).
См. ключевые слова Tag и Match в ssh_config(5) для получения дополнительной информации.
-p port
Port: порт для подключения к удаленному хосту. Это можно указать для каждого хоста в файле конфигурации.
-Q query_option
Запросы алгоритмов, поддерживаемых одной из следующих функций: cipher (поддерживаемые симметричные шифры), cipher-auth (поддерживаемые симметричные шифры, поддерживающие аутентифицированное шифрование), help (поддерживаемые термины запросов для использования с флагом -Q), mac (поддерживаемые коды целостности сообщений), kex (алгоритмы согласования ключей), kex-gss (алгоритмы согласования ключей GSSAPI), key (типы ключей), key-ca-sign (допустимые алгоритмы подписи CA для сертификатов), key-cert (типы ключей сертификатов), key-plain (несертификатные типы ключей), key-sig (все типы ключей и алгоритмы подписи), protocol-version (поддерживаемые версии протокола SSH) и sig (поддерживаемые алгоритмы подписи). Кроме того, любое ключевое слово из ssh_config(5) или sshd_config(5), которое принимает список алгоритмов, может использоваться в качестве псевдонима для соответствующего параметра query_option.
-q Режим тишины. Подавляет большинство предупреждающих и диагностических сообщений.
-R [bind_address:]port:host:hostport
-R [bind_address:]port:local_socket
-R remote_socket:host:hostport
-R remote_socket:local_socket
-R [bind_address:]port
Указывает, что подключения к указанному TCP-порту или Unix-сокету на удаленном (серверном) хосте должны перенаправляться на локальную сторону.
Это работает путем выделения сокета для прослушивания либо TCP-порта, либо Unix-сокета на удаленной стороне. Каждый раз, когда устанавливается соединение с этим портом или Unix-сокетом, соединение перенаправляется через защищенный канал, и устанавливается соединение с локальной машины либо к явно указанному назначению с помощью host:port, либо local_socket, или, если явно указанное назначение не было указано, ssh будет действовать как SOCKS 4/5 прокси и перенаправлять соединения к местам назначения, запрошенным удаленным SOCKS-клиентом.
Перенаправления портов также могут быть указаны в файле конфигурации. Привилегированные порты могут быть перенаправлены только при входе в систему от имени root на удаленной машине. IPv6-адреса могут быть указаны путем заключения адреса в квадратные скобки.
По умолчанию TCP-сокеты прослушивания на сервере будут привязаны только к локальному интерфейсу. Это можно переопределить, указав bind_address. Пустой bind_address или адрес ‘*’ указывают на то, что удаленный сокет должен прослушивать все интерфейсы. Указание удаленного bind_address будет успешным только в том случае, если на сервере включен параметр GatewayPorts (см. sshd_config(5)).
Если аргумент port равен ‘0’, порт прослушивания будет динамически выделен на сервере и сообщен клиенту во время выполнения. При использовании вместе с -O forward, выделенный порт будет напечатан в стандартный вывод.
-S ctl_path
Указывает расположение управляющего сокета для совместного использования соединений или строку «none», чтобы отключить совместное использование соединений. Обратитесь к описанию ControlPath и ControlMaster в ssh_config(5) для получения подробной информации.
-s Может использоваться для запроса вызова подсистемы на удаленной системе. Подсистемы облегчают использование SSH в качестве безопасного транспорта для других приложений (например, [sftp]({filename}../../sftp)(1)). Подсистема указывается как удаленная команда. Обратитесь к описанию SessionType в ssh_config(5) для получения подробной информации.
-T Отключает выделение псевдотерминала.
-t Принудительно выделяет псевдотерминал. Это можно использовать для выполнения произвольных программ с экранным интерфейсом на удаленной машине, что может быть очень полезно, например, при реализации служб меню. Несколько опций -t принудительно выделяют tty, даже если у ssh нет локального tty.
-V Отображает номер версии и завершает работу.
-v Подробный режим. Заставляет ssh печатать отладочные сообщения о ходе выполнения. Это полезно для отладки проблем с подключением, аутентификацией и конфигурацией. Несколько опций -v увеличивают подробность. Максимум — 3.
-W host:port
Запрашивает перенаправление стандартного ввода и вывода клиента на хост по указанному порту через защищенный канал. Подразумевает использование опций -N, -T, ExitOnForwardFailure и ClearAllForwardings, хотя их можно переопределить в файле конфигурации или с помощью опций командной строки -o.
-w local_tun[:remote_tun]
Запрашивает перенаправление устройств туннеля с использованием указанных устройств tun(4) между клиентом (local_tun) и сервером (remote_tun).
Устройства могут быть указаны числовым идентификатором или ключевым словом «any», которое использует следующее доступное устройство туннеля. Если remote_tun не указан, он по умолчанию устанавливается в «any». См. также директивы Tunnel и TunnelDevice в ssh_config(5).
Если директива Tunnel не задана, она будет установлена в режим туннелирования по умолчанию, который является «точка-точка». Если требуется другой режим перенаправления туннеля, его следует указать перед опцией -w.
-X Включает перенаправление X11. Это также можно указать для каждого хоста в файле конфигурации.
Перенаправление X11 следует включать с осторожностью. Пользователи, имеющие возможность обходить разрешения на файлы на удаленном хосте (для базы данных авторизации X пользователя), могут получить доступ к локальному X11-дисплею через перенаправленное соединение. В результате злоумышленник может выполнять такие действия, как мониторинг нажатий клавиш.
По этой причине перенаправление X11 по умолчанию подвергается ограничениям расширения X11 SECURITY. См. опцию ssh -Y и директиву ForwardX11Trusted в ssh_config(5) для получения дополнительной информации.
(Специфично для Debian: перенаправление X11 не подвергается ограничениям расширения X11 SECURITY по умолчанию, поскольку слишком много программ в настоящее время вызывают сбой в этом режиме. Установите опцию ForwardX11Trusted в значение «no», чтобы восстановить поведение, предусмотренное разработчиками. Это может измениться в будущем в зависимости от улучшений на стороне клиента.)
-x Отключает перенаправление X11.
-Y Включает доверенное перенаправление X11. Доверенное перенаправление X11 не подвергается ограничениям расширения X11 SECURITY.
(Специфично для Debian: в конфигурации по умолчанию эта опция эквивалентна -X, поскольку ForwardX11Trusted по умолчанию имеет значение «yes», как описано выше. Установите опцию ForwardX11Trusted в значение «no», чтобы восстановить поведение, предусмотренное разработчиками. Это может измениться в будущем в зависимости от улучшений на стороне клиента.)
-y Отправляет информацию журнала с помощью системного модуля syslog(3). По умолчанию эта информация отправляется в stderr.
ssh может дополнительно получать данные конфигурации из файла конфигурации для каждого пользователя и общесистемного файла конфигурации. Формат файла и параметры конфигурации описаны в ssh_config(5).
АУТЕНТИФИКАЦИЯ
Клиент OpenSSH SSH поддерживает протокол SSH версии 2.
Доступные методы аутентификации: аутентификация на основе GSSAPI, аутентификация на основе хоста, аутентификация с использованием открытого ключа, интерактивная аутентификация с клавиатуры и аутентификация с использованием пароля. Методы аутентификации пытаются применяться в указанном порядке, хотя PreferredAuthentications можно использовать для изменения порядка по умолчанию.
Аутентификация на основе хоста работает следующим образом: если машина, с которой пользователь входит в систему, указана в файлах /etc/hosts.equiv или /etc/ssh/shosts.equiv на удаленной машине, пользователь не является пользователем с правами root, и имена пользователей на обеих сторонах совпадают, или если файлы ~/.rhosts или ~/.shosts существуют в домашней директории пользователя на удаленной машине и содержат строку с именем клиентской машины и именем пользователя на этой машине, то пользователь считается авторизованным для входа. Кроме того, сервер должен иметь возможность проверить ключ хоста клиента (см. описание файлов /etc/ssh/ssh_known_hosts и ~/.ssh/known_hosts ниже), чтобы разрешить вход в систему. Этот метод аутентификации устраняет уязвимости, связанные с подменой IP-адреса, DNS и маршрутизации.
[Примечание для администратора: /etc/hosts.equiv, ~/.rhosts и протокол rlogin/rsh в целом являются принципиально небезопасными и должны быть отключены, если требуется обеспечить безопасность.]
Аутентификация с использованием открытого ключа работает следующим образом: схема основана на криптографии с открытым ключом, использующей криптосистемы, в которых шифрование и дешифрование выполняются с использованием разных ключей, и практически невозможно получить ключ дешифрования из ключа шифрования. Идея заключается в том, что каждый пользователь создает пару открытый/закрытый ключ для целей аутентификации. Сервер знает открытый ключ, а пользователь знает только закрытый ключ. ssh автоматически реализует протокол аутентификации с открытым ключом, используя один из алгоритмов ECDSA, Ed25519 или RSA.
Файл ~/.ssh/authorized_keys содержит список открытых ключей, которым разрешено входить в систему. Когда пользователь входит в систему, программа ssh сообщает серверу, какую пару ключей он хотел бы использовать для аутентификации. Клиент доказывает, что у него есть доступ к закрытому ключу, и сервер проверяет, что соответствующий открытый ключ авторизован для предоставления доступа к учетной записи.
Сервер может сообщить клиенту об ошибках, которые помешали успешной аутентификации с использованием открытого ключа после завершения аутентификации другим методом. Их можно просмотреть, увеличив уровень регистрации до DEBUG или выше (например, с помощью флага -v).
Пользователь создает свою пару ключей, выполнив команду ssh-keygen(1). Это сохраняет закрытый ключ в файлах ~/.ssh/id_ecdsa (ECDSA), ~/.ssh/id_ecdsa_sk (ECDSA с аутентификатором), ~/.ssh/id_ed25519 (Ed25519), ~/.ssh/id_ed25519_sk (Ed25519 с аутентификатором) или ~/.ssh/id_rsa (RSA) и сохраняет открытый ключ в файлах ~/.ssh/id_ecdsa.pub (ECDSA), ~/.ssh/id_ecdsa_sk.pub (ECDSA с аутентификатором), ~/.ssh/id_ed25519.pub (Ed25519), ~/.ssh/id_ed25519_sk.pub (Ed25519 с аутентификатором) или ~/.ssh/id_rsa.pub (RSA) в домашней директории пользователя. Затем пользователь должен скопировать открытый ключ в файл ~/.ssh/authorized_keys в своей домашней директории на удаленной машине. Файл authorized_keys соответствует традиционному файлу ~/.rhosts и содержит по одному ключу на строку, хотя строки могут быть очень длинными. После этого пользователь может войти в систему без ввода пароля.
Существует вариант аутентификации по открытому ключу в виде аутентификации по сертификатам: вместо набора открытых/закрытых ключей используются подписанные сертификаты. Это имеет то преимущество, что вместо множества пар открытых/закрытых ключей можно использовать один доверенный центр сертификации. Подробную информацию см. в разделе CERTIFICATES руководства ssh-keygen(1).
Наиболее удобный способ использования аутентификации по открытому ключу или сертификату — это использование агента аутентификации. Подробную информацию см. в ssh-agent(1) и (необязательно) в директиве AddKeysToAgent в ssh_config(5).
Интерактивная аутентификация с клавиатуры работает следующим образом: сервер отправляет произвольный текст "запроса" и запрашивает ответ, возможно, несколько раз. Примеры интерактивной аутентификации с клавиатуры включают аутентификацию BSD (см. login.conf(5)) и PAM (на некоторых системах, отличных от OpenBSD).
Наконец, если другие методы аутентификации не удались, ssh запрашивает у пользователя пароль. Пароль отправляется на удаленный хост для проверки; однако, поскольку вся связь зашифрована, пароль не может быть просмотрен кем-либо, прослушивающим сеть.
ssh автоматически поддерживает и проверяет базу данных, содержащую информацию обо всех хостах, с которыми он когда-либо использовался. Ключи хостов хранятся в ~/.ssh/known_hosts в домашнем каталоге пользователя. Кроме того, автоматически проверяется файл /etc/ssh/ssh_known_hosts на наличие известных хостов. Любые новые хосты автоматически добавляются в файл пользователя. Если идентификатор хоста когда-либо изменится, ssh предупреждает об этом и отключает аутентификацию по паролю, чтобы предотвратить подмену сервера или атаки типа "человек посередине", которые в противном случае могут быть использованы для обхода шифрования. Опция StrictHostKeyChecking может быть использована для управления входом в машины, ключ хоста которых неизвестен или изменился.
Когда личность пользователя подтверждена сервером, сервер либо выполняет данную команду в неинтерактивном сеансе, либо, если команда не указана, выполняет вход в машину и предоставляет пользователю обычную оболочку в интерактивном сеансе. Вся связь с удаленной командой или оболочкой будет автоматически зашифрована.
Если запрошен интерактивный сеанс, по умолчанию ssh будет запрашивать псевдотерминал (pty) только для интерактивных сеансов, когда у клиента есть терминал. Флаги -T и -t могут быть использованы для изменения этого поведения.
Если был выделен псевдотерминал, пользователь может использовать символы экранирования, указанные ниже.
Если псевдотерминал не выделен, сеанс является прозрачным и может быть использован для надежной передачи двоичных данных. В большинстве систем установка символа экранирования в "none" также сделает сеанс прозрачным, даже если используется tty.
Сеанс завершается, когда команда или оболочка на удаленной машине завершают работу и все X11 и TCP-соединения закрыты.
СИМВОЛЫ ЭСКАПИРОВАНИЯ
Когда запрошен псевдотерминал, ssh поддерживает ряд функций с помощью символа эскапирования.
Одиночный символ тильды можно отправить как ~~ или после тильды, если за ней следует символ, отличный от указанных ниже. Символ эскапирования всегда должен следовать за символом новой строки, чтобы интерпретироваться как специальный. Символ эскапирования можно изменить в файлах конфигурации с помощью директивы EscapeChar или в командной строке с помощью опции -e.
Поддерживаемые символы эскапирования (при условии использования значения по умолчанию ‘\~’):
~. Отключиться.
~^Z Переместить ssh в фоновый режим.
~# Отобразить список перенаправленных соединений.
~& Переместить ssh в фоновый режим при выходе, когда ожидаются завершение перенаправленных соединений / X11-сеансов.
~? Отобразить список символов эскапирования.
~B Отправить сигнал BREAK в удаленную систему (полезно только в том случае, если удаленная сторона поддерживает это).
~C Открыть командную строку. В настоящее время это позволяет добавлять перенаправления портов с помощью опций -L, -R и -D (см. выше). Также это позволяет отменить существующие перенаправления портов с помощью -KL[bind_address:]port для локальных, -KR[bind_address:]port для удаленных и -KD[bind_address:]port для динамических перенаправлений портов. !command позволяет пользователю выполнять локальную команду, если опция PermitLocalCommand включена в ssh_config(5). Доступна базовая справка с помощью опции -h.
~R Запросить повторную генерацию ключей соединения (полезно только в том случае, если удаленная сторона поддерживает это).
~V Уменьшить уровень детализации (LogLevel) при записи ошибок в stderr.
~v Увеличить уровень детализации (LogLevel) при записи ошибок в stderr.
ПЕРЕНАПРАВЛЕНИЕ TCP
Перенаправление произвольных TCP-соединений по защищенному каналу можно указать либо в командной строке, либо в файле конфигурации. Одним из возможных применений перенаправления TCP является безопасное соединение с почтовым сервером; другое — обход межсетевых экранов.
В приведенном ниже примере мы рассмотрим шифрование связи для IRC-клиента, даже если IRC-сервер, к которому он подключается, напрямую не поддерживает зашифрованную связь. Это работает следующим образом: пользователь подключается к удаленному хосту с помощью ssh, указывая порты, которые будут использоваться для перенаправления соединения. После этого можно запустить программу локально, и ssh зашифрует и перенаправит соединение на удаленный сервер.
В следующем примере перенаправляется IRC-сеанс от клиента к IRC-серверу по адресу «server.example.com», с подключением к каналу «#users», никнейм «pinky», с использованием стандартного IRC-порта 6667:
$ ssh -f -L 6667:localhost:6667 server.example.com sleep 10
$ irc -c '#users' pinky IRC/127.0.0.1
Опция -f запускает ssh в фоновом режиме, и указана удаленная команда «sleep 10», чтобы предоставить некоторое время (10 секунд в примере) для запуска программы, которая будет использовать туннель. Если в течение указанного времени не будет установлено ни одного соединения, ssh завершит работу.
ПЕРЕНАПРАВЛЕНИЕ X11
Если переменная ForwardX11 установлена в значение «yes» (или см. описание опций -X, -x и -Y выше) и пользователь использует X11 (переменная окружения DISPLAY установлена), соединение с X11-дисплеем автоматически перенаправляется на удаленную сторону таким образом, что любые программы X11, запущенные из оболочки (или команды), будут передаваться через зашифрованный канал, а соединение с фактическим X-сервером будет установлено с локальной машины. Пользователю не следует вручную устанавливать переменную DISPLAY. Перенаправление соединений X11 можно настроить в командной строке или в файлах конфигурации.
Значение DISPLAY, установленное ssh, будет указывать на серверную машину, но с номером дисплея больше нуля. Это нормально, и это происходит потому, что ssh создает «прокси» X-сервер на серверной машине для перенаправления соединений через зашифрованный канал.
ssh также автоматически настраивает данные Xauthority на серверной машине. Для этого он генерирует случайный файл cookie авторизации, сохраняет его в Xauthority на сервере и проверяет, что все перенаправленные соединения содержат этот cookie и заменяют его фактическим cookie при открытии соединения. Фактический cookie авторизации никогда не отправляется на серверную машину (и cookie не отправляются в незашифрованном виде).
Если переменная ForwardAgent установлена в значение «yes» (или см. описание опций -A и -a выше) и пользователь использует агент авторизации, соединение с агентом автоматически перенаправляется на удаленную сторону.
ПРОВЕРКА КЛЮЧЕЙ ХОСТОВ
При подключении к серверу в первый раз пользователю представляется отпечаток (fingerprint) открытого ключа сервера (если только не отключена опция StrictHostKeyChecking). Отпечатки можно определить с помощью команды ssh-keygen(1):
$ ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key
Если отпечаток уже известен, его можно сопоставить и принять или отклонить ключ. Если доступны только устаревшие (MD5) отпечатки сервера, можно использовать опцию ssh-keygen(1) -E для понижения алгоритма отпечатка, чтобы соответствовать.
В связи с тем, что трудно сравнивать ключи хоста, просто просматривая строки отпечатков, существует также поддержка визуального сравнения ключей хостов с использованием случайных изображений. Установив опцию VisualHostKey в значение «yes», небольшое ASCII-графическое изображение будет отображаться при каждом входе на сервер, независимо от того, является ли сеанс интерактивным или нет. Изучив шаблон известного сервера, пользователь может легко определить, изменился ли ключ хоста, когда отображается совершенно другой шаблон. Поскольку эти шаблоны не являются однозначными, шаблон, который выглядит похожим на запомненный шаблон, дает только хорошую вероятность того, что ключ хоста один и тот же, а не гарантированное доказательство.
Чтобы получить список отпечатков и их случайных изображений для всех известных хостов, можно использовать следующую командную строку:
$ ssh-keygen -lv -f ~/.ssh/known_hosts
Если отпечаток неизвестен, доступен альтернативный метод проверки: SSH-отпечатки, проверенные DNS. Дополнительная запись ресурса (RR), SSHFP, добавляется в файл зоны, и клиент, подключающийся к ней, может сопоставить отпечаток с представленным ключом.
В этом примере клиент подключается к серверу «host.example.com». Записи ресурсов SSHFP должны быть сначала добавлены в файл зоны для host.example.com:
$ ssh-keygen -r host.example.com.
Вывод этих строк необходимо добавить в файл зоны. Чтобы проверить, отвечает ли зона на запросы отпечатков:
$ dig -t SSHFP host.example.com
Наконец, клиент подключается:
$ ssh -o "VerifyHostKeyDNS ask" host.example.com
[...]
Найдено совпадающее значение отпечатка ключа хоста в DNS.
Вы уверены, что хотите продолжить подключение (да/нет)?
Подробную информацию см. в разделе «Параметр VerifyHostKeyDNS» в ssh_config(5).
SSH-СЕТИ ВИРТУАЛЬНЫХ ПРИВАТНЫХ СЕТЕЙ
ssh поддерживает туннелирование виртуальной частной сети (VPN) с использованием сетевого псевдоустройства tun(4), что позволяет безопасно объединить две сети. Параметр конфигурации sshd_config(5) PermitTunnel управляет тем, поддерживает ли сервер это и на каком уровне (трафик уровня 2 или 3).
В следующем примере сеть клиента 10.0.50.0/24 подключается к удаленной сети 10.0.99.0/24 с использованием соединения «точка-точка» от 10.1.1.1 до 10.1.1.2, при условии, что SSH-сервер, работающий на шлюзе удаленной сети по адресу 192.168.1.15, это разрешает.
На клиенте:
# ssh -f -w 0:1 192.168.1.15 true
# ifconfig tun0 10.1.1.1 10.1.1.2 netmask 255.255.255.252
# route add 10.0.99.0/24 10.1.1.2
На сервере:
# ifconfig tun1 10.1.1.2 10.1.1.1 netmask 255.255.255.252
# route add 10.0.50.0/24 10.1.1.1
Доступ клиента может быть более точно настроен с помощью файла /root/.ssh/authorized_keys (см. ниже) и серверного параметра PermitRootLogin. Следующая запись разрешит подключения на устройстве tun(4) 1 от пользователя «jane» и на устройстве tun 2 от пользователя «john», если для параметра PermitRootLogin установлено значение «forced-commands-only»:
tunnel="1",command="sh /etc/netstart tun1" ssh-rsa ... jane
tunnel="2",command="sh /etc/netstart tun2" ssh-rsa ... john
Поскольку SSH-настройка включает значительные накладные расходы, она может больше подходить для временных установок, таких как беспроводные VPN. Более постоянные VPN лучше обеспечиваются такими инструментами, как ipsecctl(8) и isakmpd(8).
СРЕДА
ssh обычно устанавливает следующие переменные среды:
DISPLAY
Переменная DISPLAY указывает местоположение сервера X11. Она автоматически устанавливается ssh, чтобы указывать на значение в форме «hostname:n», где «hostname» указывает хост, на котором работает оболочка, а «n» — целое число ≥
ssh использует это специальное значение для перенаправления подключений X11 по защищенному каналу. Пользователю обычно не следует явно устанавливать DISPLAY, так как это сделает соединение X11 небезопасным (и потребует от пользователя вручную скопировать любые необходимые файлы cookie авторизации).
HOME — Устанавливается в путь к домашнему каталогу пользователя.
LOGNAME — Синоним для USER; устанавливается для совместимости с системами, использующими эту переменную.
MAIL — Устанавливается в путь к почтовому ящику пользователя.
PATH — Устанавливается в значение по умолчанию, указанное при компиляции ssh.
SSH_ASKPASS — Если ssh требуется парольная фраза, он будет считывать ее из текущего терминала, если он был запущен из терминала. Если у ssh нет связанного терминала, но установлены DISPLAY и SSH_ASKPASS, он выполнит программу, указанную в SSH_ASKPASS, и откроет окно X11 для ввода парольной фразы. Это особенно полезно при вызове ssh из файла .xsession или аналогичного сценария. (Обратите внимание, что на некоторых машинах может потребоваться перенаправить ввод из /dev/null, чтобы это работало.)
SSH_ASKPASS_REQUIRE — Позволяет более точно контролировать использование программы askpass. Если эта переменная установлена в значение «never», то ssh никогда не будет пытаться использовать ее. Если она установлена в значение «prefer», то ssh будет предпочитать использовать программу askpass вместо терминала при запросе паролей. Наконец, если переменная установлена в значение «force», то программа askpass будет использоваться для ввода всех парольных фраз, независимо от того, установлен ли DISPLAY.
SSH_AUTH_SOCK — Определяет путь к доменному сокету Unix, используемому для связи с агентом.
SSH_CONNECTION — Определяет клиентскую и серверную части соединения. Переменная содержит четыре значения, разделенных пробелами: IP-адрес клиента, номер порта клиента, IP-адрес сервера и номер порта сервера.
SSH_ORIGINAL_COMMAND — Эта переменная содержит исходную командную строку, если выполняется принудительная команда. Ее можно использовать для извлечения исходных аргументов.
SSH_TTY — Эта переменная устанавливается в имя tty (путь к устройству), связанного с текущей оболочкой или командой. Если в текущей сессии нет tty, эта переменная не устанавливается.
SSH_TUNNEL — Опционально устанавливается [sshd]({filename}../../sshd)(8), чтобы содержать имена интерфейсов, назначенных, если клиент запросил туннельный перенаправлятор.
SSH_USER_AUTH — Опционально устанавливается [sshd]({filename}../../sshd)(8), эта переменная может содержать путь к файлу, в котором перечислены методы аутентификации, успешно использованные при установке сеанса, включая любые использованные открытые ключи.
TZ — Эта переменная устанавливается для указания текущего часового пояса, если он был установлен при запуске демона (т. е. демон передает это значение новым соединениям).
USER — Устанавливается в имя пользователя, выполняющего вход в систему.
Кроме того, ssh считывает \~/.ssh/environment и добавляет строки в формате «VARNAME=value» в среду, если файл существует и пользователям разрешено изменять свою среду. Дополнительную информацию смотрите в разделе PermitUserEnvironment в sshd_config(5).
ФАЙЛЫ
~/.rhosts
Этот файл используется для аутентификации на основе хоста (см. выше). На некоторых машинах этот файл может нуждаться в том, чтобы быть доступным для чтения всем пользователям, если домашний каталог пользователя находится на NFS-разделе, потому что sshd(8) читает его от имени root. Кроме того, этот файл должен принадлежать пользователю и не должен иметь прав на запись для кого-либо другого. Рекомендуемые разрешения для большинства машин: чтение/запись для пользователя и недоступность для других.
~/.shosts
Этот файл используется точно так же, как и .rhosts, но позволяет выполнять аутентификацию на основе хоста без разрешения входа с помощью rlogin/rsh.
~/.ssh/
Этот каталог является местом по умолчанию для хранения всей пользовательской конфигурации и информации для аутентификации. Нет общей необходимости хранить все содержимое этого каталога в секрете, но рекомендуемые разрешения: чтение/запись/выполнение для пользователя и недоступность для других.
~/.ssh/authorized_keys
Содержит список открытых ключей (ECDSA, Ed25519, RSA), которые можно использовать для входа в систему под этим пользователем. Формат этого файла описан на странице руководства sshd(8). Этот файл не является особо конфиденциальным, но рекомендуемые разрешения: чтение/запись для пользователя и недоступность для других.
~/.ssh/config
Это файл конфигурации для конкретного пользователя. Формат файла и параметры конфигурации описаны в ssh_config(5). Из-за потенциальной возможности злоупотреблений, этот файл должен иметь строгие разрешения: чтение/запись для пользователя и недоступность для записи для других. Он может быть доступен для записи группе, при условии, что группа содержит только этого пользователя.
~/.ssh/environment
Содержит дополнительные определения переменных среды; см. раздел «ОКРУЖАЮЩАЯ СРЕДА», выше.
~/.ssh/id_ecdsa
~/.ssh/id_ecdsa_sk
~/.ssh/id_ed25519
~/.ssh/id_ed25519_sk
~/.ssh/id_rsa
Содержит закрытый ключ для аутентификации. Эти файлы содержат конфиденциальные данные и должны быть доступны для чтения пользователю, но недоступны для других (чтение/запись/выполнение). ssh просто проигнорирует файл закрытого ключа, если он доступен для других. Можно указать парольную фразу при создании ключа, которая будет использоваться для шифрования конфиденциальной части этого файла с помощью AES-128.
~/.ssh/id_ecdsa.pub
~/.ssh/id_ecdsa_sk.pub
~/.ssh/id_ed25519.pub
~/.ssh/id_ed25519_sk.pub
~/.ssh/id_rsa.pub
Содержит открытый ключ для аутентификации. Эти файлы не являются конфиденциальными и могут (но не обязательно) быть доступны для чтения всем.
~/.ssh/known_hosts
Содержит список ключей хостов для всех хостов, в которые пользователь входил, и которые не находятся в системном списке известных ключей хостов. См. sshd(8) для получения дополнительной информации о формате этого файла.
~/.ssh/rc
Команды в этом файле выполняются ssh при входе пользователя в систему, непосредственно перед запуском оболочки (или команды) пользователя. См. страницу руководства sshd(8) для получения дополнительной информации.
/etc/hosts.equiv
Этот файл предназначен для аутентификации на основе хоста (см. выше). Он должен быть доступен для записи только пользователю root.
/etc/ssh/shosts.equiv
Этот файл используется точно так же, как и hosts.equiv, но позволяет осуществлять аутентификацию на основе хоста без разрешения входа с помощью rlogin/rsh.
/etc/ssh/ssh_config
Системный файл конфигурации. Формат файла и параметры конфигурации описаны в ssh_config(5).
/etc/ssh/ssh_host_ecdsa_key
/etc/ssh/ssh_host_ed25519_key
/etc/ssh/ssh_host_rsa_key
Эти файлы содержат частные части ключей хоста и используются для аутентификации на основе хоста.
/etc/ssh/ssh_known_hosts
Системный список известных ключей хостов. Этот файл должен быть подготовлен системным администратором и содержать открытые ключи хостов всех машин в организации. Он должен быть доступен для чтения всем пользователям. См. sshd(8) для получения дополнительной информации о формате этого файла.
/etc/ssh/sshrc
Команды в этом файле выполняются ssh при входе пользователя, непосредственно перед запуском оболочки (или команды) пользователя. См. страницу руководства sshd(8) для получения дополнительной информации.
СТАТУС ВЫХОДА
ssh завершается с кодом выхода удаленной команды или с 255, если произошла ошибка.
СМОТРИТЕ ТАКЖЕ
scp(1), sftp(1), ssh-add(1), ssh-agent(1), ssh-argv0(1), ssh-keygen(1), ssh-keyscan(1), tun(4), ssh_config(5), ssh-keysign(8), sshd(8)
СТАНДАРТЫ
S. Lehtinen и C. Lonvick, The Secure Shell (SSH) Protocol Assigned Numbers, RFC 4250, январь 200.
T. Ylonen и C. Lonvick, The Secure Shell (SSH) Protocol Architecture, RFC 4251, январь 2006.
T. Ylonen и C. Lonvick, The Secure Shell (SSH) Authentication Protocol, RFC 4252, январь 2006.
T. Ylonen и C. Lonvick, The Secure Shell (SSH) Transport Layer Protocol, RFC 4253, январь 200.
T. Ylonen и C. Lonvick, The Secure Shell (SSH) Connection Protocol, RFC 4254, январь 2006.
J. Schlyter и W. Griffin, Using DNS to Securely Publish Secure Shell (SSH) Key Fingerprints, RFC 4255, январь 2006.
F. Cusack и M. Forssen, Generic Message Exchange Authentication for the Secure Shell Protocol (SSH), RFC 4256, январь 2006.
J. Galbraith и P. Remaker, The Secure Shell (SSH) Session Channel Break Extension, RFC 4335, январь 2006.
M. Bellare, T. Kohno и C. Namprempre, The Secure Shell (SSH) Transport Layer Encryption Modes, RFC 4344, январь 2006.
B. Harris, Improved Arcfour Modes for the Secure Shell (SSH) Transport Layer Protocol, RFC 4345, январь 2006.
M. Friedl, N. Provos и W. Simpson, Diffie-Hellman Group Exchange for the Secure Shell (SSH) Transport Layer Protocol, RFC 4419, март 2006.
J. Galbraith и R. Thayer, The Secure Shell (SSH) Public Key File Format, RFC 4716, ноябрь 200.
D. Stebila и J. Green, Elliptic Curve Algorithm Integration in the Secure Shell Transport Layer, RFC 5656, декабрь 2009.
А. Перриг и Д. Сонг, «Визуализация хеша: новая техника для повышения безопасности в реальном мире», 1999,
Международный семинар по криптографическим технологиям и электронной коммерции (CrypTEC '99).
АВТОРЫ
OpenSSH является производной от оригинальной и бесплатной версии ssh 1.2.12, выпущенной Тату Илоненом. Аарон Кэмпбелл, Боб Бек, Маркус Фридль, Нильс Провос, Тео де Раат и Даг Сонг исправили множество ошибок, добавили новые функции и создали OpenSSH. Маркус Фридль внес вклад в поддержку протоколов SSH версий 1.5 и 2.0.