Архив метки: Linux

Домашний Сервер: Часть 4 – Настройка Transmission daemon в контейнере LXC Proxmox-VE

Приветствую, уважаемые читатели на четвертой части цикла!

В прошлый раз мы установили и настроили локальные доменные имена на базе сервиса BIND9 в LXC контейнере.
Список цикла статей:

 

  1. Домашний Сервер: Часть 1 – Предисловие, аппаратная и софтовая начинка
  2. Домашний Сервер: Часть 2 – Установка системы виртуализации Proxmox
  3. Домашний Сервер: Часть 3 – Внутренний DNS сервис на BIND9 или свои доменные имена в локальной сети
  4. Домашний Сервер: Часть 4 – Настройка Transmission daemon в контейнере LXC Proxmox-VE (вы тут)
  5. Домашний Сервер: Часть 5 – Установка и настройка Plex Media Server в контейнере LXC Proxmox-VE

Читать

Как туннелировать VNC через SSH

Если вы подключаетесь к удаленному рабочему столу по протоколу VNC, ваше соединение может быть небезопасным. Некоторые клиенты VNC, такие как популярный TightVNC, не шифруют ваше соединение после начальной стадии входа в систему. Чтобы обойти проблему, вы можете туннелировать соединение VNC через туннель Secure Shell (SSH).

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

Настройка PuTTY

В Windows 10 встроен SSH-клиент, благодаря Windows PowerShell, но это только недавняя разработка. Если вы хотите узнать, как туннелировать VNC через SSH, рекомендуется использовать PuTTY для подключения к вашему SSH-серверу.

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

  • Для начала загрузите PuTTY и откройте клиент.
  • Главное меню сеанса позволяет вам ввести IP-адрес вашего сервера или имя хоста. Введите адрес вашего SSH-сервера в текстовом поле Имя хоста (или IP-адрес). Если ваш SSH-порт отличается от стандартного порта 22, введите его в поле «Порт».
  • Вы также захотите сохранить этот сеанс, поэтому в текстовом поле «Сохраненные сеансы» добавьте подходящее имя для вашего SSH-соединения и нажмите кнопку «Сохранить».

  • В левом меню разверните вкладку «Соединение», затем сделайте то же самое для SSH. Нажмите на Туннели.

  • В разделе «Переадресация портов» меню «Туннели» вы предоставите сведения, которые позволят PuTTY туннелировать ваше соединение VNC через SSH. В текстовом поле «Порт источника» введите 5901. В текстовом поле «Адресат» введите свой удаленный IP-адрес: 5901, используя IP-адрес удаленного настольного ПК или сервера. Например, 192.168.1.100:5901 подойдет.

  • Вернитесь в раздел «Сеанс», щелкните имя сохраненного сеанса в разделе «Сохраненные сеансы», затем нажмите «Сохранить», чтобы сохранить настройки.

  • Когда настройки PuTTY будут готовы, установите соединение SSH, нажав кнопку «Открыть» внизу. Вам потребуется ввести имя пользователя и пароль, необходимые для подключения SSH, когда PuTTY попытается это сделать.

  • После завершения входа в систему вам будет предоставлен доступ к окну SSH-терминала для удаленного рабочего стола.

С активным туннелем SSH к серверу удаленного рабочего стола вы сможете установить соединение VNC. Вы можете использовать любой VNC-клиент по вашему выбору, но в этом руководстве будет рассказано, как подключиться с помощью TightVNC, популярного и бесплатного VNC-клиента для Windows и Linux.

Вы можете свернуть PuTTY, пока соединение активно.

Подключение с помощью TightVNC

Если ваше SSH-соединение активно, подключение с использованием TightVNC довольно простое. Это предполагает, что ваш VNC-сервер работает на вашем удаленном ПК или сервере.

  • Откройте TightVNC, чтобы начать. В разделе «Подключение» введите localhost :: 5901 или 127.0.0.1::5901 в текстовое поле «Удаленный хост». PuTTY контролирует этот порт и автоматически отправит это соединение, когда попытка будет предпринята, на ваш удаленный сервер.
  • Вы можете настроить свое подключение VNC дальше, нажав «Опции», но, если вы готовы к подключению, нажмите «Подключиться».

  • Вам будет предложено ввести пароль вашего сервера VNC, поэтому укажите его во всплывающем окне «Аутентификация VNC» и нажмите кнопку «ОК».

