SSH killt Server

[Sven_R]

hallo

ich hab vor ein paar tagen mitbekommen das mein ssh client meinen
server killt.
ich hab des öffteren auf einigen virtuellen servern einige sachen getestet und auch
einige dateien unter kde mit dem konqi per sftp übertragen.

nach einiger zeit hab ich immer wieder vom syslog die fehler meldung


can´t allocate memory

bekommen

beim forschen mit top und ps hab ich dann festgestellt das mehr als 40 ssh
verbindungen vom clienten zum server gingen.

erst ein killen per hand hat das wieder korrigiert.

es hat wohl den anschein das die client verbindungen zum server auf ewig offen
geblieben werden, wenn ich die fehlermeldungen nich gesehen hätte.


KANN man das irgend wie abstellen, jede sftp verbindung per hand killen ist mir
dann doch zu viel.

cu

[downtown]

Zeig mal deine sshd2_config und installiere jeweils die aktuellen Versionen des Servers und Clients.

[Sven_R]

hallo

hier meine aktuelle server und client sshd_conf


#Port 22
Protocol 2
#ListenAddress 0.0.0.0
#ListenAddress ::
# HostKey for protocol version 1
#HostKey /etc/ssh/ssh_host_key
# HostKeys for protocol version 2
#HostKey /etc/ssh/ssh_host_rsa_key
#HostKey /etc/ssh/ssh_host_dsa_key
# Lifetime and size of ephemeral version 1 server key
#KeyRegenerationInterval 1h
#ServerKeyBits 768
# Logging
#obsoletes QuietMode and FascistLogging
#SyslogFacility AUTH
#LogLevel INFO
# Authentication:
#LoginGraceTime 2m
#PermitRootLogin yes
#StrictModes yes
#RSAAuthentication yes
#PubkeyAuthentication yes
#AuthorizedKeysFile .ssh/authorized_keys
# For this to work you will also need host keys in /etc/ssh/ssh_known_hosts
#RhostsRSAAuthentication no
# similar for protocol version 2
#HostbasedAuthentication no
# Change to yes if you don't trust ~/.ssh/known_hosts for
# RhostsRSAAuthentication and HostbasedAuthentication
#IgnoreUserKnownHosts no
# Don't read the user's ~/.rhosts and ~/.shosts files
#IgnoreRhosts yes
# To disable tunneled clear text passwords, change to no here!
PasswordAuthentication no
#PermitEmptyPasswords no
# Change to no to disable s/key passwords
#ChallengeResponseAuthentication yes
# Kerberos options
#KerberosAuthentication no
#KerberosOrLocalPasswd yes
#KerberosTicketCleanup yes
#KerberosGetAFSToken no
# GSSAPI options
#GSSAPIAuthentication no
#GSSAPICleanupCredentials yes
# Set this to 'yes' to enable support for the deprecated 'gssapi' authentication
# mechanism to OpenSSH 3.8p1. The newer 'gssapi-with-mic' mechanism is included
# in this release. The use of 'gssapi' is deprecated due to the presence of
# potential man-in-the-middle attacks, which 'gssapi-with-mic' is not susceptible to.
#GSSAPIEnableMITMAttack no
# Set this to 'yes' to enable PAM authentication (via challenge-response)
# and session processing. Depending on your PAM configuration, this may
# bypass the setting of 'PasswordAuthentication' and 'PermitEmptyPasswords'
UsePAM yes
#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression yes
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
# no default banner path
#Banner /some/path
# override default of no subsystems
Subsystem sftp /usr/lib/ssh/sftp-server


und meine aktuelle ssh_conf vom clienten und server



# Configuration data is parsed as follows:
# 1. command line options
# 2. user-specific file
# 3. system-wide file
# Any configuration value is only changed the first time it is set.
# Thus, host-specific definitions should be at the beginning of the
# configuration file, and defaults at the end.
# Site-wide defaults for various options
Host *
# ForwardAgent no
# ForwardX11 no
# If you do not trust your remote host (or its administrator), you
# should not forward X11 connections to your local X11-display for
# security reasons: Someone stealing the authentification data on the
# remote side (the "spoofed" X-server by the remote sshd) can read your
# keystrokes as you type, just like any other X11 client could do.
# Set this to "no" here for global effect or in your own ~/.ssh/config
# file if you want to have the remote X11 authentification data to
# expire after two minutes after remote login.
ForwardX11Trusted yes

# RhostsRSAAuthentication no
# RSAAuthentication yes
# PasswordAuthentication yes
# HostbasedAuthentication no
# BatchMode no
# CheckHostIP yes
# AddressFamily any
# ConnectTimeout 0
# StrictHostKeyChecking ask
# IdentityFile ~/.ssh/identity
# IdentityFile ~/.ssh/id_rsa
# IdentityFile ~/.ssh/id_dsa
# Port 22
Protocol 2
# Cipher 3des
# Ciphers aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc
# EscapeChar ~
# GSSAPIAuthentication no
# GSSAPIDelegateCredentials no
# Set this to 'yes' to enable support for the deprecated 'gssapi' authentication
# mechanism to OpenSSH 3.8p1. The newer 'gssapi-with-mic' mechanism is included
# in this release. The use of 'gssapi' is deprecated due to the presence of
# potential man-in-the-middle attacks, which 'gssapi-with-mic' is not susceptible to.
# GSSAPIEnableMITMAttack no


als system läuft hier suse 9.0
das merkwürdige ist das ich die probleme mit 8.2 auf dem server und dem clienten
nicht hatte
cu

[IT-Low]

Schalte mal unnötige Serverdienste bzw. speicherhungrige Prozesse ab (falls möglich) oder kontaktiere mal deinen vserver-Provider, wegen diesem Problem.

[Sven_R]

Schalte mal unnötige Serverdienste bzw. speicherhungrige Prozesse ab (falls möglich)
:confused: :confused: :confused:
da kann ich so viel abschalten wie ich will, anscheinend versteht ihr mein problem nicht
so richtig, der sshd macht keine probleme.
mit dem kann ich verbindungen aufbauen und auch wieder ordentlich beenden oder,
wenn es sein muss, auch KILLEN. der sshd auf dem server beendet sie von allein,
nach einer gewissen zeit.


