wrote in message
news:1138087134.734312.128670@o13g2000cwo.googlegr oups.com...
> In above versions of openSSH -
> StrictHostKeyChecking parameter in ssh client config does not work
> properly.
>
> when trying a new server public host key while connecting using client,
> client simply exits with following exception "Someone could be
> eavesdropping on you right now (man-in-the-middle attack)!"

May I suggest reading the manual page for ssh_config? This is normally set
to "ask" by default, which will prompt the user for permission to add the
new key to the list of hostkeys, or skip the command if being run from a
script.

> As per the standards, in the above scenario. For the default value of
> this parameter (ASK) client should prompt user for confirming that
> server has changed its public key. should not exit ?
>
> Is it a bug in openSSH ? if it is anyone know which version is it fixed.

I don't think it's an OpenSSH bug: check your personal $HOME/.ssh/config and
your system's ssh_config file, wherever that happens to be.

gnitin21@gmail.com writes:

> Is it a bug in openSSH ? if it is anyone know which version is it
> fixed.

3.4p1 is quite old and has a lot of bugs I suspect, some of them major
security variety, I know.

--
Todd H.
http://www.toddh.net/

gnitin21@gmail.com wrote:
> In above versions of openSSH -
> StrictHostKeyChecking parameter in ssh client config does not work
> properly.

> when trying a new server public host key while connecting using client,

A new *key* or a new *server*?

> client simply exits with following exception "Someone could be
> eavesdropping on you right now (man-in-the-middle attack)!"

> As per the standards, in the above scenario. For the default value of
> this parameter (ASK) client should prompt user for confirming that
> server has changed its public key. should not exit ?

"changed its public key", so it's not a new server.

When the documentation refers to "new host key", it could say something
like "new server key entry" instead. It only handles when a key for a
new server arrives, not when a key for an existing entry changes.

"new host" key, not new "host key".

Note the "refuse to connect" part in the docs.

If this flag is set to ``ask'', new host keys
will be added to the user known host files only after the user
has confirmed that is what they really want to do, and ssh will
refuse to connect to hosts whose host key has changed.

I guess even a changed key really is a "new host key", but that's not
what's meant here. I can't think of a better way to phrase it though.
My attempts to make it less ambiguous sound very forced....

--
Darren Dunham ddunham@taos.com
Senior Technical Consultant TAOS http://www.taos.com/
Got some Dr Pepper? San Francisco, CA bay area
< This line left intentionally blank to confuse you. >

That make sense. Thanks for clarification.

Are the ssh config file formats are standardized ? i mean what
parameter and their values !
is it left to the implementators to include what is needed an what
notation !!
i checked this site "www.ietf.org/html.charters/secsh-charter.html "
but could not see any reference for ssh configuration.

On 2006-01-31, gnitin21@gmail.com wrote:
> That make sense. Thanks for clarification.
>
> Are the ssh config file formats are standardized ? i mean what
> parameter and their values ! [later ref
[...]
> i checked this site "www.ietf.org/html.charters/secsh-charter.html "
> but could not see any reference for ssh configuration.

No, the only file format (that I know of) that is part of the standard is
the public key file format, and that was relatively late in the process.

For OpenSSH, the config file format is documented in the ssh_config(5)
man page (and sshd_config(5) for the corresponding server config file).

> is it left to the implementators to include what is needed an what
> notation !!

Yes.

--
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69
Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.