From qyuan at avaya.com  Wed Nov  4 03:32:51 2015
From: qyuan at avaya.com (Yuan, Qiulin (Qiulin) )
Date: Tue, 3 Nov 2015 16:32:51 +0000
Subject: potential memory leaks and using null pointer 
Message-ID: <9A556D8D7F724145983D13100E0902BB40F9A6@AZ-US1EXMB04.global.avaya.com>

Hi,

When using openssh-7.1p1, the following potential memory leaks or potential using null pointer was found.

in kex.c
line 182, match_list().
line 540, name is not freed.
line 559, name is not freed.
line 582, name is not freed,
line 615, hostkeyalg is not freed.

in packet.c,
line 1950, potential using null pointer ssh.

Regards,

Qiulin Yuan

From max at quendi.de  Sat Nov  7 02:20:56 2015
From: max at quendi.de (Max Horn)
Date: Fri, 6 Nov 2015 16:20:56 +0100
Subject: hmac-ripemd160 not in PROTOCOL
Message-ID: <2182E080-021E-4B95-8776-93CC95726ED1@quendi.de>

Hi there,

I noticed that hmac-ripemd160 and hmac-ripemd160 at openssh.com are not listed in the OpenSSH protocols file, yet they are listed in myproposal.h. I was wondering whether this is intentional, if yes, what the rationale behind this is?

Thanks,
Max

From dtucker at zip.com.au  Sat Nov  7 14:43:49 2015
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 7 Nov 2015 14:43:49 +1100
Subject: hmac-ripemd160 not in PROTOCOL
In-Reply-To: <2182E080-021E-4B95-8776-93CC95726ED1@quendi.de>
References: <2182E080-021E-4B95-8776-93CC95726ED1@quendi.de>
Message-ID: <CALDDTe2u4aQAc+za3CRLBFpC7Rm3vmWi0bpJyF5o85QQ-4fJhQ@mail.gmail.com>

On Sat, Nov 7, 2015 at 2:20 AM, Max Horn <max at quendi.de> wrote:
> Hi there,
>
> I noticed that hmac-ripemd160 and hmac-ripemd160 at openssh.com are not listed in the OpenSSH protocols file, yet they are listed in myproposal.h. I was wondering whether this is intentional, if yes, what the rationale behind this is?

The definitions are the same, so they implement the same algorithm.

After some git archaeology I see that it was added sometime around 2.0
and was present through 2.3.x[0] with only the @openssh.com suffix.
Between 2.3 and 2.5 (there was no 2.4) it moved into mac.c and the
name without the @openssh was added.

I suspect the @openssh one was before ripemd was added to the (at the
time in draft) standards, and the new name was added once it was.  I
also think we should make the documentation accurate by removed the
nonstandard name.

[0] https://anongit.mindrot.org/openssh.git/tree/kex.c?h=V_2_3_0_P1
[1] https://anongit.mindrot.org/openssh.git/tree/mac.c?h=V_2_5_0_P1

-- 
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 max at quendi.de  Sat Nov  7 20:02:44 2015
From: max at quendi.de (Max Horn)
Date: Sat, 7 Nov 2015 10:02:44 +0100
Subject: hmac-ripemd160 not in PROTOCOL
In-Reply-To: <CALDDTe2u4aQAc+za3CRLBFpC7Rm3vmWi0bpJyF5o85QQ-4fJhQ@mail.gmail.com>
References: <2182E080-021E-4B95-8776-93CC95726ED1@quendi.de>
 <CALDDTe2u4aQAc+za3CRLBFpC7Rm3vmWi0bpJyF5o85QQ-4fJhQ@mail.gmail.com>
Message-ID: <C1D3CCAC-C77C-4F67-86D3-6E0ADDDE5371@quendi.de>


> On 07.11.2015, at 04:43, Darren Tucker <dtucker at zip.com.au> wrote:
> 
> On Sat, Nov 7, 2015 at 2:20 AM, Max Horn <max at quendi.de> wrote:
>> Hi there,
>> 
>> I noticed that hmac-ripemd160 and hmac-ripemd160 at openssh.com are not listed in the OpenSSH protocols file, yet they are listed in myproposal.h. I was wondering whether this is intentional, if yes, what the rationale behind this is?
> 
> The definitions are the same, so they implement the same algorithm.

Aye, that I also determined :).

> 
> After some git archaeology I see that it was added sometime around 2.0
> and was present through 2.3.x[0] with only the @openssh.com suffix.
> Between 2.3 and 2.5 (there was no 2.4) it moved into mac.c and the
> name without the @openssh was added.
> 
> I suspect the @openssh one was before ripemd was added to the (at the
> time in draft) standards, and the new name was added once it was.

Ahhh, I am sorry, I should have lead with this: To the best of my knowledge,
hmac-ripemd160 occurs nowhere in the SSH specification, and is an OpenSSH
extension. Hence, I am surprised to see "hmac-ripemd160" in the mac list,
without the @openssh.com, and was wondering about the story behind it...

But I am happy to learn I am wrong, though then I'd also like to learn which
standard you are referring to?

Cheers,
max


> I also think we should make the documentation accurate by removed the
> nonstandard name.
> 
> [0] https://anongit.mindrot.org/openssh.git/tree/kex.c?h=V_2_3_0_P1
> [1] https://anongit.mindrot.org/openssh.git/tree/mac.c?h=V_2_5_0_P1
> 
> -- 
> Darren Tucker (dtucker at zip.com.au)
> GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4  37C9 C982 80C7 8FF4 FA69
>    Good judgement comes with experience. Unfortunately, the experience
> usually comes from bad judgement.
> 


From dtucker at zip.com.au  Sat Nov  7 21:44:11 2015
From: dtucker at zip.com.au (Darren Tucker)
Date: Sat, 7 Nov 2015 21:44:11 +1100
Subject: hmac-ripemd160 not in PROTOCOL
In-Reply-To: <C1D3CCAC-C77C-4F67-86D3-6E0ADDDE5371@quendi.de>
References: <2182E080-021E-4B95-8776-93CC95726ED1@quendi.de>
 <CALDDTe2u4aQAc+za3CRLBFpC7Rm3vmWi0bpJyF5o85QQ-4fJhQ@mail.gmail.com>
 <C1D3CCAC-C77C-4F67-86D3-6E0ADDDE5371@quendi.de>
Message-ID: <CALDDTe1M_G3D0XZUDc_5zQs4wBRdKfuQQLHX3H8re-G=G_S+Gg@mail.gmail.com>

On Sat, Nov 7, 2015 at 8:02 PM, Max Horn <max at quendi.de> wrote:
>> On 07.11.2015, at 04:43, Darren Tucker <dtucker at zip.com.au> wrote:
[...]
>> I suspect the @openssh one was before ripemd was added to the (at the
>> time in draft) standards, and the new name was added once it was.
>
> Ahhh, I am sorry, I should have lead with this: To the best of my knowledge,
> hmac-ripemd160 occurs nowhere in the SSH specification, and is an OpenSSH
> extension. Hence, I am surprised to see "hmac-ripemd160" in the mac list,
> without the @openssh.com, and was wondering about the story behind it...
>
> But I am happy to learn I am wrong, though then I'd also like to learn which
> standard you are referring to?

I was referring to RFC4253 et al, but only assumed it was there
because of the lack of @openssh suffix on the MAC name, not because I
had gone looking for it.  Having just done so I agree that it's not
there!  I also can't find it in any of the internet-draft specs.

While trying to figure this out, I found the following interesting things:
Markus' early comment on OpenSSH protocol 2 support mentions hmac-ripemd160:
http://lists.mindrot.org/pipermail/openssh-unix-dev/2000-April/001175.html

This manual for the ssh.com software dated 2003 lists hmac-ripemd160
as a supported MAC.
http://www.hiz-saarland.de/doku/ssh/ssh2unix_adminguide32.pdf

The snail book says "OpenSSH also implements a nonstandard MAC
algorithm, hmac-ripemd160 at openssh.com.  The name hmac-ripemd160 is
also recognised without the @openssh.com suffix, but this is
deprecated, since all nonstandard names are supposed to use a domain
suffix."

Since this was before Portable pulled synced individual commits, I
went back to the OpenBSD tree.
hmac-ripemd160 at openssh appeared in a commit from Markus on 2000-04-03
with the description "DSA, keyexchange, algorithm agreement for ssh2".
hmac-ripemd160 without the suffix first appeared in a commit by Markus
on 2001-02-11 (http://www.dtucker.net/openssh/patches/openssh-ripemd160.patch)
with this description:
1) clean up the MAC support for SSH-2
2) allow you to specify the MAC with 'ssh -m'
3) or the 'MACs' keyword in ssh(d)_config
4) add hmac-{md5,sha1}-96
        ok stevesk@, provos@

In summary, I have no idea why it ended up the way it did.  Maybe
Markus can recall?

-- 
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 ross.snider at gmail.com  Sun Nov  8 11:06:32 2015
From: ross.snider at gmail.com (Ross Snider)
Date: Sat, 7 Nov 2015 16:06:32 -0800
Subject: First steps to add an authenticated key agreement protocol (private
 branch).
Message-ID: <CAPoPW6FOPM03NE1d3ES2sNFZDPdF0_f6-=4fQDQPp0P8URw2cA@mail.gmail.com>

Starting by following Damian Miller's commit
1e1242604eb0fd510fe93f81245c529237ffc513 I have been trying to understand
where precisely to include additional ciphers into my server and client
cipherlists for handshake (this commit is the start of ed25519 support).

I have looked at the diff of myproposal.h and also the 25519 implementation.

I do not see where the implementation is mapped to the canonical name
string so that it can be included in client code (ssh/sshd.c).

Does anyone have experience or a tutorial on the various areas of code that
link key exchange, EVP structs and other function pointer, and the
handshake process all together?

Best,
Ross

From djm at mindrot.org  Mon Nov  9 14:03:05 2015
From: djm at mindrot.org (Damien Miller)
Date: Mon, 9 Nov 2015 14:03:05 +1100 (AEDT)
Subject: First steps to add an authenticated key agreement protocol
 (private branch).
In-Reply-To: <CAPoPW6FOPM03NE1d3ES2sNFZDPdF0_f6-=4fQDQPp0P8URw2cA@mail.gmail.com>
References: <CAPoPW6FOPM03NE1d3ES2sNFZDPdF0_f6-=4fQDQPp0P8URw2cA@mail.gmail.com>
Message-ID: <alpine.BSO.2.20.1511091350441.30289@natsu.mindrot.org>

On Sat, 7 Nov 2015, Ross Snider wrote:

> Starting by following Damian Miller's commit
> 1e1242604eb0fd510fe93f81245c529237ffc513 I have been trying to
> understand where precisely to include additional ciphers into my
> server and client cipherlists for handshake (this commit is the start
> of ed25519 support).
>
> I have looked at the diff of myproposal.h and also the 25519
> implementation.
>
> I do not see where the implementation is mapped to the canonical name
> string so that it can be included in client code (ssh/sshd.c).
>
> Does anyone have experience or a tutorial on the various areas of code
> that link key exchange, EVP structs and other function pointer, and
> the handshake process all together?

What algorithms are you referring to?

If you mean ciphers, then the name/cipher mapping is done by the
ciphers[] array in ciphers.c.

If you mean key exchange algorithms, then it's more tricky.

The kexalgs[] array in kex.c handles name/number lookup. The client
and server need to implement handlers for each side of the key
exchange, these are setup in sshconnect2.c:ssh_kex2() (client) and
sshd.c:do_ssh2_kex() (server).

For each key exchange method, there is one file containing the
client side of the exchange, another for the server part and one for
shared stuff - usually the exchange hash. For curve25519, these are
kexc25519c.c, kexc25519s.c and kexc25519.c respectively.

An authenticated key exchange sounds like it might be fairly tricky
to implement. What are the keys and how are they managed? What's being
authenticated - server->client or both?

Also, if the AKE does do client->server authentication, then how does
it coexist with the existing authentication system? It would need to
work nicely with multiple authentication, etc.

-d

From austinenglish at gmail.com  Tue Nov 10 09:22:05 2015
From: austinenglish at gmail.com (Austin English)
Date: Mon, 9 Nov 2015 16:22:05 -0600
Subject: OpenSSH-7.1p1 fails configure check with LibreSSL-2.2.4
Message-ID: <CACC5Q1fvXwoJSZfC8FHbXXGOtBCUxaW__PssyxfyWWVCOWC6pA@mail.gmail.com>

Howdy,

I'm attempting to compile openssh-7.1p1 using libressl-2.2.4 for the
ssl implementation. Unfortunately, this fails to work (tested on
Debian Unstable and Gentoo):

cd libressl-2.2.4
./configure --prefix=/opt/libressl-2.2.4 && make -j8 && sudo make install
cd ../openssh-7.1p1
./configure --with-ssl-dir=/opt/libressl-2.2.4

fails with:
checking OpenSSL header version... not found
configure: error: OpenSSL version header not found.

config.log shows:
configure:20986: checking OpenSSL header version
configure:21033: ccache gcc -o conftest -g -O2 -Wall -Wpointer-arith
-Wuninitialized -Wsign-compare -Wformat-security
-Wsizeof-pointer-memaccess -Wno-pointer-sign -Wno-unused-result
-fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv -fno-builtin-memset
-fstack-protector-strong -fPIE -I/opt/libressl-2.2.4//include
-L/opt/libressl-2.2.4//lib  -Wl,-z,relro -Wl,-z,now -Wl,-z,noexecstack
-fstack-protector-strong -pie conftest.c -lcrypto -ldl -lutil -lz
-lnsl  >&5
conftest.c: In function 'main':
conftest.c:225:4: warning: implicit declaration of function 'exit'
[-Wimplicit-function-declaration]
    exit(1);
    ^
conftest.c:225:4: warning: incompatible implicit declaration of
built-in function 'exit'
conftest.c:225:4: note: include '<stdlib.h>' or provide a declaration of 'exit'
conftest.c:227:25: warning: format '%x' expects argument of type
'unsigned int', but argument 3 has type 'long int' [-Wformat=]
   if ((rc = fprintf(fd ,"%08x (%s)\n", OPENSSL_VERSION_NUMBER,
OPENSSL_VERSION_TEXT)) <0)
                         ^
conftest.c:228:4: warning: incompatible implicit declaration of
built-in function 'exit'
    exit(1);
    ^
conftest.c:228:4: note: include '<stdlib.h>' or provide a declaration of 'exit'
conftest.c:230:3: warning: incompatible implicit declaration of
built-in function 'exit'
   exit(0);
   ^
conftest.c:230:3: note: include '<stdlib.h>' or provide a declaration of 'exit'
configure:21036: $? = 0
configure:21042: ./conftest
./conftest: error while loading shared libraries: libcrypto.so.35:
cannot open shared object file: No such file or directory

doing:
export LD_LIBRARY_PATH=/opt/libressl-2.2.4

