From dtucker at zip.com.au  Mon Jun  1 08:48:48 2015
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 1 Jun 2015 08:48:48 +1000
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <20150530211235.GA20740@doctor.nl2k.ab.ca>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <5569E593.6050708@gmail.com>
 <CAMv58rbvtdf6PD2maVDbqB-22sU9KLOsahrN--mDDqaicEcfpA@mail.gmail.com>
 <20150530211235.GA20740@doctor.nl2k.ab.ca>
Message-ID: <CALDDTe37pVp4QNR-O4c3yADpf-vivZ3D=xPBhcwZi3-R+K_EKQ@mail.gmail.com>

On Sun, May 31, 2015 at 7:12 AM, The Doctor <doctor at doctor.nl2k.ab.ca>
wrote:

> So far BSD/OS and opensh 6.9 pre works with ZOC and Tera Term.
>
> Putty and WINSCP are broken.
>

Could you please elaborate on "broken"?  Which version of PuTTY?  (I'm not
familiar with WinSCP versions but I believe the code is based on PuTTY, so
I think if we figure out PuTTY then the same will probably apply to WinSCP).

Could you please run sshd and plink in debug mode ("/eg path/to/sshd -ddde
-p 2022" and "plink -v -P 2022 yourhost")

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From dtucker at zip.com.au  Mon Jun  1 09:03:03 2015
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 1 Jun 2015 09:03:03 +1000
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <03554CDD-7488-4823-B290-D59A49C3A2AF@timeheart.net>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <03554CDD-7488-4823-B290-D59A49C3A2AF@timeheart.net>
Message-ID: <CALDDTe3nzwG7nEwuzU8z3SV5bM_9rXYoDfKaOPo_1QQ62gtN5Q@mail.gmail.com>

On Sun, May 31, 2015 at 3:37 AM, Ron Frederick <ronf at timeheart.net> wrote:

> On May 29, 2015, at 12:12 AM, Damien Miller <djm at mindrot.org> wrote:
> > OpenSSH 6.9 is almost ready for release, so we would appreciate testing
> > on as many platforms and systems as possible. This release contains
> > some substantial new features and a number of bug fixes.
>
> I just compiled and ran the tests for openssl-snap-20150531 on Linux
> (Ubuntu 14.04.2 LTS) and MacOS (10.10.3).
>
> On Linux, the code compiled cleanly. However, during ?make tests? I got
> the following error a number of times:
>
> WARNING: /usr/local/etc/moduli does not exist, using fixed modulus
>

Most of the tests will still work with that file missing, but there's one
test that specifically checks that the DH group sizes are right, and
that'll fail (because the server doesn't have groups of the sizes it wants,
but it'll fall back to the couple that are compiled in).  You can just copy
the file into place if you like (as long as it's world readable), or you
can use configure --sysconfdir to point it at wherever the file actually is.


> Later in the test sequence I got the error:
>
> run test connect.sh ...
> Missing privilege separation directory: /var/empty
> FATAL: sshd_proxy broken
> make[1]: *** [t-exec] Error 1
> make[1]: Leaving directory `/tmp/openssh/regress'
> make: *** [tests] Error 2
> make tests  153.92s user 4.68s system 98% cpu 2:41.52 total
>
> I was not running as root at the time, as I wasn?t intending to install
> this version. It looks like it assumes that /var/empty will already exist,
> though, which it doesn?t on my system.


The privsep chroot path is specified at build time (./configure
--with-privsep-path if you want to change it).


> The currently installed sshd does have UsePrivilegeSeparation enabled, and
> it looks like the sshd user is set up with have /var/run/sshd as its home
> directory on this system, but the test script didn?t pick that up.


Having the chroot dir as the user's home dir is not a great idea.  If
someone discovers a way to write inside the chroot (eg via a permission
misconfiguration) then they can trivially escalate to full access that by
creating authorized_keys or similar.


> On MacOS, the code compiled, but there were a large number of warnings
> about constructs that were deprecated back in OS X 10.7. The output is
> quite large, but I?d be happy to provide it to anyone who wants it.

[...]

I would be interested in seeing it, although it's not something that we
would be looking at working on at this time.  Could you please either send
it to me off-list or file a bug at bugzilla.mindrot.org and attach the log?

Thanks.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From dtucker at zip.com.au  Mon Jun  1 09:06:25 2015
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 1 Jun 2015 09:06:25 +1000
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <CAMv58rbvtdf6PD2maVDbqB-22sU9KLOsahrN--mDDqaicEcfpA@mail.gmail.com>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <5569E593.6050708@gmail.com>
 <CAMv58rbvtdf6PD2maVDbqB-22sU9KLOsahrN--mDDqaicEcfpA@mail.gmail.com>
Message-ID: <CALDDTe3+-DeJ1_CNtKhJUm2Gdh-EW-3XDdSKpZh32Gc_A4WY9A@mail.gmail.com>

On Sun, May 31, 2015 at 4:56 AM, Kevin Brott <kevin.brott at gmail.com> wrote:
[...]
>
> ROOT LOGIN REFUSED FROM 127.0.0.1


You were running the tests as root?  I think we need to add
PermitRootLogin=yes to the regression tests to cover this case.


> On Sat, May 30, 2015 at 9:30 AM, Kevin Brott <kevin.brott at gmail.com>
> wrote:
>
> >
> > Starting building/testing for the lab systems I have Monday.
> >
> > Any chance a fix for Bug 2404 <
> > https://bugzilla.mindrot.org/show_bug.cgi?id=2404> could get wedged in
> > before release?
>

I'm looking at it but I don't understand what needs to change yet, so I'm
not sure if it'll make it in time.  scp is not my favourite piece of code.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From dkg at fifthhorseman.net  Mon Jun  1 10:31:16 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sun, 31 May 2015 20:31:16 -0400
Subject: Weak DH primes and openssh
In-Reply-To: <1620119.MSLpl5Hm2D@pintsize.usersys.redhat.com>
References: <555DDD09.3090606@debian.org>
 <2591117.cQXXSN3CjL@pintsize.usersys.redhat.com>
 <alpine.BSO.2.20.1505300008250.11037@natsu.mindrot.org>
 <1620119.MSLpl5Hm2D@pintsize.usersys.redhat.com>
Message-ID: <87twusfewb.fsf@alice.fifthhorseman.net>

On Fri 2015-05-29 10:14:45 -0400, Hubert Kario wrote:
> On Saturday 30 May 2015 00:09:47 Damien Miller wrote:
>> On Fri, 29 May 2015, Hubert Kario wrote:
>> > Not really, no.
>> > 
>> > We can use this time an initial seed of "OpenSSH 1024 bit prime, attempt
>> > #1". Next time we generate the primes we can use the initial seed of
>> > "2017 OpenSSH 1024 bit prime, attempt #1", but we can use just as well a
>> > "2nd generation OpenSSH 1024 bit DH parameters, try number 1". Then we
>> > can also change the algorithm to use this seed for M-R witnesses, or not.
>> > Then we can use SHA-512 instead of SHA-256, or some SHA-3 variant.
>> 
>> If you're constantly changing the parameters, then this is the opposite of
>> NUMS. Anyway, I don't think a NUMS-like approach is necessary. It certainly
>> isn't with users independently generating primality certificates.
>
> yes, I'm not saying that we should regenerate them constantly, I'm just saying 
> that if the decision was ever to do that again, it's basically impossible to 
> predict now what those numbers will be

I agree with Damien here, i don't see the point of choosing a
fixed-string seed if we're going to change it arbitrarily in the future.

And if the seed string is something semantically similar to "2017
OpenSSH 1024 bit prime, attempt #1", then there actually aren't all that
many of them to choose from, so an adversary who can do precomputation
attacks can pick the most-likely seeds and then send sockpuppets to
argue for one of them when the time comes. :/

The other alternative if you wanted fixed seeds would be to use some
high-entropy value from the real world that would be unpredictable, hard
to control, but not too hard to verify (e.g. a digest of the
concatenated UTF-8 representations of the top headline from each of the
10 highest-circulation newspapers on the day of re-generation, or
something similar).

          --dkg

From djm at mindrot.org  Mon Jun  1 11:23:51 2015
From: djm at mindrot.org (Damien Miller)
Date: Mon, 1 Jun 2015 11:23:51 +1000 (AEST)
Subject: Weak DH primes and openssh
In-Reply-To: <87twusfewb.fsf@alice.fifthhorseman.net>
References: <555DDD09.3090606@debian.org>
 <2591117.cQXXSN3CjL@pintsize.usersys.redhat.com>
 <alpine.BSO.2.20.1505300008250.11037@natsu.mindrot.org>
 <1620119.MSLpl5Hm2D@pintsize.usersys.redhat.com>
 <87twusfewb.fsf@alice.fifthhorseman.net>
Message-ID: <alpine.BSO.2.20.1506011116550.19595@natsu.mindrot.org>

On Sun, 31 May 2015, Daniel Kahn Gillmor wrote:

> The other alternative if you wanted fixed seeds would be to use some
> high-entropy value from the real world that would be unpredictable,
> hard to control, but not too hard to verify (e.g. a digest of the
> concatenated UTF-8 representations of the top headline from each of
> the 10 highest-circulation newspapers on the day of re-generation, or
> something similar).

IMO it's still pointless - NUMS-style generation might be useful in
cases where there exists suspicion (but no proof) that some parameter
choices might be trapdoor-able. There's not even the faintest hint
that this might be the case for the DLP in arbitrary strong prime modp
groups.

If vendors are concerned about the moduli that OpenSSH ships, I'd
recommend either generating your own (using ssh-keygen or some
independent means) or auditing what we do using primo or some similar
ECPP tool.

Getting a good, open-source primality prover would be nice too...

-d

From djm at mindrot.org  Mon Jun  1 11:28:05 2015
From: djm at mindrot.org (Damien Miller)
Date: Mon, 1 Jun 2015 11:28:05 +1000 (AEST)
Subject: Using two agents
In-Reply-To: <20150530120023.GA3477@colin.search.kasperd.net>
References: <20150530120023.GA3477@colin.search.kasperd.net>
Message-ID: <alpine.BSO.2.20.1506011124050.19595@natsu.mindrot.org>

On Sat, 30 May 2015, Kasper Dupont wrote:

> As far as I can tell when the ssh command uses an agent to
> authenticate to a server and then forwards an agent to that server, it
> will always use the same agent for both purposes.
>
> Has there been any attempt to make it possible for the ssh command
> to use two different agents, such that I can use one agent to
> authenticate and then forward a different agent to the server?

You could probably rig something up using the Unix domain socket
forwaring that was added a couple of releases ago.

More generally, I've long wanted the ability to restrict which keys are
made available through a forwarded-agent but doing so either requires
teaching ssh most of the agent protocol and moving ssh into the trust
path for agent keys, or a more substantial rearchitecture of how agents
are forwarded (giving each ssh a long-lived socket to the agent, or some
sort of cookie that stood for one instead of creating socket on-demand).

-d

From djm at mindrot.org  Mon Jun  1 11:30:35 2015
From: djm at mindrot.org (Damien Miller)
Date: Mon, 1 Jun 2015 11:30:35 +1000 (AEST)
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <CAMv58rbvtdf6PD2maVDbqB-22sU9KLOsahrN--mDDqaicEcfpA@mail.gmail.com>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <5569E593.6050708@gmail.com>
 <CAMv58rbvtdf6PD2maVDbqB-22sU9KLOsahrN--mDDqaicEcfpA@mail.gmail.com>
Message-ID: <alpine.BSO.2.20.1506011129350.19595@natsu.mindrot.org>

are you running the tests as root? It's possible the tests are broken
for root given the recent change of PermitRootLogin's default

On Sat, 30 May 2015, Kevin Brott wrote:

> Debian GNU/Linux 8.0 (jessie)
> OpenSSL 1.0.1k
> gcc (Debian 4.9.2-10) 4.9.2
> 
> "make tests" fails here:
> /usr/src/INET/openssh/ssh-keygen -lf
> /usr/src/INET/openssh/regress//t12.out.pub | grep test-comment-1234
> >/dev/null
> run test connect.sh ...
> ssh connect with protocol 1 failed
> ssh connect with protocol 2 failed
> failed simple connect
> Makefile:192: recipe for target 't-exec' failed
> make[1]: *** [t-exec] Error 1
> make[1]: Leaving directory '/usr/src/INET/openssh/regress'
> Makefile:544: recipe for target 'tests' failed
> make: *** [tests] Error 2
> 
> ?failed-ssh.log ends with:
> debug1: Authentications that can continue:
> publickey,password,keyboard-interactive
> debug3: start over, passed a different list
> publickey,password,keyboard-interactive
> debug3: preferred publickey
> debug3: authmethod_lookup publickey
> debug3: remaining preferred:
> debug3: authmethod_is_enabled publickey
> debug1: Next authentication method: publickey
> debug1: Offering RSA public key: /usr/src/INET/openssh/regress/rsa
> debug3: send_pubkey_test
> debug2: we sent a publickey packet, wait for reply
> debug1: Server accepts key: pkalg ssh-rsa blen 279
> debug2: input_userauth_pk_ok: fp
> SHA256:9nhdTr/rVwghJZfRSbSVGw1Rb7TuhygvZoYal45dJ98
> debug3: sign_and_send_pubkey: RSA
> SHA256:9nhdTr/rVwghJZfRSbSVGw1Rb7TuhygvZoYal45dJ98
> debug1: Authentications that can continue:
> publickey,password,keyboard-interactive
> debug2: we did not send a packet, disable method
> debug1: No more authentication methods to try.
> Permission denied (publickey,password,keyboard-interactive).
> FAIL: ssh connect with protocol 2 failed
> ?
> ?failed-sshd.log ends with:
> debug2: input_userauth_request: try method publickey [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
> debug3: mm_answer_keyallowed: key_from_blob: 0x7f0b6f1499d0
> debug1: temporarily_use_uid: 0/0 (e=0/0)
> debug1: trying public key file
> /usr/src/INET/openssh/regress/authorized_keys_root
> debug1: fd 4 clearing O_NONBLOCK
> debug1: matching key found: file
> /usr/src/INET/openssh/regress/authorized_keys_root, line 1 RSA
> SHA256:9nhdTr/rVwghJZfRSbSVGw1Rb7TuhygvZoYal45dJ98
> debug1: restore_uid: 0/0
> debug3: mm_answer_keyallowed: key 0x7f0b6f1499d0 is allowed
> debug3: mm_request_send entering: type 23
> debug3: mm_key_verify entering [preauth]
> debug3: mm_request_send entering: type 24 [preauth]
> debug3: mm_key_verify: waiting for MONITOR_ANS_KEYVERIFY [preauth]
> debug3: mm_request_receive_expect entering: type 25 [preauth]
> debug3: mm_request_receive entering [preauth]
> debug3: mm_request_receive entering
> debug3: monitor_read: checking request 24
> debug3: mm_answer_keyverify: key 0x7f0b6f149c30 signature verified
> debug3: mm_request_send entering: type 25
> ROOT LOGIN REFUSED FROM 127.0.0.1
> Failed publickey for root from 127.0.0.1 port 36951 ssh2: RSA
> SHA256:9nhdTr/rVwghJZfRSbSVGw1Rb7TuhygvZoYal45dJ98
> debug2: userauth_pubkey: authenticated 1 pkalg ssh-rsa [preauth]
> ROOT LOGIN REFUSED FROM 127.0.0.1 [preauth]
> debug3: userauth_finish: failure partial=0 next
> methods="publickey,password,keyboard-interactive" [preauth]
> FAIL: ssh connect with protocol 2 failed
> Connection closed by 127.0.0.1 [preauth]
> debug1: do_cleanup [preauth]
> debug1: monitor_read_log: child log fd closed
> debug3: mm_request_receive entering
> debug1: do_cleanup
> debug1: Killing privsep child 25262
> 
> 
> On Sat, May 30, 2015 at 9:30 AM, Kevin Brott <kevin.brott at gmail.com> wrote:
> 
> >
> > Starting building/testing for the lab systems I have Monday.
> >
> > Any chance a fix for Bug 2404 <
> > https://bugzilla.mindrot.org/show_bug.cgi?id=2404> could get wedged in
> > before release?
> >
> > --
> > # include <stddisclaimer.h>
> > /* Kevin Brott <Kevin.Brott at gmail.com> */
> >
> >
> 
> 
> -- 
> # include <stddisclaimer.h>
> /* Kevin  Brott <Kevin.Brott at gmail.com> */
> _______________________________________________
> 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  Mon Jun  1 11:30:56 2015
From: djm at mindrot.org (Damien Miller)
Date: Mon, 1 Jun 2015 11:30:56 +1000 (AEST)
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <20150530211235.GA20740@doctor.nl2k.ab.ca>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <5569E593.6050708@gmail.com>
 <CAMv58rbvtdf6PD2maVDbqB-22sU9KLOsahrN--mDDqaicEcfpA@mail.gmail.com>
 <20150530211235.GA20740@doctor.nl2k.ab.ca>
Message-ID: <alpine.BSO.2.20.1506011130450.19595@natsu.mindrot.org>

On Sat, 30 May 2015, The Doctor wrote:

> So far BSD/OS and opensh 6.9 pre works with ZOC and Tera Term.
> 
> Putty and WINSCP are broken.

broken how?

From djm at mindrot.org  Mon Jun  1 11:33:13 2015
From: djm at mindrot.org (Damien Miller)
Date: Mon, 1 Jun 2015 11:33:13 +1000 (AEST)
Subject: FWD: enable forwarding to remote named sockets in ssh
In-Reply-To: <556A3AA2.8040707@teco.edu>
References: <556A3AA2.8040707@teco.edu>
Message-ID: <alpine.BSO.2.20.1506011131520.19595@natsu.mindrot.org>

Hi,

Did you file a bug at https://bugzilla.mindrot.org/ ? That's the best
way to ensure fixes don't get lost.

-d

On Sun, 31 May 2015, Till Riedel wrote:

> Dear openssh developers,
> 
> has the problem related to remote unix socket forwarding to a local port 
> ever been fixed? (see message below: ssh -L 12345:/tmp/sock)
> 
> I could not find any code containing the patch (maybe i am looking in 
> the wrong places)
> 
> I actually had the same problem and the feature is really handy if you 
> are working on a windows machine.
> 
> Help is apreciated. Thanks!
> 
> Best regards,
> 
> Till Riedel
> 
> -------- Forwarded Message --------
> List:       openbsd-tech
> Subject:    enable forwarding to remote named sockets in ssh
> From:       Jared Yanovich <slovichon () gmail ! com>
> Date:       2014-08-08 20:38:11
> Message-ID: 20140808203811.GK16425 () nightderanger ! psc ! edu
> [Download message RAW]
> 
> I cannot forward to a socket on the remote host ("No forward host name.").
> 
> Example:
> 
>    ssh -L 12345:/tmp/sock
> 
> Index: channels.c
> ===================================================================
> RCS file: /cvs/src/usr.bin/ssh/channels.c,v
> retrieving revision 1.336
> diff -u -p -r1.336 channels.c
> --- channels.c	15 Jul 2014 15:54:14 -0000	1.336
> +++ channels.c	8 Aug 2014 20:31:29 -0000
> @@ -2771,13 +2770,18 @@ channel_setup_fwd_listener_tcpip(int typ
>   	    fwd->listen_host : fwd->connect_host;
>   	is_client = (type == SSH_CHANNEL_PORT_LISTENER);
> 
> -	if (host == NULL) {
> -		error("No forward host name.");
> -		return 0;
> -	}
> -	if (strlen(host) >= NI_MAXHOST) {
> -		error("Forward host name too long.");
> -		return 0;
> +	if (type == SSH_CHANNEL_PORT_LISTENER &&
> +	    fwd->connect_path)
> +		host = fwd->connect_path;
> +	else {
> +		if (host == NULL) {
> +			error("No forward host name.");
> +			return 0;
> +		}
> +		if (strlen(host) >= NI_MAXHOST) {
> +			error("Forward host name too long.");
> +			return 0;
> +		}
>   	}
> 
>   	/* Determine the bind address, cf. channel_fwd_bind_addr() comment */
> -- 
> Karlsruhe Institute of Technology (KIT)
> TECO - Technology for Pervasive Computing
> 
> Dr.-Ing. Dipl.-Inform. Till Riedel
> Research Director TECO
> 
> post: KIT, TecO, Vincenz-Priessnitz-Str. 1, 76131 Karlsruhe, Germany
> fon: +49 721 608-41706 , fax: +49 721 608-41702
> email: riedel at teco.edu , web: www.teco.edu/people/riedel
> 
> KIT ? University of the State of Baden-Wuerttemberg
> and National Large-scale Research Center of the Helmholtz Association
> _______________________________________________
> 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  Mon Jun  1 11:38:04 2015
From: djm at mindrot.org (Damien Miller)
Date: Mon, 1 Jun 2015 11:38:04 +1000 (AEST)
Subject: Using two agents
In-Reply-To: <556A7AE8.8070108@gmail.com>
References: <20150530120023.GA3477@colin.search.kasperd.net>
 <CAOCN9ry-PvBCXAB8XQ_29RtqaQMiYk0asZDJrBrc8H20B01SUA@mail.gmail.com>
 <20150530130010.GA3422@colin.search.kasperd.net>
 <20150530143806.GA274@tower.spodhuis.org>
 <CAOCN9rzSRrK5636kdZufjEJHtzLMrJa4q+NUaaxje0p3qCFH4g@mail.gmail.com>
 <20150530184134.32429.qmail@stuge.se>
 <CAOCN9rx1SkWn9ySc-hc=Fiepw0_HJ9WXzFTcf2VsB8RfbeJ8bw@mail.gmail.com>
 <556A7AE8.8070108@gmail.com>
Message-ID: <alpine.BSO.2.20.1506011134150.19595@natsu.mindrot.org>

On Sun, 31 May 2015, ?ngel Gonz?lez wrote:

> When you want unattended running over ssh even accross reboots,
> there's little option than having unprotected keys.

PKCS#11 token (e.g. a TPM) without a PIN. An attacker might be able to
steal use of the key, but they can't steal the key itself.

Otherwise, a hardware-free solution is to have an init script start a
ssh-agent at boot set to listen on a known socket, add keys to it and
then remove the keys from the filesystem.

-d

From root at doctor.nl2k.ab.ca  Mon Jun  1 13:31:03 2015
From: root at doctor.nl2k.ab.ca (Dave Shariff Yadallee - System Administrator a.k.a. The Root of the
 Problem)
Date: Sun, 31 May 2015 21:31:03 -0600
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <CALDDTe37pVp4QNR-O4c3yADpf-vivZ3D=xPBhcwZi3-R+K_EKQ@mail.gmail.com>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <5569E593.6050708@gmail.com>
 <CAMv58rbvtdf6PD2maVDbqB-22sU9KLOsahrN--mDDqaicEcfpA@mail.gmail.com>
 <20150530211235.GA20740@doctor.nl2k.ab.ca>
 <CALDDTe37pVp4QNR-O4c3yADpf-vivZ3D=xPBhcwZi3-R+K_EKQ@mail.gmail.com>
Message-ID: <20150601033103.GA2442@doctor.nl2k.ab.ca>

On Mon, Jun 01, 2015 at 08:48:48AM +1000, Darren Tucker wrote:
> On Sun, May 31, 2015 at 7:12 AM, The Doctor <doctor at doctor.nl2k.ab.ca>
> wrote:
> 
> > So far BSD/OS and opensh 6.9 pre works with ZOC and Tera Term.
> >
> > Putty and WINSCP are broken.
> >
> 
> Could you please elaborate on "broken"?  Which version of PuTTY?  (I'm not
> familiar with WinSCP versions but I believe the code is based on PuTTY, so
> I think if we figure out PuTTY then the same will probably apply to WinSCP).
> 
> Could you please run sshd and plink in debug mode ("/eg path/to/sshd -ddde
> -p 2022" and "plink -v -P 2022 yourhost")
>

What is plink?
 
> -- 
> Darren Tucker (dtucker at zip.com.au)
> GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
>     Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

-- 
For effective Internet Etiquette and communications read 
http://catb.org/jargon/html/T/top-post.html, http://idallen.com/topposting.html
& http://www.caliburn.nl/topposting.html

From djm at mindrot.org  Mon Jun  1 13:57:18 2015
From: djm at mindrot.org (Damien Miller)
Date: Mon, 1 Jun 2015 13:57:18 +1000 (AEST)
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <20150601033103.GA2442@doctor.nl2k.ab.ca>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <5569E593.6050708@gmail.com>
 <CAMv58rbvtdf6PD2maVDbqB-22sU9KLOsahrN--mDDqaicEcfpA@mail.gmail.com>
 <20150530211235.GA20740@doctor.nl2k.ab.ca>
 <CALDDTe37pVp4QNR-O4c3yADpf-vivZ3D=xPBhcwZi3-R+K_EKQ@mail.gmail.com>
 <20150601033103.GA2442@doctor.nl2k.ab.ca>
Message-ID: <alpine.BSO.2.20.1506011357040.19595@natsu.mindrot.org>

On Sun, 31 May 2015, Dave Shariff Yadallee - System Administrator a.k.a. The Root of the Problem wrote:

> > Could you please elaborate on "broken"?  Which version of PuTTY?  (I'm not
> > familiar with WinSCP versions but I believe the code is based on PuTTY, so
> > I think if we figure out PuTTY then the same will probably apply to WinSCP).
> > 
> > Could you please run sshd and plink in debug mode ("/eg path/to/sshd -ddde
> > -p 2022" and "plink -v -P 2022 yourhost")
> >
> 
> What is plink?

command-line putty ssh client

From dtucker at zip.com.au  Mon Jun  1 14:00:25 2015
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 1 Jun 2015 14:00:25 +1000
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <20150601033103.GA2442@doctor.nl2k.ab.ca>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <5569E593.6050708@gmail.com>
 <CAMv58rbvtdf6PD2maVDbqB-22sU9KLOsahrN--mDDqaicEcfpA@mail.gmail.com>
 <20150530211235.GA20740@doctor.nl2k.ab.ca>
 <CALDDTe37pVp4QNR-O4c3yADpf-vivZ3D=xPBhcwZi3-R+K_EKQ@mail.gmail.com>
 <20150601033103.GA2442@doctor.nl2k.ab.ca>
Message-ID: <CALDDTe3_HXKEUts8A4uOUy2Qwo+QGmUUMhxgR_HvbM_-r9eL1A@mail.gmail.com>

On Mon, Jun 1, 2015 at 1:31 PM, Dave Shariff Yadallee - System
Administrator a.k.a. The Root of the Problem <root at doctor.nl2k.ab.ca> wrote:

> On Mon, Jun 01, 2015 at 08:48:48AM +1000, Darren Tucker wrote:
>
[...]

> > Could you please run sshd and plink in debug mode ("/eg path/to/sshd
> -ddde
> > -p 2022" and "plink -v -P 2022 yourhost")
> >
>
> What is plink?
>

plink is PuTTY's command line tool.  You could probably also get the PuTTY
GUI to generate a debug log but I don't know how to do that offhand.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From kasperd at fzcpf.25.may.2015.kasperd.net  Mon Jun  1 17:37:44 2015
From: kasperd at fzcpf.25.may.2015.kasperd.net (Kasper Dupont)
Date: Mon, 1 Jun 2015 09:37:44 +0200
Subject: Using two agents
In-Reply-To: <alpine.BSO.2.20.1506011124050.19595@natsu.mindrot.org>
References: <20150530120023.GA3477@colin.search.kasperd.net>
 <alpine.BSO.2.20.1506011124050.19595@natsu.mindrot.org>
Message-ID: <20150601073744.GA3482@colin.search.kasperd.net>

On 01/06/15 11.28, Damien Miller wrote:
> On Sat, 30 May 2015, Kasper Dupont wrote:
> 
> > As far as I can tell when the ssh command uses an agent to
> > authenticate to a server and then forwards an agent to that server, it
> > will always use the same agent for both purposes.
> >
> > Has there been any attempt to make it possible for the ssh command
> > to use two different agents, such that I can use one agent to
> > authenticate and then forward a different agent to the server?
> 
> You could probably rig something up using the Unix domain socket
> forwaring that was added a couple of releases ago.

Wouldn't that require an updated server? What I had in mind
would be a fairly simple client side change that wouldn't
change the protocol used between client and server in any
way.

> 
> More generally, I've long wanted the ability to restrict which keys are
> made available through a forwarded-agent but doing so either requires
> teaching ssh most of the agent protocol and moving ssh into the trust
> path for agent keys, or a more substantial rearchitecture of how agents
> are forwarded (giving each ssh a long-lived socket to the agent, or some
> sort of cookie that stood for one instead of creating socket on-demand).

I have seen such a thing implemented externally to the ssh
client: http://serverfault.com/a/660299/214507

But if I were to use that tool, I would still like the ssh
client to use the unfiltered agent to authenticate and then
forward the filtered client.

-- 
Kasper Dupont -- Rigtige m?nd skriver deres egne backupprogrammer
#define _(_)"d.%.4s%."_"2s" /* This is my email address */
char*_="@2kaspner"_()"%03"_("4s%.")"t\n";printf(_+11,_+6,_,12,_+2,_+7,_+6);

From djm at mindrot.org  Mon Jun  1 17:51:43 2015
From: djm at mindrot.org (Damien Miller)
Date: Mon, 1 Jun 2015 17:51:43 +1000 (AEST)
Subject: Using two agents
In-Reply-To: <20150601073744.GA3482@colin.search.kasperd.net>
References: <20150530120023.GA3477@colin.search.kasperd.net>
 <alpine.BSO.2.20.1506011124050.19595@natsu.mindrot.org>
 <20150601073744.GA3482@colin.search.kasperd.net>
Message-ID: <alpine.BSO.2.20.1506011748050.18749@natsu.mindrot.org>

On Mon, 1 Jun 2015, Kasper Dupont wrote:

> > You could probably rig something up using the Unix domain socket
> > forwaring that was added a couple of releases ago.
> 
> Wouldn't that require an updated server?

Yes, it would need one with support for Unix domain socket forwarding.

> What I had in mind
> would be a fairly simple client side change that wouldn't
> change the protocol used between client and server in any
> way.

You could do this if you want, there's nothing particularly complicated
but the assumption of only working on a single agent socket is fairly
pervasive. I don't have any desire to add it to the client - it's the
sort of kludge that gets in the way of a better solution to the problem
and that we'd need to carry around forever.

-d

From calderon.thomas at gmail.com  Mon Jun  1 19:07:38 2015
From: calderon.thomas at gmail.com (Thomas Calderon)
Date: Mon, 1 Jun 2015 11:07:38 +0200
Subject: Using two agents
In-Reply-To: <alpine.BSO.2.20.1506011124050.19595@natsu.mindrot.org>
References: <20150530120023.GA3477@colin.search.kasperd.net>
 <alpine.BSO.2.20.1506011124050.19595@natsu.mindrot.org>
Message-ID: <CA+1ewKZeb9JmzuoWComDHqsfd2-wn=q4MSC0wVg-kH5PiDa64Q@mail.gmail.com>

Hi,

You might want to have a look at Caml Crush [1] which could provide you
with a software alternative.
Caml Crush is a PKCS#11 filtering proxy which can be used with PKCS#11
devices (hardware or software).

One way to have the desired functionality would be to have two instances of
Caml Crush running on your machine.
The first one would allow the first key-pair to be used and the second
instance, the second key-pair.
Now when connecting to your first SSH server, you would use Caml Crush
client library to connect to the first instance.
You would also leverage SSH to redirect the UNIX socket of the second
instance while connecting.
Thus while connected to the first hop, you would be able to use Caml Crush
client library to access your second key-pair through the exposed socket
(linked to the second Caml Crush instance).

I am pretty sure it might do the trick, although I have not yet tried the
UNIX socket redirection feature.

Cheers,

Thomas Calderon

[1] https://github.com/ANSSI-FR/caml-crush

On Mon, Jun 1, 2015 at 3:28 AM, Damien Miller <djm at mindrot.org> wrote:

> On Sat, 30 May 2015, Kasper Dupont wrote:
>
> > As far as I can tell when the ssh command uses an agent to
> > authenticate to a server and then forwards an agent to that server, it
> > will always use the same agent for both purposes.
> >
> > Has there been any attempt to make it possible for the ssh command
> > to use two different agents, such that I can use one agent to
> > authenticate and then forward a different agent to the server?
>
> You could probably rig something up using the Unix domain socket
> forwaring that was added a couple of releases ago.
>
> More generally, I've long wanted the ability to restrict which keys are
> made available through a forwarded-agent but doing so either requires
> teaching ssh most of the agent protocol and moving ssh into the trust
> path for agent keys, or a more substantial rearchitecture of how agents
> are forwarded (giving each ssh a long-lived socket to the agent, or some
> sort of cookie that stood for one instead of creating socket on-demand).
>
> -d
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

From vinschen at redhat.com  Mon Jun  1 23:30:38 2015
From: vinschen at redhat.com (Corinna Vinschen)
Date: Mon, 1 Jun 2015 15:30:38 +0200
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
Message-ID: <20150601133038.GL4308@calimero.vinschen.de>

Hi,

On May 29 17:12, Damien Miller wrote:
> Hi,
> 
> OpenSSH 6.9 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This release contains
> some substantial new features and a number of bugfixes.

I tested git master HEAD on Cygwin 2.0.2 x86_64.

Builds and runs OOTB, all tests pass.


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150601/fc2419b0/attachment-0001.bin>

From scott_n at xypro.com  Tue Jun  2 04:45:12 2015
From: scott_n at xypro.com (Scott Neugroschl)
Date: Mon, 1 Jun 2015 18:45:12 +0000
Subject: Privsep (was 6.9 testing)
Message-ID: <D358E5B1511A314F8160ADC6F375498706A0DA97@XYSVEX02.XYPRO-23.LOCAL>


On Sunday, May 31, 2015 4:03 PM, Darren Tucker wrote:

> The privsep chroot path is specified at build time (./configure --with-privsep-path if you want to change it).

I'm still trying to figure out why this, along with the privsep user, is a compile time option instead of an sshd_config option

I realize you're busy trying to get 6.9 out the door, so I understand if there's a delay in response.

Thanks,

ScottN
 




From tgc at jupiterrise.com  Tue Jun  2 06:17:34 2015
From: tgc at jupiterrise.com (Tom G. Christensen)
Date: Mon, 01 Jun 2015 22:17:34 +0200
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
Message-ID: <556CBDDE.4080303@jupiterrise.com>

On 29/05/15 09:12, Damien Miller wrote:
> OpenSSH 6.9 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible.
>

I've tested 51a1c21 from git.

sparc-sun-solaris2.9: all tests passed
sparc-sun-solaris2.8: all tests passed

On sparc-sun-solaris2.6 and sparc-sun-solaris2.7 the testsuite fails:
run test cfgparse.sh ...
reparse minimal config
reparse regress config
listenaddress order
bad addr or host: ::1 (no address associated with name)
listenaddress order 1
bad addr or host: ::1 (no address associated with name)
listenaddress order 2
failed config parse
gmake[1]: *** [t-exec] Error 1

Solaris < 8 does not support ipv6.

-tgc

From carson at taltos.org  Tue Jun  2 07:21:50 2015
From: carson at taltos.org (Carson Gaspar)
Date: Mon, 01 Jun 2015 14:21:50 -0700
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <CA+U3Mf6hdF9+HZDhAKXzO8ONS3gKmaZ_XDwoF25r04UeRc7_mA@mail.gmail.com>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <CA+U3Mf7A+AaTkD85+8khpF5KoMQQNDKpK7De1cik1+jDWXKETg@mail.gmail.com>
 <CA+U3Mf7tQGK0JAuSM=Aa_2+HctBqKrycoDTOs5z8ALZasH1Bqw@mail.gmail.com>
 <CA+U3Mf6hdF9+HZDhAKXzO8ONS3gKmaZ_XDwoF25r04UeRc7_mA@mail.gmail.com>
Message-ID: <556CCCEE.4020609@taltos.org>

On 5/30/2015 9:14 PM, Sevan / Venture37 wrote:
> Solaris 11.2 with GCC 4.9
> test_hostkeys:
> regress/unittests/hostkeys/test_iterate.c:117 test #1
> "hostkeys_iterate all with key parse" - entry 3/61, file line 3
> ASSERT_U_INT_EQ(l->status, expected_status) failed:
>     l->status = 0 / 0x0
> expected_status = 1 / 0x1
> *** Signal 6 - core dumped
> make: Fatal error: Command failed for target `unit'
> Current working directory /home/sme/openssh/regress
> *** Error code 1
> make: Fatal error: Command failed for target `tests'

I just ran tests on portable git 51a1c21 on Solaris 11.2 compiled with 
Solaris Studio 12.4 and everything passed. Not sure if the code base 
changed since Sevan's tests or what.

-- 
Carson



From riedel at teco.edu  Tue Jun  2 07:36:24 2015
From: riedel at teco.edu (Till Riedel)
Date: Mon, 01 Jun 2015 23:36:24 +0200
Subject: FWD: enable forwarding to remote named sockets in ssh
In-Reply-To: <alpine.BSO.2.20.1506011131520.19595@natsu.mindrot.org>
References: <556A3AA2.8040707@teco.edu>
 <alpine.BSO.2.20.1506011131520.19595@natsu.mindrot.org>
Message-ID: <556CD058.8040001@teco.edu>

Thx,

I filed it as #2406.

Patch still seems to work against current snapshot.

I didn't post it originally because it already was reported once and I 
couldn't figure out why it wasn't followed up on.

BR

Till

PS: the patch would make quite a difference for docker for windows users 
as it enables one to forward the client to a remote machine without 
changing the host config.


Am 01.06.2015 um 03:33 schrieb Damien Miller:
> Hi,
>
> Did you file a bug at https://bugzilla.mindrot.org/ ? That's the best
> way to ensure fixes don't get lost.
>
> -d
>
> On Sun, 31 May 2015, Till Riedel wrote:
>
>> Dear openssh developers,
>>
>> has the problem related to remote unix socket forwarding to a local port
>> ever been fixed? (see message below: ssh -L 12345:/tmp/sock)
>>
>> I could not find any code containing the patch (maybe i am looking in
>> the wrong places)
>>
>> I actually had the same problem and the feature is really handy if you
>> are working on a windows machine.
>>
>> Help is apreciated. Thanks!
>>
>> Best regards,
>>
>> Till Riedel
>>
>> -------- Forwarded Message --------
>> List:       openbsd-tech
>> Subject:    enable forwarding to remote named sockets in ssh
>> From:       Jared Yanovich <slovichon () gmail ! com>
>> Date:       2014-08-08 20:38:11
>> Message-ID: 20140808203811.GK16425 () nightderanger ! psc ! edu
>> [Download message RAW]
>>
>> I cannot forward to a socket on the remote host ("No forward host name.").
>>
>> Example:
>>
>>     ssh -L 12345:/tmp/sock
>>
>> Index: channels.c
>> ===================================================================
>> RCS file: /cvs/src/usr.bin/ssh/channels.c,v
>> retrieving revision 1.336
>> diff -u -p -r1.336 channels.c
>> --- channels.c	15 Jul 2014 15:54:14 -0000	1.336
>> +++ channels.c	8 Aug 2014 20:31:29 -0000
>> @@ -2771,13 +2770,18 @@ channel_setup_fwd_listener_tcpip(int typ
>>    	    fwd->listen_host : fwd->connect_host;
>>    	is_client = (type == SSH_CHANNEL_PORT_LISTENER);
>>
>> -	if (host == NULL) {
>> -		error("No forward host name.");
>> -		return 0;
>> -	}
>> -	if (strlen(host) >= NI_MAXHOST) {
>> -		error("Forward host name too long.");
>> -		return 0;
>> +	if (type == SSH_CHANNEL_PORT_LISTENER &&
>> +	    fwd->connect_path)
>> +		host = fwd->connect_path;
>> +	else {
>> +		if (host == NULL) {
>> +			error("No forward host name.");
>> +			return 0;
>> +		}
>> +		if (strlen(host) >= NI_MAXHOST) {
>> +			error("Forward host name too long.");
>> +			return 0;
>> +		}
>>    	}
>>
>>    	/* Determine the bind address, cf. channel_fwd_bind_addr() comment */
>> --
>> Karlsruhe Institute of Technology (KIT)
>> TECO - Technology for Pervasive Computing
>>
>> Dr.-Ing. Dipl.-Inform. Till Riedel
>> Research Director TECO
>>
>> post: KIT, TecO, Vincenz-Priessnitz-Str. 1, 76131 Karlsruhe, Germany
>> fon: +49 721 608-41706 , fax: +49 721 608-41702
>> email: riedel at teco.edu , web: www.teco.edu/people/riedel
>>
>> KIT ? University of the State of Baden-Wuerttemberg
>> and National Large-scale Research Center of the Helmholtz Association
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>

-- 
Karlsruhe Institute of Technology (KIT)
TECO - Technology for Pervasive Computing

Dr.-Ing. Dipl.-Inform. Till Riedel
Research Director TECO

post: KIT, TecO, Vincenz-Priessnitz-Str. 1, 76131 Karlsruhe, Germany
fon: +49 721 608-41706 , fax: +49 721 608-41702
email: riedel at teco.edu , web: www.teco.edu/people/riedel

KIT ? University of the State of Baden-Wuerttemberg
and National Large-scale Research Center of the Helmholtz Association

From dtucker at zip.com.au  Tue Jun  2 07:45:30 2015
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 2 Jun 2015 07:45:30 +1000
Subject: Privsep (was 6.9 testing)
In-Reply-To: <D358E5B1511A314F8160ADC6F375498706A0DA97@XYSVEX02.XYPRO-23.LOCAL>
References: <D358E5B1511A314F8160ADC6F375498706A0DA97@XYSVEX02.XYPRO-23.LOCAL>
Message-ID: <CALDDTe0n4scMASJtbtDWrXZUgUPv1bh2ckxC=p=rDee6_w=0NQ@mail.gmail.com>

On Tue, Jun 2, 2015 at 4:45 AM, Scott Neugroschl <scott_n at xypro.com> wrote:

>
> On Sunday, May 31, 2015 4:03 PM, Darren Tucker wrote:
>
> > The privsep chroot path is specified at build time (./configure
> --with-privsep-path if you want to change it).
>
> I'm still trying to figure out why this, along with the privsep user, is a
> compile time option instead of an sshd_config option
>

Because it's not something you need to change very much and fewer knobs is
better, especially in security critical parts like the pre-auth chroot.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From Todd.Miller at courtesan.com  Tue Jun  2 08:43:15 2015
From: Todd.Miller at courtesan.com (Todd C. Miller)
Date: Mon, 01 Jun 2015 16:43:15 -0600
Subject: FWD: enable forwarding to remote named sockets in ssh
In-Reply-To: Your message of "Mon, 01 Jun 2015 23:36:24 +0200."
 <556CD058.8040001@teco.edu>
References: <556A3AA2.8040707@teco.edu>
 <alpine.BSO.2.20.1506011131520.19595@natsu.mindrot.org><556CD058.8040001@teco.edu>
Message-ID: <201506012243.t51MhIDh008373@newmailhub.uq.edu.au>

I'd prefer the following.

 - todd

Index: channels.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/channels.c,v
retrieving revision 1.343
diff -u -p -u -r1.343 channels.c
--- channels.c	8 May 2015 03:25:07 -0000	1.343
+++ channels.c	1 Jun 2015 22:12:31 -0000
@@ -2778,17 +2778,21 @@ channel_setup_fwd_listener_tcpip(int typ
 	char ntop[NI_MAXHOST], strport[NI_MAXSERV];
 	in_port_t *lport_p;
 
-	host = (type == SSH_CHANNEL_RPORT_LISTENER) ?
-	    fwd->listen_host : fwd->connect_host;
 	is_client = (type == SSH_CHANNEL_PORT_LISTENER);
 
-	if (host == NULL) {
-		error("No forward host name.");
-		return 0;
-	}
-	if (strlen(host) >= NI_MAXHOST) {
-		error("Forward host name too long.");
-		return 0;
+	if (is_client && fwd->connect_path != NULL) {
+		host = fwd->connect_path;
+	} else {
+		host = (type == SSH_CHANNEL_RPORT_LISTENER) ?
+		    fwd->listen_host : fwd->connect_host;
+		if (host == NULL) {
+			error("No forward host name.");
+			return 0;
+		}
+		if (strlen(host) >= NI_MAXHOST) {
+			error("Forward host name too long.");
+			return 0;
+		}
 	}
 
 	/* Determine the bind address, cf. channel_fwd_bind_addr() comment */

From mancha1 at zoho.com  Tue Jun  2 10:17:50 2015
From: mancha1 at zoho.com (mancha)
Date: Tue, 2 Jun 2015 00:17:50 +0000
Subject: Weak DH primes and openssh
In-Reply-To: <20150527025539.GA13936@zoho.com>
References: <555DDD09.3090606@debian.org>
 <3514793.3M2ItnNxuE@pintsize.usersys.redhat.com>
 <87lhgbkzf2.fsf@alice.fifthhorseman.net>
 <2557140.HoCJ72uSvu@pintsize.usersys.redhat.com>
 <87y4kbjgty.fsf@alice.fifthhorseman.net>
 <20150527025539.GA13936@zoho.com>
Message-ID: <20150602001750.GB3491@zoho.com>

On Wed, May 27, 2015 at 02:55:39AM +0000, mancha wrote:
> On Tue, May 26, 2015 at 03:10:01PM -0400, Daniel Kahn Gillmor wrote:
> > Does anyone have a pointer to any decent free software for
> > generating and verifying primality proofs?
> > 
> >           --dkg
> 
> OpenSSH generates strong pseudoprimes to k random bases (that if prime
> would be "safe primes"). I think Darren uses k=100 (confirmation?) so
> the way the math works out, each number he generates has at most a
> 1/(4^100) probability of being composite.  
> 
> In comparison, it's estimated the odds of getting crushed to death by
> a vending machine are 1 in 112 million.
> 
> Death-by-chocolate-bar is about
> 14,347,661,109,455,270,317,338,947,253,046,094,665,376,812,444,489,221
> more likely to happen to you than having a given "Darren-prime" turn
> out to be composite.
> 
> The take-away, of course, is to always snack responsibly.
> 
> Nonetheless, the most we can currently say is the numbers are almost
> surely prime. Certainty would be nice.
> 
> ECPP is the fastest prime proving algorithm that also provides
> certificates (I think) and PRIMO is the king-of-the-hill
> implementation (others exist but are significantly slower with bigger
> numbers).
> 
> Though as you mentioned PRIMO's not libre (just free), the math in the
> certificates is open-source and that's really the critical part here.
> 
> The proofs themselves are sequences of steps that at each step (except
> the last) prove a number N is prime if a smaller number R is prime.
> Every subsequent step takes its N from the previous step's R and this
> continues until we arrive at an R < 34*10^13 because such an R can be
> proven prime if it is a strong pseudoprime to the base of the 7 primes
> smaller than 19 (i.e. 2, 3, 5, 7, 11, 13, 17)
> 
> TL;DR
> 
> With PRIMO's help, I've proved the first 200 strong pseudoprimes in
> the latest v1.12 moduli file are indeed prime. Darren, so far you're
> batting a thousand!
> 
> I've uploaded my proofs to factordb.com for independent verification
> and complementary confirmation proofs.
> 
> For example, check out the 4th prime in Darren's new moduli file: 
> 
> https://tinyurl.com/pg66aq5
> 
> As I write this I've checked through #209. Those with spare CPU cycles
> on 64-bit Linux can help with the 65 strong pseudoprimes remaining
> (#210 to #274). 
> 
> Those who wish to help should get PRIMO [1] and grab the full set of
> input files I made:
> 
> http://sf.net/projects/mancha/files/misc/openssh-moduli-20150522_primo.tar.bz2
> 
> The 7680-bit moduli (#225 - #248) and 8192-bit moduli (#249 - #274)
> are up for grabs. Probably best if you claim your range to avoid
> effort duplication.
> 
> --mancha
> 
> PS In addition to factordb.com, ecpp-dj [2] can verify PRIMO certs.
> ecpp-dj also proves primality but it is slower than PRIMO and more
> importantly its cert format can't be independently verified.
> 
> ------
> 
> [1] http://www.ellipsa.eu/public/primo/files/primo-411-lx64.7z
> [2] http://sti15.com/nt/ecpp-dj-1.04.tar.gz

I was not as clear in my above postscript as I should have been. What I
meant to say is there aren't independent software implementations that
can verify ecpp-dj generated proofs.  

That said, the certificate format is documented so one can be manually
check ecpp-dj certs by verifying requisite conditions are satisfied for
the math theorems used by its tests.

Time permitting, I plan to dig deeper into this promising program.

--mancha
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150602/29958413/attachment.bin>

From dtucker at zip.com.au  Tue Jun  2 11:39:31 2015
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 2 Jun 2015 11:39:31 +1000
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <20150601133038.GL4308@calimero.vinschen.de>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <20150601133038.GL4308@calimero.vinschen.de>
Message-ID: <20150602013931.GA7695@gate.dtucker.net>

On Mon, Jun 01, 2015 at 03:30:38PM +0200, Corinna Vinschen wrote:
> Hi,
> 
> On May 29 17:12, Damien Miller wrote:
> > Hi,
> > 
> > OpenSSH 6.9 is almost ready for release, so we would appreciate testing
> > on as many platforms and systems as possible. This release contains
> > some substantial new features and a number of bugfixes.
> 
> I tested git master HEAD on Cygwin 2.0.2 x86_64.

Thanks!  I'd like to add this small Cygwin change, could you please
sanity-check?

diff --git a/openbsd-compat/bsd-cygwin_util.c b/openbsd-compat/bsd-cygwin_util.c
index a2d8212..8672ccf 100644
--- a/openbsd-compat/bsd-cygwin_util.c
+++ b/openbsd-compat/bsd-cygwin_util.c
@@ -68,7 +68,7 @@ cygwin_ssh_privsep_user()
       if (cygwin_internal (CW_CYGNAME_FROM_WINNAME, "sshd", cyg_privsep_user,
 			   sizeof cyg_privsep_user) != 0)
 #endif
-	strcpy (cyg_privsep_user, "sshd");
+	strlcpy(cyg_privsep_user, "sshd", sizeof(cyg_privsep_user));
     }
   return cyg_privsep_user;
 }

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From vinschen at redhat.com  Tue Jun  2 18:44:53 2015
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 2 Jun 2015 10:44:53 +0200
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <20150602013931.GA7695@gate.dtucker.net>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <20150601133038.GL4308@calimero.vinschen.de>
 <20150602013931.GA7695@gate.dtucker.net>
Message-ID: <20150602084453.GB4308@calimero.vinschen.de>

Hi Darren,

On Jun  2 11:39, Darren Tucker wrote:
> On Mon, Jun 01, 2015 at 03:30:38PM +0200, Corinna Vinschen wrote:
> > Hi,
> > 
> > On May 29 17:12, Damien Miller wrote:
> > > Hi,
> > > 
> > > OpenSSH 6.9 is almost ready for release, so we would appreciate testing
> > > on as many platforms and systems as possible. This release contains
> > > some substantial new features and a number of bugfixes.
> > 
> > I tested git master HEAD on Cygwin 2.0.2 x86_64.
> 
> Thanks!  I'd like to add this small Cygwin change, could you please
> sanity-check?
> 
> diff --git a/openbsd-compat/bsd-cygwin_util.c b/openbsd-compat/bsd-cygwin_util.c
> index a2d8212..8672ccf 100644
> --- a/openbsd-compat/bsd-cygwin_util.c
> +++ b/openbsd-compat/bsd-cygwin_util.c
> @@ -68,7 +68,7 @@ cygwin_ssh_privsep_user()
>        if (cygwin_internal (CW_CYGNAME_FROM_WINNAME, "sshd", cyg_privsep_user,
>  			   sizeof cyg_privsep_user) != 0)
>  #endif
> -	strcpy (cyg_privsep_user, "sshd");
> +	strlcpy(cyg_privsep_user, "sshd", sizeof(cyg_privsep_user));
>      }
>    return cyg_privsep_user;
>  }

that patch is fine, albeit not really necessary.  The source string is a
constant string of 5 bytes and the target buffer size is guaranteed to
be larger than 5 bytes (DNLEN = 15, UNLEN = 256).


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150602/5ee75a87/attachment.bin>

From dgy.jr92 at gmail.com  Tue Jun  2 23:46:58 2015
From: dgy.jr92 at gmail.com (=?UTF-8?Q?Gy=C3=B6rgy_Demarcsek_Ifj=2E?=)
Date: Tue, 2 Jun 2015 15:46:58 +0200
Subject: OpenSSH Linux portable patch proposal
Message-ID: <CAA08f1Uo+DEDWhf4M=FCg0VLyuvU=++P9Vwz_1j4kAEW7NvJAQ@mail.gmail.com>

Dear OpenSSH Developers,

I would like to propose a patch to OpenSSH for Linux. In the recent few
months, I have encountered a scenario where a PAM module used for
authentication in SSH should be informed about the previous successful
authentication methods. I described the complete scenario here:
http://serverfault.com/questions/690038/openssh-two-factor-authentication-combined-with-kerberos-public-key
In this use case, I want to introduce a 2nd factor for authentication while
accepting public key or GSSAPI authentication as first factor. If and only
if none of those methods were successful, a password authentication should
be performed before the second factor.

I also e-mailed this to this mailing list on 4 May. On the basis of a reply
from Damien Miller, there is currently no way to fully accomplish this
scenario with OpenSSH server. So I have made a PoC implementation that I
think does the trick:

https://github.com/dgyuri92/openssh-portable/commit/4a006cad8e3f8b9277ce41747d11261175c161e2

Would you be so kind as to take a look at it? Do you think it could be
beneficial for other users too? I think it would be a nice feature to have,
especially in use cases like mine and it is quite a small patch. Is there a
chance that this patch - or a functionally equivalent one - can be
integrated into future releases?

Thank you very much!

Cheers,
Gy?rgy Demarcsek

From ronf at timeheart.net  Wed Jun  3 00:22:35 2015
From: ronf at timeheart.net (Ron Frederick)
Date: Tue, 2 Jun 2015 07:22:35 -0700
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <CALDDTe3nzwG7nEwuzU8z3SV5bM_9rXYoDfKaOPo_1QQ62gtN5Q@mail.gmail.com>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <03554CDD-7488-4823-B290-D59A49C3A2AF@timeheart.net>
 <CALDDTe3nzwG7nEwuzU8z3SV5bM_9rXYoDfKaOPo_1QQ62gtN5Q@mail.gmail.com>
Message-ID: <0E8AB1FE-071A-4099-9C6C-BD5BD1730B21@timeheart.net>

On May 31, 2015, at 4:03 PM, Darren Tucker <dtucker at zip.com.au> wrote:
> On Sun, May 31, 2015 at 3:37 AM, Ron Frederick <ronf at timeheart.net> wrote:
> On May 29, 2015, at 12:12 AM, Damien Miller <djm at mindrot.org> wrote:
> > OpenSSH 6.9 is almost ready for release, so we would appreciate testing
> > on as many platforms and systems as possible. This release contains
> > some substantial new features and a number of bug fixes.
> 
> I just compiled and ran the tests for openssl-snap-20150531 on Linux (Ubuntu 14.04.2 LTS) and MacOS (10.10.3).
> 
> On Linux, the code compiled cleanly. However, during ?make tests? I got the following error a number of times:
> 
> WARNING: /usr/local/etc/moduli does not exist, using fixed modulus
> 
> Most of the tests will still work with that file missing, but there's one test that specifically checks that the DH group sizes are right, and that'll fail (because the server doesn't have groups of the sizes it wants, but it'll fall back to the couple that are compiled in).  You can just copy the file into place if you like (as long as it's world readable), or you can use configure --sysconfdir to point it at wherever the file actually is.
>  
> Later in the test sequence I got the error:
> 
> run test connect.sh ...
> Missing privilege separation directory: /var/empty
> FATAL: sshd_proxy broken
> make[1]: *** [t-exec] Error 1
> make[1]: Leaving directory `/tmp/openssh/regress'
> make: *** [tests] Error 2
> make tests  153.92s user 4.68s system 98% cpu 2:41.52 total
> 
> I was not running as root at the time, as I wasn?t intending to install this version. It looks like it assumes that /var/empty will already exist, though, which it doesn?t on my system.
> 
> The privsep chroot path is specified at build time (./configure --with-privsep-path if you want to change it).

Ok, thanks. I?ve re-run the tests on Linux with --sysconfdir=/etc/ssh --with-privsep-path=/var/run, and I no longer see either of the issues mentioned above. With the above config option, all tests passed for me on Ubuntu 14.04.2 LTS.

 
> The currently installed sshd does have UsePrivilegeSeparation enabled, and it looks like the sshd user is set up with have /var/run/sshd as its home directory on this system, but the test script didn?t pick that up.
> 
> Having the chroot dir as the user's home dir is not a great idea.  If someone discovers a way to write inside the chroot (eg via a permission misconfiguration) then they can trivially escalate to full access that by creating authorized_keys or similar.

Sorry - I think you misunderstood me here. The directory picked by Ubuntu was not the user?s home directory. It was /var/run/sshd. I was just saying that the ?sshd? user added to the system had that configured as _its_ home directory. I wasn?t sure if that might be how OpenSSH was deciding where to look ? I didn?t realize when I said that that it was a compile-time configuration option.

 
> On MacOS, the code compiled, but there were a large number of warnings about constructs that were deprecated back in OS X 10.7. The output is quite large, but I?d be happy to provide it to anyone who wants it.
> 
> I would be interested in seeing it, although it's not something that we would be looking at working on at this time.  Could you please either send it to me off-list or file a bug at bugzilla.mindrot.org and attach the log?

Done. This is now filed as bz#2407. No hurry on this one, as the code still runs fine at the moment and passes all the tests. I just thought I?d report it to avoid future problems if those APIs are ever removed.
-- 
Ron Frederick
ronf at timeheart.net




From keisial at gmail.com  Wed Jun  3 08:01:55 2015
From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=)
Date: Wed, 03 Jun 2015 00:01:55 +0200
Subject: OpenSSH Linux portable patch proposal
In-Reply-To: <CAA08f1Uo+DEDWhf4M=FCg0VLyuvU=++P9Vwz_1j4kAEW7NvJAQ@mail.gmail.com>
References: <CAA08f1Uo+DEDWhf4M=FCg0VLyuvU=++P9Vwz_1j4kAEW7NvJAQ@mail.gmail.com>
Message-ID: <556E27D3.4070506@gmail.com>

On 02/06/15 15:46, Gy?rgy Demarcsek Ifj. wrote:
> So I have made a PoC implementation that I think does the trick:
>
> https://github.com/dgyuri92/openssh-portable/commit/4a006cad8e3f8b9277ce41747d11261175c161e2
>
> Would you be so kind as to take a look at it?

Minor cosmetic issue: you added space-indented lines to auth-pam.c, 
auth.h, auth2.c and session.c (last chunk), but those files are 
tab-indented.

You also removed a number of trailing spaces from the files, which make 
the patch harder to read.


> +  } else {
> +    am_copy = xstrdup(authctxt->last_auth_methods);
> +    free(authctxt->last_auth_methods);
> +    authctxt->last_auth_methods = xcalloc(strlen(am_copy) + 
> strlen(method) + 2, sizeof(char));
> +    strcpy(authctxt->last_auth_methods, am_copy);
> +    free(am_copy);
> +  }
Why not use realloc?

