From mindrot at hda3.com  Tue Nov  1 08:06:47 2016
From: mindrot at hda3.com (Peter Moody)
Date: Mon, 31 Oct 2016 14:06:47 -0700
Subject: use PT_DENY_ATTACH on Mac OS X
In-Reply-To: <20161026003053.GA6627@gate.dtucker.net>
References: <20161026003053.GA6627@gate.dtucker.net>
Message-ID: <CADbMJxnnBp2-FDpbJYEvvm_jWuL-ffr7CbcevC4=03JTreORNg@mail.gmail.com>

sgtm

for some reason I thought you were already doing this.

On Tue, Oct 25, 2016 at 5:30 PM, Darren Tucker <dtucker at zip.com.au> wrote:
> Hi.
>
> Mac OS X has a PT_DENY_ATTACH argument to ptrace(2) which does what
> it says on the tin:
>
>  PT_DENY_ATTACH
>            This request is the other operation used by the traced
>            process; it allows a process that is not currently being
>            traced to deny future traces by its parent.  All other
>            arguments are ignored.  If the process is currently being
>            traced, it will exit with the exit status of ENOTSUP; oth-
>            erwise, it sets a flag that denies future traces.  An
>            attempt by the parent to trace a process which has set this
>            flag will result in a segmentation violation in the parent
>
> Any reason not to use it in platform_disable_tracing() ?
>
> diff --git a/configure.ac b/configure.ac
> index f5e1378..88c4633 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -405,6 +405,7 @@ AC_CHECK_HEADERS([ \
>         sys/poll.h \
>         sys/prctl.h \
>         sys/pstat.h \
> +       sys/ptrace.h \
>         sys/select.h \
>         sys/stat.h \
>         sys/stream.h \
> diff --git a/platform-tracing.c b/platform-tracing.c
> index 81020e7..4c80a28 100644
> --- a/platform-tracing.c
> +++ b/platform-tracing.c
> @@ -20,6 +20,9 @@
>  #if defined(HAVE_SYS_PRCTL_H)
>  #include <sys/prctl.h> /* For prctl() and PR_SET_DUMPABLE */
>  #endif
> +#ifdef HAVE_SYS_PTRACE_H
> +#include <sys/ptrace.h>
> +#endif
>  #ifdef HAVE_PRIV_H
>  #include <priv.h> /* For setpflags() and __PROC_PROTECT  */
>  #endif
> @@ -40,4 +43,9 @@ platform_disable_tracing(int strict)
>         if (setpflags(__PROC_PROTECT, 1) != 0 && strict)
>                 fatal("unable to make the process untraceable");
>  #endif
> +#ifdef PT_DENY_ATTACH
> +       /* Mac OS X */
> +       if (ptrace(PT_DENY_ATTACH, 0, 0, 0) == -1 && strict)
> +               fatal("unable to set PT_DENY_ATTACH");
> +#endif
>  }
>
> --
> Darren Tucker (dtucker at zip.com.au)
> GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
>     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 dtucker at zip.com.au  Tue Nov  1 08:14:17 2016
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 1 Nov 2016 08:14:17 +1100
Subject: use PT_DENY_ATTACH on Mac OS X
In-Reply-To: <CADbMJxnnBp2-FDpbJYEvvm_jWuL-ffr7CbcevC4=03JTreORNg@mail.gmail.com>
References: <20161026003053.GA6627@gate.dtucker.net>
 <CADbMJxnnBp2-FDpbJYEvvm_jWuL-ffr7CbcevC4=03JTreORNg@mail.gmail.com>
Message-ID: <CALDDTe3h4nSco4i7i9qo+fBJKKyOmmCgUtyxz=F+YOKq7PvAdg@mail.gmail.com>

On Tue, Nov 1, 2016 at 8:06 AM, Peter Moody <mindrot at hda3.com> wrote:

> sgtm
>
> for some reason I thought you were already doing this.


It's possible I mentioned it before but did not actually commit it.
Anyway, this time for sure:
https://anongit.mindrot.org/openssh.git/commit/?id=5ee3fb5affd7646f141749483205ade5fc54adaf

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From arnebrants at hotmail.com  Tue Nov  1 10:27:17 2016
From: arnebrants at hotmail.com (Arne Brants)
Date: Mon, 31 Oct 2016 23:27:17 +0000
Subject: Unix socket forwarding stopped working
Message-ID: <KL1PR02MB1574267349A24844518205E9CFAE0@KL1PR02MB1574.apcprd02.prod.outlook.com>


Hi,


I'm using openssh to forward a remote unix socket to my local server. This has been working just fine until recently, but since a few days it is no longer working and I get error messages in the console when accessing the local socket


The command I use:

ssh -C -f -N -L/local/socket:/remote/socket user at remote-system


Error on connecting to local socket:

channel 1: open failed: unknown channel type:


Local system:

Debian Jessie

Kernel 3.16.0.4

OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.1t  3 May 2016


Remote system:

Debian Jessie

Kernel 4.7.0-0

OpenSSH_6.7p1 Debian-5+deb8u3, OpenSSL 1.0.2j  3 May 2016


Would this be an SSH or SSL issue, or has something broken between the two packages?

From cjwatson at debian.org  Wed Nov  2 11:43:59 2016
From: cjwatson at debian.org (Colin Watson)
Date: Wed, 2 Nov 2016 00:43:59 +0000
Subject: OpenSSL 1.1.0 support
In-Reply-To: <20160918182230.tflkxar45vc6xmyf@roeckx.be>
References: <20160918182230.tflkxar45vc6xmyf@roeckx.be>
Message-ID: <20161102004359.GA21575@riva.ucam.org>

On Sun, Sep 18, 2016 at 08:22:31PM +0200, Kurt Roeckx wrote:
> Attached is a patch that add supports for building against OpenSSL
> 1.1.0. I also made a github pull request for it at:
> https://github.com/openssh/openssh-portable/pull/48

Hi,

Debian unstable now has OpenSSL 1.1.0 as the default, so I'll have to
take some kind of positive action if I want my OpenSSH packages to keep
building cleanly.  I know it's a big patch, but is anyone likely to be
able to look at Kurt's changes soon?  I'm not very comfortable with
applying a change of this size as a local patch.

Thanks,

-- 
Colin Watson                                       [cjwatson at debian.org]

From jjelen at redhat.com  Wed Nov  2 20:29:55 2016
From: jjelen at redhat.com (Jakub Jelen)
Date: Wed, 2 Nov 2016 10:29:55 +0100
Subject: OpenSSL 1.1.0 support
In-Reply-To: <20161102004359.GA21575@riva.ucam.org>
References: <20160918182230.tflkxar45vc6xmyf@roeckx.be>
 <20161102004359.GA21575@riva.ucam.org>
Message-ID: <0d95cbbd-99b9-e612-6ebb-893ee989831a@redhat.com>

On 11/02/2016 01:43 AM, Colin Watson wrote:
> On Sun, Sep 18, 2016 at 08:22:31PM +0200, Kurt Roeckx wrote:
>> Attached is a patch that add supports for building against OpenSSL
>> 1.1.0. I also made a github pull request for it at:
>> https://github.com/openssh/openssh-portable/pull/48
> Hi,
>
> Debian unstable now has OpenSSL 1.1.0 as the default, so I'll have to
> take some kind of positive action if I want my OpenSSH packages to keep
> building cleanly.  I know it's a big patch, but is anyone likely to be
> able to look at Kurt's changes soon?  I'm not very comfortable with
> applying a change of this size as a local patch.
Hello Colin,
Fedora Rawhide has already OpenSSL 1.1.0 and we use the patch based on 
the Kurt's one (after fixing initial bugs and extending for GSSAPI and 
SSH1 client support). The full Fedora patch is available in our git [1].

The current set of patches are rebased on current upstream is attached 
with few more tweaks needed to build, pass testsuite and make it work. 
The upstream review and insight would be helpful.

[1] 
https://pkgs.fedoraproject.org/cgit/rpms/openssh.git/tree/openssh-7.3p1-openssl-1.1.0.patch

Regards,

-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat

-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssh-openssl-1.1.0.patch
Type: text/x-patch
Size: 123076 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20161102/eb27c572/attachment-0001.bin>

From stu at spacehopper.org  Wed Nov  2 23:03:06 2016
From: stu at spacehopper.org (Stuart Henderson)
Date: Wed, 2 Nov 2016 12:03:06 +0000 (UTC)
Subject: OpenSSL 1.1.0 support
References: <20160918182230.tflkxar45vc6xmyf@roeckx.be>
 <20161102004359.GA21575@riva.ucam.org>
 <0d95cbbd-99b9-e612-6ebb-893ee989831a@redhat.com>
Message-ID: <slrno1jlft.1joh.stu@naiad.spacehopper.org>

On 2016-11-02, Jakub Jelen <jjelen at redhat.com> wrote:
> The current set of patches are rebased on current upstream is attached 
> with few more tweaks needed to build, pass testsuite and make it work. 
> The upstream review and insight would be helpful.

Since these are going to break things with LibreSSL, I doubt they'll be
acceptable as-is.



From djm at mindrot.org  Thu Nov  3 09:33:23 2016
From: djm at mindrot.org (Damien Miller)
Date: Thu, 3 Nov 2016 09:33:23 +1100 (AEDT)
Subject: OpenSSL 1.1.0 support
In-Reply-To: <slrno1jlft.1joh.stu@naiad.spacehopper.org>
References: <20160918182230.tflkxar45vc6xmyf@roeckx.be>
 <20161102004359.GA21575@riva.ucam.org>
 <0d95cbbd-99b9-e612-6ebb-893ee989831a@redhat.com>
 <slrno1jlft.1joh.stu@naiad.spacehopper.org>
Message-ID: <alpine.BSO.2.20.1611030926130.8657@natsu.mindrot.org>

On Wed, 2 Nov 2016, Stuart Henderson wrote:

> On 2016-11-02, Jakub Jelen <jjelen at redhat.com> wrote:
> > The current set of patches are rebased on current upstream is attached 
> > with few more tweaks needed to build, pass testsuite and make it work. 
> > The upstream review and insight would be helpful.
> 
> Since these are going to break things with LibreSSL, I doubt they'll be
> acceptable as-is.

This is the nub of the problem: upstream (OpenBSD) OpenSSH targets
LibreSSL natively (it's also used by Apple for their OS X builds). If we
pick up the 1.1.0 patch, we'd probably have to do it in portable because
there's little point in patching OpenBSD for API that doesn't exist
there. I don't want to have to carry such a major divergence in just the
portable tree.

I don't know what LibreSSL's plans are wrt the 1.1.x API, but convincing
them to adopt it would remove much of the problem.

It's disappointing though that OpenSSL didn't see fit to write their own
set of 1.0.x->1.1.x API shims and ship it alongside 1.0.x releases. It
would have made the transition easier for everyone I think.

-d

From mstone at mathom.us  Thu Nov  3 10:35:04 2016
From: mstone at mathom.us (Michael Stone)
Date: Wed, 2 Nov 2016 19:35:04 -0400
Subject: OpenSSL 1.1.0 support
In-Reply-To: <alpine.BSO.2.20.1611030926130.8657@natsu.mindrot.org>
References: <20160918182230.tflkxar45vc6xmyf@roeckx.be>
 <20161102004359.GA21575@riva.ucam.org>
 <0d95cbbd-99b9-e612-6ebb-893ee989831a@redhat.com>
 <slrno1jlft.1joh.stu@naiad.spacehopper.org>
 <alpine.BSO.2.20.1611030926130.8657@natsu.mindrot.org>
Message-ID: <20161102233503.GN23907@mathom.us>

On Thu, Nov 03, 2016 at 09:33:23AM +1100, Damien Miller wrote:
>It's disappointing though that OpenSSL didn't see fit to write their own
>set of 1.0.x->1.1.x API shims and ship it alongside 1.0.x releases. It
>would have made the transition easier for everyone I think.

Given how much flack they got from various quarters, including in
particular the libressl folks, for carrying "too much legacy baggage" 
that would have ironic if nothing else.

All that aside, I'm not entirely clear on why there's a pressing need to 
link openssh against openssl 1.1 instead of just linking it to 1.0; 
1.0.2 is actually scheduled to be supported for longer than 1.1.0.

Mike Stone

From djm at mindrot.org  Thu Nov  3 10:50:33 2016
From: djm at mindrot.org (Damien Miller)
Date: Thu, 3 Nov 2016 10:50:33 +1100 (AEDT)
Subject: OpenSSL 1.1.0 support
In-Reply-To: <20161102233503.GN23907@mathom.us>
References: <20160918182230.tflkxar45vc6xmyf@roeckx.be>
 <20161102004359.GA21575@riva.ucam.org>
 <0d95cbbd-99b9-e612-6ebb-893ee989831a@redhat.com>
 <slrno1jlft.1joh.stu@naiad.spacehopper.org>
 <alpine.BSO.2.20.1611030926130.8657@natsu.mindrot.org>
 <20161102233503.GN23907@mathom.us>
Message-ID: <alpine.BSO.2.20.1611031047090.8657@natsu.mindrot.org>

On Wed, 2 Nov 2016, Michael Stone wrote:

> On Thu, Nov 03, 2016 at 09:33:23AM +1100, Damien Miller wrote:
> > It's disappointing though that OpenSSL didn't see fit to write their own
> > set of 1.0.x->1.1.x API shims and ship it alongside 1.0.x releases. It
> > would have made the transition easier for everyone I think.
> 
> Given how much flack they got from various quarters, including in
> particular the libressl folks, for carrying "too much legacy baggage" that
> would have ironic if nothing else.

I think you misunderstand: I'm not suggesting they carry 1.0.x API in
1.1.x (that would be self-defeating), but providing standard forward-
compat code in 1.0.x so everyone else doesn't have to write their own.

IMO nobody is in a better position to write said compat code than
the OpenSSL developers and forcing application developers to write
them greatly multiplies the number of shim implementations and thus
the likelihood of bugs in one or more of them.

-d

From johannes at kyriasis.com  Fri Nov  4 20:43:38 2016
From: johannes at kyriasis.com (=?UTF-8?q?Johannes=20L=C3=B6thberg?=)
Date: Fri,  4 Nov 2016 10:43:38 +0100
Subject: [PATCH] Set KRB5PRINCIPAL in user environment
Message-ID: <20161104094338.9466-1-johannes@kyriasis.com>

Signed-off-by: Johannes L?thberg <johannes at kyriasis.com>
---
 gss-serv-krb5.c | 5 +++++
 1 file changed, 5 insertions(+)

diff --git a/gss-serv-krb5.c b/gss-serv-krb5.c
index 795992d..a12bb24 100644
--- a/gss-serv-krb5.c
+++ b/gss-serv-krb5.c
@@ -106,6 +106,11 @@ ssh_gssapi_krb5_userok(ssh_gssapi_client *client, char *name)
 	} else
 		retval = 0;
 
+#ifdef USE_PAM
+	if (options.use_pam)
+		do_pam_putenv("KRB5PRINCIPAL", (char *)client->displayname.value);
+#endif
+
 	krb5_free_principal(krb_context, princ);
 	return retval;
 }
-- 
2.10.2


From campoverdeangelf at gmail.com  Sun Nov  6 04:58:09 2016
From: campoverdeangelf at gmail.com (Angel Campoverde)
Date: Sat, 5 Nov 2016 18:58:09 +0100
Subject: Kerberos + Openssh 6.7 issue in MacOS sierra
Message-ID: <CAJ22+4T483b1YctGAOgMyas3mry4zdm8SOXRZdYpODryG0gSyA@mail.gmail.com>

Hi,

I hope this is the right mailing list. I upgraded to Sierra and It came
with the new OpenSSH 6.7. When I try to get into a remote machine after
making the kerberos ticket I get:

/Users/angelcampoverde/.ssh/config: line 11: Bad configuration option:
gssapitrustdns
/Users/angelcampoverde/.ssh/config: terminating, 1 bad configuration options

Which suggests that the line:

  GSSAPIAuthentication      yes

Is not supposed to be in the ~/.ssh/config file anymore. Without this line
I cannot use kerberos to authenticate, I'd have to use the password. Is
Kerberos not supported anymore beyond version 6.6? Is there a patch or a
new line that should be there in that file instead of that one?

Other people seem to have the same problem here:

http://stackoverflow.com/questions/39634166/after-update-mac-os-sierra-can-not-use-ssh-login-remote-system-how-can-i-fix-th

and here:

http://apple.stackexchange.com/questions/256914/macos-sierra-broke-ssh-kerberos-authentication

No answer was given, so I assume this is not a trivial issue.

Cheers.

From openssh at roumenpetrov.info  Sun Nov  6 23:29:23 2016
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Sun, 06 Nov 2016 14:29:23 +0200
Subject: OpenSSL 1.1.0 support
In-Reply-To: <0d95cbbd-99b9-e612-6ebb-893ee989831a@redhat.com>
References: <20160918182230.tflkxar45vc6xmyf@roeckx.be>
 <20161102004359.GA21575@riva.ucam.org>
 <0d95cbbd-99b9-e612-6ebb-893ee989831a@redhat.com>
Message-ID: <581F2223.4070707@roumenpetrov.info>

Jakub Jelen wrote:
> On 11/02/2016 01:43 AM, Colin Watson wrote:
>> On Sun, Sep 18, 2016 at 08:22:31PM +0200, Kurt Roeckx wrote:
>>> Attached is a patch that add supports for building against OpenSSL
>>> 1.1.0. [SNIP]

Version 9.2 of PKIX-SSH supports OpenSSL API 1.1 (final).
It was a continuous process, that stats with v8.7 that move to opaque 
structures.

There is not need to patch anything. You could get all in single source 
tarball.
Version 9.2 is compatible with OpenSSH 7.3 and include more features and 
improvements..


Regards,
Roumen Petrov

-- 
Secure shell with X.509 certificate support
http://roumenpetrov.info/secsh/


From jjelen at redhat.com  Mon Nov  7 19:26:20 2016
From: jjelen at redhat.com (Jakub Jelen)
Date: Mon, 7 Nov 2016 09:26:20 +0100
Subject: Kerberos + Openssh 6.7 issue in MacOS sierra
In-Reply-To: <CAJ22+4T483b1YctGAOgMyas3mry4zdm8SOXRZdYpODryG0gSyA@mail.gmail.com>
References: <CAJ22+4T483b1YctGAOgMyas3mry4zdm8SOXRZdYpODryG0gSyA@mail.gmail.com>
Message-ID: <4baf00c1-10f4-5632-b9a8-c795254638e4@redhat.com>

On 11/05/2016 06:58 PM, Angel Campoverde wrote:
> Hi,
>
> I hope this is the right mailing list. I upgraded to Sierra and It came
> with the new OpenSSH 6.7. When I try to get into a remote machine after
> making the kerberos ticket I get:
>
> /Users/angelcampoverde/.ssh/config: line 11: Bad configuration option:
> gssapitrustdns
> /Users/angelcampoverde/.ssh/config: terminating, 1 bad configuration options
>
> Which suggests that the line:
>
>    GSSAPIAuthentication      yes
>
> Is not supposed to be in the ~/.ssh/config file anymore. Without this line
> I cannot use kerberos to authenticate, I'd have to use the password. Is
> Kerberos not supported anymore beyond version 6.6? Is there a patch or a
> new line that should be there in that file instead of that one?
>
> Other people seem to have the same problem here:
>
> http://stackoverflow.com/questions/39634166/after-update-mac-os-sierra-can-not-use-ssh-login-remote-system-how-can-i-fix-th
>
> and here:
>
> http://apple.stackexchange.com/questions/256914/macos-sierra-broke-ssh-kerberos-authentication
>
> No answer was given, so I assume this is not a trivial issue.
The GSSAPITrustDNS was never part of portable OpenSSH [1]. This option 
originally comes from third party [2] extending kerberos support in 
OpenSSH, which is no longer maintained, but can be simply rebased on the 
current sources.
The problem in this case is Apple dropping this patch used by many 
people, so the Apple is the place where you should ask (or your OpenSSH 
packager of your favorite repository).

[1] 
https://github.com/openssh/openssh-portable/search?utf8=%E2%9C%93&q=trustdns
[2] http://www.sxw.org.uk/computing/patches/openssh.html

Regards,

-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat


From campoverdeangelf at gmail.com  Tue Nov  8 06:43:11 2016
From: campoverdeangelf at gmail.com (Angel Campoverde)
Date: Mon, 7 Nov 2016 20:43:11 +0100
Subject: Kerberos + Openssh 6.7 issue in MacOS sierra
In-Reply-To: <CAJ22+4T483b1YctGAOgMyas3mry4zdm8SOXRZdYpODryG0gSyA@mail.gmail.com>
References: <CAJ22+4T483b1YctGAOgMyas3mry4zdm8SOXRZdYpODryG0gSyA@mail.gmail.com>
Message-ID: <CAJ22+4TONLx3mMyZG6-g=w++DaVf3m2Tp75dfpNQVXLgjA9BXQ@mail.gmail.com>

Hi,

Ok, I asked the apple people. In case you want to follow it, the link is:

https://discussions.apple.com/message/30925444#30925444

Cheers.

On Sat, Nov 5, 2016 at 6:58 PM, Angel Campoverde <campoverdeangelf at gmail.com
> wrote:

> Hi,
>
> I hope this is the right mailing list. I upgraded to Sierra and It came
> with the new OpenSSH 6.7. When I try to get into a remote machine after
> making the kerberos ticket I get:
>
> /Users/angelcampoverde/.ssh/config: line 11: Bad configuration option:
> gssapitrustdns
> /Users/angelcampoverde/.ssh/config: terminating, 1 bad configuration
> options
>
> Which suggests that the line:
>
>   GSSAPIAuthentication      yes
>
> Is not supposed to be in the ~/.ssh/config file anymore. Without this line
> I cannot use kerberos to authenticate, I'd have to use the password. Is
> Kerberos not supported anymore beyond version 6.6? Is there a patch or a
> new line that should be there in that file instead of that one?
>
> Other people seem to have the same problem here:
>
> http://stackoverflow.com/questions/39634166/after-
> update-mac-os-sierra-can-not-use-ssh-login-remote-system-how-can-i-fix-th
>
> and here:
>
> http://apple.stackexchange.com/questions/256914/macos-
> sierra-broke-ssh-kerberos-authentication
>
> No answer was given, so I assume this is not a trivial issue.
>
> Cheers.
>
>

From p.pan48711 at gmail.com  Tue Nov  8 03:34:50 2016
From: p.pan48711 at gmail.com (Peter P.)
Date: Mon, 7 Nov 2016 11:34:50 -0500
Subject: Compliance with RFC5647 section 7.1 in cipher_crypt()
Message-ID: <CAPVaeBkJbYKJq21G=3S1P+dniG3m-v4X3jBrzQrg0OJFKwCYCQ@mail.gmail.com>

Hi,

I noticed in the following snippet from cipher_crypt() that the requested
value to increment the the invocation field by is one octet while section
7.1 in RFC5647 states that it should be eight. Under the covers in
OpenSSL's aes_gcm_ctrl, I see that the value passed in of 1 is ignored and
is substituted by a hard-coded 8.  If the value of arg is ever honored by
the underlying OpenSSL code, the way this is coded may cause failures when
using AES-GCM ciphers.

Should cipher_crypt be updated to increment the value by 8 instead of 1?

if (authlen)
u_char lastiv[1];
if (authlen != cipher_authlen(cc->cipher))
return SSH_ERR_INVALID_ARGUMENT;
/* increment IV */
if (!EVP_CIPHER_CTX_ctrl(cc->evp, EVP_CTRL_GCM_IV_GEN,
1, lastiv))
return SSH_ERR_LIBCRYPTO_ERROR;
*snip*

Thanks,
Peter

From reader at newsguy.com  Tue Nov  8 13:02:14 2016
From: reader at newsguy.com (Harry Putnam)
Date: Mon, 07 Nov 2016 21:02:14 -0500
Subject: one host only: ssh_dispatch_run_fatal
Message-ID: <87vavyg255.fsf@reader.local.lan>

all but one lan host (gv)can ssh connect to host 2x

Included windows 10, several linux.  2x is a solaris host.

That problem host (gv) can connect to all others but 2x.

2x can connect to all other encluding the problem host (gv)

So gv ssh to 2x throws this error:

ssh_dispatch_run_fatal: Connection to 192.168.1.42 port 22: incorrect
signature.

192.168.1.42 is 2x.  So incoming ssh from gv to 2x has the problem.

So far I have removed all ssh config and files on both hosts and
reinstalled openssh.

The problem remains

Below is the full output of ssh -vv

gv (a gentoo host) ssh to 2x (a solaris <openindian> host).

gv harry> ssh -vv 2x

OpenSSH_7.3p1-hpn14v11, OpenSSL 1.0.2j  26 Sep 2016
debug1: Reading configuration data /etc/ssh/ssh_config
Pseudo-terminal will not be allocated because stdin is not a terminal.
debug2: resolving "2x" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 2x [192.168.1.42] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/harry/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/harry/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/harry/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/harry/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/harry/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/harry/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.3p1-hpn14v11
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6
debug1: match: OpenSSH_6.6 pat OpenSSH_6.5*,OpenSSH_6.6* compat 0x14000000
debug1: Remote is NON-HPN aware
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 2x:22 as 'harry'
debug2: compat_kex_proposal: original KEX proposal: curve25519-sha256 at libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: Compat: skipping algorithm "curve25519-sha256 at libssh.org"
debug2: compat_kex_proposal: compat KEX proposal: diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug1: AUTH STATE IS 0
debug2: local client KEXINIT proposal
debug2: KEX algorithms: diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ssh-ed25519-cert-v01 at openssh.com,ssh-ed25519,ssh-rsa-cert-v01 at openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib at openssh.com,zlib
debug2: compression stoc: none,zlib at openssh.com,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se
debug2: MACs ctos: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none,zlib at openssh.com
debug2: compression stoc: none,zlib at openssh.com
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: REQUESTED ENC.NAME is 'chacha20-poly1305 at openssh.com'
debug1: kex: server->client cipher: chacha20-poly1305 at openssh.com MAC: <implicit> compression: none
debug1: REQUESTED ENC.NAME is 'chacha20-poly1305 at openssh.com'
debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com MAC: <implicit> compression: none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<8192<8192) sent
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug2: bits set: 4070/8192
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: ssh-ed25519 SHA256:fDVJdFDNtnMrobEPdtuoLTTTXju1T+V+aKRGdI5Yook
debug1: Host '2x' is known and matches the ED25519 host key.
debug1: Found key in /home/harry/.ssh/known_hosts:2
debug2: bits set: 4134/8192
debug2: ssh_ed25519_verify: crypto_sign_ed25519_open failed: -1
ssh_dispatch_run_fatal: Connection to 192.168.1.42 port 22: incorrect signature




From dtucker at zip.com.au  Tue Nov  8 13:53:05 2016
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 8 Nov 2016 13:53:05 +1100
Subject: one host only: ssh_dispatch_run_fatal
In-Reply-To: <87vavyg255.fsf@reader.local.lan>
References: <87vavyg255.fsf@reader.local.lan>
Message-ID: <CALDDTe01W0jfVKo50p+iifhqkNKZm7iUPHD206CB6Mq6+4U7YQ@mail.gmail.com>

On Tue, Nov 8, 2016 at 1:02 PM, Harry Putnam <reader at newsguy.com> wrote:
[...]
> gv harry> ssh -vv 2x
>
> OpenSSH_7.3p1-hpn14v11, OpenSSL 1.0.2j  26 Sep 2016

this is a third-party modified version of OpenSSH.  Can you reproduce
the problem with a stock OpenSSH from the source from openssh.com?

> debug1: match: OpenSSH_6.6 pat OpenSSH_6.5*,OpenSSH_6.6* compat 0x14000000

OpenSSH 6.6 has a bug in curve25519-sha256 at libssh.org, which is the
kex method later selected.

Quoting the 6.7 release notes: https://www.openssh.com/releasenotes.html#6.7
"""
 * OpenSSH 6.5 and 6.6 have a bug that causes ~0.2% of connections
   using the curve25519-sha256 at libssh.org KEX exchange method to fail
   when connecting with something that implements the specification
   correctly. OpenSSH 6.7 disables this KEX method when speaking to
   one of the affected versions.
"""

> debug1: kex: host key algorithm: ssh-ed25519
[...]
> debug1: Found key in /home/harry/.ssh/known_hosts:2
> debug2: bits set: 4134/8192
> debug2: ssh_ed25519_verify: crypto_sign_ed25519_open failed: -1
> ssh_dispatch_run_fatal: Connection to 192.168.1.42 port 22: incorrect signature

Maybe the same bug also affects ed25519 as a host key algorithm?  If
so, setting HostKeyAlgorithms in ssh_config on the client to something
that doesn't include ssh-ed25519 might help.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From reader at newsguy.com  Tue Nov  8 14:43:10 2016
From: reader at newsguy.com (Harry Putnam)
Date: Mon, 07 Nov 2016 22:43:10 -0500
Subject: one host only: ssh_dispatch_run_fatal
References: <87vavyg255.fsf@reader.local.lan>
 <CALDDTe01W0jfVKo50p+iifhqkNKZm7iUPHD206CB6Mq6+4U7YQ@mail.gmail.com>
Message-ID: <87k2cefxgx.fsf@reader.local.lan>

Darren Tucker <dtucker at zip.com.au> writes:

> On Tue, Nov 8, 2016 at 1:02 PM, Harry Putnam <reader at newsguy.com> wrote:
> [...]
>> gv harry> ssh -vv 2x
>>
>> OpenSSH_7.3p1-hpn14v11, OpenSSL 1.0.2j  26 Sep 2016
>
> this is a third-party modified version of OpenSSH.  Can you reproduce
> the problem with a stock OpenSSH from the source from openssh.com?

Well, since I'm not on a BSD system... <on gentoo linux> and since the
instructions in the README file:

To extract and install this release on your OpenBSD system use:

      # cd /usr/src/usr.bin
      # tar xvfz .../openssh-x.y.tgz
      # cd ssh
      # make obj
      # make cleandir
      # make depend
      # make
      # make install
      # cp ssh_config sshd_config /etc/ssh

And since there appear to be no other helpful files... I guess mucking
around with it and pounding thru google for a hour or two are a little
above my paygrade... not to mention skill level.... I guess not.

What I am doing is backup down to version 7.2 and compiling on gentoo
system. ... will report back.

I can say that 3 Debian systems running verion 6.7 have no problem
connecting to that same host.



From reader at newsguy.com  Tue Nov  8 14:46:12 2016
From: reader at newsguy.com (Harry Putnam)
Date: Mon, 07 Nov 2016 22:46:12 -0500
Subject: one host only: ssh_dispatch_run_fatal
References: <87vavyg255.fsf@reader.local.lan>
 <CALDDTe01W0jfVKo50p+iifhqkNKZm7iUPHD206CB6Mq6+4U7YQ@mail.gmail.com>
Message-ID: <87d1i6fxbv.fsf@reader.local.lan>

Darren Tucker <dtucker at zip.com.au> writes:

> On Tue, Nov 8, 2016 at 1:02 PM, Harry Putnam <reader at newsguy.com> wrote:
> [...]
>> gv harry> ssh -vv 2x
>>
>> OpenSSH_7.3p1-hpn14v11, OpenSSL 1.0.2j  26 Sep 2016
>
> this is a third-party modified version of OpenSSH.  Can you reproduce
> the problem with a stock OpenSSH from the source from openssh.com?

I can report that gentoo's version 7.2 probably also with some kind of
3rd party changes.... also fails in the same way.


From dtucker at zip.com.au  Tue Nov  8 14:58:17 2016
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 8 Nov 2016 14:58:17 +1100
Subject: one host only: ssh_dispatch_run_fatal
In-Reply-To: <87k2cefxgx.fsf@reader.local.lan>
References: <87vavyg255.fsf@reader.local.lan>
 <CALDDTe01W0jfVKo50p+iifhqkNKZm7iUPHD206CB6Mq6+4U7YQ@mail.gmail.com>
 <87k2cefxgx.fsf@reader.local.lan>
Message-ID: <CALDDTe2MfsLjSnqzK8RWizaXT4YgoviXFLS-g_jSVGZqyZid1Q@mail.gmail.com>

On Tue, Nov 8, 2016 at 2:43 PM, Harry Putnam <reader at newsguy.com> wrote:
> Darren Tucker <dtucker at zip.com.au> writes:
>
>> On Tue, Nov 8, 2016 at 1:02 PM, Harry Putnam <reader at newsguy.com> wrote:
>> [...]
>>> gv harry> ssh -vv 2x
>>>
>>> OpenSSH_7.3p1-hpn14v11, OpenSSL 1.0.2j  26 Sep 2016
>>
>> this is a third-party modified version of OpenSSH.  Can you reproduce
>> the problem with a stock OpenSSH from the source from openssh.com?
>
> Well, since I'm not on a BSD system... <on gentoo linux> and since the
> instructions in the README file:

Well you could click on the  "For other OS's: Linux Solaris..." link
on the main page which would take you to
https://www.openssh.com/portable.html, which has installation
instructions and links to the portable version of the source (which
has an autoconf-style configure file).

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From reader at newsguy.com  Tue Nov  8 14:56:15 2016
From: reader at newsguy.com (Harry Putnam)
Date: Mon, 07 Nov 2016 22:56:15 -0500
Subject: one host only: ssh_dispatch_run_fatal
References: <87vavyg255.fsf@reader.local.lan>
 <CALDDTe01W0jfVKo50p+iifhqkNKZm7iUPHD206CB6Mq6+4U7YQ@mail.gmail.com>
Message-ID: <877f8efwv4.fsf@reader.local.lan>

Darren Tucker <dtucker at zip.com.au> writes:

> On Tue, Nov 8, 2016 at 1:02 PM, Harry Putnam <reader at newsguy.com> wrote:
> [...]
>> gv harry> ssh -vv 2x
>>
>> OpenSSH_7.3p1-hpn14v11, OpenSSL 1.0.2j  26 Sep 2016
>
> this is a third-party modified version of OpenSSH.  Can you reproduce
> the problem with a stock OpenSSH from the source from openssh.com?

I found a comment somewhere that explained that I needed the portable
version. ... got that building right now so may have something shortly


From reader at newsguy.com  Tue Nov  8 15:03:57 2016
From: reader at newsguy.com (Harry Putnam)
Date: Mon, 07 Nov 2016 23:03:57 -0500
Subject: one host only: ssh_dispatch_run_fatal
References: <87vavyg255.fsf@reader.local.lan>
 <CALDDTe01W0jfVKo50p+iifhqkNKZm7iUPHD206CB6Mq6+4U7YQ@mail.gmail.com>
 <87k2cefxgx.fsf@reader.local.lan>
 <CALDDTe2MfsLjSnqzK8RWizaXT4YgoviXFLS-g_jSVGZqyZid1Q@mail.gmail.com>
Message-ID: <8737j2fwia.fsf@reader.local.lan>

Darren Tucker <dtucker at zip.com.au> writes:

> On Tue, Nov 8, 2016 at 2:43 PM, Harry Putnam <reader at newsguy.com> wrote:
>> Darren Tucker <dtucker at zip.com.au> writes:
>>
>>> On Tue, Nov 8, 2016 at 1:02 PM, Harry Putnam <reader at newsguy.com> wrote:
>>> [...]
>>>> gv harry> ssh -vv 2x
>>>>
>>>> OpenSSH_7.3p1-hpn14v11, OpenSSL 1.0.2j  26 Sep 2016
>>>
>>> this is a third-party modified version of OpenSSH.  Can you reproduce
>>> the problem with a stock OpenSSH from the source from openssh.com?
>>
>> Well, since I'm not on a BSD system... <on gentoo linux> and since the
>> instructions in the README file:
>
> Well you could click on the  "For other OS's: Linux Solaris..." link
> on the main page which would take you to
> https://www.openssh.com/portable.html, which has installation
> instructions and links to the portable version of the source (which
> has an autoconf-style configure file).

Thanks, yes. I got past the boneheaded part and got the right thing
downloaded ... building now.


From reader at newsguy.com  Tue Nov  8 15:08:39 2016
From: reader at newsguy.com (Harry Putnam)
Date: Mon, 07 Nov 2016 23:08:39 -0500
Subject: one host only: ssh_dispatch_run_fatal
References: <87vavyg255.fsf@reader.local.lan>
 <CALDDTe01W0jfVKo50p+iifhqkNKZm7iUPHD206CB6Mq6+4U7YQ@mail.gmail.com>
 <87k2cefxgx.fsf@reader.local.lan>
 <CALDDTe2MfsLjSnqzK8RWizaXT4YgoviXFLS-g_jSVGZqyZid1Q@mail.gmail.com>
Message-ID: <87y40uehq0.fsf@reader.local.lan>

Darren Tucker <dtucker at zip.com.au> writes:

> On Tue, Nov 8, 2016 at 2:43 PM, Harry Putnam <reader at newsguy.com> wrote:
>> Darren Tucker <dtucker at zip.com.au> writes:
>>
>>> On Tue, Nov 8, 2016 at 1:02 PM, Harry Putnam <reader at newsguy.com> wrote:
>>> [...]
>>>> gv harry> ssh -vv 2x
>>>>
>>>> OpenSSH_7.3p1-hpn14v11, OpenSSL 1.0.2j  26 Sep 2016
>>>
>>> this is a third-party modified version of OpenSSH.  Can you reproduce
>>> the problem with a stock OpenSSH from the source from openssh.com?
>>
>> Well, since I'm not on a BSD system... <on gentoo linux> and since the
>> instructions in the README file:
>
> Well you could click on the  "For other OS's: Linux Solaris..." link
> on the main page which would take you to
> https://www.openssh.com/portable.html, which has installation
> instructions and links to the portable version of the source (which
> has an autoconf-style configure file).

After kicking myself a few times for not catching on earlier... I
built the right version and am sorry to say that it fails with the
same error.

gv harry > ssh -vv 2x

OpenSSH_7.3p1, OpenSSL 1.0.2j  26 Sep 2016
debug1: Reading configuration data /usr/local/src/test/etc/ssh_config
Pseudo-terminal will not be allocated because stdin is not a terminal.
debug2: resolving "2x" port 22
debug2: ssh_connect_direct: needpriv 0
debug1: Connecting to 2x [192.168.1.42] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/harry/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/harry/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/harry/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/harry/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/harry/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/harry/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_7.3
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6
debug1: match: OpenSSH_6.6 pat OpenSSH_6.5*,OpenSSH_6.6* compat 0x14000000
debug2: fd 3 setting O_NONBLOCK
debug1: Authenticating to 2x:22 as 'harry'
debug2: compat_kex_proposal: original KEX proposal: curve25519-sha256 at libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: Compat: skipping algorithm "curve25519-sha256 at libssh.org"
debug2: compat_kex_proposal: compat KEX proposal: diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: local client KEXINIT proposal
debug2: KEX algorithms: diffie-hellman-group-exchange-sha256,diffie-hellman-group16-sha512,diffie-hellman-group18-sha512,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha256,diffie-hellman-group14-sha1,ext-info-c
debug2: host key algorithms: ssh-ed25519-cert-v01 at openssh.com,ssh-ed25519,ssh-rsa-cert-v01 at openssh.com,rsa-sha2-512,rsa-sha2-256,ssh-rsa
debug2: ciphers ctos: chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: ciphers stoc: chacha20-poly1305 at openssh.com,aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com,aes128-cbc,aes192-cbc,aes256-cbc,3des-cbc
debug2: MACs ctos: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: MACs stoc: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1
debug2: compression ctos: none,zlib at openssh.com,zlib
debug2: compression stoc: none,zlib at openssh.com,zlib
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug2: peer server KEXINIT proposal
debug2: KEX algorithms: curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: host key algorithms: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: ciphers ctos: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se
debug2: ciphers stoc: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se
debug2: MACs ctos: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: MACs stoc: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: compression ctos: none,zlib at openssh.com
debug2: compression stoc: none,zlib at openssh.com
debug2: languages ctos: 
debug2: languages stoc: 
debug2: first_kex_follows 0 
debug2: reserved 0 
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305 at openssh.com MAC: <implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com MAC: <implicit> compression: none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(2048<8192<8192) sent
debug1: got SSH2_MSG_KEX_DH_GEX_GROUP
debug2: bits set: 4084/8192
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: got SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: ssh-ed25519 SHA256:fDVJdFDNtnMrobEPdtuoLTTTXju1T+V+aKRGdI5Yook
debug1: Host '2x' is known and matches the ED25519 host key.
debug1: Found key in /home/harry/.ssh/known_hosts:2
debug2: bits set: 4098/8192
debug2: ssh_ed25519_verify: crypto_sign_ed25519_open failed: -1
ssh_dispatch_run_fatal: Connection to 192.168.1.42 port 22: incorrect signature


From reader at newsguy.com  Tue Nov  8 15:30:09 2016
From: reader at newsguy.com (Harry Putnam)
Date: Mon, 07 Nov 2016 23:30:09 -0500
Subject: one host only: ssh_dispatch_run_fatal
References: <87vavyg255.fsf@reader.local.lan>
 <CALDDTe01W0jfVKo50p+iifhqkNKZm7iUPHD206CB6Mq6+4U7YQ@mail.gmail.com>
 <87k2cefxgx.fsf@reader.local.lan>
 <CALDDTe2MfsLjSnqzK8RWizaXT4YgoviXFLS-g_jSVGZqyZid1Q@mail.gmail.com>
Message-ID: <87twbiegq6.fsf@reader.local.lan>

Darren Tucker <dtucker at zip.com.au> writes:

> On Tue, Nov 8, 2016 at 2:43 PM, Harry Putnam <reader at newsguy.com> wrote:
>> Darren Tucker <dtucker at zip.com.au> writes:
>>
>>> On Tue, Nov 8, 2016 at 1:02 PM, Harry Putnam <reader at newsguy.com> wrote:
>>> [...]
>>>> gv harry> ssh -vv 2x
>>>>
>>>> OpenSSH_7.3p1-hpn14v11, OpenSSL 1.0.2j  26 Sep 2016
>>>
>>> this is a third-party modified version of OpenSSH.  Can you reproduce
>>> the problem with a stock OpenSSH from the source from openssh.com?
>>
>> Well, since I'm not on a BSD system... <on gentoo linux> and since the
>> instructions in the README file:
>
> Well you could click on the  "For other OS's: Linux Solaris..." link
> on the main page which would take you to
> https://www.openssh.com/portable.html, which has installation
> instructions and links to the portable version of the source (which
> has an autoconf-style configure file).

After having 7.3p1 & 6.8p1 fail with same wording... I tried 6.7p1 and
find it fails with what looks like the same problem but has slightly
different wording.

version 6.7_p1

gv harry > ssh -vv 2x

OpenSSH_6.7p1, OpenSSL 1.0.2j  26 Sep 2016
debug1: Reading configuration data /usr/local/src/test/etc/ssh_config
Pseudo-terminal will not be allocated because stdin is not a terminal.
debug2: ssh_connect: needpriv 0
debug1: Connecting to 2x [192.168.1.42] port 22.
debug1: Connection established.
debug1: key_load_public: No such file or directory
debug1: identity file /home/harry/.ssh/id_rsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/harry/.ssh/id_rsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/harry/.ssh/id_dsa type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/harry/.ssh/id_dsa-cert type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/harry/.ssh/id_ed25519 type -1
debug1: key_load_public: No such file or directory
debug1: identity file /home/harry/.ssh/id_ed25519-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.7
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6
debug1: match: OpenSSH_6.6 pat OpenSSH_6.5*,OpenSSH_6.6* compat 0x14000000
debug2: fd 3 setting O_NONBLOCK
debug2: compat_kex_proposal: original KEX proposal: curve25519-sha256 at libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: Compat: skipping algorithm "curve25519-sha256 at libssh.org"
debug2: compat_kex_proposal: compat KEX proposal: diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-ed25519-cert-v01 at openssh.com,ssh-ed25519,ssh-rsa-cert-v01 at openssh.com,ssh-dss-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-dss-cert-v00 at openssh.com,ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-sha1,hmac-md5-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib at openssh.com
debug2: kex_parse_kexinit: none,zlib at openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: setup umac-64-etm at openssh.com
debug1: kex: server->client aes128-ctr umac-64-etm at openssh.com none
debug2: mac_setup: setup umac-64-etm at openssh.com
debug1: kex: client->server aes128-ctr umac-64-etm at openssh.com none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: bits set: 1494/3072
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: ED25519 99:b7:1c:6d:1f:ce:dd:7f:37:a4:a2:34:56:32:18:f1
debug1: Host '2x' is known and matches the ED25519 host key.
debug1: Found key in /home/harry/.ssh/known_hosts:2
debug2: bits set: 1574/3072
debug2: ssh_ed25519_verify: crypto_sign_ed25519_open failed: -1
key_verify: incorrect signature
key_verify failed for server_host_key


From reader at newsguy.com  Tue Nov  8 15:43:26 2016
From: reader at newsguy.com (Harry Putnam)
Date: Mon, 07 Nov 2016 23:43:26 -0500
Subject: one host only: ssh_dispatch_run_fatal
References: <87vavyg255.fsf@reader.local.lan>
 <CALDDTe01W0jfVKo50p+iifhqkNKZm7iUPHD206CB6Mq6+4U7YQ@mail.gmail.com>
 <87k2cefxgx.fsf@reader.local.lan>
 <CALDDTe2MfsLjSnqzK8RWizaXT4YgoviXFLS-g_jSVGZqyZid1Q@mail.gmail.com>
 <87twbiegq6.fsf@reader.local.lan>
Message-ID: <87pom6eg41.fsf@reader.local.lan>

> Darren Tucker <dtucker at zip.com.au> writes:
>
>> On Tue, Nov 8, 2016 at 2:43 PM, Harry Putnam <reader at newsguy.com> wrote:
>>> Darren Tucker <dtucker at zip.com.au> writes:
>>>
>>>> On Tue, Nov 8, 2016 at 1:02 PM, Harry Putnam <reader at newsguy.com> wrote:
>>>> [...]
>>>>> gv harry> ssh -vv 2x
>>>>>
>>>>> OpenSSH_7.3p1-hpn14v11, OpenSSL 1.0.2j  26 Sep 2016
>>>>
>>>> this is a third-party modified version of OpenSSH.  Can you reproduce
>>>> the problem with a stock OpenSSH from the source from openssh.com?
>>>
>>> Well, since I'm not on a BSD system... <on gentoo linux> and since the
>>> instructions in the README file:
>>
>> Well you could click on the  "For other OS's: Linux Solaris..." link
>> on the main page which would take you to
>> https://www.openssh.com/portable.html, which has installation
>> instructions and links to the portable version of the source (which
>> has an autoconf-style configure file).
>
> After having 7.3p1 & 6.8p1 fail with same wording... I tried 6.7p1 and
> find it fails with what looks like the same problem but has slightly
> different wording.

finally hit paydirt with version 6.4  did not try 6.5 and 6.6 but I
can report that 6.4 works in my situation with no config
fidling... just right out of the build:

OpenSSH_6.4, OpenSSL 1.0.2j  26 Sep 2016
debug1: Reading configuration data /usr/local/src/test/etc/ssh_config
debug2: ssh_connect: needpriv 0
debug1: Connecting to 2x [192.168.1.42] port 22.
debug1: Connection established.
debug1: identity file /home/harry/.ssh/id_rsa type -1
debug1: identity file /home/harry/.ssh/id_rsa-cert type -1
debug1: identity file /home/harry/.ssh/id_dsa type -1
debug1: identity file /home/harry/.ssh/id_dsa-cert type -1
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-OpenSSH_6.4
debug1: Remote protocol version 2.0, remote software version OpenSSH_6.6
debug1: match: OpenSSH_6.6 pat OpenSSH*
debug2: fd 3 setting O_NONBLOCK
debug2: key_type_from_name: unknown key type 'ssh-ed25519'
debug1: SSH2_MSG_KEXINIT sent
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa-cert-v01 at openssh.com,ssh-rsa-cert-v00 at openssh.com,ssh-rsa,ssh-dss-cert-v01 at openssh.com,ssh-dss-cert-v00 at openssh.com,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib
debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: kex_parse_kexinit: curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se
debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib at openssh.com
debug2: kex_parse_kexinit: none,zlib at openssh.com
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: 
debug2: kex_parse_kexinit: first_kex_follows 0 
debug2: kex_parse_kexinit: reserved 0 
debug2: mac_setup: found hmac-md5-etm at openssh.com
debug1: kex: server->client aes128-ctr hmac-md5-etm at openssh.com none
debug2: mac_setup: found hmac-md5-etm at openssh.com
debug1: kex: client->server aes128-ctr hmac-md5-etm at openssh.com none
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP
debug2: dh_gen_key: priv key bits set: 129/256
debug2: bits set: 547/1024
debug1: SSH2_MSG_KEX_DH_GEX_INIT sent
debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY
debug1: Server host key: RSA 5d:29:99:eb:9e:c9:d3:59:bd:16:62:76:19:17:1d:67
debug2: key_type_from_name: unknown key type 'ssh-ed25519'
debug2: key_type_from_name: unknown key type 'ssh-ed25519'
debug1: Host '2x' is known and matches the RSA host key.
debug1: Found key in /home/harry/.ssh/known_hosts:3
debug2: bits set: 519/1024
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug2: set_newkeys: mode 1
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug2: set_newkeys: mode 0
debug1: SSH2_MSG_NEWKEYS received
debug1: Roaming not allowed by server
debug1: SSH2_MSG_SERVICE_REQUEST sent
debug2: service_accept: ssh-userauth
debug1: SSH2_MSG_SERVICE_ACCEPT received
debug2: key: /home/harry/.ssh/id_rsa ((nil)),
debug2: key: /home/harry/.ssh/id_dsa ((nil)),
debug1: Authentications that can continue: publickey,password,keyboard-interactive
debug1: Next authentication method: publickey
debug1: Trying private key: /home/harry/.ssh/id_rsa
debug1: Trying private key: /home/harry/.ssh/id_dsa
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password: 

   BINGO...



From dtucker at zip.com.au  Tue Nov  8 15:51:16 2016
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 8 Nov 2016 15:51:16 +1100
Subject: one host only: ssh_dispatch_run_fatal
In-Reply-To: <87twbiegq6.fsf@reader.local.lan>
References: <87vavyg255.fsf@reader.local.lan>
 <CALDDTe01W0jfVKo50p+iifhqkNKZm7iUPHD206CB6Mq6+4U7YQ@mail.gmail.com>
 <87k2cefxgx.fsf@reader.local.lan>
 <CALDDTe2MfsLjSnqzK8RWizaXT4YgoviXFLS-g_jSVGZqyZid1Q@mail.gmail.com>
 <87twbiegq6.fsf@reader.local.lan>
Message-ID: <CALDDTe1381d__eScDE5ddNaMLU=ZJXCeHjSSQJYFNxMsPSuTaA@mail.gmail.com>

On Tue, Nov 8, 2016 at 3:30 PM, Harry Putnam <reader at newsguy.com> wrote:
[...]
> After having 7.3p1 & 6.8p1 fail with same wording... I tried 6.7p1 and
> find it fails with what looks like the same problem but has slightly
> different wording.

I set up the same versions (server:OpenSSH_6.6p1, OpenSSL 1.0.1s  1
Mar 2016, client: OpenSSH_7.3p1, OpenSSL 1.0.1s  1 Mar 2016) on Linux
to try to reproduce it but failed.

./ssh -p 2022 -vvv -o ciphers=chacha20-poly1305 at openssh.com -o
kexalgorithms=diffie-hellman-group-exchange-sha256 localhost
[...]
debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
debug1: kex: host key algorithm: ssh-ed25519
debug1: kex: server->client cipher: chacha20-poly1305 at openssh.com MAC:
<implicit> compression: none
debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com MAC:
<implicit> compression: none

Can you tell me more about the server?  You said it's Solaris, but is
it SPARC or x86?  What OpenSSL version is it?

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From dtucker at zip.com.au  Tue Nov  8 15:55:33 2016
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 8 Nov 2016 15:55:33 +1100
Subject: one host only: ssh_dispatch_run_fatal
In-Reply-To: <87pom6eg41.fsf@reader.local.lan>
References: <87vavyg255.fsf@reader.local.lan>
 <CALDDTe01W0jfVKo50p+iifhqkNKZm7iUPHD206CB6Mq6+4U7YQ@mail.gmail.com>
 <87k2cefxgx.fsf@reader.local.lan>
 <CALDDTe2MfsLjSnqzK8RWizaXT4YgoviXFLS-g_jSVGZqyZid1Q@mail.gmail.com>
 <87twbiegq6.fsf@reader.local.lan> <87pom6eg41.fsf@reader.local.lan>
Message-ID: <CALDDTe2f9_3TAJ51Hf88QZS5rq24Scii91T106etfN58OMLJjQ@mail.gmail.com>

On Tue, Nov 8, 2016 at 3:43 PM, Harry Putnam <reader at newsguy.com> wrote:
[...]
> finally hit paydirt with version 6.4  did not try 6.5 and 6.6 but I
> can report that 6.4 works in my situation with no config
> fidling... just right out of the build:
[....]
> debug2: key_type_from_name: unknown key type 'ssh-ed25519'
> debug2: key_type_from_name: unknown key type 'ssh-ed25519'
> debug1: Host '2x' is known and matches the RSA host key.

That's because the 6.4 client doesn't do the problematic ssh-ed25519
host key algorithm.  You'll probably see  the same thing with the
newer clients if you set HostKeyAlgorithms in the client's ssh_config
like I suggested in my first reply (or remove/rename the ed25519 host
key file on the server, I think that version is before you could set
HostKeyAlgorithms).

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From reader at newsguy.com  Wed Nov  9 00:02:12 2016
From: reader at newsguy.com (Harry Putnam)
Date: Tue, 08 Nov 2016 08:02:12 -0500
Subject: one host only: ssh_dispatch_run_fatal
References: <87vavyg255.fsf@reader.local.lan>
 <CALDDTe01W0jfVKo50p+iifhqkNKZm7iUPHD206CB6Mq6+4U7YQ@mail.gmail.com>
 <87k2cefxgx.fsf@reader.local.lan>
 <CALDDTe2MfsLjSnqzK8RWizaXT4YgoviXFLS-g_jSVGZqyZid1Q@mail.gmail.com>
 <87twbiegq6.fsf@reader.local.lan>
 <CALDDTe1381d__eScDE5ddNaMLU=ZJXCeHjSSQJYFNxMsPSuTaA@mail.gmail.com>
Message-ID: <87bmxqdt0r.fsf@reader.local.lan>

Darren Tucker <dtucker at zip.com.au> writes:

> On Tue, Nov 8, 2016 at 3:30 PM, Harry Putnam <reader at newsguy.com> wrote:
> [...]
>> After having 7.3p1 & 6.8p1 fail with same wording... I tried 6.7p1 and
>> find it fails with what looks like the same problem but has slightly
>> different wording.
>
> I set up the same versions (server:OpenSSH_6.6p1, OpenSSL 1.0.1s  1
> Mar 2016, client: OpenSSH_7.3p1, OpenSSL 1.0.1s  1 Mar 2016) on Linux
> to try to reproduce it but failed.
>
> ./ssh -p 2022 -vvv -o ciphers=chacha20-poly1305 at openssh.com -o
> kexalgorithms=diffie-hellman-group-exchange-sha256 localhost
> [...]
> debug1: kex: algorithm: diffie-hellman-group-exchange-sha256
> debug1: kex: host key algorithm: ssh-ed25519
> debug1: kex: server->client cipher: chacha20-poly1305 at openssh.com MAC:
> <implicit> compression: none
> debug1: kex: client->server cipher: chacha20-poly1305 at openssh.com MAC:
> <implicit> compression: none

>From another post Darren Tucker wrote:

> > That's because the 6.4 client doesn't do the problematic
> > ssh-ed25519 host key algorithm.  You'll probably see the same
> > thing with the newer clients if you set HostKeyAlgorithms in the
> > client's ssh_config like I suggested in my first reply (or
> > remove/rename the ed25519 host key file on the server, I think
> > that version is before you could set HostKeyAlgorithms).

I'm sorry if by not doing that I tied you up in this thread but I did
not understand how that would be done.

> Can you tell me more about the server?  You said it's Solaris, but is
> it SPARC or x86?  What OpenSSL version is it?

x86

uname -a SunOS 2x 5.11 oi_151a9 i86pc i386 i86pc

It is an off shoot of Oracle Solaris named openindiana.

Running OpenSSH_6.6, OpenSSL 1.0.1u  22 Sep 2016.

Provided from the OpenCSW project that builds some solaris pkgs.

The last line of sshd_config must be the killer:
  `kexAlgorithms diffie-hellman-group-exchange-sha1'

# grep -v '^#\|^$' /etc/ssh/sshd_config
Protocol 2
Port 22
ListenAddress ::
GatewayPorts no
X11Forwarding yes
X11DisplayOffset 10
X11UseLocalhost yes
PrintMotd no
KeepAlive yes
SyslogFacility auth
LogLevel info
HostKey /etc/ssh/ssh_host_rsa_key
HostKey /etc/ssh/ssh_host_dsa_key
ServerKeyBits 768
KeyRegenerationInterval 3600
StrictModes yes
LoginGraceTime 600
MaxAuthTries    6
MaxAuthTriesLog 3
PermitEmptyPasswords no
PasswordAuthentication yes
PermitRootLogin yes
Subsystem       sftp    internal-sftp
IgnoreRhosts yes
RhostsAuthentication no
RhostsRSAAuthentication no
RSAAuthentication yes
kexAlgorithms diffie-hellman-group-exchange-sha1

-------       -------       ---=---       -------       -------

Now having reinstalled ssh-7.3p1-r7 with gentoo's build patches
and with the:
  `kexAlgorithms diffie-hellman-group-exchange-sha1'

Line removed It all works.
Does seem odd that several other ssh 6.6p1 on the lan had no trouble
connecting to 2x even with the kexAlgorithms line in its config.

Sorry about the line noise . . .

gv harry > ssh -vv 2x

OpenSSH_7.3p1-hpn14v11, OpenSSL 1.0.2j  26 Sep 2016

[...]

debug1: Next authentication method: publickey
debug1: Trying private key: /home/harry/.ssh/id_rsa
debug1: Trying private key: /home/harry/.ssh/id_dsa
debug1: Trying private key: /home/harry/.ssh/id_ed25519
debug2: we did not send a packet, disable method
debug1: Next authentication method: keyboard-interactive
debug2: userauth_kbdint
debug2: we sent a keyboard-interactive packet, wait for reply
debug2: input_userauth_info_req
debug2: input_userauth_info_req: num_prompts 1
Password


From dtucker at zip.com.au  Wed Nov  9 09:01:29 2016
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 9 Nov 2016 09:01:29 +1100
Subject: one host only: ssh_dispatch_run_fatal
In-Reply-To: <87bmxqdt0r.fsf@reader.local.lan>
References: <87vavyg255.fsf@reader.local.lan>
 <CALDDTe01W0jfVKo50p+iifhqkNKZm7iUPHD206CB6Mq6+4U7YQ@mail.gmail.com>
 <87k2cefxgx.fsf@reader.local.lan>
 <CALDDTe2MfsLjSnqzK8RWizaXT4YgoviXFLS-g_jSVGZqyZid1Q@mail.gmail.com>
 <87twbiegq6.fsf@reader.local.lan>
 <CALDDTe1381d__eScDE5ddNaMLU=ZJXCeHjSSQJYFNxMsPSuTaA@mail.gmail.com>
 <87bmxqdt0r.fsf@reader.local.lan>
Message-ID: <CALDDTe2hQ+PTMVjOWoFG9s8FGfP1KTs4gD+qD0BxVidAvykrhw@mail.gmail.com>

On Wed, Nov 9, 2016 at 12:02 AM, Harry Putnam <reader at newsguy.com> wrote:
> Darren Tucker <dtucker at zip.com.au> writes:
[...]
>> Can you tell me more about the server?  You said it's Solaris, but is
>> it SPARC or x86?  What OpenSSL version is it?
> uname -a SunOS 2x 5.11 oi_151a9 i86pc i386 i86pc
[...]
> Running OpenSSH_6.6, OpenSSL 1.0.1u  22 Sep 2016.

I built my 6.6p1 with OpenSSL 1.0.1u but still failed to reproduce the problem.

> Provided from the OpenCSW project that builds some solaris pkgs.
>
> The last line of sshd_config must be the killer:
>   `kexAlgorithms diffie-hellman-group-exchange-sha1'

diffie-hellman-group-exchange-sha1 is one of the oldest kex methods
(>10 years) so I'm surprised that it is related to the problem.

There's still a problem in there somewhere, but at this stage I have
no idea where it is (openssh, openssl, libraries, compiler,
toolchain...)

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From reader at newsguy.com  Wed Nov  9 11:34:18 2016
From: reader at newsguy.com (Harry Putnam)
Date: Tue, 08 Nov 2016 19:34:18 -0500
Subject: one host only: ssh_dispatch_run_fatal
References: <87vavyg255.fsf@reader.local.lan>
 <CALDDTe01W0jfVKo50p+iifhqkNKZm7iUPHD206CB6Mq6+4U7YQ@mail.gmail.com>
 <87k2cefxgx.fsf@reader.local.lan>
 <CALDDTe2MfsLjSnqzK8RWizaXT4YgoviXFLS-g_jSVGZqyZid1Q@mail.gmail.com>
 <87twbiegq6.fsf@reader.local.lan>
 <CALDDTe1381d__eScDE5ddNaMLU=ZJXCeHjSSQJYFNxMsPSuTaA@mail.gmail.com>
 <87bmxqdt0r.fsf@reader.local.lan>
 <CALDDTe2hQ+PTMVjOWoFG9s8FGfP1KTs4gD+qD0BxVidAvykrhw@mail.gmail.com>
Message-ID: <87fun1v6d1.fsf@reader.local.lan>

Darren Tucker <dtucker at zip.com.au> writes:

> On Wed, Nov 9, 2016 at 12:02 AM, Harry Putnam <reader at newsguy.com> wrote:
>> Darren Tucker <dtucker at zip.com.au> writes:
> [...]
>>> Can you tell me more about the server?  You said it's Solaris, but is
>>> it SPARC or x86?  What OpenSSL version is it?
>> uname -a SunOS 2x 5.11 oi_151a9 i86pc i386 i86pc
> [...]
>> Running OpenSSH_6.6, OpenSSL 1.0.1u  22 Sep 2016.
>
> I built my 6.6p1 with OpenSSL 1.0.1u but still failed to reproduce the problem.
>
>> Provided from the OpenCSW project that builds some solaris pkgs.
>>
>> The last line of sshd_config must be the killer:
>>   `kexAlgorithms diffie-hellman-group-exchange-sha1'
>
> diffie-hellman-group-exchange-sha1 is one of the oldest kex methods
> (>10 years) so I'm surprised that it is related to the problem.
>
> There's still a problem in there somewhere, but at this stage I have
> no idea where it is (openssh, openssl, libraries, compiler,
> toolchain...)

I kind of hid some info in the message you are replying to above, below
the ssh -vv output.  Maybe you didn't notice it.

After removing the diffie hellman line, (it was not in the sshd_config
as installled but something I had added way back)I was able to return
to 7.3_p1-r7 the gentoo monified version that started this thread with
no problems at all.

So for the benefit of any searchers who stumble across this thread,
removing that line seems to have removed the problem that was causing
my gentoo host to fail when connecting to my solaris host.

Now, I'm back where all lan hosts can talk to each other over ssh.

Thanks for helping me sort that out... I've been hassling with it for
a good while, and probably would have continued to stumble around a
good while longer without your clear thinking and guidance.


From alon.barlev at gmail.com  Sun Nov 13 10:25:17 2016
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Sun, 13 Nov 2016 01:25:17 +0200
Subject: [DOC] ssh_config.5 - RemoteForward,
 LocalForward missing unix domain socket
Message-ID: <CAOazyz0y3PytfyVCizx_bm8O=V3nsEFunMC4+zFS=b0VafW4WQ@mail.gmail.com>

Hi,
ssh.1 is up to date with unix domain socket.
ssh_config.5 does not mention unix domain socket.
I am not a native English speaker so it is hard for me to reach to correct
phrasing.
Can someone please sync the two?
Thanks!
Alon

From jjelen at redhat.com  Tue Nov 15 02:36:28 2016
From: jjelen at redhat.com (Jakub Jelen)
Date: Mon, 14 Nov 2016 16:36:28 +0100
Subject: OpenSSL 1.1.0 support
In-Reply-To: <alpine.BSO.2.20.1611030926130.8657@natsu.mindrot.org>
References: <20160918182230.tflkxar45vc6xmyf@roeckx.be>
 <20161102004359.GA21575@riva.ucam.org>
 <0d95cbbd-99b9-e612-6ebb-893ee989831a@redhat.com>
 <slrno1jlft.1joh.stu@naiad.spacehopper.org>
 <alpine.BSO.2.20.1611030926130.8657@natsu.mindrot.org>
Message-ID: <41b44030-f132-8a3e-168d-14b65b04ffe8@redhat.com>

On 11/02/2016 11:33 PM, Damien Miller wrote:
> On Wed, 2 Nov 2016, Stuart Henderson wrote:
>
>> On 2016-11-02, Jakub Jelen <jjelen at redhat.com> wrote:
>>> The current set of patches are rebased on current upstream is attached
>>> with few more tweaks needed to build, pass testsuite and make it work.
>>> The upstream review and insight would be helpful.
>> Since these are going to break things with LibreSSL, I doubt they'll be
>> acceptable as-is.
> This is the nub of the problem: upstream (OpenBSD) OpenSSH targets
> LibreSSL natively (it's also used by Apple for their OS X builds). If we
> pick up the 1.1.0 patch, we'd probably have to do it in portable because
> there's little point in patching OpenBSD for API that doesn't exist
> there. I don't want to have to carry such a major divergence in just the
> portable tree.

Thank you for the comments. I understand the upstream directions and 
that the OpenSSL step is not ideal. The distros will probably have to 
carry these patches until the changes will settle down a bit.

Other possible solution we were discussing here was implementation of 
non-OpenSSL specific abstract layer for crypto operations, which would 
allow implementation of cryto-library specific bits in separate file 
(unlike current situation with calls all over the place) and would 
possibly allow different crypto library providers, similar way how the 
audit is handled at this moment. It would also abstract the code from 
the changes in one or the other crypto library interface. Would 
something like this  be acceptable for OpenSSH upstream?

Kind regards,

-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat


From root at doctor.nl2k.ab.ca  Tue Nov 15 04:31:25 2016
From: root at doctor.nl2k.ab.ca (Dave Shariff Yadallee - System Administrator a.k.a. The Root of the
 Problem)
Date: Mon, 14 Nov 2016 10:31:25 -0700
Subject: OpenSSL 1.1.0 support
In-Reply-To: <41b44030-f132-8a3e-168d-14b65b04ffe8@redhat.com>
References: <20160918182230.tflkxar45vc6xmyf@roeckx.be>
 <20161102004359.GA21575@riva.ucam.org>
 <0d95cbbd-99b9-e612-6ebb-893ee989831a@redhat.com>
 <slrno1jlft.1joh.stu@naiad.spacehopper.org>
 <alpine.BSO.2.20.1611030926130.8657@natsu.mindrot.org>
 <41b44030-f132-8a3e-168d-14b65b04ffe8@redhat.com>
Message-ID: <20161114173125.GA75586@doctor.nl2k.ab.ca>

On Mon, Nov 14, 2016 at 04:36:28PM +0100, Jakub Jelen wrote:
> On 11/02/2016 11:33 PM, Damien Miller wrote:
> > On Wed, 2 Nov 2016, Stuart Henderson wrote:
> >
> >> On 2016-11-02, Jakub Jelen <jjelen at redhat.com> wrote:
> >>> The current set of patches are rebased on current upstream is attached
> >>> with few more tweaks needed to build, pass testsuite and make it work.
> >>> The upstream review and insight would be helpful.
> >> Since these are going to break things with LibreSSL, I doubt they'll be
> >> acceptable as-is.
> > This is the nub of the problem: upstream (OpenBSD) OpenSSH targets
> > LibreSSL natively (it's also used by Apple for their OS X builds). If we
> > pick up the 1.1.0 patch, we'd probably have to do it in portable because
> > there's little point in patching OpenBSD for API that doesn't exist
> > there. I don't want to have to carry such a major divergence in just the
> > portable tree.
> 
> Thank you for the comments. I understand the upstream directions and 
> that the OpenSSL step is not ideal. The distros will probably have to 
> carry these patches until the changes will settle down a bit.
> 
> Other possible solution we were discussing here was implementation of 
> non-OpenSSL specific abstract layer for crypto operations, which would 
> allow implementation of cryto-library specific bits in separate file 
> (unlike current situation with calls all over the place) and would 
> possibly allow different crypto library providers, similar way how the 
> audit is handled at this moment. It would also abstract the code from 
> the changes in one or the other crypto library interface. Would 
> something like this  be acceptable for OpenSSH upstream?
>

All SSL developers have to take into account

1) LibreSSL

2) Openssl 1.0.X and below

and
3) OPenssl 1.1 +


So stop stop living in the past and march towards the future.
 
> Kind regards,
> 
> -- 
> Jakub Jelen
> Software Engineer
> Security Technologies
> Red Hat
> 
> _______________________________________________
> 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  Tue Nov 15 10:02:06 2016
From: djm at mindrot.org (Damien Miller)
Date: Tue, 15 Nov 2016 10:02:06 +1100 (AEDT)
Subject: OpenSSL 1.1.0 support
In-Reply-To: <41b44030-f132-8a3e-168d-14b65b04ffe8@redhat.com>
References: <20160918182230.tflkxar45vc6xmyf@roeckx.be>
 <20161102004359.GA21575@riva.ucam.org>
 <0d95cbbd-99b9-e612-6ebb-893ee989831a@redhat.com>
 <slrno1jlft.1joh.stu@naiad.spacehopper.org>
 <alpine.BSO.2.20.1611030926130.8657@natsu.mindrot.org>
 <41b44030-f132-8a3e-168d-14b65b04ffe8@redhat.com>
Message-ID: <alpine.BSO.2.20.1611150946480.21227@natsu.mindrot.org>

On Mon, 14 Nov 2016, Jakub Jelen wrote:

> Thank you for the comments. I understand the upstream directions and
> that the OpenSSL step is not ideal. The distros will probably have to
> carry these patches until the changes will settle down a bit.

AFAIK Red Hat employs at least one OpenSSL maintainer. What is their
view on this situation?

> Other possible solution we were discussing here was implementation of
> non-OpenSSL specific abstract layer for crypto operations, which would
> allow implementation of cryto-library specific bits in separate file
> (unlike current situation with calls all over the place) and would
> possibly allow different crypto library providers, similar way how
> the audit is handled at this moment. It would also abstract the code
> from the changes in one or the other crypto library interface. Would
> something like this be acceptable for OpenSSH upstream?

That's an option that involves a heap of work. I've toyed with it
for a while now, but haven't been motivated enough to start it. Part
of the reason is that there has been no compelling alternative open-
source crypto library to justify the effort of building the abstraction
layer. I don't really feel like OpenSSL 1.1 is sufficiently different
to justify it either.

-d

From ryuzo.yamamoto at gmail.com  Tue Nov 15 11:50:48 2016
From: ryuzo.yamamoto at gmail.com (Ryuzo Yamamoto)
Date: Mon, 14 Nov 2016 19:50:48 -0500
Subject: SHA256 + base64 fingerprint format
Message-ID: <CAPZLP63kK9YmMiFc6YtbNY0a=mnbKwknEuYuL+Gp7S-+fCFV9A@mail.gmail.com>

Hi,
I'm now adding fingerprint format method to golang crypt library.
Here is the change set for it:
https://go-review.googlesource.com/#/c/32814/

I'd like to make sure why the trailing "=" is removed from the result of
base64.
Does anybody know?

Thank you!

Ryuzo Yamamoto

From adam at continusec.com  Tue Nov 15 12:14:39 2016
From: adam at continusec.com (Adam Eijdenberg)
Date: Tue, 15 Nov 2016 12:14:39 +1100
Subject: SHA256 + base64 fingerprint format
In-Reply-To: <CAPZLP63kK9YmMiFc6YtbNY0a=mnbKwknEuYuL+Gp7S-+fCFV9A@mail.gmail.com>
References: <CAPZLP63kK9YmMiFc6YtbNY0a=mnbKwknEuYuL+Gp7S-+fCFV9A@mail.gmail.com>
Message-ID: <CAD0Csb6G4_q+DG4=2TkpU0-sr+HKPzfDj1uebHUvOECUo9H-Nw@mail.gmail.com>

