search for: ssh_err_internal_error

...Z_MEM_ERROR: return SSH_ERR_ALLOC_FAIL; @@ -734,7 +765,7 @@ compress_buffer(struct ssh *ssh, struct sshbuf *in, struct sshbuf *out) u_char buf[4096]; int r, status; - if (ssh->state->compression_out_started != 1) + if (ssh->state->compression_out_started != COMP_ZLIB) return SSH_ERR_INTERNAL_ERROR; /* This case is not handled below. */ @@ -780,7 +811,7 @@ uncompress_buffer(struct ssh *ssh, struct sshbuf *in, struct sshbuf *out) u_char buf[4096]; int r, status; - if (ssh->state->compression_in_started != 1) + if (ssh->state->compression_in_started != COMP_ZLIB) return...

I added ZSTD support to OpenSSH roughly three years ago and I've been playing with it ever since. The nice part is that ZSTD achieves reasonable compression (like zlib) but consumes little CPU so it is unlikely that compression becomes the bottle neck of a transfer. The compression overhead (CPU) is negligible even when uncompressed data is tunneled over the SSH connection (SOCKS proxy, port

I hacked zstd support into OpenSSH a while ago and just started to clean it up in the recent days. The cleanup includes configuration support among other things that I did not have. During testing I noticed the following differences compared to zlib: - highly interactive shell output (as in refreshed at a _very_ high rate) may result in higher bandwidth compared to zlib. Since zstd is quicker

I added ZSTD support to OpenSSH roughly over a year and I've been playing with it ever since. The nice part is that ZSTD achieves reasonable compression (like zlib) but consumes little CPU so it is unlikely that compression becomes the bottle neck of a transfer. The compression overhead (CPU) is negligible even when uncompressed data is tunneled over the SSH connection (SOCKS proxy, port

...t sshbuf *child, if ((r = sshbuf_check_sanity(child)) != 0 || (r = sshbuf_check_sanity(parent)) != 0) return r; - if (child->parent != NULL && child->parent != parent) + if ((child->parent != NULL && child->parent != parent) || + child == parent) return SSH_ERR_INTERNAL_ERROR; child->parent = parent; child->parent->refcount++;

...stent state if buf->max_size < SSHBUF_SIZE_INIT, because it will make buf->alloc > buf->max_size true, which will trigger an error with a next call to sshbuf_check_sanity(). For example, struct sshbuf *buf = sshbuf_new(); sshbuf_set_max_size(buf, 100); sshbuf_reset(buf); will lead to SSH_ERR_INTERNAL_ERROR. This code is of course just for demonstration, but the thing is that an sshbuf object can be put into invalid state through its public API. Or it is just assumed that no one will ever set ->max_size to a value less than SSHBUF_SIZE_INIT? Anyway, i thought that all invariants of sshbuf object mu...

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'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 sshkey **k) +{ + EVP_PKEY *pk; + ENGINE *e; + struct sshkey *key; + int ret; + UI_METHOD *ui; + EVP_PKEY_CTX *ctx; + char hash[SHA256_DIGEST_LENGTH], result[1024]; + size_t siglen; + struct ui_data d; + + verbose("%s: add provider=%s, key=%s", __func__, engine, file); + + ret = SSH_ERR_INTERNAL_ERROR; + e = ENGINE_by_id(engine); + if (!e) { + verbose("%s: failed to get engine %s", __func__, engine); + ERR_print_errors_fp(stderr); + return ret; + } + + ui = UI_create_method("ssh-agent password writer"); + if (!ui) { + verbose("%s: failed to create UI method", __...

...atus: NEW Severity: normal Priority: P5 Component: sshd Assignee: unassigned-bugs at mindrot.org Reporter: me at basilcrow.com openssh_RSA_verify in ssh-rsa.c defines ret to be of type size_t, which is unsigned. It then assigns signed values such as SSH_ERR_INTERNAL_ERROR (-1) to ret. Finally, it returns ret (a size_t), while the method signature of openssh_RSA_verify is defined as returning type int. The method works as intended to some degree, in that on success it returns 0 and on failure it returns non-zero. But if one were to try to do something with the return...

...2_check_padding(struct sshbuf *decrypted) ? ?static int ?sshkey_parse_private2(struct sshbuf *blob, int type, const char *passphrase, -??? struct sshkey **keyp, char **commentp) +??? struct sshkey **keyp, char **commentp, struct sshkey_vault **vault_infop) ?{ ??? ?char *comment = NULL; ??? ?int r = SSH_ERR_INTERNAL_ERROR; @@ -4216,7 +4282,7 @@ sshkey_parse_private2(struct sshbuf *blob, int type, const char *passphrase, ??? ?/* Undo base64 encoding and decrypt the private section */ ??? ?if ((r = private2_uudecode(blob, &decoded)) != 0 || ??? ???? (r = private2_decrypt(decoded, passphrase, -?? ???? &decrypte...

Hello. I am trying to play through the following test scenario about certificate revocation on Ubuntu 18.04, which has OpenSSH of this version: OpenSSH_7.6p1 Ubuntu-4, OpenSSL 1.0.2n? 7 Dec 2017 1. A CA key is created ssh-keygen -t ed25519 -f ca 2. The CA public key is added to ~/.ssh/authorized_keys on some server: cert-authority ssh-ed25519 AAAA...e ca at yoga 3. A user key is created on a