Secure Shell (stable) updated to 0.60

[Mike Frysinger]

i've just released Secure Shell (stable) 0.60 which changes the connection UI to not use frames anymore.  there's some WASM IPv6 connection fixes.  and some nasftp speed improvements.

Secure Shell (nassh) ChangeLog:

# 0.60, 2023-11-16, Deframe connection dialog, WASM IPv6 fixes, nasftp speed improvements.

* wassh: Fix IPv6 address parsing with socket get name.
* wassh: Have GAI return 2 results for AF_UNSPEC.
* wassh: Fix NUL termination in secure prompt.
* nassh: Add Ctrl+Shift+N binding.
* connect: Delete promptOnReload logic.
* connect: Make connection dialog a dedicated page.
* nasftp: Change <a> downloads to use blobs for all chunks.
* nasftp: Rate limit how often we update transfer bars.
* external api: Fix connection error responses.

-mike

[Robert Raszuk]

Hello,

Many thx for keep the work on Secure Shell. 

Unfortunately as discussed on the other thread the Secure Shell is still completely broken for Win 11 Chrome users. 

Interesting that with the new version 0.60 there is an error coming out which was never seen before: 

Of course connecting from the very same machine using WSL2 works perfectly fine: 

The embedded URL is: ssh://arr...@172.28.176.2 and chrome expands it to: 

chrome-extension://iodihamcpbpeioajjeobimgagajmlibd/html/nassh.html#uri:ssh%3A%2F%2Farrcus%40172.28.176.2

Many thx,

Robert

--
You received this message because you are subscribed to the Google Groups "chromium-hterm" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-hter...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/CAAbOScn0ib6Brw_fQL5_AVBV%2BnXcnEEJCfPK_jBqp-7HNu_rsg%40mail.gmail.com.

[Robert Raszuk]

It looks like it does not realize it is running on chrome with many profiles on widows 11 machine: 

Thx,

R.

[Jon]

Still doesn't work for me at all:

Loading wasm program… «««This is in alpha -- see https://crbug.com/1312115 for KIs»»» done.
Connecting to root@server…
OpenSSH_8.8p1, OpenSSL 1.0.2k  26 Jan 2017
debug1: Reading configuration data //etc/ssh_config
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug1: Connecting to fs [100::] port 2323.
debug1: Connection established.
debug1: identity file /.ssh/identity/id_rsa type -1
debug1: identity file /.ssh/identity/id_rsa-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.8

[Robert Raszuk]

Btw with the help of Jon I tried to run Secure Shell manually with -v switch. I get the below debugs (which are different then what he sees): 

And when I try host name (entered locally to windows hosts file) I get this and it hangs forever: 

And this poped up as well: 

Of course from terminal ping works fine: 

Any takers ? Anything else I could try ? 

Why lab1r1 name resolves to IPv6 address [100::]  then tries IPv4 to [1.0.0.0] if my local hosts file just says: 

172.28.176.2  lab1r1

Thx,

Robert

[Mike Frysinger]

it doesn't sound like a regression or this release changes things. please keep the discussion in the existing threads.

-mike 

[Mike Frysinger]

Secure Shell uses Chrome to resolve hostnames. if Chrome can't resolve it, there isn't anything we can do about it. you probably want to Google for Chrome DNS server handling.

-mike 

[Robert Raszuk]

Chrome is working fine with both IP addresses in the URLs as well as domain names. 

Many thx,

R.

[Jon]

Mine stopped working with an update but I have no idea which update as I can't roll back to check. And there has been zero response in the thread I made.

How can I either a) roll back to a working version or b) troubleshoot the error with the latest version?

[Luis Flores]

Hi, 

I was getting the same issue as above: 

Connecting to acip...@10.0.226.22...
ssh: connect to host 10.0.226.22 port 22: Bad address

Using the FQDN work for me....

not working:

chrome-extension://iodihamcpbpeioajjeobimgagajmlibd/html/nassh.html#acip...@10.0.226.22:22

working:

chrome-extension://iodihamcpbpeioajjeobimgagajmlibd/html/nassh.html#acip...@N9K-L3Out-17-32.mylab.com:22

nslookup N9K-L3Out-17-32.mylab.com
Name: N9K-L3Out-17-32.mylab.com
Address: 10.0.226.22

[Robert Raszuk]

Whow ... this indeed works ! 

But how do I embed this "-4" flag into the URL like ssh://arr...@172.28.176.2 ? 

Many many thx,

R.

On Fri, 17 Nov 2023 at 00:03, Greg W <gr...@skillwaze.com> wrote:

Another possible workaround:

https://issuetracker.google.com/issues/311233544

[Robert Raszuk]

Or how do I set Secure Shell cfg to always use this flag in all ssh connections ? 

Also why out of the sudden this is required ? This does look to me like chrome regression or secure shell regression but all issues started with chrome security updates ... 

Thank you all again,

R.

[Robert Raszuk]

OK let me respond to myself ... Here is the magic which makes Secure Shell work again ... 

Greg - many many thx for this link/hint. You do not know how many hours got waisted looking for solution to this issue ... 

Cheers,

R.

[Greg W]

Another possible workaround:

https://issuetracker.google.com/issues/311233544

On Thursday, November 16, 2023 at 8:46:12 AM UTC-8 Luis Flores wrote:

[Greg W]

Thanks but Mike deserves the credit.

Hopefully we'll get a real summary of what went wrong with issue 311233544. At a minimum let's suggest a few more test cases for the Secure Shell stable releases.

[Greg W]

I know it's not a Secure Shell stable issue, I just meant adding test cases to prevent the Chrome updates from passing in the first place.

[Maciej Żenczykowski]

Yeah, it looks like ipv6 literals now work, ie.  .../html/nassh.html#[2000::1]:22

But ipv4 literals are treated as ipv6 and thus don't work.

I can actually get ipv4 to work if I use .../html/nassh.html#root@[::ffff:0102:0304]:22 ipv4 mapped syntax (for 1.2.3.4).

This should hopefully be a simple bug to fix...

(possibly: if address matches regexp ^([0-9]+\.){3}[0-9]+$ then default to AF_INET  -- though they may be much nicer solutions)

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/CA%2Bb%2BERnrnEpKXUEmsya7pz%2BNRwEb4BAinPzYUbT4Mek-qKLDNQ%40mail.gmail.com.

Maciej Żenczykowski, Kernel Networking Developer @ Google

[Maciej Żenczykowski]

On Fri, Nov 17, 2023 at 1:00 PM Maciej Żenczykowski <ma...@google.com> wrote:

Yeah, it looks like ipv6 literals now work, ie.  .../html/nassh.html#[2000::1]:22

But ipv4 literals are treated as ipv6 and thus don't work.

I can actually get ipv4 to work if I use .../html/nassh.html#root@[::ffff:0102:0304]:22 ipv4 mapped syntax (for 1.2.3.4).

This should hopefully be a simple bug to fix...

(possibly: if address matches regexp ^([0-9]+\.){3}[0-9]+$ then default to AF_INET  -- though they may be much nicer solutions)

(and the fix is https://chromium-review.googlesource.com/5034086 )