Alt linux sshd config

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

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

Содержание

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

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

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

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

На вопрос о файле для сохранения ключа нажать 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

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

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

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

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

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

При подключении не должен запрашиваться пароль.

Использование [ править ]

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

Для удобства в файле

/.ssh/config можно указать сокращение

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

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

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

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

Настройка сервера [ править ]

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

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

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

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

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

LDAP [ править ]

Чтобы sshd мог пускать пользователей из 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 укажите строку

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

Для особо изощрённой защиты можно использовать knock.
Можно ограничить число попыток средствами iptables:

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

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

В файле /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.

Копирование ключа на сервер [ править ]

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

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

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

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

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

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

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

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

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

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

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

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

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

/.google_authenticator? — y

Запретить использование одного кода несколько раз — y

Расширить время действия кода с 1,5 минут до 4? — n

Запретить попытки входа чаще, чем 3 раза за 30 сек? — y

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

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

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

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

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

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

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

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

Источник

Server Security

Эту статью следует викифицировать.

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

Содержание

Краткие заметки по минимальной защите сервера [ править ]

На написание данного черновика навел меня вопрос в рассылке:

hi all
Скажу сразу, я не спец по безопасности…
…
PS вопрос возник после того, как только что подняв машину завёл пользователя admin c паролем admin (думал когда закончу работу поменяю) поставил ssh и… пошёл на 10 мин в туалет. Когда вернулся дело было уже сделано — уже кто-то приконектился и начал что-то на мою машину заливать. Удивительно даже — маньяки какие-то… Я ж не супер-мега сервер какой-то, а рядовой

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

Проверяем, какие сервисы запущены и слушают порты [ править ]

После установки необходимого ПО, проверьте, какие порты открыты.

Приведенная строка информирует нас о том, что на всех сетевых адресах открыт порт 993, и слушает его cyrus-master.
Да, я уверен, что этот сервис должен слушать этот порт (это IMAPS). Надписи вида 127.0.0.1:xxx в третьей колонке означают, что сервис работает только в пределах самой машины (считается безопасным). Если вы обнаружите открытый порт и сервис, который вам не известен, разберитесь досконально, что это и для чего нужно, прежде чем отключать. Если данный сервис нужен в локальной сети, но не должен быть доступен извне, посмотрите в настройки данного сервиса, наиболее вероятным параметром будет LISTEN. Например, настройки сервера ssh:

В моем примере данная настройка не используется, а вы поступайте по своему разумению.

Настраиваем firewall [ править ]

Возможна ситуация, когда необходимый сервис не имеет такой настройки, и слушает все сетевые интерфейсы. В таком случае необходимо настроить iptables. (Я предполагаю, что у вас именно этот пакет. В другом случае, берите на вооружение идею, а реализуйте ее тем инструментарием, который у вас есть). Есть два пути настройки iptables, использовать тот файл настроек, который предусмотрен дистрибутивом, и написание собственного скрипта. Различий мало… Я привожу вариант настроек для /etc/sysconfig/iptables.

Более подробно почитайте на странице, подготовленной Виталием Липатовым.

Настраиваем сервисы [ править ]

SSH [ править ]

Минимально нужно ограничить вход в систему для пользователей, которым это не нужно. Оставим только того, кто реально может и должен иметь доступ (и ограничим скорость попыток подключений), и/или установим/настроим дополнительно sshutout.

По минимуму, все … Далее, имеет смысл правильно настроить ваш почтовый сервер, для того, чтобы через него не рассылали спам, но это уже другая статья (в дистрибутивах ALT Linux, в конфигурации по умолчанию, почтовик не смотрит в Интернет).

Источник