Сегодня рассмотрим примеры для запуска команд или скрипта через SSH соединения. Научимся запускать наши команды/скрипты из одной рабочей станции Linux на другой удаленной Linux машине. Рассмотрим практические примеры использования мощного инструмента SSH в администрировании Linux.

Запуск команд через SSH

Если вы хотите удаленно запустить какую-либо команду на сервере через SSH, то нет ничего проще. Давайте рассмотрим пару примеров.

Узнайте аптайм удаленного сервера:

ssh root@10.5.5.1 'uptime'

Узнать проходит ли пинг на удаленном сервере до google DNS:

ssh root@10.5.5.1 'ping 8.8.8.8 -c 5'

Перезагрузить удаленную машину:

ssh root@10.5.5.1 'reboot'

Запуск нескольких команд через SSH

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

Запустить несколько команд на удаленном хосте по SSH:

ssh ПОЛЬЗОВАТЕЛЬ@СЕРВЕР 'КОМАНДА1; КОМАНДА2; КОМАНДА3'

можно и так:

ssh ПОЛЬЗОВАТЕЛЬ@СЕРВЕР << EOF
КОМАНДА1
КОМАНДА2
КОМАНДА3
EOF

Практические примеры использования SSH

Узнайте аптайм и сколько свободного места на диске:

ssh root@10.5.5.1 'uptime; df -h'

Сколько используется памяти и среднюю нагрузку:

ssh root@10.5.5.1 'free -m ; cat /proc/loadavg'

Узнать версию ядра, количество ядер CPU и сколько всего RAM:

ssh root@10.5.5.1 << EOF
uname -a
lscpu  | grep "^CPU(s)"
grep -i memtotal /proc/meminfo
EOF

SSH: Запуск Bash Скрипта

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

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

Эта задаче безусловно может быть выполнена и при этом довольно просто.

ssh root@10.5.5.1 'bash -s' < script.sh

Что если вы хотите выполнить сценарий с аргументом.

ssh root@10.5.5.1 'bash -s' < script.sh --argument

или

ssh root@10.5.5.1 'bash -s' < "script.sh --argument"

Если требуются привилегии sudo, то команда примет вид:

ssh root@10.5.5.1 'echo "passwords" | sudo -Sv && bash -s' < script.sh

• password — пароль для пользователя root на удаленной машине.
• script.sh — файл с вашим скриптом расположенный на станции с которой производите подключение.

Сегодня рассмотрим Копирование файлов c архивированием на лету по SSH протоколу, используя TAR.

Синтаксис команды tar

tar [-] A --catenate --concatenate | c --create | d --diff --compare | --delete | r --append | t --list | --test-label | u --update | x --extract --get [options] [pathname ...]

Копирование файлов через SSH c архивированием на лету.

Выполним следующею команду:

cd /local/dir; tar cf - . | ssh server "cd /destination/dir; tar xf -"

Теперь разберем, что же происходит в коде:

1. cd /local/dir; – осуществляется переход к папке /local/dir, которая будет архивироваться;
2. tar cf - . – утилита tar выполняет следующие операции:
   • -c говорит о том, что нужно создать новый архив;
   • -f говорит о том, что используется архивный файл (или устройство);
   • парамерт - говорит о том, что tar должен использовать стандартный вывод, а не записывать данные в файл
   • параметр . говорит о том, что архивироваться будет папка, в которой находится пользователь, и из которой выполняется команда tar (в данном случае это папка /local/dir из п.1)
3. | ssh означает, что вывод утилиты tar будет передан в ssh-исполняемую следом команду;
4. server обычно имеет вид [имя_пользователя]@[адрес_сервера] и означает, что команда будет выполнена на удаленном сервере;
5. "cd /destination/dir; tar xf -" – в кавычки заключена последовательность команд для выполнения на удаленном сервере и в SSH вводится именно в кавычках, разберем ее в следующем пункте;
6. cd /destination/dir; – осуществляется переход к папке, куда будут разархивированы файлы;
7. tar xf - утилита tar выполняет следующие операции:
   • -x говорит о том, что будет происходить распаковка;
   • -f говорит о том, что используется архивный файл (или устройство);
   • параметр  -  говорит о том, что tar должен использовать не файл, а стандартный вывод.

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

1. параметр -v сообщает tar действовать вербально, т.е. отображая, либо получая исчерпывающую информацию о файлах в процессе обработки;
2. -z – параметр сообщает tar использовать программу сжатия, когда работа будет вестись с файлами;
   или
   -j – параметр сообщает tar выполнять чтение или запись архивов, используя компрессор bzip2.

[endtxt]

RSS

Как увеличить время сессий SSH на Linux. Сегодня в статье поговорим о настройке увеличения время вашей сессии SSH на операционных системах Linux.

В качестве примера я буду использовать Ubuntu Server, но вся инструкция подойдет и для остальных дистрибутивов Linux.

Как увеличить время сессий SSH на Linux

И так, открываем консоль/терминал и подключаемся к вашему серверу. Ну а далее по моему мануалу:

в конфигурационном файле:

sudo nano /etc/ssh/sshd_config

 находим там строки и снимаем комментарий “#“:

TCPKeepAlive yes
ClientAliveInterval 120
ClientAliveCountMax 10

• TCPKeepAlive — установлен в «yes», значит сервер будет периодически пинговать клиента, проверяя жив ли он.
• ClientAliveInterval — задает интервал пинга для проверки состояния клиента (в секундах). Параметр работает только для протокола версии 2 (Protocol 2).
• ClientAliveCountMax — сколько делать пингов всего.

Таким образом в моем примере таймаут сессии будет равен 10*120/60 = 20 минут, т.е. делать всего 10 пингов через каждые 120 сек.

После изменения настроек не забудьте перезапустить сервис ssh:

sudo service ssh restart

[endtxt]

RSS

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

Установка SSH

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

sudo apt install ssh

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

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

sudo service ssh stop|start|restart

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Port, ListenAddress и AddressFamily

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

[endtxt]