Подключение по ssh 1с
На самом деле, это инструкция скорее для меня самого, чтобы когда потребуется настроить такую штуку в следующий раз, не рвать волосы на голове и не думать в очередной раз: «Надо было все записать, когда в прошлый раз делал»… Но может быть, кому-то еще пригодится… Я абсолютно не претендую на то, что это абсолютно правильное решение и что нужно делать именно так, более того, буду только рад объективной критике… Просто я так сделал и решил это записать…
Итак, в один прекрасный день передо мной была поставлена следующая задача:
необходимо, чтобы пользователи удаленного офиса могли подключаться к 1С в нашем офисе…
Итак, шаг 1: настройка ssh.
Первое, что надо сделать, установить пакет OpenSSH, что делается довольно просто
yum install openssh.
К сожалению, не могу привести логов всего этого, т.к. уже есть де-факто настроенная система, а эту заметку пишу уже постфактум) =)
После установки открываем /etc/ssh/sshd_config и начинаем его редактировать:
В нашем случае авторизация будет происходить с использованием PublicKey и никакие другие виды авторизации мы не приемлем. Основные параметры, которые необходимо указать:
1) Сетевые параметры: IP-адрес и порт, которые будет прослушивать OpenSSH. В моем случае, ssh будет слушать 22й порт на IP-адресе локальной сети и на внешнем IP.
Port 22
ListenAddress 192.168.0.1
ListenAddress xxx.xxx.xxx.xxx
2) Параметры ssh: версия протокола (1 или 2) и HostKeys. Мы будем использовать только протокол версии 2, поэтому указываем следующие настройки:
Protocol 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
3) Параметры Аутентификации(различные параметры вроде времени или количества попыток аутентификации, я рассматривать не буду). Итак, необходимо запретить все виды аутентификации, кроме аутентификации с использованием открытого ключа. А также запрещаем аутентификацию для пользователя root.
PermitRootLogin no
RSAAuthentication no
PubkeyAuthentication yes
AuthorizedKeysFile /home/%u/.ssh/authorized_keys
RhostsRSAAuthentication no
HostbasedAuthentication no
IgnoreUserKnownHosts yes
IgnoreRhosts yes
PermitEmptyPasswords no
PasswordAuthentication no
UsePAM no
4) Параметры туннелирования портов. В данном случае, мы не будем использовать X11 Forwarding, а просто будем использовать ssh в качестве туннеля для порта 5901, соответственно, параметры относящиеся к X11Forwarding можно не трогать, главное — включить туннелирование.
PermitTunnel yes
Остальные параметры я оставил по умолчанию.
Итак, сервер ssh почти настроен, осталось сделать всего пару вещей.
1) Создать пару ключей для нужного пользователя. Это делается с помощью команды ssh-keygen. Можно задавать большое количество различных опций, таких как длина ключа, тип ключа, имя хоста и др, но даже при использовании с опциями по умолчанию, если вам не нужна черезчур высокая безопасность, вы получите вполне безопасный ключ. Я генерировал ключ следующим образом:
ssh-keygen -t rsa
При генерации ключа необходимо будет ввести пароль, который будет использоваться для доступа к нему в дальнейшем. По умолчанию ключи id_rsa и id_rsa.pub будут сохранены в папку
/.shh. Закрытую часть ключа(id_rsa) необходимо переместить на хост, с которого будет осуществляться удаленный доступ.
2) Скопировать ПУБЛИЧНУЮ часть созданного ключа в файл
/.ssh/authorized_keys, например так:
cat id_rsa.pub >> authorized_keys
Все, настройка OpenSSH-сервера закончена, осталось его запустить:
/sbin/service sshd start
А заодно, чтобы в дальнейшем не запускать его вручную после перезагрузок:
chkconfig sshd on
После этого можно протестировать работу нашего сервера. Подключимся из локальной сети, используя Putty.
Сначала с помощью утилиты puttygen необходимо конвертировать наш секретный ключ в формат putty:
1) Запускаем puttygen.
2) Conversions-Import Key и указываем наш секретный ключ
3) После ввода пароля, откроется окно с параметрами ключа, где необходимо выбрать «Save private key» и сохранить версию ключа для putty.
После конвертирования ключа, запускаем putty, для подключения
В настройках необходимо указать:
1) На вкладке Session — IP-адрес сервера, к которому мы подключаемся и порт(в случае использования отличного от порта 22).
2) На вкладке SSH->Auth в поле «Private key file for authentication» указать путь к нашему ключу:
После чего, можно смело нажимать Open. И… вот он, удаленный доступ.
Шаг 2: Следующее, что нам необходимо будет настроить — это сервер vnc.
1) Установка(проще некуда):
yum install vncserver
Настройка, также на удивление проста:
2) Запуск vncpasswd и установка пароля для доступа к вашему терминальному серверу
3) Описание запускаемых серверов vnc в файле /etc/sysconfig/vncservers:
Для настройки терминального сервера необходимо указать пользователей, к рабочим столам которых будет происходить подклюдчение. В данном случае, мы настроили 2 терминальных сервера для доступа к десктопам пользователей user1 и user2. По умолчанию первый будет доступен на порту 5901, второй 5902. В строках VNCSERVERARGS задаем необходимые опции для каждого из серверов. В данном случае:
-geometry — разрешение экрана.
-nohttpd — отключаем запуск https-сервера, который vnc по умолчанию запускает. (В противном случае, можно будет подключиться к рабочсему столу, набрав в браузере server-name:590x)
-localhost — разрешаем подключение только с localhost, то есть удаленно получить доступ к рабочему столу будет нельзя(но т.к. мы будем сначала подключаться к серверу через ssh, то vnc будет воспринимать наше подключение, как локальное.)
VNCSERVERS:«1: user1 2: user2»
VNCSERVERARGS[1]:"-geometry 800x600 -nohttpd -localhost"
VNCSERVERARGS[2]:"-geometry 1280x1024 -nohttpd -localhost"
4) Запуск службы:
/sbin/service vncserver start
Ну и чтобы в дальнейшем запускалась при загрузке:
chkconfig vncserver on
Можем попробовать подключиться к рабочему столу необходимого пользователя.
1) Сначала необходимо настроить в putty туннелирование портов. Для этого необходимо на вкладке SSH->Tunnels указать номер локального порта и назначение, куда будет переадресовываться данный запрос. Указываем адрес 127.0.0.1, так как мы разрешили подключение к vnc только с localhost.
2) После этого можем подключаться, используя vnc-клиент Для Windows существует несколько различных vnc-клиентов. Лично я препочитаю TightVNC, на мой взгляд, оптимальный среди бесплатных vnc-клиентов.
В окне запуска vnc указываем VNC server: 127.0.0.1:x, где x-номер порта, к которому осуществляется подключение.
Vncserver запросит имя пользователя и пароль, который мы задали командой vncpasswd при настройке сервера.
Данная статья является анонсом новой функциональности.
Не рекомендуется использовать содержание данной статьи для освоения новой функциональности.
Полное описание новой функциональности будет приведено в документации к соответствующей версии.
Полный список изменений в новой версии приводится в файле v8Update.htm.
Планируется в релизе 2020.2.2
Как мы уже писали, одно из назначений 1С:Исполнителя – это автоматизация задач администрирования. Чтобы расширить круг решаемых задач, мы добавили в 1С:Исполнитель поддержку протокола SSH.
Протокол SSH широко используется для администрирования серверов и отдельных сервисов. По сути, через этот протокол можно получить доступ к консоли удалённого сервера.
Появится также поддержка протокола SFTP, предназначенного для выполнения операций с файлами (копирования и т.п.) поверх надёжного и безопасного соединения.
В рамках поддержки SSH будет реализован ряд объектов, в частности:
СоединениеSsh: предоставляет интерфейс для взаимодействия по протоколу SSH.
КонсольSsh: предоставляет интерфейс для взаимодействия с удаленной консолью, с помощью которой можно выполнять произвольный набор команд. Объект КонсольSsh возвращается методом СоединениеSsh.ОткрытьКонсоль().
СоединениеSftp: предоставляет интерфейс для взаимодействия с сервером по протоколу SFTP. Объект СоединениеSftp возвращается методом СоединениеSsh.ОткрытьК СоединениеSftp().
Также некоторое время назад в Конфигуратор была добавлена возможность работы в режиме агента (т.е. возможность удалённо выполнять по протоколу SSH различные команды). С появлением поддержки SSH в 1С:Исполнителе появится возможность использовать этот режим Конфигуратора из 1С:Исполнителя.
Пример ниже демонстрирует, как присоединиться к Конфигуратору по протоколу SSH, выгрузить конфигурацию в файл и скачать этот файл через SFTP:
знч КонфигураторПроцесс = новый ПроцессОс(
["designer", "/IBName " + "Информационная база",
"/AgentMode", "/AgentSSHHostKeyAuto", "/AgentBaseDir",
исп СоединениеАгент = новый СоединениеSsh("127.0.0.1", 1543, "admin", "123")
исп Агент = СоединениеАгент.ОткрытьКонсоль()
пер Результат = Агент.Выполнить("common connect-ib").ПрочитатьКакТекст()
Консоль.Записать("Подключение к ИБ: " + Результат)
"config dump-cfg --file=configuration.cf").ПрочитатьКакТекст()
исп СоединениеФайлы = новый СоединениеSsh("127.0.0.1", 1543, "admin", "123")
знч Sftp = СоединениеФайлы.ОткрытьСоединениеSftp()
Помимо работы с Конфигуратором эту функциональность можно использовать и для других административных задач.
Удаленный доступ к серверу или рабочему месту часто требуется различным специалистам: системному администратору, программисту и даже бухгалтеру. Иногда на предприятии штатный системный администратор либо отказывается предоставить удаленный доступ, либо не имеет такой возможности (часто просто местный эникейщик не знает как это сделать). В подобном случае может помочь создание SSH-тунеля.
Данная обработка позволяет создать соединение с удаленным сервером или другим узлом сети напрямую из 1С:Предприятия без использования консоли Linux.
Для реализации подключения нам понадобится SSH сервер с публичным адресом. Схема проста: сервер, куда нам необходимо получить доступ, с помощью внешней обработки соединяется с промежуточным сервером, а системный администратор, используя SSH клиент (для windows подойдет PuTTY), получает доступ порту сервера.
SSH позволяет строить целые цепочки туннелей, соединяя точку входа следующего с точкой выхода предыдущего. Таким образом, чтобы получить туннель с ПК админа на RDP-сервер, при этом оба узла с "серыми" IP-адресами, нам нужно создать два туннеля с промежуточным узлом.
Хост
Адрес/порт: адрес и порт сервера, куда необходим доступ;
Служебный порт: Промежуточный порт доступа, может отличаться от порта сервера
Сокет: например /tmp/session1
Сервер SSH
Адрес/порт: адрес и порт промежуточного SSH сервера
Пользователь: Пользователь промежуточного SSH сервера
Открытый ключ: Открытый ключ RSA для доступа без пароля к SSH серверу
- Подключаем обработку через Дополнительный отчеты и обработки.
- Нажимаем настройки
- Указываем адреса и порты
- Создаем ключ
- Сохраняем параметры
- На промежуточном SSH сервере добавляем ключ и файл доверенных открытых ключей (в случае CentOS это
Теперь по адресу 127.0.0.1:ПортНаРабочемМесте нас перенаправит на Адрес/порт хоста
Особенности работы с Windows:
В Windows (до win10) нет встроенных инструментов для работы с SSH, поэтому используется утилита PuTTY plink (включил в обработку как двоичные данные).
Генерацию ключей придется произвести вручную с помощью утилиты puttygen и вставить в соответствующие поля обработки (закрытый ключ из puttygen сначала сохраняем в файл, затем открываем через блокнот и вставляем содержимое в поле обработки "ключ").
Проверено:
Платформа 1С:Предприятие 8.3 (8.3.14.1630)
Версия БСП: 3.0.1.428
PuTTY Release 0.71
UPDATE 07.08.2019: Появилась возможность отслеживания состояния подключения на сервере Windows. Добавлена возможность использования нескольких хостов/портов
Задача: Автоматизировать процесс пакетного режима работы конфигуратора 1С на сервере Linux (где есть только консоль).
Проблема: Для запуска конфигуратора в Linux необходимо графическое окружение рабочего стола (X-ы).
Запуск скрипта с помощью следующей команды (не забывайте, что используются обратные кавычки):
Где <скрипт> - это пакет команд запуска 1С-конфигуратора.
Работает. Но есть особенность.
С полноценными X-ами не получилось.
Т.к. запускаю 1С на виртуальном хостинге VDS (xen), то в системе отсутствует по-умолчанию устройство /dev/fb0, которое требуется при запуске xinit.
Его можно добавить, если в dom0 добавить в конфиг виртуальный framebuffer.
Но хостер не пошёл на контакт по этому вопросу.
В итоге нашёл вот такое решение (установка виртуального X-сервера Xvfb).
Для запуска 1С в консоли так же потребуется GTK-библиотека, поэтому:
Примечание: работает на jessie. На wheezy есть неразрешимые зависимости.
Важно (долго мучился): при запуске 1С из командной строки в режиме конфигуратора вылетала ошибка Segmentation Fault.
Решение оказалось в установке шрифтов микрософт (не спрашивайте, как до этого дошёл, в интернете нет прямой информации на это):
Ещё вариант ошибки и способ решения.
При запуске из консоли процесс запускается, но не заканчивается (висит). В логах ничего нет.
Для того, чтобы разобраться с проблемой пришлось установить графическое окружение (в частности LXDE).
В итоге увидел, что 1С не запускался. Висело окошко с ошибкой "Не удалось инициализировать компоненту frame".
Считаем "frame" библиотекой frame.so из комплекта 1С.
Проверяем какие библиотеки подгружаются при запуски frame.so:
Среди вывалившегося списка библиотек основные входят в комплект 1С.
Каждый файл можно найти и посмотреть где он лежит с использованием команды:
В моем случае не была найдена библиотека libGL.so.1.
Выяснилось, что ранее были установлены драйвера ATI Radeon, которые не были удалены.
Удалил их и все встало на свои места.
После этого можно использовать команду вида:
Как я это использую
Скрипт настроен на Подключение к хранилищу - Обновление конфигурации из хранилища - Обновление конфигурации базы данных.
Периодически читая статьи, посвящённые SSH, обратил внимание, что их авторы порой не имеют понятия, как работает этот протокол. В большинстве случаев они ограничиваются рассмотрением темы генерации ключей и описанием опций основных команд. Даже опытные системные администраторы часто несут полную ахинею при обсуждении вопросов работы SSH, выдавая опусы в стиле: передаваемые данные шифруются открытым SSH-ключом клиента, а расшифровываются закрытым, или: для шифрования данных при передаче используется алгоритм RSA.
Попытаюсь внести немного ясности в работу протокола SSH, а заодно рассмотреть роль алгоритма RSA и ключей авторизации пользователя…
Алгоритм протокола SSH можно разделить на три уровня, каждый из которых располагается над предыдущим: транспорт (открытие защищённого канала), аутентификация, подключение. Для целостности картины я также добавлю уровень установки сетевого соединения, хотя официально этот уровень находится ниже SSH.
1. Установка TCP-соединения
Не буду подробно останавливаться на принципе работы стека TCP/IP, так как эта тема достаточно хорошо задокументирована в Рунете. При необходимости вы легко найдёте информацию.
На этом этапе происходит сетевое подключение клиента к серверу на TCP-порт, указанный в опции Port (по умолчанию: 22) в файле конфигурации сервера /etc/ssh/sshd_config.
2. Открытие защищенного канала
2.1 Обмен идентификационными данными
После установки TCP-соединения, клиент и сервер (далее по тексту – стороны) обмениваются версиями SSH-протокола и другими вспомогательными данными, необходимыми для выяснения совместимости протоколов и для выбора алгоритмов работы.
2.2 Выбор алгоритмов: обмена ключами, шифрования, сжатия и т.п.
При работе SSH используется довольно много алгоритмов, одни из них используются для шифрования, вторые для обмена ключами, третьи для сжатия передаваемых данных и т.п. На этом шаге стороны отсылают друг другу списки поддерживаемых алгоритмов, наибольший приоритет имеют алгоритмы в начале каждого списка. Затем сравнивают алгоритмы в полученных списках с алгоритмами, имеющимися в системе, и выбирают первый совпавший в каждом списке.
Список доступных алгоритмов обмена ключами на стороне клиента (используются для получения сессионного ключа) можно посмотреть командой:
Список доступных в системе симметричных алгоритмов (используются для шифрования канала):
Список типов ключей для авторизации у клиента:
Дополнено по замечанию onix74:
Все используемые в публикации команды актуальны для версии OpenSSH 7.6 из Ubuntu 18.04 LTS.
2.3 Получение сессионного ключа шифрования
Процесс получения сессионного ключа может отличаться в зависимости от версии алгоритма, но в общих чертах сводится к следующему:
- Сервер отсылает клиенту свой ключ (DSA, RSA или т.п. согласно договорённости между сторонами, произведёнными в п.2.2).
- Если клиент производит соединение с данным сервером впервые (о чем говорит отсутствие записи в файле /home/username/.ssh/known_hosts у клиента), то пользователю будет задан вопрос о доверии ключу сервера. Если же соединение с данным сервером уже устанавливалось ранее, то клиент сравнивает присланный ключ с ключом, записанным в /home/username/.ssh/known_hosts. Если ключи не совпадают, то пользователь получит предупреждение о возможной попытке взлома. Впрочем, эту проверку можно пропустить, если вызвать ssh с опцией StrictHostKeyChecking:
Также, если пользователю нужно удалить старый ключ сервера (например, когда есть точная уверенность, что ключ был изменён на сервере), то используется команда:
3. Аутентификация клиента
И только теперь, когда клиент и сервер установили канал для зашифрованной передачи данных, они могут произвести аутентификацию по паролю или ключам.
В общих чертах, аутентификация посредством ключей происходит следующим образом:
4. Уровень подключения
После проведения всех вышеперечисленных процедур, пользователь получает возможность передавать команды серверу или копировать файлы.
На этом уровне обеспечивается: мультиплицирование каналов (возможность работы множества каналов к одному серверу за счет объединения их в один канал), туннелирование и т.п.
От теории к практике
Ну а теперь, думаю, у читателей назрел вполне закономерный вопрос: а зачем нужно знать все эти тонкости работы SSH-протокола, если для повседневной работы достаточно знаний команд создания ключей (ssh-keygen), открытия терминальной сессии (ssh), передачи файлов (scp)?
В качестве ответа, можно вспомнить тему о смене стандартного порта SSH на какой-то другой, которая постоянно становится причиной холивара на Хабре…
В собственной практике я не припомню ни одного смотрящего во внешнюю сеть сервера, который бы ежедневно не подвергался долбёжке на 22-й порт. В ситуации, если SSH у вас работает на стандартном порту (и ничем дополнительно не защищён), даже если аутентификация исключительно по ключам и никакие подборы паролей не пугают, то по причине постоянно валящихся запросов от недобросовестных клиентов сервер всё равно вынужден совершать массу бесполезной работы: устанавливать TCP-соединение, выбирать алгоритмы, генерировать сессионный ключ, отправлять запросы аутентификации, писать лог-файл.
В ситуации же, когда на 22-м порту ничего нет, или порт защищён с помощью iptables (либо надстройками над ним типа fail2ban), то злоумышленник будет дропнут ещё на этапе установки TCP-соединения.
Читайте также: