From openssh at roumenpetrov.info  Mon Apr  1 02:03:00 2013
From: openssh at roumenpetrov.info (Roumen Petrov)
Date: Sun, 31 Mar 2013 18:03:00 +0300
Subject: [patch] Update bsd-cygwin_util files (was Re: Announce: OpenSSH
 6.2 released)
In-Reply-To: <20130327141418.GA5860@calimero.vinschen.de>
References: <201303220038.r2M0chNQ002722@cvs.openbsd.org>
 <20130326194816.GJ7127@calimero.vinschen.de>
 <515214C3.6090502@roumenpetrov.info>
 <20130326220210.GL7127@calimero.vinschen.de>
 <20130327141418.GA5860@calimero.vinschen.de>
Message-ID: <51585024.3000105@roumenpetrov.info>

Hi ,

Corinna Vinschen wrote:
> On Mar 26 23:02, Corinna Vinschen wrote:
>> On Mar 26 23:36, Roumen Petrov wrote:
>>> Corinna Vinschen wrote:
>>>> The reason is a clash of the UINT64 type.  It gets defined in umac.c as
>>>> well as in the Windows headers.  The Windows headers define it like
>>>> this:
>>>>
>>>>    typedef unsigned __int64 UINT64,*PUINT64;
>>> Question is if build is fine  for UINTnn where nn < 64 , why fail for 64 ?
>> u_int64_t is unsigned long, while unsigned __int64 is unsigned long long.
>>
>>> May be correct patch is to define u_int64_t to be same as as
>>> unsigned __int64 ?
>> The right thing is to fix the __int64 definition in _mingw.h.in for
>> LP64 targets.  I'll send a patch to the mingw64 ML tomorrow.
> On second thought (and after some sleep), this is probably not the right
> thing to do.  Changing the type for UINT64 in the Windows headers just
> because of a single instance of clashing definitions in a POSIX file is
> pretty intrusive.  The potential side effects of this change are simply
> not worth it.
>
> As a result I have now reworked the bsd-cygwin_util.* files in
> openbsd-compat.  The most important change is not to include the
> windows.h header at all.  The only two Windows definitions used are
> HANDLE and INVALID_HANDLE_VALUE.  I defined those in bsd-cygwin_util.h
> so there's no reason anymore to include windows headers.  This fixes
> the UINT64 issue as well, obviously.
>
> Additionally I made the handling of open vs. binary_open a bit more
> clear (I think) by introducing a NO_BINARY_OPEN definition.
>
> Is that ok to apply?

It seems to me do not use windows.h on cygwin is better solution (+1).


> Thanks,
> Corinna


Roumen


> Index: openbsd-compat/bsd-cygwin_util.c
> ===================================================================
> RCS file: /cvs/openssh/openbsd-compat/bsd-cygwin_util.c,v
> retrieving revision 1.24
> diff -u -p -r1.24 bsd-cygwin_util.c
> --- openbsd-compat/bsd-cygwin_util.c	13 Feb 2012 19:38:38 -0000	1.24
> +++ openbsd-compat/bsd-cygwin_util.c	27 Mar 2013 12:59:07 -0000
> @@ -1,5 +1,5 @@
>   /*
> - * Copyright (c) 2000, 2001, 2011 Corinna Vinschen <vinschen at redhat.com>
> + * Copyright (c) 2000, 2001, 2011, 2013 Corinna Vinschen <vinschen at redhat.com>
>    *
>    * Redistribution and use in source and binary forms, with or without
>    * modification, are permitted provided that the following conditions
> @@ -27,20 +27,15 @@
>    * binary mode on Windows systems.
>    */
>   
> +#define NO_BINARY_OPEN	/* Avoid redefining open to binary_open for this file */
>   #include "includes.h"
>   
>   #ifdef HAVE_CYGWIN
>   
> -#if defined(open) && open == binary_open
> -# undef open
> -#endif
> -
>   #include <sys/types.h>
> -
>   #include <fcntl.h>
> -#include <stdlib.h>
> +#include <string.h>
>   #include <unistd.h>
> -#include <windows.h>
>   
>   #include "xmalloc.h"
>   
> Index: openbsd-compat/bsd-cygwin_util.h
> ===================================================================
> RCS file: /cvs/openssh/openbsd-compat/bsd-cygwin_util.h,v
> retrieving revision 1.15
> diff -u -p -r1.15 bsd-cygwin_util.h
> --- openbsd-compat/bsd-cygwin_util.h	28 Aug 2012 09:57:19 -0000	1.15
> +++ openbsd-compat/bsd-cygwin_util.h	27 Mar 2013 12:59:07 -0000
> @@ -1,7 +1,7 @@
>   /* $Id: bsd-cygwin_util.h,v 1.15 2012/08/28 09:57:19 dtucker Exp $ */
>   
>   /*
> - * Copyright (c) 2000, 2001, 2011 Corinna Vinschen <vinschen at redhat.com>
> + * Copyright (c) 2000, 2001, 2011, 2013 Corinna Vinschen <vinschen at redhat.com>
>    *
>    * Redistribution and use in source and binary forms, with or without
>    * modification, are permitted provided that the following conditions
> @@ -36,24 +36,21 @@
>   
>   #undef ERROR
>   
> -#define WIN32_LEAN_AND_MEAN
> +/* Avoid including windows headers. */
> +typedef void *HANDLE;
> +#define INVALID_HANDLE_VALUE ((HANDLE) -1)
>   
> -#include <windows.h>
>   #include <sys/cygwin.h>
>   #include <io.h>
>   
> -/* Make sure _WIN32 isn't defined later in the code, otherwise headers from
> -   other packages might get the wrong idea about the target system. */
> -#ifdef _WIN32
> -#undef _WIN32
> -#endif
> -
>   int binary_open(const char *, int , ...);
>   int check_ntsec(const char *);
>   char **fetch_windows_environment(void);
>   void free_windows_environment(char **);
>   
> +#ifndef NO_BINARY_OPEN
>   #define open binary_open
> +#endif
>   
>   #endif /* HAVE_CYGWIN */
>   
>


From dtucker at zip.com.au  Mon Apr  1 12:41:59 2013
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 1 Apr 2013 12:41:59 +1100
Subject: [patch] Update bsd-cygwin_util files (was Re: Announce: OpenSSH
 6.2 released)
In-Reply-To: <20130327141418.GA5860@calimero.vinschen.de>
References: <201303220038.r2M0chNQ002722@cvs.openbsd.org>
 <20130326194816.GJ7127@calimero.vinschen.de>
 <515214C3.6090502@roumenpetrov.info>
 <20130326220210.GL7127@calimero.vinschen.de>
 <20130327141418.GA5860@calimero.vinschen.de>
Message-ID: <20130401014159.GA28498@gate.dtucker.net>

On Wed, Mar 27, 2013 at 03:14:18PM +0100, Corinna Vinschen wrote:
[...]
> On second thought (and after some sleep), this is probably not the right
> thing to do.  Changing the type for UINT64 in the Windows headers just
> because of a single instance of clashing definitions in a POSIX file is
> pretty intrusive.  The potential side effects of this change are simply
> not worth it.
> 
> As a result I have now reworked the bsd-cygwin_util.* files in
> openbsd-compat.  The most important change is not to include the
> windows.h header at all.  The only two Windows definitions used are
> HANDLE and INVALID_HANDLE_VALUE.  I defined those in bsd-cygwin_util.h
> so there's no reason anymore to include windows headers.  This fixes
> the UINT64 issue as well, obviously.
> 
> Additionally I made the handling of open vs. binary_open a bit more
> clear (I think) by introducing a NO_BINARY_OPEN definition.
> 
> Is that ok to apply?

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 des at des.no  Tue Apr  2 00:44:40 2013
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Mon, 01 Apr 2013 15:44:40 +0200
Subject: "no such identity"
Message-ID: <86hajqpdpz.fsf@ds4.des.no>

With an OpenSSH 6.2p1 client with stock ssh_config and one of the
following cases:

 - I don't have any client keys
 - I have one or more client keys, but not one of each type
 - I don't have an authorized_keys on the server
 - I have an authorized_keys on the server, but it does not list any of
   the keys I have
 - One of my client keys is listed, but I don't have an agent and
   decline to type the passphrase

I get one or more of the following messages, depending on whether I have
a client key of each type:

no such identity: /home/des/.ssh/id_rsa: No such file or directory
no such identity: /home/des/.ssh/id_dsa: No such file or directory
no such identity: /home/des/.ssh/id_ecdsa: No such file or directory

load_identity_file() in sshconnect2.c prints this message if its
userprovided argument is non-zero.  The value comes from a struct
identity which is populated in pubkey_prepare() in the same file;
userprovided is set to 1 if the keyfile name comes from the client
option structure.  However, in this case, options.identity_keys is the
hardcoded default; I wouldn't say that really qualifies as "user
provided".

The attached patch adds a flag to the option structure which is set to 1
if and only if the IdentityFile option was encountered either in the
configuration file or on the command line.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no

-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssh-user-provided-identity-file.diff
Type: text/x-patch
Size: 1522 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20130401/84eb47be/attachment-0001.bin>

From des at des.no  Tue Apr  2 00:56:53 2013
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Mon, 01 Apr 2013 15:56:53 +0200
Subject: Format warnings in krl.c
Message-ID: <86d2uepd5m.fsf@ds4.des.no>

Compiling krl.c with clang results in a slew of warnings like this one:

/usr/src/secure/lib/libssh/../../../crypto/openssh/krl.c:505:37: warning: 
      format specifies type 'unsigned long long' but the argument has type
      'u_int64_t' (aka 'unsigned long') [-Wformat]

This comes from incorrectly assuming that u_int64_t is defined as
unsigned long long, whereas on 64-bit FreeBSD platforms, it is defined
as unsigned long.  I don't know if gcc cares, but clang does.

The attached patch adds explicit casts to krl.c.  I would prefer using
%ju and uintmax_t, but I'm doubt that uintmax_t is available on all
platforms OpenSSH supports.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no

-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssh-krl-printf-format.diff
Type: text/x-patch
Size: 1660 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20130401/3554cd39/attachment.bin>

From amesh at juniper.net  Tue Apr  2 04:22:51 2013
From: amesh at juniper.net (Arthur Mesh)
Date: Mon, 1 Apr 2013 10:22:51 -0700
Subject: "no such identity"
In-Reply-To: <86hajqpdpz.fsf@ds4.des.no>
References: <86hajqpdpz.fsf@ds4.des.no>
Message-ID: <20130401172251.GB47549@juniper.net>

On Mon, Apr 01, 2013 at 03:44:40PM +0200, Dag-Erling Sm??rgrav wrote:
> With an OpenSSH 6.2p1 client with stock ssh_config and one of the
> following cases:

I believe this has already been fixed, see

http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/sshconnect2.c.diff?r1=1.191;r2=1.192

(Didn't make it to 6.2 though).


-- 
Arthur Mesh <amesh at juniper.net>
Juniper Networks
+1 408 936-4968

From dkg at fifthhorseman.net  Tue Apr  2 08:36:08 2013
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 01 Apr 2013 17:36:08 -0400
Subject: ssh-agent allowing access to other users?
Message-ID: <5159FDC8.1030407@fifthhorseman.net>

hi openssh folks--

thanks to openbsd-compat/getpeereuid.c, ssh-agent refuses to allow
connections from other users.  This is great in the general case, but in
some cases, i would like to use the agent to mask off access to the raw
public key material but make it available for use by other user accounts.

For an example use case, see what Tollef (cc'ed here) was trying to do
in [0].  running the agent as one user and permitting access from
another user via filesystem permissions currently fails due to the euid
check in ssh-agent.c.

Is it unreasonable to propose a slight weakening of this check when
deliberately configured?  If so, what interface would seem most
reasonable to permit?

Some example interface choices:

 A) ssh-agent could take a new -g option indicating the name of a unix
group; if a peer's euid is a member of that group (based on the same
logic used by sshd's AllowGroups option) then access would be granted.

 B) the SSH_ALLOWED_EUIDS environment variable for the ssh-agent process
could be read as a whitespace-separated list of acceptable numeric uids
to allow connections from?

 C) some other configuration interface/authorization interface?  I'm
open to suggestions...

I'd be happy to write up a patch for A or B if folks think either would
be reasonable.

Feedback?  Thoughts?

Regards,

	--dkg


[0]
http://err.no/personal/blog/tech/2013-03-22-09-45_sharing_an_ssh_key_securely.html

-------------- 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/20130401/74301c75/attachment.bin>

From keisial at gmail.com  Tue Apr  2 09:57:23 2013
From: keisial at gmail.com (=?windows-1252?Q?=C1ngel_Gonz=E1lez?=)
Date: Tue, 02 Apr 2013 00:57:23 +0200
Subject: ssh-agent allowing access to other users?
In-Reply-To: <5159FDC8.1030407@fifthhorseman.net>
References: <5159FDC8.1030407@fifthhorseman.net>
Message-ID: <515A10D3.5020100@gmail.com>

On 01/04/13 23:36, Daniel Kahn Gillmor wrote:
> hi openssh folks--
>
> thanks to openbsd-compat/getpeereuid.c, ssh-agent refuses to allow
> connections from other users.  This is great in the general case, but in
> some cases, i would like to use the agent to mask off access to the raw
> public key material but make it available for use by other user accounts.
>
> For an example use case, see what Tollef (cc'ed here) was trying to do
> in [0].  running the agent as one user and permitting access from
> another user via filesystem permissions currently fails due to the euid
> check in ssh-agent.c.
>
> Is it unreasonable to propose a slight weakening of this check when
> deliberately configured?  If so, what interface would seem most
> reasonable to permit?
Add a --allow-other-users or --give-keys-to-anyone parameter?
Given that there will be little use of such feature, it's hard to make
an interface
which serves everybody and someone disabling that check should know what
they are doing (and thus properly secure the fs permissions).

As for the problem of Tollef due to an evil ssh-agent (clever trick!), a
solution
would be to make /usr/bin/ssh-agent sgid to another group (eg.
?good-agent?), then check
in the sudo snippet (you better make a script...) that $SSH_AUTH_SOCK
belongs
to that group (and thus was created by the trusted code).

There are a few caveats for BSD:
* Some BSD flavours ignore socket permissions (but the containing folder
should still make the initial --allow-other-users socket safe).
* It may be possible to reattach to the socket under BSD using SO_REUSEADDR
in the second process (anyone wants to test with AF_UNIX?)

Under Linux (which is what Tollef seems to be using) it would apparently
work.
Anyone seeing a hole in that method?


From dkg at fifthhorseman.net  Tue Apr  2 10:20:14 2013
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 01 Apr 2013 19:20:14 -0400
Subject: ssh-agent allowing access to other users?
In-Reply-To: <515A10D3.5020100@gmail.com>
References: <5159FDC8.1030407@fifthhorseman.net> <515A10D3.5020100@gmail.com>
Message-ID: <515A162E.3000000@fifthhorseman.net>

On 04/01/2013 06:57 PM, ?ngel Gonz?lez wrote:
> Add a --allow-other-users or --give-keys-to-anyone parameter?

i was thinking that the semantics would be more like
"allow-certain-other-users-to-make-ssh-agent-requests".  since ssh-agent
doesn't give its keys to anyone under any circumstance, there would be
no give-keys-to-anyone, and any constraints the ssh-agent owner wanted
to impose would still be honored for requests coming from other users.

So, for example, i could run an ssh-agent in my main X11 session and ask
it to prompt me for every request.  Then i could allow a designated user
account access to that agent's socket, and i could selectively allow or
deny requests made by that user account.

The idea of live modifications of the access list suggests a third
implementation option:

 C) extend the ssh-agent protocol to include enabling access to other
users with a separate protocol command type.

I'm not sure i like it, but it's worth having on the table while
brainstorming, i guess.

> Given that there will be little use of such feature, it's hard to make
> an interface
> which serves everybody and someone disabling that check should know what
> they are doing (and thus properly secure the fs permissions).

Nothing about this proposal mentions adjusting the fs permissions.  The
current code is already more restrictive than the fs permissions.  If we
wanted to trust the user to know what to do with fs permissions, we
could just do that directly by dropping the getpeereuid check entirely.
 But i'm proposing to selectively loosen the getpeereuid check, not to
tweak the fs permissions at this point.

And yes, a sophisticated user can work around this (as i am currently,
for example, by using a socat invocation as the original ssh-agent user
to launder connections from another less-restrictive socket through to
the original ssh-agent socket).  But this is crufty and more dangerous
and more complex than just having the logic where it makes more sense:
in the agent itself.

> would be to make /usr/bin/ssh-agent sgid to another group (eg.
> ?good-agent?), then check
> in the sudo snippet (you better make a script...) that $SSH_AUTH_SOCK
> belongs
> to that group (and thus was created by the trusted code).

on the system i'm currently using (Debian GNU/Linux), /usr/bin/ssh-agent
is already setgid root, to avoid arbitrary memory access by
non-privileged users.  I think this isn't compatible with the change
you're suggesting.

Thanks for the thought and feedback!

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/20130401/4dee625d/attachment.bin>

From tfheen at err.no  Tue Apr  2 16:29:55 2013
From: tfheen at err.no (Tollef Fog Heen)
Date: Tue, 02 Apr 2013 07:29:55 +0200
Subject: ssh-agent allowing access to other users?
In-Reply-To: <515A10D3.5020100@gmail.com> (=?utf-8?Q?=22=C3=81ngel_Gonz?=
 =?utf-8?Q?=C3=A1lez=22's?= message of "Tue,
 02 Apr 2013 00:57:23 +0200")
References: <5159FDC8.1030407@fifthhorseman.net> <515A10D3.5020100@gmail.com>
Message-ID: <m2obdx7b58.fsf@rahvafeir.err.no>

]] ?ngel Gonz?lez 

Daniel, thanks a lot for following up on this, I've been pondering how
to do it over Easter, but not gotten around to actually writing any
mails.

> As for the problem of Tollef due to an evil ssh-agent (clever trick!),
> a solution would be to make /usr/bin/ssh-agent sgid to another group
> (eg. ?good-agent?), then check in the sudo snippet (you better make a
> script...) that $SSH_AUTH_SOCK belongs to that group (and thus was
> created by the trusted code).

I had an idea along those lines, yes, and it will mostly work, except:

ssh-agent is currently (in my setup) sgid ssh.  Almost as the first
thing in main, it does a setegid(getgid()); setgid(getgid()), so the
socket itself is gid tfheen, not gid ssh.  I am not entirely sure why it
drops those privileges (gid ssh is, as Daniel explains, merely used to
prevent ptracing the process, thereby preventing leaked keys caused by
an exploit of other processes belonging to the user), or if it could be
taught not to.

> Under Linux (which is what Tollef seems to be using) it would apparently
> work.
> Anyone seeing a hole in that method?

Correct, I'm on Linux (Debian to be precise).

Cheers,
-- 
Tollef Fog Heen
UNIX is user friendly, it's just picky about who its friends are

From des at des.no  Tue Apr  2 19:38:30 2013
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Tue, 02 Apr 2013 10:38:30 +0200
Subject: "no such identity"
In-Reply-To: <20130401172251.GB47549@juniper.net> (Arthur Mesh's message of
 "Mon, 1 Apr 2013 10:22:51 -0700")
References: <86hajqpdpz.fsf@ds4.des.no> <20130401172251.GB47549@juniper.net>
Message-ID: <867gkle395.fsf@ds4.des.no>

Arthur Mesh <amesh at juniper.net> writes:
> I believe this has already been fixed [...]

Thanks, I've merged this into FreeBSD.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no

From vinschen at redhat.com  Tue Apr  2 23:08:40 2013
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 2 Apr 2013 14:08:40 +0200
Subject: "no such identity"
In-Reply-To: <20130401172251.GB47549@juniper.net>
References: <86hajqpdpz.fsf@ds4.des.no>
 <20130401172251.GB47549@juniper.net>
Message-ID: <20130402120840.GA29590@calimero.vinschen.de>

On Apr  1 10:22, Arthur Mesh wrote:
> On Mon, Apr 01, 2013 at 03:44:40PM +0200, Dag-Erling Sm??rgrav wrote:
> > With an OpenSSH 6.2p1 client with stock ssh_config and one of the
> > following cases:
> 
> I believe this has already been fixed, see
> 
> http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/sshconnect2.c.diff?r1=1.191;r2=1.192
> 
> (Didn't make it to 6.2 though).

Is that really the right patch?  It doesn't seem to be in the portable
version, but the portable version is apparently affected as well by the
gratuitous "No such identity" message.
The aforementioned patch breaks the portable version since Options has
no member named identity_file_userprovided.

So, what's the real patch for this problem relative to 6.2p1?


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

From dtucker at zip.com.au  Wed Apr  3 00:15:00 2013
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 3 Apr 2013 00:15:00 +1100
Subject: "no such identity"
In-Reply-To: <20130402120840.GA29590@calimero.vinschen.de>
References: <86hajqpdpz.fsf@ds4.des.no> <20130401172251.GB47549@juniper.net>
 <20130402120840.GA29590@calimero.vinschen.de>
Message-ID: <20130402131500.GA29515@gate.dtucker.net>

On Tue, Apr 02, 2013 at 02:08:40PM +0200, Corinna Vinschen wrote:
> On Apr  1 10:22, Arthur Mesh wrote:
[...]
> > (Didn't make it to 6.2 though).
> 
> Is that really the right patch?  It doesn't seem to be in the portable
> version, but the portable version is apparently affected as well by the
> gratuitous "No such identity" message.
> The aforementioned patch breaks the portable version since Options has
> no member named identity_file_userprovided.
> 
> So, what's the real patch for this problem relative to 6.2p1?

That's it, but it also needs the following patch.  Sorry, I should have
pulled both in for 6.2p1.

---------------------
PatchSet 4190 
Date: 2013/02/18 10:16:57
Author: dtucker
Branch: HEAD
Tag: (none) 
Log:
Keep track of which IndentityFile options were manually supplied and which
were default options, and don't warn if the latter are missing.  ok markus@

Members: 
	readconf.c:1.194->1.195 
	readconf.h:1.91->1.92 
	ssh.c:1.370->1.371 
	sshconnect2.c:1.191->1.192 

Index: src/usr.bin/ssh/readconf.c
diff -u src/usr.bin/ssh/readconf.c:1.194 src/usr.bin/ssh/readconf.c:1.195
--- src/usr.bin/ssh/readconf.c:1.194	Fri Sep 23 07:45:05 2011
+++ src/usr.bin/ssh/readconf.c	Sun Feb 17 23:16:57 2013
@@ -1,4 +1,4 @@
-/* $OpenBSD: readconf.c,v 1.194 2011/09/23 07:45:05 markus Exp $ */
+/* $OpenBSD: readconf.c,v 1.195 2013/02/17 23:16:57 dtucker Exp $ */
 /*
  * Author: Tatu Ylonen <ylo at cs.hut.fi>
  * Copyright (c) 1995 Tatu Ylonen <ylo at cs.hut.fi>, Espoo, Finland
@@ -322,6 +322,26 @@
 	options->tun_open = SSH_TUNMODE_NO;
 }
 
+void
+add_identity_file(Options *options, const char *dir, const char *filename,
+    int userprovided)
+{
+	char *path;
+
+	if (options->num_identity_files >= SSH_MAX_IDENTITY_FILES)
+		fatal("Too many identity files specified (max %d)",
+		    SSH_MAX_IDENTITY_FILES);
+
+	if (dir == NULL) /* no dir, filename is absolute */
+		path = xstrdup(filename);
+	else
+		(void)xasprintf(&path, "%.100s%.100s", dir, filename);
+
+	options->identity_file_userprovided[options->num_identity_files] =
+	    userprovided;
+	options->identity_files[options->num_identity_files++] = path;
+}
+
 /*
  * Returns the number of the token pointed to by cp or oBadOption.
  */
@@ -582,9 +602,7 @@
 			if (*intptr >= SSH_MAX_IDENTITY_FILES)
 				fatal("%.200s line %d: Too many identity files specified (max %d).",
 				    filename, linenum, SSH_MAX_IDENTITY_FILES);
-			charptr = &options->identity_files[*intptr];
-			*charptr = xstrdup(arg);
-			*intptr = *intptr + 1;
+			add_identity_file(options, NULL, arg, 1);
 		}
 		break;
 
@@ -1276,30 +1294,16 @@
 		options->protocol = SSH_PROTO_2;
 	if (options->num_identity_files == 0) {
 		if (options->protocol & SSH_PROTO_1) {
-			len = 2 + strlen(_PATH_SSH_CLIENT_IDENTITY) + 1;
-			options->identity_files[options->num_identity_files] =
-			    xmalloc(len);
-			snprintf(options->identity_files[options->num_identity_files++],
-			    len, "~/%.100s", _PATH_SSH_CLIENT_IDENTITY);
+			add_identity_file(options, "~/",
+			    _PATH_SSH_CLIENT_IDENTITY, 0);
 		}
 		if (options->protocol & SSH_PROTO_2) {
-			len = 2 + strlen(_PATH_SSH_CLIENT_ID_RSA) + 1;
-			options->identity_files[options->num_identity_files] =
-			    xmalloc(len);
-			snprintf(options->identity_files[options->num_identity_files++],
-			    len, "~/%.100s", _PATH_SSH_CLIENT_ID_RSA);
-
-			len = 2 + strlen(_PATH_SSH_CLIENT_ID_DSA) + 1;
-			options->identity_files[options->num_identity_files] =
-			    xmalloc(len);
-			snprintf(options->identity_files[options->num_identity_files++],
-			    len, "~/%.100s", _PATH_SSH_CLIENT_ID_DSA);
-
-			len = 2 + strlen(_PATH_SSH_CLIENT_ID_ECDSA) + 1;
-			options->identity_files[options->num_identity_files] =
-			    xmalloc(len);
-			snprintf(options->identity_files[options->num_identity_files++],
-			    len, "~/%.100s", _PATH_SSH_CLIENT_ID_ECDSA);
+			add_identity_file(options, "~/",
+			    _PATH_SSH_CLIENT_ID_RSA, 0);
+			add_identity_file(options, "~/",
+			    _PATH_SSH_CLIENT_ID_DSA, 0);
+			add_identity_file(options, "~/",
+			    _PATH_SSH_CLIENT_ID_ECDSA, 0);
 		}
 	}
 	if (options->escape_char == -1)
Index: src/usr.bin/ssh/readconf.h
diff -u src/usr.bin/ssh/readconf.h:1.91 src/usr.bin/ssh/readconf.h:1.92
--- src/usr.bin/ssh/readconf.h:1.91	Fri Sep 23 07:45:05 2011
+++ src/usr.bin/ssh/readconf.h	Sun Feb 17 23:16:57 2013
@@ -1,4 +1,4 @@
-/* $OpenBSD: readconf.h,v 1.91 2011/09/23 07:45:05 markus Exp $ */
+/* $OpenBSD: readconf.h,v 1.92 2013/02/17 23:16:57 dtucker Exp $ */
 
 /*
  * Author: Tatu Ylonen <ylo at cs.hut.fi>
@@ -96,6 +96,7 @@
 
 	int     num_identity_files;	/* Number of files for RSA/DSA identities. */
 	char   *identity_files[SSH_MAX_IDENTITY_FILES];
+	int    identity_file_userprovided[SSH_MAX_IDENTITY_FILES];
 	Key    *identity_keys[SSH_MAX_IDENTITY_FILES];
 
 	/* Local TCP/IP forward requests. */
@@ -158,5 +159,6 @@
 
 void	 add_local_forward(Options *, const Forward *);
 void	 add_remote_forward(Options *, const Forward *);
+void	 add_identity_file(Options *, const char *, const char *, int);
 
 #endif				/* READCONF_H */
Index: src/usr.bin/ssh/ssh.c
diff -u src/usr.bin/ssh/ssh.c:1.370 src/usr.bin/ssh/ssh.c:1.371
--- src/usr.bin/ssh/ssh.c:1.370	Fri Jul  6 01:47:38 2012
+++ src/usr.bin/ssh/ssh.c	Sun Feb 17 23:16:57 2013
@@ -1,4 +1,4 @@
-/* $OpenBSD: ssh.c,v 1.370 2012/07/06 01:47:38 djm Exp $ */
+/* $OpenBSD: ssh.c,v 1.371 2013/02/17 23:16:57 dtucker Exp $ */
 /*
  * Author: Tatu Ylonen <ylo at cs.hut.fi>
  * Copyright (c) 1995 Tatu Ylonen <ylo at cs.hut.fi>, Espoo, Finland
@@ -376,12 +376,7 @@
 				    strerror(errno));
 				break;
 			}
-			if (options.num_identity_files >=
-			    SSH_MAX_IDENTITY_FILES)
-				fatal("Too many identity files specified "
-				    "(max %d)", SSH_MAX_IDENTITY_FILES);
-			options.identity_files[options.num_identity_files++] =
-			    xstrdup(optarg);
+			add_identity_file(&options, NULL, optarg, 1);
 			break;
 		case 'I':
 #ifdef ENABLE_PKCS11
Index: src/usr.bin/ssh/sshconnect2.c
diff -u src/usr.bin/ssh/sshconnect2.c:1.191 src/usr.bin/ssh/sshconnect2.c:1.192
--- src/usr.bin/ssh/sshconnect2.c:1.191	Fri Feb 15 00:21:01 2013
+++ src/usr.bin/ssh/sshconnect2.c	Sun Feb 17 23:16:57 2013
@@ -1,4 +1,4 @@
-/* $OpenBSD: sshconnect2.c,v 1.191 2013/02/15 00:21:01 dtucker Exp $ */
+/* $OpenBSD: sshconnect2.c,v 1.192 2013/02/17 23:16:57 dtucker Exp $ */
 /*
  * Copyright (c) 2000 Markus Friedl.  All rights reserved.
  * Copyright (c) 2008 Damien Miller.  All rights reserved.
@@ -1378,7 +1378,7 @@
 		id = xcalloc(1, sizeof(*id));
 		id->key = key;
 		id->filename = xstrdup(options.identity_files[i]);
-		id->userprovided = 1;
+		id->userprovided = options.identity_file_userprovided[i];
 		TAILQ_INSERT_TAIL(&files, id, next);
 	}
 	/* Prefer PKCS11 keys that are explicitly listed */

-- 
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  Wed Apr  3 00:26:55 2013
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 2 Apr 2013 15:26:55 +0200
Subject: "no such identity"
In-Reply-To: <20130402131500.GA29515@gate.dtucker.net>
References: <86hajqpdpz.fsf@ds4.des.no> <20130401172251.GB47549@juniper.net>
 <20130402120840.GA29590@calimero.vinschen.de>
 <20130402131500.GA29515@gate.dtucker.net>
Message-ID: <20130402132655.GA18060@calimero.vinschen.de>

On Apr  3 00:15, Darren Tucker wrote:
> On Tue, Apr 02, 2013 at 02:08:40PM +0200, Corinna Vinschen wrote:
> > On Apr  1 10:22, Arthur Mesh wrote:
> [...]
> > > (Didn't make it to 6.2 though).
> > 
> > Is that really the right patch?  It doesn't seem to be in the portable
> > version, but the portable version is apparently affected as well by the
> > gratuitous "No such identity" message.
> > The aforementioned patch breaks the portable version since Options has
> > no member named identity_file_userprovided.
> > 
> > So, what's the real patch for this problem relative to 6.2p1?
> 
> That's it, but it also needs the following patch.  Sorry, I should have
> pulled both in for 6.2p1.

Thank you.  Wouldn't it make sense to release a 6.2p2?


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

From des at des.no  Wed Apr  3 01:05:29 2013
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Tue, 02 Apr 2013 16:05:29 +0200
Subject: "no such identity"
In-Reply-To: <20130402132655.GA18060@calimero.vinschen.de> (Corinna Vinschen's
 message of "Tue, 2 Apr 2013 15:26:55 +0200")
References: <86hajqpdpz.fsf@ds4.des.no> <20130401172251.GB47549@juniper.net>
 <20130402120840.GA29590@calimero.vinschen.de>
 <20130402131500.GA29515@gate.dtucker.net>
 <20130402132655.GA18060@calimero.vinschen.de>
Message-ID: <86txnpc9jq.fsf@ds4.des.no>

Corinna Vinschen <vinschen at redhat.com> writes:
> Wouldn't it make sense to release a 6.2p2?

For a (mostly) cosmetic issue?

DES
-- 
Dag-Erling Sm?rgrav - des at des.no

From vinschen at redhat.com  Wed Apr  3 01:26:58 2013
From: vinschen at redhat.com (Corinna Vinschen)
Date: Tue, 2 Apr 2013 16:26:58 +0200
Subject: "no such identity"
In-Reply-To: <86txnpc9jq.fsf@ds4.des.no>
References: <86hajqpdpz.fsf@ds4.des.no> <20130401172251.GB47549@juniper.net>
 <20130402120840.GA29590@calimero.vinschen.de>
 <20130402131500.GA29515@gate.dtucker.net>
 <20130402132655.GA18060@calimero.vinschen.de>
 <86txnpc9jq.fsf@ds4.des.no>
Message-ID: <20130402142658.GC12647@calimero.vinschen.de>

On Apr  2 16:05, Dag-Erling Sm?rgrav wrote:
> Corinna Vinschen <vinschen at redhat.com> writes:
> > Wouldn't it make sense to release a 6.2p2?
> 
> For a (mostly) cosmetic issue?

...which is bound to create lots of puzzled user support requests.


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

From keisial at gmail.com  Wed Apr  3 05:23:17 2013
From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=)
Date: Tue, 02 Apr 2013 20:23:17 +0200
Subject: ssh-agent allowing access to other users?
In-Reply-To: <m2obdx7b58.fsf@rahvafeir.err.no>
References: <5159FDC8.1030407@fifthhorseman.net> <515A10D3.5020100@gmail.com>
 <m2obdx7b58.fsf@rahvafeir.err.no>
Message-ID: <515B2215.80605@gmail.com>

On 02/04/13 01:20, Daniel Kahn Gillmor wrote:
>> Given that there will be little use of such feature, it's hard to make
>> > an interface
>> > which serves everybody and someone disabling that check should know what
>> > they are doing (and thus properly secure the fs permissions).
> Nothing about this proposal mentions adjusting the fs permissions.  The
> current code is already more restrictive than the fs permissions.  If we
> wanted to trust the user to know what to do with fs permissions, we
> could just do that directly by dropping the getpeereuid check entirely.
>  But i'm proposing to selectively loosen the getpeereuid check, not to
> tweak the fs permissions at this point.
As such parameter would have been equivalent to removing the getpeereid
check, the access would have to be filtered by the permissions provided by
the filesystem.

I'm not a fan of adding dynamic permissions to ssh-agent either. I don't
think
it's worth the complexity added to the simple-to-understand ssh-agent tool.
However, getpeereid() returns the effective gid, so the privileged group
should
be the primary one (the non-standard getgrouplist could be used). Access
control
to the agent by secondary groups is still easier done by fs checks :/


While brainstormin about changing the protocol, I'd like a change where
the (claimed)
target was provided (in a stackable fashion) to the agent.


On 02/04/13 07:29, Tollef Fog Heen wrote:
> I had an idea along those lines, yes, and it will mostly work, except:
>
> ssh-agent is currently (in my setup) sgid ssh.  Almost as the first
> thing in main, it does a setegid(getgid()); setgid(getgid()), so the
> socket itself is gid tfheen, not gid ssh.  I am not entirely sure why it
> drops those privileges (gid ssh is, as Daniel explains, merely used to
> prevent ptracing the process, thereby preventing leaked keys caused by
> an exploit of other processes belonging to the user), or if it could be
> taught not to.
I had been looking at that piece of code (thinking about a possible race
condition before the prctl call, which the sgid avoids) and yet failed
to notice
that. :(
You could insert a library that replaces getgid() with getegid(), but it
seems
too hacky.


From dkg at fifthhorseman.net  Wed Apr  3 05:37:18 2013
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 02 Apr 2013 14:37:18 -0400
Subject: ssh-agent allowing access to other users?
In-Reply-To: <515B2215.80605@gmail.com>
References: <5159FDC8.1030407@fifthhorseman.net> <515A10D3.5020100@gmail.com>
 <m2obdx7b58.fsf@rahvafeir.err.no> <515B2215.80605@gmail.com>
Message-ID: <515B255E.8040805@fifthhorseman.net>

On 04/02/2013 02:23 PM, ?ngel Gonz?lez wrote:

> As such parameter would have been equivalent to removing the getpeereid
> check, the access would have to be filtered by the permissions provided by
> the filesystem.

i'm not convinced by the idea that they're equivalent, but this is a
reasonable fourth interaction proposal:

 D) ssh-agent takes a new initial argument (e.g. --no-peer-id-check).
if this argument is present, then the getpeereid() check is skipped.
Users of this flag are expected to ensure that filesystem permissions
are set up properly to limit access.

This is probably the simplest/cleanest of the existing proposals for
approaching this use case so far.

> While brainstormin about changing the protocol, I'd like a change where
> the (claimed) target was provided (in a stackable fashion) to the agent.

This probably deserves a separate thread.  I don't know what you mean by
"stackable fashion" -- but if you start a separate thread about this,
i'd be happy to read and comment on it.

	--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/20130402/6c7ce872/attachment.bin>

From keisial at gmail.com  Wed Apr  3 09:13:05 2013
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Wed, 03 Apr 2013 00:13:05 +0200
Subject: RFC: More explicit ssh agent forwarding on SSH_ASKPASS confirmation
Message-ID: <515B57F1.4020508@gmail.com>

This is an old idea I had, resurrected by the mention of changing the
agent protocol in "ssh-agent allowing access to other users?" thread.

