Linux: ssh (конфигурация, 2FA, туннели, примеры подключения, автологин, удаление сессий, radius, скрипты)

• SSH3 (seclab) – протокол по функционалу близкий к ssh поверх QUIC (есть реализаци клиента и сервера), название скорее неудачное, но в целом проект интересный – напр. маскировка под HTTPS, скорость за счет ускорения handshake, проброс не только TCP, но и UDP портов; встроенный в quic “mobile IP”, «вести себя как web сервер пока не получим нужный id», нативная поддержка oauth, поддержка сертификатов x.509.

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

Создаётся нечто непонятное и непонятно для чего, полностью ломающее совместимость и закрывающее возможность для OpenSSH выпустить третью версию. 

Действительно нейминг SoH (SSH over HTTP) был бы уместней, хотя и не совсем точный

• Просмотр SSH сессий – w, pinky

# w
13:56:26 up 58 days, 49 min, 1 user, load average: 0.00, 0.00, 0.00
USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT
root pts/0 11.0.0.98 10:29 1.00s 0.08s 0.00s w

# pinky
Login Name TTY Idle When Where
root root pts/0 Apr 7 10:29 11.0.0.98

• (ssh, bash) $SSH_CLIENT, $SSH_CONNECTION, $TERM – переменные с выводом информации откуда/куда подключились по SSH, поддержка цветов терминалом

~ $ echo $SSH_CLIENT
89.179.128.38 59824 19922
~ $ echo $SSH_CONNECTION
89.179.128.38 59824 195.14.50.22 19922
# echo $TERM
xterm-256color

SSH (Secure Shell) – позволяет подключится к удаленной железке по ssh, передавать данные поверх поднятого SSH (SCP/WINSCP или даже SSH-TUNNEL, SSH-PROXY). SSH-клиент и сервер OpenSSH в Linux дистрибутивах типа RHEL7 предустановлены в систему.

Основные опции.

-l Specifies the user to log in as on the remote machine
-p Port to connect to on the remote host
-i key (PEM format)

Установка

Клиент идет обычно во всех дистрибутивах.

Сервер выбирается опционально (OpenSSH Server) при установке.

Можно установить вручную (ubuntu/debian):

sudo apt-get update
sudo apt-get install openssh-server

Если выдает ошибку ниже, то нужно разобраться с репозиториями – привести к тому, как должно быть, например для debian.

openssh-server : Depends: libwrap0(>= 7.6-4~) but it is not installable
Recommends: ssh-import-id but it is not installable

КОнфигурация

Изменяем порт с “по умолчанию” для уменьшения нагрузки от школо-брутфорсеров. Можно (если нужно) указать несколько портов, перечислив их в каждой уникальной строке.

Port 60661   # разрешаем подключения на порт 60661
Port 22222   # так же разрешаем подключения на порт 22222

Отключаем доступ рута

PermitRootLogin no

Делаем доступ только ля определенных учетных записей с определенных хостов или сетей.

AllowUsers admin@1.1.1.* admin@1.2.2.2 user@3.3.3.3
AllowUsers weril@*

Отключаем ssh-туннели. Хотя и пользователи могут их сами включить.

$ sudo grep -i forw /etc/ssh/sshd_config
#AllowTcpForwarding yes

SSH TUNNEL

