Re: SSH connection hang after upgrade - openssh

This is a discussion on Re: SSH connection hang after upgrade - openssh ; Peter Stuge wrote: > On Fri, Jun 20, 2008 at 04:00:16PM -0400, John DeStefano wrote: > > OK; thanks ... but if 'Protocol 2' is specified in sshd_config, > > should sshd be looking for an 'RSA1 key'? > > ...

+ Reply to Thread
Results 1 to 4 of 4

Thread: Re: SSH connection hang after upgrade

  1. Re: SSH connection hang after upgrade

    Peter Stuge wrote:
    > On Fri, Jun 20, 2008 at 04:00:16PM -0400, John DeStefano wrote:
    > > OK; thanks ... but if 'Protocol 2' is specified in sshd_config,
    > > should sshd be looking for an 'RSA1 key'?

    >
    > Protocol is about what sshd speaks on the network.
    >
    > But granted - there is no point in dealing with SSH v1 keys when
    > using protocol version v2. Please send patches.
    >
    > > And why would it look at .ssh/id_rsa instead of looking for
    > > .ssh/identity,

    >
    > Because .ssh/id_rsa is the default SSH v2 RSA key filename.


    Yes, but this seems to conflict with the 'RSA1' message I'm getting:
    if the daemon is truly looking for a protocol v1 key, why would it
    bother moving past the absence of an 'identity' key file and on to
    other files (of newer protocols)?

    > > which doesn't exist on my system but I believe is the file used for
    > > SSH v1 RSA? Is there a way to prevent it from doing so?

    >
    > .ssh/identity is the default SSH v1 key filename.


    Right; this much I know.

    > The key thing is not a problem - that's just how sshd looks for keys.


    I understand what you're saying, but it seems like the key thing _is_
    keeping the daemon from functioning properly in my case. Something is
    telling it to look for a protocol v1 key, and for nothing else, and I
    can't figure out what it is.

    > I'm afraid I can't provide any good suggestions about the real
    > problem. :\


    Me either; this is really baffling me: I can use the very same key
    (and other keys I've tested) with the 'ssh' client to connect
    remotely, and successfully, to other hosts. I just can't connect to
    my own 'sshd' service.

    Thanks,
    ~John
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  2. Re: SSH connection hang after upgrade


    My first recommentation is to run a sshd 5.0 client on a higher port with
    -ddd and see what is causing it to hang on the server side.

    This will give you more useful information as to what is hanging.

    - Ben

    On Mon, 23 Jun 2008, John DeStefano wrote:

    > Peter Stuge wrote:
    >> On Fri, Jun 20, 2008 at 04:00:16PM -0400, John DeStefano wrote:
    >>> OK; thanks ... but if 'Protocol 2' is specified in sshd_config,
    >>> should sshd be looking for an 'RSA1 key'?

    >>
    >> Protocol is about what sshd speaks on the network.
    >>
    >> But granted - there is no point in dealing with SSH v1 keys when
    >> using protocol version v2. Please send patches.
    >>
    >>> And why would it look at .ssh/id_rsa instead of looking for
    >>> .ssh/identity,

    >>
    >> Because .ssh/id_rsa is the default SSH v2 RSA key filename.

    >
    > Yes, but this seems to conflict with the 'RSA1' message I'm getting:
    > if the daemon is truly looking for a protocol v1 key, why would it
    > bother moving past the absence of an 'identity' key file and on to
    > other files (of newer protocols)?
    >
    >>> which doesn't exist on my system but I believe is the file used for
    >>> SSH v1 RSA? Is there a way to prevent it from doing so?

    >>
    >> .ssh/identity is the default SSH v1 key filename.

    >
    > Right; this much I know.
    >
    >> The key thing is not a problem - that's just how sshd looks for keys.

    >
    > I understand what you're saying, but it seems like the key thing _is_
    > keeping the daemon from functioning properly in my case. Something is
    > telling it to look for a protocol v1 key, and for nothing else, and I
    > can't figure out what it is.
    >
    >> I'm afraid I can't provide any good suggestions about the real
    >> problem. :\

    >
    > Me either; this is really baffling me: I can use the very same key
    > (and other keys I've tested) with the 'ssh' client to connect
    > remotely, and successfully, to other hosts. I just can't connect to
    > my own 'sshd' service.
    >
    > Thanks,
    > ~John
    > _______________________________________________
    > openssh-unix-dev mailing list
    > openssh-unix-dev@mindrot.org
    > https://lists.mindrot.org/mailman/li...enssh-unix-dev
    >

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  3. Re: SSH connection hang after upgrade

    On Jun 23, 2008, at 3:07 PM, Ben Lindstrom wrote:
    > My first recommentation is to run a sshd 5.0 client on a higher port
    > with -ddd and see what is causing it to hang on the server side.
    >
    > This will give you more useful information as to what is hanging.
    >
    > - Ben


    Thanks. Let me know what you make of this:
    http://deesto.pastebin.com/f3bff0cc8

    I was able to restore the 'original' version via installation disc,
    and the same problem persists. I don't know for sure, but it seems as
    if there may be an Apple-specific "hidden" configuration file
    somewhere, related to OpenSSH but not apparent in base config files.
    Perhaps this needs to change as well with version changes or becomes
    corrupt. I am grasping at straws, but nothing else makes sense.

    ~John


    > On Mon, 23 Jun 2008, John DeStefano wrote:
    >
    >> Peter Stuge wrote:
    >>> On Fri, Jun 20, 2008 at 04:00:16PM -0400, John DeStefano wrote:
    >>>> OK; thanks ... but if 'Protocol 2' is specified in sshd_config,
    >>>> should sshd be looking for an 'RSA1 key'?
    >>>
    >>> Protocol is about what sshd speaks on the network.
    >>>
    >>> But granted - there is no point in dealing with SSH v1 keys when
    >>> using protocol version v2. Please send patches.
    >>>
    >>>> And why would it look at .ssh/id_rsa instead of looking for
    >>>> .ssh/identity,
    >>>
    >>> Because .ssh/id_rsa is the default SSH v2 RSA key filename.

    >>
    >> Yes, but this seems to conflict with the 'RSA1' message I'm getting:
    >> if the daemon is truly looking for a protocol v1 key, why would it
    >> bother moving past the absence of an 'identity' key file and on to
    >> other files (of newer protocols)?
    >>
    >>>> which doesn't exist on my system but I believe is the file used for
    >>>> SSH v1 RSA? Is there a way to prevent it from doing so?
    >>>
    >>> .ssh/identity is the default SSH v1 key filename.

    >>
    >> Right; this much I know.
    >>
    >>> The key thing is not a problem - that's just how sshd looks for
    >>> keys.

    >>
    >> I understand what you're saying, but it seems like the key thing _is_
    >> keeping the daemon from functioning properly in my case. Something
    >> is
    >> telling it to look for a protocol v1 key, and for nothing else, and I
    >> can't figure out what it is.
    >>
    >>> I'm afraid I can't provide any good suggestions about the real
    >>> problem. :\

    >>
    >> Me either; this is really baffling me: I can use the very same key
    >> (and other keys I've tested) with the 'ssh' client to connect
    >> remotely, and successfully, to other hosts. I just can't connect to
    >> my own 'sshd' service.
    >>
    >> Thanks,
    >> ~John
    >>

    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


  4. Re: SSH connection hang after upgrade



    On Mon, 23 Jun 2008, John DeStefano wrote:

    > On Jun 23, 2008, at 3:07 PM, Ben Lindstrom wrote:
    >> My first recommentation is to run a sshd 5.0 client on a higher port with
    >> -ddd and see what is causing it to hang on the server side.
    >>
    >> This will give you more useful information as to what is hanging.
    >>
    >> - Ben

    >
    > Thanks. Let me know what you make of this:
    > http://deesto.pastebin.com/f3bff0cc8
    >
    > I was able to restore the 'original' version via installation disc, and the
    > same problem persists. I don't know for sure, but it seems as if there may
    > be an Apple-specific "hidden" configuration file somewhere, related to
    > OpenSSH but not apparent in base config files. Perhaps this needs to change
    > as well with version changes or becomes corrupt. I am grasping at straws,
    > but nothing else makes sense.
    >


    Things like this bother me..

    Client side:

    Last login: Mon Jun 23 15:13:43 2008
    debug3: PAM session not opened, exiting
    debug3: channel 0: will not send data after close
    debug2: channel 0: obuf empty
    debug2: channel 0: close_write

    Server Side:
    debug3: mm_request_receive entering
    debug3: PAM: opening session
    PAM: pam_open_session(): Cannot make/remove an entry for the specified
    session
    debug1: PAM: reinitializing credentials
    debug1: permanently_set_uid: 501/501


    What is odd is after that Server Side commentary it continues to blast
    through the code as if nothing was wrong. Either PAM did reinitialize
    right or the error is being ignored.

    But what seems to be terminating the sesson seems to be the sshd's child
    (the shell I assume) is dying off sending the parent a SIGCHLD. Which is
    then closing down everything.

    That is all I can devine from this. It has been too long since I've
    looked at the PAM code to know if I'm barking up the wrong tree or not.

    - Ben
    _______________________________________________
    openssh-unix-dev mailing list
    openssh-unix-dev@mindrot.org
    https://lists.mindrot.org/mailman/li...enssh-unix-dev


+ Reply to Thread