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

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

Вступ

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

Примітка

Ви можете застосувати ці концепції до будь-якої установки сервера та будь-якого веб-демона. Хоча ми тут припускаємо 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

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

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

Потрібно створити два сайти. Ви створите конфігурації в /etc/httpd/sites-available і зв’яжете їх з ../sites-enabled:

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

Примітка

У прикладі використовується лише протокол 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

Важливо

Перш ніж почати цей процес, настійно рекомендуємо створити резервну копію системного файлу, який ви змінюєте: /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-сервер і internal-sftp є частиною OpenSSH. internal-sftp, хоч і не надто відрізняється від sftp-сервера, спрощує конфігурації за допомогою 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

Примітка

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

Зміни сценарію і sshd_config

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"

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

Підказка

Якщо ви подивіться на сценарій вище, ви помітите зміну розділювача, який 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. Ви повинні отримати це після введення пароля:

Ця служба дозволяє лише з’єднання sftp.

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

Якщо ви отримаєте це повідомлення, наступним чином перевірте доступ 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

Підказка

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

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

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

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

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

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

ssh-keygen -t rsa

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

Generating public/private rsa key pair.
Enter file in which to save the key (/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 так. Якщо ви видалите цей один рядок, наш сценарій працюватиме нормально.
  • створіть сценарій на сервері 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