Astra linux уровень целостности ssh

Установка пакетов

Пакеты SSH (сервер — пакет openssh-server и клиент — пакет openssh-client) входит в дистрибутивы Astra Linux. При установке ОС по умолчанию устанавливается только клиент (openssh-client).

Установку сервера можно выполнить:

• при установке ОС, отметив соответствующий пункт в диалоге выбора программного обеспечения. При этом будет установлен пакет openssh-server;
• после установки ОС с помощью графического менеджера пакетов (см. Графический менеджер пакетов synaptic) или из командной строки:

Установленная с помощью графического менеджера пакетов или из командной строки служба запускается автоматически, а также сразу включается перезапуск службы после перезагрузки ОС.

Служба, установленная при установке ОС:

• в Astra Linux Common Edition начиная с обновления 2.12.12 и в Astra Linux Special Edition x.7 сервер SSH запускается после перезагрузки автоматически;
• в более ранних обновлениях автоматический запуск сервера SSH по умолчанию отключен. Автоматический запуск нужно разрешить отдельно командой:

Проверить состояние службы:

Конфигурация службы хранится в файле /etc/ssh/sshd_config. Чтобы изменения конфигурации вступили в силу требуется перезапуск службы:

Если значения параметров конфигурации содержат пробелы, то эти значения должны быть заключены в кавычки, например:

AllowGroups "group name@domain.name"

Описание синтаксиса конфигурации доступно в справочной системе man:

Простейшие меры безопасности

Из соображений повышения безопасности рекомендуется изменить некоторые значения по умолчанию:

• Port — номер порта, который слушает сервис (22) — изменить значение на любое другое и в дальнейшем использовать этот номер порта;
• MaxAuthTries — количество попыток подключения (6) — уменьшить, например, до 3;
• LoginGraceTime — время, дающееся для подключения (2m) — уменьшить, например до 30s.

Дополнительно, можно ограничить IP-адреса, с которых возможно подключение, например:

в файле /etc/hosts.deny запретить все подключения:

# /etc/hosts.deny: list of hosts that are _not_ allowed to access the system. # See the manual pages hosts_access(5) and hosts_options(5).
#
# Example: ALL: some.host.name, .some.domain
# ALL EXCEPT in.fingerd: other.host.name, .other.domain
#
# If you’re going to protect the portmapper use the name «rpcbind» for the
# daemon name. See rpcbind(8) and rpc.mountd(8) for further information.
#
# The PARANOID wildcard matches any host whose name does not match its
# address.
#
# You may wish to enable this to ensure any programs that don’t
# validate looked up hostnames still leave understandable logs. In past
# versions of Debian this has been the default.
# ALL: PARANOID SSHD: ALL

# /etc/hosts.allow: list of hosts that are allowed to access the system.
# See the manual pages hosts_access(5) and hosts_options(5).
#
# Example: ALL: LOCAL @some_netgroup
# ALL: .foobar.edu EXCEPT terminalserver.foobar.edu
#
# If you’re going to protect the portmapper use the name «rpcbind» for the
# daemon name. See rpcbind(8) and rpc.mountd(8) for further information.
# SSHD: 192.168.1.1
SSHD: 192.168.0.0/16

Аутентификация по ключам

Настройка клиента

Конфигурация клиента хранится в файле /etc/ssh/ssh_config. Клиент работоспособен сразу после установки ОС с настройками «по-умолчанию».

Настройка выбора алгоритмов защитного преобразования.

Проверить список поддерживаемых алгоритмов защитного преобразования (параметр cipher) и выработки имитовставки (параметр mac) можно командами:

В поставляемый в составе дистрибутивов Astra Linux пакет ssh встроены следующие алгоритмы защитного преобразования:

3des-cbc
blowfish-cbc
cast128-cbc
arcfour
arcfour128
arcfour256
aes128-cbc
aes192-cbc
aes256-cbc
rijndael-cbc@lysator.liu.se
aes128-ctr
aes192-ctr
aes256-ctr
grasshopper-cbc (ГОСТ Р 34.13–2015 «Кузнечик»)
grasshopper-ctr (ГОСТ Р 34.13–2015 «Кузнечик»)
aes128-gcm@openssh.com
aes256-gcm@openssh.com
chacha20-poly1305@openssh.com

В поставляемый в составе дистрибутивов Astra Linux пакет ssh встроены следующие алгоритмы выработки имитовставки:

