From nkadel at gmail.com  Mon Sep  1 02:26:43 2014
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Sun, 31 Aug 2014 12:26:43 -0400
Subject: SSH completely locks up if you have a NOT PERFECT con
In-Reply-To: <540291BA.4060103@r.paypc.com>
References: <f32b010b771d43dfb3cd799910d4798b@hoi-polloi.org>
 <540291BA.4060103@r.paypc.com>
Message-ID: <CAOCN9rwnSESbmDs4o=D9V2nL3TXC_mrR3asg_XY3UK_gvWnmaQ@mail.gmail.com>

On Sat, Aug 30, 2014 at 11:08 PM, Robin <dovecot at r.paypc.com> wrote:

> Read the manuals, educate yourself about your kernel's TCP stack tuning
> knobs (if you can even get at those on your system), but don't shriek like a
> lunatic to every software project that inherits the limitations of
> underlying protocols and demand that they redress the accumulated
> shortcomings of decades of ad-hoc and often chaotic "progress" that have
> exposed the cracks in a 30+ year old networking specification.
>
> Not an SSH Bug, but a USER Bug.

Wherever the bug resides, the userland tools to ameliorate the problem
do exist in OpenSSH. They include, on the client side:

         ServerAliveCountMax
         ServerAliveInterval
         TCPKeepAlive

And on the server side:

         ClientAliveCountMax
         ClientAliveInterval
         TCPKeepAlive

In particular, on the server side, 'ClientAliveInterval is set to '0'
in many default setups. So the keepalives are not happening. And on
the client side, "ServerAliveInterval' only works for SSH 2. So
"Anonymous" might benefit a great deal from making sure that he uses
only SSH version 2, which he can enforce by setting 'Protocol 2' in
his personal $HOME/.ssh/config file.

So, while I personally think that Anonymous was being a ranting troll
in some ways, let's not say "it's all someone else's fault, we can't
fix that". Most users have little access to the TCP stack itself, and
some thought has gone into ways to reduce the problem for SSH users.
Let's point out the factors that might help, namely the now built-in
'Keep Alive' settings.

From jdvf at optonline.net  Tue Sep  2 00:04:20 2014
From: jdvf at optonline.net (John Devitofranceschi)
Date: Mon, 01 Sep 2014 10:04:20 -0400
Subject: Call for testing: OpenSSH 6.7
In-Reply-To: <alpine.BSO.2.11.1408181120070.414@natsu.mindrot.org>
References: <alpine.BSO.2.11.1408181120070.414@natsu.mindrot.org>
Message-ID: <742CF293-C512-4357-86CC-ED8FABD363DB@optonline.net>


On Aug 17, 2014, at 9:23 PM, Damien Miller <djm at mindrot.org> wrote:

> Hi,
> 
> OpenSSH 6.7 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This is a big release
> containing a number of features, a lot of internal refactoring and some
> potentially-incompatible changes.
> 
> Snapshot releases for portable OpenSSH are available from
> http://www.mindrot.org/openssh_snap/


All tests pass with openssh-SNAP-20140901 on Mac OS X Mavericks.

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

From doctor at doctor.nl2k.ab.ca  Tue Sep  2 01:02:59 2014
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Mon, 1 Sep 2014 09:02:59 -0600
Subject: Call for testing: OpenSSH 6.7
In-Reply-To: <742CF293-C512-4357-86CC-ED8FABD363DB@optonline.net>
References: <alpine.BSO.2.11.1408181120070.414@natsu.mindrot.org>
 <742CF293-C512-4357-86CC-ED8FABD363DB@optonline.net>
Message-ID: <20140901150259.GA21787@doctor.nl2k.ab.ca>

All right Looking good except that

on my system I have <poll.h> and <sys/poll.h>

and during configuration time they are not oicked up.

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
22 Sept 2014 New Brunswick save the province vote Liberal!

From djm at mindrot.org  Tue Sep  2 07:52:42 2014
From: djm at mindrot.org (Damien Miller)
Date: Tue, 2 Sep 2014 07:52:42 +1000 (EST)
Subject: Call for testing: OpenSSH 6.7
In-Reply-To: <20140901150259.GA21787@doctor.nl2k.ab.ca>
References: <alpine.BSO.2.11.1408181120070.414@natsu.mindrot.org>
 <742CF293-C512-4357-86CC-ED8FABD363DB@optonline.net>
 <20140901150259.GA21787@doctor.nl2k.ab.ca>
Message-ID: <alpine.BSO.2.11.1409020752010.5716@natsu.mindrot.org>

On Mon, 1 Sep 2014, The Doctor wrote:

> All right Looking good except that
> 
> on my system I have <poll.h> and <sys/poll.h>
> 
> and during configuration time they are not oicked up.

There should be some clues as to why in config.log - it might be that your
poll.h requires some prerequisitie header that is missing

-d

From doctor at doctor.nl2k.ab.ca  Tue Sep  2 10:43:31 2014
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Mon, 1 Sep 2014 18:43:31 -0600
Subject: Call for testing: OpenSSH 6.7
In-Reply-To: <alpine.BSO.2.11.1409020752010.5716@natsu.mindrot.org>
References: <alpine.BSO.2.11.1408181120070.414@natsu.mindrot.org>
 <742CF293-C512-4357-86CC-ED8FABD363DB@optonline.net>
 <20140901150259.GA21787@doctor.nl2k.ab.ca>
 <alpine.BSO.2.11.1409020752010.5716@natsu.mindrot.org>
Message-ID: <20140902004328.GA21459@doctor.nl2k.ab.ca>

On Tue, Sep 02, 2014 at 07:52:42AM +1000, Damien Miller wrote:
> On Mon, 1 Sep 2014, The Doctor wrote:
> 
> > All right Looking good except that
> > 
> > on my system I have <poll.h> and <sys/poll.h>
> > 
> > and during configuration time they are not oicked up.
> 
> There should be some clues as to why in config.log - it might be that your
> poll.h requires some prerequisitie header that is missing
> 
> -d


All right here is my poll.h
---

/*-
 * Copyright (c) 1997 Peter Wemm <peter at freebsd.org>
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 * 3. The name of the author may not be used to endorse or promote products
 *    derived from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 *
 * $FreeBSD: src/sys/sys/poll.h,v 1.13.34.1 2009/04/15 03:14:26 kensmith Exp $
 */

#ifndef _SYS_POLL_H_
#define	_SYS_POLL_H_

#include <sys/cdefs.h>

/*
 * This file is intended to be compatible with the traditional poll.h.
 */

typedef	unsigned int	nfds_t;

/*
 * This structure is passed as an array to poll(2).
 */
struct pollfd {
	int	fd;		/* which file descriptor to poll */
	short	events;		/* events we are interested in */
	short	revents;	/* events found on return */
};

/*
 * Requestable events.  If poll(2) finds any of these set, they are
 * copied to revents on return.
 * XXX Note that FreeBSD doesn't make much distinction between POLLPRI
 * and POLLRDBAND since none of the file types have distinct priority
 * bands - and only some have an urgent "mode".
 * XXX Note POLLIN isn't really supported in true SVSV terms.  Under SYSV
 * POLLIN includes all of normal, band and urgent data.  Most poll handlers
 * on FreeBSD only treat it as "normal" data.
 */
#define	POLLIN		0x0001		/* any readable data available */
#define	POLLPRI		0x0002		/* OOB/Urgent readable data */
#define	POLLOUT		0x0004		/* file descriptor is writeable */
#define	POLLRDNORM	0x0040		/* non-OOB/URG data available */
#define	POLLWRNORM	POLLOUT		/* no write type differentiation */
#define	POLLRDBAND	0x0080		/* OOB/Urgent readable data */
#define	POLLWRBAND	0x0100		/* OOB/Urgent data can be written */

#if __BSD_VISIBLE
/* General FreeBSD extension (currently only supported for sockets): */
#define	POLLINIGNEOF	0x2000		/* like POLLIN, except ignore EOF */
#endif

/*
 * These events are set if they occur regardless of whether they were
 * requested.
 */
#define	POLLERR		0x0008		/* some poll error occurred */
#define	POLLHUP		0x0010		/* file descriptor was "hung up" */
#define	POLLNVAL	0x0020		/* requested events "invalid" */

#if __BSD_VISIBLE

#define	POLLSTANDARD	(POLLIN|POLLPRI|POLLOUT|POLLRDNORM|POLLRDBAND|\
			 POLLWRBAND|POLLERR|POLLHUP|POLLNVAL)

/*
 * Request that poll() wait forever.
 * XXX in SYSV, this is defined in stropts.h, which is not included
 * by poll.h.
 */
#define	INFTIM		(-1)

#endif

#ifndef _KERNEL 

__BEGIN_DECLS
int	poll(struct pollfd _pfd[], nfds_t _nfds, int _timeout);
__END_DECLS

#endif /* !_KERNEL */

#endif /* !_SYS_POLL_H_ */

---

and my <sys/poll.h>

---

/*-
 * Copyright (c) 1997 Peter Wemm <peter at freebsd.org>
 * All rights reserved.
 *
 * Redistribution and use in source and binary forms, with or without
 * modification, are permitted provided that the following conditions
 * are met:
 * 1. Redistributions of source code must retain the above copyright
 *    notice, this list of conditions and the following disclaimer.
 * 2. Redistributions in binary form must reproduce the above copyright
 *    notice, this list of conditions and the following disclaimer in the
 *    documentation and/or other materials provided with the distribution.
 * 3. The name of the author may not be used to endorse or promote products
 *    derived from this software without specific prior written permission.
 *
 * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
 * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
 * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
 * ARE DISCLAIMED.  IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
 * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
 * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
 * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
 * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
 * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
 * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
 * SUCH DAMAGE.
 *
 * $FreeBSD: src/sys/sys/poll.h,v 1.13.34.1 2009/04/15 03:14:26 kensmith Exp $
 */

#ifndef _SYS_POLL_H_
#define	_SYS_POLL_H_

#include <sys/cdefs.h>

/*
 * This file is intended to be compatible with the traditional poll.h.
 */

typedef	unsigned int	nfds_t;

/*
 * This structure is passed as an array to poll(2).
 */
struct pollfd {
	int	fd;		/* which file descriptor to poll */
	short	events;		/* events we are interested in */
	short	revents;	/* events found on return */
};

/*
 * Requestable events.  If poll(2) finds any of these set, they are
 * copied to revents on return.
 * XXX Note that FreeBSD doesn't make much distinction between POLLPRI
 * and POLLRDBAND since none of the file types have distinct priority
 * bands - and only some have an urgent "mode".
 * XXX Note POLLIN isn't really supported in true SVSV terms.  Under SYSV
 * POLLIN includes all of normal, band and urgent data.  Most poll handlers
 * on FreeBSD only treat it as "normal" data.
 */
#define	POLLIN		0x0001		/* any readable data available */
#define	POLLPRI		0x0002		/* OOB/Urgent readable data */
#define	POLLOUT		0x0004		/* file descriptor is writeable */
#define	POLLRDNORM	0x0040		/* non-OOB/URG data available */
#define	POLLWRNORM	POLLOUT		/* no write type differentiation */
#define	POLLRDBAND	0x0080		/* OOB/Urgent readable data */
#define	POLLWRBAND	0x0100		/* OOB/Urgent data can be written */

#if __BSD_VISIBLE
/* General FreeBSD extension (currently only supported for sockets): */
#define	POLLINIGNEOF	0x2000		/* like POLLIN, except ignore EOF */
#endif

/*
 * These events are set if they occur regardless of whether they were
 * requested.
 */
#define	POLLERR		0x0008		/* some poll error occurred */
#define	POLLHUP		0x0010		/* file descriptor was "hung up" */
#define	POLLNVAL	0x0020		/* requested events "invalid" */

#if __BSD_VISIBLE

#define	POLLSTANDARD	(POLLIN|POLLPRI|POLLOUT|POLLRDNORM|POLLRDBAND|\
			 POLLWRBAND|POLLERR|POLLHUP|POLLNVAL)

/*
 * Request that poll() wait forever.
 * XXX in SYSV, this is defined in stropts.h, which is not included
 * by poll.h.
 */
#define	INFTIM		(-1)

#endif

#ifndef _KERNEL

__BEGIN_DECLS
int	poll(struct pollfd _pfd[], nfds_t _nfds, int _timeout);
__END_DECLS

#endif /* !_KERNEL */

#endif /* !_SYS_POLL_H_ */

---
-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
22 Sept 2014 New Brunswick save the province vote Liberal!

From djm at mindrot.org  Tue Sep  2 13:23:29 2014
From: djm at mindrot.org (Damien Miller)
Date: Tue, 2 Sep 2014 13:23:29 +1000 (EST)
Subject: Call for testing: OpenSSH 6.7
In-Reply-To: <20140902004328.GA21459@doctor.nl2k.ab.ca>
References: <alpine.BSO.2.11.1408181120070.414@natsu.mindrot.org>
 <742CF293-C512-4357-86CC-ED8FABD363DB@optonline.net>
 <20140901150259.GA21787@doctor.nl2k.ab.ca>
 <alpine.BSO.2.11.1409020752010.5716@natsu.mindrot.org>
 <20140902004328.GA21459@doctor.nl2k.ab.ca>
Message-ID: <alpine.BSO.2.11.1409021321160.31726@natsu.mindrot.org>

On Mon, 1 Sep 2014, The Doctor wrote:

> > There should be some clues as to why in config.log - it might be
> > that your poll.h requires some prerequisitie header that is missing
>
> All right here is my poll.h

The contents look okay. but they aren't so helpful for figuring out what
is going wrong as error messages reported in config.log when configure
was searching for it. Could you take a look in there?

-d

From doctor at doctor.nl2k.ab.ca  Tue Sep  2 13:47:03 2014
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Mon, 1 Sep 2014 21:47:03 -0600
Subject: Call for testing: OpenSSH 6.7
In-Reply-To: <alpine.BSO.2.11.1409021321160.31726@natsu.mindrot.org>
References: <alpine.BSO.2.11.1408181120070.414@natsu.mindrot.org>
 <742CF293-C512-4357-86CC-ED8FABD363DB@optonline.net>
 <20140901150259.GA21787@doctor.nl2k.ab.ca>
 <alpine.BSO.2.11.1409020752010.5716@natsu.mindrot.org>
 <20140902004328.GA21459@doctor.nl2k.ab.ca>
 <alpine.BSO.2.11.1409021321160.31726@natsu.mindrot.org>
Message-ID: <20140902034700.GA19746@doctor.nl2k.ab.ca>

On Tue, Sep 02, 2014 at 01:23:29PM +1000, Damien Miller wrote:
> On Mon, 1 Sep 2014, The Doctor wrote:
> 
> > > There should be some clues as to why in config.log - it might be
> > > that your poll.h requires some prerequisitie header that is missing
> >
> > All right here is my poll.h
> 
> The contents look okay. but they aren't so helpful for figuring out what
> is going wrong as error messages reported in config.log when configure
> was searching for it. Could you take a look in there?
>

