search for: ssh2_msg_ext_info

...port-layer hardening measures under a "strict KEX" feature. This feature is signalled similarly to the @@ -163,7 +163,7 @@ b) After sending or receiving a SSH2_MSG_NEWKEYS message, reset the duration of the connection (i.e. not just the first SSH2_MSG_NEWKEYS). -1.10 transport: SSH2_MSG_EXT_INFO during user authentication +1.11 transport: SSH2_MSG_EXT_INFO during user authentication This protocol extension allows the SSH2_MSG_EXT_INFO to be sent during user authentication. RFC8308 does allow a second -- 2.42.1

...ekeying. I reproduced it on my system with OpenSSH 7.3p1 and manually rekeying with escape R http://pastebin.com/Xk0dF0mc on the client side: sshconnect2.c: void ssh_userauth2(const char *local_user, const char *server_user, char *host, Sensitive *sensitive) { ... ssh_dispatch_set(ssh, SSH2_MSG_EXT_INFO, &input_userauth_ext_info); ssh_dispatch_set(ssh, SSH2_MSG_SERVICE_ACCEPT, &input_userauth_service_accept); ssh_dispatch_run(ssh, DISPATCH_BLOCK, &authctxt.success, &authctxt); /* loop until success */ pubkey_cleanup(&authctxt); ssh_dispatch_r...

https://bugzilla.mindrot.org/show_bug.cgi?id=2929 Bug ID: 2929 Summary: OpenSSH server should not send the SSH_MSG_EXT_INFO message after rekeying Product: Portable OpenSSH Version: 7.7p1 Hardware: Other OS: Linux Status: NEW Severity: enhancement Priority: P5

Hai, Lets start here. Handy for us to know. OS? Samba version? AD or member setup? And I suggest, set this in the ssh server. # GSSAPI options GSSAPIAuthentication yes Restart the ssh server and try to SSO login. If its a AD server this should work. Yes, you dont get home dir etc, end up in / after login, but lets check if this works. Greetz, Louis > -----Oorspronkelijk

https://bugzilla.mindrot.org/show_bug.cgi?id=2348 Bug ID: 2348 Summary: allow ssh to connect to a unix domain socket Product: Portable OpenSSH Version: -current Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 Component: ssh Assignee: unassigned-bugs at

...ally, SSH server will be on a separate machine. > > I have tried two options (after `kinit administrator`): > > a) Using `UsePAM yes` in sshd_config: > ------------------------ > > I ran `ssh administrator at dc1.domain.com -vv` > > SSH client logs: > > debug1: SSH2_MSG_EXT_INFO received > debug1: kex_input_ext_info: > server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp2 > 56,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521> > debug2: service_accept: ssh-userauth > debug1: SSH2_MSG_SERVICE_ACCEPT received > debug1: Authentications that can continu...

...ne. > > I have tried two options (after `kinit administrator`): > > > > a) Using `UsePAM yes` in sshd_config: > > > > -------------------------------------- > > > > I ran `ssh administrator at dc1.domain.com -vv` > > SSH client logs: > > debug1: SSH2_MSG_EXT_INFO received > > debug1: kex_input_ext_info: > > server-sig-algs=<ssh-ed25519,ssh-rsa,ssh-dss,ecdsa-sha2-nistp2 > > 56,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521> > > debug2: service_accept: ssh-userauth > > debug1: SSH2_MSG_SERVICE_ACCEPT received > > debug1: Aut...

...'192.168.1.100' is known and matches the ECDSA host key. debug1: Found key in /Users/alice/.ssh/known_hosts:31 debug1: rekey after 134217728 blocks debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug1: SSH2_MSG_NEWKEYS received debug1: rekey after 134217728 blocks debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512> debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic,password debug1: Next authentication method: publickey debug1: Trying private key: /Users...

...tely very limited as it only allows deletion of consecutive messages, and deleting most messages at this stage of the protocol prevents user user authentication from proceeding and results in a stuck connection. The most serious identified impact is that it lets a MITM to delete the SSH2_MSG_EXT_INFO message sent before authentication starts, allowing the attacker to disable a subset of the keystroke timing obfuscation features introduced in OpenSSH 9.5. There is no other discernable impact to session secrecy or session integrity. OpenSSH 9.6 addresses this protocol weakness throug...

...d matches the ECDSA host key. > debug1: Found key in /Users/alice/.ssh/known_hosts:31 > debug1: rekey after 134217728 blocks > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug1: SSH2_MSG_NEWKEYS received > debug1: rekey after 134217728 blocks > debug1: SSH2_MSG_EXT_INFO received > debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512> > debug1: SSH2_MSG_SERVICE_ACCEPT received > debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi- > with-mic,password > debug1: Next authentication method: publickey > deb...

