This service will be undergoing maintenance at 03:30 UTC, 2016-05-27. It is expected to last about 2 hours

Bug 737295

Summary: ssh-to-rawhide hangs (uninterruptible) for 2 minutes, then fails
Product: [Fedora] Fedora Reporter: Jim Meyering <meyering>
Component: opensshAssignee: Jan F. Chadima <jchadima>
Status: CLOSED DUPLICATE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: rawhideCC: jchadima, mattias.ellert, mgrepl, tmraz
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-09-10 16:00:28 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:

Description Jim Meyering 2011-09-10 15:25:33 EDT
Description of problem:


Version-Release number of selected component (if applicable):
openssh-5.9p1-2.fc17.x86_64

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
3.
  
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 ([192.168.122.3]: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 ***