Currently, when you forward the ssh-agent, the forwarded host has the
same rights as the local user. And when the key requires confirmation,
the is quite terse: "Allow use of key foobar?
Key fingerprint abcdf."

It would be desirable to have instead a text like:
Confirmation is required before allowing usage of key foobar
Key fingerprint abcdf.
to process 1234 (ssh example.com rsync --server --sender -logDtpre.iLsf)
allegedly
for "connecting to example.com (1.2.3.4)"


The rsync command line would be recovered by the agent itself, thus
being quite trustworthy.
In this case the example represented a local application.

If it was a forwarded request it could be:
Confirmation is required before allowing usage of key foobar
Key fingerprint abcdf.
to process 1234 (ssh -A example.com) allegedly
for process 235 (ssh example.net) allegedly
for connecting to example.net (1.2.3.4)

The fact that the whole chain is provided is what I refered as
"stackable" in the previous mail. Only the first process can be trusted,
but that already diminishes the potential to get the user to accept one
key for a different usage than intended.

Another big benefit of letting the agent know about the origin of the
key request is that keys could be constrained to be used locally (or to
require confirmation from a forwarded connection, but use automatically
by a local program). More complex setups could be achieved by modifying
the available keys forwarded depending on the host you connected to (eg.
for "work" vs "personal" keys) instead of using several agents.

Investigating the agent protocol for writing this, I discovered that I
wasn't the first with this idea, and draft-ietf-secsh-agent-02 [1]
already contemplated something similar with its
SSH_AGENT_FORWARDING_NOTICE message and
SSH_AGENT_CONSTRAINT_FORWARDING_STEPS &
SSH_AGENT_CONSTRAINT_FORWARDING_PATH constraints.
They can be a source for implementing the above. I don't know if the ssh
agent of ssh.com uses a variation of that (incomplete) specification.

Regards

1- http://tools.ietf.org/html/draft-ietf-secsh-agent-02#section-1.2


From luto at amacapital.net  Wed Apr  3 09:57:15 2013
From: luto at amacapital.net (Andy Lutomirski)
Date: Tue, 2 Apr 2013 15:57:15 -0700
Subject: Too many public keys
Message-ID: <CALCETrXyLYoBe=LN3nck1mX0D2kuWmWO7bF4SMptcGEhvb17Mg@mail.gmail.com>

Apparently my ssh agent is feeling energetic today:

debug1: Authentications that can continue: publickey,password
debug1: Next authentication method: publickey
debug1: Offering RSA public key: [...]
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: [...]
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: [...]
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: [...]
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: [...]
debug1: Authentications that can continue: publickey,password
debug1: Offering RSA public key: [... (this is the only remotely sensible try)]
Received disconnect from [a.b.c.d]: 2: Too many authentication
failures for [username]

The client is 6.1p1 and the server is 5.9p1.

The web is full of workarounds (IdentitiesOnly, SSH_AUTH_SOCK=, etc),
but I think this is silly.  This IMO shouldn't happen and, if it does,
the error message should give a better clue of what's wrong.

--Andy

From peter at stuge.se  Wed Apr  3 10:40:22 2013
From: peter at stuge.se (Peter Stuge)
Date: Wed, 3 Apr 2013 01:40:22 +0200
Subject: Too many public keys
In-Reply-To: <CALCETrXyLYoBe=LN3nck1mX0D2kuWmWO7bF4SMptcGEhvb17Mg@mail.gmail.com>
References: <CALCETrXyLYoBe=LN3nck1mX0D2kuWmWO7bF4SMptcGEhvb17Mg@mail.gmail.com>
Message-ID: <20130402234022.2292.qmail@stuge.se>

Andy Lutomirski wrote:
> Apparently my ssh agent is feeling energetic today:
..
> This IMO shouldn't happen

What should happen then?


//Peter

From amesh at juniper.net  Wed Apr  3 11:01:35 2013
From: amesh at juniper.net (Arthur Mesh)
Date: Tue, 2 Apr 2013 17:01:35 -0700
Subject: Too many public keys
In-Reply-To: <CALCETrXyLYoBe=LN3nck1mX0D2kuWmWO7bF4SMptcGEhvb17Mg@mail.gmail.com>
References: <CALCETrXyLYoBe=LN3nck1mX0D2kuWmWO7bF4SMptcGEhvb17Mg@mail.gmail.com>
Message-ID: <20130403000135.GQ47549@juniper.net>

On Tue, Apr 02, 2013 at 03:57:15PM -0700, Andy Lutomirski wrote:
> Received disconnect from [a.b.c.d]: 2: Too many authentication
> failures for [username]

Would it make sense to split max_authtries in to two separate counters:
 1) one that counts password/kbd_interactive auth attempts
 2) one that counts pubkey/certs auth attempts

One could argue password/kbd_interactive authentication attempts are
much more interesting. Having a low DEFAULT_AUTH_FAIL_MAX for these
would make sense.

Whereas, pubkey/cert auth attempts could have a higher threshold. This
would allow people who have boatload of different keys to avoid this
problem.

Thoughts?

From dkg at fifthhorseman.net  Wed Apr  3 11:20:41 2013
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 02 Apr 2013 20:20:41 -0400
Subject: RFC: More explicit ssh agent forwarding on SSH_ASKPASS
 confirmation
In-Reply-To: <515B57F1.4020508@gmail.com>
References: <515B57F1.4020508@gmail.com>
Message-ID: <515B75D9.4060005@fifthhorseman.net>

On 04/02/2013 06:13 PM, ?ngel Gonz?lez wrote:

> It would be desirable to have instead a text like:
> Confirmation is required before allowing usage of key foobar
> Key fingerprint abcdf.
> to process 1234 (ssh example.com rsync --server --sender -logDtpre.iLsf)

this material itself could be presented to the user even without changes
to the protocol.

> allegedly for "connecting to example.com (1.2.3.4)"

this line would need some protocol extension.  The SSH_FORWARDING_NOTICE
protocol detail you've referenced does *not* seem to cover this case,
but as you noted, you could use it for inspiration.

It seems like the first step would be to implement the prompting you
describe without the protocol changes and get people using it and giving
feedback on whether they find it useful.  This would probably be just a
patch to ssh-agent, no need to change ssh or ssh-askpass or anything
else.  I'd be happy to review and test such a patch, if you post it
someplace publicly.

I'm less convinced of the usefulness of the advisory strings, and they
have a higher bar to meet in the first place since they require changes
to the protocol to get them through to the agent.  is there a way to do
version or feature negotiation on the channel so that clients can fall
back to not providing advisory strings to an agent that might reject or
crash on them?

	--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/20130402/42699d23/attachment.bin>

From amk at krell.zikzak.de  Wed Apr  3 12:37:17 2013
From: amk at krell.zikzak.de (Andreas M. Kirchwitz)
Date: Wed, 3 Apr 2013 01:37:17 +0000 (UTC)
Subject: "no such identity"
References: <86hajqpdpz.fsf@ds4.des.no> <20130401172251.GB47549@juniper.net>
 <20130402120840.GA29590@calimero.vinschen.de>
 <20130402131500.GA29515@gate.dtucker.net>
 <20130402132655.GA18060@calimero.vinschen.de> <86txnpc9jq.fsf@ds4.des.no>
Message-ID: <slrnkln1ud.9k8.amk@msgid.krell.zikzak.de>

Dag-Erling Sm?rgrav <des at des.no> wrote:

 >> Wouldn't it make sense to release a 6.2p2?
 >
 > For a (mostly) cosmetic issue?
 
Technically, this issue maybe is cosmetic (however, the unexpected
warning could break scripts, but that's a different story). I spent
some time to understand what this message was all about because it
didn't make much sense to me at first. Maybe the server has been
hacked or something has been compromised? Who knows these days?

Then I found two workarounds, either create all possible keys even
if you don't need them at all, or specify IdentityFile in ~/.ssh/config
for those keys that actually exist. Well, that works for me, but that's
hard to explain to regular users on my machines. ;-)

Alternatively, patch the source code and remove the message.
But is it a good thing to remove warning messages from an
application that is about security?

Maybe some admins didn't even install OpenSSH 6.2p1 because they
were wondering if more things were broken than just that.

Well, maybe it could make sense to think about a 6.2p2 release.
On the other hand, if developers already know there will be 6.3
real soon anyway, then it's better to wait for that.

	Regards, Andreas

From carson at taltos.org  Wed Apr  3 20:17:09 2013
From: carson at taltos.org (Carson Gaspar)
Date: Wed, 03 Apr 2013 10:17:09 +0100
Subject: Too many public keys
In-Reply-To: <20130403000135.GQ47549@juniper.net>
References: <CALCETrXyLYoBe=LN3nck1mX0D2kuWmWO7bF4SMptcGEhvb17Mg@mail.gmail.com>
 <20130403000135.GQ47549@juniper.net>
Message-ID: <515BF395.3030304@taltos.org>

On 4/3/13 1:01 AM, Arthur Mesh wrote:
> On Tue, Apr 02, 2013 at 03:57:15PM -0700, Andy Lutomirski wrote:
>> Received disconnect from [a.b.c.d]: 2: Too many authentication
>> failures for [username]
>
> Would it make sense to split max_authtries in to two separate counters:
>   1) one that counts password/kbd_interactive auth attempts
>   2) one that counts pubkey/certs auth attempts
>
> One could argue password/kbd_interactive authentication attempts are
> much more interesting. Having a low DEFAULT_AUTH_FAIL_MAX for these
> would make sense.
>
> Whereas, pubkey/cert auth attempts could have a higher threshold. This
> would allow people who have boatload of different keys to avoid this
> problem.

I have also seen this where GSSAPI auth eats into the auth count and 
causes spurious failures. I concur that a different threshold for 
password-like auth mechanisms would be a useful feature.

-- 
Carson



From luto at amacapital.net  Thu Apr  4 04:22:41 2013
From: luto at amacapital.net (Andy Lutomirski)
Date: Wed, 3 Apr 2013 10:22:41 -0700
Subject: Too many public keys
In-Reply-To: <20130403000135.GQ47549@juniper.net>
References: <CALCETrXyLYoBe=LN3nck1mX0D2kuWmWO7bF4SMptcGEhvb17Mg@mail.gmail.com>
 <20130403000135.GQ47549@juniper.net>
Message-ID: <CALCETrX5=XJ7itLQmyAoUjCfNJdsugLb6jxsYECrKDyGy132UQ@mail.gmail.com>

On Tue, Apr 2, 2013 at 5:01 PM, Arthur Mesh <amesh at juniper.net> wrote:
> On Tue, Apr 02, 2013 at 03:57:15PM -0700, Andy Lutomirski wrote:
>> Received disconnect from [a.b.c.d]: 2: Too many authentication
>> failures for [username]
>
> Would it make sense to split max_authtries in to two separate counters:
>  1) one that counts password/kbd_interactive auth attempts
>  2) one that counts pubkey/certs auth attempts
>
> One could argue password/kbd_interactive authentication attempts are
> much more interesting. Having a low DEFAULT_AUTH_FAIL_MAX for these
> would make sense.
>
> Whereas, pubkey/cert auth attempts could have a higher threshold. This
> would allow people who have boatload of different keys to avoid this
> problem.

That would work for me.

I wonder if (with a protocol extension) something even better could be
done: take all locally available private keys, construct a small Bloom
filter and send it to the server, and have the server decide whether
any of the keys it accepts match.  (This would be efficient for shell
accounts but would be worse than useless for things like gitolite.)

--Andy

From keisial at gmail.com  Thu Apr  4 07:16:34 2013
From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=)
Date: Wed, 03 Apr 2013 22:16:34 +0200
Subject: RFC: More explicit ssh agent forwarding on SSH_ASKPASS
 confirmation
In-Reply-To: <515B75D9.4060005@fifthhorseman.net>
References: <515B57F1.4020508@gmail.com> <515B75D9.4060005@fifthhorseman.net>
Message-ID: <515C8E22.3080408@gmail.com>

On 03/04/13 02:20, Daniel Kahn Gillmor wrote:
> On 04/02/2013 06:13 PM, ?ngel Gonz?lez wrote:
>> It would be desirable to have instead a text like:
>> Confirmation is required before allowing usage of key foobar
>> Key fingerprint abcdf.
>> to process 1234 (ssh example.com rsync --server --sender -logDtpre.iLsf)
> this material itself could be presented to the user even without changes
> to the protocol.
Right. Although I'm afraid there would be little difference between a
direct
request and one proxied from another ssh instance (specially if it is
configured
with ForwardAgent yes).

>> allegedly for "connecting to example.com (1.2.3.4)"
> this line would need some protocol extension.  The SSH_FORWARDING_NOTICE
> protocol detail you've referenced does *not* seem to cover this case,
> but as you noted, you could use it for inspiration.
The provided SSH_AGENT_FORWARDING_NOTICE only covers to whom it
would be sent, the reason would be a nice addition (perhaps as a different
message).

> It seems like the first step would be to implement the prompting you
> describe without the protocol changes and get people using it and giving
> feedback on whether they find it useful.  This would probably be just a
> patch to ssh-agent, no need to change ssh or ssh-askpass or anything
> else.  I'd be happy to review and test such a patch, if you post it
> someplace publicly.
I think the big benefit would be to separate forwarded requests from
local ones,
but I could begin with this.

> I'm less convinced of the usefulness of the advisory strings, and they
> have a higher bar to meet in the first place since they require changes
> to the protocol to get them through to the agent.  is there a way to do
> version or feature negotiation on the channel so that clients can fall
> back to not providing advisory strings to an agent that might reject or
> crash on them?
If the agent doesn't support the message, it should reply with
SSH_AGENT_FAILURE.
The client could then skip that message in later events. An agent that
crashed seems extremely broken.

Thanks for your feedback


From bostjan at a2o.si  Fri Apr  5 02:52:12 2013
From: bostjan at a2o.si (Bostjan Skufca)
Date: Thu, 4 Apr 2013 17:52:12 +0200
Subject: AuthorizedKeysCommand question
Message-ID: <CAEp_DRCNB5atC=y3Oh8uPuzG6EGGHEAhNgegJ4QCYfZNbY32ZQ@mail.gmail.com>

Hi,

is there a particular reason why this feature is "user" based and not
"user-pubkey" based?

What I mean is that it works for installation with small number of pubkeys
per user.
But imagine i.e. a GitHub scale - all users logging in as user "git". On
each auth request all the keys from database would be fetched and feeded to
OpenSSH.

Now I am only asking this out of curiosity - was it easier to implement it
the way it currently is?

Currently it executes one external command per auth request.
If we would like a larger scale support, we would need to make it
configurable to support one external command execution per presented pubkey
(user may present multiple pubkeys, of course). Something like:
AuthorizedKeysCommand "/path/to/auth %u %p"
# %p is made up, but it stands for pubkey fingerprint

b.

From dkg at fifthhorseman.net  Fri Apr  5 04:17:32 2013
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Thu, 04 Apr 2013 13:17:32 -0400
Subject: AuthorizedKeysCommand question
In-Reply-To: <CAEp_DRCNB5atC=y3Oh8uPuzG6EGGHEAhNgegJ4QCYfZNbY32ZQ@mail.gmail.com>
References: <CAEp_DRCNB5atC=y3Oh8uPuzG6EGGHEAhNgegJ4QCYfZNbY32ZQ@mail.gmail.com>
Message-ID: <515DB5AC.5000702@fifthhorseman.net>

On 04/04/2013 11:52 AM, Bostjan Skufca wrote:

> is there a particular reason why this feature is "user" based and not
> "user-pubkey" based?

i think this question has been discussed on this list before.  you might
get better details from searching the archive.


> Now I am only asking this out of curiosity - was it easier to implement it
> the way it currently is?

the  implementation was definitely simpler this way because it can reuse
all the existing code that parses authorized_keys files, substituting a
pipe from a process instead of a text file as input.

> Currently it executes one external command per auth request.
> If we would like a larger scale support, we would need to make it
> configurable to support one external command execution per presented pubkey
> (user may present multiple pubkeys, of course). Something like:
> AuthorizedKeysCommand "/path/to/auth %u %p"
> # %p is made up, but it stands for pubkey fingerprint

I can see the appeal of having this sort of functionality, but i do not
think openssh should be in the business of string mangling in this part
of the configuration.

If you're going to match user-pubkey, i would recommend that the
convention is that the user account is the first argument, and the
pubkey is provided to the authcommand on stdin in some canonicalized form.

We'd want to be backward-compatible with the existing implementation as
well, so it'd be worth thinking about how to clarify which model sshd
should use.  One approach would be a configuration variable like
AuthorizedKeysCommandMethod, which can take two options: listkeys
(current implmentation, default) or testkey (your proposal).

iirc, there are some significant changes to flow of control and
authorization logic needed to implement the testkey method.  I'd be
happy to review patches that offer this functionality and give feedback
on them.

	--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/20130404/7d691193/attachment.bin>

From djm at mindrot.org  Fri Apr  5 10:43:03 2013
From: djm at mindrot.org (Damien Miller)
Date: Fri, 5 Apr 2013 10:43:03 +1100 (EST)
Subject: AuthorizedKeysCommand question
In-Reply-To: <CAEp_DRCNB5atC=y3Oh8uPuzG6EGGHEAhNgegJ4QCYfZNbY32ZQ@mail.gmail.com>
References: <CAEp_DRCNB5atC=y3Oh8uPuzG6EGGHEAhNgegJ4QCYfZNbY32ZQ@mail.gmail.com>
Message-ID: <alpine.BSO.2.00.1304051041310.26167@natsu.mindrot.org>

On Thu, 4 Apr 2013, Bostjan Skufca wrote:

> Hi,
> 
> is there a particular reason why this feature is "user" based and not
> "user-pubkey" based?
> 
> What I mean is that it works for installation with small number of pubkeys
> per user.
> But imagine i.e. a GitHub scale - all users logging in as user "git". On
> each auth request all the keys from database would be fetched and feeded to
> OpenSSH.

There's a bug for this:

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

We're considering exposing the public key to the command, perhaps in an
environment variable.

-d

From dtucker at zip.com.au  Fri Apr  5 10:49:52 2013
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 5 Apr 2013 10:49:52 +1100
Subject: "no such identity"
In-Reply-To: <20130402132655.GA18060@calimero.vinschen.de>
References: <86hajqpdpz.fsf@ds4.des.no> <20130401172251.GB47549@juniper.net>
 <20130402120840.GA29590@calimero.vinschen.de>
 <20130402131500.GA29515@gate.dtucker.net>
 <20130402132655.GA18060@calimero.vinschen.de>
Message-ID: <20130404234952.GA28615@gate.dtucker.net>

On Tue, Apr 02, 2013 at 03:26:55PM +0200, Corinna Vinschen wrote:
> On Apr  3 00:15, Darren Tucker wrote:
[...]
> > That's it, but it also needs the following patch.  Sorry, I should have
> > pulled both in for 6.2p1.
> 
> Thank you.  Wouldn't it make sense to release a 6.2p2?

Just discussed it with Damien and yeah that's going to be pretty
annoying, so we'll do a 6.2p2 in probably a couple of weeks to pick up
this and anything else that crop up between now and then.  I'll put the
64bit cygwin change (the windows.h thing) into that branch too.

-- 
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 mrmschf at gmail.com  Fri Apr  5 09:14:24 2013
From: mrmschf at gmail.com (Jeremy Brown)
Date: Thu, 4 Apr 2013 18:14:24 -0400
Subject: OpenSSH 6.2 Not Allowing Pubkey Auth
Message-ID: <CA+1CkNfse4weV0NgoY_mdt3mG7KX64TcJRrquZQFQVefdmv_vQ@mail.gmail.com>

I'm running a Debian VPS that was originally configured with OpenSSH
5.5 and I could use pubkey auth without issue. A few days ago, I
decided to compile and install OpenSSH 6.2 for the AES-GCM support,
and now I cannot login to my server with pubkey auth. I can't seem to
figure out what the problem is, and when I replace the new sshd with
the one originally included with my server, it resumes functioning
without issue. For the record I'm using GCC 4.8 and OpenSSL 1.0.1e.

-Jeremy

From dtucker at zip.com.au  Fri Apr  5 11:36:53 2013
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 5 Apr 2013 11:36:53 +1100
Subject: "no such identity"
In-Reply-To: <20130404234952.GA28615@gate.dtucker.net>
References: <86hajqpdpz.fsf@ds4.des.no> <20130401172251.GB47549@juniper.net>
 <20130402120840.GA29590@calimero.vinschen.de>
 <20130402131500.GA29515@gate.dtucker.net>
 <20130402132655.GA18060@calimero.vinschen.de>
 <20130404234952.GA28615@gate.dtucker.net>
Message-ID: <20130405003653.GA2583@gate.dtucker.net>

On Fri, Apr 05, 2013 at 10:49:52AM +1100, Darren Tucker wrote:
> On Tue, Apr 02, 2013 at 03:26:55PM +0200, Corinna Vinschen wrote:
> > On Apr  3 00:15, Darren Tucker wrote:
> [...]
> > > That's it, but it also needs the following patch.  Sorry, I should have
> > > pulled both in for 6.2p1.
> > 
> > Thank you.  Wouldn't it make sense to release a 6.2p2?
> 
> Just discussed it with Damien and yeah that's going to be pretty
> annoying, so we'll do a 6.2p2 in probably a couple of weeks to pick up
> this and anything else that crop up between now and then.  I'll put the
> 64bit cygwin change (the windows.h thing) into that branch too.

