SFTP fails with identity keys

[Ben Edmonds]

I'm having issues with connecting using keys.

For some background, I struggled to get keys to work over the past week (I had been using a password). This was partly due to my own ignorance on how keys work, but also due to some permissions and settings at the hosts end (Webfaction).  Eventually I came across these instructions (which I found more helpful than the official docs) and also learned to add -v to SSH arguments in order to better debug. The issue was in part that the password was still be requested even though the identity was functioning. 

However, as soon as the keys started working the SFTP mount stopped. It appears as item in the File Manager left sidebar, but no files appear. The mount path has not been changed. I have restarted the device and also uninstalled & reinstalled Secure Shell app (being sure to save and restore the backup from options first) but still no mount. 

This is the output following a click on Mount SFTP:

NB: I believe none of this is private, but all the same I have redacted some personal details as I'm still not clear what shouldn't be aired publicly.

Connecting to XXX...@XX.XXX.XXX.XX...
Loading NaCl plug-in... done.
OpenSSH_7.5p1, OpenSSL 1.0.2k  26 Jan 2017
debug1: Connecting to XX.XXX.XXX.XX [XX.XXX.XXX.XX] port 22.
debug1: Connection established.
debug1: getpeername failed: No such file or directory
debug1: identity file /.ssh/id_rsa type 1
debug1: key_load_public: No such file or directory
debug1: identity file /.ssh/id_rsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.5
debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4
debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000
debug1: Authenticating to 31.170.122.49:22 as 'XXXXXX'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: kex: algorithm: curve25519-sha256
debug1: kex: host key algorithm: ecdsa-sha2-nistp256
debug1: kex: server->client cipher: chacha20...@openssh.com MAC: <implicit> compression: zl...@openssh.com
debug1: kex: client->server cipher: chacha20...@openssh.com MAC: <implicit> compression: zl...@openssh.com
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: xxxxx-xxxx-xxxxx SHA256:xXxXxXXXxx/XxXXxxx/XxXxxXX
debug1: Host '31.170.122.49' is known and matches the ECDSA host key.
debug1: Found key in /.ssh/known_hosts:1
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey after 134217728 blocks
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: /.ssh/id_rsa
debug1: Server accepts key: XXXXX rsa-sha2-512 blen 533
debug1: Enabling compression at level 6.
debug1: Authentication succeeded (publickey).
Authenticated to XX.XXX.XXX.XX ([UNKNOWN]:-1).
debug1: channel 0: new [client-session]
debug1: Requesting no-more-...@openssh.com
debug1: Entering interactive session.
debug1: pledge: network
debug1: client_input_global_request: rtype hostk...@openssh.com want_reply 0
debug1: Sending subsystem: sftp

Any thoughts? Thank you.

[Ben Edmonds]

Would anybody have any thoughts on how I could further debug this? 

This is what I get in console when mounting SFTP (but this looks benign):

[Violation] 'setTimeout' handler took 231ms

[Violation] Forced reflow while executing JavaScript took 226ms

Thanks.

[Mike Frysinger]

i think adding the -v options made it worse.  the SFTP stack can sometimes flake in the face of partial transmissions.  try dropping the -v flags.

the sftp logic doesn't actually run in the window that you're looking at.  the init/auth logic runs there, but then it's handed off to the background page.  so any errors are displayed there.  you can view that by:

- chrome://extensions

- click "Developer mode" in the upper right

- go to the Secure Shell section

- click the "background page" under "Inspect views"

- check out the JS console there

-mike

--
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/35d0fd7c-52eb-434a-a51d-c5d5a99497f6%40chromium.org.

[Ben Edmonds]

Thanks Mike. I removed the -v option and loaded the background page console but it's still not mounting. The console only has: init: SFTP in it. 

Any other routes to figure this out?

.ben.

[Mike Frysinger]

did the main window finish connecting ?  when you click sftp mount, once things have finished processing, you should see a pop up like "(C)hoose another connection or E(x)it?".  if you don't see that, the initial handshaking hasn't finished yet.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/36dd13f2-f69a-410d-a2c6-77ead8787bdd%40chromium.org.

[Ben Edmonds]

The screen message appears as expected with:  "(C)hoose another connection or E(x)it?" 

File Manager shows the server mounted in the left sidebar. However, when the mount is selected, the main panel of File Manager remains blank.

.ben.

[Ben Edmonds]

With the latest update (v0.8.39) this now works. 

Still not sure what caused the issue, or whether the update is what's actually fixed it. 

[Lukas DiBeneditto]

My situation is a little different, in that I was using a CiscoAnyConnect VPN off site along with Chrome Secure Shell SSH.

On site, bypassing the VPN:

Adding -v to the "SSH Arguments:"

----

Welcome to Secure Shell version 0.8.39.

Answers to Frequently Asked Questions: https://goo.gl/muppJj (ctrl+click on links to open)

[Pro Tip] Use 'Open as Window' to prevent Control-W from closing your terminal!

[Pro Tip] See https://goo.gl/muppJj for more information.

ChangeLog/release notes: https://goo.gl/YnmXOs

Random Pro Tip #7: Copy to your clipboard from emacs/vim/etc... using OSC-52: https://goo.gl/XSnyLo

Connecting to [redacted username]@[redacted server]...

Loading NaCl plugin... done.

OpenSSH_7.6p1, OpenSSL 1.0.2k  26 Jan 2017

debug2: resolving "[redacted server]" port 22

debug2: ssh_connect_direct: needpriv 0

