ssh2

[roland]

On Sat, 20 Sep 2008 20:48:47 +0200, Bill Davidsen <davidsen at tmr.com> wrote:

> roland wrote:
>> On Sat, 20 Sep 2008 01:06:10 +0200, Bill Davidsen <davidsen at tmr.com>  
>> wrote:
>>
>>> roland wrote:
>>>
>>>> Waw, this is a very exhaustive answer, and I thank you very much for  
>>>> this.
>>>>  How will have to do some reading.
>>>> One thing is for sure, I find the known-hosts in de userdir on  
>>>> windows but there are no entries added and I do not find anywhere the  
>>>> dsa or rsa or whatever keys.
>>>>  I removed all the keys in /etc/ssh/ and
>>>> indeed the keys were recreated.
>>>>
>>> Yes, that is the original problem, the host keys changed.
>>>
>>>> But Anita continues this difficulty and Putty never did.
>>>
>>> Anita has no "problem," it is warning you that the host has changed.  
>>> Trying to stop the warning instead of fixing the problem is like  
>>> taking the battery out of the smoke alarm instead of finding the fire!
>>>
>>>> Must have to do something with this 3DES.
>>>>
>>> It has to do with the system being hacked.
>>>
>>>> I don't understand how Putty can login because there aren't any  
>>>> entries in known_hosts under windows which are referring to the hosts  
>>>> I'm logging into. ???
>>>>
>>> That's why putty can't detect that there's a problem, because it  
>>> doesn't have the *correct* values, and so doesn't know that there is  
>>> now an incorrect host key machine at the end of the socket.
>>  Putty is using ssh2. So if the key of the remote host is not found in  
>> known_hosts on the mswindow station, why does nobody complaints? When  
>> will the key of the remote host be added in this file known_hosts?
>>
> Putty uses the ssh2 protocol, but probably not the code (haven't  
> looked). In any case, the key is added in the Fedora ssh program after  
> asking if you trust the connection (and verify the fingerprint). Without  
> going back and checking to see how putty does this (haven't use putty in  
> several years) I can't say how it works. I think I recall doing a manual  
> step to save the key, but I haven't needed putty since 25 months now.
>
> The use of known_hosts is done by the client, the protocol allows  
> checking.
>
>> following this doc here after your assumption is not correct, or do I  
>> understand something wrong?
>>
> What you describe below is the behavior of ssh as provided by Fedora,  
> and that's based on OpenSSH from the OpenBSD project. This is their  
> client's warning.
>
>> If you reinstall, the reinstalled system creates a new set of  
>> identification keys. Any clients who had connected to the system with  
>> any of the OpenSSH tools before the reinstall will see the following  
>> message:
>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>> @    WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED!     @
>> @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
>> IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY!
>> Someone could be eavesdropping on you right now (man-in-the-middle  
>> attack)!
>> It is also possible that the RSA host key has just been changed.
>
> The worrying thing is that since the sshd now asks for ssh2 protocol  
> only, there is a new sshd operating, one you didn't install, and one  
> which may be copying keystroke data (login names and passwords) to some  
> unauthorized other site. I can't say that's happening, but this has all  
> of the characteristics of that. It could also be caused by an upgrade of  
> sshd, although I read your posts to say that only you could do that.
>
> It would be useful to use 'ps' to see which sshd is running, and to do  
> an 'ls -l' and md5sum on the executable and post the values here. Also a  
> telnet to the ssh port usually gives the protocol and sshd version,  
> although that can be faked. Post that if you wish

You will find it in  annex

Thanks again for your time

Roland
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: itact.txt
URL: <http://listman.redhat.com/archives/fedora-list/attachments/20080921/ecc3942b/attachment-0001.txt>