sshd_config

Конфиг 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
...

Если этого мало

Это лишь базовые настройки. Дополнительно можно настроить

Previous Story

Как установить систему Zammad Helpdesk в Ubuntu 20.04 | 18.04

Next Story

Настройка Nginx для использования в качестве веб-сервера и обратного прокси-сервера для Apache в One Ubuntu 18.04 Server

Latest from Blog

Zabbix – Docker – Raspberry Pi

Для начала установим Portainer – веб-интерфейс для управления docker-контейнерами. Бесплатно, удобно, подойдет новичкам в docker. Установка

Сетевая папка/диск в Linux

x.x.x.x адрес шары /mnt/shara точка монтирования user пользователь с доступом к шаре 1234 пароль пользователя Для

Памятка SSH

В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые

0 £0.00