egrep poll /usr/source/openssh-SNAP-20140902/config.log
configure:6636: checking poll.h usability
configure:6636: checking poll.h presence
configure:6636: checking for poll.h
configure:6636: checking sys/poll.h usability
configure:6636: checking sys/poll.h presence
configure:6636: checking for sys/poll.h
configure:10378: checking for poll
/usr/source/openssh-SNAP-20140902/conftest.c:130: undefined reference to `poll'
| /* Define poll to an innocuous variant, in case <limits.h> declares poll.
| #define poll innocuous_poll
|     which can conflict with char poll (); below.
| #undef poll
| char poll ();
| #if defined __stub_poll || defined __stub___poll
| return poll ();
ac_cv_func_poll=no
ac_cv_header_poll_h=yes
ac_cv_header_sys_poll_h=yes  
 
> -d
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
22 Sept 2014 New Brunswick save the province vote Liberal!

From vinschen at redhat.com  Tue Sep  2 21:49:49 2014
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 2 Sep 2014 13:49:49 +0200
Subject: Call for testing: OpenSSH 6.7
In-Reply-To: <alpine.BSO.2.11.1408181120070.414@natsu.mindrot.org>
References: <alpine.BSO.2.11.1408181120070.414@natsu.mindrot.org>
Message-ID: <20140902114949.GB6056@calimero.vinschen.de>

On Aug 18 11:23, Damien Miller wrote:
> Hi,
> 
> OpenSSH 6.7 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This is a big release
> containing a number of features, a lot of internal refactoring and some
> potentially-incompatible changes.

Btw., I'm getting two new warnings during build:

gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -Wsizeof-pointer-memaccess -Wno-pointer-sign -Wno-unused-result -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset -fstack-protector-all -Wno-attributes  -I. -I../src  -I/usr/include/editline    -DSSHDIR=\"/etc\" -D_PATH_SSH_PROGRAM=\"/usr/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/sbin/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/usr/sbin/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/usr/sbin/ssh-keysign\" -D_PATH_SSH_PKCS11_HELPER=\"/usr/sbin/ssh-pkcs11-helper\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DHAVE_CONFIG_H -c ../src/sshbuf.c -o sshbuf.o
../src/sshbuf.c:34:0: warning: "__predict_true" redefined [enabled by default]
 #define __predict_true(exp)     __builtin_expect(((exp) != 0), 1)
 ^
In file included from /usr/include/features.h:14:0,
                 from /usr/include/sys/socket.h:15,
                 from ../src/includes.h:26,
                 from ../src/sshbuf.c:19:
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/include-fixed/sys/cdefs.h:445:0: note: this is the location of the previous definition
 #define __predict_true(exp)     __builtin_expect((exp), 1)
 ^
../src/sshbuf.c:35:0: warning: "__predict_false" redefined [enabled by default]
 #define __predict_false(exp)    __builtin_expect(((exp) != 0), 0)
 ^
In file included from /usr/include/features.h:14:0,
                 from /usr/include/sys/socket.h:15,
                 from ../src/includes.h:26,
                 from ../src/sshbuf.c:19:
/usr/lib/gcc/x86_64-pc-cygwin/4.8.3/include-fixed/sys/cdefs.h:446:0: note: this is the location of the previous definition
 #define __predict_false(exp)    __builtin_expect((exp), 0)
 ^

Shouldn't these be avoided by only defining them if they are not already
defined?


Corinna

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

From vinschen at redhat.com  Tue Sep  2 21:50:53 2014
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 2 Sep 2014 13:50:53 +0200
Subject: [patch/cygwin]: Remove setting extra permissions on system
 directories
In-Reply-To: <20140829213610.GA6202@calimero.vinschen.de>
References: <20140829212507.GA5854@calimero.vinschen.de>
 <20140829213610.GA6202@calimero.vinschen.de>
Message-ID: <20140902115053.GC6056@calimero.vinschen.de>

Ping?

On Aug 29 23:36, Corinna Vinschen wrote:
> On Aug 29 23:25, Corinna Vinschen wrote:
> > Hi,
> > 
> > please consider the below patch for OpenSSH 6.7.  A fix in POSIX ACL
> > handling in Cygwin turned up this rather old code in the ssh-host-config
> > script.  It opens the permissions for some directories, especially
> > /var/empty, for the "system" user for no good reason.
> > 
> > This results in sshd refusing to start because the permissions on
> > /var/empty are too open.
> > 
> > The below patch fixes that by dropping the code adding an ACL entry
> > for the "system" user.
> 
> Actually, please disregard the previous patch and use the below one.
> The script really shows its age.  It tries to create directories which
> for a long time now have been installed with correct permissions by the
> base installation already.
> 
> The only directory the script really has to care for is /var/empty.
> 
> New patch below.
> 
> 
> Thanks,
> Corinna
> 
> 
> Index: contrib/cygwin/ssh-host-config
> ===================================================================
> RCS file: /cvs/openssh/contrib/cygwin/ssh-host-config,v
> retrieving revision 1.35
> diff -u -p -r1.35 ssh-host-config
> --- contrib/cygwin/ssh-host-config	27 May 2014 04:31:59 -0000	1.35
> +++ contrib/cygwin/ssh-host-config	29 Aug 2014 21:34:00 -0000
> @@ -37,7 +37,6 @@ declare -a csih_required_commands=(
>    /usr/bin/mkpasswd cygwin
>    /usr/bin/mount cygwin
>    /usr/bin/ps cygwin
> -  /usr/bin/setfacl cygwin
>    /usr/bin/umount cygwin
>    /usr/bin/cmp diffutils
>    /usr/bin/grep grep
> @@ -651,32 +650,6 @@ echo
>  
>  warning_cnt=0
>  
> -# Check for ${SYSCONFDIR} directory
> -csih_make_dir "${SYSCONFDIR}" "Cannot create global configuration files."
> -if ! /usr/bin/chmod 775 "${SYSCONFDIR}" >/dev/null 2>&1
> -then
> -  csih_warning "Can't set permissions on ${SYSCONFDIR}!"
> -  let ++warning_cnt
> -fi
> -if ! /usr/bin/setfacl -m u:system:rwx "${SYSCONFDIR}" >/dev/null 2>&1
> -then
> -  csih_warning "Can't set extended permissions on ${SYSCONFDIR}!"
> -  let ++warning_cnt
> -fi
> -
> -# Check for /var/log directory
> -csih_make_dir "${LOCALSTATEDIR}/log" "Cannot create log directory."
> -if ! /usr/bin/chmod 775 "${LOCALSTATEDIR}/log" >/dev/null 2>&1
> -then
> -  csih_warning "Can't set permissions on ${LOCALSTATEDIR}/log!"
> -  let ++warning_cnt
> -fi
> -if ! /usr/bin/setfacl -m u:system:rwx "${LOCALSTATEDIR}/log" >/dev/null 2>&1
> -then
> -  csih_warning "Can't set extended permissions on ${LOCALSTATEDIR}/log!"
> -  let ++warning_cnt
> -fi
> -
>  # Create /var/log/lastlog if not already exists
>  if [ -e ${LOCALSTATEDIR}/log/lastlog -a ! -f ${LOCALSTATEDIR}/log/lastlog ]
>  then
> @@ -699,11 +672,6 @@ csih_make_dir "${LOCALSTATEDIR}/empty" "
>  if ! /usr/bin/chmod 755 "${LOCALSTATEDIR}/empty" >/dev/null 2>&1
>  then
>    csih_warning "Can't set permissions on ${LOCALSTATEDIR}/empty!"
> -  let ++warning_cnt
> -fi
> -if ! /usr/bin/setfacl -m u:system:rwx "${LOCALSTATEDIR}/empty" >/dev/null 2>&1
> -then
> -  csih_warning "Can't set extended permissions on ${LOCALSTATEDIR}/empty!"
>    let ++warning_cnt
>  fi

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

From djm at mindrot.org  Wed Sep  3 05:15:35 2014
From: djm at mindrot.org (Damien Miller)
Date: Wed, 3 Sep 2014 05:15:35 +1000 (EST)
Subject: Call for testing: OpenSSH 6.7
In-Reply-To: <20140902034700.GA19746@doctor.nl2k.ab.ca>
References: <alpine.BSO.2.11.1408181120070.414@natsu.mindrot.org>
 <742CF293-C512-4357-86CC-ED8FABD363DB@optonline.net>
 <20140901150259.GA21787@doctor.nl2k.ab.ca>
 <alpine.BSO.2.11.1409020752010.5716@natsu.mindrot.org>
 <20140902004328.GA21459@doctor.nl2k.ab.ca>
 <alpine.BSO.2.11.1409021321160.31726@natsu.mindrot.org>
 <20140902034700.GA19746@doctor.nl2k.ab.ca>
Message-ID: <alpine.BSO.2.11.1409030513550.10553@natsu.mindrot.org>

On Mon, 1 Sep 2014, The Doctor wrote:

> On Tue, Sep 02, 2014 at 01:23:29PM +1000, Damien Miller wrote:
> > On Mon, 1 Sep 2014, The Doctor wrote:
> > 
> > > > There should be some clues as to why in config.log - it might be
> > > > that your poll.h requires some prerequisitie header that is missing
> > >
> > > All right here is my poll.h
> > 
> > The contents look okay. but they aren't so helpful for figuring out what
> > is going wrong as error messages reported in config.log when configure
> > was searching for it. Could you take a look in there?
> >
> 
> egrep poll /usr/source/openssh-SNAP-20140902/config.log

grepping for poll will only show lines that contain poll and misses anything
nearby. Could you please include the first few lines following each occurance
of 'poll.h' - you'll probably find some error message there.

From djm at mindrot.org  Wed Sep  3 05:27:26 2014
From: djm at mindrot.org (Damien Miller)
Date: Wed, 3 Sep 2014 05:27:26 +1000 (EST)
Subject: Call for testing: OpenSSH 6.7
In-Reply-To: <20140902114949.GB6056@calimero.vinschen.de>
References: <alpine.BSO.2.11.1408181120070.414@natsu.mindrot.org>
 <20140902114949.GB6056@calimero.vinschen.de>
Message-ID: <alpine.BSO.2.11.1409030526180.10553@natsu.mindrot.org>

On Tue, 2 Sep 2014, Corinna Vinschen wrote:

> On Aug 18 11:23, Damien Miller wrote:
> > Hi,
> > 
> > OpenSSH 6.7 is almost ready for release, so we would appreciate testing
> > on as many platforms and systems as possible. This is a big release
> > containing a number of features, a lot of internal refactoring and some
> > potentially-incompatible changes.
> 
> Btw., I'm getting two new warnings during build:

This should fix it

Index: defines.h
===================================================================
RCS file: /var/cvs/openssh/defines.h,v
retrieving revision 1.182
diff -u -p -r1.182 defines.h
--- defines.h	16 Jun 2014 12:50:56 -0000	1.182
+++ defines.h	2 Sep 2014 19:27:06 -0000
@@ -830,4 +830,15 @@ struct winsize {
 # endif
 #endif
 
+#ifndef __predict_true
+# if defined(__GNUC__) && \
+     ((__GNUC__ > (2)) || (__GNUC__ == (2) && __GNUC_MINOR__ >= (96)))
+#  define __predict_true(exp)     __builtin_expect(((exp) != 0), 1)
+#  define __predict_false(exp)    __builtin_expect(((exp) != 0), 0)
+# else
+#  define __predict_true(exp)     ((exp) != 0)
+#  define __predict_false(exp)    ((exp) != 0)
+# endif /* gcc version */
+#endif /* __predict_true */
+
 #endif /* _DEFINES_H */
Index: sshbuf.c
===================================================================
RCS file: /var/cvs/openssh/sshbuf.c,v
retrieving revision 1.4
diff -u -p -r1.4 sshbuf.c
--- sshbuf.c	2 Jul 2014 05:29:22 -0000	1.4
+++ sshbuf.c	2 Sep 2014 19:27:06 -0000
@@ -28,16 +28,6 @@
 #include "ssherr.h"
 #include "sshbuf.h"
 
-/* XXX move to defines.h? */
-#if defined(__GNUC__) && \
-    ((__GNUC__ > (2)) || (__GNUC__ == (2) && __GNUC_MINOR__ >= (96)))
-#define __predict_true(exp)     __builtin_expect(((exp) != 0), 1)
-#define __predict_false(exp)    __builtin_expect(((exp) != 0), 0)
-#else
-#define __predict_true(exp)     ((exp) != 0)
-#define __predict_false(exp)    ((exp) != 0)
-#endif
-
 static inline int
 sshbuf_check_sanity(const struct sshbuf *buf)
 {



From djm at mindrot.org  Wed Sep  3 05:35:45 2014
From: djm at mindrot.org (Damien Miller)
Date: Wed, 3 Sep 2014 05:35:45 +1000 (EST)
Subject: [patch/cygwin]: Remove setting extra permissions on system
 directories
In-Reply-To: <20140829213610.GA6202@calimero.vinschen.de>
References: <20140829212507.GA5854@calimero.vinschen.de>
 <20140829213610.GA6202@calimero.vinschen.de>
Message-ID: <alpine.BSO.2.11.1409030535400.10553@natsu.mindrot.org>

applied - thanks

On Fri, 29 Aug 2014, Corinna Vinschen wrote:

> On Aug 29 23:25, Corinna Vinschen wrote:
> > Hi,
> > 
> > please consider the below patch for OpenSSH 6.7.  A fix in POSIX ACL
> > handling in Cygwin turned up this rather old code in the ssh-host-config
> > script.  It opens the permissions for some directories, especially
> > /var/empty, for the "system" user for no good reason.
> > 
> > This results in sshd refusing to start because the permissions on
> > /var/empty are too open.
> > 
> > The below patch fixes that by dropping the code adding an ACL entry
> > for the "system" user.
> 
> Actually, please disregard the previous patch and use the below one.
> The script really shows its age.  It tries to create directories which
> for a long time now have been installed with correct permissions by the
> base installation already.
> 
> The only directory the script really has to care for is /var/empty.
> 
> New patch below.
> 
> 
> Thanks,
> Corinna
> 
> 
> Index: contrib/cygwin/ssh-host-config
> ===================================================================
> RCS file: /cvs/openssh/contrib/cygwin/ssh-host-config,v
> retrieving revision 1.35
> diff -u -p -r1.35 ssh-host-config
> --- contrib/cygwin/ssh-host-config	27 May 2014 04:31:59 -0000	1.35
> +++ contrib/cygwin/ssh-host-config	29 Aug 2014 21:34:00 -0000
> @@ -37,7 +37,6 @@ declare -a csih_required_commands=(
>    /usr/bin/mkpasswd cygwin
>    /usr/bin/mount cygwin
>    /usr/bin/ps cygwin
> -  /usr/bin/setfacl cygwin
>    /usr/bin/umount cygwin
>    /usr/bin/cmp diffutils
>    /usr/bin/grep grep
> @@ -651,32 +650,6 @@ echo
>  
>  warning_cnt=0
>  
> -# Check for ${SYSCONFDIR} directory
> -csih_make_dir "${SYSCONFDIR}" "Cannot create global configuration files."
> -if ! /usr/bin/chmod 775 "${SYSCONFDIR}" >/dev/null 2>&1
> -then
> -  csih_warning "Can't set permissions on ${SYSCONFDIR}!"
> -  let ++warning_cnt
> -fi
> -if ! /usr/bin/setfacl -m u:system:rwx "${SYSCONFDIR}" >/dev/null 2>&1
> -then
> -  csih_warning "Can't set extended permissions on ${SYSCONFDIR}!"
> -  let ++warning_cnt
> -fi
> -
> -# Check for /var/log directory
> -csih_make_dir "${LOCALSTATEDIR}/log" "Cannot create log directory."
> -if ! /usr/bin/chmod 775 "${LOCALSTATEDIR}/log" >/dev/null 2>&1
> -then
> -  csih_warning "Can't set permissions on ${LOCALSTATEDIR}/log!"
> -  let ++warning_cnt
> -fi
> -if ! /usr/bin/setfacl -m u:system:rwx "${LOCALSTATEDIR}/log" >/dev/null 2>&1
> -then
> -  csih_warning "Can't set extended permissions on ${LOCALSTATEDIR}/log!"
> -  let ++warning_cnt
> -fi
> -
>  # Create /var/log/lastlog if not already exists
>  if [ -e ${LOCALSTATEDIR}/log/lastlog -a ! -f ${LOCALSTATEDIR}/log/lastlog ]
>  then
> @@ -699,11 +672,6 @@ csih_make_dir "${LOCALSTATEDIR}/empty" "
>  if ! /usr/bin/chmod 755 "${LOCALSTATEDIR}/empty" >/dev/null 2>&1
>  then
>    csih_warning "Can't set permissions on ${LOCALSTATEDIR}/empty!"
> -  let ++warning_cnt
> -fi
> -if ! /usr/bin/setfacl -m u:system:rwx "${LOCALSTATEDIR}/empty" >/dev/null 2>&1
> -then
> -  csih_warning "Can't set extended permissions on ${LOCALSTATEDIR}/empty!"
>    let ++warning_cnt
>  fi
>  
> -- 
> Corinna Vinschen
> Cygwin Maintainer
> Red Hat
> 

From vinschen at redhat.com  Wed Sep  3 06:10:46 2014
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 2 Sep 2014 22:10:46 +0200
Subject: Call for testing: OpenSSH 6.7
In-Reply-To: <alpine.BSO.2.11.1409030526180.10553@natsu.mindrot.org>
References: <alpine.BSO.2.11.1408181120070.414@natsu.mindrot.org>
 <20140902114949.GB6056@calimero.vinschen.de>
 <alpine.BSO.2.11.1409030526180.10553@natsu.mindrot.org>
Message-ID: <20140902201046.GA18049@calimero.vinschen.de>

On Sep  3 05:27, Damien Miller wrote:
> On Tue, 2 Sep 2014, Corinna Vinschen wrote:
> 
> > On Aug 18 11:23, Damien Miller wrote:
> > > Hi,
> > > 
> > > OpenSSH 6.7 is almost ready for release, so we would appreciate testing
> > > on as many platforms and systems as possible. This is a big release
> > > containing a number of features, a lot of internal refactoring and some
> > > potentially-incompatible changes.
> > 
> > Btw., I'm getting two new warnings during build:
> 
> This should fix it

It does.  Thanks.


Corinna

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

From vinschen at redhat.com  Wed Sep  3 06:11:15 2014
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 2 Sep 2014 22:11:15 +0200
Subject: [patch/cygwin]: Remove setting extra permissions on system
 directories
In-Reply-To: <alpine.BSO.2.11.1409030535400.10553@natsu.mindrot.org>
References: <20140829212507.GA5854@calimero.vinschen.de>
 <20140829213610.GA6202@calimero.vinschen.de>
 <alpine.BSO.2.11.1409030535400.10553@natsu.mindrot.org>
Message-ID: <20140902201115.GB18049@calimero.vinschen.de>

On Sep  3 05:35, Damien Miller wrote:
> applied - thanks

Thank you.


Corinna

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

From aidan.feldman at gmail.com  Wed Sep  3 08:52:21 2014
From: aidan.feldman at gmail.com (Aidan Feldman)
Date: Tue, 2 Sep 2014 18:52:21 -0400
Subject: making the passphrase prompt more clear
Message-ID: <CAPgiXS5D4J4MaPLSCQ3CgAe40mC+mjWpdfTAE2CUvR3hiypfmQ@mail.gmail.com>

I am going to preface this email by saying that I know very little
about OpenSSH internals, the protocol, etc.

I do a lot of work with novice programmers, and one step that comes up
relatively early is generating SSH keys.  In case you haven't done it
in a while, the output looks like this:

$ ssh-keygen -t rsa
Generating public/private rsa key pair.
Enter file in which to save the key (/Users/aidan/.ssh/id_rsa):
Enter passphrase (empty for no passphrase):

When that last step comes up, I am regularly asked, "Does it mean the
system password, or a new one?"  A slight tweak of the language could
easily eliminate that confusion... something like "Enter passphrase
for the new key" or "Enter new passphrase".

I would happily submit the patch myself if it wouldn't take a few
hours for me to figure out how to do so :-)  Thanks!

From lists at eitanadler.com  Wed Sep  3 09:11:52 2014
From: lists at eitanadler.com (Eitan Adler)
Date: Tue, 2 Sep 2014 16:11:52 -0700
Subject: making the passphrase prompt more clear
In-Reply-To: <CAPgiXS5D4J4MaPLSCQ3CgAe40mC+mjWpdfTAE2CUvR3hiypfmQ@mail.gmail.com>
References: <CAPgiXS5D4J4MaPLSCQ3CgAe40mC+mjWpdfTAE2CUvR3hiypfmQ@mail.gmail.com>
Message-ID: <CAF6rxgkmvnBeZYZu9sw_xaKBBaLKXUb5qJCOcp4aVaR1mRsnxw@mail.gmail.com>

On 2 September 2014 15:52, Aidan Feldman <aidan.feldman at gmail.com> wrote:
> I am going to preface this email by saying that I know very little
> about OpenSSH internals, the protocol, etc.
>
> I do a lot of work with novice programmers, and one step that comes up
> relatively early is generating SSH keys.  In case you haven't done it
> in a while, the output looks like this:
>
> $ ssh-keygen -t rsa
> Generating public/private rsa key pair.
> Enter file in which to save the key (/Users/aidan/.ssh/id_rsa):
> Enter passphrase (empty for no passphrase):
>
> When that last step comes up, I am regularly asked, "Does it mean the
> system password, or a new one?"  A slight tweak of the language could
> easily eliminate that confusion... something like "Enter passphrase
> for the new key" or "Enter new passphrase".

Perhaps "Enter new passphrase to encrypt the key (empty for no encryption):"

This makes it clear that it needs to be a new phrase, and what it will
be used for.

-- 
Eitan Adler

From mancha1 at zoho.com  Wed Sep  3 10:00:18 2014
From: mancha1 at zoho.com (mancha)
Date: Wed, 3 Sep 2014 00:00:18 +0000
Subject: making the passphrase prompt more clear
In-Reply-To: <CAF6rxgkmvnBeZYZu9sw_xaKBBaLKXUb5qJCOcp4aVaR1mRsnxw@mail.gmail.com>
References: <CAPgiXS5D4J4MaPLSCQ3CgAe40mC+mjWpdfTAE2CUvR3hiypfmQ@mail.gmail.com>
 <CAF6rxgkmvnBeZYZu9sw_xaKBBaLKXUb5qJCOcp4aVaR1mRsnxw@mail.gmail.com>
Message-ID: <20140903000018.GB30848@zoho.com>

On Tue, Sep 02, 2014 at 04:11:52PM -0700, Eitan Adler wrote:
> On 2 September 2014 15:52, Aidan Feldman <aidan.feldman at gmail.com>
> wrote:
> > I am going to preface this email by saying that I know very little
> > about OpenSSH internals, the protocol, etc.
> >
> > I do a lot of work with novice programmers, and one step that comes
> > up relatively early is generating SSH keys.  In case you haven't
> > done it in a while, the output looks like this:
> >
> > $ ssh-keygen -t rsa Generating public/private rsa key pair.  Enter
> > file in which to save the key (/Users/aidan/.ssh/id_rsa): Enter
> > passphrase (empty for no passphrase):
> >
> > When that last step comes up, I am regularly asked, "Does it mean
> > the system password, or a new one?"  A slight tweak of the language
> > could easily eliminate that confusion... something like "Enter
> > passphrase for the new key" or "Enter new passphrase".
> 
> Perhaps "Enter new passphrase to encrypt the key (empty for no
> encryption):"
> 
> This makes it clear that it needs to be a new phrase, and what it will
> be used for.

You might also consider helping your users get into the good habit of
reading documentation.

Not all software suites have good docs but OpenSSH does a pretty job of
it.

Take for example this excerpt from the ssh-keygen manpage:

  "The program also asks for a passphrase. The passphrase may be empty
   to indicate no passphrase (host keys must have an empty passphrase),
   or it may be a string of arbitrary length. A passphrase is similar
   to a password, except it can be a phrase with a series of words,
   punctuation, numbers..."

--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/20140903/3010552c/attachment.bin>

From lists at eitanadler.com  Wed Sep  3 13:25:29 2014
From: lists at eitanadler.com (Eitan Adler)
Date: Tue, 2 Sep 2014 20:25:29 -0700
Subject: making the passphrase prompt more clear
In-Reply-To: <20140903000018.GB30848@zoho.com>
References: <CAPgiXS5D4J4MaPLSCQ3CgAe40mC+mjWpdfTAE2CUvR3hiypfmQ@mail.gmail.com>
 <CAF6rxgkmvnBeZYZu9sw_xaKBBaLKXUb5qJCOcp4aVaR1mRsnxw@mail.gmail.com>
 <20140903000018.GB30848@zoho.com>
Message-ID: <CAF6rxg=y58BimYtrikBd+vnB+Wm0y6n8upB7c4MjAyNxy5fxCw@mail.gmail.com>

On 2 September 2014 17:00, mancha <mancha1 at zoho.com> wrote:
> On Tue, Sep 02, 2014 at 04:11:52PM -0700, Eitan Adler wrote:
>> On 2 September 2014 15:52, Aidan Feldman <aidan.feldman at gmail.com>
>> wrote:
>> > I am going to preface this email by saying that I know very little
>> > about OpenSSH internals, the protocol, etc.
>> >
>> > I do a lot of work with novice programmers, and one step that comes
>> > up relatively early is generating SSH keys.  In case you haven't
>> > done it in a while, the output looks like this:
>> >
>> > $ ssh-keygen -t rsa Generating public/private rsa key pair.  Enter
>> > file in which to save the key (/Users/aidan/.ssh/id_rsa): Enter
>> > passphrase (empty for no passphrase):
>> >
>> > When that last step comes up, I am regularly asked, "Does it mean
>> > the system password, or a new one?"  A slight tweak of the language
>> > could easily eliminate that confusion... something like "Enter
>> > passphrase for the new key" or "Enter new passphrase".
>>
>> Perhaps "Enter new passphrase to encrypt the key (empty for no
>> encryption):"
>>
>> This makes it clear that it needs to be a new phrase, and what it will
>> be used for.
>
> You might also consider helping your users get into the good habit of
> reading documentation.

Agreed.

> Not all software suites have good docs but OpenSSH does a pretty job of
> it.

Helpful, but short prompts within the working software are not
unreasonable.  Does making the prompt more clear have any real
negative value?

-- 
Eitan Adler

From mancha1 at zoho.com  Wed Sep  3 16:52:52 2014
From: mancha1 at zoho.com (mancha)
Date: Wed, 3 Sep 2014 06:52:52 +0000
Subject: Call for testing: OpenSSH 6.7
In-Reply-To: <alpine.BSO.2.11.1408181120070.414@natsu.mindrot.org>
References: <alpine.BSO.2.11.1408181120070.414@natsu.mindrot.org>
Message-ID: <20140903065252.GB326@zoho.com>

On Mon, Aug 18, 2014 at 11:23:41AM +1000, Damien Miller wrote:
> Hi,
> 
> OpenSSH 6.7 is almost ready for release, so we would appreciate
> testing on as many platforms and systems as possible.

Hi.

If there's still time it would be good to ensure nuking the source seed
in OpenSSH-Portable's arc4random rs_stir:

http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/crypt/arc4random.c.diff?r1=1.28&r2=1.29

--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/20140903/0a33fbd6/attachment.bin>

From nkadel at gmail.com  Wed Sep  3 21:05:28 2014
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Wed, 3 Sep 2014 07:05:28 -0400
Subject: making the passphrase prompt more clear
In-Reply-To: <CAPgiXS5D4J4MaPLSCQ3CgAe40mC+mjWpdfTAE2CUvR3hiypfmQ@mail.gmail.com>
References: <CAPgiXS5D4J4MaPLSCQ3CgAe40mC+mjWpdfTAE2CUvR3hiypfmQ@mail.gmail.com>
Message-ID: <CAOCN9rzMjYLZV=Ox8XTGKrdjywUu6rLXvHnmKtvQnydhL2pgcQ@mail.gmail.com>

On Tue, Sep 2, 2014 at 6:52 PM, Aidan Feldman <aidan.feldman at gmail.com> wrote:
> I am going to preface this email by saying that I know very little
> about OpenSSH internals, the protocol, etc.
>
> I do a lot of work with novice programmers, and one step that comes up
> relatively early is generating SSH keys.  In case you haven't done it
> in a while, the output looks like this:
>
> $ ssh-keygen -t rsa
> Generating public/private rsa key pair.
> Enter file in which to save the key (/Users/aidan/.ssh/id_rsa):
> Enter passphrase (empty for no passphrase):
>
> When that last step comes up, I am regularly asked, "Does it mean the
> system password, or a new one?"  A slight tweak of the language could
> easily eliminate that confusion... something like "Enter passphrase
> for the new key" or "Enter new passphrase".
>
> I would happily submit the patch myself if it wouldn't take a few
> hours for me to figure out how to do so :-)  Thanks!

What a *sensible* person! Kudos to you for catching just the sort of
thing that irritates or confuses people, especially new users.

I'd suggest "Enter passphrase for key (empty for no passphrase)"

From alex at alex.org.uk  Wed Sep  3 21:42:05 2014
From: alex at alex.org.uk (Alex Bligh)
Date: Wed, 3 Sep 2014 12:42:05 +0100
Subject: making the passphrase prompt more clear
In-Reply-To: <CAOCN9rzMjYLZV=Ox8XTGKrdjywUu6rLXvHnmKtvQnydhL2pgcQ@mail.gmail.com>
References: <CAPgiXS5D4J4MaPLSCQ3CgAe40mC+mjWpdfTAE2CUvR3hiypfmQ@mail.gmail.com>
 <CAOCN9rzMjYLZV=Ox8XTGKrdjywUu6rLXvHnmKtvQnydhL2pgcQ@mail.gmail.com>
Message-ID: <44C3E7CA-4D63-4436-AF50-1F11853F2C9E@alex.org.uk>


On 3 Sep 2014, at 12:05, Nico Kadel-Garcia <nkadel at gmail.com> wrote:

> What a *sensible* person! Kudos to you for catching just the sort of
> thing that irritates or confuses people, especially new users.
> 
> I'd suggest "Enter passphrase for key (empty for no passphrase)"

+1 on both points. Save that I'd perhaps say

 "Enter new passphrase for key (empty for none)"

"new" because otherwise it can be construed as asking for an
existing passphrase, and "none" because it's shorter.

-- 
Alex Bligh





From dkg at fifthhorseman.net  Thu Sep  4 01:39:24 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 03 Sep 2014 11:39:24 -0400
Subject: making the passphrase prompt more clear
In-Reply-To: <44C3E7CA-4D63-4436-AF50-1F11853F2C9E@alex.org.uk>
References: <CAPgiXS5D4J4MaPLSCQ3CgAe40mC+mjWpdfTAE2CUvR3hiypfmQ@mail.gmail.com>
 <CAOCN9rzMjYLZV=Ox8XTGKrdjywUu6rLXvHnmKtvQnydhL2pgcQ@mail.gmail.com>
 <44C3E7CA-4D63-4436-AF50-1F11853F2C9E@alex.org.uk>
Message-ID: <5407362C.5090202@fifthhorseman.net>

On 09/03/2014 07:42 AM, Alex Bligh wrote:
> 
> On 3 Sep 2014, at 12:05, Nico Kadel-Garcia <nkadel at gmail.com> wrote:
> 
>> What a *sensible* person! Kudos to you for catching just the sort of
>> thing that irritates or confuses people, especially new users.
>>
>> I'd suggest "Enter passphrase for key (empty for no passphrase)"
> 
> +1 on both points. Save that I'd perhaps say
> 
>  "Enter new passphrase for key (empty for none)"
> 
> "new" because otherwise it can be construed as asking for an
> existing passphrase, and "none" because it's shorter.

I like Alex's wording.  It's concise, and it avoids the ambiguity of the
current prompt.

Thanks for raising this, Aidan!

	--dkg

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

From djm at mindrot.org  Thu Sep  4 03:46:11 2014
From: djm at mindrot.org (Damien Miller)
Date: Thu, 4 Sep 2014 03:46:11 +1000 (EST)
Subject: Call for testing: OpenSSH 6.7
In-Reply-To: <20140903065252.GB326@zoho.com>
References: <alpine.BSO.2.11.1408181120070.414@natsu.mindrot.org>
 <20140903065252.GB326@zoho.com>
Message-ID: <alpine.BSO.2.11.1409040346030.740@natsu.mindrot.org>

On Wed, 3 Sep 2014, mancha wrote:

> On Mon, Aug 18, 2014 at 11:23:41AM +1000, Damien Miller wrote:
> > Hi,
> > 
> > OpenSSH 6.7 is almost ready for release, so we would appreciate
> > testing on as many platforms and systems as possible.
> 
> Hi.
> 
> If there's still time it would be good to ensure nuking the source seed
> in OpenSSH-Portable's arc4random rs_stir:
> 
> http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/crypt/arc4random.c.diff?r1=1.28&r2=1.29

done - thanks.

-d

From mancha1 at zoho.com  Thu Sep  4 04:00:12 2014
From: mancha1 at zoho.com (mancha)
Date: Wed, 3 Sep 2014 18:00:12 +0000
Subject: Call for testing: OpenSSH 6.7
In-Reply-To: <alpine.BSO.2.11.1409040346030.740@natsu.mindrot.org>
References: <alpine.BSO.2.11.1408181120070.414@natsu.mindrot.org>
 <20140903065252.GB326@zoho.com>
 <alpine.BSO.2.11.1409040346030.740@natsu.mindrot.org>
Message-ID: <20140903180012.GA764@zoho.com>

On Thu, Sep 04, 2014 at 03:46:11AM +1000, Damien Miller wrote:
> On Wed, 3 Sep 2014, mancha wrote:
> 
> > On Mon, Aug 18, 2014 at 11:23:41AM +1000, Damien Miller wrote:
> > > Hi,
> > > 
> > > OpenSSH 6.7 is almost ready for release, so we would appreciate
> > > testing on as many platforms and systems as possible.
> > 
> > Hi.
> > 
> > If there's still time it would be good to ensure nuking the source
> > seed in OpenSSH-Portable's arc4random rs_stir:
> > 
> > http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/crypt/arc4random.c.diff?r1=1.28&r2=1.29
> 
> done - thanks.
> 
> -d

Great; thanks.

--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/20140903/336d1dfb/attachment.bin>

From ag4ve.us at gmail.com  Thu Sep  4 20:11:46 2014
From: ag4ve.us at gmail.com (shawn wilson)
Date: Thu, 4 Sep 2014 06:11:46 -0400
Subject: Fwd: making the passphrase prompt more clear
In-Reply-To: <5407362C.5090202@fifthhorseman.net>
References: <CAPgiXS5D4J4MaPLSCQ3CgAe40mC+mjWpdfTAE2CUvR3hiypfmQ@mail.gmail.com>
 <CAOCN9rzMjYLZV=Ox8XTGKrdjywUu6rLXvHnmKtvQnydhL2pgcQ@mail.gmail.com>
 <44C3E7CA-4D63-4436-AF50-1F11853F2C9E@alex.org.uk>
 <5407362C.5090202@fifthhorseman.net>
Message-ID: <CAH_OBifvotLGN4VBvCe5AteKRU+VOrXYJpe3T4muiKyp_qmZ7A@mail.gmail.com>

This got me thinking, shouldn't this go through PAM so that password
strength restrictions can be set as well? Obviously most ssh keys are
created locally. But, if this were implemented, I think most distros
would adopt the same strength criteria on this as they do with passwd
and the like.


---------- Forwarded message ----------
From: Daniel Kahn Gillmor <dkg at fifthhorseman.net>
Date: Wed, Sep 3, 2014 at 11:39 AM
Subject: Re: making the passphrase prompt more clear
To: Alex Bligh <alex at alex.org.uk>, Nico Kadel-Garcia <nkadel at gmail.com>
Cc: Aidan Feldman <aidan.feldman at gmail.com>,
"openssh-unix-dev at mindrot.org" <openssh-unix-dev at mindrot.org>


On 09/03/2014 07:42 AM, Alex Bligh wrote:
>
> On 3 Sep 2014, at 12:05, Nico Kadel-Garcia <nkadel at gmail.com> wrote:
>
>> What a *sensible* person! Kudos to you for catching just the sort of
>> thing that irritates or confuses people, especially new users.
>>
>> I'd suggest "Enter passphrase for key (empty for no passphrase)"
>
> +1 on both points. Save that I'd perhaps say
>
>  "Enter new passphrase for key (empty for none)"
>
> "new" because otherwise it can be construed as asking for an
> existing passphrase, and "none" because it's shorter.

I like Alex's wording.  It's concise, and it avoids the ambiguity of the
current prompt.

Thanks for raising this, Aidan!

        --dkg


_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev at mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 968 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20140904/fbeb62b5/attachment.bin>

From nkadel at gmail.com  Thu Sep  4 20:59:54 2014
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Thu, 4 Sep 2014 06:59:54 -0400
Subject: making the passphrase prompt more clear
In-Reply-To: <CAH_OBifvotLGN4VBvCe5AteKRU+VOrXYJpe3T4muiKyp_qmZ7A@mail.gmail.com>
References: <CAPgiXS5D4J4MaPLSCQ3CgAe40mC+mjWpdfTAE2CUvR3hiypfmQ@mail.gmail.com>
 <CAOCN9rzMjYLZV=Ox8XTGKrdjywUu6rLXvHnmKtvQnydhL2pgcQ@mail.gmail.com>
 <44C3E7CA-4D63-4436-AF50-1F11853F2C9E@alex.org.uk>
 <5407362C.5090202@fifthhorseman.net>
 <CAH_OBifvotLGN4VBvCe5AteKRU+VOrXYJpe3T4muiKyp_qmZ7A@mail.gmail.com>
Message-ID: <CAOCN9rwUEED_mdzW4tUYbAm4wmcOegiYpYaZhFbgtYfAjBXeKA@mail.gmail.com>

On Thu, Sep 4, 2014 at 6:11 AM, shawn wilson <ag4ve.us at gmail.com> wrote:
> This got me thinking, shouldn't this go through PAM so that password
> strength restrictions can be set as well? Obviously most ssh keys are
> created locally. But, if this were implemented, I think most distros
> would adopt the same strength criteria on this as they do with passwd
> and the like.

That... sounds wildly off-topic from the original note, and extremely
fragile. You'd have to route the existing 'ssh-keygen' tool, which is
an entirely local, well contained, and very stable tool, through PAM,
which is in itself a maintenance and configuration nightmare. If you
think I'm kidding, just *look* at the contents of /etc/pam.d, and the
necessary changes for requirements such as password length or mixed
case policy, and their instability when modified by tools such as
"authconfig" in the Red Hat Linux world. On top of that, modifying
them locally for desired ssh-keygen policy would require hand-editing
the /etc/pam.d files.

I wouldn't encourage it for ssh-keygen, which works very reliably as is.

From vinschen at redhat.com  Thu Sep  4 21:10:42 2014
From: vinschen at redhat.com (Corinna Vinschen)
Date: Thu, 4 Sep 2014 13:10:42 +0200
Subject: making the passphrase prompt more clear
In-Reply-To: <CAOCN9rwUEED_mdzW4tUYbAm4wmcOegiYpYaZhFbgtYfAjBXeKA@mail.gmail.com>
References: <CAPgiXS5D4J4MaPLSCQ3CgAe40mC+mjWpdfTAE2CUvR3hiypfmQ@mail.gmail.com>
 <CAOCN9rzMjYLZV=Ox8XTGKrdjywUu6rLXvHnmKtvQnydhL2pgcQ@mail.gmail.com>
 <44C3E7CA-4D63-4436-AF50-1F11853F2C9E@alex.org.uk>
 <5407362C.5090202@fifthhorseman.net>
 <CAH_OBifvotLGN4VBvCe5AteKRU+VOrXYJpe3T4muiKyp_qmZ7A@mail.gmail.com>
 <CAOCN9rwUEED_mdzW4tUYbAm4wmcOegiYpYaZhFbgtYfAjBXeKA@mail.gmail.com>
Message-ID: <20140904111042.GA17490@calimero.vinschen.de>

On Sep  4 06:59, Nico Kadel-Garcia wrote:
> On Thu, Sep 4, 2014 at 6:11 AM, shawn wilson <ag4ve.us at gmail.com> wrote:
> > This got me thinking, shouldn't this go through PAM so that password
> > strength restrictions can be set as well? Obviously most ssh keys are
> > created locally. But, if this were implemented, I think most distros
> > would adopt the same strength criteria on this as they do with passwd
> > and the like.
> 
> That... sounds wildly off-topic from the original note, and extremely
> fragile. You'd have to route the existing 'ssh-keygen' tool, which is
> an entirely local, well contained, and very stable tool, through PAM,
> which is in itself a maintenance and configuration nightmare.

...or doesn't even exist on the target system.

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

From ag4ve.us at gmail.com  Thu Sep  4 21:08:50 2014
From: ag4ve.us at gmail.com (shawn wilson)
Date: Thu, 4 Sep 2014 07:08:50 -0400
Subject: making the passphrase prompt more clear
In-Reply-To: <CAOCN9rwUEED_mdzW4tUYbAm4wmcOegiYpYaZhFbgtYfAjBXeKA@mail.gmail.com>
References: <CAPgiXS5D4J4MaPLSCQ3CgAe40mC+mjWpdfTAE2CUvR3hiypfmQ@mail.gmail.com>
 <CAOCN9rzMjYLZV=Ox8XTGKrdjywUu6rLXvHnmKtvQnydhL2pgcQ@mail.gmail.com>
 <44C3E7CA-4D63-4436-AF50-1F11853F2C9E@alex.org.uk>
 <5407362C.5090202@fifthhorseman.net>
 <CAH_OBifvotLGN4VBvCe5AteKRU+VOrXYJpe3T4muiKyp_qmZ7A@mail.gmail.com>
 <CAOCN9rwUEED_mdzW4tUYbAm4wmcOegiYpYaZhFbgtYfAjBXeKA@mail.gmail.com>
Message-ID: <CAH_OBiezKgHt_YX6tAqSWmnzdoLh1B-cs+RqRh6gsNPpQ0_h=Q@mail.gmail.com>

On Thu, Sep 4, 2014 at 6:59 AM, Nico Kadel-Garcia <nkadel at gmail.com> wrote:
> On Thu, Sep 4, 2014 at 6:11 AM, shawn wilson <ag4ve.us at gmail.com> wrote:
>> This got me thinking, shouldn't this go through PAM so that password
>> strength restrictions can be set as well? Obviously most ssh keys are
>> created locally. But, if this were implemented, I think most distros
>> would adopt the same strength criteria on this as they do with passwd
>> and the like.
>
> That... sounds wildly off-topic from the original note,

Ah sorry, I should've modified the subject - figured the fwd would
give the email a new id.

> and extremely
> fragile. You'd have to route the existing 'ssh-keygen' tool, which is
> an entirely local, well contained, and very stable tool, through PAM,
> which is in itself a maintenance and configuration nightmare.

There is already kind of the configuration option to do this: --with-pam

> If you
> think I'm kidding, just *look* at the contents of /etc/pam.d, and the
> necessary changes for requirements such as password length or mixed
> case policy, and their instability when modified by tools such as
> "authconfig" in the Red Hat Linux world. On top of that, modifying
> them locally for desired ssh-keygen policy would require hand-editing
> the /etc/pam.d files.
>
> I wouldn't encourage it for ssh-keygen, which works very reliably as is.

Well, is there another way to warn of weak passwords in ssh-keygen?

From nkadel at gmail.com  Fri Sep  5 00:43:08 2014
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Thu, 4 Sep 2014 10:43:08 -0400
Subject: making the passphrase prompt more clear
In-Reply-To: <CAH_OBiezKgHt_YX6tAqSWmnzdoLh1B-cs+RqRh6gsNPpQ0_h=Q@mail.gmail.com>
References: <CAPgiXS5D4J4MaPLSCQ3CgAe40mC+mjWpdfTAE2CUvR3hiypfmQ@mail.gmail.com>
 <CAOCN9rzMjYLZV=Ox8XTGKrdjywUu6rLXvHnmKtvQnydhL2pgcQ@mail.gmail.com>
 <44C3E7CA-4D63-4436-AF50-1F11853F2C9E@alex.org.uk>
 <5407362C.5090202@fifthhorseman.net>
 <CAH_OBifvotLGN4VBvCe5AteKRU+VOrXYJpe3T4muiKyp_qmZ7A@mail.gmail.com>
 <CAOCN9rwUEED_mdzW4tUYbAm4wmcOegiYpYaZhFbgtYfAjBXeKA@mail.gmail.com>
 <CAH_OBiezKgHt_YX6tAqSWmnzdoLh1B-cs+RqRh6gsNPpQ0_h=Q@mail.gmail.com>
Message-ID: <CAOCN9ryeFgssoyt7voS9i00-MjnaCZF9=8azg-3RYojnV=h0wQ@mail.gmail.com>

On Thu, Sep 4, 2014 at 7:08 AM, shawn wilson <ag4ve.us at gmail.com> wrote:
> On Thu, Sep 4, 2014 at 6:59 AM, Nico Kadel-Garcia <nkadel at gmail.com> wrote:
>> On Thu, Sep 4, 2014 at 6:11 AM, shawn wilson <ag4ve.us at gmail.com> wrote:
>>> This got me thinking, shouldn't this go through PAM so that password
>>> strength restrictions can be set as well? Obviously most ssh keys are
>>> created locally. But, if this were implemented, I think most distros
>>> would adopt the same strength criteria on this as they do with passwd
>>> and the like.
>>
>> That... sounds wildly off-topic from the original note,
>
> Ah sorry, I should've modified the subject - figured the fwd would
> give the email a new id.
>
>> and extremely
>> fragile. You'd have to route the existing 'ssh-keygen' tool, which is
>> an entirely local, well contained, and very stable tool, through PAM,
>> which is in itself a maintenance and configuration nightmare.
>
> There is already kind of the configuration option to do this: --with-pam

As far as I can tell, that's for sshd, which is a very, very different tool.

From plautrba at redhat.com  Tue Sep  9 04:31:25 2014
From: plautrba at redhat.com (Petr Lautrbach)
Date: Mon, 8 Sep 2014 20:31:25 +0200
Subject: possible deadcodes in sources
Message-ID: <20140908183125.GA9419@hulk.w.lan>

Hello,

we've run a coverity scan on the openssh sources and it found several
issues. Although the scan was run on patched rhel sources, some results are applicable to vanilla sources 
too.

 * servconf.c:1458:dead_error_line ? Execution cannot reach this statement "*intptr = *intptr + 1;"

--- a/servconf.c
+++ b/servconf.c
@@ -1451,12 +1451,8 @@ process_server_config_line(ServerOptions *options, char *line,
                if (!arg || *arg == '\0')
                        fatal("%s line %d: missing file name.",
                            filename, linenum);
-               if (*activep && *charptr == NULL) {
+               if (*activep && *charptr == NULL)
                        *charptr = tilde_expand_filename(arg, getuid());
-                       /* increase optional counter */
-                       if (intptr != NULL)
-                               *intptr = *intptr + 1;
-               }
                break;
 
        case sClientAliveInterval:



 * monitor_wrap.c:720:dead_error_line ? Execution cannot reach this statement "close(tmp2);".o

--- a/monitor_wrap.c
+++ b/monitor_wrap.c
@@ -714,10 +714,8 @@ mm_pty_allocate(int *ptyfd, int *ttyfd, char *namebuf, size_t namebuflen)
        if ((tmp1 = dup(pmonitor->m_recvfd)) == -1 ||
            (tmp2 = dup(pmonitor->m_recvfd)) == -1) {
                error("%s: cannot allocate fds for pty", __func__);
-               if (tmp1 > 0)
+               if (tmp1 > -1)
                        close(tmp1);
-               if (tmp2 > 0)
-                       close(tmp2);
                return 0;
        }
        close(tmp1);


 * sshkey.c:1321:dead_error_line ? Execution cannot reach this statement "break;".

code:
		retval = 0;
/*XXXX*/
		sshkey_free(k);
		if (retval != 0)
			break;

XXXX here probably means fix in future, but the last two lines seem to be functionless



 * clientloop.c:2087:dead_error_line ? Execution cannot reach this expression "81" inside statement "packet_start((success ? 81 ...". 




I hope that it makes sense.

-- 
Petr Lautrbach

From esk-openssh at esk.cs.usu.edu  Tue Sep  9 05:01:59 2014
From: esk-openssh at esk.cs.usu.edu (Eldon Koyle)
Date: Mon, 8 Sep 2014 13:01:59 -0600
Subject: possible deadcodes in sources
In-Reply-To: <20140908183125.GA9419@hulk.w.lan>
References: <20140908183125.GA9419@hulk.w.lan>
Message-ID: <20140908190159.GA24708@esk.usu.edu>

I think coverity is probably wrong on some of these.  Code coverage
testing is a hard problem, and it is not uncommon for the tools to get
it wrong.

There wasn't enough context in servconf.c to see if there is actually a
coverage issue, but the patch completely changes the behavior.

In monitor_wrap.c, it looks like your test might be assuming that two
calls to dup() will return the same value, which is definitely not the
case.

For the one in sshkey.c, you need to check to see if retval is a global
and also check to see if sshkey_free() modifies it; just because it
isn't in the argument list doesn't mean there isn't a side-effect.

Here is an example of why not to blindly trust code checking tools:
https://www.schneier.com/blog/archives/2008/05/random_number_b.html

Not saying it isn't worth looking at, just saying you need to keep in
mind the possibility that they are completely wrong.

-- 
Eldon Koyle
-- 
"I don't care who does the electing as long as I get to do the nominating."
		-- Boss Tweed

On  Sep 08 20:31+0200, Petr Lautrbach wrote:
> Hello,
> 
> we've run a coverity scan on the openssh sources and it found several
> issues. Although the scan was run on patched rhel sources, some results are applicable to vanilla sources 
> too.
> 
>  * servconf.c:1458:dead_error_line ? Execution cannot reach this statement "*intptr = *intptr + 1;"
> 
> --- a/servconf.c
> +++ b/servconf.c
> @@ -1451,12 +1451,8 @@ process_server_config_line(ServerOptions *options, char *line,
>                 if (!arg || *arg == '\0')
>                         fatal("%s line %d: missing file name.",
>                             filename, linenum);
> -               if (*activep && *charptr == NULL) {
> +               if (*activep && *charptr == NULL)
>                         *charptr = tilde_expand_filename(arg, getuid());
> -                       /* increase optional counter */
> -                       if (intptr != NULL)
> -                               *intptr = *intptr + 1;
> -               }
>                 break;
>  
>         case sClientAliveInterval:
> 
> 
> 
>  * monitor_wrap.c:720:dead_error_line ? Execution cannot reach this statement "close(tmp2);".o
> 
> --- a/monitor_wrap.c
> +++ b/monitor_wrap.c
> @@ -714,10 +714,8 @@ mm_pty_allocate(int *ptyfd, int *ttyfd, char *namebuf, size_t namebuflen)
>         if ((tmp1 = dup(pmonitor->m_recvfd)) == -1 ||
>             (tmp2 = dup(pmonitor->m_recvfd)) == -1) {
>                 error("%s: cannot allocate fds for pty", __func__);
> -               if (tmp1 > 0)
> +               if (tmp1 > -1)
>                         close(tmp1);
> -               if (tmp2 > 0)
> -                       close(tmp2);
>                 return 0;
>         }
>         close(tmp1);
> 
> 
>  * sshkey.c:1321:dead_error_line ? Execution cannot reach this statement "break;".
> 
> code:
> 		retval = 0;
> /*XXXX*/
> 		sshkey_free(k);
> 		if (retval != 0)
> 			break;
> 
> XXXX here probably means fix in future, but the last two lines seem to be functionless
> 
> 
> 
>  * clientloop.c:2087:dead_error_line ? Execution cannot reach this expression "81" inside statement "packet_start((success ? 81 ...". 
> 
> 
> 
> 
> I hope that it makes sense.
> 
> -- 
> Petr Lautrbach
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


From esk-openssh at esk.cs.usu.edu  Tue Sep  9 05:51:56 2014
From: esk-openssh at esk.cs.usu.edu (Eldon Koyle)
Date: Mon, 8 Sep 2014 13:51:56 -0600
Subject: possible deadcodes in sources
In-Reply-To: <20140908190159.GA24708@esk.usu.edu>
References: <20140908183125.GA9419@hulk.w.lan>
 <20140908190159.GA24708@esk.usu.edu>
Message-ID: <20140908195156.GC24708@esk.usu.edu>

On  Sep 08 13:01-0600, Eldon Koyle wrote:
<snip>
> In monitor_wrap.c, it looks like your test might be assuming that two
> calls to dup() will return the same value, which is definitely not the
> case.

Looking more closely, the second if case would never be reached unless
tmp2 has been set elsewhere (or is never initialized), in which case
closing it might in fact be a bug and not just a coverage issue.

<snip>

-- 
Eldon Koyle
Information Technology
Utah State University
-- 
Liberty don't work as good in practice as it does in speeches.
		-- The Best of Will Rogers

> On  Sep 08 20:31+0200, Petr Lautrbach wrote:
> > Hello,
> > 
> > we've run a coverity scan on the openssh sources and it found several
> > issues. Although the scan was run on patched rhel sources, some results are applicable to vanilla sources 
> > too.
> > 
> >  * servconf.c:1458:dead_error_line ? Execution cannot reach this statement "*intptr = *intptr + 1;"
> > 
> > --- a/servconf.c
> > +++ b/servconf.c
> > @@ -1451,12 +1451,8 @@ process_server_config_line(ServerOptions *options, char *line,
> >                 if (!arg || *arg == '\0')
> >                         fatal("%s line %d: missing file name.",
> >                             filename, linenum);
> > -               if (*activep && *charptr == NULL) {
> > +               if (*activep && *charptr == NULL)
> >                         *charptr = tilde_expand_filename(arg, getuid());
> > -                       /* increase optional counter */
> > -                       if (intptr != NULL)
> > -                               *intptr = *intptr + 1;
> > -               }
> >                 break;
> >  
> >         case sClientAliveInterval:
> > 
> > 
> > 
> >  * monitor_wrap.c:720:dead_error_line ? Execution cannot reach this statement "close(tmp2);".o
> > 
> > --- a/monitor_wrap.c
> > +++ b/monitor_wrap.c
> > @@ -714,10 +714,8 @@ mm_pty_allocate(int *ptyfd, int *ttyfd, char *namebuf, size_t namebuflen)
> >         if ((tmp1 = dup(pmonitor->m_recvfd)) == -1 ||
> >             (tmp2 = dup(pmonitor->m_recvfd)) == -1) {
> >                 error("%s: cannot allocate fds for pty", __func__);
> > -               if (tmp1 > 0)
> > +               if (tmp1 > -1)
> >                         close(tmp1);
> > -               if (tmp2 > 0)
> > -                       close(tmp2);
> >                 return 0;
> >         }
> >         close(tmp1);
> > 
> > 
> >  * sshkey.c:1321:dead_error_line ? Execution cannot reach this statement "break;".
> > 
> > code:
> > 		retval = 0;
> > /*XXXX*/
> > 		sshkey_free(k);
> > 		if (retval != 0)
> > 			break;
> > 
> > XXXX here probably means fix in future, but the last two lines seem to be functionless
> > 
> > 
> > 
> >  * clientloop.c:2087:dead_error_line ? Execution cannot reach this expression "81" inside statement "packet_start((success ? 81 ...". 
> > 
> > 
> > 
> > 
> > I hope that it makes sense.
> > 
> > -- 
> > Petr Lautrbach
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev at mindrot.org
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From plautrba at redhat.com  Tue Sep  9 18:07:22 2014
From: plautrba at redhat.com (Petr Lautrbach)
Date: Tue, 9 Sep 2014 10:07:22 +0200
Subject: possible deadcodes in sources
In-Reply-To: <20140908190159.GA24708@esk.usu.edu>
References: <20140908183125.GA9419@hulk.w.lan>
 <20140908190159.GA24708@esk.usu.edu>
Message-ID: <20140909080721.GA10565@hulk.w.lan>

On Mon, Sep 08, 2014 at 01:01:59PM -0600, Eldon Koyle wrote:
> I think coverity is probably wrong on some of these.  Code coverage
> testing is a hard problem, and it is not uncommon for the tools to get
> it wrong.

I'll try to explain why I think that coverity is right.

> >  * servconf.c:1458:dead_error_line ? Execution cannot reach this statement "*intptr = *intptr + 1;"
> > 
> > --- a/servconf.c
> > +++ b/servconf.c
> > @@ -1451,12 +1451,8 @@ process_server_config_line(ServerOptions *options, char *line,
> >                 if (!arg || *arg == '\0')
> >                         fatal("%s line %d: missing file name.",
> >                             filename, linenum);
> > -               if (*activep && *charptr == NULL) {
> > +               if (*activep && *charptr == NULL)
> >                         *charptr = tilde_expand_filename(arg, getuid());
> > -                       /* increase optional counter */
> > -                       if (intptr != NULL)
> > -                               *intptr = *intptr + 1;
> > -               }
> >                 break;
> >  

The original code:

 848         int cmdline = 0, *intptr, value, value2, n, port;
...
 865         intptr = NULL;
...
 886         switch (opcode) {
...
1448         case sAuthorizedPrincipalsFile:
1449                 charptr = &options->authorized_principals_file;
1450                 arg = strdelim(&cp);
1451                 if (!arg || *arg == '\0')
1452                         fatal("%s line %d: missing file name.",
1453                             filename, linenum);
1454                 if (*activep && *charptr == NULL) {
1455                         *charptr = tilde_expand_filename(arg,
getuid());
1456                         /* increase optional counter */
1457                         if (intptr != NULL)
1458                                 *intptr = *intptr + 1;
1459                 }
1460                 break;

- intptr is set to NULL, it's not changed and then is compared if it's not NULL

- intptr is used as a reference to options->num_host_key_files when opcode is sHostKeyFile. While
the it's possible to have more then one hostkey, the authorizedprincipalsfile can be only only. I guess
that lines 1456 - 1458 were jsut cut&pasted from sHostKeyFile block.

> > 
> >  * monitor_wrap.c:720:dead_error_line ? Execution cannot reach this statement "close(tmp2);".o
> > 
> > --- a/monitor_wrap.c
> > +++ b/monitor_wrap.c
> > @@ -714,10 +714,8 @@ mm_pty_allocate(int *ptyfd, int *ttyfd, char *namebuf, size_t namebuflen)
> >         if ((tmp1 = dup(pmonitor->m_recvfd)) == -1 ||
> >             (tmp2 = dup(pmonitor->m_recvfd)) == -1) {
> >                 error("%s: cannot allocate fds for pty", __func__);
> > -               if (tmp1 > 0)
> > +               if (tmp1 > -1)
> >                         close(tmp1);
> > -               if (tmp2 > 0)
> > -                       close(tmp2);
> >                 return 0;
> >         }
> >         close(tmp1);

 711         int success = 0, tmp1 = -1, tmp2 = -1;
 712 
 713         /* Kludge: ensure there are fds free to receive the pty/tty */
 714         if ((tmp1 = dup(pmonitor->m_recvfd)) == -1 ||
 715             (tmp2 = dup(pmonitor->m_recvfd)) == -1) {
 716                 error("%s: cannot allocate fds for pty", __func__);
 717                 if (tmp1 > 0)
 718                         close(tmp1);
 719                 if (tmp2 > 0)
 720                         close(tmp2);
 721                 return 0;
 722         }

- when first dup(pmonitor->m_recvfd) fails, tmp1 == -1 and tmp2 == -1
- when second dup(pmonitor->m_recvfd) fails, tmp1 is the first unused fd which can be 0 or more and this should
be closed while tmp2 == -1 and there's no action needed


> > 
> >  * sshkey.c:1321:dead_error_line ? Execution cannot reach this statement "break;".
> > 
> > code:
> > 		retval = 0;
> > /*XXXX*/
> > 		sshkey_free(k);
> > 		if (retval != 0)
> > 			break;
> > 
> > XXXX here probably means fix in future, but the last two lines seem to be functionless

1180         int retval = SSH_ERR_INVALID_FORMAT;
...
1317                 retval = 0;
1318 /*XXXX*/
1319                 sshkey_free(k);
1320                 if (retval != 0)
1321                         break;



> >  * clientloop.c:2087:dead_error_line ? Execution cannot reach this expression "81" inside statement "packet_start((success ? 81 ...". 
> > 

2075 static void             
2076 client_input_global_request(int type, u_int32_t seq, void *ctxt)
2077 {                       
2078         char *rtype;    
2079         int want_reply;
2080         int success = 0;
2081 
2082         rtype = packet_get_string(NULL);
2083         want_reply = packet_get_char();
2084         debug("client_input_global_request: rtype %s want_reply %d",
2085             rtype, want_reply);
2086         if (want_reply) {       
2087                 packet_start(success ?
2088                     SSH2_MSG_REQUEST_SUCCESS : SSH2_MSG_REQUEST_FAILURE);
2089                 packet_send();
2090                 packet_write_wait(); 
2091         }
2092         free(rtype);    
2093 }


Here I'm not sure if there's missing code or it should simple sent always  SSH2_MSG_REQUEST_FAILURE



-- 
Petr Lautrbach


From poorvi.shivhare at ericsson.com  Wed Sep 10 13:57:14 2014
From: poorvi.shivhare at ericsson.com (Poorvi Shivhare)
Date: Wed, 10 Sep 2014 03:57:14 +0000
Subject: facing issues while compiling openSSH using openssl-1.0.1i
Message-ID: <7857828551CAA64992D2B1984E9EAB1D1A3609F3@ESESSMB105.ericsson.se>

Hi,

When I am trying to update openSSH using openssl-1.0.1i.It is giving issues.

./mkinstalldirs /home/epooshi/x86/openssh/openssh-5.2p1//libexec
mkdir /home/epooshi/x86/openssh/openssh-5.2p1/libexec
(umask 022 ; ./mkinstalldirs /var/empty)
mkdir /var/empty
mkdir: Failed to make directory "/var/empty"; Permission denied
*** Error code 2
make: Fatal error: Command failed for target `install-files'

