Always asking for password?

[devtekve]

I am not sure if I am doing things right, but basically running the example on the home page, regardless of whether I pass a key or not, it always asks for the user's password before firing the event service_UserAuth. The password itself doesn't even matter. Why is this happening? I am planning on using the lib to forward but asking for the password all the time feels meaningless

[Aimeast]

Can you paste your test code?

[devtekve]

Can you paste your test code?

Im running pretty much SshServerLoader https://github.com/Aimeast/FxSsh/blob/dev/SshServerLoader/Program.cs

I am noticing that my SSH client seems to be sending None as the MethodName

which makes it send FailureMessage. and I guess it then makes it fallback to asking for password.

[Aimeast]

rfc4252#section-4 say,

Authentication methods are identified by their name, as defined in
[SSH-ARCH]. The "none" method is reserved, and MUST NOT be listed as
supported. However, it MAY be sent by the client. The server MUST
always reject this request, unless the client is to be granted access
without any authentication, in which case, the server MUST accept
this request. The main purpose of sending this request is to get the
list of supported methods from the server.

So, I think your client should send an authentication method which not none.

Can you test your client's behavior when connecting to other servers?

[devtekve]

rfc4252#section-4 say,

Authentication methods are identified by their name, as defined in
[SSH-ARCH]. The "none" method is reserved, and MUST NOT be listed as
supported. However, it MAY be sent by the client. The server MUST
always reject this request, unless the client is to be granted access
without any authentication, in which case, the server MUST accept
this request. The main purpose of sending this request is to get the
list of supported methods from the server.

So, I think your client should send an authentication method which not none.

Can you test your client's behavior when connecting to other servers?

I have a feeling It's something else. The client is openssh on mac though, nothing fancy or special. But I think the problem is missing an algorithm

debug2: KEX algorithms: ecdh-sha2-nistp256,sntrup761x25519-sha512,sntrup761x25519-sha512@openssh.com,mlkem768x25519-sha256,curve25519-sha256,curve25519-sha256@libssh.org,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group14-sha256,ext-info-c,kex-strict-c-v00@openssh.com
debug2: host key algorithms: ecdsa-sha2-nistp256-cert-v01@openssh.com,ecdsa-sha2-nistp256,ssh-ed25519-cert-v01@openssh.com,ecdsa-sha2-nistp384-cert-v01@openssh.com,ecdsa-sha2-nistp521-cert-v01@openssh.com,sk-ssh-ed25519-cert-v01@openssh.com,sk-ecdsa-sha2-nistp256-cert-v01@openssh.com,rsa-sha2-512-cert-v01@openssh.com,rsa-sha2-256-cert-v01@openssh.com,ssh-ed25519,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25519@openssh.com,sk-ecdsa-sha2-nistp256@openssh.com,rsa-sha2-512,rsa-sha2-256
debug2: ciphers ctos: aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr
debug2: ciphers stoc: aes128-gcm@openssh.com,aes256-gcm@openssh.com,chacha20-poly1305@openssh.com,aes128-ctr,aes192-ctr,aes256-ctr
debug2: MACs ctos: hmac-sha2-256-etm@openssh.com,hmac-sha2-256,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: hmac-sha2-256-etm@openssh.com,hmac-sha2-256,umac-64-etm@openssh.com,umac-128-etm@openssh.com,hmac-sha2-512-etm@openssh.com,hmac-sha1-etm@openssh.com,umac-64@openssh.com,umac-128@openssh.com,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib@openssh.com
debug2: compression stoc: none,zlib@openssh.com
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug3: send packet: type 5
debug3: receive packet: type 6
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug3: send packet: type 50
debug3: receive packet: type 51
debug1: Authentications that can continue: publickey
debug3: start over, passed a different list publickey
debug3: preferred publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug3: ssh_get_authentication_socket_path: path '/private/tmp/com.apple.launchd.Go5rr5zO3l/Listeners'
debug1: get_agent_identities: bound agent to hostkey
debug1: get_agent_identities: ssh_fetch_identitylist: agent contains no identities
debug1: Will attempt key: /Users/<redacted>/.ssh/id_rsa RSA SHA256:FdkVzJdcrb7hjd8sToKWY14xAkBsglFBjWOo5VwbZ0o
debug1: Will attempt key: /Users/<redacted>/.ssh/id_rsa RSA-CERT SHA256:FdkVzJdcrb7hjd8sToKWY14xAkBsglFBjWOo5VwbZ0o
debug1: Will attempt key: /Users/<redacted>/.ssh/id_ecdsa 
debug1: Will attempt key: /Users/<redacted>/.ssh/id_ecdsa_sk 
debug1: Will attempt key: /Users/<redacted>/.ssh/id_ed25519 
debug1: Will attempt key: /Users/<redacted>/.ssh/id_ed25519_sk 
debug1: Will attempt key: /Users/<redacted>/.ssh/id_xmss 
debug1: Will attempt key: /Users/<redacted>/.ssh/id_dsa 
debug2: pubkey_prepare: done
debug1: Offering public key: /Users/<redacted>/.ssh/id_rsa RSA SHA256:FdkVzJdcrb7hjd8sToKWY14xAkBsglFBjWOo5VwbZ0o
debug1: send_pubkey_test: no mutual signature algorithm
debug1: Offering public key: /Users/<redacted>/.ssh/id_rsa RSA-CERT SHA256:FdkVzJdcrb7hjd8sToKWY14xAkBsglFBjWOo5VwbZ0o
debug1: send_pubkey_test: no mutual signature algorithm

