Exporting and Importing

feature
v1_0

(Yang.Y) #1

Some thoughts:

  1. Unlike SSH Tunnel, Core Tunnel’s exporting format follows ssh_config(5) specs
  2. But also able to import JSON file exported from SSH Tunnel

Any advices on this feature are welcome :grinning:


Feature request(s) and first impression
Core Tunnel 1.0 Release Plan
(Kim) #2

Another thought is to allow pasting of the ssh command line and parse it then run or save it


New tunnel from ssh command line
(chris) #3

Unlike SSH Tunnel, Core Tunnel’s exporting format follows ssh_config(5) specs

Importing existing ssh_config files is also planned? That would be quite useful.

A command line interface would top that even more. Then we could keep the tunnel entries withing Core Tunnel synced to whatever source one prefers (storage, LDAP, AD,…).


(Yang.Y) #4

Have created a separate topic for this feature:


#5

Wonderful, I’d love this feature. I’ve got a pretty big number of SSH tunnels configured in SSH tunnel and it would take some time to re-set them up.


(Steven) #6

Would love to have importer from SSH Tunnel file. I have quite many tunnel using SSH Tunnel that it would takes time if I had to do it one by one again in Core Tunnel.


(Yang.Y) #7

You can expect it in next alpha, stay tuned :slight_smile:


(Stefano) #8

I have sent an email about this some years ago. I would love to have synchronisation on iCloud (or Dropbox) of my tunnels. Using two different laptops and it is a pain to keep those synced.


(Yang.Y) #9

Sync is one of my heart pains :broken_heart:

The good news is Core Tunnel was born with sync prepared :heartbeat: , let’s track it here:


(chris) #10

I guess, I’ve found a bug in the latest alpha .2 :

There are two very similar host definitions in my ~/.ssh/config, one with an IP to connect to and one with a hostname:

Host host1
Hostname a.example.com
HostKeyAlias a.example.com
Port 22
User ubuntu
Identityfile ~/.ssh/2017/id_rsa-ext

Host host2
Hostname 192.168.110.110
HostKeyAlias b.example.com
Port 22
User ubuntu
Identityfile ~/.ssh/2018/id_ecdsa-ext

Since the .ssh/config settings are read by core tunnel, I’ve created two entries in core tunnel, just entering the hostnames “host1” (and in another “host2”). The tunnel for host1 works fine, core tunnel pulls the user and key from my .ssh/config. (Thanks for that btw, saves me a lot of time!)

Host2 however fails and writes a lot of “@@@@@…” into the status line right below the hostname within core tunnel.


While writing this, I’ve noticed the underlying root cause: my hostkey for host2 didn’t match the one on record in known_hosts (disabled dsa/rsa/ecdsa hostkeys recently, server is now offering only the ed25519 host key). But instead of a popup, the connection fails.

summed up:
it looks like, that when the type of an host-key changed, core tunnel does something weird instead of showing the “host key differs” - popup.
Deleting the known_hosts (or removing the old, invalid hostkeys in question) fixes that.

regards,

chris


(Yang.Y) #11

I’m able to reproduce the issue, and the weird “@@@@@…” actually a portion of a fatal error:

Core Tunnel should be improved to handle this situation properly and report the real failure reason.

But we shouldn’t expect “host key differs” popup, “hostkey has changed” is a very dangerous signal, and must treat it carefully.

If you paste “Equivalent Command” in terminal, you will find ssh command also fails without ask user accepting the changed hostkey.


(chris) #12

Do you think it’s possible to let the user choose to replace the known host key from within the popup/warning window?
Maybe with some kind of double-confirmation (which requires a manual text-input)?
This way, the workflow within core tunnel wouldn’t be interrupted too much (to manually delete the old key and resolve the issue with another application).


(Yang.Y) #13

Personally, I think though it’s possible but unnecessary. An alternative solution is allow user delete (might also able to add) known host key items in “Preferences…”, it’s easy to understand for most users and won’t alter the default behaviour too much.