antoniomika/sish

Asking password without looking for publickeys

chmuche opened this issue · 15 comments

chmuche commented

Hello,

I tried to use sish with public key instead of password.
But sish keep asking a password and I don't know why.
If I type nothing, I got rejected.

My docker-compose.yml

version: '3.7'

services:
  letsencrypt:
    image: adferrand/dnsrobocert:latest
    container_name: letsencrypt-dns
    volumes:
      - /var/run/docker.sock:/var/run/docker.sock
      - ./letsencrypt:/etc/letsencrypt
      - ./dnsrobocert/dnsrobocert-config.yml:/etc/dnsrobocert/config.yml
    restart: always
  sish:
    image: antoniomika/sish:latest
    container_name: sish
    depends_on: 
      - letsencrypt
    volumes:
      - ./letsencrypt:/etc/letsencrypt
      - ./pubkeys:/pubkeys
      - ./keys:/keys
      - ./ssl:/ssl
      - ./logs:/var/log/sish/
    command: |
      --ssh-address=:2222
      --http-address=:80
      --https-address=:443
      --https=true
      --https-certificate-directory=/ssl
      --log-to-file
      --log-to-file-path=/var/log/sish/sish.log
      --log-to-file-max-size=200
      --authentication=true
      --authentication-keys-directory=/pubkeys
      --private-keys-directory=/keys
      --bind-random-ports=false
      --bind-random-subdomains=false
      --service-console
      --domain=mysys.domain.com
    network_mode: host
    restart: always

content of my path with tree -I letsencrypt -I ssl

.
├── dnsrobocert
│   └── dnsrobocert-config.yml
├── docker-compose.yml
├── keys
│   └── id_rsa
├── log
├── logs
│   └── sish.log
├── pubkeys
│   └── all_keys
├── pubkeys2
└── ssh_key

I create pubkeys/all_keys with curl https://github.com/chmuche.keys > pubkeys/all_keys

antoniomika commented

Hey @chmuche,

Everything from your docker-compose and directory structure looks okay. Can you add --debug=true and post the logs from sish when it starts?

Best,

chmuche commented

Thanks for the prompt reply

$ docker compose stop sish && docker compose rm -f sish && docker compose up -d sish && docker compose logs -f sish
sish  | [GIN-debug] [WARNING] Running in "debug" mode. Switch to "release" mode in production.
sish  |  - using env:	export GIN_MODE=release
sish  |  - using code:	gin.SetMode(gin.ReleaseMode)
sish  | 
sish  | 2022/09/28 - 06:24:41 | Starting SSH service on address: :2222
sish  | 2022/09/28 - 06:24:41 | =======Start=========
sish  | 2022/09/28 - 06:24:41 | ===Goroutines=====
sish  | 2022/09/28 - 06:24:41 | 11
sish  | 2022/09/28 - 06:24:41 | ===Listeners======
sish  | 2022/09/28 - 06:24:41 | ===Clients========
sish  | 2022/09/28 - 06:24:41 | ===HTTP Listeners===
sish  | 2022/09/28 - 06:24:41 | ===TCP Aliases====
sish  | 2022/09/28 - 06:24:41 | ===TCP Listeners====
sish  | 2022/09/28 - 06:24:41 | ===Web Console Routes====
sish  | 2022/09/28 - 06:24:41 | ===Web Console Tokens====
sish  | 2022/09/28 - 06:24:41 | ========End==========
sish  | 2022/09/28 - 06:24:41 | Loading id_rsa as ssh-rsa host key
sish  | [GIN-debug] Loaded HTML Templates (9): 
sish  | 	- console.tmpl
sish  | 	- console
sish  | 	- footer.tmpl
sish  | 	- footer
sish  | 	- header
sish  | 	- routes.tmpl
sish  | 	- 
sish  | 	- header.tmpl
sish  | 	- routes
sish  | 
sish  | 2022/09/28 - 06:24:43 | =======Start=========
sish  | 2022/09/28 - 06:24:43 | ===Goroutines=====
sish  | 2022/09/28 - 06:24:43 | 17
sish  | 2022/09/28 - 06:24:43 | ===Listeners======
sish  | 2022/09/28 - 06:24:43 | :2222
sish  | 2022/09/28 - 06:24:43 | ===Clients========
sish  | 2022/09/28 - 06:24:43 | ===HTTP Listeners===
sish  | 2022/09/28 - 06:24:43 | ===TCP Aliases====
sish  | 2022/09/28 - 06:24:43 | ===TCP Listeners====
sish  | 2022/09/28 - 06:24:43 | ===Web Console Routes====
sish  | 2022/09/28 - 06:24:43 | ===Web Console Tokens====
sish  | 2022/09/28 - 06:24:43 | ========End==========
...

