F22 - ssh: connect to host XX port 22: Connection timed out


#1

Ahoj,

chtěl bych poprosit o radu, protože mě už nic nenapadá. Nedaří se mi z Debian serveru připojit pomocí SSH na můj Fedora (verze 22) PC (opačně to funguje). Konkrétně:

XX@XX:~$ ssh XX@XX
ssh: connect to host XX port 22: Connection timed out

XX@XX:~$ telnet XX 22
Trying XX…
telnet: Unable to connect to remote host: Connection timed out

XX@XX:~$ ping XX
PING XX (XX) 56(84) bytes of data.
64 bytes from XX (XX): icmp_seq=1 ttl=55 time=8.47 ms
64 bytes from XX (XX): icmp_seq=2 ttl=55 time=8.62 ms
64 bytes from XX (XX): icmp_seq=3 ttl=55 time=7.91 ms
64 bytes from XX (XX): icmp_seq=4 ttl=55 time=7.98 ms

— XX ping statistics —
4 packets transmitted, 4 received, 0% packet loss, time 3005ms
rtt min/avg/max/mdev = 7.915/8.251/8.627/0.313 ms

Co jsem zkoušel:

Firewally nejsou aktivní:
[XX@XX] systemctl status firewalld.service
● firewalld.service - firewalld - dynamic firewall daemon
Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled; vendor preset: enabled)
Active: inactive (dead)

[XX@XX] systemctl status iptables
● iptables.service - IPv4 firewall with iptables
Loaded: loaded (/usr/lib/systemd/system/iptables.service; disabled; vendor preset: disabled)
Active: inactive (dead) since Wed 2015-09-02 23:43:13 CEST; 11min ago

SELinux není aktivní:
[XX@XX] /usr/sbin/sestatus
SELinux status: disabled

v hosts.deny nic není:
[XX@XX] cat /etc/hosts.deny

hosts.deny This file contains access rules which are used to

deny connections to network services that either use

the tcp_wrappers library or that have been

started through a tcp_wrappers-enabled xinetd.

The rules in this file can also be set up in

/etc/hosts.allow with a ‘deny’ option instead.

See ‘man 5 hosts_options’ and ‘man 5 hosts_access’

for information on rule syntax.

See ‘man tcpd’ for information on tcp_wrappers

SSH funguje:
systemctl status sshd
● sshd.service - OpenSSH server daemon
Loaded: loaded (/usr/lib/systemd/system/sshd.service; enabled; vendor preset: enabled)
Active: active (running) since Wed 2015-09-02 23:15:49 CEST; 46min ago

[XX@XX] ssh localhost
The authenticity of host ‘localhost (::1)’ can’t be established.
ECDSA key fingerprint is XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.
ECDSA key fingerprint is XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX.
Are you sure you want to continue connecting (yes/no)?

Napadá vás čím by to mohlo být?


#2

Pokusil jsem se ještě dle http://linoxide.com/linux-how-to/disable-ipv6-centos-fedora-rhel/ a http://www.server-world.info/en/note?os=Fedora_19&p=initial_conf&f=3 utnout ipv6 kdyby byl problém že to poslouchá jen na ipv6 a zatím také stále bez výsledku.

[XX@XX] netstat -plunt
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 662/sshd


#3

[s]
taková pitomina, ale poslouchá daemon na správném portu?


netstat -ntlp | grep sshd

[/s]

Jo, jsem slepej, Ty jsi to sem už posílal :slight_smile:

Má ten PC veřejnou IP? Není schovaný za nějakým firewallem?


#4

Ahoj, mám veřejnou…když na PC byl původně taky Debian, nebyl problém. Jsem za natem.

Aktuálně jsem asi dospěl k tomu, že možná problém bude na routeru. K němu bohužel nemám přístup, tak to ještě zkoušim dál ověřovat. Vypadá to, že všechny ostatná možnosti jsem snad vyřadil.


#5

Zdravim

Zkousel jsi tcpdump, jestli ti vubec prichazeji nejake packety na SSH portu na Fedore? Minimalne tim zjistis, kde je pravdepodobne problem, jestli na siti nebo na Fedore.

Pokud mas vic jak jeden interface, tak ti jeste muze kernel zahazovat packety, ktere prichazeji po jednom interfacu, ale kvuli spatnemu routovani maji odchazet po jinem. Tusim, ze rp_filter je defaultne zapnuty, ale nejsem ted u zadne Fedory, tak to neoverim. V takovem pripade v tcpdumpu uvidis jen prichozi packety.

Ze stejne site (uvnirt site za routerem, ne pouze z localhostu) jsi to zkousel overit? Podle toho, jak jsi to popsal by tam nemel byt problem na Fedore (nebo spis nevidim duvod, proc by to nemelo jit), spis to zni jako problem nekde na siti mezi tim Debianem a Fedorou, ale chybi nejaky blizsi popis toho scenare. Pokud je tam mezitim router, ktery drzi tu verejnou IP, a predtim to fungovalo, treba je ten router stale nastaveny propoustet prichozi porty na urcitou IP adresu ve vnitrni siti, zkusil bych te Fedore dat stejnou IP jako mel ten debian, ktery si tam mel predtim - samozrejme pokud je ted jina.

Pripadne me jeste napada, jestli mas vygenerovane SSH Server klice?

ls -l /etc/ssh/ssh_host_*

Tusim se tak deje automaticky pri prvnim spusteni SSH pres systemctl/init skript, ale pro jistotu to over a kdyztak si je vygeneruj.


#6

Jojo, hledal bych problem nekde na siti. Jestli jsi za natem, tak mozna neni spravne nastavene presmerovani.
Chyba, ze se spojeni timeoutovalo by imho nemela souviset se systemovym nastavenim (pokud tam daemon bezi a neni blokovany, coz by v tomto pripade melo platit).


#7

Díky moc za nasměrování. Problém je vyřešen. Změnila se vnitřní IP adresa a nebyla nastavena na routeru.


#8

I kdyz to v tomto pripade nebyl nasledujici problem, rad bych na nej upozornil -

K ssh serveru Fedory 21+ se neda prihlasit z dropbear klienta <=v2013.58, pokus o prihlaseni skonci chybou:

ssh: Connection to root@w.x.y.z exited: No auth methods could be used

Je to sice chyba v dropbearu, ale vzhledem k tomu, ze se muze vyskytovat na spouste embedded zarizeni, tak je o zabavu postarano.