From stopspazzing at gmail.com  Sat Aug  1 02:08:14 2015
From: stopspazzing at gmail.com (Stop Spazzing)
Date: Fri, 31 Jul 2015 16:08:14 +0000
Subject: Feature Request: Invalid sshd port fallback
In-Reply-To: <alpine.BSO.2.20.1507310911280.27820@natsu.mindrot.org>
References: <CAHtGg4d3=tSYZJovdVjDBdKyf=dtP4_Tx4jJode45hdBxgPgeg@mail.gmail.com>
 <5EA3B277-D637-464E-80C7-CC110B85DE75@timeheart.net>
 <CAHtGg4dyMgWbNN5P0CsbQO_YcXoG1hkjrev=hFaR-_wM4p4QpQ@mail.gmail.com>
 <alpine.BSO.2.20.1507310911280.27820@natsu.mindrot.org>
Message-ID: <CAHtGg4e=VSjVWhWwznijDeE2P=QG0A90L5GpNvJXdsZBOsEWdQ@mail.gmail.com>

Version being used is: OpenSSH_6.6.1 was it added after this?

This is the default for Operating system Ubuntu Linux 14.04.2

On Thu, Jul 30, 2015 at 4:13 PM Damien Miller <djm at mindrot.org> wrote:

> On Thu, 30 Jul 2015, Stop Spazzing wrote:
>
> > I see your point and that makes valid sense;I even change default port.
> >
> > "It would be better to let you know the port is wrong and fail to start
> > until you fixed the problem and selected a valid non-standard port."
> >
> > Is there any reason something like this isn't implemented already? Could
> it
> > be implemented?
>
> It is:
>
> [djm at fuyu ssh]$ /usr/sbin/sshd -oPort=10000000
> command-line line 0: Badly formatted port number.
>
> Not sure what version you are using, but that check has been in place
> for a long time.
>

From mh+openssh-unix-dev at zugschlus.de  Sat Aug  1 18:35:33 2015
From: mh+openssh-unix-dev at zugschlus.de (Marc Haber)
Date: Sat, 1 Aug 2015 10:35:33 +0200
Subject: Feature Request: Invalid sshd port fallback
In-Reply-To: <CAOCN9ryxMyL1b66wqnLWLDdmXEg+E+dVARk5LtPTVODAGq-bqg@mail.gmail.com>
References: <CAHtGg4d3=tSYZJovdVjDBdKyf=dtP4_Tx4jJode45hdBxgPgeg@mail.gmail.com>
 <20150730204902.GJ29017@torres.zugschlus.de>
 <CAOCN9ryxMyL1b66wqnLWLDdmXEg+E+dVARk5LtPTVODAGq-bqg@mail.gmail.com>
Message-ID: <20150801083533.GC29017@torres.zugschlus.de>

On Thu, Jul 30, 2015 at 07:09:17PM -0400, Nico Kadel-Garcia wrote:
> On Thu, Jul 30, 2015 at 4:49 PM, Marc Haber
> <mh+openssh-unix-dev at zugschlus.de> wrote:
> > On Thu, Jul 30, 2015 at 08:30:28PM +0000, Stop Spazzing wrote:
> >> Why is this a good idea? Would be a good idea because people are human and
> >> make mistakes, and you shouldn't have to wipe your server just because an
> >> invalid port was used by accident.
> >
> > Why would one have to _WIPE_ a server because of a misconfigured sshd?
> 
> If you don't have console access, or it takes a long time to arrange,
> screwing up sshd_config means you are dead in the water.

Sure, but "Stop Spazzing" made it look like this is the normal case.
It isn't.

Greetings
Marc

-- 
-----------------------------------------------------------------------------
Marc Haber         | "I don't trust Computers. They | Mailadresse im Header
Leimen, Germany    |  lose things."    Winona Ryder | Fon: *49 6224 1600402
Nordisch by Nature |  How to make an American Quilt | Fax: *49 6224 1600421

From bjh21 at bjh21.me.uk  Sun Aug  2 09:10:09 2015
From: bjh21 at bjh21.me.uk (Ben Harris)
Date: Sun, 2 Aug 2015 00:10:09 +0100 (BST)
Subject: Regularising ssh-ed25519
Message-ID: <alpine.DEB.2.10.1507241155240.618@snap.ds.cam.ac.uk>

[ posted to comp.security.ssh last month, to no reply ]

I've written an Internet-Draft describing how to use Ed25519 in SSH and
formally allocating the name "ssh-ed25519" for it:

https://datatracker.ietf.org/doc/draft-bjh21-ssh-ed25519/

The primary purpose of this is to regularise the use of that name by 
implementations.  I'd like to know what the OpenSSH developers think of 
this draft.  Questions I'm particularly interested in are:

* Is the specification technically correct?

* Is my guess that the first implementation of ssh-ed25519 was in
OpenSSH by Markus Friedl correct?

* Is there a better way to reference the OpenSSH 6.5 release notes?

* Should this be Informational or Standards Track?  An IETF-approved
Informational RFC is the minimum that's required to get an algorithm
name allocated, but if ssh-ed25519 is expected to be the new standard
public-key format, maybe it's worth the effort to put this on the
Standards Track.

Thanks for your attention.

-- 
Ben Harris

From mfriedl at gmail.com  Mon Aug  3 05:36:13 2015
From: mfriedl at gmail.com (Markus Friedl)
Date: Sun, 2 Aug 2015 21:36:13 +0200
Subject: Regularising ssh-ed25519
In-Reply-To: <alpine.DEB.2.10.1507241155240.618@snap.ds.cam.ac.uk>
References: <alpine.DEB.2.10.1507241155240.618@snap.ds.cam.ac.uk>
Message-ID: <7919C7A3-DE0A-42BA-B65F-C389126926D9@gmail.com>


> Am 02.08.2015 um 01:10 schrieb Ben Harris <bjh21 at bjh21.me.uk>:
> 
> [ posted to comp.security.ssh last month, to no reply ]
> 

Didn't know it still exists.

> I've written an Internet-Draft describing how to use Ed25519 in SSH and
> formally allocating the name "ssh-ed25519" for it:
> 
> https://datatracker.ietf.org/doc/draft-bjh21-ssh-ed25519/
> 
> The primary purpose of this is to regularise the use of that name by implementations.  I'd like to know what the OpenSSH developers think of this draft.  Questions I'm particularly interested in are:
> 
> * Is the specification technically correct?

yes.

> 
> * Is my guess that the first implementation of ssh-ed25519 was in
> OpenSSH by Markus Friedl correct?

yes, I don't know of any prior implementations.

> 
> * Is there a better way to reference the OpenSSH 6.5 release notes?

I don't think so.


> 
> * Should this be Informational or Standards Track?  An IETF-approved
> Informational RFC is the minimum that's required to get an algorithm
> name allocated, but if ssh-ed25519 is expected to be the new standard
> public-key format, maybe it's worth the effort to put this on the
> Standards Track.

Standards Track would be nice, but I'm also undecided about the effort.

Thanks!
-m



> 
> Thanks for your attention.
> 
> -- 
> Ben Harris
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


From martin at libtec.org  Mon Aug  3 08:08:34 2015
From: martin at libtec.org (Martin)
Date: Mon, 3 Aug 2015 01:08:34 +0300
Subject: Chrooted SFTP-only users along with normal SFTP
Message-ID: <20150802220834.GA32710@localhost>

Hi!

I want to set a OpenSSH server which restricts some users to only
chrooted SFTP, while others have full/normal ssh, scp and sftp access.

Most or all guides on the web say that I should enable the config line
"Subsytem sftp internal-sftp" among other things, but I've found out
that this only causes non-restricted users to not be able use SFTP at
all, only the chrooted users.  Without it users can be still be
chrooted and forced to use only SFTP - all seems fine.

Should I really use this config line?  What does it do?  Are the
guides wrong?  Here are some guides I've seen:

https://wiki.archlinux.org/index.php/SFTP_chroot
http://www.thegeekstuff.com/2012/03/chroot-sftp-setup/

My config file (just the important and changed parts):

  PasswordAuthentication no

  Subsystem sftp /usr/lib/openssh/sftp-server
  # Subsystem sftp internal-ftp

  Match User developer
    ChrootDirectory %h
    ForceCommand internal-sftp
    PasswordAuthentication yes
    AllowTcpForwarding no
    PermitTunnel no
    X11Forwarding no

I'm using Trisquel 7, which should be identical to Ubuntu 14.04.

Thank you!

From djm at mindrot.org  Mon Aug  3 09:59:39 2015
From: djm at mindrot.org (Damien Miller)
Date: Mon, 3 Aug 2015 09:59:39 +1000 (AEST)
Subject: Chrooted SFTP-only users along with normal SFTP
In-Reply-To: <20150802220834.GA32710@localhost>
References: <20150802220834.GA32710@localhost>
Message-ID: <alpine.BSO.2.20.1508030957290.8403@natsu.mindrot.org>

On Mon, 3 Aug 2015, Martin wrote:

> Hi!
> 
> I want to set a OpenSSH server which restricts some users to only
> chrooted SFTP, while others have full/normal ssh, scp and sftp access.
> 
> Most or all guides on the web say that I should enable the config line
> "Subsytem sftp internal-sftp" among other things, but I've found out
> that this only causes non-restricted users to not be able use SFTP at
> all, only the chrooted users.  Without it users can be still be
> chrooted and forced to use only SFTP - all seems fine.
> 
> Should I really use this config line?  What does it do?  Are the
> guides wrong?  Here are some guides I've seen:
> 
> https://wiki.archlinux.org/index.php/SFTP_chroot
> http://www.thegeekstuff.com/2012/03/chroot-sftp-setup/
> 
> My config file (just the important and changed parts):
> 
>   PasswordAuthentication no
> 
>   Subsystem sftp /usr/lib/openssh/sftp-server
>   # Subsystem sftp internal-ftp
                     ^^^^^^^^^^^^^
Are you sure the problem isn't just a typo? It should be internal-sftp,
not internal-ftp.

>   Match User developer
>     ChrootDirectory %h
>     ForceCommand internal-sftp
>     PasswordAuthentication yes
>     AllowTcpForwarding no
>     PermitTunnel no
>     X11Forwarding no

If you want this account to be sftp-only then this will work fine and
you won't need to adjust the top-level Subsystem declaration, as
ForceCommand overrides it anyway.

-d

From martin at libtec.org  Mon Aug  3 11:32:10 2015
From: martin at libtec.org (Martin)
Date: Mon, 3 Aug 2015 04:32:10 +0300
Subject: Chrooted SFTP-only users along with normal SFTP
In-Reply-To: <alpine.BSO.2.20.1508030957290.8403@natsu.mindrot.org>
References: <20150802220834.GA32710@localhost>
 <alpine.BSO.2.20.1508030957290.8403@natsu.mindrot.org>
Message-ID: <20150803013210.GA1308@localhost>

> Are you sure the problem isn't just a typo? It should be internal-sftp,
> not internal-ftp.

Yes, that's exactly what the problems was and I can't believe I didn't
see it after messing with it so much.  Thank you!

From ag4ve.us at gmail.com  Mon Aug  3 19:03:18 2015
From: ag4ve.us at gmail.com (shawn wilson)
Date: Mon, 3 Aug 2015 05:03:18 -0400
Subject: Option to make IdentityFile act like other options
Message-ID: <CAH_OBieQpVTmyOZ64NPVM-G2YLUCuxfDR2wrRzMuvG6k4C-v4g@mail.gmail.com>

I would like an option so that IdentityFile only allows one file path
and ignores others after one is set. I mainly make this work with:

Host a* b* c*
  IdentityFile foo

Host *
  IdentityFile bar

But for some reason the sorting is wrong w/ some hosts (or maybe it's
an actual random hash like lookup table now?) and I'm getting some:
Aug  2 17:56:16 host sshd[2278]: Failed publickey for swilson from
1.2.3.4 port 45057 ssh2: ED25519
SHA256:m7EFGJRMFAcMVakPCm+atVGmvwkoVM61jaNy7N+ZUSU

Which is kind of annoying (I don't want to ignore "Failed publickey"
messages but the noise is annoying).

From BM-2cWsANpGbN7DB7DvP7jHAoaaPeCg2Stacm at bitmessage.ch  Wed Aug  5 21:25:52 2015
From: BM-2cWsANpGbN7DB7DvP7jHAoaaPeCg2Stacm at bitmessage.ch (BitMessenger)
Date: Wed, 05 Aug 2015 13:25:52 +0200
Subject: host key on hardware
Message-ID: <1438773952.3116.9.camel@x60>

Hi,

I'm new to this list. 
For some years I've used CryptoSticks and YubiKeys to authenticate to
SSH on the client side.
Now I wondered if the same also worked on the server side.
The closest I found was this old thread from 2012:
http://www.gossamer-threads.com/lists/openssh/dev/54825
How did this progress further? Is it in the packages in the debian
repositories yet? And is there some documentation on how to set it up?

Rgds
Richard



From mike at sentex.net  Wed Aug  5 23:16:44 2015
From: mike at sentex.net (Mike Tancsa)
Date: Wed, 5 Aug 2015 09:16:44 -0400
Subject: host key on hardware
In-Reply-To: <1438773952.3116.9.camel@x60>
References: <1438773952.3116.9.camel@x60>
Message-ID: <55C20CBC.9090402@sentex.net>

On 8/5/2015 7:25 AM, BitMessenger wrote:
> Hi,
> 
> I'm new to this list. 
> For some years I've used CryptoSticks and YubiKeys to authenticate to
> SSH on the client side.
> Now I wondered if the same also worked on the server side.
> The closest I found was this old thread from 2012:
> http://www.gossamer-threads.com/lists/openssh/dev/54825

You mean like this ?

http://www.tancsa.com/mdtblog/?p=73

	---Mike


-- 
-------------------
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, mike at sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/

From martin at winscp.net  Thu Aug  6 00:09:12 2015
From: martin at winscp.net (Martin Prikryl)
Date: Wed, 5 Aug 2015 16:09:12 +0200
Subject: WinSCP 5.7.5 will support the RFC 4419 revision to Diffie-Hellman
 group exchange
In-Reply-To: <55AD4745.7000604@winscp.net>
References: <55AD4745.7000604@winscp.net>
Message-ID: <55C21908.4000406@winscp.net>

Hello,

In case my previous appeal was ignored due to a lack of patch, I'm
attaching one know.

Thanks in advance for applying it.

WinSCP 5.7.5, with RFC 4419 support, was released meanwhile.
http://winscp.net/eng/download.php

Martin Prikryl
http://winscp.net/

On 20. 7. 2015 21:08, Martin Prikryl wrote:
> Hello,
>
> I'd like to inform you that the next release of WinSCP SFTP client (version 5.7.5) will support Diffie-Hellman group exchange as specified by RFC 4419.
> http://winscp.net/tracker/show_bug.cgi?id=1345
>
> So I'd like to ask you to kindly update the check in
> compat_datafellows() to
>
> WinSCP_release_4*
> WinSCP_release_5.0*
> WinSCP_release_5.1*
> WinSCP_release_5.2*
> WinSCP_release_5.5*
> WinSCP_release_5.6*
> WinSCP_release_5.7
> WinSCP_release_5.7.1
> WinSCP_release_5.7.2
> WinSCP_release_5.7.3
> WinSCP_release_5.7.4
>
> If you want to test this, please use:
> http://winscp.net/public/winscp20150720ropenssh.zip
>
> Thanks.
>
> Martin Prikryl
> https://winscp.net/
>

-------------- next part --------------
diff -ur a/compat.c b/compat.c
--- a/compat.c	Sun Aug  2 11:59:26 2015
+++ b/compat.c	Mon Aug  3 15:42:29 2015
@@ -174,7 +174,21 @@
 		  "PuTTY_Release_0.61*,"
 		  "PuTTY_Release_0.62*,"
 		  "PuTTY_Release_0.63*,"
-		  "PuTTY_Release_0.64*",
+		  "PuTTY_Release_0.64*,"
+		  "WinSCP_release_4*,"
+		  "WinSCP_release_5.0,"
+		  "WinSCP_release_5.0.*,"
+		  "WinSCP_release_5.1,"
+		  "WinSCP_release_5.1.*,"
+		  "WinSCP_release_5.5,"
+		  "WinSCP_release_5.5.*,"
+		  "WinSCP_release_5.6,"
+		  "WinSCP_release_5.6.*,"
+		  "WinSCP_release_5.7,"
+		  "WinSCP_release_5.7.1,"
+		  "WinSCP_release_5.7.2,"
+		  "WinSCP_release_5.7.3,"
+		  "WinSCP_release_5.7.4",
 					SSH_OLD_DHGEX },
 		{ "Probe-*",
 					SSH_BUG_PROBE },

From list at eworm.de  Thu Aug  6 06:41:45 2015
From: list at eworm.de (Christian Hesse)
Date: Wed,  5 Aug 2015 22:41:45 +0200
Subject: [PATCH 1/1] uid for expansion in ControlPath
Message-ID: <1438807305-31624-1-git-send-email-list@eworm.de>

From: Christian Hesse <mail at eworm.de>

Modern Linux systems create a private directory in /run/user/ for each
user, named by user id. This adds a new character sequence '%i' for
expansion in ControlPath to match thisi directory.

Signed-off-by: Christian Hesse <mail at eworm.de>
---
 ssh.c        | 5 ++++-
 ssh_config.5 | 4 +++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/ssh.c b/ssh.c
index 59c1f93..c4de144 100644
--- a/ssh.c
+++ b/ssh.c
@@ -505,7 +505,8 @@ main(int ac, char **av)
 {
 	int i, r, opt, exit_status, use_syslog, config_test = 0;
 	char *p, *cp, *line, *argv0, buf[PATH_MAX], *host_arg, *logfile;
-	char thishost[NI_MAXHOST], shorthost[NI_MAXHOST], portstr[NI_MAXSERV];
+	char thishost[NI_MAXHOST], shorthost[NI_MAXHOST], portstr[NI_MAXSERV],
+	    uidstr[11];
 	char cname[NI_MAXHOST];
 	struct stat st;
 	struct passwd *pw;
@@ -1122,6 +1123,7 @@ main(int ac, char **av)
 	strlcpy(shorthost, thishost, sizeof(shorthost));
 	shorthost[strcspn(thishost, ".")] = '\0';
 	snprintf(portstr, sizeof(portstr), "%d", options.port);
+	snprintf(uidstr, sizeof(uidstr), "%d", pw->pw_uid);
 
 	if ((md = ssh_digest_start(SSH_DIGEST_SHA1)) == NULL ||
 	    ssh_digest_update(md, thishost, strlen(thishost)) < 0 ||
@@ -1164,6 +1166,7 @@ main(int ac, char **av)
 		    "p", portstr,
 		    "r", options.user,
 		    "u", pw->pw_name,
+		    "i", uidstr,
 		    (char *)NULL);
 		free(cp);
 	}
diff --git a/ssh_config.5 b/ssh_config.5
index 5b0975f..852f79d 100644
--- a/ssh_config.5
+++ b/ssh_config.5
@@ -538,7 +538,9 @@ the destination port,
 .Ql %r
 by the remote login username,
 .Ql %u
-by the username of the user running
+by the username and
+.Ql %i
+by the userid of the user running
 .Xr ssh 1 , and
 .Ql \&%C
 by a hash of the concatenation: %l%h%p%r.
-- 
2.5.0


From list at eworm.de  Thu Aug  6 06:47:37 2015
From: list at eworm.de (Christian Hesse)
Date: Wed,  5 Aug 2015 22:47:37 +0200
Subject: [PATCH 1/1] document all hash algorithms available for key
 fingerprint display
Message-ID: <1438807657-32564-1-git-send-email-list@eworm.de>

From: Christian Hesse <mail at eworm.de>

Signed-off-by: Christian Hesse <mail at eworm.de>
---
 ssh_config.5 | 8 ++++++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/ssh_config.5 b/ssh_config.5
index 5b0975f..28f7714 100644
--- a/ssh_config.5
+++ b/ssh_config.5
@@ -649,9 +649,13 @@ The default is
 .It Cm FingerprintHash
 Specifies the hash algorithm used when displaying key fingerprints.
 Valid options are:
-.Dq md5
+.Dq md5 ,
+.Dq ripemd160 ,
+.Dq sha1 ,
+.Dq sha256 ,
+.Dq sha384
 and
-.Dq sha256 .
+.Dq sha512 .
 The default is
 .Dq sha256 .
 .It Cm ForwardAgent
-- 
2.5.0


From dkg at fifthhorseman.net  Thu Aug  6 07:26:12 2015
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 05 Aug 2015 17:26:12 -0400
Subject: [PATCH 1/1] uid for expansion in ControlPath
In-Reply-To: <1438807305-31624-1-git-send-email-list@eworm.de>
References: <1438807305-31624-1-git-send-email-list@eworm.de>
Message-ID: <87614tzatn.fsf@alice.fifthhorseman.net>

On Wed 2015-08-05 16:41:45 -0400, Christian Hesse wrote:
> From: Christian Hesse <mail at eworm.de>
>
> Modern Linux systems create a private directory in /run/user/ for each
> user, named by user id. This adds a new character sequence '%i' for
> expansion in ControlPath to match thisi directory.

could we say "numeric user id" instead of "user id"?  i think it would
be clearer.

   --dkg

From peter at stuge.se  Thu Aug  6 08:07:24 2015
From: peter at stuge.se (Peter Stuge)
Date: Thu, 6 Aug 2015 00:07:24 +0200
Subject: [PATCH 1/1] uid for expansion in ControlPath
In-Reply-To: <87614tzatn.fsf@alice.fifthhorseman.net>
References: <1438807305-31624-1-git-send-email-list@eworm.de>
 <87614tzatn.fsf@alice.fifthhorseman.net>
Message-ID: <20150805220724.9197.qmail@stuge.se>

Daniel Kahn Gillmor wrote:
> > Modern Linux systems create a private directory in /run/user/ for each
> > user, named by user id. This adds a new character sequence '%i' for
> > expansion in ControlPath to match thisi directory.
> 
> could we say "numeric user id" instead of "user id"?  i think it would
> be clearer.

I'd like uid please.


//Peter

From djm at mindrot.org  Thu Aug  6 11:05:42 2015
From: djm at mindrot.org (Damien Miller)
Date: Thu, 6 Aug 2015 11:05:42 +1000 (AEST)
Subject: WinSCP 5.7.5 will support the RFC 4419 revision to Diffie-Hellman
 group exchange
In-Reply-To: <55C21908.4000406@winscp.net>
References: <55AD4745.7000604@winscp.net> <55C21908.4000406@winscp.net>
Message-ID: <alpine.BSO.2.20.1508061102070.8403@natsu.mindrot.org>

sorry, I missed your email. The best way to ensure that this gets fixed is
to file a bug at https://bugzilla.mindrot.org/

I've done this, and the bug is https://bugzilla.mindrot.org/b/2441

On Wed, 5 Aug 2015, Martin Prikryl wrote:

> Hello,
> 
> In case my previous appeal was ignored due to a lack of patch, I'm
> attaching one know.
> 
> Thanks in advance for applying it.
> 
> WinSCP 5.7.5, with RFC 4419 support, was released meanwhile.
> http://winscp.net/eng/download.php
> 
> Martin Prikryl
> http://winscp.net/
> 
> On 20. 7. 2015 21:08, Martin Prikryl wrote:
> > Hello,
> >
> > I'd like to inform you that the next release of WinSCP SFTP client (version 5.7.5) will support Diffie-Hellman group exchange as specified by RFC 4419.
> > http://winscp.net/tracker/show_bug.cgi?id=1345
> >
> > So I'd like to ask you to kindly update the check in
> > compat_datafellows() to
> >
> > WinSCP_release_4*
> > WinSCP_release_5.0*
> > WinSCP_release_5.1*
> > WinSCP_release_5.2*
> > WinSCP_release_5.5*
> > WinSCP_release_5.6*
> > WinSCP_release_5.7
> > WinSCP_release_5.7.1
> > WinSCP_release_5.7.2
> > WinSCP_release_5.7.3
> > WinSCP_release_5.7.4
> >
> > If you want to test this, please use:
> > http://winscp.net/public/winscp20150720ropenssh.zip
> >
> > Thanks.
> >
> > Martin Prikryl
> > https://winscp.net/
> >
> 
> 