[Aimeast]

I have a feeling It's something else. The client is openssh on mac though, nothing fancy or special. But I think the problem is missing an algorithm

Please show your directory C:\Users\<USER>\.ssh, and the header of file id_rsa. e.g., start with ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAA.......

or,

please try to regenerate public key with algorithms: RSA family: rsa-sha2-256, rsa-sha2-512; ECDsa family: ecdsa-sha2-nistp256, ecdsa-sha2-nistp384, ecdsa-sha2-nistp521

[devtekve]

What worked:

Pretty much all ECDSA

• openssl ecparam -name prime256v1 -genkey -noout -out id_ecdsa
• ssh-keygen -t ecdsa -b 521 -f id_ecdsa_521
• ssh-keygen -t ecdsa -b 384 -f id_ecdsa_521
• id_ecdsa_256.txt
• id_ecdsa_384.txt
• id_ecdsa_521.txt

What didn't work:

• No RSA key was able to work for me. I will attach them here (they have been generated for this test)
• id_rsa_4096.txt
• id_rsa_openssl.txt

I think there's something wrong then with the use of RSA keys for some reason, I can't get any of them to work

[devtekve]

I think it's related to #39

[devtekve]

I did some digging and this is what we are missing RFC8308 Extension Negotiation in the Secure Shell (SSH) Protocol

I have tested adding it locally and I am having good progress. So I will be opening a PR for you to review soon (I sincerely lack the proper knowledge to assess whether what I am doing is the right way of doing it)

[devtekve]

@Aimeast here's the PR I mentioned #50, I tested my use case and it's now working as expected with no key changes on my end.

I have limited knowledge on the topic so feel free to edit as much as you wish as I don't have any strong opinion (besides of course being able to have it fixed)

Thanks for the amazing project !

[Aimeast]

Thank you for your research. I haven't encountered the situation you described, so I'd like to follow up with the following questions. I hope you can provide answers to help better address this issue.

1. The SSH client and version you are using, and what RSA public key it has. Please provide the public key file id_rsa.pub. (Apologies for missing .pub yesterday.)
2. As I understand it, the logic of your PR is: after the client sends ext-info-c, the server responds with server-sig-algs, listing all supported public-key-algorithms. However, from the debug logs you provided, the client did not send ext-info-c. This is something I don’t understand.
3. Could you provide the interaction after adding server-sig-algs? For example, the client's debug logs, the information received by the server, and its response.

---

Regarding PR #50,

1. 3.1. "server-sig-algs"

This extension is sent by the server and contains a list of public
key algorithms that the server is able to process as part of a
"publickey" authentication request. If a client sends this
extension, the server MAY ignore it and MAY disconnect.

It seems the server needs a mechanism to handle server-sig-algs.

2. RFC 8308 also defines delay-compression, no-flow-control, and elevation. These extensions are unrelated to key exchange, but if we start implementing RFC 8308, we need to predefine these parts and provide basic response support.

[devtekve]

hey @Aimeast

1. I am using Mac's SSH (OpenSSH OpenSSH_9.9p1, LibreSSL 3.3.6)
2. I gave you the private keys because that's what's used by the client to generate the signature to send to the server, so I think you can use the private keys I shared yesterday to test it though
3. logs.txt

---

Regarding PR #50,

My use case was only really needing the ext-info-c, so I followed a similar approach like ronf/asyncssh@e91b477#diff-bfd99085536ddab081af6d83a5c2549555be2472e4f576f99d9fbe2b8b9722d1 , they also started implementing only the server-sig-algs (which is what we are doing on that PR)

[devtekve]

@Aimeast I am shifting focus to my app so I will likely be less active here, tag me if you have further questions or comments in hopes of me getting the ping :D thanks for this project!

[Aimeast]

Thank you very much for your feedback. I also have only free time to put on this project, and I need more research on this issue to understand these behaviors. I will contact you when I need it.

[Aimeast]

@devtekve Hello! I installed Mac OS Catalina 10.15 on a virtual machine and tested that I can directly establish an SSH connection to open a Pty. Which version of Mac OS are you testing? (It seems that installing newer versions of Mac OS in a virtual machine can be somewhat challenging.)