Если ваше SSH-соединение работает правильно, TightVNC должен загрузить окно удаленного рабочего стола VNC, готовое для использования.

Клиенты SSH с поддержкой туннелирования

Хотя TightVNC является популярным клиентом Windows для VNC-соединений, он не поддерживает SSH-туннелирование внутри самого клиента, что требует использования PuTTY для установления соединения.

Однако другие VNC-клиенты включают SSH-туннелирование внутри самого клиента. Одним из примеров является SSVNC, который, хотя и базовый, будет туннелировать по SSH перед установлением VNC-соединения. SSVNC поддерживается операционными системами Windows и Linux.

  • Откройте клиент SSVNC и в главном окне клиента SSVNC заполните необходимые поля. В разделе VNC Host: Display введите SSHusername@remoteIPaddress:1. Замените SSHusername на имя пользователя, которое вы будете использовать для вашего SSH-соединения, и замените адрес удаленного IP-адреса на IP-адрес удаленного рабочего стола. Например, root@192.168.1.100:1.
  • Убедитесь, что вы выбрали опцию Использовать SSH или SSL + SSL перед подключением. Когда вы будете готовы, нажмите кнопку Подключиться.

  • Вас попросят ввести пароль SSH во всплывающем окне терминала. Введите пароль, затем нажмите клавишу ввода на клавиатуре.

Как только SSH-туннель будет активен, ваше VNC-соединение будет запущено, и должно появиться окно вашего VNC-клиента, где вы можете начать использовать удаленный рабочий стол.

Хотя соединения VNC по умолчанию не шифруются, собственный протокол удаленного рабочего стола Microsoft зашифрован. Если вы используете Windows и планируете подключиться к удаленному ПК или серверу Windows, вы можете подключиться с помощью инструмента «Подключение к удаленному рабочему столу».



2019-11-19T14:17:08
Вопросы читателей

🐧 Ошибка Sudo позволяет пользователям Linux запускать команды с правами суперпользователя

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

Эксплойт больше не актуален в последней версии Sudo.

Недостаток затрагивает все версии Sudo до последней выпущенной версии 1.8.28.

Один такой недостаток был обнаружен в функции Sudo, которая широко используется для запуска программ, скриптов и выполнения команд с правами root.

Недостаток позволяет любому скрипту быть выполненным с привилегиями суперпользователя от пользователя, не имеющего root-доступ.

Команда Sudo (superuser do) – это широко используемая команда в операционной системе Linux.

Sudo отвечает за обработку прав суперпользователя.

Недостаток затрагивает все версии Sudo до последней выпущенной версии 1.8.28.

Уязвимость отслеживается как CVE-2019-14287 и обнаружена Джо Венниксом из Apple Information Security.

На удивление, уязвимость может быть использована злоумышленником для запуска команд от имени пользователя root, просто указав идентификатор пользователя «-1» или «4294967295.»

Давайте разберемся с дизайном недостатка и с чем именно связана эта уязвимость.

Функция, которая преобразует UID (идентификатор пользователя) в свое имя пользователя, неправильно обрабатывает -1, или его неподписанный эквивалент 4294967295, как 0, всегда является идентификатором пользователя root.

С облегчением можно сказать, что атака работает только по конкретным сценариям.

Но всем пользователям Linux по-прежнему рекомендуется обновиться до последней версии Sudo как можно скорее.

Потому что, в конце концов, меры предосторожности всегда лучше лечения.

Теперь для примера сценария атаки.

Если в файле конфигурации политики безопасности /etc/sudoers указано:

myhost bob = (ALL, !root) /usr/bin/vi

Т.е. пользователь bob может запускать программы vi от любого пользователя, кроме root.

sudo -u#-1 id -u OR sudo -u#4294967295 id -u

Команды выполнит vi с привилегиями root.

 