• SSH-TUNNEL настройки клиента и SOCKS proxy Putty
• SSH-TUNNEL настройки сервера
• ssh-сервер с доступом на внешку разные “паразиты” могут использовать для доступа с него во внешку через ssh-туннели. Выдечили правилами iptables на out у нас так на одном из серваков, только пострадал скрипт, который вносит данные через WEB (добавили в исключения домен, на который обращается скрипт.
• Примеры настройки ssh tunnel в native windows/putty для доступа по RDP к серверу поверх защифрованного ssh tunnel (по сути использование вместо VPN чтобы не «светить» RDP наружу); так же описано обратное – доступ к своей подсети (обратный туннель)

Защищенный доступ к RDP через SSH туннель (local TCP forwarding)
В этом режиме вы создаете на своем компьютере локальный TCP порт, подключения к которому перенаправляются через SSH туннель на указанный порт удаленного сервера. В этом примере мы создадим локальный порт 8888, при подключении к которому выполняется перенаправление на RDP порт 3389 на удаленном компьютере. Общая схема подключения выглядит так:

Чтобы создать SSH туннель с удаленным компьютером 192.168.1.90, выполните команду:
ssh -L 8888:192.168.1.90:3389 root@192.168.1.90
В этом примере используется форматLOCAL_PORT:DESTINATION:DESTINATION_PORT и USER@DEST_SERVER_IP (имя пользователя и адрес удаленного SSH сервера). Чтобы SSH туннель работал в фоновом режиме, нужно добавит параметр –f.
Теперь, чтобы подключится к удаленному компьютеру по RDP через SSH туннель, вам запустить RDP-клиент (mstsc.exe) и подключиться на локальный порт 8888 своего компьютера:
127.0.0.1:8888

Переброс удаленного порта на локальную машину (Remote TCP forwarding)
Есть еще один вариант применения SSH туннеля – remote TCP forwarding. Через SSH туннель вы можете открыть доступ удаленному серверу к локальному порту на вашем компьютере или порту на другом компьютере в вашей локальной сети. Например, вы хотите, чтобы внешний сервер (192.168.1.90) получил доступ к вашему Интранет сайту (не опубликованному в Интернете). Для создания обратного туннеля, используйте такую команду:
ssh -R 8080:internalwebsever:80 user@192.168.1.90
Теперь, чтобы на удаленном SSH сервер получить доступ к веб серверу internalwebsever достаточно в браузере набрать адрес http://localhost:8080 .

• Отключаем ssh-туннели. Хотя и пользователи могут их сами включить.

$ sudo grep -i forw /etc/ssh/sshd_config
#AllowTcpForwarding yes

Примеры подключения

по логину/паролю

ssh 10.130.37.17 – подключаемся к хосту 10.130.37.17 по SSH порту по умолчанию (порт 22) с логином  по умолчанию (из под которого мы находимся в системе).

ssh -p 19999 -l username test.net или ssh –p 19999 username@test.net – подключаемся на порт 19999 test.net с логином username.

При первом подключении с клиента к неизвестному ранее хосту-серверу будет вопрос о том, что аутентификация сервера не может быть проверена в связи с отсутствием записи о хосте. После первого подключения в файле .ssh/known_hosts появится ECDSA/RSA2 key fingerprint хоста, к которому происходило подключение и в следующий раз вопроса о ключе не последует.

~$ ssh -l user1 192.168.1.17
The authenticity of host '192.168.1.17 (192.168.1.17)' can't be established.
ECDSA key fingerprint is 83:d6:36:5c:f6:6c:59:d0:f4:43:f6:13:fb:f0:26:5f.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '192.168.1.17' (ECDSA) to the list of known hosts.
~$ cd .ssh
~/.ssh$ more known_hosts
|1|vrUcv9MuzkA0y6h8MbKp3wwSm/w=|/wyoBsJJxIw4+i78ru52bFwOuz8= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBMf/qhQ+TZgxST09f0jYxuMla6QDCK0QAqAC3UVODyhD
uGuMaSYVln+Ypaf8cWmBUY1ECB+y/kLyyF8ZbL8JGfk=

При попытке подключения может выдавать ошибки “no supported authentication methods available server sent publickey” и “Permission denied (publickey,gssapi-keyex,gssapi-with-mic).”. Это симптом того, что отключено подключение с паролем. Если парольная аутентификация должна быть включена – отредактируйте файл sshd_config.

PasswordAuthentication yes

по ключу

Генерация ключа и передача его на удаленный сервер описана ниже – поиск по ssh-keygen и ssh-copy-id.

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

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

сhmod 400 ubuntu16_bot.pem
ssh -i ubuntu16_bot.pem ubuntu@52.37.203.47

ssh -i alicloud.pem ubuntu@47.254.169.62

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@ WARNING: UNPROTECTED PRIVATE KEY FILE! @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@

Permissions 0644 for 'alicloud.pem' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.
Load key "alicloud.pem": bad permissions

plink -telnet 10.3.3.3
plink -ssh weril.me
plink -ssh -i key.ppk ubuntu@52.37.203.47

$ cat /etc/bash/bashrc

# ALIAS
alias telnet='plink -telnet'
alias t='plink -telnet'

ssh user@172.1.1.226 'grep some_str /var/log/sys.log'

~$ (sleep 1; echo 123) | ssh -p 1999 username@1.1.1.1
Pseudo-terminal will not be allocated because stdin is not a terminal.

Удаление сессий

Удалить сессию ssh можно через Kill процесса

ps -aux | grep pts
sudo kill -9 10142

Нужно дропать активные ssh коннекты и удалять/перемещать .ssh папку пользователя, во избежания ssh-backdoor. Целиком взято отсюда

Обычное отключение/блокирование не исключает удаленного подключения пользователя к серверу, если ему предварительно была установлена аутентификация по открытому ключу RSA. Такие пользователи будут получать доступ к консольной оболочке (shell) на сервере без необходимости ввода какого-либо пароля. Не забывайте проверять пользовательские домашние каталоги на файлы, которые позволяют подобный тип авторизации по SSH, например, /home/username/.ssh/authorized_keys.

Удаление или переименование каталога .ssh/ в домашнем каталоге пользователя предотвратит дальнейшую способность аутентификации по SSH.

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

Залипнуть сессии в состоянии root@notty могут из-за не отключившегося скрипта. У меня так на сервере как-то накапилось 500 сессий root@notty, чистились конечно легко и никак на системы не влияли, но после правки кода добавлением отключения ssh_client накопление остановилось.

ps -aux | grep "root@notty" | awk '{print $2}' | while read pid; do echo $pid; kill -9 $pid; done

Radius

Для аутентификации на Linux-сервере (например, RHEL) по SSH через удаленный RADIUS на сервер для взаимодействия с RADIUS обычно ставят модуль PAM-D (pam: gdm-password).

Генерация ключа

Может понадобиться например для github – генерируем public ключ, импортируем его на сайт github, взаимодействуем (аутентифицируемся в github) с помощью ssh через CLI. Подробно описано тут.

Создать ключ можно с паролем (безопаснее) или без (удобнее).

$ ssh-keygen -t rsa -b 4096 -C "weril@me.com"
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/redkin_p/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /Users/redkin_p/.ssh/id_rsa.
Your public key has been saved in /Users/redkin_p/.ssh/id_rsa.pub.
The key fingerprint is:
SHA256:Zjhr1DFAbbonau8iUh8Ty+PZpRMNUfFK3ILi5T2+4r4 weril@me.com
The key's randomart image is:
+---[RSA 4096]----+
|     .ooo.       |
|      .+oo       |
|    . o+* o      |
|   ..+o= =       |
|   ..o=+S        |
|  . *.+*+.       |
| . o Bo*.        |
|. . B.=  .       |
| . o *E+.        |
+----[SHA256]-----+

После этого нужно добавить ключи на удаленный хост и запустить ssh agent (не всегда).

• В облаках чаще всего требуется вставить копипаст публичного ключа (не приватного!)

cat .ssh/id_rsa.pub   # меняем, если указали другое имя ранее

• Это можно сделать автоматически с хоста, на котором создан ключ, передав его на удаленный хост:

ssh-copy-id -p 555 weril@172.16.0.1

• Это можно сделать вручную, если ключ уже каким то способом передан на удаленный хост:

$ eval "$(ssh-agent -s)"
Agent pid 25236

$ ssh-add .ssh/id_rsa
Enter passphrase for .ssh/id_rsa:
Identity added: .ssh/id_rsa (weril@me.com)

Далее загружаем ключи на git и пытаемся подключиться на git@github.com. Если все ок – будет написано, что подключение (аутентификация) успешно, но git не предоставляет shell access.

ssh -T git@github.com

Зато, теперь мы можем клонировать приватный репозиторий.

git clone ssh://git@github.com/...repo.git

ПУБЛИЧНЫЙ КЛЮЧ (public key)

Публичный ключ хоста используется даже при использовании схемы аутентификации без ключей для верификации того, что хост, к которому мы подключаемся, не поменялся (spoof ip/dns/etc).

C:\Users\redkin.petr>ssh root@172.1.1.111
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
Someone could be eavesdropping on you right now (man-in-the-middle attack)!
It is also possible that a host key has just been changed.
The fingerprint for the ECDSA key sent by the remote host is
SHA256:y1yfOPQSFkcvh5tpc7XxndYb6iM1ImYiOgHkocjVvYc.

Please contact your system administrator.
Add correct host key in C:\\Users\\user/.ssh/known_hosts to get rid of this message.
Offending ECDSA key in C:\\Users\\user/.ssh/known_hosts:1
ECDSA host key for 172.1.1.111 has changed and you have requested strict checking.
Host key verification failed.

На Windows в known_hosts

172.1.1.111 ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBKZrX/vZfbDjzZ1AzBosWnvX5J7h/0VAq6qbyQG1HjRc4jWtqyaT20b4IS2X8rASRk0bdaNXI9k2XPQUuTvJo0w=

На самом сервере

# cat /etc/ssh/ssh_host_ecdsa_key.pub
ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBKZrX/vZfbDjzZ1AzBosWnvX5J7h/0VAq6qbyQG1HjRc4jWtqyaT20b4IS2X8rASRk0bdaNXI9k2XPQUuTvJo0w= root@DMG

Скрипт на событие логина по SSH

см. в отдельной статье

2FA google-authenticator

• Формально ключ + пароль это уже 2FA, но безопасней токен на отдельном устройстве (не на том, с которого происходит подключение)
• Что круто, verification code появится в любом случае – правильный вы ввели пароль или нет. Это позволяет хакеру не думать, что он обошел какой-то эшелон защиты (кхм кхм авторизация WordPress).
• Не работает со старыми версиями SecureCRT, но мне подходит mRemoteNG/SuperPutty (если только не нажимать кнопку close others).

centos, ubuntu

Устанавливаем epel репозиторий.

sudo yum install epel-release

Устанавливаем authenticator.

sudo yum install google-authenticator 
sudo apt-get install libpam-google-authenticator

Помимо самого токена делаются две доп. защиты: rate limiting, запрет использования одного токена несколько раз. Запускаем из под учетной записи, для которой включается fa, без sudo (иначе FA включается для root).

google-authenticator

Do you want authentication tokens to be time-based (y/n) y

Do you want me to update your "/home/admin/.google_authenticator" file? (y/n) y

Do you want to disallow multiple uses of the same authentication
token? This restricts you to one login about every 30s, but it increases
your chances to notice or even prevent man-in-the-middle attacks (y/n) y

By default, a new token is generated every 30 seconds by the mobile app.
In order to compensate for possible time-skew between the client and the server, we allow an extra token before and after the current time. This allows for a time skew of up to 30 seconds between authentication server and client. If you experience problems with poor time synchronization, you can increase the window from its default size of 3 permitted codes (one previous code, the current code, the next code) to 17 permitted codes (the 8 previous codes, the current code, and the 8 next codes). This will permit for a time skew of up to 4 minutes between client and server. Do you want to do so? (y/n) n

If the computer that you are logging into isn't hardened against brute-force login attempts, you can enable rate-limiting for the authentication module. By default, this limits attackers to no more than 3 login attempts every 30s.
Do you want to enable rate-limiting? (y/n) y

Редактируем файлы и перезагружаем сервис sshd

sudo vi /etc/pam.d/sshd
  auth required pam_google_authenticator.so

sudo vi /etc/ssh/sshd_config
 ChallengeResponseAuthentication yes 

sudo service sshd restart 

Enjoy!