When I try to connect, I see

sish  | 2022/09/28 - 06:26:28 | ===Web Console Tokens====
sish  | 2022/09/28 - 06:26:28 | ========End==========
sish  | 2022/09/28 - 06:26:28 | Accepted SSH connection for: [2a05:6e02:1014:8810:67f:48d6:57b2:2e5d]:35274
sish  | 2022/09/28 - 06:26:30 | =======Start=========
sish  | 2022/09/28 - 06:26:30 | ===Goroutines=====
sish  | 2022/09/28 - 06:26:30 | 21
sish  | 2022/09/28 - 06:26:30 | ===Listeners======
sish  | 2022/09/28 - 06:26:30 | :2222
sish  | 2022/09/28 - 06:26:30 | ===Clients========
sish  | 2022/09/28 - 06:26:30 | ===HTTP Listeners===
sish  | 2022/09/28 - 06:26:30 | ===TCP Aliases====
sish  | 2022/09/28 - 06:26:30 | ===TCP Listeners====
sish  | 2022/09/28 - 06:26:30 | ===Web Console Routes====
sish  | 2022/09/28 - 06:26:30 | ===Web Console Tokens====
sish  | 2022/09/28 - 06:26:30 | ========End==========
sish  | 2022/09/28 - 06:26:32 | =======Start=========
sish  | 2022/09/28 - 06:26:32 | ===Goroutines=====
sish  | 2022/09/28 - 06:26:32 | 21
sish  | 2022/09/28 - 06:26:32 | ===Listeners======
sish  | 2022/09/28 - 06:26:32 | :2222
sish  | 2022/09/28 - 06:26:32 | ===Clients========
sish  | 2022/09/28 - 06:26:32 | ===HTTP Listeners===
sish  | 2022/09/28 - 06:26:32 | ===TCP Aliases====
sish  | 2022/09/28 - 06:26:32 | ===TCP Listeners====
sish  | 2022/09/28 - 06:26:32 | ===Web Console Routes====
sish  | 2022/09/28 - 06:26:32 | ===Web Console Tokens====
sish  | 2022/09/28 - 06:26:32 | ========End==========
sish  | 2022/09/28 - 06:26:33 | read tcp [2001:bc8:182c:390::1]:2222->[2a05:6e02:1014:8810:67f:48d6:57b2:2e5d]:35274: use of closed network connection

but in local

$ ssh -p 2222 -R hostit:80:localhost:8080 user@mysish-server.com
user@mysish-server.com's password:
antoniomika commented

@chmuche is there a newline at the end of your authorized keys file? The golang parser will not accept a key without the newline as it doesn't know how to split it.

gucki commented

@antoniomika I just updated a very old installation to 2.7.0 (using the official docker image) and have the same issue now. Running ssh in verbose mode shows:

debug1: Next authentication method: publickey
debug1: Offering public key: /home/test/.ssh/id_rsa RSA SHA256:92B6aTcKRiIxvCTEuHZufC4goLYNK1C0QOKWH6j03H4 agent
debug1: send_pubkey_test: no mutual signature algorithm

Seems like sish doesn't accept rsa keys? (seems related to #196)