OK, I've pulled in all of the changes that were in what was tagged for
OpenBSD 5.3 into both HEAD and the 6.2 branch.  Here are the changes
that have been made since then and whether or not I think we should put
them into the branch (I'm open to discussion):

   - markus at cvs.openbsd.org 2013/03/05 20:16:09
     [sshconnect2.c]
     reset pubkey order on partial success; ok djm@

no (externally visible behaviour change)

   - djm at cvs.openbsd.org 2013/03/06 23:35:23
     [session.c]
     fatal() when ChrootDirectory specified by running without root privileges;
     ok markus@

yes (bugfix)

   - djm at cvs.openbsd.org 2013/03/06 23:36:53
     [readconf.c]
     g/c unused variable (-Wunused)

no.

   - djm at cvs.openbsd.org 2013/03/07 00:19:59
     [monitor.c auth2-pubkey.c]
     reconstruct the original username that was sent by the client, which may
     have included a style (e.g. "root:skey") when checking public key
     signatures. Fixes public key and hostbased auth when the client specified
     a style; ok markus@

yes (bugfix)

   - markus at cvs.openbsd.org 2013/03/07 19:27:25
     [sshd_config.5 auth.h monitor.c auth2-chall.c auth2.c]
     add submethod support to AuthenticationMethods; ok and freedback djm@

no (feature change)

   - djm at cvs.openbsd.org 2013/03/08 06:32:58
     [ssh.c]
     allow "ssh -f none ..." ok markus@

no (feature change)

-- 
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 Apr  5 14:06:22 2013
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 5 Apr 2013 14:06:22 +1100
Subject: "no such identity"
In-Reply-To: <20130402120840.GA29590@calimero.vinschen.de>
References: <86hajqpdpz.fsf@ds4.des.no> <20130401172251.GB47549@juniper.net>
 <20130402120840.GA29590@calimero.vinschen.de>
Message-ID: <20130405030622.GA16164@gate.dtucker.net>

On Tue, Apr 02, 2013 at 02:08:40PM +0200, Corinna Vinschen wrote:
> So, what's the real patch for this problem relative to 6.2p1?

For the benefit of anyone else finding this thread: there's a complete
(I hope :-) patch against 6.2p1 here:
https://bugzilla.mindrot.org/show_bug.cgi?id=2084

-- 
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 Apr  5 14:14:29 2013
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 5 Apr 2013 14:14:29 +1100
Subject: OpenSSH 6.2 Not Allowing Pubkey Auth
In-Reply-To: <CA+1CkNfse4weV0NgoY_mdt3mG7KX64TcJRrquZQFQVefdmv_vQ@mail.gmail.com>
References: <CA+1CkNfse4weV0NgoY_mdt3mG7KX64TcJRrquZQFQVefdmv_vQ@mail.gmail.com>
Message-ID: <20130405031429.GA16285@gate.dtucker.net>

On Thu, Apr 04, 2013 at 06:14:24PM -0400, Jeremy Brown wrote:
> I'm running a Debian VPS that was originally configured with OpenSSH
> 5.5 and I could use pubkey auth without issue. A few days ago, I
> decided to compile and install OpenSSH 6.2 for the AES-GCM support,
> and now I cannot login to my server with pubkey auth. I can't seem to
> figure out what the problem is, and when I replace the new sshd with
> the one originally included with my server, it resumes functioning
> without issue. For the record I'm using GCC 4.8 and OpenSSL 1.0.1e.

I would guess the stock sshd's config does not have StrictModes but the
new one does.  Check that $HOME, $HOME/.ssh and
$HOME/.ssh/authorized_keys are not group or world writable.

If that's not it:
 - run the client in debug mode ("ssh -v").  Modern versions of sshd will
   send a debug message after you log in if it refused to use a key for
   some reason (but only after you successfully authenticate somehow, eg
   password).
 - run the server in debug mode.  Assuming you can connect to some other
   port, that's something like /path/to/sshd -ddd -p 2022.  You should
   be able to see why the key was refused in the log, otherwise post it
   here for us to look at.

-- 
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  Fri Apr  5 18:55:59 2013
From: vinschen at redhat.com (Corinna Vinschen)
Date: Fri, 5 Apr 2013 09:55:59 +0200
Subject: "no such identity"
In-Reply-To: <20130405003653.GA2583@gate.dtucker.net>
References: <86hajqpdpz.fsf@ds4.des.no> <20130401172251.GB47549@juniper.net>
 <20130402120840.GA29590@calimero.vinschen.de>
 <20130402131500.GA29515@gate.dtucker.net>
 <20130402132655.GA18060@calimero.vinschen.de>
 <20130404234952.GA28615@gate.dtucker.net>
 <20130405003653.GA2583@gate.dtucker.net>
Message-ID: <20130405075559.GA30526@calimero.vinschen.de>

Hi Darren,

On Apr  5 11:36, Darren Tucker wrote:
> On Fri, Apr 05, 2013 at 10:49:52AM +1100, Darren Tucker wrote:
> > On Tue, Apr 02, 2013 at 03:26:55PM +0200, Corinna Vinschen wrote:
> > > On Apr  3 00:15, Darren Tucker wrote:
> > [...]
> > > > That's it, but it also needs the following patch.  Sorry, I should have
> > > > pulled both in for 6.2p1.
> > > 
> > > Thank you.  Wouldn't it make sense to release a 6.2p2?
> > 
> > Just discussed it with Damien and yeah that's going to be pretty
> > annoying, so we'll do a 6.2p2 in probably a couple of weeks to pick up
> > this and anything else that crop up between now and then.  I'll put the
> > 64bit cygwin change (the windows.h thing) into that branch too.

Thank you!

> OK, I've pulled in all of the changes that were in what was tagged for
> OpenBSD 5.3 into both HEAD and the 6.2 branch.  Here are the changes
> that have been made since then and whether or not I think we should put
> them into the branch (I'm open to discussion):

as another potential issue, we got a report on the Cygwin list
complaining about excessive syslog error messages:

 http://cygwin.com/ml/cygwin/2013-04/msg00019.html

It seems weird to log a disconnect as error.  Is that really the
right thing to do?


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

From aris at 0xbadc0de.be  Fri Apr  5 19:56:20 2013
From: aris at 0xbadc0de.be (Aris Adamantiadis)
Date: Fri, 05 Apr 2013 10:56:20 +0200
Subject: Too many public keys
In-Reply-To: <CALCETrX5=XJ7itLQmyAoUjCfNJdsugLb6jxsYECrKDyGy132UQ@mail.gmail.com>
References: <CALCETrXyLYoBe=LN3nck1mX0D2kuWmWO7bF4SMptcGEhvb17Mg@mail.gmail.com>
 <20130403000135.GQ47549@juniper.net>
 <CALCETrX5=XJ7itLQmyAoUjCfNJdsugLb6jxsYECrKDyGy132UQ@mail.gmail.com>
Message-ID: <515E91B4.5000306@0xbadc0de.be>

If you have too many public keys, you can use a config file to
specifically set an identity file to use with an host. I don't see what
problems you try to resolve, when in the opposite this limitation of
public key numbers tries per connection has actually been useful during
the Debian Openssl fiasco.
While I agree that there's no point counting failed gssapi attempts as
these cannot really be bruteforced.

Aris

Le 3/04/13 19:22, Andy Lutomirski a ?crit :

> I wonder if (with a protocol extension) something even better could be
> done: take all locally available private keys, construct a small Bloom
> filter and send it to the server, and have the server decide whether
> any of the keys it accepts match.  (This would be efficient for shell
> accounts but would be worse than useless for things like gitolite.)
> 
> --Andy

From panurag at in.ibm.com  Fri Apr  5 21:09:11 2013
From: panurag at in.ibm.com (Anurag Panda)
Date: Fri, 5 Apr 2013 15:39:11 +0530
Subject: Using hmac-sha2-256 in OpenSSH 6.2p1
Message-ID: <OF080538EC.BE6353F4-ON65257B44.00378696-65257B44.0037CC6E@in.ibm.com>


Hi,

I could not use hmac-sha2-256 in OpenSSH 6.2p1. I tried configuring in
sshd_config file also, but the server was not starting. How can I use
hmac-sha2-256 & hmac-sha2-512 in OpenSSH server in accordance with RFC
6668?

I have installed OpenSSH in a computer with the following configuration:
Architecture: x86 32-bit
OS: RHEL AS 4 (Nahant update 4) (Linux version 2.6.9-42.EL)

Thanks and regards,
Anurag,
Advisory Software Engineer,
B2B & Commerce, Industry Solutions, ISL, IBM,
#4/1, 2nd floor, Tower D, IBC Knowledge Park, Bannerghatta road, Bangalore,
India - 560029.
Phone (O): +91-80-49126451, ext: 26451, Tie-line: 26451.


From dtucker at zip.com.au  Fri Apr  5 22:05:23 2013
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 5 Apr 2013 22:05:23 +1100
Subject: Using hmac-sha2-256 in OpenSSH 6.2p1
In-Reply-To: <OF080538EC.BE6353F4-ON65257B44.00378696-65257B44.0037CC6E@in.ibm.com>
References: <OF080538EC.BE6353F4-ON65257B44.00378696-65257B44.0037CC6E@in.ibm.com>
Message-ID: <20130405110523.GA17808@gate.dtucker.net>

On Fri, Apr 05, 2013 at 03:39:11PM +0530, Anurag Panda wrote:
> I could not use hmac-sha2-256 in OpenSSH 6.2p1. I tried configuring in
> sshd_config file also, but the server was not starting. How can I use
> hmac-sha2-256 & hmac-sha2-512 in OpenSSH server in accordance with RFC
> 6668?
> 
> I have installed OpenSSH in a computer with the following configuration:
> Architecture: x86 32-bit
> OS: RHEL AS 4 (Nahant update 4) (Linux version 2.6.9-42.EL)

That will only be available if the OpenSSL library supports sha256.
If it does have it, you'll see HAVE_EVP_SHA256 defined in config.h

What version of OpenSSL do you have?  If I'm reading their cvs history
right, sha256 support was added in 0.9.8.

If that's the reason, and you really need those MACs, you have a couple
of options: upgrade the openssl rpms (which may cause other problems),
or you can compile a newer openssl as a static library and use
"./configure --with-ssl-dir=/path/to/your/ssl/dir" to link against that
(but you'll have to remember to recompile both if there are any security
problems in that openssl in future).

-- 
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 Apr  5 22:17:06 2013
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 5 Apr 2013 22:17:06 +1100
Subject: Using hmac-sha2-256 in OpenSSH 6.2p1
In-Reply-To: <20130405110523.GA17808@gate.dtucker.net>
References: <OF080538EC.BE6353F4-ON65257B44.00378696-65257B44.0037CC6E@in.ibm.com>
 <20130405110523.GA17808@gate.dtucker.net>
Message-ID: <20130405111706.GA18395@gate.dtucker.net>

On Fri, Apr 05, 2013 at 10:05:23PM +1100, Darren Tucker wrote:
> What version of OpenSSL do you have?  If I'm reading their cvs history
> right, sha256 support was added in 0.9.8.

Perusal of Redhat's ftp directories seems to indicate that the latest
OpenSSL is openssl-0.9.7a-43.1 so that'd probably explain it.

-- 
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 panurag at in.ibm.com  Fri Apr  5 23:25:22 2013
From: panurag at in.ibm.com (Anurag Panda)
Date: Fri, 5 Apr 2013 17:55:22 +0530
Subject: Using hmac-sha2-256 in OpenSSH 6.2p1
In-Reply-To: <20130405111706.GA18395@gate.dtucker.net>
References: <OF080538EC.BE6353F4-ON65257B44.00378696-65257B44.0037CC6E@in.ibm.com>
 <20130405110523.GA17808@gate.dtucker.net>
 <20130405111706.GA18395@gate.dtucker.net>
Message-ID: <OFCB378034.3DD4532B-ON65257B44.004429EF-65257B44.00444430@in.ibm.com>

Hi,

I installed on RHEL 5. I am able to connect now using hmac-sha2-256. Thank
you for the help.

Thanks & regards,
Anurag



From:	Darren Tucker <dtucker at zip.com.au>
To:	Anurag Panda/India/IBM at IBMIN,
Cc:	openssh-unix-dev at mindrot.org
Date:	04/05/2013 04:46 PM
Subject:	Re: Using hmac-sha2-256 in OpenSSH 6.2p1



On Fri, Apr 05, 2013 at 10:05:23PM +1100, Darren Tucker wrote:
> What version of OpenSSL do you have?  If I'm reading their cvs history
> right, sha256 support was added in 0.9.8.

Perusal of Redhat's ftp directories seems to indicate that the latest
OpenSSL is openssl-0.9.7a-43.1 so that'd probably explain it.

--
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 phil.pennock at globnix.org  Sat Apr  6 04:57:18 2013
From: phil.pennock at globnix.org (Phil Pennock)
Date: Fri, 5 Apr 2013 13:57:18 -0400
Subject: Too many public keys
In-Reply-To: <515E91B4.5000306@0xbadc0de.be>
References: <CALCETrXyLYoBe=LN3nck1mX0D2kuWmWO7bF4SMptcGEhvb17Mg@mail.gmail.com>
 <20130403000135.GQ47549@juniper.net>
 <CALCETrX5=XJ7itLQmyAoUjCfNJdsugLb6jxsYECrKDyGy132UQ@mail.gmail.com>
 <515E91B4.5000306@0xbadc0de.be>
Message-ID: <20130405175718.GA57791@redoubt.spodhuis.org>

On 2013-04-05 at 10:56 +0200, Aris Adamantiadis wrote:
> If you have too many public keys, you can use a config file to
> specifically set an identity file to use with an host. I don't see what
> problems you try to resolve, when in the opposite this limitation of
> public key numbers tries per connection has actually been useful during
> the Debian Openssl fiasco.
> While I agree that there's no point counting failed gssapi attempts as
> these cannot really be bruteforced.

Throwing out a random crazy idea for consideration:

How about cap per keytype, then?  If I'm trying to brute-force DSA,
trying an RSA key shouldn't count against that limit.

I suspect that a reasonable limit is 3 per key-type.  Folks normally
have one per type loaded, they might try a second because they
forgot/didn't-know-about IdentitiesOnly, and one more allows for
weirdness, like "I added keys from a second host for an emergency, then
ran a tool which doesn't specify IdentitiesOnly".

Does this seem reasonable?

From aris at 0xbadc0de.be  Sat Apr  6 07:54:27 2013
From: aris at 0xbadc0de.be (Aris Adamantiadis)
Date: Fri, 05 Apr 2013 22:54:27 +0200
Subject: Too many public keys
In-Reply-To: <20130405175718.GA57791@redoubt.spodhuis.org>
References: <CALCETrXyLYoBe=LN3nck1mX0D2kuWmWO7bF4SMptcGEhvb17Mg@mail.gmail.com>
 <20130403000135.GQ47549@juniper.net>
 <CALCETrX5=XJ7itLQmyAoUjCfNJdsugLb6jxsYECrKDyGy132UQ@mail.gmail.com>
 <515E91B4.5000306@0xbadc0de.be> <20130405175718.GA57791@redoubt.spodhuis.org>
Message-ID: <515F3A03.3090407@0xbadc0de.be>

Le 5/04/13 19:57, Phil Pennock a ?crit :

> How about cap per keytype, then?  If I'm trying to brute-force DSA,
> trying an RSA key shouldn't count against that limit.
> 
> I suspect that a reasonable limit is 3 per key-type.  Folks normally
> have one per type loaded, they might try a second because they
> forgot/didn't-know-about IdentitiesOnly, and one more allows for
> weirdness, like "I added keys from a second host for an emergency, then
> ran a tool which doesn't specify IdentitiesOnly".
> 
Hi Phil,

sorry but this doesn't make a lot of sense to me. Imho if you have more
than 3 keys, they're probably of the same type (if you swear by DSA
you're unlikely to have rsa keys) and you would run in the same problems
again.
Configuring your ssh client to use the appropriate key the first time
isn't harder than typing the good password the first time, and the limit
should instead show him that there's a problem.
Also there's a performance penalty because each pubkey try consumes one
RTT, this can be very significant if you have more than 3 keys on slow
links (3G). You cannot change this without making openssh incompatible
with the specifications or without an ugly hack.

Aris

From cloos at jhcloos.com  Sat Apr  6 10:01:05 2013
From: cloos at jhcloos.com (James Cloos)
Date: Fri, 05 Apr 2013 19:01:05 -0400
Subject: Too many public keys
In-Reply-To: <515F3A03.3090407@0xbadc0de.be> (Aris Adamantiadis's message of
 "Fri, 05 Apr 2013 22:54:27 +0200")
References: <CALCETrXyLYoBe=LN3nck1mX0D2kuWmWO7bF4SMptcGEhvb17Mg@mail.gmail.com>
 <20130403000135.GQ47549@juniper.net>
 <CALCETrX5=XJ7itLQmyAoUjCfNJdsugLb6jxsYECrKDyGy132UQ@mail.gmail.com>
 <515E91B4.5000306@0xbadc0de.be>
 <20130405175718.GA57791@redoubt.spodhuis.org>
 <515F3A03.3090407@0xbadc0de.be>
Message-ID: <m3hajk8tv9.fsf@carbon.jhcloos.org>

>>>>> "AA" == Aris Adamantiadis <aris at 0xbadc0de.be> writes:

AA> Configuring your ssh client to use the appropriate key the first time

The problem isn't the case where the remote site will accept one of one's
keys.  That, as you wrote, it easy to configure.

The problem is when connecting to a site which does not provide an oob
way to install an authorized_keys file.  Ssh(1) sends each key and the
remote sshd(8) drops the connection before one can enter one's passwd.

In practice, most times that occurs one intends to send an a_k file in
band, so using something like:

 :; ssh -o PreferredAuthentications\ keyboard-interactive,password

is more convenient.  Even if that means re-reading the man page yet
again or grep(1)ing around to remember what you called the shell
script or function you wrote the last time it hit you.... :-/

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

From djm at mindrot.org  Sun Apr  7 12:17:26 2013
From: djm at mindrot.org (Damien Miller)
Date: Sun, 7 Apr 2013 12:17:26 +1000 (EST)
Subject: Too many public keys
In-Reply-To: <m3hajk8tv9.fsf@carbon.jhcloos.org>
References: <CALCETrXyLYoBe=LN3nck1mX0D2kuWmWO7bF4SMptcGEhvb17Mg@mail.gmail.com>
 <20130403000135.GQ47549@juniper.net>
 <CALCETrX5=XJ7itLQmyAoUjCfNJdsugLb6jxsYECrKDyGy132UQ@mail.gmail.com>
 <515E91B4.5000306@0xbadc0de.be> <20130405175718.GA57791@redoubt.spodhuis.org>
 <515F3A03.3090407@0xbadc0de.be> <m3hajk8tv9.fsf@carbon.jhcloos.org>
Message-ID: <alpine.BSO.2.00.1304071217060.17420@natsu.mindrot.org>

On Fri, 5 Apr 2013, James Cloos wrote:

> >>>>> "AA" == Aris Adamantiadis <aris at 0xbadc0de.be> writes:
> 
> AA> Configuring your ssh client to use the appropriate key the first time
> 
> The problem isn't the case where the remote site will accept one of one's
> keys.  That, as you wrote, it easy to configure.
> 
> The problem is when connecting to a site which does not provide an oob
> way to install an authorized_keys file.  Ssh(1) sends each key and the
> remote sshd(8) drops the connection before one can enter one's passwd.

ssh -i none user at host

From cloos at jhcloos.com  Sun Apr  7 21:45:43 2013
From: cloos at jhcloos.com (James Cloos)
Date: Sun, 07 Apr 2013 07:45:43 -0400
Subject: Too many public keys
In-Reply-To: <alpine.BSO.2.00.1304071217060.17420@natsu.mindrot.org> (Damien
 Miller's message of "Sun, 7 Apr 2013 12:17:26 +1000 (EST)")
References: <CALCETrXyLYoBe=LN3nck1mX0D2kuWmWO7bF4SMptcGEhvb17Mg@mail.gmail.com>
 <20130403000135.GQ47549@juniper.net>
 <CALCETrX5=XJ7itLQmyAoUjCfNJdsugLb6jxsYECrKDyGy132UQ@mail.gmail.com>
 <515E91B4.5000306@0xbadc0de.be>
 <20130405175718.GA57791@redoubt.spodhuis.org>
 <515F3A03.3090407@0xbadc0de.be> <m3hajk8tv9.fsf@carbon.jhcloos.org>
 <alpine.BSO.2.00.1304071217060.17420@natsu.mindrot.org>
Message-ID: <m3a9pa7edb.fsf@carbon.jhcloos.org>

>>>>> "DM" == Damien Miller <djm at mindrot.org> writes:

>> The problem is when connecting to a site which does not provide an oob
>> way to install an authorized_keys file.  Ssh(1) sends each key and the
>> remote sshd(8) drops the connection before one can enter one's passwd.

DM> ssh -i none user at host

That doesn't work here:

:; ssh -i none a-remote-site.org
Warning: Identity file none not accessible: No such file or directory.
Received disconnect from 62.xx.xxx.xx: 2: Too many authentication failures for cloos

ssh skips none because it is not found and then tries everything known
to the agent, just like w/o -i none.

-o PreferredAuthentications\ keyboard-interactive,password does work.

(It seems like there was something different I used to use, but the
above is what I've ended up with.)

-JimC
-- 
James Cloos <cloos at jhcloos.com>         OpenPGP: 1024D/ED7DAEA6

From dtucker at zip.com.au  Mon Apr  8 19:41:40 2013
From: dtucker at zip.com.au (Darren Tucker)
Date: Mon, 8 Apr 2013 19:41:40 +1000
Subject: "no such identity"
In-Reply-To: <20130405075559.GA30526@calimero.vinschen.de>
References: <86hajqpdpz.fsf@ds4.des.no> <20130401172251.GB47549@juniper.net>
 <20130402120840.GA29590@calimero.vinschen.de>
 <20130402131500.GA29515@gate.dtucker.net>
 <20130402132655.GA18060@calimero.vinschen.de>
 <20130404234952.GA28615@gate.dtucker.net>
 <20130405003653.GA2583@gate.dtucker.net>
 <20130405075559.GA30526@calimero.vinschen.de>
Message-ID: <CALDDTe1FaFkoMZ=bNvTk7070yJd2dc9VWkjf3RO2hTJt3dQimg@mail.gmail.com>

On Fri, Apr 5, 2013 at 6:55 PM, Corinna Vinschen <vinschen at redhat.com> wrote:
[...]
> as another potential issue, we got a report on the Cygwin list
> complaining about excessive syslog error messages:
>
>  http://cygwin.com/ml/cygwin/2013-04/msg00019.html
>
> It seems weird to log a disconnect as error.  Is that really the
> right thing to do?

Hm.  I've reopend the bug
(https://bugzilla.mindrot.org/show_bug.cgi?id=2057) to take a look.

-- 
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 rak at debian.org  Tue Apr  9 02:25:21 2013
From: rak at debian.org (Ryan Kavanagh)
Date: Mon, 8 Apr 2013 12:25:21 -0400
Subject: [PATCH] Allow matching HostName against Host entries
In-Reply-To: <20130322015127.GC30194@nu.ryanak.ca>
References: <20130322015127.GC30194@nu.ryanak.ca>
Message-ID: <20130408162521.GA21308@nu.ryanak.ca>

Hi,

I really think this patch[0] would be useful to users[1] and would be nice
to have incorporated. Was this the correct list to submit it to, or
should I have sent it to tech at openbsd.org or elsewhere? Is there
anything I can do to help it get included?

Best wishes,
Ryan

[0] http://lists.mindrot.org/pipermail/openssh-unix-dev/2013-March/031166.html
[1] See for example
http://superuser.com/questions/469329/ssh-config-wildcard-on-expanded-hostname
http://lists.mindrot.org/pipermail/openssh-unix-dev/2008-August/026829.html

-- 
|_)|_/	Ryan Kavanagh		| Debian Developer
| \| \	http://ryanak.ca/	| GPG Key 4A11C97A

From mouring at offwriting.org  Tue Apr  9 04:13:38 2013
From: mouring at offwriting.org (Ben Lindstrom)
Date: Mon, 8 Apr 2013 13:13:38 -0500
Subject: [PATCH] Allow matching HostName against Host entries
In-Reply-To: <20130408162521.GA21308@nu.ryanak.ca>
References: <20130322015127.GC30194@nu.ryanak.ca>
 <20130408162521.GA21308@nu.ryanak.ca>
Message-ID: <FF95B9E7-0991-483F-B8CB-28B8E5F5995E@offwriting.org>


On Apr 8, 2013, at 11:25 AM, Ryan Kavanagh <rak at debian.org> wrote:

> Hi,
> 
> I really think this patch[0] would be useful to users[1] and would be nice
> to have incorporated. Was this the correct list to submit it to, or
> should I have sent it to tech at openbsd.org or elsewhere? Is there
> anything I can do to help it get included?


Isn't this failure to understand that the Host list is in first match order?  So place
what you wish to have highest priority first, and then the remaining wildcard
matches towards the bottom.

I've been doing this for ages without needing yet another option.  Unless your
description isn't fully explaining why we need this option.

- Ben

From vinschen at redhat.com  Tue Apr  9 04:33:49 2013
From: vinschen at redhat.com (Corinna Vinschen)
Date: Mon, 8 Apr 2013 20:33:49 +0200
Subject: "no such identity"
In-Reply-To: <CALDDTe1FaFkoMZ=bNvTk7070yJd2dc9VWkjf3RO2hTJt3dQimg@mail.gmail.com>
References: <86hajqpdpz.fsf@ds4.des.no> <20130401172251.GB47549@juniper.net>
 <20130402120840.GA29590@calimero.vinschen.de>
 <20130402131500.GA29515@gate.dtucker.net>
 <20130402132655.GA18060@calimero.vinschen.de>
 <20130404234952.GA28615@gate.dtucker.net>
 <20130405003653.GA2583@gate.dtucker.net>
 <20130405075559.GA30526@calimero.vinschen.de>
 <CALDDTe1FaFkoMZ=bNvTk7070yJd2dc9VWkjf3RO2hTJt3dQimg@mail.gmail.com>
Message-ID: <20130408183349.GG10126@calimero.vinschen.de>

On Apr  8 19:41, Darren Tucker wrote:
> On Fri, Apr 5, 2013 at 6:55 PM, Corinna Vinschen <vinschen at redhat.com> wrote:
> [...]
> > as another potential issue, we got a report on the Cygwin list
> > complaining about excessive syslog error messages:
> >
> >  http://cygwin.com/ml/cygwin/2013-04/msg00019.html
> >
> > It seems weird to log a disconnect as error.  Is that really the
> > right thing to do?
> 
> Hm.  I've reopend the bug
> (https://bugzilla.mindrot.org/show_bug.cgi?id=2057) to take a look.

Thank you!


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

From rak at debian.org  Tue Apr  9 11:09:41 2013
From: rak at debian.org (Ryan Kavanagh)
Date: Mon, 8 Apr 2013 21:09:41 -0400
Subject: [PATCH] Allow matching HostName against Host entries
In-Reply-To: <FF95B9E7-0991-483F-B8CB-28B8E5F5995E@offwriting.org>
References: <20130322015127.GC30194@nu.ryanak.ca>
 <20130408162521.GA21308@nu.ryanak.ca>
 <FF95B9E7-0991-483F-B8CB-28B8E5F5995E@offwriting.org>
Message-ID: <20835.27221.466113.996877@nu.ryanak.ca>

Hi Ben,

On Monday, April  8, 2013 at 13:13:38 -0500, Ben Lindstrom wrote:
> Isn't this failure to understand that the Host list is in first
> match order?  So place what you wish to have highest priority first,
> and then the remaining wildcard matches towards the bottom.

Far from it, this patch helps users make use of the fact that the Host
list is in first match order. Very briefly put, what it lets you do is
have ssh also try to match the first HostName entry from a matching
Host stanza against any subsequent Host stanzas. Without this patch,
if you had a stanza like

	Host myhost
	     HostName myhost.foo.bar

the command "ssh myhost" would not have ssh match against the stanza

	Host *.foo.bar
	     Foo1 Bar1

You could argue that I could just setup the "search" option in
resolv.conf. But what if I have hosts outside of my local domain, or
my administrator doesn't give me edit writes to /etc/resolv.conf? You
could also argue that I could change this wildcard to

	Host *.foo.bar myhost
	     Foo1 Bar1

but this quickly becomes unmanageable with complex config files, as my
example below shows.

> I've been doing this for ages without needing yet another option.
> Unless your description isn't fully explaining why we need this
> option.

Maybe my example wasn't clear. Imagine you have 510 boxes split across
two networks; 255 are in a student lab, and the remaining 255 are in a
professor lab. Let's make things dramatic and imagine you have
settings for each one of these machines, and settings for each lab,
and settings for both labs. You want to have an alias for each host,
for example, you want to be able to go "ssh slab1" to connect to
"lab1.student.lab" (for the sake of simplicity, I've just numbered
things and one could just use a "slab*" wildcard, but let's keep in
mind cases where this wouldn't work). Under the current ssh_config,
you'd have something that looked like:

	#### BEGIN CURRENT SSH_CONFIG ####
	VisualHostKey yes

	Host slab1
	     User slab1
	     HostName lab1.student.lab

	## Repeat for slab{2..254}

	Host slab255
	     User slab255
	     Hostname lab255.student.lab

	Host plab1
	     User plab1
	     HostName lab1.professor.lab

	## plab{2..254}

	Host plab255
	     User plab255
	     HostName lab255.professor.lab

	# Insert whatever other hosts you know of

	Host *.student.lab slab1 slab2 ... slab255
	     IdentityFile ~/.ssh/id_ecdsa.slab
	     UserKnownHostsFile ~/.ssh/known_hosts.d/student.lab

	Host *.professor.lab plab1 plab2 ... plab255
	     IdentityFile ~/.ssh/id_ecdsa.plab
	     UserKnownHostsFile ~/.ssh/known_hosts.d/professor.lab

	Host *.lab slab1 slab2 ... slab255 plab1 plab2 ... plab255
	     VisualHostKey no
	     ForwardX11 yes
	#### END CURRENT SSH_CONFIG ####

Note that the Host lines matching each lab will be 256 entries long,
and the one matching both labs will be 511 entries long. Now imagine
being able to match the corresponding HostName entry against a
wildcard. With my patch, your config would look like:

	#### BEGIN PROPOSED SSH_CONFIG ####
	MatchHostName yes
	# ^^^^ This is the magic line
	VisualHostKey yes

	Host slab1
	     User slab1
	     HostName lab1.student.lab

	## Repeat for slab{2..254}

	Host slab255
	     User slab255
	     Hostname lab255.student.lab

	Host plab1
	     User plab1
	     HostName lab1.professor.lab

	## plab{2..254}

	Host plab255
	     User plab255
	     HostName lab255.professor.lab

	# Insert whatever other hosts you know of

	Host *.student.lab
	     IdentityFile ~/.ssh/id_ecdsa.slab
	     UserKnownHostsFile ~/.ssh/known_hosts.d/student.lab

	Host *.professor.lab
	     IdentityFile ~/.ssh/id_ecdsa.plab
	     UserKnownHostsFile ~/.ssh/known_hosts.d/professor.lab

	Host *.lab
	     VisualHostKey no
	     ForwardX11 yes
	#### END PROPOSED SSH_CONFIG ####

In my opinion, this proposed ssh_config is considerably cleaner, and
easier to understand and manage. My own interest in this patch is
similar. I have a couple dozen hosts I connect to across three
domains. I'd like to be able to connect to each of these by using the
subdomain (set with HostName in a Host stanza matching the subdomain),
while still having the domain wildcard matched.

As for implementation, the "MatchHostName yes" doesn't need to be
enabled globally as in the example above. It can be used only for
certain aliases. Moreover, my patch only takes effect once there's
been a HostName entry in a matching Host stanza and MatchHostName has
been enabled.

I hope this helps, please let me know if you have any questions,
concerns, or comments.

Best wishes,
Ryan

-- 
|_)|_/	Ryan Kavanagh		| Debian Developer
| \| \	http://ryanak.ca/	| GPG Key 4A11C97A

From djm at mindrot.org  Tue Apr  9 12:55:00 2013
From: djm at mindrot.org (Damien Miller)
Date: Tue, 9 Apr 2013 12:55:00 +1000 (EST)
Subject: Too many public keys
In-Reply-To: <m3a9pa7edb.fsf@carbon.jhcloos.org>
References: <CALCETrXyLYoBe=LN3nck1mX0D2kuWmWO7bF4SMptcGEhvb17Mg@mail.gmail.com>
 <20130403000135.GQ47549@juniper.net>
 <CALCETrX5=XJ7itLQmyAoUjCfNJdsugLb6jxsYECrKDyGy132UQ@mail.gmail.com>
 <515E91B4.5000306@0xbadc0de.be> <20130405175718.GA57791@redoubt.spodhuis.org>
 <515F3A03.3090407@0xbadc0de.be> <m3hajk8tv9.fsf@carbon.jhcloos.org>
 <alpine.BSO.2.00.1304071217060.17420@natsu.mindrot.org>
 <m3a9pa7edb.fsf@carbon.jhcloos.org>
Message-ID: <alpine.BSO.2.00.1304091251130.23951@natsu.mindrot.org>

On Sun, 7 Apr 2013, James Cloos wrote:

> >>>>> "DM" == Damien Miller <djm at mindrot.org> writes:
> 
> >> The problem is when connecting to a site which does not provide an oob
> >> way to install an authorized_keys file.  Ssh(1) sends each key and the
> >> remote sshd(8) drops the connection before one can enter one's passwd.
> 
> DM> ssh -i none user at host
> 
> That doesn't work here:
> 
> :; ssh -i none a-remote-site.org
> Warning: Identity file none not accessible: No such file or directory.
> Received disconnect from 62.xx.xxx.xx: 2: Too many authentication failures for cloos
> 
> ssh skips none because it is not found and then tries everything known
> to the agent

Sorry, if you are using the agent then

ssh -oIdentityFile=none -oIdentitiesOnly=yes user at host

Seriously, if you have a ton of keys in the agent then it makes every
sense to limit what you present. In practice, it means filling out
~/.ssh/config:

Host a
	IdentityFile ~/.ssh/id_host_a
Host b
	IdentityFile ~/.ssh/id_host_b
Host c d e f g
	IdentityFile ~/.ssh/id_host_lots
Host z
	IdentityFile none
Host *
	IdentitiesOnly yes

-d

From imorgan at nas.nasa.gov  Wed Apr 10 05:00:43 2013
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Tue, 9 Apr 2013 12:00:43 -0700
Subject: [PATCH] Allow matching HostName against Host entries
In-Reply-To: <20835.27221.466113.996877@nu.ryanak.ca>
References: <20130322015127.GC30194@nu.ryanak.ca>
 <20130408162521.GA21308@nu.ryanak.ca>
 <FF95B9E7-0991-483F-B8CB-28B8E5F5995E@offwriting.org>
 <20835.27221.466113.996877@nu.ryanak.ca>
Message-ID: <20130409190042.GA8305@linux124.nas.nasa.gov>

On Mon, Apr 08, 2013 at 20:09:41 -0500, Ryan Kavanagh wrote:
> Hi Ben,
> 
> On Monday, April  8, 2013 at 13:13:38 -0500, Ben Lindstrom wrote:
> > Isn't this failure to understand that the Host list is in first
> > match order?  So place what you wish to have highest priority first,
> > and then the remaining wildcard matches towards the bottom.
> 
> Far from it, this patch helps users make use of the fact that the Host
> list is in first match order. Very briefly put, what it lets you do is
> have ssh also try to match the first HostName entry from a matching
> Host stanza against any subsequent Host stanzas. Without this patch,
> if you had a stanza like
> 
> 	Host myhost
> 	     HostName myhost.foo.bar
> 
> the command "ssh myhost" would not have ssh match against the stanza
> 
> 	Host *.foo.bar
> 	     Foo1 Bar1
> 
> You could argue that I could just setup the "search" option in
> resolv.conf. But what if I have hosts outside of my local domain, or
> my administrator doesn't give me edit writes to /etc/resolv.conf? You
> could also argue that I could change this wildcard to
> 
> 	Host *.foo.bar myhost
> 	     Foo1 Bar1
> 
> but this quickly becomes unmanageable with complex config files, as my
> example below shows.
> 
> > I've been doing this for ages without needing yet another option.
> > Unless your description isn't fully explaining why we need this
> > option.
> 
> Maybe my example wasn't clear. Imagine you have 510 boxes split across
> two networks; 255 are in a student lab, and the remaining 255 are in a
> professor lab. Let's make things dramatic and imagine you have
> settings for each one of these machines, and settings for each lab,
> and settings for both labs. You want to have an alias for each host,
> for example, you want to be able to go "ssh slab1" to connect to
> "lab1.student.lab" (for the sake of simplicity, I've just numbered
> things and one could just use a "slab*" wildcard, but let's keep in
> mind cases where this wouldn't work). Under the current ssh_config,
> you'd have something that looked like:
> 
> 	#### BEGIN CURRENT SSH_CONFIG ####
> 	VisualHostKey yes
> 
> 	Host slab1
> 	     User slab1
> 	     HostName lab1.student.lab
> 
> 	## Repeat for slab{2..254}
> 
> 	Host slab255
> 	     User slab255
> 	     Hostname lab255.student.lab
> 
> 	Host plab1
> 	     User plab1
> 	     HostName lab1.professor.lab
> 
> 	## plab{2..254}
> 
> 	Host plab255
> 	     User plab255
> 	     HostName lab255.professor.lab
> 
> 	# Insert whatever other hosts you know of
> 
> 	Host *.student.lab slab1 slab2 ... slab255
> 	     IdentityFile ~/.ssh/id_ecdsa.slab
> 	     UserKnownHostsFile ~/.ssh/known_hosts.d/student.lab
> 
> 	Host *.professor.lab plab1 plab2 ... plab255
> 	     IdentityFile ~/.ssh/id_ecdsa.plab
> 	     UserKnownHostsFile ~/.ssh/known_hosts.d/professor.lab
> 
> 	Host *.lab slab1 slab2 ... slab255 plab1 plab2 ... plab255
> 	     VisualHostKey no
> 	     ForwardX11 yes
> 	#### END CURRENT SSH_CONFIG ####
> 
> Note that the Host lines matching each lab will be 256 entries long,
> and the one matching both labs will be 511 entries long. Now imagine
> being able to match the corresponding HostName entry against a
> wildcard. With my patch, your config would look like:
> 
> 	#### BEGIN PROPOSED SSH_CONFIG ####
> 	MatchHostName yes
> 	# ^^^^ This is the magic line
> 	VisualHostKey yes
> 
> 	Host slab1
> 	     User slab1
> 	     HostName lab1.student.lab
> 
> 	## Repeat for slab{2..254}
> 
> 	Host slab255
> 	     User slab255
> 	     Hostname lab255.student.lab
> 
> 	Host plab1
> 	     User plab1
> 	     HostName lab1.professor.lab
> 
> 	## plab{2..254}
> 
> 	Host plab255
> 	     User plab255
> 	     HostName lab255.professor.lab
> 
> 	# Insert whatever other hosts you know of
> 
> 	Host *.student.lab
> 	     IdentityFile ~/.ssh/id_ecdsa.slab
> 	     UserKnownHostsFile ~/.ssh/known_hosts.d/student.lab
> 
> 	Host *.professor.lab
> 	     IdentityFile ~/.ssh/id_ecdsa.plab
> 	     UserKnownHostsFile ~/.ssh/known_hosts.d/professor.lab
> 
> 	Host *.lab
> 	     VisualHostKey no
> 	     ForwardX11 yes
> 	#### END PROPOSED SSH_CONFIG ####
> 
> In my opinion, this proposed ssh_config is considerably cleaner, and
> easier to understand and manage. My own interest in this patch is
> similar. I have a couple dozen hosts I connect to across three
> domains. I'd like to be able to connect to each of these by using the
> subdomain (set with HostName in a Host stanza matching the subdomain),
> while still having the domain wildcard matched.
> 
> As for implementation, the "MatchHostName yes" doesn't need to be
> enabled globally as in the example above. It can be used only for
> certain aliases. Moreover, my patch only takes effect once there's
> been a HostName entry in a matching Host stanza and MatchHostName has
> been enabled.
> 
> I hope this helps, please let me know if you have any questions,
> concerns, or comments.
> 

As you imply above, this could be addressed by using a consistent scheme
for your aliaes. Thus, the latter portions of your configuration could
use globbing:

	Host *.student.lab slab*
		...

	Host *.professor.lab plab*
		...

	Host *.lab plab* slab*
		...

Another approach which could address similar issues would be support for
subnet configuration, as requested in bz#1169[1]. 

-- 
Iain Morgan

[1] https://bugzilla.mindrot.org/show_bug.cgi?id=1169

From rak at debian.org  Wed Apr 10 05:57:13 2013
From: rak at debian.org (Ryan Kavanagh)
Date: Tue, 9 Apr 2013 15:57:13 -0400
Subject: [PATCH] Allow matching HostName against Host entries
In-Reply-To: <20130409190042.GA8305@linux124.nas.nasa.gov>
References: <20130322015127.GC30194@nu.ryanak.ca>
 <20130408162521.GA21308@nu.ryanak.ca>
 <FF95B9E7-0991-483F-B8CB-28B8E5F5995E@offwriting.org>
 <20835.27221.466113.996877@nu.ryanak.ca>
 <20130409190042.GA8305@linux124.nas.nasa.gov>
Message-ID: <20836.29337.739297.965797@nu.ryanak.ca>

Hi Iain,

On Tuesday, April  9, 2013 at 12:00:43 -0700, Iain Morgan wrote:
> As you imply above, this could be addressed by using a consistent scheme
> for your aliaes.

That is true, but ignores the fact that this is not always
possible. Some organisations don't numerically number their hosts and
instead name them after Greek gods, after composers, or
arbitrarily. And so one resorts to the consistent scheme of
"hostname.domain.tld" -> "hostname". For a simple example, consider my
config file with the patch[0], without the patch[1], and the diff[2].

As far as I can tell from looking through the patch, it won't break
any existing configuration files, and will only serve to simplify
those making use of it.

Best wishes,
Ryan

[0] http://people.debian.org/~rak/ssh_configs/config.new
[1] http://people.debian.org/~rak/ssh_configs/config.old
[2] http://people.debian.org/~rak/ssh_configs/config.diff

-- 
|_)|_/	Ryan Kavanagh		| Debian Developer
| \| \	http://ryanak.ca/	| GPG Key 4A11C97A

From mouring at offwriting.org  Wed Apr 10 06:06:55 2013
From: mouring at offwriting.org (Ben Lindstrom)
Date: Tue, 9 Apr 2013 15:06:55 -0500
Subject: [PATCH] Allow matching HostName against Host entries
In-Reply-To: <20836.29337.739297.965797@nu.ryanak.ca>
References: <20130322015127.GC30194@nu.ryanak.ca>
 <20130408162521.GA21308@nu.ryanak.ca>
 <FF95B9E7-0991-483F-B8CB-28B8E5F5995E@offwriting.org>
 <20835.27221.466113.996877@nu.ryanak.ca>
 <20130409190042.GA8305@linux124.nas.nasa.gov>
 <20836.29337.739297.965797@nu.ryanak.ca>
Message-ID: <0353A032-09F8-4AB7-A928-E03D1D4CCA21@offwriting.org>


On Apr 9, 2013, at 2:57 PM, Ryan Kavanagh <rak at debian.org> wrote:

> Hi Iain,
> 
> On Tuesday, April  9, 2013 at 12:00:43 -0700, Iain Morgan wrote:
>> As you imply above, this could be addressed by using a consistent scheme
>> for your aliaes.
> 
> That is true, but ignores the fact that this is not always
> possible. Some organisations don't numerically number their hosts and
> instead name them after Greek gods, after composers, or
> arbitrarily. And so one resorts to the consistent scheme of
> "hostname.domain.tld" -> "hostname". For a simple example, consider my
> config file with the patch[0], without the patch[1], and the diff[2].
> 
> As far as I can tell from looking through the patch, it won't break
> any existing configuration files, and will only serve to simplify
> those making use of it.

My major complaint is this one option changes how the ssh_config is
parsed.  It just takes one admin to decided he likes it to break everyone's
setup..

e.g.

host foo
  user  specialaccount
  hostname foo.bar.com

host *.bar.com
   user normaluser


Which is horrible as it *DOES* break it if you enable that switch. 

- Ben

From imorgan at nas.nasa.gov  Wed Apr 10 06:13:18 2013
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Tue, 9 Apr 2013 13:13:18 -0700
Subject: [PATCH] Allow matching HostName against Host entries
In-Reply-To: <20836.29337.739297.965797@nu.ryanak.ca>
References: <20130322015127.GC30194@nu.ryanak.ca>
 <20130408162521.GA21308@nu.ryanak.ca>
 <FF95B9E7-0991-483F-B8CB-28B8E5F5995E@offwriting.org>
 <20835.27221.466113.996877@nu.ryanak.ca>
 <20130409190042.GA8305@linux124.nas.nasa.gov>
 <20836.29337.739297.965797@nu.ryanak.ca>
Message-ID: <20130409201318.GD8336@linux124.nas.nasa.gov>

On Tue, Apr 09, 2013 at 14:57:13 -0500, Ryan Kavanagh wrote:
> Hi Iain,
> 
> On Tuesday, April  9, 2013 at 12:00:43 -0700, Iain Morgan wrote:
> > As you imply above, this could be addressed by using a consistent scheme
> > for your aliaes.
> 
> That is true, but ignores the fact that this is not always
> possible. Some organisations don't numerically number their hosts and
> instead name them after Greek gods, after composers, or
> arbitrarily. And so one resorts to the consistent scheme of
> "hostname.domain.tld" -> "hostname". For a simple example, consider my
> config file with the patch[0], without the patch[1], and the diff[2].

While it helps if the hostnames follow a consistent naming scheme, it is
not strictly necessary. Since you have control of the aliases which you
introduce in your ~/.ssh/config, you can apply whatever scheme is
convenient. For example, if a system's hostname is "zeus" you could use
"Host slab-zeus" in your configuration. Admittedly, this does require
that you remember to use the naming scheme which you have imposed
whenever you ssh to one of these systems.

-- 
Iain Morgan

From rak at debian.org  Wed Apr 10 10:51:12 2013
From: rak at debian.org (Ryan Kavanagh)
Date: Tue, 9 Apr 2013 20:51:12 -0400
Subject: [PATCH] Allow matching HostName against Host entries
In-Reply-To: <0353A032-09F8-4AB7-A928-E03D1D4CCA21@offwriting.org>
References: <20130322015127.GC30194@nu.ryanak.ca>
 <20130408162521.GA21308@nu.ryanak.ca>
 <FF95B9E7-0991-483F-B8CB-28B8E5F5995E@offwriting.org>
 <20835.27221.466113.996877@nu.ryanak.ca>
 <20130409190042.GA8305@linux124.nas.nasa.gov>
 <20836.29337.739297.965797@nu.ryanak.ca>
 <0353A032-09F8-4AB7-A928-E03D1D4CCA21@offwriting.org>
Message-ID: <20836.46976.558649.914066@nu.ryanak.ca>

On Tuesday, April  9, 2013 at 15:06:55 -0500, Ben Lindstrom wrote:
> My major complaint is this one option changes how the ssh_config is
> parsed.  It just takes one admin to decided he likes it to break everyone's
> setup..
> 
> e.g.
> 
> host foo
>   user  specialaccount
>   hostname foo.bar.com
> 
> host *.bar.com
>    user normaluser
> 
> Which is horrible as it *DOES* break it if you enable that switch. 

I'm not sure I follow your counterexample. Even if the switch was
enabled, "ssh foo" would still use "user specialaccount", not "user
normaluser" since the switch doesn't break the first match
order. Nowhere does the patch affect the check on lines 397 or 414[0]
that only set an option if it hasn't yet been unset. Or am I
misunderstanding something? Now, assume that your counterexample was
instead

	## User ~/.ssh/config ##
	host foo
	  user  specialaccount
	  hostname foo.bar.com

	## System /etc/ssh/ssh_config
	MatchHostName yes

	host *.bar.com
	   user normaluser
	   ForwardAgent yes

Enabling the proposed switch would in fact cause breakage: agent
forwarding would be enabled for "ssh foo" with the switch on, and
would be the default value with the switch off. I consider this
particular objection to be moot: any changes to the system config file
is prone to breaking users config files or causing severe carnage and
should be done with utmost caution. A nutcase admin can equally well
break everyone's config (and wipe home directories) without needing
any new flags with:

	## System /etc/ssh/ssh_config
	## Don't try this at home (or work!)
	host *
	     ForwardAgent yes
	     LocalCommand rm -fr %d
	     PermitLocalCommand yes

Best wishes,
Ryan

[0] if (*activep && *intptr == -1)
        /* *intptr is the pointer to &options->CURRENT_SETTING */
        *intptr = value;
-- 
|_)|_/	Ryan Kavanagh		| Debian Developer
| \| \	http://ryanak.ca/	| GPG Key 4A11C97A

From mfriedl at gmail.com  Wed Apr 10 20:09:40 2013
From: mfriedl at gmail.com (Markus Friedl)
Date: Wed, 10 Apr 2013 12:09:40 +0200
Subject: [PATCH] Allow matching HostName against Host entries
In-Reply-To: <20130408162521.GA21308@nu.ryanak.ca>
References: <20130322015127.GC30194@nu.ryanak.ca>
 <20130408162521.GA21308@nu.ryanak.ca>
Message-ID: <49B4AA52-D1E2-419E-B022-5C10434B5A39@gmail.com>

I'm not sure if I like it....
I don't think it's that useful....


Am 08.04.2013 um 18:25 schrieb Ryan Kavanagh <rak at debian.org>:

> Hi,
> 
> I really think this patch[0] would be useful to users[1] and would be nice
> to have incorporated. Was this the correct list to submit it to, or
> should I have sent it to tech at openbsd.org or elsewhere? Is there
> anything I can do to help it get included?
> 
> Best wishes,
> Ryan
> 
> [0] http://lists.mindrot.org/pipermail/openssh-unix-dev/2013-March/031166.html
> [1] See for example
> http://superuser.com/questions/469329/ssh-config-wildcard-on-expanded-hostname
> http://lists.mindrot.org/pipermail/openssh-unix-dev/2008-August/026829.html
> 
> -- 
> |_)|_/	Ryan Kavanagh		| Debian Developer
> | \| \	http://ryanak.ca/	| GPG Key 4A11C97A
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


From apb at cequrux.com  Thu Apr 11 15:06:06 2013
From: apb at cequrux.com (Alan Barrett)
Date: Thu, 11 Apr 2013 07:06:06 +0200
Subject: [PATCH] Allow matching HostName against Host entries
In-Reply-To: <0353A032-09F8-4AB7-A928-E03D1D4CCA21@offwriting.org>
References: <20130322015127.GC30194@nu.ryanak.ca>
 <20130408162521.GA21308@nu.ryanak.ca>
 <FF95B9E7-0991-483F-B8CB-28B8E5F5995E@offwriting.org>
 <20835.27221.466113.996877@nu.ryanak.ca>
 <20130409190042.GA8305@linux124.nas.nasa.gov>
 <20836.29337.739297.965797@nu.ryanak.ca>
 <0353A032-09F8-4AB7-A928-E03D1D4CCA21@offwriting.org>
Message-ID: <20130411050606.GB13960@apb-laptoy.apb.alt.za>

I would find the proposed MatchHostName feature very useful.  It 
would allow me to remove a significant amount of duplication from 
my ssh config files.

On Tue, 09 Apr 2013, Ben Lindstrom wrote:
>My major complaint is this one option changes how the ssh_config is
>parsed.  It just takes one admin to decided he likes it to break everyone's
>setup..

Sure.  The admin should not put "MatchHostname yes" in the system ssh
config file; it's something that users should be able to choose to put
in their own config files.

>e.g.
>
>host foo
>  user  specialaccount
>  hostname foo.bar.com
>
>host *.bar.com
>   user normaluser
>
>Which is horrible as it *DOES* break it if you enable that switch.

You could always override with "MatchHostName no", like this:

     MatchHostName yes # global setting

     host foo
       user  specialaccount
       hostname foo.bar.com
       MatchHostName no # override for "host foo"

     host *.bar.com
       user normaluser
       SomeOtherSetting "used for 'foo.bar.com', but not used for 'foo'"

--apb (Alan Barrett)

From imorgan at nas.nasa.gov  Fri Apr 12 02:37:15 2013
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Thu, 11 Apr 2013 09:37:15 -0700
Subject: [PATCH] Allow matching HostName against Host entries
In-Reply-To: <20130411050606.GB13960@apb-laptoy.apb.alt.za>
References: <20130322015127.GC30194@nu.ryanak.ca>
 <20130408162521.GA21308@nu.ryanak.ca>
 <FF95B9E7-0991-483F-B8CB-28B8E5F5995E@offwriting.org>
 <20835.27221.466113.996877@nu.ryanak.ca>
 <20130409190042.GA8305@linux124.nas.nasa.gov>
 <20836.29337.739297.965797@nu.ryanak.ca>
 <0353A032-09F8-4AB7-A928-E03D1D4CCA21@offwriting.org>
 <20130411050606.GB13960@apb-laptoy.apb.alt.za>
Message-ID: <20130411163714.GA17666@linux124.nas.nasa.gov>

On Thu, Apr 11, 2013 at 00:06:06 -0500, Alan Barrett wrote:
> 
> You could always override with "MatchHostName no", like this:
> 
>      MatchHostName yes # global setting
> 
>      host foo
>        user  specialaccount
>        hostname foo.bar.com
>        MatchHostName no # override for "host foo"
> 
>      host *.bar.com
>        user normaluser
>        SomeOtherSetting "used for 'foo.bar.com', but not used for 'foo'"
> 

The example ignores how ssh(1) parses the config file. Since the first
match is applied, global options as shown above cannot be overridden.

-- 
Iain Morgan

From rak at debian.org  Fri Apr 12 03:08:18 2013
From: rak at debian.org (Ryan Kavanagh)
Date: Thu, 11 Apr 2013 13:08:18 -0400
Subject: [PATCH] Allow matching HostName against Host entries
In-Reply-To: <20130411050606.GB13960@apb-laptoy.apb.alt.za>,
 <20130411163714.GA17666@linux124.nas.nasa.gov>
References: <20130322015127.GC30194@nu.ryanak.ca>
 <20130408162521.GA21308@nu.ryanak.ca>
 <FF95B9E7-0991-483F-B8CB-28B8E5F5995E@offwriting.org>
 <20835.27221.466113.996877@nu.ryanak.ca>
 <20130409190042.GA8305@linux124.nas.nasa.gov>
 <20836.29337.739297.965797@nu.ryanak.ca>
 <0353A032-09F8-4AB7-A928-E03D1D4CCA21@offwriting.org>
 <20130411050606.GB13960@apb-laptoy.apb.alt.za>
 <20130411163714.GA17666@linux124.nas.nasa.gov>
Message-ID: <20838.60930.13479.722946@nu.ryanak.ca>

You would probably meant something along the lines of:

      host foo
        user  specialaccount
        hostname foo.bar.com
        MatchHostName no # override for "host foo"
 
      host *.bar.com
        user normaluser
        SomeOtherSetting "used for 'foo.bar.com', but not used for 'foo'"

      host *
        MatchHostName no # global setting

in your user config, which would make sure that none of your Host
stanzas match a global config in case your sysadmin decides to turn
the flag on. Of course, if you're depending on you sysadmin's global
config for things, and he changes it to require matchhostname, then
you're equally in trouble. But again, anything your sysadmin does can
break your own configs or worse.

Best wishes,
Ryan

-- 
|_)|_/	Ryan Kavanagh		| Debian Developer
| \| \	http://ryanak.ca/	| GPG Key 4A11C97A

From djm at mindrot.org  Fri Apr 12 12:50:54 2013
From: djm at mindrot.org (Damien Miller)
Date: Fri, 12 Apr 2013 12:50:54 +1000 (EST)
Subject: [PATCH] Allow matching HostName against Host entries
In-Reply-To: <49B4AA52-D1E2-419E-B022-5C10434B5A39@gmail.com>
References: <20130322015127.GC30194@nu.ryanak.ca>
 <20130408162521.GA21308@nu.ryanak.ca>
 <49B4AA52-D1E2-419E-B022-5C10434B5A39@gmail.com>
Message-ID: <alpine.BSO.2.00.1304121217590.24613@natsu.mindrot.org>

On Wed, 10 Apr 2013, Markus Friedl wrote:

> I'm not sure if I like it....
> I don't think it's that useful....

I can see why someone might want something like it for one particular reason:
we don't do a fantastic job with unqualified hostnames right now. E.g. my
resolv.conf might contain something like:

search mel.int.spectre.com int.spectre.com spectre.com

.. and I run "ssh www023". Without explicit configuration, I'd end up with
an unqualified name in my known_hosts that isn't deduplicated with a
partially, or fully qualified one that might also be in there or come later.

Furthermore, this makes hostkey certificates much less useful. When creating
the certificates I have to chose whether to list only the FQDNs of a host
as principals or whether I should also include unqualified names too. If
I chose FQDNs that my certificates will not authenticate the host if I've
connected using an unqualified name. If I chose to list un- and partially-
qualified names then I open myself to host impersonation attacks (e.g.
consider a certificate for a server named "www" or "proxy").

Much of the pain will go away if we have some option to allow
ssh to canonicalise its hostnames. I thought we could do it using the
AI_FQDN[1] getaddrinfo hint but I've realised that this would expose
users on DHCP networks to new attacks as a spoofed DHCP server can
control the DNS search order.

A better option might be to allow specification of the suffix order in
ssh_config itself. E.g.

HostnameSuffixes mel.int.spectre.com int.spectre.com spectre.com

to make ssh try resolution of unqualified names by appending each suffix
in turn and stopping at the first successful lookup. The fully-qualified
result would then replace the unqualified hostname for the purpose of
ssh_config matching, known_hosts lookups and certificate name verification.

What do you think?

-d


From djm at mindrot.org  Fri Apr 12 13:18:22 2013
From: djm at mindrot.org (Damien Miller)
Date: Fri, 12 Apr 2013 13:18:22 +1000 (EST)
Subject: [PATCH] Allow matching HostName against Host entries
In-Reply-To: <alpine.BSO.2.00.1304121217590.24613@natsu.mindrot.org>
References: <20130322015127.GC30194@nu.ryanak.ca>
 <20130408162521.GA21308@nu.ryanak.ca>
 <49B4AA52-D1E2-419E-B022-5C10434B5A39@gmail.com>
 <alpine.BSO.2.00.1304121217590.24613@natsu.mindrot.org>
Message-ID: <alpine.BSO.2.00.1304121318080.24613@natsu.mindrot.org>

On Fri, 12 Apr 2013, Damien Miller wrote:

> Much of the pain will go away if we have some option to allow
> ssh to canonicalise its hostnames. I thought we could do it using the
> AI_FQDN[1] getaddrinfo hint but I've realised that this would expose
> users on DHCP networks to new attacks as a spoofed DHCP server can
> control the DNS search order.

[1] http://www.openbsd.org/cgi-bin/man.cgi?query=getaddrinfo&apropos=0&sektion=0&manpath=OpenBSD+Current&arch=i386&format=html

From mouring at eviladmin.org  Fri Apr 12 23:53:29 2013
From: mouring at eviladmin.org (Ben Lindstrom)
Date: Fri, 12 Apr 2013 08:53:29 -0500
Subject: [PATCH] Allow matching HostName against Host entries
In-Reply-To: <alpine.BSO.2.00.1304121217590.24613@natsu.mindrot.org>
References: <20130322015127.GC30194@nu.ryanak.ca>
 <20130408162521.GA21308@nu.ryanak.ca>
 <49B4AA52-D1E2-419E-B022-5C10434B5A39@gmail.com>
 <alpine.BSO.2.00.1304121217590.24613@natsu.mindrot.org>
Message-ID: <AD41C682-5D81-48D5-B925-7E0DEBFAB661@eviladmin.org>


On Apr 11, 2013, at 9:50 PM, Damien Miller <djm at mindrot.org> wrote:

[..]
> A better option might be to allow specification of the suffix order in
> ssh_config itself. E.g.
> 
> HostnameSuffixes mel.int.spectre.com int.spectre.com spectre.com
> 
> to make ssh try resolution of unqualified names by appending each suffix
> in turn and stopping at the first successful lookup. The fully-qualified
> result would then replace the unqualified hostname for the purpose of
> ssh_config matching, known_hosts lookups and certificate name verification.
> 
> What do you think?

Is there no way to pull this information from the resolv.conf file in an universal
way?  It really would suck having yet another location for DNS search paths
to maintain an environment.

And out of interest what would your intent be for those names who still fail this
qualification test?

e.g.

## Where minecraft "host" is really a fast alias to set username, an other
## information to correctly log into generic.server.com without having to
## hand specific them all the time.
Host minecraft   
	User minecraft
	Hostname generic.server.com 


- Ben

From imorgan at nas.nasa.gov  Sat Apr 13 05:06:07 2013
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Fri, 12 Apr 2013 12:06:07 -0700
Subject: [PATCH] Allow matching HostName against Host entries
In-Reply-To: <alpine.BSO.2.00.1304121217590.24613@natsu.mindrot.org>
References: <20130322015127.GC30194@nu.ryanak.ca>
 <20130408162521.GA21308@nu.ryanak.ca>
 <49B4AA52-D1E2-419E-B022-5C10434B5A39@gmail.com>
 <alpine.BSO.2.00.1304121217590.24613@natsu.mindrot.org>
Message-ID: <20130412190607.GB17666@linux124.nas.nasa.gov>

On Thu, Apr 11, 2013 at 21:50:54 -0500, Damien Miller wrote:
> On Wed, 10 Apr 2013, Markus Friedl wrote:
> 
> > I'm not sure if I like it....
> > I don't think it's that useful....
> 
> I can see why someone might want something like it for one particular reason:
> we don't do a fantastic job with unqualified hostnames right now. E.g. my
> resolv.conf might contain something like:
> 
> search mel.int.spectre.com int.spectre.com spectre.com
> 
> .. and I run "ssh www023". Without explicit configuration, I'd end up with
> an unqualified name in my known_hosts that isn't deduplicated with a
> partially, or fully qualified one that might also be in there or come later.
> 
> Furthermore, this makes hostkey certificates much less useful. When creating
> the certificates I have to chose whether to list only the FQDNs of a host
> as principals or whether I should also include unqualified names too. If
> I chose FQDNs that my certificates will not authenticate the host if I've
> connected using an unqualified name. If I chose to list un- and partially-
> qualified names then I open myself to host impersonation attacks (e.g.
> consider a certificate for a server named "www" or "proxy").
> 
> Much of the pain will go away if we have some option to allow
> ssh to canonicalise its hostnames. I thought we could do it using the
> AI_FQDN[1] getaddrinfo hint but I've realised that this would expose
> users on DHCP networks to new attacks as a spoofed DHCP server can
> control the DNS search order.
> 
> A better option might be to allow specification of the suffix order in
> ssh_config itself. E.g.
> 
> HostnameSuffixes mel.int.spectre.com int.spectre.com spectre.com
> 
> to make ssh try resolution of unqualified names by appending each suffix
> in turn and stopping at the first successful lookup. The fully-qualified
> result would then replace the unqualified hostname for the purpose of
> ssh_config matching, known_hosts lookups and certificate name verification.
> 
> What do you think?
> 
> -d
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

The idea sounds interesting, and would address a variety of issues. I'm
a little concerned about "replacing" the unqualified name: Users could
be confronted by StrictHostkeyChecking messages despite the fact that
they have an entry for the unqualified name in their known_hosts files
and used the unqualified name. We would probably still need to match
against the unqualified name, but give preferrence to the FQDN.

It could also cause some consternation if users place the
HostnameSuffixes option at the beginning of their .ssh/config files;
matches against the unqualified name would then fail. This could be
avoided by using the option in a Host * section near the end of the
file, but I expect a lot of people would have to learn the hard way.

On a side note, this might have implications for bz#1169. Since we would
be resolving the hostname earlier, we would also get the IP address of
the target host and thus could apply options based upon that.

-- 
Iain Morgan

From djm at mindrot.org  Sat Apr 13 10:06:50 2013
From: djm at mindrot.org (Damien Miller)
Date: Sat, 13 Apr 2013 10:06:50 +1000 (EST)
Subject: [PATCH] Allow matching HostName against Host entries
In-Reply-To: <AD41C682-5D81-48D5-B925-7E0DEBFAB661@eviladmin.org>
References: <20130322015127.GC30194@nu.ryanak.ca>
 <20130408162521.GA21308@nu.ryanak.ca>
 <49B4AA52-D1E2-419E-B022-5C10434B5A39@gmail.com>
 <alpine.BSO.2.00.1304121217590.24613@natsu.mindrot.org>
 <AD41C682-5D81-48D5-B925-7E0DEBFAB661@eviladmin.org>
Message-ID: <alpine.BSO.2.00.1304130827250.24613@natsu.mindrot.org>

On Fri, 12 Apr 2013, Ben Lindstrom wrote:

>
> Is there no way to pull this information from the resolv.conf file in
> an universal way? It really would suck having yet another location for
> DNS search paths to maintain an environment.

Pulling it from resolv.conf permits attacks from a rogue/hostile DHCP
server again. The main attack here is host subsitution, if a user happens
to have multiple servers with the same hostname but different domains names
(e.g. "www.good.com" and "www.evil.com") then someone who can spoof the 
suffix order could trick a ssh client that used it for canonicalisation
to make a user connect to the wrong host completely transparently.

It's an unlikely scenario for users on small networks, but in a large
organisation with multiple subdomains it could be a useful trick for
an attacker who wants to widen the set of hosts they have compromised.

> And out of interest what would your intent be for those names who
> still fail this qualification test?

They would fall back to regular resolution.

> ## Where minecraft "host" is really a fast alias to set username, an other
> ## information to correctly log into generic.server.com without having to
> ## hand specific them all the time.
> Host minecraft   
> 	User minecraft
> 	Hostname generic.server.com 

So you could do something like:

Host minecraft
	User minecraft
	Hostname generic.server.com

HostnameSuffixes foo.com ext.foo.com

-d

From imorgan at nas.nasa.gov  Sat Apr 13 10:42:33 2013
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Fri, 12 Apr 2013 17:42:33 -0700
Subject: [PATCH] Allow matching HostName against Host entries
In-Reply-To: <alpine.BSO.2.00.1304130827250.24613@natsu.mindrot.org>
References: <20130322015127.GC30194@nu.ryanak.ca>
 <20130408162521.GA21308@nu.ryanak.ca>
 <49B4AA52-D1E2-419E-B022-5C10434B5A39@gmail.com>
 <alpine.BSO.2.00.1304121217590.24613@natsu.mindrot.org>
 <AD41C682-5D81-48D5-B925-7E0DEBFAB661@eviladmin.org>
 <alpine.BSO.2.00.1304130827250.24613@natsu.mindrot.org>
Message-ID: <20130413004233.GC17666@linux124.nas.nasa.gov>

On Fri, Apr 12, 2013 at 19:06:50 -0500, Damien Miller wrote:
> On Fri, 12 Apr 2013, Ben Lindstrom wrote:
> 
> >
> > Is there no way to pull this information from the resolv.conf file in
> > an universal way? It really would suck having yet another location for
> > DNS search paths to maintain an environment.
> 
> Pulling it from resolv.conf permits attacks from a rogue/hostile DHCP
> server again. The main attack here is host subsitution, if a user happens
> to have multiple servers with the same hostname but different domains names
> (e.g. "www.good.com" and "www.evil.com") then someone who can spoof the 
> suffix order could trick a ssh client that used it for canonicalisation
> to make a user connect to the wrong host completely transparently.
> 
> It's an unlikely scenario for users on small networks, but in a large
> organisation with multiple subdomains it could be a useful trick for
> an attacker who wants to widen the set of hosts they have compromised.
> 
> > And out of interest what would your intent be for those names who
> > still fail this qualification test?
> 
> They would fall back to regular resolution.
> 
> > ## Where minecraft "host" is really a fast alias to set username, an other
> > ## information to correctly log into generic.server.com without having to
> > ## hand specific them all the time.
> > Host minecraft   
> > 	User minecraft
> > 	Hostname generic.server.com 
> 
> So you could do something like:
> 
> Host minecraft
> 	User minecraft
> 	Hostname generic.server.com
> 
> HostnameSuffixes foo.com ext.foo.com
> 

I think you meant:

Host minecraft
	User minecraft
	Hostname generic.server.com

Host *
	HostnameSuffixes foo.com ext.foo.com
-- 
Iain Morgan

From des at des.no  Sun Apr 14 23:07:17 2013
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Sun, 14 Apr 2013 15:07:17 +0200
Subject: "no such identity"
In-Reply-To: <CALDDTe1FaFkoMZ=bNvTk7070yJd2dc9VWkjf3RO2hTJt3dQimg@mail.gmail.com>
 (Darren Tucker's message of "Mon, 8 Apr 2013 19:41:40 +1000")
References: <86hajqpdpz.fsf@ds4.des.no> <20130401172251.GB47549@juniper.net>
 <20130402120840.GA29590@calimero.vinschen.de>
 <20130402131500.GA29515@gate.dtucker.net>
 <20130402132655.GA18060@calimero.vinschen.de>
 <20130404234952.GA28615@gate.dtucker.net>
 <20130405003653.GA2583@gate.dtucker.net>
 <20130405075559.GA30526@calimero.vinschen.de>
 <CALDDTe1FaFkoMZ=bNvTk7070yJd2dc9VWkjf3RO2hTJt3dQimg@mail.gmail.com>
Message-ID: <86ip3pclbu.fsf@ds4.des.no>

Darren Tucker <dtucker at zip.com.au> writes:
> Corinna Vinschen <vinschen at redhat.com> writes:
> > It seems weird to log a disconnect as error.  Is that really the
> > right thing to do?
> Hm.  I've reopend the bug
> (https://bugzilla.mindrot.org/show_bug.cgi?id=2057) to take a look.

Can you make sure this is included in 6.2p2 as well?

DES
-- 
Dag-Erling Sm?rgrav - des at des.no

From keisial at gmail.com  Mon Apr 15 00:29:38 2013
From: keisial at gmail.com (=?windows-1252?Q?=C1ngel_Gonz=E1lez?=)
Date: Sun, 14 Apr 2013 16:29:38 +0200
Subject: [PATCH] Allow matching HostName against Host entries
In-Reply-To: <20130411050606.GB13960@apb-laptoy.apb.alt.za>
References: <20130322015127.GC30194@nu.ryanak.ca>
 <20130408162521.GA21308@nu.ryanak.ca>
 <FF95B9E7-0991-483F-B8CB-28B8E5F5995E@offwriting.org>
 <20835.27221.466113.996877@nu.ryanak.ca>
 <20130409190042.GA8305@linux124.nas.nasa.gov>
 <20836.29337.739297.965797@nu.ryanak.ca>
 <0353A032-09F8-4AB7-A928-E03D1D4CCA21@offwriting.org>
 <20130411050606.GB13960@apb-laptoy.apb.alt.za>
Message-ID: <516ABD52.3040107@gmail.com>

On 11/04/13 07:06, Alan Barrett wrote:
> I would find the proposed MatchHostName feature very useful. It would
> allow me to remove a significant amount of duplication from my ssh
> config files.
>
> On Tue, 09 Apr 2013, Ben Lindstrom wrote:
>> My major complaint is this one option changes how the ssh_config is
>> parsed. It just takes one admin to decided he likes it to break
>> everyone's
>> setup..
>
> Sure. The admin should not put "MatchHostname yes" in the system ssh
> config file; it's something that users should be able to choose to put
> in their own config files.
>
>> e.g.
>>
>> host foo
>> user specialaccount
>> hostname foo.bar.com
>>
>> host *.bar.com
>> user normaluser
>>
>> Which is horrible as it *DOES* break it if you enable that switch.
What about changing the name of the ?hostname? option?

So you would replace hostname above with eg. ?expandhost?
host foo
expandhost foo.bar.com

The configuration option expandhost would work just like hostname, but
making foo.bar.com match with the following configuration entries.

As it's a new setting, old config files won't be affected like
MatchHostname if the boolean field is enabled (globally or locally
without realising the semantic change for some later entry).


From apb at cequrux.com  Mon Apr 15 16:57:14 2013
From: apb at cequrux.com (Alan Barrett)
Date: Mon, 15 Apr 2013 08:57:14 +0200
Subject: [PATCH] Allow matching HostName against Host entries
In-Reply-To: <alpine.BSO.2.00.1304121217590.24613@natsu.mindrot.org>
References: <20130322015127.GC30194@nu.ryanak.ca>
 <20130408162521.GA21308@nu.ryanak.ca>
 <49B4AA52-D1E2-419E-B022-5C10434B5A39@gmail.com>
 <alpine.BSO.2.00.1304121217590.24613@natsu.mindrot.org>
Message-ID: <20130415065713.GA17286@apb-laptoy.apb.alt.za>

On Fri, 12 Apr 2013, Damien Miller wrote:
>A better option might be to allow specification of the suffix order in
>ssh_config itself. E.g.
>
>HostnameSuffixes mel.int.spectre.com int.spectre.com spectre.com

That would help in many cases, but not in all cases.

I have aliases in ssh.conf that do not resemble the FQDN of the 
host (e.g. "dev" => "server123.department.company.tld").  Even if 
they do match the first label of the FQDN, I might prefer explicit 
configuration to some kind of HostnameSuffixes search.

I want something that will significantly reduce the amount of 
duplication in configurations like this:

     Host dev
         HostName server123.dept.company.tld
         HostKeyAlias server123.dept.company.tld
         UserName U34567
         IdentityFile "~/.ssh/keys/key-for-most-servers-at-company"
         # maybe more options duplicated here

     Host test
         HostName server475.dept.company.tld
         HostKeyAlias server475.dept.company.tld
         UserName U34567
         IdentityFile "~/.ssh/keys/key-for-most-servers-at-company"
         # maybe more options duplicated here

     Host prod
         HostName server931.dept.company.tld
         HostKeyAlias server931.dept.company.tld
         UserName U34567
         IdentityFile "~/.ssh/keys/key-for-production-servers"
         # maybe more options duplicated here

     Host server931.dept.company.tld
         IdentityFile "~/.ssh/keys/key-for-production-servers"

     Host *.dept.company.tld
         UserName U34567
         IdentityFile "~/.ssh/keys/key-for-most-servers-at-company"
         # maybe more options specified here

"MatchHostName yes" would work fine for me, but I might prefer 
different syntax, like the "ExpandHostName" idea that was 
suggested in another sub-thread.  Then I could replace the above 
configuration with this:

     Host dev
         ExpandHostName server123.dept.company.tld

     Host test
         ExpandHostName server475.dept.company.tld

     Host prod
         ExpandHostName server931.dept.company.tld

     Host server931.dept.company.tld
         IdentityFile "~/.ssh/keys/key-for-production-servers"

     Host *.dept.company.tld
         UserName U34567
         IdentityFile "~/.ssh/keys/key-for-most-servers-at-company"
         # maybe more options specified here

--apb (Alan Barrett)

From apb at cequrux.com  Mon Apr 15 16:58:55 2013
From: apb at cequrux.com (Alan Barrett)
Date: Mon, 15 Apr 2013 08:58:55 +0200
Subject: [PATCH] Allow matching HostName against Host entries
In-Reply-To: <20838.60930.13479.722946@nu.ryanak.ca>
References: <20130322015127.GC30194@nu.ryanak.ca>
 <20130408162521.GA21308@nu.ryanak.ca>
 <FF95B9E7-0991-483F-B8CB-28B8E5F5995E@offwriting.org>
 <20835.27221.466113.996877@nu.ryanak.ca>
 <20130409190042.GA8305@linux124.nas.nasa.gov>
 <20836.29337.739297.965797@nu.ryanak.ca>
 <0353A032-09F8-4AB7-A928-E03D1D4CCA21@offwriting.org>
 <20130411050606.GB13960@apb-laptoy.apb.alt.za>
 <20130411163714.GA17666@linux124.nas.nasa.gov>
 <20838.60930.13479.722946@nu.ryanak.ca>
Message-ID: <20130415065855.GB17286@apb-laptoy.apb.alt.za>

On Thu, 11 Apr 2013, Ryan Kavanagh wrote:
>You would probably meant something along the lines of:
> [...]
>But again, anything your sysadmin does can
>break your own configs or worse.

Yes, thank you for the correction.

--apb (Alan Barrett)

From singh.ravipratap88 at gmail.com  Tue Apr 16 17:36:07 2013
From: singh.ravipratap88 at gmail.com (RAVI PRATAP Singh)
Date: Tue, 16 Apr 2013 13:06:07 +0530
Subject: Need your inputs on issue: stale sessions in openssh
Message-ID: <CAF-xSwJHte09tcyUS0BzVsujGT2pFzVkD6S5sPTdHsKCC_1CGA@mail.gmail.com>

Hi Folks,

I am working on openssh-5.5p1.I am facing an issue in a scenario described
below.

Client has established a ssh connection to the server.
Due to no activity at the client , the shell got killed once the timeout
reached.
As shell got killed , the server sends a close to client and waits for
receiving the ack from client.
But somehow, the client is not sending the close.
Now as per RFC, ssh process on server would get killed once it receives
close(ack) from client, so in this case,
server is waiting for the signal and thus the session got stale.

Could someone please suggest me what should I do for this case.

What I thought was if shell got killed due to timeout, the client can't do
anything , so the server should not wait for close(ack) from the client,
rather it just should get killed once it has sent the close to the client.
Another was to wait for some time and then get killed, but then we would
need to create a timer and maintaining timers for all ssh processes is not
feasible.

Please provide your suggestions and help me in resolving this issue.
Thanks in advance.

Regards

From john.m.olsson at ericsson.com  Tue Apr 16 19:12:15 2013
From: john.m.olsson at ericsson.com (John Olsson M)
Date: Tue, 16 Apr 2013 09:12:15 +0000
Subject: Time zone for chrooted internal-sftp?
In-Reply-To: <alpine.BSO.2.00.1303210456110.17602@natsu.mindrot.org>
References: <56C5269167653F4EB997E85F8CBB3299140014@ESESSMB301.ericsson.se>
 <alpine.BSO.2.00.1303210456110.17602@natsu.mindrot.org>
Message-ID: <56C5269167653F4EB997E85F8CBB32991680BE@ESESSMB301.ericsson.se>

Sorry for not replying earlier. :(

Thank you!

/John

-----Original Message-----
From: Damien Miller [mailto:djm at mindrot.org] 
Sent: den 20 mars 2013 18:57
To: John Olsson M
Cc: openssh-unix-dev at mindrot.org
Subject: Re: Time zone for chrooted internal-sftp?

On Wed, 13 Mar 2013, John Olsson M wrote:

> Hi,
>
> A question regarding chroot, internal-sftp, and time zones: Is it 
> possible to get the time stamps presented by the chrooted 
> internal-sftp to always be aligned with the system global time zone 
> setting?
>
> What is the reason this not done by default, that is couldn't the 
> chrooted internal-sftp inherit the time zone information from the SSH 
> daemon?

I'd expect that it would, but maybe something gets reset after fork().
You might want to try this patch to see if it makes any difference.

Index: session.c
===================================================================
RCS file: /var/cvs/openssh/session.c,v
retrieving revision 1.416
diff -u -p -r1.416 session.c
--- session.c	15 Mar 2013 00:22:37 -0000	1.416
+++ session.c	20 Mar 2013 17:55:21 -0000
@@ -58,6 +58,7 @@
 #include <stdio.h>
 #include <stdlib.h>
 #include <string.h>
+#include <time.h>
 #include <unistd.h>
 
 #include "openbsd-compat/sys-queue.h"
@@ -1461,6 +1462,7 @@ safely_chroot(const char *path, uid_t ui
 
 	}
 
+	tzset();
 	if (chdir(path) == -1)
 		fatal("Unable to chdir to chroot path \"%s\": "
 		    "%s", path, strerror(errno));
Index: sshd.c
===================================================================
RCS file: /var/cvs/openssh/sshd.c,v
retrieving revision 1.420
diff -u -p -r1.420 sshd.c
--- sshd.c	12 Feb 2013 00:04:48 -0000	1.420
+++ sshd.c	20 Mar 2013 17:55:41 -0000
@@ -607,6 +607,7 @@ privsep_preauth_child(void)
 	arc4random_stir();
 	arc4random_buf(rnd, sizeof(rnd));
 	RAND_seed(rnd, sizeof(rnd));
+	tzset();
 
 	/* Demote the private keys to public keys. */
 	demote_sensitive_data();

From john.m.olsson at ericsson.com  Tue Apr 16 19:14:06 2013
From: john.m.olsson at ericsson.com (John Olsson M)
Date: Tue, 16 Apr 2013 09:14:06 +0000
Subject: Time zone for chrooted internal-sftp?
In-Reply-To: <5149C54A.8000500@gmail.com>
References: <56C5269167653F4EB997E85F8CBB3299140014@ESESSMB301.ericsson.se>
 <5149C54A.8000500@gmail.com>
Message-ID: <56C5269167653F4EB997E85F8CBB329916810E@ESESSMB301.ericsson.se>

> Are the relevant zoneinfo files available inside the chroot?

No. We do not want to expose anything more than necessary. Hence my question

"What is the reason this not done by default, that is couldn't the chrooted internal-sftp inherit the time zone information from the SSH daemon?" :)


/John

-----Original Message-----
From: ?ngel Gonz?lez [mailto:keisial at gmail.com] 
Sent: den 20 mars 2013 15:19
To: John Olsson M
Cc: openssh-unix-dev at mindrot.org
Subject: Re: Time zone for chrooted internal-sftp?

On 13/03/13 11:24, John Olsson M wrote:
> Hi,
>
> A question regarding chroot, internal-sftp, and time zones: Is it possible to get the time stamps presented by the chrooted internal-sftp to always be aligned with the system global time zone setting?
>
> What is the reason this not done by default, that is couldn't the chrooted internal-sftp inherit the time zone information from the SSH daemon?
>
> /John
Are the relevant zoneinfo files available inside the chroot?


From des at des.no  Tue Apr 16 19:21:25 2013
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Tue, 16 Apr 2013 11:21:25 +0200
Subject: Time zone for chrooted internal-sftp?
In-Reply-To: <56C5269167653F4EB997E85F8CBB329916810E@ESESSMB301.ericsson.se>
 (John Olsson M.'s message of "Tue, 16 Apr 2013 09:14:06 +0000")
References: <56C5269167653F4EB997E85F8CBB3299140014@ESESSMB301.ericsson.se>
 <5149C54A.8000500@gmail.com>
 <56C5269167653F4EB997E85F8CBB329916810E@ESESSMB301.ericsson.se>
Message-ID: <86ip3m25m2.fsf@ds4.des.no>

John Olsson M <john.m.olsson at ericsson.com> writes:
> What is the reason this not done by default, that is couldn't the
> chrooted internal-sftp inherit the time zone information from the SSH
> daemon?

That's outside OpenSSH's control.  You'll have to talk to your operating
system vendor.

DES
-- 
Dag-Erling Sm?rgrav - des at des.no

From djm at mindrot.org  Tue Apr 16 21:37:24 2013
From: djm at mindrot.org (Damien Miller)
Date: Tue, 16 Apr 2013 21:37:24 +1000 (EST)
Subject: Time zone for chrooted internal-sftp?
In-Reply-To: <56C5269167653F4EB997E85F8CBB32991680BE@ESESSMB301.ericsson.se>
References: <56C5269167653F4EB997E85F8CBB3299140014@ESESSMB301.ericsson.se>
 <alpine.BSO.2.00.1303210456110.17602@natsu.mindrot.org>
 <56C5269167653F4EB997E85F8CBB32991680BE@ESESSMB301.ericsson.se>
Message-ID: <alpine.BSO.2.00.1304162137210.8512@natsu.mindrot.org>

it worked?

On Tue, 16 Apr 2013, John Olsson M wrote:

> Sorry for not replying earlier. :(
> 
> Thank you!
> 
> /John
> 
> -----Original Message-----
> From: Damien Miller [mailto:djm at mindrot.org] 
> Sent: den 20 mars 2013 18:57
> To: John Olsson M
> Cc: openssh-unix-dev at mindrot.org
> Subject: Re: Time zone for chrooted internal-sftp?
> 
> On Wed, 13 Mar 2013, John Olsson M wrote:
> 
> > Hi,
> >
> > A question regarding chroot, internal-sftp, and time zones: Is it 
> > possible to get the time stamps presented by the chrooted 
> > internal-sftp to always be aligned with the system global time zone 
> > setting?
> >
> > What is the reason this not done by default, that is couldn't the 
> > chrooted internal-sftp inherit the time zone information from the SSH 
> > daemon?
> 
> I'd expect that it would, but maybe something gets reset after fork().
> You might want to try this patch to see if it makes any difference.
> 
> Index: session.c
> ===================================================================
> RCS file: /var/cvs/openssh/session.c,v
> retrieving revision 1.416
> diff -u -p -r1.416 session.c
> --- session.c	15 Mar 2013 00:22:37 -0000	1.416
> +++ session.c	20 Mar 2013 17:55:21 -0000
> @@ -58,6 +58,7 @@
>  #include <stdio.h>
>  #include <stdlib.h>
>  #include <string.h>
> +#include <time.h>
>  #include <unistd.h>
>  
>  #include "openbsd-compat/sys-queue.h"
> @@ -1461,6 +1462,7 @@ safely_chroot(const char *path, uid_t ui
>  
>  	}
>  
> +	tzset();
>  	if (chdir(path) == -1)
>  		fatal("Unable to chdir to chroot path \"%s\": "
>  		    "%s", path, strerror(errno));
> Index: sshd.c
> ===================================================================
> RCS file: /var/cvs/openssh/sshd.c,v
> retrieving revision 1.420
> diff -u -p -r1.420 sshd.c
> --- sshd.c	12 Feb 2013 00:04:48 -0000	1.420
> +++ sshd.c	20 Mar 2013 17:55:41 -0000
> @@ -607,6 +607,7 @@ privsep_preauth_child(void)
>  	arc4random_stir();
>  	arc4random_buf(rnd, sizeof(rnd));
>  	RAND_seed(rnd, sizeof(rnd));
> +	tzset();
>  
>  	/* Demote the private keys to public keys. */
>  	demote_sensitive_data();
> 

From rak at debian.org  Wed Apr 17 01:52:48 2013
From: rak at debian.org (Ryan Kavanagh)
Date: Tue, 16 Apr 2013 11:52:48 -0400
Subject: [PATCH] Allow matching HostName against Host entries
In-Reply-To: <516ABD52.3040107@gmail.com>
References: <20130322015127.GC30194@nu.ryanak.ca>
 <20130408162521.GA21308@nu.ryanak.ca>
 <FF95B9E7-0991-483F-B8CB-28B8E5F5995E@offwriting.org>
 <20835.27221.466113.996877@nu.ryanak.ca>
 <20130409190042.GA8305@linux124.nas.nasa.gov>
 <20836.29337.739297.965797@nu.ryanak.ca>
 <0353A032-09F8-4AB7-A928-E03D1D4CCA21@offwriting.org>
 <20130411050606.GB13960@apb-laptoy.apb.alt.za>
 <516ABD52.3040107@gmail.com>
Message-ID: <20845.29648.741327.384137@nu.ryanak.ca>

On Sunday, April 14, 2013 at 16:29:38 +0200, ?ngel Gonz?lez wrote:
> So you would replace hostname above with eg. ?expandhost?
> host foo
> expandhost foo.bar.com
> 
> The configuration option expandhost would work just like hostname, but
> making foo.bar.com match with the following configuration entries.

I think this is a much cleaner approach than what I proposed; users
don't need to worry about MatchHostName somehow clobbering their
config file, it requires setting one option (ExpandHost) as opposed to
two (HostName & MatchHostName), etc. Seeing that this option had
support in another subthread, I'll update my patch to use ExpandHost
instead.

To those who objected to my initial patch, does this change address
your concerns?

Best wishes,
Ryan

-- 
|_)|_/	Ryan Kavanagh		| Debian Developer
| \| \	http://ryanak.ca/	| GPG Key 4A11C97A

From mouring at eviladmin.org  Wed Apr 17 02:02:25 2013
From: mouring at eviladmin.org (Ben Lindstrom)
Date: Tue, 16 Apr 2013 11:02:25 -0500
Subject: [PATCH] Allow matching HostName against Host entries
In-Reply-To: <20845.29648.741327.384137@nu.ryanak.ca>
References: <20130322015127.GC30194@nu.ryanak.ca>
 <20130408162521.GA21308@nu.ryanak.ca>
 <FF95B9E7-0991-483F-B8CB-28B8E5F5995E@offwriting.org>
 <20835.27221.466113.996877@nu.ryanak.ca>
 <20130409190042.GA8305@linux124.nas.nasa.gov>
 <20836.29337.739297.965797@nu.ryanak.ca>
 <0353A032-09F8-4AB7-A928-E03D1D4CCA21@offwriting.org>
 <20130411050606.GB13960@apb-laptoy.apb.alt.za> <516ABD52.3040107@gmail.com>
 <20845.29648.741327.384137@nu.ryanak.ca>
Message-ID: <4D416AF3-4BDC-496E-B664-FEBD3D2DB267@eviladmin.org>


On Apr 16, 2013, at 10:52 AM, Ryan Kavanagh <rak at debian.org> wrote:

> On Sunday, April 14, 2013 at 16:29:38 +0200, ?ngel Gonz?lez wrote:
>> So you would replace hostname above with eg. ?expandhost?
>> host foo
>> expandhost foo.bar.com
>> 
>> The configuration option expandhost would work just like hostname, but
>> making foo.bar.com match with the following configuration entries.
> 
> I think this is a much cleaner approach than what I proposed; users
> don't need to worry about MatchHostName somehow clobbering their
> config file, it requires setting one option (ExpandHost) as opposed to
> two (HostName & MatchHostName), etc. Seeing that this option had
> support in another subthread, I'll update my patch to use ExpandHost
> instead.
> 
> To those who objected to my initial patch, does this change address
> your concerns?

I have no more objections anymore.

- Ben

From plautrba at redhat.com  Wed Apr 17 02:07:47 2013
From: plautrba at redhat.com (Petr Lautrbach)
Date: Tue, 16 Apr 2013 18:07:47 +0200
Subject: update config.guess and config.sub to support aarch64
Message-ID: <516D7753.1080407@redhat.com>

Hello,

would it be possible to update config.sub and config.guess to the latest versions (or at least version
from automake-1.13.1) in order to support new architectures based on the ARM 64 bit CPU?


Patch: http://plautrba.fedorapeople.org/openssh/openssh-latest-config.sub-config.guess.patch
Related Fedora bug: https://bugzilla.redhat.com/show_bug.cgi?id=926284


Thanks,

Petr

From djm at mindrot.org  Wed Apr 17 21:46:48 2013
From: djm at mindrot.org (Damien Miller)
Date: Wed, 17 Apr 2013 21:46:48 +1000 (EST)
Subject: update config.guess and config.sub to support aarch64
In-Reply-To: <516D7753.1080407@redhat.com>
References: <516D7753.1080407@redhat.com>
Message-ID: <alpine.BSO.2.00.1304172134010.8512@natsu.mindrot.org>

On Tue, 16 Apr 2013, Petr Lautrbach wrote:

> Hello,
> 
> would it be possible to update config.sub and config.guess to the latest
> versions (or at least version
> from automake-1.13.1) in order to support new architectures based on the ARM
> 64 bit CPU?

I'm not going to import GPL3 code into the OpenSSH source distribution.
Fortunately it looks like the arm64 changes were added before the
license got updated.

Does this have everything you need?

Index: config.guess
===================================================================
RCS file: /var/cvs/openssh/config.guess,v
retrieving revision 1.15
diff -u -p -r1.15 config.guess
--- config.guess	26 Jan 2011 20:32:14 -0000	1.15
+++ config.guess	17 Apr 2013 11:39:19 -0000
@@ -2,9 +2,9 @@
 # Attempt to guess a canonical system name.
 #   Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
 #   2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010,
-#   2011 Free Software Foundation, Inc.
+#   2011, 2012, 2013 Free Software Foundation, Inc.
 
-timestamp='2011-01-23'
+timestamp='2012-12-23'
 
 # This file is free software; you can redistribute it and/or modify it
 # under the terms of the GNU General Public License as published by
@@ -17,9 +17,7 @@ timestamp='2011-01-23'
 # General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA
-# 02110-1301, USA.
+# along with this program; if not, see <http://www.gnu.org/licenses/>.
 #
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
@@ -57,8 +55,8 @@ GNU config.guess ($timestamp)
 
 Originally written by Per Bothner.
 Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000,
-2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011 Free
-Software Foundation, Inc.
+2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011,
+2012, 2013 Free Software Foundation, Inc.
 
 This is free software; see the source for copying conditions.  There is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
@@ -145,7 +143,7 @@ UNAME_VERSION=`(uname -v) 2>/dev/null` |
 case "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in
     *:NetBSD:*:*)
 	# NetBSD (nbsd) targets should (where applicable) match one or
-	# more of the tupples: *-*-netbsdelf*, *-*-netbsdaout*,
+	# more of the tuples: *-*-netbsdelf*, *-*-netbsdaout*,
 	# *-*-netbsdecoff* and *-*-netbsd*.  For targets that recently
 	# switched to ELF, *-*-netbsd* would select the old
 	# object file format.  This provides both forward
@@ -181,7 +179,7 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:$
 		fi
 		;;
 	    *)
-	        os=netbsd
+		os=netbsd
 		;;
 	esac
 	# The OS release
@@ -202,6 +200,10 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:$
 	# CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM is used.
 	echo "${machine}-${os}${release}"
 	exit ;;
+    *:Bitrig:*:*)
+	UNAME_MACHINE_ARCH=`arch | sed 's/Bitrig.//'`
+	echo ${UNAME_MACHINE_ARCH}-unknown-bitrig${UNAME_RELEASE}
+	exit ;;
     *:OpenBSD:*:*)
 	UNAME_MACHINE_ARCH=`arch | sed 's/OpenBSD.//'`
 	echo ${UNAME_MACHINE_ARCH}-unknown-openbsd${UNAME_RELEASE}
@@ -224,7 +226,7 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:$
 		UNAME_RELEASE=`/usr/sbin/sizer -v | awk '{print $3}'`
 		;;
 	*5.*)
