Unable to connect to (link-local) ipv6 address

796 views
Skip to first unread message

telnetuserid

unread,
Oct 19, 2014, 9:30:40 PM10/19/14
to chromiu...@chromium.org
I am using ipv6 only on local network. Whenever I try to connect to the
ipv6 address, hterm says that the connection is refused. I even add -6
flag to tell hterm (which seems to be based on openssh) to explicitly
use ipv6 when connecting.

This behavior is not happening when using other desktop ssh client, such
as PuTTY, Cygwin-openssh, TeraTerm, and Bitvise.

Robert Ginda

unread,
Oct 20, 2014, 1:20:32 PM10/20/14
to telnetuserid, chromium-hterm
Yes, Secure Shell is based on OpenSSH and takes most of the same command line arguments in the "SSH Arguments" field.

Do you get any useful log messages if you add the -v argument?  Any chance you need to use the -b argument to bind to the correct source address?


Rob.


--
You received this message because you are subscribed to the Google Groups "chromium-hterm" group.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/20141020013035.GA26790%40SDF.ORG.

Robert Ginda

unread,
Oct 20, 2014, 3:32:37 PM10/20/14
to telnetuserid, chromium-hterm
Does the log change at all if you give a bogus ipv6 address?

On Mon, Oct 20, 2014 at 12:16 PM, telnetuserid <telnet...@sdf.org> wrote:
On Mon, Oct 20, 2014 at 10:20:10AM -0700, Robert Ginda wrote:
> Yes, Secure Shell is based on OpenSSH and takes most of the same command
> line arguments in the "SSH Arguments" field.
>
> Do you get any useful log messages if you add the -v argument?  Any chance
> you need to use the -b argument to bind to the correct source address?
>
>
> Rob.
>
> On Sun, Oct 19, 2014 at 6:30 PM, telnetuserid <telnet...@sdf.org> wrote:
>
> > I am using ipv6 only on local network. Whenever I try to connect to the
> > ipv6 address, hterm says that the connection is refused. I even add -6
> > flag to tell hterm (which seems to be based on openssh) to explicitly
> > use ipv6 when connecting.
> >
> > This behavior is not happening when using other desktop ssh client, such
> > as PuTTY, Cygwin-openssh, TeraTerm, and Bitvise.
> >

The log message says that my connection attempt is refused.

Welcome to Secure Shell version 0.8.31.
Answers to Frequently Asked Questions: http://goo.gl/TK7876
Connecting to root@fda7:6b4e:a1de::1...
Loading NaCl plugin... done.
OpenSSH_6.6, OpenSSL 1.0.1g 7 Apr 2014
debug1: Reading configuration data /.ssh/config
debug1: /.ssh/config line 118: Applying options for *
debug2: ssh_connect: needpriv 0
debug1: Connecting to fda7:6b4e:a1de::1 [fda7:6b4e:a1de::1] port 22.
debug1: connect to address fda7:6b4e:a1de::1 port 22: Connection refused
ssh: connect to host fda7:6b4e:a1de::1 port 22: Connection refused
NaCl plugin exited with status code 255.
(R)econnect, (C)hoose another connection, or E(x)it?

The flags I use are '-vvv -6 -i ~/.ssh/openssh.key'

The same result is happening with '-b fda7:6b4e:a1de:0:54ec:84fd:7cfd:eecd' or
'-b fda7:6b4e:a1de:0:b4ed:ead5:475d:929e' or '-b fda7:6b4e:a1de::16a'.

