Все что Вы хотели знать о SSH

Материал из FedoraMD.org Wiki
Перейти к навигации Перейти к поиску

ВНИМАНИЕ: команды предваряемые символом '#' должны выполняться с правами root (Суперпользователь). Открыв терминал (или находясь в консоли) с правами обычного пользователя, введите команду $ su - для повышения уровня привелегий. Символы '$' и '#' в начале строки не являются частью команды и не должны вводится. Прочие команды могут выполняться с правами обыкновенного пользователя.


Содержание

Что такое SSH?

SSH (Secure Shell) — сетевой протокол, позволяющий производить удалённое управление компьютером и передачу файлов. Сходен по функциональности с протоколом Telnet и rlogin, однако использует алгоритмы шифрования передаваемой информации.

Криптографическая защита протокола SSH не фиксирована, возможен выбор различных алгоритмов шифрования. Клиенты и серверы, поддерживающие этот протокол, доступны для различных платформ. Кроме того, протокол позволяет не только использовать безопасный удалённый shell на машине, но и туннелировать графический интерфейс — X Tunnelling (только для Unix-подобных ОС или приложений, использующих графический интерфейс X Window System). Так же ssh способен передавать через безопасный канал (Port Forwarding) любой другой сетевой протокол, обеспечивая (при надлежащем конфигурировании) возможность безопасной пересылки не только X-интерфейса, но и, например, звука.

Поддержка SSH реализована во всех UNIX системах, и на большинстве из них в числе стандартных утилит присутствуют клиент и сервер ssh. Существует множество реализаций SSH-клиентов и для не-UNIX ОС. Большую популярность протокол получил после широкого развития sniffer’ов, как альтернативное небезопасному телнету решение для управления важными узлами.

На данный момент известно две ветки версий — 1 и 2. Однако ветка 1 остановлена, так как в конце 90-x в ней было найдено много уязвимостей, некоторые из которых до сих пор накладывают серьёзные ограничения на её использование, поэтому перспективной, развивающейся и наиболее безопасной является версия 2.

Аутентификация на SSH сервере с использованием ключей

by Brian Hatch

Перевод: Сгибнев Михаил

OpenSSH кроме паролей поддерживает ещё несколько методов аутентификации. Он может быть сконфигурирован на использование методов PAM (Pluggable authentication modules), протокола Challenge/Response, Kerberos, аутентификации по доверенным хостам и такая экзотика как ключи X509. Но самым популярным является метод Identity/Pubkey.

Целью использования идентификации Identity/Pubkey является исключение использования статических паролей. Вместо того, чтобы каждый раз набирать пароли, которые могут быть перехвачены кейлоггером или просто подсмотрены, у нас на диске имеется пара ключей, которые и используются для проверки подлинности. Ваша учетная запись на сервере SSH имеет список Identities/Pubkeys, которому можно доверять и если Вы сможете доказать, что у вас есть и публичный и приватный ключ, то доступ будет предоставлен без запроса пароля.

Вот некоторые из положительных моментов этого типа аутентификации:

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

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

Создание Identity/Pubkey

В оригинальной реализации SSHv1 Вы могли создать Identity, которое было парой RSA публичного и приватного ключей. В SSHv2 формат этих ключей был изменен, стали поддерживаться ключи RSA и DSA, и эта аутентификация была переименована в Pubkey. В контексте данной статьи эти обозначения будут использоваться взаимозаменяемо, так как реализуют идентичные функции.

С помощью утилиты ssh-keygen создадим необходимые ключи: 

$ ssh-keygen -t rsa
  Generating public/private rsa key pair.
  Enter file in which to save the key (/home/xahria/.ssh/id_rsa):
  Enter passphrase (empty for no passphrase): (enter passphrase)
  Enter same passphrase again: (enter passphrase)
  Your identification has been saved in /home/xahria/.ssh/id_rsa.
  Your public key has been saved in /home/xahria/.ssh/id_rsa.pub.
  The key fingerprint is:
  2c:3f:a4:be:46:23:47:19:f7:dc:74:9b:69:24:4a:44 xahria@mydesktop
  
  
$ cd $HOME/.ssh
$ ls -l
  -rw-------    1 xahria   hatchclan   883 Jan 21 11:52 id_rsa
  -rw-r--r--    1 xahria   hatchclan   223 Jan 21 11:52 id_rsa.pub
  
