/etc/ssh/sshd_config порт с 22 на 2222 и сделал systemctl restart ssh - ничего не произошло.По-прежнему слушался порт 22. Хм... Хуйня какая-то.
ㅤ
Всё оказалось прозаичнее. В новых версиях дистрибутива, ssh демон стал использовать сокетовую модель для подключения клиентов. Как раз недавно мы разбирали
systemd и его функционал, поищи по тегу #systemdНу так вот. Если подключиться к консоли дистрибутива (не по ssh), то обнаружим, что никакой ssh сервис не запущен. Однако...
Но если выполнить:
ss -tln то увидим:tcp LISTEN 0 4096 *:22 *:*
Да ёбтвою мать! Разбираемся.
Суть такая. Для ssh используется не
ssh.service юнит, а ssh.socket. А как мы знаем юнит socket не держит процесс постоянно запущенным. Экономия ресурсов и т.п. А вот когда кто-то обращается к порту 22, запрос улетает на сокет systemd, который уже и запускает сервис ssh.service..Пиздец конечно конструкция. Если посмотреть файл
ssh.socket, в нём будет:[Unit]
Description=OpenBSD Secure Shell server socket
Before=sockets.target ssh.service
ConditionPathExists=!/etc/ssh/sshd_not_to_be_run
[Socket]
ListenStream=0.0.0.0:22
ListenStream=[::]:22
BindIPv6Only=ipv6-only
Accept=no
FreeBind=yes
[Install]
WantedBy=sockets.target
RequiredBy=ssh.service
Смотрим на
ListenStream, вот тебе и 22 порт.А чё блядь делать?
Снимать штаны и бегать. А если серьезно, то решается это просто. После правки конфига
/etc/ssh/sshd_config делаем:systemctl daemon-reload
systemctl restart ssh.socket
Перезапускаем именно юнит сокета. После этого порт изменится. А в файле
ssh.socket будет такое:[Socket]
ListenStream=0.0.0.0:2222
ListenStream=[::]:2222
Красота. Если тебя удручают эти нововведения, то можно вернуться к привычной схеме.
Делается это так:
systemctl disable --now ssh.socket
rm -f /etc/systemd/system/ssh.service.d/00-socket.conf
rm -f /etc/systemd/system/ssh.socket.d/addresses.conf
systemctl daemon-reload
systemctl enable --now ssh.service
Способ описан на официальном сайте бубунты.
Вот такие пироги.
Ну а чем отличается ssh_config от sshd_config я описывал в этом посте.
🛠 #linux
—
✅ @bashdays ✅ @linuxfactory ✅ @blog