Works around this issue, and allows OpenSSH to compile (though some
tests fail that don't with openssl-1.0.2d.

Please keep me in CC, as I'm not subscribed.

--
-Austin

From dtucker at zip.com.au  Tue Nov 10 10:35:39 2015
From: dtucker at zip.com.au (Darren Tucker)
Date: Tue, 10 Nov 2015 10:35:39 +1100
Subject: OpenSSH-7.1p1 fails configure check with LibreSSL-2.2.4
In-Reply-To: <CACC5Q1fvXwoJSZfC8FHbXXGOtBCUxaW__PssyxfyWWVCOWC6pA@mail.gmail.com>
References: <CACC5Q1fvXwoJSZfC8FHbXXGOtBCUxaW__PssyxfyWWVCOWC6pA@mail.gmail.com>
Message-ID: <CALDDTe08u039LFPfiwr7abs98ZKX-NS3Ub0woCOqKXmxFd=rFg@mail.gmail.com>

On Tue, Nov 10, 2015 at 9:22 AM, Austin English <austinenglish at gmail.com> wrote:
> Howdy,
>
> I'm attempting to compile openssh-7.1p1 using libressl-2.2.4 for the
> ssl implementation. Unfortunately, this fails to work (tested on
> Debian Unstable and Gentoo):
[...]
> conftest.c:225:4: warning: implicit declaration of function 'exit'
> [-Wimplicit-function-declaration]
>     exit(1);
>     ^

These things are noise.  I'll fix them, but they're not the cause of
your problem.

> ./conftest: error while loading shared libraries: libcrypto.so.35:
> cannot open shared object file: No such file or directory

This is the problem: configure is telling the linker to link against
libcrypto in the libressl directory but you have not told the runtime
linker to look there for shared libraries, so your binaries (in this
case, the configure test) fail at runtime.

To fix this you probably want to either:
 - add /opt/libressl-2.2.4/lib to /etc/ld.conf or /etc/ld.conf.d/ and
run ldconfig
 - remove the .so files from /opt/libressl-2.2.4/lib so that the
linker will pick up the static libcrypto.

> doing:
> export LD_LIBRARY_PATH=/opt/libressl-2.2.4
>
> Works around this issue, and allows OpenSSH to compile (though some
> tests fail that don't with openssl-1.0.2d.

That'll help anything that inherits the environment, but anything that
sanitizes its environment (eg sudo) will fail, and the resulting
binaries won't work without the environment variable.

-- 
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 ross.snider at gmail.com  Tue Nov 10 13:49:02 2015
From: ross.snider at gmail.com (Ross Snider)
Date: Mon, 9 Nov 2015 18:49:02 -0800
Subject: Fwd: First steps to add an authenticated key agreement protocol
 (private branch).
In-Reply-To: <CAPoPW6G_pOFx8Vdm3JVaSnMTKXXc3wTdRh6ACw7BCt+9bkT_mg@mail.gmail.com>
References: <CAPoPW6FOPM03NE1d3ES2sNFZDPdF0_f6-=4fQDQPp0P8URw2cA@mail.gmail.com>
 <alpine.BSO.2.20.1511091350441.30289@natsu.mindrot.org>
 <CAPoPW6G_pOFx8Vdm3JVaSnMTKXXc3wTdRh6ACw7BCt+9bkT_mg@mail.gmail.com>
Message-ID: <CAPoPW6HOzVANmAadn5_AfvtvAh3WC3bQFFVugByGrBhbxX+Owg@mail.gmail.com>

Thanks you Damien, this will help a lot.

Authenticated key exchange. Yes. It will be tricky. I am going to use a
library with a trusted implementation and just do the 'plumbing'.

The keys unfortunately are in a new format. I am going to start with a very
ugly solution (some base64 serialization) and do not know if I will ever
need to get more serious. If I iterate on this format and move towards
standardization or something, I'll definitely reach out.

Both directions, but the primary application is client->server.

The last question about playing nicely with existing auth is a good
question. I have no idea. I think I will 'hack it on' first and iterate
toward something better.

The name of the cipher is Yuan-Li IBE authenticated key agreement.

Best,
Ross

From austinenglish at gmail.com  Tue Nov 10 15:23:12 2015
From: austinenglish at gmail.com (Austin English)
Date: Mon, 9 Nov 2015 22:23:12 -0600
Subject: OpenSSH-7.1p1 fails configure check with LibreSSL-2.2.4
In-Reply-To: <CALDDTe08u039LFPfiwr7abs98ZKX-NS3Ub0woCOqKXmxFd=rFg@mail.gmail.com>
References: <CACC5Q1fvXwoJSZfC8FHbXXGOtBCUxaW__PssyxfyWWVCOWC6pA@mail.gmail.com>
 <CALDDTe08u039LFPfiwr7abs98ZKX-NS3Ub0woCOqKXmxFd=rFg@mail.gmail.com>
Message-ID: <CACC5Q1dOLGFAugr=D5Haj1Z1C4j_-yF5imiee=rbko3+1-Jtkg@mail.gmail.com>

On Mon, Nov 9, 2015 at 5:35 PM, Darren Tucker <dtucker at zip.com.au> wrote:
> On Tue, Nov 10, 2015 at 9:22 AM, Austin English <austinenglish at gmail.com> wrote:
>> Howdy,
>>
>> I'm attempting to compile openssh-7.1p1 using libressl-2.2.4 for the
>> ssl implementation. Unfortunately, this fails to work (tested on
>> Debian Unstable and Gentoo):
> [...]
>> conftest.c:225:4: warning: implicit declaration of function 'exit'
>> [-Wimplicit-function-declaration]
>>     exit(1);
>>     ^
>
> These things are noise.  I'll fix them, but they're not the cause of
> your problem.

Sure, just wanted to be complete.

>> ./conftest: error while loading shared libraries: libcrypto.so.35:
>> cannot open shared object file: No such file or directory
>
> This is the problem: configure is telling the linker to link against
> libcrypto in the libressl directory but you have not told the runtime
> linker to look there for shared libraries, so your binaries (in this
> case, the configure test) fail at runtime.
>
> To fix this you probably want to either:
>  - add /opt/libressl-2.2.4/lib to /etc/ld.conf or /etc/ld.conf.d/ and
> run ldconfig
>  - remove the .so files from /opt/libressl-2.2.4/lib so that the
> linker will pick up the static libcrypto.

I tried removing the .so's, but openssh then falls back to the system
openssl instead of the specified ssl. The .a's are present (I also
tried explicitly building libressl with --enable-shared, but that made
no difference).

>> doing:
>> export LD_LIBRARY_PATH=/opt/libressl-2.2.4
>>
>> Works around this issue, and allows OpenSSH to compile (though some
>> tests fail that don't with openssl-1.0.2d.
>
> That'll help anything that inherits the environment, but anything that
> sanitizes its environment (eg sudo) will fail, and the resulting
> binaries won't work without the environment variable.
>
> --
> 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.



-- 
-Austin

From imorgan at nas.nasa.gov  Wed Nov 11 07:19:00 2015
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Tue, 10 Nov 2015 12:19:00 -0800
Subject: OpenSSH-7.1p1 fails configure check with LibreSSL-2.2.4
In-Reply-To: <CACC5Q1dOLGFAugr=D5Haj1Z1C4j_-yF5imiee=rbko3+1-Jtkg@mail.gmail.com>
References: <CACC5Q1fvXwoJSZfC8FHbXXGOtBCUxaW__PssyxfyWWVCOWC6pA@mail.gmail.com>
 <CALDDTe08u039LFPfiwr7abs98ZKX-NS3Ub0woCOqKXmxFd=rFg@mail.gmail.com>
 <CACC5Q1dOLGFAugr=D5Haj1Z1C4j_-yF5imiee=rbko3+1-Jtkg@mail.gmail.com>
Message-ID: <20151110201900.GA9605@linux124.nas.nasa.gov>

On Mon, Nov 09, 2015 at 22:23:12 -0600, Austin English wrote:
> On Mon, Nov 9, 2015 at 5:35 PM, Darren Tucker <dtucker at zip.com.au> wrote:
> > On Tue, Nov 10, 2015 at 9:22 AM, Austin English <austinenglish at gmail.com> wrote:
> >> Howdy,
> >>
> >> I'm attempting to compile openssh-7.1p1 using libressl-2.2.4 for the
> >> ssl implementation. Unfortunately, this fails to work (tested on
> >> Debian Unstable and Gentoo):
> > [...]
> >> conftest.c:225:4: warning: implicit declaration of function 'exit'
> >> [-Wimplicit-function-declaration]
> >>     exit(1);
> >>     ^
> >
> > These things are noise.  I'll fix them, but they're not the cause of
> > your problem.
> 
> Sure, just wanted to be complete.
> 
> >> ./conftest: error while loading shared libraries: libcrypto.so.35:
> >> cannot open shared object file: No such file or directory
> >
> > This is the problem: configure is telling the linker to link against
> > libcrypto in the libressl directory but you have not told the runtime
> > linker to look there for shared libraries, so your binaries (in this
> > case, the configure test) fail at runtime.
> >
> > To fix this you probably want to either:
> >  - add /opt/libressl-2.2.4/lib to /etc/ld.conf or /etc/ld.conf.d/ and
> > run ldconfig
> >  - remove the .so files from /opt/libressl-2.2.4/lib so that the
> > linker will pick up the static libcrypto.
> 
> I tried removing the .so's, but openssh then falls back to the system
> openssl instead of the specified ssl. The .a's are present (I also
> tried explicitly building libressl with --enable-shared, but that made
> no difference).

This is actually an old issue that predates LibreSSL. The static library
is not compiled with -fPIC, so it it unusable by OpenSSH when the
build-hardening options are enabled. If you rebuild LibreSSL with
CLFAGS=-fPIC and also supply --disable-shared to ./configure, OpenSSH
should be able to build. Alternatively, you could disable the build
hardening in OpenSSH, but that seems like a step backwards.

> 
> >> doing:
> >> export LD_LIBRARY_PATH=/opt/libressl-2.2.4
> >>
> >> Works around this issue, and allows OpenSSH to compile (though some
> >> tests fail that don't with openssl-1.0.2d.
> >
> > That'll help anything that inherits the environment, but anything that
> > sanitizes its environment (eg sudo) will fail, and the resulting
> > binaries won't work without the environment variable.
> >

Another alternative would be to pass -Wl,-R/opt/libressl-2.2.4/lib to
the compiler to embed the search path in the headers of the executables.
You could add --with-ldflags=-Wl,-R/opt/libressl-2.2.4/lib to the
configure options to OpenSSH.

It might be nice if this option was added automatically be configure,
but I don't know if it's sufficiently portable to be worthwhile.

-- 
Iain Morgan

> > --
> > 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.
> 
> 
> 
> -- 
> -Austin
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev

-- 
Iain Morgan

From carson at taltos.org  Wed Nov 11 07:41:46 2015
From: carson at taltos.org (Carson Gaspar)
Date: Tue, 10 Nov 2015 12:41:46 -0800
Subject: OpenSSH-7.1p1 fails configure check with LibreSSL-2.2.4
In-Reply-To: <20151110201900.GA9605@linux124.nas.nasa.gov>
References: <CACC5Q1fvXwoJSZfC8FHbXXGOtBCUxaW__PssyxfyWWVCOWC6pA@mail.gmail.com>
 <CALDDTe08u039LFPfiwr7abs98ZKX-NS3Ub0woCOqKXmxFd=rFg@mail.gmail.com>
 <CACC5Q1dOLGFAugr=D5Haj1Z1C4j_-yF5imiee=rbko3+1-Jtkg@mail.gmail.com>
 <20151110201900.GA9605@linux124.nas.nasa.gov>
Message-ID: <5642568A.8050202@taltos.org>

On 11/10/2015 12:19 PM, Iain Morgan wrote:

> Another alternative would be to pass -Wl,-R/opt/libressl-2.2.4/lib to
> the compiler to embed the search path in the headers of the executables.
> You could add --with-ldflags=-Wl,-R/opt/libressl-2.2.4/lib to the
> configure options to OpenSSH.

This is that "standard" hack for projects that hate RPATH

> It might be nice if this option was added automatically be configure,
> but I don't know if it's sufficiently portable to be worthwhile.

This is (IMNSHO) the correct fix, and there are autoconf modules to 
determine the toolchain specific linker options, or libtool will 
correctly handle "-mode=link -rpath /some/path" arguments.

If you wanted the library found by the standard linker path, why would 
you specify its location in the configure args?

-- 
Carson


From austinenglish at gmail.com  Wed Nov 11 11:13:02 2015
From: austinenglish at gmail.com (Austin English)
Date: Tue, 10 Nov 2015 18:13:02 -0600
Subject: OpenSSH-7.1p1 fails configure check with LibreSSL-2.2.4
In-Reply-To: <20151110201900.GA9605@linux124.nas.nasa.gov>
References: <CACC5Q1fvXwoJSZfC8FHbXXGOtBCUxaW__PssyxfyWWVCOWC6pA@mail.gmail.com>
 <CALDDTe08u039LFPfiwr7abs98ZKX-NS3Ub0woCOqKXmxFd=rFg@mail.gmail.com>
 <CACC5Q1dOLGFAugr=D5Haj1Z1C4j_-yF5imiee=rbko3+1-Jtkg@mail.gmail.com>
 <20151110201900.GA9605@linux124.nas.nasa.gov>
Message-ID: <CACC5Q1fH=M1FGQ1WHf-p3xoMA6b_SJYmh7hv5Nn2pGSEh35Brw@mail.gmail.com>

On Tue, Nov 10, 2015 at 2:19 PM, Iain Morgan <imorgan at nas.nasa.gov> wrote:
> On Mon, Nov 09, 2015 at 22:23:12 -0600, Austin English wrote:
>> On Mon, Nov 9, 2015 at 5:35 PM, Darren Tucker <dtucker at zip.com.au> wrote:
>> > On Tue, Nov 10, 2015 at 9:22 AM, Austin English <austinenglish at gmail.com> wrote:
>> >> Howdy,
>> >>
>> >> I'm attempting to compile openssh-7.1p1 using libressl-2.2.4 for the
>> >> ssl implementation. Unfortunately, this fails to work (tested on
>> >> Debian Unstable and Gentoo):
>> > [...]
>> >> conftest.c:225:4: warning: implicit declaration of function 'exit'
>> >> [-Wimplicit-function-declaration]
>> >>     exit(1);
>> >>     ^
>> >
>> > These things are noise.  I'll fix them, but they're not the cause of
>> > your problem.
>>
>> Sure, just wanted to be complete.
>>
>> >> ./conftest: error while loading shared libraries: libcrypto.so.35:
>> >> cannot open shared object file: No such file or directory
>> >
>> > This is the problem: configure is telling the linker to link against
>> > libcrypto in the libressl directory but you have not told the runtime
>> > linker to look there for shared libraries, so your binaries (in this
>> > case, the configure test) fail at runtime.
>> >
>> > To fix this you probably want to either:
>> >  - add /opt/libressl-2.2.4/lib to /etc/ld.conf or /etc/ld.conf.d/ and
>> > run ldconfig
>> >  - remove the .so files from /opt/libressl-2.2.4/lib so that the
>> > linker will pick up the static libcrypto.
>>
>> I tried removing the .so's, but openssh then falls back to the system
>> openssl instead of the specified ssl. The .a's are present (I also
>> tried explicitly building libressl with --enable-shared, but that made
>> no difference).
>
> This is actually an old issue that predates LibreSSL. The static library
> is not compiled with -fPIC, so it it unusable by OpenSSH when the
> build-hardening options are enabled. If you rebuild LibreSSL with
> CLFAGS=-fPIC and also supply --disable-shared to ./configure, OpenSSH
> should be able to build. Alternatively, you could disable the build
> hardening in OpenSSH, but that seems like a step backwards.

This does work, thanks for the tip!

>> >> doing:
>> >> export LD_LIBRARY_PATH=/opt/libressl-2.2.4
>> >>
>> >> Works around this issue, and allows OpenSSH to compile (though some
>> >> tests fail that don't with openssl-1.0.2d.
>> >
>> > That'll help anything that inherits the environment, but anything that
>> > sanitizes its environment (eg sudo) will fail, and the resulting
>> > binaries won't work without the environment variable.
>> >
>
> Another alternative would be to pass -Wl,-R/opt/libressl-2.2.4/lib to
> the compiler to embed the search path in the headers of the executables.
> You could add --with-ldflags=-Wl,-R/opt/libressl-2.2.4/lib to the
> configure options to OpenSSH.
>
> It might be nice if this option was added automatically be configure,
> but I don't know if it's sufficiently portable to be worthwhile.

Yes, it would. OpenSSH(p) runs on more platforms than I'm familiar
with, so I can't say :)

> --
> Iain Morgan
>
>> > --
>> > 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.
>>
>>
>>
>> --
>> -Austin
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
> --
> Iain Morgan



-- 
-Austin

From alex at cooperi.net  Fri Nov 13 12:00:48 2015
From: alex at cooperi.net (Alex Wilson)
Date: Thu, 12 Nov 2015 17:00:48 -0800
Subject: [PATCH] Drop fine-grained privileges on Illumos/Solaris
Message-ID: <56453640.5060202@cooperi.net>

Hi,

I'm not sure how interested anybody here is in this, but I've been
working lately on getting rid of the horror that is SunSSH for some
distros of Illumos (mostly SmartOS). One of the patches we're carrying
around at the moment is one that simply drops fine-grained privileges in
sshd, ssh-agent and sftp-server. Since the privilege dropping here is
roughly equivalent to a more verbose, coarser version of a tame() call,
I was wondering if there might be any interest in taking it into
openssh-portable in future.

Patch is attached. I've made sure all the code is behind
#ifdef USE_SOLARIS_PRIVS and added some code in configure.ac to turn
this macro on and off.

It also has a related fix which turns off the UID restoration test when
building --with-solaris-privs (since the fine-grained privs model lets
you create an ordinary user who can setuid to root, and sshd should
still let such a user log in if they're allowed to by the system).

Any feedback or comments would be appreciated, of course, even if this
isn't suitable for integration into -portable.

Thanks!
-------------- next part --------------
From 59fb63fd4e3fcc8d49f493d5900831350a1aa924 Mon Sep 17 00:00:00 2001
From: Alex Wilson <alex.wilson at joyent.com>
Date: Tue, 4 Aug 2015 15:50:09 -0700
Subject: [PATCH] Support for fine-grained Illumos/Solaris privileges

---
 configure.ac  | 14 ++++++++++++++
 sftp-server.c | 33 +++++++++++++++++++++++++++++++++
 ssh-agent.c   | 37 +++++++++++++++++++++++++++++++++++++
 sshd.c        | 33 +++++++++++++++++++++++++++++++++
 uidswap.c     | 18 ++++++++++++------
 5 files changed, 129 insertions(+), 6 deletions(-)

diff --git a/configure.ac b/configure.ac
index 1527a13..66493dc 100644
--- a/configure.ac
+++ b/configure.ac
@@ -575,6 +575,8 @@ case "$host" in
 	LIBS="$LIBS /usr/lib/textreadmode.o"
 	AC_DEFINE([HAVE_CYGWIN], [1], [Define if you are on Cygwin])
 	AC_DEFINE([USE_PIPES], [1], [Use PIPES instead of a socketpair()])
+	AC_DEFINE([NO_UID_RESTORATION_TEST], [1],
+		[Define to disable UID restoration test])
 	AC_DEFINE([DISABLE_SHADOW], [1],
 		[Define if you want to disable shadow passwords])
 	AC_DEFINE([NO_X11_UNIX_SOCKETS], [1],
@@ -910,6 +912,18 @@ mips-sony-bsd|mips-sony-newsos4)
 			SP_MSG="yes" ], )
 		],
 	)
+	AC_ARG_WITH([solaris-privs],
+		[  --with-solaris-privs    Enable Solaris/Illumos privileges (experimental)],
+		[
+		AC_CHECK_FUNC([setppriv],
+			[ AC_CHECK_HEADERS([priv.h])
+			  AC_DEFINE([NO_UID_RESTORATION_TEST], [1],
+				[Define to disable UID restoration test])
+			  AC_DEFINE([USE_SOLARIS_PRIVS], [1],
+				[Define if you have Solaris privileges])
+			SP_MSG="yes" ], )
+		],
+	)
 	TEST_SHELL=$SHELL	# let configure find us a capable shell
 	;;
 *-*-sunos4*)
diff --git a/sftp-server.c b/sftp-server.c
index eac11d7..db950c3 100644
--- a/sftp-server.c
+++ b/sftp-server.c
@@ -32,6 +32,9 @@
 #ifdef HAVE_SYS_PRCTL_H
 #include <sys/prctl.h>
 #endif
+#ifdef HAVE_PRIV_H
+# include <priv.h>
+#endif
 
 #include <dirent.h>
 #include <errno.h>
@@ -1509,6 +1512,9 @@ sftp_server_main(int argc, char **argv, struct passwd *user_pw)
 	SyslogFacility log_facility = SYSLOG_FACILITY_AUTH;
 	char *cp, *homedir = NULL, buf[4*4096];
 	long mask;
+#ifdef USE_SOLARIS_PRIVS
+	priv_set_t *pset = NULL;
+#endif
 
 	extern char *optarg;
 	extern char *__progname;
@@ -1598,6 +1604,33 @@ sftp_server_main(int argc, char **argv, struct passwd *user_pw)
 		fatal("unable to make the process undumpable");
 #endif /* defined(HAVE_PRCTL) && defined(PR_SET_DUMPABLE) */
 
+#ifdef USE_SOLARIS_PRIVS
+	/*
+	 * Drop Solaris/Illumos privileges. We don't need the ability to open
+	 * new network sockets, the ability to fork or exec, or the ability to
+	 * list/access other processes past this point.
+	 */
+	if ((pset = priv_allocset()) == NULL)
+		fatal("priv_allocset failed");
+	/* Start with "basic" and drop everything we don't need. */
+	priv_basicset(pset);
+	priv_delset(pset, PRIV_FILE_LINK_ANY);
+	priv_delset(pset, PRIV_PROC_INFO);
+	priv_delset(pset, PRIV_PROC_SESSION);
+	priv_delset(pset, PRIV_PROC_FORK);
+	priv_delset(pset, PRIV_NET_ACCESS);
+	priv_delset(pset, PRIV_PROC_EXEC);
+
+	if (setppriv(PRIV_SET, PRIV_PERMITTED, pset))
+		fatal("setppriv failed: %s", strerror(errno));
+	if (setppriv(PRIV_SET, PRIV_LIMIT, pset))
+		fatal("setppriv failed: %s", strerror(errno));
+	if (setppriv(PRIV_SET, PRIV_INHERITABLE, pset))
+		fatal("setppriv failed: %s", strerror(errno));
+
+	priv_freeset(pset);
+#endif
+
 	if ((cp = getenv("SSH_CONNECTION")) != NULL) {
 		client_addr = xstrdup(cp);
 		if ((cp = strchr(client_addr, ' ')) == NULL) {
diff --git a/ssh-agent.c b/ssh-agent.c
index a335ea3..23c6822 100644
--- a/ssh-agent.c
+++ b/ssh-agent.c
@@ -67,6 +67,9 @@
 #include <stdlib.h>
 #include <time.h>
 #include <string.h>
+#ifdef HAVE_PRIV_H
+# include <priv.h>
+#endif
 #include <unistd.h>
 #ifdef HAVE_UTIL_H
 # include <util.h>
@@ -1187,6 +1190,9 @@ main(int ac, char **av)
 	struct timeval *tvp = NULL;
 	size_t len;
 	mode_t prev_mask;
+#ifdef USE_SOLARIS_PRIVS
+	priv_set_t *pset = NULL;
+#endif
 
 	/* Ensure that fds 0, 1 and 2 are open or directed to /dev/null */
 	sanitise_stdfd();
@@ -1361,6 +1367,37 @@ main(int ac, char **av)
 	/* child */
 	log_init(__progname, SYSLOG_LEVEL_INFO, SYSLOG_FACILITY_AUTH, 0);
 
+#ifdef USE_SOLARIS_PRIVS
+	/*
+	 * Drop unneeded privs, including basic ones like fork/exec.
+	 */
+	if ((pset = priv_allocset()) == NULL) {
+		error("priv_allocset: %s", strerror(errno));
+		cleanup_exit(1);
+	}
+	/* Start with "basic" and drop everything we don't need. */
+	priv_basicset(pset);
+	priv_delset(pset, PRIV_PROC_EXEC);
+	priv_delset(pset, PRIV_PROC_FORK);
+	priv_delset(pset, PRIV_FILE_LINK_ANY);
+	priv_delset(pset, PRIV_PROC_INFO);
+	priv_delset(pset, PRIV_PROC_SESSION);
+
+	if (setppriv(PRIV_SET, PRIV_PERMITTED, pset)) {
+		error("setppriv: %s", strerror(errno));
+		cleanup_exit(1);
+	}
+	if (setppriv(PRIV_SET, PRIV_LIMIT, pset)) {
+		error("setppriv: %s", strerror(errno));
+		cleanup_exit(1);
+	}
+	if (setppriv(PRIV_SET, PRIV_INHERITABLE, pset)) {
+		error("setppriv: %s", strerror(errno));
+		cleanup_exit(1);
+	}
+	priv_freeset(pset);
+#endif
+
 	if (setsid() == -1) {
 		error("setsid: %s", strerror(errno));
 		cleanup_exit(1);
diff --git a/sshd.c b/sshd.c
index d868089..9fb45a3 100644
--- a/sshd.c
+++ b/sshd.c
@@ -72,6 +72,9 @@
 #include <string.h>
 #include <unistd.h>
 #include <limits.h>
+#ifdef HAVE_PRIV_H
+# include <priv.h>
+#endif
 
 #ifdef WITH_OPENSSL
 #include <openssl/dh.h>
@@ -610,6 +613,9 @@ privsep_preauth_child(void)
 {
 	u_int32_t rnd[256];
 	gid_t gidset[1];
+#ifdef USE_SOLARIS_PRIVS
+	priv_set_t *pset = NULL;
+#endif
 
 	/* Enable challenge-response authentication for privilege separation */
 	privsep_challenge_enable();
@@ -649,6 +655,33 @@ privsep_preauth_child(void)
 		fatal("setgroups: %.100s", strerror(errno));
 	permanently_set_uid(privsep_pw);
 #endif
+#ifdef USE_SOLARIS_PRIVS
+	/* Drop Solaris/Illumos privileges. */
+	if ((pset = priv_allocset()) == NULL)
+		fatal("priv_allocset failed");
+	/* Start with "basic" and drop everything we don't need. */
+	priv_basicset(pset);
+	priv_delset(pset, PRIV_FILE_LINK_ANY);
+	priv_delset(pset, PRIV_PROC_INFO);
+	priv_delset(pset, PRIV_PROC_SESSION);
+	priv_delset(pset, PRIV_PROC_FORK);
+	priv_delset(pset, PRIV_NET_ACCESS);
+	priv_delset(pset, PRIV_PROC_EXEC);
+	/* These may not be available on older Solaris-es */
+# if defined(PRIV_FILE_READ) && defined(PRIV_FILE_WRITE)
+	priv_delset(pset, PRIV_FILE_READ);
+	priv_delset(pset, PRIV_FILE_WRITE);
+# endif
+
+	if (setppriv(PRIV_SET, PRIV_PERMITTED, pset))
+		fatal("setppriv failed: %s", strerror(errno));
+	if (setppriv(PRIV_SET, PRIV_LIMIT, pset))
+		fatal("setppriv failed: %s", strerror(errno));
+	if (setppriv(PRIV_SET, PRIV_INHERITABLE, pset))
+		fatal("setppriv failed: %s", strerror(errno));
+
+	priv_freeset(pset);
+#endif
 }
 
 static int
diff --git a/uidswap.c b/uidswap.c
index 0702e1d..8bf6b24 100644
--- a/uidswap.c
+++ b/uidswap.c
@@ -134,7 +134,7 @@ temporarily_use_uid(struct passwd *pw)
 void
 permanently_drop_suid(uid_t uid)
 {
-#ifndef HAVE_CYGWIN
+#ifndef NO_UID_RESTORATION_TEST
 	uid_t old_uid = getuid();
 #endif
 
@@ -142,8 +142,14 @@ permanently_drop_suid(uid_t uid)
 	if (setresuid(uid, uid, uid) < 0)
 		fatal("setresuid %u: %.100s", (u_int)uid, strerror(errno));
 
-#ifndef HAVE_CYGWIN
-	/* Try restoration of UID if changed (test clearing of saved uid) */
+#ifndef NO_UID_RESTORATION_TEST
+	/*
+	 * Try restoration of UID if changed (test clearing of saved uid).
+	 *
+	 * Note that we don't do this on Cygwin, or on Solaris-based platforms
+	 * where fine-grained privileges are available (the user might be
+	 * deliberately allowed the right to setuid back to root).
+	 */
 	if (old_uid != uid &&
 	    (setuid(old_uid) != -1 || seteuid(old_uid) != -1))
 		fatal("%s: was able to restore old [e]uid", __func__);
@@ -199,7 +205,7 @@ restore_uid(void)
 void
 permanently_set_uid(struct passwd *pw)
 {
-#ifndef HAVE_CYGWIN
+#ifndef NO_UID_RESTORATION_TEST
 	uid_t old_uid = getuid();
 	gid_t old_gid = getgid();
 #endif
@@ -227,7 +233,7 @@ permanently_set_uid(struct passwd *pw)
 	if (setresuid(pw->pw_uid, pw->pw_uid, pw->pw_uid) < 0)
 		fatal("setresuid %u: %.100s", (u_int)pw->pw_uid, strerror(errno));
 
-#ifndef HAVE_CYGWIN
+#ifndef NO_UID_RESTORATION_TEST
 	/* Try restoration of GID if changed (test clearing of saved gid) */
 	if (old_gid != pw->pw_gid && pw->pw_uid != 0 &&
 	    (setgid(old_gid) != -1 || setegid(old_gid) != -1))
@@ -241,7 +247,7 @@ permanently_set_uid(struct passwd *pw)
 		    (u_int)pw->pw_gid);
 	}
 
-#ifndef HAVE_CYGWIN
+#ifndef NO_UID_RESTORATION_TEST
 	/* Try restoration of UID if changed (test clearing of saved uid) */
 	if (old_uid != pw->pw_uid &&
 	    (setuid(old_uid) != -1 || seteuid(old_uid) != -1))
-- 
2.4.9 (Apple Git-60)


From dtucker at zip.com.au  Fri Nov 13 13:24:59 2015
From: dtucker at zip.com.au (Darren Tucker)
Date: Fri, 13 Nov 2015 13:24:59 +1100
Subject: [PATCH] Drop fine-grained privileges on Illumos/Solaris
In-Reply-To: <56453640.5060202@cooperi.net>
References: <56453640.5060202@cooperi.net>
Message-ID: <CALDDTe2qHLOzT92shkM4B+gvc0c03_zcRoC=UhfV8pd2t8k+yQ@mail.gmail.com>

On Fri, Nov 13, 2015 at 12:00 PM, Alex Wilson <alex at cooperi.net> wrote:
> I'm not sure how interested anybody here is in this, but I've been
> working lately on getting rid of the horror that is SunSSH for some
> distros of Illumos (mostly SmartOS).

As long as someone is willing to do the work and help with tests
(which it sounds like you are), the support doesn't compromise other
platforms or make maintenance significantly harder then I have no
objections to it going in.

> One of the patches we're carrying
> around at the moment is one that simply drops fine-grained privileges in
> sshd, ssh-agent and sftp-server. Since the privilege dropping here is
> roughly equivalent to a more verbose, coarser version of a tame() call,
> I was wondering if there might be any interest in taking it into
> openssh-portable in future.

The code itself looks quite reasonable.  Placing it inline in the main
source files is problematic since it makes maintenance of those files
harder, but it it should fit nicely in openbsd-compat/port-solaris.c.

The similarities to tame (now renamed "pledge" in OpenBSD) are
potentially useful, as we may be able to put pledge calls into the
mainline code then use that to hook into the code you wrote.

The other place these look like the'd be useful is in the pre-auth
privsep sandbox, so you may want to look at one of the example
sandbox-*.c files.

-- 
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 cooperi.net  Sat Nov 14 07:20:03 2015
From: alex at cooperi.net (Alex Wilson)
Date: Fri, 13 Nov 2015 12:20:03 -0800
Subject: [PATCH] Drop fine-grained privileges on Illumos/Solaris
In-Reply-To: <CALDDTe2qHLOzT92shkM4B+gvc0c03_zcRoC=UhfV8pd2t8k+yQ@mail.gmail.com>
References: <56453640.5060202@cooperi.net>
 <CALDDTe2qHLOzT92shkM4B+gvc0c03_zcRoC=UhfV8pd2t8k+yQ@mail.gmail.com>
Message-ID: <564645F3.5050208@cooperi.net>

On 11/12/15 6:24 PM, Darren Tucker wrote:
> 
> As long as someone is willing to do the work and help with tests
> (which it sounds like you are), the support doesn't compromise other
> platforms or make maintenance significantly harder then I have no
> objections to it going in.

Sounds good to me. We're already running with this patch in
(pre-)production, and I'm definitely happy to help out with any
additional testing needed.

> 
> The code itself looks quite reasonable.  Placing it inline in the main
> source files is problematic since it makes maintenance of those files
> harder, but it it should fit nicely in openbsd-compat/port-solaris.c.
> ...
> The other place these look like the'd be useful is in the pre-auth
> privsep sandbox...
> 

Ok, please find attached a revised version. I've moved all of the
pre-auth privsep bit into a new sandbox-solaris.c, and for the ssh-agent
and sftp-server I've created the platform_drop_agent_privs() and
platform_drop_sftp_server_privs() hooks which, if USE_SOLARIS_PRIVS is
enabled then call out to the code that's now in
openbsd-compat/port-solaris.c

Does this look a bit better? The biggest annoyance I had is that now
ssh-agent and sftp-server have to link against platform.o, and the
easiest way to organise that seemed to be to add it to libssh.a. So now
all the cmdline tools also link against libcontract and libproject,
instead of just the daemon.

Using a platform_* function seems like a nicer interface than just
calling a port-solaris function inside an #ifdef in each of them, though
-- you can just add some code now in platform.c that uses pledge()
instead, for example. So maybe it's fine to have a bit of extra link bloat.
-------------- next part --------------
From 51dbb5957b7d3c2d7c7ae2226ce112bd596e8984 Mon Sep 17 00:00:00 2001
From: Alex Wilson <alex.wilson at joyent.com>
Date: Tue, 4 Aug 2015 15:50:09 -0700
Subject: [PATCH] Support for fine-grained Illumos/Solaris privileges

---
 Makefile.in                   |   6 ++-
 configure.ac                  |  26 ++++++++++-
 openbsd-compat/port-solaris.c |  62 +++++++++++++++++++++++++
 openbsd-compat/port-solaris.h |   3 ++
 platform.c                    |  24 ++++++++++
 platform.h                    |   2 +
 sandbox-solaris.c             | 103 ++++++++++++++++++++++++++++++++++++++++++
 sftp-server.c                 |   3 ++
 ssh-agent.c                   |   3 ++
 uidswap.c                     |  18 +++++---
 10 files changed, 240 insertions(+), 10 deletions(-)
 create mode 100644 sandbox-solaris.c

diff --git a/Makefile.in b/Makefile.in
index 15cf69e..bc8c522 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -91,7 +91,8 @@ LIBSSH_OBJS=${LIBOPENSSH_OBJS} \
 	sc25519.o ge25519.o fe25519.o ed25519.o verify.o hash.o blocks.o \
 	kex.o kexdh.o kexgex.o kexecdh.o kexc25519.o \
 	kexdhc.o kexgexc.o kexecdhc.o kexc25519c.o \
-	kexdhs.o kexgexs.o kexecdhs.o kexc25519s.o
+	kexdhs.o kexgexs.o kexecdhs.o kexc25519s.o \
+	platform.o
 
 SSHOBJS= ssh.o readconf.o clientloop.o sshtty.o \
 	sshconnect.o sshconnect1.o sshconnect2.o mux.o \
@@ -110,7 +111,8 @@ SSHDOBJS=sshd.o auth-rhosts.o auth-passwd.o auth-rsa.o auth-rh-rsa.o \
 	sftp-server.o sftp-common.o \
 	roaming_common.o roaming_serv.o \
 	sandbox-null.o sandbox-rlimit.o sandbox-systrace.o sandbox-darwin.o \
-	sandbox-seccomp-filter.o sandbox-capsicum.o sandbox-pledge.o
+	sandbox-seccomp-filter.o sandbox-capsicum.o sandbox-pledge.o \
+	sandbox-solaris.o
 
 MANPAGES	= moduli.5.out scp.1.out ssh-add.1.out ssh-agent.1.out ssh-keygen.1.out ssh-keyscan.1.out ssh.1.out sshd.8.out sftp-server.8.out sftp.1.out ssh-keysign.8.out ssh-pkcs11-helper.8.out sshd_config.5.out ssh_config.5.out
 MANPAGES_IN	= moduli.5 scp.1 ssh-add.1 ssh-agent.1 ssh-keygen.1 ssh-keyscan.1 ssh.1 sshd.8 sftp-server.8 sftp.1 ssh-keysign.8 ssh-pkcs11-helper.8 sshd_config.5 ssh_config.5
diff --git a/configure.ac b/configure.ac
index 1527a13..10b6da8 100644
--- a/configure.ac
+++ b/configure.ac
@@ -469,6 +469,7 @@ AC_CHECK_HEADERS([sys/un.h], [], [], [
 SIA_MSG="no"
 SPC_MSG="no"
 SP_MSG="no"
+SPP_MSG="no"
 
 # Check for some target-specific stuff
 case "$host" in
@@ -575,6 +576,8 @@ case "$host" in
 	LIBS="$LIBS /usr/lib/textreadmode.o"
 	AC_DEFINE([HAVE_CYGWIN], [1], [Define if you are on Cygwin])
 	AC_DEFINE([USE_PIPES], [1], [Use PIPES instead of a socketpair()])
+	AC_DEFINE([NO_UID_RESTORATION_TEST], [1],
+		[Define to disable UID restoration test])
 	AC_DEFINE([DISABLE_SHADOW], [1],
 		[Define if you want to disable shadow passwords])
 	AC_DEFINE([NO_X11_UNIX_SOCKETS], [1],
@@ -896,7 +899,7 @@ mips-sony-bsd|mips-sony-newsos4)
 		AC_CHECK_LIB([contract], [ct_tmpl_activate],
 			[ AC_DEFINE([USE_SOLARIS_PROCESS_CONTRACTS], [1],
 				[Define if you have Solaris process contracts])
-			  SSHDLIBS="$SSHDLIBS -lcontract"
+			  LIBS="$LIBS -lcontract"
 			  SPC_MSG="yes" ], )
 		],
 	)
@@ -906,10 +909,22 @@ mips-sony-bsd|mips-sony-newsos4)
 		AC_CHECK_LIB([project], [setproject],
 			[ AC_DEFINE([USE_SOLARIS_PROJECTS], [1],
 				[Define if you have Solaris projects])
-			SSHDLIBS="$SSHDLIBS -lproject"
+			LIBS="$LIBS -lproject"
 			SP_MSG="yes" ], )
 		],
 	)
