Перейти до змісту

Захищений сервер - SFTP із процедурами блокування SSH

Вступ

Якщо сам протокол SSH безпечний, може здатися дивним мати документ, присвячений «безпечному» використанню SFTP (частина пакету openssh-server). Але більшість системних адміністраторів не хочуть відкривати SSH для всіх, щоб запровадити SFTP для всіх. У цьому документі описано реалізацію джейл-системи change root (chroot) для SFTP з обмеженням доступу SSH.

Багато документів стосуються створення SFTP chroot jail, але більшість не розглядають випадки використання, коли користувач може отримати доступ до веб-каталогу на сервері з багатьма веб-сайтами. Цей документ присвячений цьому. Якщо це не ваш випадок використання, ви можете швидко адаптувати ці концепції до різних ситуацій.

Автор також вважає, що під час створення документа chroot jail для SFTP необхідно обговорити інші речі, які ви повинні робити як системний адміністратор, щоб мінімізувати ціль, яку ви пропонуєте світу через SSH. З цієї причини цей документ розділений на чотири частини:

  1. Перший стосується загальної інформації, яку ми будемо використовувати для всього документа.
  2. Другий стосується налаштування chroot. Якщо ви зупинитесь на цьому, це повністю залежить від вас.
  3. Третя частина стосується налаштування доступу SSH з відкритим/приватним ключем для ваших системних адміністраторів і вимкнення віддаленої автентифікації на основі пароля.
  4. Четвертий і останній розділ цього документу стосується вимкнення віддаленого кореневого входу.

Усі ці кроки дозволять вам запропонувати безпечний доступ SFTP для ваших клієнтів, мінімізуючи ймовірність того, що зловмисник скомпрометує порт 22 (той, який зарезервовано для доступу SSH).

chroot jails для початківців:

chroot jails — це спосіб обмежити дії процесу та його різноманітних дочірніх процесів на вашому комп’ютері. Це дозволяє вам вибрати певний каталог/папку на вашому комп’ютері та зробити його «кореневим» каталогом для будь-якого процесу чи програми.

З цього моменту цей процес або програма може *тільки* отримати доступ до цієї папки та її вкладених папок.

Оновлення для Rocky Linux 8.х та 9.х

Цей документ оновлено, щоб включити нові зміни з версією 8.6, які зроблять цю процедуру ще безпечнішою. Якщо ви використовуєте 8.6 або новішу або будь-яку версію 9.x, ця процедура має працювати для вас. Розділи, що стосуються Rocky Linux 8.5, видалено, оскільки поточний випуск 8 (8.8 на момент перезапису) має бути там, де буде будь-яка версія 8.x після оновлення пакетів.

Частина 1: Загальна інформація

Припущення та умовності

Припущення полягають у тому, що:

  • вам зручно виконувати команди в командному рядку.
  • ви можете використовувати редактор командного рядка, наприклад vi (використовується тут), nano, micro тощо.
  • ви розумієте основні команди Linux для додавання груп і користувачів або можете добре слідувати.
  • ваш багатосайтовий веб-сайт налаштовано так: Apache Multisite
  • httpd (Apache) уже встановлено на сервері.

Note

Ви можете застосувати ці концепції до будь-якої установки сервера та будь-якого веб-демона. Хоча ми тут припускаємо Apache, ви також можете використовувати це для Nginx.

Сайти, користувачі, адміністратори

Це вигадані сценарії. Будь-яка схожість із реальними особами чи сайтами є абсолютно випадковою:

Сайти:

  • mybrokenaxel = (site1.com) user = mybroken
  • myfixedaxel = (site2.com) user = myfixed

Адміністратори:

  • Steve Simpson = ssimpson
  • Laura Blakely = lblakely

Частина 2: SFTP chroot jail

Встановлення

Установка проста. Вам просто потрібно встановити openssh-server, який, ймовірно, вже встановлений. Щоб переконатися, введіть цю команду:

dnf install openssh-server

Налаштування

Директорії

Структура шляху до каталогу буде /var/www/sub-domains/[ext.domainname]/html, а каталог html у цьому шляху буде chroot jail для користувача SFTP.

Створення каталогів конфігурації:

mkdir -p /etc/httpd/sites-available
mkdir -p /etc/httpd/sites-enabled

Створення веб-каталогів:

mkdir -p /var/www/sub-domains/com.site1/html
mkdir -p /var/www/sub-domains/com.site2/html