From list at eworm.de  Thu Aug  6 15:51:37 2015
From: list at eworm.de (Christian Hesse)
Date: Thu,  6 Aug 2015 07:51:37 +0200
Subject: [PATCH 1/1] uid for expansion in ControlPath
In-Reply-To: <20150805220724.9197.qmail@stuge.se>
References: <20150805220724.9197.qmail@stuge.se>
Message-ID: <1438840297-14786-1-git-send-email-list@eworm.de>

From: Christian Hesse <mail at eworm.de>

Modern Linux systems create a private directory in /run/user/ for each
user, named by numeric user id (uid). This adds a new character sequence
'%i' for expansion in ControlPath to match this (and possibly other)
directory.

Signed-off-by: Christian Hesse <mail at eworm.de>
---
 ssh.c        | 5 ++++-
 ssh_config.5 | 4 +++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/ssh.c b/ssh.c
index 59c1f93..c4de144 100644
--- a/ssh.c
+++ b/ssh.c
@@ -505,7 +505,8 @@ main(int ac, char **av)
 {
 	int i, r, opt, exit_status, use_syslog, config_test = 0;
 	char *p, *cp, *line, *argv0, buf[PATH_MAX], *host_arg, *logfile;
-	char thishost[NI_MAXHOST], shorthost[NI_MAXHOST], portstr[NI_MAXSERV];
+	char thishost[NI_MAXHOST], shorthost[NI_MAXHOST], portstr[NI_MAXSERV],
+	    uidstr[11];
 	char cname[NI_MAXHOST];
 	struct stat st;
 	struct passwd *pw;
@@ -1122,6 +1123,7 @@ main(int ac, char **av)
 	strlcpy(shorthost, thishost, sizeof(shorthost));
 	shorthost[strcspn(thishost, ".")] = '\0';
 	snprintf(portstr, sizeof(portstr), "%d", options.port);
+	snprintf(uidstr, sizeof(uidstr), "%d", pw->pw_uid);
 
 	if ((md = ssh_digest_start(SSH_DIGEST_SHA1)) == NULL ||
 	    ssh_digest_update(md, thishost, strlen(thishost)) < 0 ||
@@ -1164,6 +1166,7 @@ main(int ac, char **av)
 		    "p", portstr,
 		    "r", options.user,
 		    "u", pw->pw_name,
+		    "i", uidstr,
 		    (char *)NULL);
 		free(cp);
 	}
diff --git a/ssh_config.5 b/ssh_config.5
index 5b0975f..489452e 100644
--- a/ssh_config.5
+++ b/ssh_config.5
@@ -538,7 +538,9 @@ the destination port,
 .Ql %r
 by the remote login username,
 .Ql %u
-by the username of the user running
+by the username and
+.Ql %i
+by the numeric user id (uid) of the user running
 .Xr ssh 1 , and
 .Ql \&%C
 by a hash of the concatenation: %l%h%p%r.
-- 
2.5.0


From BM-2cWsANpGbN7DB7DvP7jHAoaaPeCg2Stacm at bitmessage.ch  Thu Aug  6 16:24:50 2015
From: BM-2cWsANpGbN7DB7DvP7jHAoaaPeCg2Stacm at bitmessage.ch (BitMessenger)
Date: Thu, 06 Aug 2015 08:24:50 +0200
Subject: host key on hardware
In-Reply-To: <55C20CBC.9090402@sentex.net>
References: <1438773952.3116.9.camel@x60> <55C20CBC.9090402@sentex.net>
Message-ID: <1438842290.3076.1.camel@x60>

Hi Mike,

yes, that looks like an excellent starting point.
I'm still wondering if it would work with an OpenPGP SmartCard.

Rgds
Richard

Am Mittwoch, den 05.08.2015, 09:16 -0400 schrieb Mike Tancsa:
> On 8/5/2015 7:25 AM, BitMessenger wrote:
> > Hi,
> > 
> > I'm new to this list. 
> > For some years I've used CryptoSticks and YubiKeys to authenticate to
> > SSH on the client side.
> > Now I wondered if the same also worked on the server side.
> > The closest I found was this old thread from 2012:
> > http://www.gossamer-threads.com/lists/openssh/dev/54825
> 
> You mean like this ?
> 
> http://www.tancsa.com/mdtblog/?p=73
> 
> 	---Mike
> 
> 




From jjelen at redhat.com  Thu Aug  6 18:54:39 2015
From: jjelen at redhat.com (Jakub Jelen)
Date: Thu, 6 Aug 2015 10:54:39 +0200
Subject: [PATCH 1/1] document all hash algorithms available for key
 fingerprint display
In-Reply-To: <1438807657-32564-1-git-send-email-list@eworm.de>
References: <1438807657-32564-1-git-send-email-list@eworm.de>
Message-ID: <55C320CF.6090201@redhat.com>

I filled bug [1] on the same topic yesterday with different approach. I 
don't think the intention was to provide all hashing algorithms for 
fingerprints, but to slowly obsolete md5, replacing by sha256.

But the final decision and clarification what was the real intention 
depends again on developers.

On 08/05/2015 10:47 PM, Christian Hesse wrote:
> From: Christian Hesse <mail at eworm.de>
>
> Signed-off-by: Christian Hesse <mail at eworm.de>
> ---
>   ssh_config.5 | 8 ++++++--
>   1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/ssh_config.5 b/ssh_config.5
> index 5b0975f..28f7714 100644
> --- a/ssh_config.5
> +++ b/ssh_config.5
> @@ -649,9 +649,13 @@ The default is
>   .It Cm FingerprintHash
>   Specifies the hash algorithm used when displaying key fingerprints.
>   Valid options are:
> -.Dq md5
> +.Dq md5 ,
> +.Dq ripemd160 ,
> +.Dq sha1 ,
> +.Dq sha256 ,
> +.Dq sha384
>   and
> -.Dq sha256 .
> +.Dq sha512 .
>   The default is
>   .Dq sha256 .
>   .It Cm ForwardAgent

-- 
Jakub Jelen
Security Technologies
Red Hat


From list at eworm.de  Thu Aug  6 19:07:28 2015
From: list at eworm.de (Christian Hesse)
Date: Thu, 6 Aug 2015 11:07:28 +0200
Subject: [PATCH 1/1] document all hash algorithms available for key
 fingerprint display
In-Reply-To: <55C320CF.6090201@redhat.com>
References: <1438807657-32564-1-git-send-email-list@eworm.de>
 <55C320CF.6090201@redhat.com>
Message-ID: <20150806110728.4f4e25f6@leda.localdomain>

Jakub Jelen <jjelen at redhat.com> on Thu, 2015/08/06 10:54:
> I filled bug [1] on the same topic yesterday

You missed to add the link. ;)

> with different approach. I 
> don't think the intention was to provide all hashing algorithms for 
> fingerprints, but to slowly obsolete md5, replacing by sha256.

Obsoleting md5 makes sense, but there is nothing wrong with providing
sha{1,384,512} for fingerprinting.
However documentation should be consistent with code.
-- 
main(a){char*c=/*    Schoene Gruesse                         */"B?IJj;MEH"
"CX:;",b;for(a/*    Chris           get my mail address:    */=0;b=c[a++];)
putchar(b-1/(/*               gcc -o sig sig.c && ./sig    */b/42*2-3)*42);}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150806/f3b79135/attachment-0001.bin>

From jjelen at redhat.com  Thu Aug  6 19:09:07 2015
From: jjelen at redhat.com (Jakub Jelen)
Date: Thu, 6 Aug 2015 11:09:07 +0200
Subject: [PATCH 1/1] document all hash algorithms available for key
 fingerprint display
In-Reply-To: <20150806110728.4f4e25f6@leda.localdomain>
References: <1438807657-32564-1-git-send-email-list@eworm.de>
 <55C320CF.6090201@redhat.com> <20150806110728.4f4e25f6@leda.localdomain>
Message-ID: <55C32433.70007@redhat.com>


On 08/06/2015 11:07 AM, Christian Hesse wrote:
> Jakub Jelen <jjelen at redhat.com> on Thu, 2015/08/06 10:54:
>> I filled bug [1] on the same topic yesterday
> You missed to add the link. ;)
Sure :)
[1] https://bugzilla.mindrot.org/show_bug.cgi?id=2439
>> with different approach. I
>> don't think the intention was to provide all hashing algorithms for
>> fingerprints, but to slowly obsolete md5, replacing by sha256.
> Obsoleting md5 makes sense, but there is nothing wrong with providing
> sha{1,384,512} for fingerprinting.
> However documentation should be consistent with code.

-- 
Jakub Jelen
Associate Software Engineer
Security Technologies
Red Hat


From michael at stroeder.com  Sat Aug  8 21:44:44 2015
From: michael at stroeder.com (=?UTF-8?Q?Michael_Str=c3=b6der?=)
Date: Sat, 08 Aug 2015 13:44:44 +0200
Subject: host key on hardware
In-Reply-To: <1438842290.3076.1.camel@x60>
References: <1438773952.3116.9.camel@x60> <55C20CBC.9090402@sentex.net>
 <1438842290.3076.1.camel@x60>
Message-ID: <55C5EBAC.8070905@stroeder.com>

BitMessenger wrote:
> yes, that looks like an excellent starting point.
> I'm still wondering if it would work with an OpenPGP SmartCard.

Is an OpenPGP SmartCard really fast enough?

Ciao, Michael.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4272 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150808/4c1a0d55/attachment.bin>

From lauri.vosandi at gmail.com  Sun Aug  9 06:29:48 2015
From: lauri.vosandi at gmail.com (lauri)
Date: Sat, 8 Aug 2015 23:29:48 +0300
Subject: UNIX domain socket forwarding enhancements
Message-ID: <CAJ1pDqQ82W=joD2H3cm5svZgnXSJQ8ii1Qdcwab_J3tdthKK0A@mail.gmail.com>

Hello,

please add remote home expansion for the UNIX domain socket
forwarding, making it possible to do something like RemoteForward
~/.blah /var/run/blah/blah

-- 
Lauri V?sandi
tel: +372 53329412
e-mail: lauri.vosandi at gmail.com
blog: http://lauri.vosandi.com/

From osandov at osandov.com  Sun Aug  9 17:30:22 2015
From: osandov at osandov.com (Omar Sandoval)
Date: Sun,  9 Aug 2015 00:30:22 -0700
Subject: [PATCH] Add a ssh_config Term option to override TERM
Message-ID: <9c7d098608ea9ca6ececdbc8d7a4a7bc3f4ee879.1439105166.git.osandov@osandov.com>

This is useful when a server is missing the necessary terminfo and
avoids having to manually set TERM before invoking ssh every time.

Signed-off-by: Omar Sandoval <osandov at osandov.com>
---
 mux.c        |  2 +-
 readconf.c   | 10 +++++++++-
 readconf.h   |  2 ++
 ssh.c        |  7 +++++--
 ssh_config.5 |  5 +++++
 5 files changed, 22 insertions(+), 4 deletions(-)

diff --git a/mux.c b/mux.c
index cdc01bd4fff5..1aa21f8eee27 100644
--- a/mux.c
+++ b/mux.c
@@ -1814,7 +1814,7 @@ mux_client_request_session(int fd)
 			close(devnull);
 	}
 
-	term = getenv("TERM");
+	term = options.term;
 
 	buffer_init(&m);
 	buffer_put_int(&m, MUX_C_NEW_SESSION);