-	        UNAME_RELEASE=`/usr/sbin/sizer -v | awk '{print $4}'`
+		UNAME_RELEASE=`/usr/sbin/sizer -v | awk '{print $4}'`
 		;;
 	esac
 	# According to Compaq, /usr/sbin/psrinfo has been available on
@@ -299,12 +301,12 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:$
 	echo s390-ibm-zvmoe
 	exit ;;
     *:OS400:*:*)
-        echo powerpc-ibm-os400
+	echo powerpc-ibm-os400
 	exit ;;
     arm:RISC*:1.[012]*:*|arm:riscix:1.[012]*:*)
 	echo arm-acorn-riscix${UNAME_RELEASE}
 	exit ;;
-    arm:riscos:*:*|arm:RISCOS:*:*)
+    arm*:riscos:*:*|arm*:RISCOS:*:*)
 	echo arm-unknown-riscos
 	exit ;;
     SR2?01:HI-UX/MPP:*:* | SR8000:HI-UX/MPP:*:*)
@@ -398,23 +400,23 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:$
     # MiNT.  But MiNT is downward compatible to TOS, so this should
     # be no problem.
     atarist[e]:*MiNT:*:* | atarist[e]:*mint:*:* | atarist[e]:*TOS:*:*)
-        echo m68k-atari-mint${UNAME_RELEASE}
+	echo m68k-atari-mint${UNAME_RELEASE}
 	exit ;;
     atari*:*MiNT:*:* | atari*:*mint:*:* | atarist[e]:*TOS:*:*)
 	echo m68k-atari-mint${UNAME_RELEASE}
