Сервис sshd
довольно просто настроить и приступить к работе.
Убедитесь, что служба запущена и работает/прослушивает порт 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
$ 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, например.
Затем убедитесь, что брандмауэр разрешает доступ сетевого трафика к порту 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.
/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
Вы можете подтвердить это с помощью такой команды от одного из ваших внешних клиентов:
$ 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
.
В некоторых ситуациях, например, когда был установлен 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
.
Я предполагаю, что у вас есть что-то вроде последовательного 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/config
2 строки опций
PermitLocalCommand yes
LocalCommand sleep 10 && stty ixon -F /dev/tty &
PermitLocalCommand
по умолчанию отключено в целях безопасности; см. man ssh_config
.