🥷 Джонни вещает: ключ сервера SSH

Прошлый пост(click) оказался для вас hard-level, поэтому сегодня тема попроще(про пальчики вверх не забываем, я для кого стараюсь 😄)

🖥 Первый раз, когда вы заходите на сервер, SSH вас спрашивает, доверяете ли вы ключу. Если отвечаете нет, соединение закрывается. Если да — ключ сохраняется в файл ~/.ssh/known_hosts. Узнать, где какой ключ нельзя (ибо несекьюрно).

— Если ключ сервера поменялся (например, сервер переустановили), SSH вопит от подделки ключа. Обратите внимание, если сервер не трогали, а SSH вопит, значит вы не на тот сервер ломитесь (например, в сети появился ещё один компьютер с тем же IP, особо этим страдают всякие локальные сети с 192.168.1.1, которых в мире несколько миллионов). Сценарий «злобной man in the middle атаки» маловероятен, чаще просто ошибка с IP, хотя если «всё хорошо», а ключ поменялся — это повод поднять уровень паранойи на пару уровней (а если у вас авторизация по ключу, а сервер вдруг запросил пароль — то паранойю можно включать на 100% и пароль не вводить).

🕹 Удалить известный ключ сервера можно командой ssh-keygen -R server. При этом нужно удалить ещё и ключ IP (они хранятся раздельно): ssh-keygen -R 127.0.0.1.

Ключ сервера хранится в /etc/ssh/ssh_host_rsa_key и /etc/ssh/ssh_host_rsa_key.pub. Их можно:
а) скопировать со старого сервера на новый.
б) сгенерировать с помощью ssh-keygen. Пароля при этом задавать не надо (т.е. пустой). Ключ с паролем ssh-сервер использовать не сможет.

🔍 Заметим, если вы сервера клонируете (например, в виртуалках), то SSH-ключи сервера нужно обязательно перегенерировать. Старые ключи из know_hosts при этом лучше убрать, иначе SSH будет ругаться на duplicate key.

#SSH #host | 😊 @iscode

🥷 Джонни вещает: вложенные туннели (естественно, туннели можно перенаправлять)

Усложним задачу: теперь нам хочется показать коллеге приложение, запущенное на localhost на сервере с адресом 10.1.1.2 (на 80ом порту).

🆘 Для понимания ситуации, пример ниже будет ссылаться на вот эту схему (click)

ssh -L 192.168.0.2:8080:127.1:9999 user@8.8.8.8 ssh -L 127.1:9999:127.1:80 user2@10.1.1.2

Твою мать, чё у вас здесь происходит? 😄 Мы говорим SSH перенаправлять локальные запросы с нашего адреса на localhost сервера Б и сразу после подключения запустить SSH (то есть клиента SSH) на сервере Б с опцией слушать на localhost и передавать запросы на сервер 10.1.1.2 (куда клиент и должен подключиться).

💬 Порт 9999 выбран произвольно, главное, чтобы совпадал в первом вызове и во втором. (ставим пальцы, и расскажу о динамическом пробросе портов)

#SSH #TCP | 😊 @iscode

🥷 Джонни вещает: динамический проброс портов

Перенаправление трафика с нескольких портов на удаленный сервер: ssh -D 3000 ssh-server. Тут мы поднимаем SOCKS-прокси на порту 3000 для всех интерфейсов в локальной системе. Теперь трафик, отправленный через прокси-сервер на SSH-сервер, можно адресовать на любой порт или конечный хост.

— По умолчанию используется протокол SOCKS5, поддерживающий TCP и UDP.

ssh -D 127.0.0.1:3000 ssh-server (поднимаем SOCKS-прокси на 127.0.0.1:3000 в локальной системе)

При работающем SOCKS-прокси можно настроить браузер на его использование для доступа к ресурсам так, как будто соединения исходят от SSH-сервера. Например, если у SSH-сервера есть доступ к другим серверам в частной сети, с помощью SOCKS-прокси можно заходить на эти серверы локально (словно вы находитесь в той же сети), и не нужно настраивать VPN.