:( MEIN grosses problem ist der SSH client bzw der sftp client.
es hat den anschein das dieser absolut keinen timeout kennt, und alle verbindungen
auf EWIG offen hällt.

ich will ja nur wissen wie man das dem ssh clienten abgewöhnen kann, MEHR NICHT



... kontaktiere mal deinen vserver-Provider, wegen diesem Problem.


NA SUPER, dann ruf ich MICH mal selber an :mad:, und frage bei MIR im support mal nach :mad:

die virtuellen server stehen bei mir ca. 5 meter weiter im RZ
sorry, aber ich hab echt die schnautze voll.
ich schlag mich mit diesem problem jetzt seit fast 2 wochen rum.
ich find absolut nichts im WWW oder anderen diversen foren.

cu

[Napf]

Hast du denn schon mal mit dem Wert rumgespielt:
# ConnectTimeout 0

Ansonsten wirklich mal ein update der ssh komponenten draufhauen.

[bla!zilla]

NA SUPER, dann ruf ich MICH mal selber an :mad:, und frage bei MIR im support mal nach :mad:


Immer fluffig bleiben mein Freund. Wir sind hier nicht dein persönliches Support-Forum.



die virtuellen server stehen bei mir ca. 5 meter weiter im RZ
sorry, aber ich hab echt die schnautze voll.
ich schlag mich mit diesem problem jetzt seit fast 2 wochen rum.
ich find absolut nichts im WWW oder anderen diversen foren.


Schade. Dann würde ich mal mit dem Troubleshooting anfangen. Als sehr sinnvoll erweisen sich immer Debugginginformationen. Aktivier, nach Möglichkeit, mal das Debugging vom SSHd. Dann siehst du evtl. warum die Verbindung nicht getrennt wird. Laufen da in irgendeiner Form Paketfilter die evtl. was wegfiltern? Mal eine Trafficanalyse mit tcpdump gemacht?

[Stormbringer]

Definiere doch bestimmte sshd Angaben, gemäß 'man sshd_config', um Probleme mit dem sshd auszuschließen (btw: welche Version nutzt Du?):


...
ListenAddress
Specifies the local addresses sshd should listen on. The follow-
ing forms may be used:

ListenAddress host|IPv4_addr|IPv6_addr
ListenAddress host|IPv4_addr:port
ListenAddress [host|IPv6_addr]:port

If port is not specified, sshd will listen on the address and all
prior Port options specified. The default is to listen on all
local addresses. Multiple ListenAddress options are permitted.
Additionally, any Port options must precede this option for non
port qualified addresses.

...
LogLevel
Gives the verbosity level that is used when logging messages from
sshd. The possible values are: QUIET, FATAL, ERROR, INFO, VER-
BOSE, DEBUG, DEBUG1, DEBUG2 and DEBUG3. The default is INFO.
DEBUG and DEBUG1 are equivalent. DEBUG2 and DEBUG3 each specify
higher levels of debugging output. Logging with a DEBUG level
violates the privacy of users and is not recommended.

...
MaxStartups
Specifies the maximum number of concurrent unauthenticated con-
nections to the sshd daemon. Additional connections will be
dropped until authentication succeeds or the LoginGraceTime
expires for a connection. The default is 10.

Alternatively, random early drop can be enabled by specifying the
three colon separated values ``start:rate:full'' (e.g.,
"10:30:60"). sshd will refuse connection attempts with a proba-
bility of ``rate/100'' (30%) if there are currently ``start''
(10) unauthenticated connections. The probability increases lin-
early and all connection attempts are refused if the number of
unauthenticated connections reaches ``full'' (60).
...
Subsystem
Configures an external subsystem (e.g., file transfer daemon).
Arguments should be a subsystem name and a command to execute
upon subsystem request. The command sftp-server(8) implements
the ``sftp'' file transfer subsystem. By default no subsystems
are defined. Note that this option applies to protocol version 2
only.

SyslogFacility
Gives the facility code that is used when logging messages from
sshd. The possible values are: DAEMON, USER, AUTH, LOCAL0,
LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. The
default is AUTH.
...

Ansonsten kann ich mich bla!zillas statements nur anschließen!
Wenn Du dir schon 2 Wochen gibst, solltest Du dem Forum auch Zeit geben.

[Sven_R]

hallo



Immer fluffig bleiben mein Freund. Wir sind hier nicht dein persönliches
Support-Forum.

bin ich ja, nur der schei** sftp client raubt mir echt den letzten NERV :o :o



Dann würde ich mal mit dem Troubleshooting anfangen. Als sehr sinnvoll erweisen
sich immer Debugginginformationen. Aktivier, nach Möglichkeit, mal das Debugging
vom SSHd. Dann siehst du evtl. warum die Verbindung nicht getrennt wird.
Laufen da in irgendeiner Form Paketfilter die evtl. was wegfiltern?
Mal eine Trafficanalyse mit tcpdump gemacht?

endlich mal eine richtung, wo ich anfangen könnte.
packetfilter laufen definitiv nicht.
auf die idee mit tcpdump hät ich auch selber kommen können :cool:



Hast du denn schon mal mit dem Wert rumgespielt:
# ConnectTimeout 0

ÄH NÖÖÖÖ
werd ich aber mal versuchen.

die ssh man seiten hab ich auch schon durch, aber wer dem englischen nicht voll
mächtig ist dem kann das auch kaum weiter helfen.

bei solchen problemen ist deshalb auch immer google.de mein freund inklusive der
sprachtools.

ich werd mich nachher mal gleich ans schrauben machen.

cu