Пізніше ви розберетеся з правом власності на ці каталоги в програмі сценарію.

Конфігурація httpd

Вам потрібно змінити вбудований файл httpd.conf, щоб він завантажував файли конфігурації з каталогу /etc/httpd/sites-enabled. Зробіть це, додавши один рядок внизу файлу httpd.conf.

Відредагуйте файл за допомогою улюбленого редактора. Автор використовує тут vi:

vi /etc/httpd/conf/httpd.conf

і додайте це внизу файлу:

Include /etc/httpd/sites-enabled

Збережіть файл і вийдіть.

Конфігурація сайту

You need two sites created. Ви створите конфігурації у /etc/httpd/sites-available та зв'яжете їх з ../sites-enabled:

vi /etc/httpd/sites-available/com.site1

Note

У прикладі використовується лише протокол HTTP. Будь-якому реальному веб-сайту потрібна конфігурація протоколу HTTPS, сертифікати SSL і, можливо, багато іншого.

<VirtualHost *:80>
        ServerName www.site1.com
        ServerAdmin username@rockylinux.org
        DocumentRoot /var/www/sub-domains/com.site1/html
        DirectoryIndex index.php index.htm index.html
        Alias /icons/ /var/www/icons/


    CustomLog "/var/log/httpd/com.site1.www-access_log" combined
    ErrorLog  "/var/log/httpd/com.site1.www-error_log"

        <Directory /var/www/sub-domains/com.site1/html>
                Options -ExecCGI -Indexes
                AllowOverride None

                Order deny,allow
                Deny from all
                Allow from all

                Satisfy all
        </Directory>
</VirtualHost>

Збережіть цей файл і вийдіть.

vi /etc/httpd/sites-available/com.site2

<VirtualHost *:80>
        ServerName www.site2.com
        ServerAdmin username@rockylinux.org
        DocumentRoot /var/www/sub-domains/com.site2/html
        DirectoryIndex index.php index.htm index.html
        Alias /icons/ /var/www/icons/


    CustomLog "/var/log/httpd/com.site2.www-access_log" combined
    ErrorLog  "/var/log/httpd/com.site2.www-error_log"

        <Directory /var/www/sub-domains/com.site2/html>
                Options -ExecCGI -Indexes
                AllowOverride None

                Order deny,allow
                Deny from all
                Allow from all

                Satisfy all
        </Directory>
</VirtualHost>

Збережіть цей файл і вийдіть.

Завершивши створення двох конфігураційних файлів, зв’яжіть їх із /etc/httpd/sites-enabled:

ln -s ../sites-available/com.site1
ln -s ../sites-available/com.site2

Увімкніть і запустіть процес httpd:

systemctl enable --now httpd

Створення користувача

Для нашого прикладу середовища припущення полягає в тому, що жоден із користувачів ще не існує. Почніть із своїх адміністраторів. Зауважте, що на цьому етапі процесу ви все ще можете увійти як користувач root, щоб додати інших користувачів і налаштувати їх так, як вам потрібно. Коли користувачі налаштовані та перевірені, ви можете видалити root-логіни.

Адміністратори

useradd -g wheel ssimpson
useradd -g wheel lblakely

Додаючи наших користувачів до групи "wheel", ви надаєте їм доступ sudo.

Вам все ще потрібен пароль для доступу sudo. Є способи обійти це, але жоден із них не є настільки безпечним. Чесно кажучи, якщо у вас проблеми з безпекою при використанні sudo на вашому сервері, то у вас набагато більші проблеми з усією вашою конфігурацією. Встановіть два паролі адміністратора з безпечними паролями:

passwd ssimpson
Changing password for user ssimpson.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.

passwd lblakely
Changing password for user lblakely.
New password:
Retype new password:
passwd: all authentication tokens updated successfully.

Перевірте доступ до сервера за допомогою ssh для двох ваших адміністративних користувачів. Ви повинні вміти:

  • використовуйте ssh для входу як один з адміністративних користувачів сервера. (Приклад: ssh lblakely@192.168.1.116 або ssh lblakely@mywebserver.com)
  • ви повинні мати доступ до root за допомогою sudo -s та введення пароля адміністратора.

Ви будете готові до наступного кроку, якщо це спрацює для всіх адміністраторів.

Веб-користувачі (SFTP)