2019-11-13T12:05:40
Закрытие уязвимостей

Как восстановить GRUB из терминала в Linux

Многие пользователи дистрибутивов Linux устанавливают на жёстком диске своего компьютера две и более систем, одну как рабочую, а другую/другие для тестирования или просто ради любопытства. И здесь возникает не существенная, но всё-таки проблема с загрузчиком GRUB, так как установка новой (другой системы) автоматически изменяет меню загрузки систем, т. е. наша вновь установленная система оказывается первой в списке. Для восстановления загрузчика GRUB своей предпочтительной системы пользователь, применяет такие графические инструменты как: Boot-Repair или Grub Customizer, которые прекрасно с этим справляются. Читать

Настраиваем SSH на Ubuntu

Для работы ssh-сервера , а также ssh-клиента будем использовать всем известный пакет OpenSSH




Установка SSH




Установим OpenSSH командой:




sudo apt install ssh




Настройка сервера




При установке SSH-сервер автоматически прописывается в автозагрузку. Управлять его запуском, остановкой или перезапуском можно с помощью команд:




sudo service ssh stop|start|restart




Основной файл конфигурации SSH-сервера — файл /etc/ssh/sshd_config, доступный для чтения или редактирования только суперпользователю. После каждого изменения этого файла ssh-сервер необходимо перезапускать для применения изменений.




Пример конфигурации SSH-сервера в Ubuntu 18.04:




 # Какие порты, IP-адреса и протоколы мы слушаем
Port 22

# “any” - любые #
# “inet” (только IPv4) #
# “inet6” (только IPv6) #
AddressFamily inet

# По каким интерфейсам/сетям разрешен доступ, если
# не указывать, то слушает по всем адресам.
#ListenAddress ::
#ListenAddress 0.0.0.0

# Протокол на котором будет работать SSH (рекомендуется второй)
Protocol 2

# Указывает файл, содержащий закрытый хост-ключ для протокола версии 2
HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
#HostKey /etc/ssh/ssh_host_ecdsa_key
#HostKey /etc/ssh/ssh_host_ed25519_key

#Разделение  привилегий включена для безопасности
UsePrivilegeSeparation yes

# Продолжительность жизни и размер бит ключа для протокола версии 1
#KeyRegenerationInterval 3600
#ServerKeyBits 1024

# Логирование
# DAEMON #
# USER #
# AUTH #
# LOCAL0 #
# LOCAL1 #
# LOCAL2 #
# LOCAL3 #
# LOCAL4 #
# LOCAL5 #
# LOCAL6 #
# LOCAL7 #
SyslogFacility AUTH
# SILENT #
# QUIET #
# FATAL #
# ERROR #
# INFO #
# VERBOSE #
# DEBUG #
# DEBUG1 #
# DEBUG2 #
# DEBUG3 #
LogLevel INFO

# Аутентификация:
 LoginGraceTime 45

# Разрешить или нет доступ root пользователю.
# “yes” - суперпользователь может зайти.
# Применяется текущая глобальная схема аутентификации.
# “without-password” - суперпользователь может зайти.
# Парольная аутентификация для него будет отключена.
# “forced-commands-only” - суперпользователь сможет зайти,
# пользуясь аутентификацией на основе публичного ключа и
# только если передаст необходимую к исполнению команду.
# Все остальные методы аутентификации для суперпользователя будут заблокированы.
# “no” - суперпользователь не может использовать ssh для входа в систему.
PermitRootLogin no
StrictModes yes

# Указывает, разрешена ли "чистая" RSA-аутентификация.
# Актуально только для протокола версии 1.
RSAAuthentication yes

# Использовать аутентификацию по публичному ключу
PubkeyAuthentication yes

# Указывает файл, в котором содержатся публичные ключи, используемые 
# для аутентификации пользователей.
#AuthorizedKeysFile     %h/.ssh/authorized_keys