On Tue, Nov 15, 2016 at 11:56 AM Ryuzo Yamamoto
<ryuzo.yamamoto at gmail.com> wrote:
> I'd like to make sure why the trailing "=" is removed from the result of
> base64.

Try using base64.RawStdEncoding instead of base64.StdEncoding.

See: https://golang.org/pkg/encoding/base64/#pkg-variables

From djm at mindrot.org  Tue Nov 15 12:32:20 2016
From: djm at mindrot.org (Damien Miller)
Date: Tue, 15 Nov 2016 12:32:20 +1100 (AEDT)
Subject: SHA256 + base64 fingerprint format
In-Reply-To: <CAPZLP63kK9YmMiFc6YtbNY0a=mnbKwknEuYuL+Gp7S-+fCFV9A@mail.gmail.com>
References: <CAPZLP63kK9YmMiFc6YtbNY0a=mnbKwknEuYuL+Gp7S-+fCFV9A@mail.gmail.com>
Message-ID: <alpine.BSO.2.20.1611151229520.21227@natsu.mindrot.org>

On Mon, 14 Nov 2016, Ryuzo Yamamoto wrote:

> Hi,
> I'm now adding fingerprint format method to golang crypt library.
> Here is the change set for it:
> https://go-review.googlesource.com/#/c/32814/
> 
> I'd like to make sure why the trailing "=" is removed from the result of
> base64.
> Does anybody know?

I trimmed them because they add no information to the fingerprint - they
are always present in the plain b64 encoding given the mismatch between
SHA256's output size and base64's "block" size but they don't represent
any bits of the hash.

Also they're ugly :)

-d

From ryuzo.yamamoto at gmail.com  Tue Nov 15 12:42:06 2016
From: ryuzo.yamamoto at gmail.com (Ryuzo Yamamoto)
Date: Mon, 14 Nov 2016 20:42:06 -0500
Subject: SHA256 + base64 fingerprint format
In-Reply-To: <alpine.BSO.2.20.1611151229520.21227@natsu.mindrot.org>
References: <CAPZLP63kK9YmMiFc6YtbNY0a=mnbKwknEuYuL+Gp7S-+fCFV9A@mail.gmail.com>
 <alpine.BSO.2.20.1611151229520.21227@natsu.mindrot.org>
Message-ID: <CAPZLP61ss1Xc3uTj5zrgkn91v=sH1c_0Ph_MtRBML+OJ=0CM2g@mail.gmail.com>

Hi Adam and Damien,

Thank you for your quick reply!

I understood that you use unpadded base64 encoding as defined in RFC
4648 section 3.2.

As Adam said, I'll use base64.RawStdEncoding instead of base64.StdEncoding.

Again, Thank you!


On Mon, Nov 14, 2016 at 8:32 PM, Damien Miller <djm at mindrot.org> wrote:
> On Mon, 14 Nov 2016, Ryuzo Yamamoto wrote:
>
>> Hi,
>> I'm now adding fingerprint format method to golang crypt library.
>> Here is the change set for it:
>> https://go-review.googlesource.com/#/c/32814/
>>
>> I'd like to make sure why the trailing "=" is removed from the result of
>> base64.
>> Does anybody know?
>
> I trimmed them because they add no information to the fingerprint - they
> are always present in the plain b64 encoding given the mismatch between
> SHA256's output size and base64's "block" size but they don't represent
> any bits of the hash.
>
> Also they're ugly :)
>
> -d

From dkg at fifthhorseman.net  Tue Nov 15 13:30:30 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 15 Nov 2016 11:30:30 +0900
Subject: OpenSSL 1.1.0 support
In-Reply-To: <alpine.BSO.2.20.1611150946480.21227@natsu.mindrot.org>
References: <20160918182230.tflkxar45vc6xmyf@roeckx.be>
 <20161102004359.GA21575@riva.ucam.org>
 <0d95cbbd-99b9-e612-6ebb-893ee989831a@redhat.com>
 <slrno1jlft.1joh.stu@naiad.spacehopper.org>
 <alpine.BSO.2.20.1611030926130.8657@natsu.mindrot.org>
 <41b44030-f132-8a3e-168d-14b65b04ffe8@redhat.com>
 <alpine.BSO.2.20.1611150946480.21227@natsu.mindrot.org>
Message-ID: <878tslcw55.fsf@alice.fifthhorseman.net>

On Tue 2016-11-15 08:02:06 +0900, Damien Miller wrote:
> That's an option that involves a heap of work. I've toyed with it
> for a while now, but haven't been motivated enough to start it. Part
> of the reason is that there has been no compelling alternative open-
> source crypto library to justify the effort of building the abstraction
> layer. I don't really feel like OpenSSL 1.1 is sufficiently different
> to justify it either.

FWIW, i consider nettle to be a compelling FLOSS crypto primitive
library.  It doesn't provide TLS or SSL, but i don't think that's
anything that OpenSSH would care about.

    https://www.lysator.liu.se/~nisse/nettle/

         --dkg
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 962 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20161115/1b5d2a66/attachment-0001.bin>

From jjelen at redhat.com  Tue Nov 15 19:15:31 2016
From: jjelen at redhat.com (Jakub Jelen)
Date: Tue, 15 Nov 2016 09:15:31 +0100
Subject: OpenSSL 1.1.0 support
In-Reply-To: <alpine.BSO.2.20.1611150946480.21227@natsu.mindrot.org>
References: <20160918182230.tflkxar45vc6xmyf@roeckx.be>
 <20161102004359.GA21575@riva.ucam.org>
 <0d95cbbd-99b9-e612-6ebb-893ee989831a@redhat.com>
 <slrno1jlft.1joh.stu@naiad.spacehopper.org>
 <alpine.BSO.2.20.1611030926130.8657@natsu.mindrot.org>
 <41b44030-f132-8a3e-168d-14b65b04ffe8@redhat.com>
 <alpine.BSO.2.20.1611150946480.21227@natsu.mindrot.org>
Message-ID: <4a029094-581b-0013-1dd0-d90a75add26c@redhat.com>



On 11/15/2016 12:02 AM, Damien Miller wrote:
> On Mon, 14 Nov 2016, Jakub Jelen wrote:
>
>> Thank you for the comments. I understand the upstream directions and
>> that the OpenSSL step is not ideal. The distros will probably have to
>> carry these patches until the changes will settle down a bit.
> AFAIK Red Hat employs at least one OpenSSL maintainer. What is their
> view on this situation?

Yes, you got a message off-the-list from Tomas Mraz, our OpenSSL 
maintainer, one week ago. The OpenSSL certainly wants to resolve these 
issues from their side (compat library in addition to 1.0.2 from OpenSSL 
side). But that will not help us with compatibility against LibreSSL if 
I see right.

Regards,

-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat


From jmtapio at ssh.com  Wed Nov 16 20:31:16 2016
From: jmtapio at ssh.com (Juha-Matti Tapio)
Date: Wed, 16 Nov 2016 11:31:16 +0200
Subject: [PATCH] ssh-pkcs11: allow providing unconditional pin code for PKCS11
Message-ID: <20161116093115.x3bv4zzu2yofygvh@ssh.com>

Some HSM's such as Safenet Network HSM do not allow searching for keys
unauthenticated. To support such devices provide a mechanism for users
to provide a pin code that is always used to automatically log in to
the HSM when using PKCS11.

The pin code is read from a file specified by the environment variable
SSH_PKCS11_PINFILE if it is set.

Tested against Safenet Network HSM.
---
 ssh-pkcs11.c | 35 +++++++++++++++++++++++++++++++++++
 1 file changed, 35 insertions(+)

diff --git a/ssh-pkcs11.c b/ssh-pkcs11.c
index aaf712d..f75b201 100644
--- a/ssh-pkcs11.c
+++ b/ssh-pkcs11.c
@@ -42,6 +42,8 @@
 #include "ssh-pkcs11.h"
 #include "xmalloc.h"
 
