Конфиг SSH
Первым делом правим в конфиге демона SSH:
/etc/ssh/sshd_config
И меняем дефолтные параметры:
Port 1480
Порт, на котором будет располагаться служба. Рекомендуется ставить значение выше 1024 — так как значения ниже зарезервированы определенными службами и чаще «пробиваются» сканерами портов. Максимальное возможное значение — 65535.
В этом случае при коннекте необходимо добавлять ключ -p, пример ssh -p 4596 sanya@188.120.242.222
PubkeyAuthentication yes
Разрешаем аутентификацию по ключам SSH. Рекомендуется использовать алгоритм Ed25519. В этом случае закрытый ключ хранится на вашем ПК, а открытый добавляется на сервер в файл .ssh/authorized_keys в директории нужного юзера.
PermitEmptyPasswords no PasswordAuthentication no
Отключение авторизации по паролю — каким бы он не был надежным, всегда есть вероятность его подбора. Важно убедиться, что подключение по SSH-ключам работает, иначе подключиться к серверу без VNC или rescue вы не сможете.
ListenAddress xxx.xxx.xxx.xxx
Если на сервере несколько IP-адресов, то этим параметром мы указываем, какой именно IP на сервере должна слушать служба.
LoginGraceTime 1m
По умолчанию при подключении по SSH у вас есть две минуты, чтобы ввести пароль. Если не успеете, то соединение будет прервано. Ставим минуту или даже тридцать секунд.
опционально:
PermitRootLogin no
Отключаем авторизацию суперпользователя root. Он имеет неограниченную власть над системой и именно к нему чаще всего пытаются подобрать пароль. Важно, чтобы в системе уже были созданы другие пользователи с sudo-правами, под которыми в дальнейшем будет осуществляться подключение по SSH.
AllowUsers Darya Tolik
Разрешаем доступ по SSH только определенным юзерам. Чтобы они имели возможность получить доступ к привилегиям суперпользователя, необходимо внести их в файл /etc/sudoers или добавить юзера в группу sudo. Например usermod -aG sudo Tolik.
ClientAliveInterval 600
Задается время (в секундах) бездействия сессии, после чего она будет прервана. Важно не ставить низкие значения, иначе кроме неудобств при работе вам это ничего не принесёт.
ClientAliveCountMax 0
Количество проверок активности сессии, тесно связанный с предыдущим параметром. Если в течение заданного количества попыток (по умолчанию три) сервер не получит ответа, то соединение завершится. Так как мы выставили значение ClientAliveInterval равное десяти минутам, то этот параметр можно выключить, задав ноль.
После всех настроек перезапускаем SSH ( текущая сессия при этом не обрывается):
service sshd restart
На выходе мы получаем нестандартный порт, который слушает определенный диапазон IP-адресов и доступ возможен только по ключу SSH или сверхнадежному паролю и не юзеру root. Как его сгенерировать и где хранить, можно прочитать в другой нашей статье.
Фаервол
Помимо изменения настроек самой службы, следует также разрешить подключение только с определенных IP-адресов с помощью Iptables и блокировать слишком частые попытки авторизоваться с неправильным паролем используя Fail2ban.
Iptables
Утилита для управления брандмауэром netfiler. Установлена по умолчанию. Пример команды:
iptables -A INPUT -s 93.94.176.0/21 -p tcp --dport 22 -j ACCEPT
Которая разрешает подключение по 22 порту из указанной подсети — если вы меняли порт на предыдущем шаге, то следует заменить его и здесь.
Для остальных диапазонов IP подключение можно запретить правилом:
iptables -A INPUT -p tcp -m tcp --dport 22 -j DROP
Если вы ранее изменяли порт SSH, то соответственно необходимо поправить и правило.
Fail2ban
Ставится командами apt/yum install fail2ban в зависимости от используемой ОС.
После установки защита SSH работает сразу. Можно подправить правила в файле /etc/fail2ban/jail.conf или создать отдельный конфиг /etc/fail2ban/jail.d/ssh.conf
В секции [ssh] указываем желаемые параметры:
ignoreip — список адресов, которые не будут блокироваться при истечении неудачных попыток авторизации. Сюда следует добавить IP-адреса, к которым будете подключаться к серверу.
findtime — интервал времени, в течение которого считаются попытки подключения. Стандартное значение — 10 минут, рекомендуем ставить значение меньше, например, 5 минут.
maxretry — собственно, количество неудачных попыток авторизации перед тем, как адрес будет заблокирован. Ставим 5.
bantime — время, на которое будет блокироваться подозрительный адрес.
Пример настроек секции:
[sshd] enabled = true filter = sshd action = iptables[name=SSH, port=ssh, protocol=tcp] logpath = /var/log/auth.log findtime = 300 maxretry = 5 bantime = 7200
Если в течение пяти минут будет три неудачных попыток авторизации, то адрес, попавший под санкции, будет заблокирован на два часа.
Список заблокированных адресов можно будет посмотреть командой:
root@api:~# fail2ban-client status sshd
Пример вывода:
Status for the jail: sshd |- Filter | |- Currently failed: 0 | |- Total failed: 0 | `- File list: /var/log/ssh-auth.log `- Actions |- Currently banned: 11 |- Total banned: 34 `- Banned IP list: 118.172.217.23 123.207.231.244 138.68.75.113 150.158.179.239 154.221.19.204 192.144.171.119 20.46.114.59 202.115.29.234 45.135.232.165 46.101.132.159
Таким образом, мы разрешаем подключаться только из определенной подсети, а частые неудачные попытки будут блокироваться.
Двухфакторная аутентификация
2FA уже плотно вошла в нашу жизнь — это удобно и безопасно. Почему бы не сделать это и на сервере?
Вам нужно установить пакет libpam-google-authenticator — на современных ОС он доступен в штатных репозиториях. После установки пакета запускаем команду:
google-authenticator
И утвердительно отвечаем на вопрос:
Do you want authentication tokens to be time-based (y/n) y
После чего появится окно с QR-кодом, кодом верификации и резервные пароли:
Сохраняем код себе, добавляем ключ в приложение.
Далее последует вопрос, сохранить ли конфигурацию в файле .google_authenticator домашней директории. Отвечаем утвердительно на этот и все последующие вопросы.
После чего в конфиге /etc/pam.d/sshd добавляем строку:
auth required pam_google_authenticator.so
Меняем в /etc/ssh/sshd_config параметр ChallengeResponseAuthentication на yes
И перезапускаем SSH командой service sshd restart
Теперь при подключении к серверу после ввода пароля будет запрашиваться код подтверждения.
Панели управления
Помимо самого сервера нужно также позаботиться и о доступах в личный кабинет и панель управления сервером. Имея доступ к VNC или кнопкам управления, злоумышленник может, например, переустановить ОС на сервере и все данные будут утеряны. Или бесконечно прожимать кнопку перезагрузки, что тоже неприятно.
В панелях управления Billmanager/VMmanager/DCImanager/ISPmanager вы можете также настроить двухфакторную аутентификацию через Google Autentificator.
===================================================================
За последние несколько лет OpenSSH из набора программ для защищенной системы регистрации, выполнения команд на удаленном хосте и передачи файлов с одной машины на другую превратился в швейцарский армейский нож, просто потрясающий своими возможностями. Используете ли вы хотя бы половину из них?
Содержание:
- Отключение прослушивания IPv6 адресов
- Адрес и порт прослушивания
- Ограничение доступа суперпользователя
- Контроль за подключениями пользователей
- Пример создания резервных копий
- Используем dump в связке с ssh
- Передача файлов и каталогов
- Безопасный способ получения почты
- Почтовый шлюз
- Выполнение заданной команды после подключения
- Мультиплексирование SSH-сессий
- Создание SOCKS-сервера
- Сажаем пользователей в песочницу
- Скрываем записи о серверах, к которым мы подключались
- Управляющие последовательности SSH
- Сокращенный набор
- Получение доступа к закрытому сервису
- Ограничение возможностей перебора паролей с помощью Pf
- Перенаправление X11-подключений
- Использование аутентификации на базе публичного ключа
- VPN на базе SSH
Отключение прослушивания IPv6 адресов
По умолчанию sshd(8) слушает как на IPv4 так и на IPv6 адресах. Для того что бы отключить возможность работы по IPv6, необходимо изменить параметр AddressFamily:
AddressFamily inet
Адрес и порт прослушивания
По умолчанию sshd(8) принимает подключения на всех интерфейсах, в чем не всегда есть необходимость. Если не требуется заходить на сервер “из вне”, следует ограничить его работу определенным адресом с помощью параметра ListenAddress:
# ListenAddress 0.0.0.0
ListenAddress 192.168.1.2
Дополнительно через двоеточие можно указать и номер порта. В данном примере используется значение порта, заданное глобально параметром Port.
Ограничение доступа суперпользователя
В большинстве дистрибутивов в целях безопасности доступ суперпользователю по SSH закрыт (PermitRootLogin no), и при попытке зарегистрироваться под root получаем сообщение об ошибке. Для выполнения задач, требующих привилегий администратора, приходится заходить под обычным пользователем и использовать su(1) или sudo(8). Красиво выйти из ситуации поможет директива Match. В качестве аргумента ей передается критерий отбора (User, Group, Host, Address), его значение и параметр, который нужно применить. Для примера разрешим подключение под root только с localhost и из доверенной подсети 192.168.5.0/24:
PermitRootLogin no
Match Host 192.168.5.*,127.0.0.1
PermitRootLogin yes
Контроль неудачных подключений
Следующие две директивы позволяют контролировать неудачные подключения к серверу:
LoginGraceTime 60
MaxStartups 2:50:10
Параметр LoginGraceTime определяет, по истечению какого времени простаивающее подключение будет разорвано (в секундах). Значение по умолчанию 120 явно завышено. Количество параллельных неаутентифицированных подключений к серверу контролируется при помощи MaxStartups. Запись параметра имеет форму “start:rate:full”. В нашем случае она означает отключение с вероятностью 50% при наличии двух неаутентифицированных связей, с линейным ростом вероятности до 100% при достижении 10.
Контроль за подключениями пользователей
Установки в файлах /etc/ssh/sshrc или ~/.ssh/rc позволяют выполнить некоторые действия при регистрации пользователя. Здесь можно использовать любые команды оболочки. Например, отправим администратору на почту уведомление о том, что в систему по SSH зашел пользователь:
# vi /etc/ssh/sshrc
echo $(date) $SSH_CONNECTION $USER $SSH_TTY | mail -s “ssh login” admin@domain.ru
Пример создания резервных копий
Генерируем пару ключей (секретный и публичный):
# sudo ssh-keygen -t rsa -C ‘remote backup’
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
/home/user/.ssh/id_rsa_backup
Добавляем публичный ключ в список авторизованных ключей на удаленной системе:
# ssh remotehost “umask 077; cat > .ssh/authorized_keys” < .ssh/id_rsa_backup.pub
Затем редактируем authorized_keys (ключ ‘-t’ следует использовать при запуске программ, требующих для своей работы наличия псевдотерминала):
$ ssh -t remotehost vi .ssh/authorized_keys
from=”192.168.0.*,212.34.XX.YY”,command=”cd /work; tar cvf – ./* | bzip2 -9″,
no-pty,no-agent-forwarding,no-X11-forwarding,no-port-forwarding ssh-rsa AAAA[…]
И запускаем процедуру резервного копирования:
$ ssh -i .ssh/id_rsa_backup remotehost > ~/backup/work-`date +%d%m%Y`.tar.bz2 2>/dev/null
Каталог /work, находящийся на сервере remotehost, будет сохранен в архив ~/backup/work-11052008.tar.bz2.
Используем dump в связке с SSH
Используя SSH, можно защитить информацию, передаваемую программами, не имеющими встроенных механизмов шифрования соединения. Например, сделаем бэкап с помощью dump(8) на удаленный сервер:
$ sudo dump -0au -f – /dev/rwd1a | gzip -9 | ssh remotehost ‘dd of=cvs_backup.dump.gz’
Поскольку в dump(8) встроена возможность передавать данные по сети с использованием RSH, существует возможность использования и SSH, поскольку его функциональность аналогична:
$ ssh remotehost touch /home/user/cvs.dump
$ env RSH=`which ssh` sudo -E dump 0f remotehost:/home/user/cvs.dump /cvs
Передача файлов и каталогов
Передать файл, используя SSH, можно одним из следующих способов:
$ cat myfile | ssh remotehost ‘cat > myfile’
$ tar zcf – ~/coding | ssh remotehost ‘cat > coding.tgz’
Чтобы рекурсивно отправить весь каталог, набираем:
$ scp -r mydir user@host.domain.ru:
Вариант копирования каталога с использованием ssh(1) и tar(1) с локального хоста на удаленный:
$ tar cf – source | ssh remotehost “(cd /target; tar xpf -)”
и с удаленного хоста на локальный:
$ ssh remotehost “tar cf – source” | (cd /target; tar xpf -)
Безопасный способ получения почты
Для безопасного получения почты с помощью fetchmail можно использовать SSH. Для этого в конфигурационном файле ~/.fetchmailrc необходимо указать следующее:
poll localhost with protocol pop3 and port 8110:
preconnect “ssh -f -q -C user@213.167.XX.YY \
-L 8110:213.167.XX.YY:110 sleep 10″ password noIdea;
Забираем почту:
$ fetchmail
1 message for user at localhost (8062 octets).
reading message user@localhost.domain.ru:1 of 1 (8062 octets)……. flushed
Почтовый шлюз
Настроим 192.168.1.1 на перенаправление входящей и исходящей почты по шифрованному каналу для клиентов из 192.168.1.0/24 на mail.domain.ru:
$ vi .ssh/config
Host mail
Hostname mail.domain.ru
LocalForward 192.168.1.1:8025 mail.domain.ru:25
LocalForward 192.168.1.1:8110 mail.domain.ru:110
LocalForward 192.168.1.1:8143 mail.domain.ru:143
GatewayPorts yes
Открываем туннель:
$ ssh mail
Выполнение заданной команды после подключения
Параметр ProxyCommand позволяет выполнить произвольную команду. Для примера подключимся через шлюз к файловому серверу, который находится за NAT:
$ vi .ssh/config
Host gateway
HostName ns.domain.ru
Host filesrv
HostName 192.168.5.201
ProxyCommand ssh gateway nc -w 180 %h %p
Подключаемся:
$ ssh filesrv
Мультиплексирование ssh-сессий
Использование параметра ControlMaster позволяет ускорить доступ к удаленному серверу за счет того, что в специальном файле сохраняются все параметры предыдущего сеанса, которые и используются при повторном подключении. Для примера создадим две Host-секции:
$ vi .ssh/config
Host srv1
HostName 213.167.XX.YY
ControlMaster yes
# Здесь %r – имя, %h – хост и %p – порт
ControlPath ~/.ssh/ctl-%r-%h-%p
Host srv1fast
HostName 213.167.XX.YY
ControlMaster no
ControlPath ~/.ssh/ctl-%r-%h-%p
Теперь на сервере srv1 выполняем утилиту uptime(1), логинимся на нем (чтобы создать локальный сокет для второго подключения), переходим на другую консоль и снова запрашиваем статистические счетчики:
ttyp0$ time ssh srv1 uptime
5:55PM up 37 days, 9:19, 1 user, load averages: 0.33, 0.32, 0.33
0m0.77s real 0m0.06s user 0m0.01s system
ttyp0$ ssh srv1
ttyp1$ time ssh srv1fast uptime
5:57PM up 37 days, 9:20, 2 users, load averages: 0.37, 0.34, 0.33
0m0.03s real 0m0.00s user 0m0.01s system
Из примера видно, что при использовании мультиплексирования соединений время выполнения команды uptime(1) на удаленном сервере уменьшилось в 25 раз.
Создание SOCKS-сервера
OpenSSH можно использовать как специальный SOCKS-сервер, который поддерживает более гибкое проксирование, чем простое перенаправление портов. Например, команда:
$ ssh -D1080 user@domain.ru
Создает локальный SOCKS5-сервер, который ждет подключения на localhost:1080. Альтернативный вариант – прописать директиву DynamicForward в .ssh/config:
$ vi .ssh/config
Host proxy
HostName ns.domain.ru
DynamicForward 1080
Подключаемся, введя ssh proxy. Протестировать работу SOCKS5-сервера можно такой командой:
$ echo -n “GET / HTTP/1.0\r\n\r\n” | nc -X 5 -x 127.0.0.1:1080 \
www.domain.ru 80 | head -4
HTTP/1.1 200 OK
Date: Sat, 23 Feb 2008 14:27:43 GMT
Server: Apache
X-Powered-By: PHP/4.4.1
Теперь SOCKS-сервер готов к использованию:
$ tsocks thunderbird
Сажаем пользователей в песочницу
В OpenSSH 4.9 появилась долгожданная поддержка chroot(2) для sshd(8), контролируемая с помощью опции ChrootDirectory. К примеру, заставим подключающегося по sftp пользователя worker переходить в измененный корневой каталог data:
# vi /etc/ssh/sshd_config
#Subsystem sftp /usr/libexec/sftp-server
Subsystem sftp internal-sftp
Match User worker
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
ChrootDirectory /data
Пример для хостинговых клиентов:
# vi /etc/ssh/sshd_config
#Subsystem sftp /usr/libexec/sftp-server
Subsystem sftp internal-sftp
Match Group wwwusers
X11Forwarding no
AllowTcpForwarding no
ForceCommand internal-sftp
ChrootDirectory /var/www/hosting/%u
Теперь зарегистрированные пользователи будут допущены только к “своему” каталогу, при подключении модификатор %u будет заменен именем пользователя. При необходимости можно использовать %h, который соответствует домашнему каталогу юзера.
Скрываем записи о серверах, к которым мы подключались
Некоторые администраторы, возможно, захотят зашифровать все IP и доменные адреса из файла .ssh/known_hosts. Делается это следующим образом:
$ echo ‘HashKnownHosts’ >> ~/.ssh/config
$ ssh-keygen -H -f ~/.ssh/known_hosts
$ head -1 ~/.ssh/known_hosts
+|1|TJ2SaXGqO8uHYeiA92KuNRIKR7M=|GpQB8Qz0tQPqA+nF+ghe37mpcHA= ssh-rsa AAAA[…]
Управляющие последовательности SSH
Управляющие последовательности SSH станут доступны, если в SSH-сессии сначала нажать <Enter>, затем управляющий символ сеанса (по умолчанию тильда, задается директивой EscapeChar) и специальную клавишу, которая указывает, какую именно функцию следует выполнить.
Допустим, мы с mail.domain.ru зашли на bastion.domain2.ru и решили, что не плохо было бы открыть обратный шифрованный туннель к почтовому серверу для безопасной загрузки сообщений. С помощью комбинации клавиш “<Enter>~C” можно интерактивно управлять локальным и удаленным форвардингами (ключи ‘-L’ и ‘-R’):
bastion$ <Enter>~C
ssh> -R 8110:mail.domain.ru:110
Forwarding port.
Проверяем работу созданного почтового туннеля:
bastion$ telnet localhost 8110
+OK Dovecot ready.
В ответ получен баннер от Dovecot, значит, все в порядке. Кстати, обратившись к подсказке, получим список всех доступных ключей и дополнительных параметров:
bastion$ <Enter>~C
ssh> help
Commands:
-L[bind_address:]port:host:hostport Request local forward
-R[bind_address:]port:host:hostport Request remote forward
-KR[bind_address:]port Cancel remote forward
Если в ~/.ssh/config установить значение директивы PermitLocalCommand в yes, то мы сможем выполнять команды в локальном шелле, т.е. на хосте, с которого зашли:
ns$ ssh mx
mx$ <Enter>~C
ssh> !uptime # команда выполняется на хосте ns
7:02PM up 100 days, 11 mins, 1 user, load averages: 0.13, 0.21, 0.23
<Enter>
mx$ uptime # команда выполняется на хосте mx
7:02PM up 4 days, 7:34, 1 user, load averages: 0.21, 0.23, 0.19
Если на предыдущем узле требуется выполнить сразу несколько команд, то SSH-сессию лучше временно засуспендить (приостановить выполнение программы ssh):
mx$ <Enter>~<Ctrl-Z>
[1] + Suspended “ssh” “$@”
Чтобы перевести SSH-сессию из остановленного режима в активный, следует воспользоваться командой fg.
Список текущих SSH-соединений можно просмотреть комбинацией:
mx$ <Enter>~#
The following connections are open:
#0 client-session (t4 r0 i0/0 o0/0 fd 5/6 cfd -1)
А для быстрого завершения SSH-сессии ставим точку:
mx$ <Enter>~.
Connection to 213.167.XX.YY closed.
Сокращенный набор
Чтобы в консоли не вводить полное доменное имя, порт и учетную запись для подключения к удаленной системе, стоит заручиться поддержкой директивы Host:
$ vi ~/.ssh/config
Host mx
Hostname mx.domain.ru
Port 2022
User admin
Таким образом, достаточно ввести ssh mx, чтобы соединиться с нужным хостом.
Получение доступа к закрытому сервису
Многие администраторы в целях безопасности скрывают свои сервера в демилитаризованной зоне, либо за NAT’ом, и разрешают входящие соединения только с доверенных IP-адресов и по определенными портам. Поэтому доступ ко многим полезным ресурсам получить напрямую нельзя. Это как раз тот случай, когда использование SSH-форвардинга может исправить ситуацию.
$ vi ~/.ssh/config
Host gate
Hostname gate.domain.ru
# Для ускорения соединений включаем мультиплексирование SSH-сессий
ControlMaster auto
ControlPath ~/.ssh/ctl-%r-%h-%p
# Перенаправляем локальный порт на файловый сервер (Win2k3 с поднятым VShell)
LocalForward 8022 192.168.1.101:22
# Подключаясь к localhost:8022, мы будем попадать на файловый сервер
Host fileserver
Hostname localhost
Port 8022
ControlMaster auto
ControlPath ~/.ssh/ctl-%r-%h-%p
HostKeyAlias fileserver
Соединяемся с узлом gate и проверяем возможность подключения к локальному порту 8022:
$ ssh -N -f gate
$ telnet localhost 8022
SSH-2.0-VShell_3_0_4_656 VShell
Теперь можно подключиться к файловому серверу, который находится за NAT’ом, в обход правил файерола, установленных на шлюзе:
$ ssh fileserver
Microsoft Windows [Version 5.2.3790]
C:\Documents and Settings\Username\My Documents>
Ограничение возможностей перебора паролей с помощью Pf
Сервис SSH является любимой мишенью злоумышленников, поэтому следует принять некоторые меры безопасности. Одна из них – ограничение количества подключений, чтобы избежать DoS-атаки и перебора паролей.
# vi /etc/pf.conf
table <sshbf> persist
block in log quick on $ext_if inet from <sshbf>
pass in log on $ext_if inet proto tcp to $ext_if port ssh keep state \
(max-src-conn-rate 5/60, overload <sshbf> flush global)
Данный набор правил инструктирует фильтр пакетов не допускать более 5 одновременных соединений к 22 порту за 60 секунд.
Перенаправление X11-подключений
Для перенаправления X11-подключений следует использовать ключ ‘-Y’:
$ ssh -Y user@domain.com
Причем в конфигурационном файле /etc/ssh/sshd_config параметр X11Forwarding должен быть установлен в “yes”. Если X-сервер запущен на локальной системе, то необходимо включить и X11UseLocalhost.
Использование аутентификации на базе публичного ключа
См. мини-руководство “шаг за шагом”.
VPN на базе SSH
См. мини-руководство “шаг за шагом”.
Некоторые советы взяты из статей “Калейдоскоп тайных знаний” и “Волшебные криптотуннели”, опубликованных в июньском и июльском номерах журнала ” Хакер” за 2008 год. Авторы статей: Андрей Матвеев и Сергей Яремчук. Коррективы и уточнения введены проектом OpenBSD.ru.
Основные приёмы
Все действия производятся в конфигурационном файле sshd демона — /etc/ssh/sshd_config. Ниже приведу часть своего конфигурационного файла с комментариями.
### Network ###
# Используем нестандартный порт (>1024)
port 5679
# Используем только IPv4 соединения
# inet = IPv4, inet6 = IPv6, any = both
AddressFamily inet
# Можно принимать соединения только с определённых IP-адресов
#ListenAddress 0.0.0.0
# Используем вторую версию протокола, т.к. первая подвержена
# известным уязвимостям
Protocol 2
# Отключаем перенаправление графики (X-сервер) до тех пор
# пока она явно не понадобится вам
X11Forwarding no
# Отключаем Disable TCPKeepAlive и используем ClientAliveInterval вместо этого,
# чтобы предотвратить атаки типа TCP Spoofing
TCPKeepAlive no
# Выкидваем пользователя через 10min (600 sec) неактивности
ClientAliveInterval 600
ClientAliveCountMax 3
### Key configuration files ###
# HostKeys для протокола версии 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
# Используем непривилегированный процесс для
# обработки входящего от клиента трафика
# sandbox - openSSH >= 5.9 ("yes" - для младших версий)
UsePrivilegeSeparation sandbox
# При изменении этих значений, требует удалить старый ключ
# /etc/ssh/ssh_host_rsa_key{,.pub}, и создать новый
# путём перезапуска sshd.
#
# Время жизни ключа, т.е. через какое время будет сгененрирован новый ключ
# в случае, если предыдущий был использован.
KeyRegenerationInterval 1h
# сила ключа
ServerKeyBits 2048
# Разрешаем авторизацию по публичному ключу
PubkeyAuthentication yes
# Место хранения доверенных ключей в каталоге пользователя
AuthorizedKeysFile .ssh/authorized_keys
### Logging ###
# Префикс для syslog
SyslogFacility AUTH
# уровень подробности сообщений для самого sshd
LogLevel INFO
### Authentication ###
# список разрешённых пользователей
AllowUsers ivan
# ограничиваем время для ввода пароля для ssh-ключа
LoginGraceTime 30s
# запрещаем удалённо входить под учётной записью root
PermitRootLogin no
# Включаем явную проверку прав файлов и директорий с ssh-ключами
StrictModes yes
# Сколько раз переспрашивать пароль при неверном вводе
MaxAuthTries 3
# Запрещаем вход по пустому паролю
PermitEmptyPasswords no
# Запрещаем вход по паролю в принципе
# (Используем публичный/приватный ключ вместо этого)
PasswordAuthentication no
# Отключаем использование "challenge-responce" авторизацию,
# т.к. она бесполезна при использовании ключей
ChallengeResponseAuthentication no
# Так как мы не используем пароль, то и {PAM, login(1)} нам не нужены
UsePAM no
UseLogin no
# Позволяем клиенту передавать лишь определённый набор переменных окружения
# RH BZ#CVE-2014-2532
# ShellShock exploit
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL
Это те параметры, что настраиваются в конфигурационном файле sshd. После изменения настроек требуется перезапустить сервис sshd.
Комментарии
- При использовании авторизации по ключу, ключ требуется предварительно сгенерировать на клиентской машине и скопировать публичный ключ на сервер. Пример:
client $ ssh-keygen
client $ cat ~/.ssh/id_rsa.pub | ssh -p 5679 ivan@serverurl.com "cat >> ~/.ssh/authorized_keys"
- В файле
/var/log/auth.logбудут находиться сообщения от sshd. В случае, если этот файл отсутствует, вам требуется настроить вашу систему логирования. Вот здесь пример дляsyslogиsyslon-ng. Я используюsyslog-ng, и мне потребовалось добавить следующие строки в файл/etc/syslog-ng/syslog-ng.conf:
destination authlog { file("/var/log/auth.log"); };
log { source(src); destination(authlog); };
и перезапустить сервис syslog-ng.
- При использовании нестандартного порта может потребоваться настроить ваш firewall (iptables, firewalld, etc).
Пример настройки для iptables:
root# iptables -A INPUT -p tcp -m state --state NEW,ESTABLISHED --dport 5679 -j ACCEPT
root# service iptables save
root# iptables -L -n
Chain INPUT (policy ACCEPT)
target prot opt source destination
ACCEPT icmp -- 0.0.0.0/0 0.0.0.0/0
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:22
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW tcp dpt:80
ACCEPT tcp -- 0.0.0.0/0 0.0.0.0/0 state NEW,ESTABLISHED tcp dpt:5679
...
Если этого мало
Это лишь базовые настройки. Дополнительно можно настроить
- firewall (iptables)
- fail2ban
- port knoking
- /etc/hosts.deny
Свежие комментарии