Вам потрібно додати наших веб-користувачів. Ця структура каталогів ../html вже існує, тому ви не хочете створювати її під час додавання користувача, але ви потрібно її вказати. Вам також не потрібен інший вхід, окрім SFTP, тому ви повинні використовувати оболонку, яка забороняє вхід.

useradd -M -d /var/www/sub-domains/com.site1/html -g apache -s /usr/sbin/nologin mybroken
useradd -M -d /var/www/sub-domains/com.site2/html -g apache -s /usr/sbin/nologin myfixed

Трохи розберемо ці команди:

  • Параметр -M каже не створювати стандартний домашній каталог для користувача.
  • -d вказує, що далі буде фактичний домашній каталог.
  • -g повідомляє, що група, до якої належить цей користувач, — apache.
  • -s повідомляє, що призначена оболонка /usr/sbin/nologin
  • У кінці вказано фактичне ім’я користувача.

Примітка. Для сервера Nginx ви б використовували nginx як групу.

Нашим користувачам SFTP все ще потрібні паролі. Встановіть безпечний пароль для кожного зараз. Ви вже бачили результат команди вище:

passwd mybroken
passwd myfixed

Конфігурація SSH

Warning

Перш ніж почати цей процес, настійно рекомендуємо створити резервну копію системного файлу, який ви змінюєте: /etc/ssh/sshd_config. Злам цього файлу та відсутність можливості повернутися до оригіналу може спричинити вам цілий душевний біль!

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Вам потрібно внести одну зміну до файлу /etc/ssh/sshd_config. Ви створите шаблон, щоб вносити зміни у свій веб-каталог поза конфігураційним файлом, і створите сценарій доповнень, які вам знадобляться.

Спочатку внесіть необхідні зміни вручну:

vi /etc/ssh/sshd_config

Унизу файлу ви знайдете це:

# override default of no subsystems
Subsystem     sftp    /usr/libexec/openssh/sftp-server

Ви хочете змінити це на наступне:

# override default of no subsystems
# Subsystem     sftp    /usr/libexec/openssh/sftp-server
Subsystem       sftp    internal-sftp

Збережіть і закрийте файл.

sftp-server та internal-sftp є частиною OpenSSH. internal-sftp, хоча й не надто відрізняється від sftp-server, спрощує налаштування за допомогою ChrootDirectory для примусового використання клієнтами іншої кореневої файлової системи. Ось чому ви використовуєте internal-sftp.

Шаблон і сценарій

Чому ви створюєте шаблон і сценарій для наступної частини? Причина полягає в тому, щоб максимально уникнути людської помилки. Ви ще не закінчили змінювати файл /etc/ssh/sshd_config, але хочете усунути якомога більше помилок, коли вам знадобиться внести ці зміни. Ви створите все це у /usr/local/sbin.

Шаблон

Спочатку створіть свій шаблон:

vi /usr/local/sbin/sshd_template

Цей шаблон матиме наступне:

Match User replaceuser
  PasswordAuthentication yes
  ChrootDirectory replacedirectory
  ForceCommand internal-sftp
  AllowTcpForwarding no
  X11Forwarding no

Note

PasswordAuthentication yes зазвичай не потрібен для chroot jail. Однак пізніше ви вимкнете PasswordAuthentication для всіх інших, тому наявність цього рядка в шаблоні є важливою.

Вам потрібен каталог для файлів користувача, який ви також створите з шаблону:

mkdir /usr/local/sbin/templates

Зміни у скрипті та sshd_config

З випусками Rocky Linux 8.6 та 9.0, нова опція для файлу sshd_config дозволяє створювати конфігурації за допомогою випадання. Це ЧУДОВА зміна. Це означає, що вам потрібно буде внести одну додаткову зміну до файлу sshd_config, а наш скрипт запише зміни sftp в окремий файл конфігурації. Ця нова зміна робить речі ще безпечнішими. Безпека - це добре!!

Через зміни, дозволені для файлу sshd_config у Rocky Linux 8.6 і 9.0, наш сценарій використовуватиме новий файл конфігурації: /etc/ssh/sftp/sftp_config.

Для початку створіть цей каталог:

mkdir /etc/ssh/sftp

Тепер створіть резервну копію sshd_config:

cp /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

І, нарешті, відредагуйте файл sshd_config, прокрутіть до самого низу файлу та додайте цей рядок:

Додайте /etc/ssh/sftp/sftp_config