# Запрещает использование файлов .rhosts и .shosts #
# в процессе аутентификации, основанной на проверке хоста.
IgnoreRhosts yes
# Для этой работы вам также потребуется ключи хоста в /etc/ssh_known_hosts
RhostsRSAAuthentication no
# аналогично для версии протокола 2
HostbasedAuthentication no
# Указывает должен ли sshd игнорировать пользовательские
# "известные хосты" ~/.ssh/known_hosts для RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# Включает аутентификацию по пустому паролю (НЕ РЕКОМЕНДУЕТСЯ)
PermitEmptyPasswords no

# Указывает, разрешить ли аутентификацию вида вопрос-ответ
ChallengeResponseAuthentication no

# Указывает, разрешена ли аутентификация по паролю
PasswordAuthentication no

# Kerberos опции
# Указывает, требует ли пароль, предоставленный #
# пользователем для аутентификации
#KerberosAuthentication no
# Если активен AFS и пользователь получил Kerberos 5 TGT,
# пытаться ли получить AFS токен до того, как пользователь
# получит доступ к своей домашней папке.
# По умолчанию - “no”.
#KerberosGetAFSToken no
# Указывает, как поступать в случае, если аутентификация
# через Kerberos завершилась неудачей. Если
# значение = "yes" - пароль будет проверен при помощи
# любого дополнительного локального механизма авторизации,
# например - /etc/passwd.
# По умолчанию - “yes”.
#KerberosOrLocalPasswd yes
# Указывает, нужно ли автоматически уничтожать файл с
# кэшем тикета пользователя по завершению сеанса.
# По умолчанию - “yes”.
#KerberosTicketCleanup yes

# GSSAPI опции
# Указывает, разрешена ли аутентификация пользователя на
# основе GSSAPI. По умолчанию - "no"
#GSSAPIAuthentication no
# Указывает, нужно ли автоматически уничтожать
# пользовательский кэш аутентификационных полномочий при
# завершении сеанса.
# По умолчанию - "yes"
#GSSAPICleanupCredentials yes

# Указывает, разрешено ли перенаправление графической
# подсистемы X11.
#X11Forwarding yes
# Указывает номер первого дисплея, доступного sshd в
# качестве перенаправления X11.
#X11DisplayOffset 10

# Указывает, должен ли sshd выводить на экран информацию /etc/motd
# при интерактивном входе пользователя.
PrintMotd no
# Указывает, должен ли sshd выводить на экран дату и время
# последнего сеанса при интерактивном входе пользователя.
# По умолчанию - “yes”.
PrintLastLog yes

# Указывает, нужно системе посылать TCP сообщения клиенту с целью 
# поддержания соединения.
TCPKeepAlive yes

# Задает количество сообщений к клиентам, которые sshd
# посылает подряд, не получая какого либо ответа от
# клиента. Если пороговое значение будет достигнуто, а
# клиент так и не ответил - sshd отключит клиента, прервав
# ssh сессию.
#ClientAliveCountMax

# Задает временной интервал в секундах. Если в течении
# этого интервала не было обмена данными с клиентом, sshd
# посылает сообщение по зашифрованному каналу,
# запрашивающее ответ от клиента. По умолчанию - 0, т.е.
# не посылать таких сообщений. Эта директива работает
# только для протокола ssh2.
#ClientAliveInterval

# Указывает, должен ли использоваться login для
# интерактивного сеанса. Значение по умолчанию - “no”.
#UseLogin no

# Указывает максимальное число одновременных
# неавторизованных подключений к sshd.
# Дополнительно, можно задать ранний сброс соединений,
# указав в качестве параметра три значения, разделенные
# двоеточием “start:rate:full” (например: "3:30:30").
# sshd отклонит попытку соединения с вероятностью равной
# “rate/100” (т.е. в нашем примере - 30%), если уже
# имеется “start” (3) неавторизованных соединений.
# Вероятность увеличивается линейно и любые попытки
# соединения будут отклонены, если число неавторизованных
# соединений достигнет значения “full” (30). #
MaxStartups 3:30:30

# Указывает какой файл содержит текстовый баннер, который
# будет показан пользователю ПЕРЕД процедурой
# аутентификации. Опция доступна только для протокола ssh2.
Banner /etc/issue.net

# Разрешить клиенту передавать региональные переменные окружения
AcceptEnv LANG LC_*