Here is cygwin-openssh log with verbose option.
```
OpenSSH_6.7p1, OpenSSL 1.0.1j 15 Oct 2014
debug1: Reading configuration data /cygdrive/c/Users/telnetuserid/.ssh/config
debug1: /cygdrive/c/Users/telnetuserid/.ssh/config line 118: Applying options for *
debug1: Connecting to fda7:6b4e:a1de::1 [fda7:6b4e:a1de::1] port 22.
debug1: Connection established.
debug1: identity file /cygdrive/c/Users/telnetuserid/.ssh/openssh.key type 1
debug1: key_load_public: No such file or directory
debug1: identity file /cygdrive/c/Users/telnetuserid/.ssh/openssh.key-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7
debug1: Remote protocol version 2.0, remote software version dropbear_2014.65
debug1: no match: dropbear_2014.65
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: server->client aes128-ctr hmac-sha1 none
debug1: kex: client->server aes128-ctr hmac-sha1 none
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug1: Server host key: RSA 58:4a:2a:ea:9c:8f:9c:5f:0e:7f:a9:86:bc:6c:e9:0c
debug1: Host 'fda7:6b4e:a1de::1' is known and matches the RSA host key.
debug1: Found key in /cygdrive/c/Users/telnetuserid/.ssh/known_hosts:5
Host key fingerprint is 58:4a:2a:ea:9c:8f:9c:5f:0e:7f:a9:86:bc:6c:e9:0c
+---[RSA 2048]----+
|                 |
|                 |
|      . .        |
|     o +         |
|  . . o S        |
| . .             |
|.E..o.  .        |
|+ B==. o         |
| B=Bo+o          |
+-----------------+

debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /cygdrive/c/Users/telnetuserid/.ssh/openssh.key
debug1: Server accepts key: pkalg ssh-rsa blen 279
debug1: key_load_private_type: incorrect passphrase supplied to decrypt private key
Enter passphrase for key '/cygdrive/c/Users/telnetuserid/.ssh/openssh.key':
debug1: Authentication succeeded (publickey).
Authenticated to fda7:6b4e:a1de::1 ([fda7:6b4e:a1de::1]:22).
debug1: channel 0: new [client-session]
debug1: Entering interactive session.


BusyBox v1.22.1 (2014-10-13 19:55:36 WIB) built-in shell (ash)
Enter 'help' for a list of built-in commands.

  _______                     ________        __
 |       |.-----.-----.-----.|  |  |  |.----.|  |_
 |   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
 |_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
 -----------------------------------------------------
 CHAOS CALMER (Bleeding Edge, r42889)
 -----------------------------------------------------
  * 1 1/2 oz Gin            Shake with a glassful
  * 1/4 oz Triple Sec       of broken ice and pour
  * 3/4 oz Lime Juice       unstrained into a goblet.
  * 1 1/2 oz Orange Juice
  * 1 tsp. Grenadine Syrup
 -----------------------------------------------------
 root@OpenWrt:~#
```
I don't think that Windows is blocking ipv6 connection.

NetBSD

unread,
Oct 20, 2014, 7:54:36 PM10/20/14
to Robert Ginda, chromiu...@chromium.org
On Mon, Oct 20, 2014 at 12:32:15PM -0700, Robert Ginda wrote:
> Does the log change at all if you give a bogus ipv6 address?
>
I don't know if it'll work. I'll give it a try later.

If you have an ipv6, you can test to connect to this server.
It's bshellz.net free shell account.

2a01:4f8:191:9111:30::1

Unfortunately, I don't have access to public ipv6 address yet
to test if the problem occurs only on local ipv6 or all ipv6 hosts.

telnetuserid

unread,
Oct 21, 2014, 8:59:40 AM10/21/14
to Robert Ginda, chromiu...@chromium.org
I tried binding with bogus ipv6 address, but it didn't work. Still no success connecting to ipv6 address.
I even tried other extension, such ash FireSSH. Both Chrome Secure Shell and FireSSH for Chrome didn't
connect to ipv6 address.

As I'm frustated about how Chrome handle ipv6 connection for extensions, I tried to give FireSSH for
Firefox
a try. Amazingly, FireSSH on Firefox works fine, even on literal ipv6 address.

Is this due to unavailable real ipv6 address, so that Chrome blocks all attempt to connect via ipv6?
I don't see any needs to block ipv6 connections, even with local-only ipv6 address(es).

Mike Frysinger

unread,
Oct 21, 2014, 10:50:03 AM10/21/14
to NetBSD, Robert Ginda, chromiu...@chromium.org
i can connect to public ipv6 just fine under Linux & CrOS. using
vap...@wh0rd.org with -6:
======================================================================
Connecting to vap...@wh0rd.org...
Loading NaCl plugin... done.
The authenticity of host 'wh0rd.org (2001:41c8:1:4f39::10)' can't be
established.
ECDSA key fingerprint is 0c:fa:1a:33:96:e2:c1:39:03:ef:e2:02:b0:78:da:5e.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added 'wh0rd.org' (ECDSA) to the list of known hosts.
vap...@wh0rd.org's password:
Last login: Tue Oct 21 14:36:01 2014 from 2620:15c:6:30:a9a4:d3c7:3543:fd11
No Sockets found in /home/vapier/.screen.