I would be very grateful if someone can give some hint that where is the problem.

Best Regards,
Poorvi Shivhare


From logan at elandsys.com  Wed Sep 10 16:18:03 2014
From: logan at elandsys.com (Loganaden Velvindron)
Date: Tue, 9 Sep 2014 23:18:03 -0700
Subject: facing issues while compiling openSSH using openssl-1.0.1i
In-Reply-To: <7857828551CAA64992D2B1984E9EAB1D1A3609F3@ESESSMB105.ericsson.se>
References: <7857828551CAA64992D2B1984E9EAB1D1A3609F3@ESESSMB105.ericsson.se>
Message-ID: <20140910061803.GA23461@mx.elandsys.com>

On Wed, Sep 10, 2014 at 03:57:14AM +0000, Poorvi Shivhare wrote:
> Hi,
> 
> When I am trying to update openSSH using openssl-1.0.1i.It is giving issues.
> 
> ./mkinstalldirs /home/epooshi/x86/openssh/openssh-5.2p1//libexec
> mkdir /home/epooshi/x86/openssh/openssh-5.2p1/libexec
> (umask 022 ; ./mkinstalldirs /var/empty)
> mkdir /var/empty
> mkdir: Failed to make directory "/var/empty"; Permission denied
> *** Error code 2
> make: Fatal error: Command failed for target `install-files'

Hi Poorvi,

you need root permissions to create /var/empty. use sudo.


> 
> I would be very grateful if someone can give some hint that where is the problem.
> 
> Best Regards,
> Poorvi Shivhare
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From imorgan at nas.nasa.gov  Thu Sep 11 02:54:50 2014
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Wed, 10 Sep 2014 09:54:50 -0700
Subject: facing issues while compiling openSSH using openssl-1.0.1i
In-Reply-To: <7857828551CAA64992D2B1984E9EAB1D1A3609F3@ESESSMB105.ericsson.se>
References: <7857828551CAA64992D2B1984E9EAB1D1A3609F3@ESESSMB105.ericsson.se>
Message-ID: <20140910165450.GF10370@linux124.nas.nasa.gov>

On Wed, Sep 10, 2014 at 03:57:14 +0000, Poorvi Shivhare wrote:
> Hi,
> 
> When I am trying to update openSSH using openssl-1.0.1i.It is giving issues.
> 
> ./mkinstalldirs /home/epooshi/x86/openssh/openssh-5.2p1//libexec
> mkdir /home/epooshi/x86/openssh/openssh-5.2p1/libexec
> (umask 022 ; ./mkinstalldirs /var/empty)
> mkdir /var/empty
> mkdir: Failed to make directory "/var/empty"; Permission denied
> *** Error code 2
> make: Fatal error: Command failed for target `install-files'
> 
> I would be very grateful if someone can give some hint that where is the problem.
> 
> Best Regards,
> Poorvi Shivhare
> 

