SSH: различия между версиями

Материал из ALT Linux Wiki
Нет описания правки
Строка 117: Строка 117:
Например:
Например:
  $ ssh-copy-id -i friends_pub_key myserver
  $ ssh-copy-id -i friends_pub_key myserver
== Настройка входа по одноразовому паролю ==
Вход по ключу - это, конечно хорошо (особенно если ключ ещё и защищён паролем), однако при входу из общественного места может не быть возможности использовать ключ (не дают тыкать свои флешки). А если такая возможность есть, то не факт, что ваш ключ не будет скопирован, а его пароль перехвачен во время ввода. В общем ключ - это просто более надёжный пароль: его тоже можно украсть и потом невозбранно использовать для входа под вашей учётной записью.
Для общественных мест хочется такую технологию входа, чтобы потенциальная компрометация ''всех'' учётных данных не дала возможности злоумышленнику войти в систему. И такая технология есть - это [http://ru.wikipedia.org/wiki/%D0%9E%D0%B4%D0%BD%D0%BE%D1%80%D0%B0%D0%B7%D0%BE%D0%B2%D1%8B%D0%B9_%D0%BF%D0%B0%D1%80%D0%BE%D0%BB%D1%8C одноразовые пароли]. Подробнее о том, как это работает можно прочитать в [http://habrahabr.ru/post/154229/ этой статье]. Для вас же их использование будут означать, что при входе в систему, помимо пароля, нужно будет вводить некий числовой код, который будет каждый раз разным.
В качестве инфраструктуры для одноразовых паролей мы возьмём [https://code.google.com/p/google-authenticator/ Google Authenticator], ибо всё необходимое уже есть в репозиториях. Нам понадобятся два пакета: libpam-google-authenticator и libqrencode (без последнего можно обойтись). Если пакета google нет в репозитории вашей платформы, то его несложно собрать самому в [[Hasher|хешере]], у него почти нет зависимостей.
Итак, пакеты установлены. На время настройки рутовую консоль лучше держать открытой.
Сначала создадим необходимые файлы у пользователя, который будет входить с одноразовым паролем. Входим под ним и выполняем:
google-authenticator
Будут заданы следующие вопросы:
* Сделать токены зависимыми от времени - y
* Здесь, если вы поставили libqrencode, вам будет показан QR-код. В приложении Google Authenticator а
на телефоне нужно создать новый аккаунт и отсканить этот код. Если не ставили библиотеку, перебивайте показанный код руками. В результате вам тут же будет сгенерирован текущий одноразовый пароль.
* Обновить файл ~/.google_authenticator? - y
* Запретить использование одного кода несколько раз - y
* Расширить время действия кода с 1,5 минут до 4? - n
* Запретить попытки входа чаще, чем 3 раза за 30 сек? - y
Всё, настройка для пользователя закончена. Идём ковырять систему (из-под рута, конечно).
Сначала OpenSSH. В /etc/openssh/sshd_config включаем вопрос-ответ:
ChallengeResponseAuthentication yes
И просим демона перечитать конфиг:
service sshd reload
Отлично, с SSH закончили. Теперь правим соответствующие настройки PAM (они лежат в /etc/pam.d/sshd). Обычно рекомендуют просто добавить гугловый пам в начало файла. В нашем случае это не заработает. Проблема в том, что модуль pam_userpass не хочет нормально работать в паре с гуглом. Если просто добавить гугл в pam.d/sshd, то независимо от порядка следования модулей, будет выводится только запрос на одноразовый пароль и всегда будет access denied.
Однако, не смотря на название, userpass не проверяет логин/пароль, он просто запрашивает их и сохраняет внутри стека pam. А проверяет их
[http://docs.altlinux.org/manpages/pam_tcb.8.html pam_tcb], причём он и сам умеет запрашивать пароль!
Решение очень простое - выкидываем userpass, вставляем на его место tcb
без параметра use_first_pass. После этип манипуляций конфиг должен выглядеть так:
#auth      required    pam_userpass.so
auth        required    pam_tcb.so shadow fork prefix=$2y$ count=8 nullok
auth        required    pam_google_authenticator.so echo_verification_code
#auth      include    common-login-use_first_pass
Весь остальной стек для auth выкидываем, ибо там тот же tcb и всякий ldap, который не нужен (если нужен, придётся перенести его сюда же).
Порядок следования модулей auth важен, при таком как в примере, сначала запрашивается пароль, затем всегда одноразовый код. Так невозможно
понять, что именно неверно, и это хорошо для безопасности. Если хотите, чтобы авторизация обламывалась сразу, замените required на requisite у
pam_tcb.


== Ссылки ==
== Ссылки ==

Версия от 10:43, 4 октября 2013

Stub.png
Данная страница находится в разработке.
Эта страница ещё не закончена. Информация, представленная здесь, может оказаться неполной или неверной.

Создание и настройка входа через ssh

Рассматривается вопрос создания ключа пользователя и настройки для авторизации на сервере в ssh через ключ. Предполагается что ssh-сервер запущен и имеет настройки, принятые по умолчанию в ALT Linux.

Введение

ssh (secure shell) — программа для входа на удалённую машину и выполнения на ней команд.

Создание ключа

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

$ ssh-keygen -t dsa

На вопрос о файле для сохранения ключа нажать Enter (по умолчанию). Далее будет задан вопрос о пароле к ключу. Пароль нужно указать.

В каталоге ~/.ssh появляются файлы

  • id_dsa — секретный ключ
  • id_dsa.pub — публичный ключ
Внимание! Никогда никому не пересылайте секретный ключ.

Настройка входа (на сервере)

Для того, чтобы пользователь мог авторизоваться в системе через ssh-ключ, нужно в файл ~/.ssh/authorized_keys добавить содержимое файла id_dsa.pub. Если пользователь будет один входить под этой учётной записью, файл id_dsa.pub можно просто скопировать, назвав authorized_keys. Также можно воспользоваться утилитой ssh-copy-id, если копировать вручную не хочется: ssh-copy-id user@host

Данные изменения проводятся в каталоге пользователя на сервере.

Обратите внимание на права файлов:
-rw------- authorized_keys
-rw-r--r-- config

и на каталог

drwx------ .ssh

принадлежать файлы должны пользователю и его группе.

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

$ xfconf-query -c xfce4-session -p /startup/ssh-agent/type -s "ssh-agent" -t string -n

Изменение вступит в силу после перелогина.

Проверка того, что ключ работает:
1. $ ssh-add
2. $ ssh другая_машина
При подключении не должен запрашиваться пароль.

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

$ ssh user@host.name

Конфигурационный файл (у пользователя)

Для удобства в файле ~/.ssh/config можно указать сокращение

Host    myserv
        HostName host.name

и вызывать просто как

$ ssh myserv

Можно добавить ещё настроек:

Host myserv
...
        User user
        Protocol 2
        ForwardX11 yes
        ForwardAgent yes
        Compression yes

Чтобы не указывать пароль каждый раз при обращении к серверу, можно запустить

$ ssh-add

Будет спрошен пароль и расшифрованный ключ запомнится на время вашего сеанса. Это сработает если запущен ssh-agent (в ALT Linux он запускается автоматически при графическом входе в систему).

Настройка сервера

Инструкция по установке и настройке сервера ssh для администратора

Нужно установить пакет openssh-server, включить автоматический запуск при загрузке системы:

# chkconfig sshd on

В файле /etc/openssh/sshd_config укажите строку AllowUsers с перечислением пользователей, имеющих право подключаться к системе.

Например

AllowUsers guest test best

А также рекомендуется выключить аутентификацию по паролю (исправить строчку PasswordAuthentication на):

PasswordAuthentication no

Для вступления настроек в силу:

# service sshd reload

LDAP

Чтобы sshd мог пускать пользователей из LDAP, нужно выполнить

control system-auth ldap

Управление сессиями

PAM session management в openssh той версии, которая находится в Сизифе и дистрибутивах, использует privilege separation и потому исполняется с правами пользователя, а не root. Как следствие,

  • pam_mktemp не сможет создать подкаталог в /tmp/.private/ с нужными правами, если его там нет;
  • pam_mkhomedir не сможет создать подкаталог с нужными правами, если его там нет;
  • pam_limits не сможет увеличить лимиты сверх тех, что есть у процесса openssh.

В качестве объезда можно помещать эти модули в PAM account management.

Полезные советы

Предотвращение брутфорс-атак

  • Можно пересадить sshd на нестандартный порт
  • Целесообразно ограничить число «ожидающих» соединений, когда пароль еще не введен. Для этого, в файле /etc/openssh/sshd_config укажите строку
MaxStartups 2:70:10

В этом случае у вас будут разрешены только 2 «ожидающих» соединения, и каждое следующее будет сброшено с вероятностью 70 %

  • Для особо изощрённой защиты можно использовать knock.
  • Можно ограничить число попыток средствами iptables:
iptables -A INPUT -p TCP --syn --dport 22 -m recent --name ssh_rate_limit --set
iptables -A INPUT -p TCP --syn --dport 22 -m recent --name ssh_rate_limit --update --seconds 60 --hitcount 4 -j LOG
iptables -A INPUT -p TCP --syn --dport 22 -m recent --name ssh_rate_limit --update --seconds 60 --hitcount 4 -j DROP

Для оптимизации этого дела настроятельно рекомендуется завести цель LOGDROP.

Настройка второго sshd

Копируем /etc/init.d/sshd и указываем через -f другой конфигурационный файл? Практика показывает, что надо менять весь набор: копировать /etc/init.d/sshd, /etc/sysconfig/sshd; (факультативно делать ссылки или копировать сам sshd, /etc/pam.d/sshd); изменять посредством /etc/sysconfig/sshd переменные PIDFILE, LOCKFILE, EXTRAOPTIONS.

Копирование ключа на сервер

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

$ ssh-copy-id

Например:

$ ssh-copy-id -i friends_pub_key myserver

Настройка входа по одноразовому паролю

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

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

В качестве инфраструктуры для одноразовых паролей мы возьмём Google Authenticator, ибо всё необходимое уже есть в репозиториях. Нам понадобятся два пакета: libpam-google-authenticator и libqrencode (без последнего можно обойтись). Если пакета google нет в репозитории вашей платформы, то его несложно собрать самому в хешере, у него почти нет зависимостей.

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

google-authenticator

Будут заданы следующие вопросы:

  • Сделать токены зависимыми от времени - y
  • Здесь, если вы поставили libqrencode, вам будет показан QR-код. В приложении Google Authenticator а

на телефоне нужно создать новый аккаунт и отсканить этот код. Если не ставили библиотеку, перебивайте показанный код руками. В результате вам тут же будет сгенерирован текущий одноразовый пароль.

  • Обновить файл ~/.google_authenticator? - y
  • Запретить использование одного кода несколько раз - y
  • Расширить время действия кода с 1,5 минут до 4? - n
  • Запретить попытки входа чаще, чем 3 раза за 30 сек? - y

Всё, настройка для пользователя закончена. Идём ковырять систему (из-под рута, конечно).

Сначала OpenSSH. В /etc/openssh/sshd_config включаем вопрос-ответ:

ChallengeResponseAuthentication yes

И просим демона перечитать конфиг:

service sshd reload

Отлично, с SSH закончили. Теперь правим соответствующие настройки PAM (они лежат в /etc/pam.d/sshd). Обычно рекомендуют просто добавить гугловый пам в начало файла. В нашем случае это не заработает. Проблема в том, что модуль pam_userpass не хочет нормально работать в паре с гуглом. Если просто добавить гугл в pam.d/sshd, то независимо от порядка следования модулей, будет выводится только запрос на одноразовый пароль и всегда будет access denied.

Однако, не смотря на название, userpass не проверяет логин/пароль, он просто запрашивает их и сохраняет внутри стека pam. А проверяет их pam_tcb, причём он и сам умеет запрашивать пароль!

Решение очень простое - выкидываем userpass, вставляем на его место tcb без параметра use_first_pass. После этип манипуляций конфиг должен выглядеть так:

#auth       required    pam_userpass.so
auth        required    pam_tcb.so shadow fork prefix=$2y$ count=8 nullok
auth        required    pam_google_authenticator.so echo_verification_code
#auth       include     common-login-use_first_pass

Весь остальной стек для auth выкидываем, ибо там тот же tcb и всякий ldap, который не нужен (если нужен, придётся перенести его сюда же).

Порядок следования модулей auth важен, при таком как в примере, сначала запрашивается пароль, затем всегда одноразовый код. Так невозможно понять, что именно неверно, и это хорошо для безопасности. Если хотите, чтобы авторизация обламывалась сразу, замените required на requisite у pam_tcb.

Ссылки