Hello!
Általában a fenti hibát kapom, amikor be akarok ssh-zni egy szerveremre.
Viszont 5-6 próbálkozás után (akár közvetlenül egymás után) beenged.
A neten kutakodva azt találtam, hogy hosts.allow-val lehet gond, viszont az nekem üres. (Megjegyzésektől eltekintve.)
A szerveren Debian Etch van az összes biztonsági frissítéssel.
Van ötlete valakinek?
Miki
espakm@zawinul:~$ ssh -v hallg.inf.unideb.hu
OpenSSH_5.1p1 Debian-3ubuntu1, OpenSSL 0.9.8g 19 Oct 2007
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Applying options for *
debug1: Connecting to hallg.inf.unideb.hu [193.6.128.169] port 22.
debug1: Connection established.
debug1: identity file /home/espakm/.ssh/identity type -1
debug1: identity file /home/espakm/.ssh/id_rsa type 1
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: identity file /home/espakm/.ssh/id_dsa type -1
ssh_exchange_identification: Connection closed by remote host
espakm@zawinul:~$
- 3731 megtekintés
Hozzászólások
debian etch en hogy van ubuntu ssh ?
OpenSSH_5.1p1 Debian-3ubuntu1, OpenSSL 0.9.8g 19 Oct 2007
ráadásul 5.1 es openssh is debain lennyben van :>
Core2Duo T7100, 2.5G, Ubuntu 8.04, 2.6.27.6
- A hozzászóláshoz be kell jelentkezni
Fordítva:
A kliensen (zawinul) van ubuntu intrepid.
A szerveren (hallg) van az etch.
- A hozzászóláshoz be kell jelentkezni
hm télleg, hol megy hol nem érdekes, ilyennel nem találkoztam illetve folyamatosan szoktam
ugyanis mikrotik alól bessh-zni hol sikerül hol nem, de ezt mindig a mikrotik hülyeségének tudtam be
valamint akkor láttam még mikor a host.allow/deny fájlban volt korlátozva az ssh hozzáférhetőség
Core2Duo T7100, 2.5G, Ubuntu 8.04, 2.6.27.6
- A hozzászóláshoz be kell jelentkezni
Mármint a mikrotik alól hova?
Úgy látom, nem a klienssel van gond. A hibaüzenet szerint sem, illetve próbáltam egy régi fedora core 6-os gépről, de ugyanezt produkálja.
Vagy a mikrotik a szerver? Ha igen, milyen ssh verzió fut rajta?
Hátha van vmi közös.
- A hozzászóláshoz be kell jelentkezni
haha, ebbe en is sorra belefutottam ugy 3-4 eve. viszont azota nem lattam a hibat. :)
- A hozzászóláshoz be kell jelentkezni
Magától múlt el?
- A hozzászóláshoz be kell jelentkezni
reg volt, fogalmam sincs. meg ilyen debian potato volt, meg redhat 6.2...
- A hozzászóláshoz be kell jelentkezni
Keves a memoria, sshd nem tud forkolni.
- A hozzászóláshoz be kell jelentkezni
Nem hinném, 8 GB RAM van a gépben, bár ebből négyet egy xen-en futó másik oprendszer használ. És 16 GB swap.
$ free
total used free shared buffers cached
Mem: 3999744 3884028 115716 0 180284 1548516
-/+ buffers/cache: 2155228 1844516
Swap: 17735672 48 17735624
- A hozzászóláshoz be kell jelentkezni
Megoldva.
DDOS támadás volt.
Feltettem a Lennyben lévő fail2ban-t, mert az etch-ben lévőben nem volt erre szűrő. (Amúgy is pár hét múlva kiadják a lennyt.)
Bekapcsoltam az ssh-ddos nevű szűrőt, és a maxretry-t 2-re állítottam. Gyönyörűen bannolja most kifelé a hostokat, a hibaüzenet pedig teljesen megszűnt.
Szóval, ha ilyeneket láttok az auth.log-ban, akkor fail2ban!
Feb 5 22:36:40 hallg sshd[29284]: Did not receive identification string from 213.222.135.30
- A hozzászóláshoz be kell jelentkezni
De ha nem ddos, akkor akar le is lehet szarni ;-)
- A hozzászóláshoz be kell jelentkezni
Jahh, ilyen véleményeket találtam én is google-lel, csak kicsit szofisztikáltabban fogalmaztak. :-D
Csak miután volt, hogy 10. kísérletre engedett be, eléggé bosszantott.
- A hozzászóláshoz be kell jelentkezni
MaxStartups
- A hozzászóláshoz be kell jelentkezni
Ez lehetett, kösz!
Nálam az alapértelmezés volt. Ha jól értem, ha tíz autentikáció egyszerre volt folyamatban (max. két perc vagy sikertelenség után fejeződtek be), addig minden további kapcsolódási kísérletet eldobott.
A log alapján pár másodpercenként jöttek a kísérletek...
A LoginGraceTime-ot levettem 30 mp-re, a MaxStartups-ot egyelőre nem bántom.
- A hozzászóláshoz be kell jelentkezni