Alt linux установка ssh

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

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

Введение

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

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

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

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

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

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

Для того, чтобы пользователь мог авторизоваться в системе через 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

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

Пользователям 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/config можно указать сокращение

Host myserv HostName host.name

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

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

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

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

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

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

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

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

AllowUsers guest test best

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

PasswordAuthentication no

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

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:

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.

В файл /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 -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 нет в репозитории вашей платформы, то его несложно собрать самому в хешере, у него почти нет зависимостей.

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

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

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

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

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

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

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

ChallengeResponseAuthentication yes

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

Отлично, с 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.

Ссылки

Документация ALM2.4
Настройка сервера SSH (теория и практика)
Настройка SSH в cygwin
Автоматизация системного администрирования с помощью ssh и scp
Защита с помощью SSH ключей
Довольно интересные трюки (в основном по работе с большим количеством систем, в том числе через одну из них)
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

Источник

Alt linux установка ssh

Источник: sfx-tula.ru ALT Linux – открытый и свободный дистрибутив Linux, который предлагает широкий набор инструментов для эффективного администрирования. Одна из наиболее важных функций, которую предлагает ALT Linux, – возможность удаленного администрирования с использованием протоколов SSH и Telnet.

Установка ALT Linux

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

Удаленное администрирование с помощью SSH

SSH (Secure Shell) – это протокол, который позволяет безопасно подключаться и управлять удаленными системами. ALT Linux поддерживает SSH «из коробки», что делает его идеальным инструментом для удаленного администрирования.

Сначала нужно убедиться, что служба SSH работает на вашем сервере ALT Linux. Это можно сделать с помощью следующей команды:

sudo systemctl status sshd

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

sudo systemctl start sshd

Для подключения к серверу ALT Linux с использованием SSH вы можете использовать команду ssh, указав имя пользователя и IP-адрес сервера:

Удаленное администрирование с помощью Telnet

Telnet – еще один протокол для удаленного управления системами. Однако, в отличие от SSH, Telnet не шифрует трафик, что делает его менее безопасным.

Прежде чем использовать Telnet в ALT Linux, убедитесь, что служба Telnet установлена и запущена:

sudo systemctl status telnet.socket

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

sudo systemctl start telnet.socket

Затем вы можете подключиться к серверу ALT Linux с помощью Telnet, указав IP-адрес сервера:

Заключение

Итак, мы рассмотрели основы удаленного администрирования в ALT Linux с использованием SSH и Telnet. Оба инструмента предлагают возможности для управления вашими системами из любой точки мира, однако SSH является более безопасным вариантом благодаря шифрованию трафика.

Источник