I just tested a bit further: the latest image that works is 1.1.7. All versions >= 2.0.0 fail with the error shown above. I also updated the command line as needed (private-key-location -> private-keys-directory). Perhaps some upgraded library disabled rsa by default (golang/go#39885 might be of interest?)?

antoniomika commented

Huh interesting. @gucki what type of host key are you using for sish? It should negotiate with whatever host key is configured.

By default, sish produces an ED25519 key in v1/v2 onwards. Also make sure that ssh-rsa is accepted as an algo on your local client. That functionality changed in a recent openssh version (OpenSSH >= 8.8). i.e.:

Host *
    PubkeyAcceptedAlgorithms +ssh-rsa
    HostkeyAlgorithms +ssh-rsa

So this could a combination of using an old key type, newer client, or incompatible key exchange protocol.

gucki commented

@antoniomika I'm using openssl-client 1:8.9p1-3 locally. The sish host key is a newly generated (by sish itself) ED25519 key.

I don't think the problem is the host key. Sish >= 2.0.0 doesn't seem to like my 4096 SHA256 RSA key. It works fine with sish 1.1.7. I assume there's a bug (misconfiguration of one of the used libraries) in sish.

antoniomika commented

I'll generate the same keys (freshly minted ED25519 key from sish + 4096 sha256 key) and report back if I can reproduce the issue.

  • 👍1
antoniomika commented

I've reproduced the issue and it's indeed what I mentioned above (with the functionality change with disabling the algo version in openssh 8.8). I'm not sure why it worked in prior versions of sish but it's probably a dependency change.

i.e. golang/go#37278 and golang/crypto#197

In the meantime, you can either enable ssh-rsa explicitly (like I mentioned in my comment) or on command line with -o "PubkeyAcceptedAlgorithms=+ssh-rsa" -o "HostkeyAlgorithms=+ssh-rsa". You can also change to using a ED25519 key for auth to sish as well. Otherwise, I'd prefer to wait for the official patch to land in x/crypto.

gucki commented

@antoniomika Thank you for the analysis. But why can I connect just fine to other "real" ssh servers with exactly the same key without having to adjust my client's openssh configuration? Some of these servers have RSA hostkeys, others ED25519…

antoniomika commented

@gucki it's not actually the host key that's the problem unfortunately, it's the client key. If you were using a sha1 based key, things would work okay actually. It has to do with the fact that x/crypto was written to really only accept one exchange type for RSA keys (sha1). This is a byproduct of not supporting the server-sig-algs extension (in golang/crypto#197). They landed support for host keys, not sure why they haven't landed support for the client keys though. I'll see if I can reproduce how it worked fine without any changes in the v1.1.7 version of sish.

  • 👍1
antoniomika commented

This is why v1.1.7 would work and why it doesn't currently work. Will hopefully have an update to x/crypto at some point to resolve this.

golang/crypto@32db794...c86fa9a#diff-5a7228268ceba2a7dcc7f9884fcde76bffe7b2f6f85f942697ff4ea7110caba3 if you're curious.

chmuche commented

Hi @antoniomika,
I tried with a new line at the end of the file all_keys where is stored my public key.

➜  sish cat pubkeys/all_keys                                                                                           
ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQDBa/Mc6RYKEayqACzSwpqKKBhZS7zKSPxtMkQGW7jNF116cFb2B6oqVcWGykggF4kL5Un7BNXQo0t7BgsElGihdAmklDlTtBqeofktHNyPLyCq/JGHW0+TD8sqDThgs5uGLVVFiJtmgJFvCPPLJWV+3Rnh4+hKq6Lay4MIetR/PnoAGxDP6pdLn2IpvmzpxysGbHxJbwpszObYn2d4ZpQtNyezt1Lv7vt/3pAQfVPgS1zO+A4VrID6zfJQkmGWvRigh4Or98TXXjhuVTKWV4HT/x9MGA8YvUdd22YFZMsYOb4wY1N1ACGhPaS/xqGQMZ+78pngu+B7ZDF09ddHtyIY921i8PtBOe0Nynj4mXzPwjRnSmShVvy1+NXLLlLkumRXVtHY94Kyf/Q1meds6nGXqRnCttFRU/OotMtfyUoCpnppJUWrBIhCqxgOzCIFLdqrel/A6hS3QB5AKxHoltXBmXQ6of3oNwHArGB9Q94/HKrfgoOgdVJpjBkA6yFDs90=

And the password is still asked

georgegebbett commented

This issue reared its head for me immediately after updating my client machine to MacOS Ventura. There seems to have been a config change as documented at https://superuser.com/questions/1749364/git-ssh-permission-denied-in-macos-13-ventura

I resolved this by generating an ed25519 key (ssh-keygen -t ed25519) and adding this to the sish pubkey file, at which point everything started working again.

chmuche commented

Thanks, I will try that ASAP 👍

antoniomika commented

Hey @georgegebbett @chmuche, actually fixed this in the latest version! Make sure you're pulling the latest docker image and should be good to go.

  • 🎉1