-        exit ;;
+	exit ;;
     *falcon*:*MiNT:*:* | *falcon*:*mint:*:* | *falcon*:*TOS:*:*)
-        echo m68k-atari-mint${UNAME_RELEASE}
+	echo m68k-atari-mint${UNAME_RELEASE}
 	exit ;;
     milan*:*MiNT:*:* | milan*:*mint:*:* | *milan*:*TOS:*:*)
-        echo m68k-milan-mint${UNAME_RELEASE}
-        exit ;;
+	echo m68k-milan-mint${UNAME_RELEASE}
+	exit ;;
     hades*:*MiNT:*:* | hades*:*mint:*:* | *hades*:*TOS:*:*)
-        echo m68k-hades-mint${UNAME_RELEASE}
-        exit ;;
+	echo m68k-hades-mint${UNAME_RELEASE}
+	exit ;;
     *:*MiNT:*:* | *:*mint:*:* | *:*TOS:*:*)
-        echo m68k-unknown-mint${UNAME_RELEASE}
-        exit ;;
+	echo m68k-unknown-mint${UNAME_RELEASE}
+	exit ;;
     m68k:machten:*:*)
 	echo m68k-apple-machten${UNAME_RELEASE}
 	exit ;;
@@ -484,8 +486,8 @@ EOF
 	echo m88k-motorola-sysv3
 	exit ;;
     AViiON:dgux:*:*)
-        # DG/UX returns AViiON for all architectures
-        UNAME_PROCESSOR=`/usr/bin/uname -p`
+	# DG/UX returns AViiON for all architectures
+	UNAME_PROCESSOR=`/usr/bin/uname -p`
 	if [ $UNAME_PROCESSOR = mc88100 ] || [ $UNAME_PROCESSOR = mc88110 ]
 	then
 	    if [ ${TARGET_BINARY_INTERFACE}x = m88kdguxelfx ] || \
@@ -498,7 +500,7 @@ EOF
 	else
 	    echo i586-dg-dgux${UNAME_RELEASE}
 	fi
- 	exit ;;
+	exit ;;
     M88*:DolphinOS:*:*)	# DolphinOS (SVR3)
 	echo m88k-dolphin-sysv3
 	exit ;;
@@ -598,52 +600,52 @@ EOF
 	    9000/[678][0-9][0-9])
 		if [ -x /usr/bin/getconf ]; then
 		    sc_cpu_version=`/usr/bin/getconf SC_CPU_VERSION 2>/dev/null`
-                    sc_kernel_bits=`/usr/bin/getconf SC_KERNEL_BITS 2>/dev/null`
-                    case "${sc_cpu_version}" in
-                      523) HP_ARCH="hppa1.0" ;; # CPU_PA_RISC1_0
-                      528) HP_ARCH="hppa1.1" ;; # CPU_PA_RISC1_1
-                      532)                      # CPU_PA_RISC2_0
-                        case "${sc_kernel_bits}" in
-                          32) HP_ARCH="hppa2.0n" ;;
-                          64) HP_ARCH="hppa2.0w" ;;
+		    sc_kernel_bits=`/usr/bin/getconf SC_KERNEL_BITS 2>/dev/null`
+		    case "${sc_cpu_version}" in
+		      523) HP_ARCH="hppa1.0" ;; # CPU_PA_RISC1_0
+		      528) HP_ARCH="hppa1.1" ;; # CPU_PA_RISC1_1
+		      532)                      # CPU_PA_RISC2_0
+			case "${sc_kernel_bits}" in
+			  32) HP_ARCH="hppa2.0n" ;;
+			  64) HP_ARCH="hppa2.0w" ;;
 			  '') HP_ARCH="hppa2.0" ;;   # HP-UX 10.20
-                        esac ;;
-                    esac
+			esac ;;
+		    esac
 		fi
 		if [ "${HP_ARCH}" = "" ]; then
 		    eval $set_cc_for_build
-		    sed 's/^              //' << EOF >$dummy.c
+		    sed 's/^		//' << EOF >$dummy.c
+
+		#define _HPUX_SOURCE
+		#include <stdlib.h>
+		#include <unistd.h>
 
-              #define _HPUX_SOURCE
-              #include <stdlib.h>
-              #include <unistd.h>
-
-              int main ()
-              {
-              #if defined(_SC_KERNEL_BITS)
-                  long bits = sysconf(_SC_KERNEL_BITS);
-              #endif
-                  long cpu  = sysconf (_SC_CPU_VERSION);
-
-                  switch (cpu)
-              	{
-              	case CPU_PA_RISC1_0: puts ("hppa1.0"); break;
-              	case CPU_PA_RISC1_1: puts ("hppa1.1"); break;
-              	case CPU_PA_RISC2_0:
-              #if defined(_SC_KERNEL_BITS)
-              	    switch (bits)
-              		{
-              		case 64: puts ("hppa2.0w"); break;
-              		case 32: puts ("hppa2.0n"); break;
-              		default: puts ("hppa2.0"); break;
-              		} break;
-              #else  /* !defined(_SC_KERNEL_BITS) */
-              	    puts ("hppa2.0"); break;
-              #endif
-              	default: puts ("hppa1.0"); break;
-              	}
-                  exit (0);
-              }
+		int main ()
+		{
+		#if defined(_SC_KERNEL_BITS)
+		    long bits = sysconf(_SC_KERNEL_BITS);
+		#endif
+		    long cpu  = sysconf (_SC_CPU_VERSION);
+
+		    switch (cpu)
+			{
+			case CPU_PA_RISC1_0: puts ("hppa1.0"); break;
+			case CPU_PA_RISC1_1: puts ("hppa1.1"); break;
+			case CPU_PA_RISC2_0:
+		#if defined(_SC_KERNEL_BITS)
+			    switch (bits)
+				{
+				case 64: puts ("hppa2.0w"); break;
+				case 32: puts ("hppa2.0n"); break;
+				default: puts ("hppa2.0"); break;
+				} break;
+		#else  /* !defined(_SC_KERNEL_BITS) */
+			    puts ("hppa2.0"); break;
+		#endif
+			default: puts ("hppa1.0"); break;
+			}
+		    exit (0);
+		}
 EOF
 		    (CCOPTS= $CC_FOR_BUILD -o $dummy $dummy.c 2>/dev/null) && HP_ARCH=`$dummy`
 		    test -z "$HP_ARCH" && HP_ARCH=hppa
@@ -734,22 +736,22 @@ EOF
 	exit ;;
     C1*:ConvexOS:*:* | convex:ConvexOS:C1*:*)
 	echo c1-convex-bsd
-        exit ;;
+	exit ;;
     C2*:ConvexOS:*:* | convex:ConvexOS:C2*:*)
 	if getsysinfo -f scalar_acc
 	then echo c32-convex-bsd
 	else echo c2-convex-bsd
 	fi
-        exit ;;
+	exit ;;
     C34*:ConvexOS:*:* | convex:ConvexOS:C34*:*)
 	echo c34-convex-bsd
-        exit ;;
+	exit ;;
     C38*:ConvexOS:*:* | convex:ConvexOS:C38*:*)
 	echo c38-convex-bsd
-        exit ;;
+	exit ;;
     C4*:ConvexOS:*:* | convex:ConvexOS:C4*:*)
 	echo c4-convex-bsd
-        exit ;;
+	exit ;;
     CRAY*Y-MP:*:*:*)
 	echo ymp-cray-unicos${UNAME_RELEASE} | sed -e 's/\.[^.]*$/.X/'
 	exit ;;
@@ -773,14 +775,14 @@ EOF
 	exit ;;
     F30[01]:UNIX_System_V:*:* | F700:UNIX_System_V:*:*)
 	FUJITSU_PROC=`uname -m | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz'`
-        FUJITSU_SYS=`uname -p | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz' | sed -e 's/\///'`
-        FUJITSU_REL=`echo ${UNAME_RELEASE} | sed -e 's/ /_/'`
-        echo "${FUJITSU_PROC}-fujitsu-${FUJITSU_SYS}${FUJITSU_REL}"
-        exit ;;
+	FUJITSU_SYS=`uname -p | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz' | sed -e 's/\///'`
+	FUJITSU_REL=`echo ${UNAME_RELEASE} | sed -e 's/ /_/'`
+	echo "${FUJITSU_PROC}-fujitsu-${FUJITSU_SYS}${FUJITSU_REL}"
+	exit ;;
     5000:UNIX_System_V:4.*:*)
-        FUJITSU_SYS=`uname -p | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz' | sed -e 's/\///'`
-        FUJITSU_REL=`echo ${UNAME_RELEASE} | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz' | sed -e 's/ /_/'`
-        echo "sparc-fujitsu-${FUJITSU_SYS}${FUJITSU_REL}"
+	FUJITSU_SYS=`uname -p | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz' | sed -e 's/\///'`
+	FUJITSU_REL=`echo ${UNAME_RELEASE} | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz' | sed -e 's/ /_/'`
+	echo "sparc-fujitsu-${FUJITSU_SYS}${FUJITSU_REL}"
 	exit ;;
     i*86:BSD/386:*:* | i*86:BSD/OS:*:* | *:Ascend\ Embedded/OS:*:*)
 	echo ${UNAME_MACHINE}-pc-bsdi${UNAME_RELEASE}
@@ -792,30 +794,35 @@ EOF
 	echo ${UNAME_MACHINE}-unknown-bsdi${UNAME_RELEASE}
 	exit ;;
     *:FreeBSD:*:*)
-	case ${UNAME_MACHINE} in
-	    pc98)
-		echo i386-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'` ;;
+	UNAME_PROCESSOR=`/usr/bin/uname -p`
+	case ${UNAME_PROCESSOR} in
 	    amd64)
 		echo x86_64-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'` ;;
 	    *)
-		echo ${UNAME_MACHINE}-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'` ;;
+		echo ${UNAME_PROCESSOR}-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'` ;;
 	esac
 	exit ;;
     i*:CYGWIN*:*)
 	echo ${UNAME_MACHINE}-pc-cygwin
 	exit ;;
+    *:MINGW64*:*)
+	echo ${UNAME_MACHINE}-pc-mingw64
+	exit ;;
     *:MINGW*:*)
 	echo ${UNAME_MACHINE}-pc-mingw32
 	exit ;;
+    i*:MSYS*:*)
+	echo ${UNAME_MACHINE}-pc-msys
+	exit ;;
     i*:windows32*:*)
-    	# uname -m includes "-pc" on this system.
-    	echo ${UNAME_MACHINE}-mingw32
+	# uname -m includes "-pc" on this system.
+	echo ${UNAME_MACHINE}-mingw32
 	exit ;;
     i*:PW*:*)
 	echo ${UNAME_MACHINE}-pc-pw32
 	exit ;;
     *:Interix*:*)
-    	case ${UNAME_MACHINE} in
+	case ${UNAME_MACHINE} in
 	    x86)
 		echo i586-pc-interix${UNAME_RELEASE}
 		exit ;;
@@ -861,6 +868,13 @@ EOF
     i*86:Minix:*:*)
 	echo ${UNAME_MACHINE}-pc-minix
 	exit ;;
+    aarch64:Linux:*:*)
+	echo ${UNAME_MACHINE}-unknown-linux-gnu
+	exit ;;
+    aarch64_be:Linux:*:*)
+	UNAME_MACHINE=aarch64_be
+	echo ${UNAME_MACHINE}-unknown-linux-gnu
+	exit ;;
     alpha:Linux:*:*)
 	case `sed -n '/^cpu model/s/^.*: \(.*\)/\1/p' < /proc/cpuinfo` in
 	  EV5)   UNAME_MACHINE=alphaev5 ;;
@@ -870,7 +884,7 @@ EOF
 	  EV6)   UNAME_MACHINE=alphaev6 ;;
 	  EV67)  UNAME_MACHINE=alphaev67 ;;
 	  EV68*) UNAME_MACHINE=alphaev68 ;;
-        esac
+	esac
 	objdump --private-headers /bin/sh | grep -q ld.so.1
 	if test "$?" = 0 ; then LIBC="libc1" ; else LIBC="" ; fi
 	echo ${UNAME_MACHINE}-unknown-linux-gnu${LIBC}
@@ -882,20 +896,29 @@ EOF
 	then
 	    echo ${UNAME_MACHINE}-unknown-linux-gnu
 	else
-	    echo ${UNAME_MACHINE}-unknown-linux-gnueabi
+	    if echo __ARM_PCS_VFP | $CC_FOR_BUILD -E - 2>/dev/null \
+		| grep -q __ARM_PCS_VFP
+	    then
+		echo ${UNAME_MACHINE}-unknown-linux-gnueabi
+	    else
+		echo ${UNAME_MACHINE}-unknown-linux-gnueabihf
+	    fi
 	fi
 	exit ;;
     avr32*:Linux:*:*)
 	echo ${UNAME_MACHINE}-unknown-linux-gnu
 	exit ;;
     cris:Linux:*:*)
-	echo cris-axis-linux-gnu
+	echo ${UNAME_MACHINE}-axis-linux-gnu
 	exit ;;
     crisv32:Linux:*:*)
-	echo crisv32-axis-linux-gnu
+	echo ${UNAME_MACHINE}-axis-linux-gnu
 	exit ;;
     frv:Linux:*:*)
-    	echo frv-unknown-linux-gnu
+	echo ${UNAME_MACHINE}-unknown-linux-gnu
+	exit ;;
+    hexagon:Linux:*:*)
+	echo ${UNAME_MACHINE}-unknown-linux-gnu
 	exit ;;
     i*86:Linux:*:*)
 	LIBC=gnu
@@ -937,7 +960,7 @@ EOF
 	test x"${CPU}" != x && { echo "${CPU}-unknown-linux-gnu"; exit; }
 	;;
     or32:Linux:*:*)
-	echo or32-unknown-linux-gnu
+	echo ${UNAME_MACHINE}-unknown-linux-gnu
 	exit ;;
     padre:Linux:*:*)
 	echo sparc-unknown-linux-gnu
@@ -963,7 +986,7 @@ EOF
 	echo ${UNAME_MACHINE}-ibm-linux
 	exit ;;
     sh64*:Linux:*:*)
-    	echo ${UNAME_MACHINE}-unknown-linux-gnu
+	echo ${UNAME_MACHINE}-unknown-linux-gnu
 	exit ;;
     sh*:Linux:*:*)
 	echo ${UNAME_MACHINE}-unknown-linux-gnu
@@ -972,16 +995,16 @@ EOF
 	echo ${UNAME_MACHINE}-unknown-linux-gnu
 	exit ;;
     tile*:Linux:*:*)
-	echo ${UNAME_MACHINE}-tilera-linux-gnu
+	echo ${UNAME_MACHINE}-unknown-linux-gnu
 	exit ;;
     vax:Linux:*:*)
 	echo ${UNAME_MACHINE}-dec-linux-gnu
 	exit ;;
     x86_64:Linux:*:*)
-	echo x86_64-unknown-linux-gnu
+	echo ${UNAME_MACHINE}-unknown-linux-gnu
 	exit ;;
     xtensa*:Linux:*:*)
-    	echo ${UNAME_MACHINE}-unknown-linux-gnu
+	echo ${UNAME_MACHINE}-unknown-linux-gnu
 	exit ;;
     i*86:DYNIX/ptx:4*:*)
 	# ptx 4.0 does uname -s correctly, with DYNIX/ptx in there.
@@ -990,11 +1013,11 @@ EOF
 	echo i386-sequent-sysv4
 	exit ;;
     i*86:UNIX_SV:4.2MP:2.*)
-        # Unixware is an offshoot of SVR4, but it has its own version
-        # number series starting with 2...
-        # I am not positive that other SVR4 systems won't match this,
+	# Unixware is an offshoot of SVR4, but it has its own version
+	# number series starting with 2...
+	# I am not positive that other SVR4 systems won't match this,
 	# I just have to hope.  -- rms.
-        # Use sysv4.2uw... so that sysv4* matches it.
+	# Use sysv4.2uw... so that sysv4* matches it.
 	echo ${UNAME_MACHINE}-pc-sysv4.2uw${UNAME_VERSION}
 	exit ;;
     i*86:OS/2:*:*)
@@ -1026,7 +1049,7 @@ EOF
 	fi
 	exit ;;
     i*86:*:5:[678]*)
-    	# UnixWare 7.x, OpenUNIX and OpenServer 6.
+	# UnixWare 7.x, OpenUNIX and OpenServer 6.
 	case `/bin/uname -X | grep "^Machine"` in
 	    *486*)	     UNAME_MACHINE=i486 ;;
 	    *Pentium)	     UNAME_MACHINE=i586 ;;
@@ -1054,13 +1077,13 @@ EOF
 	exit ;;
     pc:*:*:*)
 	# Left here for compatibility:
-        # uname -m prints for DJGPP always 'pc', but it prints nothing about
-        # the processor, so we play safe by assuming i586.
+	# uname -m prints for DJGPP always 'pc', but it prints nothing about
+	# the processor, so we play safe by assuming i586.
 	# Note: whatever this is, it MUST be the same as what config.sub
 	# prints for the "djgpp" host, or else GDB configury will decide that
 	# this is a cross-build.
 	echo i586-pc-msdosdjgpp
-        exit ;;
+	exit ;;
     Intel:Mach:3*:*)
 	echo i386-pc-mach3
 	exit ;;
@@ -1095,8 +1118,8 @@ EOF
 	/bin/uname -p 2>/dev/null | /bin/grep entium >/dev/null \
 	  && { echo i586-ncr-sysv4.3${OS_REL}; exit; } ;;
     3[34]??:*:4.0:* | 3[34]??,*:*:4.0:*)
-        /bin/uname -p 2>/dev/null | grep 86 >/dev/null \
-          && { echo i486-ncr-sysv4; exit; } ;;
+	/bin/uname -p 2>/dev/null | grep 86 >/dev/null \
+	  && { echo i486-ncr-sysv4; exit; } ;;
     NCR*:*:4.2:* | MPRAS*:*:4.2:*)
 	OS_REL='.3'
 	test -r /etc/.relid \
@@ -1139,10 +1162,10 @@ EOF
 		echo ns32k-sni-sysv
 	fi
 	exit ;;
-    PENTIUM:*:4.0*:*) # Unisys `ClearPath HMP IX 4000' SVR4/MP effort
-                      # says <Richard.M.Bartel at ccMail.Census.GOV>
-        echo i586-unisys-sysv4
-        exit ;;
+    PENTIUM:*:4.0*:*)	# Unisys `ClearPath HMP IX 4000' SVR4/MP effort
+			# says <Richard.M.Bartel at ccMail.Census.GOV>
+	echo i586-unisys-sysv4
+	exit ;;
     *:UNIX_System_V:4*:FTX*)
 	# From Gerald Hewes <hewes at openmarket.com>.
 	# How about differentiating between stratus architectures? -djm
@@ -1168,11 +1191,11 @@ EOF
 	exit ;;
     R[34]000:*System_V*:*:* | R4000:UNIX_SYSV:*:* | R*000:UNIX_SV:*:*)
 	if [ -d /usr/nec ]; then
-	        echo mips-nec-sysv${UNAME_RELEASE}
+		echo mips-nec-sysv${UNAME_RELEASE}
 	else
-	        echo mips-unknown-sysv${UNAME_RELEASE}
+		echo mips-unknown-sysv${UNAME_RELEASE}
 	fi
-        exit ;;
+	exit ;;
     BeBox:BeOS:*:*)	# BeOS running on hardware made by Be, PPC only.
 	echo powerpc-be-beos
 	exit ;;
@@ -1185,6 +1208,9 @@ EOF
     BePC:Haiku:*:*)	# Haiku running on Intel PC compatible.
 	echo i586-pc-haiku
 	exit ;;
+    x86_64:Haiku:*:*)
+	echo x86_64-unknown-haiku
+	exit ;;
     SX-4:SUPER-UX:*:*)
 	echo sx4-nec-superux${UNAME_RELEASE}
 	exit ;;
@@ -1240,7 +1266,7 @@ EOF
     NEO-?:NONSTOP_KERNEL:*:*)
 	echo neo-tandem-nsk${UNAME_RELEASE}
 	exit ;;
-    NSE-?:NONSTOP_KERNEL:*:*)
+    NSE-*:NONSTOP_KERNEL:*:*)
 	echo nse-tandem-nsk${UNAME_RELEASE}
 	exit ;;
     NSR-?:NONSTOP_KERNEL:*:*)
@@ -1285,13 +1311,13 @@ EOF
 	echo pdp10-unknown-its
 	exit ;;
     SEI:*:*:SEIUX)
-        echo mips-sei-seiux${UNAME_RELEASE}
+	echo mips-sei-seiux${UNAME_RELEASE}
 	exit ;;
     *:DragonFly:*:*)
 	echo ${UNAME_MACHINE}-unknown-dragonfly`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'`
 	exit ;;
     *:*VMS:*:*)
-    	UNAME_MACHINE=`(uname -p) 2>/dev/null`
+	UNAME_MACHINE=`(uname -p) 2>/dev/null`
 	case "${UNAME_MACHINE}" in
 	    A*) echo alpha-dec-vms ; exit ;;
 	    I*) echo ia64-dec-vms ; exit ;;
@@ -1309,11 +1335,11 @@ EOF
     i*86:AROS:*:*)
 	echo ${UNAME_MACHINE}-pc-aros
 	exit ;;
+    x86_64:VMkernel:*:*)
+	echo ${UNAME_MACHINE}-unknown-esx
+	exit ;;
 esac
 
-#echo '(No uname command or uname output not recognized.)' 1>&2
-#echo "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" 1>&2
-
 eval $set_cc_for_build
 cat >$dummy.c <<EOF
 #ifdef _SEQUENT_
@@ -1331,11 +1357,11 @@ main ()
 #include <sys/param.h>
   printf ("m68k-sony-newsos%s\n",
 #ifdef NEWSOS4
-          "4"
+	"4"
 #else
-	  ""
+	""
 #endif
-         ); exit (0);
+	); exit (0);
 #endif
 #endif
 
Index: config.sub
===================================================================
RCS file: /var/cvs/openssh/config.sub,v
retrieving revision 1.14
diff -u -p -r1.14 config.sub
--- config.sub	26 Jan 2011 20:32:14 -0000	1.14
+++ config.sub	17 Apr 2013 11:39:19 -0000
@@ -2,9 +2,9 @@
 # Configuration validation subroutine script.
 #   Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
 #   2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010,
-#   2011 Free Software Foundation, Inc.
+#   2011, 2012, 2013 Free Software Foundation, Inc.
 
-timestamp='2011-01-01'
+timestamp='2012-12-23'
 
 # This file is (in principle) common to ALL GNU software.
 # The presence of a machine in this file suggests that SOME GNU software
@@ -21,9 +21,7 @@ timestamp='2011-01-01'
 # GNU General Public License for more details.
 #
 # You should have received a copy of the GNU General Public License
-# along with this program; if not, write to the Free Software
-# Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA
-# 02110-1301, USA.
+# along with this program; if not, see <http://www.gnu.org/licenses/>.
 #
 # As a special exception to the GNU General Public License, if you
 # distribute this file as part of a program that contains a
@@ -76,8 +74,8 @@ version="\
 GNU config.sub ($timestamp)
 
 Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000,
-2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free
-Software Foundation, Inc.
+2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011,
+2012, 2013 Free Software Foundation, Inc.
 
 This is free software; see the source for copying conditions.  There is NO
 warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
@@ -125,13 +123,17 @@ esac
 maybe_os=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\2/'`
 case $maybe_os in
   nto-qnx* | linux-gnu* | linux-android* | linux-dietlibc | linux-newlib* | \
-  linux-uclibc* | uclinux-uclibc* | uclinux-gnu* | kfreebsd*-gnu* | \
+  linux-musl* | linux-uclibc* | uclinux-uclibc* | uclinux-gnu* | kfreebsd*-gnu* | \
   knetbsd*-gnu* | netbsd*-gnu* | \
   kopensolaris*-gnu* | \
   storm-chaos* | os2-emx* | rtmk-nova*)
     os=-$maybe_os
     basic_machine=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\1/'`
     ;;
+  android-linux)
+    os=-linux-android
+    basic_machine=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\1/'`-unknown
+    ;;
   *)
     basic_machine=`echo $1 | sed 's/-[^-]*$//'`
     if [ $basic_machine != $1 ]
@@ -154,12 +156,12 @@ case $os in
 	-convergent* | -ncr* | -news | -32* | -3600* | -3100* | -hitachi* |\
 	-c[123]* | -convex* | -sun | -crds | -omron* | -dg | -ultra | -tti* | \
 	-harris | -dolphin | -highlevel | -gould | -cbm | -ns | -masscomp | \
-	-apple | -axis | -knuth | -cray | -microblaze)
+	-apple | -axis | -knuth | -cray | -microblaze*)
 		os=
 		basic_machine=$1
 		;;
-        -bluegene*)
-	        os=-cnk
+	-bluegene*)
+		os=-cnk
 		;;
 	-sim | -cisco | -oki | -wec | -winbond)
 		os=
@@ -175,10 +177,10 @@ case $os in
 		os=-chorusos
 		basic_machine=$1
 		;;
- 	-chorusrdb)
- 		os=-chorusrdb
+	-chorusrdb)
+		os=-chorusrdb
 		basic_machine=$1
- 		;;
+		;;
 	-hiux*)
 		os=-hiuxwe2
 		;;
@@ -223,6 +225,12 @@ case $os in
 	-isc*)
 		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
 		;;
+	-lynx*178)
+		os=-lynxos178
+		;;
+	-lynx*5)
+		os=-lynxos5
+		;;
 	-lynx*)
 		os=-lynxos
 		;;
@@ -247,20 +255,27 @@ case $basic_machine in
 	# Some are omitted here because they have special meanings below.
 	1750a | 580 \
 	| a29k \
+	| aarch64 | aarch64_be \
 	| alpha | alphaev[4-8] | alphaev56 | alphaev6[78] | alphapca5[67] \
 	| alpha64 | alpha64ev[4-8] | alpha64ev56 | alpha64ev6[78] | alpha64pca5[67] \
 	| am33_2.0 \
-	| arc | arm | arm[bl]e | arme[lb] | armv[2345] | armv[345][lb] | avr | avr32 \
+	| arc \
+	| arm | arm[bl]e | arme[lb] | armv[2-8] | armv[3-8][lb] | armv7[arm] \
+	| avr | avr32 \
+	| be32 | be64 \
 	| bfin \
 	| c4x | clipper \
 	| d10v | d30v | dlx | dsp16xx \
+	| epiphany \
 	| fido | fr30 | frv \
 	| h8300 | h8500 | hppa | hppa1.[01] | hppa2.0 | hppa2.0[nw] | hppa64 \
+	| hexagon \
 	| i370 | i860 | i960 | ia64 \
 	| ip2k | iq2000 \
+	| le32 | le64 \
 	| lm32 \
 	| m32c | m32r | m32rle | m68000 | m68k | m88k \
-	| maxq | mb | microblaze | mcore | mep | metag \
+	| maxq | mb | microblaze | microblazeel | mcore | mep | metag \
 	| mips | mipsbe | mipseb | mipsel | mipsle \
 	| mips16 \
 	| mips64 | mips64el \
@@ -286,22 +301,23 @@ case $basic_machine in
 	| nds32 | nds32le | nds32be \
 	| nios | nios2 \
 	| ns16k | ns32k \
+	| open8 \
 	| or32 \
 	| pdp10 | pdp11 | pj | pjl \
-	| powerpc | powerpc64 | powerpc64le | powerpcle | ppcbe \
+	| powerpc | powerpc64 | powerpc64le | powerpcle \
 	| pyramid \
-	| rx \
+	| rl78 | rx \
 	| score \
 	| sh | sh[1234] | sh[24]a | sh[24]aeb | sh[23]e | sh[34]eb | sheb | shbe | shle | sh[1234]le | sh3ele \
 	| sh64 | sh64le \
 	| sparc | sparc64 | sparc64b | sparc64v | sparc86x | sparclet | sparclite \
 	| sparcv8 | sparcv9 | sparcv9b | sparcv9v \
-	| spu | strongarm \
-	| tahoe | thumb | tic4x | tic54x | tic55x | tic6x | tic80 | tron \
+	| spu \
+	| tahoe | tic4x | tic54x | tic55x | tic6x | tic80 | tron \
 	| ubicom32 \
-	| v850 | v850e \
+	| v850 | v850e | v850e1 | v850e2 | v850es | v850e2v3 \
 	| we32k \
-	| x86 | xc16x | xscale | xscalee[bl] | xstormy16 | xtensa \
+	| x86 | xc16x | xstormy16 | xtensa \
 	| z8k | z80)
 		basic_machine=$basic_machine-unknown
 		;;
@@ -314,8 +330,7 @@ case $basic_machine in
 	c6x)
 		basic_machine=tic6x-unknown
 		;;
-	m6811 | m68hc11 | m6812 | m68hc12 | picochip)
-		# Motorola 68HC11/12.
+	m6811 | m68hc11 | m6812 | m68hc12 | m68hcs12x | picochip)
 		basic_machine=$basic_machine-unknown
 		os=-none
 		;;
@@ -325,6 +340,21 @@ case $basic_machine in
 		basic_machine=mt-unknown
 		;;
 
+	strongarm | thumb | xscale)
+		basic_machine=arm-unknown
+		;;
+	xgate)
+		basic_machine=$basic_machine-unknown
+		os=-none
+		;;
+	xscaleeb)
+		basic_machine=armeb-unknown
+		;;
+
+	xscaleel)
+		basic_machine=armel-unknown
+		;;
+
 	# We use `pc' rather than `unknown'
 	# because (1) that's what they normally are, and
 	# (2) the word "unknown" tends to confuse beginning users.
@@ -339,11 +369,13 @@ case $basic_machine in
 	# Recognize the basic CPU types with company name.
 	580-* \
 	| a29k-* \
+	| aarch64-* | aarch64_be-* \
 	| alpha-* | alphaev[4-8]-* | alphaev56-* | alphaev6[78]-* \
 	| alpha64-* | alpha64ev[4-8]-* | alpha64ev56-* | alpha64ev6[78]-* \
 	| alphapca5[67]-* | alpha64pca5[67]-* | arc-* \
 	| arm-*  | armbe-* | armle-* | armeb-* | armv*-* \
 	| avr-* | avr32-* \
+	| be32-* | be64-* \
 	| bfin-* | bs2000-* \
 	| c[123]* | c30-* | [cjt]90-* | c4x-* \
 	| clipper-* | craynv-* | cydra-* \
@@ -352,12 +384,15 @@ case $basic_machine in
 	| f30[01]-* | f700-* | fido-* | fr30-* | frv-* | fx80-* \
 	| h8300-* | h8500-* \
 	| hppa-* | hppa1.[01]-* | hppa2.0-* | hppa2.0[nw]-* | hppa64-* \
+	| hexagon-* \
 	| i*86-* | i860-* | i960-* | ia64-* \
 	| ip2k-* | iq2000-* \
+	| le32-* | le64-* \
 	| lm32-* \
 	| m32c-* | m32r-* | m32rle-* \
 	| m68000-* | m680[012346]0-* | m68360-* | m683?2-* | m68k-* \
-	| m88110-* | m88k-* | maxq-* | mcore-* | metag-* | microblaze-* \
+	| m88110-* | m88k-* | maxq-* | mcore-* | metag-* \
+	| microblaze-* | microblazeel-* \
 	| mips-* | mipsbe-* | mipseb-* | mipsel-* | mipsle-* \
 	| mips16-* \
 	| mips64-* | mips64el-* \
@@ -382,24 +417,26 @@ case $basic_machine in
 	| nds32-* | nds32le-* | nds32be-* \
 	| nios-* | nios2-* \
 	| none-* | np1-* | ns16k-* | ns32k-* \
+	| open8-* \
 	| orion-* \
 	| pdp10-* | pdp11-* | pj-* | pjl-* | pn-* | power-* \
-	| powerpc-* | powerpc64-* | powerpc64le-* | powerpcle-* | ppcbe-* \
+	| powerpc-* | powerpc64-* | powerpc64le-* | powerpcle-* \
 	| pyramid-* \
-	| romp-* | rs6000-* | rx-* \
+	| rl78-* | romp-* | rs6000-* | rx-* \
 	| sh-* | sh[1234]-* | sh[24]a-* | sh[24]aeb-* | sh[23]e-* | sh[34]eb-* | sheb-* | shbe-* \
 	| shle-* | sh[1234]le-* | sh3ele-* | sh64-* | sh64le-* \
 	| sparc-* | sparc64-* | sparc64b-* | sparc64v-* | sparc86x-* | sparclet-* \
 	| sparclite-* \
-	| sparcv8-* | sparcv9-* | sparcv9b-* | sparcv9v-* | strongarm-* | sv1-* | sx?-* \
-	| tahoe-* | thumb-* \
+	| sparcv8-* | sparcv9-* | sparcv9b-* | sparcv9v-* | sv1-* | sx?-* \
+	| tahoe-* \
 	| tic30-* | tic4x-* | tic54x-* | tic55x-* | tic6x-* | tic80-* \
