I did some network sniffing today... I have a comparison of a
sucessfull attempt to connect to the server via ssh invoked by myself
from within the shell and a failed attempt to connect to the server
via ssh invoked by ldm itself.
Here the succesfull one:
39 7.461023 serverip clientip SSHv2 Server: Key
Exchange Init
40 7.461223 clientip serverip SSHv2 Client:
Diffie-Hellman GEX Request
41 7.463619 serverip clientip SSHv2 Server:
Diffie-Hellman Key Exchange Reply
42 7.467867 clientip serverip SSHv2 Client:
Diffie-Hellman GEX Init
43 7.475203 serverip clientip SSHv2 Server:
Diffie-Hellman GEX Reply
44 7.480605 clientip serverip SSHv2 Client: New Keys
45 7.517351 serverip clientip TCP ssh >
57252 [ACK] Seq=1696 Ack=1016 Win=8960 Len=0 TSV=8085799 TSER=105545
46 7.517422 clientip serverip SSHv2
Encrypted request packet len=48
47 7.517575 serverip clientip TCP ssh >
57252 [ACK] Seq=1696 Ack=1064 Win=8960 Len=0 TSV=8085799 TSER=105555
48 7.517610 serverip clientip SSHv2
Encrypted response packet len=48
49 7.517750 clientip serverip SSHv2
Encrypted request packet len=64
50 7.521916 serverip clientip SSHv2
Encrypted response packet len=64
51 7.525142 clientip serverip SSH
Encrypted response packet len=64
And the failed one:
128 24.414175 serverip clientip SSHv2 Server:
Key Exchange Init
129 24.414370 clientip serverip SSHv2 Client:
Diffie-Hellman GEX Request
130 24.416594 serverip clientip SSHv2 Server:
Diffie-Hellman Key Exchange Reply
131 24.420876 clientip serverip SSHv2 Client:
Diffie-Hellman GEX Init
132 24.428224 serverip clientip SSHv2 Server:
Diffie-Hellman GEX Reply
133 24.466471 clientip serverip TCP 57253 >
ssh [ACK] Seq=1000 Ack=1696 Win=10560 Len=0 TSV=109289 TSER=8087288
157 60.469301 clientip serverip TCP 57253 >
ssh [FIN, ACK] Seq=1000 Ack=1696 Win=10560 Len=0 TSV=118289 TSER=8087288
What I can see is, that in the case of the failed login attempt
(through ldm), after the encryption algorithm has been negotiated
(Diffie-Hellman) the client does not send its own key to the server.
So the message "no response from server" which ldm is displaying is
actually wrong. It is the client which does not continue to
communicate with server.
Am i right?
I have absolutely no clue what I could do about it to solve the problem.
Help... anybody?
Its Ubuntu 10.04
Best,
kris
Zitat von Krzysztof Paliga <[email protected]>:
> Hi,
>
> after ldm has started, the username and password has been typed in...
> all I get is "No server response"... I did put serverside the sshd
> daemon to DEBUG3 LogLevel... all I get is the following:
>
> Jul 7 13:02:07 <server> sshd[7130]: Connection from <clientip> port 45239
> Jul 7 13:02:07 <server> sshd[7130]: debug1: Client protocol version
> 2.0; client software version OpenSSH_5.3p1 Debian-3ubuntu4
> Jul 7 13:02:07 <server> sshd[7130]: debug1: match: OpenSSH_5.3p1
> Debian-3ubuntu4 pat OpenSSH*
> Jul 7 13:02:07 <server> sshd[7130]: debug1: Enabling compatibility
> mode for protocol 2.0
> Jul 7 13:02:07 <server> sshd[7130]: debug1: Local version string
> SSH-2.0-OpenSSH_5.3p1 Debian-3ubuntu4
> Jul 7 13:02:07 <server> sshd[7130]: debug2: fd 3 setting O_NONBLOCK
> Jul 7 13:02:07 <server> sshd[7130]: debug2: Network child is on pid 7131
> Jul 7 13:02:07 <server> sshd[7130]: debug3: preauth child monitor started
> Jul 7 13:02:07 <server> sshd[7130]: debug3: mm_request_receive entering
> Jul 7 13:02:07 <server> sshd[7130]: debug3: monitor_read: checking request 0
> Jul 7 13:02:07 <server> sshd[7130]: debug3: mm_answer_moduli: got
> parameters: 1024 1024 8192
> Jul 7 13:02:07 <server> sshd[7130]: debug3: mm_request_send entering: type 1
> Jul 7 13:02:07 <server> sshd[7130]: debug2: monitor_read: 0 used
> once, disabling now
> Jul 7 13:02:07 <server> sshd[7130]: debug3: mm_request_receive entering
> Jul 7 13:02:07 <server> sshd[7130]: debug3: monitor_read: checking request 5
> Jul 7 13:02:07 <server> sshd[7130]: debug3: mm_answer_sign
> Jul 7 13:02:07 <server> sshd[7130]: debug3: mm_answer_sign: signature
> 0x7fb4df52ac40(271)
> Jul 7 13:02:07 <server> sshd[7130]: debug3: mm_request_send entering: type 6
> Jul 7 13:02:07 <server> sshd[7130]: debug2: monitor_read: 5 used
> once, disabling now
> Jul 7 13:02:07 <server> sshd[7130]: debug3: mm_request_receive entering
> Jul 7 13:02:43 <server> sshd[7130]: debug1: do_cleanup
> Jul 7 13:02:43 <server> sshd[7130]: debug3: PAM:
> sshpam_thread_cleanup entering
>
> I have absolutely no clue...
>
> Thanks in advance for all kind of help...
>
> best,
> krzychu
>
> --
> ________________________________________
>
> Krzysztof Paliga
>
> Technische Universitaet Berlin
> tubIT - Server und Systeme
> Einsteinufer 17
> 10587 Berlin
>
> Tel : +49-30-314-21240
> Mail : [email protected]
> Web : http://www.tubit.tu-berlin.de
> ________________________________________
>
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _____________________________________________________________________
> Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
> https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
> For additional LTSP help, try #ltsp channel on irc.freenode.net
>
>
--
________________________________________
Krzysztof Paliga
Technische Universitaet Berlin
tubIT - Server und Systeme
Einsteinufer 17
10587 Berlin
Tel : +49-30-314-21240
Mail : [email protected]
Web : http://www.tubit.tu-berlin.de
________________________________________
------------------------------------------------------------------------------
This SF.net email is sponsored by Sprint
What will you do first with EVO, the first 4G phone?
Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
_____________________________________________________________________
Ltsp-discuss mailing list. To un-subscribe, or change prefs, goto:
https://lists.sourceforge.net/lists/listinfo/ltsp-discuss
For additional LTSP help, try #ltsp channel on irc.freenode.net