# Определяет и настраивает внешнюю подсистему (например
# демона передачи файлов - file transfer daemon).
Subsystem sftp /usr/lib/openssh/sftp-server

# Включает интерфейс PAM (Pluggable Authentication Module
# interface).Если задано значение "yes" - для всех типов
# аутентификации помимо обработки модуля сессии и аккаунта
# PAM будет использоваться аутентификация на основе
# запроса-ответа (ChallengeResponseAuthentication и
# PasswordAuthentication) Т.к. аутентификация
# запросов-ответов в PAM обычно выполняет ту же роль,
# что и парольная аутентификация, вам следует отключить
# либо PasswordAuthentication, либо
# ChallengeResponseAuthentication. Стоит отметить, что
# если директива UsePAM включена - вы не сможете запустить
# sshd от имени пользователя, отличного от root.
# Значение по умолчанию - “no”.
UsePAM yes




Можно скопировать приведенный выше текст в ваш собственный sshd_config и использовать в дальнейшем.




Рекомендуемые параметры. Безопасность




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




Port, ListenAddress и AddressFamily




На нашем ресурсе есть статья про правильную настройку ssh сервера.



[endtxt]



2019-10-24T12:05:15
SSH

Сборка собственного дистрибутива GNU/Linux. Шаг 1 – подготовка.

Решил я собрать собственный LFS. Причин тут несколько:

  • Давно хотелось и чесалось.
  • Присутствует желание лучше понять устройство операционной системы.
  • Нужно мигрировать с 32-битной архитектуры на 64. Инструкцию для Debian нашел, но лучше бы иметь запасную систему на всякий случай.
  • У меня достаточно устойчивый набор программного обеспечения, поэтому есть представление о том, что именно мне нужно.

Следовать по возможности буду этим инструкциям, однако не повторяя их полностью. Иначе смысл сборки дистрибутива для себя полностью теряется. Насчет скорости процесса так же вопросы, ибо я ленив. Но думаю за месяц справлюсь.

Выделение раздела для системы

Я сделал достаточно просто – отмонтировал /home и отрезал от него 10 Гб места под root’ом программой GParted. Это достаточно простая и полезная программа:

Как вариант, можно загрузиться с live-cd той же Ubuntu и проделать те же манипуляции.

Подготовка к началу

Добавление глобальных переменных для пользователя

Предположим, что у нас в системе есть пользователь user. В файл /home/user/.bashrc занесём следующие строки:

  1. Точка монтирования устройства с собираемой ОС:

    export LFS64="/mnt/x64lfs"
  2. Аббревиатура системы, на которой происходит сборка:

    export LFS64_HOST="i586-cross-linux-gnu"
  3. Аббревиатура системы, для которой происходит сборка:

    export LFS64_TARGET="x86_64-unknown-linux-gnu"
  4. Флаги компилятора, для целевой системы:

    export BUILD64="-m64 -march=native"
  5. Включаем путь к приложения из в будующем созданной папки для пользователя:

    PATH=/cross-tools/bin:$PATH

Теперь можно выйти из терминала и зайти в него снова, чтобы данные глобальные переменные обновились.

Монтирование раздела и создание папок

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

#mkdir $LFS64 #mount /dev/XXX $LFS64

Где /dev/XXX – собственно раздел.

Затем необходимо создать несколько папок и сделать символические ссылки на корень системы:

  1. Для временной системы, на базе которой будет происходить сборка основной:

    # mkdir $LFS64/tools # ln -sv $LFS64/tools /
  2. Для кросскомпилятора с x32 на x64:

    # mkdir -v $LFS64/cross-tools # ln -sv $LFS64/cross-tools /
  3. Для исходных текстов программ:

    # mkdir -v $LFS64/sources # ln -sv $LFS64/sources /

Осталось дать пользователю user права на чтение и запись в этих папках:

# chown -v user $LFS64/tools # chown -v user $LFS64/cross-tools # chown -v user $LFS64/sources

На это приготовления заканчиваются, следующий шаг – сборка кросскомпилятора.



2019-10-13T19:27:10
Без рубрики