-	| tile-* | tilegx-* \
+	| tile*-* \
 	| tron-* \
 	| ubicom32-* \
-	| v850-* | v850e-* | vax-* \
+	| v850-* | v850e-* | v850e1-* | v850es-* | v850e2-* | v850e2v3-* \
+	| vax-* \
 	| we32k-* \
-	| x86-* | x86_64-* | xc16x-* | xps100-* | xscale-* | xscalee[bl]-* \
+	| x86-* | x86_64-* | xc16x-* | xps100-* \
 	| xstormy16-* | xtensa*-* \
 	| ymp-* \
 	| z8k-* | z80-*)
@@ -424,7 +461,7 @@ case $basic_machine in
 		basic_machine=a29k-amd
 		os=-udi
 		;;
-    	abacus)
+	abacus)
 		basic_machine=abacus-unknown
 		;;
 	adobe68k)
@@ -507,7 +544,7 @@ case $basic_machine in
 		basic_machine=c90-cray
 		os=-unicos
 		;;
-        cegcc)
+	cegcc)
 		basic_machine=arm-unknown
 		os=-cegcc
 		;;
@@ -697,7 +734,6 @@ case $basic_machine in
 	i370-ibm* | ibm*)
 		basic_machine=i370-ibm
 		;;
-# I'm not sure what "Sysv32" means.  Should this be sysv3.2?
 	i*86v32)
 		basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
 		os=-sysv32
@@ -755,9 +791,13 @@ case $basic_machine in
 		basic_machine=ns32k-utek
 		os=-sysv
 		;;
-        microblaze)
+	microblaze*)
 		basic_machine=microblaze-xilinx
 		;;
+	mingw64)
+		basic_machine=x86_64-pc
+		os=-mingw64
+		;;
 	mingw32)
 		basic_machine=i386-pc
 		os=-mingw32
@@ -794,10 +834,18 @@ case $basic_machine in
 	ms1-*)
 		basic_machine=`echo $basic_machine | sed -e 's/ms1-/mt-/'`
 		;;
+	msys)
+		basic_machine=i386-pc
+		os=-msys
+		;;
 	mvs)
 		basic_machine=i370-ibm
 		os=-mvs
 		;;
+	nacl)
+		basic_machine=le32-unknown
+		os=-nacl
+		;;
 	ncr3000)
 		basic_machine=i486-ncr
 		os=-sysv4
@@ -862,10 +910,10 @@ case $basic_machine in
 	np1)
 		basic_machine=np1-gould
 		;;
-        neo-tandem)
+	neo-tandem)
 		basic_machine=neo-tandem
 		;;
-        nse-tandem)
+	nse-tandem)
 		basic_machine=nse-tandem
 		;;
 	nsr-tandem)
@@ -950,9 +998,10 @@ case $basic_machine in
 		;;
 	power)	basic_machine=power-ibm
 		;;
-	ppc)	basic_machine=powerpc-unknown
+	ppc | ppcbe)	basic_machine=powerpc-unknown
 		;;
-	ppc-*)	basic_machine=powerpc-`echo $basic_machine | sed 's/^[^-]*-//'`
+	ppc-* | ppcbe-*)
+		basic_machine=powerpc-`echo $basic_machine | sed 's/^[^-]*-//'`
 		;;
 	ppcle | powerpclittle | ppc-le | powerpc-little)
 		basic_machine=powerpcle-unknown
@@ -977,7 +1026,11 @@ case $basic_machine in
 		basic_machine=i586-unknown
 		os=-pw32
 		;;
-	rdos)
+	rdos | rdos64)
+		basic_machine=x86_64-pc
+		os=-rdos
+		;;
+	rdos32)
 		basic_machine=i386-pc
 		os=-rdos
 		;;
@@ -1046,6 +1099,9 @@ case $basic_machine in
 		basic_machine=i860-stratus
 		os=-sysv4
 		;;
+	strongarm-* | thumb-*)
+		basic_machine=arm-`echo $basic_machine | sed 's/^[^-]*-//'`
+		;;
 	sun2)
 		basic_machine=m68000-sun
 		;;
@@ -1102,13 +1158,8 @@ case $basic_machine in
 		basic_machine=t90-cray
 		os=-unicos
 		;;
-        # This must be matched before tile*.
-        tilegx*)
-		basic_machine=tilegx-unknown
-		os=-linux-gnu
-		;;
 	tile*)
-		basic_machine=tile-unknown
+		basic_machine=$basic_machine-unknown
 		os=-linux-gnu
 		;;
 	tx39)
@@ -1178,6 +1229,9 @@ case $basic_machine in
 	xps | xps100)
 		basic_machine=xps100-honeywell
 		;;
+	xscale-* | xscalee[bl]-*)
+		basic_machine=`echo $basic_machine | sed 's/^xscale/arm/'`
+		;;
 	ymp)
 		basic_machine=ymp-cray
 		os=-unicos
@@ -1275,11 +1329,11 @@ esac
 if [ x"$os" != x"" ]
 then
 case $os in
-        # First match some system type aliases
-        # that might get confused with valid system types.
+	# First match some system type aliases
+	# that might get confused with valid system types.
 	# -solaris* is a basic system type, with this one exception.
-        -auroraux)
-	        os=-auroraux
+	-auroraux)
+		os=-auroraux
 		;;
 	-solaris1 | -solaris1.*)
 		os=`echo $os | sed -e 's|solaris1|sunos4|'`
@@ -1309,15 +1363,15 @@ case $os in
 	      | -nindy* | -vxsim* | -vxworks* | -ebmon* | -hms* | -mvs* \
 	      | -clix* | -riscos* | -uniplus* | -iris* | -rtu* | -xenix* \
 	      | -hiux* | -386bsd* | -knetbsd* | -mirbsd* | -netbsd* \
-	      | -openbsd* | -solidbsd* \
+	      | -bitrig* | -openbsd* | -solidbsd* \
 	      | -ekkobsd* | -kfreebsd* | -freebsd* | -riscix* | -lynxos* \
 	      | -bosx* | -nextstep* | -cxux* | -aout* | -elf* | -oabi* \
 	      | -ptx* | -coff* | -ecoff* | -winnt* | -domain* | -vsta* \
 	      | -udi* | -eabi* | -lites* | -ieee* | -go32* | -aux* \
 	      | -chorusos* | -chorusrdb* | -cegcc* \
-	      | -cygwin* | -pe* | -psos* | -moss* | -proelf* | -rtems* \
-	      | -mingw32* | -linux-gnu* | -linux-android* \
-	      | -linux-newlib* | -linux-uclibc* \
+	      | -cygwin* | -msys* | -pe* | -psos* | -moss* | -proelf* | -rtems* \
+	      | -mingw32* | -mingw64* | -linux-gnu* | -linux-android* \
+	      | -linux-newlib* | -linux-musl* | -linux-uclibc* \
 	      | -uxpv* | -beos* | -mpeix* | -udk* \
 	      | -interix* | -uwin* | -mks* | -rhapsody* | -darwin* | -opened* \
 	      | -openstep* | -oskit* | -conix* | -pw32* | -nonstopux* \
@@ -1364,7 +1418,7 @@ case $os in
 	-opened*)
 		os=-openedition
 		;;
-        -os400*)
+	-os400*)
 		os=-os400
 		;;
 	-wince*)
@@ -1413,7 +1467,7 @@ case $os in
 	-sinix*)
 		os=-sysv4
 		;;
-        -tpf*)
+	-tpf*)
 		os=-tpf
 		;;
 	-triton*)
@@ -1458,8 +1512,8 @@ case $os in
 	-dicos*)
 		os=-dicos
 		;;
-        -nacl*)
-	        ;;
+	-nacl*)
+		;;
 	-none)
 		;;
 	*)
@@ -1482,10 +1536,10 @@ else
 # system, and we'll never get to this point.
 
 case $basic_machine in
-        score-*)
+	score-*)
 		os=-elf
 		;;
-        spu-*)
+	spu-*)
 		os=-elf
 		;;
 	*-acorn)
@@ -1497,8 +1551,11 @@ case $basic_machine in
 	arm*-semi)
 		os=-aout
 		;;
-        c4x-* | tic4x-*)
-        	os=-coff
+	c4x-* | tic4x-*)
+		os=-coff
+		;;
+	hexagon-*)
+		os=-elf
 		;;
 	tic54x-*)
 		os=-coff
@@ -1527,14 +1584,11 @@ case $basic_machine in
 		;;
 	m68000-sun)
 		os=-sunos3
-		# This also exists in the configure program, but was not the
-		# default.
-		# os=-sunos4
 		;;
 	m68*-cisco)
 		os=-aout
 		;;
-        mep-*)
+	mep-*)
 		os=-elf
 		;;
 	mips*-cisco)
@@ -1561,7 +1615,7 @@ case $basic_machine in
 	*-ibm)
 		os=-aix
 		;;
-    	*-knuth)
+	*-knuth)
 		os=-mmixware
 		;;
 	*-wec)

From plautrba at redhat.com  Wed Apr 17 22:16:45 2013
From: plautrba at redhat.com (Petr Lautrbach)
Date: Wed, 17 Apr 2013 14:16:45 +0200
Subject: update config.guess and config.sub to support aarch64
In-Reply-To: <alpine.BSO.2.00.1304172134010.8512@natsu.mindrot.org>
References: <516D7753.1080407@redhat.com>
 <alpine.BSO.2.00.1304172134010.8512@natsu.mindrot.org>
Message-ID: <516E92AD.7020108@redhat.com>

On 04/17/2013 01:46 PM, Damien Miller wrote:
> On Tue, 16 Apr 2013, Petr Lautrbach wrote:
>
>> Hello,
>>
>> would it be possible to update config.sub and config.guess to the latest
>> versions (or at least version
>> from automake-1.13.1) in order to support new architectures based on the ARM
>> 64 bit CPU?
>
> I'm not going to import GPL3 code into the OpenSSH source distribution.

I missed that change, sorry.

> Fortunately it looks like the arm64 changes were added before the
> license got updated
>
> Does this have everything you need?

It looks ok since the original suggestion in bug proposed version with
timestamp='2012-09-25' [1] and your version is based on newer timestamp='2012-12-23'
and aarch64 changes are included.


[1] http://ausil.fedorapeople.org/aarch64/openssh/openssh-aarch64.patch

Thanks,

Petr

>
> Index: config.guess
> ===================================================================
> RCS file: /var/cvs/openssh/config.guess,v
> retrieving revision 1.15
> diff -u -p -r1.15 config.guess
> --- config.guess	26 Jan 2011 20:32:14 -0000	1.15
> +++ config.guess	17 Apr 2013 11:39:19 -0000
> @@ -2,9 +2,9 @@
>   # Attempt to guess a canonical system name.
>   #   Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
>   #   2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010,
> -#   2011 Free Software Foundation, Inc.
> +#   2011, 2012, 2013 Free Software Foundation, Inc.
>
> -timestamp='2011-01-23'
> +timestamp='2012-12-23'
>
>   # This file is free software; you can redistribute it and/or modify it
>   # under the terms of the GNU General Public License as published by
> @@ -17,9 +17,7 @@ timestamp='2011-01-23'
>   # General Public License for more details.
>   #
>   # You should have received a copy of the GNU General Public License
> -# along with this program; if not, write to the Free Software
> -# Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA
> -# 02110-1301, USA.
> +# along with this program; if not, see<http://www.gnu.org/licenses/>.
>   #
>   # As a special exception to the GNU General Public License, if you
>   # distribute this file as part of a program that contains a
> @@ -57,8 +55,8 @@ GNU config.guess ($timestamp)
>
>   Originally written by Per Bothner.
>   Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000,
> -2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011 Free
> -Software Foundation, Inc.
> +2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011,
> +2012, 2013 Free Software Foundation, Inc.
>
>   This is free software; see the source for copying conditions.  There is NO
>   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
> @@ -145,7 +143,7 @@ UNAME_VERSION=`(uname -v) 2>/dev/null` |
>   case "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" in
>       *:NetBSD:*:*)
>   	# NetBSD (nbsd) targets should (where applicable) match one or
> -	# more of the tupples: *-*-netbsdelf*, *-*-netbsdaout*,
> +	# more of the tuples: *-*-netbsdelf*, *-*-netbsdaout*,
>   	# *-*-netbsdecoff* and *-*-netbsd*.  For targets that recently
>   	# switched to ELF, *-*-netbsd* would select the old
>   	# object file format.  This provides both forward
> @@ -181,7 +179,7 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:$
>   		fi
>   		;;
>   	    *)
> -	        os=netbsd
> +		os=netbsd
>   		;;
>   	esac
>   	# The OS release
> @@ -202,6 +200,10 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:$
>   	# CPU_TYPE-MANUFACTURER-OPERATING_SYSTEM is used.
>   	echo "${machine}-${os}${release}"
>   	exit ;;
> +    *:Bitrig:*:*)
> +	UNAME_MACHINE_ARCH=`arch | sed 's/Bitrig.//'`
> +	echo ${UNAME_MACHINE_ARCH}-unknown-bitrig${UNAME_RELEASE}
> +	exit ;;
>       *:OpenBSD:*:*)
>   	UNAME_MACHINE_ARCH=`arch | sed 's/OpenBSD.//'`
>   	echo ${UNAME_MACHINE_ARCH}-unknown-openbsd${UNAME_RELEASE}
> @@ -224,7 +226,7 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:$
>   		UNAME_RELEASE=`/usr/sbin/sizer -v | awk '{print $3}'`
>   		;;
>   	*5.*)
> -	        UNAME_RELEASE=`/usr/sbin/sizer -v | awk '{print $4}'`
> +		UNAME_RELEASE=`/usr/sbin/sizer -v | awk '{print $4}'`
>   		;;
>   	esac
>   	# According to Compaq, /usr/sbin/psrinfo has been available on
> @@ -299,12 +301,12 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:$
>   	echo s390-ibm-zvmoe
>   	exit ;;
>       *:OS400:*:*)
> -        echo powerpc-ibm-os400
> +	echo powerpc-ibm-os400
>   	exit ;;
>       arm:RISC*:1.[012]*:*|arm:riscix:1.[012]*:*)
>   	echo arm-acorn-riscix${UNAME_RELEASE}
>   	exit ;;
> -    arm:riscos:*:*|arm:RISCOS:*:*)
> +    arm*:riscos:*:*|arm*:RISCOS:*:*)
>   	echo arm-unknown-riscos
>   	exit ;;
>       SR2?01:HI-UX/MPP:*:* | SR8000:HI-UX/MPP:*:*)
> @@ -398,23 +400,23 @@ case "${UNAME_MACHINE}:${UNAME_SYSTEM}:$
>       # MiNT.  But MiNT is downward compatible to TOS, so this should
>       # be no problem.
>       atarist[e]:*MiNT:*:* | atarist[e]:*mint:*:* | atarist[e]:*TOS:*:*)
> -        echo m68k-atari-mint${UNAME_RELEASE}
> +	echo m68k-atari-mint${UNAME_RELEASE}
>   	exit ;;
>       atari*:*MiNT:*:* | atari*:*mint:*:* | atarist[e]:*TOS:*:*)
>   	echo m68k-atari-mint${UNAME_RELEASE}
> -        exit ;;
> +	exit ;;
>       *falcon*:*MiNT:*:* | *falcon*:*mint:*:* | *falcon*:*TOS:*:*)
> -        echo m68k-atari-mint${UNAME_RELEASE}
> +	echo m68k-atari-mint${UNAME_RELEASE}
>   	exit ;;
>       milan*:*MiNT:*:* | milan*:*mint:*:* | *milan*:*TOS:*:*)
> -        echo m68k-milan-mint${UNAME_RELEASE}
> -        exit ;;
> +	echo m68k-milan-mint${UNAME_RELEASE}
> +	exit ;;
>       hades*:*MiNT:*:* | hades*:*mint:*:* | *hades*:*TOS:*:*)
> -        echo m68k-hades-mint${UNAME_RELEASE}
> -        exit ;;
> +	echo m68k-hades-mint${UNAME_RELEASE}
> +	exit ;;
>       *:*MiNT:*:* | *:*mint:*:* | *:*TOS:*:*)
> -        echo m68k-unknown-mint${UNAME_RELEASE}
> -        exit ;;
> +	echo m68k-unknown-mint${UNAME_RELEASE}
> +	exit ;;
>       m68k:machten:*:*)
>   	echo m68k-apple-machten${UNAME_RELEASE}
>   	exit ;;
> @@ -484,8 +486,8 @@ EOF
>   	echo m88k-motorola-sysv3
>   	exit ;;
>       AViiON:dgux:*:*)
> -        # DG/UX returns AViiON for all architectures
> -        UNAME_PROCESSOR=`/usr/bin/uname -p`
> +	# DG/UX returns AViiON for all architectures
> +	UNAME_PROCESSOR=`/usr/bin/uname -p`
>   	if [ $UNAME_PROCESSOR = mc88100 ] || [ $UNAME_PROCESSOR = mc88110 ]
>   	then
>   	    if [ ${TARGET_BINARY_INTERFACE}x = m88kdguxelfx ] || \
> @@ -498,7 +500,7 @@ EOF
>   	else
>   	    echo i586-dg-dgux${UNAME_RELEASE}
>   	fi
> - 	exit ;;
> +	exit ;;
>       M88*:DolphinOS:*:*)	# DolphinOS (SVR3)
>   	echo m88k-dolphin-sysv3
>   	exit ;;
> @@ -598,52 +600,52 @@ EOF
>   	    9000/[678][0-9][0-9])
>   		if [ -x /usr/bin/getconf ]; then
>   		    sc_cpu_version=`/usr/bin/getconf SC_CPU_VERSION 2>/dev/null`
> -                    sc_kernel_bits=`/usr/bin/getconf SC_KERNEL_BITS 2>/dev/null`
> -                    case "${sc_cpu_version}" in
> -                      523) HP_ARCH="hppa1.0" ;; # CPU_PA_RISC1_0
> -                      528) HP_ARCH="hppa1.1" ;; # CPU_PA_RISC1_1
> -                      532)                      # CPU_PA_RISC2_0
> -                        case "${sc_kernel_bits}" in
> -                          32) HP_ARCH="hppa2.0n" ;;
> -                          64) HP_ARCH="hppa2.0w" ;;
> +		    sc_kernel_bits=`/usr/bin/getconf SC_KERNEL_BITS 2>/dev/null`
> +		    case "${sc_cpu_version}" in
> +		      523) HP_ARCH="hppa1.0" ;; # CPU_PA_RISC1_0
> +		      528) HP_ARCH="hppa1.1" ;; # CPU_PA_RISC1_1
> +		      532)                      # CPU_PA_RISC2_0
> +			case "${sc_kernel_bits}" in
> +			  32) HP_ARCH="hppa2.0n" ;;
> +			  64) HP_ARCH="hppa2.0w" ;;
>   			  '') HP_ARCH="hppa2.0" ;;   # HP-UX 10.20
> -                        esac ;;
> -                    esac
> +			esac ;;
> +		    esac
>   		fi
>   		if [ "${HP_ARCH}" = "" ]; then
>   		    eval $set_cc_for_build
> -		    sed 's/^              //'<<  EOF>$dummy.c
> +		    sed 's/^		//'<<  EOF>$dummy.c
> +
> +		#define _HPUX_SOURCE
> +		#include<stdlib.h>
> +		#include<unistd.h>
>
> -              #define _HPUX_SOURCE
> -              #include<stdlib.h>
> -              #include<unistd.h>
> -
> -              int main ()
> -              {
> -              #if defined(_SC_KERNEL_BITS)
> -                  long bits = sysconf(_SC_KERNEL_BITS);
> -              #endif
> -                  long cpu  = sysconf (_SC_CPU_VERSION);
> -
> -                  switch (cpu)
> -              	{
> -              	case CPU_PA_RISC1_0: puts ("hppa1.0"); break;
> -              	case CPU_PA_RISC1_1: puts ("hppa1.1"); break;
> -              	case CPU_PA_RISC2_0:
> -              #if defined(_SC_KERNEL_BITS)
> -              	    switch (bits)
> -              		{
> -              		case 64: puts ("hppa2.0w"); break;
> -              		case 32: puts ("hppa2.0n"); break;
> -              		default: puts ("hppa2.0"); break;
> -              		} break;
> -              #else  /* !defined(_SC_KERNEL_BITS) */
> -              	    puts ("hppa2.0"); break;
> -              #endif
> -              	default: puts ("hppa1.0"); break;
> -              	}
> -                  exit (0);
> -              }
> +		int main ()
> +		{
> +		#if defined(_SC_KERNEL_BITS)
> +		    long bits = sysconf(_SC_KERNEL_BITS);
> +		#endif
> +		    long cpu  = sysconf (_SC_CPU_VERSION);
> +
> +		    switch (cpu)
> +			{
> +			case CPU_PA_RISC1_0: puts ("hppa1.0"); break;
> +			case CPU_PA_RISC1_1: puts ("hppa1.1"); break;
> +			case CPU_PA_RISC2_0:
> +		#if defined(_SC_KERNEL_BITS)
> +			    switch (bits)
> +				{
> +				case 64: puts ("hppa2.0w"); break;
> +				case 32: puts ("hppa2.0n"); break;
> +				default: puts ("hppa2.0"); break;
> +				} break;
> +		#else  /* !defined(_SC_KERNEL_BITS) */
> +			    puts ("hppa2.0"); break;
> +		#endif
> +			default: puts ("hppa1.0"); break;
> +			}
> +		    exit (0);
> +		}
>   EOF
>   		    (CCOPTS= $CC_FOR_BUILD -o $dummy $dummy.c 2>/dev/null)&&  HP_ARCH=`$dummy`
>   		    test -z "$HP_ARCH"&&  HP_ARCH=hppa
> @@ -734,22 +736,22 @@ EOF
>   	exit ;;
>       C1*:ConvexOS:*:* | convex:ConvexOS:C1*:*)
>   	echo c1-convex-bsd
> -        exit ;;
> +	exit ;;
>       C2*:ConvexOS:*:* | convex:ConvexOS:C2*:*)
>   	if getsysinfo -f scalar_acc
>   	then echo c32-convex-bsd
>   	else echo c2-convex-bsd
>   	fi
> -        exit ;;
> +	exit ;;
>       C34*:ConvexOS:*:* | convex:ConvexOS:C34*:*)
>   	echo c34-convex-bsd
> -        exit ;;
> +	exit ;;
>       C38*:ConvexOS:*:* | convex:ConvexOS:C38*:*)
>   	echo c38-convex-bsd
> -        exit ;;
> +	exit ;;
>       C4*:ConvexOS:*:* | convex:ConvexOS:C4*:*)
>   	echo c4-convex-bsd
> -        exit ;;
> +	exit ;;
>       CRAY*Y-MP:*:*:*)
>   	echo ymp-cray-unicos${UNAME_RELEASE} | sed -e 's/\.[^.]*$/.X/'
>   	exit ;;
> @@ -773,14 +775,14 @@ EOF
>   	exit ;;
>       F30[01]:UNIX_System_V:*:* | F700:UNIX_System_V:*:*)
>   	FUJITSU_PROC=`uname -m | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz'`
> -        FUJITSU_SYS=`uname -p | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz' | sed -e 's/\///'`
> -        FUJITSU_REL=`echo ${UNAME_RELEASE} | sed -e 's/ /_/'`
> -        echo "${FUJITSU_PROC}-fujitsu-${FUJITSU_SYS}${FUJITSU_REL}"
> -        exit ;;
> +	FUJITSU_SYS=`uname -p | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz' | sed -e 's/\///'`
> +	FUJITSU_REL=`echo ${UNAME_RELEASE} | sed -e 's/ /_/'`
> +	echo "${FUJITSU_PROC}-fujitsu-${FUJITSU_SYS}${FUJITSU_REL}"
> +	exit ;;
>       5000:UNIX_System_V:4.*:*)
> -        FUJITSU_SYS=`uname -p | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz' | sed -e 's/\///'`
> -        FUJITSU_REL=`echo ${UNAME_RELEASE} | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz' | sed -e 's/ /_/'`
> -        echo "sparc-fujitsu-${FUJITSU_SYS}${FUJITSU_REL}"
> +	FUJITSU_SYS=`uname -p | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz' | sed -e 's/\///'`
> +	FUJITSU_REL=`echo ${UNAME_RELEASE} | tr 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' 'abcdefghijklmnopqrstuvwxyz' | sed -e 's/ /_/'`
> +	echo "sparc-fujitsu-${FUJITSU_SYS}${FUJITSU_REL}"
>   	exit ;;
>       i*86:BSD/386:*:* | i*86:BSD/OS:*:* | *:Ascend\ Embedded/OS:*:*)
>   	echo ${UNAME_MACHINE}-pc-bsdi${UNAME_RELEASE}
> @@ -792,30 +794,35 @@ EOF
>   	echo ${UNAME_MACHINE}-unknown-bsdi${UNAME_RELEASE}
>   	exit ;;
>       *:FreeBSD:*:*)
> -	case ${UNAME_MACHINE} in
> -	    pc98)
> -		echo i386-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'` ;;
> +	UNAME_PROCESSOR=`/usr/bin/uname -p`
> +	case ${UNAME_PROCESSOR} in
>   	    amd64)
>   		echo x86_64-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'` ;;
>   	    *)
> -		echo ${UNAME_MACHINE}-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'` ;;
> +		echo ${UNAME_PROCESSOR}-unknown-freebsd`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'` ;;
>   	esac
>   	exit ;;
>       i*:CYGWIN*:*)
>   	echo ${UNAME_MACHINE}-pc-cygwin
>   	exit ;;
> +    *:MINGW64*:*)
> +	echo ${UNAME_MACHINE}-pc-mingw64
> +	exit ;;
>       *:MINGW*:*)
>   	echo ${UNAME_MACHINE}-pc-mingw32
>   	exit ;;
> +    i*:MSYS*:*)
> +	echo ${UNAME_MACHINE}-pc-msys
> +	exit ;;
>       i*:windows32*:*)
> -    	# uname -m includes "-pc" on this system.
> -    	echo ${UNAME_MACHINE}-mingw32
> +	# uname -m includes "-pc" on this system.
> +	echo ${UNAME_MACHINE}-mingw32
>   	exit ;;
>       i*:PW*:*)
>   	echo ${UNAME_MACHINE}-pc-pw32
>   	exit ;;
>       *:Interix*:*)
> -    	case ${UNAME_MACHINE} in
> +	case ${UNAME_MACHINE} in
>   	    x86)
>   		echo i586-pc-interix${UNAME_RELEASE}
>   		exit ;;
> @@ -861,6 +868,13 @@ EOF
>       i*86:Minix:*:*)
>   	echo ${UNAME_MACHINE}-pc-minix
>   	exit ;;
> +    aarch64:Linux:*:*)
> +	echo ${UNAME_MACHINE}-unknown-linux-gnu
> +	exit ;;
> +    aarch64_be:Linux:*:*)
> +	UNAME_MACHINE=aarch64_be
> +	echo ${UNAME_MACHINE}-unknown-linux-gnu
> +	exit ;;
>       alpha:Linux:*:*)
>   	case `sed -n '/^cpu model/s/^.*: \(.*\)/\1/p'<  /proc/cpuinfo` in
>   	  EV5)   UNAME_MACHINE=alphaev5 ;;
> @@ -870,7 +884,7 @@ EOF
>   	  EV6)   UNAME_MACHINE=alphaev6 ;;
>   	  EV67)  UNAME_MACHINE=alphaev67 ;;
>   	  EV68*) UNAME_MACHINE=alphaev68 ;;
> -        esac
> +	esac
>   	objdump --private-headers /bin/sh | grep -q ld.so.1
>   	if test "$?" = 0 ; then LIBC="libc1" ; else LIBC="" ; fi
>   	echo ${UNAME_MACHINE}-unknown-linux-gnu${LIBC}
> @@ -882,20 +896,29 @@ EOF
>   	then
>   	    echo ${UNAME_MACHINE}-unknown-linux-gnu
>   	else
> -	    echo ${UNAME_MACHINE}-unknown-linux-gnueabi
> +	    if echo __ARM_PCS_VFP | $CC_FOR_BUILD -E - 2>/dev/null \
> +		| grep -q __ARM_PCS_VFP
> +	    then
> +		echo ${UNAME_MACHINE}-unknown-linux-gnueabi
> +	    else
> +		echo ${UNAME_MACHINE}-unknown-linux-gnueabihf
> +	    fi
>   	fi
>   	exit ;;
>       avr32*:Linux:*:*)
>   	echo ${UNAME_MACHINE}-unknown-linux-gnu
>   	exit ;;
>       cris:Linux:*:*)
> -	echo cris-axis-linux-gnu
> +	echo ${UNAME_MACHINE}-axis-linux-gnu
>   	exit ;;
>       crisv32:Linux:*:*)
> -	echo crisv32-axis-linux-gnu
> +	echo ${UNAME_MACHINE}-axis-linux-gnu
>   	exit ;;
>       frv:Linux:*:*)
> -    	echo frv-unknown-linux-gnu
> +	echo ${UNAME_MACHINE}-unknown-linux-gnu
> +	exit ;;
> +    hexagon:Linux:*:*)
> +	echo ${UNAME_MACHINE}-unknown-linux-gnu
>   	exit ;;
>       i*86:Linux:*:*)
>   	LIBC=gnu
> @@ -937,7 +960,7 @@ EOF
>   	test x"${CPU}" != x&&  { echo "${CPU}-unknown-linux-gnu"; exit; }
>   	;;
>       or32:Linux:*:*)
> -	echo or32-unknown-linux-gnu
> +	echo ${UNAME_MACHINE}-unknown-linux-gnu
>   	exit ;;
>       padre:Linux:*:*)
>   	echo sparc-unknown-linux-gnu
> @@ -963,7 +986,7 @@ EOF
>   	echo ${UNAME_MACHINE}-ibm-linux
>   	exit ;;
>       sh64*:Linux:*:*)
> -    	echo ${UNAME_MACHINE}-unknown-linux-gnu
> +	echo ${UNAME_MACHINE}-unknown-linux-gnu
>   	exit ;;
>       sh*:Linux:*:*)
>   	echo ${UNAME_MACHINE}-unknown-linux-gnu
> @@ -972,16 +995,16 @@ EOF
>   	echo ${UNAME_MACHINE}-unknown-linux-gnu
>   	exit ;;
>       tile*:Linux:*:*)
> -	echo ${UNAME_MACHINE}-tilera-linux-gnu
> +	echo ${UNAME_MACHINE}-unknown-linux-gnu
>   	exit ;;
>       vax:Linux:*:*)
>   	echo ${UNAME_MACHINE}-dec-linux-gnu
>   	exit ;;
>       x86_64:Linux:*:*)
> -	echo x86_64-unknown-linux-gnu
> +	echo ${UNAME_MACHINE}-unknown-linux-gnu
>   	exit ;;
>       xtensa*:Linux:*:*)
> -    	echo ${UNAME_MACHINE}-unknown-linux-gnu
> +	echo ${UNAME_MACHINE}-unknown-linux-gnu
>   	exit ;;
>       i*86:DYNIX/ptx:4*:*)
>   	# ptx 4.0 does uname -s correctly, with DYNIX/ptx in there.
> @@ -990,11 +1013,11 @@ EOF
>   	echo i386-sequent-sysv4
>   	exit ;;
>       i*86:UNIX_SV:4.2MP:2.*)
> -        # Unixware is an offshoot of SVR4, but it has its own version
> -        # number series starting with 2...
> -        # I am not positive that other SVR4 systems won't match this,
> +	# Unixware is an offshoot of SVR4, but it has its own version
> +	# number series starting with 2...
> +	# I am not positive that other SVR4 systems won't match this,
>   	# I just have to hope.  -- rms.
> -        # Use sysv4.2uw... so that sysv4* matches it.
> +	# Use sysv4.2uw... so that sysv4* matches it.
>   	echo ${UNAME_MACHINE}-pc-sysv4.2uw${UNAME_VERSION}
>   	exit ;;
>       i*86:OS/2:*:*)
> @@ -1026,7 +1049,7 @@ EOF
>   	fi
>   	exit ;;
>       i*86:*:5:[678]*)
> -    	# UnixWare 7.x, OpenUNIX and OpenServer 6.
> +	# UnixWare 7.x, OpenUNIX and OpenServer 6.
>   	case `/bin/uname -X | grep "^Machine"` in
>   	    *486*)	     UNAME_MACHINE=i486 ;;
>   	    *Pentium)	     UNAME_MACHINE=i586 ;;
> @@ -1054,13 +1077,13 @@ EOF
>   	exit ;;
>       pc:*:*:*)
>   	# Left here for compatibility:
> -        # uname -m prints for DJGPP always 'pc', but it prints nothing about
> -        # the processor, so we play safe by assuming i586.
> +	# uname -m prints for DJGPP always 'pc', but it prints nothing about
> +	# the processor, so we play safe by assuming i586.
>   	# Note: whatever this is, it MUST be the same as what config.sub
>   	# prints for the "djgpp" host, or else GDB configury will decide that
>   	# this is a cross-build.
>   	echo i586-pc-msdosdjgpp
> -        exit ;;
> +	exit ;;
>       Intel:Mach:3*:*)
>   	echo i386-pc-mach3
>   	exit ;;
> @@ -1095,8 +1118,8 @@ EOF
>   	/bin/uname -p 2>/dev/null | /bin/grep entium>/dev/null \
>   	&&  { echo i586-ncr-sysv4.3${OS_REL}; exit; } ;;
>       3[34]??:*:4.0:* | 3[34]??,*:*:4.0:*)
> -        /bin/uname -p 2>/dev/null | grep 86>/dev/null \
> -&&  { echo i486-ncr-sysv4; exit; } ;;
> +	/bin/uname -p 2>/dev/null | grep 86>/dev/null \
> +	&&  { echo i486-ncr-sysv4; exit; } ;;
>       NCR*:*:4.2:* | MPRAS*:*:4.2:*)
>   	OS_REL='.3'
>   	test -r /etc/.relid \
> @@ -1139,10 +1162,10 @@ EOF
>   		echo ns32k-sni-sysv
>   	fi
>   	exit ;;
> -    PENTIUM:*:4.0*:*) # Unisys `ClearPath HMP IX 4000' SVR4/MP effort
> -                      # says<Richard.M.Bartel at ccMail.Census.GOV>
> -        echo i586-unisys-sysv4
> -        exit ;;
> +    PENTIUM:*:4.0*:*)	# Unisys `ClearPath HMP IX 4000' SVR4/MP effort
> +			# says<Richard.M.Bartel at ccMail.Census.GOV>
> +	echo i586-unisys-sysv4
> +	exit ;;
>       *:UNIX_System_V:4*:FTX*)
>   	# From Gerald Hewes<hewes at openmarket.com>.
>   	# How about differentiating between stratus architectures? -djm
> @@ -1168,11 +1191,11 @@ EOF
>   	exit ;;
>       R[34]000:*System_V*:*:* | R4000:UNIX_SYSV:*:* | R*000:UNIX_SV:*:*)
>   	if [ -d /usr/nec ]; then
> -	        echo mips-nec-sysv${UNAME_RELEASE}
> +		echo mips-nec-sysv${UNAME_RELEASE}
>   	else
> -	        echo mips-unknown-sysv${UNAME_RELEASE}
> +		echo mips-unknown-sysv${UNAME_RELEASE}
>   	fi
> -        exit ;;
> +	exit ;;
>       BeBox:BeOS:*:*)	# BeOS running on hardware made by Be, PPC only.
>   	echo powerpc-be-beos
>   	exit ;;
> @@ -1185,6 +1208,9 @@ EOF
>       BePC:Haiku:*:*)	# Haiku running on Intel PC compatible.
>   	echo i586-pc-haiku
>   	exit ;;
> +    x86_64:Haiku:*:*)
> +	echo x86_64-unknown-haiku
> +	exit ;;
>       SX-4:SUPER-UX:*:*)
>   	echo sx4-nec-superux${UNAME_RELEASE}
>   	exit ;;
> @@ -1240,7 +1266,7 @@ EOF
>       NEO-?:NONSTOP_KERNEL:*:*)
>   	echo neo-tandem-nsk${UNAME_RELEASE}
>   	exit ;;
> -    NSE-?:NONSTOP_KERNEL:*:*)
> +    NSE-*:NONSTOP_KERNEL:*:*)
>   	echo nse-tandem-nsk${UNAME_RELEASE}
>   	exit ;;
>       NSR-?:NONSTOP_KERNEL:*:*)
> @@ -1285,13 +1311,13 @@ EOF
>   	echo pdp10-unknown-its
>   	exit ;;
>       SEI:*:*:SEIUX)
> -        echo mips-sei-seiux${UNAME_RELEASE}
> +	echo mips-sei-seiux${UNAME_RELEASE}
>   	exit ;;
>       *:DragonFly:*:*)
>   	echo ${UNAME_MACHINE}-unknown-dragonfly`echo ${UNAME_RELEASE}|sed -e 's/[-(].*//'`
>   	exit ;;
>       *:*VMS:*:*)
> -    	UNAME_MACHINE=`(uname -p) 2>/dev/null`
> +	UNAME_MACHINE=`(uname -p) 2>/dev/null`
>   	case "${UNAME_MACHINE}" in
>   	    A*) echo alpha-dec-vms ; exit ;;
>   	    I*) echo ia64-dec-vms ; exit ;;
> @@ -1309,11 +1335,11 @@ EOF
>       i*86:AROS:*:*)
>   	echo ${UNAME_MACHINE}-pc-aros
>   	exit ;;
> +    x86_64:VMkernel:*:*)
> +	echo ${UNAME_MACHINE}-unknown-esx
> +	exit ;;
>   esac
>
> -#echo '(No uname command or uname output not recognized.)' 1>&2
> -#echo "${UNAME_MACHINE}:${UNAME_SYSTEM}:${UNAME_RELEASE}:${UNAME_VERSION}" 1>&2
> -
>   eval $set_cc_for_build
>   cat>$dummy.c<<EOF
>   #ifdef _SEQUENT_
> @@ -1331,11 +1357,11 @@ main ()
>   #include<sys/param.h>
>     printf ("m68k-sony-newsos%s\n",
>   #ifdef NEWSOS4
> -          "4"
> +	"4"
>   #else
> -	  ""
> +	""
>   #endif
> -         ); exit (0);
> +	); exit (0);
>   #endif
>   #endif
>
> Index: config.sub
> ===================================================================
> RCS file: /var/cvs/openssh/config.sub,v
> retrieving revision 1.14
> diff -u -p -r1.14 config.sub
> --- config.sub	26 Jan 2011 20:32:14 -0000	1.14
> +++ config.sub	17 Apr 2013 11:39:19 -0000
> @@ -2,9 +2,9 @@
>   # Configuration validation subroutine script.
>   #   Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999,
>   #   2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010,
> -#   2011 Free Software Foundation, Inc.
> +#   2011, 2012, 2013 Free Software Foundation, Inc.
>
> -timestamp='2011-01-01'
> +timestamp='2012-12-23'
>
>   # This file is (in principle) common to ALL GNU software.
>   # The presence of a machine in this file suggests that SOME GNU software
> @@ -21,9 +21,7 @@ timestamp='2011-01-01'
>   # GNU General Public License for more details.
>   #
>   # You should have received a copy of the GNU General Public License
> -# along with this program; if not, write to the Free Software
> -# Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston, MA
> -# 02110-1301, USA.
> +# along with this program; if not, see<http://www.gnu.org/licenses/>.
>   #
>   # As a special exception to the GNU General Public License, if you
>   # distribute this file as part of a program that contains a
> @@ -76,8 +74,8 @@ version="\
>   GNU config.sub ($timestamp)
>
>   Copyright (C) 1992, 1993, 1994, 1995, 1996, 1997, 1998, 1999, 2000,
> -2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010 Free
> -Software Foundation, Inc.
> +2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011,
> +2012, 2013 Free Software Foundation, Inc.
>
>   This is free software; see the source for copying conditions.  There is NO
>   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE."
> @@ -125,13 +123,17 @@ esac
>   maybe_os=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\2/'`
>   case $maybe_os in
>     nto-qnx* | linux-gnu* | linux-android* | linux-dietlibc | linux-newlib* | \
> -  linux-uclibc* | uclinux-uclibc* | uclinux-gnu* | kfreebsd*-gnu* | \
> +  linux-musl* | linux-uclibc* | uclinux-uclibc* | uclinux-gnu* | kfreebsd*-gnu* | \
>     knetbsd*-gnu* | netbsd*-gnu* | \
>     kopensolaris*-gnu* | \
>     storm-chaos* | os2-emx* | rtmk-nova*)
>       os=-$maybe_os
>       basic_machine=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\1/'`
>       ;;
> +  android-linux)
> +    os=-linux-android
> +    basic_machine=`echo $1 | sed 's/^\(.*\)-\([^-]*-[^-]*\)$/\1/'`-unknown
> +    ;;
>     *)
>       basic_machine=`echo $1 | sed 's/-[^-]*$//'`
>       if [ $basic_machine != $1 ]
> @@ -154,12 +156,12 @@ case $os in
>   	-convergent* | -ncr* | -news | -32* | -3600* | -3100* | -hitachi* |\
>   	-c[123]* | -convex* | -sun | -crds | -omron* | -dg | -ultra | -tti* | \
>   	-harris | -dolphin | -highlevel | -gould | -cbm | -ns | -masscomp | \
> -	-apple | -axis | -knuth | -cray | -microblaze)
> +	-apple | -axis | -knuth | -cray | -microblaze*)
>   		os=
>   		basic_machine=$1
>   		;;
> -        -bluegene*)
> -	        os=-cnk
> +	-bluegene*)
> +		os=-cnk
>   		;;
>   	-sim | -cisco | -oki | -wec | -winbond)
>   		os=
> @@ -175,10 +177,10 @@ case $os in
>   		os=-chorusos
>   		basic_machine=$1
>   		;;
> - 	-chorusrdb)
> - 		os=-chorusrdb
> +	-chorusrdb)
> +		os=-chorusrdb
>   		basic_machine=$1
> - 		;;
> +		;;
>   	-hiux*)
>   		os=-hiuxwe2
>   		;;
> @@ -223,6 +225,12 @@ case $os in
>   	-isc*)
>   		basic_machine=`echo $1 | sed -e 's/86-.*/86-pc/'`
>   		;;
> +	-lynx*178)
> +		os=-lynxos178
> +		;;
> +	-lynx*5)
> +		os=-lynxos5
> +		;;
>   	-lynx*)
>   		os=-lynxos
>   		;;
> @@ -247,20 +255,27 @@ case $basic_machine in
>   	# Some are omitted here because they have special meanings below.
>   	1750a | 580 \
>   	| a29k \
> +	| aarch64 | aarch64_be \
>   	| alpha | alphaev[4-8] | alphaev56 | alphaev6[78] | alphapca5[67] \
>   	| alpha64 | alpha64ev[4-8] | alpha64ev56 | alpha64ev6[78] | alpha64pca5[67] \
>   	| am33_2.0 \
> -	| arc | arm | arm[bl]e | arme[lb] | armv[2345] | armv[345][lb] | avr | avr32 \
> +	| arc \
> +	| arm | arm[bl]e | arme[lb] | armv[2-8] | armv[3-8][lb] | armv7[arm] \
> +	| avr | avr32 \
> +	| be32 | be64 \
>   	| bfin \
>   	| c4x | clipper \
>   	| d10v | d30v | dlx | dsp16xx \
> +	| epiphany \
>   	| fido | fr30 | frv \
>   	| h8300 | h8500 | hppa | hppa1.[01] | hppa2.0 | hppa2.0[nw] | hppa64 \
> +	| hexagon \
>   	| i370 | i860 | i960 | ia64 \
>   	| ip2k | iq2000 \
> +	| le32 | le64 \
>   	| lm32 \
>   	| m32c | m32r | m32rle | m68000 | m68k | m88k \
> -	| maxq | mb | microblaze | mcore | mep | metag \
> +	| maxq | mb | microblaze | microblazeel | mcore | mep | metag \
>   	| mips | mipsbe | mipseb | mipsel | mipsle \
>   	| mips16 \
>   	| mips64 | mips64el \
> @@ -286,22 +301,23 @@ case $basic_machine in
>   	| nds32 | nds32le | nds32be \
>   	| nios | nios2 \
>   	| ns16k | ns32k \
> +	| open8 \
>   	| or32 \
>   	| pdp10 | pdp11 | pj | pjl \
> -	| powerpc | powerpc64 | powerpc64le | powerpcle | ppcbe \
> +	| powerpc | powerpc64 | powerpc64le | powerpcle \
>   	| pyramid \
> -	| rx \
> +	| rl78 | rx \
>   	| score \
>   	| sh | sh[1234] | sh[24]a | sh[24]aeb | sh[23]e | sh[34]eb | sheb | shbe | shle | sh[1234]le | sh3ele \
>   	| sh64 | sh64le \
>   	| sparc | sparc64 | sparc64b | sparc64v | sparc86x | sparclet | sparclite \
>   	| sparcv8 | sparcv9 | sparcv9b | sparcv9v \
> -	| spu | strongarm \
> -	| tahoe | thumb | tic4x | tic54x | tic55x | tic6x | tic80 | tron \
> +	| spu \
> +	| tahoe | tic4x | tic54x | tic55x | tic6x | tic80 | tron \
>   	| ubicom32 \
> -	| v850 | v850e \
> +	| v850 | v850e | v850e1 | v850e2 | v850es | v850e2v3 \
>   	| we32k \
> -	| x86 | xc16x | xscale | xscalee[bl] | xstormy16 | xtensa \
> +	| x86 | xc16x | xstormy16 | xtensa \
>   	| z8k | z80)
>   		basic_machine=$basic_machine-unknown
>   		;;
> @@ -314,8 +330,7 @@ case $basic_machine in
>   	c6x)
>   		basic_machine=tic6x-unknown
>   		;;
> -	m6811 | m68hc11 | m6812 | m68hc12 | picochip)
> -		# Motorola 68HC11/12.
> +	m6811 | m68hc11 | m6812 | m68hc12 | m68hcs12x | picochip)
>   		basic_machine=$basic_machine-unknown
>   		os=-none
>   		;;
> @@ -325,6 +340,21 @@ case $basic_machine in
>   		basic_machine=mt-unknown
>   		;;
>
> +	strongarm | thumb | xscale)
> +		basic_machine=arm-unknown
> +		;;
> +	xgate)
> +		basic_machine=$basic_machine-unknown
> +		os=-none
> +		;;
> +	xscaleeb)
> +		basic_machine=armeb-unknown
> +		;;
> +
> +	xscaleel)
> +		basic_machine=armel-unknown
> +		;;
> +
>   	# We use `pc' rather than `unknown'
>   	# because (1) that's what they normally are, and
>   	# (2) the word "unknown" tends to confuse beginning users.
> @@ -339,11 +369,13 @@ case $basic_machine in
>   	# Recognize the basic CPU types with company name.
>   	580-* \
>   	| a29k-* \
> +	| aarch64-* | aarch64_be-* \
>   	| alpha-* | alphaev[4-8]-* | alphaev56-* | alphaev6[78]-* \
>   	| alpha64-* | alpha64ev[4-8]-* | alpha64ev56-* | alpha64ev6[78]-* \
>   	| alphapca5[67]-* | alpha64pca5[67]-* | arc-* \
>   	| arm-*  | armbe-* | armle-* | armeb-* | armv*-* \
>   	| avr-* | avr32-* \
> +	| be32-* | be64-* \
>   	| bfin-* | bs2000-* \
>   	| c[123]* | c30-* | [cjt]90-* | c4x-* \
>   	| clipper-* | craynv-* | cydra-* \
> @@ -352,12 +384,15 @@ case $basic_machine in
>   	| f30[01]-* | f700-* | fido-* | fr30-* | frv-* | fx80-* \
>   	| h8300-* | h8500-* \
>   	| hppa-* | hppa1.[01]-* | hppa2.0-* | hppa2.0[nw]-* | hppa64-* \
> +	| hexagon-* \
>   	| i*86-* | i860-* | i960-* | ia64-* \
>   	| ip2k-* | iq2000-* \
> +	| le32-* | le64-* \
>   	| lm32-* \
>   	| m32c-* | m32r-* | m32rle-* \
>   	| m68000-* | m680[012346]0-* | m68360-* | m683?2-* | m68k-* \
> -	| m88110-* | m88k-* | maxq-* | mcore-* | metag-* | microblaze-* \
> +	| m88110-* | m88k-* | maxq-* | mcore-* | metag-* \
> +	| microblaze-* | microblazeel-* \
>   	| mips-* | mipsbe-* | mipseb-* | mipsel-* | mipsle-* \
>   	| mips16-* \
>   	| mips64-* | mips64el-* \
> @@ -382,24 +417,26 @@ case $basic_machine in
>   	| nds32-* | nds32le-* | nds32be-* \
>   	| nios-* | nios2-* \
>   	| none-* | np1-* | ns16k-* | ns32k-* \
> +	| open8-* \
>   	| orion-* \
>   	| pdp10-* | pdp11-* | pj-* | pjl-* | pn-* | power-* \
> -	| powerpc-* | powerpc64-* | powerpc64le-* | powerpcle-* | ppcbe-* \
> +	| powerpc-* | powerpc64-* | powerpc64le-* | powerpcle-* \
>   	| pyramid-* \
> -	| romp-* | rs6000-* | rx-* \
> +	| rl78-* | romp-* | rs6000-* | rx-* \
>   	| sh-* | sh[1234]-* | sh[24]a-* | sh[24]aeb-* | sh[23]e-* | sh[34]eb-* | sheb-* | shbe-* \
>   	| shle-* | sh[1234]le-* | sh3ele-* | sh64-* | sh64le-* \
>   	| sparc-* | sparc64-* | sparc64b-* | sparc64v-* | sparc86x-* | sparclet-* \
>   	| sparclite-* \
> -	| sparcv8-* | sparcv9-* | sparcv9b-* | sparcv9v-* | strongarm-* | sv1-* | sx?-* \
> -	| tahoe-* | thumb-* \
> +	| sparcv8-* | sparcv9-* | sparcv9b-* | sparcv9v-* | sv1-* | sx?-* \
> +	| tahoe-* \
>   	| tic30-* | tic4x-* | tic54x-* | tic55x-* | tic6x-* | tic80-* \
> -	| tile-* | tilegx-* \
> +	| tile*-* \
>   	| tron-* \
>   	| ubicom32-* \
> -	| v850-* | v850e-* | vax-* \
> +	| v850-* | v850e-* | v850e1-* | v850es-* | v850e2-* | v850e2v3-* \
> +	| vax-* \
>   	| we32k-* \
> -	| x86-* | x86_64-* | xc16x-* | xps100-* | xscale-* | xscalee[bl]-* \
> +	| x86-* | x86_64-* | xc16x-* | xps100-* \
>   	| xstormy16-* | xtensa*-* \
>   	| ymp-* \
>   	| z8k-* | z80-*)
> @@ -424,7 +461,7 @@ case $basic_machine in
>   		basic_machine=a29k-amd
>   		os=-udi
>   		;;
> -    	abacus)
> +	abacus)
>   		basic_machine=abacus-unknown
>   		;;
>   	adobe68k)
> @@ -507,7 +544,7 @@ case $basic_machine in
>   		basic_machine=c90-cray
>   		os=-unicos
>   		;;
> -        cegcc)
> +	cegcc)
>   		basic_machine=arm-unknown
>   		os=-cegcc
>   		;;
> @@ -697,7 +734,6 @@ case $basic_machine in
>   	i370-ibm* | ibm*)
>   		basic_machine=i370-ibm
>   		;;
> -# I'm not sure what "Sysv32" means.  Should this be sysv3.2?
>   	i*86v32)
>   		basic_machine=`echo $1 | sed -e 's/86.*/86-pc/'`
>   		os=-sysv32
> @@ -755,9 +791,13 @@ case $basic_machine in
>   		basic_machine=ns32k-utek
>   		os=-sysv
>   		;;
> -        microblaze)
> +	microblaze*)
>   		basic_machine=microblaze-xilinx
>   		;;
> +	mingw64)
> +		basic_machine=x86_64-pc
> +		os=-mingw64
> +		;;
>   	mingw32)
>   		basic_machine=i386-pc
>   		os=-mingw32
> @@ -794,10 +834,18 @@ case $basic_machine in
>   	ms1-*)
>   		basic_machine=`echo $basic_machine | sed -e 's/ms1-/mt-/'`
>   		;;
> +	msys)
> +		basic_machine=i386-pc
> +		os=-msys
> +		;;
>   	mvs)
>   		basic_machine=i370-ibm
>   		os=-mvs
>   		;;
> +	nacl)
> +		basic_machine=le32-unknown
> +		os=-nacl
> +		;;
>   	ncr3000)
>   		basic_machine=i486-ncr
>   		os=-sysv4
> @@ -862,10 +910,10 @@ case $basic_machine in
>   	np1)
>   		basic_machine=np1-gould
>   		;;
> -        neo-tandem)
> +	neo-tandem)
>   		basic_machine=neo-tandem
>   		;;
> -        nse-tandem)
> +	nse-tandem)
>   		basic_machine=nse-tandem
>   		;;
>   	nsr-tandem)
> @@ -950,9 +998,10 @@ case $basic_machine in
>   		;;
>   	power)	basic_machine=power-ibm
>   		;;
> -	ppc)	basic_machine=powerpc-unknown
> +	ppc | ppcbe)	basic_machine=powerpc-unknown
>   		;;
> -	ppc-*)	basic_machine=powerpc-`echo $basic_machine | sed 's/^[^-]*-//'`
> +	ppc-* | ppcbe-*)
> +		basic_machine=powerpc-`echo $basic_machine | sed 's/^[^-]*-//'`
>   		;;
>   	ppcle | powerpclittle | ppc-le | powerpc-little)
>   		basic_machine=powerpcle-unknown
> @@ -977,7 +1026,11 @@ case $basic_machine in
>   		basic_machine=i586-unknown
>   		os=-pw32
>   		;;
> -	rdos)
> +	rdos | rdos64)
> +		basic_machine=x86_64-pc
> +		os=-rdos
> +		;;
> +	rdos32)
>   		basic_machine=i386-pc
>   		os=-rdos
>   		;;
> @@ -1046,6 +1099,9 @@ case $basic_machine in
>   		basic_machine=i860-stratus
>   		os=-sysv4
>   		;;
> +	strongarm-* | thumb-*)
> +		basic_machine=arm-`echo $basic_machine | sed 's/^[^-]*-//'`
> +		;;
>   	sun2)
>   		basic_machine=m68000-sun
>   		;;
> @@ -1102,13 +1158,8 @@ case $basic_machine in
>   		basic_machine=t90-cray
>   		os=-unicos
>   		;;
> -        # This must be matched before tile*.
> -        tilegx*)
> -		basic_machine=tilegx-unknown
> -		os=-linux-gnu
> -		;;
>   	tile*)
> -		basic_machine=tile-unknown
> +		basic_machine=$basic_machine-unknown
>   		os=-linux-gnu
>   		;;
>   	tx39)
> @@ -1178,6 +1229,9 @@ case $basic_machine in
>   	xps | xps100)
>   		basic_machine=xps100-honeywell
>   		;;
> +	xscale-* | xscalee[bl]-*)
> +		basic_machine=`echo $basic_machine | sed 's/^xscale/arm/'`
> +		;;
>   	ymp)
>   		basic_machine=ymp-cray
>   		os=-unicos
> @@ -1275,11 +1329,11 @@ esac
>   if [ x"$os" != x"" ]
>   then
>   case $os in
> -        # First match some system type aliases
> -        # that might get confused with valid system types.
> +	# First match some system type aliases
> +	# that might get confused with valid system types.
>   	# -solaris* is a basic system type, with this one exception.
> -        -auroraux)
> -	        os=-auroraux
> +	-auroraux)
> +		os=-auroraux
>   		;;
>   	-solaris1 | -solaris1.*)
>   		os=`echo $os | sed -e 's|solaris1|sunos4|'`
> @@ -1309,15 +1363,15 @@ case $os in
>   	      | -nindy* | -vxsim* | -vxworks* | -ebmon* | -hms* | -mvs* \
>   	      | -clix* | -riscos* | -uniplus* | -iris* | -rtu* | -xenix* \
>   	      | -hiux* | -386bsd* | -knetbsd* | -mirbsd* | -netbsd* \
> -	      | -openbsd* | -solidbsd* \
> +	      | -bitrig* | -openbsd* | -solidbsd* \
>   	      | -ekkobsd* | -kfreebsd* | -freebsd* | -riscix* | -lynxos* \
>   	      | -bosx* | -nextstep* | -cxux* | -aout* | -elf* | -oabi* \
>   	      | -ptx* | -coff* | -ecoff* | -winnt* | -domain* | -vsta* \
>   	      | -udi* | -eabi* | -lites* | -ieee* | -go32* | -aux* \
>   	      | -chorusos* | -chorusrdb* | -cegcc* \
> -	      | -cygwin* | -pe* | -psos* | -moss* | -proelf* | -rtems* \
> -	      | -mingw32* | -linux-gnu* | -linux-android* \
> -	      | -linux-newlib* | -linux-uclibc* \
> +	      | -cygwin* | -msys* | -pe* | -psos* | -moss* | -proelf* | -rtems* \
> +	      | -mingw32* | -mingw64* | -linux-gnu* | -linux-android* \
> +	      | -linux-newlib* | -linux-musl* | -linux-uclibc* \
>   	      | -uxpv* | -beos* | -mpeix* | -udk* \
>   	      | -interix* | -uwin* | -mks* | -rhapsody* | -darwin* | -opened* \
>   	      | -openstep* | -oskit* | -conix* | -pw32* | -nonstopux* \
> @@ -1364,7 +1418,7 @@ case $os in
>   	-opened*)
>   		os=-openedition
>   		;;
> -        -os400*)
> +	-os400*)
>   		os=-os400
>   		;;
>   	-wince*)
> @@ -1413,7 +1467,7 @@ case $os in
>   	-sinix*)
>   		os=-sysv4
>   		;;
> -        -tpf*)
> +	-tpf*)
>   		os=-tpf
>   		;;
>   	-triton*)
> @@ -1458,8 +1512,8 @@ case $os in
>   	-dicos*)
>   		os=-dicos
>   		;;
> -        -nacl*)
> -	        ;;
> +	-nacl*)
> +		;;
>   	-none)
>   		;;
>   	*)
> @@ -1482,10 +1536,10 @@ else
>   # system, and we'll never get to this point.
>
>   case $basic_machine in
> -        score-*)
> +	score-*)
>   		os=-elf
>   		;;
> -        spu-*)
> +	spu-*)
>   		os=-elf
>   		;;
>   	*-acorn)
> @@ -1497,8 +1551,11 @@ case $basic_machine in
>   	arm*-semi)
>   		os=-aout
>   		;;
> -        c4x-* | tic4x-*)
> -        	os=-coff
> +	c4x-* | tic4x-*)
> +		os=-coff
> +		;;
> +	hexagon-*)
> +		os=-elf
>   		;;
>   	tic54x-*)
>   		os=-coff
> @@ -1527,14 +1584,11 @@ case $basic_machine in
>   		;;
>   	m68000-sun)
>   		os=-sunos3
> -		# This also exists in the configure program, but was not the
> -		# default.
> -		# os=-sunos4
>   		;;
>   	m68*-cisco)
>   		os=-aout
>   		;;
> -        mep-*)
> +	mep-*)
>   		os=-elf
>   		;;
>   	mips*-cisco)
> @@ -1561,7 +1615,7 @@ case $basic_machine in
>   	*-ibm)
>   		os=-aix
>   		;;
> -    	*-knuth)
> +	*-knuth)
>   		os=-mmixware
>   		;;
>   	*-wec)


