Handshake failed: ssh: unable to authenticate

victor141516 · March 11, 2022, 4:13pm

Hey thanks for this awesome project!

I’m getting the same error as this other post: [Solved] Tunnel error: Failed to Dial (BoreTunnel error: Failed to dial: %!(EXTRA *errors.errorString=ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain))

First I’ll explain my setup:

Setup

BoringProxy server is running on a Docker container (using your repo dockerfile), and I’m using this line to run BoringProxy: server -http-port 8000 -admin-domain proxy.viti.site -allow-http -behind-proxy -print-login
So it’s using port 8000 (not https), but I’m using Caddy as TLS termination and reverse proxy.
I have a wildcard certificate for *.proxy.viti.site, and I’m also reverse-proxying everything from *.proxy.viti.site to the BoringProxy container.
I’ve not mapped any port from the container, just the reverse proxy.

On the client side, I’m trying to connect from home. I’m behind a CGNAT, and my machine is running Windows but I’m running the client from WSL (a VM). This VM can SSH to the server and has internet connectivity.
I’m running it with ./boringproxy-linux-x86_64 client -server proxy.viti.site -token xxxxxxxxxxxxxxxxxxx -client-name test

Then in the web interface I have this tunnel:
ljlxkc

And I have a python http server running on port 8000:

❯ python -m http.server
Serving HTTP on 0.0.0.0 port 8000 (http://0.0.0.0:8000/) ...

The error

I’m getting this error in the BoringProxy client console:

❯ ./boringproxy-linux-x86_64 client -server proxy.viti.site -token La7k4CviG1dgGUfcI2jqUfeun9XcCgsA -client-name test 2022/03/11 17:02:33 SyncTunnels
2022/03/11 17:02:33 New tunnel asd.proxy.viti.site
2022/03/11 17:02:33 BoreTunnel asd.proxy.viti.site
2022/03/11 17:02:33 BoreTunnel error:  Failed to dial: %!(EXTRA *errors.errorString=ssh: handshake failed: ssh: unable to authenticate, attempted methods [none publickey], no supported methods remain)

And if I try to navigate to https://asd.proxy.viti.site I get:
Get "http://localhost:44655/": dial tcp 127.0.0.1:44655: connect: connection refused

I saw the other issue about this error being related to an outdated OpenSSH version. I have OpenSSH 8.9p1 in the client:

❯ ssh -v localhost
OpenSSH_8.9p1, OpenSSL 1.1.1m  14 Dec 2021

And 8.2p1 in the server:

❯ ssh -v localhost
OpenSSH_8.2p1 Ubuntu-4ubuntu0.4, OpenSSL 1.1.1f  31 Mar 2020

So I don’t think that’s the case. Do you have any other tips?

Thanks!

anders · March 11, 2022, 7:05pm

Hey @victor141516, thanks for the detailed information.

One thing to note up front is that running behind another reverse proxy (Caddy in your case) is not something I do, so it’s not as heavily tested. I’ve added a few features for use by others which you’ve discovered, but there’s a good chance we have some outlying bugs with this setup.

In terms of debugging your specific issue, what happens if you click “View” on the tunnel, then download the SSH private key and try connecting manually?

I believe the command should look like this:

ssh -v -i id_rsa -R 127.0.0.1:44655:127.0.0.1:8000 <username>@asd.proxy.viti.site

victor141516 · March 13, 2022, 12:13pm

Sorry but yesterday both of my server disks failed at the same time, so now I have to setup everything again. I’ll follow up with this asap

v3d2 · March 31, 2022, 6:08pm

Hi, hope it’s OK that I just use this topic as I’m experiencing the exact same situation.

OpenSSH version on both server and client are OpenSSH_8.9p1, OpenSSL 1.1.1n 15 Mar 2022

When I attempt to do it manually with the key it just asks for my password.
What am I doing wrong?

Thanks!

debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: id_rsa  explicit
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com,webauthn-sk-ecdsa-sha2-nistp256@openssh.com>
debug1: kex_input_ext_info: publickey-hostbound@openssh.com=<0>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Trying private key: id_rsa
debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: password

anders · March 31, 2022, 6:44pm

Hey @v3d2, a couple things. First, I recommend disabling password login for SSH unless you’re familiar with the security implications and have systems in place to prevent brute-force logins (ie Fail2Ban, etc).

In terms of getting this working, are you using the same user for the SSH command as the boringproxy server on the remote machine?

v3d2 · March 31, 2022, 9:50pm

Thanks for the the heads up - no worries there, fail2ban is very strict and active on that server, I just had to unban my own IP while trying to configure the boringproxy.

I am using the the same SSH user. I guess it’s something in OpenSSH config that’s messing with authenticating the users, just fired up a fresh ubuntu 20 instance and there it seems to be boring fine.

abhishek_pg · April 18, 2022, 11:36am

I was getting the same error for last one week. I have tried every solution. Finally found out that boringproxy is not working in openssh 8.9 but its working in 8.4. Everything worked after downgrading to openssh 8.4 both in server and client.

anders · April 18, 2022, 2:44pm

@abhishek_pg your problem might be related to this:

https://github.com/boringproxy/boringproxy/issues/111

andrewdhastings · May 14, 2022, 1:23am

I’m having the same issue on a raspberry pi. It is running OpenSSH_8.4p1 so not sure if it is the same issue or not.

I did try to SSH in directly using the key and was getting a permission denied response.

anders · May 14, 2022, 2:18pm

@andrewdhastings what’s the OpenSSH version on both the server and client? Can you check the SSH logs and see if there are any useful messages when you attempt to log in manually?

andrewdhastings · May 14, 2022, 3:19pm

@anders the server is running OpenSSH_8.2p1 and is using your prebuilt docker image.

Here is the output when trying to connect through ssh:

OpenSSH_8.4p1, OpenSSL 1.1.1j  16 Feb 2021
debug1: Reading configuration data /c/Users/ceffy/.ssh/config
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Connecting to pi-test.themodern.cloud [143.198.64.123] port 22.
debug1: Connection established.
debug1: identity file id_rsapi type -1
debug1: identity file id_rsapi-cert type -1
debug1: Local version string SSH-2.0-OpenSSH_8.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_8.2p1 Ubuntu-4ubuntu0.5
debug1: match: OpenSSH_8.2p1 Ubuntu-4ubuntu0.5 pat OpenSSH* compat 0x04000000
debug1: Authenticating to pi-test.themodern.cloud:22 as 'ceffylau'
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-poly1305@openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305@openssh.com MAC: <implicit> compression: none
debug1: expecting SSH2_MSG_KEX_ECDH_REPLY
debug1: Server host key: ecdsa-sha2-nistp256 SHA256:uUTdgKKFUWwUyEUZHNxKLSjfxzj/8I71mIHiK7LZeLI
debug1: Host 'pi-test.themodern.cloud' is known and matches the ECDSA host key.
debug1: Found key in /c/Users/ceffy/.ssh/known_hosts:19
debug1: rekey out after 134217728 blocks
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: SSH2_MSG_NEWKEYS received
debug1: rekey in after 134217728 blocks
debug1: Will attempt key: id_rsapi  explicit
debug1: SSH2_MSG_EXT_INFO received
debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,sk-ssh-ed25519@openssh.com,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ecdsa-sha2-nistp256@openssh.com>
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug1: Authentications that can continue: publickey
debug1: Next authentication method: publickey
debug1: Trying private key: id_rsapi
debug1: Authentications that can continue: publickey
debug1: No more authentication methods to try.
ceffylau@pi-test.themodern.cloud: Permission denied (publickey).

anders · May 16, 2022, 10:19pm

Hm I don’t see anything obvious in the logs. Not really sure what’s up. The docker image was contributed by community members. I don’t use it myself.

What I would try next is manually creating an SSH key and making sure it works, then adding the private key to boringproxy_db.json and see if boringproxy works then.

andrepadez · September 22, 2022, 9:51pm

How would i go and downgrade it from 8.9 to 8.4 on Ubuntu? thank you

anders · September 23, 2022, 7:40pm

Hey @andrepadez, I’m working on making a new release which hopefully will solve this problem without the need to downgrade OpenSSH. You can try it here:

https://gemdrive.io/apps/delver/?drive=https://files.apitman.com&path=/public/boringproxy/fix-outdated-rsa

andrepadez · September 24, 2022, 3:48am

Thank you so much @anders , but i managed to get it to work without downgrading. I now have a Mac and an Ubuntu client successfully connecting to it.

andrewdhastings · October 15, 2022, 5:28pm

This beta version fixed my issues and I was able to get it to work no issues at all.

anders · October 17, 2022, 8:01pm

Thanks for reporting back @andrewdhastings. This has been merged and will go into the next release.