+	AC_ARG_WITH([solaris-privs],
+		[  --with-solaris-privs    Enable Solaris/Illumos privileges (experimental)],
+		[
+		AC_CHECK_FUNC([setppriv],
+			[ AC_CHECK_HEADERS([priv.h])
+			  AC_DEFINE([NO_UID_RESTORATION_TEST], [1],
+				[Define to disable UID restoration test])
+			  AC_DEFINE([USE_SOLARIS_PRIVS], [1],
+				[Define if you have Solaris privileges])
+			SPP_MSG="yes" ], )
+		],
+	)
 	TEST_SHELL=$SHELL	# let configure find us a capable shell
 	;;
 *-*-sunos4*)
@@ -3155,6 +3170,12 @@ elif test "x$sandbox_arg" = "xrlimit" || \
 		AC_MSG_ERROR([rlimit sandbox requires select to work with rlimit])
 	SANDBOX_STYLE="rlimit"
 	AC_DEFINE([SANDBOX_RLIMIT], [1], [Sandbox using setrlimit(2)])
+elif test "x$sandbox_arg" = "xsolaris" || \
+   ( test -z "$sandbox_arg" && test "x$ac_cv_func_setppriv" = "xyes" ) ; then
+	test "x$ac_cv_func_setppriv" != "xyes" && \
+		AC_MSG_ERROR([solaris sandbox requires setppriv(2) support])
+	SANDBOX_STYLE="solaris"
+	AC_DEFINE([SANDBOX_SOLARIS], [1], [Sandbox using Solaris/Illumos privileges])
 elif test -z "$sandbox_arg" || test "x$sandbox_arg" = "xno" || \
      test "x$sandbox_arg" = "xnone" || test "x$sandbox_arg" = "xnull" ; then
 	SANDBOX_STYLE="none"
@@ -4944,6 +4965,7 @@ echo "              MD5 password support: $MD5_MSG"
 echo "                   libedit support: $LIBEDIT_MSG"
 echo "  Solaris process contract support: $SPC_MSG"
 echo "           Solaris project support: $SP_MSG"
+echo " Solaris/Illumos privilege support: $SPP_MSG"
 echo "       IP address in \$DISPLAY hack: $DISPLAY_HACK_MSG"
 echo "           Translate v4 in v6 hack: $IPV4_IN6_HACK_MSG"
 echo "                  BSD Auth support: $BSD_AUTH_MSG"
diff --git a/openbsd-compat/port-solaris.c b/openbsd-compat/port-solaris.c
index 25382f1..50e6fdc 100644
--- a/openbsd-compat/port-solaris.c
+++ b/openbsd-compat/port-solaris.c
@@ -227,3 +227,65 @@ solaris_set_default_project(struct passwd *pw)
 	}
 }
 #endif /* USE_SOLARIS_PROJECTS */
+
+#ifdef USE_SOLARIS_PRIVS
+# ifdef HAVE_PRIV_H
+#  include <priv.h>
+# endif
+
+void
+solaris_drop_fork_privs(void)
+{
+	priv_set_t *pset = NULL;
+
+	if ((pset = priv_allocset()) == NULL)
+		fatal("priv_allocset: %s", strerror(errno));
+
+	/* Start with "basic" and drop everything we don't need. */
+	priv_basicset(pset);
+
+	priv_delset(pset, PRIV_PROC_EXEC);
+	priv_delset(pset, PRIV_PROC_FORK);
+	priv_delset(pset, PRIV_FILE_LINK_ANY);
+	priv_delset(pset, PRIV_PROC_INFO);
+	priv_delset(pset, PRIV_PROC_SESSION);
+
+	if (setppriv(PRIV_SET, PRIV_PERMITTED, pset))
+		fatal("setppriv: %s", strerror(errno));
+	if (setppriv(PRIV_SET, PRIV_LIMIT, pset))
+		fatal("setppriv: %s", strerror(errno));
+	if (setppriv(PRIV_SET, PRIV_INHERITABLE, pset))
+		fatal("setppriv: %s", strerror(errno));
+
+	priv_freeset(pset);
+}
+
+void
+solaris_drop_fork_net_privs(void)
+{
+	priv_set_t *pset = NULL;
+
+	if ((pset = priv_allocset()) == NULL)
+		fatal("priv_allocset: %s", strerror(errno));
+
+	/* Start with "basic" and drop everything we don't need. */
+	priv_basicset(pset);
+
+	priv_delset(pset, PRIV_FILE_LINK_ANY);
+	priv_delset(pset, PRIV_PROC_INFO);
+	priv_delset(pset, PRIV_PROC_SESSION);
+	priv_delset(pset, PRIV_PROC_FORK);
+	priv_delset(pset, PRIV_NET_ACCESS);
+	priv_delset(pset, PRIV_PROC_EXEC);
+
+	if (setppriv(PRIV_SET, PRIV_PERMITTED, pset))
+		fatal("setppriv: %s", strerror(errno));
+	if (setppriv(PRIV_SET, PRIV_LIMIT, pset))
+		fatal("setppriv: %s", strerror(errno));
+	if (setppriv(PRIV_SET, PRIV_INHERITABLE, pset))
+		fatal("setppriv: %s", strerror(errno));
+
+	priv_freeset(pset);
+}
+
+#endif
diff --git a/openbsd-compat/port-solaris.h b/openbsd-compat/port-solaris.h
index cd442e7..686bce2 100644
--- a/openbsd-compat/port-solaris.h
+++ b/openbsd-compat/port-solaris.h
@@ -26,5 +26,8 @@ void solaris_contract_pre_fork(void);
 void solaris_contract_post_fork_child(void);
 void solaris_contract_post_fork_parent(pid_t pid);
 void solaris_set_default_project(struct passwd *);
+void solaris_drop_fork_privs(void);
+void solaris_drop_fork_net_privs(void);
+void solaris_drop_all_privs(void);
 
 #endif
diff --git a/platform.c b/platform.c
index ee313da..703d47e 100644
--- a/platform.c
+++ b/platform.c
@@ -213,3 +213,27 @@ platform_sys_dir_uid(uid_t uid)
 #endif
 	return 0;
 }
+
+/*
+ * Drop any fine-grained privileges that are not needed for post-startup
+ * operation of ssh-agent
+ */
+void
+platform_drop_agent_privs(void)
+{
+#ifdef USE_SOLARIS_PRIVS
+	solaris_drop_fork_privs();
+#endif
+}
+
+/*
+ * Drop any fine-grained privileges that are not needed for post-startup
+ * operation of sftp-server
+ */
+void
+platform_drop_sftp_server_privs(void)
+{
+#ifdef USE_SOLARIS_PRIVS
+	solaris_drop_fork_net_privs();
+#endif
+}
diff --git a/platform.h b/platform.h
index 1c7a45d..eac9b9d 100644
--- a/platform.h
+++ b/platform.h
@@ -31,3 +31,5 @@ void platform_setusercontext_post_groups(struct passwd *);
 char *platform_get_krb5_client(const char *);
 char *platform_krb5_get_principal_name(const char *);
 int platform_sys_dir_uid(uid_t);
+void platform_drop_agent_privs(void);
+void platform_drop_sftp_server_privs(void);
diff --git a/sandbox-solaris.c b/sandbox-solaris.c
new file mode 100644
index 0000000..3369531
--- /dev/null
+++ b/sandbox-solaris.c
@@ -0,0 +1,103 @@
+/*
+ * Copyright (c) 2015 Joyent, Inc
+ * Author: Alex Wilson <alex.wilson at joyent.com>
+ *
+ * Permission to use, copy, modify, and distribute this software for any
+ * purpose with or without fee is hereby granted, provided that the above
+ * copyright notice and this permission notice appear in all copies.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS" AND THE AUTHOR DISCLAIMS ALL WARRANTIES
+ * WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
+ * MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR
+ * ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+ * WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN AN
+ * ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION, ARISING OUT OF
+ * OR IN CONNECTION WITH THE USE OR PERFORMANCE OF THIS SOFTWARE.
+ */
+
+#include "includes.h"
+
+#ifdef SANDBOX_SOLARIS
+#ifndef USE_SOLARIS_PRIVS
+# error "--with-solaris-privs must be used with the Solaris sandbox"
+#endif
+
+#include <sys/types.h>
+
+#include <errno.h>
+#include <stdarg.h>
+#include <stdio.h>
+#include <stdlib.h>
+#include <string.h>
+#include <unistd.h>
+#ifdef HAVE_PRIV_H
+# include <priv.h>
+#endif
+
+#include "log.h"
+#include "ssh-sandbox.h"
+#include "xmalloc.h"
+
+struct ssh_sandbox {
+	priv_set_t *pset;
+};
+
+struct ssh_sandbox *
+ssh_sandbox_init(struct monitor *monitor)
+{
+	struct ssh_sandbox *box = NULL;
+
+	box = xcalloc(1, sizeof(*box));
+	box->pset = priv_allocset();
+
+	if (box->pset == NULL) {
+		free(box);
+		return NULL;
+	}
+
+	/* Start with "basic" and drop everything we don't need. */
+	priv_basicset(box->pset);
+
+	/* Drop everything except the ability to use already-opened files */
+	priv_delset(box->pset, PRIV_FILE_LINK_ANY);
+	priv_delset(box->pset, PRIV_PROC_INFO);
+	priv_delset(box->pset, PRIV_PROC_SESSION);
+	priv_delset(box->pset, PRIV_PROC_FORK);
+	priv_delset(box->pset, PRIV_NET_ACCESS);
+	priv_delset(box->pset, PRIV_PROC_EXEC);
+
+	/* These may not be available on older Solaris-es */
+# if defined(PRIV_FILE_READ) && defined(PRIV_FILE_WRITE)
+	priv_delset(box->pset, PRIV_FILE_READ);
+	priv_delset(box->pset, PRIV_FILE_WRITE);
+# endif
+
+	return box;
+}
+
+void
+ssh_sandbox_child(struct ssh_sandbox *box)
+{
+	if (setppriv(PRIV_SET, PRIV_PERMITTED, box->pset))
+		fatal("setppriv: %s", strerror(errno));
+	if (setppriv(PRIV_SET, PRIV_LIMIT, box->pset))
+		fatal("setppriv: %s", strerror(errno));
+	if (setppriv(PRIV_SET, PRIV_INHERITABLE, box->pset))
+		fatal("setppriv: %s", strerror(errno));
+}
+
+void
+ssh_sandbox_parent_finish(struct ssh_sandbox *box)
+{
+	priv_freeset(box->pset);
+	box->pset = NULL;
+	free(box);
+}
+
+void
+ssh_sandbox_parent_preauth(struct ssh_sandbox *box, pid_t child_pid)
+{
+	/* Nothing to do here */
+}
+
+#endif /* SANDBOX_SOLARIS */
diff --git a/sftp-server.c b/sftp-server.c
index eac11d7..2a11d3f 100644
--- a/sftp-server.c
+++ b/sftp-server.c
@@ -1598,6 +1598,9 @@ sftp_server_main(int argc, char **argv, struct passwd *user_pw)
 		fatal("unable to make the process undumpable");
 #endif /* defined(HAVE_PRCTL) && defined(PR_SET_DUMPABLE) */
 
