Unable to connect using public keys- please help

[markde...@gmail.com]

I am completely unable to connect using Secure Shell, although I can using putty on windows, terminus and juiceSSH on android/chromebook etc using the same keys

The odd thing is that until half-way through last year I could use Securer Shell- and nothing in the server or keys has changed. I presume an update broke it but I have no sills to work out why

I have tried to convert the key to different formats to see if that is the issue, but no luck yet.

I've included the verbose output of the terminal below- please help, as it is sending me mad

Using rsa keys

key formats:

============================================

-----BEGIN RSA PRIVATE KEY-----

######

-----END RSA PRIVATE KEY-----

============================================

public key 

============================================

ssh-rsa AAAAxxx

============================================

Terminal output::

============================================

Connecting to osmc@pxxx...

Loading NaCl plugin... done.

OpenSSH_7.6p1, OpenSSL 1.0.2k  26 Jan 2017

debug1: Connecting to pxxx [.] port 22.

debug1: Connection established.

debug1: getpeername failed: No such file or directory

key_load_public: invalid format

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

debug1: key_load_public: No such file or directory

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

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

debug1: Remote protocol version 2.0, remote software version OpenSSH_6.7p1 Debian-5+deb8u3

debug1: match: OpenSSH_6.7p1 Debian-5+deb8u3 pat OpenSSH* compat 0x04000000

debug1: Authenticating to pxxx:22 as 'osmc'

debug1: SSH2_MSG_KEXINIT sent

debug1: SSH2_MSG_KEXINIT received

debug1: kex: algorithm: curve255...@libssh.org

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:NAgy8DvD46kNuQtiuw9UvfAl/NuKzOh6xke0adHuFdk

The authenticity of host 'pxxx (.)' can't be established.

ECDSA key fingerprint is SHA256:NAgy8DvD46kNuQtiuw9UvfAl/NuKzOh6xke0adHuFdk.

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

Warning: Permanently added 'pxxx,' (ECDSA) to the list of known hosts.

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_SERVICE_ACCEPT received

debug1: Authentications that can continue: publickey

debug1: Next authentication method: publickey

debug1: Trying private key: /.ssh/pipriv2

Load key "/.ssh/pipriv2": Invalid key length

debug1: No more authentication methods to try.

osmc@xx: Permission denied (publickey).

NaCl plugin exited with status code 255.

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

 failed! :(

====

[Mike Frysinger]

it's hard to tell because you've truncated the output, but if you're using an old/small rsa key, then it no longer works. upstream openssh has dropped this, not us.

https://chromium.googlesource.com/apps/libapps/+/master/nassh/doc/FAQ.md#Are-RSA-keys-smaller-than-1024-bits-supported

-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/5bfc3946-bd49-4b57-a157-3c48553b2f13%40chromium.org.

[Mark Devine]

Many thanks for the reply

I didn't think i'd truncated- I just tried to remove ip addresses and my domain. Sorry if it made it hard to follow.

I took your advice- my key, when I performed

ssh-keygen -lf

it told me the key length was 1023 bits.

I used Puttygen to generate a 2048 bit key, and added it to the authorized_keys of my server and restarted.

Connecting with this key also resulted in the same failure.

Then I wondered if it was something to do with Secure Shell not liking the Putty-generated private key, so I generated 2048 bit keys using ssh-keygen on the server and, hey presto!

everything now working- but perhaps useful to note that there is an incompatibility with putty-generated keys? Is this something that others have found?

[Mike Frysinger]

you truncated the public key in your initial e-mail:

  ssh-rsa AAAAxxx

i doubt that's the actual public key :).

i'm not familiar with putty generated keys to know how well they work with openssh.

-mike

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

[Robert Kopacz]

I just had this behavior pop up today on me. All of a sudden, I am getting this prompt

key_load_public: invalid format
Enter passphrase for key '/.ssh/id_rsa':

And I have no idea why this behavior is occurring.

It started after I tried to install keys from SiteGround, I then deleted those keys and the login user name / IP address from the list of login credentials but now this is happening with all my accounts.

Any insights as to how to get rid of this would be appreciated.

[Mike Frysinger]

are you sure the answer isn't the same as i already posted above ?

if the key is too small, the newer openssh does not support it.  this is a change that the upstream openssh guys made, not the Chrome Secure Shell app.

-mike

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-hterm/373b4748-33ff-4474-a8db-b189cc66220f%40chromium.org.