Bug 737295 - ssh-to-rawhide hangs (uninterruptible) for 2 minutes, then fails
ssh-to-rawhide hangs (uninterruptible) for 2 minutes, then fails
Status: CLOSED DUPLICATE of bug 735970
Product: Fedora
Classification: Fedora
Component: openssh (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jan F. Chadima
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2011-09-10 15:25 EDT by Jim Meyering
Modified: 2013-03-13 16:41 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2011-09-10 16:00:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jim Meyering 2011-09-10 15:25:33 EDT
Description of problem:

Version-Release number of selected component (if applicable):

How reproducible: every time

Steps to Reproduce:
1. attempt to ssh to an up-to-date rawhide-based vm
2. ssh hangs (uninterruptible) for 2 minutes, then fails
Actual results:

    $ date; ssh r; date                                     
    Sat 2011-09-10 19:55:35 +0200
    Write failed: Broken pipe
    Sat 2011-09-10 19:57:35 +0200

Expected results:

    ssh succeeds

Additional info:
Note the two-minute delay.
I was unable to interrupt it, nor suspend.  Very annoying.

Using the console, I see nothing in /var/log/messages
or /var/log/audit/*.

The above was using an agent.
The same thing happens without, but only after authentication.

If I repeat the above with -v, it always hangs right after
"Entering interactive session.":

    debug3: sign_and_send_pubkey: ---
    debug1: Enabling compression at level 6.
    debug1: Authentication succeeded (publickey).
    Authenticated to r ([]:22).
    debug1: setting up multiplex master socket
    debug2: fd 4 setting O_NONBLOCK
    debug3: fd 4 is O_NONBLOCK
    debug3: fd 4 is O_NONBLOCK
    debug1: channel 0: new [/h/j/.ssh/sockets/22-r]
    debug3: muxserver_listen: mux listener channel 0 fd 4
    debug1: channel 1: new [client-session]
    debug3: ssh_session2_open: channel_new: 1
    debug2: channel 1: send open
    debug1: Entering interactive session.

Next step was to turn off enforcing.
That didn't make a difference.

Then I turned on debugging with LogLevel DEBUG3, restarted sshd and
repeated the experiment.  Nothing obviously suspicious there, at least
not to my untrained eye.

This is with openssh-5.9p1-2.fc17.x86_64 (same for -server).
Comment 1 Jim Meyering 2011-09-10 16:00:28 EDT
This is a duplicate of bug #735970

*** This bug has been marked as a duplicate of bug 735970 ***

Note You need to log in before you can comment on or make changes to this bug.