+	/* Drop any fine-grained privileges we don't need */
+	platform_drop_sftp_server_privs();
+
 	if ((cp = getenv("SSH_CONNECTION")) != NULL) {
 		client_addr = xstrdup(cp);
 		if ((cp = strchr(client_addr, ' ')) == NULL) {
diff --git a/ssh-agent.c b/ssh-agent.c
index a335ea3..7971a57 100644
--- a/ssh-agent.c
+++ b/ssh-agent.c
@@ -1361,6 +1361,9 @@ main(int ac, char **av)
 	/* child */
 	log_init(__progname, SYSLOG_LEVEL_INFO, SYSLOG_FACILITY_AUTH, 0);
 
+	/* Drop any fine-grained privileges we don't need */
+	platform_drop_agent_privs();
+
 	if (setsid() == -1) {
 		error("setsid: %s", strerror(errno));
 		cleanup_exit(1);
diff --git a/uidswap.c b/uidswap.c
index 0702e1d..8bf6b24 100644
--- a/uidswap.c
+++ b/uidswap.c
@@ -134,7 +134,7 @@ temporarily_use_uid(struct passwd *pw)
 void
 permanently_drop_suid(uid_t uid)
 {
-#ifndef HAVE_CYGWIN
+#ifndef NO_UID_RESTORATION_TEST
 	uid_t old_uid = getuid();
 #endif
 
@@ -142,8 +142,14 @@ permanently_drop_suid(uid_t uid)
 	if (setresuid(uid, uid, uid) < 0)
 		fatal("setresuid %u: %.100s", (u_int)uid, strerror(errno));
 
-#ifndef HAVE_CYGWIN
-	/* Try restoration of UID if changed (test clearing of saved uid) */
+#ifndef NO_UID_RESTORATION_TEST
+	/*
+	 * Try restoration of UID if changed (test clearing of saved uid).
+	 *
+	 * Note that we don't do this on Cygwin, or on Solaris-based platforms
+	 * where fine-grained privileges are available (the user might be
+	 * deliberately allowed the right to setuid back to root).
+	 */
 	if (old_uid != uid &&
 	    (setuid(old_uid) != -1 || seteuid(old_uid) != -1))
 		fatal("%s: was able to restore old [e]uid", __func__);
@@ -199,7 +205,7 @@ restore_uid(void)
 void
 permanently_set_uid(struct passwd *pw)
 {
-#ifndef HAVE_CYGWIN
+#ifndef NO_UID_RESTORATION_TEST
 	uid_t old_uid = getuid();
 	gid_t old_gid = getgid();
 #endif
@@ -227,7 +233,7 @@ permanently_set_uid(struct passwd *pw)
 	if (setresuid(pw->pw_uid, pw->pw_uid, pw->pw_uid) < 0)
 		fatal("setresuid %u: %.100s", (u_int)pw->pw_uid, strerror(errno));
 
-#ifndef HAVE_CYGWIN
+#ifndef NO_UID_RESTORATION_TEST
 	/* Try restoration of GID if changed (test clearing of saved gid) */
 	if (old_gid != pw->pw_gid && pw->pw_uid != 0 &&
 	    (setgid(old_gid) != -1 || setegid(old_gid) != -1))
@@ -241,7 +247,7 @@ permanently_set_uid(struct passwd *pw)
 		    (u_int)pw->pw_gid);
 	}
 
-#ifndef HAVE_CYGWIN
+#ifndef NO_UID_RESTORATION_TEST
 	/* Try restoration of UID if changed (test clearing of saved uid) */
 	if (old_uid != pw->pw_uid &&
 	    (setuid(old_uid) != -1 || seteuid(old_uid) != -1))
-- 
2.4.9 (Apple Git-60)


From alon.barlev at gmail.com  Sun Nov 15 18:55:54 2015
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Sun, 15 Nov 2015 09:55:54 +0200
Subject: ~/.ssh/config permissions
Message-ID: <CAOazyz1gp6qzWav0ekwSKGDO=1Rjj2MgHBXUQHPF+xse1r6pwA@mail.gmail.com>

Hi,

Working with apache-sshd I found that it forces ~/.ssh/config to be
owned by user without group/others permissions. It failed for me
within my valid openssh environment.

Within sources (readconf.c::read_config_file), I found that openssh
only enforces ownership by user and not group/others write.

When I opened an issue, I was referred to this[1] wiki page (not sure
who maintain it) claiming that:
"""
This file must not be accessible to other users in any way. Set strict
permissions: read/write for the user, and not accessible by others. It
may group-writable if and only if that user is the only member of the
group in question.
"""

Personally, I prefer the sources as a reference, but as this wiki page
is source for information for some, and find no reason why this file
is sensitive for read.

I would like to know what is the expected behaviour.

Regards,
Alon Bar-Lev.

[1] https://en.wikibooks.org/wiki/OpenSSH/Client_Configuration_Files#.7E.2F.ssh.2Fconfig

From imorgan at nas.nasa.gov  Wed Nov 18 09:50:47 2015
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Tue, 17 Nov 2015 14:50:47 -0800
Subject: [PATCH] Skip RSA1 host key when using hostbased auth
Message-ID: <20151117225047.GB9605@linux124.nas.nasa.gov>

Hello,

The following patch avoids a warnign message when using hostbased
authentication as root and protocol v1 support has been disabled. The
case for non-root users has already been addressed, but root follows a
different code path.

-- 
Iain Morgan

diff --git a/ssh.c b/ssh.c
index cceb36e..e32aa0a 100644
--- a/ssh.c
+++ b/ssh.c
@@ -1242,8 +1242,10 @@ main(int ac, char **av)
 			sensitive_data.keys[i] = NULL;
 
 		PRIV_START;
+#ifdef WITH_SSH1
 		sensitive_data.keys[0] = key_load_private_type(KEY_RSA1,
 		    _PATH_HOST_KEY_FILE, "", NULL, NULL);
+#endif
 #ifdef OPENSSL_HAS_ECC
 		sensitive_data.keys[1] = key_load_private_cert(KEY_ECDSA,
 		    _PATH_HOST_ECDSA_KEY_FILE, "", NULL);

From peter at stuge.se  Wed Nov 18 16:55:25 2015
From: peter at stuge.se (Peter Stuge)
Date: Wed, 18 Nov 2015 06:55:25 +0100
Subject: [PATCH] Skip RSA1 host key when using hostbased auth
In-Reply-To: <20151117225047.GB9605@linux124.nas.nasa.gov>
References: <20151117225047.GB9605@linux124.nas.nasa.gov>
Message-ID: <20151118055525.18812.qmail@stuge.se>

Iain Morgan wrote:
> --- a/ssh.c
> +++ b/ssh.c
> @@ -1242,8 +1242,10 @@ main(int ac, char **av)
>  			sensitive_data.keys[i] = NULL;
>  
>  		PRIV_START;
> +#ifdef WITH_SSH1
>  		sensitive_data.keys[0] = key_load_private_type(KEY_RSA1,
>  		    _PATH_HOST_KEY_FILE, "", NULL, NULL);
> +#endif
>  #ifdef OPENSSL_HAS_ECC
>  		sensitive_data.keys[1] = key_load_private_cert(KEY_ECDSA,

Wouldn't you need a counter or something, for the index?


//Peter

From list at eworm.de  Wed Nov 18 18:57:05 2015
From: list at eworm.de (Christian Hesse)
Date: Wed, 18 Nov 2015 08:57:05 +0100
Subject: AddKeysToAgent break local forwarding (and possibly more)
Message-ID: <20151118085705.2ca2313d@leda.localdomain>

Hello everybody,

current git breaks local forwarding (and possibly more). Looks like the
option in ignored completely. I bisected the issue and found this commit to be
the culprit:

commit f361df474c49a097bfcf16d1b7b5c36fcd844b4b
Author: jcs at openbsd.org <jcs at openbsd.org>
Date:   Sun Nov 15 22:26:49 2015 +0000

    upstream commit
    
    Add an AddKeysToAgent client option which can be set to
     'yes', 'no', 'ask', or 'confirm', and defaults to 'no'.  When enabled, a
     private key that is used during authentication will be added to
    ssh-agent if it is running (with confirmation enabled if set to
    'confirm'). 
    Initial version from Joachim Schipper many years ago.
    
    ok markus@
    
    Upstream-ID: a680db2248e8064ec55f8be72d539458c987d5f4

Giving an extra '-o AddKeysToAgent=yes' makes the local forwarding work
again, but I suppose that's not the expected behavior. ;)
-- 
main(a){char*c=/*    Schoene Gruesse                         */"B?IJj;MEH"
"CX:;",b;for(a/*    Chris           get my mail address:    */=0;b=c[a++];)
putchar(b-1/(/*               gcc -o sig sig.c && ./sig    */b/42*2-3)*42);}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20151118/54131d17/attachment.bin>

From list at eworm.de  Wed Nov 18 19:33:50 2015
From: list at eworm.de (Christian Hesse)
Date: Wed, 18 Nov 2015 09:33:50 +0100
Subject: AddKeysToAgent break local forwarding (and possibly more)
In-Reply-To: <20151118085705.2ca2313d@leda.localdomain>
References: <20151118085705.2ca2313d@leda.localdomain>
Message-ID: <20151118093350.106ed42c@leda.localdomain>

Christian Hesse <list at eworm.de> on Wed, 2015/11/18 08:57:
> Hello everybody,
> 
> current git breaks local forwarding (and possibly more). Looks like the
> option in ignored completely. I bisected the issue and found this commit to
> be the culprit:
> 
> commit f361df474c49a097bfcf16d1b7b5c36fcd844b4b
> Author: jcs at openbsd.org <jcs at openbsd.org>
> Date:   Sun Nov 15 22:26:49 2015 +0000

I was kind of wrong. After a

$ make clean
$ make ssh

everything works as expected. Looks like readconf.o was not regenerated after
readconf.h changed... That made ssh read the wrong value from struct Options.

But possibly the build system needs some tweaking. Object files should be
regenerated after header files changed, no?
-- 
main(a){char*c=/*    Schoene Gruesse                         */"B?IJj;MEH"
"CX:;",b;for(a/*    Chris           get my mail address:    */=0;b=c[a++];)
putchar(b-1/(/*               gcc -o sig sig.c && ./sig    */b/42*2-3)*42);}
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20151118/05dd8c5a/attachment-0001.bin>

From djm at mindrot.org  Wed Nov 18 19:45:22 2015
From: djm at mindrot.org (Damien Miller)
Date: Wed, 18 Nov 2015 19:45:22 +1100 (AEDT)
Subject: AddKeysToAgent break local forwarding (and possibly more)
In-Reply-To: <20151118085705.2ca2313d@leda.localdomain>
References: <20151118085705.2ca2313d@leda.localdomain>
Message-ID: <alpine.BSO.2.20.1511181927070.12629@natsu.mindrot.org>

On Wed, 18 Nov 2015, Christian Hesse wrote:

> Hello everybody,
> 
> current git breaks local forwarding (and possibly more). Looks like the
> option in ignored completely. I bisected the issue and found this commit to be
> the culprit:

I can't replicate this and regress/unit tests pass okay for me (once I
committed bcb7bc77bbb to fix a ssh-keygen bug).

How is it broken? Can you show a debug trace?

(did you forget to "make clean"?)

-d

From djm at mindrot.org  Wed Nov 18 19:46:30 2015
From: djm at mindrot.org (Damien Miller)
Date: Wed, 18 Nov 2015 19:46:30 +1100 (AEDT)
Subject: AddKeysToAgent break local forwarding (and possibly more)
In-Reply-To: <20151118093350.106ed42c@leda.localdomain>
References: <20151118085705.2ca2313d@leda.localdomain>
 <20151118093350.106ed42c@leda.localdomain>
Message-ID: <alpine.BSO.2.20.1511181945360.12629@natsu.mindrot.org>

On Wed, 18 Nov 2015, Christian Hesse wrote:

> Christian Hesse <list at eworm.de> on Wed, 2015/11/18 08:57:
> > Hello everybody,
> > 
> > current git breaks local forwarding (and possibly more). Looks like the
> > option in ignored completely. I bisected the issue and found this commit to
> > be the culprit:
> > 
> > commit f361df474c49a097bfcf16d1b7b5c36fcd844b4b
> > Author: jcs at openbsd.org <jcs at openbsd.org>
> > Date:   Sun Nov 15 22:26:49 2015 +0000
> 
> I was kind of wrong. After a
> 
> $ make clean
> $ make ssh
> 
> everything works as expected. Looks like readconf.o was not regenerated after
> readconf.h changed... That made ssh read the wrong value from struct Options.
> 
> But possibly the build system needs some tweaking. Object files should be
> regenerated after header files changed, no?

Yes, they should but I never implemented makedepend generation because
I couldn't get it working cross-platform. I'd love someone to take another
try at it.

-d


From depesz at depesz.com  Wed Nov 18 21:25:43 2015
From: depesz at depesz.com (hubert depesz lubaczewski)
Date: Wed, 18 Nov 2015 11:25:43 +0100
Subject: How to add configuration (~/.ssh/config) per ip?
Message-ID: <20151118102543.GB20202@depesz.com>

Hi,
at work we have hundreds of machines, and for various of reasons, their
hostnames (with domain) do not reflect their physical location.
This means that for host "a.bb.cc" i have to go through jump host
"jump1.bb.cc", and for "c.bb.cc" i have to go through jump host
"jump2.bb.cc".

which jump host should be used can be deduced by IP, but it looks that
rules like:

Host 10.1.*
    ProxyCommand ssh -W %h:%p jump1.bb.cc

Are not being applied when I just:

ssh a.bb.cc

Is there any way to make ssh apply rules both based on name and based on
ip?

I could, of course, add special rule for each hostname, but that would
mean that my ~/.ssh/config will be huge, and constantly change (new
hosts added, old hosts removed).

Best regards,

depesz

-- 
The best thing about modern society is how easy it is to avoid contact with it.
                                                             http://depesz.com/

From sfandino at gmail.com  Wed Nov 18 23:26:20 2015
From: sfandino at gmail.com (Salvador Fandino)
Date: Wed, 18 Nov 2015 13:26:20 +0100
Subject: How to add configuration (~/.ssh/config) per ip?
In-Reply-To: <20151118102543.GB20202@depesz.com>
References: <20151118102543.GB20202@depesz.com>
Message-ID: <564C6E6C.8070405@gmail.com>

On 11/18/2015 11:25 AM, hubert depesz lubaczewski wrote:
> Hi,
> at work we have hundreds of machines, and for various of reasons, their
> hostnames (with domain) do not reflect their physical location.
> This means that for host "a.bb.cc" i have to go through jump host
> "jump1.bb.cc", and for "c.bb.cc" i have to go through jump host
> "jump2.bb.cc".
>
> which jump host should be used can be deduced by IP, but it looks that
> rules like:
>
> Host 10.1.*
>      ProxyCommand ssh -W %h:%p jump1.bb.cc
>
> Are not being applied when I just:
>
> ssh a.bb.cc
>
> Is there any way to make ssh apply rules both based on name and based on
> ip?
>
> I could, of course, add special rule for each hostname, but that would
> mean that my ~/.ssh/config will be huge, and constantly change (new
> hosts added, old hosts removed).

you can write a script that applies any rules you may have, or even 
query some database to generate on the fly and exec'ute the correct 
proxycommand.

Something similar to:

   Host 10.1.*
      ProxyCommand connect-through-gateway %h %p

where "connect-through-gateway" is that script.

From depesz at depesz.com  Wed Nov 18 23:31:07 2015
From: depesz at depesz.com (hubert depesz lubaczewski)
Date: Wed, 18 Nov 2015 13:31:07 +0100
Subject: How to add configuration (~/.ssh/config) per ip?
In-Reply-To: <564C6E6C.8070405@gmail.com>
References: <20151118102543.GB20202@depesz.com>
 <564C6E6C.8070405@gmail.com>
Message-ID: <20151118123107.GA25615@depesz.com>

On Wed, Nov 18, 2015 at 01:26:20PM +0100, Salvador Fandino wrote:
> Something similar to:
> 
>   Host 10.1.*
>      ProxyCommand connect-through-gateway %h %p
> where "connect-through-gateway" is that script.

Thanks. Somehow it totally slipped my mind that I can script it.

Best regards,

depesz

-- 
The best thing about modern society is how easy it is to avoid contact with it.
                                                             http://depesz.com/

From alon.barlev at gmail.com  Thu Nov 19 00:13:14 2015
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Wed, 18 Nov 2015 15:13:14 +0200
Subject: ~/.ssh/config permissions
In-Reply-To: <CAOazyz1gp6qzWav0ekwSKGDO=1Rjj2MgHBXUQHPF+xse1r6pwA@mail.gmail.com>
References: <CAOazyz1gp6qzWav0ekwSKGDO=1Rjj2MgHBXUQHPF+xse1r6pwA@mail.gmail.com>
Message-ID: <CAOazyz0RQ9oDzbr=yjdR3c7_dWKDYyTAXwcJaWC+b9bXknmsfw@mail.gmail.com>

On 15 November 2015 at 09:55, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
>
> Hi,
>
> Working with apache-sshd I found that it forces ~/.ssh/config to be
> owned by user without group/others permissions. It failed for me
> within my valid openssh environment.
>
> Within sources (readconf.c::read_config_file), I found that openssh
> only enforces ownership by user and not group/others write.
>
> When I opened an issue, I was referred to this[1] wiki page (not sure
> who maintain it) claiming that:
> """
> This file must not be accessible to other users in any way. Set strict
> permissions: read/write for the user, and not accessible by others. It
> may group-writable if and only if that user is the only member of the
> group in question.
> """
>
> Personally, I prefer the sources as a reference, but as this wiki page
> is source for information for some, and find no reason why this file
> is sensitive for read.
>
> I would like to know what is the expected behaviour.

Hi!
Anyone knows what is the expected behaviour?
Thanks!

>
> Regards,
> Alon Bar-Lev.
>
> [1] https://en.wikibooks.org/wiki/OpenSSH/Client_Configuration_Files#.7E.2F.ssh.2Fconfig

From thorduri at secnorth.net  Thu Nov 19 09:52:43 2015
From: thorduri at secnorth.net (Thordur I. Bjornsson)
Date: Wed, 18 Nov 2015 23:52:43 +0100
Subject: Missing SSHFP RRs / VerifyHostKeyDNS & StrictHostKeyChecking
Message-ID: <CAC18ACOwX+d2wue6XcxRckKw5x7p235VNGLAmVLUdo4yqG9dJA@mail.gmail.com>

Y'all,

Currently (OpenSSH_7.1p1) no distinction is made between when an SSHFP
RR is missing
from the result set (rather then being empty), which can lead to
confusing error messages,
(the "normal" warn_changed_key() blurb is emitted) e.g. when the
presented host key and
known hosts both match but there is no matching RR.

Further, if VerifyHostKeyDNS and StrictHostKeyChecking are set, there
is no prompting for
confirmation if the connection should be allowed to proceed; I'm
unsure if this is by design
or not (as presented host key and known host key match), but I'd argue
this violates POLA.

Attached are two na?ve patches to portable (cloned from
anongit at mindrot.org) that attempt
to tackle the above.

-- 
/ciao, thorduri.

From imorgan at nas.nasa.gov  Thu Nov 19 11:53:31 2015
From: imorgan at nas.nasa.gov (Iain Morgan)
Date: Wed, 18 Nov 2015 16:53:31 -0800
Subject: [PATCH] Skip RSA1 host key when using hostbased auth
In-Reply-To: <20151118055525.18812.qmail@stuge.se>
References: <20151117225047.GB9605@linux124.nas.nasa.gov>
 <20151118055525.18812.qmail@stuge.se>
Message-ID: <20151119005331.GA6834@linux124.nas.nasa.gov>

On Wed, Nov 18, 2015 at 06:55:25 +0100, Peter Stuge wrote:
> Iain Morgan wrote:
> > --- a/ssh.c
> > +++ b/ssh.c
> > @@ -1242,8 +1242,10 @@ main(int ac, char **av)
> >  			sensitive_data.keys[i] = NULL;
> >  
> >  		PRIV_START;
> > +#ifdef WITH_SSH1
> >  		sensitive_data.keys[0] = key_load_private_type(KEY_RSA1,
> >  		    _PATH_HOST_KEY_FILE, "", NULL, NULL);
> > +#endif
> >  #ifdef OPENSSL_HAS_ECC
> >  		sensitive_data.keys[1] = key_load_private_cert(KEY_ECDSA,
> 
> Wouldn't you need a counter or something, for the index?
> 

Why? A fixed size array is used for sensitive_data.keys and the elements
are initially all NULL. The code that walks through the array skips an
elements that are NULL, and (if I recall correctly) each element is set
back to NULL after the key is used.

I tested this before the original post, and it worked correctly.


-- 
Iain Morgan

From djm at mindrot.org  Thu Nov 19 13:50:01 2015
From: djm at mindrot.org (Damien Miller)
Date: Thu, 19 Nov 2015 13:50:01 +1100 (AEDT)
Subject: ~/.ssh/config permissions
In-Reply-To: <CAOazyz0RQ9oDzbr=yjdR3c7_dWKDYyTAXwcJaWC+b9bXknmsfw@mail.gmail.com>
References: <CAOazyz1gp6qzWav0ekwSKGDO=1Rjj2MgHBXUQHPF+xse1r6pwA@mail.gmail.com>
 <CAOazyz0RQ9oDzbr=yjdR3c7_dWKDYyTAXwcJaWC+b9bXknmsfw@mail.gmail.com>
Message-ID: <alpine.BSO.2.20.1511191348420.12629@natsu.mindrot.org>

As far as I'm aware, none of the developers have anything to do with
the wiki page. The man pages should describe the correct behaviour
and the source should implement it :)

On Wed, 18 Nov 2015, Alon Bar-Lev wrote:

> On 15 November 2015 at 09:55, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
> >
> > Hi,
> >
> > Working with apache-sshd I found that it forces ~/.ssh/config to be
> > owned by user without group/others permissions. It failed for me
> > within my valid openssh environment.
> >
> > Within sources (readconf.c::read_config_file), I found that openssh
> > only enforces ownership by user and not group/others write.
> >
> > When I opened an issue, I was referred to this[1] wiki page (not sure
> > who maintain it) claiming that:
> > """
> > This file must not be accessible to other users in any way. Set strict
> > permissions: read/write for the user, and not accessible by others. It
> > may group-writable if and only if that user is the only member of the
> > group in question.
> > """
> >
> > Personally, I prefer the sources as a reference, but as this wiki page
> > is source for information for some, and find no reason why this file
> > is sensitive for read.
> >
> > I would like to know what is the expected behaviour.
> 
> Hi!
> Anyone knows what is the expected behaviour?
> Thanks!
> 
> >
> > Regards,
> > Alon Bar-Lev.
> >
> > [1] https://en.wikibooks.org/wiki/OpenSSH/Client_Configuration_Files#.7E.2F.ssh.2Fconfig
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

From djm at mindrot.org  Thu Nov 19 13:50:49 2015
From: djm at mindrot.org (Damien Miller)
Date: Thu, 19 Nov 2015 13:50:49 +1100 (AEDT)
Subject: Missing SSHFP RRs / VerifyHostKeyDNS & StrictHostKeyChecking
In-Reply-To: <CAC18ACOwX+d2wue6XcxRckKw5x7p235VNGLAmVLUdo4yqG9dJA@mail.gmail.com>
References: <CAC18ACOwX+d2wue6XcxRckKw5x7p235VNGLAmVLUdo4yqG9dJA@mail.gmail.com>
Message-ID: <alpine.BSO.2.20.1511191350210.12629@natsu.mindrot.org>

On Wed, 18 Nov 2015, Thordur I. Bjornsson wrote:

> Y'all,
> 
> Currently (OpenSSH_7.1p1) no distinction is made between when an SSHFP
> RR is missing
> from the result set (rather then being empty), which can lead to
> confusing error messages,
> (the "normal" warn_changed_key() blurb is emitted) e.g. when the
> presented host key and
> known hosts both match but there is no matching RR.
> 
> Further, if VerifyHostKeyDNS and StrictHostKeyChecking are set, there
> is no prompting for
> confirmation if the connection should be allowed to proceed; I'm
> unsure if this is by design
> or not (as presented host key and known host key match), but I'd argue
> this violates POLA.
> 
> Attached are two na?ve patches to portable (cloned from
> anongit at mindrot.org) that attempt
> to tackle the above.

Looks like the list server ate the attachements - could you attach them
to a bug on https://bugzilla.mindrot.org/ ?

From alon.barlev at gmail.com  Thu Nov 19 18:37:10 2015
From: alon.barlev at gmail.com (Alon Bar-Lev)
Date: Thu, 19 Nov 2015 09:37:10 +0200
Subject: ~/.ssh/config permissions
In-Reply-To: <alpine.BSO.2.20.1511191348420.12629@natsu.mindrot.org>
References: <CAOazyz1gp6qzWav0ekwSKGDO=1Rjj2MgHBXUQHPF+xse1r6pwA@mail.gmail.com>
 <CAOazyz0RQ9oDzbr=yjdR3c7_dWKDYyTAXwcJaWC+b9bXknmsfw@mail.gmail.com>
 <alpine.BSO.2.20.1511191348420.12629@natsu.mindrot.org>
Message-ID: <CAOazyz0eKz4B5U-_57pt9OFm=vKfu9UOkPk+GK5CHSTuYFS3og@mail.gmail.com>

On 19 November 2015 at 04:50, Damien Miller <djm at mindrot.org> wrote:
> As far as I'm aware, none of the developers have anything to do with
> the wiki page. The man pages should describe the correct behaviour
> and the source should implement it :)

Thank you!

>
> On Wed, 18 Nov 2015, Alon Bar-Lev wrote:
>
>> On 15 November 2015 at 09:55, Alon Bar-Lev <alon.barlev at gmail.com> wrote:
>> >
>> > Hi,
>> >
>> > Working with apache-sshd I found that it forces ~/.ssh/config to be
>> > owned by user without group/others permissions. It failed for me
>> > within my valid openssh environment.
>> >
>> > Within sources (readconf.c::read_config_file), I found that openssh
>> > only enforces ownership by user and not group/others write.
>> >
>> > When I opened an issue, I was referred to this[1] wiki page (not sure
>> > who maintain it) claiming that:
>> > """
>> > This file must not be accessible to other users in any way. Set strict
>> > permissions: read/write for the user, and not accessible by others. It
>> > may group-writable if and only if that user is the only member of the
>> > group in question.
>> > """
>> >
>> > Personally, I prefer the sources as a reference, but as this wiki page
>> > is source for information for some, and find no reason why this file
>> > is sensitive for read.
>> >
>> > I would like to know what is the expected behaviour.
>>
>> Hi!
>> Anyone knows what is the expected behaviour?
>> Thanks!
>>
>> >
>> > Regards,
>> > Alon Bar-Lev.
>> >
>> > [1] https://en.wikibooks.org/wiki/OpenSSH/Client_Configuration_Files#.7E.2F.ssh.2Fconfig
>> _______________________________________________
>> openssh-unix-dev mailing list
>> openssh-unix-dev at mindrot.org
>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>>

From thorduri at secnorth.net  Thu Nov 19 19:12:42 2015
From: thorduri at secnorth.net (Thordur I. Bjornsson)
Date: Thu, 19 Nov 2015 09:12:42 +0100
Subject: Missing SSHFP RRs / VerifyHostKeyDNS & StrictHostKeyChecking
In-Reply-To: <alpine.BSO.2.20.1511191350210.12629@natsu.mindrot.org>
References: <CAC18ACOwX+d2wue6XcxRckKw5x7p235VNGLAmVLUdo4yqG9dJA@mail.gmail.com>
 <alpine.BSO.2.20.1511191350210.12629@natsu.mindrot.org>
Message-ID: <CAC18ACN4HivEdHT7aW8cu6bEXKy7trg10FhFL2AA62KSmTzo=A@mail.gmail.com>

On Thu, Nov 19, 2015 at 3:50 AM, Damien Miller <djm at mindrot.org> wrote:
> Looks like the list server ate the attachements - could you attach them
> to a bug on https://bugzilla.mindrot.org/ ?

Welp. My Bad.

I've created: https://bugzilla.mindrot.org/show_bug.cgi?id=2501


-- 
/ciao, thorduri.

From keisial at gmail.com  Fri Nov 20 14:11:23 2015
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Fri, 20 Nov 2015 04:11:23 +0100
Subject: How to add configuration (~/.ssh/config) per ip?
In-Reply-To: <20151118102543.GB20202@depesz.com>
References: <20151118102543.GB20202@depesz.com>
Message-ID: <564E8F5B.3080108@gmail.com>

hubert depesz lubaczewski wrote:
> Is there any way to make ssh apply rules both based on name and based on
> ip?
>
> I could, of course, add special rule for each hostname, but that would
> mean that my ~/.ssh/config will be huge, and constantly change (new
> hosts added, old hosts removed).

Remember that you can use shell commands. So, assuming from your example 
that the second IP octet determines the jump host, you could do:

Host *.bb.cc
  ProxyCommand ssh -W %h:%p jump$(dig +short %h|cut -d. -f 2).bb.cc


Best regards


From dsa at cumulusnetworks.com  Mon Nov 23 13:14:28 2015
From: dsa at cumulusnetworks.com (David Ahern)
Date: Sun, 22 Nov 2015 19:14:28 -0700
Subject: bind-to-interface option
Message-ID: <56527684.7080309@cumulusnetworks.com>

Hi:

The openssh suite of commands have an option to specify address (e.g, 
ListenAddress for sshd) but I do not see support for bind-to-interface.

The motivating use case for me is using openssh commands (sshd, ssh, 
scp, sftp) with the recent VRF capability added to the Linux kernel. The 
VRF design relies on the bind-to-interface option to select the correct 
routing tables. Before I started working on patches I wanted to get a 
sense of whether it would be accepted.

Thanks,
David

From wempwer at gmail.com  Tue Nov 24 09:25:15 2015
From: wempwer at gmail.com (john smith)
Date: Mon, 23 Nov 2015 23:25:15 +0100
Subject: Why isn't it possible to lower TCP values of running SSH session?
Message-ID: <CAKmQUfYzJNjvG0TonPV9_EQZ8TRAF6zA5W=34rtL95PVjca=Zg@mail.gmail.com>

I am running OpenSSH_6.7p1 on Slackware 14.1 x64.  I haven't modified
a stock config.  On Linux TCP timeouts are controlled by these 3
files:

$ cat /proc/sys/net/ipv4/tcp_keepalive_time \
>  /proc/sys/net/ipv4/tcp_keepalive_intvl \
> /proc/sys/net/ipv4/tcp_keepalive_probes
7200
75
9

These are their default values. I modified them to 3, 1, 1
respecitively before establishing a new SSH connection. After
establishing an SSH connection to a machine next to me I unplugged a
network cable on the remote machine and had to wait for 3 seconds for
the SSH session to be terminated by Linux. This is what I
expected. Next, I connected again and while SSH session was already
opened I changed values to their defaults - 7200, 75, 9. After
unplugging a network cable I wasn't disconnected within 3 seconds. It
made me think that it's possible to modify TCP timeouts of opened TCP
sockets such as SSH connections.  However, after connecting to the same
machine again I changed timeout values to 3, 1, 1 again. To my
surpires, after unplugging a network cable on the remote side I wasn't
disconnected within 3 seconds. It seems it's only possible to increase
TCP timeout values when SSH session is already opened but not to lower
them. Why? Is it Linux or OpenSSH thing?

-- 
<wempwer at gmail.com>

From djm at mindrot.org  Tue Nov 24 10:50:17 2015
From: djm at mindrot.org (Damien Miller)
Date: Tue, 24 Nov 2015 10:50:17 +1100 (AEDT)
Subject: bind-to-interface option
In-Reply-To: <56527684.7080309@cumulusnetworks.com>
References: <56527684.7080309@cumulusnetworks.com>
Message-ID: <alpine.BSO.2.20.1511241049510.12629@natsu.mindrot.org>

On Sun, 22 Nov 2015, David Ahern wrote:

> Hi:
> 
> The openssh suite of commands have an option to specify address (e.g,
> ListenAddress for sshd) but I do not see support for bind-to-interface.
> 
> The motivating use case for me is using openssh commands (sshd, ssh, scp,
> sftp) with the recent VRF capability added to the Linux kernel. The VRF design
> relies on the bind-to-interface option to select the correct routing tables.
> Before I started working on patches I wanted to get a sense of whether it
> would be accepted.

What's wrong with the existing BindAddress option?

From djm at mindrot.org  Tue Nov 24 10:57:58 2015
From: djm at mindrot.org (Damien Miller)
Date: Tue, 24 Nov 2015 10:57:58 +1100 (AEDT)
Subject: Why isn't it possible to lower TCP values of running SSH session?
In-Reply-To: <CAKmQUfYzJNjvG0TonPV9_EQZ8TRAF6zA5W=34rtL95PVjca=Zg@mail.gmail.com>
References: <CAKmQUfYzJNjvG0TonPV9_EQZ8TRAF6zA5W=34rtL95PVjca=Zg@mail.gmail.com>
Message-ID: <alpine.BSO.2.20.1511241055230.12629@natsu.mindrot.org>

TCP is the kernel's responsibility. I guess that these values get
copied into each TCB from the copy managed via proc at connection
start time, but never updated afterwards.

You might want to consider using protocol-level keepalives:
ServerAliveInterval/ServerAliveCountMax in ssh_config.

-d

On Mon, 23 Nov 2015, john smith wrote:

> I am running OpenSSH_6.7p1 on Slackware 14.1 x64.  I haven't modified
> a stock config.  On Linux TCP timeouts are controlled by these 3
> files:
> 
> $ cat /proc/sys/net/ipv4/tcp_keepalive_time \
> >  /proc/sys/net/ipv4/tcp_keepalive_intvl \
> > /proc/sys/net/ipv4/tcp_keepalive_probes
> 7200
> 75
> 9
> 
> These are their default values. I modified them to 3, 1, 1
> respecitively before establishing a new SSH connection. After
> establishing an SSH connection to a machine next to me I unplugged a
> network cable on the remote machine and had to wait for 3 seconds for
> the SSH session to be terminated by Linux. This is what I
> expected. Next, I connected again and while SSH session was already
> opened I changed values to their defaults - 7200, 75, 9. After
> unplugging a network cable I wasn't disconnected within 3 seconds. It
> made me think that it's possible to modify TCP timeouts of opened TCP
> sockets such as SSH connections.  However, after connecting to the same
> machine again I changed timeout values to 3, 1, 1 again. To my
> surpires, after unplugging a network cable on the remote side I wasn't
> disconnected within 3 seconds. It seems it's only possible to increase
> TCP timeout values when SSH session is already opened but not to lower
> them. Why? Is it Linux or OpenSSH thing?
> 
> -- 
> <wempwer at gmail.com>
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> 

From dsa at cumulusnetworks.com  Tue Nov 24 10:59:48 2015
From: dsa at cumulusnetworks.com (David Ahern)
Date: Mon, 23 Nov 2015 16:59:48 -0700
Subject: bind-to-interface option
In-Reply-To: <alpine.BSO.2.20.1511241049510.12629@natsu.mindrot.org>
References: <56527684.7080309@cumulusnetworks.com>
 <alpine.BSO.2.20.1511241049510.12629@natsu.mindrot.org>
Message-ID: <5653A874.2000800@cumulusnetworks.com>

On 11/23/15 4:50 PM, Damien Miller wrote:
> On Sun, 22 Nov 2015, David Ahern wrote:
>
>> Hi:
>>
>> The openssh suite of commands have an option to specify address (e.g,
>> ListenAddress for sshd) but I do not see support for bind-to-interface.
>>
>> The motivating use case for me is using openssh commands (sshd, ssh, scp,
>> sftp) with the recent VRF capability added to the Linux kernel. The VRF design
>> relies on the bind-to-interface option to select the correct routing tables.
>> Before I started working on patches I wanted to get a sense of whether it
>> would be accepted.
>
> What's wrong with the existing BindAddress option?
>

For my use case the problem is that it is an address, not a device.

The VRF implementation with Linux expects tasks to use the 
SO_BINDTODEVICE option to bind to the VRF-device. That triggers the use 
of a route table associated with the VRF domain which can encapsulate 
one or more network interfaces. Addresses are local to a VRF domain 
(e.g., 2 interfaces in 2 different VRFs can have the same IP address).

i.e., to run ssh/scp/sftp/sshd in a VRF context requires the bind to 
device option.

From wempwer at gmail.com  Tue Nov 24 11:05:35 2015
From: wempwer at gmail.com (john smith)
Date: Tue, 24 Nov 2015 01:05:35 +0100
Subject: Why isn't it possible to lower TCP values of running SSH session?
In-Reply-To: <alpine.BSO.2.20.1511241055230.12629@natsu.mindrot.org>
References: <CAKmQUfYzJNjvG0TonPV9_EQZ8TRAF6zA5W=34rtL95PVjca=Zg@mail.gmail.com>
 <alpine.BSO.2.20.1511241055230.12629@natsu.mindrot.org>
Message-ID: <CAKmQUfZGYbhUg_JpxjRSyjo4J4gzfN=jgTR=UxY5nXm2UA2a1w@mail.gmail.com>

On Tue, Nov 24, 2015 at 12:57 AM, Damien Miller <djm at mindrot.org> wrote:
> TCP is the kernel's responsibility. I guess that these values get
> copied into each TCB from the copy managed via proc at connection
> start time, but never updated afterwards.
>

This had to happen but the question is why is it possible to increase
a timeout but not to decrease it.

-- 
<wempwer at gmail.com>

From wempwer at gmail.com  Tue Nov 24 11:34:45 2015
From: wempwer at gmail.com (john smith)
Date: Tue, 24 Nov 2015 01:34:45 +0100
Subject: Why isn't it possible to lower TCP values of running SSH session?
In-Reply-To: <CAKmQUfZGYbhUg_JpxjRSyjo4J4gzfN=jgTR=UxY5nXm2UA2a1w@mail.gmail.com>
References: <CAKmQUfYzJNjvG0TonPV9_EQZ8TRAF6zA5W=34rtL95PVjca=Zg@mail.gmail.com>
 <alpine.BSO.2.20.1511241055230.12629@natsu.mindrot.org>
 <CAKmQUfZGYbhUg_JpxjRSyjo4J4gzfN=jgTR=UxY5nXm2UA2a1w@mail.gmail.com>
Message-ID: <CAKmQUfYJPJoFGuYmS_2Kzwip7=pyndH38u+fttqJ3RSLE7TZ3w@mail.gmail.com>

On Tue, Nov 24, 2015 at 1:05 AM, john smith <wempwer at gmail.com> wrote:
> On Tue, Nov 24, 2015 at 12:57 AM, Damien Miller <djm at mindrot.org> wrote:
>> TCP is the kernel's responsibility. I guess that these values get
>> copied into each TCB from the copy managed via proc at connection
>> start time, but never updated afterwards.
>>
>
> This had to happen but the question is why is it possible to increase
> a timeout but not to decrease it.

Well I just did an iteresting test. If I set timeout values to 10, 1,
1, connect to remote, change timeout values to 3, 1, 1 and wait for 10
seconds inside SSH session, then unplug a network cable on the remote
it only takes 3 seconds to close an expired session. I also tried to
set timeout values to 60, 1, 1, connect to remote, change timeout
values to 3, 1, 1, wait for 60 seconds, unplug the cable and again it
only took 3 seconds to close a frozen session. I think it has
something to do with the following piece of code inside Linux kernel:

/linux/kernel/time/timer.c

    if (timer_pending(timer) && timer->expires == expires)
        return 1;

    return __mod_timer(timer, expires, false, TIMER_NOT_PINNED);

I think that after changing 7200 to 3 I would also be automatically
disconnected after 3 seconds but only after first 7200 seconds of
active session. However, I would be glad if someone more experienced
could confirm my assumptions (I am sure there are such people here).
-- 
<wempwer at gmail.com>

From alex at alex.org.uk  Tue Nov 24 17:52:46 2015
From: alex at alex.org.uk (Alex Bligh)
Date: Tue, 24 Nov 2015 06:52:46 +0000
Subject: bind-to-interface option
In-Reply-To: <5653A874.2000800@cumulusnetworks.com>
References: <56527684.7080309@cumulusnetworks.com>
 <alpine.BSO.2.20.1511241049510.12629@natsu.mindrot.org>
 <5653A874.2000800@cumulusnetworks.com>
Message-ID: <E312D430-B479-4AE3-9003-FFB951A7C8C7@alex.org.uk>


On 23 Nov 2015, at 23:59, David Ahern <dsa at cumulusnetworks.com> wrote:

>> What's wrong with the existing BindAddress option?
>> 
> 
> For my use case the problem is that it is an address, not a device.
> 
> The VRF implementation with Linux expects tasks to use the SO_BINDTODEVICE option to bind to the VRF-device. That triggers the use of a route table associated with the VRF domain which can encapsulate one or more network interfaces. Addresses are local to a VRF domain (e.g., 2 interfaces in 2 different VRFs can have the same IP address).
> 
> i.e., to run ssh/scp/sftp/sshd in a VRF context requires the bind to device option.

Just to add a little more colour to this, I believe the reason that SO_BINDTODEVICE is necessary rather than binding to the address is that in a VRF environment the same address may be present on multiple interfaces. Therefore, address cannot be used in order to select the VRF. However, the VRF can be uniquely determined from the interface.

-- 
Alex Bligh





From sfandino at gmail.com  Tue Nov 24 18:57:30 2015
From: sfandino at gmail.com (Salvador Fandino)
Date: Tue, 24 Nov 2015 08:57:30 +0100
Subject: Why isn't it possible to lower TCP values of running SSH session?
In-Reply-To: <CAKmQUfZGYbhUg_JpxjRSyjo4J4gzfN=jgTR=UxY5nXm2UA2a1w@mail.gmail.com>
References: <CAKmQUfYzJNjvG0TonPV9_EQZ8TRAF6zA5W=34rtL95PVjca=Zg@mail.gmail.com>
 <alpine.BSO.2.20.1511241055230.12629@natsu.mindrot.org>
 <CAKmQUfZGYbhUg_JpxjRSyjo4J4gzfN=jgTR=UxY5nXm2UA2a1w@mail.gmail.com>
Message-ID: <5654186A.7070407@gmail.com>

On 11/24/2015 01:05 AM, john smith wrote:
> On Tue, Nov 24, 2015 at 12:57 AM, Damien Miller <djm at mindrot.org> wrote:
>> TCP is the kernel's responsibility. I guess that these values get
>> copied into each TCB from the copy managed via proc at connection
>> start time, but never updated afterwards.
>>
>
> This had to happen but the question is why is it possible to increase
> a timeout but not to decrease it.

Some years ago I found that the implementation of TCP keepalive on Linux 
is not reliable.

Inside the kernel, the code that does the keep-alive thing is not called 
unless the output socket buffer is empty, otherwise the regular handling 
for the TCP output stream that just retries sending the queued data with 
increasing (IIRC, x2) delays is applied and it uses a different set of 
counters and timeouts that are not affected by the tcp_keepalive_* 
parameters.

That bug is probably still there.





From peter at stuge.se  Tue Nov 24 20:22:33 2015
From: peter at stuge.se (Peter Stuge)
Date: Tue, 24 Nov 2015 10:22:33 +0100
Subject: Why isn't it possible to lower TCP values of running SSH session?
In-Reply-To: <5654186A.7070407@gmail.com>
References: <CAKmQUfYzJNjvG0TonPV9_EQZ8TRAF6zA5W=34rtL95PVjca=Zg@mail.gmail.com>
 <alpine.BSO.2.20.1511241055230.12629@natsu.mindrot.org>
 <CAKmQUfZGYbhUg_JpxjRSyjo4J4gzfN=jgTR=UxY5nXm2UA2a1w@mail.gmail.com>
 <5654186A.7070407@gmail.com>
Message-ID: <20151124092233.22106.qmail@stuge.se>

Salvador Fandino wrote:
> Some years ago I found that the implementation of TCP keepalive on Linux
> is not reliable.
..
> That bug is probably still there.

Did you file a report at bugzilla.kernel.org?


//Peter

From sfandino at gmail.com  Wed Nov 25 00:34:56 2015
From: sfandino at gmail.com (Salvador Fandino)
Date: Tue, 24 Nov 2015 14:34:56 +0100
Subject: Why isn't it possible to lower TCP values of running SSH session?
In-Reply-To: <20151124092233.22106.qmail@stuge.se>
References: <CAKmQUfYzJNjvG0TonPV9_EQZ8TRAF6zA5W=34rtL95PVjca=Zg@mail.gmail.com>
 <alpine.BSO.2.20.1511241055230.12629@natsu.mindrot.org>
 <CAKmQUfZGYbhUg_JpxjRSyjo4J4gzfN=jgTR=UxY5nXm2UA2a1w@mail.gmail.com>
 <5654186A.7070407@gmail.com> <20151124092233.22106.qmail@stuge.se>
Message-ID: <56546780.5090108@gmail.com>

On 11/24/2015 10:22 AM, Peter Stuge wrote:
> Salvador Fandino wrote:
>> Some years ago I found that the implementation of TCP keepalive on Linux
>> is not reliable.
> ..
>> That bug is probably still there.
>
> Did you file a report at bugzilla.kernel.org?

I discussed the issue on the Linux networking mailing list but I went 
nowhere.

From the2nd at otpme.org  Wed Nov 25 03:21:45 2015
From: the2nd at otpme.org (the2nd at otpme.org)
Date: Tue, 24 Nov 2015 17:21:45 +0100
Subject: Problem with gpg-agent and yubikey since openssh v6.8p1
Message-ID: <2b0080a5d20b7f906082b534279fb197@otpme.org>

Hi,

i'm unsure if the problem we encounter is a bug in openssh or in gnupg. 
But as everything was working with openssh 6.7p1 and earlier i guess 
that there where at least some changes in openssh that leads to the 
problem.

You can read the latest discussion about the problem here:

https://www.mail-archive.com/gnupg-users%40gnupg.org/msg29421.html
https://www.mail-archive.com/gnupg-users at gnupg.org/msg28416.html

I hope to get some help on this list as its an very annoying problem and 
using an old openssh version is just a bad workaround.

If you need any more information or help debugging i'm glad to help.

regards
the2nd

From dsa at cumulusnetworks.com  Wed Nov 25 03:27:33 2015
From: dsa at cumulusnetworks.com (David Ahern)
Date: Tue, 24 Nov 2015 09:27:33 -0700
Subject: bind-to-interface option
In-Reply-To: <E312D430-B479-4AE3-9003-FFB951A7C8C7@alex.org.uk>
References: <56527684.7080309@cumulusnetworks.com>
 <alpine.BSO.2.20.1511241049510.12629@natsu.mindrot.org>
 <5653A874.2000800@cumulusnetworks.com>
 <E312D430-B479-4AE3-9003-FFB951A7C8C7@alex.org.uk>
Message-ID: <56548FF5.2090905@cumulusnetworks.com>

On 11/23/15 11:52 PM, Alex Bligh wrote:
>
> On 23 Nov 2015, at 23:59, David Ahern <dsa at cumulusnetworks.com> wrote:
>
>>> What's wrong with the existing BindAddress option?
>>>
>>
>> For my use case the problem is that it is an address, not a device.
>>
>> The VRF implementation with Linux expects tasks to use the SO_BINDTODEVICE option to bind to the VRF-device. That triggers the use of a route table associated with the VRF domain which can encapsulate one or more network interfaces. Addresses are local to a VRF domain (e.g., 2 interfaces in 2 different VRFs can have the same IP address).
>>
>> i.e., to run ssh/scp/sftp/sshd in a VRF context requires the bind to device option.
>
> Just to add a little more colour to this, I believe the reason that SO_BINDTODEVICE is necessary rather than binding to the address is that in a VRF environment the same address may be present on multiple interfaces. Therefore, address cannot be used in order to select the VRF. However, the VRF can be uniquely determined from the interface.

Yes, but routing is broken as well. ie., you can bind to the address, 
but the connection will not work because the lookups are not directed to 
the proper table without the bind-to-device set.

For example

             +------+
             | task |
             +------+

                             +---------+
            +---------+      |  route  |
            |   vrf   |  ==> | table N |
            +---------+      +---------+
           /     |     \
          /      |      \
   +------+  +------+  +------+
   | dev1 |  | dev2 |  | dev3 |
   +------+  +------+  +------+
   a.b.c.d    e.f.g.h   j.k.l.m

If some task bound to the one of the addresses without binding to the 
VRF device the connection will not work -- the route lookups go to the 
main table, not the table associated with the VRF.

So, it is both addresses possibly being non-unique across VRFs but also 
the route lookups needed to make the connection.

David

From radek at podgorny.cz  Wed Nov 25 04:57:56 2015
From: radek at podgorny.cz (Radek Podgorny)
Date: Tue, 24 Nov 2015 18:57:56 +0100
Subject: ssh-copy-id bugfix
Message-ID: <5654A524.7090301@podgorny.cz>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hello everyone!

i'd like to sincerely ask you to include a fix for ssh-copy-id bug
i'll be linking below. it's a trivial fix which resolves
https://bugzilla.mindrot.org/show_bug.cgi?id=2206 and eases life of
many. it's been field-tested by redhat devs and users so i see no
problem in incorporating it.

http://pkgs.fedoraproject.org/cgit/openssh.git/tree/openssh-6.8p1-fix-ss
h-copy-id-on-non-sh-shell.patch

thanks a lot!
R.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlZUpSIACgkQ7mej6pjlbYQ5EgCfV4+MBrLPgW0HpDhdz0zGBMrb
R5QAn1c/aU4PFDgNkO+9gJHxMWZoc2dK
=s5/e
-----END PGP SIGNATURE-----

From sweet_f_a at gmx.de  Wed Nov 25 22:07:13 2015
From: sweet_f_a at gmx.de (Ruediger Meier)
Date: Wed, 25 Nov 2015 12:07:13 +0100
Subject: ssh-copy-id bugfix
In-Reply-To: <5654A524.7090301@podgorny.cz>
References: <5654A524.7090301@podgorny.cz>
Message-ID: <201511251207.14945.sweet_f_a@gmx.de>

Hi,

On Tuesday 24 November 2015, Radek Podgorny wrote:
> hello everyone!
>
> i'd like to sincerely ask you to include a fix for ssh-copy-id bug
> i'll be linking below. it's a trivial fix which resolves
> https://bugzilla.mindrot.org/show_bug.cgi?id=2206 and eases life of
> many. it's been field-tested by redhat devs and users so i see no
> problem in incorporating it.
>
> http://pkgs.fedoraproject.org/cgit/openssh.git/tree/openssh-6.8p1-fix
>-ss h-copy-id-on-non-sh-shell.patch


>> - umask 077 ;
>> + exec sh -c 'umask 077; mkdir -p .ssh && cat >> .ssh/authorized_keys || exit 1; if type restorecon >/dev/null 2>&1; then restorecon -F .ssh .ssh/authorized_keys; fi'" \
>> - mkdir -p .ssh && cat >> .ssh/authorized_keys || exit 1 ;
>> - if type restorecon >/dev/null 2>&1 ; then restorecon -F .ssh .ssh/authorized_keys ; fi" \

Does "exec sh -c ..." really make sense in general? People who are
using non-posix login shells where not even "2>&1" or "&&" works are
probably good candidates who would also link /bin/sh to point to a
non-posix shell.

Personally I think it's hard enough to write POSIX compatible shell
scripts and I wouldn't start to add such hacks for fish and tcsh.
Next week somebody may complain that his "shell" does not
support "exec ...". 


cu,
Rudi

From radek at podgorny.cz  Wed Nov 25 22:43:04 2015
From: radek at podgorny.cz (Radek Podgorny)
Date: Wed, 25 Nov 2015 12:43:04 +0100
Subject: ssh-copy-id bugfix
In-Reply-To: <201511251207.14945.sweet_f_a@gmx.de>
References: <5654A524.7090301@podgorny.cz>
 <201511251207.14945.sweet_f_a@gmx.de>
Message-ID: <56559EC8.3050501@podgorny.cz>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

hi,

On 11/25/2015 12:07 PM, Ruediger Meier wrote:
> Hi,
> 
> On Tuesday 24 November 2015, Radek Podgorny wrote:
>> hello everyone!
>> 
>> i'd like to sincerely ask you to include a fix for ssh-copy-id
>> bug i'll be linking below. it's a trivial fix which resolves 
>> https://bugzilla.mindrot.org/show_bug.cgi?id=2206 and eases life
>> of many. it's been field-tested by redhat devs and users so i see
>> no problem in incorporating it.
>> 
>> http://pkgs.fedoraproject.org/cgit/openssh.git/tree/openssh-6.8p1-fix
>>
>> 
- -ss h-copy-id-on-non-sh-shell.patch
> 
> 
>>> - umask 077 ; + exec sh -c 'umask 077; mkdir -p .ssh && cat >>
>>> .ssh/authorized_keys || exit 1; if type restorecon >/dev/null
>>> 2>&1; then restorecon -F .ssh .ssh/authorized_keys; fi'" \ -
>>> mkdir -p .ssh && cat >> .ssh/authorized_keys || exit 1 ; - if
>>> type restorecon >/dev/null 2>&1 ; then restorecon -F .ssh
>>> .ssh/authorized_keys ; fi" \
> 
> Does "exec sh -c ..." really make sense in general? People who are 
> using non-posix login shells where not even "2>&1" or "&&" works
> are probably good candidates who would also link /bin/sh to point
> to a non-posix shell.
> 
> Personally I think it's hard enough to write POSIX compatible
> shell scripts and I wouldn't start to add such hacks for fish and
> tcsh. Next week somebody may complain that his "shell" does not 
> support "exec ...".

i wouldn't be afraid of that. i think it's a common practice (no hard
numbers for that, thou) that you leave the sh link pointed to posix
shell at all times - there's too many things in the wild depending on
that.

anyway, i wouldn't call it a hack. you need a posix shell on the
remote side and this so far the best method to state it. of course,
someone may have a relly odd shell with no exec support or have the sh
link pointing elsewhere but for such poor guy, the ssh-copy-id is not
working today, anyway, so no real "breakage" happens. on the other
hand, there's many people who would benefit from this patch and as
it's backwards compatible, nothing gets broken for anyone.

if - and that may never happen - in the future someone complains about
his shell not being supported, let's find a better way. but until then
i think this is a safe thing to do.

thanks,
R.

> cu, Rudi
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlZVnsQACgkQ7mej6pjlbYQavACeJEeA9swKxO8bzc6B+uCqLntH
CNAAoKh5r/n2BrkeefN2H7cBc51FyiJk
=f/zb
-----END PGP SIGNATURE-----

From nkadel at gmail.com  Wed Nov 25 23:24:36 2015
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Wed, 25 Nov 2015 07:24:36 -0500
Subject: ssh-copy-id bugfix
In-Reply-To: <201511251207.14945.sweet_f_a@gmx.de>
References: <5654A524.7090301@podgorny.cz>
 <201511251207.14945.sweet_f_a@gmx.de>
Message-ID: <CAOCN9ryjJYL6tCYmw2L84MRYk-rzxe6QWDEcYYx8EFLW8rDysg@mail.gmail.com>

On Wed, Nov 25, 2015 at 6:07 AM, Ruediger Meier <sweet_f_a at gmx.de> wrote:
> Hi,
>
> On Tuesday 24 November 2015, Radek Podgorny wrote:
>> hello everyone!
>>
>> i'd like to sincerely ask you to include a fix for ssh-copy-id bug
>> i'll be linking below. it's a trivial fix which resolves
>> https://bugzilla.mindrot.org/show_bug.cgi?id=2206 and eases life of
>> many. it's been field-tested by redhat devs and users so i see no
>> problem in incorporating it.
>>
>> http://pkgs.fedoraproject.org/cgit/openssh.git/tree/openssh-6.8p1-fix
>>-ss h-copy-id-on-non-sh-shell.patch

> Personally I think it's hard enough to write POSIX compatible shell
> scripts and I wouldn't start to add such hacks for fish and tcsh.
> Next week somebody may complain that his "shell" does not
> support "exec ...".

Making things work for more people, when it doesn't introduce a
security risk or break other tools, seems very reasonable. And there
are people out there who who do use both fish and tcsh.

What seems to be missing in the patch is a comment line, above the
stanza, explaining why the code uses "exec". It's great to be clever
and solve a problem, but it boosts your pay and makes people who
follow in your role hate you a lot less if they can understand why you
chose a particular solution.

From mstone at mathom.us  Wed Nov 25 23:22:01 2015
From: mstone at mathom.us (Michael Stone)
Date: Wed, 25 Nov 2015 07:22:01 -0500
Subject: ssh-copy-id bugfix
In-Reply-To: <201511251207.14945.sweet_f_a@gmx.de>
References: <5654A524.7090301@podgorny.cz>
 <201511251207.14945.sweet_f_a@gmx.de>
Message-ID: <f72f41cc-936e-11e5-9b6a-00163eeb5320@msgid.mathom.us>

On Wed, Nov 25, 2015 at 12:07:13PM +0100, Ruediger Meier wrote:
>Does "exec sh -c ..." really make sense in general? People who are
>using non-posix login shells where not even "2>&1" or "&&" works are
>probably good candidates who would also link /bin/sh to point to a
>non-posix shell.

Non-posix login shells (csh et al) are not exactly uncommon. /bin/sh 
pointing to something non-posix is uncommon to the point of being unable 
to work on common systems.

Mike Stone

From nkadel at gmail.com  Wed Nov 25 23:47:09 2015
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Wed, 25 Nov 2015 07:47:09 -0500
Subject: ssh-copy-id bugfix
In-Reply-To: <f72f41cc-936e-11e5-9b6a-00163eeb5320@msgid.mathom.us>
References: <5654A524.7090301@podgorny.cz>
 <201511251207.14945.sweet_f_a@gmx.de>
 <f72f41cc-936e-11e5-9b6a-00163eeb5320@msgid.mathom.us>
Message-ID: <CAOCN9rxt461A06hztDN6CZ4KT2_1XZyhnyT_3=Qi9KereWoxMg@mail.gmail.com>

On Wed, Nov 25, 2015 at 7:22 AM, Michael Stone <mstone at mathom.us> wrote:
> On Wed, Nov 25, 2015 at 12:07:13PM +0100, Ruediger Meier wrote:
>>
>> Does "exec sh -c ..." really make sense in general? People who are
>> using non-posix login shells where not even "2>&1" or "&&" works are
>> probably good candidates who would also link /bin/sh to point to a
>> non-posix shell.
>
>
> Non-posix login shells (csh et al) are not exactly uncommon. /bin/sh
> pointing to something non-posix is uncommon to the point of being unable to
> work on common systems.

Has anyone tried this one with Ubuntu, which uses a symlink from
/bin/sh to /bin/dash?

From jjelen at redhat.com  Thu Nov 26 02:04:28 2015
From: jjelen at redhat.com (Jakub Jelen)
Date: Wed, 25 Nov 2015 16:04:28 +0100
Subject: ssh-copy-id bugfix
In-Reply-To: <CAOCN9ryjJYL6tCYmw2L84MRYk-rzxe6QWDEcYYx8EFLW8rDysg@mail.gmail.com>
References: <5654A524.7090301@podgorny.cz>
 <201511251207.14945.sweet_f_a@gmx.de>
 <CAOCN9ryjJYL6tCYmw2L84MRYk-rzxe6QWDEcYYx8EFLW8rDysg@mail.gmail.com>
Message-ID: <5655CDFC.4060903@redhat.com>

On 11/25/2015 01:24 PM, Nico Kadel-Garcia wrote:
> On Wed, Nov 25, 2015 at 6:07 AM, Ruediger Meier <sweet_f_a at gmx.de> wrote:
>> Personally I think it's hard enough to write POSIX compatible shell
>> scripts and I wouldn't start to add such hacks for fish and tcsh.
>> Next week somebody may complain that his "shell" does not
>> support "exec ...".
> Making things work for more people, when it doesn't introduce a
> security risk or break other tools, seems very reasonable. And there
> are people out there who who do use both fish and tcsh.
>
> What seems to be missing in the patch is a comment line, above the
> stanza, explaining why the code uses "exec". It's great to be clever
> and solve a problem, but it boosts your pay and makes people who
> follow in your role hate you a lot less if they can understand why you
> chose a particular solution.
Currently, it is the only solution we have and works for conventional 
shells as well as for fish and tcsh. Maybe there are other solutions, 
better or worse. I am no expert on different shells and their 
compatibility, so I just shared what we actually use across our systems 
for some time and which works for us, so other interested can benefit 
from it. I am not forcing anyone to use it.

I completely agree that there should be some wider reasoning behind 
every change. But here we have just "experience" with larger subset of 
shells used these days.

Regards,

-- 
Jakub Jelen
Associate Software Engineer
Security Technologies
Red Hat


From tinkr at openmailbox.org  Thu Nov 26 02:59:14 2015
From: tinkr at openmailbox.org (Tinker)
Date: Wed, 25 Nov 2015 23:59:14 +0800
Subject: How disable forwarding-only connections (i.e. non-shell/command
 non-sftp =?UTF-8?Q?connections=29=3F=20=28Maybe=20this=20is=20a=20feature?=
 =?UTF-8?Q?=20request!=29?=
Message-ID: <203f46ea78bb7ce594c33b90a93cd1e6@openmailbox.org>

Hi!

I tried with all available options to disable forwarding-only 
connections, by:

"AllowAgentForwarding no
AllowTcpForwarding no"

This had no effect, so what I got in effect was dummy connections.

I would like to disable this "class" of connections altogether. The 
outcome will be that all authenticated connections will lead to a 
command, be it /usr/libexec/sftp-server or other.

So something like "ForwardingOnlyConnections on/off".

Would you be interested in adding this to your next release?

Thanks!


From leres at ee.lbl.gov  Thu Nov 26 04:00:10 2015
From: leres at ee.lbl.gov (Craig Leres)
Date: Wed, 25 Nov 2015 09:00:10 -0800
Subject: [PATCH] OpenSSH_7.1p1: ssh-keygen -R leaks a temp file if there is no
 known_hosts file
Message-ID: <5655E91A.3070706@ee.lbl.gov>

For example:

    $ ls ~/.ssh/known_hosts.*
    ls: /home/fun/u0/leres/.ssh/known_hosts.*: No such file or directory
    $ ssh-keygen -R `hostname`
    do_known_hosts: hostkeys_foreach failed: No such file or directory
    $ ls ~/.ssh/known_hosts.*
    /home/fun/u0/leres/.ssh/known_hosts.TZJ7CQ0iiH

The attached patch corrects this.

		Craig
-------------- next part --------------
--- ssh-keygen.c.orig	2015-11-25 08:14:19.000000000 -0800
+++ ssh-keygen.c	2015-11-25 08:22:07.000000000 -0800
@@ -1185,8 +1185,11 @@
 	foreach_options |= print_fingerprint ? HKF_WANT_PARSE_KEY : 0;
 	if ((r = hostkeys_foreach(identity_file,
 	    hash_hosts ? known_hosts_hash : known_hosts_find_delete, &ctx,
-	    name, NULL, foreach_options)) != 0)
+	    name, NULL, foreach_options)) != 0) {
+		if (inplace)
+			unlink(tmp);
 		fatal("%s: hostkeys_foreach failed: %s", __func__, ssh_err(r));
+	}
 
 	if (inplace)
 		fclose(ctx.out);

From phil at hands.com  Thu Nov 26 04:11:37 2015
From: phil at hands.com (Philip Hands)
Date: Wed, 25 Nov 2015 18:11:37 +0100
Subject: ssh-copy-id bugfix
In-Reply-To: <5654A524.7090301@podgorny.cz>
References: <5654A524.7090301@podgorny.cz>
Message-ID: <87lh9m6m2e.fsf@whist.hands.com>

Hi Radek,

Radek Podgorny <radek at podgorny.cz> writes:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> hello everyone!
>
> i'd like to sincerely ask you to include a fix for ssh-copy-id bug
> i'll be linking below. it's a trivial fix which resolves
> https://bugzilla.mindrot.org/show_bug.cgi?id=2206 and eases life of
> many. it's been field-tested by redhat devs and users so i see no
> problem in incorporating it.
>
> http://pkgs.fedoraproject.org/cgit/openssh.git/tree/openssh-6.8p1-fix-ss
> h-copy-id-on-non-sh-shell.patch

Seems fair enough to me.

I've been meaning to do some maintenance on ssh-copy-id for quite a
while, so thanks for the nudge -- that's what parenthood does for
available spare time ;-)

BTW I've just pushed this fix to my git repo:

  http://git.hands.com/ssh-copy-id

hopefully that can be in the next OpenSSH release -- I'll endeavour to
deal with some of the rest of the bug backlog in the next day or two.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20151125/867daa4b/attachment-0001.bin>

