From rak at debian.org Thu Sep 5 10:25:13 2013 From: rak at debian.org (Ryan Kavanagh) Date: Wed, 4 Sep 2013 20:25:13 -0400 Subject: Using multiple certificates for a given private key Message-ID: <20130905002513.GF6446@nu.ryanak.ca> Hi, I'm experimenting with certificates for users, giving access via the TrustedUserCAKeys mechanism. Unfortunately, there seems to be a limit of one certificate per SSH key on the user's side, which prevents using the same key for hosts using different TrustedUserCAKeys. Is there a clean way around this? To make the above clearer, consider the following situation: A collection of hosts is partitioned into A hosts and B hosts, and we have a CA key for the A hosts and one for the B hosts. Bob is a special user and is granted access to hosts in both the A and the B clusters, and so after sending his id_ecdsa.pub public key to the A and B CA key maintainers, gets back two id_ecdsa-cert.pub certificates, one granting him access to the A cluster, the other to the B cluster. Bob is however stuck in that ssh only looks at the file ~/.ssh/id_ecdsa-cert.pub for a certificate for his id_ecdsa key. If he puts A's certificate at that location, he can't login to B using B's certificate, and vice-versa. If he puts both certificates into ~/.ssh/id_ecdsa-cert.pub, ssh only uses the top one. Is there any resolution for Bob short of making two copies of ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsaA and ~/.ssh/id_ecdsaB, and similarly for ~/.ssh/id_ecdsa.pub, and placing the A and B certificates at ~/.ssh/id_ecdsaA-cert.pub and ~/.ssh/id_ecdsaB-cert.pub respectively, thereby creating two copies of the key, each with its own certificate? Looking at the source code, it looks as though not: key_load_cert (authfile.c) calls key_try_load_public (authfile.c), which parses ${keyfile}-cert.pub until a key is found, loads it, and returns, thus ignoring any subsequent certificates in the file. The cert filename is also hardcoded to be ${keyfile}-cert.pub in key_load_cert. Best wishes, Ryan -- |_)|_/ Ryan Kavanagh | Debian Developer | \| \ http://ryanak.ca/ | GPG Key 4A11C97A From djm at mindrot.org Thu Sep 5 14:21:33 2013 From: djm at mindrot.org (Damien Miller) Date: Thu, 5 Sep 2013 14:21:33 +1000 (EST) Subject: Using multiple certificates for a given private key In-Reply-To: <20130905002513.GF6446@nu.ryanak.ca> References: <20130905002513.GF6446@nu.ryanak.ca> Message-ID: On Wed, 4 Sep 2013, Ryan Kavanagh wrote: > Hi, > > I'm experimenting with certificates for users, giving access via the > TrustedUserCAKeys mechanism. Unfortunately, there seems to be a limit of > one certificate per SSH key on the user's side, which prevents using the > same key for hosts using different TrustedUserCAKeys. Is there a clean > way around this? The easiest way to have multiple certs per private key is to use an agent. You will still need to copy (or symlink) the private key for each cert but you will need to enter the passphrase only once. > A collection of hosts is partitioned into A hosts and B hosts, and we > have a CA key for the A hosts and one for the B hosts. Bob is a special > user and is granted access to hosts in both the A and the B clusters, > and so after sending his id_ecdsa.pub public key to the A and B CA key > maintainers, gets back two id_ecdsa-cert.pub certificates, one granting > him access to the A cluster, the other to the B cluster. I'd try to solve this with principals and/or authorized_principals files. E.g. setting the certificate's principals list to "bob at clusterA,bob at clusterB" (or one of the entries alone) and creating principals files (or a single file) containing "%u at clusterA" or "%u at clusterB" > Is there any resolution for Bob short of making two copies of > ~/.ssh/id_ecdsa, ~/.ssh/id_ecdsaA and ~/.ssh/id_ecdsaB, and similarly > for ~/.ssh/id_ecdsa.pub, and placing the A and B certificates at > ~/.ssh/id_ecdsaA-cert.pub and ~/.ssh/id_ecdsaB-cert.pub respectively, > thereby creating two copies of the key, each with its own certificate? Not at present. > Looking at the source code, it looks as though not: key_load_cert > (authfile.c) calls key_try_load_public (authfile.c), which parses > ${keyfile}-cert.pub until a key is found, loads it, and returns, thus > ignoring any subsequent certificates in the file. The cert filename is > also hardcoded to be ${keyfile}-cert.pub in key_load_cert. Right. I'd accept patches to allow multiple certificates in the -cert.pub file though by making key_load_cert return multiple Keys. -d From des at des.no Sun Sep 8 03:17:48 2013 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Sat, 07 Sep 2013 19:17:48 +0200 Subject: Call for testing: OpenSSH-6.3 In-Reply-To: (Damien Miller's message of "Thu, 25 Jul 2013 13:35:25 +1000 (EST)") References: Message-ID: <86k3isim9v.fsf@nine.des.no> Damien Miller writes: > OpenSSH 6.3 is almost ready for release, [...] Still no release six weeks later - is anything the matter? When can we expect 6.3p1 to ship? DES -- Dag-Erling Sm?rgrav - des at des.no From djm at mindrot.org Mon Sep 9 09:17:45 2013 From: djm at mindrot.org (Damien Miller) Date: Mon, 9 Sep 2013 09:17:45 +1000 (EST) Subject: Call for testing: OpenSSH-6.3 In-Reply-To: <86k3isim9v.fsf@nine.des.no> References: <86k3isim9v.fsf@nine.des.no> Message-ID: On Sat, 7 Sep 2013, Dag-Erling Sm?rgrav wrote: > Damien Miller writes: > > OpenSSH 6.3 is almost ready for release, [...] > > Still no release six weeks later - is anything the matter? When can we > expect 6.3p1 to ship? Just an unlucky confluence of travel, vacation and illness. We'll get the release out soon. -d From mackyle at gmail.com Tue Sep 10 18:29:22 2013 From: mackyle at gmail.com (Kyle J. McKay) Date: Tue, 10 Sep 2013 01:29:22 -0700 Subject: ssh-keygen -t dsa limited to 1024? Message-ID: Looking at ssh-keygen.c from openssh-6.2p2.tar.gz lines 186-187: if (type == KEY_DSA && *bitsp != 1024) fatal("DSA keys must be 1024 bits"); It appears to me that ssh-keygen will only generate 1024 bit DSA keys. Is that still current? FIPS 186-3 (2009-06) section 4.2 and FIPS 186-4 [1] (2013-07) section 4.2 state: 4.2 Selection of Parameter Sizes and Hash Functions for DSA This Standard specifies the following choices for the pair L and N (the bit lengths of p and q, respectively): L = 1024, N = 160 L = 2048, N = 224 L = 2048, N = 256 L = 3072, N = 256 Federal Government entities shall generate digital signatures using use one or more of these choices. I see there is bug 1647 [2] about this. However, RFC 6668 [3] (2012-07) added SHA-256 to the recommended list of data integrity functions for SSH making the L=2048,N=256 and L=3072,N=256 DSA choices from FIPS 186-3/186-4 standards compliant. It also appears that OpenSSH added support for both SHA-256 and SHA-512 in version 5.9p1 (2011-09). I have updated bug 1647 with the additional information. Are there any plans to add support for generating DSA 2048, 3072 keys? [1] http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf [2] https://bugzilla.mindrot.org/show_bug.cgi?id=1647 [3] http://tools.ietf.org/html/rfc6668 --Kyle P.S. What, by the way, does OpenSSH do if you have an existing DSA 2048 or 3072 key? (OpenSSL will generate them just fine.) From mdb at juniper.net Tue Sep 10 19:00:40 2013 From: mdb at juniper.net (Mark D. Baushke) Date: Tue, 10 Sep 2013 02:00:40 -0700 Subject: [Bug 1647] Implement FIPS 186-3 for DSA keys In-Reply-To: References: Message-ID: <81683.1378803640@eng-mail01.juniper.net> writes: > https://bugzilla.mindrot.org/show_bug.cgi?id=1647 > > mackyle at gmail.com changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |mackyle at gmail.com > > --- Comment #2 from mackyle at gmail.com --- > RFC 6668 [1] (2012-07) updated RFC 4253 adding the SHA-256 data > integrity algorithm as a new recommended algorithm. > > FIPS 186-4 [2] (2013-07) section 4.2 includes the same DSA parameters > as FIPS 186-3: > > L = 1024, N = 160 > L = 2048, N = 224 > L = 2048, N = 256 > L = 3072, N = 256 > > And it would seem that the L=2048,N=256 L=3072,N=256 selections are now > possible while remaining standards compliant. SHA-1 is not allowed in digital signatures per NIST SP 800-131A after December 31, 2013. The problem is in the way that ssh-dss is specified in RFC 4253 to use a SHA-1 hash in the dss_signature_blob. The same problems exist for x509v3-ssh-dss which also specifies the use of SHA-1. In order to use a DSA-2048 or DSA-3072 with SHA-256 or SHA-512, one would likely need to move to the pgp-sign-dss public key algorithm of RFC2440 as obsoleted by RFC 4880 section 13.6 which allows for L=1024, N=160 [not useful given NIST SP 800-131A] L=2048, N=224 with SHA-224, SHA-256, SHA-384, or SHA-512 hash L=2048, N=256 with SHA-256, SHA-384, or SHA-512 hash L=3072, N=256 with SHA-256, SHA-384, or SHA-512 hash I am not aware of any pgp-sign-dss implementations that implement the RFC 4880 updated types, but you could use it if you wished. Other alternatives would mean writing another RFC to deal with a new public key algorithm name or set of names to handle the key sizes and hash algorithms you want to allow. > > It appears that OpenSSH has added support for SHA-256 and SHA-512 in > version 5.9p1 (2011-09). RFC 6668 is good if you want to use something like the Cipher aes128-cbc with hmac-sha2-256 or hmac-sha2-512 as the MAC instead of implementing AEAD_AES_128_GCM or AEAD_AES_256_GCM. The way that RFC 5647 is written makes it hard to do the right thing when the Cipher and Macs are negotiated separately as both have to agree and having one of the AEAD_* ciphers with some other MAC just makes no sense, but has no provision for forcing the two to be sane during negotiations. The OpenSSH community implemented aes128-gcm at openssh.com and aes256-gcm at openssh.com with specified semantics during negotiation to ensure that a non-toxic selection is made and otherwise uses the RFC 5647 wire protocol for the traffic. > > [1] http://tools.ietf.org/html/rfc6668 > [2] http://nvlpubs.nist.gov/nistpubs/FIPS/NIST.FIPS.186-4.pdf > > -- > You are receiving this mail because: > You are watching the assignee of the bug. > You are watching someone on the CC list of the bug. > _______________________________________________ > openssh-bugs mailing list > openssh-bugs at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-bugs From djm at mindrot.org Wed Sep 11 13:18:27 2013 From: djm at mindrot.org (Damien Miller) Date: Wed, 11 Sep 2013 13:18:27 +1000 (EST) Subject: [Bug 1647] Implement FIPS 186-3 for DSA keys In-Reply-To: <81683.1378803640@eng-mail01.juniper.net> References: <81683.1378803640@eng-mail01.juniper.net> Message-ID: On Tue, 10 Sep 2013, Mark D. Baushke wrote: > Other alternatives would mean writing another RFC to deal with a new > public key algorithm name or set of names to handle the key sizes and > hash algorithms you want to allow. Or just abandoning DSA for ECDSA. It has the advantages of already being implemented, being faster and offering a better security level (assuming NIST/NSA haven't some exquisite backdoor in the curves). -d From djm at mindrot.org Wed Sep 11 13:22:49 2013 From: djm at mindrot.org (Damien Miller) Date: Wed, 11 Sep 2013 13:22:49 +1000 (EST) Subject: ssh-keygen -t dsa limited to 1024? In-Reply-To: References: Message-ID: On Tue, 10 Sep 2013, Kyle J. McKay wrote: > Are there any plans to add support for generating DSA 2048, 3072 keys? No. It requires a protocol extension (e.g. a "ssh-dss-v2" key method) and we aren't going to cook one up. If you want to remain compliant then I suggest you use one of the ECDSA keytypes. -d From member at linkedin.com Thu Sep 12 14:29:23 2013 From: member at linkedin.com (=?UTF-8?Q?amin_tabrizi_a_trav=C3=A9s_de_LinkedIn?=) Date: Thu, 12 Sep 2013 04:29:23 +0000 (UTC) Subject: Guillermo, conectemos en LinkedIn Message-ID: <314016724.55295506.1378960163975.JavaMail.app@ela4-bed79.prod> LinkedIn ------------ amin tabrizi ha solicitado a?adirte como contacto en LinkedIn: ------------------------------------------ Me gustar?a a?adirte a mi red profesional en LinkedIn. Aceptar invitaci?n de amin tabrizi http://www.linkedin.com/e/17jf7e-hlhha05m-3c/T3eUPsTGk1Fx4GfYY51nUKXAQCzcqTi9U612ZbP-zwu/blk/I464215455_125/e39SrCAJoS5vrCAJoyRJtCVFnSRJrScJr6RBfnhv9ClRsDgZp6lQs6lzoQ5AomZIpn8_dj8NnPkRd3kNczgSd4ALr7BTqQ5amnsLcPAQej8MdjAQdz4LrCBxbOYWrSlI/eml-comm_invm-b-in_ac-inv28/?hs=false&tok=1bdfKb-BAdI5U1 Ver el perfil de amin tabrizi http://www.linkedin.com/e/17jf7e-hlhha05m-3c/rso/287165277/jUg1/name/128341832_I464215455_125/?hs=false&tok=3NjhefShwdI5U1 ------------------------------------------ Est?s recibiendo invitaciones por correo electr?nico. Este mensaje de correo electr?nico estaba dirigido a Guillermo Bernaldo de Quir?s Maraver. Averigua la raz?n por la que incluimos esto: http://www.linkedin.com/e/17jf7e-hlhha05m-3c/plh/http%3A%2F%2Fhelp%2Elinkedin%2Ecom%2Fapp%2Fanswers%2Fdetail%2Fa_id%2F4788/-GXI/?hs=false&tok=12vUJs1hEdI5U1 (c) 2012, LinkedIn Corporation. 2029 Stierlin Ct, Mountain View, CA 94043, EE.UU. From nitheshsalian2006 at gmail.com Fri Sep 13 15:26:36 2013 From: nitheshsalian2006 at gmail.com (nithesh salian) Date: Fri, 13 Sep 2013 10:56:36 +0530 Subject: Question on configuring openssh with darwin ssl Message-ID: Hi, I am using openssh for SFTP in my application. Can I configure openssh with darwin ssl? Presently it uses libcrypto? Thanks in advance. -- Regards, Nithesh Gangadhar Salian . From djm at cvs.openbsd.org Fri Sep 13 17:43:25 2013 From: djm at cvs.openbsd.org (Damien Miller) Date: Fri, 13 Sep 2013 01:43:25 -0600 (MDT) Subject: Announce: OpenSSH 6.3 released Message-ID: <201309130743.r8D7hPWh012304@cvs.openbsd.org> Changes since OpenSSH 6.2 ========================= This release is predominantly a bugfix release: Features: * sshd(8): add ssh-agent(1) support to sshd(8); allows encrypted hostkeys, or hostkeys on smartcards. * ssh(1)/sshd(8): allow optional time-based rekeying via a second argument to the existing RekeyLimit option. RekeyLimit is now supported in sshd_config as well as on the client. * sshd(8): standardise logging of information during user authentication. The presented key/cert and the remote username (if available) is now logged in the authentication success/failure message on the same log line as the local username, remote host/port and protocol in use. Certificates contents and the key fingerprint of the signing CA are logged too. Including all relevant information on a single line simplifies log analysis as it is no longer necessary to relate information scattered across multiple log entries. * ssh(1): add the ability to query which ciphers, MAC algorithms, key types and key exchange methods are supported in the binary. * ssh(1): support ProxyCommand=- to allow support cases where stdin and stdout already point to the proxy. * ssh(1): allow IdentityFile=none * ssh(1)/sshd(8): add -E option to ssh and sshd to append debugging logs to a specified file instead of stderr or syslog. * sftp(1): add support for resuming partial downloads using the "reget" command and on the sftp commandline or on the "get" commandline using the "-a" (append) option. * ssh(1): add an "IgnoreUnknown" configuration option to selectively suppress errors arising from unknown configuration directives. * sshd(8): add support for submethods to be appended to required authentication methods listed via AuthenticationMethods. Bugfixes: * sshd(8): fix refusal to accept certificate if a key of a different type to the CA key appeared in authorized_keys before the CA key. * ssh(1)/ssh-agent(1)/sshd(8): Use a monotonic time source for timers so that things like keepalives and rekeying will work properly over clock steps. * sftp(1): update progressmeter when data is acknowledged, not when it's sent. bz#2108 * ssh(1)/ssh-keygen(1): improve error messages when the current user does not exist in /etc/passwd; bz#2125 * ssh(1): reset the order in which public keys are tried after partial authentication success. * ssh-agent(1): clean up socket files after SIGINT when in debug mode; bz#2120 * ssh(1) and others: avoid confusing error messages in the case of broken system resolver configurations; bz#2122 * ssh(1): set TCP nodelay for connections started with -N; bz#2124 * ssh(1): correct manual for permission requirements on ~/.ssh/config; bz#2078 * ssh(1): fix ControlPersist timeout not triggering in cases where TCP connections have hung. bz#1917 * ssh(1): properly deatch a ControlPersist master from its controlling terminal. * sftp(1): avoid crashes in libedit when it has been compiled with multi- byte character support. bz#1990 * sshd(8): when running sshd -D, close stderr unless we have explicitly requested logging to stderr. bz#1976, * ssh(1): fix incomplete bzero; bz#2100 * sshd(8): log and error and exit if ChrootDirectory is specified and running without root privileges. * Many improvements to the regression test suite. In particular log files are now saved from ssh and sshd after failures. * Fix a number of memory leaks. bz#1967 bz#2096 and others * sshd(8): fix public key authentication when a :style is appended to the requested username. * ssh(1): do not fatally exit when attempting to cleanup multiplexing- created channels that are incompletely opened. bz#2079 Portable OpenSSH: * Major overhaul of contrib/cygwin/README * Fix unaligned accesses in umac.c for strict-alignment architectures. bz#2101 * Enable -Wsizeof-pointer-memaccess if the compiler supports it. bz#2100 * Fix broken incorrect commandline reporting errors. bz#1448 * Only include SHA256 and ECC-based key exchange methods if libcrypto has the required support. * Fix crash in SOCKS5 dynamic forwarding code on strict-alignment architectures. * A number of portability fixes for Android: * Don't try to use lastlog on Android; bz#2111 * Fall back to using openssl's DES_crypt function on platorms that don't have a native crypt() function; bz#2112 * Test for fd_mask, howmany and NFDBITS rather than trying to enumerate the plaforms that don't have them. bz#2085 * Replace S_IWRITE, which isn't standardized, with S_IWUSR, which is. bz#2085 * Add a null implementation of endgrent for platforms that don't have it (eg Android) bz#2087 * Support platforms, such as Android, that lack struct passwd.pw_gecos. bz#2086 Checksums: ========== - SHA1 (openssh-6.3.tar.gz) = 8a6ef99ffc80c19e9afe9fe1e857370f6adcf450 - SHA1 (openssh-6.3p1.tar.gz) = 70845ca79474258cab29dbefae13d93e41a83ccb Reporting Bugs: =============== - Please read http://www.openssh.com/report.html Security bugs should be reported directly to openssh at openssh.com OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and Ben Lindstrom. From djm at mindrot.org Fri Sep 13 17:45:27 2013 From: djm at mindrot.org (Damien Miller) Date: Fri, 13 Sep 2013 17:45:27 +1000 (EST) Subject: Question on configuring openssh with darwin ssl In-Reply-To: References: Message-ID: On Fri, 13 Sep 2013, nithesh salian wrote: > Hi, > > I am using openssh for SFTP in my application. Can I configure openssh > with darwin ssl? Presently it uses libcrypto? OpenSSH only supports libcrypto. -d From martin.jacobs at arcor.de Sat Sep 14 05:29:39 2013 From: martin.jacobs at arcor.de (Martin Jacobs) Date: Fri, 13 Sep 2013 21:29:39 +0200 (MEST) Subject: openssh (6.2p2), inherit host environment variables to subsystem sftp-server process Message-ID: Hi, is there a regular way that a subsystem process (sftpserver here) inherits environment variables from its parent (sshd)? Namely LANG and LC_* variables. In my case it's important to get the variable of hosting environment and not from client side (AcceptEnv). Regards Martin -- Registered Linux User #87175, http://linuxcounter.net From djm at mindrot.org Sat Sep 14 16:47:33 2013 From: djm at mindrot.org (Damien Miller) Date: Sat, 14 Sep 2013 16:47:33 +1000 (EST) Subject: openssh (6.2p2), inherit host environment variables to subsystem sftp-server process In-Reply-To: References: Message-ID: On Fri, 13 Sep 2013, Martin Jacobs wrote: > Hi, > > is there a regular way that a subsystem process (sftpserver > here) inherits environment variables from its parent (sshd)? > Namely LANG and LC_* variables. > > In my case it's important to get the variable of hosting > environment and not from client side (AcceptEnv). Subsystems like sftp are executed via the the user's shell, so you can place environment variables in a non-interactive shell initialisation file and they will be passed through. Otherwise, you could add them to the ones that are copied from sshd to its child session processes in session.c:do_setup_env() It might be worth reviewing these... -d From martin.jacobs at arcor.de Sun Sep 15 21:41:08 2013 From: martin.jacobs at arcor.de (Martin Jacobs) Date: Sun, 15 Sep 2013 13:41:08 +0200 (MEST) Subject: openssh (6.2p2), inherit host environment variables to subsystem sftp-server process In-Reply-To: References: Message-ID: On Sat, 14 Sep 2013, Damien Miller wrote: > On Fri, 13 Sep 2013, Martin Jacobs wrote: > > > Hi, > > > > is there a regular way that a subsystem process (sftpserver > > here) inherits environment variables from its parent (sshd)? > > Namely LANG and LC_* variables. > > > > In my case it's important to get the variable of hosting > > environment and not from client side (AcceptEnv). > > Subsystems like sftp are executed via the the user's shell, so you can > place environment variables in a non-interactive shell initialisation > file and they will be passed through. Thanks for this hint. Yes, it works. I added sshd_config:PermitUserEnvironment=yes added file /etc/global/bashrc:export LANG=de_DE at euro added something like ~/.ssh/environment:BASH_ENV=/etc/global/bashrc for each (!) user. With this subservice process gesftpserver gets environment variable LANG as intended. Disadvantage of this approach: * needs PermitUserEnvironment=yes * needs per user configuration (~/.ssh/environment) * possible influence on ssh login session (LANG is set/overriden) > > Otherwise, you could add them to the ones that are copied from sshd to > its child session processes in session.c:do_setup_env() It might be > worth reviewing these... Environment variable LANG is not part of those variables provided there and it is not configurable, therefore would need a code change. Changing do_setup_env() would be a permanent change and affecting interactive sessions as well. My suggestion: New configuration option for sshd_config: InheritEnv and extend Match criteria with key Subsystem . And take InheritEnv into list of options supported in Match section. Current environment variables inherited in do_setup_env() could be taken as default values of InheritEnv. Why this: playing with green sftpserver plugin for openssh (gesftpserver) and sftp protocol versions 4 and higher, its necessary that gesftpserver process gets knowledge about filename encoding of hosting system (variable LANG). This is completely independent of user settings and independent from interactive session configuration. > > -d > Martin From jstjohn at purdue.edu Wed Sep 18 01:38:05 2013 From: jstjohn at purdue.edu (Jason St. John) Date: Tue, 17 Sep 2013 11:38:05 -0400 Subject: [PATCH] [Portable] Prune extraneous whitespace in sshd_config Message-ID: The sshd_config file shipped with OpenSSH Portable 6.3p1 (and several earlier versions as well) contains an extra space at the end of lines 87 and 88. The attached patch corrects this. Jason From dtucker at zip.com.au Wed Sep 18 15:11:07 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 18 Sep 2013 15:11:07 +1000 Subject: [PATCH] [Portable] Prune extraneous whitespace in sshd_config In-Reply-To: References: Message-ID: <20130918051107.GA323@gate.dtucker.net> On Tue, Sep 17, 2013 at 11:38:05AM -0400, Jason St. John wrote: > The sshd_config file shipped with OpenSSH Portable 6.3p1 (and several > earlier versions as well) contains an extra space at the end of lines > 87 and 88. The attached patch corrects this. The patch didn't make it (the mailing list strips anything that's not text/plain) but I made the change based on the description. Thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From jstjohn at purdue.edu Thu Sep 19 09:00:59 2013 From: jstjohn at purdue.edu (Jason St. John) Date: Wed, 18 Sep 2013 19:00:59 -0400 Subject: [PATCH] [Portable] Prune extraneous whitespace in sshd_config In-Reply-To: <20130918051107.GA323@gate.dtucker.net> References: <20130918051107.GA323@gate.dtucker.net> Message-ID: On Wed, Sep 18, 2013 at 1:11 AM, Darren Tucker wrote: > On Tue, Sep 17, 2013 at 11:38:05AM -0400, Jason St. John wrote: >> The sshd_config file shipped with OpenSSH Portable 6.3p1 (and several >> earlier versions as well) contains an extra space at the end of lines >> 87 and 88. The attached patch corrects this. > > The patch didn't make it (the mailing list strips anything that's not > text/plain) but I made the change based on the description. Thanks. > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. Gmail must have mangled the attachment. Sorry about that. Thanks! Jason From moben at exherbo.org Thu Sep 19 20:23:52 2013 From: moben at exherbo.org (Benedikt Morbach) Date: Thu, 19 Sep 2013 12:23:52 +0200 Subject: [PATCH] also look for host-prefixed ar Message-ID: <1379586232.20623.7.camel@thinkex.drpepper> This patch changes configure.ac to look for '${host}-ar' as set by AC_CANONICAL_HOST before looking for the unprefixed 'ar'. This is useful when cross-compiling when all your binutils are prefixed. I used AC_CHECK_TOOLS instead of AC_CHECK_TOOL, since autoconf docs say that the former calls AC_SUBST. Applies to OpenSSH portable 6.3p1 --- configure.ac | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 4a1b503..460addd 100644 --- a/configure.ac +++ b/configure.ac @@ -30,7 +30,7 @@ AC_PROG_CPP AC_PROG_RANLIB AC_PROG_INSTALL AC_PROG_EGREP -AC_PATH_PROG([AR], [ar]) +AC_CHECK_TOOLS([AR], [ar]) AC_PATH_PROG([CAT], [cat]) AC_PATH_PROG([KILL], [kill]) AC_PATH_PROGS([PERL], [perl5 perl]) -- 1.8.4 From jw at raven.inka.de Fri Sep 20 22:51:53 2013 From: jw at raven.inka.de (Josef Wolf) Date: Fri, 20 Sep 2013 14:51:53 +0200 Subject: Key preference Message-ID: <20130920125153.GB455@raven.inka.de> Hello everybody, I have a problem specifying identities with the -i option. For easier ssh invocations, I have setup my ssh_config files with entries like the following: Host *.domain.name Port 23457 StrictHostKeyChecking yes UserKnownHostsFile /dev/null GlobalKnownHostsFile /etc/ssh/known-hosts/domain.name IdentityFile ~/.ssh/%h-dsa IdentityFile ~/.ssh/%h-rsa IdentityFile ~/.ssh/domain.name-dsa IdentityFile ~/.ssh/domain.name-rsa In addition, I've set up a system similar to gitolite, which uses a dedicated account with authorized_keys set up like this: command="/gitrepos/.server ab",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-dss pubkey-ab command="/gitrepos/.server cd",no-port-forwarding,no-X11-forwarding,no-agent-forwarding,no-pty ssh-dss pubkey-cd This way, the connecting user is identified by its public key. This setup works fine so far. But when I try connecting with a _specific_ key using the -i option (to represent a specific role in the git repository), I get this strange result: $ ssh -vvv -i /home/jw/.ssh/specific-key gitrepos at git.domain.name debug1: identity file /home/jw/.ssh/specific-key type 1 [ ... ] debug2: key: /home/jw/.ssh/some-key.domain.name (0xb8db08b0) debug2: key: /home/jw/.ssh/specific-key (0xb8daaea0) [ ... ] debug1: Offering DSA public key: /home/jw/.ssh/some-key.domain.name This seems strange to me. I have requested a _specific_ key with the -i option. Why is a different key tried _before_ this specific key is even considered? IMHO, if a specific key is specified on the command line, this specific key (and _no_ other key) should be used. Another annoyance is that a private key will not be loaded when the corresponding public key is not available. PS: Is the list on secureshell at securityfocus.com dead? If so, then http://www.openssh.org/de/list.html should be updated accordingly. -- Josef Wolf jw at raven.inka.de From dtucker at zip.com.au Fri Sep 20 23:47:06 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 20 Sep 2013 23:47:06 +1000 Subject: Key preference In-Reply-To: <20130920125153.GB455@raven.inka.de> References: <20130920125153.GB455@raven.inka.de> Message-ID: <20130920134706.GA6403@gate.dtucker.net> On Fri, Sep 20, 2013 at 02:51:53PM +0200, Josef Wolf wrote: > I have a problem specifying identities with the -i option. [...] > This seems strange to me. I have requested a _specific_ key with the -i > option. Why is a different key tried _before_ this specific key is even > considered? If your ssh-agent has keys those will be offered to the server first. You can change that with the IdentitiesOnly option. > Another annoyance is that a private key will not be loaded when the > corresponding public key is not available. That's because if the private key is encrypted it'd need to prompt you for the passphrase every time you made a connection whether the key can be used or not. The way pubkey auth works is the client says "if I proved I had the private key corresponding to this public key fingerprint would that work?" and the server replies with yes or no. In your case, what's probably happening is that you have keys in your agent which the server will also accept. > PS: Is the list on secureshell at securityfocus.com dead? If so, then > http://www.openssh.org/de/list.html should be updated accordingly. >From the archive it looks like it died some time in 2011. I'll remove 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 deleriux1 at gmail.com Sun Sep 22 07:13:09 2013 From: deleriux1 at gmail.com (Matthew Ife) Date: Sat, 21 Sep 2013 22:13:09 +0100 Subject: [PATCH] Fix oom_adj on Linux after sshd reload Message-ID: Currently, on linux sshd attempts to remove itself from the influence of oom-killer by modifying the oom_adj parameter for itself in proc to -17. This is controlled via two functions; oom_adjust_setup() and oom_adjust_restore(). Setup saves the old score (typically zero on initialization) and sets sshd to -17 whilst oom_adjust_restore places the saved value from initialization back into the running sshd process. The principle here being that whilst we want the main sshd listener process never to be oom-killed, we want any subsequent children that sshd spawns to be oom-killed if necessary. The problem that occurs however is on a SIGHUP, sshd re-execs itself and inherits the oom_adj score from its protege. When sshd goes through its initialization steps it calls oom_adjust_setup() and saves the now -17 value. On oom_adjust_restore() sshd then restores -17 to all child processes sshd spawns. This has the effect of after performing a reload causing all sshd processes (and by the nature of inheritance) all descendant pids having -17 as their oom_adj value which causes all sshd sessions after the reload to never be candidates for oom-killer. Clearly this is not desirable as it can lead to unrecoverable out of memory conditions on linux. This is very simple to test on linux. Restart sshd on a linux host. Login to it via ssh and then run cat /proc/self/oom_adj. How reload ssh, relogin again via ssh and recheck cat /proc/self/oom_adj. I have created a patch, which I believe is honourable to the design philosophy being utilized by openssh. This patch adds an additional function to platform.h called platform_pre_restart() that (if defined) will perform oom_adjust_restore(). This is then called inside of sighup_restart() prior to performing the re-exec of ssh. From deleriux1 at gmail.com Sun Sep 22 07:50:59 2013 From: deleriux1 at gmail.com (Matthew Ife) Date: Sat, 21 Sep 2013 22:50:59 +0100 Subject: [PATCH] Fix oom_adj on Linux after sshd reload In-Reply-To: <20130921214353.9205.qmail@stuge.se> References: <20130921214353.9205.qmail@stuge.se> Message-ID: Attempting to re-attach patch. Definitely was attached the last time (mailing list made me confirm so maybe thats something to do with it..) On Sat, Sep 21, 2013 at 10:43 PM, Peter Stuge wrote: > Matthew Ife wrote: > > I have created a patch, which I believe is honourable to the design > > philosophy being utilized by openssh. > > Sounds good, but you didn't attach it to the email, or it was > stripped by the mailing list software. > > Make sure attachments have a text/ MIME type, and/or file a bug in > bugzilla and attach the patch there. > > Many thanks! > > > //Peter > From jw at raven.inka.de Sun Sep 22 20:01:33 2013 From: jw at raven.inka.de (Josef Wolf) Date: Sun, 22 Sep 2013 12:01:33 +0200 Subject: Key preference In-Reply-To: <20130920134706.GA6403@gate.dtucker.net> References: <20130920125153.GB455@raven.inka.de> <20130920134706.GA6403@gate.dtucker.net> Message-ID: <20130922100133.GA16641@raven.inka.de> On Fr, Sep 20, 2013 at 11:47:06 +1000, Darren Tucker wrote: > On Fri, Sep 20, 2013 at 02:51:53PM +0200, Josef Wolf wrote: > > I have a problem specifying identities with the -i option. > [...] > > This seems strange to me. I have requested a _specific_ key with the -i > > option. Why is a different key tried _before_ this specific key is even > > considered? > > If your ssh-agent has keys those will be offered to the server first. IMHO, it seems to be _very_ counter-intuitive to prefer something loaded in the background when a specific key was requested _explicitly_ on the command line. > You can change that with the IdentitiesOnly option. Ummm, the documentation of this option don't mention command line options at all. It talks only about identities configured in ssh_config. > > Another annoyance is that a private key will not be loaded when the > > corresponding public key is not available. > > That's because if the private key is encrypted it'd need to prompt you > for the passphrase every time you made a connection whether the key can > be used or not. > > The way pubkey auth works is the client says "if I proved I had the > private key corresponding to this public key fingerprint would that > work?" and the server replies with yes or no. I see. > In your case, what's > probably happening is that you have keys in your agent which the server > will also accept. Yes, of course! First, I have my standard key loaded, which I use for my everyday work on this server. In addition, I have multiple keys for this git repository, since I have multiple roles in its workflow. So, when I need to do something with a specific role, I'd specify the corresponding key with the -i option to override the keys offered by ssh-agent. And I'm _very_ surprised that my keys from ssh-agent are used instead of the _explicitly_ _specified_ key. IMHO, in security software, surprising behavior is evil. -- Josef Wolf jw at raven.inka.de From fdur559 at gmail.com Mon Sep 23 03:10:22 2013 From: fdur559 at gmail.com (Francois Durand) Date: Sun, 22 Sep 2013 19:10:22 +0200 Subject: ad-hoc ssh agent + control persist Message-ID: Hi all, I'm using ssh to deploy software remotely. I download stuff on the remote box from git repositories over ssh using ssh deployment keys. For this to work, I start locally an ad-hoc ssh agent loaded with only the deployment keys, and forward it to the remote host. I can use something like ssh-agent my_sub_deployment_script so that ad-hoc ssh agent only exists when needed. This alone works very well. One deployment needs several ssh connections. For obvious performance reasons using control persistance (ControlPersist=60 for instance) is highly desirable. Here is the problem: if ssh-agent stops when last connection stops, the master connection will be kept alive for 60s while the agent it is forwarding no longer runs. If I keep the ssh agent running, nothing will do the cleanup when the master connection stops and I'll end up with many unused agents running. I don't see anything simple to stop the agent when the master connection using it stops. Any ideas on this ? From dtucker at zip.com.au Mon Sep 23 13:02:20 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 23 Sep 2013 13:02:20 +1000 Subject: [PATCH] Fix oom_adj on Linux after sshd reload In-Reply-To: References: <20130921214353.9205.qmail@stuge.se> Message-ID: <20130923030220.GA14399@gate.dtucker.net> On Sat, Sep 21, 2013 at 10:50:59PM +0100, Matthew Ife wrote: > Attempting to re-attach patch. Definitely was attached the last time > (mailing list made me confirm so maybe thats something to do with it..) Confirmation is required for posts from addresses that are not list members (to cut down on spam). For the record, if you attached a patch to this email then it also didn't make it. Attachments that aren't text/plain are stripped by the list (to make it less likely it'll distribute malicious content). Anyway I've applied the patch in in https://bugzilla.mindrot.org/show_bug.cgi?id=2156 and it'll be in the next release. Thanks. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Mon Sep 23 19:04:40 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 23 Sep 2013 19:04:40 +1000 Subject: ad-hoc ssh agent + control persist In-Reply-To: References: Message-ID: <20130923090440.GA9588@gate.dtucker.net> On Sun, Sep 22, 2013 at 07:10:22PM +0200, Francois Durand wrote: [...] > One deployment needs several ssh connections. For obvious performance > reasons using control persistance (ControlPersist=60 for instance) is > highly desirable. [...] > Any ideas on this ? use "ssh -Oexit" and "ssh-agent -k" to explicitly stop the connection and agent as the last steps of your script? -- 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 jw at raven.inka.de Mon Sep 23 20:57:32 2013 From: jw at raven.inka.de (Josef Wolf) Date: Mon, 23 Sep 2013 12:57:32 +0200 Subject: Key preference In-Reply-To: <20130920134706.GA6403@gate.dtucker.net> References: <20130920125153.GB455@raven.inka.de> <20130920134706.GA6403@gate.dtucker.net> Message-ID: <20130923105732.GB16641@raven.inka.de> On Fr, Sep 20, 2013 at 11:47:06 +1000, Darren Tucker wrote: > If your ssh-agent has keys those will be offered to the server first. > You can change that with the IdentitiesOnly option. So I tried to disable the other keys by unsetting the environment variables. And here, I run into a different problem. Please note that in both connection attempts shown below, the same key is to be used. The only difference is that SSH_AUTH_SOCK is unset in the first attempt. I tried this in order to force usage of the identity on the command line. Any ideas what's going on here? raven:/var/cfsvn/conf # (unset SSH_AGENT; unset SSH_AUTH_SOCK; ssh -vvvv -i ~jw/.ssh/jw-jw.lan jw at raven.jw.lan) OpenSSH_6.1p1, OpenSSL 1.0.1e 11 Feb 2013 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 1: Applying options for * debug1: /etc/ssh/ssh_config line 261: Applying options for *.jw.lan debug2: ssh_connect: needpriv 0 debug1: permanently_set_uid: 0/0 debug3: Incorrect RSA1 identifier debug3: Could not load "/home/jw/.ssh/jw-jw.lan" as a RSA1 public key debug1: identity file /home/jw/.ssh/jw-jw.lan type 2 debug1: identity file /home/jw/.ssh/jw-jw.lan-cert type -1 debug1: identity file /root/.ssh/raven.jw.lan-dsa type -1 debug1: identity file /root/.ssh/raven.jw.lan-dsa-cert type -1 debug1: identity file /root/.ssh/raven.jw.lan-rsa type -1 debug1: identity file /root/.ssh/raven.jw.lan-rsa-cert type -1 debug1: identity file /root/.ssh/jw.lan-dsa type -1 debug1: identity file /root/.ssh/jw.lan-dsa-cert type -1 debug1: identity file /root/.ssh/jw.lan-rsa type -1 debug1: identity file /root/.ssh/jw.lan-rsa-cert type -1 debug1: identity file /root/.ssh/gem-dsa type -1 debug1: identity file /root/.ssh/gem-dsa-cert type -1 debug1: identity file /root/.ssh/gem-rsa type -1 debug1: identity file /root/.ssh/gem-rsa-cert type -1 debug1: permanently_drop_suid: 0 Permission denied (publickey). ssh_exchange_identification: Connection closed by remote host raven:/var/cfsvn/conf # (unset SSH_AGENT; ssh -vvvv -i ~jw/.ssh/jw-jw.lan jw at raven.jw.lan) OpenSSH_6.1p1, OpenSSL 1.0.1e 11 Feb 2013 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 1: Applying options for * debug1: /etc/ssh/ssh_config line 261: Applying options for *.jw.lan debug2: ssh_connect: needpriv 0 debug1: permanently_set_uid: 0/0 debug3: Incorrect RSA1 identifier debug3: Could not load "/home/jw/.ssh/jw-jw.lan" as a RSA1 public key debug1: permanently_drop_suid: 0 debug1: identity file /home/jw/.ssh/jw-jw.lan type 2 debug1: identity file /home/jw/.ssh/jw-jw.lan-cert type -1 debug1: identity file /root/.ssh/raven.jw.lan-dsa type -1 debug1: identity file /root/.ssh/raven.jw.lan-dsa-cert type -1 debug1: identity file /root/.ssh/raven.jw.lan-rsa type -1 debug1: identity file /root/.ssh/raven.jw.lan-rsa-cert type -1 debug1: identity file /root/.ssh/jw.lan-dsa type -1 debug1: identity file /root/.ssh/jw.lan-dsa-cert type -1 debug1: identity file /root/.ssh/jw.lan-rsa type -1 debug1: identity file /root/.ssh/jw.lan-rsa-cert type -1 debug1: identity file /root/.ssh/gem-dsa type -1 debug1: identity file /root/.ssh/gem-dsa-cert type -1 debug1: identity file /root/.ssh/gem-rsa type -1 debug1: identity file /root/.ssh/gem-rsa-cert type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.2 [Connection proceeds normally] -- Josef Wolf jw at raven.inka.de From fdur559 at gmail.com Tue Sep 24 00:26:18 2013 From: fdur559 at gmail.com (Francois Durand) Date: Mon, 23 Sep 2013 16:26:18 +0200 Subject: ad-hoc ssh agent + control persist In-Reply-To: <20130923090440.GA9588@gate.dtucker.net> References: <20130923090440.GA9588@gate.dtucker.net> Message-ID: On Mon, Sep 23, 2013 at 11:04 AM, Darren Tucker wrote: > On Sun, Sep 22, 2013 at 07:10:22PM +0200, Francois Durand wrote: > [...] > > One deployment needs several ssh connections. For obvious performance > > reasons using control persistance (ControlPersist=60 for instance) is > > highly desirable. > [...] > > Any ideas on this ? > > use "ssh -Oexit" and "ssh-agent -k" to explicitly stop the connection > and agent as the last steps of your script? > If I understand correctly, this completely nullify the control persistance benefit, and not using control persistance in the first place would achieve the same result, wouldn't it ? From des at des.no Tue Sep 24 04:56:25 2013 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Mon, 23 Sep 2013 20:56:25 +0200 Subject: GSSAPI headers Message-ID: <8661trjrja.fsf@nine.des.no> FreeBSD has both and , but the former is a wrapper that prints a warning before including the latter. This is a problem when building with -Werror. This patch reverses the order of preference so wins over . Index: ssh-gss.h =================================================================== --- ssh-gss.h (revision 255802) +++ ssh-gss.h (working copy) @@ -28,10 +28,10 @@ #ifdef GSSAPI -#ifdef HAVE_GSSAPI_H +#if defined(HAVE_GSSAPI_GSSAPI_H) +#include +#elif defined(HAVE_GSSAPI_H) #include -#elif defined(HAVE_GSSAPI_GSSAPI_H) -#include #endif #ifdef KRB5 Index: sshd.c =================================================================== --- sshd.c (revision 255802) +++ sshd.c (working copy) @@ -88,10 +88,10 @@ #ifdef __FreeBSD__ #include -#if defined(GSSAPI) && defined(HAVE_GSSAPI_H) +#if defined(GSSAPI) && defined(HAVE_GSSAPI_GSSAPI_H) +#include +#elif defined(GSSAPI) && defined(HAVE_GSSAPI_H) #include -#elif defined(GSSAPI) && defined(HAVE_GSSAPI_GSSAPI_H) -#include #endif #endif DES -- Dag-Erling Sm?rgrav - des at des.no From keisial at gmail.com Tue Sep 24 08:04:04 2013 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Tue, 24 Sep 2013 00:04:04 +0200 Subject: ad-hoc ssh agent + control persist In-Reply-To: References: <20130923090440.GA9588@gate.dtucker.net> Message-ID: <5240BAD4.2000507@gmail.com> On 23/09/13 16:26, Francois Durand wrote: > On Mon, Sep 23, 2013 at 11:04 AM, Darren Tucker wrote: > >> On Sun, Sep 22, 2013 at 07:10:22PM +0200, Francois Durand wrote: >> [...] >>> One deployment needs several ssh connections. For obvious performance >>> reasons using control persistance (ControlPersist=60 for instance) is >>> highly desirable. >> [...] >>> Any ideas on this ? >> use "ssh -Oexit" and "ssh-agent -k" to explicitly stop the connection >> and agent as the last steps of your script? >> > > If I understand correctly, this completely nullify the control persistance > benefit, and not using control persistance in the first place would achieve > the same result, wouldn't it ? No. This way you have control persistance until you run that, where as not having control persistance you never have it. This assumes that you are able to detect when your deployment is finished for performing those cleanup steps. From aris at 0xbadc0de.be Wed Sep 25 06:21:29 2013 From: aris at 0xbadc0de.be (Aris Adamantiadis) Date: Tue, 24 Sep 2013 22:21:29 +0200 Subject: [PATCH] curve25519-sha256@libssh.org key exchange proposal Message-ID: <5241F449.8070407@0xbadc0de.be> Dear OpenSSH developers, I've worked this week on an alternative key exchange mechanism, in reaction to the whole NSA leaks and claims over cryptographic backdoors and/or cracking advances. The key exchange is in my opinion the most critical defense against passive eavesdropping attacks. I believe Curve25519 from DJB can give users a secure alternative to classical Diffie-Hellman (with fixed groups or group exchanges) and NIST-approved elliptic curves. Here is the rationale from the small specifications draft I wrote, available on http://tinyurl.com/q22npph : The reason is the following : During summer of 2013, revelations from ex-consultant at NSA Edward Snowden gave proof that NSA willingly inserts backdoors into softwares, hardware components and published standards. While it is still believed that the mathematics behind ECC cryptography are still sound and solid, some people (including Bruce Schneier [SCHNEIER]), showed their lack of confidence in NIST-published curves such as nistp256, nistp384, nistp521, for which constant parameters (including the generator point) are defined without explanation. It is also believed that NSA had a word to say in their definition. These curves are not the most secure or fastest possible for their key sizes [DJB], and researchers think it is possible that NSA have ways of cracking NIST curves. It is also interesting to note that SSH belongs to the list of protocols the NSA claims to be able to eavesdrop. Having a secure replacement would make passive attacks much harder if such a backdoor exists. However an alternative exists in the form of Curve25519. This algorithm has been proposed in 2006 by DJB [Curve25519]. Its main stengths are its speed, its constant-time run time (and resistance against side-channel attacks), and its lack of nebulous hard-coded constants. The reference version being used in this document is the one described in [Curve25519] as implemented in the library NaCl [NaCl]. I namespaced this method with @libssh.org since I implemented it first in libssh and intent to release it with the next release. In attachment, you will find a patch to openssh-6.3p1 (I think adaptations for OpenSSH are trivial). It links to libnacl. However, my autotools skills are lacking and I compiled it with LIBS=-libnacl. I would greatly appreciate feedback and/or a debate on the relevancy of such kex method, code quality and implementation details. Aris Adamantiadis www.libssh.org -------------- next part -------------- >From c3105fa718ca813a06527a238294c148dfc91287 Mon Sep 17 00:00:00 2001 From: Aris Adamantiadis Date: Tue, 24 Sep 2013 21:59:36 +0200 Subject: [PATCH] kex: implement curve25519-sha256 at libssh.org --- Makefile.in | 4 +- kex.c | 1 + kex.h | 9 ++++ kexc25519.c | 96 +++++++++++++++++++++++++++++++++++++ kexc25519c.c | 149 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++ kexc25519s.c | 144 +++++++++++++++++++++++++++++++++++++++++++++++++++++++ myproposal.h | 1 + ssh-keyscan.c | 1 + sshconnect2.c | 1 + sshd.c | 1 + 10 files changed, 405 insertions(+), 2 deletions(-) create mode 100644 kexc25519.c create mode 100644 kexc25519c.c create mode 100644 kexc25519s.c diff --git a/Makefile.in b/Makefile.in index 92c95a9..a8e282a 100644 --- a/Makefile.in +++ b/Makefile.in @@ -73,7 +73,7 @@ LIBSSH_OBJS=authfd.o authfile.o bufaux.o bufbn.o buffer.o \ monitor_fdpass.o rijndael.o ssh-dss.o ssh-ecdsa.o ssh-rsa.o dh.o \ kexdh.o kexgex.o kexdhc.o kexgexc.o bufec.o kexecdh.o kexecdhc.o \ msg.o progressmeter.o dns.o entropy.o gss-genr.o umac.o umac128.o \ - jpake.o schnorr.o ssh-pkcs11.o krl.o + jpake.o schnorr.o ssh-pkcs11.o krl.o kexc25519.o kexc25519c.o SSHOBJS= ssh.o readconf.o clientloop.o sshtty.o \ sshconnect.o sshconnect1.o sshconnect2.o mux.o \ @@ -93,7 +93,7 @@ SSHDOBJS=sshd.o auth-rhosts.o auth-passwd.o auth-rsa.o auth-rh-rsa.o \ sftp-server.o sftp-common.o \ roaming_common.o roaming_serv.o \ sandbox-null.o sandbox-rlimit.o sandbox-systrace.o sandbox-darwin.o \ - sandbox-seccomp-filter.o + sandbox-seccomp-filter.o kexc25519s.o MANPAGES = moduli.5.out scp.1.out ssh-add.1.out ssh-agent.1.out ssh-keygen.1.out ssh-keyscan.1.out ssh.1.out sshd.8.out sftp-server.8.out sftp.1.out ssh-keysign.8.out ssh-pkcs11-helper.8.out sshd_config.5.out ssh_config.5.out MANPAGES_IN = moduli.5 scp.1 ssh-add.1 ssh-agent.1 ssh-keygen.1 ssh-keyscan.1 ssh.1 sshd.8 sftp-server.8 sftp.1 ssh-keysign.8 ssh-pkcs11-helper.8 sshd_config.5 ssh_config.5 diff --git a/kex.c b/kex.c index 54bd1a4..a27f9c3 100644 --- a/kex.c +++ b/kex.c @@ -80,6 +80,7 @@ static const struct kexalg kexalgs[] = { { KEX_ECDH_SHA2_NISTP384, KEX_ECDH_SHA2, NID_secp384r1, EVP_sha384 }, { KEX_ECDH_SHA2_NISTP521, KEX_ECDH_SHA2, NID_secp521r1, EVP_sha512 }, #endif + { KEX_CURVE25519_SHA256, KEX_C25519_SHA256, 0, EVP_sha256 }, { NULL, -1, -1, NULL}, }; diff --git a/kex.h b/kex.h index 9f1e1ad..df89ade 100644 --- a/kex.h +++ b/kex.h @@ -43,6 +43,7 @@ #define KEX_ECDH_SHA2_NISTP256 "ecdh-sha2-nistp256" #define KEX_ECDH_SHA2_NISTP384 "ecdh-sha2-nistp384" #define KEX_ECDH_SHA2_NISTP521 "ecdh-sha2-nistp521" +#define KEX_CURVE25519_SHA256 "curve25519-sha256 at libssh.org" #define COMP_NONE 0 #define COMP_ZLIB 1 @@ -74,6 +75,7 @@ enum kex_exchange { KEX_DH_GEX_SHA1, KEX_DH_GEX_SHA256, KEX_ECDH_SHA2, + KEX_C25519_SHA256, KEX_MAX }; @@ -161,6 +163,8 @@ void kexgex_client(Kex *); void kexgex_server(Kex *); void kexecdh_client(Kex *); void kexecdh_server(Kex *); +void kexc25519_client(Kex *); +void kexc25519_server(Kex *); void kex_dh_hash(char *, char *, char *, int, char *, int, u_char *, int, @@ -177,6 +181,11 @@ kex_ecdh_hash(const EVP_MD *, const EC_GROUP *, char *, char *, char *, int, #endif void +kex_c25519_hash(const EVP_MD *, char *, char *, char *, int, + char *, int, u_char *, int, const unsigned char *, const unsigned char *, + const BIGNUM *, u_char **, u_int *); + +void derive_ssh1_session_id(BIGNUM *, BIGNUM *, u_int8_t[8], u_int8_t[16]); #if defined(DEBUG_KEX) || defined(DEBUG_KEXDH) || defined(DEBUG_KEXECDH) diff --git a/kexc25519.c b/kexc25519.c new file mode 100644 index 0000000..8260fad --- /dev/null +++ b/kexc25519.c @@ -0,0 +1,96 @@ +/* + * Copyright (c) 2001 Markus Friedl. All rights reserved. + * Copyright (c) 2010 Damien Miller. All rights reserved. + * Copyright (c) 2013 Aris Adamantiadis. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +#include "includes.h" + + +#include + +#include +#include + +#include +#include + +#include "buffer.h" +#include "ssh2.h" +#include "key.h" +#include "cipher.h" +#include "kex.h" +#include "log.h" + +#include +#define CURVE25519_PUBKEY_SIZE crypto_scalarmult_curve25519_BYTES + +void +kex_c25519_hash( + const EVP_MD *evp_md, + char *client_version_string, + char *server_version_string, + char *ckexinit, int ckexinitlen, + char *skexinit, int skexinitlen, + u_char *serverhostkeyblob, int sbloblen, + const unsigned char client_dh_pub[CURVE25519_PUBKEY_SIZE], + const unsigned char server_dh_pub[CURVE25519_PUBKEY_SIZE], + const BIGNUM *shared_secret, + u_char **hash, u_int *hashlen) +{ + Buffer b; + EVP_MD_CTX md; + static u_char digest[EVP_MAX_MD_SIZE]; + + buffer_init(&b); + buffer_put_cstring(&b, client_version_string); + buffer_put_cstring(&b, server_version_string); + + /* kexinit messages: fake header: len+SSH2_MSG_KEXINIT */ + buffer_put_int(&b, ckexinitlen+1); + buffer_put_char(&b, SSH2_MSG_KEXINIT); + buffer_append(&b, ckexinit, ckexinitlen); + buffer_put_int(&b, skexinitlen+1); + buffer_put_char(&b, SSH2_MSG_KEXINIT); + buffer_append(&b, skexinit, skexinitlen); + + buffer_put_string(&b, serverhostkeyblob, sbloblen); + buffer_put_string(&b, client_dh_pub, CURVE25519_PUBKEY_SIZE); + buffer_put_string(&b, server_dh_pub, CURVE25519_PUBKEY_SIZE); + buffer_put_bignum2(&b, shared_secret); + +#ifdef DEBUG_KEX + buffer_dump(&b); +#endif + EVP_DigestInit(&md, evp_md); + EVP_DigestUpdate(&md, buffer_ptr(&b), buffer_len(&b)); + EVP_DigestFinal(&md, digest, NULL); + + buffer_free(&b); + +#ifdef DEBUG_KEX + dump_digest("hash", digest, EVP_MD_size(evp_md)); +#endif + *hash = digest; + *hashlen = EVP_MD_size(evp_md); +} diff --git a/kexc25519c.c b/kexc25519c.c new file mode 100644 index 0000000..b2000f0 --- /dev/null +++ b/kexc25519c.c @@ -0,0 +1,149 @@ +/* + * Copyright (c) 2001 Markus Friedl. All rights reserved. + * Copyright (c) 2010 Damien Miller. All rights reserved. + * Copyright (c) 2013 Aris Adamantiadis. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +#include "includes.h" + +#include + +#include +#include +#include + +#include "xmalloc.h" +#include "buffer.h" +#include "key.h" +#include "cipher.h" +#include "kex.h" +#include "log.h" +#include "packet.h" +#include "dh.h" +#include "ssh2.h" + +#include +#define CURVE25519_PUBKEY_SIZE crypto_scalarmult_curve25519_BYTES +#define CURVE25519_PRIVKEY_SIZE crypto_scalarmult_curve25519_SCALARBYTES + +void +kexc25519_client(Kex *kex) +{ + BIGNUM *shared_secret; + Key *server_host_key; + u_char client_key[CURVE25519_PRIVKEY_SIZE]; + u_char client_pubkey[CURVE25519_PUBKEY_SIZE]; + u_char *server_pubkey = NULL; + u_char shared_secret_raw[CURVE25519_PUBKEY_SIZE]; + u_char *server_host_key_blob = NULL, *signature = NULL; + u_char *hash; + u_int rnd = 0, slen, sbloblen, hashlen, i; + + /* generate private key */ + for (i = 0; i < sizeof(client_key); i++) { + if (i % 4 == 0) + rnd = arc4random(); + client_key[i] = rnd; + rnd >>= 8; + } + crypto_scalarmult_curve25519_base(client_pubkey, client_key); + + packet_start(SSH2_MSG_KEX_ECDH_INIT); + packet_put_string(client_pubkey, sizeof(client_pubkey)); + packet_send(); + debug("sending SSH2_MSG_KEX_ECDH_INIT"); + +#ifdef DEBUG_KEXECDH + dump_digest("client private key:", client_key, sizeof(client_key)); +#endif + + debug("expecting SSH2_MSG_KEX_ECDH_REPLY"); + packet_read_expect(SSH2_MSG_KEX_ECDH_REPLY); + + /* hostkey */ + server_host_key_blob = packet_get_string(&sbloblen); + server_host_key = key_from_blob(server_host_key_blob, sbloblen); + if (server_host_key == NULL) + fatal("cannot decode server_host_key_blob"); + if (server_host_key->type != kex->hostkey_type) + fatal("type mismatch for decoded server_host_key_blob"); + if (kex->verify_host_key == NULL) + fatal("cannot verify server_host_key"); + if (kex->verify_host_key(server_host_key) == -1) + fatal("server_host_key verification failed"); + + /* Q_S, server public key */ + server_pubkey = packet_get_string(&slen); + if (slen != CURVE25519_PUBKEY_SIZE) + fatal("Incorrect size for server Curve25519 public key: %d", slen); + +#ifdef DEBUG_KEXECDH + dump_digest("server public key:\n", server_pubkey, CURVE25519_PUBKEY_SIZE); +#endif + + /* signed H */ + signature = packet_get_string(&slen); + packet_check_eom(); + + crypto_scalarmult_curve25519(shared_secret_raw, client_key, server_pubkey); + +#ifdef DEBUG_KEXECDH + dump_digest("shared secret", shared_secret_raw, sizeof(shared_secret_raw)); +#endif + if ((shared_secret = BN_new()) == NULL) + fatal("%s: BN_new failed", __func__); + if (BN_bin2bn(shared_secret_raw, sizeof(shared_secret_raw), shared_secret) == NULL) + fatal("%s: BN_bin2bn failed", __func__); + memset(shared_secret_raw, 0, sizeof(shared_secret_raw)); + + /* calc and verify H */ + kex_c25519_hash( + kex->evp_md, + kex->client_version_string, + kex->server_version_string, + buffer_ptr(&kex->my), buffer_len(&kex->my), + buffer_ptr(&kex->peer), buffer_len(&kex->peer), + server_host_key_blob, sbloblen, + client_pubkey, + server_pubkey, + shared_secret, + &hash, &hashlen + ); + free(server_host_key_blob); + free(server_pubkey); + if (key_verify(server_host_key, signature, slen, hash, hashlen) != 1) + fatal("key_verify failed for server_host_key"); + key_free(server_host_key); + free(signature); + + /* save session id */ + if (kex->session_id == NULL) { + kex->session_id_len = hashlen; + kex->session_id = xmalloc(kex->session_id_len); + memcpy(kex->session_id, hash, kex->session_id_len); + } + + kex_derive_keys(kex, hash, hashlen, shared_secret); + BN_clear_free(shared_secret); + kex_finish(kex); +} diff --git a/kexc25519s.c b/kexc25519s.c new file mode 100644 index 0000000..51fa24a --- /dev/null +++ b/kexc25519s.c @@ -0,0 +1,144 @@ +/* + * Copyright (c) 2001 Markus Friedl. All rights reserved. + * Copyright (c) 2010 Damien Miller. All rights reserved. + * Copyright (c) 2013 Aris Adamantiadis. All rights reserved. + * + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +#include "includes.h" + +#include +#include +#include + +#include "xmalloc.h" +#include "buffer.h" +#include "key.h" +#include "cipher.h" +#include "kex.h" +#include "log.h" +#include "packet.h" +#include "dh.h" +#include "ssh2.h" +#include "monitor_wrap.h" + +#include +#define CURVE25519_PUBKEY_SIZE crypto_scalarmult_curve25519_BYTES +#define CURVE25519_PRIVKEY_SIZE crypto_scalarmult_curve25519_SCALARBYTES + +void +kexc25519_server(Kex *kex) +{ + BIGNUM *shared_secret; + Key *server_host_private, *server_host_public; + u_char *server_host_key_blob = NULL, *signature = NULL; + u_char server_key[CURVE25519_PRIVKEY_SIZE]; + u_char *client_pubkey = NULL; + u_char server_pubkey[CURVE25519_PUBKEY_SIZE]; + u_char shared_secret_raw[CURVE25519_PUBKEY_SIZE]; + u_char *hash; + u_int rnd=0, slen, sbloblen, hashlen, i; + + /* generate private key */ + for (i = 0; i < sizeof(server_key); i++) { + if (i % 4 == 0) + rnd = arc4random(); + server_key[i] = rnd; + rnd >>= 8; + } + crypto_scalarmult_curve25519_base(server_pubkey, server_key); +#ifdef DEBUG_KEXECDH + dump_digest("server private key:", server_key, sizeof(server_key)); +#endif + + if (kex->load_host_public_key == NULL || + kex->load_host_private_key == NULL) + fatal("Cannot load hostkey"); + server_host_public = kex->load_host_public_key(kex->hostkey_type); + if (server_host_public == NULL) + fatal("Unsupported hostkey type %d", kex->hostkey_type); + server_host_private = kex->load_host_private_key(kex->hostkey_type); + + debug("expecting SSH2_MSG_KEX_ECDH_INIT"); + packet_read_expect(SSH2_MSG_KEX_ECDH_INIT); + client_pubkey = packet_get_string(&slen); + if (slen != CURVE25519_PUBKEY_SIZE) + fatal("Incorrect size for server Curve25519 public key: %d", slen); + packet_check_eom(); + +#ifdef DEBUG_KEXECDH + dump_digest("client public key:\n", client_pubkey, CURVE25519_PUBKEY_SIZE); +#endif + + crypto_scalarmult_curve25519(shared_secret_raw, server_key, client_pubkey); + +#ifdef DEBUG_KEXECDH + dump_digest("shared secret", shared_secret_raw, sizeof(shared_secret_raw)); +#endif + if ((shared_secret = BN_new()) == NULL) + fatal("%s: BN_new failed", __func__); + if (BN_bin2bn(shared_secret_raw, sizeof(shared_secret_raw), shared_secret) == NULL) + fatal("%s: BN_bin2bn failed", __func__); + memset(shared_secret_raw, 0, sizeof(shared_secret_raw)); + + /* calc H */ + key_to_blob(server_host_public, &server_host_key_blob, &sbloblen); + kex_c25519_hash( + kex->evp_md, + kex->client_version_string, + kex->server_version_string, + buffer_ptr(&kex->peer), buffer_len(&kex->peer), + buffer_ptr(&kex->my), buffer_len(&kex->my), + server_host_key_blob, sbloblen, + client_pubkey, + server_pubkey, + shared_secret, + &hash, &hashlen + ); + + /* save session id := H */ + if (kex->session_id == NULL) { + kex->session_id_len = hashlen; + kex->session_id = xmalloc(kex->session_id_len); + memcpy(kex->session_id, hash, kex->session_id_len); + } + + /* sign H */ + kex->sign(server_host_private, server_host_public, &signature, &slen, + hash, hashlen); + + /* destroy_sensitive_data(); */ + + /* send server hostkey, ECDH pubkey 'Q_S' and signed H */ + packet_start(SSH2_MSG_KEX_ECDH_REPLY); + packet_put_string(server_host_key_blob, sbloblen); + packet_put_string(server_pubkey, sizeof(server_pubkey)); + packet_put_string(signature, slen); + packet_send(); + + free(signature); + free(server_host_key_blob); + /* have keys, free server key */ + free(client_pubkey); + kex_derive_keys(kex, hash, hashlen, shared_secret); + BN_clear_free(shared_secret); + kex_finish(kex); +} diff --git a/myproposal.h b/myproposal.h index 4e913e3..0d88090 100644 --- a/myproposal.h +++ b/myproposal.h @@ -66,6 +66,7 @@ #endif # define KEX_DEFAULT_KEX \ + "curve25519-sha256 at libssh.org," \ KEX_ECDH_METHODS \ KEX_SHA256_METHODS \ "diffie-hellman-group-exchange-sha1," \ diff --git a/ssh-keyscan.c b/ssh-keyscan.c index 8b807c1..dfe561b 100644 --- a/ssh-keyscan.c +++ b/ssh-keyscan.c @@ -254,6 +254,7 @@ keygrab_ssh2(con *c) c->c_kex->kex[KEX_DH_GEX_SHA1] = kexgex_client; c->c_kex->kex[KEX_DH_GEX_SHA256] = kexgex_client; c->c_kex->kex[KEX_ECDH_SHA2] = kexecdh_client; + c->c_kex->kex[KEX_C25519_SHA256] = kexc25519_client; c->c_kex->verify_host_key = hostjump; if (!(j = setjmp(kexjmp))) { diff --git a/sshconnect2.c b/sshconnect2.c index 70e3cd8..68031a5 100644 --- a/sshconnect2.c +++ b/sshconnect2.c @@ -208,6 +208,7 @@ ssh_kex2(char *host, struct sockaddr *hostaddr, u_short port) kex->kex[KEX_DH_GEX_SHA1] = kexgex_client; kex->kex[KEX_DH_GEX_SHA256] = kexgex_client; kex->kex[KEX_ECDH_SHA2] = kexecdh_client; + kex->kex[KEX_C25519_SHA256] = kexc25519_client; kex->client_version_string=client_version_string; kex->server_version_string=server_version_string; kex->verify_host_key=&verify_host_key_callback; diff --git a/sshd.c b/sshd.c index 174cc7a..56f75d9 100644 --- a/sshd.c +++ b/sshd.c @@ -2446,6 +2446,7 @@ do_ssh2_kex(void) kex->kex[KEX_DH_GEX_SHA1] = kexgex_server; kex->kex[KEX_DH_GEX_SHA256] = kexgex_server; kex->kex[KEX_ECDH_SHA2] = kexecdh_server; + kex->kex[KEX_C25519_SHA256] = kexc25519_server; kex->server = 1; kex->client_version_string=client_version_string; kex->server_version_string=server_version_string; -- 1.7.10.4 From mfriedl at gmail.com Wed Sep 25 06:57:27 2013 From: mfriedl at gmail.com (Markus Friedl) Date: Tue, 24 Sep 2013 22:57:27 +0200 Subject: [PATCH] curve25519-sha256@libssh.org key exchange proposal In-Reply-To: <5241F449.8070407@0xbadc0de.be> References: <5241F449.8070407@0xbadc0de.be> Message-ID: <5DD5FFB6-2BD3-4B39-AD40-156F29583666@gmail.com> thanks, i was looking into doing this, too. still looking for a way to keep the number of dublicated lines down.... Am 24.09.2013 um 22:21 schrieb Aris Adamantiadis : > <0001-kex-implement-curve25519-sha256-libssh.org.patch> From scott_n at xypro.com Wed Sep 25 07:32:37 2013 From: scott_n at xypro.com (Scott Neugroschl) Date: Tue, 24 Sep 2013 21:32:37 +0000 Subject: Port Knocking? Message-ID: I haven't been keeping up with the internals, I'm afraid. Does OpenSSH have support for Port Knocking? I might be interested in looking into that, as a way of reacquainting myself with the current code base. --- Scott Neugroschl | XYPRO Technology Corporation 4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 583-2874|Fax 805 583-0124 | From roland.mainz at nrubsig.org Wed Sep 25 07:39:57 2013 From: roland.mainz at nrubsig.org (Roland Mainz) Date: Tue, 24 Sep 2013 23:39:57 +0200 Subject: Multiple keys/methods per key exchange (e.g. multi-md5-sha1-md4@libssh.org) Re: [PATCH] curve25519-sha256@libssh.org key exchange proposal Message-ID: On Tue, Sep 24, 2013 at 10:21 PM, Aris Adamantiadis wrote: [snip] > I've worked this week on an alternative key exchange mechanism, in > reaction to the whole NSA leaks and claims over cryptographic backdoors > and/or cracking advances. The key exchange is in my opinion the most > critical defense against passive eavesdropping attacks. > I believe Curve25519 from DJB can give users a secure alternative to > classical Diffie-Hellman (with fixed groups or group exchanges) and > NIST-approved elliptic curves. [snip] ... that reminds me of an old idea (note: I'm no expert in this stuff... which means the idea may be total nonsense... or not... :-) ): Is it usefull to combine multiple hash algorithms/methods for a key exchange ? The idea would be to use something like "md5" and "sha1" in a key exchange (and append the hash sums) ... individually there are obsolete and more or less cracked or have serious weaknesses, but if the hash sums are combined (e.g. appended... *NOT* XOR'ed !) it would be near impossible to exploit the known weaknesses for reasonable small data. AFAIK the advantages would be: - Existing hardware acceleration for md4/md5/sha1 can be used - Even using something like md5+sha256 would mean additional protection against weaknesses in either of the hash sum methods - All algorithms can be executed in parallel (either different CPUs or different crypto engines) Note that the whole thing is not limited to two keys/methods, in theory there could be something like "multi-md5-sha1-md4-sha256 at libssh.org" to use md5, sha1, md4 and sha256 hash sums. Question is now... how mad/bad is the idea ? ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 3992797 (;O/ \/ \O;) From ag4ve.us at gmail.com Wed Sep 25 08:57:15 2013 From: ag4ve.us at gmail.com (Shawn Wilson) Date: Tue, 24 Sep 2013 18:57:15 -0400 Subject: Port Knocking? In-Reply-To: References: Message-ID: <8667a21d-16fe-47c7-9415-b9de0f872e00@email.android.com> AFAIK, no. However IIRC fwknop has a patch for ssh (never used the patch). SSH shouldn't have port knocking code either imo as there are more than one way to knock and this isn't ssh data or key management. Scott Neugroschl wrote: >I haven't been keeping up with the internals, I'm afraid. Does >OpenSSH have support for Port Knocking? >I might be interested in looking into that, as a way of reacquainting >myself with the current code base. > >--- >Scott Neugroschl | XYPRO Technology Corporation >4100 Guardian Street | Suite 100 |Simi Valley, CA 93063 | Phone 805 >583-2874|Fax 805 583-0124 | > >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From aris at 0xbadc0de.be Wed Sep 25 15:48:05 2013 From: aris at 0xbadc0de.be (Aris Adamantiadis) Date: Wed, 25 Sep 2013 07:48:05 +0200 Subject: Multiple keys/methods per key exchange (e.g. multi-md5-sha1-md4@libssh.org) Re: [PATCH] curve25519-sha256@libssh.org key exchange proposal In-Reply-To: References: Message-ID: <52427915.3040900@0xbadc0de.be> Le 24/09/13 23:39, Roland Mainz a ?crit : > Is it usefull to combine multiple hash algorithms/methods for a key exchange ? > > The idea would be to use something like "md5" and "sha1" in a key > exchange (and append the hash sums) ... individually there are > obsolete and more or less cracked or have serious weaknesses, but if > the hash sums are combined (e.g. appended... *NOT* XOR'ed !) it would > be near impossible to exploit the known weaknesses for reasonable > small data. Hi, That doesn't seem a very good idea. It is harmless, but currently we still have no preimage attack on sha1, which would be needed to perform such an attack. SHA2 is still very strong and that's what is used with all ECDH key exchange. MD5 is used nowhere in SSH (and there's no preimage attack for it either). I am myself thinking of using SHA3 in sponge mode for the packet authentication layer but it's probably overkill. Using existing crypto correctly (like ETM mode) is probably more efficient. Aris From naddy at mips.inka.de Thu Sep 26 01:40:44 2013 From: naddy at mips.inka.de (Christian Weisgerber) Date: Wed, 25 Sep 2013 15:40:44 +0000 (UTC) Subject: Multiple keys/methods per key exchange (e.g. multi-md5-sha1-md4@libssh.org) Re: [PATCH] curve25519-sha256@libssh.org key exchange proposal References: Message-ID: Roland Mainz wrote: > Is it usefull to combine multiple hash algorithms/methods for a key exchange ? > > The idea would be to use something like "md5" and "sha1" in a key > exchange (and append the hash sums) ... individually there are > obsolete and more or less cracked or have serious weaknesses, but if > the hash sums are combined (e.g. appended... *NOT* XOR'ed !) it would > be near impossible to exploit the known weaknesses for reasonable > small data. In general, this is not a good idea, see Antoine Joux, "Multicollisions in iterated hash functions. Application to cascased constructions" http://www.iacr.org/cryptodb/archive/2004/CRYPTO/1472/1472.pdf -- Christian "naddy" Weisgerber naddy at mips.inka.de From iszczesniak at gmail.com Thu Sep 26 02:26:42 2013 From: iszczesniak at gmail.com (Irek Szczesniak) Date: Wed, 25 Sep 2013 18:26:42 +0200 Subject: Multiple keys/methods per key exchange (e.g. multi-md5-sha1-md4@libssh.org) Re: [PATCH] curve25519-sha256@libssh.org key exchange proposal In-Reply-To: References: Message-ID: On Wed, Sep 25, 2013 at 5:40 PM, Christian Weisgerber wrote: > Roland Mainz wrote: > >> Is it usefull to combine multiple hash algorithms/methods for a key exchange ? >> >> The idea would be to use something like "md5" and "sha1" in a key >> exchange (and append the hash sums) ... individually there are >> obsolete and more or less cracked or have serious weaknesses, but if >> the hash sums are combined (e.g. appended... *NOT* XOR'ed !) it would >> be near impossible to exploit the known weaknesses for reasonable >> small data. > > In general, this is not a good idea, see > > Antoine Joux, "Multicollisions in iterated hash functions. Application > to cascased constructions" > http://www.iacr.org/cryptodb/archive/2004/CRYPTO/1472/1472.pdf I see one merit: If openssh combines multiple hash algorithms a single exploit in a single hash algorithms has no use. That would guard against sneaky NSA&fellows and their happy sure-we-can-never-crack-because-we-designed-it-that-way SHA2. If you'd read the commendatory on the Snowden papers you'd seen the comment that the NSA can handle SHA2 much faster than AES-256 so anything based on that can no longer be considered 'secure'. Irek From vir.khatri at gmail.com Thu Sep 26 02:55:27 2013 From: vir.khatri at gmail.com (Virender Khatri) Date: Wed, 25 Sep 2013 22:25:27 +0530 Subject: CA Signed Public Key User Authentication does not honor ~/.ssh/authorized_keys Message-ID: Greetings, I am using OpenSSH Signed Public Key authentication for servers ssh login. All of the servers are setup with below sshd_config options: TrustedUserCAKeys /etc/ssh/ca.pub # CA Public Keys RevokedKeys /etc/ssh/revoke.pub # User Public Keys When i started working on it, for ssh authentication i had to have CA Public Key in User ~/.ssh/authorized_keys, like: cert-authority ssh-rsa But, now i am able to login without having CA Public Key in User ' ~/.ssh/authorized_keys' file. Even if i remove '' ~/.ssh/authorized_keys' file from for a user, i am able to login. I wanted to know whether it is no longer require or it is a bug. OpenSSH Version - openssh-6.1p1-8.30.amzn1.x86_64. -V From dflatley at us.ibm.com Fri Sep 27 04:30:57 2013 From: dflatley at us.ibm.com (David Flatley) Date: Thu, 26 Sep 2013 14:30:57 -0400 Subject: 6.2p2 question Message-ID: Built RPM's from the 6.2p2 openssh.spec file on a Red Hat 6.4 x86_64 server. Build a new Red Hat 6.4 x86_64 server, then when I go to install the RPM's on the server it overwrites the functioning /etc/ssh/sshd_config and /etc/pam.d/sshd files with a non-functional versions. Normally when I compile on the systems Openssh does not over write these files. Any ideas? Thanks David Flatley To err is human. To really screw up requires the root password." -UNKNOWN From cloos at jhcloos.com Fri Sep 27 06:30:58 2013 From: cloos at jhcloos.com (James Cloos) Date: Thu, 26 Sep 2013 16:30:58 -0400 Subject: [PATCH] curve25519-sha256@libssh.org key exchange proposal In-Reply-To: <5241F449.8070407@0xbadc0de.be> (Aris Adamantiadis's message of "Tue, 24 Sep 2013 22:21:29 +0200") References: <5241F449.8070407@0xbadc0de.be> Message-ID: Cool. Did you consider ed25519 for the kex? http://ed25519.cr.yp.to/ -JimC -- James Cloos OpenPGP: 1024D/ED7DAEA6 From layer at franz.com Fri Sep 27 06:52:55 2013 From: layer at franz.com (Kevin Layer) Date: Thu, 26 Sep 2013 13:52:55 -0700 Subject: ssh-agent w/timeout: does ssh-add reset that timeout? Message-ID: <19710.1380228775@freon.franz.com> I run ssh-agent like this: /usr/bin/ssh-agent -t 12h -s If I run ssh-add will it reset the timeout period back to 12h for that key, if it was already known to ssh-agent? I ask because I've looked at the documentation and performed exhaustive google searches for the answer and I've found no mention of this issue anywhere. Thank you. From aris at 0xbadc0de.be Fri Sep 27 07:15:08 2013 From: aris at 0xbadc0de.be (Aris Adamantiadis) Date: Thu, 26 Sep 2013 23:15:08 +0200 Subject: [PATCH] curve25519-sha256@libssh.org key exchange proposal In-Reply-To: References: <5241F449.8070407@0xbadc0de.be> Message-ID: <5244A3DC.6010408@0xbadc0de.be> Le 26/09/13 22:30, James Cloos a ?crit : > Cool. > > Did you consider ed25519 for the kex? > > http://ed25519.cr.yp.to/ > > -JimC > Hi, ed25519 is a signature algorithm and is not relevant to the key exchange. It could be used for authentication (server host key and user's private keys) however I do not feel this increases the confidentiality properties of SSH. (btw I'm still expecting more feedback, negative or positive, to the my proposal and how it could be shipped with openssh). Aris From tim at multitalents.net Fri Sep 27 07:19:41 2013 From: tim at multitalents.net (Tim Rice) Date: Thu, 26 Sep 2013 14:19:41 -0700 (PDT) Subject: 6.2p2 question In-Reply-To: References: Message-ID: On Thu, 26 Sep 2013, David Flatley wrote: > > Built RPM's from the 6.2p2 openssh.spec file on a Red Hat 6.4 x86_64 > server. Build a new Red Hat 6.4 x86_64 server, then when I go to install > the RPM's on the server it overwrites > the functioning /etc/ssh/sshd_config and /etc/pam.d/sshd files with a > non-functional versions. Normally when I compile on the systems Openssh > does not over write these files. > Any ideas? Looking at the contrib/redhat/openssh.spec file ..... %attr(0644,root,root) %config(noreplace) %{_sysconfdir}/ssh/ssh_config %attr(0600,root,root) %config(noreplace) %{_sysconfdir}/ssh/sshd_config %attr(0600,root,root) %config(noreplace) /etc/pam.d/sshd .... we see those files are noreplace. So some of the possibilities are a modified openssh.spec, or maybe using --force or --replacefiles caused grief. > > Thanks > David Flatley > To err is human. To really screw up requires the root password." -UNKNOWN > -- Tim Rice Multitalents tim at multitalents.net From djm at mindrot.org Fri Sep 27 08:24:40 2013 From: djm at mindrot.org (Damien Miller) Date: Fri, 27 Sep 2013 08:24:40 +1000 (EST) Subject: [PATCH] curve25519-sha256@libssh.org key exchange proposal In-Reply-To: References: <5241F449.8070407@0xbadc0de.be> Message-ID: On Thu, 26 Sep 2013, James Cloos wrote: > Cool. > > Did you consider ed25519 for the kex? > > http://ed25519.cr.yp.to/ No, but it would make a good public key type. I'm interested in supporting ed25519 as a key algorithm, EC-DH in curve25519 and ChaCha/Salsa20+poly1305 as an AEAD cipher+MAC. Just need to figure out when and how :) -d From djm at mindrot.org Fri Sep 27 08:28:52 2013 From: djm at mindrot.org (Damien Miller) Date: Fri, 27 Sep 2013 08:28:52 +1000 (EST) Subject: ssh-agent w/timeout: does ssh-add reset that timeout? In-Reply-To: <19710.1380228775@freon.franz.com> References: <19710.1380228775@freon.franz.com> Message-ID: On Thu, 26 Sep 2013, Kevin Layer wrote: > I run ssh-agent like this: > > /usr/bin/ssh-agent -t 12h -s > > If I run ssh-add will it reset the timeout period back to 12h for that > key, if it was already known to ssh-agent? Yes From layer at franz.com Fri Sep 27 08:50:30 2013 From: layer at franz.com (Kevin Layer) Date: Thu, 26 Sep 2013 15:50:30 -0700 Subject: ssh-agent w/timeout: does ssh-add reset that timeout? In-Reply-To: References: <19710.1380228775@freon.franz.com> Message-ID: <28221.1380235830@freon.franz.com> Damien Miller wrote: >> On Thu, 26 Sep 2013, Kevin Layer wrote: >> >> > I run ssh-agent like this: >> > >> > /usr/bin/ssh-agent -t 12h -s >> > >> > If I run ssh-add will it reset the timeout period back to 12h for that >> > key, if it was already known to ssh-agent? >> >> Yes It would be nice to update the documentation for ssh-add to say this, as well as a mention for the -t argument for ssh-agent. Thanks. From rosslagerwall at gmail.com Mon Sep 30 18:22:23 2013 From: rosslagerwall at gmail.com (Ross Lagerwall) Date: Mon, 30 Sep 2013 10:22:23 +0200 Subject: [PATCH] Implement SSH2_FXF_APPEND Message-ID: <20130930082223.GA12650@hobo> Hi, Here is a fairly simple patch to implement append mode for the sftp server. The patch was tested against the portable version but it applies cleanly to the normal version. Regards -- Ross Lagerwall -------------- next part -------------- A non-text attachment was scrubbed... Name: sftp_append.patch Type: text/x-diff Size: 2543 bytes Desc: not available URL: