Secure shell is broken

[Robert Raszuk]

Hi, 

Since previous chrome update I can no longer (almost always in 90% of cases) use Secure Shell extension. 

I am getting following errors: 

- - - 

'fileSystemProvider' is not allowed for specified platform.

'terminalPrivate' is not allowed for specified platform.

Blocked attempt to show a 'beforeunload' confirmation panel for a frame that never had a user gesture since its load. https://www.chromestatus.com/feature/5082396709879808

Ignoring IP_TOS=72

Ignoring IP_TOS=72

Blocked attempt to show a 'beforeunload' confirmation panel for a frame that never had a user gesture since its load. https://www.chromestatus.com/feature/5082396709879808

- - -

By "almost always" I observed that if I restart extension and within 5-10 sec I can connect with no issue. After that the following errors are reported and screen is stuck at this point: 

Secure Shell
On
Description
Terminal emulator and SSH and SFTP client.
Version
7 Oct 2023 14:09
Size
41.5 MB
ID
algkcnfjnajfhgimadimbjhmpaeohhln

Google Chrome
Chrome is up to date
Version 117.0.5938.150 (Official Build) (64-bit)

Many thx,

Robert Raszuk

[Robert Raszuk]

Btw when I reverted back to iodihamcpbpeioajjeobimgagajmlibd I see a different error: 

= = =

Blocked attempt to show a 'beforeunload' confirmation panel for a frame that never had a user gesture since its load. https://www.chromestatus.com/feature/5082396709879808

Context
html/nassh.html#uri:ssh%3A%2F%2Farrcus%40172.28.176.2
Stack Trace
html/nassh.html#uri:ssh%3A%2F%2Farrcus%40172.28.176.2:0 (anonymous function)

= = = 

Of course in all cases ssh to the same userid@node from shell works fine without any glitch each time. 

Thx

[Robert Raszuk]

On a different Win 11 when I tried today I see a new error when trying to establish ssh session from the browser: 

console.warn('Failed to request persistent storage.');

Errors

Context

html/nassh.html#uri:ssh%3A%2F%2Farrcus%40172.28.176.2

Stack Trace

• js/nassh_main.js:63 (anonymous function)

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 121 122 123 124 125 126 127 128 129 130 131 132 133 134 135 136 137 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167 168 169 170 171 172 173 174 175 176 177 178 179 180 181 182 183

// Copyright 2012 The ChromiumOS Authors // Use of this source code is governed by a BSD-style license that can be // found in the LICENSE file. import {lib} from '../../libdot/index.js'; import {hterm} from '../../hterm/index.js'; import { disableTabDiscarding, getSyncStorage, loadWebFonts, localize, openOptionsPage, runtimeSendMessage, sendFeedback, setupForWebApp, watchBackgroundColor, } from './nassh.js'; import {CommandInstance} from './nassh_command_instance.js'; /** * Open a new window to the specified URL. * * We have to go through the background page in order to set chrome=no. * Normally Chrome will ignore it (for security reasons) when run in a * webpage or tab. Extensions/apps are allowed to though, so grab the * background page and let it do the open for us. * * @param {string} url The URL to open. * @return {!Promise} A promise resolving once the window opens. */ const openNewWindow = function(url) { const msg = { command: 'nassh', width: globalThis.innerWidth, height: globalThis.innerHeight, url: url, window: true, }; return runtimeSendMessage(msg).then((response) => { if (response && response.error) { throw new Error(`request failed: ${response.message}`); } }); }; /** * CSP means that we can't kick off the initialization from the html file, * so we do it like this instead. */ globalThis.addEventListener('DOMContentLoaded', async (event) => { // If we're being opened by a link from another page, clear the opener setting // so we can't reach back into them. They should have used noopener, but help // cover if they don't. if (globalThis.opener !== null) { globalThis.opener = null; globalThis.location.reload(); return; } // Check if site's storage has been marked as persistent. if (globalThis.navigator?.storage?.persist && globalThis.navigator?.storage?.persisted) { if (!await navigator.storage.persisted()) { // Request persistent storage for site. const isPersisted = await navigator.storage.persist(); if (!isPersisted) { console.warn('Failed to request persistent storage.'); } } } const params = new URLSearchParams(globalThis.location.search);

Here chrome version was: 

Updating Chrome (66%)
Version 117.0.5938.149 (Official Build) (64-bit)

Thx,
R.

[Lex Anderson]

Im experiencing the same. It's disappointing that Google cancels so many of its useful projects.

[Robert Raszuk]

Is Secure Shell cancelled or just best effort project ? I would assume/hope this is just a bug. 

If it is cancelled any hints on what could be the substitute to ssh from browser with embedded URL ? Firing external app ? 

Many thx,

R.

[Nom De Plume]

I have no idea if you are using the Chrome app or the extension. The
app has been deprecated for some time in favor of the Chrome extension
from the webstore. I have been using the extension for some time and
it works extremely well and is constantly updated. After lamenting the
loss of the app, I quickly fell in love with its replacement. Same
development team or at least Mike is / was responsible for both


> Is Secure Shell cancelled or just best effort project ? I would assume/hope this is just a bug. If it is cancelled any hints on what could be the substitute to ssh from browser with embedded URL ? Firing external app ? Many thx, R. To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/2f629bda-6008-41c5-b80b-16b9de05e757n%40chromium.org.

[Aaron Anderson]

I am also using the extension, both the stable version (iodihamcpbpeioajjeobimgagajmlibd) and the dev version (algkcnfjnajfhgimadimbjhmpaeohhln) with identical results as reported by Robert. The server logs show a disconnect from the client side. Adding debug does not reveal much apart from the client disconnect happening sometime after the local version string is output. And, yes very occasionally after terminating and restarting the service workers the extension will connect successfully, but less than 1/20 in my case.

On Sun, Oct 15, 2023 at 6:14 AM Robert Raszuk <rra...@gmail.com> wrote:

I am using the extension. I have been using it and it worked flowless for over one year. 

After updating chrome to incorporate some security updates it simply "almost" stop working as reported above. 

I say "almost" - as if I am persistent and either after disable/enable the extension or keep retrying for 20 times it does connect. In all other cases it simply stops at this point: 

Many thx,

R.

[Robert Raszuk]

I am using the extension. I have been using it and it worked flowless for over one year. 

After updating chrome to incorporate some security updates it simply "almost" stop working as reported above. 

I say "almost" - as if I am persistent and either after disable/enable the extension or keep retrying for 20 times it does connect. In all other cases it simply stops at this point: 

Many thx,

R.

On Saturday, 14 October 2023 at 17:57:46 UTC+2 david....@gmail.com wrote:

[Maciej Żenczykowski]

I use iodihamcpbpeioajjeobimgagajmlibd all the time on my chromebook - and haven't seen *any* issues.

I wonder if this is some chrome on windows specific bug...

--
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/CAGmwJmvvpVAmadLLQihi%3DCUCJoOyOOwHzYk%2BLAJJbCL9Z4npvg%40mail.gmail.com.

Maciej Żenczykowski, Kernel Networking Developer @ Google

[Robert Raszuk]

Extremely likely ... 

[Jon]

Unfortunately this is not the case. The extensions worked great for years but no longer works.

[Nom De Plume]

Since not everyone has the issue, it is worth seeing if something else can be interfering. I recently had an issue with a website that kept sending me back to the login screen. The website worked fine with Firefox but not with Chrome. Get yourself back to a very basic browser profile. You can create a guest profile and then add just the ssh extension. 

--

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/ed3a8b90-1381-4f53-a152-200b0f97214fn%40chromium.org.

[Robert Raszuk]

