One place for hosting & domains

      настройка

      Настройка аутентификации на базе ключей SSH на сервере Linux


      Введение

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

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

      Как работают ключи SSH?

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

      Хотя пароли отправляются на сервер в безопасном режиме, обычно они недостаточно сложные и длинные, чтобы обеспечить надежную защиту против упорных злоумышленников, совершающих многократные атаки. Вычислительная мощность современных систем и автоматизированные скрипты позволяют достаточно легко взломать учетную запись методом прямого подбора пароля. Хотя существуют и другие методы усиления мер безопасности (fail2ban и т. д.), ключи SSH показали себя надежной и безопасной альтернативой.

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

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

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

      Открытый ключ выгружается на удаленный сервер, на который вы хотите заходить, используя SSH. Этот ключ добавляется в специальный файл ~/.ssh/authorized_keys в учетной записи пользователя, которую вы используете для входа.

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

      Создание ключей SSH

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

      Для этого мы можем использовать специальную утилиту ssh-keygen, которая входит в стандартный набор инструментов OpenSSH. По умолчанию она создает пару 2048-битных ключей RSA, что подходит для большинства сценариев использования.

      Сгенерируйте на локальном компьютере пару ключей SSH, введя следующую команду:

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

      Утилита предложит вам выбрать место размещения генерируемых ключей. По умолчанию ключи хранятся в каталоге ~/.ssh внутри домашнего каталога вашего пользователя. Закрытый ключ будет иметь имя id_rsa, а соответствующий открытый ключ будет иметь имя id_rsa.pub.

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

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

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

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

      Created directory '/home/username/.ssh'.
      Enter passphrase (empty for no passphrase):
      Enter same passphrase again:
      

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

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

      • Закрытый ключ SSH (защищенная паролем часть) никогда не доступен через сеть. Парольная фраза используется только для расшифровки ключа на локальном компьютере. Это означает, что парольную фразу нельзя взломать через сеть методом прямого подбора.
      • Закрытый ключ хранится в каталоге с ограниченным доступом. Клиент SSH не принимает закрытые ключи, хранящиеся в каталогах, доступ к которым не ограничен. У самого ключа могут быть ограниченные разрешения (чтение и запись доступны только владельцу). Это означает, что другие пользователи системы не смогут создать уязвимость.
      • Для попытки взлома защищенного парольной фразой закрытого ключа SSH злоумышленнику уже необходим доступ к системе. Это означает, что у него уже должен быть доступ к учетной записи пользователя или учетной записи root. Если вы окажетесь в такой ситуации, парольная фраза может помешать злоумышленнику сразу же попасть на ваши другие серверы. Это может дать вам достаточно времени, чтобы создать и внедрить новую пару ключей SSH и запретить доступ с взломанным ключом.

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

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

      Your identification has been saved in /home/username/.ssh/id_rsa.
      Your public key has been saved in /home/username/.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 для входа в систему.

      Как встроить открытый ключ при создании сервера

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

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

      Встраивание ключа SSH

      Если вы уже добавили файл открытого ключа в учетную запись DigitalOcean, вы сможете выбрать данную опцию (в примере выше указаны два существующих ключа: “Work key” и “Home key”). Чтобы встроить существующий ключ, нажмите на него, чтобы его выделить. Вы можете встроить несколько ключей на один сервер:

      Выбор ключа SSH

      Если в вашу учетную запись еще не выгружен открытый ключ SSH, или если вы хотите добавить новый ключ, нажмите кнопку “+ Add SSH Key”. При этом будет открыто диалоговое окно:

      Диалог ключа SSH

      Вставьте содержимое открытого ключа SSH в поле “SSH Key content”. Если вы сгенерировали ключи, используя указанный выше метод, вы можете получить содержимое открытого ключа на локальном компьютере, введя следующую команду:

      cat ~/.ssh/id_rsa.pub
      
      ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDNqqi1mHLnryb1FdbePrSZQdmXRZxGZbo0gTfglysq6KMNUNY2VhzmYN9JYW39yNtjhVxqfW6ewc+eHiL+IRRM1P5ecDAaL3V0ou6ecSurU+t9DR4114mzNJ5SqNxMgiJzbXdhR+j55GjfXdk0FyzxM3a5qpVcGZEXiAzGzhHytUV51+YGnuLGaZ37nebh3UlYC+KJev4MYIVww0tWmY+9GniRSQlgLLUQZ+FcBUjaqhwqVqsHe4F/woW1IHe7mfm63GXyBavVc+llrEzRbMO111MogZUcoWDI9w7UIm8ZOTnhJsk7jhJzG2GpSXZHmly/a/buFaaFnmfZ4MYPkgJD username@example.com
      

      Вставьте это значение в более крупное поле целиком. В поле “Comment (optional)” вы можете выбрать ярлык для данного ключа. Этот ярлык будет отображаться как имя ключа в интерфейсе DigitalOcean:

      Новый ключ SSH

      При создании дроплета выбранные вами открытые ключи SSH будут помещены в файл ~/.ssh/authorized_keys в учетной записи пользователя root. Это позволит вам входить на сервер с компьютера, используя ваш закрытый ключ.

      Как скопировать открытый ключ на ваш сервер

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

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

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

      Самый удобный способ скопировать открытый ключ на существующий сервер — использовать утилиту под названием ssh-copy-id. Поскольку этот метод очень простой, если он доступен, его рекомендуется использовать.

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

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

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

      ssh-copy-id username@remote_host
      

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

      The authenticity of host '111.111.11.111 (111.111.11.111)' 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. Когда ключ будет найден, вам будет предложено ввести пароль учетной записи удаленного пользователя:

      /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@111.111.11.111's password:
      

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

      Вы получите следующий результат:

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

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

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

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

      Для выполнения этой задачи мы можем вывести содержимое нашего открытого ключа SSH на локальный компьютер и передать его через соединение SSH на удаленный сервер. С другой стороны, мы можем подтвердить существование каталога ~/.ssh в используемой нами учетной записи и вывести переданные данные в файл authorized_keys в этом каталоге.

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

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

      cat ~/.ssh/id_rsa.pub | ssh username@remote_host "mkdir -p ~/.ssh && cat >> ~/.ssh/authorized_keys"
      

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

      The authenticity of host '111.111.11.111 (111.111.11.111)' 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, чтобы продолжить.

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

      username@111.111.11.111's password:
      

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

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

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

      Содержимое файла id_rsa.pub нужно будет каким-то образом добавить в файл ~/.ssh/authorized_keys на удаленном компьютере.

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

      cat ~/.ssh/id_rsa.pub
      

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

      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
      

      Откройте удаленный хост, используя любой доступный метод. Например, если вы используете дроплет DigitalOcean Droplet как сервер, вы можете выполнить вход, используя веб-консоль на панели управления:

      Доступ к консоли DigitalOcean

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

      mkdir -p ~/.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

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

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

      ssh username@remote_host
      

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

      The authenticity of host '111.111.11.111 (111.111.11.111)' 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, чтобы продолжить.

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

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

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

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

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

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

      sudo nano /etc/ssh/sshd_config
      

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

      PasswordAuthentication no
      

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

      На компьютерах под управлением Ubuntu или Debian можно использовать следующую команду:

      sudo service ssh restart
      

      На компьютерах под управлением CentOS/Fedora этот демон носит имя sshd:

      sudo service sshd restart
      

      Выполнив этот шаг, вы успешно перенастроили демон SSH так, чтобы он реагировал только на ключи SSH.

      Заключение

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



      Source link

      Считывание и настройка переменных оболочки и окружения в Linux


      Введение

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

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

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

      Как работают окружение и переменные окружения

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

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

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

      KEY=value1:value2:...
      

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

      KEY="value with spaces"
      

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

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

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

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

      Вывод переменных оболочки и окружения

      Каждый сеанс оболочки отслеживает собственные переменные оболочки и окружения. Мы можем получить доступ к этим переменным разными способами.

      Мы можем просмотреть список всех наших переменных окружения с помощью команд env или printenv. В состоянии по умолчанию они должны работать одинаково:

      Output

      SHELL=/bin/bash TERM=xterm USER=demouser LS_COLORS=rs=0:di=01;34:ln=01;36:mh=00:pi=40;33:so=01;35:do=01;35:bd=40;33;01:cd=40;33;01:or=40;31;01:su=37;41:sg=30;43:ca:... MAIL=/var/mail/demouser PATH=/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games PWD=/home/demouser LANG=en_US.UTF-8 SHLVL=1 HOME=/home/demouser LOGNAME=demouser LESSOPEN=| /usr/bin/lesspipe %s LESSCLOSE=/usr/bin/lesspipe %s %s _=/usr/bin/printenv

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

      Output

      /bin/bash

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

      • env VAR1="value" command_to_run command_options

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

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

      Эти команды отображают переменные окружения, но как мы можем просмотреть переменные оболочки?

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

      Output

      BASH=/bin/bash BASHOPTS=checkwinsize:cmdhist:expand_aliases:extglob:extquote:force_fignore:histappend:interactive_comments:login_shell:progcomp:promptvars:sourcepath BASH_ALIASES=() BASH_ARGC=() BASH_ARGV=() BASH_CMDS=() . . .

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

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

      Мы можем очистить вывод, указав, что команда set должна работать в режиме POSIX, которые не подразумевает вывода функций оболочки. Также эту команду можно выполнить в субоболочке, чтобы не менять наше текущее окружение:

      Она будет выводить список всех определенных переменных окружения и оболочки.

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

      • comm -23 <(set -o posix; set | sort) <(env | sort)

      Он все равно будет включать несколько переменных окружения из-за того, что команда set выводит значения в кавычках, а команды printenv и env не помещают строковые значения в кавычки.

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

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

      Стандартные переменные окружения и оболочки

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

      • SHELL: описывает оболочку, где будет выполняться интерпретация любых команд, которые вы вводите. В большинстве случаев по умолчанию будет использоваться bash, но другие значения можно установить, если вы предпочитаете использовать другие варианты.
      • TERM: указывает тип терминала, который будет использоваться при запуске оболочки. Различные аппаратные терминалы могут имитироваться согласно различным операционным требованиям. Скорее всего вам не придется думать об этом.
      • USER: текущий пользователь, для которого выполнен вход.
      • PWD: текущий рабочий каталог.
      • OLDPWD: предыдущий рабочий каталог. Эта информация сохраняется оболочкой, чтобы выполнять переход к предыдущему каталогу с помощью команды cd -.
      • LS_COLORS: цветовые коды, которые используются для опционального добавления цветного вывода для команды ls. Эта команда используется для выделения различных типов файлов и предоставления пользователю большего количества информации при беглом просмотре.
      • MAIL: путь к почтовому ящику текущего пользователя.
      • PATH: список каталогов, которые система будет проверять при поиске команд. Когда пользователь вводит команду, система будет проверять каталоги в указанном здесь порядке при поиске исполняемого файла.
      • LANG: текущий язык и настройки локализации, включая кодирование символов.
      • HOME: домашний каталог текущего пользователя.
      • _: последняя предыдущая выполненная команда.

      Помимо этих переменных окружения существует ряд переменных оболочки, с которыми вы будете часто встречаться:

      • BASHOPTS: список опций, которые использовались при исполнении bash. Это может быть полезно, если вам нужно узнать, будет ли окружение оболочки работать так, как вы хотите.
      • BASH_VERSION: используемая версия bash, описанная в понятной человеку форме.
      • BASH_VERSINFO: версия bash в машиночитаемом виде.
      • COLUMNS: количество столбцов, используемых для отображения вывода на экране.
      • DIRSTACK: стек каталогов, доступных с помощью команд pushd и popd.
      • HISTFILESIZE: количество строк истории команды, хранящейся в файле.
      • HISTSIZE: количество строк истории команды, допустимое для хранения в памяти.
      • HOSTNAME: имя хоста компьютера в настоящий момент.
      • IFS: внутренний разделитель поля для выделения ввода в командной строке. По умолчанию используется пробел.
      • PS1: определение первичного приглашения ввода. Эта опция используется для определения того, как будет выглядеть ваше приглашение при запуске сеанса оболочки. PS2 используется для объявления вторичного приглашения для случаев, когда команда использует несколько строк.
      • SHELLOPTS: опции оболочки, которые можно задать с помощью опции set.
      • UID: уникальный идентификатор текущего пользователя.

      Настройка переменных оболочки и окружения

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

      Создание переменных оболочки

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

      Здесь мы использовали кавычки, поскольку значение нашей переменной содержит пробел. Кроме того, мы использовали одинарные кавычки, потому что восклицательный знак — это специальный символ оболочки bash, который обычно использует историю bash, если не воспользоваться экранированием или одинарными кавычками.

      Теперь у нас есть переменная. Эта переменная доступна в нашем текущем сеансе, но она не будет передаваться дочерним процессам.

      Мы можем увидеть это, выполнив с помощью команды grep поиск новой переменной в выводе set:

      Output

      TEST_VAR='Hello World!'

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

      Вывод должен быть пустой.

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

      Output

      Hello World!

      Как вы можете видеть, сослаться на значение переменной можно, добавив перед ее именем знак $. Оболочка в результате понимает, что при обнаружении этой конструкции следует подставить значение переменной.

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

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

      Вернитесь к нашей оригинальной оболочке, введя exit:

      Создание переменных окружения

      Теперь давайте превратим нашу переменную оболочки в переменную окружения. Мы можем сделать это с помощью экспорта переменной. Команда для выполнения этой задачи имеет соответствующее название:

      Наша переменная будет превращена в переменную окружения. Мы можем убедиться в этом, снова проверив наш список переменных окружения:

      Output

      TEST_VAR=Hello World!

      В этот раз наша переменная отображается в списке. Давайте повторим наш эксперимент с дочерней оболочкой:

      Output

      Hello World!

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

      • export NEW_VAR="Testing export"

      Проверьте, что переменная успешно была экспортирована в окружение:

      Output

      NEW_VAR=Testing export

      Теперь давайте вернемся в нашу оригинальную оболочку:

      Давайте посмотрим, доступна ли наша новая переменная:

      Ничего не возвращается.

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

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

      Понижение и сброс переменных

      Наша переменная TEST_VAR все еще определена в качестве переменной окружения. Мы можем превратить ее обратно в переменную оболочки, введя следующую команду:

      Она больше не является переменной окружения:

      Однако она все еще сохранила статус переменной оболочки:

      Output

      TEST_VAR='Hello World!'

      Если мы хотим полностью сбросить переменную, как оболочки, так и окружения, мы можем сделать это с помощью команды unset:

      Мы можем убедиться, что эта переменная больше не задана:

      Ничего не возвращается, потому что переменная была сброшена.

      Настройка переменных окружения во время входа

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

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

      Разница между сеансами оболочки входа, без входа, интерактивными и неинтерактивными сеансами

      Оболочка bash считывает разные файлы конфигурации в зависимости от того, как запускается сеанс.

      Одно из различий между сеансами заключается в том, что оболочка запускается в рамках сеанса входа или без входа.

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

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

      Еще одним отличием, которое можно отметить, является интерактивный или неинтерактивный характер сеанса оболочки.

      Интерактивный сеанс оболочки — это сеанс оболочки, прикрепленный к терминалу. Неинтерактивный сеанс оболочки не прикреплен к сеансу терминала.

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

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

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

      Сеанс, запускаемый в виде сеанса входа, будет считывать данные конфигурации сначала из файла /etc/profile. Затем он будет искать первый файл конфигурации сеанса входа в домашнем каталоге пользователя, чтобы получить данные конфигурации для конкретного пользователя.

      Сеанс считывает первый из файлов ~/.bash_profile, ~/.bash_login и ~/.profile, который ему удается найти, и не считывает остальные файлы.

      В отличие от этого сеанс, определенный в оболочке без входа, будет читать файл /etc/bash.bashrc и затем использовать файл ~/.bashrc конкретного пользователя для создания окружения.

      Неинтерактивные оболочки считывают значение переменной окружения BASH_ENV и указанный в нем файл для определения нового окружения.

      Реализация переменных окружения

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

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

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

      Чаще всего мы будем настраивать переменные окружения для конкретного пользователя, и наши настройки, как правило, будут доступны в оболочках как со входом, так и без входа. Это означает, что лучше всего использовать для определения этих переменных файл ~/.bashrc.

      Откройте этот файл:

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

      Любые новые переменные окружения можно добавить в любое место файла ~/.bashrc при условии, что они не помещаются внутри другой команды или цикла. Сохраните и закройте файл. В следующий раз при запуске сеанса оболочки ваше объявление переменной окружения будет считываться и передаваться в среду оболочки. Вы можете заставить ваш текущий сеанс считать файл прямо сейчас, введя следующую команду:

      Если вам потребуется задать общесистемные переменные, вы можете рассмотреть возможность их добавления в файлы /etc/profile, /etc/bash.bashrc или /etc/environment.

      Заключение

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

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

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



      Source link

      Настройка проекта Node с помощью Typescript


      Введение

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

      Разработчики, переходящие на JavaScript с других языков, часто жалуются на отсутствие мощного статического типирования, но TypeScript позволяет устранить этот недостаток.

      TypeScript — это типовой (опциональный) супернабор JavaScript, который может помочь со сборкой и управлением крупномасштабными проектами JavaScript. Его можно представить как JavaScript с дополнительными возможностями, включая мощное статическое типирование, компиляцию и объектно-ориентированное программирование.

      Примечание. С технической точки зрения TypeScript является супернабором JavaScript, и это означает, что весь код JavaScript является корректным кодом TypeScript.

      Перечислим некоторые преимущества использования TypeScript:

      1. Опциональная статическая типизация.
      2. Логическая обработка типов.
      3. Возможность использования интерфейсов.

      В этом учебном модуле вы настроите проект Node с помощью TypeScript. Вы создадите приложение Express с помощью TypeScript и преобразуете его в компактный и надежный код JavaScript.

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

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

      Шаг 1 — Инициализация проекта npm

      Для начала создайте новую папку с именем node_project и перейдите в этот каталог.

      • mkdir node_project
      • cd node_project

      Затем инициализируйте его как проект npm:

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

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

      Шаг 2 — Установка зависимостей

      Следующий шаг после инициализации базового проекта npm — установить зависимости, требующиеся для запуска TypeScript.

      Запустите следующие команды из каталога вашего проекта для установки зависимостей:

      • npm install -D typescript@3.3.3
      • npm install -D tslint@5.12.1

      Флаг -D — сокращенное обозначение опции: --save-dev. Более подробную информацию об этом флаге можно найти в документации npmjs.

      Пришло время установить платформу Express:

      • npm install -S express@4.16.4
      • npm install -D @types/express@4.16.1

      Вторая команда устанавливает типы Express для поддержки TypeScript. Типы в TypeScript — это файлы, которые обычно имеют расширение .d.ts. Файлы используются для предоставления типовой информации об API, в данном случае структуры Express.

      Этот пакет требуется, потому что TypeScript и Express являются независимыми пакетами. Без пакета @types/express у TypeScript нет способа узнавать типы классов Express.

      Шаг 3 — Настройка TypeScript

      В этом разделе мы настроим TypeScript и проверку соблюдения стандартов для TypeScript. TypeScript использует файл tsconfig.json для настройки опций компилятора для проекта. Создайте файл tsconfig.json в корне каталога проекта и вставьте следующий фрагмент кода:

      tsconfig.json

      {
        "compilerOptions": {
          "module": "commonjs",
          "esModuleInterop": true,
          "target": "es6",
          "moduleResolution": "node",
          "sourceMap": true,
          "outDir": "dist"
        },
        "lib": ["es2015"]
      }
      

      Давайте рассмотрим некоторые ключи во фрагменте кода JSON выше:

      • module: указывает метод генерирования кода модуля. Node использует commonjs.
      • target: указывает уровень языка на выходе.
      • moduleResolution: помогает компилятору определить, на что ссылается импорт. Значение node имитирует механизм разрешения модуля Node.
      • outDir: Это место для вывода файлов .js после транспиляции. В этом учебном модуле мы сохраним его как dist.

      В качестве альтернативы созданию и заполнения файла tsconfig.json вручную можно запустить следующую команду:

      Эта команда сгенерирует файл tsconfig.json с правильными комментариями.

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

      Теперь вы можете настроить проверку соответствия стандартам кода TypeScript для этого проекта. Откройте в терминале корневой каталог вашего проекта, который установлен в этом учебном модуле как node_project, и запустите следующую команду для генерирования файла tslint.json:

      • ./node_modules/.bin/tslint --init

      Откройте сгенерированный файл tslint.json и добавьте соответствующее правило no-console:

      tslint.json

      {
        "defaultSeverity": "error",
        "extends": ["tslint:recommended"],
        "jsRules": {},
        "rules": {
          "no-console": false
        },
        "rulesDirectory": []
      }
      

      По умолчанию модуль проверки TypeScript предотвращает использование отладки через команды консоли, поэтому нужно явно предписать ему отключить правило по умолчанию no-console.

      Шаг 4 — Обновление файла package.json

      Сейчас вы можете запускать функции в терминале по отдельности или создать скрипт npm для их запуска.

      На этом шаге мы создадим скрипт start, который выполнит компиляцию и транспиляцию кода TypeScript, а затем запустит полученное приложение .js.

      Откройте файл package.json и обновите его соответствующим образом:

      package.json

      {
        "name": "node-with-ts",
        "version": "1.0.0",
        "description": "",
        "main": "dist/app.js",
        "scripts": {
          "start": "tsc && node dist/app.js",
          "test": "echo "Error: no test specified" && exit 1"
        },
        "author": "",
        "license": "ISC",
        "devDependencies": {
          "@types/express": "^4.16.1",
          "tslint": "^5.12.1",
          "typescript": "^3.3.3"
        },
        "dependencies": {
          "express": "^4.16.4"
        }
      }
      

      В приведенном выше фрагменте кода мы обновили путь main и добавили команду start в раздел scripts. Если посмотреть на команду start, вы увидите, что вначале запускается команда tsc, а затем — команда node. При этом будет проведена компиляция, и сгенерированный вывод будет запущен с помощью node.

      Команда tsc предписывает TypeScript скомпилировать приложение и поместить сгенерированный вывод .js в указанном каталоге outDir, как указано в файле tsconfig.json.

      Шаг 5 — Создание и запуск базового сервера Express

      Теперь TypeScript и модуль проверки настроены, и мы можем приступить к сборке модуля Node Express Server.

      Вначале создайте папку src в корневом каталоге вашего проекта:

      Затем создайте файл с именем app.ts:

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

      ├── node_modules/
      ├── src/
        ├── app.ts
      ├── package-lock.json
      ├── package.json
      ├── tsconfig.json
      ├── tslint.json
      

      Откройте файл app.ts в предпочитаемом текстовом редакторе и вставьте следующий фрагмент кода:

      src/app.ts

      import express from 'express';
      
      const app = express();
      const port = 3000;
      app.get('/', (req, res) => {
        res.send('The sedulous hyena ate the antelope!');
      });
      app.listen(port, err => {
        if (err) {
          return console.error(err);
        }
        return console.log(`server is listening on ${port}`);
      });
      

      Приведенный выше код создает сервер Node, прослушивающий порт 3000 на предмет запросов. Запустите приложение с помощью следующей команды:

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

      Output

      • server is listening on 3000

      Теперь вы можете открыть в браузере адрес http://localhost:3000 и увидите следующее сообщение:

      Output

      • The sedulous hyena ate the antelope!

      Окно браузера с сообщением: Усердная гиена съела антилопу!

      Откройте файл dist/app.js, и вы найдете в нем транспилированную версию кода TypeScript:

      dist/app.js

      "use strict";
      
      var __importDefault = (this && this.__importDefault) || function (mod) {
          return (mod && mod.__esModule) ? mod : { "default": mod };
      };
      Object.defineProperty(exports, "__esModule", { value: true });
      const express_1 = __importDefault(require("express"));
      const app = express_1.default();
      const port = 3000;
      app.get('/', (req, res) => {
          res.send('The sedulous hyena ate the antelope!');
      });
      app.listen(port, err => {
          if (err) {
              return console.error(err);
          }
          return console.log(`server is listening on ${port}`);
      });
      
      //# sourceMappingURL=app.js.map
      

      Вы успешно настроили проект Node для использования TypeScript.

      Заключение

      В этом учебном модуле вы узнали, почему TypeScript полезен для написания надежного кода JavaScript. Также вы узнали о некоторых преимуществах работы с TypeScript.

      Наконец, вы настроили проект Node с использованием структуры Express, но скомпилировали и запустили проект с помощью TypeScript.



      Source link