- Доступ по SSH
- Предварительный бэкап
- Доступ по SSH через сеть
- Обмен файлами
- Alt linux включить ssh
- Введение
- Создание ключа
- Настройка входа (на сервере)
- Использование
- Конфигурационный файл (у пользователя)
- Настройка сервера
- Инструкция по установке и настройке сервера ssh для администратора
- LDAP
- Управление сессиями
- Полезные советы
- Предотвращение брутфорс-атак
- Настройка второго sshd
- Копирование ключа на сервер
- Cisco IOS и SSH 6.6p1
- Настройка входа по одноразовому паролю
- Ссылки
Доступ по SSH
Примечание: Обратите внимение, что это не официальная документация, а попытка начинающего админа объяснить материал начинающим админам. Официальная и более подробная документация здесь.
С помощью SSH-сервера можно удаленно управлять сервером через консоль (ssh://-соединение) и передавать файлы (sftp-сервер).
В данной статье будут рассмотрены настройка доступа к терминалу (TODO: надо описать. В данный момент настройка терминального доступа не описана) и файлам через SSH.
Предварительный бэкап
На сервере переключаемся в режим суперпользователя:
Делаем на всякий случай бэкап конфига:
# cd /etc/openssh # cp -a sshd_config sshd_config.bak
# cd /etc/openssh # mcedit sshd_config
Потом, если что-то пошло не так, удаляем измененный и восстанавливаем исходный:
# cd /etc/openssh # rm sshd_config # cp -a sshd_config.bak sshd_config # service sshd reload
В любом случае при изменениях этого файла стоит обязательно:
- держать уже открытую рутовую сессию через достаточно надёжное соединение;
- перезапустить sshd;
- попытаться подключиться ещё одной рутовой сессией по ключу (либо пользовательской с поднятием привилегий, что несколько менее предпочтительно),
чтобы убедиться в том, что удалённый доступ к системе всё ещё функционирует.
Доступ по SSH через сеть
Редактируем следующие значения:
Port 22 //раскоментируем строчку MaxSessions 10 //раскомментируем строчку PubkeyAuthentication yes //раскомментируем строчку PubkeyAcceptedKeyTypes ssh-ed25519-cert-v01@openssh.com,ssh-ed25519,rsa-sha2-512,rsa-sha2-256,ssh-rsa-cert-v01@openssh.com,ssh-rsa,ecdsa-sha2-nistp521-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp521,ecdsa-sha2-nistp384,ecdsa-sha2-nistp256 //раскомментируем строчку PasswordAuthentication yes //раскомментируем строчку PermitEmptyPasswords no //раскомментируем строчку ChallengeResponseAuthentication yes //раскомментируем строчку ClientAliveInterval 300 //раскомментируем строчку и меняем значение ClientAliveCountMax 3 //раскомментируем строчку Subsystem sftp /usr/lib/openssh/sftp-server //раскомментируем строчку Match User petr //тут пишем пользователя, под которым будем заходить X11Forwarding yes //раскомментируем строчку AllowTcpForwarding yes //раскомментируем строчку PermitTTY yes //раскомментируем строчку
Сохраняем файл и перезапускаем сервис:
Вводим в консоли ssh user@ip:
Система запросит разрешение на принятие SSH-ключа и ввод пароля. После этого у Вас будет консоль подключенного сервера.
Обмен файлами
Обмен файлами с сервером будет происходить по протоколу SSH.
Этот же каталог прописываем в ChrootDirectory.
ChrootDirectory /home/files
# chown petr:petr /home/files # chmod -R u+rwx /home/files
- Открываем Caja
- Файл > Соединиться с сервером:
- IP
- Тип: SSH
- Папка: /home/files
- Имя пользователя: petr (учетка на сервере, которой мы дали права)
- Пароль: (соответствующий)
- Можно поставить галочку «Добавить закладку»
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