Не в состоянии ssh к другому компьютеру, но может пинговать это?

Невозможно подключиться к ssh к другому компьютеру, но можно проверить его? Не уверен, что мне не хватает?
Использование маршрутизатора Netgear

bash-3.2$ ifconfig
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> mtu 16384
        inet6 ::1 prefixlen 128 
        inet6 fe80::1%lo0 prefixlen 64 scopeid 0x1 
        inet 127.0.0.1 netmask 0xff000000 
gif0: flags=8010<POINTOPOINT,MULTICAST> mtu 1280
stf0: flags=0<> mtu 1280
en0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        ether xx:xx:xx:xx:xx:xx 
        media: autoselect (none)
        status: inactive
en1: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 1500
        ether xx:xx:xx:xx:xx:xx 
        inet6 xxxx::xxxx:xxxx:xxxx:xxxxxx prefixlen 64 scopeid 0x5 
        inet 10.0.0.3 netmask 0xffffff00 broadcast 10.0.0.255
        media: autoselect
        status: active
fw0: flags=8863<UP,BROADCAST,SMART,RUNNING,SIMPLEX,MULTICAST> mtu 4078
        lladdr xx:xx:xx:xx:xx:xx:xx:xx 
        media: autoselect <full-duplex>
        status: inactive
bash-3.2$ ssh jeremy@10.0.0.4
ssh: connect to host 10.0.0.4 port 22: Connection refused
bash-3.2$ ssh -p 5900 jeremy@10.0.0.4
ssh: connect to host 10.0.0.4 port 5900: Connection refused
bash-3.2$ ping 10.0.0.3
PING 10.0.0.3 (10.0.0.3): 56 data bytes
64 bytes from 10.0.0.3: icmp_seq=0 ttl=64 time=0.046 ms
64 bytes from 10.0.0.3: icmp_seq=1 ttl=64 time=0.079 ms
64 bytes from 10.0.0.3: icmp_seq=2 ttl=64 time=0.078 ms
64 bytes from 10.0.0.3: icmp_seq=3 ttl=64 time=0.077 ms
64 bytes from 10.0.0.3: icmp_seq=4 ttl=64 time=0.079 ms
64 bytes from 10.0.0.3: icmp_seq=5 ttl=64 time=0.081 ms
64 bytes from 10.0.0.3: icmp_seq=6 ttl=64 time=0.078 ms
^C
--- 10.0.0.3 ping statistics ---
7 packets transmitted, 7 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 0.046/0.074/0.081/0.011 ms
bash-3.2$ ping 10.0.0.4
PING 10.0.0.4 (10.0.0.4): 56 data bytes
64 bytes from 10.0.0.4: icmp_seq=0 ttl=64 time=2.667 ms
64 bytes from 10.0.0.4: icmp_seq=1 ttl=64 time=2.675 ms
64 bytes from 10.0.0.4: icmp_seq=2 ttl=64 time=2.969 ms
64 bytes from 10.0.0.4: icmp_seq=3 ttl=64 time=2.663 ms
64 bytes from 10.0.0.4: icmp_seq=4 ttl=64 time=2.723 ms
^C
--- 10.0.0.4 ping statistics ---
5 packets transmitted, 5 packets received, 0.0% packet loss
round-trip min/avg/max/stddev = 2.663/2.739/2.969/0.117 ms
bash-3.2$ 

На сервере либо не запущен sshd (и, следовательно, он не прослушивает порт 22), либо установлен порт блокировки межсетевого экрана 22 (порт ssh по умолчанию), либо в невероятно редких случаях работает ssh на каком-либо другом порту (что почти наверняка не так) ,

Сначала проверьте, установлен ли sshd (на примерах Debian)

sudo apt-get install openssh-server

И если так, это работает:

ps -ef | grep sshd

затем проверьте, слушает ли он порт 22

sudo netstat -nlp | grep :22
tcp        0      0 0.0.0.0:22              0.0.0.0:*               LISTEN      946/sshd
tcp6       0      0 :::22                   :::*                    LISTEN      946/sshd

затем проверьте правила брандмауэра (это сильно различается, поэтому я покажу пример debian / ubuntu / etc):

sudo ufw status

sudo ufw show listening
tcp:
  22 * (sshd)
  24224 * (ruby)
tcp6:
  22 * (sshd)
  8080 * (java)
udp:
  123 10.X.Y.Z (ntpd)
  123 * (ntpd)
  18649 * (dhclient)
  24224 * (ruby)
  34131 * (ruby)
  60001 10.87.43.24 (mosh-server)
  68 * (dhclient)
udp6:
  123 fe80::1031:AAAA:BBBB:CCCC (ntpd)
  123 * (ntpd)
  48573 * (dhclient)

Если ufwпоказывает, что он закрыт, запустите (снова пример Debian / Ubuntu)

sudo ufw allow 22

Вроде странный выстрел в темноте, но убедитесь, что ваш IP не изменился. Однажды у меня возникла эта проблема - я установил .bashrcпсевдоним alias sshdev='ssh me@123.2.3.4'как типичный способ входа в систему, и однажды я начал получать следующую ошибку:

ME-M-216C:~ me$ sshdev 
ssh: connect to host 123.2.3.4 port 22: Connection refused

У нас просто было отключение электричества на работе, которое сбрасывало IP-адреса, поэтому я успешно проверял IP-адрес, но это был не тот компьютер. Вы можете использовать, nslookup <IP>чтобы убедиться, что это правильное имя машины, на которое вы пытаетесь указать ssh.

Когда вы получаете сообщение «Отказано в соединении», это означает, что демон не прослушивает этот порт или брандмауэр отклоняет соединение. Чтобы устранить эту проблему, убедитесь, что sshона работает, а локальные правила брандмауэра не отклоняют входящие подключения через этот порт.

У меня была такая же проблема с Linux Lite. Чтобы решить эту проблему, мне нужно было зайти в «Настройки»> «Конфигурация брандмауэра». После входа в root я изменил входящий параметр на Allow, и это сработало.

Две мысли

1. Позволяет ли брандмауэр подключаться к порту через порт 22?
2. sshdРаботает ли ssh daemon ( )?

эта команда работала для меня. Попробуй это.

update-rc.d -f ssh enable 2 3 4 5

В общем, следуйте инструкциям: 1) отправьте эхо-запрос на хост назначения и проверьте и перепроверьте введенный IP-адрес. 2) Проверьте состояние sshd службы sudo на обоих хостах. Если остановлено, запустите службу sshd. Если вы получаете сообщение об ошибке sshd.service не найден, установите openssh-server -> sudo apt install -y openssh-server и перезапустите sshd.service. 3) Отключение брандмауэра или внесение изменений в файлы конфигурации следует рассматривать как последний вариант.