hmac-sha1
hmac-sha1-96
hmac-sha2-256
hmac-sha2-512
hmac-md5
hmac-md5-96
hmac-ripemd160
hmac-ripemd160@openssh.com
umac-64@openssh.com
umac-128@openssh.com
hmac-sha1-etm@openssh.com
hmac-sha1-96-etm@openssh.com
hmac-sha2-256-etm@openssh.com
hmac-sha2-512-etm@openssh.com
hmac-md5-etm@openssh.com
hmac-md5-96-etm@openssh.com
hmac-ripemd160-etm@openssh.com
umac-64-etm@openssh.com
umac-128-etm@openssh.com
hmac-gost2012-256-etm (ГОСТ Р 34.11-2012)

При этом в список алгоритмов защитного преобразования (параметр конфигурации Ciphers) и выработки имитовставок (параметр конфигурации MACs), допустимых к использованию, по умолчанию включены следующие алгоритмы (перечислены в порядке убывания приоритетов применения):

# Ciphers grasshopper-ctr,aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc
# MACs hmac-gost2012-256-etm,hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160

Выше приведены строчки из конфигурационного файла клиента /etc/ssh/ssh_config, аналогичные строчки имеются в конфигурационном файле сервера /etc/ssh/sshd_config.
Если возникает необходимость изменить набор допустимых алгоритмов, или изменить их приоритеты, следует раскомментировать эту строчку, и указать нужные алгоритмы в нужном порядка приоритета.

Например, для приоритетного выбора более простых, а значит, более быстрых алгоритмов можно использовать в файле /etc/ssh/ssh_config следующую конфигурацию:

Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,grasshopper-ctr
MACs hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-ripemd160,hmac-gost2012-256-etm

Монтирование удаленной файловой системы по ssh

SSHFS (Secure Shell FileSystem) — программа, позволяющая монтировать удаленную файловую систему и взаимодействовать с удаленными файловыми ресурсами как с обычными файлами.

Для монтирования SSHFS использует SSH File Transfer Protocol (SFTP) — безопасный протокол передачи данных, обеспечивающий полный доступ к файловым ресурсам через протокол Secure Shell.

От сервера, предоставляющего удалённый ресурс для монтирования, требуется только работающий сервис SSH.

При стандартной установке Astra Linux пакет sshfs устанавливается автоматически, при необходимости может быть установлен с помощью графического менеджера пакетов или из командной строки:

Для выполнения монтирования без запроса пароля должна быть настроена авторизация по ключам (см. выше).

• -o — ключ, указывающий, что далее следуют параметры подключения/монтирования;
• allow_other — разрешить доступ к примонтированному ресурсу непривилегированным пользователям (необязательный параметр);
• IdentityFile=~local_user/.ssh/id_rsa — файл с ключом доступа (необязательный параметр, если его нет — будет запрошен пароль);
• remote_user@server:/home/remote_user — указание на ресурс, который будем монтировать;
  (в данном случае на сервере server от имени пользователя remote_user монтируем домашний каталог этого пользователя /home/remote_user)
• /mnt — локальная точка монтирования

Автоматическое монтирование может быть задано в файле /etc/fstab:

sshfs#remote_user@server:/home/remote_user/ /mnt fuse defaults,allow_other,IdentityFile=~local_user/.ssh/id_rsa 0 0

Для выполнения автоматического монтирования без запроса пароля должна быть настроена авторизация по ключам (см. выше).

Демонтировать ресурс можно обычной командой umount с указанием точки монтирования:

Использование алгоритмов защитного преобразования данных ГОСТ

Сервер и клиент ssh, входящие в состав дистрибутивов Astra Linux, имеют встроенную поддержку работы с алгоритмами защитного преобразования ГОСТ,
причем, если такие алгоритмы поддерживаются и клиентом и сервером, то они используются по умолчанию.
Некоторые подробности про эти алгоритмы можно прочитать в описании библиотеки libgost-astra.

Проверка используемого алгоритма защитного преобразования

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

На стороне сервера:
в файле конфигурации сервера /etc/ssh/sshd_config раскомментировать строчки SyslogFacility и LogLevel, заменить уровень отладки INFO на DEBUG

После внесения изменений перезапустить сервер:

Отладочная информация сервера ssh выводится в файл /var/log/auth.log, и отслеживать сообщения о методах защитного преобразования, используемых при подключении клиентов, можно командой:

На стороне клиента:
При выполнении подключения использовать опцию -v для вывода отладочной информации:

И в первом, и во втором случае используемый для подключения метод защитного преобразования будет отображен в виде строчек такого вида:

debug1: kex: server->client cipher: grasshopper-ctr MAC: hmac-gost2012-256-etm compression: none
debug1: kex: client->server cipher: grasshopper-ctr MAC: hmac-gost2012-256-etm compression: none

Источник

Смоленск 1.6 Изменение переменной PATH при логине через SSH

Предположим в сети имеется сервер Астра Линукс 1.6 Смоленск с включенным ssh сервером. Заметил, что переменная PATH имеет разные значения у пользователя root и, скажем, user, при выполнении следующих команд:

[user@ws ~]$ ssh root@astra "echo \$PATH" /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin [user@ws ~]$ ssh user@astra "echo \$PATH" /usr/local/bin:/usr/bin:/bin:/usr/games

Для меня является фатальным тот факт, что у пользователя «user» в такой конфигурации нет «/usr/sbin» в переменной PATH — туда устанавливается нужный для работы софт. Пытался разобраться как переопределить, как дополнить переменную PATH для данного случая. Нашел похожие строки в /etc/login.defs и /etc/profile, но они не влияют на ситуацию.

P.S. Обратите внимание, интересует именно такой способ выполнения команд. Как сделать переменную PATH корректной для стандартного ввода (когда сначала залогинились, а потом что-то делаем), я знаю.

oko

New member

Tempest

New member

to oko
Для классического линукс дистрибутива (для меня это RHEL/CentOS) — да. Но не для Астры 1.6. Здесь это не работает. Поэтому и обратился за советом

oko

New member

to Tempest
На ALSE 1.6 без графики проверил — прекрасно работает способ с .bashrc (в примере ниже .bashrc очищен до минимума и cp используется для удобства размещения всего на 1 изображении).

Tempest

New member

ssh user1@localhost "echo \$PATH"

Вы тут же получите вывод значения переменной PATH и ssh сеанс завершится

ssh user1@localhost echo $PATH

oko

New member

• создал user2 с 0:0 мандатными уровнями и 0:0 мандатными категориями;
• очистил его .bashrc для наглядности;
• создал новый bashrc_new с экспортом нужной PATH;
• создал /usr/sbin/myscript.sh, дал ему права на исполнение;
• проверил без PATH — myscript по быстрому имени не отрабатывает;
• внес изменения в .bashrc и перезашел в шелл — myscript по быстрому имени отрабатывает.

Либо вы что-то не так делаете, либо я не могу понять вашу задачу и проблему.
Либо проблема в используемых средствах: нативное подключение Astra-Astra через терминал и ssh-client (ваш случай) резко отличается от подключения Win-Astra с использованием Putty (мой случай) именно в части $PATH.

oko

New member

to Tempest
Проверил связку Astra-Astra. Подключался к приведенному выше серверу с модифицированной PATH для user2. При этом на АРМ user1 имел 0:0 мандатку и 63 уровень целостности.

Любопытно различие в выводе $PATH для двух случаев подключения в части /usr/local/games. И, собственно, эта часть $PATH реально не экспортируется.
В такой ситуации возможно явно задать весь перечень нужных $PATH в /home/имя_пользователя/.bashrc — тогда они будут отрабатывать и при ssh имя_пользователя@адрес_сервера «echo \$PATH» и вообще (пусть и с дубляжом, связанным с дефолтными значениями оболочки, заданными в /etc/skel и /etc/login.defs).

Tempest

New member

Спасибо за развернутый ответ. Вижу что у Вас получилось то, что мне нужно с user2 и ssh. Возможно дело в том, что я неправильно создавал своего пользователя.

Если не сложно, можете кинуть в меня ссылкой как из терминала (без графики) создать «user2 с 0:0 мандатными уровнями и 0:0 мандатными категориями;»? Буду очень признателен.

oko

New member

to Tempest
Из-под пользователя-администратора (который в astra-admins группе или который создавался при старте системы) заходите с 63 уровнем целостности (если через ssh — пускает сразу в нужном контексте). Далее adduser user2 — создание пользователя. usermac user2 -l 0:0 — установка ему мин/макс уровней мандатки (собственно, 0). Остальные опции по adduser —help и usermac —help.
63 уровень целостности выставлял пользователю user1 на АРМ через графическую утилиту на клиенте. На сервере для user2 вообще не трогал целостность пользователя (по умолчанию, 0 — Низкий).
Кстати, не забывайте, что при входе по ssh вы всегда попадаете под пользователя с 0 мандатным уровнем, вне зависимости от доступных ему уровней.

Источник