From phil at hands.com  Thu Nov 26 04:20:46 2015
From: phil at hands.com (Philip Hands)
Date: Wed, 25 Nov 2015 18:20:46 +0100
Subject: ssh-copy-id bugfix
In-Reply-To: <CAOCN9ryjJYL6tCYmw2L84MRYk-rzxe6QWDEcYYx8EFLW8rDysg@mail.gmail.com>
References: <5654A524.7090301@podgorny.cz>
 <201511251207.14945.sweet_f_a@gmx.de>
 <CAOCN9ryjJYL6tCYmw2L84MRYk-rzxe6QWDEcYYx8EFLW8rDysg@mail.gmail.com>
Message-ID: <87io4q6ln5.fsf@whist.hands.com>

Nico Kadel-Garcia <nkadel at gmail.com> writes:

> On Wed, Nov 25, 2015 at 6:07 AM, Ruediger Meier <sweet_f_a at gmx.de> wrote:
>> Hi,
>>
>> On Tuesday 24 November 2015, Radek Podgorny wrote:
>>> hello everyone!
>>>
>>> i'd like to sincerely ask you to include a fix for ssh-copy-id bug
>>> i'll be linking below. it's a trivial fix which resolves
>>> https://bugzilla.mindrot.org/show_bug.cgi?id=2206 and eases life of
>>> many. it's been field-tested by redhat devs and users so i see no
>>> problem in incorporating it.
>>>
>>> http://pkgs.fedoraproject.org/cgit/openssh.git/tree/openssh-6.8p1-fix
>>>-ss h-copy-id-on-non-sh-shell.patch
>
>> Personally I think it's hard enough to write POSIX compatible shell
>> scripts and I wouldn't start to add such hacks for fish and tcsh.
>> Next week somebody may complain that his "shell" does not
>> support "exec ...".
>
> Making things work for more people, when it doesn't introduce a
> security risk or break other tools, seems very reasonable. And there
> are people out there who who do use both fish and tcsh.
>
> What seems to be missing in the patch is a comment line, above the
> stanza, explaining why the code uses "exec".

My reading of the presence of "exec" there was:

  We're assuming that the current shell may not be to our liking, so
  there seems to be little point keeping it in memory solely so it can
  at worst somehow get in the way of a clean exit.

Does that really need a comment?  I'm not sure I can make a succinct
explanation of what's going on for anyone that doesn't already know what
exec does.  Feel free to make suggestions though.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20151125/02ab5b45/attachment.bin>

From alex at cooperi.net  Thu Nov 26 05:25:49 2015
From: alex at cooperi.net (Alex Wilson)
Date: Wed, 25 Nov 2015 10:25:49 -0800
Subject: [PATCH] Drop fine-grained privileges on Illumos/Solaris
In-Reply-To: <564645F3.5050208@cooperi.net>
References: <56453640.5060202@cooperi.net>
 <CALDDTe2qHLOzT92shkM4B+gvc0c03_zcRoC=UhfV8pd2t8k+yQ@mail.gmail.com>
 <564645F3.5050208@cooperi.net>
Message-ID: <5655FD2D.8020208@cooperi.net>

On 11/13/15 12:20 PM, Alex Wilson wrote:
> Does this look a bit better? 
>

Did anyone have any more comments/concerns on this patch after my last
revision? Just wondering how to proceed from here or what the usual way
forward is. Do I need to file a bug on bugzilla.mindrot.org for it?

Sorry to make noise on the list about it -- I did look around on the
site for advice on how to send in patches but it only seems to offer
advice about reporting bugs (I guess this could be a kind of bug?)

Thanks!

From peter at stuge.se  Thu Nov 26 08:25:39 2015
From: peter at stuge.se (Peter Stuge)
Date: Wed, 25 Nov 2015 22:25:39 +0100
Subject: [PATCH] Drop fine-grained privileges on Illumos/Solaris
In-Reply-To: <5655FD2D.8020208@cooperi.net>
References: <56453640.5060202@cooperi.net>
 <CALDDTe2qHLOzT92shkM4B+gvc0c03_zcRoC=UhfV8pd2t8k+yQ@mail.gmail.com>
 <564645F3.5050208@cooperi.net> <5655FD2D.8020208@cooperi.net>
Message-ID: <20151125212539.1339.qmail@stuge.se>

Alex Wilson wrote:
> Did anyone have any more comments/concerns on this patch after my last
> revision? Just wondering how to proceed from here or what the usual way
> forward is. Do I need to file a bug on bugzilla.mindrot.org for it?

Enhancement requests with patches can certainly go into bugzilla,
that way they will not get forgotten, and eventually someone will
take a closer look.


//Peter

From keisial at gmail.com  Thu Nov 26 08:39:57 2015
From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=)
Date: Wed, 25 Nov 2015 22:39:57 +0100
Subject: How disable forwarding-only connections (i.e. non-shell/command
 non-sftp connections)? (Maybe this is a feature request!)
In-Reply-To: <203f46ea78bb7ce594c33b90a93cd1e6@openmailbox.org>
References: <203f46ea78bb7ce594c33b90a93cd1e6@openmailbox.org>
Message-ID: <56562AAD.6040504@gmail.com>

On 25/11/15 16:59, Tinker wrote:
> Hi!
>
> I tried with all available options to disable forwarding-only 
> connections, by:
>
> "AllowAgentForwarding no
> AllowTcpForwarding no"
>
> This had no effect, so what I got in effect was dummy connections.
>
> I would like to disable this "class" of connections altogether. The 
> outcome will be that all authenticated connections will lead to a 
> command, be it /usr/libexec/sftp-server or other.
>
> So something like "ForwardingOnlyConnections on/off".
>
> Would you be interested in adding this to your next release?
>
> Thanks!
I don't think the ssh protocols allows that. You first authenticate, and 
only then you create the different channels. Also, it would be possible 
to create a pty channel, then a forwarding, then close the first channel.
Do you want to allow forwardings for "command connections"?