From imorgan at nas.nasa.gov  Thu Apr 18 09:03:11 2013
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Wed, 17 Apr 2013 16:03:11 -0700
Subject: additional compiler hardening flags
In-Reply-To: <20130322050815.GA6024@gate.dtucker.net>
References: <20130322050815.GA6024@gate.dtucker.net>
Message-ID: <20130417230311.GD17666@linux124.nas.nasa.gov>

Hello Darren,

Seeing as no one has responded on the list regarding this, I wanted to
give a brief response. I applied your proposed changes to the 6.2p1
release and have been running it for some time now. I'm not prepared to
comment on the individual compiler/linker options, but they seem
reasonable at a glance.

The only complication which I encountered was that it failed to link a
local build of OpenSSL. Once I rebuilt OpenSSL with -fPIC, everything
was find.

On Fri, Mar 22, 2013 at 00:08:15 -0500, Darren Tucker wrote:
> Hi all.
> 
> Any reason not to turn these on if the system supports them?  They're
> cheap but not free (a bit under 1% slower to run the complete regress
> suite in a completely unscientific test).
> 
> They're based on info from these places:
> https://wiki.ubuntu.com/ToolChain/CompilerFlags
> http://wiki.debian.org/Hardening
> http://www.gentoo.org/proj/en/hardened/gnu-stack.xml
> and I've attempted to take the ones that make sense for openssh.
> 
> >From my reading, -fPIE should be sufficient since we're not building a
> shared library, however having -fPIC to does not seem to hurt.
> 
> Things in those pages that I don't think are needed:
>  -Wa,--noexecstack (don't have any assembler sources) .
>  --param=ssp-buffer-size=4 (superceded by -fstack-protector-all)
> 
> Tests/comments/corrections welcome.
> 
> Index: Makefile.in
> ===================================================================
> RCS file: /home/dtucker/openssh/cvs/openssh/Makefile.in,v
> retrieving revision 1.336
> diff -u -p -r1.336 Makefile.in
> --- Makefile.in	7 Mar 2013 15:37:13 -0000	1.336
> +++ Makefile.in	22 Mar 2013 02:42:20 -0000
> @@ -383,7 +383,7 @@ uninstall:
>  
>  regress/modpipe$(EXEEXT): $(srcdir)/regress/modpipe.c
>  	[ -d `pwd`/regress ]  ||  mkdir -p `pwd`/regress; \
> -	$(CC) $(CPPFLAGS) -o $@ $? \
> +	$(CC) $(CPPFLAGS) $(CFLAGS) -o $@ $? \
>  	$(LDFLAGS) -lopenbsd-compat -lssh -lopenbsd-compat $(LIBS)
>  
>  tests interop-tests:	$(TARGETS) regress/modpipe$(EXEEXT)
> Index: aclocal.m4
> ===================================================================
> RCS file: /home/dtucker/openssh/cvs/openssh/aclocal.m4,v
> retrieving revision 1.8
> diff -u -p -r1.8 aclocal.m4
> --- aclocal.m4	20 May 2011 01:45:25 -0000	1.8
> +++ aclocal.m4	22 Mar 2013 02:42:20 -0000
> @@ -21,6 +21,23 @@ AC_DEFUN([OSSH_CHECK_CFLAG_COMPILE], [{
>  	)
>  }])
>  
> +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 $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.519
> diff -u -p -r1.519 configure.ac
> --- configure.ac	22 Mar 2013 01:49:15 -0000	1.519
> +++ configure.ac	22 Mar 2013 04:45:37 -0000
> @@ -138,6 +138,13 @@ 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])
> +	OSSH_CHECK_CFLAG_COMPILE([-ftrapv])
> +	OSSH_CHECK_CFLAG_COMPILE([-fPIC])
> +	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])
>  	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.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

-- 
Iain Morgan

From dtucker at zip.com.au  Thu Apr 18 11:16:13 2013
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 18 Apr 2013 11:16:13 +1000
Subject: additional compiler hardening flags
In-Reply-To: <20130417230311.GD17666@linux124.nas.nasa.gov>
References: <20130322050815.GA6024@gate.dtucker.net>
 <20130417230311.GD17666@linux124.nas.nasa.gov>
Message-ID: <20130418011613.GA16696@gate.dtucker.net>

On Wed, Apr 17, 2013 at 04:03:11PM -0700, Iain Morgan wrote:
> Hello Darren,
> 
> Seeing as no one has responded on the list regarding this, I wanted to
> give a brief response. I applied your proposed changes to the 6.2p1
> release and have been running it for some time now. I'm not prepared to
> comment on the individual compiler/linker options, but they seem
> reasonable at a glance.

After doing some more reading, I don't think we need -fPIC for openssh
since that's only applicable to shared libraries, and -fPIE is
sufficient for static libraries and executables.

> The only complication which I encountered was that it failed to link a
> local build of OpenSSL. Once I rebuilt OpenSSL with -fPIC, everything
> was find.

Thanks.  What configuration was that?  (platform/compiler/flags/openssl
version?)  I tried several variations on linux (fedora, gcc 4.6.3,
openssl 1.0.1e) and it always produced a working binary.

Anyway, we could easily add a configure knob to turn it off should that
be necessary.

-- 
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  Thu Apr 18 11:41:00 2013
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 18 Apr 2013 11:41:00 +1000
Subject: additional compiler hardening flags
In-Reply-To: <20130418011613.GA16696@gate.dtucker.net>
References: <20130322050815.GA6024@gate.dtucker.net>
 <20130417230311.GD17666@linux124.nas.nasa.gov>
 <20130418011613.GA16696@gate.dtucker.net>
Message-ID: <20130418014100.GA30605@gate.dtucker.net>

On Thu, Apr 18, 2013 at 11:16:13AM +1000, Darren Tucker wrote:
> Anyway, we could easily add a configure knob to turn it off should that
> be necessary.

here's an updated patch without -fPIC, and with a configure knob
(--without-hardening) to turn this off.

Index: Makefile.in
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/Makefile.in,v
retrieving revision 1.337
diff -u -p -r1.337 Makefile.in
--- Makefile.in	22 Mar 2013 17:14:33 -0000	1.337
+++ Makefile.in	27 Mar 2013 00:37:08 -0000
@@ -385,7 +385,7 @@ regress/modpipe$(EXEEXT): $(srcdir)/regr
 	[ -d `pwd`/regress ]  ||  mkdir -p `pwd`/regress
 	[ -f `pwd`/regress/Makefile ]  || \
 	    ln -s `cd $(srcdir) && pwd`/regress/Makefile `pwd`/regress/Makefile
-	$(CC) $(CPPFLAGS) -o $@ $? \
+	$(CC) $(CPPFLAGS) $(CFLAGS) -o $@ $? \
 	$(LDFLAGS) -lopenbsd-compat -lssh -lopenbsd-compat $(LIBS)
 
 tests interop-tests:	$(TARGETS) regress/modpipe$(EXEEXT)
Index: aclocal.m4
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/aclocal.m4,v
retrieving revision 1.8
diff -u -p -r1.8 aclocal.m4
--- aclocal.m4	20 May 2011 01:45:25 -0000	1.8
+++ aclocal.m4	22 Mar 2013 02:42:20 -0000
@@ -21,6 +21,23 @@ AC_DEFUN([OSSH_CHECK_CFLAG_COMPILE], [{
 	)
 }])
 
+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 $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.519
diff -u -p -r1.519 configure.ac
--- configure.ac	22 Mar 2013 01:49:15 -0000	1.519
+++ configure.ac	18 Apr 2013 01:31:24 -0000
@@ -121,12 +121,18 @@ 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 ])
 
 if test "$GCC" = "yes" || test "$GCC" = "egcs"; then
 	OSSH_CHECK_CFLAG_COMPILE([-Wall])
@@ -138,6 +144,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 vinschen at redhat.com  Thu Apr 18 17:16:22 2013
From: vinschen at redhat.com (Corinna Vinschen)
Date: Thu, 18 Apr 2013 09:16:22 +0200
Subject: additional compiler hardening flags
In-Reply-To: <20130418014100.GA30605@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>
Message-ID: <20130418071622.GA3059@calimero.vinschen.de>

Hi Darren,

On Apr 18 11:41, Darren Tucker wrote:
> On Thu, Apr 18, 2013 at 11:16:13AM +1000, Darren Tucker wrote:
> > Anyway, we could easily add a configure knob to turn it off should that
> > be necessary.
> 
> here's an updated patch without -fPIC, and with a configure knob
> (--without-hardening) to turn this off.
> [...]
> +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 $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" ]
> +	)
> +}])

Does this check also catch the situation that commandline options
are only warned about?  On PE/COFF platforms, the -fPIE option is
ignored, but the build will then be littered with warnings:

   $ gcc -fPIE -c x.c
   x.c:1:0: warning: -fPIC ignored for target (all code is position independent) [enabled by default]
    #include <stdio.h>
    ^


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

From dtucker at zip.com.au  Thu Apr 18 18:22:00 2013
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 18 Apr 2013 18:22:00 +1000
Subject: additional compiler hardening flags
In-Reply-To: <20130418071622.GA3059@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>
 <20130418071622.GA3059@calimero.vinschen.de>
Message-ID: <20130418082200.GA32447@gate.dtucker.net>

On Thu, Apr 18, 2013 at 09:16:22AM +0200, Corinna Vinschen wrote:
> Does this check also catch the situation that commandline options
> are only warned about?  On PE/COFF platforms, the -fPIE option is
> ignored, but the build will then be littered with warnings:
> 
>    $ gcc -fPIE -c x.c
>    x.c:1:0: warning: -fPIC ignored for target (all code is position independent) [enabled by default]

As long as the compile or link succeeded it'd set the flag.  We could
add -Werror to the tests to prevent that in those cases, like so:

Index: Makefile.in
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/Makefile.in,v
retrieving revision 1.337
diff -u -p -r1.337 Makefile.in
--- Makefile.in	22 Mar 2013 17:14:33 -0000	1.337
+++ Makefile.in	27 Mar 2013 00:37:08 -0000
@@ -385,7 +385,7 @@ regress/modpipe$(EXEEXT): $(srcdir)/regr
 	[ -d `pwd`/regress ]  ||  mkdir -p `pwd`/regress
 	[ -f `pwd`/regress/Makefile ]  || \
 	    ln -s `cd $(srcdir) && pwd`/regress/Makefile `pwd`/regress/Makefile
-	$(CC) $(CPPFLAGS) -o $@ $? \
+	$(CC) $(CPPFLAGS) $(CFLAGS) -o $@ $? \
 	$(LDFLAGS) -lopenbsd-compat -lssh -lopenbsd-compat $(LIBS)
 
 tests interop-tests:	$(TARGETS) regress/modpipe$(EXEEXT)
Index: aclocal.m4
===================================================================
RCS file: /home/dtucker/openssh/cvs/openssh/aclocal.m4,v
retrieving revision 1.8
diff -u -p -r1.8 aclocal.m4
--- aclocal.m4	20 May 2011 01:45:25 -0000	1.8
+++ aclocal.m4	22 Mar 2013 02:42:20 -0000
@@ -21,6 +21,23 @@ AC_DEFUN([OSSH_CHECK_CFLAG_COMPILE], [{
 	)
 }])
 
+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 $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.519
diff -u -p -r1.519 configure.ac
--- configure.ac	22 Mar 2013 01:49:15 -0000	1.519
+++ configure.ac	18 Apr 2013 08:19:30 -0000
@@ -121,12 +121,18 @@ 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 ])
 
 if test "$GCC" = "yes" || test "$GCC" = "egcs"; then
 	OSSH_CHECK_CFLAG_COMPILE([-Wall])
@@ -138,6 +144,16 @@ 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
+	# these tests are done with -Werror so that we don't get warnings
+	# when things like -fPIE are enabled by default.
+	OSSH_CHECK_CFLAG_COMPILE([-ftrapv -Werror], [-ftrapv])
+	OSSH_CHECK_CFLAG_COMPILE([-fPIE -Werror], [-fPIE])
+	OSSH_CHECK_LDFLAG_LINK([-pie -Werror], [-pie])
+	OSSH_CHECK_LDFLAG_LINK([-Wl,-z,relro -Werror], [-Wl,-z,relro])
+	OSSH_CHECK_LDFLAG_LINK([-Wl,-z,now -Werror], [-Wl,-z,now])
+	OSSH_CHECK_LDFLAG_LINK([-Wl,-z,noexecstack -Werror], [-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 vinschen at redhat.com  Thu Apr 18 18:23:57 2013
From: vinschen at redhat.com (Corinna Vinschen)
Date: Thu, 18 Apr 2013 10:23:57 +0200
Subject: additional compiler hardening flags
In-Reply-To: <20130418071622.GA3059@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>
 <20130418071622.GA3059@calimero.vinschen.de>
Message-ID: <20130418082357.GC4188@calimero.vinschen.de>

On Apr 18 09:16, Corinna Vinschen wrote:
> Hi Darren,
> 
> On Apr 18 11:41, Darren Tucker wrote:
> > On Thu, Apr 18, 2013 at 11:16:13AM +1000, Darren Tucker wrote:
> > > Anyway, we could easily add a configure knob to turn it off should that
> > > be necessary.
> > 
> > here's an updated patch without -fPIC, and with a configure knob
> > (--without-hardening) to turn this off.
> > [...]
> > +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 $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" ]
> > +	)
> > +}])
> 
> Does this check also catch the situation that commandline options
> are only warned about?  On PE/COFF platforms, the -fPIE option is
> ignored, but the build will then be littered with warnings:
> 
>    $ gcc -fPIE -c x.c
           ^^^^^

>    x.c:1:0: warning: -fPIC ignored for target (all code is position independent) [enabled by default]
                       ^^^^^

Yes, that's not a typo or copy/paster error on my part.  gcc returns
this text even when using the -fPIE option.


>     #include <stdio.h>
>     ^


Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

From vinschen at redhat.com  Thu Apr 18 19:29:55 2013
From: vinschen at redhat.com (Corinna Vinschen)
Date: Thu, 18 Apr 2013 11:29:55 +0200
Subject: additional compiler hardening flags
In-Reply-To: <20130418082200.GA32447@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>
 <20130418071622.GA3059@calimero.vinschen.de>
 <20130418082200.GA32447@gate.dtucker.net>
Message-ID: <20130418092955.GA5562@calimero.vinschen.de>

On Apr 18 18:22, Darren Tucker wrote:
> On Thu, Apr 18, 2013 at 09:16:22AM +0200, Corinna Vinschen wrote:
> > Does this check also catch the situation that commandline options
> > are only warned about?  On PE/COFF platforms, the -fPIE option is
> > ignored, but the build will then be littered with warnings:
> > 
> >    $ gcc -fPIE -c x.c
> >    x.c:1:0: warning: -fPIC ignored for target (all code is position independent) [enabled by default]
> 
> As long as the compile or link succeeded it'd set the flag.  We could
> add -Werror to the tests to prevent that in those cases, like so:

Sounds good to me, but wouldn't it be simpler to add -Werror by default
in OSSH_CHECK_CFLAG_COMPILE and OSSH_CHECK_CFLAG_LINK?


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

From dtucker at zip.com.au  Thu Apr 18 20:13:26 2013
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 18 Apr 2013 20:13:26 +1000
Subject: additional compiler hardening flags
In-Reply-To: <20130418092955.GA5562@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>
 <20130418071622.GA3059@calimero.vinschen.de>
 <20130418082200.GA32447@gate.dtucker.net>
 <20130418092955.GA5562@calimero.vinschen.de>