auth2_update_methods_lists() is called after authentication. Can't 
sshpam_auth_passwd be called
before auth2_update_methods_lists? (ie. last_auth_methods would be NULL) 
In that case do_pam_putenv()
would segfault...



From djm at mindrot.org  Wed Jun  3 09:46:47 2015
From: djm at mindrot.org (Damien Miller)
Date: Wed, 3 Jun 2015 09:46:47 +1000 (AEST)
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <0E8AB1FE-071A-4099-9C6C-BD5BD1730B21@timeheart.net>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <03554CDD-7488-4823-B290-D59A49C3A2AF@timeheart.net>
 <CALDDTe3nzwG7nEwuzU8z3SV5bM_9rXYoDfKaOPo_1QQ62gtN5Q@mail.gmail.com>
 <0E8AB1FE-071A-4099-9C6C-BD5BD1730B21@timeheart.net>
Message-ID: <alpine.BSO.2.20.1506030943070.19595@natsu.mindrot.org>

On Tue, 2 Jun 2015, Ron Frederick wrote:

> > The privsep chroot path is specified at build time (./configure --with-privsep-path if you want to change it).
>
> Ok, thanks. I?ve re-run the tests on Linux with --sysconfdir=/etc/ssh
> --with-privsep-path=/var/run, and I no longer see either of the issues
> mentioned above. With the above config option, all tests passed for me
> on Ubuntu 14.04.2 LTS.

You should use /var/run/sshd on Ubuntu. Don't use a directory with other
stuff in it.

> Done. This is now filed as bz#2407. No hurry on this one, as the code
>still runs fine at the moment and passes all the tests. I just thought
>I?d report it to avoid future problems if those APIs are ever removed.

Most of those are due to Apple soft-deprecating the OpenSSL libcrypto
API as a supported interface. If they ever fully deprecate it, we'll
ask users to build OpenSSH against an independent installation of
libcrypto.

-d

From djm at mindrot.org  Wed Jun  3 10:01:07 2015
From: djm at mindrot.org (Damien Miller)
Date: Wed, 3 Jun 2015 10:01:07 +1000 (AEST)
Subject: OpenSSH Linux portable patch proposal
In-Reply-To: <CAA08f1Uo+DEDWhf4M=FCg0VLyuvU=++P9Vwz_1j4kAEW7NvJAQ@mail.gmail.com>
References: <CAA08f1Uo+DEDWhf4M=FCg0VLyuvU=++P9Vwz_1j4kAEW7NvJAQ@mail.gmail.com>
Message-ID: <alpine.BSO.2.20.1506030949260.19595@natsu.mindrot.org>

On Tue, 2 Jun 2015, Gy?rgy Demarcsek Ifj. wrote:

> Dear OpenSSH Developers,
> 
> I would like to propose a patch to OpenSSH for Linux. In the recent few
> months, I have encountered a scenario where a PAM module used for
> authentication in SSH should be informed about the previous successful
> authentication methods. I described the complete scenario here:
> http://serverfault.com/questions/690038/openssh-two-factor-authentication-combined-with-kerberos-public-key

I've wanted to expose more information about how the user authenticated
to the environment for a while, but I think that if we do it then we
should include (at least) key fingerprints too. Something like:

SSH_USER_AUTH=hostbased RSA SHA256:Iw75Ex+Re8WyIjqHEukxHtwz2weTFTBLPD2J9doYEfU, publickey CA ED25519 SHA256:rLKEbjpoN2+kuMQB7EiPqaeHut65ZfSe/z1EaWtKEmk Cert ID djm at mindrot.org Serial 27908739, password

We could probably expose this to PAM as well, as SSH_COMPLETED_AUTH or
similar.

Could you please file a bug at https://bugzilla.mindrot.org/ to track
this feature?

-d

From ronf at timeheart.net  Wed Jun  3 10:43:03 2015
From: ronf at timeheart.net (Ron Frederick)
Date: Tue, 2 Jun 2015 17:43:03 -0700
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <alpine.BSO.2.20.1506030943070.19595@natsu.mindrot.org>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <03554CDD-7488-4823-B290-D59A49C3A2AF@timeheart.net>
 <CALDDTe3nzwG7nEwuzU8z3SV5bM_9rXYoDfKaOPo_1QQ62gtN5Q@mail.gmail.com>
 <0E8AB1FE-071A-4099-9C6C-BD5BD1730B21@timeheart.net>
 <alpine.BSO.2.20.1506030943070.19595@natsu.mindrot.org>
Message-ID: <E3EE8799-49F8-4E90-B68F-39B68CF45387@timeheart.net>

On Jun 2, 2015, at 4:46 PM, Damien Miller <djm at mindrot.org> wrote:
> On Tue, 2 Jun 2015, Ron Frederick wrote:
> 
>>> The privsep chroot path is specified at build time (./configure --with-privsep-path if you want to change it).
>> 
>> Ok, thanks. I?ve re-run the tests on Linux with --sysconfdir=/etc/ssh
>> --with-privsep-path=/var/run, and I no longer see either of the issues
>> mentioned above. With the above config option, all tests passed for me
>> on Ubuntu 14.04.2 LTS.
> 
> You should use /var/run/sshd on Ubuntu. Don't use a directory with other
> stuff in it.

Ok, thanks. I didn?t actually do an install with those parameters. I was just using them to get around the ?/var/empty? error that I got in my previous run, but I?ll keep this in mind if I upgrade OpenSSH myself on that system.


>> Done. This is now filed as bz#2407. No hurry on this one, as the code
>> still runs fine at the moment and passes all the tests. I just thought
>> I?d report it to avoid future problems if those APIs are ever removed.
> 
> Most of those are due to Apple soft-deprecating the OpenSSL libcrypto
> API as a supported interface. If they ever fully deprecate it, we'll
> ask users to build OpenSSH against an independent installation of
> libcrypto.

I see. Do you know if there is any way to add something to the Makefile to suppress the warnings in the meantime?

One of the other items I called out in the bug that wasn?t a deprecation was around the assignment of ssh1_3des_cdc to a ?do_cipher? function pointer. It looks like the issue there is that ssh1_3des_cbc is declared to take a ?size_t? as its last argument, where the do_cipher function pointer is expecting an ?unsigned int?. It looks like other instances of functions assigned to do_cipher use the type LIBCRYPTO_EVP_INL_TYPE as the type of this argument, but for some reason this wasn?t done in the ssh1 3des case. This looks like it would be an easy fix, though.

The last issue was clang not liking the ?-pie? switch on compilations.
-- 
Ron Frederick
ronf at timeheart.net




From dtucker at zip.com.au  Wed Jun  3 13:39:54 2015
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 3 Jun 2015 13:39:54 +1000
Subject: OpenSSH Linux portable patch proposal
In-Reply-To: <556E27D3.4070506@gmail.com>
References: <CAA08f1Uo+DEDWhf4M=FCg0VLyuvU=++P9Vwz_1j4kAEW7NvJAQ@mail.gmail.com>
 <556E27D3.4070506@gmail.com>
Message-ID: <CALDDTe3cyHKkLPuFz5Bp8Spy3TJUuykNg3oRnXb43-5GMQ4i5A@mail.gmail.com>

On Wed, Jun 3, 2015 at 8:01 AM, ?ngel Gonz?lez <keisial at gmail.com> wrote:

> On 02/06/15 15:46, Gy?rgy Demarcsek Ifj. wrote:
>
[...]

> You also removed a number of trailing spaces from the files, which make
> the patch harder to read.
>

We should clean up the trailing spaces upstream (there's more than I would
have thought) but that churn can wait until after the upcoming release.  I
agree that having no-op whitespace changes in the diff doesn't help.

Anyway, as to the diff itself:

+  if (authctxt->last_auth_methods == NULL) {
+    authctxt->last_auth_methods = xcalloc(strlen(method) + 2,
sizeof(char));

sizeof(char) == 1 by definition.

+  } else {
+    am_copy = xstrdup(authctxt->last_auth_methods);
+    free(authctxt->last_auth_methods);
+    authctxt->last_auth_methods = xcalloc(strlen(am_copy) + strlen(method)
+ 2, sizeof(char));
+    strcpy(authctxt->last_auth_methods, am_copy);

strcpy (and strcat) are not bounds checked (probably safe in this
particular case but we consider their use to be bad practice).

+    free(am_copy);
+  }
+
+  strcat(authctxt->last_auth_methods, method);
+  if (authctxt->num_auth_methods != 1)
+    strcat(authctxt->last_auth_methods, ",");

This seems to be an extremely complicated way of saying "append the method
to a comma separated list" (although it'll have a trailing comma, which I'm
not sure is intended.  How about something like:

if (authctxt->last_auth_methods == NULL)
    authctxt->last_auth_methods = xstrdup(method);
else {
    am_copy = authctxt->last_auth_methods;
    xasprintf(&authctxt->last_auth_methods, "%s,%s", am_copy, method);
    free(am_copy);
}

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From dtucker at zip.com.au  Wed Jun  3 13:55:34 2015
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 3 Jun 2015 13:55:34 +1000
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <20150602084453.GB4308@calimero.vinschen.de>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <20150601133038.GL4308@calimero.vinschen.de>
 <20150602013931.GA7695@gate.dtucker.net>
 <20150602084453.GB4308@calimero.vinschen.de>
Message-ID: <CALDDTe1RdY9P+sv_Avi2xuu5g1jb35bn2qdQ6FJ5Q-LvTKMNXg@mail.gmail.com>

In Tue, Jun 2, 2015 at 6:44 PM, Corinna Vinschen <vinschen at redhat.com>
wrote:
[...]

> that patch is fine, albeit not really necessary.


Thanks.


> The source string is a
> constant string of 5 bytes and the target buffer size is guaranteed to
> be larger than 5 bytes (DNLEN = 15, UNLEN = 256).


Assuming DNLEN and UNLEN don't change in future :-)

Anyway I'd like to be able to do "#pragma GCC poison strcpy" or
__attribute__((deprecated)) + -Werror or something one day to help stop
problematic functions creeping in where it might matter (assuming I can
figure out a way to do it without increasing the cost of keeping in sync
with OpenBSD).

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From hecht at hlrs.de  Thu Jun  4 01:36:23 2015
From: hecht at hlrs.de (Martin Hecht)
Date: Wed, 03 Jun 2015 17:36:23 +0200
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
Message-ID: <556F1EF7.1040105@hlrs.de>

openssh-SNAP-20150603 all tests passed for:

SUSE Linux Enterprise Server 11 SP3, OpenSSL 0.9.8j-fips 07 Jan 2009

Scientific Linux release 6.6 (Carbon), OpenSSL 1.0.1e-fips 11 Feb 2013

Ubuntu 14.04.2 LTS,  OpenSSL 1.0.1f 6 Jan 2014

The openssl versions are those shipped (and patched) by the distributions.
I did not run the tests as root, and the tests which require sudo were
skipped.


From openssh at tlinx.org  Thu Jun  4 07:10:30 2015
From: openssh at tlinx.org (L. A. Walsh)
Date: Wed, 03 Jun 2015 14:10:30 -0700
Subject: how to have ssh not disable local security policy?
Message-ID: <556F6D46.4010605@tlinx.org>

It seems something changed (maybe I'm missing a patch)
to turn off this message:
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
@         WARNING: UNPROTECTED PRIVATE KEY FILE!          @
@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@
Permissions 0650 for '/root/.ssh/id_rsa' are too open.
It is required that your private key files are NOT accessible by others.
This private key will be ignored.

It isn't.  The other permissions are controlled by the right
most digit which is 0.  Each user -- including root,
is in their own group, so allowing groups access to
be the same as user access is policy.

By forcing this protection on my setup, I can't
have the same home directory for my local and domain
users even though they are the same on the server.

But on the win-machine with home mounted directories,
it messes things up and people have to come up with
insecure work-arounds.  Group permissions != "others".

I did set the strictmodes to 'no', in the sshd_config
file... but I don't see a similar parameter in the
ssh file.  Am I missing something?

Thanks!


From calestyo at scientia.net  Thu Jun  4 09:08:35 2015
From: calestyo at scientia.net (Christoph Anton Mitterer)
Date: Thu, 04 Jun 2015 01:08:35 +0200
Subject: Weak DH primes and openssh
In-Reply-To: <87twusfewb.fsf@alice.fifthhorseman.net>
References: <555DDD09.3090606@debian.org>
 <2591117.cQXXSN3CjL@pintsize.usersys.redhat.com>
 <alpine.BSO.2.20.1505300008250.11037@natsu.mindrot.org>
 <1620119.MSLpl5Hm2D@pintsize.usersys.redhat.com>
 <87twusfewb.fsf@alice.fifthhorseman.net>
Message-ID: <1433372915.14463.9.camel@scientia.net>

On Sun, 2015-05-31 at 20:31 -0400, Daniel Kahn Gillmor wrote: 
> (e.g. a digest of the
> concatenated UTF-8 representations of the top headline from each of the
> 10 highest-circulation newspapers on the day of re-generation, or
> something similar).
I don't think this would be a good idea.

Government agencies may certainly have the power to influence this
enough, perhaps even without the newspaper being aware of it.
The same applies to basically all other "news" items, like the current
lottery numbers, the place of the most recent accident with > 10 death
victims, and so on.

Something that cannot be influenced by humans but is yet measurable by
many must be chosen.
Perhaps something based on the mean temperatures at the 10 biggest
cities in the world at the same date/time.
Or the most recent date/time/intensity of coronal mass ejections or
number of sun spots (which both has again the disadvantage that not many
people can measure it, thus it may again be subject to forgery).


Cheers,
Chris.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5313 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150604/bc16298f/attachment.bin>

From keisial at gmail.com  Thu Jun  4 09:13:16 2015
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Thu, 04 Jun 2015 01:13:16 +0200
Subject: how to have ssh not disable local security policy?
In-Reply-To: <556F6D46.4010605@tlinx.org>
References: <556F6D46.4010605@tlinx.org>
Message-ID: <556F8A0C.4070804@gmail.com>

On 03/06/15 23:10, L. A. Walsh wrote:
> It seems something changed (maybe I'm missing a patch)
> to turn off this message:
(...)
> Each user -- including root, is in their own group, so allowing groups 
> access to
> be the same as user access is policy.
>
> By forcing this protection on my setup, I can't
> have the same home directory for my local and domain
> users even though they are the same on the server.
>
> But on the win-machine with home mounted directories,
> it messes things up and people have to come up with
> insecure work-arounds.  (...)  Am I missing something?
You need to apply 
https://sources.debian.net/src/openssh/1:6.7p1-6/debian/patches/user-group-modes.patch/

I was convinced it was available as a ./configure switch but turns out 
it isn't upstreamed.
Darren, Damien could you reconsider the decision of not accepting this 
relatively common patch? After reading the discussion at 
https://bugzilla.mindrot.org/show_bug.cgi?id=1060 I also think there was 
a misunderstanding from your part.

I have reviewed the patch (note it is an improved version than the one 
submitted in the bug) and it seems suitable for inclusion.
I recommend however to add a setpwent() just before the getpwent() loop, 
to protect against the possibility of some library calling getpwent() 
before secure_permissions().


From keisial at gmail.com  Thu Jun  4 09:39:07 2015
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Thu, 04 Jun 2015 01:39:07 +0200
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
Message-ID: <556F901B.2030107@gmail.com>

On 29/05/15 09:12, Damien Miller wrote:
> Hi,
>
> OpenSSH 6.9 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible.

  $ ./configure --help | grep -F '\$'
   --with-ipaddr-display   Use ip address instead of hostname in \$DISPLAY
   --with-default-path=    Specify default \$PATH environment for server


The following patch solves it:

diff --git a/configure.ac b/configure.ac
index 68ce7d6..b6f9302 100644
--- a/configure.ac
+++ b/configure.ac
@@ -4356,7 +4356,7 @@ if test ! -z "$IPADDR_IN_DISPLAY" ; then
  else
         DISPLAY_HACK_MSG="no"
         AC_ARG_WITH([ipaddr-display],
-               [  --with-ipaddr-display   Use ip address instead of 
hostname in \$DISPLAY],
+               [  --with-ipaddr-display   Use ip address instead of 
hostname in $DISPLAY],
                 [
                         if test "x$withval" != "xno" ; then
                                 AC_DEFINE([IPADDR_IN_DISPLAY])
@@ -4402,7 +4402,7 @@ fi
  # Whether to mess with the default path
  SERVER_PATH_MSG="(default)"
  AC_ARG_WITH([default-path],
-       [  --with-default-path=    Specify default \$PATH environment 
for server],
+       [  --with-default-path=    Specify default $PATH environment for 
server],
         [
                 if test "x$external_path_file" = "x/etc/login.conf" ; then
                         AC_MSG_WARN([


From tim at multitalents.net  Thu Jun  4 14:55:13 2015
From: tim at multitalents.net (Tim Rice)
Date: Wed, 3 Jun 2015 21:55:13 -0700 (PDT)
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <556F901B.2030107@gmail.com>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <556F901B.2030107@gmail.com>
Message-ID: <alpine.UW2.2.11.1506032153370.7749@server01.int.multitalents.net>

On Thu, 4 Jun 2015, ?ngel Gonz?lez wrote:

> On 29/05/15 09:12, Damien Miller wrote:
> > Hi,
> > 
> > OpenSSH 6.9 is almost ready for release, so we would appreciate testing
> > on as many platforms and systems as possible.
> 
>  $ ./configure --help | grep -F '\$'
>   --with-ipaddr-display   Use ip address instead of hostname in \$DISPLAY
>   --with-default-path=    Specify default \$PATH environment for server

Thanks for the report.
Fix commited.

-- 
Tim Rice				Multitalents
tim at multitalents.net

From root at doctor.nl2k.ab.ca  Thu Jun  4 21:11:42 2015
From: root at doctor.nl2k.ab.ca (Dave Shariff Yadallee - System Administrator a.k.a. The Root of the
 Problem)
Date: Thu, 4 Jun 2015 05:11:42 -0600
Subject: Openssh 6.9 testing
Message-ID: <20150604111142.GA27861@doctor.nl2k.ab.ca>

Hello.

Just wondering how to testing for Putty.

I will do that against openssh-SNAP-20150604 today.

-- 
For effective Internet Etiquette and communications read 
http://catb.org/jargon/html/T/top-post.html, http://idallen.com/topposting.html
& http://www.caliburn.nl/topposting.html

From djm at mindrot.org  Fri Jun  5 15:00:52 2015
From: djm at mindrot.org (Damien Miller)
Date: Fri, 5 Jun 2015 15:00:52 +1000 (AEST)
Subject: Openssh 6.9 testing
In-Reply-To: <20150604111142.GA27861@doctor.nl2k.ab.ca>
References: <20150604111142.GA27861@doctor.nl2k.ab.ca>
Message-ID: <alpine.BSO.2.20.1506051454460.1384@natsu.mindrot.org>

On Thu, 4 Jun 2015, Dave Shariff Yadallee - System Administrator a.k.a. The Root of the Problem wrote:

> Hello.
> 
> Just wondering how to testing for Putty.
> 
> I will do that against openssh-SNAP-20150604 today.

You can do it manually, or there are a few regress/putty-*.sh tests
that could be beaten into working shape. You'll need puttygen and
plink installed and then you should be able to do something like:

make tests SKIP_UNIT=1 LTESTS='putty-ciphers putty-kex putty-transfer'

The tests are possibly a bit rusty, and might need some fixing...

-d

From aixtools at gmail.com  Sun Jun  7 10:02:17 2015
From: aixtools at gmail.com (aixtools)
Date: Sun, 07 Jun 2015 02:02:17 +0200
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <CALDDTe3+-DeJ1_CNtKhJUm2Gdh-EW-3XDdSKpZh32Gc_A4WY9A@mail.gmail.com>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <5569E593.6050708@gmail.com>
 <CAMv58rbvtdf6PD2maVDbqB-22sU9KLOsahrN--mDDqaicEcfpA@mail.gmail.com>
 <CALDDTe3+-DeJ1_CNtKhJUm2Gdh-EW-3XDdSKpZh32Gc_A4WY9A@mail.gmail.com>
Message-ID: <55738A09.4010303@gmail.com>

On 2015-06-01 1:06 AM, Darren Tucker wrote:
> You were running the tests as root?  I think we need to add
> PermitRootLogin=yes to the regression tests to cover this case.
I filed a bug report 
(https://bugzilla.mindrot.org/show_bug.cgi?id=2412), prematurely perhaps 
(i.e., I hope not a duplicate) - and doing a su to michael helped the 
tests along - a lot.

In the end some of the tests fail because AIX diff does not support the 
-u option. I shall rerun tomorrow with gnu diff installed.

As I never use sudo - how is "make tests" expected to work on pristine 
system? Or will sudo just default to letting everyone become root so 
"rootlike" things can be tested? (This is why for builds I test as root 
- so applications can verify they drop "super" powers.

Please note: that this build that is passing tests is the same build 
process (less one argument --without-openssl). So, I am hoping you will 
be able to get "make tests" working (on AIX) in time for 6.9p1. (and I 
requested the https://bugzilla.mindrot.org/show_bug.cgi?id=2370 be 
reopened - or do you prefer a new one as the "symptom" has changed.

* I have not forgotten it is 'experimental' - but I would love to be 
able to try it in production!

Details are at https://bugzilla.mindrot.org/show_bug.cgi?id=2412

From djm at mindrot.org  Sun Jun  7 13:13:29 2015
From: djm at mindrot.org (Damien Miller)
Date: Sun, 7 Jun 2015 13:13:29 +1000 (AEST)
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <55738A09.4010303@gmail.com>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <5569E593.6050708@gmail.com>
 <CAMv58rbvtdf6PD2maVDbqB-22sU9KLOsahrN--mDDqaicEcfpA@mail.gmail.com>
 <CALDDTe3+-DeJ1_CNtKhJUm2Gdh-EW-3XDdSKpZh32Gc_A4WY9A@mail.gmail.com>
 <55738A09.4010303@gmail.com>
Message-ID: <alpine.BSO.2.20.1506071311450.1454@natsu.mindrot.org>

On Sun, 7 Jun 2015, aixtools wrote:

> On 2015-06-01 1:06 AM, Darren Tucker wrote:
> > You were running the tests as root?  I think we need to add
> > PermitRootLogin=yes to the regression tests to cover this case.
> I filed a bug report (https://bugzilla.mindrot.org/show_bug.cgi?id=2412),
> prematurely perhaps (i.e., I hope not a duplicate) - and doing a su to michael
> helped the tests along - a lot.
> 
> In the end some of the tests fail because AIX diff does not support the -u
> option. I shall rerun tomorrow with gnu diff installed.

I think we should just remove -u from our diff calls - we've already
done this for other tests.

> As I never use sudo - how is "make tests" expected to work on pristine
> system? Or will sudo just default to letting everyone become root so
> "rootlike" things can be tested? (This is why for builds I test as
> root - so applications can verify they drop "super" powers.

It expects that sudo can be run with any command and root as a target
user.

-d

From aixtools at gmail.com  Sun Jun  7 21:59:58 2015
From: aixtools at gmail.com (aixtools)
Date: Sun, 07 Jun 2015 13:59:58 +0200
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <alpine.BSO.2.20.1506071311450.1454@natsu.mindrot.org>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <5569E593.6050708@gmail.com>
 <CAMv58rbvtdf6PD2maVDbqB-22sU9KLOsahrN--mDDqaicEcfpA@mail.gmail.com>
 <CALDDTe3+-DeJ1_CNtKhJUm2Gdh-EW-3XDdSKpZh32Gc_A4WY9A@mail.gmail.com>
 <55738A09.4010303@gmail.com>
 <alpine.BSO.2.20.1506071311450.1454@natsu.mindrot.org>
Message-ID: <5574323E.6000105@gmail.com>

On 2015-06-07 5:13 AM, Damien Miller wrote:
> On Sun, 7 Jun 2015, aixtools wrote:
>
>> On 2015-06-01 1:06 AM, Darren Tucker wrote:
>>> You were running the tests as root?  I think we need to add
>>> PermitRootLogin=yes to the regression tests to cover this case.
>> I filed a bug report (https://bugzilla.mindrot.org/show_bug.cgi?id=2412),
>> prematurely perhaps (i.e., I hope not a duplicate) - and doing a su to michael
>> helped the tests along - a lot.
>>
>> In the end some of the tests fail because AIX diff does not support the -u
>> option. I shall rerun tomorrow with gnu diff installed.
> I think we should just remove -u from our diff calls - we've already
> done this for other tests.
>
>> As I never use sudo - how is "make tests" expected to work on pristine
>> system? Or will sudo just default to letting everyone become root so
>> "rootlike" things can be tested? (This is why for builds I test as
>> root - so applications can verify they drop "super" powers.
> It expects that sudo can be run with any command and root as a target
> user.
>
> -d
In any case, after adding gnu.diffutils -
all tests passed
(except for those skipped, re: SUDO)

And - I'll repeat here. Willing to provide 'whatever is needed' to addin 
AIX RBAC support. Will need help to get it integrated though.

From aixtools at gmail.com  Sun Jun  7 21:56:36 2015
From: aixtools at gmail.com (aixtools)
Date: Sun, 07 Jun 2015 13:56:36 +0200
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <55742EDF.6010406@gmail.com>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <03554CDD-7488-4823-B290-D59A49C3A2AF@timeheart.net>
 <CALDDTe3nzwG7nEwuzU8z3SV5bM_9rXYoDfKaOPo_1QQ62gtN5Q@mail.gmail.com>
 <0E8AB1FE-071A-4099-9C6C-BD5BD1730B21@timeheart.net>
 <alpine.BSO.2.20.1506030943070.19595@natsu.mindrot.org>
 <E3EE8799-49F8-4E90-B68F-39B68CF45387@timeheart.net>
 <55742EDF.6010406@gmail.com>
Message-ID: <55743174.2030403@gmail.com>

On 2015-06-07 1:45 PM, aixtools wrote:
> On 2015-06-03 2:43 AM, Ron Frederick wrote:
>> On Jun 2, 2015, at 4:46 PM, Damien Miller<djm at mindrot.org>  wrote:
>>> On Tue, 2 Jun 2015, Ron Frederick wrote:
>>>
>>>>> The privsep chroot path is specified at build time (./configure 
>>>>> --with-privsep-path if you want to change it).
>>>> Ok, thanks. I?ve re-run the tests on Linux with --sysconfdir=/etc/ssh
>>>> --with-privsep-path=/var/run, and I no longer see either of the issues
>>>> mentioned above. With the above config option, all tests passed for me
>>>> on Ubuntu 14.04.2 LTS.
>>> You should use /var/run/sshd on Ubuntu. Don't use a directory with 
>>> other
>>> stuff in it.
> I added --with-privsep-path=/var/run/sshd (as non-root) and when I ran 
> "make tests" it aborted when /var/run did not exist - but ran normally 
> when /var/run (only exists). but is not writeable by the non-root user 
> (i.e., cannot mkdir /var/run/sshd either - so why die when /var/run is 
> not there?)
>
> root at x064:[/]ls -ld /var/run
> drwxr-xr-x 2 root system 256 Jun  7 11:31 /var/run
> root at x064:[/]ls -l /var/run
> total 0
>
Shall I add a feature request - to have these tests ALSO run as root, 
and privsep is tested as downgrading from root, rather than SUDO up to root.

And, if someone will be willing to assist me with how to integrate some 
tests I would work on some tests for AIX using AIX's version of RBAC for 
privelidge control. (FYI, I will be researching what sshd actually needs 
to be run without 'root' as a kickstart - and, in all honesty, am hoping 
there is some interest to see configuration example and tests in 
openssh-portable)

And the message above (about make tests stopping when /var/run does not 
exist) - looks like I forgot reply to all the first time, sigh.
>> Ok, thanks. I didn?t actually do an install with those parameters. I 
>> was just using them to get around the ?/var/empty? error that I got 
>> in my previous run, but I?ll keep this in mind if I upgrade OpenSSH 
>> myself on that system.
>>
>>
>>>> Done. This is now filed as bz#2407. No hurry on this one, as the code
>>>> still runs fine at the moment and passes all the tests. I just thought
>>>> I?d report it to avoid future problems if those APIs are ever removed.
>>> Most of those are due to Apple soft-deprecating the OpenSSL libcrypto
>>> API as a supported interface. If they ever fully deprecate it, we'll
>>> ask users to build OpenSSH against an independent installation of
>>> libcrypto.
>> I see. Do you know if there is any way to add something to the 
>> Makefile to suppress the warnings in the meantime?
>>
>> One of the other items I called out in the bug that wasn?t a 
>> deprecation was around the assignment of ssh1_3des_cdc to a 
>> ?do_cipher? function pointer. It looks like the issue there is that 
>> ssh1_3des_cbc is declared to take a ?size_t? as its last argument, 
>> where the do_cipher function pointer is expecting an ?unsigned int?. 
>> It looks like other instances of functions assigned to do_cipher use 
>> the type LIBCRYPTO_EVP_INL_TYPE as the type of this argument, but for 
>> some reason this wasn?t done in the ssh1 3des case. This looks like 
>> it would be an easy fix, though.
>>
>> The last issue was clang not liking the ?-pie? switch on compilations.
>


From Lee.Holmes at microsoft.com  Tue Jun  9 06:45:38 2015
From: Lee.Holmes at microsoft.com (Lee Holmes ([PS C:\>   ]))
Date: Mon, 8 Jun 2015 20:45:38 +0000
Subject: Participating in Win32 OpenSSH port
Message-ID: <SN2PR03MB0140138204B147A7D5E3C8693BF0@SN2PR03MB014.namprd03.prod.outlook.com>

As you may have heard, the PowerShell team is looking to contribute to OpenSSH to make it available on Win32 platforms [1]. As part of this, we're looking to contract some experts on SSH and Win32 to collaborate  with us on the Win32 port. Our focus is to contribute to OpenSSH - not to create a private fork.

If you're interested in contracting to participate in this effort, we'd love to talk! Please contact me directly, and we'll take it from there.

Lee Holmes
Principal Software Engineer, Windows PowerShell

[1] http://blogs.msdn.com/b/powershell/archive/2015/06/03/looking-forward-microsoft-support-for-secure-shell-ssh.aspx

From mehdisotoodeh at gmail.com  Wed Jun 10 13:16:23 2015
From: mehdisotoodeh at gmail.com (Mehdi Sotoodeh)
Date: Tue, 9 Jun 2015 20:16:23 -0700
Subject: curve25519
Message-ID: <CANgBTQTbGFghP-k3jgLTZ+Ch+7cWdHv+ko+nvgDfX3xd+=+Fsg@mail.gmail.com>

I have developed a compact at the same time high performance library for
curve25519/ed25519 and I have placed it in the public domain. It support DH
key exchange as well as ed25519 keygen, sign and verify. The implementation
is constant-time, supports blinding, bulk-verify and more.

The library is available as portable-C as well as ASM for Intel-x64 CPUs.
It outperforms curve25519-donna by a factor of 3.6 to 11 depending on the
target.

You may have a look at the source code hosted at:
https://github.com/msotoodeh/curve25519.

I was wondering if OpenSSH is a suitable home for this library?


Thanks, Mehdi.

From maniac.nl at gmail.com  Wed Jun 10 20:11:13 2015
From: maniac.nl at gmail.com (Mark Janssen)
Date: Wed, 10 Jun 2015 12:11:13 +0200
Subject: curve25519
In-Reply-To: <CANgBTQTbGFghP-k3jgLTZ+Ch+7cWdHv+ko+nvgDfX3xd+=+Fsg@mail.gmail.com>
References: <CANgBTQTbGFghP-k3jgLTZ+Ch+7cWdHv+ko+nvgDfX3xd+=+Fsg@mail.gmail.com>
Message-ID: <CAKs9msjnj3Z8svhcPp+qVR4YqpUBEtbg1semvkt0X7CYRoAi_g@mail.gmail.com>

I haven't looked at the code... and I'm not qualified to look at assembly
and crypto code, so I won't comment on that, but you are not exactly clear
on the license on the code. In your readme you first state 'All rights
reserved' ... then claim the code is in 'the public domain'. Looking into
the headings on the source-code, I see a BSD like license-text:

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that source code retains the
above copyright notice and following disclaimer.

But otherwise... well done on building a fast cypher

Mark


On Wed, Jun 10, 2015 at 5:16 AM, Mehdi Sotoodeh <mehdisotoodeh at gmail.com>
wrote:
>
> I have developed a compact at the same time high performance library for
> curve25519/ed25519 and I have placed it in the public domain. It support
DH
> key exchange as well as ed25519 keygen, sign and verify. The
implementation
> is constant-time, supports blinding, bulk-verify and more.
>
> The library is available as portable-C as well as ASM for Intel-x64 CPUs.
> It outperforms curve25519-donna by a factor of 3.6 to 11 depending on the
> target.
>
> You may have a look at the source code hosted at:
> https://github.com/msotoodeh/curve25519.
>
> I was wondering if OpenSSH is a suitable home for this library?
>
>
> Thanks, Mehdi.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev




-- 
Mark Janssen  --  maniac(at)maniac.nl
Unix / Linux Open-Source and Internet Consultant
Maniac.nl Sig-IO.nl Vps.Stoned-IT.com

From peter at stuge.se  Wed Jun 10 20:38:19 2015
From: peter at stuge.se (Peter Stuge)
Date: Wed, 10 Jun 2015 12:38:19 +0200
Subject: curve25519
In-Reply-To: <CANgBTQTbGFghP-k3jgLTZ+Ch+7cWdHv+ko+nvgDfX3xd+=+Fsg@mail.gmail.com>
References: <CANgBTQTbGFghP-k3jgLTZ+Ch+7cWdHv+ko+nvgDfX3xd+=+Fsg@mail.gmail.com>
Message-ID: <20150610103819.9301.qmail@stuge.se>

Mehdi Sotoodeh wrote:
> I have developed a compact at the same time high performance library for
> curve25519/ed25519 and I have placed it in the public domain.

Since public domain is not recognized worldwide it would be much
better to claim your copyright but publish the code under a very
permissive license. BSD-2 is a good fit for something you want to
propose for BSD projects. I like MIT too.


//Peter

From aixtools at gmail.com  Wed Jun 10 21:38:26 2015
From: aixtools at gmail.com (Michael Felt)
Date: Wed, 10 Jun 2015 13:38:26 +0200
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <CALDDTe3+-DeJ1_CNtKhJUm2Gdh-EW-3XDdSKpZh32Gc_A4WY9A@mail.gmail.com>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <5569E593.6050708@gmail.com>
 <CAMv58rbvtdf6PD2maVDbqB-22sU9KLOsahrN--mDDqaicEcfpA@mail.gmail.com>
 <CALDDTe3+-DeJ1_CNtKhJUm2Gdh-EW-3XDdSKpZh32Gc_A4WY9A@mail.gmail.com>
Message-ID: <CANvxniU0xP4KLN2-Hr61it1AaG1r8SLLae4Bcn5B5DaH=Q-9Bw@mail.gmail.com>

 On 2015-06-01 1:06 AM, Darren Tucker wrote:

You were running the tests as root?  I think we need to add
PermitRootLogin=yes to the regression tests to cover this case.

 I filed a bug report (https://bugzilla.mindrot.org/show_bug.cgi?id=2412),
prematurely perhaps I hope (i.e., I hope not a duplicate) - and doing a su
to michael helped the tests along - a lot.

In the end some of the tests fail because AIX diff does not support the -u
option. I shall rerun tomorrow with gnu diff installed.

As I never use sudo - how is "make tests" expected to work on pristine
system? Or will sudo just default to letting everyone become root so
"rootlike" things can be tested? (This is why for builds I test as root -
so applications can verify they drop "super" powers.

Please note: that this build that is passing tests is the same build
process (less one argument --without-openssl). So, I am hoping you will be
able to get "make tests" working (on AIX) in time for 6.9p1. (and I
requested the https://bugzilla.mindrot.org/show_bug.cgi?id=2370 be reopened
- or do you prefer a new one as the "symptom" has changed.

* I have not forgotten it is 'experimental' - but I would love to be able
to try it in production!

*** 3 days later *** hope this is not a repeat, but found this in gmail
drafts rather than as sent ***

From mehdisotoodeh at gmail.com  Thu Jun 11 01:05:24 2015
From: mehdisotoodeh at gmail.com (Mehdi Sotoodeh)
Date: Wed, 10 Jun 2015 08:05:24 -0700
Subject: curve25519
In-Reply-To: <CAKs9msjnj3Z8svhcPp+qVR4YqpUBEtbg1semvkt0X7CYRoAi_g@mail.gmail.com>
References: <CANgBTQTbGFghP-k3jgLTZ+Ch+7cWdHv+ko+nvgDfX3xd+=+Fsg@mail.gmail.com>
 <CAKs9msjnj3Z8svhcPp+qVR4YqpUBEtbg1semvkt0X7CYRoAi_g@mail.gmail.com>
Message-ID: <98B848CD-DC98-4955-AE04-161339410570@gmail.com>

Hi Mark,
Thanks for taking the time and pointing out the inconsistencies of the license terms. You are right and I have not paid enough attention on it. This can be changed easily to meet openssh requirements.
I am considering a cleanup round to get rid of duplicates and some reorganization of files. I welcome reviews and appreciate comments.

Regards
mehdi.

Sent from my iPad

> On Jun 10, 2015, at 3:11 AM, Mark Janssen <maniac.nl at gmail.com> wrote:
> 
> I haven't looked at the code... and I'm not qualified to look at assembly and crypto code, so I won't comment on that, but you are not exactly clear on the license on the code. In your readme you first state 'All rights reserved' ... then claim the code is in 'the public domain'. Looking into the headings on the source-code, I see a BSD like license-text:
> 
> Redistribution and use in source and binary forms, with or without
> modification, are permitted provided that source code retains the
> above copyright notice and following disclaimer.
> 
> But otherwise... well done on building a fast cypher
> 
> Mark
> 
> 
> On Wed, Jun 10, 2015 at 5:16 AM, Mehdi Sotoodeh <mehdisotoodeh at gmail.com> wrote:
> >
> > I have developed a compact at the same time high performance library for
> > curve25519/ed25519 and I have placed it in the public domain. It support DH
> > key exchange as well as ed25519 keygen, sign and verify. The implementation
> > is constant-time, supports blinding, bulk-verify and more.
> >
> > The library is available as portable-C as well as ASM for Intel-x64 CPUs.
> > It outperforms curve25519-donna by a factor of 3.6 to 11 depending on the
> > target.
> >
> > You may have a look at the source code hosted at:
> > https://github.com/msotoodeh/curve25519.
> >
> > I was wondering if OpenSSH is a suitable home for this library?
> >
> >
> > Thanks, Mehdi.
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev at mindrot.org
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 
> 
> 
> 
> -- 
> Mark Janssen  --  maniac(at)maniac.nl
> Unix / Linux Open-Source and Internet Consultant
> Maniac.nl Sig-IO.nl Vps.Stoned-IT.com

From mouring at eviladmin.org  Thu Jun 11 01:49:16 2015
From: mouring at eviladmin.org (Ben Lindstrom)
Date: Wed, 10 Jun 2015 10:49:16 -0500
Subject: curve25519
In-Reply-To: <98B848CD-DC98-4955-AE04-161339410570@gmail.com>
References: <CANgBTQTbGFghP-k3jgLTZ+Ch+7cWdHv+ko+nvgDfX3xd+=+Fsg@mail.gmail.com>
 <CAKs9msjnj3Z8svhcPp+qVR4YqpUBEtbg1semvkt0X7CYRoAi_g@mail.gmail.com>
 <98B848CD-DC98-4955-AE04-161339410570@gmail.com>
Message-ID: <55785C7C.7090902@eviladmin.org>


I know that OpenSSH team original put some of theses cryptos into 
OpenSSH because they didn't exist in upstream crypto libraries at the 
time.  However, this really feels like something that should go into 
libressl or openssl.  As it will open it up to other applications that 
may use those crypto standards.

- Ben

Mehdi Sotoodeh wrote:
> Hi Mark,
> Thanks for taking the time and pointing out the inconsistencies of the license terms. You are right and I have not paid enough attention on it. This can be changed easily to meet openssh requirements.
> I am considering a cleanup round to get rid of duplicates and some reorganization of files. I welcome reviews and appreciate comments.
>
> Regards
> mehdi.
>
> Sent from my iPad
>
>> On Jun 10, 2015, at 3:11 AM, Mark Janssen<maniac.nl at gmail.com>  wrote:
>>
>> I haven't looked at the code... and I'm not qualified to look at assembly and crypto code, so I won't comment on that, but you are not exactly clear on the license on the code. In your readme you first state 'All rights reserved' ... then claim the code is in 'the public domain'. Looking into the headings on the source-code, I see a BSD like license-text:
>>
>> Redistribution and use in source and binary forms, with or without
>> modification, are permitted provided that source code retains the
>> above copyright notice and following disclaimer.
>>
>> But otherwise... well done on building a fast cypher
>>
>> Mark
>>
>>
>> On Wed, Jun 10, 2015 at 5:16 AM, Mehdi Sotoodeh<mehdisotoodeh at gmail.com>  wrote:
>>> I have developed a compact at the same time high performance library for
>>> curve25519/ed25519 and I have placed it in the public domain. It support DH
>>> key exchange as well as ed25519 keygen, sign and verify. The implementation
>>> is constant-time, supports blinding, bulk-verify and more.
>>>
>>> The library is available as portable-C as well as ASM for Intel-x64 CPUs.
>>> It outperforms curve25519-donna by a factor of 3.6 to 11 depending on the
>>> target.
>>>
>>> You may have a look at the source code hosted at:
>>> https://github.com/msotoodeh/curve25519.
>>>
>>> I was wondering if OpenSSH is a suitable home for this library?
>>>
>>>
>>> Thanks, Mehdi.
>>> _______________________________________________
>>> openssh-unix-dev mailing list
>>> openssh-unix-dev at mindrot.org
>>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>
>>
>> -- 
>> Mark Janssen  --  maniac(at)maniac.nl
>> Unix / Linux Open-Source and Internet Consultant
>> Maniac.nl Sig-IO.nl Vps.Stoned-IT.com
> _______________________________________________
> 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  Thu Jun 11 08:05:00 2015
From: djm at mindrot.org (Damien Miller)
Date: Thu, 11 Jun 2015 08:05:00 +1000 (AEST)
Subject: curve25519
In-Reply-To: <CANgBTQTbGFghP-k3jgLTZ+Ch+7cWdHv+ko+nvgDfX3xd+=+Fsg@mail.gmail.com>
References: <CANgBTQTbGFghP-k3jgLTZ+Ch+7cWdHv+ko+nvgDfX3xd+=+Fsg@mail.gmail.com>
Message-ID: <alpine.BSO.2.20.1506110801560.22353@natsu.mindrot.org>

On Tue, 9 Jun 2015, Mehdi Sotoodeh wrote:

> I have developed a compact at the same time high performance library for
> curve25519/ed25519 and I have placed it in the public domain. It support DH
> key exchange as well as ed25519 keygen, sign and verify. The implementation
> is constant-time, supports blinding, bulk-verify and more.
> 
> The library is available as portable-C as well as ASM for Intel-x64 CPUs.
> It outperforms curve25519-donna by a factor of 3.6 to 11 depending on the
> target.

Great work! Unfortunately I'm don't feel qualified to review crypto
primitives for correctness - this is why we went with reference
implementations for curve25519/ed25519. You should see about getting
your implementation into NaCl or libsodium.

We should see about making it possible to use libsodium for some
crypto...

-d

From naddy at mips.inka.de  Fri Jun 12 01:56:50 2015
From: naddy at mips.inka.de (Christian Weisgerber)
Date: Thu, 11 Jun 2015 15:56:50 +0000 (UTC)
Subject: curve25519
References: <CANgBTQTbGFghP-k3jgLTZ+Ch+7cWdHv+ko+nvgDfX3xd+=+Fsg@mail.gmail.com>
Message-ID: <slrnmnjbu2.1fk2.naddy@lorvorc.mips.inka.de>

On 2015-06-10, Mehdi Sotoodeh <mehdisotoodeh at gmail.com> wrote:

> I have developed a compact at the same time high performance library for
> curve25519/ed25519 and I have placed it in the public domain. It support DH
> key exchange as well as ed25519 keygen, sign and verify. The implementation
> is constant-time, supports blinding, bulk-verify and more.
     ^^^^^^^^^^^^^
I'm skeptical of this claim.

The ecp_Cmp() function is blatantly not constant-time, and strewn
about the source there are various unbalanced if(...) branches and
while(...) loops with a variable number of iterations.

-- 
Christian "naddy" Weisgerber                          naddy at mips.inka.de

From carstengrohmann at gmx.de  Fri Jun 12 05:10:28 2015
From: carstengrohmann at gmx.de (Carsten Grohmann)
Date: Thu, 11 Jun 2015 21:10:28 +0200
Subject: [PATCH] contrib/redhat/openssh.spec
Message-ID: <20150611211028.0f07004c@max.localdomain>

Hello,

please see my pull request on github
(patch attached as well to this mail):

> https://github.com/openssh/openssh-portable/pull/23

Thanks,
Carsten
-------------- next part --------------
A non-text attachment was scrubbed...
Name: redhat_openssh_spec.diff
Type: text/x-patch
Size: 1070 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150611/07d5b570/attachment.bin>

From mdb at juniper.net  Fri Jun 12 15:52:54 2015
From: mdb at juniper.net (Mark D. Baushke)
Date: Thu, 11 Jun 2015 22:52:54 -0700
Subject: [Bug 2302] with DH-GEX,
 ssh (and sshd) should not fall back to unconfigured DH groups or at
 least document this behaviour and use a stronger group 
In-Reply-To: <20150527220240.GA5826@zoho.com> 
References: <bug-2302-705@https.bugzilla.mindrot.org/>
 <bug-2302-705-KG2jIZVXcm@https.bugzilla.mindrot.org/>
 <48704.1432669189@eng-mail01.juniper.net>
 <87siahhgom.fsf@alice.fifthhorseman.net> <20150527220240.GA5826@zoho.com>
Message-ID: <49674.1434088374@eng-mail01.juniper.net>

I am coming late to this thread.

mancha <mancha1 at zoho.com> writes:

> On Wed, May 27, 2015 at 05:08:25PM -0400, Daniel Kahn Gillmor wrote:
> > On Tue 2015-05-26 15:39:49 -0400, Mark D. Baushke wrote:
> > > Hi Folks,
> > >
> > > The generator value of 5 does not lead to a q-ordered subgroup which
> > > is needed to pass tests in
> > >
> > > http://csrc.nist.gov/publications/nistpubs/800-56A/SP800-56A_Revision1_Mar08-2007.pdf
> > 
> > I pulled revision 2 of this document from here:
> > 
> > https://dx.doi.org/10.6028/nist.sp.800-56ar2
> > 
> > The "FFC Domain Parameter Generation" section does say:
> > 
> >     g is a generator of the cyclic subgroup of GF(p)* of order q,
> > 
> > But i don't see a recommendation of why this matters.  Surely we don't
> > want the subgroup of order 2, but what is wrong with using a subgroup
> > of order 2q = p-1?
> > 
> > There's clearly no strong security advantage to the 2q subgroup --
> > it's just one bit larger -- but is there an attack that works against
> > the 2q subgroup that doesn't work against the q subgroup?  If this is
> > a known concern, i'd be happy with just a pointer to a paper or web
> > page explaining the risks of the larger group.
> > 
> > otoh, if the goal is just to ensure we have word-for-word compliance
> > with SP800-56A, then it's clear that choosing a different generator is
> > the way to go (and without much of a security cost).  but i'd like to
> > know if there's a reason other than blind-spec-compliance.  Pointers?
> > 
> > Regards,
> > 
> >         --dkg
> 
> One reason the generator of the full (Z/pZ)* is avoided is because
> knowledge of g^a and g^b (both known to Mallory) leaks information about
> the shared secret g^(ab) via their legendre symbols.  This is
> particularly troublesome in the context of El Gamal.  
> 
> I don't have a reference to recommend off-hand but you might want to
> google for "decisional diffie hellman assumption".
> 
> --mancha

I have communicated with Allen Roginsky on this topic and I have been given permission to post his response.

In this message below, the 'vendor' was Darren Tucker's generated prime
that used a generator value of 5.

	-- Mark

From: "Roginsky, Allen" <allen.roginsky at nist.gov>
Subject: RE: Question on SP 800-56A rev2

The reason the y^q=1 (mod p) tests exists is to verify that y is in the
required subgroup. In general, for any y mutually prime with p, it is
true that y^(p-1) = 1 mod p. (The Fermat's Little Theorem.) Of course,
when taking an arbitrary y into the power smaller than (p-1) the above
equality does not necessarily hold. Suppose, however, that y is a
generator of a cyclic subgroup that has q elements. This is subgroup of
a larger group that has (p-1) elements; (p-1) is a multiple of q). The
way y was selected was by taking an arbitrary number w into the power of
(p-1)/q mod p (to be sure that it is in the subgroup of order q) and
checking that the result is not 1 (mod p) (otherwise, it is in the right
subgroup but is a unit element there - not a useful case.) Now, to test
that y is in a subgroup of order q one has to check that y^q = 1 mod p.
This would indeed hold if, as designed, y=w^(p-1)/q) mod p and
therefore, y^q = [w^(p-1)/q]^q ] = w^(p-1) = 1 mod p. This is why this
test (y^q = 1 mod p) exists in FIPS 186-4. \

My guess is that the value of 5 in your vendor's example, does not
satisfy this test, so it is not a generator of a subgroup of order q.
This value 5 could not have then been generated using w^[(p-1)q] (mod p)
method.

I do not know why some other standards appear to impose the additional
requirements on g. To find a generator of the entire cyclic group of the
order of (p-1) one usually has to make many tries, so some specific
methods or restrictions may apply there, but any g not equal to 1 and
such that g = w^[(p-1)q] (mod p) is good to be a generator of the
smaller subgroup (size q), as far as I can tell.

Please do not hesitate to call me or let your vendor call if they have
any additional questions.

Regards,
Allen

From mancha1 at zoho.com  Fri Jun 12 16:00:21 2015
From: mancha1 at zoho.com (mancha)
Date: Fri, 12 Jun 2015 06:00:21 +0000
Subject: OpenSSL ABI change 20150612
Message-ID: <20150612060021.GA29666@zoho.com>

Hi Folks.

Today's OpenSSL releases 1.0.1n and 1.0.2b introduce ABI gremlins.
Specifically, the HMAC_CTX stucture has a new "key_init" field of type
integer:

  --- a/crypto/hmac/hmac.h
  +++ b/crypto/hmac/hmac.h
  @@ -75,6 +75,7 @@ typedef struct hmac_ctx_st {
       EVP_MD_CTX o_ctx;
       unsigned int key_length;
       unsigned char key[HMAC_MAX_MD_CBLOCK];
  +    int key_init;
   } HMAC_CTX;


This issue was identified by Dan McDonald of OmniOS (an illumos
distribution) after their version of SSH (based on OpenSSH) broke. [1]

I've quickly reviewed things in OpenSSH and it seems to impact versions
4.7 through 6.5 inclusive (kex.h,v 1.62 makes it a NOP [2]).

Just a friendly heads up...

--mancha

---
[1] http://marc.info/?l=openssl-dev&m=143407129721271&w=2
[2] http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/kex.h.diff?r1=1.61&r2=1.62
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150612/030c316e/attachment.bin>

From mancha1 at zoho.com  Sat Jun 13 01:50:56 2015
From: mancha1 at zoho.com (mancha)
Date: Fri, 12 Jun 2015 15:50:56 +0000
Subject: OpenSSL ABI change 20150612
In-Reply-To: <20150612060021.GA29666@zoho.com>
References: <20150612060021.GA29666@zoho.com>
Message-ID: <20150612155056.GA6534@zoho.com>

On Fri, Jun 12, 2015 at 06:00:21AM +0000, mancha wrote:
> Hi Folks.
> 
> Today's OpenSSL releases 1.0.1n and 1.0.2b introduce ABI gremlins.
> Specifically, the HMAC_CTX stucture has a new "key_init" field of type
> integer:
> 
>   --- a/crypto/hmac/hmac.h
>   +++ b/crypto/hmac/hmac.h
>   @@ -75,6 +75,7 @@ typedef struct hmac_ctx_st {
>        EVP_MD_CTX o_ctx;
>        unsigned int key_length;
>        unsigned char key[HMAC_MAX_MD_CBLOCK];
>   +    int key_init;
>    } HMAC_CTX;
> 
> 
> This issue was identified by Dan McDonald of OmniOS (an illumos
> distribution) after their version of SSH (based on OpenSSH) broke. [1]
> 
> I've quickly reviewed things in OpenSSH and it seems to impact versions
> 4.7 through 6.5 inclusive (kex.h,v 1.62 makes it a NOP [2]).
> 
> Just a friendly heads up...
> 
> --mancha
> 
> ---
> [1] http://marc.info/?l=openssl-dev&m=143407129721271&w=2
> [2] http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/kex.h.diff?r1=1.61&r2=1.62

By way of update, OpenSSL released versions 1.0.1o and 1.0.2c today to
resolve this issue.

https://twitter.com/mancha140/status/609386942489178112

--mancha
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150612/4ee2779e/attachment.bin>

From dkg at fifthhorseman.net  Sat Jun 13 05:41:23 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Fri, 12 Jun 2015 15:41:23 -0400
Subject: [Bug 2302] with DH-GEX,
 ssh (and sshd) should not fall back to unconfigured DH groups or at
 least document this behaviour and use a stronger group
In-Reply-To: <49674.1434088374@eng-mail01.juniper.net>
References: <bug-2302-705@https.bugzilla.mindrot.org/>
 <bug-2302-705-KG2jIZVXcm@https.bugzilla.mindrot.org/>
 <48704.1432669189@eng-mail01.juniper.net>
 <87siahhgom.fsf@alice.fifthhorseman.net> <20150527220240.GA5826@zoho.com>
 <49674.1434088374@eng-mail01.juniper.net>
Message-ID: <87ioaslnoc.fsf@alice.fifthhorseman.net>

On Fri 2015-06-12 01:52:54 -0400, Mark D. Baushke wrote:
> I have communicated with Allen Roginsky on this topic and I have been given permission to post his response.
>
> In this message below, the 'vendor' was Darren Tucker's generated prime
> that used a generator value of 5.
>
> 	-- Mark
>
> From: "Roginsky, Allen" <allen.roginsky at nist.gov>
> Subject: RE: Question on SP 800-56A rev2
>
> The reason the y^q=1 (mod p) tests exists is to verify that y is in the
> required subgroup.

I think this answer "begs the question" -- yes, the mathematical test
verifies that y generates a subgroup of size q.  But the question we
were discussing is why does the subgroup need to be of size q instead of
size p-1?  

     --dkg

From etienne.buira at gmail.com  Sat Jun 13 22:08:51 2015
From: etienne.buira at gmail.com (=?utf-8?Q?=C3=89tienne?= Buira)
Date: Sat, 13 Jun 2015 14:08:51 +0200
Subject: [PATCH] sshd: Add ChangeDirectory configuration directive
Message-ID: <20150613120851.GD11678@rcKGHUlyQfVFW>

Directive described in sshd_config (5).

Also remove chdir warning skip code both because this can be handled
with more flexibility with this added directive and were broken since
a56086b9903b62c1c4fdedf01b68338fe4dc90e4.
---
 regress/Makefile      |  5 +++--
 regress/sftp-chdir.sh | 30 ++++++++++++++++++++++++++++++
 servconf.c            | 15 ++++++++++++++-
 servconf.h            |  2 ++
 session.c             | 23 +++++++++++++++--------
 sshd_config           |  1 +
 sshd_config.5         | 16 +++++++++++++++-
 7 files changed, 80 insertions(+), 12 deletions(-)
 create mode 100644 regress/sftp-chdir.sh

diff --git a/regress/Makefile b/regress/Makefile
index cba83f4..395241a 100644
--- a/regress/Makefile
+++ b/regress/Makefile
@@ -11,7 +11,7 @@ prep:
 
 clean:
 	for F in $(CLEANFILES); do rm -f $(OBJ)$$F; done
-	test -z "${SUDO}" || ${SUDO} rm -f ${SUDO_CLEAN}
+	test -z "${SUDO}" || ${SUDO} rm -df ${SUDO_CLEAN}
 	rm -rf $(OBJ).putty
 
 distclean:	clean
@@ -43,6 +43,7 @@ LTESTS= 	connect \
 		scp \
 		sftp \
 		sftp-chroot \
+		sftp-chdir \
 		sftp-cmds \
 		sftp-badcmds \
 		sftp-batch \
@@ -107,7 +108,7 @@ CLEANFILES=	t2.out t3.out t6.out1 t6.out2 t7.out t7.out.pub copy.1 copy.2 \
 		key.ed25519-512.pub netcat host_krl_* host_revoked_* \
 		kh.* user_*key* agent-key.* known_hosts.* hkr.*
 
-SUDO_CLEAN+=	/var/run/testdata_${USER} /var/run/keycommand_${USER}
+SUDO_CLEAN+=	/var/run/testdata_${USER} /var/run/testlanddir_${USER}{/testdata_${USER},} /var/run/keycommand_${USER}
 
 # Enable all malloc(3) randomisations and checks
 TEST_ENV=      "MALLOC_OPTIONS=AFGJPRX"
diff --git a/regress/sftp-chdir.sh b/regress/sftp-chdir.sh
new file mode 100644
index 0000000..46f5759
--- /dev/null
+++ b/regress/sftp-chdir.sh
@@ -0,0 +1,30 @@
+#	$OpenBSD: sftp-chroot.sh,v 1.4 2014/01/20 00:00:30 dtucker Exp $
+#	Placed in the Public Domain.
+
+tid="sftp in chroot with chdir"
+
+CHROOT=/var/run
+CHDIR=testlanddir_${USER}
+CHDIROUT=${CHROOT}/${CHDIR}
+FILENAME=testdata_${USER}
+PRIVDATA=${CHDIROUT}/${FILENAME}
+
+if [ -z "$SUDO" ]; then
+  echo "skipped: need SUDO to create file in /var/run, test won't work without"
+  exit 0
+fi
+
+$SUDO sh -c "mkdir -p $CHDIROUT && echo mekmitastdigoat > $PRIVDATA" || \
+	fatal "create $PRIVDATA failed"
+
+start_sshd -oChrootDirectory=$CHROOT -oForceCommand="internal-sftp" -oChangeDirectory=$CHDIR
+
+verbose "test $tid: get"
+${SFTP} -S "$SSH" -F $OBJ/ssh_config host:${FILENAME} $COPY \
+    >>$TEST_REGRESS_LOGFILE 2>&1 || \
+	fatal "Fetch ${FILENAME} failed"
+cmp $PRIVDATA $COPY || fail "$PRIVDATA $COPY differ"
+
+$SUDO rm $PRIVDATA
+$SUDO rmdir $CHDIROUT
+
diff --git a/servconf.c b/servconf.c
index eb32db0..6812c94 100644
--- a/servconf.c
+++ b/servconf.c
@@ -167,6 +167,7 @@ initialize_server_options(ServerOptions *options)
 	options->ip_qos_bulk = -1;
 	options->version_addendum = NULL;
 	options->fingerprint_hash = -1;
+	options->change_directory = NULL;
 }
 
 /* Returns 1 if a string option is unset or set to "none" or 0 otherwise. */
@@ -411,7 +412,7 @@ typedef enum {
 	sAuthorizedKeysCommand, sAuthorizedKeysCommandUser,
 	sAuthenticationMethods, sHostKeyAgent, sPermitUserRC,
 	sStreamLocalBindMask, sStreamLocalBindUnlink,
-	sAllowStreamLocalForwarding, sFingerprintHash,
+	sAllowStreamLocalForwarding, sFingerprintHash, sChangeDirectory,
 	sDeprecated, sUnsupported
 } ServerOpCodes;
 
@@ -549,6 +550,7 @@ static struct {
 	{ "streamlocalbindunlink", sStreamLocalBindUnlink, SSHCFG_ALL },
 	{ "allowstreamlocalforwarding", sAllowStreamLocalForwarding, SSHCFG_ALL },
 	{ "fingerprinthash", sFingerprintHash, SSHCFG_GLOBAL },
+	{ "changedirectory", sChangeDirectory, SSHCFG_ALL },
 	{ NULL, sBadOption, 0 }
 };
 
@@ -1826,6 +1828,15 @@ process_server_config_line(ServerOptions *options, char *line,
 			options->fingerprint_hash = value;
 		break;
 
+	case sChangeDirectory:
+		arg = strdelim(&cp);
+		if (!arg || *arg == '\0')
+			fatal("%s line %d: missing directory name.",
+			    filename, linenum);
+		if (*activep && !options->change_directory)
+			options->change_directory = xstrdup(arg);
+		break;
+
 	case sDeprecated:
 		logit("%s line %d: Deprecated option %s",
 		    filename, linenum, arg);
@@ -2007,6 +2018,7 @@ copy_set_server_options(ServerOptions *dst, ServerOptions *src, int preauth)
 
 	M_CP_STROPT(adm_forced_command);
 	M_CP_STROPT(chroot_directory);
+	M_CP_STROPT(change_directory);
 }
 
 #undef M_CP_INTOPT
@@ -2281,6 +2293,7 @@ dump_config(ServerOptions *o)
 	    o->hostbased_key_types : KEX_DEFAULT_PK_ALG);
 	dump_cfg_string(sPubkeyAcceptedKeyTypes, o->pubkey_key_types ?
 	    o->pubkey_key_types : KEX_DEFAULT_PK_ALG);
+	dump_cfg_string(sChangeDirectory, o->change_directory);
 
 	/* string arguments requiring a lookup */
 	dump_cfg_string(sLogLevel, log_level_name(o->log_level));
diff --git a/servconf.h b/servconf.h
index 606d80c..02089e1 100644
--- a/servconf.h
+++ b/servconf.h
@@ -194,6 +194,8 @@ typedef struct {
 	char   *auth_methods[MAX_AUTH_METHODS];
 
 	int	fingerprint_hash;
+
+	char   *change_directory;
 }       ServerOptions;
 
 /* Information about the incoming connection as used by Match */
diff --git a/session.c b/session.c
index 5a64715..6955737 100644
--- a/session.c
+++ b/session.c
@@ -1670,6 +1670,7 @@ do_child(Session *s, const char *command)
 	char *argv[ARGV_MAX];
 	const char *shell, *shell0, *hostname = NULL;
 	struct passwd *pw = s->pw;
+	char *landingdir;
 	int r = 0;
 
 	/* remove hostkey from the child's memory */
@@ -1784,20 +1785,26 @@ do_child(Session *s, const char *command)
 	}
 #endif
 
-	/* Change current directory to the user's home directory. */
-	if (chdir(pw->pw_dir) < 0) {
-		/* Suppress missing homedir warning for chroot case */
+	/* Change current directory to landing directory (either home or
+	 * set by config). */
+	if (!options.change_directory || !strcasecmp(options.change_directory, "none"))
+		landingdir = pw->pw_dir;
+	else
+		landingdir = percent_expand(options.change_directory,
+		    "h", pw->pw_dir, "u", pw->pw_name, (char*)NULL);
+	if (chdir(landingdir) < 0) {
 #ifdef HAVE_LOGIN_CAP
 		r = login_getcapbool(lc, "requirehome", 0);
 #endif
-		if (r || options.chroot_directory == NULL ||
-		    strcasecmp(options.chroot_directory, "none") == 0)
-			fprintf(stderr, "Could not chdir to home "
-			    "directory %s: %s\n", pw->pw_dir,
-			    strerror(errno));
+		fprintf(stderr, "Could not chdir to landing "
+		    "directory %s: %s\n", landingdir,
+		    strerror(errno));
+
 		if (r)
 			exit(1);
 	}
+	if (options.change_directory && strcasecmp(options.change_directory, "none"))
+		free(landingdir);
 
 	closefrom(STDERR_FILENO + 1);
 
diff --git a/sshd_config b/sshd_config
index cf7d8e1..e850f0d 100644
--- a/sshd_config
+++ b/sshd_config
@@ -118,6 +118,7 @@ UsePrivilegeSeparation sandbox		# Default for new installations.
 #PermitTunnel no
 #ChrootDirectory none
 #VersionAddendum none
+#ChangeDirectory none
 
 # no default banner path
 #Banner none
diff --git a/sshd_config.5 b/sshd_config.5
index 5ab4318..539c229 100644
--- a/sshd_config.5
+++ b/sshd_config.5
@@ -378,6 +378,17 @@ PAM or through authentication styles supported in
 .Xr login.conf 5 )
 The default is
 .Dq yes .
+.It Cm ChangeDirectory
+Specifies the pathname of a directory to
+.Xr chdir 2
+to after authentication, and after entering the chroot if
+.Cm ChrootDirectory
+were specified.
+.Pp
+The pathname may contain the following tokens that are expanded at runtime once
+the connecting user has been authenticated: %% is replaced by a literal '%',
+%h is replaced by the home directory of the user being authenticated, and
+%u is replaced by the username of that user.
 .It Cm ChrootDirectory
 Specifies the pathname of a directory to
 .Xr chroot 2
@@ -388,7 +399,9 @@ checks that all components of the pathname are root-owned directories
 which are not writable by any other user or group.
 After the chroot,
 .Xr sshd 8
-changes the working directory to the user's home directory.
+changes the working directory to the user's home directory (by default), or
+to directory specified with
+.Cm ChangeDirectory .
 .Pp
 The pathname may contain the following tokens that are expanded at runtime once
 the connecting user has been authenticated: %% is replaced by a literal '%',
@@ -1041,6 +1054,7 @@ Available keywords are
 .Cm AuthorizedKeysFile ,
 .Cm AuthorizedPrincipalsFile ,
 .Cm Banner ,
+.Cm ChangeDirectory ,
 .Cm ChrootDirectory ,
 .Cm DenyGroups ,
 .Cm DenyUsers ,
-- 
2.0.5


From aris at 0xbadc0de.be  Sat Jun 13 23:21:19 2015
From: aris at 0xbadc0de.be (Aris Adamantiadis)
Date: Sat, 13 Jun 2015 15:21:19 +0200
Subject: curve25519
In-Reply-To: <CANgBTQTbGFghP-k3jgLTZ+Ch+7cWdHv+ko+nvgDfX3xd+=+Fsg@mail.gmail.com>
References: <CANgBTQTbGFghP-k3jgLTZ+Ch+7cWdHv+ko+nvgDfX3xd+=+Fsg@mail.gmail.com>
Message-ID: <557C2E4F.6040907@0xbadc0de.be>

Hi,

The main advantage of your contribution is a speed increase. The 
disadvantage is that your implementation has not been reviewed for 
security by experts yet, and thus is not as reliable as the reference 
implementation.
I believe OpenSSH (and libssh from my pov) is not the right place to 
introduce experimental cryptographic code. The speed increase advantage 
is not very relevant to SSH, because the key exchange happens only once 
per session (on average), and we were using much slower algorithms till 
last year (DH and ECDH), that nobody ever complained about.

You should probably try to get that code to be part of OpenSSL. I 
Believe cryptographic implementations should go in crypto libs, and we 
should bundle/maintain as little crypto code as possible in crypto 
consuming projects.

Aris

Le 10/06/15 05:16, Mehdi Sotoodeh a ?crit :
> I have developed a compact at the same time high performance library for
> curve25519/ed25519 and I have placed it in the public domain. It support DH
> key exchange as well as ed25519 keygen, sign and verify. The implementation
> is constant-time, supports blinding, bulk-verify and more.
>
> The library is available as portable-C as well as ASM for Intel-x64 CPUs.
> It outperforms curve25519-donna by a factor of 3.6 to 11 depending on the
> target.
>
> You may have a look at the source code hosted at:
> https://github.com/msotoodeh/curve25519.
>
> I was wondering if OpenSSH is a suitable home for this library?
>
>
> Thanks, Mehdi.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>


From loganaden at gmail.com  Sat Jun 13 23:34:25 2015
From: loganaden at gmail.com (Loganaden Velvindron)
Date: Sat, 13 Jun 2015 13:34:25 +0000
Subject: curve25519
In-Reply-To: <557C2E4F.6040907@0xbadc0de.be>
References: <CANgBTQTbGFghP-k3jgLTZ+Ch+7cWdHv+ko+nvgDfX3xd+=+Fsg@mail.gmail.com>
 <557C2E4F.6040907@0xbadc0de.be>
Message-ID: <CAOp4FwSFdG8ED-1bLC0gpSKAUJLqeMHtU_18H=ruA3ALdZRu+Q@mail.gmail.com>

On Sat, Jun 13, 2015 at 1:21 PM, Aris Adamantiadis <aris at 0xbadc0de.be> wrote:
> Hi,
>
> The main advantage of your contribution is a speed increase. The
> disadvantage is that your implementation has not been reviewed for security
> by experts yet, and thus is not as reliable as the reference implementation.
> I believe OpenSSH (and libssh from my pov) is not the right place to
> introduce experimental cryptographic code. The speed increase advantage is
> not very relevant to SSH, because the key exchange happens only once per
> session (on average), and we were using much slower algorithms till last
> year (DH and ECDH), that nobody ever complained about.
>
> You should probably try to get that code to be part of OpenSSL. I Believe

Or LibreSSL :)

From mdb at juniper.net  Mon Jun 15 17:09:19 2015
From: mdb at juniper.net (Mark D. Baushke)
Date: Mon, 15 Jun 2015 00:09:19 -0700
Subject: [Bug 2302] with DH-GEX,
 ssh (and sshd) should not fall back to unconfigured DH groups or at
 least document this behaviour and use a stronger group 
In-Reply-To: <87ioaslnoc.fsf@alice.fifthhorseman.net> 
References: <bug-2302-705@https.bugzilla.mindrot.org/>
 <bug-2302-705-KG2jIZVXcm@https.bugzilla.mindrot.org/>
 <48704.1432669189@eng-mail01.juniper.net>
 <87siahhgom.fsf@alice.fifthhorseman.net> <20150527220240.GA5826@zoho.com>
 <49674.1434088374@eng-mail01.juniper.net>
 <87ioaslnoc.fsf@alice.fifthhorseman.net>
Message-ID: <68285.1434352159@eng-mail01.juniper.net>

Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:

> > From: "Roginsky, Allen" <allen.roginsky at nist.gov>
> > Subject: RE: Question on SP 800-56A rev2
> >
> > The reason the y^q=1 (mod p) tests exists is to verify that y is in the
> > required subgroup.
> 
> I think this answer "begs the question" -- yes, the mathematical test
> verifies that y generates a subgroup of size q.  But the question we
> were discussing is why does the subgroup need to be of size q instead of
> size p-1?  

I forwarded your post to Allen Raginsky with this note:

> > From: Mark Baushke [mailto:mdb at juniper.net]
> > Sent: Friday, June 12, 2015 10:23 PM
> > To: Roginsky, Allen
> > Subject: Fwd: [Bug 2302] with DH-GEX, ssh (and sshd) should not fall back to unconfigured DH groups or at least document this behaviour and use a stronger group
> > 
> > Hi Allen,
> > 
> > It seems that there is a followup question to your statements?
> > 
> > It really is sort of the root question, whey does anyone actually
> > care if we have a q-ordered subgroup or not? Is there an attack
> > which is not published on this kind of issue?
> > 
> > -- Mark

I have received this reply from Allen...

	-- Mark

 ------- forwarded message -------
From: "Roginsky, Allen" <allen.roginsky at nist.gov>
To: Mark Baushke <mdb at juniper.net>
Subject: RE: [Bug 2302] with DH-GEX, ssh (and sshd) should not fall back to
 unconfigured DH groups or at least document this behaviour and use a stronger
 group
Date: Mon, 15 Jun 2015 06:17:55 +0000

Hi Mark,

The private key x may be placed in the smaller subgroup ? of size q ? precisely because there are no known attacks against the DH method that could exploit the structure of this subgroup.  The public key must be in a larger group because there are attacks exploiting the structure of the DH public key (the attacks against the discreet logarithm problem in the multiplicative group of a finite field).

Regards,
Allen

 ------- end of forwarded message -------

From lists at wiesinger.com  Tue Jun 16 00:05:28 2015
From: lists at wiesinger.com (Gerhard Wiesinger)
Date: Mon, 15 Jun 2015 16:05:28 +0200
Subject: OpenSSH and CBC
Message-ID: <557EDBA8.6060006@wiesinger.com>

Hello,

I saw that OpenSSH release 6.7 removed all CBC ciphers by default. Is 
CBC therefore considered as broken and unsecure (in general or SSH 
implementation)?

I also read a lot of references (see below) but still not clear to me 
what's the actual "security status" of CBC and why it has been removed 
in general.

http://www.openssh.com/txt/release-6.7
sshd(8): The default set of ciphers and MACs has been altered to remove 
unsafe algorithms. In particular, CBC ciphers and arcfour are disabled 
by default.

OpenSSH release 5.2 should have fixed that.

Please clarify it.

Thank you.

Ciao,
Gerhard

-- http://www.wiesinger.com

References:
https://en.wikipedia.org/wiki/Block_cipher_mode_of_operation
https://en.wikipedia.org/wiki/CBC-MAC

https://crypto.stackexchange.com/questions/1075/why-is-it-insecure-to-use-a-randomized-iv-for-cbc-mac-instead-of-an-all-zero-iv
http://blog.cryptographyengineering.com/2013/02/why-i-hate-cbc-mac.html
Now a quick note: there's nothing really wrong with CBC-MAC, when 
implemented correctly. And it's not even that hard to implement 
properly. The problem is that many people who use CBC-MAC (rather than 
HMAC or a proper AEAD mode) seem incapable of actually doing this.

http://blog.cryptographyengineering.com/2012/05/how-to-choose-authenticated-encryption.html
Vulnerability Name: SSH CBC Mode Ciphers Enabled
https://access.redhat.com/solutions/420283

http://forums.eeye.com/index.php?/topic/2858-11867-ssh-cbc-mode-plaintext-recovery-remote-false-positive/
The reality is that all of the CBC mode ciphers are vulnerable and this 
includes the old standby [3DES-CBC] and even, likely, [BLOWFISH-CBC].
We can look at the references provided by the Retina finding for a more 
detailed analysis.
The first is the reference from CERT:
http://www.kb.cert.org/vuls/id/958563
This clearly states that ALL CBC mode ciphers are vulnerable and that 
the only real mitigation is to use CTR mode, or other secure ciphers 
which do not use Cipher Block Chaining (like [ARCFOUR]).

The last reference is from OpenSSH:
http://openssh.org/txt/cbc.adv
They basically suggest that the likelihood of a successful attack is 
very low, while acknowledging that there is a vulnerability with ALL CBC 
mode ciphers.
The OpenSSH team also suggests a mitigation in which the CTR mode 
ciphers "may be preferentially selected" first in the ssh[d]_config files:
Ciphers aes128-ctr,aes256-ctr,arcfour256,arcfour,aes128-cbc,aes256-cbc

http://www.cpni.gov.uk/Docs/Vulnerability_Advisory_SSH.txt
https://packetstormsecurity.com/files/72061/Vulnerability_Advisory_SSH.txt.html

http://www.cs.washington.edu/homes/yoshi/papers/TISSEC04/
https://homes.cs.washington.edu/~yoshi/papers/TISSEC04/ssh-acmccs.pdf

http://isg.rhul.ac.uk/~kp/SandPfinal.pdf
https://lwn.net/Articles/307873/
http://www.openssh.com/security.html
http://www.openssh.com/txt/release-5.2
Security:
  * This release changes the default cipher order to prefer the AES CTR
    modes and the revised "arcfour256" mode to CBC mode ciphers that are
    susceptible to CPNI-957037 "Plaintext Recovery Attack Against SSH".
  * This release also adds countermeasures to mitigate CPNI-957037-style
    attacks against the SSH protocol's use of CBC-mode ciphers. Upon
    detection of an invalid packet length or Message Authentication
    Code, ssh/sshd will continue reading up to the maximum supported
    packet length rather than immediately terminating the connection.
    This eliminates most of the known differences in behaviour that
    leaked information about the plaintext of injected data which formed
    the basis of this attack. We believe that these attacks are rendered
    infeasible by these changes.

https://www.digitalocean.com/community/tutorials/understanding-the-ssh-encryption-and-connection-process

SSH implementation comparison
http://ssh-comparison.quendi.de/comparison.html

Analysis of the SSH Key Exchange Protocol
https://eprint.iacr.org/2011/276.pdf


From mancha1 at zoho.com  Tue Jun 16 03:31:23 2015
From: mancha1 at zoho.com (mancha)
Date: Mon, 15 Jun 2015 17:31:23 +0000
Subject: [Bug 2302] with DH-GEX, ssh (and sshd) should not fall back to
 unconfigured DH groups or at least document this behaviour and use a
 stronger group
In-Reply-To: <68285.1434352159@eng-mail01.juniper.net>
References: <bug-2302-705@https.bugzilla.mindrot.org/>
 <bug-2302-705-KG2jIZVXcm@https.bugzilla.mindrot.org/>
 <48704.1432669189@eng-mail01.juniper.net>
 <87siahhgom.fsf@alice.fifthhorseman.net>
 <20150527220240.GA5826@zoho.com>
 <49674.1434088374@eng-mail01.juniper.net>
 <87ioaslnoc.fsf@alice.fifthhorseman.net>
 <68285.1434352159@eng-mail01.juniper.net>
Message-ID: <20150615173123.GA10873@zoho.com>

On Mon, Jun 15, 2015 at 12:09:19AM -0700, Mark D. Baushke wrote:
> Daniel Kahn Gillmor <dkg at fifthhorseman.net> writes:
> 
> > > From: "Roginsky, Allen" <allen.roginsky at nist.gov> Subject: RE:
> > > Question on SP 800-56A rev2
> > >
> > > The reason the y^q=1 (mod p) tests exists is to verify that y is
> > > in the required subgroup.
> > 
> > I think this answer "begs the question" -- yes, the mathematical
> > test verifies that y generates a subgroup of size q.  But the
> > question we were discussing is why does the subgroup need to be of
> > size q instead of size p-1?  
> 
> I forwarded your post to Allen Raginsky with this note:
> 
> > > From: Mark Baushke [mailto:mdb at juniper.net] Sent: Friday, June 12,
> > > 2015 10:23 PM To: Roginsky, Allen Subject: Fwd: [Bug 2302] with
> > > DH-GEX, ssh (and sshd) should not fall back to unconfigured DH
> > > groups or at least document this behaviour and use a stronger
> > > group
> > > 
> > > Hi Allen,
> > > 
> > > It seems that there is a followup question to your statements?
> > > 
> > > It really is sort of the root question, whey does anyone actually
> > > care if we have a q-ordered subgroup or not? Is there an attack
> > > which is not published on this kind of issue?
> > > 
> > > -- Mark
> 
> I have received this reply from Allen...
> 
> 	-- Mark
> 
>  ------- forwarded message ------- From: "Roginsky, Allen"
>  <allen.roginsky at nist.gov> To: Mark Baushke <mdb at juniper.net> Subject:
>  RE: [Bug 2302] with DH-GEX, ssh (and sshd) should not fall back to
>  unconfigured DH groups or at least document this behaviour and use a
>  stronger group Date: Mon, 15 Jun 2015 06:17:55 +0000
> 
> Hi Mark,
> 
> The private key x may be placed in the smaller subgroup ? of size q ?
> precisely because there are no known attacks against the DH method
> that could exploit the structure of this subgroup.  The public key
> must be in a larger group because there are attacks exploiting the
> structure of the DH public key (the attacks against the discreet
> logarithm problem in the multiplicative group of a finite field).
> 
> Regards, Allen
> 
>  ------- end of forwarded message -------

Hi Mark.

Thanks for following up on this important and interesting issue and for
serving as interlocutor with the good folks at NIST.

Regarding Allen's last comment, I believe what he means is there doesn't
appear to be a way to apply the methods of the index-calculus directly
to the q-subgroup. In these subgroups, the state of the art algorithms
have much lower O(n^(1/2)) runtimes.

This is probably why NIST feels comfortable with the low q
bit-requirements compared to the p bit-requirements in SP-800-56:

   p    q
1024  160
2048  224
2048  256

In OpenSSH's case, where p=2q+1 by construction, the bit profiles are:

   p     q
1024  1023
2048  2047
4096  4095

In this latter situation, an attacker would choose to compute discrete
logs in (Z/pZ)* even when the generator generates the subgroup order q.
Why? Because O(sqrt(2^||q||)) costs are so much much greater.

In other words, the decision to attack the subgroup directly or the full
group depends on the relative bit sizes of p & q. However, of note, when
the generator used generates the q-subgroup, one can always fall back to
computing the discrete log in the full group.

Finally, as I wrote in an earlier email, all else equal, one reason to
avoid the full group is the leakage of the Legendre symbol. This is
particularly bad for ElGamal where one leaks the Legendre symbol of the
cleartext. For example, imagine an e-voting system than encrypts "GOP"
and "DEM" such that their Legendre symbols differ. There, the leakage
would be catastrophic.

Feel free to forward my email to NIST for comments/review/corrections.

Best,

--mancha
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150615/a35ce95e/attachment-0001.bin>

From mail at quitesimple.org  Tue Jun 16 03:35:04 2015
From: mail at quitesimple.org (Albert S.)
Date: Mon, 15 Jun 2015 19:35:04 +0200
Subject: [PATCH] openbsd-compat/port-tun.c: fix missing NULL check
Message-ID: <557F0CC8.6050605@quitesimple.org>

Hello,

file openbsd-compat/port-tun.c, function sys_tun_outfilter().

This moves the "*dlen < sizeof(*af)" check inside the if-block above it,
thus avoiding a potential NULL dereference.

Found with clang's scan-build.

--- a/openbsd-compat/port-tun.c
+++ b/openbsd-compat/port-tun.c
@@ -260,10 +260,11 @@ sys_tun_outfilter(struct Channel *c, u_char
**data, u_int *dlen)
 	/* XXX new API is incompatible with this signature. */
 	if ((r = sshbuf_get_string(&c->output, data, &xxx_dlen)) != 0)
 		fatal("%s: buffer error: %s", __func__, ssh_err(r));
-	if (dlen != NULL)
+	if (dlen != NULL) {
 		*dlen = xxx_dlen;
-	if (*dlen < sizeof(*af))
-		return (NULL);
+		if (*dlen < sizeof(*af))
+			return (NULL);
+	}
 	buf = *data;

 #if defined(SSH_TUN_PREPEND_AF)

Best regards,
Albert

From naddy at mips.inka.de  Tue Jun 16 05:31:22 2015
From: naddy at mips.inka.de (Christian Weisgerber)
Date: Mon, 15 Jun 2015 19:31:22 +0000 (UTC)
Subject: OpenSSH and CBC
References: <557EDBA8.6060006@wiesinger.com>
Message-ID: <slrnmnua0a.1kdi.naddy@lorvorc.mips.inka.de>

On 2015-06-15, Gerhard Wiesinger <lists at wiesinger.com> wrote:

> I saw that OpenSSH release 6.7 removed all CBC ciphers by default. Is 
> CBC therefore considered as broken and unsecure (in general or SSH 
> implementation)?

CBC modes in SSH use the last encrypted block of the previous packet
as the IV for the next packet.  The protocol is specified this way.

> I also read a lot of references (see below) but still not clear to me 
> what's the actual "security status" of CBC and why it has been removed 
> in general.

These are pertinent:

> http://www.kb.cert.org/vuls/id/958563
http://www.openssh.com/txt/cbc.adv

-- 
Christian "naddy" Weisgerber                          naddy at mips.inka.de

From ag4ve.us at gmail.com  Tue Jun 16 07:03:06 2015
From: ag4ve.us at gmail.com (shawn wilson)
Date: Mon, 15 Jun 2015 17:03:06 -0400
Subject: OpenSSH and CBC
In-Reply-To: <slrnmnua0a.1kdi.naddy@lorvorc.mips.inka.de>
References: <557EDBA8.6060006@wiesinger.com>
 <slrnmnua0a.1kdi.naddy@lorvorc.mips.inka.de>
Message-ID: <CAH_OBifscdk+YMspY8L9zrKmZZ4OynXGd+Ze16Lb0OzM-Uce-Q@mail.gmail.com>

On Mon, Jun 15, 2015 at 3:31 PM, Christian Weisgerber
<naddy at mips.inka.de> wrote:
> On 2015-06-15, Gerhard Wiesinger <lists at wiesinger.com> wrote:
>
>> I saw that OpenSSH release 6.7 removed all CBC ciphers by default. Is
>> CBC therefore considered as broken and unsecure (in general or SSH
>> implementation)?
>
> CBC modes in SSH use the last encrypted block of the previous packet
> as the IV for the next packet.  The protocol is specified this way.
>
>> I also read a lot of references (see below) but still not clear to me
>> what's the actual "security status" of CBC and why it has been removed
>> in general.
>
> These are pertinent:
>
>> http://www.kb.cert.org/vuls/id/958563
> http://www.openssh.com/txt/cbc.adv
>

There PoC for that?

From mancha1 at zoho.com  Tue Jun 16 08:45:48 2015
From: mancha1 at zoho.com (mancha)
Date: Mon, 15 Jun 2015 22:45:48 +0000
Subject: [Bug 2302] with DH-GEX, ssh (and sshd) should not fall back to
 unconfigured DH groups or at least document this behaviour and use a
 stronger group
In-Reply-To: <20150615173123.GA10873@zoho.com>
References: <bug-2302-705@https.bugzilla.mindrot.org/>
 <bug-2302-705-KG2jIZVXcm@https.bugzilla.mindrot.org/>
 <48704.1432669189@eng-mail01.juniper.net>
 <87siahhgom.fsf@alice.fifthhorseman.net>
 <20150527220240.GA5826@zoho.com>
 <49674.1434088374@eng-mail01.juniper.net>
 <87ioaslnoc.fsf@alice.fifthhorseman.net>
 <68285.1434352159@eng-mail01.juniper.net>
 <20150615173123.GA10873@zoho.com>
Message-ID: <20150615224548.GA11649@zoho.com>

On Mon, Jun 15, 2015 at 05:31:23PM +0000, mancha wrote:
> Regarding Allen's last comment, I believe what he means is there
> doesn't appear to be a way to apply the methods of the index-calculus
> directly to the q-subgroup. In these subgroups, the state of the art
> algorithms have much lower O(n^(1/2)) runtimes.

I just noticed a most unfortunate typo in the above that inverts the
meaning. As most of you deduced, the sentence meant to say the
algorithms that can be used in the q-subgroup take longer: "In these
subgroups, the state of the art algorithms have much *slower* O(n^(1/2))
runtimes."

In contrast, when armed with the index calculus one is looking at a
complexity of L[1/3,(64/9)^(1/3)].

--mancha
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150615/73e165e4/attachment.bin>

From mancha1 at zoho.com  Tue Jun 16 09:21:16 2015
From: mancha1 at zoho.com (mancha)
Date: Mon, 15 Jun 2015 23:21:16 +0000
Subject: slothful ML
Message-ID: <20150615232116.GB11649@zoho.com>

Hi.

Recently my emails to the ML are taking a while to post (around 30
minutes).

I think these delays are recent (at least I've not noticed them before).

Ideas?

--mancha
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150615/48ce48eb/attachment.bin>

From lists at wiesinger.com  Tue Jun 16 19:52:56 2015
From: lists at wiesinger.com (Gerhard Wiesinger)
Date: Tue, 16 Jun 2015 11:52:56 +0200
Subject: OpenSSH and CBC
In-Reply-To: <slrnmnua0a.1kdi.naddy@lorvorc.mips.inka.de>
References: <557EDBA8.6060006@wiesinger.com>
 <slrnmnua0a.1kdi.naddy@lorvorc.mips.inka.de>
Message-ID: <557FF1F8.2060304@wiesinger.com>

On 15.06.2015 21:31, Christian Weisgerber wrote:
> On 2015-06-15, Gerhard Wiesinger <lists at wiesinger.com> wrote:
>
>> I saw that OpenSSH release 6.7 removed all CBC ciphers by default. Is
>> CBC therefore considered as broken and unsecure (in general or SSH
>> implementation)?
> CBC modes in SSH use the last encrypted block of the previous packet
> as the IV for the next packet.  The protocol is specified this way.

As the new IV depends on the (unknown) key and an unbroken crypto/hash 
algorithms I don't see any problem with this assuming normal behaviour 
with new keys on a new connection and correct implementation. Am I wrong?

>
>> I also read a lot of references (see below) but still not clear to me
>> what's the actual "security status" of CBC and why it has been removed
>> in general.
> These are pertinent:
>
>> http://www.kb.cert.org/vuls/id/958563
> http://www.openssh.com/txt/cbc.adv
>

But that should be already covered by:
http://www.openssh.com/txt/release-5.2
We believe that these attacks are rendered infeasible by these changes.

BTW: If you didn't know, here you find the details about the attacks 
(already in my link list):
http://isg.rhul.ac.uk/~kp/SandPfinal.pdf
I think it was unknown at the time OpenSSH 5.2 was released.
E.g. some assumptions are wrong: After at most 2^14 connections ...
With each new ssh connection I will have a new symmetrical key so the 
assumption is not feasible.

Also: One of the main challenges for building an exploit based on our 
proof-of-concept code would be to find a service which tolerates SSH 
connection failures and reconnects on these failures.
I think such assumptions are just theoretical.
Also according to the paper encrypt then-MAC schemes are also vulnerable 
(which are considered secure): But it is not hard to see that this 
construction would still be vulnerable to our attacks.

There is another paper available: Some Fixes To SSH
https://eprint.iacr.org/2013/151.pdf

BTW: Jan Zerebecki also doesn't recommend the AES CTR modes as they 
disclose packet length.
https://wiki.mozilla.org/Security/Guidelines/OpenSSH
Any comments on this?

Ciao,
Gerhard

-- http://www.wiesinger.com/


From lists at wiesinger.com  Tue Jun 16 21:14:39 2015
From: lists at wiesinger.com (Gerhard Wiesinger)
Date: Tue, 16 Jun 2015 13:14:39 +0200
Subject: OpenSSH and CBC
In-Reply-To: <557FF1F8.2060304@wiesinger.com>
References: <557EDBA8.6060006@wiesinger.com>
 <slrnmnua0a.1kdi.naddy@lorvorc.mips.inka.de> <557FF1F8.2060304@wiesinger.com>
Message-ID: <5580051F.4000203@wiesinger.com>

On 16.06.2015 11:52, Gerhard Wiesinger wrote:
> On 15.06.2015 21:31, Christian Weisgerber wrote:
>> On 2015-06-15, Gerhard Wiesinger <lists at wiesinger.com> wrote:
>>
>>> I saw that OpenSSH release 6.7 removed all CBC ciphers by default. Is
>>> CBC therefore considered as broken and unsecure (in general or SSH
>>> implementation)?
>> CBC modes in SSH use the last encrypted block of the previous packet
>> as the IV for the next packet.  The protocol is specified this way.
>
> As the new IV depends on the (unknown) key and an unbroken crypto/hash 
> algorithms I don't see any problem with this assuming normal behaviour 
> with new keys on a new connection and correct implementation. Am I wrong?
>
>>
>>> I also read a lot of references (see below) but still not clear to me
>>> what's the actual "security status" of CBC and why it has been removed
>>> in general.
>> These are pertinent:
>>
>>> http://www.kb.cert.org/vuls/id/958563
>> http://www.openssh.com/txt/cbc.adv
>>
>
> But that should be already covered by:
> http://www.openssh.com/txt/release-5.2
> We believe that these attacks are rendered infeasible by these changes.
>
> BTW: If you didn't know, here you find the details about the attacks 
> (already in my link list):
> http://isg.rhul.ac.uk/~kp/SandPfinal.pdf
> I think it was unknown at the time OpenSSH 5.2 was released.
> E.g. some assumptions are wrong: After at most 2^14 connections ...
> With each new ssh connection I will have a new symmetrical key so the 
> assumption is not feasible.
>
> Also: One of the main challenges for building an exploit based on our 
> proof-of-concept code would be to find a service which tolerates SSH 
> connection failures and reconnects on these failures.
> I think such assumptions are just theoretical.
> Also according to the paper encrypt then-MAC schemes are also 
> vulnerable (which are considered secure): But it is not hard to see 
> that this construction would still be vulnerable to our attacks.
>
> There is another paper available: Some Fixes To SSH
> https://eprint.iacr.org/2013/151.pdf
>
> BTW: Jan Zerebecki also doesn't recommend the AES CTR modes as they 
> disclose packet length.
> https://wiki.mozilla.org/Security/Guidelines/OpenSSH
> Any comments on this?
>

Jan answered me, as the packet length is transmitted in plaintext, see:
http://blog.djm.net.au/2013/11/chacha20-and-poly1305-in-openssh.html

Ciao,
Gerhard

-- http://www.wiesinger.com/


From aris at 0xbadc0de.be  Tue Jun 16 22:43:34 2015
From: aris at 0xbadc0de.be (Aris Adamantiadis)
Date: Tue, 16 Jun 2015 14:43:34 +0200
Subject: OpenSSH and CBC
In-Reply-To: <5580051F.4000203@wiesinger.com>
References: <557EDBA8.6060006@wiesinger.com>
 <slrnmnua0a.1kdi.naddy@lorvorc.mips.inka.de> <557FF1F8.2060304@wiesinger.com>
 <5580051F.4000203@wiesinger.com>
Message-ID: <558019F6.9000307@0xbadc0de.be>

Hi Gerhard,

This is not exactly true. CTR modes have the length field encrypted. etm 
MAC modes and AES-GCM have the length field in cleartext.
CBC is dangerous because the length field is encrypted with CBC.

aes128-ctr + hmac-sha256 doesn't have any known vulnerability and 
encrypts the packet length, but uses the bad practice of e&m.
chacha20-poly1305 encrypts both payload and packet len + uses 
authenticated encryption (best practice), even if the implementation 
looks very similar to etm.

Aris

>> BTW: Jan Zerebecki also doesn't recommend the AES CTR modes as they 
>> disclose packet length.
>> https://wiki.mozilla.org/Security/Guidelines/OpenSSH
>> Any comments on this?
>>
>
> Jan answered me, as the packet length is transmitted in plaintext, see:
> http://blog.djm.net.au/2013/11/chacha20-and-poly1305-in-openssh.html
>
> Ciao,
> Gerhard
>
> -- http://www.wiesinger.com/
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>


From openssh-unix-dev at opinionatedgeek.com  Thu Jun 18 00:08:22 2015
From: openssh-unix-dev at opinionatedgeek.com (Geoff Taylor)
Date: Wed, 17 Jun 2015 15:08:22 +0100
Subject: Building OpenSSH using Android's NDK
Message-ID: <CAHS0i2iMidWAsqjeeA7BbLaT4J=-=3UpLNxbb_tyVfwpAfJhnw@mail.gmail.com>

Hi,

(I hope this is the right list for this problem. My apologies if it's
not - can you please send me details of where I should post this
instead?)

tl;dr: I'd appreciate some help getting OpenSSH 6.8p1 to build using
Android's Native Development Kit. I've put together a Docker container
with the build environment if you want to try building it yourself
without changing your existing build setup.

I wanted to get an OpenSSH binary for an app I'm playing around with,
so I thought I'd try building OpenSSH6.8 using the Android NDK. It
didn't go well, and I'm hoping someone can point me in the right
direction. (I couldn't find any documents detailing how to build on
Android so if they exist please do let me know.) The problems and
error messages are detailed below.

To avoid any environmental differences, I've created a basic Docker
image for cross compilation. If you use Docker, you should be able to
grab it, start it, and have the latest NDK set up for cross-compiling
Android binaries. The Docker image is called
'opinionatedgeek/android-ndk-10e' on the Hub, and /src is available
for mapping so you don't lose changes when you stop the image.
Alternatively you can just view/copy the Dockerfile from:
    https://registry.hub.docker.com/u/opinionatedgeek/android-ndk-10e/dockerfile/

Once the Docker image is running, here are all the commands I used to
build OpenSSH:

----****----****----

# Some environment variables for building OpenSSL.
export FIPS_SIG=$PWD/openssl-fips-2.0.2/util/incore
export MACHINE=armv7l
export RELEASE=2.6.37
export SYSTEM=android
export ARCH=arm
export ANDROID_DEV="$ANDROID_NDK/platforms/android-21/arch-arm/usr"
export HOSTCC=gcc

# Get OpenSSL source code.
cd /src
wget https://www.openssl.org/source/openssl-1.0.2c.tar.gz
tar zxvf openssl-1.0.2c.tar.gz

# Build OpenSSL - this seems to go OK.
cd /src/openssl-1.0.2c
./config shared no-ssl2 no-ssl3 no-comp no-hw no-engine
--openssldir=/usr/local/ssl/$ANDROID_API
make depend
make all

# Get OpenSSH source code.
cd /src
wget http://mirror.ox.ac.uk/pub/OpenBSD/OpenSSH/portable/openssh-6.8p1.tar.gz
tar zxvf openssh-6.8p1.tar.gz

# Build OpenSSH.
cd /src/openssh-6.8p1
./configure --host=arm-linux-androideabi --with-ssl-dir=/src/openssl-1.0.2c
make all

----****----****----

The final line fails. It's a known problem, but when I fix that
another problem appears, and then another, and it got to the stage
that I wasn't comfortable with the horrible changes I was making to
work around the errors.

I'm new to both OpenSSH and Android NDK but, either:
* The environment is bad in some way.
* The configure command is wrong. (I've tried variants without success.)
* The 6.8p1 release isn't expected to build using the standard Android
NDK version 10e.
* There's an actual problem with building the source code.

(I'm hoping it's one of the first two options.)

Here are some of the errors I get:

----****----****----

(cd openbsd-compat && make)
make[1]: Entering directory '/src/openssh-6.8p1/openbsd-compat'
/android-ndk-r10e/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc
--sysroot=/android-ndk-r10e/platforms/android-21/arch-arm/ -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  -I. -I.. -I. -I./..
-I/src/openssl-1.0.2c/include
--sysroot=/android-ndk-r10e/platforms/android-21/arch-arm/
-DHAVE_CONFIG_H -c arc4random.c
In file included from ../includes.h:177:0,
                 from arc4random.c:27:
../openbsd-compat/openbsd-compat.h:224:22: error: expected identifier
or '(' before numeric constant
 # define mblen(x, y) 1
                      ^
Makefile:26: recipe for target 'arc4random.o' failed
make[1]: *** [arc4random.o] Error 1
make[1]: Leaving directory '/src/openssh-6.8p1/openbsd-compat'
Makefile:156: recipe for target 'openbsd-compat/libopenbsd-compat.a' failed
make: *** [openbsd-compat/libopenbsd-compat.a] Error 2

----****----****----

Changing:

# define mblen(x, y)  1

to:

# define mblen(x, y)  (1)

(as per Bugzilla) didn't fix this for me, but this allowed the build
to continue:

#define mblen innocuous_mblen

The next problem:

----****----****----

/android-ndk-r10e/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc
--sysroot=/android-ndk-r10e/platforms/android-21/arch-arm/ -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  -I. -I.. -I. -I./..
-I/src/openssl-1.0.2c/include
--sysroot=/android-ndk-r10e/platforms/android-21/arch-arm/
-DHAVE_CONFIG_H -c getrrsetbyname.c
getrrsetbyname.c: In function 'getrrsetbyname':
getrrsetbyname.c:190:59: error: dereferencing pointer to incomplete type
  struct __res_state *_resp = _THREAD_PRIVATE(_res, _res, &_res);
                                                           ^
getrrsetbyname.c:68:33: note: in definition of macro '_THREAD_PRIVATE'
 #define _THREAD_PRIVATE(a,b,c) (c)
                                 ^
getrrsetbyname.c:219:12: error: dereferencing pointer to incomplete type
  if ((_resp->options & RES_INIT) == 0 && res_init() == -1) {
            ^
getrrsetbyname.c:219:24: error: 'RES_INIT' undeclared (first use in
this function)
  if ((_resp->options & RES_INIT) == 0 && res_init() == -1) {
                        ^
getrrsetbyname.c:219:24: note: each undeclared identifier is reported
only once for each function it appears in
getrrsetbyname.c:219:2: warning: implicit declaration of function
'res_init' [-Wimplicit-function-declaration]
  if ((_resp->options & RES_INIT) == 0 && res_init() == -1) {
  ^
getrrsetbyname.c:235:2: warning: implicit declaration of function
'res_query' [-Wimplicit-function-declaration]
  length = res_query(hostname, (signed int) rdclass, (signed int) rdtype,
  ^
Makefile:26: recipe for target 'getrrsetbyname.o' failed
make[1]: *** [getrrsetbyname.o] Error 1
make[1]: Leaving directory '/src/openssh-6.8p1/openbsd-compat'
Makefile:156: recipe for target 'openbsd-compat/libopenbsd-compat.a' failed
make: *** [openbsd-compat/libopenbsd-compat.a] Error 2

----****----****----

looked more serious. When I worked around this problem, more problems
appeared and really, the workaround itself was just plain wrong. (The
workaround that allowed me to continue building involved copying in
structs, enums and defines from the regular resolv.h on Ubuntu.) It
was then I figured I should ask for help.

For the record, the next build error was:

----****----****----

/android-ndk-r10e/toolchains/arm-linux-androideabi-4.9/prebuilt/linux-x86_64/bin/arm-linux-androideabi-gcc
--sysroot=/android-ndk-r10e/platforms/android-21/arch-arm/ -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  -I. -I.. -I. -I./..
-I/src/openssl-1.0.2c/include
--sysroot=/android-ndk-r10e/platforms/android-21/arch-arm/
-DHAVE_CONFIG_H -c pwcache.c
In file included from pwcache.c:37:0:
/android-ndk-r10e/platforms/android-21/arch-arm/usr/include/grp.h:59:21:
error: macro "endgrent" passed 1 arguments, but takes just 0
 void   endgrent(void);
                     ^
Makefile:26: recipe for target 'pwcache.o' failed
make[1]: *** [pwcache.o] Error 1
make[1]: Leaving directory '/src/openssh-6.8p1/openbsd-compat'
Makefile:156: recipe for target 'openbsd-compat/libopenbsd-compat.a' failed
make: *** [openbsd-compat/libopenbsd-compat.a] Error 2

----****----****----

So, should it build or am I doing something wrong? I tried pulling the
latest code from git too, but didn't have any more success getting it
to build.

Any help would be appreciated.

Many thanks,

    Geoff

From mark at markelee.com  Fri Jun 19 00:55:10 2015
From: mark at markelee.com (Mark Lee)
Date: Thu, 18 Jun 2015 10:55:10 -0400
Subject: What does the socks function of openssh hide?
Message-ID: <2091088.OiL94qK7yK@melech-hp>

Salutations,

I was recently using openssh 6.8p1-3 for socks tunelling with a public wifi 
hotspot. I attempted to watch youtube but was notified that it was not allowed 
in my area. The socks server I was connected to definitely had the ability to 
connect to youtube, so I concluded the issue was with the public wifi hotspot. 
How much does socks tunneling with openssh obscure?

Command : ssh -ND 4711

Regards,
Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150618/232cbe32/attachment.bin>

From flavien-ssh at lebarbe.net  Fri Jun 19 01:59:32 2015
From: flavien-ssh at lebarbe.net (Flavien)
Date: Thu, 18 Jun 2015 17:59:32 +0200
Subject: What does the socks function of openssh hide?
In-Reply-To: <2091088.OiL94qK7yK@melech-hp>
References: <2091088.OiL94qK7yK@melech-hp>
Message-ID: <20150618155932.GB24498@srv3.flavien.org>

Hi,


What client software were you proxying with socks ? Could it be
Firefox ? I was quite surprised once to see that by default firefox
did *not* proxy the dns queries through socks. I had to set some
advance option to force that.

This could explain your situation : the DNS of the public wifi hotspot
sent you to youtube servers close to you, not the ones close to
your server.


Flavien.


Mark Lee ecrivait :
> Salutations,
> 
> I was recently using openssh 6.8p1-3 for socks tunelling with a public wifi 
> hotspot. I attempted to watch youtube but was notified that it was not allowed 
> in my area. The socks server I was connected to definitely had the ability to 
> connect to youtube, so I concluded the issue was with the public wifi hotspot. 
> How much does socks tunneling with openssh obscure?
> 
> Command : ssh -ND 4711
> 
> Regards,
> Mark

From esk-openssh at esk.cs.usu.edu  Fri Jun 19 02:04:01 2015
From: esk-openssh at esk.cs.usu.edu (Eldon Koyle)
Date: Thu, 18 Jun 2015 10:04:01 -0600
Subject: What does the socks function of openssh hide?
In-Reply-To: <2091088.OiL94qK7yK@melech-hp>
References: <2091088.OiL94qK7yK@melech-hp>
Message-ID: <20150618160401.GC1890@esk.usu.edu>

Hi Mark,

On  Jun 18 10:55-0400, Mark Lee wrote:
<snip>
> in my area. The socks server I was connected to definitely had the ability to 
> connect to youtube, so I concluded the issue was with the public wifi hotspot. 
> How much does socks tunneling with openssh obscure?
<snip>

I suspect your DNS requests are going across your normal network
connection.  It looks like a lot of browsers require additional
configuration to push DNS traffic over socks:

http://serverfault.com/questions/337791/if-i-am-using-ssh-for-a-socks-proxy-do-dns-connections-go-through-it

-- 
Eldon Koyle
Information Technology
Utah State University
-- 
BOFH excuse #11:
magnetic interference from money/credit cards

From mark at markelee.com  Fri Jun 19 02:30:54 2015
From: mark at markelee.com (Mark Lee)
Date: Thu, 18 Jun 2015 12:30:54 -0400
Subject: What does the socks function of openssh hide?
In-Reply-To: <20150618155932.GB24498@srv3.flavien.org>
References: <2091088.OiL94qK7yK@melech-hp>
 <20150618155932.GB24498@srv3.flavien.org>
Message-ID: <1806013.fsmXiX160G@melech-hp>

On Thursday, June 18, 2015 05:59:32 PM Flavien wrote:
> Hi,
> 
> 
> What client software were you proxying with socks ? Could it be
> Firefox ? I was quite surprised once to see that by default firefox
> did *not* proxy the dns queries through socks. I had to set some
> advance option to force that.
> 
> This could explain your situation : the DNS of the public wifi hotspot
> sent you to youtube servers close to you, not the ones close to
> your server.

I was using firefox.

Regards,
Mark
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150618/9552d8cd/attachment.bin>

From lists at wiesinger.com  Fri Jun 19 03:25:19 2015
From: lists at wiesinger.com (Gerhard Wiesinger)
Date: Thu, 18 Jun 2015 19:25:19 +0200
Subject: OpenSSH and CBC
In-Reply-To: <558019F6.9000307@0xbadc0de.be>
References: <557EDBA8.6060006@wiesinger.com>
 <slrnmnua0a.1kdi.naddy@lorvorc.mips.inka.de> <557FF1F8.2060304@wiesinger.com>
 <5580051F.4000203@wiesinger.com> <558019F6.9000307@0xbadc0de.be>
Message-ID: <5582FEFF.4080107@wiesinger.com>

On 16.06.2015 14:43, Aris Adamantiadis wrote:
> Hi Gerhard,
>
> This is not exactly true. CTR modes have the length field encrypted. 
> etm MAC modes and AES-GCM have the length field in cleartext.
> CBC is dangerous because the length field is encrypted with CBC.
>

What's exactly the topic encrypting the length field with CBC?
Any documentation/papers on this to understand (except the source)?

> aes128-ctr + hmac-sha256 doesn't have any known vulnerability and 
> encrypts the packet length, but uses the bad practice of e&m.
> chacha20-poly1305 encrypts both payload and packet len + uses 
> authenticated encryption (best practice), even if the implementation 
> looks very similar to etm.
>

Why is E&M bad practice?

Thank you.

Ciao,
Gerhard

From dtucker at zip.com.au  Fri Jun 19 11:18:03 2015
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 19 Jun 2015 11:18:03 +1000
Subject: What does the socks function of openssh hide?
In-Reply-To: <1806013.fsmXiX160G@melech-hp>
References: <2091088.OiL94qK7yK@melech-hp>
 <20150618155932.GB24498@srv3.flavien.org>
 <1806013.fsmXiX160G@melech-hp>
Message-ID: <CALDDTe3HV+qrc9Ag0VxRhFvbwBmP65qEaPWF8yq==5CORLtRqQ@mail.gmail.com>

On Fri, Jun 19, 2015 at 2:30 AM, Mark Lee <mark at markelee.com> wrote:
>
> I was using firefox.
>

By default Firefox will do the name resolution locally then make SOCKS4
requests with the resulting IP addresses.  You can change that by going to
about:config and setting network.proxy.socks_remote_dns to true, which will
cause Firefox to make SOCKS4A requests which have the un-resolved names in
them, which the SSH server will then resolve.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From lists at wiesinger.com  Fri Jun 19 14:46:12 2015
From: lists at wiesinger.com (Gerhard Wiesinger)
Date: Fri, 19 Jun 2015 06:46:12 +0200
Subject: OpenSSH and CBC
In-Reply-To: <557EDBA8.6060006@wiesinger.com>
References: <557EDBA8.6060006@wiesinger.com>
Message-ID: <55839E94.8070009@wiesinger.com>

On 15.06.2015 16:05, Gerhard Wiesinger wrote:
> http://www.cpni.gov.uk/Docs/Vulnerability_Advisory_SSH.txt
> https://packetstormsecurity.com/files/72061/Vulnerability_Advisory_SSH.txt.html 
>
> http://isg.rhul.ac.uk/~kp/SandPfinal.pdf

The success probability in recovering 32 plaintext bits is 2^{-18} when 
attacking the OpenSSH implementation of the SSH RFCs. A variant of the 
attack against the OpenSSH implementation verifiably recovers 14 
plaintext bits with probability 2^{-14}.

Recovering 14 bits: That's basically no better than brute force, so no 
real attack, isn't it?
Recovering 32 bits: That's basically a little bit better than brute 
force bu think there is also no real attack vector, isn't it?

Especially in the context of OpenSSH 5.2 mitigation and different keys 
in different kind of connections.

Any opinions on this?

Ciao,
Gerhard

--
http://www.wiesinger.com/


From Robert.Mattson at exelisinc.com  Fri Jun 19 15:24:37 2015
From: Robert.Mattson at exelisinc.com (Mattson, Robert - Exelis)
Date: Fri, 19 Jun 2015 05:24:37 +0000
Subject: subscribe
Message-ID: <B6BD7CABC9E71E429C5D3E8B57DC088625ECD498@USFWA1E14-08.corp.exelisinc.com>





Dr Robert Mattson
[Exelis_C4i_rgb]
380 St Kilda Rd, Melbourne,
Vic, 3004, Australia
+61 3 9926 1124
robert.mattson at exelisinc.com  <mailto:robert.mattson at exelisinc.com>
www.c4i.com<http://www.c4i.com/>       www.exelisinc.com<http://www.exelisinc.com/>
[Follow Exelis][Exelis Facebook link]<https://www.facebook.com/Exelis>[Exelis Twitter link]<https://twitter.com/exelisinc>[Exelis YouTube link]<http://www.youtube.com/ittexelis>[Exelis Facebook careers link]<https://www.facebook.com/pages/Exelis-Careers/160367014041823>[Exelis Linkedin link]<http://www.linkedin.com/company/2375961>

























________________________________

This e-mail and any files transmitted with it may be proprietary and are intended solely for the use of the individual or entity to whom they are addressed. If you have received this e-mail in error please notify the sender. Please note that any views or opinions presented in this e-mail are solely those of the author and do not necessarily represent those of Exelis Inc. The recipient should check this e-mail and any attachments for the presence of viruses. Exelis Inc. accepts no liability for any damage caused by any virus transmitted by this e-mail.

From djm at mindrot.org  Fri Jun 19 18:29:57 2015
From: djm at mindrot.org (Damien Miller)
Date: Fri, 19 Jun 2015 18:29:57 +1000 (AEST)
Subject: OpenSSH and CBC
In-Reply-To: <55839E94.8070009@wiesinger.com>
References: <557EDBA8.6060006@wiesinger.com> <55839E94.8070009@wiesinger.com>
Message-ID: <alpine.BSO.2.20.1506191827400.22353@natsu.mindrot.org>

On Fri, 19 Jun 2015, Gerhard Wiesinger wrote:

> On 15.06.2015 16:05, Gerhard Wiesinger wrote:
> > http://www.cpni.gov.uk/Docs/Vulnerability_Advisory_SSH.txt
> > https://packetstormsecurity.com/files/72061/Vulnerability_Advisory_SSH.txt.html 
> > http://isg.rhul.ac.uk/~kp/SandPfinal.pdf
> 
> The success probability in recovering 32 plaintext bits is 2^{-18} when
> attacking the OpenSSH implementation of the SSH RFCs. A variant of the attack
> against the OpenSSH implementation verifiably recovers 14 plaintext bits with
> probability 2^{-14}.

That's before our countermeasures, that make this attack AFAIK infeasible.

> Recovering 14 bits: That's basically no better than brute force, so no real
> attack, isn't it?

No, it's a real attack but it is not practical in most configurations.

> Recovering 32 bits: That's basically a little bit better than brute force bu
> think there is also no real attack vector, isn't it?

Depends on what the 32 bits are. If I can recover 32 bits of a password
than you're going to have a bad day.

> Especially in the context of OpenSSH 5.2 mitigation and different keys in
> different kind of connections.
> 
> Any opinions on this?

The defaults in recent OpenSSH are safe against this attack. It's not
something you need to worry about if both ends are OpenSSH. If you're
using a non-OpenSSH client or server then you might need to pay more
attention.

-d

From venugrda at gmail.com  Sat Jun 20 00:23:48 2015
From: venugrda at gmail.com (Venugopal Rao)
Date: Fri, 19 Jun 2015 19:53:48 +0530
Subject: Reg sftp commands
Message-ID: <CACgKAG=tyN1jNE18yJjFucVG5w3DpvvkoW9=4ALjKrgNgD+S-A@mail.gmail.com>

Hi,

In ftp we have binary and site commands. what are the relevant commands in
sftp. The problems we are facing are mainframe binary conversion from ASCII
when sending files to mainframe from Unix. And file size allocations when
sending large files(in ftp we can specify size using site).

Thanks,
Venu.

From djm at mindrot.org  Sat Jun 20 09:00:27 2015
From: djm at mindrot.org (Damien Miller)
Date: Sat, 20 Jun 2015 09:00:27 +1000 (AEST)
Subject: Reg sftp commands
In-Reply-To: <CACgKAG=tyN1jNE18yJjFucVG5w3DpvvkoW9=4ALjKrgNgD+S-A@mail.gmail.com>
References: <CACgKAG=tyN1jNE18yJjFucVG5w3DpvvkoW9=4ALjKrgNgD+S-A@mail.gmail.com>
Message-ID: <alpine.BSO.2.20.1506200857390.1901@natsu.mindrot.org>

On Fri, 19 Jun 2015, Venugopal Rao wrote:

> Hi,
> 
> In ftp we have binary and site commands. what are the relevant commands in
> sftp. The problems we are facing are mainframe binary conversion from ASCII
> when sending files to mainframe from Unix. And file size allocations when
> sending large files(in ftp we can specify size using site).

Neither are supported in OpenSSH's sftp and we have no intention of
doing so. There are 3rd-party sftp servers that might implement some
of these options though.

-d

From keisial at gmail.com  Sat Jun 20 10:01:15 2015
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Sat, 20 Jun 2015 02:01:15 +0200
Subject: OpenSSH and CBC
In-Reply-To: <5582FEFF.4080107@wiesinger.com>
References: <557EDBA8.6060006@wiesinger.com>
 <slrnmnua0a.1kdi.naddy@lorvorc.mips.inka.de> <557FF1F8.2060304@wiesinger.com>
 <5580051F.4000203@wiesinger.com> <558019F6.9000307@0xbadc0de.be>
 <5582FEFF.4080107@wiesinger.com>
Message-ID: <5584AD4B.1050400@gmail.com>

On 18/06/15 19:25, Gerhard Wiesinger wrote:
>> aes128-ctr + hmac-sha256 doesn't have any known vulnerability and 
>> encrypts the packet length, but uses the bad practice of e&m.
>> chacha20-poly1305 encrypts both payload and packet len + uses 
>> authenticated encryption (best practice), even if the implementation 
>> looks very similar to etm.
>>
>
> Why is E&M bad practice?
First of all Encrypt-and-MAC (E&M) allows an attacker to recognise two 
identical messages due to the shared MAC.

The ideal method of composing ciphers and macs is to use 
Encrypt-and-MAC, which has the very nice property of not decrypting 
anything before authenticating it. For instance, a common error is to 
fail early (in a way noticeable by timing) before checking the mac (eg. 
such as noticing that the plaintext is corrupt).

Colin Percival explains in 
http://www.daemonology.net/blog/2009-06-24-encrypt-then-mac.html how 
only Encrypt-then-MAC is provably secure. See 
http://cseweb.ucsd.edu/~mihir/papers/oem.pdf for the detailed proof 
comparing the modes.



From nkadel at gmail.com  Sat Jun 20 21:49:37 2015
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Sat, 20 Jun 2015 07:49:37 -0400
Subject: Reg sftp commands
In-Reply-To: <CACgKAG=tyN1jNE18yJjFucVG5w3DpvvkoW9=4ALjKrgNgD+S-A@mail.gmail.com>
References: <CACgKAG=tyN1jNE18yJjFucVG5w3DpvvkoW9=4ALjKrgNgD+S-A@mail.gmail.com>
Message-ID: <CAOCN9ryzghMP25opYMf0YaXnS8RWLMHCFzP0Uv_dCTh8aSgyVQ@mail.gmail.com>

On Fri, Jun 19, 2015 at 10:23 AM, Venugopal Rao <venugrda at gmail.com> wrote:
> Hi,
>
> In ftp we have binary and site commands. what are the relevant commands in
> sftp. The problems we are facing are mainframe binary conversion from ASCII
> when sending files to mainframe from Unix. And file size allocations when
> sending large files(in ftp we can specify size using site).
>
> Thanks,
> Venu.

There are quite a few FTP behaviors that SFTP does not support. If you
think of SFTP as being "SCP with a command line interface", instead of
being "secured FTP", you'll be closer to the reality of it. SFTP, for
example, is "binary-only". You can't enable 'end-of-line" conversions
in it, and it doesn't handle differences in local time settings
between clients and servers well.

If you need FTPs subtler features, then I'd urge you to switch to
FTPS, and use the 'vsftpd' daemon. That also supports symlinks and the
full FTP command line toolset, and it's much easier to segregate
individual clients to individual, distinct, effectively chrooted
directories for access. It's also usable with tools like the "lftp"
mirror command to mirror a remote repository, instead of simply
downloading it.

Alternatively, I've found myself actually preferring to use "git" for
complex local file synchronization. That allows me to maintain
slightly distinct variants of the same content for slightly distinct
local environments, to efficiently download local changes much the
lftp 'mirror' or rsync based commands, and to allow recording and
publishing local changes to a central git repo more effectively, with
changes bothlogged and reversible. Git might not work well for large
binary directories, but it's a thought.

From mail at quitesimple.org  Sun Jun 21 00:31:11 2015
From: mail at quitesimple.org (Albert S.)
Date: Sat, 20 Jun 2015 16:31:11 +0200
Subject: [PATCH] Fix potential use after free in uidswap.c (portable)
Message-ID: <5585792F.70600@quitesimple.org>

Fixes a potential (but probably rather unlikely) use after free bug in
function temporarily_use_uid(), file uidswap.c.

--- a/uidswap.c
+++ b/uidswap.c
@@ -113,8 +113,9 @@ temporarily_use_uid(struct passwd *pw)
                }
        }
        /* Set the effective uid to the given (unprivileged) uid. */
-       if (setgroups(user_groupslen, user_groups) < 0)
-               fatal("setgroups: %.100s", strerror(errno));
+       if (user_groupslen > 0 &&
+            (setgroups(user_groupslen, user_groups)) < 0)
+               fatal("setgroups: %.100s", strerror(errno));

Best regards,
Albert

From igor at mir2.org  Sun Jun 21 05:12:45 2015
From: igor at mir2.org (Igor Bukanov)
Date: Sat, 20 Jun 2015 21:12:45 +0200
Subject: sshd and consequences of HostKeyAgent
Message-ID: <CADd11yVJ9B46hiie7wFg3oNHXdhAG7DP1neZ=2rdaaWiQBn0Ag@mail.gmail.com>

Hello,

I tried to use HostKeyAgent with sshd 6.7 under Linux. That worked for
Linux clients. However, when I tried to connect from OpenSSH 6.2 under
Mac OS X, the server disconnects:

debug2: bits set: 1026/2048
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
Connection closed by 84.22.97.209

When I disabled HostKeyAgent and switched HostKey back to the private
keys, then I could connect from the Mac client again.This implies that
HostKeyAgent somehow affects the bytes that are sent to the client.

Why is it so? I.e. shouldn't HostKeyAgent just be an implementation
detail that should not affect the client in any way?

From zev at bewilderbeest.net  Sun Jun 21 06:34:46 2015
From: zev at bewilderbeest.net (Zev Weiss)
Date: Sat, 20 Jun 2015 15:34:46 -0500
Subject: sshd and consequences of HostKeyAgent
In-Reply-To: <CADd11yVJ9B46hiie7wFg3oNHXdhAG7DP1neZ=2rdaaWiQBn0Ag@mail.gmail.com>
References: <CADd11yVJ9B46hiie7wFg3oNHXdhAG7DP1neZ=2rdaaWiQBn0Ag@mail.gmail.com>
Message-ID: <20150620203446.GD27916@hatter.bewilderbeest.net>

On Sat, Jun 20, 2015 at 09:12:45PM +0200, Igor Bukanov wrote:
>Hello,
>
>I tried to use HostKeyAgent with sshd 6.7 under Linux. That worked for
>Linux clients. However, when I tried to connect from OpenSSH 6.2 under
>Mac OS X, the server disconnects:
>
>debug2: bits set: 1026/2048
>debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
>debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
>Connection closed by 84.22.97.209
>
>When I disabled HostKeyAgent and switched HostKey back to the private
>keys, then I could connect from the Mac client again.This implies that
>HostKeyAgent somehow affects the bytes that are sent to the client.
>
>Why is it so? I.e. shouldn't HostKeyAgent just be an implementation
>detail that should not affect the client in any way?
>

Apologies if this is overly obvious, but are you certain you added a key 
of a type supported by the client to the hostkey agent?  The 
Apple-supplied, nominally-6.2 ssh client on my OSX machine doesn't seem 
to support anything but RSA and DSS, so with that client I get the same 
behavior you note above with only ECDSA & ED25519 hostkeys added to the 
server's agent, but after also adding an RSA key it works fine.  (A 6.7 
client I have from MacPorts does support ECDSA and ED25519 though, for 
what it's worth.)


Zev


From igor at mir2.org  Sun Jun 21 08:24:40 2015
From: igor at mir2.org (Igor Bukanov)
Date: Sun, 21 Jun 2015 00:24:40 +0200
Subject: sshd and consequences of HostKeyAgent
In-Reply-To: <20150620203446.GD27916@hatter.bewilderbeest.net>
References: <CADd11yVJ9B46hiie7wFg3oNHXdhAG7DP1neZ=2rdaaWiQBn0Ag@mail.gmail.com>
 <20150620203446.GD27916@hatter.bewilderbeest.net>
Message-ID: <CADd11yVh=NRnG=9HKu2xDY-Wa9rgomThQAoE-ofL9eDHBWQrRw@mail.gmail.com>

On 20 June 2015 at 22:34, Zev Weiss <zev at bewilderbeest.net> wrote:
>
> Apologies if this is overly obvious, but are you certain you added a key of
> a type supported by the client to the hostkey agent?

Big thanks for the tip!!! It turned out my script was adding a wrong
private rsa key to the agent that has not matched the public key from
ssh_config file. After I fixed that everything started to work :)

From dtucker at zip.com.au  Mon Jun 22 11:36:45 2015
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 22 Jun 2015 11:36:45 +1000
Subject: [PATCH] Fix potential use after free in uidswap.c (portable)
In-Reply-To: <5585792F.70600@quitesimple.org>
References: <5585792F.70600@quitesimple.org>
Message-ID: <CALDDTe3CKBxfFTk-XFvw0b5BYVhPEZq_dgAwPMCoSi83wDe8pA@mail.gmail.com>

On Sun, Jun 21, 2015 at 12:31 AM, Albert S. <mail at quitesimple.org> wrote:

> Fixes a potential (but probably rather unlikely) use after free bug in
> function temporarily_use_uid(), file uidswap.c.
>

Does seem unlikely (with zero entries there's no reason for it to deref the
pointer), however reading the man pages it seems like there's no guarantee
that it won't, so seems reasonable to me.  Damien?


> --- a/uidswap.c
> +++ b/uidswap.c
> @@ -113,8 +113,9 @@ temporarily_use_uid(struct passwd *pw)
>                 }
>         }
>         /* Set the effective uid to the given (unprivileged) uid. */
> -       if (setgroups(user_groupslen, user_groups) < 0)
> -               fatal("setgroups: %.100s", strerror(errno));
> +       if (user_groupslen > 0 &&
> +            (setgroups(user_groupslen, user_groups)) < 0)
> +               fatal("setgroups: %.100s", strerror(errno));
>
> Best regards,
> Albert
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>



-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From djm at mindrot.org  Mon Jun 22 12:59:56 2015
From: djm at mindrot.org (Damien Miller)
Date: Mon, 22 Jun 2015 12:59:56 +1000 (AEST)
Subject: [PATCH] Fix potential use after free in uidswap.c (portable)
In-Reply-To: <CALDDTe3CKBxfFTk-XFvw0b5BYVhPEZq_dgAwPMCoSi83wDe8pA@mail.gmail.com>
References: <5585792F.70600@quitesimple.org>
 <CALDDTe3CKBxfFTk-XFvw0b5BYVhPEZq_dgAwPMCoSi83wDe8pA@mail.gmail.com>
Message-ID: <alpine.BSO.2.20.1506221259510.32517@natsu.mindrot.org>

ok djm

On Mon, 22 Jun 2015, Darren Tucker wrote:

> On Sun, Jun 21, 2015 at 12:31 AM, Albert S. <mail at quitesimple.org> wrote:
> 
> > Fixes a potential (but probably rather unlikely) use after free bug in
> > function temporarily_use_uid(), file uidswap.c.
> >
> 
> Does seem unlikely (with zero entries there's no reason for it to deref the
> pointer), however reading the man pages it seems like there's no guarantee
> that it won't, so seems reasonable to me.  Damien?
> 
> 
> > --- a/uidswap.c
> > +++ b/uidswap.c
> > @@ -113,8 +113,9 @@ temporarily_use_uid(struct passwd *pw)
> >                 }
> >         }
> >         /* Set the effective uid to the given (unprivileged) uid. */
> > -       if (setgroups(user_groupslen, user_groups) < 0)
> > -               fatal("setgroups: %.100s", strerror(errno));
> > +       if (user_groupslen > 0 &&
> > +            (setgroups(user_groupslen, user_groups)) < 0)
> > +               fatal("setgroups: %.100s", strerror(errno));
> >
> > Best regards,
> > Albert
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev at mindrot.org
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> >
> 
> 
> 
> -- 
> Darren Tucker (dtucker at zip.com.au)
> GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
>     Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

From pch-openssh at u-1.phicoh.com  Mon Jun 22 22:21:50 2015
From: pch-openssh at u-1.phicoh.com (Philip Homburg)
Date: Mon, 22 Jun 2015 14:21:50 +0200
Subject: Small issue with DNSSEC / SSHFP
Message-ID: <m1Z70jY-0000CVC@stereo.hq.phicoh.net>

Hi,

I found a small issue with DNSSEC validation of SSHFP lookups. (For reference
I used OpenSSH 6.8p1 on FreeBSD 10.1).

The issues is that when DNSSEC valiation fails, ssh displays a confusing
message to the user. When DNSSEC validation of a SSHFP record fails, ssh
presents the user with
"Matching host key fingerprint found in DNS.
"Are you sure you want to continue connecting (yes/no)?

(For example 
$ ./ssh -o 'VerifyHostKeyDNS True' fx.dnssec-broken.phicoh.nl
Which has an intentionally broken DNSSEC delegation)

I propose to change that to:
"The DNS lookup was not secure, however a matching host key fingerprint was found in DNS."

This should make it clear to anyone who relies on DNSSEC that something went
wrong. A patch is at the end of this mail.

At first I also found that DNSSEC validation always fails due to lack of trust
anchor. There is also a ticket for that:
https://bugzilla.mindrot.org/show_bug.cgi?id=2119

However, in the mailing list archive I found:
https://lists.mindrot.org/pipermail/openssh-unix-dev/2012-May/030443.html
(Just adding an 'anchor' line to /etc/resolv.conf solves that issue)

Finally, there is the issue that ldns relies on a DNSSEC aware resolver to
supply the RRSIG records. Note that the resolver doesn't have to be trusted,
it just has to pass the RRSIG records.

However, many CPEs are not DNSSEC aware, so that breaks the validation.


commit da3654f67293daffc913b87eb05eac098e462838
Author: Philip Homburg <philip at f-src.phicoh.com>
Date:   Mon Jun 22 12:52:45 2015 +0200

    Better diagnostic when DNSSEC validation fails.

diff --git a/sshconnect.c b/sshconnect.c
index f41960c..9f1eafa 100644
--- a/sshconnect.c
+++ b/sshconnect.c
@@ -71,6 +71,7 @@ char *server_version_string = NULL;
 Key *previous_host_key = NULL;
 
 static int matching_host_key_dns = 0;
+static int dns_secure = 0;
 
 static pid_t proxy_command_pid = 0;
 
@@ -972,13 +973,18 @@ check_host_key(char *hostname, struct sockaddr *hostaddr, u_short port,
 				fatal("%s: sshkey_fingerprint fail", __func__);
 			msg2[0] = '\0';
 			if (options.verify_host_key_dns) {
-				if (matching_host_key_dns)
+				if (!matching_host_key_dns)
 					snprintf(msg2, sizeof(msg2),
-					    "Matching host key fingerprint"
+					    "No matching host key fingerprint"
 					    " found in DNS.\n");
+				else if (!dns_secure)
+					snprintf(msg2, sizeof(msg2),
+					    "The DNS lookup was not secure,"
+					    " however a matching host key"
+					    " fingerprint was found in DNS.\n");
 				else
 					snprintf(msg2, sizeof(msg2),
-					    "No matching host key fingerprint"
+					    "Matching host key fingerprint"
 					    " found in DNS.\n");
 			}
 			snprintf(msg, sizeof(msg),
@@ -1295,6 +1301,9 @@ verify_host_key(char *host, struct sockaddr *hostaddr, Key *host_key)
 					r = 0;
 					goto out;
 				}
+				if (flags & DNS_VERIFY_SECURE) {
+					dns_secure = 1;
+				}
 				if (flags & DNS_VERIFY_MATCH) {
 					matching_host_key_dns = 1;
 				} else {

From opensshdev at r.paypc.com  Tue Jun 23 10:24:01 2015
From: opensshdev at r.paypc.com (Malcolm)
Date: Mon, 22 Jun 2015 17:24:01 -0700
Subject: Small issue with DNSSEC / SSHFP
In-Reply-To: <m1Z70jY-0000CVC@stereo.hq.phicoh.net>
References: <m1Z70jY-0000CVC@stereo.hq.phicoh.net>
Message-ID: <1435019041.5588a721f15357.76125085@www.paypc.com>

Quoting Philip Homburg <pch-openssh at u-1.phicoh.com>:

> Hi,
> 
> I found a small issue with DNSSEC validation of SSHFP lookups. (For
> reference
> I used OpenSSH 6.8p1 on FreeBSD 10.1).
> 
> The issues is that when DNSSEC valiation fails, ssh displays a confusing
> message to the user. When DNSSEC validation of a SSHFP record fails, ssh
> presents the user with
> "Matching host key fingerprint found in DNS.
> "Are you sure you want to continue connecting (yes/no)?

That's not the only confusing one.  I ran into another confusing error message
on some of my 6.6 clients when connecting to hosts which had published a full
set of SSHFPs (types 1 and 4 anyway, with both hash records for each of
those).  It was something vague like "Error calculating host key fingerprint"
with no mention of an unsupported SSHFP record.

Even though Curve25519 support was in those older versions, I guess the
support for the Ed25519 algorithm in SSHFPs lagged them by quite a while.  I
don't use algorithms 2 or 3 since none of my SSHDs are configured to support them.

It's probably of minor importance, since DNS fingerprinting is not the best
primary mechanism to verify a server's host key fingerprint.

=R=

From dtucker at zip.com.au  Tue Jun 23 12:53:39 2015
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 23 Jun 2015 12:53:39 +1000
Subject: [PATCH] Fix potential use after free in uidswap.c (portable)
In-Reply-To: <CALDDTe3CKBxfFTk-XFvw0b5BYVhPEZq_dgAwPMCoSi83wDe8pA@mail.gmail.com>
References: <5585792F.70600@quitesimple.org>
 <CALDDTe3CKBxfFTk-XFvw0b5BYVhPEZq_dgAwPMCoSi83wDe8pA@mail.gmail.com>
Message-ID: <CALDDTe318V8S8qaKsL7GQxLVjRvqhwU_-u2SzLsJwMrSpy+sMw@mail.gmail.com>

On Mon, Jun 22, 2015 at 11:36 AM, Darren Tucker <dtucker at zip.com.au> wrote:

> On Sun, Jun 21, 2015 at 12:31 AM, Albert S. <mail at quitesimple.org> wrote:
>
>> Fixes a potential (but probably rather unlikely) use after free bug in
>> function temporarily_use_uid(), file uidswap.c.
>>
>
> Does seem unlikely (with zero entries there's no reason for it to deref
> the pointer), however reading the man pages it seems like there's no
> guarantee that it won't, so seems reasonable to me.  Damien?
>

Thanks, this has been committed and will be in the next release.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From jjelen at redhat.com  Tue Jun 23 19:01:54 2015
From: jjelen at redhat.com (Jakub Jelen)
Date: Tue, 23 Jun 2015 11:01:54 +0200
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
Message-ID: <55892082.2030208@redhat.com>


On 05/29/2015 09:12 AM, Damien Miller wrote:
> Hi,
>
> OpenSSH 6.9 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This release contains
> some substantial new features and a number of bugfixes.
Tested basic configuration on Fedora 22. With default configuration I 
ran in few problems:
  ~ root login
     ~ can be there some test if you are running as root and if you are, 
add this configuration option? Or
  ~ warnings about missing moduli
     ~ WARNING: /usr/local/etc/moduli does not exist, using fixed modulus
     ~ the path is compiled in so no way to expect it somewhere else 
than it is configured

Maybe it would be useful to update README.regress with such know issues. 
At least these two issues seems to be pretty common recently.


With normal user, sudo and our configuration all tests went well.

Experimental build without openssl (regardless other config options) 
fails early during linking of test suite:

/home/jjelen/openssh/build/../regress/unittests/sshbuf/test_sshbuf_getput_crypto.c:81: 
undefined reference to `BN_hex2bn'
/home/jjelen/openssh/build/../regress/unittests/sshbuf/test_sshbuf_getput_crypto.c:86: 
undefined reference to `BN_num_bits'
/home/jjelen/openssh/build/../regress/unittests/sshbuf/test_sshbuf_getput_crypto.c:88: 
undefined reference to `BN_free'
[...]
/home/jjelen/openssh/build/../regress/unittests/sshbuf/test_sshbuf_getput_fuzz.c:57: 
undefined reference to `BN_new'
/home/jjelen/openssh/build/../regress/unittests/sshbuf/test_sshbuf_getput_fuzz.c:59: 
undefined reference to `BN_clear_free'
[...]
/home/jjelen/openssh/build/../regress/unittests/test_helper/test_helper.c:254: 
undefined reference to `ERR_get_error'
/home/jjelen/openssh/build/../regress/unittests/test_helper/test_helper.c:259: 
undefined reference to `ERR_error_string'
[...]
/home/jjelen/openssh/build/../sshbuf-getput-crypto.c:43: undefined 
reference to `BN_bin2bn'

I didn't progress any further.

I will try to run more regression tests later this week.

-- 
Jakub Jelen
Red Hat


From pch-openssh at u-1.phicoh.com  Tue Jun 23 23:09:04 2015
From: pch-openssh at u-1.phicoh.com (Philip Homburg)
Date: Tue, 23 Jun 2015 15:09:04 +0200
Subject: Small issue with DNSSEC / SSHFP 
In-Reply-To: Your message of "Mon, 22 Jun 2015 17:24:01 -0700 ."
 <1435019041.5588a721f15357.76125085@www.paypc.com> 
References: <m1Z70jY-0000CVC@stereo.hq.phicoh.net>
 <1435019041.5588a721f15357.76125085@www.paypc.com> 
Message-ID: <m1Z7Nwo-0000DMC@stereo.hq.phicoh.net>

In your letter dated Mon, 22 Jun 2015 17:24:01 -0700 you wrote:
>It's probably of minor importance, since DNS fingerprinting is not the best
>primary mechanism to verify a server's host key fingerprint.

My experience is that my sites do not have any sensible policy of publishing
ssh fingerprints and quite a few admins would quite like to use DNSSEC
validated fingerprints. 



From sfandino at gmail.com  Tue Jun 23 23:42:37 2015
From: sfandino at gmail.com (salvador fandino)
Date: Tue, 23 Jun 2015 15:42:37 +0200
Subject: [PATCH] Allow forwarding of stdio to streamlocal end points
Message-ID: <CAA2CF7WxF15_W-mq=4GT5saTQc=wgCfVKo9OOKchqfRk9fbnyA@mail.gmail.com>

Later versions of OpenSSH allow the user to forward connections also
to/from Unix sockets.

This patch allows to use Unix sockets as the target when forwarding the
local stdio using the -W feature.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Allow-forwarding-of-stdio-to-streamlocal-end-points.patch
Type: application/text
Size: 5796 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150623/590ae16b/attachment.bin>

From djm at mindrot.org  Wed Jun 24 00:57:29 2015
From: djm at mindrot.org (Damien Miller)
Date: Wed, 24 Jun 2015 00:57:29 +1000 (AEST)
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <55892082.2030208@redhat.com>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <55892082.2030208@redhat.com>
Message-ID: <alpine.BSO.2.20.1506240056370.29757@natsu.mindrot.org>

On Tue, 23 Jun 2015, Jakub Jelen wrote:

> 
> On 05/29/2015 09:12 AM, Damien Miller wrote:
> > Hi,
> > 
> > OpenSSH 6.9 is almost ready for release, so we would appreciate testing
> > on as many platforms and systems as possible. This release contains
> > some substantial new features and a number of bugfixes.
> Tested basic configuration on Fedora 22. With default configuration I ran in
> few problems:
>  ~ root login
>     ~ can be there some test if you are running as root and if you are, add
> this configuration option? Or
>  ~ warnings about missing moduli
>     ~ WARNING: /usr/local/etc/moduli does not exist, using fixed modulus
>     ~ the path is compiled in so no way to expect it somewhere else than it is
> configured
> 
> Maybe it would be useful to update README.regress with such know issues. At
> least these two issues seems to be pretty common recently.
> 
> 
> With normal user, sudo and our configuration all tests went well.
> 
> Experimental build without openssl (regardless other config options) fails
> early during linking of test suite:

We've not really tried to make the unit/regress tests work without OpenSSL.
Here's a first attempt at the unit tests:


diff --git a/regress/unittests/bitmap/tests.c b/regress/unittests/bitmap/tests.c
index 23025f9..2271e94 100644
--- a/regress/unittests/bitmap/tests.c
+++ b/regress/unittests/bitmap/tests.c
@@ -27,6 +27,7 @@
 void
 tests(void)
 {
+#ifdef WITH_OPENSSL
 	struct bitmap *b;
 	BIGNUM *bn;
 	size_t len;
@@ -131,5 +132,6 @@ tests(void)
 	bitmap_free(b);
 	BN_free(bn);
 	TEST_DONE();
+#endif /* WITH_OPENSSL */
 }
 
diff --git a/regress/unittests/hostkeys/test_iterate.c b/regress/unittests/hostkeys/test_iterate.c
index 2eaaf06..da0e353 100644
--- a/regress/unittests/hostkeys/test_iterate.c
+++ b/regress/unittests/hostkeys/test_iterate.c
@@ -92,12 +92,22 @@ check(struct hostkey_foreach_line *l, void *_ctx)
 
 #ifndef WITH_SSH1
 	if (parse_key && (expected->l.keytype == KEY_RSA1 ||
-	    expected->no_parse_keytype == KEY_RSA1)) {
+	    expected->no_parse_keytype == KEY_RSA1))  {
 		expected_status = HKF_STATUS_INVALID;
 		expected_keytype = KEY_UNSPEC;
 		parse_key = 0;
 	}
 #endif
+#ifndef WITH_OPENSSL
+	if (expected->l.keytype == KEY_RSA ||
+	    expected->no_parse_keytype == KEY_RSA ||
+	    expected->l.keytype == KEY_DSA ||
+	    expected->no_parse_keytype == KEY_DSA)  {
+		expected_status = HKF_STATUS_INVALID;
+		expected_keytype = KEY_UNSPEC;
+		parse_key = 0;
+	}
+#endif /* WITH_OPENSSL */
 #ifndef OPENSSL_HAS_ECC
 	if (expected->l.keytype == KEY_ECDSA ||
 	    expected->no_parse_keytype == KEY_ECDSA) {
@@ -105,7 +115,7 @@ check(struct hostkey_foreach_line *l, void *_ctx)
 		expected_keytype = KEY_UNSPEC;
 		parse_key = 0;
 	}
-#endif
+#endif /* OPENSSL_HAS_ECC */
 
 	UPDATE_MATCH_STATUS(match_host_p);
 	UPDATE_MATCH_STATUS(match_host_s);
@@ -154,10 +164,15 @@ prepare_expected(struct expected *expected, size_t n)
 		if (expected[i].l.keytype == KEY_RSA1)
 			continue;
 #endif
+#ifndef WITH_OPENSSL
+		if (expected[i].l.keytype == KEY_RSA ||
+		    expected[i].l.keytype == KEY_DSA)
+			continue;
 #ifndef OPENSSL_HAS_ECC
 		if (expected[i].l.keytype == KEY_ECDSA)
 			continue;
-#endif
+#endif /* OPENSSL_HAS_ECC */
+#endif /* WITH_OPENSSL */
 		ASSERT_INT_EQ(sshkey_load_public(
 		    test_data_file(expected[i].key_file), &expected[i].l.key,
 		    NULL), 0);
diff --git a/regress/unittests/kex/test_kex.c b/regress/unittests/kex/test_kex.c
index c61e2bd..cf35f09 100644
--- a/regress/unittests/kex/test_kex.c
+++ b/regress/unittests/kex/test_kex.c
@@ -141,13 +141,16 @@ do_kex_with_key(char *kex, int keytype, int bits)
 	sshbuf_free(state);
 	ASSERT_PTR_NE(server2->kex, NULL);
 	/* XXX we need to set the callbacks */
+#ifdef WITH_OPENSSL
 	server2->kex->kex[KEX_DH_GRP1_SHA1] = kexdh_server;
 	server2->kex->kex[KEX_DH_GRP14_SHA1] = kexdh_server;
 	server2->kex->kex[KEX_DH_GEX_SHA1] = kexgex_server;
 	server2->kex->kex[KEX_DH_GEX_SHA256] = kexgex_server;
 #ifdef OPENSSL_HAS_ECC
 	server2->kex->kex[KEX_ECDH_SHA2] = kexecdh_server;
-#endif
+#endif /* OPENSSL_HAS_ECC */
+#endif /* WITH_OPENSSL */
+
 	server2->kex->kex[KEX_C25519_SHA256] = kexc25519_server;
 	server2->kex->load_host_public_key = server->kex->load_host_public_key;
 	server2->kex->load_host_private_key = server->kex->load_host_private_key;
@@ -173,11 +176,13 @@ do_kex_with_key(char *kex, int keytype, int bits)
 static void
 do_kex(char *kex)
 {
+#ifdef WITH_OPENSSL
 	do_kex_with_key(kex, KEY_RSA, 2048);
 	do_kex_with_key(kex, KEY_DSA, 1024);
 #ifdef OPENSSL_HAS_ECC
 	do_kex_with_key(kex, KEY_ECDSA, 256);
-#endif
+#endif /* OPENSSL_HAS_ECC */
+#endif /* WITH_OPENSSL */
 	do_kex_with_key(kex, KEY_ED25519, 256);
 }
 
@@ -185,13 +190,15 @@ void
 kex_tests(void)
 {
 	do_kex("curve25519-sha256 at libssh.org");
+#ifdef WITH_OPENSSL
 #ifdef OPENSSL_HAS_ECC
 	do_kex("ecdh-sha2-nistp256");
 	do_kex("ecdh-sha2-nistp384");
 	do_kex("ecdh-sha2-nistp521");
-#endif
+#endif /* OPENSSL_HAS_ECC */
 	do_kex("diffie-hellman-group-exchange-sha256");
 	do_kex("diffie-hellman-group-exchange-sha1");
 	do_kex("diffie-hellman-group14-sha1");
 	do_kex("diffie-hellman-group1-sha1");
+#endif /* WITH_OPENSSL */
 }
diff --git a/regress/unittests/sshbuf/test_sshbuf_getput_crypto.c b/regress/unittests/sshbuf/test_sshbuf_getput_crypto.c
index a68e132..0b50bd3 100644
--- a/regress/unittests/sshbuf/test_sshbuf_getput_crypto.c
+++ b/regress/unittests/sshbuf/test_sshbuf_getput_crypto.c
@@ -31,6 +31,7 @@ void sshbuf_getput_crypto_tests(void);
 void
 sshbuf_getput_crypto_tests(void)
 {
+#ifdef WITH_OPENSSL
 	struct sshbuf *p1;
 	BIGNUM *bn, *bn2;
 	/* This one has num_bits != num_bytes * 8 to test bignum1 encoding */
@@ -404,6 +405,7 @@ sshbuf_getput_crypto_tests(void)
 	BN_free(bn);
 	BN_free(bn2);
 	TEST_DONE();
-#endif
+#endif /* defined(OPENSSL_HAS_ECC) && defined(OPENSSL_HAS_NISTP256) */
+#endif /* WITH_OPENSSL */
 }
 
diff --git a/regress/unittests/sshbuf/test_sshbuf_getput_fuzz.c b/regress/unittests/sshbuf/test_sshbuf_getput_fuzz.c
index c6b5c29..ed605ce 100644
--- a/regress/unittests/sshbuf/test_sshbuf_getput_fuzz.c
+++ b/regress/unittests/sshbuf/test_sshbuf_getput_fuzz.c
@@ -32,7 +32,9 @@ static void
 attempt_parse_blob(u_char *blob, size_t len)
 {
 	struct sshbuf *p1;
+#ifdef WITH_OPENSSL
 	BIGNUM *bn;
+#endif
 #if defined(OPENSSL_HAS_ECC) && defined(OPENSSL_HAS_NISTP256)
 	EC_KEY *eck;
 #endif
@@ -54,12 +56,14 @@ attempt_parse_blob(u_char *blob, size_t len)
 		bzero(s, l);
 		free(s);
 	}
+#ifdef WITH_OPENSSL
 	bn = BN_new();
 	sshbuf_get_bignum1(p1, bn);
 	BN_clear_free(bn);
 	bn = BN_new();
 	sshbuf_get_bignum2(p1, bn);
 	BN_clear_free(bn);
+#endif
 #if defined(OPENSSL_HAS_ECC) && defined(OPENSSL_HAS_NISTP256)
 	eck = EC_KEY_new_by_curve_name(NID_X9_62_prime256v1);
 	ASSERT_PTR_NE(eck, NULL);
diff --git a/regress/unittests/sshkey/common.c b/regress/unittests/sshkey/common.c
index b598f05..7deacf9 100644
--- a/regress/unittests/sshkey/common.c
+++ b/regress/unittests/sshkey/common.c
@@ -70,6 +70,7 @@ load_text_file(const char *name)
 	return ret;
 }
 
+#ifdef WITH_OPENSSL
 BIGNUM *
 load_bignum(const char *name)
 {
@@ -81,4 +82,5 @@ load_bignum(const char *name)
 	sshbuf_free(buf);
 	return ret;
 }
+#endif /* WITH_OPENSSL */
 
diff --git a/regress/unittests/sshkey/test_file.c b/regress/unittests/sshkey/test_file.c
index fa95212..452ab6e 100644
--- a/regress/unittests/sshkey/test_file.c
+++ b/regress/unittests/sshkey/test_file.c
@@ -44,8 +44,10 @@ sshkey_file_tests(void)
 {
 	struct sshkey *k1, *k2;
 	struct sshbuf *buf, *pw;
-	BIGNUM *a, *b, *c;
 	char *cp;
+#ifdef WITH_OPENSSL
+	BIGNUM *a, *b, *c;
+#endif
 
 	TEST_START("load passphrase");
 	pw = load_text_file("pw");
@@ -102,6 +104,7 @@ sshkey_file_tests(void)
 	sshkey_free(k1);
 #endif
 
+#ifdef WITH_OPENSSL
 	TEST_START("parse RSA from private");
 	buf = load_file("rsa_1");
 	ASSERT_INT_EQ(sshkey_parse_private_fileblob(buf, "", "rsa_1",
@@ -388,6 +391,7 @@ sshkey_file_tests(void)
 
 	sshkey_free(k1);
 #endif /* OPENSSL_HAS_ECC */
+#endif /* WITH_OPENSSL */
 
 	TEST_START("parse Ed25519 from private");
 	buf = load_file("ed25519_1");
@@ -399,6 +403,7 @@ sshkey_file_tests(void)
 	/* XXX check key contents */
 	TEST_DONE();
 
+#ifdef WITH_OPENSSL /* XXX ed25519_1_pw is encrypted with aes256-cbc */
 	TEST_START("parse Ed25519 from private w/ passphrase");
 	buf = load_file("ed25519_1_pw");
 	ASSERT_INT_EQ(sshkey_parse_private_fileblob(buf,
@@ -408,6 +413,7 @@ sshkey_file_tests(void)
 	ASSERT_INT_EQ(sshkey_equal(k1, k2), 1);
 	sshkey_free(k2);
 	TEST_DONE();
+#endif
 
 	TEST_START("load Ed25519 from public");
 	ASSERT_INT_EQ(sshkey_load_public(test_data_file("ed25519_1.pub"), &k2,
diff --git a/regress/unittests/sshkey/test_fuzz.c b/regress/unittests/sshkey/test_fuzz.c
index 1f08a2e..4fc6584 100644
--- a/regress/unittests/sshkey/test_fuzz.c
+++ b/regress/unittests/sshkey/test_fuzz.c
@@ -150,6 +150,7 @@ sshkey_fuzz_tests(void)
 	TEST_DONE();
 #endif
 
+#ifdef WITH_OPENSSL
 	TEST_START("fuzz RSA private");
 	buf = load_file("rsa_1");
 	fuzz = fuzz_begin(FUZZ_BASE64, sshbuf_mutable_ptr(buf),
@@ -282,7 +283,8 @@ sshkey_fuzz_tests(void)
 	sshbuf_free(fuzzed);
 	fuzz_cleanup(fuzz);
 	TEST_DONE();
-#endif
+#endif /* OPENSSL_HAS_ECC */
+#endif /* WITH_OPENSSL */
 
 	TEST_START("fuzz Ed25519 private");
 	buf = load_file("ed25519_1");
@@ -306,6 +308,7 @@ sshkey_fuzz_tests(void)
 	fuzz_cleanup(fuzz);
 	TEST_DONE();
 
+#ifdef WITH_OPENSSL
 	TEST_START("fuzz RSA public");
 	buf = load_file("rsa_1");
 	ASSERT_INT_EQ(sshkey_parse_private_fileblob(buf, "", "key",
@@ -351,7 +354,8 @@ sshkey_fuzz_tests(void)
 	public_fuzz(k1);
 	sshkey_free(k1);
 	TEST_DONE();
-#endif
+#endif /* OPENSSL_HAS_ECC */
+#endif /* WITH_OPENSSL */
 
 	TEST_START("fuzz Ed25519 public");
 	buf = load_file("ed25519_1");
@@ -368,6 +372,7 @@ sshkey_fuzz_tests(void)
 	sshkey_free(k1);
 	TEST_DONE();
 
+#ifdef WITH_OPENSSL
 	TEST_START("fuzz RSA sig");
 	buf = load_file("rsa_1");
 	ASSERT_INT_EQ(sshkey_parse_private_fileblob(buf, "", "key",
@@ -395,7 +400,8 @@ sshkey_fuzz_tests(void)
 	sig_fuzz(k1);
 	sshkey_free(k1);
 	TEST_DONE();
-#endif
+#endif /* OPENSSL_HAS_ECC */
+#endif /* WITH_OPENSSL */
 
 	TEST_START("fuzz Ed25519 sig");
 	buf = load_file("ed25519_1");
diff --git a/regress/unittests/sshkey/test_sshkey.c b/regress/unittests/sshkey/test_sshkey.c
index 4453a85..d4a3dee 100644
--- a/regress/unittests/sshkey/test_sshkey.c
+++ b/regress/unittests/sshkey/test_sshkey.c
@@ -50,6 +50,7 @@ put_opt(struct sshbuf *b, const char *name, const char *value)
 	sshbuf_free(sect);
 }
 
+#ifdef WITH_OPENSSL
 static void
 build_cert(struct sshbuf *b, const struct sshkey *k, const char *type,
     const struct sshkey *sign_key, const struct sshkey *ca_key)
@@ -109,6 +110,7 @@ build_cert(struct sshbuf *b, const struct sshkey *k, const char *type,
 	sshbuf_free(principals);
 	sshbuf_free(pk);
 }
+#endif /* WITH_OPENSSL */
 
 static void
 signature_test(struct sshkey *k, struct sshkey *bad, const u_char *d, size_t l)
@@ -174,7 +176,10 @@ get_private(const char *n)
 void
 sshkey_tests(void)
 {
-	struct sshkey *k1, *k2, *k3, *k4, *kr, *kd, *kf;
+	struct sshkey *k1, *k2, *k3, *kf;
+#ifdef WITH_OPENSSL
+	struct sshkey *k4, *kr, *kd;
+#endif
 #ifdef OPENSSL_HAS_ECC
 	struct sshkey *ke;
 #endif
@@ -191,6 +196,7 @@ sshkey_tests(void)
 	sshkey_free(k1);
 	TEST_DONE();
 
+#ifdef WITH_OPENSSL
 	TEST_START("new/free KEY_RSA1");
 	k1 = sshkey_new(KEY_RSA1);
 	ASSERT_PTR_NE(k1, NULL);
@@ -227,7 +233,8 @@ sshkey_tests(void)
 	ASSERT_PTR_EQ(k1->ecdsa, NULL);  /* Can't allocate without NID */
 	sshkey_free(k1);
 	TEST_DONE();
-#endif
+#endif /* OPENSSL_HAS_ECC */
+#endif /* WITH_OPENSSL */
 
 	TEST_START("new/free KEY_ED25519");
 	k1 = sshkey_new(KEY_ED25519);
@@ -238,6 +245,7 @@ sshkey_tests(void)
 	sshkey_free(k1);
 	TEST_DONE();
 
+#ifdef WITH_OPENSSL
 	TEST_START("new_private KEY_RSA");
 	k1 = sshkey_new_private(KEY_RSA);
 	ASSERT_PTR_NE(k1, NULL);
@@ -313,7 +321,8 @@ sshkey_tests(void)
 	ASSERT_PTR_NE(EC_KEY_get0_public_key(ke->ecdsa), NULL);
 	ASSERT_PTR_NE(EC_KEY_get0_private_key(ke->ecdsa), NULL);
 	TEST_DONE();
-#endif
+#endif /* OPENSSL_HAS_ECC */
+#endif /* WITH_OPENSSL */
 
 	TEST_START("generate KEY_ED25519");
 	ASSERT_INT_EQ(sshkey_generate(KEY_ED25519, 256, &kf), 0);
@@ -323,6 +332,7 @@ sshkey_tests(void)
 	ASSERT_PTR_NE(kf->ed25519_sk, NULL);
 	TEST_DONE();
 
+#ifdef WITH_OPENSSL
 	TEST_START("demote KEY_RSA");
 	ASSERT_INT_EQ(sshkey_demote(kr, &k1), 0);
 	ASSERT_PTR_NE(k1, NULL);
@@ -370,7 +380,8 @@ sshkey_tests(void)
 	ASSERT_INT_EQ(sshkey_equal(ke, k1), 1);
 	sshkey_free(k1);
 	TEST_DONE();
-#endif
+#endif /* OPENSSL_HAS_ECC */
+#endif /* WITH_OPENSSL */
 
 	TEST_START("demote KEY_ED25519");
 	ASSERT_INT_EQ(sshkey_demote(kf, &k1), 0);
@@ -386,6 +397,7 @@ sshkey_tests(void)
 	sshkey_free(k1);
 	TEST_DONE();
 
+#ifdef WITH_OPENSSL
 	TEST_START("equal mismatched key types");
 	ASSERT_INT_EQ(sshkey_equal(kd, kr), 0);
 #ifdef OPENSSL_HAS_ECC
@@ -412,13 +424,16 @@ sshkey_tests(void)
 	ASSERT_INT_EQ(sshkey_equal(kf, k1), 0);
 	sshkey_free(k1);
 	TEST_DONE();
+#endif /* WITH_OPENSSL */
 
+#ifdef WITH_OPENSSL
 	sshkey_free(kr);
 	sshkey_free(kd);
 #ifdef OPENSSL_HAS_ECC
 	sshkey_free(ke);
 #endif
 	sshkey_free(kf);
+#endif /* WITH_OPENSSL */
 
 	TEST_START("certify key");
 	ASSERT_INT_EQ(sshkey_load_public(test_data_file("ed25519_1.pub"),
@@ -463,6 +478,7 @@ sshkey_tests(void)
 	sshbuf_reset(b);
 	TEST_DONE();
 
+#ifdef WITH_OPENSSL
 	TEST_START("sign and verify RSA");
 	k1 = get_private("rsa_1");
 	ASSERT_INT_EQ(sshkey_load_public(test_data_file("rsa_2.pub"), &k2,
@@ -490,7 +506,8 @@ sshkey_tests(void)
 	sshkey_free(k1);
 	sshkey_free(k2);
 	TEST_DONE();
-#endif
+#endif /* OPENSSL_HAS_ECC */
+#endif /* WITH_OPENSSL */
 
 	TEST_START("sign and verify ED25519");
 	k1 = get_private("ed25519_1");
@@ -501,6 +518,7 @@ sshkey_tests(void)
 	sshkey_free(k2);
 	TEST_DONE();
 
+#ifdef WITH_OPENSSL
 	TEST_START("nested certificate");
 	ASSERT_INT_EQ(sshkey_load_cert(test_data_file("rsa_1"), &k1), 0);
 	ASSERT_INT_EQ(sshkey_load_public(test_data_file("rsa_1.pub"), &k2,
@@ -515,5 +533,5 @@ sshkey_tests(void)
 	sshkey_free(k3);
 	sshbuf_free(b);
 	TEST_DONE();
-
+#endif /* WITH_OPENSSL */
 }
diff --git a/regress/unittests/sshkey/tests.c b/regress/unittests/sshkey/tests.c
index 13f265c..b1baf12 100644
--- a/regress/unittests/sshkey/tests.c
+++ b/regress/unittests/sshkey/tests.c
@@ -18,8 +18,10 @@ void sshkey_fuzz_tests(void);
 void
 tests(void)
 {
+#ifdef WITH_OPENSSL
 	OpenSSL_add_all_algorithms();
 	ERR_load_CRYPTO_strings();
+#endif
 
 	sshkey_tests();
 	sshkey_file_tests();
diff --git a/regress/unittests/test_helper/test_helper.c b/regress/unittests/test_helper/test_helper.c
index 26ca26b..8bd9e0f 100644
--- a/regress/unittests/test_helper/test_helper.c
+++ b/regress/unittests/test_helper/test_helper.c
@@ -248,6 +248,7 @@ test_subtest_info(const char *fmt, ...)
 	va_end(ap);
 }
 
+#ifdef WITH_OPENSSL
 void
 ssl_err_check(const char *file, int line)
 {
@@ -260,6 +261,7 @@ ssl_err_check(const char *file, int line)
 	    file, line, ERR_error_string(openssl_error, NULL));
 	abort();
 }
+#endif
 
 static const char *
 pred_name(enum test_predicate p)
@@ -302,6 +304,7 @@ test_header(const char *file, int line, const char *a1, const char *a2,
 	    a2 != NULL ? ", " : "", a2 != NULL ? a2 : "");
 }
 
+#ifdef WITH_OPENSSL
 void
 assert_bignum(const char *file, int line, const char *a1, const char *a2,
     const BIGNUM *aa1, const BIGNUM *aa2, enum test_predicate pred)
@@ -314,6 +317,7 @@ assert_bignum(const char *file, int line, const char *a1, const char *a2,
 	fprintf(stderr, "%12s = 0x%s\n", a2, BN_bn2hex(aa2));
 	test_die();
 }
+#endif
 
 void
 assert_string(const char *file, int line, const char *a1, const char *a2,

From djm at mindrot.org  Wed Jun 24 10:15:02 2015
From: djm at mindrot.org (Damien Miller)
Date: Wed, 24 Jun 2015 10:15:02 +1000 (AEST)
Subject: [PATCH] Allow forwarding of stdio to streamlocal end points
In-Reply-To: <CAA2CF7WxF15_W-mq=4GT5saTQc=wgCfVKo9OOKchqfRk9fbnyA@mail.gmail.com>
References: <CAA2CF7WxF15_W-mq=4GT5saTQc=wgCfVKo9OOKchqfRk9fbnyA@mail.gmail.com>
Message-ID: <alpine.BSO.2.20.1506241014310.6794@natsu.mindrot.org>

oh, nice! Could you please create a feature request at
https://bugzilla.mindrot.org/ and attach the patch?

Thanks,
Damien

On Tue, 23 Jun 2015, salvador fandino wrote:

> Later versions of OpenSSH allow the user to forward connections also
> to/from Unix sockets.
> 
> This patch allows to use Unix sockets as the target when forwarding the
> local stdio using the -W feature.
> 

From jjelen at redhat.com  Wed Jun 24 17:15:17 2015
From: jjelen at redhat.com (Jakub Jelen)
Date: Wed, 24 Jun 2015 09:15:17 +0200
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <alpine.BSO.2.20.1506240056370.29757@natsu.mindrot.org>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <55892082.2030208@redhat.com>
 <alpine.BSO.2.20.1506240056370.29757@natsu.mindrot.org>
Message-ID: <558A5905.7070702@redhat.com>


On 06/23/2015 04:57 PM, Damien Miller wrote:
> On Tue, 23 Jun 2015, Jakub Jelen wrote:
>
>> On 05/29/2015 09:12 AM, Damien Miller wrote:
>>> Hi,
>>>
>>> OpenSSH 6.9 is almost ready for release, so we would appreciate testing
>>> on as many platforms and systems as possible. This release contains
>>> some substantial new features and a number of bugfixes.
>> Tested basic configuration on Fedora 22. With default configuration I ran in
>> few problems:
>>   ~ root login
>>      ~ can be there some test if you are running as root and if you are, add
>> this configuration option? Or
>>   ~ warnings about missing moduli
>>      ~ WARNING: /usr/local/etc/moduli does not exist, using fixed modulus
>>      ~ the path is compiled in so no way to expect it somewhere else than it is
>> configured
>>
>> Maybe it would be useful to update README.regress with such know issues. At
>> least these two issues seems to be pretty common recently.
>>
>>
>> With normal user, sudo and our configuration all tests went well.
>>
>> Experimental build without openssl (regardless other config options) fails
>> early during linking of test suite:
> We've not really tried to make the unit/regress tests work without OpenSSL.
> Here's a first attempt at the unit tests:
>
Thanks for update. It helped to compile on my system. As I noticed now, 
import/export of keys in ssh-keygen is not supported without openssl 
(according to code), so there are still some things to fix in bash test 
suite. Basically all test cases t1 to t12 are failing. Mostly because of 
the import/export or the key type is unknown.
If I skipped these, whole test suite widely depend on generated rsa keys 
and without major changes in bash test suite I am unable to continue any 
further. This would require some more care.

-- 
Jakub Jelen
Red Hat


From sfandino at gmail.com  Wed Jun 24 18:14:18 2015
From: sfandino at gmail.com (Salvador Fandino)
Date: Wed, 24 Jun 2015 10:14:18 +0200
Subject: [PATCH] Allow forwarding of stdio to streamlocal end points
In-Reply-To: <alpine.BSO.2.20.1506241014310.6794@natsu.mindrot.org>
References: <CAA2CF7WxF15_W-mq=4GT5saTQc=wgCfVKo9OOKchqfRk9fbnyA@mail.gmail.com>
 <alpine.BSO.2.20.1506241014310.6794@natsu.mindrot.org>
Message-ID: <mmdosq$54h$1@ger.gmane.org>

On 06/24/2015 02:15 AM, Damien Miller wrote:
> oh, nice! Could you please create a feature request at
> https://bugzilla.mindrot.org/ and attach the patch?

Done! #2416

https://bugzilla.mindrot.org/show_bug.cgi?id=2416




From djm at mindrot.org  Wed Jun 24 18:45:49 2015
From: djm at mindrot.org (Damien Miller)
Date: Wed, 24 Jun 2015 18:45:49 +1000 (AEST)
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <558A5905.7070702@redhat.com>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <55892082.2030208@redhat.com>
 <alpine.BSO.2.20.1506240056370.29757@natsu.mindrot.org>
 <558A5905.7070702@redhat.com>
Message-ID: <alpine.BSO.2.20.1506241845110.24182@natsu.mindrot.org>

On Wed, 24 Jun 2015, Jakub Jelen wrote:

> Thanks for update. It helped to compile on my system. As I noticed now,
> import/export of keys in ssh-keygen is not supported without openssl
> (according to code), so there are still some things to fix in bash test suite.
> Basically all test cases t1 to t12 are failing. Mostly because of the
> import/export or the key type is unknown.
> If I skipped these, whole test suite widely depend on generated rsa keys and
> without major changes in bash test suite I am unable to continue any further.
> This would require some more care.

Yeah, there's quite a bit more to do - liberal checks of 
`ssh -Q protocol-version` are required...

-d

From ag4ve.us at gmail.com  Thu Jun 25 11:15:17 2015
From: ag4ve.us at gmail.com (shawn wilson)
Date: Wed, 24 Jun 2015 21:15:17 -0400
Subject: feature: deprecate dsa
Message-ID: <CAH_OBifS7cKenOmr9p=w-7V5g79Of6QqKCC9=aRVnfzJ-BokDw@mail.gmail.com>

Can we make the server stop creating ssh_host_dsa pairs (use them w/
another log line if they are manually created).

It would also be nice to add a big note at the top of the ssh-keygen
documentation about dsa being weak and that you shouldn't use it (if
you have a device that can only use dsa, you'll obviously ignore the
warning but it'd be good to say as strongly as possible).

From djm at mindrot.org  Thu Jun 25 11:40:59 2015
From: djm at mindrot.org (Damien Miller)
Date: Thu, 25 Jun 2015 11:40:59 +1000 (AEST)
Subject: feature: deprecate dsa
In-Reply-To: <CAH_OBifS7cKenOmr9p=w-7V5g79Of6QqKCC9=aRVnfzJ-BokDw@mail.gmail.com>
References: <CAH_OBifS7cKenOmr9p=w-7V5g79Of6QqKCC9=aRVnfzJ-BokDw@mail.gmail.com>
Message-ID: <alpine.BSO.2.20.1506251140530.26784@natsu.mindrot.org>

yes, stay tuned

On Wed, 24 Jun 2015, shawn wilson wrote:

> Can we make the server stop creating ssh_host_dsa pairs (use them w/
> another log line if they are manually created).
> 
> It would also be nice to add a big note at the top of the ssh-keygen
> documentation about dsa being weak and that you shouldn't use it (if
> you have a device that can only use dsa, you'll obviously ignore the
> warning but it'd be good to say as strongly as possible).
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

From tgc at jupiterrise.com  Thu Jun 25 16:04:08 2015
From: tgc at jupiterrise.com (Tom G. Christensen)
Date: Thu, 25 Jun 2015 08:04:08 +0200
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <556CBDDE.4080303@jupiterrise.com>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <556CBDDE.4080303@jupiterrise.com>
Message-ID: <558B99D8.7080204@jupiterrise.com>

On 01/06/15 22:17, Tom G. Christensen wrote:
> On sparc-sun-solaris2.6 and sparc-sun-solaris2.7 the testsuite fails:
> run test cfgparse.sh ...
> reparse minimal config
> reparse regress config
> listenaddress order
> bad addr or host: ::1 (no address associated with name)
> listenaddress order 1
> bad addr or host: ::1 (no address associated with name)
> listenaddress order 2
> failed config parse
> gmake[1]: *** [t-exec] Error 1
>

I just re-tested on Solaris 2.6 with 9488538a from git and this is still 
an issue.
Removing the ipv6 addresses from cfgparse.sh allows the testsuite to run 
to completion.

-tgc

From somenxavier at gmail.com  Thu Jun 25 18:01:42 2015
From: somenxavier at gmail.com (Xavier)
Date: Thu, 25 Jun 2015 10:01:42 +0200
Subject: More elliptic curves option
Message-ID: <20150625100142.4f64704401ba8cad1ec2e3ca@gmail.com>

Hi,

I want to use elliptic curve cryptography in openssh. But I think that you have not enough and diverse type of curves [http://safecurves.cr.yp.to/rigid.html]. Can you implement some other types of curves like  brainpool type or even strongest types. For obvious reasons I think we can't trust NIST.

Thanks,
Xavier

From sfandino at gmail.com  Thu Jun 25 20:28:46 2015
From: sfandino at gmail.com (Salvador Fandino)
Date: Thu, 25 Jun 2015 12:28:46 +0200
Subject: [PATCH] Fix buffer overrun
Message-ID: <mmgl4u$ojq$1@ger.gmane.org>

When a forwarding specification ending in a slash ('\\') is used,
the function "parse_fwd_field" jumps over the '\0' char marking
the end of the string and keeps processing.

This patch checks for that condition.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-buffer-overrun.patch
Type: application/text
Size: 850 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150625/b3ac0f28/attachment.bin>

From sfandino at gmail.com  Thu Jun 25 22:18:42 2015
From: sfandino at gmail.com (Salvador Fandino)
Date: Thu, 25 Jun 2015 14:18:42 +0200
Subject: [PATCH] Fix buffer overrun
In-Reply-To: <mmgl4u$ojq$1@ger.gmane.org>
References: <mmgl4u$ojq$1@ger.gmane.org>
Message-ID: <mmgrj2$4bd$1@ger.gmane.org>

On 06/25/2015 12:28 PM, Salvador Fandino wrote:
> When a forwarding specification ending in a slash ('\\') is used,
> the function "parse_fwd_field" jumps over the '\0' char marking
> the end of the string and keeps processing.
>
> This patch checks for that condition.
>
>
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

Wait, this is still broken!

For instance,

   ssh -R/tmp/foo\\1\\2:localhost:11111 localhost

... parses as /tmp/foo1\2

A new patch is coming soon.


From sfandino at gmail.com  Thu Jun 25 22:32:30 2015
From: sfandino at gmail.com (Salvador Fandino)
Date: Thu, 25 Jun 2015 14:32:30 +0200
Subject: [PATCH] Fix buffer overrun
In-Reply-To: <mmgl4u$ojq$1@ger.gmane.org>
References: <mmgl4u$ojq$1@ger.gmane.org>
Message-ID: <mmgscv$icn$1@ger.gmane.org>

And now the proper fix (hopefully)!


-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Fix-buffer-overrun.patch
Type: application/text
Size: 943 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150625/c300be41/attachment.bin>

From aixtools at gmail.com  Thu Jun 25 23:24:58 2015
From: aixtools at gmail.com (Michael Felt)
Date: Thu, 25 Jun 2015 15:24:58 +0200
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <558B99D8.7080204@jupiterrise.com>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <556CBDDE.4080303@jupiterrise.com>
 <558B99D8.7080204@jupiterrise.com>
Message-ID: <CANvxniUgT8GepV=Ec3dn43gCH8-pAnggAAdkAc=14s3c_-gpcA@mail.gmail.com>

Just running a standard make, and then a make install to a packaging
directory. It seems to be complaining about missing keys - not sure yet if
this is a show stopper

Further, some compiler warning messages (some may be ignored completely,
others may be interesting)...

xlc is /usr/vacpp/bin/xlc
+ CPPFLAGS="-I/opt/buildaix/include -I/opt/include" CFLAGS="-I/opt/include
-I/opt/buildaix/include -O2" ./configure \
                --prefix=/opt  \
                --sysconfdir=/var/openssh/etc \
                --sharedstatedir=/var/openssh/com \
                --localstatedir=/var/openssh \
                --mandir=/usr/share/man \
                --infodir=/opt/share/info/openssh  \
                        > .buildaix/configure.out
configure: WARNING: Please check and edit blibpath in LDFLAGS in Makefile
+ /opt/bin/make > .buildaix/make.out
"bsd-cray.c", line 817.23: 1506-356 (W) Compilation unit is empty.
"kludge-fd_set.c", line 28.1: 1506-356 (W) Compilation unit is empty.
"glob.c", line 93.9: 1506-236 (W) Macro name TILDE has been redefined.
"glob.c", line 93.9: 1506-358 (I) "TILDE" is defined on line 250 of
/usr/include/sys/ioctl.h.
"strnlen.c", line 37.7: 1506-356 (W) Compilation unit is empty.
"/usr/include/syms.h", line 288.9: 1506-236 (W) Macro name T_NULL has been
redefined.
"/usr/include/syms.h", line 288.9: 1506-358 (I) "T_NULL" is defined on line
150 of /usr/include/arpa/onameser_compat.h.
ar: Creating an archive file libopenbsd-compat.a.
"ssh-pkcs11.c", line 578.30: 1506-068 (W) Operation between types "unsigned
long(*)(struct _CK_FUNCTION_LIST**)" and "void*" is not allowed.
ar: Creating an archive file libssh.a.
    1500-030: (I) INFORMATION: main: Additional optimization may be
attained by recompiling and specifying MAXMEM option with a value greater
than 8192.
    1500-030: (I) INFORMATION: process_config_line: Additional optimization
may be attained by recompiling and specifying MAXMEM option with a value
greater than 8192.
    1500-030: (I) INFORMATION: main: Additional optimization may be
attained by recompiling and specifying MAXMEM option with a value greater
than 8192.
"auth-rsa.c", line 220.44: 1506-280 (W) Function argument assignment
between types "unsigned int*" and "int*" is not allowed.
"platform.c", line 195.44: 1506-280 (W) Function argument assignment
between types "char*" and "const char*" is not allowed.
    1500-030: (I) INFORMATION: process_server_config_line: Additional
optimization may be attained by recompiling and specifying MAXMEM option
with a value greater than 8192.
"monitor.c", line 702.36: 1506-280 (W) Function argument assignment between
types "unsigned int*" and "int*" is not allowed.
     470  1500-010: (W) WARNING in monitor_child_postauth: Infinite loop.
Program may not stop.
    1640  1500-010: (W) WARNING in sftp_server_main: Infinite loop.
Program may not stop.
     307  1500-010: (W) WARNING in main: Infinite loop.  Program may not
stop.
    1408  1500-010: (W) WARNING in main: Infinite loop.  Program may not
stop.
+ /opt/bin/make install DESTDIR=/var/aixtools/snap/openssh/1.0.0.0 >
.buildaix/install.out
Could not load host key: /var/openssh/etc/ssh_host_rsa_key
Could not load host key: /var/openssh/etc/ssh_host_dsa_key
Could not load host key: /var/openssh/etc/ssh_host_ed25519_key
Disabling protocol version 2. Could not load host key
sshd: no hostkeys available -- exiting.
make: [check-config] Error 1 (ignored)

p.s. will test soon with compiling against LibreSSL.

On Thu, Jun 25, 2015 at 8:04 AM, Tom G. Christensen <tgc at jupiterrise.com>
wrote:

> On 01/06/15 22:17, Tom G. Christensen wrote:
>
>> On sparc-sun-solaris2.6 and sparc-sun-solaris2.7 the testsuite fails:
>> run test cfgparse.sh ...
>> reparse minimal config
>> reparse regress config
>> listenaddress order
>> bad addr or host: ::1 (no address associated with name)
>> listenaddress order 1
>> bad addr or host: ::1 (no address associated with name)
>> listenaddress order 2
>> failed config parse
>> gmake[1]: *** [t-exec] Error 1
>>
>>
> I just re-tested on Solaris 2.6 with 9488538a from git and this is still
> an issue.
> Removing the ipv6 addresses from cfgparse.sh allows the testsuite to run
> to completion.
>
>
> -tgc
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

From aixtools at gmail.com  Fri Jun 26 00:23:49 2015
From: aixtools at gmail.com (Michael Felt)
Date: Thu, 25 Jun 2015 16:23:49 +0200
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <CANvxniUgT8GepV=Ec3dn43gCH8-pAnggAAdkAc=14s3c_-gpcA@mail.gmail.com>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <556CBDDE.4080303@jupiterrise.com>
 <558B99D8.7080204@jupiterrise.com>
 <CANvxniUgT8GepV=Ec3dn43gCH8-pAnggAAdkAc=14s3c_-gpcA@mail.gmail.com>
Message-ID: <CANvxniVA8iW32NojgiB34QLoRZY=PtgfZ5aRF-ywj35qxO8tkQ@mail.gmail.com>

Oh yes, ran into this again - running tests as root.

run test connect.sh ...
ssh connect with protocol 1 failed
ssh connect with protocol 2 failed
failed simple connect

After su to non-root...

skipped (SUDO not set)
need SUDO to create file in /var/run, test won't work without
make[1]: Leaving directory `/data/prj/openbsd/openssh/snap/openssh/regress'
all tests passed


On Thu, Jun 25, 2015 at 3:24 PM, Michael Felt <aixtools at gmail.com> wrote:

> Just running a standard make, and then a make install to a packaging
> directory. It seems to be complaining about missing keys - not sure yet if
> this is a show stopper
>
> Further, some compiler warning messages (some may be ignored completely,
> others may be interesting)...
>
> xlc is /usr/vacpp/bin/xlc
> + CPPFLAGS="-I/opt/buildaix/include -I/opt/include" CFLAGS="-I/opt/include
> -I/opt/buildaix/include -O2" ./configure \
>                 --prefix=/opt  \
>                 --sysconfdir=/var/openssh/etc \
>                 --sharedstatedir=/var/openssh/com \
>                 --localstatedir=/var/openssh \
>                 --mandir=/usr/share/man \
>                 --infodir=/opt/share/info/openssh  \
>                         > .buildaix/configure.out
> configure: WARNING: Please check and edit blibpath in LDFLAGS in Makefile
> + /opt/bin/make > .buildaix/make.out
> "bsd-cray.c", line 817.23: 1506-356 (W) Compilation unit is empty.
> "kludge-fd_set.c", line 28.1: 1506-356 (W) Compilation unit is empty.
> "glob.c", line 93.9: 1506-236 (W) Macro name TILDE has been redefined.
> "glob.c", line 93.9: 1506-358 (I) "TILDE" is defined on line 250 of
> /usr/include/sys/ioctl.h.
> "strnlen.c", line 37.7: 1506-356 (W) Compilation unit is empty.
> "/usr/include/syms.h", line 288.9: 1506-236 (W) Macro name T_NULL has been
> redefined.
> "/usr/include/syms.h", line 288.9: 1506-358 (I) "T_NULL" is defined on
> line 150 of /usr/include/arpa/onameser_compat.h.
> ar: Creating an archive file libopenbsd-compat.a.
> "ssh-pkcs11.c", line 578.30: 1506-068 (W) Operation between types
> "unsigned long(*)(struct _CK_FUNCTION_LIST**)" and "void*" is not allowed.
> ar: Creating an archive file libssh.a.
>     1500-030: (I) INFORMATION: main: Additional optimization may be
> attained by recompiling and specifying MAXMEM option with a value greater
> than 8192.
>     1500-030: (I) INFORMATION: process_config_line: Additional
> optimization may be attained by recompiling and specifying MAXMEM option
> with a value greater than 8192.
>     1500-030: (I) INFORMATION: main: Additional optimization may be
> attained by recompiling and specifying MAXMEM option with a value greater
> than 8192.
> "auth-rsa.c", line 220.44: 1506-280 (W) Function argument assignment
> between types "unsigned int*" and "int*" is not allowed.
> "platform.c", line 195.44: 1506-280 (W) Function argument assignment
> between types "char*" and "const char*" is not allowed.
>     1500-030: (I) INFORMATION: process_server_config_line: Additional
> optimization may be attained by recompiling and specifying MAXMEM option
> with a value greater than 8192.
> "monitor.c", line 702.36: 1506-280 (W) Function argument assignment
> between types "unsigned int*" and "int*" is not allowed.
>      470  1500-010: (W) WARNING in monitor_child_postauth: Infinite loop.
> Program may not stop.
>     1640  1500-010: (W) WARNING in sftp_server_main: Infinite loop.
> Program may not stop.
>      307  1500-010: (W) WARNING in main: Infinite loop.  Program may not
> stop.
>     1408  1500-010: (W) WARNING in main: Infinite loop.  Program may not
> stop.
> + /opt/bin/make install DESTDIR=/var/aixtools/snap/openssh/1.0.0.0 >
> .buildaix/install.out
> Could not load host key: /var/openssh/etc/ssh_host_rsa_key
> Could not load host key: /var/openssh/etc/ssh_host_dsa_key
> Could not load host key: /var/openssh/etc/ssh_host_ed25519_key
> Disabling protocol version 2. Could not load host key
> sshd: no hostkeys available -- exiting.
> make: [check-config] Error 1 (ignored)
>
> p.s. will test soon with compiling against LibreSSL.
>
> On Thu, Jun 25, 2015 at 8:04 AM, Tom G. Christensen <tgc at jupiterrise.com>
> wrote:
>
>> On 01/06/15 22:17, Tom G. Christensen wrote:
>>
>>> On sparc-sun-solaris2.6 and sparc-sun-solaris2.7 the testsuite fails:
>>> run test cfgparse.sh ...
>>> reparse minimal config
>>> reparse regress config
>>> listenaddress order
>>> bad addr or host: ::1 (no address associated with name)
>>> listenaddress order 1
>>> bad addr or host: ::1 (no address associated with name)
>>> listenaddress order 2
>>> failed config parse
>>> gmake[1]: *** [t-exec] Error 1
>>>
>>>
>> I just re-tested on Solaris 2.6 with 9488538a from git and this is still
>> an issue.
>> Removing the ipv6 addresses from cfgparse.sh allows the testsuite to run
>> to completion.
>>
>>
>> -tgc
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>
>
>

From tim at multitalents.net  Fri Jun 26 01:18:13 2015
From: tim at multitalents.net (Tim Rice)
Date: Thu, 25 Jun 2015 08:18:13 -0700 (PDT)
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <CANvxniUgT8GepV=Ec3dn43gCH8-pAnggAAdkAc=14s3c_-gpcA@mail.gmail.com>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <556CBDDE.4080303@jupiterrise.com> <558B99D8.7080204@jupiterrise.com>
 <CANvxniUgT8GepV=Ec3dn43gCH8-pAnggAAdkAc=14s3c_-gpcA@mail.gmail.com>
Message-ID: <alpine.UW2.2.11.1506250816300.18080@server01.int.multitalents.net>

On Thu, 25 Jun 2015, Michael Felt wrote:

> Just running a standard make, and then a make install to a packaging
> directory. It seems to be complaining about missing keys - not sure yet if
> this is a show stopper

For packaging you want the install-nokeys rule not install.

-- 
Tim Rice				Multitalents
tim at multitalents.net



From aixtools at gmail.com  Fri Jun 26 01:58:52 2015
From: aixtools at gmail.com (Michael Felt)
Date: Thu, 25 Jun 2015 17:58:52 +0200
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <alpine.UW2.2.11.1506250816300.18080@server01.int.multitalents.net>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <556CBDDE.4080303@jupiterrise.com>
 <558B99D8.7080204@jupiterrise.com>
 <CANvxniUgT8GepV=Ec3dn43gCH8-pAnggAAdkAc=14s3c_-gpcA@mail.gmail.com>
 <alpine.UW2.2.11.1506250816300.18080@server01.int.multitalents.net>
Message-ID: <CANvxniURtMyQVtGzGWcB0Ka+u8hSJsxcZ79QZxbat+uaVzzyfw@mail.gmail.com>

Ah - thanks Tim!


Now for the report on AIX and --without-openssl (something I am looking
forward to!)

Basically, it seems to build and "install" (see above), but make tests
fails due to, guessing, lack of openssl.

root at x064:[/data/prj/openbsd/openssh/snap/openssh]buildaix
--without-openssl
xlc is /usr/vacpp/bin/xlc
+ CPPFLAGS="-I/opt/buildaix/include -I/opt/include" CFLAGS="-I/opt/include
-I/opt/buildaix/include -O2" ./configure \
                --prefix=/opt  \
                --sysconfdir=/var/openssh/etc \
                --sharedstatedir=/var/openssh/com \
                --localstatedir=/var/openssh \
                --mandir=/usr/share/man \
                --infodir=/opt/share/info/openssh --without-openssl \
                        > .buildaix/configure.out
configure: WARNING: OpenSSH will use /dev/urandom as a source of random
numbers. It will fail if this device is not supported or accessible
configure: WARNING: ** Cannot find lastlog **
configure: WARNING: Please check and edit blibpath in LDFLAGS in Makefile
+ /opt/bin/make > .buildaix/make.out
"bsd-cray.c", line 817.23: 1506-356 (W) Compilation unit is empty.
"kludge-fd_set.c", line 28.1: 1506-356 (W) Compilation unit is empty.
"glob.c", line 93.9: 1506-236 (W) Macro name TILDE has been redefined.
"glob.c", line 93.9: 1506-358 (I) "TILDE" is defined on line 250 of
/usr/include/sys/ioctl.h.
"sha2.c", line 867.32: 1506-1332 (W) A function with return type "void" may
not return a value of type "void".
"strnlen.c", line 37.7: 1506-356 (W) Compilation unit is empty.
"/usr/include/syms.h", line 288.9: 1506-236 (W) Macro name T_NULL has been
redefined.
"/usr/include/syms.h", line 288.9: 1506-358 (I) "T_NULL" is defined on line
150 of /usr/include/arpa/onameser_compat.h.
ar: Creating an archive file libopenbsd-compat.a.
ar: Creating an archive file libssh.a.
    1500-030: (I) INFORMATION: main: Additional optimization may be
attained by recompiling and specifying MAXMEM option with a value greater
than 8192.
    1500-030: (I) INFORMATION: process_config_line: Additional optimization
may be attained by recompiling and specifying MAXMEM option with a value
greater than 8192.
    1500-030: (I) INFORMATION: main: Additional optimization may be
attained by recompiling and specifying MAXMEM option with a value greater
than 8192.
"platform.c", line 195.44: 1506-280 (W) Function argument assignment
between types "char*" and "const char*" is not allowed.
    1500-030: (I) INFORMATION: process_server_config_line: Additional
optimization may be attained by recompiling and specifying MAXMEM option
with a value greater than 8192.
"monitor.c", line 702.36: 1506-280 (W) Function argument assignment between
types "unsigned int*" and "int*" is not allowed.
     470  1500-010: (W) WARNING in monitor_child_postauth: Infinite loop.
Program may not stop.
    1640  1500-010: (W) WARNING in sftp_server_main: Infinite loop.
Program may not stop.
    1408  1500-010: (W) WARNING in main: Infinite loop.  Program may not
stop.

+ /opt/bin/make install DESTDIR=/var/aixtools/snap/openssh/6.9.0.176 >
.buildaix/install.out
key_load_private: invalid format
key_load_public: invalid format
Could not load host key: /var/openssh/etc/ssh_host_rsa_key
key_load_private: invalid format
key_load_public: invalid format
Could not load host key: /var/openssh/etc/ssh_host_dsa_key
+ mkinstallp.ksh /var/aixtools/snap/openssh/6.9.0.176 >
.buildaix/mkinstallp.out
readline() on closed filehandle RAL at /usr/sbin/makebff.pl line 276.
==============================
aixtools.snap.openssh:aixtools.snap.openssh.man.en_US:6.9.0.176::I:T:::::N:man
pages::::0::
aixtools.snap.openssh:aixtools.snap.openssh.rte:6.9.0.176::I:T:::::N:1525
0625 1433::::0::
==============================
root at x064:[/data/prj/openbsd/openssh/snap/openssh]
root at x064:[/data/prj/openbsd/openssh/snap/openssh]id
uid=199(michael) gid=1(staff) groups=1(staff)

And the the tests that do not get started because they are not ready to be
--without-openssl it seems.

root at x064:[/data/prj/openbsd/openssh/snap/openssh]make tests
[ -d `pwd`/regress ] || mkdir -p `pwd`/regress
[ -d `pwd`/regress/unittests ] || mkdir -p `pwd`/regress/unittests
[ -d `pwd`/regress/unittests/test_helper ] || \
        mkdir -p `pwd`/regress/unittests/test_helper
[ -d `pwd`/regress/unittests/sshbuf ] || \
        mkdir -p `pwd`/regress/unittests/sshbuf
[ -d `pwd`/regress/unittests/sshkey ] || \
        mkdir -p `pwd`/regress/unittests/sshkey
[ -d `pwd`/regress/unittests/bitmap ] || \
        mkdir -p `pwd`/regress/unittests/bitmap
[ -d `pwd`/regress/unittests/hostkeys ] || \
        mkdir -p `pwd`/regress/unittests/hostkeys
[ -d `pwd`/regress/unittests/kex ] || \
        mkdir -p `pwd`/regress/unittests/kex
[ -f `pwd`/regress/Makefile ] || \
    ln -s `cd . && pwd`/regress/Makefile `pwd`/regress/Makefile
(cd openbsd-compat && make)
make[1]: Entering directory
`/data/prj/openbsd/openssh/snap/openssh/openbsd-compat'
make[1]: Nothing to be done for `all'.
make[1]: Leaving directory
`/data/prj/openbsd/openssh/snap/openssh/openbsd-compat'
xlc -I/opt/include -I/opt/buildaix/include -O2  -I. -I.
-I/opt/buildaix/include -I/opt/include -DSSHDIR=\"/var/openssh/etc\"
-D_PATH_SSH_PROGRAM=\"/opt/bin/ssh\"
-D_PATH_SSH_ASKPASS_DEFAULT=\"/opt/libexec/ssh-askpass\"
-D_PATH_SFTP_SERVER=\"/opt/libexec/sftp-server\"
-D_PATH_SSH_KEY_SIGN=\"/opt/libexec/ssh-keysign\"
-D_PATH_SSH_PKCS11_HELPER=\"/opt/libexec/ssh-pkcs11-helper\"
-D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\"
-DHAVE_CONFIG_H -o regress/modpipe regress/modpipe.c \
-L. -Lopenbsd-compat/  -blibpath:/usr/lib:/lib -lssh -lopenbsd-compat -lssh
-lopenbsd-compat -lz  -lcrypt
...
ar rv regress/unittests/test_helper/libtest_helper.a
regress/unittests/test_helper/test_helper.o
regress/unittests/test_helper/fuzz.o
ar: Creating an archive file regress/unittests/test_helper/libtest_helper.a.
a - regress/unittests/test_helper/test_helper.o
a - regress/unittests/test_helper/fuzz.o
ranlib regress/unittests/test_helper/libtest_helper.a
xlc -o regress/unittests/sshbuf/test_sshbuf -L. -Lopenbsd-compat/
-blibpath:/usr/lib:/lib regress/unittests/sshbuf/tests.o
regress/unittests/sshbuf/test_sshbuf.o
regress/unittests/sshbuf/test_sshbuf_getput_basic.o
regress/unittests/sshbuf/test_sshbuf_getput_crypto.o
regress/unittests/sshbuf/test_sshbuf_misc.o
regress/unittests/sshbuf/test_sshbuf_fuzz.o
regress/unittests/sshbuf/test_sshbuf_getput_fuzz.o
regress/unittests/sshbuf/test_sshbuf_fixed.o \
    regress/unittests/test_helper/libtest_helper.a \
    -lssh -lopenbsd-compat -lssh -lopenbsd-compat -lz  -lcrypt
ld: 0711-317 ERROR: Undefined symbol: .BN_hex2bn
ld: 0711-317 ERROR: Undefined symbol: .BN_num_bits
ld: 0711-317 ERROR: Undefined symbol: .BN_bn2bin
ld: 0711-317 ERROR: Undefined symbol: .BN_bin2bn
ld: 0711-317 ERROR: Undefined symbol: .BN_free
ld: 0711-317 ERROR: Undefined symbol: .BN_new
ld: 0711-317 ERROR: Undefined symbol: .BN_clear_free
ld: 0711-317 ERROR: Undefined symbol: .BN_cmp
ld: 0711-317 ERROR: Undefined symbol: .BN_bn2hex
ld: 0711-317 ERROR: Undefined symbol: .ERR_get_error
ld: 0711-317 ERROR: Undefined symbol: .ERR_error_string
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
information.



On Thu, Jun 25, 2015 at 5:18 PM, Tim Rice <tim at multitalents.net> wrote:

> On Thu, 25 Jun 2015, Michael Felt wrote:
>
> > Just running a standard make, and then a make install to a packaging
> > directory. It seems to be complaining about missing keys - not sure yet
> if
> > this is a show stopper
>
> For packaging you want the install-nokeys rule not install.
>
> --
> Tim Rice                                Multitalents
> tim at multitalents.net
>
>
>

From aixtools at gmail.com  Fri Jun 26 02:23:25 2015
From: aixtools at gmail.com (Michael Felt)
Date: Thu, 25 Jun 2015 18:23:25 +0200
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <CANvxniURtMyQVtGzGWcB0Ka+u8hSJsxcZ79QZxbat+uaVzzyfw@mail.gmail.com>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <556CBDDE.4080303@jupiterrise.com>
 <558B99D8.7080204@jupiterrise.com>
 <CANvxniUgT8GepV=Ec3dn43gCH8-pAnggAAdkAc=14s3c_-gpcA@mail.gmail.com>
 <alpine.UW2.2.11.1506250816300.18080@server01.int.multitalents.net>
 <CANvxniURtMyQVtGzGWcB0Ka+u8hSJsxcZ79QZxbat+uaVzzyfw@mail.gmail.com>
Message-ID: <CANvxniXFr97v-gY5Hc4nGnA+94r141BuuCug9Ai5mFZuRSMygA@mail.gmail.com>

FYI - the -bnoquiet output...

root at x064:[/data/prj/openbsd/openssh/snap/openssh]lopenbsd-compat -lz
-lcrypt -bnoquiet                 <
(ld): halt 4
(ld): setfflag 4
(ld): savename regress/unittests/sshbuf/test_sshbuf
(ld): filelist 18 1
(ld): i /lib/crt0.o
(ld): i regress/unittests/sshbuf/tests.o
(ld): i regress/unittests/sshbuf/test_sshbuf.o
(ld): i regress/unittests/sshbuf/test_sshbuf_getput_basic.o
(ld): i regress/unittests/sshbuf/test_sshbuf_getput_crypto.o
(ld): i regress/unittests/sshbuf/test_sshbuf_misc.o
(ld): i regress/unittests/sshbuf/test_sshbuf_fuzz.o
(ld): i regress/unittests/sshbuf/test_sshbuf_getput_fuzz.o
(ld): i regress/unittests/sshbuf/test_sshbuf_fixed.o
(ld): i regress/unittests/test_helper/libtest_helper.a
(ld): lib ./libssh.a
(ld): lib openbsd-compat//libopenbsd-compat.a
(ld): lib /usr/lib/libz.a
(ld): lib /usr/lib/libcrypt.a
(ld): lib /usr/vac/lib/libxlopt.a
(ld): lib /usr/vac/lib/libxlipa.a
(ld): lib /usr/vac/lib/libxl.a
(ld): lib /usr/lib/libc.a
LIBRARY: Shared object libz.a[libz.so.1]: 72 symbols imported.
LIBRARY: Shared object libcrypt.a[shr.o]: 8 symbols imported.
LIBRARY: Shared object libc.a[shr.o]: 2873 symbols imported.
LIBRARY: Shared object libc.a[meth.o]: 2 symbols imported.
LIBRARY: Shared object libc.a[posix_aio.o]: 20 symbols imported.
LIBRARY: Shared object libc.a[aio.o]: 18 symbols imported.
LIBRARY: Shared object libc.a[pse.o]: 5 symbols imported.
LIBRARY: Shared object libc.a[dl.o]: 4 symbols imported.
LIBRARY: Shared object libc.a[pty.o]: 1 symbols imported.
FILELIST: Number of previously inserted files processed: 18
(ld): resolve
RESOLVE: 304 of 8566 symbols were kept.
(ld): addgl /usr/lib/glink.o
ADDGL: Glink code added for 60 symbols.
(ld): er full
ld: 0711-318 ERROR: Undefined symbols were found.
        The following symbols are in error:
 Symbol                    Inpndx  TY CL Source-File(Object-File) OR
Import-File{Shared-object}
                              RLD: Address  Section  Rld-type Referencing
Symbol
 ----------------------------------------------------------------------------------------------
 .BN_hex2bn                [26]    ER PR
regress/unittests/sshbuf/test_sshbuf_getput_crypto.c(regress/unittests/sshbuf/test_sshbuf_getput_crypto.o)
                                   0000014c .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   000002d4 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00000404 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   0000058c .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   000006bc .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00000878 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   000009a8 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00000b98 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00000cc8 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00000ee4 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   000010a4 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001258 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001470 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001630 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001850 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   000019e8 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001b6c .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001dc4 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001f94 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
 .BN_num_bits              [38]    ER PR
sshbuf-getput-crypto.c(./libssh.a[sshbuf-getput-crypto.o])
                                   00000024 .text    R_RBR    [12]
.sshbuf_put_bignum1
                                   000001c4 .text    R_RBR    [14]
.sshbuf_put_bignum2
 .BN_num_bits              [42]    ER PR
regress/unittests/sshbuf/test_sshbuf_getput_crypto.c(regress/unittests/sshbuf/test_sshbuf_getput_crypto.o)
                                   0000023c .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   000004f4 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   000007d8 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00000ac4 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00000d2c .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00000f48 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   000012bc .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   000014d4 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001694 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   000018b4 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001bd0 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001e28 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001ff8 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
 .BN_bn2bin                [40]    ER PR
sshbuf-getput-crypto.c(./libssh.a[sshbuf-getput-crypto.o])
                                   00000050 .text    R_RBR    [12]
.sshbuf_put_bignum1
                                   000001f8 .text    R_RBR    [14]
.sshbuf_put_bignum2
 .BN_bin2bn                [54]    ER PR
sshbuf-getput-crypto.c(./libssh.a[sshbuf-getput-crypto.o])
                                   000003ac .text    R_RBR    [16]
.sshbuf_get_bignum1
                                   000004c0 .text    R_RBR    [18]
.sshbuf_get_bignum2
 .BN_free                  [48]    ER PR
regress/unittests/sshbuf/test_sshbuf_getput_crypto.c(regress/unittests/sshbuf/test_sshbuf_getput_crypto.o)
                                   000002a0 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   000003d0 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00000558 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00000688 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00000844 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00000974 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00000b64 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00000c94 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00000ea4 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00000eb0 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001064 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001070 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001218 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001224 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001430 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   0000143c .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   000015f0 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   000015fc .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001810 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   0000181c .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   000019a8 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   000019b4 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001b2c .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001b38 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001d84 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001d90 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001f54 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001f60 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   000020ec .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   000020f8 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
 .BN_new                   [58]    ER PR
regress/unittests/sshbuf/test_sshbuf_getput_fuzz.c(regress/unittests/sshbuf/test_sshbuf_getput_fuzz.o)
                                   00000148 .text    R_RBR    [14]
<.attempt_parse_blob>
                                   00000174 .text    R_RBR    [14]
<.attempt_parse_blob>
                                   000001d4 .text    R_RBR    [14]
<.attempt_parse_blob>
                                   00000200 .text    R_RBR    [14]
<.attempt_parse_blob>
 .BN_new                   [66]    ER PR
regress/unittests/sshbuf/test_sshbuf_getput_crypto.c(regress/unittests/sshbuf/test_sshbuf_getput_crypto.o)
                                   00000e08 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00000fec .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   000011a0 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001394 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001578 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001774 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001930 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001ab4 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001ce8 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00001edc .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
                                   00002074 .text    R_RBR    [12]
.sshbuf_getput_crypto_tests
 .BN_clear_free            [62]    ER PR
regress/unittests/sshbuf/test_sshbuf_getput_fuzz.c(regress/unittests/sshbuf/test_sshbuf_getput_fuzz.o)
                                   0000016c .text    R_RBR    [14]
<.attempt_parse_blob>
                                   00000198 .text    R_RBR    [14]
<.attempt_parse_blob>
                                   000001f8 .text    R_RBR    [14]
<.attempt_parse_blob>
                                   00000224 .text    R_RBR    [14]
<.attempt_parse_blob>
 .BN_cmp                   [216]   ER PR
regress/unittests/test_helper/test_helper.c(regress/unittests/test_helper/libtest_helper.a[test_helper.o])
                                   000020d8 .text    R_RBR    [50]
.assert_bignum
 .BN_bn2hex                [218]   ER PR
regress/unittests/test_helper/test_helper.c(regress/unittests/test_helper/libtest_helper.a[test_helper.o])
                                   00002130 .text    R_RBR    [50]
.assert_bignum
                                   00002154 .text    R_RBR    [50]
.assert_bignum
                                   000021fc .text    R_RBR    [50]
.assert_bignum
                                   00002220 .text    R_RBR    [50]
.assert_bignum
 .ERR_get_error            [220]   ER PR
regress/unittests/test_helper/test_helper.c(regress/unittests/test_helper/libtest_helper.a[test_helper.o])
                                   00002294 .text    R_RBR    [52]
.ssl_err_check
 .ERR_error_string         [222]   ER PR
regress/unittests/test_helper/test_helper.c(regress/unittests/test_helper/libtest_helper.a[test_helper.o])
                                   000022b8 .text    R_RBR    [52]
.ssl_err_check
ER: The return code is 8.
root at x064:[/data/prj/openbsd/openssh/snap/openssh]


On Thu, Jun 25, 2015 at 5:58 PM, Michael Felt <aixtools at gmail.com> wrote:

> Ah - thanks Tim!
>
>
> Now for the report on AIX and --without-openssl (something I am looking
> forward to!)
>
> Basically, it seems to build and "install" (see above), but make tests
> fails due to, guessing, lack of openssl.
>
> root at x064:[/data/prj/openbsd/openssh/snap/openssh]buildaix
> --without-openssl
> xlc is /usr/vacpp/bin/xlc
> + CPPFLAGS="-I/opt/buildaix/include -I/opt/include" CFLAGS="-I/opt/include
> -I/opt/buildaix/include -O2" ./configure \
>                 --prefix=/opt  \
>                 --sysconfdir=/var/openssh/etc \
>                 --sharedstatedir=/var/openssh/com \
>                 --localstatedir=/var/openssh \
>                 --mandir=/usr/share/man \
>                 --infodir=/opt/share/info/openssh --without-openssl \
>                         > .buildaix/configure.out
> configure: WARNING: OpenSSH will use /dev/urandom as a source of random
> numbers. It will fail if this device is not supported or accessible
> configure: WARNING: ** Cannot find lastlog **
> configure: WARNING: Please check and edit blibpath in LDFLAGS in Makefile
> + /opt/bin/make > .buildaix/make.out
> "bsd-cray.c", line 817.23: 1506-356 (W) Compilation unit is empty.
> "kludge-fd_set.c", line 28.1: 1506-356 (W) Compilation unit is empty.
> "glob.c", line 93.9: 1506-236 (W) Macro name TILDE has been redefined.
> "glob.c", line 93.9: 1506-358 (I) "TILDE" is defined on line 250 of
> /usr/include/sys/ioctl.h.
> "sha2.c", line 867.32: 1506-1332 (W) A function with return type "void"
> may not return a value of type "void".
> "strnlen.c", line 37.7: 1506-356 (W) Compilation unit is empty.
> "/usr/include/syms.h", line 288.9: 1506-236 (W) Macro name T_NULL has been
> redefined.
> "/usr/include/syms.h", line 288.9: 1506-358 (I) "T_NULL" is defined on
> line 150 of /usr/include/arpa/onameser_compat.h.
> ar: Creating an archive file libopenbsd-compat.a.
> ar: Creating an archive file libssh.a.
>     1500-030: (I) INFORMATION: main: Additional optimization may be
> attained by recompiling and specifying MAXMEM option with a value greater
> than 8192.
>     1500-030: (I) INFORMATION: process_config_line: Additional
> optimization may be attained by recompiling and specifying MAXMEM option
> with a value greater than 8192.
>     1500-030: (I) INFORMATION: main: Additional optimization may be
> attained by recompiling and specifying MAXMEM option with a value greater
> than 8192.
> "platform.c", line 195.44: 1506-280 (W) Function argument assignment
> between types "char*" and "const char*" is not allowed.
>     1500-030: (I) INFORMATION: process_server_config_line: Additional
> optimization may be attained by recompiling and specifying MAXMEM option
> with a value greater than 8192.
> "monitor.c", line 702.36: 1506-280 (W) Function argument assignment
> between types "unsigned int*" and "int*" is not allowed.
>      470  1500-010: (W) WARNING in monitor_child_postauth: Infinite loop.
> Program may not stop.
>     1640  1500-010: (W) WARNING in sftp_server_main: Infinite loop.
> Program may not stop.
>     1408  1500-010: (W) WARNING in main: Infinite loop.  Program may not
> stop.
>
> + /opt/bin/make install DESTDIR=/var/aixtools/snap/openssh/6.9.0.176 >
> .buildaix/install.out
> key_load_private: invalid format
> key_load_public: invalid format
> Could not load host key: /var/openssh/etc/ssh_host_rsa_key
> key_load_private: invalid format
> key_load_public: invalid format
> Could not load host key: /var/openssh/etc/ssh_host_dsa_key
> + mkinstallp.ksh /var/aixtools/snap/openssh/6.9.0.176 >
> .buildaix/mkinstallp.out
> readline() on closed filehandle RAL at /usr/sbin/makebff.pl line 276.
> ==============================
> aixtools.snap.openssh:aixtools.snap.openssh.man.en_US:6.9.0.176::I:T:::::N:man
> pages::::0::
> aixtools.snap.openssh:aixtools.snap.openssh.rte:6.9.0.176::I:T:::::N:1525
> 0625 1433::::0::
> ==============================
> root at x064:[/data/prj/openbsd/openssh/snap/openssh]
> root at x064:[/data/prj/openbsd/openssh/snap/openssh]id
> uid=199(michael) gid=1(staff) groups=1(staff)
>
> And the the tests that do not get started because they are not ready to be
> --without-openssl it seems.
>
> root at x064:[/data/prj/openbsd/openssh/snap/openssh]make tests
> [ -d `pwd`/regress ] || mkdir -p `pwd`/regress
> [ -d `pwd`/regress/unittests ] || mkdir -p `pwd`/regress/unittests
> [ -d `pwd`/regress/unittests/test_helper ] || \
>         mkdir -p `pwd`/regress/unittests/test_helper
> [ -d `pwd`/regress/unittests/sshbuf ] || \
>         mkdir -p `pwd`/regress/unittests/sshbuf
> [ -d `pwd`/regress/unittests/sshkey ] || \
>         mkdir -p `pwd`/regress/unittests/sshkey
> [ -d `pwd`/regress/unittests/bitmap ] || \
>         mkdir -p `pwd`/regress/unittests/bitmap
> [ -d `pwd`/regress/unittests/hostkeys ] || \
>         mkdir -p `pwd`/regress/unittests/hostkeys
> [ -d `pwd`/regress/unittests/kex ] || \
>         mkdir -p `pwd`/regress/unittests/kex
> [ -f `pwd`/regress/Makefile ] || \
>     ln -s `cd . && pwd`/regress/Makefile `pwd`/regress/Makefile
> (cd openbsd-compat && make)
> make[1]: Entering directory
> `/data/prj/openbsd/openssh/snap/openssh/openbsd-compat'
> make[1]: Nothing to be done for `all'.
> make[1]: Leaving directory
> `/data/prj/openbsd/openssh/snap/openssh/openbsd-compat'
> xlc -I/opt/include -I/opt/buildaix/include -O2  -I. -I.
> -I/opt/buildaix/include -I/opt/include -DSSHDIR=\"/var/openssh/etc\"
> -D_PATH_SSH_PROGRAM=\"/opt/bin/ssh\"
> -D_PATH_SSH_ASKPASS_DEFAULT=\"/opt/libexec/ssh-askpass\"
> -D_PATH_SFTP_SERVER=\"/opt/libexec/sftp-server\"
> -D_PATH_SSH_KEY_SIGN=\"/opt/libexec/ssh-keysign\"
> -D_PATH_SSH_PKCS11_HELPER=\"/opt/libexec/ssh-pkcs11-helper\"
> -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\"
> -DHAVE_CONFIG_H -o regress/modpipe regress/modpipe.c \
> -L. -Lopenbsd-compat/  -blibpath:/usr/lib:/lib -lssh -lopenbsd-compat
> -lssh -lopenbsd-compat -lz  -lcrypt
> ...
> ar rv regress/unittests/test_helper/libtest_helper.a
> regress/unittests/test_helper/test_helper.o
> regress/unittests/test_helper/fuzz.o
> ar: Creating an archive file
> regress/unittests/test_helper/libtest_helper.a.
> a - regress/unittests/test_helper/test_helper.o
> a - regress/unittests/test_helper/fuzz.o
> ranlib regress/unittests/test_helper/libtest_helper.a
> xlc -o regress/unittests/sshbuf/test_sshbuf -L. -Lopenbsd-compat/
> -blibpath:/usr/lib:/lib regress/unittests/sshbuf/tests.o
> regress/unittests/sshbuf/test_sshbuf.o
> regress/unittests/sshbuf/test_sshbuf_getput_basic.o
> regress/unittests/sshbuf/test_sshbuf_getput_crypto.o
> regress/unittests/sshbuf/test_sshbuf_misc.o
> regress/unittests/sshbuf/test_sshbuf_fuzz.o
> regress/unittests/sshbuf/test_sshbuf_getput_fuzz.o
> regress/unittests/sshbuf/test_sshbuf_fixed.o \
>     regress/unittests/test_helper/libtest_helper.a \
>     -lssh -lopenbsd-compat -lssh -lopenbsd-compat -lz  -lcrypt
> ld: 0711-317 ERROR: Undefined symbol: .BN_hex2bn
> ld: 0711-317 ERROR: Undefined symbol: .BN_num_bits
> ld: 0711-317 ERROR: Undefined symbol: .BN_bn2bin
> ld: 0711-317 ERROR: Undefined symbol: .BN_bin2bn
> ld: 0711-317 ERROR: Undefined symbol: .BN_free
> ld: 0711-317 ERROR: Undefined symbol: .BN_new
> ld: 0711-317 ERROR: Undefined symbol: .BN_clear_free
> ld: 0711-317 ERROR: Undefined symbol: .BN_cmp
> ld: 0711-317 ERROR: Undefined symbol: .BN_bn2hex
> ld: 0711-317 ERROR: Undefined symbol: .ERR_get_error
> ld: 0711-317 ERROR: Undefined symbol: .ERR_error_string
> ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
> information.
>
>
>
> On Thu, Jun 25, 2015 at 5:18 PM, Tim Rice <tim at multitalents.net> wrote:
>
>> On Thu, 25 Jun 2015, Michael Felt wrote:
>>
>> > Just running a standard make, and then a make install to a packaging
>> > directory. It seems to be complaining about missing keys - not sure yet
>> if
>> > this is a show stopper
>>
>> For packaging you want the install-nokeys rule not install.
>>
>> --
>> Tim Rice                                Multitalents
>> tim at multitalents.net
>>
>>
>>
>

From djm at mindrot.org  Fri Jun 26 11:44:55 2015
From: djm at mindrot.org (Damien Miller)
Date: Fri, 26 Jun 2015 11:44:55 +1000 (AEST)
Subject: [PATCH] Fix buffer overrun
In-Reply-To: <mmgscv$icn$1@ger.gmane.org>
References: <mmgl4u$ojq$1@ger.gmane.org> <mmgscv$icn$1@ger.gmane.org>
Message-ID: <alpine.BSO.2.20.1506261141160.10428@natsu.mindrot.org>

On Thu, 25 Jun 2015, Salvador Fandino wrote:

> And now the proper fix (hopefully)!

Good catch, I think it should return failure in this case though. An
escape at the end of the line is bad syntax.

diff --git a/readconf.c b/readconf.c
index 0d41d78..06d600c 100644
--- a/readconf.c
+++ b/readconf.c
@@ -1913,7 +1913,8 @@ parse_fwd_field(char **p, struct fwdarg *fwd)
 		switch (*cp) {
 		case '\\':
 			memmove(cp, cp + 1, strlen(cp + 1) + 1);
-			cp++;
+			if (*cp == '\0')
+				return -1;
 			break;
 		case '/':
 			ispath = 1;

From Thomas.Portmann at bger.ch  Fri Jun 26 22:44:30 2015
From: Thomas.Portmann at bger.ch (Thomas Portmann)
Date: Fri, 26 Jun 2015 14:44:30 +0200
Subject: [Q] TCP segment sent is larger than peers advertised MSS
Message-ID: <558D492E.6020308@bger.ch>

Hello,

I am in the process of troubleshooting another problem and noticed a 
rather strange behavior with the openssh client. A client (OpenSSH 5.3) 
and a server (6.7p1) do the TCP handshake, the client announces a MSS of 
1460 (its MTU is 1500), while the server announces a MSS of 1260 (its 
MTU is set to 1300). What troubles me is, that the client is sending the 
server a frame of 2034 bytes (TCP segment length of 1968, during the 
"Client: Key Exchange Init"). Why is it that the client seems to ignore 
the servers MSS?

Thanks for your input


     tom


From Thomas.Portmann at bger.ch  Fri Jun 26 23:30:41 2015
From: Thomas.Portmann at bger.ch (Thomas Portmann)
Date: Fri, 26 Jun 2015 15:30:41 +0200
Subject: [Q] TCP segment sent is larger than peers advertised MSS
In-Reply-To: <20150626132139.GB4023@srv3.flavien.org>
References: <558D492E.6020308@bger.ch> <20150626132139.GB4023@srv3.flavien.org>
Message-ID: <558D5401.3010006@bger.ch>

On 06/26/2015 03:21 PM, Flavien Lebarbe wrote:
> Thomas Portmann ecrivait :
>> I am in the process of troubleshooting another problem and noticed a
>> rather strange behavior with the openssh client. A client (OpenSSH
>> 5.3) and a server (6.7p1) do the TCP handshake, the client announces
>> a MSS of 1460 (its MTU is 1500), while the server announces a MSS of
>> 1260 (its MTU is set to 1300). What troubles me is, that the client
>> is sending the server a frame of 2034 bytes (TCP segment length of
>> 1968, during the "Client: Key Exchange Init"). Why is it that the
>> client seems to ignore the servers MSS?
>  From what you say, the client not only disregards the server MSS, but
> also the client MSS itself : 2034 is larger than 1500. That's weird...
> Do you have a pcap capture of it ? Where do you see the 2034 ? In a
> strace by chance ?

I have a tcpdump I made on the client. Since it is rather small (~7KB), 
I will just attach it to the mail. The 2034 is taken from the capture.


     tom

From gert at greenie.muc.de  Sat Jun 27 01:10:05 2015
From: gert at greenie.muc.de (Gert Doering)
Date: Fri, 26 Jun 2015 17:10:05 +0200
Subject: [Q] TCP segment sent is larger than peers advertised MSS
In-Reply-To: <558D492E.6020308@bger.ch>
References: <558D492E.6020308@bger.ch>
Message-ID: <20150626151004.GB382@greenie.muc.de>

Hi,

On Fri, Jun 26, 2015 at 02:44:30PM +0200, Thomas Portmann wrote:
> Why is it that the client seems to ignore the servers MSS?

TCP segmentation offloading in your network card.

So tcpdump is lying to you if you want to know "what packets are really
travelling over the wire".

gert
-- 
USENET is *not* the non-clickable part of WWW!
                                                           //www.muc.de/~gert/
Gert Doering - Munich, Germany                             gert at greenie.muc.de
fax: +49-89-35655025                        gert at net.informatik.tu-muenchen.de

From djm at mindrot.org  Tue Jun 30 13:13:08 2015
From: djm at mindrot.org (Damien Miller)
Date: Tue, 30 Jun 2015 13:13:08 +1000 (AEST)
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <558B99D8.7080204@jupiterrise.com>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <556CBDDE.4080303@jupiterrise.com> <558B99D8.7080204@jupiterrise.com>
Message-ID: <alpine.BSO.2.20.1506301312140.7061@natsu.mindrot.org>

On Thu, 25 Jun 2015, Tom G. Christensen wrote:

> > bad addr or host: ::1 (no address associated with name)
> > listenaddress order 2
> > failed config parse
> > gmake[1]: *** [t-exec] Error 1
> > 
> 
> I just re-tested on Solaris 2.6 with 9488538a from git and this is still an
> issue.
> Removing the ipv6 addresses from cfgparse.sh allows the testsuite to run to
> completion.

I think we should just disable the test if the host doesn't support IPv6.

diff --git a/regress/cfgparse.sh b/regress/cfgparse.sh
index 7f377d8..e19b4d0 100644
--- a/regress/cfgparse.sh
+++ b/regress/cfgparse.sh
@@ -3,6 +3,12 @@
 
 tid="config parse"
 
+# Possessing struct addrinfo is a reasonable proxy for IPv6 support.
+if ! config_defined HAVE_STRUCT_ADDRINFO ; then
+	echo "skipped (not supported on this platform)"
+	exit 0
+fi
+
 # We need to use the keys generated for the regression test because sshd -T
 # will fail if we're not running with SUDO (no permissions for real keys) or
 # if we are # running tests on a system that has never had sshd installed

From djm at mindrot.org  Tue Jun 30 14:09:31 2015
From: djm at mindrot.org (Damien Miller)
Date: Tue, 30 Jun 2015 14:09:31 +1000 (AEST)
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <CANvxniVA8iW32NojgiB34QLoRZY=PtgfZ5aRF-ywj35qxO8tkQ@mail.gmail.com>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <556CBDDE.4080303@jupiterrise.com> <558B99D8.7080204@jupiterrise.com>
 <CANvxniUgT8GepV=Ec3dn43gCH8-pAnggAAdkAc=14s3c_-gpcA@mail.gmail.com>
 <CANvxniVA8iW32NojgiB34QLoRZY=PtgfZ5aRF-ywj35qxO8tkQ@mail.gmail.com>
Message-ID: <alpine.BSO.2.20.1506301409180.7061@natsu.mindrot.org>

On Thu, 25 Jun 2015, Michael Felt wrote:

> Oh yes, ran into this again - running tests as root.
> 
> run test connect.sh ...
> ssh connect with protocol 1 failed
> ssh connect with protocol 2 failed
> failed simple connect
> 
> After su to non-root...

I think this should fix it:


diff --git a/regress/test-exec.sh b/regress/test-exec.sh
index 114e129..4ec9c3b 100644
--- a/regress/test-exec.sh
+++ b/regress/test-exec.sh
@@ -416,6 +416,11 @@ if [ ! -z "$TEST_SSH_SSHD_CONFOPTS" ]; then
 	echo "$TEST_SSH_SSHD_CONFOPTS" >> $OBJ/sshd_config
 fi
 
+# Override default if running as root to allow tests to complete.
+if test "x$USER" = "xroot" ; then
+	echo "PermitRootLogin without-password" >> $OBJ/sshd_config
+fi
+
 # server config for proxy connects
 cp $OBJ/sshd_config $OBJ/sshd_proxy
 

From tim at multitalents.net  Tue Jun 30 14:09:37 2015
From: tim at multitalents.net (Tim Rice)
Date: Mon, 29 Jun 2015 21:09:37 -0700 (PDT)
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <alpine.BSO.2.20.1506301312140.7061@natsu.mindrot.org>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <556CBDDE.4080303@jupiterrise.com> <558B99D8.7080204@jupiterrise.com>
 <alpine.BSO.2.20.1506301312140.7061@natsu.mindrot.org>
Message-ID: <alpine.UW2.2.11.1506292101170.10635@server01.int.multitalents.net>

On Tue, 30 Jun 2015, Damien Miller wrote:

| I think we should just disable the test if the host doesn't support IPv6.
| 
| diff --git a/regress/cfgparse.sh b/regress/cfgparse.sh
| index 7f377d8..e19b4d0 100644
| --- a/regress/cfgparse.sh
| +++ b/regress/cfgparse.sh
| @@ -3,6 +3,12 @@
|  
|  tid="config parse"
|  
| +# Possessing struct addrinfo is a reasonable proxy for IPv6 support.
| +if ! config_defined HAVE_STRUCT_ADDRINFO ; then

Did you mean HAVE_STRUCT_IN6_ADDR ?

| +	echo "skipped (not supported on this platform)"
| +	exit 0
| +fi

-- 
Tim Rice				Multitalents
tim at multitalents.net



From djm at mindrot.org  Tue Jun 30 14:10:47 2015
From: djm at mindrot.org (Damien Miller)
Date: Tue, 30 Jun 2015 14:10:47 +1000 (AEST)
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <CANvxniURtMyQVtGzGWcB0Ka+u8hSJsxcZ79QZxbat+uaVzzyfw@mail.gmail.com>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <556CBDDE.4080303@jupiterrise.com> <558B99D8.7080204@jupiterrise.com>
 <CANvxniUgT8GepV=Ec3dn43gCH8-pAnggAAdkAc=14s3c_-gpcA@mail.gmail.com>
 <alpine.UW2.2.11.1506250816300.18080@server01.int.multitalents.net>
 <CANvxniURtMyQVtGzGWcB0Ka+u8hSJsxcZ79QZxbat+uaVzzyfw@mail.gmail.com>
Message-ID: <alpine.BSO.2.20.1506301410030.7061@natsu.mindrot.org>

On Thu, 25 Jun 2015, Michael Felt wrote:

> Ah - thanks Tim!
> 
> 
> Now for the report on AIX and --without-openssl (something I am looking
> forward to!)

Yes, the whole of regress/ requires OpenSSL. I have a patch to get the
unit tests working that I'll commit after release but much more is
required for the regression suite.

-d

From djm at mindrot.org  Tue Jun 30 14:12:48 2015
From: djm at mindrot.org (Damien Miller)
Date: Tue, 30 Jun 2015 14:12:48 +1000 (AEST)
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <alpine.UW2.2.11.1506292101170.10635@server01.int.multitalents.net>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <556CBDDE.4080303@jupiterrise.com> <558B99D8.7080204@jupiterrise.com>
 <alpine.BSO.2.20.1506301312140.7061@natsu.mindrot.org>
 <alpine.UW2.2.11.1506292101170.10635@server01.int.multitalents.net>
Message-ID: <alpine.BSO.2.20.1506301411150.7061@natsu.mindrot.org>

On Mon, 29 Jun 2015, Tim Rice wrote:

> On Tue, 30 Jun 2015, Damien Miller wrote:
> 
> | I think we should just disable the test if the host doesn't support IPv6.
> | 
> | diff --git a/regress/cfgparse.sh b/regress/cfgparse.sh
> | index 7f377d8..e19b4d0 100644
> | --- a/regress/cfgparse.sh
> | +++ b/regress/cfgparse.sh
> | @@ -3,6 +3,12 @@
> |  
> |  tid="config parse"
> |  
> | +# Possessing struct addrinfo is a reasonable proxy for IPv6 support.
> | +if ! config_defined HAVE_STRUCT_ADDRINFO ; then
> 
> Did you mean HAVE_STRUCT_IN6_ADDR ?

That's even betterer. Ok?

diff --git a/regress/cfgparse.sh b/regress/cfgparse.sh
index 7f377d8..a5296a2 100644
--- a/regress/cfgparse.sh
+++ b/regress/cfgparse.sh
@@ -3,6 +3,12 @@
 
 tid="config parse"
 
+# This is a reasonable proxy for IPv6 support.
+if ! config_defined HAVE_STRUCT_IN6_ADDR ; then
+	echo "skipped (not supported on this platform)"
+	exit 0
+fi
+
 # We need to use the keys generated for the regression test because sshd -T
 # will fail if we're not running with SUDO (no permissions for real keys) or
 # if we are # running tests on a system that has never had sshd installed

From tim at multitalents.net  Tue Jun 30 14:36:12 2015
From: tim at multitalents.net (Tim Rice)
Date: Mon, 29 Jun 2015 21:36:12 -0700 (PDT)
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <alpine.BSO.2.20.1506301411150.7061@natsu.mindrot.org>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <556CBDDE.4080303@jupiterrise.com> <558B99D8.7080204@jupiterrise.com>
 <alpine.BSO.2.20.1506301312140.7061@natsu.mindrot.org>
 <alpine.UW2.2.11.1506292101170.10635@server01.int.multitalents.net>
 <alpine.BSO.2.20.1506301411150.7061@natsu.mindrot.org>
Message-ID: <alpine.UW2.2.11.1506292134460.10635@server01.int.multitalents.net>

On Tue, 30 Jun 2015, Damien Miller wrote:

| On Mon, 29 Jun 2015, Tim Rice wrote:
| 
| > On Tue, 30 Jun 2015, Damien Miller wrote:
| > 
| > | I think we should just disable the test if the host doesn't support IPv6.
| > | 
| > | diff --git a/regress/cfgparse.sh b/regress/cfgparse.sh
| > | index 7f377d8..e19b4d0 100644
| > | --- a/regress/cfgparse.sh
| > | +++ b/regress/cfgparse.sh
| > | @@ -3,6 +3,12 @@
| > |  
| > |  tid="config parse"
| > |  
| > | +# Possessing struct addrinfo is a reasonable proxy for IPv6 support.
| > | +if ! config_defined HAVE_STRUCT_ADDRINFO ; then
| > 
| > Did you mean HAVE_STRUCT_IN6_ADDR ?
| 
| That's even betterer. Ok?
| 
| diff --git a/regress/cfgparse.sh b/regress/cfgparse.sh
| index 7f377d8..a5296a2 100644
| --- a/regress/cfgparse.sh
| +++ b/regress/cfgparse.sh
| @@ -3,6 +3,12 @@
|  
|  tid="config parse"
|  
| +# This is a reasonable proxy for IPv6 support.
| +if ! config_defined HAVE_STRUCT_IN6_ADDR ; then
| +	echo "skipped (not supported on this platform)"
| +	exit 0
| +fi
| +
|  # We need to use the keys generated for the regression test because sshd -T
|  # will fail if we're not running with SUDO (no permissions for real keys) or
|  # if we are # running tests on a system that has never had sshd installed
| _______________________________________________

Seems a shame to disable the whole test.
Is this too ugly?
............
--- cfgparse.sh.old	2015-06-01 22:43:48.721636775 -0700
+++ cfgparse.sh	2015-06-29 21:33:04.793724856 -0700
@@ -3,6 +3,11 @@
 
 tid="config parse"
 
+# This is a reasonable proxy for IPv6 support.
+if ! config_defined HAVE_STRUCT_IN6_ADDR ; then
+	SKIP_IPV6=yes
+fi
+
 # We need to use the keys generated for the regression test because sshd -T
 # will fail if we're not running with SUDO (no permissions for real keys) or
 # if we are # running tests on a system that has never had sshd installed
@@ -26,6 +31,9 @@
 cat > $OBJ/sshd_config.0 <<EOD
 listenaddress 1.2.3.4:1234
 listenaddress 1.2.3.4:5678
+EOD
+
+[ X${SKIP_IPV6} = Xyes ]  ||  cat > $OBJ/sshd_config.0 <<EOD
 listenaddress [::1]:1234
 listenaddress [::1]:5678
 EOD
@@ -37,6 +45,9 @@
 port 1234
 port 5678
 listenaddress 1.2.3.4
+EOD
+
+[ X${SKIP_IPV6} = Xyes ]  ||  cat > $OBJ/sshd_config.1 <<EOD
 listenaddress ::1
 EOD
 ($SUDO ${SSHD} -T -f $OBJ/sshd_config.1 | \
@@ -47,11 +58,14 @@
 cat > $OBJ/sshd_config.1 <<EOD
 ${SSHD_KEYS}
 listenaddress 1.2.3.4
-listenaddress ::1
 port 1234
 port 5678
 addressfamily any
 EOD
+
+[ X${SKIP_IPV6} = Xyes ]  ||  cat > $OBJ/sshd_config.1 <<EOD
+listenaddress ::1
+EOD
 ($SUDO ${SSHD} -T -f $OBJ/sshd_config.1 | \
  grep 'listenaddress ' >$OBJ/sshd_config.2 &&
  diff $OBJ/sshd_config.0 $OBJ/sshd_config.2) || \
............

-- 
Tim Rice				Multitalents
tim at multitalents.net



From djm at mindrot.org  Tue Jun 30 15:34:11 2015
From: djm at mindrot.org (Damien Miller)
Date: Tue, 30 Jun 2015 15:34:11 +1000 (AEST)
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <alpine.UW2.2.11.1506292134460.10635@server01.int.multitalents.net>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <556CBDDE.4080303@jupiterrise.com> <558B99D8.7080204@jupiterrise.com>
 <alpine.BSO.2.20.1506301312140.7061@natsu.mindrot.org>
 <alpine.UW2.2.11.1506292101170.10635@server01.int.multitalents.net>
 <alpine.BSO.2.20.1506301411150.7061@natsu.mindrot.org>
 <alpine.UW2.2.11.1506292134460.10635@server01.int.multitalents.net>
Message-ID: <alpine.BSO.2.20.1506301530270.7061@natsu.mindrot.org>

On Mon, 29 Jun 2015, Tim Rice wrote:

> Seems a shame to disable the whole test.
> Is this too ugly?

don't mind, but there were a couple of bugs (tests reverse, > instead of >>)

ok?

diff --git a/regress/cfgparse.sh b/regress/cfgparse.sh
index 7f377d8..fca46c1 100644
--- a/regress/cfgparse.sh
+++ b/regress/cfgparse.sh
@@ -3,6 +3,11 @@
 
 tid="config parse"
 
+# This is a reasonable proxy for IPv6 support.
+if ! config_defined HAVE_STRUCT_IN6_ADDR ; then
+	SKIP_IPV6=yes
+fi
+
 # We need to use the keys generated for the regression test because sshd -T
 # will fail if we're not running with SUDO (no permissions for real keys) or
 # if we are # running tests on a system that has never had sshd installed
@@ -26,9 +31,12 @@ verbose "listenaddress order"
 cat > $OBJ/sshd_config.0 <<EOD
 listenaddress 1.2.3.4:1234
 listenaddress 1.2.3.4:5678
+EOD
+[ X${SKIP_IPV6} = Xyes ] && cat >> $OBJ/sshd_config.0 <<EOD
 listenaddress [::1]:1234
 listenaddress [::1]:5678
 EOD
+
 # test input sets.  should all result in the output above.
 # test 1: addressfamily and port first
 cat > $OBJ/sshd_config.1 <<EOD
@@ -37,8 +45,11 @@ addressfamily any
 port 1234
 port 5678
 listenaddress 1.2.3.4
+EOD
+[ X${SKIP_IPV6} = Xyes ] && cat >> $OBJ/sshd_config.1 <<EOD
 listenaddress ::1
 EOD
+
 ($SUDO ${SSHD} -T -f $OBJ/sshd_config.1 | \
  grep 'listenaddress ' >$OBJ/sshd_config.2 &&
  diff $OBJ/sshd_config.0 $OBJ/sshd_config.2) || \
@@ -47,11 +58,14 @@ EOD
 cat > $OBJ/sshd_config.1 <<EOD
 ${SSHD_KEYS}
 listenaddress 1.2.3.4
-listenaddress ::1
 port 1234
 port 5678
 addressfamily any
 EOD
+[ X${SKIP_IPV6} = Xyes ] && cat >> $OBJ/sshd_config.1 <<EOD
+listenaddress ::1
+EOD
+
 ($SUDO ${SSHD} -T -f $OBJ/sshd_config.1 | \
  grep 'listenaddress ' >$OBJ/sshd_config.2 &&
  diff $OBJ/sshd_config.0 $OBJ/sshd_config.2) || \

From tim at multitalents.net  Tue Jun 30 15:56:11 2015
From: tim at multitalents.net (Tim Rice)
Date: Mon, 29 Jun 2015 22:56:11 -0700 (PDT)
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <alpine.BSO.2.20.1506301530270.7061@natsu.mindrot.org>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <556CBDDE.4080303@jupiterrise.com> <558B99D8.7080204@jupiterrise.com>
 <alpine.BSO.2.20.1506301312140.7061@natsu.mindrot.org>
 <alpine.UW2.2.11.1506292101170.10635@server01.int.multitalents.net>
 <alpine.BSO.2.20.1506301411150.7061@natsu.mindrot.org>
 <alpine.UW2.2.11.1506292134460.10635@server01.int.multitalents.net>
 <alpine.BSO.2.20.1506301530270.7061@natsu.mindrot.org>
Message-ID: <alpine.UW2.2.11.1506292250010.10635@server01.int.multitalents.net>

On Tue, 30 Jun 2015, Damien Miller wrote:

> On Mon, 29 Jun 2015, Tim Rice wrote:
> 
> > Seems a shame to disable the whole test.
> > Is this too ugly?
> 
> don't mind, but there were a couple of bugs (tests reverse, > instead of >>)

Actually the test was correct. Skip or append IPv6 bits.
But "> instead of >>" was a mistake. 
Oops.

> ok?

OK leaving "||" and fixing "> instead of >>".
(tested this time, although not on solaris 2.6 like the original poster)

> 
> diff --git a/regress/cfgparse.sh b/regress/cfgparse.sh
> index 7f377d8..fca46c1 100644
> --- a/regress/cfgparse.sh
> +++ b/regress/cfgparse.sh
> @@ -3,6 +3,11 @@
>  
>  tid="config parse"
>  
> +# This is a reasonable proxy for IPv6 support.
> +if ! config_defined HAVE_STRUCT_IN6_ADDR ; then
> +	SKIP_IPV6=yes
> +fi
> +
>  # We need to use the keys generated for the regression test because sshd -T
>  # will fail if we're not running with SUDO (no permissions for real keys) or
>  # if we are # running tests on a system that has never had sshd installed
> @@ -26,9 +31,12 @@ verbose "listenaddress order"
>  cat > $OBJ/sshd_config.0 <<EOD
>  listenaddress 1.2.3.4:1234
>  listenaddress 1.2.3.4:5678
> +EOD
> +[ X${SKIP_IPV6} = Xyes ] && cat >> $OBJ/sshd_config.0 <<EOD
>  listenaddress [::1]:1234
>  listenaddress [::1]:5678
>  EOD
> +
>  # test input sets.  should all result in the output above.
>  # test 1: addressfamily and port first
>  cat > $OBJ/sshd_config.1 <<EOD
> @@ -37,8 +45,11 @@ addressfamily any
>  port 1234
>  port 5678
>  listenaddress 1.2.3.4
> +EOD
> +[ X${SKIP_IPV6} = Xyes ] && cat >> $OBJ/sshd_config.1 <<EOD
>  listenaddress ::1
>  EOD
> +
>  ($SUDO ${SSHD} -T -f $OBJ/sshd_config.1 | \
>   grep 'listenaddress ' >$OBJ/sshd_config.2 &&
>   diff $OBJ/sshd_config.0 $OBJ/sshd_config.2) || \
> @@ -47,11 +58,14 @@ EOD
>  cat > $OBJ/sshd_config.1 <<EOD
>  ${SSHD_KEYS}
>  listenaddress 1.2.3.4
> -listenaddress ::1
>  port 1234
>  port 5678
>  addressfamily any
>  EOD
> +[ X${SKIP_IPV6} = Xyes ] && cat >> $OBJ/sshd_config.1 <<EOD
> +listenaddress ::1
> +EOD
> +
>  ($SUDO ${SSHD} -T -f $OBJ/sshd_config.1 | \
>   grep 'listenaddress ' >$OBJ/sshd_config.2 &&
>   diff $OBJ/sshd_config.0 $OBJ/sshd_config.2) || \
> _______________________________________________

-- 
Tim Rice				Multitalents
tim at multitalents.net



From alex at alex.org.uk  Tue Jun 30 16:44:20 2015
From: alex at alex.org.uk (Alex Bligh)
Date: Tue, 30 Jun 2015 07:44:20 +0100
Subject: Call for testing: OpenSSH 6.9
In-Reply-To: <alpine.UW2.2.11.1506292250010.10635@server01.int.multitalents.net>
References: <alpine.BSO.2.20.1505291345470.11037@natsu.mindrot.org>
 <556CBDDE.4080303@jupiterrise.com> <558B99D8.7080204@jupiterrise.com>
 <alpine.BSO.2.20.1506301312140.7061@natsu.mindrot.org>
 <alpine.UW2.2.11.1506292101170.10635@server01.int.multitalents.net>
 <alpine.BSO.2.20.1506301411150.7061@natsu.mindrot.org>
 <alpine.UW2.2.11.1506292134460.10635@server01.int.multitalents.net>
 <alpine.BSO.2.20.1506301530270.7061@natsu.mindrot.org>
 <alpine.UW2.2.11.1506292250010.10635@server01.int.multitalents.net>
Message-ID: <182A98C2-4117-4C46-99F7-9F6AEED57C6C@alex.org.uk>


On 30 Jun 2015, at 06:56, Tim Rice <tim at multitalents.net> wrote:

> On Tue, 30 Jun 2015, Damien Miller wrote:
> 
>> On Mon, 29 Jun 2015, Tim Rice wrote:
>> 
>>> Seems a shame to disable the whole test.
>>> Is this too ugly?
>> 
>> don't mind, but there were a couple of bugs (tests reverse, > instead of >>)
> 
> Actually the test was correct. Skip or append IPv6 bits.
> But "> instead of >>" was a mistake. 
> Oops.

Note that the proposed test tests whether IPv6 code can be
compiled, not whether it's supported or enabled on the host.

For instance, the following sysctl's will turn IPv6 support]
off under Linux:
    net.ipv6.conf.all.disable_ipv6 = 1
    net.ipv6.conf.default.disable_ipv6 = 1
    net.ipv6.conf.lo.disable_ipv6 = 1
but the test would still be run. I believe OpenBSD would
perform similarly if the kernel were compiled without
IPv6 support.

I think the real test would involve running a tiny program
to check you can bind to an IPv6 loopback address as well
as checking compile time support.

-- 
Alex Bligh





From Thomas.Portmann at bger.ch  Tue Jun 30 19:28:27 2015
From: Thomas.Portmann at bger.ch (Thomas Portmann)
Date: Tue, 30 Jun 2015 11:28:27 +0200
Subject: [Q] TCP segment sent is larger than peers advertised MSS
In-Reply-To: <20150626151004.GB382@greenie.muc.de>
References: <558D492E.6020308@bger.ch> <20150626151004.GB382@greenie.muc.de>
Message-ID: <5592613B.7000903@bger.ch>

On 06/26/2015 05:10 PM, Gert Doering wrote:
> On Fri, Jun 26, 2015 at 02:44:30PM +0200, Thomas Portmann wrote:

Hello Gert and all,

>> Why is it that the client seems to ignore the servers MSS?
> TCP segmentation offloading in your network card.
>
> So tcpdump is lying to you if you want to know "what packets are really
> travelling over the wire".

It turns out Gert was right (and I didn't even know TCP segmentation 
offloading exists)... but the mean thing is, even doing port mirroring 
to another computer, TCP segement reassembly happened on the monitoring 
computer in the NIC, so in wireshark I just saw one large frame, until I 
changed the NIC!

So, thank you Greg for your hint and Flavien for your response

Regards


     tom

From ag4ve.us at gmail.com  Tue Jun 30 21:35:06 2015
From: ag4ve.us at gmail.com (shawn wilson)
Date: Tue, 30 Jun 2015 07:35:06 -0400
Subject: how is the sha fingerprint generated?
Message-ID: <CAH_OBie=h=Pw2bGuZZtKjiXkcc7Uy32T3NfbBzzntn73xuc8rw@mail.gmail.com>

% cat ext_rsa.pub| sed -r 's/.*(AAAA[^ ]+).*/\1/' | sha256sum

  ~/.ssh swlap1
d4bf8b06f2d9d9af7a11583a5367205ed310a84f0dee68d062e2ddca1e85c3ff  -
 % ssh-keygen -lf ext_rsa.pub

   ~/.ssh swlap1
8192 SHA256:FgrfxmdjTM/j4wwRa7nVdPSUaJdqHYMJtJ6aciPl9ug swilson at swlap1 (RSA)

Why do those differ and how would i generate the equivalent (mainly
just curious)? I've also tried base64 and a few other substitutions at
the end and I can't get them to match (probably would save time to
just look at the code, but...).