vapier@wh0rd 0:0 ~ $ env | grep SSH
SSH_CLIENT=2620:0:1004:2:c5d:9348:bd6:f69a 58719 22
SSH_TTY=/dev/pts/0
SSH_CONNECTION=2620:0:1004:2:c5d:9348:bd6:f69a 58719 2001:41c8:1:4f39::10 22
======================================================================

i can also connect to localhost6 just fine:
======================================================================
Connecting to vapier@::1...
Loading NaCl plugin... done.
The authenticity of host '::1 (::1)' can't be established.
RSA key fingerprint is dd:25:e9:d6:19:1f:2f:03:ea:3a:8d:22:cf:9e:bd:05.
Are you sure you want to continue connecting (yes/no)? yes
Warning: Permanently added '::1' (RSA) to the list of known hosts.
Password:
======================================================================

my linux system works w/link ipv6 addrs:
======================================================================
$ ip addr show em1 scope link
2: em1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast
state UP group default qlen 1000
link/ether ac:16:2d:07:50:1b brd ff:ff:ff:ff:ff:ff
inet6 fe80::ae16:2dff:fe07:501b/64 scope link
valid_lft forever preferred_lft forever
$ nc -6 -vvv fe80::ae16:2dff:fe07:501b%em1 22
Connection to fe80::ae16:2dff:fe07:501b%em1 22 port [tcp/ssh] succeeded!
SSH-2.0-OpenSSH_6.6.1
======================================================================

however, connecting via SecureShell fails:
======================================================================
Connecting to vapier@fe80::ae16:2dff:fe07:501b%em1...
Loading NaCl plugin... done.
ssh: connect to host fe80::ae16:2dff:fe07:501b%em1 port 22: Connection refused
NaCl plugin exited with status code 255.
(R)econnect, (C)hoose another connection, or E(x)it?
======================================================================

my guess is the simple network library we're linking SecureShell
against does not process the %zone-index syntax properly:
http://en.wikipedia.org/wiki/IPv6_address#Link-local_addresses_and_zone_indices
-mike

NetBSD

unread,
Oct 21, 2014, 12:20:52 PM10/21/14
to Mike Frysinger, Robert Ginda, chromiu...@chromium.org
Thanks for your additional explanation. It seems that the problem only occurs on
link-local ipv6 only.

I hope this problem will be fixed soon.

Robert Ginda

unread,
Oct 21, 2014, 3:16:12 PM10/21/14
to telnetuserid, chromium-hterm
I was actually suggesting you *connect* to a bogus address, to see if the verbose log is different than the "connection refused" you get when connecting to a good address.

telnetuserid

unread,
Oct 21, 2014, 7:53:03 PM10/21/14
to Robert Ginda, chromium-hterm
On Tue, Oct 21, 2014 at 12:15:49PM -0700, Robert Ginda wrote:
> I was actually suggesting you *connect* to a bogus address, to see if the
> verbose log is different than the "connection refused" you get when
> connecting to a good address.

Sorry for my mistake.

Here is connection log when I attempt to connect to "bogus" ipv6 address.

```
Connecting to root@fda7:11be:a1df::2...
Loading NaCl plugin... done.
OpenSSH_6.6, OpenSSL 1.0.1g 7 Apr 2014
debug1: Reading configuration data /.ssh/config
debug1: /.ssh/config line 118: Applying options for *
debug1: Connecting to fda7:11be:a1df::2 [fda7:11be:a1df::2] port 22.
debug1: connect to address fda7:11be:a1df::2 port 22: Connection refused
ssh: connect to host fda7:11be:a1df::2 port 22: Connection refused
NaCl plugin exited with status code 255.
(R)econnect, (C)hoose another connection, or E(x)it?
```

For your information, my ~/.ssh/config is shared from cygwin ssh. On line 118 is
a global configuration to display randomart image of known host.

```
Host *
VisualHostKey yes
```

I hope this will give you a good information about the error.

telnetuserid

unread,
Oct 23, 2014, 9:54:33 AM10/23/14
to Robert Ginda, chromium-hterm
After some trials and errors, I found that Chrome doesn't enable ipv6
with my connection by default. I think this is the cause of extensions,
including Secure Shell, don't work with link-local ipv6.

Starting Chrome with flag `--enable-ipv6` fixes this problem.

I hope this information will be useful for Secure Shell and Chromium
development.
Reply all
Reply to author
Forward
0 new messages