Dotaz: Připojení na ssh server pouze po ping

[Lada]

Řeším problém na Ubuntu 18 běžící jako virtuál na Proxmoxu. Na stanici se přes ssh připojím pouze pokud nejdřív kontaktuji stanici příkazem ping. Arp je v pořádku, kolize ip nebo mac adres není, Řešil už někdo něco podobného? Budu rád za každou radu.

---

---

Odpovědi

[Max]

Asi by to chtělo více informací. Co vypíše ssh, když se chceš připojit? Můžeš sem postnout výpis? A případně i podrobnější s "-vv" ?
Zdar Max

[Lada]

ssh -vvv SERVER
OpenSSH_7.9p1, OpenSSL 1.1.0i-fips  14 Aug 2018
debug1: Reading configuration data /home/XXX/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 25: Applying options for *
debug2: resolving "SERVER" port 22
debug2: ssh_connect_direct
debug1: Connecting to SERVER [10.6.1.16] port 22.
debug1: Connection established.
debug1: identity file /home/XXX/.ssh/id_rsa type 0
debug1: identity file /home/XXX/.ssh/id_rsa-cert type -1
debug1: identity file /home/XXX/.ssh/id_dsa type -1
debug1: identity file /home/XXX/.ssh/id_dsa-cert type -1
debug1: identity file /home/XXX/.ssh/id_ecdsa type -1
debug1: identity file /home/XXX/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/XXX/.ssh/id_ed25519 type -1
debug1: identity file /home/XXX/.ssh/id_ed25519-cert type -1
debug1: identity file /home/XXX/.ssh/id_xmss type -1
debug1: identity file /home/XXX/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
ssh_exchange_identification: read: Connection reset by peer

ping SERVER
PING SERVER.net1 (10.6.1.16) 56(84) bytes of data.
64 bytes from SERVER.net1 (10.6.1.16): icmp_seq=1 ttl=63 time=0.734 ms
64 bytes from SERVER.net1 (10.6.1.16): icmp_seq=2 ttl=64 time=0.358 ms
64 bytes from SERVER.net1 (10.6.1.16): icmp_seq=3 ttl=64 time=0.547 ms
^C
--- SERVER.net1 ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2025ms
rtt min/avg/max/mdev = 0.358/0.546/0.734/0.154 ms

ssh -vvv SERVER
OpenSSH_7.9p1, OpenSSL 1.1.0i-fips  14 Aug 2018
debug1: Reading configuration data /home/XXX/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 25: Applying options for *
debug2: resolving "SERVER" port 22
debug2: ssh_connect_direct
debug1: Connecting to SERVER [10.6.1.16] port 22.
debug1: Connection established.
debug1: identity file /home/XXX/.ssh/id_rsa type 0
debug1: identity file /home/XXX/.ssh/id_rsa-cert type -1
debug1: identity file /home/XXX/.ssh/id_dsa type -1
debug1: identity file /home/XXX/.ssh/id_dsa-cert type -1
debug1: identity file /home/XXX/.ssh/id_ecdsa type -1
debug1: identity file /home/XXX/.ssh/id_ecdsa-cert type -1
debug1: identity file /home/XXX/.ssh/id_ed25519 type -1
debug1: identity file /home/XXX/.ssh/id_ed25519-cert type -1
debug1: identity file /home/XXX/.ssh/id_xmss type -1
debug1: identity file /home/XXX/.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_7.9
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.6p1 Ubuntu-4ubuntu0.7
debug1: match: OpenSSH_7.6p1 Ubuntu-4ubuntu0.7 pat OpenSSH_7.0*,OpenSSH_7.1*,OpenSSH_7.2*,OpenSSH_7.3*,OpenSSH_7.4*,OpenSSH_7.5*,OpenSSH_7.6*,OpenSSH_7.7* compat 0x04000002
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to SERVER:22 as 'XXX'
debug3: hostkeys_foreach: reading file "/dev/null"
debug3: send packet: type 20
debug1: SSH2_MSG_KEXINIT sent
debug3: receive packet: type 20
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
...

[Max]

To je celé? Takže u "Connection established." to zamrzne a dál už nic nenastane?
Zdar Max

[Lada]

Ano, mám podezření, že to dělá starý linux openSUSE Leap 15.1. Když zadám ping, tak se spojení naváže. ARP tabulka je v pořádku, záznam MAC adresy serveru taky v pořádku.

[Max]

Jsem slepej. Nechápu, jak jsem mohl přehlédnout možnost rozbalení výpisu. Takže to končí na informaci o výměně verzí ssh. Tím pádem se nedohodnou na tom, v jaké verzi se má ssh nahodit. Ty tedy pošleš serveru info o své verzi klienta a klient čeká, až ti server pošle info o své verzi.
Toto značí problém na straně serveru, nebo síťový problém. Tj. buď nevhodně nastavené filtrování provozu, nebo nějaký síťový problém. Co se stane, když se zeptáš na verzi přes nc?