🖥 Работу SOCKS-прокси можно проверить командой: curl -x socks5://127.0.0.1:12345 https://example.org

#SSH #Socks #Proxy | 😊 @iscode

Обычный день с СДВГ

#meme | 😊 @iscode

🥷 Джонни вещает: управление ключами SSH

Теория в "двух словах": SSH может авторизоваться не по паролю, а по ключу. Ключ состоит из открытой и закрытой части. Открытая кладётся в домашний каталог пользователя, «которым» заходят на сервер, закрытая — в домашний каталог пользователя, который идёт на удалённый сервер. Половинки сравниваются (я утрирую) и если всё ок — пускают.

🖥 Важно: авторизуется не только клиент на сервере, но и сервер по отношению к клиенту (то есть у сервера есть свой собственный ключ). Главной особенностью ключа по сравнению с паролем является то, что его нельзя «украсть», взломав сервер — ключ не передаётся с клиента на сервер, а во время авторизации клиент доказывает серверу, что владеет ключом (та самая криптографическая магия).

Генерация ключа и его структура: cвой ключ можно сгенерировать с помощью команды ssh-keygen. Если не задать параметры, то он сохранит всё так, как надо. Сменить пароль на ключ можно с помощью команды ssh-keygen -p.

~/.ssh/id_rsa.pub — открытый ключ. Его копируют на сервера, куда нужно получить доступ.
~/.ssh/id_rsa — закрытый ключ. Его нельзя никому показывать. Если вы в письмо/чат скопипастите его вместо pub, то нужно генерировать новый ключ. (Я не шучу, примерно 10% людей, которых просишь дать ssh-ключ постят id_rsa).

🎙 Если подобный формат постов вам понравиться, сделаю и на другие темы.

#SSH | 😊 @iscode

🥷 Docker в виртуальной машине

#meme | 😊 @iscode

🥷 HTTP: Uniform Resource Locator — или просто URL

Важную роль в работе HTTP играет Uniform Resource Locator, сокращенно URL – единообразный определитель местонахождения ресурса. Именно URL используется для того, чтобы указать, к какой странице мы хотим получить доступ.

❗️ URL состоит из трех основных частей(см. приложение):

1. Название протокола, в примере на рисунке протокол HTTP.
2. Адрес сервера, на котором размещен ресурс. Можно использовать IP-адрес или доменное имя. Адрес сервера отделяется от названия протокола двоеточием и двумя слешами.
3. Адрес ресурса на сервере. Это может быть HTML-страница, изображение, видео или ресурс другого типа. В примере на рисунке адрес страницы: /posts/http.

В URL не обязательно использовать только протокол HTTP, вот примеры с другими протоколами:

https://ya.ru | ftp://example.com

URL может включать достаточно большое количество других компонентов, кроме протокола, адреса сервера и адреса ресурса. Более подробно почитать о них можно в документе RFC 1738, Uniform Resource Locators (URL).

#HTTP #URL | 😏 @iscode

😟 Как сделать и настроить собственный VPN

В этой статье я подробно расскажу как оформить сервер и поднять свой VPN на протоколе VLESS с XTLS-Reality, который выделяется на общем плане тем, что трафик шифруется и маскируется под подключение к популярным сайтам (доменам), тем самым станет тёмной лошадкой для ТСПУ.

↘️ habr.com/ru/users/stein_osint/

— Дорогие сабчики, канал разрастается, а анимированных эмодзи всё меньше, просьба к вам - проголосовать за меня.

#VPN #VLESS #Reality #РКН | 😈 @secur_researcher

🥷 Протокол HTTP: принцип работы и методы

Протокол HTTP работает в режиме запрос-ответ. Клиент, например, браузер, передает на сервер запрос к определенному ресурсу, например, Web-странице. Сервер в ответ отправляет клиенту этот ресурс или сообщение об ошибке, если ресурс передать нельзя.