Message-ID: <20130418101326.GA9344@gate.dtucker.net>

On Thu, Apr 18, 2013 at 11:29:55AM +0200, Corinna Vinschen wrote:
> Sounds good to me, but wouldn't it be simpler to add -Werror by default
> in OSSH_CHECK_CFLAG_COMPILE and OSSH_CHECK_CFLAG_LINK?

I considered that, but I was concerned it may mis-detect some of the other
options for compilers that aren't gcc, but identify themselves as such
enough that configure thinks they are and sets $GCC (eg clang, intelcc).
I guess we could check for -Werror too before using it.

-- 
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  Thu Apr 18 21:44:28 2013
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 18 Apr 2013 21:44:28 +1000
Subject: additional compiler hardening flags
In-Reply-To: <20130418101326.GA9344@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>
 <20130418071622.GA3059@calimero.vinschen.de>
 <20130418082200.GA32447@gate.dtucker.net>
 <20130418092955.GA5562@calimero.vinschen.de>
 <20130418101326.GA9344@gate.dtucker.net>
Message-ID: <20130418114428.GA9195@gate.dtucker.net>

On Thu, Apr 18, 2013 at 08:13:26PM +1000, Darren Tucker wrote:
> On Thu, Apr 18, 2013 at 11:29:55AM +0200, Corinna Vinschen wrote:
> > Sounds good to me, but wouldn't it be simpler to add -Werror by default
> > in OSSH_CHECK_CFLAG_COMPILE and OSSH_CHECK_CFLAG_LINK?
> 
> I considered that, but I was concerned it may mis-detect some of the other
> options for compilers that aren't gcc, but identify themselves as such
> enough that configure thinks they are and sets $GCC (eg clang, intelcc).
> I guess we could check for -Werror too before using it.

Like so.

Index: Makefile.in
===================================================================
RCS file: /var/cvs/openssh/Makefile.in,v
retrieving revision 1.337
diff -u -p -r1.337 Makefile.in
--- Makefile.in	22 Mar 2013 17:14:33 -0000	1.337
+++ Makefile.in	18 Apr 2013 11:41:27 -0000
@@ -385,7 +385,7 @@ regress/modpipe$(EXEEXT): $(srcdir)/regr
 	[ -d `pwd`/regress ]  ||  mkdir -p `pwd`/regress
 	[ -f `pwd`/regress/Makefile ]  || \
 	    ln -s `cd $(srcdir) && pwd`/regress/Makefile `pwd`/regress/Makefile
-	$(CC) $(CPPFLAGS) -o $@ $? \
+	$(CC) $(CPPFLAGS) $(CFLAGS) -o $@ $? \
 	$(LDFLAGS) -lopenbsd-compat -lssh -lopenbsd-compat $(LIBS)
 
 tests interop-tests:	$(TARGETS) regress/modpipe$(EXEEXT)
Index: aclocal.m4
===================================================================
RCS file: /var/cvs/openssh/aclocal.m4,v
retrieving revision 1.8
diff -u -p -r1.8 aclocal.m4
--- aclocal.m4	20 May 2011 01:45:25 -0000	1.8
+++ aclocal.m4	18 Apr 2013 11:41:27 -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; }]])],
@@ -21,6 +21,23 @@ AC_DEFUN([OSSH_CHECK_CFLAG_COMPILE], [{
 	)
 }])
 
+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: /var/cvs/openssh/configure.ac,v
retrieving revision 1.520
diff -u -p -r1.520 configure.ac
--- configure.ac	18 Apr 2013 11:36:20 -0000	1.520
+++ configure.ac	18 Apr 2013 11:41:27 -0000
@@ -121,12 +121,31 @@ 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([-Wall])
@@ -139,6 +158,14 @@ if test "$GCC" = "yes" || test "$GCC" = 
 	OSSH_CHECK_CFLAG_COMPILE([-fno-strict-aliasing])
 	OSSH_CHECK_CFLAG_COMPILE([-Qunused-arguments])
 	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 vinschen at redhat.com  Thu Apr 18 22:19:13 2013
From: vinschen at redhat.com (Corinna Vinschen)
Date: Thu, 18 Apr 2013 14:19:13 +0200
Subject: additional compiler hardening flags
In-Reply-To: <20130418114428.GA9195@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>
 <20130418071622.GA3059@calimero.vinschen.de>
 <20130418082200.GA32447@gate.dtucker.net>
 <20130418092955.GA5562@calimero.vinschen.de>
 <20130418101326.GA9344@gate.dtucker.net>
 <20130418114428.GA9195@gate.dtucker.net>
Message-ID: <20130418121913.GD5562@calimero.vinschen.de>

On Apr 18 21:44, Darren Tucker wrote:
> On Thu, Apr 18, 2013 at 08:13:26PM +1000, Darren Tucker wrote:
> > On Thu, Apr 18, 2013 at 11:29:55AM +0200, Corinna Vinschen wrote:
> > > Sounds good to me, but wouldn't it be simpler to add -Werror by default
> > > in OSSH_CHECK_CFLAG_COMPILE and OSSH_CHECK_CFLAG_LINK?
> > 
> > I considered that, but I was concerned it may mis-detect some of the other
> > options for compilers that aren't gcc, but identify themselves as such
> > enough that configure thinks they are and sets $GCC (eg clang, intelcc).
> > I guess we could check for -Werror too before using it.
> 
> Like so.

Looks good.  Here's what I get on Cygwin:

  checking if gcc supports -Werror... yes
  checking if gcc supports -Wall... yes
  checking if gcc supports -Wpointer-arith... yes
  checking if gcc supports -Wuninitialized... yes
  checking if gcc supports -Wsign-compare... yes
  checking if gcc supports -Wformat-security... yes
  checking if gcc supports -Wpointer-sign... yes
  checking if gcc supports -Wunused-result... yes
  checking if gcc supports -fno-strict-aliasing... yes
  checking if gcc supports -D_FORTIFY_SOURCE=2... yes
  checking if gcc supports -ftrapv... yes
  checking if gcc supports -fPIE... no
  checking if gcc supports -pie... yes
  checking if gcc supports -Wl,-z,relro... no
  checking if gcc supports -Wl,-z,now... no
  checking if gcc supports -Wl,-z,noexecstack... no

Note the "no" for -fPIE :)


Thanks,
Corinna

-- 
Corinna Vinschen
Cygwin Maintainer
Red Hat

From jonathan at pauliwerks.com  Fri Apr 19 17:04:03 2013
From: jonathan at pauliwerks.com (Jonathan Pauli)
Date: Fri, 19 Apr 2013 02:04:03 -0500
Subject: Auth_Banner question
Message-ID: <5170EC63.5020004@pauliwerks.com>

Hi all,

I'm working with a pure PHP implementation of the SSH2 protocol. I've 
read the rfc and the thousands of lines in this project: 
http://phpseclib.sourceforge.net/

I'm simply trying to add a feature that will capture and display the 
USERAUTH_BANNER displayed by Open sshd prior to login.

When I connect to my opensshd server configured with the banner from 
openssh on any linux distro, I see the banner and all is well.
When I debug this PHP library, it never sees a binary packet of type 53- 
the Banner packet. I can connect, authenticate, etc, but a full
dump of the data shows no banner was sent by sshd. This makes me sad.

So, I'm wondering if there is some way to trigger sshd to send the 
banner. Can I request it explicitly with some message to sshd?
I know that according to the RFC it can be sent after authentication 
begins, but before it succeeds, but is there a specific sequence of events
in sshd where I can expect to see it?

Thanks so much!

-JP



From djm at mindrot.org  Fri Apr 19 21:18:07 2013
From: djm at mindrot.org (Damien Miller)
Date: Fri, 19 Apr 2013 21:18:07 +1000 (EST)
Subject: Auth_Banner question
In-Reply-To: <5170EC63.5020004@pauliwerks.com>
References: <5170EC63.5020004@pauliwerks.com>
Message-ID: <alpine.BSO.2.00.1304192113260.8512@natsu.mindrot.org>

On Fri, 19 Apr 2013, Jonathan Pauli wrote:

> I'm working with a pure PHP implementation of the SSH2 protocol.

I'm terrified.

> So, I'm wondering if there is some way to trigger sshd to send the banner.
> Can I request it explicitly with some message to sshd?

sshd sends the banner for protocol 2 connections at before it responds to
the the first SSH_MSG_USERAUTH_REQUEST packet. I.e

Client: SSH_MSG_USERAUTH_REQUEST
Server: SSH_MSG_USERAUTH_BANNER
Server: SSH2_MSG_USERAUTH_SUCCESS, SSH2_MSG_USERAUTH_FAILURE
        (or a userauth method-specific reply)

Have a look at auth2.c:input_userauth_request() to see how it works.

There isn't anything else you can do to trigger it than attempting
authentication.

-d

From mstanciu at axway.com  Sat Apr 20 01:44:40 2013
From: mstanciu at axway.com (Marian Stanciu)
Date: Fri, 19 Apr 2013 15:44:40 +0000
Subject: OpenSSH_6.1p1 sends a SSH packet bigger than 32K
Message-ID: <EA62B890F5CED54DB9BE84966287C645394F8452@WPTXMAIL1.ptx.axway.int>

The full SSH_MSG_CHANNEL_DATA packet looks like this:

uint32    packet length
byte      SSH_MSG_CHANNEL_DATA
uint32    recipient channel
uint32    nr data bytes
byte[]    data

OpenSSH_6.1p1 considers that the 'maximum packet size' from SSH_MSG_CHANNEL_OPEN or SSH_MSG_CHANNEL_OPEN_CONFIRMATION impacts only the 'byte[]    data' field and not the entire message (headers included). Section 5.1 from RFC 4254 (which talks about this limitation) leaves room for interpretation when it comes to the 'maximum packet size' because it "specifies the maximum size of an individual data packet that can be sent to the sender" without pointing out if specific headers are included or not.

This is equivalent to a 32768+13 byte packet for the lower layer, the binary packet protocol.

There's another section which somewhat clears things out - section 6.1 from RFC4253. Each SSH Connection Protocol packet (RFC 4254) is encapsulated entirely (headers included) in the binary packet protocol (bpp) payload from the SSH Transport Layer (RFC4253). And the above mentioned section stipulates all implementations must support an uncompressed payload length of 32768 for a bpp packet. Of course, implementations may support even bigger payload lengths and the means to announce it to a partner is through the identification string. In the absence of a specific identification string, a minimal SSH implementation should be assumed, and as such the SSH_MSG_CHANNEL_DATA packet should not surpass 32678 bytes in total.

I searched the mailing list for similar topics, but couldn't find any. Was this subject discussed somewhere? Is it considered a known issue, maybe?

Thank you,
Marian STANCIU

From jonathan at pauliwerks.com  Sat Apr 20 04:43:32 2013
From: jonathan at pauliwerks.com (Jonathan Pauli)
Date: Fri, 19 Apr 2013 13:43:32 -0500
Subject: Auth_Banner question
In-Reply-To: <alpine.BSO.2.00.1304192113260.8512@natsu.mindrot.org>
References: <5170EC63.5020004@pauliwerks.com>
 <alpine.BSO.2.00.1304192113260.8512@natsu.mindrot.org>
Message-ID: <51719054.9090007@pauliwerks.com>

Thanks for your help Damien. After much debugging I discovered that 
OpenSSHd 4.3 only seems to display the banner when the authentication 
method is none. By default this php SSH client library uses the password 
method so the banner is never sent by the server.

I also tested on OpenSSH_5.5p1 where the banner works with any auth 
method, so it looks like you developer types found and fixed this quite 
awhile ago. Sadly I'm stuck with CentOS 5.9 and thus OpenSSHd 4.3 in 
production.

Thanks for your help though!



On 4/19/13 6:18 AM, Damien Miller wrote:
>
> sshd sends the banner for protocol 2 connections at before it responds to
> the the first SSH_MSG_USERAUTH_REQUEST packet. I.e
>
> Client: SSH_MSG_USERAUTH_REQUEST
> Server: SSH_MSG_USERAUTH_BANNER
> Server: SSH2_MSG_USERAUTH_SUCCESS, SSH2_MSG_USERAUTH_FAILURE
>          (or a userauth method-specific reply)
>
> Have a look at auth2.c:input_userauth_request() to see how it works.
>
> There isn't anything else you can do to trigger it than attempting
> authentication.
>
> -d
>


From des at des.no  Tue Apr 23 17:15:30 2013
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Tue, 23 Apr 2013 09:15:30 +0200
Subject: "no such identity"
In-Reply-To: <20130404234952.GA28615@gate.dtucker.net> (Darren Tucker's
 message of "Fri, 5 Apr 2013 10:49:52 +1100")
References: <86hajqpdpz.fsf@ds4.des.no> <20130401172251.GB47549@juniper.net>
 <20130402120840.GA29590@calimero.vinschen.de>
 <20130402131500.GA29515@gate.dtucker.net>
 <20130402132655.GA18060@calimero.vinschen.de>
 <20130404234952.GA28615@gate.dtucker.net>
Message-ID: <86txmx7m5p.fsf@ds4.des.no>

Darren Tucker <dtucker at zip.com.au> writes:
> [...] so we'll do a 6.2p2 in probably a couple of weeks [...]

Any ETA on p2?

DES
-- 
Dag-Erling Sm?rgrav - des at des.no

From prassidice at gmail.com  Fri Apr 26 04:34:41 2013
From: prassidice at gmail.com (Prassidice)
Date: Thu, 25 Apr 2013 20:34:41 +0200
Subject: openssh cross compilation issue
Message-ID: <51797741.1030908@gmail.com>

Hi,

I'm cross compiling openSSH-6.2p1 on a ARM architecture
with
zlib-1.2.7
openssl-1.0.1e


the compilation succeeds but when I launch sftp x.y.z.t it fails:
exec: /home/working_area/disk1/usr/bin/ssh: No such file or directory

the problem is that /home/working_area/disk1/ is the path within the host PC

Is there a way to fix the cross-compilation or to export a variable in 
the target system such that the PATH is correct?

I'm compiling with this commands:

/home/working_area/disk1


./configure \
CC=arm-linux-gnueabi-gcc \
--host=arm-linux \
--build=arm-linux-gnueabi \
--with-ssl-dir=/home/working_area/disk1 \
--with-zlib=/home/working_area/disk1/usr \
--prefix=/home/working_area/disk1/usr \
--disable-etc-default-login

(at the end of this commands it explicitly says:
sshd default user PATH: 
/usr/bin:/bin:/usr/sbin:/sbin:/home/working_area/disk1/usr/bin

while it should be:
sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/usr/bin)

then I do:
make
make install


I already tried with  make install-nosysconf, but I had the same problem

how can I fix this?

to be more precise,
after the ./configure ...

in order to have the compilation to proceeds without problems I have to 
edit Makefile and modify in this way:

1) near check-config:
from:
     -$(DESTDIR)$(sbindir)/sshd -t -f $(DESTDIR)$(sysconfdir)/sshd_config
to:
     /usr/sbin/sshd -t -f $(DESTDIR)$(sysconfdir)/sshd_config

2) near host-key: ssh-keygen$(EXEEXT)
from:
     ./ssh-keygen -t rsa1 -f $(sysconfdir)/ssh_host_key -N "" ; \
to:
     /usr/bin/ssh-keygen -t rsa1 -f $(sysconfdir)/ssh_host_key -N "" ; \

from:
     ./ssh-keygen -t dsa -f $(sysconfdir)/ssh_host_dsa_key -N "" ; \
to:
     /usr/bin/ssh-keygen -t dsa -f $(sysconfdir)/ssh_host_dsa_key -N "" ; \

from:
     ./ssh-keygen -t rsa -f $(sysconfdir)/ssh_host_rsa_key -N "" ; \
to:
     /usr/bin/ssh-keygen -t rsa -f $(sysconfdir)/ssh_host_rsa_key -N "" ; \

from:
     ./ssh-keygen -t ecdsa -f $(sysconfdir)/ssh_host_ecdsa_key -N "" ; \
to:
     /usr/bin/ssh-keygen -t ecdsa -f $(sysconfdir)/ssh_host_ecdsa_key -N 
"" ; \

3) near (umask 022...)
from:
     $(INSTALL) -m 0755 $(STRIP_OPT) ssh$(EXEEXT) 
$(DESTDIR)$(bindir)/ssh$(EXEEXT)
     $(INSTALL) -m 0755 $(STRIP_OPT) scp$(EXEEXT) 
$(DESTDIR)$(bindir)/scp$(EXEEXT)
     $(INSTALL) -m 0755 $(STRIP_OPT) ssh-add$(EXEEXT) 
$(DESTDIR)$(bindir)/ssh-add$(EXEEXT)
     $(INSTALL) -m 0755 $(STRIP_OPT) ssh-agent$(EXEEXT) 
$(DESTDIR)$(bindir)/ssh-agent$(EXEEXT)
     $(INSTALL) -m 0755 $(STRIP_OPT) ssh-keygen$(EXEEXT) 
$(DESTDIR)$(bindir)/ssh-keygen$(EXEEXT)
     $(INSTALL) -m 0755 $(STRIP_OPT) ssh-keyscan$(EXEEXT) 
$(DESTDIR)$(bindir)/ssh-keyscan$(EXEEXT)
     $(INSTALL) -m 0755 $(STRIP_OPT) sshd$(EXEEXT) 
$(DESTDIR)$(sbindir)/sshd$(EXEEXT)
     $(INSTALL) -m 4711 $(STRIP_OPT) ssh-keysign$(EXEEXT) 
$(DESTDIR)$(SSH_KEYSIGN)$(EXEEXT)
     $(INSTALL) -m 0755 $(STRIP_OPT) ssh-pkcs11-helper$(EXEEXT) 
$(DESTDIR)$(SSH_PKCS11_HELPER)$(EXEEXT)
     $(INSTALL) -m 0755 $(STRIP_OPT) sftp$(EXEEXT) 
$(DESTDIR)$(bindir)/sftp$(EXEEXT)
     $(INSTALL) -m 0755 $(STRIP_OPT) sftp-server$(EXEEXT) 
$(DESTDIR)$(SFTP_SERVER)$(EXEEXT)

to:
     $(INSTALL) -m 0755 ssh-agent$(EXEEXT) 
$(DESTDIR)$(bindir)/ssh-agent$(EXEEXT)
     arm-linux-gnueabi-strip $(DESTDIR)$(bindir)/ssh-agent$(EXEEXT)
     $(INSTALL) -m 0755 ssh-keygen$(EXEEXT) 
$(DESTDIR)$(bindir)/ssh-keygen$(EXEEXT)
     arm-linux-gnueabi-strip $(DESTDIR)$(bindir)/ssh-keygen$(EXEEXT)
     $(INSTALL) -m 0755 ssh-keyscan$(EXEEXT) 
$(DESTDIR)$(bindir)/ssh-keyscan$(EXEEXT)
     arm-linux-gnueabi-strip $(DESTDIR)$(bindir)/ssh-keyscan$(EXEEXT)
     $(INSTALL) -m 0755 sshd$(EXEEXT) $(DESTDIR)$(sbindir)/sshd$(EXEEXT)
     arm-linux-gnueabi-strip $(DESTDIR)$(sbindir)/sshd$(EXEEXT)
     $(INSTALL) -m 0755 ssh-keysign$(EXEEXT) 
$(DESTDIR)$(SSH_KEYSIGN)$(EXEEXT)
     arm-linux-gnueabi-strip $(DESTDIR)$(SSH_KEYSIGN)$(EXEEXT)
     $(INSTALL) -m 0755 ssh-pkcs11-helper$(EXEEXT) 
$(DESTDIR)$(SSH_PKCS11_HELPER)$(EXEEXT)
     arm-linux-gnueabi-strip $(DESTDIR)$(SSH_PKCS11_HELPER)$(EXEEXT)
     $(INSTALL) -m 0755 sftp$(EXEEXT) $(DESTDIR)$(bindir)/sftp$(EXEEXT)
     arm-linux-gnueabi-strip $(DESTDIR)$(bindir)/sftp$(EXEEXT)
     $(INSTALL) -m 0755 sftp-server$(EXEEXT) 
$(DESTDIR)$(SFTP_SERVER)$(EXEEXT)
     arm-linux-gnueabi-strip $(DESTDIR)$(SFTP_SERVER)$(EXEEXT)

here the problem is with the strip option that cannot use the host functions


best regards,

     Prassidice




From peter at stuge.se  Fri Apr 26 05:22:57 2013
From: peter at stuge.se (Peter Stuge)
Date: Thu, 25 Apr 2013 21:22:57 +0200
Subject: openssh cross compilation issue
In-Reply-To: <51797741.1030908@gmail.com>
References: <51797741.1030908@gmail.com>
Message-ID: <20130425192257.13932.qmail@stuge.se>

Prassidice wrote:
> ./configure \
> CC=arm-linux-gnueabi-gcc \
> --host=arm-linux \
> --build=arm-linux-gnueabi \
> --with-ssl-dir=/home/working_area/disk1 \
> --with-zlib=/home/working_area/disk1/usr \
> --prefix=/home/working_area/disk1/usr \
> --disable-etc-default-login

No, use --prefix=/usr


> make install

No, use make install DESTDIR=/home/working_area/disk1


> how can I fix this?

The above is rather basic crosscompiling.


> 3) near (umask 022...)
> from:
>     $(INSTALL) -m 0755 $(STRIP_OPT) ssh$(EXEEXT) 
> $(DESTDIR)$(bindir)/ssh$(EXEEXT)

And since you saw the above Makefile rules you really had all the
clues at hand already.


//Peter

From vintobe at gmail.com  Fri Apr 26 19:06:36 2013
From: vintobe at gmail.com (Vincent Lin)
Date: Fri, 26 Apr 2013 17:06:36 +0800
Subject: how to check whether the ssh tunnel is up
Message-ID: <CAKi2yo8dXjd3_pY5ECDxAH7r+2ttHjWxBo8poJJZoR2wv39=_A@mail.gmail.com>

Hi all,

I use the command below to set up a ssh tunnel. And I run it as a daemon
process to keep the ssh tunnel work all the time. And I should wait for the
ssh tunnel to be up and notify the tunnel is OK before sending any command
to the remote port on the remote server. But the question is I don't know
how to check the ssh tunnel status. Is there a way to show whether the ssh
tunnel is up?  Thank you for your help.

*"ssh -i /root/ah_rsa -oUserKnownHostsFile=/root/hosts
-oStrictHostKeyChecking=yes -oNumberOfPasswordPrompts=0 -oBatchMode=yes
-oHostKeyAlgorithms=ssh-rsa -R 20001:localhost:22 user at xxx.xxx.xxx.xxx -p
13422 -Nyv"*


Best Regard,
Vincent

From djm at mindrot.org  Sat Apr 27 16:19:22 2013
From: djm at mindrot.org (Damien Miller)
Date: Sat, 27 Apr 2013 16:19:22 +1000 (EST)
Subject: how to check whether the ssh tunnel is up
In-Reply-To: <CAKi2yo8dXjd3_pY5ECDxAH7r+2ttHjWxBo8poJJZoR2wv39=_A@mail.gmail.com>
References: <CAKi2yo8dXjd3_pY5ECDxAH7r+2ttHjWxBo8poJJZoR2wv39=_A@mail.gmail.com>
Message-ID: <alpine.BSO.2.03.1304271616520.19959@mindrot.org>

On Fri, 26 Apr 2013, Vincent Lin wrote:

> Hi all,
> 
> I use the command below to set up a ssh tunnel. And I run it as a daemon
> process to keep the ssh tunnel work all the time. And I should wait for the
> ssh tunnel to be up and notify the tunnel is OK before sending any command
> to the remote port on the remote server. But the question is I don't know
> how to check the ssh tunnel status. Is there a way to show whether the ssh
> tunnel is up?  Thank you for your help.
> 
> *"ssh -i /root/ah_rsa -oUserKnownHostsFile=/root/hosts
> -oStrictHostKeyChecking=yes -oNumberOfPasswordPrompts=0 -oBatchMode=yes
> -oHostKeyAlgorithms=ssh-rsa -R 20001:localhost:22 user at xxx.xxx.xxx.xxx -p
> 13422 -Nyv"*

ExitOnForwardFailure=yes should provide the checking you need. If you use
it with -f then the fork is delayed until the forwarding is answered by
the server, though note that this doesn't include an end-to-end test that
involves the forward target - that is till up to you to check if you need it.

-d



From dkg at fifthhorseman.net  Sat Apr 27 16:22:50 2013
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sat, 27 Apr 2013 14:22:50 +0800
Subject: how to check whether the ssh tunnel is up
In-Reply-To: <CAKi2yo8dXjd3_pY5ECDxAH7r+2ttHjWxBo8poJJZoR2wv39=_A@mail.gmail.com>
References: <CAKi2yo8dXjd3_pY5ECDxAH7r+2ttHjWxBo8poJJZoR2wv39=_A@mail.gmail.com>
Message-ID: <517B6EBA.2090903@fifthhorseman.net>

On 04/26/2013 05:06 PM, Vincent Lin wrote:

> I use the command below to set up a ssh tunnel. And I run it as a daemon
> process to keep the ssh tunnel work all the time. And I should wait for the
> ssh tunnel to be up and notify the tunnel is OK before sending any command
> to the remote port on the remote server. But the question is I don't know
> how to check the ssh tunnel status. Is there a way to show whether the ssh
> tunnel is up?  Thank you for your help.

I recommend using -oExitOnForwardFailure=yes in such a configuration.

You could also look into the various keepalive options (TCPKeepAlive,
ServerAliveCountMax, ServerAliveInterval) to ensure that your process
terminates when the connection is no longer established.

This reduces your problem to ensuring that your daemon process is still
running (and there are a number of good solutions for that sort of
daemon supervision -- e.g. runit, daemontools, systemd, etc)

Finally, you could test whether the tunnel is up by sending traffic over
it and seeing if there is a response :)

hth,

	--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/20130427/1a83734c/attachment.bin>

From alex at alex.org.uk  Sat Apr 27 18:37:14 2013
From: alex at alex.org.uk (Alex Bligh)
Date: Sat, 27 Apr 2013 09:37:14 +0100
Subject: how to check whether the ssh tunnel is up
In-Reply-To: <CAKi2yo8dXjd3_pY5ECDxAH7r+2ttHjWxBo8poJJZoR2wv39=_A@mail.gmail.com>
References: <CAKi2yo8dXjd3_pY5ECDxAH7r+2ttHjWxBo8poJJZoR2wv39=_A@mail.gmail.com>
Message-ID: <6FAC4BA7-6B49-46A7-9523-0F23E7827A55@alex.org.uk>


On 26 Apr 2013, at 10:06, Vincent Lin wrote:

> Is there a way to show whether the ssh
> tunnel is up?

In addition to the suggestions you have already been
sent, can I suggest you look at autossh? It uses
a combination of -L and -R to send packets to the
other end and back, to check the tunnel is working
as well as up, and reopens the tunnel if it's
not up.

-- 
Alex Bligh





From meyerchr at us.ibm.com  Sat Apr 27 20:01:53 2013
From: meyerchr at us.ibm.com (Christopher Meyer)
Date: Sat, 27 Apr 2013 04:01:53 -0600
Subject: AUTO: [auto] Chris Meyer is out of the office (returning 04/29/2013)
Message-ID: <OFA196FADD.E565DCB8-ON87257B5A.00371AAC-87257B5A.00371AAC@us.ibm.com>



I am out of the office until 04/29/2013.

I am out of the office and will not be checking e-mail.   I will respond to
your e-mail after I return.

Thanks,

Chris Meyer


Note: This is an automated response to your message  "Re: how to check
whether the ssh tunnel is up" sent on 04/27/2013 0:22:50.

This is the only notification you will receive while this person is away.

From vintobe at gmail.com  Sat Apr 27 21:37:32 2013
From: vintobe at gmail.com (Vincent Lin)
Date: Sat, 27 Apr 2013 19:37:32 +0800
Subject: how to check whether the ssh tunnel is up
In-Reply-To: <alpine.BSO.2.03.1304271616520.19959@mindrot.org>
References: <CAKi2yo8dXjd3_pY5ECDxAH7r+2ttHjWxBo8poJJZoR2wv39=_A@mail.gmail.com>
 <alpine.BSO.2.03.1304271616520.19959@mindrot.org>
Message-ID: <CAKi2yo_WK6kkBMrReiEht3SUfpBthR5nFk4ZUsFg8bCudWvwgw@mail.gmail.com>

Hi damien,

Thanks for your reply. ExitOnForwardFailure=yes will exit the process if
SSH tunnel failed to create. But what if it's OK?  Is there a way to know
when it will be OK? I mean maybe it will cost some time, and when the
tunnel is up, I can know it, or I can get the status all the time on the
SSH client side, if it's possible. And what's the difference with or
without -f, since I already create a  SSH daemon. Do I have to fork another
process again?

Best Regard
Vincent

From vintobe at gmail.com  Sat Apr 27 21:42:59 2013
From: vintobe at gmail.com (Vincent Lin)
Date: Sat, 27 Apr 2013 19:42:59 +0800
Subject: how to check whether the ssh tunnel is up
In-Reply-To: <6FAC4BA7-6B49-46A7-9523-0F23E7827A55@alex.org.uk>
References: <CAKi2yo8dXjd3_pY5ECDxAH7r+2ttHjWxBo8poJJZoR2wv39=_A@mail.gmail.com>
 <6FAC4BA7-6B49-46A7-9523-0F23E7827A55@alex.org.uk>
Message-ID: <CAKi2yo8oZ2GvC8uGdpTsF+aDNxmQBUAE3rvER0Y1BXFiH4chdQ@mail.gmail.com>

Hi Alex,

Thank you for your suggestion. But I have to use openssh.

Best Regard
Vincent


On Sat, Apr 27, 2013 at 4:37 PM, Alex Bligh <alex at alex.org.uk> wrote:

>
> On 26 Apr 2013, at 10:06, Vincent Lin wrote:
>
> > Is there a way to show whether the ssh
> > tunnel is up?
>
> In addition to the suggestions you have already been
> sent, can I suggest you look at autossh? It uses
> a combination of -L and -R to send packets to the
> other end and back, to check the tunnel is working
> as well as up, and reopens the tunnel if it's
> not up.
>
> --
> Alex Bligh
>
>
>
>
>

From djm at mindrot.org  Sat Apr 27 21:47:42 2013
From: djm at mindrot.org (Damien Miller)
Date: Sat, 27 Apr 2013 21:47:42 +1000 (EST)
Subject: how to check whether the ssh tunnel is up
In-Reply-To: <CAKi2yo_WK6kkBMrReiEht3SUfpBthR5nFk4ZUsFg8bCudWvwgw@mail.gmail.com>
References: <CAKi2yo8dXjd3_pY5ECDxAH7r+2ttHjWxBo8poJJZoR2wv39=_A@mail.gmail.com>
 <alpine.BSO.2.03.1304271616520.19959@mindrot.org>
 <CAKi2yo_WK6kkBMrReiEht3SUfpBthR5nFk4ZUsFg8bCudWvwgw@mail.gmail.com>
Message-ID: <alpine.BSO.2.03.1304272142310.31090@mindrot.org>

On Sat, 27 Apr 2013, Vincent Lin wrote:

> Hi damien,
> 
> Thanks for your reply. ExitOnForwardFailure=yes will exit the process if SSH
> tunnel failed to create. But what if it's OK?  Is there a way to know when
> it will be OK? I mean maybe it will cost some time, and when the tunnel is
> up, I can know it, or I can get the status all the time on the SSH client
> side, if it's possible. And what's the difference with or without -f, since
> I already create a  SSH daemon. Do I have to fork another process again?

The fork will happen once the tunnel is ready, so you can do something
like:

ssh -nNfoExitOnForwardFailure=yes \
    -oControlMaster=yes -oControlPath=~/.ssh/fwd%l-%r-%h-%p \
     -L1234:10.11.12.13:1234 user at host
if test $? -ne 0 ; then
	echo failed 2>&1
	exit 1
fi

# ... later, to clean up:
ssh -O exit -oControlPath=~/.ssh/fwd%l-%r-%h-%p user at host

These use the multiplexing socket to cleanly terminate the forwarding ssh
client. Have a look at the sections on '-f' in ssh(1) and the various
options in ssh_config(5) to see how they work together.

-d

From vintobe at gmail.com  Sat Apr 27 21:47:34 2013
From: vintobe at gmail.com (Vincent Lin)
Date: Sat, 27 Apr 2013 19:47:34 +0800
Subject: how to check whether the ssh tunnel is up
In-Reply-To: <517B6EBA.2090903@fifthhorseman.net>
References: <CAKi2yo8dXjd3_pY5ECDxAH7r+2ttHjWxBo8poJJZoR2wv39=_A@mail.gmail.com>
 <517B6EBA.2090903@fifthhorseman.net>
Message-ID: <CAKi2yo9ARonxasoz-Z5Qe+v_2q6ey4RMZ9Vr225urtkOdZoCPA@mail.gmail.com>

Hi Daniel,

Is it the only way to check the tunnel on the remote server side? How about
on the local client side?

Thanks,
Vincent


On Sat, Apr 27, 2013 at 2:22 PM, Daniel Kahn Gillmor
<dkg at fifthhorseman.net>wrote:

> On 04/26/2013 05:06 PM, Vincent Lin wrote:
>
> > I use the command below to set up a ssh tunnel. And I run it as a daemon
> > process to keep the ssh tunnel work all the time. And I should wait for
> the
> > ssh tunnel to be up and notify the tunnel is OK before sending any
> command
> > to the remote port on the remote server. But the question is I don't know
> > how to check the ssh tunnel status. Is there a way to show whether the
> ssh
> > tunnel is up?  Thank you for your help.
>
> I recommend using -oExitOnForwardFailure=yes in such a configuration.
>
> You could also look into the various keepalive options (TCPKeepAlive,
> ServerAliveCountMax, ServerAliveInterval) to ensure that your process
> terminates when the connection is no longer established.
>
> This reduces your problem to ensuring that your daemon process is still
> running (and there are a number of good solutions for that sort of
> daemon supervision -- e.g. runit, daemontools, systemd, etc)
>
> Finally, you could test whether the tunnel is up by sending traffic over
> it and seeing if there is a response :)
>
> hth,
>
>         --dkg
>
>

From alex at alex.org.uk  Sat Apr 27 23:39:17 2013
From: alex at alex.org.uk (Alex Bligh)
Date: Sat, 27 Apr 2013 14:39:17 +0100
Subject: how to check whether the ssh tunnel is up
In-Reply-To: <CAKi2yo8oZ2GvC8uGdpTsF+aDNxmQBUAE3rvER0Y1BXFiH4chdQ@mail.gmail.com>
References: <CAKi2yo8dXjd3_pY5ECDxAH7r+2ttHjWxBo8poJJZoR2wv39=_A@mail.gmail.com>
 <6FAC4BA7-6B49-46A7-9523-0F23E7827A55@alex.org.uk>
 <CAKi2yo8oZ2GvC8uGdpTsF+aDNxmQBUAE3rvER0Y1BXFiH4chdQ@mail.gmail.com>
Message-ID: <BA2D1BAE-07B0-428F-9594-1B4AB667177F@alex.org.uk>

Vincent,

On 27 Apr 2013, at 12:42, Vincent Lin wrote:
> Thank you for your suggestion. But I have to use openssh.

autossh is a small wrapper for openssh. It's not a different ssh.

Alex



> Best Regard
> Vincent
> 
> 
> On Sat, Apr 27, 2013 at 4:37 PM, Alex Bligh <alex at alex.org.uk> wrote:
> 
> On 26 Apr 2013, at 10:06, Vincent Lin wrote:
> 
> > Is there a way to show whether the ssh
> > tunnel is up?
> 
> In addition to the suggestions you have already been
> sent, can I suggest you look at autossh? It uses
> a combination of -L and -R to send packets to the
> other end and back, to check the tunnel is working
> as well as up, and reopens the tunnel if it's
> not up.
> 
> --
> Alex Bligh
> 
> 
> 
> 
> 

-- 
Alex Bligh





From dkg at fifthhorseman.net  Sun Apr 28 01:48:25 2013
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Sat, 27 Apr 2013 23:48:25 +0800
Subject: how to check whether the ssh tunnel is up
In-Reply-To: <CAKi2yo9ARonxasoz-Z5Qe+v_2q6ey4RMZ9Vr225urtkOdZoCPA@mail.gmail.com>
References: <CAKi2yo8dXjd3_pY5ECDxAH7r+2ttHjWxBo8poJJZoR2wv39=_A@mail.gmail.com>
 <517B6EBA.2090903@fifthhorseman.net>
 <CAKi2yo9ARonxasoz-Z5Qe+v_2q6ey4RMZ9Vr225urtkOdZoCPA@mail.gmail.com>
Message-ID: <517BF349.8090004@fifthhorseman.net>

On 04/27/2013 07:47 PM, Vincent Lin wrote:

> Is it the only way to check the tunnel on the remote server side? How about
> on the local client side?

the tunnel you're specifying is:

 ssh [...] -R 20001:localhost:22

this means that sshd (on the remote machine) will listen on remote port
20001.  if a request comes in, then sshd will call across the
established ssh connection to ask ssh (on the local machine) to create a
connection to localhost:22.  I don't see a way to examine this situation
from the client side, since the local side hasn't done anything yet.
But maybe i'm missing something, and someone more knowledgable might be
able to suggest an approach i'm missing. (e.g. see the autossh idea
mentioned elsewhere in this thread)

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/20130427/1c594a05/attachment.bin>