From djm at mindrot.org  Wed Jan  1 09:37:34 2014
From: djm at mindrot.org (Damien Miller)
Date: Wed, 1 Jan 2014 09:37:34 +1100 (EST)
Subject: Cipher preference
In-Reply-To: <m3zjnhzekn.fsf@carbon.jhcloos.org>
References: <m361q523ij.fsf@carbon.jhcloos.org>
 <alpine.BSO.2.03.1312311341180.7877@mindrot.org>
 <m3zjnhzekn.fsf@carbon.jhcloos.org>
Message-ID: <alpine.BSO.2.03.1401010936440.30571@mindrot.org>

On Tue, 31 Dec 2013, James Cloos wrote:

> >>>>> "DM" == Damien Miller <djm at mindrot.org> writes:
> 
> DM> Lots of cryptographers also think that AES-GCM is fiendishly difficult
> DM> to get right, especially wrt timing leaks. That, and it's relative
> DM> newness in OpenSSH are the reasons it is not the default.
> 
> Indeed, I should have added a paragraph about that.
> 
> My understanding is that the consensus is that openssl has fixed the
> early bugs in its implementation and gcm therefore is safe enough to
> promote.

Evidence? openssl/crypto/modes/gcm128.c is full of array operations
that look decidedly non-constant time to me.

-d

From dimitri.nuescheler at sunrise.ch  Wed Jan  1 13:12:58 2014
From: dimitri.nuescheler at sunrise.ch (=?ISO-8859-1?Q?Dimitri_N=FCscheler?=)
Date: Wed, 1 Jan 2014 03:12:58 +0100
Subject: Soft chroot jail for sftp-server
Message-ID: <CAGnp+2wgSoEwcOF9URT8hJ9L7JdE+ZXBxBM+z=PiMf=v1Tt8Ag@mail.gmail.com>

Hi everyone

I would like to enable unprivileged users to share only certain
directories using SFTP without acquiring root, without setting
capabilities using public-key-based forced commands.

In another use case unprivileged users could write scripts that
evaluate "$SSH_ORIGINAL_COMMAND" and then either execute sftp-server
in a jail "$SSH_ORIGINAL_COMMAND" after "review" (e.g. matches a
certain regexp) and fortification.

External users would access the system in a user-defined restricted way to:
upload data, trigger processing of data, download processed data.

I created a patch against the debian sid distribution of OpenSSH
6.4-p1-1 "sftp-server.c" that introduces a command line option "-j"
(original file and patch attached)

It's not yet in a fully polished, robust and tested state, but I think
at least it is serves as PoC.

Would you accept such a patch if finalized?
Do you have any recommendations
- regarding my patch?
- to what I would like to achieve?
(basic C programming hints welcome too, I usually don't code in C,
first serious use)

Thank you & Kind Regards

Dimitri
-------------- next part --------------
75a76,78
> /* Restrict access to this directory */
> char* jail;
> 
85a89,213
> /* Concatenate 2 path parts in a way that one doesn't need to care about leading/trailing slashes. Returned pointer can be freed. */
> static char* concat_path(char* parent, char* child) {
> 	size_t parent_len = strlen(parent);
> 	if (parent_len < 1)
> 		return xstrdup(child);
> 	size_t child_len = strlen(child);
> 	if (child_len < 1)
> 		return xstrdup(parent);
> 	
> 	if (*child == '/') {
> 		child++;
> 		child_len--;
> 	}
> 	
> 	char* cat;
> 	if (*(parent + parent_len - 1) == '/') {
> 		size_t cat_len = sizeof(char) * (parent_len + child_len + 1);
> 		cat = xmalloc(sizeof(char) * cat_len);
> 		*cat = '\0';
> 		strlcat(cat,parent,cat_len);
> 		strlcat(cat,child,cat_len);
> 		return cat;
> 	} else {
> 		size_t cat_len = sizeof(char) * (parent_len + child_len + 2);
> 		cat = xmalloc(sizeof(char) * cat_len);
> 		*cat = '\0';
> 		strlcat(cat,parent,cat_len);
> 		strlcat(cat,"/",cat_len);
> 		strlcat(cat,child,cat_len);
> 		return cat;
> 	}
> }
> 
> /* shorten the path by removing occurences of "//" and any relative (backward) directory references (".", ".."), ignoring backward references
>  * that traverse the current directory or root, maintaining leading "/" and maintaining trailing "/" if possible.
>  * The passed string is modified.
>  */
> static char* shorten_path(char* path) {
> 	unsigned int path_len = strlen(path)+1;
> 	//char* short_path = path; malloc(sizeof(char) * short_path_len);
> 	size_t j = 0;
> 	size_t i = 0;
> 	//Make sure path doesn't contain any "//"
> 	for (i = 0; i < path_len; i++) {
> 		if (*(path+i) == '/' && j>0 && *(path+j-1) == '/')
> 			j--;
> 		
> 		*(path+j) = *(path+i);
> 		j++;
> 	}
> 	
> 	j = 0;
> 	int dot_count = 0;
> 	i = 0;
> 	path_len = strlen(path)+1;
> 	char* real_path = path;
> 	if (*path == '/') {
> 		path++;
> 		path_len--;
> 	}
> 	
> 	// Execute actual ".." resolution with a path that doesn't care if it is absolute or relative
> 	for (i = 0; i < path_len; i++) {
> 		if (*(path+i) == '/' || *(path+i) == '\0') {
> 			if (dot_count == 2) {
> 				while (j>0 && *(path+j-1) != '/') {
> 					j--;	
> 				}
> 				if (j>0) j--;
> 				while (j>0 && *(path+j-1) != '/') {
> 					j--;	
> 				}
> 				if (j<1 && *(path+i) == '/') i++;
> 			}
> 			else if (dot_count == 1) {
> 				while (j>0 && *(path+j-1) != '/') {
> 					j--;	
> 				}
> 				if (j<1 && *(path+i) == '/') i++;
> 			}
> 			dot_count = *(path+i) == '.' ? 1 : 0;
> 		}
> 		else if (*(path+i) == '.') dot_count++;
> 		else dot_count = 3;
> 		
> 		if (*(path+i) == '/' && j>0 && *(path+j-1) == '/')
> 		j--;
> 		
> 		*(path+j) = *(path+i);
> 		j++;
> 	}
> 	return real_path;
> }
> /* Takes a path from jail perspective and converts it to the actual path. This function frees path (so expects a freeable pointer) or reuses it so in any case returns a freeable pointer. */
> static char* jail_to_actual(char* path) {
> 	if (jail == NULL) return path;
> 	char* shortened = shorten_path(path);
> 	char* translated = concat_path(jail,shortened);
> 	free(shortened);
> 	return translated;
> }
> /* The opposite of jail_to_actual, returns NULL if path is not in jail, This function frees path (so expects a freeable pointer) or reuses it so in any case returns a freeable pointer. */
> static char* actual_to_jail(char* path) {
> 	if (jail == NULL) return path;
> 	unsigned int jail_len = strlen(jail);
> 	if (strncmp(jail,path,jail_len) != 0) return NULL;
> 	char* actual = xstrdup(path+jail_len);
> 	free(path);
> 	if (strlen(actual) < 1) {
> 		free(actual);
> 		actual = xstrdup("/");
> 	}
> 	return actual;
> }
> /* Removes trailing slashes, except a leading one, modifies the passed string */
> static void rtrim_slash(char* path) {
> 	unsigned int len = strlen(path);
> 	int i;
> 	for (i = len-1; i > 0; i--) {
> 		if (*(path+i) == '/')
> 			*(path+i) = '\0';
> 		else break;
> 	}
> }
> 
523d650
< 
552d678
< 
554a681,696
> 	name = jail_to_actual(name);
> 	if (jail != NULL) {
> 		char resolvedname[MAXPATHLEN];
> 		if (realpath(name, resolvedname) == NULL) {
> 			send_status(id, errno_to_portable(errno));
> 			free(name);
> 			return;
> 		}
> 		char* jailed_resolvedname = actual_to_jail(xstrdup(resolvedname));
> 		if (jailed_resolvedname == NULL) {
> 			send_status(id,SSH2_FX_FAILURE);
> 			free(name);
> 			return;
> 		}
> 		
> 	}
589d730
< 
695a837
> 	name = jail_to_actual(name);
771a914
> 	name = jail_to_actual(name);
889a1033,1048
> 	path = jail_to_actual(path);
> 	if (jail != NULL) {
> 		char resolvedname[MAXPATHLEN];
> 		if (realpath(path, resolvedname) == NULL) {
> 			send_status(id, errno_to_portable(errno));
> 			free(path);
> 			return;
> 		}
> 		char* jailed_resolvedname = actual_to_jail(xstrdup(resolvedname));
> 		if (jailed_resolvedname == NULL) {
> 			send_status(id,SSH2_FX_FAILURE);
> 			free(path);
> 			return;
> 		}
> 		
> 	}
975a1135
> 	name = jail_to_actual(name);
997a1158
> 	name = jail_to_actual(name);
1021a1183
> 	name = jail_to_actual(name);
1042a1205
> 	path = jail_to_actual(path);
1054,1055c1217,1233
< 		s.name = s.long_name = resolvedname;
< 		send_names(id, 1, &s);
---
> 		if (jail != NULL) {
> 			char* jailed_resolvedname = actual_to_jail(xstrdup(resolvedname));
> 			/* Note that only the resolved string needs to point inside the jail. During resolution it may visit links outside jail
> 			 * The SFTP-user, however, is not able to create links to the outside anyway.
> 			 */
> 			if (jailed_resolvedname == NULL) send_status(id,SSH2_FX_FAILURE);
> 			else {
> 				s.name = s.long_name = jailed_resolvedname;
> 				send_names(id, 1, &s);
> 			}
> 			free(jailed_resolvedname);
> 		}
> 		else {
> 			s.name = s.long_name = resolvedname;
> 			send_names(id, 1, &s);
> 		}
> 		
1070a1249,1250
> 	oldpath = jail_to_actual(oldpath);
> 	newpath = jail_to_actual(newpath);
1131a1312
> 	path = jail_to_actual(path);
1156a1338,1339
> 	oldpath = jail_to_actual(oldpath);
> 	newpath = jail_to_actual(newpath);
1178a1362,1363
> 	oldpath = jail_to_actual(oldpath);
> 	newpath = jail_to_actual(newpath);
1198a1384
> 	path = jail_to_actual(path);
1235a1422,1423
> 	oldpath = jail_to_actual(oldpath);
> 	newpath = jail_to_actual(newpath);
1406a1595
> 	jail = NULL;
1414d1602
< 
1417c1605
< 	while (!skipargs && (ch = getopt(argc, argv, "d:f:l:u:cehR")) != -1) {
---
> 	while (!skipargs && (ch = getopt(argc, argv, "d:f:l:u:j:cehR")) != -1) {
1455a1644,1657
> 		case 'j':
> 			if (strlen(optarg) > 0 && *optarg == '/')
> 				jail = xstrdup(optarg);
> 			else {
> 				char* wd = get_current_dir_name();
> 				jail = concat_path(wd,optarg);
> 				free(wd);
> 			}
> 			rtrim_slash(jail);
> 			if (*jail == '\0' || (strlen(jail) == 1 && *jail == '/' )) {
> 				jail = NULL;
> 				break;
> 			}
> 			break;
1498c1700
< 
---
> 	
1500,1501c1702,1709
< 		if (chdir(homedir) != 0) {
< 			error("chdir to \"%s\" failed: %s", homedir,
---
> 		char* jailed_homedir;
> 		if (jail != NULL) {
> 			jailed_homedir = concat_path(jail,homedir);
> 		}
> 		else
> 			jailed_homedir = xstrdup(homedir);
> 		if (chdir(jailed_homedir) != 0) {
> 			error("chdir to \"%s\" failed: %s", jailed_homedir,
1503a1712
> 		free(jailed_homedir);
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sftp-server.c
Type: text/x-csrc
Size: 33990 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20140101/8703378a/attachment-0001.bin>

From naddy at mips.inka.de  Thu Jan  2 02:41:17 2014
From: naddy at mips.inka.de (Christian Weisgerber)
Date: Wed, 1 Jan 2014 15:41:17 +0000 (UTC)
Subject: Cipher preference
References: <m361q523ij.fsf@carbon.jhcloos.org>
Message-ID: <la1cut$2710$1@lorvorc.mips.inka.de>

James Cloos <cloos at jhcloos.com> wrote:

> When testing chacha20-poly1305, I noticed that aes-gcm is significantly
> faster than aes-ctr or aes-cbs with umac.  Even on systems w/o aes-ni
> or other recent instruction set additions.

No way.  This disagrees completely with what I'm seeing:

On Sandy Bridge systems with AES-NI, aes128-gcm is about as fast
as aes128-ctr+umac-64.

On x86-64 systems without AES-NI, aes128-gcm is slower than
aes128-ctr+umac-64.  (OpenSSL 1.0.1c, 1.0.1e)

On other systems without AES-NI or the benefit of assembly language
optimizations in OpenSSL, aes128-gcm is painfully slower than
aes128-ctr+umac-64.  (OpenSSL 1.0.1c)

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

From pcerny at suse.cz  Fri Jan  3 02:09:02 2014
From: pcerny at suse.cz (Petr Cerny)
Date: Thu, 02 Jan 2014 16:09:02 +0100
Subject: ForwardX11Timeout = 0 disables untrusted connections
Message-ID: <52C5810E.2000701@suse.cz>

Hi,

it seems that setting

ForwardX11Trusted = yes
ForwardX11Timeout = 0

causes untrusted connections to be refused immediately. While this 
certainly makes sense this way, I believe in this case ForwardX11Timeout 
= 0 might be better used for disabling the timeout entirely (the current 
behaviour is the same as ForwardX11Trusted = no).

Is there some reason while this would be a bad idea?

Thanks
Cheers
	Petr Cerny
-- 
Petr Cerny
Mozilla/OpenSSH maintainer for SUSE Linux

From bob at proulx.com  Fri Jan  3 06:55:39 2014
From: bob at proulx.com (Bob Proulx)
Date: Thu, 2 Jan 2014 12:55:39 -0700
Subject: New Log Messages?
Message-ID: <20140102195539.GA5963@hysteria.proulx.com>

In recent months I started noticing a new type of log message.  Here
are some examples.  One of each but my logs show many runs of these
types of messages.  Along with others but these are the majority
type.  Imagine lines like these repeated many times in the syslog.

  Dec  7 15:49:42 havoc sshd[7575]: Received disconnect from 114.80.246.178: 11: Normal Shutdown, Thank you for playing [preauth]
  Dec 10 12:05:45 havoc sshd[6580]: Received disconnect from 134.147.203.117: 11: Bye [preauth]
  Dec 24 11:33:05 havoc sshd[410]: Received disconnect from 183.136.213.228: 11: Normal [preauth]

I don't recall that these were seen until recently.  Of course I
searched these out and found them in the libssh example source code.
I know that attackers have done a simple hacking of the examples and
are now using these and trying dictionary and other attacks on any
server they can probe.

I am not concerned about the attack itself.  I have good password
security and rate limiting and so forth and am not asking about the
attack itself.  Attackers have been attacking systems for a long time.
I am only asking for background so that I can understand why these new
messages are being logged now when they haven't been seen in the
syslog previously.  Just trying to understand what changed recently.
Did the examples change to include disconnect messages when they
previously did not?

I do find it annoying that anyone on the net can log any message they
want to the syslog by sending it in the disconnect message.  It makes
it more difficult to sift useful alert information from the syslog.

Thanks,
Bob

From gturner at unzane.com  Fri Jan  3 11:04:17 2014
From: gturner at unzane.com (Gerald Turner)
Date: Thu, 02 Jan 2014 16:04:17 -0800
Subject: VisualHostKey vs. RekeyLimit vs. VerifyHostKeyDNS
Message-ID: <8761q2ylq6.fsf@zoth-ommog.unzane.com>

Hello list, I'm not sure whether this is bug worthy or just my own
insanity.  I'm using 6.4p1 packages from Debian jessie and
wheezy-backports.

I like VisualHostKey, although it may not add any protection (other than
not trusting ones own known_hosts file?), I've become accustomed to it
as it seems that extra neurons fire when I log into a host and get a
visual cue of what looks like a strawberry or jester hat and suddenly a
catalog of frequent commands relevant to the particular host surface in
mind ;-)

I have two configuration problems that make VisualHostKey less usable.

* RekeyLimit

I'm no crypto expert, pretty much cargo-culting here, but from bits and
pieces I've read, it seems like re-keying is crucial for a cipher like
AES-GCM.  Maybe it's just a gut feeling inspired by strongSwan IPsec
daemons which are constantly re-keying.

Every time the cipher is re-keyed, VisualHostKey clobbers the terminal,
usually with broken line feeds such that the ascii-art is unintelligible
and wraps off the right side of the terminal.  This is annoying,
especially with a screen(1) full of ssh sessions that may be idle and
re-keyed several times over a weekend, coming back and having to work
through clearing the screens of each session (^L suffices for a shell or
emacs, but sometimes the session is in a curses application, or lost
information while tailing a log, etc.).  This gets uglier when making
use of the fantastic ControlPersist options - seemingly logged out ssh
session still blast the initial terminal with re-keying fingerprints.

* VerifyHostKeyDNS=yes

It seems VerifyHostKeyDNS=yes short-circuits VisualHostKey - it's
neither displayed on initial connection, or on re-keying (good).

So I have a funny setup:

  For hosts which have SSHFP records, I have set VerifyHostKeyDNS=yes
  and ineffectively set VisualHostKey=yes (never prints), and can also
  set a timed RekeyLimit rate.

  For hosts which don't have SSHFP, I could leave RekeyLimit at the
  default (1G none) and rarely see the re-key fingerprints, however in
  an all-or-nothing sort of decision, simply set VisualHostKey=no and be
  done with it.

Am I missing something?  Is there a way to comfortably get VisualHostKey
back?  Perhaps a trivial/wishlist bug with re-keying should be filed?

Perhaps this is already solved by bug 2154, "Avoid key lookup overhead
when re-keying":

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

P.S. I think it's wonderful you folks are working on curve25519,
ed25519, and chacha20+poly1305.  I've moved a bunch of systems to ECDHE
last year, great speedup, especially from crap Atom clients, but feel
that I've shot myself in the foot after Schneier's denouncement of the
NIST curves.

-- 
Gerald Turner   Email: gturner at unzane.com   JID: gturner at unzane.com
GPG: 0xFA8CD6D5  21D9 B2E8 7FE7 F19E 5F7D  4D0C 3FA0 810F FA8C D6D5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20140102/0c48aa5d/attachment.bin>

From djm at mindrot.org  Fri Jan  3 16:15:23 2014
From: djm at mindrot.org (Damien Miller)
Date: Fri, 3 Jan 2014 16:15:23 +1100 (EST)
Subject: New Log Messages?
In-Reply-To: <20140102195539.GA5963@hysteria.proulx.com>
References: <20140102195539.GA5963@hysteria.proulx.com>
Message-ID: <alpine.BSO.2.03.1401031610180.8654@mindrot.org>

On Thu, 2 Jan 2014, Bob Proulx wrote:

> In recent months I started noticing a new type of log message.  Here
> are some examples.  One of each but my logs show many runs of these
> types of messages.  Along with others but these are the majority
> type.  Imagine lines like these repeated many times in the syslog.
> 
>   Dec  7 15:49:42 havoc sshd[7575]: Received disconnect from 114.80.246.178: 11: Normal Shutdown, Thank you for playing [preauth]
>   Dec 10 12:05:45 havoc sshd[6580]: Received disconnect from 134.147.203.117: 11: Bye [preauth]
>   Dec 24 11:33:05 havoc sshd[410]: Received disconnect from 183.136.213.228: 11: Normal [preauth]

...

> I am not concerned about the attack itself.  I have good password
> security and rate limiting and so forth and am not asking about the
> attack itself.  Attackers have been attacking systems for a long time.
> I am only asking for background so that I can understand why these new
> messages are being logged now when they haven't been seen in the
> syslog previously.  Just trying to understand what changed recently.
> Did the examples change to include disconnect messages when they
> previously did not?

Not that I am aware - did you perhaps upgrade from some old version that
was not logging the preauth messages?

> I do find it annoying that anyone on the net can log any message they
> want to the syslog by sending it in the disconnect message.  It makes
> it more difficult to sift useful alert information from the syslog.

It's useful information in some cases.

-d

From djm at mindrot.org  Fri Jan  3 16:22:18 2014
From: djm at mindrot.org (Damien Miller)
Date: Fri, 3 Jan 2014 16:22:18 +1100 (EST)
Subject: VisualHostKey vs. RekeyLimit vs. VerifyHostKeyDNS
In-Reply-To: <8761q2ylq6.fsf@zoth-ommog.unzane.com>
References: <8761q2ylq6.fsf@zoth-ommog.unzane.com>
Message-ID: <alpine.BSO.2.03.1401031617000.8654@mindrot.org>

On Thu, 2 Jan 2014, Gerald Turner wrote:

> Hello list, I'm not sure whether this is bug worthy or just my own
> insanity.  I'm using 6.4p1 packages from Debian jessie and
> wheezy-backports.
> 
> I like VisualHostKey, although it may not add any protection (other than
> not trusting ones own known_hosts file?), I've become accustomed to it
> as it seems that extra neurons fire when I log into a host and get a
> visual cue of what looks like a strawberry or jester hat and suddenly a
> catalog of frequent commands relevant to the particular host surface in
> mind ;-)
> 
> I have two configuration problems that make VisualHostKey less usable.
> 
> * RekeyLimit
> 
> I'm no crypto expert, pretty much cargo-culting here, but from bits and
> pieces I've read, it seems like re-keying is crucial for a cipher like
> AES-GCM.  Maybe it's just a gut feeling inspired by strongSwan IPsec
> daemons which are constantly re-keying.
> 
> Every time the cipher is re-keyed, VisualHostKey clobbers the terminal,
> usually with broken line feeds such that the ascii-art is unintelligible
> and wraps off the right side of the terminal.  This is annoying,
> especially with a screen(1) full of ssh sessions that may be idle and
> re-keyed several times over a weekend, coming back and having to work
> through clearing the screens of each session (^L suffices for a shell or
> emacs, but sometimes the session is in a curses application, or lost
> information while tailing a log, etc.).  This gets uglier when making
> use of the fantastic ControlPersist options - seemingly logged out ssh
> session still blast the initial terminal with re-keying fingerprints.

Could you please file a bug for this on https://bugzilla.mindrot.org/ ?
We should suppress the message on rekeying.

> * VerifyHostKeyDNS=yes
> 
> It seems VerifyHostKeyDNS=yes short-circuits VisualHostKey - it's
> neither displayed on initial connection, or on re-keying (good).

If you really want to see it, maybe we could make a
VisualHostKey=always option?

> So I have a funny setup:
> 
>   For hosts which have SSHFP records, I have set VerifyHostKeyDNS=yes
>   and ineffectively set VisualHostKey=yes (never prints), and can also
>   set a timed RekeyLimit rate.
> 
>   For hosts which don't have SSHFP, I could leave RekeyLimit at the
>   default (1G none) and rarely see the re-key fingerprints, however in
>   an all-or-nothing sort of decision, simply set VisualHostKey=no and be
>   done with it.
> 
> Am I missing something?  Is there a way to comfortably get VisualHostKey
> back?  Perhaps a trivial/wishlist bug with re-keying should be filed?
> 
> Perhaps this is already solved by bug 2154, "Avoid key lookup overhead
> when re-keying":
> 
>   https://bugzilla.mindrot.org/show_bug.cgi?id=2154

Yes, it probably is.

> P.S. I think it's wonderful you folks are working on curve25519,
> ed25519, and chacha20+poly1305.  I've moved a bunch of systems to ECDHE
> last year, great speedup, especially from crap Atom clients, but feel
> that I've shot myself in the foot after Schneier's denouncement of the
> NIST curves.

IMO the concerns about the NIST EC curves are a bit overblown. If the NSA
had some way of breaking EC directly, then they wouldn't need to resort
to things like Dual_EC_DRBG.

-d


From bob at proulx.com  Sat Jan  4 04:55:19 2014
From: bob at proulx.com (Bob Proulx)
Date: Fri, 3 Jan 2014 10:55:19 -0700
Subject: New Log Messages?
In-Reply-To: <alpine.BSO.2.03.1401031610180.8654@mindrot.org>
References: <20140102195539.GA5963@hysteria.proulx.com>
 <alpine.BSO.2.03.1401031610180.8654@mindrot.org>
Message-ID: <20140103175519.GA24478@hysteria.proulx.com>

Damien Miller wrote:
> Bob Proulx wrote:
> > In recent months I started noticing a new type of log message.
> > ...
> > Just trying to understand what changed recently.  Did the examples
> > change to include disconnect messages when they previously did
> > not?
>
> Not that I am aware - did you perhaps upgrade from some old version that
> was not logging the preauth messages?

I am always hesitant to mention version numbers upstream because I am
using a software distribution and as you know software distributions
support a single release for the lifetime of the distro's stable
release.  I am running Debian Stable on my internet facing machines.
For Debian it is about two years.  For me this is perfect.

In private mail I had someone point me to this serverfault question.
Apparently I was not the only one who noticed this change and was
asking questions about it.  (shrug)

  http://serverfault.com/questions/559200/what-does-normal-shutdown-thank-you-for-playing-preauth-in-ssh-logs-mean

And the answer proposed seems reasonable.  That the disconnect message
wasn't logged by sshd previously and now it is being logged.  In your
upstream sources this could have been a change any time in the last
two years.  I only made the upgrade on my machines last summer from a
5.x release to a 6.x release.  I have been noticing these for some
months but just finally decided to ask about it.

> > I do find it annoying that anyone on the net can log any message they
> > want to the syslog by sending it in the disconnect message.  It makes
> > it more difficult to sift useful alert information from the syslog.
> 
> It's useful information in some cases.

It has certainly seen use for some fun and games from the script
kiddies trying to shake the doors and lift the windows.  :-)  Although
thinking about it maybe I could write a rule for any unusual logged
message to feed into the fail2ban rules?  Maybe.

In any case, thank you for maintaining ssh!

Bob

From gturner at unzane.com  Sat Jan  4 06:03:07 2014
From: gturner at unzane.com (Gerald Turner)
Date: Fri, 03 Jan 2014 11:03:07 -0800
Subject: VisualHostKey vs. RekeyLimit vs. VerifyHostKeyDNS
In-Reply-To: <alpine.BSO.2.03.1401031617000.8654@mindrot.org> (Damien Miller's
 message of "Fri, 3 Jan 2014 16:22:18 +1100 (EST)")
References: <8761q2ylq6.fsf@zoth-ommog.unzane.com>
 <alpine.BSO.2.03.1401031617000.8654@mindrot.org>
Message-ID: <87lhywyjkk.fsf@zoth-ommog.unzane.com>

Damien Miller <djm at mindrot.org> writes:
> On Thu, 2 Jan 2014, Gerald Turner wrote:
>> Every time the cipher is re-keyed, VisualHostKey clobbers the
>> terminal, usually with broken line feeds such that the ascii-art is
>> unintelligible and wraps off the right side of the terminal.  This is
>> annoying, especially with a screen(1) full of ssh sessions that may
>> be idle and re-keyed several times over a weekend, coming back and
>> having to work through clearing the screens of each session (^L
>> suffices for a shell or emacs, but sometimes the session is in a
>> curses application, or lost information while tailing a log, etc.).
>> This gets uglier when making use of the fantastic ControlPersist
>> options - seemingly logged out ssh session still blast the initial
>> terminal with re-keying fingerprints.
>
> Could you please file a bug for this on https://bugzilla.mindrot.org/
> ?  We should suppress the message on rekeying.

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

Thanks!

>> It seems VerifyHostKeyDNS=yes short-circuits VisualHostKey - it's
>> neither displayed on initial connection, or on re-keying (good).
>
> If you really want to see it, maybe we could make a
> VisualHostKey=always option?

Actually I'm fine with VerifyHostKeyDNS=ask (was only using 'yes' as an
intermediate hack to get rid of the fingerprint spam).

>> P.S. I think it's wonderful you folks are working on curve25519,
>> ed25519, and chacha20+poly1305.  I've moved a bunch of systems to
>> ECDHE last year, great speedup, especially from crap Atom clients,
>> but feel that I've shot myself in the foot after Schneier's
>> denouncement of the NIST curves.
>
> IMO the concerns about the NIST EC curves are a bit overblown. If the
> NSA had some way of breaking EC directly, then they wouldn't need to
> resort to things like Dual_EC_DRBG.

Nevertheless, the "Safe Curves" work by DJB and Tanja Lange is rather
convincing that we should have better curves than the NIST curves:
   http://safecurves.cr.yp.to/

-- 
Gerald Turner   Email: gturner at unzane.com   JID: gturner at unzane.com
GPG: 0xFA8CD6D5  21D9 B2E8 7FE7 F19E 5F7D  4D0C 3FA0 810F FA8C D6D5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20140103/be85d5e8/attachment.bin>

From roseandrew at me.com  Sun Jan  5 20:10:24 2014
From: roseandrew at me.com (ANDREY ROZE)
Date: Sun, 05 Jan 2014 13:10:24 +0400
Subject: Segmentation faut on mips device
Message-ID: <5DF7F25F-10C8-4151-A380-3654A2FCDEB0@me.com>

Good day! I write cycles articles about the possibility of expanding the standard firmware optical terminal . This is a standard optical terminal which put all subscribers mgts in Moscow - Zte f660.

CPU info and version:
http://pastebin.com/raw.php?i=ye6k3eJb

More than 5 million subscribers use this terminal and very much it would be interesting to extend the standard capabilities of the router. I began to study the creation of an isolated chroot environment. I managed to compile the latest version toolchan gcc 4.8.2.
Toolchan create script:

http://pastebin.com/RxwS09iT

With his help I was able to create a guaranteed working bash and coreutils.

Openssh create script:

http://pastebin.com/bCM1wJSG

I also managed to create openssh, but when I run any of the software package openssh I get a segmentation fault (segmentation fault). In this program from the OpenSSL by the same compiler working properly.
....
InstallOpenSSl()
{
cd openssl-1.0.1e
make clean
./Configure dist shared - prefix = $SYSROOT -fPIC
make
check_success
make install
check_success
cd ..
}

InstallOpenSSH()
{
cd openssh-6.4p1
make clean
./configure - prefix = $SYSROOT -host = $HOST
make LDFLAGS = "-shared-L.-Lopenbsd-compat /" CFLAGS = "-fPIC"
check_success
make install-files STRIP_OPT = "- strip-program = mips-unknown-linux-gnu-strip"
check_success
cd ..
}

I unfortunately I am unable to run under gdb debugger as it must also be compiled. Please help solve this problem, for me it is a major obstacle .
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1732 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20140105/b3b3f406/attachment.bin>

From dtucker at zip.com.au  Sun Jan  5 21:19:53 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 5 Jan 2014 21:19:53 +1100
Subject: Segmentation faut on mips device
In-Reply-To: <5DF7F25F-10C8-4151-A380-3654A2FCDEB0@me.com>
References: <5DF7F25F-10C8-4151-A380-3654A2FCDEB0@me.com>
Message-ID: <CALDDTe2gzoSh10kN-bvw7VW3HSB267NcT3r1Ly6tRvy4-XEynA@mail.gmail.com>

On Sun, Jan 5, 2014 at 8:10 PM, ANDREY ROZE <roseandrew at me.com> wrote:
> I unfortunately I am unable to run under gdb debugger as it must also be compiled. Please help solve this problem, for me it is a major obstacle .

First suggest: run whichever program crashes with full debugging on
("ssh -vvv" for the client, "sshd -ddde" for the server) and post
those.  This might give a hint as to approximately where and what it's
doing when it's crashing, which might be enough for someone to guess
what's going on.  Failing that, you might need to build a debugger for
your target platform.

-- 
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 roseandrew at me.com  Wed Jan  8 02:30:27 2014
From: roseandrew at me.com (ANDREY ROZE)
Date: Tue, 07 Jan 2014 19:30:27 +0400
Subject: Segmentation faut on mips device
In-Reply-To: <CALDDTe2gzoSh10kN-bvw7VW3HSB267NcT3r1Ly6tRvy4-XEynA@mail.gmail.com>
References: <5DF7F25F-10C8-4151-A380-3654A2FCDEB0@me.com>
 <CALDDTe2gzoSh10kN-bvw7VW3HSB267NcT3r1Ly6tRvy4-XEynA@mail.gmail.com>
Message-ID: <E3C33139-F9F3-4FD1-A733-2B9140DEEF11@me.com>

I managed to compile the gdb debugger for the target architecture and run under gdb
That's what he gave me :

This GDB was configured as "mips-unknown-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/> ...
Reading symbols from / bin / ssh...done.
(gdb) run
Starting program: / bin / ssh

Program received signal SIGSEGV, Segmentation fault.
0x555887e0 in?? ()


I also tried to run ssh with -vvv. With the same result.
I also did an experiment . Replaced the source code to the stub ssh.c "hellow world", the program also issued a segmentation fault.

I'm not sure but it may be a bug associated with the correct configuration at compile time.
I tried to configure with default settings , but there were errors . I had to add two flag -fPIC-shared. Finally make looks like:


make LDFLAGS = "-shared-L.-Lopenbsd-compat /-fstack-protector-all" CFLAGS = "-fPIC-g-O2-Wall-Wpointer-arith-Wuninitialized-Wsign-compare-Wformat-security-Wno-pointer -sign-Wno-unused-result-fno-strict-aliasing-D_FORTIFY_SOURCE = 2 -fno-builtin-memset-fstack-protector-all 



On 05 ???. 2014 ?., at 14:19, Darren Tucker <dtucker at zip.com.au> wrote:

> On Sun, Jan 5, 2014 at 8:10 PM, ANDREY ROZE <roseandrew at me.com> wrote:
>> I unfortunately I am unable to run under gdb debugger as it must also be compiled. Please help solve this problem, for me it is a major obstacle .
> 
> First suggest: run whichever program crashes with full debugging on
> ("ssh -vvv" for the client, "sshd -ddde" for the server) and post
> those.  This might give a hint as to approximately where and what it's
> doing when it's crashing, which might be enough for someone to guess
> what's going on.  Failing that, you might need to build a debugger for
> your target platform.
> 
> -- 
> 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.

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

From djm at mindrot.org  Wed Jan  8 09:59:01 2014
From: djm at mindrot.org (Damien Miller)
Date: Wed, 8 Jan 2014 09:59:01 +1100 (EST)
Subject: New Log Messages?
In-Reply-To: <20140103175519.GA24478@hysteria.proulx.com>
References: <20140102195539.GA5963@hysteria.proulx.com>
 <alpine.BSO.2.03.1401031610180.8654@mindrot.org>
 <20140103175519.GA24478@hysteria.proulx.com>
Message-ID: <alpine.BSO.2.03.1401080954320.3003@mindrot.org>

On Fri, 3 Jan 2014, Bob Proulx wrote:

> I am always hesitant to mention version numbers upstream because I am
> using a software distribution and as you know software distributions
> support a single release for the lifetime of the distro's stable
> release.  I am running Debian Stable on my internet facing machines.
> For Debian it is about two years.  For me this is perfect.
> 
> In private mail I had someone point me to this serverfault question.
> Apparently I was not the only one who noticed this change and was
> asking questions about it.  (shrug)
> 
>   http://serverfault.com/questions/559200/what-does-normal-shutdown-thank-you-for-playing-preauth-in-ssh-logs-mean
> 
> And the answer proposed seems reasonable.  That the disconnect message
> wasn't logged by sshd previously and now it is being logged.  In your
> upstream sources this could have been a change any time in the last
> two years.  I only made the upgrade on my machines last summer from a
> 5.x release to a 6.x release.  I have been noticing these for some
> months but just finally decided to ask about it.

The message has been there basically forever:

1.41  (markus 02-Jan-01): log("Received disconnect from %s: %d: %.400s", ...

The only thing to have changed semi-recently is that we improved
logging of preauthentication messages in privsep mode in the 5.9
release to no longer need a /dev/log inside the privsep chroot. If
your old OpenSSH version was <5.9 and the /var/empty chroot didn't
have a /dev/log in it then you may have been missing these messages.

-d

From loganaden at gmail.com  Wed Jan  8 22:49:21 2014
From: loganaden at gmail.com (Loganaden Velvindron)
Date: Wed, 8 Jan 2014 15:49:21 +0400
Subject: OpenSSH 6.4 connection to Cisco 6506 routers/switches fails
In-Reply-To: <CALDDTe0AXQQyerAHQMLjxUC=jqCiGdAjgjzmT68NM_-w7jxdiA@mail.gmail.com>
References: <Pine.GSO.4.64.1311121621111.28075@kraken.noc.utoronto.ca>
 <CALDDTe3gjR6G4AHCNYfMwf44AMb1C=qPxDwkjbj1KJwLRvazpA@mail.gmail.com>
 <CAOp4FwRGoY8abfKjGd-sovHQ-831AeFnrFz+o7Cm+9u-nwfmXw@mail.gmail.com>
 <Pine.GSO.4.64.1312231309290.2856@kraken.noc.utoronto.ca>
 <CALDDTe0AXQQyerAHQMLjxUC=jqCiGdAjgjzmT68NM_-w7jxdiA@mail.gmail.com>
Message-ID: <CAOp4FwRbT=KKTpGFv9rNvtL57T6swbMm9HcHeci=6cySnW7LpQ@mail.gmail.com>

On Tue, Dec 24, 2013 at 4:00 AM, Darren Tucker <dtucker at zip.com.au> wrote:
> On Tue, Dec 24, 2013 at 7:52 AM,  <mikep at noc.utoronto.ca> wrote:
> [...]
>> Sorry to have taken so long to get back to you about this - your suggestion
>> about "KexAlgorithms" caused me to test a lot of combinations to find what
>> will work. It turns out the Cisco SSH server only supports a limited set of
>> ciphers (this is documented sort-of by Cisco, and is displayed when you try
>> to force a non-supported cipher).
>>
>> This in turn seems to limit the key exchange mechanisms that will work.
>>
>> Forcing a cipher with '-c' also appears to force something in the Kex for
>> OpenSSH; I can't find anything about Kex in any Cisco docs.
>
> I'm happy you found something that works, but the SSH protocol 2
> negotiation should allow it to negotiate a mutually-compatible set of
> algorithms or to definitively tell you that no such set exists.  The
> fact that it hangs with some settings means there's still a bug in
> there somewhere.
>
> Did you get a response from Cisco?

Off topic:
I tried connecting to a CISCO router and it doesn't offer blowfish as
a cipher :-(

http://www.cisco.com/en/US/tech/tk583/tk617/technologies_q_and_a_item09186a0080267e0f.shtml#qa8

I think it's time we all start lobbying CISCO to ship the new
cipher/mac/kex algorithms that are going
to ship with OpenSSH 6.5 when it's going to be released.





>
> --
> 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.



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

From loganaden at gmail.com  Wed Jan  8 23:49:03 2014
From: loganaden at gmail.com (Loganaden Velvindron)
Date: Wed, 8 Jan 2014 16:49:03 +0400
Subject: OpenSSH 6.4 connection to Cisco 6506 routers/switches fails
In-Reply-To: <Pine.GSO.4.64.1312231309290.2856@kraken.noc.utoronto.ca>
References: <Pine.GSO.4.64.1311121621111.28075@kraken.noc.utoronto.ca>
 <CALDDTe3gjR6G4AHCNYfMwf44AMb1C=qPxDwkjbj1KJwLRvazpA@mail.gmail.com>
 <CAOp4FwRGoY8abfKjGd-sovHQ-831AeFnrFz+o7Cm+9u-nwfmXw@mail.gmail.com>
 <Pine.GSO.4.64.1312231309290.2856@kraken.noc.utoronto.ca>
Message-ID: <CAOp4FwQqHteVaWr99jB8f+GzHAvt85ARc=vLo+WAX7Y3ciSzpQ@mail.gmail.com>

On Tue, Dec 24, 2013 at 12:52 AM,  <mikep at noc.utoronto.ca> wrote:
> On Wed, 13 Nov 2013, Loganaden Velvindron wrote:
>
>> On Wed, Nov 13, 2013 at 2:05 AM, Darren Tucker <dtucker at zip.com.au> wrote:
>>>
>>> On Tue, Nov 12, 2013 at 4:40 PM, <mikep at noc.utoronto.ca> wrote:
>>>
>>>> Just upgraded to OpenSSH_6.4 with OpenSSL 1.0.1e and libz.so.1.2.8.
>>>> Now some (but not all) Cisco router logins hang:
>>>>
>>>> debug1: sending SSH2_MSG_KEXDH_INIT
>>>> debug1: expecting SSH2_MSG_KEXDH_REPLY
>>>>  [hangs]
>>>>
>>>
>>> Suggestions in approximate order of likelihood.
>>>  - the additional KexAlgorithms exceed some static buffer in the Cisco.
>>>  Try:
>>> "KexAlgorithms
>>> diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1"
>>>  - you have some kind of path MTU problem and the extra traffic from the
>>> additional algorithms pushes you past some packet boundary.  Check the
>>> "send-q" column on client and the equivalent on the server and see if
>>> they're non-zero and non-decreasing).
>>
>>
>> Shouldn't Mike open a ticket at CISCO so that they start fixing the
>> software on their side as well ?
>
>
> Sorry to have taken so long to get back to you about this - your suggestion
> about "KexAlgorithms" caused me to test a lot of combinations to find what
> will work. It turns out the Cisco SSH server only supports a limited set of
> ciphers (this is documented sort-of by Cisco, and is displayed when you try
> to force a non-supported cipher).

That's short-sighted coming from them.

I have tested and I have the same problem with the latest snapshot. This is very
annoying.

Do you have a ticket number where I can also chip in ?


>
> This in turn seems to limit the key exchange mechanisms that will work.
>
> Forcing a cipher with '-c' also appears to force something in the Kex for
> OpenSSH; I can't find anything about Kex in any Cisco docs.
>
> I have created a special section of the 'ssh_config' file for those devices
> with these options, and all seems to be working fine:
>
> Ciphers aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
> KexAlgorithms
> diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchan
> ge-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
>
> Thank you for the help!
>
>
>>>> Originally I had 'Cipher blowfish' set in '/etc/ssh/ssh_config', but
>>>> removing that makes no difference.
>>>
>>>
>>> That's because Cipher affects only Protocol 1 (which was some time in the
>>> past the only version at least some Cisco devices spoke).
>>>
>>>> However, forcing '-c 3des' does
>>>> allow it to work (even though '3des' is supposed to be the default):
>>>
>>>
>>> 3des is the default Cipher Protocol 1.  Protocol 2 takes a list (Ciphers)
>>> and its default is
>>>
>>>                 aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,
>>>                 aes128-gcm at openssh.com,aes256-gcm at openssh.com,
>>>                 aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,
>>>                 aes256-cbc,arcfour
>>>
>>> the -c option overrides both.
>>>
>>> --
>>> Darren Tucker (dtucker at zip.com.au)
>>> GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
>>>     Good judgement comes with experience. Unfortunately, the experience
>>> usually comes from bad judgement.
>>> _______________________________________________
>>> openssh-unix-dev mailing list
>>> openssh-unix-dev at mindrot.org
>>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
>
> Mike
> --
> Mike Peterson                            Information Security Analyst -
> Audit
> E-mail: mikep at noc.utoronto.ca                WWW:
> http://www.noc.utoronto.ca/
> Tel: 416-978-5230                                           Fax:
> 416-978-6620



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

From mikep at noc.utoronto.ca  Thu Jan  9 04:30:09 2014
From: mikep at noc.utoronto.ca (mikep at noc.utoronto.ca)
Date: Wed, 8 Jan 2014 12:30:09 -0500 (EST)
Subject: OpenSSH 6.4 connection to Cisco 6506 routers/switches fails
In-Reply-To: <CAOp4FwQqHteVaWr99jB8f+GzHAvt85ARc=vLo+WAX7Y3ciSzpQ@mail.gmail.com>
References: <Pine.GSO.4.64.1311121621111.28075@kraken.noc.utoronto.ca>
 <CALDDTe3gjR6G4AHCNYfMwf44AMb1C=qPxDwkjbj1KJwLRvazpA@mail.gmail.com>
 <CAOp4FwRGoY8abfKjGd-sovHQ-831AeFnrFz+o7Cm+9u-nwfmXw@mail.gmail.com>
 <Pine.GSO.4.64.1312231309290.2856@kraken.noc.utoronto.ca>
 <CAOp4FwQqHteVaWr99jB8f+GzHAvt85ARc=vLo+WAX7Y3ciSzpQ@mail.gmail.com>
Message-ID: <Pine.GSO.4.64.1401081227390.17064@kraken.noc.utoronto.ca>

On Wed, 8 Jan 2014, Loganaden Velvindron wrote:

> On Tue, Dec 24, 2013 at 12:52 AM,  <mikep at noc.utoronto.ca> wrote:
>> On Wed, 13 Nov 2013, Loganaden Velvindron wrote:
>>
>>> On Wed, Nov 13, 2013 at 2:05 AM, Darren Tucker <dtucker at zip.com.au> wrote:
>>>>
>>>> On Tue, Nov 12, 2013 at 4:40 PM, <mikep at noc.utoronto.ca> wrote:
>>>>
>>>>> Just upgraded to OpenSSH_6.4 with OpenSSL 1.0.1e and libz.so.1.2.8.
>>>>> Now some (but not all) Cisco router logins hang:
>>>>>
>>>>> debug1: sending SSH2_MSG_KEXDH_INIT
>>>>> debug1: expecting SSH2_MSG_KEXDH_REPLY
>>>>>  [hangs]
>>>>>
>>>>
>>>> Suggestions in approximate order of likelihood.
>>>>  - the additional KexAlgorithms exceed some static buffer in the Cisco.
>>>>  Try:
>>>> "KexAlgorithms
>>>> diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1"
>>>>  - you have some kind of path MTU problem and the extra traffic from the
>>>> additional algorithms pushes you past some packet boundary.  Check the
>>>> "send-q" column on client and the equivalent on the server and see if
>>>> they're non-zero and non-decreasing).
>>>
>>>
>>> Shouldn't Mike open a ticket at CISCO so that they start fixing the
>>> software on their side as well ?
>>
>>
>> Sorry to have taken so long to get back to you about this - your suggestion
>> about "KexAlgorithms" caused me to test a lot of combinations to find what
>> will work. It turns out the Cisco SSH server only supports a limited set of
>> ciphers (this is documented sort-of by Cisco, and is displayed when you try
>> to force a non-supported cipher).
>
> That's short-sighted coming from them.
>
> I have tested and I have the same problem with the latest snapshot. This 
> is very annoying.
>
> Do you have a ticket number where I can also chip in ?

I have no access to open Cisco tickets, and our local router person who
does is still away (like most universities, we've been closed for the
past few weeks).

I'll talk to him when he gets back, but agree this is very annoying.

>> This in turn seems to limit the key exchange mechanisms that will work.
>>
>> Forcing a cipher with '-c' also appears to force something in the Kex for
>> OpenSSH; I can't find anything about Kex in any Cisco docs.
>>
>> I have created a special section of the 'ssh_config' file for those devices
>> with these options, and all seems to be working fine:
>>
>> Ciphers aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
>> KexAlgorithms
>> diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchan
>> ge-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
>>
>> Thank you for the help!
>>
>>
>>>>> Originally I had 'Cipher blowfish' set in '/etc/ssh/ssh_config', but
>>>>> removing that makes no difference.
>>>>
>>>>
>>>> That's because Cipher affects only Protocol 1 (which was some time in the
>>>> past the only version at least some Cisco devices spoke).
>>>>
>>>>> However, forcing '-c 3des' does
>>>>> allow it to work (even though '3des' is supposed to be the default):
>>>>
>>>>
>>>> 3des is the default Cipher Protocol 1.  Protocol 2 takes a list (Ciphers)
>>>> and its default is
>>>>
>>>>                 aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,
>>>>                 aes128-gcm at openssh.com,aes256-gcm at openssh.com,
>>>>                 aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,
>>>>                 aes256-cbc,arcfour
>>>>
>>>> the -c option overrides both.
>>>>
>>>> --
>>>> Darren Tucker (dtucker at zip.com.au)
>>>> GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
>>>>     Good judgement comes with experience. Unfortunately, the experience
>>>> usually comes from bad judgement.
>>>> _______________________________________________
>>>> openssh-unix-dev mailing list
>>>> openssh-unix-dev at mindrot.org
>>>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>
>>
>> Mike
>> --
>> Mike Peterson                            Information Security Analyst -
>> Audit
>> E-mail: mikep at noc.utoronto.ca                WWW:
>> http://www.noc.utoronto.ca/
>> Tel: 416-978-5230                                           Fax:
>> 416-978-6620

--
Mike Peterson                            Information Security Analyst - Audit
E-mail: mikep at noc.utoronto.ca                WWW: http://www.noc.utoronto.ca/
Tel: 416-978-5230                                           Fax: 416-978-6620

From dkg at fifthhorseman.net  Thu Jan  9 06:40:31 2014
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Wed, 08 Jan 2014 14:40:31 -0500
Subject: OpenSSH 6.4 connection to Cisco 6506 routers/switches fails
In-Reply-To: <Pine.GSO.4.64.1401081227390.17064@kraken.noc.utoronto.ca>
References: <Pine.GSO.4.64.1311121621111.28075@kraken.noc.utoronto.ca>
 <CALDDTe3gjR6G4AHCNYfMwf44AMb1C=qPxDwkjbj1KJwLRvazpA@mail.gmail.com>
 <CAOp4FwRGoY8abfKjGd-sovHQ-831AeFnrFz+o7Cm+9u-nwfmXw@mail.gmail.com>
 <Pine.GSO.4.64.1312231309290.2856@kraken.noc.utoronto.ca>
 <CAOp4FwQqHteVaWr99jB8f+GzHAvt85ARc=vLo+WAX7Y3ciSzpQ@mail.gmail.com>
 <Pine.GSO.4.64.1401081227390.17064@kraken.noc.utoronto.ca>
Message-ID: <52CDA9AF.8030204@fifthhorseman.net>

[re: http://marc.info/?l=openssh-unix-dev&m=138920224702016&w=2 and
previous discussion]

On 01/08/2014 12:30 PM, mikep at noc.utoronto.ca wrote:
> On Wed, 8 Jan 2014, Loganaden Velvindron <loganaden at gmail.com> wrote:
>> On Tue, Dec 24, 2013 at 12:52 AM,  <mikep at noc.utoronto.ca> wrote:
>>>  It turns out the Cisco SSH server only supports a limited set of
>>> ciphers (this is documented sort-of by Cisco, and is displayed when
>>> you try to force a non-supported cipher).
>>
>> That's short-sighted coming from them.
>>
>> I have tested and I have the same problem with the latest snapshot.
>> This is very annoying.
>>
>> Do you have a ticket number where I can also chip in ?
> 
> I have no access to open Cisco tickets, and our local router person who
> does is still away (like most universities, we've been closed for the
> past few weeks).
> 
> I'll talk to him when he gets back, but agree this is very annoying.

fwiw, one of the co-chairs of the IRTF's Crypto Forum Research Group is
David McGrew, who works for Cisco:

 https://www.irtf.org/cfrg

I'm cc'ing David here, because i figure he would be interested in
hearing this concern about cryptographic choices in Cisco's products,
though i don't know whether his position within Cisco gives him the
ability to address the situation.  At the very least, i figure he'd want
to be aware of it.

Regards,

	--dkg


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

From keisial at gmail.com  Thu Jan  9 11:12:33 2014
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Thu, 09 Jan 2014 01:12:33 +0100
Subject: Segmentation faut on mips device
In-Reply-To: <E3C33139-F9F3-4FD1-A733-2B9140DEEF11@me.com>
References: <5DF7F25F-10C8-4151-A380-3654A2FCDEB0@me.com>
 <CALDDTe2gzoSh10kN-bvw7VW3HSB267NcT3r1Ly6tRvy4-XEynA@mail.gmail.com>
 <E3C33139-F9F3-4FD1-A733-2B9140DEEF11@me.com>
Message-ID: <52CDE971.7050804@gmail.com>

On 07/01/14 16:30, ANDREY ROZE wrote:
> I managed to compile the gdb debugger for the target architecture and run under gdb
> That's what he gave me :
>
> This GDB was configured as "mips-unknown-linux-gnu".
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>  ...
> Reading symbols from / bin / ssh...done.
> (gdb) run
> Starting program: / bin / ssh
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x555887e0 in?? ()
>
>
> I also tried to run ssh with -vvv. With the same result.
> I also did an experiment . Replaced the source code to the stub ssh.c "hellow world", the program also issued a segmentation fault.
>
> I'm not sure but it may be a bug associated with the correct configuration at compile time.
> I tried to configure with default settings , but there were errors . I had to add two flag -fPIC-shared. Finally make looks like:
If even if a simple a hello world segfaults*, then I would point to your 
compiler as creating wrong executables, and it wouldn't be openssh fault.

* I understand that's what you done above,but perhaps you did something 
a bit different.


From picsolvebryan at gmail.com  Thu Jan  9 23:32:12 2014
From: picsolvebryan at gmail.com (bryan hunt)
Date: Thu, 9 Jan 2014 12:32:12 +0000
Subject: OSX - SSH agent functionality differing based upon CLI arguments 
Message-ID: <8E835267-780D-4EA5-B41D-CF068361D412@gmail.com>


Trying to get SSH agent forwarding working for a popular open source configuration management system called Ansible.

I?ve had some unexpected behaviour, the only cause of which I can find is how I express the command line arguments.

http://stackoverflow.com/questions/20952689/vagrant-ssh-agent-forwarding-how-is-it-working?noredirect=1#comment31511341_20952689

In summarise:

In the first instance I can create a SSH connection, and and execute a remote git clone (via SSH), the Agent Forwarding works, and I am not prompted for credentials:

ssh vagrant at 127.0.0.1 -p 2222 \
-o Compression=yes \
-o StrictHostKeyChecking=no \
-o LogLevel=FATAL \
-o StrictHostKeyChecking=no \
-o UserKnownHostsFile=/dev/null \
-o IdentitiesOnly=yes \
-i /Users/bryanhunt/.vagrant.d/insecure_private_key \
-o ForwardAgent=yes \
"/bin/sh  -c 'git clone git at bitbucket.org:bryan_picsolve/poc_docker.git /home/vagrant/poc_dockera' "
Cloning into '/home/vagrant/poc_dockera'...

In the second instance I express the arguments differently ( -o HostName=127.0.0.1 -o User=vagrant ), and Agent Forwarding doesn?t seem to work:

ssh -o HostName=127.0.0.1 -o User=vagrant -p 2222 \
-o Compression=yes \
-o StrictHostKeyChecking=no \
-o LogLevel=FATAL \
-o StrictHostKeyChecking=no \
-o UserKnownHostsFile=/dev/null \
-o IdentitiesOnly=yes \
-i /Users/bryanhunt/.vagrant.d/insecure_private_key \
-o ForwardAgent=yes \
"/bin/sh  -c 'git clone git at bitbucket.org:bryan_picsolve/poc_docker.git /home/vagrant/poc_dockerb' "
/bin/sh  -c 'git clone git at 127.0.0.1's password:

The client side SSH is:

OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011

The server side SSH is:

OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012


Have any of the list members got an insight into this behaviour ?

Thanks in advance, 

Bryan Hunt







From mfriedl at gmail.com  Fri Jan 10 00:21:17 2014
From: mfriedl at gmail.com (Markus Friedl)
Date: Thu, 9 Jan 2014 14:21:17 +0100
Subject: OSX - SSH agent functionality differing based upon CLI arguments
In-Reply-To: <8E835267-780D-4EA5-B41D-CF068361D412@gmail.com>
References: <8E835267-780D-4EA5-B41D-CF068361D412@gmail.com>
Message-ID: <BDB13A1C-1E5C-42A0-B6A4-CB28BD14ED40@gmail.com>

The 2nd example misses the required hostname argument.




> Am 09.01.2014 um 13:32 schrieb bryan hunt <picsolvebryan at gmail.com>:
> 
> 
> Trying to get SSH agent forwarding working for a popular open source configuration management system called Ansible.
> 
> I?ve had some unexpected behaviour, the only cause of which I can find is how I express the command line arguments.
> 
> http://stackoverflow.com/questions/20952689/vagrant-ssh-agent-forwarding-how-is-it-working?noredirect=1#comment31511341_20952689
> 
> In summarise:
> 
> In the first instance I can create a SSH connection, and and execute a remote git clone (via SSH), the Agent Forwarding works, and I am not prompted for credentials:
> 
> ssh vagrant at 127.0.0.1 -p 2222 \
> -o Compression=yes \
> -o StrictHostKeyChecking=no \
> -o LogLevel=FATAL \
> -o StrictHostKeyChecking=no \
> -o UserKnownHostsFile=/dev/null \
> -o IdentitiesOnly=yes \
> -i /Users/bryanhunt/.vagrant.d/insecure_private_key \
> -o ForwardAgent=yes \
> "/bin/sh  -c 'git clone git at bitbucket.org:bryan_picsolve/poc_docker.git /home/vagrant/poc_dockera' "
> Cloning into '/home/vagrant/poc_dockera'...
> 
> In the second instance I express the arguments differently ( -o HostName=127.0.0.1 -o User=vagrant ), and Agent Forwarding doesn?t seem to work:
> 
> ssh -o HostName=127.0.0.1 -o User=vagrant -p 2222 \
> -o Compression=yes \
> -o StrictHostKeyChecking=no \
> -o LogLevel=FATAL \
> -o StrictHostKeyChecking=no \
> -o UserKnownHostsFile=/dev/null \
> -o IdentitiesOnly=yes \
> -i /Users/bryanhunt/.vagrant.d/insecure_private_key \
> -o ForwardAgent=yes \
> "/bin/sh  -c 'git clone git at bitbucket.org:bryan_picsolve/poc_docker.git /home/vagrant/poc_dockerb' "
> /bin/sh  -c 'git clone git at 127.0.0.1's password:
> 
> The client side SSH is:
> 
> OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
> 
> The server side SSH is:
> 
> OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
> 
> 
> Have any of the list members got an insight into this behaviour ?
> 
> Thanks in advance, 
> 
> Bryan Hunt
> 
> 
> 
> 
> 
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From darryl-mailinglists at netbauds.net  Fri Jan 10 03:48:37 2014
From: darryl-mailinglists at netbauds.net (Darryl L. Miles)
Date: Thu, 09 Jan 2014 16:48:37 +0000
Subject: ServerAliveCountMax (and Client) waits for TCP timeout before process
 exit
Message-ID: <52CED2E5.8080507@netbauds.net>



I am of the opinion that ClientAliveCountMax should really force a 
disconnection from the testing side when a ping-pong control packet 
retransmission would exceed the max counter.

But it appears to need TCP to timeout to occur from that point, for the 
process/tty to close.



For SSH client options:
  -o ServerAliveInterval=60
  -o ServerAliveCountMax=3
Should cause the client to force an immediate disconnection at 240 
seconds, when the 4th retry would have been attempted.


For SSH server options:
   -o ClientAliveInternal=60
   -o ClientAliveCountMax=3
Should cause the server to force an immediate disconnection at 240 
seconds, when the 4th retry would have been attempted.



Can anyone confirm if this was/is the intention of this feature ?

This way the client/server administrator have better control over the 
timescales for recovery.



At the moment in my usage of this feature once a timeout has occurred, 
the SSH server/SSH client appears to wait for a TCP socket timeout to 
occur which is approximately 15 minutes after TCP backoff and 
retransmissions, etc...  So in the above configuration it takes up to 19 
minutes (4 mins for SSH to notice and 15 minutes for TCP to timeout).

This behaviour sets a floor on the minimum timeout value possible to 
recover a connection, that I can not think of a use case for ?  Can you?

The scenario is that connectivity between the IPs has been lost, or 
changed, such that TCP RST packets will no occur durign the TCP 
retransmissions.


NOTE: It was some weeks ago I tested this theory out and has taken me 
get to writing an email to the list, I hope I got the details right.


Thanks,

Darryl


From darryl-mailinglists at netbauds.net  Fri Jan 10 04:18:51 2014
From: darryl-mailinglists at netbauds.net (Darryl Miles)
Date: Thu, 09 Jan 2014 17:18:51 +0000
Subject: Server/Client Alive mechanism issues
In-Reply-To: <4F203B4A.6050305@ll.mit.edu>
References: <4F203B4A.6050305@ll.mit.edu>
Message-ID: <52CED9FB.6060606@netbauds.net>



Old thread I know but I have opposite problem.  Maybe SSH was changed in 
connection with this  report ?  See my recent (Jan 2014) ML thread.

I am observing SSH waiting for a TCP level timeout to occur when the 
other end has done away (and it not sending back any data or TCP RST).



Jeff Mitchell wrote:
> I have a bandwidth-constrained connection that I'd like to run rsync
> over through an SSH tunnel. I also want to detect any network drops
> pretty rapidly.

If you are bandwidth constrained why are you wasting bandwidth on 1 
second ping-pongs ?  What % of your overall data are you wasting on that 
effort?

Does your usage of the application require connection recovery (for a 
stalled, non-working connection) within 10s of seconds ?  So you are in 
a bandwidth contained environment trying to send bulk data and must know 
if the other end has become unavailable within 6 seconds of it doing so ?

If you're bandwidth constrained I would have thought both ends would be 
patient when waiting for data and turning up Interval (like 10 seconds) 
and turning down CountMax (like 2) is a better way to go, increasing 
Interval as necessary.


> After about 5 seconds, the connection is being dropped, but during that
> time the rsync is successfully transferring data near the full bandwidth
> of the connection.

Maybe you can ask SSH client/server (on both sides or at least the side 
with the most data being pushed) to turn down the SO_SNDBUF to the 
minimize the kernel buffer.  This can be done on a socket by socket 
basis using C kernel API setsockopt().  So is something ssh/sshd needs 
to implement on your behalf.

When the connection is sending if you run "netstat -tanp" (on Linux) the 
number of bytes in the kernel buffer will be shown in the Send-Q. 
Reducing SO_SNDBUF decreases this value but with the effect of causing 
the sending process to wake up more often to refill the kernel buffer. 
It sounds like your CPU processing power far exceed the network 
throughput so I do not think this will be a concern in your scenario. 
The lowest value for SO_SNDBUF according to Linux man page is 2048  bytes.

Note if you make this value too low and your CPU does not refill the 
kernel buffer and it underruns (i.e. the TCP stack could send data but 
there was none available as the application did not wakeup and write() 
data quick enough) it will mess up performance as TCP slow start 
congestion control may reset causing overall measured throughput to drop.


man 7 socket (search SO_SNDBUF)
man 7 tcp

On Linux see also /proc/sys/net/core/wmem_default for system wide 
default of SSH application does not have option.

You can 'cat /proc/sys/net/core/wmem_default' to see the current value, 
going below 32k for 100mbit (or better) ethernet system is probably a 
bad idea.

Note on the bandwidth restricted application you want to tweak it, 
setting it too low will have a major effect on normal performance of a 
normal Ethernet based system.


>
> My understanding is that since the alive mechanism is running inside the
> encrypted connection, OpenSSH would be able to (and would) prioritize
> the alive packets over other data. So if any data is able to get through
> (and it does) the alive packets should be able to as well. But this
> doesn't seem to be the case.

No.  While SSH is able to multiplex different streams inside a single 
TCP connection, the aggregated stream is still subject to kernel Send-Q 
buffering and then network latency, congestion and performance metrics.


So what are doing is taking system memory and Ethernet performance tuned 
parameters for networking (in the cause of Linux again) and trying to 
use them with bandwidth restricted connectivity.

The default OS picked wmem/sendq is based on system memory and other 
such inter-related params allowing auto-tune.


Darryl



From picsolvebryan at gmail.com  Fri Jan 10 04:43:08 2014
From: picsolvebryan at gmail.com (bryan hunt)
Date: Thu, 9 Jan 2014 17:43:08 +0000
Subject: OSX - SSH agent functionality differing based upon CLI arguments
In-Reply-To: <4E41EE56-A482-4355-8256-0D15AFD7793B@gmail.com>
References: <8E835267-780D-4EA5-B41D-CF068361D412@gmail.com>
 <BDB13A1C-1E5C-42A0-B6A4-CB28BD14ED40@gmail.com>
 <1246AE7E-91C9-4427-9444-9868CCD156DC@gmail.com>
 <4E41EE56-A482-4355-8256-0D15AFD7793B@gmail.com>
Message-ID: <55F5E4A1-40DF-47E3-83DA-98A37EE1EB9F@gmail.com>

Yes, called as you describe, SSH works correctly (it Forwards Agent). Quirky!

But, called the way I was doing, everything but Agent Forwarding works. 

Strange. Looking further, I found another odd behaviour. 

ssh -o User=vagrant -o Hostname=127.0.0.1 -p 2222 -o Compression=yes -o StrictHostKeyChecking=no -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o IdentitiesOnly=yes -i /Users/bryanhunt/.vagrant.d/insecure_private_key -o ForwardAgent=yes -o LogLevel=DEBUG "" "/bin/sh  -c 'git clone git at bitbucket.org:bryan_picsolve/poc_docker.git /home/vagrant/poc_dockerddd? "

Note how I added the empty quoted string in the hostname position. 

SSH Agent Forwarding works if I add that empty quoted string. 

If I remove the empty quoted string, the git checkout is executed, but prompts for authentication.

I would expect SSH to completely succeed, or completely fail to execute the command - rather than have the side channel (SSH agent) fail or succeed based upon how I express the command line arguments. 

This is a stock version of the ssh command on OSX.

The checksum is:

MD5 (/usr/bin/ssh) = 35caacee333ebae93d4087ca349738e4

Perhaps another OSX user could verify this behaviour? 

Regards,

Bryan Hunt


On 9 Jan 2014, at 17:21, Markus Friedl <mfriedl at gmail.com> wrote:

> You pass it as an option. 
> 
> But ssh is called like 
> 
> $ ssh [options] hostname [command]
> 
> 
> 
> 
> 
>> Am 09.01.2014 um 16:21 schrieb bryan hunt <picsolvebryan at gmail.com>:
>> 
>> 
>> I don?t understand, in the second example, "ssh -o HostName=127.0.0.1 ?, is the very first argument to the program?
>> 
>> 
>> 
>>> On 9 Jan 2014, at 13:21, Markus Friedl <mfriedl at gmail.com> wrote:
>>> 
>>> The 2nd example misses the required hostname argument.
>>> 
>>> 
>>> 
>>> 
>>>> Am 09.01.2014 um 13:32 schrieb bryan hunt <picsolvebryan at gmail.com>:
>>>> 
>>>> 
>>>> Trying to get SSH agent forwarding working for a popular open source configuration management system called Ansible.
>>>> 
>>>> I?ve had some unexpected behaviour, the only cause of which I can find is how I express the command line arguments.
>>>> 
>>>> http://stackoverflow.com/questions/20952689/vagrant-ssh-agent-forwarding-how-is-it-working?noredirect=1#comment31511341_20952689
>>>> 
>>>> In summarise:
>>>> 
>>>> In the first instance I can create a SSH connection, and and execute a remote git clone (via SSH), the Agent Forwarding works, and I am not prompted for credentials:
>>>> 
>>>> ssh vagrant at 127.0.0.1 -p 2222 \
>>>> -o Compression=yes \
>>>> -o StrictHostKeyChecking=no \
>>>> -o LogLevel=FATAL \
>>>> -o StrictHostKeyChecking=no \
>>>> -o UserKnownHostsFile=/dev/null \
>>>> -o IdentitiesOnly=yes \
>>>> -i /Users/bryanhunt/.vagrant.d/insecure_private_key \
>>>> -o ForwardAgent=yes \
>>>> "/bin/sh  -c 'git clone git at bitbucket.org:bryan_picsolve/poc_docker.git /home/vagrant/poc_dockera' "
>>>> Cloning into '/home/vagrant/poc_dockera'...
>>>> 
>>>> In the second instance I express the arguments differently ( -o HostName=127.0.0.1 -o User=vagrant ), and Agent Forwarding doesn?t seem to work:
>>>> 
>>>> ssh -o HostName=127.0.0.1 -o User=vagrant -p 2222 \
>>>> -o Compression=yes \
>>>> -o StrictHostKeyChecking=no \
>>>> -o LogLevel=FATAL \
>>>> -o StrictHostKeyChecking=no \
>>>> -o UserKnownHostsFile=/dev/null \
>>>> -o IdentitiesOnly=yes \
>>>> -i /Users/bryanhunt/.vagrant.d/insecure_private_key \
>>>> -o ForwardAgent=yes \
>>>> "/bin/sh  -c 'git clone git at bitbucket.org:bryan_picsolve/poc_docker.git /home/vagrant/poc_dockerb' "
>>>> /bin/sh  -c 'git clone git at 127.0.0.1's password:
>>>> 
>>>> The client side SSH is:
>>>> 
>>>> OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
>>>> 
>>>> The server side SSH is:
>>>> 
>>>> OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
>>>> 
>>>> 
>>>> Have any of the list members got an insight into this behaviour ?
>>>> 
>>>> Thanks in advance, 
>>>> 
>>>> Bryan Hunt
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> openssh-unix-dev mailing list
>>>> openssh-unix-dev at mindrot.org
>>>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>> 


From mfriedl at gmail.com  Fri Jan 10 07:12:09 2014
From: mfriedl at gmail.com (Markus Friedl)
Date: Thu, 9 Jan 2014 21:12:09 +0100
Subject: OSX - SSH agent functionality differing based upon CLI arguments
In-Reply-To: <55F5E4A1-40DF-47E3-83DA-98A37EE1EB9F@gmail.com>
References: <8E835267-780D-4EA5-B41D-CF068361D412@gmail.com>
 <BDB13A1C-1E5C-42A0-B6A4-CB28BD14ED40@gmail.com>
 <1246AE7E-91C9-4427-9444-9868CCD156DC@gmail.com>
 <4E41EE56-A482-4355-8256-0D15AFD7793B@gmail.com>
 <55F5E4A1-40DF-47E3-83DA-98A37EE1EB9F@gmail.com>
Message-ID: <BE188C07-E50D-474D-B374-68A37BBB0D04@gmail.com>

This is due to ssh's flexible argument parsing. If you skip the hostname, them something else is interpreted as the hostname. 




> Am 09.01.2014 um 18:43 schrieb bryan hunt <picsolvebryan at gmail.com>:
> 
> Yes, called as you describe, SSH works correctly (it Forwards Agent). Quirky!
> 
> But, called the way I was doing, everything but Agent Forwarding works. 
> 
> Strange. Looking further, I found another odd behaviour. 
> 
> ssh -o User=vagrant -o Hostname=127.0.0.1 -p 2222 -o Compression=yes -o StrictHostKeyChecking=no -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o IdentitiesOnly=yes -i /Users/bryanhunt/.vagrant.d/insecure_private_key -o ForwardAgent=yes -o LogLevel=DEBUG "" "/bin/sh  -c 'git clone git at bitbucket.org:bryan_picsolve/poc_docker.git /home/vagrant/poc_dockerddd? "
> 
> Note how I added the empty quoted string in the hostname position. 
> 
> SSH Agent Forwarding works if I add that empty quoted string. 
> 
> If I remove the empty quoted string, the git checkout is executed, but prompts for authentication.
> 
> I would expect SSH to completely succeed, or completely fail to execute the command - rather than have the side channel (SSH agent) fail or succeed based upon how I express the command line arguments. 
> 
> This is a stock version of the ssh command on OSX.
> 
> The checksum is:
> 
> MD5 (/usr/bin/ssh) = 35caacee333ebae93d4087ca349738e4
> 
> Perhaps another OSX user could verify this behaviour? 
> 
> Regards,
> 
> Bryan Hunt
> 
> 
>> On 9 Jan 2014, at 17:21, Markus Friedl <mfriedl at gmail.com> wrote:
>> 
>> You pass it as an option. 
>> 
>> But ssh is called like 
>> 
>> $ ssh [options] hostname [command]
>> 
>> 
>> 
>> 
>> 
>>> Am 09.01.2014 um 16:21 schrieb bryan hunt <picsolvebryan at gmail.com>:
>>> 
>>> 
>>> I don?t understand, in the second example, "ssh -o HostName=127.0.0.1 ?, is the very first argument to the program?
>>> 
>>> 
>>> 
>>>> On 9 Jan 2014, at 13:21, Markus Friedl <mfriedl at gmail.com> wrote:
>>>> 
>>>> The 2nd example misses the required hostname argument.
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> Am 09.01.2014 um 13:32 schrieb bryan hunt <picsolvebryan at gmail.com>:
>>>>> 
>>>>> 
>>>>> Trying to get SSH agent forwarding working for a popular open source configuration management system called Ansible.
>>>>> 
>>>>> I?ve had some unexpected behaviour, the only cause of which I can find is how I express the command line arguments.
>>>>> 
>>>>> http://stackoverflow.com/questions/20952689/vagrant-ssh-agent-forwarding-how-is-it-working?noredirect=1#comment31511341_20952689
>>>>> 
>>>>> In summarise:
>>>>> 
>>>>> In the first instance I can create a SSH connection, and and execute a remote git clone (via SSH), the Agent Forwarding works, and I am not prompted for credentials:
>>>>> 
>>>>> ssh vagrant at 127.0.0.1 -p 2222 \
>>>>> -o Compression=yes \
>>>>> -o StrictHostKeyChecking=no \
>>>>> -o LogLevel=FATAL \
>>>>> -o StrictHostKeyChecking=no \
>>>>> -o UserKnownHostsFile=/dev/null \
>>>>> -o IdentitiesOnly=yes \
>>>>> -i /Users/bryanhunt/.vagrant.d/insecure_private_key \
>>>>> -o ForwardAgent=yes \
>>>>> "/bin/sh  -c 'git clone git at bitbucket.org:bryan_picsolve/poc_docker.git /home/vagrant/poc_dockera' "
>>>>> Cloning into '/home/vagrant/poc_dockera'...
>>>>> 
>>>>> In the second instance I express the arguments differently ( -o HostName=127.0.0.1 -o User=vagrant ), and Agent Forwarding doesn?t seem to work:
>>>>> 
>>>>> ssh -o HostName=127.0.0.1 -o User=vagrant -p 2222 \
>>>>> -o Compression=yes \
>>>>> -o StrictHostKeyChecking=no \
>>>>> -o LogLevel=FATAL \
>>>>> -o StrictHostKeyChecking=no \
>>>>> -o UserKnownHostsFile=/dev/null \
>>>>> -o IdentitiesOnly=yes \
>>>>> -i /Users/bryanhunt/.vagrant.d/insecure_private_key \
>>>>> -o ForwardAgent=yes \
>>>>> "/bin/sh  -c 'git clone git at bitbucket.org:bryan_picsolve/poc_docker.git /home/vagrant/poc_dockerb' "
>>>>> /bin/sh  -c 'git clone git at 127.0.0.1's password:
>>>>> 
>>>>> The client side SSH is:
>>>>> 
>>>>> OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
>>>>> 
>>>>> The server side SSH is:
>>>>> 
>>>>> OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
>>>>> 
>>>>> 
>>>>> Have any of the list members got an insight into this behaviour ?
>>>>> 
>>>>> Thanks in advance, 
>>>>> 
>>>>> Bryan Hunt
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> _______________________________________________
>>>>> 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 loganaden at gmail.com  Fri Jan 10 17:52:56 2014
From: loganaden at gmail.com (Loganaden Velvindron)
Date: Fri, 10 Jan 2014 10:52:56 +0400
Subject: OpenSSH 6.4 connection to Cisco 6506 routers/switches fails
In-Reply-To: <Pine.GSO.4.64.1401081227390.17064@kraken.noc.utoronto.ca>
References: <Pine.GSO.4.64.1311121621111.28075@kraken.noc.utoronto.ca>
 <CALDDTe3gjR6G4AHCNYfMwf44AMb1C=qPxDwkjbj1KJwLRvazpA@mail.gmail.com>
 <CAOp4FwRGoY8abfKjGd-sovHQ-831AeFnrFz+o7Cm+9u-nwfmXw@mail.gmail.com>
 <Pine.GSO.4.64.1312231309290.2856@kraken.noc.utoronto.ca>
 <CAOp4FwQqHteVaWr99jB8f+GzHAvt85ARc=vLo+WAX7Y3ciSzpQ@mail.gmail.com>
 <Pine.GSO.4.64.1401081227390.17064@kraken.noc.utoronto.ca>
Message-ID: <CAOp4FwRfcf6ewuajVRHrSJx3_0a09wFG_v+gZQf4rdK9rqFERA@mail.gmail.com>

On Wed, Jan 8, 2014 at 9:30 PM,  <mikep at noc.utoronto.ca> wrote:
> On Wed, 8 Jan 2014, Loganaden Velvindron wrote:
>
>> On Tue, Dec 24, 2013 at 12:52 AM,  <mikep at noc.utoronto.ca> wrote:
>>>
>>> On Wed, 13 Nov 2013, Loganaden Velvindron wrote:
>>>
>>>> On Wed, Nov 13, 2013 at 2:05 AM, Darren Tucker <dtucker at zip.com.au>
>>>> wrote:
>>>>>
>>>>>
>>>>> On Tue, Nov 12, 2013 at 4:40 PM, <mikep at noc.utoronto.ca> wrote:
>>>>>
>>>>>> Just upgraded to OpenSSH_6.4 with OpenSSL 1.0.1e and libz.so.1.2.8.
>>>>>> Now some (but not all) Cisco router logins hang:
>>>>>>
>>>>>> debug1: sending SSH2_MSG_KEXDH_INIT
>>>>>> debug1: expecting SSH2_MSG_KEXDH_REPLY
>>>>>>  [hangs]
>>>>>>
>>>>>
>>>>> Suggestions in approximate order of likelihood.
>>>>>  - the additional KexAlgorithms exceed some static buffer in the Cisco.
>>>>>  Try:
>>>>> "KexAlgorithms
>>>>>
>>>>> diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1"
>>>>>  - you have some kind of path MTU problem and the extra traffic from
>>>>> the
>>>>> additional algorithms pushes you past some packet boundary.  Check the
>>>>> "send-q" column on client and the equivalent on the server and see if
>>>>> they're non-zero and non-decreasing).
>>>>
>>>>
>>>>
>>>> Shouldn't Mike open a ticket at CISCO so that they start fixing the
>>>> software on their side as well ?
>>>
>>>
>>>
>>> Sorry to have taken so long to get back to you about this - your
>>> suggestion
>>> about "KexAlgorithms" caused me to test a lot of combinations to find
>>> what
>>> will work. It turns out the Cisco SSH server only supports a limited set
>>> of
>>> ciphers (this is documented sort-of by Cisco, and is displayed when you
>>> try
>>> to force a non-supported cipher).
>>
>>
>> That's short-sighted coming from them.
>>
>> I have tested and I have the same problem with the latest snapshot. This
>> is very annoying.
>>
>> Do you have a ticket number where I can also chip in ?
>
>
> I have no access to open Cisco tickets, and our local router person who
> does is still away (like most universities, we've been closed for the
> past few weeks).
>
> I'll talk to him when he gets back, but agree this is very annoying.

I can confirm that the issue is present on the CISCO 1841.


>
>
>>> This in turn seems to limit the key exchange mechanisms that will work.
>>>
>>> Forcing a cipher with '-c' also appears to force something in the Kex for
>>> OpenSSH; I can't find anything about Kex in any Cisco docs.
>>>
>>> I have created a special section of the 'ssh_config' file for those
>>> devices
>>> with these options, and all seems to be working fine:
>>>
>>> Ciphers aes128-cbc,3des-cbc,aes192-cbc,aes256-cbc
>>> KexAlgorithms
>>> diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchan
>>> ge-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
>>>
>>> Thank you for the help!
>>>
>>>
>>>>>> Originally I had 'Cipher blowfish' set in '/etc/ssh/ssh_config', but
>>>>>> removing that makes no difference.
>>>>>
>>>>>
>>>>>
>>>>> That's because Cipher affects only Protocol 1 (which was some time in
>>>>> the
>>>>> past the only version at least some Cisco devices spoke).
>>>>>
>>>>>> However, forcing '-c 3des' does
>>>>>> allow it to work (even though '3des' is supposed to be the default):
>>>>>
>>>>>
>>>>>
>>>>> 3des is the default Cipher Protocol 1.  Protocol 2 takes a list
>>>>> (Ciphers)
>>>>> and its default is
>>>>>
>>>>>                 aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,
>>>>>                 aes128-gcm at openssh.com,aes256-gcm at openssh.com,
>>>>>
>>>>> aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,
>>>>>                 aes256-cbc,arcfour
>>>>>
>>>>> the -c option overrides both.
>>>>>
>>>>> --
>>>>> Darren Tucker (dtucker at zip.com.au)
>>>>> GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
>>>>>     Good judgement comes with experience. Unfortunately, the experience
>>>>> usually comes from bad judgement.
>>>>> _______________________________________________
>>>>> openssh-unix-dev mailing list
>>>>> openssh-unix-dev at mindrot.org
>>>>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>>
>>>
>>>
>>> Mike
>>> --
>>> Mike Peterson                            Information Security Analyst -
>>> Audit
>>> E-mail: mikep at noc.utoronto.ca                WWW:
>>> http://www.noc.utoronto.ca/
>>> Tel: 416-978-5230                                           Fax:
>>> 416-978-6620
>
>
> --
> Mike Peterson                            Information Security Analyst -
> Audit
> E-mail: mikep at noc.utoronto.ca                WWW:
> http://www.noc.utoronto.ca/
> Tel: 416-978-5230                                           Fax:
> 416-978-6620



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

From picsolvebryan at gmail.com  Fri Jan 10 21:16:27 2014
From: picsolvebryan at gmail.com (bryan hunt)
Date: Fri, 10 Jan 2014 10:16:27 +0000
Subject: OSX - SSH agent functionality differing based upon CLI arguments
In-Reply-To: <BE188C07-E50D-474D-B374-68A37BBB0D04@gmail.com>
References: <8E835267-780D-4EA5-B41D-CF068361D412@gmail.com>
 <BDB13A1C-1E5C-42A0-B6A4-CB28BD14ED40@gmail.com>
 <1246AE7E-91C9-4427-9444-9868CCD156DC@gmail.com>
 <4E41EE56-A482-4355-8256-0D15AFD7793B@gmail.com>
 <55F5E4A1-40DF-47E3-83DA-98A37EE1EB9F@gmail.com>
 <BE188C07-E50D-474D-B374-68A37BBB0D04@gmail.com>
Message-ID: <9E47E04B-F6BE-44F8-90CA-DE0410B78D11@gmail.com>

But it isn?t. 

"/bin/sh  -c 'git clone git at bitbucket.org:bryan_picsolve/poc_docker.git /home/vagrant/poc_dockerddd? ? is not interpreted as the hostname, it is executed as a remote command, but without SSH agent working. 

Anyhow, I?m not here to demand a better command line argument parser, merely to verify the behaviour so I can help to resolve the problems that Ansible are having. 

But thank you for the help.

Bryan


On 9 Jan 2014, at 20:12, Markus Friedl <mfriedl at gmail.com> wrote:

> This is due to ssh's flexible argument parsing. If you skip the hostname, them something else is interpreted as the hostname. 
> 
> 
> 
> 
>> Am 09.01.2014 um 18:43 schrieb bryan hunt <picsolvebryan at gmail.com>:
>> 
>> Yes, called as you describe, SSH works correctly (it Forwards Agent). Quirky!
>> 
>> But, called the way I was doing, everything but Agent Forwarding works. 
>> 
>> Strange. Looking further, I found another odd behaviour. 
>> 
>> ssh -o User=vagrant -o Hostname=127.0.0.1 -p 2222 -o Compression=yes -o StrictHostKeyChecking=no -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o IdentitiesOnly=yes -i /Users/bryanhunt/.vagrant.d/insecure_private_key -o ForwardAgent=yes -o LogLevel=DEBUG "" "/bin/sh  -c 'git clone git at bitbucket.org:bryan_picsolve/poc_docker.git /home/vagrant/poc_dockerddd? "
>> 
>> Note how I added the empty quoted string in the hostname position. 
>> 
>> SSH Agent Forwarding works if I add that empty quoted string. 
>> 
>> If I remove the empty quoted string, the git checkout is executed, but prompts for authentication.
>> 
>> I would expect SSH to completely succeed, or completely fail to execute the command - rather than have the side channel (SSH agent) fail or succeed based upon how I express the command line arguments. 
>> 
>> This is a stock version of the ssh command on OSX.
>> 
>> The checksum is:
>> 
>> MD5 (/usr/bin/ssh) = 35caacee333ebae93d4087ca349738e4
>> 
>> Perhaps another OSX user could verify this behaviour? 
>> 
>> Regards,
>> 
>> Bryan Hunt
>> 
>> 
>>> On 9 Jan 2014, at 17:21, Markus Friedl <mfriedl at gmail.com> wrote:
>>> 
>>> You pass it as an option. 
>>> 
>>> But ssh is called like 
>>> 
>>> $ ssh [options] hostname [command]
>>> 
>>> 
>>> 
>>> 
>>> 
>>>> Am 09.01.2014 um 16:21 schrieb bryan hunt <picsolvebryan at gmail.com>:
>>>> 
>>>> 
>>>> I don?t understand, in the second example, "ssh -o HostName=127.0.0.1 ?, is the very first argument to the program?
>>>> 
>>>> 
>>>> 
>>>>> On 9 Jan 2014, at 13:21, Markus Friedl <mfriedl at gmail.com> wrote:
>>>>> 
>>>>> The 2nd example misses the required hostname argument.
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>> Am 09.01.2014 um 13:32 schrieb bryan hunt <picsolvebryan at gmail.com>:
>>>>>> 
>>>>>> 
>>>>>> Trying to get SSH agent forwarding working for a popular open source configuration management system called Ansible.
>>>>>> 
>>>>>> I?ve had some unexpected behaviour, the only cause of which I can find is how I express the command line arguments.
>>>>>> 
>>>>>> http://stackoverflow.com/questions/20952689/vagrant-ssh-agent-forwarding-how-is-it-working?noredirect=1#comment31511341_20952689
>>>>>> 
>>>>>> In summarise:
>>>>>> 
>>>>>> In the first instance I can create a SSH connection, and and execute a remote git clone (via SSH), the Agent Forwarding works, and I am not prompted for credentials:
>>>>>> 
>>>>>> ssh vagrant at 127.0.0.1 -p 2222 \
>>>>>> -o Compression=yes \
>>>>>> -o StrictHostKeyChecking=no \
>>>>>> -o LogLevel=FATAL \
>>>>>> -o StrictHostKeyChecking=no \
>>>>>> -o UserKnownHostsFile=/dev/null \
>>>>>> -o IdentitiesOnly=yes \
>>>>>> -i /Users/bryanhunt/.vagrant.d/insecure_private_key \
>>>>>> -o ForwardAgent=yes \
>>>>>> "/bin/sh  -c 'git clone git at bitbucket.org:bryan_picsolve/poc_docker.git /home/vagrant/poc_dockera' "
>>>>>> Cloning into '/home/vagrant/poc_dockera'...
>>>>>> 
>>>>>> In the second instance I express the arguments differently ( -o HostName=127.0.0.1 -o User=vagrant ), and Agent Forwarding doesn?t seem to work:
>>>>>> 
>>>>>> ssh -o HostName=127.0.0.1 -o User=vagrant -p 2222 \
>>>>>> -o Compression=yes \
>>>>>> -o StrictHostKeyChecking=no \
>>>>>> -o LogLevel=FATAL \
>>>>>> -o StrictHostKeyChecking=no \
>>>>>> -o UserKnownHostsFile=/dev/null \
>>>>>> -o IdentitiesOnly=yes \
>>>>>> -i /Users/bryanhunt/.vagrant.d/insecure_private_key \
>>>>>> -o ForwardAgent=yes \
>>>>>> "/bin/sh  -c 'git clone git at bitbucket.org:bryan_picsolve/poc_docker.git /home/vagrant/poc_dockerb' "
>>>>>> /bin/sh  -c 'git clone git at 127.0.0.1's password:
>>>>>> 
>>>>>> The client side SSH is:
>>>>>> 
>>>>>> OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
>>>>>> 
>>>>>> The server side SSH is:
>>>>>> 
>>>>>> OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
>>>>>> 
>>>>>> 
>>>>>> Have any of the list members got an insight into this behaviour ?
>>>>>> 
>>>>>> Thanks in advance, 
>>>>>> 
>>>>>> Bryan Hunt
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> _______________________________________________
>>>>>> 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 alex at alex.org.uk  Fri Jan 10 21:36:01 2014
From: alex at alex.org.uk (Alex Bligh)
Date: Fri, 10 Jan 2014 10:36:01 +0000
Subject: OSX - SSH agent functionality differing based upon CLI arguments
In-Reply-To: <9E47E04B-F6BE-44F8-90CA-DE0410B78D11@gmail.com>
References: <8E835267-780D-4EA5-B41D-CF068361D412@gmail.com>
 <BDB13A1C-1E5C-42A0-B6A4-CB28BD14ED40@gmail.com>
 <1246AE7E-91C9-4427-9444-9868CCD156DC@gmail.com>
 <4E41EE56-A482-4355-8256-0D15AFD7793B@gmail.com>
 <55F5E4A1-40DF-47E3-83DA-98A37EE1EB9F@gmail.com>
 <BE188C07-E50D-474D-B374-68A37BBB0D04@gmail.com>
 <9E47E04B-F6BE-44F8-90CA-DE0410B78D11@gmail.com>
Message-ID: <65C85C20-EE12-484E-9C41-3CEDEB188182@alex.org.uk>

I may be being a bit thick here, but if you reduce your command line, by removing the -o and -i options, it says:

>> ssh "" "/bin/sh  -c 'git clone git at bitbucket.org:bryan_picsolve/poc_docker.git /home/vagrant/poc_dockerddd? "

which is the equivalent to
  ssh "" "command"

Is using an empty hostname documented as something that is meant to work? I suspect the hostname is simply being merged into the command, and you are doing
  ssh command

which is failing.

Alex

On 10 Jan 2014, at 10:16, bryan hunt wrote:

> But it isn?t. 
> 
> "/bin/sh  -c 'git clone git at bitbucket.org:bryan_picsolve/poc_docker.git /home/vagrant/poc_dockerddd? ? is not interpreted as the hostname, it is executed as a remote command, but without SSH agent working. 
> 
> Anyhow, I?m not here to demand a better command line argument parser, merely to verify the behaviour so I can help to resolve the problems that Ansible are having. 
> 
> But thank you for the help.
> 
> Bryan
> 
> 
> On 9 Jan 2014, at 20:12, Markus Friedl <mfriedl at gmail.com> wrote:
> 
>> This is due to ssh's flexible argument parsing. If you skip the hostname, them something else is interpreted as the hostname. 
>> 
>> 
>> 
>> 
>>> Am 09.01.2014 um 18:43 schrieb bryan hunt <picsolvebryan at gmail.com>:
>>> 
>>> Yes, called as you describe, SSH works correctly (it Forwards Agent). Quirky!
>>> 
>>> But, called the way I was doing, everything but Agent Forwarding works. 
>>> 
>>> Strange. Looking further, I found another odd behaviour. 
>>> 
>>> ssh -o User=vagrant -o Hostname=127.0.0.1 -p 2222 -o Compression=yes -o StrictHostKeyChecking=no -o StrictHostKeyChecking=no -o UserKnownHostsFile=/dev/null -o IdentitiesOnly=yes -i /Users/bryanhunt/.vagrant.d/insecure_private_key -o ForwardAgent=yes -o LogLevel=DEBUG "" "/bin/sh  -c 'git clone git at bitbucket.org:bryan_picsolve/poc_docker.git /home/vagrant/poc_dockerddd? "
>>> 
>>> Note how I added the empty quoted string in the hostname position. 
>>> 
>>> SSH Agent Forwarding works if I add that empty quoted string. 
>>> 
>>> If I remove the empty quoted string, the git checkout is executed, but prompts for authentication.
>>> 
>>> I would expect SSH to completely succeed, or completely fail to execute the command - rather than have the side channel (SSH agent) fail or succeed based upon how I express the command line arguments. 
>>> 
>>> This is a stock version of the ssh command on OSX.
>>> 
>>> The checksum is:
>>> 
>>> MD5 (/usr/bin/ssh) = 35caacee333ebae93d4087ca349738e4
>>> 
>>> Perhaps another OSX user could verify this behaviour? 
>>> 
>>> Regards,
>>> 
>>> Bryan Hunt
>>> 
>>> 
>>>> On 9 Jan 2014, at 17:21, Markus Friedl <mfriedl at gmail.com> wrote:
>>>> 
>>>> You pass it as an option. 
>>>> 
>>>> But ssh is called like 
>>>> 
>>>> $ ssh [options] hostname [command]
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>>> Am 09.01.2014 um 16:21 schrieb bryan hunt <picsolvebryan at gmail.com>:
>>>>> 
>>>>> 
>>>>> I don?t understand, in the second example, "ssh -o HostName=127.0.0.1 ?, is the very first argument to the program?
>>>>> 
>>>>> 
>>>>> 
>>>>>> On 9 Jan 2014, at 13:21, Markus Friedl <mfriedl at gmail.com> wrote:
>>>>>> 
>>>>>> The 2nd example misses the required hostname argument.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>> Am 09.01.2014 um 13:32 schrieb bryan hunt <picsolvebryan at gmail.com>:
>>>>>>> 
>>>>>>> 
>>>>>>> Trying to get SSH agent forwarding working for a popular open source configuration management system called Ansible.
>>>>>>> 
>>>>>>> I?ve had some unexpected behaviour, the only cause of which I can find is how I express the command line arguments.
>>>>>>> 
>>>>>>> http://stackoverflow.com/questions/20952689/vagrant-ssh-agent-forwarding-how-is-it-working?noredirect=1#comment31511341_20952689
>>>>>>> 
>>>>>>> In summarise:
>>>>>>> 
>>>>>>> In the first instance I can create a SSH connection, and and execute a remote git clone (via SSH), the Agent Forwarding works, and I am not prompted for credentials:
>>>>>>> 
>>>>>>> ssh vagrant at 127.0.0.1 -p 2222 \
>>>>>>> -o Compression=yes \
>>>>>>> -o StrictHostKeyChecking=no \
>>>>>>> -o LogLevel=FATAL \
>>>>>>> -o StrictHostKeyChecking=no \
>>>>>>> -o UserKnownHostsFile=/dev/null \
>>>>>>> -o IdentitiesOnly=yes \
>>>>>>> -i /Users/bryanhunt/.vagrant.d/insecure_private_key \
>>>>>>> -o ForwardAgent=yes \
>>>>>>> "/bin/sh  -c 'git clone git at bitbucket.org:bryan_picsolve/poc_docker.git /home/vagrant/poc_dockera' "
>>>>>>> Cloning into '/home/vagrant/poc_dockera'...
>>>>>>> 
>>>>>>> In the second instance I express the arguments differently ( -o HostName=127.0.0.1 -o User=vagrant ), and Agent Forwarding doesn?t seem to work:
>>>>>>> 
>>>>>>> ssh -o HostName=127.0.0.1 -o User=vagrant -p 2222 \
>>>>>>> -o Compression=yes \
>>>>>>> -o StrictHostKeyChecking=no \
>>>>>>> -o LogLevel=FATAL \
>>>>>>> -o StrictHostKeyChecking=no \
>>>>>>> -o UserKnownHostsFile=/dev/null \
>>>>>>> -o IdentitiesOnly=yes \
>>>>>>> -i /Users/bryanhunt/.vagrant.d/insecure_private_key \
>>>>>>> -o ForwardAgent=yes \
>>>>>>> "/bin/sh  -c 'git clone git at bitbucket.org:bryan_picsolve/poc_docker.git /home/vagrant/poc_dockerb' "
>>>>>>> /bin/sh  -c 'git clone git at 127.0.0.1's password:
>>>>>>> 
>>>>>>> The client side SSH is:
>>>>>>> 
>>>>>>> OpenSSH_6.2p2, OSSLShim 0.9.8r 8 Dec 2011
>>>>>>> 
>>>>>>> The server side SSH is:
>>>>>>> 
>>>>>>> OpenSSH_5.9p1 Debian-5ubuntu1.1, OpenSSL 1.0.1 14 Mar 2012
>>>>>>> 
>>>>>>> 
>>>>>>> Have any of the list members got an insight into this behaviour ?
>>>>>>> 
>>>>>>> Thanks in advance, 
>>>>>>> 
>>>>>>> Bryan Hunt
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> _______________________________________________
>>>>>>> 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
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 
> 

-- 
Alex Bligh





From picsolvebryan at gmail.com  Fri Jan 10 21:48:51 2014
From: picsolvebryan at gmail.com (bryan hunt)
Date: Fri, 10 Jan 2014 10:48:51 +0000
Subject: OSX - SSH agent functionality differing based upon CLI arguments 
In-Reply-To: <65C85C20-EE12-484E-9C41-3CEDEB188182@alex.org.uk>
References: <8E835267-780D-4EA5-B41D-CF068361D412@gmail.com>
 <BDB13A1C-1E5C-42A0-B6A4-CB28BD14ED40@gmail.com>
 <1246AE7E-91C9-4427-9444-9868CCD156DC@gmail.com>
 <4E41EE56-A482-4355-8256-0D15AFD7793B@gmail.com>
 <55F5E4A1-40DF-47E3-83DA-98A37EE1EB9F@gmail.com>
 <BE188C07-E50D-474D-B374-68A37BBB0D04@gmail.com>
 <9E47E04B-F6BE-44F8-90CA-DE0410B78D11@gmail.com>
 <65C85C20-EE12-484E-9C41-3CEDEB188182@alex.org.uk>
Message-ID: <19EB6BB4-CD2D-491C-AD66-ADD6FACC7E2E@gmail.com>

LOL. Maybe. 

What I?m trying to express (through the void of the interwebs)...

Regardless of which way SSH is executed, the command runs on the remote host (success)

Each of the examples I?ve given work. 

That is to say, they execute the given command on the remote server. 

No problem there, none whatsoever (success)

What is a problem:

Expressing the arguments one way, SSH Agent Forwarding works.

AND

Expressed the arguments the other way, SSH Agent Forwarding fails.

 (fail)

From alex at alex.org.uk  Fri Jan 10 22:42:22 2014
From: alex at alex.org.uk (Alex Bligh)
Date: Fri, 10 Jan 2014 11:42:22 +0000
Subject: OSX - SSH agent functionality differing based upon CLI arguments 
In-Reply-To: <19EB6BB4-CD2D-491C-AD66-ADD6FACC7E2E@gmail.com>
References: <8E835267-780D-4EA5-B41D-CF068361D412@gmail.com>
 <BDB13A1C-1E5C-42A0-B6A4-CB28BD14ED40@gmail.com>
 <1246AE7E-91C9-4427-9444-9868CCD156DC@gmail.com>
 <4E41EE56-A482-4355-8256-0D15AFD7793B@gmail.com>
 <55F5E4A1-40DF-47E3-83DA-98A37EE1EB9F@gmail.com>
 <BE188C07-E50D-474D-B374-68A37BBB0D04@gmail.com>
 <9E47E04B-F6BE-44F8-90CA-DE0410B78D11@gmail.com>
 <65C85C20-EE12-484E-9C41-3CEDEB188182@alex.org.uk>
 <19EB6BB4-CD2D-491C-AD66-ADD6FACC7E2E@gmail.com>
Message-ID: <F1F97234-7293-4D38-BC34-97DAE3056704@alex.org.uk>


On 10 Jan 2014, at 10:48, bryan hunt wrote:

> Expressed the arguments the other way, SSH Agent Forwarding fails.

I suspect the agent stuff expects a hostname parameter that matches ^\S+$

-- 
Alex Bligh





From picsolvebryan at gmail.com  Fri Jan 10 22:46:15 2014
From: picsolvebryan at gmail.com (bryan hunt)
Date: Fri, 10 Jan 2014 11:46:15 +0000
Subject: OSX - SSH agent functionality differing based upon CLI arguments 
In-Reply-To: <F1F97234-7293-4D38-BC34-97DAE3056704@alex.org.uk>
References: <8E835267-780D-4EA5-B41D-CF068361D412@gmail.com>
 <BDB13A1C-1E5C-42A0-B6A4-CB28BD14ED40@gmail.com>
 <1246AE7E-91C9-4427-9444-9868CCD156DC@gmail.com>
 <4E41EE56-A482-4355-8256-0D15AFD7793B@gmail.com>
 <55F5E4A1-40DF-47E3-83DA-98A37EE1EB9F@gmail.com>
 <BE188C07-E50D-474D-B374-68A37BBB0D04@gmail.com>
 <9E47E04B-F6BE-44F8-90CA-DE0410B78D11@gmail.com>
 <65C85C20-EE12-484E-9C41-3CEDEB188182@alex.org.uk>
 <19EB6BB4-CD2D-491C-AD66-ADD6FACC7E2E@gmail.com>
 <F1F97234-7293-4D38-BC34-97DAE3056704@alex.org.uk>
Message-ID: <B83E5180-98C1-46A8-81CC-4B0AEC71D7E8@gmail.com>

Give it a try.

On 10 Jan 2014, at 11:42, Alex Bligh <alex at alex.org.uk> wrote:

> 
> On 10 Jan 2014, at 10:48, bryan hunt wrote:
> 
>> Expressed the arguments the other way, SSH Agent Forwarding fails.
> 
> I suspect the agent stuff expects a hostname parameter that matches ^\S+$
> 
> -- 
> Alex Bligh
> 
> 
> 
> 


From dimitri.nuescheler at gmail.com  Sun Jan 12 10:21:09 2014
From: dimitri.nuescheler at gmail.com (=?ISO-8859-1?Q?Dimitri_N=FCscheler?=)
Date: Sun, 12 Jan 2014 00:21:09 +0100
Subject: Soft chroot jail for sftp-server
Message-ID: <CABQ6qDwoNCj1Hp=gXnf3MGH-DM_ksV+TeG5f+_kN1i9rWqevyA@mail.gmail.com>

Hi again

I refactored the patch. It's now more decoupled from the SFTP
processing code. All the syscalls used by the processing code now have
a proxy instead of having the processing code very jail-aware.

With that comes a functional difference: The content of a symlink is
not prepended with the jail path. Instead there is also a modified
realpath() also used by the other proxy-syscalls.

I will try to write tests for it. I don't know how to get full
coverage by just using sftp. Help appreciated and any hints on using
the existing regression test framework.

Regards
Dimitri
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sftp-server-soft-jail.patch
Type: text/x-patch
Size: 13831 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20140112/d4464c66/attachment-0001.bin>

From bob at proulx.com  Sun Jan 12 12:36:47 2014
From: bob at proulx.com (Bob Proulx)
Date: Sat, 11 Jan 2014 18:36:47 -0700
Subject: New Log Messages?
In-Reply-To: <alpine.BSO.2.03.1401080954320.3003@mindrot.org>
References: <20140102195539.GA5963@hysteria.proulx.com>
 <alpine.BSO.2.03.1401031610180.8654@mindrot.org>
 <20140103175519.GA24478@hysteria.proulx.com>
 <alpine.BSO.2.03.1401080954320.3003@mindrot.org>
Message-ID: <20140112013647.GA27483@hysteria.proulx.com>

Damien Miller wrote:
> The only thing to have changed semi-recently is that we improved
> logging of preauthentication messages in privsep mode in the 5.9
> release to no longer need a /dev/log inside the privsep chroot. If
> your old OpenSSH version was <5.9 and the /var/empty chroot didn't
> have a /dev/log in it then you may have been missing these messages.

I just looked and that appears to have been the case.  I see no
/dev/log in the empty directory.  So that will explain it then.
Wasn't getting those messages before even if they were intended to be
logged but am getting those messages now due to the change to log them
even if /dev/log is not present.

Thanks for taking the time to describe it.  It is so much nicer
understanding what is going on.

Thanks!
Bob

From C++ at Cns.SU  Sun Jan 12 14:11:08 2014
From: C++ at Cns.SU (Constantine Aleksandrovich Murenin)
Date: Sat, 11 Jan 2014 19:11:08 -0800
Subject: PuTTY: Forwarded connection refused by server: Administratively
 prohibited [open failed]
Message-ID: <52D207CC.9050602@Cns.SU>

Hello,

In my installation, one of the resolvers specified in /etc/resolv.conf 
on the sshd OpenSSH server side appears to be experiencing some issues, 
and this results in the following issues on the client side with PuTTY:

* a SOCKS5-powered multi-tab web-browser has some web-pages timeout 
(takes many seconds), whereas other web-pages stall during this time

* during the time where any web-page is in the process of timing out 
(which, as mentioned, takes many seconds), the terminal is stalling, 
too;  basically, the terminal is just about entirely unusable -- the 
stalls persist for dozens of seconds at a time;  remove dynamic port 
forwarding, wait for the timeouts to expire, and the terminal stalls no 
more, not even a little bit

The following appears in PuTTY Event Log around these troubling times:

2014-01-11 17:12:03 Forwarded connection refused by server: 
Administratively prohibited [open failed]

Otherwise, the following entries appear within PuTTY, which gives me the 
impression that the whole DNS resolution is done entirely on the server 
side (a SOCKS5 feature, per my understanding), with the client being 
entirely IPv4/IPv6 agnostic, most of the time:

2014-01-11 17:51:31	Opening forwarded connection to www.openssh.com:80


Why does the DNS timing out take so long?  Is there a way to abandon DNS 
queries after at most 1 s, or maybe even start issuing a duplicate query 
to the next server at 300 ms, without abandoning the first one for a 
while?  Or maybe be smart about the first server acting up, and issue 
most subsequent queries to the second server etc?  (I realise this is 
now in the realm of the DNS resolver library talk, arguably unrelated to 
OpenSSH, but, hey, you do have to start the discussion somewhere.)

Most importantly, why is there so much stalling going on?  This 
basically sounds like a DoS to me.

Cheers,
Constantine.

From djm at mindrot.org  Sun Jan 12 22:39:39 2014
From: djm at mindrot.org (Damien Miller)
Date: Sun, 12 Jan 2014 22:39:39 +1100 (EST)
Subject: PuTTY: Forwarded connection refused by server: Administratively
 prohibited [open failed]
In-Reply-To: <52D207CC.9050602@Cns.SU>
References: <52D207CC.9050602@Cns.SU>
Message-ID: <alpine.BSO.2.03.1401122230120.20430@mindrot.org>

On Sat, 11 Jan 2014, Constantine Aleksandrovich Murenin wrote:

> Hello,
> 
> In my installation, one of the resolvers specified in /etc/resolv.conf
> on the sshd OpenSSH server side appears to be experiencing some
> issues, and this results in the following issues on the client side
> with PuTTY:
>
> * a SOCKS5-powered multi-tab web-browser has some web-pages timeout
> (takes many seconds), whereas other web-pages stall during this time
>
> * during the time where any web-page is in the process of timing out
> (which, as mentioned, takes many seconds), the terminal is stalling,
> too; basically, the terminal is just about entirely unusable -- the
> stalls persist for dozens of seconds at a time; remove dynamic port
> forwarding, wait for the timeouts to expire, and the terminal stalls
> no more, not even a little bit

Yes, OpenSSH uses the standard libc resolver to perform name
resolution. This is synchronous and blocking, so no other traffic
is processed while one is in progress.

Fixing this would require an asynchronous resolver. It's probably
worth doing, but we'd need to select one and integrate it with the
channels code. Depending on the resolver, this could be a little
or a lot of work.

> Why does the DNS timing out take so long? Is there a way to abandon
> DNS queries after at most 1 s, or maybe even start issuing a duplicate
> query to the next server at 300 ms, without abandoning the first one
> for a while? Or maybe be smart about the first server acting up, and
> issue most subsequent queries to the second server etc? (I realise
> this is now in the realm of the DNS resolver library talk, arguably
> unrelated to OpenSSH, but, hey, you do have to start the discussion
> somewhere.)

The libc resolver doesn't offer enough control or feedback
to support any of this. We'd need to use something different.

-d

From cespare at gmail.com  Wed Jan 15 12:42:22 2014
From: cespare at gmail.com (Caleb Spare)
Date: Tue, 14 Jan 2014 17:42:22 -0800
Subject: ControlMaster auto and stderr
Message-ID: <CAGeFq+n1cbFditvHzoEOdtcOzgu9AAgij1EfudODZgmFrxLLug@mail.gmail.com>

I use ControlMaster auto (along with ControlPath) in my ssh config and
find it very handy.

I have noticed an annoying behavior, though: it seems that if there is
no existing master connection and ssh creates a new one, the master
connection process that is started has its stderr left open.

This has manifested itself in two ways so far:

(1) When using ssh day-to-day, I may be doing some work and the text
'Shared connection to [servername] closed.' appears in my terminal.
This happens when the remote server closes the connection after some
amount of time (maybe hours or days). It's disruptive; I don't care
about that connection and ssh will transparently open a new one the
next time I ssh in. The text might appear while I'm inside vim or top
and mess with that program.

(2) Some software (I noticed it with Ansible[1]) waits for
stderr/stdout of a process to be closed. In the case of Ansible it was
because the communicate() method of Python's subprocess module[2]
waits on stdout/stderr as well as wait()ing on the process itself.
(This behavior seems strange to me, but it's indicative that openssh's
behavior here is atypical, I think.)

I haven't looked at the code yet, but I think the behavior I'd expect
would be that when ssh creates the controlmaster process, it would set
its stdin/stderr/stdout to /dev/null, or else some logfile. It's not
useful to have that process writing to the terminal after its parent
is long dead.

Thanks for any information/feedback you can provide!
-Caleb

[1] http://www.ansibleworks.com/
[2] http://docs.python.org/2/library/subprocess.html#subprocess.Popen.communicate

From cespare at gmail.com  Wed Jan 15 13:44:04 2014
From: cespare at gmail.com (Caleb Spare)
Date: Tue, 14 Jan 2014 18:44:04 -0800
Subject: ControlMaster auto and stderr
In-Reply-To: <CAGeFq+n1cbFditvHzoEOdtcOzgu9AAgij1EfudODZgmFrxLLug@mail.gmail.com>
References: <CAGeFq+n1cbFditvHzoEOdtcOzgu9AAgij1EfudODZgmFrxLLug@mail.gmail.com>
Message-ID: <CAGeFq+n8+x=G8ftFg7oLy5L6auPCZ7D3kv0NFWTvGuFgeH-GyA@mail.gmail.com>

A small correction: when I referred to text appearing in my terminal
in (1), the message is actually (for example):

Connection to github.com closed by remote host.

On Tue, Jan 14, 2014 at 5:42 PM, Caleb Spare <cespare at gmail.com> wrote:
> I use ControlMaster auto (along with ControlPath) in my ssh config and
> find it very handy.
>
> I have noticed an annoying behavior, though: it seems that if there is
> no existing master connection and ssh creates a new one, the master
> connection process that is started has its stderr left open.
>
> This has manifested itself in two ways so far:
>
> (1) When using ssh day-to-day, I may be doing some work and the text
> 'Shared connection to [servername] closed.' appears in my terminal.
> This happens when the remote server closes the connection after some
> amount of time (maybe hours or days). It's disruptive; I don't care
> about that connection and ssh will transparently open a new one the
> next time I ssh in. The text might appear while I'm inside vim or top
> and mess with that program.
>
> (2) Some software (I noticed it with Ansible[1]) waits for
> stderr/stdout of a process to be closed. In the case of Ansible it was
> because the communicate() method of Python's subprocess module[2]
> waits on stdout/stderr as well as wait()ing on the process itself.
> (This behavior seems strange to me, but it's indicative that openssh's
> behavior here is atypical, I think.)
>
> I haven't looked at the code yet, but I think the behavior I'd expect
> would be that when ssh creates the controlmaster process, it would set
> its stdin/stderr/stdout to /dev/null, or else some logfile. It's not
> useful to have that process writing to the terminal after its parent
> is long dead.
>
> Thanks for any information/feedback you can provide!
> -Caleb
>
> [1] http://www.ansibleworks.com/
> [2] http://docs.python.org/2/library/subprocess.html#subprocess.Popen.communicate

From the.warl0ck.1989 at gmail.com  Wed Jan 15 18:44:33 2014
From: the.warl0ck.1989 at gmail.com (Aaron Lewis)
Date: Wed, 15 Jan 2014 15:44:33 +0800
Subject: Why does restarting sshd require an absolute path?
Message-ID: <CAJZVxRn8FaizQvEo7NsVvkE9pmi2zmSBBEuihku4j44J4hU+aA@mail.gmail.com>

Hi,

When I start sshd with non-absolute path, it complains:

sshd re-exec requires execution with an absolute path

Is there any security implications?


-- 
Best Regards,
Aaron Lewis - PGP: 0x13714D33 - http://pgp.mit.edu/
Finger Print:   9F67 391B B770 8FF6 99DC  D92D 87F6 2602 1371 4D33

From vintobe at gmail.com  Wed Jan 15 18:47:09 2014
From: vintobe at gmail.com (Vincent Lin)
Date: Wed, 15 Jan 2014 15:47:09 +0800
Subject: remote port forward failed because of failure resolving localhost to
 IP with error No such file or directory
Message-ID: <CAKi2yo-P1fFG8i=W6FCdYj8bVoEj2McyDHVTo11X_qpeN_Ju4w@mail.gmail.com>

Hi all,

I'm using openssh 5.9p1 with the remote port forwarding "ssh -R
20000:localhost:22 xxx at x.x.x.x". The tunnel is set up. But when I write
data to the tunnel, the ssh client failed to forward the data to the
localhost. The debug is below:

debug1: client_input_channel_open: ctype forwarded-tcpip rchan 2 win
131072 max 32768
debug1: client_request_forwarded_tcpip: listen localhost port 20000,
originator 127.0.0.1 port 36478
connect_to localhost: unknown host (No such file or directory)
debug1: failure forwarded-tcpip


The code relevant is here:

3133 /* Return CONNECTING channel to remote host, port */
3134 static Channel *
3135 connect_to(const char *host, u_short port, char *ctype, char *rname)
3136 {
3137     struct addrinfo hints;
3138     int gaierr;
3139     int sock = -1;
3140     char strport[NI_MAXSERV];
3141     struct channel_connect cctx;
3142     Channel *c;
3143
3144     memset(&cctx, 0, sizeof(cctx));
3145     memset(&hints, 0, sizeof(hints));
3146     hints.ai_family = IPv4or6;
3147     hints.ai_socktype = SOCK_STREAM;
3148     snprintf(strport, sizeof strport, "%d", port);
3149     if ((gaierr = getaddrinfo(host, strport, &hints, &cctx.aitop)) != 0) {
3150         error("connect_to %.100s: unknown host (%s)", host,
3151             ssh_gai_strerror(gaierr));
3152         return NULL;
3153     }


The error is returned by the function getaddrinfo. And it's "No such
file or directory". That is saying it can't find some file to resolve
localhost to IP. I found the error is only occurred on the x86_64 with
glibc 2.9.

Does anybody has the similar problem before? Thanks in advance.


Thanks,

Vincent

From mackyle at gmail.com  Wed Jan 15 23:04:24 2014
From: mackyle at gmail.com (Kyle J. McKay)
Date: Wed, 15 Jan 2014 04:04:24 -0800
Subject: PuTTY: Forwarded connection refused by server: Administratively
 prohibited [open failed]
In-Reply-To: <mailman.1563.1389772038.26979.openssh-unix-dev@mindrot.org>
References: <mailman.1563.1389772038.26979.openssh-unix-dev@mindrot.org>
Message-ID: <801DE24D-D0C0-41D1-A8C3-62087728CD6D@gmail.com>

On January 12, 2014 03:39:39 PST, Damien Miller wrote:
>> * during the time where any web-page is in the process of timing out
>> (which, as mentioned, takes many seconds), the terminal is stalling,
>> too; basically, the terminal is just about entirely unusable -- the
>> stalls persist for dozens of seconds at a time; remove dynamic port
>> forwarding, wait for the timeouts to expire, and the terminal stalls
>> no more, not even a little bit
>
> Yes, OpenSSH uses the standard libc resolver to perform name
> resolution. This is synchronous and blocking, so no other traffic
> is processed while one is in progress.
>
> Fixing this would require an asynchronous resolver. It's probably
> worth doing, but we'd need to select one and integrate it with the
> channels code. Depending on the resolver, this could be a little
> or a lot of work.

I suggest looking at c-ares (http://c-ares.haxx.se/) which seems to  
have a compatible license and is one of the resolver options for both  
curl and wireshark.  There's a working source code example at [1].

Kyle

[1] http://stackoverflow.com/questions/4854284/how-do-i-resolve-an-ip-into-host-using-c-ares


From dtucker at zip.com.au  Thu Jan 16 00:49:35 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 16 Jan 2014 00:49:35 +1100
Subject: PuTTY: Forwarded connection refused by server: Administratively
 prohibited [open failed]
In-Reply-To: <alpine.BSO.2.03.1401122230120.20430@mindrot.org>
References: <52D207CC.9050602@Cns.SU>
 <alpine.BSO.2.03.1401122230120.20430@mindrot.org>
Message-ID: <CALDDTe0E-GFZzs9sJ6mzcVD17XntiK4xE5_N1O3mFM0jtzdNmg@mail.gmail.com>

On Sun, Jan 12, 2014 at 10:39 PM, Damien Miller <djm at mindrot.org> wrote:
> Yes, OpenSSH uses the standard libc resolver to perform name
> resolution. This is synchronous and blocking, so no other traffic
> is processed while one is in progress.

Note that which side the address is resolved on is under the control
of the SOCKS client. eg, in firefox this is about:config
network.proxy.socks_remote_dns.

The up side is that the client can implement different retry
behaviour.  The down side is that any addrress resolution on the
client side leaks information.

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

From dtucker at zip.com.au  Fri Jan 17 08:58:32 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 17 Jan 2014 08:58:32 +1100
Subject: additional compiler hardening flags
In-Reply-To: <20131220190112.GT10110@linux124.nas.nasa.gov>
References: <20130322050815.GA6024@gate.dtucker.net>
 <20130417230311.GD17666@linux124.nas.nasa.gov>
 <20130418011613.GA16696@gate.dtucker.net>
 <20130418014100.GA30605@gate.dtucker.net>
 <20131220190112.GT10110@linux124.nas.nasa.gov>
Message-ID: <20140116215832.GA14093@gate.dtucker.net>

On Fri, Dec 20, 2013 at 11:01:12AM -0800, Iain Morgan wrote:
> I don't recall seeing these improvements to the build system being
> committed. Is there any chance of adding them for the next release, or
> is it too late in the development cycle?

Sorry, this was on my list to get back to and I didn't.

Here's the current diff.  Given that there's an off switch I think I
should just commit it.  Damien?


Index: aclocal.m4
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/aclocal.m4,v
retrieving revision 1.9
diff -u -p -r1.9 aclocal.m4
--- aclocal.m4	2 Jun 2013 21:31:27 -0000	1.9
+++ aclocal.m4	30 Jul 2013 01:34:12 -0000
@@ -10,7 +10,7 @@ dnl 'check_flag'.
 AC_DEFUN([OSSH_CHECK_CFLAG_COMPILE], [{
 	AC_MSG_CHECKING([if $CC supports $1])
 	saved_CFLAGS="$CFLAGS"
-	CFLAGS="$CFLAGS $1"
+	CFLAGS="$CFLAGS $WERROR $1"
 	_define_flag="$2"
 	test "x$_define_flag" = "x" && _define_flag="$1"
 	AC_COMPILE_IFELSE([AC_LANG_SOURCE([[int main(void) { return 0; }]])],
@@ -28,6 +28,23 @@ fi],
 	)
 }])
 
+dnl OSSH_CHECK_CFLAG_LINK(check_flag[, define_flag])
+dnl Check that $LD accepts a flag 'check_flag'. If it is supported append
+dnl 'define_flag' to $LDFLAGS. If 'define_flag' is not specified, then append
+dnl 'check_flag'.
+AC_DEFUN([OSSH_CHECK_LDFLAG_LINK], [{
+	AC_MSG_CHECKING([if $LD supports $1])
+	saved_LDFLAGS="$LDFLAGS"
+	LDFLAGS="$LDFLAGS $WERROR $1"
+	_define_flag="$2"
+	test "x$_define_flag" = "x" && _define_flag="$1"
+	AC_LINK_IFELSE([AC_LANG_SOURCE([[int main(void) { return 0; }]])],
+		[ AC_MSG_RESULT([yes])
+		  LDFLAGS="$saved_LDFLAGS $_define_flag"],
+		[ AC_MSG_RESULT([no])
+		  LDFLAGS="$saved_LDFLAGS" ]
+	)
+}])
 
 dnl OSSH_CHECK_HEADER_FOR_FIELD(field, header, symbol)
 dnl Does AC_EGREP_HEADER on 'header' for the string 'field'
Index: configure.ac
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/configure.ac,v
retrieving revision 1.547
diff -u -p -r1.547 configure.ac
--- configure.ac	19 Dec 2013 00:00:12 -0000	1.547
+++ configure.ac	16 Jan 2014 21:40:45 -0000
@@ -121,18 +121,35 @@ AC_CHECK_DECL([PR_SET_NO_NEW_PRIVS], [ha
 	#include <linux/prctl.h>
 ])
 use_stack_protector=1
+use_toolchain_hardening=1
 AC_ARG_WITH([stackprotect],
     [  --without-stackprotect  Don't use compiler's stack protection], [
     if test "x$withval" = "xno"; then
 	use_stack_protector=0
     fi ])
+AC_ARG_WITH([hardening],
+    [  --without-hardening     Don't use toolchain hardening flags], [
+    if test "x$withval" = "xno"; then
+	use_stack_protector=0
+	use_toolchain_hardening=0
+    fi ])
 
+# We use -Werror for the tests only so that we catch warnings like "this is
+# on by default" for things like -fPIE.
+AC_MSG_CHECKING([if $CC supports -Werror])
+saved_CFLAGS="$CFLAGS"
+CFLAGS="$CFLAGS -Werror"
+AC_COMPILE_IFELSE([AC_LANG_SOURCE([[int main(void) { return 0; }]])],
+	[ AC_MSG_RESULT([yes])
+	  WERROR="-Werror"],
+	[ AC_MSG_RESULT([no])
+	  WERROR="" ]
+)
+CFLAGS="$saved_CFLAGS"
 
 if test "$GCC" = "yes" || test "$GCC" = "egcs"; then
-	OSSH_CHECK_CFLAG_COMPILE([-Qunused-arguments -Werror],
-	    [-Qunused-arguments])
-	OSSH_CHECK_CFLAG_COMPILE([-Wunknown-warning-option -Werror],
-	    [-Wno-unknown-warning-option])
+	OSSH_CHECK_CFLAG_COMPILE([-Qunused-arguments])
+	OSSH_CHECK_CFLAG_COMPILE([-Wunknown-warning-option])
 	OSSH_CHECK_CFLAG_COMPILE([-Wall])
 	OSSH_CHECK_CFLAG_COMPILE([-Wpointer-arith])
 	OSSH_CHECK_CFLAG_COMPILE([-Wuninitialized])
@@ -143,6 +160,14 @@ if test "$GCC" = "yes" || test "$GCC" = 
 	OSSH_CHECK_CFLAG_COMPILE([-Wunused-result], [-Wno-unused-result])
 	OSSH_CHECK_CFLAG_COMPILE([-fno-strict-aliasing])
 	OSSH_CHECK_CFLAG_COMPILE([-D_FORTIFY_SOURCE=2])
+    if test "x$use_toolchain_hardening" = "x1"; then
+	OSSH_CHECK_CFLAG_COMPILE([-ftrapv])
+	OSSH_CHECK_CFLAG_COMPILE([-fPIE])
+	OSSH_CHECK_LDFLAG_LINK([-pie])
+	OSSH_CHECK_LDFLAG_LINK([-Wl,-z,relro])
+	OSSH_CHECK_LDFLAG_LINK([-Wl,-z,now])
+	OSSH_CHECK_LDFLAG_LINK([-Wl,-z,noexecstack])
+    fi
 	AC_MSG_CHECKING([gcc version])
 	GCC_VER=`$CC -v 2>&1 | $AWK '/gcc version /{print $3}'`
 	case $GCC_VER in

-- 
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  Fri Jan 17 09:39:58 2014
From: djm at mindrot.org (Damien Miller)
Date: Fri, 17 Jan 2014 09:39:58 +1100 (EST)
Subject: additional compiler hardening flags
In-Reply-To: <20140116215832.GA14093@gate.dtucker.net>
References: <20130322050815.GA6024@gate.dtucker.net>
 <20130417230311.GD17666@linux124.nas.nasa.gov>
 <20130418011613.GA16696@gate.dtucker.net>
 <20130418014100.GA30605@gate.dtucker.net>
 <20131220190112.GT10110@linux124.nas.nasa.gov>
 <20140116215832.GA14093@gate.dtucker.net>
Message-ID: <alpine.BSO.2.11.1401170939020.32270@natsu.mindrot.org>

On Fri, 17 Jan 2014, Darren Tucker wrote:

> On Fri, Dec 20, 2013 at 11:01:12AM -0800, Iain Morgan wrote:
> > I don't recall seeing these improvements to the build system being
> > committed. Is there any chance of adding them for the next release, or
> > is it too late in the development cycle?
> 
> Sorry, this was on my list to get back to and I didn't.
> 
> Here's the current diff.  Given that there's an off switch I think I
> should just commit it.  Damien?

ok djm

there's also a -fstack-protector-strong that we should support, probably
in preference to -fstack-protector-all

From vinschen at redhat.com  Fri Jan 17 09:44:26 2014
From: vinschen at redhat.com (Corinna Vinschen)
Date: Thu, 16 Jan 2014 23:44:26 +0100
Subject: additional compiler hardening flags
In-Reply-To: <20140116215832.GA14093@gate.dtucker.net>
References: <20130322050815.GA6024@gate.dtucker.net>
 <20130417230311.GD17666@linux124.nas.nasa.gov>
 <20130418011613.GA16696@gate.dtucker.net>
 <20130418014100.GA30605@gate.dtucker.net>
 <20131220190112.GT10110@linux124.nas.nasa.gov>
 <20140116215832.GA14093@gate.dtucker.net>
Message-ID: <20140116224426.GG2831@calimero.vinschen.de>

On Jan 17 08:58, Darren Tucker wrote:
> On Fri, Dec 20, 2013 at 11:01:12AM -0800, Iain Morgan wrote:
> > I don't recall seeing these improvements to the build system being
> > committed. Is there any chance of adding them for the next release, or
> > is it too late in the development cycle?
> 
> Sorry, this was on my list to get back to and I didn't.
> 
> Here's the current diff.  Given that there's an off switch I think I
> should just commit it.  Damien?

Will you accept patches to get rid of the existing warnings so we can
build all of OpenSSH with -Werror?


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/20140116/67451913/attachment.bin>

From dtucker at zip.com.au  Fri Jan 17 09:46:22 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 17 Jan 2014 09:46:22 +1100
Subject: additional compiler hardening flags
In-Reply-To: <alpine.BSO.2.11.1401170939020.32270@natsu.mindrot.org>
References: <20130322050815.GA6024@gate.dtucker.net>
 <20130417230311.GD17666@linux124.nas.nasa.gov>
 <20130418011613.GA16696@gate.dtucker.net>
 <20130418014100.GA30605@gate.dtucker.net>
 <20131220190112.GT10110@linux124.nas.nasa.gov>
 <20140116215832.GA14093@gate.dtucker.net>
 <alpine.BSO.2.11.1401170939020.32270@natsu.mindrot.org>
Message-ID: <20140116224622.GA26377@gate.dtucker.net>

On Fri, Jan 17, 2014 at 09:39:58AM +1100, Damien Miller wrote:
> there's also a -fstack-protector-strong that we should support, probably
> in preference to -fstack-protector-all

added, here's what I'm about to commit.

Index: aclocal.m4
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/aclocal.m4,v
retrieving revision 1.9
diff -u -p -r1.9 aclocal.m4
--- aclocal.m4	2 Jun 2013 21:31:27 -0000	1.9
+++ aclocal.m4	30 Jul 2013 01:34:12 -0000
@@ -10,7 +10,7 @@ dnl 'check_flag'.
 AC_DEFUN([OSSH_CHECK_CFLAG_COMPILE], [{
 	AC_MSG_CHECKING([if $CC supports $1])
 	saved_CFLAGS="$CFLAGS"
-	CFLAGS="$CFLAGS $1"
+	CFLAGS="$CFLAGS $WERROR $1"
 	_define_flag="$2"
 	test "x$_define_flag" = "x" && _define_flag="$1"
 	AC_COMPILE_IFELSE([AC_LANG_SOURCE([[int main(void) { return 0; }]])],
@@ -28,6 +28,23 @@ fi],
 	)
 }])
 
+dnl OSSH_CHECK_CFLAG_LINK(check_flag[, define_flag])
+dnl Check that $LD accepts a flag 'check_flag'. If it is supported append
+dnl 'define_flag' to $LDFLAGS. If 'define_flag' is not specified, then append
+dnl 'check_flag'.
+AC_DEFUN([OSSH_CHECK_LDFLAG_LINK], [{
+	AC_MSG_CHECKING([if $LD supports $1])
+	saved_LDFLAGS="$LDFLAGS"
+	LDFLAGS="$LDFLAGS $WERROR $1"
+	_define_flag="$2"
+	test "x$_define_flag" = "x" && _define_flag="$1"
+	AC_LINK_IFELSE([AC_LANG_SOURCE([[int main(void) { return 0; }]])],
+		[ AC_MSG_RESULT([yes])
+		  LDFLAGS="$saved_LDFLAGS $_define_flag"],
+		[ AC_MSG_RESULT([no])
+		  LDFLAGS="$saved_LDFLAGS" ]
+	)
+}])
 
 dnl OSSH_CHECK_HEADER_FOR_FIELD(field, header, symbol)
 dnl Does AC_EGREP_HEADER on 'header' for the string 'field'
Index: configure.ac
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/configure.ac,v
retrieving revision 1.547
diff -u -p -r1.547 configure.ac
--- configure.ac	19 Dec 2013 00:00:12 -0000	1.547
+++ configure.ac	16 Jan 2014 22:43:45 -0000
@@ -121,18 +121,35 @@ AC_CHECK_DECL([PR_SET_NO_NEW_PRIVS], [ha
 	#include <linux/prctl.h>
 ])
 use_stack_protector=1
+use_toolchain_hardening=1
 AC_ARG_WITH([stackprotect],
     [  --without-stackprotect  Don't use compiler's stack protection], [
     if test "x$withval" = "xno"; then
 	use_stack_protector=0
     fi ])
+AC_ARG_WITH([hardening],
+    [  --without-hardening     Don't use toolchain hardening flags], [
+    if test "x$withval" = "xno"; then
+	use_stack_protector=0
+	use_toolchain_hardening=0
+    fi ])
 
+# We use -Werror for the tests only so that we catch warnings like "this is
+# on by default" for things like -fPIE.
+AC_MSG_CHECKING([if $CC supports -Werror])
+saved_CFLAGS="$CFLAGS"
+CFLAGS="$CFLAGS -Werror"
+AC_COMPILE_IFELSE([AC_LANG_SOURCE([[int main(void) { return 0; }]])],
+	[ AC_MSG_RESULT([yes])
+	  WERROR="-Werror"],
+	[ AC_MSG_RESULT([no])
+	  WERROR="" ]
+)
+CFLAGS="$saved_CFLAGS"
 
 if test "$GCC" = "yes" || test "$GCC" = "egcs"; then
-	OSSH_CHECK_CFLAG_COMPILE([-Qunused-arguments -Werror],
-	    [-Qunused-arguments])
-	OSSH_CHECK_CFLAG_COMPILE([-Wunknown-warning-option -Werror],
-	    [-Wno-unknown-warning-option])
+	OSSH_CHECK_CFLAG_COMPILE([-Qunused-arguments])
+	OSSH_CHECK_CFLAG_COMPILE([-Wunknown-warning-option])
 	OSSH_CHECK_CFLAG_COMPILE([-Wall])
 	OSSH_CHECK_CFLAG_COMPILE([-Wpointer-arith])
 	OSSH_CHECK_CFLAG_COMPILE([-Wuninitialized])
@@ -143,6 +160,14 @@ if test "$GCC" = "yes" || test "$GCC" = 
 	OSSH_CHECK_CFLAG_COMPILE([-Wunused-result], [-Wno-unused-result])
 	OSSH_CHECK_CFLAG_COMPILE([-fno-strict-aliasing])
 	OSSH_CHECK_CFLAG_COMPILE([-D_FORTIFY_SOURCE=2])
+    if test "x$use_toolchain_hardening" = "x1"; then
+	OSSH_CHECK_CFLAG_COMPILE([-ftrapv])
+	OSSH_CHECK_CFLAG_COMPILE([-fPIE])
+	OSSH_CHECK_LDFLAG_LINK([-pie])
+	OSSH_CHECK_LDFLAG_LINK([-Wl,-z,relro])
+	OSSH_CHECK_LDFLAG_LINK([-Wl,-z,now])
+	OSSH_CHECK_LDFLAG_LINK([-Wl,-z,noexecstack])
+    fi
 	AC_MSG_CHECKING([gcc version])
 	GCC_VER=`$CC -v 2>&1 | $AWK '/gcc version /{print $3}'`
 	case $GCC_VER in
@@ -169,7 +194,8 @@ if test "$GCC" = "yes" || test "$GCC" = 
 	# and/or platforms, so we test if we can.  If it's not supported
 	# on a given platform gcc will emit a warning so we use -Werror.
 	if test "x$use_stack_protector" = "x1"; then
-	    for t in -fstack-protector-all -fstack-protector; do
+	    for t in -fstack-protector-strong -fstack-protector-all \
+		    -fstack-protector; do
 		AC_MSG_CHECKING([if $CC supports $t])
 		saved_CFLAGS="$CFLAGS"
 		saved_LDFLAGS="$LDFLAGS"

-- 
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  Fri Jan 17 10:00:56 2014
From: djm at mindrot.org (Damien Miller)
Date: Fri, 17 Jan 2014 10:00:56 +1100 (EST)
Subject: additional compiler hardening flags
In-Reply-To: <20140116224426.GG2831@calimero.vinschen.de>
References: <20130322050815.GA6024@gate.dtucker.net>
 <20130417230311.GD17666@linux124.nas.nasa.gov>
 <20130418011613.GA16696@gate.dtucker.net>
 <20130418014100.GA30605@gate.dtucker.net>
 <20131220190112.GT10110@linux124.nas.nasa.gov>
 <20140116215832.GA14093@gate.dtucker.net>
 <20140116224426.GG2831@calimero.vinschen.de>
Message-ID: <alpine.BSO.2.11.1401170959590.32270@natsu.mindrot.org>

On Thu, 16 Jan 2014, Corinna Vinschen wrote:

> Will you accept patches to get rid of the existing warnings so we can
> build all of OpenSSH with -Werror?

We'll certainly consider them. I keep it warning-free on the platforms
that I build on.

-d

From dtucker at zip.com.au  Fri Jan 17 10:10:48 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 17 Jan 2014 10:10:48 +1100
Subject: additional compiler hardening flags
In-Reply-To: <20140116224426.GG2831@calimero.vinschen.de>
References: <20130322050815.GA6024@gate.dtucker.net>
 <20130417230311.GD17666@linux124.nas.nasa.gov>
 <20130418011613.GA16696@gate.dtucker.net>
 <20130418014100.GA30605@gate.dtucker.net>
 <20131220190112.GT10110@linux124.nas.nasa.gov>
 <20140116215832.GA14093@gate.dtucker.net>
 <20140116224426.GG2831@calimero.vinschen.de>
Message-ID: <20140116231048.GA31136@gate.dtucker.net>

On Thu, Jan 16, 2014 at 11:44:26PM +0100, Corinna Vinschen wrote:
> Will you accept patches to get rid of the existing warnings so we can
> build all of OpenSSH with -Werror?

Probably yes as long as it doesn't break any currently-working
platforms, and isn't a large maintenace burden.  At one point I could
compile on Fedora warning-free including PAM support, but I see a couple
of warnings have crept in due to either pickier compilers or platform
changes.

So warning fixes for -portable specific code: sure.  For code shared
with openbsd, yes if we can push it back upstream or do it in a way
that's doesn't cause every diff we pull to be a hassle.  Other things
maybe depending on what it is.

What have you got?  I'll open the bidding.

loginrec.c: In function 'login_get_lastlog':
loginrec.c:316:7: warning: format '%lu' expects argument of type
'long unsigned int', but argument 3 has type 'size_t' [-Wformat]
loginrec.c:316:7: warning: format '%lu' expects argument of type
'long unsigned int', but argument 4 has type 'unsigned int' [-Wformat]

Index: loginrec.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/loginrec.c,v
retrieving revision 1.93
diff -u -p -r1.93 loginrec.c
--- loginrec.c	29 Dec 2013 06:40:19 -0000	1.93
+++ loginrec.c	16 Jan 2014 22:58:07 -0000
@@ -313,7 +313,8 @@ login_get_lastlog(struct logininfo *li, 
 	if (strlcpy(li->username, pw->pw_name, sizeof(li->username)) >=
 	    sizeof(li->username)) {
 		error("%s: username too long (%lu > max %lu)", __func__,
-		    strlen(pw->pw_name), sizeof(li->username) - 1);
+		    (unsigned long)strlen(pw->pw_name),
+		    (unsigned long)sizeof(li->username) - 1);
 		return NULL;
 	}
 

-- 
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  Fri Jan 17 11:26:47 2014
From: djm at mindrot.org (Damien Miller)
Date: Fri, 17 Jan 2014 11:26:47 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
Message-ID: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>

Hi,

OpenSSH 6.5 is almost ready for release, so we would appreciate testing
on as many platforms and systems as possible. This release contains
some substantial new features and a number of bugfixes.

Snapshot releases for portable OpenSSH are available from
http://www.mindrot.org/openssh_snap/

The OpenBSD version is available in CVS HEAD:
http://www.openbsd.org/anoncvs.html

Portable OpenSSH is also available via anonymous CVS using the
instructions at http://www.openssh.com/portable.html#cvs or
via Mercurial at http://hg.mindrot.org/openssh

Running the regression tests supplied with Portable OpenSSH does not
require installation and is a simply:

$ ./configure && make tests

Live testing on suitable non-production systems is also
appreciated. Please send reports of success or failure to
openssh-unix-dev at mindrot.org.

Below is a summary of changes. More detail may be found in the ChangeLog
in the portable OpenSSH tarballs.

Thanks to the many people who contributed to this release.

Changes since OpenSSH 6.4
=========================

This is a feature-focused release.

New features:

 * ssh(1), sshd(8): Add support for key exchange using elliptic-curve
   Diffie Hellman in Daniel Bernstein's Curve25519. This key exchange
   method is the default when both the client and server support it.

 * ssh(1), sshd(8): Add support for Ed25519 as a public key type.
   Ed25519 is a elliptic curve signature scheme that offers
   better security than ECDSA and DSA and good performance. It may be
   used for both user and host keys.

 * Add a new private key format that uses a bcrypt KDF to better
   protect keys at rest. This format is used unconditionally for
   Ed25519 keys, but may be requested when generating or saving
   existing keys of other types via the -o ssh-keygen(1) option.
   We intend to make the new format the default in the near future.
   Details of the new format are in the PROTOCOL.key file.

 * ssh(1), sshd(8): Add a new transport cipher
   "chacha20-poly1305 at openssh.com" that combines Daniel Bernstein's
   ChaCha20 stream cipher and Poly1305 MAC to build an authenticated
   encryption mode. Details are in the PROTOCOL.chacha20poly1305 file.

 * ssh(1), sshd(8): Refuse RSA keys from old proprietary clients and
   servers that use the obsolete RSA+MD5 signature scheme. It will
   still be possible to connect with these clients/servers but only
   DSA keys will be accepted, and OpenSSH will refuse connection
   entirely in a future release.

 * ssh(1), sshd(8): Refuse old proprietary clients and servers that
   use a weaker key exchange hash calculation.

 * ssh(1): Increase the size of the Diffie-Hellman groups requested
   for each symmetric key size. New values from NIST Special
   Publication 800-57 with the upper limit specified by RFC4419

 * ssh(1), ssh-agent(1): Support pkcs#11 tokes that only provide
   X.509 certs instead of raw public keys (requested as bz#1908).

 * ssh(1): Add a ssh_config(5) "Match" keyword that allows
   conditional configuration to be applied by matching on hostname,
   user and result of arbitrary commands.

 * ssh(1): Add support for client-side hostname canonicalisation
   using a set of DNS suffixes and rules in ssh_config(5). This
   allows unqualified names to be canonicalised to fully-qualified
   domain names to eliminate ambiguity when looking up keys in
   known_hosts or checking host certificate names.

 * sftp-server(8): Add the ability to whitelist and/or blacklist sftp
   protocol requests by name.

 * sftp-server(8): Add a sftp "fsync at openssh.com" to support calling
   fsync(2) on an open file handle.

 * sshd(8): Add a ssh_config(5) PermitTTY to disallow TTY allocation,
   mirroring the longstanding no-pty authorized_keys option.

 * ssh(1): Add a ssh_config ProxyUseFDPass option that supports the
   use of ProxyCommands that establish a connection and then pass a
   connected file descriptor back to ssh(1). This allows the
   ProxyCommand to exit rather than staying around to transfer data.

Bugfixes:

 * ssh(1), sshd(8): Fix potential stack exhaustion caused by nested
   certificates.

 * ssh(1): bz#1211: make BindAddress work with UsePrivilegedPort.

 * sftp(1): bz#2137: fix the progress meter for resumed transfer.

 * ssh-add(1): bz#2187: do not request smartcard PIN when removing
   keys from ssh-agent.

 * sshd(8): bz#2139: fix re-exec fallback when original sshd binary
   cannot be executed.

 * ssh-keygen(1): Make relative-specified certificate expiry times
   relative to current time and not the validity start time.

 * sshd(8): bz#2161: fix AuthorizedKeysCommand inside a Match block.

 * sftp(1): bz#2129: symlinking a file would incorrectly canonicalise
   the target path.

 * ssh-agent(1): bz#2175: fix a use-after-free in the PKCS#11 agent
   helper executable.

 * sshd(8): Improve logging of sessions to include the user name,
   remote host and port, the session type (shell, command, etc.) and
   allocated TTY (if any).

 * sshd(8): bz#1297: tell the client (via a debug message) when
   their preferred listen address has been overridden by the
   server's GatewayPorts setting.

 * sshd(8): bz#2162: include report port in bad protocol banner
   message.

 * sftp(1): bz#2163: fix memory leak in error path in do_readdir()

 * sftp(1): bz#2171: don't leak file descriptor on error.

 * sshd(8): Include the local address and port in "Connection from
   ..." message (only shown at loglevel>=verbose)

Portable OpenSSH:

 * Switch to a ChaCha20-based arc4random() PRNG for platforms that do
   not provide their own.

 * sshd(8): bz#2156: restore Linux oom_adj setting when handling
   SIGHUP to maintain behaviour over retart.

 * sshd(8): bz#2032: use local username in krb5_kuserok check rather
   than full client name which may be of form user at REALM.

 * ssh(1), sshd(8): Test for both the presence of ECC NID numbers in
   OpenSSL and that they actually work. Fedora (at least) has
   NID_secp521r1 that doesn't work.

 * bz#2173: use pkg-config --libs to include correct -L location for
   libedit.

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

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

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


From djm at mindrot.org  Fri Jan 17 17:10:28 2014
From: djm at mindrot.org (Damien Miller)
Date: Fri, 17 Jan 2014 17:10:28 +1100 (EST)
Subject: New git repository
Message-ID: <alpine.BSO.2.11.1401171706470.32270@natsu.mindrot.org>

Hi,

When the Subversion mirror of portable OpenSSH fell into disrepair, I
promised to replace it with a git mirror. Well, I finally got around to
it - you can clone git://anongit.mindrot.org/openssh.git and browse at
https://anongit.mindrot.org/openssh.git/

The repository is also mirrored to github at
https://github.com/openssh/openssh-portable

These are very new and it's entirely possible that something is broken.
Please let me know if this is the case.

I'll look at switching development for portable OpenSSH from CVS to git
at some future time.

-d

From dtucker at zip.com.au  Fri Jan 17 19:26:54 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 17 Jan 2014 19:26:54 +1100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
Message-ID: <CALDDTe1PXoZUGNkZU0=x-VC6w0r9PJ-fA_aP1SNT+OCO7K=rYQ@mail.gmail.com>

Here's a potential problem (freebsd4 but probably other older platforms):

monitor_mm.c: In function `mm_make_entry':
monitor_mm.c:78: warning: unknown conversion type character `z' in format

All instances I've seen so far have been calls to fatal(), and that
does through snprintf. We should probably check for that and if found
use the snprintf in the compat library.

haven't had a chance to look into it yet but posting in case someone
else sees this.

-- 
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 sdaoden at gmail.com  Fri Jan 17 22:08:24 2014
From: sdaoden at gmail.com (Steffen Nurpmeso (Daode))
Date: Fri, 17 Jan 2014 12:08:24 +0100
Subject: New git repository
In-Reply-To: <alpine.BSO.2.11.1401171706470.32270@natsu.mindrot.org>
References: <alpine.BSO.2.11.1401171706470.32270@natsu.mindrot.org>
Message-ID: <20140117110824.xv0mIDT4PIvl10/gYAdJWgm9@dietcurd.local>

Damien Miller <djm at mindrot.org> wrote:
 |When the Subversion mirror of portable OpenSSH fell into disrepair, I
 |promised to replace it with a git mirror. Well, I finally got around to
 |it - you can clone git://anongit.mindrot.org/openssh.git and browse at
 |https://anongit.mindrot.org/openssh.git/
 |
 |The repository is also mirrored to github at
 |https://github.com/openssh/openssh-portable

That is great!
(It turns out .. i became addicted to git(1).)

 |These are very new and it's entirely possible that something is broken.
 |Please let me know if this is the case.
 |
 |I'll look at switching development for portable OpenSSH from CVS to git
 |at some future time.

It is working fine.
If i could voice a wish -- i'd hope for a mainstream branch; i.e.,
when all i do is

  $ git remote add -t master origin git://anongit.mindrot.org/openssh.git
  $ git fetch -v
  ...
   * [new tag]         V_5_5_P1   -> V_5_5_P1
   * [new tag]         V_5_7_P1   -> V_5_7_P1
   * [new tag]         V_6_0_P1   -> V_6_0_P1
   * [new tag]         V_6_1_P1   -> V_6_1_P1
   * [new tag]         V_6_2_P1   -> V_6_2_P1
  $

So i don't get all the releases through [master]:

  $ git ls-remote git://anongit.mindrot.org/openssh.git
  ...
  627337d95bee7dd8d4690238a35fffd35072d1fa  refs/tags/V_5_5_P1
  4b8ebe7e3647d3078fd4d025f4325b8cc1ac20d6  refs/tags/V_5_6_P1
  6f8f04b860765da07938bfe1fef017b00c3a3d55  refs/tags/V_5_7_P1
  8c0fe794fcc0f47ff728101568da865ab387dc6d  refs/tags/V_5_8_P1
  e784fe2683d560a8ab3d87b5b35f8e7b1ea20854  refs/tags/V_5_8_P2
  5643cf0fc4d71e783c6aef2574684f07d21945ab  refs/tags/V_5_9_P1
  d5dacb43fa30c2f6d7eebbd4c5fcf906c3b5d5d8  refs/tags/V_6_0_P1
  4eb0a532efe679917e07655721145c6882bdb4c7  refs/tags/V_6_1_P1
  eed8dc261018aea4d6b8606ca3addc9f8cf9ed1e  refs/tags/V_6_2_P1
  b396fa313014ca06e7e694ab01b7c36cba660b0a  refs/tags/V_6_2_P2
  4425e64da7dee0b3e81f1ae301f56fa3a83fe221  refs/tags/V_6_3_P1
  e01f4f6bfd6f5a47f810fd3522a151d59815402b  refs/tags/V_6_4_P1
  ...

It would be great if there would be the possibility to simply
follow the/a streamline (whatever it is, maybe a new dedicated
under refs/heads, like [releases] or simply whatever, there are
quite a few thereunder) and get all the releases.
While here, i'd be dreaming of an included generated configure,
too, as in checkout == distribution-to-go.
But enough -- thank you for sshd(8)!

--steffen

From aris at badcode.be  Fri Jan 17 22:49:58 2014
From: aris at badcode.be (Aris Adamantiadis)
Date: Fri, 17 Jan 2014 12:49:58 +0100
Subject: New git repository
In-Reply-To: <alpine.BSO.2.11.1401171706470.32270@natsu.mindrot.org>
References: <alpine.BSO.2.11.1401171706470.32270@natsu.mindrot.org>
Message-ID: <52D918E6.7050204@badcode.be>

Le 17/01/14 07:10, Damien Miller a ?crit :

> I'll look at switching development for portable OpenSSH from CVS to git
> at some future time.

That's really awesome ! Even better as Steffen suggested would be to
have a single git repository with portable branches and vanilla
branches. It would greatly help the cherry-picking of patches (my
favorite feature in git).

Aris


From gert at greenie.muc.de  Fri Jan 17 23:42:14 2014
From: gert at greenie.muc.de (Gert Doering)
Date: Fri, 17 Jan 2014 13:42:14 +0100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
Message-ID: <20140117124214.GH226@greenie.muc.de>

Hi,

On Fri, Jan 17, 2014 at 11:26:47AM +1100, Damien Miller wrote:
> OpenSSH 6.5 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This release contains
> some substantial new features and a number of bugfixes.
[..]

Tested the snapshot of today on NetBSD 5.1_STABLE/sparc64.

Took an eternity and a bit :-) - but everything passed:

...
key revocation lists: checking revocations for unrevoked certs
ok key revocation lists
all tests passed

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

From djm at mindrot.org  Fri Jan 17 23:49:31 2014
From: djm at mindrot.org (Damien Miller)
Date: Fri, 17 Jan 2014 23:49:31 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <20140117124214.GH226@greenie.muc.de>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <20140117124214.GH226@greenie.muc.de>
Message-ID: <alpine.BSO.2.11.1401172345330.32270@natsu.mindrot.org>

On Fri, 17 Jan 2014, Gert Doering wrote:

> Hi,
> 
> On Fri, Jan 17, 2014 at 11:26:47AM +1100, Damien Miller wrote:
> > OpenSSH 6.5 is almost ready for release, so we would appreciate testing
> > on as many platforms and systems as possible. This release contains
> > some substantial new features and a number of bugfixes.
> [..]
> 
> Tested the snapshot of today on NetBSD 5.1_STABLE/sparc64.
> 
> Took an eternity and a bit :-) - but everything passed:

Yes, the tests are a little slower now - we are testing more KEX, key
and cipher combinations, and doing it a little more exhaustively

Thanks!

-d

From djm at mindrot.org  Fri Jan 17 23:51:21 2014
From: djm at mindrot.org (Damien Miller)
Date: Fri, 17 Jan 2014 23:51:21 +1100 (EST)
Subject: New git repository
In-Reply-To: <20140117110824.xv0mIDT4PIvl10/gYAdJWgm9@dietcurd.local>
References: <alpine.BSO.2.11.1401171706470.32270@natsu.mindrot.org>
 <20140117110824.xv0mIDT4PIvl10/gYAdJWgm9@dietcurd.local>
Message-ID: <alpine.BSO.2.11.1401172349430.32270@natsu.mindrot.org>

On Fri, 17 Jan 2014, Steffen Nurpmeso wrote:

> It is working fine.
> If i could voice a wish -- i'd hope for a mainstream branch; i.e.,
> when all i do is
> 
>   $ git remote add -t master origin git://anongit.mindrot.org/openssh.git
>   $ git fetch -v
>   ...
>    * [new tag]         V_5_5_P1   -> V_5_5_P1
>    * [new tag]         V_5_7_P1   -> V_5_7_P1
>    * [new tag]         V_6_0_P1   -> V_6_0_P1
>    * [new tag]         V_6_1_P1   -> V_6_1_P1
>    * [new tag]         V_6_2_P1   -> V_6_2_P1
>   $
> 
> So i don't get all the releases through [master]:
> 
>   $ git ls-remote git://anongit.mindrot.org/openssh.git
>   ...
>   627337d95bee7dd8d4690238a35fffd35072d1fa  refs/tags/V_5_5_P1
>   4b8ebe7e3647d3078fd4d025f4325b8cc1ac20d6  refs/tags/V_5_6_P1
>   6f8f04b860765da07938bfe1fef017b00c3a3d55  refs/tags/V_5_7_P1
>   8c0fe794fcc0f47ff728101568da865ab387dc6d  refs/tags/V_5_8_P1
>   e784fe2683d560a8ab3d87b5b35f8e7b1ea20854  refs/tags/V_5_8_P2
>   5643cf0fc4d71e783c6aef2574684f07d21945ab  refs/tags/V_5_9_P1
>   d5dacb43fa30c2f6d7eebbd4c5fcf906c3b5d5d8  refs/tags/V_6_0_P1
>   4eb0a532efe679917e07655721145c6882bdb4c7  refs/tags/V_6_1_P1
>   eed8dc261018aea4d6b8606ca3addc9f8cf9ed1e  refs/tags/V_6_2_P1
>   b396fa313014ca06e7e694ab01b7c36cba660b0a  refs/tags/V_6_2_P2
>   4425e64da7dee0b3e81f1ae301f56fa3a83fe221  refs/tags/V_6_3_P1
>   e01f4f6bfd6f5a47f810fd3522a151d59815402b  refs/tags/V_6_4_P1
>   ...
> 
> It would be great if there would be the possibility to simply
> follow the/a streamline (whatever it is, maybe a new dedicated
> under refs/heads, like [releases] or simply whatever, there are
> quite a few thereunder) and get all the releases.

This might be a possibility if/when we move development to git.

> While here, i'd be dreaming of an included generated configure,
> too, as in checkout == distribution-to-go.
> But enough -- thank you for sshd(8)!

Not sure about this; I don't really want configure checked in as changes
there are just noise.

-d

From djm at mindrot.org  Fri Jan 17 23:59:38 2014
From: djm at mindrot.org (Damien Miller)
Date: Fri, 17 Jan 2014 23:59:38 +1100 (EST)
Subject: New git repository
In-Reply-To: <52D918E6.7050204@badcode.be>
References: <alpine.BSO.2.11.1401171706470.32270@natsu.mindrot.org>
 <52D918E6.7050204@badcode.be>
Message-ID: <alpine.BSO.2.11.1401172351240.32270@natsu.mindrot.org>

On Fri, 17 Jan 2014, Aris Adamantiadis wrote:

> Le 17/01/14 07:10, Damien Miller a ?crit :
> 
> > I'll look at switching development for portable OpenSSH from CVS to git
> > at some future time.
> 
> That's really awesome ! Even better as Steffen suggested would be to
> have a single git repository with portable branches and vanilla
> branches. It would greatly help the cherry-picking of patches (my
> favorite feature in git).

So, I'd like to make a maintained cvs->git conversions of the OpenBSD
upstream tree. How this will relate to a possible future primary git
portable tree is an open question that needs to be resolved before
we move development to git.

Ideally, portable would be a set of separable and well-labeled
patches atop the upstream tree but getting to that point would
take a lot of manual work to make said patches. I'm not sure
I have the time or the stomach to go through it.

While I have you attention, Aris. Could I ask you to check that
the current git portable OpenSSH interops with libssh using your
Curve25519 KEX? I make a couple of non-protocol code tweaks there
and want to be triply sure I didn't break anything...

-d


From gert at greenie.muc.de  Sat Jan 18 00:12:40 2014
From: gert at greenie.muc.de (Gert Doering)
Date: Fri, 17 Jan 2014 14:12:40 +0100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.11.1401172345330.32270@natsu.mindrot.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <20140117124214.GH226@greenie.muc.de>
 <alpine.BSO.2.11.1401172345330.32270@natsu.mindrot.org>
Message-ID: <20140117131240.GI226@greenie.muc.de>

Hi,

On Fri, Jan 17, 2014 at 11:49:31PM +1100, Damien Miller wrote:
> > Took an eternity and a bit :-) - but everything passed:
> 
> Yes, the tests are a little slower now - we are testing more KEX, key
> and cipher combinations, and doing it a little more exhaustively

I'm all for testing every possible combination of stuff :-) - running
the full test on this box took about 4 hours, but if it saves a single
debugging session of "why does it fail for cipher X on platform Y"
later on, it's all worth it...

gert

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

From dtucker at zip.com.au  Sat Jan 18 00:27:41 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 18 Jan 2014 00:27:41 +1100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <20140117131240.GI226@greenie.muc.de>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <20140117124214.GH226@greenie.muc.de>
 <alpine.BSO.2.11.1401172345330.32270@natsu.mindrot.org>
 <20140117131240.GI226@greenie.muc.de>
Message-ID: <CALDDTe3Yox5HhR5rTJn=H4XMvRe-wDoCKwABK7HMJQM1iHG5bw@mail.gmail.com>

On Sat, Jan 18, 2014 at 12:12 AM, Gert Doering <gert at greenie.muc.de> wrote:
[...]
> I'm all for testing every possible combination of stuff :-) - running
> the full test on this box took about 4 hours, but if it saves a single
> debugging session of "why does it fail for cipher X on platform Y"
> later on, it's all worth it...

It does.  In the case of failure there should be a set of failed-*.log
files containing both client and server side debug logs.  It's not
perfect, but it's a lot better than it used to be.

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

From dtucker at zip.com.au  Sat Jan 18 00:55:13 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 18 Jan 2014 00:55:13 +1100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
Message-ID: <CALDDTe3DBdXV6W17yXYqphHuJ=J7JPAgHgeufQkmHJGv2SYmZQ@mail.gmail.com>

build failure on netbsd4 with gssapi enabled while linking sshd:

gss-serv-krb5.o: In function `ssh_gssapi_krb5_storecreds?:
gss-serv-krb5.c:135: undefined reference to `krb5_cc_new_unique?

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

From vinschen at redhat.com  Sat Jan 18 01:59:52 2014
From: vinschen at redhat.com (Corinna Vinschen)
Date: Fri, 17 Jan 2014 15:59:52 +0100
Subject: additional compiler hardening flags
In-Reply-To: <20140116231048.GA31136@gate.dtucker.net>
References: <20130322050815.GA6024@gate.dtucker.net>
 <20130417230311.GD17666@linux124.nas.nasa.gov>
 <20130418011613.GA16696@gate.dtucker.net>
 <20130418014100.GA30605@gate.dtucker.net>
 <20131220190112.GT10110@linux124.nas.nasa.gov>
 <20140116215832.GA14093@gate.dtucker.net>
 <20140116224426.GG2831@calimero.vinschen.de>
 <20140116231048.GA31136@gate.dtucker.net>
Message-ID: <20140117145952.GN2831@calimero.vinschen.de>

On Jan 17 10:10, Darren Tucker wrote:
> On Thu, Jan 16, 2014 at 11:44:26PM +0100, Corinna Vinschen wrote:
> > Will you accept patches to get rid of the existing warnings so we can
> > build all of OpenSSH with -Werror?
> 
> Probably yes as long as it doesn't break any currently-working
> platforms, and isn't a large maintenace burden.  At one point I could
> compile on Fedora warning-free including PAM support, but I see a couple
> of warnings have crept in due to either pickier compilers or platform
> changes.
> 
> So warning fixes for -portable specific code: sure.  For code shared
> with openbsd, yes if we can push it back upstream or do it in a way
> that's doesn't cause every diff we pull to be a hassle.  Other things
> maybe depending on what it is.
> 
> What have you got?  I'll open the bidding.
> 
> loginrec.c: In function 'login_get_lastlog':
> loginrec.c:316:7: warning: format '%lu' expects argument of type
> 'long unsigned int', but argument 3 has type 'size_t' [-Wformat]
> loginrec.c:316:7: warning: format '%lu' expects argument of type
> 'long unsigned int', but argument 4 has type 'unsigned int' [-Wformat]
> 
> Index: loginrec.c
> ===================================================================
> RCS file: /home/dtucker/openssh/cvs/openssh/loginrec.c,v
> retrieving revision 1.93
> diff -u -p -r1.93 loginrec.c
> --- loginrec.c	29 Dec 2013 06:40:19 -0000	1.93
> +++ loginrec.c	16 Jan 2014 22:58:07 -0000
> @@ -313,7 +313,8 @@ login_get_lastlog(struct logininfo *li, 
>  	if (strlcpy(li->username, pw->pw_name, sizeof(li->username)) >=
>  	    sizeof(li->username)) {
>  		error("%s: username too long (%lu > max %lu)", __func__,
> -		    strlen(pw->pw_name), sizeof(li->username) - 1);
> +		    (unsigned long)strlen(pw->pw_name),
> +		    (unsigned long)sizeof(li->username) - 1);
>  		return NULL;
>  	}

I don't think I have any warning which is too intrusive to fix.
Let me see, I've just started building the latest from CVS.

[...time passes...]

Here's the first one:

   ../../src/openbsd-compat/fmt_scaled.c:84:2: error: array subscript has type ?char? [-Werror=char-subscripts]
     while (isascii(*p) && isspace(*p))
     ^
 
  This is a warning message which has been deliberately introduced
  in newlib years ago.  Per POSIX, the arguments to the ctype functions
  or macros are

  "[...] an *int*, the value of which the application shall ensure is
   representable as an *unsigned* *char* or equal to the value of the
   macro EOF. If the argument has any other value, the behavior is
   *undefined*."

  See, for instance
  http://pubs.opengroup.org/onlinepubs/9699919799/functions/isalpha.html

  The problem is this:  If char is a signed type, the value of the
  character 0xff, when cast to int, is -1, which is in practically all
  cases == EOF.  That means, the character 0xff is mistreated as EOF,
  even if it's a valid char, if the application does not cast the input
  character to unsigned char.  And the character 0xff is a valid char in
  many codesets, as in most ISO-8859 variants.

  So, quite literally, this is wrong:

    char p;
    if (isalpha (p))

  and this is correct:

    char p;
    if (isalpha((unsigned char) p)

  The fix is to change all calls to the ctype functions so that an
  input of type char is casted to unsigned char, so that the conversion
  to int does not result in invalid values.

Patch is easy:

Index: openbsd-compat/fmt_scaled.c
===================================================================
RCS file: /cvs/openssh/openbsd-compat/fmt_scaled.c,v
retrieving revision 1.1
diff -u -p -r1.1 fmt_scaled.c
--- openbsd-compat/fmt_scaled.c	19 May 2008 22:57:08 -0000	1.1
+++ openbsd-compat/fmt_scaled.c	17 Jan 2014 14:21:57 -0000
@@ -55,7 +55,7 @@ typedef enum {
 
 /* These three arrays MUST be in sync!  XXX make a struct */
 static unit_type units[] = { NONE, KILO, MEGA, GIGA, TERA, PETA, EXA };
-static char scale_chars[] = "BKMGTPE";
+static unsigned char scale_chars[] = "BKMGTPE";
 static long long scale_factors[] = {
 	1LL,
 	1024LL,
@@ -75,7 +75,7 @@ static long long scale_factors[] = {
 int
 scan_scaled(char *scaled, long long *result)
 {
-	char *p = scaled;
+	unsigned char *p = scaled;
 	int sign = 0;
 	unsigned int i, ndigits = 0, fract_digits = 0;
 	long long scale_fact = 1, whole = 0, fpart = 0;
Index: openbsd-compat/readpassphrase.c
===================================================================
RCS file: /cvs/openssh/openbsd-compat/readpassphrase.c,v
retrieving revision 1.23
diff -u -p -r1.23 readpassphrase.c
--- openbsd-compat/readpassphrase.c	13 Jan 2010 10:32:44 -0000	1.23
+++ openbsd-compat/readpassphrase.c	17 Jan 2014 14:59:24 -0000
@@ -131,11 +131,11 @@ restart:
 			if (p < end) {
 				if ((flags & RPP_SEVENBIT))
 					ch &= 0x7f;
-				if (isalpha(ch)) {
+				if (isalpha((unsigned char )ch)) {
 					if ((flags & RPP_FORCELOWER))
-						ch = (char)tolower(ch);
+						ch = (char)tolower((unsigned char )ch);
 					if ((flags & RPP_FORCEUPPER))
-						ch = (char)toupper(ch);
+						ch = (char)toupper((unsigned char )ch);
 				}
 				*p++ = ch;
 			}

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/20140117/a8cf1e04/attachment-0001.bin>

From vinschen at redhat.com  Sat Jan 18 03:03:54 2014
From: vinschen at redhat.com (Corinna Vinschen)
Date: Fri, 17 Jan 2014 17:03:54 +0100
Subject: additional compiler hardening flags
In-Reply-To: <20140117145952.GN2831@calimero.vinschen.de>
References: <20130322050815.GA6024@gate.dtucker.net>
 <20130417230311.GD17666@linux124.nas.nasa.gov>
 <20130418011613.GA16696@gate.dtucker.net>
 <20130418014100.GA30605@gate.dtucker.net>
 <20131220190112.GT10110@linux124.nas.nasa.gov>
 <20140116215832.GA14093@gate.dtucker.net>
 <20140116224426.GG2831@calimero.vinschen.de>
 <20140116231048.GA31136@gate.dtucker.net>
 <20140117145952.GN2831@calimero.vinschen.de>
Message-ID: <20140117160354.GO2831@calimero.vinschen.de>

On Jan 17 15:59, Corinna Vinschen wrote:
> On Jan 17 10:10, Darren Tucker wrote:
> > On Thu, Jan 16, 2014 at 11:44:26PM +0100, Corinna Vinschen wrote:
> > > Will you accept patches to get rid of the existing warnings so we can
> > > build all of OpenSSH with -Werror?
> > [...]
> I don't think I have any warning which is too intrusive to fix.
> Let me see, I've just started building the latest from CVS.
> 
> [...time passes...]
> 
> Here's the first one:
>

[...more time passes...]

And here's the rest of them:


"signed - unsigned comparisons".  The reason is that socklen_t
is signed, but sizeof returns a size_t value (addrmatch.c), resp
i was defined as unsigend type (canohost.c).

Index: addrmatch.c
===================================================================
RCS file: /cvs/openssh/addrmatch.c,v
retrieving revision 1.7
diff -u -p -r1.7 addrmatch.c
--- addrmatch.c	1 Jun 2013 21:31:18 -0000	1.7
+++ addrmatch.c	17 Jan 2014 15:52:17 -0000
@@ -88,13 +88,13 @@ addr_sa_to_xaddr(struct sockaddr *sa, so
 
 	switch (sa->sa_family) {
 	case AF_INET:
-		if (slen < sizeof(*in4))
+		if ((size_t) slen < sizeof(*in4))
 			return -1;
 		xa->af = AF_INET;
 		memcpy(&xa->v4, &in4->sin_addr, sizeof(xa->v4));
 		break;
 	case AF_INET6:
-		if (slen < sizeof(*in6))
+		if ((size_t) slen < sizeof(*in6))
 			return -1;
 		xa->af = AF_INET6;
 		memcpy(&xa->v6, &in6->sin6_addr, sizeof(xa->v6));
Index: canohost.c
===================================================================
RCS file: /cvs/openssh/canohost.c,v
retrieving revision 1.80
diff -u -p -r1.80 canohost.c
--- canohost.c	21 Nov 2013 02:57:15 -0000	1.80
+++ canohost.c	17 Jan 2014 15:52:17 -0000
@@ -155,7 +155,7 @@ check_ip_options(int sock, char *ipaddr)
 	u_char options[200];
 	char text[sizeof(options) * 3 + 1];
 	socklen_t option_size;
-	u_int i;
+	socklen_t i;
 	int ipproto;
 	struct protoent *ip;
 

A cygwin problem: The getopt variables (like optargs, optind) are
defined in getopt.h already.  Unfortunately they are defined as
"declspec(dllimport)" for historical reasons, because the GNU linker
didn't allow auto-import on PE/COFF targets way back when.  The problem
is, the dllexport attributes collide with the definitions in the various
source files in OpenSSH, which obviousy define the variables without 
declspec(dllimport).  The least intrusive way to get rid of these
warnings is to disable warnings for GCC compiler attributes.

Index: configure.ac
===================================================================
RCS file: /cvs/openssh/configure.ac,v
retrieving revision 1.553
diff -u -p -r1.553 configure.ac
--- configure.ac	17 Jan 2014 08:17:35 -0000	1.553
+++ configure.ac	17 Jan 2014 15:52:18 -0000
@@ -155,6 +155,7 @@ if test "$GCC" = "yes" || test "$GCC" = 
 	OSSH_CHECK_CFLAG_COMPILE([-Qunused-arguments])
 	OSSH_CHECK_CFLAG_COMPILE([-Wunknown-warning-option])
 	OSSH_CHECK_CFLAG_COMPILE([-Wall])
+	OSSH_CHECK_CFLAG_COMPILE([-Wno-attributes])
 	OSSH_CHECK_CFLAG_COMPILE([-Wpointer-arith])
 	OSSH_CHECK_CFLAG_COMPILE([-Wuninitialized])
 	OSSH_CHECK_CFLAG_COMPILE([-Wsign-compare])


The definition of USE_PIPES in session.c collides with the
definition in config.h:

Index: session.c
===================================================================
RCS file: /cvs/openssh/session.c,v
retrieving revision 1.424
diff -u -p -r1.424 session.c
--- session.c	30 Oct 2013 11:21:50 -0000	1.424
+++ session.c	17 Jan 2014 15:52:18 -0000
@@ -441,7 +441,7 @@ do_authenticated1(Authctxt *authctxt)
 	}
 }
 
-#define USE_PIPES
+#define USE_PIPES 1
 /*
  * This is called to fork and execute a command when we have no tty.  This
  * will call do_child from the child, and server_loop from the parent after


GCC is unhappy: error: no return statement in function returning non-void
[-Werror=return-type]:

Index: ssh-keyscan.c
===================================================================
RCS file: /cvs/openssh/ssh-keyscan.c,v
retrieving revision 1.110
diff -u -p -r1.110 ssh-keyscan.c
--- ssh-keyscan.c	7 Dec 2013 00:24:02 -0000	1.110
+++ ssh-keyscan.c	17 Jan 2014 15:52:18 -0000
@@ -221,6 +221,7 @@ hostjump(Key *hostkey)
 {
 	kexjmp_key = hostkey;
 	longjmp(kexjmp, 1);
+	return 0;		/* Silence compiler warnings. */
 }
 
 static int


Cygwin-only:   error: unused variable ?old_uid? [-Werror=unused-variable]
               error: unused variable ?old_gid? [-Werror=unused-variable]

Index: uidswap.c
===================================================================
RCS file: /cvs/openssh/uidswap.c,v
retrieving revision 1.63
diff -u -p -r1.63 uidswap.c
--- uidswap.c	21 Nov 2013 02:55:44 -0000	1.63
+++ uidswap.c	17 Jan 2014 15:52:18 -0000
@@ -134,7 +134,9 @@ temporarily_use_uid(struct passwd *pw)
 void
 permanently_drop_suid(uid_t uid)
 {
+#ifndef HAVE_CYGWIN
 	uid_t old_uid = getuid();
+#endif
 
 	debug("permanently_drop_suid: %u", (u_int)uid);
 	if (setresuid(uid, uid, uid) < 0)
@@ -197,8 +199,10 @@ restore_uid(void)
 void
 permanently_set_uid(struct passwd *pw)
 {
+#ifndef HAVE_CYGWIN
 	uid_t old_uid = getuid();
 	gid_t old_gid = getgid();
+#endif
 
 	if (pw == NULL)
 		fatal("permanently_set_uid: no user given");

Cygwin-only: Missing function declarations because a couple of months
ago we removed `#include <windows.h> from openbsd-compat/bsd-cygwin_util.h.
The problem:  The function declarations are only enabled in the system
header, if windows.h is included.  Duh.

Index: openbsd-compat/bsd-cygwin_util.h
===================================================================
RCS file: /cvs/openssh/openbsd-compat/bsd-cygwin_util.h,v
retrieving revision 1.16
diff -u -p -r1.16 bsd-cygwin_util.h
--- openbsd-compat/bsd-cygwin_util.h	1 Apr 2013 01:40:49 -0000	1.16
+++ openbsd-compat/bsd-cygwin_util.h	17 Jan 2014 15:52:19 -0000
@@ -40,8 +40,14 @@
 typedef void *HANDLE;
 #define INVALID_HANDLE_VALUE ((HANDLE) -1)
 
+/* Cygwin functions for which declarations are only available when including
+   windows headers, so we have to define them here explicitely. */
+extern HANDLE cygwin_logon_user (const struct passwd *, const char *);
+extern void cygwin_set_impersonation_token (const HANDLE);
+
 #include <sys/cygwin.h>
 #include <io.h>
+
 
 int binary_open(const char *, int , ...);
 int check_ntsec(const char *);


That's it, as far as the warnings are concerned.


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/20140117/5dffcbf4/attachment.bin>

From vinschen at redhat.com  Sat Jan 18 04:00:48 2014
From: vinschen at redhat.com (Corinna Vinschen)
Date: Fri, 17 Jan 2014 18:00:48 +0100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
Message-ID: <20140117170048.GP2831@calimero.vinschen.de>

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

I pulled from CVS HEAD.  Builds out of the box on Cygwin (baring the
-Werror issues, of course). All tests pass.


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/20140117/d61287f9/attachment.bin>

From sachstobia at aol.com  Sat Jan 18 04:13:15 2014
From: sachstobia at aol.com (Tobias Sachs)
Date: Fri, 17 Jan 2014 18:13:15 +0100
Subject: OpenSSH 6.5 test results
Message-ID: <52D964AB.8070900@aol.com>

Hello,

here are my test results on an Ubuntu 13.10 64Bit DigitalOcean 512 MB
Droplet
Linux cloud.gc-mc.de 3.8.0-19-generic #30-Ubuntu SMP Wed May 1 16:35:23
UTC 2013 x86_64 x86_64 x86_64 GNU/Linux

1st test:
run test connect.sh ...
Missing privilege separation directory: /var/empty
FATAL: sshd_proxy broken
make[1]: *** [t-exec] Error 1
make[1]: Leaving directory `/root/openssh/regress'
make: *** [tests] Error 2

2st test:
mkdir /var/empty

http://pastebin.com/y4SzETDD
or
https://tobiassachs.de/paste/?ffda4dbaa4f1677f#YWPHWFWUzAt09C13xM1NWqItBhewv+vJwfxa3IFvD5k=
please ignore the ssl warnings from my site i still have not a own ssl
cert for every domain ;)

3st test:

this test was on my own Proxmox vServer with Debian 7.3 with 16 GB RAM
and 8 kerns from i7 4770K
Linux gc-mc 3.12.1-4custom01-686-pae #3 SMP PREEMPT Thu Nov 28 19:13:57
CET 2013 x86_64 GNU/Linux

http://pastebin.com/Dxvs0ih5
https://tobiassachs.de/paste/?cd71aa3cf26d1cc3#U/atnyLfmCWaXD8KwBSNhY3KN+zFV6f37WqClFLMrCQ=

if you need more informations pls contact me :)

Greez
Tobias Sachs



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

From apb at cequrux.com  Sat Jan 18 05:35:26 2014
From: apb at cequrux.com (Alan Barrett)
Date: Fri, 17 Jan 2014 20:35:26 +0200
Subject: additional compiler hardening flags
In-Reply-To: <20140117145952.GN2831@calimero.vinschen.de>
References: <20130322050815.GA6024@gate.dtucker.net>
 <20130417230311.GD17666@linux124.nas.nasa.gov>
 <20130418011613.GA16696@gate.dtucker.net>
 <20130418014100.GA30605@gate.dtucker.net>
 <20131220190112.GT10110@linux124.nas.nasa.gov>
 <20140116215832.GA14093@gate.dtucker.net>
 <20140116224426.GG2831@calimero.vinschen.de>
 <20140116231048.GA31136@gate.dtucker.net>
 <20140117145952.GN2831@calimero.vinschen.de>
Message-ID: <20140117183526.GF2863@apb-laptoy.apb.alt.za>

On Fri, 17 Jan 2014, Corinna Vinschen wrote:
>Here's the first one:
>
>   ../../src/openbsd-compat/fmt_scaled.c:84:2: error: array subscript has type ?char? [-Werror=char-subscripts]
>     while (isascii(*p) && isspace(*p))
>     ^

If the openssh developers are interested in fixing this bug, I 
refer them to the spatch which I submitted several years ago, in
<https://lists.mindrot.org/pipermail/openssh-unix-dev/2010-August/028895.html>

--apb (Alan Barrett)

From imorgan at nas.nasa.gov  Sat Jan 18 09:14:52 2014
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Fri, 17 Jan 2014 14:14:52 -0800
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
Message-ID: <20140117221452.GA9100@linux124.nas.nasa.gov>

On Fri, Jan 17, 2014 at 11:26:47 +1100, Damien Miller wrote:
> Hi,
> 
> OpenSSH 6.5 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This release contains
> some substantial new features and a number of bugfixes.
> 

The 20140118 snapshot builds and passes all tests on:

	RHEL 6.5/amd64
	SLES 11sp1/amd64
	Mac OS X 10.8.5

For completeness, the following warnings were reported on RHEL and SLES:

readpassphrase.c:127: warning: ignoring return value of ?write?, declared with attribute warn_unused_result
readpassphrase.c:146: warning: ignoring return value of ?write?, declared with attribute warn_unused_result
log.c:448: warning: ignoring return value of ?write?, declared with attribute warn_unused_result
ssh.c:1183: warning: ignoring return value of ?daemon?, declared with attribute warn_unused_result
serverloop.c:151: warning: ignoring return value of ?write?, declared with attribute warn_unused_result
ssh-agent.c:1211: warning: ignoring return value of ?chdir?, declared with attribute warn_unused_result
scp.c:1341: warning: ignoring return value of ?write?, declared with attribute warn_unused_result
sftp.c:234: warning: ignoring return value of ?write?, declared with attribute warn_unused_result
sftp-client.c:1262: warning: ignoring return value of ?ftruncate?, declared with attribute warn_unused_result

The list is _much_ longer on OS X; about 750 warnings. However, most of
these appear to be related to OpenSSL and are probably related to having to
use --without-openssl-header-check.

-- 
Iain Morgan

From djm at mindrot.org  Sat Jan 18 09:30:24 2014
From: djm at mindrot.org (Damien Miller)
Date: Sat, 18 Jan 2014 09:30:24 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <CALDDTe3DBdXV6W17yXYqphHuJ=J7JPAgHgeufQkmHJGv2SYmZQ@mail.gmail.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <CALDDTe3DBdXV6W17yXYqphHuJ=J7JPAgHgeufQkmHJGv2SYmZQ@mail.gmail.com>
Message-ID: <alpine.BSO.2.11.1401180929010.32270@natsu.mindrot.org>

On Sat, 18 Jan 2014, Darren Tucker wrote:

> build failure on netbsd4 with gssapi enabled while linking sshd:
> 
> gss-serv-krb5.o: In function `ssh_gssapi_krb5_storecreds?:
> gss-serv-krb5.c:135: undefined reference to `krb5_cc_new_unique?

hmm, that line has been there for a while. No obvious changes to
krb5 detection in configure.ac either...


From loganaden at gmail.com  Sat Jan 18 17:24:21 2014
From: loganaden at gmail.com (Loganaden Velvindron)
Date: Sat, 18 Jan 2014 10:24:21 +0400
Subject: New git repository
In-Reply-To: <alpine.BSO.2.11.1401171706470.32270@natsu.mindrot.org>
References: <alpine.BSO.2.11.1401171706470.32270@natsu.mindrot.org>
Message-ID: <CAOp4FwS09a9ZuG+tDausZ=VeT1ggTX9hijPGBLhv2V_ndSuATA@mail.gmail.com>

On Fri, Jan 17, 2014 at 10:10 AM, Damien Miller <djm at mindrot.org> wrote:
> Hi,
>
> When the Subversion mirror of portable OpenSSH fell into disrepair, I
> promised to replace it with a git mirror. Well, I finally got around to
> it - you can clone git://anongit.mindrot.org/openssh.git and browse at
> https://anongit.mindrot.org/openssh.git/
>
> The repository is also mirrored to github at
> https://github.com/openssh/openssh-portable
>
> These are very new and it's entirely possible that something is broken.
> Please let me know if this is the case.

https://anongit.mindrot.org/ <- I'm getting gateway timed-out from Mauritius.


>
> I'll look at switching development for portable OpenSSH from CVS to git
> at some future time.
>
> -d
> _______________________________________________
> 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 dtucker at zip.com.au  Sat Jan 18 18:10:15 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 18 Jan 2014 18:10:15 +1100
Subject: New git repository
In-Reply-To: <CAOp4FwS09a9ZuG+tDausZ=VeT1ggTX9hijPGBLhv2V_ndSuATA@mail.gmail.com>
References: <alpine.BSO.2.11.1401171706470.32270@natsu.mindrot.org>
 <CAOp4FwS09a9ZuG+tDausZ=VeT1ggTX9hijPGBLhv2V_ndSuATA@mail.gmail.com>
Message-ID: <CALDDTe1frtJy0ZTEA8L5J2bWS_oW6p1k+aJKK-eKmP-Znn1Hmg@mail.gmail.com>

On Sat, Jan 18, 2014 at 5:24 PM, Loganaden Velvindron
<loganaden at gmail.com> wrote:
[...]
> https://anongit.mindrot.org/ <- I'm getting gateway timed-out from Mauritius.

Both ICMP and TCP to port 443 work from Australia and a host in the US
a of right now.  Maybe a local problem?

-- 
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 loganaden at gmail.com  Sat Jan 18 18:30:55 2014
From: loganaden at gmail.com (Loganaden Velvindron)
Date: Sat, 18 Jan 2014 11:30:55 +0400
Subject: New git repository
In-Reply-To: <CALDDTe1frtJy0ZTEA8L5J2bWS_oW6p1k+aJKK-eKmP-Znn1Hmg@mail.gmail.com>
References: <alpine.BSO.2.11.1401171706470.32270@natsu.mindrot.org>
 <CAOp4FwS09a9ZuG+tDausZ=VeT1ggTX9hijPGBLhv2V_ndSuATA@mail.gmail.com>
 <CALDDTe1frtJy0ZTEA8L5J2bWS_oW6p1k+aJKK-eKmP-Znn1Hmg@mail.gmail.com>
Message-ID: <CAOp4FwQjFc=OnUgN5OX32me9UYhEfP-RrLjA7Phcb_UE9OXp3g@mail.gmail.com>

On Sat, Jan 18, 2014 at 11:10 AM, Darren Tucker <dtucker at zip.com.au> wrote:
> On Sat, Jan 18, 2014 at 5:24 PM, Loganaden Velvindron
> <loganaden at gmail.com> wrote:
> [...]
>> https://anongit.mindrot.org/ <- I'm getting gateway timed-out from Mauritius.
>
> Both ICMP and TCP to port 443 work from Australia and a host in the US
> a of right now.  Maybe a local problem?

It was working perfectly fine when it was first set up. anoncvs and
bugzilla are working fine
from here. I'm digging further to see where the issue might be.

>
> --
> 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.



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

From loganaden at gmail.com  Sat Jan 18 18:37:54 2014
From: loganaden at gmail.com (Loganaden Velvindron)
Date: Sat, 18 Jan 2014 11:37:54 +0400
Subject: New git repository
In-Reply-To: <CAOp4FwQjFc=OnUgN5OX32me9UYhEfP-RrLjA7Phcb_UE9OXp3g@mail.gmail.com>
References: <alpine.BSO.2.11.1401171706470.32270@natsu.mindrot.org>
 <CAOp4FwS09a9ZuG+tDausZ=VeT1ggTX9hijPGBLhv2V_ndSuATA@mail.gmail.com>
 <CALDDTe1frtJy0ZTEA8L5J2bWS_oW6p1k+aJKK-eKmP-Znn1Hmg@mail.gmail.com>
 <CAOp4FwQjFc=OnUgN5OX32me9UYhEfP-RrLjA7Phcb_UE9OXp3g@mail.gmail.com>
Message-ID: <CAOp4FwT13W3UoG+dWo4+4Dz9oV-tJ8pgY+nmEwmLLYOU_Qrsrg@mail.gmail.com>

On Sat, Jan 18, 2014 at 11:30 AM, Loganaden Velvindron
<loganaden at gmail.com> wrote:
> On Sat, Jan 18, 2014 at 11:10 AM, Darren Tucker <dtucker at zip.com.au> wrote:
>> On Sat, Jan 18, 2014 at 5:24 PM, Loganaden Velvindron
>> <loganaden at gmail.com> wrote:
>> [...]
>>> https://anongit.mindrot.org/ <- I'm getting gateway timed-out from Mauritius.
>>
>> Both ICMP and TCP to port 443 work from Australia and a host in the US
>> a of right now.  Maybe a local problem?
>
> It was working perfectly fine when it was first set up. anoncvs and
> bugzilla are working fine
> from here. I'm digging further to see where the issue might be.

I also get the gateway timed-out message from devio.us in the US when I
connect to anongit.mindrot.org.


>
>>
>> --
>> 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.
>
>
>
> --
> This message is strictly personal and the opinions expressed do not
> represent those of my employers, either past or present.



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

From mancha1 at hush.com  Sat Jan 18 19:19:12 2014
From: mancha1 at hush.com (mancha)
Date: Sat, 18 Jan 2014 08:19:12 +0000 (UTC)
Subject: New git repository
References: <alpine.BSO.2.11.1401171706470.32270@natsu.mindrot.org>
 <CAOp4FwS09a9ZuG+tDausZ=VeT1ggTX9hijPGBLhv2V_ndSuATA@mail.gmail.com>
 <CALDDTe1frtJy0ZTEA8L5J2bWS_oW6p1k+aJKK-eKmP-Znn1Hmg@mail.gmail.com>
 <CAOp4FwQjFc=OnUgN5OX32me9UYhEfP-RrLjA7Phcb_UE9OXp3g@mail.gmail.com>
 <CAOp4FwT13W3UoG+dWo4+4Dz9oV-tJ8pgY+nmEwmLLYOU_Qrsrg@mail.gmail.com>
Message-ID: <loom.20140118T091801-888@post.gmane.org>

Loganaden Velvindron <loganaden <at> gmail.com> writes:
> > It was working perfectly fine when it was first set up. anoncvs and
> > bugzilla are working fine
> > from here. I'm digging further to see where the issue might be.
> 
> I also get the gateway timed-out message from devio.us in the US when I
> connect to anongit.mindrot.org.
> 

Also getting "504 Gateway Time-out" here. Problem likely lies
server-side.

--mancha


From dtucker at zip.com.au  Sat Jan 18 20:23:17 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 18 Jan 2014 20:23:17 +1100
Subject: New git repository
In-Reply-To: <loom.20140118T091801-888@post.gmane.org>
References: <alpine.BSO.2.11.1401171706470.32270@natsu.mindrot.org>
 <CAOp4FwS09a9ZuG+tDausZ=VeT1ggTX9hijPGBLhv2V_ndSuATA@mail.gmail.com>
 <CALDDTe1frtJy0ZTEA8L5J2bWS_oW6p1k+aJKK-eKmP-Znn1Hmg@mail.gmail.com>
 <CAOp4FwQjFc=OnUgN5OX32me9UYhEfP-RrLjA7Phcb_UE9OXp3g@mail.gmail.com>
 <CAOp4FwT13W3UoG+dWo4+4Dz9oV-tJ8pgY+nmEwmLLYOU_Qrsrg@mail.gmail.com>
 <loom.20140118T091801-888@post.gmane.org>
Message-ID: <CALDDTe1O6Biy4NyRKkWyuGwcUh9VVCEoxFdTrk5m_6Fk-FRwBQ@mail.gmail.com>

On Sat, Jan 18, 2014 at 7:19 PM, mancha <mancha1 at hush.com> wrote:
> Also getting "504 Gateway Time-out" here. Problem likely lies
> server-side.

Interesting.  Actually poking the http and https services shows the
same problem for me.  In summary:

ping works.
telnet anongit.mindrot.org on port 80 and 443 accept connections
git clone works
http and https on anongit.mindrot.org connect but return "504 Gateway
Time-out" from nginx.

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

From dtucker at zip.com.au  Sat Jan 18 21:14:00 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 18 Jan 2014 21:14:00 +1100
Subject: additional compiler hardening flags
In-Reply-To: <20140117160354.GO2831@calimero.vinschen.de>
References: <20130322050815.GA6024@gate.dtucker.net>
 <20130417230311.GD17666@linux124.nas.nasa.gov>
 <20130418011613.GA16696@gate.dtucker.net>
 <20130418014100.GA30605@gate.dtucker.net>
 <20131220190112.GT10110@linux124.nas.nasa.gov>
 <20140116215832.GA14093@gate.dtucker.net>
 <20140116224426.GG2831@calimero.vinschen.de>
 <20140116231048.GA31136@gate.dtucker.net>
 <20140117145952.GN2831@calimero.vinschen.de>
 <20140117160354.GO2831@calimero.vinschen.de>
Message-ID: <CALDDTe1wqZXQT06wC4wkm8mJP7ep=TeWPBrTKs8kAeHckVPosg@mail.gmail.com>

On Sat, Jan 18, 2014 at 3:03 AM, Corinna Vinschen <vinschen at redhat.com> wrote:
[warning fixes]

Thanks!

> A cygwin problem: The getopt variables (like optargs, optind) are
> defined in getopt.h already.  Unfortunately they are defined as
> "declspec(dllimport)" for historical reasons, because the GNU linker
> didn't allow auto-import on PE/COFF targets way back when.  The problem
> is, the dllexport attributes collide with the definitions in the various
> source files in OpenSSH, which obviousy define the variables without
> declspec(dllimport).  The least intrusive way to get rid of these
> warnings is to disable warnings for GCC compiler attributes.
[...]
> +       OSSH_CHECK_CFLAG_COMPILE([-Wno-attributes])

committed, but in the cygwin-specific section.

> The definition of USE_PIPES in session.c collides with the
> definition in config.h:
[...]

committed upstream.

> Cygwin-only:   error: unused variable ?old_uid? [-Werror=unused-variable]
>                error: unused variable ?old_gid? [-Werror=unused-variable]

committed.

> Cygwin-only: Missing function declarations because a couple of months
> ago we removed `#include <windows.h> from openbsd-compat/bsd-cygwin_util.h.
> The problem:  The function declarations are only enabled in the system
> header, if windows.h is included.  Duh.

committed.

I'm still looking at the rest.

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

From dtucker at zip.com.au  Sat Jan 18 21:23:54 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 18 Jan 2014 21:23:54 +1100
Subject: additional compiler hardening flags
In-Reply-To: <20140117183526.GF2863@apb-laptoy.apb.alt.za>
References: <20130322050815.GA6024@gate.dtucker.net>
 <20130417230311.GD17666@linux124.nas.nasa.gov>
 <20130418011613.GA16696@gate.dtucker.net>
 <20130418014100.GA30605@gate.dtucker.net>
 <20131220190112.GT10110@linux124.nas.nasa.gov>
 <20140116215832.GA14093@gate.dtucker.net>
 <20140116224426.GG2831@calimero.vinschen.de>
 <20140116231048.GA31136@gate.dtucker.net>
 <20140117145952.GN2831@calimero.vinschen.de>
 <20140117183526.GF2863@apb-laptoy.apb.alt.za>
Message-ID: <CALDDTe3hzy0FjmvgG0mQqTanoWE+ZXBm5ULcU2_dq3VtnJwrvA@mail.gmail.com>

On Sat, Jan 18, 2014 at 5:35 AM, Alan Barrett <apb at cequrux.com> wrote:
> On Fri, 17 Jan 2014, Corinna Vinschen wrote:
>>
>> Here's the first one:
>>
>>   ../../src/openbsd-compat/fmt_scaled.c:84:2: error: array subscript has
>> type ?char? [-Werror=char-subscripts]
>>     while (isascii(*p) && isspace(*p))
>>     ^
> If the openssh developers are interested in fixing this bug, I refer them to
> the spatch which I submitted several years ago, in
> <https://lists.mindrot.org/pipermail/openssh-unix-dev/2010-August/028895.html>

Sorry, I don't recall looking at that, or if I did I intended to go
back to it after that particular release and didn't.

Anyway, most of those have been fixed upstream recently and these
changes have been pulled into Portable.  The ones that haven't are in
the library functions we pull from OpenBSD but are not part of the
main OpenSSH source.

These have also have been fixed upstream, but there are other
non-trivial changes in those files too.  The choices are:
 a) pull in all the changes for the release and risk breaking something
 b) pull in just the ctype fixes for the release

I am not inclined to do a) until after the release, but doing b)
before the release makes that messier.  I'm leaning toward leaving
those 3 files until immediately after the release.

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

From apb at cequrux.com  Sat Jan 18 21:31:59 2014
From: apb at cequrux.com (Alan Barrett)
Date: Sat, 18 Jan 2014 12:31:59 +0200
Subject: additional compiler hardening flags
In-Reply-To: <CALDDTe3hzy0FjmvgG0mQqTanoWE+ZXBm5ULcU2_dq3VtnJwrvA@mail.gmail.com>
References: <20130417230311.GD17666@linux124.nas.nasa.gov>
 <20130418011613.GA16696@gate.dtucker.net>
 <20130418014100.GA30605@gate.dtucker.net>
 <20131220190112.GT10110@linux124.nas.nasa.gov>
 <20140116215832.GA14093@gate.dtucker.net>
 <20140116224426.GG2831@calimero.vinschen.de>
 <20140116231048.GA31136@gate.dtucker.net>
 <20140117145952.GN2831@calimero.vinschen.de>
 <20140117183526.GF2863@apb-laptoy.apb.alt.za>
 <CALDDTe3hzy0FjmvgG0mQqTanoWE+ZXBm5ULcU2_dq3VtnJwrvA@mail.gmail.com>
Message-ID: <20140118103158.GH2863@apb-laptoy.apb.alt.za>

On Sat, 18 Jan 2014, Darren Tucker wrote:
>>> [ctype functions called with char arguments]

>These have also have been fixed upstream, but there are other
>non-trivial changes in those files too.  The choices are:
> a) pull in all the changes for the release and risk breaking something
> b) pull in just the ctype fixes for the release
>
>I am not inclined to do a) until after the release, but doing b)
>before the release makes that messier.  I'm leaning toward leaving
>those 3 files until immediately after the release.

That seems fine to me.

--apb (Alan Barrett)

From loganaden at gmail.com  Sun Jan 19 00:36:09 2014
From: loganaden at gmail.com (Loganaden Velvindron)
Date: Sat, 18 Jan 2014 17:36:09 +0400
Subject: New git repository
In-Reply-To: <CALDDTe1O6Biy4NyRKkWyuGwcUh9VVCEoxFdTrk5m_6Fk-FRwBQ@mail.gmail.com>
References: <alpine.BSO.2.11.1401171706470.32270@natsu.mindrot.org>
 <CAOp4FwS09a9ZuG+tDausZ=VeT1ggTX9hijPGBLhv2V_ndSuATA@mail.gmail.com>
 <CALDDTe1frtJy0ZTEA8L5J2bWS_oW6p1k+aJKK-eKmP-Znn1Hmg@mail.gmail.com>
 <CAOp4FwQjFc=OnUgN5OX32me9UYhEfP-RrLjA7Phcb_UE9OXp3g@mail.gmail.com>
 <CAOp4FwT13W3UoG+dWo4+4Dz9oV-tJ8pgY+nmEwmLLYOU_Qrsrg@mail.gmail.com>
 <loom.20140118T091801-888@post.gmane.org>
 <CALDDTe1O6Biy4NyRKkWyuGwcUh9VVCEoxFdTrk5m_6Fk-FRwBQ@mail.gmail.com>
Message-ID: <CAOp4FwQMnwT=dV9uZE7AeSX7z01Y5rAk90CX6hppxpxaG78AQg@mail.gmail.com>

On Sat, Jan 18, 2014 at 1:23 PM, Darren Tucker <dtucker at zip.com.au> wrote:
> On Sat, Jan 18, 2014 at 7:19 PM, mancha <mancha1 at hush.com> wrote:
>> Also getting "504 Gateway Time-out" here. Problem likely lies
>> server-side.
>
> Interesting.  Actually poking the http and https services shows the
> same problem for me.  In summary:
>
> ping works.
> telnet anongit.mindrot.org on port 80 and 443 accept connections
> git clone works
> http and https on anongit.mindrot.org connect but return "504 Gateway
> Time-out" from nginx.

It was working quite well some time ago. However, it's no longer the
case right now :-(

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



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

From mancha1 at hush.com  Sun Jan 19 01:18:20 2014
From: mancha1 at hush.com (mancha)
Date: Sat, 18 Jan 2014 14:18:20 +0000 (UTC)
Subject: New git repository
References: <alpine.BSO.2.11.1401171706470.32270@natsu.mindrot.org>
 <CAOp4FwS09a9ZuG+tDausZ=VeT1ggTX9hijPGBLhv2V_ndSuATA@mail.gmail.com>
 <CALDDTe1frtJy0ZTEA8L5J2bWS_oW6p1k+aJKK-eKmP-Znn1Hmg@mail.gmail.com>
 <CAOp4FwQjFc=OnUgN5OX32me9UYhEfP-RrLjA7Phcb_UE9OXp3g@mail.gmail.com>
 <CAOp4FwT13W3UoG+dWo4+4Dz9oV-tJ8pgY+nmEwmLLYOU_Qrsrg@mail.gmail.com>
 <loom.20140118T091801-888@post.gmane.org>
 <CALDDTe1O6Biy4NyRKkWyuGwcUh9VVCEoxFdTrk5m_6Fk-FRwBQ@mail.gmail.com>
 <CAOp4FwQMnwT=dV9uZE7AeSX7z01Y5rAk90CX6hppxpxaG78AQg@mail.gmail.com>
Message-ID: <loom.20140118T151547-316@post.gmane.org>

Loganaden Velvindron <loganaden <at> gmail.com> writes:
> On Sat, Jan 18, 2014 at 1:23 PM, Darren Tucker <dtucker <at> zip.com.au>
wrote:
> > On Sat, Jan 18, 2014 at 7:19 PM, mancha <mancha1 <at> hush.com> wrote:
> >> Also getting "504 Gateway Time-out" here. Problem likely lies
> >> server-side.
> >
> > Interesting.  Actually poking the http and https services shows the
> > same problem for me.  In summary:
> >
> > ping works.
> > telnet anongit.mindrot.org on port 80 and 443 accept connections
> > git clone works
> > http and https on anongit.mindrot.org connect but return "504 Gateway
> > Time-out" from nginx.
> 
> It was working quite well some time ago. However, it's no longer the
> case right now 

Though it still doesn't work for me, the error has changed from 
"504 Gateway Time-out" to "502 Bad Gateway". Maybe this information
helps debug things.


From mouring at eviladmin.org  Sun Jan 19 04:38:17 2014
From: mouring at eviladmin.org (Ben Lindstrom)
Date: Sat, 18 Jan 2014 11:38:17 -0600
Subject: New git repository
In-Reply-To: <loom.20140118T151547-316@post.gmane.org>
References: <alpine.BSO.2.11.1401171706470.32270@natsu.mindrot.org>
 <CAOp4FwS09a9ZuG+tDausZ=VeT1ggTX9hijPGBLhv2V_ndSuATA@mail.gmail.com>
 <CALDDTe1frtJy0ZTEA8L5J2bWS_oW6p1k+aJKK-eKmP-Znn1Hmg@mail.gmail.com>
 <CAOp4FwQjFc=OnUgN5OX32me9UYhEfP-RrLjA7Phcb_UE9OXp3g@mail.gmail.com>
 <CAOp4FwT13W3UoG+dWo4+4Dz9oV-tJ8pgY+nmEwmLLYOU_Qrsrg@mail.gmail.com>
 <loom.20140118T091801-888@post.gmane.org>
 <CALDDTe1O6Biy4NyRKkWyuGwcUh9VVCEoxFdTrk5m_6Fk-FRwBQ@mail.gmail.com>
 <CAOp4FwQMnwT=dV9uZE7AeSX7z01Y5rAk90CX6hppxpxaG78AQg@mail.gmail.com>
 <loom.20140118T151547-316@post.gmane.org>
Message-ID: <4A61D330-3EC6-4CBD-B661-2264158460F1@eviladmin.org>


And FYI.. From my work (US - ATT) and my home (US - VISI) both come back with 504 Bad Gateway as well.

- Ben

On Jan 18, 2014, at 8:18 AM, mancha <mancha1 at hush.com> wrote:

> Loganaden Velvindron <loganaden <at> gmail.com> writes:
>> On Sat, Jan 18, 2014 at 1:23 PM, Darren Tucker <dtucker <at> zip.com.au>
> wrote:
>>> On Sat, Jan 18, 2014 at 7:19 PM, mancha <mancha1 <at> hush.com> wrote:
>>>> Also getting "504 Gateway Time-out" here. Problem likely lies
>>>> server-side.
>>> 
>>> Interesting.  Actually poking the http and https services shows the
>>> same problem for me.  In summary:
>>> 
>>> ping works.
>>> telnet anongit.mindrot.org on port 80 and 443 accept connections
>>> git clone works
>>> http and https on anongit.mindrot.org connect but return "504 Gateway
>>> Time-out" from nginx.
>> 
>> It was working quite well some time ago. However, it's no longer the
>> case right now 
> 
> Though it still doesn't work for me, the error has changed from 
> "504 Gateway Time-out" to "502 Bad Gateway". Maybe this information
> helps debug things.
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


From djm at mindrot.org  Sun Jan 19 09:15:42 2014
From: djm at mindrot.org (Damien Miller)
Date: Sun, 19 Jan 2014 09:15:42 +1100 (EST)
Subject: New git repository
In-Reply-To: <4A61D330-3EC6-4CBD-B661-2264158460F1@eviladmin.org>
References: <alpine.BSO.2.11.1401171706470.32270@natsu.mindrot.org>
 <CAOp4FwS09a9ZuG+tDausZ=VeT1ggTX9hijPGBLhv2V_ndSuATA@mail.gmail.com>
 <CALDDTe1frtJy0ZTEA8L5J2bWS_oW6p1k+aJKK-eKmP-Znn1Hmg@mail.gmail.com>
 <CAOp4FwQjFc=OnUgN5OX32me9UYhEfP-RrLjA7Phcb_UE9OXp3g@mail.gmail.com>
 <CAOp4FwT13W3UoG+dWo4+4Dz9oV-tJ8pgY+nmEwmLLYOU_Qrsrg@mail.gmail.com>
 <loom.20140118T091801-888@post.gmane.org>
 <CALDDTe1O6Biy4NyRKkWyuGwcUh9VVCEoxFdTrk5m_6Fk-FRwBQ@mail.gmail.com>
 <CAOp4FwQMnwT=dV9uZE7AeSX7z01Y5rAk90CX6hppxpxaG78AQg@mail.gmail.com>
 <loom.20140118T151547-316@post.gmane.org>
 <4A61D330-3EC6-4CBD-B661-2264158460F1@eviladmin.org>
Message-ID: <alpine.BSO.2.11.1401190914530.12826@natsu.mindrot.org>

Yes, still working the kinks out.

(Specifically, debugging the interaction between nginx and cgit via slowcgi)

On Sat, 18 Jan 2014, Ben Lindstrom wrote:

> 
> And FYI.. From my work (US - ATT) and my home (US - VISI) both come back with 504 Bad Gateway as well.
> 
> - Ben
> 
> On Jan 18, 2014, at 8:18 AM, mancha <mancha1 at hush.com> wrote:
> 
> > Loganaden Velvindron <loganaden <at> gmail.com> writes:
> >> On Sat, Jan 18, 2014 at 1:23 PM, Darren Tucker <dtucker <at> zip.com.au>
> > wrote:
> >>> On Sat, Jan 18, 2014 at 7:19 PM, mancha <mancha1 <at> hush.com> wrote:
> >>>> Also getting "504 Gateway Time-out" here. Problem likely lies
> >>>> server-side.
> >>> 
> >>> Interesting.  Actually poking the http and https services shows the
> >>> same problem for me.  In summary:
> >>> 
> >>> ping works.
> >>> telnet anongit.mindrot.org on port 80 and 443 accept connections
> >>> git clone works
> >>> http and https on anongit.mindrot.org connect but return "504 Gateway
> >>> Time-out" from nginx.
> >> 
> >> It was working quite well some time ago. However, it's no longer the
> >> case right now 
> > 
> > Though it still doesn't work for me, the error has changed from 
> > "504 Gateway Time-out" to "502 Bad Gateway". Maybe this information
> > helps debug things.
> > 
> > _______________________________________________
> > 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 kevin.brott at gmail.com  Sun Jan 19 11:29:21 2014
From: kevin.brott at gmail.com (Kevin Brott)
Date: Sat, 18 Jan 2014 16:29:21 -0800
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
Message-ID: <52DB1C61.9070701@gmail.com>

On 2014-01-16 16:26, Damien Miller wrote:
> Hi,
>
> OpenSSH 6.5 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This release contains
> some substantial new features and a number of bugfixes.
>
> Snapshot releases for portable OpenSSH are available from
> http://www.mindrot.org/openssh_snap/
>
> The OpenBSD version is available in CVS HEAD:
> http://www.openbsd.org/anoncvs.html
>
> Portable OpenSSH is also available via anonymous CVS using the
> instructions at http://www.openssh.com/portable.html#cvs or
> via Mercurial at http://hg.mindrot.org/openssh
>
> Running the regression tests supplied with Portable OpenSSH does not
> require installation and is a simply:
>
> $ ./configure && make tests
>
>

Using openssh-SNAP-20140119.tar.gz:
Debian GNU/Linux 7.3 (wheezy) x86_64, gcc (Debian 4.7.2-5) , and OpenSSL 1.0.1e 11 - all tests passed

Full test suite (RHEL/AIX/HP-UX/maybe Solaris) will get cranked up in the lab at work come Monday. :)





From nina.togakushi+ssh at gmail.com  Sun Jan 19 14:23:28 2014
From: nina.togakushi+ssh at gmail.com (togakushi)
Date: Sun, 19 Jan 2014 12:23:28 +0900
Subject: For the default of CanonicalizeFallbackLocal
Message-ID: <CAL8KRfp0t_UPyoMi7A7mtHnruGAycORCAA0x_cQJ4goOqoxTpg@mail.gmail.com>

Hi,

The default value for the option CanonicalizeFallbackLocal.

In the manual, The default value "no".

     CanonicalizeFallbackLocal
             Specifies whether to fail with an error when hostname canonical-
             ization fails.  The default, ?no?, will attempt to look up the
             unqualified hostname using the system resolver?s search rules.  A
             value of ?yes? will cause ssh(1) to fail instantly if
             CanonicalizeHostname is enabled and the target hostname cannot be
             found in any of the domains specified by CanonicalDomains.

but, I think in the "yes".
In the source code...

1476 initialize_options(Options * options)
1477 {
1561   options->canonicalize_fallback_local = -1;
1563 }

1571 fill_default_options(Options * options)
1572 {
1720   if (options->canonicalize_fallback_local == -1)
1721     options->canonicalize_fallback_local = 1;
1738 }

try,

"myserver" can name resolution but, "myserver.localdomain.local" can not.

  <.ssh/config>
  CanonicalizeHostname yes
  CanonicalDomains localdomain.local
  CanonicalizeFallbackLocal no

  $ ssh root at myserver
  ssh: Could not resolve host "myserver"

Not connected.

  <.ssh/config>
  CanonicalizeHostname yes
  CanonicalDomains localdomain.local
  #CanonicalizeFallbackLocal no <- comment out

  $ ssh root at myserver
  Last login: Sun Jan 19 02:51:12 2014 from 192.168.x.x
  root at myserver:~$

Connected.

When the settings have not been, I fall back.
This is the behavior when it is set to "yes".

Thanks.

From dtucker at zip.com.au  Sun Jan 19 15:18:37 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 19 Jan 2014 15:18:37 +1100
Subject: additional compiler hardening flags
In-Reply-To: <20140117160354.GO2831@calimero.vinschen.de>
References: <20130322050815.GA6024@gate.dtucker.net>
 <20130417230311.GD17666@linux124.nas.nasa.gov>
 <20130418011613.GA16696@gate.dtucker.net>
 <20130418014100.GA30605@gate.dtucker.net>
 <20131220190112.GT10110@linux124.nas.nasa.gov>
 <20140116215832.GA14093@gate.dtucker.net>
 <20140116224426.GG2831@calimero.vinschen.de>
 <20140116231048.GA31136@gate.dtucker.net>
 <20140117145952.GN2831@calimero.vinschen.de>
 <20140117160354.GO2831@calimero.vinschen.de>
Message-ID: <CALDDTe1be_acZru-NH0wtuOcbm5MUHaOM3uOv5MNxe6t1KA8CQ@mail.gmail.com>

On Sat, Jan 18, 2014 at 3:03 AM, Corinna Vinschen <vinschen at redhat.com> wrote:
[...]
> "signed - unsigned comparisons".  The reason is that socklen_t
> is signed, but sizeof returns a size_t value (addrmatch.c), resp
> i was defined as unsigend type (canohost.c).

committed upstream.

[...]'
> GCC is unhappy: error: no return statement in function returning non-void
> [-Werror=return-type]:
[...]
>         longjmp(kexjmp, 1);
> +       return 0;               /* Silence compiler warnings. */

This doesn't seem to be a problem on any other platforms.  Should your
longjmp be marked __attribute__ ((__noreturn__)) ?  If I'm looking at
the right thing it seems like it's not:
http://cygwin.com/cgi-bin/cvsweb.cgi/src/newlib/libc/include/setjmp.h?cvsroot=src

-- 
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  Sun Jan 19 15:47:21 2014
From: djm at mindrot.org (Damien Miller)
Date: Sun, 19 Jan 2014 15:47:21 +1100 (EST)
Subject: For the default of CanonicalizeFallbackLocal
In-Reply-To: <CAL8KRfp0t_UPyoMi7A7mtHnruGAycORCAA0x_cQJ4goOqoxTpg@mail.gmail.com>
References: <CAL8KRfp0t_UPyoMi7A7mtHnruGAycORCAA0x_cQJ4goOqoxTpg@mail.gmail.com>
Message-ID: <alpine.BSO.2.11.1401191547050.4801@natsu.mindrot.org>

On Sun, 19 Jan 2014, togakushi wrote:

> Hi,
> 
> The default value for the option CanonicalizeFallbackLocal.
> 
> In the manual, The default value "no".
> 
>      CanonicalizeFallbackLocal
>              Specifies whether to fail with an error when hostname canonical-
>              ization fails.  The default, ?no?, will attempt to look up the
>              unqualified hostname using the system resolver?s search rules.  A
>              value of ?yes? will cause ssh(1) to fail instantly if
>              CanonicalizeHostname is enabled and the target hostname cannot be
>              found in any of the domains specified by CanonicalDomains.
> 
> but, I think in the "yes".
> In the source code...

Thanks - the manpage is wrong:

Index: ssh_config.5
===================================================================
RCS file: /cvs/src/usr.bin/ssh/ssh_config.5,v
retrieving revision 1.183
diff -u -p -r1.183 ssh_config.5
--- ssh_config.5	7 Dec 2013 11:58:46 -0000	1.183
+++ ssh_config.5	19 Jan 2014 04:46:57 -0000
@@ -229,11 +229,11 @@ search for the specified destination hos
 .It Cm CanonicalizeFallbackLocal
 Specifies whether to fail with an error when hostname canonicalization fails.
 The default,
-.Dq no ,
+.Dq yes ,
 will attempt to look up the unqualified hostname using the system resolver's
 search rules.
 A value of
-.Dq yes
+.Dq no
 will cause
 .Xr ssh 1
 to fail instantly if

From raubvogel at gmail.com  Sun Jan 19 18:49:56 2014
From: raubvogel at gmail.com (Mauricio Tavares)
Date: Sun, 19 Jan 2014 02:49:56 -0500
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <52DB1C61.9070701@gmail.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52DB1C61.9070701@gmail.com>
Message-ID: <CAHEKYV4FLE=gGf-G_JtMi8xOnH8XWRnvuctPxaPZcX+s2ESBAw@mail.gmail.com>

On Sat, Jan 18, 2014 at 7:29 PM, Kevin Brott <kevin.brott at gmail.com> wrote:
> On 2014-01-16 16:26, Damien Miller wrote:
>>
>> Hi,
>>
>> OpenSSH 6.5 is almost ready for release, so we would appreciate testing
>> on as many platforms and systems as possible. This release contains
>> some substantial new features and a number of bugfixes.
>>
>> Snapshot releases for portable OpenSSH are available from
>> http://www.mindrot.org/openssh_snap/
>>
>> The OpenBSD version is available in CVS HEAD:
>> http://www.openbsd.org/anoncvs.html
>>
>> Portable OpenSSH is also available via anonymous CVS using the
>> instructions at http://www.openssh.com/portable.html#cvs or
>> via Mercurial at http://hg.mindrot.org/openssh
>>
>> Running the regression tests supplied with Portable OpenSSH does not
>> require installation and is a simply:
>>
>> $ ./configure && make tests
>>
>>
>
> Using openssh-SNAP-20140119.tar.gz:
> Debian GNU/Linux 7.3 (wheezy) x86_64, gcc (Debian 4.7.2-5) , and OpenSSL
> 1.0.1e 11 - all tests passed
>
> Full test suite (RHEL/AIX/HP-UX/maybe Solaris) will get cranked up in the
> lab at work come Monday. :)
>
      Ran 20140119 snapshot tests on Ubuntu 12.04.4 LTS x64; had to
create /var/empty but after that all test passed. Also compiled and
ran the same tests on CentOS 6.5 x64. And got the following:

[...]
certified host keys: host rsa connect wrong cert
certified host keys: host dsa connect wrong cert
certified host keys: host rsa connect wrong cert
certified host keys: host dsa connect wrong cert
failed certified host keys
make[1]: *** [t-exec] Error 1
make[1]: Leaving directory `/home/raub/dev/openssh/regress'
make: *** [tests] Error 2
[raub at devcentos openssh]$

Anything I should worry about? Or are they related to openssl/something else?

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

From vinschen at redhat.com  Sun Jan 19 20:40:13 2014
From: vinschen at redhat.com (Corinna Vinschen)
Date: Sun, 19 Jan 2014 10:40:13 +0100
Subject: additional compiler hardening flags
In-Reply-To: <CALDDTe1be_acZru-NH0wtuOcbm5MUHaOM3uOv5MNxe6t1KA8CQ@mail.gmail.com>
References: <20130417230311.GD17666@linux124.nas.nasa.gov>
 <20130418011613.GA16696@gate.dtucker.net>
 <20130418014100.GA30605@gate.dtucker.net>
 <20131220190112.GT10110@linux124.nas.nasa.gov>
 <20140116215832.GA14093@gate.dtucker.net>
 <20140116224426.GG2831@calimero.vinschen.de>
 <20140116231048.GA31136@gate.dtucker.net>
 <20140117145952.GN2831@calimero.vinschen.de>
 <20140117160354.GO2831@calimero.vinschen.de>
 <CALDDTe1be_acZru-NH0wtuOcbm5MUHaOM3uOv5MNxe6t1KA8CQ@mail.gmail.com>
Message-ID: <20140119094013.GA2358@calimero.vinschen.de>

On Jan 19 15:18, Darren Tucker wrote:
> On Sat, Jan 18, 2014 at 3:03 AM, Corinna Vinschen <vinschen at redhat.com> wrote:
> [...]
> > "signed - unsigned comparisons".  The reason is that socklen_t
> > is signed, but sizeof returns a size_t value (addrmatch.c), resp
> > i was defined as unsigend type (canohost.c).
> 
> committed upstream.
> 
> [...]'
> > GCC is unhappy: error: no return statement in function returning non-void
> > [-Werror=return-type]:
> [...]
> >         longjmp(kexjmp, 1);
> > +       return 0;               /* Silence compiler warnings. */
> 
> This doesn't seem to be a problem on any other platforms.  Should your
> longjmp be marked __attribute__ ((__noreturn__)) ?  If I'm looking at
> the right thing it seems like it's not:
> http://cygwin.com/cgi-bin/cvsweb.cgi/src/newlib/libc/include/setjmp.h?cvsroot=src

Thanks, I applied a patch upstream.

What about the patches from
http://lists.mindrot.org/pipermail/openssh-unix-dev/2014-January/031999.html
?


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/20140119/33122b2e/attachment.bin>

From dtucker at zip.com.au  Sun Jan 19 20:48:27 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 19 Jan 2014 20:48:27 +1100
Subject: additional compiler hardening flags
In-Reply-To: <20140119094013.GA2358@calimero.vinschen.de>
References: <20130417230311.GD17666@linux124.nas.nasa.gov>
 <20130418011613.GA16696@gate.dtucker.net>
 <20130418014100.GA30605@gate.dtucker.net>
 <20131220190112.GT10110@linux124.nas.nasa.gov>
 <20140116215832.GA14093@gate.dtucker.net>
 <20140116224426.GG2831@calimero.vinschen.de>
 <20140116231048.GA31136@gate.dtucker.net>
 <20140117145952.GN2831@calimero.vinschen.de>
 <20140117160354.GO2831@calimero.vinschen.de>
 <CALDDTe1be_acZru-NH0wtuOcbm5MUHaOM3uOv5MNxe6t1KA8CQ@mail.gmail.com>
 <20140119094013.GA2358@calimero.vinschen.de>
Message-ID: <CALDDTe06HJraVCwn6U1S82JdeaBuN68eLa1aFazbS8NrVx9CyA@mail.gmail.com>

On Sun, Jan 19, 2014 at 8:40 PM, Corinna Vinschen <vinschen at redhat.com> wrote:
[...]
> Thanks, I applied a patch upstream.

Thanks.

> What about the patches from
> http://lists.mindrot.org/pipermail/openssh-unix-dev/2014-January/031999.html
> ?

Those three have already been fixed in their respective upstream
versions, however they also contain other changes which I don't want
to risk pulling in right now given that we're so close to the release.
 I'll pull in all of the changes including the ctype fixes after the
release.

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

From djm at mindrot.org  Sun Jan 19 21:50:29 2014
From: djm at mindrot.org (Damien Miller)
Date: Sun, 19 Jan 2014 21:50:29 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <CAHEKYV4FLE=gGf-G_JtMi8xOnH8XWRnvuctPxaPZcX+s2ESBAw@mail.gmail.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52DB1C61.9070701@gmail.com>
 <CAHEKYV4FLE=gGf-G_JtMi8xOnH8XWRnvuctPxaPZcX+s2ESBAw@mail.gmail.com>
Message-ID: <alpine.BSO.2.11.1401192148480.4801@natsu.mindrot.org>

On Sun, 19 Jan 2014, Mauricio Tavares wrote:

>       Ran 20140119 snapshot tests on Ubuntu 12.04.4 LTS x64; had to
> create /var/empty but after that all test passed. Also compiled and
> ran the same tests on CentOS 6.5 x64. And got the following:
> 
> [...]
> certified host keys: host rsa connect wrong cert
> certified host keys: host dsa connect wrong cert
> certified host keys: host rsa connect wrong cert
> certified host keys: host dsa connect wrong cert
> failed certified host keys
> make[1]: *** [t-exec] Error 1
> make[1]: Leaving directory `/home/raub/dev/openssh/regress'
> make: *** [tests] Error 2
> [raub at devcentos openssh]$
> 
> Anything I should worry about? Or are they related to
> openssl/something else?

Those lines don't contain the actual error message. There should be a
failed-regress.log in the regress/ directory that shows the full test
log and failure. The one of failed-ssh.log and failed-sshd.log files
might also contain some clues.

-d

From vinschen at redhat.com  Sun Jan 19 21:58:41 2014
From: vinschen at redhat.com (Corinna Vinschen)
Date: Sun, 19 Jan 2014 11:58:41 +0100
Subject: additional compiler hardening flags
In-Reply-To: <CALDDTe06HJraVCwn6U1S82JdeaBuN68eLa1aFazbS8NrVx9CyA@mail.gmail.com>
References: <20130418014100.GA30605@gate.dtucker.net>
 <20131220190112.GT10110@linux124.nas.nasa.gov>
 <20140116215832.GA14093@gate.dtucker.net>
 <20140116224426.GG2831@calimero.vinschen.de>
 <20140116231048.GA31136@gate.dtucker.net>
 <20140117145952.GN2831@calimero.vinschen.de>
 <20140117160354.GO2831@calimero.vinschen.de>
 <CALDDTe1be_acZru-NH0wtuOcbm5MUHaOM3uOv5MNxe6t1KA8CQ@mail.gmail.com>
 <20140119094013.GA2358@calimero.vinschen.de>
 <CALDDTe06HJraVCwn6U1S82JdeaBuN68eLa1aFazbS8NrVx9CyA@mail.gmail.com>
Message-ID: <20140119105841.GB2358@calimero.vinschen.de>

On Jan 19 20:48, Darren Tucker wrote:
> On Sun, Jan 19, 2014 at 8:40 PM, Corinna Vinschen <vinschen at redhat.com> wrote:
> [...]
> > Thanks, I applied a patch upstream.
> 
> Thanks.
> 
> > What about the patches from
> > http://lists.mindrot.org/pipermail/openssh-unix-dev/2014-January/031999.html
> > ?
> 
> Those three have already been fixed in their respective upstream
> versions, however they also contain other changes which I don't want
> to risk pulling in right now given that we're so close to the release.
>  I'll pull in all of the changes including the ctype fixes after the
> release.

Sounds good.


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/20140119/7f1af481/attachment.bin>

From loganaden at gmail.com  Mon Jan 20 01:46:28 2014
From: loganaden at gmail.com (Loganaden Velvindron)
Date: Sun, 19 Jan 2014 18:46:28 +0400
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.11.1401192148480.4801@natsu.mindrot.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52DB1C61.9070701@gmail.com>
 <CAHEKYV4FLE=gGf-G_JtMi8xOnH8XWRnvuctPxaPZcX+s2ESBAw@mail.gmail.com>
 <alpine.BSO.2.11.1401192148480.4801@natsu.mindrot.org>
Message-ID: <CAOp4FwTMzFvDFvm69YRhAMqmA08nVu+-m3XZaYdugioTY+7ktw@mail.gmail.com>

On Sun, Jan 19, 2014 at 2:50 PM, Damien Miller <djm at mindrot.org> wrote:
> On Sun, 19 Jan 2014, Mauricio Tavares wrote:
>
>>       Ran 20140119 snapshot tests on Ubuntu 12.04.4 LTS x64; had to
>> create /var/empty but after that all test passed. Also compiled and
>> ran the same tests on CentOS 6.5 x64. And got the following:
>>
>> [...]
>> certified host keys: host rsa connect wrong cert
>> certified host keys: host dsa connect wrong cert
>> certified host keys: host rsa connect wrong cert
>> certified host keys: host dsa connect wrong cert
>> failed certified host keys
>> make[1]: *** [t-exec] Error 1
>> make[1]: Leaving directory `/home/raub/dev/openssh/regress'
>> make: *** [tests] Error 2
>> [raub at devcentos openssh]$
>>
>> Anything I should worry about? Or are they related to
>> openssl/something else?
>
> Those lines don't contain the actual error message. There should be a
> failed-regress.log in the regress/ directory that shows the full test
> log and failure. The one of failed-ssh.log and failed-sshd.log files
> might also contain some clues.

I was looking at the new digest API and something caught my attention.

struct ssh_digest_ctx *
ssh_digest_start(int alg) {
        const struct ssh_digest *digest = ssh_digest_by_alg(alg);
        struct ssh_digest_ctx *ret;

        if (digest == NULL || ((ret = calloc(1, sizeof(*ret))) == NULL))
                return NULL;
        ret->alg = alg;
        EVP_MD_CTX_init(&ret->mdctx);
        if (EVP_DigestInit_ex(&ret->mdctx, digest->mdfunc(), NULL) != 1) {
                free(ret);
                return NULL;
        }
        return ret;
}
ret is calloc()'ed.

int
ssh_digest_memory(int alg, const void *m, size_t mlen, u_char *d, size_t dlen)
{
        struct ssh_digest_ctx *ctx = ssh_digest_start(alg);

        if (ctx == NULL)
                return -1;
        if (ssh_digest_update(ctx, m, mlen) != 0 ||
            ssh_digest_final(ctx, d, dlen) != 0)
                return -1;
        ssh_digest_free(ctx);
        return 0;
}

ssh_digest_memory() it calls ssh_digest_free(ctx);

void
ssh_digest_free(struct ssh_digest_ctx *ctx)
{
        EVP_MD_CTX_cleanup(&ctx->mdctx);
        memset(ctx, 0, sizeof(*ctx));

}
shouldn't there be a call to free(ctx); in ssh_digest_free()  before returning ?



>
> -d
> _______________________________________________
> 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 dtucker at zip.com.au  Mon Jan 20 12:51:23 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 20 Jan 2014 12:51:23 +1100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.11.1401180929010.32270@natsu.mindrot.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <CALDDTe3DBdXV6W17yXYqphHuJ=J7JPAgHgeufQkmHJGv2SYmZQ@mail.gmail.com>
 <alpine.BSO.2.11.1401180929010.32270@natsu.mindrot.org>
Message-ID: <CALDDTe3G7L_p0K5yfi4tjW2Ze76B-ua38uHmz0DciF6QggCx1A@mail.gmail.com>

On Sat, Jan 18, 2014 at 9:30 AM, Damien Miller <djm at mindrot.org> wrote:
> On Sat, 18 Jan 2014, Darren Tucker wrote:
>
>> build failure on netbsd4 with gssapi enabled while linking sshd:
>>
>> gss-serv-krb5.o: In function `ssh_gssapi_krb5_storecreds?:
>> gss-serv-krb5.c:135: undefined reference to `krb5_cc_new_unique?
>
> hmm, that line has been there for a while. No obvious changes to
> krb5 detection in configure.ac either...

It came in with this change:

revision 1.18
date: 2013/07/20 03:35:45;  author: djm;  state: Exp;  lines: +25 -19
   - djm at cvs.openbsd.org 2013/07/20 01:55:13
     [auth-krb5.c gss-serv-krb5.c gss-serv.c]
     fix kerberos/GSSAPI deprecation warnings and linking; "looks okay" millert@

-       if ((problem = krb5_cc_gen_new(krb_context, &krb5_fcc_ops, &ccache))) {
-               logit("krb5_cc_gen_new(): %.100s",
-                   krb5_get_err_text(krb_context, problem));
+       if ((problem = krb5_cc_new_unique(krb_context, krb5_fcc_ops.prefix,
+           NULL, &ccache)) != 0) {
+               errmsg = krb5_get_error_message(krb_context, problem);
+               logit("krb5_cc_new_unique(): %.100s", errmsg);
+               krb5_free_error_message(krb_context, errmsg);
                return;
        }
[other stuff omitted]

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

From dtucker at zip.com.au  Mon Jan 20 13:02:30 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 20 Jan 2014 13:02:30 +1100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.11.1401180929010.32270@natsu.mindrot.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <CALDDTe3DBdXV6W17yXYqphHuJ=J7JPAgHgeufQkmHJGv2SYmZQ@mail.gmail.com>
 <alpine.BSO.2.11.1401180929010.32270@natsu.mindrot.org>
Message-ID: <20140120020230.GA24475@gate.dtucker.net>

On Sat, Jan 18, 2014 at 09:30:24AM +1100, Damien Miller wrote:
> On Sat, 18 Jan 2014, Darren Tucker wrote:
> 
> > build failure on netbsd4 with gssapi enabled while linking sshd:
> > 
> > gss-serv-krb5.o: In function `ssh_gssapi_krb5_storecreds?:
> > gss-serv-krb5.c:135: undefined reference to `krb5_cc_new_unique?
> 
> hmm, that line has been there for a while. No obvious changes to
> krb5 detection in configure.ac either...

Turns out we already detect this in configure and handle it in
auth-krb5.c.  ok?

Index: gss-serv-krb5.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/gss-serv-krb5.c,v
retrieving revision 1.18
diff -u -p -r1.18 gss-serv-krb5.c
--- gss-serv-krb5.c	20 Jul 2013 03:35:45 -0000	1.18
+++ gss-serv-krb5.c	20 Jan 2014 01:58:33 -0000
@@ -132,10 +132,16 @@ ssh_gssapi_krb5_storecreds(ssh_gssapi_cl
 		return;
 
 #ifdef HEIMDAL
+# ifdef HAVE_KRB5_CC_NEW_UNIQUE
 	if ((problem = krb5_cc_new_unique(krb_context, krb5_fcc_ops.prefix,
 	    NULL, &ccache)) != 0) {
 		errmsg = krb5_get_error_message(krb_context, problem);
 		logit("krb5_cc_new_unique(): %.100s", errmsg);
+# else
+	if ((problem = krb5_cc_gen_new(krb_context, &krb5_fcc_ops, &ccache))) {
+	    logit("krb5_cc_gen_new(): %.100s",
+		krb5_get_err_text(krb_context, problem));
+# endif
 		krb5_free_error_message(krb_context, errmsg);
 		return;
 	}

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

From djm at mindrot.org  Mon Jan 20 13:34:56 2014
From: djm at mindrot.org (Damien Miller)
Date: Mon, 20 Jan 2014 13:34:56 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <CALDDTe3G7L_p0K5yfi4tjW2Ze76B-ua38uHmz0DciF6QggCx1A@mail.gmail.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <CALDDTe3DBdXV6W17yXYqphHuJ=J7JPAgHgeufQkmHJGv2SYmZQ@mail.gmail.com>
 <alpine.BSO.2.11.1401180929010.32270@natsu.mindrot.org>
 <CALDDTe3G7L_p0K5yfi4tjW2Ze76B-ua38uHmz0DciF6QggCx1A@mail.gmail.com>
Message-ID: <alpine.BSO.2.11.1401201332560.4801@natsu.mindrot.org>

On Mon, 20 Jan 2014, Darren Tucker wrote:

> On Sat, Jan 18, 2014 at 9:30 AM, Damien Miller <djm at mindrot.org> wrote:
> > On Sat, 18 Jan 2014, Darren Tucker wrote:
> >
> >> build failure on netbsd4 with gssapi enabled while linking sshd:
> >>
> >> gss-serv-krb5.o: In function `ssh_gssapi_krb5_storecreds?:
> >> gss-serv-krb5.c:135: undefined reference to `krb5_cc_new_unique?
> >
> > hmm, that line has been there for a while. No obvious changes to
> > krb5 detection in configure.ac either...
> 
> It came in with this change:

ah, I'd only looked back at the previous release.

Looks like we already have #ifdefs around it in auth-krb5.c:

# ifdef HAVE_KRB5_CC_NEW_UNIQUE
        problem = krb5_cc_new_unique(authctxt->krb5_ctx,
             krb5_mcc_ops.prefix, NULL, &ccache);
# else
        problem = krb5_cc_gen_new(authctxt->krb5_ctx, &krb5_mcc_ops, &ccache);
# endif

From djm at mindrot.org  Mon Jan 20 15:00:27 2014
From: djm at mindrot.org (Damien Miller)
Date: Mon, 20 Jan 2014 15:00:27 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <20140120020230.GA24475@gate.dtucker.net>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <CALDDTe3DBdXV6W17yXYqphHuJ=J7JPAgHgeufQkmHJGv2SYmZQ@mail.gmail.com>
 <alpine.BSO.2.11.1401180929010.32270@natsu.mindrot.org>
 <20140120020230.GA24475@gate.dtucker.net>
Message-ID: <alpine.BSO.2.11.1401201500100.4801@natsu.mindrot.org>

ok djm

On Mon, 20 Jan 2014, Darren Tucker wrote:

> On Sat, Jan 18, 2014 at 09:30:24AM +1100, Damien Miller wrote:
> > On Sat, 18 Jan 2014, Darren Tucker wrote:
> > 
> > > build failure on netbsd4 with gssapi enabled while linking sshd:
> > > 
> > > gss-serv-krb5.o: In function `ssh_gssapi_krb5_storecreds?:
> > > gss-serv-krb5.c:135: undefined reference to `krb5_cc_new_unique?
> > 
> > hmm, that line has been there for a while. No obvious changes to
> > krb5 detection in configure.ac either...
> 
> Turns out we already detect this in configure and handle it in
> auth-krb5.c.  ok?
> 
> Index: gss-serv-krb5.c
> ===================================================================
> RCS file: /home/dtucker/openssh/cvs/openssh/gss-serv-krb5.c,v
> retrieving revision 1.18
> diff -u -p -r1.18 gss-serv-krb5.c
> --- gss-serv-krb5.c	20 Jul 2013 03:35:45 -0000	1.18
> +++ gss-serv-krb5.c	20 Jan 2014 01:58:33 -0000
> @@ -132,10 +132,16 @@ ssh_gssapi_krb5_storecreds(ssh_gssapi_cl
>  		return;
>  
>  #ifdef HEIMDAL
> +# ifdef HAVE_KRB5_CC_NEW_UNIQUE
>  	if ((problem = krb5_cc_new_unique(krb_context, krb5_fcc_ops.prefix,
>  	    NULL, &ccache)) != 0) {
>  		errmsg = krb5_get_error_message(krb_context, problem);
>  		logit("krb5_cc_new_unique(): %.100s", errmsg);
> +# else
> +	if ((problem = krb5_cc_gen_new(krb_context, &krb5_fcc_ops, &ccache))) {
> +	    logit("krb5_cc_gen_new(): %.100s",
> +		krb5_get_err_text(krb_context, problem));
> +# endif
>  		krb5_free_error_message(krb_context, errmsg);
>  		return;
>  	}
> 
> -- 
> 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 andyb1 at andy-t.org  Mon Jan 20 15:48:30 2014
From: andyb1 at andy-t.org (Andy Tsouladze)
Date: Sun, 19 Jan 2014 22:48:30 -0600 (CST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <CALDDTe3G7L_p0K5yfi4tjW2Ze76B-ua38uHmz0DciF6QggCx1A@mail.gmail.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <CALDDTe3DBdXV6W17yXYqphHuJ=J7JPAgHgeufQkmHJGv2SYmZQ@mail.gmail.com>
 <alpine.BSO.2.11.1401180929010.32270@natsu.mindrot.org>
 <CALDDTe3G7L_p0K5yfi4tjW2Ze76B-ua38uHmz0DciF6QggCx1A@mail.gmail.com>
Message-ID: <alpine.LNX.2.02.1401192126000.26637@mate.andy-t.org>

Snapshot openssh-SNAP-20140121.tar.gz builds and passes all tests on 
Slackware-14.0, 64-bit.

Regards,

Andy

Dr Andy Tsouladze
Sr Unix/Storage/Security SysAdmin
PWD=`cat /dev/urandom | sed 's/[^\x21-\x7f]//g' | head -c 14`

From andyb1 at andy-t.org  Mon Jan 20 16:38:45 2014
From: andyb1 at andy-t.org (Andy Tsouladze)
Date: Sun, 19 Jan 2014 23:38:45 -0600 (CST)
Subject: bug in scp (maybe)
Message-ID: <alpine.LNX.2.02.1401192314190.26637@mate.andy-t.org>

Hello,

While playing around with various openssh features and options, I tried to 
use `scp -3' which copies files between two remote systems.  It works fine 
if password is not required for either SRC or DEST systems, and if 
password is required only for one remote system (either SRC or DEST).  The 
problem happens only if both SRC and DEST systems require a password. 
Here is a session:

----------------------------
scp -3 andyt2 at majesty:/etc/group andyt2 at mate:/tmp/group
andyt2 at majesty's password: andyt2 at mate's password:
XXXXXX

---------------------------
As you can see, after the command is started, both remote systems prompt 
for a password on the same line.  So I enter a password for user andyt2 
and press ENTER.  What happens next is probably a bug.  Line advances, and 
nothing at all happens.  So I am assuming that now the second system is 
waiting for a password.  I enter it, and it appears in the terminal in 
cleartext (substituted here with XXXXXX).  The command then proceeds and 
finishes successfully.

A workaround I found is to simply press ENTER instead of typing a second 
password.  Then, you get an error saying the password is incorrect, and 
a new, normal password prompt appears.  Enter the password, and this time, 
it is not visible.

This is what it looks like:

----------------------------
andyt at king: andyt> scp -3 andyt2 at majesty:/etc/group andyt2 at mate:/tmp/group
andyt2 at majesty's password: andyt2 at mate's password:


Permission denied, please try again.
andyt2 at mate's password:
----------------------------

I imagine a similar problem may exist if a user is prompted for a 
passphrase.

System info:

All three systems run Slackware ver. 14.0, openssh-6.4.

Please let me know if further clarification or test runs are needed.

Regards,

Andy

Dr Andy Tsouladze
Sr Unix/Storage/Security SysAdmin
PWD=`cat /dev/urandom | sed 's/[^\x21-\x7f]//g' | head -c 14`

From dtucker at zip.com.au  Mon Jan 20 16:49:19 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 20 Jan 2014 16:49:19 +1100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.11.1401192148480.4801@natsu.mindrot.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52DB1C61.9070701@gmail.com>
 <CAHEKYV4FLE=gGf-G_JtMi8xOnH8XWRnvuctPxaPZcX+s2ESBAw@mail.gmail.com>
 <alpine.BSO.2.11.1401192148480.4801@natsu.mindrot.org>
Message-ID: <CALDDTe3fcFu6ctND+HK5m5OxX=cswf+sVUHiac=jyVwKvt=quA@mail.gmail.com>

On Sun, Jan 19, 2014 at 9:50 PM, Damien Miller <djm at mindrot.org> wrote:
[...]
> Those lines don't contain the actual error message. There should be a
> failed-regress.log in the regress/ directory that shows the full test
> log and failure. The one of failed-ssh.log and failed-sshd.log files
> might also contain some clues.

run test cert-hostkey.sh ...
certified host keys: sign host rsa cert
certified host keys: sign host rsa_v00 cert
certified host keys: sign host dsa cert
certified host keys: sign host dsa_v00 cert
certified host keys: sign host ed25519 cert
certified host keys: sign host ecdsa-sha2-nistp256 cert
certified host keys: sign host ecdsa-sha2-nistp384 cert
certified host keys: host rsa cert connect privsep yes
certified host keys: host dsa cert connect privsep yes
certified host keys: host ed25519 cert connect privsep yes
certified host keys: host ecdsa-sha2-nistp256 cert connect privsep yes
certified host keys: host ecdsa-sha2-nistp384 cert connect privsep yes
certified host keys: host rsa_v00 cert connect privsep yes
certified host keys: host dsa_v00 cert connect privsep yes
certified host keys: host rsa cert connect privsep no
certified host keys: host dsa cert connect privsep no
certified host keys: host ed25519 cert connect privsep no
certified host keys: host ecdsa-sha2-nistp256 cert connect privsep no
certified host keys: host ecdsa-sha2-nistp384 cert connect privsep no
certified host keys: host rsa_v00 cert connect privsep no
certified host keys: host dsa_v00 cert connect privsep no
cat: /root/openssh/regress/cert_host_key_ecdsa-sha2-nistp521.pub: No
such file or directory
certified host keys: host rsa revoked cert privsep yes
certified host keys: host dsa revoked cert privsep yes
certified host keys: host ed25519 revoked cert privsep yes
ssh cert connect succeeded unexpectedly
certified host keys: host ecdsa-sha2-nistp256 revoked cert privsep yes
certified host keys: host ecdsa-sha2-nistp384 revoked cert privsep yes
certified host keys: host rsa_v00 revoked cert privsep yes
certified host keys: host dsa_v00 revoked cert privsep yes
certified host keys: host rsa revoked cert privsep no
certified host keys: host dsa revoked cert privsep no
certified host keys: host ed25519 revoked cert privsep no
ssh cert connect succeeded unexpectedly
certified host keys: host ecdsa-sha2-nistp256 revoked cert privsep no
certified host keys: host ecdsa-sha2-nistp384 revoked cert privsep no
certified host keys: host rsa_v00 revoked cert privsep no
certified host keys: host dsa_v00 revoked cert privsep no
certified host keys: host rsa revoked cert
certified host keys: host dsa revoked cert
certified host keys: host ed25519 revoked cert
certified host keys: host ecdsa-sha2-nistp256 revoked cert
certified host keys: host ecdsa-sha2-nistp384 revoked cert
certified host keys: host rsa_v00 revoked cert
certified host keys: host dsa_v00 revoked cert
certified host keys: host cert connect user-certificate rsa expect failure
certified host keys: host cert connect user-certificate rsa_v00 expect failure
certified host keys: host cert connect empty principals rsa expect success
certified host keys: host cert connect empty principals rsa_v00 expect success
certified host keys: host cert connect wrong principals rsa expect failure
certified host keys: host cert connect wrong principals rsa_v00 expect failure
certified host keys: host cert connect cert not yet valid rsa expect failure
certified host keys: host cert connect cert not yet valid rsa_v00 expect failure
certified host keys: host cert connect cert expired rsa expect failure
certified host keys: host cert connect cert expired rsa_v00 expect failure
certified host keys: host cert connect cert valid interval rsa expect success
certified host keys: host cert connect cert valid interval rsa_v00
expect success
certified host keys: host cert connect cert has constraints rsa expect failure
certified host keys: host cert connect cert has constraints rsa_v00
expect failure
certified host keys: host rsa v01 cert downgrade to raw key
certified host keys: host dsa v01 cert downgrade to raw key
certified host keys: host rsa v00 cert downgrade to raw key
certified host keys: host dsa v00 cert downgrade to raw key
certified host keys: host rsa connect wrong cert
certified host keys: host dsa connect wrong cert
certified host keys: host rsa connect wrong cert
certified host keys: host dsa connect wrong cert
failed certified host keys
make[1]: *** [t-exec] Error 1
make[1]: Leaving directory `/root/openssh/regress'
make: *** [tests] Error 2

I suspect that is is at least partly related to the fact that redhat
don't implement NID_secp521r1
(https://bugzilla.redhat.com/show_bug.cgi?id=1019256)

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

From djm at mindrot.org  Mon Jan 20 17:01:20 2014
From: djm at mindrot.org (Damien Miller)
Date: Mon, 20 Jan 2014 17:01:20 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <CALDDTe3fcFu6ctND+HK5m5OxX=cswf+sVUHiac=jyVwKvt=quA@mail.gmail.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52DB1C61.9070701@gmail.com>
 <CAHEKYV4FLE=gGf-G_JtMi8xOnH8XWRnvuctPxaPZcX+s2ESBAw@mail.gmail.com>
 <alpine.BSO.2.11.1401192148480.4801@natsu.mindrot.org>
 <CALDDTe3fcFu6ctND+HK5m5OxX=cswf+sVUHiac=jyVwKvt=quA@mail.gmail.com>
Message-ID: <alpine.BSO.2.11.1401201700330.4801@natsu.mindrot.org>

On Mon, 20 Jan 2014, Darren Tucker wrote:

> cat: /root/openssh/regress/cert_host_key_ecdsa-sha2-nistp521.pub: No
> such file or directory
> certified host keys: host rsa revoked cert privsep yes
> certified host keys: host dsa revoked cert privsep yes
> certified host keys: host ed25519 revoked cert privsep yes
> ssh cert connect succeeded unexpectedly

Does this help? (my centos 6.5 is still installing)

Index: regress/cert-hostkey.sh
===================================================================
RCS file: /var/cvs/openssh/regress/cert-hostkey.sh,v
retrieving revision 1.15
diff -u -p -r1.15 cert-hostkey.sh
--- regress/cert-hostkey.sh	7 Dec 2013 06:07:16 -0000	1.15
+++ regress/cert-hostkey.sh	20 Jan 2014 06:00:39 -0000
@@ -72,32 +72,10 @@ done
 	printf '@cert-authority '
 	printf "$HOSTS "
 	cat $OBJ/host_ca_key.pub
-	printf '@revoked '
-	printf "* "
-	cat $OBJ/cert_host_key_rsa.pub
-	if test "x$TEST_SSH_ECC" = "xyes"; then
-		printf '@revoked '
-		printf "* "
-		cat $OBJ/cert_host_key_ecdsa-sha2-nistp256.pub
-		printf '@revoked '
-		printf "* "
-		cat $OBJ/cert_host_key_ecdsa-sha2-nistp384.pub
-		printf '@revoked '
-		printf "* "
-		cat $OBJ/cert_host_key_ecdsa-sha2-nistp521.pub
-	fi
-	printf '@revoked '
-	printf "* "
-	cat $OBJ/cert_host_key_ed25519.pub
-	printf '@revoked '
-	printf "* "
-	cat $OBJ/cert_host_key_dsa.pub
-	printf '@revoked '
-	printf "* "
-	cat $OBJ/cert_host_key_rsa_v00.pub
-	printf '@revoked '
-	printf "* "
-	cat $OBJ/cert_host_key_dsa_v00.pub
+	for ktype in $PLAIN_TYPES rsa_v00 dsa_v00; do
+		test -f "$OBJ/cert_host_key_${ktype}.pub" || fatal "no pubkey"
+		printf "@revoked * `cat $OBJ/cert_host_key_${ktype}.pub`\n"
+	done
 ) > $OBJ/known_hosts-cert
 for privsep in yes no ; do
 	for ktype in $PLAIN_TYPES rsa_v00 dsa_v00; do 

From plautrba at redhat.com  Wed Jan 22 03:14:03 2014
From: plautrba at redhat.com (Petr Lautrbach)
Date: Tue, 21 Jan 2014 17:14:03 +0100
Subject: 3des cipher and DH group size
Message-ID: <52DE9CCB.5070505@redhat.com>

Hello everybody,

An issue was reported in RH bugzilla [1] about the size of the used DH
group  when combined with the 3des-cbc cipher. OpenSSH uses the
actual key length for the size estimation. This is probably fine as far
as the cipher has the same number of bits of security as the key
length. But this is not true for 3TDEA where the key size is 168 resp
192 but it's security is only 112.

Given that the key size in openssh is set to 192, DH group size is
estimated to 7680. But according to NIST SP 800-57, the size of DH key
should be 2048 so openssh doesn't follow that  and it might cause
problems with key exchanges with some servers.

Would it make sense to extend the Cipher struct with the bits for
security and estimate  the DH size from this value? Or do
special handling just of 3des?

What do you think?

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1053107

Thanks,

Petr
-- 
Petr Lautrbach
Security Technologies
Red Hat

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com.

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

From max at lausarve.se  Wed Jan 22 05:02:46 2014
From: max at lausarve.se (Max Thoursie)
Date: Tue, 21 Jan 2014 19:02:46 +0100
Subject: Keys from -i should have precedence over agent keys
Message-ID: <CACVHtEg0RLYLgHimEJH_Tr5Esx4L9RQgOnq2GW7RXaROASQH6A@mail.gmail.com>

Hi,

I believe it would make more sense if,
when specifying a key with -i, that key (or keys) should be tried prior to
the keys in the agent.

Otherwise, if I have many keys in my agent, the server will kick me out. I
can see no situation where one would like to use agent keys instead of the
ones explicitly stated.

Do you agree?

The workaround is of course to set the IdentitiesOnly option.

Best regards
(off list, please include me in reply)
-- 
Max Thoursie

From djm at mindrot.org  Wed Jan 22 07:56:42 2014
From: djm at mindrot.org (Damien Miller)
Date: Wed, 22 Jan 2014 07:56:42 +1100 (EST)
Subject: Keys from -i should have precedence over agent keys
In-Reply-To: <CACVHtEg0RLYLgHimEJH_Tr5Esx4L9RQgOnq2GW7RXaROASQH6A@mail.gmail.com>
References: <CACVHtEg0RLYLgHimEJH_Tr5Esx4L9RQgOnq2GW7RXaROASQH6A@mail.gmail.com>
Message-ID: <alpine.BSO.2.11.1401220755530.19533@natsu.mindrot.org>

On Tue, 21 Jan 2014, Max Thoursie wrote:

> Hi,
> 
> I believe it would make more sense if,
> when specifying a key with -i, that key (or keys) should be tried prior to
> the keys in the agent.
> 
> Otherwise, if I have many keys in my agent, the server will kick me out. I
> can see no situation where one would like to use agent keys instead of the
> ones explicitly stated.
> 
> Do you agree?

Yes, and that is what the code is supposed to do already. See
sshconnect2.c:pubkey_prepare()

-d

From kevin.brott at gmail.com  Wed Jan 22 11:51:38 2014
From: kevin.brott at gmail.com (Kevin Brott)
Date: Tue, 21 Jan 2014 16:51:38 -0800
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <52DB1C61.9070701@gmail.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52DB1C61.9070701@gmail.com>
Message-ID: <CAMv58rbbz9fGoOQvNBVHdWgrB5x7Pp9XV2ZALkk5E8b3RpRHpA@mail.gmail.com>

On-call this week so it's going slow - but felt I should report on the
build failure I found:

Using http://www.mindrot.org/openssh_snap/openssh-SNAP-20140122.tar.gz

OS              Build_Target                CC
OpenSSL      BUILD TEST
==============  =========================== ================
============ ===== =================
RHEL 2.1        i686-pc-linux-gnu           gcc 2.96-129.7.2
0.9.6b-eng   OK    all tests passed
RHEL 3 TU4      i686-pc-linux-gnu           gcc 3.2.3-47
0.9.7a       FAIL*2
Fedora Core r2  i686-pc-linux-gnu           gcc 3.3.3-7
0.9.7a       OK*1  all tests passed
RHEL 4.0 nu8    i686-pc-linux-gnu           gcc 3.4.6-11
0.9.7a       OK*1  all tests passed
RHEL 4.0 nu8    x86_64-unknown-linux-gnu    gcc 3.4.6-11
0.9.7a       OK*1  all tests passed

# RHL     Red Hat Linux
# RHEL    Red Hat Enterprise Linux

# *1 --without-zlib-version-check
# *2 build failure:
  gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare
-Wformat-security -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv
-fno-builtin-memset -std=gnu99 -fPIE  -I. -I.. -I. -I./..  -DHAVE_CONFIG_H
-c setproctitle.c
  setproctitle.c: In function `compat_init_setproctitle':
  setproctitle.c:99: warning: implicit declaration of function `strlen'
  setproctitle.c:107: `argv_start' undeclared (first use in this function)
  setproctitle.c:107: (Each undeclared identifier is reported only once
  setproctitle.c:107: for each function it appears in.)
  setproctitle.c:108: `argv_env_len' undeclared (first use in this function)
  setproctitle.c:115: warning: implicit declaration of function `strdup'
  setproctitle.c:115: warning: assignment makes pointer from integer
without a cast
  make[1]: *** [setproctitle.o] Error 1
  make[1]: Leaving directory `/usr/src/openssh/openbsd-compat'
  make: *** [openbsd-compat/libopenbsd-compat.a] Error 2
  ##
  ## OPENSSH 6.4p1 builds/tests fine
  ##




On Sat, Jan 18, 2014 at 4:29 PM, Kevin Brott <kevin.brott at gmail.com> wrote:

> On 2014-01-16 16:26, Damien Miller wrote:
>
>> Hi,
>>
>> OpenSSH 6.5 is almost ready for release, so we would appreciate testing
>> on as many platforms and systems as possible. This release contains
>> some substantial new features and a number of bugfixes.
>>
>> Snapshot releases for portable OpenSSH are available from
>> http://www.mindrot.org/openssh_snap/
>>
>> The OpenBSD version is available in CVS HEAD:
>> http://www.openbsd.org/anoncvs.html
>>
>> Portable OpenSSH is also available via anonymous CVS using the
>> instructions at http://www.openssh.com/portable.html#cvs or
>> via Mercurial at http://hg.mindrot.org/openssh
>>
>> Running the regression tests supplied with Portable OpenSSH does not
>> require installation and is a simply:
>>
>> $ ./configure && make tests
>>
>>
>>
> Using openssh-SNAP-20140119.tar.gz:
> Debian GNU/Linux 7.3 (wheezy) x86_64, gcc (Debian 4.7.2-5) , and OpenSSL
> 1.0.1e 11 - all tests passed
>
> Full test suite (RHEL/AIX/HP-UX/maybe Solaris) will get cranked up in the
> lab at work come Monday. :)
>
>
>
>
>


-- 
# include <stddisclaimer.h>
/* Kevin  Brott <Kevin.Brott at gmail.com> */

From djm at mindrot.org  Wed Jan 22 12:10:28 2014
From: djm at mindrot.org (Damien Miller)
Date: Wed, 22 Jan 2014 12:10:28 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <CAMv58rbbz9fGoOQvNBVHdWgrB5x7Pp9XV2ZALkk5E8b3RpRHpA@mail.gmail.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52DB1C61.9070701@gmail.com>
 <CAMv58rbbz9fGoOQvNBVHdWgrB5x7Pp9XV2ZALkk5E8b3RpRHpA@mail.gmail.com>
Message-ID: <alpine.BSO.2.11.1401221209170.14832@natsu.mindrot.org>

On Tue, 21 Jan 2014, Kevin Brott wrote:

> On-call this week so it's going slow - but felt I should report on the build
> failure I found:

thanks again for testing.

>   gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare
> -Wformat-security -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv
> -fno-builtin-memset -std=gnu99 -fPIE  -I. -I.. -I. -I./..  -DHAVE_CONFIG_H
> -c setproctitle.c
>   setproctitle.c: In function `compat_init_setproctitle':
>   setproctitle.c:99: warning: implicit declaration of function `strlen'
>   setproctitle.c:107: `argv_start' undeclared (first use in this function)
>   setproctitle.c:107: (Each undeclared identifier is reported only once
>   setproctitle.c:107: for each function it appears in.)
>   setproctitle.c:108: `argv_env_len' undeclared (first use in this function)
>   setproctitle.c:115: warning: implicit declaration of function `strdup'
>   setproctitle.c:115: warning: assignment makes pointer from integer without
> a cast
>   make[1]: *** [setproctitle.o] Error 1
>   make[1]: Leaving directory `/usr/src/openssh/openbsd-compat'
>   make: *** [openbsd-compat/libopenbsd-compat.a] Error 2

Could you send the output of "grep SPT_ config.h" for this one?

Thanks,
Damien

From raubvogel at gmail.com  Wed Jan 22 16:21:03 2014
From: raubvogel at gmail.com (Mauricio Tavares)
Date: Wed, 22 Jan 2014 00:21:03 -0500
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.11.1401192148480.4801@natsu.mindrot.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52DB1C61.9070701@gmail.com>
 <CAHEKYV4FLE=gGf-G_JtMi8xOnH8XWRnvuctPxaPZcX+s2ESBAw@mail.gmail.com>
 <alpine.BSO.2.11.1401192148480.4801@natsu.mindrot.org>
Message-ID: <CAHEKYV6i7royX2bqgCJU_FccjTJ4PmCP0dzp9FK02=2EnJEG-g@mail.gmail.com>

On Sun, Jan 19, 2014 at 5:50 AM, Damien Miller <djm at mindrot.org> wrote:
> On Sun, 19 Jan 2014, Mauricio Tavares wrote:
>
>>       Ran 20140119 snapshot tests on Ubuntu 12.04.4 LTS x64; had to
>> create /var/empty but after that all test passed. Also compiled and
>> ran the same tests on CentOS 6.5 x64. And got the following:
>>
>> [...]
>> certified host keys: host rsa connect wrong cert
>> certified host keys: host dsa connect wrong cert
>> certified host keys: host rsa connect wrong cert
>> certified host keys: host dsa connect wrong cert
>> failed certified host keys
>> make[1]: *** [t-exec] Error 1
>> make[1]: Leaving directory `/home/raub/dev/openssh/regress'
>> make: *** [tests] Error 2
>> [raub at devcentos openssh]$
>>
>> Anything I should worry about? Or are they related to
>> openssl/something else?
>
> Those lines don't contain the actual error message. There should be a
> failed-regress.log in the regress/ directory that shows the full test
> log and failure. The one of failed-ssh.log and failed-sshd.log files
> might also contain some clues.
>
> -d

      Oops! Shame on me! So, this is what I am getting in the
failed-regress file:

[dalek at devcentos openssh]$ cat regress/failed-regress.log
trace: certified host keys: host ed25519 revoked cert privsep yes
FAIL: ssh cert connect succeeded unexpectedly

trace: certified host keys: host ed25519 revoked cert privsep no
FAIL: ssh cert connect succeeded unexpectedly

[dalek at devcentos openssh]$

I am seeing more details on this in the failed_ssh* files, but I
honestly do not know what I am looking for. Would you want the two
files? They are around 300 lines each.

      Now, while I was out, I also got my Mac mini g4 running OSX
10.5.something-or-another and stock Xcode 3.1.1 and ran tests in it.
And it worked.

From djm at mindrot.org  Wed Jan 22 16:38:34 2014
From: djm at mindrot.org (Damien Miller)
Date: Wed, 22 Jan 2014 16:38:34 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.11.1401221209170.14832@natsu.mindrot.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52DB1C61.9070701@gmail.com>
 <CAMv58rbbz9fGoOQvNBVHdWgrB5x7Pp9XV2ZALkk5E8b3RpRHpA@mail.gmail.com>
 <alpine.BSO.2.11.1401221209170.14832@natsu.mindrot.org>
Message-ID: <alpine.BSO.2.11.1401221637520.14832@natsu.mindrot.org>

On Wed, 22 Jan 2014, Damien Miller wrote:

> On Tue, 21 Jan 2014, Kevin Brott wrote:
> 
> >   gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare
> > -Wformat-security -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv
> > -fno-builtin-memset -std=gnu99 -fPIE  -I. -I.. -I. -I./..  -DHAVE_CONFIG_H
> > -c setproctitle.c
> >   setproctitle.c: In function `compat_init_setproctitle':
> >   setproctitle.c:99: warning: implicit declaration of function `strlen'
> >   setproctitle.c:107: `argv_start' undeclared (first use in this function)
> >   setproctitle.c:107: (Each undeclared identifier is reported only once
> >   setproctitle.c:107: for each function it appears in.)
> >   setproctitle.c:108: `argv_env_len' undeclared (first use in this function)
> >   setproctitle.c:115: warning: implicit declaration of function `strdup'
> >   setproctitle.c:115: warning: assignment makes pointer from integer without
> > a cast
> >   make[1]: *** [setproctitle.o] Error 1
> >   make[1]: Leaving directory `/usr/src/openssh/openbsd-compat'
> >   make: *** [openbsd-compat/libopenbsd-compat.a] Error 2
> 
> Could you send the output of "grep SPT_ config.h" for this one?

Don't worry - I installed CentOS 3.4 and was able to reproduce and fix
this. It was fallout from the toolchain hardening options that we are
turning on by default now.

-d

From dtucker at zip.com.au  Wed Jan 22 17:04:45 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 22 Jan 2014 17:04:45 +1100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <CAHEKYV6i7royX2bqgCJU_FccjTJ4PmCP0dzp9FK02=2EnJEG-g@mail.gmail.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52DB1C61.9070701@gmail.com>
 <CAHEKYV4FLE=gGf-G_JtMi8xOnH8XWRnvuctPxaPZcX+s2ESBAw@mail.gmail.com>
 <alpine.BSO.2.11.1401192148480.4801@natsu.mindrot.org>
 <CAHEKYV6i7royX2bqgCJU_FccjTJ4PmCP0dzp9FK02=2EnJEG-g@mail.gmail.com>
Message-ID: <CALDDTe2eD2KRw1GjZ39tb-YmhqeFDz4nCa1dhu7HqfCBmnwTJg@mail.gmail.com>

On Wed, Jan 22, 2014 at 4:21 PM, Mauricio Tavares <raubvogel at gmail.com> wrote:
[...]
> [dalek at devcentos openssh]$ cat regress/failed-regress.log
> trace: certified host keys: host ed25519 revoked cert privsep yes
> FAIL: ssh cert connect succeeded unexpectedly
> trace: certified host keys: host ed25519 revoked cert privsep no
> FAIL: ssh cert connect succeeded unexpectedly

this one was due to redhat not supporting the NID_secp521r1 algorithm.
This caused a test failure, but that failure also corrupted the setup
for the following line a

Damien fixed it:
https://anongit.mindrot.org/openssh.git/commit/?id=f9df7f6f477792254eab33cdef71a6d66488cb88

and the next snapshot (or possibly even the current one) should be good.

> Would you want the two files? They are around 300 lines each.

only if a snapshot built after that change above still shows a problem

-- 
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  Wed Jan 22 23:25:28 2014
From: djm at mindrot.org (Damien Miller)
Date: Wed, 22 Jan 2014 23:25:28 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.11.1401221637520.14832@natsu.mindrot.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52DB1C61.9070701@gmail.com>
 <CAMv58rbbz9fGoOQvNBVHdWgrB5x7Pp9XV2ZALkk5E8b3RpRHpA@mail.gmail.com>
 <alpine.BSO.2.11.1401221209170.14832@natsu.mindrot.org>
 <alpine.BSO.2.11.1401221637520.14832@natsu.mindrot.org>
Message-ID: <alpine.BSO.2.11.1401222324380.21543@natsu.mindrot.org>

On Wed, 22 Jan 2014, Damien Miller wrote:

> Don't worry - I installed CentOS 3.4 and was able to reproduce and fix
> this. It was fallout from the toolchain hardening options that we are
> turning on by default now.

CVS/git head and the 20140123 snapshot (due in ~1 hour) have the fixes for
this.

-d

From max at lausarve.se  Thu Jan 23 00:16:43 2014
From: max at lausarve.se (Max Thoursie)
Date: Wed, 22 Jan 2014 14:16:43 +0100
Subject: Keys from -i should have precedence over agent keys
In-Reply-To: <alpine.BSO.2.11.1401220755530.19533@natsu.mindrot.org>
References: <CACVHtEg0RLYLgHimEJH_Tr5Esx4L9RQgOnq2GW7RXaROASQH6A@mail.gmail.com>
 <alpine.BSO.2.11.1401220755530.19533@natsu.mindrot.org>
Message-ID: <CACVHtEhKAc=6+W4HwQ569hX1noH+pJJxVJ1JPO7Pp2uahcYL1A@mail.gmail.com>

On Tue, Jan 21, 2014 at 9:56 PM, Damien Miller <djm at mindrot.org> wrote:

> On Tue, 21 Jan 2014, Max Thoursie wrote:
>
> > Hi,
> >
> > I believe it would make more sense if,
> > when specifying a key with -i, that key (or keys) should be tried prior
> to
> > the keys in the agent.
> >
> > Otherwise, if I have many keys in my agent, the server will kick me out.
> I
> > can see no situation where one would like to use agent keys instead of
> the
> > ones explicitly stated.
> >
> > Do you agree?
>
> Yes, and that is what the code is supposed to do already. See
> sshconnect2.c:pubkey_prepare()


Only if I have the key specified in my agent. But keys from the command
line, not present in the agent, will be tried last. And I object that.

>From the comment in pubkey_prepare:

  try keys in the following order:
1. agent keys that are found in the config file
2. other agent keys
3. keys that are only listed in the config file

I think it would make more sense to do 1,3,2.

The reason beeing that in config, or in the command line, you can tie a
specific key to a specific host, which you can't do in the agent. So given
that you have more keys than tries on the remote servers, you could then
solve that situation by providing a host specific config.

From gturner at unzane.com  Thu Jan 23 08:54:28 2014
From: gturner at unzane.com (Gerald Turner)
Date: Wed, 22 Jan 2014 13:54:28 -0800
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.03.1401141556410.3003@mindrot.org> (Damien Miller's
 message of "Fri, 17 Jan 2014 11:26:47 +1100 (EST)")
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
Message-ID: <87a9enlm23.fsf@zoth-ommog.unzane.com>

Damien Miller <djm at mindrot.org> writes:
> Running the regression tests supplied with Portable OpenSSH does not
> require installation and is a simply:
>
> $ ./configure && make tests

Tested openssh-SNAP-20140123 on Debian jessie/testing amd64 with OpenSSL
1.0.1f on two machines (one with AES-NI instructions), all tests passed
and no warnings.

>  * ssh(1), sshd(8): Add support for Ed25519 as a public key type.
>    Ed25519 is a elliptic curve signature scheme that offers
>    better security than ECDSA and DSA and good performance. It may be
>    used for both user and host keys.

Is there SSHFP support for Ed25519?  I suppose not - looks like it would
need Internet Drafts equivalent to RFC6090 (ECDSA) and RFC6594 (SSHFP).
Currently Curve25519 has an I-D but not for Ed25519:

http://datatracker.ietf.org/doc/draft-josefsson-tls-curve25519/

  ?This document only describes usage of additional curves for ephemeral
   key exchange (ECDHE), not for use with long-term keys embedded in
   PKIX certificates (ECDH_RSA and ECDH_ECDSA).  This is because
   Curve25519 is not directly suitable for authentication with ECDSA,
   and thus not applicable for signing of e.g.  PKIX certificates.?

-- 
Gerald Turner   Email: gturner at unzane.com   JID: gturner at unzane.com
GPG: 0xFA8CD6D5  21D9 B2E8 7FE7 F19E 5F7D  4D0C 3FA0 810F FA8C D6D5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20140122/65201d70/attachment.bin>

From htodd at twofifty.com  Thu Jan 23 10:12:55 2014
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Wed, 22 Jan 2014 15:12:55 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
Message-ID: <alpine.NEB.2.11.1401221509590.330@chris.i8u.org>

On NetBSD amd64-current with a git pull on 1/22 at about 2300GMT:

(cd openbsd-compat && make)
BUILDDIR=`pwd`;  TEST_SHELL="sh";  TEST_SSH_SSH="${BUILDDIR}/ssh";  TEST_SSH_SSHD="${BUILDDIR}/sshd";  TEST_SSH_SSHAGENT="${BUILDDIR}/ssh-agent";  TEST_SSH_SSHADD="${BUILDDIR}/ssh-add";  TEST_SSH_SSHKEYGEN="${BUILDDIR}/ssh-keygen";  TEST_SSH_SSHPKCS11HELPER="${BUILDDIR}/ssh-pkcs11-helper";  TEST_SSH_SSHKEYSCAN="${BUILDDIR}/ssh-keyscan";  TEST_SSH_SFTP="${BUILDDIR}/sftp";  TEST_SSH_SFTPSERVER="${BUILDDIR}/sftp-server";  TEST_SSH_PLINK="plink";  TEST_SSH_PUTTYGEN="puttygen";  TEST_SSH_CONCH="conch";  TEST_SSH_IPV6="yes" ;  TEST_SSH_ECC="yes" ;  cd ./regress || exit $?;  make  .OBJDIR="${BUILDDIR}/regress"  .CURDIR="`pwd`"  BUILDDIR="${BUILDDIR}"  OBJ="${BUILDDIR}/regress/"  PATH="${BUILDDIR}:${PATH}"  TEST_ENV=MALLOC_OPTIONS="AJRX"  TEST_SHELL="${TEST_SHELL}"  TEST_SSH_SSH="${TEST_SSH_SSH}"  TEST_SSH_SSHD="${TEST_SSH_SSHD}"  TEST_SSH_SSHAGENT="${TEST_SSH_SSHAGENT}"  TEST_SSH_SSHADD="${TEST_SSH_SSHADD}"  TEST_SSH_SSHKEYGEN="${TEST_SSH_SSHKEYGEN}"  TEST_SSH_SSHPKCS11HELPER="${TES
 T_SSH_SSHPKCS11HELPER}"  TEST_SSH_SSHKEYSCAN="${TEST_SSH_SSHKEYSCAN}"  TEST_SSH_SFTP="${TEST_SSH_SFTP}"  TEST_SSH_SFTPSERVER="${TEST_SSH_SFTPSERVER}"  TEST_SSH_PLINK="${TEST_SSH_PLINK}"  TEST_SSH_PUTTYGEN="${TEST_SSH_PUTTYGEN}"  TEST_SSH_CONCH="${TEST_SSH_CONCH}"  TEST_SSH_IPV6="${TEST_SSH_IPV6}"  TEST_SSH_ECC="${TEST_SSH_ECC}"  EXEEXT=""  tests && echo all tests passed
/home/htodd/openssh/ssh-keygen -if /home/htodd/openssh/regress/rsa_ssh2.prv | diff - /home/htodd/openssh/regress/rsa_openssh.prv
tr '\n' '\r' </home/htodd/openssh/regress/rsa_ssh2.prv > /home/htodd/openssh/regress/rsa_ssh2_cr.prv
/home/htodd/openssh/ssh-keygen -if /home/htodd/openssh/regress/rsa_ssh2_cr.prv | diff - /home/htodd/openssh/regress/rsa_openssh.prv
awk '{print $0 "\r"}' /home/htodd/openssh/regress/rsa_ssh2.prv > /home/htodd/openssh/regress/rsa_ssh2_crnl.prv
/home/htodd/openssh/ssh-keygen -if /home/htodd/openssh/regress/rsa_ssh2_crnl.prv | diff - /home/htodd/openssh/regress/rsa_openssh.prv
cat /home/htodd/openssh/regress/rsa_openssh.prv > /home/htodd/openssh/regress//t2.out
chmod 600 /home/htodd/openssh/regress//t2.out
/home/htodd/openssh/ssh-keygen -yf /home/htodd/openssh/regress//t2.out | diff - /home/htodd/openssh/regress/rsa_openssh.pub
/home/htodd/openssh/ssh-keygen -ef /home/htodd/openssh/regress/rsa_openssh.pub >/home/htodd/openssh/regress//t3.out
/home/htodd/openssh/ssh-keygen -if /home/htodd/openssh/regress//t3.out | diff - /home/htodd/openssh/regress/rsa_openssh.pub
/home/htodd/openssh/ssh-keygen -lf /home/htodd/openssh/regress/rsa_openssh.pub | awk '{print $2}' | diff - /home/htodd/openssh/regress/t4.ok
/home/htodd/openssh/ssh-keygen -Bf /home/htodd/openssh/regress/rsa_openssh.pub | awk '{print $2}' | diff - /home/htodd/openssh/regress/t5.ok
/home/htodd/openssh/ssh-keygen -if /home/htodd/openssh/regress/dsa_ssh2.prv > /home/htodd/openssh/regress//t6.out1
/home/htodd/openssh/ssh-keygen -if /home/htodd/openssh/regress/dsa_ssh2.pub > /home/htodd/openssh/regress//t6.out2
chmod 600 /home/htodd/openssh/regress//t6.out1
/home/htodd/openssh/ssh-keygen -yf /home/htodd/openssh/regress//t6.out1 | diff - /home/htodd/openssh/regress//t6.out2
/home/htodd/openssh/ssh-keygen -lf /home/htodd/openssh/regress//t7.out > /dev/null
/home/htodd/openssh/ssh-keygen -Bf /home/htodd/openssh/regress//t7.out > /dev/null
/home/htodd/openssh/ssh-keygen -lf /home/htodd/openssh/regress//t8.out > /dev/null
/home/htodd/openssh/ssh-keygen -Bf /home/htodd/openssh/regress//t8.out > /dev/null
test "yes" != yes ||  /home/htodd/openssh/ssh-keygen -lf /home/htodd/openssh/regress//t9.out > /dev/null
test "yes" != yes ||  /home/htodd/openssh/ssh-keygen -Bf /home/htodd/openssh/regress//t9.out > /dev/null
/home/htodd/openssh/ssh-keygen -lf /home/htodd/openssh/regress//t10.out > /dev/null
/home/htodd/openssh/ssh-keygen -Bf /home/htodd/openssh/regress//t10.out > /dev/null
FATAL: sshd_proxy broken
*** Error code 1

Stop.
make[1]: stopped in /home/htodd/openssh/regress
*** Error code 1

Stop.
make: stopped in /home/htodd/openssh

-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

From dtucker at zip.com.au  Thu Jan 23 10:17:55 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 23 Jan 2014 10:17:55 +1100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.NEB.2.11.1401221509590.330@chris.i8u.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <alpine.NEB.2.11.1401221509590.330@chris.i8u.org>
Message-ID: <CALDDTe38x1aLoFKB1AvbkEU65ueD3cWB5Jv-_Dhas29=x75f3g@mail.gmail.com>

On Thu, Jan 23, 2014 at 10:12 AM, Hisashi T Fujinaka <htodd at twofifty.com> wrote:
> On NetBSD amd64-current with a git pull on 1/22 at about 2300GMT:
[...]

The test framework should have created the files failed-sshd.log and
failed-ssh.log and failed-regress.log containing the output of the
failing test.

The problem is most likely in failed-sshd.log.  If it's not obvious,
please post all three.

-- 
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 htodd at twofifty.com  Thu Jan 23 10:27:44 2014
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Wed, 22 Jan 2014 15:27:44 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <CALDDTe38x1aLoFKB1AvbkEU65ueD3cWB5Jv-_Dhas29=x75f3g@mail.gmail.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <alpine.NEB.2.11.1401221509590.330@chris.i8u.org>
 <CALDDTe38x1aLoFKB1AvbkEU65ueD3cWB5Jv-_Dhas29=x75f3g@mail.gmail.com>
Message-ID: <alpine.NEB.2.11.1401221526120.330@chris.i8u.org>

> On Thu, Jan 23, 2014 at 10:12 AM, Hisashi T Fujinaka <htodd at twofifty.com> wrote:
>> On NetBSD amd64-current with a git pull on 1/22 at about 2300GMT:
> [...]
>
> The test framework should have created the files failed-sshd.log and
> failed-ssh.log and failed-regress.log containing the output of the
> failing test.
>
> The problem is most likely in failed-sshd.log.  If it's not obvious,
> please post all three.

diff3 (if I did it right) shows the same in all three files:
trace: generate keys
FATAL: sshd_proxy broken

trace: generate keys
FATAL: sshd_proxy broken
FAIL: sshd_proxy broken

trace: generate keys
FATAL: sshd_proxy broken

trace: generate keys
FATAL: sshd_proxy broken
FAIL: sshd_proxy broken


-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

From dtucker at zip.com.au  Thu Jan 23 10:38:09 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 23 Jan 2014 10:38:09 +1100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.NEB.2.11.1401221526120.330@chris.i8u.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <alpine.NEB.2.11.1401221509590.330@chris.i8u.org>
 <CALDDTe38x1aLoFKB1AvbkEU65ueD3cWB5Jv-_Dhas29=x75f3g@mail.gmail.com>
 <alpine.NEB.2.11.1401221526120.330@chris.i8u.org>
Message-ID: <CALDDTe2qYO1_haF6VD4=phE7+2AvJ1BS5Za6cpW53KtqN6C2Tw@mail.gmail.com>

On Thu, Jan 23, 2014 at 10:27 AM, Hisashi T Fujinaka <htodd at twofifty.com> wrote:
>> On Thu, Jan 23, 2014 at 10:12 AM, Hisashi T Fujinaka <htodd at twofifty.com>
>> wrote:
>>>
>>> On NetBSD amd64-current with a git pull on 1/22 at about 2300GMT:
>>
>> [...]
>>
>> The test framework should have created the files failed-sshd.log and
>> failed-ssh.log and failed-regress.log containing the output of the
>> failing test.
>>
>> The problem is most likely in failed-sshd.log.  If it's not obvious,
>> please post all three.
>
> diff3 (if I did it right) shows the same in all three files:
> trace: generate keys
> FATAL: sshd_proxy broken

That's not what I was expecting to see.  That's the entire content of
those files?  How big are they?  Also take a look at ssh.log and
sshd.log.

If that doesn't prove helpful the next step is to add "set -x" to the
top of regress/test-exec.sh and rerun the tests.  It'll be somewhat
noisy but might give a clue about what's going on.

-- 
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 htodd at twofifty.com  Thu Jan 23 10:41:10 2014
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Wed, 22 Jan 2014 15:41:10 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <CALDDTe2qYO1_haF6VD4=phE7+2AvJ1BS5Za6cpW53KtqN6C2Tw@mail.gmail.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <alpine.NEB.2.11.1401221509590.330@chris.i8u.org>
 <CALDDTe38x1aLoFKB1AvbkEU65ueD3cWB5Jv-_Dhas29=x75f3g@mail.gmail.com>
 <alpine.NEB.2.11.1401221526120.330@chris.i8u.org>
 <CALDDTe2qYO1_haF6VD4=phE7+2AvJ1BS5Za6cpW53KtqN6C2Tw@mail.gmail.com>
Message-ID: <alpine.NEB.2.11.1401221539450.330@chris.i8u.org>

On Thu, 23 Jan 2014, Darren Tucker wrote:

> On Thu, Jan 23, 2014 at 10:27 AM, Hisashi T Fujinaka <htodd at twofifty.com> wrote:
>>> On Thu, Jan 23, 2014 at 10:12 AM, Hisashi T Fujinaka <htodd at twofifty.com>
>>> wrote:
>>>>
>>>> On NetBSD amd64-current with a git pull on 1/22 at about 2300GMT:
>>>
>>> [...]
>>>
>>> The test framework should have created the files failed-sshd.log and
>>> failed-ssh.log and failed-regress.log containing the output of the
>>> failing test.
>>>
>>> The problem is most likely in failed-sshd.log.  If it's not obvious,
>>> please post all three.
>>
>> diff3 (if I did it right) shows the same in all three files:
>> trace: generate keys
>> FATAL: sshd_proxy broken
>
> That's not what I was expecting to see.  That's the entire content of
> those files?  How big are they?  Also take a look at ssh.log and
> sshd.log.
>
> If that doesn't prove helpful the next step is to add "set -x" to the
> top of regress/test-exec.sh and rerun the tests.  It'll be somewhat
> noisy but might give a clue about what's going on.

ssh.log  and sshd.log are even smaller and only contain:

trace: generate keys
FATAL: sshd_proxy broken
FAIL: sshd_proxy broken

I did re-run the tests after doing a build, so that might be part of it.

-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

From htodd at twofifty.com  Thu Jan 23 10:42:50 2014
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Wed, 22 Jan 2014 15:42:50 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.NEB.2.11.1401221539450.330@chris.i8u.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <alpine.NEB.2.11.1401221509590.330@chris.i8u.org>
 <CALDDTe38x1aLoFKB1AvbkEU65ueD3cWB5Jv-_Dhas29=x75f3g@mail.gmail.com>
 <alpine.NEB.2.11.1401221526120.330@chris.i8u.org>
 <CALDDTe2qYO1_haF6VD4=phE7+2AvJ1BS5Za6cpW53KtqN6C2Tw@mail.gmail.com>
 <alpine.NEB.2.11.1401221539450.330@chris.i8u.org>
Message-ID: <alpine.NEB.2.11.1401221542130.330@chris.i8u.org>

On Wed, 22 Jan 2014, Hisashi T Fujinaka wrote:

> On Thu, 23 Jan 2014, Darren Tucker wrote:
>
>> On Thu, Jan 23, 2014 at 10:27 AM, Hisashi T Fujinaka <htodd at twofifty.com> 
>> wrote:
>>>> On Thu, Jan 23, 2014 at 10:12 AM, Hisashi T Fujinaka <htodd at twofifty.com>
>>>> wrote:
>>>>> 
>>>>> On NetBSD amd64-current with a git pull on 1/22 at about 2300GMT:
>>>> 
>>>> [...]
>>>> 
>>>> The test framework should have created the files failed-sshd.log and
>>>> failed-ssh.log and failed-regress.log containing the output of the
>>>> failing test.
>>>> 
>>>> The problem is most likely in failed-sshd.log.  If it's not obvious,
>>>> please post all three.
>>> 
>>> diff3 (if I did it right) shows the same in all three files:
>>> trace: generate keys
>>> FATAL: sshd_proxy broken
>> 
>> That's not what I was expecting to see.  That's the entire content of
>> those files?  How big are they?  Also take a look at ssh.log and
>> sshd.log.
>> 
>> If that doesn't prove helpful the next step is to add "set -x" to the
>> top of regress/test-exec.sh and rerun the tests.  It'll be somewhat
>> noisy but might give a clue about what's going on.
>
> ssh.log  and sshd.log are even smaller and only contain:
>
> trace: generate keys
> FATAL: sshd_proxy broken
> FAIL: sshd_proxy broken
>
> I did re-run the tests after doing a build, so that might be part of it.

The -x didn't add much interesting, but I did see:
+ /home/htodd/openssh/sshd -t -f '/home/htodd/openssh/regress/sshd_proxy'
[1]   Segmentation fault (core dumped) ${SSHD} -t -f ${...


-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

From dtucker at zip.com.au  Thu Jan 23 10:43:49 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 23 Jan 2014 10:43:49 +1100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.NEB.2.11.1401221539450.330@chris.i8u.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <alpine.NEB.2.11.1401221509590.330@chris.i8u.org>
 <CALDDTe38x1aLoFKB1AvbkEU65ueD3cWB5Jv-_Dhas29=x75f3g@mail.gmail.com>
 <alpine.NEB.2.11.1401221526120.330@chris.i8u.org>
 <CALDDTe2qYO1_haF6VD4=phE7+2AvJ1BS5Za6cpW53KtqN6C2Tw@mail.gmail.com>
 <alpine.NEB.2.11.1401221539450.330@chris.i8u.org>
Message-ID: <CALDDTe2jM48Kn_ovy+cAq2d7Y=p=KjX4n8iv+Rd2c3m_9UaoWA@mail.gmail.com>

On Thu, Jan 23, 2014 at 10:41 AM, Hisashi T Fujinaka <htodd at twofifty.com> wrote:
[...]
> I did re-run the tests after doing a build, so that might be part of it.

That shouldn't make a difference.  I'd suggest trying the set -x thing
described above next.

Also one other simple test see if the binaries are actually
executable: "./ssh -V"

-- 
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 htodd at twofifty.com  Thu Jan 23 10:57:46 2014
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Wed, 22 Jan 2014 15:57:46 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <CALDDTe2jM48Kn_ovy+cAq2d7Y=p=KjX4n8iv+Rd2c3m_9UaoWA@mail.gmail.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <alpine.NEB.2.11.1401221509590.330@chris.i8u.org>
 <CALDDTe38x1aLoFKB1AvbkEU65ueD3cWB5Jv-_Dhas29=x75f3g@mail.gmail.com>
 <alpine.NEB.2.11.1401221526120.330@chris.i8u.org>
 <CALDDTe2qYO1_haF6VD4=phE7+2AvJ1BS5Za6cpW53KtqN6C2Tw@mail.gmail.com>
 <alpine.NEB.2.11.1401221539450.330@chris.i8u.org>
 <CALDDTe2jM48Kn_ovy+cAq2d7Y=p=KjX4n8iv+Rd2c3m_9UaoWA@mail.gmail.com>
Message-ID: <alpine.NEB.2.11.1401221555310.330@chris.i8u.org>

On Thu, 23 Jan 2014, Darren Tucker wrote:

> On Thu, Jan 23, 2014 at 10:41 AM, Hisashi T Fujinaka <htodd at twofifty.com> wrote:
> [...]
>> I did re-run the tests after doing a build, so that might be part of it.
>
> That shouldn't make a difference.  I'd suggest trying the set -x thing
> described above next.
>
> Also one other simple test see if the binaries are actually
> executable: "./ssh -V"

The set -x created a lot of noise on the screen, but even less in the
log files. And ./ssh -V gave "OpenSSH_6.5p1, OpenSSL 1.0.1f 6 Jan 2014".


(cd openbsd-compat && make)
BUILDDIR=`pwd`;  TEST_SHELL="sh";  TEST_SSH_SSH="${BUILDDIR}/ssh";  TEST_SSH_SSHD="${BUILDDIR}/sshd";  TEST_SSH_SSHAGENT="${BUILDDIR}/ssh-agent";  TEST_SSH_SSHADD="${BUILDDIR}/ssh-add";  TEST_SSH_SSHKEYGEN="${BUILDDIR}/ssh-keygen";  TEST_SSH_SSHPKCS11HELPER="${BUILDDIR}/ssh-pkcs11-helper";  TEST_SSH_SSHKEYSCAN="${BUILDDIR}/ssh-keyscan";  TEST_SSH_SFTP="${BUILDDIR}/sftp";  TEST_SSH_SFTPSERVER="${BUILDDIR}/sftp-server";  TEST_SSH_PLINK="plink";  TEST_SSH_PUTTYGEN="puttygen";  TEST_SSH_CONCH="conch";  TEST_SSH_IPV6="yes" ;  TEST_SSH_ECC="yes" ;  cd ./regress || exit $?;  make  .OBJDIR="${BUILDDIR}/regress"  .CURDIR="`pwd`"  BUILDDIR="${BUILDDIR}"  OBJ="${BUILDDIR}/regress/"  PATH="${BUILDDIR}:${PATH}"  TEST_ENV=MALLOC_OPTIONS="AJRX"  TEST_SHELL="${TEST_SHELL}"  TEST_SSH_SSH="${TEST_SSH_SSH}"  TEST_SSH_SSHD="${TEST_SSH_SSHD}"  TEST_SSH_SSHAGENT="${TEST_SSH_SSHAGENT}"  TEST_SSH_SSHADD="${TEST_SSH_SSHADD}"  TEST_SSH_SSHKEYGEN="${TEST_SSH_SSHKEYGEN}"  TEST_SSH_SSHPKCS11HELPER="${TES
 T_SSH_SSHPKCS11HELPER}"  TEST_SSH_SSHKEYSCAN="${TEST_SSH_SSHKEYSCAN}"  TEST_SSH_SFTP="${TEST_SSH_SFTP}"  TEST_SSH_SFTPSERVER="${TEST_SSH_SFTPSERVER}"  TEST_SSH_PLINK="${TEST_SSH_PLINK}"  TEST_SSH_PUTTYGEN="${TEST_SSH_PUTTYGEN}"  TEST_SSH_CONCH="${TEST_SSH_CONCH}"  TEST_SSH_IPV6="${TEST_SSH_IPV6}"  TEST_SSH_ECC="${TEST_SSH_ECC}"  EXEEXT=""  tests && echo all tests passed
/home/htodd/openssh/ssh-keygen -if /home/htodd/openssh/regress/rsa_ssh2.prv | diff - /home/htodd/openssh/regress/rsa_openssh.prv
tr '\n' '\r' </home/htodd/openssh/regress/rsa_ssh2.prv > /home/htodd/openssh/regress/rsa_ssh2_cr.prv
/home/htodd/openssh/ssh-keygen -if /home/htodd/openssh/regress/rsa_ssh2_cr.prv | diff - /home/htodd/openssh/regress/rsa_openssh.prv
awk '{print $0 "\r"}' /home/htodd/openssh/regress/rsa_ssh2.prv > /home/htodd/openssh/regress/rsa_ssh2_crnl.prv
/home/htodd/openssh/ssh-keygen -if /home/htodd/openssh/regress/rsa_ssh2_crnl.prv | diff - /home/htodd/openssh/regress/rsa_openssh.prv
cat /home/htodd/openssh/regress/rsa_openssh.prv > /home/htodd/openssh/regress//t2.out
chmod 600 /home/htodd/openssh/regress//t2.out
/home/htodd/openssh/ssh-keygen -yf /home/htodd/openssh/regress//t2.out | diff - /home/htodd/openssh/regress/rsa_openssh.pub
/home/htodd/openssh/ssh-keygen -ef /home/htodd/openssh/regress/rsa_openssh.pub >/home/htodd/openssh/regress//t3.out
/home/htodd/openssh/ssh-keygen -if /home/htodd/openssh/regress//t3.out | diff - /home/htodd/openssh/regress/rsa_openssh.pub
/home/htodd/openssh/ssh-keygen -lf /home/htodd/openssh/regress/rsa_openssh.pub | awk '{print $2}' | diff - /home/htodd/openssh/regress/t4.ok
/home/htodd/openssh/ssh-keygen -Bf /home/htodd/openssh/regress/rsa_openssh.pub | awk '{print $2}' | diff - /home/htodd/openssh/regress/t5.ok
/home/htodd/openssh/ssh-keygen -if /home/htodd/openssh/regress/dsa_ssh2.prv > /home/htodd/openssh/regress//t6.out1
/home/htodd/openssh/ssh-keygen -if /home/htodd/openssh/regress/dsa_ssh2.pub > /home/htodd/openssh/regress//t6.out2
chmod 600 /home/htodd/openssh/regress//t6.out1
/home/htodd/openssh/ssh-keygen -yf /home/htodd/openssh/regress//t6.out1 | diff - /home/htodd/openssh/regress//t6.out2
/home/htodd/openssh/ssh-keygen -lf /home/htodd/openssh/regress//t7.out > /dev/null
/home/htodd/openssh/ssh-keygen -Bf /home/htodd/openssh/regress//t7.out > /dev/null
/home/htodd/openssh/ssh-keygen -lf /home/htodd/openssh/regress//t8.out > /dev/null
/home/htodd/openssh/ssh-keygen -Bf /home/htodd/openssh/regress//t8.out > /dev/null
test "yes" != yes ||  /home/htodd/openssh/ssh-keygen -lf /home/htodd/openssh/regress//t9.out > /dev/null
test "yes" != yes ||  /home/htodd/openssh/ssh-keygen -Bf /home/htodd/openssh/regress//t9.out > /dev/null
/home/htodd/openssh/ssh-keygen -lf /home/htodd/openssh/regress//t10.out > /dev/null
/home/htodd/openssh/ssh-keygen -Bf /home/htodd/openssh/regress//t10.out > /dev/null
run test connect.sh ...
+ '_POSIX2_VERSION=199209'
+ export '_POSIX2_VERSION'
+ uname -s
+ '[' '!' -z '' ']'
+ PORT=4242
+ '[' -x /usr/ucb/whoami ']'
+ whoami
+ whoami
+ USER=htodd
+ OBJ=/home/htodd/openssh/regress
+ '[' x/home/htodd/openssh/regress = x ']'
+ '[' '!' -d /home/htodd/openssh/regress ']'
+ 'SCRIPT=/home/htodd/openssh/regress/connect.sh'
+ '[' 'x/home/htodd/openssh/regress/connect.sh' = x ']'
+ '[' '!' -f '/home/htodd/openssh/regress/connect.sh' ']'
+ sh -n '/home/htodd/openssh/regress/connect.sh'
+ true
+ unset 'SSH_AUTH_SOCK'
+ dirname '/home/htodd/openssh/regress/connect.sh'
+ SRC=/home/htodd/openssh/regress
+ SSH=ssh
+ SSHD=sshd
+ SSHAGENT=ssh-agent
+ SSHADD=ssh-add
+ SSHKEYGEN=ssh-keygen
+ SSHKEYSCAN=ssh-keyscan
+ SFTP=sftp
+ SFTPSERVER=/usr/libexec/openssh/sftp-server
+ SCP=scp
+ PLINK=plink
+ PUTTYGEN=puttygen
+ CONCH=conch
+ '[' x/home/htodd/openssh/ssh '!=' x ']'
+ SSH=/home/htodd/openssh/ssh
+ '[' x/home/htodd/openssh/sshd '!=' x ']'
+ SSHD=/home/htodd/openssh/sshd
+ '[' x/home/htodd/openssh/ssh-agent '!=' x ']'
+ SSHAGENT=/home/htodd/openssh/ssh-agent
+ '[' x/home/htodd/openssh/ssh-add '!=' x ']'
+ SSHADD=/home/htodd/openssh/ssh-add
+ '[' x/home/htodd/openssh/ssh-keygen '!=' x ']'
+ SSHKEYGEN=/home/htodd/openssh/ssh-keygen
+ '[' x/home/htodd/openssh/ssh-keyscan '!=' x ']'
+ SSHKEYSCAN=/home/htodd/openssh/ssh-keyscan
+ '[' x/home/htodd/openssh/sftp '!=' x ']'
+ SFTP=/home/htodd/openssh/sftp
+ '[' x/home/htodd/openssh/sftp-server '!=' x ']'
+ SFTPSERVER=/home/htodd/openssh/sftp-server
+ '[' x '!=' x ']'
+ '[' xplink '!=' x ']'
+ which plink
+ PLINK=
+ '[' xputtygen '!=' x ']'
+ which puttygen
+ PUTTYGEN=
+ '[' xconch '!=' x ']'
+ which conch
+ CONCH=
+ '[' x = x ']'
+ 'TEST_SSH_LOGFILE=/home/htodd/openssh/regress/ssh.log'
+ '[' x = x ']'
+ 'TEST_SSHD_LOGFILE=/home/htodd/openssh/regress/sshd.log'
+ '[' x = x ']'
+ 'TEST_REGRESS_LOGFILE=/home/htodd/openssh/regress/regress.log'
+ 
+ 
+ 
+ 'SSHLOGWRAP=/home/htodd/openssh/regress/ssh-log-wrapper.sh'
+ echo '#!/bin/sh'
+ echo 'exec /home/htodd/openssh/ssh -E/home/htodd/openssh/regress/ssh.log "$@"'
+ chmod 'a+rx' '/home/htodd/openssh/regress/ssh-log-wrapper.sh'
+ 'SSH=/home/htodd/openssh/regress/ssh-log-wrapper.sh'
+ DATANAME=data
+ DATA=/home/htodd/openssh/regress/data
+ cat /home/htodd/openssh/ssh-agent
+ chmod 'u+w' /home/htodd/openssh/regress/data
+ COPY=/home/htodd/openssh/regress/copy
+ rm -f /home/htodd/openssh/regress/copy
+ export SSH SSHD SSHAGENT SSHADD SSHKEYGEN SSHKEYSCAN SFTP SFTPSERVER SCP
+ RESULT=0
+ PIDFILE=/home/htodd/openssh/regress/pidfile
+ trap fatal 3 2
+ cat
+ '[' '!' -z '' ']'
+ cp '/home/htodd/openssh/regress/sshd_config' '/home/htodd/openssh/regress/sshd_proxy'
+ echo 'StrictModes no'
+ cat
+ '[' '!' -z '' ']'
+ rm -f '/home/htodd/openssh/regress/known_hosts' '/home/htodd/openssh/regress/authorized_keys_htodd'
+ trace 'generate keys'
+ 'start_debug_log' generate keys
+ echo 'trace: generate' keys
+ echo 'trace: generate' keys
+ echo 'trace: generate' keys
+ '[' X = Xyes ']'
+ '[' '!' -f /home/htodd/openssh/regress/rsa ']'
+ '[' /home/htodd/openssh/ssh-keygen -nt /home/htodd/openssh/regress/rsa ']'
+ printf 'localhost-with-alias,127.0.0.1,::1 '
+ cat '/home/htodd/openssh/regress/rsa.pub'
+ cat '/home/htodd/openssh/regress/rsa.pub'
+ echo IdentityFile /home/htodd/openssh/regress/rsa
+ cp /home/htodd/openssh/regress/rsa '/home/htodd/openssh/regress/host.rsa'
+ echo HostKey '/home/htodd/openssh/regress/host.rsa'
+ echo HostKey /home/htodd/openssh/regress/rsa
+ '[' '!' -f /home/htodd/openssh/regress/rsa1 ']'
+ '[' /home/htodd/openssh/ssh-keygen -nt /home/htodd/openssh/regress/rsa1 ']'
+ printf 'localhost-with-alias,127.0.0.1,::1 '
+ cat '/home/htodd/openssh/regress/rsa1.pub'
+ cat '/home/htodd/openssh/regress/rsa1.pub'
+ echo IdentityFile /home/htodd/openssh/regress/rsa1
+ cp /home/htodd/openssh/regress/rsa1 '/home/htodd/openssh/regress/host.rsa1'
+ echo HostKey '/home/htodd/openssh/regress/host.rsa1'
+ echo HostKey /home/htodd/openssh/regress/rsa1
+ chmod 644 '/home/htodd/openssh/regress/authorized_keys_htodd'
+ 'REGRESS_INTEROP_CONCH=no'
+ test -x ''
+ 'REGRESS_INTEROP_PUTTY=no'
+ test -x '' -a -x ''
+ 'REGRESS_INTEROP_PUTTY=no'
+ test no = yes
+ cat '/home/htodd/openssh/regress/ssh_config'
+ echo proxycommand sh '/home/htodd/openssh/regress/sshd-log-wrapper.sh' /home/htodd/openssh/sshd '/home/htodd/openssh/regress/sshd.log' -i -f '/home/htodd/openssh/regress/sshd_proxy'
+ /home/htodd/openssh/sshd -t -f '/home/htodd/openssh/regress/sshd_proxy'
[1]   Segmentation fault (core dumped) ${SSHD} -t -f ${...
+ fatal 'sshd_proxy broken'
+ 'save_debug_log' 'FATAL: sshd_proxy broken'
+ echo 'FATAL:' 'sshd_proxy' broken
+ echo 'FATAL:' 'sshd_proxy' broken
+ echo 'FATAL:' 'sshd_proxy' broken
+ cat '/home/htodd/openssh/regress/regress.log'
+ echo
+ cat '/home/htodd/openssh/regress/ssh.log'
+ echo
+ cat '/home/htodd/openssh/regress/sshd.log'
+ echo
+ printf 'FATAL: '
FATAL: + fail 'sshd_proxy broken'
+ 'save_debug_log' 'FAIL: sshd_proxy broken'
+ echo 'FAIL:' 'sshd_proxy' broken
+ echo 'FAIL:' 'sshd_proxy' broken
+ echo 'FAIL:' 'sshd_proxy' broken
+ cat '/home/htodd/openssh/regress/regress.log'
+ echo
+ cat '/home/htodd/openssh/regress/ssh.log'
+ echo
+ cat '/home/htodd/openssh/regress/sshd.log'
+ echo
+ RESULT=1
+ echo 'sshd_proxy broken'
sshd_proxy broken
+ cleanup
+ '[' -f /home/htodd/openssh/regress/pidfile ']'
+ exit 1
*** Error code 1

Stop.
make[1]: stopped in /home/htodd/openssh/regress
*** Error code 1

Stop.
make: stopped in /home/htodd/openssh

-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

From dtucker at zip.com.au  Thu Jan 23 11:08:25 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 23 Jan 2014 11:08:25 +1100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.NEB.2.11.1401221555310.330@chris.i8u.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <alpine.NEB.2.11.1401221509590.330@chris.i8u.org>
 <CALDDTe38x1aLoFKB1AvbkEU65ueD3cWB5Jv-_Dhas29=x75f3g@mail.gmail.com>
 <alpine.NEB.2.11.1401221526120.330@chris.i8u.org>
 <CALDDTe2qYO1_haF6VD4=phE7+2AvJ1BS5Za6cpW53KtqN6C2Tw@mail.gmail.com>
 <alpine.NEB.2.11.1401221539450.330@chris.i8u.org>
 <CALDDTe2jM48Kn_ovy+cAq2d7Y=p=KjX4n8iv+Rd2c3m_9UaoWA@mail.gmail.com>
 <alpine.NEB.2.11.1401221555310.330@chris.i8u.org>
Message-ID: <CALDDTe0R7+z8UgrbvW+MbEEp77y15OgRX4fPETj=hZ+nfO++_A@mail.gmail.com>

On Thu, Jan 23, 2014 at 10:57 AM, Hisashi T Fujinaka <htodd at twofifty.com> wrote:
> + /home/htodd/openssh/sshd -t -f '/home/htodd/openssh/regress/sshd_proxy'
> [1]   Segmentation fault (core dumped) ${SSHD} -t -f ${...

well there's the problem: sshd is segfaulting immediately on startup.

I suspect this is fallout from the extra compiler hardening flags we
added recently.  Could you rebuild with "./configure
--without-hardening --without-pie && make clean && make tests' and see
if that works?

-- 
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 htodd at twofifty.com  Thu Jan 23 12:05:19 2014
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Wed, 22 Jan 2014 17:05:19 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <CALDDTe0R7+z8UgrbvW+MbEEp77y15OgRX4fPETj=hZ+nfO++_A@mail.gmail.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <alpine.NEB.2.11.1401221509590.330@chris.i8u.org>
 <CALDDTe38x1aLoFKB1AvbkEU65ueD3cWB5Jv-_Dhas29=x75f3g@mail.gmail.com>
 <alpine.NEB.2.11.1401221526120.330@chris.i8u.org>
 <CALDDTe2qYO1_haF6VD4=phE7+2AvJ1BS5Za6cpW53KtqN6C2Tw@mail.gmail.com>
 <alpine.NEB.2.11.1401221539450.330@chris.i8u.org>
 <CALDDTe2jM48Kn_ovy+cAq2d7Y=p=KjX4n8iv+Rd2c3m_9UaoWA@mail.gmail.com>
 <alpine.NEB.2.11.1401221555310.330@chris.i8u.org>
 <CALDDTe0R7+z8UgrbvW+MbEEp77y15OgRX4fPETj=hZ+nfO++_A@mail.gmail.com>
Message-ID: <alpine.NEB.2.11.1401221704550.330@chris.i8u.org>

On Thu, 23 Jan 2014, Darren Tucker wrote:

> On Thu, Jan 23, 2014 at 10:57 AM, Hisashi T Fujinaka <htodd at twofifty.com> wrote:
>> + /home/htodd/openssh/sshd -t -f '/home/htodd/openssh/regress/sshd_proxy'
>> [1]   Segmentation fault (core dumped) ${SSHD} -t -f ${...
>
> well there's the problem: sshd is segfaulting immediately on startup.
>
> I suspect this is fallout from the extra compiler hardening flags we
> added recently.  Could you rebuild with "./configure
> --without-hardening --without-pie && make clean && make tests' and see
> if that works?

Looks like the exact same error. Let me try on a netbsd-6 machine to see
if that works.

-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

From htodd at twofifty.com  Thu Jan 23 12:13:13 2014
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Wed, 22 Jan 2014 17:13:13 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.NEB.2.11.1401221704550.330@chris.i8u.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <alpine.NEB.2.11.1401221509590.330@chris.i8u.org>
 <CALDDTe38x1aLoFKB1AvbkEU65ueD3cWB5Jv-_Dhas29=x75f3g@mail.gmail.com>
 <alpine.NEB.2.11.1401221526120.330@chris.i8u.org>
 <CALDDTe2qYO1_haF6VD4=phE7+2AvJ1BS5Za6cpW53KtqN6C2Tw@mail.gmail.com>
 <alpine.NEB.2.11.1401221539450.330@chris.i8u.org>
 <CALDDTe2jM48Kn_ovy+cAq2d7Y=p=KjX4n8iv+Rd2c3m_9UaoWA@mail.gmail.com>
 <alpine.NEB.2.11.1401221555310.330@chris.i8u.org>
 <CALDDTe0R7+z8UgrbvW+MbEEp77y15OgRX4fPETj=hZ+nfO++_A@mail.gmail.com>
 <alpine.NEB.2.11.1401221704550.330@chris.i8u.org>
Message-ID: <alpine.NEB.2.11.1401221712230.330@chris.i8u.org>

On Wed, 22 Jan 2014, Hisashi T Fujinaka wrote:

> On Thu, 23 Jan 2014, Darren Tucker wrote:
>
>> On Thu, Jan 23, 2014 at 10:57 AM, Hisashi T Fujinaka <htodd at twofifty.com> 
>> wrote:
>>> + /home/htodd/openssh/sshd -t -f '/home/htodd/openssh/regress/sshd_proxy'
>>> [1]   Segmentation fault (core dumped) ${SSHD} -t -f ${...
>> 
>> well there's the problem: sshd is segfaulting immediately on startup.
>> 
>> I suspect this is fallout from the extra compiler hardening flags we
>> added recently.  Could you rebuild with "./configure
>> --without-hardening --without-pie && make clean && make tests' and see
>> if that works?
>
> Looks like the exact same error. Let me try on a netbsd-6 machine to see
> if that works.

htodd at mara:~/openssh/regress > gdb ../sshd sshd.core
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64--netbsd".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/htodd/openssh/sshd...done.
[New process 1]
Core was generated by `sshd'.
Program terminated with signal 11, Segmentation fault.
#0  0x00007f7ff62a0603 in istrsenvisx (mbdst=0x7f7fffffbde0 "\rj\340R", dlen=0x7f7fffffbc88,
     mbsrc=0x400 <Address 0x400 out of bounds>, mblength=0, flags=33, mbextra=0x7f7ff6310ee2 "", cerr_ptr=0x0)
     at /usr/src/lib/libc/gen/vis.c:379
379                     mblength = strlen(mbsrc);
(gdb) bt
#0  0x00007f7ff62a0603 in istrsenvisx (mbdst=0x7f7fffffbde0 "\rj\340R", dlen=0x7f7fffffbc88,
     mbsrc=0x400 <Address 0x400 out of bounds>, mblength=0, flags=33, mbextra=0x7f7ff6310ee2 "", cerr_ptr=0x0)
     at /usr/src/lib/libc/gen/vis.c:379
#1  0x00007f7ff62a11f8 in strnvis (mbdst=<optimized out>, dlen=140187732525536, mbsrc=<optimized out>, flags=<optimized out>)
     at /usr/src/lib/libc/gen/vis.c:655
#2  0x0000000000439ec5 in do_log (level=SYSLOG_LEVEL_FATAL, fmt=<optimized out>, args=0x7f7fffffc630) at log.c:438
#3  0x0000000000438c15 in fatal (fmt=<optimized out>) at fatal.c:42
#4  0x000000000040a7c8 in main (ac=<optimized out>, av=<optimized out>) at sshd.c:1803
(gdb)

-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

From dtucker at zip.com.au  Thu Jan 23 12:56:48 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 23 Jan 2014 12:56:48 +1100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.NEB.2.11.1401221712230.330@chris.i8u.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <alpine.NEB.2.11.1401221509590.330@chris.i8u.org>
 <CALDDTe38x1aLoFKB1AvbkEU65ueD3cWB5Jv-_Dhas29=x75f3g@mail.gmail.com>
 <alpine.NEB.2.11.1401221526120.330@chris.i8u.org>
 <CALDDTe2qYO1_haF6VD4=phE7+2AvJ1BS5Za6cpW53KtqN6C2Tw@mail.gmail.com>
 <alpine.NEB.2.11.1401221539450.330@chris.i8u.org>
 <CALDDTe2jM48Kn_ovy+cAq2d7Y=p=KjX4n8iv+Rd2c3m_9UaoWA@mail.gmail.com>
 <alpine.NEB.2.11.1401221555310.330@chris.i8u.org>
 <CALDDTe0R7+z8UgrbvW+MbEEp77y15OgRX4fPETj=hZ+nfO++_A@mail.gmail.com>
 <alpine.NEB.2.11.1401221704550.330@chris.i8u.org>
 <alpine.NEB.2.11.1401221712230.330@chris.i8u.org>
Message-ID: <CALDDTe1e490W6CVxF2PgNstswQf0yJsPBun_8qBUBsstzQ8s5A@mail.gmail.com>

On Thu, Jan 23, 2014 at 12:13 PM, Hisashi T Fujinaka <htodd at twofifty.com> wrote:
> #1  0x00007f7ff62a11f8 in strnvis (mbdst=<optimized out>,
> dlen=140187732525536, mbsrc=<optimized out>, flags=<optimized out>)
>     at /usr/src/lib/libc/gen/vis.c:655

strnvis?  interesting.   Could you please try:

../../configure --with-cflags=-DBROKEN_STRNVIS && make clean && make tests

Thanks.

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

From mark at markelee.com  Thu Jan 23 13:01:49 2014
From: mark at markelee.com (Mark E. Lee)
Date: Wed, 22 Jan 2014 21:01:49 -0500
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
Message-ID: <1390442509.6847.1.camel@melech-server.localdomain>

On Fri, 2014-01-17 at 11:26 +1100, Damien Miller wrote:
> Hi,
> 
> OpenSSH 6.5 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This release contains
> some substantial new features and a number of bugfixes.
> 
> Snapshot releases for portable OpenSSH are available from
> http://www.mindrot.org/openssh_snap/
> 
> The OpenBSD version is available in CVS HEAD:
> http://www.openbsd.org/anoncvs.html
> 
> Portable OpenSSH is also available via anonymous CVS using the
> instructions at http://www.openssh.com/portable.html#cvs or
> via Mercurial at http://hg.mindrot.org/openssh
> 
> Running the regression tests supplied with Portable OpenSSH does not
> require installation and is a simply:
> 
> $ ./configure && make tests
> 
> Live testing on suitable non-production systems is also
> appreciated. Please send reports of success or failure to
> openssh-unix-dev at mindrot.org.
> 
> Below is a summary of changes. More detail may be found in the ChangeLog
> in the portable OpenSSH tarballs.
> 
> Thanks to the many people who contributed to this release.
> 
> Changes since OpenSSH 6.4
> =========================
> 
> This is a feature-focused release.
> 
> New features:
> 
>  * ssh(1), sshd(8): Add support for key exchange using elliptic-curve
>    Diffie Hellman in Daniel Bernstein's Curve25519. This key exchange
>    method is the default when both the client and server support it.
> 
>  * ssh(1), sshd(8): Add support for Ed25519 as a public key type.
>    Ed25519 is a elliptic curve signature scheme that offers
>    better security than ECDSA and DSA and good performance. It may be
>    used for both user and host keys.
> 
>  * Add a new private key format that uses a bcrypt KDF to better
>    protect keys at rest. This format is used unconditionally for
>    Ed25519 keys, but may be requested when generating or saving
>    existing keys of other types via the -o ssh-keygen(1) option.
>    We intend to make the new format the default in the near future.
>    Details of the new format are in the PROTOCOL.key file.
> 
>  * ssh(1), sshd(8): Add a new transport cipher
>    "chacha20-poly1305 at openssh.com" that combines Daniel Bernstein's
>    ChaCha20 stream cipher and Poly1305 MAC to build an authenticated
>    encryption mode. Details are in the PROTOCOL.chacha20poly1305 file.
> 
>  * ssh(1), sshd(8): Refuse RSA keys from old proprietary clients and
>    servers that use the obsolete RSA+MD5 signature scheme. It will
>    still be possible to connect with these clients/servers but only
>    DSA keys will be accepted, and OpenSSH will refuse connection
>    entirely in a future release.
> 
>  * ssh(1), sshd(8): Refuse old proprietary clients and servers that
>    use a weaker key exchange hash calculation.
> 
>  * ssh(1): Increase the size of the Diffie-Hellman groups requested
>    for each symmetric key size. New values from NIST Special
>    Publication 800-57 with the upper limit specified by RFC4419
> 
>  * ssh(1), ssh-agent(1): Support pkcs#11 tokes that only provide
>    X.509 certs instead of raw public keys (requested as bz#1908).
> 
>  * ssh(1): Add a ssh_config(5) "Match" keyword that allows
>    conditional configuration to be applied by matching on hostname,
>    user and result of arbitrary commands.
> 
>  * ssh(1): Add support for client-side hostname canonicalisation
>    using a set of DNS suffixes and rules in ssh_config(5). This
>    allows unqualified names to be canonicalised to fully-qualified
>    domain names to eliminate ambiguity when looking up keys in
>    known_hosts or checking host certificate names.
> 
>  * sftp-server(8): Add the ability to whitelist and/or blacklist sftp
>    protocol requests by name.
> 
>  * sftp-server(8): Add a sftp "fsync at openssh.com" to support calling
>    fsync(2) on an open file handle.
> 
>  * sshd(8): Add a ssh_config(5) PermitTTY to disallow TTY allocation,
>    mirroring the longstanding no-pty authorized_keys option.
> 
>  * ssh(1): Add a ssh_config ProxyUseFDPass option that supports the
>    use of ProxyCommands that establish a connection and then pass a
>    connected file descriptor back to ssh(1). This allows the
>    ProxyCommand to exit rather than staying around to transfer data.
> 
> Bugfixes:
> 
>  * ssh(1), sshd(8): Fix potential stack exhaustion caused by nested
>    certificates.
> 
>  * ssh(1): bz#1211: make BindAddress work with UsePrivilegedPort.
> 
>  * sftp(1): bz#2137: fix the progress meter for resumed transfer.
> 
>  * ssh-add(1): bz#2187: do not request smartcard PIN when removing
>    keys from ssh-agent.
> 
>  * sshd(8): bz#2139: fix re-exec fallback when original sshd binary
>    cannot be executed.
> 
>  * ssh-keygen(1): Make relative-specified certificate expiry times
>    relative to current time and not the validity start time.
> 
>  * sshd(8): bz#2161: fix AuthorizedKeysCommand inside a Match block.
> 
>  * sftp(1): bz#2129: symlinking a file would incorrectly canonicalise
>    the target path.
> 
>  * ssh-agent(1): bz#2175: fix a use-after-free in the PKCS#11 agent
>    helper executable.
> 
>  * sshd(8): Improve logging of sessions to include the user name,
>    remote host and port, the session type (shell, command, etc.) and
>    allocated TTY (if any).
> 
>  * sshd(8): bz#1297: tell the client (via a debug message) when
>    their preferred listen address has been overridden by the
>    server's GatewayPorts setting.
> 
>  * sshd(8): bz#2162: include report port in bad protocol banner
>    message.
> 
>  * sftp(1): bz#2163: fix memory leak in error path in do_readdir()
> 
>  * sftp(1): bz#2171: don't leak file descriptor on error.
> 
>  * sshd(8): Include the local address and port in "Connection from
>    ..." message (only shown at loglevel>=verbose)
> 
> Portable OpenSSH:
> 
>  * Switch to a ChaCha20-based arc4random() PRNG for platforms that do
>    not provide their own.
> 
>  * sshd(8): bz#2156: restore Linux oom_adj setting when handling
>    SIGHUP to maintain behaviour over retart.
> 
>  * sshd(8): bz#2032: use local username in krb5_kuserok check rather
>    than full client name which may be of form user at REALM.
> 
>  * ssh(1), sshd(8): Test for both the presence of ECC NID numbers in
>    OpenSSL and that they actually work. Fedora (at least) has
>    NID_secp521r1 that doesn't work.
> 
>  * bz#2173: use pkg-config --libs to include correct -L location for
>    libedit.
> 
> Reporting Bugs:
> ===============
> 
> - Please read http://www.openssh.com/report.html
>   Security bugs should be reported directly to openssh at openssh.com
> 
> OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt,
> Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and
> Ben Lindstrom.
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

Salutations,

Tested 1/23/2014 snapshot on Arch Linux 64-bit with following configure
options:
./configure \
                --prefix=/usr \
                --sbindir=/usr/bin \
                --libexecdir=/usr/lib/ssh \
                --sysconfdir=/etc/ssh \
                --with-ldns \
                --with-libedit \
                --with-ssl-engine \
                --with-pam \
                --with-privsep-user=nobody \
                --with-kerberos5=/usr \
                --with-xauth=/usr/bin/xauth \
                --with-mantype=man \
                --with-md5-passwords \
                --with-pid-dir=/run \

Passed all tests.

Regards,
Mark
-- 
Mark E. Lee <mark at markelee.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 230 bytes
Desc: This is a digitally signed message part
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20140122/8a8aac61/attachment-0001.bin>

From htodd at twofifty.com  Thu Jan 23 13:56:34 2014
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Wed, 22 Jan 2014 18:56:34 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <CALDDTe1e490W6CVxF2PgNstswQf0yJsPBun_8qBUBsstzQ8s5A@mail.gmail.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <alpine.NEB.2.11.1401221509590.330@chris.i8u.org>
 <CALDDTe38x1aLoFKB1AvbkEU65ueD3cWB5Jv-_Dhas29=x75f3g@mail.gmail.com>
 <alpine.NEB.2.11.1401221526120.330@chris.i8u.org>
 <CALDDTe2qYO1_haF6VD4=phE7+2AvJ1BS5Za6cpW53KtqN6C2Tw@mail.gmail.com>
 <alpine.NEB.2.11.1401221539450.330@chris.i8u.org>
 <CALDDTe2jM48Kn_ovy+cAq2d7Y=p=KjX4n8iv+Rd2c3m_9UaoWA@mail.gmail.com>
 <alpine.NEB.2.11.1401221555310.330@chris.i8u.org>
 <CALDDTe0R7+z8UgrbvW+MbEEp77y15OgRX4fPETj=hZ+nfO++_A@mail.gmail.com>
 <alpine.NEB.2.11.1401221704550.330@chris.i8u.org>
 <alpine.NEB.2.11.1401221712230.330@chris.i8u.org>
 <CALDDTe1e490W6CVxF2PgNstswQf0yJsPBun_8qBUBsstzQ8s5A@mail.gmail.com>
Message-ID: <alpine.NEB.2.11.1401221855550.330@chris.i8u.org>

On Thu, 23 Jan 2014, Darren Tucker wrote:

> On Thu, Jan 23, 2014 at 12:13 PM, Hisashi T Fujinaka <htodd at twofifty.com> wrote:
>> #1  0x00007f7ff62a11f8 in strnvis (mbdst=<optimized out>,
>> dlen=140187732525536, mbsrc=<optimized out>, flags=<optimized out>)
>>     at /usr/src/lib/libc/gen/vis.c:655
>
> strnvis?  interesting.   Could you please try:
>
> ../../configure --with-cflags=-DBROKEN_STRNVIS && make clean && make tests

I had to make /var/empty, and then it appears to be hanging in "scp:
simple copy remote file to local file".

-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

From htodd at twofifty.com  Thu Jan 23 14:25:07 2014
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Wed, 22 Jan 2014 19:25:07 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.NEB.2.11.1401221920160.330@chris.i8u.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <alpine.NEB.2.11.1401221509590.330@chris.i8u.org>
 <CALDDTe38x1aLoFKB1AvbkEU65ueD3cWB5Jv-_Dhas29=x75f3g@mail.gmail.com>
 <alpine.NEB.2.11.1401221526120.330@chris.i8u.org>
 <CALDDTe2qYO1_haF6VD4=phE7+2AvJ1BS5Za6cpW53KtqN6C2Tw@mail.gmail.com>
 <alpine.NEB.2.11.1401221539450.330@chris.i8u.org>
 <CALDDTe2jM48Kn_ovy+cAq2d7Y=p=KjX4n8iv+Rd2c3m_9UaoWA@mail.gmail.com>
 <alpine.NEB.2.11.1401221555310.330@chris.i8u.org>
 <CALDDTe0R7+z8UgrbvW+MbEEp77y15OgRX4fPETj=hZ+nfO++_A@mail.gmail.com>
 <alpine.NEB.2.11.1401221704550.330@chris.i8u.org>
 <alpine.NEB.2.11.1401221712230.330@chris.i8u.org>
 <CALDDTe1e490W6CVxF2PgNstswQf0yJsPBun_8qBUBsstzQ8s5A@mail.gmail.com>
 <alpine.NEB.2.11.1401221920160.330@chris.i8u.org>
Message-ID: <alpine.NEB.2.11.1401221924480.330@chris.i8u.org>

On Wed, 22 Jan 2014, Hisashi T Fujinaka wrote:

> On Thu, 23 Jan 2014, Darren Tucker wrote:
>
>> On Thu, Jan 23, 2014 at 12:13 PM, Hisashi T Fujinaka <htodd at twofifty.com> 
>> wrote:
>>> #1  0x00007f7ff62a11f8 in strnvis (mbdst=<optimized out>,
>>> dlen=140187732525536, mbsrc=<optimized out>, flags=<optimized out>)
>>>     at /usr/src/lib/libc/gen/vis.c:655
>> 
>> strnvis?  interesting.   Could you please try:
>> 
>> ../../configure --with-cflags=-DBROKEN_STRNVIS && make clean && make tests
>
> I gave up on the file copy and here are the three fail logs.

Oh, I may have made a mistake. Is the git version the portable version?

-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

From htodd at twofifty.com  Thu Jan 23 14:22:28 2014
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Wed, 22 Jan 2014 19:22:28 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <CALDDTe1e490W6CVxF2PgNstswQf0yJsPBun_8qBUBsstzQ8s5A@mail.gmail.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <alpine.NEB.2.11.1401221509590.330@chris.i8u.org>
 <CALDDTe38x1aLoFKB1AvbkEU65ueD3cWB5Jv-_Dhas29=x75f3g@mail.gmail.com>
 <alpine.NEB.2.11.1401221526120.330@chris.i8u.org>
 <CALDDTe2qYO1_haF6VD4=phE7+2AvJ1BS5Za6cpW53KtqN6C2Tw@mail.gmail.com>
 <alpine.NEB.2.11.1401221539450.330@chris.i8u.org>
 <CALDDTe2jM48Kn_ovy+cAq2d7Y=p=KjX4n8iv+Rd2c3m_9UaoWA@mail.gmail.com>
 <alpine.NEB.2.11.1401221555310.330@chris.i8u.org>
 <CALDDTe0R7+z8UgrbvW+MbEEp77y15OgRX4fPETj=hZ+nfO++_A@mail.gmail.com>
 <alpine.NEB.2.11.1401221704550.330@chris.i8u.org>
 <alpine.NEB.2.11.1401221712230.330@chris.i8u.org>
 <CALDDTe1e490W6CVxF2PgNstswQf0yJsPBun_8qBUBsstzQ8s5A@mail.gmail.com>
Message-ID: <alpine.NEB.2.11.1401221920160.330@chris.i8u.org>

On Thu, 23 Jan 2014, Darren Tucker wrote:

> On Thu, Jan 23, 2014 at 12:13 PM, Hisashi T Fujinaka <htodd at twofifty.com> wrote:
>> #1  0x00007f7ff62a11f8 in strnvis (mbdst=<optimized out>,
>> dlen=140187732525536, mbsrc=<optimized out>, flags=<optimized out>)
>>     at /usr/src/lib/libc/gen/vis.c:655
>
> strnvis?  interesting.   Could you please try:
>
> ../../configure --with-cflags=-DBROKEN_STRNVIS && make clean && make tests

I gave up on the file copy and here are the three fail logs.

-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte
-------------- next part --------------
trace: generate keys
FATAL: sshd_proxy broken

trace: generate keys
FATAL: sshd_proxy broken
FAIL: sshd_proxy broken

trace: scp: simple copy remote file to local file
FATAL:

trace: scp: simple copy remote file to local file
FATAL:
FAIL:

trace: test remote exit status: proto 1 status 0
debug1: inetd sockets after dupping: 4, 5

Connection from UNKNOWN port 65535 on UNKNOWN port 65535

debug1: Client protocol version 1.5; client software version OpenSSH_6.5

debug1: match: OpenSSH_6.5 pat OpenSSH* compat 0x04000000

debug1: Local version string SSH-1.99-OpenSSH_6.5

Generating 1024 bit RSA key.

RSA key generation complete.

debug2: fd 4 setting O_NONBLOCK

debug2: fd 5 setting O_NONBLOCK

debug2: Network child is on pid 4361

debug3: preauth child monitor started

debug1: Sent 1024 bit server key and 2048 bit host key. [preauth]

debug1: Encryption type: 3des [preauth]

debug3: mm_request_send entering: type 32 [preauth]

debug3: mm_request_receive entering

debug3: monitor_read: checking request 32

debug3: mm_request_send entering: type 33

debug2: monitor_read: 32 used once, disabling now

debug3: mm_request_receive_expect entering: type 33 [preauth]

debug3: mm_request_receive entering [preauth]

debug3: mm_ssh1_session_id entering [preauth]

debug3: mm_request_send entering: type 34 [preauth]

debug3: mm_request_receive entering

debug3: monitor_read: checking request 34

debug3: mm_answer_sessid entering

debug2: monitor_read: 34 used once, disabling now

debug2: cipher_init: set keylen (16 -> 32) [preauth]

debug2: cipher_init: set keylen (16 -> 32) [preauth]

debug1: Received session key; encryption turned on. [preauth]

debug1: Installing crc compensation attack detector. [preauth]

debug3: mm_getpwnamallow entering [preauth]

debug3: mm_request_send entering: type 8 [preauth]

debug3: mm_request_receive entering

debug3: monitor_read: checking request 8

debug3: mm_answer_pwnamallow

debug2: parse_server_config: config reprocess config len 405

debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1

debug3: mm_request_send entering: type 9

debug2: monitor_read: 8 used once, disabling now

debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM [preauth]

debug3: mm_request_receive_expect entering: type 9 [preauth]

debug3: mm_request_receive entering [preauth]

debug1: Attempting authentication for htodd. [preauth]

debug3: mm_auth_rsa_key_allowed entering [preauth]

debug3: mm_request_send entering: type 36 [preauth]

debug3: mm_request_receive entering

debug3: monitor_read: checking request 36

debug3: mm_answer_rsa_keyallowed entering

debug1: trying public RSA key file /home/htodd/openssh/regress/authorized_keys_htodd

debug1: fd 6 clearing O_NONBLOCK

debug1: /home/htodd/openssh/regress/authorized_keys_htodd, line 1: non ssh1 key syntax

debug1: matching key found: file /home/htodd/openssh/regress/authorized_keys_htodd, line 2 RSA1 fe:d0:cf:47:30:46:c1:1f:55:e5:4e:60:2a:9f:1d:3b

debug1: restore_uid: (unprivileged)

debug3: mm_request_send entering: type 37

Failed rsa for htodd from UNKNOWN port 65535 ssh1

debug3: mm_request_receive_expect entering: type 37 [preauth]

debug3: mm_request_receive entering [preauth]

debug3: mm_auth_rsa_generate_challenge entering [preauth]

debug3: mm_request_send entering: type 38 [preauth]

debug3: mm_request_receive entering

debug3: monitor_read: checking request 38

debug3: mm_answer_rsa_challenge entering

debug3: mm_answer_rsa_challenge sending reply

debug3: mm_request_send entering: type 39

debug2: monitor_read: 38 used once, disabling now

debug3: mm_request_receive_expect entering: type 39 [preauth]

debug3: mm_request_receive entering [preauth]

debug3: mm_auth_rsa_verify_response entering [preauth]

debug3: mm_request_send entering: type 40 [preauth]

debug3: mm_request_receive entering

debug3: monitor_read: checking request 40

debug3: mm_answer_rsa_response entering

debug3: mm_request_send entering: type 41

debug2: monitor_read: 40 used once, disabling now

Accepted rsa for htodd from UNKNOWN port 65535 ssh1

debug1: monitor_child_preauth: htodd has been authenticated by privileged process

debug3: mm_get_keystate: Waiting for new keys

debug3: mm_request_receive_expect entering: type 26

debug3: mm_request_receive entering

debug3: mm_get_keystate: Getting compression state

debug3: mm_get_keystate: Getting Network I/O buffers

debug3: mm_request_receive_expect entering: type 41 [preauth]

debug3: mm_request_receive entering [preauth]

debug3: mm_send_keystate: Sending ssh1 KEY+IV [preauth]

debug3: ssh1_3des_iv: Copying 3DES IV [preauth]

debug3: ssh1_3des_iv: Copying 3DES IV [preauth]

debug3: mm_send_keystate: Sending compression state [preauth]

debug3: mm_request_send entering: type 26 [preauth]

debug3: mm_send_keystate: Finished sending state [preauth]

debug1: monitor_read_log: child log fd closed

debug3: mm_share_sync: Share sync

debug3: mm_share_sync: Share sync end

User child is on pid 2619

debug2: cipher_init: set keylen (16 -> 32)

debug2: cipher_init: set keylen (16 -> 32)

debug3: ssh1_3des_iv: Installed 3DES IV

debug3: ssh1_3des_iv: Installed 3DES IV

debug2: session_new: allocate (allocated 0 max 10)

debug3: session_unused: session id 0 unused

debug1: session_new: session 0

debug1: Installing crc compensation attack detector.

debug1: Exec command 'exit 0'

Starting session: command for htodd from UNKNOWN port 65535

debug1: Entering interactive session.

debug2: fd 8 setting O_NONBLOCK

debug2: fd 9 setting O_NONBLOCK

debug2: fd 11 setting O_NONBLOCK

debug2: fd 7 setting O_NONBLOCK

debug2: fd 10 setting O_NONBLOCK

debug1: server_init_dispatch_13

debug1: server_init_dispatch_15

debug2: notify_done: reading

debug1: End of interactive session; stdin 0, stdout (read 0, sent 0), stderr 0 bytes.

debug1: Command exited with status 0.

debug3: mm_request_receive entering

debug1: do_cleanup

debug1: inetd sockets after dupping: 4, 5

Connection from UNKNOWN port 65535 on UNKNOWN port 65535

debug1: Client protocol version 1.5; client software version OpenSSH_6.5

debug1: match: OpenSSH_6.5 pat OpenSSH* compat 0x04000000

debug1: Local version string SSH-1.99-OpenSSH_6.5

Generating 1024 bit RSA key.

RSA key generation complete.

debug2: fd 4 setting O_NONBLOCK

debug2: fd 5 setting O_NONBLOCK

debug2: Network child is on pid 3499

debug3: preauth child monitor started

debug1: Sent 1024 bit server key and 2048 bit host key. [preauth]

debug1: Encryption type: 3des [preauth]

debug3: mm_request_send entering: type 32 [preauth]

debug3: mm_request_receive entering

debug3: monitor_read: checking request 32

debug3: mm_request_send entering: type 33

debug2: monitor_read: 32 used once, disabling now

debug3: mm_request_receive_expect entering: type 33 [preauth]

debug3: mm_request_receive entering [preauth]

debug3: mm_ssh1_session_id entering [preauth]

debug3: mm_request_send entering: type 34 [preauth]

debug3: mm_request_receive entering

debug3: monitor_read: checking request 34

debug3: mm_answer_sessid entering

debug2: monitor_read: 34 used once, disabling now

debug2: cipher_init: set keylen (16 -> 32) [preauth]

debug2: cipher_init: set keylen (16 -> 32) [preauth]

debug1: Received session key; encryption turned on. [preauth]

debug1: Installing crc compensation attack detector. [preauth]

debug3: mm_getpwnamallow entering [preauth]

debug3: mm_request_send entering: type 8 [preauth]

debug3: mm_request_receive entering

debug3: monitor_read: checking request 8

debug3: mm_answer_pwnamallow

debug2: parse_server_config: config reprocess config len 405

debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1

debug3: mm_request_send entering: type 9

debug2: monitor_read: 8 used once, disabling now

debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM [preauth]

debug3: mm_request_receive_expect entering: type 9 [preauth]

debug3: mm_request_receive entering [preauth]

debug1: Attempting authentication for htodd. [preauth]

debug3: mm_auth_rsa_key_allowed entering [preauth]

debug3: mm_request_send entering: type 36 [preauth]

debug3: mm_request_receive entering

debug3: monitor_read: checking request 36

debug3: mm_answer_rsa_keyallowed entering

debug1: trying public RSA key file /home/htodd/openssh/regress/authorized_keys_htodd

debug1: fd 6 clearing O_NONBLOCK

debug1: /home/htodd/openssh/regress/authorized_keys_htodd, line 1: non ssh1 key syntax

debug1: matching key found: file /home/htodd/openssh/regress/authorized_keys_htodd, line 2 RSA1 fe:d0:cf:47:30:46:c1:1f:55:e5:4e:60:2a:9f:1d:3b

debug1: restore_uid: (unprivileged)

debug3: mm_request_send entering: type 37

Failed rsa for htodd from UNKNOWN port 65535 ssh1

debug3: mm_request_receive_expect entering: type 37 [preauth]

debug3: mm_request_receive entering [preauth]

debug3: mm_auth_rsa_generate_challenge entering [preauth]

debug3: mm_request_send entering: type 38 [preauth]

debug3: mm_request_receive entering

debug3: monitor_read: checking request 38

debug3: mm_answer_rsa_challenge entering

debug3: mm_answer_rsa_challenge sending reply

debug3: mm_request_send entering: type 39

debug2: monitor_read: 38 used once, disabling now

debug3: mm_request_receive_expect entering: type 39 [preauth]

debug3: mm_request_receive entering [preauth]

debug3: mm_auth_rsa_verify_response entering [preauth]

debug3: mm_request_send entering: type 40 [preauth]

debug3: mm_request_receive entering

debug3: monitor_read: checking request 40

debug3: mm_answer_rsa_response entering

debug3: mm_request_send entering: type 41

debug2: monitor_read: 40 used once, disabling now

Accepted rsa for htodd from UNKNOWN port 65535 ssh1

debug1: monitor_child_preauth: htodd has been authenticated by privileged process

debug3: mm_get_keystate: Waiting for new keys

debug3: mm_request_receive_expect entering: type 26

debug3: mm_request_receive entering

debug3: mm_get_keystate: Getting compression state

debug3: mm_get_keystate: Getting Network I/O buffers

debug3: mm_request_receive_expect entering: type 41 [preauth]

debug3: mm_request_receive entering [preauth]

debug3: mm_send_keystate: Sending ssh1 KEY+IV [preauth]

debug3: ssh1_3des_iv: Copying 3DES IV [preauth]

debug3: ssh1_3des_iv: Copying 3DES IV [preauth]

debug3: mm_send_keystate: Sending compression state [preauth]

debug3: mm_request_send entering: type 26 [preauth]

debug3: mm_send_keystate: Finished sending state [preauth]

debug1: monitor_read_log: child log fd closed

debug3: mm_share_sync: Share sync

debug3: mm_share_sync: Share sync end

User child is on pid 4961

debug2: cipher_init: set keylen (16 -> 32)

debug2: cipher_init: set keylen (16 -> 32)

debug3: ssh1_3des_iv: Installed 3DES IV

debug3: ssh1_3des_iv: Installed 3DES IV

debug2: session_new: allocate (allocated 0 max 10)

debug3: session_unused: session id 0 unused

debug1: session_new: session 0

debug1: Installing crc compensation attack detector.

debug1: Exec command 'exec sh -c 'sleep 2; exec > /dev/null 2>&1; sleep 3; exit 0''

Starting session: command for htodd from UNKNOWN port 65535

debug1: Entering interactive session.

debug2: fd 8 setting O_NONBLOCK

debug2: fd 9 setting O_NONBLOCK

debug2: fd 11 setting O_NONBLOCK

debug2: fd 7 setting O_NONBLOCK

debug2: fd 10 setting O_NONBLOCK

debug1: server_init_dispatch_13

debug1: server_init_dispatch_15

debug1: EOF received for stdin.

debug3: mm_request_receive entering

debug1: do_cleanup

FATAL:

trace: test remote exit status: proto 1 status 0
debug1: inetd sockets after dupping: 4, 5

Connection from UNKNOWN port 65535 on UNKNOWN port 65535

debug1: Client protocol version 1.5; client software version OpenSSH_6.5

debug1: match: OpenSSH_6.5 pat OpenSSH* compat 0x04000000

debug1: Local version string SSH-1.99-OpenSSH_6.5

Generating 1024 bit RSA key.

RSA key generation complete.

debug2: fd 4 setting O_NONBLOCK

debug2: fd 5 setting O_NONBLOCK

debug2: Network child is on pid 4361

debug3: preauth child monitor started

debug1: Sent 1024 bit server key and 2048 bit host key. [preauth]

debug1: Encryption type: 3des [preauth]

debug3: mm_request_send entering: type 32 [preauth]

debug3: mm_request_receive entering

debug3: monitor_read: checking request 32

debug3: mm_request_send entering: type 33

debug2: monitor_read: 32 used once, disabling now

debug3: mm_request_receive_expect entering: type 33 [preauth]

debug3: mm_request_receive entering [preauth]

debug3: mm_ssh1_session_id entering [preauth]

debug3: mm_request_send entering: type 34 [preauth]

debug3: mm_request_receive entering

debug3: monitor_read: checking request 34

debug3: mm_answer_sessid entering

debug2: monitor_read: 34 used once, disabling now

debug2: cipher_init: set keylen (16 -> 32) [preauth]

debug2: cipher_init: set keylen (16 -> 32) [preauth]

debug1: Received session key; encryption turned on. [preauth]

debug1: Installing crc compensation attack detector. [preauth]

debug3: mm_getpwnamallow entering [preauth]

debug3: mm_request_send entering: type 8 [preauth]

debug3: mm_request_receive entering

debug3: monitor_read: checking request 8

debug3: mm_answer_pwnamallow

debug2: parse_server_config: config reprocess config len 405

debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1

debug3: mm_request_send entering: type 9

debug2: monitor_read: 8 used once, disabling now

debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM [preauth]

debug3: mm_request_receive_expect entering: type 9 [preauth]

debug3: mm_request_receive entering [preauth]

debug1: Attempting authentication for htodd. [preauth]

debug3: mm_auth_rsa_key_allowed entering [preauth]

debug3: mm_request_send entering: type 36 [preauth]

debug3: mm_request_receive entering

debug3: monitor_read: checking request 36

debug3: mm_answer_rsa_keyallowed entering

debug1: trying public RSA key file /home/htodd/openssh/regress/authorized_keys_htodd

debug1: fd 6 clearing O_NONBLOCK

debug1: /home/htodd/openssh/regress/authorized_keys_htodd, line 1: non ssh1 key syntax

debug1: matching key found: file /home/htodd/openssh/regress/authorized_keys_htodd, line 2 RSA1 fe:d0:cf:47:30:46:c1:1f:55:e5:4e:60:2a:9f:1d:3b

debug1: restore_uid: (unprivileged)

debug3: mm_request_send entering: type 37

Failed rsa for htodd from UNKNOWN port 65535 ssh1

debug3: mm_request_receive_expect entering: type 37 [preauth]

debug3: mm_request_receive entering [preauth]

debug3: mm_auth_rsa_generate_challenge entering [preauth]

debug3: mm_request_send entering: type 38 [preauth]

debug3: mm_request_receive entering

debug3: monitor_read: checking request 38

debug3: mm_answer_rsa_challenge entering

debug3: mm_answer_rsa_challenge sending reply

debug3: mm_request_send entering: type 39

debug2: monitor_read: 38 used once, disabling now

debug3: mm_request_receive_expect entering: type 39 [preauth]

debug3: mm_request_receive entering [preauth]

debug3: mm_auth_rsa_verify_response entering [preauth]

debug3: mm_request_send entering: type 40 [preauth]

debug3: mm_request_receive entering

debug3: monitor_read: checking request 40

debug3: mm_answer_rsa_response entering

debug3: mm_request_send entering: type 41

debug2: monitor_read: 40 used once, disabling now

Accepted rsa for htodd from UNKNOWN port 65535 ssh1

debug1: monitor_child_preauth: htodd has been authenticated by privileged process

debug3: mm_get_keystate: Waiting for new keys

debug3: mm_request_receive_expect entering: type 26

debug3: mm_request_receive entering

debug3: mm_get_keystate: Getting compression state

debug3: mm_get_keystate: Getting Network I/O buffers

debug3: mm_request_receive_expect entering: type 41 [preauth]

debug3: mm_request_receive entering [preauth]

debug3: mm_send_keystate: Sending ssh1 KEY+IV [preauth]

debug3: ssh1_3des_iv: Copying 3DES IV [preauth]

debug3: ssh1_3des_iv: Copying 3DES IV [preauth]

debug3: mm_send_keystate: Sending compression state [preauth]

debug3: mm_request_send entering: type 26 [preauth]

debug3: mm_send_keystate: Finished sending state [preauth]

debug1: monitor_read_log: child log fd closed

debug3: mm_share_sync: Share sync

debug3: mm_share_sync: Share sync end

User child is on pid 2619

debug2: cipher_init: set keylen (16 -> 32)

debug2: cipher_init: set keylen (16 -> 32)

debug3: ssh1_3des_iv: Installed 3DES IV

debug3: ssh1_3des_iv: Installed 3DES IV

debug2: session_new: allocate (allocated 0 max 10)

debug3: session_unused: session id 0 unused

debug1: session_new: session 0

debug1: Installing crc compensation attack detector.

debug1: Exec command 'exit 0'

Starting session: command for htodd from UNKNOWN port 65535

debug1: Entering interactive session.

debug2: fd 8 setting O_NONBLOCK

debug2: fd 9 setting O_NONBLOCK

debug2: fd 11 setting O_NONBLOCK

debug2: fd 7 setting O_NONBLOCK

debug2: fd 10 setting O_NONBLOCK

debug1: server_init_dispatch_13

debug1: server_init_dispatch_15

debug2: notify_done: reading

debug1: End of interactive session; stdin 0, stdout (read 0, sent 0), stderr 0 bytes.

debug1: Command exited with status 0.

debug3: mm_request_receive entering

debug1: do_cleanup

debug1: inetd sockets after dupping: 4, 5

Connection from UNKNOWN port 65535 on UNKNOWN port 65535

debug1: Client protocol version 1.5; client software version OpenSSH_6.5

debug1: match: OpenSSH_6.5 pat OpenSSH* compat 0x04000000

debug1: Local version string SSH-1.99-OpenSSH_6.5

Generating 1024 bit RSA key.

RSA key generation complete.

debug2: fd 4 setting O_NONBLOCK

debug2: fd 5 setting O_NONBLOCK

debug2: Network child is on pid 3499

debug3: preauth child monitor started

debug1: Sent 1024 bit server key and 2048 bit host key. [preauth]

debug1: Encryption type: 3des [preauth]

debug3: mm_request_send entering: type 32 [preauth]

debug3: mm_request_receive entering

debug3: monitor_read: checking request 32

debug3: mm_request_send entering: type 33

debug2: monitor_read: 32 used once, disabling now

debug3: mm_request_receive_expect entering: type 33 [preauth]

debug3: mm_request_receive entering [preauth]

debug3: mm_ssh1_session_id entering [preauth]

debug3: mm_request_send entering: type 34 [preauth]

debug3: mm_request_receive entering

debug3: monitor_read: checking request 34

debug3: mm_answer_sessid entering

debug2: monitor_read: 34 used once, disabling now

debug2: cipher_init: set keylen (16 -> 32) [preauth]

debug2: cipher_init: set keylen (16 -> 32) [preauth]

debug1: Received session key; encryption turned on. [preauth]

debug1: Installing crc compensation attack detector. [preauth]

debug3: mm_getpwnamallow entering [preauth]

debug3: mm_request_send entering: type 8 [preauth]

debug3: mm_request_receive entering

debug3: monitor_read: checking request 8

debug3: mm_answer_pwnamallow

debug2: parse_server_config: config reprocess config len 405

debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1

debug3: mm_request_send entering: type 9

debug2: monitor_read: 8 used once, disabling now

debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM [preauth]

debug3: mm_request_receive_expect entering: type 9 [preauth]

debug3: mm_request_receive entering [preauth]

debug1: Attempting authentication for htodd. [preauth]

debug3: mm_auth_rsa_key_allowed entering [preauth]

debug3: mm_request_send entering: type 36 [preauth]

debug3: mm_request_receive entering

debug3: monitor_read: checking request 36

debug3: mm_answer_rsa_keyallowed entering

debug1: trying public RSA key file /home/htodd/openssh/regress/authorized_keys_htodd

debug1: fd 6 clearing O_NONBLOCK

debug1: /home/htodd/openssh/regress/authorized_keys_htodd, line 1: non ssh1 key syntax

debug1: matching key found: file /home/htodd/openssh/regress/authorized_keys_htodd, line 2 RSA1 fe:d0:cf:47:30:46:c1:1f:55:e5:4e:60:2a:9f:1d:3b

debug1: restore_uid: (unprivileged)

debug3: mm_request_send entering: type 37

Failed rsa for htodd from UNKNOWN port 65535 ssh1

debug3: mm_request_receive_expect entering: type 37 [preauth]

debug3: mm_request_receive entering [preauth]

debug3: mm_auth_rsa_generate_challenge entering [preauth]

debug3: mm_request_send entering: type 38 [preauth]

debug3: mm_request_receive entering

debug3: monitor_read: checking request 38

debug3: mm_answer_rsa_challenge entering

debug3: mm_answer_rsa_challenge sending reply

debug3: mm_request_send entering: type 39

debug2: monitor_read: 38 used once, disabling now

debug3: mm_request_receive_expect entering: type 39 [preauth]

debug3: mm_request_receive entering [preauth]

debug3: mm_auth_rsa_verify_response entering [preauth]

debug3: mm_request_send entering: type 40 [preauth]

debug3: mm_request_receive entering

debug3: monitor_read: checking request 40

debug3: mm_answer_rsa_response entering

debug3: mm_request_send entering: type 41

debug2: monitor_read: 40 used once, disabling now

Accepted rsa for htodd from UNKNOWN port 65535 ssh1

debug1: monitor_child_preauth: htodd has been authenticated by privileged process

debug3: mm_get_keystate: Waiting for new keys

debug3: mm_request_receive_expect entering: type 26

debug3: mm_request_receive entering

debug3: mm_get_keystate: Getting compression state

debug3: mm_get_keystate: Getting Network I/O buffers

debug3: mm_request_receive_expect entering: type 41 [preauth]

debug3: mm_request_receive entering [preauth]

debug3: mm_send_keystate: Sending ssh1 KEY+IV [preauth]

debug3: ssh1_3des_iv: Copying 3DES IV [preauth]

debug3: ssh1_3des_iv: Copying 3DES IV [preauth]

debug3: mm_send_keystate: Sending compression state [preauth]

debug3: mm_request_send entering: type 26 [preauth]

debug3: mm_send_keystate: Finished sending state [preauth]

debug1: monitor_read_log: child log fd closed

debug3: mm_share_sync: Share sync

debug3: mm_share_sync: Share sync end

User child is on pid 4961

debug2: cipher_init: set keylen (16 -> 32)

debug2: cipher_init: set keylen (16 -> 32)

debug3: ssh1_3des_iv: Installed 3DES IV

debug3: ssh1_3des_iv: Installed 3DES IV

debug2: session_new: allocate (allocated 0 max 10)

debug3: session_unused: session id 0 unused

debug1: session_new: session 0

debug1: Installing crc compensation attack detector.

debug1: Exec command 'exec sh -c 'sleep 2; exec > /dev/null 2>&1; sleep 3; exit 0''

Starting session: command for htodd from UNKNOWN port 65535

debug1: Entering interactive session.

debug2: fd 8 setting O_NONBLOCK

debug2: fd 9 setting O_NONBLOCK

debug2: fd 11 setting O_NONBLOCK

debug2: fd 7 setting O_NONBLOCK

debug2: fd 10 setting O_NONBLOCK

debug1: server_init_dispatch_13

debug1: server_init_dispatch_15

debug1: EOF received for stdin.

debug3: mm_request_receive entering

debug1: do_cleanup

FATAL:
FAIL:

trace: generate keys
FATAL: sshd_proxy broken

trace: generate keys
FATAL: sshd_proxy broken
FAIL: sshd_proxy broken

trace: generate keys
FATAL: sshd_proxy broken

trace: generate keys
FATAL: sshd_proxy broken
FAIL: sshd_proxy broken

trace: scp: simple copy remote file to local file
FATAL:

trace: scp: simple copy remote file to local file
FATAL:
FAIL:

-------------- next part --------------
trace: generate keys
FATAL: sshd_proxy broken

trace: generate keys
FATAL: sshd_proxy broken
FAIL: sshd_proxy broken

trace: scp: simple copy remote file to local file
FATAL:

trace: scp: simple copy remote file to local file
FATAL:
FAIL:

trace: test remote exit status: proto 1 status 0
debug1: Executing proxy command: exec sh /home/htodd/openssh/regress/sshd-log-wrapper.sh /home/htodd/openssh/sshd /home/htodd/openssh/regress/sshd.log -i -f /home/htodd/openssh/regress/sshd_proxy

debug3: Incorrect RSA1 identifier

debug3: Could not load "/home/htodd/openssh/regress/rsa" as a RSA1 public key

debug1: identity file /home/htodd/openssh/regress/rsa type 1

debug1: identity file /home/htodd/openssh/regress/rsa-cert type -1

debug1: identity file /home/htodd/openssh/regress/rsa1 type 0

debug1: identity file /home/htodd/openssh/regress/rsa1-cert type -1

debug1: permanently_drop_suid: 1000

debug1: Remote protocol version 1.99, remote software version OpenSSH_6.5

debug1: match: OpenSSH_6.5 pat OpenSSH* compat 0x04000000

debug1: Local version string SSH-1.5-OpenSSH_6.5

debug2: fd 6 setting O_NONBLOCK

debug2: fd 5 setting O_NONBLOCK

debug1: Waiting for server public key.

debug1: Received server public key (1024 bits) and host key (2048 bits).

debug1: Server host key: RSA1 fe:d0:cf:47:30:46:c1:1f:55:e5:4e:60:2a:9f:1d:3b

debug1: using hostkeyalias: localhost-with-alias

debug3: load_hostkeys: loading entries for host "localhost-with-alias" from file "/home/htodd/openssh/regress/known_hosts"

debug3: load_hostkeys: found key type RSA in file /home/htodd/openssh/regress/known_hosts:1

debug2: key_type_from_name: unknown key type '2048'

debug3: key_read: missing keytype

debug3: load_hostkeys: found key type RSA1 in file /home/htodd/openssh/regress/known_hosts:2

debug3: load_hostkeys: loaded 2 keys

debug3: load_hostkeys: loading entries for host "localhost-with-alias" from file "/home/htodd/openssh/regress/known_hosts"

debug3: load_hostkeys: found key type RSA in file /home/htodd/openssh/regress/known_hosts:1

debug2: key_type_from_name: unknown key type '2048'

debug3: key_read: missing keytype

debug3: load_hostkeys: found key type RSA1 in file /home/htodd/openssh/regress/known_hosts:2

debug3: load_hostkeys: loaded 2 keys

debug1: Host 'localhost-with-alias' is known and matches the RSA1 host key.

debug1: Found key in /home/htodd/openssh/regress/known_hosts:2

debug1: Encryption type: 3des

debug1: Sent encrypted session key.

debug2: cipher_init: set keylen (16 -> 32)

debug2: cipher_init: set keylen (16 -> 32)

debug1: Installing crc compensation attack detector.

debug1: Received encrypted confirmation.

debug1: Trying RSA authentication with key '/home/htodd/openssh/regress/rsa1'

debug1: Received RSA challenge from server.

debug1: Sending response to host key RSA challenge.

debug1: Remote: RSA authentication accepted.

debug1: RSA authentication accepted by server.

Authenticated to 127.0.0.1 (via proxy).

debug1: Sending command: exit 0

debug1: Entering interactive session.

debug2: fd 0 setting O_NONBLOCK

debug1: fd 0 clearing O_NONBLOCK

Transferred: sent 1202, received 804 bytes, in 0.0 seconds

Bytes per second: sent 78800.1, received 52708.2

debug1: Exit status 0

debug1: Executing proxy command: exec sh /home/htodd/openssh/regress/sshd-log-wrapper.sh /home/htodd/openssh/sshd /home/htodd/openssh/regress/sshd.log -i -f /home/htodd/openssh/regress/sshd_proxy

debug3: Incorrect RSA1 identifier

debug3: Could not load "/home/htodd/openssh/regress/rsa" as a RSA1 public key

debug1: permanently_drop_suid: 1000

debug1: identity file /home/htodd/openssh/regress/rsa type 1

debug1: identity file /home/htodd/openssh/regress/rsa-cert type -1

debug1: identity file /home/htodd/openssh/regress/rsa1 type 0

debug1: identity file /home/htodd/openssh/regress/rsa1-cert type -1

debug1: Remote protocol version 1.99, remote software version OpenSSH_6.5

debug1: match: OpenSSH_6.5 pat OpenSSH* compat 0x04000000

debug1: Local version string SSH-1.5-OpenSSH_6.5

debug2: fd 6 setting O_NONBLOCK

debug2: fd 5 setting O_NONBLOCK

debug1: Waiting for server public key.

debug1: Received server public key (1024 bits) and host key (2048 bits).

debug1: Server host key: RSA1 fe:d0:cf:47:30:46:c1:1f:55:e5:4e:60:2a:9f:1d:3b

debug1: using hostkeyalias: localhost-with-alias

debug3: load_hostkeys: loading entries for host "localhost-with-alias" from file "/home/htodd/openssh/regress/known_hosts"

debug3: load_hostkeys: found key type RSA in file /home/htodd/openssh/regress/known_hosts:1

debug2: key_type_from_name: unknown key type '2048'

debug3: key_read: missing keytype

debug3: load_hostkeys: found key type RSA1 in file /home/htodd/openssh/regress/known_hosts:2

debug3: load_hostkeys: loaded 2 keys

debug3: load_hostkeys: loading entries for host "localhost-with-alias" from file "/home/htodd/openssh/regress/known_hosts"

debug3: load_hostkeys: found key type RSA in file /home/htodd/openssh/regress/known_hosts:1

debug2: key_type_from_name: unknown key type '2048'

debug3: key_read: missing keytype

debug3: load_hostkeys: found key type RSA1 in file /home/htodd/openssh/regress/known_hosts:2

debug3: load_hostkeys: loaded 2 keys

debug1: Host 'localhost-with-alias' is known and matches the RSA1 host key.

debug1: Found key in /home/htodd/openssh/regress/known_hosts:2

debug1: Encryption type: 3des

debug1: Sent encrypted session key.

debug2: cipher_init: set keylen (16 -> 32)

debug2: cipher_init: set keylen (16 -> 32)

debug1: Installing crc compensation attack detector.

debug1: Received encrypted confirmation.

debug1: Trying RSA authentication with key '/home/htodd/openssh/regress/rsa1'

debug1: Received RSA challenge from server.

debug1: Sending response to host key RSA challenge.

debug1: Remote: RSA authentication accepted.

debug1: RSA authentication accepted by server.

Authenticated to 127.0.0.1 (via proxy).

debug1: Sending command: exec sh -c 'sleep 2; exec > /dev/null 2>&1; sleep 3; exit 0'

debug1: Entering interactive session.

debug1: Sending eof.

Killed by signal 2.

FATAL:

trace: test remote exit status: proto 1 status 0
debug1: Executing proxy command: exec sh /home/htodd/openssh/regress/sshd-log-wrapper.sh /home/htodd/openssh/sshd /home/htodd/openssh/regress/sshd.log -i -f /home/htodd/openssh/regress/sshd_proxy

debug3: Incorrect RSA1 identifier

debug3: Could not load "/home/htodd/openssh/regress/rsa" as a RSA1 public key

debug1: identity file /home/htodd/openssh/regress/rsa type 1

debug1: identity file /home/htodd/openssh/regress/rsa-cert type -1

debug1: identity file /home/htodd/openssh/regress/rsa1 type 0

debug1: identity file /home/htodd/openssh/regress/rsa1-cert type -1

debug1: permanently_drop_suid: 1000

debug1: Remote protocol version 1.99, remote software version OpenSSH_6.5

debug1: match: OpenSSH_6.5 pat OpenSSH* compat 0x04000000

debug1: Local version string SSH-1.5-OpenSSH_6.5

debug2: fd 6 setting O_NONBLOCK

debug2: fd 5 setting O_NONBLOCK

debug1: Waiting for server public key.

debug1: Received server public key (1024 bits) and host key (2048 bits).

debug1: Server host key: RSA1 fe:d0:cf:47:30:46:c1:1f:55:e5:4e:60:2a:9f:1d:3b

debug1: using hostkeyalias: localhost-with-alias

debug3: load_hostkeys: loading entries for host "localhost-with-alias" from file "/home/htodd/openssh/regress/known_hosts"

debug3: load_hostkeys: found key type RSA in file /home/htodd/openssh/regress/known_hosts:1

debug2: key_type_from_name: unknown key type '2048'

debug3: key_read: missing keytype

debug3: load_hostkeys: found key type RSA1 in file /home/htodd/openssh/regress/known_hosts:2

debug3: load_hostkeys: loaded 2 keys

debug3: load_hostkeys: loading entries for host "localhost-with-alias" from file "/home/htodd/openssh/regress/known_hosts"

debug3: load_hostkeys: found key type RSA in file /home/htodd/openssh/regress/known_hosts:1

debug2: key_type_from_name: unknown key type '2048'

debug3: key_read: missing keytype

debug3: load_hostkeys: found key type RSA1 in file /home/htodd/openssh/regress/known_hosts:2

debug3: load_hostkeys: loaded 2 keys

debug1: Host 'localhost-with-alias' is known and matches the RSA1 host key.

debug1: Found key in /home/htodd/openssh/regress/known_hosts:2

debug1: Encryption type: 3des

debug1: Sent encrypted session key.

debug2: cipher_init: set keylen (16 -> 32)

debug2: cipher_init: set keylen (16 -> 32)

debug1: Installing crc compensation attack detector.

debug1: Received encrypted confirmation.

debug1: Trying RSA authentication with key '/home/htodd/openssh/regress/rsa1'

debug1: Received RSA challenge from server.

debug1: Sending response to host key RSA challenge.

debug1: Remote: RSA authentication accepted.

debug1: RSA authentication accepted by server.

Authenticated to 127.0.0.1 (via proxy).

debug1: Sending command: exit 0

debug1: Entering interactive session.

debug2: fd 0 setting O_NONBLOCK

debug1: fd 0 clearing O_NONBLOCK

Transferred: sent 1202, received 804 bytes, in 0.0 seconds

Bytes per second: sent 78800.1, received 52708.2

debug1: Exit status 0

debug1: Executing proxy command: exec sh /home/htodd/openssh/regress/sshd-log-wrapper.sh /home/htodd/openssh/sshd /home/htodd/openssh/regress/sshd.log -i -f /home/htodd/openssh/regress/sshd_proxy

debug3: Incorrect RSA1 identifier

debug3: Could not load "/home/htodd/openssh/regress/rsa" as a RSA1 public key

debug1: permanently_drop_suid: 1000

debug1: identity file /home/htodd/openssh/regress/rsa type 1

debug1: identity file /home/htodd/openssh/regress/rsa-cert type -1

debug1: identity file /home/htodd/openssh/regress/rsa1 type 0

debug1: identity file /home/htodd/openssh/regress/rsa1-cert type -1

debug1: Remote protocol version 1.99, remote software version OpenSSH_6.5

debug1: match: OpenSSH_6.5 pat OpenSSH* compat 0x04000000

debug1: Local version string SSH-1.5-OpenSSH_6.5

debug2: fd 6 setting O_NONBLOCK

debug2: fd 5 setting O_NONBLOCK

debug1: Waiting for server public key.

debug1: Received server public key (1024 bits) and host key (2048 bits).

debug1: Server host key: RSA1 fe:d0:cf:47:30:46:c1:1f:55:e5:4e:60:2a:9f:1d:3b

debug1: using hostkeyalias: localhost-with-alias

debug3: load_hostkeys: loading entries for host "localhost-with-alias" from file "/home/htodd/openssh/regress/known_hosts"

debug3: load_hostkeys: found key type RSA in file /home/htodd/openssh/regress/known_hosts:1

debug2: key_type_from_name: unknown key type '2048'

debug3: key_read: missing keytype

debug3: load_hostkeys: found key type RSA1 in file /home/htodd/openssh/regress/known_hosts:2

debug3: load_hostkeys: loaded 2 keys

debug3: load_hostkeys: loading entries for host "localhost-with-alias" from file "/home/htodd/openssh/regress/known_hosts"

debug3: load_hostkeys: found key type RSA in file /home/htodd/openssh/regress/known_hosts:1

debug2: key_type_from_name: unknown key type '2048'

debug3: key_read: missing keytype

debug3: load_hostkeys: found key type RSA1 in file /home/htodd/openssh/regress/known_hosts:2

debug3: load_hostkeys: loaded 2 keys

debug1: Host 'localhost-with-alias' is known and matches the RSA1 host key.

debug1: Found key in /home/htodd/openssh/regress/known_hosts:2

debug1: Encryption type: 3des

debug1: Sent encrypted session key.

debug2: cipher_init: set keylen (16 -> 32)

debug2: cipher_init: set keylen (16 -> 32)

debug1: Installing crc compensation attack detector.

debug1: Received encrypted confirmation.

debug1: Trying RSA authentication with key '/home/htodd/openssh/regress/rsa1'

debug1: Received RSA challenge from server.

debug1: Sending response to host key RSA challenge.

debug1: Remote: RSA authentication accepted.

debug1: RSA authentication accepted by server.

Authenticated to 127.0.0.1 (via proxy).

debug1: Sending command: exec sh -c 'sleep 2; exec > /dev/null 2>&1; sleep 3; exit 0'

debug1: Entering interactive session.

debug1: Sending eof.

Killed by signal 2.

FATAL:
FAIL:

trace: generate keys
FATAL: sshd_proxy broken

trace: generate keys
FATAL: sshd_proxy broken
FAIL: sshd_proxy broken

trace: generate keys
FATAL: sshd_proxy broken

trace: generate keys
FATAL: sshd_proxy broken
FAIL: sshd_proxy broken

trace: scp: simple copy remote file to local file
FATAL:

trace: scp: simple copy remote file to local file
FATAL:
FAIL:

-------------- next part --------------
trace: generate keys
FATAL: sshd_proxy broken

trace: generate keys
FATAL: sshd_proxy broken
FAIL: sshd_proxy broken

trace: scp: simple copy remote file to local file
FATAL:

trace: scp: simple copy remote file to local file
FATAL:
FAIL:

trace: test remote exit status: proto 1 status 0
FATAL:

trace: test remote exit status: proto 1 status 0
FATAL:
FAIL:

trace: generate keys
FATAL: sshd_proxy broken

trace: generate keys
FATAL: sshd_proxy broken
FAIL: sshd_proxy broken

trace: generate keys
FATAL: sshd_proxy broken

trace: generate keys
FATAL: sshd_proxy broken
FAIL: sshd_proxy broken

trace: scp: simple copy remote file to local file
FATAL:

trace: scp: simple copy remote file to local file
FATAL:
FAIL:


From dtucker at zip.com.au  Thu Jan 23 14:38:41 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 23 Jan 2014 14:38:41 +1100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.NEB.2.11.1401221924480.330@chris.i8u.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <alpine.NEB.2.11.1401221509590.330@chris.i8u.org>
 <CALDDTe38x1aLoFKB1AvbkEU65ueD3cWB5Jv-_Dhas29=x75f3g@mail.gmail.com>
 <alpine.NEB.2.11.1401221526120.330@chris.i8u.org>
 <CALDDTe2qYO1_haF6VD4=phE7+2AvJ1BS5Za6cpW53KtqN6C2Tw@mail.gmail.com>
 <alpine.NEB.2.11.1401221539450.330@chris.i8u.org>
 <CALDDTe2jM48Kn_ovy+cAq2d7Y=p=KjX4n8iv+Rd2c3m_9UaoWA@mail.gmail.com>
 <alpine.NEB.2.11.1401221555310.330@chris.i8u.org>
 <CALDDTe0R7+z8UgrbvW+MbEEp77y15OgRX4fPETj=hZ+nfO++_A@mail.gmail.com>
 <alpine.NEB.2.11.1401221704550.330@chris.i8u.org>
 <alpine.NEB.2.11.1401221712230.330@chris.i8u.org>
 <CALDDTe1e490W6CVxF2PgNstswQf0yJsPBun_8qBUBsstzQ8s5A@mail.gmail.com>
 <alpine.NEB.2.11.1401221920160.330@chris.i8u.org>
 <alpine.NEB.2.11.1401221924480.330@chris.i8u.org>
Message-ID: <CALDDTe3ue_ne9CJsZmuFmv-FveQvUtm1XnNEEr6eb2ZtxVkehQ@mail.gmail.com>

On Thu, Jan 23, 2014 at 2:25 PM, Hisashi T Fujinaka <htodd at twofifty.com> wrote:
> On Wed, 22 Jan 2014, Hisashi T Fujinaka wrote:
>> On Thu, 23 Jan 2014, Darren Tucker wrote:
[...]
>>> ../../configure --with-cflags=-DBROKEN_STRNVIS && make clean && make
>>> tests
>>
>>
>> I gave up on the file copy and here are the three fail logs.

"Killed by signal 2."

that's SIGINT.  Was it working correctly, and did you ctrl-C'ed it?

> Oh, I may have made a mistake. Is the git version the portable version?

https://anongit.mindrot.org/openssh.git/ is the portable version.

-- 
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 htodd at twofifty.com  Thu Jan 23 14:41:25 2014
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Wed, 22 Jan 2014 19:41:25 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <CALDDTe3ue_ne9CJsZmuFmv-FveQvUtm1XnNEEr6eb2ZtxVkehQ@mail.gmail.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <alpine.NEB.2.11.1401221509590.330@chris.i8u.org>
 <CALDDTe38x1aLoFKB1AvbkEU65ueD3cWB5Jv-_Dhas29=x75f3g@mail.gmail.com>
 <alpine.NEB.2.11.1401221526120.330@chris.i8u.org>
 <CALDDTe2qYO1_haF6VD4=phE7+2AvJ1BS5Za6cpW53KtqN6C2Tw@mail.gmail.com>
 <alpine.NEB.2.11.1401221539450.330@chris.i8u.org>
 <CALDDTe2jM48Kn_ovy+cAq2d7Y=p=KjX4n8iv+Rd2c3m_9UaoWA@mail.gmail.com>
 <alpine.NEB.2.11.1401221555310.330@chris.i8u.org>
 <CALDDTe0R7+z8UgrbvW+MbEEp77y15OgRX4fPETj=hZ+nfO++_A@mail.gmail.com>
 <alpine.NEB.2.11.1401221704550.330@chris.i8u.org>
 <alpine.NEB.2.11.1401221712230.330@chris.i8u.org>
 <CALDDTe1e490W6CVxF2PgNstswQf0yJsPBun_8qBUBsstzQ8s5A@mail.gmail.com>
 <alpine.NEB.2.11.1401221920160.330@chris.i8u.org>
 <alpine.NEB.2.11.1401221924480.330@chris.i8u.org>
 <CALDDTe3ue_ne9CJsZmuFmv-FveQvUtm1XnNEEr6eb2ZtxVkehQ@mail.gmail.com>
Message-ID: <alpine.NEB.2.11.1401221940481.330@chris.i8u.org>

On Thu, 23 Jan 2014, Darren Tucker wrote:

> On Thu, Jan 23, 2014 at 2:25 PM, Hisashi T Fujinaka <htodd at twofifty.com> wrote:
>> On Wed, 22 Jan 2014, Hisashi T Fujinaka wrote:
>>> On Thu, 23 Jan 2014, Darren Tucker wrote:
> [...]
>>>> ../../configure --with-cflags=-DBROKEN_STRNVIS && make clean && make
>>>> tests
>>>
>>>
>>> I gave up on the file copy and here are the three fail logs.
>
> "Killed by signal 2."
>
> that's SIGINT.  Was it working correctly, and did you ctrl-C'ed it?

I gave up after waiting 15 minutes. The OSX version didn't take that
long so I thought it was hung.

>> Oh, I may have made a mistake. Is the git version the portable version?
>
> https://anongit.mindrot.org/openssh.git/ is the portable version.

Yep. That's the one I have.

-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

From loganaden at gmail.com  Thu Jan 23 15:14:44 2014
From: loganaden at gmail.com (Loganaden Velvindron)
Date: Thu, 23 Jan 2014 08:14:44 +0400
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <87a9enlm23.fsf@zoth-ommog.unzane.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <87a9enlm23.fsf@zoth-ommog.unzane.com>
Message-ID: <CAOp4FwR4H=5zPcbddDrc3KXpQC_iqekjVNpNe4BxND0hOH0+kQ@mail.gmail.com>

On Thu, Jan 23, 2014 at 1:54 AM, Gerald Turner <gturner at unzane.com> wrote:
> Damien Miller <djm at mindrot.org> writes:
>> Running the regression tests supplied with Portable OpenSSH does not
>> require installation and is a simply:
>>
>> $ ./configure && make tests
>
> Tested openssh-SNAP-20140123 on Debian jessie/testing amd64 with OpenSSL
> 1.0.1f on two machines (one with AES-NI instructions), all tests passed
> and no warnings.
>
>>  * ssh(1), sshd(8): Add support for Ed25519 as a public key type.
>>    Ed25519 is a elliptic curve signature scheme that offers
>>    better security than ECDSA and DSA and good performance. It may be
>>    used for both user and host keys.
>
> Is there SSHFP support for Ed25519?  I suppose not - looks like it would
> need Internet Drafts equivalent to RFC6090 (ECDSA) and RFC6594 (SSHFP).
> Currently Curve25519 has an I-D but not for Ed25519:

A draft for sshfp is being worked on.

>
> http://datatracker.ietf.org/doc/draft-josefsson-tls-curve25519/
>
>   ?This document only describes usage of additional curves for ephemeral
>    key exchange (ECDHE), not for use with long-term keys embedded in
>    PKIX certificates (ECDH_RSA and ECDH_ECDSA).  This is because
>    Curve25519 is not directly suitable for authentication with ECDSA,
>    and thus not applicable for signing of e.g.  PKIX certificates.?
>
> --
> Gerald Turner   Email: gturner at unzane.com   JID: gturner at unzane.com
> GPG: 0xFA8CD6D5  21D9 B2E8 7FE7 F19E 5F7D  4D0C 3FA0 810F FA8C D6D5
>
> _______________________________________________
> 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 nicholas.marriott at gmail.com  Thu Jan 23 19:33:03 2014
From: nicholas.marriott at gmail.com (Nicholas Marriott)
Date: Thu, 23 Jan 2014 08:33:03 +0000
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <CALDDTe1e490W6CVxF2PgNstswQf0yJsPBun_8qBUBsstzQ8s5A@mail.gmail.com>
References: <CALDDTe38x1aLoFKB1AvbkEU65ueD3cWB5Jv-_Dhas29=x75f3g@mail.gmail.com>
 <alpine.NEB.2.11.1401221526120.330@chris.i8u.org>
 <CALDDTe2qYO1_haF6VD4=phE7+2AvJ1BS5Za6cpW53KtqN6C2Tw@mail.gmail.com>
 <alpine.NEB.2.11.1401221539450.330@chris.i8u.org>
 <CALDDTe2jM48Kn_ovy+cAq2d7Y=p=KjX4n8iv+Rd2c3m_9UaoWA@mail.gmail.com>
 <alpine.NEB.2.11.1401221555310.330@chris.i8u.org>
 <CALDDTe0R7+z8UgrbvW+MbEEp77y15OgRX4fPETj=hZ+nfO++_A@mail.gmail.com>
 <alpine.NEB.2.11.1401221704550.330@chris.i8u.org>
 <alpine.NEB.2.11.1401221712230.330@chris.i8u.org>
 <CALDDTe1e490W6CVxF2PgNstswQf0yJsPBun_8qBUBsstzQ8s5A@mail.gmail.com>
Message-ID: <20140123083303.GI11155@yelena.nicm.ath.cx>

Hi

When NetBSD added strnvis they swapped around the argument order.

On OpenBSD:

int     strnvis(char *, const char *, size_t, int)

On NetBSD:

int     strnvis(char *, size_t, const char *, int);

Don't ask me why.


On Thu, Jan 23, 2014 at 12:56:48PM +1100, Darren Tucker wrote:
> On Thu, Jan 23, 2014 at 12:13 PM, Hisashi T Fujinaka <htodd at twofifty.com> wrote:
> > #1  0x00007f7ff62a11f8 in strnvis (mbdst=<optimized out>,
> > dlen=140187732525536, mbsrc=<optimized out>, flags=<optimized out>)
> >     at /usr/src/lib/libc/gen/vis.c:655
> 
> strnvis?  interesting.   Could you please try:
> 
> ../../configure --with-cflags=-DBROKEN_STRNVIS && make clean && make tests
> 
> Thanks.
> 
> -- 
> Darren Tucker (dtucker at zip.com.au)
> GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
>     Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From dtucker at zip.com.au  Thu Jan 23 22:22:51 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 23 Jan 2014 22:22:51 +1100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <20140123083303.GI11155@yelena.nicm.ath.cx>
References: <alpine.NEB.2.11.1401221526120.330@chris.i8u.org>
 <CALDDTe2qYO1_haF6VD4=phE7+2AvJ1BS5Za6cpW53KtqN6C2Tw@mail.gmail.com>
 <alpine.NEB.2.11.1401221539450.330@chris.i8u.org>
 <CALDDTe2jM48Kn_ovy+cAq2d7Y=p=KjX4n8iv+Rd2c3m_9UaoWA@mail.gmail.com>
 <alpine.NEB.2.11.1401221555310.330@chris.i8u.org>
 <CALDDTe0R7+z8UgrbvW+MbEEp77y15OgRX4fPETj=hZ+nfO++_A@mail.gmail.com>
 <alpine.NEB.2.11.1401221704550.330@chris.i8u.org>
 <alpine.NEB.2.11.1401221712230.330@chris.i8u.org>
 <CALDDTe1e490W6CVxF2PgNstswQf0yJsPBun_8qBUBsstzQ8s5A@mail.gmail.com>
 <20140123083303.GI11155@yelena.nicm.ath.cx>
Message-ID: <20140123112251.GA19903@gate.dtucker.net>

On Thu, Jan 23, 2014 at 08:33:03AM +0000, Nicholas Marriott wrote:
> Hi
> 
> When NetBSD added strnvis they swapped around the argument order.
> 
> On OpenBSD:
> int     strnvis(char *, const char *, size_t, int)
> 
> On NetBSD:
> int     strnvis(char *, size_t, const char *, int);
> 
> Don't ask me why.

Sigh.  FreeBSD too.  Seriously guys?  The OpenBSD usage predates both
by >10 years.

http://www.freebsd.org/cgi/man.cgi?query=strnvis&sektion=3&n=1
"strnvis() [...] appeared in and[sic] FreeBSD 9.2."

http://gnats.netbsd.org/cgi-bin/query-pr-single.pl?number=44977
http://netbsd.gw.com/cgi-bin/man-cgi?strnvis++NetBSD-current
"strnvis(), [...] appeared in NetBSD 6.0"

http://www.openbsd.org/cgi-bin/man.cgi?query=strnvis&sektion=3
"The strnvis() function first appeared in OpenBSD 2.9".

For those keeping score, OpenBSD 2.9 was in 2001, NetBSD 6.0 was 2012 and
FreeBSD 9.2 was 2013.

Index: configure.ac
===================================================================
RCS file: /var/cvs/openssh/configure.ac,v
retrieving revision 1.558
diff -u -p -r1.558 configure.ac
--- configure.ac	22 Jan 2014 10:30:13 -0000	1.558
+++ configure.ac	23 Jan 2014 10:58:47 -0000
@@ -769,6 +769,8 @@ mips-sony-bsd|mips-sony-newsos4)
 	AC_DEFINE([SSH_TUN_PREPEND_AF], [1],
 	    [Prepend the address family to IP tunnel traffic])
 	TEST_MALLOC_OPTIONS="AJRX"
+	AC_DEFINE([BROKEN_STRNVIS], [1],
+	    [NetBSD strnvis argument order is swapped compared to OpenBSD])
 	;;
 *-*-freebsd*)
 	check_for_libcrypt_later=1
@@ -777,7 +779,8 @@ mips-sony-bsd|mips-sony-newsos4)
 	AC_CHECK_HEADER([net/if_tap.h], ,
 	    AC_DEFINE([SSH_TUN_NO_L2], [1], [No layer 2 tunnel support]))
 	AC_DEFINE([BROKEN_GLOB], [1], [FreeBSD glob does not do what we need])
-	 AC_DEFINE([BROKEN_STRNVIS], [1], [FreeBSD strnvis does not do what we need])
+	 AC_DEFINE([BROKEN_STRNVIS], [1],
+	    [FreeBSD strnvis argument order is swapped compared to OpenBSD])
 	TEST_MALLOC_OPTIONS="AJRX"
 	;;
 *-*-bsdi*)

-- 
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  Thu Jan 23 23:02:36 2014
From: djm at mindrot.org (Damien Miller)
Date: Thu, 23 Jan 2014 23:02:36 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <20140123112251.GA19903@gate.dtucker.net>
References: <alpine.NEB.2.11.1401221526120.330@chris.i8u.org>
 <CALDDTe2qYO1_haF6VD4=phE7+2AvJ1BS5Za6cpW53KtqN6C2Tw@mail.gmail.com>
 <alpine.NEB.2.11.1401221539450.330@chris.i8u.org>
 <CALDDTe2jM48Kn_ovy+cAq2d7Y=p=KjX4n8iv+Rd2c3m_9UaoWA@mail.gmail.com>
 <alpine.NEB.2.11.1401221555310.330@chris.i8u.org>
 <CALDDTe0R7+z8UgrbvW+MbEEp77y15OgRX4fPETj=hZ+nfO++_A@mail.gmail.com>
 <alpine.NEB.2.11.1401221704550.330@chris.i8u.org>
 <alpine.NEB.2.11.1401221712230.330@chris.i8u.org>
 <CALDDTe1e490W6CVxF2PgNstswQf0yJsPBun_8qBUBsstzQ8s5A@mail.gmail.com>
 <20140123083303.GI11155@yelena.nicm.ath.cx>
 <20140123112251.GA19903@gate.dtucker.net>
Message-ID: <alpine.BSO.2.11.1401232253070.14832@natsu.mindrot.org>

On Thu, 23 Jan 2014, Darren Tucker wrote:

> On Thu, Jan 23, 2014 at 08:33:03AM +0000, Nicholas Marriott wrote:
> > Hi
> > 
> > When NetBSD added strnvis they swapped around the argument order.
> > 
> > On OpenBSD:
> > int     strnvis(char *, const char *, size_t, int)
> > 
> > On NetBSD:
> > int     strnvis(char *, size_t, const char *, int);
> > 
> > Don't ask me why.
> 
> Sigh.  FreeBSD too.  Seriously guys?  The OpenBSD usage predates both
> by >10 years.

I get that the OpenBSD argument order is arguably a bit inconsistent
with other string functions (though hardly the worst wart in libc), but
the solution to this is either grudingly accept it or to import strnvis
_under a different name_, not to import it but silently introduce a
gaping, idiotic incompatibility that yields silent string corruption at
best, crashes in all likelihood and exploitable stack/heap overflows at
worst.

> For those keeping score, OpenBSD 2.9 was in 2001, NetBSD 6.0 was 2012 and
> FreeBSD 9.2 was 2013.

ok djm, for lack of a time machine and cluebat

> Index: configure.ac
> ===================================================================
> RCS file: /var/cvs/openssh/configure.ac,v
> retrieving revision 1.558
> diff -u -p -r1.558 configure.ac
> --- configure.ac	22 Jan 2014 10:30:13 -0000	1.558
> +++ configure.ac	23 Jan 2014 10:58:47 -0000
> @@ -769,6 +769,8 @@ mips-sony-bsd|mips-sony-newsos4)
>  	AC_DEFINE([SSH_TUN_PREPEND_AF], [1],
>  	    [Prepend the address family to IP tunnel traffic])
>  	TEST_MALLOC_OPTIONS="AJRX"
> +	AC_DEFINE([BROKEN_STRNVIS], [1],
> +	    [NetBSD strnvis argument order is swapped compared to OpenBSD])
>  	;;
>  *-*-freebsd*)
>  	check_for_libcrypt_later=1
> @@ -777,7 +779,8 @@ mips-sony-bsd|mips-sony-newsos4)
>  	AC_CHECK_HEADER([net/if_tap.h], ,
>  	    AC_DEFINE([SSH_TUN_NO_L2], [1], [No layer 2 tunnel support]))
>  	AC_DEFINE([BROKEN_GLOB], [1], [FreeBSD glob does not do what we need])
> -	 AC_DEFINE([BROKEN_STRNVIS], [1], [FreeBSD strnvis does not do what we need])
> +	 AC_DEFINE([BROKEN_STRNVIS], [1],
> +	    [FreeBSD strnvis argument order is swapped compared to OpenBSD])
>  	TEST_MALLOC_OPTIONS="AJRX"
>  	;;
>  *-*-bsdi*)
> 
> -- 
> Darren Tucker (dtucker at zip.com.au)
> GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
>     Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

From htodd at twofifty.com  Fri Jan 24 03:24:41 2014
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Thu, 23 Jan 2014 08:24:41 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <20140123112251.GA19903@gate.dtucker.net>
References: <alpine.NEB.2.11.1401221526120.330@chris.i8u.org>
 <CALDDTe2qYO1_haF6VD4=phE7+2AvJ1BS5Za6cpW53KtqN6C2Tw@mail.gmail.com>
 <alpine.NEB.2.11.1401221539450.330@chris.i8u.org>
 <CALDDTe2jM48Kn_ovy+cAq2d7Y=p=KjX4n8iv+Rd2c3m_9UaoWA@mail.gmail.com>
 <alpine.NEB.2.11.1401221555310.330@chris.i8u.org>
 <CALDDTe0R7+z8UgrbvW+MbEEp77y15OgRX4fPETj=hZ+nfO++_A@mail.gmail.com>
 <alpine.NEB.2.11.1401221704550.330@chris.i8u.org>
 <alpine.NEB.2.11.1401221712230.330@chris.i8u.org>
 <CALDDTe1e490W6CVxF2PgNstswQf0yJsPBun_8qBUBsstzQ8s5A@mail.gmail.com>
 <20140123083303.GI11155@yelena.nicm.ath.cx>
 <20140123112251.GA19903@gate.dtucker.net>
Message-ID: <alpine.NEB.2.11.1401230759450.330@chris.i8u.org>

On Thu, 23 Jan 2014, Darren Tucker wrote:

> For those keeping score, OpenBSD 2.9 was in 2001, NetBSD 6.0 was 2012 and
> FreeBSD 9.2 was 2013.
>
> Index: configure.ac
> ===================================================================
> RCS file: /var/cvs/openssh/configure.ac,v
> retrieving revision 1.558
> diff -u -p -r1.558 configure.ac
> --- configure.ac	22 Jan 2014 10:30:13 -0000	1.558
> +++ configure.ac	23 Jan 2014 10:58:47 -0000
> @@ -769,6 +769,8 @@ mips-sony-bsd|mips-sony-newsos4)
> 	AC_DEFINE([SSH_TUN_PREPEND_AF], [1],
> 	    [Prepend the address family to IP tunnel traffic])
> 	TEST_MALLOC_OPTIONS="AJRX"
> +	AC_DEFINE([BROKEN_STRNVIS], [1],
> +	    [NetBSD strnvis argument order is swapped compared to OpenBSD])
> 	;;
> *-*-freebsd*)
> 	check_for_libcrypt_later=1
> @@ -777,7 +779,8 @@ mips-sony-bsd|mips-sony-newsos4)
> 	AC_CHECK_HEADER([net/if_tap.h], ,
> 	    AC_DEFINE([SSH_TUN_NO_L2], [1], [No layer 2 tunnel support]))
> 	AC_DEFINE([BROKEN_GLOB], [1], [FreeBSD glob does not do what we need])
> -	 AC_DEFINE([BROKEN_STRNVIS], [1], [FreeBSD strnvis does not do what we need])
> +	 AC_DEFINE([BROKEN_STRNVIS], [1],
> +	    [FreeBSD strnvis argument order is swapped compared to OpenBSD])
> 	TEST_MALLOC_OPTIONS="AJRX"
> 	;;
> *-*-bsdi*)

So I did a git pull and I'm trying again. It appears to be getting
farther and right now I'm waiting for "scp: simple copy remote file to
local file".

-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

From htodd at twofifty.com  Fri Jan 24 04:17:34 2014
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Thu, 23 Jan 2014 09:17:34 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.NEB.2.11.1401230759450.330@chris.i8u.org>
References: <alpine.NEB.2.11.1401221526120.330@chris.i8u.org>
 <CALDDTe2qYO1_haF6VD4=phE7+2AvJ1BS5Za6cpW53KtqN6C2Tw@mail.gmail.com>
 <alpine.NEB.2.11.1401221539450.330@chris.i8u.org>
 <CALDDTe2jM48Kn_ovy+cAq2d7Y=p=KjX4n8iv+Rd2c3m_9UaoWA@mail.gmail.com>
 <alpine.NEB.2.11.1401221555310.330@chris.i8u.org>
 <CALDDTe0R7+z8UgrbvW+MbEEp77y15OgRX4fPETj=hZ+nfO++_A@mail.gmail.com>
 <alpine.NEB.2.11.1401221704550.330@chris.i8u.org>
 <alpine.NEB.2.11.1401221712230.330@chris.i8u.org>
 <CALDDTe1e490W6CVxF2PgNstswQf0yJsPBun_8qBUBsstzQ8s5A@mail.gmail.com>
 <20140123083303.GI11155@yelena.nicm.ath.cx>
 <20140123112251.GA19903@gate.dtucker.net>
 <alpine.NEB.2.11.1401230759450.330@chris.i8u.org>
Message-ID: <alpine.NEB.2.11.1401230915550.330@chris.i8u.org>

On Thu, 23 Jan 2014, Hisashi T Fujinaka wrote:

> On Thu, 23 Jan 2014, Darren Tucker wrote:
>
>> For those keeping score, OpenBSD 2.9 was in 2001, NetBSD 6.0 was 2012 and
>> FreeBSD 9.2 was 2013.
>> 
>> Index: configure.ac
>> ===================================================================
>> RCS file: /var/cvs/openssh/configure.ac,v
>> retrieving revision 1.558
>> diff -u -p -r1.558 configure.ac
>> --- configure.ac	22 Jan 2014 10:30:13 -0000	1.558
>> +++ configure.ac	23 Jan 2014 10:58:47 -0000
>> @@ -769,6 +769,8 @@ mips-sony-bsd|mips-sony-newsos4)
>> 	AC_DEFINE([SSH_TUN_PREPEND_AF], [1],
>> 	    [Prepend the address family to IP tunnel traffic])
>> 	TEST_MALLOC_OPTIONS="AJRX"
>> +	AC_DEFINE([BROKEN_STRNVIS], [1],
>> +	    [NetBSD strnvis argument order is swapped compared to OpenBSD])
>> 	;;
>> *-*-freebsd*)
>> 	check_for_libcrypt_later=1
>> @@ -777,7 +779,8 @@ mips-sony-bsd|mips-sony-newsos4)
>> 	AC_CHECK_HEADER([net/if_tap.h], ,
>> 	    AC_DEFINE([SSH_TUN_NO_L2], [1], [No layer 2 tunnel support]))
>> 	AC_DEFINE([BROKEN_GLOB], [1], [FreeBSD glob does not do what we 
>> need])
>> -	 AC_DEFINE([BROKEN_STRNVIS], [1], [FreeBSD strnvis does not do what 
>> we need])
>> +	 AC_DEFINE([BROKEN_STRNVIS], [1],
>> +	    [FreeBSD strnvis argument order is swapped compared to OpenBSD])
>> 	TEST_MALLOC_OPTIONS="AJRX"
>> 	;;
>> *-*-bsdi*)
>
> So I did a git pull and I'm trying again. It appears to be getting
> farther and right now I'm waiting for "scp: simple copy remote file to
> local file".

So I've been waiting over an hour. I think I can call it hung. Do you
have any further suggestions for me?

What I did was git pull; autoreconf; ./configure; make clean; make tests

-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

From mancha1 at hush.com  Fri Jan 24 08:40:55 2014
From: mancha1 at hush.com (mancha)
Date: Thu, 23 Jan 2014 21:40:55 +0000 (UTC)
Subject: Call for testing: OpenSSH-6.5
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
Message-ID: <loom.20140123T222341-55@post.gmane.org>

Damien Miller <djm <at> mindrot.org> writes:
> Hi,
> 
> OpenSSH 6.5 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This release contains
> some substantial new features and a number of bugfixes.
> 
> Live testing on suitable non-production systems is also
> appreciated. Please send reports of success or failure to
> openssh-unix-dev <at> mindrot.org.

Hi.

Some results to add to the mix using openssh-SNAP-20140124:

1. System:  Slackware 14.1 (w/ security patches thru 20140123)
   Command: ./configure && make tests
   Result:  all tests passed(*)

   (*) some tests were skipped because:
       -unset "SUDO" variable
       -Slackware doesn't ship a netcat suitable for ProxyCommand
       -no setuid-allowed in regress dir

2. System:  Slackware 14.1 (same as above + port of OpenBSD's nc)
   Command: ./configure && SUDO=/usr/bin/sudo make tests
   Result:  all tests passed(*)
   
   (*) some tests were skipped because:
       -no setuid-allowed in regress dir

Is skipping the compilation of setuid-allowed.c intentional?

Finally, you asked for confirmation from Aris but I thought I'd
share I built an ssh client using libssh 0.6.0 and successfully
connect to SNAP-20140124's sshd using curve255190sha256 at libssh.org
KEX. Interop confirmed.

--mancha





From dtucker at zip.com.au  Fri Jan 24 09:27:12 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 24 Jan 2014 09:27:12 +1100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.NEB.2.11.1401230915550.330@chris.i8u.org>
References: <alpine.NEB.2.11.1401221526120.330@chris.i8u.org>
 <CALDDTe2qYO1_haF6VD4=phE7+2AvJ1BS5Za6cpW53KtqN6C2Tw@mail.gmail.com>
 <alpine.NEB.2.11.1401221539450.330@chris.i8u.org>
 <CALDDTe2jM48Kn_ovy+cAq2d7Y=p=KjX4n8iv+Rd2c3m_9UaoWA@mail.gmail.com>
 <alpine.NEB.2.11.1401221555310.330@chris.i8u.org>
 <CALDDTe0R7+z8UgrbvW+MbEEp77y15OgRX4fPETj=hZ+nfO++_A@mail.gmail.com>
 <alpine.NEB.2.11.1401221704550.330@chris.i8u.org>
 <alpine.NEB.2.11.1401221712230.330@chris.i8u.org>
 <CALDDTe1e490W6CVxF2PgNstswQf0yJsPBun_8qBUBsstzQ8s5A@mail.gmail.com>
 <20140123083303.GI11155@yelena.nicm.ath.cx>
 <20140123112251.GA19903@gate.dtucker.net>
 <alpine.NEB.2.11.1401230759450.330@chris.i8u.org>
 <alpine.NEB.2.11.1401230915550.330@chris.i8u.org>
Message-ID: <CALDDTe2EMsCGBaCXqXCyCmqPJ4+12WM4Ybg=vsxRnDyi8ZKeoA@mail.gmail.com>

On Fri, Jan 24, 2014 at 4:17 AM, Hisashi T Fujinaka <htodd at twofifty.com> wrote:
> So I've been waiting over an hour. I think I can call it hung. Do you
> have any further suggestions for me?

Yeah, it's hung.  It should complete in <1min.

> What I did was git pull; autoreconf; ./configure; make clean; make tests

That command line looks right.  If you want to run a specific test you
can use "make tests LTESTS=scp" to skip the other tests.

The only other thing I can suggest is, while it's in the hung state,
grab copies of ssh.log, sshd.log and regress.log then run strace -p on
the two scp processes, ssh and sshd.  Maybe that'll show what it's
waiting for.

I'm in the process of installing a VM to attempt to reproduce it but
got held up by http://gnats.netbsd.org/44069.  I got past that but now
it panics when I try to bring up the network interface.  If I can get
the VM up and reproduce it then I'll try to diagnose locally.

Thanks.

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

From htodd at twofifty.com  Fri Jan 24 09:47:31 2014
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Thu, 23 Jan 2014 14:47:31 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <CALDDTe2EMsCGBaCXqXCyCmqPJ4+12WM4Ybg=vsxRnDyi8ZKeoA@mail.gmail.com>
References: <alpine.NEB.2.11.1401221526120.330@chris.i8u.org>
 <CALDDTe2qYO1_haF6VD4=phE7+2AvJ1BS5Za6cpW53KtqN6C2Tw@mail.gmail.com>
 <alpine.NEB.2.11.1401221539450.330@chris.i8u.org>
 <CALDDTe2jM48Kn_ovy+cAq2d7Y=p=KjX4n8iv+Rd2c3m_9UaoWA@mail.gmail.com>
 <alpine.NEB.2.11.1401221555310.330@chris.i8u.org>
 <CALDDTe0R7+z8UgrbvW+MbEEp77y15OgRX4fPETj=hZ+nfO++_A@mail.gmail.com>
 <alpine.NEB.2.11.1401221704550.330@chris.i8u.org>
 <alpine.NEB.2.11.1401221712230.330@chris.i8u.org>
 <CALDDTe1e490W6CVxF2PgNstswQf0yJsPBun_8qBUBsstzQ8s5A@mail.gmail.com>
 <20140123083303.GI11155@yelena.nicm.ath.cx>
 <20140123112251.GA19903@gate.dtucker.net>
 <alpine.NEB.2.11.1401230759450.330@chris.i8u.org>
 <alpine.NEB.2.11.1401230915550.330@chris.i8u.org>
 <CALDDTe2EMsCGBaCXqXCyCmqPJ4+12WM4Ybg=vsxRnDyi8ZKeoA@mail.gmail.com>
Message-ID: <alpine.NEB.2.11.1401231444260.330@chris.i8u.org>

On Fri, 24 Jan 2014, Darren Tucker wrote:

> On Fri, Jan 24, 2014 at 4:17 AM, Hisashi T Fujinaka <htodd at twofifty.com> wrote:
>> So I've been waiting over an hour. I think I can call it hung. Do you
>> have any further suggestions for me?
>
> Yeah, it's hung.  It should complete in <1min.
>
>> What I did was git pull; autoreconf; ./configure; make clean; make tests
>
> That command line looks right.  If you want to run a specific test you
> can use "make tests LTESTS=scp" to skip the other tests.
>
> The only other thing I can suggest is, while it's in the hung state,
> grab copies of ssh.log, sshd.log and regress.log then run strace -p on
> the two scp processes, ssh and sshd.  Maybe that'll show what it's
> waiting for.
>
> I'm in the process of installing a VM to attempt to reproduce it but
> got held up by http://gnats.netbsd.org/44069.  I got past that but now
> it panics when I try to bring up the network interface.  If I can get
> the VM up and reproduce it then I'll try to diagnose locally.

Cool, thanks. Let me know if there's anything else I can do on my end.
I'll be poking around in the processes.

-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

From htodd at twofifty.com  Fri Jan 24 10:15:11 2014
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Thu, 23 Jan 2014 15:15:11 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.NEB.2.11.1401231444260.330@chris.i8u.org>
References: <alpine.NEB.2.11.1401221526120.330@chris.i8u.org>
 <CALDDTe2qYO1_haF6VD4=phE7+2AvJ1BS5Za6cpW53KtqN6C2Tw@mail.gmail.com>
 <alpine.NEB.2.11.1401221539450.330@chris.i8u.org>
 <CALDDTe2jM48Kn_ovy+cAq2d7Y=p=KjX4n8iv+Rd2c3m_9UaoWA@mail.gmail.com>
 <alpine.NEB.2.11.1401221555310.330@chris.i8u.org>
 <CALDDTe0R7+z8UgrbvW+MbEEp77y15OgRX4fPETj=hZ+nfO++_A@mail.gmail.com>
 <alpine.NEB.2.11.1401221704550.330@chris.i8u.org>
 <alpine.NEB.2.11.1401221712230.330@chris.i8u.org>
 <CALDDTe1e490W6CVxF2PgNstswQf0yJsPBun_8qBUBsstzQ8s5A@mail.gmail.com>
 <20140123083303.GI11155@yelena.nicm.ath.cx>
 <20140123112251.GA19903@gate.dtucker.net>
 <alpine.NEB.2.11.1401230759450.330@chris.i8u.org>
 <alpine.NEB.2.11.1401230915550.330@chris.i8u.org>
 <CALDDTe2EMsCGBaCXqXCyCmqPJ4+12WM4Ybg=vsxRnDyi8ZKeoA@mail.gmail.com>
 <alpine.NEB.2.11.1401231444260.330@chris.i8u.org>
Message-ID: <alpine.NEB.2.11.1401231514290.330@chris.i8u.org>

On Thu, 23 Jan 2014, Hisashi T Fujinaka wrote:

> On Fri, 24 Jan 2014, Darren Tucker wrote:
>
>> On Fri, Jan 24, 2014 at 4:17 AM, Hisashi T Fujinaka <htodd at twofifty.com> 
>> wrote:
>>> So I've been waiting over an hour. I think I can call it hung. Do you
>>> have any further suggestions for me?
>> 
>> Yeah, it's hung.  It should complete in <1min.
>> 
>>> What I did was git pull; autoreconf; ./configure; make clean; make tests
>> 
>> That command line looks right.  If you want to run a specific test you
>> can use "make tests LTESTS=scp" to skip the other tests.
>> 
>> The only other thing I can suggest is, while it's in the hung state,
>> grab copies of ssh.log, sshd.log and regress.log then run strace -p on
>> the two scp processes, ssh and sshd.  Maybe that'll show what it's
>> waiting for.
>> 
>> I'm in the process of installing a VM to attempt to reproduce it but
>> got held up by http://gnats.netbsd.org/44069.  I got past that but now
>> it panics when I try to bring up the network interface.  If I can get
>> the VM up and reproduce it then I'll try to diagnose locally.
>
> Cool, thanks. Let me know if there's anything else I can do on my end.
> I'll be poking around in the processes.

Does this tell you anything?

  21116      1 scp      read(0x3, 0x7f7ff7b20000, 0x8000) = 32768
        "\^?ELF\^B\^A\^A\0\0\0\0\0\0\0\0\0\^B\0>\0\^A\0\0\0pK@\0\0\0\0\0@\0\0\0\0\0\0\0\M-8\M-\\t\0\0\0\0\0\0\0\0\0@\08\0\t\0@\0'"
  21116      1 scp      write(0x6, 0x7f7ff7b20000, 0x8000) = 32768
        "\^?ELF\^B\^A\^A\0\0\0\0\0\0\0\0\0\^B\0>\0\^A\0\0\0pK@\0\0\0\0\0@\0\0\0\0\0\0\0\M-8\M-\\t\0\0\0\0\0\0\0\0\0@\08\0\t\0@\0'"
  21116      1 scp      read(0x3, 0x7f7ff7b20000, 0x8000) = 32768
        "\M^?H\M^I\M-CH\M^E\M-@\^O\M^D\M-=\0\0\0\M^KT$\^D\M^E\M-Rt&\^O\M-6\0\M^D\M-@\^O\M^H\M^M\0\0\0\M^A\M-z\0 \0\0wh\M^C\M-z\^At"
  21116      1 scp      write(0x6, 0x7f7ff7b20000, 0x8000) = 32768
        "\M^?H\M^I\M-CH\M^E\M-@\^O\M^D\M-=\0\0\0\M^KT$\^D\M^E\M-Rt&\^O\M-6\0\M^D\M-@\^O\M^H\M^M\0\0\0\M^A\M-z\0 \0\0wh\M^C\M-z\^At"
  21116      1 scp      read(0x3, 0x7f7ff7b20000, 0x8000) = 32768
        "\0\0\0\M^K}\0H\M^IT$\b\M-h\M-e\M-R\M^?\M^?H\M^KT$\b\M-i\\\M-~\M^?\M^?\M-8\240\^PB\0D\M^Kh\^XE\M^E\M-m\^O\M^D\M-f\M-~\M^?"
  21116      1 scp      write(0x6, 0x7f7ff7b20000, 0x8000) Err#35 EAGAIN
  21116      1 scp      poll(0x7f7fffffc180, 0x1, 0xffffffff) = 1
  21116      1 scp      write(0x6, 0x7f7ff7b20000, 0x8000) = 32768
        "\0\0\0\M^K}\0H\M^IT$\b\M-h\M-e\M-R\M^?\M^?H\M^KT$\b\M-i\\\M-~\M^?\M^?\M-8\240\^PB\0D\M^Kh\^XE\M^E\M-m\^O\M^D\M-f\M-~\M^?"
  21116      1 scp      read(0x3, 0x7f7ff7b20000, 0x8000) = 32768
        "\M-B8I\M^I\M-QI\M-A\M-A?M1\M-JI\M^I\M-QI\M-A\M-i\aM1\M-JI\^A\M-JL\^CT$@I\M^I\M-AI\M-A\M-A\^CH\M^I\M-AH\M-A\M-A-I1\M-IH"
  21116      1 scp      write(0x6, 0x7f7ff7b20000, 0x8000) Err#35 EAGAIN
  21116      1 scp      poll(0x7f7fffffc180, 0x1, 0xffffffff) = 1
  21116      1 scp      write(0x6, 0x7f7ff7b20000, 0x8000) = 32768
        "\M-B8I\M^I\M-QI\M-A\M-A?M1\M-JI\M^I\M-QI\M-A\M-i\aM1\M-JI\^A\M-JL\^CT$@I\M^I\M-AI\M-A\M-A\^CH\M^I\M-AH\M-A\M-A-I1\M-IH"
  21116      1 scp      read(0x3, 0x7f7ff7b20000, 0x8000) = 32768
        "cates are not supported\0%s: legacy ED25519 certificates are not supported\0\0\0\0\0\0\0Certificate invalid: not a host c"
  21116      1 scp      write(0x6, 0x7f7ff7b20000, 0x8000) = 32768
        "cates are not supported\0%s: legacy ED25519 certificates are not supported\0\0\0\0\0\0\0Certificate invalid: not a host c"
  21116      1 scp      read(0x3, 0x7f7ff7b20000, 0x8000) = 32768
        "\^_\0\0\0\M^R\0\0\0\^D\0\0\0\M-F\0\0\0\^E\0\0\0\M-v\0\0\0\M-_\0\0\0\M-!\0\0\0\M-L\0\0\0\^_\0\0\0\M^A\0\0\0\M-u\0\0\0\^N\0"
  21116      1 scp      write(0x6, 0x7f7ff7b20000, 0x8000) = 32768
        "\^_\0\0\0\M^R\0\0\0\^D\0\0\0\M-F\0\0\0\^E\0\0\0\M-v\0\0\0\M-_\0\0\0\M-!\0\0\0\M-L\0\0\0\^_\0\0\0\M^A\0\0\0\M-u\0\0\0\^N\0"
  21116      1 scp      read(0x3, 0x7f7ff7b20000, 0x8000) = 32768
        "\M->\0\0\0i\0\0\0\M^]\0\0\0\M-3\0\0\0\M->\0\0\0\b\0\0\0|\0\0\0*\0\0\0G\0\0\0\b\0\0\0\M-}\0\0\0\M-T\0\0\0\M-M\0\0\0\^N\0\0"
  21116      1 scp      write(0x6, 0x7f7ff7b20000, 0x8000) = 32768
        "\M->\0\0\0i\0\0\0\M^]\0\0\0\M-3\0\0\0\M->\0\0\0\b\0\0\0|\0\0\0*\0\0\0G\0\0\0\b\0\0\0\M-}\0\0\0\M-T\0\0\0\M-M\0\0\0\^N\0\0"
  21116      1 scp      read(0x3, 0x7f7ff7b20000, 0x8000) = 32768
        "\M-V\0\0\0\M-=\0\0\0\M^W\0\0\0z\0\0\0|\0\0\0u\0\0\0\M^F\0\0\0z\0\0\0%\0\0\0Z\0\0\0n\0\0\0|\0\0\0\M-e\0\0\0Q\0\0\0<\0\0\0"
  21116      1 scp      write(0x6, 0x7f7ff7b20000, 0x8000) Err#35 EAGAIN



-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

From djm at mindrot.org  Fri Jan 24 11:04:01 2014
From: djm at mindrot.org (Damien Miller)
Date: Fri, 24 Jan 2014 11:04:01 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.NEB.2.11.1401231514290.330@chris.i8u.org>
References: <alpine.NEB.2.11.1401221526120.330@chris.i8u.org>
 <CALDDTe2qYO1_haF6VD4=phE7+2AvJ1BS5Za6cpW53KtqN6C2Tw@mail.gmail.com>
 <alpine.NEB.2.11.1401221539450.330@chris.i8u.org>
 <CALDDTe2jM48Kn_ovy+cAq2d7Y=p=KjX4n8iv+Rd2c3m_9UaoWA@mail.gmail.com>
 <alpine.NEB.2.11.1401221555310.330@chris.i8u.org>
 <CALDDTe0R7+z8UgrbvW+MbEEp77y15OgRX4fPETj=hZ+nfO++_A@mail.gmail.com>
 <alpine.NEB.2.11.1401221704550.330@chris.i8u.org>
 <alpine.NEB.2.11.1401221712230.330@chris.i8u.org>
 <CALDDTe1e490W6CVxF2PgNstswQf0yJsPBun_8qBUBsstzQ8s5A@mail.gmail.com>
 <20140123083303.GI11155@yelena.nicm.ath.cx>
 <20140123112251.GA19903@gate.dtucker.net>
 <alpine.NEB.2.11.1401230759450.330@chris.i8u.org>
 <alpine.NEB.2.11.1401230915550.330@chris.i8u.org>
 <CALDDTe2EMsCGBaCXqXCyCmqPJ4+12WM4Ybg=vsxRnDyi8ZKeoA@mail.gmail.com>
 <alpine.NEB.2.11.1401231444260.330@chris.i8u.org>
 <alpine.NEB.2.11.1401231514290.330@chris.i8u.org>
Message-ID: <alpine.BSO.2.11.1401241102440.14832@natsu.mindrot.org>

On Thu, 23 Jan 2014, Hisashi T Fujinaka wrote:

> > Cool, thanks. Let me know if there's anything else I can do on my end.
> > I'll be poking around in the processes.
> 
> Does this tell you anything?
> 
[snip]

It looks like it is copying as expected.

You don't happen to be running the tests on a slow NFS filesystem or
similar, do you?

-d

From htodd at twofifty.com  Fri Jan 24 11:05:57 2014
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Thu, 23 Jan 2014 16:05:57 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.11.1401241102440.14832@natsu.mindrot.org>
References: <alpine.NEB.2.11.1401221526120.330@chris.i8u.org>
 <CALDDTe2qYO1_haF6VD4=phE7+2AvJ1BS5Za6cpW53KtqN6C2Tw@mail.gmail.com>
 <alpine.NEB.2.11.1401221539450.330@chris.i8u.org>
 <CALDDTe2jM48Kn_ovy+cAq2d7Y=p=KjX4n8iv+Rd2c3m_9UaoWA@mail.gmail.com>
 <alpine.NEB.2.11.1401221555310.330@chris.i8u.org>
 <CALDDTe0R7+z8UgrbvW+MbEEp77y15OgRX4fPETj=hZ+nfO++_A@mail.gmail.com>
 <alpine.NEB.2.11.1401221704550.330@chris.i8u.org>
 <alpine.NEB.2.11.1401221712230.330@chris.i8u.org>
 <CALDDTe1e490W6CVxF2PgNstswQf0yJsPBun_8qBUBsstzQ8s5A@mail.gmail.com>
 <20140123083303.GI11155@yelena.nicm.ath.cx>
 <20140123112251.GA19903@gate.dtucker.net>
 <alpine.NEB.2.11.1401230759450.330@chris.i8u.org>
 <alpine.NEB.2.11.1401230915550.330@chris.i8u.org>
 <CALDDTe2EMsCGBaCXqXCyCmqPJ4+12WM4Ybg=vsxRnDyi8ZKeoA@mail.gmail.com>
 <alpine.NEB.2.11.1401231444260.330@chris.i8u.org>
 <alpine.NEB.2.11.1401231514290.330@chris.i8u.org>
 <alpine.BSO.2.11.1401241102440.14832@natsu.mindrot.org>
Message-ID: <alpine.NEB.2.11.1401231605330.330@chris.i8u.org>

On Fri, 24 Jan 2014, Damien Miller wrote:

> On Thu, 23 Jan 2014, Hisashi T Fujinaka wrote:
>
>>> Cool, thanks. Let me know if there's anything else I can do on my end.
>>> I'll be poking around in the processes.
>>
>> Does this tell you anything?
>>
> [snip]
>
> It looks like it is copying as expected.
>
> You don't happen to be running the tests on a slow NFS filesystem or
> similar, do you?

No, local SATA disk.

-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

From givemefive at gmail.com  Fri Jan 24 19:20:39 2014
From: givemefive at gmail.com (John)
Date: Fri, 24 Jan 2014 02:20:39 -0600
Subject: Change initial directory based on port of reverse tunnel?
Message-ID: <CALa+F_QOcy-rZamt7+kNKCQCUQdWJSRoShUFdbiTAs_8v5pbxA@mail.gmail.com>

Hello

I'm  trying to create compatibility with an automated system that I do
not have control over and cannot change. The system was built to
connect to individual embedded linux machines that create reverse
tunnels back to a server.

These tunnels take the form:
/bin/ssh -i /home/remote/.ssh/id_rsa -Nnx2TR 22000:127.0.0.1:22
robot at externalhost
/bin/ssh -i /home/remote/.ssh/id_rsa -Nnx2TR 22001:127.0.0.1:22
robot at externalhost
/bin/ssh -i /home/remote/.ssh/id_rsa -Nnx2TR 22002:127.0.0.1:22
robot at externalhost
/bin/ssh -i /home/remote/.ssh/id_rsa -Nnx2TR 22003:127.0.0.1:22
robot at externalhost

The bot then SCP copies from the home directory:
scp -i id_rsa -P 22000 remote at localhost:file.tar.gz

The major issue is that the Port is the identifying metric for the
home folder of the remote user. Each tunnel should have a different
folder because each folder represents a different physical location.
The system was setup with individual machines in mind.

Instead of SCP pulling from /home/remote, it should pull from
/home/remote22000, /home/remote22001, etc based on the port number of
the reverse tunnel.'

I'm not sure if there's anyway to get sshd to solve this problem
currently.  I'm open to all suggestions. I have spent a lot of time
reading man pages for openssh and nothing I have tried has worked so
far.

I found this post to the mailing list:
http://www.gossamer-threads.com/lists/openssh/dev/52909

If I made each tunnel listen on a different port then I could use that
to chroot each port to a different directory. I don't know if this is
the best approach.

I can't get the patch to work on a current version of openssh so if
that's the best solution I would need some help with that.

Thanks

From dtucker at zip.com.au  Fri Jan 24 20:22:49 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 24 Jan 2014 20:22:49 +1100
Subject: Change initial directory based on port of reverse tunnel?
In-Reply-To: <CALa+F_QOcy-rZamt7+kNKCQCUQdWJSRoShUFdbiTAs_8v5pbxA@mail.gmail.com>
References: <CALa+F_QOcy-rZamt7+kNKCQCUQdWJSRoShUFdbiTAs_8v5pbxA@mail.gmail.com>
Message-ID: <CALDDTe2in+snVgTe94VR_R-m1=N0KCFJHxQc_H44+s62Ouq6og@mail.gmail.com>

On Fri, Jan 24, 2014 at 7:20 PM, John <givemefive at gmail.com> wrote:
> I'm  trying to create compatibility with an automated system that I do
> not have control over and cannot change.

I'm having trouble visualising the picture here.

> The system was built to
> connect to individual embedded linux machines that create reverse
> tunnels back to a server.
>
> These tunnels take the form:
> /bin/ssh -i /home/remote/.ssh/id_rsa -Nnx2TR 22000:127.0.0.1:22
> robot at externalhost
> /bin/ssh -i /home/remote/.ssh/id_rsa -Nnx2TR 22001:127.0.0.1:22
> robot at externalhost
> /bin/ssh -i /home/remote/.ssh/id_rsa -Nnx2TR 22002:127.0.0.1:22
> robot at externalhost
> /bin/ssh -i /home/remote/.ssh/id_rsa -Nnx2TR 22003:127.0.0.1:22
> robot at externalhost

ok, so far this sounds like you have some devices out in the field
which may be behind stateful firewalls, NAT or dynamic addresses and a
server on a fixed address and you want to be able to connect back to
these devices in the field.

remotedevice ssh'es into externalhost and presumably keeps the connections up.
when you want to connect to a device you get onto externalhost and ssh
to localhost on whatever port corresponds to that device.  so far so
good.

> The bot then SCP copies from the home directory:
> scp -i id_rsa -P 22000 remote at localhost:file.tar.gz

This is where I'm not sure I follow you.  This is initiated by
remotedevice or by externalhost?

If it's initiated by externalhost, then I would think you could change
whatever initiates it on externalhost.  The only way I can see this
working is if it's initiated by remotedevice to be run on externalhost
via ssh, which is much more complicated that necessary, ie you'd see
these commands on externaldevice:

externaldevice$ ssh -i /home/remote/.ssh/id_rsa -Nnx2TR \
   22000:127.0.0.1:22  robot at externalhost

externaldevice$ ssh  robot at externalhost scp -i id_rsa -P 22000 \
   file.tar.gz remote at localhost:file.tar.gz

instead of the simpler:

externaldevice$ ssh  scp -i id_rsa remote at localhost:file.tar.gz file.tar.gz

am I following correctly?

> The major issue is that the Port is the identifying metric for the
> home folder of the remote user.

the id_rsa keys and usernames are all identical?

> Each tunnel should have a different
> folder because each folder represents a different physical location.
> The system was setup with individual machines in mind.
>
> Instead of SCP pulling from /home/remote, it should pull from
> /home/remote22000, /home/remote22001, etc based on the port number of
> the reverse tunnel.'
>
> I'm not sure if there's anyway to get sshd to solve this problem
> currently.  I'm open to all suggestions. I have spent a lot of time
> reading man pages for openssh and nothing I have tried has worked so
> far.
>
> I found this post to the mailing list:
> http://www.gossamer-threads.com/lists/openssh/dev/52909
>
> If I made each tunnel listen on a different port then I could use that
> to chroot each port to a different directory. I don't know if this is
> the best approach.
>
> I can't get the patch to work on a current version of openssh so if
> that's the best solution I would need some help with that.

That patch is already in the current version of OpenSSH.  If I'm
following you then it's not going to help, though (it's about making
decisions in sshd based on which port the connection is made on,
however in your scenario you're actually connecting to ssh on
externalhost, not sshd).

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

From dtucker at zip.com.au  Fri Jan 24 21:07:45 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 24 Jan 2014 21:07:45 +1100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.NEB.2.11.1401231605330.330@chris.i8u.org>
References: <CALDDTe1e490W6CVxF2PgNstswQf0yJsPBun_8qBUBsstzQ8s5A@mail.gmail.com>
 <20140123083303.GI11155@yelena.nicm.ath.cx>
 <20140123112251.GA19903@gate.dtucker.net>
 <alpine.NEB.2.11.1401230759450.330@chris.i8u.org>
 <alpine.NEB.2.11.1401230915550.330@chris.i8u.org>
 <CALDDTe2EMsCGBaCXqXCyCmqPJ4+12WM4Ybg=vsxRnDyi8ZKeoA@mail.gmail.com>
 <alpine.NEB.2.11.1401231444260.330@chris.i8u.org>
 <alpine.NEB.2.11.1401231514290.330@chris.i8u.org>
 <alpine.BSO.2.11.1401241102440.14832@natsu.mindrot.org>
 <alpine.NEB.2.11.1401231605330.330@chris.i8u.org>
Message-ID: <20140124100745.GA18706@gate.dtucker.net>

On Thu, Jan 23, 2014 at 04:05:57PM -0800, Hisashi T Fujinaka wrote:
[...]
> No, local SATA disk.

I'm stealing Damien's thunder here since he did most of the work
reproducing and figuring the out the problem, but since he seems to be
missing in action at the moment: we think we figured it out.

Short answer: please try the patch below.

Long answer:
atomicio is a wrapper function around read and write that ensures all of
the data intended to be read or written actually does.  It does that by
passing a function pointer as its first argument, which it then calls for
the action.  If the read or write returns EAGAIN, it uses poll() to wait
for the descriptor to become readable or writeable, which it decides by
looking at the function pointer.  ccp uses atomicio.

What's happening is that in this case the passed function pointer is
not equal to atomicio's idea of of the address of the read function,
thus when we set the poll flags:

	pfd.events = f == read ? POLLIN : POLLOUT;

it means that on the read side, when the buffer fills, it starts waiting
for it to be *writeable*.  This doesn't happen and thus the the copy
stalls.

Why is the pointer different?  It seems that enabling --stack-protector
or similar (which one did configure enable?) turns read() into a macro
that ends up calling a different function which presumably does some
extra checking..  Why doesn't this transform also apply to atomicio.o?
That part is not clear.

There doesn't seem to be any equivalent macro for write(), so inverting
the test seems to fix it for now.  Longer term maybe we don't want to
use function pointers to pass what's essentially a boolean, but that
would be a larger change for another day after the release.

Thanks for your patience with this.  It does seem like a genuine
problem, albeit with a somewhat obscure cause.

Index: atomicio.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/atomicio.c,v
retrieving revision 1.40
diff -u -p -r1.40 atomicio.c
--- atomicio.c	24 Sep 2010 12:15:11 -0000	1.40
+++ atomicio.c	24 Jan 2014 04:24:50 -0000
@@ -57,7 +57,7 @@ atomicio6(ssize_t (*f) (int, void *, siz
 	struct pollfd pfd;
 
 	pfd.fd = fd;
-	pfd.events = f == read ? POLLIN : POLLOUT;
+	pfd.events = f == vwrite ? POLLOUT : POLLIN;
 	while (n > pos) {
 		res = (f) (fd, s + pos, n - pos);
 		switch (res) {

-- 
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 lssh.mailing.list at gmail.com  Fri Jan 24 21:21:09 2014
From: lssh.mailing.list at gmail.com (mailing-list ssh)
Date: Fri, 24 Jan 2014 11:21:09 +0100
Subject: Openssh, moduli and ssh-keygen
Message-ID: <CAOjYGHD_J3xCn5yhZpVR=6jCLKooVtdaRsXgojJ6QTa1ct=6AQ@mail.gmail.com>

Hi,

my question is related to the kex algorithm
diffie-hellman-group-exchange-sha256 and moduli generation. I've seen that
through ssh-keygen, I'm able to re-generate my moduli file used by DH but
I'm note sure to understand one point in the ssh-keygen manpage :
"Screened DH groups may be installed in /etc/ssh/moduli.  It is important
that this file contains moduli of a range of bit lengths and that both ends
of a connection share common moduli."

I don't understand why both ends of a connection should share a common
moduli file ?

If I trace the key exchange through wiresharck, I can see that the modulus
in transmitted as a public data to the client which is the expected
behavior according to the protocol.
If I strace the ssh client command (OpenSSH_5.9p1), I do not see any access
to the /etc/ssh/moduli file.

It seems that the moduli sharing between server and client is automaticaly
done by the protocol.

So, did I miss something or the manpage has a typo or is not clear ? Maybe
the sentence is aimed to say that bit lengths generated must be supported
by both ends ?

Thanks in advance for your explanation.

From dtucker at zip.com.au  Fri Jan 24 22:00:49 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 24 Jan 2014 22:00:49 +1100
Subject: Openssh, moduli and ssh-keygen
In-Reply-To: <CAOjYGHD_J3xCn5yhZpVR=6jCLKooVtdaRsXgojJ6QTa1ct=6AQ@mail.gmail.com>
References: <CAOjYGHD_J3xCn5yhZpVR=6jCLKooVtdaRsXgojJ6QTa1ct=6AQ@mail.gmail.com>
Message-ID: <CALDDTe1Ssb2ttiYqxHT0BX-LX+GqEDODW7ey-WEzJ-v6zQbU5A@mail.gmail.com>

On Fri, Jan 24, 2014 at 9:21 PM, mailing-list ssh
<lssh.mailing.list at gmail.com> wrote:
> my question is related to the kex algorithm
> diffie-hellman-group-exchange-sha256 and moduli generation. I've seen that
> through ssh-keygen, I'm able to re-generate my moduli file used by DH but
> I'm note sure to understand one point in the ssh-keygen manpage :
> "Screened DH groups may be installed in /etc/ssh/moduli.  It is important
> that this file contains moduli of a range of bit lengths and that both ends
> of a connection share common moduli."
>
> I don't understand why both ends of a connection should share a common
> moduli file ?

I think the man page is unclear.

The part about needing a range of sizes is true.  I suspect the part
about "both ends sharing common moduli" is trying to refer to
Diffie-Hellman Group Exchange, which is how the moduli for a
particular SSH session get to the client.

There is no requirement for the server and client to have the same
moduli file, and in fact no requirement for a client to have a moduli
file at all.

-- 
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 Yogendra.Kumar at ncr.com  Fri Jan 24 21:38:13 2014
From: Yogendra.Kumar at ncr.com (Kumar, Yogendra)
Date: Fri, 24 Jan 2014 05:38:13 -0500
Subject: Question Reagrding open SSH 
Message-ID: <0270B60DC8448C4EA47D54E8CA8C55478C92392264@susday218.corp.ncr.com>

Hi Team,

I have a question regarding open ssh issue.

We have a SFTP automate process to upload file at customer server using ssh key based authentication. But some simultaneously process going in hung state. I have enable verbose mode but I am not able to understand that log. Can you please let us know by below log why we are facing this issue?


While process going in hung state:-
============================

Connecting to b2bpsftp.dell.com...
Sun_SSH_1.1.4, SSH protocols 1.5/2.0, OpenSSL 0x0090704f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to b2bpsftp.dell.com [150.105.78.125] port 22.
debug1: Connection established.
debug3: Not a RSA1 key file /cdunix/appl/user/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: no key found
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: no key found
debug1: identity file /cdunix/appl/user/.ssh/id_rsa type 1
debug3: Not a RSA1 key file /cdunix/appl/user/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: no key found
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: no key found
debug1: identity file /cdunix/appl/user/.ssh/id_dsa type -1
debug1: Logging to host: b2bpsftp.dell.com
debug1: Local user: cduser Remote user: 700000035
=========================================================



While process successfully completed:-

Connecting to b2bpsftp.dell.com...
Sun_SSH_1.1.4, SSH protocols 1.5/2.0, OpenSSL 0x0090704f
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: Rhosts Authentication disabled, originating port will not be trusted.
debug1: ssh_connect: needpriv 0
debug1: Connecting to b2bpsftp.dell.com [150.105.78.125] port 22.
debug1: Connection established.
debug3: Not a RSA1 key file /cdunix/appl/user/.ssh/id_rsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: no key found
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: no key found
debug1: identity file /cdunix/appl/user/.ssh/id_rsa type 1
debug3: Not a RSA1 key file /cdunix/appl/user/.ssh/id_dsa.
debug2: key_type_from_name: unknown key type '-----BEGIN'
debug3: key_read: no key found
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug3: key_read: no space
debug2: key_type_from_name: unknown key type '-----END'
debug3: key_read: no key found
debug1: identity file /cdunix/appl/user/.ssh/id_dsa type -1
debug1: Logging to host: b2bpsftp.dell.com
debug1: Local user: cduser Remote user: 700000035
debug1: Remote protocol version 2.0, remote software version SecureLink SSH Server (Version 3.2.1.142)
debug1: no match: SecureLink SSH Server (Version 3.2.1.142)
debug1: Enabling compatibility mode for protocol 2.0
debug1: Local version string SSH-2.0-Sun_SSH_1.1.4
debug1: use_engine is 'yes'
debug1: pkcs11 engine initialized, now setting it as default for RSA, DSA, and symmetric ciphers
debug1: pkcs11 engine initialization complete
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: i-default
debug2: kex_parse_kexinit: i-default
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug1: Failed to acquire GSS-API credentials for any mechanisms (No credentials were supplied, or the credentials were unavailable or inaccessible
Unknown code 0
)
debug1: SSH2_MSG_KEXINIT sent
debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0 && !0
debug1: SSH2_MSG_KEXINIT received
debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1
debug2: kex_parse_kexinit: ssh-rsa,ssh-dss
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
debug2: kex_parse_kexinit: aes128-ctr,aes128-cbc,arcfour,3des-cbc,blowfish-cbc,aes192-ctr,aes192-cbc,aes256-ctr,aes256-cbc
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-sha1-96,hmac-md5-96
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: i-default
debug2: kex_parse_kexinit: i-default
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: kex_parse_kexinit: diffie-hellman-group1-sha1,diffie-hellman-group14-sha1
debug2: kex_parse_kexinit: ssh-rsa
debug2: kex_parse_kexinit: aes128-cbc,arcfour256,aes192-ctr,twofish192-cbc,cast128-cbc,twofish256-cbc,aes128-ctr,twofish128-cbc,3des-cbc,blowfish-cbc,arcfour128,arcfour,aes256-cbc,aes256-ctr,aes192-cbc
debug2: kex_parse_kexinit: aes128-cbc,arcfour256,aes192-ctr,twofish192-cbc,cast128-cbc,twofish256-cbc,aes128-ctr,twofish128-cbc,3des-cbc,blowfish-cbc,arcfour128,arcfour,aes256-cbc,aes256-ctr,aes192-cbc
debug2: kex_parse_kexinit: hmac-sha1,hmac-md5-96,hmac-md5,hmac-sha1-96,hmac-ripemd160
debug2: kex_parse_kexinit: hmac-sha1,hmac-md5-96,hmac-md5,hmac-sha1-96,hmac-ripemd160
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit: none,zlib
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit:
debug2: kex_parse_kexinit: first_kex_follows 0
debug2: kex_parse_kexinit: reserved 0
debug2: mac_init: found hmac-md5
debug1: kex: server->client aes128-ctr hmac-md5 none
debug2: mac_init: found hmac-md5
debug1: kex: client->server aes128-ctr hmac-md5 none
debug1: Peer sent proposed langtags, ctos:
debug1: Peer sent proposed langtags, stoc:
debug1: We proposed langtags, ctos: i-default
debug1: We proposed langtags, stoc: i-default
debug1: dh_gen_key: priv key bits set: 135/256
debug1: bits set: 1043/2048
debug1: sending SSH2_MSG_KEXDH_INIT
debug1: expecting SSH2_MSG_KEXDH_REPLY
debug3: check_host_in_hostfile: filename /cdunix/appl/user/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 32
debug3: check_host_in_hostfile: filename /cdunix/appl/user/.ssh/known_hosts
debug3: check_host_in_hostfile: match line 32
debug1: Host 'b2bpsftp.dell.com' is known and matches the RSA host key.
debug1: Found key in /cdunix/appl/user/.ssh/known_hosts:32
debug1: bits set: 1050/2048
debug1: ssh_rsa_verify: signature correct
debug2: kex_derive_keys
debug3: kex_reset_dispatch -- should we dispatch_set(KEXINIT) here? 0 && !0
debug1: newkeys: mode 1
debug1: set_newkeys: setting new keys for 'out' mode
debug3: aes-128-ctr NID found
debug1: SSH2_MSG_NEWKEYS sent
debug1: expecting SSH2_MSG_NEWKEYS
debug1: newkeys: mode 0
debug1: set_newkeys: setting new keys for 'in' mode
debug3: aes-128-ctr NID found
debug1: SSH2_MSG_NEWKEYS received
debug1: done: ssh_kex2.
debug1: send SSH2_MSG_SERVICE_REQUEST
debug2: service_accept: ssh-userauth
debug1: got SSH2_MSG_SERVICE_ACCEPT
debug3: input_userauth_banner
sftp.gatewaydebug1: Authentications that can continue: publickey,password
debug3: start over, passed a different list publickey,password
debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password
debug3: authmethod_lookup publickey
debug3: remaining preferred: keyboard-interactive,password
debug3: authmethod_is_enabled publickey
debug1: Next authentication method: publickey
debug1: Trying public key: /cdunix/appl/user/.ssh/id_rsa
debug3: send_pubkey_test
debug2: we sent a publickey packet, wait for reply
debug1: Server accepts key: pkalg ssh-rsa blen 149 lastkey 6f1f8 hint 0
debug2: input_userauth_pk_ok: fp f8:d2:f2:e0:e9:a1:a5:92:a9:a4:cb:c5:c8:0d:ed:ff
debug3: sign_and_send_pubkey
debug1: read PEM private key done: type RSA
debug1: Authentication succeeded (publickey)
debug1: fd 6 setting O_NONBLOCK
debug2: fd 7 is O_NONBLOCK
debug1: fd 8 setting O_NONBLOCK
debug1: channel 0: new [client-session]
debug3: ssh_session2_open: channel_new: 0
debug1: send channel open 0
debug1: Entering interactive session.
debug2: callback start
debug1: ssh_session2_setup: id 0
debug1: channel request 0: env
debug2: Sent request for environment variable LC_CTYPE=en_US.ISO8859-1
debug1: channel request 0: env
debug2: Sent request for environment variable LC_COLLATE=en_US.ISO8859-1
debug1: channel request 0: env
debug2: Sent request for environment variable LC_TIME=en_US.ISO8859-1
debug1: channel request 0: env
debug2: Sent request for environment variable LC_NUMERIC=en_US.ISO8859-1
debug1: channel request 0: env
debug2: Sent request for environment variable LC_MONETARY=en_US.ISO8859-1
debug1: channel request 0: env
debug2: Sent request for environment variable LC_MESSAGES=C
debug1: Sending subsystem: sftp
debug1: channel request 0: subsystem
debug2: callback done
debug1: channel 0: open confirm rwindow 0 rmax 34000
debug2: channel 0: rcvd adjust 131072
debug2: Remote version: 3
debug3: Sent message fd 6 T:16 I:1
debug3: SSH_FXP_REALPATH . -> /home/700000035
sftp> put /cust01/dellinvs/edi_prod/push/snd/OUT100000157152.INT.sch /home/700000035/tovan/OUT100000157152.INT.wrk
debug3: Looking up /cust01/dellinvs/edi_prod/push/snd/OUT100000157152.INT.sch
debug3: Sent message fd 6 T:17 I:2
debug3: Received stat reply T:101 I:2
debug1: Couldn't stat remote file: No such file or directory
Uploading /cust01/dellinvs/edi_prod/push/snd/OUT100000157152.INT.sch to /home/700000035/tovan/OUT100000157152.INT.wrk
debug3: Sent message SSH2_FXP_OPEN I:3 P:/home/700000035/tovan/OUT100000157152.INT.wrk
debug3: Sent message SSH2_FXP_WRITE I:4 O:0 S:564
debug3: SSH2_FXP_STATUS 0
debug3: In write loop, ack for 4 564 bytes at 0
debug3: Sent message SSH2_FXP_CLOSE I:4
debug3: SSH2_FXP_STATUS 0
sftp> rename /home/700000035/tovan/OUT100000157152.INT.wrk /home/700000035/tovan/OUT100000157152.INT
debug3: Sent message SSH2_FXP_RENAME "/home/700000035/tovan/OUT100000157152.INT.wrk" -> "/home/700000035/tovan/OUT100000157152.INT"
debug3: SSH2_FXP_STATUS 0
sftp> quit
debug1: channel 0: read<=0 rfd 6 len 0
debug1: channel 0: read failed
debug1: channel 0: close_read
debug1: channel 0: input open -> drain
debug1: channel 0: ibuf empty
debug1: channel 0: send eof
debug1: channel 0: input drain -> closed
debug1: client_input_channel_req: channel 0 rtype exit-status reply 0
debug1: channel 0: rcvd close
debug1: channel 0: output open -> drain
debug3: channel 0: will not send data after close
debug1: channel 0: obuf empty
debug1: channel 0: close_write
debug1: channel 0: output drain -> closed
debug1: channel 0: almost dead
debug1: channel 0: gc: notify user
debug1: channel 0: gc: user detached
debug1: channel 0: send close
debug1: channel 0: is dead
debug1: channel 0: garbage collecting
debug1: channel_free: channel 0: client-session, nchannels 1
debug3: channel_free: status: The following connections are open:
  #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1)

debug3: channel_close_fds: channel 0: r -1 w -1 e 8
debug1: fd 0 clearing O_NONBLOCK
debug2: fd 1 is not O_NONBLOCK
debug1: fd 2 clearing O_NONBLOCK
debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 1.9 seconds
debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0
debug1: Exit status 0
ssh_exchange_identification: read: Connection timed out
debug1: Calling cleanup 0x34d88(0x0)
Connection closed
=======================================================================

[cid:image001.jpg at 01CF191E.67041DB0]Yogendra Kumar
Services Technology - FTS/CTS
NCR Corporation
Office: +91 124 4353314  |  Mobile: 8882622243
kumar.yogendra at ncr.com  |  www.ncr.com<http://www.ncr.com/>


From dtucker at zip.com.au  Fri Jan 24 22:31:23 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 24 Jan 2014 22:31:23 +1100
Subject: Question Reagrding open SSH
In-Reply-To: <0270B60DC8448C4EA47D54E8CA8C55478C92392264@susday218.corp.ncr.com>
References: <0270B60DC8448C4EA47D54E8CA8C55478C92392264@susday218.corp.ncr.com>
Message-ID: <CALDDTe0XfCEW7JHRKbmxQ4xkUUqteg_s46K1NawXc-zio16i3g@mail.gmail.com>

On Fri, Jan 24, 2014 at 9:38 PM, Kumar, Yogendra <Yogendra.Kumar at ncr.com> wrote:
[...]
> Connecting to b2bpsftp.dell.com...
> Sun_SSH_1.1.4, SSH protocols 1.5/2.0, OpenSSL 0x0090704f

This is not OpenSSH, it's a derivative modified work by Sun/Oracle.
We can't help you with this.

[...]
> debug1: Remote protocol version 2.0, remote software version SecureLink SSH Server (Version 3.2.1.142)

This is also not OpenSSH, and I've never even heard of it before.  We
can't help you with this either.  I will say that since your failing
case didn't even get the remote banner, I'd be looking for problems
with your network.

Can you reproduce the problem with the stock OpenSSH built from the
code from openssh.com?

-- 
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 ronf at timeheart.net  Sat Jan 25 01:01:09 2014
From: ronf at timeheart.net (Ron Frederick)
Date: Fri, 24 Jan 2014 06:01:09 -0800
Subject: Question Reagrding open SSH
In-Reply-To: <CALDDTe0XfCEW7JHRKbmxQ4xkUUqteg_s46K1NawXc-zio16i3g@mail.gmail.com>
References: <0270B60DC8448C4EA47D54E8CA8C55478C92392264@susday218.corp.ncr.com>
 <CALDDTe0XfCEW7JHRKbmxQ4xkUUqteg_s46K1NawXc-zio16i3g@mail.gmail.com>
Message-ID: <8F5FF3B3-FB3C-4A5D-ACC2-115CD55B10A9@timeheart.net>

On Jan 24, 2014, at 3:31 AM, Darren Tucker <dtucker at zip.com.au> wrote:
> On Fri, Jan 24, 2014 at 9:38 PM, Kumar, Yogendra <Yogendra.Kumar at ncr.com> wrote:
> [...]
>> Connecting to b2bpsftp.dell.com...
>> Sun_SSH_1.1.4, SSH protocols 1.5/2.0, OpenSSL 0x0090704f
> 
> This is not OpenSSH, it's a derivative modified work by Sun/Oracle.
> We can't help you with this.
> 
> [...]
>> debug1: Remote protocol version 2.0, remote software version SecureLink SSH Server (Version 3.2.1.142)
> 
> This is also not OpenSSH, and I've never even heard of it before.  We
> can't help you with this either.  I will say that since your failing
> case didn't even get the remote banner, I'd be looking for problems
> with your network.
> 
> Can you reproduce the problem with the stock OpenSSH built from the
> code from openssh.com?

I ran across something like this when writing my own SSH server recently. I don?t know if it applies here but in my case it turned out to be related to the fact that the Sun client sent its version identification with only a ?\n? at the end of the line instead of ?\r\n?. My server was sending ?SSH-2.0? as the version ending with ?\r\n? and the client accepted that just fine, but the client sent its version as ?SSH-2.0? ending with only ?\n?. I had to generalize my server code to accept either ?\r\n? or just ?\n? as a line terminator for the handshake to proceed.

I think the client is out of spec here, but it was a simple change to make. From what I can see in the RFC, the only case where ?\n? should be used is on the server when it is in SSHv1-compatibility mode and it sends ?SSH-1.99? as the version.
-- 
Ron Frederick
ronf at timeheart.net




From givemefive at gmail.com  Sat Jan 25 03:00:42 2014
From: givemefive at gmail.com (John)
Date: Fri, 24 Jan 2014 10:00:42 -0600
Subject: Change initial directory based on port of reverse tunnel?
In-Reply-To: <CALDDTe2in+snVgTe94VR_R-m1=N0KCFJHxQc_H44+s62Ouq6og@mail.gmail.com>
References: <CALa+F_QOcy-rZamt7+kNKCQCUQdWJSRoShUFdbiTAs_8v5pbxA@mail.gmail.com>
 <CALDDTe2in+snVgTe94VR_R-m1=N0KCFJHxQc_H44+s62Ouq6og@mail.gmail.com>
Message-ID: <CALa+F_Sf+-V7FSgDhCFxXChUae-9kHwmsaAW+49fgYhzbe-7-Q@mail.gmail.com>

> ok, so far this sounds like you have some devices out in the field
> which may be behind stateful firewalls, NAT or dynamic addresses and a
> server on a fixed address and you want to be able to connect back to
> these devices in the field.
>
> remotedevice ssh'es into externalhost and presumably keeps the connections up.
> when you want to connect to a device you get onto externalhost and ssh
> to localhost on whatever port corresponds to that device.  so far so
> good.
>

Yeah so this is exactly right.

>
> the id_rsa keys and usernames are all identical?
>

Yes, everything is identical and the only way the external host can
identify a folder of data is by the port number it connects to.

>
> That patch is already in the current version of OpenSSH.  If I'm
> following you then it's not going to help, though (it's about making
> decisions in sshd based on which port the connection is made on,
> however in your scenario you're actually connecting to ssh on
> externalhost, not sshd).

So taking this knowledge which I couldn't find documented in the man
pages but I found elsewhere on the Internet:


remote device /etc/ssh/sshd_config:
Port 22222
Match LocalPort 22222
        Banner /etc/ssh/banner
        ForceCommand /etc/ssh/script

remote device /etc/ssh/script:
#!/bin/sh
PORT="${SSH_CONNECTION##* }"
DIR="/home/remoteuser/$PORT"
mkdir -p "$DIR"
cd "$DIR"
[ -z "$SSH_ORIGINAL_COMMAND" ] && exec bash --login
exec $SSH_ORIGINAL_COMMAND

remote device-- tunnel:
/usr/bin/ssh -i /home/remoteuser/.ssh/id_rsa_for_external_host -Nxn2TR
52000:127.0.0.1:22222 testuser at externalhost

command for externalhost admin/bot
ssh -i id_rsa_for_remote_device -p 52000 remoteuser at localhost
scp -i id_rsa_for_remote_device -P 52000 remoteuser at localhost:testfile .


Now I have the incoming ssh from the external hosts being
transparently placed into the right directory. This is exactly what I
need.  Is there a better way to do what I want or should I just stick
with what works?

Thanks

From plautrba at redhat.com  Sat Jan 25 03:28:03 2014
From: plautrba at redhat.com (Petr Lautrbach)
Date: Fri, 24 Jan 2014 17:28:03 +0100
Subject: 3des cipher and DH group size
In-Reply-To: <52DE9CCB.5070505@redhat.com>
References: <52DE9CCB.5070505@redhat.com>
Message-ID: <52E29493.1050102@redhat.com>

On 01/21/2014 05:14 PM, Petr Lautrbach wrote:
> Hello everybody,
> 
> An issue was reported in RH bugzilla [1] about the size of the used DH
> group  when combined with the 3des-cbc cipher. OpenSSH uses the
> actual key length for the size estimation. This is probably fine as far
> as the cipher has the same number of bits of security as the key
> length. But this is not true for 3TDEA where the key size is 168 resp
> 192 but it's security is only 112.
> 
> Given that the key size in openssh is set to 192, DH group size is
> estimated to 7680. But according to NIST SP 800-57, the size of DH key
> should be 2048 so openssh doesn't follow that  and it might cause
> problems with key exchanges with some servers.
> 

It was confirmed that openssh can't connect to the server with a server string
'SSH-2.0-cryptlib' using diffie-hellman-group-exchange-sha1 and 3des-cbc with
SSH2_MSG_KEX_DH_GEX_REQUEST(1024<7680<8192).

It's due to a issue in its code [1] which takes only requested value and is limited
only to 4096 bits. So I've made a patch [2] as a POF which adds a security length column and
uses this value for dh_estimation. For 3des-cbc it's 14 which makes 2048 of preferred
DH group size:
SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<8192)

and I've got confirmed that is solves the issue with this particular server.



[1] https://bugzilla.redhat.com/show_bug.cgi?id=1026430#c5
[2] http://fedorapeople.org/~plautrba/openssh/cipher-security-size.patch

Petr
-- 
Petr Lautrbach
Security Technologies
Red Hat

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com.

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

From htodd at twofifty.com  Sat Jan 25 03:54:40 2014
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Fri, 24 Jan 2014 08:54:40 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <20140124100745.GA18706@gate.dtucker.net>
References: <CALDDTe1e490W6CVxF2PgNstswQf0yJsPBun_8qBUBsstzQ8s5A@mail.gmail.com>
 <20140123083303.GI11155@yelena.nicm.ath.cx>
 <20140123112251.GA19903@gate.dtucker.net>
 <alpine.NEB.2.11.1401230759450.330@chris.i8u.org>
 <alpine.NEB.2.11.1401230915550.330@chris.i8u.org>
 <CALDDTe2EMsCGBaCXqXCyCmqPJ4+12WM4Ybg=vsxRnDyi8ZKeoA@mail.gmail.com>
 <alpine.NEB.2.11.1401231444260.330@chris.i8u.org>
 <alpine.NEB.2.11.1401231514290.330@chris.i8u.org>
 <alpine.BSO.2.11.1401241102440.14832@natsu.mindrot.org>
 <alpine.NEB.2.11.1401231605330.330@chris.i8u.org>
 <20140124100745.GA18706@gate.dtucker.net>
Message-ID: <alpine.NEB.2.11.1401240851470.12225@chris.i8u.org>

On Fri, 24 Jan 2014, Darren Tucker wrote:

> I'm stealing Damien's thunder here since he did most of the work
> reproducing and figuring the out the problem, but since he seems to be
> missing in action at the moment: we think we figured it out.
>
> Short answer: please try the patch below.

> Index: atomicio.c
> ===================================================================
> RCS file: /home/dtucker/openssh/cvs/openssh/atomicio.c,v
> retrieving revision 1.40
> diff -u -p -r1.40 atomicio.c
> --- atomicio.c	24 Sep 2010 12:15:11 -0000	1.40
> +++ atomicio.c	24 Jan 2014 04:24:50 -0000
> @@ -57,7 +57,7 @@ atomicio6(ssize_t (*f) (int, void *, siz
> 	struct pollfd pfd;
>
> 	pfd.fd = fd;
> -	pfd.events = f == read ? POLLIN : POLLOUT;
> +	pfd.events = f == vwrite ? POLLOUT : POLLIN;
> 	while (n > pos) {
> 		res = (f) (fd, s + pos, n - pos);
> 		switch (res) {

I changed that one and also the one in atomiciov6 and I'm still getting
hangs. Actually, what I did was change one, got hangs, changed both, got
hangs. There are previous errors that might be part of it, like the
errors in malloc? I'm sure Damien's seen those, though.

-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

From djm at mindrot.org  Sat Jan 25 06:59:02 2014
From: djm at mindrot.org (Damien Miller)
Date: Sat, 25 Jan 2014 06:59:02 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.NEB.2.11.1401240851470.12225@chris.i8u.org>
References: <CALDDTe1e490W6CVxF2PgNstswQf0yJsPBun_8qBUBsstzQ8s5A@mail.gmail.com>
 <20140123083303.GI11155@yelena.nicm.ath.cx>
 <20140123112251.GA19903@gate.dtucker.net>
 <alpine.NEB.2.11.1401230759450.330@chris.i8u.org>
 <alpine.NEB.2.11.1401230915550.330@chris.i8u.org>
 <CALDDTe2EMsCGBaCXqXCyCmqPJ4+12WM4Ybg=vsxRnDyi8ZKeoA@mail.gmail.com>
 <alpine.NEB.2.11.1401231444260.330@chris.i8u.org>
 <alpine.NEB.2.11.1401231514290.330@chris.i8u.org>
 <alpine.BSO.2.11.1401241102440.14832@natsu.mindrot.org>
 <alpine.NEB.2.11.1401231605330.330@chris.i8u.org>
 <20140124100745.GA18706@gate.dtucker.net>
 <alpine.NEB.2.11.1401240851470.12225@chris.i8u.org>
Message-ID: <alpine.BSO.2.11.1401250655510.24928@natsu.mindrot.org>

On Fri, 24 Jan 2014, Hisashi T Fujinaka wrote:

> I changed that one and also the one in atomiciov6 and I'm still getting
> hangs. Actually, what I did was change one, got hangs, changed both, got
> hangs. There are previous errors that might be part of it, like the
> errors in malloc? I'm sure Damien's seen those, though.

You'll probably need this patch too, to make sure you are testing the
right scp - our regress tests were incorrectly testing the system one
rather than the one that was just built:


commit b0e0f760b861676a3fe5c40133b270713d5321a9
Author: Damien Miller <djm at mindrot.org>
Date:   Fri Jan 24 14:27:04 2014 +1100

     - (djm) [Makefile.in regress/scp-ssh-wrapper.sh regress/scp.sh] Make
       the scp regress test actually test the built scp rather than the one
       in $PATH. ok dtucker@

diff --git a/ChangeLog b/ChangeLog
index e352892..d928479 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,8 @@
+20130124
+ - (djm) [Makefile.in regress/scp-ssh-wrapper.sh regress/scp.sh] Make
+   the scp regress test actually test the built scp rather than the one
+   in $PATH. ok dtucker@
+
 20130123
  - (tim) [session.c] Improve error reporting on set_id().
  - (dtucker) [configure.ac] NetBSD's (and FreeBSD's) strnvis is gratuitously
diff --git a/Makefile.in b/Makefile.in
index f5dd3b8..e3dfab2 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -1,4 +1,4 @@
-# $Id: Makefile.in,v 1.350 2014/01/17 05:47:04 djm Exp $
+# $Id: Makefile.in,v 1.351 2014/01/24 03:27:04 djm Exp $
 
 # uncomment if you run a non bourne compatable shell. Ie. csh
 #SHELL = @SH@
@@ -411,6 +411,7 @@ regress/setuid-allowed$(EXEEXT): $(srcdir)/regress/setuid-allowed.c
 tests interop-tests:	$(TARGETS) regress/modpipe$(EXEEXT)
 	BUILDDIR=`pwd`; \
 	TEST_SHELL="@TEST_SHELL@"; \
+	TEST_SSH_SCP="$${BUILDDIR}/scp"; \
 	TEST_SSH_SSH="$${BUILDDIR}/ssh"; \
 	TEST_SSH_SSHD="$${BUILDDIR}/sshd"; \
 	TEST_SSH_SSHAGENT="$${BUILDDIR}/ssh-agent"; \
@@ -434,6 +435,7 @@ tests interop-tests:	$(TARGETS) regress/modpipe$(EXEEXT)
 		PATH="$${BUILDDIR}:$${PATH}" \
 		TEST_ENV=MALLOC_OPTIONS="@TEST_MALLOC_OPTIONS@" \
 		TEST_SHELL="$${TEST_SHELL}" \
+		TEST_SSH_SCP="$${TEST_SSH_SCP}" \
 		TEST_SSH_SSH="$${TEST_SSH_SSH}" \
 		TEST_SSH_SSHD="$${TEST_SSH_SSHD}" \
 		TEST_SSH_SSHAGENT="$${TEST_SSH_SSHAGENT}" \
diff --git a/regress/scp-ssh-wrapper.sh b/regress/scp-ssh-wrapper.sh
index d1005a9..c63bc2b 100644
--- a/regress/scp-ssh-wrapper.sh
+++ b/regress/scp-ssh-wrapper.sh
@@ -17,7 +17,7 @@ printname () {
 }
 
 # Discard all but last argument.  We use arg later.
-while test "$1" != ""; do
+while test "x$1" != "x"; do
 	arg="$1"
 	shift
 done
@@ -52,6 +52,8 @@ badserver_4)
 	echo "X"
 	;;
 *)
-	exec $arg
+	set -- $arg
+	shift
+	exec $SCP "$@"
 	;;
 esac
diff --git a/regress/scp.sh b/regress/scp.sh
index 29c5b35..c2da2a8 100644
--- a/regress/scp.sh
+++ b/regress/scp.sh
@@ -20,6 +20,7 @@ SRC=`dirname ${SCRIPT}`
 cp ${SRC}/scp-ssh-wrapper.sh ${OBJ}/scp-ssh-wrapper.scp
 chmod 755 ${OBJ}/scp-ssh-wrapper.scp
 scpopts="-q -S ${OBJ}/scp-ssh-wrapper.scp"
+export SCP # used in scp-ssh-wrapper.scp
 
 scpclean() {
 	rm -rf ${COPY} ${COPY2} ${DIR} ${DIR2}

From dtucker at zip.com.au  Sat Jan 25 08:00:28 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 25 Jan 2014 08:00:28 +1100
Subject: 3des cipher and DH group size
In-Reply-To: <52E29493.1050102@redhat.com>
References: <52DE9CCB.5070505@redhat.com> <52E29493.1050102@redhat.com>
Message-ID: <CALDDTe3tj+TBGdrV5EpY5Y89meeBSMf-JgJD8wQmfJSgfDZugw@mail.gmail.com>

On Sat, Jan 25, 2014 at 3:28 AM, Petr Lautrbach <plautrba at redhat.com> wrote:
> It was confirmed that openssh can't connect to the server with a server string
> 'SSH-2.0-cryptlib' using diffie-hellman-group-exchange-sha1 and 3des-cbc with
> SSH2_MSG_KEX_DH_GEX_REQUEST(1024<7680<8192).
>
> It's due to a issue in its code [1] which takes only requested value

Well, that's a bug in cryptlib, but I'll let you follow that one up.

> and is limited only to 4096 bits.

RFC4419 says supporting groups up to 8k is a SHOULD, so that seems ok.

> So I've made a patch [2] as a POF which adds a security length column and
> uses this value for dh_estimation. For 3des-cbc it's 14 which makes 2048 of preferred
> DH group size:
> SSH2_MSG_KEX_DH_GEX_REQUEST(1024<2048<8192)
>
> and I've got confirmed that is solves the issue with this particular server.
[...]
> [2] http://fedorapeople.org/~plautrba/openssh/cipher-security-size.patch

BTW I think there's a bug in your patch:

+ u_int mode, ctos, need, dh_need, authlen;
[...]
+ if (dh_need < newkeys->enc.sec_len)
+ dh_need = newkeys->enc.sec_len;
[...]
+ kex->dh_need = ( dh_need ? dh_need : need );

dh_need is used uninitialized.

-- 
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 mancha1 at hush.com  Sat Jan 25 08:23:09 2014
From: mancha1 at hush.com (mancha)
Date: Fri, 24 Jan 2014 21:23:09 +0000 (UTC)
Subject: 3des cipher and DH group size
References: <52DE9CCB.5070505@redhat.com> <52E29493.1050102@redhat.com>
Message-ID: <loom.20140124T175200-839@post.gmane.org>

Petr Lautrbach <plautrba <at> redhat.com> writes:
> 
> It was confirmed that openssh can't connect to the server with a server
> string 'SSH-2.0-cryptlib' using diffie-hellman-group-exchange-sha1 and
> 3des-cbc with SSH2_MSG_KEX_DH_GEX_REQUEST(1024<7680<8192).
> 
> It's due to a issue in its code [1] which takes only requested value and
> is limited only to 4096 bits.

Setting aside 3DES's effective crypto strength and NIST guidelines, it's
unfortunate cryptlib-based SSH servers don't follow RFC4419
recommendations:

   "The server should return the smallest group it knows that is larger
   than the size the client requested.  If the server does not know a
   group that is larger than the client request, then it SHOULD return
   the largest group it knows.  In all cases, the size of the returned
   group SHOULD be at least 1024 bits."

Have you asked them what exceptional circumstances (cf. RFC2119) justify
the deviation?

--mancha


From cloos at jhcloos.com  Sat Jan 25 08:15:24 2014
From: cloos at jhcloos.com (James Cloos)
Date: Fri, 24 Jan 2014 16:15:24 -0500
Subject: Cipher preference
In-Reply-To: <alpine.BSO.2.03.1401010936440.30571@mindrot.org> (Damien
 Miller's message of "Wed, 1 Jan 2014 09:37:34 +1100 (EST)")
References: <m361q523ij.fsf@carbon.jhcloos.org>
 <alpine.BSO.2.03.1312311341180.7877@mindrot.org>
 <m3zjnhzekn.fsf@carbon.jhcloos.org>
 <alpine.BSO.2.03.1401010936440.30571@mindrot.org>
Message-ID: <m3iot95bei.fsf@carbon.jhcloos.org>

>>>>> "DM" == Damien Miller <djm at mindrot.org> writes:

DM> Evidence? openssl/crypto/modes/gcm128.c is full of array operations
DM> that look decidedly non-constant time to me.

[Appologies for the delay.]

Then it seems that the articles which favoured gcm presumed that it
would only get use with aesni or equivalent, or that I misread the
authors' intent. :(

An alternative would be an easy way to specify a preferred option for
configs Ciphers, KexAlgorithms and/or MACs without disabling the
defaults and without having to re-specify all of them.

It might take the form of a string, such as DEFAULT, which expands to
the default list or something like preferredCiphers, preferredKex and
preferredMACs which, if set, are tried first.

The ability to prefer a given algorithm set w/o blocking connections to
hosts which cannot handle that set is useful.  Doing so w/o having to
duplicate the full list in the config file is even better.

-JimC
--
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 835 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20140124/ce77de2c/attachment.bin>

From cloos at jhcloos.com  Sat Jan 25 08:47:03 2014
From: cloos at jhcloos.com (James Cloos)
Date: Fri, 24 Jan 2014 16:47:03 -0500
Subject: Cipher preference
In-Reply-To: <la1cut$2710$1@lorvorc.mips.inka.de> (Christian Weisgerber's
 message of "Wed, 1 Jan 2014 15:41:17 +0000 (UTC)")
References: <m361q523ij.fsf@carbon.jhcloos.org>
 <la1cut$2710$1@lorvorc.mips.inka.de>
Message-ID: <m3d2jh59xr.fsf@carbon.jhcloos.org>

>>>>> "CW" == Christian Weisgerber <naddy at mips.inka.de> writes:

JC>> When testing chacha20-poly1305, I noticed that aes-gcm is significantly
JC>> faster than aes-ctr or aes-cbs with umac.  Even on systems w/o aes-ni
JC>> or other recent instruction set additions.

CW> No way.  This disagrees completely with what I'm seeing:

CW> On x86-64 systems without AES-NI, aes128-gcm is slower than
CW> aes128-ctr+umac-64.  (OpenSSL 1.0.1c, 1.0.1e)

On my k10 in performance mode, with long scp(1)s which (as reported by
scp) is limited to 2MB/s, aes128-ctr + umac-64-etm at openssh.com took 17%
of a core, aes128-gcm at openssh.com took 12% and chacha20-poly1305@
openssh.com took 10%, as reported by GNU time(1).

CW> On other systems without AES-NI or the benefit of assembly language
CW> optimizations in OpenSSL, aes128-gcm is painfully slower than
CW> aes128-ctr+umac-64.  (OpenSSL 1.0.1c)

W/o assembly that is not surprising.  I bet chacha+poly is the most
efficient secure option on those platforms.

-JimC
--
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

From htodd at twofifty.com  Sat Jan 25 11:18:33 2014
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Fri, 24 Jan 2014 16:18:33 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.11.1401250655510.24928@natsu.mindrot.org>
References: <CALDDTe1e490W6CVxF2PgNstswQf0yJsPBun_8qBUBsstzQ8s5A@mail.gmail.com>
 <20140123083303.GI11155@yelena.nicm.ath.cx>
 <20140123112251.GA19903@gate.dtucker.net>
 <alpine.NEB.2.11.1401230759450.330@chris.i8u.org>
 <alpine.NEB.2.11.1401230915550.330@chris.i8u.org>
 <CALDDTe2EMsCGBaCXqXCyCmqPJ4+12WM4Ybg=vsxRnDyi8ZKeoA@mail.gmail.com>
 <alpine.NEB.2.11.1401231444260.330@chris.i8u.org>
 <alpine.NEB.2.11.1401231514290.330@chris.i8u.org>
 <alpine.BSO.2.11.1401241102440.14832@natsu.mindrot.org>
 <alpine.NEB.2.11.1401231605330.330@chris.i8u.org>
 <20140124100745.GA18706@gate.dtucker.net>
 <alpine.NEB.2.11.1401240851470.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401250655510.24928@natsu.mindrot.org>
Message-ID: <alpine.NEB.2.11.1401241617390.12225@chris.i8u.org>

On Sat, 25 Jan 2014, Damien Miller wrote:

> You'll probably need this patch too, to make sure you are testing the
> right scp - our regress tests were incorrectly testing the system one
> rather than the one that was just built:
>
>
> commit b0e0f760b861676a3fe5c40133b270713d5321a9

I think I'm doing something wrong because I'm still stuck at the copy.
Maybe I can get it to dump a core file.

-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

From djm at mindrot.org  Sat Jan 25 12:13:37 2014
From: djm at mindrot.org (Damien Miller)
Date: Sat, 25 Jan 2014 12:13:37 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.NEB.2.11.1401241617390.12225@chris.i8u.org>
References: <CALDDTe1e490W6CVxF2PgNstswQf0yJsPBun_8qBUBsstzQ8s5A@mail.gmail.com>
 <20140123083303.GI11155@yelena.nicm.ath.cx>
 <20140123112251.GA19903@gate.dtucker.net>
 <alpine.NEB.2.11.1401230759450.330@chris.i8u.org>
 <alpine.NEB.2.11.1401230915550.330@chris.i8u.org>
 <CALDDTe2EMsCGBaCXqXCyCmqPJ4+12WM4Ybg=vsxRnDyi8ZKeoA@mail.gmail.com>
 <alpine.NEB.2.11.1401231444260.330@chris.i8u.org>
 <alpine.NEB.2.11.1401231514290.330@chris.i8u.org>
 <alpine.BSO.2.11.1401241102440.14832@natsu.mindrot.org>
 <alpine.NEB.2.11.1401231605330.330@chris.i8u.org>
 <20140124100745.GA18706@gate.dtucker.net>
 <alpine.NEB.2.11.1401240851470.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401250655510.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241617390.12225@chris.i8u.org>
Message-ID: <alpine.BSO.2.11.1401251210530.24928@natsu.mindrot.org>



On Fri, 24 Jan 2014, Hisashi T Fujinaka wrote:

> On Sat, 25 Jan 2014, Damien Miller wrote:
> 
> > You'll probably need this patch too, to make sure you are testing the
> > right scp - our regress tests were incorrectly testing the system one
> > rather than the one that was just built:
> > 
> > 
> > commit b0e0f760b861676a3fe5c40133b270713d5321a9
> 
> I think I'm doing something wrong because I'm still stuck at the copy.
> Maybe I can get it to dump a core file.

There will be two sftp processes run in the test - see if you can get
a core and ktrace from each. I used something like this (patch from
memory):


Index: regress/scp-ssh-wrapper.sh
===================================================================
RCS file: /var/cvs/openssh/regress/scp-ssh-wrapper.sh,v
retrieving revision 1.4
diff -u -p -r1.4 scp-ssh-wrapper.sh
--- regress/scp-ssh-wrapper.sh	24 Jan 2014 03:27:06 -0000	1.4
+++ regress/scp-ssh-wrapper.sh	25 Jan 2014 01:12:30 -0000
@@ -54,6 +54,6 @@ badserver_4)
 *)
 	set -- $arg
 	shift
-	exec $SCP "$@"
+	exec ktruss -o /tmp/scp-remote.ktrace $SCP "$@"
 	;;
 esac
Index: regress/scp.sh
===================================================================
RCS file: /var/cvs/openssh/regress/scp.sh,v
retrieving revision 1.13
diff -u -p -r1.13 scp.sh
--- regress/scp.sh	24 Jan 2014 03:27:06 -0000	1.13
+++ regress/scp.sh	25 Jan 2014 01:13:12 -0000
@@ -29,63 +29,63 @@ scpclean() {
 
 verbose "$tid: simple copy local file to local file"
 scpclean
-$SCP $scpopts ${DATA} ${COPY} || fail "copy failed"
+ktruss -o /tmp/scp-local.ktrace $SCP $scpopts ${DATA} ${COPY} || fail "copy failed"
 cmp ${DATA} ${COPY} || fail "corrupted copy"
 
 verbose "$tid: simple copy local file to remote file"
 scpclean
-$SCP $scpopts ${DATA} somehost:${COPY} || fail "copy failed"
+ktruss -o /tmp/scp-local.ktrace $SCP $scpopts ${DATA} somehost:${COPY} || fail "copy failed"
 cmp ${DATA} ${COPY} || fail "corrupted copy"
 
 verbose "$tid: simple copy remote file to local file"
 scpclean
-$SCP $scpopts somehost:${DATA} ${COPY} || fail "copy failed"
+ktruss -o /tmp/scp-local.ktrace $SCP $scpopts somehost:${DATA} ${COPY} || fail "copy failed"
 cmp ${DATA} ${COPY} || fail "corrupted copy"
 
 verbose "$tid: simple copy local file to remote dir"
 scpclean
 cp ${DATA} ${COPY}
-$SCP $scpopts ${COPY} somehost:${DIR} || fail "copy failed"
+ktruss -o /tmp/scp-local.ktrace $SCP $scpopts ${COPY} somehost:${DIR} || fail "copy failed"
 cmp ${COPY} ${DIR}/copy || fail "corrupted copy"
 
 verbose "$tid: simple copy local file to local dir"
 scpclean
 cp ${DATA} ${COPY}
-$SCP $scpopts ${COPY} ${DIR} || fail "copy failed"
+ktruss -o /tmp/scp-local.ktrace $SCP $scpopts ${COPY} ${DIR} || fail "copy failed"
 cmp ${COPY} ${DIR}/copy || fail "corrupted copy"
 
 verbose "$tid: simple copy remote file to local dir"
 scpclean
 cp ${DATA} ${COPY}
-$SCP $scpopts somehost:${COPY} ${DIR} || fail "copy failed"
+ktruss -o /tmp/scp-local.ktrace $SCP $scpopts somehost:${COPY} ${DIR} || fail "copy failed"
 cmp ${COPY} ${DIR}/copy || fail "corrupted copy"
 
 verbose "$tid: recursive local dir to remote dir"
 scpclean
 rm -rf ${DIR2}
 cp ${DATA} ${DIR}/copy
-$SCP $scpopts -r ${DIR} somehost:${DIR2} || fail "copy failed"
+ktruss -o /tmp/scp-local.ktrace $SCP $scpopts -r ${DIR} somehost:${DIR2} || fail "copy failed"
 diff ${DIFFOPT} ${DIR} ${DIR2} || fail "corrupted copy"
 
 verbose "$tid: recursive local dir to local dir"
 scpclean
 rm -rf ${DIR2}
 cp ${DATA} ${DIR}/copy
-$SCP $scpopts -r ${DIR} ${DIR2} || fail "copy failed"
+ktruss -o /tmp/scp-local.ktrace $SCP $scpopts -r ${DIR} ${DIR2} || fail "copy failed"
 diff ${DIFFOPT} ${DIR} ${DIR2} || fail "corrupted copy"
 
 verbose "$tid: recursive remote dir to local dir"
 scpclean
 rm -rf ${DIR2}
 cp ${DATA} ${DIR}/copy
-$SCP $scpopts -r somehost:${DIR} ${DIR2} || fail "copy failed"
+ktruss -o /tmp/scp-local.ktrace $SCP $scpopts -r somehost:${DIR} ${DIR2} || fail "copy failed"
 diff ${DIFFOPT} ${DIR} ${DIR2} || fail "corrupted copy"
 
 verbose "$tid: shell metacharacters"
 scpclean
 (cd ${DIR} && \
 touch '`touch metachartest`' && \
-$SCP $scpopts *metachar* ${DIR2} 2>/dev/null; \
+ktruss -o /tmp/scp-local.ktrace $SCP $scpopts *metachar* ${DIR2} 2>/dev/null; \
 [ ! -f metachartest ] ) || fail "shell metacharacters"
 
 if [ ! -z "$SUDO" ]; then
@@ -119,7 +119,7 @@ verbose "$tid: detect non-directory targ
 scpclean
 echo a > ${COPY}
 echo b > ${COPY2}
-$SCP $scpopts ${DATA} ${COPY} ${COPY2}
+ktruss -o /tmp/scp-local.ktrace $SCP $scpopts ${DATA} ${COPY} ${COPY2}
 cmp ${COPY} ${COPY2} >/dev/null && fail "corrupt target"
 
 scpclean

From htodd at twofifty.com  Sat Jan 25 12:26:01 2014
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Fri, 24 Jan 2014 17:26:01 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.11.1401251210530.24928@natsu.mindrot.org>
References: <CALDDTe1e490W6CVxF2PgNstswQf0yJsPBun_8qBUBsstzQ8s5A@mail.gmail.com>
 <20140123083303.GI11155@yelena.nicm.ath.cx>
 <20140123112251.GA19903@gate.dtucker.net>
 <alpine.NEB.2.11.1401230759450.330@chris.i8u.org>
 <alpine.NEB.2.11.1401230915550.330@chris.i8u.org>
 <CALDDTe2EMsCGBaCXqXCyCmqPJ4+12WM4Ybg=vsxRnDyi8ZKeoA@mail.gmail.com>
 <alpine.NEB.2.11.1401231444260.330@chris.i8u.org>
 <alpine.NEB.2.11.1401231514290.330@chris.i8u.org>
 <alpine.BSO.2.11.1401241102440.14832@natsu.mindrot.org>
 <alpine.NEB.2.11.1401231605330.330@chris.i8u.org>
 <20140124100745.GA18706@gate.dtucker.net>
 <alpine.NEB.2.11.1401240851470.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401250655510.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241617390.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251210530.24928@natsu.mindrot.org>
Message-ID: <alpine.NEB.2.11.1401241725020.12225@chris.i8u.org>

>> I think I'm doing something wrong because I'm still stuck at the copy.
>> Maybe I can get it to dump a core file.

Duh. No wonder I was getting nothing. I was looking in the wrong directory.

Here's what I have before the last patch.

htodd at mara:~/openssh2 > gdb scp regress/scp.core
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64--netbsd".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/htodd/openssh2/scp...done.
[New process 1]
Core was generated by `scp'.
Program terminated with signal 3, Quit.
#0  0x00007f7ff623b06a in poll () from /usr/lib/libc.so.12
(gdb) bt
#0  0x00007f7ff623b06a in poll () from /usr/lib/libc.so.12
#1  0x0000000000407f6d in atomicio6 (f=0x4027d3 <read>, fd=0, _s=0x7f7ff7b32000, n=32768, cb=0x402801 <scpio>,
     cb_arg=0x7f7fffffbcb0) at atomicio.c:68
#2  0x00000000004039ee in sink (argc=<optimized out>, argv=<optimized out>) at scp.c:1107
#3  0x0000000000403d15 in sink (argc=<optimized out>, argv=<optimized out>) at scp.c:1071
#4  0x00000000004055ee in main (argc=<optimized out>, argv=<optimized out>) at scp.c:497
(gdb)

-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

From djm at mindrot.org  Sat Jan 25 13:24:43 2014
From: djm at mindrot.org (Damien Miller)
Date: Sat, 25 Jan 2014 13:24:43 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.NEB.2.11.1401241725020.12225@chris.i8u.org>
References: <CALDDTe1e490W6CVxF2PgNstswQf0yJsPBun_8qBUBsstzQ8s5A@mail.gmail.com>
 <20140123083303.GI11155@yelena.nicm.ath.cx>
 <20140123112251.GA19903@gate.dtucker.net>
 <alpine.NEB.2.11.1401230759450.330@chris.i8u.org>
 <alpine.NEB.2.11.1401230915550.330@chris.i8u.org>
 <CALDDTe2EMsCGBaCXqXCyCmqPJ4+12WM4Ybg=vsxRnDyi8ZKeoA@mail.gmail.com>
 <alpine.NEB.2.11.1401231444260.330@chris.i8u.org>
 <alpine.NEB.2.11.1401231514290.330@chris.i8u.org>
 <alpine.BSO.2.11.1401241102440.14832@natsu.mindrot.org>
 <alpine.NEB.2.11.1401231605330.330@chris.i8u.org>
 <20140124100745.GA18706@gate.dtucker.net>
 <alpine.NEB.2.11.1401240851470.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401250655510.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241617390.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251210530.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241725020.12225@chris.i8u.org>
Message-ID: <alpine.BSO.2.11.1401251318460.24928@natsu.mindrot.org>

On Fri, 24 Jan 2014, Hisashi T Fujinaka wrote:

> > > I think I'm doing something wrong because I'm still stuck at the copy.
> > > Maybe I can get it to dump a core file.
> 
> Duh. No wonder I was getting nothing. I was looking in the wrong directory.
> 
> Here's what I have before the last patch.

Right - we know it is hanging in poll because pfd.events is being
set incorrectly when -fstack-protector redirects the 'read' function.
Darren's patch should fix that by testing against write instead.

If you are able to get gdb attached to each, then the following
info would help:

The test that is running and, for each scp process (there are two, one
started from scp.sh and another from scp-ssh-wrapper.sh) via gdb:

'up' until you are in atomicio6()
print f
print read
print write
print pfd.events

From htodd at twofifty.com  Sat Jan 25 14:55:54 2014
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Fri, 24 Jan 2014 19:55:54 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.11.1401251318460.24928@natsu.mindrot.org>
References: <CALDDTe1e490W6CVxF2PgNstswQf0yJsPBun_8qBUBsstzQ8s5A@mail.gmail.com>
 <20140123083303.GI11155@yelena.nicm.ath.cx>
 <20140123112251.GA19903@gate.dtucker.net>
 <alpine.NEB.2.11.1401230759450.330@chris.i8u.org>
 <alpine.NEB.2.11.1401230915550.330@chris.i8u.org>
 <CALDDTe2EMsCGBaCXqXCyCmqPJ4+12WM4Ybg=vsxRnDyi8ZKeoA@mail.gmail.com>
 <alpine.NEB.2.11.1401231444260.330@chris.i8u.org>
 <alpine.NEB.2.11.1401231514290.330@chris.i8u.org>
 <alpine.BSO.2.11.1401241102440.14832@natsu.mindrot.org>
 <alpine.NEB.2.11.1401231605330.330@chris.i8u.org>
 <20140124100745.GA18706@gate.dtucker.net>
 <alpine.NEB.2.11.1401240851470.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401250655510.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241617390.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251210530.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241725020.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251318460.24928@natsu.mindrot.org>
Message-ID: <alpine.NEB.2.11.1401241955090.12225@chris.i8u.org>

On Sat, 25 Jan 2014, Damien Miller wrote:

> On Fri, 24 Jan 2014, Hisashi T Fujinaka wrote:
>
>>>> I think I'm doing something wrong because I'm still stuck at the copy.
>>>> Maybe I can get it to dump a core file.
>>
>> Duh. No wonder I was getting nothing. I was looking in the wrong directory.
>>
>> Here's what I have before the last patch.
>
> Right - we know it is hanging in poll because pfd.events is being
> set incorrectly when -fstack-protector redirects the 'read' function.
> Darren's patch should fix that by testing against write instead.
>
> If you are able to get gdb attached to each, then the following
> info would help:
>
> The test that is running and, for each scp process (there are two, one
> started from scp.sh and another from scp-ssh-wrapper.sh) via gdb:
>
> 'up' until you are in atomicio6()
> print f
> print read
> print write
> print pfd.events

I may have done this incorrectly, but here's what I saw.

ra:~/openssh > ps auxw | grep ssh
root      773  0.0  0.0  57544  3012 ?     Is    8:15PM 0:00.01 /usr/sbin/sshd
root      780  0.0  0.1  76624  5952 ?     Is    8:15PM 0:00.02 sshd: htodd [priv]
htodd    1041  0.0  0.0  76624  4152 ?     S     8:15PM 0:01.38 sshd: htodd at pts/0 (sshd)
htodd    1045  0.0  0.0  19532  2452 ?     Is    8:15PM 0:00.22 ssh-agent
htodd     804  0.0  0.0  13304  1524 pts/1 I+    5:35PM 0:00.00 sh /home/htodd/openssh/regress/test-exec.sh /home/htodd/openssh/reg
htodd    8150  0.0  0.0  19344  2400 pts/1 I+    5:35PM 0:00.00 /home/htodd/openssh/scp -q -S /home/htodd/openssh/regress/scp-ssh-w
htodd   26374  0.0  0.0  19344  2364 pts/1 I+    5:35PM 0:00.00 /home/htodd/openssh/scp -t /home/htodd/openssh/regress/copy
htodd   21579  0.0  0.0   2240    48 pts/2 R+    7:51PM 0:00.00 grep ssh
htodd at mara:~/openssh > gdb ssh
ssh               ssh-agent         ssh-keyscan       ssh-pkcs11-helper
ssh-add           ssh-keygen        ssh-keysign       sshd
htodd at mara:~/openssh > gdb ssh 8150
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64--netbsd".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/htodd/openssh/ssh...done.
Attaching to program: /home/htodd/openssh/ssh, process 8150
Reading symbols from /usr/libexec/ld.elf_so...Reading symbols from /usr/libdata/debug/libexec/ld.elf_so.debug...done.
done.
Loaded symbols for /usr/libexec/ld.elf_so
0x00007f7ff623b06a in .rtld_start () from /usr/libexec/ld.elf_so
(gdb) up
#1  0x0000000000407f6d in ssh_confirm_remote_forward (type=4203424, seq=<optimized out>, ctxt=0x6) at ssh.c:1230
1230            if (++remote_forward_confirms_received == options.num_remote_forwards) {
(gdb) up
#2  0x0000000000010000 in ?? ()
(gdb) up
#3  0x0000000000000000 in ?? ()
(gdb) up
Initial frame selected; you cannot go up.
(gdb) down
#2  0x0000000000010000 in ?? ()
(gdb) down
#1  0x0000000000407f6d in ssh_confirm_remote_forward (type=4203424, seq=<optimized out>, ctxt=0x6) at ssh.c:1230
1230            if (++remote_forward_confirms_received == options.num_remote_forwards) {
(gdb) print read
Cannot access memory at address 0x43fe00
(gdb) print write
$1 = {<text variable, no debug info>} 0x7f7ff624474a <write>
(gdb) q
A debugging session is active.

         Inferior 1 [process 8150] will be detached.

Quit anyway? (y or n) y
Detaching from program: /home/htodd/openssh/ssh, process 8150
htodd at mara:~/openssh > gdb ssh 26374
GNU gdb (GDB) 7.6.1
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64--netbsd".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/htodd/openssh/ssh...done.
Attaching to program: /home/htodd/openssh/ssh, process 26374
Reading symbols from /usr/libexec/ld.elf_so...Reading symbols from /usr/libdata/debug/libexec/ld.elf_so.debug...done.
done.
Loaded symbols for /usr/libexec/ld.elf_so
0x00007f7ff623b06a in .rtld_start () from /usr/libexec/ld.elf_so
(gdb) up
#1  0x0000000000407f6d in ssh_confirm_remote_forward (type=4204499, seq=<optimized out>, ctxt=0x0) at ssh.c:1230
1230            if (++remote_forward_confirms_received == options.num_remote_forwards) {
(gdb) print read
Cannot access memory at address 0x43fe00
(gdb) print write
$1 = {<text variable, no debug info>} 0x7f7ff624474a <write>
(gdb) print pfd.events
No symbol "pfd" in current context.
(gdb) q
A debugging session is active.

         Inferior 1 [process 26374] will be detached.

Quit anyway? (y or n) y
Detaching from program: /home/htodd/openssh/ssh, process 26374
htodd at mara:~/openssh >

-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

From dtucker at zip.com.au  Sat Jan 25 15:14:57 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 25 Jan 2014 15:14:57 +1100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.NEB.2.11.1401241955090.12225@chris.i8u.org>
References: <alpine.BSO.2.11.1401241102440.14832@natsu.mindrot.org>
 <alpine.NEB.2.11.1401231605330.330@chris.i8u.org>
 <20140124100745.GA18706@gate.dtucker.net>
 <alpine.NEB.2.11.1401240851470.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401250655510.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241617390.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251210530.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241725020.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251318460.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241955090.12225@chris.i8u.org>
Message-ID: <20140125041457.GA525@gate.dtucker.net>

Maybe there's something wrapping write() on your system too?  Try adding
this to the start of atomicio.c:atomicio6():

printf(stderr, "read %x write %x argument %x\n", read, vwrite, f);

then compile it and run a small scp:

$ ./scp testfile localhost:/tmp/
read b73eced0 write b73ecf50 argument b73eced0

The patch below makes the first argument to atomicio an int rather than
a function pointer.

On the plus side: it also allows the removal of some hacks around
vwrite/writev.  On the minus side: it's a large change albeit mostly
mechanical.

Index: atomicio.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/atomicio.c,v
retrieving revision 1.40
diff -u -p -r1.40 atomicio.c
--- atomicio.c	24 Sep 2010 12:15:11 -0000	1.40
+++ atomicio.c	25 Jan 2014 04:04:41 -0000
@@ -45,10 +45,10 @@
 #include "atomicio.h"
 
 /*
- * ensure all of data on socket comes through. f==read || f==vwrite
+ * ensure all of data on socket comes through.
  */
 size_t
-atomicio6(ssize_t (*f) (int, void *, size_t), int fd, void *_s, size_t n,
+atomicio6(int operation, int fd, void *_s, size_t n,
     int (*cb)(void *, size_t), void *cb_arg)
 {
 	char *s = _s;
@@ -57,9 +57,12 @@ atomicio6(ssize_t (*f) (int, void *, siz
 	struct pollfd pfd;
 
 	pfd.fd = fd;
-	pfd.events = f == read ? POLLIN : POLLOUT;
+	pfd.events = operation == ATOMICIO_READ ? POLLIN : POLLOUT;
 	while (n > pos) {
-		res = (f) (fd, s + pos, n - pos);
+		if (operation == ATOMICIO_READ)
+			res = read(fd, s + pos, n - pos);
+		else
+			res = write(fd, s + pos, n - pos);
 		switch (res) {
 		case -1:
 			if (errno == EINTR)
@@ -84,17 +87,16 @@ atomicio6(ssize_t (*f) (int, void *, siz
 }
 
 size_t
-atomicio(ssize_t (*f) (int, void *, size_t), int fd, void *_s, size_t n)
+atomicio(int operation, int fd, void *_s, size_t n)
 {
-	return atomicio6(f, fd, _s, n, NULL, NULL);
+	return atomicio6(operation, fd, _s, n, NULL, NULL);
 }
 
 /*
- * ensure all of data on socket comes through. f==readv || f==writev
+ * ensure all of data on socket comes through.
  */
 size_t
-atomiciov6(ssize_t (*f) (int, const struct iovec *, int), int fd,
-    const struct iovec *_iov, int iovcnt,
+atomiciov6(int operation, int fd, const struct iovec *_iov, int iovcnt,
     int (*cb)(void *, size_t), void *cb_arg)
 {
 	size_t pos = 0, rem;
@@ -109,20 +111,20 @@ atomiciov6(ssize_t (*f) (int, const stru
 	/* Make a copy of the iov array because we may modify it below */
 	memcpy(iov, _iov, iovcnt * sizeof(*_iov));
 
-#ifndef BROKEN_READV_COMPARISON
 	pfd.fd = fd;
-	pfd.events = f == readv ? POLLIN : POLLOUT;
-#endif
+	pfd.events = operation == ATOMICIO_READ ? POLLIN : POLLOUT;
+
 	for (; iovcnt > 0 && iov[0].iov_len > 0;) {
-		res = (f) (fd, iov, iovcnt);
+		if (operation == ATOMICIO_READ)
+			res = readv(fd, iov, iovcnt);
+		else
+			res = writev(fd, iov, iovcnt);
 		switch (res) {
 		case -1:
 			if (errno == EINTR)
 				continue;
 			if (errno == EAGAIN || errno == EWOULDBLOCK) {
-#ifndef BROKEN_READV_COMPARISON
 				(void)poll(&pfd, 1, -1);
-#endif
 				continue;
 			}
 			return 0;
@@ -158,8 +160,8 @@ atomiciov6(ssize_t (*f) (int, const stru
 }
 
 size_t
-atomiciov(ssize_t (*f) (int, const struct iovec *, int), int fd,
+atomiciov(int operation, int fd,
     const struct iovec *_iov, int iovcnt)
 {
-	return atomiciov6(f, fd, _iov, iovcnt, NULL, NULL);
+	return atomiciov6(operation, fd, _iov, iovcnt, NULL, NULL);
 }
Index: atomicio.h
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/atomicio.h,v
retrieving revision 1.11
diff -u -p -r1.11 atomicio.h
--- atomicio.h	24 Sep 2010 12:15:11 -0000	1.11
+++ atomicio.h	25 Jan 2014 03:54:08 -0000
@@ -29,23 +29,21 @@
 #ifndef _ATOMICIO_H
 #define _ATOMICIO_H
 
+#define ATOMICIO_READ	0
+#define ATOMICIO_WRITE	1
+
 /*
  * Ensure all of data on socket comes through. f==read || f==vwrite
  */
-size_t
-atomicio6(ssize_t (*f) (int, void *, size_t), int fd, void *_s, size_t n,
+size_t atomicio6(int operation, int fd, void *_s, size_t n,
     int (*cb)(void *, size_t), void *);
-size_t	atomicio(ssize_t (*)(int, void *, size_t), int, void *, size_t);
-
-#define vwrite (ssize_t (*)(int, void *, size_t))write
+size_t	atomicio(int operation, int, void *, size_t);
 
 /*
  * ensure all of data on socket comes through. f==readv || f==writev
  */
-size_t
-atomiciov6(ssize_t (*f) (int, const struct iovec *, int), int fd,
+size_t atomiciov6(int operation, int fd,
     const struct iovec *_iov, int iovcnt, int (*cb)(void *, size_t), void *);
-size_t	atomiciov(ssize_t (*)(int, const struct iovec *, int),
-    int, const struct iovec *, int);
+size_t	atomiciov(int operation, int, const struct iovec *, int);
 
 #endif /* _ATOMICIO_H */
Index: auth2.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/auth2.c,v
retrieving revision 1.159
diff -u -p -r1.159 auth2.c
--- auth2.c	1 Jun 2013 21:41:51 -0000	1.159
+++ auth2.c	25 Jan 2014 03:54:07 -0000
@@ -126,7 +126,7 @@ auth2_read_banner(void)
 
 	len = (size_t)st.st_size;		/* truncate */
 	banner = xmalloc(len + 1);
-	n = atomicio(read, fd, banner, len);
+	n = atomicio(ATOMICIO_READ, fd, banner, len);
 	close(fd);
 
 	if (n != len) {
Index: authfd.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/authfd.c,v
retrieving revision 1.88
diff -u -p -r1.88 authfd.c
--- authfd.c	29 Dec 2013 06:49:56 -0000	1.88
+++ authfd.c	25 Jan 2014 03:54:11 -0000
@@ -134,8 +134,8 @@ ssh_request_reply(AuthenticationConnecti
 	put_u32(buf, len);
 
 	/* Send the length and then the packet to the agent. */
-	if (atomicio(vwrite, auth->fd, buf, 4) != 4 ||
-	    atomicio(vwrite, auth->fd, buffer_ptr(request),
+	if (atomicio(ATOMICIO_WRITE, auth->fd, buf, 4) != 4 ||
+	    atomicio(ATOMICIO_WRITE, auth->fd, buffer_ptr(request),
 	    buffer_len(request)) != buffer_len(request)) {
 		error("Error writing to authentication socket.");
 		return 0;
@@ -144,7 +144,7 @@ ssh_request_reply(AuthenticationConnecti
 	 * Wait for response from the agent.  First read the length of the
 	 * response packet.
 	 */
-	if (atomicio(read, auth->fd, buf, 4) != 4) {
+	if (atomicio(ATOMICIO_READ, auth->fd, buf, 4) != 4) {
 	    error("Error reading response length from authentication socket.");
 	    return 0;
 	}
@@ -160,7 +160,7 @@ ssh_request_reply(AuthenticationConnecti
 		l = len;
 		if (l > sizeof(buf))
 			l = sizeof(buf);
-		if (atomicio(read, auth->fd, buf, l) != l) {
+		if (atomicio(ATOMICIO_READ, auth->fd, buf, l) != l) {
 			error("Error reading response from authentication socket.");
 			return 0;
 		}
Index: authfile.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/authfile.c,v
retrieving revision 1.106
diff -u -p -r1.106 authfile.c
--- authfile.c	29 Dec 2013 06:50:15 -0000	1.106
+++ authfile.c	25 Jan 2014 03:54:12 -0000
@@ -568,7 +568,7 @@ key_save_private_blob(Buffer *keybuf, co
 		error("open %s failed: %s.", filename, strerror(errno));
 		return 0;
 	}
-	if (atomicio(vwrite, fd, buffer_ptr(keybuf),
+	if (atomicio(ATOMICIO_WRITE, fd, buffer_ptr(keybuf),
 	    buffer_len(keybuf)) != buffer_len(keybuf)) {
 		error("write to key file %s failed: %s", filename,
 		    strerror(errno));
@@ -696,7 +696,7 @@ key_load_file(int fd, const char *filena
 	}
 	buffer_clear(blob);
 	for (;;) {
-		if ((len = atomicio(read, fd, buf, sizeof(buf))) == 0) {
+		if ((len = atomicio(ATOMICIO_READ, fd, buf, sizeof(buf))) == 0) {
 			if (errno == EPIPE)
 				break;
 			debug("%s: read from key file %.200s%sfailed: %.100s",
Index: clientloop.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/clientloop.c,v
retrieving revision 1.245
diff -u -p -r1.245 clientloop.c
--- clientloop.c	21 Nov 2013 02:57:15 -0000	1.245
+++ clientloop.c	25 Jan 2014 03:54:08 -0000
@@ -687,10 +687,10 @@ client_suspend_self(Buffer *bin, Buffer 
 {
 	/* Flush stdout and stderr buffers. */
 	if (buffer_len(bout) > 0)
-		atomicio(vwrite, fileno(stdout), buffer_ptr(bout),
+		atomicio(ATOMICIO_WRITE, fileno(stdout), buffer_ptr(bout),
 		    buffer_len(bout));
 	if (buffer_len(berr) > 0)
-		atomicio(vwrite, fileno(stderr), buffer_ptr(berr),
+		atomicio(ATOMICIO_WRITE, fileno(stderr), buffer_ptr(berr),
 		    buffer_len(berr));
 
 	leave_raw_mode(options.request_tty == REQUEST_TTY_FORCE);
@@ -1714,7 +1714,7 @@ client_loop(int have_pty, int escape_cha
 
 	/* Output any buffered data for stdout. */
 	if (buffer_len(&stdout_buffer) > 0) {
-		len = atomicio(vwrite, fileno(stdout),
+		len = atomicio(ATOMICIO_WRITE, fileno(stdout),
 		    buffer_ptr(&stdout_buffer), buffer_len(&stdout_buffer));
 		if (len < 0 || (u_int)len != buffer_len(&stdout_buffer))
 			error("Write failed flushing stdout buffer.");
@@ -1724,7 +1724,7 @@ client_loop(int have_pty, int escape_cha
 
 	/* Output any buffered data for stderr. */
 	if (buffer_len(&stderr_buffer) > 0) {
-		len = atomicio(vwrite, fileno(stderr),
+		len = atomicio(ATOMICIO_WRITE, fileno(stderr),
 		    buffer_ptr(&stderr_buffer), buffer_len(&stderr_buffer));
 		if (len < 0 || (u_int)len != buffer_len(&stderr_buffer))
 			error("Write failed flushing stderr buffer.");
Index: entropy.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/entropy.c,v
retrieving revision 1.63
diff -u -p -r1.63 entropy.c
--- entropy.c	30 Mar 2012 00:34:27 -0000	1.63
+++ entropy.c	25 Jan 2014 03:54:07 -0000
@@ -130,7 +130,7 @@ reopen:
 	msg[0] = 0x02;
 	msg[1] = len;
 
-	if (atomicio(vwrite, fd, msg, sizeof(msg)) != sizeof(msg)) {
+	if (atomicio(ATOMICIO_WRITE, fd, msg, sizeof(msg)) != sizeof(msg)) {
 		if (errno == EPIPE && errors < 10) {
 			close(fd);
 			errors++;
@@ -141,7 +141,7 @@ reopen:
 		goto done;
 	}
 
-	if (atomicio(read, fd, buf, len) != (size_t)len) {
+	if (atomicio(ATOMICIO_READ, fd, buf, len) != (size_t)len) {
 		if (errno == EPIPE && errors < 10) {
 			close(fd);
 			errors++;
Index: loginrec.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/loginrec.c,v
retrieving revision 1.94
diff -u -p -r1.94 loginrec.c
--- loginrec.c	17 Jan 2014 01:23:24 -0000	1.94
+++ loginrec.c	25 Jan 2014 03:54:08 -0000
@@ -886,7 +886,7 @@ utmp_write_direct(struct logininfo *li, 
 		 * If the new ut_line is empty but the old one is not
 		 * and ut_line and ut_name match, preserve the old ut_line.
 		 */
-		if (atomicio(read, fd, &old_ut, sizeof(old_ut)) == sizeof(old_ut) &&
+		if (atomicio(ATOMICIO_READ, fd, &old_ut, sizeof(old_ut)) == sizeof(old_ut) &&
 		    (ut->ut_host[0] == '\0') && (old_ut.ut_host[0] != '\0') &&
 		    (strncmp(old_ut.ut_line, ut->ut_line, sizeof(ut->ut_line)) == 0) &&
 		    (strncmp(old_ut.ut_name, ut->ut_name, sizeof(ut->ut_name)) == 0))
@@ -903,7 +903,7 @@ utmp_write_direct(struct logininfo *li, 
 			close(fd);
 			return (0);
 		}
-		if (atomicio(vwrite, fd, ut, sizeof(*ut)) != sizeof(*ut)) {
+		if (atomicio(ATOMICIO_WRITE, fd, ut, sizeof(*ut)) != sizeof(*ut)) {
 			logit("%s: error writing %s: %s", __func__,
 			    UTMP_FILE, strerror(errno));
 			close(fd);
@@ -1097,7 +1097,7 @@ wtmp_write(struct logininfo *li, struct 
 		return (0);
 	}
 	if (fstat(fd, &buf) == 0)
-		if (atomicio(vwrite, fd, ut, sizeof(*ut)) != sizeof(*ut)) {
+		if (atomicio(ATOMICIO_WRITE, fd, ut, sizeof(*ut)) != sizeof(*ut)) {
 			ftruncate(fd, buf.st_size);
 			logit("%s: problem writing %s: %s", __func__,
 			    WTMP_FILE, strerror(errno));
@@ -1205,7 +1205,7 @@ wtmp_get_entry(struct logininfo *li)
 	}
 
 	while (!found) {
-		if (atomicio(read, fd, &ut, sizeof(ut)) != sizeof(ut)) {
+		if (atomicio(ATOMICIO_READ, fd, &ut, sizeof(ut)) != sizeof(ut)) {
 			logit("%s: read of %s failed: %s", __func__,
 			    WTMP_FILE, strerror(errno));
 			close (fd);
@@ -1270,7 +1270,7 @@ wtmpx_write(struct logininfo *li, struct
 	}
 
 	if (fstat(fd, &buf) == 0)
-		if (atomicio(vwrite, fd, utx, sizeof(*utx)) != sizeof(*utx)) {
+		if (atomicio(ATOMICIO_WRITE, fd, utx, sizeof(*utx)) != sizeof(*utx)) {
 			ftruncate(fd, buf.st_size);
 			logit("%s: problem writing %s: %s", __func__,
 			    WTMPX_FILE, strerror(errno));
@@ -1370,7 +1370,7 @@ wtmpx_get_entry(struct logininfo *li)
 	}
 
 	while (!found) {
-		if (atomicio(read, fd, &utx, sizeof(utx)) != sizeof(utx)) {
+		if (atomicio(ATOMICIO_READ, fd, &utx, sizeof(utx)) != sizeof(utx)) {
 			logit("%s: read of %s failed: %s", __func__,
 			    WTMPX_FILE, strerror(errno));
 			close (fd);
@@ -1548,7 +1548,7 @@ lastlog_write_entry(struct logininfo *li
 			return (0);
 	
 		/* write the entry */
-		if (atomicio(vwrite, fd, &last, sizeof(last)) != sizeof(last)) {
+		if (atomicio(ATOMICIO_WRITE, fd, &last, sizeof(last)) != sizeof(last)) {
 			close(fd);
 			logit("%s: Error writing to %s: %s", __func__,
 			    LASTLOG_FILE, strerror(errno));
@@ -1591,7 +1591,7 @@ lastlog_get_entry(struct logininfo *li)
 	if (!lastlog_openseek(li, &fd, O_RDONLY))
 		return (0);
 
-	ret = atomicio(read, fd, &last, sizeof(last));
+	ret = atomicio(ATOMICIO_READ, fd, &last, sizeof(last));
 	close(fd);
 
 	switch (ret) {
@@ -1716,7 +1716,7 @@ record_failed_login(const char *username
 #endif
 	}
 
-	if (atomicio(vwrite, fd, &ut, sizeof(ut)) != sizeof(ut))
+	if (atomicio(ATOMICIO_WRITE, fd, &ut, sizeof(ut)) != sizeof(ut))
 		error("Failed to write to %s: %s", _PATH_BTMP,
 		    strerror(errno));
 
Index: monitor.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/monitor.c,v
retrieving revision 1.166
diff -u -p -r1.166 monitor.c
--- monitor.c	7 Nov 2013 02:32:52 -0000	1.166
+++ monitor.c	25 Jan 2014 03:54:07 -0000
@@ -520,7 +520,7 @@ monitor_read_log(struct monitor *pmonito
 
 	/* Read length */
 	buffer_append_space(&logmsg, 4);
-	if (atomicio(read, pmonitor->m_log_recvfd,
+	if (atomicio(ATOMICIO_READ, pmonitor->m_log_recvfd,
 	    buffer_ptr(&logmsg), buffer_len(&logmsg)) != buffer_len(&logmsg)) {
 		if (errno == EPIPE) {
 			buffer_free(&logmsg);
@@ -538,7 +538,7 @@ monitor_read_log(struct monitor *pmonito
 	/* Read severity, message */
 	buffer_clear(&logmsg);
 	buffer_append_space(&logmsg, len);
-	if (atomicio(read, pmonitor->m_log_recvfd,
+	if (atomicio(ATOMICIO_READ, pmonitor->m_log_recvfd,
 	    buffer_ptr(&logmsg), buffer_len(&logmsg)) != buffer_len(&logmsg))
 		fatal("%s: log fd read: %s", __func__, strerror(errno));
 
Index: monitor_wrap.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/monitor_wrap.c,v
retrieving revision 1.95
diff -u -p -r1.95 monitor_wrap.c
--- monitor_wrap.c	7 Nov 2013 02:35:39 -0000	1.95
+++ monitor_wrap.c	25 Jan 2014 03:54:12 -0000
@@ -108,7 +108,7 @@ mm_log_handler(LogLevel level, const cha
 	buffer_put_int(&log_msg, level);
 	buffer_put_cstring(&log_msg, msg);
 	put_u32(buffer_ptr(&log_msg), buffer_len(&log_msg) - 4);
-	if (atomicio(vwrite, mon->m_log_sendfd, buffer_ptr(&log_msg),
+	if (atomicio(ATOMICIO_WRITE, mon->m_log_sendfd, buffer_ptr(&log_msg),
 	    buffer_len(&log_msg)) != buffer_len(&log_msg))
 		fatal("%s: write: %s", __func__, strerror(errno));
 	buffer_free(&log_msg);
@@ -134,9 +134,9 @@ mm_request_send(int sock, enum monitor_r
 
 	put_u32(buf, mlen + 1);
 	buf[4] = (u_char) type;		/* 1st byte of payload is mesg-type */
-	if (atomicio(vwrite, sock, buf, sizeof(buf)) != sizeof(buf))
+	if (atomicio(ATOMICIO_WRITE, sock, buf, sizeof(buf)) != sizeof(buf))
 		fatal("%s: write: %s", __func__, strerror(errno));
-	if (atomicio(vwrite, sock, buffer_ptr(m), mlen) != mlen)
+	if (atomicio(ATOMICIO_WRITE, sock, buffer_ptr(m), mlen) != mlen)
 		fatal("%s: write: %s", __func__, strerror(errno));
 }
 
@@ -148,7 +148,7 @@ mm_request_receive(int sock, Buffer *m)
 
 	debug3("%s entering", __func__);
 
-	if (atomicio(read, sock, buf, sizeof(buf)) != sizeof(buf)) {
+	if (atomicio(ATOMICIO_READ, sock, buf, sizeof(buf)) != sizeof(buf)) {
 		if (errno == EPIPE)
 			cleanup_exit(255);
 		fatal("%s: read: %s", __func__, strerror(errno));
@@ -158,7 +158,7 @@ mm_request_receive(int sock, Buffer *m)
 		fatal("%s: read: bad msg_len %d", __func__, msg_len);
 	buffer_clear(m);
 	buffer_append_space(m, msg_len);
-	if (atomicio(read, sock, buffer_ptr(m), msg_len) != msg_len)
+	if (atomicio(ATOMICIO_READ, sock, buffer_ptr(m), msg_len) != msg_len)
 		fatal("%s: read: %s", __func__, strerror(errno));
 }
 
Index: msg.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/msg.c,v
retrieving revision 1.16
diff -u -p -r1.16 msg.c
--- msg.c	5 Aug 2006 02:39:40 -0000	1.16
+++ msg.c	25 Jan 2014 03:54:06 -0000
@@ -50,11 +50,11 @@ ssh_msg_send(int fd, u_char type, Buffer
 
 	put_u32(buf, mlen + 1);
 	buf[4] = type;		/* 1st byte of payload is mesg-type */
-	if (atomicio(vwrite, fd, buf, sizeof(buf)) != sizeof(buf)) {
+	if (atomicio(ATOMICIO_WRITE, fd, buf, sizeof(buf)) != sizeof(buf)) {
 		error("ssh_msg_send: write");
 		return (-1);
 	}
-	if (atomicio(vwrite, fd, buffer_ptr(m), mlen) != mlen) {
+	if (atomicio(ATOMICIO_WRITE, fd, buffer_ptr(m), mlen) != mlen) {
 		error("ssh_msg_send: write");
 		return (-1);
 	}
@@ -69,7 +69,7 @@ ssh_msg_recv(int fd, Buffer *m)
 
 	debug3("ssh_msg_recv entering");
 
-	if (atomicio(read, fd, buf, sizeof(buf)) != sizeof(buf)) {
+	if (atomicio(ATOMICIO_READ, fd, buf, sizeof(buf)) != sizeof(buf)) {
 		if (errno != EPIPE)
 			error("ssh_msg_recv: read: header");
 		return (-1);
@@ -81,7 +81,7 @@ ssh_msg_recv(int fd, Buffer *m)
 	}
 	buffer_clear(m);
 	buffer_append_space(m, msg_len);
-	if (atomicio(read, fd, buffer_ptr(m), msg_len) != msg_len) {
+	if (atomicio(ATOMICIO_READ, fd, buffer_ptr(m), msg_len) != msg_len) {
 		error("ssh_msg_recv: read: %s", strerror(errno));
 		return (-1);
 	}
Index: progressmeter.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/progressmeter.c,v
retrieving revision 1.41
diff -u -p -r1.41 progressmeter.c
--- progressmeter.c	9 Oct 2013 23:25:10 -0000	1.41
+++ progressmeter.c	25 Jan 2014 03:54:09 -0000
@@ -223,7 +223,7 @@ refresh_progress_meter(void)
 			strlcat(buf, "    ", win_size);
 	}
 
-	atomicio(vwrite, STDOUT_FILENO, buf, win_size - 1);
+	atomicio(ATOMICIO_WRITE, STDOUT_FILENO, buf, win_size - 1);
 	last_update = now;
 }
 
@@ -280,7 +280,7 @@ stop_progress_meter(void)
 	if (cur_pos != end_pos)
 		refresh_progress_meter();
 
-	atomicio(vwrite, STDOUT_FILENO, "\n", 1);
+	atomicio(ATOMICIO_WRITE, STDOUT_FILENO, "\n", 1);
 }
 
 /*ARGSUSED*/
Index: roaming.h
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/roaming.h,v
retrieving revision 1.5
diff -u -p -r1.5 roaming.h
--- roaming.h	18 Dec 2011 23:52:52 -0000	1.5
+++ roaming.h	25 Jan 2014 03:54:06 -0000
@@ -34,7 +34,7 @@ void	roaming_reply(int, u_int32_t, void 
 void	set_out_buffer_size(size_t);
 ssize_t	roaming_write(int, const void *, size_t, int *);
 ssize_t	roaming_read(int, void *, size_t, int *);
-size_t	roaming_atomicio(ssize_t (*)(int, void *, size_t), int, void *, size_t);
+size_t	roaming_atomicio(int, int, void *, size_t);
 u_int64_t	get_recv_bytes(void);
 u_int64_t	get_sent_bytes(void);
 void	roam_set_bytes(u_int64_t, u_int64_t);
Index: roaming_common.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/roaming_common.c,v
retrieving revision 1.11
diff -u -p -r1.11 roaming_common.c
--- roaming_common.c	9 Jan 2014 23:58:53 -0000	1.11
+++ roaming_common.c	25 Jan 2014 03:54:12 -0000
@@ -183,14 +183,14 @@ roaming_read(int fd, void *buf, size_t c
 }
 
 size_t
-roaming_atomicio(ssize_t(*f)(int, void*, size_t), int fd, void *buf,
+roaming_atomicio(int op, int fd, void *buf,
     size_t count)
 {
-	size_t ret = atomicio(f, fd, buf, count);
+	size_t ret = atomicio(op, fd, buf, count);
 
-	if (f == vwrite && ret > 0 && !resume_in_progress) {
+	if (op == ATOMICIO_WRITE && ret > 0 && !resume_in_progress) {
 		write_bytes += ret;
-	} else if (f == read && ret > 0 && !resume_in_progress) {
+	} else if (op == ATOMICIO_WRITE && ret > 0 && !resume_in_progress) {
 		read_bytes += ret;
 	}
 	return ret;
@@ -212,11 +212,11 @@ resend_bytes(int fd, u_int64_t *offset)
 		fatal("Needed to resend more data than in the cache");
 	if (out_last < needed) {
 		int chunkend = needed - out_last;
-		atomicio(vwrite, fd, out_buf + out_buf_size - chunkend,
+		atomicio(ATOMICIO_WRITE, fd, out_buf + out_buf_size - chunkend,
 		    chunkend);
-		atomicio(vwrite, fd, out_buf, out_last);
+		atomicio(ATOMICIO_WRITE, fd, out_buf, out_last);
 	} else {
-		atomicio(vwrite, fd, out_buf + (out_last - needed), needed);
+		atomicio(ATOMICIO_WRITE, fd, out_buf + (out_last - needed), needed);
 	}
 }
 
Index: scp.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/scp.c,v
retrieving revision 1.198
diff -u -p -r1.198 scp.c
--- scp.c	21 Nov 2013 02:56:49 -0000	1.198
+++ scp.c	25 Jan 2014 03:54:06 -0000
@@ -564,7 +564,7 @@ do_times(int fd, int verb, const struct 
 		    (long long)sb->st_mtime, (long long)sb->st_atime);
 		fprintf(stderr, "Sending file timestamps: %s", buf);
 	}
-	(void) atomicio(vwrite, fd, buf, strlen(buf));
+	(void) atomicio(ATOMICIO_WRITE, fd, buf, strlen(buf));
 	return (response());
 }
 
@@ -802,7 +802,7 @@ syserr:			run_err("%s: %s", name, strerr
 		if (verbose_mode) {
 			fprintf(stderr, "Sending file modes: %s", buf);
 		}
-		(void) atomicio(vwrite, remout, buf, strlen(buf));
+		(void) atomicio(ATOMICIO_WRITE, remout, buf, strlen(buf));
 		if (response() < 0)
 			goto next;
 		if ((bp = allocbuf(&buffer, fd, COPY_BUFLEN)) == NULL) {
@@ -820,16 +820,16 @@ next:			if (fd != -1) {
 			if (i + (off_t)amt > stb.st_size)
 				amt = stb.st_size - i;
 			if (!haderr) {
-				if (atomicio(read, fd, bp->buf, amt) != amt)
+				if (atomicio(ATOMICIO_READ, fd, bp->buf, amt) != amt)
 					haderr = errno;
 			}
 			/* Keep writing after error to retain sync */
 			if (haderr) {
-				(void)atomicio(vwrite, remout, bp->buf, amt);
+				(void)atomicio(ATOMICIO_WRITE, remout, bp->buf, amt);
 				continue;
 			}
-			if (atomicio6(vwrite, remout, bp->buf, amt, scpio,
-			    &statbytes) != amt)
+			if (atomicio6(ATOMICIO_WRITE, remout, bp->buf, amt,
+			    scpio, &statbytes) != amt)
 				haderr = errno;
 		}
 		unset_nonblock(remout);
@@ -842,7 +842,7 @@ next:			if (fd != -1) {
 			fd = -1;
 		}
 		if (!haderr)
-			(void) atomicio(vwrite, remout, "", 1);
+			(void) atomicio(ATOMICIO_WRITE, remout, "", 1);
 		else
 			run_err("%s: %s", name, strerror(haderr));
 		(void) response();
@@ -875,7 +875,7 @@ rsource(char *name, struct stat *statp)
 	    (u_int) (statp->st_mode & FILEMODEMASK), 0, last);
 	if (verbose_mode)
 		fprintf(stderr, "Entering directory: %s", path);
-	(void) atomicio(vwrite, remout, path, strlen(path));
+	(void) atomicio(ATOMICIO_WRITE, remout, path, strlen(path));
 	if (response() < 0) {
 		closedir(dirp);
 		return;
@@ -894,7 +894,7 @@ rsource(char *name, struct stat *statp)
 		source(1, vect);
 	}
 	(void) closedir(dirp);
-	(void) atomicio(vwrite, remout, "E\n", 2);
+	(void) atomicio(ATOMICIO_WRITE, remout, "E\n", 2);
 	(void) response();
 }
 
@@ -933,17 +933,17 @@ sink(int argc, char **argv)
 	if (targetshouldbedirectory)
 		verifydir(targ);
 
-	(void) atomicio(vwrite, remout, "", 1);
+	(void) atomicio(ATOMICIO_WRITE, remout, "", 1);
 	if (stat(targ, &stb) == 0 && S_ISDIR(stb.st_mode))
 		targisdir = 1;
 	for (first = 1;; first = 0) {
 		cp = buf;
-		if (atomicio(read, remin, cp, 1) != 1)
+		if (atomicio(ATOMICIO_READ, remin, cp, 1) != 1)
 			return;
 		if (*cp++ == '\n')
 			SCREWUP("unexpected <newline>");
 		do {
-			if (atomicio(read, remin, &ch, sizeof(ch)) != sizeof(ch))
+			if (atomicio(ATOMICIO_READ, remin, &ch, sizeof(ch)) != sizeof(ch))
 				SCREWUP("lost connection");
 			*cp++ = ch;
 		} while (cp < &buf[sizeof(buf) - 1] && ch != '\n');
@@ -953,7 +953,7 @@ sink(int argc, char **argv)
 
 		if (buf[0] == '\01' || buf[0] == '\02') {
 			if (iamremote == 0)
-				(void) atomicio(vwrite, STDERR_FILENO,
+				(void) atomicio(ATOMICIO_WRITE, STDERR_FILENO,
 				    buf + 1, strlen(buf + 1));
 			if (buf[0] == '\02')
 				exit(1);
@@ -961,7 +961,7 @@ sink(int argc, char **argv)
 			continue;
 		}
 		if (buf[0] == 'E') {
-			(void) atomicio(vwrite, remout, "", 1);
+			(void) atomicio(ATOMICIO_WRITE, remout, "", 1);
 			return;
 		}
 		if (ch == '\n')
@@ -997,7 +997,7 @@ sink(int argc, char **argv)
 			if (!cp || *cp++ != '\0' || atime.tv_usec < 0 ||
 			    atime.tv_usec > 999999)
 				SCREWUP("atime.usec not delimited");
-			(void) atomicio(vwrite, remout, "", 1);
+			(void) atomicio(ATOMICIO_WRITE, remout, "", 1);
 			continue;
 		}
 		if (*cp != 'C' && *cp != 'D') {
@@ -1086,7 +1086,7 @@ sink(int argc, char **argv)
 bad:			run_err("%s: %s", np, strerror(errno));
 			continue;
 		}
-		(void) atomicio(vwrite, remout, "", 1);
+		(void) atomicio(ATOMICIO_WRITE, remout, "", 1);
 		if ((bp = allocbuf(&buffer, ofd, COPY_BUFLEN)) == NULL) {
 			(void) close(ofd);
 			continue;
@@ -1104,7 +1104,7 @@ bad:			run_err("%s: %s", np, strerror(er
 				amt = size - i;
 			count += amt;
 			do {
-				j = atomicio6(read, remin, cp, amt,
+				j = atomicio6(ATOMICIO_READ, remin, cp, amt,
 				    scpio, &statbytes);
 				if (j == 0) {
 					run_err("%s", j != EPIPE ?
@@ -1119,7 +1119,7 @@ bad:			run_err("%s: %s", np, strerror(er
 			if (count == bp->cnt) {
 				/* Keep reading so we stay sync'd up. */
 				if (wrerr == NO) {
-					if (atomicio(vwrite, ofd, bp->buf,
+					if (atomicio(ATOMICIO_WRITE, ofd, bp->buf,
 					    count) != count) {
 						wrerr = YES;
 						wrerrno = errno;
@@ -1133,7 +1133,7 @@ bad:			run_err("%s: %s", np, strerror(er
 		if (showprogress)
 			stop_progress_meter();
 		if (count != 0 && wrerr == NO &&
-		    atomicio(vwrite, ofd, bp->buf, count) != count) {
+		    atomicio(ATOMICIO_WRITE, ofd, bp->buf, count) != count) {
 			wrerr = YES;
 			wrerrno = errno;
 		}
@@ -1183,7 +1183,7 @@ bad:			run_err("%s: %s", np, strerror(er
 			run_err("%s: %s", np, strerror(wrerrno));
 			break;
 		case NO:
-			(void) atomicio(vwrite, remout, "", 1);
+			(void) atomicio(ATOMICIO_WRITE, remout, "", 1);
 			break;
 		case DISPLAYED:
 			break;
@@ -1199,7 +1199,7 @@ response(void)
 {
 	char ch, *cp, resp, rbuf[2048];
 
-	if (atomicio(read, remin, &resp, sizeof(resp)) != sizeof(resp))
+	if (atomicio(ATOMICIO_READ, remin, &resp, sizeof(resp)) != sizeof(resp))
 		lostconn(0);
 
 	cp = rbuf;
@@ -1212,13 +1212,13 @@ response(void)
 	case 1:		/* error, followed by error msg */
 	case 2:		/* fatal error, "" */
 		do {
-			if (atomicio(read, remin, &ch, sizeof(ch)) != sizeof(ch))
+			if (atomicio(ATOMICIO_READ, remin, &ch, sizeof(ch)) != sizeof(ch))
 				lostconn(0);
 			*cp++ = ch;
 		} while (cp < &rbuf[sizeof(rbuf) - 1] && ch != '\n');
 
 		if (!iamremote)
-			(void) atomicio(vwrite, STDERR_FILENO, rbuf, cp - rbuf);
+			(void) atomicio(ATOMICIO_WRITE, STDERR_FILENO, rbuf, cp - rbuf);
 		++errs;
 		if (resp == 1)
 			return (-1);
Index: sftp-client.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/sftp-client.c,v
retrieving revision 1.126
diff -u -p -r1.126 sftp-client.c
--- sftp-client.c	17 Jan 2014 05:29:46 -0000	1.126
+++ sftp-client.c	25 Jan 2014 03:57:54 -0000
@@ -113,7 +113,7 @@ send_msg(struct sftp_conn *conn, Buffer 
 	iov[1].iov_base = buffer_ptr(m);
 	iov[1].iov_len = buffer_len(m);
 
-	if (atomiciov6(writev, conn->fd_out, iov, 2,
+	if (atomiciov6(ATOMICIO_WRITE, conn->fd_out, iov, 2,
 	    conn->limit_kbps > 0 ? sftpio : NULL, &conn->bwlimit_out) !=
 	    buffer_len(m) + sizeof(mlen))
 		fatal("Couldn't send packet: %s", strerror(errno));
@@ -127,7 +127,7 @@ get_msg(struct sftp_conn *conn, Buffer *
 	u_int msg_len;
 
 	buffer_append_space(m, 4);
-	if (atomicio6(read, conn->fd_in, buffer_ptr(m), 4,
+	if (atomicio6(ATOMICIO_READ, conn->fd_in, buffer_ptr(m), 4,
 	    conn->limit_kbps > 0 ? sftpio : NULL, &conn->bwlimit_in) != 4) {
 		if (errno == EPIPE)
 			fatal("Connection closed");
@@ -140,7 +140,7 @@ get_msg(struct sftp_conn *conn, Buffer *
 		fatal("Received message too long %u", msg_len);
 
 	buffer_append_space(m, msg_len);
-	if (atomicio6(read, conn->fd_in, buffer_ptr(m), msg_len,
+	if (atomicio6(ATOMICIO_READ, conn->fd_in, buffer_ptr(m), msg_len,
 	    conn->limit_kbps > 0 ? sftpio : NULL, &conn->bwlimit_in)
 	    != msg_len) {
 		if (errno == EPIPE)
@@ -1194,7 +1194,7 @@ do_download(struct sftp_conn *conn, char
 				fatal("Received more data than asked for "
 				    "%u > %u", len, req->len);
 			if ((lseek(local_fd, req->offset, SEEK_SET) == -1 ||
-			    atomicio(vwrite, local_fd, data, len) != len) &&
+			    atomicio(ATOMICIO_WRITE, local_fd, data, len) != len) &&
 			    !write_error) {
 				write_errno = errno;
 				write_error = 1;
Index: ssh-keygen.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/ssh-keygen.c,v
retrieving revision 1.258
diff -u -p -r1.258 ssh-keygen.c
--- ssh-keygen.c	7 Dec 2013 00:24:02 -0000	1.258
+++ ssh-keygen.c	25 Jan 2014 03:54:06 -0000
@@ -2109,7 +2109,7 @@ do_gen_krl(struct passwd *pw, int updati
 		fatal("Couldn't generate KRL");
 	if ((fd = open(identity_file, O_WRONLY|O_CREAT|O_TRUNC, 0644)) == -1)
 		fatal("open %s: %s", identity_file, strerror(errno));
-	if (atomicio(vwrite, fd, buffer_ptr(&kbuf), buffer_len(&kbuf)) !=
+	if (atomicio(ATOMICIO_WRITE, fd, buffer_ptr(&kbuf), buffer_len(&kbuf)) !=
 	    buffer_len(&kbuf))
 		fatal("write %s: %s", identity_file, strerror(errno));
 	close(fd);
Index: ssh-keyscan.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/ssh-keyscan.c,v
retrieving revision 1.110
diff -u -p -r1.110 ssh-keyscan.c
--- ssh-keyscan.c	7 Dec 2013 00:24:02 -0000	1.110
+++ ssh-keyscan.c	25 Jan 2014 03:54:07 -0000
@@ -412,7 +412,7 @@ congreet(int s)
 		bufsiz = sizeof(buf);
 		cp = buf;
 		while (bufsiz-- &&
-		    (n = atomicio(read, s, cp, 1)) == 1 && *cp != '\n') {
+		    (n = atomicio(ATOMICIO_READ, s, cp, 1)) == 1 && *cp != '\n') {
 			if (*cp == '\r')
 				*cp = '\n';
 			cp++;
@@ -465,7 +465,7 @@ congreet(int s)
 		confree(s);
 		return;
 	}
-	if (atomicio(vwrite, s, buf, n) != (size_t)n) {
+	if (atomicio(ATOMICIO_WRITE, s, buf, n) != (size_t)n) {
 		error("write (%s): %s", c->c_name, strerror(errno));
 		confree(s);
 		return;
@@ -489,7 +489,7 @@ conread(int s)
 		congreet(s);
 		return;
 	}
-	n = atomicio(read, s, c->c_data + c->c_off, c->c_len - c->c_off);
+	n = atomicio(ATOMICIO_READ, s, c->c_data + c->c_off, c->c_len - c->c_off);
 	if (n == 0) {
 		error("read (%s): %s", c->c_name, strerror(errno));
 		confree(s);
Index: ssh-pkcs11-client.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/ssh-pkcs11-client.c,v
retrieving revision 1.6
diff -u -p -r1.6 ssh-pkcs11-client.c
--- ssh-pkcs11-client.c	1 Jun 2013 21:31:19 -0000	1.6
+++ ssh-pkcs11-client.c	25 Jan 2014 03:54:08 -0000
@@ -52,8 +52,8 @@ send_msg(Buffer *m)
 	int mlen = buffer_len(m);
 
 	put_u32(buf, mlen);
-	if (atomicio(vwrite, fd, buf, 4) != 4 ||
-	    atomicio(vwrite, fd, buffer_ptr(m),
+	if (atomicio(ATOMICIO_WRITE, fd, buf, 4) != 4 ||
+	    atomicio(ATOMICIO_WRITE, fd, buffer_ptr(m),
 	    buffer_len(m)) != buffer_len(m))
 		error("write to helper failed");
 	buffer_consume(m, mlen);
@@ -65,7 +65,7 @@ recv_msg(Buffer *m)
 	u_int l, len;
 	u_char buf[1024];
 
-	if ((len = atomicio(read, fd, buf, 4)) != 4) {
+	if ((len = atomicio(ATOMICIO_READ, fd, buf, 4)) != 4) {
 		error("read from helper failed: %u", len);
 		return (0); /* XXX */
 	}
@@ -78,7 +78,7 @@ recv_msg(Buffer *m)
 		l = len;
 		if (l > sizeof(buf))
 			l = sizeof(buf);
-		if (atomicio(read, fd, buf, l) != l) {
+		if (atomicio(ATOMICIO_READ, fd, buf, l) != l) {
 			error("response from helper failed.");
 			return (0); /* XXX */
 		}
Index: sshconnect.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/sshconnect.c,v
retrieving revision 1.217
diff -u -p -r1.217 sshconnect.c
--- sshconnect.c	9 Jan 2014 23:59:24 -0000	1.217
+++ sshconnect.c	25 Jan 2014 03:54:12 -0000
@@ -522,7 +522,7 @@ send_client_banner(int connection_out, i
 		xasprintf(&client_version_string, "SSH-%d.%d-%.100s\n",
 		    PROTOCOL_MAJOR_1, minor1, SSH_VERSION);
 	}
-	if (roaming_atomicio(vwrite, connection_out, client_version_string,
+	if (roaming_atomicio(ATOMICIO_WRITE, connection_out, client_version_string,
 	    strlen(client_version_string)) != strlen(client_version_string))
 		fatal("write: %.100s", strerror(errno));
 	chop(client_version_string);
@@ -582,7 +582,7 @@ ssh_exchange_identification(int timeout_
 				}
 			}
 
-			len = roaming_atomicio(read, connection_in, &buf[i], 1);
+			len = roaming_atomicio(ATOMICIO_READ, connection_in, &buf[i], 1);
 
 			if (len != 1 && errno == EPIPE)
 				fatal("ssh_exchange_identification: "
Index: sshd.c
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/sshd.c,v
retrieving revision 1.441
diff -u -p -r1.441 sshd.c
--- sshd.c	17 Jan 2014 05:47:04 -0000	1.441
+++ sshd.c	25 Jan 2014 03:54:06 -0000
@@ -441,7 +441,7 @@ sshd_exchange_identification(int sock_in
 	    options.version_addendum, newline);
 
 	/* Send our protocol version identification. */
-	if (roaming_atomicio(vwrite, sock_out, server_version_string,
+	if (roaming_atomicio(ATOMICIO_WRITE, sock_out, server_version_string,
 	    strlen(server_version_string))
 	    != strlen(server_version_string)) {
 		logit("Could not write ident string to %s", get_remote_ipaddr());
@@ -451,7 +451,7 @@ sshd_exchange_identification(int sock_in
 	/* Read other sides version identification. */
 	memset(buf, 0, sizeof(buf));
 	for (i = 0; i < sizeof(buf) - 1; i++) {
-		if (roaming_atomicio(read, sock_in, &buf[i], 1) != 1) {
+		if (roaming_atomicio(ATOMICIO_READ, sock_in, &buf[i], 1) != 1) {
 			logit("Did not receive identification string from %s",
 			    get_remote_ipaddr());
 			cleanup_exit(255);
@@ -479,7 +479,7 @@ sshd_exchange_identification(int sock_in
 	if (sscanf(client_version_string, "SSH-%d.%d-%[^\n]\n",
 	    &remote_major, &remote_minor, remote_version) != 3) {
 		s = "Protocol mismatch.\n";
-		(void) atomicio(vwrite, sock_out, s, strlen(s));
+		(void) atomicio(ATOMICIO_WRITE, sock_out, s, strlen(s));
 		logit("Bad protocol version identification '%.100s' "
 		    "from %s port %d", client_version_string,
 		    get_remote_ipaddr(), get_remote_port());
@@ -548,7 +548,7 @@ sshd_exchange_identification(int sock_in
 
 	if (mismatch) {
 		s = "Protocol major versions differ.\n";
-		(void) atomicio(vwrite, sock_out, s, strlen(s));
+		(void) atomicio(ATOMICIO_WRITE, sock_out, s, strlen(s));
 		close(sock_in);
 		close(sock_out);
 		logit("Protocol major versions differ for %s: %.200s vs. %.200s",

-- 
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 Jan 25 15:51:31 2014
From: djm at mindrot.org (Damien Miller)
Date: Sat, 25 Jan 2014 15:51:31 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <20140125041457.GA525@gate.dtucker.net>
References: <alpine.BSO.2.11.1401241102440.14832@natsu.mindrot.org>
 <alpine.NEB.2.11.1401231605330.330@chris.i8u.org>
 <20140124100745.GA18706@gate.dtucker.net>
 <alpine.NEB.2.11.1401240851470.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401250655510.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241617390.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251210530.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241725020.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251318460.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241955090.12225@chris.i8u.org>
 <20140125041457.GA525@gate.dtucker.net>
Message-ID: <alpine.BSO.2.11.1401251549580.24928@natsu.mindrot.org>

On Sat, 25 Jan 2014, Darren Tucker wrote:

> Maybe there's something wrapping write() on your system too?  Try adding
> this to the start of atomicio.c:atomicio6():
> 
> printf(stderr, "read %x write %x argument %x\n", read, vwrite, f);
> 
> then compile it and run a small scp:
> 
> $ ./scp testfile localhost:/tmp/
> read b73eced0 write b73ecf50 argument b73eced0
> 
> The patch below makes the first argument to atomicio an int rather than
> a function pointer.
> 
> On the plus side: it also allows the removal of some hacks around
> vwrite/writev.  On the minus side: it's a large change albeit mostly
> mechanical.

IMO it would be better to s/atomicio[(v]*/_/ - i.e. do a separate
atomicio_read and atomicio_write (that could use the flags internally).

-d

From htodd at twofifty.com  Sat Jan 25 15:52:19 2014
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Fri, 24 Jan 2014 20:52:19 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <20140125041457.GA525@gate.dtucker.net>
References: <alpine.BSO.2.11.1401241102440.14832@natsu.mindrot.org>
 <alpine.NEB.2.11.1401231605330.330@chris.i8u.org>
 <20140124100745.GA18706@gate.dtucker.net>
 <alpine.NEB.2.11.1401240851470.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401250655510.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241617390.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251210530.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241725020.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251318460.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241955090.12225@chris.i8u.org>
 <20140125041457.GA525@gate.dtucker.net>
Message-ID: <alpine.NEB.2.11.1401242048320.12225@chris.i8u.org>

On Sat, 25 Jan 2014, Darren Tucker wrote:

> Maybe there's something wrapping write() on your system too?  Try adding
> this to the start of atomicio.c:atomicio6():
>
> printf(stderr, "read %x write %x argument %x\n", read, vwrite, f);
>
> then compile it and run a small scp:
>
> $ ./scp testfile localhost:/tmp/
> read b73eced0 write b73ecf50 argument b73eced0
>
> The patch below makes the first argument to atomicio an int rather than
> a function pointer.
>
> On the plus side: it also allows the removal of some hacks around
> vwrite/writev.  On the minus side: it's a large change albeit mostly
> mechanical.

I tried building after applying the patch, but I think I started in the wrong
place? I think I started with a fresh git clone.

Also, the scp told me it couldn't find /usr/local/bin/ssh. I'm guessing
there are environment variables I need.

gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare -Wformat-security -Wno-pointer-sign -Wno-unused-result -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset -fstack-protector-all -I. -I.  -DSSHDIR=\"/usr/local/etc\"  -D_PATH_SSH_PROGRAM=\"/usr/local/bin/ssh\"  -D_PATH_SSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh-askpass\"  -D_PATH_SFTP_SERVER=\"/usr/local/libexec/sftp-server\"  -D_PATH_SSH_KEY_SIGN=\"/usr/local/libexec/ssh-keysign\"  -D_PATH_SSH_PKCS11_HELPER=\"/usr/local/libexec/ssh-pkcs11-helper\"  -D_PATH_SSH_PIDDIR=\"/var/run\"  -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DHAVE_CONFIG_H -c atomicio.c
atomicio.c: In function 'atomicio6':
atomicio.c:59:57: error: 'vwrite' undeclared (first use in this function)
atomicio.c:59:57: note: each undeclared identifier is reported only once for each function it appears in
atomicio.c:59:65: error: 'f' undeclared (first use in this function)
atomicio.c:59:2: warning: passing argument 1 of 'printf' from incompatible pointer type
/usr/include/stdio.h:249:6: note: expected 'const char * __restrict__' but argument is of type 'struct FILE *'
*** Error code 1



-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

From dtucker at zip.com.au  Sat Jan 25 16:07:09 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 25 Jan 2014 16:07:09 +1100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.NEB.2.11.1401242048320.12225@chris.i8u.org>
References: <alpine.BSO.2.11.1401241102440.14832@natsu.mindrot.org>
 <alpine.NEB.2.11.1401231605330.330@chris.i8u.org>
 <20140124100745.GA18706@gate.dtucker.net>
 <alpine.NEB.2.11.1401240851470.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401250655510.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241617390.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251210530.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241725020.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251318460.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241955090.12225@chris.i8u.org>
 <20140125041457.GA525@gate.dtucker.net>
 <alpine.NEB.2.11.1401242048320.12225@chris.i8u.org>
Message-ID: <CALDDTe3N7LfcTeko-nwO=XDTDHyRrCURccRa5MLcqCgZs8u7pA@mail.gmail.com>

On Sat, Jan 25, 2014 at 3:52 PM, Hisashi T Fujinaka <htodd at twofifty.com> wrote:
> On Sat, 25 Jan 2014, Darren Tucker wrote:
>
>> Maybe there's something wrapping write() on your system too?  Try adding
>> this to the start of atomicio.c:atomicio6():
>>
>> printf(stderr, "read %x write %x argument %x\n", read, vwrite, f);
>>
>> then compile it and run a small scp:
>>
>> $ ./scp testfile localhost:/tmp/
>> read b73eced0 write b73ecf50 argument b73eced0
>>
>> The patch below makes the first argument to atomicio an int rather than
>> a function pointer.
>>
>> On the plus side: it also allows the removal of some hacks around
>> vwrite/writev.  On the minus side: it's a large change albeit mostly
>> mechanical.
>
>
> I tried building after applying the patch, but I think I started in the
> wrong place? I think I started with a fresh git clone.

I think you started with a tree which had one of the changes I
suggested upthread ( where I suggest changing the line to:

pfd.events = f == vwrite ? POLLOUT : POLLIN;

> Also, the scp told me it couldn't find /usr/local/bin/ssh. I'm guessing
> there are environment variables I need.

you can work around that with "./configure --prefix=/usr" for testing,
but don't do "make install" unless you really want to replace the
system binaries in /usr/{bin,sbin}

> atomicio.c:59:57: error: 'vwrite' undeclared (first use in this function)

"vwrite" doesn't appear in the unmodified version of atomicio.c except
in a comment.

-- 
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 htodd at twofifty.com  Sat Jan 25 16:25:10 2014
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Fri, 24 Jan 2014 21:25:10 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <CALDDTe3N7LfcTeko-nwO=XDTDHyRrCURccRa5MLcqCgZs8u7pA@mail.gmail.com>
References: <alpine.BSO.2.11.1401241102440.14832@natsu.mindrot.org>
 <alpine.NEB.2.11.1401231605330.330@chris.i8u.org>
 <20140124100745.GA18706@gate.dtucker.net>
 <alpine.NEB.2.11.1401240851470.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401250655510.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241617390.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251210530.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241725020.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251318460.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241955090.12225@chris.i8u.org>
 <20140125041457.GA525@gate.dtucker.net>
 <alpine.NEB.2.11.1401242048320.12225@chris.i8u.org>
 <CALDDTe3N7LfcTeko-nwO=XDTDHyRrCURccRa5MLcqCgZs8u7pA@mail.gmail.com>
Message-ID: <alpine.NEB.2.11.1401242118240.12225@chris.i8u.org>

On Sat, 25 Jan 2014, Darren Tucker wrote:

> On Sat, Jan 25, 2014 at 3:52 PM, Hisashi T Fujinaka <htodd at twofifty.com> wrote:
>> On Sat, 25 Jan 2014, Darren Tucker wrote:
>>
>>> Maybe there's something wrapping write() on your system too?  Try adding
>>> this to the start of atomicio.c:atomicio6():
>>>
>>> printf(stderr, "read %x write %x argument %x\n", read, vwrite, f);
>>>
>>> then compile it and run a small scp:
>>>
>>> $ ./scp testfile localhost:/tmp/
>>> read b73eced0 write b73ecf50 argument b73eced0
>>>
>>> The patch below makes the first argument to atomicio an int rather than
>>> a function pointer.
>>>
>>> On the plus side: it also allows the removal of some hacks around
>>> vwrite/writev.  On the minus side: it's a large change albeit mostly
>>> mechanical.
>>
>>
>> I tried building after applying the patch, but I think I started in the
>> wrong place? I think I started with a fresh git clone.
>
> I think you started with a tree which had one of the changes I
> suggested upthread ( where I suggest changing the line to:
>
> pfd.events = f == vwrite ? POLLOUT : POLLIN;

I don't see that in my current tree.

>> Also, the scp told me it couldn't find /usr/local/bin/ssh. I'm guessing
>> there are environment variables I need.
>
> you can work around that with "./configure --prefix=/usr" for testing,
> but don't do "make install" unless you really want to replace the
> system binaries in /usr/{bin,sbin}

Wouldn't that test my local ssh?

>> atomicio.c:59:57: error: 'vwrite' undeclared (first use in this function)
>
> "vwrite" doesn't appear in the unmodified version of atomicio.c except
> in a comment.

I'm confused. Should I start with a clean tree or a modified tree? And
which patches should I use? I have a lot in my email at this point.

-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

From djm at mindrot.org  Sat Jan 25 17:04:28 2014
From: djm at mindrot.org (Damien Miller)
Date: Sat, 25 Jan 2014 17:04:28 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.NEB.2.11.1401242118240.12225@chris.i8u.org>
References: <alpine.BSO.2.11.1401241102440.14832@natsu.mindrot.org>
 <alpine.NEB.2.11.1401231605330.330@chris.i8u.org>
 <20140124100745.GA18706@gate.dtucker.net>
 <alpine.NEB.2.11.1401240851470.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401250655510.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241617390.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251210530.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241725020.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251318460.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241955090.12225@chris.i8u.org>
 <20140125041457.GA525@gate.dtucker.net>
 <alpine.NEB.2.11.1401242048320.12225@chris.i8u.org>
 <CALDDTe3N7LfcTeko-nwO=XDTDHyRrCURccRa5MLcqCgZs8u7pA@mail.gmail.com>
 <alpine.NEB.2.11.1401242118240.12225@chris.i8u.org>
Message-ID: <alpine.BSO.2.11.1401251703330.24928@natsu.mindrot.org>

On Fri, 24 Jan 2014, Hisashi T Fujinaka wrote:

> I'm confused. Should I start with a clean tree or a modified tree? And
> which patches should I use? I have a lot in my email at this point.

If I checkout the current git or CVS head and apply this then the scp
test passes on NetBSD 6.1.3 where it was hanging previously:

Index: atomicio.c
===================================================================
RCS file: /var/cvs/openssh/atomicio.c,v
retrieving revision 1.40
diff -u -r1.40 atomicio.c
--- atomicio.c	24 Sep 2010 12:15:11 -0000	1.40
+++ atomicio.c	25 Jan 2014 06:03:19 -0000
@@ -57,7 +57,7 @@
 	struct pollfd pfd;
 
 	pfd.fd = fd;
-	pfd.events = f == read ? POLLIN : POLLOUT;
+	pfd.events = f == vwrite ? POLLOUT : POLLIN;
 	while (n > pos) {
 		res = (f) (fd, s + pos, n - pos);
 		switch (res) {

From htodd at twofifty.com  Sat Jan 25 17:38:19 2014
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Fri, 24 Jan 2014 22:38:19 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.11.1401251703330.24928@natsu.mindrot.org>
References: <alpine.BSO.2.11.1401241102440.14832@natsu.mindrot.org>
 <alpine.NEB.2.11.1401231605330.330@chris.i8u.org>
 <20140124100745.GA18706@gate.dtucker.net>
 <alpine.NEB.2.11.1401240851470.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401250655510.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241617390.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251210530.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241725020.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251318460.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241955090.12225@chris.i8u.org>
 <20140125041457.GA525@gate.dtucker.net>
 <alpine.NEB.2.11.1401242048320.12225@chris.i8u.org>
 <CALDDTe3N7LfcTeko-nwO=XDTDHyRrCURccRa5MLcqCgZs8u7pA@mail.gmail.com>
 <alpine.NEB.2.11.1401242118240.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251703330.24928@natsu.mindrot.org>
Message-ID: <alpine.NEB.2.11.1401242236560.12225@chris.i8u.org>

On Sat, 25 Jan 2014, Damien Miller wrote:

> On Fri, 24 Jan 2014, Hisashi T Fujinaka wrote:
>
>> I'm confused. Should I start with a clean tree or a modified tree? And
>> which patches should I use? I have a lot in my email at this point.
>
> If I checkout the current git or CVS head and apply this then the scp
> test passes on NetBSD 6.1.3 where it was hanging previously:
>
> Index: atomicio.c
> ===================================================================
> RCS file: /var/cvs/openssh/atomicio.c,v
> retrieving revision 1.40
> diff -u -r1.40 atomicio.c
> --- atomicio.c	24 Sep 2010 12:15:11 -0000	1.40
> +++ atomicio.c	25 Jan 2014 06:03:19 -0000
> @@ -57,7 +57,7 @@
> 	struct pollfd pfd;
>
> 	pfd.fd = fd;
> -	pfd.events = f == read ? POLLIN : POLLOUT;
> +	pfd.events = f == vwrite ? POLLOUT : POLLIN;
> 	while (n > pos) {
> 		res = (f) (fd, s + pos, n - pos);
> 		switch (res) {

Weird. Fresh checkout, patch applied, and I got it to pass. Is there any
particular log file that people are posting afterwards?

-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

From djm at mindrot.org  Sat Jan 25 17:44:28 2014
From: djm at mindrot.org (Damien Miller)
Date: Sat, 25 Jan 2014 17:44:28 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.NEB.2.11.1401242236560.12225@chris.i8u.org>
References: <alpine.BSO.2.11.1401241102440.14832@natsu.mindrot.org>
 <alpine.NEB.2.11.1401231605330.330@chris.i8u.org>
 <20140124100745.GA18706@gate.dtucker.net>
 <alpine.NEB.2.11.1401240851470.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401250655510.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241617390.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251210530.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241725020.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251318460.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241955090.12225@chris.i8u.org>
 <20140125041457.GA525@gate.dtucker.net>
 <alpine.NEB.2.11.1401242048320.12225@chris.i8u.org>
 <CALDDTe3N7LfcTeko-nwO=XDTDHyRrCURccRa5MLcqCgZs8u7pA@mail.gmail.com>
 <alpine.NEB.2.11.1401242118240.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251703330.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401242236560.12225@chris.i8u.org>
Message-ID: <alpine.BSO.2.11.1401251743480.24928@natsu.mindrot.org>

On Fri, 24 Jan 2014, Hisashi T Fujinaka wrote:

> Weird. Fresh checkout, patch applied, and I got it to pass. Is there any
> particular log file that people are posting afterwards?

No - I've swum through enough logs and debug traces on this to last a
while :/

-d

From htodd at twofifty.com  Sat Jan 25 17:45:33 2014
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Fri, 24 Jan 2014 22:45:33 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.11.1401251743480.24928@natsu.mindrot.org>
References: <alpine.BSO.2.11.1401241102440.14832@natsu.mindrot.org>
 <alpine.NEB.2.11.1401231605330.330@chris.i8u.org>
 <20140124100745.GA18706@gate.dtucker.net>
 <alpine.NEB.2.11.1401240851470.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401250655510.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241617390.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251210530.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241725020.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251318460.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241955090.12225@chris.i8u.org>
 <20140125041457.GA525@gate.dtucker.net>
 <alpine.NEB.2.11.1401242048320.12225@chris.i8u.org>
 <CALDDTe3N7LfcTeko-nwO=XDTDHyRrCURccRa5MLcqCgZs8u7pA@mail.gmail.com>
 <alpine.NEB.2.11.1401242118240.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251703330.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401242236560.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251743480.24928@natsu.mindrot.org>
Message-ID: <alpine.NEB.2.11.1401242245010.12225@chris.i8u.org>

On Sat, 25 Jan 2014, Damien Miller wrote:

> On Fri, 24 Jan 2014, Hisashi T Fujinaka wrote:
>
>> Weird. Fresh checkout, patch applied, and I got it to pass. Is there any
>> particular log file that people are posting afterwards?
>
> No - I've swum through enough logs and debug traces on this to last a
> while :/

Heh. Thanks for all the help and I hope it was useful to more than just
me. There has to be at least a half-dozen people running NetBSD. :)

-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

From dtucker at zip.com.au  Sat Jan 25 21:17:28 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 25 Jan 2014 21:17:28 +1100
Subject: 3des cipher and DH group size
In-Reply-To: <52E29493.1050102@redhat.com>
References: <52DE9CCB.5070505@redhat.com>
 <52E29493.1050102@redhat.com>
Message-ID: <20140125101728.GA22103@gate.dtucker.net>

On Fri, Jan 24, 2014 at 05:28:03PM +0100, Petr Lautrbach wrote:
> On 01/21/2014 05:14 PM, Petr Lautrbach wrote:
> > Hello everybody,
> > 
> > An issue was reported in RH bugzilla [1] about the size of the used DH
> > group  when combined with the 3des-cbc cipher. OpenSSH uses the
> > actual key length for the size estimation. This is probably fine as far
> > as the cipher has the same number of bits of security as the key
> > length. But this is not true for 3TDEA where the key size is 168 resp
> > 192 but it's security is only 112.
> > 
> > Given that the key size in openssh is set to 192, DH group size is
> > estimated to 7680. But according to NIST SP 800-57, the size of DH key
> > should be 2048 so openssh doesn't follow that  and it might cause
> > problems with key exchanges with some servers.
> > 
> 
> It was confirmed that openssh can't connect to the server with a server string
> 'SSH-2.0-cryptlib' using diffie-hellman-group-exchange-sha1 and 3des-cbc with
> SSH2_MSG_KEX_DH_GEX_REQUEST(1024<7680<8192).
 
Thanks for the patch.  Since we are so close to the 6.5 release I have
committed a smaller change that should still resolve the problem
(confirmed by checking the debug output for the requested group sizes).

Thanks.

Index: cipher.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/cipher.c,v
retrieving revision 1.93
diff -u -p -r1.93 cipher.c
--- cipher.c	6 Dec 2013 13:34:54 -0000	1.93
+++ cipher.c	25 Jan 2014 10:04:23 -0000
@@ -136,6 +136,14 @@ cipher_keylen(const Cipher *c)
 }
 
 u_int
+cipher_seclen(const Cipher *c)
+{
+	if (strcmp("3des-cbc", c->name) == 0)
+		return 14;
+	return cipher_keylen(c);
+}
+
+u_int
 cipher_authlen(const Cipher *c)
 {
 	return (c->auth_len);
Index: cipher.h
===================================================================
RCS file: /cvs/src/usr.bin/ssh/cipher.h,v
retrieving revision 1.43
diff -u -p -r1.43 cipher.h
--- cipher.h	6 Dec 2013 13:34:54 -0000	1.43
+++ cipher.h	25 Jan 2014 10:04:23 -0000
@@ -89,6 +89,7 @@ void	 cipher_cleanup(CipherContext *);
 void	 cipher_set_key_string(CipherContext *, const Cipher *, const char *, int);
 u_int	 cipher_blocksize(const Cipher *);
 u_int	 cipher_keylen(const Cipher *);
+u_int	 cipher_seclen(const Cipher *);
 u_int	 cipher_authlen(const Cipher *);
 u_int	 cipher_ivlen(const Cipher *);
 u_int	 cipher_is_cbc(const Cipher *);
Index: kex.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/kex.c,v
retrieving revision 1.95
diff -u -p -r1.95 kex.c
--- kex.c	12 Jan 2014 08:13:13 -0000	1.95
+++ kex.c	25 Jan 2014 10:04:23 -0000
@@ -438,7 +438,7 @@ kex_choose_conf(Kex *kex)
 	char **my, **peer;
 	char **cprop, **sprop;
 	int nenc, nmac, ncomp;
-	u_int mode, ctos, need, authlen;
+	u_int mode, ctos, need, dh_need, authlen;
 	int first_kex_follows, type;
 
 	my   = kex_buf2prop(&kex->my, NULL);
@@ -486,7 +486,7 @@ kex_choose_conf(Kex *kex)
 	choose_kex(kex, cprop[PROPOSAL_KEX_ALGS], sprop[PROPOSAL_KEX_ALGS]);
 	choose_hostkeyalg(kex, cprop[PROPOSAL_SERVER_HOST_KEY_ALGS],
 	    sprop[PROPOSAL_SERVER_HOST_KEY_ALGS]);
-	need = 0;
+	need = dh_need = 0;
 	for (mode = 0; mode < MODE_MAX; mode++) {
 		newkeys = kex->newkeys[mode];
 		if (need < newkeys->enc.key_len)
@@ -497,9 +497,12 @@ kex_choose_conf(Kex *kex)
 			need = newkeys->enc.iv_len;
 		if (need < newkeys->mac.key_len)
 			need = newkeys->mac.key_len;
+		if (dh_need < cipher_seclen(newkeys->enc.cipher))
+			dh_need = cipher_seclen(newkeys->enc.cipher);
 	}
 	/* XXX need runden? */
 	kex->we_need = need;
+	kex->dh_need = dh_need;
 
 	/* ignore the next message if the proposals do not match */
 	if (first_kex_follows && !proposals_match(my, peer) &&
Index: kex.h
===================================================================
RCS file: /cvs/src/usr.bin/ssh/kex.h,v
retrieving revision 1.60
diff -u -p -r1.60 kex.h
--- kex.h	12 Jan 2014 08:13:13 -0000	1.60
+++ kex.h	25 Jan 2014 10:04:23 -0000
@@ -121,6 +121,7 @@ struct Kex {
 	u_int	session_id_len;
 	Newkeys	*newkeys[MODE_MAX];
 	u_int	we_need;
+	u_int	dh_need;
 	int	server;
 	char	*name;
 	int	hostkey_type;
Index: kexgexc.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/kexgexc.c,v
retrieving revision 1.15
diff -u -p -r1.15 kexgexc.c
--- kexgexc.c	12 Jan 2014 08:13:13 -0000	1.15
+++ kexgexc.c	25 Jan 2014 10:04:23 -0000
@@ -55,7 +55,7 @@ kexgex_client(Kex *kex)
 	int min, max, nbits;
 	DH *dh;
 
-	nbits = dh_estimate(kex->we_need * 8);
+	nbits = dh_estimate(kex->dh_need * 8);
 
 	if (datafellows & SSH_OLD_DHGEX) {
 		/* Old GEX request */

-- 
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 Jan 25 22:44:09 2014
From: djm at mindrot.org (Damien Miller)
Date: Sat, 25 Jan 2014 22:44:09 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.NEB.2.11.1401242245010.12225@chris.i8u.org>
References: <alpine.BSO.2.11.1401241102440.14832@natsu.mindrot.org>
 <alpine.NEB.2.11.1401231605330.330@chris.i8u.org>
 <20140124100745.GA18706@gate.dtucker.net>
 <alpine.NEB.2.11.1401240851470.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401250655510.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241617390.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251210530.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241725020.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251318460.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241955090.12225@chris.i8u.org>
 <20140125041457.GA525@gate.dtucker.net>
 <alpine.NEB.2.11.1401242048320.12225@chris.i8u.org>
 <CALDDTe3N7LfcTeko-nwO=XDTDHyRrCURccRa5MLcqCgZs8u7pA@mail.gmail.com>
 <alpine.NEB.2.11.1401242118240.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251703330.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401242236560.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251743480.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401242245010.12225@chris.i8u.org>
Message-ID: <alpine.BSO.2.11.1401252243060.24928@natsu.mindrot.org>

On Fri, 24 Jan 2014, Hisashi T Fujinaka wrote:

> Heh. Thanks for all the help and I hope it was useful to more than just
> me. There has to be at least a half-dozen people running NetBSD. :)

No problem - apart from the bugs on NetBSD, I found some bugs in the scp
regress test along the way.

-d

From mancha1 at hush.com  Sun Jan 26 00:31:25 2014
From: mancha1 at hush.com (mancha)
Date: Sat, 25 Jan 2014 13:31:25 +0000 (UTC)
Subject: 3des cipher and DH group size
References: <52DE9CCB.5070505@redhat.com> <52E29493.1050102@redhat.com>
 <20140125101728.GA22103@gate.dtucker.net>
Message-ID: <loom.20140125T142528-684@post.gmane.org>

Darren Tucker <dtucker <at> zip.com.au> writes:
> 
> On Fri, Jan 24, 2014 at 05:28:03PM +0100, Petr Lautrbach wrote:
> > On 01/21/2014 05:14 PM, Petr Lautrbach wrote:
> > > Hello everybody,
> > > 
> > > An issue was reported in RH bugzilla [1] about the size of the used DH
> > > group  when combined with the 3des-cbc cipher. OpenSSH uses the
> > > actual key length for the size estimation. This is probably fine as far
> > > as the cipher has the same number of bits of security as the key
> > > length. But this is not true for 3TDEA where the key size is 168 resp
> > > 192 but it's security is only 112.
> > > 
> > > Given that the key size in openssh is set to 192, DH group size is
> > > estimated to 7680. But according to NIST SP 800-57, the size of DH key
> > > should be 2048 so openssh doesn't follow that  and it might cause
> > > problems with key exchanges with some servers.
> > > 
> > 
> > It was confirmed that openssh can't connect to the server with a server
string
> > 'SSH-2.0-cryptlib' using diffie-hellman-group-exchange-sha1 and 3des-cbc
with
> > SSH2_MSG_KEX_DH_GEX_REQUEST(1024<7680<8192).
> 
> Thanks for the patch.  Since we are so close to the 6.5 release I have
> committed a smaller change that should still resolve the problem
> (confirmed by checking the debug output for the requested group sizes).
> 
> Thanks.

Hi.

Not sure I'd characterize this commit as a "smaller change". It has
a much larger algorithmic footprint than Petr's patch.

Pre-commit, the dh group size requested was a function of
max(enc.key_len, enc.block_size, enc.iv_len, mac.key_len).

Post-commit, it is only a function of enc.key_len (or 14 for 3des).

Was this intended?

--mancha


From opensshdev at r.paypc.com  Sun Jan 26 11:25:50 2014
From: opensshdev at r.paypc.com (Morham)
Date: Sat, 25 Jan 2014 16:25:50 -0800
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.11.1401252243060.24928@natsu.mindrot.org>
References: <alpine.BSO.2.11.1401241102440.14832@natsu.mindrot.org>
 <20140124100745.GA18706@gate.dtucker.net>
 <alpine.NEB.2.11.1401240851470.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401250655510.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241617390.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251210530.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241725020.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251318460.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241955090.12225@chris.i8u.org>
 <20140125041457.GA525@gate.dtucker.net>
 <alpine.NEB.2.11.1401242048320.12225@chris.i8u.org>
 <CALDDTe3N7LfcTeko-nwO=XDTDHyRrCURccRa5MLcqCgZs8u7pA@mail.gmail.com>
 <alpine.NEB.2.11.1401242118240.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251703330.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401242236560.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251743480.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401242245010.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401252243060.24928@natsu.mindrot.org>
Message-ID: <52E4560E.3040008@r.paypc.com>

On 1/25/2014 3:44 AM, Damien Miller wrote:

> No problem - apart from the bugs on NetBSD, I found some bugs in the scp
> regress test along the way.

One thing in the forwarding.sh test that could bear a notice in the 
script as a reminder to forgetful/senile/frazzled/overworked admins is 
the port range(s) used for the test.  ClamAV's clamd service is often 
configured to use TCP port 3310, and this will cause the forwarding test 
to "hang" briefly and fail with a "corrupt file", when in actual fact, 
the file has zero bytes because the transfer never starts.

The GNU "cmp" tool spits out an extra diagnostic complaining about 
premature EOF as well.

See the attached for a proposed patch to clarify the problem as well as 
shift the base port range, which is an admittedly arbitrarily chosen one.

=M=
-------------- next part --------------
A non-text attachment was scrubbed...
Name: forwarding_nullfile.patch.gz
Type: application/gzip
Size: 514 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20140125/cb48683a/attachment.bin>

From tgc at jupiterrise.com  Mon Jan 27 00:04:12 2014
From: tgc at jupiterrise.com (Tom Christensen)
Date: Sun, 26 Jan 2014 14:04:12 +0100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
Message-ID: <52E507CC.7090107@jupiterrise.com>

On 17/01/14 01:26, Damien Miller wrote:
> Hi,
>
> OpenSSH 6.5 is almost ready for release, so we would appreciate testing
> on as many platforms and systems as possible. This release contains
> some substantial new features and a number of bugfixes.
>
I tried building from git HEAD (603b8f4) but ran into a few issues.

It fails to build out of the box on Solaris 2.6:
gmake[1]: Entering directory 
`/export/home/tgc/buildpkg/openssh/src/openssh-git/openbsd-compat'
gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare 
-Wformat-security -Wno-pointer-sign -fno-strict-aliasing 
-D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset -fstack-protector-all 
-I. -I.. -I. -I./.. -I/usr/tgcware/include -DHAVE_CONFIG_H -c arc4random.c
In file included from ../includes.h:174,
                  from arc4random.c:27:
../openbsd-compat/openbsd-compat.h:124: error: conflicting types for 
'inet_ntop'
/usr/include/resolv.h:303: error: previous declaration of 'inet_ntop' 
was here
gmake[1]: *** [arc4random.o] Error 1

The problem is that configure does not detect that inet_ntop is in 
libresolv.
...
checking for inet_ntop... no
...
$ nm /usr/lib/libresolv.so|grep inet_ntop
[264]   |     42144|      83|FUNC |GLOB |0    |12     |inet_ntop
[153]   |         0|       0|FILE |LOCL |0    |ABS    |inet_ntop.c
[154]   |     42228|     104|FUNC |LOCL |0    |12     |inet_ntop4
[155]   |     42332|     504|FUNC |LOCL |0    |12     |inet_ntop6
$ grep inet_ntop /usr/include/resolv.h
const char *inet_ntop __P((int af, const void *src, char *dst, size_t s));
$

I modified configure.ac to detect inet_ntop and the build completes and 
it passes the testsuite.

I also gave it a try on IRIX and found issues there aswell.

During configure I get this error:
./configure[10160]: ==: unknown test operator
This is a typo in configure.ac, in the pie test.

There is still the generic IRIX issue with killpg() only being supported 
when explicitly using BSD signal semantics.
Details are here:
http://permalink.gmane.org/gmane.network.openssh.devel/19422
I'm using kill(0, SIGTERM) instead as kill(2) indicates it should work 
the same.

On IRIX 6.5.22 it builds out of the box using MIPSpro 7.4.4m (CC=c99).
The testsuite runs until:
env passing over multiplexed connection
Where is seems to hang, or atleast 10 minutes later there has been no 
further activity in the logs.

On IRIX 6.2 it builds out of the box using MIPSpro 7.3 (7.3.1.2m).
The testsuite runs until:
test stderr data transfer: proto 2 ()
Where it hangs and does not get any further, this is the same as 
previous releases.

On IRIX 5.3 the compilation fails using gcc 3.4.6:
gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare 
-Wformat-security -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv 
-fno-builtin-memset -std=gnu99  -I. -I.. -I. -I./.. 
-I/usr/tgcware/include/openssl -I/usr/tgcware/include -DHAVE_CONFIG_H -c 
bcrypt_pbkdf.c
In file included from bcrypt_pbkdf.c:34:
../crypto_api.h:17: error: syntax error before "crypto_uint32"
../crypto_api.h:17: warning: type defaults to `int' in declaration of 
`crypto_uint32'
../crypto_api.h:17: warning: data definition has no type or storage class
bcrypt_pbkdf.c: In function `bcrypt_hash':
bcrypt_pbkdf.c:70: error: `uint32_t' undeclared (first use in this function)
bcrypt_pbkdf.c:70: error: (Each undeclared identifier is reported only once
bcrypt_pbkdf.c:70: error: for each function it appears in.)
bcrypt_pbkdf.c:70: error: syntax error before "cdata"
bcrypt_pbkdf.c:72: error: `uint16_t' undeclared (first use in this function)
bcrypt_pbkdf.c:72: error: syntax error before "j"
bcrypt_pbkdf.c:84: error: `j' undeclared (first use in this function)
bcrypt_pbkdf.c:86: error: `cdata' undeclared (first use in this function)
bcrypt_pbkdf.c:89: error: `uint64_t' undeclared (first use in this function)
bcrypt_pbkdf.c: In function `bcrypt_pbkdf':
bcrypt_pbkdf.c:115: error: `uint32_t' undeclared (first use in this 
function)
bcrypt_pbkdf.c:115: error: syntax error before "count"
bcrypt_pbkdf.c:134: error: `count' undeclared (first use in this function)
make[1]: *** [bcrypt_pbkdf.o] Error 1
make[1]: Leaving directory 
`/usr/people/tgc/buildpkg/openssh/src/openssh-git/openbsd-compat'

It's the same issue with poly1305.c

For building with gcc < 4.5 adding #include <inttypes.h> is necessary, 
while gcc 4.5 and later provides <stdint.h> on platforms that lack it.
Unfortunately on IRIX 5.3 <inttypes.h> conflicts with <sys/types.h> when 
using the SGI compiler which means building with gcc is now the only 
option since the source seems to rely on being able to include 
<sys/types.h> unconditionally.

Once I got the build to complete using gcc 4.5.3, it ends up failling 
some of the rekey tests.

$ cat failed-regress.log
trace: client rekey chacha20-poly1305 at openssh.com 
diffie-hellman-group-exchange-sha1
FAIL: ssh failed (-oRekeyLimit=256k 
-oCiphers=chacha20-poly1305 at openssh.com 
-oKexAlgorithms=diffie-hellman-group-exchange-sha1)

trace: client rekey chacha20-poly1305 at openssh.com 
diffie-hellman-group-exchange-sha1
FAIL: ssh failed (-oRekeyLimit=256k 
-oCiphers=chacha20-poly1305 at openssh.com 
-oKexAlgorithms=diffie-hellman-group-exchange-sha1)
FAIL: corrupted copy (-oRekeyLimit=256k 
-oCiphers=chacha20-poly1305 at openssh.com 
-oKexAlgorithms=diffie-hellman-group-exchange-sha1)

trace: -1 rekeying(s)
FAIL: no rekeying occured (-oRekeyLimit=256k 
-oCiphers=chacha20-poly1305 at openssh.com 
-oKexAlgorithms=diffie-hellman-group-exchange-sha1)

trace: client rekey chacha20-poly1305 at openssh.com 
diffie-hellman-group-exchange-sha256
FAIL: ssh failed (-oRekeyLimit=256k 
-oCiphers=chacha20-poly1305 at openssh.com 
-oKexAlgorithms=diffie-hellman-group-exchange-sha256)

trace: client rekey chacha20-poly1305 at openssh.com 
diffie-hellman-group-exchange-sha256
FAIL: ssh failed (-oRekeyLimit=256k 
-oCiphers=chacha20-poly1305 at openssh.com 
-oKexAlgorithms=diffie-hellman-group-exchange-sha256)
FAIL: corrupted copy (-oRekeyLimit=256k 
-oCiphers=chacha20-poly1305 at openssh.com 
-oKexAlgorithms=diffie-hellman-group-exchange-sha256)

trace: -1 rekeying(s)
FAIL: no rekeying occured (-oRekeyLimit=256k 
-oCiphers=chacha20-poly1305 at openssh.com 
-oKexAlgorithms=diffie-hellman-group-exchange-sha256)

The failed-* logs are here:
http://www.jupiterrise.com/tmp/

If I skip the rekey tests the testsuite runs until:
test stderr data transfer: proto 2 ()
Where it hangs and does not get any further, this is the same as 
previous releases.

None of these issues will prevent me from using openssh on IRIX, basic 
functionality is still okay.

-tgc

From djm at mindrot.org  Mon Jan 27 10:50:45 2014
From: djm at mindrot.org (Damien Miller)
Date: Mon, 27 Jan 2014 10:50:45 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <52E507CC.7090107@jupiterrise.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52E507CC.7090107@jupiterrise.com>
Message-ID: <alpine.BSO.2.11.1401271046480.9143@natsu.mindrot.org>

On Sun, 26 Jan 2014, Tom Christensen wrote:

> I modified configure.ac to detect inet_ntop and the build completes and it
> passes the testsuite.
...
> There is still the generic IRIX issue with killpg() only being supported when
> explicitly using BSD signal semantics.
> Details are here:
> http://permalink.gmane.org/gmane.network.openssh.devel/19422
> I'm using kill(0, SIGTERM) instead as kill(2) indicates it should work the
> same.

Do you have diffs for these changes?

> In file included from bcrypt_pbkdf.c:34:
> ../crypto_api.h:17: error: syntax error before "crypto_uint32"
> ../crypto_api.h:17: warning: type defaults to `int' in declaration of
> `crypto_uint32'
> ../crypto_api.h:17: warning: data definition has no type or storage class
> bcrypt_pbkdf.c: In function `bcrypt_hash':
> bcrypt_pbkdf.c:70: error: `uint32_t' undeclared (first use in this function)

I think Darren was looking at something related to the C99 int types
last week.

-d

From carson at taltos.org  Mon Jan 27 11:48:37 2014
From: carson at taltos.org (Carson Gaspar)
Date: Sun, 26 Jan 2014 16:48:37 -0800
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
Message-ID: <52E5ACE5.3010705@taltos.org>

SNAP 20140127 - All test pass on Solaris 11.1 (SRU 15) with Solaris 
Studio 12.3



From dtucker at zip.com.au  Mon Jan 27 12:43:40 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 27 Jan 2014 12:43:40 +1100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.11.1401271046480.9143@natsu.mindrot.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52E507CC.7090107@jupiterrise.com>
 <alpine.BSO.2.11.1401271046480.9143@natsu.mindrot.org>
Message-ID: <CALDDTe08cnHYrtd-HO5rU2rAVSWH5Bcq-E9U4Uc-ySVi+mxD6w@mail.gmail.com>

On Mon, Jan 27, 2014 at 10:50 AM, Damien Miller <djm at mindrot.org> wrote:
>> In file included from bcrypt_pbkdf.c:34:
>> ../crypto_api.h:17: error: syntax error before "crypto_uint32"
>> ../crypto_api.h:17: warning: type defaults to `int' in declaration of
>> `crypto_uint32'
>> ../crypto_api.h:17: warning: data definition has no type or storage class
>> bcrypt_pbkdf.c: In function `bcrypt_hash':
>> bcrypt_pbkdf.c:70: error: `uint32_t' undeclared (first use in this function)
>
> I think Darren was looking at something related to the C99 int types
> last week.

Should have been fixed by
https://anongit.mindrot.org/openssh.git/commit/defines.h?id=355f861022be7b23d3009fae8f3c9f6f7fc685f7
and
https://anongit.mindrot.org/openssh.git/commit/defines.h?id=355f861022be7b23d3009fae8f3c9f6f7fc685f7
.

How old was the snapshot you were testing?

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

From dtucker at zip.com.au  Mon Jan 27 21:23:40 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 27 Jan 2014 21:23:40 +1100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <CALDDTe08cnHYrtd-HO5rU2rAVSWH5Bcq-E9U4Uc-ySVi+mxD6w@mail.gmail.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52E507CC.7090107@jupiterrise.com>
 <alpine.BSO.2.11.1401271046480.9143@natsu.mindrot.org>
 <CALDDTe08cnHYrtd-HO5rU2rAVSWH5Bcq-E9U4Uc-ySVi+mxD6w@mail.gmail.com>
Message-ID: <CALDDTe1t6gvAA1MBvwWY34OmnB9vpevV8ezfnTcki8CLbo6FVA@mail.gmail.com>

On Mon, Jan 27, 2014 at 12:43 PM, Darren Tucker <dtucker at zip.com.au> wrote:
> On Mon, Jan 27, 2014 at 10:50 AM, Damien Miller <djm at mindrot.org> wrote:
>>> In file included from bcrypt_pbkdf.c:34:
>>> ../crypto_api.h:17: error: syntax error before "crypto_uint32"
>>> ../crypto_api.h:17: warning: type defaults to `int' in declaration of
>>> `crypto_uint32'
>>> ../crypto_api.h:17: warning: data definition has no type or storage class
>>> bcrypt_pbkdf.c: In function `bcrypt_hash':
>>> bcrypt_pbkdf.c:70: error: `uint32_t' undeclared (first use in this function)
>>
>> I think Darren was looking at something related to the C99 int types
>> last week.
>
> Should have been fixed by
> https://anongit.mindrot.org/openssh.git/commit/defines.h?id=355f861022be7b23d3009fae8f3c9f6f7fc685f7
> and

the second one should have been
https://anongit.mindrot.org/openssh.git/commit/defines.h?id=acad351a5b1c37de9130c9c1710445cc45a7f6b9

anyway, I dug out my old sparc and I was able to reproduce that error
message with the tree before those commits and build successfully with
the most current one, so I'm pretty sure this has been fixed.

-- 
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 tgc at jupiterrise.com  Mon Jan 27 22:23:00 2014
From: tgc at jupiterrise.com (Tom G. Christensen)
Date: Mon, 27 Jan 2014 12:23:00 +0100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.11.1401271046480.9143@natsu.mindrot.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52E507CC.7090107@jupiterrise.com>
 <alpine.BSO.2.11.1401271046480.9143@natsu.mindrot.org>
Message-ID: <52E64194.7080505@jupiterrise.com>

On 27/01/14 00:50, Damien Miller wrote:
> On Sun, 26 Jan 2014, Tom Christensen wrote:
>
>> I modified configure.ac to detect inet_ntop and the build completes and it
>> passes the testsuite.
> ...
>> There is still the generic IRIX issue with killpg() only being supported when
>> explicitly using BSD signal semantics.
>> Details are here:
>> http://permalink.gmane.org/gmane.network.openssh.devel/19422
>> I'm using kill(0, SIGTERM) instead as kill(2) indicates it should work the
>> same.
>
> Do you have diffs for these changes?
>
Sorry, but the inet_ntop change was just a hack, not a proper solution.
For correctness such a change should be looking for inet_ntop in both 
libresolv and libnsl (for Solaris 8-10).
Note though that Solaris 7 does not declare this function in the headers.

For killpg vs. kill I'm just patching sshd.c, changing the single use of 
killpg to kill.
I don't know if this is universally acceptable and I only know of IRIX 
which has this issue. It might not actually cause any problems to use 
killpg, but as the manpage says results can be unpredictable.

-tgc

From djm at mindrot.org  Mon Jan 27 23:11:19 2014
From: djm at mindrot.org (Damien Miller)
Date: Mon, 27 Jan 2014 23:11:19 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <52E64194.7080505@jupiterrise.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52E507CC.7090107@jupiterrise.com>
 <alpine.BSO.2.11.1401271046480.9143@natsu.mindrot.org>
 <52E64194.7080505@jupiterrise.com>
Message-ID: <alpine.BSO.2.11.1401272308490.24928@natsu.mindrot.org>

On Mon, 27 Jan 2014, Tom G. Christensen wrote:

> Sorry, but the inet_ntop change was just a hack, not a proper solution.
> For correctness such a change should be looking for inet_ntop in both
> libresolv and libnsl (for Solaris 8-10).
> Note though that Solaris 7 does not declare this function in the headers.
> 
> For killpg vs. kill I'm just patching sshd.c, changing the single use of
> killpg to kill.
> I don't know if this is universally acceptable and I only know of IRIX which
> has this issue. It might not actually cause any problems to use killpg, but as
> the manpage says results can be unpredictable.

Could you try this? You'll need to run autoreconf.

AFAIK it's actually better to use kill(0, ...) than killpg(0, ...).
My copy of susv3 says:

> int killpg(pid_t pgrp, int sig);
> ...
> If pgrp is less than or equal to 1, the behavior of killpg() is undefined.

This code was only added relatively recently, with AuthorizedKeysCommand.
It should be safe to change.

-d

Index: configure.ac
===================================================================
RCS file: /var/cvs/openssh/configure.ac,v
retrieving revision 1.564
diff -u -p -r1.564 configure.ac
--- configure.ac	25 Jan 2014 22:46:54 -0000	1.564
+++ configure.ac	27 Jan 2014 12:05:32 -0000
@@ -1240,6 +1240,9 @@ AC_SEARCH_LIBS([openpty], [util bsd])
 AC_SEARCH_LIBS([updwtmp], [util bsd])
 AC_CHECK_FUNCS([fmt_scaled scan_scaled login logout openpty updwtmp logwtmp])
 
+# On some platforms, inet_ntop may be found in libresolv or libnsl.
+AC_SEARCH_LIBS([inet_ntop], [resolv nsl])
+
 AC_FUNC_STRFTIME
 
 # Check for ALTDIRFUNC glob() extension
Index: sshd.c
===================================================================
RCS file: /var/cvs/openssh/sshd.c,v
retrieving revision 1.441
diff -u -p -r1.441 sshd.c
--- sshd.c	17 Jan 2014 05:47:04 -0000	1.441
+++ sshd.c	27 Jan 2014 12:07:47 -0000
@@ -372,7 +372,7 @@ grace_alarm_handler(int sig)
 	 */
 	if (getpgid(0) == getpid()) {
 		signal(SIGTERM, SIG_IGN);
-		killpg(0, SIGTERM);
+		kill(0, SIGTERM);
 	}
 
 	/* Log error and exit. */

From tgc at jupiterrise.com  Tue Jan 28 00:36:44 2014
From: tgc at jupiterrise.com (Tom G. Christensen)
Date: Mon, 27 Jan 2014 14:36:44 +0100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <CALDDTe1t6gvAA1MBvwWY34OmnB9vpevV8ezfnTcki8CLbo6FVA@mail.gmail.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52E507CC.7090107@jupiterrise.com>
 <alpine.BSO.2.11.1401271046480.9143@natsu.mindrot.org>
 <CALDDTe08cnHYrtd-HO5rU2rAVSWH5Bcq-E9U4Uc-ySVi+mxD6w@mail.gmail.com>
 <CALDDTe1t6gvAA1MBvwWY34OmnB9vpevV8ezfnTcki8CLbo6FVA@mail.gmail.com>
Message-ID: <52E660EC.6050003@jupiterrise.com>

On 27/01/14 11:23, Darren Tucker wrote:
> On Mon, Jan 27, 2014 at 12:43 PM, Darren Tucker <dtucker at zip.com.au> wrote:
>> On Mon, Jan 27, 2014 at 10:50 AM, Damien Miller <djm at mindrot.org> wrote:
>>>> In file included from bcrypt_pbkdf.c:34:
>>>> ../crypto_api.h:17: error: syntax error before "crypto_uint32"
>>>> ../crypto_api.h:17: warning: type defaults to `int' in declaration of
>>>> `crypto_uint32'
>>>> ../crypto_api.h:17: warning: data definition has no type or storage class
>>>> bcrypt_pbkdf.c: In function `bcrypt_hash':
>>>> bcrypt_pbkdf.c:70: error: `uint32_t' undeclared (first use in this function)
>>>
>>> I think Darren was looking at something related to the C99 int types
>>> last week.
>>
>> Should have been fixed by
>> https://anongit.mindrot.org/openssh.git/commit/defines.h?id=355f861022be7b23d3009fae8f3c9f6f7fc685f7
>> and
>
> the second one should have been
> https://anongit.mindrot.org/openssh.git/commit/defines.h?id=acad351a5b1c37de9130c9c1710445cc45a7f6b9
>
> anyway, I dug out my old sparc and I was able to reproduce that error
> message with the tree before those commits and build successfully with
> the most current one, so I'm pretty sure this has been fixed.
>
As I stated in the original mail, testing was done with gitrev 603b8f4 
which is well after those changes.

What old Solaris is missing is u_intXX_t, however IRIX 5.3 has both 
u_intXX_t (defined in <sys/types.h>) and uintXX_t (defined in <inttypes.h>).
Unfortunately those headers cannot be included at the same time when 
using the SGI compiler.

So this is the real problem:
checking for inttypes.h... no
...
checking for uintXX_t types in inttypes.h... yes
...

It should not be looking for uintXX_t in inttypes.h if the header is 
unuseable (ie. ac_cv_header_inttypes_h=no).

Also even if inttypes.h is available and defines uintXX_t, the source 
does not seem to make consistent use of it (only used in roaming_*.c).

I modified configure.ac to skip the check for uintXX_t in inttypes.h and 
now it works with the SGI compiler.
There's an unrelated include issue which prevents a complete build but 
the original problem is gone.

-tgc

From tgc at jupiterrise.com  Tue Jan 28 06:38:36 2014
From: tgc at jupiterrise.com (Tom G. Christensen)
Date: Mon, 27 Jan 2014 20:38:36 +0100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.11.1401272308490.24928@natsu.mindrot.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52E507CC.7090107@jupiterrise.com>
 <alpine.BSO.2.11.1401271046480.9143@natsu.mindrot.org>
 <52E64194.7080505@jupiterrise.com>
 <alpine.BSO.2.11.1401272308490.24928@natsu.mindrot.org>
Message-ID: <52E6B5BC.1060908@jupiterrise.com>

On 27/01/14 13:11, Damien Miller wrote:
> Could you try this? You'll need to run autoreconf.
>
<snip patch>

I tested on sparc-sun-solaris2.[678] and in all cases inet_ntop is 
correctly detected.
On Solaris 7 I got the expected warning about the missing prototype.

I'm however seeing errors in the rekey test on sparc-sun-solaris2.[67], 
the same three errors I got on IRIX 5.3.
Something is iffy with that since those same tests passes on 
i386-pc-solaris2.6.
Could there be some timing/performance issue causing those failures? The 
3 hosts that fail those tests are also the slowest hosts (USII 336/400 
Mhz, and MIPS R4600PC/133).
My sparc-sun-solaris2.8 host is a zone on a 4x900Mhz USIII system and it 
passes the testsuite fine, the i386-pc-solaris2.6 host is a VM running 
on an i7-2600 cpu.

-tgc



From plautrba at redhat.com  Tue Jan 28 06:57:40 2014
From: plautrba at redhat.com (Petr Lautrbach)
Date: Mon, 27 Jan 2014 20:57:40 +0100
Subject: 3des cipher and DH group size
In-Reply-To: <20140125101728.GA22103@gate.dtucker.net>
References: <52DE9CCB.5070505@redhat.com> <52E29493.1050102@redhat.com>
 <20140125101728.GA22103@gate.dtucker.net>
Message-ID: <52E6BA34.6000108@redhat.com>

Dne 25.1.2014 11:17, Darren Tucker napsal(a):
> On Fri, Jan 24, 2014 at 05:28:03PM +0100, Petr Lautrbach wrote:
>> On 01/21/2014 05:14 PM, Petr Lautrbach wrote:
>>> Hello everybody,
>>>
>>> An issue was reported in RH bugzilla [1] about the size of the used DH
>>> group  when combined with the 3des-cbc cipher. OpenSSH uses the
>>> actual key length for the size estimation. This is probably fine as far
>>> as the cipher has the same number of bits of security as the key
>>> length. But this is not true for 3TDEA where the key size is 168 resp
>>> 192 but it's security is only 112.
>>>
>>> Given that the key size in openssh is set to 192, DH group size is
>>> estimated to 7680. But according to NIST SP 800-57, the size of DH key
>>> should be 2048 so openssh doesn't follow that  and it might cause
>>> problems with key exchanges with some servers.
>>>
>>
>> It was confirmed that openssh can't connect to the server with a server string
>> 'SSH-2.0-cryptlib' using diffie-hellman-group-exchange-sha1 and 3des-cbc with
>> SSH2_MSG_KEX_DH_GEX_REQUEST(1024<7680<8192).
>
> Thanks for the patch.  Since we are so close to the 6.5 release I have
> committed a smaller change that should still resolve the problem
> (confirmed by checking the debug output for the requested group sizes).
>

Works, thanks.

I'll try to communicate a change with the other side to follow RFC and 
provide at least  the largest group it knows.

Petr
-- 
Petr Lautrbach <plautrba at redhat.com>, Red Hat, Inc.

From djm at mindrot.org  Tue Jan 28 09:56:43 2014
From: djm at mindrot.org (Damien Miller)
Date: Tue, 28 Jan 2014 09:56:43 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <52E6B5BC.1060908@jupiterrise.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52E507CC.7090107@jupiterrise.com>
 <alpine.BSO.2.11.1401271046480.9143@natsu.mindrot.org>
 <52E64194.7080505@jupiterrise.com>
 <alpine.BSO.2.11.1401272308490.24928@natsu.mindrot.org>
 <52E6B5BC.1060908@jupiterrise.com>
Message-ID: <alpine.BSO.2.11.1401280956060.24928@natsu.mindrot.org>

On Mon, 27 Jan 2014, Tom G. Christensen wrote:

> On 27/01/14 13:11, Damien Miller wrote:
> > Could you try this? You'll need to run autoreconf.
> > 
> <snip patch>
> 
> I tested on sparc-sun-solaris2.[678] and in all cases inet_ntop is correctly
> detected.
> On Solaris 7 I got the expected warning about the missing prototype.

Thanks.

> I'm however seeing errors in the rekey test on sparc-sun-solaris2.[67], the
> same three errors I got on IRIX 5.3.
> Something is iffy with that since those same tests passes on
> i386-pc-solaris2.6.
> Could there be some timing/performance issue causing those failures? The 3
> hosts that fail those tests are also the slowest hosts (USII 336/400 Mhz, and
> MIPS R4600PC/133).
> My sparc-sun-solaris2.8 host is a zone on a 4x900Mhz USIII system and it
> passes the testsuite fine, the i386-pc-solaris2.6 host is a VM running on an
> i7-2600 cpu.

There might be some clues as to what went wrong in regress/failed*.log

-d

From dtucker at zip.com.au  Tue Jan 28 10:20:21 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 28 Jan 2014 10:20:21 +1100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <52E6B5BC.1060908@jupiterrise.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52E507CC.7090107@jupiterrise.com>
 <alpine.BSO.2.11.1401271046480.9143@natsu.mindrot.org>
 <52E64194.7080505@jupiterrise.com>
 <alpine.BSO.2.11.1401272308490.24928@natsu.mindrot.org>
 <52E6B5BC.1060908@jupiterrise.com>
Message-ID: <CALDDTe2JSBrRe8zYJ7xK8BO0th2526Kmws_-C_4fZjUNrS_4=A@mail.gmail.com>

On Tue, Jan 28, 2014 at 6:38 AM, Tom G. Christensen <tgc at jupiterrise.com> wrote:
[...]
> Could there be some timing/performance issue causing those failures?

It's possible.  We try to not make the tests timing-sensitive where
possible but some of them are inherently racy.

The slowest machine I've run the tests on is either a 166MHz powerpc
or a 170 MHz sparc.  On the sparcs at least, building openssl with gcc
-mv8 or better makes a huge difference because it enables the hardware
multiply, and DH does a lot of multiplies.

-- 
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 tgc at jupiterrise.com  Tue Jan 28 21:54:17 2014
From: tgc at jupiterrise.com (Tom G. Christensen)
Date: Tue, 28 Jan 2014 11:54:17 +0100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <CALDDTe2JSBrRe8zYJ7xK8BO0th2526Kmws_-C_4fZjUNrS_4=A@mail.gmail.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52E507CC.7090107@jupiterrise.com>
 <alpine.BSO.2.11.1401271046480.9143@natsu.mindrot.org>
 <52E64194.7080505@jupiterrise.com>
 <alpine.BSO.2.11.1401272308490.24928@natsu.mindrot.org>
 <52E6B5BC.1060908@jupiterrise.com>
 <CALDDTe2JSBrRe8zYJ7xK8BO0th2526Kmws_-C_4fZjUNrS_4=A@mail.gmail.com>
Message-ID: <52E78C59.90006@jupiterrise.com>

On 28/01/14 00:20, Darren Tucker wrote:
> On Tue, Jan 28, 2014 at 6:38 AM, Tom G. Christensen <tgc at jupiterrise.com> wrote:
> [...]
>> Could there be some timing/performance issue causing those failures?
>
> It's possible.  We try to not make the tests timing-sensitive where
> possible but some of them are inherently racy.
>
> The slowest machine I've run the tests on is either a 166MHz powerpc
> or a 170 MHz sparc.  On the sparcs at least, building openssl with gcc
> -mv8 or better makes a huge difference because it enables the hardware
> multiply, and DH does a lot of multiplies.
>

Good call.

I rebuilt openssl with sparcv8 on the Solaris 7 host, and now it can 
complete the rekey test.
I guess there is a timeout somewhere that causes the test to fail if it 
takes too long to do the math.
I'm not sure I can get much more performance out of the IRIX 5.3 host, 
so if there is a way to avoid or extend this timeout that would be nice.

-tgc


From djm at mindrot.org  Tue Jan 28 22:17:39 2014
From: djm at mindrot.org (Damien Miller)
Date: Tue, 28 Jan 2014 22:17:39 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <52E78C59.90006@jupiterrise.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52E507CC.7090107@jupiterrise.com>
 <alpine.BSO.2.11.1401271046480.9143@natsu.mindrot.org>
 <52E64194.7080505@jupiterrise.com>
 <alpine.BSO.2.11.1401272308490.24928@natsu.mindrot.org>
 <52E6B5BC.1060908@jupiterrise.com>
 <CALDDTe2JSBrRe8zYJ7xK8BO0th2526Kmws_-C_4fZjUNrS_4=A@mail.gmail.com>
 <52E78C59.90006@jupiterrise.com>
Message-ID: <alpine.BSO.2.11.1401282212300.24928@natsu.mindrot.org>

On Tue, 28 Jan 2014, Tom G. Christensen wrote:

> Good call.
> 
> I rebuilt openssl with sparcv8 on the Solaris 7 host, and now it can
> complete the rekey test. I guess there is a timeout somewhere that
> causes the test to fail if it takes too long to do the math. I'm not
> sure I can get much more performance out of the IRIX 5.3 host, so if
> there is a way to avoid or extend this timeout that would be nice.

OpenSSL does ship MIPS assembler bits for its bignum code, though I
have no idea under what circumstances it is activated.

As for altering the test to take longer - you could try increasing
the 'sleep 3' statements in rekey.sh to something longer and see
if that helps. Unfortunately, this is a more fiddly one to avoid the
races on.

btw, if you want to re-run a single test you can do:

make tests LTESTS=rekey

from the top level directory

-d

From mail at eworm.de  Tue Jan 28 22:22:17 2014
From: mail at eworm.de (Christian Hesse)
Date: Tue, 28 Jan 2014 12:22:17 +0100
Subject: [PATCH 1/1] rework printing for visual host key upper border
Message-ID: <1390908137-2443-1-git-send-email-mail@eworm.de>

Key types are getting longer and the current implementation of visual
host key breaks with ED25519, resulting in (note the missing bracket):

+--[ED25519  256--+

This reworks the calculation of visual host key upper border. Please be
aware that this may change the output for other key types as well.
---
 key.c | 12 ++++++++----
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/key.c b/key.c
index 9142338..430f290 100644
--- a/key.c
+++ b/key.c
@@ -530,13 +530,14 @@ key_fingerprint_randomart(u_char *dgst_raw, u_int dgst_raw_len, const Key *k)
 	 * intersects with itself.  Matter of taste.
 	 */
 	char	*augmentation_string = " .o+=*BOX@%&#/^SE";
-	char	*retval, *p;
+	char	*retval, *p, key_details[FLDSIZE_X + 1];
 	u_char	 field[FLDSIZE_X][FLDSIZE_Y];
 	u_int	 i, b;
 	int	 x, y;
 	size_t	 len = strlen(augmentation_string) - 1;
 
 	retval = xcalloc(1, (FLDSIZE_X + 3) * (FLDSIZE_Y + 2));
+	p = retval;
 
 	/* initialize field */
 	memset(field, 0, FLDSIZE_X * FLDSIZE_Y * sizeof(char));
@@ -570,11 +571,14 @@ key_fingerprint_randomart(u_char *dgst_raw, u_int dgst_raw_len, const Key *k)
 	field[FLDSIZE_X / 2][FLDSIZE_Y / 2] = len - 1;
 	field[x][y] = len;
 
-	/* fill in retval */
-	snprintf(retval, FLDSIZE_X, "+--[%4s %4u]", key_type(k), key_size(k));
-	p = strchr(retval, '\0');
+	/* assemble key detail string */
+	snprintf(key_details, FLDSIZE_X, "[%s %u]", key_type(k), key_size(k));
 
 	/* output upper border */
+	*p++ = '+';
+	for (i = 0; i < (FLDSIZE_X - strlen(key_details)) / 2; i++)
+		*p++ = '-';
+	p += sprintf(p, "%s", key_details);
 	for (i = p - retval - 1; i < FLDSIZE_X; i++)
 		*p++ = '-';
 	*p++ = '+';
-- 
1.8.5.3


From me at rakul.info  Tue Jan 28 23:54:07 2014
From: me at rakul.info (Rakulenko A.)
Date: Tue, 28 Jan 2014 16:54:07 +0400
Subject: [SUSPECTED SPAM] default change in 6.2 breaks sslh
Message-ID: <52E7A86F.40400@rakul.info>

Hi all!

I'm using sslh. It's a multiplexer, used to let you have ssh, https,
stunnel, etc on one port.
In 6.2 there is a change in default behaviour:

 * ssh(1): When SSH protocol 2 only is selected (the default), ssh(1)
   now immediately sends its SSH protocol banner to the server without
   waiting to receive the server's banner, saving time when connecting.

which, i suppose, breaks the way sslh detects openssh traffic. I found
the cause in this discussion:
http://rutschle.net/pipermail/sslh/2011-January/000045.html
which is related to similar problem, but with "connectBot" - a mobile
ssh client.

the workaround is simply to add "Protocol 1,2" to ssh_config and force
it to wait for banner.
I'm just not quite sure that this is a good idea to add such config
option, cause everywhere you can see advises never to use ssh version 1,
and probably it would be a security loss to allow one's client to
connect to v.1 servers.

Maybe, if i'm getting everything right, there may be a way to add an
option to force ssh to wait for banner, set off by default?

Alex.

Thank you!

From cybermedi at yahoo.com  Wed Jan 29 01:02:48 2014
From: cybermedi at yahoo.com (Martin Meduna)
Date: Tue, 28 Jan 2014 15:02:48 +0100
Subject: safenet eToken 5100 pkcs11 bug(?)
Message-ID: <FDA5192A-35C4-4C09-8664-3D76F522E5EC@yahoo.com>

Guys, I am not able to get it run. I can not say where is the problem but it seams that the openssh client is not able to get list of rsa key from token. See two logs from pkcs11-spy. one is for "ssh  -I" the second is for "pkcs11-tool -O"
In the second log there is private_key visible or offered in the first one is not. 
I use openssh 6.4 version on Linux or Mac.


Log from ssh -I
0: C_GetFunctionList
2014-01-28 03:26:42.350
Returned:  0 CKR_OK

1: C_Initialize
2014-01-28 03:26:42.351
[in] pInitArgs = (nil)
Returned:  0 CKR_OK

2: C_GetInfo
2014-01-28 03:26:42.352
[out] pInfo: 
      cryptokiVersion:         2.20
      manufacturerID:         'SafeNet, Inc.                   '
      flags:                   0
      libraryDescription:     'SafeNet eToken PKCS#11          '
      libraryVersion:          8.3
Returned:  0 CKR_OK

3: C_GetSlotList
2014-01-28 03:26:42.352
[in] tokenPresent = 0x1
[out] pSlotList: 
Count is 1
[out] *pulCount = 0x1
Returned:  0 CKR_OK

4: C_GetSlotList
2014-01-28 03:26:42.352
[in] tokenPresent = 0x1
[out] pSlotList: 
Slot 0
[out] *pulCount = 0x1
Returned:  0 CKR_OK

5: C_GetTokenInfo
2014-01-28 03:26:42.352
[in] slotID = 0x0
[out] pInfo: 
      label:                  'mToken2                         '
      manufacturerID:         'SafeNet, Inc.                   '
      model:                  'eToken          '
      serialNumber:           '01db04cc        '
      ulMaxSessionCount:       0
      ulSessionCount:          0
      ulMaxRwSessionCount:     0
      ulRwSessionCount:        0
      ulMaxPinLen:             0
      ulMinPinLen:             0
      ulTotalPublicMemory:     73728
      ulFreePublicMemory:      54312
      ulTotalPrivateMemory:    73728
      ulFreePrivateMemory:     54312
      hardwareVersion:         8.0
      firmwareVersion:         1.0
      time:                   '                '
      flags:                   601
        CKF_RNG                          
        CKF_DUAL_CRYPTO_OPERATIONS       
        CKF_TOKEN_INITIALIZED            
Returned:  0 CKR_OK

6: C_OpenSession
2014-01-28 03:26:42.353
[in] slotID = 0x0
[in] flags = 0x6
pApplication=(nil)
Notify=(nil)
[out] *phSession = 0x3c60002
Returned:  0 CKR_OK

7: C_FindObjectsInit
2014-01-28 03:26:42.353
[in] hSession = 0x3c60002
[in] pTemplate[1]: 
    CKA_CLASS             CKO_PUBLIC_KEY       
Returned:  0 CKR_OK

8: C_FindObjects
2014-01-28 03:26:42.353
[in] hSession = 0x3c60002
[in] ulMaxObjectCount = 0x1
[out] ulObjectCount = 0x1
Object 0x8690003 matches
Returned:  0 CKR_OK

9: C_GetAttributeValue
2014-01-28 03:26:42.353
[in] hSession = 0x3c60002
[in] hObject = 0x8690003
[in] pTemplate[3]: 
    CKA_ID                0000000000000000 / 0
    CKA_MODULUS           0000000000000000 / 0
    CKA_PUBLIC_EXPONENT   0000000000000000 / 0
[out] pTemplate[3]: 
    CKA_ID                0000000000000000 / 0
    CKA_MODULUS           0000000000000000 / 256
    CKA_PUBLIC_EXPONENT   0000000000000000 / 3
Returned:  0 CKR_OK

10: C_FindObjects
2014-01-28 03:26:42.354
[in] hSession = 0x3c60002
[in] ulMaxObjectCount = 0x1
[out] ulObjectCount = 0x0
Returned:  0 CKR_OK

11: C_FindObjectsFinal
2014-01-28 03:26:42.354
[in] hSession = 0x3c60002
Returned:  0 CKR_OK

12: C_Finalize
2014-01-28 03:26:42.354
Returned:  0 CKR_OK

Log from   pkcs11-tool --module=/usr/lib/x86_64-linux-gnu/pkcs11-spy.so -

*************** OpenSC PKCS#11 spy *****************
Loaded: "/usr/lib/libeTPkcs11.so"

0: C_GetFunctionList
2014-01-28 04:00:43.576
Returned:  0 CKR_OK

1: C_Initialize
2014-01-28 04:00:43.576
[in] pInitArgs = (nil)
Returned:  0 CKR_OK

2: C_GetSlotList
2014-01-28 04:00:43.577
[in] tokenPresent = 0x0
[out] pSlotList: 
Count is 6
[out] *pulCount = 0x6
Returned:  0 CKR_OK

3: C_GetSlotList
2014-01-28 04:00:43.577
[in] tokenPresent = 0x0
[out] pSlotList: 
Slot 0
Slot 1
Slot 2
Slot 3
Slot 4
Slot 5
[out] *pulCount = 0x6
Returned:  0 CKR_OK

4: C_GetSlotInfo
2014-01-28 04:00:43.577
[in] slotID = 0x0
[out] pInfo: 
      slotDescription:        'AKS ifdh [Main Interface] 00 00 '
                              '                                '
      manufacturerID:         'SafeNet, Inc.                   '
      hardwareVersion:         1.0
      firmwareVersion:         0.0
      flags:                   7
        CKF_TOKEN_PRESENT                
        CKF_REMOVABLE_DEVICE             
        CKF_HW_SLOT                      
Returned:  0 CKR_OK

5: C_OpenSession
2014-01-28 04:00:43.578
[in] slotID = 0x0
[in] flags = 0x4
pApplication=(nil)
Notify=(nil)
[out] *phSession = 0x5670001
Returned:  0 CKR_OK

6: C_FindObjectsInit
2014-01-28 04:00:43.578
[in] hSession = 0x5670001
[in] pTemplate[0]: 
Returned:  0 CKR_OK

7: C_FindObjects
2014-01-28 04:00:43.579
[in] hSession = 0x5670001
[in] ulMaxObjectCount = 0x1
[out] ulObjectCount = 0x1
Object 0x3c60002 matches
Returned:  0 CKR_OK

8: C_GetAttributeValue
2014-01-28 04:00:43.579
[in] hSession = 0x5670001
[in] hObject = 0x3c60002
[in] pTemplate[1]: 
    CKA_CLASS             00007fff3bd35a58 / 8
[out] pTemplate[1]: 
    CKA_CLASS             CKO_PRIVATE_KEY      
Returned:  0 CKR_OK

9: C_GetAttributeValue
2014-01-28 04:00:43.579
[in] hSession = 0x5670001
[in] hObject = 0x3c60002
[in] pTemplate[1]: 
    CKA_KEY_TYPE          00007fff3bd35a58 / 8
[out] pTemplate[1]: 
    CKA_KEY_TYPE          CKK_RSA            
Returned:  0 CKR_OK

10: C_GetAttributeValue
2014-01-28 04:00:43.579
[in] hSession = 0x5670001
[in] hObject = 0x3c60002
[in] pTemplate[1]: 
    CKA_CLASS             00007fff3bd35a58 / 8
[out] pTemplate[1]: 
    CKA_CLASS             CKO_PRIVATE_KEY      
Returned:  0 CKR_OK

11: C_GetAttributeValue
2014-01-28 04:00:43.579
[in] hSession = 0x5670001
[in] hObject = 0x3c60002
[in] pTemplate[1]: 
    CKA_LABEL             0000000000000000 / 0
[out] pTemplate[1]: 
    CKA_LABEL             0000000000000000 / 0
Returned:  0 CKR_OK

12: C_GetAttributeValue
2014-01-28 04:00:43.579
[in] hSession = 0x5670001
[in] hObject = 0x3c60002
[in] pTemplate[1]: 
    CKA_LABEL             0000000000bb14b0 / 0
[out] pTemplate[1]: 
    CKA_LABEL             0000000000bb14b0 / 0
Returned:  0 CKR_OK

13: C_GetAttributeValue
2014-01-28 04:00:43.579
[in] hSession = 0x5670001
[in] hObject = 0x3c60002
[in] pTemplate[1]: 
    CKA_ID                0000000000000000 / 0
[out] pTemplate[1]: 
    CKA_ID                0000000000000000 / 0
Returned:  0 CKR_OK

14: C_GetAttributeValue
2014-01-28 04:00:43.579
[in] hSession = 0x5670001
[in] hObject = 0x3c60002
[in] pTemplate[1]: 
    CKA_ID                0000000000bb14b0 / 0
[out] pTemplate[1]: 
    CKA_ID                0000000000bb14b0 / 0
Returned:  0 CKR_OK

15: C_GetAttributeValue
2014-01-28 04:00:43.579
[in] hSession = 0x5670001
[in] hObject = 0x3c60002
[in] pTemplate[1]: 
    CKA_DECRYPT           00007fff3bd35a5f / 1
[out] pTemplate[1]: 
    CKA_DECRYPT           True
Returned:  0 CKR_OK

16: C_GetAttributeValue
2014-01-28 04:00:43.580
[in] hSession = 0x5670001
[in] hObject = 0x3c60002
[in] pTemplate[1]: 
    CKA_SIGN              00007fff3bd35a5f / 1
[out] pTemplate[1]: 
    CKA_SIGN              True
Returned:  0 CKR_OK

17: C_GetAttributeValue
2014-01-28 04:00:43.580
[in] hSession = 0x5670001
[in] hObject = 0x3c60002
[in] pTemplate[1]: 
    CKA_? (0x80000001)    00007fff3bd35ab7 / 1
[out] pTemplate[1]: 
    CKA_? (0x80000001)    00007fff3bd35ab7 / 8
Returned:  0 CKR_OK

18: C_GetAttributeValue
2014-01-28 04:00:43.580
[in] hSession = 0x5670001
[in] hObject = 0x3c60002
[in] pTemplate[1]: 
    CKA_UNWRAP            00007fff3bd35a5f / 1
[out] pTemplate[1]: 
    CKA_UNWRAP            True
Returned:  0 CKR_OK

19: C_GetAttributeValue
2014-01-28 04:00:43.580
[in] hSession = 0x5670001
[in] hObject = 0x3c60002
[in] pTemplate[1]: 
    CKA_DERIVE            00007fff3bd35ab7 / 1
[out] pTemplate[1]: 
    CKA_DERIVE            False
Returned:  0 CKR_OK

20: C_GetAttributeValue
2014-01-28 04:00:43.580
[in] hSession = 0x5670001
[in] hObject = 0x3c60002
[in] pTemplate[1]: 
    CKA_ALWAYS_AUTHENTICATE  00007fff3bd35a5f / 1
[out] pTemplate[1]: 
    CKA_ALWAYS_AUTHENTICATE  False
Returned:  0 CKR_OK

21: C_FindObjects
2014-01-28 04:00:43.580
[in] hSession = 0x5670001
[in] ulMaxObjectCount = 0x1
[out] ulObjectCount = 0x1
Object 0x8690003 matches
Returned:  0 CKR_OK

22: C_GetAttributeValue
2014-01-28 04:00:43.580
[in] hSession = 0x5670001
[in] hObject = 0x8690003
[in] pTemplate[1]: 
    CKA_CLASS             00007fff3bd35a58 / 8
[out] pTemplate[1]: 
    CKA_CLASS             CKO_PUBLIC_KEY       
Returned:  0 CKR_OK

23: C_GetAttributeValue
2014-01-28 04:00:43.580
[in] hSession = 0x5670001
[in] hObject = 0x8690003
[in] pTemplate[1]: 
    CKA_KEY_TYPE          00007fff3bd35a58 / 8
[out] pTemplate[1]: 
    CKA_KEY_TYPE          CKK_RSA            
Returned:  0 CKR_OK

24: C_GetAttributeValue
2014-01-28 04:00:43.580
[in] hSession = 0x5670001
[in] hObject = 0x8690003
[in] pTemplate[1]: 
    CKA_CLASS             00007fff3bd35a58 / 8
[out] pTemplate[1]: 
    CKA_CLASS             CKO_PUBLIC_KEY       
Returned:  0 CKR_OK

25: C_GetAttributeValue
2014-01-28 04:00:43.580
[in] hSession = 0x5670001
[in] hObject = 0x8690003
[in] pTemplate[1]: 
    CKA_MODULUS_BITS      00007fff3bd35a58 / 8
[out] pTemplate[1]: 
    CKA_MODULUS_BITS      00007fff3bd35a58 / 8
    00000000  00 08 00 00 00 00 00 00                          ........        
Returned:  0 CKR_OK

26: C_GetAttributeValue
2014-01-28 04:00:43.580
[in] hSession = 0x5670001
[in] hObject = 0x8690003
[in] pTemplate[1]: 
    CKA_LABEL             0000000000000000 / 0
[out] pTemplate[1]: 
    CKA_LABEL             0000000000000000 / 0
Returned:  0 CKR_OK

27: C_GetAttributeValue
2014-01-28 04:00:43.581
[in] hSession = 0x5670001
[in] hObject = 0x8690003
[in] pTemplate[1]: 
    CKA_LABEL             0000000000bb14d0 / 0
[out] pTemplate[1]: 
    CKA_LABEL             0000000000bb14d0 / 0
Returned:  0 CKR_OK

28: C_GetAttributeValue
2014-01-28 04:00:43.581
[in] hSession = 0x5670001
[in] hObject = 0x8690003
[in] pTemplate[1]: 
    CKA_ID                0000000000000000 / 0
[out] pTemplate[1]: 
    CKA_ID                0000000000000000 / 0
Returned:  0 CKR_OK

29: C_GetAttributeValue
2014-01-28 04:00:43.581
[in] hSession = 0x5670001
[in] hObject = 0x8690003
[in] pTemplate[1]: 
    CKA_ID                0000000000bb14d0 / 0
[out] pTemplate[1]: 
    CKA_ID                0000000000bb14d0 / 0
Returned:  0 CKR_OK

30: C_GetAttributeValue
2014-01-28 04:00:43.581
[in] hSession = 0x5670001
[in] hObject = 0x8690003
[in] pTemplate[1]: 
    CKA_ENCRYPT           00007fff3bd35ab7 / 1
[out] pTemplate[1]: 
    CKA_ENCRYPT           True
Returned:  0 CKR_OK

31: C_GetAttributeValue
2014-01-28 04:00:43.581
[in] hSession = 0x5670001
[in] hObject = 0x8690003
[in] pTemplate[1]: 
    CKA_VERIFY            00007fff3bd35ab7 / 1
[out] pTemplate[1]: 
    CKA_VERIFY            True
Returned:  0 CKR_OK

32: C_GetAttributeValue
2014-01-28 04:00:43.581
[in] hSession = 0x5670001
[in] hObject = 0x8690003
[in] pTemplate[1]: 
    CKA_WRAP              00007fff3bd35ab7 / 1
[out] pTemplate[1]: 
    CKA_WRAP              True
Returned:  0 CKR_OK

33: C_FindObjects
2014-01-28 04:00:43.582
[in] hSession = 0x5670001
[in] ulMaxObjectCount = 0x1
[out] ulObjectCount = 0x1
Object 0x8730004 matches
Returned:  0 CKR_OK

34: C_GetAttributeValue
2014-01-28 04:00:43.582
[in] hSession = 0x5670001
[in] hObject = 0x8730004
[in] pTemplate[1]: 
    CKA_CLASS             00007fff3bd35a58 / 8
[out] pTemplate[1]: 
    CKA_CLASS             CKO_CERTIFICATE      
Returned:  0 CKR_OK

35: C_GetAttributeValue
2014-01-28 04:00:43.582
[in] hSession = 0x5670001
[in] hObject = 0x8730004
[in] pTemplate[1]: 
    CKA_CERTIFICATE_TYPE  00007fff3bd35ab8 / 8
[out] pTemplate[1]: 
    CKA_CERTIFICATE_TYPE  CKC_X_509
Returned:  0 CKR_OK

36: C_GetAttributeValue
2014-01-28 04:00:43.582
[in] hSession = 0x5670001
[in] hObject = 0x8730004
[in] pTemplate[1]: 
    CKA_LABEL             0000000000000000 / 0
[out] pTemplate[1]: 
    CKA_LABEL             0000000000000000 / 0
Returned:  0 CKR_OK

37: C_GetAttributeValue
2014-01-28 04:00:43.582
[in] hSession = 0x5670001
[in] hObject = 0x8730004
[in] pTemplate[1]: 
    CKA_LABEL             0000000000bb14f0 / 0
[out] pTemplate[1]: 
    CKA_LABEL             0000000000bb14f0 / 0
Returned:  0 CKR_OK

38: C_GetAttributeValue
2014-01-28 04:00:43.582
[in] hSession = 0x5670001
[in] hObject = 0x8730004
[in] pTemplate[1]: 
    CKA_ID                0000000000000000 / 0
[out] pTemplate[1]: 
    CKA_ID                0000000000000000 / 0
Returned:  0 CKR_OK

39: C_GetAttributeValue
2014-01-28 04:00:43.582
[in] hSession = 0x5670001
[in] hObject = 0x8730004
[in] pTemplate[1]: 
    CKA_ID                0000000000bb14f0 / 0
[out] pTemplate[1]: 
    CKA_ID                0000000000bb14f0 / 0
Returned:  0 CKR_OK

40: C_FindObjects
2014-01-28 04:00:43.582
[in] hSession = 0x5670001
[in] ulMaxObjectCount = 0x1
[out] ulObjectCount = 0x0
Returned:  0 CKR_OK

41: C_FindObjectsFinal
2014-01-28 04:00:43.583
[in] hSession = 0x5670001
Returned:  0 CKR_OK

42: C_CloseSession
2014-01-28 04:00:43.583
[in] hSession = 0x5670001
Returned:  0 CKR_OK

43: C_Finalize
2014-01-28 04:00:43.583
Returned:  0 CKR_OK


log from ssh

OpenSSH_6.4, OpenSSL 1.0.1e 11 Feb 2013
debug1: Reading configuration data /etc/ssh/ssh_config
debug1: /etc/ssh/ssh_config line 19: Applying options for *
debug1: Connecting to 192.1.1.1 [192.1.1.1] port 22.
debug1: Connection established.
debug1: permanently_set_uid: 0/0
debug1: manufacturerID <SafeNet, Inc.> cryptokiVersion 2.20 libraryDescription <SafeNet eToken PKCS#11> libraryVersion 8.3
debug1: label <mToken2> manufacturerID <SafeNet, Inc.> model <eToken> serial <01db04cc> flags 0x601
no keys


From tgc at jupiterrise.com  Wed Jan 29 01:28:55 2014
From: tgc at jupiterrise.com (Tom G. Christensen)
Date: Tue, 28 Jan 2014 15:28:55 +0100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.11.1401282212300.24928@natsu.mindrot.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52E507CC.7090107@jupiterrise.com>
 <alpine.BSO.2.11.1401271046480.9143@natsu.mindrot.org>
 <52E64194.7080505@jupiterrise.com>
 <alpine.BSO.2.11.1401272308490.24928@natsu.mindrot.org>
 <52E6B5BC.1060908@jupiterrise.com>
 <CALDDTe2JSBrRe8zYJ7xK8BO0th2526Kmws_-C_4fZjUNrS_4=A@mail.gmail.com>
 <52E78C59.90006@jupiterrise.com>
 <alpine.BSO.2.11.1401282212300.24928@natsu.mindrot.org>
Message-ID: <52E7BEA7.2080202@jupiterrise.com>

On 28/01/14 12:17, Damien Miller wrote:
> As for altering the test to take longer - you could try increasing
> the 'sleep 3' statements in rekey.sh to something longer and see
> if that helps. Unfortunately, this is a more fiddly one to avoid the
> races on.
>
AFAICT the two tests that fail are run through the ssh_data_rekeying 
function which does not include a sleep.

The failed tests:
client rekey chacha20-poly1305 at openssh.com 
diffie-hellman-group-exchange-sha1
client rekey chacha20-poly1305 at openssh.com 
diffie-hellman-group-exchange-sha256

See also http://jupiterrise.com/tmp where the failed-* logs are.

-tgc

From plautrba at redhat.com  Wed Jan 29 01:51:29 2014
From: plautrba at redhat.com (Petr Lautrbach)
Date: Tue, 28 Jan 2014 15:51:29 +0100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
Message-ID: <52E7C3F1.5030306@redhat.com>

Hi,

regress/agent.sh reports wrong exit codes when some of tests fail:

run test agent.sh ...
agent fwd proto 1 failed (exit code 0)
agent fwd proto 2 failed (exit code 0)
failed simple agent test

It's probably due to using $? value in error message after
"if [ $? -ne 0 ]; then"
which sets $? to 0.

With the attached patch, the output would look like:
run test agent.sh ...
agent fwd proto 1 failed (exit code 255)
agent fwd proto 2 failed (exit code 255)
failed simple agent test


I noticed it when I'd run "make tests" by an user, who runs ssh-agent with a static socket from .bashrc:
eval `ssh-agent -a /tmp/plautrba/.ssh-agent.sock`

In this case, the agent.sh always fails, but I consider this more as a configuration issue than
a real bug in test suite.

However, with the standard .bashrc I can confirm that "make tests" passes on RHEL-7 Beta.

Thanks,

Petr
-- 
Petr Lautrbach
Security Technologies
Red Hat

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: agent.sh.patch
Type: text/x-patch
Size: 1687 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20140128/947b3a2e/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20140128/947b3a2e/attachment-0003.bin>

From mancha1 at hush.com  Wed Jan 29 02:12:15 2014
From: mancha1 at hush.com (mancha)
Date: Tue, 28 Jan 2014 15:12:15 +0000 (UTC)
Subject: default change in 6.2 breaks sslh
References: <52E7A86F.40400@rakul.info>
Message-ID: <loom.20140128T153318-615@post.gmane.org>

Rakulenko A. <me <at> rakul.info> writes:
> 
> Hi all!
> 
> I'm using sslh. It's a multiplexer, used to let you have ssh, https,
> stunnel, etc on one port.
> In 6.2 there is a change in default behaviour:
> 
>  * ssh(1): When SSH protocol 2 only is selected (the default), ssh(1)
>    now immediately sends its SSH protocol banner to the server without
>    waiting to receive the server's banner, saving time when connecting.
> 
> which, i suppose, breaks the way sslh detects openssh traffic. I found
> the cause in this discussion:
> http://rutschle.net/pipermail/sslh/2011-January/000045.html
> which is related to similar problem, but with "connectBot" - a mobile
> ssh client.

The ML message you post, aside from being inaccurate (nothing in the
SSH 2.0 specification prevents the client from firing off its banner
immediately), is quite dated.

I built sslh 1.15 (latest point release) and it has no issue handling
an OpenSSH 6.4 client connect in Protocol 2 mode (where the client
sends its banner immediately after the TCP handshake).

Looking at old sslh code, it seems it once relied on client-side
silence to distinguish ssh from ssl traffic (ugh). What version
of sslh are you using?
 
> Maybe, if i'm getting everything right, there may be a way to add an
> option to force ssh to wait for banner, set off by default?

My quick read of current OpenSSH code is the client banner will be
sent immediately when in "Protocol 2" mode and there is no override
for this behavior.

--mancha


From tim at multitalents.net  Wed Jan 29 05:29:31 2014
From: tim at multitalents.net (Tim Rice)
Date: Tue, 28 Jan 2014 10:29:31 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <52E7C3F1.5030306@redhat.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52E7C3F1.5030306@redhat.com>
Message-ID: <Pine.UW2.4.64.1401281026470.20351@server01.int.multitalents.net>

On Tue, 28 Jan 2014, Petr Lautrbach wrote:

> Hi,
> 
> regress/agent.sh reports wrong exit codes when some of tests fail:
> 
> run test agent.sh ...
> agent fwd proto 1 failed (exit code 0)
> agent fwd proto 2 failed (exit code 0)
> failed simple agent test
> 
> It's probably due to using $? value in error message after
> "if [ $? -ne 0 ]; then"
> which sets $? to 0.

Thanks for spotting this. I've commited your patch and also fixed
the same problem in agent-ptrace.sh.


-- 
Tim Rice				Multitalents
tim at multitalents.net



From djm at mindrot.org  Wed Jan 29 09:50:40 2014
From: djm at mindrot.org (Damien Miller)
Date: Wed, 29 Jan 2014 09:50:40 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <52E7BEA7.2080202@jupiterrise.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52E507CC.7090107@jupiterrise.com>
 <alpine.BSO.2.11.1401271046480.9143@natsu.mindrot.org>
 <52E64194.7080505@jupiterrise.com>
 <alpine.BSO.2.11.1401272308490.24928@natsu.mindrot.org>
 <52E6B5BC.1060908@jupiterrise.com>
 <CALDDTe2JSBrRe8zYJ7xK8BO0th2526Kmws_-C_4fZjUNrS_4=A@mail.gmail.com>
 <52E78C59.90006@jupiterrise.com>
 <alpine.BSO.2.11.1401282212300.24928@natsu.mindrot.org>
 <52E7BEA7.2080202@jupiterrise.com>
Message-ID: <alpine.BSO.2.11.1401290932590.24928@natsu.mindrot.org>

On Tue, 28 Jan 2014, Tom G. Christensen wrote:

> On 28/01/14 12:17, Damien Miller wrote:
> > As for altering the test to take longer - you could try increasing
> > the 'sleep 3' statements in rekey.sh to something longer and see
> > if that helps. Unfortunately, this is a more fiddly one to avoid the
> > races on.
> > 
> AFAICT the two tests that fail are run through the ssh_data_rekeying function
> which does not include a sleep.
> 
> The failed tests:
> client rekey chacha20-poly1305 at openssh.com diffie-hellman-group-exchange-sha1
> client rekey chacha20-poly1305 at openssh.com
> diffie-hellman-group-exchange-sha256
> 
> See also http://jupiterrise.com/tmp where the failed-* logs are.

It shows the client getting a "Write failed: broken pipe" on the socket to
the server and the last message on the server being "debug1:
SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth]".

I suspect the server might be silently crashing in packet.c:packet_write_wait
or possibly dh.c:dh_gen_key. These are usually a little tricky to debug.

The way I usually start is by sprinkling logit() statements though these
functions to see where it gets to.

-d


From list at eworm.de  Wed Jan 29 18:32:21 2014
From: list at eworm.de (Christian Hesse)
Date: Wed, 29 Jan 2014 08:32:21 +0100
Subject: [PATCH 1/1] rework printing for visual host key upper border
In-Reply-To: <1390908137-2443-1-git-send-email-mail@eworm.de>
References: <1390908137-2443-1-git-send-email-mail@eworm.de>
Message-ID: <20140129083221.7ebd4589@leda.localdomain>

Christian Hesse <mail at eworm.de> on Tue, 2014/01/28 12:22:
> Key types are getting longer and the current implementation of visual
> host key breaks with ED25519, resulting in (note the missing bracket):
> 
> +--[ED25519  256--+
> 
> This reworks the calculation of visual host key upper border. Please be
> aware that this may change the output for other key types as well.

Just to show the differences... This is a before and after comparison:

+--[ DSA 1024]----+
+---[DSA 1024]----+

+--[ RSA 2048]----+
+---[RSA 2048]----+

+--[ECDSA  256]---+
+---[ECDSA 256]---+

+--[ED25519  256--+
+--[ED25519 256]--+
-- 
main(a){char*c=/*    Schoene Gruesse                         */"B?IJj;MEH"
"CX:;",b;for(a/*    Chris           get my mail address:    */=0;b=c[a++];)
putchar(b-1/(/*               gcc -o sig sig.c && ./sig    */b/42*2-3)*42);}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20140129/65c705e9/attachment.bin>

From tgc at jupiterrise.com  Wed Jan 29 19:28:08 2014
From: tgc at jupiterrise.com (Tom G. Christensen)
Date: Wed, 29 Jan 2014 09:28:08 +0100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <52E507CC.7090107@jupiterrise.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52E507CC.7090107@jupiterrise.com>
Message-ID: <52E8BB98.2010501@jupiterrise.com>

On 26/01/14 14:04, Tom Christensen wrote:
> During configure I get this error:
> ./configure[10160]: ==: unknown test operator
> This is a typo in configure.ac, in the pie test.
>

Patch attached.

-tgc



-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-configure.ac-use-for-shell-test-and-not.patch
Type: text/x-patch
Size: 797 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20140129/0dfb1ae4/attachment.bin>

From tgc at jupiterrise.com  Wed Jan 29 19:32:22 2014
From: tgc at jupiterrise.com (Tom G. Christensen)
Date: Wed, 29 Jan 2014 09:32:22 +0100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <52E660EC.6050003@jupiterrise.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52E507CC.7090107@jupiterrise.com>
 <alpine.BSO.2.11.1401271046480.9143@natsu.mindrot.org>
 <CALDDTe08cnHYrtd-HO5rU2rAVSWH5Bcq-E9U4Uc-ySVi+mxD6w@mail.gmail.com>
 <CALDDTe1t6gvAA1MBvwWY34OmnB9vpevV8ezfnTcki8CLbo6FVA@mail.gmail.com>
 <52E660EC.6050003@jupiterrise.com>
Message-ID: <52E8BC96.2060300@jupiterrise.com>

On 27/01/14 14:36, Tom G. Christensen wrote:
> So this is the real problem:
> checking for inttypes.h... no
> ...
> checking for uintXX_t types in inttypes.h... yes
> ...
>
> It should not be looking for uintXX_t in inttypes.h if the header is
> unuseable (ie. ac_cv_header_inttypes_h=no).
>
Patch attached.
It will avoid the extra testing for types in headers we already know are 
not available.
This follows the style already found in configure.ac.

It fixes the build on IRIX 5.3 when using the SGI compiler, and a quick 
test on CentOS 6.5 verifies that it makes no difference there.

> Also even if inttypes.h is available and defines uintXX_t, the source does not seem to make consistent use of it (only used in roaming_*.c).

This part I've not touched.
There is some inconsistence in the use of <stdint.h> and <inttypes.h>.
In includes.h <stdint.h> is always included if HAVE_STDINT_H is true, in 
which case it makes no sense that poly1305.c also includes it.
The roaming_c*.c files check for HAVE_INTTYPES_H and includes it if 
available, but relies on includes.h otherwise.

Should includes.h simply check HAVE_INTTYPES_H? perhaps only if 
HAVE_STDINT_H is not defined?

-tgc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-configure.ac-only-look-for-types-in-useable-headers.patch
Type: text/x-patch
Size: 1573 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20140129/d2a321d8/attachment-0001.bin>

From list at eworm.de  Wed Jan 29 20:31:38 2014
From: list at eworm.de (Christian Hesse)
Date: Wed, 29 Jan 2014 10:31:38 +0100
Subject: tests: multiplex.sh fails on i686
Message-ID: <20140129103138.595beae3@leda.localdomain>

Hello everybody,

compiled openssh git master (6f917ad) on i686 without problems, but tests
fail:

[...]
run test multiplex.sh ...
test connection multiplexing: envpass
test connection multiplexing: transfer
scp: failed copy /tmp/openssh-git/src/openssh/regress/data
cmp: /tmp/openssh-git/src/openssh/regress/copy: No such file or directory
scp: corrupted copy of /tmp/openssh-git/src/openssh/regress/data test
connection multiplexing: status 0 test connection multiplexing: status 1 test
connection multiplexing: status 4 test connection multiplexing: status 5 test
connection multiplexing: status 44 test connection multiplexing: cmd check
test connection multiplexing: cmd forward local
test connection multiplexing: cmd forward remote
test connection multiplexing: cmd exit
test connection multiplexing: cmd stop
failed connection multiplexing
Makefile:167: recipe for target 't-exec' failed
make[1]: *** [t-exec] Error 1
make[1]: Leaving directory
'/tmp/openssh-git/src/openssh/regress' Makefile:412:
recipe for target 'tests' failed make: *** [tests] Error 2

Everything works just fine on x86_64.
-- 
main(a){char*c=/*    Schoene Gruesse                         */"B?IJj;MEH"
"CX:;",b;for(a/*    Chris           get my mail address:    */=0;b=c[a++];)
putchar(b-1/(/*               gcc -o sig sig.c && ./sig    */b/42*2-3)*42);}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20140129/26bf59f4/attachment.bin>

From list at eworm.de  Wed Jan 29 20:48:33 2014
From: list at eworm.de (Christian Hesse)
Date: Wed, 29 Jan 2014 10:48:33 +0100
Subject: tests: multiplex.sh fails on i686
In-Reply-To: <20140129103138.595beae3@leda.localdomain>
References: <20140129103138.595beae3@leda.localdomain>
Message-ID: <20140129104833.09fc75be@leda.localdomain>

Christian Hesse <list at eworm.de> on Wed, 2014/01/29 10:31:
> Hello everybody,
> 
> compiled openssh git master (6f917ad) on i686 without problems, but tests
> fail:
> 
> [...]
> run test multiplex.sh ...
> test connection multiplexing: envpass
> test connection multiplexing: transfer
> scp: failed copy /tmp/openssh-git/src/openssh/regress/data
> cmp: /tmp/openssh-git/src/openssh/regress/copy: No such file or directory
> scp: corrupted copy of /tmp/openssh-git/src/openssh/regress/data test
> connection multiplexing: status 0 test connection multiplexing: status 1
> test connection multiplexing: status 4 test connection multiplexing: status
> 5 test connection multiplexing: status 44 test connection multiplexing: cmd
> check test connection multiplexing: cmd forward local
> test connection multiplexing: cmd forward remote
> test connection multiplexing: cmd exit
> test connection multiplexing: cmd stop
> failed connection multiplexing
> Makefile:167: recipe for target 't-exec' failed
> make[1]: *** [t-exec] Error 1
> make[1]: Leaving directory
> '/tmp/openssh-git/src/openssh/regress' Makefile:412:
> recipe for target 'tests' failed make: *** [tests] Error 2

Oh, this is a bit more complicated. It works just fine in a virtual machine,
but fails in a systemd nspawn container. Looking into that...

Is there a simple way to run/debug just this test?
-- 
main(a){char*c=/*    Schoene Gruesse                         */"B?IJj;MEH"
"CX:;",b;for(a/*    Chris           get my mail address:    */=0;b=c[a++];)
putchar(b-1/(/*               gcc -o sig sig.c && ./sig    */b/42*2-3)*42);}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20140129/13935ad1/attachment.bin>

From vinschen at redhat.com  Wed Jan 29 20:47:00 2014
From: vinschen at redhat.com (Corinna Vinschen)
Date: Wed, 29 Jan 2014 10:47:00 +0100
Subject: tests: multiplex.sh fails on i686
In-Reply-To: <20140129103138.595beae3@leda.localdomain>
References: <20140129103138.595beae3@leda.localdomain>
Message-ID: <20140129094700.GR2821@calimero.vinschen.de>

On Jan 29 10:31, Christian Hesse wrote:
> Hello everybody,
> 
> compiled openssh git master (6f917ad) on i686 without problems, but tests
> fail:
> 
> [...]
> run test multiplex.sh ...
> test connection multiplexing: envpass
> test connection multiplexing: transfer
> scp: failed copy /tmp/openssh-git/src/openssh/regress/data
> cmp: /tmp/openssh-git/src/openssh/regress/copy: No such file or directory
> scp: corrupted copy of /tmp/openssh-git/src/openssh/regress/data test
> connection multiplexing: status 0 test connection multiplexing: status 1 test
> connection multiplexing: status 4 test connection multiplexing: status 5 test
> connection multiplexing: status 44 test connection multiplexing: cmd check
> test connection multiplexing: cmd forward local
> test connection multiplexing: cmd forward remote
> test connection multiplexing: cmd exit
> test connection multiplexing: cmd stop
> failed connection multiplexing
> Makefile:167: recipe for target 't-exec' failed
> make[1]: *** [t-exec] Error 1
> make[1]: Leaving directory
> '/tmp/openssh-git/src/openssh/regress' Makefile:412:
> recipe for target 'tests' failed make: *** [tests] Error 2
> 
> Everything works just fine on x86_64.

It might be helpful for the developers to know the OS you're trying
this on, not only the CPU...


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/20140129/2b557369/attachment.bin>

From plautrba at redhat.com  Wed Jan 29 20:54:31 2014
From: plautrba at redhat.com (Petr Lautrbach)
Date: Wed, 29 Jan 2014 10:54:31 +0100
Subject: tests: multiplex.sh fails on i686
In-Reply-To: <20140129104833.09fc75be@leda.localdomain>
References: <20140129103138.595beae3@leda.localdomain>
 <20140129104833.09fc75be@leda.localdomain>
Message-ID: <52E8CFD7.2060009@redhat.com>

On 01/29/2014 10:48 AM, Christian Hesse wrote:
> Christian Hesse <list at eworm.de> on Wed, 2014/01/29 10:31:
>> Hello everybody,
>>
>> compiled openssh git master (6f917ad) on i686 without problems, but tests
>> fail:
>>
>> [...]
>> run test multiplex.sh ...
>> test connection multiplexing: envpass
>> test connection multiplexing: transfer
>> scp: failed copy /tmp/openssh-git/src/openssh/regress/data
>> cmp: /tmp/openssh-git/src/openssh/regress/copy: No such file or directory
>> scp: corrupted copy of /tmp/openssh-git/src/openssh/regress/data test
>> connection multiplexing: status 0 test connection multiplexing: status 1
>> test connection multiplexing: status 4 test connection multiplexing: status
>> 5 test connection multiplexing: status 44 test connection multiplexing: cmd
>> check test connection multiplexing: cmd forward local
>> test connection multiplexing: cmd forward remote
>> test connection multiplexing: cmd exit
>> test connection multiplexing: cmd stop
>> failed connection multiplexing
>> Makefile:167: recipe for target 't-exec' failed
>> make[1]: *** [t-exec] Error 1
>> make[1]: Leaving directory
>> '/tmp/openssh-git/src/openssh/regress' Makefile:412:
>> recipe for target 'tests' failed make: *** [tests] Error 2
> 
> Oh, this is a bit more complicated. It works just fine in a virtual machine,
> but fails in a systemd nspawn container. Looking into that...
> 
> Is there a simple way to run/debug just this test?
> 

You can find useful information in regress/README.regress


Petr
-- 
Petr Lautrbach
Security Technologies
Red Hat

Better technology. Faster innovation. Powered by community collaboration.
See how it works at redhat.com.

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

From djm at mindrot.org  Wed Jan 29 21:01:45 2014
From: djm at mindrot.org (Damien Miller)
Date: Wed, 29 Jan 2014 21:01:45 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <52E8BB98.2010501@jupiterrise.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52E507CC.7090107@jupiterrise.com> <52E8BB98.2010501@jupiterrise.com>
Message-ID: <alpine.BSO.2.11.1401292101370.24928@natsu.mindrot.org>

On Wed, 29 Jan 2014, Tom G. Christensen wrote:

> On 26/01/14 14:04, Tom Christensen wrote:
> > During configure I get this error:
> > ./configure[10160]: ==: unknown test operator
> > This is a typo in configure.ac, in the pie test.
> > 
> 
> Patch attached.

applied - thanks

From djm at mindrot.org  Wed Jan 29 21:02:56 2014
From: djm at mindrot.org (Damien Miller)
Date: Wed, 29 Jan 2014 21:02:56 +1100 (EST)
Subject: tests: multiplex.sh fails on i686
In-Reply-To: <20140129104833.09fc75be@leda.localdomain>
References: <20140129103138.595beae3@leda.localdomain>
 <20140129104833.09fc75be@leda.localdomain>
Message-ID: <alpine.BSO.2.11.1401292102190.24928@natsu.mindrot.org>

On Wed, 29 Jan 2014, Christian Hesse wrote:

> Oh, this is a bit more complicated. It works just fine in a virtual machine,
> but fails in a systemd nspawn container. Looking into that...
> 
> Is there a simple way to run/debug just this test?

yes:

make tests LTESTS=multiplex

you can look at regress/failed-* for what went wrong.

-d

From mail at eworm.de  Wed Jan 29 22:48:02 2014
From: mail at eworm.de (Christian Hesse)
Date: Wed, 29 Jan 2014 12:48:02 +0100
Subject: [PATCH 1/1] fix tests if scp is not installed
In-Reply-To: <20140129124529.39a7384a@leda.localdomain>
References: <20140129124529.39a7384a@leda.localdomain>
Message-ID: <1390996082-8535-1-git-send-email-mail@eworm.de>

From: Christian Hesse <eworm at leda.eworm.de>

---
 regress/multiplex.sh | 6 +++++-
 1 file changed, 5 insertion(+), 1 deletion(-)

diff --git a/regress/multiplex.sh b/regress/multiplex.sh
index 3e697e6..3b49b5b 100644
--- a/regress/multiplex.sh
+++ b/regress/multiplex.sh
@@ -12,6 +12,10 @@ fi
 
 P=3301  # test port
 
+SRC=$(dirname ${SCRIPT})
+cp ${SRC}/scp-ssh-wrapper.sh ${OBJ}/scp-ssh-wrapper.scp
+chmod 755 ${OBJ}/scp-ssh-wrapper.scp
+
 wait_for_mux_master_ready()
 {
 	for i in 1 2 3 4 5; do
@@ -66,7 +66,7 @@ cmp ${DATA} ${COPY}		|| fail "sftp: corrupted copy of ${DATA}"
 
 rm -f ${COPY}
 trace "scp transfer over multiplexed connection and check result"
-${SCP} -S ${SSH} -F $OBJ/ssh_config -oControlPath=$CTL otherhost:${DATA} ${COPY} >>$TEST_REGRESS_LOGFILE 2>&1
+${SCP} -S ${OBJ}/scp-ssh-wrapper.scp -F $OBJ/ssh_config -oControlPath=$CTL otherhost:${DATA} ${COPY} >>$TEST_REGRESS_LOGFILE 2>&1
 test -f ${COPY}			|| fail "scp: failed copy ${DATA}" 
 cmp ${DATA} ${COPY}		|| fail "scp: corrupted copy of ${DATA}"
 
-- 
1.8.5.3


From list at eworm.de  Wed Jan 29 22:45:29 2014
From: list at eworm.de (Christian Hesse)
Date: Wed, 29 Jan 2014 12:45:29 +0100
Subject: tests: multiplex.sh fails on i686
In-Reply-To: <alpine.BSO.2.11.1401292102190.24928@natsu.mindrot.org>
References: <20140129103138.595beae3@leda.localdomain>
 <20140129104833.09fc75be@leda.localdomain>
 <alpine.BSO.2.11.1401292102190.24928@natsu.mindrot.org>
Message-ID: <20140129124529.39a7384a@leda.localdomain>

Damien Miller <djm at mindrot.org> on Wed, 2014/01/29 21:02:
> On Wed, 29 Jan 2014, Christian Hesse wrote:
> 
> > Oh, this is a bit more complicated. It works just fine in a virtual
> > machine, but fails in a systemd nspawn container. Looking into that...
> > 
> > Is there a simple way to run/debug just this test?
> 
> yes:
> 
> make tests LTESTS=multiplex
> 
> you can look at regress/failed-* for what went wrong.

Thanks! That did the trick.

The problem is that openssh is not installed in the container and scp can not
be launched on the "remote" side. I will reply with a patch.
-- 
main(a){char*c=/*    Schoene Gruesse                         */"B?IJj;MEH"
"CX:;",b;for(a/*    Chris           get my mail address:    */=0;b=c[a++];)
putchar(b-1/(/*               gcc -o sig sig.c && ./sig    */b/42*2-3)*42);}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20140129/11573a06/attachment.bin>

From mfriedl at gmail.com  Thu Jan 30 06:46:20 2014
From: mfriedl at gmail.com (Markus Friedl)
Date: Wed, 29 Jan 2014 20:46:20 +0100
Subject: safenet eToken 5100 pkcs11 bug(?)
In-Reply-To: <FDA5192A-35C4-4C09-8664-3D76F522E5EC@yahoo.com>
References: <FDA5192A-35C4-4C09-8664-3D76F522E5EC@yahoo.com>
Message-ID: <5B87856F-2294-4362-8FCE-1A624863E8CB@gmail.com>

please try the current snapshot

Am 28.01.2014 um 15:02 schrieb Martin Meduna <cybermedi at yahoo.com>:

> Guys, I am not able to get it run. I can not say where is the problem but it seams that the openssh client is not able to get list of rsa key from token. See two logs from pkcs11-spy. one is for "ssh  -I" the second is for "pkcs11-tool -O"
> In the second log there is private_key visible or offered in the first one is not. 
> I use openssh 6.4 version on Linux or Mac.
> 
> 
> Log from ssh -I
> 0: C_GetFunctionList
> 2014-01-28 03:26:42.350
> Returned:  0 CKR_OK
> 
> 1: C_Initialize
> 2014-01-28 03:26:42.351
> [in] pInitArgs = (nil)
> Returned:  0 CKR_OK
> 
> 2: C_GetInfo
> 2014-01-28 03:26:42.352
> [out] pInfo: 
>      cryptokiVersion:         2.20
>      manufacturerID:         'SafeNet, Inc.                   '
>      flags:                   0
>      libraryDescription:     'SafeNet eToken PKCS#11          '
>      libraryVersion:          8.3
> Returned:  0 CKR_OK
> 
> 3: C_GetSlotList
> 2014-01-28 03:26:42.352
> [in] tokenPresent = 0x1
> [out] pSlotList: 
> Count is 1
> [out] *pulCount = 0x1
> Returned:  0 CKR_OK
> 
> 4: C_GetSlotList
> 2014-01-28 03:26:42.352
> [in] tokenPresent = 0x1
> [out] pSlotList: 
> Slot 0
> [out] *pulCount = 0x1
> Returned:  0 CKR_OK
> 
> 5: C_GetTokenInfo
> 2014-01-28 03:26:42.352
> [in] slotID = 0x0
> [out] pInfo: 
>      label:                  'mToken2                         '
>      manufacturerID:         'SafeNet, Inc.                   '
>      model:                  'eToken          '
>      serialNumber:           '01db04cc        '
>      ulMaxSessionCount:       0
>      ulSessionCount:          0
>      ulMaxRwSessionCount:     0
>      ulRwSessionCount:        0
>      ulMaxPinLen:             0
>      ulMinPinLen:             0
>      ulTotalPublicMemory:     73728
>      ulFreePublicMemory:      54312
>      ulTotalPrivateMemory:    73728
>      ulFreePrivateMemory:     54312
>      hardwareVersion:         8.0
>      firmwareVersion:         1.0
>      time:                   '                '
>      flags:                   601
>        CKF_RNG                          
>        CKF_DUAL_CRYPTO_OPERATIONS       
>        CKF_TOKEN_INITIALIZED            
> Returned:  0 CKR_OK
> 
> 6: C_OpenSession
> 2014-01-28 03:26:42.353
> [in] slotID = 0x0
> [in] flags = 0x6
> pApplication=(nil)
> Notify=(nil)
> [out] *phSession = 0x3c60002
> Returned:  0 CKR_OK
> 
> 7: C_FindObjectsInit
> 2014-01-28 03:26:42.353
> [in] hSession = 0x3c60002
> [in] pTemplate[1]: 
>    CKA_CLASS             CKO_PUBLIC_KEY       
> Returned:  0 CKR_OK
> 
> 8: C_FindObjects
> 2014-01-28 03:26:42.353
> [in] hSession = 0x3c60002
> [in] ulMaxObjectCount = 0x1
> [out] ulObjectCount = 0x1
> Object 0x8690003 matches
> Returned:  0 CKR_OK
> 
> 9: C_GetAttributeValue
> 2014-01-28 03:26:42.353
> [in] hSession = 0x3c60002
> [in] hObject = 0x8690003
> [in] pTemplate[3]: 
>    CKA_ID                0000000000000000 / 0
>    CKA_MODULUS           0000000000000000 / 0
>    CKA_PUBLIC_EXPONENT   0000000000000000 / 0
> [out] pTemplate[3]: 
>    CKA_ID                0000000000000000 / 0
>    CKA_MODULUS           0000000000000000 / 256
>    CKA_PUBLIC_EXPONENT   0000000000000000 / 3
> Returned:  0 CKR_OK
> 
> 10: C_FindObjects
> 2014-01-28 03:26:42.354
> [in] hSession = 0x3c60002
> [in] ulMaxObjectCount = 0x1
> [out] ulObjectCount = 0x0
> Returned:  0 CKR_OK
> 
> 11: C_FindObjectsFinal
> 2014-01-28 03:26:42.354
> [in] hSession = 0x3c60002
> Returned:  0 CKR_OK
> 
> 12: C_Finalize
> 2014-01-28 03:26:42.354
> Returned:  0 CKR_OK
> 
> Log from   pkcs11-tool --module=/usr/lib/x86_64-linux-gnu/pkcs11-spy.so -
> 
> *************** OpenSC PKCS#11 spy *****************
> Loaded: "/usr/lib/libeTPkcs11.so"
> 
> 0: C_GetFunctionList
> 2014-01-28 04:00:43.576
> Returned:  0 CKR_OK
> 
> 1: C_Initialize
> 2014-01-28 04:00:43.576
> [in] pInitArgs = (nil)
> Returned:  0 CKR_OK
> 
> 2: C_GetSlotList
> 2014-01-28 04:00:43.577
> [in] tokenPresent = 0x0
> [out] pSlotList: 
> Count is 6
> [out] *pulCount = 0x6
> Returned:  0 CKR_OK
> 
> 3: C_GetSlotList
> 2014-01-28 04:00:43.577
> [in] tokenPresent = 0x0
> [out] pSlotList: 
> Slot 0
> Slot 1
> Slot 2
> Slot 3
> Slot 4
> Slot 5
> [out] *pulCount = 0x6
> Returned:  0 CKR_OK
> 
> 4: C_GetSlotInfo
> 2014-01-28 04:00:43.577
> [in] slotID = 0x0
> [out] pInfo: 
>      slotDescription:        'AKS ifdh [Main Interface] 00 00 '
>                              '                                '
>      manufacturerID:         'SafeNet, Inc.                   '
>      hardwareVersion:         1.0
>      firmwareVersion:         0.0
>      flags:                   7
>        CKF_TOKEN_PRESENT                
>        CKF_REMOVABLE_DEVICE             
>        CKF_HW_SLOT                      
> Returned:  0 CKR_OK
> 
> 5: C_OpenSession
> 2014-01-28 04:00:43.578
> [in] slotID = 0x0
> [in] flags = 0x4
> pApplication=(nil)
> Notify=(nil)
> [out] *phSession = 0x5670001
> Returned:  0 CKR_OK
> 
> 6: C_FindObjectsInit
> 2014-01-28 04:00:43.578
> [in] hSession = 0x5670001
> [in] pTemplate[0]: 
> Returned:  0 CKR_OK
> 
> 7: C_FindObjects
> 2014-01-28 04:00:43.579
> [in] hSession = 0x5670001
> [in] ulMaxObjectCount = 0x1
> [out] ulObjectCount = 0x1
> Object 0x3c60002 matches
> Returned:  0 CKR_OK
> 
> 8: C_GetAttributeValue
> 2014-01-28 04:00:43.579
> [in] hSession = 0x5670001
> [in] hObject = 0x3c60002
> [in] pTemplate[1]: 
>    CKA_CLASS             00007fff3bd35a58 / 8
> [out] pTemplate[1]: 
>    CKA_CLASS             CKO_PRIVATE_KEY      
> Returned:  0 CKR_OK
> 
> 9: C_GetAttributeValue
> 2014-01-28 04:00:43.579
> [in] hSession = 0x5670001
> [in] hObject = 0x3c60002
> [in] pTemplate[1]: 
>    CKA_KEY_TYPE          00007fff3bd35a58 / 8
> [out] pTemplate[1]: 
>    CKA_KEY_TYPE          CKK_RSA            
> Returned:  0 CKR_OK
> 
> 10: C_GetAttributeValue
> 2014-01-28 04:00:43.579
> [in] hSession = 0x5670001
> [in] hObject = 0x3c60002
> [in] pTemplate[1]: 
>    CKA_CLASS             00007fff3bd35a58 / 8
> [out] pTemplate[1]: 
>    CKA_CLASS             CKO_PRIVATE_KEY      
> Returned:  0 CKR_OK
> 
> 11: C_GetAttributeValue
> 2014-01-28 04:00:43.579
> [in] hSession = 0x5670001
> [in] hObject = 0x3c60002
> [in] pTemplate[1]: 
>    CKA_LABEL             0000000000000000 / 0
> [out] pTemplate[1]: 
>    CKA_LABEL             0000000000000000 / 0
> Returned:  0 CKR_OK
> 
> 12: C_GetAttributeValue
> 2014-01-28 04:00:43.579
> [in] hSession = 0x5670001
> [in] hObject = 0x3c60002
> [in] pTemplate[1]: 
>    CKA_LABEL             0000000000bb14b0 / 0
> [out] pTemplate[1]: 
>    CKA_LABEL             0000000000bb14b0 / 0
> Returned:  0 CKR_OK
> 
> 13: C_GetAttributeValue
> 2014-01-28 04:00:43.579
> [in] hSession = 0x5670001
> [in] hObject = 0x3c60002
> [in] pTemplate[1]: 
>    CKA_ID                0000000000000000 / 0
> [out] pTemplate[1]: 
>    CKA_ID                0000000000000000 / 0
> Returned:  0 CKR_OK
> 
> 14: C_GetAttributeValue
> 2014-01-28 04:00:43.579
> [in] hSession = 0x5670001
> [in] hObject = 0x3c60002
> [in] pTemplate[1]: 
>    CKA_ID                0000000000bb14b0 / 0
> [out] pTemplate[1]: 
>    CKA_ID                0000000000bb14b0 / 0
> Returned:  0 CKR_OK
> 
> 15: C_GetAttributeValue
> 2014-01-28 04:00:43.579
> [in] hSession = 0x5670001
> [in] hObject = 0x3c60002
> [in] pTemplate[1]: 
>    CKA_DECRYPT           00007fff3bd35a5f / 1
> [out] pTemplate[1]: 
>    CKA_DECRYPT           True
> Returned:  0 CKR_OK
> 
> 16: C_GetAttributeValue
> 2014-01-28 04:00:43.580
> [in] hSession = 0x5670001
> [in] hObject = 0x3c60002
> [in] pTemplate[1]: 
>    CKA_SIGN              00007fff3bd35a5f / 1
> [out] pTemplate[1]: 
>    CKA_SIGN              True
> Returned:  0 CKR_OK
> 
> 17: C_GetAttributeValue
> 2014-01-28 04:00:43.580
> [in] hSession = 0x5670001
> [in] hObject = 0x3c60002
> [in] pTemplate[1]: 
>    CKA_? (0x80000001)    00007fff3bd35ab7 / 1
> [out] pTemplate[1]: 
>    CKA_? (0x80000001)    00007fff3bd35ab7 / 8
> Returned:  0 CKR_OK
> 
> 18: C_GetAttributeValue
> 2014-01-28 04:00:43.580
> [in] hSession = 0x5670001
> [in] hObject = 0x3c60002
> [in] pTemplate[1]: 
>    CKA_UNWRAP            00007fff3bd35a5f / 1
> [out] pTemplate[1]: 
>    CKA_UNWRAP            True
> Returned:  0 CKR_OK
> 
> 19: C_GetAttributeValue
> 2014-01-28 04:00:43.580
> [in] hSession = 0x5670001
> [in] hObject = 0x3c60002
> [in] pTemplate[1]: 
>    CKA_DERIVE            00007fff3bd35ab7 / 1
> [out] pTemplate[1]: 
>    CKA_DERIVE            False
> Returned:  0 CKR_OK
> 
> 20: C_GetAttributeValue
> 2014-01-28 04:00:43.580
> [in] hSession = 0x5670001
> [in] hObject = 0x3c60002
> [in] pTemplate[1]: 
>    CKA_ALWAYS_AUTHENTICATE  00007fff3bd35a5f / 1
> [out] pTemplate[1]: 
>    CKA_ALWAYS_AUTHENTICATE  False
> Returned:  0 CKR_OK
> 
> 21: C_FindObjects
> 2014-01-28 04:00:43.580
> [in] hSession = 0x5670001
> [in] ulMaxObjectCount = 0x1
> [out] ulObjectCount = 0x1
> Object 0x8690003 matches
> Returned:  0 CKR_OK
> 
> 22: C_GetAttributeValue
> 2014-01-28 04:00:43.580
> [in] hSession = 0x5670001
> [in] hObject = 0x8690003
> [in] pTemplate[1]: 
>    CKA_CLASS             00007fff3bd35a58 / 8
> [out] pTemplate[1]: 
>    CKA_CLASS             CKO_PUBLIC_KEY       
> Returned:  0 CKR_OK
> 
> 23: C_GetAttributeValue
> 2014-01-28 04:00:43.580
> [in] hSession = 0x5670001
> [in] hObject = 0x8690003
> [in] pTemplate[1]: 
>    CKA_KEY_TYPE          00007fff3bd35a58 / 8
> [out] pTemplate[1]: 
>    CKA_KEY_TYPE          CKK_RSA            
> Returned:  0 CKR_OK
> 
> 24: C_GetAttributeValue
> 2014-01-28 04:00:43.580
> [in] hSession = 0x5670001
> [in] hObject = 0x8690003
> [in] pTemplate[1]: 
>    CKA_CLASS             00007fff3bd35a58 / 8
> [out] pTemplate[1]: 
>    CKA_CLASS             CKO_PUBLIC_KEY       
> Returned:  0 CKR_OK
> 
> 25: C_GetAttributeValue
> 2014-01-28 04:00:43.580
> [in] hSession = 0x5670001
> [in] hObject = 0x8690003
> [in] pTemplate[1]: 
>    CKA_MODULUS_BITS      00007fff3bd35a58 / 8
> [out] pTemplate[1]: 
>    CKA_MODULUS_BITS      00007fff3bd35a58 / 8
>    00000000  00 08 00 00 00 00 00 00                          ........        
> Returned:  0 CKR_OK
> 
> 26: C_GetAttributeValue
> 2014-01-28 04:00:43.580
> [in] hSession = 0x5670001
> [in] hObject = 0x8690003
> [in] pTemplate[1]: 
>    CKA_LABEL             0000000000000000 / 0
> [out] pTemplate[1]: 
>    CKA_LABEL             0000000000000000 / 0
> Returned:  0 CKR_OK
> 
> 27: C_GetAttributeValue
> 2014-01-28 04:00:43.581
> [in] hSession = 0x5670001
> [in] hObject = 0x8690003
> [in] pTemplate[1]: 
>    CKA_LABEL             0000000000bb14d0 / 0
> [out] pTemplate[1]: 
>    CKA_LABEL             0000000000bb14d0 / 0
> Returned:  0 CKR_OK
> 
> 28: C_GetAttributeValue
> 2014-01-28 04:00:43.581
> [in] hSession = 0x5670001
> [in] hObject = 0x8690003
> [in] pTemplate[1]: 
>    CKA_ID                0000000000000000 / 0
> [out] pTemplate[1]: 
>    CKA_ID                0000000000000000 / 0
> Returned:  0 CKR_OK
> 
> 29: C_GetAttributeValue
> 2014-01-28 04:00:43.581
> [in] hSession = 0x5670001
> [in] hObject = 0x8690003
> [in] pTemplate[1]: 
>    CKA_ID                0000000000bb14d0 / 0
> [out] pTemplate[1]: 
>    CKA_ID                0000000000bb14d0 / 0
> Returned:  0 CKR_OK
> 
> 30: C_GetAttributeValue
> 2014-01-28 04:00:43.581
> [in] hSession = 0x5670001
> [in] hObject = 0x8690003
> [in] pTemplate[1]: 
>    CKA_ENCRYPT           00007fff3bd35ab7 / 1
> [out] pTemplate[1]: 
>    CKA_ENCRYPT           True
> Returned:  0 CKR_OK
> 
> 31: C_GetAttributeValue
> 2014-01-28 04:00:43.581
> [in] hSession = 0x5670001
> [in] hObject = 0x8690003
> [in] pTemplate[1]: 
>    CKA_VERIFY            00007fff3bd35ab7 / 1
> [out] pTemplate[1]: 
>    CKA_VERIFY            True
> Returned:  0 CKR_OK
> 
> 32: C_GetAttributeValue
> 2014-01-28 04:00:43.581
> [in] hSession = 0x5670001
> [in] hObject = 0x8690003
> [in] pTemplate[1]: 
>    CKA_WRAP              00007fff3bd35ab7 / 1
> [out] pTemplate[1]: 
>    CKA_WRAP              True
> Returned:  0 CKR_OK
> 
> 33: C_FindObjects
> 2014-01-28 04:00:43.582
> [in] hSession = 0x5670001
> [in] ulMaxObjectCount = 0x1
> [out] ulObjectCount = 0x1
> Object 0x8730004 matches
> Returned:  0 CKR_OK
> 
> 34: C_GetAttributeValue
> 2014-01-28 04:00:43.582
> [in] hSession = 0x5670001
> [in] hObject = 0x8730004
> [in] pTemplate[1]: 
>    CKA_CLASS             00007fff3bd35a58 / 8
> [out] pTemplate[1]: 
>    CKA_CLASS             CKO_CERTIFICATE      
> Returned:  0 CKR_OK
> 
> 35: C_GetAttributeValue
> 2014-01-28 04:00:43.582
> [in] hSession = 0x5670001
> [in] hObject = 0x8730004
> [in] pTemplate[1]: 
>    CKA_CERTIFICATE_TYPE  00007fff3bd35ab8 / 8
> [out] pTemplate[1]: 
>    CKA_CERTIFICATE_TYPE  CKC_X_509
> Returned:  0 CKR_OK
> 
> 36: C_GetAttributeValue
> 2014-01-28 04:00:43.582
> [in] hSession = 0x5670001
> [in] hObject = 0x8730004
> [in] pTemplate[1]: 
>    CKA_LABEL             0000000000000000 / 0
> [out] pTemplate[1]: 
>    CKA_LABEL             0000000000000000 / 0
> Returned:  0 CKR_OK
> 
> 37: C_GetAttributeValue
> 2014-01-28 04:00:43.582
> [in] hSession = 0x5670001
> [in] hObject = 0x8730004
> [in] pTemplate[1]: 
>    CKA_LABEL             0000000000bb14f0 / 0
> [out] pTemplate[1]: 
>    CKA_LABEL             0000000000bb14f0 / 0
> Returned:  0 CKR_OK
> 
> 38: C_GetAttributeValue
> 2014-01-28 04:00:43.582
> [in] hSession = 0x5670001
> [in] hObject = 0x8730004
> [in] pTemplate[1]: 
>    CKA_ID                0000000000000000 / 0
> [out] pTemplate[1]: 
>    CKA_ID                0000000000000000 / 0
> Returned:  0 CKR_OK
> 
> 39: C_GetAttributeValue
> 2014-01-28 04:00:43.582
> [in] hSession = 0x5670001
> [in] hObject = 0x8730004
> [in] pTemplate[1]: 
>    CKA_ID                0000000000bb14f0 / 0
> [out] pTemplate[1]: 
>    CKA_ID                0000000000bb14f0 / 0
> Returned:  0 CKR_OK
> 
> 40: C_FindObjects
> 2014-01-28 04:00:43.582
> [in] hSession = 0x5670001
> [in] ulMaxObjectCount = 0x1
> [out] ulObjectCount = 0x0
> Returned:  0 CKR_OK
> 
> 41: C_FindObjectsFinal
> 2014-01-28 04:00:43.583
> [in] hSession = 0x5670001
> Returned:  0 CKR_OK
> 
> 42: C_CloseSession
> 2014-01-28 04:00:43.583
> [in] hSession = 0x5670001
> Returned:  0 CKR_OK
> 
> 43: C_Finalize
> 2014-01-28 04:00:43.583
> Returned:  0 CKR_OK
> 
> 
> log from ssh
> 
> OpenSSH_6.4, OpenSSL 1.0.1e 11 Feb 2013
> debug1: Reading configuration data /etc/ssh/ssh_config
> debug1: /etc/ssh/ssh_config line 19: Applying options for *
> debug1: Connecting to 192.1.1.1 [192.1.1.1] port 22.
> debug1: Connection established.
> debug1: permanently_set_uid: 0/0
> debug1: manufacturerID <SafeNet, Inc.> cryptokiVersion 2.20 libraryDescription <SafeNet eToken PKCS#11> libraryVersion 8.3
> debug1: label <mToken2> manufacturerID <SafeNet, Inc.> model <eToken> serial <01db04cc> flags 0x601
> no keys
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


From djm at mindrot.org  Thu Jan 30 09:48:08 2014
From: djm at mindrot.org (Damien Miller)
Date: Thu, 30 Jan 2014 09:48:08 +1100 (EST)
Subject: [PATCH 1/1] fix tests if scp is not installed
In-Reply-To: <1390996082-8535-1-git-send-email-mail@eworm.de>
References: <20140129124529.39a7384a@leda.localdomain>
 <1390996082-8535-1-git-send-email-mail@eworm.de>
Message-ID: <alpine.BSO.2.11.1401300943040.24928@natsu.mindrot.org>

On Wed, 29 Jan 2014, Christian Hesse wrote:

> -${SCP} -S ${SSH} -F $OBJ/ssh_config -oControlPath=$CTL otherhost:${DATA} ${COPY} >>$TEST_REGRESS_LOGFILE 2>&1
> +${SCP} -S ${OBJ}/scp-ssh-wrapper.scp -F $OBJ/ssh_config -oControlPath=$CTL otherhost:${DATA} ${COPY} >>$TEST_REGRESS_LOGFILE 2>&1

Unfortunately, this will cause scp to skip using ssh completely as the
-S option specifies a replacement for ssh. We could either 1) make a
different wrapper that runs the scp under test via ssh, 2) add an option
to scp that lets it specify an explicit path to a scp binary to run on
the remote end or 3) remove scp from the test entirely.

I don't much like (2) as I don't want to add more options.

-d

From djm at mindrot.org  Thu Jan 30 10:21:55 2014
From: djm at mindrot.org (Damien Miller)
Date: Thu, 30 Jan 2014 10:21:55 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <52E8BC96.2060300@jupiterrise.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52E507CC.7090107@jupiterrise.com>
 <alpine.BSO.2.11.1401271046480.9143@natsu.mindrot.org>
 <CALDDTe08cnHYrtd-HO5rU2rAVSWH5Bcq-E9U4Uc-ySVi+mxD6w@mail.gmail.com>
 <CALDDTe1t6gvAA1MBvwWY34OmnB9vpevV8ezfnTcki8CLbo6FVA@mail.gmail.com>
 <52E660EC.6050003@jupiterrise.com> <52E8BC96.2060300@jupiterrise.com>
Message-ID: <alpine.BSO.2.11.1401301021370.24928@natsu.mindrot.org>

On Wed, 29 Jan 2014, Tom G. Christensen wrote:

> Patch attached.
> It will avoid the extra testing for types in headers we already know are not
> available.
> This follows the style already found in configure.ac.

Applied - thanks

-d

From dtucker at zip.com.au  Thu Jan 30 10:23:27 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 30 Jan 2014 10:23:27 +1100
Subject: [PATCH 1/1] fix tests if scp is not installed
In-Reply-To: <alpine.BSO.2.11.1401300943040.24928@natsu.mindrot.org>
References: <20140129124529.39a7384a@leda.localdomain>
 <1390996082-8535-1-git-send-email-mail@eworm.de>
 <alpine.BSO.2.11.1401300943040.24928@natsu.mindrot.org>
Message-ID: <CALDDTe3J5u1XLG1MNrP7xqbcevLHWkrU4=YA1v7fmO0JxNz4NQ@mail.gmail.com>

On Thu, Jan 30, 2014 at 9:48 AM, Damien Miller <djm at mindrot.org> wrote:
> Unfortunately, this will cause scp to skip using ssh completely as the
> -S option specifies a replacement for ssh. We could either 1) make a
> different wrapper that runs the scp under test via ssh, 2) add an option
> to scp that lets it specify an explicit path to a scp binary to run on
> the remote end or 3) remove scp from the test entirely.

4) use ssh -oSendEnv to set $PATH to find the scp we want to test?

-- 
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  Thu Jan 30 10:29:57 2014
From: djm at mindrot.org (Damien Miller)
Date: Thu, 30 Jan 2014 10:29:57 +1100 (EST)
Subject: [PATCH 1/1] fix tests if scp is not installed
In-Reply-To: <CALDDTe3J5u1XLG1MNrP7xqbcevLHWkrU4=YA1v7fmO0JxNz4NQ@mail.gmail.com>
References: <20140129124529.39a7384a@leda.localdomain>
 <1390996082-8535-1-git-send-email-mail@eworm.de>
 <alpine.BSO.2.11.1401300943040.24928@natsu.mindrot.org>
 <CALDDTe3J5u1XLG1MNrP7xqbcevLHWkrU4=YA1v7fmO0JxNz4NQ@mail.gmail.com>
Message-ID: <alpine.BSO.2.11.1401301026590.24928@natsu.mindrot.org>

On Thu, 30 Jan 2014, Darren Tucker wrote:

> On Thu, Jan 30, 2014 at 9:48 AM, Damien Miller <djm at mindrot.org> wrote:
> > Unfortunately, this will cause scp to skip using ssh completely as the
> > -S option specifies a replacement for ssh. We could either 1) make a
> > different wrapper that runs the scp under test via ssh, 2) add an option
> > to scp that lets it specify an explicit path to a scp binary to run on
> > the remote end or 3) remove scp from the test entirely.
> 
> 4) use ssh -oSendEnv to set $PATH to find the scp we want to test?

I could be wrong, but I think PATH is overridden when sent via SendEnv

-d

From djm at mindrot.org  Thu Jan 30 10:42:20 2014
From: djm at mindrot.org (Damien Miller)
Date: Thu, 30 Jan 2014 10:42:20 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <52E7BEA7.2080202@jupiterrise.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52E507CC.7090107@jupiterrise.com>
 <alpine.BSO.2.11.1401271046480.9143@natsu.mindrot.org>
 <52E64194.7080505@jupiterrise.com>
 <alpine.BSO.2.11.1401272308490.24928@natsu.mindrot.org>
 <52E6B5BC.1060908@jupiterrise.com>
 <CALDDTe2JSBrRe8zYJ7xK8BO0th2526Kmws_-C_4fZjUNrS_4=A@mail.gmail.com>
 <52E78C59.90006@jupiterrise.com>
 <alpine.BSO.2.11.1401282212300.24928@natsu.mindrot.org>
 <52E7BEA7.2080202@jupiterrise.com>
Message-ID: <alpine.BSO.2.11.1401301033140.24928@natsu.mindrot.org>

On Tue, 28 Jan 2014, Tom G. Christensen wrote:

> On 28/01/14 12:17, Damien Miller wrote:
> > As for altering the test to take longer - you could try increasing
> > the 'sleep 3' statements in rekey.sh to something longer and see
> > if that helps. Unfortunately, this is a more fiddly one to avoid the
> > races on.
> > 
> AFAICT the two tests that fail are run through the ssh_data_rekeying function
> which does not include a sleep.
> 
> The failed tests:
> client rekey chacha20-poly1305 at openssh.com diffie-hellman-group-exchange-sha1
> client rekey chacha20-poly1305 at openssh.com
> diffie-hellman-group-exchange-sha256
> 
> See also http://jupiterrise.com/tmp where the failed-* logs are.

Darren and I just talked about this and we have a theory of
what is going wrong. chacha20-poly1305 at openssh.com demands the
most key material from the key exchange and thus causes the
diffie-hellman-group-exchange-* methods to select their largest and most
computationally expensive DH groups.

So your poor machine is trying to do these 8kbit modular exponentiations
and they are taking too long for the tests' default LoginGraceTime of
two minutes.

Unfortunately we don't have a good way to report this, as the login
grace stuff runs as a SIGALARM handler and Irix doesn't have a
signal-safe fprintf or syslog_r.

Fortunately, working around this in the test is easy:

Index: regress/test-exec.sh
===================================================================
RCS file: /var/cvs/openssh/regress/test-exec.sh,v
retrieving revision 1.61
diff -u -p -r1.61 test-exec.sh
--- regress/test-exec.sh	9 Nov 2013 05:55:03 -0000	1.61
+++ regress/test-exec.sh	29 Jan 2014 23:37:41 -0000
@@ -328,6 +328,7 @@ cat << EOF > $OBJ/sshd_config
 	StrictModes		no
 	Port			$PORT
 	Protocol		2,1
+	LoginGraceTime		15m
 	AddressFamily		inet
 	ListenAddress		127.0.0.1
 	#ListenAddress		::1

Please let us know if this works.

-d

From djm at mindrot.org  Thu Jan 30 11:11:10 2014
From: djm at mindrot.org (Damien Miller)
Date: Thu, 30 Jan 2014 11:11:10 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.11.1401301033140.24928@natsu.mindrot.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52E507CC.7090107@jupiterrise.com>
 <alpine.BSO.2.11.1401271046480.9143@natsu.mindrot.org>
 <52E64194.7080505@jupiterrise.com>
 <alpine.BSO.2.11.1401272308490.24928@natsu.mindrot.org>
 <52E6B5BC.1060908@jupiterrise.com>
 <CALDDTe2JSBrRe8zYJ7xK8BO0th2526Kmws_-C_4fZjUNrS_4=A@mail.gmail.com>
 <52E78C59.90006@jupiterrise.com>
 <alpine.BSO.2.11.1401282212300.24928@natsu.mindrot.org>
 <52E7BEA7.2080202@jupiterrise.com>
 <alpine.BSO.2.11.1401301033140.24928@natsu.mindrot.org>
Message-ID: <alpine.BSO.2.11.1401301054560.24928@natsu.mindrot.org>

On Thu, 30 Jan 2014, Damien Miller wrote:

> Fortunately, working around this in the test is easy:

here's a better patch that doesn't break login-timeout

Index: regress/login-timeout.sh
===================================================================
RCS file: /var/cvs/openssh/regress/login-timeout.sh,v
retrieving revision 1.7
diff -u -p -r1.7 login-timeout.sh
--- regress/login-timeout.sh	17 May 2013 10:41:07 -0000	1.7
+++ regress/login-timeout.sh	29 Jan 2014 23:55:26 -0000
@@ -4,6 +4,8 @@
 tid="connect after login grace timeout"
 
 trace "test login grace with privsep"
+cp $OBJ/sshd_config $OBJ/sshd_config.orig
+grep -vi LoginGraceTime $OBJ/sshd_config.orig > $OBJ/sshd_config
 echo "LoginGraceTime 10s" >> $OBJ/sshd_config
 echo "MaxStartups 1" >> $OBJ/sshd_config
 start_sshd
Index: regress/test-exec.sh
===================================================================
RCS file: /var/cvs/openssh/regress/test-exec.sh,v
retrieving revision 1.61
diff -u -p -r1.61 test-exec.sh
--- regress/test-exec.sh	9 Nov 2013 05:55:03 -0000	1.61
+++ regress/test-exec.sh	29 Jan 2014 23:55:26 -0000
@@ -328,6 +328,7 @@ cat << EOF > $OBJ/sshd_config
 	StrictModes		no
 	Port			$PORT
 	Protocol		2,1
+	LoginGraceTime		15m
 	AddressFamily		inet
 	ListenAddress		127.0.0.1
 	#ListenAddress		::1

From djm at cvs.openbsd.org  Thu Jan 30 17:34:18 2014
From: djm at cvs.openbsd.org (Damien Miller)
Date: Wed, 29 Jan 2014 23:34:18 -0700 (MST)
Subject: Announce: OpenSSH 6.5 released
Message-ID: <201401300634.s0U6YI9i011801@cvs.openbsd.org>

Changes since OpenSSH 6.4
=========================

This is a feature-focused release.

New features:

 * ssh(1), sshd(8): Add support for key exchange using elliptic-curve
   Diffie Hellman in Daniel Bernstein's Curve25519. This key exchange
   method is the default when both the client and server support it.

 * ssh(1), sshd(8): Add support for Ed25519 as a public key type.
   Ed25519 is a elliptic curve signature scheme that offers
   better security than ECDSA and DSA and good performance. It may be
   used for both user and host keys.

 * Add a new private key format that uses a bcrypt KDF to better
   protect keys at rest. This format is used unconditionally for
   Ed25519 keys, but may be requested when generating or saving
   existing keys of other types via the -o ssh-keygen(1) option.
   We intend to make the new format the default in the near future.
   Details of the new format are in the PROTOCOL.key file.

 * ssh(1), sshd(8): Add a new transport cipher
   "chacha20-poly1305 at openssh.com" that combines Daniel Bernstein's
   ChaCha20 stream cipher and Poly1305 MAC to build an authenticated
   encryption mode. Details are in the PROTOCOL.chacha20poly1305 file.

 * ssh(1), sshd(8): Refuse RSA keys from old proprietary clients and
   servers that use the obsolete RSA+MD5 signature scheme. It will
   still be possible to connect with these clients/servers but only
   DSA keys will be accepted, and OpenSSH will refuse connection
   entirely in a future release.

 * ssh(1), sshd(8): Refuse old proprietary clients and servers that
   use a weaker key exchange hash calculation.

 * ssh(1): Increase the size of the Diffie-Hellman groups requested
   for each symmetric key size. New values from NIST Special
   Publication 800-57 with the upper limit specified by RFC4419.

 * ssh(1), ssh-agent(1): Support pkcs#11 tokes that only provide
   X.509 certs instead of raw public keys (requested as bz#1908).

 * ssh(1): Add a ssh_config(5) "Match" keyword that allows
   conditional configuration to be applied by matching on hostname,
   user and result of arbitrary commands.

 * ssh(1): Add support for client-side hostname canonicalisation
   using a set of DNS suffixes and rules in ssh_config(5). This
   allows unqualified names to be canonicalised to fully-qualified
   domain names to eliminate ambiguity when looking up keys in
   known_hosts or checking host certificate names.

 * sftp-server(8): Add the ability to whitelist and/or blacklist sftp
   protocol requests by name.

 * sftp-server(8): Add a sftp "fsync at openssh.com" to support calling
   fsync(2) on an open file handle.

 * sshd(8): Add a ssh_config(5) PermitTTY to disallow TTY allocation,
   mirroring the longstanding no-pty authorized_keys option.

 * ssh(1): Add a ssh_config ProxyUseFDPass option that supports the
   use of ProxyCommands that establish a connection and then pass a
   connected file descriptor back to ssh(1). This allows the
   ProxyCommand to exit rather than staying around to transfer data.

Bugfixes:

 * ssh(1), sshd(8): Fix potential stack exhaustion caused by nested
   certificates.

 * ssh(1): bz#1211: make BindAddress work with UsePrivilegedPort.

 * sftp(1): bz#2137: fix the progress meter for resumed transfer.

 * ssh-add(1): bz#2187: do not request smartcard PIN when removing
   keys from ssh-agent.

 * sshd(8): bz#2139: fix re-exec fallback when original sshd binary
   cannot be executed.

 * ssh-keygen(1): Make relative-specified certificate expiry times
   relative to current time and not the validity start time.

 * sshd(8): bz#2161: fix AuthorizedKeysCommand inside a Match block.

 * sftp(1): bz#2129: symlinking a file would incorrectly canonicalise
   the target path.

 * ssh-agent(1): bz#2175: fix a use-after-free in the PKCS#11 agent
   helper executable.

 * sshd(8): Improve logging of sessions to include the user name,
   remote host and port, the session type (shell, command, etc.) and
   allocated TTY (if any).

 * sshd(8): bz#1297: tell the client (via a debug message) when
   their preferred listen address has been overridden by the
   server's GatewayPorts setting.

 * sshd(8): bz#2162: include report port in bad protocol banner
   message.

 * sftp(1): bz#2163: fix memory leak in error path in do_readdir().

 * sftp(1): bz#2171: don't leak file descriptor on error.

 * sshd(8): Include the local address and port in "Connection from
   ..." message (only shown at loglevel>=verbose).

Portable OpenSSH:

 * Please note that this is the last version of Portable OpenSSH that
   will support versions of OpenSSL prior to 0.9.6. Support (i.e.
   SSH_OLD_EVP) will be removed following the 6.5p1 release.

 * Portable OpenSSH will attempt compile and link as a Position
   Independent Executable on Linux, OS X and OpenBSD on recent gcc-
   like compilers. Other platforms and older/other compilers may
   request this using the --with-pie configure flag.

 * A number of other toolchain-related hardening options are used
   automatically if available, including -ftrapv to abort on signed
   integer overflow and options to write-protect dynamic linking
   information.  The use of these options may be disabled using the
   --without-hardening configure flag.

 * If the toolchain supports it, one of the -fstack-protector-strong,
   -fstack-protector-all or -fstack-protector compilation flag are
   used to add guards to mitigate attacks based on stack overflows.
   The use of these options may be disabled using the
   --without-stackprotect configure option.

 * sshd(8): Add support for pre-authentication sandboxing using the
   Capsicum API introduced in FreeBSD 10.

 * Switch to a ChaCha20-based arc4random() PRNG for platforms that do
   not provide their own.

 * sshd(8): bz#2156: restore Linux oom_adj setting when handling
   SIGHUP to maintain behaviour over retart.

 * sshd(8): bz#2032: use local username in krb5_kuserok check rather
   than full client name which may be of form user at REALM.

 * ssh(1), sshd(8): Test for both the presence of ECC NID numbers in
   OpenSSL and that they actually work. Fedora (at least) has
   NID_secp521r1 that doesn't work.

 * bz#2173: use pkg-config --libs to include correct -L location for
   libedit.

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

 - SHA1 (openssh-6.5.tar.gz) = 0a375e20d895670489a9241f8faa57670214fbed
 - SHA256 (openssh-6.5.tar.gz) = sK5q2rB0o5JCbEmbeE/6N9DtJkT81dwmeuhogT4i900=

 - SHA1 (openssh-6.5p1.tar.gz) = 3363a72b4fee91b29cf2024ff633c17f6cd2f86d
 - SHA256 (openssh-6.5p1.tar.gz) = oRle1V25RSUtWhcw1KKipcHJpqoB7y5a91CpYmI9kCc=

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

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

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

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


From tgc at jupiterrise.com  Thu Jan 30 21:12:07 2014
From: tgc at jupiterrise.com (Tom G. Christensen)
Date: Thu, 30 Jan 2014 11:12:07 +0100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.11.1401301054560.24928@natsu.mindrot.org>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52E507CC.7090107@jupiterrise.com>
 <alpine.BSO.2.11.1401271046480.9143@natsu.mindrot.org>
 <52E64194.7080505@jupiterrise.com>
 <alpine.BSO.2.11.1401272308490.24928@natsu.mindrot.org>
 <52E6B5BC.1060908@jupiterrise.com>
 <CALDDTe2JSBrRe8zYJ7xK8BO0th2526Kmws_-C_4fZjUNrS_4=A@mail.gmail.com>
 <52E78C59.90006@jupiterrise.com>
 <alpine.BSO.2.11.1401282212300.24928@natsu.mindrot.org>
 <52E7BEA7.2080202@jupiterrise.com>
 <alpine.BSO.2.11.1401301033140.24928@natsu.mindrot.org>
 <alpine.BSO.2.11.1401301054560.24928@natsu.mindrot.org>
Message-ID: <52EA2577.3000703@jupiterrise.com>

On 30/01/14 01:11, Damien Miller wrote:
> On Thu, 30 Jan 2014, Damien Miller wrote:
>
>> Fortunately, working around this in the test is easy:
>
> here's a better patch that doesn't break login-timeout
>
It works perfectly, thank you!

The rekey test now passes on both the IRIX 5.3 host and the 2x400Mhz 
UltraSPARCII using openssl built for sparcv7.

-tgc


From no_spam_98 at yahoo.com  Fri Jan 31 05:20:44 2014
From: no_spam_98 at yahoo.com (no_spam_98 at yahoo.com)
Date: Thu, 30 Jan 2014 10:20:44 -0800 (PST)
Subject: CVE-2014-1692
Message-ID: <1391106044.16117.YahooMailNeo@web140602.mail.bf1.yahoo.com>

http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-1692

The NIST advisory says that all versions of OpenSSH potentially contain the flaw. ?But is that really true? ?For example, I looked at the 3.8.1p1 distribution and didn't find any reference to JPAKE at all.

Thanks.


From mancha1 at hush.com  Fri Jan 31 05:43:10 2014
From: mancha1 at hush.com (mancha)
Date: Thu, 30 Jan 2014 18:43:10 +0000 (UTC)
Subject: CVE-2014-1692
References: <1391106044.16117.YahooMailNeo@web140602.mail.bf1.yahoo.com>
Message-ID: <loom.20140130T193352-406@post.gmane.org>

<no_spam_98 <at> yahoo.com> writes:
> 
> http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-1692
> 
> The NIST advisory says that all versions of OpenSSH potentially contain
> the flaw. ?But is that really true? ?For example, I looked at the
> 3.8.1p1 distribution and didn't find any reference to JPAKE at all.

Hi. The NVD advisory is inaccurate. JPAKE experimental code was
first introduced in OpenSSH 5.2, iirc.

Also, the advisory should be taken with a grain of salt as the
vulnerable code is not activated without pro-active user code
modification.

--mancha



From djm at mindrot.org  Fri Jan 31 07:31:52 2014
From: djm at mindrot.org (Damien Miller)
Date: Fri, 31 Jan 2014 07:31:52 +1100 (EST)
Subject: CVE-2014-1692
In-Reply-To: <loom.20140130T193352-406@post.gmane.org>
References: <1391106044.16117.YahooMailNeo@web140602.mail.bf1.yahoo.com>
 <loom.20140130T193352-406@post.gmane.org>
Message-ID: <alpine.BSO.2.11.1401310727590.24928@natsu.mindrot.org>

On Thu, 30 Jan 2014, mancha wrote:

> <no_spam_98 <at> yahoo.com> writes:
> > 
> > http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2014-1692
> > 
> > The NIST advisory says that all versions of OpenSSH potentially contain
> > the flaw.  But is that really true?  For example, I looked at the
> > 3.8.1p1 distribution and didn't find any reference to JPAKE at all.
> 
> Hi. The NVD advisory is inaccurate. JPAKE experimental code was
> first introduced in OpenSSH 5.2, iirc.
> 
> Also, the advisory should be taken with a grain of salt as the
> vulnerable code is not activated without pro-active user code
> modification.

oh man, that CVE is nuts.

"Exploitability Subscore: 10.0" - it's code that is experimental,
never enabled, never mentioned in release notes, has no configure
option. On top of that, the attacker has to make EVP_Digest* fail
(and I know of no way to do this remotely) as a result.

-d

From htodd at twofifty.com  Fri Jan 31 07:53:25 2014
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Thu, 30 Jan 2014 12:53:25 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.11.1401251703330.24928@natsu.mindrot.org>
References: <alpine.BSO.2.11.1401241102440.14832@natsu.mindrot.org>
 <alpine.NEB.2.11.1401231605330.330@chris.i8u.org>
 <20140124100745.GA18706@gate.dtucker.net>
 <alpine.NEB.2.11.1401240851470.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401250655510.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241617390.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251210530.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241725020.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251318460.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241955090.12225@chris.i8u.org>
 <20140125041457.GA525@gate.dtucker.net>
 <alpine.NEB.2.11.1401242048320.12225@chris.i8u.org>
 <CALDDTe3N7LfcTeko-nwO=XDTDHyRrCURccRa5MLcqCgZs8u7pA@mail.gmail.com>
 <alpine.NEB.2.11.1401242118240.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251703330.24928@natsu.mindrot.org>
Message-ID: <alpine.NEB.2.11.1401301251560.12225@chris.i8u.org>

On Sat, 25 Jan 2014, Damien Miller wrote:

> On Fri, 24 Jan 2014, Hisashi T Fujinaka wrote:
>
>> I'm confused. Should I start with a clean tree or a modified tree? And
>> which patches should I use? I have a lot in my email at this point.
>
> If I checkout the current git or CVS head and apply this then the scp
> test passes on NetBSD 6.1.3 where it was hanging previously:
>
> Index: atomicio.c
> ===================================================================
> RCS file: /var/cvs/openssh/atomicio.c,v
> retrieving revision 1.40
> diff -u -r1.40 atomicio.c
> --- atomicio.c	24 Sep 2010 12:15:11 -0000	1.40
> +++ atomicio.c	25 Jan 2014 06:03:19 -0000
> @@ -57,7 +57,7 @@
> 	struct pollfd pfd;
>
> 	pfd.fd = fd;
> -	pfd.events = f == read ? POLLIN : POLLOUT;
> +	pfd.events = f == vwrite ? POLLOUT : POLLIN;
> 	while (n > pos) {
> 		res = (f) (fd, s + pos, n - pos);
> 		switch (res) {

I still have to apply this (by hand) for make tests to work on NetBSD.
Is this function used in anything other than testing?

-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

From alex at alex.org.uk  Fri Jan 31 07:59:59 2014
From: alex at alex.org.uk (Alex Bligh)
Date: Thu, 30 Jan 2014 20:59:59 +0000
Subject: CVE-2014-1692
In-Reply-To: <alpine.BSO.2.11.1401310727590.24928@natsu.mindrot.org>
References: <1391106044.16117.YahooMailNeo@web140602.mail.bf1.yahoo.com>
 <loom.20140130T193352-406@post.gmane.org>
 <alpine.BSO.2.11.1401310727590.24928@natsu.mindrot.org>
Message-ID: <5D6B0C13-0ABC-4AC7-BD4E-5861DC185221@alex.org.uk>


On 30 Jan 2014, at 20:31, Damien Miller wrote:

> oh man, that CVE is nuts.

It starts "The hash_buffer function in schnorr.c in OpenSSH through 6.4,
when Makefile.inc is modified to enable the J-PAKE protocol ..."

If one is allowed to modify files in order to trigger security vulnerabilities,
I think I could find some rather more obvious modifications to do with
rather more serious impacts.

-- 
Alex Bligh





From djm at mindrot.org  Fri Jan 31 08:40:29 2014
From: djm at mindrot.org (Damien Miller)
Date: Fri, 31 Jan 2014 08:40:29 +1100 (EST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.NEB.2.11.1401301251560.12225@chris.i8u.org>
References: <alpine.BSO.2.11.1401241102440.14832@natsu.mindrot.org>
 <alpine.NEB.2.11.1401231605330.330@chris.i8u.org>
 <20140124100745.GA18706@gate.dtucker.net>
 <alpine.NEB.2.11.1401240851470.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401250655510.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241617390.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251210530.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241725020.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251318460.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241955090.12225@chris.i8u.org>
 <20140125041457.GA525@gate.dtucker.net>
 <alpine.NEB.2.11.1401242048320.12225@chris.i8u.org>
 <CALDDTe3N7LfcTeko-nwO=XDTDHyRrCURccRa5MLcqCgZs8u7pA@mail.gmail.com>
 <alpine.NEB.2.11.1401242118240.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251703330.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401301251560.12225@chris.i8u.org>
Message-ID: <alpine.BSO.2.11.1401310840000.24928@natsu.mindrot.org>

On Thu, 30 Jan 2014, Hisashi T Fujinaka wrote:

> I still have to apply this (by hand) for make tests to work on NetBSD.
> Is this function used in anything other than testing?

You shouldn't need to - I committed a slightly different fix for
the 6.5 release.

-d

From tibbs at math.uh.edu  Fri Jan 31 08:45:15 2014
From: tibbs at math.uh.edu (Jason L Tibbitts III)
Date: Thu, 30 Jan 2014 15:45:15 -0600
Subject: CVE-2014-1692
In-Reply-To: <5D6B0C13-0ABC-4AC7-BD4E-5861DC185221@alex.org.uk> (Alex Bligh's
 message of "Thu, 30 Jan 2014 20:59:59 +0000")
References: <1391106044.16117.YahooMailNeo@web140602.mail.bf1.yahoo.com>
 <loom.20140130T193352-406@post.gmane.org>
 <alpine.BSO.2.11.1401310727590.24928@natsu.mindrot.org>
 <5D6B0C13-0ABC-4AC7-BD4E-5861DC185221@alex.org.uk>
Message-ID: <ufabnytuot0.fsf@epithumia.math.uh.edu>

>>>>> "AB" == Alex Bligh <alex at alex.org.uk> writes:

AB> If one is allowed to modify files in order to trigger security
AB> vulnerabilities, I think I could find some rather more obvious
AB> modifications to do with rather more serious impacts.

The original filing is interesting; there was confusion about whether it
qualified for a CVE at all, and the rationale by the assignment team is
given in a reply.

http://openwall.com/lists/oss-security/2014/01/29/2

 - J<

From htodd at twofifty.com  Fri Jan 31 08:52:36 2014
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Thu, 30 Jan 2014 13:52:36 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.BSO.2.11.1401310840000.24928@natsu.mindrot.org>
References: <alpine.BSO.2.11.1401241102440.14832@natsu.mindrot.org>
 <alpine.NEB.2.11.1401231605330.330@chris.i8u.org>
 <20140124100745.GA18706@gate.dtucker.net>
 <alpine.NEB.2.11.1401240851470.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401250655510.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241617390.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251210530.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241725020.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251318460.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241955090.12225@chris.i8u.org>
 <20140125041457.GA525@gate.dtucker.net>
 <alpine.NEB.2.11.1401242048320.12225@chris.i8u.org>
 <CALDDTe3N7LfcTeko-nwO=XDTDHyRrCURccRa5MLcqCgZs8u7pA@mail.gmail.com>
 <alpine.NEB.2.11.1401242118240.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251703330.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401301251560.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401310840000.24928@natsu.mindrot.org>
Message-ID: <alpine.NEB.2.11.1401301341010.12225@chris.i8u.org>

On Fri, 31 Jan 2014, Damien Miller wrote:

> On Thu, 30 Jan 2014, Hisashi T Fujinaka wrote:
>
>> I still have to apply this (by hand) for make tests to work on NetBSD.
>> Is this function used in anything other than testing?
>
> You shouldn't need to - I committed a slightly different fix for
> the 6.5 release.

Ah. I now that I think about it, I think I checked out the latest git
version and remembered to do the autoreconf but not the configure.
Whoops.

-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte

From kevin.brott at gmail.com  Fri Jan 31 11:12:15 2014
From: kevin.brott at gmail.com (Kevin Brott)
Date: Thu, 30 Jan 2014 16:12:15 -0800
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <CAMv58rbbz9fGoOQvNBVHdWgrB5x7Pp9XV2ZALkk5E8b3RpRHpA@mail.gmail.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52DB1C61.9070701@gmail.com>
 <CAMv58rbbz9fGoOQvNBVHdWgrB5x7Pp9XV2ZALkk5E8b3RpRHpA@mail.gmail.com>
Message-ID: <CAMv58rZpHNVnaX3kbt1NHeYaFVuay_hJOV2E6Kz+J9ttEZyybQ@mail.gmail.com>

Crazy days ... so I finally got to the non-redhat builds and ran into two
issues.  One's an IBM stupidity - and the other is an issue in the openssh
code under the HP-UX Ansi C compiler on 11.23.

Using
ftp://ftp3.usa.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-6.5p1.tar.gz

OS              Build_Target                CC
OpenSSL      BUILD TEST
==============  =========================== ================
============ ===== =================
Debian 7.3      x86_64-linux-gnu            gcc Debian 4.7.2-5
1.0.1e       OK    all tests passed
AIX 5300-12-04  powerpc-ibm-aix5.3.0.0      gcc 4.2.0
0.9.8k       OK    all tests passed
AIX 5300-12-02  powerpc-ibm-aix5.3.0.0      xlc 08.00.0000.0016
0.9.8k       OK    all tests passed
AIX 6100-07-06  powerpc-ibm-aix6.1.0.0      gcc 4.2.0
0.9.8y       OK    all tests passed
AIX 6100-07-06  powerpc-ibm-aix6.1.0.0      xlc 11.01.0000.0016
0.9.8y       OK    all tests passed
AIX 7100-03-01  powerpc-ibm-aix7.1.0.0      gcc 4.2.0           1.0.1e
OK*1  all tests passed
AIX 7100-03-01  powerpc-ibm-aix7.1.0.0      xlc 12.01.0000.0006
1.0.1e       OK    all tests passed
HP-UX 11.23     ia64-hp-hpux11.23           gcc 4.3.1
0.9.8w       OK    all tests passed
HP-UX 11.23     ia64-hp-hpux11.23           C/aC++ C.11.23.12
0.9.8w       FOK*2 all tests passed
HP-UX 11.31     ia64-hp-hpux11.31           gcc 4.6.2
0.9.8t       OK    all tests passed
HP-UX 11.31     ia64-hp-hpux11.31           C/aC++ C.11.31.05
0.9.8t       OK    all tests passed

*1 IBM auto-generated prologs in /usr/include/openssl/ec*.h break compile,
commented out properly (/*/ vs #) and then everything is go.

*2 build fails here:
     cc -o ssh ssh.o readconf.o clientloop.o sshtty.o  sshconnect.o
sshconnect1.o sshconnect2.o mux.o  roaming_common.o roaming_client.o -L.
-Lopenbsd-compat/ -L/opt/iexpress/zlib/lib  -lssh -lopenbsd-compat
-lcrypto -lz -lnsl -lxnet  -lsec
     ld: Unsatisfied symbol "ntohs" in file readconf.o
     1 errors.
     *** Error exit code 1
Fixed - by manually adding this line to readconf.c after reading
http://bugs.php.net/32591
*** readconf.c.orig     Fri Jan 17 05:03:57 2014
--- readconf.c  Thu Jan 30 15:37:31 2014
***************
*** 22,23 ****
--- 22,24 ----
  #include <netinet/in.h>
+ #include <arpa/inet.h>
  #include <netinet/in_systm.h>

I'm no code-grinder - but I'm guessing there's a test failing (or succeding
incorrectly) somewhere.The readconf.c hack lets the build complete and all
tests pass afterwards.  The example patch in the php bug report points to a
better fix for readconf.c - if configure defined HAVE_ARPA_INET_H





On Tue, Jan 21, 2014 at 4:51 PM, Kevin Brott <kevin.brott at gmail.com> wrote:

> On-call this week so it's going slow - but felt I should report on the
> build failure I found:
>
> Using http://www.mindrot.org/openssh_snap/openssh-SNAP-20140122.tar.gz
>
> OS              Build_Target                CC
> OpenSSL      BUILD TEST
> ==============  =========================== ================
> ============ ===== =================
> RHEL 2.1        i686-pc-linux-gnu           gcc 2.96-129.7.2
> 0.9.6b-eng   OK    all tests passed
> RHEL 3 TU4      i686-pc-linux-gnu           gcc 3.2.3-47
> 0.9.7a       FAIL*2
> Fedora Core r2  i686-pc-linux-gnu           gcc 3.3.3-7
> 0.9.7a       OK*1  all tests passed
> RHEL 4.0 nu8    i686-pc-linux-gnu           gcc 3.4.6-11
> 0.9.7a       OK*1  all tests passed
> RHEL 4.0 nu8    x86_64-unknown-linux-gnu    gcc 3.4.6-11
> 0.9.7a       OK*1  all tests passed
>
> # RHL     Red Hat Linux
> # RHEL    Red Hat Enterprise Linux
>
> # *1 --without-zlib-version-check
> # *2 build failure:
>   gcc -g -O2 -Wall -Wpointer-arith -Wuninitialized -Wsign-compare
> -Wformat-security -fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv
> -fno-builtin-memset -std=gnu99 -fPIE  -I. -I.. -I. -I./..  -DHAVE_CONFIG_H
> -c setproctitle.c
>   setproctitle.c: In function `compat_init_setproctitle':
>   setproctitle.c:99: warning: implicit declaration of function `strlen'
>   setproctitle.c:107: `argv_start' undeclared (first use in this function)
>   setproctitle.c:107: (Each undeclared identifier is reported only once
>   setproctitle.c:107: for each function it appears in.)
>   setproctitle.c:108: `argv_env_len' undeclared (first use in this
> function)
>   setproctitle.c:115: warning: implicit declaration of function `strdup'
>   setproctitle.c:115: warning: assignment makes pointer from integer
> without a cast
>   make[1]: *** [setproctitle.o] Error 1
>   make[1]: Leaving directory `/usr/src/openssh/openbsd-compat'
>   make: *** [openbsd-compat/libopenbsd-compat.a] Error 2
>   ##
>   ## OPENSSH 6.4p1 builds/tests fine
>   ##
>
>
>
>
> On Sat, Jan 18, 2014 at 4:29 PM, Kevin Brott <kevin.brott at gmail.com>wrote:
>
>> On 2014-01-16 16:26, Damien Miller wrote:
>>
>>> Hi,
>>>
>>> OpenSSH 6.5 is almost ready for release, so we would appreciate testing
>>> on as many platforms and systems as possible. This release contains
>>> some substantial new features and a number of bugfixes.
>>>
>>> Snapshot releases for portable OpenSSH are available from
>>> http://www.mindrot.org/openssh_snap/
>>>
>>> The OpenBSD version is available in CVS HEAD:
>>> http://www.openbsd.org/anoncvs.html
>>>
>>> Portable OpenSSH is also available via anonymous CVS using the
>>> instructions at http://www.openssh.com/portable.html#cvs or
>>> via Mercurial at http://hg.mindrot.org/openssh
>>>
>>> Running the regression tests supplied with Portable OpenSSH does not
>>> require installation and is a simply:
>>>
>>> $ ./configure && make tests
>>>
>>>
>>>
>> Using openssh-SNAP-20140119.tar.gz:
>> Debian GNU/Linux 7.3 (wheezy) x86_64, gcc (Debian 4.7.2-5) , and OpenSSL
>> 1.0.1e 11 - all tests passed
>>
>> Full test suite (RHEL/AIX/HP-UX/maybe Solaris) will get cranked up in the
>> lab at work come Monday. :)
>>
>>
>>
>>
>>
>
>
> --
> # include <stddisclaimer.h>
> /* Kevin  Brott <Kevin.Brott at gmail.com> */
>
>


-- 
# include <stddisclaimer.h>
/* Kevin  Brott <Kevin.Brott at gmail.com> */

From djm at mindrot.org  Fri Jan 31 11:28:31 2014
From: djm at mindrot.org (Damien Miller)
Date: Fri, 31 Jan 2014 11:28:31 +1100 (EST)
Subject: Wanted: smartcard with ECDSA support
Message-ID: <alpine.BSO.2.11.1401311124290.10693@natsu.mindrot.org>

Hi,

I'm interested in extending OpenSSH's PKCS#11 code to support ECDSA
keys, but have so far been unable to find anyone who can sell me
a smartcard that supports it.

They certainly exist - AFAIK it's required by the US PIV standard,
but obtaining cards that support it in single digit quantities
seems all but impossible.

Can anybody on this list help? I'd want 2-6 cards/tokens that support
ECDSA in the NIST p256 curve and ideally RSA and DSA too.

Cheers,
Damien

From deengert at gmail.com  Fri Jan 31 13:37:20 2014
From: deengert at gmail.com (Douglas E Engert)
Date: Thu, 30 Jan 2014 20:37:20 -0600
Subject: Wanted: smartcard with ECDSA support
In-Reply-To: <alpine.BSO.2.11.1401311124290.10693@natsu.mindrot.org>
References: <alpine.BSO.2.11.1401311124290.10693@natsu.mindrot.org>
Message-ID: <52EB0C60.7030504@gmail.com>



On 1/30/2014 6:28 PM, Damien Miller wrote:
> Hi,
>
> I'm interested in extending OpenSSH's PKCS#11 code to support ECDSA
> keys, but have so far been unable to find anyone who can sell me
> a smartcard that supports it.
>
> They certainly exist - AFAIK it's required by the US PIV standard,
> but obtaining cards that support it in single digit quantities
> seems all but impossible.


Also ask on the OpenSC list: opensc-devel at lists.sourceforge.net


Oberthur has cards (including PIV but is reluctant to sell in small quantities.)

They do have the ID-ONE Evaluation kit with 5 PIV cards, a combo fingerprint
reader and smartcard reader. $1000 (We have one at work, but I cant find it
online.)

NIST has a test suite of 16 PIV cards some of which have EC keys,
but you can not update them.
http://csrc.nist.gov/groups/SNS/piv/testcards.html

(I have used all three of the above to develop the OpenSC PIV EC support.)

CardContact is working on the SmartCard-HSM that has EC.

Yubico has a PIV applet on their device. It is in beta but does not have ECC yet.

https://store.yubico.com/store/catalog/product_info.php?cPath=21&products_id=88

>
> Can anybody on this list help? I'd want 2-6 cards/tokens that support
> ECDSA in the NIST p256 curve and ideally RSA and DSA too.
>
> Cheers,
> Damien
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

-- 

  Douglas E. Engert  <DEEngert at gmail.com>


From dtucker at zip.com.au  Fri Jan 31 14:24:25 2014
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 31 Jan 2014 14:24:25 +1100
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <CAMv58rZpHNVnaX3kbt1NHeYaFVuay_hJOV2E6Kz+J9ttEZyybQ@mail.gmail.com>
References: <alpine.BSO.2.03.1401141556410.3003@mindrot.org>
 <52DB1C61.9070701@gmail.com>
 <CAMv58rbbz9fGoOQvNBVHdWgrB5x7Pp9XV2ZALkk5E8b3RpRHpA@mail.gmail.com>
 <CAMv58rZpHNVnaX3kbt1NHeYaFVuay_hJOV2E6Kz+J9ttEZyybQ@mail.gmail.com>
Message-ID: <CALDDTe1PVwnWJoF=-5myUOwtk+9Sr03y=32jD7OUWrdrLS3m+Q@mail.gmail.com>

On Fri, Jan 31, 2014 at 11:12 AM, Kevin Brott <kevin.brott at gmail.com> wrote:
> Crazy days ... so I finally got to the non-redhat builds and ran into two
> issues.  One's an IBM stupidity - and the other is an issue in the openssh
> code under the HP-UX Ansi C compiler on 11.23.

Doh.  It's a shame my old C class workstation bit the dust otherwise I
might have caught that before the release.

> *** readconf.c.orig     Fri Jan 17 05:03:57 2014
> --- readconf.c  Thu Jan 30 15:37:31 2014
> ***************
> *** 22,23 ****
> --- 22,24 ----
>   #include <netinet/in.h>
> + #include <arpa/inet.h>
>   #include <netinet/in_systm.h>
>
> I'm no code-grinder - but I'm guessing there's a test failing (or succeding
> incorrectly) somewhere.The readconf.c hack lets the build complete and all
> tests pass afterwards.  The example patch in the php bug report points to a
> better fix for readconf.c - if configure defined HAVE_ARPA_INET_H

We already unconditionally include arpa/inet.h in a few other files so
doing this should be safe.  Patch applied.

Thanks.

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

From htodd at twofifty.com  Fri Jan 31 16:49:12 2014
From: htodd at twofifty.com (Hisashi T Fujinaka)
Date: Thu, 30 Jan 2014 21:49:12 -0800 (PST)
Subject: Call for testing: OpenSSH-6.5
In-Reply-To: <alpine.NEB.2.11.1401301341010.12225@chris.i8u.org>
References: <alpine.BSO.2.11.1401241102440.14832@natsu.mindrot.org>
 <alpine.NEB.2.11.1401231605330.330@chris.i8u.org>
 <20140124100745.GA18706@gate.dtucker.net>
 <alpine.NEB.2.11.1401240851470.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401250655510.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241617390.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251210530.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241725020.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251318460.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401241955090.12225@chris.i8u.org>
 <20140125041457.GA525@gate.dtucker.net>
 <alpine.NEB.2.11.1401242048320.12225@chris.i8u.org>
 <CALDDTe3N7LfcTeko-nwO=XDTDHyRrCURccRa5MLcqCgZs8u7pA@mail.gmail.com>
 <alpine.NEB.2.11.1401242118240.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401251703330.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401301251560.12225@chris.i8u.org>
 <alpine.BSO.2.11.1401310840000.24928@natsu.mindrot.org>
 <alpine.NEB.2.11.1401301341010.12225@chris.i8u.org>
Message-ID: <alpine.NEB.2.11.1401302149000.12225@chris.i8u.org>

On Thu, 30 Jan 2014, Hisashi T Fujinaka wrote:

> On Fri, 31 Jan 2014, Damien Miller wrote:
>
>> On Thu, 30 Jan 2014, Hisashi T Fujinaka wrote:
>> 
>>> I still have to apply this (by hand) for make tests to work on NetBSD.
>>> Is this function used in anything other than testing?
>> 
>> You shouldn't need to - I committed a slightly different fix for
>> the 6.5 release.
>
> Ah. I now that I think about it, I think I checked out the latest git
> version and remembered to do the autoreconf but not the configure.
> Whoops.

Yep, it all works.

-- 
Hisashi T Fujinaka - htodd at twofifty.com
BSEE(6/86) + BSChem(3/95) + BAEnglish(8/95) + MSCS(8/03) + $2.50 = latte