Передается ли управление потоком XON/XOFF через несколько переходов сеанса терминала?

Сервис sshdдовольно просто настроить и приступить к работе.

1. Запустить службу

Убедитесь, что служба запущена и работает/прослушивает порт 22.

запуск службы
$ sudo systemctl start sshd
проверить статус
$ sudo systemctl status sshd
● sshd.service - OpenSSH server daemon
   Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
   Active: active (running) since Tue 2018-07-24 22:24:00 EDT; 1h 40min left
     Docs: man:sshd(8)
           man:sshd_config(5)
 Main PID: 1270 (sshd)
    Tasks: 1
   CGroup: /system.slice/sshd.service
           └─1270 /usr/sbin/sshd -D

Jul 24 22:24:00 centos7 systemd[1]: Starting OpenSSH server daemon...
Jul 24 22:24:00 centos7 systemd[1270]: Executing: /usr/sbin/sshd -D
Jul 24 22:24:00 centos7 sshd[1270]: Server listening on 0.0.0.0 port 22.
Jul 24 22:24:00 centos7 sshd[1270]: Server listening on :: port 22.
Jul 24 22:24:00 centos7 systemd[1]: Started OpenSSH server daemon.
Jul 24 20:31:37 centos7 sshd[1582]: Accepted publickey for vagrant from 10.0.2.2 port 64437 ssh2: RSA SHA256:1vJymfZsu2KZ49lDftGMzz2VEb2Z2Y8PNi9cs55eHGE
Jul 24 20:43:29 centos7 systemd[1]: Trying to enqueue job sshd.service/start/replace
Jul 24 20:43:29 centos7 systemd[1]: Installed new job sshd.service/start as 560
Jul 24 20:43:29 centos7 systemd[1]: Enqueued job sshd.service/start as 560
Jul 24 20:43:29 centos7 systemd[1]: Job sshd.service/start finished, result=done

2. Убедитесь, что служба прослушивает

проверьте, прослушивается ли порт 22
$ sudo netstat -tlpn | grep sshd
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      1270/sshd
tcp6       0      0 :::22                   :::*                    LISTEN      1270/sshd

Вы также можете убедиться, что sshdпрослушивает либо все интерфейсы (0.0.0.0 ), либо, по крайней мере, IP-адрес вашей системы:

$ ip a l eth0 | awk '/inet / {print $2}'
192.168.56.101/24

Таким образом, вы увидите в выводе netstat, 192.168.56.101 :22, например.

3. Брандмауэр

Затем убедитесь, что брандмауэр разрешает доступ сетевого трафика к порту 22.

$ sudo firewall-cmd  --list-all
FirewallD is not running

Если это так, то трафик может достигать порта 22. Если это выглядит так:

$ firewall-cmd  --list-all
public (active)
  target: DROP
  icmp-block-inversion: no
  interfaces: eth0 eth1
  sources:
  services: ssh dhcpv6-client
  ports:
  protocols:
  masquerade: no
  forward-ports:
  source-ports:
  icmp-blocks:
  rich rules:

Разрешается трафик для служб sshи dhcpv6-clientи отключается для всего остального. Опять же, это нормально и должно разрешать трафик SSH.

4. Проверьте/etc/ssh/sshd_config

Убедитесь, что /etc/ssh/sshd_configне блокирует внешние подключения.Следующие параметры должны быть установлены аналогично тому, что я показываю ниже.

$ grep -vE '^#|^$|AcceptEnv|HostKey|Syslog|MAC|Banner|LogLevel|Authorized' /etc/ssh/sshd_config
PermitRootLogin yes
MaxAuthTries 4
HostbasedAuthentication no
IgnoreRhosts yes
PermitEmptyPasswords no
PasswordAuthentication yes
ChallengeResponseAuthentication no
GSSAPIAuthentication yes
GSSAPICleanupCredentials no
UsePAM yes
X11Forwarding no
Subsystem   sftp    /usr/libexec/openssh/sftp-server
Protocol 2

5. Подтвердить

Вы можете подтвердить это с помощью такой команды от одного из ваших внешних клиентов:

$ timeout 2 curl -v telnet://192.168.56.101:22
* Rebuilt URL to: telnet://192.168.56.101:22/
*   Trying 192.168.56.101...
* Connected to 192.168.56.101 (192.168.56.101) port 22 (#0)
SSH-2.0-OpenSSH_7.4 
$

ПРИМЕЧАНИЕ.:Если вы видите здесь сообщение об IP-адресе «Подключено к X.X.X.X», ничто не препятствует вашему сетевому трафику с клиентского компьютера, на котором вы используете curl, на сервер sshd.

6. Докер

В некоторых ситуациях, например, когда был установлен Docker, вы столкнетесь со сценарием, когда мост docker0добавил несколько виртуальных сетей в мост docker0. Вы можете видеть их вот так:

$ docker network ls
NETWORK ID          NAME                DRIVER              SCOPE
bd7594c1dce3        bridge              bridge              local
db24b1e2be58        host                host                local
edf606d533a5        none                null                local

В таких случаях вам потребуется удалить все дополнительные сети, чтобы восстановить вашу физическую сеть, чтобы она могла правильно маршрутизировать пакеты SSH. Просто используйте команду docker network rm , чтобы удалить все, что выходит за рамки стандартных bridge, hostи none.

Ссылки

2
24.06.2021, 17:44
1 ответ

Я предполагаю, что у вас есть что-то вроде последовательного USB-адаптера с -на -на пи, и вы настроили getty, чтобы вы могли войти в этот tty со своего PX -8. После входа в систему, stty ixonиз оболочки активирует управление потоком xon/xoff для вывода из pi. Если вы сейчас sshиз оболочки войдете в какой-нибудь удаленный компьютер, управление потоком будет неадекватным, чтобы остановить большой вывод данных с удаленного компьютера.

Кажется, что происходит (сделать strace -v -f -o /tmp/trace sshи найти ioctl(0,...)), что sshпреднамеренно переводит терминал в необработанный режим, который включает в себя отключение настройки ixon. Обычно это то, что желательно; вы хотите, чтобы каждый набранный символ перешел на удаленный компьютер, у которого есть собственный pty для управления потоком данных и так далее.

К сожалению, выходные данные с удаленного устройства отправляются в больших буферах, поэтому символ xoff из PX -8 будет малоэффективен, так как к тому времени, когда он дойдет до удаленного устройства, весь большой буфер уже получен pi. будет продолжать выводиться, что может привести к переполнению и потере данных.

Что вы можете попробовать, так это повторно -выдать stty ixonна pi после установления соединения ssh. Один из способов сделать это автоматически — добавить в ~/.ssh/config2 строки опций

PermitLocalCommand yes
LocalCommand sleep 10 && stty ixon -F /dev/tty &

PermitLocalCommandпо умолчанию отключено в целях безопасности; см. man ssh_config.

2
28.07.2021, 11:22

Теги

Похожие вопросы