From jjelen at redhat.com Thu Oct 1 19:39:01 2015 From: jjelen at redhat.com (Jakub Jelen) Date: Thu, 1 Oct 2015 11:39:01 +0200 Subject: stderr pipe not closed when cancelling session on shared connection In-Reply-To: <20150929165002.GA13961@chaz.gmail.com> References: <20150929165002.GA13961@chaz.gmail.com> Message-ID: <560CFF35.7050904@redhat.com> On 09/29/2015 06:50 PM, Stephane Chazelas wrote: > when investigating an issue with gitolite > (http://thread.gmane.org/gmane.comp.version-control.gitolite/4006) > I realised that when you do > > # Create a master connection > ssh -MnNfS ~/.ssh/ctl localhost > > # Reuse that shared connection to run a command on the host > ssh -S ~/.ssh/ctl localhost 'cat; yes >&2' > > And then press Ctrl-C, sshd does close the stdin and stdout pipe > to the remote shell (so cat returns after seeing eof on stdin), > but not the stderr pipe. > > That next "yes" command does fill up the stderr pipe, and > looking at strace output, at the other end of the pipe, sshd is > not reading from it. > > If I kill that "yes" command, "bash" hangs again trying to write > a "job killed" message on stderr. > > If I kill "bash", I can see sshd returning from a waitpid(), > doing *one* read (of 16384 bytes) from that stderr pipe (put > doesn't do anything with the data read) and closes that last > pipe. > > It seems to me that if sshd is not going to do anything with > that pipe, it should close it as soon as it becomes impossible > to send the data to the client like it does for the stdout pipe. > > In the case of gitolite, gitolite was writing a character to > stderr upon EOF to force a SIGPIPE delivery when the ssh > connection is aborted. While that works for a normal ssh > connection, that does't work for one using a shared connection. > > Reproduced with: > OpenSSH_6.9p1 Debian-2, OpenSSL 1.0.2d 9 Jul 2015 > and > OpenSSH_7.1p1, OpenSSL 1.0.1f 6 Jan 2014 The issue is wider than you describe. There is bug #52 [1] which was causing hang for a long time and fix for this issue brought your described behavior and bug #2071 [2], where is similar reproducer even without connection multiplexing. I was trying to figure out what is going on there and what could be the best solution, but so far without any great success. [1] https://bugzilla.mindrot.org/show_bug.cgi?id=52 [2] https://bugzilla.mindrot.org/show_bug.cgi?id=2071 -- Jakub Jelen Security Technologies Red Hat From adam at jooadam.hu Thu Oct 1 20:06:31 2015 From: adam at jooadam.hu (=?UTF-8?B?Sm/DsyDDgWTDoW0=?=) Date: Thu, 1 Oct 2015 12:06:31 +0200 Subject: ControlMaster auto and stderr Message-ID: Hi, Caleb has posted a message in January last year: https://lists.mindrot.org/pipermail/openssh-unix-dev/2014-January/031975.html I don?t see any replies there, so I would like to bring this up again. I have the exact same setup, and this behaviour is really annoying. Is there anything that can be done about it? Thanks, ?d?m From noreply at simpaticotech.it Wed Oct 7 01:32:17 2015 From: noreply at simpaticotech.it (SimpaticoTech - Offerte) Date: Tue, 6 Oct 2015 16:32:17 +0200 Subject: Tablet MEDIACOM WinPad 10.1 WPW100E 32Gb EDUCATION GARANZIA 2 ANNI Message-ID: <11684399763624200211414@Ghapios-PC> [1][LINK]-[2]SimpaticoTech [3]SimpaticoTech con Microsoft PRONTA CONSEGNA TABLET PER A SCUOLA Tablet MEDIACOM WinPad 10.1 WPW100E 32Gb 10.1 Pollici WiFi Windows 8.1 Pro EDUCATION Tastiera e Custodia incorporati - GARANZIA 2 ANNI Prezzo 165,00EUR Codice MEPA 1983194 [4][1983194_medium.jpg] [5][1983194_medium_3.jpg] PRONTA CONSEGNA PC PER A SCUOLA [6][pcedu.jpg] Tantissime scuole in Italia hanno gi? acquistato con successo i nostri PC Ricondizionati Economici Tutti i nostri PC avranno Windows 10 Pro Gratuitamente! Inoltre dal 1 Luglio tutti i PC sono dotati di Antivirus GDATA gi? installato e con codice di attivazione gratuito per 1 Anno [7] Maggiori info Cerca questi codici che trovi sul portale MEPA: 1449463-SC SOLO PC CON 2GB + WINDOWS 7 o 8.1 PRO Prezzo Euro 80+IVA 1449463-SC-UP SOLO PC CON 4GB + WINDOWS 7 o 8.1 PRO Prezzo Euro 95+IVA 1449463-19-TM-SC PC CON 2GB + WINDOWS 7 o 8.1 PRO + MONITOR 19" + KIT TASTIERA MOUSE E CAVI Prezzo Euro 125+IVA 1449463-19-TM-SC-UP PC CON 4GB + WINDOWS 7 o 8.1 PRO + MONITOR 19" + KIT TASTIERA MOUSE Prezzo Euro 145+IVA Visita il nostro catalogo completo sul portale MEPA nome azienda: "Simpatico Network srl" e PIVA "13221010153" Disponibili anche PC Core i5 - Notebook Core i5 - Tablet con Windows 8.1 Scrivi a questa e-mail lasciando i vostri recapiti e sarete contattati da un nostro esperto per fare un'offerta personalizzata. email: [8]scuola at simpaticotech.it Tel. 895-5698707 9:00-13:00 e 14:00-18:00 Grazie all'accordo con Microsoft la nostra azienda ? unica in Italia a diventare "Microsoft Authorized Refurbisher" questo significa che possiamo rivendere dei computer usati e ricondizionati installando nuovi sistemi operativi Windows 7 oppure 8.1 con licenza d'uso originale e immagine sul hard disk come se fosse un PC nuovo. [9]Microsoft Authorized refurbisher [10][xp_shock.jpg] Se state ancora usando dei computer con Windows XP questo comporta un grosso rischio per la vostra struttura perch? dal 8 aprile 2014 il supporto tecnico per Windows XP non ? pi? disponibile, inclusi gli aggiornamenti automatici per la sicurezza che ti aiutano a proteggere il tuo PC. Inoltre, poich? il numero di produttori hardware e software che continuano a ottimizzare le loro soluzioni per le versioni pi? recenti di Windows ? in costante aumento, sempre pi? app e dispositivi non funzioneranno con Windows XP. SIAMO PRESENTI SUL MEPA E EMETTIAMO FATTURA ELETTRONICA "tutti i loghi e i marchi sono propriet? delle relative case produttrici" ? Copyright 2000-2015 SIMPATICOTECH.IT, All rights reserved Ricevi questa email perch? il tuo indirizzo email risulta iscritto alla nostra mailing list. Se cos? non fosse ci scusiamo! Noi rispettiamo la tua privacy, per non ricevere pi? le nostre email clicca sotto su: [11]Iscriviti [12]Cancellati La presente newsletter ? da considerarsi una comunicazione commerciale. Ai sensi dell'art. 13 del Decreto legislativo 30 giugno 2003, n. 196 (Codice della Privacy) La informiamo che i Suoi dati personali sono utilizzati da Simpatico Network srl per finalita' promozionali e pubblicitarie e, in particolare, per l'invio della nostra newsletter. Il conferimento dei Suoi dati personali, per le indicate finalita', ? una Sua facolta', ma ha il diritto di opporSi alla prosecuzione del trattamento in qualsiasi momento, provvedendo alla cancellazione dei dati da Lei forniti. Lei ? titolare dei diritti di cui all'art. 7 del Codice della Privacy. Il trattamento si svolge, con l'ausilio di mezzi elettronici, nel rispetto delle modalita' che il Codice della Privacy pone a Sua garanzia e, in generale, tutelando i Suoi diritti, liberta' fondamentali e dignita', con particolare riferimento alla riservatezza e all'identita' personale. Il trattamento si svolgera' per il periodo da Te consentito e cessera' a seguito dell'intervenuta cancellazione dei Suoi dati personali, a Te i consentita in qualsiasi momento. I dati personali da Te forniti non sono comunicati a soggetti terzi. Simpatico Network srl ha adottato le misure di sicurezza per il trattamento dei Suoi dati personali previste dagli artt. 33 ss. del Codice della Privacy e dal Disciplinare Tecnico di cui All'allegato B) del medesimo. Simpatico Network srl si impegna, altresi', ad adeguare le suddette misure in modo conforme a quanto stabilito dalle successive modifiche legislative, nonch? in relazione all'evoluzione tecnica del settore e all'esperienza maturata. Simpatico Network srl, con sede operativa in Buccinasco (MI), Via Enrico Fermi 10/6 ? la titolare del trattamento , e a lei competono le decisioni in ordine alle finalita' ed alle modalita' del trattamento dei dati personali. References 1. http://bit.ly/Syjfwl 2. LYNXIMGMAP:file://localhost/tmp/tmpX28YD7.html#FPMap0 3. http://bit.ly/UvNQg9 4. C:\Users\Ghapios\AppData\Local\Temp\~ed_sb_i\www.simpaticotech.it\lista.php?id_macro=1&id_categorie=144&ricerca=MEDIACOM&agente=MAILING 5. C:\Users\Ghapios\AppData\Local\Temp\~ed_sb_i\www.simpaticotech.it\lista.php?id_macro=1&id_categorie=144&ricerca=MEDIACOM&agente=MAILING 6. http://www.simpaticotech.it/pc-per-scuola.php 7. http://www.simpaticotech.it/windows10.php 8. mailto:scuola at simpaticotech.it 9. http://bit.ly/UvNQg9 10. http://www.simpaticotech.it/ 11. mailto:noreply at simpaticotech.it?subject=Subscribe 12. mailto:noreply at simpaticotech.it?subject=Unsubscribe [USEMAP] file://localhost/tmp/tmpX28YD7.html#FPMap0 1. http://on.fb.me/V82GWv 2. http://bit.ly/iFcMxX 3. http://bit.ly/Syjfwl From simon at josefsson.org Thu Oct 8 20:49:43 2015 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 08 Oct 2015 11:49:43 +0200 Subject: [PATCH] Enabling ECDSA in PKCS#11 support for ssh-agent In-Reply-To: (Mathias Brossard's message of "Mon, 28 Sep 2015 01:17:34 -0700") References: Message-ID: <87r3l5u1u0.fsf@latte.josefsson.org> Mathias Brossard writes: > Hi, > > I have made a patch for enabling the use of ECDSA keys in the PKCS#11 > support of ssh-agent which will be of interest to other users. Nice! What would it take to add support for Ed25519 too? Do we need to allocate any new PKCS#11 identifiers? The Gnuk smartcard supports Ed25519 but I don't know if it is common to use it with OpenSSH through PKCS#11 (I would expect it to be used with OpenSSH through GnuPG's gpg-agent). At least it might be useful as a test case. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From deengert at gmail.com Fri Oct 9 00:00:07 2015 From: deengert at gmail.com (Douglas E Engert) Date: Thu, 8 Oct 2015 08:00:07 -0500 Subject: [PATCH] Enabling ECDSA in PKCS#11 support for ssh-agent In-Reply-To: <87r3l5u1u0.fsf@latte.josefsson.org> References: <87r3l5u1u0.fsf@latte.josefsson.org> Message-ID: <561668D7.1020400@gmail.com> On 10/8/2015 4:49 AM, Simon Josefsson wrote: > Mathias Brossard writes: > >> Hi, >> >> I have made a patch for enabling the use of ECDSA keys in the PKCS#11 >> support of ssh-agent which will be of interest to other users. > > Nice! What would it take to add support for Ed25519 too? Do we need to > allocate any new PKCS#11 identifiers? Yes, and PKCS#11 allows for *_VENDOR_SUPPLIED identifiers. But using these can get out of hand. Best to try and get them in the standard. OASIS controls the standard From 14 April 2015: http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.html 2.40 does not define Ed25519. > The Gnuk smartcard supports > Ed25519 but I don't know if it is common to use it with OpenSSH through > PKCS#11 (I would expect it to be used with OpenSSH through GnuPG's > gpg-agent). At least it might be useful as a test case. > > /Simon > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Douglas E. Engert From calderon.thomas at gmail.com Fri Oct 9 00:36:44 2015 From: calderon.thomas at gmail.com (Thomas Calderon) Date: Thu, 8 Oct 2015 14:36:44 +0100 Subject: [PATCH] Enabling ECDSA in PKCS#11 support for ssh-agent In-Reply-To: <561668D7.1020400@gmail.com> References: <87r3l5u1u0.fsf@latte.josefsson.org> <561668D7.1020400@gmail.com> Message-ID: Hi, There is no need to add new mechanism identifiers to use specific curves. This can be done already using the CKM_ECDSA mechanism parameters (see CKA_ECDSA_PARAMS in the standard). Given that the underlying HW or SW tokens supports Ed25519 curves, then you could leverage it even with version 2.20 of the PKCS#11 standard. Cheers, Thomas On Thu, Oct 8, 2015 at 2:00 PM, Douglas E Engert wrote: > > > On 10/8/2015 4:49 AM, Simon Josefsson wrote: > >> Mathias Brossard writes: >> >> Hi, >>> >>> I have made a patch for enabling the use of ECDSA keys in the PKCS#11 >>> support of ssh-agent which will be of interest to other users. >>> >> >> Nice! What would it take to add support for Ed25519 too? Do we need to >> allocate any new PKCS#11 identifiers? >> > > Yes, and PKCS#11 allows for *_VENDOR_SUPPLIED identifiers. But using these > can > get out of hand. Best to try and get them in the standard. OASIS controls > the > standard From 14 April 2015: > > > http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.html > > 2.40 does not define Ed25519. > > The Gnuk smartcard supports >> Ed25519 but I don't know if it is common to use it with OpenSSH through >> PKCS#11 (I would expect it to be used with OpenSSH through GnuPG's >> gpg-agent). At least it might be useful as a test case. >> >> /Simon >> >> >> >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> >> > -- > > Douglas E. Engert > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From simon at josefsson.org Fri Oct 9 01:17:41 2015 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 08 Oct 2015 16:17:41 +0200 Subject: [PATCH] Enabling ECDSA in PKCS#11 support for ssh-agent In-Reply-To: (Thomas Calderon's message of "Thu, 8 Oct 2015 14:36:44 +0100") References: <87r3l5u1u0.fsf@latte.josefsson.org> <561668D7.1020400@gmail.com> Message-ID: <87d1wpo35m.fsf@latte.josefsson.org> Thomas Calderon writes: > Hi, > > There is no need to add new mechanism identifiers to use specific curves. > > This can be done already using the CKM_ECDSA mechanism parameters (see > CKA_ECDSA_PARAMS > in the standard). > Given that the underlying HW or SW tokens supports Ed25519 curves, then you > could leverage it even with version 2.20 of the PKCS#11 standard. I think you need an OID to put in the namedCurve field of EC Parameters structure, right? The structure is: Parameters:: = CHOICE { ecParametersECParameters, namedCurveCURVES. & id( { CurveNames}), implicitlyCANULL} The ecParametersECParameters approach doesn't work, I believe, for EdDSA, but a namedCurve would probably do. But what OID to use? I'm happy to reserve 1.3.6.1.4.1.11591.9 to mean a namedCurve value for Ed25519 in PKCS#11. I'm not sure this approach works out -- but let's try. /Simon > Cheers, > > Thomas > > On Thu, Oct 8, 2015 at 2:00 PM, Douglas E Engert wrote: > >> >> >> On 10/8/2015 4:49 AM, Simon Josefsson wrote: >> >>> Mathias Brossard writes: >>> >>> Hi, >>>> >>>> I have made a patch for enabling the use of ECDSA keys in the PKCS#11 >>>> support of ssh-agent which will be of interest to other users. >>>> >>> >>> Nice! What would it take to add support for Ed25519 too? Do we need to >>> allocate any new PKCS#11 identifiers? >>> >> >> Yes, and PKCS#11 allows for *_VENDOR_SUPPLIED identifiers. But using these >> can >> get out of hand. Best to try and get them in the standard. OASIS controls >> the >> standard From 14 April 2015: >> >> >> http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.html >> >> 2.40 does not define Ed25519. >> >> The Gnuk smartcard supports >>> Ed25519 but I don't know if it is common to use it with OpenSSH through >>> PKCS#11 (I would expect it to be used with OpenSSH through GnuPG's >>> gpg-agent). At least it might be useful as a test case. >>> >>> /Simon >>> >>> >>> >>> _______________________________________________ >>> openssh-unix-dev mailing list >>> openssh-unix-dev at mindrot.org >>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >>> >>> >> -- >> >> Douglas E. Engert >> >> >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From calderon.thomas at gmail.com Fri Oct 9 01:45:21 2015 From: calderon.thomas at gmail.com (Thomas Calderon) Date: Thu, 8 Oct 2015 15:45:21 +0100 Subject: [PATCH] Enabling ECDSA in PKCS#11 support for ssh-agent In-Reply-To: <87d1wpo35m.fsf@latte.josefsson.org> References: <87r3l5u1u0.fsf@latte.josefsson.org> <561668D7.1020400@gmail.com> <87d1wpo35m.fsf@latte.josefsson.org> Message-ID: Hi Simon, Agreed, ecParameters are not suitable but namedCurve should do the trick. Did you mean: 1.3.6.1.4.1.11591.15.1 which seems reserved by GNU for Ed25519 (https://www.gnu.org/prep/standards/html_node/OID-Allocations.html)? As for putting it into the standard, not sure this is even needed. Cheers, Thomas On Thu, Oct 8, 2015 at 3:17 PM, Simon Josefsson wrote: > Thomas Calderon writes: > > > Hi, > > > > There is no need to add new mechanism identifiers to use specific curves. > > > > This can be done already using the CKM_ECDSA mechanism parameters (see > > CKA_ECDSA_PARAMS > > in the standard). > > Given that the underlying HW or SW tokens supports Ed25519 curves, then > you > > could leverage it even with version 2.20 of the PKCS#11 standard. > > I think you need an OID to put in the namedCurve field of EC Parameters > structure, right? The structure is: > > Parameters:: = CHOICE { > ecParametersECParameters, > namedCurveCURVES. & id( { CurveNames}), > implicitlyCANULL} > > The ecParametersECParameters approach doesn't work, I believe, for > EdDSA, but a namedCurve would probably do. But what OID to use? I'm > happy to reserve 1.3.6.1.4.1.11591.9 to mean a namedCurve value for > Ed25519 in PKCS#11. > > I'm not sure this approach works out -- but let's try. > > /Simon > > > Cheers, > > > > Thomas > > > > On Thu, Oct 8, 2015 at 2:00 PM, Douglas E Engert > wrote: > > > >> > >> > >> On 10/8/2015 4:49 AM, Simon Josefsson wrote: > >> > >>> Mathias Brossard writes: > >>> > >>> Hi, > >>>> > >>>> I have made a patch for enabling the use of ECDSA keys in the PKCS#11 > >>>> support of ssh-agent which will be of interest to other users. > >>>> > >>> > >>> Nice! What would it take to add support for Ed25519 too? Do we need > to > >>> allocate any new PKCS#11 identifiers? > >>> > >> > >> Yes, and PKCS#11 allows for *_VENDOR_SUPPLIED identifiers. But using > these > >> can > >> get out of hand. Best to try and get them in the standard. OASIS > controls > >> the > >> standard From 14 April 2015: > >> > >> > >> > http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.html > >> > >> 2.40 does not define Ed25519. > >> > >> The Gnuk smartcard supports > >>> Ed25519 but I don't know if it is common to use it with OpenSSH through > >>> PKCS#11 (I would expect it to be used with OpenSSH through GnuPG's > >>> gpg-agent). At least it might be useful as a test case. > >>> > >>> /Simon > >>> > >>> > >>> > >>> _______________________________________________ > >>> openssh-unix-dev mailing list > >>> openssh-unix-dev at mindrot.org > >>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > >>> > >>> > >> -- > >> > >> Douglas E. Engert > >> > >> > >> _______________________________________________ > >> openssh-unix-dev mailing list > >> openssh-unix-dev at mindrot.org > >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > >> > From deengert at gmail.com Fri Oct 9 02:37:22 2015 From: deengert at gmail.com (Douglas E Engert) Date: Thu, 8 Oct 2015 10:37:22 -0500 Subject: [PATCH] Enabling ECDSA in PKCS#11 support for ssh-agent In-Reply-To: <87d1wpo35m.fsf@latte.josefsson.org> References: <87r3l5u1u0.fsf@latte.josefsson.org> <561668D7.1020400@gmail.com> <87d1wpo35m.fsf@latte.josefsson.org> Message-ID: <56168DB2.7000501@gmail.com> On 10/8/2015 9:17 AM, Simon Josefsson wrote: > Thomas Calderon writes: > >> Hi, >> >> There is no need to add new mechanism identifiers to use specific curves. >> >> This can be done already using the CKM_ECDSA mechanism parameters (see >> CKA_ECDSA_PARAMS >> in the standard). >> Given that the underlying HW or SW tokens supports Ed25519 curves, then you >> could leverage it even with version 2.20 of the PKCS#11 standard. > > I think you need an OID to put in the namedCurve field of EC Parameters > structure, right? The structure is: > > Parameters:: = CHOICE { > ecParametersECParameters, > namedCurveCURVES. & id( { CurveNames}), > implicitlyCANULL} > > The ecParametersECParameters approach doesn't work, I believe, for > EdDSA, but a namedCurve would probably do. But what OID to use? I'm > happy to reserve 1.3.6.1.4.1.11591.9 to mean a namedCurve value for > Ed25519 in PKCS#11. Then what is: 1.3.6.1.4.1.11591.15.1 Ed25519 defined here: https://www.gnu.org/prep/standards/html_node/OID-Allocations.html The whole idea of namedCurve was you did not have to pass in the parameters, and PKIX certificates only allow namedCurve. But PKCS#11 does all the passing of the ecParameters but a PKCS#11 implementation may not. (OpenSC for example, but there is a request to allow them.) Or a hardware token may only support a limited number of curves. This in still not clear how to use ECDSA routines to do EDDSA. (I have been looking at Simon's RFCs on how to use EDDSA in TLS.) To use ECDSA PKCS#11 functions, do you need to use Curve25519 rather the Ed25519? > > I'm not sure this approach works out -- but let's try. > > /Simon > >> Cheers, >> >> Thomas >> >> On Thu, Oct 8, 2015 at 2:00 PM, Douglas E Engert wrote: >> >>> >>> >>> On 10/8/2015 4:49 AM, Simon Josefsson wrote: >>> >>>> Mathias Brossard writes: >>>> >>>> Hi, >>>>> >>>>> I have made a patch for enabling the use of ECDSA keys in the PKCS#11 >>>>> support of ssh-agent which will be of interest to other users. >>>>> >>>> >>>> Nice! What would it take to add support for Ed25519 too? Do we need to >>>> allocate any new PKCS#11 identifiers? >>>> >>> >>> Yes, and PKCS#11 allows for *_VENDOR_SUPPLIED identifiers. But using these >>> can >>> get out of hand. Best to try and get them in the standard. OASIS controls >>> the >>> standard From 14 April 2015: >>> >>> >>> http://docs.oasis-open.org/pkcs11/pkcs11-curr/v2.40/pkcs11-curr-v2.40.html >>> >>> 2.40 does not define Ed25519. >>> >>> The Gnuk smartcard supports >>>> Ed25519 but I don't know if it is common to use it with OpenSSH through >>>> PKCS#11 (I would expect it to be used with OpenSSH through GnuPG's >>>> gpg-agent). At least it might be useful as a test case. >>>> >>>> /Simon >>>> >>>> >>>> >>>> _______________________________________________ >>>> openssh-unix-dev mailing list >>>> openssh-unix-dev at mindrot.org >>>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >>>> >>>> >>> -- >>> >>> Douglas E. Engert >>> >>> >>> _______________________________________________ >>> openssh-unix-dev mailing list >>> openssh-unix-dev at mindrot.org >>> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >>> -- Douglas E. Engert From djm at mindrot.org Fri Oct 9 04:29:57 2015 From: djm at mindrot.org (Damien Miller) Date: Fri, 9 Oct 2015 04:29:57 +1100 (AEDT) Subject: [PATCH] Enabling ECDSA in PKCS#11 support for ssh-agent In-Reply-To: <56168DB2.7000501@gmail.com> References: <87r3l5u1u0.fsf@latte.josefsson.org> <561668D7.1020400@gmail.com> <87d1wpo35m.fsf@latte.josefsson.org> <56168DB2.7000501@gmail.com> Message-ID: On Thu, 8 Oct 2015, Douglas E Engert wrote: > Then what is: > 1.3.6.1.4.1.11591.15.1 Ed25519 > > defined here: > https://www.gnu.org/prep/standards/html_node/OID-Allocations.html > > The whole idea of namedCurve was you did not have to pass in the parameters, > and PKIX certificates only allow namedCurve. Ed25519 is a different algorithm to ECDSA, not just a different curve. -d From simon at josefsson.org Fri Oct 9 07:30:16 2015 From: simon at josefsson.org (Simon Josefsson) Date: Thu, 08 Oct 2015 22:30:16 +0200 Subject: [PATCH] Enabling ECDSA in PKCS#11 support for ssh-agent In-Reply-To: (Damien Miller's message of "Fri, 9 Oct 2015 04:29:57 +1100 (AEDT)") References: <87r3l5u1u0.fsf@latte.josefsson.org> <561668D7.1020400@gmail.com> <87d1wpo35m.fsf@latte.josefsson.org> <56168DB2.7000501@gmail.com> Message-ID: <87ziztm7c7.fsf@latte.josefsson.org> Damien Miller writes: > On Thu, 8 Oct 2015, Douglas E Engert wrote: > >> Then what is: >> 1.3.6.1.4.1.11591.15.1 Ed25519 >> >> defined here: >> https://www.gnu.org/prep/standards/html_node/OID-Allocations.html >> >> The whole idea of namedCurve was you did not have to pass in the parameters, >> and PKIX certificates only allow namedCurve. > > Ed25519 is a different algorithm to ECDSA, not just a different curve. Still it might work anyway. We noticed this with TLS and PKIX. While EdDSA is different from "normal" ECDSA, by using a namedCurve value corresponding to Ed25519 you tell implementations you really mean EdDSA. This is usually enough. Then EdDSA can be used in the already existing ECDSA umbrella. Of course, it has to be implemented and tested to iron out any problems. /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From deengert at gmail.com Fri Oct 9 08:14:47 2015 From: deengert at gmail.com (Douglas E Engert) Date: Thu, 8 Oct 2015 16:14:47 -0500 Subject: [PATCH] Enabling ECDSA in PKCS#11 support for ssh-agent In-Reply-To: References: <87r3l5u1u0.fsf@latte.josefsson.org> <561668D7.1020400@gmail.com> <87d1wpo35m.fsf@latte.josefsson.org> <56168DB2.7000501@gmail.com> Message-ID: <5616DCC7.1010902@gmail.com> On 10/8/2015 12:29 PM, Damien Miller wrote: > On Thu, 8 Oct 2015, Douglas E Engert wrote: > >> Then what is: >> 1.3.6.1.4.1.11591.15.1 Ed25519 >> >> defined here: >> https://www.gnu.org/prep/standards/html_node/OID-Allocations.html >> >> The whole idea of namedCurve was you did not have to pass in the parameters, >> and PKIX certificates only allow namedCurve. > > Ed25519 is a different algorithm to ECDSA, not just a different curve. Then can you comment on what Thomas Calderon said: > This can be done already using the CKM_ECDSA mechanism parameters (see CKA_ECDSA_PARAMS in the standard). > Given that the underlying HW or SW tokens supports Ed25519 curves, then you could leverage it even with version 2.20 of the PKCS#11 standard. > > -d > -- Douglas E. Engert From pv.safronov at gmail.com Fri Oct 9 09:42:33 2015 From: pv.safronov at gmail.com (=?UTF-8?B?0J/QsNCy0LXQuyDQodCw0YTRgNC+0L3QvtCy?=) Date: Fri, 9 Oct 2015 01:42:33 +0300 Subject: OpenSSH and stdin/stdout assigning Message-ID: Hey, guys, I have a question about a difference between openssh 4.3 and 5.3. I have plenty of servers with RHEL5 and RHEL6. Most of RHEL5 servers have openssh-server version 4.3p2-72.el5_6.3 (kernel 2.6.39-100.7.1uek) And RHEL6 servers have 5.3p1-111.el6 (kernel 3.8.13-35.el6uek.x86_64) So there is the difference in assigning stdin and stdout for ssh connections. Openssh 4.3 assigns socket (I assume this socket points to /dev/log but not really sure, I've got it from strace), and openssh 5.3 assigns pipes. $ ssh root at rhel6 '/bin/ls -la /proc/self/fd' total 0 dr-x------ 2 root root 0 Oct 9 00:26 . dr-xr-xr-x 8 root root 0 Oct 9 00:26 .. lr-x------ 1 root root 64 Oct 9 00:26 0 -> pipe:[3818769145] l-wx------ 1 root root 64 Oct 9 00:26 1 -> pipe:[3818769146] l-wx------ 1 root root 64 Oct 9 00:26 2 -> pipe:[3818769147] lr-x------ 1 root root 64 Oct 9 00:26 3 -> /proc/26794/fd $ ssh root at rhel6 '/bin/ls -la /proc/self/fd' total 0 dr-x------ 2 root root 0 Oct 9 00:26 . dr-xr-xr-x 8 root root 0 Oct 9 00:26 .. lrwx------ 1 root root 64 Oct 9 00:26 0 -> socket:[3010813704] lrwx------ 1 root root 64 Oct 9 00:26 1 -> socket:[3010813704] lrwx------ 1 root root 64 Oct 9 00:26 2 -> socket:[3010813706] lr-x------ 1 root root 64 Oct 9 00:26 3 -> /proc/12193/fd I'm wondering is it expected behaviour? Is there way to assign pipes in openssh 4.3 too? Looked through code but I'm not very familiar with C programming. PS Some daemon libs think that if stdin is socket then daemon is running from inetd and it is causing some troubles. PSS Sorry for broken english :( From dtucker at dtucker.net Fri Oct 9 13:17:18 2015 From: dtucker at dtucker.net (Darren Tucker) Date: Fri, 9 Oct 2015 13:17:18 +1100 Subject: OpenSSH and stdin/stdout assigning In-Reply-To: References: Message-ID: On Oct 9, 2015 11:29 AM, "????? ????????" wrote: > > Hey, guys, I have a question about a difference between openssh 4.3 and 5.3. > I have plenty of servers with RHEL5 and RHEL6. > Most of RHEL5 servers have openssh-server version 4.3p2-72.el5_6.3 > (kernel 2.6.39-100.7.1uek) > And RHEL6 servers have 5.3p1-111.el6 (kernel 3.8.13-35.el6uek.x86_64) > > So there is the difference in assigning stdin and stdout for ssh > connections. Openssh 4.3 assigns socket (I assume this socket points > to /dev/log No, sshd calls socketpair(2). > I'm wondering is it expected behaviour? Yes, in that we changed the compile time default at some point between those two because pipes have better close semantics for what sshd wants to do. > Is there way to assign pipes in openssh 4.3 too? Recompile it with -DUSE_PIPES. > Looked through code but I'm not very familiar with C programming. > > PS Some daemon libs think that if stdin is socket then daemon is > running from inetd and it is causing some trouble. That sounds a bit silly. Which daemons? From philipp.marek at linbit.com Fri Oct 9 16:49:57 2015 From: philipp.marek at linbit.com (Philipp Marek) Date: Fri, 9 Oct 2015 07:49:57 +0200 Subject: OpenSSH and stdin/stdout assigning In-Reply-To: References: Message-ID: <20151009054955.GC29734@cacao.linbit> > So there is the difference in assigning stdin and stdout for ssh > connections. Openssh 4.3 assigns socket (I assume this socket points > to /dev/log but not really sure, I've got it from strace), and openssh > 5.3 assigns pipes. ... > I'm wondering is it expected behaviour? Is there way to assign pipes > in openssh 4.3 too? > Looked through code but I'm not very familiar with C programming. The most easy way is to *make* STDIN (and STDOUT) a pipe: $ ssh root at rhel5 'cat | /bin/ls -la /proc/self/fd | cat' From pv.safronov at gmail.com Fri Oct 9 18:57:53 2015 From: pv.safronov at gmail.com (=?UTF-8?B?0J/QsNCy0LXQuyDQodCw0YTRgNC+0L3QvtCy?=) Date: Fri, 9 Oct 2015 10:57:53 +0300 Subject: OpenSSH and stdin/stdout assigning In-Reply-To: References: Message-ID: > https://alioth.debian.org/scm/browser.php?group_id=100328 Oh, wrong link, sorry. Navigate to /trunk/daemon/daemon.py there. 2015-10-09 10:54 GMT+03:00 ????? ???????? : >> Yes, in that we changed the compile time default at some point between those two because pipes have better close semantics for what sshd wants to do. > Thanks for quick reply, appreciate it. > >> That sounds a bit silly. Which daemons? > At least python-daemon lib. > Look here for functions is_process_started_by_superserver() and > is_detach_process_context_required() > https://alioth.debian.org/scm/browser.php?group_id=100328 > > 2015-10-09 5:17 GMT+03:00 Darren Tucker : >> >> On Oct 9, 2015 11:29 AM, "????? ????????" wrote: >>> >>> Hey, guys, I have a question about a difference between openssh 4.3 and >>> 5.3. >>> I have plenty of servers with RHEL5 and RHEL6. >>> Most of RHEL5 servers have openssh-server version 4.3p2-72.el5_6.3 >>> (kernel 2.6.39-100.7.1uek) >>> And RHEL6 servers have 5.3p1-111.el6 (kernel 3.8.13-35.el6uek.x86_64) >>> >>> So there is the difference in assigning stdin and stdout for ssh >>> connections. Openssh 4.3 assigns socket (I assume this socket points >>> to /dev/log >> >> No, sshd calls socketpair(2). >> >>> I'm wondering is it expected behaviour? >> >> Yes, in that we changed the compile time default at some point between those >> two because pipes have better close semantics for what sshd wants to do. >> >>> Is there way to assign pipes in openssh 4.3 too? >> >> Recompile it with -DUSE_PIPES. >> >>> Looked through code but I'm not very familiar with C programming. >>> >>> PS Some daemon libs think that if stdin is socket then daemon is >>> running from inetd and it is causing some trouble. >> >> That sounds a bit silly. Which daemons? > > > > -- > ? ?????????, ???????? ?????. -- ? ?????????, ???????? ?????. From pv.safronov at gmail.com Fri Oct 9 18:54:24 2015 From: pv.safronov at gmail.com (=?UTF-8?B?0J/QsNCy0LXQuyDQodCw0YTRgNC+0L3QvtCy?=) Date: Fri, 9 Oct 2015 10:54:24 +0300 Subject: OpenSSH and stdin/stdout assigning In-Reply-To: References: Message-ID: > Yes, in that we changed the compile time default at some point between those two because pipes have better close semantics for what sshd wants to do. Thanks for quick reply, appreciate it. > That sounds a bit silly. Which daemons? At least python-daemon lib. Look here for functions is_process_started_by_superserver() and is_detach_process_context_required() https://alioth.debian.org/scm/browser.php?group_id=100328 2015-10-09 5:17 GMT+03:00 Darren Tucker : > > On Oct 9, 2015 11:29 AM, "????? ????????" wrote: >> >> Hey, guys, I have a question about a difference between openssh 4.3 and >> 5.3. >> I have plenty of servers with RHEL5 and RHEL6. >> Most of RHEL5 servers have openssh-server version 4.3p2-72.el5_6.3 >> (kernel 2.6.39-100.7.1uek) >> And RHEL6 servers have 5.3p1-111.el6 (kernel 3.8.13-35.el6uek.x86_64) >> >> So there is the difference in assigning stdin and stdout for ssh >> connections. Openssh 4.3 assigns socket (I assume this socket points >> to /dev/log > > No, sshd calls socketpair(2). > >> I'm wondering is it expected behaviour? > > Yes, in that we changed the compile time default at some point between those > two because pipes have better close semantics for what sshd wants to do. > >> Is there way to assign pipes in openssh 4.3 too? > > Recompile it with -DUSE_PIPES. > >> Looked through code but I'm not very familiar with C programming. >> >> PS Some daemon libs think that if stdin is socket then daemon is >> running from inetd and it is causing some trouble. > > That sounds a bit silly. Which daemons? -- ? ?????????, ???????? ?????. From sdaoden at yandex.com Sat Oct 10 03:50:15 2015 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Fri, 09 Oct 2015 18:50:15 +0200 Subject: Permanently added hostkeys (due to IP address pool), without confirmation Message-ID: <20151009165015.CmVLEZNXJ%sdaoden@yandex.com> Hello, maybe someone could please help and shed some light on a problem that i don't understand, and that even in multiple ways. The problem occurred three or four times over the past months (maybe half a year?) and manifests as ++ Pushing to "gitlab" (at least "master" differs)! Warning: Permanently added the RSA host key for IP address '104.46.105.89' to the list of known hosts. I get no confirmation prompt, which i normally do?! Of course i do have a configuration file with an UserKnownHostsFile ~/arena/data/ssh/known_hosts entry, and that already has a gitlab.com,54.93.71.23 DATA line for months. I do have a "Host" entry for "*gitlab.org" (with explicit IdentityFile). The entry in known_hosts that i (hope to have confirmed correctly back then) is not identical with the other two entries, but which are, except for the addresses --- k.1 2015-10-09 18:09:10.511793883 +0200 +++ k.2 2015-10-09 18:09:26.508373888 +0200 @@ -1,2 +1,2 @@ -52.21.36.51 +104.46.105.89 ssh-rsa ... I understand that the keys in k.1 and k.2 are the same that ssh-keyscan(1) gives me, whereas the address i verified does currently give no ssh-keyscan result at all. (I verified it back in the day in that i was able to login after placing my public key at their server via a HTTPS connection after i had created my account. I'm no expert in mathematics or the SSH protocols, but i'm confident as only a greenhorn or real expert can be.) So: no confirmation prompt, no hostname but only the address for the entry in known_hosts even though the connection is to gitlab.com (they're appended though), and multiple entries with the same key. I'm on "OpenSSH_7.1p1, OpenSSL 1.0.2d 9 Jul 2015". Thank you in advance for any hint, ciao, --steffen From mathias at brossard.org Sat Oct 10 07:10:06 2015 From: mathias at brossard.org (Mathias Brossard) Date: Fri, 9 Oct 2015 13:10:06 -0700 Subject: [PATCH] Enabling ECDSA in PKCS#11 support for ssh-agent In-Reply-To: <87r3l5u1u0.fsf@latte.josefsson.org> References: <87r3l5u1u0.fsf@latte.josefsson.org> Message-ID: On Thu, Oct 8, 2015 at 2:49 AM, Simon Josefsson wrote: > Mathias Brossard writes: > > I have made a patch for enabling the use of ECDSA keys in the PKCS#11 > > support of ssh-agent which will be of interest to other users. > > Nice! What would it take to add support for Ed25519 too? Do we need to > allocate any new PKCS#11 identifiers? The Gnuk smartcard supports > Ed25519 but I don't know if it is common to use it with OpenSSH through > PKCS#11 (I would expect it to be used with OpenSSH through GnuPG's > gpg-agent). At least it might be useful as a test case. > This raises a lot of different questions. I'll try to be brief and not too controversial (so I'll skip the PKCS#11 in GnuPG question). PKCS#11 is the standard API to access smartcards and if you want, for instance, browsers to support Ed25519 for TLS authentication (I'm sure you're familiar with https://tools.ietf.org/html/draft-josefsson-tls-eddsa2-02), this will be a necessary step. For supporting Ed25519 in ssh-agent through PKCS#11, it should be possible using the same path as my ECDSA patch. The current implementation for PKCS#11 uses OpenSSL as scaffolding and essentially overloads the signing method with its own. Now the question becomes how should Ed25519 on PKCS#11. I hadn't subscribed to the mailing list so I missed a few mails. The key type CKK_ECDSA has been renamed CKK_EC and CKA_ECDSA_PARAMS is now CKA_EC_PARAMS, which I take is a signal from the PKCS#11 TC to say that if you can fit into this framework, you are encouraged to do so. For CKA_EC_PARAMS, using named curves is definitely the preferred way to do it. For the mechanism I can not pretend to be well versed in EdDSA, but signature seems to return a (R,s) tuple. So application could possibly be using CKM_ECDSA to minimize the number of execution paths (and distinguish with CKA_EC_PARAMS if necessary). A technical problem might come up, or it might be judged by the PKCS#11 TC to be too confusing, so a switch to CKM_EDDSA (or CKM_EC_EDDSA). As a first step and while the RFCs and TCs are assigning new magic values, I would suggest: - CKA_KEY_TYPE: CKK_EC - CKA_EC_PARAMS: 1.3.6.1.4.1.11591.15.1 - CKA_ALLOWED_MECHANISMS: [ CKM_ECDSA ] If adding Ed25559 support in PKCS#11 is in the work for the (OpenSC or otherwise), I could help adding the support to ssh-agent. Sincerely, -- Mathias Brossard From djm at mindrot.org Sat Oct 10 09:00:21 2015 From: djm at mindrot.org (Damien Miller) Date: Sat, 10 Oct 2015 09:00:21 +1100 (AEDT) Subject: Permanently added hostkeys (due to IP address pool), without confirmation In-Reply-To: <20151009165015.CmVLEZNXJ%sdaoden@yandex.com> References: <20151009165015.CmVLEZNXJ%sdaoden@yandex.com> Message-ID: On Fri, 9 Oct 2015, Steffen Nurpmeso wrote: > Hello, > > maybe someone could please help and shed some light on a problem > that i don't understand, and that even in multiple ways. > The problem occurred three or four times over the past months > (maybe half a year?) and manifests as > > ++ Pushing to "gitlab" (at least "master" differs)! > Warning: Permanently added the RSA host key for IP address '104.46.105.89' to the list of known hosts. > > I get no confirmation prompt, which i normally do?! > Of course i do have a configuration file with an > > UserKnownHostsFile ~/arena/data/ssh/known_hosts > > entry, and that already has a > > gitlab.com,54.93.71.23 DATA > > line for months. I do have a "Host" entry for "*gitlab.org" (with > explicit IdentityFile). The entry in known_hosts that i (hope to > have confirmed correctly back then) is not identical with the > other two entries, but which are, except for the addresses > > --- k.1 2015-10-09 18:09:10.511793883 +0200 > +++ k.2 2015-10-09 18:09:26.508373888 +0200 > @@ -1,2 +1,2 @@ > -52.21.36.51 > +104.46.105.89 > ssh-rsa ... You have CheckHostIP enabled (it is on by default) and some DNS server or hosts file is returning 104.46.105.89 for that hostname. When ssh connects to 104.46.105.89, it is offering the same key as you have already learned for 52.21.36.51, so it is automatically added to known_hosts. See ssh_config's entry on CheckHostIP for a few more details. -d From sdaoden at yandex.com Sat Oct 10 22:22:36 2015 From: sdaoden at yandex.com (Steffen Nurpmeso) Date: Sat, 10 Oct 2015 13:22:36 +0200 Subject: Permanently added hostkeys (due to IP address pool), without confirmation In-Reply-To: References: <20151009165015.CmVLEZNXJ%sdaoden@yandex.com> Message-ID: <20151010112236.xVJYdZjlP%sdaoden@yandex.com> Damien Miller wrote: |On Fri, 9 Oct 2015, Steffen Nurpmeso wrote: |You have CheckHostIP enabled (it is on by default) and some DNS server |or hosts file is returning 104.46.105.89 for that hostname. When ssh |connects to 104.46.105.89, it is offering the same key as you have |already learned for 52.21.36.51, so it is automatically added to |known_hosts. | |See ssh_config's entry on CheckHostIP for a few more details. Yes (through default). Ok that explains the missing confirmation. It's pretty clear from the manual, thank you. --steffen From micah at riseup.net Tue Oct 13 05:56:27 2015 From: micah at riseup.net (micah anderson) Date: Mon, 12 Oct 2015 14:56:27 -0400 Subject: ssh-keyscan non-standard port broken Message-ID: <87twpvapb8.fsf@muck.riseup.net> Hello, If one passes the -p option for a non-standard port to ssh-keyscan when using the -f option to pull hosts from a file, it results in a known_hosts entry that is incorrect: micah at muck$ cat /tmp/try 199.254.238.47 micah.riseup.net,199.254.238.47 ssh-keyscan -t rsa -p 4422 -f /tmp/try > /tmp/known micah at muck$ cat /tmp/known [micah.riseup.net,199.254.238.47]:4422 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwv2zUVJbsQWoezgI3JSwCJVyo95lDcq43dXhoLV3l+aDJZu+Yb6hPRFVHOn/XJXrrVsbY30jqBb498rFRcNg+2lrO/lalg33Ek/pjL2GiezRkKl4m/kMHd2wEvf+ZyvWOIg34jGe4ZMJUIAoJg/NOPzGiA05U8FabTK1jB2IsHMX3cnX9qEm0P9qyOc37AO8yTQUeF53CyZ1Vq6/8VYK1Fu8W+Uup0iikfsLFHlhxC4vkg2gEFp8iSp4gBUybIJ0mBcjGpwt+8KTqEHBEkRjWqH3EkacVm/uWQhVWqPNnamxuc0g0Al9L4htd9GhPqHTrnct+uweVzvsLBI99SPRew== It seems like putting a list of hostnames,ips inside of the [] doesn't work: micah at muck:dotfiles$ ssh -oUserKnownHostsFile=/tmp/known micah at micah.riseup.net -p 4422 The authenticity of host '[micah.riseup.net]:4422 ([199.254.238.47]:4422)' can't be established. RSA key fingerprint is SHA256:CbHIxWJjFKJk5V+G09XeiABqIRTooC646ZfSl7FRp2w. Are you sure you want to continue connecting (yes/no)? It should be constructed like this: [micah.riseup.net]:4422,[199.254.238.47]:4422 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwv2zUVJbsQWoezgI3JSwCJVyo95lDcq43dXhoLV3l+aDJZu+Yb6hPRFVHOn/XJXrrVsbY30jqBb498rFRcNg+2lrO/lalg33Ek/pjL2GiezRkKl4m/kMHd2wEvf+ZyvWOIg34jGe4ZMJUIAoJg/NOPzGiA05U8FabTK1jB2IsHMX3cnX9qEm0P9qyOc37AO8yTQUeF53CyZ1Vq6/8VYK1Fu8W+Uup0iikfsLFHlhxC4vkg2gEFp8iSp4gBUybIJ0mBcjGpwt+8KTqEHBEkRjWqH3EkacVm/uWQhVWqPNnamxuc0g0Al9L4htd9GhPqHTrnct+uweVzvsLBI99SPRew== which works. micah From alexinbeijing at gmail.com Tue Oct 13 05:51:18 2015 From: alexinbeijing at gmail.com (Alex Dowad) Date: Mon, 12 Oct 2015 20:51:18 +0200 Subject: [PATCH] ANSI terminal escape sequences do not affect processing of SSH escapes Message-ID: <1444675878-10625-1-git-send-email-alexinbeijing@gmail.com> Even when the user has not pressed a key, ANSI-compatible terminal emulators can send escape sequences to ssh's stdin at any time. For example, any time that the server sends an "[6n" (query cursor position) sequence, an ANSI-compatible terminal will send back "[;R". ssh sees these escape sequences just as if they were characters typed in by the user. This causes problems if the user is attempting to type an SSH escape sequence, starting with "~". Therefore, when scanning user input for SSH escape sequences, skip over any ANSI terminal control sequences which appear in the input. --- Dear OpenSSH-Portable Devs, Please CC replies as I am not (yet) a subscriber! I should probably send this upstream, but I've been searching for the right mailing list and haven't found anything. Your feedback will be appreciated. I've read your style guidelines and attempted to follow them. This patch was prompted by the observation that SSH escapes (using ~) don't work at all when the remote shell is BusyBox ash (used by Alpine Linux and some other minimalist and/or embedded Linux distributions). This is because the BusyBox shell *always* sends a "query cursor position" terminal control escape sequence each time you press the key. Quick as a flash, as your pinky finger is descending towards the tilda key, the terminal sends back a "report cursor position" sequence. The result is that the SSH client *never* sees your tilda as immediately following the newline. Those ANSI terminal control sequences always begin with "[" and end with an alphabetic character. Hence the call to isalpha() in my code. Can someone confirm that isalpha() *always* treats a-z and A-Z as alphabetic, no matter what the locale is? Thank you, Alex Dowad clientloop.c | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/clientloop.c b/clientloop.c index 87ceb3d..b15e470 100644 --- a/clientloop.c +++ b/clientloop.c @@ -1096,7 +1096,17 @@ process_escapes(Channel *c, Buffer *bin, Buffer *bout, Buffer *berr, /* Get one character at a time. */ ch = buf[i]; - if (*escape_pendingp) { + /* ANSI terminal escape sequences may appear anywhere in input stream. */ + /* They do not affect our processing of our own escapes. */ + if (ch == 0x1B && buf[i+1] == '[') { + for (; i < (u_int)len; i++) { + ch = buf[i]; + buffer_put_char(bin, ch); + if (isalpha(ch)) + break; + } + continue; + } else if (*escape_pendingp) { /* We have previously seen an escape character. */ /* Clear the flag now. */ *escape_pendingp = 0; -- 2.0.0.GIT From djm at mindrot.org Tue Oct 13 06:28:29 2015 From: djm at mindrot.org (Damien Miller) Date: Tue, 13 Oct 2015 06:28:29 +1100 (AEDT) Subject: [PATCH] ANSI terminal escape sequences do not affect processing of SSH escapes In-Reply-To: <1444675878-10625-1-git-send-email-alexinbeijing@gmail.com> References: <1444675878-10625-1-git-send-email-alexinbeijing@gmail.com> Message-ID: Hi, Thanks for this - could I ask you to create a bug at https://bugzilla.mindrot.org for this and attach your patch? This will make sure it doesn't get lost. Thanks, Damien On Mon, 12 Oct 2015, Alex Dowad wrote: > Even when the user has not pressed a key, ANSI-compatible terminal emulators > can send escape sequences to ssh's stdin at any time. For example, any time that > the server sends an "[6n" (query cursor position) sequence, an > ANSI-compatible terminal will send back "[;R". ssh sees these > escape sequences just as if they were characters typed in by the user. This > causes problems if the user is attempting to type an SSH escape sequence, > starting with "~". > > Therefore, when scanning user input for SSH escape sequences, skip over any > ANSI terminal control sequences which appear in the input. > --- > > Dear OpenSSH-Portable Devs, > > Please CC replies as I am not (yet) a subscriber! > > I should probably send this upstream, but I've been searching for the right > mailing list and haven't found anything. Your feedback will be appreciated. > I've read your style guidelines and attempted to follow them. > > This patch was prompted by the observation that SSH escapes (using ~) don't work > at all when the remote shell is BusyBox ash (used by Alpine Linux and some > other minimalist and/or embedded Linux distributions). > > This is because the BusyBox shell *always* sends a "query cursor position" > terminal control escape sequence each time you press the key. > Quick as a flash, as your pinky finger is descending towards the tilda key, > the terminal sends back a "report cursor position" sequence. The result is > that the SSH client *never* sees your tilda as immediately following the > newline. > > Those ANSI terminal control sequences always begin with "[" and end > with an alphabetic character. Hence the call to isalpha() in my code. > Can someone confirm that isalpha() *always* treats a-z and A-Z as alphabetic, > no matter what the locale is? > > Thank you, > Alex Dowad > > clientloop.c | 12 +++++++++++- > 1 file changed, 11 insertions(+), 1 deletion(-) > > diff --git a/clientloop.c b/clientloop.c > index 87ceb3d..b15e470 100644 > --- a/clientloop.c > +++ b/clientloop.c > @@ -1096,7 +1096,17 @@ process_escapes(Channel *c, Buffer *bin, Buffer *bout, Buffer *berr, > /* Get one character at a time. */ > ch = buf[i]; > > - if (*escape_pendingp) { > + /* ANSI terminal escape sequences may appear anywhere in input stream. */ > + /* They do not affect our processing of our own escapes. */ > + if (ch == 0x1B && buf[i+1] == '[') { > + for (; i < (u_int)len; i++) { > + ch = buf[i]; > + buffer_put_char(bin, ch); > + if (isalpha(ch)) > + break; > + } > + continue; > + } else if (*escape_pendingp) { > /* We have previously seen an escape character. */ > /* Clear the flag now. */ > *escape_pendingp = 0; > -- > 2.0.0.GIT > > _______________________________________________ > 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 Tue Oct 13 06:30:05 2015 From: djm at mindrot.org (Damien Miller) Date: Tue, 13 Oct 2015 06:30:05 +1100 (AEDT) Subject: ssh-keyscan non-standard port broken In-Reply-To: <87twpvapb8.fsf@muck.riseup.net> References: <87twpvapb8.fsf@muck.riseup.net> Message-ID: Hi Michah, Thanks for reporting this. Could I ask you to file a bug at https://bugzilla.mindrot.org/ so we don't lose it? Thanks, Damien On Mon, 12 Oct 2015, micah anderson wrote: > > Hello, > > If one passes the -p option for a non-standard port to ssh-keyscan when > using the -f option to pull hosts from a file, it results in a > known_hosts entry that is incorrect: > > micah at muck$ cat /tmp/try > 199.254.238.47 micah.riseup.net,199.254.238.47 > > ssh-keyscan -t rsa -p 4422 -f /tmp/try > /tmp/known > > micah at muck$ cat /tmp/known > [micah.riseup.net,199.254.238.47]:4422 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwv2zUVJbsQWoezgI3JSwCJVyo95lDcq43dXhoLV3l+aDJZu+Yb6hPRFVHOn/XJXrrVsbY30jqBb498rFRcNg+2lrO/lalg33Ek/pjL2GiezRkKl4m/kMHd2wEvf+ZyvWOIg34jGe4ZMJUIAoJg/NOPzGiA05U8FabTK1jB2IsHMX3cnX9qEm0P9qyOc37AO8yTQUeF53CyZ1Vq6/8VYK1Fu8W+Uup0iikfsLFHlhxC4vkg2gEFp8iSp4gBUybIJ0mBcjGpwt+8KTqEHBEkRjWqH3EkacVm/uWQhVWqPNnamxuc0g0Al9L4htd9GhPqHTrnct+uweVzvsLBI99SPRew== > > It seems like putting a list of hostnames,ips inside of the [] doesn't > work: > > micah at muck:dotfiles$ ssh -oUserKnownHostsFile=/tmp/known micah at micah.riseup.net -p 4422 > The authenticity of host '[micah.riseup.net]:4422 ([199.254.238.47]:4422)' can't be established. > RSA key fingerprint is SHA256:CbHIxWJjFKJk5V+G09XeiABqIRTooC646ZfSl7FRp2w. > Are you sure you want to continue connecting (yes/no)? > > It should be constructed like this: > > [micah.riseup.net]:4422,[199.254.238.47]:4422 ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEAwv2zUVJbsQWoezgI3JSwCJVyo95lDcq43dXhoLV3l+aDJZu+Yb6hPRFVHOn/XJXrrVsbY30jqBb498rFRcNg+2lrO/lalg33Ek/pjL2GiezRkKl4m/kMHd2wEvf+ZyvWOIg34jGe4ZMJUIAoJg/NOPzGiA05U8FabTK1jB2IsHMX3cnX9qEm0P9qyOc37AO8yTQUeF53CyZ1Vq6/8VYK1Fu8W+Uup0iikfsLFHlhxC4vkg2gEFp8iSp4gBUybIJ0mBcjGpwt+8KTqEHBEkRjWqH3EkacVm/uWQhVWqPNnamxuc0g0Al9L4htd9GhPqHTrnct+uweVzvsLBI99SPRew== > > which works. > > micah > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From simon at josefsson.org Tue Oct 13 08:13:31 2015 From: simon at josefsson.org (Simon Josefsson) Date: Mon, 12 Oct 2015 23:13:31 +0200 Subject: [PATCH] Enabling ECDSA in PKCS#11 support for ssh-agent In-Reply-To: References: <87r3l5u1u0.fsf@latte.josefsson.org> Message-ID: <20151012231331.004e299e@latte.josefsson.org> > For supporting Ed25519 in ssh-agent through PKCS#11, it should be > possible using the same path as my ECDSA patch. The current > implementation for PKCS#11 uses OpenSSL as scaffolding and > essentially overloads the signing method with its own. > > Now the question becomes how should Ed25519 on PKCS#11. I hadn't > subscribed to the mailing list so I missed a few mails. > > The key type CKK_ECDSA has been renamed CKK_EC and > CKA_ECDSA_PARAMS is now CKA_EC_PARAMS, which I take is a signal from > the PKCS#11 TC to say that if you can fit into this framework, you are > encouraged > to do so. For CKA_EC_PARAMS, using named curves is definitely the > preferred way to do it. > > For the mechanism I can not pretend to be well versed in EdDSA, but > signature > seems to return a (R,s) tuple. So application could possibly be using > CKM_ECDSA to minimize the number of execution paths (and distinguish > with CKA_EC_PARAMS if necessary). A technical problem might come up, > or it might be judged by the PKCS#11 TC to be too confusing, so a > switch to CKM_EDDSA (or CKM_EC_EDDSA). > > As a first step and while the RFCs and TCs are assigning new magic > values, I would suggest: > - CKA_KEY_TYPE: CKK_EC > - CKA_EC_PARAMS: 1.3.6.1.4.1.11591.15.1 > - CKA_ALLOWED_MECHANISMS: [ CKM_ECDSA ] > > If adding Ed25559 support in PKCS#11 is in the work for the (OpenSC or > otherwise), I could help adding the support to ssh-agent. Maybe someone could try to implement Ed25519 support in a "soft" PKCS#11 provider (SoftHSMv2?) for simpler experimentation? /Simon -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 473 bytes Desc: OpenPGP digital signatur URL: From micah at riseup.net Tue Oct 13 08:17:45 2015 From: micah at riseup.net (micah) Date: Mon, 12 Oct 2015 17:17:45 -0400 Subject: ssh-keyscan non-standard port broken In-Reply-To: References: <87twpvapb8.fsf@muck.riseup.net> Message-ID: <87zizn947a.fsf@muck.riseup.net> Hi Damien, Damien Miller writes: > Thanks for reporting this. Could I ask you to file a bug at > https://bugzilla.mindrot.org/ so we don't lose it? No problem, I was hoping you would say that it was PEBKAC, but alas... https://bugzilla.mindrot.org/show_bug.cgi?id=2479 micah From william at 25thandClement.com Wed Oct 14 06:36:45 2015 From: william at 25thandClement.com (William Ahern) Date: Tue, 13 Oct 2015 12:36:45 -0700 Subject: wrong strlcat limit value in realpath.c Message-ID: <20151013193645.GA20581@wilbur.25thandClement.com> In realpath.c at line 182 left_len = strlcat(symlink, left, sizeof(left)); should be left_len = strlcat(symlink, left, sizeof(symlink)); It's a benign issue because both arrays are the same size. And I can't imagine that ever changing. But it's inconsistent, not to mention throwing compiler warnings on OS X. From Todd.Miller at courtesan.com Wed Oct 14 07:57:35 2015 From: Todd.Miller at courtesan.com (Todd C. Miller) Date: Tue, 13 Oct 2015 14:57:35 -0600 Subject: wrong strlcat limit value in realpath.c In-Reply-To: Your message of "Tue, 13 Oct 2015 12:36:45 -0700." <20151013193645.GA20581@wilbur.25thandClement.com> References: <20151013193645.GA20581@wilbur.25thandClement.com> Message-ID: <968a5e639d2d06d1@courtesan.com> On Tue, 13 Oct 2015 12:36:45 -0700, William Ahern wrote: > In realpath.c at line 182 > > left_len = strlcat(symlink, left, sizeof(left)); > > should be > > left_len = strlcat(symlink, left, sizeof(symlink)); > > It's a benign issue because both arrays are the same size. And I can't > imagine that ever changing. But it's inconsistent, not to mention throwing > compiler warnings on OS X. Correct. This was fixed some time ago i version shipped with OpenSSH was not updated. The truncation check immediately following the strlcat also should use sizeof(symlink) rather than sizeof(left). - todd From djm at mindrot.org Wed Oct 14 08:29:45 2015 From: djm at mindrot.org (Damien Miller) Date: Wed, 14 Oct 2015 08:29:45 +1100 (AEDT) Subject: wrong strlcat limit value in realpath.c In-Reply-To: <968a5e639d2d06d1@courtesan.com> References: <20151013193645.GA20581@wilbur.25thandClement.com> <968a5e639d2d06d1@courtesan.com> Message-ID: On Tue, 13 Oct 2015, Todd C. Miller wrote: > On Tue, 13 Oct 2015 12:36:45 -0700, William Ahern wrote: > > > In realpath.c at line 182 > > > > left_len = strlcat(symlink, left, sizeof(left)); > > > > should be > > > > left_len = strlcat(symlink, left, sizeof(symlink)); > > > > It's a benign issue because both arrays are the same size. And I can't > > imagine that ever changing. But it's inconsistent, not to mention throwing > > compiler warnings on OS X. > > Correct. This was fixed some time ago i version shipped with OpenSSH > was not updated. The truncation check immediately following the > strlcat also should use sizeof(symlink) rather than sizeof(left). Thanks, I've just synced the OpenSSH openbsd-compat/realpath.c to -current. -d From fidencio at redhat.com Wed Oct 14 09:19:48 2015 From: fidencio at redhat.com (=?UTF-8?Q?Fabiano_Fid=C3=AAncio?=) Date: Wed, 14 Oct 2015 00:19:48 +0200 Subject: [RFC][PATCH v2] Support a list of sockets on SSH_AUTH_SOCK In-Reply-To: <1443231698-17257-1-git-send-email-fidencio@redhat.com> References: <1443231698-17257-1-git-send-email-fidencio@redhat.com> Message-ID: People, I've filed a bug[0] about this topic and hope we can keep the discussion there. [0]: https://bugzilla.mindrot.org/show_bug.cgi?id=2480 Best Regards, -- Fabiano Fid?nncio From fccagou at gmail.com Wed Oct 14 09:33:38 2015 From: fccagou at gmail.com (the cagou) Date: Wed, 14 Oct 2015 00:33:38 +0200 Subject: [KRB] - set principal in environment Message-ID: Hello, While connecting on ssh using kerberos, k5login and no credential delegation, I would like to know the principal/login used by the client; as done in apache with REMOTE_USER. Looking in the code, this information is known by 'ssh_gssapi_krb5_userok' in 'gss-serv-krb5.c' and could be passed to environment. Is this feature yet discussed on the list ? Could it be added in sshd server ? Thanks in advance for the feedback. -- Fran?ois From mathias at brossard.org Wed Oct 14 15:19:54 2015 From: mathias at brossard.org (Mathias Brossard) Date: Tue, 13 Oct 2015 21:19:54 -0700 Subject: [PATCH] Enabling ECDSA in PKCS#11 support for ssh-agent In-Reply-To: References: Message-ID: On Mon, Sep 28, 2015 at 1:17 AM, Mathias Brossard wrote: > I have made a patch for enabling the use of ECDSA keys in the PKCS#11 > support of ssh-agent which will be of interest to other users. > > I have tested it with P-256 keys. P-384 and P-521 should work > out-of-the box. The code is ready for non-FIPS curves (named or > explicit), but OpenSSH currently limits ECDSA to those 3 curves. > I've now been able to test the patch with 2 different smart-cards with P-256 and a software token with P-256, P-384 and P-521. > I added this patch and text as > https://bugzilla.mindrot.org/show_bug.cgi?id=2474 > The patch has been updated in the ticket with two bugs fixed. Sincerely, -- Mathias Brossard From fccagou at gmail.com Thu Oct 15 06:06:41 2015 From: fccagou at gmail.com (the cagou) Date: Wed, 14 Oct 2015 21:06:41 +0200 Subject: [KRB] - set principal in environment In-Reply-To: References: Message-ID: Hello. I've found this feature in ticket 2063 [1]. 3 patches are proposed since 01/17/2013.and I don't find any thread explaining why the feature is not added in sshd. Is somebody know something about it Thanks a lot [1] - https://bugzilla.mindrot.org/show_bug.cgi?id=2063 2015-10-14 0:33 GMT+02:00 the cagou : > Hello, > > While connecting on ssh using kerberos, k5login and no credential > delegation, I would like to > know the principal/login used by the client; as done in apache with > REMOTE_USER. > > Looking in the code, this information is known by > 'ssh_gssapi_krb5_userok' in 'gss-serv-krb5.c' > and could be passed to environment. > > > Is this feature yet discussed on the list ? > Could it be added in sshd server ? > > > Thanks in advance for the feedback. > > -- Fran?ois > > From steve at steve.org.uk Thu Oct 15 16:32:56 2015 From: steve at steve.org.uk (Steve Kemp) Date: Thu, 15 Oct 2015 05:32:56 +0000 Subject: Segfault on invalid SSH keys. Message-ID: <1444887176.1976.0@ssh.steve.org.uk> Hi, I reported a bug against the Debian distribution, but it might be more useful to report it here. Via fuzzing I discovered a key which will cause the ssh-keygen process to segfault when fingerprinting via: ssh-keygen -l -f bogus.key This segfault is a NULL pointer dereference, and is a denial of service attack if you run a service which allows SSH keys to be uploaded and display their fingerprints. (I run such a service. Oops.) There is a simple patch which I've posted in the bug report which fixes the problem for me, but probably needs more eyes. This is the patch: --- sshkey.c.orig 2015-10-13 22:42:26.178252307 +0300 +++ sshkey.c 2015-10-13 22:42:58.781080815 +0300 @@ -1198,6 +1198,9 @@ bits == 0 || bits > SSHBUF_MAX_BIGNUM * 8) return SSH_ERR_INVALID_FORMAT; /* Bad bit count... */ + if ( ret->rsa == NULL ) + return SSH_ERR_INVALID_FORMAT; + /* Get public exponent, public modulus. */ if ((r = read_decimal_bignum(&ep, ret->rsa->e)) < 0) return r; The crasher can be found in the bug-report (note there are two, the second is easier to deal with): https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=801530:w I'm not a member of the list, but I'll keep an eye out for updates, via the archives, for the next few days in case there are questions. Steve -- http://www.steve.org.uk/ From djm at mindrot.org Thu Oct 15 16:53:08 2015 From: djm at mindrot.org (Damien Miller) Date: Thu, 15 Oct 2015 16:53:08 +1100 (AEDT) Subject: Segfault on invalid SSH keys. In-Reply-To: <1444887176.1976.0@ssh.steve.org.uk> References: <1444887176.1976.0@ssh.steve.org.uk> Message-ID: On Thu, 15 Oct 2015, Steve Kemp wrote: > Hi, > > I reported a bug against the Debian distribution, > but it might be more useful to report it here. > > Via fuzzing I discovered a key which will cause > the ssh-keygen process to segfault when fingerprinting > via: > > ssh-keygen -l -f bogus.key Could you please share the key that causes this problem? Thanks, Damien From steve at steve.org.uk Thu Oct 15 16:59:23 2015 From: steve at steve.org.uk (Steve Kemp) Date: Thu, 15 Oct 2015 05:59:23 +0000 Subject: Segfault on invalid SSH keys. In-Reply-To: References: <1444887176.1976.0@ssh.steve.org.uk> Message-ID: <20151015055923.GA6306@steve.org.uk> > > Via fuzzing I discovered a key which will cause > > the ssh-keygen process to segfault when fingerprinting > > via: > > > > ssh-keygen -l -f bogus.key > > Could you please share the key that causes this problem? The key was attached to the referenced bug report, but please find attached a copy to this mail. Usage is: $ gunzip crash.min.pub.gz $ ssh-keygen -l -f ./crash.min.pub Segmentation fault (It also crashes when running "ssh -i x.pub user at host", but that's less interesting.) Steve -- http://www.steve.org.uk/ -------------- next part -------------- A non-text attachment was scrubbed... Name: crash.min.pub.gz Type: application/gzip Size: 41 bytes Desc: not available URL: From depesz at depesz.com Fri Oct 16 01:34:43 2015 From: depesz at depesz.com (hubert depesz lubaczewski) Date: Thu, 15 Oct 2015 16:34:43 +0200 Subject: Is there any solution, or even work on, limiting which keys gets forwarded where? Message-ID: <20151015143443.GA16054@depesz.com> Hi, I'm in a situation where I'm using multiple SSH keys, each to connect to different set of servers. I can't load/unload keys on demand, as I usually am connected to at least 2 of such sets. But - some rogue "root", could get access to my agent-forwarding socket, and in turn, get access to keys loaded to agent (not in terms of obtaining the key, but being able to use it to log to server he shouldn't be able to). As I understand the only solution is to run multiple ssh-agents, and load each key to only one of them, and then, before connecting, pick which agent to choose. But this is pretty tedious, and error-prone. Is there any ready solution that could be used, or perhaps a work on incorporating key-filtering to ssh itself? Best regards, depesz -- The best thing about modern society is how easy it is to avoid contact with it. http://depesz.com/ From djm at mindrot.org Fri Oct 16 01:39:53 2015 From: djm at mindrot.org (Damien Miller) Date: Fri, 16 Oct 2015 01:39:53 +1100 (AEDT) Subject: Segfault on invalid SSH keys. In-Reply-To: <20151015055923.GA6306@steve.org.uk> References: <1444887176.1976.0@ssh.steve.org.uk> <20151015055923.GA6306@steve.org.uk> Message-ID: On Thu, 15 Oct 2015, Steve Kemp wrote: > > > Via fuzzing I discovered a key which will cause > > > the ssh-keygen process to segfault when fingerprinting > > > via: > > > > > > ssh-keygen -l -f bogus.key > > > > Could you please share the key that causes this problem? > > The key was attached to the referenced bug report, but > please find attached a copy to this mail. > > Usage is: > > $ gunzip crash.min.pub.gz > $ ssh-keygen -l -f ./crash.min.pub > Segmentation fault What version of OpenSSH are you using? I don't see a crash with 7.1 or HEAD: [djm at laptop openssh]$ ssh-keygen -lf /tmp/crash.min.pub line 2 too long: 4... /tmp/crash.min.pub is not a public key file. -d From steve at steve.org.uk Fri Oct 16 02:23:24 2015 From: steve at steve.org.uk (Steve Kemp) Date: Thu, 15 Oct 2015 15:23:24 +0000 Subject: Segfault on invalid SSH keys. Message-ID: <1444922604.27105.0@ssh.steve.org.uk> > > $ gunzip crash.min.pub.gz > > $ ssh-keygen -l -f ./crash.min.pub > > Segmentation fault > > What version of OpenSSH are you using? I don't see a crash with 7.1 or > HEAD: Debian's wheezy release, which identifies as: OpenSSH_6.0p1 Debian-4+deb7u2, OpenSSL 1.0.1e 11 Feb 2013 Debian's jessie release, which identifies as: OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015 Steve -- http://www.steve.org.uk/ From djm at mindrot.org Fri Oct 16 02:56:39 2015 From: djm at mindrot.org (Damien Miller) Date: Fri, 16 Oct 2015 02:56:39 +1100 (AEDT) Subject: Segfault on invalid SSH keys. In-Reply-To: <1444922604.27105.0@ssh.steve.org.uk> References: <1444922604.27105.0@ssh.steve.org.uk> Message-ID: On Thu, 15 Oct 2015, Steve Kemp wrote: > > > $ gunzip crash.min.pub.gz > > > $ ssh-keygen -l -f ./crash.min.pub > > > Segmentation fault > > > > What version of OpenSSH are you using? I don't see a crash with 7.1 or > > HEAD: > > Debian's wheezy release, which identifies as: > OpenSSH_6.0p1 Debian-4+deb7u2, OpenSSL 1.0.1e 11 Feb 2013 > > Debian's jessie release, which identifies as: > OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015 ok, I can reproduce it in 6.6, but it's fixed in 6.8. -d From steve at steve.org.uk Fri Oct 16 05:54:42 2015 From: steve at steve.org.uk (Steve Kemp) Date: Thu, 15 Oct 2015 18:54:42 +0000 Subject: Segfault on invalid SSH keys. Message-ID: <1444935282.4518.0@ssh.steve.org.uk> > > Debian's wheezy release, which identifies as: > > OpenSSH_6.0p1 Debian-4+deb7u2, OpenSSL 1.0.1e 11 Feb 2013 > > > > Debian's jessie release, which identifies as: > > OpenSSH_6.7p1 Debian-5, OpenSSL 1.0.1k 8 Jan 2015 > > ok, I can reproduce it in 6.6, but it's fixed in 6.8. Thanks for checking. I guess a CVE would make tracking useful for the future, but it is low risk DoS for most people, so I'll not push it :) Steve -- http://www.steve.org.uk/ From dkg at fifthhorseman.net Fri Oct 16 07:15:03 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 15 Oct 2015 16:15:03 -0400 Subject: Is there any solution, or even work on, limiting which keys gets forwarded where? In-Reply-To: <20151015143443.GA16054@depesz.com> References: <20151015143443.GA16054@depesz.com> Message-ID: <87io67rirc.fsf@alice.fifthhorseman.net> On Thu 2015-10-15 10:34:43 -0400, hubert depesz lubaczewski wrote: > I'm in a situation where I'm using multiple SSH keys, each to connect to > different set of servers. > > I can't load/unload keys on demand, as I usually am connected to at > least 2 of such sets. > > But - some rogue "root", could get access to my agent-forwarding socket, > and in turn, get access to keys loaded to agent (not in terms of > obtaining the key, but being able to use it to log to server he > shouldn't be able to). > > As I understand the only solution is to run multiple ssh-agents, and > load each key to only one of them, and then, before connecting, pick > which agent to choose. the better solution is to avoid forwarding an agent entirely, usually by using a "jumphost" instead. Have you tried and considered this approach? this approach doesn't permit any compromised intermediary machine any access at all to your agent. if the intermediary machine (the "jumphost") is jumphost.example, and you are trying to reach bar.example.com (which is behind the firewall), you would do: ssh -oProxyCommand='ssh jumphost.example -W %h:%p' bar.example.com (this can also be placed in ~/.ssh/config, of course). Another approach, if you find you must forward your agent, is to load all keys in your agent with confirmation prompt required (ssh-add -c) so that your local machine is still in control of when the different keys get used. There may be other approaches under development (some have been discussed on this list recently) but please make sure you've considered the jumphost approach, as it is strictly better than forwarded agents in all cases except for large data transfers between the two remote hosts. --dkg From djm at mindrot.org Fri Oct 16 07:36:05 2015 From: djm at mindrot.org (Damien Miller) Date: Fri, 16 Oct 2015 07:36:05 +1100 (AEDT) Subject: Segfault on invalid SSH keys. In-Reply-To: <1444935282.4518.0@ssh.steve.org.uk> References: <1444935282.4518.0@ssh.steve.org.uk> Message-ID: On Thu, 15 Oct 2015, Steve Kemp wrote: > > ok, I can reproduce it in 6.6, but it's fixed in 6.8. > > Thanks for checking. I guess a CVE would make tracking useful for > the future, but it is low risk DoS for most people, so I'll not push > it :) There's no vulnerability here - it's an unexploitable NULL dereference. I can't see how it would be a denial of service either, because attempting to parse they key was always going to yield a fatal() exit anyway. -d From nkadel at gmail.com Fri Oct 16 10:02:58 2015 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Thu, 15 Oct 2015 19:02:58 -0400 Subject: Is there any solution, or even work on, limiting which keys gets forwarded where? In-Reply-To: <20151015143443.GA16054@depesz.com> References: <20151015143443.GA16054@depesz.com> Message-ID: On Thu, Oct 15, 2015 at 10:34 AM, hubert depesz lubaczewski wrote: > Hi, > > I'm in a situation where I'm using multiple SSH keys, each to connect to > different set of servers. > > I can't load/unload keys on demand, as I usually am connected to at > least 2 of such sets. I *just* went through some of this, to distinguish between github SSH "deploykeys" and my personal key when connected to a remote server for which I may wish to publish updates to github. I personally now set up a .ssh/config with "Host" entries specified for different services and different "IdentityFile" services, to ensure use of one local key or the other for a particular "Host" as designated in .ssh/config. This does not require a real CNAME or valid DNS for the target host, and lends itself well to automated services where one upstream git repo requires a different SSH key than another. This does mean a private key on the server, which is its own risk. But for automated, unattended git deployment, you make tradeoffs. Nico Kadel-Garcia > But - some rogue "root", could get access to my agent-forwarding socket, > and in turn, get access to keys loaded to agent (not in terms of > obtaining the key, but being able to use it to log to server he > shouldn't be able to). > > As I understand the only solution is to run multiple ssh-agents, and > load each key to only one of them, and then, before connecting, pick > which agent to choose. > > But this is pretty tedious, and error-prone. > > Is there any ready solution that could be used, or perhaps a work on > incorporating key-filtering to ssh itself? > > Best regards, > > depesz > > -- > The best thing about modern society is how easy it is to avoid contact with it. > http://depesz.com/ > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From steve at steve.org.uk Fri Oct 16 16:08:29 2015 From: steve at steve.org.uk (Steve Kemp) Date: Fri, 16 Oct 2015 05:08:29 +0000 Subject: Segfault on invalid SSH keys. Message-ID: <1444972109.9280.0@ssh.steve.org.uk> > There's no vulnerability here - it's an unexploitable NULL dereference. I am considering the case where a user uploads a public-key to a service, and ssh-keygen is used to display a fingerprint of that key. (I run such a service, the github key-management page is another example - although they don't do things the same way my service crashed on the bogus key, theirs didn't!) Anyway thanks again for looking at it, in the future I'll try against HEAD before reporting things. Steve -- http://www.steve.org.uk/ From depesz at depesz.com Fri Oct 16 21:46:44 2015 From: depesz at depesz.com (hubert depesz lubaczewski) Date: Fri, 16 Oct 2015 12:46:44 +0200 Subject: Is there any solution, or even work on, limiting which keys gets forwarded where? In-Reply-To: <87io67rirc.fsf@alice.fifthhorseman.net> References: <20151015143443.GA16054@depesz.com> <87io67rirc.fsf@alice.fifthhorseman.net> Message-ID: <20151016104644.GA30266@depesz.com> On Thu, Oct 15, 2015 at 04:15:03PM -0400, Daniel Kahn Gillmor wrote: > if the intermediary machine (the "jumphost") is jumphost.example, and > you are trying to reach bar.example.com (which is behind the firewall), > you would do: > ssh -oProxyCommand='ssh jumphost.example -W %h:%p' bar.example.com We use jump host, but there are literally hundreds of hosts behind it. And since I often need to run things on multiple hosts, I ssh to jump host, start tmux session, and ssh from there wherever I need. Not to mention that in case like above, I would have to type the password to key two times, which is complicated, to put it lightly, as I use very long, very secure passphrases. > Another approach, if you find you must forward your agent, is to load > all keys in your agent with confirmation prompt required (ssh-add -c) > so that your local machine is still in control of when the different > keys get used. Yeah, but that will (from what I understand from man) re-ask for my password, which is highly impractical given the above passphrase situation. Best regards, depesz From depesz at depesz.com Fri Oct 16 21:47:58 2015 From: depesz at depesz.com (hubert depesz lubaczewski) Date: Fri, 16 Oct 2015 12:47:58 +0200 Subject: Is there any solution, or even work on, limiting which keys gets forwarded where? In-Reply-To: References: <20151015143443.GA16054@depesz.com> Message-ID: <20151016104758.GB30266@depesz.com> On Thu, Oct 15, 2015 at 07:02:58PM -0400, Nico Kadel-Garcia wrote: > On Thu, Oct 15, 2015 at 10:34 AM, hubert depesz lubaczewski > wrote: > > Hi, > > > > I'm in a situation where I'm using multiple SSH keys, each to connect to > > different set of servers. > > > > I can't load/unload keys on demand, as I usually am connected to at > > least 2 of such sets. > > I *just* went through some of this, to distinguish between github SSH > "deploykeys" and my personal key when connected to a remote server for > which I may wish to publish updates to github. > > I personally now set up a .ssh/config with "Host" entries specified > for different services and different "IdentityFile" services, to > ensure use of one local key or the other for a particular "Host" as > designated in .ssh/config. This does not require a real CNAME or valid > DNS for the target host, and lends itself well to automated services > where one upstream git repo requires a different SSH key than another. > > This does mean a private key on the server, which is its own risk. But > for automated, unattended git deployment, you make tradeoffs. So it's unacceptable for me - I have to have access to production servers - access to them, without password, from jump host, shouldn't be possible, but we can use ssh agent - which solves the problem. But the flip side is that using agent opens access to all keys in it from any connected host :( depesz From peter at stuge.se Sat Oct 17 01:33:37 2015 From: peter at stuge.se (Peter Stuge) Date: Fri, 16 Oct 2015 16:33:37 +0200 Subject: Is there any solution, or even work on, limiting which keys gets forwarded where? In-Reply-To: <20151016104644.GA30266@depesz.com> References: <20151015143443.GA16054@depesz.com> <87io67rirc.fsf@alice.fifthhorseman.net> <20151016104644.GA30266@depesz.com> Message-ID: <20151016143337.3694.qmail@stuge.se> hubert depesz lubaczewski wrote: > > Another approach, if you find you must forward your agent, is to load > > all keys in your agent with confirmation prompt required (ssh-add -c) > > so that your local machine is still in control of when the different > > keys get used. > > Yeah, but that will (from what I understand from man) re-ask for my > password, which is highly impractical given the above passphrase > situation. You should try it out. No, the agent on your client only asks for confirmation to use the key (enter=yes, type anything+enter=no) not for the passphrase. //Peter From djm at mindrot.org Sat Oct 17 06:07:44 2015 From: djm at mindrot.org (Damien Miller) Date: Sat, 17 Oct 2015 06:07:44 +1100 (AEDT) Subject: FYI HEAD now refuses <1024 bit DH keys in group-exchange Message-ID: Hi, I just committed a change to HEAD that raises the minimum Diffie-Hellman group size that the client will accept from 1024 to 2048 bits. Connections to well-behaved servers should not be affected by this change, but I've identified at least one case where a misconfigured server can cause connection failure. The errors look like: > ssh_dispatch_run_fatal: Connection to 10.1.1.1: DH GEX group out of > range The problematic software is OpenSSH <3.9 or Sun_SSH (all versions). It will use a fixed 1024 bit DH group as an implicit fallback if /etc/ssh/moduli is missing, unreadable or empty. Hopefully nobody is still using such an ancient OpenSSH (>10 years old!), so the Sun_SSH case is more likely. If this change prevents you from connecting to a server, then the workaround is to explicitly use the weak diffie-hellman-group1-sha1 key exchange method to connect, i.e. ssh -oKexAlgorithms=diffie-hellman-group1-sha1 user at host Once you are logged in, restore a good /etc/ssh/moduli (you can copy one from OpenSSH HEAD[1]), log out and try to log in again without the KexAlgorithms option. It should work fine. We always appreaciate reports from people who are able to test HEAD in their environments and I'm particularly interested in reports of similar failures. -d [1] https://anongit.mindrot.org/openssh.git/plain/moduli From keisial at gmail.com Sat Oct 17 08:58:33 2015 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Fri, 16 Oct 2015 23:58:33 +0200 Subject: FYI HEAD now refuses <1024 bit DH keys in group-exchange In-Reply-To: References: Message-ID: <56217309.6070409@gmail.com> On 16/10/15 21:07, Damien Miller wrote: > Hi, > > I just committed a change to HEAD that raises the minimum Diffie-Hellman > group size that the client will accept from 1024 to 2048 bits. > Connections to well-behaved servers should not be affected by this > change, but I've identified at least one case where a misconfigured > server can cause connection failure. The errors look like: > >> ssh_dispatch_run_fatal: Connection to 10.1.1.1: DH GEX group out of >> range > The problematic software is OpenSSH<3.9 or Sun_SSH (all versions). > It will use a fixed 1024 bit DH group as an implicit fallback if > /etc/ssh/moduli is missing, unreadable or empty. Thanks for the heads-up. We know that people will find that a bit cryptic. What about showing a message like: "A Diffie-Hellman group of %d bits is too weak. Does the server have a /etc/ssh/moduli file with suitable values?" Best regards From kaleb at wolfssl.com Tue Oct 20 05:04:19 2015 From: kaleb at wolfssl.com (Kaleb Himes) Date: Mon, 19 Oct 2015 12:04:19 -0600 Subject: Inter-op and port (wolfSSL + openSSH) In-Reply-To: References: <20150830160842.GB6818@hatter.bewilderbeest.net> Message-ID: Hi Damien and openSSH, We have discussed internally the resources and time required to implementing a "crypto abstraction layer". Unfortunately at the current time we do not have the engineering resources/man power to be able to assign this task. We are happy to submit a pull request on our current modifications and to support those changes going forward. Let us know your thoughts. Best Regards, The wolfSSL Team. Kaleb Himes www.wolfssl.com kaleb at wolfssl.com Skype: kaleb.himes +1 406 381 9556 On Thu, Sep 3, 2015 at 9:12 PM, Damien Miller wrote: > On Tue, 1 Sep 2015, Kaleb Himes wrote: > > > Hi openSSH, > > > > After having time to review our licensing model and perhaps play around > > with our product we were checking back to see what your thoughts might > be. > > > > We also wanted to point out that we only desire to give end-users an > > alternative option to compiling with openSSL. > > End users who configure with the "--enable-wolfssl" option would need to > > consider licensing. > > That would be a part of their project evaluation phase. Any patch we > submit > > to you would retain your licensing model. > > Hi, > > I'm not opposed to making OpenSSH play nicer with non-OpenSSL crypto > libraries, but I am worried that attempts to do so could yield a worse > #ifdef maze than we already have. > > Microsoft will need to figure out how to handle crypto in their port > of OpenSSH since they'll likely be using CryptoAPI instead of OpenSSL, > so perhaps there is an opportunity to find some nice way of abstracting > out all the BIGNUM, RSA, DSA, EC*, etc out that suits you both (and > cleans up core OpenSSH along the way). > > -d > > From phil.pennock at globnix.org Tue Oct 20 10:35:30 2015 From: phil.pennock at globnix.org (Phil Pennock) Date: Mon, 19 Oct 2015 23:35:30 +0000 Subject: Is there any solution, or even work on, limiting which keys gets forwarded where? In-Reply-To: <20151016104758.GB30266@depesz.com> References: <20151015143443.GA16054@depesz.com> <20151016104758.GB30266@depesz.com> Message-ID: <20151019233530.GA35560@tower.spodhuis.org> On 2015-10-16 at 12:47 +0200, hubert depesz lubaczewski wrote: > But the flip side is that using agent opens access to all keys in it > from any connected host :( I scripted a setup which generates different `config` and `known_hosts` files in ~/.ssh and has a wrapper around invoking ssh which uses those files. The wrapper looks in an index file (also generated) to decide which ssh-keys need to be loaded for which destinations and starts a dedicated ssh-agent before connecting. This works well for our use-case. Persistent connection to a jump-host; SSH key to reach the jump-host doesn't need to be (and isn't) the key which is loaded into the agent (so that the key passed around for use remotely does not grant access to the perimeter). It's not the cleanest and requires strict hygiene to protect against people helpfully setting the internal key to grant access to the perimeter class of machines. The core boils down to (with some renaming): eval $(ssh-agent -s) #... stuff including loading the correct keys if ssh-add -l >|/dev/null 2>&1 ; then true # all is good else echo >&2 "${0}: WARNING: NO SSH KEYS FOUND LOADED INTO AGENT" eval $(ssh-agent -k) exit 1 fi set +e ${SSH_CMD:-ssh} -F "${YourSpecialConfigFile:?}" "$@" exit_status=$? set -e eval $(ssh-agent -k) exit $exit_status where the stanzas in the config file should include: IdentityFile path/to/perimeter/access IdentitiesOnly yes UserKnownHostsFile ~/.ssh/your_special_config_file StrictHostKeyChecking yes ForwardAgent yes -Phil From keisial at gmail.com Tue Oct 20 10:31:46 2015 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Tue, 20 Oct 2015 01:31:46 +0200 Subject: Is there any solution, or even work on, limiting which keys gets forwarded where? In-Reply-To: <20151016104644.GA30266@depesz.com> References: <20151015143443.GA16054@depesz.com> <87io67rirc.fsf@alice.fifthhorseman.net> <20151016104644.GA30266@depesz.com> Message-ID: <56257D62.1000103@gmail.com> On 16/10/15 12:46, hubert depesz lubaczewski wrote: > On Thu, Oct 15, 2015 at 04:15:03PM -0400, Daniel Kahn Gillmor wrote: >> > if the intermediary machine (the "jumphost") is jumphost.example, and >> > you are trying to reach bar.example.com (which is behind the firewall), >> > you would do: >> > ssh -oProxyCommand='ssh jumphost.example -W %h:%p' bar.example.com > We use jump host, but there are literally hundreds of hosts behind it. > And since I often need to run things on multiple hosts, I ssh to jump > host, start tmux session, and ssh from there wherever I need. You can run tmux locally. Don't worry about having to add the -oProxyCommand='ssh jumphost.example -W %h:%p' each time. That can be abstracted in the ssh_config. You can simply provide the name as you used on the jumphos, but have ssh automatically connect to it "the right way". If you are concerned about having to perform two ssh logins (automatically, as performed by the key authentication) per connection, you can make it use a master ssh connection so there's a single connection to the jumphost through all the others are tunneled. From depesz at depesz.com Tue Oct 20 18:08:11 2015 From: depesz at depesz.com (hubert depesz lubaczewski) Date: Tue, 20 Oct 2015 09:08:11 +0200 Subject: Is there any solution, or even work on, limiting which keys gets forwarded where? In-Reply-To: <56257D62.1000103@gmail.com> References: <20151015143443.GA16054@depesz.com> <87io67rirc.fsf@alice.fifthhorseman.net> <20151016104644.GA30266@depesz.com> <56257D62.1000103@gmail.com> Message-ID: <20151020070811.GB9714@depesz.com> On Tue, Oct 20, 2015 at 01:31:46AM +0200, ?ngel Gonz?lez wrote: > On 16/10/15 12:46, hubert depesz lubaczewski wrote: > >On Thu, Oct 15, 2015 at 04:15:03PM -0400, Daniel Kahn Gillmor wrote: > >>> if the intermediary machine (the "jumphost") is jumphost.example, and > >>> you are trying to reach bar.example.com (which is behind the firewall), > >>> you would do: > >>> ssh -oProxyCommand='ssh jumphost.example -W %h:%p' bar.example.com > >We use jump host, but there are literally hundreds of hosts behind it. > >And since I often need to run things on multiple hosts, I ssh to jump > >host, start tmux session, and ssh from there wherever I need. > You can run tmux locally. Don't worry about having to add the > > -oProxyCommand='ssh jumphost.example -W %h:%p' each time. That can be abstracted > in the ssh_config. You can simply provide the name as you used on the jumphos, but > have ssh automatically connect to it "the right way". If I run tmux locally, and my network connection dies, then I lose what I was doing on remote host. Tmux is there to protect me from losing work (let's say, in the middle of datbase upgrade) due to network issues). > If you are concerned about having to perform two ssh logins (automatically, as > performed by the key authentication) per connection, you can make it use a master > ssh connection so there's a single connection to the jumphost through all the others > are tunneled. I'm concerned about safety (someone having access to my agent socket, shouldn't really have access to all my keys), and convenience (not having to retype the password every time). Best regards, depesz -- The best thing about modern society is how easy it is to avoid contact with it. http://depesz.com/ From phil at hands.com Tue Oct 20 18:23:06 2015 From: phil at hands.com (Philip Hands) Date: Tue, 20 Oct 2015 08:23:06 +0100 Subject: Is there any solution, or even work on, limiting which keys gets forwarded where? In-Reply-To: <20151019233530.GA35560@tower.spodhuis.org> References: <20151015143443.GA16054@depesz.com> <20151016104758.GB30266@depesz.com> <20151019233530.GA35560@tower.spodhuis.org> Message-ID: <87fv16atr9.fsf@whist.hands.com> Phil Pennock writes: > On 2015-10-16 at 12:47 +0200, hubert depesz lubaczewski wrote: >> But the flip side is that using agent opens access to all keys in it >> from any connected host :( > > I scripted a setup which generates different `config` and `known_hosts` > files in ~/.ssh and has a wrapper around invoking ssh which uses those > files. The wrapper looks in an index file (also generated) to decide > which ssh-keys need to be loaded for which destinations and starts a > dedicated ssh-agent before connecting. > > This works well for our use-case. Persistent connection to a jump-host; > SSH key to reach the jump-host doesn't need to be (and isn't) the key > which is loaded into the agent (so that the key passed around for use > remotely does not grant access to the perimeter). It's not the cleanest > and requires strict hygiene to protect against people helpfully setting > the internal key to grant access to the perimeter class of machines. > > The core boils down to (with some renaming): > > eval $(ssh-agent -s) > #... stuff including loading the correct keys > if ssh-add -l >|/dev/null 2>&1 ; then > true # all is good > else > echo >&2 "${0}: WARNING: NO SSH KEYS FOUND LOADED INTO AGENT" > eval $(ssh-agent -k) > exit 1 > fi > set +e > ${SSH_CMD:-ssh} -F "${YourSpecialConfigFile:?}" "$@" > exit_status=$? > set -e > eval $(ssh-agent -k) > exit $exit_status > > where the stanzas in the config file should include: > > IdentityFile path/to/perimeter/access > IdentitiesOnly yes > UserKnownHostsFile ~/.ssh/your_special_config_file > StrictHostKeyChecking yes > ForwardAgent yes If you used the ProxyCommand ssh -W trick with that, you would not need the ForwardAgent, at which point each internal server would never see the jumphost key but also the jumphost would never see any of the internal keys, because they'd be going over the still-encrypted links that are being forwarded to the internal servers. This also means that the hostkey checking on the internal servers is done at your end, and not on the jumphost, so one doesn't need to have any real trust in the jumphost as it's just acting as a router really. 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: From phil at hands.com Tue Oct 20 19:56:27 2015 From: phil at hands.com (Philip Hands) Date: Tue, 20 Oct 2015 09:56:27 +0100 Subject: Is there any solution, or even work on, limiting which keys gets forwarded where? In-Reply-To: <20151020070811.GB9714@depesz.com> References: <20151015143443.GA16054@depesz.com> <87io67rirc.fsf@alice.fifthhorseman.net> <20151016104644.GA30266@depesz.com> <56257D62.1000103@gmail.com> <20151020070811.GB9714@depesz.com> Message-ID: <87a8rdc404.fsf@whist.hands.com> hubert depesz lubaczewski writes: > On Tue, Oct 20, 2015 at 01:31:46AM +0200, ?ngel Gonz?lez wrote: >> On 16/10/15 12:46, hubert depesz lubaczewski wrote: >> >On Thu, Oct 15, 2015 at 04:15:03PM -0400, Daniel Kahn Gillmor wrote: >> >>> if the intermediary machine (the "jumphost") is jumphost.example, and >> >>> you are trying to reach bar.example.com (which is behind the firewall), >> >>> you would do: >> >>> ssh -oProxyCommand='ssh jumphost.example -W %h:%p' bar.example.com >> >We use jump host, but there are literally hundreds of hosts behind it. >> >And since I often need to run things on multiple hosts, I ssh to jump >> >host, start tmux session, and ssh from there wherever I need. >> You can run tmux locally. Don't worry about having to add the >> >> -oProxyCommand='ssh jumphost.example -W %h:%p' each time. That can be abstracted >> in the ssh_config. You can simply provide the name as you used on the jumphos, but >> have ssh automatically connect to it "the right way". > > If I run tmux locally, and my network connection dies, then I lose what > I was doing on remote host. > Tmux is there to protect me from losing work (let's say, in the middle > of datbase upgrade) due to network issues). > >> If you are concerned about having to perform two ssh logins (automatically, as >> performed by the key authentication) per connection, you can make it use a master >> ssh connection so there's a single connection to the jumphost through all the others >> are tunneled. > > I'm concerned about safety (someone having access to my agent socket, > shouldn't really have access to all my keys), and convenience (not > having to retype the password every time). The way to address that concern is to never forward the agent off of the local machine (which can be acheived via the ProxyCommand approach), then you don't even have to consider which remote hosts you trust with which keys. 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: From dkg at fifthhorseman.net Wed Oct 21 00:33:46 2015 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 20 Oct 2015 09:33:46 -0400 Subject: Is there any solution, or even work on, limiting which keys gets forwarded where? In-Reply-To: <20151020070811.GB9714@depesz.com> References: <20151015143443.GA16054@depesz.com> <87io67rirc.fsf@alice.fifthhorseman.net> <20151016104644.GA30266@depesz.com> <56257D62.1000103@gmail.com> <20151020070811.GB9714@depesz.com> Message-ID: <87lhaxis05.fsf@alice.fifthhorseman.net> On Tue 2015-10-20 03:08:11 -0400, hubert depesz lubaczewski wrote: > If I run tmux locally, and my network connection dies, then I lose what > I was doing on remote host. > Tmux is there to protect me from losing work (let's say, in the middle > of datbase upgrade) due to network issues). if you want that kind of protection, run tmux (or GNU screen) on the remote host itself. that will protect you from outages on the jumphost as well. > I'm concerned about safety (someone having access to my agent socket, > shouldn't really have access to all my keys), and convenience (not > having to retype the password every time). a local ssh agent, not forwarded, with a controlMaster socket for the jumphost, and your keys loaded with confirmation prompt seems like the solution that would solve the most problems: ~/.ssh/config: -------------- Host jumphost.example ControlMaster autoask ControlPath ~/.ssh/masters/%r@%h:%p ProxyCommand none Host *.example ProxyCommand ssh -W %h:%p jumphost.example -------------- Before connecting, ensure that ssh-agent is running and do: ssh-add -c /path/to/my/key You'll have to type your password exactly once. When you get a prompt for the use of your key, or a prompt to use the control master, you can just hit "OK" or type "yes". if your workflow is just to connect to one remote machine from your local computer, do: ssh -t foo.example tmux If your workflow is to connect to multiple machines, start with: ssh jumphost.example and leave that session open while you do the rest of your work from your local computer.: ssh -t foo.example tmux ssh -t bar.example tmux hth, --dkg From depesz at depesz.com Wed Oct 21 01:00:02 2015 From: depesz at depesz.com (hubert depesz lubaczewski) Date: Tue, 20 Oct 2015 16:00:02 +0200 Subject: Is there any solution, or even work on, limiting which keys gets forwarded where? In-Reply-To: <87lhaxis05.fsf@alice.fifthhorseman.net> References: <20151015143443.GA16054@depesz.com> <87io67rirc.fsf@alice.fifthhorseman.net> <20151016104644.GA30266@depesz.com> <56257D62.1000103@gmail.com> <20151020070811.GB9714@depesz.com> <87lhaxis05.fsf@alice.fifthhorseman.net> Message-ID: <20151020140001.GA12210@depesz.com> On Tue, Oct 20, 2015 at 09:33:46AM -0400, Daniel Kahn Gillmor wrote: > On Tue 2015-10-20 03:08:11 -0400, hubert depesz lubaczewski wrote: > > If I run tmux locally, and my network connection dies, then I lose what > > I was doing on remote host. > > Tmux is there to protect me from losing work (let's say, in the middle > > of datbase upgrade) due to network issues). > > if you want that kind of protection, run tmux (or GNU screen) on the > remote host itself. that will protect you from outages on the jumphost > as well. That's not an option, since I usually work on multiple hosts behind single jump host at once. Anyway - I need agent forwarding, and from what I gather - there is no solution, or work on solution, that would allow me to limit which keys gets forwarded. That's fine, really (kindof, but it's better to know that there is no such thing than spend hours hunting for something that just doesn't exist). depesz From sanumesh at in.ibm.com Wed Oct 21 15:18:00 2015 From: sanumesh at in.ibm.com (Sandeep Umesh) Date: Wed, 21 Oct 2015 09:48:00 +0530 Subject: SSH and Kerberos usage Message-ID: <201510210418.t9L4IqVA015048@d28av02.in.ibm.com> Hello I am not sure if this has already been discussed over time, but I have a situation where I am not able to ssh with kerberos principal name. Here is the scenario - currently I am using openSSH 6.0 version and I have set the following - in sshd_config file - KerberosAuthentication yes GSSAPIAuthentication yes GSSAPICleanupCredentials yes in ssh_config file - GSSAPIAuthentication yes GSSAPIDelegateCredentials yes After I obtain the kerberos TGT using - kinit user_name and try to login as ssh user_name at hostname, it works fine and I am able to login without a password prompt . However, if I try to login as ssh user_name at realm_name@hostname then I am prompted for the password. I think the principal name to local name conversation is not happening properly which I am yet to verify. But is there any other solution available for this? Thanks Regards Sandeep From keisial at gmail.com Thu Oct 22 08:26:35 2015 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Wed, 21 Oct 2015 23:26:35 +0200 Subject: SSH and Kerberos usage In-Reply-To: <201510210418.t9L4IqVA015048@d28av02.in.ibm.com> References: <201510210418.t9L4IqVA015048@d28av02.in.ibm.com> Message-ID: <5628030B.10701@gmail.com> On 21/10/15 06:18, Sandeep Umesh wrote: > However, if I try to login as ssh user_name at realm_name@hostname then I am > prompted for the password. > > I think the principal name to local name conversation is not happening > properly which I am yet to verify. But is there any other solution > available for this? Does ssh -l 'user_name at realm_name' hostname make a difference here? From keisial at gmail.com Thu Oct 22 08:31:02 2015 From: keisial at gmail.com (=?UTF-8?B?w4FuZ2VsIEdvbnrDoWxleg==?=) Date: Wed, 21 Oct 2015 23:31:02 +0200 Subject: Is there any solution, or even work on, limiting which keys gets forwarded where? In-Reply-To: <20151020140001.GA12210@depesz.com> References: <20151015143443.GA16054@depesz.com> <87io67rirc.fsf@alice.fifthhorseman.net> <20151016104644.GA30266@depesz.com> <56257D62.1000103@gmail.com> <20151020070811.GB9714@depesz.com> <87lhaxis05.fsf@alice.fifthhorseman.net> <20151020140001.GA12210@depesz.com> Message-ID: <56280416.5050509@gmail.com> On 20/10/15 16:00, hubert depesz lubaczewski wrote: > On Tue, Oct 20, 2015 at 09:33:46AM -0400, Daniel Kahn Gillmor wrote: >> On Tue 2015-10-20 03:08:11 -0400, hubert depesz lubaczewski wrote: >>> If I run tmux locally, and my network connection dies, then I lose what >>> I was doing on remote host. >>> Tmux is there to protect me from losing work (let's say, in the middle >>> of datbase upgrade) due to network issues). >> if you want that kind of protection, run tmux (or GNU screen) on the >> remote host itself. that will protect you from outages on the jumphost >> as well. > That's not an option, since I usually work on multiple hosts behind > single jump host at once. You can run a tmux locally where you load several hosts running screen. > Anyway - I need agent forwarding, I'm not so sure about this point. > and from what I gather - there is no > solution, or work on solution, that would allow me to limit which keys > gets forwarded. Right. The only solution currently available is to play with several ssh agents, or changing the loaded keys in the agent (in addition of the ask-before-use feature). > That's fine, really (kindof, but it's better to know > that there is no such thing than spend hours hunting for something that > just doesn't exist). There's no such thing :) We have discussed that in the past, but there's no code doing that (yet). Best regards From deengert at gmail.com Thu Oct 22 13:24:30 2015 From: deengert at gmail.com (Douglas E Engert) Date: Wed, 21 Oct 2015 21:24:30 -0500 Subject: SSH and Kerberos usage In-Reply-To: <201510210418.t9L4IqVA015048@d28av02.in.ibm.com> References: <201510210418.t9L4IqVA015048@d28av02.in.ibm.com> Message-ID: <562848DE.8050403@gmail.com> On 10/20/2015 11:18 PM, Sandeep Umesh wrote: > Hello > > I am not sure if this has already been discussed over time, but I have a > situation where I am not able to ssh with kerberos principal name. > > Here is the scenario - > currently I am using openSSH 6.0 version and I have set the following - > in sshd_config file - > KerberosAuthentication yes > GSSAPIAuthentication yes > GSSAPICleanupCredentials yes > in ssh_config file - > GSSAPIAuthentication yes > GSSAPIDelegateCredentials yes > > After I obtain the kerberos TGT using - kinit user_name and try to login > as ssh user_name at hostname, it works fine and I am able to login without a > password prompt . > However, if I try to login as ssh user_name at realm_name@hostname then I am > prompted for the password. I don't think user at realm@hostname will work. SSh deals with unix usernames, Kerberos deals with users in realms. In the general case, you could have username on the client and different remote username on the server, and principal that does not match either. Are both the client and server in the same realm? If the username on the server is not the same as the principal name, you may need the Kerberos ~/.k5login file in the home directory of the user on the server. > > I think the principal name to local name conversation is not happening > properly which I am yet to verify. But is there any other solution > available for this? > Thanks > > Regards > Sandeep > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Douglas E. Engert From lukeglazebrook at gmail.com Tue Oct 27 01:49:41 2015 From: lukeglazebrook at gmail.com (Luke Glazebrook) Date: Mon, 26 Oct 2015 14:49:41 +0000 Subject: Only seems to work for local admin on Windows Server 2012R2, any idea's? Thanks for replying if you get time to read this :) Message-ID: Hi OpenSSH people, I would be extremely grateful if you could provide some advice on an issue I am facing. Installed OpenSSH 7.1 on Server 2012, it works great for the local administrator account however not for any others L Are you able to give me a pointer/clue as to what silly mistake I am presumably making? After the install I also performed the following steps to try and get it working however it only work the local admin http://diddy.boot-land.net/ssh/files/ssh_openssh.htm From simonzack at gmail.com Tue Oct 27 13:57:59 2015 From: simonzack at gmail.com (Simon) Date: Tue, 27 Oct 2015 13:57:59 +1100 Subject: possibility of a RemoteCommand option in the ssh config file Message-ID: <562EE837.10101@gmail.com> Hi ssh devs, I'm wondering about the possibility of adding a "RemoteCommand" option in the ssh config file, which is what -t does in the command line. I personally need this to run a small user background process on ssh login, and it makes more sense to me to put this in the config file since I do some port forwarding too for this process. I did some research and there have been some similar requests over the years so I think there is a need: - http://serverfault.com/questions/56086/ssh-how-to-include-t-command-in-the-ssh-config-file - http://unix.stackexchange.com/questions/214004/ssh-config-auto-execute-remote-command - http://superuser.com/questions/124101/run-a-remote-command-using-ssh-config-file - http://unix.stackexchange.com/questions/91747/ssh-config-specify-command-to-be-executed-on-the-remote-machine-upon-login What do you think? Cheers, Simon From dtucker at zip.com.au Tue Oct 27 15:00:48 2015 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 27 Oct 2015 15:00:48 +1100 Subject: possibility of a RemoteCommand option in the ssh config file In-Reply-To: <562EE837.10101@gmail.com> References: <562EE837.10101@gmail.com> Message-ID: On Tue, Oct 27, 2015 at 1:57 PM, Simon wrote: > Hi ssh devs, > > I'm wondering about the possibility of adding a "RemoteCommand" option in > the ssh config file, which is what -t does in the command line. -t just requests that the server assign a pseudoterminal for whatever command you later give it, and it already has an equivalent in ~/.ssh/config ("RequestTTY yes"). > I personally need this to run a small user background process on ssh login, > and it makes more sense to me to put this in the config file since I do some > port forwarding too for this process. It's not clear to me what you're trying to do. If you're running a small process in the background, wouldn't the shell startup script be the right place to put it? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From reubenhwk at gmail.com Wed Oct 28 07:28:00 2015 From: reubenhwk at gmail.com (Reuben Hawkins) Date: Tue, 27 Oct 2015 13:28:00 -0700 Subject: ssh-keyscan namelist fixup Message-ID: -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-ssh-keyscan.c-fixup-output-host-namelist.patch Type: text/x-patch Size: 2091 bytes Desc: not available URL: From djm at mindrot.org Wed Oct 28 09:08:20 2015 From: djm at mindrot.org (Damien Miller) Date: Wed, 28 Oct 2015 09:08:20 +1100 (AEDT) Subject: ssh-keyscan namelist fixup In-Reply-To: References: Message-ID: On Tue, 27 Oct 2015, Reuben Hawkins wrote: > [patch] I already committed something similar: https://anongit.mindrot.org/openssh.git/commit/?id=9ada37d36003a7790 From mdb at juniper.net Thu Oct 29 12:32:16 2015 From: mdb at juniper.net (Mark D. Baushke) Date: Wed, 28 Oct 2015 18:32:16 -0700 Subject: [Bug 2464] Adding timestamp to debug messages (log.c:do_log) In-Reply-To: References: Message-ID: <51377.1446082336@eng-mail01.juniper.net> Diff updated with suggested changes (also, making the timestamp format ISO8601 compliant). Hmmm... full IOS8601 compliance would include the timzeone so the format string would be "%Y%m%dT%H%M%S%z" (and need to increase the size of the timebuf[20] by one byte or you would use gmtime() instead of localtime() and the format string "%Y%m%dT%H%M%SZ". I think gmtime() may be simpler. -- Mark From lists at spuddy.org Thu Oct 29 13:04:59 2015 From: lists at spuddy.org (Stephen Harris) Date: Wed, 28 Oct 2015 22:04:59 -0400 Subject: [Bug 2464] Adding timestamp to debug messages (log.c:do_log) In-Reply-To: <51377.1446082336@eng-mail01.juniper.net> References: <51377.1446082336@eng-mail01.juniper.net> Message-ID: <20151029020459.GA28694@mercury7.spuddy.org> On Wed, Oct 28, 2015 at 06:32:16PM -0700, Mark D. Baushke wrote: > and the format string "%Y%m%dT%H%M%SZ". I think gmtime() may be simpler. The world should live in GMT. Unfortunately people want their logs to be consitent on a machine; syslog reports in localtime so we should report in localtime :-( -- rgds Stephen From dtucker at zip.com.au Thu Oct 29 13:11:10 2015 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 29 Oct 2015 13:11:10 +1100 Subject: [Bug 2464] Adding timestamp to debug messages (log.c:do_log) In-Reply-To: <51377.1446082336@eng-mail01.juniper.net> References: <51377.1446082336@eng-mail01.juniper.net> Message-ID: On Thu, Oct 29, 2015 at 12:32 PM, Mark D. Baushke wrote: > Diff updated with suggested changes (also, making the timestamp format > ISO8601 compliant). > > Hmmm... full IOS8601 compliance would include the timzeone so the format I don't have a copy of the ISO8601 text, but the wikipedia page says "If no UTC relation information is given with a time representation, the time is assumed to be in local time." Which in this case it 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 mdb at juniper.net Thu Oct 29 13:11:05 2015 From: mdb at juniper.net (Mark D. Baushke) Date: Wed, 28 Oct 2015 19:11:05 -0700 Subject: [Bug 2464] Adding timestamp to debug messages (log.c:do_log) In-Reply-To: <20151029020459.GA28694@mercury7.spuddy.org> References: <51377.1446082336@eng-mail01.juniper.net> <20151029020459.GA28694@mercury7.spuddy.org> Message-ID: <57647.1446084665@eng-mail01.juniper.net> Stephen Harris writes: > On Wed, Oct 28, 2015 at 06:32:16PM -0700, Mark D. Baushke wrote: > > and the format string "%Y%m%dT%H%M%SZ". I think gmtime() may be simpler. > > The world should live in GMT. Unfortunately people want their logs > to be consitent on a machine; syslog reports in localtime so we should > report in localtime :-( I understand. I observed that the current patch was not a complete IS8601 timestamp as it was missing the timezeone. If localtime() is used, then %z should be added to the format which takes 21 charcters yyyymmddThhmmss-zzzz\0 or yyyymmddThhmmss+zzzz\0 that is 20 printable characters and the NUL byte to terminate the string. -- Mark From mdb at juniper.net Thu Oct 29 13:23:54 2015 From: mdb at juniper.net (Mark D. Baushke) Date: Wed, 28 Oct 2015 19:23:54 -0700 Subject: [Bug 2464] Adding timestamp to debug messages (log.c:do_log) In-Reply-To: References: <51377.1446082336@eng-mail01.juniper.net> Message-ID: <59719.1446085434@eng-mail01.juniper.net> Darren Tucker writes: > On Thu, Oct 29, 2015 at 12:32 PM, Mark D. Baushke wrote: > > Diff updated with suggested changes (also, making the timestamp format > > ISO8601 compliant). > > > > Hmmm... full IOS8601 compliance would include the timzeone so the format > > I don't have a copy of the ISO8601 text, but the wikipedia page says > "If no UTC relation information is given with a time representation, > the time is assumed to be in local time." Which in this case it is. Hmmm... I could be wrong here as I have not read the actual ISO 8601 standard since 1999, but the form 'YYYY-MM-DD HH:MM:SS' is the form where the lack of a timezone indicated local time. I do recall that a default local time was generally discouraged as being ambiguous. In any case, I am more interested in syslog() being used rather than an ISO 8601 format time and wonder what use case needs to use strftime() foromats at all. -- Mark From dtucker at zip.com.au Thu Oct 29 13:32:21 2015 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 29 Oct 2015 13:32:21 +1100 Subject: [Bug 2464] Adding timestamp to debug messages (log.c:do_log) In-Reply-To: <59719.1446085434@eng-mail01.juniper.net> References: <51377.1446082336@eng-mail01.juniper.net> <59719.1446085434@eng-mail01.juniper.net> Message-ID: On Thu, Oct 29, 2015 at 1:23 PM, Mark D. Baushke wrote: > Hmmm... I could be wrong here as I have not read the actual ISO 8601 > standard since 1999, but the form 'YYYY-MM-DD HH:MM:SS' is the form > where the lack of a timezone indicated local time. That's entirely possible, I've never read it and the text is not generally available. The wikipedia page gives an example with the "T" and without the timezone specifiier, though. > I do recall that a > default local time was generally discouraged as being ambiguous. > > In any case, I am more interested in syslog() being used ssh(1) can already do syslog: -y Send log information using the syslog(3) system module. By default this information is sent to stderr. -- 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 mstone at mathom.us Fri Oct 30 09:53:31 2015 From: mstone at mathom.us (Michael Stone) Date: Thu, 29 Oct 2015 18:53:31 -0400 Subject: [Bug 2464] Adding timestamp to debug messages (log.c:do_log) In-Reply-To: References: <51377.1446082336@eng-mail01.juniper.net> <59719.1446085434@eng-mail01.juniper.net> Message-ID: On Thu, Oct 29, 2015 at 01:32:21PM +1100, Darren Tucker wrote: >On Thu, Oct 29, 2015 at 1:23 PM, Mark D. Baushke wrote: >> Hmmm... I could be wrong here as I have not read the actual ISO 8601 >> standard since 1999, but the form 'YYYY-MM-DD HH:MM:SS' is the form >> where the lack of a timezone indicated local time. > >That's entirely possible, I've never read it and the text is not >generally available. The wikipedia page gives an example with the "T" >and without the timezone specifiier, though. At this point for most general purposes (like timestamping) it makes more sense to reference RFC 3339 rather than ISO 8601, which is freely available and has fewer options for people to screw up. AFAIK, the presence or absence of a T in an ISO 8601 timestamp has nothing to do with local time zone. The T is required in all cases of combined date and time unless people decide not to use it. My only criticism of RFC 3339 was failing to make the T mandatory. Mike Stone