One place for hosting & domains

      CentOS

      Установка и настройка стека LEMP с помощью Software Collections в CentOS 7


      Автор выбрал Apache Software Foundation для получения пожертвования в размере $100 в рамках программы Write for DOnations.

      Введение

      Стек ПО LEMP — это группа программного обеспечения с открытым исходным кодом, которая обычно устанавливается вместе, чтобы на сервере могли размещаться динамические веб-сайты и веб-приложения. Этот термин представляет собой акроним, представляющий операционную систему Linux с веб-сервером ENginx (который заменяет Apache в стеке LAMP). Данные сайта хранятся в базе данных MySQL (используется MariaDB), а за динамическое содержание отвечает PHP.

      Компоненты стека LEMP иногда устанавливаются с помощью репозитория EPEL CentOS 7. Однако этот репозиторий содержит устаревшие пакеты. Например, вы не можете установить версию PHP старше 5.4.16 из EPEL, хотя этот релиз не поддерживается уже длительное время. Для получения новых версий программного обеспечения рекомендуется использовать набор Software Collections, также известный как SCL. SCL — это коллекции ресурсов для разработчиков, предоставленные RedHat, которые позволяют использовать различные версии программного обеспечения в одной и той же системе без какого-либо влияния на ранее установленные пакеты.

      В этом руководстве вы установите стек LEMP на сервер с CentOS 7. Операционная система CentOS отвечает за работу компонентов Linux. Вы установите остальные компоненты с помощью репозитория Software Collections, а затем настроите их для обслуживания простой веб-страницы.

      Предварительные требования

      Прежде чем приступить к выполнению данного обучающего руководства, у вас должен быть сервер CentOS 7, настроенный согласно руководству по начальной настройке сервера CentOS 7, а также пользователь sudo без прав root.

      Шаг 1 — Активация репозитория Software Collections

      Для получения доступа к SCL для CentOS установите release-файл для Software Collections в CentOS:

      • sudo yum install centos-release-scl

      Просмотрите список доступных пакетов SCL с помощью следующей команды:

      • yum --disablerepo='*' --enablerepo='centos-sclo-rh' --enablerepo='centos-sclo-sclo' list available

      Для предотвращения конфликтов в рамках всей системы пакеты SCL устанавливаются в директорию /opt/rh. Это позволяет установить, например, Python 3.5 на компьютере с CentOS 7 без удаления или вмешательства в работу Python 2.7.

      Все файлы конфигурации для пакетов SCL хранятся в соответствующей директории внутри директории /etc/opt/rh/. Пакеты SCL содержат скрипты, которые определяют переменные среды, необходимые для использования приложений внутри пакета, например, PATH, LD_LIBRARY_PATH и MANPATH. Эти скрипты хранятся в файловой системе в каталоге /opt/rh/package-name/enable.

      Теперь вы можете начать установку пакетов, описанных в этом руководстве.

      Шаг 2 — Установка сервера Web Nginx

      Для показа веб-страниц посетителям мы будем использовать Nginx, современный и эффективный веб-сервер.

      Установите Nginx с помощью следующей команды yum. Обязательно замените выделенное значение версией Nginx, которую вы хотите установить; самая последняя версия будет иметь самый большой номер в имени пакета (112 на момент написания статьи):

      • sudo yum install rh-nginx112

      После завершения установки запустите службу Nginx:

      • sudo systemctl start rh-nginx112-nginx

      Проверьте, что Nginx запущен с помощью команды systemctl status​​​:

      • sudo systemctl status rh-nginx112-nginx

      Output

      ● rh-nginx112-nginx.service - The nginx HTTP and reverse proxy server Loaded: loaded (/usr/lib/systemd/system/rh-nginx112-nginx.service; disabled; vendor preset: disabled) Active: active (running) since Fri 2018-03-19 15:15:43 UTC; 1min 17s ago Main PID: 10556 (nginx) CGroup: /system.slice/rh-nginx112-nginx.service ├─10556 nginx: master process /opt/rh/rh-nginx112/root/usr/sbin/nginx ├─10557 nginx: worker process └─10558 nginx: worker process Mar 19 15:15:43 lemp-centos-222 systemd[1]: Starting The nginx HTTP and reverse proxy server... Mar 19 15:15:43 lemp-centos-222 nginx-scl-helper[10541]: nginx: the configuration file /etc/opt/rh/rh-nginx... ok Mar 19 15:15:43 lemp-centos-222 nginx-scl-helper[10541]: nginx: configuration file /etc/opt/rh/rh-nginx112/...ful Mar 19 15:15:43 lemp-centos-222 systemd[1]: Started The nginx HTTP and reverse proxy server. Hint: Some lines were ellipsized, use -l to show in full.

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

      • sudo yum install firewalld

      После этого вы сможете запустить службу firewalld:

      • sudo systemctl start firewalld

      Затем добавьте ряд правил брандмауэра, чтобы разрешить доступ SSH-доступ к вашему серверу и подключение через HTTP и HTTPS к Nginx:

      • sudo firewall-cmd --permanent --add-service=ssh
      • sudo firewall-cmd --zone=public --permanent --add-service=http
      • sudo firewall-cmd --zone=public --permanent --add-service=https

      Перезапустите firewalld для вступления в силу новых правил брандмауэра:

      • sudo firewall-cmd --reload

      Подробнее о firewalld см. в статье Настройка брандмауэра с помощью FirewallD в CentOS 7.

      После добавления этих новых правил брандмауэра вы можете проверить, запущен ли сервер, указав в браузере доменное имя вашего сервера или открытый IP-адрес.

      Если у вас нет доменного имени, указывающего на ваш сервер, и вы не знаете открытый IP-адрес вашего сервера, вы можете найти его, введя в терминал следующую команду:

      Введите полученный IP-адрес в адресную строку браузера, в результате чего вы должны увидеть используемую по умолчанию начальную страницу Nginx:

      http://server_domain_or_IP
      

      Страница Nginx по умолчанию

      Если вы видите эту страницу, это значит, что вы успешно установили Nginx. Перед продолжением активируйте запуск Nginx при загрузке сервера с помощью следующей команды:

      • sudo systemctl enable rh-nginx112-nginx

      Сервер Nginx установлен, и теперь вы можете перейти к установке программного обеспечения для работы с базами данных MariaDB.

      Шаг 3 — Установка MariaDB для управления данными сайта

      Теперь, когда у нас есть веб-сервер, пришло время установить MariaDB, упрощенную версию MySQL, используемую для хранения данных вашего сайта и управления ими.

      Установите MariaDB с помощью следующей команды. Снова замените выделенное значение номером версии, которую вы хотите установить, самый большой номер является номером самой последней версии (102 на момент написания):

      • sudo yum install rh-mariadb102

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

      • sudo systemctl start rh-mariadb102-mariadb

      После этого службу MariaDB можно считать установленной и запущенной. Однако ее настройка еще не завершена.

      Для обеспечения безопасности MariaDB устанавливается вместе с скриптом безопасности, который напоминает вам о необходимости изменения небезопасных настроек по умолчанию. Запустите скрипт, введя следующую команду:

      • source /opt/rh/rh-mariadb102/enable
      • mysql_secure_installation

      Вам потребуется ввести ваш текущий пароль root. Так как вы только что установили MySQL, у вас нет пароля, поэтому оставьте это поле пустым и нажмите ENTER. После этого вам будет предложено установить пароль root. Введите Y и следуйте этим инструкциям:

      . . .
      Enter current password for root (enter for none):
      OK, successfully used password, moving on...
      
      Setting the root password ensures that nobody can log into the MariaDB
      root user without the proper authorization.
      
      Set root password? [Y/n] Y
      New password: password
      Re-enter new password: password
      Password updated successfully!
      Reloading privilege tables..
       ... Success!
      . . .
      

      Для остальных вопросов нажмите клавишу ENTER для использования значения по умолчанию. В результате вы должны удалить ряд анонимных пользователей и тестовую базу данных, отключить возможность удаленного входя для root и загрузить эти новые правила, чтобы MariaDB немедленно использовала внесенные нами изменения.

      Последнее, что нужно сделать, — это активировать для MariaDB запуск при загрузке сервера. Для этого используйте следующую команду:

      • sudo systemctl enable rh-mariadb102-mariadb

      В данный момент ваша система базы данных настроена, и вы можете переходить к настройке PHP на своем сервере.

      Шаг 4 — Установка и настройка PHP

      Теперь у вас есть Nginx для обслуживания ваших страниц и MariaDB для хранения и управления данными, однако у вас до сих пор не установлено ПО, которое может генерировать динамическое содержание. Именно для этого и нужен PHP.

      Поскольку Nginx не поддерживает нативную обработку PHP, как некоторые другие веб-серверы, вам потребуется установить php-fpm, т.е. «менеджер процессов fastCGI». Затем вы должны будете настроить Nginx, чтобы передавать PHP-запросы этому программному продукту.

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

      • sudo yum install rh-php71-php-fpm rh-php71-php-mysqlnd

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

      Откройте главный файл конфигурации php.ini с правами root:

      • sudo vi /etc/opt/rh/rh-php71/php.ini

      В этом файле вам нужно найти параметр, который устанавливает значение для cgi.fix_pathinfo. Он будет закомментирован с помощью точки с запятой (;) и имеет значение «1» по умолчанию.

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

      Измените оба эти условия, разкомментировав строку и установив значение «0»:

      71/php.ini’>/etc/opt/rh/rh-php71/php.ini

      cgi.fix_pathinfo=0
      

      Сохраните и закройте файл после завершения редактирования (нажмите ESC, введите :wq, а затем нажмите ENTER).“”

      Теперь откройте файл конфигурации php-fpm по адресу www.conf​​​​:

      • sudo vi /etc/opt/rh/rh-php71/php-fpm.d/www.conf

      По умолчанию этот файл настроен для работы с сервером Apache. Поскольку на вашем сервере установлен Nginx, найдите строки, которые устанавливают user и group и измените их значения с «apache» на «nginx»:

      71/php-fpm.d/www.conf’>/etc/opt/rh/rh-php71/php-fpm.d/www.conf

      user = nginx
      group = nginx
      

      Затем сохраните и закройте файл.

      Теперь запустите процессор PHP с помощью следующей команды:

      • sudo systemctl start rh-php71-php-fpm

      Активируйте запуск php-fpm при загрузке:

      • sudo systemctl enable rh-php71-php-fpm

      Поздравляем, вы успешно установили PHP на свой сервер. Однако он должен быть настроен для работы с другим ПО, которое вы установили, чтобы позволить вашему серверу корректно обслуживать содержание вашего сайта.

      Шаг 5 — Настройка Nginx для использования процессора PHP

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

      Это изменение конфигурации выполняется уровне блока server (блоки сервера похожи на виртуальные хосты в Apache). Откройте файл конфигурации сервера Nginx по умолчанию, введя следующую команду:

      • sudo vi /etc/opt/rh/rh-nginx112/nginx/nginx.conf

      Раскомментируйте блок location ~ .php$ (сегмент файла, обрабатывающий запросы PHP и находящийся внутри блока server) и его содержимое, удалив символ решетки (#) в начале строки. Также вам нужно обновить параметр fastcgi_param и указать значение SCRIPT FILENAME $document_root$fastcgi_script_name. Это позволит PHP узнать местоположение документа root, где он сможет найти файлы для обработки.

      После внесения необходимых изменений блок server будет выглядеть следующим образом:

      /etc/nginx/sites-available/default

      ...
      server {
          listen       80 default_server;
          listen       [::]:80 default_server;
          server_name  _;
          root         /opt/rh/rh-nginx112/root/usr/share/nginx/html;
      
          # Load configuration files for the default server block.
          include      /etc/opt/rh/rh-nginx112/nginx/default.d/*.conf;
      
          location / {
          }
      
          error_page 404 /404.html;
          location = /40x.html {
          }
      
          error_page 500 502 503 504  /50x.html;
          location = /50x.html {
          }
      
          # proxy the PHP scripts to Apache listening on 127.0.0.1:80
          #
          #location ~ .php$ {
          #    proxy_pass   http://127.0.0.1;
          #}
      
          # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
          #
          location ~ .php$ {
              root           html;
              fastcgi_pass   127.0.0.1:9000;
              fastcgi_index  index.php;
              fastcgi_param  SCRIPT_FILENAME $document_root$fastcgi_script_name;
              include        fastcgi_params;
          }
      
          # deny access to .htaccess files, if Apache's document root
          # concurs with nginx's one
          #
          #location ~ /.ht {
          #    deny  all;
          #}
      }
      ...
      

      После внесения необходимых изменений вы можете сохранить файл и закрыть редактор.

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

      • source /opt/rh/rh-nginx112/enable
      • sudo nginx -t

      При появлении сообщений о каких-либо ошибках, вернитесь и повторно проверьте ваш файл, прежде чем продолжать.

      После подтверждения корректности файла конфигурации перезагрузите Nginx, чтобы внесенные вами изменения вступили в силу:

      • sudo systemctl reload rh-nginx112-nginx

      Теперь, когда Nginx, PHP и MariaDB были установлены и настроены, осталось только подтвердить, что настройка стека LEMP способна корректно предоставлять содержание для посетителей вашего сайта.

      Шаг 6 — Создание файла PHP для тестовой конфигурации

      Ваш стек LEMP полностью настроен, и вы можете протестировать его, чтобы убедиться, что Nginx может корректно предоставлять файлы .php вашему процессору PHP. Для этого мы создадим тестовый файл PHP в корневой директории документа.

      Откройте новый файл с названием info.php внутри корневой директории документа:

      • sudo vi /opt/rh/rh-nginx112/root/usr/share/nginx/html/info.php

      Добавьте в новый файл следующую строку. Это корректный код PHP, который будет возвращать информацию о вашем сервере:

      112/root/usr/share/nginx/html/info.php’>/opt/rh/rh-nginx112/root/usr/share/nginx/html/info.php

      <?php phpinfo(); ?>
      

      После завершения редактирования сохраните и закройте файл. Затем откройте эту страницу в браузере, указав в адресной строке доменное имя вашего сервера или открытый IP-адрес и добавив /info.php:

      http://server_domain_or_IP/info.php
      

      Вы увидите веб-страницу, сгенерированную PHP, с информацией о вашем сервере:

      Страница PHP с информацией

      Если ваша страница выглядит таким образом, вам удалось успешно реализовать обработку PHP с помощью Nginx.

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

      Удалите файл, введя следующую команду:

      • sudo rm /opt/rh/rh-nginx112/root/usr/share/nginx/html/info.php

      Вы успешно подтвердили, что все компоненты стека LEMP установлены и настроены корректно на вашем сервере.

      Заключение

      Теперь у вас в распоряжении есть полностью настроенный стек LEMP на вашем сервере с CentOS 7. Он будет служить гибкой основой для предоставления веб-контента вашим посетителям.

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

      Дополнительную информацию о Software Collections вы можете найти на официальном сайте.



      Source link

      Настройка ключей SSH в CentOS 7


      Введение

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

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

      Шаг 1 — Создание пары ключей RSA

      Первый шаг — создание пары ключей на клиентской системе (обычно на вашем компьютере):

      По умолчанию команда ssh-keygen создает пару 2048-битных ключей RSA. Этот уровень защиты достаточен для большинства случаев (но при желании вы можете использовать флаг -b 4096, чтобы создать более надежный 4096-битный ключ).

      Восле ввода команды вы должны увидеть следующую строку:

      Output

      Generating public/private rsa key pair. Enter file in which to save the key (/your_home/.ssh/id_rsa):

      Нажмите ENTER, чтобы сохранить пару ключей в подкаталог .ssh/ домашнего каталога или укажите альтернативный путь.

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

      Output

      /home/your_home/.ssh/id_rsa already exists. Overwrite (y/n)?

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

      Затем вы должны увидеть следующую строку:

      Output

      Enter passphrase (empty for no passphrase):

      Здесь вы можете ввести защищенный пароль, что настоятельно рекомендуется сделать. Пароль добавляет дополнительный уровень безопасности для защиты от входа в систему несанкционированных пользователей. Дополнительную информацию о безопасности можно найти в нашем обучающем модуле Настройка аутентификации на базе ключей SSH на сервере Linux.

      Вы должны увидеть следующий результат:

      Output

      Your identification has been saved in /your_home/.ssh/id_rsa. Your public key has been saved in /your_home/.ssh/id_rsa.pub. The key fingerprint is: a9:49:2e:2a:5e:33:3e:a9:de:4e:77:11:58:b6:90:26 username@remote_host The key's randomart image is: +--[ RSA 2048]----+ | ..o | | E o= . | | o. o | | .. | | ..S | | o o. | | =o.+. | |. =++.. | |o=++. | +-----------------+

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

      Шаг 2 — Копирование открытого ключа на сервер CentOS

      Самый быстрый способ скопировать открытый ключ на хост CentOS — использовать утилиту ssh-copy-id. Это самый простой способ, поэтому его рекомендуется использовать, если он доступен. Если на клиентском компьютере нет утилиты ssh-copy-id, вы можете использовать один из двух альтернативных методов, описанных в этом разделе (копирование через SSH на базе пароля или копирование ключа вручную).

      Копирование открытого ключа с помощью утилиты ssh-copy-id

      Утилита ssh-copy-id по умолчанию входит в состав многих операционных систем, поэтому она может быть доступна на вашем локальном компьютере. Чтобы этот метод сработал, вы должны уже настроить защищенный паролем доступ к серверу через SSH.

      Для использования этой утилиты вам нужно только указать удаленный хост, к которому вы хотите подключиться, и учетную запись пользователя, к которой у вас есть доступ через SSH с использованием пароля. Ваш открытый ключ SSH будет скопирован в эту учетную запись.

      Синтаксис выглядит следующим образом:

      • ssh-copy-id username@remote_host

      Вы можете увидеть следующее сообщение:

      Output

      The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes

      Это означает, что ваш локальный компьютер не распознает удаленный хост. Это произойдет при первом подключении к новому хосту. Введите «yes» и нажмите ENTER, чтобы продолжить.

      Затем утилита проведет сканирование локальной учетной записи для поиска ранее созданного ключа id_rsa.pub. Когда ключ будет найден, вам будет предложено ввести пароль учетной записи удаленного пользователя:

      Output

      /usr/bin/ssh-copy-id: INFO: attempting to log in with the new key(s), to filter out any that are already installed /usr/bin/ssh-copy-id: INFO: 1 key(s) remain to be installed -- if you are prompted now it is to install the new keys username@203.0.113.1's password:

      Введите пароль (для безопасности вводимый текст не будет отображаться) и нажмите ENTER. Утилита подключится к учетной записи на удаленном хосте, используя указанный вами пароль. Затем содержимое ключа ~/.ssh/id_rsa.pub будет скопировано в каталог основной каталог ~/.ssh удаленной учетной записи в файл с именем authorized_keys.

      Вы должны увидеть следующий результат:

      Output

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

      Теперь ваш ключ id_rsa.pub key выгружен в удаленную учетную запись. Вы можете переходить к шагу 3.

      Копирование открытого ключа с помощью SSH

      Если у вас нет ssh-copy-id, но вы активировали защищенный паролем доступ к учетной записи на вашем сервере через SSH, вы можете выгрузить ключи с помощью стандартного метода SSH.

      Для этого нужно использовать команду cat, чтобы прочитать содержимое открытого ключа SSH на локальном компьютере и передать его через соединение SSH на удаленный сервер.

      Также мы можем убедиться, что каталог ~/.ssh и имеет правильные разрешения для используемой нами учетной записи.

      Мы можем вывести переданное содержимое в файл с именем authorized_keys в этом каталоге. Мы используем символ перенаправления >>, чтобы дополнять содержимое, а не заменять его. Это позволяет добавлять ключи без уничтожения ранее добавленных ключей.

      Полная команда выглядит следующим образом:

      • cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && touch ~/.ssh/authorized_keys && chmod -R go= ~/.ssh && cat >> ~/.ssh/authorized_keys"

      Вы можете увидеть следующее сообщение:

      Output

      The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes

      Это означает, что ваш локальный компьютер не распознает удаленный хост. Это произойдет при первом подключении к новому хосту. Введите «yes» и нажмите ENTER, чтобы продолжить.

      После этого вам нужно будет ввести пароль учетной записи удаленного пользователя:

      Output

      username@203.0.113.1's password:

      После ввода пароля содержимое ключа id_rsa.pub будет скопировано в конец файла authorized_keys учетной записи удаленного пользователя. Если операция выполнена успешно, переходите к шагу 3.

      Копирование открытого ключа вручную

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

      Мы вручную добавим содержимое вашего файла id_rsa.pub в файл ~/.ssh/authorized_keys на удаленном компьютере.

      Чтобы вывести содержимое ключа id_rsa.pub, введите на локальном компьютере следующую команду:

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

      Output

      ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAACAQCqql6MzstZYh1TmWWv11q5O3pISj2ZFl9HgH1JLknLLx44+tXfJ7mIrKNxOOwxIxvcBF8PXSYvobFYEZjGIVCEAjrUzLiIxbyCoxVyle7Q+bqgZ8SeeM8wzytsY+dVGcBxF6N4JS+zVk5eMcV385gG3Y6ON3EG112n6d+SMXY0OEBIcO6x+PnUSGHrSgpBgX7Ks1r7xqFa7heJLLt2wWwkARptX7udSq05paBhcpB0pHtA1Rfz3K2B+ZVIpSDfki9UVKzT8JUmwW6NNzSgxUfQHGwnW7kj4jp4AT0VZk3ADw497M2G/12N0PPB5CnhHf7ovgy6nL1ikrygTKRFmNZISvAcywB9GVqNAVE+ZHDSCuURNsAInVzgYo9xgJDW8wUw2o8U77+xiFxgI5QSZX3Iq7YLMgeksaO4rBJEa54k8m5wEiEE1nUhLuJ0X/vh2xPff6SQ1BL/zkOhvJCACK6Vb15mDOeCSq54Cr7kvS46itMosi/uS66+PujOO+xt/2FWYepz6ZlN70bRly57Q06J+ZJoc9FfBCbCyYH7U/ASsmY095ywPsBo1XQ9PqhnN1/YOorJ068foQDNVpm146mUpILVxmq41Cj55YKHEazXGsdBIbXWhcrRf4G2fJLRcGUr9q8/lERo9oxRm5JFX6TCmj6kmiFqv+Ow9gI0x8GvaQ== demo@test

      Получите доступ к удаленному хосту с использованием любого доступного метода.

      После получения доступа к учетной записи на удаленном сервере убедитесь, что каталог ~/.ssh существует. При необходимости эта команда создаст каталог, а если каталог уже существует, команда ничего не сделает.

      Теперь вы можете создать или изменить файл authorized_keys в этом каталоге. Вы можете добавить содержимое файла id_rsa.pub в конец файла authorized_keys и при необходимости создать его с помощью этой команды:

      • echo public_key_string >> ~/.ssh/authorized_keys

      В вышеуказанной команде замените public_key_string результатами команды cat ~/.ssh/id_rsa.pub, выполненной на локальном компьютере. Она должна начинаться с ssh-rsa AAAA....

      Наконец, нужно убедиться, что каталог ~/.ssh и файл authorized_keys имеют соответствующий набор разрешений:

      При этом будут рекурсивно удалены все разрешения «group» и «other» для каталога ~/.ssh/.

      Если вы используете учетную запись root для настройки ключей учетной записи пользователя, важно учитывать, что каталог ~/.ssh принадлежит пользователю, а не пользователю root:

      • chown -R sammy:sammy ~/.ssh

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

      Теперь мы можем попробовать настроить аутентификацию без пароля на нашем сервере Ubuntu.

      Шаг 3 — Аутентификация на сервере CentOS с помощью ключей SSH

      Если вы успешно выполнили одну из вышеописанных процедур, вы сможете войти на удаленный хост без пароля учетной записи для удаленного хоста.

      Базовый процесс выглядит аналогично:

      Если вы подключаетесь к этому хосту первый раз (если вы используете указанный выше последний метод), вы сможете увидеть следующее:

      Output

      The authenticity of host '203.0.113.1 (203.0.113.1)' can't be established. ECDSA key fingerprint is fd:fd:d4:f9:77:fe:73:84:e1:55:00:ad:d6:6d:22:fe. Are you sure you want to continue connecting (yes/no)? yes

      Это означает, что ваш локальный компьютер не распознает удаленный хост. Введите «yes» и нажмите ENTER, чтобы продолжить.

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

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

      Шаг 4 — Отключение аутентификации на сервере с помощью пароля

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

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

      Подтвердив права администратора для удаленной учетной записи, выполните вход на удаленный сервер с помощью ключей SSH как пользователь с привилегиями root или как пользователь с привилегиями sudo. Затем откройте файл конфигурации демона SSH:

      • sudo vi /etc/ssh/sshd_config

      Найдите в файле директиву PasswordAuthentication. В начале строки этой директивы может стоять знак комментария. Нажмите i для вставки текста, удалите знак комментария и установите значение «no». После этого вы не сможете выполнять вход в систему через SSH с использованием паролей учетной записи:

      /etc/ssh/sshd_config

      ...
      PasswordAuthentication no
      ...
      

      Когда вы закончите вносить изменения, нажмите ESC, а затем введите :wq для записи изменений в файл и выхода из системы. Для фактического внесения этих изменений нужно перезапустить службу sshd:

      • sudo systemctl restart sshd.service

      В качестве меры предосторожности откройте новое окно терминала и проверьте работу службы SSH, прежде чем закрывать этот сеанс:

      После проверки работы службы SSH вы сможете безопасно закрыть все текущие сеансы сервера.

      Теперь демон SSH на вашем сервере CentOS будет реагировать только на ключи SSH. Аутентификация на базе паролей успешно отключена.

      Заключение

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

      Если вы хотите узнать больше о работе с SSH, посмотрите наше Руководство по основам SSH.



      Source link

      How To Set Up the code-server Cloud IDE Platform on CentOS 7


      The author selected the Free and Open Source Fund to receive a donation as part of the Write for DOnations program.

      Introduction

      With developer tools moving to the cloud, creation and adoption of cloud IDE (Integrated Development Environment) platforms is growing. Cloud IDEs allow for real-time collaboration between developer teams to work in a unified development environment that minimizes incompatibilities and enhances productivity. Accessible through web browsers, cloud IDEs are available from every type of modern device.

      code-server is Microsoft Visual Studio Code running on a remote server and accessible directly from your browser. Visual Studio Code is a modern code editor with integrated Git support, a code debugger, smart autocompletion, and customizable and extensible features. This means that you can use various devices running different operating systems, and always have a consistent development environment on hand.

      In this tutorial, you will set up the code-server cloud IDE platform on your CentOS 7 machine and expose it at your domain, secured with free Let’s Encrypt TLS certificates. In the end, you’ll have Microsoft Visual Studio Code running on your CentOS 7 server, available at your domain and protected with a password.

      Prerequisites

      • A server running CentOS 7 with at least 2GB RAM, root access, and a sudo, non-root account. You can set this up by following this initial server setup guide.

      • Nginx installed on your server. For a guide on how to do this, see How To Install Nginx on CentOS 7.

      • Both of the following DNS records set up for your server. You can follow this introduction to DigitalOcean DNS for details on how to add them.

        • An A record with your-domain pointing to your server’s public IP address.
        • An A record with www.your-domain pointing to your server’s public IP address.
      • A fully registered domain name to host code-server, pointed to your server. This tutorial will use code-server.your-domain throughout. You can purchase a domain name on Namecheap, get one for free on Freenom, or use the domain registrar of your choice.

      Step 1 — Installing code-server

      In this section, you will set up code-server on your server. This entails downloading the latest version and creating a systemd service that will keep code-server always running in the background. You’ll also specify a restart policy for the service, so that code-server stays available after possible crashes or reboots.

      You’ll store all data pertaining to code-server in a folder named ~/code-server. Create it by running the following command:

      Navigate to it:

      You’ll need to head over to the Github releases page of code-server and pick the latest Linux build (the file will contain ‘linux’ in its name). At the time of writing, the latest version was 2.1692. Download it using curl by running the following command:

      • curl -LO https://github.com/cdr/code-server/releases/download/2.1692-vsc1.39.2/code-server2.1692-vsc1.39.2-linux-x86_64.tar.gz

      Then, unpack the archive by running:

      • tar -xzvf code-server2.1692-vsc1.39.2-linux-x86_64.tar.gz

      You’ll get a folder named exactly as the original file you downloaded, which contains the code-server executable. Navigate to it:

      • cd code-server2.1692-vsc1.39.2-linux-x86_64

      Copy the code-server executable to /usr/local/bin so you’ll be able to access it system wide by running the following command:

      • sudo cp code-server /usr/local/bin

      Next, create a folder for code-server, where it will store user data:

      • sudo mkdir /var/lib/code-server

      Now that you’ve downloaded code-server and made it available system-wide, you will create a systemd service to keep code-server running in the background at all times.

      You’ll store the service configuration in a file named code-server.service, in the /usr/lib/systemd/system directory, where systemd stores its services. Create it using the vi editor:

      • sudo vi /usr/lib/systemd/system/code-server.service

      Add the following lines:

      /usr/lib/systemd/system/code-server.service

      [Unit]
      Description=code-server
      After=nginx.service
      
      [Service]
      Type=simple
      Environment=PASSWORD=your_password
      ExecStart=/usr/local/bin/code-server --host 127.0.0.1 --user-data-dir /var/lib/code-server --auth password
      Restart=always
      
      [Install]
      WantedBy=multi-user.target
      

      Here you first specify the description of the service. Then, you state that the nginx service must be started before this one. After the [Unit] section, you define the type of the service (simple means that the process should be simply run) and provide the command that will be executed.

      You also specify that the global code-server executable should be started with a few arguments specific to code-server. --host 127.0.0.1 binds it to localhost, so it’s only directly accessible from inside of your server. --user-data-dir /var/lib/code-server sets its user data directory, and --auth password specifies that it should authenticate visitors with a password, specified in the PASSWORD environment variable declared on the line above it.

      Remember to replace your_password with your desired password. Type :wq and then ENTER to save and close the file.

      The next line tells systemd to restart code-server in all malfunction events (for example, when it crashes or the process is killed). The [Install] section orders systemd to start this service when it becomes possible to log in to your server.

      Start the code-server service by running the following command:

      • sudo systemctl start code-server

      Check that it’s started correctly by observing its status:

      • sudo systemctl status code-server

      You’ll see output similar to:

      Output

      ● code-server.service - code-server Loaded: loaded (/usr/lib/systemd/system/code-server.service; disabled; vendor preset: disabled) Active: active (running) since Thu 2019-12-19 19:24:42 UTC; 5s ago Main PID: 1668 (code-server) CGroup: /system.slice/code-server.service ├─1668 /usr/local/bin/code-server --host 127.0.0.1 --user-data-dir /var/lib/code-server --auth password └─1679 /usr/local/bin/code-server --host 127.0.0.1 --user-data-dir /var/lib/code-server --auth password Dec 19 19:24:42 code-server-centos systemd[1]: Started code-server. Dec 19 19:24:44 code-server-centos code-server[1668]: info Server listening on http://127.0.0.1:8080 Dec 19 19:24:44 code-server-centos code-server[1668]: info - Using custom password for authentication Dec 19 19:24:44 code-server-centos code-server[1668]: info - Not serving HTTPS

      To make code-server start automatically after a server reboot, enable its service by running the following command:

      • sudo systemctl enable code-server

      In this step, you’ve downloaded code-server and made it available globally. Then, you’ve created a systemd service for it and enabled it, so code-server will start at every server boot. Next, you’ll expose it at your domain by configuring Nginx to serve as a reverse proxy between the visitor and code-server.

      Step 2 — Exposing code-server at Your Domain

      In this section, you will configure Nginx as a reverse proxy for code-server.

      As you have learned in the Nginx prerequisite step, its site configuration files are stored under /etc/nginx/conf.d and will automatically be loaded when Nginx starts.

      You’ll store the configuration for exposing code-server at your domain in a file named code-server.conf, under /etc/nginx/conf.d. Start off by creating it using your editor:

      • sudo vi /etc/nginx/conf.d/code-server.conf

      Add the following lines:

      /etc/nginx/conf.d/code-server.conf

      server {
          listen 80;
          listen [::]:80;
      
          server_name code-server.your-domain;
      
          location / {
              proxy_pass http://localhost:8080/;
              proxy_set_header Upgrade $http_upgrade;
              proxy_set_header Connection upgrade;
              proxy_set_header Accept-Encoding gzip;
          }
      }
      

      Replace code-server.your-domain with your desired domain, then save and close the file.

      In this file, you define that Nginx should listen to HTTP port 80. Then, you specify a server_name that tells Nginx for which domain to accept requests and apply this particular configuration.

      In the next block, for the root location (/), you specify that requests should be passed back and forth to code-server running at localhost:8080. The next three lines (starting with proxy_set_header) order Nginx to carry over some HTTP request headers that are needed for correct functioning of WebSockets, which code-server extensively uses.

      To test the validity of the configuration, run the following command:

      You’ll see the following output:

      Output

      nginx: the configuration file /etc/nginx/nginx.conf syntax is ok nginx: configuration file /etc/nginx/nginx.conf test is successful

      For the configuration to take effect, you’ll need to restart Nginx:

      • sudo systemctl restart nginx

      CentOS 7 comes with SELinux turned on, with a strict ruleset, which by default does not permit Nginx to connect to local TCP sockets. Nginx needs to do in order to serve as a reverse proxy for code-server. Run the following command to relax the rule permanently:

      • sudo setsebool httpd_can_network_connect 1 -P

      Then, in your browser, navigate to the domain you used for code-server. You will see the code-server login prompt.

      code-server login prompt

      code-server is asking you for your password. Enter the one you set in the previous step and press Enter IDE. You’ll now enter code-server and immediately see its editor GUI.

      code-server GUI

      You now have your code-server installation accessible at your domain. In the next step, you’ll secure it by applying a free Let’s Encrypt TLS certificate.

      Step 3 — Securing Your Domain

      In this section, you will secure your domain using a Let’s Encrypt TLS certificate, which you’ll provision using Certbot.

      To install the latest version of Certbot and its Nginx plugin, run the following command:

      • sudo yum install certbot python2-certbot-nginx

      To request certificates for your domain, run the following command:

      • sudo certbot --nginx -d code-server.your-domain

      In this command, you run certbot to request certificates for your domain—you pass the domain name with the -d parameter. The --nginx flag tells it to automatically change Nginx site configuration to support HTTPS. Remember to replace code-server.your-domain with your domain name.

      If this is your first time running Certbot, you’ll be asked to provide an email address for urgent notices and to accept the EFF’s Terms of Service. Certbot will then request certificates for your domain from Let’s Encrypt. It will then ask you if you’d like to redirect all HTTP traffic to HTTPS:

      Output

      Please choose whether or not to redirect HTTP traffic to HTTPS, removing HTTP access. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - 1: No redirect - Make no further changes to the webserver configuration. 2: Redirect - Make all requests redirect to secure HTTPS access. Choose this for new sites, or if you're confident your site works on HTTPS. You can undo this change by editing your web server's configuration. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - Select the appropriate number [1-2] then [enter] (press 'c' to cancel):

      It is recommended to select the second option in order to maximize security. After you input your selection, press ENTER.

      The output will be similar to this:

      Output

      IMPORTANT NOTES: - Congratulations! Your certificate and chain have been saved at: /etc/letsencrypt/live/code-server.your-domain/fullchain.pem Your key file has been saved at: /etc/letsencrypt/live/code-server.your-domain/privkey.pem Your cert will expire on ... To obtain a new or tweaked version of this certificate in the future, simply run certbot again with the "certonly" option. To non-interactively renew *all* of your certificates, run "certbot renew" - Your account credentials have been saved in your Certbot configuration directory at /etc/letsencrypt. You should make a secure backup of this folder now. This configuration directory will also contain certificates and private keys obtained by Certbot so making regular backups of this folder is ideal. - If you like Certbot, please consider supporting our work by: Donating to ISRG / Let's Encrypt: https://letsencrypt.org/donate Donating to EFF: https://eff.org/donate-le

      This means that Certbot has sucessfully generated TLS certificates and applied them to the Nginx configuration for your domain. You can now reload your code-server domain in your browser and observe a padlock to the left of the site address, which means that your connection is properly secured.

      Now you’ll make Certbot automatically renew the certificates before they expire. To run the renewal check daily, you’ll use cron, a standard system service for running periodic jobs. You direct cron by opening and editing a file called a crontab:

      This command will open the default crontab, which is currently an empty text file. Add the following line, then save and close it:

      crontab

      . . .
      15 3 * * * /usr/bin/certbot renew --quiet
      

      15 3 * * * will run the following command at 3:15 am every day—you can adapt this to any time.

      The renew command for Certbot will check all certificates installed on the system and update any that are set to expire in less than thirty days. --quiet tells Certbot not to output information or wait for user input.

      cron will now run this command daily. All installed certificates will be automatically renewed and reloaded when they have thirty days or less before they expire.

      Now that you have code-server accessible at your domain through a secured Nginx reverse proxy, you’re ready to review the user interface of code-server.

      Step 4 — Using the code-server Interface

      In this section, you’ll use some of the features of the code-server interface. Since code-server is Visual Studio Code running in the cloud, it has the same interface as the standalone desktop edition.

      On the left-hand side of the IDE, there is a vertical row of six buttons opening the most commonly used features in a side panel known as the Activity Bar.

      code-server GUI - Sidepanel

      This bar is customizable so you can move these views to a different order or remove them from the bar. By default, the first button opens the general menu in a dropdown, while the second view opens the Explorer panel that provides tree-like navigation of the project’s structure. You can manage your folders and files here—creating, deleting, moving, and renaming them as necessary. The next view provides access to a search and replace functionality.

      Following this, in the default order, is your view of the source control systems, like Git. Visual Studio code also supports other source control providers and you can find further instructions for source control work flows with the editor in this documentation.

      Git pane with context-menu open

      The debugger option on the Activity Bar provides all the common actions for debugging in the panel. Visual Studio Code comes with built-in support for the Node.js runtime debugger and any language that transpiles to Javascript. For other languages you can install extensions for the required debugger. You can save debugging configurations in the launch.json file.

      Debugger View with launch.json open

      The final view in the Activity Bar provides a menu to access available extensions on the Marketplace.

      code-server GUI - Tabs

      The central part of the GUI is your editor, which you can separate by tabs for your code editing. You can change your editing view to a grid system or to side-by-side files.

      Editor Grid View

      After creating a new file through the File menu, an empty file will open in a new tab, and once saved, the file’s name will be viewable in the Explorer side panel. Creating folders can be done by right clicking on the Explorer sidebar and clicking on New Folder. You can expand a folder by clicking on its name as well as dragging and dropping files and folders to upper parts of the hierarchy to move them to a new location.

      code-server GUI - New Folder

      You can gain access to a terminal by entering CTRL+SHIFT+`, or by clicking on Terminal in the upper menu dropdown, and selecting New Terminal. The terminal will open in a lower panel and its working directory will be set to the project’s workspace, which contains the files and folders shown in the Explorer side panel.

      You’ve explored a high-level overview of the code-server interface and reviewed some of the most commonly used features.

      Conclusion

      You now have code-server, a versatile cloud IDE, installed on your CentOS 7 server, exposed at your domain and secured using Let’s Encrypt certificates. You can now work on projects individually, as well as in a team-collaboration setting. Running a cloud IDE frees resources on your local machine and allows you to scale the resources when needed. For further information, see the Visual Studio Code documentation for additional features and detailed instructions on other components of code-server.

      If you would like to run code-server on your DigitalOcean Kubernetes cluster check out our tutorial on How To Set Up the code-server Cloud IDE Platform on DigitalOcean Kubernetes.



      Source link