Bug 3161 - ssh -J <public IPv6> <LL IPv6%scopeID> doesn't work as expected
Summary: ssh -J <public IPv6> <LL IPv6%scopeID> doesn't work as expected
Status: NEW
Alias: None
Product: Portable OpenSSH
Classification: Unclassified
Component: sshd (show other bugs)
Version: 8.2p1
Hardware: ix86 Linux
: P3 normal
Assignee: Assigned to nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-05-07 15:47 AEST by Owen DeLong
Modified: 2021-01-08 14:45 AEDT (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Owen DeLong 2020-05-07 15:47:37 AEST
I'm unsure whether this is a bug in the client or server or both.

It appears that there is no syntax which will work for this scenario:

1. Original Client and "Jump" Host both have public IPv6 addresses.
2. Target host has only Link Local IPv6 address on same link as Jump Host.

In principal, I believe the following incantation (or some similar form) should work (assuming Jump Host with address 2001:db8:f3f4::2ae0 and target host with address fe80::2001:db8:3 on common link interface enp0s31f6 (interface ID on jump host):

ssh -J '[2001:db8:f3f4::2ae0]' '[fe80::2001:db8:3%enp0s31f6]'

However, this results in the following:
% ssh -J '[2001:db8:f3f4::2ae0]' '[fe80::2001:db8:3]'                                                                 2020/05/06 22:41:51
Bad stdio forwarding specification '[[fe80::2001:db8:3%enp0s31f6]]:22'
ssh_exchange_identification: Connection closed by remote host

Jump host is Fedora 31 with the following SSH Packages installed:
sshpass-1.06-8.fc31.x86_64
qemu-block-ssh-4.1.1-1.fc31.x86_64
libssh-0.9.3-1.fc31.x86_64
apache-sshd-2.2.0-2.fc31.noarch
libssh-config-0.9.3-1.fc31.noarch
jsch-agent-proxy-sshagent-0.0.8-11.fc31.noarch
jsch-agent-proxy-trilead-ssh2-0.0.8-11.fc31.noarch
openssh-clients-8.1p1-1.fc31.x86_64
libssh2-1.9.0-3.fc31.x86_64
trilead-ssh2-217-13.jenkins8.fc31.noarch
openssh-8.1p1-1.fc31.x86_64
openssh-server-8.1p1-1.fc31.x86_64

Target host (and origin host) is iMac running OSX Mojave 10.14.6
OpenSSH_8.1p1, OpenSSL 1.1.1d FIPS  10 Sep 2019
(client and server report same version string)
Comment 1 Owen DeLong 2020-05-07 15:57:26 AEST
For purposes of complete information, yes, the following sequence does work as expected:
ssh '[2001:db8:f3f4::2ae0]' # ssh to jump host
ssh 'fe80::2001:db8:3%enp0s31f6' # executed on jump host

However, it is worth noting that the parser does not handle the following correctly:
ssh '[fe80::2001:db8:3%enp0s31f6]'
and reports:
ssh: Could not resolve hostname [fe80::2001:db8:3%enp0s31f6]: Name or service not known


It appears that there's a bug in the IPv6 address parser being used which does not handle addresses contained in brackets that also have zone ids specified (e.g. %enp0s31f6).

However, for jump, the following doesn't work either:
kiev:owen (170) ~ % ssh -J '[2001:db8:f3f4::2ae0]' 'fe80::2001:db8:3%enp0s31f6'                                                                   2020/05/06 22:53:36
channel 0: open failed: connect failed: open failed
stdio forwarding failed
ssh_exchange_identification: Connection closed by remote host


I have anonymized all fo the addresses in this report by using example prefix in place of actual addresses. Any inconsistencies in the addresses are typographical errors during manual editing for anonymization. The anonymized addresses are properly:
Jump Host (Fedora 31): 2001:db8:f3f4::2ae0
Link Local of iMac: fe80::2001:db8:3
GUA of iMac (not mentioned, likely not relevant) 2001:db8:f3f4::3
Comment 2 Damien Miller 2021-01-08 14:45:44 AEDT
you shouldn't enclose the addresses in square braces, OpenSSH only accepts bare addresses.