доставка кода на сервер
Установка и настройка локального сервера gitlab
Gitlab обрел большую популярность в последние годы, т.к. является коробочным решением, позволяющим не только использовать функционал системы хранения версий кода, но и хранить образы во встроенном registry, настраивать пайплайны для сборок, тестирования и доставки кода и множество других функций. Так же gitlab возможно установить непосредственно в контур предприятия, что является важной и удобной возможностью с точки зрения безопасности и ускорения процессов внутри компании.
Локальная установка и конфигурирование Gitlab
Рассмотрим этапы установки локальной копии сервера gitlab с доступным для хранения образов registry и настроенным раннером для выполнения пайплайнов на базе gitlab-ci.
Настраиваем второй сервер с nginx, который будет проксировать на наш gitlab трафик. В качестве операционной системы так же используем centos7, выделяемые ресурсы минимальны, 2 ядра и 512 МБ ОЗУ.
Устанавливаем nginx
Проверяем
Проверяем доступ к нашему gitlab с помощью браузера ( для доступа по доменному имени из локальной сети дополнительно требуется настройка так называемого hairpin nat на сетевом оборудовании, данная задача выходит за рамки данной инструкции):
Таким образом, получили готовую к использованию инсталляцию сервера gitlab с репозиторием для докер образов, раннером для выполнения CI/CD пайплайнов.
Есть DevOps-задачи? Мы можем предложить решение любых вопросов нашими специалистами DevOps-аутсорсинга.
Дебажим U-boot на реальном железе
Продолжение предыдущей статьи, в которой мы ускорили разработку под embedded linux. Рабочая станция + sftp сервер + nfs сервер ускорили на порядок (10х) доставку изменений кода на целевое железо. Теперь не нужно часами компилировать код. В этой статье продолжаем очеловечивать разработку. На этот раз прикручиваем полноценную графическую IDE и пошаговую отладку кода на целевом железе с помощью программатора J-Link. Но пока только загрузчика U-boot. И автоматизируем развертывание рабочей среды разработчика с помощью Docker.
Подготовка железа
Подключаем программатор по JTAG к целевой железке.
подключаем программатор по USB к хосту (рабочему ПК).
подключаем железку к хосту с помощью COM-порта.
подаем питание на железку.
Может случиться такое, что, в ядре выводы JTAG-интерфейса переинициализируются на другие функции. В этом случае, сразу после подачи питания нужно не дать загрузчику начать загрузку ядра. Для этого нужно в консоли нажать любую клавишу до окончания обратного отсчета и остаться в консоли загрузчика.
Установка драйверов
Скачиваем драйвера j-link и устанавливаем их:
Сборка toolchain
В вашем случае он может быть уже предустановлен/предскомпилирован. В нашем случае компилируем:
Установка IDE и создание проекта
Скачиваем Eclipse IDE for Embedded C/C++ Developers и распаковываем архив в /opt/eclipse.
Задаем каталог с исходниками U-boot. В нашем случае, их можно найти в build_dir/target-arm_cortex-a7+neon-vfpv4_musl_eabi/u-boot-wirelessroad_ecspi3/u-boot-2017.07:
Здесь, несколько каталогов тулчейна, разделенных двоеточием. В итоге, должно получиться следующее:
Следующим шагом отключаем дефолтный компилятор:
и задаем пути к заголовочным файлам нашего тулчейна:
Не забываем включить параллельную сборку:
Готово. Теперь можно попробовать собрать u-boot. Нажмите правой кнопкой мыши на проект и затем Clean Project для очистки проекта, Build Project для сборки:
Возможно, в ide вы не найдете этого файла, поскольку он скрыт. Включить отображение скрытых файлов можно следующим образом:
После этого пересоберите проект, чтобы отладочные символы попали в итоговый бинарник.
Автоматизируй это.
Довольно длительная последовательность действий и практически каждый клиент, использующий наше BSP, каждый новый разработчик на каком-нибудь этапе да и споткнется, проверено на практике. Поэтому, логично будет автоматизировать развертнывание всей среды разработки, включая скачивание исходных кодов, сборку тулчейна и установку IDE. При этом, упаковка в docker контейнер дает надежку, что вся процедура развертывания будет более-менее стабильно разработать на максимально большом количестве компьютеров. Таким образом, вся выше-описанная инструкция заменяется четырьмя консольными командами:
И уже из консоли контейнера:
Исходники среды и более подробную инструкцию с некоторыми пояснениями можно найти тут. Eclipse, к сожалению, имеет ограниченные возможности для работы из консоли, но, к счастью, он portable. Таким образом, один раз настроив проект в eclipse, и упаковав его обратно в архив, можно переносить пред-настроенную IDE с машины на машину. Использование docker, в добавок к изоляции среды позволяет также решить возможные ошибки при распаковке архива по другому пути. В теории должно работать, практика покажет как оно на самом деле.
и данное значение хард-кодим в u-boot/lib/fdtdec.c в функции fdtdec_setup():
Как этот костыль заменить корректными методами мы пока, к сожалению, не разобрались. Надеюсь, осилим в ближайшее время, но пока так. В вашем случае, если eclipse не сможет стартануть отладку кода, может оказаться полезным запустить отладку в консольном режиме. Для этого запускаете GDBServer:
а далее шагаете до участка кода, на котором все рушится:
Тут можно ознакомиться с тем, как мы искали проблемный код.
Собственно, отладка
Задаем точку остановки, например функцию initcall_run_list, которая в цикле запускает функции инициализации перферии:
И нажимаем на кнопку Debug, а следом на кнопку Resume:
Продолжение
Тут и тут можно ознакомиться с удаленной отладкой приложений пользовательского уровня. В следующей же статье надеюсь добраться до пошаговой отладки ядра.
Web PUSH Notifications быстро и просто
Добрый день. В этой небольшой заметке я хочу рассказать как быстро и просто настроить push-уведомления на вашем сайте. Эта статья ни в коем случае не претендует на звание исчерпывающего руководства, но, я надеюсь, что она даст точку старта для дальнейшего изучения.
Информации по этой теме в интернете полно, но она фрагментирована, разбросана по разным ресурсам и перемешена с уведомлениями для мобильных устройств с примерами на Java, C++ и Python. Нас же, как веб-разработчиков, интересует JavaScript. В этой статье я постараюсь саккумулировать всю необходимую и полезную информацию.
Я думаю, вы уже знаете что такое push-уведомления, но я всё же напишу коротко о главном.
Пользователь, заходя на сайт, вытягивает (pull) с него данные. Это удобно и безопасно, но с развитием интернет ресурсов, появилась необходимость оперативно доставлять информацию пользователям не дожидаясь пока те сами сделают запрос. Так и появилась технология принудительной доставки (push) данных с сервера клиенту.
Push-уведомления работают только если у вас на сайте есть HTTPS.
Без валидного SSL сертификата запустить не получится. Так что если у вас еще нет поддержки HTTPS, то пришло время её сделать. Рекомендую воспользоваться Let’s Encrypt.
Для запуска на localhost нужно прибегать к хитростям. Я же тестировал скрипты на Github Pages.
Оглавление
Хорошие уведомления
Сразу хочу оговориться, что push-уведомления не для рекламных рассылок. Отправлять нужно только то, что действительно нужно конкретному пользователю и на что он действительно должен оперативно отреагировать.
Плохие примеры тоже требуют уведомления, но на них не нужно реагировать оперативно. Эти уведомления можно отправить на почту. Вообще, все важные уведомления рекомендуется дублировать на почту, так-как push-уведомления могут не дойти до пользователя по разным, не зависящих от вас, причинам. Также важным фактором является актуальность события. Об этом я еще поговорю чуть позже. Рекомендую к прочтению:
Вернемся к нашим баранам. Так как же всё это работает? Для начала немного теории.
Теория
Среди непосвященных бытует мнение что push-уведомления это простая технология, не требующая для реализации особых ресурсов. В действительности же это целый пул технологий.
Для начала небольшая схема того как все это работает (анимированная схема):
К сожалению, мне не удалось выяснить кто и как создает ID устройства и как сервер сообщений привязывается к конкретному устройству. Я использовал сервер сообщений Firebase Cloud Messaging от Google и его библиотеку. К сожалению, я не смог выяснить можно ли его заменить на свой сервер и как это сделать.
Изначально для отправки сообщений использовали:
Cloud to Device Messaging
Потом его заменили на:
Google Cloud Messaging
А потом еще раз поменяли на:
Firebase Cloud Messaging
Интересно, что дальше.
Что же происходит на стороне клиента?
Google рекомендует использовать переключатель для подписки и отписки от уведомлений. Таким образом, инициация процедуры подписки на уведомления исходит от пользователя, а не от сайта.
Принудительно подписывать на уведомления каждого приходящего пользователя, это плохая практика. Не делайте так.
Это все выглядит очень сложно, но на сервере все не проще.
Сложности на серверной стороне
Практика
Наконец-то, мы перешли к самому главному. Как я уже говорил ранее, в качестве сервера сообщений мы будем использовать Firebase Cloud Messaging, поэтому мы начинаем с регистрации и создания проекта на Firebase.
Можно еще покопаться в настройках и поиграться с разделением прав доступа, но, в общем-то, работа с сайтом Firebase закончена.
Приступаем к написанию клиента
Начнем с того что создадим Service Worker для получения push-уведомлений.
Создаем файл firebase-messaging-sw.js с следующим содержимым.
Файл Service Worker-а должен называться именно firebase-messaging-sw.js и обязательно должен находиться в корне проекта, то есть доступен по адресу https://example.com/firebase-messaging-sw.js. Путь к этому файлу жестко прописан в библиотеке Firebase.
Написанного кода достаточно для того чтобы показывать уведомления. О дополнительных возможностях поговорим чуть позже. Теперь добавим библиотеку Firebase и скрипт подписки в наш шаблон страницы.
Добавляем на страницу кнопку для подписки на уведомления
Подписка на уведомления
Вот и все. Это весь код который требуется для получения push-уведомлений.
Отправка уведомлений с сервера
В общем виде отправка уведомления выглядит так:
Все поля по порядку:
Это пример отправки одного уведомления одному получателю. Можно отправить одно уведомление сразу нескольким получателям. Вплоть до 1000 получателей за раз.
Пример ответов от сервера сообщений:
Мы не привязаны к какому-то конкретному языку программирования и для простоты примера будем использовать PHP с расширением cURL. Скрипт отправки уведомления нужно запускать из консоли.
messaging.onMessage
Обработчик messaging.onMessage стоит отдельного упоминания, так как он относится как раз к категории подводных камней. В примерах от Firebase я не видел примера использование этого обработчика. О нем мне рассказал FluorescentHallucinogen, за что ему отдельное спасибо, но он не упомянул о некоторых особенностях его использования.
Что же это за обработчик и как он работает. Из документации мы знаем, что этот обработчик вызывается если мы получаем push-уведомление и находимся в этот момент на странице сайта с которого отправлено уведомление (желающие использовать нативное решение могут посмотреть пример реализации). Эта функциональность очень полезна тем, что мы можем отобразить уведомление на странице сделав красивую модалку или еще что-то. У меня такой необходимости нет, потому я просто отображу стандартное уведомление.
Вроде все просто, но есть подводный камень. Дело все в том что на мобильных устройствах запрещено использовать конструктор Notification. И для решения этой проблемы нужно использовать ServiceWorkerRegistration.showNotification() и обработчик в этом случае будет иметь виде:
Теперь уведомления работают и на мобильных устройствах. Казалось бы уже все, но нет. Не смотря на заверения некоторых, ServiceWorker не должен быть пустым. Мы же хотим, что бы по клику пользователь переходил на нужную нам страницу. Для этого нам нужно добавить обработчик клика по уведомлению в ServiceWorker.
Сохраняем параметры уведомления для доступа свойству click_action в ServiceWorker-е.
Обрабатываем клик по уведомлению в ServiceWorker-е.
TTL и дополнительный контроль над уведомлением
Важным свойством для уведомления может является время его актуальности. Это зависит от ваших бизнес процессов. По умолчанию время жизни уведомлений 4 недели. Это очень много для уведомлений такого характера. Например, уведомление «Ваша любимая передача начинается через 15 минут» актуально в течении 15 минут. После этого сообщение уже не актуально и показываться не должно. За контроль над временем жизни отвечает свойство time_to_live со значением от 0 до 2419200 секунд. Подробней читать в документации. Сообщение с указанным TTL будет иметь вид:
Сообщение вида «Ваша любимая передача начинается через 15 минут» актуально в течении 15 минут, но уже через минуту после отправки оно станет не корректным. Потому что передача начнется не через 15 минут, а уже через 14. Контролировать такие ситуации нужно на стороне клиента.
Для этого мы поменяем отправляемое с сервера сообщение:
Вот таким незамысловатым образом мы получили полный контроль над уведомлением. Что самое интересное, пользователю мы показываем время уведомления в его часовом поясе. Это актуально для сервисов который работают по всему миру или регионах с широким разбросом часовых поясов как у матушки-России.
Заключение
А теперь поговорим о грустном. Не смотря на все прелести технологии, у неё есть ряд недостатков:
Библиотека Firebase скрывает в себе много тайн и её исследование могло бы дать ответы на некоторые вопросы, но это уже выходит за рамки этой статьи.
Поиграться
Проект на GitHub Pages
Так как для запуска Service Worker-а нужен HTTPS, то самым простым решением было разместить проект на GitHub Pages, что я и сделал.
Проект представляет из себя полноценное приложение для отправки и получения уведомлений. Для того что бы получить уведомление надо:
Можно отправить уведомление через любой инструмент для отправки HTTP запросов. Можно использовать сURL, я предпочитаю приложение Postman для Chrome.
Запрос такой же как и описанный ранее:
Вот и все. Получаем уведомление и радуемся жизни.
Ссылки
Updated at 2018-06-09
Обнаружились некоторые «особенности» в работе уведомлений.
Дубликаты уведомлений
Ко мне несколько раз обращались с вопросом: «Как исправить дублирующиеся уведомления?»
Проявляется эта проблема если открыть сайт отправляющий уведомления одновременно в нескольких вкладках. В этом случае Service Worker отправляет уведомление в обе вкладки и в обоих вкладках срабатывает метод messaging.onMessage. Наблюдать эту проблему можно на моем Demo проекте.
Могу порекомендовать для этих целей библиотеку pamelafox/lscache.
Если у вас есть другой метод решения проблемы, напишите в комментариях.
Картинки в уведомлениях
Сегодня ко мне обратился пользователь CTterorist, заметивший, что не отображаются картинки (image) в уведомлениях.
То есть, если вы отправите сообщение в таком виде, то Firebase потеряет картинку.
Обработчики показа уведомления такие же как в примерах выше.
Подключение к сайту и отправка или получение данных по API (POST, GET. ) (с описанием кода)
Стояла задача отправить данные по API на внешний сервер из 1С, задача достаточно тривиальная, но возникли некоторые сложности поскольку у меня никак не выходило отправить данные через POST. После того как была написана данная обработка сразу смог определить проблему.
Тестировалось в УПП 1.3 (8.3.9.2170)
В моем соединении нету пользователя, пароля, не используется защищенное соединение. Если Вам необходимы эти параметры их можно добавить в строке «Все параметры подключения» и вынести поля на форму или написать комментарий я обновлю обработку.
Основной код отправки данных из описанного функционала (у меня использовалось только GET и POST, остальное добавил вдруг кому пригодится):
Можете поблагодарить, если Вам помог описанный функционал.
Скачать файлы
Специальные предложения
Попробуйте заменить на вот это:
Обновление 12.08.19 15:30
См. также
Модуль обмена с QIWI Промо
Компании, которые используют систему моментальных платежей QIWI, ценят ее за удобство по скорости выплат и для платежей по запросу. Но такие переводы сложны для учета, а при большом объеме проводимых операций отнимают много времени и превращаются в дополнительную головную боль. Мы сотрудничали с компаниями, которые отправляют большое количество платеже на QIWI, и часто слышали боль бухгалтеров о том, как им сложно работать с такими переводами. Поэтому мы автоматизировали выплаты через QIWI в 1С и создали модуль интеграции 1С c API QIWI Wallet и QIWI TopUp.
25.05.2020 6900 0 Neti 10
Расширение конфигурации для Web-доступа к 1С (1С в роли back-end)
Для реализации того, чтобы 1С формировала и отдавала страницу, которую можно было бы открыть через браузер было написано расширение, которое позволяет публиковать из 1С произвольные ресурсы, будь то API, сайт или изображения / прочие файлы.
01.04.2021 7532 10 SaschaG 4
Работа с картами в 1С на примере бесплатной библиотеки Leaflet
Разработка функционала отображения и выбора пунктов доставки на карте прямо в 1С с помощью бесплатной библиотеки Leaflet. Тестирование производилось на платформе 8.3.15.1534 на тонком клиенте.
31.03.2021 8439 21 Parsec1C 11
Отправка Push-уведомлений через сервис Firebase Cloud Messaging по протоколу FCM HTTP v1 API
При разработке нативного приложения Android для ТСД, в котором присутствует функционал отображения задач кладовщикам, созданных в 1С, возникла необходимость отправлять push-уведомления о появлении новых задач. Для отправки таких уведомлений было решено использовать сервис Firebase Cloud Messaging (FCM). Так как для 1С, в отличии от других языков программирования, не существует готовых библиотек, что вполне логично, то очевидным способом отправки является использование протокола HTTP. Однако, существующая информация в интернете в части 1С содержит только сведений об отправке push-уведомлений через этот сервис с использованием устаревшего протокола HTTP Firebase Cloud Messaging. Сам Google не рекомендует использовать данный протокол и настоятельно склоняет к переходу на новый протокол FCM HTTP v1 API. Что ж, пришлось разбираться самостоятельно.
24.03.2021 5471 10 ltfriend 6
BIM: взаимодействие с платформой Autodesk Forge Промо
Предлагаемый пример демонстрирует широкие возможности для взаимодействия «1С:Предприятие» с платформой Autodesk Forge и позволяет вам получить базовые представления о применения технологий информационного моделирования в строительстве. Поддерживаются все версии платформы от 8.3.12 и выше до 8.3.18.
Памятка пользователям ssh
Предупреждение: пост очень объёмный, но для удобства использования я решил не резать его на части.
Управление ключами
Теория в нескольких словах: ssh может авторизоваться не по паролю, а по ключу. Ключ состоит из открытой и закрытой части. Открытая кладётся в домашний каталог пользователя, «которым» заходят на сервер, закрытая — в домашний каталог пользователя, который идёт на удалённый сервер. Половинки сравниваются (я утрирую) и если всё ок — пускают. Важно: авторизуется не только клиент на сервере, но и сервер по отношению к клиенту (то есть у сервера есть свой собственный ключ). Главной особенностью ключа по сравнению с паролем является то, что его нельзя «украсть», взломав сервер — ключ не передаётся с клиента на сервер, а во время авторизации клиент доказывает серверу, что владеет ключом (та самая криптографическая магия).
Генерация ключа
Свой ключ можно сгенерировать с помощью команды ssh-keygen. Если не задать параметры, то он сохранит всё так, как надо.
Ключ можно закрыть паролем. Этот пароль (в обычных графических интерфейсах) спрашивается один раз и сохраняется некоторое время. Если пароль указать пустым, он спрашиваться при использовании не будет. Восстановить забытый пароль невозможно.
Структура ключа
/.ssh/id_rsa.pub — открытый ключ. Его копируют на сервера, куда нужно получить доступ.
/.ssh/id_rsa — закрытый ключ. Его нельзя никому показывать. Если вы в письмо/чат скопипастите его вместо pub, то нужно генерировать новый ключ. (Я не шучу, примерно 10% людей, которых просишь дать ssh-ключ постят id_rsa, причём из этих десяти процентов мужского пола 100%).
Копирование ключа на сервер
/.ssh/authorized_keys и положить туда открытый ключ, то можно будет заходить без пароля. Обратите внимание, права на файл не должны давать возможность писать в этот файл посторонним пользователям, иначе ssh его не примет. В ключе последнее поле — user@machine. Оно не имеет никакого отношения к авторизации и служит только для удобства определения где чей ключ. Заметим, это поле может быть поменяно (или даже удалено) без нарушения структуры ключа.
Если вы знаете пароль пользователя, то процесс можно упростить. Команда ssh-copy-id user@server позволяет скопировать ключ не редактируя файлы вручную.
Замечание: Старые руководства по ssh упоминают про authorized_keys2. Причина: была первая версия ssh, потом стала вторая (текущая), для неё сделали свой набор конфигов, всех это очень утомило, и вторая версия уже давным давно переключилась на версии без всяких «2». То есть всегда authorized_keys и не думать о разных версиях.
Если у вас ssh на нестандартном порту, то ssh-copy-id требует особого ухищрения при работе: ssh-copy-id ‘-p 443 user@server’ (внимание на кавычки).
Ключ сервера
/.ssh/known_hosts. Узнать, где какой ключ нельзя (ибо несекьюрно).
Если ключ сервера поменялся (например, сервер переустановили), ssh вопит от подделке ключа. Обратите внимание, если сервер не трогали, а ssh вопит, значит вы не на тот сервер ломитесь (например, в сети появился ещё один компьютер с тем же IP, особо этим страдают всякие локальные сети с 192.168.1.1, которых в мире несколько миллионов). Сценарий «злобной man in the middle атаки» маловероятен, чаще просто ошибка с IP, хотя если «всё хорошо», а ключ поменялся — это повод поднять уровень паранойи на пару уровней (а если у вас авторизация по ключу, а сервер вдруг запросил пароль — то паранойю можно включать на 100% и пароль не вводить).
Ключ сервера хранится в /etc/ssh/ssh_host_rsa_key и /etc/ssh/ssh_host_rsa_key.pub. Их можно:
а) скопировать со старого сервера на новый.
б) сгенерировать с помощью ssh-keygen. Пароля при этом задавать не надо (т.е. пустой). Ключ с паролем ssh-сервер использовать не сможет.
Заметим, если вы сервера клонируете (например, в виртуалках), то ssh-ключи сервера нужно обязательно перегенерировать.
Старые ключи из know_hosts при этом лучше убрать, иначе ssh будет ругаться на duplicate key.
Копирование файлов
Передача файлов на сервер иногда может утомлять. Помимо возни с sftp и прочими странными вещами, ssh предоставляет нам команду scp, которая осуществляет копирование файла через ssh-сессию.
scp path/myfile user@8.8.8.8:/full/path/to/new/location/
Обратно тоже можно:
scp user@8.8.8.8:/full/path/to/file /path/to/put/here
Fish warning: Не смотря на то, что mc умеет делать соединение по ssh, копировать большие файлы будет очень мучительно, т.к. fish (модуль mc для работы с ssh как с виртуальной fs) работает очень медленно. 100-200кб — предел, дальше начинается испытание терпения. (Я вспомнил свою очень раннюю молодость, когда не зная про scp, я копировал
5Гб через fish в mc, заняло это чуть больше 12 часов на FastEthernet).
Возможность копировать здорово. Но хочется так, чтобы «сохранить как» — и сразу на сервер. И чтобы в графическом режиме копировать не из специальной программы, а из любой, привычной.
sshfs
Теория: модуль fuse позволяет «экспортировать» запросы к файловой системе из ядра обратно в userspace к соответствующей программе. Это позволяет легко реализовывать «псевдофайловые системы». Например, мы можем предоставить доступ к удалённой файловой системе через ssh так, что все локальные приложения (за малым исключением) не будут ничего подозревать.
Собственно, исключение: O_DIRECT не поддерживается, увы (это проблема не sshfs, это проблема fuse вообще).
Использование: установить пакет sshfs (сам притащит за собой fuse).
Собственно, пример моего скрипта, который монтирует desunote.ru (размещающийся у меня на домашнем комьютере — с него в этой статье показываются картинки) на мой ноут:
Делаем файл +x, вызываем, идём в любое приложение, говорим сохранить и видим:
Если вы много работаете с данными от рута, то можно (нужно) сделать idmap:
-o idmap=user. Работает она следующим образом: если мы коннектимся как пользователь pupkin@server, а локально работаем как пользователь vasiliy, то мы говорим «считать, что файлы pupkin, это файлы vasiliy». ну или «root», если мы коннектимся как root.
В моём случае idmap не нужен, так как имена пользователей (локальное и удалённое) совпадают.
Заметим, комфортно работать получается только если у нас есть ssh-ключик (см. начало статьи), если нет — авторизация по паролю выбешивает на 2-3 подключение.
Удалённое исполнение кода
ssh может выполнить команду на удалённом сервере и тут же закрыть соединение. Простейший пример:
ssh user@server ls /etc/
Выведет нам содержимое /etc/ на server, при этом у нас будет локальная командная строка.
Это нас приводит следующей фиче:
Проброс stdin/out
Допустим, мы хотим сделать запрос к программе удалённо, а потом её вывод поместить в локальный файл
ssh user@8.8.8.8 command >my_file
Допустим, мы хотим локальный вывод положить удалённо
mycommand |scp — user@8.8.8.8:/path/remote_file
Усложним пример — мы можем прокидывать файлы с сервера на сервер: Делаем цепочку, чтобы положить stdin на 10.1.1.2, который нам не доступен снаружи:
mycommand | ssh user@8.8.8.8 «scp — user@10.1.1.2:/path/to/file»
Есть и вот такой головоломный приём использования pipe’а (любезно подсказали в комментариях в жж):
Tar запаковывает файлы по маске локально, пишет их в stdout, откуда их читает ssh, передаёт в stdin на удалённом сервере, где их cd игнорирует (не читает stdin), а tar — читает и распаковывает. Так сказать, scp для бедных.
Алиасы
Скажу честно, до последнего времени не знал и не использовал. Оказались очень удобными.
Можно прописать общесистемные alias’ы на IP (/etc/hosts), но это кривоватый выход (и пользователя и опции всё равно печатать). Есть путь короче.
/.ssh/config позволяет задать параметры подключения, в том числе специальные для серверов, что самое важное, для каждого сервера своё. Вот пример конфига:
Все доступные для использования опции можно увидеть в man ssh_config (не путать с sshd_config).
Опции по умолчанию
По подсказке UUSER: вы можете указать настройки соединения по умолчанию с помощью конструкции Host *, т.е., например:
То же самое можно сделать и в /etc/ssh/ssh_config (не путать с /etc/ssh/sshd_config), но это требует прав рута и распространяется на всех пользователей.
Проброс X-сервера
Собственно, немножко я проспойлерил эту часть в примере конфига выше. ForwardX11 — это как раз оно.
и чудо, окошко логина в windows на нашем рабочем столе. Заметим, тщательно зашифрованное и неотличимое от обычного ssh-трафика.
Socks-proxy
Когда я оказываюсь в очередной гостинице (кафе, конференции), то местный wifi чаще всего оказывается ужасным — закрытые порты, неизвестно какой уровень безопасности. Да и доверия к чужим точкам доступа не особо много (это не паранойя, я вполне наблюдал как уводят пароли и куки с помощью банального ноутбука, раздающего 3G всем желающим с названием близлежащей кафешки (и пишущего интересное в процессе)).
Особые проблемы доставляют закрытые порты. То джаббер прикроют, то IMAP, то ещё что-нибудь.
Обычный VPN (pptp, l2tp, openvpn) в таких ситуациях не работает — его просто не пропускают. Экспериментально известно, что 443ий порт чаще всего оставляют, причём в режиме CONNECT, то есть пропускают «как есть» (обычный http могут ещё прозрачно на сквид завернуть).
Решением служит socks-proxy режим работы ssh. Его принцип: ssh-клиент подключается к серверу и слушает локально. Получив запрос, он отправляет его (через открытое соединение) на сервер, сервер устанавливает соединение согласно запросу и все данные передаёт обратно ssh-клиенту. А тот отвечает обратившемуся. Для работы нужно сказать приложениям «использовать socks-proxy». И указать IP-адрес прокси. В случае с ssh это чаще всего localhost (так вы не отдадите свой канал чужим людям).
Подключение в режиме sock-proxy выглядит так:
Вот так выглядит мой конфиг:
/etc/ssh/sshd_config:
(фрагмент)
Port 22
Port 443
/.ssh/config с ноутбука, который описывает vpn
(обратите внимание на «ленивую» форму записи localhost — 127.1, это вполне себе законный метод написать 127.0.0.1)
Проброс портов
Мы переходим к крайне сложной для понимания части функционала SSH, позволяющей осуществлять головоломные операции по туннелированию TCP «из сервера» и «на сервер».
Для понимания ситуации все примеры ниже будут ссылаться на вот эту схему:
Комментарии: Две серые сети. Первая сеть напоминает типичную офисную сеть (NAT), вторая — «гейтвей», то есть сервер с белым интерфейсом и серым, смотрящим в свою собственную приватную сеть. В дальнейших рассуждениях мы полагаем, что «наш» ноутбук — А, а «сервер» — Б.
Задача: у нас локально запущено приложение, нам нужно дать возможность другому пользователю (за пределами нашей сети) посмотреть на него.
Решение: проброс локального порта (127.0.0.1:80) на публично доступный адрес. Допустим, наш «публично доступный» Б занял 80ый порт чем-то полезным, так что пробрасывать мы будем на нестандартный порт (8080).
Итоговая конфигурация: запросы на 8.8.8.8:8080 будут попадать на localhost ноутбука А.
Опция -R позволяет перенаправлять с удалённого (Remote) сервера порт на свой (локальный).
Важно: если мы хотим использовать адрес 8.8.8.8, то нам нужно разрешить GatewayPorts в настройках сервера Б.
Задача. На сервере «Б» слушает некий демон (допустим, sql-сервер). Наше приложение не совместимо с сервером (другая битность, ОС, злой админ, запрещающий и накладывающий лимиты и т.д.). Мы хотим локально получить доступ к удалённому localhost’у.
Итоговая конфигурация: запросы на localhost:3333 на ‘A’ должны обслуживаться демоном на localhost:3128 ‘Б’.
Опция -L позволяет локальные обращения (Local) направлять на удалённый сервер.
Задача: На сервере «Б» на сером интерфейсе слушает некий сервис и мы хотим дать возможность коллеге (192.168.0.3) посмотреть на это приложение.
Итоговая конфигурация: запросы на наш серый IP-адрес (192.168.0.2) попадают на серый интерфейс сервера Б.
Вложенные туннели
Разумеется, туннели можно перенаправлять.
Усложним задачу: теперь нам хочется показать коллеге приложение, запущенное на localhost на сервере с адресом 10.1.1.2 (на 80ом порту).
Что происходит? Мы говорим ssh перенаправлять локальные запросы с нашего адреса на localhost сервера Б и сразу после подключения запустить ssh (то есть клиента ssh) на сервере Б с опцией слушать на localhost и передавать запросы на сервер 10.1.1.2 (куда клиент и должен подключиться). Порт 9999 выбран произвольно, главное, чтобы совпадал в первом вызове и во втором.
Реверс-сокс-прокси
Туннелирование
Если к этому моменту попа отдела безопасности не сияет лысиной, а ssh всё ещё не внесён в список врагов безопасности номер один, вот вам окончательный убийца всего и вся: туннелирование IP или даже ethernet. В самых радикальных случаях это позволяет туннелировать dhcp, заниматься удалённым arp-спуфингом, делать wake up on lan и прочие безобразия второго уровня.
(сам я увы, таким не пользовался).
Легко понять, что в таких условиях невозможно никаким DPI (deep packet inspection) отловить подобные туннели — либо ssh разрешён (читай — делай что хочешь), либо ssh запрещён (и можно смело из такой компании идиотов увольняться не ощущая ни малейшего сожаления).
Проброс авторизации
Если вы думаете, что на этом всё, то…… впрочем, в отличие от автора, у которого «снизу» ещё не написано, читатель заранее видит, что там снизу много букв и интриги не получается.
OpenSSH позволяет использовать сервера в качестве плацдарма для подключения к другим серверам, даже если эти сервера недоверенные и могут злоупотреблять чем хотят.
Для начала о простом пробросе авторизации.
Допустим, мы хотим подключиться к серверу 10.1.1.2, который готов принять наш ключ. Но копировать его на 8.8.8.8 мы не хотим, ибо там проходной двор и половина людей имеет sudo и может шариться по чужим каталогам. Компромиссным вариантом было бы иметь «другой» ssh-ключ, который бы авторизовывал user@8.8.8.8 на 10.1.1.2, но если мы не хотим пускать кого попало с 8.8.8.8 на 10.1.1.2, то это не вариант (тем паче, что ключ могут не только поюзать, но и скопировать себе «на чёрный день»).
Вызов выглядит так:
Удалённый ssh-клиент (на 8.8.8.8) может доказать 10.1.1.2, что мы это мы только если мы к этому серверу подключены и дали ssh-клиенту доступ к своему агенту авторизации (но не ключу!).
В большинстве случаев это прокатывает.
Однако, если сервер совсем дурной, то root сервера может использовать сокет для имперсонализации, когда мы подключены.
Есть ещё более могучий метод — он превращает ssh в простой pipe (в смысле, «трубу») через которую насквозь мы осуществляем работу с удалённым сервером.
Главным достоинством этого метода является полная независимость от доверенности промежуточного сервера. Он может использовать поддельный ssh-сервер, логгировать все байты и все действия, перехватывать любые данные и подделывать их как хочет — взаимодействие идёт между «итоговым» сервером и клиентом. Если данные оконечного сервера подделаны, то подпись не сойдётся. Если данные не подделаны, то сессия устанавливается в защищённом режиме, так что перехватывать нечего.
Эту клёвую настройку я не знал, и раскопал её redrampage.
Выглядит это так (циферки для картинки выше):
Повторю важную мысль: сервер 8.8.8.8 не может перехватить или подделать трафик, воспользоваться агентом авторизации пользователя или иным образом изменить трафик. Запретить — да, может. Но если разрешил — пропустит через себя без расшифровки или модификации. Для работы конфигурации нужно иметь свой открытый ключ в authorized_keys как для user@8.8.8.8, так и в user2@10.1.1.2
Разумеется, подключение можно оснащать всеми прочими фенечками — прокидыванием портов, копированием файлов, сокс-прокси, L2-туннелями, туннелированием X-сервера и т.д.