SSH - (Secure Shell — «безопасная оболочка») - сетевой протокол прикладного уровня, позволяющий производить удалённое управление операционной системой и туннелирование TCP- соединений (например, для передачи файлов). Далее рассматривается OpenSSH (демон sshd) альтернатива проприетарного ПО от SSH Communications Security. OpenSSH (открытая безопасная оболочка) — набор программ, предоставляющих шифрование сеансов связи по компьютерным сетям с использованием протокола SSH.

Какой порт у SSH? SSH сервер обычно прослушивает соединения на TCP -порту 22.

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

ssh root@your_server_ip

И делаем свое черное дело список здесь список здесь.

Потом вы подумали, что это очень легко работать под правами root, нужно усложнить себе работу и ввести новую сущность - бесправного пользователя и обязательно дать ему имя как ваш ник в Одноглазиках (сорри, вы продвинутые тогда берите из VK)! Чтобы когда вы в логах (/var/log/auth.log) увидите как хакеры пробуют взломать вашего демона SSH и не догадались о вашем нике из Одноглазиков - это победа!! Вы можете гордиться вашим ником в социальных сетях - его никто не знает. И значит можно пароль поставить как на домашний роутер admin. Я шутил!

По делу: не работайте от root, пожалуйста!

Пример подключения к удаленному нестандартному серверу, который настраивал нестандартный админ, для этого используем ключ -p задания порта и ключ -i для задания ssh ключа (в случае беспарольной аутентификации):

ssh -p 1861 -i  id_divinity syperadmin@superserver.com

Cоздадим пользователя с правами которого будем работать с сервером, для примера создается новый пользователь с именем remuserbak, но вы должны заменить его на имя пользователя, которое вам нравится:

root@vps:~# adduser remuserbak

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

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

На втором шаге был создан пользователь remuserbak, но администрировать с ним сервер нельзя, ибо нет у него прав таких! Придется дать ему возможность становится рутом, как говорится с чего начали - тем и закончили.

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

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

