Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Asking password without looking for publickeys #245

Closed
chmuche opened this issue Sep 27, 2022 · 15 comments
Closed

Asking password without looking for publickeys #245

chmuche opened this issue Sep 27, 2022 · 15 comments

Comments

@chmuche
Copy link

chmuche commented Sep 27, 2022

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
Copy link
Owner

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
Copy link
Author

chmuche commented Sep 28, 2022

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:

@chmuche chmuche mentioned this issue Sep 28, 2022
Open
@antoniomika
Copy link
Owner

@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
Copy link

gucki commented Sep 29, 2022 •
edited
Loading

@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
Copy link
Owner

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
Copy link

gucki commented Sep 29, 2022 •
edited
Loading

@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
Copy link
Owner

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

@antoniomika
Copy link
Owner

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
Copy link

gucki commented Sep 29, 2022

@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
Copy link
Owner

@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.

@antoniomika
Copy link
Owner

antoniomika commented Sep 30, 2022 •
edited
Loading

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
Copy link
Author

chmuche commented Oct 3, 2022

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
Copy link

georgegebbett commented Dec 20, 2022 •
edited
Loading

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
Copy link
Author

chmuche commented Dec 20, 2022

Thanks, I will try that ASAP 👍

@antoniomika
Copy link
Owner

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@gucki @antoniomika @chmuche @georgegebbett