From maximejeanrey at gmail.com Fri Nov 1 01:05:16 2024 From: maximejeanrey at gmail.com (Maxime Rey) Date: Thu, 31 Oct 2024 15:05:16 +0100 Subject: [PATCH] Specify signature algorithm during server hostkeys prove In-Reply-To: (Damien Miller's message of "Tue, 29 Oct 2024 10:58:53 +1100 (AEDT)") References: <87o734fezz.fsf@gmail.com> Message-ID: <87r07wqsf7.fsf@gmail.com> Damien Miller writes: > > Hi, > > I'm having trouble replicating this failure by making changes to the > existing hostkey-agent.sh regress test. > > Can you share a bit more about how it happens? Debug traces from the > client and server would be very helpful. > > Thanks, > Damien Miller Hi Damien, Thanks for your response. I'm currently working on reproducing this with the hostkey-agent.sh test, but I can consistently reproduce it using a clean OpenSSH repository. Here?s how: 1. Start the SSH agent. 2. Add two ECDSA keys to the agent. 3. Modify sshd_config: Set HostKeyAgent as the agent path. Add the public parts of the ECDSA keys to the configuration. 4. Start sshd. 5. Run the SSH client: Use default configuration, with no prior server keys in the known_hosts file. In this setup, the server and client complete the key exchange successfully. However, when the server attempts to prove the authenticity of the second ECDSA key, the process fails as described. I've attached logs and my configuration files for reference. Let me know if I?m missing anything or if there?s anything else I should provide to help replicate the issue. Please tell me if i'm doing anything wrong, multiple mails. Apologies for the multiple emails. I forgot to include the mailing list in my previous reply. Maxime Rey -------------- next part -------------- debug2: load_server_config: filename /usr/local/etc/sshd_config debug2: load_server_config: done config len = 3651 debug2: parse_server_config_depth: config /usr/local/etc/sshd_config len 3651 debug3: /usr/local/etc/sshd_config:23 setting HostKey /etc/ssh/ssh_host_ecdsa_key.pub debug3: /usr/local/etc/sshd_config:26 setting HostKey /etc/ssh/ssh_host_ecdsa_key2.pub debug3: /usr/local/etc/sshd_config:32 setting HostKeyAgent /tmp/ssh-XXXXXXylicM7/agent.85320 debug3: /usr/local/etc/sshd_config:39 setting SshdSessionPath /home/maxime/Projects/Dev/openssh-portable/sshd-session debug3: /usr/local/etc/sshd_config:56 setting AuthorizedKeysFile .ssh/authorized_keys debug3: /usr/local/etc/sshd_config:124 setting Subsystem sftp /usr/lib/ssh/sftp-server debug1: sshd version OpenSSH_9.9, OpenSSL 3.3.2 3 Sep 2024 debug3: ssh_get_authentication_socket_path: path '/tmp/ssh-XXXXXXylicM7/agent.85320' Unable to load host key "/etc/ssh/ssh_host_ecdsa_key.pub": error in libcrypto debug1: will rely on agent for hostkey /etc/ssh/ssh_host_ecdsa_key.pub debug1: agent host key #0: ecdsa-sha2-nistp256 SHA256:YkIO1IvDg3w8IaG+jWWJ8qSL5dr/NTZ+4xAA0Wau5Fc Unable to load host key "/etc/ssh/ssh_host_ecdsa_key2.pub": error in libcrypto debug1: will rely on agent for hostkey /etc/ssh/ssh_host_ecdsa_key2.pub debug1: agent host key #1: ecdsa-sha2-nistp521 SHA256:3jTqlIIrC33dsPwveXAP2Qqi24vo9Olaq2M1WIA+A3I debug1: rexec_argv[1]='-ddd' debug3: using /home/maxime/Projects/Dev/openssh-portable/sshd-session for re-exec debug3: oom_adjust_setup debug1: Set /proc/self/oom_score_adj from 100 to -1000 debug2: fd 7 setting O_NONBLOCK debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. debug2: fd 8 setting O_NONBLOCK debug3: sock_set_v6only: set socket 8 IPV6_V6ONLY debug1: Bind to port 22 on ::. Server listening on :: port 22. debug3: fd 9 is not O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 12 config len 3651 debug3: ssh_msg_send: type 0 len 3971 debug3: ssh_msg_send: done debug3: send_rexec_state: done debug1: rexec start in 9 out 9 newsock 9 pipe -1 sock 12/13 debug1: sshd version OpenSSH_9.9, OpenSSL 3.3.2 3 Sep 2024 debug3: recv_rexec_state: entering fd = 5 debug3: ssh_msg_recv entering debug2: parse_hostkeys: pubkey 0: ecdsa-sha2-nistp256 debug2: parse_hostkeys: pubkey 1: ecdsa-sha2-nistp521 debug3: recv_rexec_state: done debug2: parse_server_config_depth: config rexec len 3651 debug3: rexec:23 setting HostKey /etc/ssh/ssh_host_ecdsa_key.pub debug3: rexec:26 setting HostKey /etc/ssh/ssh_host_ecdsa_key2.pub debug3: rexec:32 setting HostKeyAgent /tmp/ssh-XXXXXXylicM7/agent.85320 debug3: rexec:39 setting SshdSessionPath /home/maxime/Projects/Dev/openssh-portable/sshd-session debug3: rexec:56 setting AuthorizedKeysFile .ssh/authorized_keys debug3: rexec:124 setting Subsystem sftp /usr/lib/ssh/sftp-server debug3: ssh_get_authentication_socket_path: path '/tmp/ssh-XXXXXXylicM7/agent.85320' debug1: network sockets: 7, 7 debug3: server_process_channel_timeouts: setting 0 timeouts debug3: channel_clear_timeouts: clearing Connection from 127.0.0.1 port 37054 on 127.0.0.1 port 22 rdomain "" debug1: Local version string SSH-2.0-OpenSSH_9.9 debug1: Remote protocol version 2.0, remote software version OpenSSH_9.9 debug1: compat_banner: match: OpenSSH_9.9 pat OpenSSH* compat 0x04000000 debug2: fd 7 setting O_NONBLOCK debug2: Network child is on pid 86786 debug3: ssh_get_authentication_socket_path: path '/tmp/ssh-XXXXXXylicM7/agent.85320' debug3: preauth child monitor started debug1: sshd version OpenSSH_9.9, OpenSSL 3.3.2 3 Sep 2024 [preauth] debug1: network sockets: 5, 5 [preauth] debug3: recv_privsep_state: begin [preauth] debug3: mm_get_state: entering [preauth] debug3: mm_request_send: entering, type 51 [preauth] debug3: mm_get_state: waiting for MONITOR_ANS_STATE [preauth] debug3: mm_request_receive_expect: entering, type 52 [preauth] debug3: mm_request_receive: entering [preauth] debug3: mm_request_receive: entering debug3: monitor_read: checking request 51 debug1: mm_answer_state: config len 3651 debug3: mm_request_send: entering, type 52 debug3: mm_answer_state: done debug2: monitor_read: 51 used once, disabling now debug3: mm_get_state: done [preauth] debug2: parse_hostkeys: key 0: ecdsa-sha2-nistp256 [preauth] debug2: parse_hostkeys: key 1: ecdsa-sha2-nistp521 [preauth] debug3: recv_privsep_state: done [preauth] debug2: parse_server_config_depth: config rexec len 3651 [preauth] debug3: rexec:23 setting HostKey /etc/ssh/ssh_host_ecdsa_key.pub [preauth] debug3: rexec:26 setting HostKey /etc/ssh/ssh_host_ecdsa_key2.pub [preauth] debug3: rexec:32 setting HostKeyAgent /tmp/ssh-XXXXXXylicM7/agent.85320 [preauth] debug3: rexec:39 setting SshdSessionPath /home/maxime/Projects/Dev/openssh-portable/sshd-session [preauth] debug3: rexec:56 setting AuthorizedKeysFile .ssh/authorized_keys [preauth] debug3: rexec:124 setting Subsystem sftp /usr/lib/ssh/sftp-server [preauth] debug3: ssh_get_authentication_socket_path: path '/tmp/ssh-XXXXXXylicM7/agent.85320' [preauth] debug3: server_process_channel_timeouts: setting 0 timeouts [preauth] debug3: channel_clear_timeouts: clearing [preauth] debug3: fd 5 is O_NONBLOCK [preauth] debug3: ssh_sandbox_init: preparing seccomp filter sandbox [preauth] debug3: privsep user:group 34:34 [preauth] debug1: permanently_set_uid: 34/34 [preauth] debug3: ssh_sandbox_child: setting PR_SET_NO_NEW_PRIVS [preauth] debug3: ssh_sandbox_child: attaching seccomp filter program [preauth] debug1: list_hostkey_types: ecdsa-sha2-nistp256,ecdsa-sha2-nistp521 [preauth] debug3: send packet: type 20 [preauth] debug1: SSH2_MSG_KEXINIT sent [preauth] debug3: receive packet: type 20 [preauth] debug1: SSH2_MSG_KEXINIT received [preauth] debug2: local server KEXINIT proposal [preauth] debug2: KEX algorithms: mlkem768x25519-sha256,sntrup761x25519-sha512,sntrup761x25519-sha512 at openssh.com,curve25519-sha256,curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,ext-info-s,kex-strict-s-v00 at openssh.com [preauth] debug2: host key algorithms: ecdsa-sha2-nistp256,ecdsa-sha2-nistp521 [preauth] debug2: ciphers ctos: chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com [preauth] debug2: ciphers stoc: chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com [preauth] debug2: MACs ctos: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 [preauth] debug2: MACs stoc: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 [preauth] debug2: compression ctos: none,zlib at openssh.com [preauth] debug2: compression stoc: none,zlib at openssh.com [preauth] debug2: languages ctos: [preauth] debug2: languages stoc: [preauth] debug2: first_kex_follows 0 [preauth] debug2: reserved 0 [preauth] debug2: peer client KEXINIT proposal [preauth] debug2: KEX algorithms: mlkem768x25519-sha256,sntrup761x25519-sha512,sntrup761x25519-sha512 at openssh.com,curve25519-sha256,curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,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 at openssh.com [preauth] debug2: host key algorithms: ssh-ed25519-cert-v01 at openssh.com,ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,sk-ssh-ed25519-cert-v01 at openssh.com,sk-ecdsa-sha2-nistp256-cert-v01 at openssh.com,rsa-sha2-512-cert-v01 at openssh.com,rsa-sha2-256-cert-v01 at openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25519 at openssh.com,sk-ecdsa-sha2-nistp256 at openssh.com,rsa-sha2-512,rsa-sha2-256 [preauth] debug2: ciphers ctos: chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com [preauth] debug2: ciphers stoc: chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com [preauth] debug2: MACs ctos: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 [preauth] debug2: MACs stoc: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 [preauth] debug2: compression ctos: none,zlib at openssh.com [preauth] debug2: compression stoc: none,zlib at openssh.com [preauth] debug2: languages ctos: [preauth] debug2: languages stoc: [preauth] debug2: first_kex_follows 0 [preauth] debug2: reserved 0 [preauth] debug3: kex_choose_conf: will use strict KEX ordering [preauth] debug1: kex: algorithm: mlkem768x25519-sha256 [preauth] debug1: kex: host key algorithm: ecdsa-sha2-nistp256 [preauth] debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com MAC: compression: none [preauth] debug1: kex: server->client cipher: chacha20-poly1305 at openssh.com MAC: compression: none [preauth] debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth] debug3: receive packet: type 30 [preauth] debug1: SSH2_MSG_KEX_ECDH_INIT received [preauth] debug3: mm_sshkey_sign: entering [preauth] debug3: mm_request_send: entering, type 6 [preauth] debug3: mm_sshkey_sign: waiting for MONITOR_ANS_SIGN [preauth] debug3: mm_request_receive_expect: entering, type 7 [preauth] debug3: mm_request_receive: entering [preauth] debug3: mm_request_receive: entering debug3: monitor_read: checking request 6 debug3: mm_answer_sign: entering debug1: mm_answer_sign: hostkey ecdsa-sha2-nistp256 index 0 debug3: mm_answer_sign: ecdsa-sha2-nistp256 KEX signature len=100 debug3: mm_request_send: entering, type 7 debug2: monitor_read: 6 used once, disabling now debug3: mm_sshkey_sign: ecdsa-sha2-nistp256 signature len=100 [preauth] debug3: send packet: type 31 [preauth] debug3: send packet: type 21 [preauth] debug1: ssh_packet_send2_wrapped: resetting send seqnr 3 [preauth] debug2: ssh_set_newkeys: mode 1 [preauth] debug1: rekey out after 134217728 blocks [preauth] debug1: SSH2_MSG_NEWKEYS sent [preauth] debug1: Sending SSH2_MSG_EXT_INFO [preauth] debug3: send packet: type 7 [preauth] debug1: expecting SSH2_MSG_NEWKEYS [preauth] debug3: receive packet: type 21 [preauth] debug1: ssh_packet_read_poll2: resetting read seqnr 3 [preauth] debug1: SSH2_MSG_NEWKEYS received [preauth] debug2: ssh_set_newkeys: mode 0 [preauth] debug1: rekey in after 134217728 blocks [preauth] debug2: KEX algorithms: mlkem768x25519-sha256,sntrup761x25519-sha512,sntrup761x25519-sha512 at openssh.com,curve25519-sha256,curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,ext-info-s,kex-strict-s-v00 at openssh.com [preauth] debug2: host key algorithms: ecdsa-sha2-nistp256,ecdsa-sha2-nistp521 [preauth] debug2: ciphers ctos: chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com [preauth] debug2: ciphers stoc: chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com [preauth] debug2: MACs ctos: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 [preauth] debug2: MACs stoc: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 [preauth] debug2: compression ctos: none,zlib at openssh.com [preauth] debug2: compression stoc: none,zlib at openssh.com [preauth] debug2: languages ctos: [preauth] debug2: languages stoc: [preauth] debug2: first_kex_follows 0 [preauth] debug2: reserved 0 [preauth] debug1: KEX done [preauth] debug3: receive packet: type 7 [preauth] debug1: SSH2_MSG_EXT_INFO received [preauth] debug3: kex_input_ext_info: extension ext-info-in-auth at openssh.com [preauth] debug1: kex_ext_info_check_ver: ext-info-in-auth at openssh.com=<0> [preauth] debug3: receive packet: type 5 [preauth] debug3: send packet: type 6 [preauth] debug3: receive packet: type 50 [preauth] debug1: userauth-request for user maxime service ssh-connection method none [preauth] debug1: attempt 0 failures 0 [preauth] debug3: mm_getpwnamallow: entering [preauth] debug3: mm_request_send: entering, type 8 [preauth] debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM [preauth] debug3: mm_request_receive_expect: entering, type 9 [preauth] debug3: mm_request_receive: entering [preauth] debug3: mm_request_receive: entering debug3: monitor_read: checking request 8 debug3: mm_answer_pwnamallow: entering debug2: parse_server_config_depth: config reprocess config len 3651 debug3: auth_shadow_acctexpired: today 20027 sp_expire -1 days left -20028 debug3: account expiration disabled debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 debug3: mm_request_send: entering, type 9 debug2: monitor_read: 8 used once, disabling now debug3: server_process_channel_timeouts: setting 0 timeouts [preauth] debug3: channel_clear_timeouts: clearing [preauth] debug2: input_userauth_request: setting up authctxt for maxime [preauth] debug3: mm_inform_authserv: entering [preauth] debug3: mm_request_send: entering, type 4 [preauth] debug1: kex_server_update_ext_info: Sending SSH2_MSG_EXT_INFO [preauth] debug3: send packet: type 7 [preauth] debug2: input_userauth_request: try method none [preauth] debug3: userauth_finish: failure partial=0 next methods="publickey,password,keyboard-interactive" [preauth] debug3: send packet: type 51 [preauth] debug3: mm_request_receive: entering debug3: monitor_read: checking request 4 debug3: mm_answer_authserv: service=ssh-connection, style= debug2: monitor_read: 4 used once, disabling now debug3: receive packet: type 50 [preauth] debug1: userauth-request for user maxime service ssh-connection method publickey [preauth] debug1: attempt 1 failures 0 [preauth] debug2: input_userauth_request: try method publickey [preauth] debug2: userauth_pubkey: valid user maxime querying public key ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIO1eB+ms1FCh9bRMbu2BmsoWNYrru+tS1wVOPzSMEEYU [preauth] debug1: userauth_pubkey: publickey test pkalg ssh-ed25519 pkblob ED25519 SHA256:19J+iR0fmy8ExjxEopqcxD5iaa9u71VZ1+LeJx1Mr/A [preauth] debug3: mm_key_allowed: entering [preauth] debug3: mm_request_send: entering, type 22 [preauth] debug3: mm_key_allowed: waiting for MONITOR_ANS_KEYALLOWED [preauth] debug3: mm_request_receive_expect: entering, type 23 [preauth] debug3: mm_request_receive: entering [preauth] debug3: mm_request_receive: entering debug3: monitor_read: checking request 22 debug3: mm_answer_keyallowed: entering debug1: temporarily_use_uid: 1000/1000 (e=0/0) debug1: trying public key file /home/maxime/.ssh/authorized_keys debug1: fd 8 clearing O_NONBLOCK debug2: auth_check_authkeys_file: /home/maxime/.ssh/authorized_keys: processed 1/1 lines debug1: restore_uid: 0/0 debug3: mm_answer_keyallowed: publickey authentication test: ED25519 key is not allowed Failed publickey for maxime from 127.0.0.1 port 37054 ssh2: ED25519 SHA256:19J+iR0fmy8ExjxEopqcxD5iaa9u71VZ1+LeJx1Mr/A debug3: mm_request_send: entering, type 23 debug2: userauth_pubkey: authenticated 0 pkalg ssh-ed25519 [preauth] debug3: user_specific_delay: user specific delay 0.000ms [preauth] debug3: ensure_minimum_time_since: elapsed 3.061ms, delaying 5.020ms (requested 8.081ms) [preauth] debug3: userauth_finish: failure partial=0 next methods="publickey,password,keyboard-interactive" [preauth] debug3: send packet: type 51 [preauth] debug3: receive packet: type 50 [preauth] debug1: userauth-request for user maxime service ssh-connection method keyboard-interactive [preauth] debug1: attempt 2 failures 1 [preauth] debug2: input_userauth_request: try method keyboard-interactive [preauth] debug1: keyboard-interactive devs [preauth] debug1: auth2_challenge: user=maxime devs= [preauth] debug1: kbdint_alloc: devices '' [preauth] debug2: auth2_challenge_start: devices [preauth] debug3: user_specific_delay: user specific delay 0.000ms [preauth] debug3: ensure_minimum_time_since: elapsed 0.061ms, delaying 8.020ms (requested 8.081ms) [preauth] debug3: userauth_finish: failure partial=0 next methods="publickey,password,keyboard-interactive" [preauth] debug3: send packet: type 51 [preauth] debug3: receive packet: type 50 [preauth] debug1: userauth-request for user maxime service ssh-connection method password [preauth] debug1: attempt 3 failures 2 [preauth] debug2: input_userauth_request: try method password [preauth] debug3: mm_auth_password: entering [preauth] debug3: mm_request_send: entering, type 12 [preauth] debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD [preauth] debug3: mm_request_receive_expect: entering, type 13 [preauth] debug3: mm_request_receive: entering [preauth] debug3: mm_request_receive: entering debug3: monitor_read: checking request 12 debug3: auth_shadow_pwexpired: today 20027 sp_lstchg 19946 sp_max 99999 debug3: mm_answer_authpassword: sending result 1 debug3: mm_answer_authpassword: sending result 1 debug3: mm_request_send: entering, type 13 Accepted password for maxime from 127.0.0.1 port 37054 ssh2 debug1: monitor_child_preauth: user maxime authenticated by privileged process debug3: mm_get_keystate: Waiting for new keys debug3: mm_request_receive_expect: entering, type 26 debug3: mm_request_receive: entering debug3: mm_get_keystate: GOT new keys debug3: mm_auth_password: user authenticated [preauth] debug3: user_specific_delay: user specific delay 0.000ms [preauth] debug3: ensure_minimum_time_since: elapsed 27.344ms, delaying 4.980ms (requested 8.081ms) [preauth] debug3: send packet: type 52 [preauth] debug3: mm_request_send: entering, type 26 [preauth] debug3: mm_send_keystate: Finished sending state [preauth] debug1: monitor_read_log: child log fd closed User child is on pid 86788 debug1: permanently_set_uid: 1000/1000 debug3: monitor_apply_keystate: packet_set_state debug2: ssh_set_newkeys: mode 0 debug1: rekey in after 134217728 blocks debug2: ssh_set_newkeys: mode 1 debug1: rekey out after 134217728 blocks debug1: ssh_packet_set_postauth: called debug3: ssh_packet_set_state: done debug3: notify_hostkeys: key 0: ecdsa-sha2-nistp256 SHA256:YkIO1IvDg3w8IaG+jWWJ8qSL5dr/NTZ+4xAA0Wau5Fc debug3: notify_hostkeys: key 1: ecdsa-sha2-nistp521 SHA256:3jTqlIIrC33dsPwveXAP2Qqi24vo9Olaq2M1WIA+A3I debug3: notify_hostkeys: sent 2 hostkeys debug3: send packet: type 80 debug1: active: key options: agent-forwarding port-forwarding pty user-rc x11-forwarding debug1: Entering interactive session for SSH2. debug1: server_init_dispatch debug3: receive packet: type 90 debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max 16384 debug1: input_session_request debug1: channel 0: new session [server-session] (inactive timeout: 0) debug2: session_new: allocate (allocated 0 max 10) debug3: session_unused: session id 0 unused debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug3: send packet: type 91 debug3: receive packet: type 80 debug1: server_input_global_request: rtype no-more-sessions at openssh.com want_reply 0 debug3: receive packet: type 80 debug1: server_input_global_request: rtype hostkeys-prove-00 at openssh.com want_reply 1 debug3: server_input_hostkeys_prove: sign ECDSA key (index 1) using sigalg default debug3: mm_sshkey_sign: entering debug3: mm_request_send: entering, type 6 debug3: mm_sshkey_sign: waiting for MONITOR_ANS_SIGN debug3: mm_request_receive: entering debug3: mm_request_receive_expect: entering, type 7 debug3: monitor_read: checking request 6 debug3: mm_request_receive: entering debug3: mm_answer_sign: entering debug1: mm_answer_sign: hostkey ecdsa-sha2-nistp521 index 1 mm_answer_sign: agent sign: invalid argument debug1: do_cleanup debug3: mm_request_receive: monitor fd closed debug1: do_cleanup -------------- next part -------------- ~ Projects/Dev/openssh-portable/ssh 127.0.0.1 -vvv OpenSSH_9.9p1, OpenSSL 3.3.2 3 Sep 2024 debug1: Reading configuration data /usr/local/etc/ssh_config debug3: /usr/local/etc/ssh_config line 2: Including file /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf depth 0 debug1: Reading configuration data /etc/ssh/ssh_config.d/20-systemd-ssh-proxy.conf debug2: resolve_canonicalize: hostname 127.0.0.1 is address debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts' -> '/home/maxime/.ssh/known_hosts' debug3: expanded UserKnownHostsFile '~/.ssh/known_hosts2' -> '/home/maxime/.ssh/known_hosts2' debug1: Authenticator provider $SSH_SK_PROVIDER did not resolve; disabling debug3: channel_clear_timeouts: clearing debug3: ssh_connect_direct: entering debug1: Connecting to 127.0.0.1 [127.0.0.1] port 22. debug3: set_sock_tos: set socket 3 IP_TOS 0x48 debug1: Connection established. debug1: identity file /home/maxime/.ssh/id_rsa type -1 debug1: identity file /home/maxime/.ssh/id_rsa-cert type -1 debug1: identity file /home/maxime/.ssh/id_ecdsa type -1 debug1: identity file /home/maxime/.ssh/id_ecdsa-cert type -1 debug1: identity file /home/maxime/.ssh/id_ecdsa_sk type -1 debug1: identity file /home/maxime/.ssh/id_ecdsa_sk-cert type -1 debug1: identity file /home/maxime/.ssh/id_ed25519 type 3 debug1: identity file /home/maxime/.ssh/id_ed25519-cert type -1 debug1: identity file /home/maxime/.ssh/id_ed25519_sk type -1 debug1: identity file /home/maxime/.ssh/id_ed25519_sk-cert type -1 debug1: identity file /home/maxime/.ssh/id_xmss type -1 debug1: identity file /home/maxime/.ssh/id_xmss-cert type -1 debug1: Local version string SSH-2.0-OpenSSH_9.9 debug1: Remote protocol version 2.0, remote software version OpenSSH_9.9 debug1: compat_banner: match: OpenSSH_9.9 pat OpenSSH* compat 0x04000000 debug2: fd 3 setting O_NONBLOCK debug1: Authenticating to 127.0.0.1:22 as 'maxime' debug1: load_hostkeys: fopen /home/maxime/.ssh/known_hosts: No such file or directory debug1: load_hostkeys: fopen /home/maxime/.ssh/known_hosts2: No such file or directory debug1: load_hostkeys: fopen /usr/local/etc/ssh_known_hosts: No such file or directory debug1: load_hostkeys: fopen /usr/local/etc/ssh_known_hosts2: No such file or directory debug3: order_hostkeyalgs: no algorithms matched; accept original debug3: send packet: type 20 debug1: SSH2_MSG_KEXINIT sent debug3: receive packet: type 20 debug1: SSH2_MSG_KEXINIT received debug2: local client KEXINIT proposal debug2: KEX algorithms: mlkem768x25519-sha256,sntrup761x25519-sha512,sntrup761x25519-sha512 at openssh.com,curve25519-sha256,curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,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 at openssh.com debug2: host key algorithms: ssh-ed25519-cert-v01 at openssh.com,ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,sk-ssh-ed25519-cert-v01 at openssh.com,sk-ecdsa-sha2-nistp256-cert-v01 at openssh.com,rsa-sha2-512-cert-v01 at openssh.com,rsa-sha2-256-cert-v01 at openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25519 at openssh.com,sk-ecdsa-sha2-nistp256 at openssh.com,rsa-sha2-512,rsa-sha2-256 debug2: ciphers ctos: chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com debug2: ciphers stoc: chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com debug2: MACs ctos: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: MACs stoc: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: compression ctos: none,zlib at openssh.com debug2: compression stoc: none,zlib at openssh.com debug2: languages ctos: debug2: languages stoc: debug2: first_kex_follows 0 debug2: reserved 0 debug2: peer server KEXINIT proposal debug2: KEX algorithms: mlkem768x25519-sha256,sntrup761x25519-sha512,sntrup761x25519-sha512 at openssh.com,curve25519-sha256,curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,ext-info-s,kex-strict-s-v00 at openssh.com debug2: host key algorithms: ecdsa-sha2-nistp256,ecdsa-sha2-nistp521 debug2: ciphers ctos: chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com debug2: ciphers stoc: chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com debug2: MACs ctos: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: MACs stoc: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: compression ctos: none,zlib at openssh.com debug2: compression stoc: none,zlib at openssh.com debug2: languages ctos: debug2: languages stoc: debug2: first_kex_follows 0 debug2: reserved 0 debug3: kex_choose_conf: will use strict KEX ordering debug1: kex: algorithm: mlkem768x25519-sha256 debug1: kex: host key algorithm: ecdsa-sha2-nistp256 debug1: kex: server->client cipher: chacha20-poly1305 at openssh.com MAC: compression: none debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com MAC: compression: none debug3: send packet: type 30 debug1: expecting SSH2_MSG_KEX_ECDH_REPLY debug3: receive packet: type 31 debug1: SSH2_MSG_KEX_ECDH_REPLY received debug1: Server host key: ecdsa-sha2-nistp256 SHA256:YkIO1IvDg3w8IaG+jWWJ8qSL5dr/NTZ+4xAA0Wau5Fc debug1: load_hostkeys: fopen /home/maxime/.ssh/known_hosts: No such file or directory debug1: load_hostkeys: fopen /home/maxime/.ssh/known_hosts2: No such file or directory debug1: load_hostkeys: fopen /usr/local/etc/ssh_known_hosts: No such file or directory debug1: load_hostkeys: fopen /usr/local/etc/ssh_known_hosts2: No such file or directory debug3: hostkeys_find_by_key_hostfile: trying user hostfile "/home/maxime/.ssh/known_hosts" debug1: hostkeys_find_by_key_hostfile: hostkeys file /home/maxime/.ssh/known_hosts does not exist debug3: hostkeys_find_by_key_hostfile: trying user hostfile "/home/maxime/.ssh/known_hosts2" debug1: hostkeys_find_by_key_hostfile: hostkeys file /home/maxime/.ssh/known_hosts2 does not exist debug3: hostkeys_find_by_key_hostfile: trying system hostfile "/usr/local/etc/ssh_known_hosts" debug1: hostkeys_find_by_key_hostfile: hostkeys file /usr/local/etc/ssh_known_hosts does not exist debug3: hostkeys_find_by_key_hostfile: trying system hostfile "/usr/local/etc/ssh_known_hosts2" debug1: hostkeys_find_by_key_hostfile: hostkeys file /usr/local/etc/ssh_known_hosts2 does not exist The authenticity of host '127.0.0.1 (127.0.0.1)' can't be established. ECDSA key fingerprint is SHA256:YkIO1IvDg3w8IaG+jWWJ8qSL5dr/NTZ+4xAA0Wau5Fc. This key is not known by any other names. Are you sure you want to continue connecting (yes/no/[fingerprint])? yes Warning: Permanently added '127.0.0.1' (ECDSA) to the list of known hosts. debug3: send packet: type 21 debug1: ssh_packet_send2_wrapped: resetting send seqnr 3 debug2: ssh_set_newkeys: mode 1 debug1: rekey out after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: Sending SSH2_MSG_EXT_INFO debug3: send packet: type 7 debug1: expecting SSH2_MSG_NEWKEYS debug3: receive packet: type 21 debug1: ssh_packet_read_poll2: resetting read seqnr 3 debug1: SSH2_MSG_NEWKEYS received debug2: ssh_set_newkeys: mode 0 debug1: rekey in after 134217728 blocks debug2: KEX algorithms: mlkem768x25519-sha256,sntrup761x25519-sha512,sntrup761x25519-sha512 at openssh.com,curve25519-sha256,curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,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 at openssh.com debug2: host key algorithms: ssh-ed25519-cert-v01 at openssh.com,ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,sk-ssh-ed25519-cert-v01 at openssh.com,sk-ecdsa-sha2-nistp256-cert-v01 at openssh.com,rsa-sha2-512-cert-v01 at openssh.com,rsa-sha2-256-cert-v01 at openssh.com,ssh-ed25519,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,sk-ssh-ed25519 at openssh.com,sk-ecdsa-sha2-nistp256 at openssh.com,rsa-sha2-512,rsa-sha2-256 debug2: ciphers ctos: chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com debug2: ciphers stoc: chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com debug2: MACs ctos: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: MACs stoc: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1 debug2: compression ctos: none,zlib at openssh.com debug2: compression stoc: none,zlib at 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 7 debug1: SSH2_MSG_EXT_INFO received debug3: kex_input_ext_info: extension server-sig-algs debug1: kex_ext_info_client_parse: server-sig-algs= debug3: kex_input_ext_info: extension publickey-hostbound at openssh.com debug1: kex_ext_info_check_ver: publickey-hostbound at openssh.com=<0> debug3: kex_input_ext_info: extension ping at openssh.com debug1: kex_ext_info_check_ver: ping at openssh.com=<0> 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 7 debug1: SSH2_MSG_EXT_INFO received debug3: kex_input_ext_info: extension server-sig-algs debug1: kex_ext_info_client_parse: server-sig-algs= debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,password,keyboard-interactive debug3: start over, passed a different list publickey,password,keyboard-interactive 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 debug1: Will attempt key: /home/maxime/.ssh/id_rsa debug1: Will attempt key: /home/maxime/.ssh/id_ecdsa debug1: Will attempt key: /home/maxime/.ssh/id_ecdsa_sk debug1: Will attempt key: /home/maxime/.ssh/id_ed25519 ED25519 SHA256:19J+iR0fmy8ExjxEopqcxD5iaa9u71VZ1+LeJx1Mr/A debug1: Will attempt key: /home/maxime/.ssh/id_ed25519_sk debug1: Will attempt key: /home/maxime/.ssh/id_xmss debug2: pubkey_prepare: done debug1: Trying private key: /home/maxime/.ssh/id_rsa debug3: no such identity: /home/maxime/.ssh/id_rsa: No such file or directory debug1: Trying private key: /home/maxime/.ssh/id_ecdsa debug3: no such identity: /home/maxime/.ssh/id_ecdsa: No such file or directory debug1: Trying private key: /home/maxime/.ssh/id_ecdsa_sk debug3: no such identity: /home/maxime/.ssh/id_ecdsa_sk: No such file or directory debug1: Offering public key: /home/maxime/.ssh/id_ed25519 ED25519 SHA256:19J+iR0fmy8ExjxEopqcxD5iaa9u71VZ1+LeJx1Mr/A debug3: send packet: type 50 debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,password,keyboard-interactive debug1: Trying private key: /home/maxime/.ssh/id_ed25519_sk debug3: no such identity: /home/maxime/.ssh/id_ed25519_sk: No such file or directory debug1: Trying private key: /home/maxime/.ssh/id_xmss debug3: no such identity: /home/maxime/.ssh/id_xmss: No such file or directory debug2: we did not send a packet, disable method debug3: authmethod_lookup keyboard-interactive debug3: remaining preferred: password debug3: authmethod_is_enabled keyboard-interactive debug1: Next authentication method: keyboard-interactive debug2: userauth_kbdint debug3: send packet: type 50 debug2: we sent a keyboard-interactive packet, wait for reply debug3: receive packet: type 51 debug1: Authentications that can continue: publickey,password,keyboard-interactive debug3: userauth_kbdint: disable: no info_req_seen debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: debug3: authmethod_is_enabled password debug1: Next authentication method: password maxime at 127.0.0.1's password: debug3: send packet: type 50 debug2: we sent a password packet, wait for reply debug3: receive packet: type 52 Authenticated to 127.0.0.1 ([127.0.0.1]:22) using "password". debug1: channel 0: new session [client-session] (inactive timeout: 0) debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug3: send packet: type 90 debug1: Requesting no-more-sessions at openssh.com debug3: send packet: type 80 debug1: Entering interactive session. debug1: pledge: filesystem debug3: client_repledge: enter debug3: receive packet: type 80 debug1: client_input_global_request: rtype hostkeys-00 at openssh.com want_reply 0 debug3: client_input_hostkeys: received ECDSA key SHA256:YkIO1IvDg3w8IaG+jWWJ8qSL5dr/NTZ+4xAA0Wau5Fc debug3: client_input_hostkeys: received ECDSA key SHA256:3jTqlIIrC33dsPwveXAP2Qqi24vo9Olaq2M1WIA+A3I debug1: client_input_hostkeys: searching /home/maxime/.ssh/known_hosts for 127.0.0.1 / (none) debug3: hostkeys_foreach: reading file "/home/maxime/.ssh/known_hosts" debug3: hostkeys_find: found ecdsa-sha2-nistp256 key at /home/maxime/.ssh/known_hosts:1 debug1: client_input_hostkeys: searching /home/maxime/.ssh/known_hosts2 for 127.0.0.1 / (none) debug1: client_input_hostkeys: hostkeys file /home/maxime/.ssh/known_hosts2 does not exist debug3: client_input_hostkeys: 2 server keys: 1 new, 0 retained, 1 incomplete match. 0 to remove debug3: client_input_hostkeys: asking server to prove ownership for 1 keys debug3: send packet: type 80 debug3: receive packet: type 91 debug2: channel_input_open_confirmation: channel 0: callback start debug2: fd 3 setting TCP_NODELAY debug3: set_sock_tos: set socket 3 IP_TOS 0x48 debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 1 debug3: send packet: type 98 debug2: channel 0: request shell confirm 1 debug3: send packet: type 98 debug3: client_repledge: enter debug2: channel_input_open_confirmation: channel 0: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 Read from remote host 127.0.0.1: Connection reset by peer Connection to 127.0.0.1 closed. debug3: send packet: type 1 client_loop: send disconnect: Broken pipe From amballip at gmail.com Sun Nov 3 01:21:04 2024 From: amballip at gmail.com (Preetish Amballi) Date: Sat, 2 Nov 2024 19:51:04 +0530 Subject: [PATCH] Memory leak fixed - when lauched as non-root user When we lauch sshd as non-root user, its still able to load public keys but fails to load private keys. So before exiting free the memory allocated for the public key In-Reply-To: <20241025141428.25785-1-amballip@gmail.com> References: <20241025141428.25785-1-amballip@gmail.com> Message-ID: Hi Team, Any update on this patch? Regards, Preetish On Fri, 25 Oct 2024 at 19:44, Preetish Amballi wrote: > --- > sshd.c | 2 ++ > 1 file changed, 2 insertions(+) > > diff --git a/sshd.c b/sshd.c > index dda8d9b77..cbdced5db 100644 > --- a/sshd.c > +++ b/sshd.c > @@ -1533,6 +1533,8 @@ main(int ac, char **av) > } else { > do_log2(ll, "Unable to load host key: %s", > options.host_key_files[i]); > + sshkey_free(pubkey); > + pubkey = NULL; > sensitive_data.host_keys[i] = NULL; > sensitive_data.host_pubkeys[i] = NULL; > continue; > -- > 2.45.2 > > From rapier at psc.edu Thu Nov 7 08:45:01 2024 From: rapier at psc.edu (Chris Rapier) Date: Wed, 6 Nov 2024 16:45:01 -0500 Subject: ssh compat information Message-ID: <4650e971-0c05-4967-8ead-44466c00b3c7@psc.edu> I think I know the answer to this (which would be that you can't) but is there any not entirely insane way to get the ssh->compat information back to either scp or sftp? I'm doing some extensions on scp (and eventually sftp) and having remote version or capability information would be helpful. Chris From djm at mindrot.org Thu Nov 7 12:07:08 2024 From: djm at mindrot.org (Damien Miller) Date: Thu, 7 Nov 2024 12:07:08 +1100 (AEDT) Subject: ssh compat information In-Reply-To: <4650e971-0c05-4967-8ead-44466c00b3c7@psc.edu> References: <4650e971-0c05-4967-8ead-44466c00b3c7@psc.edu> Message-ID: <542acd5d-5fac-0b0e-b2f9-f1f127bfa79c@mindrot.org> On Wed, 6 Nov 2024, Chris Rapier wrote: > I think I know the answer to this (which would be that you can't) but is there > any not entirely insane way to get the ssh->compat information back to either > scp or sftp? There's no way at present. > I'm doing some extensions on scp (and eventually sftp) and having remote > version or capability information would be helpful. IMO it would be easier for SFTP, as the protocol has an explicit extension mechanism. If you're prepared to trust this mechanism to make assertions about the SSH channel the SFTP session is running over, then it would be very easy to wire it up to make changes to buffer sizes, the number of requests in flight, etc. as these are already configurable. -d From rapier at psc.edu Fri Nov 8 02:52:48 2024 From: rapier at psc.edu (Chris Rapier) Date: Thu, 7 Nov 2024 10:52:48 -0500 Subject: ssh compat information In-Reply-To: <542acd5d-5fac-0b0e-b2f9-f1f127bfa79c@mindrot.org> References: <4650e971-0c05-4967-8ead-44466c00b3c7@psc.edu> <542acd5d-5fac-0b0e-b2f9-f1f127bfa79c@mindrot.org> Message-ID: <99ecf284-ab2e-403d-91fe-d909f5108ea6@psc.edu> On 11/6/24 8:07 PM, Damien Miller wrote: > On Wed, 6 Nov 2024, Chris Rapier wrote: > >> I think I know the answer to this (which would be that you can't) but is there >> any not entirely insane way to get the ssh->compat information back to either >> scp or sftp? > > There's no way at present. That's what I thought. >> I'm doing some extensions on scp (and eventually sftp) and having remote >> version or capability information would be helpful. > > IMO it would be easier for SFTP, as the protocol has an explicit > extension mechanism. If you're prepared to trust this mechanism > to make assertions about the SSH channel the SFTP session is > running over, then it would be very easy to wire it up to make > changes to buffer sizes, the number of requests in flight, etc. > as these are already configurable. I'll be looking into that. The background is that a few year ago I introduced a method to restart failed transfers in HPN-SSH. Some of the people I'm dealing with are moving files that are 10s of GB in size so anything that can reduce the retransmission of already received data can be helpful. It's similar to rsync in that we use hashes to determine if the file fragment (assuming that the transfer cut out mid-file) is identical to the corresponding fragment on the source side. If it is then we start the transfer from the last received byte and append to the destination. I had been using Blake2b512 for the hashing algorithm but I want to put in a path to use xxhash instead. Maintaining backward compatibility means I need to know something about the remote. Hence, the question. I think I have an idea that might work but it's hacky. Alternatively, I can just break compatibility as I am not convinced a lot of people use this function in its current state. Especially being that people should just use rsync :) Also, the work required to do this in SCP really helped my understand why you want to stop supporting SCP. Chris From dtucker at dtucker.net Fri Nov 8 03:14:58 2024 From: dtucker at dtucker.net (Darren Tucker) Date: Thu, 7 Nov 2024 08:14:58 -0800 Subject: ssh compat information In-Reply-To: <99ecf284-ab2e-403d-91fe-d909f5108ea6@psc.edu> References: <4650e971-0c05-4967-8ead-44466c00b3c7@psc.edu> <542acd5d-5fac-0b0e-b2f9-f1f127bfa79c@mindrot.org> <99ecf284-ab2e-403d-91fe-d909f5108ea6@psc.edu> Message-ID: On Thu, 7 Nov 2024 at 07:55, Chris Rapier wrote: >[...]I had been using > Blake2b512 for the hashing algorithm but I want to put in a path to use > xxhash instead. Maintaining backward compatibility means I need to know > something about the remote. In the case of sftp at least, that sounds like a function of the sftp-server not sshd, in which case could you advertise the capability as an sftp extension? (look for the SSH2_FXP_VERSION handling) -- Darren Tucker (dtucker at dtucker.net) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dgl at dgl.cx Fri Nov 8 09:06:12 2024 From: dgl at dgl.cx (David Leadbeater) Date: Fri, 8 Nov 2024 09:06:12 +1100 Subject: ssh compat information In-Reply-To: References: <4650e971-0c05-4967-8ead-44466c00b3c7@psc.edu> <542acd5d-5fac-0b0e-b2f9-f1f127bfa79c@mindrot.org> <99ecf284-ab2e-403d-91fe-d909f5108ea6@psc.edu> Message-ID: On Fri, 8 Nov 2024 at 03:16, Darren Tucker wrote: > > On Thu, 7 Nov 2024 at 07:55, Chris Rapier wrote: > >[...]I had been using > > Blake2b512 for the hashing algorithm but I want to put in a path to use > > xxhash instead. Maintaining backward compatibility means I need to know > > something about the remote. Could you use the already (draft) specified sftp check-file extension[1] for this? It takes a comma separated list of algorithms and the server picks the first it supports. David [1]: https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-extensions-00#section-3 From rapier at psc.edu Tue Nov 12 03:13:42 2024 From: rapier at psc.edu (Chris Rapier) Date: Mon, 11 Nov 2024 11:13:42 -0500 Subject: ssh compat information In-Reply-To: References: <4650e971-0c05-4967-8ead-44466c00b3c7@psc.edu> <542acd5d-5fac-0b0e-b2f9-f1f127bfa79c@mindrot.org> <99ecf284-ab2e-403d-91fe-d909f5108ea6@psc.edu> Message-ID: <4e60c132-8ee6-4a18-8326-37d7746ce3a7@psc.edu> On 11/7/24 5:06 PM, David Leadbeater wrote: > On Fri, 8 Nov 2024 at 03:16, Darren Tucker wrote: >> >> On Thu, 7 Nov 2024 at 07:55, Chris Rapier wrote: >>> [...]I had been using >>> Blake2b512 for the hashing algorithm but I want to put in a path to use >>> xxhash instead. Maintaining backward compatibility means I need to know >>> something about the remote. > > Could you use the already (draft) specified sftp check-file > extension[1] for this? > > It takes a comma separated list of algorithms and the server picks the > first it supports. > > David > > [1]: https://datatracker.ietf.org/doc/html/draft-ietf-secsh-filexfer-extensions-00#section-3 It's possible that this could work very well. Is there a reference implementation? If not I can still use SSH_FXP_EXTENDED as described in the draft as I'm assuming if I send an unknown request type to the server I'll get a null/empty/whatever response. As an aside, this implementation would not fully meet the implementation requirements of the draft but as I'm not sure I'll have the bandwidth to implement all of the required hashes but It would be a reasonable basis for it. Chris From anctop at gmail.com Tue Nov 12 23:39:42 2024 From: anctop at gmail.com (anctop) Date: Tue, 12 Nov 2024 20:39:42 +0800 Subject: openssh-9.9p1 problem with faillock pam module Message-ID: Dear developers, Our server implements two SSH services on ports 22 & 8022, with different PAM settings. The daemon is built from source of OpenSSH portable releases. Following the instructions in the INSTALL file, we made a copy of "/sbin/sshd" (for port 22) as "/sbin/sshd2" (for port 8022), created a separate "sshd2_config" file, and added corresponding commands for service "sshd2" in "/etc/pam.conf". We use the "faillock" PAM module with tally directories "/etc/security/sshd" and "/etc/security/sshd2" for "sshd" and "sshd2" respectively. This approach worked well for release 9.3p1, but a problem is identified with release 9.9p1. Normally when a user logs in via "ssh -p 8022 @", his tally "/etc/security/sshd2/" will be updated. However, running release 9.9p1, it is found that the tally "/etc/security/sshd/" is updated instead. We have also tried to rebuild a binary for "sshd2" with the option "--with-pam-service=sshd2", but it did not help. It seems that release 9.9p1 does not use the binary filename as the PAM service name, but sticks to "sshd" for all instances. Please kindly advise. From b.candler at pobox.com Tue Nov 12 23:52:41 2024 From: b.candler at pobox.com (Brian Candler) Date: Tue, 12 Nov 2024 12:52:41 +0000 Subject: openssh-9.9p1 problem with faillock pam module In-Reply-To: References: Message-ID: <70aadcdc-0669-4f00-aec0-70a6cef93e3a@pobox.com> On 12/11/2024 12:39, anctop wrote: > It seems that release 9.9p1 does not use the binary filename as the > PAM service name, but sticks to "sshd" for all instances. man sshd_config: ???? PAMServiceName ???????????? Specifies the service name used for Pluggable Authentication Modules (PAM) authentication, authorisation and session controls when ???????????? UsePAM is enabled.? The default is sshd. Does this help? From anctop at gmail.com Wed Nov 13 00:11:04 2024 From: anctop at gmail.com (anctop) Date: Tue, 12 Nov 2024 21:11:04 +0800 Subject: openssh-9.9p1 problem with faillock pam module In-Reply-To: <70aadcdc-0669-4f00-aec0-70a6cef93e3a@pobox.com> References: <70aadcdc-0669-4f00-aec0-70a6cef93e3a@pobox.com> Message-ID: Hi, Many thanks for your prompt answer. We overlooked this new option because it was not available in the 9.3p1 config. On Tue, 12 Nov 2024 at 20:52, Brian Candler wrote: > > On 12/11/2024 12:39, anctop wrote: > > It seems that release 9.9p1 does not use the binary filename as the > PAM service name, but sticks to "sshd" for all instances. > > man sshd_config: > > PAMServiceName > Specifies the service name used for Pluggable Authentication Modules (PAM) authentication, authorisation and session controls when > UsePAM is enabled. The default is sshd. > > Does this help? From b.candler at pobox.com Wed Nov 13 00:47:35 2024 From: b.candler at pobox.com (Brian Candler) Date: Tue, 12 Nov 2024 13:47:35 +0000 Subject: openssh-9.9p1 problem with faillock pam module In-Reply-To: References: <70aadcdc-0669-4f00-aec0-70a6cef93e3a@pobox.com> Message-ID: <77ad7584-62df-4d88-ac12-596fb92391e3@pobox.com> It's always worth checking the release notes for intervening versions when upgrading, as behaviour can change. https://www.openssh.com/releasenotes.html This particular change is mentioned in the release notes for 9.8, under the heading "Potentially-incompatible changes" *sshd(8) : (portable OpenSSH only) sshd will no longer use argv[0] as the PAM service name. A new "PAMServiceName"sshd_config(5) directive allows selecting the service name at runtime. This defaults to "sshd".bz2101 From maximejeanrey at gmail.com Wed Nov 13 04:50:18 2024 From: maximejeanrey at gmail.com (maximejeanrey at gmail.com) Date: Tue, 12 Nov 2024 18:50:18 +0100 Subject: [PATCH 1/2] Add test to cover multiple server hostkeys with agent In-Reply-To: <20241112175019.52344-1-maximejeanrey@gmail.com> References: <20241112175019.52344-1-maximejeanrey@gmail.com> Message-ID: <20241112175019.52344-2-maximejeanrey@gmail.com> From: Maxime Rey This tests the hostkey-prove mechanism in sshd when provided with multiple host keys managed by the agent --- regress/hostkey-agent.sh | 31 +++++++++++++++++++++++++++++++ 1 file changed, 31 insertions(+) diff --git a/regress/hostkey-agent.sh b/regress/hostkey-agent.sh index 222d424bd..3fa80655e 100644 --- a/regress/hostkey-agent.sh +++ b/regress/hostkey-agent.sh @@ -82,6 +82,37 @@ for k in $SSH_CERTTYPES ; do fi done +# Run sshd with multiple keys handeled by agent + +cp $OBJ/sshd_proxy.orig $OBJ/sshd_proxy + +mv $OBJ/ssh_proxy $OBJ/ssh_proxy.orig +grep -vi 'globalknownhostsfile' $OBJ/ssh_proxy.orig > $OBJ/ssh_proxy +echo "UpdateHostkeys=yes" >> $OBJ/ssh_proxy +echo "GlobalKnownHostsFile=none" >> $OBJ/ssh_proxy + +read -p "Doing the multiple keys (y/n)? " answer +for k in $SSH_KEYTYPES ; do + verbose "Addkey type $k" + echo "Hostkey $OBJ/agent-key.${k}" >> $OBJ/sshd_proxy + + ( printf 'localhost-with-alias ' ; + cat $OBJ/agent-key.$k.pub) > $OBJ/known_hosts +done + +opts="-oStrictHostKeyChecking=yes -F $OBJ/ssh_proxy" +SSH_CONNECTION=`${SSH} $opts host 'echo $SSH_CONNECTION'` + +if [ $? -ne 0 ]; then + fail "Hostkeys-prove error. Unable to proceed" +fi +if [ "$SSH_CONNECTION" != "UNKNOWN 65535 UNKNOWN 65535" ]; then + fail "bad SSH_CONNECTION key type $k" +fi + + +read -p "End (y/n)? " answer + trace "kill agent" ${SSHAGENT} -k > /dev/null -- 2.47.0 From maximejeanrey at gmail.com Wed Nov 13 04:50:17 2024 From: maximejeanrey at gmail.com (maximejeanrey at gmail.com) Date: Tue, 12 Nov 2024 18:50:17 +0100 Subject: [PATCH 0/2] Specify signature algorithm during server hostkeys prove Message-ID: <20241112175019.52344-1-maximejeanrey@gmail.com> From: Maxime Rey Hello, I've discovered an issue with sshd when it's configured to use the SSH agent alongside multiple host keys. Specifically, this problem happens during the hostkeys-prove-00 at openssh.com request, when the server attempts to demonstrate ownership of the host keys by calling the agent. The issue occurs because, while processing the hostkeys-prove-00 at openssh.com request, sshd does not specify the signature algorithm in its call to the agent. As a result, when sshd attempts to verify the response, it encounters an error due to the missing algorithm specification. To address this, I have made two contributions: 1 - A modified hostkey-agent.sh regression test that reproduces the issue under these conditions. 2 - A patch in serverloop.c to correct the error by ensuring the algorithm is explicitly specified during the hostkeys-prove-00 at openssh.com response. Thank you for your time and feedback. Best regards, Maxime Maxime Rey (2): Add test to cover multiple server hostkeys with agent Specify signature algorithm during server hostkeys prove regress/hostkey-agent.sh | 31 +++++++++++++++++++++++++++++++ serverloop.c | 3 +++ 2 files changed, 34 insertions(+) -- 2.47.0 From maximejeanrey at gmail.com Wed Nov 13 04:50:19 2024 From: maximejeanrey at gmail.com (maximejeanrey at gmail.com) Date: Tue, 12 Nov 2024 18:50:19 +0100 Subject: [PATCH 2/2] Specify signature algorithm during server hostkeys prove In-Reply-To: <20241112175019.52344-1-maximejeanrey@gmail.com> References: <20241112175019.52344-1-maximejeanrey@gmail.com> Message-ID: <20241112175019.52344-3-maximejeanrey@gmail.com> From: Maxime Rey Set sigalg to the correct key algorithm for every key type. This allow sshd to verify the signing algorithm used by ssh-agent during the hostkey-prove. --- serverloop.c | 3 +++ 1 file changed, 3 insertions(+) diff --git a/serverloop.c b/serverloop.c index 757cc6f02..4ef7998cb 100644 --- a/serverloop.c +++ b/serverloop.c @@ -699,6 +699,9 @@ server_input_hostkeys_prove(struct ssh *ssh, struct sshbuf **respp) else if (ssh->kex->flags & KEX_RSA_SHA2_256_SUPPORTED) sigalg = "rsa-sha2-256"; } + else + sigalg = sshkey_ssh_name(key); + debug3_f("sign %s key (index %d) using sigalg %s", sshkey_type(key), ndx, sigalg == NULL ? "default" : sigalg); if ((r = sshbuf_put_cstring(sigbuf, -- 2.47.0 From ra at ra.is Sat Nov 16 02:48:11 2024 From: ra at ra.is (Richard Allen) Date: Fri, 15 Nov 2024 15:48:11 +0000 (GMT) Subject: MFA and PubKeys Message-ID: <588897269.1200.1731685691413.JavaMail.zimbra@ra.is> Hello all, I'm trying to get a properly working MFA solution working with our ssh servers. I have it working wonderfully well with duo until ssh keys are added to the mix. As I understand it, using keys results in the PAM stack not getting called and thus something like pam_duo never get's a chance to work in that scenario. I'm aware that I can use something like "ForceCommand /usr/sbin/login_duo" but that results in two requests unless it is removed from PAM beforehand which is not ideal as there are other services that also benefit from having MFA present in the PAM stack. Using ForceCommand like this is also dubious as users can still put whatever they like in their shell rc files. Is there a better way to properly integrate MFA into the login process when ssh keys are used? Thanks in advance. -- Rikki From b.candler at pobox.com Sat Nov 16 02:54:23 2024 From: b.candler at pobox.com (Brian Candler) Date: Fri, 15 Nov 2024 15:54:23 +0000 Subject: MFA and PubKeys In-Reply-To: <588897269.1200.1731685691413.JavaMail.zimbra@ra.is> References: <588897269.1200.1731685691413.JavaMail.zimbra@ra.is> Message-ID: On 15/11/2024 15:48, Richard Allen via openssh-unix-dev wrote: > As I understand it, using keys results in the PAM stack not getting > called and thus something like pam_duo never get's a chance to work in > that scenario. No, it depends on how you configure sshd. You can require both ssh key auth and PAM auth: |AuthenticationMethods publickey,keyboard-interactive:pam| (Note that the methods must be comma-separated, not space-separated, to require both). I don't know about integrating with Duo, but I've it with TOTP from Vault: https://github.com/candlerb/vault-totp-helper From morten at linderud.pw Sun Nov 24 02:37:19 2024 From: morten at linderud.pw (Morten Linderud) Date: Sat, 23 Nov 2024 16:37:19 +0100 Subject: [PATCH] sshsig: check hashalg before selecting the RSA signature algorithm In-Reply-To: <20240411191640.2280049-1-morten@linderud.pw> References: <20240411191640.2280049-1-morten@linderud.pw> Message-ID: Hi, I sent this patch back inn april and I still have a need for this. Would it be possible to get any pointers how we can have `hashalg` selectable by `ssh-keygen -Y`? -- Morten Linderud PGP: 9C02FF419FECBE16 On Thu, Apr 11, 2024 at 09:16:39PM +0200, Morten Linderud wrote: > `ssh-keygen -Y sign` only selects the signing algorithm `rsa-sha2-512` > and this prevents ssh-agent implementations that can't support sha512 > from signing messages. > > An example of this is TPMs which mostly only really supports sha256 > widely. > > This change enables `ssh-keygen -Y sign` to honor the `hashalg` option > for the signing algorithm. > > Signed-off-by: Morten Linderud > --- > sshsig.c | 10 ++++++++-- > 1 file changed, 8 insertions(+), 2 deletions(-) > > diff --git a/sshsig.c b/sshsig.c > index 470b286a3..033b43353 100644 > --- a/sshsig.c > +++ b/sshsig.c > @@ -190,8 +190,14 @@ sshsig_wrap_sign(struct sshkey *key, const char *hashalg, > } > > /* If using RSA keys then default to a good signature algorithm */ > - if (sshkey_type_plain(key->type) == KEY_RSA) > - sign_alg = RSA_SIGN_ALG; > + if (sshkey_type_plain(key->type) == KEY_RSA){ > + if (hashalg == NULL) > + sign_alg = RSA_SIGN_ALG; > + else if (strcmp(hashalg, "sha256") == 0) > + sign_alg = "rsa-sha2-256"; > + else if (strcmp(hashalg, "sha512") == 0) > + sign_alg = "rsa-sha2-512"; > + } > > if (signer != NULL) { > if ((r = signer(key, &sig, &slen, > -- > 2.44.0 > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: From ronf at timeheart.net Sun Nov 24 02:55:17 2024 From: ronf at timeheart.net (Ron Frederick) Date: Sat, 23 Nov 2024 07:55:17 -0800 Subject: [PATCH] sshsig: check hashalg before selecting the RSA signature algorithm In-Reply-To: References: <20240411191640.2280049-1-morten@linderud.pw> Message-ID: <6C1EF1C7-A490-4CB6-865B-63991465FA07@timeheart.net> There is no hash algorithm associated with SSH keys. The key format for RSA keys is always ?ssh-rsa?, and it is capable of being used with any of the available signature algorithms (ssh-rsa for SHA-1 and rsa-sha2-256 or rsa-sha2-512 for SHA-2). See section 3 in https://www.rfc-editor.org/rfc/rfc8332: rsa-sha2-256 RECOMMENDED sign Raw RSA key rsa-sha2-512 OPTIONAL sign Raw RSA key These algorithms are suitable for use both in the SSH transport layer [RFC4253 ] for server authentication and in the authentication layer [RFC4252 ] for client authentication. Since RSA keys are not dependent on the choice of hash function, the new public key algorithms reuse the "ssh-rsa" public key format as defined in [RFC4253 ]: string "ssh-rsa" mpint e mpint n It is only RSA signature blobs that will show the new signature algorithm names. On Nov 23, 2024, at 7:37?AM, Morten Linderud wrote: > I sent this patch back inn april and I still have a need for this. Would it be > possible to get any pointers how we can have `hashalg` selectable by `ssh-keygen -Y`? > > -- > Morten Linderud > PGP: 9C02FF419FECBE16 > > On Thu, Apr 11, 2024 at 09:16:39PM +0200, Morten Linderud wrote: >> `ssh-keygen -Y sign` only selects the signing algorithm `rsa-sha2-512` >> and this prevents ssh-agent implementations that can't support sha512 >> from signing messages. >> >> An example of this is TPMs which mostly only really supports sha256 >> widely. >> >> This change enables `ssh-keygen -Y sign` to honor the `hashalg` option >> for the signing algorithm. >> >> Signed-off-by: Morten Linderud >> --- >> sshsig.c | 10 ++++++++-- >> 1 file changed, 8 insertions(+), 2 deletions(-) >> >> diff --git a/sshsig.c b/sshsig.c >> index 470b286a3..033b43353 100644 >> --- a/sshsig.c >> +++ b/sshsig.c >> @@ -190,8 +190,14 @@ sshsig_wrap_sign(struct sshkey *key, const char *hashalg, >> } >> >> /* If using RSA keys then default to a good signature algorithm */ >> - if (sshkey_type_plain(key->type) == KEY_RSA) >> - sign_alg = RSA_SIGN_ALG; >> + if (sshkey_type_plain(key->type) == KEY_RSA){ >> + if (hashalg == NULL) >> + sign_alg = RSA_SIGN_ALG; >> + else if (strcmp(hashalg, "sha256") == 0) >> + sign_alg = "rsa-sha2-256"; >> + else if (strcmp(hashalg, "sha512") == 0) >> + sign_alg = "rsa-sha2-512"; >> + } >> >> if (signer != NULL) { >> if ((r = signer(key, &sig, &slen, >> -- >> 2.44.0 -- Ron Frederick ronf at timeheart.net From morten at linderud.pw Sun Nov 24 03:15:48 2024 From: morten at linderud.pw (Morten Linderud) Date: Sat, 23 Nov 2024 17:15:48 +0100 Subject: [PATCH] sshsig: check hashalg before selecting the RSA signature algorithm In-Reply-To: <6C1EF1C7-A490-4CB6-865B-63991465FA07@timeheart.net> References: <20240411191640.2280049-1-morten@linderud.pw> <6C1EF1C7-A490-4CB6-865B-63991465FA07@timeheart.net> Message-ID: On Sat, Nov 23, 2024 at 07:55:17AM -0800, Ron Frederick wrote: > There is no hash algorithm associated with SSH keys. The key format for RSA keys is always ?ssh-rsa?, and it is capable of being used with any of the available signature algorithms (ssh-rsa for SHA-1 and rsa-sha2-256 or rsa-sha2-512 for SHA-2). > > See section 3 in https://www.rfc-editor.org/rfc/rfc8332: > > rsa-sha2-256 RECOMMENDED sign Raw RSA key > rsa-sha2-512 OPTIONAL sign Raw RSA key > > These algorithms are suitable for use both in the SSH transport layer > [RFC4253 ] for server authentication and in the authentication layer > [RFC4252 ] for client authentication. > > Since RSA keys are not dependent on the choice of hash function, the > new public key algorithms reuse the "ssh-rsa" public key format as > defined in [RFC4253 ]: > > string "ssh-rsa" > mpint e > mpint n > > It is only RSA signature blobs that will show the new signature algorithm names. I think this misunderstands the problem? The issue here is that for `ssh-keygen -Y` signatures with RSA keys the hashing algorithm is hardcoded to sha512 without any possibility to change this. > On Nov 23, 2024, at 7:37?AM, Morten Linderud wrote: > > I sent this patch back inn april and I still have a need for this. Would it be > > possible to get any pointers how we can have `hashalg` selectable by `ssh-keygen -Y`? > > > > -- > > Morten Linderud > > PGP: 9C02FF419FECBE16 > > > > On Thu, Apr 11, 2024 at 09:16:39PM +0200, Morten Linderud wrote: > >> `ssh-keygen -Y sign` only selects the signing algorithm `rsa-sha2-512` > >> and this prevents ssh-agent implementations that can't support sha512 > >> from signing messages. > >> > >> An example of this is TPMs which mostly only really supports sha256 > >> widely. > >> > >> This change enables `ssh-keygen -Y sign` to honor the `hashalg` option > >> for the signing algorithm. > >> > >> Signed-off-by: Morten Linderud > >> --- > >> sshsig.c | 10 ++++++++-- > >> 1 file changed, 8 insertions(+), 2 deletions(-) > >> > >> diff --git a/sshsig.c b/sshsig.c > >> index 470b286a3..033b43353 100644 > >> --- a/sshsig.c > >> +++ b/sshsig.c > >> @@ -190,8 +190,14 @@ sshsig_wrap_sign(struct sshkey *key, const char *hashalg, > >> } > >> > >> /* If using RSA keys then default to a good signature algorithm */ > >> - if (sshkey_type_plain(key->type) == KEY_RSA) > >> - sign_alg = RSA_SIGN_ALG; > >> + if (sshkey_type_plain(key->type) == KEY_RSA){ > >> + if (hashalg == NULL) > >> + sign_alg = RSA_SIGN_ALG; > >> + else if (strcmp(hashalg, "sha256") == 0) > >> + sign_alg = "rsa-sha2-256"; > >> + else if (strcmp(hashalg, "sha512") == 0) > >> + sign_alg = "rsa-sha2-512"; > >> + } > >> > >> if (signer != NULL) { > >> if ((r = signer(key, &sig, &slen, > >> -- > >> 2.44.0 > > -- > Ron Frederick > ronf at timeheart.net > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From djm at mindrot.org Wed Nov 27 08:25:15 2024 From: djm at mindrot.org (Damien Miller) Date: Wed, 27 Nov 2024 08:25:15 +1100 (AEDT) Subject: [PATCH] sshsig: check hashalg before selecting the RSA signature algorithm In-Reply-To: References: <20240411191640.2280049-1-morten@linderud.pw> Message-ID: <525c812a-dcae-e46c-09f8-cfb9f193f512@mindrot.org> Sorry, this now been committed and will be in openssh-10.0 On Sat, 23 Nov 2024, Morten Linderud wrote: > Hi, > > I sent this patch back inn april and I still have a need for this. Would it be > possible to get any pointers how we can have `hashalg` selectable by `ssh-keygen -Y`? > > -- > Morten Linderud > PGP: 9C02FF419FECBE16 > > On Thu, Apr 11, 2024 at 09:16:39PM +0200, Morten Linderud wrote: > > `ssh-keygen -Y sign` only selects the signing algorithm `rsa-sha2-512` > > and this prevents ssh-agent implementations that can't support sha512 > > from signing messages. > > > > An example of this is TPMs which mostly only really supports sha256 > > widely. > > > > This change enables `ssh-keygen -Y sign` to honor the `hashalg` option > > for the signing algorithm. > > > > Signed-off-by: Morten Linderud > > --- > > sshsig.c | 10 ++++++++-- > > 1 file changed, 8 insertions(+), 2 deletions(-) > > > > diff --git a/sshsig.c b/sshsig.c > > index 470b286a3..033b43353 100644 > > --- a/sshsig.c > > +++ b/sshsig.c > > @@ -190,8 +190,14 @@ sshsig_wrap_sign(struct sshkey *key, const char *hashalg, > > } > > > > /* If using RSA keys then default to a good signature algorithm */ > > - if (sshkey_type_plain(key->type) == KEY_RSA) > > - sign_alg = RSA_SIGN_ALG; > > + if (sshkey_type_plain(key->type) == KEY_RSA){ > > + if (hashalg == NULL) > > + sign_alg = RSA_SIGN_ALG; > > + else if (strcmp(hashalg, "sha256") == 0) > > + sign_alg = "rsa-sha2-256"; > > + else if (strcmp(hashalg, "sha512") == 0) > > + sign_alg = "rsa-sha2-512"; > > + } > > > > if (signer != NULL) { > > if ((r = signer(key, &sig, &slen, > > -- > > 2.44.0 > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From morten at linderud.pw Wed Nov 27 08:33:54 2024 From: morten at linderud.pw (Morten Linderud) Date: Tue, 26 Nov 2024 22:33:54 +0100 Subject: [PATCH] sshsig: check hashalg before selecting the RSA signature algorithm In-Reply-To: <525c812a-dcae-e46c-09f8-cfb9f193f512@mindrot.org> References: <20240411191640.2280049-1-morten@linderud.pw> <525c812a-dcae-e46c-09f8-cfb9f193f512@mindrot.org> Message-ID: Thank you! There is now two " XXX maybe make configurable " in the top of the file that is probably no longer relevant. Do you want a followup patch for that? Cheers, Morten Linderud On Wed, Nov 27, 2024 at 08:25:15AM +1100, Damien Miller wrote: > Sorry, this now been committed and will be in openssh-10.0 > > On Sat, 23 Nov 2024, Morten Linderud wrote: > > > Hi, > > > > I sent this patch back inn april and I still have a need for this. Would it be > > possible to get any pointers how we can have `hashalg` selectable by `ssh-keygen -Y`? > > > > -- > > Morten Linderud > > PGP: 9C02FF419FECBE16 > > > > On Thu, Apr 11, 2024 at 09:16:39PM +0200, Morten Linderud wrote: > > > `ssh-keygen -Y sign` only selects the signing algorithm `rsa-sha2-512` > > > and this prevents ssh-agent implementations that can't support sha512 > > > from signing messages. > > > > > > An example of this is TPMs which mostly only really supports sha256 > > > widely. > > > > > > This change enables `ssh-keygen -Y sign` to honor the `hashalg` option > > > for the signing algorithm. > > > > > > Signed-off-by: Morten Linderud > > > --- > > > sshsig.c | 10 ++++++++-- > > > 1 file changed, 8 insertions(+), 2 deletions(-) > > > > > > diff --git a/sshsig.c b/sshsig.c > > > index 470b286a3..033b43353 100644 > > > --- a/sshsig.c > > > +++ b/sshsig.c > > > @@ -190,8 +190,14 @@ sshsig_wrap_sign(struct sshkey *key, const char *hashalg, > > > } > > > > > > /* If using RSA keys then default to a good signature algorithm */ > > > - if (sshkey_type_plain(key->type) == KEY_RSA) > > > - sign_alg = RSA_SIGN_ALG; > > > + if (sshkey_type_plain(key->type) == KEY_RSA){ > > > + if (hashalg == NULL) > > > + sign_alg = RSA_SIGN_ALG; > > > + else if (strcmp(hashalg, "sha256") == 0) > > > + sign_alg = "rsa-sha2-256"; > > > + else if (strcmp(hashalg, "sha512") == 0) > > > + sign_alg = "rsa-sha2-512"; > > > + } > > > > > > if (signer != NULL) { > > > if ((r = signer(key, &sig, &slen, > > > -- > > > 2.44.0 > > > _______________________________________________ > > > openssh-unix-dev mailing list > > > openssh-unix-dev at mindrot.org > > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From djm at mindrot.org Wed Nov 27 09:03:24 2024 From: djm at mindrot.org (Damien Miller) Date: Wed, 27 Nov 2024 09:03:24 +1100 (AEDT) Subject: [PATCH 0/2] Specify signature algorithm during server hostkeys prove In-Reply-To: <20241112175019.52344-1-maximejeanrey@gmail.com> References: <20241112175019.52344-1-maximejeanrey@gmail.com> Message-ID: <176d1161-3a71-dacb-4e24-ecf10ef1b2db@mindrot.org> Thanks, these have all been committed and will be in openssh-10.0. Thanks especially for writing the regression test. -d On Tue, 12 Nov 2024, maximejeanrey at gmail.com wrote: > From: Maxime Rey > > Hello, > > I've discovered an issue with sshd when it's configured to use the SSH agent > alongside multiple host keys. Specifically, this problem happens during the > hostkeys-prove-00 at openssh.com request, when the server attempts to > demonstrate ownership of the host keys by calling the agent. > > The issue occurs because, while processing the hostkeys-prove-00 at openssh.com > request, sshd does not specify the signature algorithm in its call to > the agent. As a result, when sshd attempts to verify the response, it > encounters an error due to the missing algorithm specification. > > To address this, I have made two contributions: > > 1 - A modified hostkey-agent.sh regression test that reproduces the issue > under these conditions. > 2 - A patch in serverloop.c to correct the error > by ensuring the algorithm is explicitly specified during the > hostkeys-prove-00 at openssh.com response. > > Thank you for your time and feedback. > > Best regards, > Maxime > > Maxime Rey (2): > Add test to cover multiple server hostkeys with agent > Specify signature algorithm during server hostkeys prove > > regress/hostkey-agent.sh | 31 +++++++++++++++++++++++++++++++ > serverloop.c | 3 +++ > 2 files changed, 34 insertions(+) > > -- > 2.47.0 > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From djm at mindrot.org Wed Nov 27 09:06:01 2024 From: djm at mindrot.org (Damien Miller) Date: Wed, 27 Nov 2024 09:06:01 +1100 (AEDT) Subject: [PATCH] sshsig: check hashalg before selecting the RSA signature algorithm In-Reply-To: References: <20240411191640.2280049-1-morten@linderud.pw> <525c812a-dcae-e46c-09f8-cfb9f193f512@mindrot.org> Message-ID: good point - done :) On Tue, 26 Nov 2024, Morten Linderud wrote: > Thank you! > > There is now two " XXX maybe make configurable " in the top of the file that is > probably no longer relevant. Do you want a followup patch for that? > > Cheers, > Morten Linderud > > On Wed, Nov 27, 2024 at 08:25:15AM +1100, Damien Miller wrote: > > Sorry, this now been committed and will be in openssh-10.0 > > > > On Sat, 23 Nov 2024, Morten Linderud wrote: > > > > > Hi, > > > > > > I sent this patch back inn april and I still have a need for this. Would it be > > > possible to get any pointers how we can have `hashalg` selectable by `ssh-keygen -Y`? > > > > > > -- > > > Morten Linderud > > > PGP: 9C02FF419FECBE16 > > > > > > On Thu, Apr 11, 2024 at 09:16:39PM +0200, Morten Linderud wrote: > > > > `ssh-keygen -Y sign` only selects the signing algorithm `rsa-sha2-512` > > > > and this prevents ssh-agent implementations that can't support sha512 > > > > from signing messages. > > > > > > > > An example of this is TPMs which mostly only really supports sha256 > > > > widely. > > > > > > > > This change enables `ssh-keygen -Y sign` to honor the `hashalg` option > > > > for the signing algorithm. > > > > > > > > Signed-off-by: Morten Linderud > > > > --- > > > > sshsig.c | 10 ++++++++-- > > > > 1 file changed, 8 insertions(+), 2 deletions(-) > > > > > > > > diff --git a/sshsig.c b/sshsig.c > > > > index 470b286a3..033b43353 100644 > > > > --- a/sshsig.c > > > > +++ b/sshsig.c > > > > @@ -190,8 +190,14 @@ sshsig_wrap_sign(struct sshkey *key, const char *hashalg, > > > > } > > > > > > > > /* If using RSA keys then default to a good signature algorithm */ > > > > - if (sshkey_type_plain(key->type) == KEY_RSA) > > > > - sign_alg = RSA_SIGN_ALG; > > > > + if (sshkey_type_plain(key->type) == KEY_RSA){ > > > > + if (hashalg == NULL) > > > > + sign_alg = RSA_SIGN_ALG; > > > > + else if (strcmp(hashalg, "sha256") == 0) > > > > + sign_alg = "rsa-sha2-256"; > > > > + else if (strcmp(hashalg, "sha512") == 0) > > > > + sign_alg = "rsa-sha2-512"; > > > > + } > > > > > > > > if (signer != NULL) { > > > > if ((r = signer(key, &sig, &slen, > > > > -- > > > > 2.44.0 > > > > _______________________________________________ > > > > openssh-unix-dev mailing list > > > > openssh-unix-dev at mindrot.org > > > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >