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

Материал из ALT Linux Wiki
Перейти к: навигация, поиск
(К викификации)
(Настройка входа (на сервере))
 
(не показано 25 промежуточных версий 13 участников)
Строка 1: Строка 1:
[[Категория:Admin]]
 
{{Викифицировать}}
 
 
{{Stub}}
 
{{Stub}}
{{MovedFromFreesourceInfo|AltLinux/Документация/НастройкаSSH}}
+
{{span|font-size: 180%|Создание и настройка входа через ssh}}
 
 
== Создание и настройка входа через ssh ==
 
  
 
Рассматривается вопрос создания ключа пользователя и настройки для авторизации на сервере в ssh через ключ.
 
Рассматривается вопрос создания ключа пользователя и настройки для авторизации на сервере в ssh через ключ.
Предполагается что ssh-сервер запущен и имеет настройки, принятые по умолчанию в ALTLinux.
+
Предполагается что ssh-сервер запущен и имеет настройки, принятые по умолчанию в ALT Linux.
 
 
__TOC__
 
 
 
  
=== Введение ===
+
== Введение ==
 +
ssh (secure shell) — программа для входа на удалённую машину и выполнения на ней команд.
  
ssh — программа для входа на удалённую машину и выполнения на ней команд.
+
== Создание ключа ==
 
+
В ssh используется асимметричное шифрование, соответственно используется пара из закрытого и открытого ключа.
=== Создание ключа ===
 
 
 
В ssh используется ассиметричное шифрование, соответственно используется пара из закрытого и открытого ключа.
 
 
Для создания ключа на компьютере пользователя нужно выполнить
 
Для создания ключа на компьютере пользователя нужно выполнить
<pre>$ ssh-keygen -b 2048 -t dsa</pre>
+
<pre>$ ssh-keygen -t ed25519</pre>
  
 
На вопрос о файле для сохранения ключа нажать Enter (по умолчанию). Далее будет задан вопрос о пароле к ключу. Пароль нужно указать.
 
На вопрос о файле для сохранения ключа нажать Enter (по умолчанию). Далее будет задан вопрос о пароле к ключу. Пароль нужно указать.
  
В каталоге ~/.ssh
+
В каталоге {{path|~/.ssh}}
 
появляются файлы
 
появляются файлы
* id_dsa — секретный ключ
+
* id_ed25519 — секретный ключ
* id_dsa.pub — публичный ключ
+
* id_ed25519.pub — публичный ключ
<div style="display: inline; color: red;">Внимание! Никогда никому не пересылайте секретный ключ.</div>
+
<div style="display: inline; color: red;">Внимание! Никогда никому не пересылайте '''секретный''' ключ.</div>
 +
 
 +
== Настройка входа (на сервере) ==
 +
Для того, чтобы пользователь мог авторизоваться в системе через ssh-ключ, нужно в файл {{path|~/.ssh/authorized_keys}} добавить содержимое файла {{path|id_ed25519.pub}}. Если пользователь будет один входить под этой учётной записью, файл {{path|id_ed25519.pub}} можно просто скопировать, назвав authorized_keys.
 +
Также можно воспользоваться утилитой {{prg|ssh-copy-id}}, если копировать вручную не хочется: {{cmd|ssh-copy-id user@host}}
  
=== Настройка входа (на сервере) ===
 
Для того, чтобы пользователь мог авторизоваться в системе через ssh-ключ, нужно в файл ~/.ssh/authorized_keys добавить содержимое файла id_dsa.pub. Если пользователь будет один входить под этой учётной записью, файл id_dsa.pub можно просто скопировать, назвав authorized_keys.
 
Также можно воспользоваться утилиой ssh-copy-id, если копировать вручную не хочется.
 
 
'''Данные изменения проводятся в каталоге пользователя ''на сервере'''''.
 
'''Данные изменения проводятся в каталоге пользователя ''на сервере'''''.
 
<div style="display: inline; color: red;">Обратите внимание на права файлов:</div>
 
