ssh connection failure error message confusing when talking to dual IPv4/6 host

Bug #1028182 reported by Scott Kitterman
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
portable OpenSSH
Confirmed
Medium
openssh (Ubuntu)
New
Medium
Unassigned

Bug Description

I have a dual IPv4/6 server which has both A and AAAA records published for it's primary domain name. I had just rebooted the server for a kernel update and was trying to ssh back in. It failed with a "network unreachable" error which was totally misleading. The issue was that the server was slow to come up and was not listening on port 22 yet. The error message should have been "connection refused".

During the period when I was waiting, if I used ssh directly to the IPv4 address, I (correctly) got "connection refused". When I ssh'd to the IPv6 address I (also correctly) got network unreachable since there is no IPv6 connectivity other than link-local on the network the ssh client was connecting from.

it looks like what ssh is doing in the case of a host with dual A/AAAA records is looking them both up, trying both connections, and if the case of both failing, it's returning the IPv6 error message. In this case it was quite confusing as there's no indication it's an IPv6 connection the message is about. I was trying to figure out how I could ping the server and at the same time have the network be unreachable.

It would be better if, in the case of two errors, network unreachable is only handed back to the user if no other error (such as connection refused) does not indicate that the network was reachable and a connection to the remote server made at some level.

ProblemType: Bug
DistroRelease: Ubuntu 12.04
Package: openssh-client 1:5.9p1-5ubuntu1
ProcVersionSignature: Ubuntu 3.2.0-27.43-generic-pae 3.2.21
Uname: Linux 3.2.0-27-generic-pae i686
ApportVersion: 2.0.1-0ubuntu11
Architecture: i386
Date: Mon Jul 23 19:28:02 2012
EcryptfsInUse: Yes
InstallationMedia: Kubuntu 11.04 "Natty Narwhal" - Beta i386 (20110330)
ProcEnviron:
 LANGUAGE=
 TERM=xterm
 LANG=en_US.UTF-8
 SHELL=/bin/bash
RelatedPackageVersions:
 ssh-askpass N/A
 libpam-ssh N/A
 keychain N/A
 ssh-askpass-gnome N/A
SSHClientVersion: OpenSSH_5.9p1 Debian-5ubuntu1, OpenSSL 1.0.1 14 Mar 2012
SourcePackage: openssh
UpgradeStatus: Upgraded to precise on 2012-04-09 (105 days ago)

Revision history for this message
Scott Kitterman (kitterman) wrote :
Robie Basak (racb)
Changed in openssh (Ubuntu):
importance: Undecided → Medium
Revision history for this message
In , Sklist (sklist) wrote :

I have a dual IPv4/6 server which has both A and AAAA records
  published for it's primary domain name. I had just rebooted the
  server for a kernel update and was trying to ssh back in. It failed
  with a "network unreachable" error which was totally misleading. The
  issue was that the server was slow to come up and was not listening on
  port 22 yet. The error message should have been "connection refused".

  During the period when I was waiting, if I used ssh directly to the
  IPv4 address, I (correctly) got "connection refused". When I ssh'd to
  the IPv6 address I (also correctly) got network unreachable since
  there is no IPv6 connectivity other than link-local on the network the
  ssh client was connecting from.

  it looks like what ssh is doing in the case of a host with dual A/AAAA
  records is looking them both up, trying both connections, and if the
  case of both failing, it's returning the IPv6 error message. In this
  case it was quite confusing as there's no indication it's an IPv6
  connection the message is about. I was trying to figure out how I
  could ping the server and at the same time have the network be
  unreachable.

  It would be better if, in the case of two errors, network unreachable
  is only handed back to the user if no other error (such as connection
  refused) does not indicate that the network was reachable and a
  connection to the remote server made at some level.

Changed in openssh:
importance: Unknown → Medium
status: Unknown → Confirmed
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.