From tinkr at openmailbox.org  Thu Nov 26 09:16:25 2015
From: tinkr at openmailbox.org (Tinker)
Date: Thu, 26 Nov 2015 06:16:25 +0800
Subject: How disable forwarding-only connections (i.e. non-shell/command
 non-sftp =?UTF-8?Q?connections=29=3F=20=28Maybe=20this=20is=20a=20feature?=
 =?UTF-8?Q?=20request!=29?=
In-Reply-To: <56562AAD.6040504@gmail.com>
References: <203f46ea78bb7ce594c33b90a93cd1e6@openmailbox.org>
 <56562AAD.6040504@gmail.com>
Message-ID: <ba3a9131c0ea151946782e26d9e6184c@openmailbox.org>

On 2015-11-26 05:39, ?ngel Gonz?lez wrote:
> On 25/11/15 16:59, Tinker wrote:
>> Hi!
>> 
>> I tried with all available options to disable forwarding-only 
>> connections, by:
>> 
>> "AllowAgentForwarding no
>> AllowTcpForwarding no"
>> 
>> This had no effect, so what I got in effect was dummy connections.
>> 
>> I would like to disable this "class" of connections altogether. The 
>> outcome will be that all authenticated connections will lead to a 
>> command, be it /usr/libexec/sftp-server or other.
>> 
>> So something like "ForwardingOnlyConnections on/off".
>> 
>> Would you be interested in adding this to your next release?
>> 
>> Thanks!
> I don't think the ssh protocols allows that. You first authenticate,
> and only then you create the different channels. Also, it would be
> possible to create a pty channel, then a forwarding, then close the
> first channel.
> Do you want to allow forwardings for "command connections"?

Angel,

Yes - actually my whole problem is that ForceCommand is invoked for 
*all* SSH connections, *except* for the forwarding-only connections.

Maybe another solution would be to add an option so that ForceCommand 
always is run, e.g. for /bin/noop on all non-SFTP non-shell non-command 
connections.

Thanks!


From tinkr at openmailbox.org  Thu Nov 26 09:16:56 2015
From: tinkr at openmailbox.org (Tinker)
Date: Thu, 26 Nov 2015 06:16:56 +0800
Subject: How disable forwarding-only connections (i.e. non-shell/command
 non-sftp =?UTF-8?Q?connections=29=3F=20=28Maybe=20this=20is=20a=20feature?=
 =?UTF-8?Q?=20request!=29?=
In-Reply-To: <ba3a9131c0ea151946782e26d9e6184c@openmailbox.org>
References: <203f46ea78bb7ce594c33b90a93cd1e6@openmailbox.org>
 <56562AAD.6040504@gmail.com>
 <ba3a9131c0ea151946782e26d9e6184c@openmailbox.org>
Message-ID: <419d0428c83008e4c6c73bf163574f4e@openmailbox.org>

On 2015-11-26 06:16, Tinker wrote:
> On 2015-11-26 05:39, ?ngel Gonz?lez wrote:
>> On 25/11/15 16:59, Tinker wrote:
>>> Hi!
>>> 
>>> I tried with all available options to disable forwarding-only 
>>> connections, by:
>>> 
>>> "AllowAgentForwarding no
>>> AllowTcpForwarding no"
>>> 
>>> This had no effect, so what I got in effect was dummy connections.
>>> 
>>> I would like to disable this "class" of connections altogether. The 
>>> outcome will be that all authenticated connections will lead to a 
>>> command, be it /usr/libexec/sftp-server or other.
>>> 
>>> So something like "ForwardingOnlyConnections on/off".
>>> 
>>> Would you be interested in adding this to your next release?
>>> 
>>> Thanks!
>> I don't think the ssh protocols allows that. You first authenticate,
>> and only then you create the different channels. Also, it would be
>> possible to create a pty channel, then a forwarding, then close the
>> first channel.
>> Do you want to allow forwardings for "command connections"?
> 
> Angel,
> 
> Yes - actually my whole problem is that ForceCommand is invoked for
> *all* SSH connections, *except* for the forwarding-only connections.
> 
> Maybe another solution would be to add an option so that ForceCommand
> always is run, e.g. for /bin/noop on all non-SFTP non-shell
> non-command connections.

Ah - kindly let me know how you see that this works currently, and what 
you say about the suggestion?

Thanks


From radek at podgorny.cz  Thu Nov 26 09:37:33 2015
From: radek at podgorny.cz (Radek Podgorny)
Date: Wed, 25 Nov 2015 23:37:33 +0100
Subject: ssh-copy-id bugfix
In-Reply-To: <87lh9m6m2e.fsf@whist.hands.com>
References: <5654A524.7090301@podgorny.cz> <87lh9m6m2e.fsf@whist.hands.com>
Message-ID: <5656382D.7040505@podgorny.cz>

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

thanks for your effort, phil!

R.


On 11/25/2015 06:11 PM, Philip Hands wrote:
> Hi Radek,
> 
> Radek Podgorny <radek at podgorny.cz> writes:
> 
>> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
>> 
>> hello everyone!
>> 
>> i'd like to sincerely ask you to include a fix for ssh-copy-id
>> bug i'll be linking below. it's a trivial fix which resolves 
>> https://bugzilla.mindrot.org/show_bug.cgi?id=2206 and eases life
>> of many. it's been field-tested by redhat devs and users so i see
>> no problem in incorporating it.
>> 
>> http://pkgs.fedoraproject.org/cgit/openssh.git/tree/openssh-6.8p1-fix
- -ss
>>
>> 
h-copy-id-on-non-sh-shell.patch
> 
> Seems fair enough to me.
> 
> I've been meaning to do some maintenance on ssh-copy-id for quite
> a while, so thanks for the nudge -- that's what parenthood does
> for available spare time ;-)
> 
> BTW I've just pushed this fix to my git repo:
> 
> http://git.hands.com/ssh-copy-id
> 
> hopefully that can be in the next OpenSSH release -- I'll endeavour
> to deal with some of the rest of the bug backlog in the next day or
> two.
> 
> Cheers, Phil.
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iEYEARECAAYFAlZWOCsACgkQ7mej6pjlbYT5DwCffsVd2w/dUCL3BKEUgfxwj+QI
PpsAnjRQP6MM38F3lMfR4fB8gFmAquiO
=8CR0
-----END PGP SIGNATURE-----

From peter at stuge.se  Thu Nov 26 11:10:21 2015
From: peter at stuge.se (Peter Stuge)
Date: Thu, 26 Nov 2015 01:10:21 +0100
Subject: How disable forwarding-only connections (i.e.
 non-shell/command non-sftp connections)? (Maybe this is a feature
 request!)
In-Reply-To: <203f46ea78bb7ce594c33b90a93cd1e6@openmailbox.org>
References: <203f46ea78bb7ce594c33b90a93cd1e6@openmailbox.org>
Message-ID: <20151126001021.13868.qmail@stuge.se>

Tinker wrote:
> I tried with all available options to disable forwarding-only
> connections, by:
>
> "AllowAgentForwarding no
> AllowTcpForwarding no"
>
> This had no effect, so what I got in effect was dummy connections.

The above two options combined with X11Forwarding no added to your
sshd_config will disallow all forwarding.

Please explain what you mean by "dummy" above?


> I would like to disable this "class" of connections altogether.

Note that a forwarding is not a connection, but a channel. One
connection can have several channels.


> The outcome will be that all authenticated connections will lead to
> a command, be it /usr/libexec/sftp-server or other.

The above three options should do just that. If it's not working as
you want then please provide debug log output from the sshd where you
have added the three above configuration statements, when a client
connects to it and is able to open a forwarding channel. That would
be a bug.


//Peter

From tinkr at openmailbox.org  Thu Nov 26 15:41:25 2015
From: tinkr at openmailbox.org (Tinker)
Date: Thu, 26 Nov 2015 12:41:25 +0800
Subject: How disable forwarding-only connections (i.e. non-shell/command
 non-sftp =?UTF-8?Q?connections=29=3F=20=28Maybe=20this=20is=20a=20feature?=
 =?UTF-8?Q?=20request!=29?=
In-Reply-To: <20151126001021.13868.qmail@stuge.se>
References: <203f46ea78bb7ce594c33b90a93cd1e6@openmailbox.org>
 <20151126001021.13868.qmail@stuge.se>
Message-ID: <2642ca9bad35b2284c84e30d8ced50af@openmailbox.org>

Hi Peter,

What I am looking for is an SSHD configuration where every successfully 
authenticated connection also guaranteedly will lead to a ForcedCommand 
invocation.


Currently I understand this to be the case only for the connections that 
open channel to deliver a terminal, command or SFTP (I don't know if you 
have a collective name for such non-forwarding channels).


Is this possible?

Do you feel that it is a relevant feature?

Thanks,
Tinker

On 2015-11-26 08:10, Peter Stuge wrote:
> Tinker wrote:
>> I tried with all available options to disable forwarding-only
>> connections, by:
>> 
>> "AllowAgentForwarding no
>> AllowTcpForwarding no"
>> 
>> This had no effect, so what I got in effect was dummy connections.
> 
> The above two options combined with X11Forwarding no added to your
> sshd_config will disallow all forwarding.
> 
> Please explain what you mean by "dummy" above?
> 
> 
>> I would like to disable this "class" of connections altogether.
> 
> Note that a forwarding is not a connection, but a channel. One
> connection can have several channels.
> 
> 
>> The outcome will be that all authenticated connections will lead to
>> a command, be it /usr/libexec/sftp-server or other.
> 
> The above three options should do just that. If it's not working as
> you want then please provide debug log output from the sshd where you
> have added the three above configuration statements, when a client
> connects to it and is able to open a forwarding channel. That would
> be a bug.
> 
> 
> //Peter
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


From dtucker at zip.com.au  Thu Nov 26 16:03:10 2015
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 26 Nov 2015 16:03:10 +1100
Subject: How disable forwarding-only connections (i.e. non-shell/command
 non-sftp connections)? (Maybe this is a feature request!)
In-Reply-To: <2642ca9bad35b2284c84e30d8ced50af@openmailbox.org>
References: <203f46ea78bb7ce594c33b90a93cd1e6@openmailbox.org>
 <20151126001021.13868.qmail@stuge.se>
 <2642ca9bad35b2284c84e30d8ced50af@openmailbox.org>
Message-ID: <CALDDTe0ZWPTgwvUXVW7Vrmc9v__oubaQoGGpNQZE9ZwQzTGKuA@mail.gmail.com>

On Thu, Nov 26, 2015 at 3:41 PM, Tinker <tinkr at openmailbox.org> wrote:
> What I am looking for is an SSHD configuration where every successfully
> authenticated connection also guaranteedly will lead to a ForcedCommand
> invocation.
[...]
> Is this possible?

I don't think it's possible.  Or at least, not in any reasonable way.

The SSH (v2) protocol can have zero or more channels multiplexed over
it, and after the connection has been established (and authenticated)
it is up to the client to request whatever channels it wants.

Simplifying a little, these channels can be "session" (ie interactive
shell or non-interactive commands) or port forwards.  The client may
specify zero or more of these channels of either type, and there's
nothing that requires the client to request a session channel at all
(eg ssh's -N option).  The "session" request is where ForceCommand is
applied.

You could potentially hack the server to reject forwarding requests
until it had seen a session request, but that'd break reasonable
client behaviours.

What's the objective of this exercise?

-- 
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 tinkr at openmailbox.org  Thu Nov 26 16:11:45 2015
From: tinkr at openmailbox.org (Tinker)
Date: Thu, 26 Nov 2015 13:11:45 +0800
Subject: How disable forwarding-only connections (i.e. non-shell/command
 non-sftp =?UTF-8?Q?connections=29=3F=20=28Maybe=20this=20is=20a=20feature?=
 =?UTF-8?Q?=20request!=29?=
In-Reply-To: <CALDDTe0ZWPTgwvUXVW7Vrmc9v__oubaQoGGpNQZE9ZwQzTGKuA@mail.gmail.com>
References: <203f46ea78bb7ce594c33b90a93cd1e6@openmailbox.org>
 <20151126001021.13868.qmail@stuge.se>
 <2642ca9bad35b2284c84e30d8ced50af@openmailbox.org>
 <CALDDTe0ZWPTgwvUXVW7Vrmc9v__oubaQoGGpNQZE9ZwQzTGKuA@mail.gmail.com>
Message-ID: <dcd3db80f47f77097c195fbb45e00960@openmailbox.org>

On 2015-11-26 13:03, Darren Tucker wrote:
> On Thu, Nov 26, 2015 at 3:41 PM, Tinker <tinkr at openmailbox.org> wrote:
>> What I am looking for is an SSHD configuration where every 
>> successfully
>> authenticated connection also guaranteedly will lead to a 
>> ForcedCommand
>> invocation.
> [...]
>> Is this possible?
> 
> I don't think it's possible.  Or at least, not in any reasonable way.
> 
> The SSH (v2) protocol can have zero or more channels multiplexed over
> it, and after the connection has been established (and authenticated)
> it is up to the client to request whatever channels it wants.
> 
> Simplifying a little, these channels can be "session" (ie interactive
> shell or non-interactive commands) or port forwards.  The client may
> specify zero or more of these channels of either type, and there's
> nothing that requires the client to request a session channel at all
> (eg ssh's -N option).  The "session" request is where ForceCommand is
> applied.

Aha, I understand the protocol level problem.

> You could potentially hack the server to reject forwarding requests
> until it had seen a session request, but that'd break reasonable
> client behaviours.
> 
> What's the objective of this exercise?

The goal is to get a script invoked *at login time*, so that the 
authentication only is known to the client after that the script 
invocation has completed.

Does that make sense as a usecase? :)

Can it be done?

I understand that it can can be done via PAM, but then PAM is not in all 
environments and everyone don't like PAM.


From dtucker at zip.com.au  Thu Nov 26 16:33:10 2015
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 26 Nov 2015 16:33:10 +1100
Subject: How disable forwarding-only connections (i.e. non-shell/command
 non-sftp connections)? (Maybe this is a feature request!)
In-Reply-To: <dcd3db80f47f77097c195fbb45e00960@openmailbox.org>
References: <203f46ea78bb7ce594c33b90a93cd1e6@openmailbox.org>
 <20151126001021.13868.qmail@stuge.se>
 <2642ca9bad35b2284c84e30d8ced50af@openmailbox.org>
 <CALDDTe0ZWPTgwvUXVW7Vrmc9v__oubaQoGGpNQZE9ZwQzTGKuA@mail.gmail.com>
 <dcd3db80f47f77097c195fbb45e00960@openmailbox.org>
Message-ID: <CALDDTe1s1q1W_QtDpbm87rX7MTz90i1=njz3EEWGd2hJTrp=dQ@mail.gmail.com>

On Thu, Nov 26, 2015 at 4:11 PM, Tinker <tinkr at openmailbox.org> wrote:
> The goal is to get a script invoked *at login time*,

This part I follow, but having a script run is just a means to an end
not the end itself.  What is the script going to do?

> so that the authentication only is known to the client after that the script invocation
> has completed.

I don't quite follow the part about the "authentication being known to
the client".  You want your command to complete before allowing any
port forwards?  Does the result of the script matter?

> Does that make sense as a usecase? :)
>
> Can it be done?
>
> I understand that it can can be done via PAM, but then PAM is not in all
> environments and everyone don't like PAM.

PAM or bsdauth are the two obvious ways to do this.  If you are always
using public-key authentication, you could possibly abuse
AuthorizedKeysCommand in sshd_config.

This sounds a bit like what authpf[1] does.  I imagine you could write
firewall rules to block outgoing tcp connections from sshd until after
authpf runs, if that is an option for you.

[1] http://www.openbsd.org/faq/pf/authpf.html

-- 
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 tinkr at openmailbox.org  Thu Nov 26 16:49:40 2015
From: tinkr at openmailbox.org (Tinker)
Date: Thu, 26 Nov 2015 13:49:40 +0800
Subject: How disable forwarding-only connections (i.e. non-shell/command
 non-sftp =?UTF-8?Q?connections=29=3F=20=28Maybe=20this=20is=20a=20feature?=
 =?UTF-8?Q?=20request!=29?=
In-Reply-To: <CALDDTe1s1q1W_QtDpbm87rX7MTz90i1=njz3EEWGd2hJTrp=dQ@mail.gmail.com>
References: <203f46ea78bb7ce594c33b90a93cd1e6@openmailbox.org>
 <20151126001021.13868.qmail@stuge.se>
 <2642ca9bad35b2284c84e30d8ced50af@openmailbox.org>
 <CALDDTe0ZWPTgwvUXVW7Vrmc9v__oubaQoGGpNQZE9ZwQzTGKuA@mail.gmail.com>
 <dcd3db80f47f77097c195fbb45e00960@openmailbox.org>
 <CALDDTe1s1q1W_QtDpbm87rX7MTz90i1=njz3EEWGd2hJTrp=dQ@mail.gmail.com>
Message-ID: <889bd426fca64b359358c1cb3251f880@openmailbox.org>

On 2015-11-26 13:33, Darren Tucker wrote:
> On Thu, Nov 26, 2015 at 4:11 PM, Tinker <tinkr at openmailbox.org> wrote:
>> The goal is to get a script invoked *at login time*,
> 
> This part I follow, but having a script run is just a means to an end
> not the end itself.  What is the script going to do?
> 
>> so that the authentication only is known to the client after that the 
>> script invocation
>> has completed.
> 
> I don't quite follow the part about the "authentication being known to
> the client".  You want your command to complete before allowing any
> port forwards?

Yes.

> Does the result of the script matter?

No.

>> Does that make sense as a usecase? :)
>> 
>> Can it be done?
>> 
>> I understand that it can can be done via PAM, but then PAM is not in 
>> all
>> environments and everyone don't like PAM.
> 
> PAM or bsdauth are the two obvious ways to do this.

How would you do it using bsdauth?

(PAM seems very redundant to install on OBSD.)

> If you are always
> using public-key authentication, you could possibly abuse
> AuthorizedKeysCommand in sshd_config.

As in key files. Could be partially interesting to know how a 
passthrough script would look for it, but, if an all-encompassing way 
could be worked out it would be better i.e. that supports password 
logins too.

> This sounds a bit like what authpf[1] does.  I imagine you could write
> firewall rules to block outgoing tcp connections from sshd until after
> authpf runs, if that is an option for you.

(That sounds like a very indirect approach, in particular as it would 
cover only some connections?)

> 
> [1] http://www.openbsd.org/faq/pf/authpf.html

Thanks!


From dtucker at zip.com.au  Thu Nov 26 17:16:27 2015
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 26 Nov 2015 17:16:27 +1100
Subject: How disable forwarding-only connections (i.e. non-shell/command
 non-sftp connections)? (Maybe this is a feature request!)
In-Reply-To: <889bd426fca64b359358c1cb3251f880@openmailbox.org>
References: <203f46ea78bb7ce594c33b90a93cd1e6@openmailbox.org>
 <20151126001021.13868.qmail@stuge.se>
 <2642ca9bad35b2284c84e30d8ced50af@openmailbox.org>
 <CALDDTe0ZWPTgwvUXVW7Vrmc9v__oubaQoGGpNQZE9ZwQzTGKuA@mail.gmail.com>
 <dcd3db80f47f77097c195fbb45e00960@openmailbox.org>
 <CALDDTe1s1q1W_QtDpbm87rX7MTz90i1=njz3EEWGd2hJTrp=dQ@mail.gmail.com>
 <889bd426fca64b359358c1cb3251f880@openmailbox.org>
Message-ID: <CALDDTe2zSNeT5MXvj7s7BF-xWXXnKHP-8UEZudKFdEJCGHbFig@mail.gmail.com>

On Thu, Nov 26, 2015 at 4:49 PM, Tinker <tinkr at openmailbox.org> wrote:
> On 2015-11-26 13:33, Darren Tucker wrote:
[...]
>>  What is the script going to do?

You didn't answer this.

> How would you do it using bsdauth?
>
> (PAM seems very redundant to install on OBSD.)

You are using OpenBSD or something else?

[...]
>> This sounds a bit like what authpf[1] does.  I imagine you could write
>> firewall rules to block outgoing tcp connections from sshd until after
>> authpf runs, if that is an option for you.
>
> (That sounds like a very indirect approach, in particular as it would cover
> only some connections?)

Assuming you write the PF rules to do so you should be able to match
local processes (using "user" rules and the $user_id authpf macro) as
well as connections from the IP address they're logging in as (using
"from" rules and $user_ip macro).

But all of this is speculative because you still have not described
what the objective of this exercise is.

-- 
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 tinkr at openmailbox.org  Thu Nov 26 17:23:45 2015
From: tinkr at openmailbox.org (Tinker)
Date: Thu, 26 Nov 2015 14:23:45 +0800
Subject: How disable forwarding-only connections (i.e. non-shell/command
 non-sftp =?UTF-8?Q?connections=29=3F=20=28Maybe=20this=20is=20a=20feature?=
 =?UTF-8?Q?=20request!=29?=
In-Reply-To: <CALDDTe2zSNeT5MXvj7s7BF-xWXXnKHP-8UEZudKFdEJCGHbFig@mail.gmail.com>
References: <203f46ea78bb7ce594c33b90a93cd1e6@openmailbox.org>
 <20151126001021.13868.qmail@stuge.se>
 <2642ca9bad35b2284c84e30d8ced50af@openmailbox.org>
 <CALDDTe0ZWPTgwvUXVW7Vrmc9v__oubaQoGGpNQZE9ZwQzTGKuA@mail.gmail.com>
 <dcd3db80f47f77097c195fbb45e00960@openmailbox.org>
 <CALDDTe1s1q1W_QtDpbm87rX7MTz90i1=njz3EEWGd2hJTrp=dQ@mail.gmail.com>
 <889bd426fca64b359358c1cb3251f880@openmailbox.org>
 <CALDDTe2zSNeT5MXvj7s7BF-xWXXnKHP-8UEZudKFdEJCGHbFig@mail.gmail.com>
Message-ID: <bcb0db18b29c0bab5255e44ed0e3de1d@openmailbox.org>

On 2015-11-26 14:16, Darren Tucker wrote:
> On Thu, Nov 26, 2015 at 4:49 PM, Tinker <tinkr at openmailbox.org> wrote:
>> On 2015-11-26 13:33, Darren Tucker wrote:
> [...]
>>>  What is the script going to do?
> 
> You didn't answer this.

Register the login to the group's login database.

>> How would you do it using bsdauth?
>> 
>> (PAM seems very redundant to install on OBSD.)
> 
> You are using OpenBSD or something else?

OpenBSD.

> [...]
>>> This sounds a bit like what authpf[1] does.  I imagine you could 
>>> write
>>> firewall rules to block outgoing tcp connections from sshd until 
>>> after
>>> authpf runs, if that is an option for you.
>> 
>> (That sounds like a very indirect approach, in particular as it would 
>> cover
>> only some connections?)
> 
> Assuming you write the PF rules to do so you should be able to match
> local processes (using "user" rules and the $user_id authpf macro) as
> well as connections from the IP address they're logging in as (using
> "from" rules and $user_ip macro).

Wait, to PF, isn't the user for all SSH connections "root" (independent 
of what user you log in as)?

Also, how would PF know when an SSH connection became authenticated as 
to trig some rule to run a script, then.

http://www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/pf.conf.5?query=pf%2econf&arch=i386

> But all of this is speculative because you still have not described
> what the objective of this exercise is.

The object is to get a complete set of registrations of all logins on 
all servers, at auth time, sent by the registration script to the 
central database.


(If the auth time requirement was not there, adding the script as a 
"pipe" line in syslog.conf could have worked, but I think because it's 
quite indirect it's unpreferable, also not sure if you can get the 
client IP there.)




From dtucker at zip.com.au  Thu Nov 26 18:34:22 2015
From: dtucker at zip.com.au (Darren Tucker)
Date: Thu, 26 Nov 2015 18:34:22 +1100
Subject: How disable forwarding-only connections (i.e. non-shell/command
 non-sftp connections)? (Maybe this is a feature request!)
In-Reply-To: <bcb0db18b29c0bab5255e44ed0e3de1d@openmailbox.org>
References: <203f46ea78bb7ce594c33b90a93cd1e6@openmailbox.org>
 <20151126001021.13868.qmail@stuge.se>
 <2642ca9bad35b2284c84e30d8ced50af@openmailbox.org>
 <CALDDTe0ZWPTgwvUXVW7Vrmc9v__oubaQoGGpNQZE9ZwQzTGKuA@mail.gmail.com>
 <dcd3db80f47f77097c195fbb45e00960@openmailbox.org>
 <CALDDTe1s1q1W_QtDpbm87rX7MTz90i1=njz3EEWGd2hJTrp=dQ@mail.gmail.com>
 <889bd426fca64b359358c1cb3251f880@openmailbox.org>
 <CALDDTe2zSNeT5MXvj7s7BF-xWXXnKHP-8UEZudKFdEJCGHbFig@mail.gmail.com>
 <bcb0db18b29c0bab5255e44ed0e3de1d@openmailbox.org>
Message-ID: <CALDDTe0ZJ8d_QjAUzCePsRa-T8aFtaTMJc-++UHWVxkfZXByjQ@mail.gmail.com>

On Thu, Nov 26, 2015 at 5:23 PM, Tinker <tinkr at openmailbox.org> wrote:
[...]
> Wait, to PF, isn't the user for all SSH connections "root" (independent of
> what user you log in as)?

Not since privilege separation became the default ten years or so ago:
forwarded TCP connections will come from the unprivileged child sshd
running as the logged-in user.

> Also, how would PF know when an SSH connection became authenticated as to
> trig some rule to run a script, then.

authpf would just be the mechanism for ensuring that they'd sent a
session request, otherwise their outgoing tcp connections coming out
of sshd would get denied by PF.  You could have your script as the
login shell do its thing then exec authpf (or authpf-noip) at the end.

> The object is to get a complete set of registrations of all logins on all
> servers, at auth time, sent by the registration script to the central
> database.
>
> (If the auth time requirement was not there, adding the script as a "pipe"
> line in syslog.conf could have worked, but I think because it's quite
> indirect it's unpreferable, also not sure if you can get the client IP
> there.)

OK, thanks.  It feels like there should be some way to get a bsdauth
module to do this, but I've never tried anything like this before. I
can't find an obvious equivalent to a PAM session module, I'm not even
sure there is one.  I'll think about it a bit more.