nc 10.6.1.16 22

Mělo by ti to vrátit jeden řádek s verzí ssh serveru.
Zdar Max

[Lada]

SSH spojení z openSUSE na jiné servery ve stejné síti přes ssh funguje bez problémů. Z jiné stanice např Debian 11 se na to Ubuntu připojím také v pořádku, jen mu nechutná spojení z openSUSE 15.1 na Ubuntu 18.04, opačně naváže spojení v pořádku. Je to záhada.

[czjaromir]

Ahoj zkus něco takového domovském adresáři/.ssh vytvořit soubor config s tímto obsahem: Host XXX.XXX.XXX.XXX (ip vzdálené stanice) HostKeyAlgorithms=+ssh-dss KexAlgorithms +diffie-hellman-group1-sha1

[czjaromir]

rozjelo se formátování takže znovu
Ahoj zkus něco takového domovském adresáři/.ssh vytvořit soubor config s tímto obsahem:
Host XXX.XXX.XXX.XXX (ip vzdálené stanice)
HostKeyAlgorithms=+ssh-dss
KexAlgorithms +diffie-hellman-group1-sha1

[Max]

Jaký má smysl vynucovat slabé šifrování, když to na šifrování nepadá?
Navíc by default toto bývá už hodně dlouho zakázáno, takže by se na server nemělo dát s takto obstarožním nastavením připojit.
Zdar Max

[czjaromir]

no jestli je ten problém pak se vyřeší

[Lada]

Děkuji za rady, ale divný je, že po pingu se spojení naváže. To mi nedává smysl v kolizi verzí či něco jiného. Nedám ping, spojení se odmitne, dám ping a spojení se naváže. Co ten ping provede jiného, jen si ověří MAC adresu, tu ale v arp tabulce už vidím.

[OldFrog {Ondra Nemecek}]

Logy ze serveru v okamžiku prvního pingu? Není tam zapnutý nějaký jednoduchý port-knocking?

[henk]

To by mohl být problém firewallu - často vidím pravidla related & estabilished.
To znamená, že pingem, který je povolený získáš některý z těchto stavů a pak už se přes FW dostaneš.
I když je to v rozporu s SSH výpisem výše (spojení se asi naváže), stejně bych zkusil dočasně vypnout na obou strojích FW.

[Lada]

Děkuji za tip, ale na straně SSH klienta i serveru není FW zapnut. A na server se z jiných stanic dostanu bez problémů. Ještě zprávy od příkazu

nc 10.6.1.16 22

openSUSE Leap 15.1 (spojení nejde):

nc -v  10.6.1.16 22
Connection to 10.6.1.16 22 port [tcp/ssh] succeeded!

Debian 11 (spojení v pořádku):

nc -v  10.6.1.16 22
SERVER [10.6.1.16] 22 (ssh) open
SSH-2.0-OpenSSH_7.6p1 Ubuntu-4ubuntu0.7

[Max]

Takže je to tak, máš tam síťový problém. Jseš si opravdu jist, že tam nemáš více zařízení se stejnou MAC adresou nebo IP adresou? Zkus si nainstalovat arpwatch, který ti bude logovat změny "MAC vs IP" v síti.
A pozor, nemusí jít nutně o kolizní MAC/IP na straně serveru, ale i na straně klienta.
Zdar Max

[Lada]

Dík, budu to sledovat, ale moc se mi to nezdá.

[čavo]

Záhada vyřešena, na SSH SERVERU jsem měl blbě nastavenu ip adresu ethernet 10.6.1.16/26 místo správně 10.6.1.16/24 a tak někdy (?) jsem se z adresy 10.6.1.160/24 na server dostat. Trkla mě až hlášení arpwatch

arpwatch: bogon 10.6.1.160 10:fe:ed:07:c9:67 ens18

Maxi, moc děkuji. Taková blbost a několik dní v čudu...

[X]

Spojeni je v pohode:

Connection to 10.6.1.16 22 port [tcp/ssh] succeeded!

Ale, neco ti do toho spojeni leze, SSH to neni.. Co posloucha na serveru na portu 22 za sluzbu? Klidne si na tom serveru pust paralelne jeste tcpdump at mame jistotu, ze to neni nekde mezi.

[Peter Golis]

Toto mi robilo keď som vyklonoval VM a nechal rovnaké MAC Adresy. Alebo keď som zabudol zmeniť Machine ID (hostnamectl). Niekde to išlo v pohode, a niekde až po pingu.

Nebude to takáto drobnosť?

[Lada]

Děkuji za tip. MAC adresa je jednoznačná v celé síti. Na ten Machine ID se ještě podívám, ale vytvářel jsem nový VM a byla by to velká náhoda. Divný je, že z jiných stanic se připojí bez problémů.