Given the location that you are trying to install OpenSSH, I'm making
the assumption that you only want the client. In that case, you can run
"make install-nosysconf."

-- 
Iain Morgan

From phil.pennock at globnix.org  Thu Sep 11 16:31:01 2014
From: phil.pennock at globnix.org (Phil Pennock)
Date: Thu, 11 Sep 2014 06:31:01 +0000
Subject: MacOS; Unix sockets & man (Re: Call for testing: OpenSSH 6.7)
In-Reply-To: <alpine.BSO.2.11.1408181120070.414@natsu.mindrot.org>
References: <alpine.BSO.2.11.1408181120070.414@natsu.mindrot.org>
Message-ID: <20140911063100.GA10270@tower.spodhuis.org>

On 2014-08-18 at 11:23 +1000, Damien Miller wrote:
> OpenSSH 6.7 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This is a big release
> containing a number of features, a lot of internal refactoring and some
> potentially-incompatible changes.
> 
> Snapshot releases for portable OpenSSH are available from
> http://www.mindrot.org/openssh_snap/

Downloaded openssh-SNAP-20140911.tar.gz onto MacOS 10.8.5, using Clang
(Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)).

Configured with:

  ./configure --with-libedit --with-pam --with-kerberos5 \
    --prefix=/opt/openssh --sysconfdir=/etc/ssh \
    --with-ssl-dir=/usr/local/Cellar/openssl/1.0.1i \
    --with-ldns

stolen/derived from the Homebrew configuration: so I think this will
match a common configuration profile on this platform (everything except
the --prefix value chosen).

"all tests passed".

The Unix port forwarding appears to be undocumented.  From reading the
code, presence of a '/' anywhere in the PORT field causes
parse_fwd_field() to mark the item as a path.  When I supply an absolute
path, this works and works great!  :)  If I supply a relative path, then
it's passed to the server as a path but fails, triggering a warning
message:

  Warning: remote port forwarding failed for listen path tmp/FRED

The server-side debug logs:
----------------------------8< cut here >8------------------------------
debug1: server_input_global_request: rtype streamlocal-forward at openssh.com want_reply 1
debug1: server_input_global_request: streamlocal-forward listen path usr/fred
debug3: channel_setup_fwd_listener_streamlocal: type 19 path usr/fred
bind: Permission denied
unix_listener: cannot bind to path: usr/fred
----------------------------8< cut here >8------------------------------

This is with client and server both on the same MacOS box.

Since I'm not sure if it's only supposed to work if the path _starts_
with a slash, or if it _should_ work for _contains_ a slash, I'm not
offering a documentation patch; I'll note that I'd expect to see this
documented under -L, -R or the ssh_config options, or perhaps in a new
section in ssh(1) "Port Forwarding" and cut down on a bunch of the
duplication by referring to a full spec in that.

(If you want an nroff patch and say what the behaviour should be, I'd be
happy to contribute).


To finish off, compilation warnings until the end of the email, so if
not interested in these, then there's nothing else to read here.

Thanks,
-Phil

I'll list them all for completeness, despite the lack of visible
replacements for some deprecation-warning items:

 * `getrrsetbyname-ldns.c` had complaints on multiple lines of the form:
----------------------------8< cut here >8------------------------------
getrrsetbyname-ldns.c:92:6: warning: variable 'ldns_res' is used uninitialized whenever 'if' condition is true
----------------------------8< cut here >8------------------------------
    Always for `ldns_res`.
    These were classed as `-Wsometimes-uninitialized` warnings.

 * Lots of ranlib complaints of files having no symbols; which I suspect
   come down to not defining things like USE_BUILTIN_RIJNDAEL so these
   are just noise

 * Two complaints of daemon() deprecation in ssh.c, lines 1288 & 1300;
   also in sshd.c:1892:
----------------------------8< cut here >8------------------------------
ssh.c:1288:2: warning: 'daemon' is deprecated: first deprecated in OS X 10.5 [-Wdeprecated-declarations]
----------------------------8< cut here >8------------------------------
   Man-page daemon(3) says nothing about a deprecation; stdlib.h just
   has:
----------------------------8< cut here >8------------------------------
int      daemon(int, int) __DARWIN_1050(daemon) __OSX_AVAILABLE_BUT_DEPRECATED(__MAC_10_0, __MAC_10_5, __IPHONE_2_0, __IPHONE_2_0);
----------------------------8< cut here >8------------------------------
   and I'm not seeing what replaces it, unless the answer is just
   "use launchd".

 * Many of these:
----------------------------8< cut here >8------------------------------
clang: warning: argument unused during compilation: '-pie'
----------------------------8< cut here >8------------------------------

 * loginrec.c : `struct utmp` and the `login()`, `logout()` and
   `logwtmp()` functions are triggering deprecation warnings:
----------------------------8< cut here >8------------------------------
loginrec.c:188:49: warning: 'utmp' is deprecated [-Wdeprecated-declarations]
void set_utmp_time(struct logininfo *li, struct utmp *ut);
----------------------------8< cut here >8------------------------------
   The function at least has a deprecated-since label of 10.5:
     __OSX_AVAILABLE_BUT_DEPRECATED(__MAC_10_0,__MAC_10_5,__IPHONE_NA,__IPHONE_NA);

 * sandbox-darwin.c warnings and deprecations:
----------------------------8< cut here >8------------------------------
sandbox-darwin.c:43:25: warning: declaration of 'struct monitor' will not be visible outside of this function [-Wvisibility]
ssh_sandbox_init(struct monitor *monitor)
                        ^
sandbox-darwin.c:65:6: warning: 'sandbox_init' is deprecated: first deprecated in OS X 10.8 [-Wdeprecated-declarations]
        if (sandbox_init(kSBXProfilePureComputation, SANDBOX_NAMED,
            ^
/usr/include/sandbox.h:65:5: note: 'sandbox_init' declared here
int sandbox_init(const char *profile, uint64_t flags, char **errorbuf);
    ^
sandbox-darwin.c:65:19: warning: 'kSBXProfilePureComputation' is deprecated: first deprecated in OS X 10.8
      [-Wdeprecated-declarations]
        if (sandbox_init(kSBXProfilePureComputation, SANDBOX_NAMED,
                         ^
/usr/include/sandbox.h:97:19: note: 'kSBXProfilePureComputation' declared here
extern const char kSBXProfilePureComputation[];
                  ^
3 warnings generated.
----------------------------8< cut here >8------------------------------

From poorvi.shivhare at ericsson.com  Thu Sep 11 20:41:53 2014
From: poorvi.shivhare at ericsson.com (Poorvi Shivhare)
Date: Thu, 11 Sep 2014 10:41:53 +0000
Subject: Soalris Sparc platform: issues coming while compiling openSSH using
 openssl-1.0.1i
Message-ID: <7857828551CAA64992D2B1984E9EAB1D1A36CDE1@ESESSMB105.ericsson.se>

Hi,

When I am trying to update openSSH using openssl-1.0.1i on Solaris sparc platform.It is giving issues.

making all in crypto...
gmake[1]: Entering directory `/home/epooshi/openssl_sparc/openssl-1.0.1i/crypto'
( echo "#ifndef MK1MF_BUILD"; \
        echo '  /* auto-generated by crypto/Makefile for crypto/cversion.c */'; \
        echo '  #define CFLAGS "cc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xtarget=ultra -xarch=v8plus -xO5 -xstrcons t -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM"'; \
        echo '  #define PLATFORM "solaris-sparcv9-cc"'; \
        echo "  #define DATE \"`LC_ALL=C LC_TIME=C date`\""; \
        echo '#endif' ) >buildinf.h
cc -I. -I.. -I../include  -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xtarget=ultra -xarch=v8plus -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM   -c -o cryptlib.o cryptlib                                                             .c
gmake[1]: cc: Command not found
gmake[1]: *** [cryptlib.o] Error 127
gmake[1]: Leaving directory `/home/epooshi/openssl_sparc/openssl-1.0.1i/crypto'
gmake: *** [build_crypto] Error 1
%sekax116:/home/epooshi/openssl_sparc/openssl-1.0.1i

I would be very grateful if someone can give some hint that where is the problem.

Best Regards,
Poorvi Shivhare


From loganaden at gmail.com  Thu Sep 11 21:23:36 2014
From: loganaden at gmail.com (Loganaden Velvindron)
Date: Thu, 11 Sep 2014 15:23:36 +0400
Subject: Soalris Sparc platform: issues coming while compiling openSSH
 using openssl-1.0.1i
In-Reply-To: <7857828551CAA64992D2B1984E9EAB1D1A36CDE1@ESESSMB105.ericsson.se>
References: <7857828551CAA64992D2B1984E9EAB1D1A36CDE1@ESESSMB105.ericsson.se>
Message-ID: <CAOp4FwTySennujAxpdoJJ9Av6i-iWSWMfhmADwrmcEiq50k8jA@mail.gmail.com>

On Thu, Sep 11, 2014 at 2:41 PM, Poorvi Shivhare
<poorvi.shivhare at ericsson.com> wrote:
> Hi,
>
> When I am trying to update openSSH using openssl-1.0.1i on Solaris sparc platform.It is giving issues.
>
> making all in crypto...
> gmake[1]: Entering directory `/home/epooshi/openssl_sparc/openssl-1.0.1i/crypto'
> ( echo "#ifndef MK1MF_BUILD"; \
>         echo '  /* auto-generated by crypto/Makefile for crypto/cversion.c */'; \
>         echo '  #define CFLAGS "cc -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xtarget=ultra -xarch=v8plus -xO5 -xstrcons t -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM"'; \
>         echo '  #define PLATFORM "solaris-sparcv9-cc"'; \
>         echo "  #define DATE \"`LC_ALL=C LC_TIME=C date`\""; \
>         echo '#endif' ) >buildinf.h
> cc -I. -I.. -I../include  -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN -DHAVE_DLFCN_H -xtarget=ultra -xarch=v8plus -xO5 -xstrconst -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM   -c -o cryptlib.o cryptlib                                                             .c
> gmake[1]: cc: Command not found
> gmake[1]: *** [cryptlib.o] Error 127
> gmake[1]: Leaving directory `/home/epooshi/openssl_sparc/openssl-1.0.1i/crypto'
> gmake: *** [build_crypto] Error 1
> %sekax116:/home/epooshi/openssl_sparc/openssl-1.0.1i
>
> I would be very grateful if someone can give some hint that where is the problem.

It looks like you are missing the gcc compiler.

>
> Best Regards,
> Poorvi Shivhare
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev



-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.

From Sami.Hartikainen at teleste.com  Thu Sep 11 22:58:35 2014
From: Sami.Hartikainen at teleste.com (Sami.Hartikainen at teleste.com)
Date: Thu, 11 Sep 2014 12:58:35 +0000
Subject: Remote port forwarding in a multiplexed connection: possible
 "clientspecified" bug
Message-ID: <6F84EA015648C0459529AABFB7BF9E02016C9EE8CF@DAYX.twin.net>

Remote port forwarding with sshd_config option 'GatewayPorts' set to "clientspecified" does not seem to work as specified, when configured from a  "slave" ssh using a multiplexed connection. Ssh man page on remote port forwarding says:

"-R [bind_address:]port:host:hostport
             ...
             By default, the listening socket on the server will be bound to the loopback
             interface only.  This may be overridden by specifying a bind_address.  An empty
             bind_address, or the address '*', indicates that the remote socket should listen
             on all interfaces.
             ...
"

Now the following mux command (on client with ControlMaster connected and running and ControlPath set appropriately):

    $ ssh -O forward -R ':0:localhost:3502' <hostaddr>
    Allocated port 48293 for remote forward to localhost:3502

results in (on server):

    $ netstat -lt
    Active Internet connections (only servers)
    Proto	Recv-Q	Send-Q	Local Address	Foreign Address State      
    tcp	0	0	localhost:48293	*:*                     LISTEN     
    tcp	0	0	*:ssh		*:*                     LISTEN     
    tcp6	0	0	localhost:48293	[::]:*                  LISTEN     
    tcp6	0	0	[::]:ssh		[::]:*                  LISTEN     

Port 48293 (set with an empty bind_address) should be bind to wildcard address, not localhost. The same -R option given for ControlMaster (or non-multiplexed ssh client) works as expected.

Looks like a bug in ssh client code?

Client version: OpenSSH_6.6.1p1 Ubuntu-2ubuntu2, OpenSSL 1.0.1f 6 Jan 2014

--
Sami Hartikainen


From djm at mindrot.org  Fri Sep 12 11:33:47 2014
From: djm at mindrot.org (Damien Miller)
Date: Fri, 12 Sep 2014 11:33:47 +1000 (EST)
Subject: Soalris Sparc platform: issues coming while compiling openSSH
 using openssl-1.0.1i
In-Reply-To: <7857828551CAA64992D2B1984E9EAB1D1A36CDE1@ESESSMB105.ericsson.se>
References: <7857828551CAA64992D2B1984E9EAB1D1A36CDE1@ESESSMB105.ericsson.se>
Message-ID: <alpine.BSO.2.11.1409121133380.10472@natsu.mindrot.org>

please stop emailing openssh at openssh.com

On Thu, 11 Sep 2014, Poorvi Shivhare wrote:

> 
> Hi,
> 
>  
> 
> When I am trying to update openSSH using openssl-1.0.1i on Solaris sparc
> platform.It is giving issues.
> 
>  
> 
> making all in crypto...
> 
> gmake[1]: Entering directory
> `/home/epooshi/openssl_sparc/openssl-1.0.1i/crypto'
> 
> ( echo "#ifndef MK1MF_BUILD"; \
> 
>         echo '  /* auto-generated by crypto/Makefile for crypto/cversion.c
> */'; \
> 
>         echo '  #define CFLAGS "cc -DOPENSSL_THREADS -D_REENTRANT
> -DDSO_DLFCN -DHAVE_DLFCN_H -xtarget=ultra -xarch=v8plus -xO5 -xstrcons t
> -xdepend -Xa -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DSHA1_ASM
> -DSHA256_ASM -DSHA512_ASM -DAES_ASM -DGHASH_ASM"'; \
> 
>         echo '  #define PLATFORM "solaris-sparcv9-cc"'; \
> 
>         echo "  #define DATE \"`LC_ALL=C LC_TIME=C date`\""; \
> 
>         echo '#endif' ) >buildinf.h
> 
> cc -I. -I.. -I../include  -DOPENSSL_THREADS -D_REENTRANT -DDSO_DLFCN
> -DHAVE_DLFCN_H -xtarget=ultra -xarch=v8plus -xO5 -xstrconst -xdepend -Xa
> -DB_ENDIAN -DBN_DIV2W -DOPENSSL_BN_ASM_MONT -DSHA1_ASM -DSHA256_ASM
> -DSHA512_ASM -DAES_ASM -DGHASH_ASM   -c -o cryptlib.o
> cryptlib                                                             .c
> 
> gmake[1]: cc: Command not found
> 
> gmake[1]: *** [cryptlib.o] Error 127
> 
> gmake[1]: Leaving directory
> `/home/epooshi/openssl_sparc/openssl-1.0.1i/crypto'
> 
> gmake: *** [build_crypto] Error 1
> 
> %sekax116:/home/epooshi/openssl_sparc/openssl-1.0.1i       
> 
>  
> 
> I would be very grateful if someone can give some hint that where is the
> problem.
> 
>  
> 
> Best Regards,
> 
> Poorvi Shivhare
> 
>  
> 
> 
> 

From phil.pennock at globnix.org  Fri Sep 12 14:14:00 2014
From: phil.pennock at globnix.org (Phil Pennock)
Date: Fri, 12 Sep 2014 04:14:00 +0000
Subject: MacOS; Unix sockets & man (Re: Call for testing: OpenSSH 6.7)
In-Reply-To: <20140911063100.GA10270@tower.spodhuis.org>
References: <alpine.BSO.2.11.1408181120070.414@natsu.mindrot.org>
 <20140911063100.GA10270@tower.spodhuis.org>
Message-ID: <20140912041400.GA72937@tower.spodhuis.org>

On 2014-09-11 at 06:31 +0000, Phil Pennock wrote:
> Downloaded openssh-SNAP-20140911.tar.gz onto MacOS 10.8.5, using Clang
> (Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn)).

> The Unix port forwarding appears to be undocumented.  From reading the
> code, presence of a '/' anywhere in the PORT field causes
> parse_fwd_field() to mark the item as a path.  When I supply an absolute
> path, this works and works great!  :)  If I supply a relative path, then
> it's passed to the server as a path but fails, triggering a warning
> message:

In addition, `-o StreamLocalBindUnlink=yes` is ineffective when used
with -R:

  ssh -R /tmp/f1:www.spodhuis.org:80 \
    -o ExitOnForwardFailure=yes \
    -o StreamLocalBindUnlink=yes \
    -p 27 localhost

The server logs:
----------------------------8< cut here >8------------------------------
debug1: server_init_dispatch_20
debug1: server_input_global_request: rtype streamlocal-forward at openssh.com want_reply 1
debug1: server_input_global_request: streamlocal-forward listen path /tmp/f1
debug3: channel_setup_fwd_listener_streamlocal: type 19 path /tmp/f1
bind: Address already in use
unix_listener: cannot bind to path: /tmp/f1
----------------------------8< cut here >8------------------------------

For `StreamLocalBindUnlink` the man-page text "This option is only used
for port forwarding to a Unix-domain socket file." is also a little
strange.  It might be a failure of my imagination, but it seems that
port-forwarding destinations which are also accept-only are really
bi-directional and so with "interesting" security implications.

It seems more likely that the "forwarded to" location is always going to
be a connect() to an existing socket, which it makes no sense to unlink
first, so the `StreamLocalBindUnlink` bind+unlink semantics mean this
should be "for port forwarding from a Unix-domain socket file." --
"from", not "to".

Regards,
-Phil

From benjaminfras at netbens.de  Sun Sep 14 00:45:02 2014
From: benjaminfras at netbens.de (Benjamin Fras)
Date: Sat, 13 Sep 2014 16:45:02 +0200
Subject: Use safenet etoken with ssh-agent
Message-ID: <5414586E.2070000@netbens.de>

Hi,

we are using eToken Pro Anywhere to connect with ssh. Basically this is 
working just fine, if you use ssh -I /lib/libeToken.so.8. But I need to 
be able to add the eToken to the ssh-agent due to ForwardAgent-Option. 
In our setup we use ssh-jumphosts from which you can connect to other 
hosts that are isolated from the workstation's network.

Unfortunately ssh-add -s /lib/libeToken.so.8 does not work. After 
entering the passphrase for PKCS#11, the operation fails with "Could not 
add card: /lib/libeToken.so.8". Is there any option to get mores details 
from ssh-add? I didn't find any debug mode I could turn on.

Btw. I'm using Ubuntu 14.04 amd64 with the OpenSSH_6.6.1, OpenSSL 1.0.1f 
6 Jan 2014.

Best regards,
Ben





From djm at mindrot.org  Sun Sep 14 09:43:16 2014
From: djm at mindrot.org (Damien Miller)
Date: Sun, 14 Sep 2014 09:43:16 +1000 (EST)
Subject: Use safenet etoken with ssh-agent
In-Reply-To: <5414586E.2070000@netbens.de>
References: <5414586E.2070000@netbens.de>
Message-ID: <alpine.BSO.2.11.1409140939200.10687@natsu.mindrot.org>

On Sat, 13 Sep 2014, Benjamin Fras wrote:

> Hi,
> 
> we are using eToken Pro Anywhere to connect with ssh. Basically this is
> working just fine, if you use ssh -I /lib/libeToken.so.8. But I need to be
> able to add the eToken to the ssh-agent due to ForwardAgent-Option. In our
> setup we use ssh-jumphosts from which you can connect to other hosts that are
> isolated from the workstation's network.
> 
> Unfortunately ssh-add -s /lib/libeToken.so.8 does not work. After entering the
> passphrase for PKCS#11, the operation fails with "Could not add card:
> /lib/libeToken.so.8". Is there any option to get mores details from ssh-add? I
> didn't find any debug mode I could turn on.

No, because all of the action happens in ssh-agent. You can run ssh-agent
in debugging mode though:

$ ssh-agent -d
SSH_AUTH_SOCK=/tmp/ssh-w2Q7ZYWsIZR5/agent.30154; export SSH_AUTH_SOCK;
echo Agent pid 30154;
$ env SSH_AUTH_SOCK=/tmp/ssh-w2Q7ZYWsIZR5/agent.30154 \
  ssh-add -s /lib/libeToken.so.8

-d

From benjaminfras at netbens.de  Sun Sep 14 23:03:45 2014
From: benjaminfras at netbens.de (Benjamin Fras)
Date: Sun, 14 Sep 2014 15:03:45 +0200
Subject: Use safenet etoken with ssh-agent
In-Reply-To: <alpine.BSO.2.11.1409140939200.10687@natsu.mindrot.org>
References: <5414586E.2070000@netbens.de>
 <alpine.BSO.2.11.1409140939200.10687@natsu.mindrot.org>
Message-ID: <54159231.7090101@netbens.de>

thanks for your reply. I managed to make it work now. I just needed to 
start the ssh-agent and then properly set the SSH_AUTH_SOCK variable. 
Then it is behaving exactly the way I want.

On 14.09.2014 01:43, Damien Miller wrote:
> On Sat, 13 Sep 2014, Benjamin Fras wrote:
>
>> Hi,
>>
>> we are using eToken Pro Anywhere to connect with ssh. Basically this is
>> working just fine, if you use ssh -I /lib/libeToken.so.8. But I need to be
>> able to add the eToken to the ssh-agent due to ForwardAgent-Option. In our
>> setup we use ssh-jumphosts from which you can connect to other hosts that are
>> isolated from the workstation's network.
>>
>> Unfortunately ssh-add -s /lib/libeToken.so.8 does not work. After entering the
>> passphrase for PKCS#11, the operation fails with "Could not add card:
>> /lib/libeToken.so.8". Is there any option to get mores details from ssh-add? I
>> didn't find any debug mode I could turn on.
> No, because all of the action happens in ssh-agent. You can run ssh-agent
> in debugging mode though:
>
> $ ssh-agent -d
> SSH_AUTH_SOCK=/tmp/ssh-w2Q7ZYWsIZR5/agent.30154; export SSH_AUTH_SOCK;
> echo Agent pid 30154;
> $ env SSH_AUTH_SOCK=/tmp/ssh-w2Q7ZYWsIZR5/agent.30154 \
>    ssh-add -s /lib/libeToken.so.8
>
> -d
>


From loganaden at gmail.com  Mon Sep 15 04:37:29 2014
From: loganaden at gmail.com (Loganaden Velvindron)
Date: Sun, 14 Sep 2014 22:37:29 +0400
Subject: New feature discussion: sshd --status
Message-ID: <CAOp4FwQzTbBUaNptyZL3VTDh=TWWsi9Y3J53xx=KOf6pyKOcjg@mail.gmail.com>

Hi All,

I would like to know if there would be any objectionn to having a
--status flag which would be useful to show logged in users. w and who
already do that. The output would go further: show list of forwarded
ports.

I believe that this is useful as netstat output differs from among
different Unix vendors.

Kind regards,
//Logan
C-x-C-c


-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.

From djm at mindrot.org  Mon Sep 15 09:01:57 2014
From: djm at mindrot.org (Damien Miller)
Date: Mon, 15 Sep 2014 09:01:57 +1000 (EST)
Subject: New feature discussion: sshd --status
In-Reply-To: <CAOp4FwQzTbBUaNptyZL3VTDh=TWWsi9Y3J53xx=KOf6pyKOcjg@mail.gmail.com>
References: <CAOp4FwQzTbBUaNptyZL3VTDh=TWWsi9Y3J53xx=KOf6pyKOcjg@mail.gmail.com>
Message-ID: <alpine.BSO.2.11.1409150855120.10472@natsu.mindrot.org>

On Sun, 14 Sep 2014, Loganaden Velvindron wrote:

> Hi All,
>
> I would like to know if there would be any objectionn to having a
> --status flag which would be useful to show logged in users. w and who
> already do that. The output would go further: show list of forwarded
> ports.

Apart from --long_options being frowned upon, there is no single place
that collects all this information. All sshd instances that are handling
connections are completely* independent.

There are arguments for and against making the master listener sshd take
a more active role in the lifecycle of its children.


The main for doing so is that it would allow us to better notice
abnormal termination of sshd processes. E.g. noticing when waitpid()
indicates that child crashed or the connection was closed for too many
authentication attempts. Either of these could be useful signals for
blackholing bad origins.

The main argument against is that it builds more complexity into perhaps
the most critical section of sshd code. If there is a bug in the master
accept loop that causes sshd to crash, then users can no longer log in
via ssh...

-d

* well, after authentication concludes (cf. MaxStartups)

From scott_n at xypro.com  Tue Sep 16 04:06:57 2014
From: scott_n at xypro.com (Scott Neugroschl)
Date: Mon, 15 Sep 2014 18:06:57 +0000
Subject: OpenSSH 6.6  get -a option not shown in help.
Message-ID: <D358E5B1511A314F8160ADC6F375498706961204@XYSVEX02.XYPRO-23.LOCAL>

OpenSSH 6.6

>From the sftp command prompt, the help command does not show the f, a, or R options.

sftp> help
Available commands:
[redacted]
get [-Ppr] remote [local]          Download file

Should read

get [-afPpRr] remote [local]       Download file

---
Scott Neugroschl | XYPRO Technology Corporation
4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 |


From loganaden at gmail.com  Tue Sep 16 04:19:36 2014
From: loganaden at gmail.com (Loganaden Velvindron)
Date: Mon, 15 Sep 2014 22:19:36 +0400
Subject: OpenSSH 6.6 get -a option not shown in help.
In-Reply-To: <D358E5B1511A314F8160ADC6F375498706961204@XYSVEX02.XYPRO-23.LOCAL>
References: <D358E5B1511A314F8160ADC6F375498706961204@XYSVEX02.XYPRO-23.LOCAL>
Message-ID: <CAOp4FwTvQ5+zbu2ObyDcNFsQ=jPTedY3_D6CtHyCRq2uUA8Zfw@mail.gmail.com>

On Mon, Sep 15, 2014 at 10:06 PM, Scott Neugroschl <scott_n at xypro.com> wrote:
> OpenSSH 6.6
>
> From the sftp command prompt, the help command does not show the f, a, or R options.
>
> sftp> help
> Available commands:
> [redacted]
> get [-Ppr] remote [local]          Download file
>
> Should read
>
> get [-afPpRr] remote [local]       Download file
>

Thanks. I'm looking into this !

> ---
> Scott Neugroschl | XYPRO Technology Corporation
> 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 |
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev



-- 
This message is strictly personal and the opinions expressed do not
represent those of my employers, either past or present.

From mancha1 at zoho.com  Tue Sep 16 12:41:03 2014
From: mancha1 at zoho.com (mancha)
Date: Tue, 16 Sep 2014 02:41:03 +0000
Subject: OpenSSH 6.6 get -a option not shown in help.
In-Reply-To: <CAOp4FwTvQ5+zbu2ObyDcNFsQ=jPTedY3_D6CtHyCRq2uUA8Zfw@mail.gmail.com>
References: <D358E5B1511A314F8160ADC6F375498706961204@XYSVEX02.XYPRO-23.LOCAL>
 <CAOp4FwTvQ5+zbu2ObyDcNFsQ=jPTedY3_D6CtHyCRq2uUA8Zfw@mail.gmail.com>
Message-ID: <20140916024103.GA21852@zoho.com>

On Mon, Sep 15, 2014 at 10:19:36PM +0400, Loganaden Velvindron wrote:
> On Mon, Sep 15, 2014 at 10:06 PM, Scott Neugroschl <scott_n at xypro.com>
> wrote:
> > OpenSSH 6.6
> >
> > From the sftp command prompt, the help command does not show the f,
> > a, or R options.
> >
> > sftp> help Available commands: [redacted] get [-Ppr] remote [local]
> > Download file
> >
> > Should read
> >
> > get [-afPpRr] remote [local]       Download file
> >
> 
> Thanks. I'm looking into this !
> 

Unless I missed something, attached diff should harmonize things.

Cheers.

--mancha

-------------- next part --------------
--- a/sftp.c
+++ b/sftp.c
@@ -250,9 +250,9 @@
 	    "df [-hi] [path]                    Display statistics for current directory or\n"
 	    "                                   filesystem containing 'path'\n"
 	    "exit                               Quit sftp\n"
-	    "get [-Ppr] remote [local]          Download file\n"
-	    "reget remote [local]		Resume download file\n"
-	    "reput [local] remote               Resume upload file\n"
+	    "get [-afPpRr] remote [local]       Download file\n"
+	    "reget [-fPpRr] remote [local]	Resume download file\n"
+	    "reput [-fPpRr] [local] remote      Resume upload file\n"
 	    "help                               Display this help text\n"
 	    "lcd path                           Change local directory to 'path'\n"
 	    "lls [ls-options [path]]            Display local directory listing\n"
@@ -263,7 +263,7 @@
 	    "lumask umask                       Set local umask to 'umask'\n"
 	    "mkdir path                         Create remote directory\n"
 	    "progress                           Toggle display of progress meter\n"
-	    "put [-Ppr] local [remote]          Upload file\n"
+	    "put [-afPpRr] local [remote]       Upload file\n"
 	    "pwd                                Display remote working directory\n"
 	    "quit                               Quit sftp\n"
 	    "rename oldpath newpath             Rename remote file\n"
--- a/sftp.1
+++ b/sftp.1
@@ -357,7 +357,7 @@
 Quit
 .Nm sftp .
 .It Xo Ic get
-.Op Fl afPpr
+.Op Fl afPpRr
 .Ar remote-path
 .Op Ar local-path
 .Xc
@@ -399,7 +399,9 @@
 flag is specified, then full file permissions and access times are
 copied too.
 .Pp
-If the
+If either the
+.Fl R
+or
 .Fl r
 flag is specified then directories will be copied recursively.
 Note that
@@ -495,7 +497,7 @@
 .It Ic progress
 Toggle display of progress meter.
 .It Xo Ic put
-.Op Fl afPpr
+.Op Fl afPpRr
 .Ar local-path
 .Op Ar remote-path
 .Xc
@@ -538,7 +540,9 @@
 flag is specified, then full file permissions and access times are
 copied too.
 .Pp
-If the
+If either the
+.Fl R
+or
 .Fl r
 flag is specified then directories will be copied recursively.
 Note that
@@ -550,7 +554,7 @@
 Quit
 .Nm sftp .
 .It Xo Ic reget
-.Op Fl Ppr
+.Op Fl fPpRr
 .Ar remote-path
 .Op Ar local-path
 .Xc
@@ -562,7 +566,7 @@
 .Fl a
 flag set.
 .It Xo Ic reput
-.Op Fl Ppr
+.Op Fl fPpRr
 .Op Ar local-path
 .Ar remote-path
 .Xc
-------------- 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/20140916/cfe42799/attachment.bin>

From Sami.Hartikainen at teleste.com  Fri Sep 19 00:08:53 2014
From: Sami.Hartikainen at teleste.com (Sami.Hartikainen at teleste.com)
Date: Thu, 18 Sep 2014 14:08:53 +0000
Subject: Remote port forwarding in a multiplexed connection: possible
 "clientspecified" bug
Message-ID: <6F84EA015648C0459529AABFB7BF9E02016C9EF143@DAYX.twin.net>

> Now the following mux command (on client with ControlMaster connected
> and running and ControlPath set appropriately):
> 
>     $ ssh -O forward -R ':0:localhost:3502' <hostaddr>
> 
> Port ... (set with an empty bind_address) should be bind to wildcard
> address, not localhost. The same -R option given for ControlMaster (or non-
> multiplexed ssh client) works as expected.

(Answering to myself...)

The reason seems to be that the unset bind_address (i.e. NULL) is transformed
into an empty string in mux.c:mux_client_forward():

	buffer_put_cstring(&m,
	    fwd->listen_host == NULL ? "" : fwd->listen_host);

Separation between an unset and an empty bind_address is now lost; ControlMaster
in turn nullifies such an empty listen_addr, resulting in a localhost bind. This happens
in mux.c:process_mux_open_fwd():

	if (*listen_addr == '\0') {
		free(listen_addr);
		listen_addr = NULL;
	}

I guess this is done because the Buffer (i.e. the underlying sshbuf) does not differentiate
NULL string from an empty one. And NULL is assumed/preferred here because it's safer.

--
Sami


From Sami.Hartikainen at teleste.com  Fri Sep 19 18:49:42 2014
From: Sami.Hartikainen at teleste.com (Sami.Hartikainen at teleste.com)
Date: Fri, 19 Sep 2014 08:49:42 +0000
Subject: Remote port forwarding in a multiplexed connection: possible
 "clientspecified" bug
In-Reply-To: <6F84EA015648C0459529AABFB7BF9E02016C9EF143@DAYX.twin.net>
References: <6F84EA015648C0459529AABFB7BF9E02016C9EF143@DAYX.twin.net>
Message-ID: <6F84EA015648C0459529AABFB7BF9E02016C9EF22C@DAYX.twin.net>

...and the fix could be something like the patch below:

---
 mux.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/mux.c b/mux.c
index 48f7a05..f6ac30c 100644
--- a/mux.c
+++ b/mux.c
@@ -1689,7 +1689,8 @@ mux_client_forward(int fd, int cancel_flag, u_int ftype, struct Forward *fwd)
 		buffer_put_cstring(&m, fwd->listen_path);
 	} else {
 		buffer_put_cstring(&m,
-		    fwd->listen_host == NULL ? "" : fwd->listen_host);
+		    fwd->listen_host == NULL ? "" :
+		    *fwd->listen_host == '\0' ? "*" : fwd->listen_host);
 	}
 	buffer_put_int(&m, fwd->listen_port);
 	if (fwd->connect_path != NULL) {
-- 
1.9.1


From mg at intar.cz  Fri Sep 19 23:22:35 2014
From: mg at intar.cz (Miroslav Geisselreiter)
Date: Fri, 19 Sep 2014 15:22:35 +0200
Subject: compile problem openssh-6.6p1
Message-ID: <541C2E1B.8090601@intar.cz>

Hi all,

First I compile and install openssl-1.0.1i to /opt/openssl and the same 
for zib-1.2.8.
Then I compile openssh-6.6p1 on CentOS 6.5 x86_64.
./configure --prefix=/opt/openssh --with-ssl-dir=/opt/openssl 
--with-xauth=/usr/bin/xauth --with-zlib=/opt/zlib
It stops with this errors:
checking openssl/opensslv.h usability... no
checking openssl/opensslv.h presence... no
checking for openssl/opensslv.h... no
configure: error: *** OpenSSL headers missing - please install first or 
check config.log ***

I think there is something wrong with file "configure" because:
- openssh-6.4p1 compiles fine (v6.5 has the same problem as v6.6)
- when I put file "configure" from v6.4 to v6.6 compiles fine
- when I do yum install openssl-devel (v1.0.1e) and compile v6.6 it uses 
header files from openssl-1.0.1e (and not 1.0.1i from /opt/openssl dir) 
=> it looks like ignoring --with-ssl-dir=/opt/openssl option

Could you please check what is wrong with configure since v6.5? I am not 
programmer but just admin.

Thanks in advance,

Miroslav Geisselreiter
IT administrator / IT manager
support department

INTAR a.s.
Bezru?ova 81/17a
602 00 Brno
Czech Republic

M +420 605 233 487
T +420 543 422 274
F +420 543 211 173
E  mg at intar.cz
W  www.intar.cz


From scott_n at xypro.com  Sat Sep 20 01:43:36 2014
From: scott_n at xypro.com (Scott Neugroschl)
Date: Fri, 19 Sep 2014 15:43:36 +0000
Subject: compile problem openssh-6.6p1
In-Reply-To: <541C2E1B.8090601@intar.cz>
References: <541C2E1B.8090601@intar.cz>
Message-ID: <D358E5B1511A314F8160ADC6F375498706961A4D@XYSVEX02.XYPRO-23.LOCAL>

> First I compile and install openssl-1.0.1i to /opt/openssl and the same for zib-1.2.8.
> Then I compile openssh-6.6p1 on CentOS 6.5 x86_64.
> ./configure --prefix=/opt/openssh --with-ssl-dir=/opt/openssl --with-xauth=/usr/bin/xauth --with-zlib=/opt/zlib It stops with this errors:
> checking openssl/opensslv.h usability... no checking openssl/opensslv.h presence... no checking for openssl/opensslv.h... no
> configure: error: *** OpenSSL headers missing - please install first or check config.log ***
> 
> I think there is something wrong with file "configure" because:
> - openssh-6.4p1 compiles fine (v6.5 has the same problem as v6.6)
> - when I put file "configure" from v6.4 to v6.6 compiles fine
> - when I do yum install openssl-devel (v1.0.1e) and compile v6.6 it uses header files from openssl-1.0.1e (and not 1.0.1i from /opt/openssl dir) => it looks like ignoring --with-ssl-dir=/opt/openssl option
> 
> Could you please check what is wrong with configure since v6.5? I am not programmer but just admin.

I've ran into this too.  I believe that configure automatically checks /usr/local for OpenSSL, even if you specify -with-ssl-dir.  IMHO this is a bug with configure.
The same thing happens with ZLIB.

From hasa100 at hotmail.com  Mon Sep 22 23:33:19 2014
From: hasa100 at hotmail.com (Sami Hartikainen)
Date: Mon, 22 Sep 2014 16:33:19 +0300
Subject: Patch to Prevent client from not opening channel
Message-ID: <DUB123-W347F21F0033E45D71AFC38E5B30@phx.gbl>

>i had the problem that it wasn't possible to prevent the client from not
>opening a channel.
>This is necessary for me because i have written a custom shell which is
>doing some cleanup work after the connection is closed, which is not
>possible in case the shell isn't started at all.

Are you actually attempting to deny a connection without running a *remote command* -- e.g. the custom shell you mention?

If this is the case, clearing the alarm in channel_post_open() will not enforce that. Consider this: if the client opens a connection and just sets up port forwarding channel(s), the channel_post_open() gets called when such a forwarding channel is opened for communication with whatever is on those forwarded ports. 

--
Sami 		 	   		  

From palmer at dabbelt.com  Tue Sep 23 08:33:30 2014
From: palmer at dabbelt.com (Palmer Dabbelt)
Date: Mon, 22 Sep 2014 15:33:30 -0700
Subject: [PATCH] Allow the TERM env variable to be overwritten by .ssh/config
In-Reply-To: <1411425210-22584-1-git-send-email-palmer@dabbelt.com>
References: <1411425210-22584-1-git-send-email-palmer@dabbelt.com>
Message-ID: <1411425210-22584-2-git-send-email-palmer@dabbelt.com>

I run urxvt, but I have some hosts that have an older terminal info
database that don't support the "rxvt-unicode-256color" string that my
terminal exports.  Many applications just fail to open when faced with
an unknown TERM string, which is a huge pain.

This patch allows me to specify what TERM should be for each host in
my .ssh/config.  This allows me to override TERM differently on each
host depending on their level of support for my TERM variable (either
rxvt-unicode, rxvt, or xterm).

There are a number of posts referencing this lack of feature on the
Internet along with some workarounds, but I think this is cleaner.
---
 readconf.c |  8 +++++++-
 readconf.h |  2 ++
 ssh.c      | 11 +++++++++--
 3 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/readconf.c b/readconf.c
index dc884c9..db85a25 100644
--- a/readconf.c
+++ b/readconf.c
@@ -129,7 +129,7 @@ typedef enum {
 	oPasswordAuthentication, oRSAAuthentication,
 	oChallengeResponseAuthentication, oXAuthLocation,
 	oIdentityFile, oHostName, oPort, oCipher, oRemoteForward, oLocalForward,
-	oUser, oEscapeChar, oRhostsRSAAuthentication, oProxyCommand,
+	oUser, oEscapeChar, oRhostsRSAAuthentication, oProxyCommand, oTerm,
 	oGlobalKnownHostsFile, oUserKnownHostsFile, oConnectionAttempts,
 	oBatchMode, oCheckHostIP, oStrictHostKeyChecking, oCompression,
 	oCompressionLevel, oTCPKeepAlive, oNumberOfPasswordPrompts,
@@ -196,6 +196,7 @@ static struct {
 	{ "hostname", oHostName },
 	{ "hostkeyalias", oHostKeyAlias },
 	{ "proxycommand", oProxyCommand },
+	{ "term", oTerm },
 	{ "port", oPort },
 	{ "cipher", oCipher },
 	{ "ciphers", oCiphers },
@@ -994,6 +995,10 @@ parse_command:
 			*charptr = xstrdup(s + len);
 		return 0;
 
+	case oTerm:
+		charptr = &options->term;
+		goto parse_string;
+
 	case oPort:
 		intptr = &options->port;
 parse_int:
@@ -1568,6 +1573,7 @@ initialize_options(Options * options)
 	options->canonicalize_max_dots = -1;
 	options->canonicalize_fallback_local = -1;
 	options->canonicalize_hostname = -1;
+	options->term = NULL;
 }
 
 /*
diff --git a/readconf.h b/readconf.h
index 75e3f8f..883bfed 100644
--- a/readconf.h
+++ b/readconf.h
@@ -104,6 +104,8 @@ typedef struct {
 	int    identity_file_userprovided[SSH_MAX_IDENTITY_FILES];
 	Key    *identity_keys[SSH_MAX_IDENTITY_FILES];
 
+	char   *term;	/* TERM to send to the server, or NULL if getenv("TERM") is used */
+
 	/* Local TCP/IP forward requests. */
 	int     num_local_forwards;
 	Forward *local_forwards;
diff --git a/ssh.c b/ssh.c
index 1e6cb90..c19ed46 100644
--- a/ssh.c
+++ b/ssh.c
@@ -1439,7 +1439,10 @@ ssh_session(void)
 
 		/* Store TERM in the packet.  There is no limit on the
 		   length of the string. */
-		cp = getenv("TERM");
+		cp = options.term;
+		fprintf(stderr, "stored term: '%s'\n", cp);
+		if (!cp)
+			cp = getenv("TERM");
 		if (!cp)
 			cp = "";
 		packet_put_cstring(cp);
@@ -1568,6 +1571,7 @@ ssh_session2_setup(int id, int success, void *arg)
 {
 	extern char **environ;
 	const char *display;
+	char *term;
 	int interactive = tty_flag;
 
 	if (!success)
@@ -1601,7 +1605,10 @@ 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"),
+	term = options.term;
+	if (!term)
+		term = getenv("TERM");
+	client_session2_setup(id, tty_flag, subsystem_flag, term,
 	    NULL, fileno(stdin), &command, environ);
 }
 
-- 
1.8.5.5


From palmer at dabbelt.com  Tue Sep 23 08:33:29 2014
From: palmer at dabbelt.com (Palmer Dabbelt)
Date: Mon, 22 Sep 2014 15:33:29 -0700
Subject: Allow the TERM env variable to be overwritten by .ssh/config
Message-ID: <1411425210-22584-1-git-send-email-palmer@dabbelt.com>

This is pretty much the same request as an old mailing list thread

http://marc.info/?l=openssh-unix-dev&m=134073696320230&w=2

for almost exactly the same reason: some machines don't have
new-enough terminal info databases to support newer TERM strings
("rxvt-unicode-256color" in my case).  As such, I'd like to be able to
override the TERM that is forwarded to some machines from my
.ssh/config.

The solutions proposed in that post don't work well for me because I
like having a shared .bashrc and don't want to go making it super long
just to have a big list of hosts that don't support "*-256color".

Following is a git-formatted patch to implement this feature.  It's
based against the 6.6-p1 tarballs as I'm not really sure what else to
base it against.  Hopefully that's OK?


From carson at taltos.org  Tue Sep 23 09:22:26 2014
From: carson at taltos.org (Carson Gaspar)
Date: Mon, 22 Sep 2014 16:22:26 -0700
Subject: Allow the TERM env variable to be overwritten by .ssh/config
In-Reply-To: <1411425210-22584-1-git-send-email-palmer@dabbelt.com>
References: <1411425210-22584-1-git-send-email-palmer@dabbelt.com>
Message-ID: <5420AF32.3040704@taltos.org>

On 9/22/2014 3:33 PM, Palmer Dabbelt wrote:
> This is pretty much the same request as an old mailing list thread
>
> http://marc.info/?l=openssh-unix-dev&m=134073696320230&w=2
[*snip*]
> The solutions proposed in that post don't work well for me because I
> like having a shared .bashrc and don't want to go making it super long
> just to have a big list of hosts that don't support "*-256color".

I don't like your patch as-is. If ssh needs something like this, it 
should be generic to any env var, not TERM specific. And then one could 
argue that a shell wrapper function could do the same thing (but 
wouldn't have identical destination parsing rules and would need config 
to live elsewhere, so there is some value in having such functionality 
in ssh itself).

Put something like this in your shell startup on the destination hosts 
to avoid maintaining a host list anywhere or patching ssh:

# Optionally wrap in "if test -t 1" to only bother on a TTY
local TRYTERMLIST=''
case "$TERM" in
   'rxvt-unicode-256color')
     TRYTERMLIST='rxvt-unicode-256color rxvt-256color xterm'
     ;;
esac
if test -n "$TRYTERMLIST" && test -x "$(type -P infocmp)"; then
   local T
   for T in $TRYTERMLIST; do
     if infocmp "$T" >/dev/null 2>&1; then
       export TERM="$T"
       break
     fi
   done
fi

Or, given that you appear to have a shared/dist'd home directory, just 
copy the correct terminfo file(s) into your home dir and set TERMINFO.

-- 
Carson


From scott_n at xypro.com  Tue Sep 23 09:40:31 2014
From: scott_n at xypro.com (Scott Neugroschl)
Date: Mon, 22 Sep 2014 23:40:31 +0000
Subject: transfer.sh
Message-ID: <D358E5B1511A314F8160ADC6F37549870696CE28@XYSVEX02.XYPRO-23.LOCAL>

When I run "make tests" with OpenSSH 6.6p1 , it fails transfer.sh

It looks to me like it's barfing on the host name "somehost".

I've looked throughout the regress subdir and can't quite see where "somehost" gets replaced with a real host name.

---
Scott Neugroschl | XYPRO Technology Corporation
4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 |


From imorgan at nas.nasa.gov  Tue Sep 23 12:06:51 2014
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Mon, 22 Sep 2014 19:06:51 -0700
Subject: Allow the TERM env variable to be overwritten by .ssh/config
In-Reply-To: <1411425210-22584-1-git-send-email-palmer@dabbelt.com>
References: <1411425210-22584-1-git-send-email-palmer@dabbelt.com>
Message-ID: <20140923020651.GA6678@linux124.nas.nasa.gov>

On Mon, Sep 22, 2014 at 15:33:29 -0700, Palmer Dabbelt wrote:
> This is pretty much the same request as an old mailing list thread
> 
> http://marc.info/?l=openssh-unix-dev&m=134073696320230&w=2
> 
> for almost exactly the same reason: some machines don't have
> new-enough terminal info databases to support newer TERM strings
> ("rxvt-unicode-256color" in my case).  As such, I'd like to be able to
> override the TERM that is forwarded to some machines from my
> .ssh/config.
> 
> The solutions proposed in that post don't work well for me because I
> like having a shared .bashrc and don't want to go making it super long
> just to have a big list of hosts that don't support "*-256color".
> 

Perhaps you could use tput to test for terminal capabilities rather than
keeping a list of hosts.

I've had to deal with a somewhat different issue; preferring to suppress
color support. I used to use "tput colors" to test for the number of
colors supported, and re-define TERM as needed. More recently, I taken
to simply overriding the terminfo definitions for those terminal types
that I use by creating a ~/.terminfo directory or ~/.terminfo.db
database.

-- 
Iain Morgan

From palmer at dabbelt.com  Tue Sep 23 13:35:06 2014
From: palmer at dabbelt.com (Palmer Dabbelt)
Date: Mon, 22 Sep 2014 20:35:06 -0700 (PDT)
Subject: Allow the TERM env variable to be overwritten by .ssh/config
In-Reply-To: <20140923020651.GA6678@linux124.nas.nasa.gov>
Message-ID: <5420ea6a.1022460a.4912.05d8@mx.google.com>

On Mon, 22 Sep 2014 19:06:51 PDT (-0700), imorgan at nas.nasa.gov wrote:
> On Mon, Sep 22, 2014 at 15:33:29 -0700, Palmer Dabbelt wrote:
> > This is pretty much the same request as an old mailing list thread
> >
> > http://marc.info/?l=openssh-unix-dev&m=134073696320230&w=2
> >
> > for almost exactly the same reason: some machines don't have
> > new-enough terminal info databases to support newer TERM strings
> > ("rxvt-unicode-256color" in my case).  As such, I'd like to be able to
> > override the TERM that is forwarded to some machines from my
> > .ssh/config.
> >
> > The solutions proposed in that post don't work well for me because I
> > like having a shared .bashrc and don't want to go making it super long
> > just to have a big list of hosts that don't support "*-256color".
> >
> 
> Perhaps you could use tput to test for terminal capabilities rather than
> keeping a list of hosts.
> 
> I've had to deal with a somewhat different issue; preferring to suppress
> color support. I used to use "tput colors" to test for the number of
> colors supported, and re-define TERM as needed. More recently, I taken
> to simply overriding the terminfo definitions for those terminal types
> that I use by creating a ~/.terminfo directory or ~/.terminfo.db
> database.

These are all hosts that are managed by the university, so I've got to
have some username overrides in there anyway.  This way just seemed
like the path of least resistance.

Just doing a "tput colors" doesn't seem to do it for me:

$ tput colors
tput: unknown terminal "rxvt-unicode-256color"

I could just check for a "tput" failure and redefine the terminal, I
don't really like overriding TERM because I worry about how it'll
interact with screen and such.

I think overriding the terminfo database is probably the best way to
do this, I didn't know that was possible!  Unfortunately it doesn't
appear to work on OSX, but that might just be user error...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20140922/1da32bd0/attachment.bin>

From imorgan at nas.nasa.gov  Wed Sep 24 04:01:02 2014
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Tue, 23 Sep 2014 11:01:02 -0700
Subject: Allow the TERM env variable to be overwritten by .ssh/config
In-Reply-To: <5420ea6a.1022460a.4912.05d8@mx.google.com>
References: <20140923020651.GA6678@linux124.nas.nasa.gov>
 <5420ea6a.1022460a.4912.05d8@mx.google.com>
Message-ID: <20140923180102.GH6668@linux124.nas.nasa.gov>

On Mon, Sep 22, 2014 at 20:35:06 -0700, Palmer Dabbelt wrote:
> On Mon, 22 Sep 2014 19:06:51 PDT (-0700), imorgan at nas.nasa.gov wrote:
> > On Mon, Sep 22, 2014 at 15:33:29 -0700, Palmer Dabbelt wrote:
> > > This is pretty much the same request as an old mailing list thread
> > >
> > > http://marc.info/?l=openssh-unix-dev&m=134073696320230&w=2
> > >
> > > for almost exactly the same reason: some machines don't have
> > > new-enough terminal info databases to support newer TERM strings
> > > ("rxvt-unicode-256color" in my case).  As such, I'd like to be able to
> > > override the TERM that is forwarded to some machines from my
> > > .ssh/config.
> > >
> > > The solutions proposed in that post don't work well for me because I
> > > like having a shared .bashrc and don't want to go making it super long
> > > just to have a big list of hosts that don't support "*-256color".
> > >
> > 
> > Perhaps you could use tput to test for terminal capabilities rather than
> > keeping a list of hosts.
> > 
> > I've had to deal with a somewhat different issue; preferring to suppress
> > color support. I used to use "tput colors" to test for the number of
> > colors supported, and re-define TERM as needed. More recently, I taken
> > to simply overriding the terminfo definitions for those terminal types
> > that I use by creating a ~/.terminfo directory or ~/.terminfo.db
> > database.
> 
> These are all hosts that are managed by the university, so I've got to
> have some username overrides in there anyway.  This way just seemed
> like the path of least resistance.
> 
> Just doing a "tput colors" doesn't seem to do it for me:
> 
> $ tput colors
> tput: unknown terminal "rxvt-unicode-256color"
> 
> I could just check for a "tput" failure and redefine the terminal, I
> don't really like overriding TERM because I worry about how it'll
> interact with screen and such.
> 
> I think overriding the terminfo database is probably the best way to
> do this, I didn't know that was possible!  Unfortunately it doesn't
> appear to work on OSX, but that might just be user error...

OS X may need a ~/.terminfo.db file rather than a ~/.terminfo directory.
On Linux (RHEL and SLES) ~/.terminfo works, whereas on OpenBSD you need
~/.terminfo.db. I haven't experimented with OS X.

-- 
Iain Morgan

From nicholas.marriott at gmail.com  Wed Sep 24 08:34:40 2014
From: nicholas.marriott at gmail.com (Nicholas Marriott)
Date: Tue, 23 Sep 2014 23:34:40 +0100
Subject: Allow the TERM env variable to be overwritten by .ssh/config
In-Reply-To: <20140923180102.GH6668@linux124.nas.nasa.gov>
References: <20140923020651.GA6678@linux124.nas.nasa.gov>
 <5420ea6a.1022460a.4912.05d8@mx.google.com>
 <20140923180102.GH6668@linux124.nas.nasa.gov>
Message-ID: <20140923223440.GA19299@yelena>

Hi

.terminfo/ should work on OpenBSD too (as well as .terminfo.db), at
least it does on -current and I don't remember any recent changes.


On Tue, Sep 23, 2014 at 11:01:02AM -0700, Iain Morgan wrote:
> On Mon, Sep 22, 2014 at 20:35:06 -0700, Palmer Dabbelt wrote:
> > On Mon, 22 Sep 2014 19:06:51 PDT (-0700), imorgan at nas.nasa.gov wrote:
> > > On Mon, Sep 22, 2014 at 15:33:29 -0700, Palmer Dabbelt wrote:
> > > > This is pretty much the same request as an old mailing list thread
> > > >
> > > > http://marc.info/?l=openssh-unix-dev&m=134073696320230&w=2
> > > >
> > > > for almost exactly the same reason: some machines don't have
> > > > new-enough terminal info databases to support newer TERM strings
> > > > ("rxvt-unicode-256color" in my case).  As such, I'd like to be able to
> > > > override the TERM that is forwarded to some machines from my
> > > > .ssh/config.
> > > >
> > > > The solutions proposed in that post don't work well for me because I
> > > > like having a shared .bashrc and don't want to go making it super long
> > > > just to have a big list of hosts that don't support "*-256color".
> > > >
> > > 
> > > Perhaps you could use tput to test for terminal capabilities rather than
> > > keeping a list of hosts.
> > > 
> > > I've had to deal with a somewhat different issue; preferring to suppress
> > > color support. I used to use "tput colors" to test for the number of
> > > colors supported, and re-define TERM as needed. More recently, I taken
> > > to simply overriding the terminfo definitions for those terminal types
> > > that I use by creating a ~/.terminfo directory or ~/.terminfo.db
> > > database.
> > 
> > These are all hosts that are managed by the university, so I've got to
> > have some username overrides in there anyway.  This way just seemed
> > like the path of least resistance.
> > 
> > Just doing a "tput colors" doesn't seem to do it for me:
> > 
> > $ tput colors
> > tput: unknown terminal "rxvt-unicode-256color"
> > 
> > I could just check for a "tput" failure and redefine the terminal, I
> > don't really like overriding TERM because I worry about how it'll
> > interact with screen and such.
> > 
> > I think overriding the terminfo database is probably the best way to
> > do this, I didn't know that was possible!  Unfortunately it doesn't
> > appear to work on OSX, but that might just be user error...
> 
> OS X may need a ~/.terminfo.db file rather than a ~/.terminfo directory.
> On Linux (RHEL and SLES) ~/.terminfo works, whereas on OpenBSD you need
> ~/.terminfo.db. I haven't experimented with OS X.
> 
> -- 
> Iain Morgan
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From imorgan at nas.nasa.gov  Wed Sep 24 09:48:47 2014
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Tue, 23 Sep 2014 16:48:47 -0700
Subject: Allow the TERM env variable to be overwritten by .ssh/config
In-Reply-To: <20140923223440.GA19299@yelena>
References: <20140923020651.GA6678@linux124.nas.nasa.gov>
 <5420ea6a.1022460a.4912.05d8@mx.google.com>
 <20140923180102.GH6668@linux124.nas.nasa.gov>
 <20140923223440.GA19299@yelena>
Message-ID: <20140923234847.GM6668@linux124.nas.nasa.gov>

Interesting... I used to use ~/.terminfo/ on OpenBSD, but when I
upgraded to 5.4 (skipping several releases), it stopped working. That is
when I switched to ~/.terminfo.db. I'll have to check when I next
upgrade.

-- 
Iain

On Tue, Sep 23, 2014 at 23:34:40 +0100, Nicholas Marriott wrote:
> Hi
> 
> .terminfo/ should work on OpenBSD too (as well as .terminfo.db), at
> least it does on -current and I don't remember any recent changes.
> 
> 
> On Tue, Sep 23, 2014 at 11:01:02AM -0700, Iain Morgan wrote:
> > On Mon, Sep 22, 2014 at 20:35:06 -0700, Palmer Dabbelt wrote:
> > > On Mon, 22 Sep 2014 19:06:51 PDT (-0700), imorgan at nas.nasa.gov wrote:
> > > > On Mon, Sep 22, 2014 at 15:33:29 -0700, Palmer Dabbelt wrote:
> > > > > This is pretty much the same request as an old mailing list thread
> > > > >
> > > > > http://marc.info/?l=openssh-unix-dev&m=134073696320230&w=2
> > > > >
> > > > > for almost exactly the same reason: some machines don't have
> > > > > new-enough terminal info databases to support newer TERM strings
> > > > > ("rxvt-unicode-256color" in my case).  As such, I'd like to be able to
> > > > > override the TERM that is forwarded to some machines from my
> > > > > .ssh/config.
> > > > >
> > > > > The solutions proposed in that post don't work well for me because I
> > > > > like having a shared .bashrc and don't want to go making it super long
> > > > > just to have a big list of hosts that don't support "*-256color".
> > > > >
> > > > 
> > > > Perhaps you could use tput to test for terminal capabilities rather than
> > > > keeping a list of hosts.
> > > > 
> > > > I've had to deal with a somewhat different issue; preferring to suppress
> > > > color support. I used to use "tput colors" to test for the number of
> > > > colors supported, and re-define TERM as needed. More recently, I taken
> > > > to simply overriding the terminfo definitions for those terminal types
> > > > that I use by creating a ~/.terminfo directory or ~/.terminfo.db
> > > > database.
> > > 
> > > These are all hosts that are managed by the university, so I've got to
> > > have some username overrides in there anyway.  This way just seemed
> > > like the path of least resistance.
> > > 
> > > Just doing a "tput colors" doesn't seem to do it for me:
> > > 
> > > $ tput colors
> > > tput: unknown terminal "rxvt-unicode-256color"
> > > 
> > > I could just check for a "tput" failure and redefine the terminal, I
> > > don't really like overriding TERM because I worry about how it'll
> > > interact with screen and such.
> > > 
> > > I think overriding the terminfo database is probably the best way to
> > > do this, I didn't know that was possible!  Unfortunately it doesn't
> > > appear to work on OSX, but that might just be user error...
> > 
> > OS X may need a ~/.terminfo.db file rather than a ~/.terminfo directory.
> > On Linux (RHEL and SLES) ~/.terminfo works, whereas on OpenBSD you need
> > ~/.terminfo.db. I haven't experimented with OS X.
> > 
> > -- 
> > Iain Morgan
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev at mindrot.org
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

-- 
Iain Morgan

From plautrba at redhat.com  Thu Sep 25 00:30:20 2014
From: plautrba at redhat.com (Petr Lautrbach)
Date: Wed, 24 Sep 2014 16:30:20 +0200
Subject: AuthenticationMethods in sshd_config accepting empty method list
In-Reply-To: <53A2DE11.9000100@redhat.com>
References: <53A2DE11.9000100@redhat.com>
Message-ID: <20140924143019.GA13410@hulk.w.lan>

On Thu, Jun 19, 2014 at 02:56:49PM +0200, mvadkert wrote:
> Hi everyone,
> 
> I just came across a contradiction between the man page of AuthenticationMethods and the accepted
> methods list.
> 
> According to the sshd_config manual page:
> """
> AuthenticationMethods
> 
> Specifies the authentication methods that must be successfully completed for a user to be granted
> access. This option must be followed by one or more comma-separated lists of authentication method
> names. Successful authentication requires completion of every method in at least one of these lists.
> """"
> 
> But in reality the also an empty list is accepted by sshd (servconf.c:1605).
> 
> What is the reason to accept an empty method list? Does the man page need an update?
> 

Hi,

I believe that this is a bug in the parsing code which doesn't handle empty list correctly. The following patch
fixes it.

--- a/servconf.c
+++ b/servconf.c
@@ -1630,6 +1630,8 @@ process_server_config_line(ServerOptions *options, char *line,
                break;
 
        case sAuthenticationMethods:
+               if (cp == NULL || *cp == '\0')
+                       fatal("%.200s line %d: Missing argument.", filename, linenum);
                if (*activep && options->num_auth_methods == 0) {
                        while ((arg = strdelim(&cp)) && *arg != '\0') {
                                if (options->num_auth_methods >=


-- 
Petr Lautrbach

From mancha1 at zoho.com  Thu Sep 25 01:34:08 2014
From: mancha1 at zoho.com (mancha)
Date: Wed, 24 Sep 2014 15:34:08 +0000
Subject: Bash vuln. can affect OpenSSH
Message-ID: <20140924153408.GA29511@zoho.com>

This is a friendly heads up regarding a recently-disclosed Bash
vulnerability that can impact behavior in the context of OpenSSH
connections (CVE-2014-6271).

In sum, the vulnerability relates to a flaw in Bash's evaluation of
environment variables such that attackers can use specially-crafted
environment variables for code injection [1].

For example, server-side OpenSSH restrictions might be bypassed with
maliciously-crafted TERM or SSH_ORIGINAL_COMMAND variables.

Bash has issued patches to fix this issue:

http://ftp.gnu.org/pub/gnu/bash/bash-3.0-patches/bash30-017
http://ftp.gnu.org/pub/gnu/bash/bash-3.1-patches/bash31-018
http://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-052
http://ftp.gnu.org/pub/gnu/bash/bash-4.0-patches/bash40-039
http://ftp.gnu.org/pub/gnu/bash/bash-4.1-patches/bash41-012
http://ftp.gnu.org/pub/gnu/bash/bash-4.2-patches/bash42-048
http://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-025

--mancha

[1] https://securityblog.redhat.com/2014/09/24/bash-specially-crafted-environment-variables-code-injection-attack/
-------------- 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/20140924/49a88df6/attachment.bin>

From lionelcons1972 at gmail.com  Thu Sep 25 01:49:37 2014
From: lionelcons1972 at gmail.com (Lionel Cons)
Date: Wed, 24 Sep 2014 17:49:37 +0200
Subject: Bash vuln. can affect OpenSSH
In-Reply-To: <20140924153408.GA29511@zoho.com>
References: <20140924153408.GA29511@zoho.com>
Message-ID: <CAPJSo4VS8gm7CXpFGwE=eA38mj6UCrqTKTtRtSsUy5TK2Zbx5w@mail.gmail.com>

On 24 September 2014 17:34, mancha <mancha1 at zoho.com> wrote:
> This is a friendly heads up regarding a recently-disclosed Bash
> vulnerability that can impact behavior in the context of OpenSSH
> connections (CVE-2014-6271).
>
> In sum, the vulnerability relates to a flaw in Bash's evaluation of
> environment variables such that attackers can use specially-crafted
> environment variables for code injection [1].
>
> For example, server-side OpenSSH restrictions might be bypassed with
> maliciously-crafted TERM or SSH_ORIGINAL_COMMAND variables.
>
> Bash has issued patches to fix this issue:
>
> http://ftp.gnu.org/pub/gnu/bash/bash-3.0-patches/bash30-017
> http://ftp.gnu.org/pub/gnu/bash/bash-3.1-patches/bash31-018
> http://ftp.gnu.org/pub/gnu/bash/bash-3.2-patches/bash32-052
> http://ftp.gnu.org/pub/gnu/bash/bash-4.0-patches/bash40-039
> http://ftp.gnu.org/pub/gnu/bash/bash-4.1-patches/bash41-012
> http://ftp.gnu.org/pub/gnu/bash/bash-4.2-patches/bash42-048
> http://ftp.gnu.org/pub/gnu/bash/bash-4.3-patches/bash43-025

A better fix is to switch to /usr/bin/ksh (AT&T ksh93) - it has been
designed and written with security in mind and has better automated
testing coverage than bash (which is a shame, but then the UNIX
enterprise is ruled by ksh93, not bash).

Lionel

From bamamorgans at gmail.com  Sat Sep 27 06:01:49 2014
From: bamamorgans at gmail.com (Todd Morgan)
Date: Fri, 26 Sep 2014 15:01:49 -0500
Subject: Port Forward Limit?
Message-ID: <CAAx=oh0_MPr_-MWMsg5CH3zDzssoSB3u-WRsRyghXVX0pT7Hig@mail.gmail.com>

At my company we use port forwarding as an alternative to VPN. In previous
releases of openssh (pre 6.0) we could run a script and fetch the thousands
of forwards to our local machine to connect to remote machines. Since
openssh 6.x, whenever we run the same script we get a bufferoverflow error.

----
debug1: channel 4577: new [port listener]
debug1: channel 4578: new [client-session]
debug1: Requesting no-more-sessions at openssh.com
debug1: Entering interactive session.
*** buffer overflow detected ***: ssh terminated
======= Backtrace: =========
/lib64/libc.so.6(__fortify_fail+0x37)[0x7f3516baf8f7]
/lib64/libc.so.6(+0x10bac0)[0x7f3516badac0]
/lib64/libc.so.6(+0x10d867)[0x7f3516baf867]
ssh(+0x26825)[0x7f3519304825]
ssh(+0x2aece)[0x7f3519308ece]
ssh(+0x12d05)[0x7f35192f0d05]
ssh(+0xb3ee)[0x7f35192e93ee]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f3516ac3af5]
ssh(+0xc289)[0x7f35192ea289]
 ----

I assume this is a security measure to thwart overflow attacks. I've tried
utilizing multiplexing, but received the same type of buffer overflow.

Are there any settings that I can change to allow for more forwards? At the
moment we have a work around to only pull back ports in batches but that
isn't a long term solution.

Any advice would be appreciated. Thanks

-Todd Morgan

From mail at eworm.de  Sat Sep 27 07:00:47 2014
From: mail at eworm.de (Christian Hesse)
Date: Fri, 26 Sep 2014 23:00:47 +0200
Subject: Port Forward Limit?
In-Reply-To: <CAAx=oh0_MPr_-MWMsg5CH3zDzssoSB3u-WRsRyghXVX0pT7Hig@mail.gmail.com>
References: <CAAx=oh0_MPr_-MWMsg5CH3zDzssoSB3u-WRsRyghXVX0pT7Hig@mail.gmail.com>
Message-ID: <20140926230047.4fd59318@leda.localdomain>

Todd Morgan <bamamorgans at gmail.com> on Fri, 2014/09/26 15:01:
> At my company we use port forwarding as an alternative to VPN. In previous
> releases of openssh (pre 6.0) we could run a script and fetch the thousands
> of forwards to our local machine to connect to remote machines. Since
> openssh 6.x, whenever we run the same script we get a bufferoverflow error.

Did not take a look at you issue, but (if I understand your needs
correctly) using sshuttle [0] may be an option.

Buffer overflow should not occur, though...

[0] https://github.com/apenwarr/sshuttle
-- 
Schoene Gruesse
Chris
                         O< ascii ribbon campaign
                   stop html mail - www.asciiribbon.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20140926/42e16b3e/attachment-0001.bin>

From scott_n at xypro.com  Sat Sep 27 07:12:54 2014
From: scott_n at xypro.com (Scott Neugroschl)
Date: Fri, 26 Sep 2014 21:12:54 +0000
Subject: DSA 2048 bit keys?
Message-ID: <D358E5B1511A314F8160ADC6F3754987069705F5@XYSVEX02.XYPRO-23.LOCAL>

Is there a reason ssh-keygen restricts DSA keys to exactly 1024 bits, given that NIST is recommending a minimum of 2048?

http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf



---
Scott Neugroschl | XYPRO Technology Corporation
4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 |


From bamamorgans at gmail.com  Sat Sep 27 07:12:20 2014
From: bamamorgans at gmail.com (Todd Morgan)
Date: Fri, 26 Sep 2014 21:12:20 +0000
Subject: Port Forward Limit?
In-Reply-To: <CAAx=oh2WztCEpZ2in2ntQ2VraD11ZSixKFP_LtH0kBdm1cJGQQ@mail.gmail.com>
References: <CAAx=oh0_MPr_-MWMsg5CH3zDzssoSB3u-WRsRyghXVX0pT7Hig@mail.gmail.com>
 <20140926230047.4fd59318@leda.localdomain>
 <CAAx=oh2WztCEpZ2in2ntQ2VraD11ZSixKFP_LtH0kBdm1cJGQQ@mail.gmail.com>
Message-ID: <CAAx=oh0f2zhJHwWS8axzknTZYz1eCjL0oBYtPJboDheLHUk4+A@mail.gmail.com>

We have our own internal set of utilities, we'll call it "myssh." We have
one central server that receives ssh connections from client servers. Each
client server is then associated with a port on that central server. myssh
(just a wrapper around ssh) pulls back all of the ports to in use to our
local machine. Each port is then associated with a hostname. So we just use
the utility in place of ssh and it maps the port.


So instead of "ssh -p 12345 localhost" it would be "myssh client.server.com"

One of the switches for "myssh" allows us to pull ports for a group of
servers instead of all of them. If we use that switch and pull back a few
hundred at a time, we're fine. It looks like it has a problem right around
2300 ports.

On Fri, Sep 26, 2014 at 9:11 PM, Todd Morgan <bamamorgans at gmail.com> wrote:

> We have our own internal set of utilities, we'll call it "myssh." We have
> one central server that receives ssh connections from client servers. Each
> client server is then associated with a port on that central server. myssh
> (just a wrapper around ssh) pulls back all of the ports to in use to our
> local machine. Each port is then associated with a hostname. So we just use
> the utility in place of ssh and it maps the port.
>
>
> So instead of "ssh -p 12345 localhost" it would be "myssh
> client.server.com"
>
> One of the switches for "myssh" allows us to pull ports for a group of
> servers instead of all of them. If we use that switch and pull back a few
> hundred at a time, we're fine. It looks like it has a problem right around
> 2300 ports.
>
> On Fri, Sep 26, 2014 at 9:00 PM, Christian Hesse <mail at eworm.de> wrote:
>
>> Todd Morgan <bamamorgans at gmail.com> on Fri, 2014/09/26 15:01:
>> > At my company we use port forwarding as an alternative to VPN. In
>> previous
>> > releases of openssh (pre 6.0) we could run a script and fetch the
>> thousands
>> > of forwards to our local machine to connect to remote machines. Since
>> > openssh 6.x, whenever we run the same script we get a bufferoverflow
>> error.
>>
>> Did not take a look at you issue, but (if I understand your needs
>> correctly) using sshuttle [0] may be an option.
>>
>> Buffer overflow should not occur, though...
>>
>> [0] https://github.com/apenwarr/sshuttle
>> --
>> Schoene Gruesse
>> Chris
>>                          O< ascii ribbon campaign
>>                    stop html mail - www.asciiribbon.org
>>
>
>

From dtucker at zip.com.au  Sat Sep 27 07:38:21 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 26 Sep 2014 17:38:21 -0400
Subject: DSA 2048 bit keys?
In-Reply-To: <D358E5B1511A314F8160ADC6F3754987069705F5@XYSVEX02.XYPRO-23.LOCAL>
References: <D358E5B1511A314F8160ADC6F3754987069705F5@XYSVEX02.XYPRO-23.LOCAL>
Message-ID: <CALDDTe3CGqE36smkxC87JB_aNhyw8zqvwMt9iZiuDYgyOor2jQ@mail.gmail.com>

On Fri, Sep 26, 2014 at 5:12 PM, Scott Neugroschl <scott_n at xypro.com> wrote:

> Is there a reason ssh-keygen restricts DSA keys to exactly 1024 bits,
> given that NIST is recommending a minimum of 2048?
>

NIST also requires that DSA keys longer than 1024 bits use a hash stronger
than SHA1 while the SSH RFC require the use of SHA1.

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

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

From djm at mindrot.org  Sat Sep 27 07:51:32 2014
From: djm at mindrot.org (Damien Miller)
Date: Sat, 27 Sep 2014 07:51:32 +1000 (EST)
Subject: Port Forward Limit?
In-Reply-To: <CAAx=oh0_MPr_-MWMsg5CH3zDzssoSB3u-WRsRyghXVX0pT7Hig@mail.gmail.com>
References: <CAAx=oh0_MPr_-MWMsg5CH3zDzssoSB3u-WRsRyghXVX0pT7Hig@mail.gmail.com>
Message-ID: <alpine.BSO.2.11.1409270747210.5398@natsu.mindrot.org>

On Fri, 26 Sep 2014, Todd Morgan wrote:

> At my company we use port forwarding as an alternative to VPN. In previous
> releases of openssh (pre 6.0) we could run a script and fetch the thousands
> of forwards to our local machine to connect to remote machines. Since
> openssh 6.x, whenever we run the same script we get a bufferoverflow error.
> 
> ----
> debug1: channel 4577: new [port listener]
> debug1: channel 4578: new [client-session]
> debug1: Requesting no-more-sessions at openssh.com
> debug1: Entering interactive session.
> *** buffer overflow detected ***: ssh terminated
> ======= Backtrace: =========
> /lib64/libc.so.6(__fortify_fail+0x37)[0x7f3516baf8f7]
> /lib64/libc.so.6(+0x10bac0)[0x7f3516badac0]
> /lib64/libc.so.6(+0x10d867)[0x7f3516baf867]
> ssh(+0x26825)[0x7f3519304825]
> ssh(+0x2aece)[0x7f3519308ece]
> ssh(+0x12d05)[0x7f35192f0d05]
> ssh(+0xb3ee)[0x7f35192e93ee]
> /lib64/libc.so.6(__libc_start_main+0xf5)[0x7f3516ac3af5]
> ssh(+0xc289)[0x7f35192ea289]
>  ----
> 
> I assume this is a security measure to thwart overflow attacks. I've tried
> utilizing multiplexing, but received the same type of buffer overflow.
> 
> Are there any settings that I can change to allow for more forwards? At the
> moment we have a work around to only pull back ports in batches but that
> isn't a long term solution.
> 
> Any advice would be appreciated. Thanks

It looks like it is crashing inside libc, but it is hard to tell. Did
you build OpenSSH yourself? If so, could you try compiling with debugging
symbols enabled (ensure -g is in Makefile CFLAGS, "make clean; make").
Then try to run ssh under a debugger, e.g. from your build directory

gdb --args ./ssh user at host

When it crashes, enter "bt" to get a backtrace. That should give us a good
start to figure out what is going wrong.

-d

From imorgan at nas.nasa.gov  Sat Sep 27 08:00:08 2014
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Fri, 26 Sep 2014 15:00:08 -0700
Subject: DSA 2048 bit keys?
In-Reply-To: <D358E5B1511A314F8160ADC6F3754987069705F5@XYSVEX02.XYPRO-23.LOCAL>
References: <D358E5B1511A314F8160ADC6F3754987069705F5@XYSVEX02.XYPRO-23.LOCAL>
Message-ID: <20140926220008.GB6678@linux124.nas.nasa.gov>

On Fri, Sep 26, 2014 at 21:12:54 +0000, Scott Neugroschl wrote:
> Is there a reason ssh-keygen restricts DSA keys to exactly 1024 bits, given that NIST is recommending a minimum of 2048?
> 
> http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf
> 

Yes, a conflict between the RFC and NIST. Use ecdsa instead.

-- 
Iain Morgan

From bamamorgans at gmail.com  Sat Sep 27 22:22:41 2014
From: bamamorgans at gmail.com (Todd Morgan)
Date: Sat, 27 Sep 2014 07:22:41 -0500
Subject: Port Forward Limit?
In-Reply-To: <alpine.BSO.2.11.1409270747210.5398@natsu.mindrot.org>
References: <CAAx=oh0_MPr_-MWMsg5CH3zDzssoSB3u-WRsRyghXVX0pT7Hig@mail.gmail.com>
 <alpine.BSO.2.11.1409270747210.5398@natsu.mindrot.org>
Message-ID: <5426AC11.2070903@gmail.com>


   Damien,
   We use opensuse and centos at my office and are using the openssh
   provided by the OS repo. There was a lot more output from the
   backtrace. I will get that to you.

   On 09/26/2014 04:51 PM, Damien Miller wrote:

On Fri, 26 Sep 2014, Todd Morgan wrote:


At my company we use port forwarding as an alternative to VPN. In previous
releases of openssh (pre 6.0) we could run a script and fetch the thousands
of forwards to our local machine to connect to remote machines. Since
openssh 6.x, whenever we run the same script we get a bufferoverflow error.

----
debug1: channel 4577: new [port listener]
debug1: channel 4578: new [client-session]
debug1: Requesting [1]no-more-sessions at openssh.com
debug1: Entering interactive session.
*** buffer overflow detected ***: ssh terminated
======= Backtrace: =========
/lib64/libc.so.6(__fortify_fail+0x37)[0x7f3516baf8f7]
/lib64/libc.so.6(+0x10bac0)[0x7f3516badac0]
/lib64/libc.so.6(+0x10d867)[0x7f3516baf867]
ssh(+0x26825)[0x7f3519304825]
ssh(+0x2aece)[0x7f3519308ece]
ssh(+0x12d05)[0x7f35192f0d05]
ssh(+0xb3ee)[0x7f35192e93ee]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x7f3516ac3af5]
ssh(+0xc289)[0x7f35192ea289]
 ----

I assume this is a security measure to thwart overflow attacks. I've tried
utilizing multiplexing, but received the same type of buffer overflow.

Are there any settings that I can change to allow for more forwards? At the
moment we have a work around to only pull back ports in batches but that
isn't a long term solution.

Any advice would be appreciated. Thanks

It looks like it is crashing inside libc, but it is hard to tell. Did
you build OpenSSH yourself? If so, could you try compiling with debugging
symbols enabled (ensure -g is in Makefile CFLAGS, "make clean; make").
Then try to run ssh under a debugger, e.g. from your build directory

gdb --args ./ssh user at host

When it crashes, enter "bt" to get a backtrace. That should give us a good
start to figure out what is going wrong.

-d

References

   1. mailto:no-more-sessions at openssh.com

From djm at mindrot.org  Tue Sep 30 14:47:09 2014
From: djm at mindrot.org (Damien Miller)
Date: Tue, 30 Sep 2014 14:47:09 +1000 (EST)
Subject: Port Forward Limit?
In-Reply-To: <CAAx=oh0_MPr_-MWMsg5CH3zDzssoSB3u-WRsRyghXVX0pT7Hig@mail.gmail.com>
References: <CAAx=oh0_MPr_-MWMsg5CH3zDzssoSB3u-WRsRyghXVX0pT7Hig@mail.gmail.com>
Message-ID: <alpine.BSO.2.11.1409301426390.23886@natsu.mindrot.org>

On Fri, 26 Sep 2014, Todd Morgan wrote:

> At my company we use port forwarding as an alternative to VPN. In previous
> releases of openssh (pre 6.0) we could run a script and fetch the thousands
> of forwards to our local machine to connect to remote machines. Since
> openssh 6.x, whenever we run the same script we get a bufferoverflow error.
> 
> ----
> debug1: channel 4577: new [port listener]
> debug1: channel 4578: new [client-session]
> debug1: Requesting no-more-sessions at openssh.com
> debug1: Entering interactive session.
> *** buffer overflow detected ***: ssh terminated

I figured this out - there is no actual buffer overflow, but a misguided
FD_SET check misfiring.

Some background. OpenSSH uses select(2) for fd monitoring. Yes, this
is a crappy interface but it is the most portable way to do it and for
the vast majority of use absolutely fine. One of the biggest problems
with select(2) is that the POSIX-specified API limits the number of file
descriptors that can be monitored to FD_SETSIZE (typically 1024).

Many Unix variants, including Linux, several commercial Unix and all
current BSD allow exceeding this limit by manually allocating the
fd_set. OpenSSH has used this for ~15 years.

Recently, we enabled FORTIFY_SOURCE to get some libc/toolchain hardening
checks. It turns out that one of these is a dumb check in the FD_SET
macro that fd < 1024. The check isn't aware of allocated fd_sets or that
no overflow actually happens.

https://sourceware.org/bugzilla/show_bug.cgi?id=10352

I'm not sure how to disable this check (which is broken) without turning
off the rest of FORTIFY_SOURCE (which gives some good hardening).
Suggestions welcome.

In the meantime, you can disable this check by editing your Makefile (as
generated by configure) and removing the -DFORTIFY_SOURCE option from
CFLAGS.

-d

From djm at mindrot.org  Tue Sep 30 15:21:17 2014
From: djm at mindrot.org (Damien Miller)
Date: Tue, 30 Sep 2014 15:21:17 +1000 (EST)
Subject: Port Forward Limit?
In-Reply-To: <alpine.BSO.2.11.1409301426390.23886@natsu.mindrot.org>
References: <CAAx=oh0_MPr_-MWMsg5CH3zDzssoSB3u-WRsRyghXVX0pT7Hig@mail.gmail.com>
 <alpine.BSO.2.11.1409301426390.23886@natsu.mindrot.org>
Message-ID: <alpine.BSO.2.11.1409301520140.23886@natsu.mindrot.org>

On Tue, 30 Sep 2014, Damien Miller wrote:

> I'm not sure how to disable this check (which is broken) without turning
> off the rest of FORTIFY_SOURCE (which gives some good hardening).
> Suggestions welcome.

This is the best that I've come up with for now:

Index: openbsd-compat/Makefile.in
===================================================================
RCS file: /var/cvs/openssh/openbsd-compat/Makefile.in,v
retrieving revision 1.55
diff -u -p -r1.55 Makefile.in
--- openbsd-compat/Makefile.in	4 Feb 2014 00:37:50 -0000	1.55
+++ openbsd-compat/Makefile.in	30 Sep 2014 05:19:06 -0000
@@ -18,7 +18,7 @@ LDFLAGS=-L. @LDFLAGS@
 
 OPENBSD=base64.o basename.o bcrypt_pbkdf.o bindresvport.o blowfish.o daemon.o dirname.o fmt_scaled.o getcwd.o getgrouplist.o getopt_long.o getrrsetbyname.o glob.o inet_aton.o inet_ntoa.o inet_ntop.o mktemp.o pwcache.o readpassphrase.o realpath.o rresvport.o setenv.o setproctitle.o sha2.o sigact.o strlcat.o strlcpy.o strmode.o strnlen.o strptime.o strsep.o strtonum.o strtoll.o strtoul.o strtoull.o timingsafe_bcmp.o vis.o blowfish.o bcrypt_pbkdf.o explicit_bzero.o
 
-COMPAT=arc4random.o bsd-asprintf.o bsd-closefrom.o bsd-cray.o bsd-cygwin_util.o bsd-getpeereid.o getrrsetbyname-ldns.o bsd-misc.o bsd-nextstep.o bsd-openpty.o bsd-poll.o bsd-setres_id.o bsd-snprintf.o bsd-statvfs.o bsd-waitpid.o fake-rfc2553.o openssl-compat.o xmmap.o xcrypt.o
+COMPAT=arc4random.o bsd-asprintf.o bsd-closefrom.o bsd-cray.o bsd-cygwin_util.o bsd-getpeereid.o getrrsetbyname-ldns.o bsd-misc.o bsd-nextstep.o bsd-openpty.o bsd-poll.o bsd-setres_id.o bsd-snprintf.o bsd-statvfs.o bsd-waitpid.o fake-rfc2553.o openssl-compat.o xmmap.o xcrypt.o kludge-fd_set.o
 
 PORTS=port-aix.o port-irix.o port-linux.o port-solaris.o port-tun.o port-uw.o
 
Index: openbsd-compat/kludge-fd_set.c
===================================================================
RCS file: openbsd-compat/kludge-fd_set.c
diff -N openbsd-compat/kludge-fd_set.c
--- /dev/null	1 Jan 1970 00:00:00 -0000
+++ openbsd-compat/kludge-fd_set.c	30 Sep 2014 05:19:06 -0000
@@ -0,0 +1,28 @@
+/* Placed in the public domain.  */
+
+/*
+ * _FORTIFY_SOURCE includes a misguided check for FD_SET(n)/FD_ISSET(b)
+ * where n > FD_SETSIZE. This breaks OpenSSH and other programs that
+ * explicitly allocate fd_sets. To avoid this, we wrap FD_SET in a
+ * function compiled without _FORTIFY_SOURCE.
+ */
+
+#include "config.h"
+
+#if defined(HAVE_FEATURES_H) && defined(_FORTIFY_SOURCE)
+# include <features.h>
+# if defined(__GNU_LIBRARY__) && defined(__GLIBC_PREREQ)
+#  if __GLIBC_PREREQ(2, 15) && (_FORTIFY_SOURCE > 0)
+#   undef FORTIFY_SOURCE
+#   undef __USE_FORTIFY_LEVEL
+#   include <sys/socket.h>
+void kludge_FD_SET(int n, fd_set *set) {
+	FD_SET(n, set);
+}
+int kludge_FD_ISSET(int n, fd_set *set) {
+	return FD_ISSET(n, set);
+}
+#  endif /* __GLIBC_PREREQ(2, 15) && (_FORTIFY_SOURCE > 0) */
+# endif /* __GNU_LIBRARY__ && __GLIBC_PREREQ */
+#endif /* HAVE_FEATURES_H && _FORTIFY_SOURCE */
+
Index: openbsd-compat/openbsd-compat.h
===================================================================
RCS file: /var/cvs/openssh/openbsd-compat/openbsd-compat.h,v
retrieving revision 1.61
diff -u -p -r1.61 openbsd-compat.h
--- openbsd-compat/openbsd-compat.h	4 Feb 2014 00:18:23 -0000	1.61
+++ openbsd-compat/openbsd-compat.h	30 Sep 2014 05:19:06 -0000
@@ -268,4 +268,20 @@ char *shadow_pw(struct passwd *pw);
 #include "port-tun.h"
 #include "port-uw.h"
 
+/* _FORTIFY_SOURCE breaks FD_ISSET(n)/FD_SET(n) for n > FD_SETSIZE. Avoid. */
+#if defined(HAVE_FEATURES_H) && defined(_FORTIFY_SOURCE)
+# include <features.h>
+# if defined(__GNU_LIBRARY__) && defined(__GLIBC_PREREQ)
+#  if __GLIBC_PREREQ(2, 15) && (_FORTIFY_SOURCE > 0)
+#   include <sys/socket.h>  /* Ensure include guard is defined */
+#   undef FD_SET
+#   undef FD_ISSET
+#   define FD_SET(n, set)	kludge_FD_SET(n, set)
+#   define FD_ISSET(n, set)	kludge_FD_ISSET(n, set)
+void kludge_FD_SET(int, fd_set *);
+int kludge_FD_ISSET(int, fd_set *);
+#  endif /* __GLIBC_PREREQ(2, 15) && (_FORTIFY_SOURCE > 0) */
+# endif /* __GNU_LIBRARY__ && __GLIBC_PREREQ */
+#endif /* HAVE_FEATURES_H && _FORTIFY_SOURCE */
+
 #endif /* _OPENBSD_COMPAT_H */