Збережіть зміни та вийдіть із файлу. Вам потрібно буде перезапустити sshd, але наш скрипт зробить це за нас після оновлення файлу sftp_config, тому створіть скрипт і запустіть його.

vi /usr/local/sbin/webuser

І вставте в нього цей код:

#!/bin/bash
    # script to populate the SSHD configuration for web users.

    # Set variables

    tempfile="/usr/local/sbin/sshd_template"
    dompath="/var/www/sub-domains/"

    # Prompt for user and domain in reverse (ext.domainname):

    clear

    echo -n "Enter the web sftp user: "
    read sftpuser
    echo -n "Enter the domain in reverse. Example: com.domainname: "
    read dom
    echo -n "Is all of this correct: sftpuser = $sftpuser and domain = $dom (Y/N)? "
    read yn
    if [ "$yn" = "n" ] || [ "$yn" = "N" ]
    then
        exit
    fi
    if [ "$yn" = "y" ] || [ "$yn" = "Y" ]
    then
        /usr/bin/cat $tempfile > /usr/local/sbin/templates/$dom.txt
        /usr/bin/sed -i "s,replaceuser,$sftpuser,g" /usr/local/sbin/templates/$dom.txt
        /usr/bin/sed -i "s,replacedirectory,$dompath$dom,g" /usr/local/sbin/templates/$dom.txt
        /usr/bin/chown -R $sftpuser.apache $dompath$dom/html
        # Ensure directory permissions are correct
        # The root user owns all directories except the chroot, which is owned by the sftpuser
        # when connecting, you will end up one directory down, and you must actually change to the html directory
        # With a graphical SFTP client, this will be visible to you, you just need to double-click on the html 
        # directory before attmpting to drop in files.
        chmod 755 $dompath
        chmod 755 $dompath$dom
        chmod 755 $dompath$dom/html
        chmod 744 -R $dompath$dom/html/
    fi

    ## Make a backup of /etc/ssh/sftp/sftp_config

    /usr/bin/rm -f /etc/ssh/sftp/sftp_config.bak

    /usr/bin/cp /etc/ssh/sftp/sftp_config /etc/ssh/sftp/sftp_config.bak

    ## Now append our new user information to to the file

    cat /usr/local/sbin/templates/$dom.txt >> /etc/ssh/sftp/sftp_config

    ## Restart sshd

    /usr/bin/systemctl restart sshd

    echo " "
    echo "Please check the status of sshd with systemctl status sshd."
    echo "You can verify that your information was added by doing a more of the sftp_config"
    echo "A backup of the working sftp_config was created when this script was run: sftp_config.bak"

Остаточні зміни та примітки до сценарію

Tip