+#define SSH_MAX_PKCS11_PIN_BYTES 128
+
 struct pkcs11_slotinfo {
 	CK_TOKEN_INFO		token;
 	CK_SESSION_HANDLE	session;
@@ -216,6 +218,36 @@ pkcs11_find(struct pkcs11_provider *p, CK_ULONG slotidx, CK_ATTRIBUTE *attr,
 	return (ret);
 }
 
+/* read pin from a file specified in SSH_PKCS11_PINFILE if one exists */
+char *
+pkcs11_read_pinfile()
+{
+	FILE *f;
+	char *pinfilename;
+	char buf[SSH_MAX_PKCS11_PIN_BYTES];
+	int i;
+
+	if ((pinfilename = getenv("SSH_PKCS11_PINFILE")) == NULL)
+		return NULL;
+	if ((f = fopen(pinfilename, "r")) == NULL) {
+		debug("failed to read SSH_PKCS11_PINFILE");
+		return NULL;
+	}
+	if (fgets(buf, SSH_MAX_PKCS11_PIN_BYTES, f) == NULL)
+		return NULL;
+	fclose(f);
+
+	/* truncate first line and ignore the rest */
+	for (i = 0; buf[i] && i < SSH_MAX_PKCS11_PIN_BYTES; i++) {
+		if (buf[i] == '\n' || buf[i] == '\r') {
+			buf[i] = '\0';
+			break;
+		}
+	}
+
+	return xstrdup(buf);
+}
+
 /* openssl callback doing the actual signing operation */
 static int
 pkcs11_rsa_private_encrypt(int flen, const u_char *from, u_char *to, RSA *rsa,
@@ -575,6 +607,9 @@ pkcs11_add_provider(char *provider_id, char *pin, struct sshkey ***keyp)
 	CK_TOKEN_INFO *token;
 	CK_ULONG i;
 
+	if (!pin)
+		pin = pkcs11_read_pinfile();
+
 	*keyp = NULL;
 	if (pkcs11_provider_lookup(provider_id) != NULL) {
 		debug("%s: provider already registered: %s",

From peter at stuge.se  Wed Nov 16 22:20:20 2016
From: peter at stuge.se (Peter Stuge)
Date: Wed, 16 Nov 2016 11:20:20 +0000
Subject: [PATCH] ssh-pkcs11: allow providing unconditional pin code for
 PKCS11
In-Reply-To: <20161116093115.x3bv4zzu2yofygvh@ssh.com>
References: <20161116093115.x3bv4zzu2yofygvh@ssh.com>
Message-ID: <20161116112020.GI31660@foo.stuge.se>

Juha-Matti Tapio wrote:
> +pkcs11_read_pinfile()
..
> +	if ((f = fopen(pinfilename, "r")) == NULL) {
> +		debug("failed to read SSH_PKCS11_PINFILE");
> +		return NULL;
> +	}
> +	if (fgets(buf, SSH_MAX_PKCS11_PIN_BYTES, f) == NULL)
> +		return NULL;

This leaks the open file on error.


> +	fclose(f);
> +
> +	/* truncate first line and ignore the rest */
> +	for (i = 0; buf[i] && i < SSH_MAX_PKCS11_PIN_BYTES; i++) {
> +		if (buf[i] == '\n' || buf[i] == '\r') {
> +			buf[i] = '\0';
> +			break;
> +		}
> +	}

Why not just a call to strtok() ?


> +	return xstrdup(buf);

Does this memory get freed somewhere?


I don't think this patch is ready yet, and I don't know if this
functionality is really desirable. Would it be an option to store the
pin itself in the environment? HSM seems a bit pointless if a PIN
must be stored in plain text on disk..


//Peter

From uri at ll.mit.edu  Wed Nov 16 23:54:44 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Wed, 16 Nov 2016 12:54:44 +0000
Subject: [PATCH] ssh-pkcs11: allow providing unconditional pin code for
 PKCS11
Message-ID: <20161116125452.18280523.77034.101891@ll.mit.edu>

I find this approach very bad in general.?

PKCS#11 standard says that *private* keys should not be accessible without authentication. *Public* keys and certificates of course can and should be accessible with no authentication.

SoftHSM misinterpreted this originally (older pkcs11 documents were less clear :), but they rectified this mistake. We should not repeat it.?

Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network.
? Original Message ?
From: Juha-Matti Tapio
Sent: Wednesday, November 16, 2016 04:35
To: openssh-unix-dev at mindrot.org
Subject: [PATCH] ssh-pkcs11: allow providing unconditional pin code for PKCS11

Some HSM's such as Safenet Network HSM do not allow searching for keys
unauthenticated. To support such devices provide a mechanism for users
to provide a pin code that is always used to automatically log in to
the HSM when using PKCS11.

The pin code is read from a file specified by the environment variable
SSH_PKCS11_PINFILE if it is set.

Tested against Safenet Network HSM.
---
ssh-pkcs11.c | 35 +++++++++++++++++++++++++++++++++++
1 file changed, 35 insertions(+)

diff --git a/ssh-pkcs11.c b/ssh-pkcs11.c
index aaf712d..f75b201 100644
--- a/ssh-pkcs11.c
+++ b/ssh-pkcs11.c
@@ -42,6 +42,8 @@
#include "ssh-pkcs11.h"
#include "xmalloc.h"

+#define SSH_MAX_PKCS11_PIN_BYTES 128
+
struct pkcs11_slotinfo {
CK_TOKEN_INFO	 token;
CK_SESSION_HANDLE	session;
@@ -216,6 +218,36 @@ pkcs11_find(struct pkcs11_provider *p, CK_ULONG slotidx, CK_ATTRIBUTE *attr,
return (ret);
}

+/* read pin from a file specified in SSH_PKCS11_PINFILE if one exists */
+char *
+pkcs11_read_pinfile()
+{
+	FILE *f;
+	char *pinfilename;
+	char buf[SSH_MAX_PKCS11_PIN_BYTES];
+	int i;
+
+	if ((pinfilename = getenv("SSH_PKCS11_PINFILE")) == NULL)
+	 return NULL;
+	if ((f = fopen(pinfilename, "r")) == NULL) {
+	 debug("failed to read SSH_PKCS11_PINFILE");
+	 return NULL;
+	}
+	if (fgets(buf, SSH_MAX_PKCS11_PIN_BYTES, f) == NULL)
+	 return NULL;
+	fclose(f);
+
+	/* truncate first line and ignore the rest */
+	for (i = 0; buf[i] && i < SSH_MAX_PKCS11_PIN_BYTES; i++) {
+	 if (buf[i] == '\n' || buf[i] == '\r') {
+	 buf[i] = '\0';
+	 break;
+	 }
+	}
+
+	return xstrdup(buf);
+}
+
/* openssl callback doing the actual signing operation */
static int
pkcs11_rsa_private_encrypt(int flen, const u_char *from, u_char *to, RSA *rsa,
@@ -575,6 +607,9 @@ pkcs11_add_provider(char *provider_id, char *pin, struct sshkey ***keyp)
CK_TOKEN_INFO *token;
CK_ULONG i;

+	if (!pin)
+	 pin = pkcs11_read_pinfile();
+
*keyp = NULL;
if (pkcs11_provider_lookup(provider_id) != NULL) {
debug("%s: provider already registered: %s",
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 4350 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20161116/612a394b/attachment-0001.bin>

From jmtapio at ssh.com  Thu Nov 17 00:55:15 2016
From: jmtapio at ssh.com (Juha-Matti Tapio)
Date: Wed, 16 Nov 2016 15:55:15 +0200
Subject: [PATCH] ssh-pkcs11: allow providing unconditional pin code for
 PKCS11
In-Reply-To: <20161116125452.18280523.77034.101891@ll.mit.edu>
References: <20161116125452.18280523.77034.101891@ll.mit.edu>
Message-ID: <20161116135515.2ocryez7cc2zuwxz@ssh.com>

On Wed, Nov 16, 2016 at 12:54:44PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
> I find this approach very bad in general.?
> 
> PKCS#11 standard says that *private* keys should not be accessible without authentication. *Public* keys and certificates of course can and should be accessible with no authentication.
> 
> SoftHSM misinterpreted this originally (older pkcs11 documents were less clear :), but they rectified this mistake. We should not repeat it.?

I do agree that requiring authentication to access public keys is not
a very pleasant way to do PKCS11. For example having to provide
authentication for ssh-keygen -D is a slight pain. I am happy to
listen to any alternative solutions given that we are unable to modify
the HSM itself.

We solved the issue this way because we had a customer requirement to
support using Safenet Network HSM for some critical automated
connections. Unfortunately we have no way to influence how the HSM in
our case works as all we have to work with is a binary PKCS11 library
and a hardware box with closed source firmware.

Btw as a response to other comments, the justification for using an
environment variable to point to a pin code file instead of
environment variable with a pin code is that there is a risk that
runtime environment might be inadvertently leaked in some debug
outputs or verification scripts. Distinct files are less likely to be
leaked by accident. In the case of Safenet Network HSM there are three
layers of "authentication" (or rather security checks): Certificates
authenticate the host and the HSM to each other, IP addresses are
checked and all operations must provide the pin to the HSM partition.
The main justification for the customer organization to use a network
HSM instead of local passwordless private keys is to prevent the key
from leaking.

I believe this is a somewhat rare case but we feel it might be useful
to people other than us. Safenet HSM products seem fairly popular with
enterprises and I believe Amazon CloudHSM is really close to it. Oh
and we do appreciate the feedback.

From uri at ll.mit.edu  Thu Nov 17 02:58:23 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Wed, 16 Nov 2016 15:58:23 +0000
Subject: [PATCH] ssh-pkcs11: allow providing unconditional pin code for
 PKCS11
In-Reply-To: <20161116135515.2ocryez7cc2zuwxz@ssh.com>
References: <20161116125452.18280523.77034.101891@ll.mit.edu>
 <20161116135515.2ocryez7cc2zuwxz@ssh.com>
Message-ID: <BF7BCF27-C885-44AC-81C2-D7ADAB2370BC@ll.mit.edu>


On 11/16/16, 8:55 AM, "openssh-unix-dev on behalf of Juha-Matti Tapio" <openssh-unix-dev-bounces+uri=ll.mit.edu at mindrot.org on behalf of jmtapio at ssh.com> wrote:

    On Wed, Nov 16, 2016 at 12:54:44PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
    > I find this approach very bad in general. 
    > 
    > PKCS#11 standard says that *private* keys should not be accessible without authentication. *Public* keys and certificates of course can and should be accessible with no authentication.
    > 
    > SoftHSM misinterpreted this originally (older pkcs11 documents were less clear :), but they rectified this mistake. We should not repeat it. 
    
    I do agree that requiring authentication to access public keys is not
    a very pleasant way to do PKCS11. 

The point is not as much of being ?not very pleasant?. The point is to avoid breaking it for everything and everybody else (like, forcing them to authenticate for public key operations ? which would break all the existing scripts), for the sake of one screwed-up HSM device.

    I am happy to listen to any alternative solutions 

I?m OK with a hack to take care of one non-compliant device. I am not OK with having that hack as part of the mainstream code.

    ?given that we are unable to modify the HSM itself.

Are you so sure? Does SafeNet maybe have a firmware upgrade? Did your people talk to SafeNet, with PKCS#11 v2.40 document in hand? Perhaps they can be convinced??
    
    We solved the issue this way because we had a customer requirement to
    support using Safenet Network HSM for some critical automated
    connections. Unfortunately we have no way to influence how the HSM in
    our case works as all we have to work with is a binary PKCS11 library
    and a hardware box with closed source firmware.

Understood. But see above.
    
    Btw as a response to other comments, the justification for using an
    environment variable to point to a pin code file instead of
    environment variable with a pin code is that there is a risk that
    runtime environment might be inadvertently leaked in some debug
    outputs or verification scripts. 

Yes, very valid concern and approach. As I said, *my* concern is avoiding the need to provide a PIN for non-private keys and certs.

    The main justification for the customer organization to use a network
    HSM instead of local passwordless private keys is to prevent the key
    from leaking.

This cannot be argued with. I?m doing something similar.

    
    I believe this is a somewhat rare case but we feel it might be useful
    to people other than us. Oh and we do appreciate the feedback.

The question is how to accommodate your needs without breaking it for everybody else. This is my main concern/objection.
 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20161116/6e741b88/attachment.bin>

From jmtapio at ssh.com  Thu Nov 17 06:11:51 2016
From: jmtapio at ssh.com (Juha-Matti Tapio)
Date: Wed, 16 Nov 2016 21:11:51 +0200
Subject: [PATCH] ssh-pkcs11: allow providing unconditional pin code for
 PKCS11
In-Reply-To: <BF7BCF27-C885-44AC-81C2-D7ADAB2370BC@ll.mit.edu>
References: <20161116125452.18280523.77034.101891@ll.mit.edu>
 <20161116135515.2ocryez7cc2zuwxz@ssh.com>
 <BF7BCF27-C885-44AC-81C2-D7ADAB2370BC@ll.mit.edu>
Message-ID: <20161116191151.ezjupitaudl263ol@ssh.com>

On Wed, Nov 16, 2016 at 03:58:23PM +0000, Blumenthal, Uri - 0553 - MITLL wrote:
> On 11/16/16, 8:55 AM, "openssh-unix-dev on behalf of Juha-Matti Tapio" <openssh-unix-dev-bounces+uri=ll.mit.edu at mindrot.org on behalf of jmtapio at ssh.com> wrote:
>     I do agree that requiring authentication to access public keys is not
>     a very pleasant way to do PKCS11. 
> 
> The point is not as much of being ?not very pleasant?. The point is to avoid breaking it for everything and everybody else (like, forcing them to authenticate for public key operations ? which would break all the existing scripts), for the sake of one screwed-up HSM device.

The patch does not change any existing functionality. It only adds a
mechanism that allows users to force providing a pin code even if one
is not asked by default. Nothing happens if the users do not trigger
the mechanism and I am not sure why anything would break even if they
did provide a pin code.

>     ?given that we are unable to modify the HSM itself.
> 
> Are you so sure? Does SafeNet maybe have a firmware upgrade? Did your people talk to SafeNet, with PKCS#11 v2.40 document in hand? Perhaps they can be convinced??

The software is upgradeable but it is not something we can influence.
We are mainly concerned about interoperability with existing
installations.

>     Btw as a response to other comments, the justification for using an
>     environment variable to point to a pin code file instead of
>     environment variable with a pin code is that there is a risk that
>     runtime environment might be inadvertently leaked in some debug
>     outputs or verification scripts. 
> 
> Yes, very valid concern and approach. As I said, *my* concern is avoiding the need to provide a PIN for non-private keys and certs.

If the pin is not provided using our mechanism, then it is NULL and
C_Login is not called, just as without our patch. So no change there
to existing behaviour.

From uri at ll.mit.edu  Thu Nov 17 09:18:26 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Wed, 16 Nov 2016 22:18:26 +0000
Subject: [PATCH] ssh-pkcs11: allow providing unconditional pin code for
 PKCS11
In-Reply-To: <20161116191151.ezjupitaudl263ol@ssh.com>
References: <20161116125452.18280523.77034.101891@ll.mit.edu>
 <20161116135515.2ocryez7cc2zuwxz@ssh.com>
 <BF7BCF27-C885-44AC-81C2-D7ADAB2370BC@ll.mit.edu>
 <20161116191151.ezjupitaudl263ol@ssh.com>
Message-ID: <B08CD8A3-07B9-4E4C-92B6-F1551169EA47@ll.mit.edu>

On 11/16/16, 2:11 PM, "openssh-unix-dev on behalf of Juha-Matti Tapio" <openssh-unix-dev-bounces+uri=ll.mit.edu at mindrot.org on behalf of jmtapio at ssh.com> wrote:
    The patch does not change any existing functionality. It only adds a
    mechanism that allows users to force providing a pin code even if one
    is not asked by default. Nothing happens if the users do not trigger
    the mechanism and I am not sure why anything would break even if they
    did provide a pin code.

OK, that makes things better.

    
      > Yes, very valid concern and approach. As I said, *my* concern is avoiding
      > the need to provide a PIN for non-private keys and certs.
    
    If the pin is not provided using our mechanism, then it is NULL and
    C_Login is not called, just as without our patch. So no change there
    to existing behavior.

The mechanism might require some more thinking. But based on the above, I (reluctantly ? I still don?t like it) withdraw my objection. 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5211 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20161116/407fd458/attachment.bin>

From djm at mindrot.org  Fri Nov 18 11:41:41 2016
From: djm at mindrot.org (Damien Miller)
Date: Fri, 18 Nov 2016 11:41:41 +1100 (AEDT)
Subject: OpenSSL 1.1.0 support
In-Reply-To: <4a029094-581b-0013-1dd0-d90a75add26c@redhat.com>
References: <20160918182230.tflkxar45vc6xmyf@roeckx.be>
 <20161102004359.GA21575@riva.ucam.org>
 <0d95cbbd-99b9-e612-6ebb-893ee989831a@redhat.com>
 <slrno1jlft.1joh.stu@naiad.spacehopper.org>
 <alpine.BSO.2.20.1611030926130.8657@natsu.mindrot.org>
 <41b44030-f132-8a3e-168d-14b65b04ffe8@redhat.com>
 <alpine.BSO.2.20.1611150946480.21227@natsu.mindrot.org>
 <4a029094-581b-0013-1dd0-d90a75add26c@redhat.com>
Message-ID: <alpine.BSO.2.20.1611181110320.64663@natsu.mindrot.org>

On Tue, 15 Nov 2016, Jakub Jelen wrote:

> On 11/15/2016 12:02 AM, Damien Miller wrote:
> > On Mon, 14 Nov 2016, Jakub Jelen wrote:
> > 
> > > Thank you for the comments. I understand the upstream directions and
> > > that the OpenSSL step is not ideal. The distros will probably have to
> > > carry these patches until the changes will settle down a bit.
> > AFAIK Red Hat employs at least one OpenSSL maintainer. What is their
> > view on this situation?
> 
> Yes, you got a message off-the-list from Tomas Mraz, our OpenSSL maintainer,
> one week ago. The OpenSSL certainly wants to resolve these issues from their
> side (compat library in addition to 1.0.2 from OpenSSL side). But that will
> not help us with compatibility against LibreSSL if I see right.

For my part, I'm going to wait a while to see what migration improvements
come from OpenSSL and I don't plan on merging any changes to support 1.1.x
until there's a better story.

I'm sure that if OpenSSL come up with a cleaner way for their users to
support 1.0.x and 1.1.x then it will be easier to convince Libre/BoringSSL
to follow suit.

-d

From thomas at aptible.com  Sat Nov 19 01:18:59 2016
From: thomas at aptible.com (Thomas Orozco)
Date: Fri, 18 Nov 2016 15:18:59 +0100
Subject: Allow UNIX socket forwarding, but disallow TCP forwarding?
Message-ID: <CAMQuowNnYMpciG3=AsGqT1Qr+0kBsq9TaY93x=rpvSQYj+VcZA@mail.gmail.com>

Hi there!

We're trying to set up OpenSSH to allow socket forwarding, but
disallow TCP forwarding.

The "intuitive" configuration doesn't appear to work (more on that below!):

```
AllowTCPForwarding no
AllowStreamLocalForwarding yes
PermitOpen any
```

First a note about our use case.

We're using OpenSSH on a bastion host (technically, OpenSSH itself is
running within a container on a bastion host, but that's not very
important here) and using it to punch holes in our network for
authorized users.

Here's an example, we have a bastion host that's accessible to both
Alice and Bob (who may or may not be adversarial towards each other).

Both users have one database running on a server that's accessible
*behind* the bastion host (it's reasonably easy for both Alice and Bob
to find the IP for this). We want Alice to be able to access her own
DB, and Bob to access his, but we don't want them to access each
other's database.

So, to let Alice and Bob log in to our bastion host, we want to
provide them with (short-term) SSH Certificates that essentially:

- Allow port forwarding.
- Set up a force command that runs socat listening on a specific UNIX
socket and forwarding to the user's database (I'm simplifying a little
bit here). Currently, Bob and Alice use the same user, so we randomize
the socket name to prevent them from simply connecting to the other's
socket. In the longer term, they might use different users altogether.

Now, hopefully, this makes some sense!

Assuming it does, here's the problem we're running into: this
configuration doesn't actually work. When we attempt to create a port
forward with it, SSHD doesn't allow it:

```
debug1: server_input_channel_open: ctype
direct-streamlocal at openssh.com rchan 7 win 2097152 max 32768
debug1: server_request_direct_streamlocal: originator 127.0.0.1 port
54402, target MY_SOCKET
Received request to connect to path MY_SOCKET, but the request was denied.
debug1: server_input_channel_open: failure direct-streamlocal at openssh.com
```

This appears to be caused by the fact that if TCP forwarding is
disabled, the function do_authenticated in session.c will disable all
forwarding (by calling channel_disable_adm_local_opens).

But, unfortunately, enabling TCP forwarding here would defeat what
we're trying to do: that'd allow Alice and Bob to directly establish a
port forward to one of the database hosts behind the bastion host,
bypassing the socat tunnel altogether.

Now, we tried using PermitOpen to lock that down, but unfortunately,
that doesn't appear to work either:

- It appears that for a stream local forward, SSHD matches the path of
the socket against the hosts allowed in PermitOpen, which
unfortunately doesn't work for us here, so we can't restrict forwards
that way.
- It *also* appears that SSHD matches the port -2 against PermitOpen
for a stream local forward, but -2 isn't a valid port in PermitOpen :)

Now, digging a little further, the following patch *appears* to make
things work (it allows stream local forwarding, but continues to
disallow TCP forwarding ? at least in my trivial testing...):

diff --git a/session.c b/session.c
index 85805f5..0717c2c 100644
--- a/session.c
+++ b/session.c
@@ -256,9 +256,9 @@ do_authenticated(Authctxt *authctxt)
        setproctitle("%s", authctxt->pw->pw_name);

        /* setup the channel layer */
-       /* XXX - streamlocal? */
        if (no_port_forwarding_flag ||
-           (options.allow_tcp_forwarding & FORWARD_LOCAL) == 0)
+           ((options.allow_tcp_forwarding & FORWARD_LOCAL) == 0) &&
+            (options.allow_streamlocal_forwarding & FORWARD_LOCAL) == 0)
                channel_disable_adm_local_opens();
        else
                channel_permit_all_opens();


So, my questions to you are:

- Is this a use case that makes sense for OpenSSH?
- If so, how appropriate is the above patch? As I mentioned, in my
testing, it doesn't appear to allow TCP forwarding when it should be
disabled, but I don't understand exactly what the
`options.allow_tcp_forwarding & FORWARD_LOCAL) == 0` condition is
looking for yet, so this is likely to be totally the wrong way to go
about this.

Thanks in advance!

-- Thomas

-- 
*Disclaimer: This e-mail and any attachments may contain confidential 
information. If you are not the intended recipient, any disclosure, 
copying, distribution or use of any information contained herein is 
strictly prohibited. *

*If you have received this transmission in error, please immediately notify 
security at aptible.com <security at aptible.com> or call (866) 296-5003 and 
destroy the original transmission and any attachments without reading or 
saving.*

From openssh at roumenpetrov.info  Sat Nov 19 19:56:59 2016
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Sat, 19 Nov 2016 10:56:59 +0200
Subject: OpenSSL 1.1.0 support
In-Reply-To: <4a029094-581b-0013-1dd0-d90a75add26c@redhat.com>
References: <20160918182230.tflkxar45vc6xmyf@roeckx.be>
 <20161102004359.GA21575@riva.ucam.org>
 <0d95cbbd-99b9-e612-6ebb-893ee989831a@redhat.com>
 <slrno1jlft.1joh.stu@naiad.spacehopper.org>
 <alpine.BSO.2.20.1611030926130.8657@natsu.mindrot.org>
 <41b44030-f132-8a3e-168d-14b65b04ffe8@redhat.com>
 <alpine.BSO.2.20.1611150946480.21227@natsu.mindrot.org>
 <4a029094-581b-0013-1dd0-d90a75add26c@redhat.com>
Message-ID: <583013DB.8080805@roumenpetrov.info>

Jakub Jelen wrote:
> On 11/15/2016 12:02 AM, Damien Miller wrote:
>> On Mon, 14 Nov 2016, Jakub Jelen wrote:
>>> Thank you for the comments. I understand the upstream directions and
>>> that the OpenSSL step is not ideal. The distros will probably have to
>>> carry these patches until the changes will settle down a bit.
>> AFAIK Red Hat employs at least one OpenSSL maintainer. What is their
>> view on this situation?
> Yes, you got a message off-the-list from Tomas Mraz, our OpenSSL 
> maintainer, one week ago. The OpenSSL certainly wants to resolve these 
> issues from their side (compat library in addition to 1.0.2 from 
> OpenSSL side). 
I don't think that this is so important. Each project has specific use 
of crypto library and is not so difficult to write compatibility layer. 
I know a number of projects that already has such layer.

> But that will not help us with compatibility against LibreSSL if I see 
> right.
If compatibility layer is written properly OpenSSL compatible libraries 
will be supported as well.
For instance PKIX-SSH mainly tests for the presence of each feature and 
as result supported builds with various OpenSSL versions, including FIPS 
or Kerberos enable. Such tests ensure builds with OpenSSL compatible 
libraries.


Using cryptographic library A or B version c or d and etc. depends of 
many things. One criteria is that know defects are fixed, but this is 
off-topic to  OpenSSL API 1.1 support.


Just one remark: Long time ago OpenSSL team announce plan to hide 
structures to ensure better compatibility between releases. Team miss 
1.0 release but now this is fact.


Regards,
Roumen Petrov

-- 
Secure shell with X.509 certificate support
http://roumenpetrov.info/secsh/


From jjelen at redhat.com  Mon Nov 21 19:05:23 2016
From: jjelen at redhat.com (Jakub Jelen)
Date: Mon, 21 Nov 2016 09:05:23 +0100
Subject: [PATCH] ssh-pkcs11: allow providing unconditional pin code for
 PKCS11
In-Reply-To: <20161116093115.x3bv4zzu2yofygvh@ssh.com>
References: <20161116093115.x3bv4zzu2yofygvh@ssh.com>
Message-ID: <6bc20ed1-aa97-18e5-5601-323b16fb4154@redhat.com>

On 11/16/2016 10:31 AM, Juha-Matti Tapio wrote:
> Some HSM's such as Safenet Network HSM do not allow searching for keys
> unauthenticated. To support such devices provide a mechanism for users
> to provide a pin code that is always used to automatically log in to
> the HSM when using PKCS11.
>
> The pin code is read from a file specified by the environment variable
> SSH_PKCS11_PINFILE if it is set.
Don't we have PKCS#11 URI [1] to handle this? Without re-inventing wheel 
again? Wider implemenation would solve also other pains in PKCS#11 
waters in OpenSSH (choosing single key from a card -- alternative to 
IdentityFile, using p11kit, ...), though it would need some work to 
implement in OpenSSH, but as I can observe, PKCS#11 is not a biggest 
priority. Though I am having a look into that.

[1] https://tools.ietf.org/html/rfc7512

Regards,

-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat


From jmtapio at ssh.com  Mon Nov 21 21:36:15 2016
From: jmtapio at ssh.com (Juha-Matti Tapio)
Date: Mon, 21 Nov 2016 12:36:15 +0200
Subject: [PATCH] ssh-pkcs11: allow providing unconditional pin code for
 PKCS11
In-Reply-To: <6bc20ed1-aa97-18e5-5601-323b16fb4154@redhat.com>
References: <20161116093115.x3bv4zzu2yofygvh@ssh.com>
 <6bc20ed1-aa97-18e5-5601-323b16fb4154@redhat.com>
Message-ID: <20161121103615.2xhmukvyb6ksel3d@ssh.com>

On Mon, Nov 21, 2016 at 09:05:23AM +0100, Jakub Jelen wrote:
> On 11/16/2016 10:31 AM, Juha-Matti Tapio wrote:
> > Some HSM's such as Safenet Network HSM do not allow searching for keys
> > unauthenticated. To support such devices provide a mechanism for users
> > to provide a pin code that is always used to automatically log in to
> > the HSM when using PKCS11.
> > 
> > The pin code is read from a file specified by the environment variable
> > SSH_PKCS11_PINFILE if it is set.
> Don't we have PKCS#11 URI [1] to handle this? Without re-inventing wheel
> again? Wider implemenation would solve also other pains in PKCS#11 waters in
> OpenSSH (choosing single key from a card -- alternative to IdentityFile,
> using p11kit, ...), though it would need some work to implement in OpenSSH,
> but as I can observe, PKCS#11 is not a biggest priority. Though I am having
> a look into that.

I think PKCS#11 URI support would be an excellent way to do it and
being able to choose the key would be a definite improvement. I
am not sure how much effort it would take but in principle I think it
would be the cleanest way to solve the issues.


From uri at ll.mit.edu  Tue Nov 22 01:05:59 2016
From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL)
Date: Mon, 21 Nov 2016 14:05:59 +0000
Subject: [PATCH] ssh-pkcs11: allow providing unconditional pin code for
 PKCS11
Message-ID: <20161121140608.18280523.97221.102761@ll.mit.edu>

+1

Sent?from?my?BlackBerry?10?smartphone?on?the Verizon?Wireless?4G?LTE?network.
? Original Message ?
From: Jakub Jelen
Sent: Monday, November 21, 2016 03:07
To: Juha-Matti Tapio; openssh-unix-dev at mindrot.org
Subject: Re: [PATCH] ssh-pkcs11: allow providing unconditional pin code for PKCS11

On 11/16/2016 10:31 AM, Juha-Matti Tapio wrote:
> Some HSM's such as Safenet Network HSM do not allow searching for keys
> unauthenticated. To support such devices provide a mechanism for users
> to provide a pin code that is always used to automatically log in to
> the HSM when using PKCS11.
>
> The pin code is read from a file specified by the environment variable
> SSH_PKCS11_PINFILE if it is set.
Don't we have PKCS#11 URI [1] to handle this? Without re-inventing wheel 
again? Wider implemenation would solve also other pains in PKCS#11 
waters in OpenSSH (choosing single key from a card -- alternative to 
IdentityFile, using p11kit, ...), though it would need some work to 
implement in OpenSSH, but as I can observe, PKCS#11 is not a biggest 
priority. Though I am having a look into that.

[1] https://tools.ietf.org/html/rfc7512

Regards,

-- 
Jakub Jelen
Software Engineer
Security Technologies
Red Hat

_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

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

From dtucker at zip.com.au  Wed Nov 23 09:17:01 2016
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 23 Nov 2016 09:17:01 +1100
Subject: Dynamic Remote Port forward?
In-Reply-To: <CAKPyHN1atbGj-5S1dXh2+V==dFNOz18PEzPcB-zXqLXVzrMoXA@mail.gmail.com>
References: <CAOYdKdjm28S=UdzwuXPdxh8roaNzrVVGyVZJ3hdmA-9fWuNo1w@mail.gmail.com>
 <572F9A9C.9000802@gmail.com>
 <CAKPyHN1atbGj-5S1dXh2+V==dFNOz18PEzPcB-zXqLXVzrMoXA@mail.gmail.com>
Message-ID: <CALDDTe3hOeow0B2aDVhizjtksK8vRwmqMdtHAjW8KOU7HABXXQ@mail.gmail.com>

On Mon, May 9, 2016 at 4:21 PM, Bert Wesarg <bert.wesarg at googlemail.com> wrote:
> On Sun, May 8, 2016 at 9:59 PM, ?ngel Gonz?lez <keisial at gmail.com> wrote:
>> I think this would be doable with:
>>
>> ssh -oProxyCommand="ssh -D 1080 localhost -W %h:%p" -R
>> /sshvpn/gateway-xxxx:localhost:1080 sshvpn at central
>
> AFAIK -W forces ClearAllForwardings=1, which makes -D a no-op.

For future reference: OpenSSH 7.3 added the ability to override that
ClearAllForwardings settings when -W is used.

https://bugzilla.mindrot.org/show_bug.cgi?id=2577
https://anongit.mindrot.org/openssh.git/commit/?id=0cb2f4c2494b115d0f346ed2d8b603ab3ba643f4

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From sam at hocevar.net  Wed Nov 23 11:09:37 2016
From: sam at hocevar.net (Sam Hocevar)
Date: Wed, 23 Nov 2016 01:09:37 +0100
Subject: [PATCH] Allow scp to copy files that start with a Windows drive
 name.
In-Reply-To: <20160920092019.GA44000@hocevar.net>
Message-ID: <20161123000937.GT7984@hocevar.net>

On Tue, Sep 20, 2016, Sam Hocevar wrote:
> On Windows, ?scp C:/foo/bar remotehost:? will attempt to connect to
> a remote host ?C? and access file ?/foo/bar?. There is currently no
> syntax or flag to allow copying files that start with a drive name.

   Any comments on this patch maybe? Right now it is impossible to do
?scp 'C:\foo\bar' remotehost:? on Windows.

Regards,
-- 
Sam.

From melo at simplicidade.org  Thu Nov 24 04:37:22 2016
From: melo at simplicidade.org (Pedro Melo)
Date: Wed, 23 Nov 2016 17:37:22 +0000
Subject: Inconsistency between legacy and release notes?
Message-ID: <80E9A172-ABC5-44C8-B217-91444E067567@simplicidade.org>

Hi,

 

Someone told me that DSA keys were being deprecated with OpenSSH 7.0. The only reference I could find about this topic on openSSH site is on the legacy page:

 

?OpenSSH 7.0 and greater similarly disable the ssh-dss (DSA) public key algorithm. It too is weak and we recommend against its use.?

 

There is no explanation about the weakness. But more than that, I could not find any mention of this deprecation on OpenSSH 7.0, 7.1, 7.2 and 7.3 release notes.

 

So my question is: are DSA keys really deprecated?

 

Thank you in advance,

-- 

Pedro Melo

melo at simplicidade.org (e-mail, SIP, XMPP)

https://www.simplicidade.org

 


From arw at cs.fau.de  Sat Nov 26 01:16:43 2016
From: arw at cs.fau.de (Alexander Wuerstlein)
Date: Fri, 25 Nov 2016 15:16:43 +0100
Subject: Inconsistency between legacy and release notes?
In-Reply-To: <80E9A172-ABC5-44C8-B217-91444E067567@simplicidade.org>
References: <80E9A172-ABC5-44C8-B217-91444E067567@simplicidade.org>
Message-ID: <20161125141643.GL27032@cip.informatik.uni-erlangen.de>

On 2016-11-25T10:58, Pedro Melo <melo at simplicidade.org> wrote:
> Hi,
> 
>  
> 
> Someone told me that DSA keys were being deprecated with OpenSSH 7.0. The only reference I could find about this topic on openSSH site is on the legacy page:
> 
>  
> 
> ?OpenSSH 7.0 and greater similarly disable the ssh-dss (DSA) public key algorithm. It too is weak and we recommend against its use.?
> 
>  
> 
> There is no explanation about the weakness. But more than that, I could not find any mention of this deprecation on OpenSSH 7.0, 7.1, 7.2 and 7.3 release notes.
> 
>  
> 
> So my question is: are DSA keys really deprecated?

Afaik its because DSA key size has (for very weird reasons admittedly:
FIPS 186-4) been limited to 1024 bits which is considered weak nowadays. 
Also, DSA has the inherent weakness that a random number is used in
producing a DSA signature. If such a random number were ever reused, an
attacker could easily calculate the secret key from just looking at the
signatures. This means that DSA together with a weak source of
randomness endangers your keys and therefore your machines.

There is a workaround for the weak randomness problem (derive the
'random' number deterministically from the message and the secret key),
and I think its implemented in OpenSSH. But that doesn't take care of
all the old installations and different SSH implementations. Therefore
since DSA keys are too small anyways, its just better to get rid of it
altogether.



Ciao,

Alexander Wuerstlein.

From gheskett at shentel.net  Sun Nov 27 02:54:45 2016
From: gheskett at shentel.net (Gene Heskett)
Date: Sat, 26 Nov 2016 10:54:45 -0500
Subject: SBC's and ssh's encryptions
Message-ID: <201611261054.45049.gheskett@shentel.net>

Greetings everybody;

I have 2 questions today, but to put them in context, I'll describe the 
setup first.

I am in the process of cnc'ing an old Sheldon metal lathe.  These can 
make large amounts of flying metal chips & stringers when doing what 
they do, so its paramount that the electronics to run them are either 
far enough away, or put in a box thats well sealed, with fans in the box 
to distribute the heat, and a fan blowing on the box to cool its 
surface. So the motor supplies and motor drivers are in the box, and 
supply their own fans, leaving room on the inside of the door for the 
controlling interfaces and two SBC's:

A Raspberry pi 3b (4 core arm64 @ 1.2GHz, and a gig of ddr3 ram) to run 
the program, called LinuxCNC.

And an odroid64-c2, faster 4 core arm64, 2GB of ram, which should handle 
the graphical duties of controlling the program as it claims to be able 
to drive a 4k display at 30 FPS.

I have tried running X on the raspi, but it hasn't enough memory or iron 
to do it well. With only a gigabyte of ram and running from a u-sd card 
for a boot drive, there is a hint of OOM to its failures.

Running htop on the odroid, its not x but sshd thats the bottleneck thats 
causing the odroid to render at 3 or 4 frames per second at whatever the 
default encryption was.  Last night, I went around and converted all 
my /etc/ssh/ssh_config's to:

cipher chacha20-poly1305 at openssh.com

This got me up to maybe 8 frames a second. My current networking test 
setup has several devices, hubs and switches in the data path between 
the SBC's but will only have about a 50 foot cable to a gigabit switch 
in the final lashup from each SBC.  There's another cnc'd machine there 
that also needs net access to keep it up to date.

I am not too worried about being penetrated, a router running dd-wrt is 
between me and the net modem, and has been for several years. No one has 
come thru it except to my web page, on this machine. url in the sig.

So my two questions are:

Is there a faster thru-put yet encryption, like none?

How can I query the running ssh setup to see what encryption it is 
actually using?

Thank you, all.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

From peter at stuge.se  Sun Nov 27 11:25:41 2016
From: peter at stuge.se (Peter Stuge)
Date: Sun, 27 Nov 2016 00:25:41 +0000
Subject: SBC's and ssh's encryptions
In-Reply-To: <201611261054.45049.gheskett@shentel.net>
References: <201611261054.45049.gheskett@shentel.net>
Message-ID: <20161127002541.GN21523@foo.stuge.se>

Gene Heskett wrote:
> the inside of the door .. two SBC's:
..
> I have tried running X on the raspi, but it hasn't enough memory or
> iron to do it well.

A GHz system with GB of RAM is certainly capable of running a
well-written GUI effortlessly.


> Running htop on the odroid, its not x but sshd thats the bottleneck
> thats causing the odroid to render at 3 or 4 frames per second

Why are you running X through SSH? Run X directly over the network
instead; that is literally what it is made for.

(Set DISPLAY on pi with odroid IP. Run xauth +pi on odroid. Start X
programs on pi.)


But again: I guess the real problem is somewhere else entirely.


//Peter

From gheskett at shentel.net  Sun Nov 27 13:01:49 2016
From: gheskett at shentel.net (Gene Heskett)
Date: Sat, 26 Nov 2016 21:01:49 -0500
Subject: SBC's and ssh's encryptions
In-Reply-To: <20161127002541.GN21523@foo.stuge.se>
References: <201611261054.45049.gheskett@shentel.net>
 <20161127002541.GN21523@foo.stuge.se>
Message-ID: <201611262101.49340.gheskett@shentel.net>

On Saturday 26 November 2016 19:25:41 Peter Stuge wrote:

> Gene Heskett wrote:
> > the inside of the door .. two SBC's:
>
> ..
>
> > I have tried running X on the raspi, but it hasn't enough memory or
> > iron to do it well.
>
> A GHz system with GB of RAM is certainly capable of running a
> well-written GUI effortlessly.
>
> > Running htop on the odroid, its not x but sshd thats the bottleneck
> > thats causing the odroid to render at 3 or 4 frames per second
>
> Why are you running X through SSH? Run X directly over the network
> instead; that is literally what it is made for.
>
> (Set DISPLAY on pi with odroid IP. Run xauth +pi on odroid. Start X
> programs on pi.)

Hmm, learning something new like most days:
sample/example cli?
Something like 

export DISPLAY 192.168.xx.9:10:0

 on the pi, and

xauth +raspi on the odroid?
; >
> But again: I guess the real problem is somewhere else entirely.

I have the X manpage up on the odroid and I am logged into the pi too.
From that manpage I should set and export DISPLAY to
 
  hostname:displaynumber.screennumber, so on the pi

setenv DISPLAY odroid:12.0
or
DISPLAY = odroid:12.0
export DISPLAY
>
this on the raspi

on the odroid64
xauth +raspi

then to conserve keyboards, log into raspi, and start my x using program

Have I got it right?

The reason for the 12 is that as I am logged into the odroid twice right 
now, so screens 10 and 11 are already in use with my ssh -Y logins and I 
asumme I can't re-use a display number.  Or should I re-use the display 
number, and enum the screen number some how?  Obviously this is 
something I've never done before. I would also assume the ssh login 
would be without any -X or -Y options. 

So Plz clarify.  If this gets rid of most or all of the lag, I'll be in 
hog heaven.

Thanks Peter.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

From peter at stuge.se  Sun Nov 27 23:40:43 2016
From: peter at stuge.se (Peter Stuge)
Date: Sun, 27 Nov 2016 12:40:43 +0000
Subject: SBC's and ssh's encryptions
In-Reply-To: <201611262101.49340.gheskett@shentel.net>
References: <201611261054.45049.gheskett@shentel.net>
 <20161127002541.GN21523@foo.stuge.se>
 <201611262101.49340.gheskett@shentel.net>
Message-ID: <20161127124043.GP21523@foo.stuge.se>

Gene Heskett wrote:
> > (Set DISPLAY on pi with odroid IP. Run xauth +pi on odroid. Start X
> > programs on pi.)
> 
> sample/example cli?

192.168.1.2 pi
192.168.1.3 odroid

On odroid, xauth +192.168.1.2
On pi, export DISPLAY=192.168.1.3:0
On pi, in same shell as above, start the GUI application

No X server runs on pi. Change only the IP addresses.

Read more man-pages and maybe also some tutorials to get an idea of
how it works.


//Peter

From gheskett at shentel.net  Mon Nov 28 03:30:08 2016
From: gheskett at shentel.net (Gene Heskett)
Date: Sun, 27 Nov 2016 11:30:08 -0500
Subject: SBC's and ssh's encryptions
In-Reply-To: <20161127124043.GP21523@foo.stuge.se>
References: <201611261054.45049.gheskett@shentel.net>
 <201611262101.49340.gheskett@shentel.net>
 <20161127124043.GP21523@foo.stuge.se>
Message-ID: <201611271130.08991.gheskett@shentel.net>

On Sunday 27 November 2016 07:40:43 Peter Stuge wrote:

> Gene Heskett wrote:
> > > (Set DISPLAY on pi with odroid IP. Run xauth +pi on odroid. Start
> > > X programs on pi.)
> >
> > sample/example cli?
>
> 192.168.1.2 pi (pi is ..71.8
> 192.168.1.3 odroid (odroid64 is ..71.9
>
> On odroid
xauth +192.168.71.8
> On pi,
export DISPLAY=192.168.71.9:0
 
> On pi, in same shell as above, start the GUI application

So the monitor is plugged into the droid, but the keyboard & mouse are 
plugged into the pi? That may be better than my image of running the pi 
from an ssh login to it from the droid.  Which is how its running now, 
useing the ssh forwarding thru all the encrypt.decrypt stuff, which is 
killing the speed.

If all this can be put into the correct rc.local files, so it Just Works 
when the whole system is powered up, that would be very nice as it gets 
rid of one keyboard and mouse except when doing maintenance or trouble 
shooting.

> No X server runs on pi. Change only the IP addresses.
>
> Read more man-pages and maybe also some tutorials to get an idea of
> how it works.

I think I am getting a grip on it, you are basically saying exactly the 
same thing 2 others have told me in the last 2 hours.  Now all I should 
have to do is undo, from its own keyboard a change I made 
to /etc/ssh/sshd_config, reboot it again, right now its not accepting 
connections from at least 2 other machines.
>
Thank you Peter

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

From peter at stuge.se  Mon Nov 28 05:49:17 2016
From: peter at stuge.se (Peter Stuge)
Date: Sun, 27 Nov 2016 18:49:17 +0000
Subject: SBC's and ssh's encryptions
In-Reply-To: <201611271130.08991.gheskett@shentel.net>
References: <201611261054.45049.gheskett@shentel.net>
 <201611262101.49340.gheskett@shentel.net>
 <20161127124043.GP21523@foo.stuge.se>
 <201611271130.08991.gheskett@shentel.net>
Message-ID: <20161127184917.GQ21523@foo.stuge.se>

Gene Heskett wrote:
> > On pi, in same shell as above, start the GUI application
> 
> So the monitor is plugged into the droid, but the keyboard & mouse are 
> plugged into the pi?

No; X11 is a remote windowing protocol. Monitor, keyboard and mouse
are connected where your X server runs.

Applications run on the network and their windows display on the X server.


> ssh login

There seems to be no reason to use SSH.


> If all this can be put into the correct rc.local files

Set environments correctly and then start X server on one system and
the application on the other system.


//Peter

From gheskett at shentel.net  Mon Nov 28 09:16:02 2016
From: gheskett at shentel.net (Gene Heskett)
Date: Sun, 27 Nov 2016 17:16:02 -0500
Subject: SBC's and ssh's encryptions
In-Reply-To: <20161127184917.GQ21523@foo.stuge.se>
References: <201611261054.45049.gheskett@shentel.net>
 <201611271130.08991.gheskett@shentel.net>
 <20161127184917.GQ21523@foo.stuge.se>
Message-ID: <201611271716.02339.gheskett@shentel.net>

On Sunday 27 November 2016 13:49:17 Peter Stuge wrote:

> Gene Heskett wrote:
> > > On pi, in same shell as above, start the GUI application
> >
> > So the monitor is plugged into the droid, but the keyboard & mouse
> > are plugged into the pi?
>
> No; X11 is a remote windowing protocol. Monitor, keyboard and mouse
> are connected where your X server runs.
>
> Applications run on the network and their windows display on the X
> server.
>
> > ssh login
>
> There seems to be no reason to use SSH.
>
> > If all this can be put into the correct rc.local files
>
> Set environments correctly and then start X server on one system and
> the application on the other system.
>
The odroid64 already has an x system running as soon as I log into the 
odroid64.  Its $DISPLAY is :0

I'm at a dead end, I think I have all the i's dotted and the t's crossed 
but I cannot get a single byte across the link because the pi cannot 
open the display on the odroid64.

I suspect it may be the display number, which is :0 on the instance 
running on the odroid46, automaticly brought up when I log into the 
odroid64.

and an echo $DISPLAY on the pi shows: (after I've done the commands)
192.168.71.9:0

I have a hunch that is the error. Or at least the next hurdle.

The .Xauthority file on both machines had grown to several kilobytes, so 
I blew them away, then discovered I needed to touch them, x couldn't 
create the missing file.

I figured I'd start with a clean slate on both SBC's that way.

And I did get a round tuit and put a power cord in the two pads next to 
that worthless coax connector, so now the odroid64 has solid power. 
Finally.

Thanks Peter.

> //Peter
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

From peter at stuge.se  Mon Nov 28 10:21:00 2016
From: peter at stuge.se (Peter Stuge)
Date: Sun, 27 Nov 2016 23:21:00 +0000
Subject: SBC's and ssh's encryptions
In-Reply-To: <201611271716.02339.gheskett@shentel.net>
References: <201611261054.45049.gheskett@shentel.net>
 <201611271130.08991.gheskett@shentel.net>
 <20161127184917.GQ21523@foo.stuge.se>
 <201611271716.02339.gheskett@shentel.net>
Message-ID: <20161127232100.GX21523@foo.stuge.se>

Gene Heskett wrote:
> The odroid64 already has an x system running as soon as I log into
> the odroid64.  Its $DISPLAY is :0

That's fine. Remember to run xhost +192.168.71.pi on odroid64.


> the pi cannot open the display on the odroid64.

Show an error message when starting e.g. xterm on pi.


> an echo $DISPLAY on the pi shows: (after I've done the commands)
> 192.168.71.9:0

If the odroid IP is 192.168.71.9 then that is correct.


Way off topic now.


//Peter

From deengert at gmail.com  Mon Nov 28 10:40:54 2016
From: deengert at gmail.com (Douglas E Engert)
Date: Sun, 27 Nov 2016 17:40:54 -0600
Subject: SBC's and ssh's encryptions
In-Reply-To: <20161127232100.GX21523@foo.stuge.se>
References: <201611261054.45049.gheskett@shentel.net>
 <201611271130.08991.gheskett@shentel.net>
 <20161127184917.GQ21523@foo.stuge.se>
 <201611271716.02339.gheskett@shentel.net>
 <20161127232100.GX21523@foo.stuge.se>
Message-ID: <96a0ce7c-5604-c3d8-73d3-207e04d09fdc@gmail.com>



On 11/27/2016 5:21 PM, Peter Stuge wrote:
> Gene Heskett wrote:
>> The odroid64 already has an x system running as soon as I log into
>> the odroid64.  Its $DISPLAY is :0
>
> That's fine. Remember to run xhost +192.168.71.pi on odroid64.
>
>
>> the pi cannot open the display on the odroid64.
>
> Show an error message when starting e.g. xterm on pi.
>
>
>> an echo $DISPLAY on the pi shows: (after I've done the commands)
>> 192.168.71.9:0

That looks like the local display in the pi but you said it has no monitor is attached.

If you ran ssh on odroid64 and had the X11 Forwarding correct, the sshd on pi will set up an X proxy
on pi and set DISPLAY=localhost:10.0 for the first user and pass this to the user in the environment
On the pi you also need /etc/ssh/sshd_config:
X11Forwarding yes
X11DisplayOffset 10
If you have a ~/.ssh/rc file on the pi you may need to add code to process the cookie and set the DISPLAY.
See the man ssh on the pi,. look for DISPLAY
This is done before the login shell, so you must not set the
DISPLAY again in your login files.

Just ran some tests using my old pi from 2013:
Linux raspberrypi 3.18.11+ #781 PREEMPT Tue Apr 21 18:02:18 BST 2015 armv6l GNU/Linux
OpenSSH_6.0p1 Debian-4+deb7u2, OpenSSL 1.0.1e 11 Feb 2013

SSh from Windows 10 using PuTTY, with Xming.

 From a Ubuntu-16.4  VM to the pi using
ssh -l user -X ip-address-of-pi
the display gets set as  DISPLAY=localhost:11.0

/usr/bin/X11/xev on the pi is a good test program.
or x-terminal-emulator

For performance you may want to google for:
"X windows" performance ssh

>
> If the odroid IP is 192.168.71.9 then that is correct.
>
>
> Way off topic now.
>
>
> //Peter
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

-- 

  Douglas E. Engert  <DEEngert at gmail.com>


From gheskett at shentel.net  Mon Nov 28 10:52:41 2016
From: gheskett at shentel.net (Gene Heskett)
Date: Sun, 27 Nov 2016 18:52:41 -0500
Subject: SBC's and ssh's encryptions
In-Reply-To: <20161127232100.GX21523@foo.stuge.se>
References: <201611261054.45049.gheskett@shentel.net>
 <201611271716.02339.gheskett@shentel.net>
 <20161127232100.GX21523@foo.stuge.se>
Message-ID: <201611271852.41536.gheskett@shentel.net>

On Sunday 27 November 2016 18:21:00 Peter Stuge wrote:

> Gene Heskett wrote:
> > The odroid64 already has an x system running as soon as I log into
> > the odroid64.  Its $DISPLAY is :0
>
> That's fine. Remember to run xhost +192.168.71.pi on odroid64.
>
> > the pi cannot open the display on the odroid64.
>
> Show an error message when starting e.g. xterm on pi.
>
> > an echo $DISPLAY on the pi shows: (after I've done the commands)
> > 192.168.71.9:0
>
> If the odroid IP is 192.168.71.9 then that is correct.

It is.
>
> Way off topic now.

Not really, its getting closer to what I wanted to do when I started 
this thread. What I wanted to do was bypass the ssh's encrypt/decrypt 
time killers.

But another network savvy fellow on the emc list says I should get the 
display by running this on the pi:

xauth extract - $DISPLAY|ssh <pi-usr>@<raspi-ip> xauth merge -

which does not update the $DISPLAY var on the pi, it remains at at localhost:10
This was the actual command line:

gene at raspberrypi:~ $ xauth extract - $DISPLAY|ssh gene at 192.168.71.9 xauth merge -
gene at 192.168.71.9's password: 
gene at raspberrypi:~ $ echo $DISPLAY
localhost:10.0

This lack of apparent effect is possibly an artifact of my being logged 
into both SBC from a 3rd (this machine) source.

Thank you Peter. Got to get more sleep tonight.

Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

From gheskett at shentel.net  Mon Nov 28 11:01:03 2016
From: gheskett at shentel.net (Gene Heskett)
Date: Sun, 27 Nov 2016 19:01:03 -0500
Subject: SBC's and ssh's encryptions
In-Reply-To: <96a0ce7c-5604-c3d8-73d3-207e04d09fdc@gmail.com>
References: <201611261054.45049.gheskett@shentel.net>
 <20161127232100.GX21523@foo.stuge.se>
 <96a0ce7c-5604-c3d8-73d3-207e04d09fdc@gmail.com>
Message-ID: <201611271901.03144.gheskett@shentel.net>

On Sunday 27 November 2016 18:40:54 Douglas E Engert wrote:

> On 11/27/2016 5:21 PM, Peter Stuge wrote:
> > Gene Heskett wrote:
> >> The odroid64 already has an x system running as soon as I log into
> >> the odroid64.  Its $DISPLAY is :0
> >
> > That's fine. Remember to run xhost +192.168.71.pi on odroid64.
> >
> >> the pi cannot open the display on the odroid64.
> >
> > Show an error message when starting e.g. xterm on pi.
> >
> >> an echo $DISPLAY on the pi shows: (after I've done the commands)
> >> 192.168.71.9:0
>
> That looks like the local display in the pi but you said it has no
> monitor is attached.

Its a 10 inch move of the HDMI and USB cables :)
>
> If you ran ssh on odroid64 and had the X11 Forwarding correct, the
> sshd on pi will set up an X proxy on pi and set DISPLAY=localhost:10.0
> for the first user and pass this to the user in the environment On the
> pi you also need /etc/ssh/sshd_config:
> X11Forwarding yes
> X11DisplayOffset 10

not specifically but those are the defaults.
ssh -Y forwarding works, I can turn around to the milling machine, log 
into the pi from with an ssh -Y, and run the program, getting the laggy 
image on the milling machines monitor.

> If you have a ~/.ssh/rc file on the pi you may need to add code to
> process the cookie and set the DISPLAY. See the man ssh on the pi,.
> look for DISPLAY
> This is done before the login shell, so you must not set the
> DISPLAY again in your login files.
>
> Just ran some tests using my old pi from 2013:
> Linux raspberrypi 3.18.11+ #781 PREEMPT Tue Apr 21 18:02:18 BST 2015
> armv6l GNU/Linux OpenSSH_6.0p1 Debian-4+deb7u2, OpenSSL 1.0.1e 11 Feb
> 2013
>
> SSh from Windows 10 using PuTTY, with Xming.
>
>  From a Ubuntu-16.4  VM to the pi using
> ssh -l user -X ip-address-of-pi
> the display gets set as  DISPLAY=localhost:11.0
>
> /usr/bin/X11/xev on the pi is a good test program.
> or x-terminal-emulator
>
> For performance you may want to google for:
> "X windows" performance ssh
>
> > If the odroid IP is 192.168.71.9 then that is correct.
> >
> >
> > Way off topic now.
> >
> >
> > //Peter
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev at mindrot.org
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


Cheers, Gene Heskett
-- 
"There are four boxes to be used in defense of liberty:
 soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Genes Web page <http://geneslinuxbox.net:6309/gene>

From dtucker at zip.com.au  Mon Nov 28 11:14:00 2016
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 28 Nov 2016 11:14:00 +1100
Subject: Inconsistency between legacy and release notes?
In-Reply-To: <20161125141643.GL27032@cip.informatik.uni-erlangen.de>
References: <80E9A172-ABC5-44C8-B217-91444E067567@simplicidade.org>
 <20161125141643.GL27032@cip.informatik.uni-erlangen.de>
Message-ID: <CALDDTe20ahow2ENPLsLb4vhX160CSdQHSBHpuPW5Za79WeFAeg@mail.gmail.com>

On Sat, Nov 26, 2016 at 1:16 AM, Alexander Wuerstlein <arw at cs.fau.de> wrote:
[...]
> Afaik its because DSA key size has (for very weird reasons admittedly:
> FIPS 186-4) been limited to 1024 bits which is considered weak nowadays.

Use of DSA within the SSH protocol requires the use of SHA1, which is
160 bits (80 bits against a birthday attack) and is reaching its
use-by date.  This is probably why FIPS requires stronger hashes for
DSA key sizes >1k, but those can't be used in SSH because it specifies
only SHA1.

There's some more info in https://bugzilla.mindrot.org/show_bug.cgi?id=1647

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From peter at stuge.se  Mon Nov 28 12:14:12 2016
From: peter at stuge.se (Peter Stuge)
Date: Mon, 28 Nov 2016 01:14:12 +0000
Subject: SBC's and ssh's encryptions
In-Reply-To: <201611271852.41536.gheskett@shentel.net>
References: <201611261054.45049.gheskett@shentel.net>
 <201611271716.02339.gheskett@shentel.net>
 <20161127232100.GX21523@foo.stuge.se>
 <201611271852.41536.gheskett@shentel.net>
Message-ID: <20161128011412.GZ21523@foo.stuge.se>

Gene Heskett wrote:
> > Show an error message when starting e.g. xterm on pi.

Without error messages you can't really get further help.


> > Way off topic now.
> 
> Not really,

Yes, really. Off topic for this mailing list.

This is Unix/X basics, nothing at all to do with OpenSSH.


> gene at raspberrypi:~ $ xauth extract - $DISPLAY|ssh gene at 192.168.71.9 xauth merge -
> gene at 192.168.71.9's password: 
> gene at raspberrypi:~ $ echo $DISPLAY
> localhost:10.0
> 
> This lack of apparent effect

The command will have had an effect, but maybe not what you think.
Your method of measuring is at least not measuring the effect.

And it's not appropriate for what you want to do.


//Peter

From melo at simplicidade.org  Mon Nov 28 17:46:31 2016
From: melo at simplicidade.org (Pedro Melo)
Date: Mon, 28 Nov 2016 06:46:31 +0000
Subject: Inconsistency between legacy and release notes?
In-Reply-To: <CALDDTe20ahow2ENPLsLb4vhX160CSdQHSBHpuPW5Za79WeFAeg@mail.gmail.com>
References: <80E9A172-ABC5-44C8-B217-91444E067567@simplicidade.org>
 <20161125141643.GL27032@cip.informatik.uni-erlangen.de>
 <CALDDTe20ahow2ENPLsLb4vhX160CSdQHSBHpuPW5Za79WeFAeg@mail.gmail.com>
Message-ID: <5C211AB2-40F2-4DA8-9509-45EF872248DB@simplicidade.org>

Hi

On 28/11/16 00:14, "dtucker at dtucker.net on behalf of Darren Tucker" <dtucker at dtucker.net on behalf of dtucker at zip.com.au> wrote:

    On Sat, Nov 26, 2016 at 1:16 AM, Alexander Wuerstlein <arw at cs.fau.de> wrote:
    [...]
    > Afaik its because DSA key size has (for very weird reasons admittedly:
    > FIPS 186-4) been limited to 1024 bits which is considered weak nowadays.
    
    Use of DSA within the SSH protocol requires the use of SHA1, which is
    160 bits (80 bits against a birthday attack) and is reaching its
    use-by date.  This is probably why FIPS requires stronger hashes for
    DSA key sizes >1k, but those can't be used in SSH because it specifies
    only SHA1.
    
    There's some more info in https://bugzilla.mindrot.org/show_bug.cgi?id=1647

My initial email was not about why DSA was deprecated (although I do appreciate the reasons, thank you), but more about the fact that this deprecation is not mentioned on the OpenSSH release notes, so I would argue that DSA was not in fact deprecated?

I think mentioning on the next release release notes would be important to make it official.

Thank you,



From dtucker at zip.com.au  Mon Nov 28 18:10:55 2016
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 28 Nov 2016 18:10:55 +1100
Subject: Inconsistency between legacy and release notes?
In-Reply-To: <5C211AB2-40F2-4DA8-9509-45EF872248DB@simplicidade.org>
References: <80E9A172-ABC5-44C8-B217-91444E067567@simplicidade.org>
 <20161125141643.GL27032@cip.informatik.uni-erlangen.de>
 <CALDDTe20ahow2ENPLsLb4vhX160CSdQHSBHpuPW5Za79WeFAeg@mail.gmail.com>
 <5C211AB2-40F2-4DA8-9509-45EF872248DB@simplicidade.org>
Message-ID: <CALDDTe3SAWGaKEgCJvWQK7QFRPHO6W2nJSyfa-Ov+XVYtnXLZA@mail.gmail.com>

On Mon, Nov 28, 2016 at 5:46 PM, Pedro Melo <melo at simplicidade.org> wrote:
> Hi
>
> On 28/11/16 00:14, "dtucker at dtucker.net on behalf of Darren Tucker" <dtucker at dtucker.net on behalf of dtucker at zip.com.au> wrote:
[...]
> My initial email was not about why DSA was deprecated (although I do appreciate the reasons, thank you), but more about the fact that this deprecation is not mentioned on the OpenSSH release notes, so I would argue that DSA was not in fact deprecated?

In the 7.0 release notes:

 * Support for ssh-dss, ssh-dss-cert-* host and user keys is disabled
   by default at run-time. These may be re-enabled using the
   instructions at http://www.openssh.com/legacy.html

DSS = Digital Signature Standard, DSA = Digital Signature Algorithm
but they refer to the same thing.  Given that the SSH standards use
ssh-dss, by rights keygen should refer to it as "dss" instead of "dsa"
but that ship sailed long ago.

-- 
Darren Tucker (dtucker at zip.com.au)
GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860  37F4 9357 ECEF 11EA A6FA (new)
    Good judgement comes with experience. Unfortunately, the experience
usually comes from bad judgement.

From melo at simplicidade.org  Mon Nov 28 18:14:55 2016
From: melo at simplicidade.org (Pedro Melo)
Date: Mon, 28 Nov 2016 07:14:55 +0000
Subject: Inconsistency between legacy and release notes?
In-Reply-To: <CALDDTe3SAWGaKEgCJvWQK7QFRPHO6W2nJSyfa-Ov+XVYtnXLZA@mail.gmail.com>
References: <80E9A172-ABC5-44C8-B217-91444E067567@simplicidade.org>
 <20161125141643.GL27032@cip.informatik.uni-erlangen.de>
 <CALDDTe20ahow2ENPLsLb4vhX160CSdQHSBHpuPW5Za79WeFAeg@mail.gmail.com>
 <5C211AB2-40F2-4DA8-9509-45EF872248DB@simplicidade.org>
 <CALDDTe3SAWGaKEgCJvWQK7QFRPHO6W2nJSyfa-Ov+XVYtnXLZA@mail.gmail.com>
Message-ID: <8567B6C0-C4E9-45B1-83C0-FD082D10EBB3@simplicidade.org>

Hi,

On 28/11/16 07:10, "dtucker at dtucker.net on behalf of Darren Tucker" <dtucker at dtucker.net on behalf of dtucker at zip.com.au> wrote:

    On Mon, Nov 28, 2016 at 5:46 PM, Pedro Melo <melo at simplicidade.org> wrote:
    > Hi
    >
    > On 28/11/16 00:14, "dtucker at dtucker.net on behalf of Darren Tucker" <dtucker at dtucker.net on behalf of dtucker at zip.com.au> wrote:
    [...]
    > My initial email was not about why DSA was deprecated (although I do appreciate the reasons, thank you), but more about the fact that this deprecation is not mentioned on the OpenSSH release notes, so I would argue that DSA was not in fact deprecated?
    
    In the 7.0 release notes:
    
     * Support for ssh-dss, ssh-dss-cert-* host and user keys is disabled
       by default at run-time. These may be re-enabled using the
       instructions at http://www.openssh.com/legacy.html
    
    DSS = Digital Signature Standard, DSA = Digital Signature Algorithm
    but they refer to the same thing.  Given that the SSH standards use
    ssh-dss, by rights keygen should refer to it as "dss" instead of "dsa"
    but that ship sailed long ago.

Oh, my apologies, I missed that. I searched for DSA only.

Thank you,