- На транспортном уровне HTTP использует протокол TCP (кроме HTTP/3, в котором применяется QUIC), порт Web-сервера по-умолчанию: 80.

🕹 Запрос HTTP состоит из трех основных частей:
· Запрос
· Заголовки (не обязательно)
· Тело сообщения (не обязательно)

Пример простого запроса HTTP в текстовом режиме:
GET /posts/http HTTP/1.1
Host: johnny.ru

Начинается всё с метода HTTP, в нашем случае это - GET, он указывает, какое действие требуется выполнить с ресурсом. В примере метод GET говорит о том, что мы хотим получить (загрузить) ресурс, далее адрес ресурса /posts/http – путь к странице на Web-сервере, которую мы хотим загрузить и далее идёт версия протокола.

- Во второй строке указывается заголовок Host. Этот заголовок является обязательным в версии HTTP/1.1, в нем задается доменное имя сервера, к которому направлен запрос.

❗️ Методы HTTP: они говорят нам, какое действие с ресурсом мы хотим совершить. В примере запроса мы видели метод GET, который предназначен для получения ресурса. Кроме GET в HTTP есть и другие методы, наиболее важные из которых определены в документе RFC 9110 HTTP Semantics.

1. GET — Запрос на передачу ресурса.
2. HEAD — Запрос на передачу ресурса, но сам ресурс в ответе не передается, только заголовки.
3. POST — Передача данных на сервер для обработки указанного ресурса.
4. PUT — Размещение ресурса на сервере (если такой ресурс уже есть на сервере, то он замещается).
5. DELETE — Удаление ресурса на сервере.
6. CONNECT — Установка соединение с сервером на основе ресурса.
7. OPTIONS — Запрос поддерживаемых методов HTTP для ресурса и других параметров коммуникации.
8. TRACE — Запрос на трассировку сообщения: сервер должен включить в свой ответ исходный запрос, на который он отвечает. Это полезно, когда запрос проходит через промежуточные устройства, которые могут изменить запрос, например, добавить заголовки.

Полный список всех существующих методов HTTP находится в документе Hypertext Transfer Protocol (HTTP) Method Registry, который сопровождается организацией Internet Assigned Numbers Authority (IANA).

Жду от вас реакшена и делаю пост о кодах статусов ответов HTTP!

#HTTP #Method #Request | 😏 @iscode

🥷 Протокол HTTP: коды состояния ответов и ошибки

Первая строка ответа HTTP содержит код статуса ответа – число в диапазоне от 100 до 599, которое характеризует результат выполнения запроса. Возможные коды статусов ответов описаны в документе RFC 9110 HTTP Semantics.

❗️ Коды статусов ответов разделены на пять классов, которые определяются по первой цифре кода:
· 1ХХ (информация): запрос получен, обработка продолжается
· 2ХХ (успешное выполнение): запрос был успешно принят и понят
· 3ХХ (перенаправление): для выполнения запроса необходимо предпринять дополнительные действия.
· 4ХХ (ошибка клиента): запрос содержит синтаксическую ошибку или не может быть выполнен.
· 5ХХ (ошибка сервера): запрос от клиента оформлен правильно, но при его обработке произошла ошибка на стороне сервера.

#HTTP | 😏 @iscode

😊 Более подробное описание по часто встречающимся кодам статусов ответов

1. 1ХХ (информация)
101 Switching Protocols — Запрос принят, сервер предлагает дальнейшее взаимодействие выполнять по другому протоколу (например, WebSocket).

2. 2ХХ (успешное выполнение)
200 OK — Запрос выполнен успешно.
201 Created — В результате выполнения запроса на сервере был успешно создан ресурс (например, в ответ на запрос PUT).

3. 3ХХ (перенаправление)
301 Moved Permanently — Запрошенный ресурс был перемещен. Новый URL ресурса указывается в заголовке ответа Location. В дальнейшем клиенту рекомендуется использовать новый URL.
302 Found — Запрошенный ресурс был временно перемещен в другое место. Новый URL ресурса указывается в заголовке ответа Location. В дальнейшем клиенту рекомендуется использовать старый URL, т.к. перемещение временное.
304 Not Modified — Запрошенный ресурс не был изменен, поэтому можно взять ресурс из кэша, а не передавать его по сети.