debug1: Connecting to [redacted server] [[redacted server ip]] port 22.

debug1: Connection established.

debug1: getpeername failed: No such file or directory

debug1: key_load_public: No such file or directory

debug1: identity file /.ssh/id_rsa type -1

debug1: key_load_public: No such file or directory

debug1: identity file /.ssh/id_rsa-cert type -1

debug1: key_load_public: No such file or directory

debug1: identity file /.ssh/id_dsa type -1

debug1: key_load_public: No such file or directory

debug1: identity file /.ssh/id_dsa-cert type -1

debug1: key_load_public: No such file or directory

debug1: identity file /.ssh/id_ecdsa type -1

debug1: key_load_public: No such file or directory

debug1: identity file /.ssh/id_ecdsa-cert type -1

debug1: key_load_public: No such file or directory

debug1: identity file /.ssh/id_ed25519 type -1

debug1: key_load_public: No such file or directory

debug1: key_load_public: No such file or directory

debug1: identity file /.ssh/id_ed25519-cert type -1

debug1: Local version string SSH-2.0-OpenSSH_7.6

ssh_exchange_identification: Connection closed by remote host

NaCl plugin exited with status code 255.

(R)econnect, (C)hoose another connection, or E(x)it?

 failed! :(

---- 

[Lukas DiBeneditto]

I have since gone on site, and followed the directions below, I have modified them some:

Using SSH on Chrome

http://cs.umw.edu/~finlayson/class/cpsc225/notes/01-ssh-chrome.html

Essentially you need to be able to access the remote host (the server) then type the following comands:

(First check if you have a ".ssh" folder in your home directory. If not you can type these these commands: )

1. Generate a Key Pair

cd ~

ssh-keygen

When it asks you to “Enter the file in which to save the key”, type “id_rsa” and hit enter.

Hit enter without typing a passphrase for the next two questions.

Then enter the command:

cat .ssh/id_rsa >> .ssh/authorized_keys

This will append the contents of the file "id_rsa" into the file "authorized_keys".

2. Copy the Keys to Your Machine

You can cat the contents out the files and copy and paste the text into 2 files, but I ended up using SFTP to get them off.

cat .ssh/id_rsa

Copy the contents of this into a text file named "id_rsa" to your local machine.

cat .ssh/id_rsa.pub

Copy the contents of this into a text file named "id_rsa.pub" to your local machine.

3. Load the local files "id_rsa" and "id_rsa.pub" into Chrome Secure Shell

Now close the chrome SSH window, and launch the app again.

This time, before logging on, click the “Import...” button next to the “Identity” line:

In the file window, select both the id_rsa and id_rsa.pub files, and click “Open”.

Now your Identity should read “id_rsa” instead of “[default]“.

4. Log in Again

It should work, but when I go offsite I plan to confirm it.

[Lukas DiBeneditto]

If you have done it correctly you should get something like this:

----

Welcome to Secure Shell version 0.8.39.

Answers to Frequently Asked Questions: https://goo.gl/muppJj (ctrl+click on links to open)

[Pro Tip] Use 'Open as Window' to prevent Control-W from closing your terminal!

[Pro Tip] See https://goo.gl/muppJj for more information.

ChangeLog/release notes: https://goo.gl/YnmXOs

Random Pro Tip #3: Connect from the omnibox by typing 'ssh <profile name>': https://goo.gl/V7o8ki

Connecting to [redacted username]@[redacted server]...

Loading NaCl plugin... done.

OpenSSH_7.6p1, OpenSSL 1.0.2k  26 Jan 2017

debug1: Connecting to [redacted server] [[redacted ip address]] port 22.

debug1: Connection established.

debug1: getpeername failed: No such file or directory

debug1: identity file /.ssh/id_rsa type 0

debug1: key_load_public: No such file or directory

debug1: identity file /.ssh/id_rsa-cert type -1

debug1: Local version string SSH-2.0-OpenSSH_7.6

debug1: Remote protocol version 2.0, remote software version OpenSSH_7.4

debug1: match: OpenSSH_7.4 pat OpenSSH* compat 0x04000000

debug1: Authenticating to [redacted server]:22 as '[redacted username]'

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: algorithm: curve25519-sha256

debug1: kex: host key algorithm: ecdsa-sha2-nistp256

debug1: kex: server->client cipher: chacha20...@openssh.com MAC: <implicit> compression: zl...@openssh.com

debug1: kex: client->server cipher: chacha20...@openssh.com MAC: <implicit> compression: zl...@openssh.com

debug1: expecting SSH2_MSG_KEX_ECDH_REPLY

debug1: Server host key: ecdsa-sha2-nistp256 SHA256:[redacted sha256]

The authenticity of host '[redacted server] ([redacted server ip])' can't be established.

ECDSA key fingerprint is SHA256:[redacted sha256].

Are you sure you want to continue connecting (yes/no)? 

----

I know I am definitely not doing this correctly, but it seems to be working. The concerning part is "The authenticity of host '[redacted server] ([redacted server ip])' can't be established." That is most likely my ignorance. After you type "yes" it should work.

[Mike Frysinger]

your connection issues are unrelated to sftp and thus this thread.  since you already started a thread on the topic, please only post to that.

-mike

[Mike Frysinger]

0.8.39 was rebuilt to use the new openssh release while 0.8.38 uses the previous one.  it might have "fixed" some interoperability issues, or some set of bugs working against each other.  but if it's working for you now, i'm glad :).

-mike