PUTTY062 Anmeldung mit SSH an UBUNTU12.10 braucht zwei Versuche
Hallo Admins. Ich habe mich heute wegen eines Problems mit meinem SAMBA Server hier angemeldet. Das Problem habe ich durch googlen nicht lösen können, darum meine Frage hier.
Ich betreibe einen UBUNTU 12.10 server mit SAMBA3.6.6. im kleinen Windows Netzwerk.
Zur Administration des entfernt platzierten Servers benutze ich von einem Win 7 Rechner aus "putty062" mit SSH und direkter IP Angabe des Servers.
Dies funktioniert soweit ohne Probleme aber:
Jede Anmeldung am Server benötigt zwei Versuche von mir. Das bedeutet ich starte putty, nach ca. 3-4 Sekunden öffnet sich die Putty-Oberfläche (was mir langsam vorkommt). Nun wähle meine vordefinierte Einstellung im putty frontend zum server durch Doppelklick, worauf sich sofort die Eingabeaufforderung öffnet. Nun dauert es einige Sekunden (...über 10 schätze ich) bis ein Timeout gemeldet wird. Die Eingabeaufforderung bleibt dabei leer (schwarz - keine Textausgabe). Wenn ich den Netbios Namen verwende ist das Verhalten identisch.
Erst wenn ich das Vorgehen wiederhole, bekomme ich in der Eingabeaufforderung auch das Login angeboten. Ab da läuft alles normal.
Wenn ich innerhalb einer nicht zu langen Zeit (geschätzt so ein paar Minuten) eine weitere Verbindung öffne funktioniert es auf Anhieb. Erst nach längerer Zeit benötige ich wieder zwei Versuche.
Kennt jemand dieses Verhalten und die Ursache dafür?
Gruß
Christian
Ich betreibe einen UBUNTU 12.10 server mit SAMBA3.6.6. im kleinen Windows Netzwerk.
Zur Administration des entfernt platzierten Servers benutze ich von einem Win 7 Rechner aus "putty062" mit SSH und direkter IP Angabe des Servers.
Dies funktioniert soweit ohne Probleme aber:
Jede Anmeldung am Server benötigt zwei Versuche von mir. Das bedeutet ich starte putty, nach ca. 3-4 Sekunden öffnet sich die Putty-Oberfläche (was mir langsam vorkommt). Nun wähle meine vordefinierte Einstellung im putty frontend zum server durch Doppelklick, worauf sich sofort die Eingabeaufforderung öffnet. Nun dauert es einige Sekunden (...über 10 schätze ich) bis ein Timeout gemeldet wird. Die Eingabeaufforderung bleibt dabei leer (schwarz - keine Textausgabe). Wenn ich den Netbios Namen verwende ist das Verhalten identisch.
Erst wenn ich das Vorgehen wiederhole, bekomme ich in der Eingabeaufforderung auch das Login angeboten. Ab da läuft alles normal.
Wenn ich innerhalb einer nicht zu langen Zeit (geschätzt so ein paar Minuten) eine weitere Verbindung öffne funktioniert es auf Anhieb. Erst nach längerer Zeit benötige ich wieder zwei Versuche.
Kennt jemand dieses Verhalten und die Ursache dafür?
Gruß
Christian
Kommentieren
Teilen
Auf Facebook teilen
Auf X (Twitter) teilen
Auf Reddit teilen
Auf Linkedin teilenBitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 202456
Url: https://administrator.de/forum/putty062-anmeldung-mit-ssh-an-ubuntu12-10-braucht-zwei-versuche-202456.html
Ausgedruckt am: 30.04.2025 um 02:04 Uhr
8 Kommentare
Neuester Kommentar
Hallo,
dein Problem ist also SSH und nicht Samba...
Wahrscheinlich liegt es daran das der bei Ubuntu eingestellte DNS Server mit reverse lookups überfordert ist bzw. deine Windows 7 Kiste dort nicht zu finden ist. Guckst du hier:
http://forum.ivorde.ro/ssh-disable-dns-reverse-lookups-t71.html
oder saubere reverse mappings im DNS einrichten.
Gruß
Andi
dein Problem ist also SSH und nicht Samba...
Wahrscheinlich liegt es daran das der bei Ubuntu eingestellte DNS Server mit reverse lookups überfordert ist bzw. deine Windows 7 Kiste dort nicht zu finden ist. Guckst du hier:
http://forum.ivorde.ro/ssh-disable-dns-reverse-lookups-t71.html
oder saubere reverse mappings im DNS einrichten.
Gruß
Andi
Hallo Andi,
der Eintrag ist schon vorhanden. Was ich nun getestet habe ist der Start im debug modus.
Das bringt mir folgende Ausgabe:
debug2: load_server_config: filename /etc/ssh/sshd_config
debug2: load_server_config: done config len = 694
debug2: parse_server_config: config /etc/ssh/sshd_config len 694
debug3: /etc/ssh/sshd_config:5 setting Port 22
debug3: /etc/ssh/sshd_config:9 setting Protocol 2
debug3: /etc/ssh/sshd_config:11 setting HostKey /etc/ssh/ssh_host_rsa_key
debug3: /etc/ssh/sshd_config:12 setting HostKey /etc/ssh/ssh_host_dsa_key
debug3: /etc/ssh/sshd_config:13 setting HostKey /etc/ssh/ssh_host_ecdsa_key
debug3: /etc/ssh/sshd_config:15 setting UsePrivilegeSeparation yes
debug3: /etc/ssh/sshd_config:18 setting KeyRegenerationInterval 3600
debug3: /etc/ssh/sshd_config:19 setting ServerKeyBits 768
debug3: /etc/ssh/sshd_config:22 setting SyslogFacility AUTH
debug3: /etc/ssh/sshd_config:23 setting LogLevel INFO
debug3: /etc/ssh/sshd_config:26 setting LoginGraceTime 120
debug3: /etc/ssh/sshd_config:27 setting PermitRootLogin yes
debug3: /etc/ssh/sshd_config:28 setting StrictModes yes
debug3: /etc/ssh/sshd_config:30 setting RSAAuthentication yes
debug3: /etc/ssh/sshd_config:31 setting PubkeyAuthentication yes
debug3: /etc/ssh/sshd_config:35 setting IgnoreRhosts yes
debug3: /etc/ssh/sshd_config:37 setting RhostsRSAAuthentication no
debug3: /etc/ssh/sshd_config:39 setting HostbasedAuthentication no
debug3: /etc/ssh/sshd_config:44 setting PermitEmptyPasswords no
debug3: /etc/ssh/sshd_config:48 setting ChallengeResponseAuthentication no
debug3: /etc/ssh/sshd_config:63 setting X11Forwarding yes
debug3: /etc/ssh/sshd_config:64 setting X11DisplayOffset 10
debug3: /etc/ssh/sshd_config:65 setting PrintMotd no
debug3: /etc/ssh/sshd_config:66 setting PrintLastLog yes
debug3: /etc/ssh/sshd_config:67 setting TCPKeepAlive yes
debug3: /etc/ssh/sshd_config:74 setting AcceptEnv LANG LC_*
debug3: /etc/ssh/sshd_config:76 setting Subsystem sftp /usr/lib/openssh/sftp-server
debug3: /etc/ssh/sshd_config:87 setting UsePAM yes
debug3: /etc/ssh/sshd_config:90 setting UseDNS no
debug1: sshd version OpenSSH_6.0p1 Debian-3ubuntu1
debug3: Incorrect RSA1 identifier
debug1: read PEM private key done: type RSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: private host key: type 1 RSA
debug3: Incorrect RSA1 identifier
debug1: read PEM private key done: type DSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: private host key: #1 type 2 DSA
debug3: Incorrect RSA1 identifier
debug1: read PEM private key done: type ECDSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.ECDSA-256
debug1: Checking blacklist file /etc/ssh/blacklist.ECDSA-256
debug1: private host key: #2 type 3 ECDSA
debug1: rexec_argv='/usr/sbin/sshd'
debug1: rexec_argv[1]='-ddd'
debug3: oom_adjust_setup
Set /proc/self/oom_score_adj from 0 to -1000
debug2: fd 3 setting O_NONBLOCK
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug2: fd 4 setting O_NONBLOCK
debug3: sock_set_v6only: set socket 4 IPV6_V6ONLY
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
Beim ersten Verbindungsversuch mittels putty kommt hier keinerlei weitere Ausgabe. Auch nicht nach dem time out. Er wartet auf Port 22.
Beim zweiten Versuch jedoch kommt folgende Ausgabe und alles ist wie gewollt:
debug3: fd 5 is not O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug3: send_rexec_state: entering fd = 8 config len 694
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from MEI.NE.EIGENE.IP port 51338
debug1: Client protocol version 2.0; client software version PuTTY_Release_0.62
debug1: no match: PuTTY_Release_0.62
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-3ubuntu1
debug2: fd 3 setting O_NONBLOCK
debug2: Network child is on pid 27396
debug3: preauth child monitor started
debug3: privsep user:group 115:65534 [preauth]
debug1: permanently_set_uid: 115/65534 [preauth]
debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth]
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se [preauth]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se [preauth]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
debug2: kex_parse_kexinit: none,zlib@openssh.com [preauth]
debug2: kex_parse_kexinit: none,zlib@openssh.com [preauth]
debug2: kex_parse_kexinit: [preauth]
debug2: kex_parse_kexinit: [preauth]
debug2: kex_parse_kexinit: first_kex_follows 0 [preauth]
debug2: kex_parse_kexinit: reserved 0 [preauth]
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,rsa2048-sha256,rsa1024-sha1 [preauth]
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss [preauth]
debug2: kex_parse_kexinit: aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 [preauth]
debug2: kex_parse_kexinit: aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 [preauth]
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5 [preauth]
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5 [preauth]
debug2: kex_parse_kexinit: none,zlib [preauth]
debug2: kex_parse_kexinit: none,zlib [preauth]
debug2: kex_parse_kexinit: [preauth]
debug2: kex_parse_kexinit: [preauth]
debug2: kex_parse_kexinit: first_kex_follows 0 [preauth]
debug2: kex_parse_kexinit: reserved 0 [preauth]
debug2: mac_setup: found hmac-sha1 [preauth]
debug1: kex: client->server aes256-ctr hmac-sha1 none [preauth]
debug2: mac_setup: found hmac-sha1 [preauth]
debug1: kex: server->client aes256-ctr hmac-sha1 none [preauth]
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received [preauth]
debug3: mm_request_send entering: type 0 [preauth]
debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI [preauth]
debug3: mm_request_receive_expect entering: type 1 [preauth]
debug3: mm_request_receive entering [preauth]
debug3: mm_request_receive entering
debug3: monitor_read: checking request 0
debug3: mm_answer_moduli: got parameters: 1024 4096 8192
debug3: mm_request_send entering: type 1
debug2: monitor_read: 0 used once, disabling now
debug3: mm_choose_dh: remaining 0 [preauth]
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth]
debug2: dh_gen_key: priv key bits set: 264/512 [preauth]
debug2: bits set: 2135/4096 [preauth]
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth]
debug2: bits set: 2096/4096 [preauth]
debug3: mm_key_sign entering [preauth]
debug3: mm_request_send entering: type 5 [preauth]
debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth]
debug3: mm_request_receive_expect entering: type 6 [preauth]
debug3: mm_request_receive entering [preauth]
debug3: mm_request_receive entering
debug3: monitor_read: checking request 5
debug3: mm_answer_sign
debug3: mm_answer_sign: signature 0x7f986f2d7cd0(271)
debug3: mm_request_send entering: type 6
debug2: monitor_read: 5 used once, disabling now
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth]
debug2: kex_derive_keys [preauth]
debug2: set_newkeys: mode 1 [preauth]
debug2: cipher_init: set keylen (16 -> 32) [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug2: set_newkeys: mode 0 [preauth]
debug2: cipher_init: set keylen (16 -> 32) [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: KEX done [preauth]
Sieht doch so aus, als würde der sshd garnichts empfangen, oder sehe ich das falsch?
Gruß
der Eintrag ist schon vorhanden. Was ich nun getestet habe ist der Start im debug modus.
Das bringt mir folgende Ausgabe:
debug2: load_server_config: filename /etc/ssh/sshd_config
debug2: load_server_config: done config len = 694
debug2: parse_server_config: config /etc/ssh/sshd_config len 694
debug3: /etc/ssh/sshd_config:5 setting Port 22
debug3: /etc/ssh/sshd_config:9 setting Protocol 2
debug3: /etc/ssh/sshd_config:11 setting HostKey /etc/ssh/ssh_host_rsa_key
debug3: /etc/ssh/sshd_config:12 setting HostKey /etc/ssh/ssh_host_dsa_key
debug3: /etc/ssh/sshd_config:13 setting HostKey /etc/ssh/ssh_host_ecdsa_key
debug3: /etc/ssh/sshd_config:15 setting UsePrivilegeSeparation yes
debug3: /etc/ssh/sshd_config:18 setting KeyRegenerationInterval 3600
debug3: /etc/ssh/sshd_config:19 setting ServerKeyBits 768
debug3: /etc/ssh/sshd_config:22 setting SyslogFacility AUTH
debug3: /etc/ssh/sshd_config:23 setting LogLevel INFO
debug3: /etc/ssh/sshd_config:26 setting LoginGraceTime 120
debug3: /etc/ssh/sshd_config:27 setting PermitRootLogin yes
debug3: /etc/ssh/sshd_config:28 setting StrictModes yes
debug3: /etc/ssh/sshd_config:30 setting RSAAuthentication yes
debug3: /etc/ssh/sshd_config:31 setting PubkeyAuthentication yes
debug3: /etc/ssh/sshd_config:35 setting IgnoreRhosts yes
debug3: /etc/ssh/sshd_config:37 setting RhostsRSAAuthentication no
debug3: /etc/ssh/sshd_config:39 setting HostbasedAuthentication no
debug3: /etc/ssh/sshd_config:44 setting PermitEmptyPasswords no
debug3: /etc/ssh/sshd_config:48 setting ChallengeResponseAuthentication no
debug3: /etc/ssh/sshd_config:63 setting X11Forwarding yes
debug3: /etc/ssh/sshd_config:64 setting X11DisplayOffset 10
debug3: /etc/ssh/sshd_config:65 setting PrintMotd no
debug3: /etc/ssh/sshd_config:66 setting PrintLastLog yes
debug3: /etc/ssh/sshd_config:67 setting TCPKeepAlive yes
debug3: /etc/ssh/sshd_config:74 setting AcceptEnv LANG LC_*
debug3: /etc/ssh/sshd_config:76 setting Subsystem sftp /usr/lib/openssh/sftp-server
debug3: /etc/ssh/sshd_config:87 setting UsePAM yes
debug3: /etc/ssh/sshd_config:90 setting UseDNS no
debug1: sshd version OpenSSH_6.0p1 Debian-3ubuntu1
debug3: Incorrect RSA1 identifier
debug1: read PEM private key done: type RSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.RSA-2048
debug1: Checking blacklist file /etc/ssh/blacklist.RSA-2048
debug1: private host key: type 1 RSA
debug3: Incorrect RSA1 identifier
debug1: read PEM private key done: type DSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.DSA-1024
debug1: Checking blacklist file /etc/ssh/blacklist.DSA-1024
debug1: private host key: #1 type 2 DSA
debug3: Incorrect RSA1 identifier
debug1: read PEM private key done: type ECDSA
debug1: Checking blacklist file /usr/share/ssh/blacklist.ECDSA-256
debug1: Checking blacklist file /etc/ssh/blacklist.ECDSA-256
debug1: private host key: #2 type 3 ECDSA
debug1: rexec_argv='/usr/sbin/sshd'
debug1: rexec_argv[1]='-ddd'
debug3: oom_adjust_setup
Set /proc/self/oom_score_adj from 0 to -1000
debug2: fd 3 setting O_NONBLOCK
debug1: Bind to port 22 on 0.0.0.0.
Server listening on 0.0.0.0 port 22.
debug2: fd 4 setting O_NONBLOCK
debug3: sock_set_v6only: set socket 4 IPV6_V6ONLY
debug1: Bind to port 22 on ::.
Server listening on :: port 22.
Beim ersten Verbindungsversuch mittels putty kommt hier keinerlei weitere Ausgabe. Auch nicht nach dem time out. Er wartet auf Port 22.
Beim zweiten Versuch jedoch kommt folgende Ausgabe und alles ist wie gewollt:
debug3: fd 5 is not O_NONBLOCK
debug1: Server will not fork when running in debugging mode.
debug3: send_rexec_state: entering fd = 8 config len 694
debug3: ssh_msg_send: type 0
debug3: send_rexec_state: done
debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8
debug1: inetd sockets after dupping: 3, 3
Connection from MEI.NE.EIGENE.IP port 51338
debug1: Client protocol version 2.0; client software version PuTTY_Release_0.62
debug1: no match: PuTTY_Release_0.62
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.0p1 Debian-3ubuntu1
debug2: fd 3 setting O_NONBLOCK
debug2: Network child is on pid 27396
debug3: preauth child monitor started
debug3: privsep user:group 115:65534 [preauth]
debug1: permanently_set_uid: 115/65534 [preauth]
debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
debug1: SSH2_MSG_KEXINIT sent [preauth]
debug1: SSH2_MSG_KEXINIT received [preauth]
debug2: kex_parse_kexinit: ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth]
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256 [preauth]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se [preauth]
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysator.liu.se [preauth]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64@openssh.com,hmac-sha2-256,hmac-sha2-256-96,hmac-sha2-512,hmac-sha2-512-96,hmac-ripemd160,hmac-ripemd160@openssh.com,hmac-sha1-96,hmac-md5-96 [preauth]
debug2: kex_parse_kexinit: none,zlib@openssh.com [preauth]
debug2: kex_parse_kexinit: none,zlib@openssh.com [preauth]
debug2: kex_parse_kexinit: [preauth]
debug2: kex_parse_kexinit: [preauth]
debug2: kex_parse_kexinit: first_kex_follows 0 [preauth]
debug2: kex_parse_kexinit: reserved 0 [preauth]
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1,rsa2048-sha256,rsa1024-sha1 [preauth]
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss [preauth]
debug2: kex_parse_kexinit: aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 [preauth]
debug2: kex_parse_kexinit: aes256-ctr,aes256-cbc,rijndael-cbc@lysator.liu.se,aes192-ctr,aes192-cbc,aes128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,arcfour128 [preauth]
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5 [preauth]
debug2: kex_parse_kexinit: hmac-sha1,hmac-sha1-96,hmac-md5 [preauth]
debug2: kex_parse_kexinit: none,zlib [preauth]
debug2: kex_parse_kexinit: none,zlib [preauth]
debug2: kex_parse_kexinit: [preauth]
debug2: kex_parse_kexinit: [preauth]
debug2: kex_parse_kexinit: first_kex_follows 0 [preauth]
debug2: kex_parse_kexinit: reserved 0 [preauth]
debug2: mac_setup: found hmac-sha1 [preauth]
debug1: kex: client->server aes256-ctr hmac-sha1 none [preauth]
debug2: mac_setup: found hmac-sha1 [preauth]
debug1: kex: server->client aes256-ctr hmac-sha1 none [preauth]
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received [preauth]
debug3: mm_request_send entering: type 0 [preauth]
debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI [preauth]
debug3: mm_request_receive_expect entering: type 1 [preauth]
debug3: mm_request_receive entering [preauth]
debug3: mm_request_receive entering
debug3: monitor_read: checking request 0
debug3: mm_answer_moduli: got parameters: 1024 4096 8192
debug3: mm_request_send entering: type 1
debug2: monitor_read: 0 used once, disabling now
debug3: mm_choose_dh: remaining 0 [preauth]
debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth]
debug2: dh_gen_key: priv key bits set: 264/512 [preauth]
debug2: bits set: 2135/4096 [preauth]
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth]
debug2: bits set: 2096/4096 [preauth]
debug3: mm_key_sign entering [preauth]
debug3: mm_request_send entering: type 5 [preauth]
debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth]
debug3: mm_request_receive_expect entering: type 6 [preauth]
debug3: mm_request_receive entering [preauth]
debug3: mm_request_receive entering
debug3: monitor_read: checking request 5
debug3: mm_answer_sign
debug3: mm_answer_sign: signature 0x7f986f2d7cd0(271)
debug3: mm_request_send entering: type 6
debug2: monitor_read: 5 used once, disabling now
debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth]
debug2: kex_derive_keys [preauth]
debug2: set_newkeys: mode 1 [preauth]
debug2: cipher_init: set keylen (16 -> 32) [preauth]
debug1: SSH2_MSG_NEWKEYS sent [preauth]
debug1: expecting SSH2_MSG_NEWKEYS [preauth]
debug2: set_newkeys: mode 0 [preauth]
debug2: cipher_init: set keylen (16 -> 32) [preauth]
debug1: SSH2_MSG_NEWKEYS received [preauth]
debug1: KEX done [preauth]
Sieht doch so aus, als würde der sshd garnichts empfangen, oder sehe ich das falsch?
Gruß
Hallo,
läuft denn der sshd überhaupt wenn Du zum ersten mal versuchst, Dich zu verbinden? Kannst Du mal auf dem Server ausführen? und vielleicht mal mit nmap checken, ob Port 22 offen istwobei xxx.xxx.xxx.xxx natürlich die IP-Adresse des Servers ist.
Markus
läuft denn der sshd überhaupt wenn Du zum ersten mal versuchst, Dich zu verbinden? Kannst Du mal auf dem Server
ps -e | grep sshdnmap -p 22 xxx.xxx.xxx.xxxMarkus
Hallo Markus,
ja, der sshd läuft derzeit sogar mit 4 offenen sessions. Das zeigt "ps.." auch an. In einer dieser führe ich gerade eben diese Kommandos aus (ps -e... und nmap ..)
ps -e | grep sshd
24300 ? 00:00:00 sshd
24598 ? 00:00:00 sshd
25047 ? 00:00:00 sshd
25176 ? 00:00:00 sshd
Starting Nmap 6.00 ( http://nmap.org ) at 2013-02-27 17:27 CET
Nmap scan report for XXX.XXX.XX.XXX
Host is up (0.000031s latency).
PORT STATE SERVICE
22/tcp closed ssh
Nmap done: 1 IP address (1 host up) scanned in 0.05 seconds
trotzdem habe ich wieder das timeout Verhalten, wenn ich eine weitere Putty Verbindung öffnen will
ja, der sshd läuft derzeit sogar mit 4 offenen sessions. Das zeigt "ps.." auch an. In einer dieser führe ich gerade eben diese Kommandos aus (ps -e... und nmap ..)
ps -e | grep sshd
24300 ? 00:00:00 sshd
24598 ? 00:00:00 sshd
25047 ? 00:00:00 sshd
25176 ? 00:00:00 sshd
Starting Nmap 6.00 ( http://nmap.org ) at 2013-02-27 17:27 CET
Nmap scan report for XXX.XXX.XX.XXX
Host is up (0.000031s latency).
PORT STATE SERVICE
22/tcp closed ssh
Nmap done: 1 IP address (1 host up) scanned in 0.05 seconds
trotzdem habe ich wieder das timeout Verhalten, wenn ich eine weitere Putty Verbindung öffnen will
22/tcp closed ssh
der port ist nicht offen. das ist das Problem. prüfe die Konfiguration von ssh auf dem Server.Markus
Hallo,
eventuell auf beiden Maschinen IPv6 vorhanden aber nicht funktionierend bzw. Zielport 22 für IPv6 gedroppt??
Teste mal mit Putty unter "Connection" auf IPv4 eingestellt.
Gruß
Andi
eventuell auf beiden Maschinen IPv6 vorhanden aber nicht funktionierend bzw. Zielport 22 für IPv6 gedroppt??
Teste mal mit Putty unter "Connection" auf IPv4 eingestellt.
Gruß
Andi
Meine Idee, weshalb ich nach der Ausgabe von nmap gefragt habe, war dass ich aus den Logs den Eindruck hatte, dass der sshd erst gestartet wird wenn die erste Anfrage kommt. Wenn er läuft ist wahrscheinlich auch Port 22 offen und deshalb klappt es im zweiten Anlauf.
Dazu müsste man aber mehr über die Konfiguration wissen, insbesondere "wer" denn nun tatsächlich auf dem NIC lauscht (sshd oder xinetd) usw.
Ob IPv6 da eventuell mit reinspielt kann ich nicht beurteilen.
Markus
Dazu müsste man aber mehr über die Konfiguration wissen, insbesondere "wer" denn nun tatsächlich auf dem NIC lauscht (sshd oder xinetd) usw.
Ob IPv6 da eventuell mit reinspielt kann ich nicht beurteilen.
Markus
Guten Morgen,
es ist also wirklich so. Wenn ich per remote desktop auf dem server in einer konsole die offenen ports mit nmap ansehe, ist port 22 nicht dabei. Nach dem ersten Fehlversuch einer putty Verbindung taucht port 22 dann auf.
Wenn ich aber nun die SSH session wieder schließe und einige Minuten warte, so zeigt ein nmap auf dem server immernoch den geöffneten port 22. Eine putty-Anmeldung geht aber wieder erst beim zweiten Versuch.
Christian
es ist also wirklich so. Wenn ich per remote desktop auf dem server in einer konsole die offenen ports mit nmap ansehe, ist port 22 nicht dabei. Nach dem ersten Fehlversuch einer putty Verbindung taucht port 22 dann auf.
Wenn ich aber nun die SSH session wieder schließe und einige Minuten warte, so zeigt ein nmap auf dem server immernoch den geöffneten port 22. Eine putty-Anmeldung geht aber wieder erst beim zweiten Versuch.
Christian