4. 4ХХ (ошибка клиента)
400 Bad Request — Запрос не может быть обработан из-за ошибки синтаксиса.
403 Forbidden — Доступ к запрошенному клиентом ресурсу запрещен.
404 Not Found — Запрошенный ресурс не найден на сервере.

5. 5ХХ (ошибка сервера)
500 Internal Server Error — Запрос не может быть выполнен из-за внутренней ошибки в программном обеспечении сервера.
501 Not Implemented — Сервер не поддерживает запрошенную функциональность, например, не может выполнить запрошенный метод HTTP для указанного ресурса.
505 HTTP Version Not Supported — Версия HTTP, указанная в запросе, не поддерживается.

Полный список кодов ответов с описанием можно посмотреть в разделе «Status Codes» документа RFC 9110.

#HTTP #Status | 😏 @iscode

🥷 Джонни вещает: распространенные ошибки веб-сервера Nginx (1 ч.)

Начинаем объемную рубрику, которая посвящена ошибкам веб-сервера Nginx, с которыми вы сталкивались или столкнетесь (не дай бог конечно🚬)

Стартуем с самой тяжелой ошибки — Unable to connect/Refused to Connect 🪫

Если при попытке получить доступ к вашему сайту вы видите следующие ошибки — Firefox can’t establish a connection to the server at www.example.com, или www.example.com refused to connect, то причины следующие:

⏳ Nginx не запущен: проверьте состояние Nginx с помощью sudo systemctl status nginx.

Запустите Nginx с помощью sudo systemctl start nginx. Если Nginx не удается запустить, запустите sudo nginx -t, чтобы выяснить, нет ли ошибок в вашем конфигурационном файле, и проверьте логи (sudo journalctl -eu nginx), чтобы выяснить, почему он не запускается.

Брандмауэр блокирует порты 80 и 443: если вы используете брандмауэр UFW на Debian/Ubuntu, выполните sudo ufw allow 80,443/tcp, чтобы открыть TCP порты 80 и 443.

— Если вы используете Firewalld на RHEL/CentOS/Rocky Linux/AlmaLinux, выполните sudo firewall-cmd –permanent –add-service={http,https}, затем sudo systemctl reload firewalld, чтобы открыть TCP порты 80 и 443.

Fail2ban: если ваш сервер использует его для блокировки вредоносных запросов — представим, fail2ban запретил ваш IP-адрес.

Решение: выполните команду sudo journalctl -eu fail2ban, чтобы проверить, не заблокирован ли ваш IP-адрес. Вы можете добавить свой IP-адрес в список fail2ban ignoreip, чтобы он получил разбан.

🌃 Ошибки 404 Not Found и 403 Forbidden я разберу во второй части, а сейчас поставьте реакций, чтобы ускорить ее выход 💵

#Nginx | 😏 @iscode

🥷 Джонни вещает: консольная утилита для визуализации результата любых shell команд

В общем случае с помощью shell команды можно получить любую метрику, без написания кода и интеграций. А значит в консоли должен быть простой и удобный инструмент для визуализации.

— Наблюдение за изменением состояния в базе данных, мониторинг размера очередей, телеметрия с удаленных серверов, запуск деплой скриптов и получение нотификации по завершению — конфигурируется за минуту простым YAML файлом.

🕹 Код доступен на гитхабе. Инструкции по установке — для Linux, macOS и (экспериментально) Windows.

Но, зачем мне твоя бурда, когда у меня есть, допустим, полноценные системы мониторинга? - а я сразу оговорюсь, что это ни в коей мере не альтернатива полномасштабным дашбордам и мониторингу. Сравнивать Sampler c Prometheus+Grafana — то же что сравнивать tail и less с Elastic Stack или Splunk.