$ cat id_rsa
  -----BEGIN RSA PRIVATE KEY-----
  MIICWgIBAAKBgQCc+1oixZ/g84gpZH0NeI+CvVoY5O0FOCSpFCbhUGJigQ6VeKI5
  gpOlDztpJ1Rc+KmfZ2qMaftwwnLmefhk1wPcvfZvvLjfdmHY5/LFgDujLuL2Pv+F
  7tBjlyX9e9JfXZau2o8uhBkMbb3ZqYlbUuuoCAnUtL5uZUiiHM0BAtnGAd6epAYE
  gBHw1xnqsy+mzbuWdLEVF7crlUSsctwGapb6/SEQgEXFm0RITQ3jCY808NjRS3hW
  Z+uCCO8GGUsn2bZpcGXa5vZzACvZL8epJoMgQ4D0T50rAkEA0AvK4PsMF02Rzi4E
  mXgzd1yCa030LYR/AkApG1KT//9gju6QCXlWL6ckZg/QoyglW5myHmfPR8tbz+54
  /lj06BtBA9iag5+x+caV7qKth1NPBbbUF8Sbs/WI5NYweNoG8dNY2e0JRzLamAUk
  jK2TIwbHtE7GoP/Za3NTZJm2Ozviz8+PHPIEyyt9/kzT0+yo3KmgsstlqwIBIwKB
  XdBh42izEWsWpXf9t4So0upV1DEcjq8CQQDEKGAzNdgzOoIozE3Z3thIjrmkimXM
  J/Y3xQJBAMEqZ6syYX/+uRt+any1LADRebCq6UA076Sv1dmQ5HMfPbPuU9d3yOqV
  j0Fn2H68bX8KkGBzGhhuLmbrgRqr3+SPM/frUj3UyYxns5rnGspRkGB3AkALCbzH
  9EAV8Uxn+Jhe5cgAC/hTPPdiwTJD7MpkNCpPuKRwrohytmNAmtIpKipAf0LS61np
  wtq59ssjBG/a4ZXNn32n78DO0i6zVV5vwf8rv2sf
  -----END RSA PRIVATE KEY-----
  
$ cat id_rsa.pub
    ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAcMJy5nn4ZNcD3L32b7y433Zh2IEAnPt
    aIsWf4POIKWR9DXiPgr1aGOTtBTgkqRQm4VBiYoEOlXiiOYKTpQ87aSdUXPipn
    2dqjGn7OfyxYA7oy7i9j7/hYytkyMGx7ROxqD/2WtzU2SZtjs74s/PjxzyBMsr
    ff5M09PsqNypoLLLZas= xahria@mydesktop

Обратите внимание, что 'ssh-rsa...xahria@mydesktop' это одна строка, а не несколько.

Как Вы могли убедиться, ssh-keygen создал два файла: id_rsa и id_rsa.pub. В первом файле хранится приватный ключ, защищенный кодовой фразой, введенной Вами при создании. **НИКОМУ** не давайте копаться в этом файле. Второй файл - Ваш публичный ключ, он не содержит никаких тайн и может быть доступен любому встречному-поперечному. В случае утраты он может быть восстановлен из приватного ключа.

Типы ключей SSH

При создании ключей Вы указывали опцию -t rsa. Этим параметром мы указываем тип создаваемых ключей. Также возможно создать ключи rsa1, rsa или dsa. Рассмотрим их отличия:

Тип Аргумент Имя по умолчанию Протокол Пример заголовка
RSA1 -t rsa1 identity SSH 1 protocol only 1024 35 118118225938285...
RSA -t rsa id_rsa SSH 2 protocol only ssh-dss AAAAB3nzaC1kc3M...
DSA -t dsa id_dsa SSH 2 protocol only ssh-rsa AAAAB3NzaC1yc2E...

Вы можете изменить имя файла с помощью опции -f filename. Если Вы не определили имя файла, то ключи будут записаны в каталог $HOME/.ssh/ с именем, принятым по умолчанию для данного типа ключа.

Разрешение Identity/Pubkey аутентификации на сервере

После того, как мы создали ключи, необходимо разрешить данный тип аутентификации на сервере SSH. Сначала определим тип аутентификации - Pubkey или Identity, установив следующие настройки в sshd_config: 

# Should we allow Identity (SSH version 1) authentication?
RSAAuthentication yes
  
# Should we allow Pubkey (SSH version 2) authentication?
PubkeyAuthentication yes
 
# Where do we look for authorized public keys?
# If it doesn't start with a slash, then it is
# relative to the user's home directory
AuthorizedKeysFile    .ssh/authorized_keys

Приведенные выше значения разрешают аутентификацию Identity/Pubkey для протокола SSH версии 1 и 2, и проверяют наличие публичных ключей в файле $HOME/.ssh/authorized_keys.

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

Содержимое файла authorized_keys

Файл authorized_keys просто содержит список ключей, по одному в строке. В него мы и пропишем ключ, сгенерированный нами на своей машине. 

# Copy the RSA Pubkey to the server using scp.
# You can use any method you like, including using
# copy/paste if it's convenient.
$ cd $HOME/.ssh
$ scp id_rsa.pub ssh-server:id_rsa_mydesktop.pub
xahria@ssh-server's password: (enter password)
  
# Now let's log in and create the authorized_keys file
$ ssh ssh-server
xahria@ssh-server's password: (enter password)
 
# Create the .ssh dir if it doesn't already exist
ssh-server$ mkdir .ssh
ssh-server$ chmod 700 .ssh
ssh-server$ cd .ssh
  
# Concatenate the RSA Pubkey we just uploaded to
# the authorized_keys file.  (This will create
# if it doesn't already exist.)
ssh-server$ cat ../id_rsa_mydesktop.pub >> authorized_keys
  
# Let's check out the file
ssh-server$ cat authorized_keys
ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAcMJy5nn4ZNcD3L32b7y433Zh2IEAnPt
  aIsWf4POIKWR9DXiPgr1aGOTtBTgkqRQm4VBiYoEOlXiiOYKTpQ87aSdUXPipn
  2dqjGn7OfyxYA7oy7i9j7/hYytkyMGx7ROxqD/2WtzU2SZtjs74s/PjxzyBMsr
  ff5M09PsqNypoLLLZas= xahria@mydesktop
  
# Make sure permissions are paranoid
ssh-server$ chmod 600 authorized_keys
  
# Excellent, let's log out.
ssh-server$ exit

Прядок действий следующий: копируем публичный ключ RSA на сервер, используя scp или любой другой способ. Создаем файл authorized_keys, если каталога .ssh не существует - создаем. Добавляем публичный ключ RSA в файл authorized_keys. Проверяем, устанавливаем права доступа и выходим.

Также можно упростить процедуру используя стандартный скрипт ssh-copy-id. 

ssh-copy-id -i .id_rsa.pub xahria@ssh-server

Пришла пора проверить. что мы наваяли: 

mydesktop$ ssh ssh-server
Enter passphrase for key '/home/xahria/.ssh/id_rsa':

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

Рассмотрим процесс подключения по разделениям:

  • /usr/bin/ssh соединяется с сервером на порт SSH
  • Клиент и сервер обмениваются ключами, определяется алгорит м шифрования
  • Клиент ищет файлы, по умолчанию испрользуемые Pubkey/Identity
  • Если один из таких файлов был найден, то посылается публичный ключ на сервер и запрашивается аутентификация по этому ключу
  • Сервер проверяет файл authorized_keys пользователя на наличие публичного ключа и посылает клиенту последовательность, зашифрованную открытым ключом. Если приватный ключ защищен кодовым словом, то /usr/bin/ssh просит его ввести для дешифровки приватного ключа.
  • Клиент расшифровывает посланную последовательность для подтверждения правильности публичного и приватного ключей
  • Если расшифровка удалась, то сервер пускает клиента без запроса пароля Unix
  • Если клиент не может доказать, что это имеет ключ, то он может предложить другие ключи
  • При отсутствии корректных ключей пользователю будет предложено авторизоваться с помощью авторизации Unix

Все это проходит незаметно для пользователя. Если Вы хотите наблюдать за фазами соединения, то используйте ключ -v: 

mydesktop$ ssh ssh-server
OpenSSH_3.8.1p2, SSH protocols 1.5/2.0, OpenSSL 0x009060cf
...
debug1: identity file /home/xahria/.ssh/identity type 0
debug1: identity file /home/xahria/.ssh/id_rsa type 1
debug1: Remote protocol version 1.99, remote software version OpenSSH_3.7.1p2
...
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Offering public key: /home/xahria/.ssh/id_rsa
debug1: Server accepts key: pkalg ssh-rsa blen 149 lastkey 0x601d0 hint 1
debug1: PEM_read_PrivateKey failed
debug1: read PEM private key done: type <unknown>
Enter passphrase for key '/home/xahria/.ssh/id_rsa': (Enter wrong passphrase)
 
debug1: PEM_read_PrivateKey failed
debug1: Next authentication method: keyboard-interactive
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: password
xahria@ssh-server's password:  (Enter Unix password)

Для наглядности, в этом примере мы вводим неправильное кодовое слово для дешифровки приватного ключа. Также Вы можете заметить, что были найдены файлы identity и id_rsa, хотя они могут использоваться только с SSHv2.

Выбор ключей

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

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

Определить используемый ключ можно с помощью опции -i private_key_file: 

mydesktop$ ssh -i ~/.ssh/special_ssh_key  ssh-server
Enter passphrase for key '/home/xahria/.ssh/special_ssh_key':

Следущая опция создаст в Вашем ~/.ssh/config указание на отображение еспользуемого ключа: 

mydesktop$ cat ~/.ssh/config
 Host ssh-server
 IdentityFile ~/.ssh/special_ssh_key
  
mydesktop$ ssh ssh-server
Enter passphrase for key '/home/xahria/.ssh/special_ssh_key':

Обратите внимание, что переменная config всегда равна IdentityFile, независимо от того, используется Pubkey или Identity.

Безопасность кодовой фразы

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

authorized_keys2

Старые версии OpenSSH использовали два различных публичных ключа для доступа к серверу - authorized_keys для Identities (SSHv1) и authorized_keys2 для Pubkeys (SSHv2). Позже было решено, что это глупо и теперь используется один файл для ключей всех типов, но при отсутствии подходящего ключа будет проверен и authorized_keys2. Более поздние версии OpenSSH могут вполне прекратить поддерживать authorized_keys2 вовсе.

Чтобы не думать об этом ограничении, создадим жесткую ссылку authorized_keys2 на файл authorized_keys. 

ssh-server$ cd .ssh
ssh-server$ ls -l
-rw-------    1 xahria   hatchclan   883 Jan 21 11:52 authorized_keys

# make a hard link so they are the same file, just different
# file names.
ssh-server$ ln authorized_keys authorized_keys2

ssh-server$ ls -l
-rw-------    2 xahria   hatchclan   883 Jan 21 11:52 authorized_keys
-rw-------    2 xahria   hatchclan   883 Jan 21 11:52 authorized_keys2

Так мы удовлетворим потребности любой версии OpenSSH.

Аутентификация на SSH сервере с использованием ssh-agent

by Brian Hatch

Перевод: Сгибнев Михаил

Никто не любит вводить пароли. Если бы компьютеры, как люди, четко представляли себе, кто они такие и к чему они могут получить доступ, а к чему нет и не заставляли бы каждый раз напрягать клавиатуру... В моей последней статье я показал Вам, как создать SSH Identities/Pubkeys, который может использоваться как альтернатива вводу пароля. Однако, поскольку мы используем кодовую фразу для защиты, то получается, что мы просто поменяли один пароль на другой.


Сейчас мы разберем следующую ситуацию: мы возьмем доверительные отношения между хостами, данные нам Identity/Pubkey и для управления ключами будем использовать ssh-agent.

Запуск ssh-agent

Для запуска ssh-agent необходимо просто дать команду: 

$ ssh-agent
 SSH_AUTH_SOCK=/tmp/ssh-OqdW7921/agent.7921; export SSH_AUTH_SOCK;
 SSH_AGENT_PID=7922; export SSH_AGENT_PID;
 echo Agent pid 7922;

При запуске агента он выведет на консоль некоторую информацию, которую Вы можете использовать для установки переменных среды. В настоящем примере используется синтаксис Bourne shell. Если Вы используете C-shell, такой как /bin/csh или /bin/tcsh, то переменные отобразились бы по другому. Если ssh-agent не может определить, какую оболочку Вы используете, Вы можете использовать ключи -s или -c соответственно для Bourne shell/C-shell.

Программа /usr/bin/ssh использует переменную среды SSH_AUTH_SOCK, чтобы знать, как войти в контакт с запущеным Вами ssh-агентом. Эту переменную необходимо определить. Самый простой способ сделать это - использовать функцию оболочки eval, 

# Note: no ssh agent related variables yet
 $ set | grep SSH_
  
# Run it inside backticks, which will capture the output and
# pass it to 'eval' which will run it in your current shell.
$ eval `ssh-agent`
 Agent pid 7943
  
# And now those variables are in your shell, ready to use.
$ set | grep SSH_
 SSH_AUTH_SOCK=/tmp/ssh-xoGi7942/agent.7942
 SSH_AGENT_PID=7943

Если Вам известна переменная SSH_AGENT_PID, то Вы можете завершить работу агента с помощью команды ssh-agent -k, хотя и команда kill по прежнему неплохо работает.

Примечание: в Fedora Linux, работая в X сессии запущеной из GDM можно не заботится запуском ssh-agent - система делает это по умолчанию. Просто добавьте в ssh-agent необходимые ключи (см. ниже).

Загрузка ключей в агент

Сам по себе агент не очень полезен, пока в него не загружены ключи. Все управление ключами происходит через команду ssh-add, если Вы запустите ее без аргументов, то она загрузит "стандартные ключи" из $HOME/.ssh/identity, $HOME/.ssh/id_rsa и $HOME/.ssh/id_dsa. Если Ваши ключи защищены кодовой фразой (по другому и быть не может!), то ее потребуется ввести для декодирования ключей. Если кодовая фраза одинакова для всех ключей, то и ввести ее необходимо только один раз.

Итак: 

$ ps -fp $SSH_AGENT_PID
  UID        PID  PPID  C STIME TTY          TIME CMD
  lainee    7943     1  0 15:52 ?        00:00:00 ssh-agent
  
  # Are there any keys in there currently?
  #  'ssh-add -l' (list) will show us.
$ ssh-add -l
  The agent has no identities.
  
  # Let's import the default keys.  In our case, we have
  # each key protected with the same passphrase, which is
  # why it only asks once.
$ ssh-add
  Enter passphrase for /home/lainee/.ssh/id_rsa:
  Identity added: /home/lainee/.ssh/id_rsa (/home/lainee/.ssh/id_rsa)
  Identity added: /home/lainee/.ssh/id_dsa (/home/lainee/.ssh/id_dsa)
  Identity added: /home/lainee/.ssh/identity (lainee@desktop)
  
  # What's in our agent now?
$ ssh-add -l
  1024 79:e9:6f:99:a3:2d:ae:f3:bd:3a:87:6c:ed:4e:bb:ad lainee@desktop (RSA1)
  1024 23:d5:2b:20:02:a4:1a:c2:d0:d8:66:8f:a9:67:db:c0 id_dsa (DSA)
  1024 e8:17:67:cf:9c:24:2b:59:ad:48:1d:e6:ea:d6:d9:3d id_rsa(RSA)
  
  # And let's add a few one-off keys also
$ ssh-add ssh-keys/id*
  Enter passphrase for id_dsa.webrooters:
  Identity added: id_dsa.webrooters (id_dsa.webrooters)
  Enter passphrase for identity.webrooters:
  Identity added: identity.webrooters (webrooters@my_company.com)
  
  
  # What's in our agent now?
$ ssh-add -l
  1024 79:e9:6f:99:a3:2d:ae:f3:bd:3a:87:6c:ed:4e:bb:ad lainee@desktop (RSA1)
  1024 23:d5:2b:20:02:a4:1a:a9:67:db:c0:c2:d0:d8:66:8f id_dsa (DSA)
  1024 e8:17:67:cf:9c:24:2b:59:ad:48:1d:e6:ea:d6:d9:3d id_rsa(RSA)
  1024 1a:c2:d0:d8:66:23:d5:2b:20:02:a4:8f:a9:67:db:c0 id_dsa.webrooters (DSA)
  1024 ae:f3:bd:3a:87:79:e9:6f:99:4e:bb:ad:a3:2d:6c:ed webrooters@my_company.com (RSA1)

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

Удаление ключей из агента

Вы можете использовать команду ssh-agent -d для удаления ключей: 

# List keys
$ ssh-add -l
  1024 79:e9:6f:99:a3:2d:ae:f3:bd:3a:87:6c:ed:4e:bb:ad lainee@desktop (RSA1)
  1024 23:d5:2b:20:02:a4:1a:a9:67:db:c0:c2:d0:d8:66:8f id_dsa (DSA)
  1024 e8:17:67:cf:9c:24:2b:59:ad:48:1d:e6:ea:d6:d9:3d id_rsa(RSA)
  1024 1a:c2:d0:d8:66:23:d5:2b:20:02:a4:8f:a9:67:db:c0 id_dsa.webrooters (DSA)
  1024 ae:f3:bd:3a:87:79:e9:6f:99:4e:bb:ad:a3:2d:6c:ed webrooters@my_company.com (RSA1)
  
  # Remove the key that came from the file ~/.ssh/id_dsa.webrooters
  # from the agent.  (Does not remove the file from the directory.)
$ ssh-add -d ~/.ssh/id_dsa.webrooters
  Identity removed: id_dsa.webrooters (id_dsa.webrooters.pub)
  
  # List keys again
$ ssh-add -l
  1024 79:e9:6f:99:a3:2d:ae:f3:bd:3a:87:6c:ed:4e:bb:ad lainee@desktop (RSA1)
  1024 23:d5:2b:20:02:a4:1a:a9:67:db:c0:c2:d0:d8:66:8f id_dsa (DSA)
  1024 e8:17:67:cf:9c:24:2b:59:ad:48:1d:e6:ea:d6:d9:3d id_rsa(RSA)
  1024 ae:f3:bd:3a:87:79:e9:6f:99:4e:bb:ad:a3:2d:6c:ed webrooters@my_company.com (RSA1

Зачем удалять ключи из агента? Может быть несколько причин:

  • Вы добавляете временный ключ, который будет действовать в течение блиайшего часа и хотите удалить его после работы из-за приступа паранойи.
  • Вы перешли на протокол SSHv2, и ваши ключи RSA1 больше не нужны.
  • У вас в агенте содержится слишком много ключей и Вы удаляете наименее часто используемые. Почему это может понадобиться - смотрите ниже.

Слишком много ключей?

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

  • Если у Вас имеются устаревшие ключи, то удалите их с помощью команды ssh-agent -d filename.
  • Вы можете использовать аутентификацию по паролю, временно отключив переменную SSH_AUTH_SOCK:
$ SSH_AUTH_SOCK='' ssh user@myserver ...

Или Вы можете внести необходимые опции в ~/.ssh/options, а затем выполнить команду: 

# Using the configuration file:
$ head  ~/.ssh/config

 Host myserver
    #  Allow SSHv1 Identity authentication?
    RSAAuthentication    no

    # Allow SSHv2 Pubkey authentication?
    PubkeyAuthentication no

$ ssh myserver

или

# Put it all on the command line.
# Or better yet, put it in a shell script or an alias...
$ ssh -o'RSAAuthentication=no' -o 'PubkeyAuthentication=no' user@myserver ...
  • Если Вы хотите использовать авторизацию по ключу, но он находится слишком далеко в списке и сервер SSH не пускает Вас, то Вам не повезло. Если у кого-либо есть идеи относительно этой проблемы, то прошу поделиться.

переносим ключи в отдельную директорию, и вызываем явно с помощью IdentityFile 

# Using the configuration file:
$ cat  ~/.ssh/config

Host    portal 
        HostName portal.zone.local
	IdentityFile ~/.ssh/tmp/id_rsa_4096_portal 
	Port 22335

в случае использования ssh-agent приходится прибегать к дополнительным ухищрениям, ибо он всё равно норовит использовать все известные ему ключи. 

# Using the configuration file:
$ cat  ~/.ssh/config
HashKnownHosts yes
RSAAuthentication    no

Host    portal 
        HostName portal.zone.local
        PubkeyAuthentication yes
	IdentityFile ~/.ssh/tmp/id_rsa_4096_portal 
	Port 22335

Host    gw
	HostName 10.1.12.1
        PubkeyAuthentication yes
	IdentityFile ~/.ssh/tmp/id_rsa_4096_gw

Host   *
        PasswordAuthentication yes
        PubkeyAuthentication no

подробности в man ssh_config

Мероприятия по защите агента

ssh-agent создает unix domain socket и затем слушает все подключения от /usr/bin/ssh на этом сокете. В принципе Ваши ключи могут оказаться доступны любому, кто подключится к этому сокету.

При запуске агента, создается временный каталог /tmp/, с установленными правами доступа (0700) и уже внутри него создается сокет с правами (0600). Однако пользователь root по преженму имеет доступ к этому сокету, также он может произвольным образом поменять права доступа к сокету. 

root# set | grep SSH_
root# ssh-add -l
Cannot connect to your agent.
  
root# ls -l /tmp/ssh-*/* 
srwx------ 1  lainee  alandra   0 Jan 21 11:51  /tmp/ssh-OqdW7921/agent.7921
  
root# SSH_AUTH_SOCK=/tmp/ssh-OqdW7921/agent.7921
root# export SSH_AUTH_SOCK
root# ssh-add -l
1024 79:e9:6f:99:a3:2d:ae:f3:bd:3a:87:6c:ed:4e:bb:ad lainee@desktop (RSA1)
1024 23:d5:2b:20:02:a4:1a:a9:67:db:c0:c2:d0:d8:66:8f id_dsa (DSA)
1024 e8:17:67:cf:9c:24:2b:59:ad:48:1d:e6:ea:d6:d9:3d id_rsa(RSA)
1024 ae:f3:bd:3a:87:79:e9:6f:99:4e:bb:ad:a3:2d:6c:ed webrooters@my_company.com (RSA1)

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

Можем ли мы воспрепятствовать root получить доступ к нашему агенту, даже с учетом того, что он не обращает внимания на права доступа? Да, можем, если будем использовать опцию -c при импорте ключей в агента. В этом случае будет сделан запрос на подтверждение при каждой попытке авторизации на сервере с помощью программы ssh-askpass. Эта программа выскочит на вашем X11 рабочем столе и будет просить о подтверждении каждый раз перед использованием ключа.

Примерно в этой точке Вы должны понять, что мы заведомо проиграли. root может обратиться к Вашему X11 рабочему столу и вообще ко всем Вашим процессам. Если Вы не доверяете root, то Ваше положение не завидно.

Перенаправление агента

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

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

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

  • /usr/bin/ssh с Вашей машины соединяется с сервером управления, аутентифицируется и запрашивает форвардинг агента.
  • /usr/sbin/sshd на сервере управления открывает сокет /tmp/ssh-XXXXXXX/agent.~##### и устанавливает переменную SSH_AUTH_SOCK
  • Стартует демон SSH и вы начинаете работу в шелле на сервере управления.
  • Когда Вы решаете соединиться по SSH к почтовому серверу, программа/usr/bin/ssh (на сервере управления) видит переменную среды SSH_AUTH_SOCK и соединяется с локальным сокетом.
  • SSH демон, который является другим концом сокета /tmp/ssh-XXXXXXX/agent.~#####, просто перегоняет данные от/usr/bin/ssh на сервере управления к и от ssh-agent, выполняющегося на вашем рабочем столе. Все операции с ключами выполняются на агенте, который выполняется на Вашем рабочем столе.
  • Агент аутентифицируется на сервере.

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

Также обратите внимание, что так Ваш агент доступен любой машине, с которой Вы соединяетесь. Соответственно, и пользователю root этой машины. Будьте бдительны!

Глобальное отключение перенаправления

Если у Вас нет серьезных причин разрешать перенаправление, то проверьте соответствующий параметр в глобальном файле конфигурации ssh_config, который обычно расположен в /etc/ или /etc/ssh/ . Должно быть: 

Host *
  ForwardAgent  no

Перенаправление агента из командной строки

Для перенаправлении агента из командной строки, используйте опцию -A: 

desktop$ ssh -A user@remotehost

Опция -a отключает форвардинг, что является значением по умолчанию.

Перенаправление агента из файла конфигурации

Если у Вас есть хост, на котором Вы всегда используете перенаправление и Вы не хотите постоянно использовать флаг -A, то Вы можете сделать для этих хостов записи в ~/.ssh/config: 

$ cat ~/.ssh/config
Host shellserver
  ForwardAgent yes
  
Host management-server
  ForwardAgent yes
  
Host *
  ForwardAgent no

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

Прочие возможности

Есть еще несколько дополнительных флагов для ssh-add и ssh-agent: 

ssh-add -L

Выведет не заголовок, а ключ полностью. Может быть полезным при обьединении их в одном файле ~/.ssh/authorized_keys 

ssh-add -D

Удаляет ВСЕ ключи из агента 

ssh-add -x

Блокирует агента до ввода пароля. Заблокированный агент не пригоден для использования. Хороший способ обезопасить агента, когда Вы на ночь уходите с работы домой. Для разблокировки используйте ssh-add -X. 

ssh-add -t seconds filename

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

ssh-agent -t seconds

Определяет время жизни ключей после запуска агента.

Перенаправление портов в SSH

by Brian Hatch

Перевод: Сгибнев Михаил

Введение

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

Всякий раз используя SSH для соединения одной машины с другой, мы создаем безопасный сеанс связи. Вы можете ознакомиться с другими статьями, связанными с настройкой и эксплуатированием SSH: SSH Host Key Protection, SSH User Identities и SSH and ssh-agent.

SSH также имеет замечательную возможность перенаправления портов, что позволяет нам создать безопасный сеанс связи и затем туннелировать через него произвольные подключения TCP. Туннелирование создается очень легко и не требует знаний программирования, что делает его очень привлекательным. В этой статье мы детально рассмотрим перенаправление портов в SSH, поскольку это - очень полезная, но часто неправильно истолковываемая технология. Перенаправление портов может использоваться в несметном количестве мест. Давайте подкрепим это утверждение примером.

Пример локального перенаправления

Предположим, что на вашей машине имеется почтовый клиент и вы получаете письма с почтового сервера по протоколу POP (Post Office Protocol), порт 110. Вы хотите защитить ваше POP соединение с целью препятствовать перехвату пароля или почты (Некоторые POP серверы поддерживают дополнительные методы авторизации, типа S/Key или обмен запросами).

В обычном случае, клиент создает сессию с портом TCP за номером 110, вводится имя пользователя и пароль и скачиваются письма. Давайте просто попробуем использовать telnet или nc: 

xahria@desktop$ nc mailserver 110
+OK SuperDuper POP3 mail server (mailserver.my_isp.net) ready.
USER xahria
+OK
PASS twinnies
+OK User successfully logged on.
LIST
+OK 48 1420253
1 1689
2 1359
3 59905
...
47 3476
48 3925
.
QUIT
+OK SuperDuper POP3 mail server signing off.
  
xahria@desktop$

Мы можем перенаправить эту TCP-сессию внутрь SSH-сессии используя перенаправление портов. Если мы имеем доступ по SSH к машине, на которой запущен требуемый нам сервис (в нашем случае POP, порт 110), то цель близка и приятна. Также, для наших целей мы можем использовать любой SSH-сервер в сети, из которой доступен целевой почтовый сервер.

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

# first, show that nothing's listening on our local machine on port 9999:
xahria@desktop$ nc localhost 9999
Connection refused.
  
xahria@desktop$ ssh -L 9999:mailserver:110 shellserver 
xahria@shellserver's password: ********
  
xahria@shellserver$ hostname
shellserver

С другого терминала вашей машины соединитесь с портом 9999 своей же машины(localhost). 

xahria@desktop$ nc localhost 9999
+OK SuperDuper POP3 mail server (mailserver.my_isp.net) ready.
USER xahria
+OK
PASS twinnies
...

Прежде чем мы соединились с shellserver по SSH ничто не слушало на порту 9999. Именно технологии туннелирования мы обязаны волшебному появлению на порту 9999 нашей локальной машины приглашения почтового сервера.

Давайте подробно разберем предложенный пример:

  • Вы запустили клиент SSH /usr/bin/ssh из командной строки
  • Клиент регистрируется на удаленной машине используя один из методов авторизации (пароль или ключ)
  • SSH клиент занимает определенный вами локальный порт 9999 на кольцевом интерфейсе 127.0.0.1 (loopback)
  • Открытая же сессия с удаленной машиной вполне пригодна для использования, вы можете архивировать файлы или удалить /etc/shadow...
  • Когда же вы соединяетесь с локальной машиной 127.0.0.1 на порт 9999, то клиентская программа /usr/bin/ssh принимает соединение.
  • SSH клиент информирует сервер через шифрованный канал о необходимости создать соединение с mailserver, порт 110
  • Клиент принимает все данные, посылаемые на порт и посылает их серверу через шифрованный туннель, который расшифровывает их и передает их открытым текстом на mailserver, порт 110
  • При завершении сеанса любой из точек, туннель также прекращает существование.

Отладка перенаправления

Давайте рассмотрим этот механизм, используя опцию отладки: 

xahria@desktop$ ssh -v -L 9999:mailserver:110 shellserver 
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: Connecting to shellserver [296.62.257.251] port 22.
debug1: Connection established.
debug1: identity file /home/bri/.ssh/identity type 0
debug1: identity file /home/bri/.ssh/id_rsa type 1
debug1: identity file /home/bri/.ssh/id_dsa type 2
...
debug1: Next authentication method: password
xahria@shellserver's password: ********
debug1: Authentication succeeded (password).
debug1: Connections to local port 9999 forwarded to remote address localhost:110
debug1: Local forwarding listening on 127.0.0.1 port 9999.
debug1: channel 0: new [client-session]
debug1: Entering interactive session.
debug1: channel 0: request pty-req
debug1: channel 0: request shell
xahria@shellserver$

Как вы видите, порт 9999 резервируется для открытия туннеля. В настоящее время мы не соединяемя с этим портом, поэтому туннель не открыт. Вы можете использовать escape-последовательность ~# для просмотра соединений. Эта последовательность работает только после символа перевода каретки, поэтому вам придется сделать так: 

xahria@shellserver$ (enter)
xahria@shellserver$ (enter)
xahria@shellserver$ (enter)
xahria@shellserver$ ~#
The following connections are open:
  #1 client-session (t4 r0 i0/0 o0/0 fd 5/6)
xahria@shellserver$

Видим, что в системе открыта только одна SSH-сессия, используя именно ее, мы вводим текущие команды unix.

Так, а теперь попробуем выполнить команду telnet localhost 9999 и просмотрим состояние соединений: 

xahria@shellserver$ (enter)
xahria@shellserver$ ~#
The following connections are open:
  #1 client-session (t4 r0 i0/0 o0/0 fd 5/6)
  #2 direct-tcpip: listening port 9999 for mailserver port 110,
                   connect from 127.0.0.1 port 42789 (t4 r1 i0/0
                   o0/0 fd 8/8)

И что же мы видим? Таки туннель был создан! Мы можем воспользоваться утилитами netstat или lsof, чтобы увидеть соединение с 127.0.0.1, порт 42789 на 127.0.0.1, порт 9999.

Пример удаленного перенаправления

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

Приведем классический пример использования удаленного перенаправления.Вы весь в работе, а на выходные VPN доступ закрывается на техническое обслуживание. Однако, у вас действительно имеется очень важная работа, но вы предпочитаете делать ее дома, вместо того, что бы торчать в офисе в выходные. И по SSH к вашей рабочей машине никак не пробиться, ибо наличествует фаервол. Значит, перед уходом домой, сделаем пару движений. Ваш ~/.ssh/config должен содержать такие строки: 

lainee@work$ tail ~/.ssh/config
  Host home-with-tunnel
     Hostname      204.225.288.29
     RemoteForward 2222:localhost:22
     User          laineeboo

lainee@work$ ssh home-with-tunnel
laineeboo@204.225.228.29's password: ********
  
laineeboo@home$ ping -i 5 127.0.0.1
PING 127.0.0.1 (127.0.0.1): 56 data bytes
64 bytes from 127.0.0.1: icmp_seq=0 ttl=255 time=0.1 ms
64 bytes from 127.0.0.1: icmp_seq=1 ttl=255 time=0.2 ms
64 bytes from 127.0.0.1: icmp_seq=2 ttl=255 time=0.2 ms
...

Мы утановили в файле конфигурации SSH опцию RemoteForward, она то и позволяет осуществить туннелирование (в случае использования командной строки используйте опцию -R). Для того, чтобы удостовериться, что наше соединение не блокируется системой сетевой защиты, выполним команду ping:

Вечером на домашней машине удостоверимся в удачном исходе дела: 

laineeboo@home$ last -1
laineeboo  pts/18   firewall.my_work.com Tue Nov 23 22:28   still logged in
  
laineeboo@home$ ps -t pts/18
 PID TTY          TIME CMD
3794 pts/18   00:00:00 ksh
4027 pts/18   00:00:00 ping -i 5 127.0.0.1

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

laineboo@home$ ssh -p 2222 lainee@localhost 
lainee@localhost's password: ********
  
lainee@work$

Port Forwarding Cheat Sheet

Помнить куда что перенаправляется - довольно непростая задача. Данная таблица должна помочь.

Локальное перенаправление

Опции командной строки -L local_listen_port:destination_host:destination_port
Строки в файле конфигурации LocalForward local_listen_port destination_host:destination_port
local_listen_port is on SSH client loopback interface
destination_host is contacted from SSH server host


Удаленное перенаправление

Опции командной строки -R remote_listen_port:destination_host:destination_port
Строки в файле конфигурации RemoteForward remote_listen_port:destination_host:destination_port
remote_listen_port is on SSH server loopback interface
destination_host is contacted from SSH client host

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

Безопасность перенаправления портов

Перенаправление занимает порт на ssh клиенте(локальное перенаправление) или на ssh сервере (удаленное перенаправление). По умолчанию, этот порт будет доступен только на кольцевом интерфейсе 127.0.0.1, это означает, что туннель будет доступен только локальному пользователю.

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

Command line option Configuration file option
LocalForwards -g GatewayPorts yes (in ~/.ssh/config or /etc/ssh/ssh_config)
RemoteForwards (none available) GatewayPorts yes (in /etc/sshd_config)

Другая важная вещь, которую Вы должны помнить - то, что поток данных шифруется только на участке между ssh клиентом b ssh сервером. Если определенный вами destination_host – не localhost, то то часть трафика не будет зашифрована. Рассмотрим пример: 

desktop$ ssh -L 8080:www.example.com:80 somemachine

Любое соединение с localhost:8080 будет зашифровано на участке от desktop до somemachine, но пойдет открытым текстом от somemachine до www.example.com. Если это соответствует вашей концепции безопасности, то проблемы нет.

Источники:

Советы по SSH

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

DenyHosts - блокируем подбор пароля

DenyHosts анализирует лог-файл, и при многократной ошибке авторизации добавляет атакующий хост в /etc/hosts.deny . Установка проста: 

# yum install denyhosts
# chkconfig denyhosts on
# service denyhosts start

Настройки по умолчанию вполне достаточны. Если же есть желание более тонкой подстройки, правим неплохо комментированный файл /etc/denyhosts.conf

Нестандартный порт сервера

Изменив порт который слушает ssh демон, мы отсечем большинство попыток атак. Для этого в файл /etc/ssh/sshd_config добавляем строку: 

Port 22022

и перезапускаем ssh сервер: 

# service sshd restart

На клиентской системе придется использовать параметр -p для ssh: 

$ ssh -p 22022 user@ssh-server

и -P для scp (а также явно указывать порт в другом ПО, например gftp, lftp при использовании sftp-протокола ): 

$ scp -P 22022  file.txt user@ssh-server:public_dir/

Клиентская машина не используется для разового соединения с удаленым сервером, то можно прописать соответствие хоста и порта в файл конфигурации пользователя (~/.ssh/config) или системы (/etc/ssh/ssh_config): 

Host ssh-server
Port 22022

Устанавливаем ограничение на доступ к файлу конфигурации: 

$ chmod 600 ~/.ssh/config file

Не забываем открыть новый порт ssh в конфигурации iptables.

Отключаем вход для root

Запретив вход для root по ssh, мы ограничим привелегии атакущего. Чтобы получить полный контроль над системой ему потребуется дополнительно узнать пароль непривилегерованого пользователя. Для этого в файл /etc/ssh/sshd_config добавляем строку: 

PermitRootLogin no

и перегружаем ssh сервер: 

# service sshd reload

SSH-клиенты и оболочки

  • GNU/Linux: kdessh, lsh-client, openssh-client, PuTTY
  • MS Windows и Windows NT: PuTTY, SecureCRT, ShellGuard, Axessh, ZOC, SSHWindows, ProSSHD
  • MS Windows Mobile: PocketPuTTy, mToken, sshCE, PocketTTY, OpenSSH, PocketConsole
  • Mac OS: NiftyTelnet SSH
  • Symbian OS: PuTTY
  • Java: MindTerm, AppGate Security Server
  • J2ME: MidpSSH
  • iPhone: pTerm, i-SSH, ssh (в комплекте с Terminal)
Источник — http://www.fedora.md/w/index.php?title=Все_что_Вы_хотели_знать_о_SSH&oldid=496