similar to: Dubious use of BN_num_bits in sshconnect1.c (resend)

Hiho... I have recently encountered problems using OpenSSH 2.3.0p1 to connect to a SSH 1.2.20 server, with messages such as the following: Warning: Server lies about size of server public key: actual size is 1151 bits vs. announced 1152. Warning: This may be due to an old implementation of ssh. respond_to_rsa_challenge: public_key 1151 < host_key 1024 + SSH_KEY_BITS_RESERVED 128

Below is a patch against the current OpenBSD OpenSSH CVS to workaround a behavior I have observed when converting from SSH 1.2.27 to OpenSSH while using the same old RSA1 host key for protocol 1. In several cases I saw that old SSH sshd reported a host key size of 1024 bits when OpenSSH saw it as 1023 bits. Without the patch, when OpenSSH's ssh client connects to an old SSH sshd it warns

I'm trying to replace some sshv1 clients and servers in a modular way, and the "Server Lies" warning (when the server says the key has one more bit than it really has) is causing heartache. Per the FAQ, this is relatively benign. Here's a patch that allows an admin or user to disable the warning. - Morty diff -Nur openssh-3.7.1p2/readconf.c

Hi all, I have a question about OpenSSH configuration. In Makefile there is defined LIBS=$(LIBCRYPTO), but the problem is that the version of OpenSSL that I'm using holds only the version LIBCRYPT. When adding LIBCRYPT to the Makefile I get: sshd.elf2flt: In function `key_regeneration_alarm': /.../ssh/sshd.c:252: undefined reference to `RSA_free' /.../ssh/sshd.c:253: undefined

Correct me if I'm wrong, but init_rng() in entropy.c doesn't call seed_rng(), and in fact seed_rng() isn't called from _anywhere_ (in openssh-2.5.1p2). So calls to BN_rand() only pick up the tiny/non-existent amount of entropy added by BN_rand() itself from the system clock (time in seconds). Shouldn't seed_rng() be called from init_rng()? It should be called from _somewhere_,

On Thu, Sep 21, 2017 at 02:22:10AM -0500, Zev Weiss wrote: > test_kex: regress/unittests/kex/test_kex.c:91 test #1 "sshkey_generate" > ASSERT_INT_EQ(sshkey_generate(keytype, bits, &private), 0) failed: > sshkey_generate(keytype, bits, &private) = -56 That error code is: $ grep -- -56 ssherr.h #define SSH_ERR_KEY_LENGTH -56 Unfortunately there's lots of

In the current implementation, ssh always uses the hostname supplied by the user directly for the SSHFP DNS record lookup. This causes problems when using the domain search path, e.g. I have "search example.com" in my resolv.conf and then do a "ssh host", I will connect to host.example.com, but ssh will query the DNS for an SSHFP record of "host.", not

<alex@foogod.com> schrieb im Newsbeitrag news:20020924181444.H16854@firestar.foogod.com... > Greetings all.. I'm sending this message out here because I suspect that some > folks involved in this project might be interested in the following. If this > is not the case (or this is not an appropriate forum for this sort of thing) I > apologize in advance.. >

Hi, Has anybody produced diffs for openssh-2.3.0p1 for the rsa keyexchange problem that Core-SDI described ? ( I noticed that fix is already in openbsd tree ). -Jarno -- Jarno Huuskonen - System Administrator | Jarno.Huuskonen at uku.fi University of Kuopio - Computer Center | Work: +358 17 162822 PO BOX 1627, 70211 Kuopio, Finland | Mobile: +358 40 5388169

`git describe' says V_7_3_P1-207-gc924b2ef (shouldn't it say V_7_4_P1-<yadayada>?). This is what I see: gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -Wsizeof-pointer-memaccess -Wno-pointer-sign -Wno-unused-result -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset -fstack-protector-strong -fPIE -I. -I.

Hello, I'm trying to compile openssh 3.7.1p2 on a sparc 5 running OpenBSD 2.8. I compiled and installed OpenSSL 0.9.7b, and the tests all pass without error. I configured openssh with --with-ssl-dir=/usr/local/ssl and ssh compiles fine, however when it attepts to make a rsa1 key, ssh-keygen core dumps: oldyeek# make host-key (cd openbsd-compat && make) gcc -o ssh-keygen

I remember a discussion to the effect that using DSA keys in sshd increases the requirement for random bits available on the system... and that this requirement (was it a 128 bit random number per connection?) presents security problems on systems that don't have a decent source of entropy? Am I misinterpreting those discussions? We are having a problem deploying sshd (no prngd) where sshd

Hello Steve, Hello OpenSSH-portable developers, I am building OpenSSH for our (EBCDIC-based) BS2000 mainframe operating system, and I noticed you do the same for OS/390. Because my initial ssh port was based on IBM's OSS port (ssh-1.2.2 or some such), I thought it was fair enough to help with a little co-operation; we might come up with a unified EBCDIC patch which could be contributed to

Hi, during our usual work I found it anoying that one can not easily see who logged in using public key authentication. In newer versions of SSH the fingerprint of the public key gets logged, but who can tell which key belongs to whom from his head? So I wrote a little ad-hoc patch (vs. 3.5.p1) so that the comment field on the keys in the authorized_keys[2] files get logged to make life

Hi. I've got the following problem with our SSH client library: - client connects to OpenSSH 5.9+ server and they choose hmac-sha2-512 with diffie-hellman-group-exchange-sha256. - client sends MSG_KEX_DH_GEX_REQUEST DH group request with parameters (1024, 1024, 8192). I.e. minimum and preferred group size is 1024-bit, - OpenSSH server in kexgexs.c:kexgex_server processes this message and

https://bugzilla.mindrot.org/show_bug.cgi?id=2371 Bug ID: 2371 Summary: make check fails when using --without-openssl on AIX Product: Portable OpenSSH Version: 6.9p1 Hardware: Other OS: All Status: NEW Severity: normal Priority: P5 Component: Build system Assignee:

https://bugzilla.mindrot.org/show_bug.cgi?id=2371 Bug ID: 2371 Summary: make check fails when using --without-openssl on AIX Product: Portable OpenSSH Version: 6.9p1 Hardware: Other OS: All Status: NEW Severity: normal Priority: P5 Component: Build system Assignee:

Add support to load additional certificates for already loaded private keys. Useful if the private key is on a PKCS#11 hardware token. The private keys inside ssh-agent are now using a refcount to share the private parts between "Identities". The reason for this change was that the PKCS#11 code might have redirected ("wrap") the RSA functions to a hardware token. We don't

Could everyone please test the latest snapshots as we will be making a new release soon. If you have any patches you would like us to consider, please resend them to the list ASAP. -d -- | Damien Miller <djm at mindrot.org> \ ``E-mail attachments are the poor man's | http://www.mindrot.org / distributed filesystem'' - Dan Geer

Hi, I have a FreeBSD 4.8 box connected to the net which until recently hasn't had any problems. Today DNS lookups mysteriously stopped working (the box has tinydns & dnscache installed to handle dns requests). I noticed some strange things while checking the problem with tcpdump. Tcpdump appears not to show any traffic whatsoever on either my external interface or internal lan interface,