ssh über lokales Netz funzt nicht

Hi,
ich habe suse 10.3 installiert und da wurde ssh standardmäßig mitinstalliert. Lokales anmelden per ssh funktioniert, jedoch über das lokale Netz nicht. Auf dem WinXP möchte ich mich per Putty einloggen (mit username und Passwort) aber es kommt immer ein Connection timed out. Sniffern am Linux-Rechner ergab, dass ein TCP-Paket mit SYN-Bit ankommt aber es wird nie geantwortet.
Firewall wurde am Linux-Rechner deaktiviert. Pingen gegenseitig und Samba funktioniert !
Was kann der Fehler sein ?
Gruß
frabe74

Na wenn du schon einen Sniffer benutzen kannst, denke ich, sollte es bis zur Firewall nicht weit sein :-D Irgendwo im yast kann man das dann entsprechend einstellen.

Firewall ist deaktiviert, lt. yast

Meldet sich denn der SSH-Server, wenn Du 'telnet IP 22' in einer Kommandozeile eingibst? Was sagt '/etc/init.d/sshd status' als root auf dem Linuxrechner?

Hallo rolle,
also telnet <IP> 22 auf dem Linux-Rechner funzt, aber auf dem Windows-Rechner kommt nur ein Verbindung fehlgeschlagen.
Bei "/etc/init.d/sshd status" kommt
Checking for service sshd running
Ich weis nicht weiter
Gruß
frabe74

Dann poste doch mal Deine sshd_conf. Eventuell stimmt das was nicht. Und steht etwas in den logs dazu?

hier ist die sshd_config:

# $OpenBSD: sshd_config,v 1.74 2006/07/19 13:07:10 dtucker Exp $

# This is the sshd server system-wide configuration file. See
# sshd_config(5) for more information.

# This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin

# The strategy used for options in the default sshd_config shipped with
# OpenSSH is to specify options with their default value where
# possible, but leave them commented. Uncommented options change a
# default value.

Port 22
Protocol 2
#AddressFamily any
ListenAddress 192.168.1.11
#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
#MaxAuthTries 6

#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 yes
#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, account processing,
# and session processing. If this is enabled, PAM authentication will
# be allowed through the ChallengeResponseAuthentication and
# PasswordAuthentication. Depending on your PAM configuration,
# PAM authentication via ChallengeResponseAuthentication may bypass
# the setting of "PermitRootLogin without-password".
# If you just want the PAM account and session checks to run without
# PAM authentication, then enable this but set PasswordAuthentication
# and ChallengeResponseAuthentication to 'no'.
UsePAM no

#AllowTcpForwarding yes
#GatewayPorts no
X11Forwarding yes
#X11DisplayOffset 10
#X11UseLocalhost yes
#PrintMotd yes
#PrintLastLog yes
#TCPKeepAlive yes
#UseLogin no
#UsePrivilegeSeparation yes
#PermitUserEnvironment no
#Compression delayed
#ClientAliveInterval 0
#ClientAliveCountMax 3
#UseDNS yes
#PidFile /var/run/sshd.pid
#MaxStartups 10
#PermitTunnel no

# no default banner path
#Banner /some/path

# override default of no subsystems
Subsystem sftp /usr/lib/ssh/sftp-server

# This enables accepting locale enviroment variables LC_* LANG, see sshd_config(5).
AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES
AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT
AcceptEnv LC_IDENTIFICATION LC_ALL

# Example of overriding settings on a per-user basis
#Match User anoncvs
# X11Forwarding no
# AllowTcpForwarding no
# ForceCommand cvs server

In /var/log/messages steht nur, dass der Dienst gestartet wurde und auf 192.168.1.11 auf Port 22 lauscht

Hi,

dein ssh-Server (Linux-Rechner) ist die 192.168.1.11 - richtig?
und der sshd lauscht ausschließlich auf Anforderungen von der IP 192.168.1.11 ... (ListenAddress 192.168.1.11)

MfG Peter

hi,
also, der Linux-Rechner bekommt vom DSL-Router per DHCP immer die 192.168.1.11
Vorher war in der config 0.0.0.0 eingetragen, das habe ich durch die IP-Adresse geändert, hab's gerade mit 0.0.0.0 getestet, funktioniert auch nicht
der Windows-Rechner hat die 192.168.1.10

frabe74 schrieb:

der Windows-Rechner hat die 192.168.1.10

Zum Vergrößern anklicken....

Tja, da 10 != 11 ignoriert der sshd Anfragen von allen IPs (außer der eigenen, *.11)

Was nicht wirklich Sinn ergibt, da du offensichtlich von einer anderen IP aus connecten willst. :mrgreen:

Also solltest du den ListenAddress Eintrag auskommentieren (oder vernünftige Werte eingeben, siehe man sshd_config), danach sshd neu starten.