Но если поднимать и настраивать продакшн мониторинг для вашей задачи — как из пушки по воробьям, то возможно Sampler будет ответом на вопрос. Он задумывался как инструмент для прототипирования, демонстраций, или просто наблюдения за метриками на локали и удаленном сервере. Вы можете подумать, что его надо ставить на все сервера, но нет, запускаем локально, но метрики собираем с удалённых тачек.

Каждый компонент на дашборде имеет init секцию, где можно произвести вход по ssh (или сделать любое другое действие для входа в interactive shell — установить соединение с БД, подключиться по JMX, авторизоваться в API, итп)

Как бекенд-программисту, мне часто приходится отлаживать, прототипировать и измерять. Отсюда и регулярная необходимость визуализации и мониторинга на скорую руку.

🚬 Писать каждый раз что-то кастомное — неоправданно долго, но если процесс кастомизации был бы быстрым и (более-менее) удобным, такая визуализация вполне могла бы экономить время и решать задачи.

#DevOps #shell #prototyping | 😊 @iscode

🥷 Джонни вещает: деление IP сети на подсети при помощи маски легко и быстро

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

🌃 youtube.com (руководство как поднять впн для комфортного просмотра YT)

#IP #Subnet #Summarization

🥷 Джонни вещает: Осеннее обновление: релиз Proxmox VE 8.3

Проксмокс, он же прокс, он же Proxmox VE, или Proxmox Virtual Environment - в очередной раз обновился. Платформа виртуализации, плавно, в отличии от конкурентов развивающаяся уже 16 с половиной лет (!), вышла, в этот раз, с небольшим, но интересным списком обновлений.

— Эта версия построена на базе Debian 12.8 (Bookworm), но использует ядро Linux 6.8.12-4 по умолчанию, с возможностью выбора ядра 6.11. Программное обеспечение включает обновления таких технологий, как QEMU 9.0.2, LXC 6.0.0 и ZFS 2.2.6 (с совместимостью для ядра 6.11).

❗️ Улучшения в Proxmox Virtual Environment 8.3
1. Интеграция SDN и брандмауэра: SDN позволяет создавать виртуальные сети (VNet-ы) и управлять ими через веб-интерфейс Proxmox VE. Теперь SDN интегрирован с брандмауэром, автоматически создавая IP-set-ы для VNet-ов и виртуальных гостей. Это упрощает создание и управление правилами брандмауэра. Новый брандмауэр на основе nftables может фильтровать сетевой трафик как на уровне хоста, так и на уровне VNet.

2. Webhook-и для системы уведомлений: Система уведомлений Proxmox позволяет настраивать HTTP-запросы для различных событий, таких как обновления системы или проблемы с узлами кластера. Это позволяет интегрироваться с сервисами, поддерживающими webhook-и.

3. Новая функция «Tag View» для дерева ресурсов: Позволяет пользователям быстро видеть виртуальных гостей, сгруппированных по тегам.

4. Поддержка Ceph Squid (technology preview): Добавлена поддержка Ceph Squid 19.2.0, а также продолжается поддержка Ceph Reef 18.2.4 и Ceph Quincy 17.2.7. Пользователи могут выбрать предпочтительную версию Ceph при установке.

5. Быстрее резервные копии контейнеров: При резервном копировании контейнеров на Proxmox Backup Server теперь можно пропускать файлы, которые не изменились с момента последнего бэкапа, что ускоряет процесс.

6. Миграция с других гипервизоров: Упрощен импорт виртуальных машин из форматов OVF и OVA через веб-интерфейс Proxmox VE. Также появился мастер импорта для миграции виртуальных машин с других гипервизоров, таких как VMware.

Proxmox VE 8.3 доступен для скачивания тут. ISO-образ содержит полный набор функций и может быть установлен на "голое железо". Обновления дистрибутива с более ранних версий Proxmox VE возможны через apt. Возможно установить Proxmox VE 8.3 в Debian.

#VE #Proxmox | 😊 @iscode