search for: sshbuf_put_cstring

...buf_put_u32(b, a->mtime)) != 0) return r; + } + if (a->flags & SSH2_FILEXFER_ATTR_EXTENDED) { + u_int32_t count = 0; + if (a->has_nlink) { + count += 1; + } + + if (count) { + if ((r = sshbuf_put_u32(b, count)) != 0) + return r; + + if (a->has_nlink) { + if ((r = sshbuf_put_cstring(b, SFTP_EXT_ATTR_LINK_COUNT)) != 0 || + (r = sshbuf_put_u32(b, 8)) != 0 || + (r = sshbuf_put_u64(b, a->nlink))) + return r; + } + } } return 0; } Index: sftp-common.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/sftp...

In sshconnect.c there are two global variables for server_version_string client_version_string. These are used just in a few functions and can easily be passed as parameters. Also, there is a strange construct, where their memory is allocated to the global pointers, then copies of these pointers are assigned to the kex structure. The kex_free finally frees them via cleanup of the kex

Hi, I have a question regarding the binary format of the certificates generated with ssh-keygen, in particular when the critical options of source-address or force-command are present and the correspondence to the certificate format specifications such as http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/PROTOCOL.certkeys?rev=HEAD . It appears that the string values of the source-address

Engine keys are private key files which are only understood by openssl external engines. ?The problem is they can't be loaded with the usual openssl methods, they have to be loaded via ENGINE_load_private_key(). ?Because they're files, they fit well into openssh pub/private file structure, so they're not very appropriately handled by the pkcs11 interface because it assumes the private

I was recently looking at verifying the attestation data (ssh-sk-attest-v00) for a SK key, but I believe the data saved in this structure is insufficient for completing verification of the attestation. While the structure has enough information for U2F devices, FIDO2 devices sign their attestation over a richer "authData" blob [1] (concatenated with the challenge hash). The authData blob

I've architected this in a way that looks future proof at least to the openssl provider transition. What will happen in openssl 3.0.0 is that providers become active and will accept keys via URI. The current file mechanisms will still be available but internally it will become a file URI. To support the provider interface, openssl will have to accept keys by URI instead of file and may

...+ struct sshbuf *msg; + int r, constrained = (lifetime || confirm); + u_char type = constrained ? SSH_AGENTC_ADD_ENGINE_KEY_CONSTRAINED : + SSH_AGENTC_ADD_ENGINE_KEY; + + msg = sshbuf_new(); + if (!msg) + return SSH_ERR_ALLOC_FAIL; + r = sshbuf_put_u8(msg, type); + if (r) + goto out; + r = sshbuf_put_cstring(msg, engine); + if (r) + goto out; + r = sshbuf_put_cstring(msg, file); + if (r) + goto out; + r = sshbuf_put_cstring(msg, pin); + if (r) + goto out; + if (constrained) { + r = encode_constraints(msg, lifetime, confirm, maxsign, NULL); + if (r) + goto out; + } + r = ssh_request_reply(sock, m...