SSH-2.0-OpenSSH_3.4p1 and SSH-2.0-OpenSSH_3.7.1p2 : StrictHostKeyChecking - SSH

This is a discussion on SSH-2.0-OpenSSH_3.4p1 and SSH-2.0-OpenSSH_3.7.1p2 : StrictHostKeyChecking - SSH ; 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 ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: SSH-2.0-OpenSSH_3.4p1 and SSH-2.0-OpenSSH_3.7.1p2 : StrictHostKeyChecking

  1. SSH-2.0-OpenSSH_3.4p1 and SSH-2.0-OpenSSH_3.7.1p2 : StrictHostKeyChecking

    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)!"

    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.


  2. Re: SSH-2.0-OpenSSH_3.4p1 and SSH-2.0-OpenSSH_3.7.1p2 : StrictHostKeyChecking


    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.



  3. Re: SSH-2.0-OpenSSH_3.4p1 and SSH-2.0-OpenSSH_3.7.1p2 : StrictHostKeyChecking

    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/

  4. Re: SSH-2.0-OpenSSH_3.4p1 and SSH-2.0-OpenSSH_3.7.1p2 : StrictHostKeyChecking

    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. >

  5. Re: SSH-2.0-OpenSSH_3.4p1 and SSH-2.0-OpenSSH_3.7.1p2 : StrictHostKeyChecking

    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.


  6. Re: SSH-2.0-OpenSSH_3.4p1 and SSH-2.0-OpenSSH_3.7.1p2 : StrictHostKeyChecking

    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.

+ Reply to Thread