Якщо ви подивіться на сценарій вище, ви помітите зміну розділювача, який sed використовує за замовчуванням, з / на ,. sed дозволяє використовувати будь-який однобайтовий символ як роздільник. Те, що ви шукаєте у файлі, містить купу символів "/", і вам довелося б уникнути кожного з них (додати "\" перед ними), щоб знайти та замінити ці рядки. Зміна розділювача робить це нескінченно легшим, оскільки усуває необхідність виконувати ці екранування.

Є кілька речей, які слід знати про сценарій і SFTP chroot загалом. Спочатку ви запитуєте необхідну інформацію та повертаєте її користувачеві електронною поштою для перевірки. Якщо ви відповідаєте «N» на запитання підтвердження, сценарій завершується і нічого не робить. Скрипт для версії 8.5 створює резервну копію sshd_config (/etc/ssh/sshd_config.bak) у тому вигляді, у якому вона була до запуску скрипта. Скрипт 8.6 або 9.0 робить те саме для файлу sftp_config (/etc/ssh/sftp/sftp_config.bak). Таким чином, якщо ви допустите помилки в записі, ви можете відновити відповідний файл резервної копії та перезапустити sshd, щоб все знову запрацювало.

SFTP chroot вимагає, щоб шлях, вказаний у sshd_config, мав root-права власності. З цієї причини вам не потрібно додавати каталог html в кінець шляху. Після автентифікації користувача chroot переключить домашній каталог користувача, у цьому випадку каталог ../html, на той домен, який ви вводите. Ваш скрипт належним чином змінив власника каталогу ../html на sftpuser та групу apache.

Зробіть сценарій виконуваним:

chmod +x /usr/local/sbin/webuser

Запустіть сценарій для наших двох тестових доменів.

Тестування відмови SSH і доступу SFTP

Спочатку перевіримо підключення за допомогою ssh з іншої машини на нашу головну машину як один з користувачів SFTP. Ви повинні отримати це після введення пароля:

This service allows sftp connections only.

Тестування графічного інструменту

Якщо ви отримаєте це повідомлення, наступним кроком буде перевірка доступу SFTP. Для простоти тестування ви можете використовувати графічну програму FTP, яка підтримує SFTP, наприклад Filezilla. У таких випадках ваші поля виглядатимуть приблизно так:

  • Host: sftp://hostname_or_IP_of_the_server
  • Username: (Приклад: myfixed)
  • Password: (пароль користувача SFTP)
  • Port: якщо ви використовуєте SSH і SFTP на порті за замовчуванням 22, введіть цей порт

Після заповнення ви можете натиснути кнопку «Швидке підключення» (Filezilla), і ви підключитеся до каталогу ../html відповідного сайту. Двічі клацніть на каталозі "html", щоб помістити себе в нього та спробувати перекинути файл у каталог. Якщо ви досягли успіху, все працює правильно.

Тестування інструментів командного рядка

Ви можете зробити все це з командного рядка на машині з інстальованим SSH (більшість установок Linux). Ось короткий огляд методу підключення за допомогою командного рядка та кілька параметрів:

  • sftp ім’я користувача (Приклад: myfixed@ hostname або IP-адреса сервера: sftp myfixed@192.168.1.116)
  • Введіть пароль, коли буде запропоновано
  • cd html (перейти до каталогу html)
  • pwd (має показувати, що ви перебуваєте в каталозі html)
  • lpwd (повинен показати ваш локальний робочий каталог)
  • lcd PATH (має змінити ваш локальний робочий каталог на те, що ви хочете використовувати)
  • put filename (буде скопійовано файл до каталогу ..html)

Щоб отримати вичерпний перелік параметрів та багато іншого, перегляньте сторінку посібника SFTP.

Веб-тестові файли

Для наших фіктивних доменів вам потрібно створити кілька файлів index.html, якими можна заповнити каталог ../html. Після створення їх потрібно розмістити в каталозі для кожного домену з обліковими даними SFTP. Ці файли спрощені. Ви просто хочете щось перевірити, чи ваші сайти запущені й працюють, а SFTP працює належним чином. Ось приклад цього файлу. Ви можете змінити його, якщо хочете:

<!DOCTYPE html>
<html>
<head>
<title>My Broken Axel</title>
</head>
<body>

<h1>My Broken Axel</h1>
<p>A test page for the site.</p>

</body>
</html>

Веб-тести

Вам потрібно змінити файл hosts на вашій робочій станції, щоб перевірити, чи ці файли відображаються та завантажуються належним чином. Для Linux це буде sudo vi /etc/hosts, і додайте IP-адресу та імена хостів, які ви тестуєте, ось так:

127.0.0.1 localhost
192.168.1.116 www.site1.com site1.com
192.168.1.116 www.site2.com site2.com
# The following lines are desirable for IPv6 capable hosts
::1     ip6-localhost ip6-loopback
fe00::0 ip6-localnet
ff00::0 ip6-mcastprefix
ff02::1 ip6-allnodes
ff02::2 ip6-allrouters

Tip

Ви б хотіли заповнити ваші DNS-сервери зазначеними вище хостами для справжніх доменів. Однак ви можете використовувати цей DNS бідняка для тестування будь-якого домену, навіть того, який не був активований на справжніх серверах DNS.

Відкрийте веббраузер і переконайтеся, що файл index.html для кожного домену відображається, ввівши URL-адресу в адресний рядок браузера. (Приклад: http://site1.com) Якщо ваші тестові індексні файли завантажуються, все працює правильно.

Частина 3: Адміністративний доступ за допомогою пар ключів SSH

Зверніть увагу, що ви використовуватимете концепції, обговорені в документі SSH Public and Private Keys, а також удосконалюватимете його. Якщо ви новачок у цьому процесі, прочитайте цю статтю, перш ніж продовжити.

Створення пар відкритих/приватних ключів

З командного рядка однієї з робочих станцій адміністратора (приклад: lblakely) виконайте наступне:

ssh-keygen -t rsa

Що дасть вам це:

Генерація пари ключів rsa (публічний/приватний).
Введіть файл, у якому потрібно зберегти ключ (/home/lblakely/.ssh/id_rsa):

Натисніть Enter, щоб створити закритий ключ у вказаному місці. Це дасть вам таке діалогове вікно:

Enter passphrase (empty for no passphrase):

Ви повинні особисто вирішити, чи потрібна вам парольна фраза для цього кроку. Автор завжди просто натискає сюди.

Enter same passphrase again:

Повторіть будь-яку парольну фразу, яку ви ввели раніше, або введіть жодну.

На даний момент існують відкритий і закритий ключі. Повторіть цей крок для іншого прикладу користувача системного адміністратора.

Передача відкритого ключа на сервер SFTP

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

Користувач може безпечно надіслати ключ на сервер за допомогою ssh-id-copy після створення:

ssh-id-copy lblakely@192.168.1.116

Сервер один раз запросить пароль користувача та скопіює ключ у authorized_keys. Ви також отримаєте це повідомлення:

Number of key(s) added: 1

Now try logging into the machine, with:   "ssh 'lblakely@192.168.1.116'"
and check to make sure that only the key(s) you wanted were added.

Якщо ви можете ввійти за допомогою цього облікового запису, повторіть процес з іншим адміністратором.

Дозволено ЛИШЕ вхід на основі ключів

Якщо все пройшло так, як було заплановано, і наші ключі для наших адміністраторів тепер на сервері SFTP, вам потрібно вимкнути автентифікацію пароля на сервері. З міркувань безпеки переконайтеся, що у вас є два підключення до сервера, щоб скасувати будь-які зміни, якщо у вас виникнуть небажані наслідки.

Щоб виконати цей крок, вам потрібно знову змінити sshd_config і, як і раніше, спочатку потрібно створити резервну копію файлу:

cp -f /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Далі відредагуйте файл sshd_config:

vi /etc/ssh/sshd_config

Ви хочете вимкнути тунельовані паролі. Знайдіть цей рядок у конфігурації:

PasswordAuthentication yes

Змініть його на "no" - зауважте, що це лише зауваження, що цей рядок не завершиться, оскільки за замовчуванням завжди "yes".

PasswordAuthentication no

Автентифікацію з відкритим ключем увімкнено за замовчуванням, але переконайтеся, що це так, видаливши примітку перед цим рядком:

#PubkeyAuthentication yes

Так, щоб воно читало:

PubkeyAuthentication yes

Це робить наш файл sshd_config певною мірою самодокументованим.

Збережіть зміни. Схрестіть пальці та перезапустіть sshd:

systemctl restart sshd

Спроба входу на сервер як один із ваших адміністраторів за допомогою їхніх ключів має працювати, як і раніше. Якщо ні, відновіть резервну копію, переконайтеся, що ви виконали всі кроки, і повторіть спробу.

Частина 4: Вимкніть віддалений root-вхід

Ви функціонально це вже зробили. Якщо ви спробуєте зараз увійти на сервер із правами root, ви отримаєте наступне:

root@192.168.1.116: Permission denied (publickey,gssapi-keyex,gssapi-with-mic).

Але ви хочете переконатися, що хтось не зможе створити відкритий/приватний ключ для користувача root і таким чином отримати доступ до сервера. Для цього вам знадобиться один останній крок. Ви внесете цю зміну... Ви вгадали! ... у файлі sshd_config.

Подібно до будь-якого іншого кроку під час зміни файлу sshd_config, перш ніж продовжити, потрібно створити резервну копію файлу:

cp -f /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

Відредагуйте sshd_config:

vi /etc/ssh/sshd_config

Знайдіть цей рядок:

PermitRootLogin yes

Змініть його на "no":

PermitRootLogin no

Збережіть, вийдіть із файлу та перезапустіть sshd:

systemctl restart sshd

Віддалений вхід користувача root через ssh отримає те саме повідомлення про відмову, що й раніше, але все ще не зможе навіть отримати доступ до сервера якщо вони мають пару відкритий/приватний ключ для root.

Додаток: нові системні адміністратори

Ще не обговорювалося те, що відбувається при додаванні іншого системного адміністратора. ssh-copy-id не працюватиме, якщо вимкнено автентифікацію за паролем. Ось що рекомендує автор у таких ситуаціях. Зверніть увагу, що існує більше одного рішення. На додаток до методів, згаданих тут, існуючий адміністратор може створити та розгорнути ключі для іншого адміністратора.

Перше рішення – Sneaker Net

Це рішення передбачає фізичний доступ до сервера та те, що сервер є фізичним обладнанням, а не віртуальним (контейнер або віртуальна машина):

  • Додайте користувача до групи «колесо» на сервері SFTP
  • Попросіть користувача згенерувати відкритий і закритий ключі SSH
  • За допомогою USB-накопичувача скопіюйте відкритий ключ на диск, фізично перенесіть його на сервер і встановіть його вручну в новому каталозі системних адміністраторів /home/[username]/.ssh

Друге рішення – тимчасово відредагуйте sshd_config

Це рішення схильне до людських помилок, але оскільки це робиться нечасто, можливо, буде добре, якщо це робити обережно:

  • Додайте користувача до групи «колесо» на сервері SFTP
  • Попросіть іншого системного адміністратора, який уже має автентифікацію на основі ключа, тимчасово ввімкніть «PasswordAuthentication yes» у файлі sshd_config і перезапустіть sshd
  • Попросіть нового системного адміністратора запустити ssh-copy-id, використовуючи свій пароль, щоб скопіювати ключ ssh на сервер.

Рішення третє - сценарій процесу

Цей процес використовує системного адміністратора, який уже має доступ на основі ключів, і сценарій, який має виконуватися з bash [script-name], щоб виконати те саме, що й у «Рішенні два» вище:

  • вручну відредагуйте файл sshd_config та видаліть зарезервований рядок, який виглядає так: #PasswordAuthentication no. Цей рядок документує процес вимкнення автентифікації за паролем, але він заважатиме виконанню наведеного нижче скрипта, оскільки наш скрипт шукатиме перше входження PasswordAuthentication no, а потім перше входження PasswordAuthentication yes. Якщо ви видалите цей один рядок, наш сценарій працюватиме нормально.
  • створіть сценарій на сервері SFTP під назвою "quickswitch" або як завгодно його називаєте. Вміст цього сценарію виглядатиме так:
#!/bin/bash
# for use in adding a new system administrator

/usr/bin/cp -f /etc/ssh/sshd_config /etc/ssh/sshd_config.bak

/usr/bin/sed -i '0,/PasswordAuthentication no/ s/PasswordAuthentication no/PasswordAuthentication yes/' /etc/ssh/sshd_config
/usr/bin/systemctl restart sshd
echo "Have the user send his keys, and then hit enter."
read yn
/usr/bin/sed -i '0,/PasswordAuthentication yes/ s/PasswordAuthentication yes/PasswordAuthentication no/' /etc/ssh/sshd_config
/usr/bin/systemctl restart sshd
echo "Changes reversed"

Пояснення сценарію: ви не робите цей сценарій виконуваним. Причина в тому, що ви не хочете, щоб він запускався випадково. Скрипт працює (як зазначено вище) так: bash /usr/local/sbin/quickswitch. Цей скрипт створює резервну копію файлу sshd_config, як і всі інші наші приклади вище. Потім він редагує файл sshd_config на місці та шукає ПЕРШИЙ вхід PasswordAuthentication no та змінює його на PasswordAuthentication yes, потім перезапускає sshd та чекає, поки користувач скрипта натисне Enter, перш ніж продовжити. Системний адміністратор, який запускає скрипт, зв'язуватиметься з новим системним адміністратором, і щойно новий системний адміністратор запустить ssh-copy-id, щоб скопіювати свій ключ на сервер, системний адміністратор, який запускає скрипт, натискатиме Enter, і це скасує зміни.

Коротше кажучи, існує багато способів додати іншого системного адміністратора після впровадження процедур блокування SSH.

Висновок

Цей документ великий. Це зробить багатосайтовий веб-сервер більш безпечним і менш схильним до векторів атак через SSH під час увімкнення SFTP для доступу клієнтів. SFTP набагато безпечніший за FTP, навіть якщо ви використовуєте справді ХОРОШИЙ FTP-сервер і налаштовуєте його максимально безпечно, як зазначено в цьому документі про VSFTPD. Виконуючи всі кроки, описані в цьому документі, ви можете впевнено відкривати порт 22 (SSH) для вашої публічної зони та все одно бути впевненим у безпеці вашого середовища.

Author: Steven Spencer

Contributors: Ezequiel Bruni, Ganna Zhyrnova