SSH vypadky serveru a nasledne zvlastni chovani [vyřešeno]

[bone]

Pri pripojeni pres SSH dojde po nekolika minutach k vypadku

Kód: [Vybrat]

mercury:/var/log# uptime
 10:46:33 up 5 days, 12:28,  3 users,  load average: 0.01, 0.02, 0.00
mercury:/var/log# Read from remote host XXX.XXX.XXX.XXX: Connection reset by peer
Connection to XXX.XXX.XXX.XXX closed.
bone@earth:~$ ping XXX.XXX.XXX.XXX
PING XXX.XXX.XXX.XXX (XXX.XXX.XXX.XXX) 56(84) bytes of data.

--- XXX.XXX.XXX.XXX ping statistics ---
18 packets transmitted, 0 received, 100% packet loss, time 17026ms

Connection reset by peer povetsinou znamena ztratu spojeni, nemyslim ale ze k ni dochazi, zvlast v takovych pravidelnych intervalech.

Zkousel jsem preinstalovat SSH, to nepomohlo.
Dale upravit konfigurak SSH - zejmena vlastnosti:

Kód: [Vybrat]

KeepAlive Yes
KeepTCPConnection Yes
Dalsim podivem pro me je, ze po ztrate spojeni se vygeneruji nove RSA klice a to i presto ze jsem prenastavil volbu

Kód: [Vybrat]

KeyRegenerationInterval 0 (tzn. Klic se nevytvari novy)

Co je ale jeste zvlastnejsi se mi zda fakt, ze nekolik minut po vypadku neni mozne se na stroj napriklad pingnout, jakoby odmital pripojeni do site? Pokud ale pracuji pres VNC, k zadnym vypadkum nedochazi.

Pro uplnost pridavam konfiguracni soubor sshd:

Kód: [Vybrat]

mercury:~# cat /etc/ssh/sshd_config
##Pridano kvuli castym resetum (po trech minutach??) - Connection closed by peer.
KeepAlive yes

# Package generated configuration file
# See the sshd(8) manpage for details

# What ports, IPs and protocols we listen for
Port 22
# Use these options to restrict which interfaces/protocols sshd will bind to
#ListenAddress ::
#ListenAddress 0.0.0.0
Protocol 2
# HostKeys for protocol version 2
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
#Privilege Separation is turned on for security
UsePrivilegeSeparation yes

# Lifetime and size of ephemeral version 1 server key
KeyRegenerationInterval 0
ServerKeyBits 768

# Logging
SyslogFacility AUTH
LogLevel INFO

# Authentication:
LoginGraceTime 120
PermitRootLogin yes
StrictModes yes

RSAAuthentication yes
PubkeyAuthentication yes
#AuthorizedKeysFile     %h/.ssh/authorized_keys

# Don't read the user's ~/.rhosts and ~/.shosts files
IgnoreRhosts yes
# For this to work you will also need host keys in /etc/ssh_known_hosts
RhostsRSAAuthentication no
# similar for protocol version 2
HostbasedAuthentication no
# Uncomment if you don't trust ~/.ssh/known_hosts for RhostsRSAAuthentication
#IgnoreUserKnownHosts yes

# To enable empty passwords, change to yes (NOT RECOMMENDED)
PermitEmptyPasswords no

# Change to yes to enable challenge-response passwords (beware issues with
# some PAM modules and threads)
ChallengeResponseAuthentication no

# Change to no to disable tunnelled clear text passwords
#PasswordAuthentication yes

# Kerberos options
#KerberosAuthentication no
#KerberosGetAFSToken no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes

# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes

#defaultne X11Forwarding yes
X11Forwarding no
X11DisplayOffset 10
PrintMotd no
PrintLastLog yes
TCPKeepAlive yes

#UseLogin no

#MaxStartups 10:30:60
#Banner /etc/issue.net

# Allow client to pass locale environment variables
AcceptEnv LANG LC_*

Subsystem sftp /usr/lib/openssh/sftp-server

UsePAM yes

Pokud ma kdokoli napad jak to resim, sem s nim prosim, zacinam byt docela zoufaly a stravil jsem nad tim opravdu hodne casu:(

[Petr Merlin Vaněček]

Vypadá to na výpadek konektivity.
Mrkněte do logů - jestli tam není něco ve smyslu eth0: link down - špatný kabel

V každém případě bych to neodhadoval na chybu toho stroje (pokud není mrtvá síťová karta), ale na chybu někde kousek dál od něj - špatný kabel, špatný switch, špatný spoj ... ale to vše by měl řešit ISP.

[bone]

Dekuji za odpoved,
chyba byla v ISP, pridelil mi IP adresu, kterou pouzival nekdo jiny.

[Petr Merlin Vaněček]

Super provider
označuji za vyřešené