Hi,

I followed your advise and tested the clean just created chrome profile. Unfortunately the error is identical with the same setup on my real chrome profile and it fails to connect with error "Failed to request persistent storage": 

Kind regards,

Robert. 

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/CADNdfaWELZDkNzXnoW4XbTwfpQixhSXNtd00-rfpY-R%2BT1%3DBFw%40mail.gmail.com.

[Maciej Żenczykowski]

What version of the browser (and OS) and what version of the app/extension are you using?

Are you sure you're using a real chrome browser and not some alternative security locked down or corporate/enterprise locked down version?

Persistent storage has been a feature for a *long* time.

Perhaps something is corrupt... try uninstalling the extension and reinstalling it from the webstore...

[Robert Raszuk]

Hi Maciek,

I have been using vanilla chrome (no corporate junk of any sort): 

Version 118.0.5993.118 (Official Build) (64-bit)

Now when I checked version it auto upgraded to: 

Version 119.0.6045.106 (Official Build) (64-bit)

The error/warning changed but the Secure Shell extension is still not working: 

I am using Secure Shell 0.59 and did removed and reinstalled it many times. Funny it works only once after the fresh install then stops. Almost like some LOCK files get's setup which subsequent runs can not clear. But also if I keep trying for 20_ times I sometimes get lucky to connect. 

As I mentioned in this case the extension was working perfectly till I applied one of the lates chrome urgent security updates then it started to permanently fail. 

I am pretty sure this is related to some security setting and I am a bit stuck here. I installed chromium too on my win 11 (well two different machines I tried with identical results) but I have no clue how to change default ssh setting now on win11 to allow chromium and not chrome to handle ssh URLs. 

When I look at files this extension places in C:\Users\rober\AppData\Local\Google\Chrome\User Data\Profile 1\Local Extension Settings\iodihamcpbpeioajjeobimgagajmlibd

MANIFEST-00001 file looks like this: 

957c b9c5 2200 0101 1a6c 6576 656c 6462

2e42 7974 6577 6973 6543 6f6d 7061 7261
746f 7202 0003 0204 00

No idea if this is correct or not. Extensions docs rather suggest that this should be json file. 

Many thx for any help,

Robert

[Robert Raszuk]

Correction: 

Funny it works only once after the fresh install then stops. Almost like some LOCK files get's setup which subsequent runs can not clear. But also if I keep trying for 20_ times I sometimes get lucky to connect. 

Now it no longer works at all - neither after fresh install nor even when trying for 30 times .... 

[Maciej Żenczykowski]

Hmm.

My home windows 10 pro 22H2 (19045.3636) running Google Chrome 118.0.5993.118 (and it started the update as I look at the version, but I haven't restarted chrome yet) with the iodiham... extension (Secure Shell 0.59 - wasm) works just fine for me...

(I never use it on windows [instead using WSL2 ssh client there], usually just on my chromebook, but it sync'ed over all my settings from my chromebook just fine, and connected/logged into to my openwrt router...)

Maciej Żenczykowski, Kernel Networking Developer @ Google

[Robert Raszuk]

Yeh ... when I was running windows 10 it was always rock solid. There must be some interaction between Windows 11 and new chrome security updates which now completely breaks Secure Shell extension ver 0.59.  

>  [instead using WSL2 ssh client there]

Is there any hint to redirect ssh:// url from web page link to fire WLS2 terminal instead of any chrome extension ? If not from chrome - from any browser would be fine with me. I would love to go that way ... so far failed to find any way to do that. 

Many thx again,

Robert

[Maciej Żenczykowski]

On Thu, Nov 2, 2023 at 5:12 PM Robert Raszuk <rra...@gmail.com> wrote:

Yeh ... when I was running windows 10 it was always rock solid.

Ah...
 

There must be some interaction between Windows 11 and new chrome security updates which now completely breaks Secure Shell extension ver 0.59.  

I'm afraid none of my own Windows running hardware is new enough to support Win11 (either too old cpu or no TPM).

As such, I've intentionally held off on installing Win11 on any of my family's machines because of that (also Win11 opinions were bad...).

Thus, I've never even used it...

 

>  [instead using WSL2 ssh client there]

Is there any hint to redirect ssh:// url from web page link to fire WLS2 terminal instead of any chrome extension ? If not from chrome - from any browser would be fine with me. I would love to go that way ... so far failed to find any way to do that. 

No idea, sorry, I really only use Windows for gaming, doing all my productivity stuff on chrome os or linux.

Many thx again,

Robert

On Fri, 3 Nov 2023 at 01:07, Maciej Żenczykowski <ma...@google.com> wrote:

Hmm.

My home windows 10 pro 22H2 (19045.3636) running Google Chrome 118.0.5993.118 (and it started the update as I look at the version, but I haven't restarted chrome yet) with the iodiham... extension (Secure Shell 0.59 - wasm) works just fine for me...

(I never use it on windows [instead using WSL2 ssh client there], usually just on my chromebook, but it sync'ed over all my settings from my chromebook just fine, and connected/logged into to my openwrt router...)

On Thu, Nov 2, 2023 at 4:08 PM Robert Raszuk <rra...@gmail.com> wrote:

Correction: 

Funny it works only once after the fresh install then stops. Almost like some LOCK files get's setup which subsequent runs can not clear. But also if I keep trying for 20_ times I sometimes get lucky to connect. 

Now it no longer works at all - neither after fresh install nor even when trying for 30 times .... 

On Thu, 2 Nov 2023 at 23:25, Robert Raszuk <rra...@gmail.com> wrote:

Hi Maciek,

I have been using vanilla chrome (no corporate junk of any sort): 

Version 118.0.5993.118 (Official Build) (64-bit)

Now when I checked version it auto upgraded to: 

Version 119.0.6045.106 (Official Build) (64-bit)

The error/warning changed but the Secure Shell extension is still not working: 

developer.chrome.com/docs/extensions/reference/fileSystemProvider/

"Important: This API works only on ChromeOS"

So why is it showing up on windows?

Where are you seeing these errors?

 

I am using Secure Shell 0.59 and did removed and reinstalled it many times. Funny it works only once after the fresh install then stops. Almost like some LOCK files get's setup which subsequent runs can not clear. But also if I keep trying for 20_ times I sometimes get lucky to connect. 

As I mentioned in this case the extension was working perfectly till I applied one of the lates chrome urgent security updates then it started to permanently fail. 

I am pretty sure this is related to some security setting and I am a bit stuck here. I installed chromium too on my win 11 (well two different machines I tried with identical results) but I have no clue how to change default ssh setting now on win11 to allow chromium and not chrome to handle ssh URLs. 

When I look at files this extension places in C:\Users\rober\AppData\Local\Google\Chrome\User Data\Profile 1\Local Extension Settings\iodihamcpbpeioajjeobimgagajmlibd

Curious I don't see that at all... closest I found is under

C:\Users\MaZe\AppData\Local\Google\Chrome\User Data\Default\ 

(maybe because I both have multiple profiles setup, and sync?)

 

MANIFEST-00001 file looks like this: 

957c b9c5 2200 0101 1a6c 6576 656c 6462

2e42 7974 6577 6973 6543 6f6d 7061 7261
746f 7202 0003 0204 00

I do see a file like that (at a diff location) - the above includes ascii 'leveldb.BytewiseComparator' and seems irrelevant...

I see a (much larger) manifest.json in a different directory.

[maze@imac /mnt/c/Users/MaZe/AppData/Local/Google/Chrome]$ find 2>/dev/null | grep iodiham | grep -i manifest

./User Data/Default/Extensions/iodihamcpbpeioajjeobimgagajmlibd/0.59_0/manifest.fingerprint

./User Data/Default/Extensions/iodihamcpbpeioajjeobimgagajmlibd/0.59_0/manifest.json

./User Data/Default/Extensions/iodihamcpbpeioajjeobimgagajmlibd/0.59_0/plugin/mosh/mosh_client_manifest_all_architectures.nmf

./User Data/Default/Extensions/iodihamcpbpeioajjeobimgagajmlibd/0.59_0/plugin/mosh/mosh_manifest.js

./User Data/Default/IndexedDB/chrome-extension_iodihamcpbpeioajjeobimgagajmlibd_0.indexeddb.leveldb/MANIFEST-000001

./User Data/Default/Local Extension Settings/iodihamcpbpeioajjeobimgagajmlibd/MANIFEST-000001

./User Data/Default/Sync Extension Settings/iodihamcpbpeioajjeobimgagajmlibd/MANIFEST-000001

 When I look at the above manifest.json it is valid json and does mention both 'terminalPrivate' and 'fileSystemProvider' - but I don't see any complaints about it.

Maybe because (your) local storage is broken it's falling back to fileSystemProvider (and then that isn't working because not chrome os) ?

I really have no idea how this (should) work(s)...  [note: I'm just another user]

Perhaps try shutting down chrome.  Going into your chrome profile directory and removing all the 'iodiham...' directories along with their content.

Then restart things?  [this assumes you don't have anything secure shell extension related you can't afford to lose...]

Or in chrome in the extension view (you pasted a screen shot up above) click on 'Site Settings' and then 'Reset Permissions' ???

This feels like somehow your Chrome has some setting set to block storage for the extension (or more globally)

[Maciej Żenczykowski]

One possibility is that 'localStorage' (likely meaning HTML5 LocalStorage) for the extension is disabled by some cookie setting 'Block sites from setting any data' (though that's info from 10+ years ago, so likely has long been renamed)

I think the extension is considered 'just another site' although with a weird url.

Also in chrome://flags check if you don't have something storage related disabled (search for storage).

For example I see "Storage Access API" & "Storage Buckets API" & "Storage Access API permission UI" Default.

Maciej Żenczykowski, Kernel Networking Developer @ Google

[Robert Raszuk]

The error/warning changed but the Secure Shell extension is still not working: 

developer.chrome.com/docs/extensions/reference/fileSystemProvider/

"Important: This API works only on ChromeOS"

So why is it showing up on windows?

Where are you seeing these errors?

I see those when I enable Secure Shell extension to report errors on chrome extension under win11. 

When I look at files this extension places in C:\Users\rober\AppData\Local\Google\Chrome\User Data\Profile 1\Local Extension Settings\iodihamcpbpeioajjeobimgagajmlibd

Curious I don't see that at all... closest I found is under

C:\Users\MaZe\AppData\Local\Google\Chrome\User Data\Default\ 

(maybe because I both have multiple profiles setup, and sync?)

I also have multiple profiles setup and sync ... 

 

 MANIFEST-00001 file looks like this: 

957c b9c5 2200 0101 1a6c 6576 656c 6462

2e42 7974 6577 6973 6543 6f6d 7061 7261
746f 7202 0003 0204 00

I do see a file like that (at a diff location) - the above includes ascii 'leveldb.BytewiseComparator' and seems irrelevant...

ok. 

 

I see a (much larger) manifest.json in a different directory.

[maze@imac /mnt/c/Users/MaZe/AppData/Local/Google/Chrome]$ find 2>/dev/null | grep iodiham | grep -i manifest

./User Data/Default/Extensions/iodihamcpbpeioajjeobimgagajmlibd/0.59_0/manifest.fingerprint

./User Data/Default/Extensions/iodihamcpbpeioajjeobimgagajmlibd/0.59_0/manifest.json

./User Data/Default/Extensions/iodihamcpbpeioajjeobimgagajmlibd/0.59_0/plugin/mosh/mosh_client_manifest_all_architectures.nmf

./User Data/Default/Extensions/iodihamcpbpeioajjeobimgagajmlibd/0.59_0/plugin/mosh/mosh_manifest.js

./User Data/Default/IndexedDB/chrome-extension_iodihamcpbpeioajjeobimgagajmlibd_0.indexeddb.leveldb/MANIFEST-000001

./User Data/Default/Local Extension Settings/iodihamcpbpeioajjeobimgagajmlibd/MANIFEST-000001

./User Data/Default/Sync Extension Settings/iodihamcpbpeioajjeobimgagajmlibd/MANIFEST-000001

 When I look at the above manifest.json it is valid json and does mention both 'terminalPrivate' and 'fileSystemProvider' - but I don't see any complaints about it.

Well under C:\Users\rober\AppData\Local\Google\Chrome\User Data\ 

in windows 11 there is no more Default folder at all. 

I see folder: 

C:\Users\rober\AppData\Local\Google\Chrome\User Data\Profile 1\Extensions but there is no "iodihamcpbpeioajjeobimgagajmlibd" there at all. 

Maybe because (your) local storage is broken it's falling back to fileSystemProvider (and then that isn't working because not chrome os) ?

Could be, but I would presume extension would self create such folders ....

 

I really have no idea how this (should) work(s)...  [note: I'm just another user]

Perhaps try shutting down chrome.  Going into your chrome profile directory and removing all the 'iodiham...' directories along with their content.

Then restart things?  [this assumes you don't have anything secure shell extension related you can't afford to lose...]

True ... tired that too. Few times .. no luck. 

Or in chrome in the extension view (you pasted a screen shot up above) click on 'Site Settings' and then 'Reset Permissions' ???

Did that too .... no difference. 

Many thx for your huge help ! 

Robert

[Robert Raszuk]

Ok so after I enabled almost all storage settings from Default to Enabled under chrome://flags/ suddenly I see a Secure Shell folder under: 

C:\Users\rober\AppData\Local\Google\Chrome\User Data\Profile 1\Extensions

But Secure Shell still is not working ... it now shows different error when debugging more: 

+

webapp_manifest.json file not found ! 

+ 

I am not sure what is normal warning and what is the real issue here :( 

Thx,

R.

[Maciej Żenczykowski]

In a profile where I've never used secure shell (AFAICR) I installed
it from the chrome web store.
In developer view I do see

"Failed to request persistent storage"

and
"requestFileSystem API does not exist"
and
"Ignoring IP_TOS=72"

(and the form field element... too)

but ssh works...

On Thu, Nov 2, 2023 at 6:22 PM Robert Raszuk <rra...@gmail.com> wrote:
>
>
> Ok so after I enabled almost all storage settings from Default to Enabled under chrome://flags/ suddenly I see a Secure Shell folder under:
>
> C:\Users\rober\AppData\Local\Google\Chrome\User Data\Profile 1\Extensions
>
> But Secure Shell still is not working ... it now shows different error when debugging more:
>
>
>

> +
>
> webapp_manifest.json file not found !
>
> +
>
>
>

> I am not sure what is normal warning and what is the real issue here :(
>
> Thx,
> R.
>
>
>
>
>
>
>
> On Fri, 3 Nov 2023 at 01:59, Robert Raszuk <rra...@gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> The error/warning changed but the Secure Shell extension is still not working:
>>>>>>>
>>>>>>>
>>>

> --
> 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/CA%2Bb%2BERmMZB5va6PpAYVpseFvDkRknn_KG3i-LH3edRXtqZgkLg%40mail.gmail.com.Maciej Żenczykowski, Kernel Networking Developer @ Google

[Maciej Żenczykowski]

and I've had that 'GET chrome-extension://iodi.../webapp_manifest.json
net::ERR_FILE_NOT_FOUND' pop up now too.

> > To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/CA%2Bb%2BERmMZB5va6PpAYVpseFvDkRknn_KG3i-LH3edRXtqZgkLg%40mail.gmail.com.Maciej Żenczykowski, Kernel Networking Developer @ GoogleMaciej Żenczykowski, Kernel Networking Developer @ Google

[Maciej Żenczykowski]

When you say it's still not working, how is it failing? Does it hang?
Is there an error message? Is there a final line it printed?

> > > To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/CA%2Bb%2BERmMZB5va6PpAYVpseFvDkRknn_KG3i-LH3edRXtqZgkLg%40mail.gmail.com.Maciej Żenczykowski, Kernel Networking Developer @ GoogleMaciej Żenczykowski, Kernel Networking Developer @ GoogleMaciej Żenczykowski, Kernel Networking Developer @ Google

[Robert Raszuk]

When I click the link URL: ssh://arr...@172.28.176.3 it pops new TAB and simply hangs after "Connecting to ...." here: 

Of course connecting from WLS2 to the very same node works fine. 

What I am also quite puzzled about is that the extension ssh files show completely empty and Secure Shell never ask to add a new host to it: 

While in my "C:\Users\rober\.ssh\known_hosts" I do have bunch of stuff, but this is apparently not the one Secure Shell is using. 

That could be the problem perhaps ?

On the other hand folder C:\Users\rober\AppData\Local\Google\Chrome\User Data\Profile 1\ does not contain even .ssh folder so I do not have any idea where the Secure Shell extension is trying to look for ~/.ssh/known_hosts or ~/.ssh/config in Win 11 running chrome with multiple profiles. 

When I search for known_hosts in my local drive I see some known_hosts related to teraterm but nothing about SecureShell extension. 

Many thx,

Robert

[Robert Raszuk]

Hmmm going along this new path when I tried to add new host to known_host in this Secure Shell window I get an interesting new error: 

So where the heck is "root" in windows 11 world ? 

Thx,

R.

[Robert Raszuk]

I cleaned up all Secure Shell extensions in all profiles and started clean. 

Secure Shell is still not working It seems that previous path is confirmed ... it files at requesting File System API access: 

/**
 * Request the persistent HTML5 filesystem for this extension.
 *
 * This will also create the /.ssh/ directory if it does not exist.
 *
 * @return {!Promise<!FileSystem|undefined>} The root filesystem handle.
 */
export async function getDomFileSystem() {
  const requestFS =
      globalThis.requestFileSystem || globalThis.webkitRequestFileSystem;
  const size = 16 * 1024 * 1024;

  if (!requestFS) {
    console.warn('requestFileSystem API does not exist');   <<<<<<<<<<<<<<<<<<<<<<<<<<<<<  line 30 
    return Promise.resolve(undefined);
  }

@ nsssh_fs.js 

Any idea how can I enable HTML5 persistent filesystem API for Secure Shell ? 

Many thx,

Robert

[Maciej Żenczykowski]

If it's getting to 'connecting' then I think the problem is elsewhere...

This is the point at which I'd start running tcpdump... to see if packets are being sent... received...

and/or add -vvv to ssh arguments to get more verbosity...

[Jon]

This is what I get with -vvv

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
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/.ssh/known_hosts2'
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug2: resolving "server" port 2323
debug3: resolve_host: lookup server:2323
debug3: ssh_connect_direct: entering
debug1: Connecting to server [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

It gets to "connection established" then hangs

[Jon]

I just tried with a fresh Chrome profile and got the following instead:

Loading wasm program… «««This is in alpha -- see https://crbug.com/1312115 for KIs»»» done.

Connecting to root@fs…

OpenSSH_8.8p1, OpenSSL 1.0.2k  26 Jan 2017
debug1: Reading configuration data //etc/ssh_config
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/.ssh/known_hosts2'
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling

debug2: resolving "fs" port 2323
debug3: resolve_host: lookup fs:2323
debug3: ssh_connect_direct: entering
debug1: Connecting to fs [100::] port 2323.
debug1: Connection established.
debug1: identity file /.ssh/id_rsa type -1
debug1: identity file /.ssh/id_rsa-cert type -1
debug1: identity file /.ssh/id_dsa type -1
debug1: identity file /.ssh/id_dsa-cert type -1
debug1: identity file /.ssh/id_ecdsa type -1
debug1: identity file /.ssh/id_ecdsa-cert type -1
debug1: identity file /.ssh/id_ecdsa_sk type -1
debug1: identity file /.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /.ssh/id_ed25519 type -1
debug1: identity file /.ssh/id_ed25519-cert type -1
debug1: identity file /.ssh/id_ed25519_sk type -1
debug1: identity file /.ssh/id_ed25519_sk-cert type -1
debug1: identity file /.ssh/id_xmss type -1
debug1: identity file /.ssh/id_xmss-cert type -1

debug1: Local version string SSH-2.0-OpenSSH_8.8

Note it's doing more with ssh identify files.

It's also still finding "~/.ssh/known_hosts" even though I have no idea where this actually is on my computer.

On my server logs it sees the connection attempt:  Nov 16 10:27:22 server sshd[21461]: Connection from 192.168.0.201 port 14229 on 192.168.0.250 port 2323 rdomain ""

[Maciej Żenczykowski]

I think this is the spot where it is waiting on a banner from the server.

Try running tcpdump and see if the server received the banner from the client and sent a banner back...

[Jon]

Thanks. This is what I get from tcpdump:

root@server tcpdump -i 2 port 2323
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes
11:23:54.632048 IP 192.168.0.21.1918 > server.local.2323: Flags [F.], seq 100062940, ack 579616543, win 1022, length 0
11:23:54.633264 IP server.local.2323 > 192.168.0.21.1918: Flags [F.], seq 1, ack 1, win 83, length 0
11:23:54.637638 IP 192.168.0.21.1918 > server.local.2323: Flags [.], ack 2, win 1022, length 0
11:23:54.905046 IP 192.168.0.21.1943 > server.local.2323: Flags [S], seq 2942140994, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
11:23:54.905118 IP server.local.2323 > 192.168.0.21.1943: Flags [S.], seq 2597682384, ack 2942140995, win 42340, options [mss 1460,nop,nop,sackOK,nop,wscale 9], length 0
11:23:54.910187 IP 192.168.0.21.1943 > server.local.2323: Flags [.], ack 1, win 1026, length 0
11:23:54.919004 IP server.local.2323 > 192.168.0.21.1943: Flags [P.], seq 1:22, ack 1, win 83, length 21
11:23:54.938647 IP 192.168.0.21.1943 > server.local.2323: Flags [P.], seq 1:22, ack 22, win 1026, length 21
11:23:54.938714 IP server.local.2323 > 192.168.0.21.1943: Flags [.], ack 22, win 83, length 0
11:23:54.940475 IP server.local.2323 > 192.168.0.21.1943: Flags [P.], seq 22:1078, ack 22, win 83, length 1056
11:23:54.990652 IP 192.168.0.21.1943 > server.local.2323: Flags [.], ack 1078, win 1022, length 0

[Maciej Żenczykowski]

Could you try that again with more verbosity so we can see the SSH header?

I think that's "-s 1500" and either "-X" or "-A" (not sure which).

It does look like the server is sending 1056 bytes (but what's in them)...

What sort of an ssh server is this (OS + sshd version).

Do you have other ssh servers that it works with?  Or do you only use this one?

[Jon]

Thanks for the reply. My responses inline below:

On Thursday, 16 November 2023 at 11:31:00 UTC Maciej Żenczykowski wrote:

Could you try that again with more verbosity so we can see the SSH header?

I think that's "-s 1500" and either "-X" or "-A" (not sure which).

-X for hex -A for ASCII

 

It does look like the server is sending 1056 bytes (but what's in them)...

root@server tcpdump -i 2 port 2323 -s 1500 -A

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 1500 bytes
11:49:13.887057 IP 192.168.0.21.2385 > server.local.2323: Flags [F.], seq 1592654982, ack 506618644, win 1022, length 0
E..(.I@...Z'........    Q       .^....2c.P...:W........
11:49:13.887097 IP server.local.2323 > 192.168.0.21.2385: Flags [.], ack 1, win 83, length 0
E..(..@.@..p........    .       Q.2c.^...P..S>...
11:49:14.145537 IP 192.168.0.21.2449 > server.local.2323: Flags [S], seq 4015891855, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
E..4.J@...Z.........    .       ..]..........J...............
11:49:14.145620 IP server.local.2323 > 192.168.0.21.2449: Flags [S.], seq 2293509640, ack 4015891856, win 42340, options [mss 1460,nop,nop,sackOK,nop,wscale 9], length 0
E..4..@.@..d........    .       ......].....d...............
11:49:14.154099 IP 192.168.0.21.2449 > server.local.2323: Flags [.], ack 1, win 1026, length 0
E..(.K@...[%........    .       ..].....        P...."........
11:49:14.162641 IP server.local.2323 > 192.168.0.21.2449: Flags [P.], seq 1:22, ack 1, win 83, length 21
E..=.   @.@..R........  .       ....    .]..P..S....SSH-2.0-OpenSSH_8.4

11:49:14.184756 IP 192.168.0.21.2449 > server.local.2323: Flags [P.], seq 1:22, ack 22, win 1026, length 21
E..=.L@...[.........    .       ..]......P....H..SSH-2.0-OpenSSH_8.8

11:49:14.184782 IP server.local.2323 > 192.168.0.21.2449: Flags [.], ack 22, win 83, length 0
E..(.
@.@..f........  .       ......]..P..S.z..
11:49:14.185951 IP server.local.2323 > 192.168.0.21.2449: Flags [P.], seq 22:1078, ack 22, win 83, length 1056
E..H..@.@..E........    .       ......]..P..S........
..$.%L=As...\J.0.....curve25519-sha256,curve255...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256...Arsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519...lchacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes12...@openssh.com,aes25...@openssh.com...lchacha20...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes12...@openssh.com,aes25...@openssh.com....umac-...@openssh.com,umac-1...@openssh.com,hmac-sha...@openssh.com,hmac-sha...@openssh.com,hmac-s...@openssh.com,uma...@openssh.com,umac...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1....umac-64-etm@openssh.com,umac-1...@openssh.com,hmac-sha...@openssh.com,hmac-sha...@openssh.com,hmac-s...@openssh.com,uma...@openssh.com,umac...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1....none,zl...@openssh.com....none,zl...@openssh.com.......................
11:49:14.244566 IP 192.168.0.21.2449 > server.local.2323: Flags [.], ack 1078, win 1022, length 0
E..(.M@...[#........    .       ..]....2>P.............

 

What sort of an ssh server is this (OS + sshd version).

unRAID 6.9.2

OpenSSH_8.4p1, OpenSSL 1.1.1j  16 Feb 2021

 

Do you have other ssh servers that it works with?  Or do you only use this one?

Good idea, let me check

[Jon]

Same issue with other ssh servers:

Loading wasm program… «««This is in alpha -- see https://crbug.com/1312115 for KIs»»» done.

Connecting to us...@ssh.nyc1.nearlyfreespeech.net…

OpenSSH_8.8p1, OpenSSL 1.0.2k  26 Jan 2017
debug1: Reading configuration data //etc/ssh_config
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/.ssh/known_hosts2'
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling

debug2: resolving "ssh.nyc1.nearlyfreespeech.net" port 22
debug3: resolve_host: lookup ssh.nyc1.nearlyfreespeech.net:22
debug3: ssh_connect_direct: entering
debug1: Connecting to ssh.nyc1.nearlyfreespeech.net [100::] port 22.

debug1: Connection established.
debug1: identity file /.ssh/id_rsa type -1
debug1: identity file /.ssh/id_rsa-cert type -1
debug1: identity file /.ssh/id_dsa type -1
debug1: identity file /.ssh/id_dsa-cert type -1
debug1: identity file /.ssh/id_ecdsa type -1
debug1: identity file /.ssh/id_ecdsa-cert type -1
debug1: identity file /.ssh/id_ecdsa_sk type -1
debug1: identity file /.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /.ssh/id_ed25519 type -1
debug1: identity file /.ssh/id_ed25519-cert type -1
debug1: identity file /.ssh/id_ed25519_sk type -1
debug1: identity file /.ssh/id_ed25519_sk-cert type -1
debug1: identity file /.ssh/id_xmss type -1
debug1: identity file /.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.8

On Thursday, 16 November 2023 at 11:31:00 UTC Maciej Żenczykowski wrote:

[Maciej Żenczykowski]

So I have no idea what is wrong...

For me the next line after:

  debug1: Local version string SSH-2.0-OpenSSH_8.8

is

  debug1: Remote protocol version 2.0, remote software version OpenSSH_9.3

However, I do see that Linux/Chrome/SecureShell v60 WASM also reports "100::" as the resolved IP, buth then it does work.

I'm guessing this 100:: / 1.0.0.0 is some WASM placeholder IP (ie. when you do a dns lookup for the first time you get back 1, then when you connect to 1 you connect to whatever you actually looked up)...

Anyway, the point is that the 100:: / 1.0.0.0 appears to be ok...

(Maybe the bad address stuff is actually because it doesn't go via this path???)

[Mike Frysinger]

the bad address error is unrelated.  it should be fixed by next week.

https://issuetracker.google.com/311233544

the 100:: stuff are placeholders covered in the wassh documents:

https://chromium.googlesource.com/apps/libapps/+/HEAD/wassh/docs/sockets.md#dns-support

it sounds like Win11 specifically has issues.  i only have access to Win10 systems atm and they're working fine.

https://issuetracker.google.com/303565674

i have some ideas, but it's hard to test/check when my systems are passing.  kind of seems like the TCP recv isn't firing which means the client is never notified that new data has arrived.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/CANP3RGeLkPLVoTBCTP%3DjwaeVyxozMFcQLu4tdTw9qL1gfkukkA%40mail.gmail.com.

[Jon]

This is on Windows 10 not Windows 11.

The weird thing is that it worked perfectly fine in September and had done for years previously. When the extension got updated it suddenly wouldn't connect to any ssh server at all.

[Robert Raszuk]

> When the extension got updated

WFIW for me on Win 11 it stopped working the moment I upgraded Chrome browser with security fixes few weeks back. 

Thx.

R.

[Jon]

I'm afraid that despite searching I can't work out what "WFIW" means...

[Robert Raszuk]

Sorry s/WFIW/FWIW/ 

[Robert Raszuk]

Dear Team,

Thank you again for fixing the IP address issue in 0.61. But it looks like this was only part of my problem with the Secure Shell Chrome extension. 

So my peers are far away and running SSH-2.0 OpenSSH_7.9p1 Debian-10+deb10u2

Secure Shell seems to be using OpenSSH_8.8

What I am observing is that Secure Shell side is too quickly resetting the connection attempt before the other side responds. Basically local SSH is sending TCP RST and game's over before the other side responds. 

Is there any way to delay local client to wait a bit longer for the remote side in Secure Shell ? 

Thank You !

Robert

[Maciej Żenczykowski]

What OS is your client? Is it Linux?
Have you manually tweaked/changed the TCP Keepalive settings?
Linux has some sysctls for this (tcp_keepalive_time
tcp_keepalive_intvl tcp_keepalive_probes ifirc)
Those 3 tcp keep alive packets immediately after the 3 way handshake
are a bit unusual... that's *super* early.
Usually keepalive are only sent after a connection has been idle for a bit...
Indeed those are being sent even before the SSH banner, which is a bit
of a WTF...

From the SYN-SYNACK it's clear the RTT is around 180ms but the
retransmits are every ~15ms.

This is breakage at the client OS TCP stack level... it's like it's
miss-detecting RTT or something...

See also ssh keep alive (incl. tcp keep alive) configuration options:

https://unix.stackexchange.com/questions/568872/openssh-what-is-the-interval-for-tcpkeepalive-option
Maybe you need '-o TCPKeepAlive=no'

On Wed, Nov 22, 2023 at 6:21 AM Robert Raszuk <rra...@gmail.com> wrote:
>
> Dear Team,
>
> Thank you again for fixing the IP address issue in 0.61. But it looks like this was only part of my problem with the Secure Shell Chrome extension.
>
> So my peers are far away and running SSH-2.0 OpenSSH_7.9p1 Debian-10+deb10u2
>
> Secure Shell seems to be using OpenSSH_8.8
>
> What I am observing is that Secure Shell side is too quickly resetting the connection attempt before the other side responds. Basically local SSH is sending TCP RST and game's over before the other side responds.
>
>
>

> Is there any way to delay local client to wait a bit longer for the remote side in Secure Shell ?
>
> Thank You !
> Robert
>

[Robert Raszuk]

Hi,

Indeed this seems to be a TCP issue. I am using vanilla windows 11 with all the latest updates. 

Tested putting TCPKeepAlive no into ssh/conf via Secure Shell client ssh configuration and it seems to be working fine now. 

Will monitor it for a while ...

Kind regards,

Robert Raszuk

[Maciej Żenczykowski]

Hmm the secure shell implementation seems to be just:

wassh/js/sockets.js-788- case SO_KEEPALIVE:
wassh/js/sockets.js:789: return {option: this.tcpKeepAlive_ ? 1 : 0};
...
wassh/js/sockets.js-807- async setSocketOption(level, name, value) {
wassh/js/sockets.js-808- switch (level) {
wassh/js/sockets.js-809- case SOL_SOCKET: {
wassh/js/sockets.js-810- switch (name) {
wassh/js/sockets.js-811- case SO_KEEPALIVE: {
wassh/js/sockets.js:812: this.tcpKeepAlive_ = value;
wassh/js/sockets.js-813- return WASI.errno.ESUCCESS;
wassh/js/sockets.js-814- }
...
wassh/js/sockets.js-909- // Keep alive is disabled by default, so
don't specify it if it's disabled.
wassh/js/sockets.js-910- if (this.tcpKeepAlive_) {
wassh/js/sockets.js-911- // Default to 75 seconds to match
default Linux TCP_KEEPINTVL.
wassh/js/sockets.js:912: options.keepAliveDelay = 75000;
wassh/js/sockets.js-913- }

so assuming keepAliveDelay is indeed measured in ms (
https://wicg.github.io/direct-sockets/#dom-tcpsocketoptions-keepalivedelay
doesn't quite seem to specify this, though 1000 is minimum acceptable
value so it seems likely)... this should work, and thus points to a
bug either in chrome or windows itself.

>> Maciej Żenczykowski, Kernel Networking Developer @ GoogleMaciej Żenczykowski, Kernel Networking Developer @ Google

[Robert Raszuk]

Just to follow up ... 

After adding:

 

I can connect every time to all of my remote nodes. 

Thank you all,

R.

PS. Apologies if this has been already discussed in the past but is there any way to get chromaterm https://github.com/tunnelsup/chromaterm integrated with Secure Shell ? 

[Robert Raszuk]

Sorry old link got pasted :( 

New one is: https://github.com/hSaria/ChromaTerm

[Mike Frysinger]

careful here ... the code you're quoting is from diff backends.  we provide TCP sockets to the WASM side via 3 backends currently:

* ChromeTcpSocket: Chrome sockets (the newer Chrome Apps APIs)

* RelaySocket: WebSockets using our various relay servers

* WebTcpSocket: the newer direct sockets APIs that Chrome is trying to make into a W3C standard

you quoted code from the latter two, but those wouldn't matter to non-Googlers on Windows.  direct sockets aren't available to the extension atm.

that leaves Chrome sockets. we're using the chrome.sockets.tcp.setKeepAlive function:

              chrome.sockets.tcp.setKeepAlive(this.socketId_, !!value, resolve);

https://developer.chrome.com/docs/extensions/reference/sockets_tcp/#method-setKeepAlive

basically we're just turning it on ... we aren't specifying a value.  the Chrome API says the default is 0.  which is what we're using by virtue of not specifying anything.

the Chrome code is a bit interesting:

https://source.chromium.org/chromium/chromium/src/+/main:net/socket/tcp_socket_posix.cc;drc=d4a7d3fb6f5100019d6153d5cf00c60f06b1d0a2;bpv=1;bpt=1;l=68

https://source.chromium.org/chromium/chromium/src/+/main:net/socket/tcp_socket_win.cc;l=672;drc=d4a7d3fb6f5100019d6153d5cf00c60f06b1d0a2;bpv=1;bpt=1

POSIX turns keep alive on via SOL_SOCKET+SO_KEEPALIVE, and you set the delay via SOL_TCP+TCP_KEEPxxx.  the Chrome POSIX backend always turns it on, but doesn't set TCP if delay is 0.

Windows on the otherhand has a single SIO_KEEPALIVE_VALS call which turns on & sets TCP.  so it would pass delay=0 down to the OS.  i'm guessing Windows 10 and older didn't care, or is handling it better, while Windows 11 is performing differently.

so if this is the case, the fix should be fairly easy -- plumb a default through like direct sockets.  i'll put that together.

-mike

[Mike Frysinger]

posted https://crrev.com/c/5056706 to set the default to 75 seconds for everyone

it's kind of annoying that the sockets APIs conflate the idle period with the intervals, but so it goes.

-mike

[Maciej Żenczykowski]

On Wed, Nov 22, 2023 at 9:08 PM Mike Frysinger <vap...@chromium.org> wrote:
>
> posted https://crrev.com/c/5056706 to set the default to 75 seconds for everyone
>
> it's kind of annoying that the sockets APIs conflate the idle period with the intervals, but so it goes.
> -mike

Yeah, noticed that too... and there's no ability to configure the keep
count either.

Normally you'd want the idle time to be high (ie. 300-3600 seconds, to
be slightly less than standard firewall established tcp connection
timeouts) but the repeat interval significantly shorter (i.e. 1-10
seconds) and the repeat count somewhere around 3-15.

Thanks for fixing this, I was finding the code base quite confusing,
but I thought I had it worked out... live and learn.

I guess we'll need to wait for an 0.62 to see if this fixes the issue
for Robert.
And if it works, I'll have to follow up on my email to MS...

[Jon]

To answer my own question, the only way I have found to fix this extension is to remove it and manually install an old version.

Suddenly everything works perfectly for all ssh servers as it did before for years.

Here's a working version for all those who had this suddenly break.

[Maciej Żenczykowski]

On Wed, Nov 22, 2023 at 11:20 PM Maciej Żenczykowski <ma...@google.com> wrote:
>
> On Wed, Nov 22, 2023 at 9:08 PM Mike Frysinger <vap...@chromium.org> wrote:
> >
> > posted https://crrev.com/c/5056706 to set the default to 75 seconds for everyone
> >
> > it's kind of annoying that the sockets APIs conflate the idle period with the intervals, but so it goes.
> > -mike
>
> Yeah, noticed that too... and there's no ability to configure the keep
> count either.
>
> Normally you'd want the idle time to be high (ie. 300-3600 seconds, to
> be slightly less than standard firewall established tcp connection
> timeouts) but the repeat interval significantly shorter (i.e. 1-10
> seconds) and the repeat count somewhere around 3-15.
>
> Thanks for fixing this, I was finding the code base quite confusing,
> but I thought I had it worked out... live and learn.
>
> I guess we'll need to wait for an 0.62 to see if this fixes the issue
> for Robert.
> And if it works, I'll have to follow up on my email to MS...

Robert, 0.62 is out now. Could you confirm you no longer need the
manual keepalive setting (ie. that things are fixed).
I'd like to get back to MS on this.

> >>> >> > RobertMaciej Żenczykowski, Kernel Networking Developer @ Google

[Robert Raszuk]

Hi,

Yes I upgraded and removed the manual setting to disable TCP keepalives. 

It works now ! (So far :)

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/CANP3RGfCpVw7gHkRZUh_XzBFmd%2B9U30YxYah4oHR2adepSMBCg%40mail.gmail.com.

[Maciej Żenczykowski]

On Mon, Dec 4, 2023 at 2:51 PM Robert Raszuk <rra...@gmail.com> wrote:
>
> Hi,
>

> Yes I upgraded and removed the manual setting to disable TCP keepalives.
>
> It works now ! (So far :)
>
> Many thx,
> Robert

Ok, thanks for confirming!


And Jon, if you read this... try 0.62, if you still see issues, well
you're free to keep using the old version of the extension, but be
aware that the entire reason we're switching to wasm is that chrome is
dropping pnacl support, so at some point it'll presumably stop
working... anyway, this means it would be worth figuring out what is
going wrong... but that may require tcpdumps (packet captures), etc...

[Jon]

Maciej,

Thanks for mentioning me. I can confirm that 0.62 doesn't work with exactly the same error we've all been getting.

Also, some people have mentioned that the other version of Secure Shell on the chrome webstore works - it doesn't and never has done with the issue I'm having.

I've already posted lots of tcpdumps in another thread but if anyone is willing to work with me to troubleshoot this I can certainly post more.

[Maciej Żenczykowski]

On Mon, Dec 4, 2023 at 3:41 PM Jon <turke...@gmail.com> wrote:
>
> Maciej,
>
> Thanks for mentioning me. I can confirm that 0.62 doesn't work with exactly the same error we've all been getting.
>
> Also, some people have mentioned that the other version of Secure Shell on the chrome webstore works - it doesn't and never has done with the issue I'm having.
>
> I've already posted lots of tcpdumps in another thread but if anyone is willing to work with me to troubleshoot this I can certainly post more.

Hmm, I've not seen any, any pointers (an archive, or maybe something
to search for, or a repost of what you've figure out...)

[Jon]

I think I replied directly to you on 16 Nov but the message has been deleted for some reason.

On Thursday, 16 November 2023 at 11:31:00 UTC Maciej Żenczykowski wrote:

Could you try that again with more verbosity so we can see the SSH header?

I think that's "-s 1500" and either "-X" or "-A" (not sure which).

-X for hex -A for ASCII

 

It does look like the server is sending 1056 bytes (but what's in them)...

root@server tcpdump -i 2 port 2323 -s 1500 -A

tcpdump: verbose output suppressed, use -v or -vv for full protocol decode

listening on eth0, link-type EN10MB (Ethernet), capture size 1500 bytes
11:49:13.887057 IP 192.168.0.21.2385 > server.local.2323: Flags [F.], seq 1592654982, ack 506618644, win 1022, length 0
E..(.I@...Z'........    Q       .^....2c.P...:W........
11:49:13.887097 IP server.local.2323 > 192.168.0.21.2385: Flags [.], ack 1, win 83, length 0
E..(..@.@..p........    .       Q.2c.^...P..S>...
11:49:14.145537 IP 192.168.0.21.2449 > server.local.2323: Flags [S], seq 4015891855, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
E..4.J@...Z.........    .       ..]..........J...............
11:49:14.145620 IP server.local.2323 > 192.168.0.21.2449: Flags [S.], seq 2293509640, ack 4015891856, win 42340, options [mss 1460,nop,nop,sackOK,nop,wscale 9], length 0
E..4..@.@..d........    .       ......].....d...............
11:49:14.154099 IP 192.168.0.21.2449 > server.local.2323: Flags [.], ack 1, win 1026, length 0
E..(.K@...[%........    .       ..].....        P...."........
11:49:14.162641 IP server.local.2323 > 192.168.0.21.2449: Flags [P.], seq 1:22, ack 1, win 83, length 21
E..=.   @.@..R........  .       ....    .]..P..S....SSH-2.0-OpenSSH_8.4

11:49:14.184756 IP 192.168.0.21.2449 > server.local.2323: Flags [P.], seq 1:22, ack 22, win 1026, length 21
E..=.L@...[.........    .       ..]......P....H..SSH-2.0-OpenSSH_8.8

11:49:14.184782 IP server.local.2323 > 192.168.0.21.2449: Flags [.], ack 22, win 83, length 0
E..(.
@.@..f........  .       ......]..P..S.z..
11:49:14.185951 IP server.local.2323 > 192.168.0.21.2449: Flags [P.], seq 22:1078, ack 22, win 83, length 1056
E..H..@.@..E........    .       ......]..P..S........
..$.%L=As...\J.0.....curve25519-sha256,curve255...@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256...Arsa-sha2-512,rsa-sha2-256,ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519...lchacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes12...@openssh.com,aes25...@openssh.com...lchacha20...@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes12...@openssh.com,aes25...@openssh.com....umac-...@openssh.com,umac-1...@openssh.com,hmac-sha...@openssh.com,hmac-sha...@openssh.com,hmac-s...@openssh.com,uma...@openssh.com,umac...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1....umac-64-etm@openssh.com,umac-1...@openssh.com,hmac-sha...@openssh.com,hmac-sha...@openssh.com,hmac-s...@openssh.com,uma...@openssh.com,umac...@openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1....none,zl...@openssh.com....none,zl...@openssh.com.......................
11:49:14.244566 IP 192.168.0.21.2449 > server.local.2323: Flags [.], ack 1078, win 1022, length 0
E..(.M@...[#........    .       ..]....2>P.............

 

What sort of an ssh server is this (OS + sshd version).

unRAID 6.9.2

OpenSSH_8.4p1, OpenSSL 1.1.1j  16 Feb 2021

 

Do you have other ssh servers that it works with?  Or do you only use this one?

Same issue with other ssh servers:

[Maciej Żenczykowski]

There's nothing immediately wrong from the above... It looks like
everything is ok.
Certainly the tcp connection looks healthy...
I think you'd need to look at -vvv logs on the client to perhaps
hopefully see why it doesn't respond...
what does it think it is doing...

> What sort of an ssh server is this (OS + sshd version).
>
> unRAID 6.9.2
> OpenSSH_8.4p1, OpenSSL 1.1.1j 16 Feb 2021
>
>
> Do you have other ssh servers that it works with? Or do you only use this one?
>
>
> Same issue with other ssh servers:
>
> On Tuesday 5 December 2023 at 01:14:13 UTC Maciej Żenczykowski wrote:
>>
>> On Mon, Dec 4, 2023 at 3:41 PM Jon <turke...@gmail.com> wrote:
>> >
>> > Maciej,
>> >
>> > Thanks for mentioning me. I can confirm that 0.62 doesn't work with exactly the same error we've all been getting.
>> >
>> > Also, some people have mentioned that the other version of Secure Shell on the chrome webstore works - it doesn't and never has done with the issue I'm having.
>> >
>> > I've already posted lots of tcpdumps in another thread but if anyone is willing to work with me to troubleshoot this I can certainly post more.
>>
>> Hmm, I've not seen any, any pointers (an archive, or maybe something

>> to search for, or a repost of what you've figure out...)Maciej Żenczykowski, Kernel Networking Developer @ Google

[Jon]

I already posted -vvv logs too:

Loading wasm program… «««This is in alpha -- see https://crbug.com/1312115 for KIs»»» done.

Connecting to user@server…

OpenSSH_8.8p1, OpenSSL 1.0.2k  26 Jan 2017
debug1: Reading configuration data //etc/ssh_config
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/.ssh/known_hosts'
debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/.ssh/known_hosts2'
debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling
debug2: resolving "server" port 2323
debug3: resolve_host: lookup server:2323
debug3: ssh_connect_direct: entering
debug1: Connecting to server [100::] port 2323.
debug1: Connection established.

debug1: identity file /.ssh/id_rsa type -1
debug1: identity file /.ssh/id_rsa-cert type -1
debug1: identity file /.ssh/id_dsa type -1
debug1: identity file /.ssh/id_dsa-cert type -1
debug1: identity file /.ssh/id_ecdsa type -1
debug1: identity file /.ssh/id_ecdsa-cert type -1
debug1: identity file /.ssh/id_ecdsa_sk type -1
debug1: identity file /.ssh/id_ecdsa_sk-cert type -1
debug1: identity file /.ssh/id_ed25519 type -1
debug1: identity file /.ssh/id_ed25519-cert type -1
debug1: identity file /.ssh/id_ed25519_sk type -1
debug1: identity file /.ssh/id_ed25519_sk-cert type -1
debug1: identity file /.ssh/id_xmss type -1
debug1: identity file /.ssh/id_xmss-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.8

and here it just hangs and never gets any further

[Maciej Żenczykowski]

I'm at a total loss... so this looks like it never seems to receive
the banner, but clearly tcpdump shows it...
That suggests that read on the socket is blocked or poll is faling to
trigger in spite of available data... which is super weird...

Is this server available somewhere on a public dns/ip/port that I
could poke at it?
(I don't need login credentials, since it's failing long before auth...)

I guess I actually now actually have a throwaway disk (due to a
machine motherboard failure) I could try upgrading to Win11...

>> >> to search for, or a repost of what you've figure out...)Maciej Żenczykowski, Kernel Networking Developer @ GoogleMaciej Żenczykowski, Kernel Networking Developer @ Google

[Jon]

I've said that I'm just using Windows 10. This is not a
Windows 11 issue.

I'll privately email you another server that doesn't work. But ALL ssh
servers I've tried fail in the same fashion since the update.

[Robert Raszuk]

I'm at a total loss... so this looks like it never seems to receive
the banner, but clearly tcpdump shows it...
That suggests that read on the socket is blocked or poll is faling to
trigger in spite of available data... which is super weird...

Recall that I was seeing the same ... The remote side responded in TCP when local client already decided to close the connection. 

But in my case disabling TCP Keepalives was the fix. 

Cheers,

R.

 

[Jon]

Hi Robert,

What ssh arguments should I use to try this?

[Robert Raszuk]

Well 0.62 has added this support by default so no more . 

I simply used before 0.62 was out this:

TCPKeepAlive

no in

here:

Thx,

R.

[Jon]

Thank you for trying. Just installed 0.62 again and used that setting.

Still exactly the same error.

I and dozens of others had this working perfectly but not getting this bug which breaks the entire extension :(

[Maciej Żenczykowski]

On Tue, Dec 5, 2023 at 6:31 PM Jon <turke...@gmail.com> wrote:

Thank you for trying. Just installed 0.62 again and used that setting.

Still exactly the same error.

I and dozens of others had this working perfectly but not getting this bug which breaks the entire extension :(

So, bad news... Windows 10 + chrome + secure shell 0.62 works for me when connecting to the server you sent me.

(I can't of course actually log in but I get past the banner to where it asks me for a password)

However, I do have an idea.  Try -6 and -4 flags to ssh (SSH Arguments field).

Things default to ipv6, perhaps your ipv6 is bad...

Also, something I can't confirm easily, but something that comes to mind is that perhaps your problems are mtu related...

[Jon]

Exact same issue with either -4 or -6.

Tried with both MTU of 1500 and 9000 and same issue too.

Tried multiple ethernet interfaces as well

Something in the extension has changed between 0.53 and 0.62 to break this for me and many other people.

[Maciej Żenczykowski]

On Fri, Dec 8, 2023 at 4:35 PM Jon <turke...@gmail.com> wrote:
>
> Exact same issue with either -4 or -6.

I assume you've verified that the connection establishes, and the
banners are exchanged and yet it gets stuck?

> Tried with both MTU of 1500 and 9000 and same issue too.

Try lower mtu than 1500, rather than higher: 1492, 1480, 1460, 1440,
1400, 1340, 1280.
(though yes, I am grasping at straws)

You could also try changing qos: -o IPQoS=... I've seen that be an
issue in the past.
Though again, this is unlikely to be the issue after connection establishment...

> Tried multiple ethernet interfaces as well
>
> Something in the extension has changed between 0.53 and 0.62 to break this for me and many other people.

Perhaps? But as I said... it works for me on Win 10
Pro/Chrome/SecureShell 0.62, to the server you provided...
so that heavily (though not definitely) implies it's something
specific to your network connection...
(clearly it's not that rare, since more than just you are affected)

I'm guessing you're running tcpdump on the server side?
Try running wireshark on the local windows side too.
See if there's some packet one side is sending that the other side is
not receiving...

As a desperate last measure you could also try building various
versions of the extension between 0.53 and 0.62 and trying to track
down the specific change that broke things (though I'm worried it'll
just be a generic switch over from pnacl to wasm cl...)

Perhaps try that same machine from a different network, or a different
machine...

I'm running out of ideas...
It's really pretty much impossible to debug failures we can't reproduce...

> On Thursday 7 December 2023 at 21:20:03 UTC Maciej Żenczykowski wrote:
>>
>> On Tue, Dec 5, 2023 at 6:31 PM Jon <turke...@gmail.com> wrote:
>>>
>>> Thank you for trying. Just installed 0.62 again and used that setting.
>>>
>>> Still exactly the same error.
>>>
>>> I and dozens of others had this working perfectly but not getting this bug which breaks the entire extension :(
>>
>>
>> So, bad news... Windows 10 + chrome + secure shell 0.62 works for me when connecting to the server you sent me.
>> (I can't of course actually log in but I get past the banner to where it asks me for a password)
>>
>> However, I do have an idea. Try -6 and -4 flags to ssh (SSH Arguments field).
>> Things default to ipv6, perhaps your ipv6 is bad...
>>
>> Also, something I can't confirm easily, but something that comes to mind is that perhaps your problems are mtu related...

--

[Mike Frysinger]

you don't need to build older ones.  we archive them at gs://chromeos-localmirror/secureshell/releases/.  we just don't really document it ... maybe we should.

https://storage.googleapis.com/chromeos-localmirror/secureshell/releases/SecureShell-0.53.crx

rename it to .zip, unpack it, then "load unpacked" in Chrome.

-mike