...tely very limited as it only allows deletion of consecutive messages, and deleting most messages at this stage of the protocol prevents user user authentication from proceeding and results in a stuck connection. The most serious identified impact is that it lets a MITM to delete the SSH2_MSG_EXT_INFO message sent before authentication starts, allowing the attacker to disable a subset of the keystroke timing obfuscation features introduced in OpenSSH 9.5. There is no other discernable impact to session secrecy or session integrity. OpenSSH 9.6 addresses this protocol weakness throug...

...type 21 debug1: SSH2_MSG_NEWKEYS received debug2: set_newkeys: mode 0 debug1: rekey after 134217728 blocks debug2: key: /.ssh/id_rsa (0) debug2: key: /.ssh/id_dsa (0) debug2: key: /.ssh/id_ecdsa (0) debug2: key: /.ssh/id_ed25519 (0) debug3: send packet: type 5 debug3: receive packet: type 7 debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs=<ssh-ed25519,ssh-rsa,rsa-sha2-256,rsa-sha2-512,ssh-dss,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521> debug3: receive packet: type 6 debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug3: send p...

Hi, I'm doing some test with a pkcs11 token that can only sign short messages. When connecting to one server, that reports pkalg rsa-sha2-512 blen 151, it fails to sign the pubkey because it is 83 bytes long. (sshd: OpenSSH_7.3p1) A older server that reports pkalg ssh-rsa blen 151, works perfectly as the pubkey signature required is only 35 bytes long. (sshd: OpenSSH_6.7p1) I am not sure

Get the following error: root at x065:[/data/prj/openbsd/openssh/openssh-7.7p1/openbsd-compat]make ??????? xlc_r -I/opt/include -O2 -qmaxmem=-1 -qarch=pwr5 -q64 -I. -I.. -I../../src/openssh-7.7p1/openbsd-compat -I../../src/openssh-7.7p1/openbsd-compat/.. -I/opt/include -DHAVE_CONFIG_H -c ../../src/openssh-7.7p1/openbsd-compat/strndup.c

https://bugzilla.mindrot.org/show_bug.cgi?id=2521 Bug ID: 2521 Summary: subtract buffer size from computed rekey limit to avoid exceeding it Product: Portable OpenSSH Version: 6.8p1 Hardware: amd64 OS: Linux Status: NEW Severity: minor Priority: P5 Component: sshd

...e..13bb9aa 100644 --- a/kex.c +++ b/kex.c @@ -348,7 +348,7 @@ kex_send_ext_info(struct ssh *ssh) int r; char *algs; - if ((algs = sshkey_alg_list(0, 1, ',')) == NULL) + if ((algs = sshkey_alg_list(0, 1, 1, ',')) == NULL) return SSH_ERR_ALLOC_FAIL; if ((r = sshpkt_start(ssh, SSH2_MSG_EXT_INFO)) != 0 || (r = sshpkt_put_u32(ssh, 1)) != 0 || diff --git a/ssh.c b/ssh.c index ee0b16d..edef335 100644 --- a/ssh.c +++ b/ssh.c @@ -684,11 +684,11 @@ main(int ac, char **av) else if (strcmp(optarg, "kex") == 0) cp = kex_alg_list('\n'); else if (strcmp(optarg, "key&...

https://bugzilla.mindrot.org/show_bug.cgi?id=2729 Bug ID: 2729 Summary: Can connect with MAC hmac-sha1 even though it's not configured on the server Product: Portable OpenSSH Version: 7.5p1 Hardware: All OS: Linux Status: NEW Severity: security Priority: P5

.../home/me/.ssh/id_dsa > debug1: Will attempt key: /home/me/.ssh/id_ecdsa > debug1: Will attempt key: /home/me/.ssh/id_ed25519 > debug1: Will attempt key: /home/me/.ssh/id_xmss > debug2: pubkey_prepare: done > debug3: send packet: type 5 > debug3: receive packet: type 7 > debug1: SSH2_MSG_EXT_INFO received > debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512> > 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:...

https://bugzilla.mindrot.org/show_bug.cgi?id=2573 Bug ID: 2573 Summary: dead sessions cannot be closed with ~. Product: Portable OpenSSH Version: 3.7.1p2 Hardware: Other OS: Linux Status: NEW Severity: normal Priority: P5 Component: ssh Assignee: unassigned-bugs at mindrot.org

...ll attempt key: /export/home/user/.ssh/id_ecdsa_sk debug1: Will attempt key: /export/home/user/.ssh/id_ed25519 debug1: Will attempt key: /export/home/user/.ssh/id_ed25519_sk debug1: Will attempt key: /export/home/user/.ssh/id_xmss debug1: Will attempt key: /export/home/user/.ssh/id_dsa debug1: SSH2_MSG_EXT_INFO received debug1: kex_input_ext_info: server-sig-algs=<rsa-sha2-256,rsa-sha2-512> debug1: SSH2_MSG_SERVICE_ACCEPT received debug1: Authentications that can continue: publickey,password debug1: Next authentication method: publickey debug1: Trying private key: /export/home/user/.ssh/id_rsa debug...