also, soweit ich die Option listenaddress verstehe, ist das die IP-Adresse des ssh-Servers, nicht die der Clients.
Also wenn der Server mehrere IP-Adressen hat, kann man hier die IP-Adressen angeben, die auf Port 22 antworten, das hat nichts mit der IP-Adresse des Clients zu tun. Der Linux-Rechner hat die .11, der Windows-Rechner die .10
Mit der .10-Adresse kann man den sshd gar nicht starten !
Hab gerade alle möglichen Kombinationen ausprobiert, aber es funktioniert einfach nicht :evil:

Warum ignorierst du den Rat, den dir hier zwei Leute geben?

ich glaub ich steh auf der leitung !!!
Also, ich hab die Option ListenAddress auf 0.0.0.0 gesetzt, dann auskommentiert, dann auf 192.168.1.10 gesetzt (dann startet sshd garnicht) auf 192.168.1.11 gesetzt, immer dasgleiche Ergebnis -> vom Windows Rechner aus kommt mit Putty ein Connection Timed out
Welchen Rat habe ich noch nicht befolgt ?

Hast Du in Putty auch ganz sicher die richtige SSH-Protokollversion eingestellt?

Vielleicht noch einen Hinweis:

Ich würde zuerst - bis alles funktioniert - alle Einstellungen in der Original sshd_config lassen, wie sie sind. Also weder User, noch IPs noch Protokollversionen, noch das Login mit Benutzername/PW usw. verbieten bzw. aussperren.
Mit dieser config MUSS es funktionieren, wenn nicht gerade :22 gesperrt ist, oder vergessen wurde den sshd zu starten . Und dann funktioniert es auch mit putty oder winSCP.

Ja und dann ..., kannst du die vielen Hinweise hier im Forum zur Härtung des sshd durchsetzen.

MfG Peter

Hi,
hab mal den Debuglevel auf DEBUG3 gesetzt, jetzt erscheint in /var/log/messages folgende Meldung:

Dec 6 19:36:43 Vigor11 avahi-daemon[3190]: Loading service file /etc/avahi/services/sftp-ssh.service.
Dec 6 19:36:43 Vigor11 avahi-daemon[3190]: Loading service file /etc/avahi/services/ssh.service.
Dec 6 19:36:45 Vigor11 avahi-daemon[3190]: Service "Vigor11" (/etc/avahi/services/ssh.service) successfully established.
Dec 6 19:36:45 Vigor11 avahi-daemon[3190]: Service "SFTP File Transfer on Vigor11" (/etc/avahi/services/sftp-ssh.service) successfully established.
Dec 6 19:36:45 Vigor11 sshd[3378]: debug1: Bind to port 22 on 0.0.0.0.
Dec 6 19:36:45 Vigor11 sshd[3378]: Server listening on 0.0.0.0 port 22.
Dec 6 19:36:46 Vigor11 xinetd[3422]: Reading included configuration file: /etc/xinetd.d/ssh [file=/etc/xinetd.d/ssh] [line=14]
Dec 6 19:36:46 Vigor11 xinetd[3422]: Must specify a server in ssh

Was bedeutet die letzte Zeile, muss ich irgendwo noch den Server spezifizieren ?

frabe74 schrieb:

Dec 6 19:36:46 Vigor11 xinetd[3422]: Reading included configuration file: /etc/xinetd.d/ssh [file=/etc/xinetd.d/ssh] [line=14]
Dec 6 19:36:46 Vigor11 xinetd[3422]: Must specify a server in ssh

Zum Vergrößern anklicken....

Was hat der xinetd da rumzumaulen? Hast du sshd als Subservice vom xinetd konfiguriert? Was steht in /etc/xinetd.d/ssh (und wo kommt die her)?

Ich bin etwas verwirrt, was der xinetd mit dem sshd zu tun hat. Wird der sshd nicht als eigenes Initscript gestartet?

vorsicht, richtig lesen
da steht ssh und nicht sshd
ssh - ist das Clientprogramm
sshd - ist der Serverdienst
Aber trotzdem ist das komisch !
Hab jetzt SSH deinstalliert und wieder neu installiert, also die sshd_config ist jetzt wieder jungfräulich, aber es funzt einfach nicht
Hab zum Spass mal Knoppix 5.0 gebootet, den SSHD gestartet, funktionierte sofort !

In /var/log/messages habe ich noch folgende Fehlermeldung gefunden, aber seit der neuinstallation von ssh kann ich es nicht mehr reproduzieren:
Dec 6 19:00:59 Vigor11 sshd[3398]: error: Bind to port 22 on 192.168.1.10 failed: Cannot assign requested address.
Dec 6 19:00:59 Vigor11 sshd[3398]: fatal: Cannot bind any address.

Kann damit einer was anfangen ?
Die 192.168.1.10 ist die IP von meinem Windows-Rechner.

aah, jetzt hab ich die Fehlermeldung reproduzieren können, wenn man bei ListenAddress eine IP-Adresse verwendet, die am Server nicht konfiguriert ist, dann kommt diese Fehlermeldung, eigentlich logisch !
Also bei ListenAddress muss definitiv die IP-Adresse des Servers rein oder 0.0.0.0