От имени пользователя root выполните команду usermod, чтобы добавить нового пользователя в группу sudo (замените имя пользователя своим новым пользователем:

root@vps:~# usermod -aG sudo remuserbak

Проверим командой id добавился ли пользователь в группу sudo

root@vps:~# id remuserbak
uid=1000(remuserbak) gid=1000(remuserbak) groups=1000(remuserbak),27(sudo)

Теперь, когда вы войдя в систему как обычный пользователь remuserbak, можете ввести sudo перед командами, чтобы выполнять действия с привилегиями суперпользователя (root).

После установки сервера SSH, первым делом исправить файл sshd_config. В нем запретить удалённый доступ пользователя root и разрешить доступ только для доверенных пользователей. Настраиваем от непривилегированного пользователя, используя sudo.

Первое действие перед правкой любого файла - это бекап этого файла, делаем:

remuserbak@vps:~$ sudo cp /etc/ssh/sshd_config /etc/ssh/sshd_config.orig
[sudo] password for remuserbak:

Посмотреть текущее настройки демона ssh

sudo sshd -T

Отключение SSH-логин для пользователя root, используя параметр PermitRootLogin no.

remuserbak@vps:~$ sudo nano /etc/ssh/sshd_config
 
# Authentication:
PermitRootLogin no # запретить удалённый доступ для root
AllowUsers remuserbak user1 user2 # список пользователей, которым разрешён доступ по SSH

После внесения изменений в sshd_config - перегружаем демона SSH.

$ sudo systemctl restart ssh.service
или
$ sudo service sshd restart

При таком способе перезагрузки демона SSH текущее соединение не прерывается. Теперь при попытке залогинеться с пользователем root, в логах вы увидите запись:

User root from 222.187.238.57 not allowed because not listed in AllowUsers

Всё, у вас демон SSH минимально защищен!

Дополнительные параметры sshd_config, которые можно менять, под ваши задачи и условия, но не делайте это без нужды и предварительно изучите руководство man 5 sshd_config

• LoginGraceTime 120: Сервер отключается по истечении этого времени, если пользователю не удалась регистрация в системе. Если стоит значение 0, то время ожидания не ограничено. Значение по умолчанию - 120 секунд.
• StrictModes yes: Проверять наборы прав доступа и принадлежность конфигурационных файлов и домашнего каталога пользователя перед разрешением регистрации в системе. Это рекомендуется выполнять потому, что новички иногда оставляют свои каталоги или файлы доступными для записи всем. Значение по умолчанию - yes.
• AddressFamily inet: Семейство адресов которое должна использовать служба sshd, допустимые значения: any, inet (только IPv4) и inet6 (только IPv6). Значение по умолчанию - any.
• Port 22: Порт, на котором следует ожидать запросы на ssh соединение. Значение по умолчанию - 22, рекомендуется ставить значение нового порта выше 1024 так как значение ниже уже зарезервированы (например 2007). Внимание! При подключение к нестандартному порту используйте ключ -p для задания порта.
• PubkeyAuthentication yes — включение авторизации по ssh-ключам.
• PermitEmptyPasswords no — запрет использования пустых паролей.
• PasswordAuthentication no — запрет авторизации по паролю в принципе. (не меняйте, пока не убедитесь, что авторизация по SSH-ключам работает)
• ListenAddress XXX.XXX.XXX.XXX — указываем конкретный IP, на котором будет располагаться служба. По умолчанию на всех.

• fail2ban
• Руководство по iptables: Настройка и оптимизация фаервола Linux
• iptables для начинающих: Простое управление брандмауэром с UFW

man sshd раздел SSHRC рассказывает об использовании файла /etc/ssh/sshrc. Если этот файл создан с правами на выполнение, то он будет запускать после успешного логина пользователя, но до запуска оболочки пользователя, например bash.

Подробно на примерах в статье Пример использования файла sshrc для отслеживания действий пользователя в текущей сессии ssh.

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

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

Вместо использования паролей, с помощью ssh-keygen можно создать ключи DSA или RSA, которыми пользователи могут аутентифицироваться. Ключи RSA являются наиболее широко используемыми и создаются по умолчанию. Немножко терминов:

• RSA (Rivest-Shamir-Adleman) является одним из первых криптосистемы с открытым ключом и широко используется для безопасной передачи данных. Безопасность основана на целочисленной факторизации, поэтому безопасный RNG никогда не нужен. По сравнению с DSA RSA быстрее проверяет подпись, но медленнее для генерации.
• DSA (Digital Signature Algorithm — алгоритм цифровой подписи) является федеральным стандартом обработки информации для цифровых подписей. Безопасность зависит от дискретной логарифмической проблемы. По сравнению с RSA DSA быстрее генерирует подпись, но медленнее для проверки.

Итак: делаем ssh-ключи для беспарольной авторизации.

$ ssh-keygen -b 2048 -t rsa -f ~/.ssh/work_key -C "Key for Work stuff"
$ ssh-keygen -b 2048 -t rsa -f ~/.ssh/myvps -C "Key for vps"

Мы обзавелись ключами, раскидали их публичные части (pub) в authorized_keys соответствующих удаленных хостов (например командой ssh-copy-id):

ssh-copy-id -i work_key.pub USER@HOST

Для включения аутентификации по ключам, публичный ключ (расширение .pub) должен быть помещен в файл ~/.ssh/authorized_keys на удаленном компьютере, например так:

cat ~/.ssh/id_rsa.pub | ssh root@ip-адрес-сервера 'cat >> ~/.ssh/authorized_keys'

или второй способ копирования более простой и правильный, но не передающий в отличии от первого способа, что происходит в реальности

ssh-copy-id -i .ssh/id_rsa.pub remuserbak@xxx.xxx.xxx.xxx

Теперь определим с каким ключём куда ходить:

создаем конфиг

$ touch ~/.ssh/config
$ chmod 600 ~/.ssh/config

с содержимым, например

IdentityFile ~/.ssh/work_key
IdentityFile ~/.ssh/myvps

Host *.company.org
  IdentityFile ~/.ssh/work_key
  User workusername
 
Host 127.65.43.21
  IdentityFile ~/.ssh/myvps
  User bliznezz
  Port 22322

теперь будут подтягиваться соответствующие настройки. Конечно, при подключении к удаленному серверу, который не определен в ~/.ssh/config - будет по умолчанию, или стандартные ключи ~/.ssh/id_rsa, или логин/пароль если иначе не прописано в конфиге.

Утилита ssh-keygen служит для генерация, преобразование и управление ключами. По умолчанию генерирует RSA ключ (ключ -t позволяет задать тип ключа). При генерации запрашивается парольная фраза для 3DES (рекомендуется 10-30 символов). Забытую парольную фразу восстановить невозможно. Число бит по умолчанию - 1024 (минимум - 512 бит, увеличение длины ключа замедляет работу). Комментарий по умолчанию - имя-пользователя@имя-хоста. Имя файла для хранения публичного ключа образуется из имени файла для частного ключа добавлением суффикса ".pub". Ключ хоста должен иметь пустую парольную фразу.

• ssh-keygen [-t rsa1|dsa|rsa] [-b бит] [-N парольная-фраза] [-C комментарий] [-f имя-файла-записи] [-q]
• ssh-keygen -c [-P парольная-фраза] [-C комментарий] [-f файл-с-ключами] - изменить комментарий
• ssh-keygen -e [-f файл-с-ключами] - читает приватный или публичный ключ в формате OpenSSH и преобразует его в формат SECSH для экспорта в другие реализации SSH
• ssh-keygen -i [-f файл-с-ключами] - читает приватный или публичный ключ в формате SSH2 или SECSH и преобразует его в формат OpenSSH
• ssh-keygen -l [-f файл-с-ключами] - показать fingerprint
• ssh-keygen -B [-f файл-с-ключами] - показать bubblebabble digest
• ssh-keygen -p [-P старая-парольная-фраза] [-N новая-парольная-фраза] [-f файл-с-ключами] - изменить парольную фразу
• ssh-keygen -y [-f файл-с-ключами] - читает приватный OpenSSH DSA ключ и выдает OpenSSH DSA публичный ключ
• ssh-keygen -r доменное-имя [-g] [-f файл-с-ключами] - выводит запись ресурса DNS SSHFP (fingerprint RR)

Обычно каждый пользователь, желающий использовать SSH с RSA или DSA аутентификацией, запускает его единожды для создания аутентификационного ключа в $HOME/.ssh/identity, $HOME/.ssh/id_dsa или $HOME/.ssh/id_rsa.

Обычно эта программа генерирует ключи и спрашивает название файла в котором надо сохранить приватный ключ. Публичный ключ будет сохранен в файле с тем же именем, только к нему будет добавлено расширение ".pub". Программа также спросит у вас ключевую фразу. Ключевая фраза может быть пустой, это означает, что ключевая фраза не используется (ключ машины должен иметь пустую ключевую фразу), или это может быть строка произвольной длины. Ключевая фраза схожа с паролем, за исключением того, что ключевая фраза может состоять из набора слов, знаков препинания, цифр, пробелов или любого набора символов, какой вы пожелаете. Хорошими считаются ключевые фразы из 10-30 символов, не являющиеся простыми предложениями или легко угадываемыми (английская проза имеет только 1-2 бита энтропии на символ и обеспечивает очень плохие ключевые фразы) и содержать чередование букв, цифр и не буквенно-цифровых, набранных в верхнем и нижнем регистре, знаков. Ключевая фраза может быть позднее изменена при помощи опции -p.

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

Для RSA1-ключей в файле ключа имеется поле комментария, который служит только для удобства пользователя, чтобы было проще идентифицировать ключ. Комментарий может вам сообщить для чего этот ключ или чем он полезен. Комментарий инициализируется при создании для "user@host", но может быть изменен при помощи опции -c.

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

Используемые опции:

• -b bits Определяет число бит в ключе при его создании. Минимум это 512 бит. Как правило, 2048 бит считается достаточным. По умолчанию используется 2048 бит.
• -c Запрашивает изменение комментария в файлах приватных и публичных ключей. Операция поддерживается только для RSA1-ключей. Программа предложит указать файл содержащей приватный ключ, спросит ключевое слово, если таковое имеется, и новый комментарий.
• -е Эта опция позволяет прочитать приватный или публичный OpenSSH-файл ключа и распечатать его в "SECSH Public Key File Format" в стандартный вывод. Также, данная опция позволяет экспортировать ключи для использования с некоторыми коммерческими реализациями SSH. -f filename Определяет имя файла для файла ключа.
• -i Эта опция считывает не зашифрованный SSH2-совместимый приватный (или публичный) файл ключа и распечатывает OpenSSH-совместимый приватный (или публичный) ключ в стандартный вывод. Также, ssh-keygen считывает "SECSH Public Key File Format". Данная опция позволяет импортировать ключи из некоторых коммерческих реализаций SSH.
• -l Показывает распечатку указанного приватного или публичного ключа. Также поддерживаются приватные RSA1-ключи. Для RSA- и DSA-ключей ssh-keygen предпримет попытку найти соответствующие публичные ключи и их отпечатки.
• -p Запрашивает изменение ключевой фразы приватного ключа вместо создания нового приватного ключа. Программа предложит указать имя файла содержащего приватный ключ, старую ключевую фразу и, дважды, новую ключевую фразу.
• -q Тихий ssh-keygen. Используется в работе /etc/rc при создании нового ключа.
• -y Эта опция читает приватный OpenSSH-формат файла и печатает публичный ключ OpenSSH в стандартный вывод.
• -t type Определяет тип создаваемого ключа. Допустимыми являются значения "rsa1", для протокола версии 1, и "rsa1" или "dsa", для протокола версии 2.
• -В Этот параметр отображает "bubblebabble" дайджест заданного файла публичного или приватного ключа.
• -C comment Обеспечивает ввод нового комментария.
• -D reader Копировать сохранённый публичный RSA-ключ со smartcard в устройстве reader.
• -N new_passphrase Обеспечивает ввод новой ключевой фразы.
• -P passphrase Обеспечивает ввод (старой) ключевой фразы.
• -D reader Копировать публичный RSA-ключ на smartcard в устройстве reader.

ФАЙЛЫ

• $HOME/.ssh/identity Содержит идентификацию для RSA-аутентификации пользователя по протоколу версии 1. Этот файл должен быть доступен для чтения только владельцу. Этого можно добиться путем указания ключевой фразы при создании ключа; эта ключевая фраза будет использована для шифрования приватной части этого файла с использованием 3DES. Этот файл не доступен для ssh-keygen автоматически, но подразумевается, что это файл по умолчанию для приватного ключа. ssh(1) будет считывать данные из этого файла, если будет предпринята попытка входа в систему.
• $HOME/.ssh/identity.pub Содержит публичный ключ для RSA-аутентификации по протоколу версии 1. Содержимое этого файла должно быть добавлено к $HOME/.ssh/authorized_keys на всех машинах, где вы желаете иметь возможность входа в систему с использованием RSA-аутентификации. Нет никакой необходимости хранить содержимое этого файла в тайне.
• $HOME/.ssh/id_dsa Содержит идентификацию для DSA-аутентификации пользователя по протоколу версии 2. Этот файл должен быть доступен для чтения только владельцу. Этого можно добиться путем указания ключевой фразы при создании ключа; эта ключевая фраза будет использована для шифрования приватной части этого файла с использованием 3DES. Этот файл не доступен для ssh-keygen автоматически, но подразумевается, что это файл по умолчанию для приватного ключа. ssh будет считывать данные из этого файла, если будет предпринята попытка входа в систему.
• $HOME/.ssh/id_dsa.pub Содержит публичный ключ для DSA-аутентификации по протоколу версии 2. Содержимое этого файла должно быть добавлено к $HOME/.ssh/authorized_keys на всех машинах, где вы желаете иметь возможность входа в систему с использованием аутентификации с публичным ключем. Нет никакой необходимости хранить содержимое этого файла в тайне.
• $HOME/.ssh/id_rsa Содержит идентификацию для RSA-аутентификации пользователя по протоколу версии 2. Этот файл должен быть доступен для чтения только владельцу. Этого можно добиться путем указания ключевой фразы при создании ключа; эта ключевая фраза будет использована для шифрования приватной части этого файла с использованием 3DES. Этот файл не доступен для ssh-keygen автоматически, но подразумевается, что это файл по умолчанию для приватного ключа. ssh будет считывать данные из этого файла, если будет предпринята попытка входа в систему.
• $HOME/.ssh/id_rsa.pub Содержит публичный ключ для RSA-аутентификации по протоколу версии 2. Содержимое этого файла должно быть добавлено к $HOME/.ssh/authorized_keys на всех машинах, где вы желаете иметь возможность входа в систему с использованием аутентификации с публичным ключем. Нет никакой необходимости хранить содержимое этого файла в тайне.

Задача. На удаленном компьютере anacron запускает скрипт для резервирования БД PostgreSQL один раз в сутки. Нужно создать скрипт который будет копировать удаленные backup-копии на локальный сервер бекапов. Скрипт запустим при помощи Использование планировщика cron в Linux.

$ ssh-keygen -t dsa
$ ls
id_dsa  id_dsa.pub
$ chmod 600 id_dsa

Поместим публичный ключ файл ~/.ssh/authorized_keys на удаленном компьютере.

$ ssh-copy-id -i id_dsa.pub USER@HOST

Скрипт:

#!/bin/bash
 
# Copy PostgreSQL
 
SFTP='/usr/bin/sftp'
DIR='/home/backups_mbill_sql/'
HOST='user@host:/home/backups_mbill_sql/'
FILES="psql-`date +%d.%m.%Y`*.sql"
 
$SFTP $HOST$FILES $DIR

Создание ssh ключей для виртуальной Linux в Microsoft Azure. Для создания и использования ключей SSH с Azure выполните описанные ниже действия.

cd .ssh/
ssh-keygen -t rsa -b 2048 -N "" -C 'your-email@example' -f azuressh -q

Будут созданы два ключа azuressh и публичный azuressh.pub. Чтобы без ошибок скопировать содержимое azuressh.pub и вставить его в поле при создании VE, используйте ssh-keygen. Весь вывод, без исключений нужно копировать.

ssh-keygen -e -f azuressh.pub
---- BEGIN SSH2 PUBLIC KEY ----
Comment: "2048-bit RSA
...
---- END SSH2 PUBLIC KEY ----

Не забудьте настроить файл config, для большего удобства.

sshpass - это утилита командной строки, предназначенная для автоматизации ввода паролей при подключении к SSH-серверам. Она позволяет вам указать пароль один раз, а затем использовать его для выполнения различных SSH-команд без повторного ввода. Утилита sshpass часто используется в сценариях Bash, Ansible для автоматизации задач, требующих подключения к SSH-серверам.

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

Примеры использования `sshpass`:

1. Выполнение команд на удаленном сервере:

sshpass -p 'your_password' ssh username@remote_host 'command_to_execute'

2. Использование с sshfs для монтирования удаленной файловой системы:

sshpass -p 'your_password' sshfs username@remote_host:/remote/directory /local/mount/point

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

3. Автоматизация входа по SSH с использованием sshpass с scp:

sshpass -p mypass scp file user@ipaddress:/remote/path

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