From felix at kngnt.org Sat Apr 1 02:03:17 2017 From: felix at kngnt.org (Felix Rubio) Date: Fri, 31 Mar 2017 17:03:17 +0200 Subject: Buffer flush when using =?UTF-8?Q?pam=5Finfo?= In-Reply-To: <405beeefa214818f98ec88c720e052d0@kngnt.org> References: <405beeefa214818f98ec88c720e052d0@kngnt.org> Message-ID: <056565c9fc43f6479b9bbed5420646f7@kngnt.org> I think I have started to understand: pam_info messages (together with pam_error messages) are packed together into SSH2_MSG_USERAUTH_BANNER messages. I have not checked it yet but, probably the pam_prompt triggers either the sent of this message to client, or the display of these messages in the client. Can somebody tell me if this is the case? What I am trying to do is: I have a script that produces a URL that is supposed to be sent to the client, and wait while polling a web service. When the user has authenticated on this server, the script is notified and returns zero or one. Therefore, I need to find a way to send a string to the ssh client, and have it display this string. Thank you for your time, Felix --- Felix Rubio "Don't believe what you're told. Double check." On 2017-03-31 10:44, Felix Rubio wrote: > Hi all, > > I had posted a related question to pam developers list, but I have > continued investigating and seems to be a question for this mailing > list. I have a script to be used by pam_exec when logging into a > system through openssh client. This script writes a message in its > stdout, that is passed to ssh_thread_conv(auth-pam.c) by a call to > pam_info, in pam_exec.so. The message is passed to ssh_msg_send, which > issues a write into the corresponent file descriptor. > > The problem is: I never get to see that message in the ssh client. > OTOH, if I modify pam_exec module to issue a pam_prompt instead of a > pam_info, the message appears on the ssh client. The relevant code for > both functionalities in auth-pam.c is: > > static int > sshpam_thread_conv(int n, sshpam_const struct pam_message **msg, > struct pam_response **resp, void *data) > { > ..... > case PAM_PROMPT_ECHO_OFF: > case PAM_PROMPT_ECHO_ON: > buffer_put_cstring(&buffer, > PAM_MSG_MEMBER(msg, i, msg)); > if (ssh_msg_send(ctxt->pam_csock, > PAM_MSG_MEMBER(msg, i, msg_style), &buffer) > == -1) > goto fail; > if (ssh_msg_recv(ctxt->pam_csock, &buffer) == > -1) > goto fail; > if (buffer_get_char(&buffer) != PAM_AUTHTOK) > goto fail; > reply[i].resp = buffer_get_string(&buffer, > NULL); > break; > case PAM_ERROR_MSG: > case PAM_TEXT_INFO: > buffer_put_cstring(&buffer, > PAM_MSG_MEMBER(msg, i, msg)); > if (ssh_msg_send(ctxt->pam_csock, > PAM_MSG_MEMBER(msg, i, msg_style), &buffer) > == -1) > goto fail; > break; > ..... > } > > As can be seen, the only difference (I have also checked the contents > of ssh_msg_send) is in the fact that, when pam_prompt is used, a > ssh_msg_send is followed by a ssh_msg_recv, whereas for a pam_info, > only the ssh_msg_send is performed. > > The OpenSSH version is 7.5p1, and the operating system is CentOS7.3. > > Can somebody advice on whether this is a client or a server issue, > and... yeah.. what can I do? > > Thank you! > Felix From tgc at jupiterrise.com Sat Apr 1 06:30:10 2017 From: tgc at jupiterrise.com (Tom G. Christensen) Date: Fri, 31 Mar 2017 21:30:10 +0200 Subject: testsuite error on Solaris 2.6 [Re: Announce: OpenSSH 7.5 released] In-Reply-To: References: Message-ID: On 27/03/17 17:06, Tom G. Christensen wrote: > On 20/03/17 14:31, Damien Miller wrote: >> OpenSSH 7.5 has just been released. It will be available from the >> mirrors listed at http://www.openssh.com/ shortly. >> > > I'm seeing an error in the testsuite on Solaris 2.6: > test_utf8: ........................ > regress/unittests/utf8/tests.c:48 test #25 "c_esc" > ASSERT_INT_EQ(len, wantlen) failed: > len = -1 > wantlen = 5 > > > It seems this might be related to the fact that on Solaris < 7 > nl_langinfo(CODESET) returns an empty string when the codeset is ASCII. > > To verify I put together a small testprogram that does a setlocale > followed by nl_langinfo(CODESET) and for the 'C' locale it returns an > empty string while 'da' returns ISO8859-1 as expected. > I worked some more on this and comparing locales and their codesets between Solaris 2.6 and 7 I'm reasonably sure that an empty codeset value means ascii on Solaris 2.6. So to ensure proper operation and get rid of the error in the testsuite I've added "" as a valid alias for ascii in dangerous_locales(). With this change in place the testsuite runs with no errors. -tgc From noloader at gmail.com Sat Apr 1 14:28:47 2017 From: noloader at gmail.com (Jeffrey Walton) Date: Fri, 31 Mar 2017 23:28:47 -0400 Subject: Solaris and use of /usr/ucb Message-ID: Hi Everyone, The portability team may be interesting in this. It looks like /usr/ucb is being used a fair amount on Solaris: $ /usr/gnu/bin/grep -IR '/usr/ucb' * | wc -l 17 According to https://blogs.oracle.com/partnertech/entry/preparing_for_the_upcoming_removal, /usr/ucb is going away. I think the mostly equivalent place to find utilities is /usr/gnu (its present on Solaris 11): $ ls /usr/gnu/bin/ [ eqn mkfifo soelim addr2line expand mknod sort amd64 expr mktemp split ... It appears /usr/gnu is not being used at the moment: $ /usr/gnu/bin/grep -IR '/usr/gnu' * | wc -l 0 Jeff From dtucker at zip.com.au Sat Apr 1 19:43:41 2017 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 1 Apr 2017 19:43:41 +1100 Subject: Solaris and use of /usr/ucb In-Reply-To: References: Message-ID: On Sat, Apr 1, 2017 at 2:28 PM, Jeffrey Walton wrote: > Hi Everyone, > > The portability team may be interesting in this. It looks like > /usr/ucb is being used a fair amount on Solaris: > > $ /usr/gnu/bin/grep -IR '/usr/ucb' * | wc -l > 17 > I don't think it's anything to be concerned about. The bulk are in the automatically generated configure script and for the most part it's just one more place to look. $ grep -rc /usr/ucb * | grep -v :0 configure:12 configure.ac:3 regress/test-exec.sh:2 Of the remaining ones, 2 in configure.ac are not even for Solaris and the other one is only a path addition if test -z "$MANTYPE"; then TestPath="/usr/bin${PATH_SEPARATOR}/usr/ucb" AC_PATH_PROGS([NROFF], [nroff awf], [/bin/false], [$TestPath]) if ${NROFF} -mdoc ${srcdir}/ssh.1 >/dev/null 2>&1; then test-exec also looks innocuous: if [ -x /usr/ucb/whoami ]; then USER=`/usr/ucb/whoami` elif whoami >/dev/null 2>&1; then USER=`whoami` -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From schwarze at usta.de Sun Apr 2 23:43:13 2017 From: schwarze at usta.de (Ingo Schwarze) Date: Sun, 2 Apr 2017 15:43:13 +0200 Subject: testsuite error on Solaris 2.6 In-Reply-To: References: Message-ID: <20170402134313.GD79932@athene.usta.de> Hi, Tom G. Christensen wrote on Fri, Mar 31, 2017 at 09:30:10PM +0200: > On 27/03/17 17:06, Tom G. Christensen wrote: >> I'm seeing an error in the testsuite on Solaris 2.6: >> test_utf8: ........................ >> regress/unittests/utf8/tests.c:48 test #25 "c_esc" >> ASSERT_INT_EQ(len, wantlen) failed: >> len = -1 >> wantlen = 5 >> >> >> It seems this might be related to the fact that on Solaris < 7 >> nl_langinfo(CODESET) returns an empty string when the codeset is ASCII. >> >> To verify I put together a small testprogram that does a setlocale >> followed by nl_langinfo(CODESET) and for the 'C' locale it returns an >> empty string while 'da' returns ISO8859-1 as expected. > I worked some more on this and comparing locales and their codesets > between Solaris 2.6 and 7 I'm reasonably sure that an empty codeset > value means ascii on Solaris 2.6. I'm not quite sure how relevant Solaris 2.6 still is, but i dimly remeber having seen systems where nl_langinfo(3) returns "" for ASCII before, though i have forgotten which ones. > So to ensure proper operation and get rid of the error in the testsuite > I've added "" as a valid alias for ascii in dangerous_locales(). > With this change in place the testsuite runs with no errors. That would be the following patch. I don't see any downside. A system where nl_codeset(3) would return "" for some non-ASCII and non-UTF-8 locale would probably cause you worse grief than sftp(1) or scp(1) potentially screwing up your terminal settings. OK? Ingo Index: utf8.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/utf8.c,v retrieving revision 1.5 diff -u -p -r1.5 utf8.c --- utf8.c 19 Feb 2017 00:10:57 -0000 1.5 +++ utf8.c 2 Apr 2017 13:35:38 -0000 @@ -51,8 +51,8 @@ dangerous_locale(void) { char *loc; loc = nl_langinfo(CODESET); - return strcmp(loc, "US-ASCII") != 0 && strcmp(loc, "UTF-8") != 0 && - strcmp(loc, "ANSI_X3.4-1968") != 0; + return *loc != '\0' && strcmp(loc, "US-ASCII") != 0 && + strcmp(loc, "UTF-8") != 0 && strcmp(loc, "ANSI_X3.4-1968") != 0; } static int From tgc at jupiterrise.com Mon Apr 3 01:33:33 2017 From: tgc at jupiterrise.com (Tom G. Christensen) Date: Sun, 2 Apr 2017 17:33:33 +0200 Subject: testsuite error on Solaris 2.6 In-Reply-To: <20170402134313.GD79932@athene.usta.de> References: <20170402134313.GD79932@athene.usta.de> Message-ID: <1187550e-298f-ed2f-c9e0-20c2f38e3d01@jupiterrise.com> On 02/04/17 15:43, Ingo Schwarze wrote: > Tom G. Christensen wrote on Fri, Mar 31, 2017 at 09:30:10PM +0200: >> I worked some more on this and comparing locales and their codesets >> between Solaris 2.6 and 7 I'm reasonably sure that an empty codeset >> value means ascii on Solaris 2.6. > > I'm not quite sure how relevant Solaris 2.6 still is, but i dimly > remeber having seen systems where nl_langinfo(3) returns "" for > ASCII before, though i have forgotten which ones. > I doubt Solaris 2.6 or 7 for that matter has any commercial relevance I just work on these old releases for hobbyist purposes. I uploaded my OpenSSH 7.5p1 packages here: https://jupiterrise.com/ >> So to ensure proper operation and get rid of the error in the testsuite >> I've added "" as a valid alias for ascii in dangerous_locales(). >> With this change in place the testsuite runs with no errors. > > That would be the following patch. I don't see any downside. > A system where nl_codeset(3) would return "" for some non-ASCII > and non-UTF-8 locale would probably cause you worse grief than > sftp(1) or scp(1) potentially screwing up your terminal settings. > For reference this is the patch I made and included in my Solaris 2.6 openssh packages: https://github.com/tgc/tgcware-for-solaris/blob/master/openssh/src/0001-Treat-empty-codeset-value-as-ascii.patch > OK? > Ingo > > > Index: utf8.c > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/utf8.c,v > retrieving revision 1.5 > diff -u -p -r1.5 utf8.c > --- utf8.c 19 Feb 2017 00:10:57 -0000 1.5 > +++ utf8.c 2 Apr 2017 13:35:38 -0000 > @@ -51,8 +51,8 @@ dangerous_locale(void) { > char *loc; > > loc = nl_langinfo(CODESET); > - return strcmp(loc, "US-ASCII") != 0 && strcmp(loc, "UTF-8") != 0 && > - strcmp(loc, "ANSI_X3.4-1968") != 0; > + return *loc != '\0' && strcmp(loc, "US-ASCII") != 0 && > + strcmp(loc, "UTF-8") != 0 && strcmp(loc, "ANSI_X3.4-1968") != 0; > } > > static int > Note that in 7.5p1, '646' was added as an additional alias (which happened to cover not only NetBSD but also Solaris 7 and later.) -tgc From schwarze at usta.de Mon Apr 3 04:15:58 2017 From: schwarze at usta.de (Ingo Schwarze) Date: Sun, 2 Apr 2017 20:15:58 +0200 Subject: testsuite error on Solaris 2.6 In-Reply-To: <1187550e-298f-ed2f-c9e0-20c2f38e3d01@jupiterrise.com> References: <20170402134313.GD79932@athene.usta.de> <1187550e-298f-ed2f-c9e0-20c2f38e3d01@jupiterrise.com> Message-ID: <20170402181558.GE79932@athene.usta.de> Hi, Tom G. Christensen wrote on Sun, Apr 02, 2017 at 05:33:33PM +0200: > For reference this is the patch I made and included in my Solaris 2.6 > openssh packages: > https://github.com/tgc/tgcware-for-solaris/blob/master/openssh/src/0001-Treat-empty-codeset-value-as-ascii.patch Sure, that has the same effect as what i sent, maybe a bit more readable. > Note that in 7.5p1, '646' was added as an additional alias (which > happened to cover not only NetBSD but also Solaris 7 and later.) Now i'm confused. Why would anyone allow dangerous_locale() to diverge between OpenSSH proper and -portable? I'd prefer the simplest approach of having all its parts in OpenSSH proper; it does no harm on OpenBSD. If people think it's too ugly, my second preference would be to delete the whole function from OpenSSH proper outright and only have it in -portable, which is admittedly somewhat less simple. But maintaining two different versions really seems pointless and confusing to me. So, that would be this patch: OK? Ingo Index: utf8.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/utf8.c,v retrieving revision 1.5 diff -u -p -r1.5 utf8.c --- utf8.c 19 Feb 2017 00:10:57 -0000 1.5 +++ utf8.c 2 Apr 2017 18:13:27 -0000 @@ -52,7 +52,8 @@ dangerous_locale(void) { loc = nl_langinfo(CODESET); return strcmp(loc, "US-ASCII") != 0 && strcmp(loc, "UTF-8") != 0 && - strcmp(loc, "ANSI_X3.4-1968") != 0; + strcmp(loc, "ANSI_X3.4-1968") != 0 && strcmp(loc, "646") != 0 && + strcmp(loc, "") != 0; } static int From vapier at gentoo.org Tue Apr 4 07:43:08 2017 From: vapier at gentoo.org (Mike Frysinger) Date: Mon, 3 Apr 2017 17:43:08 -0400 Subject: [PATCH] authfile: do not check st_size if we munged it Message-ID: <20170403214308.30030-1-vapier@gentoo.org> From: Mike Frysinger The recent change to sshkey_load_file to bump the default stat size from 0 up to 64KiB ends up breaking loading of keys in that scenario. This is because later in the function, we check to see if the amount of data we read matches what we stat-ed, and since we changed it to 64KiB, we never actually match (unless the key data happens to be 64KiB exactly). Change the code to skip the sanity check in case we bumped it. This shows up in the PNaCl version of ssh used by the SecureShell Chrome extension: https://crbug.com/707941 --- authfile.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/authfile.c b/authfile.c index 7411b68f6e42..557e0205ab97 100644 --- a/authfile.c +++ b/authfile.c @@ -133,7 +133,8 @@ sshkey_load_file(int fd, struct sshbuf *blob) goto out; } } - if ((st.st_mode & (S_IFSOCK|S_IFCHR|S_IFIFO)) == 0 && + if (dontmax == 0 && + (st.st_mode & (S_IFSOCK|S_IFCHR|S_IFIFO)) == 0 && st.st_size != (off_t)sshbuf_len(blob)) { r = SSH_ERR_FILE_CHANGED; goto out; -- 2.12.0 From nunojpg at gmail.com Wed Apr 5 00:18:30 2017 From: nunojpg at gmail.com (=?UTF-8?Q?Nuno_Gon=C3=A7alves?=) Date: Tue, 4 Apr 2017 16:18:30 +0200 Subject: Allow SHA1 deprecation for rsa-sha Message-ID: Hi, Following the fix [1] being released on 7.5, now SHA2 RSA signature methods work properly. On the other hand it is still not possible to disable SHA1 RSA alone (as an example, as SHA2-256 or SHA2-512 could also potentially be not desirable), where it is considered insecure or undesirable. I am proposing to add a mechanism, and happy to submit a patch, to enable selection of the Hashes allowed for RSA. If all or any of SHA1, SHA2-256, and SHA2-512. The straighforward solution would be just to adapt all options that currently accept "ssh-rsa" to mean that they accept (SHA1,SHA2-256,SHA2-512), and to use rsa-sha2-256 and rsa-sha2-512 to mean just the specific hash formats. So ssh-rsa would mean the same as now, and in the future deprecation for sha1 could be enforced by replacing the config with "rsa-sha2-256,rsa-sha2-512". Unfortunately this doesn't cover the possibility the user wants to disable instead sha2 and only allow sha1. For that case I propose to extend keytypes at sshkey.c, with an additional "rsa-sha1" algorithm. This means that ssh-rsa would be the "legacy" configuration, with the same meaning as "rsa-sha1, rsa-sha2-256, rsa-sha2-512". I would appreciate comments if this is seen fit. Also, since I am lacking on understanding the ssh protocol, I question if this sha2 extensions also apply "ssh-rsa-cert-v01 at openssh.com". Thanks, Nuno [1] https://bugzilla.mindrot.org/show_bug.cgi?id=2680 From jjelen at redhat.com Wed Apr 5 18:21:10 2017 From: jjelen at redhat.com (Jakub Jelen) Date: Wed, 5 Apr 2017 10:21:10 +0200 Subject: Allow SHA1 deprecation for rsa-sha In-Reply-To: References: Message-ID: On 04/04/2017 04:18 PM, Nuno Gon?alves wrote: > Hi, > > Following the fix [1] being released on 7.5, now SHA2 RSA signature > methods work properly. > > On the other hand it is still not possible to disable SHA1 RSA alone > (as an example, as SHA2-256 or SHA2-512 could also potentially be not > desirable), where it is considered insecure or undesirable. > > I am proposing to add a mechanism, and happy to submit a patch, to > enable selection of the Hashes allowed for RSA. If all or any of SHA1, > SHA2-256, and SHA2-512. > > The straighforward solution would be just to adapt all options that > currently accept "ssh-rsa" to mean that they accept > (SHA1,SHA2-256,SHA2-512), and to use rsa-sha2-256 and rsa-sha2-512 to > mean just the specific hash formats. > > So ssh-rsa would mean the same as now, and in the future deprecation > for sha1 could be enforced by replacing the config with > "rsa-sha2-256,rsa-sha2-512". > > Unfortunately this doesn't cover the possibility the user wants to > disable instead sha2 and only allow sha1. > > For that case I propose to extend keytypes at sshkey.c, with an > additional "rsa-sha1" algorithm. > > This means that ssh-rsa would be the "legacy" configuration, with the > same meaning as "rsa-sha1, rsa-sha2-256, rsa-sha2-512". > > I would appreciate comments if this is seen fit. > > Also, since I am lacking on understanding the ssh protocol, I question > if this sha2 extensions also apply "ssh-rsa-cert-v01 at openssh.com". > > Thanks, > Nuno > > [1] https://bugzilla.mindrot.org/show_bug.cgi?id=2680 Hello, Disabling SHA-1 for signatures sounds like a good idea these days (and was the main reason why the extension created if I read it right [1]). This leaves me confused if the use case without SHA1 was missed from the draft or it was left as an implementation detail, that was not implemented in OpenSSH. Your proposal sounds reasonable, though not sure if this should all go into this single configuration option, or we should use different talking about the hash algorithms such as PubkeySignatureHash, since the existing list of algorithms (PubkeyAcceptedKeyTypes) is long enough already. To my understanding, this update should not be needed for the certificates, since they are just an addition to public keys and do not change how the private key operations are performed (and secured). [1] https://tools.ietf.org/html/draft-rsa-dsa-sha2-256-03 Regards, -- Jakub Jelen Software Engineer Security Technologies Red Hat From nunojpg at gmail.com Thu Apr 6 00:41:23 2017 From: nunojpg at gmail.com (=?UTF-8?Q?Nuno_Gon=C3=A7alves?=) Date: Wed, 5 Apr 2017 16:41:23 +0200 Subject: Allow SHA1 deprecation for rsa-sha In-Reply-To: References: Message-ID: On Wed, Apr 5, 2017 at 10:21 AM, Jakub Jelen wrote: > Your proposal sounds reasonable, though not sure if this should all go into > this single configuration option, or we should use different talking about > the hash algorithms such as PubkeySignatureHash, since the existing list of > algorithms (PubkeyAcceptedKeyTypes) is long enough already. Actually I tried exactly as you suggested 1 month ago [1], but I'm not sure if that is the best way forward now after comments from Douglas, and so I was proposing to just extend the same option. Anyway I'll wait for comments for 1 week and then eventually provide patchs for both options as they are quite trivial in any case. Thanks, Nuno [1] https://github.com/nunojpg/openssh-portable/commit/1739aceb34c0eb4a9b363ff2515925e093d7ddcc From djm at mindrot.org Thu Apr 6 08:29:10 2017 From: djm at mindrot.org (Damien Miller) Date: Thu, 6 Apr 2017 08:29:10 +1000 (AEST) Subject: Allow SHA1 deprecation for rsa-sha In-Reply-To: References: Message-ID: On Wed, 5 Apr 2017, Jakub Jelen wrote: > Disabling SHA-1 for signatures sounds like a good idea these days (and was the > main reason why the extension created if I read it right [1]). > This leaves me confused if the use case without SHA1 was missed from the draft > or it was left as an implementation detail, that was not implemented in > OpenSSH. The reasons we didn't implement disabling RSA/SHA1 were basically: 1) The protocol extension used to negotiate the RSA/SHA2 methods is still an early draft and is subject to change 2) Hardly any other implementations support the necessary extension. 3) Support for RSA/SHA2 signatures is still incomplete, e.g. they aren't usable with PKCS#11 tokens yet. IMO users who want a stronger signature hash algorithm should use ed25519 or one of the ECDSA methods for the time being. All of these use SHA2 hashes. -d From nunojpg at gmail.com Thu Apr 6 08:53:36 2017 From: nunojpg at gmail.com (=?UTF-8?Q?Nuno_Gon=C3=A7alves?=) Date: Thu, 6 Apr 2017 00:53:36 +0200 Subject: Allow SHA1 deprecation for rsa-sha In-Reply-To: References: Message-ID: On Thu, Apr 6, 2017 at 12:29 AM, Damien Miller wrote: > 3) Support for RSA/SHA2 signatures is still incomplete, e.g. they aren't > usable with PKCS#11 tokens yet. Could you please elaborate on what that means? I only use RSA keys with PKCS11 tokens (OpenSC), and it works with SHA2. > IMO users who want a stronger signature hash algorithm should use ed25519 > or one of the ECDSA methods for the time being. All of these use SHA2 hashes. Exactly what I do, when I don't need to use a legacy key on a PKCS11 token... Thanks, Nuno From uri at ll.mit.edu Thu Apr 6 09:16:45 2017 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 5 Apr 2017 23:16:45 +0000 Subject: Allow SHA1 deprecation for rsa-sha In-Reply-To: References: Message-ID: And mouse07410 fork of OpenSC.tokend supports both SHA-2 and ECC. Regards, Uri Sent from my iPhone > On Apr 5, 2017, at 19:00, Nuno Gon?alves wrote: > >> On Thu, Apr 6, 2017 at 12:29 AM, Damien Miller wrote: >> 3) Support for RSA/SHA2 signatures is still incomplete, e.g. they aren't >> usable with PKCS#11 tokens yet. > > Could you please elaborate on what that means? I only use RSA keys > with PKCS11 tokens (OpenSC), and it works with SHA2. > >> IMO users who want a stronger signature hash algorithm should use ed25519 >> or one of the ECDSA methods for the time being. All of these use SHA2 hashes. > > Exactly what I do, when I don't need to use a legacy key on a PKCS11 token... > > Thanks, > Nuno > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4223 bytes Desc: not available URL: From uri at ll.mit.edu Thu Apr 6 09:15:31 2017 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Wed, 5 Apr 2017 23:15:31 +0000 Subject: Allow SHA1 deprecation for rsa-sha In-Reply-To: References: Message-ID: The problem is that (AFAIK) OpenSSH doesn't work with EC tokens. On the other hand, I've been using RSA with SHA-2 successfully with several tokens (mostly PIV). Regards, Uri Sent from my iPhone > On Apr 5, 2017, at 19:00, Nuno Gon?alves wrote: > >> On Thu, Apr 6, 2017 at 12:29 AM, Damien Miller wrote: >> 3) Support for RSA/SHA2 signatures is still incomplete, e.g. they aren't >> usable with PKCS#11 tokens yet. > > Could you please elaborate on what that means? I only use RSA keys > with PKCS11 tokens (OpenSC), and it works with SHA2. > >> IMO users who want a stronger signature hash algorithm should use ed25519 >> or one of the ECDSA methods for the time being. All of these use SHA2 hashes. > > Exactly what I do, when I don't need to use a legacy key on a PKCS11 token... > > Thanks, > Nuno > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4223 bytes Desc: not available URL: From rabel at b1-systems.de Thu Apr 6 19:22:40 2017 From: rabel at b1-systems.de (David Rabel) Date: Thu, 6 Apr 2017 11:22:40 +0200 Subject: Troubleshoot "could not write ident string" error Message-ID: <3e9a50ed-219b-23c9-38a9-54c52cd5acd6@b1-systems.de> Hi there, I have an sshd running in a virtual machine running openSUSE 12.3. I want to connect to that VM via ssh (the host OS is Debian Testing), but it fails. In the syslog of the VM I only recieve ""could not write ident string to ", even with LogLevel set to DEBUG. I had a brief look at the source code but was not able to understand what is going wrong. Searching for that error message on the web did not produce any useful results. Do you have any hint for me how to troubleshoot this issue? Thank you! Yours David -- David Rabel Linux Consultant & Trainer Tel.: +49-1511-5908566 Mail: rabel at b1-systems.de B1 Systems GmbH Osterfeldstra?e 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 From reuti at staff.uni-marburg.de Thu Apr 6 19:34:32 2017 From: reuti at staff.uni-marburg.de (Reuti) Date: Thu, 6 Apr 2017 11:34:32 +0200 Subject: Troubleshoot "could not write ident string" error In-Reply-To: <3e9a50ed-219b-23c9-38a9-54c52cd5acd6@b1-systems.de> References: <3e9a50ed-219b-23c9-38a9-54c52cd5acd6@b1-systems.de> Message-ID: Hi, > Am 06.04.2017 um 11:22 schrieb David Rabel : > > Hi there, > > I have an sshd running in a virtual machine running openSUSE 12.3. I > want to connect to that VM via ssh (the host OS is Debian Testing), but > it fails. In the syslog of the VM I only recieve ""could not write ident > string to ", even with LogLevel set to DEBUG. Can you connect local inside the VM to itself by ssh, and/or does it only effect the external connection? -- Reuti > > I had a brief look at the source code but was not able to understand > what is going wrong. Searching for that error message on the web did not > produce any useful results. > > Do you have any hint for me how to troubleshoot this issue? > > Thank you! > > Yours > David > > > -- > David Rabel > Linux Consultant & Trainer > Tel.: +49-1511-5908566 > Mail: rabel at b1-systems.de > > B1 Systems GmbH > Osterfeldstra?e 7 / 85088 Vohburg / http://www.b1-systems.de > GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 203 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rabel at b1-systems.de Thu Apr 6 19:40:05 2017 From: rabel at b1-systems.de (David Rabel) Date: Thu, 6 Apr 2017 11:40:05 +0200 Subject: Troubleshoot "could not write ident string" error In-Reply-To: References: <3e9a50ed-219b-23c9-38a9-54c52cd5acd6@b1-systems.de> Message-ID: Hi Reuti, On 06.04.2017 11:34, Reuti wrote: >> Am 06.04.2017 um 11:22 schrieb David Rabel : >> >> I have an sshd running in a virtual machine running openSUSE 12.3. I >> want to connect to that VM via ssh (the host OS is Debian Testing), but >> it fails. In the syslog of the VM I only recieve ""could not write ident >> string to ", even with LogLevel set to DEBUG. > > Can you connect local inside the VM to itself by ssh, and/or does it only effect the external connection? Yes, "ssh localhost" inside the VM works. Yours David -- David Rabel Linux Consultant & Trainer Tel.: +49-1511-5908566 Mail: rabel at b1-systems.de B1 Systems GmbH Osterfeldstra?e 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: From rabel at b1-systems.de Thu Apr 6 19:52:04 2017 From: rabel at b1-systems.de (David Rabel) Date: Thu, 6 Apr 2017 11:52:04 +0200 Subject: Troubleshoot "could not write ident string" error In-Reply-To: <3e9a50ed-219b-23c9-38a9-54c52cd5acd6@b1-systems.de> References: <3e9a50ed-219b-23c9-38a9-54c52cd5acd6@b1-systems.de> Message-ID: <9cd0f160-e890-557f-d2f0-95d641c33b35@b1-systems.de> On 06.04.2017 11:22, David Rabel wrote: > Hi there, > > I have an sshd running in a virtual machine running openSUSE 12.3. I > want to connect to that VM via ssh (the host OS is Debian Testing), but > it fails. In the syslog of the VM I only recieve ""could not write ident > string to ", even with LogLevel set to DEBUG. > > I had a brief look at the source code but was not able to understand > what is going wrong. Searching for that error message on the web did not > produce any useful results. Problem solved by deleting the VM and setting it up from scratch. ;) Yours David -- David Rabel Linux Consultant & Trainer Tel.: +49-1511-5908566 Mail: rabel at b1-systems.de B1 Systems GmbH Osterfeldstra?e 7 / 85088 Vohburg / http://www.b1-systems.de GF: Ralph Dehner / Unternehmenssitz: Vohburg / AG: Ingolstadt,HRB 3537 From ethan.rahn at gmail.com Fri Apr 7 16:45:27 2017 From: ethan.rahn at gmail.com (Ethan Rahn) Date: Thu, 6 Apr 2017 23:45:27 -0700 Subject: Any interest in a patch for setting the syslog facility for the ssh client? In-Reply-To: References: Message-ID: To revive this thread - I filed a bug in bugzilla.mindrot.org ( Bug 2705 - https://bugzilla.mindrot.org/show_bug.cgi?id=2705 ). I have a patch attached to the email that implements this as well. I wasn't able to find a list of coding standards or contribution guidelines for OpenSSH, so please correct me if I'm wrong. I'd also like to thank Jakuje for helping me out with some info on the whitespace standards a few months ago when I posted this on GitHub. Cheers, Ethan On Mon, Jan 9, 2017 at 5:15 PM, Darren Tucker wrote: > On Tue, Jan 10, 2017 at 11:34 AM, Ethan Rahn wrote: > > I recently made a change to the openssh ssh client code to allow > > configuring the client syslog facility to use. I made the change in > > openssh-6.6p1. If there is interest I can port the change to the openssh > > portable github. > > Sounds reasonable. > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > From livingdeadzerg at yandex.ru Fri Apr 7 19:54:31 2017 From: livingdeadzerg at yandex.ru (navern) Date: Fri, 07 Apr 2017 12:54:31 +0300 Subject: Include for sshd_config In-Reply-To: References: <43b80823-096d-1c06-f9f9-3b15b288cd7e@redhat.com> Message-ID: <58E761D7.3000407@yandex.ru> Hello, Afaik there was added Include feature for ssh_config. I want to add this option to sshd_config as well. I think about local patch(i am not sure this will be required for upstream). Code for Include option in readconf.c doesn't look very specific. Is there some reason why this wasn't introduced for sshd_config as well? Maybe someone already have patch for this feature? It would be great because i am pretty awful C programmer. From jjelen at redhat.com Fri Apr 7 22:05:15 2017 From: jjelen at redhat.com (Jakub Jelen) Date: Fri, 7 Apr 2017 14:05:15 +0200 Subject: Include for sshd_config In-Reply-To: <58E761D7.3000407@yandex.ru> References: <43b80823-096d-1c06-f9f9-3b15b288cd7e@redhat.com> <58E761D7.3000407@yandex.ru> Message-ID: <3c1f3237-6b11-85fd-41ab-d77e71d5d325@redhat.com> On 04/07/2017 11:54 AM, navern wrote: > Hello, > > Afaik there was added Include feature for ssh_config. I want to add this > option to sshd_config as well. I think about local patch(i am not sure > this will be required for upstream). > > Code for Include option in readconf.c doesn't look very specific. Is > there some reason why this wasn't introduced for sshd_config as well? > > Maybe someone already have patch for this feature? It would be great > because i am pretty awful C programmer. This is already implemented in the following bugzilla: https://bugzilla.mindrot.org/show_bug.cgi?id=2468 The code gets little bit more complicated because of requirement to re-read the configuration for every incoming connection. Giving a test and comments would be very appreciated. Regards, -- Jakub Jelen Software Engineer Security Technologies Red Hat From dtucker at zip.com.au Fri Apr 7 22:02:03 2017 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 7 Apr 2017 22:02:03 +1000 Subject: Any interest in a patch for setting the syslog facility for the ssh client? In-Reply-To: References: Message-ID: On Fri, Apr 7, 2017 at 4:45 PM, Ethan Rahn wrote: > To revive this thread - I filed a bug in bugzilla.mindrot.org ( Bug 2705 > - https://bugzilla.mindrot.org/show_bug.cgi?id=2705 ). > > I have a patch attached to the email that implements this as well. I > wasn't able to find a list of coding standards or contribution guidelines > for OpenSSH, > In general, the OpenBSD style guide. From the README: Code contribution are welcomed, but please follow the OpenBSD style guidelines[6]. [...] [6] http://man.openbsd.org/style.9 -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From ethan.rahn at gmail.com Sat Apr 8 04:21:33 2017 From: ethan.rahn at gmail.com (Ethan Rahn) Date: Fri, 7 Apr 2017 11:21:33 -0700 Subject: Any interest in a patch for setting the syslog facility for the ssh client? In-Reply-To: References: Message-ID: Darren, Thanks, evidently I need to practice my reading skills. I did some practice on the style guide, and I believe that I have the patch fixed up per the style guidelines. I've attached the new patch to this email for review. Cheers, Ethan On Fri, Apr 7, 2017 at 5:02 AM, Darren Tucker wrote: > On Fri, Apr 7, 2017 at 4:45 PM, Ethan Rahn wrote: > >> To revive this thread - I filed a bug in bugzilla.mindrot.org ( Bug 2705 >> - https://bugzilla.mindrot.org/show_bug.cgi?id=2705 ). >> >> I have a patch attached to the email that implements this as well. I >> wasn't able to find a list of coding standards or contribution guidelines >> for OpenSSH, >> > > In general, the OpenBSD style guide. From the README: > > Code contribution are welcomed, but please follow the OpenBSD > style guidelines[6]. > [...] > [6] http://man.openbsd.org/style.9 > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > From mouring at offwriting.org Sat Apr 8 04:33:58 2017 From: mouring at offwriting.org (Ben Lindstrom) Date: Fri, 07 Apr 2017 13:33:58 -0500 Subject: Any interest in a patch for setting the syslog facility for the ssh client? In-Reply-To: References: Message-ID: <58E7DB96.2060302@offwriting.org> The mailinglist strips out attachments. So either you need to add it to the bug or post it in-line to the email. Ben Ethan Rahn wrote: > Darren, > > Thanks, evidently I need to practice my reading skills. I did some practice > on the style guide, and I believe that I have the patch fixed up per the > style guidelines. I've attached the new patch to this email for review. > > Cheers, > > Ethan > > On Fri, Apr 7, 2017 at 5:02 AM, Darren Tucker wrote: > >> On Fri, Apr 7, 2017 at 4:45 PM, Ethan Rahn wrote: >> >>> To revive this thread - I filed a bug in bugzilla.mindrot.org ( Bug 2705 >>> - https://bugzilla.mindrot.org/show_bug.cgi?id=2705 ). >>> >>> I have a patch attached to the email that implements this as well. I >>> wasn't able to find a list of coding standards or contribution guidelines >>> for OpenSSH, >>> >> In general, the OpenBSD style guide. From the README: >> >> Code contribution are welcomed, but please follow the OpenBSD >> style guidelines[6]. >> [...] >> [6] http://man.openbsd.org/style.9 >> >> -- >> Darren Tucker (dtucker at zip.com.au) >> GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) >> Good judgement comes with experience. Unfortunately, the experience >> usually comes from bad judgement. >> > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From ethan.rahn at gmail.com Sat Apr 8 04:39:17 2017 From: ethan.rahn at gmail.com (Ethan Rahn) Date: Fri, 7 Apr 2017 11:39:17 -0700 Subject: Any interest in a patch for setting the syslog facility for the ssh client? In-Reply-To: <58E7DB96.2060302@offwriting.org> References: <58E7DB96.2060302@offwriting.org> Message-ID: Ben, Thanks for the tip! I've added the patch to Bug 2705 on bugzilla. Cheers, Ethan On Fri, Apr 7, 2017 at 11:33 AM, Ben Lindstrom wrote: > > The mailinglist strips out attachments. So either you need to add it to > the bug or post it in-line to the email. > > Ben > > Ethan Rahn wrote: > > Darren, > > Thanks, evidently I need to practice my reading skills. I did some practice > on the style guide, and I believe that I have the patch fixed up per the > style guidelines. I've attached the new patch to this email for review. > > Cheers, > > Ethan > > On Fri, Apr 7, 2017 at 5:02 AM, Darren Tucker wrote: > > > On Fri, Apr 7, 2017 at 4:45 PM, Ethan Rahn wrote: > > > To revive this thread - I filed a bug in bugzilla.mindrot.org ( Bug 2705 > - https://bugzilla.mindrot.org/show_bug.cgi?id=2705 ). > > I have a patch attached to the email that implements this as well. I > wasn't able to find a list of coding standards or contribution guidelines > for OpenSSH, > > > In general, the OpenBSD style guide. From the README: > > Code contribution are welcomed, but please follow the OpenBSD > style guidelines[6]. > [...] > [6] http://man.openbsd.org/style.9 > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > > > _______________________________________________ > openssh-unix-dev mailing listopenssh-unix-dev at mindrot.orghttps://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > > From livingdeadzerg at yandex.ru Tue Apr 11 06:02:41 2017 From: livingdeadzerg at yandex.ru (navern) Date: Mon, 10 Apr 2017 23:02:41 +0300 Subject: Include for sshd_config In-Reply-To: <3c1f3237-6b11-85fd-41ab-d77e71d5d325@redhat.com> References: <43b80823-096d-1c06-f9f9-3b15b288cd7e@redhat.com> <58E761D7.3000407@yandex.ru> <3c1f3237-6b11-85fd-41ab-d77e71d5d325@redhat.com> Message-ID: <58EBE4E1.307@yandex.ru> On 07.04.2017 15:05, Jakub Jelen wrote: > On 04/07/2017 11:54 AM, navern wrote: >> Hello, >> >> Afaik there was added Include feature for ssh_config. I want to add this >> option to sshd_config as well. I think about local patch(i am not sure >> this will be required for upstream). >> >> Code for Include option in readconf.c doesn't look very specific. Is >> there some reason why this wasn't introduced for sshd_config as well? >> >> Maybe someone already have patch for this feature? It would be great >> because i am pretty awful C programmer. > > This is already implemented in the following bugzilla: > > https://bugzilla.mindrot.org/show_bug.cgi?id=2468 > > The code gets little bit more complicated because of requirement to > re-read the configuration for every incoming connection. Giving a test > and comments would be very appreciated. > > Regards, Hello, I've fixed this patch a little to apply it to version 7.4p1. I will test it in following week and let you know about results. Thanks for the patch. From openssh at tlinx.org Sun Apr 16 01:59:52 2017 From: openssh at tlinx.org (L A Walsh) Date: Sat, 15 Apr 2017 08:59:52 -0700 Subject: How to create 'root' user on Windows? Message-ID: <58F24378.2070202@tlinx.org> I'm running cygwin on windows, and the new version of ssh is complaining about /var/empty, saying it needs to be owned by root and not group or world writable. Since there is no root on windows, what is it wanting? Tried the account called 'root' (Administrator on my machine), but it didn't like that: > llg -a /var/empty total 4 drwx------+ 1 root Administrators 0 Oct 11 2014 ./ Also tried changing root to UID=0 in cygwin, but it didn't like that either: > llg -an /var/empty total 4 drwx------+ 1 0 544 0 Oct 11 2014 ./ So what is it wanting? Is there a way to turn off config checking akin to sendmail's "dontblamesendmail" option? Thanks! -l From schwarze at usta.de Tue Apr 18 00:41:41 2017 From: schwarze at usta.de (Ingo Schwarze) Date: Mon, 17 Apr 2017 16:41:41 +0200 Subject: testsuite error on Solaris 2.6 In-Reply-To: <1187550e-298f-ed2f-c9e0-20c2f38e3d01@jupiterrise.com> References: <20170402134313.GD79932@athene.usta.de> <1187550e-298f-ed2f-c9e0-20c2f38e3d01@jupiterrise.com> Message-ID: <20170417144141.GA32426@athene.usta.de> Hi Tom, Tom G. Christensen wrote on Sun, Apr 02, 2017 at 05:33:33PM +0200: > For reference this is the patch I made and included in my Solaris 2.6 > openssh packages: > https://github.com/tgc/tgcware-for-solaris/blob/master/openssh/src/0001-Treat-empty-codeset-value-as-ascii.patch [...] > Note that in 7.5p1, '646' was added as an additional alias (which happened > to cover not only NetBSD but also Solaris 7 and later.) at long last, i committed the patch appended below to OpenBSD. By the standard OpenSSH-portable development process, i assume that it is likely to also show up in the next OpenSSH-portable release. Thanks again for reporting, Ingo CVSROOT: /cvs Module name: src Changes by: schwarze at cvs.openbsd.org 2017/04/17 08:31:23 Modified files: usr.bin/ssh : utf8.c Log message: Recognize nl_langinfo(CODESET) return values "646" and "" as aliases for "US-ASCII", useful for different versions of NetBSD and Solaris. Found by dtucker@ and by Tom G. Christensen . OK dtucker@ deraadt@ Index: utf8.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/utf8.c,v retrieving revision 1.5 retrieving revision 1.6 diff -u -p -r1.5 -r1.6 --- utf8.c 19 Feb 2017 00:10:57 -0000 1.5 +++ utf8.c 17 Apr 2017 14:31:23 -0000 1.6 @@ -1,4 +1,4 @@ -/* $OpenBSD: utf8.c,v 1.5 2017/02/19 00:10:57 djm Exp $ */ +/* $OpenBSD: utf8.c,v 1.6 2017/04/17 14:31:23 schwarze Exp $ */ /* * Copyright (c) 2016 Ingo Schwarze * @@ -52,7 +52,8 @@ dangerous_locale(void) { loc = nl_langinfo(CODESET); return strcmp(loc, "US-ASCII") != 0 && strcmp(loc, "UTF-8") != 0 && - strcmp(loc, "ANSI_X3.4-1968") != 0; + strcmp(loc, "ANSI_X3.4-1968") != 0 && strcmp(loc, "646") != 0 && + strcmp(loc, "") != 0; } static int From vinschen at redhat.com Tue Apr 18 19:18:19 2017 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 18 Apr 2017 11:18:19 +0200 Subject: How to create 'root' user on Windows? In-Reply-To: <58F24378.2070202@tlinx.org> References: <58F24378.2070202@tlinx.org> Message-ID: <20170418091819.GA30642@calimero.vinschen.de> On Apr 15 08:59, L A Walsh wrote: > I'm running cygwin on windows, and the new version of ssh > is complaining about /var/empty, saying it needs to be owned > by root and not group or world writable. > > Since there is no root on windows, what is it > wanting? /var/empty should be owned by the same user account running the sshd service, usually the "cyg_server" account. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From livingdeadzerg at yandex.ru Thu Apr 20 03:02:21 2017 From: livingdeadzerg at yandex.ru (navern) Date: Wed, 19 Apr 2017 20:02:21 +0300 Subject: Include for sshd_config In-Reply-To: <58EBE4E1.307@yandex.ru> References: <43b80823-096d-1c06-f9f9-3b15b288cd7e@redhat.com> <58E761D7.3000407@yandex.ru> <3c1f3237-6b11-85fd-41ab-d77e71d5d325@redhat.com> <58EBE4E1.307@yandex.ru> Message-ID: <58F7981D.10805@yandex.ru> On 10.04.2017 23:02, navern wrote: > > On 07.04.2017 15:05, Jakub Jelen wrote: >> On 04/07/2017 11:54 AM, navern wrote: >>> Hello, >>> >>> Afaik there was added Include feature for ssh_config. I want to add >>> this >>> option to sshd_config as well. I think about local patch(i am not sure >>> this will be required for upstream). >>> >>> Code for Include option in readconf.c doesn't look very specific. Is >>> there some reason why this wasn't introduced for sshd_config as well? >>> >>> Maybe someone already have patch for this feature? It would be great >>> because i am pretty awful C programmer. >> >> This is already implemented in the following bugzilla: >> >> https://bugzilla.mindrot.org/show_bug.cgi?id=2468 >> >> The code gets little bit more complicated because of requirement to >> re-read the configuration for every incoming connection. Giving a >> test and comments would be very appreciated. >> >> Regards, > Hello, > > I've fixed this patch a little to apply it to version 7.4p1. I will > test it in following week and let you know about results. Thanks for > the patch. Hi, I've been testing this for about a week on 150 servers and everything running fine. I hadn't seen any bugs. Thanks! From nkadel at gmail.com Thu Apr 20 21:56:48 2017 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 20 Apr 2017 07:56:48 -0400 Subject: Include for sshd_config In-Reply-To: <58F7981D.10805@yandex.ru> References: <43b80823-096d-1c06-f9f9-3b15b288cd7e@redhat.com> <58E761D7.3000407@yandex.ru> <3c1f3237-6b11-85fd-41ab-d77e71d5d325@redhat.com> <58EBE4E1.307@yandex.ru> <58F7981D.10805@yandex.ru> Message-ID: On Wed, Apr 19, 2017 at 1:02 PM, navern wrote: > On 10.04.2017 23:02, navern wrote: >> >> >> On 07.04.2017 15:05, Jakub Jelen wrote: >>> >>> On 04/07/2017 11:54 AM, navern wrote: >>>> >>>> Hello, >>>> >>>> Afaik there was added Include feature for ssh_config. I want to add this >>>> option to sshd_config as well. I think about local patch(i am not sure >>>> this will be required for upstream). >>>> >>>> Code for Include option in readconf.c doesn't look very specific. Is >>>> there some reason why this wasn't introduced for sshd_config as well? >>>> >>>> Maybe someone already have patch for this feature? It would be great >>>> because i am pretty awful C programmer. >>> >>> >>> This is already implemented in the following bugzilla: >>> >>> https://bugzilla.mindrot.org/show_bug.cgi?id=2468 >>> >>> The code gets little bit more complicated because of requirement to >>> re-read the configuration for every incoming connection. Giving a test and >>> comments would be very appreciated. >>> >>> Regards, >> >> Hello, >> >> I've fixed this patch a little to apply it to version 7.4p1. I will test >> it in following week and let you know about results. Thanks for the patch. > > > Hi, > > I've been testing this for about a week on 150 servers and everything > running fine. I hadn't seen any bugs. Thanks! What is the performance penalty for incoming connectons? Have you any sense of this? I'm slightly leery of this approach. I've encountered numerous systems that sought to split out subconfigurations sensibly, such as /etc/cron.d for cron jobs, /et/sudoers.d for sudo access, and individual zone files for DNS configurations. Some of them have worked very well, but some of them which parse all files for all connections have been vulnerable to a single typo in a single included file destroying the *whole* system. If you do that to the SSH which is used for remote system management, well, you can suddenly be up a nasty creek without a paddle unless you're as paranoid as I've sometimes been and run a second daemon with a separate set of config files with very restrictive access for emergencies. It can be exacerbated if you have a system configuration tool, such as ansible or puppet or chef, which can modify your OpenSSH config without you're being connected on a live SSH session which is still active and might be used for salvage if you screw up a file. Is there any available tool with this for pre-evaluating the resulting sshd_config for fatal errors? I'm not demanding: I'm thinking "that could be really, really useful". From scott_n at xypro.com Fri Apr 21 01:00:40 2017 From: scott_n at xypro.com (Scott Neugroschl) Date: Thu, 20 Apr 2017 15:00:40 +0000 Subject: Include for sshd_config In-Reply-To: References: <43b80823-096d-1c06-f9f9-3b15b288cd7e@redhat.com> <58E761D7.3000407@yandex.ru> <3c1f3237-6b11-85fd-41ab-d77e71d5d325@redhat.com> <58EBE4E1.307@yandex.ru> <58F7981D.10805@yandex.ru> Message-ID: On Wed, Apr 19, 2017 at 1:02 PM, navern wrote: > Is there any available tool with this for pre-evaluating the resulting sshd_config for fatal errors? I'm not demanding: I'm thinking "that could be really, really useful". What's wrong with "sshd -t"? From nkadel at gmail.com Fri Apr 21 15:49:12 2017 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Fri, 21 Apr 2017 01:49:12 -0400 Subject: Include for sshd_config In-Reply-To: References: <43b80823-096d-1c06-f9f9-3b15b288cd7e@redhat.com> <58E761D7.3000407@yandex.ru> <3c1f3237-6b11-85fd-41ab-d77e71d5d325@redhat.com> <58EBE4E1.307@yandex.ru> <58F7981D.10805@yandex.ru> Message-ID: On Thu, Apr 20, 2017 at 11:00 AM, Scott Neugroschl wrote: > > On Wed, Apr 19, 2017 at 1:02 PM, navern wrote: > >> Is there any available tool with this for pre-evaluating the resulting sshd_config for fatal errors? I'm not demanding: I'm thinking "that could be really, really useful". > > What's wrong with "sshd -t"? Good reminder, thank you. I'm still slightly concerned about deploying a new, broken configuration and being unable to get in to fix it. You'd have to *stage* the deployment, first into a test environment against which you can run "sshd -t", and then deploy them robustly and without dangling bits to be sure that the test environment correlated well to the production enviornment. But that's for fascist control in environments where you can't get hands and eyes at the keyboard on the local system, and especially if you're getting complex with your "include" files. From livingdeadzerg at yandex.ru Fri Apr 21 20:47:02 2017 From: livingdeadzerg at yandex.ru (navern) Date: Fri, 21 Apr 2017 13:47:02 +0300 Subject: Include for sshd_config In-Reply-To: References: <43b80823-096d-1c06-f9f9-3b15b288cd7e@redhat.com> <58E761D7.3000407@yandex.ru> <3c1f3237-6b11-85fd-41ab-d77e71d5d325@redhat.com> <58EBE4E1.307@yandex.ru> <58F7981D.10805@yandex.ru> Message-ID: <58F9E326.4060204@yandex.ru> On 21.04.2017 08:49, Nico Kadel-Garcia wrote: > On Thu, Apr 20, 2017 at 11:00 AM, Scott Neugroschl wrote: >> On Wed, Apr 19, 2017 at 1:02 PM, navern wrote: >> >>> Is there any available tool with this for pre-evaluating the resulting sshd_config for fatal errors? I'm not demanding: I'm thinking "that could be really, really useful". >> What's wrong with "sshd -t"? > Good reminder, thank you. > > I'm still slightly concerned about deploying a new, broken > configuration and being unable to get in to fix it. You'd have to > *stage* the deployment, first into a test environment against which > you can run "sshd -t", and then deploy them robustly and without > dangling bits to be sure that the test environment correlated well to > the production enviornment. But that's for fascist control in > environments where you can't get hands and eyes at the keyboard on the > local system, and especially if you're getting complex with your > "include" files. > Hello, Actually i can't see difference between "no include and typo brokes whole sshd server" and "include files and typo in include brokes whole sshd server". Other questions related more to configuration/system management. With this include feature i manage as following: 1) main /etc/ssh/sshd_config is managed by ansible automatic configuration 2) include file is managed by python script on specific server(fills dynamic information) From jjelen at redhat.com Mon Apr 24 16:46:28 2017 From: jjelen at redhat.com (Jakub Jelen) Date: Mon, 24 Apr 2017 08:46:28 +0200 Subject: Include for sshd_config In-Reply-To: References: <43b80823-096d-1c06-f9f9-3b15b288cd7e@redhat.com> <58E761D7.3000407@yandex.ru> <3c1f3237-6b11-85fd-41ab-d77e71d5d325@redhat.com> <58EBE4E1.307@yandex.ru> <58F7981D.10805@yandex.ru> Message-ID: On 04/20/2017 01:56 PM, Nico Kadel-Garcia wrote: > On Wed, Apr 19, 2017 at 1:02 PM, navern wrote: >> On 10.04.2017 23:02, navern wrote: >> >> >> Hi, >> >> I've been testing this for about a week on 150 servers and everything >> running fine. I hadn't seen any bugs. Thanks! > > What is the performance penalty for incoming connectons? Have you any > sense of this? Quite much none if I remember well how does the code look like. It should cache the included files the same way as it did before with the main sshd_config. It is just parsing more lines if there is more in the files included. Also the random-typos should be caught during the startup/restart, not per-connection because of the caching. -- Jakub Jelen Software Engineer Security Technologies Red Hat From jjelen at redhat.com Mon Apr 24 17:49:52 2017 From: jjelen at redhat.com (Jakub Jelen) Date: Mon, 24 Apr 2017 09:49:52 +0200 Subject: seccomp filter for ppc64le in FIPS mode Message-ID: Hello all, OpenSSL is using socket() calls (in FIPS mode) when handling ECDSA keys in privsep child. The socket() syscall is already denied in the seccomp filter, but in ppc64le kernel, it is implemented using socketcall() syscall, which is not denied yet (only SYS_SHUTDOWN is allowed) and therefore fails hard. See attached patch with proposed patch (deny is intentionally after allowing the SYS_SHUTDOWN). Can we have it fixed in OpenSSH portable? Regards, -- Jakub Jelen Software Engineer Security Technologies Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-7.4p1-sandbox-ppc64le.patch Type: text/x-patch Size: 461 bytes Desc: not available URL: From dtucker at zip.com.au Mon Apr 24 19:47:20 2017 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 24 Apr 2017 19:47:20 +1000 Subject: seccomp filter for ppc64le in FIPS mode In-Reply-To: References: Message-ID: On Mon, Apr 24, 2017 at 5:49 PM, Jakub Jelen wrote: > [...] > See attached patch with proposed patch (deny is intentionally after > allowing the SYS_SHUTDOWN). Can we have it fixed in OpenSSH portable? > Applied, thanks, also cherry picked onto the 7.5 branch. The diff did not apply cleanly ("__NR_$syscall" vs "$syscall" so I hand-edited it. I don't have access to one of these systems to test so could you please confirm that I got it right? -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From djm at mindrot.org Mon Apr 24 19:58:58 2017 From: djm at mindrot.org (Damien Miller) Date: Mon, 24 Apr 2017 19:58:58 +1000 (AEST) Subject: Include for sshd_config In-Reply-To: <3c1f3237-6b11-85fd-41ab-d77e71d5d325@redhat.com> References: <43b80823-096d-1c06-f9f9-3b15b288cd7e@redhat.com> <58E761D7.3000407@yandex.ru> <3c1f3237-6b11-85fd-41ab-d77e71d5d325@redhat.com> Message-ID: On Fri, 7 Apr 2017, Jakub Jelen wrote: > On 04/07/2017 11:54 AM, navern wrote: > > Hello, > > > > Afaik there was added Include feature for ssh_config. I want to add this > > option to sshd_config as well. I think about local patch(i am not sure > > this will be required for upstream). > > > > Code for Include option in readconf.c doesn't look very specific. Is > > there some reason why this wasn't introduced for sshd_config as well? > > > > Maybe someone already have patch for this feature? It would be great > > because i am pretty awful C programmer. > > This is already implemented in the following bugzilla: > > https://bugzilla.mindrot.org/show_bug.cgi?id=2468 > > The code gets little bit more complicated because of requirement to re-read > the configuration for every incoming connection. Giving a test and comments > would be very appreciated. I'll update the bug, but IMO re-reading config at runtime is a significant behaviour change and is probably unacceptable. We go through some hassle wrt re-execution to ensure that the configuration sshd is started with is the one that it. To do otherwise is IMO inviting surprise and trouble for administrators. -d From jjelen at redhat.com Mon Apr 24 20:04:12 2017 From: jjelen at redhat.com (Jakub Jelen) Date: Mon, 24 Apr 2017 12:04:12 +0200 Subject: seccomp filter for ppc64le in FIPS mode In-Reply-To: References: Message-ID: On 04/24/2017 11:47 AM, Darren Tucker wrote: > On Mon, Apr 24, 2017 at 5:49 PM, Jakub Jelen > wrote: > > [...] > See attached patch with proposed patch (deny is intentionally after > allowing the SYS_SHUTDOWN). Can we have it fixed in OpenSSH portable? > > > Applied, thanks, also cherry picked onto the 7.5 branch. > > The diff did not apply cleanly ("__NR_$syscall" vs "$syscall" so I > hand-edited it. I don't have access to one of these systems to test so > could you please confirm that I got it right? If I see right, you put there two ss in socketcall [1] After fixing that it builds just fine with this line: + SC_DENY(__NR_socketcall, EACCES), [1] https://github.com/openssh/openssh-portable/commit/8b0eee14 Thanks, -- Jakub Jelen Software Engineer Security Technologies Red Hat From jjelen at redhat.com Mon Apr 24 20:07:46 2017 From: jjelen at redhat.com (Jakub Jelen) Date: Mon, 24 Apr 2017 12:07:46 +0200 Subject: Include for sshd_config In-Reply-To: References: <43b80823-096d-1c06-f9f9-3b15b288cd7e@redhat.com> <58E761D7.3000407@yandex.ru> <3c1f3237-6b11-85fd-41ab-d77e71d5d325@redhat.com> Message-ID: <8d93aa29-c724-c84b-8ac4-6589193a06db@redhat.com> On 04/24/2017 11:58 AM, Damien Miller wrote: > On Fri, 7 Apr 2017, Jakub Jelen wrote: > >> On 04/07/2017 11:54 AM, navern wrote: >>> Hello, >>> >>> Afaik there was added Include feature for ssh_config. I want to add this >>> option to sshd_config as well. I think about local patch(i am not sure >>> this will be required for upstream). >>> >>> Code for Include option in readconf.c doesn't look very specific. Is >>> there some reason why this wasn't introduced for sshd_config as well? >>> >>> Maybe someone already have patch for this feature? It would be great >>> because i am pretty awful C programmer. >> >> This is already implemented in the following bugzilla: >> >> https://bugzilla.mindrot.org/show_bug.cgi?id=2468 >> >> The code gets little bit more complicated because of requirement to re-read >> the configuration for every incoming connection. Giving a test and comments >> would be very appreciated. > > I'll update the bug, but IMO re-reading config at runtime is a significant > behaviour change and is probably unacceptable. We go through some hassle > wrt re-execution to ensure that the configuration sshd is started with is > the one that it. > > To do otherwise is IMO inviting surprise and trouble for administrators. That was just wrongly worded. The configuration file is not re-read from filesystem with every connection, but I meant the need to re-parse the file for every connection (which does not exists for client config). Regards, -- Jakub Jelen Software Engineer Security Technologies Red Hat From nkadel at gmail.com Mon Apr 24 20:18:41 2017 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Mon, 24 Apr 2017 06:18:41 -0400 Subject: Include for sshd_config In-Reply-To: <58F9E326.4060204@yandex.ru> References: <43b80823-096d-1c06-f9f9-3b15b288cd7e@redhat.com> <58E761D7.3000407@yandex.ru> <3c1f3237-6b11-85fd-41ab-d77e71d5d325@redhat.com> <58EBE4E1.307@yandex.ru> <58F7981D.10805@yandex.ru> <58F9E326.4060204@yandex.ru> Message-ID: On Fri, Apr 21, 2017 at 6:47 AM, navern wrote: > On 21.04.2017 08:49, Nico Kadel-Garcia wrote: >> >> On Thu, Apr 20, 2017 at 11:00 AM, Scott Neugroschl >> wrote: >>> >>> On Wed, Apr 19, 2017 at 1:02 PM, navern wrote: >>> >>>> Is there any available tool with this for pre-evaluating the resulting >>>> sshd_config for fatal errors? I'm not demanding: I'm thinking "that could be >>>> really, really useful". >>> >>> What's wrong with "sshd -t"? >> >> Good reminder, thank you. >> >> I'm still slightly concerned about deploying a new, broken >> configuration and being unable to get in to fix it. You'd have to >> *stage* the deployment, first into a test environment against which >> you can run "sshd -t", and then deploy them robustly and without >> dangling bits to be sure that the test environment correlated well to >> the production enviornment. But that's for fascist control in >> environments where you can't get hands and eyes at the keyboard on the >> local system, and especially if you're getting complex with your >> "include" files. >> > Hello, > > Actually i can't see difference between "no include and typo brokes whole > sshd server" and "include files and typo in include brokes whole sshd > server". Other questions related more to configuration/system management. It's a pretty similar problem. The danger is that if you put *other* files into the mix, controlled by other tools, it becomes more difficult to keep control of verification. If it's only one file, it's easier to keep control of and check. > With this include feature i manage as following: > 1) main /etc/ssh/sshd_config is managed by ansible automatic configuration > 2) include file is managed by python script on specific server(fills dynamic > information) How do you track and revert broken versions? Or do you have so much trust in your configurations that you're sure they can't break things? I ran into this headlong with the chef cookbook for openssh. It can store configuration information among "roles", among "node" settings, and among "environments", which it combines to assemble into the sshd_config file published. A subtle error in any one file where settings are stored can propagate at configuration resetting time and break the system, and become quite confusing to track down. The flexibility provided is powerful and potentially quite useful. But it comes with risks of debilitating errors. My personal favorite for such errors in the chef cookbook are where you accidentally set the same attribute multiple times with different values, or especially if you provide multiple ruby hashes with the same name and they get merged instead of replacing one with the other. From jjelen at redhat.com Mon Apr 24 22:26:44 2017 From: jjelen at redhat.com (Jakub Jelen) Date: Mon, 24 Apr 2017 14:26:44 +0200 Subject: PKCS#11 URIs in OpenSSH Message-ID: Hello all, as PKCS#11 URI became standard (RFC 7512), it would be good to be able to specify the keys using this notation in openssh. So far I implemented the minimal subset of this standard allowing to specify the URI for the ssh tool, in ssh_config and to work with ssh-agent. It does not bring any new dependency, provides unit and regress tests (while fixing agent-pkcs11 regress test). The code is on github and ready for comments/reviews (some details will need to be adjusted): https://github.com/openssh/openssh-portable/compare/master...Jakuje:jjelen-pkcs11 I will fill a bugzilla later. I would be grateful for your ideas, comments or reviews for this feature. Other useful parts of RFC, that could be implemented would be a way to provide a PIN or a PIN source for the token, other ways of providing module-path (module-name). Regards, -- Jakub Jelen Software Engineer Security Technologies Red Hat From djm at mindrot.org Mon Apr 24 22:39:49 2017 From: djm at mindrot.org (Damien Miller) Date: Mon, 24 Apr 2017 22:39:49 +1000 (AEST) Subject: Include for sshd_config In-Reply-To: <8d93aa29-c724-c84b-8ac4-6589193a06db@redhat.com> References: <43b80823-096d-1c06-f9f9-3b15b288cd7e@redhat.com> <58E761D7.3000407@yandex.ru> <3c1f3237-6b11-85fd-41ab-d77e71d5d325@redhat.com> <8d93aa29-c724-c84b-8ac4-6589193a06db@redhat.com> Message-ID: On Mon, 24 Apr 2017, Jakub Jelen wrote: > > I'll update the bug, but IMO re-reading config at runtime is a significant > > behaviour change and is probably unacceptable. We go through some hassle > > wrt re-execution to ensure that the configuration sshd is started with is > > the one that it. > > > > To do otherwise is IMO inviting surprise and trouble for administrators. > > That was just wrongly worded. The configuration file is not re-read from > filesystem with every connection, but I meant the need to re-parse the file > for every connection (which does not exists for client config). oh, ok - I withdraw that objection then :) From uri at ll.mit.edu Tue Apr 25 03:37:40 2017 From: uri at ll.mit.edu (Blumenthal, Uri - 0553 - MITLL) Date: Mon, 24 Apr 2017 17:37:40 +0000 Subject: PKCS#11 URIs in OpenSSH In-Reply-To: References: Message-ID: PKCS11 URI support is a very good thing to add. I?d like the PRs separated ? e.g., one for PKCS11 URI, and one for ALWAYS_AUTHENTICATE. ? Regards, Uri On 4/24/17, 8:26 AM, "openssh-unix-dev on behalf of Jakub Jelen" wrote: Hello all, as PKCS#11 URI became standard (RFC 7512), it would be good to be able to specify the keys using this notation in openssh. So far I implemented the minimal subset of this standard allowing to specify the URI for the ssh tool, in ssh_config and to work with ssh-agent. It does not bring any new dependency, provides unit and regress tests (while fixing agent-pkcs11 regress test). The code is on github and ready for comments/reviews (some details will need to be adjusted): https://github.com/openssh/openssh-portable/compare/master...Jakuje:jjelen-pkcs11 I will fill a bugzilla later. I would be grateful for your ideas, comments or reviews for this feature. Other useful parts of RFC, that could be implemented would be a way to provide a PIN or a PIN source for the token, other ways of providing module-path (module-name). Regards, -- Jakub Jelen Software Engineer Security Technologies Red Hat _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 5211 bytes Desc: not available URL: From ethan.rahn at gmail.com Tue Apr 25 05:38:06 2017 From: ethan.rahn at gmail.com (Ethan Rahn) Date: Mon, 24 Apr 2017 12:38:06 -0700 Subject: Any interest in a patch for setting the syslog facility for the ssh client? In-Reply-To: References: <58E7DB96.2060302@offwriting.org> Message-ID: Hello, I wanted to check back in. It doesn't look like anyone has commented on the patch. Is there someone I should prod to get this looked at? Cheers, Ethan On Fri, Apr 7, 2017 at 11:39 AM, Ethan Rahn wrote: > Ben, > > Thanks for the tip! I've added the patch to Bug 2705 on bugzilla. > > Cheers, > > Ethan > > On Fri, Apr 7, 2017 at 11:33 AM, Ben Lindstrom > wrote: > >> >> The mailinglist strips out attachments. So either you need to add it to >> the bug or post it in-line to the email. >> >> Ben >> >> Ethan Rahn wrote: >> >> Darren, >> >> Thanks, evidently I need to practice my reading skills. I did some practice >> on the style guide, and I believe that I have the patch fixed up per the >> style guidelines. I've attached the new patch to this email for review. >> >> Cheers, >> >> Ethan >> >> On Fri, Apr 7, 2017 at 5:02 AM, Darren Tucker wrote: >> >> >> On Fri, Apr 7, 2017 at 4:45 PM, Ethan Rahn wrote: >> >> >> To revive this thread - I filed a bug in bugzilla.mindrot.org ( Bug 2705 >> - https://bugzilla.mindrot.org/show_bug.cgi?id=2705 ). >> >> I have a patch attached to the email that implements this as well. I >> wasn't able to find a list of coding standards or contribution guidelines >> for OpenSSH, >> >> >> In general, the OpenBSD style guide. From the README: >> >> Code contribution are welcomed, but please follow the OpenBSD >> style guidelines[6]. >> [...] >> [6] http://man.openbsd.org/style.9 >> >> -- >> Darren Tucker (dtucker at zip.com.au) >> GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) >> Good judgement comes with experience. Unfortunately, the experience >> usually comes from bad judgement. >> >> >> _______________________________________________ >> openssh-unix-dev mailing listopenssh-unix-dev at mindrot.orghttps://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> >> >> > From dtucker at zip.com.au Tue Apr 25 08:37:00 2017 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 25 Apr 2017 08:37:00 +1000 Subject: seccomp filter for ppc64le in FIPS mode In-Reply-To: References: Message-ID: On Mon, Apr 24, 2017 at 8:04 PM, Jakub Jelen wrote: > [...] > If I see right, you put there two ss in socketcall [1] > Oops, indeed I did. Fixed, thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From ethan.rahn at gmail.com Tue Apr 25 09:06:24 2017 From: ethan.rahn at gmail.com (Ethan Rahn) Date: Mon, 24 Apr 2017 16:06:24 -0700 Subject: Any interest in a patch for setting the syslog facility for the ssh client? In-Reply-To: References: <58E7DB96.2060302@offwriting.org> Message-ID: Awesome, thank you! On Mon, Apr 24, 2017 at 4:01 PM, Darren Tucker wrote: > On Tue, Apr 25, 2017 at 5:38 AM, Ethan Rahn wrote: > >> Hello, >> >> I wanted to check back in. It doesn't look like anyone has commented on >> the >> patch. Is there someone I should prod to get this looked at? >> > > Sorry, it came in just as we were prepping for the 7.5 release and we > generally only take bug fixes at that point. I've added it to the list for > 7.6. > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > From dtucker at zip.com.au Tue Apr 25 09:01:58 2017 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 25 Apr 2017 09:01:58 +1000 Subject: Any interest in a patch for setting the syslog facility for the ssh client? In-Reply-To: References: <58E7DB96.2060302@offwriting.org> Message-ID: On Tue, Apr 25, 2017 at 5:38 AM, Ethan Rahn wrote: > Hello, > > I wanted to check back in. It doesn't look like anyone has commented on the > patch. Is there someone I should prod to get this looked at? > Sorry, it came in just as we were prepping for the 7.5 release and we generally only take bug fixes at that point. I've added it to the list for 7.6. -- Darren Tucker (dtucker at zip.com.au) GPG key 11EAA6FA / A86E 3E07 5B19 5880 E860 37F4 9357 ECEF 11EA A6FA (new) Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From jjelen at redhat.com Tue Apr 25 17:30:51 2017 From: jjelen at redhat.com (Jakub Jelen) Date: Tue, 25 Apr 2017 09:30:51 +0200 Subject: PKCS#11 URIs in OpenSSH In-Reply-To: References: Message-ID: <6c65e9be-05dd-4662-83c9-d1bca6a688b5@redhat.com> On 04/24/2017 07:37 PM, Blumenthal, Uri - 0553 - MITLL wrote: > PKCS11 URI support is a very good thing to add. > > I?d like the PRs separated ? e.g., one for PKCS11 URI, and one for ALWAYS_AUTHENTICATE. Yes, the ALWAYS_AUTHENTICATE check is a separate feature already filled as a bugzilla 2638: https://bugzilla.mindrot.org/show_bug.cgi?id=2638 It is just in the same branch (with relation to PKCS#11 improvements) and one does not depend on the other. Jakub From gbdj at gbdj.ru Wed Apr 26 13:00:16 2017 From: gbdj at gbdj.ru (Anton Worshevsky) Date: Wed, 26 Apr 2017 07:00:16 +0400 Subject: sshd: SSH_CLIENT_CERT and SSH_CLIENT_PUBKEY env variables Message-ID: <20170426070016.3e5c9d91@beer.gbdj.ru> Hello, There are environment variables SSH_CLIENT and SSH_CONNECTION with information about client of current session. I want to implement new variables with info about credentials used for session authentication. Such as: SSH_CLIENT_CERT SSH_CLIENT_CERT_ID SSH_CLIENT_CERT_PRINCIPALS SSH_CLIENT_PUBKEY SSH_CLIENT_PUBKEY_FINGERPRINT Some of that information available in logs but not inside the session. Is there good reason why it's not implemented yet? Do i need to hold myself from writing it? =) -- Anton Worshevsky -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 163 bytes Desc: not available URL: From jjelen at redhat.com Wed Apr 26 18:52:07 2017 From: jjelen at redhat.com (Jakub Jelen) Date: Wed, 26 Apr 2017 10:52:07 +0200 Subject: sshd: SSH_CLIENT_CERT and SSH_CLIENT_PUBKEY env variables In-Reply-To: <20170426070016.3e5c9d91@beer.gbdj.ru> References: <20170426070016.3e5c9d91@beer.gbdj.ru> Message-ID: On 04/26/2017 05:00 AM, Anton Worshevsky wrote: > Hello, > > There are environment variables SSH_CLIENT and SSH_CONNECTION > with information about client of current session. > > I want to implement new variables with info about credentials used for session authentication. > Such as: > > SSH_CLIENT_CERT > SSH_CLIENT_CERT_ID > SSH_CLIENT_CERT_PRINCIPALS > > SSH_CLIENT_PUBKEY > SSH_CLIENT_PUBKEY_FINGERPRINT > > Some of that information available in logs but not inside the session. > Is there good reason why it's not implemented yet? > Do i need to hold myself from writing it? =) Hello, very similar thing was already implemented by and waits for review, more use cases or higher interest by users: https://bugzilla.mindrot.org/show_bug.cgi?id=2408 This creates variables SSH_USER_AUTH which contains all the successfully used authentication methods with all the needed information. It also provides configuration options to expose these information to PAM (for possible additional authentication methods outside of SSH) or to user session. Rather than implementing something new, it would be better to work on improving this feature to suit your needs and merging it upstream. Regards, -- Jakub Jelen Software Engineer Security Technologies Red Hat From martino87rm at gmail.com Fri Apr 28 03:27:39 2017 From: martino87rm at gmail.com (Martino Io) Date: Thu, 27 Apr 2017 19:27:39 +0200 Subject: Strange identity ordering with sshclient and agent Message-ID: Hello, I have a rather strange problem with a setup where keys are fed to SSH_AGENT and a PAM integration, let me be clear that works flawlessly, the only problem I have is that wherever a key is coming from an agent, the order seems to be messed up, not honouring the -i option: This is the output from a console with the agent disabled and it works as it should, I'm specifying the identity manually here (-i ~/.ssh/id_rsa_laptop) debug1: pubkey_prepare: ssh_get_authentication_socket: Connection refused debug2: key: /home/martino/.ssh/id_rsa_laptop (0x561c908da690), explicit debug2: key: /home/martino/.ssh/id_rsa (0x561c908da9d0) debug3: send packet: type 5 debug3: receive packet: type 6 debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug3: send packet: type 50 debug3: receive packet: type 51 debug1: Authentications that can continue: publickey debug3: start over, passed a different list publickey debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/martino/.ssh/id_rsa_laptop debug3: send_pubkey_test debug3: send packet: type 50 debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 60 debug1: Server accepts key: pkalg ssh-rsa blen 279 debug2: input_userauth_pk_ok And this is the output where the agent is enabled: debug2: key: /home/martino/.ssh/id_rsa (0x55a4dcddd9e0), agent debug2: key: /home/martino/.ssh/id_rsa_laptop (0x55a4dcddd6a0), explicit, agent debug3: send packet: type 5 debug3: receive packet: type 6 debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug3: send packet: type 50 debug3: receive packet: type 51 debug1: Authentications that can continue: publickey debug3: start over, passed a different list publickey debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /home/martino/.ssh/id_rsa debug3: send_pubkey_test debug3: send packet: type 50 debug2: we sent a publickey packet, wait for reply debug3: receive packet: type 60 debug1: Server accepts key: pkalg ssh-rsa blen 279 debug2: input_userauth_pk_ok The settings are stored in ~/.ssh/config and both identities are added correctly to the agent: 2048 SHA256: /home/martino/.ssh/id_rsa (RSA) 2048 SHA256: /home/martino/.ssh/id_rsa_laptop (RSA) The problem lies in the fact that both identities are accepted by the server (id_rsa and id_rsa_laptop) but I need the explicit key to be used first as it has different ACL settings in the server, not sure why it is not working at this point. Any help would be appreciated -- Marcin