<div style="display: inline; color: red;">Обратите внимание на права файлов:</div>
Строка 39: Строка 31:
 
и на каталог
 
и на каталог
 
<pre>drwx------ .ssh</pre>
 
<pre>drwx------ .ssh</pre>
принадлежать файлы должны пользователю и его группе
+
принадлежать файлы должны пользователю и его группе.
  
'' Настройку доступа на сервере можно посмотреть в разделе: [http://freesource.info/wiki//ALTLinux/Dokumentacija/NastrojjkaSSH#h576-6 Настройка сервера]''
+
Пользователям XFCE [https://bugzilla.altlinux.org/show_bug.cgi?id=27342 может потребоваться] включить явный запуск ssh-agent, чтобы его использовать:
 +
$ xfconf-query -c xfce4-session -p /startup/ssh-agent/type -s "ssh-agent" -t string -n
 +
Изменение вступит в силу после перелогина.
  
=== Использование ===
+
Проверка того, что ключ работает:
 +
<pre>$ ssh-add
 +
$ ssh другая_машина</pre>
 +
При подключении не должен запрашиваться пароль.
  
<pre>$ ssh user@server.fullname.ru</pre>
+
== Использование ==
 
+
$ ssh user@host.name
=== Конфигурационный файл (у пользователя) ===
 
  
 +
== Конфигурационный файл (у пользователя) ==
 
Для удобства в файле ~/.ssh/config можно указать сокращение
 
Для удобства в файле ~/.ssh/config можно указать сокращение
 
<pre>Host    myserv
 
<pre>Host    myserv
         HostName server.fullname.ru</pre>
+
         HostName host.name</pre>
  
 
и вызывать просто как
 
и вызывать просто как
<pre>$ ssh myserv</pre>
+
$ ssh myserv
  
 
Можно добавить ещё настроек:
 
Можно добавить ещё настроек:
Строка 66: Строка 63:
  
 
Чтобы не указывать пароль каждый раз при обращении к серверу, можно запустить
 
Чтобы не указывать пароль каждый раз при обращении к серверу, можно запустить
<pre>$ ssh-add</pre>
+
$ ssh-add
будет спрошен пароль и расшифрованный ключ запомнится на время вашего сеанса.
+
Будет спрошен пароль и расшифрованный ключ запомнится на время вашего сеанса. Это сработает если запущен ssh-agent (в ALT Linux он запускается автоматически при графическом входе в систему).
Это сработает если запущен ssh-agent (в ALT Linux он запускается автоматически при графическом входе в систему).
 
  
=== Настройка сервера ===
+
== Настройка сервера ==
  
==== sshd ====
+
=== Инструкция по установке и настройке сервера ssh для администратора ===
Инструкция по установке и настройке сервера ssh для администратора.
+
Нужно установить пакет {{pkg|openssh-server}}, включить автоматический запуск при загрузке системы:
Нужно установить пакет openssh-server, включить автоматический запуск при загрузке системы:
+
# chkconfig sshd on
<pre># chkconfig sshd on</pre>
+
В файле {{path|/etc/openssh/sshd_config}} укажите строку [[Документация/AllowUsers|AllowUsers]] с перечислением пользователей, имеющих право подключаться к системе (также существует опция AllowGroups); например:
В файле /etc/openssh/sshd_config укажите строку [[Документация/AllowUsers|AllowUsers]] с перечислением пользователей, имеющих право подключаться к системе.
+
AllowUsers guest test best
Например
+
 
<pre>AllowUsers guest test best</pre>
+
А также для исключения возможности подбора паролей локальных пользователей рекомендуется выключить аутентификацию по паролю (обратите внимание: создать, разложить и проверить их следует ''заранее''):
А также рекомендуется выключить аутентификацию по паролю (исправить строчку [[Документация/PasswordAuthentication|PasswordAuthentication]] на):
+
# control sshd-password-auth disabled
<pre>PasswordAuthentication no</pre>
 
  
 
Для вступления настроек в силу:
 
Для вступления настроек в силу:
<pre># service sshd reload</pre>
+
# service sshd reload
  
==== [[Документация/OpenLDAP|LDAP]] ====
+
=== [[OpenLDAP|LDAP]] ===
 +
Чтобы sshd мог пускать пользователей из LDAP, нужно выполнить
 +
# control system-auth ldap
  
Чтобы sshd мог пускать пользователей, живущих в LDAP, нужно немного подправить /etc/pam.d/sshd
+
== Управление сессиями ==
<pre>auth    required pam_userpass.so
+
PAM session management в openssh той версии, которая находится в Сизифе и дистрибутивах, использует [http://www.citi.umich.edu/u/provos/ssh/privsep.html privilege separation] и потому исполняется с правами пользователя, а не root. Как следствие,
auth sufficient pam_ldap.so use_first_pass
+
* [[pam_mktemp]] не сможет создать подкаталог в /tmp/.private/ с нужными правами, если его там нет;
auth    required pam_tcb.so shadow fork prefix=$2a$ count=8 nullok nodelay blank_nolog use_first_pass
+
* pam_mkhomedir не сможет создать подкаталог с нужными правами, если его там нет;
auth    required pam_nologin.so
+
* pam_limits не сможет увеличить лимиты сверх тех, что есть у процесса openssh.
account  include system-auth
 
password include system-auth
 
session  include system-auth</pre>
 
  
Думаю, не будет лишним указать содержимое /etc/pam.d/system-auth и system-auth-use_first_pass
+
В качестве объезда можно помещать эти модули в PAM account management.
  
'''Предупреждение''': с openssh-server версии openssh-3.6.1p2-alt6 из ALTLinux Master 2.4 pam_mkhomedir <div style="display: inline; color: red;">НЕ РАБОТАЕТ</div>, [https://bugzilla.altlinux.org/show_bug.cgi?id=6385 это решенный баг]. См. тж. ниже.
+
== Полезные советы ==
  
system-auth
+
=== Предотвращение брутфорс-атак ===
<pre>#%PAM-1.0
+
* Можно пересадить sshd на нестандартный порт
auth    sufficient pam_ldap.so
+
* Целесообразно ограничить число «ожидающих» соединений, когда пароль еще не введен. Для этого, в файле /etc/openssh/sshd_config укажите строку
auth     required pam_tcb.so shadow fork prefix=$2a$ count=8 nullok use_first_pass
+
MaxStartups 2:70:10
 +
В этом случае у вас будут разрешены только 2 «ожидающих» соединения, и каждое следующее будет сброшено с вероятностью 70 %
 +
* Для особо изощрённой защиты можно использовать [http://sisyphus.ru/srpm/knock 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.
 +
* Настроить {{pkg|fail2ban}}:
 +
В файл /etc/fail2ban/jail.d/customisation.local записать
 +
<pre>
 +
[sshd]
 +
enabled  = true
 +
filter  = sshd
 +
logpath  = /var/log/auth/messages
 +
maxretry = 3
 +
</pre>
 +
В файле /etc/openssh/sshd_config параметру '''UseDNS''' задать значение <tt>no</tt>.
  
account  sufficient pam_ldap.so
+
* Либо настроить {{pkg|sshutout}}, см. [http://www.techfinesse.com/sshutout/sshutout.html описание].
account  required pam_tcb.so shadow fork
 
password sufficient pam_ldap.so
 
password required pam_passwdqc.so min=disabled,24,12,8,7 max=40 passphrase=3 match=4 similar=deny random=42 enforce=users retry=3
 
password required pam_tcb.so use_authtok shadow fork prefix=$2a$ count=8 write_to=tcb
 
session  required      pam_mkhomedir.so skel=/etc/skel/ umask=0026
 
  
session  sufficient pam_ldap.so
+
=== Настройка второго sshd ===
#session  required      pam_mkhomedir.so skel=/etc/skel/ umask=0026
+
Копируем /etc/init.d/sshd и указываем через -f другой конфигурационный файл?
session  required pam_tcb.so
+
Практика показывает, что надо менять весь набор: копировать /etc/init.d/sshd, /etc/sysconfig/sshd; (факультативно делать ссылки или копировать сам sshd, /etc/pam.d/sshd); изменять посредством /etc/sysconfig/sshd переменные PIDFILE, LOCKFILE, EXTRAOPTIONS.
session  required pam_limits.so</pre>
 
  
  system-auth-use_first_pass
+
=== Копирование ключа на сервер ===
<pre>#%PAM-1.0
+
Если вам нужно добавить на сервер, куда вы имеете доступ, чей-то ключ, используйте
#auth    required pam_tcb.so shadow fork prefix=$2a$ count=8 nullok use_first_pass
+
  $ ssh-copy-id
#password required pam_tcb.so use_authtok shadow fork prefix=$2a$ count=8 write_to=tcb
+
Например:
auth sufficient /lib/security/pam_tcb.so shadow fork prefix=$2a$ count=8 nullok use_first_pass
+
$ ssh-copy-id -i friends_pub_key myserver
auth required /lib/security/pam_ldap.so use_first_pass
+
 
password sufficient /lib/security/pam_ldap.so use_authok
+
=== Cisco IOS и SSH 6.6p1 ===
password required /lib/security/pam_tcb.so use_authtok shadow fork prefix=$2a$ count=8 write_to=tcb</pre>
+
Ошибка при подключении:
 +
SSH2 0:  Client DH key range mismatch with max built-in DH key on server!
 +
 
 +
в ~/.ssh/config (что бы не переопределять глобально у остальных пользователей) добавить:
 +
 
 +
<pre>
 +
Host 192.168.1.*
 +
    KexAlgorithms diffie-hellman-group14-sha1,curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,\
 +
diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
 +
</pre>
 +
 
 +
т.е.  diffie-hellman-group14-sha1 - на первое место.
  
=== Управление сессиями ===
+
== Настройка входа по одноразовому паролю ==
<pre>Date: Fri, 27 May 2005 13:24:49 +0400
+
Вход по ключу - это, конечно хорошо (особенно если ключ ещё и защищён паролем), однако при входу из общественного места может не быть возможности использовать ключ (не дают тыкать свои флешки). А если такая возможность есть, то не факт, что ваш ключ не будет скопирован, а его пароль перехвачен во время ввода. В общем ключ - это просто более надёжный пароль: его тоже можно украсть и потом невозбранно использовать для входа под вашей учётной записью.
From: "Dmitry V. Levin" <ldv@>
 
To: <sisyphus@>
 
Subject: Re: [sisyphus] openssh update
 
  
PAM session management в openssh той версии, которая находится в
+
Для общественных мест хочется такую технологию входа, чтобы потенциальная компрометация ''всех'' учётных данных не дала возможности злоумышленнику войти в систему. И такая технология есть - это [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/ этой статье]. Для вас же их использование будут означать, что при входе в систему, помимо пароля, нужно будет вводить некий числовой код, который будет каждый раз разным.
Сизифе/дистрибутивах и использует privilege separation, исполняется
 
с правами пользователя, а не root'а. Как следствие,
 
- pam_mktemp не сможет создать подкаталог в /tmp/.private/ с нужными
 
  правами, если его там нет;
 
- pam_mkhomedir не сможет создать подкаталог с нужными правами, если его
 
  там нет;
 
- pam_limits не сможет увеличить лимиты сверх тех, что есть у процесса
 
  openssh.
 
  
В качестве workaround'а можно помещать это модули в PAM account
+
В качестве инфраструктуры для одноразовых паролей мы возьмём [https://code.google.com/p/google-authenticator/ Google Authenticator], ибо всё необходимое уже есть в репозиториях. Нам понадобятся два пакета: libpam-google-authenticator и libqrencode (без последнего можно обойтись). Если пакета google нет в репозитории вашей платформы, то его несложно собрать самому в [[Hasher|хешере]], у него почти нет зависимостей.
management.</pre>
 
  
=== Полезные советы ===
+
Итак, пакеты установлены. На время настройки рутовую консоль лучше держать открытой.
 +
Сначала создадим необходимые файлы у пользователя, который будет входить с одноразовым паролем. Входим под ним и выполняем:
 +
google-authenticator
 +
Будут заданы следующие вопросы:
 +
* Сделать токены зависимыми от времени - y
 +
* Здесь, если вы поставили libqrencode, вам будет показан QR-код. В приложении Google Authenticator а
 +
на телефоне нужно создать новый аккаунт и отсканить этот код. Если не ставили библиотеку, перебивайте показанный код руками. В результате вам тут же будет сгенерирован текущий одноразовый пароль.
 +
* Обновить файл ~/.google_authenticator? - y
 +
* Запретить использование одного кода несколько раз - y
 +
* Расширить время действия кода с 1,5 минут до 4? - n
 +
* Запретить попытки входа чаще, чем 3 раза за 30 сек? - y
 +
Всё, настройка для пользователя закончена. Идём ковырять систему (из-под рута, конечно).
  
==== Как отучить взломщиков подбирать пароли ====
+
Сначала OpenSSH. В /etc/openssh/sshd_config включаем вопрос-ответ:
Например, можно перенести sshd на другой порт, а на родной порт (22) ssh натравить portsentry.
+
ChallengeResponseAuthentication yes
<pre>On Mon, Sep 26, 2005 at 12:28:57PM +0400, ABATAPA wrote:
+
И просим демона перечитать конфиг:
> Можно сделать еще проще: разрешить такие пакеты не чаще, скажем, N в 5 минут с
+
service sshd reload
> каждой сети C средствами IPTables. Если сам ошибся - можно и подождать.
 
wrar:
 
Разве это не limit делается?</pre>
 
  
Так же целесообразно ограничить число «ожидающих» соединений, когда пароль еще не введен.
+
Отлично, с SSH закончили. Теперь правим соответствующие настройки PAM (они лежат в /etc/pam.d/sshd). Обычно рекомендуют просто добавить гугловый пам в начало файла. В нашем случае это не заработает. Проблема в том, что модуль pam_userpass не хочет нормально работать в паре с гуглом. Если просто добавить гугл в pam.d/sshd, то независимо от порядка следования модулей, будет выводится только запрос на одноразовый пароль и всегда будет access denied.
Для этого, в файле /etc/openssh/sshd_config укажите строку
 
<pre>MaxStartups 2:70:10</pre>
 
В этом случае у вас будут разрешены только 2 «ожидающих» соединения, и каждое следующее будет сброшено с вероятностью 70 %
 
  
Для особо изощрённой защиты можно использовать knock.
+
Однако, не смотря на название, userpass не проверяет логин/пароль, он просто запрашивает их и сохраняет внутри стека pam. А проверяет их
См. также [http://www.linux.com/article.pl?sid=05/09/15/1655234 http://www.linux.com/article.pl?sid=05/09/15/1655234] и [http://fail2ban.sourceforge.net/ http://fail2ban.sourceforge.net/]
+
[http://docs.altlinux.org/manpages/pam_tcb.8.html pam_tcb], причём он и сам умеет запрашивать пароль!
И ещё [http://www.csc.liv.ac.uk/~greg/sshdfilter/ http://www.csc.liv.ac.uk/~greg/sshdfilter/]
 
  
==== Настройка второго sshd ==== &gt; Копируем /etc/init.d/sshd и указываем через -f другой конфигурационный файл?
+
Решение очень простое - выкидываем userpass, вставляем на его место tcb
Практика показывает, что надо менять весь набор: копировать /etc/init.d/sshd, /etc/sysconfig/sshd; (факультативно делать ссылки или копировать сам sshd, /etc/pam.d/sshd); изменять посредством /etc/sysconfig/sshd переменные PIDFILE, LOCKFILE, EXTRAOPTIONS.
+
без параметра use_first_pass. После этип манипуляций конфиг должен выглядеть так:
''Dmitry V. Levin''
+
#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 у
<pre>$ ssh-copy-id</pre>
+
pam_tcb.
например,
 
<pre>$ ssh-copy_id -i friends_pub_key myserver</pre>
 
  
=== Ссылки ===
+
== Ссылки ==
* ALM24Doc:ch06s05.html#distrib.setup.network.ssh
+
* [http://ftp.altlinux.org/pub/distributions/ALTLinux/2.4/Master/docs/ch06s05.html#distrib.setup.network.ssh Документация ALM2.4]
 
* [http://www.nixp.ru/cgi-bin/go.pl?q=articles;a=ssh Настройка сервера SSH (теория и практика])
 
* [http://www.nixp.ru/cgi-bin/go.pl?q=articles;a=ssh Настройка сервера SSH (теория и практика])
 
* [http://www.opennet.ru/openforum/vsluhforumID14/179.html Настройка SSH в cygwin]
 
* [http://www.opennet.ru/openforum/vsluhforumID14/179.html Настройка SSH в cygwin]
Строка 181: Строка 191:
 
* [http://www.securitylab.ru/analytics/216377.php Защита с помощью SSH ключей]
 
* [http://www.securitylab.ru/analytics/216377.php Защита с помощью SSH ключей]
 
* [http://www.stearns.org/doc/ssh-techniques-two.current.html Довольно интересные трюки] (в основном по работе с большим количеством систем, в том числе через одну из них)
 
* [http://www.stearns.org/doc/ssh-techniques-two.current.html Довольно интересные трюки] (в основном по работе с большим количеством систем, в том числе через одну из них)
 +
* http://www.linux.com/article.pl?sid=05/09/15/1655234
 +
* http://fail2ban.sourceforge.net/
 +
* http://www.csc.liv.ac.uk/~greg/sshdfilter/
 +
* http://tychoish.com/rhizome/9-awesome-ssh-tricks/
 +
* https://wiki.archlinux.org/index.php/Secure_Shell
 +
 +
[[Категория:Admin]]
 +
{{Category navigation|title=Системному администратору|category=Admin|sortkey={{SUBPAGENAME}}}}

Текущая версия на 22:39, 30 мая 2020

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

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

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

Введение[править]

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

Создание ключа[править]

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

$ ssh-keygen -t ed25519

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

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

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

Настройка входа (на сервере)[править]

Для того, чтобы пользователь мог авторизоваться в системе через ssh-ключ, нужно в файл ~/.ssh/authorized_keys добавить содержимое файла id_ed25519.pub. Если пользователь будет один входить под этой учётной записью, файл id_ed25519.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

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

Проверка того, что ключ работает:

$ ssh-add
$ 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 с перечислением пользователей, имеющих право подключаться к системе (также существует опция AllowGroups); например:

AllowUsers guest test best

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

# control sshd-password-auth disabled

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

# 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.

  • Настроить fail2ban:

В файл /etc/fail2ban/jail.d/customisation.local записать

[sshd]
enabled  = true
filter   = sshd
logpath  = /var/log/auth/messages
maxretry = 3

В файле /etc/openssh/sshd_config параметру UseDNS задать значение no.

Настройка второго 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

Cisco IOS и SSH 6.6p1[править]

Ошибка при подключении: SSH2 0: Client DH key range mismatch with max built-in DH key on server!

в ~/.ssh/config (что бы не переопределять глобально у остальных пользователей) добавить:

Host 192.168.1.*
    KexAlgorithms diffie-hellman-group14-sha1,curve25519-sha256@libssh.org,ecdh-sha2-nistp521,ecdh-sha2-nistp384,ecdh-sha2-nistp256,\
diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1

т.е. diffie-hellman-group14-sha1 - на первое место.

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

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

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

В качестве инфраструктуры для одноразовых паролей мы возьмём 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.

Ссылки[править]