diff --git a/readconf.c b/readconf.c
index 1d03bdf72d92..27169a8e9094 100644
--- a/readconf.c
+++ b/readconf.c
@@ -148,7 +148,7 @@ typedef enum {
 	oEnableSSHKeysign, oRekeyLimit, oVerifyHostKeyDNS, oConnectTimeout,
 	oAddressFamily, oGssAuthentication, oGssDelegateCreds,
 	oServerAliveInterval, oServerAliveCountMax, oIdentitiesOnly,
-	oSendEnv, oControlPath, oControlMaster, oControlPersist,
+	oSendEnv, oTerm, oControlPath, oControlMaster, oControlPersist,
 	oHashKnownHosts,
 	oTunnel, oTunnelDevice, oLocalCommand, oPermitLocalCommand,
 	oVisualHostKey, oUseRoaming,
@@ -251,6 +251,7 @@ static struct {
 	{ "serveraliveinterval", oServerAliveInterval },
 	{ "serveralivecountmax", oServerAliveCountMax },
 	{ "sendenv", oSendEnv },
+	{ "term", oTerm },
 	{ "controlpath", oControlPath },
 	{ "controlmaster", oControlMaster },
 	{ "controlpersist", oControlPersist },
@@ -1294,6 +1295,10 @@ parse_keytypes:
 		}
 		break;
 
+	case oTerm:
+		charptr = &options->term;
+		goto parse_string;
+
 	case oControlPath:
 		charptr = &options->control_path;
 		goto parse_string;
@@ -1650,6 +1655,7 @@ initialize_options(Options * options)
 	options->server_alive_interval = -1;
 	options->server_alive_count_max = -1;
 	options->num_send_env = 0;
+	options->term = NULL;
 	options->control_path = NULL;
 	options->control_master = -1;
 	options->control_persist = -1;
@@ -1879,6 +1885,7 @@ fill_default_options(Options * options)
 	/* options->hostname will be set in the main program if appropriate */
 	/* options->host_key_alias should not be set by default */
 	/* options->preferred_authentications will be set in ssh */
+	/* options->term will be set in ssh */
 }
 
 struct fwdarg {
@@ -2302,6 +2309,7 @@ dump_client_config(Options *o, const char *host)
 	/* String options */
 	dump_cfg_string(oBindAddress, o->bind_address);
 	dump_cfg_string(oCiphers, o->ciphers ? o->ciphers : KEX_CLIENT_ENCRYPT);
+	dump_cfg_string(oTerm, o->term);
 	dump_cfg_string(oControlPath, o->control_path);
 	dump_cfg_string(oHostKeyAlgorithms, o->hostkeyalgorithms ? o->hostkeyalgorithms : KEX_DEFAULT_PK_ALG);
 	dump_cfg_string(oHostKeyAlias, o->host_key_alias);
diff --git a/readconf.h b/readconf.h
index bb2d55283dd0..17e02f24ae4e 100644
--- a/readconf.h
+++ b/readconf.h
@@ -115,6 +115,8 @@ typedef struct {
 	int     num_send_env;
 	char   *send_env[MAX_SEND_ENV];
 
+	char   *term;
+
 	char	*control_path;
 	int	control_master;
 	int     control_persist; /* ControlPersist flag */
diff --git a/ssh.c b/ssh.c
index 59c1f931cb0a..60a661ac3ac8 100644
--- a/ssh.c
+++ b/ssh.c
@@ -1117,6 +1117,9 @@ main(int ac, char **av)
 	if (options.user == NULL)
 		options.user = xstrdup(pw->pw_name);
 
+	if (options.term == NULL)
+		options.term = getenv("TERM");
+
 	if (gethostname(thishost, sizeof(thishost)) == -1)
 		fatal("gethostname: %s", strerror(errno));
 	strlcpy(shorthost, thishost, sizeof(shorthost));
@@ -1638,7 +1641,7 @@ ssh_session(void)
 
 		/* Store TERM in the packet.  There is no limit on the
 		   length of the string. */
-		cp = getenv("TERM");
+		cp = options.term;
 		if (!cp)
 			cp = "";
 		packet_put_cstring(cp);
@@ -1804,7 +1807,7 @@ ssh_session2_setup(int id, int success, void *arg)
 	packet_set_interactive(interactive,
 	    options.ip_qos_interactive, options.ip_qos_bulk);
 
-	client_session2_setup(id, tty_flag, subsystem_flag, getenv("TERM"),
+	client_session2_setup(id, tty_flag, subsystem_flag, options.term,
 	    NULL, fileno(stdin), &command, environ);
 }
 
diff --git a/ssh_config.5 b/ssh_config.5
index 5b0975f87e2f..da075f2164df 100644
--- a/ssh_config.5
+++ b/ssh_config.5
@@ -1521,6 +1521,11 @@ This is important in scripts, and many users want it too.
 .Pp
 To disable TCP keepalive messages, the value should be set to
 .Dq no .
+.It Cm Term
+Overrides the
+.Ev TERM
+environment variable which is sent to the server. This can be useful when the
+server does not have the proper terminfo installed.
 .It Cm Tunnel
 Request
 .Xr tun 4
-- 
2.5.0


From nkadel at gmail.com  Mon Aug 10 00:04:38 2015
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Sun, 9 Aug 2015 10:04:38 -0400
Subject: [PATCH] Add a ssh_config Term option to override TERM
In-Reply-To: <9c7d098608ea9ca6ececdbc8d7a4a7bc3f4ee879.1439105166.git.osandov@osandov.com>
References: <9c7d098608ea9ca6ececdbc8d7a4a7bc3f4ee879.1439105166.git.osandov@osandov.com>
Message-ID: <CAOCN9rxWcDsORj5Vh-mueCSy_vJYz8D=hQx=m0U0F4QoS4Cn0g@mail.gmail.com>

On Sun, Aug 9, 2015 at 3:30 AM, Omar Sandoval <osandov at osandov.com> wrote:
> This is useful when a server is missing the necessary terminfo and
> avoids having to manually set TERM before invoking ssh every time.
>
> Signed-off-by: Omar Sandoval <osandov at osandov.com>

And it doesn't fit within 'AcceptEnv' because of the disparity of
availalbe TERM settings, right. I've actually run into this problem
and would welcome the change. The code looks pretty clean.

From m.stolarek at icm.edu.pl  Mon Aug 10 18:44:32 2015
From: m.stolarek at icm.edu.pl (Marcin Stolarek)
Date: Mon, 10 Aug 2015 10:44:32 +0200 (CEST)
Subject: sftp and ControlPath 
Message-ID: <alpine.DEB.2.10.1508101032490.23898@cinek-ws>

Hi guys,

I've check that when using sftp with -o ControlPath=... the first attempt 
just hangs. Can someone point me to appropriate lines in code where can I 
check whats going on?

Maybe it's known issue? I'm using  5.3p1.

cheers,
marcin

From djm at cvs.openbsd.org  Tue Aug 11 22:53:24 2015
From: djm at cvs.openbsd.org (Damien Miller)
Date: Tue, 11 Aug 2015 06:53:24 -0600 (MDT)
Subject: Announce: OpenSSH 7.0 released
Message-ID: <14355436344777315020.enqueue@cvs.openbsd.org>

OpenSSH 7.0 has just been released. It will be available from the
mirrors listed at http://www.openssh.com/ shortly.

OpenSSH is a 100% complete SSH protocol 2.0 implementation and
includes sftp client and server support. OpenSSH also includes
transitional support for the legacy SSH 1.3 and 1.5 protocols
that may be enabled at compile-time.

Once again, we would like to thank the OpenSSH community for their
continued support of the project, especially those who contributed
code or patches, reported bugs, tested snapshots or donated to the
project. More information on donations may be found at:
http://www.openssh.com/donations.html

Future deprecation notice
=========================

We plan on retiring more legacy cryptography in the next release
including:

 * Refusing all RSA keys smaller than 1024 bits (the current minimum
   is 768 bits)

 * Several ciphers will be disabled by default: blowfish-cbc,
   cast128-cbc, all arcfour variants and the rijndael-cbc aliases
   for AES.

 * MD5-based HMAC algorithms will be disabled by default.

This list reflects our current intentions, but please check the final
release notes for OpenSSH 7.1 when it is released.

Changes since OpenSSH 6.9
=========================

This focus of this release is primarily to deprecate weak, legacy
and/or unsafe cryptography.

Security
--------

 * sshd(8): OpenSSH 6.8 and 6.9 incorrectly set TTYs to be world-
   writable. Local attackers may be able to write arbitrary messages
   to logged-in users, including terminal escape sequences.
   Reported by Nikolay Edigaryev.

 * sshd(8): Portable OpenSSH only: Fixed a privilege separation
   weakness related to PAM support. Attackers who could successfully
   compromise the pre-authentication process for remote code
   execution and who had valid credentials on the host could
   impersonate other users.  Reported by Moritz Jodeit.

 * sshd(8): Portable OpenSSH only: Fixed a use-after-free bug
   related to PAM support that was reachable by attackers who could
   compromise the pre-authentication process for remote code
   execution. Also reported by Moritz Jodeit.

 * sshd(8): fix circumvention of MaxAuthTries using keyboard-
   interactive authentication. By specifying a long, repeating
   keyboard-interactive "devices" string, an attacker could request
   the same authentication method be tried thousands of times in
   a single pass. The LoginGraceTime timeout in sshd(8) and any
   authentication failure delays implemented by the authentication
   mechanism itself were still applied. Found by Kingcope.

Potentially-incompatible Changes
--------------------------------

 * Support for the legacy SSH version 1 protocol is disabled by
   default at compile time.

 * Support for the 1024-bit diffie-hellman-group1-sha1 key exchange
   is disabled by default at run-time. It may be re-enabled using
   the instructions at http://www.openssh.com/legacy.html

 * 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

 * Support for the legacy v00 cert format has been removed.

 * The default for the sshd_config(5) PermitRootLogin option has
   changed from "yes" to "prohibit-password".

 * PermitRootLogin=without-password/prohibit-password now bans all
   interactive authentication methods, allowing only public-key,
   hostbased and GSSAPI authentication (previously it permitted
   keyboard-interactive and password-less authentication if those
   were enabled).

New Features
------------

 * ssh_config(5): add PubkeyAcceptedKeyTypes option to control which
   public key types are available for user authentication.

 * sshd_config(5): add HostKeyAlgorithms option to control which
   public key types are offered for host authentications.

 * ssh(1), sshd(8): extend Ciphers, MACs, KexAlgorithms,
   HostKeyAlgorithms, PubkeyAcceptedKeyTypes and HostbasedKeyTypes
   options to allow appending to the default set of algorithms
   instead of replacing it. Options may now be prefixed with a '+'
   to append to the default, e.g. "HostKeyAlgorithms=+ssh-dss".

 * sshd_config(5): PermitRootLogin now accepts an argument of
   'prohibit-password' as a less-ambiguous synonym of 'without-
   password'.

Bugfixes
--------

 * ssh(1), sshd(8): add compatability workarounds for Cisco and more
   PuTTY versions. bz#2424

 * Fix some omissions and errors in the PROTOCOL and PROTOCOL.mux
   documentation relating to Unix domain socket forwarding;
   bz#2421 bz#2422

 * ssh(1): Improve the ssh(1) manual page to include a better
   description of Unix domain socket forwarding; bz#2423

 * ssh(1), ssh-agent(1): skip uninitialised PKCS#11 slots, fixing
   failures to load keys when they are present. bz#2427

 * ssh(1), ssh-agent(1): do not ignore PKCS#11 hosted keys that wth
   empty CKA_ID; bz#2429

 * sshd(8): clarify documentation for UseDNS option; bz#2045

Portable OpenSSH
----------------

 * Check realpath(3) behaviour matches what sftp-server requires and
   use a replacement if necessary.

Checksums:
==========

 - SHA1 (openssh-7.0.tar.gz) = a19ff0bad2a67348b1d01a38a9580236120b7099
 - SHA256 (openssh-7.0.tar.gz) = 4F6HV/ZqT465f3sMB2vIkXO+wrYtL5hnqzAymfbZ1Jk=

 - SHA1 (openssh-7.0p1.tar.gz) = d8337c9eab91d360d104f6dd805f8b32089c063c
 - SHA256 (openssh-7.0p1.tar.gz) = /VkySToZ9MgRU9gS7k4EK0m707dZqz2TRKvswrwUheU=

Please note that the PGP key used to sign releases was recently rotated.
The new key has been signed by the old key to provide continuity. It is
available from the mirror sites as RELEASE_KEY.asc.

Reporting Bugs:
===============

- Please read http://www.openssh.com/report.html
  Security bugs should be reported directly to openssh at openssh.com

OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt,
Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and
Ben Lindstrom.


From djm at mindrot.org  Tue Aug 11 23:37:35 2015
From: djm at mindrot.org (Damien Miller)
Date: Tue, 11 Aug 2015 23:37:35 +1000 (AEST)
Subject: sftp and ControlPath
In-Reply-To: <alpine.DEB.2.10.1508101032490.23898@cinek-ws>
References: <alpine.DEB.2.10.1508101032490.23898@cinek-ws>
Message-ID: <alpine.BSO.2.20.1508112336210.32090@natsu.mindrot.org>

On Mon, 10 Aug 2015, Marcin Stolarek wrote:

> Hi guys,
> 
> I've check that when using sftp with -o ControlPath=... the first attempt just
> hangs. Can someone point me to appropriate lines in code where can I check
> whats going on?

Please post a debug log "sftp -vvv ..." - it's essential to figure out
what is going wrong.

> Maybe it's known issue? I'm using  5.3p1.

That's pretty old and there have been multiplexing-related bugs fixed since
then.

From mancha1 at zoho.com  Wed Aug 12 14:23:52 2015
From: mancha1 at zoho.com (mancha)
Date: Wed, 12 Aug 2015 04:23:52 +0000
Subject: [ANN] OpenSSH 7.0p1 TCP Wrapper support
Message-ID: <20150812042352.GA26751@zoho.com>

Hello.

Patch re-introducing TCP Wrappers (libwrap) support has been updated for
use with OpenSSH 7.0p1:

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

Note: don't forget to autoreconf -fiv.

Enjoy.

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

From istvan.bohm at gmail.com  Thu Aug 13 22:56:51 2015
From: istvan.bohm at gmail.com (=?UTF-8?B?QsO2aG0gSXN0dsOhbg==?=)
Date: Thu, 13 Aug 2015 14:56:51 +0200
Subject: openssh coverage
Message-ID: <CAGMW7g9+iWom2UMRxxMjSTQ-WnuyZua_+X-t-cc9p113UKj6tw@mail.gmail.com>

Hi,

I want to measure the coverage of tests of OpenSSH (one by one), but I
get an error, when I run the connect-privsep test. I can't find out
what is the problem.

$ ./configure --with-cflags="-fprofile-arcs -ftest-coverage"
--with-ldflags="-fprofile-arcs -lgcov"
$ make
$ env TEST_SSH_LOGFILE=/tmp/sshd.log SUDO=sudo make tests LTESTS=connect-privsep

output: http://pastebin.com/eDiC894E
sshd.log: http://pastebin.com/sWRCeQiy

I get a failed proxy connect with privsep error message.

The test runs fine without coverage flags:

$ ./configure
$ make
$ env TEST_SSH_LOGFILE=/tmp/sshd.log SUDO=sudo make tests LTESTS=connect-privsep
... all tests passed

I installed the following packages:

$ sudo apt-get install build-essential
$ sudo apt-get install zlib1g-dev
$ sudo apt-get install libssl-dev

I created the user for privilege separation too:

# mkdir /var/empty
# chown root:sys /var/empty
# chmod 755 /var/empty
# groupadd sshd
# useradd -g sshd -c 'sshd privsep' -d /var/empty -s /bin/false sshd

I tried it on:
Ubuntu 14.04 x64 VM
Ubuntu 14.04 x64
Debian 8 VM

The results were the - same. (VM=Virtual Machine)

I tried other versions of OpenSSH (6.x) too, but the results were the same.

I tried the script of this guy, but the result were the same:
http://cipherdyne.org/blog/2014/08/code-coverage-challenges-for-open-source-projects.html

Could you help me to fix this?

Best Regards,
Istvan

From dtucker at zip.com.au  Thu Aug 13 23:25:12 2015
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 13 Aug 2015 23:25:12 +1000
Subject: openssh coverage
In-Reply-To: <CAGMW7g9+iWom2UMRxxMjSTQ-WnuyZua_+X-t-cc9p113UKj6tw@mail.gmail.com>
References: <CAGMW7g9+iWom2UMRxxMjSTQ-WnuyZua_+X-t-cc9p113UKj6tw@mail.gmail.com>
Message-ID: <CALDDTe0sbEXb46Zrzgqabfc2b5Lf4DTMkGgNW9dHEXXpN0Jbaw@mail.gmail.com>

There will be two files, ssh.log and sshd.log in the regress directory, one
of which should have a hint as to what went wrong.
On Aug 13, 2015 11:10 PM, "B?hm Istv?n" <istvan.bohm at gmail.com> wrote:

> Hi,
>
> I want to measure the coverage of tests of OpenSSH (one by one), but I
> get an error, when I run the connect-privsep test. I can't find out
> what is the problem.
>
> $ ./configure --with-cflags="-fprofile-arcs -ftest-coverage"
> --with-ldflags="-fprofile-arcs -lgcov"
> $ make
> $ env TEST_SSH_LOGFILE=/tmp/sshd.log SUDO=sudo make tests
> LTESTS=connect-privsep
>
> output: http://pastebin.com/eDiC894E
> sshd.log: http://pastebin.com/sWRCeQiy
>
> I get a failed proxy connect with privsep error message.
>
> The test runs fine without coverage flags:
>
> $ ./configure
> $ make
> $ env TEST_SSH_LOGFILE=/tmp/sshd.log SUDO=sudo make tests
> LTESTS=connect-privsep
> ... all tests passed
>
> I installed the following packages:
>
> $ sudo apt-get install build-essential
> $ sudo apt-get install zlib1g-dev
> $ sudo apt-get install libssl-dev
>
> I created the user for privilege separation too:
>
> # mkdir /var/empty
> # chown root:sys /var/empty
> # chmod 755 /var/empty
> # groupadd sshd
> # useradd -g sshd -c 'sshd privsep' -d /var/empty -s /bin/false sshd
>
> I tried it on:
> Ubuntu 14.04 x64 VM
> Ubuntu 14.04 x64
> Debian 8 VM
>
> The results were the - same. (VM=Virtual Machine)
>
> I tried other versions of OpenSSH (6.x) too, but the results were the same.
>
> I tried the script of this guy, but the result were the same:
>
> http://cipherdyne.org/blog/2014/08/code-coverage-challenges-for-open-source-projects.html
>
> Could you help me to fix this?
>
> Best Regards,
> Istvan
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

From thomas.jarosch at intra2net.com  Fri Aug 14 02:04:30 2015
From: thomas.jarosch at intra2net.com (Thomas Jarosch)
Date: Thu, 13 Aug 2015 18:04:30 +0200
Subject: [PATCH] ssh-agent: Add support to load additional certificates
In-Reply-To: <55B4F422.7030405@intra2net.com>
References: <55B4F422.7030405@intra2net.com>
Message-ID: <1647204.J8msWKWJdq@storm>

Hi,

On Sunday, 26. July 2015 16:52:18 you wrote:
> Add support to load additional certificates
> for already loaded private keys. Useful
> if the private key is on a PKCS#11 hardware token.
> 
> The private keys inside ssh-agent are now using a refcount
> to share the private parts between "Identities".
> The reason for this change was that the PKCS#11 code
> might have redirected ("wrap") the RSA functions to a hardware token.
> We don't want to mess with those internals.
> 
> Tested with an OpenGPG card. Patch developed against 6.9p
> and applies to original 6.9, too.
> 
> Please CC: comments.
> 
> Signed-off-by: Thomas Jarosch <thomas.jarosch at intra2net.com>

any comment on this?

Is the concept sound or did I take the wrong turn here?

If upstream considers this the way to go, I can try
to split up the patch into smaller pieces like this:

- sshkey.c: Add "int sshkey_is_private(const struct sshkey *)" function
- ssh-agent: Transition to private key refcounting
- ssh-agent: Implement private key "shadowing"
- ssh-add: Add support to add plain certificates

Thanks in advance,
Thomas


From osandov at osandov.com  Sat Aug 15 13:35:45 2015
From: osandov at osandov.com (Omar Sandoval)
Date: Fri, 14 Aug 2015 20:35:45 -0700
Subject: [PATCH v2] Add a ssh_config Term option to override TERM
Message-ID: <c6330812bd30b6ca79ed0dd78c4b77ced166159b.1439608720.git.osandov@osandov.com>

This is useful when a server is missing the necessary terminfo and
avoids having to manually set TERM before invoking ssh every time.

Signed-off-by: Omar Sandoval <osandov at osandov.com>
---

Changes from v1:

- Allow ``none'' to force using TERM from the environment

I'll elaborate on my use case. I use suckless's st terminal, so I install the
st terminfo on the machines I frequent. On other machines, though, I end up
having to set TERM to xterm manually on the command line, e.g.,

TERM=xterm-256color ssh foo

Instead, it'd be much more convenient to do the following:

Host machine_i_use_alot
	Term none

Host *
	Term xterm-256color

So ssh will default to using xterm-256color, but on hosts that I whitelist, it
will use TERM from the environment.

 mux.c        |  2 +-
 readconf.c   | 10 +++++++++-
 readconf.h   |  2 ++
 ssh.c        |  7 +++++--
 ssh_config.5 | 10 ++++++++++
 5 files changed, 27 insertions(+), 4 deletions(-)

diff --git a/mux.c b/mux.c
index cdc01bd4fff5..1aa21f8eee27 100644
--- a/mux.c
+++ b/mux.c
@@ -1814,7 +1814,7 @@ mux_client_request_session(int fd)
 			close(devnull);
 	}
 
-	term = getenv("TERM");
+	term = options.term;
 
 	buffer_init(&m);
 	buffer_put_int(&m, MUX_C_NEW_SESSION);
diff --git a/readconf.c b/readconf.c
index 1d03bdf72d92..27169a8e9094 100644
--- a/readconf.c
+++ b/readconf.c
@@ -148,7 +148,7 @@ typedef enum {
 	oEnableSSHKeysign, oRekeyLimit, oVerifyHostKeyDNS, oConnectTimeout,
 	oAddressFamily, oGssAuthentication, oGssDelegateCreds,
 	oServerAliveInterval, oServerAliveCountMax, oIdentitiesOnly,
-	oSendEnv, oControlPath, oControlMaster, oControlPersist,
+	oSendEnv, oTerm, oControlPath, oControlMaster, oControlPersist,
 	oHashKnownHosts,
 	oTunnel, oTunnelDevice, oLocalCommand, oPermitLocalCommand,
 	oVisualHostKey, oUseRoaming,
@@ -251,6 +251,7 @@ static struct {
 	{ "serveraliveinterval", oServerAliveInterval },
 	{ "serveralivecountmax", oServerAliveCountMax },
 	{ "sendenv", oSendEnv },
+	{ "term", oTerm },
 	{ "controlpath", oControlPath },
 	{ "controlmaster", oControlMaster },
 	{ "controlpersist", oControlPersist },
@@ -1294,6 +1295,10 @@ parse_keytypes:
 		}
 		break;
 
+	case oTerm:
+		charptr = &options->term;
+		goto parse_string;
+
 	case oControlPath:
 		charptr = &options->control_path;
 		goto parse_string;
@@ -1650,6 +1655,7 @@ initialize_options(Options * options)
 	options->server_alive_interval = -1;
 	options->server_alive_count_max = -1;
 	options->num_send_env = 0;
+	options->term = NULL;
 	options->control_path = NULL;
 	options->control_master = -1;
 	options->control_persist = -1;
@@ -1879,6 +1885,7 @@ fill_default_options(Options * options)
 	/* options->hostname will be set in the main program if appropriate */
 	/* options->host_key_alias should not be set by default */
 	/* options->preferred_authentications will be set in ssh */
+	/* options->term will be set in ssh */
 }
 
 struct fwdarg {
@@ -2302,6 +2309,7 @@ dump_client_config(Options *o, const char *host)
 	/* String options */
 	dump_cfg_string(oBindAddress, o->bind_address);
 	dump_cfg_string(oCiphers, o->ciphers ? o->ciphers : KEX_CLIENT_ENCRYPT);
+	dump_cfg_string(oTerm, o->term);
 	dump_cfg_string(oControlPath, o->control_path);
 	dump_cfg_string(oHostKeyAlgorithms, o->hostkeyalgorithms ? o->hostkeyalgorithms : KEX_DEFAULT_PK_ALG);
 	dump_cfg_string(oHostKeyAlias, o->host_key_alias);
diff --git a/readconf.h b/readconf.h
index bb2d55283dd0..17e02f24ae4e 100644
--- a/readconf.h
+++ b/readconf.h
@@ -115,6 +115,8 @@ typedef struct {
 	int     num_send_env;
 	char   *send_env[MAX_SEND_ENV];
 
+	char   *term;
+
 	char	*control_path;
 	int	control_master;
 	int     control_persist; /* ControlPersist flag */
diff --git a/ssh.c b/ssh.c
index 59c1f931cb0a..db8bfd2d32eb 100644
--- a/ssh.c
+++ b/ssh.c
@@ -1117,6 +1117,9 @@ main(int ac, char **av)
 	if (options.user == NULL)
 		options.user = xstrdup(pw->pw_name);
 
+	if (option_clear_or_none(options.term))
+		options.term = getenv("TERM");
+
 	if (gethostname(thishost, sizeof(thishost)) == -1)
 		fatal("gethostname: %s", strerror(errno));
 	strlcpy(shorthost, thishost, sizeof(shorthost));
@@ -1638,7 +1641,7 @@ ssh_session(void)
 
 		/* Store TERM in the packet.  There is no limit on the
 		   length of the string. */
-		cp = getenv("TERM");
+		cp = options.term;
 		if (!cp)
 			cp = "";
 		packet_put_cstring(cp);
@@ -1804,7 +1807,7 @@ ssh_session2_setup(int id, int success, void *arg)
 	packet_set_interactive(interactive,
 	    options.ip_qos_interactive, options.ip_qos_bulk);
 
-	client_session2_setup(id, tty_flag, subsystem_flag, getenv("TERM"),
+	client_session2_setup(id, tty_flag, subsystem_flag, options.term,
 	    NULL, fileno(stdin), &command, environ);
 }
 
diff --git a/ssh_config.5 b/ssh_config.5
index 5b0975f87e2f..b0441f1c4dda 100644
--- a/ssh_config.5
+++ b/ssh_config.5
@@ -1521,6 +1521,16 @@ This is important in scripts, and many users want it too.
 .Pp
 To disable TCP keepalive messages, the value should be set to
 .Dq no .
+.It Cm Term
+Specifies the
+.Ev TERM
+environment variable which is sent to the server. This can be useful when the
+server does not have the proper terminfo installed. By default, or if set to
+.Dq none ,
+the server gets the
+.Ev TERM
+variable from the local
+.Xr environ 7 .
 .It Cm Tunnel
 Request
 .Xr tun 4
-- 
2.5.0


From djm at mindrot.org  Mon Aug 17 10:33:54 2015
From: djm at mindrot.org (Damien Miller)
Date: Mon, 17 Aug 2015 10:33:54 +1000 (AEST)
Subject: [PATCH] ssh-agent: Add support to load additional certificates
In-Reply-To: <1647204.J8msWKWJdq@storm>
References: <55B4F422.7030405@intra2net.com> <1647204.J8msWKWJdq@storm>
Message-ID: <alpine.BSO.2.20.1508171032590.32090@natsu.mindrot.org>

Hi,

This seems like a resonable idea.

Could you please attach this to a bug at https://bugzilla.mindrot.org/ ?
This will ensure it won't get lost. 

On Thu, 13 Aug 2015, Thomas Jarosch wrote:

> Hi,
> 
> On Sunday, 26. July 2015 16:52:18 you wrote:
> > Add support to load additional certificates
> > for already loaded private keys. Useful
> > if the private key is on a PKCS#11 hardware token.
> > 
> > The private keys inside ssh-agent are now using a refcount
> > to share the private parts between "Identities".
> > The reason for this change was that the PKCS#11 code
> > might have redirected ("wrap") the RSA functions to a hardware token.
> > We don't want to mess with those internals.
> > 
> > Tested with an OpenGPG card. Patch developed against 6.9p
> > and applies to original 6.9, too.
> > 
> > Please CC: comments.
> > 
> > Signed-off-by: Thomas Jarosch <thomas.jarosch at intra2net.com>
> 
> any comment on this?
> 
> Is the concept sound or did I take the wrong turn here?
> 
> If upstream considers this the way to go, I can try
> to split up the patch into smaller pieces like this:
> 
> - sshkey.c: Add "int sshkey_is_private(const struct sshkey *)" function
> - ssh-agent: Transition to private key refcounting
> - ssh-agent: Implement private key "shadowing"
> - ssh-add: Add support to add plain certificates
> 
> Thanks in advance,
> Thomas
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

From djm at mindrot.org  Mon Aug 17 10:36:25 2015
From: djm at mindrot.org (Damien Miller)
Date: Mon, 17 Aug 2015 10:36:25 +1000 (AEST)
Subject: [PATCH v2] Add a ssh_config Term option to override TERM
In-Reply-To: <c6330812bd30b6ca79ed0dd78c4b77ced166159b.1439608720.git.osandov@osandov.com>
References: <c6330812bd30b6ca79ed0dd78c4b77ced166159b.1439608720.git.osandov@osandov.com>
Message-ID: <alpine.BSO.2.20.1508171033570.32090@natsu.mindrot.org>

On Fri, 14 Aug 2015, Omar Sandoval wrote:

> This is useful when a server is missing the necessary terminfo and
> avoids having to manually set TERM before invoking ssh every time.

I don't think adding a special-case for TERM is worth it, but maybe
a more generic "SetEnv" that works in conjunction with SendEnv?

E.g.

Host foo
	SetEnv TERM xterm
	SetEnv LANG C

TERM would be sent implicitly as part of session setup, but the rest would
be equivalent to pre-loading the environment and doing SendEnv.

-d

From ricky at burg.in  Mon Aug 17 19:36:01 2015
From: ricky at burg.in (ricky at burg.in)
Date: Mon, 17 Aug 2015 09:36:01 +0000
Subject: Optional WHOIS netname on login banner
Message-ID: <4a68411924c1ece867d69b41ab603446@mail.burg.in>

I think this is probably my first post to this mailing list, so hello!

Occasionally I log in to my servers from IP addresses without reverse DNS configured, so sometimes I'll see an IP I don't recognise because I can't remember what I did the day before and get a bit spooked until I WHOIS the IP and find the netname reminds me I logged in from that IP.

I set out prepared to script it, but I understand that the reporting of failed/last logins is only really configurable at source, so instead of submitting a hilarious poorly coded patch from which I receive numerous critique and ridicule, I figured I'd just submit the idea/use-case and hope that at least one of you think it might be a nice idea. Even if I were to be able to submit openssh patches with code that is not awful, I think it sensible to check to see if you'd be prepared to accept such a patch in the first place anyway.

Regards,
Ricky Burgin

From lauri.vosandi at gmail.com  Tue Aug 18 04:23:13 2015
From: lauri.vosandi at gmail.com (=?UTF-8?q?Lauri=20V=C3=B5sandi?=)
Date: Mon, 17 Aug 2015 21:23:13 +0300
Subject: [PATCH] Expand tilde for UNIX domain socket forwards.
Message-ID: <1439835793-30017-1-git-send-email-lauri.vosandi@gmail.com>

---
 channels.c | 6 +++++-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/channels.c b/channels.c
index a84b487..396e192 100644
--- a/channels.c
+++ b/channels.c
@@ -3014,10 +3014,14 @@ channel_setup_fwd_listener_streamlocal(int type, struct Forward *fwd,
 
 	debug3("%s: type %d path %s", __func__, type, fwd->listen_path);
 
+	/* Expand home directory if necessary */
+	char *expanded_path = tilde_expand_filename(fwd->listen_path, getuid());
+
 	/* Start a Unix domain listener. */
 	omask = umask(fwd_opts->streamlocal_bind_mask);
-	sock = unix_listener(fwd->listen_path, SSH_LISTEN_BACKLOG,
+	sock = unix_listener(expanded_path, SSH_LISTEN_BACKLOG,
 	    fwd_opts->streamlocal_bind_unlink);
+	free(expanded_path);
 	umask(omask);
 	if (sock < 0)
 		return 0;
-- 
1.9.1


From Todd.Miller at courtesan.com  Tue Aug 18 05:14:20 2015
From: Todd.Miller at courtesan.com (Todd C. Miller)
Date: Mon, 17 Aug 2015 13:14:20 -0600
Subject: [PATCH] Expand tilde for UNIX domain socket forwards.
In-Reply-To: Your message of "Mon, 17 Aug 2015 21:23:13 +0300."
 <1439835793-30017-1-git-send-email-lauri.vosandi@gmail.com>
References: <1439835793-30017-1-git-send-email-lauri.vosandi@gmail.com>
Message-ID: <aea6cdc0dcfc203b@courtesan.com>

I like the idea but tilde_expand_filename() calls fatal() if it
cannot resolve ~foo.  This is not terrible when using -L and -R on
the normal command line but it seems pretty harsh to exit when -L
or -R are used via the ~C escape or the streamlocal-forward at openssh.com
request.
Message-Id: <aea6cdc1d1b42d07 at courtesan.com>

Perhaps we just need a non-fatal version of tilde_expand_filename().
Message-Id: <aea6cdc2c787751c at courtesan.com>

 - todd

From djm at mindrot.org  Tue Aug 18 09:41:47 2015
From: djm at mindrot.org (Damien Miller)
Date: Tue, 18 Aug 2015 09:41:47 +1000 (AEST)
Subject: [PATCH] Expand tilde for UNIX domain socket forwards.
In-Reply-To: <aea6cdc0dcfc203b@courtesan.com>
References: <1439835793-30017-1-git-send-email-lauri.vosandi@gmail.com>
 <aea6cdc0dcfc203b@courtesan.com>
Message-ID: <alpine.BSO.2.20.1508180940470.32090@natsu.mindrot.org>

On Mon, 17 Aug 2015, Todd C. Miller wrote:

> I like the idea but tilde_expand_filename() calls fatal() if it
> cannot resolve ~foo.  This is not terrible when using -L and -R on
> the normal command line but it seems pretty harsh to exit when -L
> or -R are used via the ~C escape or the streamlocal-forward at openssh.com
> request.
> Message-Id: <aea6cdc1d1b42d07 at courtesan.com>
> 
> Perhaps we just need a non-fatal version of tilde_expand_filename().

Yeah, we should refactor it into a version that returns a ssherr.h code
and (perhaps) leave the existing tilde_expand_filename() as a wrapper.

-d

From ethan.rahn at gmail.com  Tue Aug 18 09:58:10 2015
From: ethan.rahn at gmail.com (Ethan Rahn)
Date: Mon, 17 Aug 2015 16:58:10 -0700
Subject: Fix for CVE-2015-5600 can erroneously prevent logging in sometimes
Message-ID: <CAEW9rAisTOfrWK7scqOwzYOMVR+kzcmP=SUy3Hb9QfX+CdGc8w@mail.gmail.com>

Hello,

When testing a fix for CVE-2015-5600 based on the Ubuntu patch in
openssh-5.9 (
https://launchpadlibrarian.net/214490716/openssh_1%3A5.9p1-5ubuntu1.4_1%3A5.9p1-5ubuntu1.6.diff.gz
), I noticed that there was an issue with getting permission denied when
trying to log in lots of times with what should be valid credentials.

The symptom was when logging in with the command and sshd_config below I
would get permission denied sometimes and permission granted other times.
Upon investigating the reason for permission being denied was sshd
erroneously thinking "pam" had already been used as a login method on the
first attempt to use it. This appeared to be related to the kbdinit_alloc
function in auth2_chall.c not initializing devices_done. Once I made the
following patch the issue went away:

@@ -130,6 +131,7 @@ kbdint_alloc(const char *devs)
        kbdintctxt->ctxt = NULL;
        kbdintctxt->device = NULL;
        kbdintctxt->nreq = 0;
+       kbdintctxt->devices_done = 0;

        return kbdintctxt;
 }

Since openssh uses xmalloc ( i.e. malloc or die ) to initialize data
structures, it seems that the issue is the struct not getting zero'ed out
at the start. I haven't taken the time to verify this in openssh-6.9 /
openssh-7.0, but it seems like since xmalloc / malloc is still in use that
it should still fail in the same manner.

These are the ssh command sshd_config that were in use when the issue was
happening. I'm not sure if something about them makes the issue more likely
to happen:
===
ssh command:
ssh -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o
ConnectTimeout=120 -o ServerAliveInterval=15 -m hmac-md5 -c aes256-ctr -e
\~ -oKexAlgorithms=diffie-hellman-group-exchange-sha1 <username>@<host>


sshd_config:
Protocol 2
Port 22
SyslogFacility AUTHPRIV
PasswordAuthentication no
ChallengeResponseAuthentication yes
UsePAM yes
MaxStartups 10:30:100
Subsystem sftp /usr/libexec/openssh/sftp-server
PermitEmptyPasswords yes
AllowTcpForwarding no
Banner /etc/issue
StrictModes yes
UsePrivilegeSeparation yes
Compression delayed
GatewayPorts no
GSSAPIAuthentication no
KerberosAuthentication no
LoginGraceTime 120
LogLevel DEBUG2
Ciphers
3des-cbc,aes128-cbc,aes128-ctr,aes192-cbc,aes192-ctr,aes256-cbc,aes256-ctr,arcfour,arcfour128,arcfour256,blowfish-cbc,cast128-cbc
KexAlgorithms
diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
MACs hmac-md5,hmac-sha1,hmac-ripemd160,hmac-sha1-96,hmac-md5-96
HostKey <removed rsa keypath>
HostKey <removed dsa keypath>

===

Is anyone else able to see this issue and verify that my fix is correct?
I've also filed this under Ubuntu as BUG#1485807

Thanks,

Ethan

From djm at mindrot.org  Tue Aug 18 10:48:36 2015
From: djm at mindrot.org (Damien Miller)
Date: Tue, 18 Aug 2015 10:48:36 +1000 (AEST)
Subject: Fix for CVE-2015-5600 can erroneously prevent logging in sometimes
In-Reply-To: <CAEW9rAisTOfrWK7scqOwzYOMVR+kzcmP=SUy3Hb9QfX+CdGc8w@mail.gmail.com>
References: <CAEW9rAisTOfrWK7scqOwzYOMVR+kzcmP=SUy3Hb9QfX+CdGc8w@mail.gmail.com>
Message-ID: <alpine.BSO.2.20.1508181046430.32090@natsu.mindrot.org>

On Mon, 17 Aug 2015, Ethan Rahn wrote:

> Hello,
> 
> When testing a fix for CVE-2015-5600 based on the Ubuntu patch in
> openssh-5.9 (
> https://launchpadlibrarian.net/214490716/openssh_1%3A5.9p1-5ubuntu1.4_1%3A5.9p1-5ubuntu1.6.diff.gz
> ), I noticed that there was an issue with getting permission denied when
> trying to log in lots of times with what should be valid credentials.
> 
> The symptom was when logging in with the command and sshd_config below I
> would get permission denied sometimes and permission granted other times.
> Upon investigating the reason for permission being denied was sshd
> erroneously thinking "pam" had already been used as a login method on the
> first attempt to use it. This appeared to be related to the kbdinit_alloc
> function in auth2_chall.c not initializing devices_done. Once I made the
> following patch the issue went away:
> 
> @@ -130,6 +131,7 @@ kbdint_alloc(const char *devs)
>         kbdintctxt->ctxt = NULL;
>         kbdintctxt->device = NULL;
>         kbdintctxt->nreq = 0;
> +       kbdintctxt->devices_done = 0;
> 
>         return kbdintctxt;
>  }

Your patch is needed for openssh <= 6.3. Newer versions have used calloc
to allocate kbdintctxt. Whoever backported the patch for 7.0 should have
checked to begin with.

-d


From aixtools at gmail.com  Tue Aug 18 18:37:48 2015
From: aixtools at gmail.com (aixtools)
Date: Tue, 18 Aug 2015 10:37:48 +0200
Subject: no config.sub after 'make distclean' - FYI
Message-ID: <55D2EEDC.60701@gmail.com>

FYI: About to leave on vacation, so no time to go deep. so sorry.

Downloaded openssh-7.0p1 and build using --without-openssl

First issue was:
  make install DESTDIR=/var/aixtools/openbsd/openssh/7.0.0.1601 > 
.buildaix/install.out
Could not load host key: /var/openssh/etc/ssh_host_rsa_key
Could not load host key: /var/openssh/etc/ssh_host_dsa_key
Could not load host key: /var/openssh/etc/ssh_host_ed25519_key
Disabling protocol version 2. Could not load host key
sshd: no hostkeys available -- exiting.
make: 1254-004 The error code from the last command is 1.
make: 1254-005 Ignored error code 1 from last command.

I did not run make check; neither am I sure if this is a new "make 
install" issue.
However, I recall "make check" would fail when these keys did not pre-exist.

Next:
after "make distclean" I get

root at x064:[/data/prj/openbsd/openssh/openssh-7.0p1]./configure
checking for gcc... no
checking for cc... cc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... no
checking whether cc accepts -g... yes
checking for cc option to accept ISO C89... -qlanglvl=extc89
configure: error: cannot run /bin/sh ./config.sub

Again, all FYI. When I am back in September I will look more closely, if 
still needed.


From m.stolarek at icm.edu.pl  Tue Aug 18 18:42:30 2015
From: m.stolarek at icm.edu.pl (Marcin Stolarek)
Date: Tue, 18 Aug 2015 10:42:30 +0200 (CEST)
Subject: sftp and ControlPath
In-Reply-To: <alpine.BSO.2.20.1508112336210.32090@natsu.mindrot.org>
References: <alpine.DEB.2.10.1508101032490.23898@cinek-ws>
 <alpine.BSO.2.20.1508112336210.32090@natsu.mindrot.org>
Message-ID: <alpine.DEB.2.10.1508181041390.27379@cinek-ws>



On Tue, 11 Aug 2015, Damien Miller wrote:

> On Mon, 10 Aug 2015, Marcin Stolarek wrote:
>
>> Hi guys,
>>
>> I've check that when using sftp with -o ControlPath=... the first attempt just
>> hangs. Can someone point me to appropriate lines in code where can I check
>> whats going on?
>
> Please post a debug log "sftp -vvv ..." - it's essential to figure out
> what is going wrong.
I've pasted the output to gist:
https://gist.github.com/anonymous/0eefbd24ca96b23128ef

marcin

From aixtools at gmail.com  Tue Aug 18 19:07:02 2015
From: aixtools at gmail.com (aixtools)
Date: Tue, 18 Aug 2015 11:07:02 +0200
Subject: no config.sub after 'make distclean' - FYI
In-Reply-To: <55D2EEDC.60701@gmail.com>
References: <55D2EEDC.60701@gmail.com>
Message-ID: <55D2F5B6.1040302@gmail.com>

On 2015-08-18 10:37 AM, aixtools wrote:
> FYI: About to leave on vacation, so no time to go deep. so sorry.
>
> Downloaded openssh-7.0p1 and build using --without-openssl
>
> First issue was:
>  make install DESTDIR=/var/aixtools/openbsd/openssh/7.0.0.1601 > 
> .buildaix/install.out
> Could not load host key: /var/openssh/etc/ssh_host_rsa_key
> Could not load host key: /var/openssh/etc/ssh_host_dsa_key
> Could not load host key: /var/openssh/etc/ssh_host_ed25519_key
> Disabling protocol version 2. Could not load host key
> sshd: no hostkeys available -- exiting.
> make: 1254-004 The error code from the last command is 1.
> make: 1254-005 Ignored error code 1 from last command.
>
> I did not run make check; neither am I sure if this is a new "make 
> install" issue.
> However, I recall "make check" would fail when these keys did not 
> pre-exist.
>
> Next:
> after "make distclean" I get
>
> root at x064:[/data/prj/openbsd/openssh/openssh-7.0p1]./configure
> checking for gcc... no
> checking for cc... cc
> checking for C compiler default output file name... a.out
> checking whether the C compiler works... yes
> checking whether we are cross compiling... no
> checking for suffix of executables...
> checking for suffix of object files... o
> checking whether we are using the GNU C compiler... no
> checking whether cc accepts -g... yes
> checking for cc option to accept ISO C89... -qlanglvl=extc89
> configure: error: cannot run /bin/sh ./config.sub
>
> Again, all FYI. When I am back in September I will look more closely, 
> if still needed.
>
Additional FYI.

I probably need to read the Change Notes - so probably it is not a 
surprise that Putty 0.64 is not (always) working.

I thought I only had one "old cbc" cipher active to support an old SSH 
client.

The surprising part is when sshd_config has this added:
ciphers 
aes128-ctr,aes192-ctr,aes256-ctr,chacha20-poly1305 at openssh.com,aes256-cbc
KexAlgorithms  
curve25519-sha256 at libssh.org,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
macs hmac-sha2-256,hmac-sha2-512,hmac-sha1-96,hmac-sha1

openssh-7.0p1 sshd does actually ask for the password, rather than fail 
outright with protocol mismatch
(which is what it does without the "backwards-compatible" ciphers, et 
al, above., i.e., never gets to asking for password).

From djm at mindrot.org  Wed Aug 19 10:20:42 2015
From: djm at mindrot.org (Damien Miller)
Date: Wed, 19 Aug 2015 10:20:42 +1000 (AEST)
Subject: sftp and ControlPath
In-Reply-To: <alpine.DEB.2.10.1508181041390.27379@cinek-ws>
References: <alpine.DEB.2.10.1508101032490.23898@cinek-ws>
 <alpine.BSO.2.20.1508112336210.32090@natsu.mindrot.org>
 <alpine.DEB.2.10.1508181041390.27379@cinek-ws>
Message-ID: <alpine.BSO.2.20.1508191018280.32090@natsu.mindrot.org>

On Tue, 18 Aug 2015, Marcin Stolarek wrote:

> 
> 
> On Tue, 11 Aug 2015, Damien Miller wrote:
> 
> > On Mon, 10 Aug 2015, Marcin Stolarek wrote:
> > 
> > > Hi guys,
> > > 
> > > I've check that when using sftp with -o ControlPath=... the first attempt
> > > just
> > > hangs. Can someone point me to appropriate lines in code where can I check
> > > whats going on?
> > 
> > Please post a debug log "sftp -vvv ..." - it's essential to figure out
> > what is going wrong.
> I've pasted the output to gist:
> https://gist.github.com/anonymous/0eefbd24ca96b23128ef

debug1: Local version string SSH-2.0-OpenSSH_5.3

This is pretty old - we've fixed a lot of bugs in the last six years
and I can't replicate your hang with OpenSSH 7.0.

If you can't install a recent version and your operating system vendor
doesn't offer one then you'll have to ask for support from your vendor.

-d

From Todd.Miller at courtesan.com  Wed Aug 19 12:31:04 2015
From: Todd.Miller at courtesan.com (Todd C. Miller)
Date: Tue, 18 Aug 2015 20:31:04 -0600
Subject: [PATCH] Expand tilde for UNIX domain socket forwards.
In-Reply-To: Your message of "Tue, 18 Aug 2015 09:41:47 +1000."
 <alpine.BSO.2.20.1508180940470.32090@natsu.mindrot.org>
References: <1439835793-30017-1-git-send-email-lauri.vosandi@gmail.com>
 <aea6cdc0dcfc203b@courtesan.com>
 <alpine.BSO.2.20.1508180940470.32090@natsu.mindrot.org>
Message-ID: <c731f24f22be3085@courtesan.com>

On Tue, 18 Aug 2015 09:41:47 +1000, Damien Miller wrote:

> Yeah, we should refactor it into a version that returns a ssherr.h code
> and (perhaps) leave the existing tilde_expand_filename() as a wrapper.

We could do something like this.  The name stinks but...

 - todd

Index: misc.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/misc.c,v
retrieving revision 1.97
diff -u -p -u -r1.97 misc.c
--- misc.c	24 Apr 2015 01:36:00 -0000	1.97
+++ misc.c	19 Aug 2015 02:28:18 -0000
@@ -50,6 +50,7 @@
 #include "xmalloc.h"
 #include "misc.h"
 #include "log.h"
+#include "ssherr.h"
 #include "ssh.h"
 
 /* remove newline at end of string */
@@ -499,29 +500,31 @@ freeargs(arglist *args)
  * Expands tildes in the file name.  Returns data allocated by xmalloc.
  * Warning: this calls getpw*.
  */
-char *
-tilde_expand_filename(const char *filename, uid_t uid)
+int
+tilde_expand_filename2(const char *filename, char **expanded, uid_t uid)
 {
 	const char *path, *sep;
 	char user[128], *ret;
 	struct passwd *pw;
-	u_int len, slash;
+	size_t len, slash;
 
-	if (*filename != '~')
-		return (xstrdup(filename));
+	if (*filename != '~') {
+		*expanded = xstrdup(filename);
+		return SSH_ERR_SUCCESS;
+	}
 	filename++;
 
 	path = strchr(filename, '/');
 	if (path != NULL && path > filename) {		/* ~user/path */
 		slash = path - filename;
 		if (slash > sizeof(user) - 1)
-			fatal("tilde_expand_filename: ~username too long");
+			return SSH_ERR_PATH_TOO_LONG;
 		memcpy(user, filename, slash);
 		user[slash] = '\0';
 		if ((pw = getpwnam(user)) == NULL)
-			fatal("tilde_expand_filename: No such user %s", user);
+			return SSH_ERR_UNKNOWN_USER;
 	} else if ((pw = getpwuid(uid)) == NULL)	/* ~/path */
-		fatal("tilde_expand_filename: No such uid %ld", (long)uid);
+		return SSH_ERR_UNKNOWN_USER;
 
 	/* Make sure directory has a trailing '/' */
 	len = strlen(pw->pw_dir);
@@ -534,10 +537,29 @@ tilde_expand_filename(const char *filena
 	if (path != NULL)
 		filename = path + 1;
 
-	if (xasprintf(&ret, "%s%s%s", pw->pw_dir, sep, filename) >= PATH_MAX)
-		fatal("tilde_expand_filename: Path too long");
+	if (xasprintf(ret, "%s%s%s", pw->pw_dir, sep, filename) >= PATH_MAX) {
+		free(ret);
+		return SSH_ERR_PATH_TOO_LONG;
+	}
+
+	*expanded = ret;
+	return SSH_ERR_SUCCESS;
+}
+
+/*
+ * Expands tildes in the file name.  Returns data allocated by xmalloc.
+ * Warning: this calls getpw*.
+ */
+char *
+tilde_expand_filename(const char *filename, uid_t uid)
+{
+	char *ret;
+	int rc;
 
-	return (ret);
+	rc = tilde_expand_filename2(filename, &ret, uid);
+	if (rc != SSH_ERR_SUCCESS)
+		fatal("%s: %s", __func__, ssh_err(rc));
+	return ret;
 }
 
 /*
Index: misc.h
===================================================================
RCS file: /cvs/src/usr.bin/ssh/misc.h,v
retrieving revision 1.54
diff -u -p -u -r1.54 misc.h
--- misc.h	15 Jul 2014 15:54:14 -0000	1.54
+++ misc.h	19 Aug 2015 02:27:37 -0000
@@ -49,6 +49,7 @@ char	*cleanhostname(char *);
 char	*colon(char *);
 long	 convtime(const char *);
 char	*tilde_expand_filename(const char *, uid_t);
+int	 tilde_expand_filename2(const char *, char **, uid_t);
 char	*percent_expand(const char *, ...) __attribute__((__sentinel__));
 char	*tohex(const void *, size_t);
 void	 sanitise_stdfd(void);
Index: ssherr.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/ssherr.c,v
retrieving revision 1.4
diff -u -p -u -r1.4 ssherr.c
--- ssherr.c	16 Feb 2015 22:13:32 -0000	1.4
+++ ssherr.c	19 Aug 2015 02:19:05 -0000
@@ -135,6 +135,10 @@ ssh_err(int n)
 		return "Connection corrupted";
 	case SSH_ERR_PROTOCOL_ERROR:
 		return "Protocol error";
+	case SSH_ERR_UNKNOWN_USER:
+		return "Unknown user";
+	case SSH_ERR_PATH_TOO_LONG:
+		return "Path too long";
 	default:
 		return "unknown error";
 	}
Index: ssherr.h
===================================================================
RCS file: /cvs/src/usr.bin/ssh/ssherr.h,v
retrieving revision 1.3
diff -u -p -u -r1.3 ssherr.h
--- ssherr.h	30 Jan 2015 01:13:33 -0000	1.3
+++ ssherr.h	19 Aug 2015 02:18:29 -0000
@@ -77,6 +77,8 @@
 #define SSH_ERR_CONN_TIMEOUT			-53
 #define SSH_ERR_CONN_CORRUPT			-54
 #define SSH_ERR_PROTOCOL_ERROR			-55
+#define SSH_ERR_UNKNOWN_USER			-56
+#define SSH_ERR_PATH_TOO_LONG			-57
 
 /* Translate a numeric error code to a human-readable error string */
 const char *ssh_err(int n);

From saku at ytti.fi  Wed Aug 19 15:44:47 2015
From: saku at ytti.fi (Saku Ytti)
Date: Wed, 19 Aug 2015 08:44:47 +0300
Subject: Bootstrapping SSH security
Message-ID: <CAAeewD_UkYFeUzKuSUxE8iER7i7az83EEv7JsycXK5qNnMLWrg@mail.gmail.com>

Hey,

What is the canonical way that SSH security should be bootsrapped. How
are users expected to know if fingerprint is correct or not?
To me canonical way seems that it's not done, at all, only very very
few use communicate the fingerprints somehow.

Are there reasons why we couldn't out-of-the-package trust on SSHFP
when found with validating DNSSEC?
Those few how have higher security requirements could manually turn it
off. I feel it would be net-gain on security, but I may have missed
some important arguments.

Thanks,
-- 
  ++ytti

From pch-openssh at u-1.phicoh.com  Thu Aug 20 19:07:32 2015
From: pch-openssh at u-1.phicoh.com (Philip Homburg)
Date: Thu, 20 Aug 2015 11:07:32 +0200
Subject: Bootstrapping SSH security 
In-Reply-To: Your message of "Wed, 19 Aug 2015 08:44:47 +0300 ."
 <CAAeewD_UkYFeUzKuSUxE8iER7i7az83EEv7JsycXK5qNnMLWrg@mail.gmail.com> 
Message-ID: <m1ZSLot-0000FDC@stereo.hq.phicoh.net>

In your letter dated Wed, 19 Aug 2015 08:44:47 +0300 you wrote:
>Are there reasons why we couldn't out-of-the-package trust on SSHFP
>when found with validating DNSSEC?

There is currently some support for SSHFP in openssh, but it doesn't really
work.

I created a patch to fix the issue and put a fork up on github:
https://github.com/phicoh/openssh-getdns/tree/getdns

Note that you have to enable this in configure with '--with-getdns' and
use -o 'VerifyHostKeyDNS yes' to enable the feature at runtime.



From antoine.durand at bodet-software.com  Fri Aug 21 01:45:04 2015
From: antoine.durand at bodet-software.com (Durand Antoine)
Date: Thu, 20 Aug 2015 15:45:04 +0000
Subject: OpenSSH Cross-Compilation for android
Message-ID: <006b447d8329493e81854a116209a24f@CORMMAIL20.TREM.BOD>


Hello,
I'm trying to cross-compile OpenSSH for an Android Plateform (Armv7) using the Android-NDK. To do this, I followed instructions based on this post : Cross Compile OpenSSH for ARM<http://stackoverflow.com/questions/11841919/cross-compile-openssh-for-arm>.
I replace the "arm-linux-gnueabi-gcc" by the android equivalent : "arm-linux-androideabi-gcc". I managed to compile zlib and openssl, but when it comes to openssh, things become more complicated ...
Here is what I've done :
export HOST=arm-linux-androideabi
./configure --host=$HOST --target=$HOST --prefix=$HOME/OpenSSH/opensshArm
After that I had the following output :
configure: error: *** OpenSSL headers missing - please install first or check config.log ***
So I modified my ./configure by this one :
./configure --host=$HOST --target=$HOST --prefix=$HOME/OpenSSH/opensshArm --with-ssl-dir=$HOME/OpenSSH/out/usr
Where $HOME/out/ is the output directory used to compile zlib and openssl.
Here is where I'm stuck : I launch the "make" and here is thi output :
make[1]: Entering directory `/home/test/OpenSSH/openssh-6.4p1/openbsd-compat'
arm-linux-androideabi-gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -Wno-pointer-sign -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -fno-builtin-memset  -I. -I.. -I. -I./.. -I/home/test/OpenSSH/out/usr/include  -DHAVE_CONFIG_H -c bsd-arc4random.c
In file included from /home/test/OpenSSH/out/usr/include/openssl/crypto.h:120,
                 from /home/test/OpenSSH/out/usr/include/openssl/bn.h:133,
                 from ../buffer.h:49,
                 from ../entropy.h:30,
                 from ../includes.h:177,
                 from bsd-arc4random.c:17:
/home/test/toolchain/bin/../sysroot/usr/include/stdlib.h:168: error: expected identifier or '(' before numeric constant
make[1]: *** [bsd-arc4random.o] Error 1
make[1]: Leaving directory `/home/test/OpenSSH/openssh-6.4p1/openbsd-compat'
make: *** [openbsd-compat/libopenbsd-compat.a] Error 2
Any helps ?



Antoine Durand
Embedded System Engineer
Bodet Software



Ce message et toutes les pieces jointes (ci-apres le "message") sont etablis a l'intention exclusive de ses destinataires.
Si vous recevez ce message par erreur, merci de le detruire et d'en avertir immediatement l'expediteur par e-mail.
Toute utilisation de ce message non conforme a sa destination, toute diffusion ou toute publication, totale ou partielle, est interdite, sauf autorisation expresse. Les communications sur Internet n'etant pas securisees, l'expediteur informe qu'il ne peut accepter aucune responsabilite quant au contenu de ce message.
This mail message and attachments (the "message") are solely intended for the addresses. It is confidential in nature.
If you receive this message in error, please delete it and immediately notify the sender by e-mail.
Any use other than its intended purpose, dissemination or disclosure, either whole or partial, is prohibited except if formal approval is granted. As communication on the Internet is not secure, the sender does not accept responsibility for the content of this message.

From djm at cvs.openbsd.org  Fri Aug 21 16:11:02 2015
From: djm at cvs.openbsd.org (Damien Miller)
Date: Fri, 21 Aug 2015 00:11:02 -0600 (MDT)
Subject: Announce: OpenSSH 7.1 released
Message-ID: <8775156675321531465.enqueue@cvs.openbsd.org>

OpenSSH 7.1 has just been released. It will be available from the
mirrors listed at http://www.openssh.com/ shortly.

OpenSSH is a 100% complete SSH protocol 2.0 implementation and
includes sftp client and server support. OpenSSH also includes
transitional support for the legacy SSH 1.3 and 1.5 protocols
that may be enabled at compile-time.

Once again, we would like to thank the OpenSSH community for their
continued support of the project, especially those who contributed
code or patches, reported bugs, tested snapshots or donated to the
project. More information on donations may be found at:
http://www.openssh.com/donations.html

Future deprecation notice
=========================

We plan on retiring more legacy cryptography in the next release
including:

 * Refusing all RSA keys smaller than 1024 bits (the current minimum
   is 768 bits)

 * Several ciphers will be disabled by default: blowfish-cbc,
   cast128-cbc, all arcfour variants and the rijndael-cbc aliases
   for AES.

 * MD5-based HMAC algorithms will be disabled by default.

This list reflects our current intentions, but please check the final
release notes for OpenSSH 7.1 when it is released.

Changes since OpenSSH 7.0
=========================

This is a bugfix release.

Security
--------

 * sshd(8): OpenSSH 7.0 contained a logic error in PermitRootLogin=
   prohibit-password/without-password that could, depending on
   compile-time configuration, permit password authentication to
   root while preventing other forms of authentication. This problem
   was reported by Mantas Mikulenas.

Bugfixes
--------

 * ssh(1), sshd(8): add compatability workarounds for FuTTY

 * ssh(1), sshd(8): refine compatability workarounds for WinSCP

 * Fix a number of memory faults (double-free, free of uninitialised
   memory, etc) in ssh(1) and ssh-keygen(1). Reported by Mateusz
   Kocielski.

Checksums:
==========

 - SHA1 (openssh-7.1.tar.gz) = 06c1db39f33831fe004726e013b2cf84f1889042
 - SHA256 (openssh-7.1.tar.gz) = H7U1se9EoBmhkKi2i7lqpMX9QHdDTsgpu7kd5VZUGSY=

 - SHA1 (openssh-7.1p1.tar.gz) = ed22af19f962262c493fcc6ed8c8826b2761d9b6
 - SHA256 (openssh-7.1p1.tar.gz) = /AptLR0GPVxm3/2VJJPQzaJWytIE9oHeD4TvhbKthCg=

Please note that the SHA256 signatures are base64 encoded and not
hexadecimal (which is the default for most checksum tools). The PGP
key used to sign the releases is available as RELEASE_KEY.asc from
the mirror sites.

Reporting Bugs:
===============

- Please read http://www.openssh.com/report.html
  Security bugs should be reported directly to openssh at openssh.com

OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt,
Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and
Ben Lindstrom.


From list at eworm.de  Fri Aug 21 19:12:47 2015
From: list at eworm.de (Christian Hesse)
Date: Fri, 21 Aug 2015 11:12:47 +0200
Subject: [PATCH 1/1] update error messages about moduli and primes files
In-Reply-To: <1435739405-12226-1-git-send-email-list@eworm.de>
References: <1435739405-12226-1-git-send-email-list@eworm.de>
Message-ID: <20150821111247.1e66b965@leda.localdomain>

Christian Hesse <list at eworm.de> on Wed, 2015/07/01 10:30:
> From: Christian Hesse <mail at eworm.de>
> 
> Both files can be used, so mention both in error messages.
> 
> Signed-off-by: Christian Hesse <mail at eworm.de>

I have sent some patches here. Will anybody care? Or is there any better
place to put them?
-- 
main(a){char*c=/*    Schoene Gruesse                         */"B?IJj;MEH"
"CX:;",b;for(a/*    Chris           get my mail address:    */=0;b=c[a++];)
putchar(b-1/(/*               gcc -o sig sig.c && ./sig    */b/42*2-3)*42);}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150821/85dedbc2/attachment.bin>

From djm at mindrot.org  Fri Aug 21 20:00:46 2015
From: djm at mindrot.org (Damien Miller)
Date: Fri, 21 Aug 2015 20:00:46 +1000 (AEST)
Subject: [PATCH 1/1] update error messages about moduli and primes
 files
In-Reply-To: <20150821111247.1e66b965@leda.localdomain>
References: <1435739405-12226-1-git-send-email-list@eworm.de>
 <20150821111247.1e66b965@leda.localdomain>
Message-ID: <alpine.BSO.2.20.1508212000170.32090@natsu.mindrot.org>

On Fri, 21 Aug 2015, Christian Hesse wrote:

> Christian Hesse <list at eworm.de> on Wed, 2015/07/01 10:30:
> > From: Christian Hesse <mail at eworm.de>
> > 
> > Both files can be used, so mention both in error messages.
> > 
> > Signed-off-by: Christian Hesse <mail at eworm.de>
> 
> I have sent some patches here. Will anybody care? Or is there any better
> place to put them?

Yes, https://bugzilla.mindrot.org/ is the best place to put patches
to ensure they don't get lost.

-d

From maniac.nl at gmail.com  Fri Aug 21 21:04:20 2015
From: maniac.nl at gmail.com (Mark Janssen)
Date: Fri, 21 Aug 2015 13:04:20 +0200
Subject: Announce: OpenSSH 7.1 released
In-Reply-To: <8775156675321531465.enqueue@cvs.openbsd.org>
References: <8775156675321531465.enqueue@cvs.openbsd.org>
Message-ID: <CAKs9mshstWpAniuXnWEVt80Q_huUY7K_cCK8abXJW5srm=S34g@mail.gmail.com>

I'm assuming the "deprecation notice" section should refer to 7.2 now, and
not 7.1 ?

Mark

On Fri, Aug 21, 2015 at 8:11 AM, Damien Miller <djm at cvs.openbsd.org> wrote:

> OpenSSH 7.1 has just been released. It will be available from the
> mirrors listed at http://www.openssh.com/ shortly.
>
> OpenSSH is a 100% complete SSH protocol 2.0 implementation and
> includes sftp client and server support. OpenSSH also includes
> transitional support for the legacy SSH 1.3 and 1.5 protocols
> that may be enabled at compile-time.
>
> Once again, we would like to thank the OpenSSH community for their
> continued support of the project, especially those who contributed
> code or patches, reported bugs, tested snapshots or donated to the
> project. More information on donations may be found at:
> http://www.openssh.com/donations.html
>
> Future deprecation notice
> =========================
>
> We plan on retiring more legacy cryptography in the next release
> including:
>
>  * Refusing all RSA keys smaller than 1024 bits (the current minimum
>    is 768 bits)
>
>  * Several ciphers will be disabled by default: blowfish-cbc,
>    cast128-cbc, all arcfour variants and the rijndael-cbc aliases
>    for AES.
>
>  * MD5-based HMAC algorithms will be disabled by default.
>
> This list reflects our current intentions, but please check the final
> release notes for OpenSSH 7.1 when it is released.
>
> Changes since OpenSSH 7.0
> =========================
>
> This is a bugfix release.
>
> Security
> --------
>
>  * sshd(8): OpenSSH 7.0 contained a logic error in PermitRootLogin=
>    prohibit-password/without-password that could, depending on
>    compile-time configuration, permit password authentication to
>    root while preventing other forms of authentication. This problem
>    was reported by Mantas Mikulenas.
>
> Bugfixes
> --------
>
>  * ssh(1), sshd(8): add compatability workarounds for FuTTY
>
>  * ssh(1), sshd(8): refine compatability workarounds for WinSCP
>
>  * Fix a number of memory faults (double-free, free of uninitialised
>    memory, etc) in ssh(1) and ssh-keygen(1). Reported by Mateusz
>    Kocielski.
>
> Checksums:
> ==========
>
>  - SHA1 (openssh-7.1.tar.gz) = 06c1db39f33831fe004726e013b2cf84f1889042
>  - SHA256 (openssh-7.1.tar.gz) =
> H7U1se9EoBmhkKi2i7lqpMX9QHdDTsgpu7kd5VZUGSY=
>
>  - SHA1 (openssh-7.1p1.tar.gz) = ed22af19f962262c493fcc6ed8c8826b2761d9b6
>  - SHA256 (openssh-7.1p1.tar.gz) =
> /AptLR0GPVxm3/2VJJPQzaJWytIE9oHeD4TvhbKthCg=
>
> Please note that the SHA256 signatures are base64 encoded and not
> hexadecimal (which is the default for most checksum tools). The PGP
> key used to sign the releases is available as RELEASE_KEY.asc from
> the mirror sites.
>
> Reporting Bugs:
> ===============
>
> - Please read http://www.openssh.com/report.html
>   Security bugs should be reported directly to openssh at openssh.com
>
> OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt,
> Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and
> Ben Lindstrom.
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>



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

From mfriedl at gmail.com  Fri Aug 21 21:43:09 2015
From: mfriedl at gmail.com (Markus Friedl)
Date: Fri, 21 Aug 2015 13:43:09 +0200
Subject: Announce: OpenSSH 7.1 released
In-Reply-To: <CAKs9mshstWpAniuXnWEVt80Q_huUY7K_cCK8abXJW5srm=S34g@mail.gmail.com>
References: <8775156675321531465.enqueue@cvs.openbsd.org>
 <CAKs9mshstWpAniuXnWEVt80Q_huUY7K_cCK8abXJW5srm=S34g@mail.gmail.com>
Message-ID: <6D113D37-7C3A-435E-89F1-897F195BE9FB@gmail.com>

It refers to the future.  



> Am 21.08.2015 um 13:04 schrieb Mark Janssen <maniac.nl at gmail.com>:
> 
> I'm assuming the "deprecation notice" section should refer to 7.2 now, and
> not 7.1 ?
> 
> Mark
> 
>> On Fri, Aug 21, 2015 at 8:11 AM, Damien Miller <djm at cvs.openbsd.org> wrote:
>> 
>> OpenSSH 7.1 has just been released. It will be available from the
>> mirrors listed at http://www.openssh.com/ shortly.
>> 
>> OpenSSH is a 100% complete SSH protocol 2.0 implementation and
>> includes sftp client and server support. OpenSSH also includes
>> transitional support for the legacy SSH 1.3 and 1.5 protocols
>> that may be enabled at compile-time.
>> 
>> Once again, we would like to thank the OpenSSH community for their
>> continued support of the project, especially those who contributed
>> code or patches, reported bugs, tested snapshots or donated to the
>> project. More information on donations may be found at:
>> http://www.openssh.com/donations.html
>> 
>> Future deprecation notice
>> =========================
>> 
>> We plan on retiring more legacy cryptography in the next release
>> including:
>> 
>> * Refusing all RSA keys smaller than 1024 bits (the current minimum
>>   is 768 bits)
>> 
>> * Several ciphers will be disabled by default: blowfish-cbc,
>>   cast128-cbc, all arcfour variants and the rijndael-cbc aliases
>>   for AES.
>> 
>> * MD5-based HMAC algorithms will be disabled by default.
>> 
>> This list reflects our current intentions, but please check the final
>> release notes for OpenSSH 7.1 when it is released.
>> 
>> Changes since OpenSSH 7.0
>> =========================
>> 
>> This is a bugfix release.
>> 
>> Security
>> --------
>> 
>> * sshd(8): OpenSSH 7.0 contained a logic error in PermitRootLogin=
>>   prohibit-password/without-password that could, depending on
>>   compile-time configuration, permit password authentication to
>>   root while preventing other forms of authentication. This problem
>>   was reported by Mantas Mikulenas.
>> 
>> Bugfixes
>> --------
>> 
>> * ssh(1), sshd(8): add compatability workarounds for FuTTY
>> 
>> * ssh(1), sshd(8): refine compatability workarounds for WinSCP
>> 
>> * Fix a number of memory faults (double-free, free of uninitialised
>>   memory, etc) in ssh(1) and ssh-keygen(1). Reported by Mateusz
>>   Kocielski.
>> 
>> Checksums:
>> ==========
>> 
>> - SHA1 (openssh-7.1.tar.gz) = 06c1db39f33831fe004726e013b2cf84f1889042
>> - SHA256 (openssh-7.1.tar.gz) =
>> H7U1se9EoBmhkKi2i7lqpMX9QHdDTsgpu7kd5VZUGSY=
>> 
>> - SHA1 (openssh-7.1p1.tar.gz) = ed22af19f962262c493fcc6ed8c8826b2761d9b6
>> - SHA256 (openssh-7.1p1.tar.gz) =
>> /AptLR0GPVxm3/2VJJPQzaJWytIE9oHeD4TvhbKthCg=
>> 
>> Please note that the SHA256 signatures are base64 encoded and not
>> hexadecimal (which is the default for most checksum tools). The PGP
>> key used to sign the releases is available as RELEASE_KEY.asc from
>> the mirror sites.
>> 
>> Reporting Bugs:
>> ===============
>> 
>> - Please read http://www.openssh.com/report.html
>>  Security bugs should be reported directly to openssh at openssh.com
>> 
>> OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt,
>> Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and
>> Ben Lindstrom.
>> 
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 
> 
> 
> -- 
> Mark Janssen  --  maniac(at)maniac.nl
> Unix / Linux Open-Source and Internet Consultant
> Maniac.nl Sig-IO.nl Vps.Stoned-IT.com
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From jonnybarnes at gmail.com  Fri Aug 21 21:57:33 2015
From: jonnybarnes at gmail.com (Jonny Barnes)
Date: Fri, 21 Aug 2015 11:57:33 +0000
Subject: Inconcsistent SSH1 option text in configure
Message-ID: <CACReSE10tXYKyKB4RxL8hcthRvKPKuyGq3X3HPw31_swqUzjpg@mail.gmail.com>

Downloaded openssh 7.1 and ran `./configure --help`. It contains the
following line:

    --without-ssh1        Enable support for SSH protocol 1

Surely the option should be `--with-ssh1` or the description should be
?Disable support for SSH protocol 1?.

From bdrewery at FreeBSD.org  Sat Aug 22 07:46:53 2015
From: bdrewery at FreeBSD.org (Bryan Drewery)
Date: Fri, 21 Aug 2015 14:46:53 -0700
Subject: HostkeyAlgorithms + support seems broken [7.0]
Message-ID: <55D79C4D.5030004@FreeBSD.org>

The `+' support for HostkeyAlgorithms seems wrong compared to the other
configuration options; it replaces with literal +value.

Default:

# sshd -v
sshd: illegal option -- v
OpenSSH_7.0p1, OpenSSL 1.0.2d 9 Jul 2015

# sshd -T -f /usr/local/etc/ssh/sshd_config|grep hostkeyalgorithms
hostkeyalgorithms
ecdsa-sha2-nistp256-cert-v01 at openssh.com,ecdsa-sha2-nistp384-cert-v01 at openssh.com,ecdsa-sha2-nistp521-cert-v01 at openssh.com,ssh-ed25519-cert-v01 at openssh.com,ssh-rsa-cert-v01 at openssh.com,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-rsa

With this in sshd_config:
HostkeyAlgorithms +ssh-dss

The result:

# sshd -T -f /usr/local/etc/ssh/sshd_config|grep hostkeyalgorithms
hostkeyalgorithms +ssh-dss

This disables all algorithms:

# ssh -vvv user at 127.0.0.1
...
debug1: REQUESTED ENC.NAME is 'chacha20-poly1305 at openssh.com'
debug1: kex: server->client chacha20-poly1305 at openssh.com <implicit> none
debug1: REQUESTED ENC.NAME is 'chacha20-poly1305 at openssh.com'
debug1: kex: client->server chacha20-poly1305 at openssh.com <implicit> none
Unable to negotiate with 127.0.0.1: no matching host key type found.
Their offer:


A similar problem exists with ssh_config:

# ssh -G user at 127.0.0.1|grep hostkeyalgorithms
hostkeyalgorithms +ssh-dss




Also many of these new configuration options are missing in the manpages.

-- 
Regards,
Bryan Drewery

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150821/8a9f0e40/attachment.bin>

From bdrewery at FreeBSD.org  Sat Aug 22 08:21:27 2015
From: bdrewery at FreeBSD.org (Bryan Drewery)
Date: Fri, 21 Aug 2015 15:21:27 -0700
Subject: Announce: OpenSSH 7.0 released
In-Reply-To: <14355436344777315020.enqueue@cvs.openbsd.org>
References: <14355436344777315020.enqueue@cvs.openbsd.org>
Message-ID: <55D7A467.8050303@FreeBSD.org>

On 8/11/2015 5:53 AM, Damien Miller wrote:
>  * sshd(8): Portable OpenSSH only: Fixed a privilege separation
>    weakness related to PAM support. Attackers who could successfully
>    compromise the pre-authentication process for remote code
>    execution and who had valid credentials on the host could
>    impersonate other users.  Reported by Moritz Jodeit.
> 
>  * sshd(8): Portable OpenSSH only: Fixed a use-after-free bug
>    related to PAM support that was reachable by attackers who could
>    compromise the pre-authentication process for remote code
>    execution. Also reported by Moritz Jodeit.

Which versions did these first exist in?

-- 
Regards,
Bryan Drewery

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150821/bf3dcd62/attachment.bin>

From keisial at gmail.com  Sat Aug 22 08:45:05 2015
From: keisial at gmail.com (=?windows-1252?Q?=C1ngel_Gonz=E1lez?=)
Date: Sat, 22 Aug 2015 00:45:05 +0200
Subject: Optional WHOIS netname on login banner
In-Reply-To: <4a68411924c1ece867d69b41ab603446@mail.burg.in>
References: <4a68411924c1ece867d69b41ab603446@mail.burg.in>
Message-ID: <55D7A9F1.4010508@gmail.com>

On 17/08/15 11:36, ricky wrote:
> I think this is probably my first post to this mailing list, so hello!
>
> Occasionally I log in to my servers from IP addresses without reverse DNS configured, so sometimes I'll see an IP I don't recognise because I can't remember what I did the day before and get a bit spooked until I WHOIS the IP and find the netname reminds me I logged in from that IP.
>
> I set out prepared to script it, but I understand that the reporting of failed/last logins is only really configurable at source, so instead of submitting a hilarious poorly coded patch from which I receive numerous critique and ridicule, I figured I'd just submit the idea/use-case and hope that at least one of you think it might be a nice idea. Even if I were to be able to submit openssh patches with code that is not awful, I think it sensible to check to see if you'd be prepared to accept such a patch in the first place anyway.
>
> Regards,
> Ricky Burgin
Welcome Ricky,

Don't worry, we wouldn't treat you that bad :)

I'm not sure if the (optional) change you propose should happen at ssh 
before sending to syslog, or rather by a wrapper showing the IPs. In the 
former case, I don't think you should put whois search code into 
openssh, but allow it to run an external program which would fetch the 
additional data.
You are interested in netname, but someone else may just be interested 
in the country and another in the AS.


Also I wouldn't be surprised if doing that reliably turns out to be 
quite complex (differences between rirs, several netnames, ips with no 
netname at all?) even though the initial assumption would be simply:
whois $ip | grep -i ^netname:

Best regards


From keisial at gmail.com  Sat Aug 22 08:49:43 2015
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Sat, 22 Aug 2015 00:49:43 +0200
Subject: [PATCH] Expand tilde for UNIX domain socket forwards.
In-Reply-To: <c731f24f22be3085@courtesan.com>
References: <1439835793-30017-1-git-send-email-lauri.vosandi@gmail.com>
 <aea6cdc0dcfc203b@courtesan.com>
 <alpine.BSO.2.20.1508180940470.32090@natsu.mindrot.org>
 <c731f24f22be3085@courtesan.com>
Message-ID: <55D7AB07.1060109@gmail.com>

The name is not that bad, and the code looks ok.



On 19/08/15 04:31, Todd C. Miller wrote:
> diff -u -p -u -r1.54 misc.h
> --- misc.h	15 Jul 2014 15:54:14 -0000	1.54
> +++ misc.h	19 Aug 2015 02:27:37 -0000
> @@ -49,7 +49,8 @@
> char *cleanhostname(char *);
> char *colon(char *);
> long convtime(const char *);
> char *tilde_expand_filename(const char *, uid_t);
> +int tilde_expand_filename2(const char *, char **, uid_t);
> char *percent_expand(const char *, ...) __attribute__((__sentinel__));
> char *tohex(const void *, size_t);
Note that here you are breaking the alignment of function names. (yep, 
completely minor)


From djm at mindrot.org  Sat Aug 22 09:24:55 2015
From: djm at mindrot.org (Damien Miller)
Date: Sat, 22 Aug 2015 09:24:55 +1000 (AEST)
Subject: Announce: OpenSSH 7.1 released
In-Reply-To: <CAKs9mshstWpAniuXnWEVt80Q_huUY7K_cCK8abXJW5srm=S34g@mail.gmail.com>
References: <8775156675321531465.enqueue@cvs.openbsd.org>
 <CAKs9mshstWpAniuXnWEVt80Q_huUY7K_cCK8abXJW5srm=S34g@mail.gmail.com>
Message-ID: <alpine.BSO.2.20.1508220924450.32090@natsu.mindrot.org>

yes, that's a typo

On Fri, 21 Aug 2015, Mark Janssen wrote:

> I'm assuming the "deprecation notice" section should refer to 7.2 now, and
> not 7.1 ?
> Mark
> 
> On Fri, Aug 21, 2015 at 8:11 AM, Damien Miller <djm at cvs.openbsd.org> wrote:
>       OpenSSH 7.1 has just been released. It will be available from
>       the
>       mirrors listed at http://www.openssh.com/ shortly.
> 
>       OpenSSH is a 100% complete SSH protocol 2.0 implementation and
>       includes sftp client and server support. OpenSSH also includes
>       transitional support for the legacy SSH 1.3 and 1.5 protocols
>       that may be enabled at compile-time.
> 
>       Once again, we would like to thank the OpenSSH community for
>       their
>       continued support of the project, especially those who
>       contributed
>       code or patches, reported bugs, tested snapshots or donated to
>       the
>       project. More information on donations may be found at:
>       http://www.openssh.com/donations.html
> 
>       Future deprecation notice
>       =========================
> 
>       We plan on retiring more legacy cryptography in the next release
>       including:
> 
>        * Refusing all RSA keys smaller than 1024 bits (the current
>       minimum
>          is 768 bits)
> 
>        * Several ciphers will be disabled by default: blowfish-cbc,
>          cast128-cbc, all arcfour variants and the rijndael-cbc
>       aliases
>          for AES.
> 
>        * MD5-based HMAC algorithms will be disabled by default.
> 
>       This list reflects our current intentions, but please check the
>       final
>       release notes for OpenSSH 7.1 when it is released.
> 
>       Changes since OpenSSH 7.0
>       =========================
> 
>       This is a bugfix release.
> 
>       Security
>       --------
> 
>        * sshd(8): OpenSSH 7.0 contained a logic error in
>       PermitRootLogin=
>          prohibit-password/without-password that could, depending on
>          compile-time configuration, permit password authentication to
>          root while preventing other forms of authentication. This
>       problem
>          was reported by Mantas Mikulenas.
> 
>       Bugfixes
>       --------
> 
>        * ssh(1), sshd(8): add compatability workarounds for FuTTY
> 
>        * ssh(1), sshd(8): refine compatability workarounds for WinSCP
> 
>        * Fix a number of memory faults (double-free, free of
>       uninitialised
>          memory, etc) in ssh(1) and ssh-keygen(1). Reported by Mateusz
>          Kocielski.
> 
>       Checksums:
>       ==========
> 
>        - SHA1 (openssh-7.1.tar.gz) =
>       06c1db39f33831fe004726e013b2cf84f1889042
>        - SHA256 (openssh-7.1.tar.gz) =
>       H7U1se9EoBmhkKi2i7lqpMX9QHdDTsgpu7kd5VZUGSY=
> 
>        - SHA1 (openssh-7.1p1.tar.gz) =
>       ed22af19f962262c493fcc6ed8c8826b2761d9b6
>        - SHA256 (openssh-7.1p1.tar.gz) =
>       /AptLR0GPVxm3/2VJJPQzaJWytIE9oHeD4TvhbKthCg=
> 
>       Please note that the SHA256 signatures are base64 encoded and
>       not
>       hexadecimal (which is the default for most checksum tools). The
>       PGP
>       key used to sign the releases is available as RELEASE_KEY.asc
>       from
>       the mirror sites.
> 
>       Reporting Bugs:
>       ===============
> 
>       - Please read http://www.openssh.com/report.html
>         Security bugs should be reported directly to
>       openssh at openssh.com
> 
>       OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo
>       de Raadt,
>       Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim
>       Rice and
>       Ben Lindstrom.
> 
>       _______________________________________________
>       openssh-unix-dev mailing list
>       openssh-unix-dev at mindrot.org
>       https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 
> 
> 
> 
> --
> Mark Janssen  --  maniac(at)maniac.nl
> Unix / Linux Open-Source and Internet Consultant
> Maniac.nl Sig-IO.nl Vps.Stoned-IT.com
> 
> 
> 

From djm at mindrot.org  Sat Aug 22 09:28:07 2015
From: djm at mindrot.org (Damien Miller)
Date: Sat, 22 Aug 2015 09:28:07 +1000 (AEST)
Subject: Announce: OpenSSH 7.0 released
In-Reply-To: <55D7A467.8050303@FreeBSD.org>
References: <14355436344777315020.enqueue@cvs.openbsd.org>
 <55D7A467.8050303@FreeBSD.org>
Message-ID: <alpine.BSO.2.20.1508220926500.32090@natsu.mindrot.org>



On Fri, 21 Aug 2015, Bryan Drewery wrote:

> On 8/11/2015 5:53 AM, Damien Miller wrote:
> >  * sshd(8): Portable OpenSSH only: Fixed a privilege separation
> >    weakness related to PAM support. Attackers who could successfully
> >    compromise the pre-authentication process for remote code
> >    execution and who had valid credentials on the host could
> >    impersonate other users.  Reported by Moritz Jodeit.
> > 
> >  * sshd(8): Portable OpenSSH only: Fixed a use-after-free bug
> >    related to PAM support that was reachable by attackers who could
> >    compromise the pre-authentication process for remote code
> >    execution. Also reported by Moritz Jodeit.
> 
> Which versions did these first exist in?

They've been there for a long time, over 12 years


From djm at mindrot.org  Sat Aug 22 09:51:51 2015
From: djm at mindrot.org (Damien Miller)
Date: Sat, 22 Aug 2015 09:51:51 +1000 (AEST)
Subject: HostkeyAlgorithms + support seems broken [7.0]
In-Reply-To: <55D79C4D.5030004@FreeBSD.org>
References: <55D79C4D.5030004@FreeBSD.org>
Message-ID: <alpine.BSO.2.20.1508220939460.32090@natsu.mindrot.org>

On Fri, 21 Aug 2015, Bryan Drewery wrote:

> The `+' support for HostkeyAlgorithms seems wrong compared to the other
> configuration options; it replaces with literal +value.

Oops, yes - it's broken for the server.

> A similar problem exists with ssh_config:
> 
> # ssh -G user at 127.0.0.1|grep hostkeyalgorithms
> hostkeyalgorithms +ssh-dss

The client handles it correctly as far as key exchange goes, but doesn't
display the expanded set. This diff fixes both:


diff --git a/readconf.c b/readconf.c
index 374e741..23d74fb 100644
--- a/readconf.c
+++ b/readconf.c
@@ -2229,6 +2229,10 @@ dump_client_config(Options *o, const char *host)
 	int i;
 	char vbuf[5];
 
+	/* This is normally prepared in ssh_kex2 */
+	if (kex_assemble_names(KEX_DEFAULT_PK_ALG, &o->hostkeyalgorithms) != 0)
+		fatal("%s: kex_assemble_names failed", __func__);
+
 	/* Most interesting options first: user, host, port */
 	dump_cfg_string(oUser, o->user);
 	dump_cfg_string(oHostName, host);
@@ -2289,7 +2293,7 @@ dump_client_config(Options *o, const char *host)
 	dump_cfg_string(oBindAddress, o->bind_address);
 	dump_cfg_string(oCiphers, o->ciphers ? o->ciphers : KEX_CLIENT_ENCRYPT);
 	dump_cfg_string(oControlPath, o->control_path);
-	dump_cfg_string(oHostKeyAlgorithms, o->hostkeyalgorithms ? o->hostkeyalgorithms : KEX_DEFAULT_PK_ALG);
+	dump_cfg_string(oHostKeyAlgorithms, o->hostkeyalgorithms);
 	dump_cfg_string(oHostKeyAlias, o->host_key_alias);
 	dump_cfg_string(oHostbasedKeyTypes, o->hostbased_key_types);
 	dump_cfg_string(oKbdInteractiveDevices, o->kbd_interactive_devices);
diff --git a/servconf.c b/servconf.c
index 04404a4..08c8139 100644
--- a/servconf.c
+++ b/servconf.c
@@ -242,8 +242,6 @@ fill_default_server_options(ServerOptions *options)
 		options->hostbased_authentication = 0;
 	if (options->hostbased_uses_name_from_packet_only == -1)
 		options->hostbased_uses_name_from_packet_only = 0;
-	if (options->hostkeyalgorithms == NULL)
-		options->hostkeyalgorithms = xstrdup(KEX_DEFAULT_PK_ALG);
 	if (options->rsa_authentication == -1)
 		options->rsa_authentication = 1;
 	if (options->pubkey_authentication == -1)
@@ -329,6 +327,8 @@ fill_default_server_options(ServerOptions *options)
 	    kex_assemble_names(KEX_SERVER_MAC, &options->macs) != 0 ||
 	    kex_assemble_names(KEX_SERVER_KEX, &options->kex_algorithms) != 0 ||
 	    kex_assemble_names(KEX_DEFAULT_PK_ALG,
+	    &options->hostkeyalgorithms) != 0 ||
+	    kex_assemble_names(KEX_DEFAULT_PK_ALG,
 	    &options->hostbased_key_types) != 0 ||
 	    kex_assemble_names(KEX_DEFAULT_PK_ALG,
 	    &options->pubkey_key_types) != 0)

From nkadel at gmail.com  Sat Aug 22 22:00:27 2015
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Sat, 22 Aug 2015 08:00:27 -0400
Subject: Optional WHOIS netname on login banner
In-Reply-To: <55D7A9F1.4010508@gmail.com>
References: <4a68411924c1ece867d69b41ab603446@mail.burg.in>
 <55D7A9F1.4010508@gmail.com>
Message-ID: <CAOCN9rzXiyDvjZAYND0qZPCoucw3dSikSHzXEcOuL5_oC2Lmfw@mail.gmail.com>

On Fri, Aug 21, 2015 at 6:45 PM, ?ngel Gonz?lez <keisial at gmail.com> wrote:
> On 17/08/15 11:36, ricky wrote:
>>
>> I think this is probably my first post to this mailing list, so hello!
>>
>> Occasionally I log in to my servers from IP addresses without reverse DNS
>> configured, so sometimes I'll see an IP I don't recognise because I can't
>> remember what I did the day before and get a bit spooked until I WHOIS the
>> IP and find the netname reminds me I logged in from that IP.
>>
>> I set out prepared to script it, but I understand that the reporting of
>> failed/last logins is only really configurable at source, so instead of
>> submitting a hilarious poorly coded patch from which I receive numerous
>> critique and ridicule, I figured I'd just submit the idea/use-case and hope
>> that at least one of you think it might be a nice idea. Even if I were to be
>> able to submit openssh patches with code that is not awful, I think it
>> sensible to check to see if you'd be prepared to accept such a patch in the
>> first place anyway.
>>
>> Regards,
>> Ricky Burgin
>
> Welcome Ricky,
>
> Don't worry, we wouldn't treat you that bad :)
>
> I'm not sure if the (optional) change you propose should happen at ssh
> before sending to syslog, or rather by a wrapper showing the IPs. In the
> former case, I don't think you should put whois search code into openssh,
> but allow it to run an external program which would fetch the additional
> data.
> You are interested in netname, but someone else may just be interested in
> the country and another in the AS.


If I may suggest, it doesn't sound like a good idea to put it in the
OpenSSH at all. If DNS behavior is failing or not fully configured,
configure DNS more fully. or acknowledge that it's not able to be
fixed. In many environments, frankly, it's not fixable: the reverse
DNS is administered by different people than the forward DNS and there
are other environments with dynamic DNS where reverse DNS is never
expired, and reverse DNS has multiple entries and is a nightmare.
This really looks like a log analysis problem to sanitize bad DNS:
trying to sanitize incomplete or bad DNS in OpenSSH processing, before
the connection is even established, sounds like a really, really deep
rathole.

A post-analysis tools for logs sounds potentially much more useful for
environments where, for performance and configuration reasons,  the
reverse DNS is turned off *entirely* by using the "sshd -u0" option.
I've certainly seen this done in worldwide, distributed networks with
CNAME or multiple A record named hosts where the reverse DNS cannot be
relied on, and the lengthy timeouts of non-existent reverse DNS
lookups caused very real performance problems.

> Also I wouldn't be surprised if doing that reliably turns out to be quite
> complex (differences between rirs, several netnames, ips with no netname at
> all?) even though the initial assumption would be simply:
> whois $ip | grep -i ^netname:
>
> Best regards

It's an unstable and potentially confusing modification of a long
stable bit of code.

From nlndipi at hotmail.com  Sun Aug 23 15:17:04 2015
From: nlndipi at hotmail.com (ali rezaee)
Date: Sun, 23 Aug 2015 05:17:04 +0000
Subject: ssh and tacacs+
Message-ID: <BAY180-W36652FD2DE0A948DE75746B7630@phx.gbl>

Hi,I'm trying to use TACACS+ authentication for ssh, but up to now, have been unsuccessful. I can login or telnet using TACACS, but apparently, ssh uses some kind of encryption, that my tacacs server cannot read. Therefore, it is unable to authenticate the user. The weird thing is that if the user has been created locally on the client system, i won't have such a problem and it authenticates just fine. I was wondering if there is a way to have ssh, not encrypt the password or if i can find a source code in the openssh library, where i can add the user locally, before authentication (I did the second one for login). I've been reading the openssh source codes and haven't yet been able to figure this out. Any help would be appreciated.Thanks,Ali Rezaee 		 	   		  

From nkadel at gmail.com  Sun Aug 23 22:23:15 2015
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Sun, 23 Aug 2015 08:23:15 -0400
Subject: ssh and tacacs+
In-Reply-To: <BAY180-W36652FD2DE0A948DE75746B7630@phx.gbl>
References: <BAY180-W36652FD2DE0A948DE75746B7630@phx.gbl>
Message-ID: <CAOCN9ryo4m1=xYnfN5B91xPW3XS5ouMA=Qm-oXkJpv=DaCEj8A@mail.gmail.com>

On Sun, Aug 23, 2015 at 1:17 AM, ali rezaee <nlndipi at hotmail.com> wrote:
> Hi,I'm trying to use TACACS+ authentication for ssh, but up to now, have been unsuccessful. I can login or telnet using TACACS, but apparently, ssh uses some kind of encryption, that my tacacs server cannot read. Therefore, it is unable to authenticate the user. The weird thing is that if the user has been created locally on the client system, i won't have such a problem and it authenticates just fine. I was wondering if there is a way to have ssh, not encrypt the password or if i can find a source code in the openssh library, where i can add the user locally, before authentication (I did the second one for login). I've been reading the openssh source codes and haven't yet been able to figure this out. Any help would be appreciated.Thanks,Ali Rezaee

Oh, brother. sounds like you are in it deep, or having some language
problems. This doesn't sound like an "OpenSSH source code" problem,
but more like an authentication layer problem, and a lot of that is
done with PAM on Linux and some other systems.

TACACS+ is an *authentication* standard, and can handle authorization
as well. Much like Active Directory, you have to keep the
authentication separate from the account management in debugging. So
one problem at a time: when you "created a local account", did you
create that account with a local password? Or did you create just the
account with a locked password, and TACACS+ is handling
authentication?

If you created an account with a local password, I bet your OpenSSH
server is not correctly configured to authenticate against the TACACS+
server. I do see plenty of Google references to "linux tacacs+ SSH'
providing hints on how to activate this with the PAM configuration, so
it does seem to be supportable.

It's also unclear what your server operating system or version of
OpenSSH are. Please post them if you need more help.

From osandov at osandov.com  Wed Aug 26 17:14:29 2015
From: osandov at osandov.com (Omar Sandoval)
Date: Wed, 26 Aug 2015 00:14:29 -0700
Subject: [PATCH] Add a ssh_config SetEnv option to override environment
 variables
Message-ID: <f9289bb1820b5aa248c2078cb0b210eb97bcc9fc.1440573095.git.osandov@osandov.com>

This can be useful when a server is missing the necessary terminfo or
locale and avoids having to manually set TERM or LANG before invoking
ssh every time.

Signed-off-by: Omar Sandoval <osandov at osandov.com>
---

Per Damien Miller's suggestion, here's a generic solution to the problem
of wanting to set environment variables per host because of missing
terminfo on the server. Now, my example from last time could be done as:

Host machine_i_use_alot
	SendEnv TERM

Host machine_without_my_locale
	SetEnv LANG C

Host *
	SetEnv TERM xterm-256color

Thanks!

 readconf.c   | 33 +++++++++++++++++++++++++++++++--
 ssh_config.5 | 10 ++++++++++
 2 files changed, 41 insertions(+), 2 deletions(-)

diff --git a/readconf.c b/readconf.c
index 1d03bdf72d92..b1cfc8e48a17 100644
--- a/readconf.c
+++ b/readconf.c
@@ -148,7 +148,7 @@ typedef enum {
 	oEnableSSHKeysign, oRekeyLimit, oVerifyHostKeyDNS, oConnectTimeout,
 	oAddressFamily, oGssAuthentication, oGssDelegateCreds,
 	oServerAliveInterval, oServerAliveCountMax, oIdentitiesOnly,
-	oSendEnv, oControlPath, oControlMaster, oControlPersist,
+	oSendEnv, oSetEnv, oControlPath, oControlMaster, oControlPersist,
 	oHashKnownHosts,
 	oTunnel, oTunnelDevice, oLocalCommand, oPermitLocalCommand,
 	oVisualHostKey, oUseRoaming,
@@ -251,6 +251,7 @@ static struct {
 	{ "serveraliveinterval", oServerAliveInterval },
 	{ "serveralivecountmax", oServerAliveCountMax },
 	{ "sendenv", oSendEnv },
+	{ "setenv", oSetEnv },
 	{ "controlpath", oControlPath },
 	{ "controlmaster", oControlMaster },
 	{ "controlpersist", oControlPersist },
@@ -749,7 +750,7 @@ process_config_line(Options *options, struct passwd *pw, const char *host,
 	char *s, **charptr, *endofnumber, *keyword, *arg, *arg2;
 	char **cpptr, fwdarg[256];
 	u_int i, *uintptr, max_entries = 0;
-	int negated, opcode, *intptr, value, value2, cmdline = 0;
+	int negated, opcode, *intptr, value, value2, cmdline = 0, j;
 	LogLevel *log_level_ptr;
 	long long val64;
 	size_t len;
@@ -1294,6 +1295,34 @@ parse_keytypes:
 		}
 		break;
 
+	case oSetEnv:
+		arg = strdelim(&s);
+		if (arg == NULL || *arg == '\0')
+			fatal("%.200s line %d: Missing environment name.",
+			    filename, linenum);
+		arg2 = strdelim(&s);
+		if (arg2 == NULL || *arg2 == '\0')
+			fatal("%.200s line %d: Missing environment value.",
+			    filename, linenum);
+		value = 0;
+		for (j = 0; j < options->num_send_env; j++) {
+			if (match_pattern(arg, options->send_env[j])) {
+				value = 1;
+				break;
+			}
+		}
+		if (*activep && !value) {
+			if (setenv(arg, arg2, 1) != 0)
+				fatal("%.200s line %d: Bad environment: %s",
+				    filename, linenum, strerror(errno));
+			if (options->num_send_env >= MAX_SEND_ENV)
+				fatal("%.200s line %d: too many send env.",
+				    filename, linenum);
+			options->send_env[options->num_send_env++] =
+			    xstrdup(arg);
+		}
+		break;
+
 	case oControlPath:
 		charptr = &options->control_path;
 		goto parse_string;
diff --git a/ssh_config.5 b/ssh_config.5
index a47f3ca9e3e2..0c578bf6d368 100644
--- a/ssh_config.5
+++ b/ssh_config.5
@@ -1444,6 +1444,16 @@ channel to request a response from the server.
 The default
 is 0, indicating that these messages will not be sent to the server.
 This option applies to protocol version 2 only.
+.It Cm SetEnv
+Overwrite a variable in the local
+.Xr environ 7
+and send it as if given in a
+.Cm SendEnv
+directive. An environment variable set by an earlier
+.Cm SetEnv
+directive or matched by an earlier
+.Cm SendEnv
+directive will not be overwritten.
 .It Cm StreamLocalBindMask
 Sets the octal file creation mode mask
 .Pq umask
-- 
2.5.0


From nboecking at deloitte.de  Wed Aug 26 20:12:45 2015
From: nboecking at deloitte.de (Boecking, Nicklas (DE - Duesseldorf))
Date: Wed, 26 Aug 2015 10:12:45 +0000
Subject: Open SSH portable security
Message-ID: <FF77159A25CFB745ADFF9913BE90FAAD0C10F99B@DEPDC1421.atrema.deloitte.com>

An embedded message was scrubbed...
From: "Boecking, Nicklas (DE - Duesseldorf)" <nboecking at deloitte.de>
Subject: Open SSH portable security
Date: Wed, 26 Aug 2015 10:12:45 +0000
Size: 15824
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20150826/aa282aa1/attachment.mht>

From peter at stuge.se  Wed Aug 26 23:50:40 2015
From: peter at stuge.se (Peter Stuge)
Date: Wed, 26 Aug 2015 15:50:40 +0200
Subject: [PATCH] Add a ssh_config SetEnv option to override environment
 variables
In-Reply-To: <f9289bb1820b5aa248c2078cb0b210eb97bcc9fc.1440573095.git.osandov@osandov.com>
References: <f9289bb1820b5aa248c2078cb0b210eb97bcc9fc.1440573095.git.osandov@osandov.com>
Message-ID: <20150826135040.29419.qmail@stuge.se>

Omar Sandoval wrote:
> +++ b/readconf.c
> @@ -1294,6 +1295,34 @@ parse_keytypes:
..
> +	case oSetEnv:
..
> +		value = 0;
> +		for (j = 0; j < options->num_send_env; j++) {
> +			if (match_pattern(arg, options->send_env[j])) {
> +				value = 1;
> +				break;
> +			}
> +		}

Should the above really use pattern matching to compare variable names?


//Peter

From wlcrls47 at gmail.com  Thu Aug 27 08:21:53 2015
From: wlcrls47 at gmail.com (Walter Carlson)
Date: Wed, 26 Aug 2015 22:21:53 +0000
Subject: Disabling host key checking on LAN
Message-ID: <CAMBGa2Et0Q10g=dyCO3ZB8kUGyoQqZH-qsV0upC9_NtT3H4pYQ@mail.gmail.com>

If I want to specify for LAN addresses that I don't want to deal with host
keys, how do I do that?  Understanding the risks, knowing almost everyone
will say not to do this - it's a horrible idea, but deciding I want to do
it anyway.  Tired of having to remove entries from known_hosts with the
multiple VM's I have that often change fingerprints, and am willing to live
with the risks.

/etc/ssh/ssh_config
Host 192.168.*.*
   StrictHostKeyChecking no
   UserKnownHostsFile /dev/null

or
   UserKnownHostsFile none

Isn't doing the trick.  With no known_hosts file in ~/.ssh or /etc, I still
get:
The authenticity of host '<hostname> (192.168.2.2)' can't be established.
ECDSA key fingerprint is SHA256:.....
Are you sure you want to continue connecting (yes/no)?

From bostjan at a2o.si  Thu Aug 27 08:53:00 2015
From: bostjan at a2o.si (Bostjan Skufca)
Date: Thu, 27 Aug 2015 00:53:00 +0200
Subject: Disabling host key checking on LAN
In-Reply-To: <CAMBGa2Et0Q10g=dyCO3ZB8kUGyoQqZH-qsV0upC9_NtT3H4pYQ@mail.gmail.com>
References: <CAMBGa2Et0Q10g=dyCO3ZB8kUGyoQqZH-qsV0upC9_NtT3H4pYQ@mail.gmail.com>
Message-ID: <CAEp_DRDnjwMb92Jsv3_1Lf79DdbBzACyZp7R3sxNLOv4XwhdaA@mail.gmail.com>

Are you connecting by specifying "ssh HOSTNAME" instead of "ssh IP.IP.IP.IP"?

If this is the case, then "Host 192.168.*.*" line never matches when
you think it should.

>From ssh_config manpage:
"The host is the hostname argument given on the command line (i.e. the
name is not converted to a canonicalized host name before matching)."

b.

On 27 August 2015 at 00:21, Walter Carlson <wlcrls47 at gmail.com> wrote:
> If I want to specify for LAN addresses that I don't want to deal with host
> keys, how do I do that?  Understanding the risks, knowing almost everyone
> will say not to do this - it's a horrible idea, but deciding I want to do
> it anyway.  Tired of having to remove entries from known_hosts with the
> multiple VM's I have that often change fingerprints, and am willing to live
> with the risks.
>
> /etc/ssh/ssh_config
> Host 192.168.*.*
>    StrictHostKeyChecking no
>    UserKnownHostsFile /dev/null
>
> or
>    UserKnownHostsFile none
>
> Isn't doing the trick.  With no known_hosts file in ~/.ssh or /etc, I still
> get:
> The authenticity of host '<hostname> (192.168.2.2)' can't be established.
> ECDSA key fingerprint is SHA256:.....
> Are you sure you want to continue connecting (yes/no)?
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From mstone at mathom.us  Thu Aug 27 09:05:50 2015
From: mstone at mathom.us (Michael Stone)
Date: Wed, 26 Aug 2015 19:05:50 -0400
Subject: Disabling host key checking on LAN
In-Reply-To: <CAMBGa2Et0Q10g=dyCO3ZB8kUGyoQqZH-qsV0upC9_NtT3H4pYQ@mail.gmail.com>
References: <CAMBGa2Et0Q10g=dyCO3ZB8kUGyoQqZH-qsV0upC9_NtT3H4pYQ@mail.gmail.com>
Message-ID: <d94a1fde-4c46-11e5-9b6a-00163eeb5320@msgid.mathom.us>

On Wed, Aug 26, 2015 at 10:21:53PM +0000, Walter Carlson wrote:
>If I want to specify for LAN addresses that I don't want to deal with host
>keys, how do I do that?  Understanding the risks, knowing almost everyone
>will say not to do this - it's a horrible idea, but deciding I want to do
>it anyway.  Tired of having to remove entries from known_hosts with the
>multiple VM's I have that often change fingerprints, and am willing to live
>with the risks.

Just use rsh?

Mike Stone

From bostjan at a2o.si  Thu Aug 27 09:47:36 2015
From: bostjan at a2o.si (Bostjan Skufca)
Date: Thu, 27 Aug 2015 01:47:36 +0200
Subject: Disabling host key checking on LAN
In-Reply-To: <CAMBGa2Fe-ekZ3gLqie7KBbbDN-qcefSg3xV+=11DgaxambmT5w@mail.gmail.com>
References: <CAMBGa2Et0Q10g=dyCO3ZB8kUGyoQqZH-qsV0upC9_NtT3H4pYQ@mail.gmail.com>
 <CAEp_DRDnjwMb92Jsv3_1Lf79DdbBzACyZp7R3sxNLOv4XwhdaA@mail.gmail.com>
 <CAMBGa2Fe-ekZ3gLqie7KBbbDN-qcefSg3xV+=11DgaxambmT5w@mail.gmail.com>
Message-ID: <CAEp_DRCvG7o-7w2ag2bsg4rWmX3hYNSxrzZifSP37Mxi+A0Pww@mail.gmail.com>

(+cc list)

You could use something in the following manner:

Match originalhost *      exec "/check/if/this/hostname/is/on/lan.sh"
    ...(lan-specific opts)...

But this one is a bit tricky to get right, as order of entries begins
to matter more than you would initially anticipate (or at least I
didn't). Also I am not using this mode with asterisk (*), but with
fixed hostnames (to determine ipv4-or-ipv6 connection without using
DNS) so it might not work at all.

b.


On 27 August 2015 at 01:25, Walter Carlson <wlcrls47 at gmail.com> wrote:
> You nailed it.  I am using a single word hostname.
>
> Is there any way for me to specify the private IP space I'm using, so I can
> use single word hostnames in the command line, without having to list each
> of them in ssh_config?
>
> Setting CanonicalizeHostname it looks like just uses the CanoncialDomains
> suffixes and CanonicalizePermittedCNAMEs rules, which I don't think I can
> set up to canonicalize to IP address.
>
> I realize I could make the options I want globally set, but I wanted them to
> be defaults for if I ever used openssh with outside-my-network systems.
>
> On Wed, Aug 26, 2015 at 10:53 PM, Bostjan Skufca <bostjan at a2o.si> wrote:
>>
>> Are you connecting by specifying "ssh HOSTNAME" instead of "ssh
>> IP.IP.IP.IP"?
>>
>> If this is the case, then "Host 192.168.*.*" line never matches when
>> you think it should.
>>
>> From ssh_config manpage:
>> "The host is the hostname argument given on the command line (i.e. the
>> name is not converted to a canonicalized host name before matching)."
>>
>> b.
>>
>> On 27 August 2015 at 00:21, Walter Carlson <wlcrls47 at gmail.com> wrote:
>> > If I want to specify for LAN addresses that I don't want to deal with
>> > host
>> > keys, how do I do that?  Understanding the risks, knowing almost
>> > everyone
>> > will say not to do this - it's a horrible idea, but deciding I want to
>> > do
>> > it anyway.  Tired of having to remove entries from known_hosts with the
>> > multiple VM's I have that often change fingerprints, and am willing to
>> > live
>> > with the risks.
>> >
>> > /etc/ssh/ssh_config
>> > Host 192.168.*.*
>> >    StrictHostKeyChecking no
>> >    UserKnownHostsFile /dev/null
>> >
>> > or
>> >    UserKnownHostsFile none
>> >
>> > Isn't doing the trick.  With no known_hosts file in ~/.ssh or /etc, I
>> > still
>> > get:
>> > The authenticity of host '<hostname> (192.168.2.2)' can't be
>> > established.
>> > ECDSA key fingerprint is SHA256:.....
>> > Are you sure you want to continue connecting (yes/no)?
>> > _______________________________________________
>> > openssh-unix-dev mailing list
>> > openssh-unix-dev at mindrot.org
>> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
>

From wlcrls47 at gmail.com  Thu Aug 27 10:26:13 2015
From: wlcrls47 at gmail.com (Walter Carlson)
Date: Thu, 27 Aug 2015 00:26:13 +0000
Subject: Disabling host key checking on LAN
In-Reply-To: <CAEp_DRCvG7o-7w2ag2bsg4rWmX3hYNSxrzZifSP37Mxi+A0Pww@mail.gmail.com>
References: <CAMBGa2Et0Q10g=dyCO3ZB8kUGyoQqZH-qsV0upC9_NtT3H4pYQ@mail.gmail.com>
 <CAEp_DRDnjwMb92Jsv3_1Lf79DdbBzACyZp7R3sxNLOv4XwhdaA@mail.gmail.com>
 <CAMBGa2Fe-ekZ3gLqie7KBbbDN-qcefSg3xV+=11DgaxambmT5w@mail.gmail.com>
 <CAEp_DRCvG7o-7w2ag2bsg4rWmX3hYNSxrzZifSP37Mxi+A0Pww@mail.gmail.com>
Message-ID: <CAMBGa2E1OvCuje8aR1Gz5gv=bvVs1RWwG=xznQRop_iPY9pueg@mail.gmail.com>

Perfect, thanks.  This winds up working for me (as far as I've tested so
far.)

Match exec "ping -q -c 1 -t 1 %n | grep '192\.168\.'"
   StrictHostKeyChecking no
   UserKnownHostsFile none

On Wed, Aug 26, 2015 at 11:47 PM, Bostjan Skufca <bostjan at a2o.si> wrote:

> (+cc list)
>
> You could use something in the following manner:
>
> Match originalhost *      exec "/check/if/this/hostname/is/on/lan.sh"
>     ...(lan-specific opts)...
>
> But this one is a bit tricky to get right, as order of entries begins
> to matter more than you would initially anticipate (or at least I
> didn't). Also I am not using this mode with asterisk (*), but with
> fixed hostnames (to determine ipv4-or-ipv6 connection without using
> DNS) so it might not work at all.
>
> b.
>
>
> On 27 August 2015 at 01:25, Walter Carlson <wlcrls47 at gmail.com> wrote:
> > You nailed it.  I am using a single word hostname.
> >
> > Is there any way for me to specify the private IP space I'm using, so I
> can
> > use single word hostnames in the command line, without having to list
> each
> > of them in ssh_config?
> >
> > Setting CanonicalizeHostname it looks like just uses the CanoncialDomains
> > suffixes and CanonicalizePermittedCNAMEs rules, which I don't think I can
> > set up to canonicalize to IP address.
> >
> > I realize I could make the options I want globally set, but I wanted
> them to
> > be defaults for if I ever used openssh with outside-my-network systems.
> >
> > On Wed, Aug 26, 2015 at 10:53 PM, Bostjan Skufca <bostjan at a2o.si> wrote:
> >>
> >> Are you connecting by specifying "ssh HOSTNAME" instead of "ssh
> >> IP.IP.IP.IP"?
> >>
> >> If this is the case, then "Host 192.168.*.*" line never matches when
> >> you think it should.
> >>
> >> From ssh_config manpage:
> >> "The host is the hostname argument given on the command line (i.e. the
> >> name is not converted to a canonicalized host name before matching)."
> >>
> >> b.
> >>
> >> On 27 August 2015 at 00:21, Walter Carlson <wlcrls47 at gmail.com> wrote:
> >> > If I want to specify for LAN addresses that I don't want to deal with
> >> > host
> >> > keys, how do I do that?  Understanding the risks, knowing almost
> >> > everyone
> >> > will say not to do this - it's a horrible idea, but deciding I want to
> >> > do
> >> > it anyway.  Tired of having to remove entries from known_hosts with
> the
> >> > multiple VM's I have that often change fingerprints, and am willing to
> >> > live
> >> > with the risks.
> >> >
> >> > /etc/ssh/ssh_config
> >> > Host 192.168.*.*
> >> >    StrictHostKeyChecking no
> >> >    UserKnownHostsFile /dev/null
> >> >
> >> > or
> >> >    UserKnownHostsFile none
> >> >
> >> > Isn't doing the trick.  With no known_hosts file in ~/.ssh or /etc, I
> >> > still
> >> > get:
> >> > The authenticity of host '<hostname> (192.168.2.2)' can't be
> >> > established.
> >> > ECDSA key fingerprint is SHA256:.....
> >> > Are you sure you want to continue connecting (yes/no)?
> >> > _______________________________________________
> >> > openssh-unix-dev mailing list
> >> > openssh-unix-dev at mindrot.org
> >> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> >
> >
>

From peter at stuge.se  Thu Aug 27 12:23:19 2015
From: peter at stuge.se (Peter Stuge)
Date: Thu, 27 Aug 2015 04:23:19 +0200
Subject: Disabling host key checking on LAN
In-Reply-To: <CAMBGa2E1OvCuje8aR1Gz5gv=bvVs1RWwG=xznQRop_iPY9pueg@mail.gmail.com>
References: <CAMBGa2Et0Q10g=dyCO3ZB8kUGyoQqZH-qsV0upC9_NtT3H4pYQ@mail.gmail.com>
 <CAEp_DRDnjwMb92Jsv3_1Lf79DdbBzACyZp7R3sxNLOv4XwhdaA@mail.gmail.com>
 <CAMBGa2Fe-ekZ3gLqie7KBbbDN-qcefSg3xV+=11DgaxambmT5w@mail.gmail.com>
 <CAEp_DRCvG7o-7w2ag2bsg4rWmX3hYNSxrzZifSP37Mxi+A0Pww@mail.gmail.com>
 <CAMBGa2E1OvCuje8aR1Gz5gv=bvVs1RWwG=xznQRop_iPY9pueg@mail.gmail.com>
Message-ID: <20150827022319.21148.qmail@stuge.se>

Walter Carlson wrote:
> Match exec "ping -q -c 1 -t 1 %n | grep '192\.168\.'"

Maybe use host(1) instead.


//Peter

From djm at mindrot.org  Thu Aug 27 13:01:25 2015
From: djm at mindrot.org (Damien Miller)
Date: Thu, 27 Aug 2015 13:01:25 +1000 (AEST)
Subject: Disabling host key checking on LAN
In-Reply-To: <CAEp_DRDnjwMb92Jsv3_1Lf79DdbBzACyZp7R3sxNLOv4XwhdaA@mail.gmail.com>
References: <CAMBGa2Et0Q10g=dyCO3ZB8kUGyoQqZH-qsV0upC9_NtT3H4pYQ@mail.gmail.com>
 <CAEp_DRDnjwMb92Jsv3_1Lf79DdbBzACyZp7R3sxNLOv4XwhdaA@mail.gmail.com>
Message-ID: <alpine.BSO.2.20.1508271258040.19592@natsu.mindrot.org>

On Thu, 27 Aug 2015, Bostjan Skufca wrote:

> Are you connecting by specifying "ssh HOSTNAME" instead of "ssh IP.IP.IP.IP"?
> 
> If this is the case, then "Host 192.168.*.*" line never matches when
> you think it should.
> 
> From ssh_config manpage:
> "The host is the hostname argument given on the command line (i.e. the
> name is not converted to a canonicalized host name before matching)."

Yeah, it's unfortunately quite difficult to implement address matching
in ~/.ssh/config because of the interplay of Host matching, Hostname
directives, hostname canonicalisation*, proxy commands, hosts having
multiple addresses, IPv4/IPv6 and when the addresses are actually
resolved and available to the parser.

I've not figured out a clean way to do it that isn't also complex and
probably fragile to implement.

-d

* that was my contribution to the problem :/

From mancha1 at zoho.com  Fri Aug 28 14:28:39 2015
From: mancha1 at zoho.com (mancha)
Date: Fri, 28 Aug 2015 04:28:39 +0000
Subject: Announce: OpenSSH 7.1 released
In-Reply-To: <8775156675321531465.enqueue@cvs.openbsd.org>
References: <8775156675321531465.enqueue@cvs.openbsd.org>
Message-ID: <20150828042839.GA6540@zoho.com>

On Fri, Aug 21, 2015 at 12:11:02AM -0600, Damien Miller wrote:
> OpenSSH 7.1 has just been released. It will be available from the
> mirrors listed at http://www.openssh.com/ shortly.

For those using my TCP Wrapper patch, you can use the 7.0p1 patch
against 7.1p1.

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

From bostjan at a2o.si  Fri Aug 28 22:48:09 2015
From: bostjan at a2o.si (Bostjan Skufca)
Date: Fri, 28 Aug 2015 14:48:09 +0200
Subject: Disabling host key checking on LAN
In-Reply-To: <alpine.BSO.2.20.1508271258040.19592@natsu.mindrot.org>
References: <CAMBGa2Et0Q10g=dyCO3ZB8kUGyoQqZH-qsV0upC9_NtT3H4pYQ@mail.gmail.com>
 <CAEp_DRDnjwMb92Jsv3_1Lf79DdbBzACyZp7R3sxNLOv4XwhdaA@mail.gmail.com>
 <alpine.BSO.2.20.1508271258040.19592@natsu.mindrot.org>
Message-ID: <CAEp_DRCpPYVXQr8AkC3V3e1xRHKGgSAvyuqnNaZb_ZHcvvhqzg@mail.gmail.com>

On 27 August 2015 at 05:01, Damien Miller <djm at mindrot.org> wrote:
> Yeah, it's unfortunately quite difficult to implement address matching
> in ~/.ssh/config because of the interplay of Host matching, Hostname
> directives, hostname canonicalisation*, proxy commands, hosts having
> multiple addresses, IPv4/IPv6 and when the addresses are actually
> resolved and available to the parser.
>
> I've not figured out a clean way to do it that isn't also complex and
> probably fragile to implement.

If we disregard the "complex and probably fragile" part, what is the
"clean way" you are talking about?
Do you have some sort of RFC written down somewhere?


b.

From nkadel at gmail.com  Fri Aug 28 23:10:41 2015
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Fri, 28 Aug 2015 09:10:41 -0400
Subject: Disabling host key checking on LAN
In-Reply-To: <CAEp_DRCpPYVXQr8AkC3V3e1xRHKGgSAvyuqnNaZb_ZHcvvhqzg@mail.gmail.com>
References: <CAMBGa2Et0Q10g=dyCO3ZB8kUGyoQqZH-qsV0upC9_NtT3H4pYQ@mail.gmail.com>
 <CAEp_DRDnjwMb92Jsv3_1Lf79DdbBzACyZp7R3sxNLOv4XwhdaA@mail.gmail.com>
 <alpine.BSO.2.20.1508271258040.19592@natsu.mindrot.org>
 <CAEp_DRCpPYVXQr8AkC3V3e1xRHKGgSAvyuqnNaZb_ZHcvvhqzg@mail.gmail.com>
Message-ID: <CAOCN9rwJBZGiPBUAXAQHhGLBHj0LVxmttDFrzVWnkZdZVDCt_w@mail.gmail.com>

On Fri, Aug 28, 2015 at 8:48 AM, Bostjan Skufca <bostjan at a2o.si> wrote:
> On 27 August 2015 at 05:01, Damien Miller <djm at mindrot.org> wrote:
>> Yeah, it's unfortunately quite difficult to implement address matching
>> in ~/.ssh/config because of the interplay of Host matching, Hostname
>> directives, hostname canonicalisation*, proxy commands, hosts having
>> multiple addresses, IPv4/IPv6 and when the addresses are actually
>> resolved and available to the parser.
>>
>> I've not figured out a clean way to do it that isn't also complex and
>> probably fragile to implement.
>
> If we disregard the "complex and probably fragile" part, what is the
> "clean way" you are talking about?
> Do you have some sort of RFC written down somewhere?

The interplays between DNS and multiple formats for the same target
SSH server makes such an RFC a nightmare in outsmarting all the local
settings. In complex environments, I'm afraid that "known_hosts" is
often an active detriment to stable operation, especially because
there is *no* published tool for "scrub the old rejected line and
accept the new one*. It's most clear when a new server on the same IP
address replaces an old host but uses new SSH host keys.

In environments where critical server hostnames and IP addresses are
not tied to consistent SSH keys, I'm afraid there is little choice but
to discard the use of known_hosts.

From bostjan at a2o.si  Sat Aug 29 00:37:19 2015
From: bostjan at a2o.si (Bostjan Skufca)
Date: Fri, 28 Aug 2015 16:37:19 +0200
Subject: Disabling host key checking on LAN
In-Reply-To: <CAOCN9rwJBZGiPBUAXAQHhGLBHj0LVxmttDFrzVWnkZdZVDCt_w@mail.gmail.com>
References: <CAMBGa2Et0Q10g=dyCO3ZB8kUGyoQqZH-qsV0upC9_NtT3H4pYQ@mail.gmail.com>
 <CAEp_DRDnjwMb92Jsv3_1Lf79DdbBzACyZp7R3sxNLOv4XwhdaA@mail.gmail.com>
 <alpine.BSO.2.20.1508271258040.19592@natsu.mindrot.org>
 <CAEp_DRCpPYVXQr8AkC3V3e1xRHKGgSAvyuqnNaZb_ZHcvvhqzg@mail.gmail.com>
 <CAOCN9rwJBZGiPBUAXAQHhGLBHj0LVxmttDFrzVWnkZdZVDCt_w@mail.gmail.com>
Message-ID: <CAEp_DRDFFB1uEwpQaobzth8uXCMrbAaApTn8PoE76Hi=0uf-rQ@mail.gmail.com>

On 28 August 2015 at 15:10, Nico Kadel-Garcia <nkadel at gmail.com> wrote:
>
> In environments where critical server hostnames and IP addresses are
> not tied to consistent SSH keys, I'm afraid there is little choice but
> to discard the use of known_hosts.
>

Shouldn't in such complex environments configuration management
pre-generate known_hosts from collected facts from hosts?

I know it is a hassle, but having a fuse that ensures that you are indeed
connecting to what you think you are connecting to is something worth
having, or not?

b.

From mebhat at akamai.com  Sat Aug 29 06:29:36 2015
From: mebhat at akamai.com (Meghana Bhat)
Date: Fri, 28 Aug 2015 16:29:36 -0400
Subject: [PATCH] ssh-keygen: Add ssh agent support for generating certificates
Message-ID: <1440793776-8278-1-git-send-email-mebhat@akamai.com>

Communicate with the ssh agent to sign certificates if agent is present
and is loaded with the specified certificate authority.
In order for the agent to sign, the certificate authority public key
must be alongside the private key with the same file name but a .pub
extension.
This patch addresses the bug at:
https://bugzilla.mindrot.org/show_bug.cgi?id=2377
Patch developed against 7.1p.
---
 authfd.c     |   2 +-
 authfd.h     |   1 +
 ssh-keygen.c | 109 ++++++++++++++++++++++++++++++++++++++++++++++++++++-------
 sshkey.c     |  36 +++++++++++++++-----
 sshkey.h     |   1 +
 5 files changed, 126 insertions(+), 23 deletions(-)

diff --git a/authfd.c b/authfd.c
index eaa1426..f7933fc 100644
--- a/authfd.c
+++ b/authfd.c
@@ -121,7 +121,7 @@ ssh_get_authentication_socket(int *fdp)
 }
 
 /* Communicate with agent: send request and read reply */
-static int
+int
 ssh_request_reply(int sock, struct sshbuf *request, struct sshbuf *reply)
 {
 	int r;
diff --git a/authfd.h b/authfd.h
index bea20c2..f58af43 100644
--- a/authfd.h
+++ b/authfd.h
@@ -42,6 +42,7 @@ int	ssh_decrypt_challenge(int sock, struct sshkey* key, BIGNUM *challenge,
 int	ssh_agent_sign(int sock, struct sshkey *key,
 	    u_char **sigp, size_t *lenp,
 	    const u_char *data, size_t datalen, u_int compat);
+int	ssh_request_reply(int sock, struct sshbuf *request, struct sshbuf *reply);
 
 /* Messages for the authentication agent connection. */
 #define SSH_AGENTC_REQUEST_RSA_IDENTITIES	1
diff --git a/ssh-keygen.c b/ssh-keygen.c
index 4e0a855..168d6c0 100644
--- a/ssh-keygen.c
+++ b/ssh-keygen.c
@@ -57,6 +57,7 @@
 #include "atomicio.h"
 #include "krl.h"
 #include "digest.h"
+#include "authfd.h"
 
 #ifdef WITH_OPENSSL
 # define DEFAULT_KEY_TYPE_NAME "rsa"
@@ -1566,25 +1567,92 @@ load_pkcs11_key(char *path)
 #endif /* ENABLE_PKCS11 */
 }
 
+static int
+do_agent_sign(int agent_fd, struct sshkey *k, struct sshkey *ca_pk,
+	u_char *ca_blob, size_t ca_len)
+{
+	u_char type;
+	u_char *sig;
+	size_t slen;
+	struct sshbuf *msg, *cert_blob;
+	u_int flags = 0;
+	int ret = 0, r = 0;
+
+	cert_blob = k->cert->certblob; /* for readability */
+	if ((msg = sshbuf_new()) == NULL)
+		fatal("%s: sshbuf_new failed", __func__);
+	if ((r = sshkey_cert_prepare_sign(k, ca_pk)) != 0) {
+		ret = -1;
+	}
+	
+	if (ret == 0) {
+		if ((r = sshbuf_put_u8(msg, SSH2_AGENTC_SIGN_REQUEST)) != 0 ||
+			(r = sshbuf_put_string(msg, ca_blob, ca_len)) != 0 ||
+			(r = sshbuf_put_string(msg, sshbuf_ptr(cert_blob),
+			sshbuf_len(cert_blob))) != 0 ||
+			(r = sshbuf_put_u32(msg, flags)) != 0)
+			fatal("%s: buffer error: %s", __func__, ssh_err(r));
+		if ((r = ssh_request_reply(agent_fd, msg, msg)) != 0)
+			ret = -1;
+		else if ((r = sshbuf_get_u8(msg, &type)) != 0)
+			fatal("%s: buffer error: %s", __func__, ssh_err(r));
+		else if ((type == SSH_AGENT_FAILURE) ||
+				 (type == SSH2_AGENT_FAILURE))
+			ret = -1;
+		else if ((r = sshbuf_get_string(msg, &sig, &slen)) != 0 ||
+				 (r = sshbuf_put_string(cert_blob, sig, slen)) != 0)
+			fatal("%s: buffer error: %s", __func__, ssh_err(r));
+		else
+			free(sig);
+	}
+	
+	sshbuf_free(msg);
+	return ret;
+}
+
 static void
 do_ca_sign(struct passwd *pw, int argc, char **argv)
 {
-	int r, i, fd;
+	int r, i, fd, agent_fd;
 	u_int n;
-	struct sshkey *ca, *public;
+	struct sshkey *ca, *ca_pk, *public;
 	char *otmp, *tmp, *cp, *out, *comment, **plist = NULL;
 	FILE *f;
+	u_char *ca_blob;
+	size_t ca_len;
+	/* flag indicating whether to try the ssh-agent to sign certificates */
+	int try_agent = 0;
 
 #ifdef ENABLE_PKCS11
 	pkcs11_init(1);
 #endif
+	
+	/* load pubkey of CA first (ca_blob), if it works, try getting agent socket */
 	tmp = tilde_expand_filename(ca_key_path, pw->pw_uid);
-	if (pkcs11provider != NULL) {
-		if ((ca = load_pkcs11_key(tmp)) == NULL)
-			fatal("No PKCS#11 key matching %s found", ca_key_path);
-	} else
-		ca = load_identity(tmp);
-	free(tmp);
+	if ((r = sshkey_load_public(tmp, &ca_pk, NULL)) == 0 &&
+	    (r = sshkey_to_blob(ca_pk, &ca_blob, &ca_len)) == 0) {
+		switch (r = ssh_get_authentication_socket(&agent_fd)) {
+		case SSH_ERR_SUCCESS:
+			try_agent = 1;
+			ca = NULL;
+			break;
+		case SSH_ERR_AGENT_NOT_PRESENT:
+			debug("Couldn't open connection to agent");
+			break;
+		default:
+			debug("Error connecting to agent");
+			break;
+		}
+	}
+	
+	if (!try_agent) {
+		if (pkcs11provider != NULL) {
+			if ((ca = load_pkcs11_key(tmp)) == NULL)
+				fatal("No PKCS#11 key matching %s found", ca_key_path);
+		} else
+			ca = load_identity(tmp);
+		free(tmp);
+	}
 
 	for (i = 0; i < argc; i++) {
 		/* Split list of principals */
@@ -1623,13 +1691,28 @@ do_ca_sign(struct passwd *pw, int argc, char **argv)
 		prepare_options_buf(public->cert->critical, OPTIONS_CRITICAL);
 		prepare_options_buf(public->cert->extensions,
 		    OPTIONS_EXTENSIONS);
-		if ((r = sshkey_from_private(ca,
-		    &public->cert->signature_key)) != 0)
-			fatal("key_from_private (ca key): %s", ssh_err(r));
 
-		if (sshkey_certify(public, ca) != 0)
-			fatal("Couldn't not certify key %s", tmp);
+		if (try_agent &&
+			(r = do_agent_sign(agent_fd, public, ca_pk, ca_blob, ca_len)) != 0) {
+			try_agent = 0;
+			otmp = tilde_expand_filename(ca_key_path, pw->pw_uid);
+			if (pkcs11provider != NULL) {
+				if ((ca = load_pkcs11_key(otmp)) == NULL)
+					fatal("No PKCS#11 key matching %s found", ca_key_path);
+			} else
+				ca = load_identity(otmp);
+			free(otmp);
+		}
 
+		if (!try_agent) {
+			if ((r = sshkey_from_private(ca,
+			    &public->cert->signature_key)) != 0)
+				fatal("key_from_private (ca key): %s", ssh_err(r));
+	
+			if (sshkey_certify(public, ca) != 0)
+				fatal("Couldn't not certify key %s", tmp);
+		}
+	
 		if ((cp = strrchr(tmp, '.')) != NULL && strcmp(cp, ".pub") == 0)
 			*cp = '\0';
 		xasprintf(&out, "%s-cert.pub", tmp);
diff --git a/sshkey.c b/sshkey.c
index 32dd8f2..bded18a 100644
--- a/sshkey.c
+++ b/sshkey.c
@@ -2370,13 +2370,12 @@ sshkey_drop_cert(struct sshkey *k)
 	return 0;
 }
 
-/* Sign a certified key, (re-)generating the signed certblob. */
+/* Prepare a certificate blob for CA signing. */
 int
-sshkey_certify(struct sshkey *k, struct sshkey *ca)
-{
+sshkey_cert_prepare_sign(struct sshkey *k, struct sshkey *ca) {
 	struct sshbuf *principals = NULL;
-	u_char *ca_blob = NULL, *sig_blob = NULL, nonce[32];
-	size_t i, ca_len, sig_len;
+	u_char *ca_blob = NULL, nonce[32];
+	size_t i, ca_len;
 	int ret = SSH_ERR_INTERNAL_ERROR;
 	struct sshbuf *cert;
 
@@ -2459,7 +2458,30 @@ sshkey_certify(struct sshkey *k, struct sshkey *ca)
 	    (ret = sshbuf_put_string(cert, NULL, 0)) != 0 || /* Reserved */
 	    (ret = sshbuf_put_string(cert, ca_blob, ca_len)) != 0)
 		goto out;
+	ret = 0;
+ out:
+	if (ret != 0)
+		sshbuf_reset(cert);
+	if (ca_blob != NULL)
+		free(ca_blob);
+	if (principals != NULL)
+		sshbuf_free(principals);
+	return ret;
+}
 
+/* Sign a certified key, (re-)generating the signed certblob. */
+int
+sshkey_certify(struct sshkey *k, struct sshkey *ca)
+{
+	u_char *sig_blob = NULL;
+	size_t sig_len;
+	int ret = SSH_ERR_INTERNAL_ERROR;
+	struct sshbuf *cert;
+  
+	cert = k->cert->certblob; /* for readability */
+	if ((ret = sshkey_cert_prepare_sign(k, ca)) != 0)
+		goto out;
+	
 	/* Sign the whole mess */
 	if ((ret = sshkey_sign(ca, &sig_blob, &sig_len, sshbuf_ptr(cert),
 	    sshbuf_len(cert), 0)) != 0)
@@ -2474,10 +2496,6 @@ sshkey_certify(struct sshkey *k, struct sshkey *ca)
 		sshbuf_reset(cert);
 	if (sig_blob != NULL)
 		free(sig_blob);
-	if (ca_blob != NULL)
-		free(ca_blob);
-	if (principals != NULL)
-		sshbuf_free(principals);
 	return ret;
 }
 
diff --git a/sshkey.h b/sshkey.h
index c8d3cdd..0a62563 100644
--- a/sshkey.h
+++ b/sshkey.h
@@ -137,6 +137,7 @@ int	 sshkey_type_is_cert(int);
 int	 sshkey_type_plain(int);
 int	 sshkey_to_certified(struct sshkey *);
 int	 sshkey_drop_cert(struct sshkey *);
+int	 sshkey_cert_prepare_sign(struct sshkey *, struct sshkey *);
 int	 sshkey_certify(struct sshkey *, struct sshkey *);
 int	 sshkey_cert_copy(const struct sshkey *, struct sshkey *);
 int	 sshkey_cert_check_authority(const struct sshkey *, int, int,
-- 
2.3.2 (Apple Git-55)


From kaleb at wolfssl.com  Sat Aug 29 06:57:49 2015
From: kaleb at wolfssl.com (Kaleb Himes)
Date: Fri, 28 Aug 2015 14:57:49 -0600
Subject: Inter-op and port (wolfSSL + openSSH)
Message-ID: <CAMB3dQW206OH4Vmg3X4Zc174ZMuesMwveXxU7G7NTOzZMc1-Xg@mail.gmail.com>

To whom it may concern,

I work for a company wolfSSL .Inc. Over the summer some of our engineers
have worked to build openSSH with wolfSSL instead of openSSL as we were
tired of constant security issues needing patched due to openSSL
compilation. As a result of the efforts made we would like to submit a
patch that offers users an alternate configure option when configuring
openSSH (--with-wolfssl). Similary in our libraries we now have the option
"--with-openssh".

Could you please get this to the relevant individual(s). We have an altered
version of openSSH we currently use and a README to go along which will
make initial testing / integration easier.

Additionally we are conscious that the changes we made for our purposes may
not reflect the goals of the openSSH community as a whole. We would
therefore like to discuss the goals of openSSH so that if a patch is
implemented, that patch will reflect the goals, wants, and needs of the
openSSH community as a whole and not just us here at wolfSSL.

Thank you so much for your time and we look forward to further discussion.


Kind Regards,

Kaleb Himes

www.wolfssl.com

kaleb at wolfssl.com

Skype: kaleb.himes

+1 406 381 9556

From nkadel at gmail.com  Sat Aug 29 11:16:21 2015
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Fri, 28 Aug 2015 21:16:21 -0400
Subject: Disabling host key checking on LAN
In-Reply-To: <CAEp_DRDFFB1uEwpQaobzth8uXCMrbAaApTn8PoE76Hi=0uf-rQ@mail.gmail.com>
References: <CAMBGa2Et0Q10g=dyCO3ZB8kUGyoQqZH-qsV0upC9_NtT3H4pYQ@mail.gmail.com>
 <CAEp_DRDnjwMb92Jsv3_1Lf79DdbBzACyZp7R3sxNLOv4XwhdaA@mail.gmail.com>
 <alpine.BSO.2.20.1508271258040.19592@natsu.mindrot.org>
 <CAEp_DRCpPYVXQr8AkC3V3e1xRHKGgSAvyuqnNaZb_ZHcvvhqzg@mail.gmail.com>
 <CAOCN9rwJBZGiPBUAXAQHhGLBHj0LVxmttDFrzVWnkZdZVDCt_w@mail.gmail.com>
 <CAEp_DRDFFB1uEwpQaobzth8uXCMrbAaApTn8PoE76Hi=0uf-rQ@mail.gmail.com>
Message-ID: <CAOCN9rzRMX-PpRs1M1igQLJTxLY=Nuqe9fBFPADoQzbuhqoyiA@mail.gmail.com>

On Fri, Aug 28, 2015 at 10:37 AM, Bostjan Skufca <bostjan at a2o.si> wrote:
>
> On 28 August 2015 at 15:10, Nico Kadel-Garcia <nkadel at gmail.com> wrote:
>>
>> In environments where critical server hostnames and IP addresses are
>> not tied to consistent SSH keys, I'm afraid there is little choice but
>> to discard the use of known_hosts.
>
>
> Shouldn't in such complex environments configuration management pre-generate
> known_hosts from collected facts from hosts?

At first glance, that sounds like a great idea. From harsh experience,
the man-hours and system resources and system integration blown on
building and maintaining and publishing such a system, and keeping it
synced despite the phase lag between the DHCP or system re-allocaiton
systems is dangerous, and it's much worse in an AD or Samba version of
dynamic DNS used to register wandering laptops. And now, as IPv4
addressea are finally being used up and companies are scrambling to
re-arrange and re-allocate IP space, the addresses are even more
likely to be re-used for another host with another key.

I simply don't see many graceful ways to track *all possible* hostkey
address spaces, and to find *everybody's* accidentally locally
published known_hosts to scrub them of entries that are in the
system's /etc/ssh/known_hosts or similar file.

My favorite recent example of where it bites me is small test or
staging environments, where the host keys for new test hosts are
generated dynamically and the IP addresses are re-used. It's so much
faster to simply turn off hostkeys altogether and make it stop
whinging at me, it seems much more effective than building and
maintaining an authorized_)keys generation tool. The payoff is very
small for all the work.

> I know it is a hassle, but having a fuse that ensures that you are indeed
> connecting to what you think you are connecting to is something worth
> having, or not?
>
> b.

For environments where IP addresses are consistent for the same IP
address, it can be useful.  But it's cycles of setup and maintainence
better used elsewhere in the environments I've mentioned.

From wlcrls47 at gmail.com  Sat Aug 29 13:51:38 2015
From: wlcrls47 at gmail.com (Walter Carlson)
Date: Sat, 29 Aug 2015 03:51:38 +0000
Subject: Disabling host key checking on LAN
In-Reply-To: <CAMBGa2E1OvCuje8aR1Gz5gv=bvVs1RWwG=xznQRop_iPY9pueg@mail.gmail.com>
References: <CAMBGa2Et0Q10g=dyCO3ZB8kUGyoQqZH-qsV0upC9_NtT3H4pYQ@mail.gmail.com>
 <CAEp_DRDnjwMb92Jsv3_1Lf79DdbBzACyZp7R3sxNLOv4XwhdaA@mail.gmail.com>
 <CAMBGa2Fe-ekZ3gLqie7KBbbDN-qcefSg3xV+=11DgaxambmT5w@mail.gmail.com>
 <CAEp_DRCvG7o-7w2ag2bsg4rWmX3hYNSxrzZifSP37Mxi+A0Pww@mail.gmail.com>
 <CAMBGa2E1OvCuje8aR1Gz5gv=bvVs1RWwG=xznQRop_iPY9pueg@mail.gmail.com>
Message-ID: <CAMBGa2Ewb3j_H3tG6shVNk8xFiRiBMMPBqCD-rBLhL9vh7gGbQ@mail.gmail.com>

On Thu, Aug 27, 2015 at 12:26 AM, Walter Carlson <wlcrls47 at gmail.com> wrote:

> Perfect, thanks.  This winds up working for me (as far as I've tested so
> far.)
>
> Match exec "ping -q -c 1 -t 1 %n | grep '192\.168\.'"
>    StrictHostKeyChecking no
>    UserKnownHostsFile none
>

For the record, the last line has to be "UserKnownHostsFile /dev/null".  I
saw "none" being used in others' openssh examples, but for me, that's using
the file ~/none rather than being interpreted as "don't use one".

From nkadel at gmail.com  Sat Aug 29 20:25:59 2015
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Sat, 29 Aug 2015 06:25:59 -0400
Subject: Disabling host key checking on LAN
In-Reply-To: <CAMBGa2Ewb3j_H3tG6shVNk8xFiRiBMMPBqCD-rBLhL9vh7gGbQ@mail.gmail.com>
References: <CAMBGa2Et0Q10g=dyCO3ZB8kUGyoQqZH-qsV0upC9_NtT3H4pYQ@mail.gmail.com>
 <CAEp_DRDnjwMb92Jsv3_1Lf79DdbBzACyZp7R3sxNLOv4XwhdaA@mail.gmail.com>
 <CAMBGa2Fe-ekZ3gLqie7KBbbDN-qcefSg3xV+=11DgaxambmT5w@mail.gmail.com>
 <CAEp_DRCvG7o-7w2ag2bsg4rWmX3hYNSxrzZifSP37Mxi+A0Pww@mail.gmail.com>
 <CAMBGa2E1OvCuje8aR1Gz5gv=bvVs1RWwG=xznQRop_iPY9pueg@mail.gmail.com>
 <CAMBGa2Ewb3j_H3tG6shVNk8xFiRiBMMPBqCD-rBLhL9vh7gGbQ@mail.gmail.com>
Message-ID: <CAOCN9ryKd1Evz135QNuwFmOQEYa6xOf5cN_TbCUNH59ff5asWA@mail.gmail.com>

On Fri, Aug 28, 2015 at 11:51 PM, Walter Carlson <wlcrls47 at gmail.com> wrote:
> On Thu, Aug 27, 2015 at 12:26 AM, Walter Carlson <wlcrls47 at gmail.com> wrote:
>
>> Perfect, thanks.  This winds up working for me (as far as I've tested so
>> far.)
>>
>> Match exec "ping -q -c 1 -t 1 %n | grep '192\.168\.'"
>>    StrictHostKeyChecking no
>>    UserKnownHostsFile none
>>
>
> For the record, the last line has to be "UserKnownHostsFile /dev/null".  I
> saw "none" being used in others' openssh examples, but for me, that's using
> the file ~/none rather than being interpreted as "don't use one".

If you've installed the relevant "bind-utils" or similar DNS package,
can't you ust use "host %n  | grep ' 192\.168\\." ? It's faster than
running ping, especially for non-responsive hosts.

From peter at stuge.se  Sat Aug 29 21:33:27 2015
From: peter at stuge.se (Peter Stuge)
Date: Sat, 29 Aug 2015 13:33:27 +0200
Subject: Inter-op and port (wolfSSL + openSSH)
In-Reply-To: <CAMB3dQW206OH4Vmg3X4Zc174ZMuesMwveXxU7G7NTOzZMc1-Xg@mail.gmail.com>
References: <CAMB3dQW206OH4Vmg3X4Zc174ZMuesMwveXxU7G7NTOzZMc1-Xg@mail.gmail.com>
Message-ID: <20150829113327.12964.qmail@stuge.se>

Kaleb Himes wrote:
> As a result of the efforts made we would like to submit a patch

Send it as an attachment to start the conversation.


> Could you please get this to the relevant individual(s).

The way it works is that you send your code, as a patch against
current git, to start things off.


> we are conscious that the changes we made for our purposes may
> not reflect the goals of the openSSH community as a whole.

Noone can see what you've done unless you send a patch.


//Peter

From djm at mindrot.org  Sun Aug 30 13:58:15 2015
From: djm at mindrot.org (Damien Miller)
Date: Sun, 30 Aug 2015 13:58:15 +1000 (AEST)
Subject: Inter-op and port (wolfSSL + openSSH)
In-Reply-To: <CAMB3dQW206OH4Vmg3X4Zc174ZMuesMwveXxU7G7NTOzZMc1-Xg@mail.gmail.com>
References: <CAMB3dQW206OH4Vmg3X4Zc174ZMuesMwveXxU7G7NTOzZMc1-Xg@mail.gmail.com>
Message-ID: <alpine.BSO.2.20.1508301357510.19592@natsu.mindrot.org>

On Fri, 28 Aug 2015, Kaleb Himes wrote:

> To whom it may concern,
> 
> I work for a company wolfSSL .Inc. Over the summer some of our engineers
> have worked to build openSSH with wolfSSL instead of openSSL as we were
> tired of constant security issues needing patched due to openSSL
> compilation. As a result of the efforts made we would like to submit a
> patch that offers users an alternate configure option when configuring
> openSSH (--with-wolfssl). Similary in our libraries we now have the option
> "--with-openssh".
> 
> Could you please get this to the relevant individual(s). We have an altered
> version of openSSH we currently use and a README to go along which will
> make initial testing / integration easier.

Is WolfSSL open source? If so, what license it is under?

-d

From dtucker at zip.com.au  Sun Aug 30 17:06:56 2015
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 30 Aug 2015 17:06:56 +1000
Subject: Inter-op and port (wolfSSL + openSSH)
In-Reply-To: <alpine.BSO.2.20.1508301357510.19592@natsu.mindrot.org>
References: <CAMB3dQW206OH4Vmg3X4Zc174ZMuesMwveXxU7G7NTOzZMc1-Xg@mail.gmail.com>
 <alpine.BSO.2.20.1508301357510.19592@natsu.mindrot.org>
Message-ID: <CALDDTe0HHCRC6B3fzEJWvEp_dzrXGmtOcZ-F_vf_dZQfXVjnYg@mail.gmail.com>

On Aug 30, 2015 2:10 PM, "Damien Miller" <djm at mindrot.org> wrote:
> Is WolfSSL open source? If so, what license it is under?

https://wolfssl.com/wolfSSL/download/downloadForm.php says gplv2 and hints
at other proprietary options.  I lost interest when the download required
registration.

From bostjan at a2o.si  Sun Aug 30 20:57:25 2015
From: bostjan at a2o.si (Bostjan Skufca)
Date: Sun, 30 Aug 2015 12:57:25 +0200
Subject: Disabling host key checking on LAN
In-Reply-To: <CAOCN9ryKd1Evz135QNuwFmOQEYa6xOf5cN_TbCUNH59ff5asWA@mail.gmail.com>
References: <CAMBGa2Et0Q10g=dyCO3ZB8kUGyoQqZH-qsV0upC9_NtT3H4pYQ@mail.gmail.com>
 <CAEp_DRDnjwMb92Jsv3_1Lf79DdbBzACyZp7R3sxNLOv4XwhdaA@mail.gmail.com>
 <CAMBGa2Fe-ekZ3gLqie7KBbbDN-qcefSg3xV+=11DgaxambmT5w@mail.gmail.com>
 <CAEp_DRCvG7o-7w2ag2bsg4rWmX3hYNSxrzZifSP37Mxi+A0Pww@mail.gmail.com>
 <CAMBGa2E1OvCuje8aR1Gz5gv=bvVs1RWwG=xznQRop_iPY9pueg@mail.gmail.com>
 <CAMBGa2Ewb3j_H3tG6shVNk8xFiRiBMMPBqCD-rBLhL9vh7gGbQ@mail.gmail.com>
 <CAOCN9ryKd1Evz135QNuwFmOQEYa6xOf5cN_TbCUNH59ff5asWA@mail.gmail.com>
Message-ID: <CAEp_DRBJr7TAfvjW5tDHcGmWanCKM3OyQ6-UQDaoAFif-Y2FJg@mail.gmail.com>

Nico,

those were my thoughts, exacly, except that I was thinking about using "dig
+short HOST | ..." which has the cleanest output of all.

But there is that initial "if" in your email, which prevented me from
sending email in the first place. Using ping seems the most portable way,
albeit not very elegant.

b.


On 29 August 2015 at 12:25, Nico Kadel-Garcia <nkadel at gmail.com> wrote:

> On Fri, Aug 28, 2015 at 11:51 PM, Walter Carlson <wlcrls47 at gmail.com>
> wrote:
> > On Thu, Aug 27, 2015 at 12:26 AM, Walter Carlson <wlcrls47 at gmail.com>
> wrote:
> >
> >> Perfect, thanks.  This winds up working for me (as far as I've tested so
> >> far.)
> >>
> >> Match exec "ping -q -c 1 -t 1 %n | grep '192\.168\.'"
> >>    StrictHostKeyChecking no
> >>    UserKnownHostsFile none
> >>
> >
> > For the record, the last line has to be "UserKnownHostsFile /dev/null".
> I
> > saw "none" being used in others' openssh examples, but for me, that's
> using
> > the file ~/none rather than being interpreted as "don't use one".
>
> If you've installed the relevant "bind-utils" or similar DNS package,
> can't you ust use "host %n  | grep ' 192\.168\\." ? It's faster than
> running ping, especially for non-responsive hosts.
>

From zev at bewilderbeest.net  Mon Aug 31 02:08:42 2015
From: zev at bewilderbeest.net (Zev Weiss)
Date: Sun, 30 Aug 2015 11:08:42 -0500
Subject: Inter-op and port (wolfSSL + openSSH)
In-Reply-To: <CALDDTe0HHCRC6B3fzEJWvEp_dzrXGmtOcZ-F_vf_dZQfXVjnYg@mail.gmail.com>
References: <CAMB3dQW206OH4Vmg3X4Zc174ZMuesMwveXxU7G7NTOzZMc1-Xg@mail.gmail.com>
 <alpine.BSO.2.20.1508301357510.19592@natsu.mindrot.org>
 <CALDDTe0HHCRC6B3fzEJWvEp_dzrXGmtOcZ-F_vf_dZQfXVjnYg@mail.gmail.com>
Message-ID: <20150830160842.GB6818@hatter.bewilderbeest.net>

On Sun, Aug 30, 2015 at 05:06:56PM +1000, Darren Tucker wrote:
> I lost interest when the download required registration.

I initially had the same reaction, but then discovered that (though it's 
not at all obvious from looking at it) the "information" part of the 
form on that page is actually optional; you can just select the desired 
.zip, check the "I agree to the GPL" box (assuming you do), click 
"download" and it'll go right ahead and download.


Zev


From nkadel at gmail.com  Mon Aug 31 02:53:57 2015
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Sun, 30 Aug 2015 12:53:57 -0400
Subject: Disabling host key checking on LAN
In-Reply-To: <CAEp_DRBJr7TAfvjW5tDHcGmWanCKM3OyQ6-UQDaoAFif-Y2FJg@mail.gmail.com>
References: <CAMBGa2Et0Q10g=dyCO3ZB8kUGyoQqZH-qsV0upC9_NtT3H4pYQ@mail.gmail.com>
 <CAEp_DRDnjwMb92Jsv3_1Lf79DdbBzACyZp7R3sxNLOv4XwhdaA@mail.gmail.com>
 <CAMBGa2Fe-ekZ3gLqie7KBbbDN-qcefSg3xV+=11DgaxambmT5w@mail.gmail.com>
 <CAEp_DRCvG7o-7w2ag2bsg4rWmX3hYNSxrzZifSP37Mxi+A0Pww@mail.gmail.com>
 <CAMBGa2E1OvCuje8aR1Gz5gv=bvVs1RWwG=xznQRop_iPY9pueg@mail.gmail.com>
 <CAMBGa2Ewb3j_H3tG6shVNk8xFiRiBMMPBqCD-rBLhL9vh7gGbQ@mail.gmail.com>
 <CAOCN9ryKd1Evz135QNuwFmOQEYa6xOf5cN_TbCUNH59ff5asWA@mail.gmail.com>
 <CAEp_DRBJr7TAfvjW5tDHcGmWanCKM3OyQ6-UQDaoAFif-Y2FJg@mail.gmail.com>
Message-ID: <CAOCN9rxgg5r6ygk6nmFRZHOVJz0uSUG8aqXprppKmxabBENdBg@mail.gmail.com>

On Sun, Aug 30, 2015 at 6:57 AM, Bostjan Skufca <bostjan at a2o.si> wrote:
> Nico,
>
> those were my thoughts, exacly, except that I was thinking about using "dig
> +short HOST | ..." which has the cleanest output of all.

Excellent point. I like it! It can get a bit confusing with
round-robin DNS, which can give multiple responses.

> But there is that initial "if" in your email, which prevented me from
> sending email in the first place. Using ping seems the most portable way,
> albeit not very elegant.

And it does help deal with the round-robin, or /etc/hosts published
hostnames in a way that "dig" does not.

> On 29 August 2015 at 12:25, Nico Kadel-Garcia <nkadel at gmail.com> wrote:
>>
>> On Fri, Aug 28, 2015 at 11:51 PM, Walter Carlson <wlcrls47 at gmail.com>
>> wrote:
>> > On Thu, Aug 27, 2015 at 12:26 AM, Walter Carlson <wlcrls47 at gmail.com>
>> > wrote:
>> >
>> >> Perfect, thanks.  This winds up working for me (as far as I've tested
>> >> so
>> >> far.)
>> >>
>> >> Match exec "ping -q -c 1 -t 1 %n | grep '192\.168\.'"
>> >>    StrictHostKeyChecking no
>> >>    UserKnownHostsFile none
>> >>
>> >
>> > For the record, the last line has to be "UserKnownHostsFile /dev/null".
>> > I
>> > saw "none" being used in others' openssh examples, but for me, that's
>> > using
>> > the file ~/none rather than being interpreted as "don't use one".
>>
>> If you've installed the relevant "bind-utils" or similar DNS package,
>> can't you ust use "host %n  | grep ' 192\.168\\." ? It's faster than
>> running ping, especially for non-responsive hosts.
>
>

From bostjan at a2o.si  Mon Aug 31 23:02:21 2015
From: bostjan at a2o.si (Bostjan Skufca)
Date: Mon, 31 Aug 2015 15:02:21 +0200
Subject: Disabling host key checking on LAN
In-Reply-To: <CAOCN9rxgg5r6ygk6nmFRZHOVJz0uSUG8aqXprppKmxabBENdBg@mail.gmail.com>
References: <CAMBGa2Et0Q10g=dyCO3ZB8kUGyoQqZH-qsV0upC9_NtT3H4pYQ@mail.gmail.com>
 <CAEp_DRDnjwMb92Jsv3_1Lf79DdbBzACyZp7R3sxNLOv4XwhdaA@mail.gmail.com>
 <CAMBGa2Fe-ekZ3gLqie7KBbbDN-qcefSg3xV+=11DgaxambmT5w@mail.gmail.com>
 <CAEp_DRCvG7o-7w2ag2bsg4rWmX3hYNSxrzZifSP37Mxi+A0Pww@mail.gmail.com>
 <CAMBGa2E1OvCuje8aR1Gz5gv=bvVs1RWwG=xznQRop_iPY9pueg@mail.gmail.com>
 <CAMBGa2Ewb3j_H3tG6shVNk8xFiRiBMMPBqCD-rBLhL9vh7gGbQ@mail.gmail.com>
 <CAOCN9ryKd1Evz135QNuwFmOQEYa6xOf5cN_TbCUNH59ff5asWA@mail.gmail.com>
 <CAEp_DRBJr7TAfvjW5tDHcGmWanCKM3OyQ6-UQDaoAFif-Y2FJg@mail.gmail.com>
 <CAOCN9rxgg5r6ygk6nmFRZHOVJz0uSUG8aqXprppKmxabBENdBg@mail.gmail.com>
Message-ID: <CAEp_DRA21tiXxjdvUrnUWBG66HY75+zxrMgGWSwhm4t4uTFKEQ@mail.gmail.com>

On 30 August 2015 at 18:53, Nico Kadel-Garcia <nkadel at gmail.com> wrote:
>
> On Sun, Aug 30, 2015 at 6:57 AM, Bostjan Skufca <bostjan at a2o.si> wrote:
> > those were my thoughts, exacly, except that I was thinking about using "dig
> > +short HOST | ..." which has the cleanest output of all.
>
> It can get a bit confusing with
> round-robin DNS, which can give multiple responses.


Care to illustrate your use case?

I am having difficulties imagining it:
1. If you are managing particular host, you connect to its IP directly
(possibly via DNS entry).
2. If that DNS entry represents a service that has a load-balanced IP
list, you should not be connecting to arbitrary host in that list, but
use dedicated IP of particular server in that list, or am I missing
something here?

Additional point:
If your environment gets complicated enough, it probably justifies
usage of ProxyCommand directive with reference to dedicated
script/program that does the necessary plumbing (technical and
policy-wise) to set up your connection.

b.