[Bug 1179344] [NEW] ssh doesn't get pty; says "inappropriate ioctl for device"

Mon May 13 02:22:30 UTC 2013

Public bug reported:

## Versions

    $ lsb_release -rd
    Description:    Ubuntu Saucy Salamander (development branch)
    Release:        13.10

    $ uname -a
    Linux emu 3.9.0-1-generic #5-Ubuntu SMP Wed May 8 20:52:16 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

    $ apt-show-versions -a openssh-server
    openssh-server 1:6.2p1-2 install ok installed
    openssh-server 1:6.2p1-2 saucy us.archive.ubuntu.com

## Problem

After a recent (accidental) upgrade to 13.10, recent updates to the
kernel seem to make inbound SSH connections problematic. Specifically,
the remote client is unable to connect to a login shell. This was
extremely difficult to diagnose, because all the client says is:

    $ ssh emu 
    Last login: Sun May 12 21:35:35 2013 from goldendelicious
    Shared connection to 192.168.1.127 closed.
    Connection to 192.168.1.127 closed by remote host.

Even with the verbose flag turned on (e.g. `-v` and `-vvv`) all you see
is that you connect, then get "debug1: Exit status -1" for no
discernable reason. The rest of the verbose output is completely
uninteresting However, there are other ways to debug this, as shown
below.

### SSH connection results in dumb terminal

    $ echo $TERM
    xterm-256color

    $ ssh emu /bin/echo \$TERM
    dumb

As you can see, openssh does not use the correct TERM environment
variable. However, manually setting TERM (e.g. `export TERM=vt100`)
doesn't solve the problem, because you don't actually have a pty. See
next section.

### Non-login shells work...sort of

    $ ssh emu /bin/bash -i
    bash: cannot set terminal process group (-1): Inappropriate ioctl for device
    bash: no job control in this shell
    emu:~$  echo $TERM
    echodumb
     $TERM
    emu:~$ tty
    tty
    not a tty

As you can see here, openssh is unable to open a tty or pty. If you try
to force it with `-t` or `-tt`, then it returns to the previous behavior
of simply closing the connection without explanation.

## Temporary Work-Around

One way to work around this problem is to use X-Forwarding to launch an
xterm as a login shell. For example:

    $ ssh emu xterm -e 'bash -l'

This works, assigns a pty, and otherwise results in a usable remote
connection, but is certainly not a substitute for having a working
non-X11 shell.

## Expected Behavior

1. OpenSSH should receive a pty on the remote host.
2. The TERM variable should be properly propogated.
3. There should be a more obvious way to debug this; openssh reports NOTHING of use in this situation, even with maximum verbosity.

ProblemType: Bug
DistroRelease: Ubuntu 13.10
Package: openssh-server 1:6.2p1-2
ProcVersionSignature: Ubuntu 3.9.0-1.5-generic 3.9.1
Uname: Linux 3.9.0-1-generic x86_64
NonfreeKernelModules: nvidia
ApportVersion: 2.10-0ubuntu3
Architecture: amd64
Date: Sun May 12 21:40:41 2013
EcryptfsInUse: Yes
InstallationDate: Installed on 2011-10-15 (575 days ago)
InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
MarkForUpload: True
SourcePackage: openssh
UpgradeStatus: Upgraded to saucy on 2013-05-06 (6 days ago)

** Affects: openssh (Ubuntu)
     Importance: Undecided
         Status: New

** Tags: amd64 apport-bug saucy uec-images

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to openssh in Ubuntu.
https://bugs.launchpad.net/bugs/1179344

Title:
  ssh doesn't get pty; says "inappropriate ioctl for device"

Status in “openssh” package in Ubuntu:
  New

Bug description:
  ## Versions

      $ lsb_release -rd
      Description:    Ubuntu Saucy Salamander (development branch)
      Release:        13.10

      $ uname -a
      Linux emu 3.9.0-1-generic #5-Ubuntu SMP Wed May 8 20:52:16 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

      $ apt-show-versions -a openssh-server
      openssh-server 1:6.2p1-2 install ok installed
      openssh-server 1:6.2p1-2 saucy us.archive.ubuntu.com

  ## Problem

  After a recent (accidental) upgrade to 13.10, recent updates to the
  kernel seem to make inbound SSH connections problematic. Specifically,
  the remote client is unable to connect to a login shell. This was
  extremely difficult to diagnose, because all the client says is:

      $ ssh emu 
      Last login: Sun May 12 21:35:35 2013 from goldendelicious
      Shared connection to 192.168.1.127 closed.
      Connection to 192.168.1.127 closed by remote host.

  Even with the verbose flag turned on (e.g. `-v` and `-vvv`) all you
  see is that you connect, then get "debug1: Exit status -1" for no
  discernable reason. The rest of the verbose output is completely
  uninteresting However, there are other ways to debug this, as shown
  below.

  ### SSH connection results in dumb terminal

      $ echo $TERM
      xterm-256color

      $ ssh emu /bin/echo \$TERM
      dumb

  As you can see, openssh does not use the correct TERM environment
  variable. However, manually setting TERM (e.g. `export TERM=vt100`)
  doesn't solve the problem, because you don't actually have a pty. See
  next section.

  ### Non-login shells work...sort of

      $ ssh emu /bin/bash -i
      bash: cannot set terminal process group (-1): Inappropriate ioctl for device
      bash: no job control in this shell
      emu:~$  echo $TERM
      echodumb
       $TERM
      emu:~$ tty
      tty
      not a tty

  As you can see here, openssh is unable to open a tty or pty. If you
  try to force it with `-t` or `-tt`, then it returns to the previous
  behavior of simply closing the connection without explanation.

  ## Temporary Work-Around

  One way to work around this problem is to use X-Forwarding to launch
  an xterm as a login shell. For example:

      $ ssh emu xterm -e 'bash -l'

  This works, assigns a pty, and otherwise results in a usable remote
  connection, but is certainly not a substitute for having a working
  non-X11 shell.

  ## Expected Behavior

  1. OpenSSH should receive a pty on the remote host.
  2. The TERM variable should be properly propogated.
  3. There should be a more obvious way to debug this; openssh reports NOTHING of use in this situation, even with maximum verbosity.

  ProblemType: Bug
  DistroRelease: Ubuntu 13.10
  Package: openssh-server 1:6.2p1-2
  ProcVersionSignature: Ubuntu 3.9.0-1.5-generic 3.9.1
  Uname: Linux 3.9.0-1-generic x86_64
  NonfreeKernelModules: nvidia
  ApportVersion: 2.10-0ubuntu3
  Architecture: amd64
  Date: Sun May 12 21:40:41 2013
  EcryptfsInUse: Yes
  InstallationDate: Installed on 2011-10-15 (575 days ago)
  InstallationMedia: Ubuntu 11.10 "Oneiric Ocelot" - Release amd64 (20111012)
  MarkForUpload: True
  SourcePackage: openssh
  UpgradeStatus: Upgraded to saucy on 2013-05-06 (6 days ago)

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1179344/+subscriptions