-- 
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 tinkr at openmailbox.org  Thu Nov 26 18:55:57 2015
From: tinkr at openmailbox.org (Tinker)
Date: Thu, 26 Nov 2015 15:55:57 +0800
Subject: How disable forwarding-only connections (i.e. non-shell/command
 non-sftp =?UTF-8?Q?connections=29=3F=20=28Maybe=20this=20is=20a=20feature?=
 =?UTF-8?Q?=20request!=29?=
In-Reply-To: <CALDDTe0ZJ8d_QjAUzCePsRa-T8aFtaTMJc-++UHWVxkfZXByjQ@mail.gmail.com>
References: <203f46ea78bb7ce594c33b90a93cd1e6@openmailbox.org>
 <20151126001021.13868.qmail@stuge.se>
 <2642ca9bad35b2284c84e30d8ced50af@openmailbox.org>
 <CALDDTe0ZWPTgwvUXVW7Vrmc9v__oubaQoGGpNQZE9ZwQzTGKuA@mail.gmail.com>
 <dcd3db80f47f77097c195fbb45e00960@openmailbox.org>
 <CALDDTe1s1q1W_QtDpbm87rX7MTz90i1=njz3EEWGd2hJTrp=dQ@mail.gmail.com>
 <889bd426fca64b359358c1cb3251f880@openmailbox.org>
 <CALDDTe2zSNeT5MXvj7s7BF-xWXXnKHP-8UEZudKFdEJCGHbFig@mail.gmail.com>
 <bcb0db18b29c0bab5255e44ed0e3de1d@openmailbox.org>
 <CALDDTe0ZJ8d_QjAUzCePsRa-T8aFtaTMJc-++UHWVxkfZXByjQ@mail.gmail.com>
Message-ID: <43a62441f39ed5aa4949330d50c71ac5@openmailbox.org>

On 2015-11-26 15:34, Darren Tucker wrote:
> On Thu, Nov 26, 2015 at 5:23 PM, Tinker <tinkr at openmailbox.org> wrote:
> [...]
>> Wait, to PF, isn't the user for all SSH connections "root" 
>> (independent of
>> what user you log in as)?
> 
> Not since privilege separation became the default ten years or so ago:
> forwarded TCP connections will come from the unprivileged child sshd
> running as the logged-in user.
> 
>> Also, how would PF know when an SSH connection became authenticated as 
>> to
>> trig some rule to run a script, then.
> 
> authpf would just be the mechanism for ensuring that they'd sent a
> session request, otherwise their outgoing tcp connections coming out
> of sshd would get denied by PF.  You could have your script as the
> login shell do its thing then exec authpf (or authpf-noip) at the end.

Can you give an example of the pf.conf line and shellscript, that 
appends the username and remote IP logged in to, to /tmp/logins.txt? 
E.g. echo $user $ip >> /tmp/logins.txt .


An alternative way could be:

>> The object is to get a complete set of registrations of all logins on 
>> all
>> servers, at auth time, sent by the registration script to the central
>> database.
>> 
>> (If the auth time requirement was not there, adding the script as a 
>> "pipe"
>> line in syslog.conf could have worked, but I think because it's quite
>> indirect it's unpreferable, also not sure if you can get the client IP
>> there.)
> 
> OK, thanks.  It feels like there should be some way to get a bsdauth
> module to do this, but I've never tried anything like this before. I
> can't find an obvious equivalent to a PAM session module, I'm not even
> sure there is one.  I'll think about it a bit more.


login.conf has an "approve" program option, I guess actually that one 
applies for SSHD logins too?

www.openbsd.org/cgi-bin/man.cgi/OpenBSD-current/man5/login.conf.5?query=login%2econf&sec=5

From nkadel at gmail.com  Fri Nov 27 00:45:01 2015
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Thu, 26 Nov 2015 08:45:01 -0500
Subject: ssh-copy-id bugfix
In-Reply-To: <87io4q6ln5.fsf@whist.hands.com>
References: <5654A524.7090301@podgorny.cz>
 <201511251207.14945.sweet_f_a@gmx.de>
 <CAOCN9ryjJYL6tCYmw2L84MRYk-rzxe6QWDEcYYx8EFLW8rDysg@mail.gmail.com>
 <87io4q6ln5.fsf@whist.hands.com>
Message-ID: <CAOCN9rwQM=aK-2=cgCGoefa4DVu7E=2BjJ4voQuAiAcGAo5eSg@mail.gmail.com>

On Wed, Nov 25, 2015 at 12:20 PM, Philip Hands <phil at hands.com> wrote:
> Nico Kadel-Garcia <nkadel at gmail.com> writes:

>> What seems to be missing in the patch is a comment line, above the
>> stanza, explaining why the code uses "exec".
>
> My reading of the presence of "exec" there was:
>
>   We're assuming that the current shell may not be to our liking, so
>   there seems to be little point keeping it in memory solely so it can
>   at worst somehow get in the way of a clean exit.
>
> Does that really need a comment?  I'm not sure I can make a succinct
> explanation of what's going on for anyone that doesn't already know what
> exec does.  Feel free to make suggestions though.

That is _precisely_ why it needs a comment. It's a selection of a
particular technology for a particular reason that someone may not
understand as important without having to dig back to a thread or bug
report like this. For example:

     # Use "exec sh -c" to ensure POSIX compliant scripting,
especially for fish and tcsh users
     [ "$DRY_RUN" ] || printf '%s\n' "$NEW_IDS" | ssh "$@" "
     .....

From peter at stuge.se  Fri Nov 27 03:45:38 2015
From: peter at stuge.se (Peter Stuge)
Date: Thu, 26 Nov 2015 17:45:38 +0100
Subject: ssh-copy-id bugfix
In-Reply-To: <CAOCN9rwQM=aK-2=cgCGoefa4DVu7E=2BjJ4voQuAiAcGAo5eSg@mail.gmail.com>
References: <5654A524.7090301@podgorny.cz>
 <201511251207.14945.sweet_f_a@gmx.de>
 <CAOCN9ryjJYL6tCYmw2L84MRYk-rzxe6QWDEcYYx8EFLW8rDysg@mail.gmail.com>
 <87io4q6ln5.fsf@whist.hands.com>
 <CAOCN9rwQM=aK-2=cgCGoefa4DVu7E=2BjJ4voQuAiAcGAo5eSg@mail.gmail.com>
Message-ID: <20151126164538.22888.qmail@stuge.se>

Nico Kadel-Garcia wrote:
> > Does that really need a comment?
> 
> That is _precisely_ why it needs a comment. It's a selection of a
> particular technology for a particular reason that someone may not
> understand as important

Not even if they understand what the command does? (Use another shell.)

I dislike redundant comments, which this seems to be. As code change
and comments don't, those comments end up creating a lot more confusion
than they resolve.

Having clear code is far more important.

It's reasonable to require that someone reading code already knows the
tools being used.

It's not reasonable for code to educate readers on tools being used.


//Peter

From vincent.brillault at lerya.net  Fri Nov 27 07:32:05 2015
From: vincent.brillault at lerya.net (Vincent Brillault)
Date: Thu, 26 Nov 2015 21:32:05 +0100
Subject: [PATCH] Expose authentication information
Message-ID: <20151126203205.GC31718@Fea.lerya.net>

Hi all,

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?

Thanks in advance,
Vincent

PS: I've posted these patches as a single patch on the bugzilla, but as
I didn't get any feedback, I'm trying my luck here directly
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0001-Store-details-about-successful-auth-methods.patch
Type: text/x-diff
Size: 1954 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20151126/2a26a6ba/attachment-0008.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0002-Export-auth_details-to-child-env-as-SSH_USER_AUTH.patch
Type: text/x-diff
Size: 717 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20151126/2a26a6ba/attachment-0009.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0003-Expose-auth_details-to-pam-via-SSH_USER_AUTH.patch
Type: text/x-diff
Size: 1196 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20151126/2a26a6ba/attachment-0010.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0004-Extract-pubkey_format-from-pubkey_auth_info.patch
Type: text/x-diff
Size: 2889 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20151126/2a26a6ba/attachment-0011.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0005-auth2-pubkey-fill-last_details-on-success.patch
Type: text/x-diff
Size: 1334 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20151126/2a26a6ba/attachment-0012.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0006-auth2-hostbased-fill-last_details-on-success.patch
Type: text/x-diff
Size: 1414 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20151126/2a26a6ba/attachment-0013.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0007-privsep-Expose-success-auth-methods.patch
Type: text/x-diff
Size: 1537 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20151126/2a26a6ba/attachment-0014.bin>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: 0008-Mention-SSH_USER_AUTH-in-the-man-page.patch
Type: text/x-diff
Size: 927 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20151126/2a26a6ba/attachment-0015.bin>

From nkadel at gmail.com  Fri Nov 27 12:34:50 2015
From: nkadel at gmail.com (Nico Kadel-Garcia)
Date: Thu, 26 Nov 2015 20:34:50 -0500
Subject: ssh-copy-id bugfix
In-Reply-To: <20151126164538.22888.qmail@stuge.se>
References: <5654A524.7090301@podgorny.cz>
 <201511251207.14945.sweet_f_a@gmx.de>
 <CAOCN9ryjJYL6tCYmw2L84MRYk-rzxe6QWDEcYYx8EFLW8rDysg@mail.gmail.com>
 <87io4q6ln5.fsf@whist.hands.com>
 <CAOCN9rwQM=aK-2=cgCGoefa4DVu7E=2BjJ4voQuAiAcGAo5eSg@mail.gmail.com>
 <20151126164538.22888.qmail@stuge.se>
Message-ID: <CAOCN9rx9WSzkDbdDBm=eHXSDkGiprO490vrA_CzkPYdt6eTThQ@mail.gmail.com>

On Thu, Nov 26, 2015 at 11:45 AM, Peter Stuge <peter at stuge.se> wrote:
> Nico Kadel-Garcia wrote:
>> > Does that really need a comment?
>>
>> That is _precisely_ why it needs a comment. It's a selection of a
>> particular technology for a particular reason that someone may not
>> understand as important
>
> Not even if they understand what the command does? (Use another shell.)
>
> I dislike redundant comments, which this seems to be. As code change
> and comments don't, those comments end up creating a lot more confusion
> than they resolve.
>
> Having clear code is far more important.
>
> It's reasonable to require that someone reading code already knows the
> tools being used.

I'm familiar with the old "the code is the comments" approach to
documentation. The difficulty with it is exactly what we see here.
It's not clear, even to a reasonably intelligent bash progammer, that
the use of "exec" is to insure compatibility with fish and tcsh users.
I've used both, and in fact published the first public ports of tcsh
for SunOS, and even I'd have think carefully to deduce, from raw
principles, why my scripting in bash is written in a fairly ugly to
ensure compatibility with alternative shells. 5 years from now, I'd
probably have forgotten completely about this thread and be
hard-pressed to remember why I or someone else didn't simply quote
ordinary bash syntax there.

> It's not reasonable for code to educate readers on tools being used.

I suggest that it's very reasonable to explain particular choices in
code, especially when those choices were made for compatibility
reasons less common configurations. Failure to document such choices
leads to regression errors when someone unweaves the undocumented
compatibility code.

Been there, done that, especially had screwups with underdocumented
and subtly incompatible or inconsistent tools for editing
$HOME/.ssh/authorized_keys editing.

From lists at spuddy.org  Fri Nov 27 13:15:13 2015
From: lists at spuddy.org (Stephen Harris)
Date: Thu, 26 Nov 2015 21:15:13 -0500
Subject: ssh-copy-id bugfix
In-Reply-To: <CAOCN9rx9WSzkDbdDBm=eHXSDkGiprO490vrA_CzkPYdt6eTThQ@mail.gmail.com>
References: <5654A524.7090301@podgorny.cz>
 <201511251207.14945.sweet_f_a@gmx.de>
 <CAOCN9ryjJYL6tCYmw2L84MRYk-rzxe6QWDEcYYx8EFLW8rDysg@mail.gmail.com>
 <87io4q6ln5.fsf@whist.hands.com>
 <CAOCN9rwQM=aK-2=cgCGoefa4DVu7E=2BjJ4voQuAiAcGAo5eSg@mail.gmail.com>
 <20151126164538.22888.qmail@stuge.se>
 <CAOCN9rx9WSzkDbdDBm=eHXSDkGiprO490vrA_CzkPYdt6eTThQ@mail.gmail.com>
Message-ID: <20151127021513.GA17405@mercury7.spuddy.org>

On Thu, Nov 26, 2015 at 08:34:50PM -0500, Nico Kadel-Garcia wrote:
> It's not clear, even to a reasonably intelligent bash progammer, that
> the use of "exec" is to insure compatibility with fish and tcsh users.

The use of exec is not to ensure compatability.  Just doing
  sh -c "..."
would be enough.

The "exec" is for efficiency.  It is not _needed_. 

I would skip it, personally.  The efficiency gains are neglibible.

-- 

rgds
Stephen

From phil at hands.com  Sat Nov 28 06:52:01 2015
From: phil at hands.com (Philip Hands)
Date: Fri, 27 Nov 2015 20:52:01 +0100
Subject: ssh-copy-id bugfix
In-Reply-To: <20151127021513.GA17405@mercury7.spuddy.org>
References: <5654A524.7090301@podgorny.cz>
 <201511251207.14945.sweet_f_a@gmx.de>
 <CAOCN9ryjJYL6tCYmw2L84MRYk-rzxe6QWDEcYYx8EFLW8rDysg@mail.gmail.com>
 <87io4q6ln5.fsf@whist.hands.com>
 <CAOCN9rwQM=aK-2=cgCGoefa4DVu7E=2BjJ4voQuAiAcGAo5eSg@mail.gmail.com>
 <20151126164538.22888.qmail@stuge.se>
 <CAOCN9rx9WSzkDbdDBm=eHXSDkGiprO490vrA_CzkPYdt6eTThQ@mail.gmail.com>
 <20151127021513.GA17405@mercury7.spuddy.org>
Message-ID: <87mvtz5ify.fsf@whist.hands.com>

Stephen Harris <lists at spuddy.org> writes:

> On Thu, Nov 26, 2015 at 08:34:50PM -0500, Nico Kadel-Garcia wrote:
>> It's not clear, even to a reasonably intelligent bash progammer, that
>> the use of "exec" is to insure compatibility with fish and tcsh users.
>
> The use of exec is not to ensure compatability.  Just doing
>   sh -c "..."
> would be enough.
>
> The "exec" is for efficiency.  It is not _needed_. 
>
> I would skip it, personally.  The efficiency gains are neglibible.

I doubt I'd have put the "exec" in, but having thought about it briefly,
I decided to keep it (at least until someone points to a shell that
doesn't have exec, but would otherwise succeed in running sh).

FWIW I think Nico does have a point about having a comment that would
act as a reminder not to break the portability features of that line, so
that's what I'll do.

Cheers, Phil.
-- 
|)|  Philip Hands  [+44 (0)20 8530 9560]  HANDS.COM Ltd.
|-|  http://www.hands.com/    http://ftp.uk.debian.org/
|(|  Hugo-Klemm-Strasse 34,   21075 Hamburg,    GERMANY
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20151127/277fde7e/attachment.bin>

From lists at spuddy.org  Sat Nov 28 07:47:47 2015
From: lists at spuddy.org (Stephen Harris)
Date: Fri, 27 Nov 2015 15:47:47 -0500
Subject: ssh-copy-id bugfix
In-Reply-To: <87mvtz5ify.fsf@whist.hands.com>
References: <5654A524.7090301@podgorny.cz>
 <201511251207.14945.sweet_f_a@gmx.de>
 <CAOCN9ryjJYL6tCYmw2L84MRYk-rzxe6QWDEcYYx8EFLW8rDysg@mail.gmail.com>
 <87io4q6ln5.fsf@whist.hands.com>
 <CAOCN9rwQM=aK-2=cgCGoefa4DVu7E=2BjJ4voQuAiAcGAo5eSg@mail.gmail.com>
 <20151126164538.22888.qmail@stuge.se>
 <CAOCN9rx9WSzkDbdDBm=eHXSDkGiprO490vrA_CzkPYdt6eTThQ@mail.gmail.com>
 <20151127021513.GA17405@mercury7.spuddy.org>
 <87mvtz5ify.fsf@whist.hands.com>
Message-ID: <20151127204747.GA21790@mercury7.spuddy.org>

On Fri, Nov 27, 2015 at 08:52:01PM +0100, Philip Hands wrote:
> Stephen Harris <lists at spuddy.org> writes:
> 
> > On Thu, Nov 26, 2015 at 08:34:50PM -0500, Nico Kadel-Garcia wrote:
> >> It's not clear, even to a reasonably intelligent bash progammer, that
> >> the use of "exec" is to insure compatibility with fish and tcsh users.
> >
> > The use of exec is not to ensure compatability.  Just doing
> >   sh -c "..."
> > would be enough.
> >
> > The "exec" is for efficiency.  It is not _needed_. 

> I doubt I'd have put the "exec" in, but having thought about it briefly,
> I decided to keep it (at least until someone points to a shell that
> doesn't have exec, but would otherwise succeed in running sh).

I can come up with an artificial case (a "menu shell" type construct,
or some embedded device with a limited CLI) but I can't think of any
regular shell that'd suffer the issue.

> FWIW I think Nico does have a point about having a comment that would
> act as a reminder not to break the portability features of that line, so
> that's what I'll do.

A comment is definitely necessary because this thread has shown that
a multi-decade old coding construct (I first came across it in 1991)
isn't properly understood, even by the smart people on this list.

If I was doing it from scratch I might have considered just having
something like
  ssh -t "$@" /bin/sh -i
and then putting the umask/mkdir/... commands on stdin before the pubkeys
(that's how I've built solutions in the past) to keep complicated commands
and quoting away from the CLI parser, but in this case the commands are
simple enough that the proposed patch works well enough.

-- 

rgds
Stephen

From djm at mindrot.org  Sun Nov 29 22:14:32 2015
From: djm at mindrot.org (Damien Miller)
Date: Sun, 29 Nov 2015 22:14:32 +1100 (AEDT)
Subject: Problem with gpg-agent and yubikey since openssh v6.8p1
In-Reply-To: <2b0080a5d20b7f906082b534279fb197@otpme.org>
References: <2b0080a5d20b7f906082b534279fb197@otpme.org>
Message-ID: <alpine.BSO.2.20.1511292214040.12629@natsu.mindrot.org>

On Tue, 24 Nov 2015, the2nd at otpme.org wrote:

> Hi,
> 
> i'm unsure if the problem we encounter is a bug in openssh or in gnupg. But as
> everything was working with openssh 6.7p1 and earlier i guess that there where
> at least some changes in openssh that leads to the problem.
> 
> You can read the latest discussion about the problem here:
> 
> https://www.mail-archive.com/gnupg-users%40gnupg.org/msg29421.html
> https://www.mail-archive.com/gnupg-users at gnupg.org/msg28416.html
> 
> I hope to get some help on this list as its an very annoying problem and using
> an old openssh version is just a bad workaround.
> 
> If you need any more information or help debugging i'm glad to help.

At the very least, we'd need the output of "ssh -vvv user at host" for a
failing attempt.

-d

From djm at mindrot.org  Sun Nov 29 22:17:21 2015
From: djm at mindrot.org (Damien Miller)
Date: Sun, 29 Nov 2015 22:17:21 +1100 (AEDT)
Subject: How disable forwarding-only connections (i.e. non-shell/command
 non-sftp connections)? (Maybe this is a feature request!)
In-Reply-To: <203f46ea78bb7ce594c33b90a93cd1e6@openmailbox.org>
References: <203f46ea78bb7ce594c33b90a93cd1e6@openmailbox.org>
Message-ID: <alpine.BSO.2.20.1511292214530.12629@natsu.mindrot.org>

On Wed, 25 Nov 2015, Tinker wrote:

> Hi!
> 
> I tried with all available options to disable forwarding-only connections, by:
> 
> "AllowAgentForwarding no
> AllowTcpForwarding no"
> 
> This had no effect, so what I got in effect was dummy connections.
> 
> I would like to disable this "class" of connections altogether. The outcome
> will be that all authenticated connections will lead to a command, be it
> /usr/libexec/sftp-server or other.

There's no real way to do this in the SSH protocol. After the SSH transport
protocol is running and authentication has completed, there's no ironclad
way to distinguish between a connection that will never execute a command
from one that's merely slow to do so.

I don't understand why turning off agent/X11/TCP forwarding was no
sufficient for you - could you clarify?

-d


From tinkr at openmailbox.org  Sun Nov 29 22:36:45 2015
From: tinkr at openmailbox.org (Tinker)
Date: Sun, 29 Nov 2015 19:36:45 +0800
Subject: How disable forwarding-only connections (i.e. non-shell/command
 non-sftp =?UTF-8?Q?connections=29=3F=20=28Maybe=20this=20is=20a=20feature?=
 =?UTF-8?Q?=20request!=29?=
In-Reply-To: <alpine.BSO.2.20.1511292214530.12629@natsu.mindrot.org>
References: <203f46ea78bb7ce594c33b90a93cd1e6@openmailbox.org>
 <alpine.BSO.2.20.1511292214530.12629@natsu.mindrot.org>
Message-ID: <450ab44c55c718c8ed78939b59ceb320@openmailbox.org>

Damien,

Presuming it's actually using BSDauth, I think the most viable option is 
to use the "approve" program option in login.conf to reach this goal 
which is to get a command run on every successful SSH auth, to answer 
your question.

Will need to try it out, will be back here if it does not.

The pf.conf auth user discussed in this thread previously could perhaps 
work but I think it would be asynchronous.

Thanks,
Tinker

On 2015-11-29 19:17, Damien Miller wrote:
> On Wed, 25 Nov 2015, Tinker wrote:
> 
>> Hi!
>> 
>> I tried with all available options to disable forwarding-only 
>> connections, by:
>> 
>> "AllowAgentForwarding no
>> AllowTcpForwarding no"
>> 
>> This had no effect, so what I got in effect was dummy connections.
>> 
>> I would like to disable this "class" of connections altogether. The 
>> outcome
>> will be that all authenticated connections will lead to a command, be 
>> it
>> /usr/libexec/sftp-server or other.
> 
> There's no real way to do this in the SSH protocol. After the SSH 
> transport
> protocol is running and authentication has completed, there's no 
> ironclad
> way to distinguish between a connection that will never execute a 
> command
> from one that's merely slow to do so.
> 
> I don't understand why turning off agent/X11/TCP forwarding was no
> sufficient for you - could you clarify?
> 
> -d
> 
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev at mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev


From andrey.od.utkin at gmail.com  Sat Nov 28 09:01:52 2015
From: andrey.od.utkin at gmail.com (Andrey Utkin)
Date: Fri, 27 Nov 2015 22:01:52 -0000
Subject: [RFC] Keychain for GPG, SSH, X.509 etc. (inspired by Split GPG)
Message-ID: <5658D146.2070403@gmail.com>

TL;DR: Generalization of "Split GPG" concept.
Any comments?
Anybody likes the idea?
Ready to join development or early adoption?


What is this: Concept of flexible solution for usage of private keys
without disclosing them. Key usage is always confirmed by user (as a
form of AnyNumber-factor auth).

What is planned to guard: OpenPGP keys, SSH keys, X.509 client certificates.

Inspiration: Split GPG (https://www.qubes-os.org/doc/split-gpg/),
PGP-smartcards, SSH-smartcards.

Implementation form: portable libraries/toolkit.

Elements:
 - keychain server (KS): the process which is accessible via specified
protocols and has access to the unprotected keys, so that it can use them:
 --- encrypt/decrypt/sign;
 --- create challenge responses;
 - keychain key usage client (KUC): the process which makes requests for
key usage;
 - keychain confirmation server (KCS): the process conveying User's
decision (approval or rejection) to each key usage request;

The following elements must run in trusted environment (including
trusted physical security system, trusted hypervisor, trusted machine OS);
 - keychain server;
 - keychain confirmation server.
Keychain key usage client can work in entirely hostile environment.
Keychain usage client (KUC) may be entirely spoofed by attacker, no data
from KUC is trusted and it must be verified by User.

The above restriction is not a show-stopper ("oh, too much restricted
scheme - how to get such trusted environments?"). It is an improvement
comparing to default scheme, which supposes secret keys exposition in
same hostile environment. The point is in decoupling these three
essential entities of key material, key usage agent (gpg-agent,
ssh-agent) and key control (usually underdeveloped in mainstream systems
- you just MAY get asked to enter passphrase if you use it).
This scheme is an improvement comparing to hardware smartcard usage
because it brings flexiblility and fine-grained control to key usage
confirmation procedure.

Q: How confirmation happens?
A: This function is outsourced to plugin system. Different systems would
find different ways as most fit. Used/allowed plugins configuration is
set up in keychain server. It possibly will look similar to Linux PAM.

Q: How to have keychain server data encrypted?
A: As long as KS must actually use the keys in their unencrypted form,
it is required that safety of KS is trusted. If we cannot assume KS
environment trusted, then keys are compromised as soon as they get
loaded in unencrypted form. See http://blog.invisiblethings.org/keys/ "I
proudly use empty passphrases on all of my private keys...". Encryption
of KS data is out of scope of this scheme, but it may be implemented as
the adopter decides, as additional safety measure.

Q: How to ensure unspoofability of confirmation dialog?
A: Confirmation app must run in trusted environment, so this is not
needed. If environment is not trusted, the unspoofability of
confirmation dialog is only one of countless unresonvable security issues.

Q: Which protocols are used to convey key usage dialogs and confirmation
dialogs?
A: The ones that can be considered handy and trusted in specific case.
The following ones are offered for adopters consideration:
 - SSH;
 - other end-to-end (KUC-KS, KS-KCS, KUC-KCS) encrypted connections:
 --- XMPP via TLS chat with PGP or OTR encryption;
 --- HTTPS online session with realtime notifications;
 --- encrypted VoIP or VVoIP call communication (smart audio
synthesis/recognition software are probably required);
 --- confirmation HTTPS link in encrypted email;
 - NFC (near-field communication protocol, hardware) - NFC crypto chip
prepares signature which shows approval to KS;
 - (bad, use as fallback) SMS, PSTN call;
It should be stated that KC may want to gather more than one approval,
by more than one communication channel (thus we have multi-factor
authorization). Or system may query several confirmation channels in
parallel or serial fashion.


Examples of viable platforms for trusted elements (KC, KCS), review of
potential risks:
 - Android device: so-so to bad (depending on whether the system is
fully dedicated, and on system configuration):
 --- risk for KC: vendor-provided OS system services tend to spy on user;
 --- risk for KC: normally every app has its kernel-guarded storage, but
processes with system privilegee (gained by exploit or by user
permission) may access this data;
 --- risk for KCS: potential spoofing of KCS app dialogs;

 - Remote sever: bad to so-so to good (depending on whether VPS or owned
and guarded physical machine):
 --- risk for any component: remote attack (TODO elaborate, review more
in-depth);

 - Pluggable micro-PC with dedicated system (like
http://inversepath.com/usbarmory.html): potentially good, but there's
lack of interactive peripheral for dialog, a gadget like androids
without bloatware would be nice.

 - Virtual machines: good, but must be used properly - untrusted env
mustn't be supervising trusted env.

 - Different UNIX system accounts from untrusted component: bad, trusted
elements are owned on privilege escalating exploitation.

 - LXC: same as with UNIX accounts (kernel exploit owns everything)?


Example elements layouts:

 - keychain server (KC) and confirmation server (KCS) on Android device,
keychain usage client (KUC) on a workstation: simple, affordable, bad
security;
 - keycnain server (KC) on remote server, usage client (KUC) on a
workstation, confirmation client (KCS) on another, trusted workstation:
pretty good, if remote server is safe;


Further expansion of this scheme:
 - X.509 client cert auth challenge forwarding (using browser plugin);
 - HTTP DIGEST auth challenges forwarding from KUC (using browser
plugin) to KS;
 - forwarding requests for file access, i.e. implementation of
filesystem in userspace, with manual access control on sensitive data
exposed to untrusted environment.

-- 
OpenPGP usage is appreciated (it also helps your letter to bypass spam
filters). To email me with encryption easily, go
https://encrypt.to/0xC6FCDB11

-------------- 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/20151127/2e433b66/attachment.bin>