From aris at 0xbadc0de.be Wed Oct 2 00:09:08 2013 From: aris at 0xbadc0de.be (Aris Adamantiadis) Date: Tue, 01 Oct 2013 16:09:08 +0200 Subject: [PATCH] curve25519-sha256@libssh.org key exchange proposal In-Reply-To: <5DD5FFB6-2BD3-4B39-AD40-156F29583666@gmail.com> References: <5241F449.8070407@0xbadc0de.be> <5DD5FFB6-2BD3-4B39-AD40-156F29583666@gmail.com> Message-ID: <524AD784.9030204@0xbadc0de.be> Hi Markus, I'm really looking forward having this patch into upstream openssh, but I need to know what openssh expects from the code to be mergeable. There's some duplicated code but it's a general problem for shared key generation for ECDH, DH and Curve25519 in openssh. I could help but don't want to start hacking this code before receiving some feedback. Thanks, Aris Le 24/09/13 22:57, Markus Friedl a ?crit : > 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> > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From esk-openssh at esk.cs.usu.edu Wed Oct 2 07:38:16 2013 From: esk-openssh at esk.cs.usu.edu (Eldon Koyle) Date: Tue, 1 Oct 2013 15:38:16 -0600 Subject: sshd accepted fingerprint logging Message-ID: <20131001213816.GK25125@esk.usu.edu> Currently, LogLevel must be set to VERBOSE to see the fingerprint of an accepted key, and the default LogLevel is INFO. Since this is useful security information, I would like to propose that the 'Accepted publickey' message be modified to include the fingerprint of the accepted key. Is this a reasonable solution? Here is an example log snippet with LogLevel VERBOSE: Oct 1 15:23:24 somehost sshd[18603]: Set /proc/self/oom_score_adj to 0 Oct 1 15:23:24 somehost sshd[18603]: Connection from 192.168.1.2 port 49331 Oct 1 15:23:24 somehost sshd[18603]: Found matching RSA key: 7a:70:db:e4:2a:6f:1f:01:8a:fe:15:97:99:fb:e0:2a Oct 1 15:23:24 somehost sshd[18603]: Postponed publickey for someuser from 192.168.1.2 port 49331 ssh2 [preauth] Oct 1 15:23:24 somehost sshd[18603]: Found matching RSA key: 7a:70:db:e4:2a:6f:1f:01:8a:fe:15:97:99:fb:e0:2a Oct 1 15:23:24 somehost sshd[18603]: Accepted publickey for someuser from 192.168.1.2 port 49331 ssh2 Oct 1 15:23:24 somehost sshd[18603]: pam_unix(sshd:session): session opened for user someuser by (uid=0) Oct 1 15:23:24 somehost sshd[18603]: User child is on pid 18610 -- Eldon Koyle -- Men often believe -- or pretend -- that the "Law" is something sacred, or at least a science -- an unfounded assumption very convenient to governments. From dtucker at zip.com.au Wed Oct 2 12:45:27 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 2 Oct 2013 12:45:27 +1000 Subject: sshd accepted fingerprint logging In-Reply-To: <20131001213816.GK25125@esk.usu.edu> References: <20131001213816.GK25125@esk.usu.edu> Message-ID: <20131002024527.GA19736@gate.dtucker.net> On Tue, Oct 01, 2013 at 03:38:16PM -0600, Eldon Koyle wrote: > Currently, LogLevel must be set to VERBOSE to see the fingerprint of an > accepted key, and the default LogLevel is INFO. Since this is useful > security information, I would like to propose that the 'Accepted > publickey' message be modified to include the fingerprint of the > accepted key. Is this a reasonable solution? It's already in the 6.3 release at the default log level: Accepted publickey for dtucker from 127.0.0.1 port 43693 ssh2: RSA [fingerprint] -- 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 Theary.Loch at worldline.com Wed Oct 2 22:18:05 2013 From: Theary.Loch at worldline.com (Loch Theary) Date: Wed, 2 Oct 2013 14:18:05 +0200 Subject: sshd accepted fingerprint logging In-Reply-To: <20131001213816.GK25125@esk.usu.edu> References: <20131001213816.GK25125@esk.usu.edu> Message-ID: <5F8F324242D0E14B97060D4D32CD0F5C81DFCF17F9@FRSPX100.fr01.awl.atosorigin.net> My respects all, In the same idea, I have developed a patch (I called it "Audit data") and I wanted to propose to the community to be part of the main branch. Here is a few lines in my syslog files. Oct 1 23:01:00 XXXSOMEHOSTNAME1XXX sshd[31568]: LOGIN Audit Data: [ 82:12:65:5a:1a:91:58:71:b2:31:06:80:3c:1b:7b:95 # XXXFROM_IPXXX # /dev/pts/3 # sys_admin ] Oct 2 13:08:46 XXXSOMEHOSTNAME1XXX sshd[7689]: COMMAND Audit Data: [ 82:fa:c2:26:42:12:36:5b:56:25:9b:5c:fc:af:9f:8e # XXXFROM_IPXXX # no pty # sys_admin # rsync --server -logDtprI --timeout=30 --numeric-ids . / ] Oct 1 23:42:40 XXXSOMEHOSTNAME1XXX sshd[31567]: LOGOUT Audit Data: [ 82:12:65:5a:1a:91:58:71:b2:31:06:80:3c:1b:7b:95 # XXXFROM_IPXXX # /dev/pts/3 # sys_admin ] We manage a lot of "identical" hosts and instead of having an username for each person or implementing an expensive solution for Identity management (such as Novell Identity Manager or Control SA), we have defined "generic" users on the remote hosts (sys_admin, net_admin, dba_admin, ... ). SSH Public keys of authorized peoples are deployed via an internal tool to remote hosts according to their permissions. An unix administrator --> /home/sys_admin/.ssh/authorized_keys An Network administrator --> /home/net_admin/.ssh/authorized_keys And so on ... By patching the SSHD daemon with the "audit patch" I have created, SSHD sends to syslog all the details to identify who is connecting on "sys_admin" for a given time. (of course rsyslog also sends to a remote rsyslog server) 3 types of logs are sent to rsyslog: * LOGIN Audit data: [ Fingerprint + Source_IP + PTY allocated + Generic User used ] * LOGOUT Audit data: [ Fingerprint + Source_IP + PTY allocated + Generic User used ] * COMMAND Audit data (Command executed via "ssh host command" for instance) : [ fingerprint + Source IP + pty if allocated + Remote user used + Detail of the remote command launched] ("LogLevel INFO" in the sshd_config file) Do you find my idea is worth enough to be part of the main branch ? What is the procedure to "propose" a patch to the community ? Thank you for your answers in advance ! Best regards, Theary LOCH. (System and Security Engineer) -----Message d'origine----- De : openssh-unix-dev-bounces+theary.loch=atos.net at mindrot.org [mailto:openssh-unix-dev-bounces+theary.loch=atos.net at mindrot.org] De la part de Eldon Koyle Envoy? : mardi 1 octobre 2013 23:38 ? : openssh-unix-dev at mindrot.org Objet : sshd accepted fingerprint logging Currently, LogLevel must be set to VERBOSE to see the fingerprint of an accepted key, and the default LogLevel is INFO. Since this is useful security information, I would like to propose that the 'Accepted publickey' message be modified to include the fingerprint of the accepted key. Is this a reasonable solution? Here is an example log snippet with LogLevel VERBOSE: Oct 1 15:23:24 somehost sshd[18603]: Set /proc/self/oom_score_adj to 0 Oct 1 15:23:24 somehost sshd[18603]: Connection from 192.168.1.2 port 49331 Oct 1 15:23:24 somehost sshd[18603]: Found matching RSA key: 7a:70:db:e4:2a:6f:1f:01:8a:fe:15:97:99:fb:e0:2a Oct 1 15:23:24 somehost sshd[18603]: Postponed publickey for someuser from 192.168.1.2 port 49331 ssh2 [preauth] Oct 1 15:23:24 somehost sshd[18603]: Found matching RSA key: 7a:70:db:e4:2a:6f:1f:01:8a:fe:15:97:99:fb:e0:2a Oct 1 15:23:24 somehost sshd[18603]: Accepted publickey for someuser from 192.168.1.2 port 49331 ssh2 Oct 1 15:23:24 somehost sshd[18603]: pam_unix(sshd:session): session opened for user someuser by (uid=0) Oct 1 15:23:24 somehost sshd[18603]: User child is on pid 18610 -- Eldon Koyle -- Men often believe -- or pretend -- that the "Law" is something sacred, or at least a science -- an unfounded assumption very convenient to governments. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. From trent at trentnet.net Thu Oct 3 03:06:36 2013 From: trent at trentnet.net (Trent Gemmill) Date: Wed, 02 Oct 2013 13:06:36 -0400 Subject: Version problems Message-ID: <524C529C.8020401@trentnet.net> I pray I haven't missed something obvious. I downloaded, compiled and installed from tar version 6.3. Version 4.3 was previously installed. When I ssh in It identifies as version 6.3, but ssh -v reveals: Match ... remote version 4.3 . This is causing my system to fail a required security scan which doesn't like openssh version 4.3. Can anyone tell me what I am doing wrong? Thank you. From philipp.marek at linbit.com Thu Oct 3 03:49:56 2013 From: philipp.marek at linbit.com (Philipp Marek) Date: Wed, 02 Oct 2013 19:49:56 +0200 Subject: Version problems In-Reply-To: <524C529C.8020401@trentnet.net> References: <524C529C.8020401@trentnet.net> Message-ID: <2881526.FzBflsWuUB@cacao> > I pray I haven't missed something obvious. I downloaded, compiled and > installed from tar version 6.3. Version 4.3 was previously installed. > When I ssh in It identifies as version 6.3, but ssh -v reveals: > Match ... remote version 4.3 . This is causing my system to fail a > required security scan which doesn't like openssh version 4.3. Can > anyone tell me what I am doing wrong? Thank you. /usr/local/sbin vs. /usr/sbin, or similar path mismatches? From peter at stuge.se Thu Oct 3 03:55:13 2013 From: peter at stuge.se (Peter Stuge) Date: Wed, 2 Oct 2013 19:55:13 +0200 Subject: Version problems In-Reply-To: <524C529C.8020401@trentnet.net> References: <524C529C.8020401@trentnet.net> Message-ID: <20131002175513.32617.qmail@stuge.se> Trent Gemmill wrote: > Can anyone tell me what I am doing wrong? You've installed a new version of OpenSSH manually in parallell with the old version installed by the package manager. You'll have to resolve that, one way or the other. How to do that doesn't have anything to do with OpenSSH however. //Peter From keisial at gmail.com Thu Oct 3 09:19:19 2013 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Thu, 03 Oct 2013 01:19:19 +0200 Subject: Version problems In-Reply-To: <524C529C.8020401@trentnet.net> References: <524C529C.8020401@trentnet.net> Message-ID: <524CA9F7.4070504@gmail.com> Trent Gemmill wrote: > I pray I haven't missed something obvious. I downloaded, compiled and > installed from tar version 6.3. Version 4.3 was previously installed. > When I ssh in It identifies as version 6.3, but ssh -v reveals: Match > ... remote version 4.3 . This is causing my system to fail a required > security scan which doesn't like openssh version 4.3. Can anyone tell > me what I am doing wrong? Thank you. Did you forget to restart the openssh server? From luto at amacapital.net Thu Oct 3 13:44:03 2013 From: luto at amacapital.net (Andy Lutomirski) Date: Thu, 3 Oct 2013 04:44:03 +0100 Subject: DH modulus size Message-ID: With the default openssh configuration, the selected cipher is aes128-ctr. This means that dh_estimate gets called with bits=128, so dh_estimate selects a DH modulus size of 1024 bits. This seems questionable. Since the NSA seems to be sniffing most internet traffic, keeping SSH sessions secure against after-the-fact offline attack matters, and 1024-bit DH is not convincingly secure against well-funded adversaries. (On the other hand, 128-bit symmetric keys are probably secure against anyone without a rather large quantum computer.) Various current estimates suggest that the DH modulus should be somewhere between 2048 bits and 4096 bits, even with 128-bit symmetric keys. See, for example [1]. Would you accept a patch to change the group size estimate to something like: int dh_estimate(int bits) { if (bits <= 80) return (1024); if (bits <= 192) return (3072); return (4096); } Redhat [2] and Fedora [3] have open bugs about this. [1] http://www.keylength.com/en/5/ [2] https://bugzilla.redhat.com/show_bug.cgi?id=1010607 [2] https://bugzilla.redhat.com/show_bug.cgi?id=1012577 From silviuvlasceanu at yahoo.com Thu Oct 3 20:53:37 2013 From: silviuvlasceanu at yahoo.com (Silviu Vlasceanu) Date: Thu, 3 Oct 2013 13:53:37 +0300 Subject: ssh-keygen DSA keys longer than 1024 bit Message-ID: Hi, Why is there still a limit on the length of a DSA key generated by ssh-keygen? I mean that ssh-keygen only expects 1024 as key length, or fails. Here is the code excerpt that enforces the limitation: if (type == KEY_DSA && *bitsp != 1024) fatal("DSA keys must be 1024 bits"); Commenting these two lines allows the generation of, say, 2048 bit DSA keys that work just fine with sshd. The only reason that I could previously find is that 1024 is imposed by FIPS 186-2, but the current FIPS 186-3 allows for larger DSA keys. In light of the NIST SP800-131A guide that recommends 2048 as a minimum for DSA key length, can anyone please explain me why the limitation still exists in current openssh (6.3p1)? Is there a legal constraint? Thank you, -- Silviu From Theary.Loch at worldline.com Thu Oct 3 20:51:11 2013 From: Theary.Loch at worldline.com (Loch Theary) Date: Thu, 3 Oct 2013 12:51:11 +0200 Subject: sshd accepted fingerprint logging In-Reply-To: <5F8F324242D0E14B97060D4D32CD0F5C81DFCF17F9@FRSPX100.fr01.awl.atosorigin.net> References: <20131001213816.GK25125@esk.usu.edu> <5F8F324242D0E14B97060D4D32CD0F5C81DFCF17F9@FRSPX100.fr01.awl.atosorigin.net> Message-ID: <5F8F324242D0E14B97060D4D32CD0F5C81E404A09D@FRSPX100.fr01.awl.atosorigin.net> Just to be clear: the aim is to identity a user via the fingerprint of his ssh key when he logs in with a generic user on the remote host and without "Debug" mode for the sshd. (you can easily imagine how much 10 000 hosts costs in terms of network traffics and disk usage when all servers send theirs syslogs files to a central syslog server...) Best regards, Theary LOCH -----Message d'origine----- De : openssh-unix-dev-bounces+theary.loch=atos.net at mindrot.org [mailto:openssh-unix-dev-bounces+theary.loch=atos.net at mindrot.org] De la part de Loch Theary Envoy? : mercredi 2 octobre 2013 14:18 ? : openssh-unix-dev at mindrot.org Cc : Eldon Koyle Objet : RE: sshd accepted fingerprint logging My respects all, In the same idea, I have developed a patch (I called it "Audit data") and I wanted to propose to the community to be part of the main branch. Here is a few lines in my syslog files. Oct 1 23:01:00 XXXSOMEHOSTNAME1XXX sshd[31568]: LOGIN Audit Data: [ 82:12:65:5a:1a:91:58:71:b2:31:06:80:3c:1b:7b:95 # XXXFROM_IPXXX # /dev/pts/3 # sys_admin ] Oct 2 13:08:46 XXXSOMEHOSTNAME1XXX sshd[7689]: COMMAND Audit Data: [ 82:fa:c2:26:42:12:36:5b:56:25:9b:5c:fc:af:9f:8e # XXXFROM_IPXXX # no pty # sys_admin # rsync --server -logDtprI --timeout=30 --numeric-ids . / ] Oct 1 23:42:40 XXXSOMEHOSTNAME1XXX sshd[31567]: LOGOUT Audit Data: [ 82:12:65:5a:1a:91:58:71:b2:31:06:80:3c:1b:7b:95 # XXXFROM_IPXXX # /dev/pts/3 # sys_admin ] We manage a lot of "identical" hosts and instead of having an username for each person or implementing an expensive solution for Identity management (such as Novell Identity Manager or Control SA), we have defined "generic" users on the remote hosts (sys_admin, net_admin, dba_admin, ... ). SSH Public keys of authorized peoples are deployed via an internal tool to remote hosts according to their permissions. An unix administrator --> /home/sys_admin/.ssh/authorized_keys An Network administrator --> /home/net_admin/.ssh/authorized_keys And so on ... By patching the SSHD daemon with the "audit patch" I have created, SSHD sends to syslog all the details to identify who is connecting on "sys_admin" for a given time. (of course rsyslog also sends to a remote rsyslog server) 3 types of logs are sent to rsyslog: * LOGIN Audit data: [ Fingerprint + Source_IP + PTY allocated + Generic User used ] * LOGOUT Audit data: [ Fingerprint + Source_IP + PTY allocated + Generic User used ] * COMMAND Audit data (Command executed via "ssh host command" for instance) : [ fingerprint + Source IP + pty if allocated + Remote user used + Detail of the remote command launched] ("LogLevel INFO" in the sshd_config file) Do you find my idea is worth enough to be part of the main branch ? What is the procedure to "propose" a patch to the community ? Thank you for your answers in advance ! Best regards, Theary LOCH. (System and Security Engineer) -----Message d'origine----- De : openssh-unix-dev-bounces+theary.loch=atos.net at mindrot.org [mailto:openssh-unix-dev-bounces+theary.loch=atos.net at mindrot.org] De la part de Eldon Koyle Envoy? : mardi 1 octobre 2013 23:38 ? : openssh-unix-dev at mindrot.org Objet : sshd accepted fingerprint logging Currently, LogLevel must be set to VERBOSE to see the fingerprint of an accepted key, and the default LogLevel is INFO. Since this is useful security information, I would like to propose that the 'Accepted publickey' message be modified to include the fingerprint of the accepted key. Is this a reasonable solution? Here is an example log snippet with LogLevel VERBOSE: Oct 1 15:23:24 somehost sshd[18603]: Set /proc/self/oom_score_adj to 0 Oct 1 15:23:24 somehost sshd[18603]: Connection from 192.168.1.2 port 49331 Oct 1 15:23:24 somehost sshd[18603]: Found matching RSA key: 7a:70:db:e4:2a:6f:1f:01:8a:fe:15:97:99:fb:e0:2a Oct 1 15:23:24 somehost sshd[18603]: Postponed publickey for someuser from 192.168.1.2 port 49331 ssh2 [preauth] Oct 1 15:23:24 somehost sshd[18603]: Found matching RSA key: 7a:70:db:e4:2a:6f:1f:01:8a:fe:15:97:99:fb:e0:2a Oct 1 15:23:24 somehost sshd[18603]: Accepted publickey for someuser from 192.168.1.2 port 49331 ssh2 Oct 1 15:23:24 somehost sshd[18603]: pam_unix(sshd:session): session opened for user someuser by (uid=0) Oct 1 15:23:24 somehost sshd[18603]: User child is on pid 18610 -- Eldon Koyle -- Men often believe -- or pretend -- that the "Law" is something sacred, or at least a science -- an unfounded assumption very convenient to governments. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev Ce message et les pi?ces jointes sont confidentiels et r?serv?s ? l'usage exclusif de ses destinataires. Il peut ?galement ?tre prot?g? par le secret professionnel. Si vous recevez ce message par erreur, merci d'en avertir imm?diatement l'exp?diteur et de le d?truire. L'int?grit? du message ne pouvant ?tre assur?e sur Internet, la responsabilit? de Worldline ne pourra ?tre recherch?e quant au contenu de ce message. Bien que les meilleurs efforts soient faits pour maintenir cette transmission exempte de tout virus, l'exp?diteur ne donne aucune garantie ? cet ?gard et sa responsabilit? ne saurait ?tre recherch?e pour tout dommage r?sultant d'un virus transmis. This e-mail and the documents attached are confidential and intended solely for the addressee; it may also be privileged. If you receive this e-mail in error, please notify the sender immediately and destroy it. As its integrity cannot be secured on the Internet, the Worldline liability cannot be triggered for the message content. Although the sender endeavours to maintain a computer virus-free network, the sender does not warrant that this transmission is virus-free and will not be liable for any damages resulting from any virus transmitted. From dtucker at zip.com.au Fri Oct 4 00:59:03 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 4 Oct 2013 00:59:03 +1000 Subject: ssh-keygen DSA keys longer than 1024 bit In-Reply-To: References: Message-ID: <20131003145903.GA8769@gate.dtucker.net> On Thu, Oct 03, 2013 at 01:53:37PM +0300, Silviu Vlasceanu wrote: > Hi, > > Why is there still a limit on the length of a DSA key generated by > ssh-keygen? I mean that ssh-keygen only expects 1024 as key length, or > fails. Here is the code excerpt that enforces the limitation: > > if (type == KEY_DSA && *bitsp != 1024) > fatal("DSA keys must be 1024 bits"); > > Commenting these two lines allows the generation of, say, 2048 bit DSA keys > that work just fine with sshd. > > The only reason that I could previously find is that 1024 is imposed by > FIPS 186-2, but the current FIPS 186-3 allows for larger DSA keys. FIPS 186-3 also specifies which hash algorithms are permitted for those larger DSA key lengths (section 4.2). You might want to compare those with the hash (note: singular) specified by RFC 4253. > In light of the NIST SP800-131A guide that recommends 2048 as a minimum for > DSA key length, can anyone please explain me why the limitation still > exists in current openssh (6.3p1)? Is there a legal constraint? It's specification constraint. The intersection of what's permitted by FIPS 186-3 and RFC 4253 is DSA keys of exactly 1024 bits (which is coincidentally what ssh-keygen currently does). For further information see https://bugzilla.mindrot.org/show_bug.cgi?id=1647 -- 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 phil at hands.com Sun Oct 6 12:24:49 2013 From: phil at hands.com (Philip Hands) Date: Sun, 06 Oct 2013 02:24:49 +0100 Subject: PermitRootLogin=without-password as default Message-ID: <87mwmni42m.fsf@poker.hands.com> Hi, Ever since 'without-password' became an option, I've thought it would make a better default (and I actually used to patch it that way when I was the Debian Maintainer. My successors think that it's more important to minimise the size of the patch, which is also a reasonable point). The thing that prompted me to finally mention this here, is this story: http://bsdly.blogspot.ca/2013/10/the-hail-mary-cloud-and-lessons-learned.html and the unsurprising fact that the most popular account to guess is 'root', as seen here: http://home.nuug.no/~peter/hailmary2013/2008nov19/slowbrutes.data/massage/hail-mary-users-by-frequency.txt I imagine that this issue seems a little irrelevant on this list, as we're all perfectly capable of setting whatever value we want in the sshd_config, but that's not the point. The point is that the default set here is then inherited by the maintainers of the packages for various OSs, and then offered to users as the default value. Some of those users are not very competent, and will have chosen worthless passwords when setting up the system, and are not necessarily aware of quite what they are doing when installing sshd. For example, I can imagine someone being told that they can improve the security of their server if they switch from using ftp to sftp for uploads and not realising that the useless root password is going to be placed in the firing line for these attacks if they follow that advice. I don't know if the best route is to actually change the default in the binary, or perhaps to supply the default sshd_config with the setting in place, or even just to strongly recommend that distributions ensure that 'without-password' is the setting that new installs get by default unless the user requests otherwise. It is of course important that any change avoids the risk of locking people out of systems when they upgrade them via an ssh connection. It probably seems to many here that this is a problem that the distributions need to handle, and I'd mostly agree with that, but since the distributions look here for guidance I's suggest that any change needs to come from the top. Thoughts? Cheers, Phil. P.S. This could have been a bug report, and I'll happily submit a bug if there's a consensus about this, but I know that people have held differing views about this, and I didn't want to clog the bug tracker with a massive argument -- I hope we can avoid that on the mailing list too :-) -- |)| Philip Hands [+44 (0)20 8530 9560] http://www.hands.com/ |-| HANDS.COM Ltd. http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From bryan-lists at shatow.net Mon Oct 7 05:02:02 2013 From: bryan-lists at shatow.net (Bryan Drewery) Date: Sun, 06 Oct 2013 13:02:02 -0500 Subject: PermitRootLogin=without-password as default In-Reply-To: <87mwmni42m.fsf@poker.hands.com> References: <87mwmni42m.fsf@poker.hands.com> Message-ID: <5251A59A.2060401@shatow.net> On 10/5/2013 8:24 PM, Philip Hands wrote: > Hi, > > Ever since 'without-password' became an option, I've thought it would > make a better default (and I actually used to patch it that way when I > was the Debian Maintainer. My successors think that it's more important > to minimise the size of the patch, which is also a reasonable point). > > The thing that prompted me to finally mention this here, is this story: > > http://bsdly.blogspot.ca/2013/10/the-hail-mary-cloud-and-lessons-learned.html > > and the unsurprising fact that the most popular account to guess is > 'root', as seen here: > > http://home.nuug.no/~peter/hailmary2013/2008nov19/slowbrutes.data/massage/hail-mary-users-by-frequency.txt > > I imagine that this issue seems a little irrelevant on this list, as > we're all perfectly capable of setting whatever value we want in the > sshd_config, but that's not the point. > > The point is that the default set here is then inherited by the > maintainers of the packages for various OSs, and then offered to users as > the default value. > > Some of those users are not very competent, and will have chosen > worthless passwords when setting up the system, and are not necessarily > aware of quite what they are doing when installing sshd. > > For example, I can imagine someone being told that they can improve the > security of their server if they switch from using ftp to sftp for > uploads and not realising that the useless root password is going to be > placed in the firing line for these attacks if they follow that advice. > > I don't know if the best route is to actually change the default in the > binary, or perhaps to supply the default sshd_config with the setting in > place, or even just to strongly recommend that distributions ensure that > 'without-password' is the setting that new installs get by default > unless the user requests otherwise. > > It is of course important that any change avoids the risk of locking > people out of systems when they upgrade them via an ssh connection. > > It probably seems to many here that this is a problem that the > distributions need to handle, and I'd mostly agree with that, but since > the distributions look here for guidance I's suggest that any change > needs to come from the top. > > Thoughts? PermitRootLogin Yes is very much not secure by default. I run my systems as 'without-password' as well. That or 'No' would be a much more sane default IMHO. > > Cheers, Phil. > > P.S. This could have been a bug report, and I'll happily submit a bug if > there's a consensus about this, but I know that people have held > differing views about this, and I didn't want to clog the bug tracker > with a massive argument -- I hope we can avoid that on the mailing list > too :-) > -- Regards, Bryan Drewery bdrewery at freenode/EFNet From mittspamkonto at gmail.com Tue Oct 8 01:48:11 2013 From: mittspamkonto at gmail.com (Alexander T) Date: Mon, 7 Oct 2013 16:48:11 +0200 Subject: Feature request: FQDN Host match Message-ID: Hello! I'm hoping that Gmail won't HTML format this mail so that I'll get flamed :) Anyway, my question relates to ssh_config. The problem I find is that the Host pattern is only applied to the argument given on the command line, as outlined in the man page: "The host is the hostname argument given on the command line (i.e. the name is not converted to a canonicalized host name before matching)." I find this problematic, since I have resolv.conf-entries listing certain search domains, like: search my.very.long.subdomain.at.example.com This shortens the amount of typing I have to do when connecting to boxes in this subdomain, like 'ssh mybox' instead of 'ssh mybox.my.very.long.subdomain.at.example.com' BUT this becomes problematic when combined with .ssh/config, where I would like to specify something like Host *.subdomain.at.example.com User notme This since the fully qualified domain name is not used when matching Host directives, and I'm only saying 'ssh mybox', so the rule will never match. So my question is whether there is some specific reason why FQDN isn't used when matching Host-entries. And if not, would you consider a patch containing this change? Best regards, Alexander T From peter at stuge.se Tue Oct 8 02:41:36 2013 From: peter at stuge.se (Peter Stuge) Date: Mon, 7 Oct 2013 17:41:36 +0200 Subject: Feature request: FQDN Host match In-Reply-To: References: Message-ID: <20131007154136.8351.qmail@stuge.se> Alexander T wrote: > my question is whether there is some specific reason why FQDN isn't > used when matching Host-entries. Do you trust DNS? //Peter From mstone at mathom.us Tue Oct 8 04:23:03 2013 From: mstone at mathom.us (Michael Stone) Date: Mon, 7 Oct 2013 13:23:03 -0400 Subject: Feature request: FQDN Host match In-Reply-To: References: Message-ID: On Mon, Oct 07, 2013 at 04:48:11PM +0200, Alexander T wrote: >This since the fully qualified domain name is not used when matching >Host directives, and I'm only saying 'ssh mybox', so the rule will >never match. > >So my question is whether there is some specific reason why FQDN isn't >used when matching Host-entries. 1) ssh doesn't necessarily know what the resolver will end up resolving (it can't guess what the FQDN will be, it's just passing the string) 2) it would break things like Host nonexistentname HostName existingname.example.com Mike Stone From djm at mindrot.org Tue Oct 8 10:48:09 2013 From: djm at mindrot.org (Damien Miller) Date: Tue, 8 Oct 2013 10:48:09 +1100 (EST) Subject: Feature request: FQDN Host match In-Reply-To: References: Message-ID: On Mon, 7 Oct 2013, Alexander T wrote: > Hello! > > I'm hoping that Gmail won't HTML format this mail so that I'll get flamed :) > > Anyway, my question relates to ssh_config. The problem I find is that > the Host pattern is only applied to the argument given on the command > line, as outlined in the man page: > > "The host is the hostname argument given on the command line (i.e. the > name is not converted to a canonicalized host name before matching)." > > I find this problematic, since I have resolv.conf-entries listing > certain search domains, like: > > search my.very.long.subdomain.at.example.com The problems are: 1) The resolver doesn't offer a way to figure out what the fully-qualified name is. Some platforms do, via AI_FQDN - but it isn't widely available (Windows and OpenBSD only AFAIK) 2) Even if we could get the name, then we couldn't trust it for anything configured via DHCP anyway. The only solution I've thought of is to add explicit hostname canonicalisation options that allow the user to define their own optional DNS search paths in OpenSSH itself. Here's the patch and explanation: > This implements explicit client-side hostname canonicalisation. The idea > is to make host certificates usable for common use - the problem at the > moment is while host certificates work with fully-qualified names, users > (quite legitimately) like to type things like "ssh cvs" and the client > has no good way to figure out how to convert "cvs" to the fully-qualified > name that the server's certificate will offer. > > A similar problem exists with plain host keys, but users just usually > accept all the synonyms for the hosts that they refer to by unqualified > names. Some (like me) use HostKeyAlias to manually work around it, but > it's a kludge. > > This adds a few new options to allow a client to explicitly convert an > unqualified (or underqualified) hostname into a fully-qualified one: > > CanonicaliseHostname => turns on/off the canonicalisation > CanonicalDomains => specifies suffixes appended to qualify a bare name > CanonicaliseMaxDots => specifies how to tell if a name is underqualified > CanonicaliseFallbackLocal => if 'no', error if canonicalisation failed > CanonicalisePermittedCNAMEs => specifies rules for when to follow CNAMEs > > We can't use the system resolver for two reasons: first, the facilities > that we need aren't standard. AI_FQDN offers most of what we need, but > isn't compatible with AI_CANONNAME. Second, we can't trust the resolver's > configuration in dhcpful environments - a rogue server could return an > attacker-controlled search list. I wrote it mostly to make host certificates work better, but it works for regular hostnames too. Warning: patch is only lightly tested. Index: canohost.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/canohost.c,v retrieving revision 1.67 diff -u -p -r1.67 canohost.c --- canohost.c 17 May 2013 00:13:13 -0000 1.67 +++ canohost.c 12 Sep 2013 11:07:09 -0000 @@ -45,7 +45,6 @@ static char * get_remote_hostname(int sock, int use_dns) { struct sockaddr_storage from; - int i; socklen_t fromlen; struct addrinfo hints, *ai, *aitop; char name[NI_MAXHOST], ntop[NI_MAXHOST], ntop2[NI_MAXHOST]; @@ -91,13 +90,9 @@ get_remote_hostname(int sock, int use_dn return xstrdup(ntop); } - /* - * Convert it to all lowercase (which is expected by the rest - * of this software). - */ - for (i = 0; name[i]; i++) - if (isupper(name[i])) - name[i] = (char)tolower(name[i]); + /* Names are stores in lowercase. */ + lowercase(name); + /* * Map it back to an IP address and check that the given * address actually is an address of this host. This is Index: misc.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/misc.c,v retrieving revision 1.91 diff -u -p -r1.91 misc.c --- misc.c 12 Jul 2013 00:43:50 -0000 1.91 +++ misc.c 12 Sep 2013 11:07:09 -0000 @@ -35,6 +35,7 @@ #include #include +#include #include #include #include @@ -987,3 +988,11 @@ iptos2str(int iptos) snprintf(iptos_str, sizeof iptos_str, "0x%02x", iptos); return iptos_str; } + +void +lowercase(char *s) +{ + for (; *s; s++) + *s = tolower((u_char)*s); +} + Index: misc.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/misc.h,v retrieving revision 1.49 diff -u -p -r1.49 misc.h --- misc.h 1 Jun 2013 13:15:52 -0000 1.49 +++ misc.h 12 Sep 2013 11:07:09 -0000 @@ -36,6 +36,7 @@ void sanitise_stdfd(void); void ms_subtract_diff(struct timeval *, int *); void ms_to_timeval(struct timeval *, int); time_t monotime(void); +void lowercase(char *s); struct passwd *pwcopy(struct passwd *); const char *ssh_gai_strerror(int); Index: readconf.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/readconf.c,v retrieving revision 1.205 diff -u -p -r1.205 readconf.c --- readconf.c 20 Aug 2013 00:11:37 -0000 1.205 +++ readconf.c 12 Sep 2013 11:07:10 -0000 @@ -133,6 +133,8 @@ typedef enum { oTunnel, oTunnelDevice, oLocalCommand, oPermitLocalCommand, oVisualHostKey, oUseRoaming, oZeroKnowledgePasswordAuthentication, oKexAlgorithms, oIPQoS, oRequestTTY, oIgnoreUnknown, oProxyUseFdpass, + oCanonicalDomains, oCanonicaliseHostname, oCanonicaliseMaxDots, + oCanonicaliseFallbackLocal, oCanonicalisePermittedCNAMEs, oIgnoredUnknownOption, oDeprecated, oUnsupported } OpCodes; @@ -245,6 +247,11 @@ static struct { { "ipqos", oIPQoS }, { "requesttty", oRequestTTY }, { "proxyusefdpass", oProxyUseFdpass }, + { "canonicaldomains", oCanonicalDomains }, + { "canonicalisefallbacklocal", oCanonicaliseFallbackLocal }, + { "canonicalisehostname", oCanonicaliseHostname }, + { "canonicalisemaxdots", oCanonicaliseMaxDots }, + { "canonicalisepermittedcnames", oCanonicalisePermittedCNAMEs }, { "ignoreunknown", oIgnoreUnknown }, { NULL, oBadOption } @@ -343,6 +350,34 @@ add_identity_file(Options *options, cons options->identity_files[options->num_identity_files++] = path; } +/* Check and prepare a domain name: removes trailing '.' and lowercases */ +static void +valid_domain(char *name, const char *filename, int linenum) +{ + size_t i, l = strlen(name); + u_char c, last = '\0'; + + if (l == 0) + fatal("%s line %d: empty hostname suffix", filename, linenum); + if (!isalpha((u_char)name[0]) && !isdigit((u_char)name[0])) + fatal("%s line %d: hostname suffix \"%.100s\" " + "starts with invalid character", filename, linenum, name); + for (i = 0; i < l; i++) { + c = tolower((u_char)name[i]); + name[i] = (char)c; + if (last == '.' && c == '.') + fatal("%s line %d: hostname suffix \"%.100s\" contains " + "consecutive separators", filename, linenum, name); + if (c != '.' && c != '-' && !isalnum(c) && + c != '_') /* technically invalid, but common */ + fatal("%s line %d: hostname suffix \"%.100s\" contains " + "invalid characters", filename, linenum, name); + last = c; + } + if (name[l - 1] == '.') + name[l - 1] = '\0'; +} + /* * Returns the number of the token pointed to by cp or oBadOption. */ @@ -364,6 +399,69 @@ parse_token(const char *cp, const char * return oBadOption; } +/* Multistate option parsing */ +struct multistate { + char *key; + int value; +}; +static const struct multistate multistate_flag[] = { + { "true", 1 }, + { "false", 0 }, + { "yes", 1 }, + { "no", 0 }, + { NULL, -1 } +}; +static const struct multistate multistate_yesnoask[] = { + { "true", 1 }, + { "false", 0 }, + { "yes", 1 }, + { "no", 0 }, + { "ask", 2 }, + { NULL, -1 } +}; +static const struct multistate multistate_addressfamily[] = { + { "inet", AF_INET }, + { "inet6", AF_INET6 }, + { "any", AF_UNSPEC }, + { NULL, -1 } +}; +static const struct multistate multistate_controlmaster[] = { + { "true", SSHCTL_MASTER_YES }, + { "yes", SSHCTL_MASTER_YES }, + { "false", SSHCTL_MASTER_NO }, + { "no", SSHCTL_MASTER_NO }, + { "auto", SSHCTL_MASTER_AUTO }, + { "ask", SSHCTL_MASTER_ASK }, + { "autoask", SSHCTL_MASTER_AUTO_ASK }, + { NULL, -1 } +}; +static const struct multistate multistate_tunnel[] = { + { "ethernet", SSH_TUNMODE_ETHERNET }, + { "point-to-point", SSH_TUNMODE_POINTOPOINT }, + { "true", SSH_TUNMODE_DEFAULT }, + { "yes", SSH_TUNMODE_DEFAULT }, + { "false", SSH_TUNMODE_NO }, + { "no", SSH_TUNMODE_NO }, + { NULL, -1 } +}; +static const struct multistate multistate_requesttty[] = { + { "true", REQUEST_TTY_YES }, + { "yes", REQUEST_TTY_YES }, + { "false", REQUEST_TTY_NO }, + { "no", REQUEST_TTY_NO }, + { "force", REQUEST_TTY_FORCE }, + { "auto", REQUEST_TTY_AUTO }, + { NULL, -1 } +}; +static const struct multistate multistate_canonicalisehostname[] = { + { "true", SSH_CANONICALISE_YES }, + { "false", SSH_CANONICALISE_NO }, + { "yes", SSH_CANONICALISE_YES }, + { "no", SSH_CANONICALISE_NO }, + { "always", SSH_CANONICALISE_ALWAYS }, + { NULL, -1 } +}; + /* * Processes a single option line as used in the configuration files. This * only sets those values that have not already been set. @@ -383,6 +481,8 @@ process_config_line(Options *options, co long long val64; size_t len; Forward fwd; + const struct multistate *multistate_ptr; + struct allowed_cname *cname; /* Strip trailing whitespace */ for (len = strlen(line) - 1; len > 0; len--) { @@ -432,17 +532,23 @@ parse_time: case oForwardAgent: intptr = &options->forward_agent; -parse_flag: + parse_flag: + multistate_ptr = multistate_flag; + parse_multistate: arg = strdelim(&s); if (!arg || *arg == '\0') - fatal("%.200s line %d: Missing yes/no argument.", filename, linenum); - value = 0; /* To avoid compiler warning... */ - if (strcmp(arg, "yes") == 0 || strcmp(arg, "true") == 0) - value = 1; - else if (strcmp(arg, "no") == 0 || strcmp(arg, "false") == 0) - value = 0; - else - fatal("%.200s line %d: Bad yes/no argument.", filename, linenum); + fatal("%s line %d: missing argument.", + filename, linenum); + value = -1; + for (i = 0; multistate_ptr[i].key != NULL; i++) { + if (strcasecmp(arg, multistate_ptr[i].key) == 0) { + value = multistate_ptr[i].value; + break; + } + } + if (value == -1) + fatal("%s line %d: unsupported option \"%s\".", + filename, linenum, arg); if (*activep && *intptr == -1) *intptr = value; break; @@ -525,27 +631,13 @@ parse_flag: case oVerifyHostKeyDNS: intptr = &options->verify_host_key_dns; - goto parse_yesnoask; + multistate_ptr = multistate_yesnoask; + goto parse_multistate; case oStrictHostKeyChecking: intptr = &options->strict_host_key_checking; -parse_yesnoask: - arg = strdelim(&s); - if (!arg || *arg == '\0') - fatal("%.200s line %d: Missing yes/no/ask argument.", - filename, linenum); - value = 0; /* To avoid compiler warning... */ - if (strcmp(arg, "yes") == 0 || strcmp(arg, "true") == 0) - value = 1; - else if (strcmp(arg, "no") == 0 || strcmp(arg, "false") == 0) - value = 0; - else if (strcmp(arg, "ask") == 0) - value = 2; - else - fatal("%.200s line %d: Bad yes/no/ask argument.", filename, linenum); - if (*activep && *intptr == -1) - *intptr = value; - break; + multistate_ptr = multistate_yesnoask; + goto parse_multistate; case oCompression: intptr = &options->compression; @@ -871,22 +963,9 @@ parse_int: break; case oAddressFamily: - arg = strdelim(&s); - if (!arg || *arg == '\0') - fatal("%s line %d: missing address family.", - filename, linenum); intptr = &options->address_family; - if (strcasecmp(arg, "inet") == 0) - value = AF_INET; - else if (strcasecmp(arg, "inet6") == 0) - value = AF_INET6; - else if (strcasecmp(arg, "any") == 0) - value = AF_UNSPEC; - else - fatal("Unsupported AddressFamily \"%s\"", arg); - if (*activep && *intptr == -1) - *intptr = value; - break; + multistate_ptr = multistate_addressfamily; + goto parse_multistate; case oEnableSSHKeysign: intptr = &options->enable_ssh_keysign; @@ -925,27 +1004,8 @@ parse_int: case oControlMaster: intptr = &options->control_master; - arg = strdelim(&s); - if (!arg || *arg == '\0') - fatal("%.200s line %d: Missing ControlMaster argument.", - filename, linenum); - value = 0; /* To avoid compiler warning... */ - if (strcmp(arg, "yes") == 0 || strcmp(arg, "true") == 0) - value = SSHCTL_MASTER_YES; - else if (strcmp(arg, "no") == 0 || strcmp(arg, "false") == 0) - value = SSHCTL_MASTER_NO; - else if (strcmp(arg, "auto") == 0) - value = SSHCTL_MASTER_AUTO; - else if (strcmp(arg, "ask") == 0) - value = SSHCTL_MASTER_ASK; - else if (strcmp(arg, "autoask") == 0) - value = SSHCTL_MASTER_AUTO_ASK; - else - fatal("%.200s line %d: Bad ControlMaster argument.", - filename, linenum); - if (*activep && *intptr == -1) - *intptr = value; - break; + multistate_ptr = multistate_controlmaster; + goto parse_multistate; case oControlPersist: /* no/false/yes/true, or a time spec */ @@ -977,25 +1037,8 @@ parse_int: case oTunnel: intptr = &options->tun_open; - arg = strdelim(&s); - if (!arg || *arg == '\0') - fatal("%s line %d: Missing yes/point-to-point/" - "ethernet/no argument.", filename, linenum); - value = 0; /* silence compiler */ - if (strcasecmp(arg, "ethernet") == 0) - value = SSH_TUNMODE_ETHERNET; - else if (strcasecmp(arg, "point-to-point") == 0) - value = SSH_TUNMODE_POINTOPOINT; - else if (strcasecmp(arg, "yes") == 0) - value = SSH_TUNMODE_DEFAULT; - else if (strcasecmp(arg, "no") == 0) - value = SSH_TUNMODE_NO; - else - fatal("%s line %d: Bad yes/point-to-point/ethernet/" - "no argument: %s", filename, linenum, arg); - if (*activep) - *intptr = value; - break; + multistate_ptr = multistate_tunnel; + goto parse_multistate; case oTunnelDevice: arg = strdelim(&s); @@ -1044,24 +1087,9 @@ parse_int: goto parse_flag; case oRequestTTY: - arg = strdelim(&s); - if (!arg || *arg == '\0') - fatal("%s line %d: missing argument.", - filename, linenum); intptr = &options->request_tty; - if (strcasecmp(arg, "yes") == 0) - value = REQUEST_TTY_YES; - else if (strcasecmp(arg, "no") == 0) - value = REQUEST_TTY_NO; - else if (strcasecmp(arg, "force") == 0) - value = REQUEST_TTY_FORCE; - else if (strcasecmp(arg, "auto") == 0) - value = REQUEST_TTY_AUTO; - else - fatal("Unsupported RequestTTY \"%s\"", arg); - if (*activep && *intptr == -1) - *intptr = value; - break; + multistate_ptr = multistate_requesttty; + goto parse_multistate; case oIgnoreUnknown: charptr = &options->ignored_unknown; @@ -1071,6 +1099,62 @@ parse_int: intptr = &options->proxy_use_fdpass; goto parse_flag; + case oCanonicalDomains: + value = options->num_canonical_domains != 0; + while ((arg = strdelim(&s)) != NULL && *arg != '\0') { + valid_domain(arg, filename, linenum); + if (!*activep || value) + continue; + if (options->num_canonical_domains >= MAX_CANON_DOMAINS) + fatal("%s line %d: too many hostname suffixes.", + filename, linenum); + options->canonical_domains[ + options->num_canonical_domains++] = xstrdup(arg); + } + break; + + case oCanonicalisePermittedCNAMEs: + value = options->num_permitted_cnames != 0; + while ((arg = strdelim(&s)) != NULL && *arg != '\0') { + /* Either '*' for everything or 'list:list' */ + if (strcmp(arg, "*") == 0) + arg2 = arg; + else { + lowercase(arg); + if ((arg2 = strchr(arg, ':')) == NULL || + arg2[1] == '\0') { + fatal("%s line %d: " + "Invalid permitted CNAME \"%s\"", + filename, linenum, arg); + } + *arg2 = '\0'; + arg2++; + } + if (!*activep || value) + continue; + if (options->num_permitted_cnames >= MAX_CANON_DOMAINS) + fatal("%s line %d: too many permitted CNAMEs.", + filename, linenum); + cname = options->permitted_cnames + + options->num_permitted_cnames++; + cname->source_list = xstrdup(arg); + cname->target_list = xstrdup(arg2); + } + break; + + case oCanonicaliseHostname: + intptr = &options->canonicalise_hostname; + multistate_ptr = multistate_canonicalisehostname; + goto parse_multistate; + + case oCanonicaliseMaxDots: + intptr = &options->canonicalise_max_dots; + goto parse_int; + + case oCanonicaliseFallbackLocal: + intptr = &options->canonicalise_fallback_local; + goto parse_flag; + case oDeprecated: debug("%s line %d: Deprecated option \"%s\"", filename, linenum, keyword); @@ -1234,6 +1318,11 @@ initialize_options(Options * options) options->request_tty = -1; options->proxy_use_fdpass = -1; options->ignored_unknown = NULL; + options->num_canonical_domains = 0; + options->num_permitted_cnames = 0; + options->canonicalise_max_dots = -1; + options->canonicalise_fallback_local = -1; + options->canonicalise_hostname = -1; } /* @@ -1385,8 +1474,22 @@ fill_default_options(Options * options) options->request_tty = REQUEST_TTY_AUTO; if (options->proxy_use_fdpass == -1) options->proxy_use_fdpass = 0; - /* options->local_command should not be set by default */ - /* options->proxy_command should not be set by default */ + if (options->canonicalise_max_dots == -1) + options->canonicalise_max_dots = 1; + if (options->canonicalise_fallback_local == -1) + options->canonicalise_fallback_local = 1; + if (options->canonicalise_hostname == -1) + options->canonicalise_hostname = SSH_CANONICALISE_NO; +#define CLEAR_ON_NONE(v) \ + do { \ + if (v != NULL && strcasecmp(v, "none") == 0) { \ + free(v); \ + v = NULL; \ + } \ + } while(0) + CLEAR_ON_NONE(options->local_command); + CLEAR_ON_NONE(options->proxy_command); + CLEAR_ON_NONE(options->control_path); /* options->user will be set in the main program if appropriate */ /* options->hostname will be set in the main program if appropriate */ /* options->host_key_alias should not be set by default */ Index: readconf.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/readconf.h,v retrieving revision 1.96 diff -u -p -r1.96 readconf.h --- readconf.h 20 Aug 2013 00:11:38 -0000 1.96 +++ readconf.h 12 Sep 2013 11:07:10 -0000 @@ -29,7 +29,13 @@ typedef struct { /* Data structure for representing option data. */ #define MAX_SEND_ENV 256 -#define SSH_MAX_HOSTS_FILES 256 +#define SSH_MAX_HOSTS_FILES 32 +#define MAX_CANON_DOMAINS 32 + +struct allowed_cname { + char *source_list; + char *target_list; +}; typedef struct { int forward_agent; /* Forward authentication agent. */ @@ -140,8 +146,20 @@ typedef struct { int proxy_use_fdpass; + int num_canonical_domains; + char *canonical_domains[MAX_CANON_DOMAINS]; + int canonicalise_hostname; + int canonicalise_max_dots; + int canonicalise_fallback_local; + int num_permitted_cnames; + struct allowed_cname permitted_cnames[MAX_CANON_DOMAINS]; + char *ignored_unknown; /* Pattern list of unknown tokens to ignore */ } Options; + +#define SSH_CANONICALISE_NO 0 +#define SSH_CANONICALISE_YES 1 +#define SSH_CANONICALISE_ALWAYS 2 #define SSHCTL_MASTER_NO 0 #define SSHCTL_MASTER_YES 1 Index: roaming_client.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/roaming_client.c,v retrieving revision 1.5 diff -u -p -r1.5 roaming_client.c --- roaming_client.c 17 May 2013 00:13:14 -0000 1.5 +++ roaming_client.c 12 Sep 2013 11:07:10 -0000 @@ -255,10 +255,10 @@ wait_for_roaming_reconnect(void) if (c != '\n' && c != '\r') continue; - if (ssh_connect(host, &hostaddr, options.port, + if (ssh_connect(host, NULL, &hostaddr, options.port, options.address_family, 1, &timeout_ms, - options.tcp_keep_alive, options.use_privileged_port, - options.proxy_command) == 0 && roaming_resume() == 0) { + options.tcp_keep_alive, options.use_privileged_port) == 0 && + roaming_resume() == 0) { packet_restore_state(); reenter_guard = 0; fprintf(stderr, "[connection resumed]\n"); Index: ssh.1 =================================================================== RCS file: /cvs/src/usr.bin/ssh/ssh.1,v retrieving revision 1.336 diff -u -p -r1.336 ssh.1 --- ssh.1 20 Aug 2013 06:56:07 -0000 1.336 +++ ssh.1 12 Sep 2013 11:07:10 -0000 @@ -417,6 +417,11 @@ For full details of the options listed b .It AddressFamily .It BatchMode .It BindAddress +.It CanonicalDomains +.It CanonicaliseFallbackLocal +.It CanonicaliseHostname +.It CanonicaliseMaxDots +.It CanonicalisePermittedCNAMEs .It ChallengeResponseAuthentication .It CheckHostIP .It Cipher Index: ssh.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/ssh.c,v retrieving revision 1.381 diff -u -p -r1.381 ssh.c --- ssh.c 25 Jul 2013 00:29:10 -0000 1.381 +++ ssh.c 12 Sep 2013 11:07:10 -0000 @@ -218,6 +218,134 @@ tilde_expand_paths(char **paths, u_int n } } +static struct addrinfo * +resolve_host(const char *name, u_int port, int logerr, char *cname, size_t clen) +{ + char strport[NI_MAXSERV]; + struct addrinfo hints, *res; + int gaierr, loglevel = SYSLOG_LEVEL_DEBUG1; + + snprintf(strport, sizeof strport, "%u", port); + bzero(&hints, sizeof(hints)); + hints.ai_family = options.address_family; + hints.ai_socktype = SOCK_STREAM; + if (cname != NULL) + hints.ai_flags = AI_CANONNAME; + if ((gaierr = getaddrinfo(name, strport, &hints, &res)) != 0) { + if (logerr || (gaierr != EAI_NONAME && gaierr != EAI_NODATA)) + loglevel = SYSLOG_LEVEL_ERROR; + do_log2(loglevel, "%s: Could not resolve hostname %.100s: %s", + __progname, name, ssh_gai_strerror(gaierr)); + return NULL; + } + if (cname != NULL && res->ai_canonname != NULL) { + if (strlcpy(cname, res->ai_canonname, clen) >= clen) { + error("%s: host \"%s\" cname \"%s\" too long (max %lu)", + __func__, name, res->ai_canonname, (u_long)clen); + if (clen > 0) + *cname = '\0'; + } + } + return res; +} + +/* + * Check whether the cname is a permitted replacement for the hostname + * and perform the replacement if it is. + */ +static int +check_follow_cname(char **namep, const char *cname) +{ + int i; + struct allowed_cname *rule; + + if (*cname == '\0' || options.num_permitted_cnames == 0 || + strcmp(*namep, cname) == 0) + return 0; + if (options.canonicalise_hostname == SSH_CANONICALISE_NO) + return 0; + /* + * Don't attempt to canonicalise names that will be interpreted by + * a proxy unless the user specifically requests so. + */ + if (options.proxy_command != NULL && + options.canonicalise_hostname != SSH_CANONICALISE_ALWAYS) + return 0; + debug3("%s: check \"%s\" CNAME \"%s\"", __func__, *namep, cname); + for (i = 0; i < options.num_permitted_cnames; i++) { + rule = options.permitted_cnames + i; + if (match_pattern_list(*namep, rule->source_list, + strlen(rule->source_list), 1) != 1 || + match_pattern_list(cname, rule->target_list, + strlen(rule->target_list), 1) != 1) + continue; + verbose("Canonicalised DNS aliased hostname " + "\"%s\" => \"%s\"", *namep, cname); + free(*namep); + *namep = xstrdup(cname); + return 1; + } + return 0; +} + +/* + * Attempt to resolve the supplied hostname after applying the user's + * canonicalisation rules. Returns the address list for the host or NULL + * if no name was found after canonicalisation. + */ +static struct addrinfo * +resolve_canonicalise(char **hostp, u_int port) +{ + int i, ndots; + char *cp, *fullhost, cname_target[NI_MAXHOST]; + struct addrinfo *addrs; + + if (options.canonicalise_hostname == SSH_CANONICALISE_NO) + return NULL; + /* + * Don't attempt to canonicalise names that will be interpreted by + * a proxy unless the user specifically requests so. + */ + if (options.proxy_command != NULL && + options.canonicalise_hostname != SSH_CANONICALISE_ALWAYS) + return NULL; + /* Don't apply canonicalisation to sufficiently-qualified hostnames */ + ndots = 0; + for (cp = *hostp; *cp != '\0'; cp++) { + if (*cp == '.') + ndots++; + } + if (ndots > options.canonicalise_max_dots) { + debug3("%s: not canonicalising hostname \"%s\" (max dots %d)", + __func__, *hostp, options.canonicalise_max_dots); + return NULL; + } + /* Attempt each supplied suffix */ + for (i = 0; i < options.num_canonical_domains; i++) { + *cname_target = '\0'; + xasprintf(&fullhost, "%s.%s.", *hostp, + options.canonical_domains[i]); + if ((addrs = resolve_host(fullhost, options.port, 0, + cname_target, sizeof(cname_target))) == NULL) { + free(fullhost); + continue; + } + /* Remove trailing '.' */ + fullhost[strlen(fullhost) - 1] = '\0'; + /* Follow CNAME if requested */ + if (!check_follow_cname(&fullhost, cname_target)) { + debug("Canonicalised hostname \"%s\" => \"%s\"", + *hostp, fullhost); + } + free(*hostp); + *hostp = fullhost; + return addrs; + } + if (!options.canonicalise_fallback_local) + fatal("%s: Could not resolve host \"%s\"", __progname, host); + return NULL; +} + /* * Main program for the ssh client. */ @@ -227,6 +355,7 @@ main(int ac, char **av) int i, r, opt, exit_status, use_syslog; char *p, *cp, *line, *argv0, buf[MAXPATHLEN], *host_arg, *logfile; char thishost[NI_MAXHOST], shorthost[NI_MAXHOST], portstr[NI_MAXSERV]; + char cname[NI_MAXHOST]; struct stat st; struct passwd *pw; int dummy, timeout_ms; @@ -234,6 +363,7 @@ main(int ac, char **av) extern char *optarg; struct servent *sp; Forward fwd; + struct addrinfo *addrs = NULL; /* Ensure that fds 0, 1 and 2 are open or directed to /dev/null */ sanitise_stdfd(); @@ -604,9 +734,9 @@ main(int ac, char **av) usage(); options.user = p; *cp = '\0'; - host = ++cp; + host = xstrdup(++cp); } else - host = *av; + host = xstrdup(*av); if (ac > 1) { optind = optreset = 1; goto again; @@ -618,6 +748,9 @@ main(int ac, char **av) if (!host) usage(); + lowercase(host); + host_arg = xstrdup(host); + OpenSSL_add_all_algorithms(); ERR_load_crypto_strings(); @@ -694,6 +827,14 @@ main(int ac, char **av) channel_set_af(options.address_family); + /* Tidy and check options */ + if (options.host_key_alias != NULL) + lowercase(options.host_key_alias); + if (options.proxy_command != NULL && + strcmp(options.proxy_command, "-") == 0 && + options.proxy_use_fdpass) + fatal("ProxyCommand=- and ProxyUseFDPass are incompatible"); + /* reinit */ log_init(argv0, options.log_level, SYSLOG_FACILITY_USER, !use_syslog); @@ -727,10 +868,26 @@ main(int ac, char **av) } /* preserve host name given on command line for %n expansion */ - host_arg = host; if (options.hostname != NULL) { - host = percent_expand(options.hostname, + cp = percent_expand(options.hostname, "h", host, (char *)NULL); + free(host); + host = cp; + } + + /* If canonicalisation requested then try to apply it */ + if (options.canonicalise_hostname != SSH_CANONICALISE_NO) + addrs = resolve_canonicalise(&host, options.port); + /* + * If canonicalisation not requested, or if it failed then try to + * resolve the bare hostname name using the system resolver's usual + * search rules. + */ + if (addrs == NULL) { + if ((addrs = resolve_host(host, options.port, 1, + cname, sizeof(cname))) == NULL) + cleanup_exit(255); /* resolve_host logs the error */ + check_follow_cname(&host, cname); } if (gethostname(thishost, sizeof(thishost)) == -1) @@ -750,24 +907,6 @@ main(int ac, char **av) free(cp); } - /* force lowercase for hostkey matching */ - if (options.host_key_alias != NULL) { - for (p = options.host_key_alias; *p; p++) - if (isupper(*p)) - *p = (char)tolower(*p); - } - - if (options.proxy_command != NULL && - strcmp(options.proxy_command, "none") == 0) { - free(options.proxy_command); - options.proxy_command = NULL; - } - if (options.control_path != NULL && - strcmp(options.control_path, "none") == 0) { - free(options.control_path); - options.control_path = NULL; - } - if (options.control_path != NULL) { cp = tilde_expand_filename(options.control_path, original_real_uid); @@ -786,13 +925,16 @@ main(int ac, char **av) timeout_ms = options.connection_timeout * 1000; /* Open a connection to the remote host. */ - if (ssh_connect(host, &hostaddr, options.port, - options.address_family, options.connection_attempts, &timeout_ms, - options.tcp_keep_alive, - original_effective_uid == 0 && options.use_privileged_port, - options.proxy_command) != 0) + if (ssh_connect(host, addrs, &hostaddr, options.port, + options.address_family, options.connection_attempts, + &timeout_ms, options.tcp_keep_alive, + original_effective_uid == 0 && options.use_privileged_port) != 0) exit(255); + freeaddrinfo(addrs); + packet_set_timeout(options.server_alive_interval, + options.server_alive_count_max); + if (timeout_ms > 0) debug3("timeout: %d ms remain after connect", timeout_ms); @@ -1584,4 +1726,3 @@ main_sigchld_handler(int sig) signal(sig, main_sigchld_handler); errno = save_errno; } - Index: ssh_config.5 =================================================================== RCS file: /cvs/src/usr.bin/ssh/ssh_config.5,v retrieving revision 1.168 diff -u -p -r1.168 ssh_config.5 --- ssh_config.5 20 Aug 2013 06:56:07 -0000 1.168 +++ ssh_config.5 12 Sep 2013 11:07:11 -0000 @@ -152,6 +152,77 @@ Note that this option does not work if .Cm UsePrivilegedPort is set to .Dq yes . +.It Cm CanonicalDomains +when +.Cm CanonicaliseHostname +is enabled, this option specifies the list of domain suffixes in which to +search for the specified destination host. +.It Cm CanonicaliseFallbackLocal +specified whether to fail with an error when hostname canonicalisation fails. +The default of +.Dq no +will attempt to lookup the unqualified hostname using the system resolver's +search rules. +A value of +.Dq yes +will cause +.Xr ssh 1 +to fail instantly if +.Cm CanonicaliseHostname +is enabled and the target hostname cannot be found in any of the domains +specified by +.Cm CanonicalDomains . +.It Cm CanonicaliseHostname +controls whether explicit hostname canonicalisation is performed. +The default +.Dq no +is not to perform any name rewriting and let the system resolver handle all +hostname lookups. +If set to +.Dq yes +then, for connections that do not use a +.Cm ProxyCommand , +.Xr ssh 1 +will attempt to canonicalise the hostname specified on the command line +using the +.Cm CanonicalDomains +suffixes and +.Cm CanonicalisePermittedCNAMEs +rules. +If +.Cm CanonicaliseHostname +is set to +.Dq always , +then canonicalisation is applied to proxied connections to. +.It Cm CanonicaliseMaxDots +specifies the maximum number of dot characters in a hostname name before +canonicalisation is disabled. +The default of +.Dq 1 +allows a single dot (i.e. hostname.subdomain) +.It Cm CanonicalisePermittedCNAMEs +specifies rules to determine whether CNAMEs should be followed when +canonicalising hostnames. +The rules consist of one or more arguments of +.Sm off +.Ar source_domain_list : Ar target_domain_list +.Sm on +where +.Ar source_domain_list +is a pattern-list of domains that are may follow CNAMEs in canonicalisation +and +.Ar target_domain_list +is a pattern-list of domains that they may resove to. +.Pp +For example, +.Dq *.a.example.com:*.b.example.com,*.c.example.com +will allow hostnames matching +.Dq *.a.example.com +to be canonicalised to names in the +.Dq *.b.example.com +or +.Dq *.c.example.com +domains. .It Cm ChallengeResponseAuthentication Specifies whether to use challenge-response authentication. The argument to this keyword must be Index: sshconnect.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/sshconnect.c,v retrieving revision 1.239 diff -u -p -r1.239 sshconnect.c --- sshconnect.c 20 Aug 2013 00:11:38 -0000 1.239 +++ sshconnect.c 12 Sep 2013 11:07:11 -0000 @@ -76,7 +76,7 @@ expand_proxy_command(const char *proxy_c { char *tmp, *ret, strport[NI_MAXSERV]; - snprintf(strport, sizeof strport, "%hu", port); + snprintf(strport, sizeof strport, "%d", port); xasprintf(&tmp, "exec %s", proxy_command); ret = percent_expand(tmp, "h", host, "p", strport, "r", options.user, (char *)NULL); @@ -160,8 +160,6 @@ ssh_proxy_fdpass_connect(const char *hos /* Set the connection file descriptors. */ packet_set_connection(sock, sock); - packet_set_timeout(options.server_alive_interval, - options.server_alive_count_max); return 0; } @@ -177,16 +175,6 @@ ssh_proxy_connect(const char *host, u_sh pid_t pid; char *shell; - if (!strcmp(proxy_command, "-")) { - packet_set_connection(STDIN_FILENO, STDOUT_FILENO); - packet_set_timeout(options.server_alive_interval, - options.server_alive_count_max); - return 0; - } - - if (options.proxy_use_fdpass) - return ssh_proxy_fdpass_connect(host, port, proxy_command); - if ((shell = getenv("SHELL")) == NULL || *shell == '\0') shell = _PATH_BSHELL; @@ -248,8 +236,6 @@ ssh_proxy_connect(const char *host, u_sh /* Set the connection file descriptors. */ packet_set_connection(pout[0], pin[1]); - packet_set_timeout(options.server_alive_interval, - options.server_alive_count_max); /* Indicate OK return */ return 0; @@ -418,33 +404,18 @@ timeout_connect(int sockfd, const struct * and %p substituted for host and port, respectively) to use to contact * the daemon. */ -int -ssh_connect(const char *host, struct sockaddr_storage * hostaddr, - u_short port, int family, int connection_attempts, int *timeout_ms, - int want_keepalive, int needpriv, const char *proxy_command) +static int +ssh_connect_direct(const char *host, struct addrinfo *aitop, + struct sockaddr_storage *hostaddr, u_short port, int family, + int connection_attempts, int *timeout_ms, int want_keepalive, int needpriv) { - int gaierr; int on = 1; int sock = -1, attempt; char ntop[NI_MAXHOST], strport[NI_MAXSERV]; - struct addrinfo hints, *ai, *aitop; + struct addrinfo *ai; debug2("ssh_connect: needpriv %d", needpriv); - /* If a proxy command is given, connect using it. */ - if (proxy_command != NULL) - return ssh_proxy_connect(host, port, proxy_command); - - /* No proxy command. */ - - memset(&hints, 0, sizeof(hints)); - hints.ai_family = family; - hints.ai_socktype = SOCK_STREAM; - snprintf(strport, sizeof strport, "%u", port); - if ((gaierr = getaddrinfo(host, strport, &hints, &aitop)) != 0) - fatal("%s: Could not resolve hostname %.100s: %s", __progname, - host, ssh_gai_strerror(gaierr)); - for (attempt = 0; attempt < connection_attempts; attempt++) { if (attempt > 0) { /* Sleep a moment before retrying. */ @@ -456,7 +427,8 @@ ssh_connect(const char *host, struct soc * sequence until the connection succeeds. */ for (ai = aitop; ai; ai = ai->ai_next) { - if (ai->ai_family != AF_INET && ai->ai_family != AF_INET6) + if (ai->ai_family != AF_INET && + ai->ai_family != AF_INET6) continue; if (getnameinfo(ai->ai_addr, ai->ai_addrlen, ntop, sizeof(ntop), strport, sizeof(strport), @@ -489,8 +461,6 @@ ssh_connect(const char *host, struct soc break; /* Successful connection. */ } - freeaddrinfo(aitop); - /* Return failure if we didn't get a successful connection. */ if (sock == -1) { error("ssh: connect to host %s port %s: %s", @@ -508,12 +478,28 @@ ssh_connect(const char *host, struct soc /* Set the connection. */ packet_set_connection(sock, sock); - packet_set_timeout(options.server_alive_interval, - options.server_alive_count_max); return 0; } +int +ssh_connect(const char *host, struct addrinfo *addrs, + struct sockaddr_storage *hostaddr, u_short port, int family, + int connection_attempts, int *timeout_ms, int want_keepalive, int needpriv) +{ + if (options.proxy_command == NULL) { + return ssh_connect_direct(host, addrs, hostaddr, port, family, + connection_attempts, timeout_ms, want_keepalive, needpriv); + } else if (strcmp(options.proxy_command, "-") == 0) { + packet_set_connection(STDIN_FILENO, STDOUT_FILENO); + return 0; /* Always succeeds */ + } else if (options.proxy_use_fdpass) { + return ssh_proxy_fdpass_connect(host, port, + options.proxy_command); + } + return ssh_proxy_connect(host, port, options.proxy_command); +} + static void send_client_banner(int connection_out, int minor1) { @@ -1238,7 +1224,7 @@ void ssh_login(Sensitive *sensitive, const char *orighost, struct sockaddr *hostaddr, u_short port, struct passwd *pw, int timeout_ms) { - char *host, *cp; + char *host; char *server_user, *local_user; local_user = xstrdup(pw->pw_name); @@ -1246,9 +1232,7 @@ ssh_login(Sensitive *sensitive, const ch /* Convert the user-supplied hostname into all lowercase. */ host = xstrdup(orighost); - for (cp = host; *cp; cp++) - if (isupper(*cp)) - *cp = (char)tolower(*cp); + lowercase(host); /* Exchange protocol version identification strings with the server. */ ssh_exchange_identification(timeout_ms); Index: sshconnect.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/sshconnect.h,v retrieving revision 1.27 diff -u -p -r1.27 sshconnect.h --- sshconnect.h 29 Nov 2010 23:45:51 -0000 1.27 +++ sshconnect.h 12 Sep 2013 11:07:11 -0000 @@ -31,9 +31,9 @@ struct Sensitive { int external_keysign; }; -int -ssh_connect(const char *, struct sockaddr_storage *, u_short, int, int, - int *, int, int, const char *); +struct addrinfo; +int ssh_connect(const char *, struct addrinfo *, struct sockaddr_storage *, + u_short, int, int, int *, int, int); void ssh_kill_proxy_command(void); void ssh_login(Sensitive *, const char *, struct sockaddr *, u_short, From djm at mindrot.org Thu Oct 10 08:09:40 2013 From: djm at mindrot.org (Damien Miller) Date: Thu, 10 Oct 2013 08:09:40 +1100 (EST) Subject: Want to hack on OpenSSH? Want to get paid for it? Message-ID: Hi, Google has just announced that they will pay up to $3113.70 for proactive security patches to OpenSSH. https://www.google.com/about/appsecurity/patch-rewards/ For a patch to be eligible, it has to 1) improve OpenSSH's security and 2) actually ship in a release. If you want to work on a patch to improve some aspect of OpenSSH's security then please contact us first on this list, our bugtracker or the openssh at openssh.com list to make sure that what you are planning is likely to be accepted. -d From manish.jagtap at airtightnetworks.com Thu Oct 10 15:01:38 2013 From: manish.jagtap at airtightnetworks.com (Manish Jagtap) Date: Thu, 10 Oct 2013 09:31:38 +0530 Subject: FIPS 140-2 patch for openssh 6.3.p1 Message-ID: <525626a6.a459440a.7091.337a@mx.google.com> Hi, Is FIPS 140-2 patch for openssh 6.3.p1 available somewhere or do I have to make one using http://www.openssl.com/export/openssh/openssh-6.0p1.fips-revised.patch ? Regards, Manish From marquess at opensslfoundation.com Thu Oct 10 23:29:29 2013 From: marquess at opensslfoundation.com (Steve Marquess) Date: Thu, 10 Oct 2013 08:29:29 -0400 Subject: FIPS 140-2 patch for openssh 6.3.p1 In-Reply-To: <525626a6.a459440a.7091.337a@mx.google.com> References: <525626a6.a459440a.7091.337a@mx.google.com> Message-ID: <52569DA9.20900@opensslfoundation.com> On 10/10/2013 12:01 AM, Manish Jagtap wrote: > Hi, > > > > Is FIPS 140-2 patch for openssh 6.3.p1 available somewhere or do I have to > make one using > http://www.openssl.com/export/openssh/openssh-6.0p1.fips-revised.patch ? I think you'll need to refactor that yourself for 6.3p1, sorry. We get asked about that fairly frequently. That patch was developed at the request of some commercial clients, most recently for 6.0p1. If we ever update it we'll post the new version(s) too. If you do create a newer patch I'll be glad to post the result at the same location. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc From manish.jagtap at airtightnetworks.com Sat Oct 12 01:40:43 2013 From: manish.jagtap at airtightnetworks.com (Manish Jagtap) Date: Fri, 11 Oct 2013 20:10:43 +0530 Subject: FIPS 140-2 patch for openssh 6.3.p1 In-Reply-To: <52569DA9.20900@opensslfoundation.com> References: <525626a6.a459440a.7091.337a@mx.google.com> <52569DA9.20900@opensslfoundation.com> Message-ID: <52580def.a700420a.3855.1f30@mx.google.com> Sure. Will post in couple of days. Regards, Manish Jagtap -----Original Message----- From: openssh-unix-dev-bounces+manish.jagtap=airtightnetworks.com at mindrot.org [mailto:openssh-unix-dev-bounces+manish.jagtap=airtightnetworks.com at mindrot. org] On Behalf Of Steve Marquess Sent: Thursday, October 10, 2013 5:59 PM To: openssh-unix-dev at mindrot.org Subject: Re: FIPS 140-2 patch for openssh 6.3.p1 On 10/10/2013 12:01 AM, Manish Jagtap wrote: > Hi, > > > > Is FIPS 140-2 patch for openssh 6.3.p1 available somewhere or do I have to > make one using > http://www.openssl.com/export/openssh/openssh-6.0p1.fips-revised.patch ? I think you'll need to refactor that yourself for 6.3p1, sorry. We get asked about that fairly frequently. That patch was developed at the request of some commercial clients, most recently for 6.0p1. If we ever update it we'll post the new version(s) too. If you do create a newer patch I'll be glad to post the result at the same location. -Steve M. -- Steve Marquess OpenSSL Software Foundation, Inc. 1829 Mount Ephraim Road Adamstown, MD 21710 USA +1 877 673 6775 s/b +1 301 874 2571 direct marquess at opensslfoundation.com marquess at openssl.com gpg/pgp key: http://openssl.com/docs/0xCE69424E.asc _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From rosslagerwall at gmail.com Tue Oct 15 07:52:42 2013 From: rosslagerwall at gmail.com (Ross Lagerwall) Date: Mon, 14 Oct 2013 22:52:42 +0200 Subject: [PATCH-resend] Implement SSH2_FXF_APPEND Message-ID: <20131014205242.GA11651@hobo> Hi, I submitted this a few weeks ago but here it is again since I got no response. If there is somewhere else I should send this, please tell me. This patch implements SSH2_FXF_APPEND in the sftp server. It is a fairly trivial patch and applies against the proper OpenSSH and the Portable edition. I would argue that it is important for OpenSSH to implement SSH2_FXF_APPEND since it is in the spec and clients who expect it to work find that their files are overwritten rather than appended to. I opened a bug for it: https://bugzilla.mindrot.org/show_bug.cgi?id=2159 Some relevant links: http://marc.info/?l=openssh-unix-dev&m=138053388830753&w=2 http://marc.info/?l=openssh-unix-dev&m=123798287811788 http://marc.info/?l=openssh-unix-dev&m=111093206900604 https://bugzilla.gnome.org/show_bug.cgi?id=608910 Thanks -- Ross Lagerwall -------------- next part -------------- Index: sftp-server.c =================================================================== RCS file: /cvs/openssh/sftp-server.c,v retrieving revision 1.114 diff -u -p -r1.114 sftp-server.c --- sftp-server.c 1 Jun 2013 21:31:19 -0000 1.114 +++ sftp-server.c 30 Sep 2013 08:16:57 -0000 @@ -130,6 +130,8 @@ flags_from_portable(int pflags) } else if (pflags & SSH2_FXF_WRITE) { flags = O_WRONLY; } + if (pflags & SSH2_FXF_APPEND) + flags |= O_APPEND; if (pflags & SSH2_FXF_CREAT) flags |= O_CREAT; if (pflags & SSH2_FXF_TRUNC) @@ -156,6 +158,8 @@ string_from_portable(int pflags) PAPPEND("READ") if (pflags & SSH2_FXF_WRITE) PAPPEND("WRITE") + if (pflags & SSH2_FXF_APPEND) + PAPPEND("APPEND") if (pflags & SSH2_FXF_CREAT) PAPPEND("CREATE") if (pflags & SSH2_FXF_TRUNC) @@ -179,6 +183,7 @@ struct Handle { int use; DIR *dirp; int fd; + int flags; char *name; u_int64_t bytes_read, bytes_write; int next_unused; @@ -202,7 +207,7 @@ static void handle_unused(int i) } static int -handle_new(int use, const char *name, int fd, DIR *dirp) +handle_new(int use, const char *name, int fd, int flags, DIR *dirp) { int i; @@ -220,6 +225,7 @@ handle_new(int use, const char *name, in handles[i].use = use; handles[i].dirp = dirp; handles[i].fd = fd; + handles[i].flags = flags; handles[i].name = xstrdup(name); handles[i].bytes_read = handles[i].bytes_write = 0; @@ -282,6 +288,14 @@ handle_to_fd(int handle) return -1; } +static int +handle_to_flags(int handle) +{ + if (handle_is_ok(handle, HANDLE_FILE)) + return handles[handle].flags; + return -1; +} + static void handle_update_read(int handle, ssize_t bytes) { @@ -567,7 +581,7 @@ process_open(void) if (fd < 0) { status = errno_to_portable(errno); } else { - handle = handle_new(HANDLE_FILE, name, fd, NULL); + handle = handle_new(HANDLE_FILE, name, fd, flags, NULL); if (handle < 0) { close(fd); } else { @@ -660,7 +674,8 @@ process_write(void) else if (readonly) status = SSH2_FX_PERMISSION_DENIED; else { - if (lseek(fd, off, SEEK_SET) < 0) { + if (!(handle_to_flags(handle) & O_APPEND) && + lseek(fd, off, SEEK_SET) < 0) { status = errno_to_portable(errno); error("process_write: seek failed"); } else { @@ -893,7 +908,7 @@ process_opendir(void) if (dirp == NULL) { status = errno_to_portable(errno); } else { - handle = handle_new(HANDLE_DIR, path, 0, dirp); + handle = handle_new(HANDLE_DIR, path, 0, 0, dirp); if (handle < 0) { closedir(dirp); } else { From ryan_cox at byu.edu Tue Oct 15 09:01:31 2013 From: ryan_cox at byu.edu (Ryan Cox) Date: Mon, 14 Oct 2013 16:01:31 -0600 Subject: Provide AcceptEnv variables to a Linux PAM module? Message-ID: <525C69BB.90103@byu.edu> I've been looking for a while and can't figure out for sure if variables allowed by AcceptEnv are readable by a PAM module. I looked through the openssh source code and found a few calls to pam_putenv(), which looks like the relevant call, but I don't see anything that would copy over AcceptEnv variables. Am I correct that the variables are not available to PAM? I'm guessing there are security implications to passing arbitrary variables through to PAM but is there some other way I can do so? The reason I ask is because I'm working with the SLURM resource manager to monitor remote processes launched via ssh. It's not perfect, but I'm using SendEnv and AcceptEnv to pass $SLURM_JOB_ID around. I want to run a pam module or script that assigns sshd and its children to a particular cgroup (based on $SLURM_JOB_ID) using a slurm API call. The best solution I have found seems to be calling a script from /etc/ssh/sshrc as the user (which can be negated by users creating ~/.sshrc). Is that the best option at the moment? Ideally we would do this in PAM as root but it doesn't seem possible for now. Ryan Cox From djm at mindrot.org Tue Oct 15 10:04:27 2013 From: djm at mindrot.org (Damien Miller) Date: Tue, 15 Oct 2013 10:04:27 +1100 (EST) Subject: Provide AcceptEnv variables to a Linux PAM module? In-Reply-To: <525C69BB.90103@byu.edu> References: <525C69BB.90103@byu.edu> Message-ID: On Mon, 14 Oct 2013, Ryan Cox wrote: > I've been looking for a while and can't figure out for sure if variables > allowed by AcceptEnv are readable by a PAM module. I looked through the > openssh source code and found a few calls to pam_putenv(), which looks like > the relevant call, but I don't see anything that would copy over AcceptEnv > variables. Am I correct that the variables are not available to PAM? No, they are only applied when the user's session is created, after authentication. > I'm > guessing there are security implications to passing arbitrary variables > through to PAM but is there some other way I can do so? No, because the accepted environment variables are sent as part of the session establishment that occurs well after authentication completes. Maybe it would be possible to run the PAM session modules for each multiplexed session (right now we run them right after authentication but before session), but I'm not sure it would be safe to allow the user environment through to them if they continue to run as root. -d From tim.ruehsen at gmx.de Wed Oct 16 00:45:29 2013 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Tue, 15 Oct 2013 15:45:29 +0200 Subject: SSH development questions Message-ID: <5511708.gPiiLEl6uU@blitz-lx> Hi, I would like to contribute to OpenSSH. Theo pointed out that development first takes place on OpenBSD, than ported. My first steps where - installation of OpenBSD 5.3 - CVS downloaded /usr/src from -current branch - compiling/linking /usr/src/usr.bin/ssh/ (following the README) Now I would like to do some changes to the sources and contribute a patch. My main questions is What is the official/recommended procedure to do the testing after my changes? Especially without installing the freshly installed (and perhaps notworking) software. I found a directory /usr/src/regress/usr.bin/ssh where I could 'make regress', but that seems to test the installed programs. Thanks, Tim From keisial at gmail.com Wed Oct 16 06:52:35 2013 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Tue, 15 Oct 2013 21:52:35 +0200 Subject: Feature request: FQDN Host match In-Reply-To: References: Message-ID: <525D9D03.1090501@gmail.com> On 07/10/13 16:48, Alexander T wrote: > 'ssh mybox.my.very.long.subdomain.at.example.com' > > BUT this becomes problematic when combined with .ssh/config, where I > would like to specify something like > > Host *.subdomain.at.example.com > User notme > > This since the fully qualified domain name is not used when matching > Host directives, and I'm only saying 'ssh mybox', so the rule will > never match. > > So my question is whether there is some specific reason why FQDN isn't > used when matching Host-entries. And if not, would you consider a > patch containing this change? > > Best regards, > > Alexander T It's doing it backwards, but you could do: Host mybox joebox alexbox ... HostName %h.my.very.long.subdomain.at.example.com User notme From ryan_cox at byu.edu Wed Oct 16 10:02:50 2013 From: ryan_cox at byu.edu (Ryan Cox) Date: Tue, 15 Oct 2013 17:02:50 -0600 Subject: Provide AcceptEnv variables to a Linux PAM module? In-Reply-To: References: <525C69BB.90103@byu.edu> Message-ID: <525DC99A.9050905@byu.edu> On 10/14/2013 05:04 PM, Damien Miller wrote: > On Mon, 14 Oct 2013, Ryan Cox wrote: > >> I've been looking for a while and can't figure out for sure if variables >> allowed by AcceptEnv are readable by a PAM module. I looked through the >> openssh source code and found a few calls to pam_putenv(), which looks like >> the relevant call, but I don't see anything that would copy over AcceptEnv >> variables. Am I correct that the variables are not available to PAM? > No, they are only applied when the user's session is created, after > authentication. > >> I'm >> guessing there are security implications to passing arbitrary variables >> through to PAM but is there some other way I can do so? > No, because the accepted environment variables are sent as part of the > session establishment that occurs well after authentication completes. That makes sense. It seems like a major architectural change to do things differently. > Maybe it would be possible to run the PAM session modules for each > multiplexed session (right now we run them right after authentication but > before session), but I'm not sure it would be safe to allow the user > environment through to them if they continue to run as root. I guess if that change is made and there is some concern about overwriting variables, maybe a variable prefix could be added so there are no name collisions? E.g. USER_PROVIDED_SLURM_JOB_ID or something like that for SLURM_JOB_ID. I haven't really thought through it much but that seems like it could work since the PAM module would have to be coded to look for some variable anyway. At the very least, I would like to find some surefire way to run a script (as root or the user) and /etc/ssh/sshrc seems like the only option at this point. Is there a way to either 1) ignore any ~/.sshrc or 2) tell sshd to run both /etc/ssh/sshrc *and* ~/.sshrc if they exist? I couldn't find any mention of that possibility in the manpages or code. I suppose I could recompile sshd and have it ignore ~/.sshrc but some configuration parameter would be nice. If you ever did want to pursue my original idea of sending AcceptEnv variables to PAM, I'm sure there would be a lot of grateful HPC users. That said, I think the mandatory execution of /etc/ssh/sshrc or something similar would work equally well in SLURM. If this doesn't seem like a good feature to add, I can cron something to remove any existing ~/.sshrc files and it will likely be just fine. Thanks, Ryan From djm at mindrot.org Wed Oct 16 11:00:59 2013 From: djm at mindrot.org (Damien Miller) Date: Wed, 16 Oct 2013 11:00:59 +1100 (EST) Subject: Provide AcceptEnv variables to a Linux PAM module? In-Reply-To: <525DC99A.9050905@byu.edu> References: <525C69BB.90103@byu.edu> <525DC99A.9050905@byu.edu> Message-ID: On Tue, 15 Oct 2013, Ryan Cox wrote: > At the very least, I would like to find some surefire way to run a > script (as root or the user) and /etc/ssh/sshrc seems like the only > option at this point. Is there a way to either 1) ignore any ~/.sshrc > or 2) tell sshd to run both /etc/ssh/sshrc *and* ~/.sshrc if they > exist? I couldn't find any mention of that possibility in the manpages > or code. I suppose I could recompile sshd and have it ignore ~/.sshrc > but some configuration parameter would be nice. So, if you are using public key authentication then you can set the "no-user-rc" key option to disable the ~/.sshrc file. I'd support adding a configuration option to control this; IMO it makes sense that one should be able to control this from sshd_config too. Would you mind filing a bug at https://bugzilla.mindrot.org/ to request the new option? -d From ryan_cox at byu.edu Wed Oct 16 13:00:24 2013 From: ryan_cox at byu.edu (Ryan Cox) Date: Tue, 15 Oct 2013 20:00:24 -0600 Subject: Provide AcceptEnv variables to a Linux PAM module? In-Reply-To: References: <525C69BB.90103@byu.edu> <525DC99A.9050905@byu.edu> Message-ID: <525DF338.3020902@byu.edu> On 10/15/2013 06:00 PM, Damien Miller wrote: > So, if you are using public key authentication then you can set > the "no-user-rc" key option to disable the ~/.sshrc file. I'd support We have a few hundred users and they're all in control of their authorized_keys file so that wouldn't work very well. > adding a configuration option to control this; IMO it makes sense that > one should be able to control this from sshd_config too. > > Would you mind filing a bug at https://bugzilla.mindrot.org/ to > request the new option? Done. https://bugzilla.mindrot.org/show_bug.cgi?id=2160 Thank you, Ryan > > -d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From tim.ruehsen at gmx.de Thu Oct 17 22:10:04 2013 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Thu, 17 Oct 2013 13:10:04 +0200 Subject: SSH regression test failure question Message-ID: <1716475.KNHQ0nGbzA@blitz-lx> Hi, meanwhile I am deeper into OpenSSH (followed the well-done docs, that I missed in the beginning). 'make build' works with current CVS. But REGRESS_FULL=1 make regress fails for ssh: failed sftp permissions *** Error 1 in ssh (Makefile:145 't-sftp-perm') FAILED *** Error 1 in ssh (:101 'regress') *** Error 1 in /usr/src/regress/usr.bin (:48 'regress') I can see it is due to postcondition check failed: setstat readonly which fails since I am running the regression test as user 'root'. Question: Should I patch the test (to work as user root), or am I doing something wrong (e.g. missed to set an env variable or being the wrong user ?) Regards, Tim From djm at mindrot.org Fri Oct 18 08:59:05 2013 From: djm at mindrot.org (Damien Miller) Date: Fri, 18 Oct 2013 08:59:05 +1100 (EST) Subject: SSH regression test failure question In-Reply-To: <1716475.KNHQ0nGbzA@blitz-lx> References: <1716475.KNHQ0nGbzA@blitz-lx> Message-ID: > Hi, > > meanwhile I am deeper into OpenSSH (followed the well-done docs, that I missed > in the beginning). > > 'make build' works with current CVS. > > But > REGRESS_FULL=1 make regress > fails for ssh: > failed sftp permissions > *** Error 1 in ssh (Makefile:145 't-sftp-perm') > FAILED > *** Error 1 in ssh (:101 'regress') > *** Error 1 in /usr/src/regress/usr.bin (:48 'regress') > > I can see it is due to > postcondition check failed: setstat readonly > which fails since I am running the regression test as user 'root'. Thanks for the diagnosis and thanks for running the regress tests :) The fix is pretty simple: set/test executability instead of writability. I'll commit this, it should be in tomorrow's snapshot. Index: sftp-perm.sh =================================================================== RCS file: /cvs/src/regress/usr.bin/ssh/sftp-perm.sh,v retrieving revision 1.1 diff -u -p -r1.1 sftp-perm.sh --- sftp-perm.sh 9 Oct 2013 23:44:14 -0000 1.1 +++ sftp-perm.sh 17 Oct 2013 21:57:49 -0000 @@ -90,10 +90,10 @@ ro_test \ ro_test \ "setstat" \ - "chmod 0600 $COPY" \ + "chmod 0700 $COPY" \ "touch $COPY; chmod 0400 $COPY" \ - "test -w $COPY" \ - "test ! -w $COPY" + "test -x $COPY" \ + "test ! -x $COPY" ro_test \ "rm" \ @@ -191,10 +191,10 @@ perm_test \ perm_test \ "setstat" \ "realpath,stat,lstat" \ - "chmod 0600 $COPY" \ + "chmod 0700 $COPY" \ "touch $COPY; chmod 0400 $COPY" \ - "test -w $COPY" \ - "test ! -w $COPY" + "test -x $COPY" \ + "test ! -x $COPY" perm_test \ "remove" \ From imorgan at nas.nasa.gov Fri Oct 18 12:15:24 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 17 Oct 2013 18:15:24 -0700 Subject: Feedback regarding the ssh(1) Match directive Message-ID: <20131018011524.GA10382@linux124.nas.nasa.gov> Hi, I noticed the recent commit adding Match support to ssh(1). I look forward to giving it a try, but I have some initial feedback based on ssh_config.5 and an examiniation of match_cfg_line(). First, the "command" keyword could be a little deceptive. Although the man page makes the use of this keyword quite clear, my initial assumption was that the intent was to match against the remote command that is being requested. That would seem to be a more natural interpretation of this keyword. Instead it is an arbitrary local test. Perhaps "localtest" would be a better choice for the keyword. There are cases where it would be useful to match on the requested command, to select a different public key or possibly use a different port. For example, I use one key for CVS operations against a local server, where the key is restricted to "cvs server," and a different key for shell logins to that same server. Currently, I manage this by using different hostnames, but I was hoping that the Match directive would provide a cleaner approach. Also, the man page does not document any of the percent macros supported by teh command keyword. -- Iain Morgan From plautrba at redhat.com Sat Oct 19 00:31:37 2013 From: plautrba at redhat.com (Petr Lautrbach) Date: Fri, 18 Oct 2013 15:31:37 +0200 Subject: confusing documentation for ssh-keygen -V validity_interval Message-ID: <52613839.3080506@redhat.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hello, ssh-keygen.1 says that: - -V validity_interval For example: ?+52w1d? (valid from now to 52 weeks and one day from now), ?-4w:+4w? (valid from four weeks ago to four weeks from now), This sounds like the interval is from 4 weeks ago and to 4 weeks from now. But according to the code, 'to' is created relatively to from not now: ssh-keygen.c: 1740 if (*from == '-' || *from == '+') 1741 cert_valid_from = parse_relative_time(from, now); 1742 else 1743 cert_valid_from = parse_absolute_time(from); 1744 1745 if (*to == '-' || *to == '+') 1746 cert_valid_to = parse_relative_time(to, cert_valid_from); 1747 else 1748 cert_valid_to = parse_absolute_time(to); What is right? The man page or the code? Thanks, Petr - -- Petr Lautrbach Security Technologies Red Hat Better technology. Faster innovation. Powered by community collaboration. See how it works at redhat.com. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.21 (GNU/Linux) iQIcBAEBAgAGBQJSYTg4AAoJEGOorUuYLENzjBEQALIwDWBTXu4q3FMTXSoEe4MV SB/SujyukHSUBF9aAGHHSznCiu7GWi6bR18tlyjujO8rvtdHmSRRJ1uR99IMIqAp mBzDbt3UgKJ98Dnr481XKu8AnmJ4F5zHumF5j2U/Q2NBM1HS5pFBPcdPCt1kJwDP C2HerTf3JEn68s43Dv8lLZmFZFu/ZG7HOvzjBOv4nHqpRmxrIFqq1KM2UvQr9nYF mflDjdnMRHUsQeocsYMp3EKfddFnvg7w9b4ZJuhtXu5M0CexH23iNb4qVAEQzs8U jX8zLO6Kmtp0D1CbfEuPdqsFpNya+2R/ijsJXtbVMXJ1gloCNbcjiRcEXGEL/ArD 1kvEZ0URpD1ZX5mLTVuG0L1AMTsXn9rvZPOWZMuYDGW0/bUFuIbgMvvimdwOpA4/ w4L3eif7j/JL4aKkJZKALxIfvdvwgynuC8OtDxseOAyt5Bmvk1ew8n3JZfkQRN4B k/gtobSdHGAQfH/bqiwz57jWL4HWfr/iPFrYYVUtzLDwQAO9bS4QTu1wPQsv8MdN LEVCLZRr6e1xKQpTPIGyk73gjvKtyEKQZs7iso3X83kmOv8Qpc2ViBOATPGuHeoY b/gBSayj50gwlmrUosRr9UL53o3ZgQDsOGsLUcDD2ZZfc0ETCpDt19jItKSGS/y0 l7swCjQle5b8DhLDfLzz =p/YF -----END PGP SIGNATURE----- From tim.ruehsen at gmx.de Sun Oct 20 03:18:15 2013 From: tim.ruehsen at gmx.de (Tim =?ISO-8859-1?Q?R=FChsen?=) Date: Sat, 19 Oct 2013 18:18:15 +0200 Subject: SSH regression test failure question In-Reply-To: References: <1716475.KNHQ0nGbzA@blitz-lx> Message-ID: <5762571.APJsgQcrut@debian> Am Freitag, 18. Oktober 2013, 08:59:05 schrieb Damien Miller: > > REGRESS_FULL=1 make regress > > > > fails for ssh: > > failed sftp permissions > > *** Error 1 in ssh (Makefile:145 't-sftp-perm') > > FAILED > > *** Error 1 in ssh (:101 'regress') > > *** Error 1 in /usr/src/regress/usr.bin (:48 'regress') > > > > Thanks for the diagnosis and thanks for running the regress tests :) > > The fix is pretty simple: set/test executability instead of writability. > I'll commit this, it should be in tomorrow's snapshot. Thanks for fixing it. Here is a patch fixing two things: - added missing files to 'make clean' - added UNPRIV user for agent-ptrace.sh (else ptrace would work and the test fails, if started as root) Regards, Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: ssh_regress.diff Type: text/x-patch Size: 1723 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From djm at mindrot.org Sun Oct 20 17:14:53 2013 From: djm at mindrot.org (Damien Miller) Date: Sun, 20 Oct 2013 17:14:53 +1100 (EST) Subject: Feedback regarding the ssh(1) Match directive In-Reply-To: <20131018011524.GA10382@linux124.nas.nasa.gov> References: <20131018011524.GA10382@linux124.nas.nasa.gov> Message-ID: On Thu, 17 Oct 2013, Iain Morgan wrote: > Hi, > > I noticed the recent commit adding Match support to ssh(1). I look > forward to giving it a try, but I have some initial feedback based on > ssh_config.5 and an examiniation of match_cfg_line(). > > First, the "command" keyword could be a little deceptive. Although the > man page makes the use of this keyword quite clear, my initial > assumption was that the intent was to match against the remote command > that is being requested. That would seem to be a more natural > interpretation of this keyword. Instead it is an arbitrary local test. > Perhaps "localtest" would be a better choice for the keyword. Maybe rename it to "exec"? Index: readconf.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/readconf.c,v retrieving revision 1.209 diff -u -p -r1.209 readconf.c --- readconf.c 16 Oct 2013 22:49:38 -0000 1.209 +++ readconf.c 20 Oct 2013 06:12:56 -0000 @@ -498,7 +498,7 @@ match_cfg_line(Options *options, char ** debug("%.200s line %d: matched " "'LocalUser %.100s' ", filename, linenum, pw->pw_name); - } else if (strcasecmp(attrib, "command") == 0) { + } else if (strcasecmp(attrib, "exec") == 0) { if (gethostname(thishost, sizeof(thishost)) == -1) fatal("gethostname: %s", strerror(errno)); strlcpy(shorthost, thishost, sizeof(shorthost)); @@ -517,11 +517,11 @@ match_cfg_line(Options *options, char ** (char *)NULL); r = execute_in_shell(cmd); if (r == -1) { - fatal("%.200s line %d: match command '%.100s' " + fatal("%.200s line %d: match exec '%.100s' " "error", filename, linenum, cmd); } else if (r == 0) { debug("%.200s line %d: matched " - "'Command \"%.100s\"' ", + "'exec \"%.100s\"' ", filename, linenum, cmd); } else result = 0; Index: ssh_config.5 =================================================================== RCS file: /cvs/src/usr.bin/ssh/ssh_config.5,v retrieving revision 1.175 diff -u -p -r1.175 ssh_config.5 --- ssh_config.5 20 Oct 2013 04:39:28 -0000 1.175 +++ ssh_config.5 20 Oct 2013 06:12:56 -0000 @@ -136,7 +136,7 @@ keyword) to be used only when the condit keyword are satisfied. Match conditions are specified using one or more keyword/criteria pairs. The available keywords are: -.Cm command , +.Cm exec , .Cm host , .Cm originalhost , .Cm user , @@ -144,8 +144,8 @@ and .Cm localuser . .Pp The criteria for the -.Cm command -keyword is a path to a command that is executed. +.Cm exec +keyword is command that is executed under the user's shell.. If the command returns a zero exit status then the condition is considered true. Commands containing whitespace characters must be quoted. The following character sequences in the command will be expanded prior to @@ -158,7 +158,7 @@ will be substituted by the local host na will be substituted by the target host name, .Ql %n will be substituted by the original target host name -specified on the command line, +specified on the command-line, .Ql %p the destination port, .Ql %r > There are cases where it would be useful to match on the requested command, > to select a different public key or possibly use a different port. For > example, I use one key for CVS operations against a local server, where > the key is restricted to "cvs server," and a different key for shell > logins to that same server. Currently, I manage this by using different > hostnames, but I was hoping that the Match directive would provide a > cleaner approach. I guess that's reasonable. Our wildcard matching code is a little inexpressive to do anything sophisticated though. > Also, the man page does not document any of the percent macros supported > by teh command keyword. I've added these. -d From tim.ruehsen at gmx.de Mon Oct 21 20:12:57 2013 From: tim.ruehsen at gmx.de (Tim Ruehsen) Date: Mon, 21 Oct 2013 11:12:57 +0200 Subject: [PATCH] added warning options to CDIAGFLAGS Message-ID: <11821282.GFrMmm0HhU@blitz-lx> In short - added -Wextra, -Wold-style-definition and -Wformat=2 - fixed compiler warnings in roaming_common.c and ssh-agent.c The changes in ssh-agent.c enable gcc format checking in some cases where it has been circumvented before. Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: ssh.diff Type: text/x-patch Size: 3733 bytes Desc: not available URL: From theaspect at gmail.com Tue Oct 22 15:05:55 2013 From: theaspect at gmail.com (Constantine) Date: Tue, 22 Oct 2013 11:05:55 +0700 Subject: [Proposal] Add ability to read authorized keys from shell script instead of file Message-ID: File authorized_keys is unusable for mass key storage and manipulation. I wan to store keys in something like mysql server, but It will add big unwanted dependency to package. What if we use auth_rsa.c but instead search in file send key to some script and read sigle return value if key finded and empty if not. I think it will be very customizable. -- With Best Regards, Constantine From djm at mindrot.org Tue Oct 22 19:01:08 2013 From: djm at mindrot.org (Damien Miller) Date: Tue, 22 Oct 2013 19:01:08 +1100 (EST) Subject: [Proposal] Add ability to read authorized keys from shell script instead of file In-Reply-To: References: Message-ID: On Tue, 22 Oct 2013, Constantine wrote: > File authorized_keys is unusable for mass key storage and manipulation. I > wan to store keys in something like mysql server, but It will add big > unwanted dependency to package. What if we use auth_rsa.c but instead > search in file send key to some script and read sigle return value if key > finded and empty if not. I think it will be very customizable. You mean like AuthorizedKeysCommand in OpenSSH 6.2? From imorgan at nas.nasa.gov Wed Oct 23 11:08:47 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Tue, 22 Oct 2013 17:08:47 -0700 Subject: Feedback regarding the ssh(1) Match directive In-Reply-To: References: <20131018011524.GA10382@linux124.nas.nasa.gov> Message-ID: <20131023000847.GG10422@linux124.nas.nasa.gov> On Sun, Oct 20, 2013 at 17:14:53 +1100, Damien Miller wrote: > On Thu, 17 Oct 2013, Iain Morgan wrote: > > > Hi, > > > > I noticed the recent commit adding Match support to ssh(1). I look > > forward to giving it a try, but I have some initial feedback based on > > ssh_config.5 and an examiniation of match_cfg_line(). > > > > First, the "command" keyword could be a little deceptive. Although the > > man page makes the use of this keyword quite clear, my initial > > assumption was that the intent was to match against the remote command > > that is being requested. That would seem to be a more natural > > interpretation of this keyword. Instead it is an arbitrary local test. > > Perhaps "localtest" would be a better choice for the keyword. > > Maybe rename it to "exec"? > That works for me. After doing a little experimentation, I've found one small bug: percent_expand() needs to be applied to options->hostname to handle the case where an earlier block used HostName with %h. We currently do that expansion in ssh.c, but it looks like we also need to do it in match_cfg_lien() or find some more appropriate spot so that we only have to do it once. -- Iain Morgan From theaspect at gmail.com Wed Oct 23 16:05:24 2013 From: theaspect at gmail.com (Constantine) Date: Wed, 23 Oct 2013 12:05:24 +0700 Subject: Fwd: [Proposal] Add ability to read authorized keys from shell script instead of file In-Reply-To: References: Message-ID: Well, it is almost what I speak about, but single user as param is not enough. We have setup with shared folder and all keys owned by single user. What if add requested key as second param to increase selectivity? 2013/10/22 Damien Miller > On Tue, 22 Oct 2013, Constantine wrote: > > > File authorized_keys is unusable for mass key storage and manipulation. I > > wan to store keys in something like mysql server, but It will add big > > unwanted dependency to package. What if we use auth_rsa.c but instead > > search in file send key to some script and read sigle return value if key > > finded and empty if not. I think it will be very customizable. > > You mean like AuthorizedKeysCommand in OpenSSH 6.2? > > > -- With Best Regards, Constantine From djm at mindrot.org Wed Oct 23 16:32:18 2013 From: djm at mindrot.org (Damien Miller) Date: Wed, 23 Oct 2013 16:32:18 +1100 (EST) Subject: confusing documentation for ssh-keygen -V validity_interval In-Reply-To: <52613839.3080506@redhat.com> References: <52613839.3080506@redhat.com> Message-ID: On Fri, 18 Oct 2013, Petr Lautrbach wrote: > ssh-keygen.1 says that: > > - -V validity_interval > > For example: ?+52w1d? (valid from now to 52 weeks and one day from now), > ?-4w:+4w? (valid from four weeks ago to four weeks from now), > > This sounds like the interval is from 4 weeks ago and to 4 weeks from now. But according to the code, > 'to' is created relatively to from not now: > > ssh-keygen.c: > 1740 if (*from == '-' || *from == '+') > 1741 cert_valid_from = parse_relative_time(from, now); > 1742 else > 1743 cert_valid_from = parse_absolute_time(from); > 1744 > 1745 if (*to == '-' || *to == '+') > 1746 cert_valid_to = parse_relative_time(to, cert_valid_from); > 1747 else > 1748 cert_valid_to = parse_absolute_time(to); > > What is right? The man page or the code? The manpage should be right. I've fixed this for openssh-6.4. Thanks, Damien From djm at mindrot.org Wed Oct 23 16:32:49 2013 From: djm at mindrot.org (Damien Miller) Date: Wed, 23 Oct 2013 16:32:49 +1100 (EST) Subject: Feedback regarding the ssh(1) Match directive In-Reply-To: <20131023000847.GG10422@linux124.nas.nasa.gov> References: <20131018011524.GA10382@linux124.nas.nasa.gov> <20131023000847.GG10422@linux124.nas.nasa.gov> Message-ID: On Tue, 22 Oct 2013, Iain Morgan wrote: > After doing a little experimentation, I've found one small bug: > percent_expand() needs to be applied to options->hostname to handle the > case where an earlier block used HostName with %h. We currently do that > expansion in ssh.c, but it looks like we also need to do it in > match_cfg_lien() or find some more appropriate spot so that we only have > to do it once. Fixed - thanks. -d From imorgan at nas.nasa.gov Thu Oct 24 05:52:43 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Wed, 23 Oct 2013 11:52:43 -0700 Subject: ProxyCommand brokent in recent snapshots Message-ID: <20131023185243.GB10382@linux124.nas.nasa.gov> Hello, While testing recent snapshots (20131023 and 20131024) I encountered a problem with ProxyCommand. The regression tests all passed, but the use of ProxyCommand's in my ~/.ssh/config resulted in name resolution errors; even if CanonicalizeHostname was explicitly set to "no." The patch included inline below fixed the issue: Index: ssh.c =================================================================== RCS file: /cvs/openssh/ssh.c,v retrieving revision 1.386 diff -u -r1.386 ssh.c --- ssh.c 23 Oct 2013 05:31:11 -0000 1.386 +++ ssh.c 23 Oct 2013 18:42:01 -0000 @@ -915,7 +915,7 @@ * resolve the bare hostname name using the system resolver's usual * search rules. */ - if (addrs == NULL) { + if (addrs == NULL && options.proxy_command == NULL) { if ((addrs = resolve_host(host, options.port, 1, cname, sizeof(cname))) == NULL) cleanup_exit(255); /* resolve_host logs the error */ -- Iain Morgan From panneerselvamit34 at gmail.com Thu Oct 24 05:25:58 2013 From: panneerselvamit34 at gmail.com (pans NT) Date: Wed, 23 Oct 2013 23:55:58 +0530 Subject: unsubscribe this service Message-ID: Hi Team, Please unsubscribe this service. Regards, Panneer. From djm at mindrot.org Thu Oct 24 11:19:35 2013 From: djm at mindrot.org (Damien Miller) Date: Thu, 24 Oct 2013 11:19:35 +1100 (EST) Subject: ProxyCommand brokent in recent snapshots In-Reply-To: <20131023185243.GB10382@linux124.nas.nasa.gov> References: <20131023185243.GB10382@linux124.nas.nasa.gov> Message-ID: On Wed, 23 Oct 2013, Iain Morgan wrote: > Hello, > > While testing recent snapshots (20131023 and 20131024) I encountered a > problem with ProxyCommand. The regression tests all passed, but the use > of ProxyCommand's in my ~/.ssh/config resulted in name resolution > errors; even if CanonicalizeHostname was explicitly set to "no." > > The patch included inline below fixed the issue: > > Index: ssh.c > =================================================================== > RCS file: /cvs/openssh/ssh.c,v > retrieving revision 1.386 > diff -u -r1.386 ssh.c > --- ssh.c 23 Oct 2013 05:31:11 -0000 1.386 > +++ ssh.c 23 Oct 2013 18:42:01 -0000 > @@ -915,7 +915,7 @@ > * resolve the bare hostname name using the system resolver's usual > * search rules. > */ > - if (addrs == NULL) { > + if (addrs == NULL && options.proxy_command == NULL) { > if ((addrs = resolve_host(host, options.port, 1, > cname, sizeof(cname))) == NULL) > cleanup_exit(255); /* resolve_host logs the error */ Thanks - I think it needs a further clause in that test because that block might also canonicalise a CNAME under some circumstances. Index: ssh.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/ssh.c,v retrieving revision 1.389 diff -u -p -r1.389 ssh.c --- ssh.c 23 Oct 2013 03:05:19 -0000 1.389 +++ ssh.c 24 Oct 2013 00:19:02 -0000 @@ -881,9 +881,11 @@ main(int ac, char **av) /* * If canonicalization not requested, or if it failed then try to * resolve the bare hostname name using the system resolver's usual - * search rules. + * search rules. Skip the lookup if a ProxyCommand is being used + * unless the user has specifically requested canonicalisation. */ - if (addrs == NULL) { + if (addrs == NULL && (options.proxy_command == NULL || + options.canonicalize_hostname == SSH_CANONICALISE_ALWAYS)) { if ((addrs = resolve_host(host, options.port, 1, cname, sizeof(cname))) == NULL) cleanup_exit(255); /* resolve_host logs the error */ From binny.joseph at hp.com Fri Oct 25 00:12:17 2013 From: binny.joseph at hp.com (Joseph, Binny Kallarackal (MCOU)) Date: Thu, 24 Oct 2013 13:12:17 +0000 Subject: FIPS 140-2 patch for openssh 6.3.p1 Message-ID: <95F810D815A9AB449C311D797347145E517C9D3E@G4W3292.americas.hpqcorp.net> Hi, As per the FIPS patch http://www.openssl.com/export/openssh/openssh-6.0p1.fips-revised.patch , the cipher_set_key_string() in cipher.c replaces MD5 calls with EVP_Digest() as given below: "if (EVP_Digest(passphrase, strlen(passphrase), digest, NULL, EVP_md5(), NULL) <= 0)" Since OpenSSL does not support EVP_md5() in FIPS mode, should this be replaced with EVP_sha1() or another FIPS compliant call inside the above EVP_Digest() ? Thanks and Regards, Binny. From djm at mindrot.org Fri Oct 25 10:26:19 2013 From: djm at mindrot.org (Damien Miller) Date: Fri, 25 Oct 2013 10:26:19 +1100 (EST) Subject: FIPS 140-2 patch for openssh 6.3.p1 In-Reply-To: <95F810D815A9AB449C311D797347145E517C9D3E@G4W3292.americas.hpqcorp.net> References: <95F810D815A9AB449C311D797347145E517C9D3E@G4W3292.americas.hpqcorp.net> Message-ID: On Thu, 24 Oct 2013, Joseph, Binny Kallarackal (MCOU) wrote: > Hi, > > As per the FIPS patch http://www.openssl.com/export/openssh/openssh-6.0p1.fips-revised.patch > > , the cipher_set_key_string() in cipher.c replaces MD5 calls with EVP_Digest() as given below: > > "if (EVP_Digest(passphrase, strlen(passphrase), digest, NULL, EVP_md5(), NULL) <= 0)" > > Since OpenSSL does not support EVP_md5() in FIPS mode, should this be > replaced with EVP_sha1() or another FIPS compliant call inside the > above EVP_Digest() ? That's only used by SSH protocol 1. MD5 is so baked into that protocol that I don't think it would be possible to run it while complying with FIPS. You should probably just comment it out or define an EVP_md5() that calls fatal(). -d From mark at markelee.com Fri Oct 25 10:30:38 2013 From: mark at markelee.com (Mark E. Lee) Date: Thu, 24 Oct 2013 19:30:38 -0400 Subject: LZ4 compression in openssh Message-ID: <1382657438.1670.0.camel@melech-server.localdomain> I'm a long time user of openssh and I was wondering if there is any work towards supporting alternative compression methods in openssh like LZ4? Regards, Mark -- Mark E. Lee -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: This is a digitally signed message part URL: From dtucker at zip.com.au Fri Oct 25 12:42:13 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 25 Oct 2013 12:42:13 +1100 Subject: LZ4 compression in openssh In-Reply-To: <1382657438.1670.0.camel@melech-server.localdomain> References: <1382657438.1670.0.camel@melech-server.localdomain> Message-ID: <20131025014213.GA6820@gate.dtucker.net> On Thu, Oct 24, 2013 at 07:30:38PM -0400, Mark E. Lee wrote: > I'm a long time user of openssh and I was wondering if there is any work > towards supporting alternative compression methods in openssh like LZ4? not that I've heard of. -- 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 dan at doxpara.com Fri Oct 25 19:02:50 2013 From: dan at doxpara.com (Dan Kaminsky) Date: Fri, 25 Oct 2013 04:02:50 -0400 Subject: LZ4 compression in openssh In-Reply-To: <20131025014213.GA6820@gate.dtucker.net> References: <1382657438.1670.0.camel@melech-server.localdomain> <20131025014213.GA6820@gate.dtucker.net> Message-ID: Compression has some problematic interactions with encryption that OpenSSH seems to have handled far before anyone else (by having it off by default). On Thursday, October 24, 2013, Darren Tucker wrote: > On Thu, Oct 24, 2013 at 07:30:38PM -0400, Mark E. Lee wrote: > > I'm a long time user of openssh and I was wondering if there is any work > > towards supporting alternative compression methods in openssh like LZ4? > > not that I've heard of. > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From mark at markelee.com Sat Oct 26 06:23:46 2013 From: mark at markelee.com (Mark E. Lee) Date: Fri, 25 Oct 2013 15:23:46 -0400 Subject: LZ4 compression in openssh In-Reply-To: References: <1382657438.1670.0.camel@melech-server.localdomain> <20131025014213.GA6820@gate.dtucker.net> Message-ID: <1382729026.7065.1.camel@melech-server.localdomain> Thanks for the response, what kind of problematic interactions would occur (other than trying to compress seemingly random data)? Regards, Mark On Fri, 2013-10-25 at 04:02 -0400, Dan Kaminsky wrote: > Compression has some problematic interactions with encryption that > OpenSSH seems to have handled far before anyone else (by having it off > by default). > > On Thursday, October 24, 2013, Darren Tucker wrote: > On Thu, Oct 24, 2013 at 07:30:38PM -0400, Mark E. Lee wrote: > > I'm a long time user of openssh and I was wondering if there > is any work > > towards supporting alternative compression methods in > openssh like LZ4? > > not that I've heard of. > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 > 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the > experience > usually comes from bad judgement. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Mark E. Lee -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: This is a digitally signed message part URL: From dkg at fifthhorseman.net Sat Oct 26 06:47:02 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 25 Oct 2013 15:47:02 -0400 Subject: LZ4 compression in openssh In-Reply-To: <1382729026.7065.1.camel@melech-server.localdomain> References: <1382657438.1670.0.camel@melech-server.localdomain> <20131025014213.GA6820@gate.dtucker.net> <1382729026.7065.1.camel@melech-server.localdomain> Message-ID: <526ACAB6.80906@fifthhorseman.net> On 10/25/2013 03:23 PM, Mark E. Lee wrote: > Thanks for the response, what kind of problematic interactions would > occur (other than trying to compress seemingly random data)? e.g. https://en.wikipedia.org/wiki/CRIME or similar attacks where the attacker can inject pre-defined cleartext into the channel and can then observe length changes in the ciphertext to derive the other (non-injected) contents of the cleartext. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From mark at markelee.com Sat Oct 26 07:29:44 2013 From: mark at markelee.com (Mark E. Lee) Date: Fri, 25 Oct 2013 16:29:44 -0400 Subject: LZ4 compression in openssh In-Reply-To: <526ACAB6.80906@fifthhorseman.net> References: <1382657438.1670.0.camel@melech-server.localdomain> <20131025014213.GA6820@gate.dtucker.net> <1382729026.7065.1.camel@melech-server.localdomain> <526ACAB6.80906@fifthhorseman.net> Message-ID: <1382732984.7065.4.camel@melech-server.localdomain> I see. From reading that wikipedia article, I'm wondering what gets compressed when compression is enabled in openssh. Is it the ciphertext or the cleartext? Regards, Mark On Fri, 2013-10-25 at 15:47 -0400, Daniel Kahn Gillmor wrote: > On 10/25/2013 03:23 PM, Mark E. Lee wrote: > > Thanks for the response, what kind of problematic interactions would > > occur (other than trying to compress seemingly random data)? > > e.g. https://en.wikipedia.org/wiki/CRIME or similar attacks where the > attacker can inject pre-defined cleartext into the channel and can then > observe length changes in the ciphertext to derive the other > (non-injected) contents of the cleartext. > > --dkg > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Mark E. Lee -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 230 bytes Desc: This is a digitally signed message part URL: From dan at doxpara.com Sat Oct 26 07:52:24 2013 From: dan at doxpara.com (Dan Kaminsky) Date: Fri, 25 Oct 2013 16:52:24 -0400 Subject: LZ4 compression in openssh In-Reply-To: <1382732984.7065.4.camel@melech-server.localdomain> References: <1382657438.1670.0.camel@melech-server.localdomain> <20131025014213.GA6820@gate.dtucker.net> <1382729026.7065.1.camel@melech-server.localdomain> <526ACAB6.80906@fifthhorseman.net> <1382732984.7065.4.camel@melech-server.localdomain> Message-ID: Ciphertext is incompressible. On Friday, October 25, 2013, Mark E. Lee wrote: > I see. > > From reading that wikipedia article, I'm wondering what gets compressed > when compression is enabled in openssh. Is it the ciphertext or the > cleartext? > > Regards, > Mark > > On Fri, 2013-10-25 at 15:47 -0400, Daniel Kahn Gillmor wrote: > > On 10/25/2013 03:23 PM, Mark E. Lee wrote: > > > Thanks for the response, what kind of problematic interactions would > > > occur (other than trying to compress seemingly random data)? > > > > e.g. https://en.wikipedia.org/wiki/CRIME or similar attacks where the > > attacker can inject pre-defined cleartext into the channel and can then > > observe length changes in the ciphertext to derive the other > > (non-injected) contents of the cleartext. > > > > --dkg > > > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > -- > Mark E. Lee > > From tim.ruehsen at gmx.de Sat Oct 26 08:13:26 2013 From: tim.ruehsen at gmx.de (Tim =?ISO-8859-1?Q?R=FChsen?=) Date: Fri, 25 Oct 2013 23:13:26 +0200 Subject: ProxyCommand brokent in recent snapshots In-Reply-To: References: <20131023185243.GB10382@linux124.nas.nasa.gov> Message-ID: <3700357.Wtk8ntvszG@debian> Am Donnerstag, 24. Oktober 2013, 11:19:35 schrieb Damien Miller: > Index: ssh.c > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/ssh.c,v > retrieving revision 1.389 > diff -u -p -r1.389 ssh.c > --- ssh.c 23 Oct 2013 03:05:19 -0000 1.389 > +++ ssh.c 24 Oct 2013 00:19:02 -0000 > @@ -881,9 +881,11 @@ main(int ac, char **av) > /* > * If canonicalization not requested, or if it failed then try to > * resolve the bare hostname name using the system resolver's usual > - * search rules. > + * search rules. Skip the lookup if a ProxyCommand is being used > + * unless the user has specifically requested canonicalisation. > */ > - if (addrs == NULL) { > + if (addrs == NULL && (options.proxy_command == NULL || > + options.canonicalize_hostname == SSH_CANONICALISE_ALWAYS)) { > if ((addrs = resolve_host(host, options.port, 1, > cname, sizeof(cname))) == NULL) > cleanup_exit(255); /* resolve_host logs the error */ > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev With this change, the regression test fails (ssh dumps core). 'addrs' stays NULL but is freed unconditionally a few lines further down. Tim -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: This is a digitally signed message part. URL: From dtucker at zip.com.au Sat Oct 26 09:32:34 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 26 Oct 2013 09:32:34 +1100 Subject: ProxyCommand brokent in recent snapshots In-Reply-To: <3700357.Wtk8ntvszG@debian> References: <20131023185243.GB10382@linux124.nas.nasa.gov> <3700357.Wtk8ntvszG@debian> Message-ID: On 26 Oct 2013 08:38, "Tim R?hsen" wrote: [...] > With this change, the regression test fails (ssh dumps core). > 'addrs' stays NULL but is freed unconditionally a few lines further down. What platform is this on? POSIX says free(NULL) is a no-op. http://pubs.opengroup.org/onlinepubs/000095399/functions/free.html From djm at mindrot.org Sat Oct 26 09:37:48 2013 From: djm at mindrot.org (Damien Miller) Date: Sat, 26 Oct 2013 09:37:48 +1100 (EST) Subject: ProxyCommand brokent in recent snapshots In-Reply-To: References: <20131023185243.GB10382@linux124.nas.nasa.gov> <3700357.Wtk8ntvszG@debian> Message-ID: On Sat, 26 Oct 2013, Darren Tucker wrote: > On 26 Oct 2013 08:38, "Tim R?hsen" wrote: > [...] > > With this change, the regression test fails (ssh dumps core). > > 'addrs' stays NULL but is freed unconditionally a few lines further down. > > What platform is this on? POSIX says free(NULL) is a no-op. > > http://pubs.opengroup.org/onlinepubs/000095399/functions/free.html It's freaddrinfo() that blows up - I just ok'd sthen@ to commit a fix. -d From lists at eitanadler.com Sat Oct 26 10:11:55 2013 From: lists at eitanadler.com (Eitan Adler) Date: Fri, 25 Oct 2013 19:11:55 -0400 Subject: ProxyCommand brokent in recent snapshots In-Reply-To: References: <20131023185243.GB10382@linux124.nas.nasa.gov> <3700357.Wtk8ntvszG@debian> Message-ID: On Fri, Oct 25, 2013 at 6:32 PM, Darren Tucker wrote: > On 26 Oct 2013 08:38, "Tim R?hsen" wrote: > [...] >> With this change, the regression test fails (ssh dumps core). >> 'addrs' stays NULL but is freed unconditionally a few lines further down. > > What platform is this on? POSIX says free(NULL) is a no-op. > > http://pubs.opengroup.org/onlinepubs/000095399/functions/free.html FWIW this is not unique to posix. It is part of the C standard (7.20.3.2.1 in C99). -- Eitan Adler From dtucker at zip.com.au Sat Oct 26 11:47:42 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 26 Oct 2013 11:47:42 +1100 Subject: ProxyCommand brokent in recent snapshots In-Reply-To: References: <20131023185243.GB10382@linux124.nas.nasa.gov> <3700357.Wtk8ntvszG@debian> Message-ID: On 26 Oct 2013 09:38, "Damien Miller" wrote: > It's freaddrinfo() that blows up - I just ok'd sthen@ to commit a fix. Fair enough. I guess that's what I get for commenting on a diff from my phone :-) From trent at trentnet.net Sat Oct 26 13:40:32 2013 From: trent at trentnet.net (Trent Gemmill) Date: Fri, 25 Oct 2013 22:40:32 -0400 Subject: Version problems In-Reply-To: <2881526.FzBflsWuUB@cacao> References: <524C529C.8020401@trentnet.net> <2881526.FzBflsWuUB@cacao> Message-ID: <526B2BA0.4010805@trentnet.net> Indeed. Thank you all for your help and my apologies for tying up the list with something such as this. I didn't think the 2 versions would be in different locations. >> I pray I haven't missed something obvious. I downloaded, compiled and >> installed from tar version 6.3. Version 4.3 was previously installed. >> When I ssh in It identifies as version 6.3, but ssh -v reveals: >> Match ... remote version 4.3 . This is causing my system to fail a >> required security scan which doesn't like openssh version 4.3. Can >> anyone tell me what I am doing wrong? Thank you. > /usr/local/sbin vs. /usr/sbin, or similar path mismatches? > > From aris at 0xbadc0de.be Mon Oct 28 21:56:38 2013 From: aris at 0xbadc0de.be (Aris Adamantiadis) Date: Mon, 28 Oct 2013 11:56:38 +0100 Subject: LZ4 compression in openssh In-Reply-To: <526ACAB6.80906@fifthhorseman.net> References: <1382657438.1670.0.camel@melech-server.localdomain> <20131025014213.GA6820@gate.dtucker.net> <1382729026.7065.1.camel@melech-server.localdomain> <526ACAB6.80906@fifthhorseman.net> Message-ID: <526E42E6.8030608@0xbadc0de.be> Also nice to know that zlib at openssh.com enables the compression only after authentication, mitigating the known problems with compression and passwords. It is also very hard to do chosen-plaintext attacks on the client to server side (in opposite to HTTPS where that's trivial). And most passwords that are typed after authentications are entered character by character, making them fall under the padding length anyway. I think the compression vulnerabilities in CRIME are not appliable to SSH with delayed compression. Aris Le 25/10/13 21:47, Daniel Kahn Gillmor a ?crit : > On 10/25/2013 03:23 PM, Mark E. Lee wrote: >> Thanks for the response, what kind of problematic interactions >> would occur (other than trying to compress seemingly random >> data)? > > e.g. https://en.wikipedia.org/wiki/CRIME or similar attacks where > the attacker can inject pre-defined cleartext into the channel and > can then observe length changes in the ciphertext to derive the > other (non-injected) contents of the cleartext. > > --dkg > > > > _______________________________________________ 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 29 13:01:08 2013 From: djm at mindrot.org (Damien Miller) Date: Tue, 29 Oct 2013 13:01:08 +1100 (EST) Subject: LZ4 compression in openssh In-Reply-To: <526E42E6.8030608@0xbadc0de.be> References: <1382657438.1670.0.camel@melech-server.localdomain> <20131025014213.GA6820@gate.dtucker.net> <1382729026.7065.1.camel@melech-server.localdomain> <526ACAB6.80906@fifthhorseman.net> <526E42E6.8030608@0xbadc0de.be> Message-ID: On Mon, 28 Oct 2013, Aris Adamantiadis wrote: > Also nice to know that zlib at openssh.com enables the compression only > after authentication, mitigating the known problems with compression > and passwords. It is also very hard to do chosen-plaintext attacks on > the client to server side (in opposite to HTTPS where that's trivial). > And most passwords that are typed after authentications are entered > character by character, making them fall under the padding length > anyway. I think the compression vulnerabilities in CRIME are not > appliable to SSH with delayed compression. I think CRIME-like attacks would be impractical for SSH anyway. HTTPS is somewhat special in that an attacker may plausibly force their victim to make an effectively unlimited number of connections containing chosen plaintext. This set of circumstances is pretty far from usual for SSH. -d From djm at mindrot.org Wed Oct 30 17:27:59 2013 From: djm at mindrot.org (Damien Miller) Date: Wed, 30 Oct 2013 17:27:59 +1100 (EST) Subject: [PATCH] curve25519-sha256@libssh.org key exchange proposal In-Reply-To: <5241F449.8070407@0xbadc0de.be> References: <5241F449.8070407@0xbadc0de.be> Message-ID: On Tue, 24 Sep 2013, Aris Adamantiadis wrote: > 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. ... I just had a quick look at the patch. Overall it's good; some preliminary comments below. diff --git a/kexc25519.c b/kexc25519.c new file mode 100644 index 0000000..8260fad --- /dev/null +++ b/kexc25519.c ... +#include +#define CURVE25519_PUBKEY_SIZE crypto_scalarmult_curve25519_BYTES For OpenSSH, I think we could just include the portable C version from https://code.google.com/p/curve25519-donna/ rather than depending on the entirety of nacl. nacl includes a heap of stuff that we don't need and makes some unusual design choices like choosing between native implementations by measuring the host it is being compiled on. The downside to the -donna implementation is that it doesn't promise constant time execution. AFAIK this isn't a killer for the SSH case as an attacker doesn't get to measure the processing time for any set of DH public values more than once. It would be worse if we reused DH values, but we don't. (-donna also has the disadvantage of being slower, but were quibbling over single-digit milliseconds here so IMO it doesn't matter at all.) +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, ... + buffer_put_bignum2(&b, shared_secret); It would be simpler to pass the shared_secret as a const u_char* and length here - saving a round-trip to BIGNUM and back. diff --git a/kexc25519c.c b/kexc25519c.c new file mode 100644 index 0000000..b2000f0 --- /dev/null +++ b/kexc25519c.c ... +void +kexc25519_client(Kex *kex) +{ ... + /* generate private key */ + for (i = 0; i < sizeof(client_key); i++) { + if (i % 4 == 0) + rnd = arc4random(); + client_key[i] = rnd; + rnd >>= 8; + } easier to use arc4random_buf() here. If we use the -donna implementation then we need to do the client_key[0] &= 248; client_key[31] &= 127; client_key[31] |= 64; ourselves. It might be better to have put a kex_c25519_genkey() in kexc25519.c that does it all and use it in both the client and server. -d From imorgan at nas.nasa.gov Thu Oct 31 06:02:03 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Wed, 30 Oct 2013 12:02:03 -0700 Subject: Lazy evaluation of exec clause in ssh Match statement Message-ID: <20131030190203.GA8747@linux124.nas.nasa.gov> Hello, At present, if a ssh Match block contains an exec clause, the specified command is executed regardless of whether any preceding clauses are true. Thus, Match host !*.* exec "some_command %h" ... would always execute some_command regardless of whether the host matches the preceding pattern. That seems undesirable, particularly as the user-specified command may do name lookups or other operations that may introduce delays. Using a lazy approach, where the command is only executed if the preceding clauses are true would seem to be better. -- Iain Morgan From aris at 0xbadc0de.be Thu Oct 31 07:50:47 2013 From: aris at 0xbadc0de.be (Aris Adamantiadis) Date: Wed, 30 Oct 2013 21:50:47 +0100 Subject: [PATCH] curve25519-sha256@libssh.org key exchange proposal In-Reply-To: References: <5241F449.8070407@0xbadc0de.be> Message-ID: <52717127.4010005@0xbadc0de.be> Le 30/10/13 07:27, Damien Miller a ?crit : > For OpenSSH, I think we could just include the portable C version from > https://code.google.com/p/curve25519-donna/ rather than depending on > the entirety of nacl. nacl includes a heap of stuff that we don't need > and makes some unusual design choices like choosing between native > implementations by measuring the host it is being compiled on. > > The downside to the -donna implementation is that it doesn't promise > constant time execution. AFAIK this isn't a killer for the SSH case as > an attacker doesn't get to measure the processing time for any set of DH > public values more than once. It would be worse if we reused DH values, > but we don't. (-donna also has the disadvantage of being slower, but were > quibbling over single-digit milliseconds here so IMO it doesn't matter at > all.) Hi Damien, I did some research. It seems the two portable alternatives either are: -curve25519-donna (non constant time, BSD-with-don't-use-google-name-clause) --> https://github.com/agl/curve25519-donna/blob/master/curve25519-donna.c -Nacl's C implementation (Public domain, Matthew Dempsky, 2008, see on github) --> https://github.com/cjdelisle/cnacl/blob/master/crypto_scalarmult/curve25519/ref/smult.c Unfortunately the lack of metrics and claims in the latter code makes it harder to decide which one to use. But NaCl's code looks simpler (which doesn't mean faster or constant time). Up to you guys to decide :) > + const BIGNUM *shared_secret, > ... > + buffer_put_bignum2(&b, shared_secret); > > It would be simpler to pass the shared_secret as a const u_char* and > length here - saving a round-trip to BIGNUM and back. I must say I just copied ecdh implementation that did this. I can change it, I only have to verify if there's no trick in the encoding of bignums (prepending a 0 if first bit is set pops to my head). I wouldn't change the specs to use a standard string because that would differ from all other existing key exchanges. > + for (i = 0; i < sizeof(client_key); i++) { > + if (i % 4 == 0) > + rnd = arc4random(); > + client_key[i] = rnd; > + rnd >>= 8; > + } > > easier to use arc4random_buf() here. ack, but I think I copied that loop from somewhere else in openssh and deduced that was the way to go. > If we use the -donna implementation > then we need to do the > > client_key[0] &= 248; > client_key[31] &= 127; > client_key[31] |= 64; > > ourselves. It might be better to have put a kex_c25519_genkey() in > kexc25519.c that does it all and use it in both the client and server. > The implementation I pointed to already does this, at least in the git version. Regards, Aris From imorgan at nas.nasa.gov Thu Oct 31 08:09:58 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Wed, 30 Oct 2013 14:09:58 -0700 Subject: Lazy evaluation of exec clause in ssh Match statement In-Reply-To: <20131030190203.GA8747@linux124.nas.nasa.gov> References: <20131030190203.GA8747@linux124.nas.nasa.gov> Message-ID: <20131030210958.GB8747@linux124.nas.nasa.gov> On Wed, Oct 30, 2013 at 12:02:03 -0700, Iain Morgan wrote: > Hello, > > At present, if a ssh Match block contains an exec clause, the specified > command is executed regardless of whether any preceding clauses are > true. Thus, > > Match host !*.* exec "some_command %h" > ... > > would always execute some_command regardless of whether the host matches > the preceding pattern. That seems undesirable, particularly as the > user-specified command may do name lookups or other operations that may > introduce delays. > > Using a lazy approach, where the command is only executed if the > preceding clauses are true would seem to be better. > > -- > Iain Morgan > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev It looks like there is alos an issue with negation, so a better example of the initial issue would be: Match user someuser exec "some_command %h" ... -- Iain Morgan From imorgan at nas.nasa.gov Thu Oct 31 11:01:18 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Wed, 30 Oct 2013 17:01:18 -0700 Subject: Lazy evaluation of exec clause in ssh Match statement In-Reply-To: <20131030210958.GB8747@linux124.nas.nasa.gov> References: <20131030190203.GA8747@linux124.nas.nasa.gov> <20131030210958.GB8747@linux124.nas.nasa.gov> Message-ID: <20131031000118.GC8747@linux124.nas.nasa.gov> On Wed, Oct 30, 2013 at 14:09:58 -0700, Iain Morgan wrote: > On Wed, Oct 30, 2013 at 12:02:03 -0700, Iain Morgan wrote: > > Hello, > > > > At present, if a ssh Match block contains an exec clause, the specified > > command is executed regardless of whether any preceding clauses are > > true. Thus, > > > > Match host !*.* exec "some_command %h" > > ... > > > > would always execute some_command regardless of whether the host matches > > the preceding pattern. That seems undesirable, particularly as the > > user-specified command may do name lookups or other operations that may > > introduce delays. > > > > Using a lazy approach, where the command is only executed if the > > preceding clauses are true would seem to be better. > > > > -- > > Iain Morgan > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > It looks like there is alos an issue with negation, so a better example > of the initial issue would be: > > Match user someuser exec "some_command %h" > ... > > -- > Iain Morgan Oops! Please ignore what I said about negation. I should have used "host *,!*.*" in the first example. -- Iain Morgan From pcerny at suse.cz Thu Oct 31 18:54:01 2013 From: pcerny at suse.cz (Petr Cerny) Date: Thu, 31 Oct 2013 08:54:01 +0100 Subject: FIPS 140-2 patch for openssh 6.3.p1 In-Reply-To: <525626a6.a459440a.7091.337a@mx.google.com> References: <525626a6.a459440a.7091.337a@mx.google.com> Message-ID: <52720C99.6060501@suse.cz> Manish Jagtap wrote: > Hi, > > Is FIPS 140-2 patch for openssh 6.3.p1 available somewhere or do I have to > make one using > http://www.openssl.com/export/openssh/openssh-6.0p1.fips-revised.patch ? You can also look at the openSUSE package (https://build.opensuse.org/package/show/network/openssh) the patches you'd need are: openssh-6.2p2-fingerprint_hash.patch openssh-6.2p2-fips.patch Update to 6.3p1 is WIP. Kind regards Petr -- Petr Cerny Mozilla/OpenSSH maintainer for SUSE Linux From manish.jagtap at airtightnetworks.com Thu Oct 31 19:19:04 2013 From: manish.jagtap at airtightnetworks.com (Manish Jagtap) Date: Thu, 31 Oct 2013 13:49:04 +0530 Subject: Older ssh clients can't connect to sshd (6.3p1) built using FIPS object module 2.0.5 Message-ID: <5272128b.488b440a.2017.ffff9637@mx.google.com> Hi, ssh server: OpenSSH_6.3-FIPS, OpenSSL FIPS Object Module v2.0.5 ssh client: OpenSSH_5.3p1, OpenSSL FIPS Object Module v1.2 We have built and installed FIPS object module (v2.0.5) using http://www.openssl.org/source/openssl-fips-2.0.5.tar.gz Using this FIPS object module, we have build FIPS capable openssl as well. Note that we have "not" used ecp version (with binary curve ECC omitted) of FIPS object module. We have applied a FIPS patch similar to http://www.openssl.com/export/openssh/openssh-6.0p1.fips-revised.patch to openssh suite v6.3p1 and successfully generated openssh suite binaries. PFA our draft of FIPS patch for openssh: openssh-6.3p1-fips-patch (Not reviewed by OpenSSL Software Foundation). sshd built this way has connection issues with older ssh clients - even in FIPS off mode. PFA error logs (ssh_error.log) ssh client just blocks at the following log: >debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP openssh client v6.3.p1 can successfully connect to this server - but some of older clients can't. Any pointers? Thanks, Manish Jagtap -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-6.3p1-fips-patch.txt URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ssh_error.log.txt URL: