SSH keys (Русский)

From ArchWiki
(Redirected from SSH Keys (Русский))
Jump to: navigation, search

Tango-preferences-desktop-locale.pngЭта страница нуждается в сопроводителеTango-preferences-desktop-locale.png

Статья не гарантирует актуальность информации. Помогите русскоязычному сообществу поддержкой подобных страниц. См. Команда переводчиков ArchWiki
Состояние перевода: На этой странице представлен перевод статьи SSH keys. Дата последней синхронизации: 2014-10-22. Вы можете помочь синхронизировать перевод, если в английской версии произошли изменения.

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

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

У метода использования ключей SSH есть определенные недостатки, и он подходит не для всех, но при этом во многих случаях он может предложить несколько существенных преимуществ. Общее понимание того, как работают ключи SSH, поможет вам решить, как и когда применять их для удовлетворения ваших потребностей. Если вы собираетесь читать эту статью, предполагается, что вы уже знаете основы работы протокола Secure Shell и установили пакет openssh.

Описание

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

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

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

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

Генерация пары ключей SSH

Пара ключей SSH может быть сгенерирована при помощи команды ssh-keygen:

$ ssh-keygen -t ecdsa -b 521 -C "$(whoami)@$(hostname)-$(date -I)"
Generating public/private ecdsa key pair.
Enter file in which to save the key (/home/username/.ssh/id_ecdsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/username/.ssh/id_ecdsa.
Your public key has been saved in /home/username/.ssh/id_ecdsa.pub.
The key fingerprint is:
dd:15:ee:24:20:14:11:01:b8:72:a2:0f:99:4c:79:7f username@localhost-2011-12-22
The key's randomart image is:
+--[ECDSA  521]---+
|     ..oB=.   .  |
|    .    . . . . |
|  .  .      . +  |
| oo.o    . . =   |
|o+.+.   S . . .  |
|=.   . E         |
| o    .          |
|  .              |
|                 |
+-----------------+

В данном примере команда ssh-keygen генерирует пару (открытый и закрытый) ключей ECDSA (-t ecdsa) длиной 521 бит (-b 521) с расширенным комментарием, включающим указанные данные (-C "$(whoami)@$(hostname)-$(date -I)"). Изображение randomart было введено в OpenSSH 5.1 в качестве простого средства визуальной идентификации отпечатка ключа.

Выбор типа шифрования

Обеспечивая примерно такой же уровень безопасности, как и предыдущие методы, ECDSA (the Elliptic Curve Digital Signature Algorithm) предусматривает меньший размер ключей и более быстрое выполнение операций. Он был введен в качестве предпочтительного алгоритма для аутентификации в OpenSSH 5.7 (смотрите примечания к выпуску OpenSSH 5.7). Ключи ECDSA могут быть несовместимы с системами, которые используют старые версии OpenSSH. Некоторые производители также отключают необходимые реализации в связи с возможным появлением патентных вопросов.

Примечание: По состоянию на 28 декабря 2013 г. SSH-клиент для Windows "PuTTY" не поддерживает ECDSA и, следовательно, не может подключаться к серверам, использующим ключи ECDSA
Примечание: По состоянию на 10 июня 2014 г. ключи ECDSA не будут работать в Gnome Keyring (связке ключей GNOME) из-за известного бага GNOME

Если вы хотите создать пару ключей RSA (2048-16384 бит) или DSA (2048 бита) вместо ECDSA, используйте параметр -t rsa или -t dsa соответственно в вашей команде ssh-keygen и не забудьте увеличить размер ключа. Выполнение ssh-keygen без параметра -b установит разумные значения по умолчанию.

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

Выбор места расположения ключа и пароля

Во время выполнения команды ssh-keygen вам будет предложено выбрать подходящие имя и место расположения для вашего закрытого ключа. По умолчанию ключи будут расположены в каталоге ~/.ssh/ и названы в соответствии с используемым типом шифрования. Рекомендуем вам принять имя и расположение, предлагаемые по умолчанию, чтобы примеры, приведенные далее в этой статье, работали корректно.

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

Также есть возможность создать ваш закрытый ключ без пароля. Это может быть удобным, но вы должны знать о возможных рисках. При отсутствии пароля ваш закрытый ключ будет храниться на диске в незашифрованном виде. Любой человек, который получит доступ к файлу вашего закрытого ключа, будет иметь возможность подключаться ко всем серверам SSH, к которым вы подключаетесь, используя аутентификацию при помощи ключей. Кроме того, без пароля вы должны доверять суперпользователю (root), поскольку он может обойти права доступа к файлу и получить незашифрованный закрытый ключ в любой момент.

Изменение пароля закрытого ключа без изменения самого ключа

Если выбранный пароль для ключа SSH нежелателен или должен быть изменен, можно использовать команду ssh-keygen, не меняя при этом самого ключа.

Для смены пароля закрытого ключа RSA выполните следующую команду:

$ ssh-keygen -f ~/.ssh/id_rsa -p

Управление несколькими ключами

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

Host ИМЯ_СЕРВЕРА1
  IdentitiesOnly yes
  IdentityFile ~/.ssh/id_rsa_SERVER1
  # CheckHostIP yes
  # Port 22
Host ИМЯ_СЕРВЕРА2
  IdentitiesOnly yes
  IdentityFile ~/.ssh/id_rsa_SERVER2
  # CheckHostIP no
  # Port 2177
ControlMaster auto
ControlPath /tmp/%r@%h:%p

Гораздо больше опций вы найдете на странице справочного руководства:

$ man ssh_config 5

Копирование открытого ключа на удаленный сервер

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

Простой метод

Примечание: Этот метод может не сработать, если на удаленном сервере по умолчанию используется "не-sh оболочка", вроде tcsh. Смотрите этот багрепорт

Если ваш ключ хранится в файле ~/.ssh/id_rsa.pub, достаточно выполнить следующую команду:

$ ssh-copy-id remote-server.org

Если ваше имя пользователя на удаленной машине отличается, не забудьте предварить имя сервера именем пользователя, разделив их знаком @:

$ ssh-copy-id имя_пользователя@remote-server.org

Если имя файла вашего открытого ключа отличается от используемого по умолчанию ~/.ssh/id_rsa.pub, вы увидите ошибку /usr/bin/ssh-copy-id: ERROR: No identities found. В этом случае вы должны прямо указать расположение открытого ключа:

$ ssh-copy-id -i ~/.ssh/id_ecdsa.pub имя_пользователя@remote-server.org

Если сервер ssh прослушивает порт, отличный от используемого по умолчанию порта 22, не забудьте указать это:

$ ssh-copy-id -i ~/.ssh/id_ecdsa.pub -p 221 имя_пользователя@remote-server.org

Традиционный метод

По умолчанию, принятому в OpenSSH, открытый ключ должен быть "связан" (concatenated) с ~/.ssh/authorized_keys. Начните копирование открытого ключа на удаленный сервер:

$ scp ~/.ssh/id_ecdsa.pub имя_пользователя@remote-server.org:

Приведенная команда копирует открытый ключ (id_ecdsa.pub) в ваш домашний каталог на удаленном сервере, используя scp. Не забудьте поставить двоеточие (:) в конце адреса сервера. Также помните, что имя вашего открытого ключа может отличаться от имени, использованного в приведенном примере.

На удаленном сервере вам необходимо создать каталог ~/.ssh, если он еще не существует, и добавить ваш открытый ключ в файл authorized_keys:

$ ssh имя_пользователя@remote-server.org
имя_пользователя@remote-server.org's password:
$ mkdir ~/.ssh
$ chmod 700 ~/.ssh
$ cat ~/id_ecdsa.pub >> ~/.ssh/authorized_keys
$ rm ~/id_ecdsa.pub
$ chmod 600 ~/.ssh/authorized_keys

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

Безопасность

Обеспечение безопасности файла authorized_keys

Для дополнительной защиты вы можете запретить пользователям добавлять новые открытые ключи и подключаться с их помощью.

Сделайте файл authorized_keys доступным только для чтения пользователям и запретите все остальное:

$ chmod 400 ~/.ssh/authorized_keys

Для того, чтобы лишить пользователей возможности вернуть права доступа обратно, установите защитный (immutable) бит для файла authorized_keys:

# chattr +i ~/.ssh/authorized_keys

После этого у пользователей остается возможность переименовать каталог ~/.ssh и создать другую директорию с именем ~/.ssh, а в ней - другой файл authorized_keys. Чтобы запретить эти действия установите защитный (immutable) бит для каталога ~/.ssh:

# chattr +i ~/.ssh
Примечание: Если вам в дальнейшем будет необходимо добавить новый ключ, сперва понадобится убрать защитный бит с файла authorized_keys и предоставить права на запись. После того, как вы внесете необходимые изменения, следуйте инструкциям, приведенным выше, чтобы вновь обеспечить безопасность этого файла

Отключение входа по паролю

Несмотря на то, что копирование вашего открытого ключа на удаленный сервер SSH исключает необходимость передавать пароль через сеть, оно не дает никакой дополнительной защиты против брут-форс (brute-force) атак. В случае отсутствия нужного открытого ключа сервер SSH предложит аутентификацию по паролю, предоставляя таким образом злоумышленнику возможность попытаться получить доступ подбором пароля. Чтобы отключить подобное поведение, отредактируйте следующие строки в файле /etc/ssh/sshd_config на удаленном сервере:

/etc/ssh/sshd_config
PasswordAuthentication no
ChallengeResponseAuthentication no

Двухфакторная аутентификация и открытые ключи

Начиная с OpenSSH версии 6.2, вы можете добавить свою собственную систему (chain) для аутентификации при помощи опции AuthenticationMethods. Это позволит вам использовать открытые ключи так же, как и двухфакторную авторизацию.

Для настройки аутентификатора Google смотрите статью Google Authenticator.

Для использования PAM с OpenSSH отредактируйте следующие строки:

/etc/ssh/sshd_config
ChallengeResponseAuthentication yes
AuthenticationMethods publickey keyboard-interactive:pam

Теперь вы можете подключиться либо при помощи открытого ключа, либо при помощи комбинации пароля и проверочного кода.

Агенты SSH

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

Агент SSH - это программа, которая кэширует ваши зашифрованные закрытые ключи и предоставляет их программам-клиентам SSH от вашего имени. При их использовании вы должны будете ввести ваш пароль только один раз: при добавлении закрытого ключа в кэш агента. Это может быть очень удобно при частом подключении по SSH.

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

ssh-agent

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

$ ssh-agent
SSH_AUTH_SOCK=/tmp/ssh-vEGjCM2147/agent.2147; export SSH_AUTH_SOCK;
SSH_AGENT_PID=2148; export SSH_AGENT_PID;
echo Agent pid 2148;

Чтобы использовать эти переменные, выполните команду с использованием eval:

$ eval $(ssh-agent)
Agent pid 2157

Вы можете добавить приведенную команду в ваш ~/.bash_profile, чтобы агент запускался автоматически при входе в систему:

$ echo 'eval $(ssh-agent)' >> ~/.bash_profile

Если вы хотите, чтобы ssh-agent запускался автоматически вне зависимости от того, кто из пользователей входит в систему, примените эту команду к другому файлу - /etc/profile:

# echo 'eval $(ssh-agent)' >> /etc/profile

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

$ ssh-add ~/.ssh/id_ecdsa
Enter passphrase for /home/user/.ssh/id_ecdsa:
Identity added: /home/user/.ssh/id_ecdsa (/home/user/.ssh/id_ecdsa)

Если вы захотите, чтобы ваши закрытые ключи добавлялись автоматически при входе в систему, добавьте следующую команду в ваш ~/.bash_profile:

$ ssh-add

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

Если вы хотите получать предложение ввести пароль только тогда, когда он понадобится, добавьте

$ ssh-add -l >/dev/null || alias ssh='ssh-add -l >/dev/null || ssh-add && unalias ssh; ssh'

в файл ~/.bashrc, чтобы ssh-add запускался при необходимости.

Недостатком этого подхода является то, что новый экземпляр ssh-agent будет запускаться при каждом новом входе в систему, и каждый экземпляр будет сохраняться между сессиями. Через некоторое время вы можете столкнуться с тем, что будет запущено много ненужный копий ssh-agent. Существую фронт-энды к ssh-agent, а также альтернативные агенты, которые описаны далее в этом разделе, не допускающие подобного поведения.

ssh-agent в качестве программы-обертки

Альтернативная возможность запуска ssh-agent (например, с каждой X-сессией) описана в этом руководстве по ssh-agent от UC Berkeley Labs. Основной вариант использования - запуск X-сессии при помощи команды startx. В этом случае вы можете использовать префикс ssh-agent, как указано в следующем примере:

$ ssh-agent startx

В этом случае нет необходимости думать о том, чтобы добавлять алиасы в ваш файл .bash_aliases или ему подобные:

alias startx='ssh-agent startx'

Использование данного метода решает проблему запуска множества процессов ssh-agent. Только один процесс будет работать до тех пор, пока запущена X-сессия.

Примечание: Также вы можете добавить строку eval $(ssh-agent) в файл ~/.xinitrc

Обратитесь к данным заметкам для использования x11-ssh-askpass вместе с ssh-add по вопросу, связанному с быстрым добавлением вашего ключа в агент.

Агент GnuPG

Агент GnuPG, распространяемый в пакете gnupg, доступном в официальных репозиториях, имеет поддержку эмуляции агента OpenSSH. Если вы уже используете GnuPG, вы можете также кэшировать ваши ключи SSH с его помощью. Также некоторые пользователи могут предпочесть диалог ввода PIN-кода, который имеется в агенте GnuPG как часть его системы управления паролями.

Примечание: Если вы используете KDE и у вас установлен пакет kde-agent[ссылка недействительна: package not found], вам необходимо лишь добавить enable-ssh-support в файл ~/.gnupg/gpg-agent.conf! В ином случае продолжайте чтение

Чтобы начать использовать агент GnuPG для ваших ключей SSH, необходимо сперва запустить gpg-agent с опцией --enable-ssh-support. Пример (не забудьте сделать файл исполняемым):

/etc/profile.d/gpg-agent.sh
#!/bin/sh

# Start the GnuPG agent and enable OpenSSH agent emulation
gnupginf="${HOME}/.gpg-agent-info"

if pgrep -x -u "${USER}" gpg-agent >/dev/null 2>&1; then
    eval `cat $gnupginf`
    eval `cut -d= -f1 $gnupginf | xargs echo export`
else
    eval `gpg-agent -s --enable-ssh-support --daemon --write-env-file "$gnupginf"`
fi

После запуска gpg-agent вы можете использовать ssh-add для добавления ключей так же, как вы это делали с ssh-agent. Список санкционированных ключей находится в файле ~/.gnupg/sshcontrol. Как только ваш ключ будет принят, вы увидите диалог ввода PIN-кода каждый раз, когда потребуется ваш пароль. Вы можете управлять кэшированием паролей в файле ~/.gnupg/gpg-agent.conf. Следующий пример заставит gpg-agent кэшировать ваши ключи на протяжении трех часов:

~/.gnupg/gpg-agent.conf
  # Cache settings
  default-cache-ttl 10800
  default-cache-ttl-ssh 10800

Среди других полезных настроек в этом файле - программа ввода PIN-кода (версии GTK, QT или ncurses), захват клавиатуры (keyboard grabbing) и прочее...

Примечание: gpg-agent.conf должен быть создан, и должна быть установлена переменная write-env-file, чтобы позволить ключам gpg-agent вводиться в SSH, пока вы не перезапустите gpg-agent, и, следовательно, экспортировать эти настройки при каждом входе
~/.gnupg/gpg-agent.conf
  # Environment file
  write-env-file /home/username/.gpg-agent-info
  
  # Keyboard control
  #no-grab
    
  # PIN entry program
  #pinentry-program /usr/bin/pinentry-curses
  #pinentry-program /usr/bin/pinentry-qt4
  #pinentry-program /usr/bin/pinentry-kwallet
  pinentry-program /usr/bin/pinentry-gtk-2

Чтобы использовать агент, вы можете указать в качестве источника и экспортировать переменные окружения, которые gpg-agent записывает в .gpg-agent-info, файл, указанный в write-env-file:

~/.bashrc
...

if [ -f "${HOME}/.gpg-agent-info" ]; then
  . "${HOME}/.gpg-agent-info"
  export GPG_AGENT_INFO
  export SSH_AUTH_SOCK
fi

Keychain

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

Установите пакет keychain, доступный в официальных репозиториях.

Добавьте следующую строку в файл ~/.bash_profile или создайте /etc/profile.d/keychain.sh от имени суперпользователя, после чего сделайте его исполняемым (например, chmod 755 keychain.sh):

~/.bash_profile
eval $(keychain --eval --agents ssh -Q --quiet id_ecdsa)

В данном примере флаг --eval выводит строки команды eval. Это позволяет необходимым переменным окружения клиента SSH использоваться в вашем агенте. Флаг --agents не столь необходим, поскольку Keychain создаст список автоматически, основываясь на существовании в системе ssh-agent или gpg-agent. Добавление флага --quiet ограничит вывод предупреждениями, ошибками и обращениями к пользователю. Если вам необходима дополнительная безопасность, замените флаг -Q на --clear, но вам будет не так удобно.

Если необходимо, замените ~/.ssh/id_ecdsa на путь к вашему закрытому ключу. Если вы используете несовместимую с Bash оболочку, смотрите keychain --help или man keychain для получения информации по использованию.

Чтобы протестировать Keychain, завершите вашу сессию и войдите заново. Если вы запустили Keychain первый раз, будет предложено ввести пароль от указанного закрытого ключа. Поскольку Keychain продолжает использовать тот же процесс ssh-agent в успешных входах в систему, у вас не будет необходимости вводить пароль в следующий раз: это потребуется только после перезагрузки машины.

Альтернативные методы запуска

Существуют разнообразные способы запуска Keychain, и вам предлагается поэксперементировать, чтобы выбрать то, что будет работать у вас. Команда keychain имеет множество опций командной строки, которые описаны на странице руководства (man) Keychain.

Одна из доступных реализаций скрипта запуска Keychain - создание файла /etc/profile.d/keychain.sh от имени суперпользователя и добавление в него следующих строк:

/etc/profile.d/keychain.sh
/usr/bin/keychain -Q -q --nogui ~/.ssh/id_ecdsa
[[ -f $HOME/.keychain/$HOSTNAME-sh ]] && source $HOME/.keychain/$HOSTNAME-sh

Не забудьте также сделать файл /etc/profile.d/keychain.sh исполняемым, изменив его права доступа:

# chmod 755 /etc/profile.d/keychain.sh

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

alias ssh='eval $(/usr/bin/keychain --eval --agents ssh -Q --quiet ~/.ssh/id_ecdsa) && ssh'

При этом запрос появится тогда, когда вы используете SSH в первый раз. Помните, однако, что подобный запрос будет лишь в том случае, если ~/.bashrc будет применим (applicable). Так что вам необходимо будет проверять, что ваша первая команда SSH будет выполняться в терминале.

envoy

Альтернативой keychain является envoy. Envoy доступен в пакете envoy из официальных репозиториев. Также можно воспользоваться Git-версией из AUR, установив пакет envoy-gitAUR.

После установки включите сокет командой

 # systemctl enable envoy@ssh-agent.socket

и добавьте следующие строки в файл rc вашей оболочки:

 envoy -t ssh-agent -a ключ_ssh
 source <(envoy -p)

Если ключ расположен в файле ~/.ssh/id_rsa, ~/.ssh/id_dsa, ~/.ssh/id_ecdsa или ~/.ssh/identity, нет необходимости указывать параметр -a ключ_ssh.

envoy с паролями ключей, хранящимися в kwallet

Если вы установили длинные пароли для ваших ключей SSH, возможно, вам будет трудно их помнить. Давайте сделаем так, чтобы этим занимался kwallet! Помимо пакета envoy установите ksshaskpass и kdeutils-kwalletmanager[ссылка недействительна: replaced by kwalletmanager] из официальных репозиториев. После этого включите сокет envoy в systemd (см. выше).

Создайте скрипт ~/.kde4/Autostart/ssh-agent.sh:

#!/bin/sh
envoy -t ssh-agent -a ключ_ssh

Затем сделайте этот скрипт исполняемым, выполнив команду chmod +x ~/.kde4/Autostart/ssh-agent.sh

Добавьте следующие строки в файл ~/.kde4/env/ssh-agent.sh:

#!/bin/sh
eval $(envoy -p)

Когда вы войдете в сеанс KDE, запустится скрипт ssh-agent.sh. Он, в свою очередь, вызовет ksshaskpass, который предложит вам ввести пароль kwallet, когда envoy запустит ssh-agent.

x11-ssh-askpass

Пакет x11-ssh-askpass предоставляет диалоговое окно с графическим интерфейсом для ввода вашего пароля в X-сессии. x11-ssh-askpass имеет в зависимостях только библиотеки libx11 и libxt, а его внешний вид можно настраивать. Несмотря на то, что это диалоговое окно может быть вызвано программой ssh-add, которая затем загрузит ваши зашифрованные ключи в #ssh-agent, приведенная инструкция позволит настроить x11-ssh-askpass на работу с приведенным выше скриптом #Keychain.

Установите пакеты keychain и x11-ssh-askpass, доступные в официальных репозиториях.

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

~/.xinitrc
keychain ~/.ssh/id_ecdsa
[ -f ~/.keychain/$HOSTNAME-sh ] && . ~/.keychain/$HOSTNAME-sh 2>/dev/null
[ -f ~/.keychain/$HOSTNAME-sh-gpg ] && . ~/.keychain/$HOSTNAME-sh-gpg 2>/dev/null
...
exec openbox-session

В данном примере первая строка запускает keychain и передает имя и место расположения вашего закрытого ключа. Если это не первый запуск keychain, следующие две строки загружают содержимое из $HOSTNAME-sh и $HOSTNAME-sh-gpg, если они существуют. Эти файлы хранят переменные окружения из предыдущих запусков keychain.

Вызов x11-ssh-askpass вместе с ssh-add

Страница руководства (man) по ssh-add указывает на то, что, помимо переменной DISPLAY, необходимо указать имя программы запроса пароля в переменной SSH_ASKPASS (в данном случае x11-ssh-askpass). Стоит иметь в виду, что стандартная установка Arch Linux разместит двоичный файл x11-ssh-askpass в каталоге /usr/lib/ssh/, который у большинства пользователей не прописан в PATH. Это лишь небольшое замечание, важное не только при указании значения переменной SSH_ASKPASS, но и при настройке внешнего вида. Везде необходимо будет указывать полный путь. Это неудобство можно исправить созданием символьной ссылки:

$ ln -sv /usr/lib/ssh/x11-ssh-askpass ~/bin/ssh-askpass

При этом предполагается, что каталог ~/bin прописан в PATH. Теперь в вашем .xinitrc, перед запуском оконного менеджера, необходимо указать следующее:

$ export SSH_ASKPASS=ssh-askpass

и ваши Ресурсы Х будут содержать что-то вроде этого:

ssh-askpass*background: #000000

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

Настройка внешнего вида

Внешний вид диалогового окна x11-ssh-askpass может быть настроен в соответствующих Ресурсах Х. На домашней странице x11-ssh-askpass содержится несколько примеров тем. Смотрите страницу руководства (man) x11-ssh-askpass для получения дополнительных подробностей.

Альтернативные диалоговые окна ввода пароля

Существуют другие программы, предоставляющие диалоговые окна для ввода пароля, которые могут быть использованы вместо x11-ssh-askpass. В этом списке указаны некоторые из доступных решений:

  • ksshaskpass доступна в официальных репозиториях. Зависит от пакета kdelibs и подходит для тех, кто использует окружение KDE
  • openssh-askpass зависит от библиотек qt4 и доступна в официальных репозиториях

pam_ssh

Проект pam_ssh разрабатывается для использования подключаемых модулей аутентификации (PAM) с закрытыми ключами SSH. Этот модуль может предоставлять единое поведение ( single sign-on behavior) для ваших подключений по SSH. При входе ваш пароль от закрытого ключа SSH может быть введен вместо или в качестве дополнения к вашему традиционному паролю системы. Как только произойдет аутентификация, модуль pam_ssh заставит ssh-agent хранить ваш зашифрованный закрытый ключ на протяжении времени работы сессии.

Чтобы включить единое поведение в приглашении входа в tty, установите неофициальный пакет pam_sshAUR, доступный в AUR.

Примечание: pam_ssh 2.0 теперь требует, чтобы все закрытые ключи, используемые в процессе аутентификации, были расположены в каталоге ~/.ssh/login-keys.d/

Создайте символьную ссылку на файл вашего закрытого ключа и разместите ее в ~/.ssh/login-keys.d/. Замените id_rsa в приведенном ниже примере на имя вашего собственного файла закрытого ключа:

$ mkdir ~/.ssh/login-keys.d/
$ cd ~/.ssh/login-keys.d/
$ ln -s ../id_rsa

Отредактируйте конфигурационный файл /etc/pam.d/login, включив в него строки, отмеченные жирным шрифтом в приведенном ниже примере. Порядок следования строк является существенным и может повлиять на возможность входа в систему.

Важно: Создание неправильной конфигурации PAM может оставить систему в состоянии, при котором все пользователи окажутся заблокированными. Перед тем, как делать какие-либо изменения, вам необходимо понять, как работает конфигурация PAM. В качестве средства восстановления можно использовать, например, Arch Live CD, в случае, если вы заблокированы, и вам необходимо отменить изменения. В статье от IBM developerWorks настройка PAM рассматривается более детально
/etc/pam.d/login
#%PAM-1.0

auth       required     pam_securetty.so
auth       requisite    pam_nologin.so
auth       include      system-local-login
auth       optional     pam_ssh.so        try_first_pass
account    include      system-local-login
session    include      system-local-login
session    optional     pam_ssh.so

В приведенном выше примере аутентификация проходит так, как обычно, с приглашением ввести пароль пользователя. Дополнительное правило аутентификации auth, добавленное в конце, говорит модулю pam_ssh попробовать расшифровать любые закрытые ключи, найденные в каталоге ~/.ssh/login-keys.d. Опция try_first_pass передается модулю pam_ssh, говоря ему сперва попытаться расшифровать любые закрытые ключи SSH, используя только что введенный пароль пользователя. Если пароль пользователя и его закрытого ключа являются одинаковыми, ключ будет расшифрован, и не будет предлагаться ввести тот же пароль повторно. Если же они различаются, модуль pam_ssh предложит пользователю ввести пароль SSH после ввода пароля пользователя. Строка optional делает проверку того, что пользователи, у которых нет закрытых ключей SSH, по-прежнему могут входить в систему. В этом случае использование pam_ssh будет прозрачным для пользователей без закрытых ключей SSH.

Если вы используете другой способ входа в систему, например, дисплейный менеджер вроде SLiM или XDM, и хотите, чтобы он предоставлял вам похожий функционал, необходимо отредактировать его связанный с PAM файл конфигурации в похожем виде. Пакеты, предоставляющие поддержку PAM, обычно располагают конфигурационный файл по умолчанию в каталоге /etc/pam.d/.

Более подробную информацию по использованию pam_ssh, а также список его опций, вы можете найти на странице руководства (man) pam_ssh.

Известные проблемы pam_ssh

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

  • pam_ssh до версии 2.0 не поддерживает ключи SSH с новой криптографией ECDSA (elliptic curve). Если вы используете ранние версии pam_ssh, необходимо использовать ключи RSA или DSA
  • Процесс ssh-agent, вызываемый pam_ssh, не сохраняется между входами пользователей в систему. Если вам нравится сохранять сессию GNU Screen между входами, вы можете заметить во время повторного присоединения к вашей сессии, что теперь невозможно соединиться с ssh-agent. Это происходит потому, что окружение GNU Screen и его производные будут ссылаться на процесс ssh-agent, вызванный во время первого запуска GNU Screen, который был завершен во время выхода из сеанса. Keychain решает эту проблему, заставляя процесс ssh-agent работать между входами в систему.

GNOME Keyring

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

Решение проблем

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

$ chmod 700 ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/id_ecdsa

Для удаленной машины:

$ chmod 700 ~/
$ chmod 700 ~/.ssh
$ chmod 600 ~/.ssh/authorized_keys

Если это не решает проблему, вы можете попробовать временно установить StrictModes в значние no в файле sshd_config. Если аутентификация с отключенным StrictModes удастся, это может быть связано с сохранением прав доступа.

Tip: Не забудьте установить StrictModes в значение yes ради безопасности

Удостоверьтесь, что удаленная машина поддерживает тип ключей, который вы используете. Попробуйте использовать ключи RSA или DSA вместо генерации пары ключей SSH

Некоторые серверы не поддерживают ключи ECDSA

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

# /usr/bin/sshd -d

Использование kdm

KDM не запускает процесс ssh-agent напрямую, он использует пакет kde-agent[ссылка недействительна: package not found] для его запуска во время входа в систему, но, начиная с версии 20140102-1, он был удален.

Чтобы запускать ssh-agent при старте KDE для пользователя, создайте скрипт. То же самое необходимо для остановки ssh-agent при выходе из сеанса:

echo -e '#!/bin/sh\n[ -n "$SSH_AGENT_PID" ] || eval "$(ssh-agent -s)"' > ~/.kde4/env/ssh-agent-startup.sh
echo -e '#!/bin/sh\n[ -z "$SSH_AGENT_PID" ] || eval "$(ssh-agent -k)"' > ~/.kde4/shutdown/ssh-agent-shutdown.sh
chmod 755 ~/.kde4/env/ssh-agent-startup.sh ~/.kde4/shutdown/ssh-agent-shutdown.sh

Смотрите также