From rak at debian.org Fri May 3 12:32:15 2013 From: rak at debian.org (Ryan Kavanagh) Date: Thu, 2 May 2013 22:32:15 -0400 Subject: [PATCH] Allow matching HostName against Host entries In-Reply-To: <20845.29648.741327.384137@nu.ryanak.ca> References: <20130322015127.GC30194@nu.ryanak.ca> <20130408162521.GA21308@nu.ryanak.ca> <20835.27221.466113.996877@nu.ryanak.ca> <20130409190042.GA8305@linux124.nas.nasa.gov> <20836.29337.739297.965797@nu.ryanak.ca> <0353A032-09F8-4AB7-A928-E03D1D4CCA21@offwriting.org> <20130411050606.GB13960@apb-laptoy.apb.alt.za> <516ABD52.3040107@gmail.com> <20845.29648.741327.384137@nu.ryanak.ca> Message-ID: <20130503023215.GF6176@nu.ryanak.ca> Hi all, Sorry for the delay, I got caught up with work related things. On Tue, Apr 16, 2013 at 11:52:48AM -0400, Ryan Kavanagh wrote: > Seeing that this option had support in another subthread, I'll update > my patch to use ExpandHost instead. > > To those who objected to my initial patch, does this change address > your concerns? I've updated the patch, inlined below. I've added the following additional extensions to the ExpandHost idea: * Add a "%h" flag to ExpandHost that does the same thing as "%h" in HostName: substitute in the host passed on the command line * Add a "%e" flag to HostName that expands to the value of ExpandHost. These percent-expansions simplify cases like Host foo HostName foo.bar.baz ExpandHost foo.bar.baz or Host foo HostName %h.bar.baz ExpandHost foo.bar.baz to the simpler Host foo HostName %h.bar.baz ExpandHost %h.bar.baz or even simpler, to Host foo HostName %e ExpandHost %h.bar.baz Note that the ordering of HostName and ExpandHost doesn't matter for the percent-expansions: %e in HostName gets expanded from ssh.c after the config file is processed, and nothing in ExpandHost depends on HostName. Both of these percent-expansions are easy to remove should there be any objections, but I think both are useful and I can easily think of real-world use cases for each. Please let me know if you have any questions/concerns/comments, and if the patch below addresses the previously raised concerns. Best wishes, Ryan -- |_)|_/ Ryan Kavanagh | Debian Developer | \| \ http://ryanak.ca/ | GPG Key 4A11C97A Index: usr.bin/ssh/readconf.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/readconf.h,v retrieving revision 1.93 diff -u -r1.93 readconf.h --- usr.bin/ssh/readconf.h 22 Feb 2013 04:45:09 -0000 1.93 +++ usr.bin/ssh/readconf.h 3 May 2013 02:27:33 -0000 @@ -80,6 +80,7 @@ char *kex_algorithms; /* SSH2 kex methods in order of preference. */ int protocol; /* Protocol in order of preference. */ char *hostname; /* Real host to connect. */ + char *expand_host; /* Possible additional hostname to use in matching. */ char *host_key_alias; /* hostname alias for .ssh/known_hosts */ char *proxy_command; /* Proxy command for connecting the host. */ char *user; /* User to log in as. */ Index: usr.bin/ssh/readconf.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/readconf.c,v retrieving revision 1.197 diff -u -r1.197 readconf.c --- usr.bin/ssh/readconf.c 6 Mar 2013 23:36:53 -0000 1.197 +++ usr.bin/ssh/readconf.c 3 May 2013 02:27:36 -0000 @@ -128,7 +128,7 @@ oAddressFamily, oGssAuthentication, oGssDelegateCreds, oServerAliveInterval, oServerAliveCountMax, oIdentitiesOnly, oSendEnv, oControlPath, oControlMaster, oControlPersist, - oHashKnownHosts, + oHashKnownHosts, oExpandHost, oTunnel, oTunnelDevice, oLocalCommand, oPermitLocalCommand, oVisualHostKey, oUseRoaming, oZeroKnowledgePasswordAuthentication, oKexAlgorithms, oIPQoS, oRequestTTY, @@ -177,6 +177,7 @@ { "identityfile2", oIdentityFile }, /* obsolete */ { "identitiesonly", oIdentitiesOnly }, { "hostname", oHostName }, + { "expandhost", oExpandHost }, { "hostkeyalias", oHostKeyAlias }, { "proxycommand", oProxyCommand }, { "port", oPort }, @@ -647,6 +648,16 @@ charptr = &options->hostname; goto parse_string; + case oExpandHost: + charptr = &options->expand_host; + arg = strdelim(&s); + if (!arg || *arg == '\0') + fatal("%.200s line %d: Missing argument.", + filename, linenum); + if (*activep && *charptr == NULL) + *charptr = percent_expand(arg, "h", host, (char *)NULL); + break; + case oHostKeyAlias: charptr = &options->host_key_alias; goto parse_string; @@ -823,7 +834,9 @@ negated = *arg == '!'; if (negated) arg++; - if (match_pattern(host, arg)) { + if (match_pattern(host, arg) || + (options->expand_host && + match_pattern(options->expand_host, arg))) { if (negated) { debug("%.200s line %d: Skipping Host " "block because of negated match " @@ -1179,6 +1192,7 @@ options->protocol = SSH_PROTO_UNKNOWN; options->num_identity_files = 0; options->hostname = NULL; + options->expand_host = NULL; options->host_key_alias = NULL; options->proxy_command = NULL; options->user = NULL; Index: usr.bin/ssh/ssh.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/ssh.c,v retrieving revision 1.377 diff -u -r1.377 ssh.c --- usr.bin/ssh/ssh.c 19 Apr 2013 11:10:18 -0000 1.377 +++ usr.bin/ssh/ssh.c 3 May 2013 02:27:37 -0000 @@ -729,8 +729,13 @@ /* preserve host name given on command line for %n expansion */ host_arg = host; if (options.hostname != NULL) { - host = percent_expand(options.hostname, - "h", host, (char *)NULL); + if (options.expand_host != NULL) { + host = percent_expand(options.hostname, + "h", host, "e", options.expand_host, (char *)NULL); + } else { + host = percent_expand(options.hostname, + "h", host, (char *)NULL); + } } if (gethostname(thishost, sizeof(thishost)) == -1) Index: usr.bin/ssh/ssh_config.5 =================================================================== RCS file: /cvs/src/usr.bin/ssh/ssh_config.5,v retrieving revision 1.161 diff -u -r1.161 ssh_config.5 --- usr.bin/ssh/ssh_config.5 8 Jan 2013 18:49:04 -0000 1.161 +++ usr.bin/ssh/ssh_config.5 3 May 2013 02:27:39 -0000 @@ -1,4 +1,4 @@ -.\" +\" .\" Author: Tatu Ylonen .\" Copyright (c) 1995 Tatu Ylonen , Espoo, Finland .\" All rights reserved @@ -65,7 +65,10 @@ .Dq Host specifications, and that section is only applied for hosts that match one of the patterns given in the specification. -The matched host name is the one given on the command line. +The matched host name is the one given on the command line, +and additionally the value of the +.Dq ExpandHost +configuration option once set. .Pp Since the first obtained value for each parameter is used, more host-specific declarations should be given near the beginning of the @@ -111,6 +114,9 @@ .Ar hostname argument given on the command line (i.e. the name is not converted to a canonicalized host name before matching). +If the +.Cm ExpandHost +option has been set, its value is also matched against the patterns. .Pp A pattern entry may be negated by prefixing it with an exclamation mark .Pq Sq !\& . @@ -434,6 +440,13 @@ .Dq no . The default is .Dq no . +.It Cm ExpandHost +Specifies an additional string to match against any subsequent +.Cm Host +stanza's patterns. +If the specification contains the character sequence +.Ql %h , +then this will be replaced with the host name specified on the command line. .It Cm ForwardAgent Specifies whether the connection to the authentication agent (if any) will be forwarded to the remote machine. @@ -593,6 +606,11 @@ .Ql %h , then this will be replaced with the host name specified on the command line (this is useful for manipulating unqualified names). +If it contains the character sequence +.Ql %e , +then this will be replaced with the value of the +.Cm ExpandHost +specification, which must have been set. The default is the name given on the command line. Numeric IP addresses are also permitted (both on the command line and in .Cm HostName From rak at debian.org Fri May 3 13:07:37 2013 From: rak at debian.org (Ryan Kavanagh) Date: Thu, 2 May 2013 23:07:37 -0400 Subject: [PATCH] Allow matching HostName against Host entries In-Reply-To: <20130503023215.GF6176@nu.ryanak.ca> References: <20130408162521.GA21308@nu.ryanak.ca> <20835.27221.466113.996877@nu.ryanak.ca> <20130409190042.GA8305@linux124.nas.nasa.gov> <20836.29337.739297.965797@nu.ryanak.ca> <0353A032-09F8-4AB7-A928-E03D1D4CCA21@offwriting.org> <20130411050606.GB13960@apb-laptoy.apb.alt.za> <516ABD52.3040107@gmail.com> <20845.29648.741327.384137@nu.ryanak.ca> <20130503023215.GF6176@nu.ryanak.ca> Message-ID: <20130503030737.GG6176@nu.ryanak.ca> Sorry, a typo crept in to the final diff while I was revising it, On Thu, May 02, 2013 at 10:32:15PM -0400, Ryan Kavanagh wrote: > --- usr.bin/ssh/ssh_config.5 8 Jan 2013 18:49:04 -0000 1.161 > +++ usr.bin/ssh/ssh_config.5 3 May 2013 02:27:39 -0000 > @@ -1,4 +1,4 @@ > -.\" > +\" > .\" Author: Tatu Ylonen Here ^^ The updated ssh_config.5 patch is inlined below. A complete patch can be retrieved from http://athena.caslab.queensu.ca/~ryan/ssh_expandhost.diff Best wishes, Ryan -- |_)|_/ Ryan Kavanagh | Debian Developer | \| \ http://ryanak.ca/ | GPG Key 4A11C97A Index: usr.bin/ssh/ssh_config.5 =================================================================== RCS file: /cvs/src/usr.bin/ssh/ssh_config.5,v retrieving revision 1.161 diff -u -r1.161 ssh_config.5 --- usr.bin/ssh/ssh_config.5 8 Jan 2013 18:49:04 -0000 1.161 +++ usr.bin/ssh/ssh_config.5 3 May 2013 03:02:50 -0000 @@ -65,7 +65,10 @@ .Dq Host specifications, and that section is only applied for hosts that match one of the patterns given in the specification. -The matched host name is the one given on the command line. +The matched host name is the one given on the command line, +and additionally the value of the +.Dq ExpandHost +configuration option once set. .Pp Since the first obtained value for each parameter is used, more host-specific declarations should be given near the beginning of the @@ -111,6 +114,9 @@ .Ar hostname argument given on the command line (i.e. the name is not converted to a canonicalized host name before matching). +If the +.Cm ExpandHost +option has been set, its value is also matched against the patterns. .Pp A pattern entry may be negated by prefixing it with an exclamation mark .Pq Sq !\& . @@ -434,6 +440,13 @@ .Dq no . The default is .Dq no . +.It Cm ExpandHost +Specifies an additional string to match against any subsequent +.Cm Host +stanza's patterns. +If the specification contains the character sequence +.Ql %h , +then this will be replaced with the host name specified on the command line. .It Cm ForwardAgent Specifies whether the connection to the authentication agent (if any) will be forwarded to the remote machine. @@ -593,6 +606,11 @@ .Ql %h , then this will be replaced with the host name specified on the command line (this is useful for manipulating unqualified names). +If it contains the character sequence +.Ql %e , +then this will be replaced with the value of the +.Cm ExpandHost +specification, which must have been set. The default is the name given on the command line. Numeric IP addresses are also permitted (both on the command line and in .Cm HostName From graeme.wallace at farecompare.com Sat May 4 08:58:59 2013 From: graeme.wallace at farecompare.com (Graeme Wallace) Date: Fri, 3 May 2013 17:58:59 -0500 Subject: Debugging SFTP question Message-ID: I'm using the openssh that comes with Ubuntu 12.04 so thats 5.9p1 I'm trying to debug why i'm getting corrupt bzip2 files when they are transferred using sftp. The corruption doesnt happen on every file. I'm running debug mode on sftp-server, but when doing that i see output like the following for both valid and corrupt files, May 3 18:50:55 ftp-new sftp-server[16955]: debug3: request 1470: sent status 0 May 3 18:50:55 ftp-new sftp-server[16955]: sent status Success May 3 18:50:55 ftp-new sftp-server[16955]: debug1: request 1471: write "/home/travelport2/OTH_ALL_20130503_2247_V3.part" (handle 0) off 48103424 len 32768 May 3 18:50:55 ftp-new sftp-server[16955]: debug3: request 1471: sent status 0 May 3 18:50:55 ftp-new sftp-server[16955]: sent status Success May 3 18:50:55 ftp-new sftp-server[16955]: debug1: request 1472: write "/home/travelport2/OTH_ALL_20130503_2247_V3.part" (handle 0) off 48136192 len 32768 May 3 18:50:55 ftp-new sftp-server[16955]: debug3: request 1472: sent status 0 May 3 18:51:01 ftp-new sftp-server[16955]: debug1: request 3383: write "/home/travelport2/OTH_ALL_20130503_2247_V3.part" (handle 0) off 110755840 len 32768 May 3 18:51:01 ftp-new sftp-server[16955]: debug3: request 3383: sent status 0 May 3 18:51:01 ftp-new sftp-server[16955]: sent status Success May 3 18:51:01 ftp-new sftp-server[16955]: debug1: request 3384: write "/home/travelport2/OTH_ALL_20130503_2247_V3.part" (handle 0) off 110788608 len 32768 May 3 18:51:01 ftp-new sftp-server[16955]: debug3: request 3384: sent status 0 May 3 18:51:01 ftp-new sftp-server[16955]: sent status Success May 3 18:51:01 ftp-new sftp-server[16955]: debug1: request 3385: write "/home/travelport2/OTH_ALL_20130503_2247_V3.part" (handle 0) off 110821376 len 32768 Is it normal for request numbers and offsets to suddenly jump massively ? >From looking at the code, it would seem the server is merely responding to the request from the client, but I dont understand what would make the client 'skip' from offset 48136192 to offset 110755840 and from request 1472 to 3383 - as the client code looks like its just it plods through the file. Is this just a red herring ? -- Graeme Wallace CTO FareCompare.com O: 972 588 1414 M: 214 681 9018 From christian.heinrich at cmlh.id.au Sat May 4 11:33:18 2013 From: christian.heinrich at cmlh.id.au (Christian Heinrich) Date: Sat, 4 May 2013 11:33:18 +1000 Subject: Debugging SFTP question In-Reply-To: References: Message-ID: Graeme, I have encountered a similar issue before i.e. https://speakerdeck.com/cmlh/ssh Is the SSH client different from the OpenSSH server i.e. Ubuntu 12.04? Are the bzip2 files created on a different host to that of the SSH client? Also, is the 32-bit CRC calculated by bzip2 different before and after it is transferred? I would recommend that you also calculate the hash of the bzip2 file using http://www.openssl.org/docs/apps/dgst.html or similar. On Sat, May 4, 2013 at 8:58 AM, Graeme Wallace < graeme.wallace at farecompare.com> wrote: > I'm using the openssh that comes with Ubuntu 12.04 so thats 5.9p1 > > I'm trying to debug why i'm getting corrupt bzip2 files when they are > transferred using sftp. The corruption doesnt happen on every file. I'm > running debug mode on sftp-server, but when doing that i see output like > the following for both valid and corrupt files, > > > May 3 18:50:55 ftp-new sftp-server[16955]: debug3: request 1470: sent > status 0 > May 3 18:50:55 ftp-new sftp-server[16955]: sent status Success > May 3 18:50:55 ftp-new sftp-server[16955]: debug1: request 1471: write > "/home/travelport2/OTH_ALL_20130503_2247_V3.part" (handle 0) off 48103424 > len 32768 > May 3 18:50:55 ftp-new sftp-server[16955]: debug3: request 1471: sent > status 0 > May 3 18:50:55 ftp-new sftp-server[16955]: sent status Success > May 3 18:50:55 ftp-new sftp-server[16955]: debug1: request 1472: write > "/home/travelport2/OTH_ALL_20130503_2247_V3.part" (handle 0) off 48136192 > len 32768 > May 3 18:50:55 ftp-new sftp-server[16955]: debug3: request 1472: sent > status 0 > May 3 18:51:01 ftp-new sftp-server[16955]: debug1: request 3383: write > "/home/travelport2/OTH_ALL_20130503_2247_V3.part" (handle 0) off 110755840 > len 32768 > May 3 18:51:01 ftp-new sftp-server[16955]: debug3: request 3383: sent > status 0 > May 3 18:51:01 ftp-new sftp-server[16955]: sent status Success > May 3 18:51:01 ftp-new sftp-server[16955]: debug1: request 3384: write > "/home/travelport2/OTH_ALL_20130503_2247_V3.part" (handle 0) off 110788608 > len 32768 > May 3 18:51:01 ftp-new sftp-server[16955]: debug3: request 3384: sent > status 0 > May 3 18:51:01 ftp-new sftp-server[16955]: sent status Success > May 3 18:51:01 ftp-new sftp-server[16955]: debug1: request 3385: write > "/home/travelport2/OTH_ALL_20130503_2247_V3.part" (handle 0) off 110821376 > len 32768 > > > Is it normal for request numbers and offsets to suddenly jump massively ? > From looking at the code, it would seem the server is merely responding to > the request from the client, but I dont understand what would make the > client 'skip' from offset 48136192 to offset 110755840 and from request > 1472 to 3383 - as the client code looks like its just it plods through the > file. > > Is this just a red herring ? > > -- > Graeme Wallace > CTO > FareCompare.com > O: 972 588 1414 > M: 214 681 9018 > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Regards, Christian Heinrich http://cmlh.id.au/contact From djm at mindrot.org Sun May 5 22:14:07 2013 From: djm at mindrot.org (Damien Miller) Date: Sun, 5 May 2013 22:14:07 +1000 (EST) Subject: Debugging SFTP question In-Reply-To: References: Message-ID: On Fri, 3 May 2013, Graeme Wallace wrote: > I'm using the openssh that comes with Ubuntu 12.04 so thats 5.9p1 > > I'm trying to debug why i'm getting corrupt bzip2 files when they are > transferred using sftp. The corruption doesnt happen on every file. I'm > running debug mode on sftp-server, but when doing that i see output like > the following for both valid and corrupt files, It looks like the client is doing something wrong. Is the client OpenSSH? If so, can you capture a trace from it? -d From dtucker at zip.com.au Sun May 5 23:15:50 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 5 May 2013 23:15:50 +1000 Subject: Debugging SFTP question In-Reply-To: References: Message-ID: <20130505131550.GB22609@gate.dtucker.net> On Fri, May 03, 2013 at 05:58:59PM -0500, Graeme Wallace wrote: > Is it normal for request numbers and offsets to suddenly jump massively ? The client doesn't happen to be sshfs does it? If so the offset jump might be the client writing a sparse file. -- 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 graeme.wallace at farecompare.com Sun May 5 23:29:41 2013 From: graeme.wallace at farecompare.com (Graeme Wallace) Date: Sun, 5 May 2013 08:29:41 -0500 Subject: Debugging SFTP question In-Reply-To: <20130505131550.GB22609@gate.dtucker.net> References: <20130505131550.GB22609@gate.dtucker.net> Message-ID: The client is Axway Secure Transport. The files we are receiving are from a vendor so I don't have any control over the client side unfortunately. The file shouldnt be sparse as its a bzipped ASCII file. I've also downloaded the bzip source and dumped out the offset at which its corrupt, and it doesnt correspond to the offset jumps. (I'm still confused about whats going on there) If i look at the debug logs from sftpd, the 32K packet that contains the corrupt offset says it was received ok. What else can I check ? (The vendor assures me that they transmit files around using Axway all over the place without problems and its just our system....) regards Graeme On Sun, May 5, 2013 at 8:15 AM, Darren Tucker wrote: > On Fri, May 03, 2013 at 05:58:59PM -0500, Graeme Wallace wrote: > > Is it normal for request numbers and offsets to suddenly jump massively ? > > The client doesn't happen to be sshfs does it? If so the offset jump > might be the client writing a sparse file. > > -- > 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. > -- Graeme Wallace CTO FareCompare.com O: 972 588 1414 M: 214 681 9018 From dtucker at zip.com.au Mon May 6 00:12:27 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 6 May 2013 00:12:27 +1000 Subject: Debugging SFTP question In-Reply-To: References: <20130505131550.GB22609@gate.dtucker.net> Message-ID: <20130505141227.GA25100@gate.dtucker.net> On Sun, May 05, 2013 at 08:29:41AM -0500, Graeme Wallace wrote: > The client is Axway Secure Transport. The files we are receiving are from a > vendor so I don't have any control over the client side unfortunately. > > The file shouldnt be sparse as its a bzipped ASCII file. > > I've also downloaded the bzip source and dumped out the offset at which its > corrupt, and it doesnt correspond to the offset jumps. (I'm still confused > about whats going on there) > > If i look at the debug logs from sftpd, the 32K packet that contains the > corrupt offset says it was received ok. > > What else can I check ? (The vendor assures me that they transmit files > around using Axway all over the place without problems and its just our Without knowing what the client is doing it's kinda hard to say. I think we'll need to see a complete debug trace. Does the client upload the file with a .part extension then rename it when it's done? I could imagine some kind of race where the rename happens before the last write. In that case I'd imagine the file differences would be at the last offset sent. Other possible variables: what filesystem is sftp-server writing to? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Mon May 6 11:12:11 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 6 May 2013 11:12:11 +1000 Subject: Debugging SFTP question In-Reply-To: References: <20130505131550.GB22609@gate.dtucker.net> <20130505141227.GA25100@gate.dtucker.net> Message-ID: <20130506011211.GA5626@gate.dtucker.net> On Sun, May 05, 2013 at 01:39:06PM -0500, Graeme Wallace wrote: > Corruption occurs early in the file. Filesystem is ext4 on Ubuntu 12.04. > I've attached the transfer log at DEBUG3. I notice the log does not show the file being closed. Is that really the case or is it just missing from the log? In theory it could be an error when the file is flushed to disk, and that wouldn't be detected because of the missing close, but that seems pretty unlikely. Looking at the server log I see huge chunks of the file missing. I ran the perl script below over the log and got: chunks written: 0-2097152 41910272-44105728 95027200-97222656 120356864-122552320 156434432-158629888 193921024-196116480 237043712-239239168 269942784-272138240 the non-contiguous portions are suspiciously regular, and they correspond to the jumps in the request numbers (the latter is not necessarily a problem but the former probably is). My guess is that the client is multithreaded, doing multiple concurrent writes and is mixing up the increments of both the request numbers and offsets. How big is the file supposed to be? Based on the number of packets I'd guess about 17M, but the client seems to be creating a sparse file about 260M in size (compare the sizes reported by ls -l and du). while (<>) { unless (/off (\d+) len (\d+)/) { next; } $off = $1; $len = $2; #print "off $off len $len\n"; if (!defined($start)) { $start = $off; $end = $len; } elsif ($off == $end) { $end = $off + $len; } else { print "non-contig write at $off $len\n"; $chunks = "$chunks $start-$end"; $start = $off; $end = $off + $len; } } $chunks = "$chunks $start-$end"; print "chunks written: $chunks\n" -- 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 graeme.wallace at farecompare.com Mon May 6 12:33:09 2013 From: graeme.wallace at farecompare.com (Graeme Wallace) Date: Sun, 5 May 2013 21:33:09 -0500 Subject: Debugging SFTP question In-Reply-To: <20130506011211.GA5626@gate.dtucker.net> References: <20130505131550.GB22609@gate.dtucker.net> <20130505141227.GA25100@gate.dtucker.net> <20130506011211.GA5626@gate.dtucker.net> Message-ID: I've no idea how big the files are supposed to be - as they've always shown up at around the 260Mb size. As far as the close being missing - i didnt remove anything from the logs - and the code looks like it should log at DEBUG3 - so i guess the client doesnt call close directly. However, even the implicit close in the code from a client disconnect looks like it should log the close on the handle...... regards, Graeme On Sun, May 5, 2013 at 8:12 PM, Darren Tucker wrote: > On Sun, May 05, 2013 at 01:39:06PM -0500, Graeme Wallace wrote: > > Corruption occurs early in the file. Filesystem is ext4 on Ubuntu 12.04. > > I've attached the transfer log at DEBUG3. > > I notice the log does not show the file being closed. Is that really > the case or is it just missing from the log? In theory it could be an > error when the file is flushed to disk, and that wouldn't be detected > because of the missing close, but that seems pretty unlikely. > > Looking at the server log I see huge chunks of the file missing. I ran > the perl script below over the log and got: > > chunks written: 0-2097152 41910272-44105728 95027200-97222656 > 120356864-122552320 156434432-158629888 193921024-196116480 > 237043712-239239168 269942784-272138240 > > the non-contiguous portions are suspiciously regular, and they > correspond to the jumps in the request numbers (the latter is not > necessarily a problem but the former probably is). My guess is that the > client is multithreaded, doing multiple concurrent writes and is mixing > up the increments of both the request numbers and offsets. > > How big is the file supposed to be? Based on the number of packets I'd > guess about 17M, but the client seems to be creating a sparse file about > 260M in size (compare the sizes reported by ls -l and du). > > while (<>) { > unless (/off (\d+) len (\d+)/) { next; } > $off = $1; $len = $2; > #print "off $off len $len\n"; > if (!defined($start)) { > $start = $off; > $end = $len; > } elsif ($off == $end) { > $end = $off + $len; > } else { > print "non-contig write at $off $len\n"; > $chunks = "$chunks $start-$end"; > $start = $off; > $end = $off + $len; > } > } > $chunks = "$chunks $start-$end"; > > print "chunks written: $chunks\n" > > -- > 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. > -- Graeme Wallace CTO FareCompare.com O: 972 588 1414 M: 214 681 9018 From dtucker at zip.com.au Mon May 6 12:44:31 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 6 May 2013 12:44:31 +1000 Subject: Debugging SFTP question In-Reply-To: References: <20130505131550.GB22609@gate.dtucker.net> <20130505141227.GA25100@gate.dtucker.net> <20130506011211.GA5626@gate.dtucker.net> Message-ID: <20130506024431.GA9365@gate.dtucker.net> On Sun, May 05, 2013 at 09:33:09PM -0500, Graeme Wallace wrote: > I've no idea how big the files are supposed to be - as they've always shown > up at around the 260Mb size. That'd be what ls -l shows. What does du -k show? My be is it'll be a lot less. -- 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 des at des.no Tue May 7 16:42:05 2013 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Tue, 07 May 2013 08:42:05 +0200 Subject: "no such identity" In-Reply-To: <86txmx7m5p.fsf@ds4.des.no> ("Dag-Erling =?utf-8?Q?Sm=C3=B8rg?= =?utf-8?Q?rav=22's?= message of "Tue, 23 Apr 2013 09:15:30 +0200") References: <86hajqpdpz.fsf@ds4.des.no> <20130401172251.GB47549@juniper.net> <20130402120840.GA29590@calimero.vinschen.de> <20130402131500.GA29515@gate.dtucker.net> <20130402132655.GA18060@calimero.vinschen.de> <20130404234952.GA28615@gate.dtucker.net> <86txmx7m5p.fsf@ds4.des.no> Message-ID: <86mws7guki.fsf@nine.des.no> Dag-Erling Sm?rgrav writes: > Darren Tucker writes: > > [...] so we'll do a 6.2p2 in probably a couple of weeks [...] > Any ETA on p2? Ping DES -- Dag-Erling Sm?rgrav - des at des.no From jonathan at pauliwerks.com Tue May 7 21:56:49 2013 From: jonathan at pauliwerks.com (Jonathan Pauli) Date: Tue, 07 May 2013 11:56:49 -0000 Subject: FW: Message-ID: <20130507115630.C31FB5E060@homiemail-a83.g.dreamhost.com> http://www.canal16.com.br/z3dius.php From zhenbo1987 at gmail.com Wed May 8 01:44:02 2013 From: zhenbo1987 at gmail.com (Zhenbo Xu) Date: Tue, 7 May 2013 23:44:02 +0800 Subject: Some potential bugs in Openssh-6.2p1 Message-ID: Hi, I'm a developer of a static analysis tool canalyze. Recently I applied it to Openssh-6.2p1. It seems some reports are real after by manually checking: 1. Use undefined value file: dispatch.c function: dispatch_run At line 93: type = packet_read_poll_seqnr(&seqnr); seqnr may not be override at file: packet.c function: packet_read_poll_seqnr line 1442 where compat20 is 0. 2. Null Pointer file: session.c function: child_set_env At line 962: if (*envp == NULL && *envsizep == 0) Is it possible that *envp == NULL while *envsizep != 0? If it is feasible, null pointer dereference would occur At line 975: for (i = 0; env[i]; i++) env is null. 3. Null Pointer file: serverloop.c function: server_loop2 At line 853: rekeying = (xxx_kex != NULL && !xxx_kex->done); xxx_key may be null. At line 871: xxx_kex->done = 0; directly use xxx_key. 4. Null Pointer file: sftp.c function: parse_args At line 1143: for (i = 0; cmds[i].c != NULL; i++) { Could this loop breaks when cmds[i].c is null? if so At line 1148: cmd = cmds[i].c; cmd is null, which is passed to strlen at line 1237. 5. Use after free file: uidswap.c function: temporarily_use_uid At line 113: xfree(user_groups); user_groups is freed and is used at line 117: if (setgroups(user_groupslen, user_groups) < 0) as a function argument. 6. Use After free file: monitor.c function: At line 1219: debug3("%s: key %p is %s", __func__, key, allowed ? "allowed" : "not allowed"); in which key is release at line 1198: key_free(key); Hope for your replies! Regards, -- Zhenbo Xu From kspillner at acm.org Wed May 8 04:12:19 2013 From: kspillner at acm.org (Kent R. Spillner) Date: Tue, 7 May 2013 13:12:19 -0500 (CDT) Subject: SSH key exchange algorithm negotiation payload growth Message-ID: <1367950339.7330437@apps.rackspace.com> Howdy- TL;DR An SSH daemon for a memory-constrained embedded platform didn't work with a recent OpenSSH client because it couldn't handle the payload size during key exchange. In general, what should SSH implementors in such limited environments do to ensure forwards compatibility with future OpenSSH releases? I am unable to SSH to any of my HP servers' iLO2 interfaces using OpenSSH 6.2p1. My particular problem looked similar to earlier compatibility problems between OpenSSH and mpSSH, the iLO2 SSH daemon, e.g. http://marc.info/?l=openssh-unix-dev&m=130574789103948&w=2, but unfortunately the suggested work-arounds didn't work in my case. I reported the issue to HP (http://h30499.www3.hp.com/t5/ITRC-Remote-Lights-Out-Mgmt-iLO/Unable-to-SSH-to-iLO2-with-OpenSSH-6-2/td-p/6050925) and it appears they fixed the problem for a future release of iLO2: http://h30499.www3.hp.com/t5/ITRC-Remote-Lights-Out-Mgmt-iLO/Unable-to-SSH-to-iLO2-with-OpenSSH-6-2/m-p/6055771#M7322 I'm curious, though, how other embedded SSH implementors maintain forwards compatibility with future releases of OpenSSH. Am I correct in reading RFC 4253 sections 6.2 - 6.5 and section 7.1 as saying that implementations must be prepared to accept an arbitrary number of algorithms of each type during initial key exchange? When I was troubleshooting this issue I tried playing around with different combinations of -o KexAlgorithms and -o HostKeyAlgorithms at the command line. Are there other configuration paramters for the other name-lists during algorithm negotiation, e.g. encryption_algorithms_client_to_server, compression_algorithms_server_to_client, etc? Thanks in advance! Best, Kent From peter at stuge.se Wed May 8 04:43:58 2013 From: peter at stuge.se (Peter Stuge) Date: Tue, 7 May 2013 20:43:58 +0200 Subject: SSH key exchange algorithm negotiation payload growth In-Reply-To: <1367950339.7330437@apps.rackspace.com> References: <1367950339.7330437@apps.rackspace.com> Message-ID: <20130507184358.4136.qmail@stuge.se> Kent R. Spillner wrote: > I'm curious, though, how other embedded SSH implementors maintain > forwards compatibility More clever parsing of incoming packets, I guess? > Are there other configuration paramters for the other name-lists > during algorithm negotiation, e.g. > encryption_algorithms_client_to_server, > compression_algorithms_server_to_client, etc? See Ciphers and Compression in man ssh_config and man sshd_config. //Peter From djm at mindrot.org Wed May 8 10:23:03 2013 From: djm at mindrot.org (Damien Miller) Date: Wed, 8 May 2013 10:23:03 +1000 (EST) Subject: "no such identity" In-Reply-To: <86mws7guki.fsf@nine.des.no> References: <86hajqpdpz.fsf@ds4.des.no> <20130401172251.GB47549@juniper.net> <20130402120840.GA29590@calimero.vinschen.de> <20130402131500.GA29515@gate.dtucker.net> <20130402132655.GA18060@calimero.vinschen.de> <20130404234952.GA28615@gate.dtucker.net> <86txmx7m5p.fsf@ds4.des.no> <86mws7guki.fsf@nine.des.no> Message-ID: On Tue, 7 May 2013, Dag-Erling Sm?rgrav wrote: > Dag-Erling Sm?rgrav writes: > > Darren Tucker writes: > > > [...] so we'll do a 6.2p2 in probably a couple of weeks [...] > > Any ETA on p2? > > Ping Darren and I wanted to see if anything else came up before rushing a release out, and then Other Stuff has prevented me from looking at it for the last couple of weeks. I think it is 99.5% likely that what is on the V_6_2 branch now (post the V_6_2_P1 tag) will be the 6.2p2 release. -d From djm at mindrot.org Wed May 8 10:37:48 2013 From: djm at mindrot.org (Damien Miller) Date: Wed, 8 May 2013 10:37:48 +1000 (EST) Subject: SSH key exchange algorithm negotiation payload growth In-Reply-To: <1367950339.7330437@apps.rackspace.com> References: <1367950339.7330437@apps.rackspace.com> Message-ID: On Tue, 7 May 2013, Kent R. Spillner wrote: > Howdy- > > TL;DR > > An SSH daemon for a memory-constrained embedded platform didn't work > with a recent OpenSSH client because it couldn't handle the payload > size during key exchange. In general, what should SSH implementors in > such limited environments do to ensure forwards compatibility with > future OpenSSH releases? Not assume fixed size buffers will always fit proposal strings :) The maximum likely size of a KEXINIT packet is always going to be smaller than the 32KB minimum payload length required by RFC4253. > I'm curious, though, how other embedded SSH implementors maintain > forwards compatibility with future releases of OpenSSH. Am I correct > in reading RFC 4253 sections 6.2 - 6.5 and section 7.1 as saying that > implementations must be prepared to accept an arbitrary number of > algorithms of each type during initial key exchange? Up to the 32KB packet size required in section 6.1. > When I was troubleshooting this issue I tried playing around > with different combinations of -o KexAlgorithms and -o > HostKeyAlgorithms at the command line. Are there other > configuration paramters for the other name-lists during algorithm > negotiation, e.g. encryption_algorithms_client_to_server, > compression_algorithms_server_to_client, etc? The options that select the contents of the KEXINIT packet are: Ciphers MACs Compression HostKeyAlgorithms KexAlgorithms If you ever encounter a broken implementation that chokes on something in the KEXINIT packet, you can use one (or all) of these to remove the offending morsel. -d From g.liakhovetski at gmx.de Fri May 10 02:23:24 2013 From: g.liakhovetski at gmx.de (Guennadi Liakhovetski) Date: Thu, 9 May 2013 18:23:24 +0200 (CEST) Subject: ssh ethernet tunnel performance problem Message-ID: Hi (I'm not subscribed, please, cc) I've got an ethernet level ssh tunnel to a remote system. That system is running a terminal server, so, that tunnel is the only connection, I've got. The terminal server is connected via a serial and an ethernet cable to a test board and is configured to bridge that ethernet connection to my tunnel. I can then trigger that test board to start a TFTP or NFS data transfer over the tunnel from my system. The whole should look like this: [my client] --- --- [terminal] === === [test ] [ server ] ----- ----- [board] (whereas I don't know whether the terminal server actually has 2 ethernet interfaces or only 1. I think, it should really have 2 at least, because actually it's serving 8 test boards, I'll try to clarify its configuration and post an update) This works in principle, and from a "geographically close" location also runs reasonably quickly. Whereas from my half-world distance I'm getting like 1.5kBps tftp and a bit more with NFS. The person, who's set up the server says, that he previously also had performance problems with an older Fedora distro, but with Fedora 18 it runs fast now. I've tried with Debian squeeze with a self-build 3.9.1 and (about 1-2 year old) Ubuntu both over my and a 3G connection - the speed remains the same. Any clues? Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ From dtucker at zip.com.au Fri May 10 09:31:13 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 10 May 2013 09:31:13 +1000 Subject: ssh ethernet tunnel performance problem In-Reply-To: References: Message-ID: <20130509233113.GA17515@gate.dtucker.net> On Thu, May 09, 2013 at 06:23:24PM +0200, Guennadi Liakhovetski wrote: > Hi > > (I'm not subscribed, please, cc) > > I've got an ethernet level ssh tunnel to a remote system. That system is > running a terminal server, so, that tunnel is the only connection, I've > got. The terminal server is connected via a serial and an ethernet cable > to a test board and is configured to bridge that ethernet connection to my > tunnel. I can then trigger that test board to start a TFTP or NFS data > transfer over the tunnel from my system. The whole should look like this: > > [my client] --- --- [terminal] === === [test ] > [ server ] ----- ----- [board] > > (whereas I don't know whether the terminal server actually has 2 ethernet > interfaces or only 1. I think, it should really have 2 at least, because > actually it's serving 8 test boards, I'll try to clarify its > configuration and post an update) > > This works in principle, and from a "geographically close" location also > runs reasonably quickly. Whereas from my half-world distance I'm getting > like 1.5kBps tftp and a bit more with NFS. Based on the version and presumably latency I'd guess the reason is the small default channel window size in older versions of OpenSSH. You fill the channel window up and since you have a high-latency are then blocked until it drains. That'd explain why it works ok when you're close. The channel window size used to be (I think) 64k but was changed to 2M several years ago. You can check this by running ssh -vvv and look for this: debug2: channel 0: rcvd adjust 2097152 (You should also see the same thing on the server side) > The person, who's set up the > server says, that he previously also had performance problems with an > older Fedora distro, but with Fedora 18 it runs fast now. I've tried with > Debian squeeze with a self-build 3.9.1 and (about 1-2 year old) Ubuntu You mean OpenSSH 3.9p1? That's pretty old and before the channel window changes. Can you reproduce the problem with a current version (6.2p1?) -- 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 vintobe at gmail.com Fri May 10 12:44:59 2013 From: vintobe at gmail.com (Vincent Lin) Date: Fri, 10 May 2013 10:44:59 +0800 Subject: how to check whether the ssh tunnel is up In-Reply-To: <517BF349.8090004@fifthhorseman.net> References: <517B6EBA.2090903@fifthhorseman.net> <517BF349.8090004@fifthhorseman.net> Message-ID: Hi Daniel, I have an idea. If we get the ssh process ID, then we can check the local socket . Once the socket is established, the tunnel is OK. For example, ssh [...] -R 20001:localhost:22 We can check the socket that is used by specific ssh process. If the Foreign Address is localhost:22 and state is ESTABLISH, the tunnel is up. What do you think? Best Regard Vincent On Sat, Apr 27, 2013 at 11:48 PM, Daniel Kahn Gillmor wrote: > On 04/27/2013 07:47 PM, Vincent Lin wrote: > > > Is it the only way to check the tunnel on the remote server side? How > about > > on the local client side? > > the tunnel you're specifying is: > > ssh [...] -R 20001:localhost:22 > > this means that sshd (on the remote machine) will listen on remote port > 20001. if a request comes in, then sshd will call across the > established ssh connection to ask ssh (on the local machine) to create a > connection to localhost:22. I don't see a way to examine this situation > from the client side, since the local side hasn't done anything yet. > But maybe i'm missing something, and someone more knowledgable might be > able to suggest an approach i'm missing. (e.g. see the autossh idea > mentioned elsewhere in this thread) > > regards, > > -dkg > > From g.liakhovetski at gmx.de Fri May 10 15:35:09 2013 From: g.liakhovetski at gmx.de (Guennadi Liakhovetski) Date: Fri, 10 May 2013 07:35:09 +0200 (CEST) Subject: ssh ethernet tunnel performance problem In-Reply-To: <20130509233113.GA17515@gate.dtucker.net> References: <20130509233113.GA17515@gate.dtucker.net> Message-ID: Hi Darren Thanks for your reply. On Fri, 10 May 2013, Darren Tucker wrote: > On Thu, May 09, 2013 at 06:23:24PM +0200, Guennadi Liakhovetski wrote: > > Hi > > > > (I'm not subscribed, please, cc) > > > > I've got an ethernet level ssh tunnel to a remote system. That system is > > running a terminal server, so, that tunnel is the only connection, I've > > got. The terminal server is connected via a serial and an ethernet cable > > to a test board and is configured to bridge that ethernet connection to my > > tunnel. I can then trigger that test board to start a TFTP or NFS data > > transfer over the tunnel from my system. The whole should look like this: > > > > [my client] --- --- [terminal] === === [test ] > > [ server ] ----- ----- [board] > > > > (whereas I don't know whether the terminal server actually has 2 ethernet > > interfaces or only 1. I think, it should really have 2 at least, because > > actually it's serving 8 test boards, I'll try to clarify its > > configuration and post an update) > > > > This works in principle, and from a "geographically close" location also > > runs reasonably quickly. Whereas from my half-world distance I'm getting > > like 1.5kBps tftp and a bit more with NFS. > > Based on the version and presumably latency I'd guess the reason is > the small default channel window size in older versions of OpenSSH. > You fill the channel window up and since you have a high-latency are > then blocked until it drains. That'd explain why it works ok when > you're close. > > The channel window size used to be (I think) 64k but was changed to > 2M several years ago. You can check this by running ssh -vvv and look > for this: > > debug2: channel 0: rcvd adjust 2097152 I see it on the client side, which is much older than the server, so, it should be ok on the server too. > (You should also see the same thing on the server side) > > > The person, who's set up the > > server says, that he previously also had performance problems with an > > older Fedora distro, but with Fedora 18 it runs fast now. I've tried with > > Debian squeeze with a self-build 3.9.1 and (about 1-2 year old) Ubuntu > > You mean OpenSSH 3.9p1? That's pretty old and before the channel window > changes. Can you reproduce the problem with a current version (6.2p1?) No, sorry, I meant Linux kernel 3.9.1 :) Do you think the problem can be somewhere below ssh - in the OS networking layer? Although I tested 3 OSes in the meantime, the latter one was Fedora 18 - the newest - with the same result. Thanks Guennadi --- Guennadi Liakhovetski, Ph.D. Freelance Open-Source Software Developer http://www.open-technology.de/ From djm at mindrot.org Fri May 10 16:19:52 2013 From: djm at mindrot.org (Damien Miller) Date: Fri, 10 May 2013 16:19:52 +1000 (EST) Subject: Candidate tarball for openssh-6.2p2 Message-ID: Hi, Here is a release candidate tarball for openssh-6.2p2: http://www.mindrot.org/openssh_snap/candidate-openssh-6.2p2.tar.gz http://www.mindrot.org/openssh_snap/candidate-openssh-6.2p2.tar.gz.asc This includes the following bugfixes (relative to 6.2p1): - (dtucker) [openbsd-compat/bsd-cygwin_util.{c,h}] Don't include windows.h to avoid conflicting definitions of __int64, adding the required bits. Patch from Corinna Vinschen. - djm at cvs.openbsd.org 2013/04/11 02:27:50 [packet.c] quiet disconnect notifications on the server from error() back to logit() if it is a normal client closure; bz#2057 ok+feedback dtucker@ - dtucker at cvs.openbsd.org 2013/02/17 23:16:57 [readconf.c ssh.c readconf.h sshconnect2.c] Keep track of which IndentityFile options were manually supplied and which were default options, and don't warn if the latter are missing. ok markus@ - dtucker at cvs.openbsd.org 2013/02/19 02:12:47 [krl.c] Remove bogus include. ok djm - dtucker at cvs.openbsd.org 2013/02/22 04:45:09 [ssh.c readconf.c readconf.h] Don't complain if IdentityFiles specified in system-wide configs are missing. ok djm, deraadt. - markus at cvs.openbsd.org 2013/02/22 19:13:56 [sshconnect.c] support ProxyCommand=- (stdin/out already point to the proxy); ok djm@ - djm at cvs.openbsd.org 2013/02/22 22:09:01 [ssh.c] Allow IdenityFile=none; ok markus deraadt (and dtucker for an earlier version) If there are no objections or demands for last-minute inclusion, I'll make a real 6.2p2 release next week. Damien From bob at proulx.com Fri May 10 16:38:32 2013 From: bob at proulx.com (Bob Proulx) Date: Fri, 10 May 2013 00:38:32 -0600 Subject: ssh ethernet tunnel performance problem In-Reply-To: <20130509233113.GA17515@gate.dtucker.net> References: <20130509233113.GA17515@gate.dtucker.net> Message-ID: <20130510063832.GB27182@hysteria.proulx.com> Darren Tucker wrote: > Guennadi Liakhovetski wrote: > > older Fedora distro, but with Fedora 18 it runs fast now. I've tried with > > Debian squeeze with a self-build 3.9.1 and (about 1-2 year old) Ubuntu > > You mean OpenSSH 3.9p1? That's pretty old and before the channel window > changes. Can you reproduce the problem with a current version (6.2p1?) Debian versions: Etch 4 -- 4.3p2 Lenny 5 -- 5.1p1 Squeeze 6 -- 5.5p1 Wheezy 7 -- 6.0p1 Sid today -- 6.2p1 Version 3.9.1 must be referring to something else. Hopefully. Bob From gert at greenie.muc.de Fri May 10 19:33:54 2013 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 10 May 2013 11:33:54 +0200 Subject: how to check whether the ssh tunnel is up In-Reply-To: References: <517B6EBA.2090903@fifthhorseman.net> <517BF349.8090004@fifthhorseman.net> Message-ID: <20130510093353.GB20843@greenie.muc.de> Hi, On Fri, May 10, 2013 at 10:44:59AM +0800, Vincent Lin wrote: > I have an idea. If we get the ssh process ID, then we can check the local > socket . Once the socket is established, the tunnel is OK. For example, > > ssh [...] -R 20001:localhost:22 > > We can check the socket that is used by specific ssh process. If the > Foreign Address is localhost:22 and state is ESTABLISH, the tunnel is up. > What do you think? This is not how it works. Unless someone actually connects to 20001 on the remote side, there is nothing on the local side that you could see in "netstat" gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From brindhait.2010 at gmail.com Mon May 13 23:10:16 2013 From: brindhait.2010 at gmail.com (brindha perumal) Date: Mon, 13 May 2013 18:40:16 +0530 Subject: Session rekeying support in OpenSSH Message-ID: Hi, I am using OpenSSH_5.2p1. It seems ssh server doesn't support key regeneration after a specified amount of time. I manually verified the OpenSSH_5.2p1 and OpenSSH-6.2 source codes and haven?t found any code support for session rekeying in both releases. SSH2 supports session rekeying using the parameter ?RekeyIntervalSeconds? with default value 3600 seconds (one hour) in both ssh2_config and sshd2_config files. I haven?t found similar parameter in both releases OpenSSH_5.2p1 and openssh-6.2 configuration files. Does openSSH not support session rekeying (rekeying after a specified amount of time)? If so, is there any alternative approach to achieve this behavior? Your prompt reply would be so helpful. Thanks, Brundha From dtucker at zip.com.au Mon May 13 23:40:43 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 13 May 2013 23:40:43 +1000 Subject: Session rekeying support in OpenSSH In-Reply-To: References: Message-ID: <20130513134043.GA21438@gate.dtucker.net> On Mon, May 13, 2013 at 06:40:16PM +0530, brindha perumal wrote: > Hi, > > I am using OpenSSH_5.2p1. It seems ssh server doesn't support key > regeneration after a specified amount of time. I manually verified the > OpenSSH_5.2p1 and OpenSSH-6.2 source codes and haven?t found any code > support for session rekeying in both releases. It can do rekeying based on the volume of data transmitted or manually via the ~R escape sequence but not based on the amount of time since last rekeying. > SSH2 supports session rekeying using the parameter ?RekeyIntervalSeconds? > with default value 3600 seconds (one hour) in both ssh2_config and > sshd2_config files. I haven?t found similar parameter in both releases > OpenSSH_5.2p1 and openssh-6.2 configuration files. > > Does openSSH not support session rekeying (rekeying after a specified > amount of time)? If so, is there any alternative approach to achieve this > behavior? You could combine a low RekeyLimit with ServerAliveInterval to ensure enough traffic gets generated to trigger it, but that would involve extra traffic. Looks like it wouldn't be hard to add, but what problem are you trying to solve? -- 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 kenneth.schmidt at pnnl.gov Tue May 14 02:22:13 2013 From: kenneth.schmidt at pnnl.gov (Schmidt, Kenneth P) Date: Mon, 13 May 2013 09:22:13 -0700 Subject: [PATCH] Specify PAM Service name in sshd_config Message-ID: Hello All, The attached patch allows openssh to specify which pam service name to authenticate users against by specifying the PAMServiceName attribute in the sshd_config file. Because the parameter can be included in the Match directive sections, it allows different authentication based on the Match directive. In our case, we use it to allow different levels of authentication based on the source of the authentication attempts (securID auth in untrusted zones, password auth in trusted zones). The default is still to use the binary name. ____________________________________________ Ken Schmidt Research Scientist, Molecular Science Computing Operations EMSL: Environmental Molecular Sciences Laboratory Pacific Northwest National Laboratory 902 Battelle Boulevard P.O. Box 999, MSIN K8-83 Richland, WA 99352 USA Tel: 509-371-6107 Fax: 509-371-6110 Kenneth.schmidt at pnnl.gov www.emsl.pnl.gov This material was prepared as an account of work sponsored by an agency of the United States Government. Neither the United States Government nor the United States Department of Energy, nor any of their employees, nor Battelle Memorial Institute nor any of its employees, makes any warranty, express or implied, or assumes any legal liability or responsibility for the accuracy, completeness, or usefulness or any information, apparatus, product, or process disclosed, or represents that its use would not infringe privately owned rights. From kenneth.schmidt at pnnl.gov Tue May 14 06:05:51 2013 From: kenneth.schmidt at pnnl.gov (Schmidt, Kenneth P) Date: Mon, 13 May 2013 13:05:51 -0700 Subject: [PATCH] Specify PAM Service name in sshd_config In-Reply-To: Message-ID: Seems as though somewhere along the way the attachment got stripped. Lets see if it makes it through this time. On 5/13/13 9:22 a.m., "Schmidt, Kenneth P" wrote: >Hello All, > >The attached patch allows openssh to specify which pam service name to >authenticate users against by specifying the PAMServiceName attribute in >the sshd_config file. Because the parameter can be included in the Match >directive sections, it allows different authentication based on the Match >directive. In our case, we use it to allow different levels of >authentication based on the source of the authentication attempts >(securID auth in untrusted zones, password auth in trusted zones). The >default is still to use the binary name. > >____________________________________________ >Ken Schmidt >Research Scientist, Molecular Science Computing Operations >EMSL: Environmental Molecular Sciences Laboratory > >Pacific Northwest National Laboratory >902 Battelle Boulevard >P.O. Box 999, MSIN K8-83 >Richland, WA 99352 USA >Tel: 509-371-6107 >Fax: 509-371-6110 >Kenneth.schmidt at pnnl.gov >www.emsl.pnl.gov > >This material was prepared as an account of work sponsored by an agency of >the United States Government. Neither the United States Government nor >the United States Department of Energy, nor any of their employees, nor >Battelle Memorial Institute nor any of its employees, makes any warranty, >express or implied, or assumes any legal liability or responsibility for >the accuracy, completeness, or usefulness or any information, apparatus, >product, or process disclosed, or represents that its use would not >infringe privately owned rights. From mouring at eviladmin.org Tue May 14 06:21:14 2013 From: mouring at eviladmin.org (Ben Lindstrom) Date: Mon, 13 May 2013 15:21:14 -0500 Subject: [PATCH] Specify PAM Service name in sshd_config In-Reply-To: References: Message-ID: Best to create a bug in the bugzilla ( https://bugzilla.mindrot.org/ ) as it will not be lost as easy as if it is just attached to a random email. - Ben On May 13, 2013, at 3:05 PM, "Schmidt, Kenneth P" wrote: > Seems as though somewhere along the way the attachment got stripped. Lets > see if it makes it through this time. > > On 5/13/13 9:22 a.m., "Schmidt, Kenneth P" > wrote: > >> Hello All, >> >> The attached patch allows openssh to specify which pam service name to >> authenticate users against by specifying the PAMServiceName attribute in >> the sshd_config file. Because the parameter can be included in the Match >> directive sections, it allows different authentication based on the Match >> directive. In our case, we use it to allow different levels of >> authentication based on the source of the authentication attempts >> (securID auth in untrusted zones, password auth in trusted zones). The >> default is still to use the binary name. >> >> ____________________________________________ >> Ken Schmidt >> Research Scientist, Molecular Science Computing Operations >> EMSL: Environmental Molecular Sciences Laboratory >> >> Pacific Northwest National Laboratory >> 902 Battelle Boulevard >> P.O. Box 999, MSIN K8-83 >> Richland, WA 99352 USA >> Tel: 509-371-6107 >> Fax: 509-371-6110 >> Kenneth.schmidt at pnnl.gov >> www.emsl.pnl.gov >> >> This material was prepared as an account of work sponsored by an agency of >> the United States Government. Neither the United States Government nor >> the United States Department of Energy, nor any of their employees, nor >> Battelle Memorial Institute nor any of its employees, makes any warranty, >> express or implied, or assumes any legal liability or responsibility for >> the accuracy, completeness, or usefulness or any information, apparatus, >> product, or process disclosed, or represents that its use would not >> infringe privately owned rights. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From kenneth.schmidt at pnnl.gov Tue May 14 06:31:53 2013 From: kenneth.schmidt at pnnl.gov (Schmidt, Kenneth P) Date: Mon, 13 May 2013 13:31:53 -0700 Subject: [PATCH] Specify PAM Service name in sshd_config In-Reply-To: Message-ID: That will work. I created ticket number 2102, at the following link: https://bugzilla.mindrot.org/show_bug.cgi?id=2102 On 5/13/13 1:21 p.m., "Ben Lindstrom" wrote: > >Best to create a bug in the bugzilla ( https://bugzilla.mindrot.org/ ) >as it will not be lost as easy as if it is just attached to a random >email. > >- Ben > >On May 13, 2013, at 3:05 PM, "Schmidt, Kenneth P" > wrote: > >> Seems as though somewhere along the way the attachment got stripped. >>Lets >> see if it makes it through this time. >> >> On 5/13/13 9:22 a.m., "Schmidt, Kenneth P" >> wrote: >> >>> Hello All, >>> >>> The attached patch allows openssh to specify which pam service name to >>> authenticate users against by specifying the PAMServiceName attribute >>>in >>> the sshd_config file. Because the parameter can be included in the >>>Match >>> directive sections, it allows different authentication based on the >>>Match >>> directive. In our case, we use it to allow different levels of >>> authentication based on the source of the authentication attempts >>> (securID auth in untrusted zones, password auth in trusted zones). The >>> default is still to use the binary name. >>> >>> ____________________________________________ >>> Ken Schmidt >>> Research Scientist, Molecular Science Computing Operations >>> EMSL: Environmental Molecular Sciences Laboratory >>> >>> Pacific Northwest National Laboratory >>> 902 Battelle Boulevard >>> P.O. Box 999, MSIN K8-83 >>> Richland, WA 99352 USA >>> Tel: 509-371-6107 >>> Fax: 509-371-6110 >>> Kenneth.schmidt at pnnl.gov >>> www.emsl.pnl.gov >>> >>> This material was prepared as an account of work sponsored by an >>>agency of >>> the United States Government. Neither the United States Government nor >>> the United States Department of Energy, nor any of their employees, nor >>> Battelle Memorial Institute nor any of its employees, makes any >>>warranty, >>> express or implied, or assumes any legal liability or responsibility >>>for >>> the accuracy, completeness, or usefulness or any information, >>>apparatus, >>> product, or process disclosed, or represents that its use would not >>> infringe privately owned rights. >> >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From flavien-ssh at lebarbe.net Tue May 14 07:16:54 2013 From: flavien-ssh at lebarbe.net (Flavien Lebarbe) Date: Mon, 13 May 2013 23:16:54 +0200 Subject: [PATCH] Specify PAM Service name in sshd_config In-Reply-To: References: Message-ID: <20130513211654.GA21861@srv3.flavien.org> > The attached patch allows openssh to specify which pam service name to > authenticate users against by specifying the PAMServiceName attribute in > the sshd_config file. Because the parameter can be included in the Match > directive sections, it allows different authentication based on the Match > directive. In our case, we use it to allow different levels of > authentication based on the source of the authentication attempts > (securID auth in untrusted zones, password auth in trusted zones). The > default is still to use the binary name. Have a look at this thread : http://thread.gmane.org/gmane.network.openssh.devel/9576 My old attempt at solving the same issue is now 10 years old. Oh well... http://article.gmane.org/gmane.network.openssh.devel/4247 Hope this helps, Flavien. From imorgan at nas.nasa.gov Tue May 14 08:32:17 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 13 May 2013 15:32:17 -0700 Subject: [PATCH] Specify PAM Service name in sshd_config In-Reply-To: References: Message-ID: <20130513223217.GA5002@linux124.nas.nasa.gov> On Mon, May 13, 2013 at 11:22:13 -0500, Schmidt, Kenneth P wrote: > Hello All, > > The attached patch allows openssh to specify which pam service name to > authenticate users against by specifying the PAMServiceName attribute in > the sshd_config file. Because the parameter can be included in the Match > directive sections, it allows different authentication based on the Match > directive. In our case, we use it to allow different levels of > authentication based on the source of the authentication attempts > (securID auth in untrusted zones, password auth in trusted zones). The > default is still to use the binary name. > Hello Ken, Do you anticipate using this primarily with PasswordAuthentication or ChallengeResponseAuthentication? There may be situations where it is desirable to use different PAM service names for each of these authentication methods. For example, it might be desirable to allow a choice of password or public-key authentication in conjunction with the use of a hardware token via AuthenticationMethods: AuthenticationMethods publickey,keyboard-interactive password,keyboard-interactive In such a scenario, you would probably want to use different PAM configurations for keyboard-interactive and password authentication. Keyboard-interactive would use a different PAM service name to implement the hardware token support, but you might still want password authentication to use PAM for failed login tracking, LDAP support, etc. Perhaps one apparoach would be to extend the submethod support which was recently added to AuthenticationMethods; adding an optional third parameter which (in the case of PAM) would specify the service name. Using the above AuthenticationMethods line as an example, the new (somewhat lenghty) line would be: AuthenticationMethods publickey,keyboard-interactive:pam:service password,keyboard-interactive:pam:service -- Iain Morgan From kenneth.schmidt at pnnl.gov Tue May 14 08:32:21 2013 From: kenneth.schmidt at pnnl.gov (Schmidt, Kenneth P) Date: Mon, 13 May 2013 15:32:21 -0700 Subject: [PATCH] Specify PAM Service name in sshd_config In-Reply-To: <20130513211654.GA21861@srv3.flavien.org> Message-ID: On 5/13/13 2:16 p.m., "Flavien Lebarbe" wrote: >> The attached patch allows openssh to specify which pam service name to >> authenticate users against by specifying the PAMServiceName attribute in >> the sshd_config file. Because the parameter can be included in the >>Match >> directive sections, it allows different authentication based on the >>Match >> directive. In our case, we use it to allow different levels of >> authentication based on the source of the authentication attempts >> (securID auth in untrusted zones, password auth in trusted zones). The >> default is still to use the binary name. > >Have a look at this thread : >http://thread.gmane.org/gmane.network.openssh.devel/9576 > >My old attempt at solving the same issue is now 10 years old. Oh well... >http://article.gmane.org/gmane.network.openssh.devel/4247 > > >Hope this helps, > >Flavien. Its obvious there is a desire for the configuration option. Why hasn't it been added? It is considerably easier to add a single configuration option than it is to play tricks with the binary and firewall rules to allow separate authentication methods. With our configuration management system, It is trivial to add a line to the sshd_config, but I would have to write a script to check for a link to the binary and add some firewall rules, not to mention the documentation that would be needed to explain the round about setup. Combined with the Match directive, the PamServiceName directive is a more flexible setup that doesn't require multiple running binaries. In fact, you can do things you can't with the binary link such as having different authentication systems based on the user logging in. For example, one group could authenticate locally, and another group can authenticate to kerberos. From imorgan at nas.nasa.gov Tue May 14 10:29:01 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 13 May 2013 17:29:01 -0700 Subject: [PATCH] Specify PAM Service name in sshd_config In-Reply-To: <20130513223217.GA5002@linux124.nas.nasa.gov> References: <20130513223217.GA5002@linux124.nas.nasa.gov> Message-ID: <20130514002901.GB5002@linux124.nas.nasa.gov> On Mon, May 13, 2013 at 17:32:17 -0500, Iain Morgan wrote: > On Mon, May 13, 2013 at 11:22:13 -0500, Schmidt, Kenneth P wrote: > > Hello All, > > > > The attached patch allows openssh to specify which pam service name to > > authenticate users against by specifying the PAMServiceName attribute in > > the sshd_config file. Because the parameter can be included in the Match > > directive sections, it allows different authentication based on the Match > > directive. In our case, we use it to allow different levels of > > authentication based on the source of the authentication attempts > > (securID auth in untrusted zones, password auth in trusted zones). The > > default is still to use the binary name. > > > > Hello Ken, > > Do you anticipate using this primarily with PasswordAuthentication or > ChallengeResponseAuthentication? > > There may be situations where it is desirable to use different PAM > service names for each of these authentication methods. For example, it > might be desirable to allow a choice of password or public-key > authentication in conjunction with the use of a hardware token via > AuthenticationMethods: > > AuthenticationMethods publickey,keyboard-interactive password,keyboard-interactive > > In such a scenario, you would probably want to use different PAM > configurations for keyboard-interactive and password authentication. > Keyboard-interactive would use a different PAM service name to implement > the hardware token support, but you might still want password > authentication to use PAM for failed login tracking, LDAP support, etc. > > Perhaps one apparoach would be to extend the submethod support which was > recently added to AuthenticationMethods; adding an optional third > parameter which (in the case of PAM) would specify the service name. > Using the above AuthenticationMethods line as an example, the new > (somewhat lenghty) line would be: > > AuthenticationMethods publickey,keyboard-interactive:pam:service password,keyboard-interactive:pam:service > > -- > Iain Morgan > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev Please ignore what I said regarding extending submethod support in AuthenticationMethods. We would still need a mechanism to specify the alternative PAM service used by keyboard-interactive in cases where AuthenticationMethods is not used. However, I hsould note the following item which has been on the TODO list for many years. % grep 'PAM service' TODO - Use different PAM service name for kbdint vs regular auth (suggest from -- Iain Morgan From jan.pechanec at oracle.com Wed May 15 10:01:48 2013 From: jan.pechanec at oracle.com (Jan Pechanec) Date: Tue, 14 May 2013 17:01:48 -0700 (PDT) Subject: [PATCH] Specify PAM Service name in sshd_config In-Reply-To: <20130514002901.GB5002@linux124.nas.nasa.gov> References: <20130513223217.GA5002@linux124.nas.nasa.gov> <20130514002901.GB5002@linux124.nas.nasa.gov> Message-ID: On Mon, 13 May 2013, Iain Morgan wrote: >Please ignore what I said regarding extending submethod support in >AuthenticationMethods. We would still need a mechanism to specify the >alternative PAM service used by keyboard-interactive in cases where >AuthenticationMethods is not used. Iain, aside from PAMServiceName, we have implemented PAMServicePrefix in Solaris so that admins can use different PAM service names for different auth methods: PAMServicePrefix Specifies the PAM service name prefix for service names used for individual user authentication methods. The default is sshd. The PAMServiceName and PAMServicePrefix options are mutually exclusive and if both set, sshd does not start. For example, if this option is set to admincli, the ser- vice name for the keyboard-interactive authentication method is admincli-kbdint instead of the default sshd- kbdint. J. >However, I hsould note the following item which has been on the TODO >list for many years. > >% grep 'PAM service' TODO > - Use different PAM service name for kbdint vs regular auth (suggest from > > -- Jan Pechanec From jonathan at pauliwerks.com Wed May 15 10:21:35 2013 From: jonathan at pauliwerks.com (Jonathan Pauli) Date: Wed, 15 May 2013 00:21:35 -0000 Subject: FW: Message-ID: <20130515001630.56ED44F8057@homiemail-a48.g.dreamhost.com> http://www.rrm-rederiodemedicina.com.br/antgo/y8ndrw.php From rtswguru at hotmail.com Wed May 15 10:18:39 2013 From: rtswguru at hotmail.com (Jeffrey Hawkins) Date: Tue, 14 May 2013 19:18:39 -0500 Subject: Support for "ssh-rsa-sha256" and "ssh-dss-sha256" ? Message-ID: Functionality request for supporting Digital Signatures for RSA and DSS Public Key Algorithms in alignment with NIST SP800-131A. I assume this has been asked before, but I could not find in the archives. Support of "ssh-rsa-sha256" and "ssh-dss-sha256" public key algorithms for OpenSSH? I know Suite B Algorithms and x509 SSH Extension Algorithms are supported, but not a path some folks (us) want to take. Tectia supports similar algorithms via their own extensions in commercial SSH. Are these algorithms being worked on for OpenSSH or been previously rejected? Assuming not rejected, and no one working on it, if I were to do the work and create the patch set, would it be accepted into the mainline? Thanks, Jeff From rtswguru at hotmail.com Wed May 15 10:33:23 2013 From: rtswguru at hotmail.com (Jeffrey Hawkins) Date: Tue, 14 May 2013 19:33:23 -0500 Subject: =?windows-1256?Q?Support_fo?= =?windows-1256?Q?r_"ssh-rsa?= =?windows-1256?Q?-sha256"_a?= =?windows-1256?Q?nd_"ssh-ds?= =?windows-1256?Q?s-sha256"_?= =?windows-1256?Q?=3F=FE?= Message-ID: Functionality request for supporting Digital Signatures for RSA and DSS Public Key Algorithms in alignment with NIST SP800-131A. I assume this has been asked before, but I could not find in the archives. Support of "ssh-rsa-sha256" and "ssh-dss-sha256" public key algorithms for OpenSSH? I know Suite B Algorithms and x509 SSH Extension Algorithms are supported, but not a path some folks (us) want to take. Tectia supports similar algorithms via their own extensions in commercial SSH. Are these algorithms being worked on for OpenSSH or been previously rejected? Assuming not rejected, and no one working on it, if I were to do the work and create the patch set, would it be accepted into the mainline? Thanks, Jeff From dtucker at zip.com.au Wed May 15 11:37:50 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 15 May 2013 11:37:50 +1000 Subject: Session rekeying support in OpenSSH In-Reply-To: <20130513134043.GA21438@gate.dtucker.net> References: <20130513134043.GA21438@gate.dtucker.net> Message-ID: <20130515013750.GA7808@gate.dtucker.net> On Mon, May 13, 2013 at 11:40:43PM +1000, Darren Tucker wrote: > Looks like it wouldn't be hard to add, but what problem are you trying > to solve? As usual it wasn't quite as simple as I initially thought, but this adds an optional second parameter to RekeyLimit in the client and adds RekeyLimit to the server. Basically you should just be able to add "RekeyLimit 1G 1h" to the config files on both the client and server. Patch is against -current but should apply to 6.2p1 with some fuzz. Index: clientloop.c =================================================================== RCS file: /cvs/openssh/clientloop.c,v retrieving revision 1.237 diff -u -p -r1.237 clientloop.c --- clientloop.c 9 Jan 2013 04:55:51 -0000 1.237 +++ clientloop.c 15 May 2013 01:24:13 -0000 @@ -583,7 +583,7 @@ client_wait_until_can_do_something(fd_se { struct timeval tv, *tvp; int timeout_secs; - time_t minwait_secs = 0; + time_t minwait_secs = 0, server_alive_time = 0, now = time(NULL); int ret; /* Add any selections by the channel mechanism. */ @@ -632,12 +632,16 @@ client_wait_until_can_do_something(fd_se */ timeout_secs = INT_MAX; /* we use INT_MAX to mean no timeout */ - if (options.server_alive_interval > 0 && compat20) + if (options.server_alive_interval > 0 && compat20) { timeout_secs = options.server_alive_interval; + server_alive_time = now + options.server_alive_interval; + } + if (options.rekey_interval > 0 && compat20 && !rekeying) + timeout_secs = MIN(timeout_secs, packet_get_rekey_timeout()); set_control_persist_exit_time(); if (control_persist_exit_time > 0) { timeout_secs = MIN(timeout_secs, - control_persist_exit_time - time(NULL)); + control_persist_exit_time - now); if (timeout_secs < 0) timeout_secs = 0; } @@ -669,8 +673,15 @@ client_wait_until_can_do_something(fd_se snprintf(buf, sizeof buf, "select: %s\r\n", strerror(errno)); buffer_append(&stderr_buffer, buf, strlen(buf)); quit_pending = 1; - } else if (ret == 0) - server_alive_check(); + } else if (ret == 0) { + /* + * Timeout. Could have been either keepalive or rekeying. + * Keepalive we check here, rekeying is checked in clientloop. + */ + if (server_alive_time != 0 && server_alive_time <= time(NULL)) + server_alive_check(); + } + } static void Index: monitor.c =================================================================== RCS file: /cvs/openssh/monitor.c,v retrieving revision 1.158 diff -u -p -r1.158 monitor.c --- monitor.c 23 Apr 2013 05:18:10 -0000 1.158 +++ monitor.c 15 May 2013 01:24:13 -0000 @@ -1810,6 +1810,10 @@ monitor_apply_keystate(struct monitor *p if (options.compression) mm_init_compression(pmonitor->m_zlib); + if (options.rekey_limit || options.rekey_interval) + packet_set_rekey_limits((u_int32_t)options.rekey_limit, + (time_t)options.rekey_interval); + /* Network I/O buffers */ /* XXX inefficient for large buffers, need: buffer_init_from_string */ buffer_clear(packet_get_input()); Index: packet.c =================================================================== RCS file: /cvs/openssh/packet.c,v retrieving revision 1.190 diff -u -p -r1.190 packet.c --- packet.c 23 Apr 2013 09:24:32 -0000 1.190 +++ packet.c 15 May 2013 01:24:13 -0000 @@ -58,6 +58,7 @@ #include #include #include +#include #include "xmalloc.h" #include "buffer.h" @@ -165,9 +166,14 @@ struct session_state { Newkeys *newkeys[MODE_MAX]; struct packet_state p_read, p_send; + /* Volume-based rekeying */ u_int64_t max_blocks_in, max_blocks_out; u_int32_t rekey_limit; + /* Time-based rekeying */ + time_t rekey_interval; /* how often in seconds */ + time_t rekey_time; /* time of last rekeying */ + /* Session key for protocol v1 */ u_char ssh1_key[SSH_SESSION_KEY_LENGTH]; u_int ssh1_keylen; @@ -1009,6 +1015,7 @@ packet_send2(void) /* after a NEWKEYS message we can send the complete queue */ if (type == SSH2_MSG_NEWKEYS) { active_state->rekeying = 0; + active_state->rekey_time = time(NULL); while ((p = TAILQ_FIRST(&active_state->outgoing))) { type = p->type; debug("dequeue packet: %u", type); @@ -1933,13 +1940,29 @@ packet_need_rekeying(void) (active_state->max_blocks_out && (active_state->p_send.blocks > active_state->max_blocks_out)) || (active_state->max_blocks_in && - (active_state->p_read.blocks > active_state->max_blocks_in)); + (active_state->p_read.blocks > active_state->max_blocks_in)) || + (active_state->rekey_interval != 0 && active_state->rekey_time + + active_state->rekey_interval <= time(NULL)); } void -packet_set_rekey_limit(u_int32_t bytes) +packet_set_rekey_limits(u_int32_t bytes, time_t seconds) { + debug3("rekey after %lld bytes, %d seconds", (long long)bytes, + (int)seconds); active_state->rekey_limit = bytes; + active_state->rekey_interval = seconds; + active_state->rekey_time = time(NULL); +} + +time_t +packet_get_rekey_timeout(void) +{ + time_t seconds; + + seconds = active_state->rekey_time + active_state->rekey_interval - + time(NULL); + return (seconds < 0 ? 0 : seconds); } void Index: packet.h =================================================================== RCS file: /cvs/openssh/packet.h,v retrieving revision 1.60 diff -u -p -r1.60 packet.h --- packet.h 10 Feb 2012 21:19:21 -0000 1.60 +++ packet.h 15 May 2013 01:24:13 -0000 @@ -115,7 +115,8 @@ do { \ } while (0) int packet_need_rekeying(void); -void packet_set_rekey_limit(u_int32_t); +void packet_set_rekey_limits(u_int32_t, time_t); +time_t packet_get_rekey_timeout(void); void packet_backup_state(void); void packet_restore_state(void); Index: readconf.c =================================================================== RCS file: /cvs/openssh/readconf.c,v retrieving revision 1.177 diff -u -p -r1.177 readconf.c --- readconf.c 23 Apr 2013 05:17:12 -0000 1.177 +++ readconf.c 15 May 2013 01:24:13 -0000 @@ -562,39 +562,54 @@ parse_yesnoask: case oRekeyLimit: arg = strdelim(&s); if (!arg || *arg == '\0') - fatal("%.200s line %d: Missing argument.", filename, linenum); - if (arg[0] < '0' || arg[0] > '9') - fatal("%.200s line %d: Bad number.", filename, linenum); - orig = val64 = strtoll(arg, &endofnumber, 10); - if (arg == endofnumber) - fatal("%.200s line %d: Bad number.", filename, linenum); - switch (toupper(*endofnumber)) { - case '\0': - scale = 1; - break; - case 'K': - scale = 1<<10; - break; - case 'M': - scale = 1<<20; - break; - case 'G': - scale = 1<<30; - break; - default: - fatal("%.200s line %d: Invalid RekeyLimit suffix", - filename, linenum); + fatal("%.200s line %d: Missing argument.", filename, + linenum); + if (strcmp(arg, "default") == 0) { + val64 = 0; + } else { + if (arg[0] < '0' || arg[0] > '9') + fatal("%.200s line %d: Bad number.", filename, + linenum); + orig = val64 = strtoll(arg, &endofnumber, 10); + if (arg == endofnumber) + fatal("%.200s line %d: Bad number.", filename, + linenum); + switch (toupper(*endofnumber)) { + case '\0': + scale = 1; + break; + case 'K': + scale = 1<<10; + break; + case 'M': + scale = 1<<20; + break; + case 'G': + scale = 1<<30; + break; + default: + fatal("%.200s line %d: Invalid RekeyLimit " + "suffix", filename, linenum); + } + val64 *= scale; + /* detect integer wrap and too-large limits */ + if ((val64 / scale) != orig || val64 > UINT_MAX) + fatal("%.200s line %d: RekeyLimit too large", + filename, linenum); + if (val64 != 0 && val64 < 16) + fatal("%.200s line %d: RekeyLimit too small", + filename, linenum); } - val64 *= scale; - /* detect integer wrap and too-large limits */ - if ((val64 / scale) != orig || val64 > UINT_MAX) - fatal("%.200s line %d: RekeyLimit too large", - filename, linenum); - if (val64 < 16) - fatal("%.200s line %d: RekeyLimit too small", - filename, linenum); if (*activep && options->rekey_limit == -1) options->rekey_limit = (u_int32_t)val64; + if (s != NULL) { /* optional rekey interval present */ + if (strcmp(s, "none") == 0) { + (void)strdelim(&s); /* discard */ + break; + } + intptr = &options->rekey_interval; + goto parse_time; + } break; case oIdentityFile: @@ -1202,6 +1217,7 @@ initialize_options(Options * options) options->no_host_authentication_for_localhost = - 1; options->identities_only = - 1; options->rekey_limit = - 1; + options->rekey_interval = -1; options->verify_host_key_dns = -1; options->server_alive_interval = -1; options->server_alive_count_max = -1; @@ -1337,6 +1353,8 @@ fill_default_options(Options * options) options->enable_ssh_keysign = 0; if (options->rekey_limit == -1) options->rekey_limit = 0; + if (options->rekey_interval == -1) + options->rekey_interval = 0; if (options->verify_host_key_dns == -1) options->verify_host_key_dns = 0; if (options->server_alive_interval == -1) Index: readconf.h =================================================================== RCS file: /cvs/openssh/readconf.h,v retrieving revision 1.85 diff -u -p -r1.85 readconf.h --- readconf.h 5 Apr 2013 00:18:36 -0000 1.85 +++ readconf.h 15 May 2013 01:24:13 -0000 @@ -110,6 +110,7 @@ typedef struct { int enable_ssh_keysign; int64_t rekey_limit; + int rekey_interval; int no_host_authentication_for_localhost; int identities_only; int server_alive_interval; Index: servconf.c =================================================================== RCS file: /cvs/openssh/servconf.c,v retrieving revision 1.231 diff -u -p -r1.231 servconf.c --- servconf.c 12 Feb 2013 00:02:08 -0000 1.231 +++ servconf.c 15 May 2013 01:24:13 -0000 @@ -20,6 +20,7 @@ #include #include +#include #include #include #include @@ -110,6 +111,8 @@ initialize_server_options(ServerOptions options->permit_user_env = -1; options->use_login = -1; options->compression = -1; + options->rekey_limit = -1; + options->rekey_interval = -1; options->allow_tcp_forwarding = -1; options->allow_agent_forwarding = -1; options->num_allow_users = 0; @@ -249,6 +252,10 @@ fill_default_server_options(ServerOption options->use_login = 0; if (options->compression == -1) options->compression = COMP_DELAYED; + if (options->rekey_limit == -1) + options->rekey_limit = 0; + if (options->rekey_interval == -1) + options->rekey_interval = 0; if (options->allow_tcp_forwarding == -1) options->allow_tcp_forwarding = FORWARD_ALLOW; if (options->allow_agent_forwarding == -1) @@ -320,7 +327,7 @@ typedef enum { sX11Forwarding, sX11DisplayOffset, sX11UseLocalhost, sStrictModes, sEmptyPasswd, sTCPKeepAlive, sPermitUserEnvironment, sUseLogin, sAllowTcpForwarding, sCompression, - sAllowUsers, sDenyUsers, sAllowGroups, sDenyGroups, + sRekeyLimit, sAllowUsers, sDenyUsers, sAllowGroups, sDenyGroups, sIgnoreUserKnownHosts, sCiphers, sMacs, sProtocol, sPidFile, sGatewayPorts, sPubkeyAuthentication, sXAuthLocation, sSubsystem, sMaxStartups, sMaxAuthTries, sMaxSessions, @@ -422,6 +429,7 @@ static struct { { "permituserenvironment", sPermitUserEnvironment, SSHCFG_GLOBAL }, { "uselogin", sUseLogin, SSHCFG_GLOBAL }, { "compression", sCompression, SSHCFG_GLOBAL }, + { "rekeylimit", sRekeyLimit, SSHCFG_ALL }, { "tcpkeepalive", sTCPKeepAlive, SSHCFG_GLOBAL }, { "keepalive", sTCPKeepAlive, SSHCFG_GLOBAL }, /* obsolete alias */ { "allowtcpforwarding", sAllowTcpForwarding, SSHCFG_ALL }, @@ -800,14 +808,15 @@ process_server_config_line(ServerOptions const char *filename, int linenum, int *activep, struct connection_info *connectinfo) { - char *cp, **charptr, *arg, *p; + char *cp, **charptr, *arg, *p, *endofnumber; int cmdline = 0, *intptr, value, value2, n; SyslogFacility *log_facility_ptr; LogLevel *log_level_ptr; ServerOpCodes opcode; - int port; + int port, scale; u_int i, flags = 0; size_t len; + long long orig, val64; const struct multistate *multistate_ptr; cp = line; @@ -1118,6 +1127,59 @@ process_server_config_line(ServerOptions multistate_ptr = multistate_compression; goto parse_multistate; + case sRekeyLimit: + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%.200s line %d: Missing argument.", filename, + linenum); + if (strcmp(arg, "default") == 0) { + val64 = 0; + } else { + if (arg[0] < '0' || arg[0] > '9') + fatal("%.200s line %d: Bad number.", filename, + linenum); + orig = val64 = strtoll(arg, &endofnumber, 10); + if (arg == endofnumber) + fatal("%.200s line %d: Bad number.", filename, + linenum); + switch (toupper(*endofnumber)) { + case '\0': + scale = 1; + break; + case 'K': + scale = 1<<10; + break; + case 'M': + scale = 1<<20; + break; + case 'G': + scale = 1<<30; + break; + default: + fatal("%.200s line %d: Invalid RekeyLimit " + "suffix", filename, linenum); + } + val64 *= scale; + /* detect integer wrap and too-large limits */ + if ((val64 / scale) != orig || val64 > UINT_MAX) + fatal("%.200s line %d: RekeyLimit too large", + filename, linenum); + if (val64 != 0 && val64 < 16) + fatal("%.200s line %d: RekeyLimit too small", + filename, linenum); + } + if (*activep && options->rekey_limit == -1) + options->rekey_limit = (u_int32_t)val64; + if (cp != NULL) { /* optional rekey interval present */ + if (strcmp(cp, "none") == 0) { + (void)strdelim(&cp); /* discard */ + break; + } + intptr = &options->rekey_interval; + goto parse_time; + } + break; + case sGatewayPorts: intptr = &options->gateway_ports; multistate_ptr = multistate_gatewayports; @@ -1718,6 +1780,8 @@ copy_set_server_options(ServerOptions *d M_CP_INTOPT(max_authtries); M_CP_INTOPT(ip_qos_interactive); M_CP_INTOPT(ip_qos_bulk); + M_CP_INTOPT(rekey_limit); + M_CP_INTOPT(rekey_interval); /* See comment in servconf.h */ COPY_MATCH_STRING_OPTS(); Index: servconf.h =================================================================== RCS file: /cvs/openssh/servconf.h,v retrieving revision 1.99 diff -u -p -r1.99 servconf.h --- servconf.h 9 Jan 2013 04:56:45 -0000 1.99 +++ servconf.h 15 May 2013 01:24:13 -0000 @@ -176,6 +176,9 @@ typedef struct { char *authorized_keys_command; char *authorized_keys_command_user; + int64_t rekey_limit; + int rekey_interval; + char *version_addendum; /* Appended to SSH banner */ u_int num_auth_methods; Index: serverloop.c =================================================================== RCS file: /cvs/openssh/serverloop.c,v retrieving revision 1.173 diff -u -p -r1.173 serverloop.c --- serverloop.c 7 Dec 2012 02:07:47 -0000 1.173 +++ serverloop.c 15 May 2013 01:24:13 -0000 @@ -826,6 +826,7 @@ server_loop2(Authctxt *authctxt) { fd_set *readset = NULL, *writeset = NULL; int rekeying = 0, max_fd, nalloc = 0; + u_int rekey_timeout_ms = 0; debug("Entering interactive session for SSH2."); @@ -854,8 +855,13 @@ server_loop2(Authctxt *authctxt) if (!rekeying && packet_not_very_much_data_to_write()) channel_output_poll(); + if (options.rekey_interval > 0 && compat20 && !rekeying) + rekey_timeout_ms = packet_get_rekey_timeout() * 1000; + else + rekey_timeout_ms = 0; + wait_until_can_do_something(&readset, &writeset, &max_fd, - &nalloc, 0); + &nalloc, rekey_timeout_ms); if (received_sigterm) { logit("Exiting on signal %d", (int)received_sigterm); @@ -870,6 +876,7 @@ server_loop2(Authctxt *authctxt) debug("need rekeying"); xxx_kex->done = 0; kex_send_kexinit(xxx_kex); + packet_write_wait(); } } process_input(readset); Index: ssh_config =================================================================== RCS file: /cvs/openssh/ssh_config,v retrieving revision 1.28 diff -u -p -r1.28 ssh_config --- ssh_config 12 Jan 2010 08:40:27 -0000 1.28 +++ ssh_config 15 May 2013 01:24:13 -0000 @@ -45,3 +45,4 @@ # PermitLocalCommand no # VisualHostKey no # ProxyCommand ssh -q -W %h:%p gateway.example.com +# RekeyLimit 1G 1h Index: ssh_config.5 =================================================================== RCS file: /cvs/openssh/ssh_config.5,v retrieving revision 1.161 diff -u -p -r1.161 ssh_config.5 --- ssh_config.5 9 Jan 2013 05:12:19 -0000 1.161 +++ ssh_config.5 15 May 2013 01:24:14 -0000 @@ -931,8 +931,9 @@ The default is This option applies to protocol version 2 only. .It Cm RekeyLimit Specifies the maximum amount of data that may be transmitted before the -session key is renegotiated. -The argument is the number of bytes, with an optional suffix of +session key is renegotiated, optionally followed a maximum amount of +time that may pass before the session key is renegotiated. +The first argument is specified in bytes and may have a suffix of .Sq K , .Sq M , or @@ -943,6 +944,17 @@ The default is between and .Sq 4G , depending on the cipher. +The optional second value is specified in seconds and may use any of the +units documented in the +.Sx TIME FORMATS +section of +.Xr sshd_config 5 . +The default value for +.Cm RekeyLimit +is +.Dq default none , +which means that rekeying is performed after the cipher's default amount +of data has been sent or received and no time based rekeying is done. This option applies to protocol version 2 only. .It Cm RemoteForward Specifies that a TCP port on the remote machine be forwarded over Index: sshconnect2.c =================================================================== RCS file: /cvs/openssh/sshconnect2.c,v retrieving revision 1.187 diff -u -p -r1.187 sshconnect2.c --- sshconnect2.c 23 Apr 2013 05:18:52 -0000 1.187 +++ sshconnect2.c 15 May 2013 01:24:14 -0000 @@ -197,8 +197,9 @@ ssh_kex2(char *host, struct sockaddr *ho if (options.kex_algorithms != NULL) myproposal[PROPOSAL_KEX_ALGS] = options.kex_algorithms; - if (options.rekey_limit) - packet_set_rekey_limit((u_int32_t)options.rekey_limit); + if (options.rekey_limit || options.rekey_interval) + packet_set_rekey_limits((u_int32_t)options.rekey_limit, + (time_t)options.rekey_interval); /* start key exchange */ kex = kex_setup(myproposal); Index: sshd.c =================================================================== RCS file: /cvs/openssh/sshd.c,v retrieving revision 1.422 diff -u -p -r1.422 sshd.c --- sshd.c 23 Apr 2013 05:21:07 -0000 1.422 +++ sshd.c 15 May 2013 01:24:14 -0000 @@ -2364,6 +2364,10 @@ do_ssh2_kex(void) if (options.kex_algorithms != NULL) myproposal[PROPOSAL_KEX_ALGS] = options.kex_algorithms; + if (options.rekey_limit || options.rekey_interval) + packet_set_rekey_limits((u_int32_t)options.rekey_limit, + (time_t)options.rekey_interval); + myproposal[PROPOSAL_SERVER_HOST_KEY_ALGS] = list_hostkey_types(); /* start key exchange */ Index: sshd_config =================================================================== RCS file: /cvs/openssh/sshd_config,v retrieving revision 1.91 diff -u -p -r1.91 sshd_config --- sshd_config 12 Feb 2013 00:02:09 -0000 1.91 +++ sshd_config 15 May 2013 01:24:14 -0000 @@ -29,6 +29,9 @@ #KeyRegenerationInterval 1h #ServerKeyBits 1024 +# Ciphers and keying +#RekeyLimit default none + # Logging # obsoletes QuietMode and FascistLogging #SyslogFacility AUTH Index: sshd_config.5 =================================================================== RCS file: /cvs/openssh/sshd_config.5,v retrieving revision 1.165 diff -u -p -r1.165 sshd_config.5 --- sshd_config.5 23 Apr 2013 05:23:08 -0000 1.165 +++ sshd_config.5 15 May 2013 01:24:14 -0000 @@ -814,6 +814,7 @@ Available keywords are .Cm PermitRootLogin , .Cm PermitTunnel , .Cm PubkeyAuthentication , +.Cm RekeyLimit , .Cm RhostsRSAAuthentication , .Cm RSAAuthentication , .Cm X11DisplayOffset , @@ -1008,6 +1009,33 @@ Specifies whether public key authenticat The default is .Dq yes . Note that this option applies to protocol version 2 only. +.It Cm RekeyLimit +Specifies the maximum amount of data that may be transmitted before the +session key is renegotiated, optionally followed a maximum amount of +time that may pass before the session key is renegotiated. +The first argument is specified in bytes and may have a suffix of +.Sq K , +.Sq M , +or +.Sq G +to indicate Kilobytes, Megabytes, or Gigabytes, respectively. +The default is between +.Sq 1G +and +.Sq 4G , +depending on the cipher. +The optional second value is specified in seconds and may use any of the +units documented in the +.Sx TIME FORMATS +section of +.Xr sshd_config 5 . +The default value for +.Cm RekeyLimit +is +.Dq default none , +which means that rekeying is performed after the cipher's default amount +of data has been sent or received and no time based rekeying is done. +This option applies to protocol version 2 only. .It Cm RevokedKeys Specifies revoked public keys. Keys listed in this file will be refused for public key authentication. -- 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 dkg at fifthhorseman.net Wed May 15 13:47:38 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 14 May 2013 23:47:38 -0400 Subject: key rotation on ssh servers Message-ID: <874ne4rjj9.fsf@alice.fifthhorseman.net> hi OpenSSH folks-- I have several OpenSSH sshd servers that i've maintained for a long time. Some of them have keys that are considered short by today's standards (e.g. 1024-bit RSA keys). On these servers, I would like to be able to do a key rotation such that multiple keys are valid during a time window so that users can learn the new key before i remove the old one. I don't think this is currently supported, but i'm interested in figuring out how something like this might happen in the future. Reading the spec i don't see an explicit prohibition against multiple keys of the same key type, but i don't see how it would be handled exactly in the protocol either: https://tools.ietf.org/html/rfc4253#page-18 Looking at sshd.c, it seems to me that get_hostkey_by_type() only permits sshd to offer a single key of each type. Would it be possible for some sshd to offer more than one key of any given type? If so, this would permit such a key transition from clients that could support it? Or is there something in the spec that i'm not seeing which makes this explicitly impossible? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 965 bytes Desc: not available URL: From djm at mindrot.org Wed May 15 14:38:47 2013 From: djm at mindrot.org (Damien Miller) Date: Wed, 15 May 2013 14:38:47 +1000 (EST) Subject: Session rekeying support in OpenSSH In-Reply-To: <20130515013750.GA7808@gate.dtucker.net> References: <20130513134043.GA21438@gate.dtucker.net> <20130515013750.GA7808@gate.dtucker.net> Message-ID: On Wed, 15 May 2013, Darren Tucker wrote: > + switch (toupper(*endofnumber)) { > + case '\0': > + scale = 1; > + break; > + case 'K': > + scale = 1<<10; > + break; > + case 'M': > + scale = 1<<20; > + break; > + case 'G': > + scale = 1<<30; > + break; Good opportunity to switch to scan_scaled()? -d From djm at mindrot.org Wed May 15 15:11:37 2013 From: djm at mindrot.org (Damien Miller) Date: Wed, 15 May 2013 15:11:37 +1000 (EST) Subject: key rotation on ssh servers In-Reply-To: <874ne4rjj9.fsf@alice.fifthhorseman.net> References: <874ne4rjj9.fsf@alice.fifthhorseman.net> Message-ID: On Tue, 14 May 2013, Daniel Kahn Gillmor wrote: > Reading the spec i don't see an explicit prohibition against multiple > keys of the same key type, but i don't see how it would be handled > exactly in the protocol either: > > https://tools.ietf.org/html/rfc4253#page-18 > > Looking at sshd.c, it seems to me that get_hostkey_by_type() only > permits sshd to offer a single key of each type. Right. The protocol only supports sending a single host key as part of key exchange. E.g. RFC4253 section 8 (search for "K_S") We've toyed with an extension to express "since you trust this one, here all my other keys" but never implemented it. To my mind, it would look something like: byte SSH_MSG_HOSTKEYS string hostkeys string signature Where "hostkeys" contains: string hostkey[0] ... string hostkey[n] and "signature" is made with the hostkey that was used to sign the last KEX exchange. -d From dkg at fifthhorseman.net Wed May 15 15:38:59 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 15 May 2013 01:38:59 -0400 Subject: key rotation on ssh servers In-Reply-To: References: <874ne4rjj9.fsf@alice.fifthhorseman.net> Message-ID: <51931F73.3060606@fifthhorseman.net> On 05/15/2013 01:11 AM, Damien Miller wrote: > Right. The protocol only supports sending a single host key as part of > key exchange. E.g. RFC4253 section 8 (search for "K_S") hm, right; and i don't see a way for the client to say "no thanks, try again, but with the same key type". if the key exchange fails, it fails. > We've toyed with an extension to express "since you trust this one, > here all my other keys" but never implemented it. To my mind, it would > look something like: > > byte SSH_MSG_HOSTKEYS > string hostkeys > string signature > > Where "hostkeys" contains: > > string hostkey[0] > ... > string hostkey[n] > > and "signature" is made with the hostkey that was used to sign the last > KEX exchange. Depending on how you specify hostkey[n], this would let you rotate keys across key types as well, which is a nice feature. I'm assuming this is wrapped inside the DH layer, after the key exchange so that it is authenticated, encrypted, and bound to the session. this sounds like it is similar to (but simpler than) the TACK proposal currently under consideration for TLS [0]. I wonder if any of the additional semantics considered for TACK would be useful for this sort of extension for SSH. certainly the form you're proposing has the advantage of simplicity :) Do you imagine that the server would just send this message to any connected client blindly after each keyexchange, or should the client signal its willingness to receive such a message first? (e.g. with an otherwise empty SSH_MSG_HOSTKEYS message?) client signalling seems like it would reduce bandwidth costs initially (no bulk keys would be sent to clients who don't want them) but might increase them in the long run (an extra packet from the client that is not needed). Is there any interest in an implementation of this? Should i open an issue for it on the bug tracker? --dkg [0] https://tools.ietf.org/html/draft-perrin-tls-tack -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 1027 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Wed May 15 15:55:22 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 15 May 2013 01:55:22 -0400 Subject: key rotation on ssh servers In-Reply-To: <51931F73.3060606@fifthhorseman.net> References: <874ne4rjj9.fsf@alice.fifthhorseman.net> <51931F73.3060606@fifthhorseman.net> Message-ID: <5193234A.80006@fifthhorseman.net> On 05/15/2013 01:38 AM, Daniel Kahn Gillmor wrote: > this sounds like it is similar to (but simpler than) the TACK proposal > currently under consideration for TLS [0]. I wonder if any of the > additional semantics considered for TACK would be useful for this sort > of extension for SSH. certainly the form you're proposing has the > advantage of simplicity :) oh, i guess one more question, sorry: One of the goals of a key exchange is to permit future authentications with a new key. Looking even further down the road, you'd also want to *prevent* future authentications with an old key. That is, if the process never removes the old key from the client's ~/.ssh/known_hosts file, then it doesn't really protect the client against a key compromise of the old key in the long run. So do you think the semantics of the proposed SSH_MSG_HOSTKEYS message should include "please invalidate all host keys not listed here"? --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 dtucker at zip.com.au Wed May 15 15:51:33 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 15 May 2013 15:51:33 +1000 Subject: Session rekeying support in OpenSSH In-Reply-To: References: <20130513134043.GA21438@gate.dtucker.net> <20130515013750.GA7808@gate.dtucker.net> Message-ID: On Wed, May 15, 2013 at 2:38 PM, Damien Miller wrote: > On Wed, 15 May 2013, Darren Tucker wrote: > > > + switch (toupper(*endofnumber)) { > > + case '\0': > > + scale = 1; > > + break; > > + case 'K': > > + scale = 1<<10; > > + break; > > + case 'M': > > + scale = 1<<20; > > + break; > > + case 'G': > > + scale = 1<<30; > > + break; > > Good opportunity to switch to scan_scaled()? sure. I was going to factor out that code as a separate change, but if there's a library function we can steal then even better. > > -d > -- 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 vintobe at gmail.com Thu May 16 00:30:24 2013 From: vintobe at gmail.com (Vincent Lin) Date: Wed, 15 May 2013 22:30:24 +0800 Subject: how to check whether the ssh tunnel is up In-Reply-To: <20130510093353.GB20843@greenie.muc.de> References: <517B6EBA.2090903@fifthhorseman.net> <517BF349.8090004@fifthhorseman.net> <20130510093353.GB20843@greenie.muc.de> Message-ID: Hi Gert, Yes, you're right, I tried and it turned out to be as you said. So what can I do? Maybe I can check the 20001 port to see whether it's listening, but I found when the socket is set up on the server side. It still needs to notify ssh client side. And ssh client side should establish the local port mapping to the destination localhost:22. Is that mean the only way to find tunnel status is to send data from server side and look forward to receiving the reply just like autossh? Thanks Vincent On Fri, May 10, 2013 at 5:33 PM, Gert Doering wrote: > Hi, > > On Fri, May 10, 2013 at 10:44:59AM +0800, Vincent Lin wrote: > > I have an idea. If we get the ssh process ID, then we can check the local > > socket . Once the socket is established, the tunnel is OK. For example, > > > > ssh [...] -R 20001:localhost:22 > > > > We can check the socket that is used by specific ssh process. If the > > Foreign Address is localhost:22 and state is ESTABLISH, the tunnel is up. > > What do you think? > > This is not how it works. > > Unless someone actually connects to 20001 on the remote side, there is > nothing on the local side that you could see in "netstat" > > gert > -- > USENET is *not* the non-clickable part of WWW! > // > www.muc.de/~gert/ > Gert Doering - Munich, Germany > gert at greenie.muc.de > fax: +49-89-35655025 > gert at net.informatik.tu-muenchen.de > From keisial at gmail.com Thu May 16 01:04:12 2013 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Wed, 15 May 2013 17:04:12 +0200 Subject: key rotation on ssh servers In-Reply-To: <5193234A.80006@fifthhorseman.net> References: <874ne4rjj9.fsf@alice.fifthhorseman.net> <51931F73.3060606@fifthhorseman.net> <5193234A.80006@fifthhorseman.net> Message-ID: <5193A3EC.5010005@gmail.com> Om 15/05/13 07:55, Daniel Kahn Gillmor wrote: > oh, i guess one more question, sorry: > > One of the goals of a key exchange is to permit future authentications > with a new key. > > Looking even further down the road, you'd also want to *prevent* future > authentications with an old key. > > That is, if the process never removes the old key from the client's > ~/.ssh/known_hosts file, then it doesn't really protect the client > against a key compromise of the old key in the long run. > > So do you think the semantics of the proposed SSH_MSG_HOSTKEYS message > should include "please invalidate all host keys not listed here"? Perhaps the hostkeys message should include an expiry field? > Do you imagine that the server would just send this message to any > connected client blindly after each keyexchange, or should the client > signal its willingness to receive such a message first? (e.g. with an > otherwise empty SSH_MSG_HOSTKEYS message?) client signalling seems like > it would reduce bandwidth costs initially (no bulk keys would be sent to > clients who don't want them) but might increase them in the long run (an > extra packet from the client that is not needed). Maybe add "support for hostkey listing" as a pseudo-key type in the key exchange? I should check the rfc for the current key exchange process. From alex at alex.org.uk Thu May 16 02:21:32 2013 From: alex at alex.org.uk (Alex Bligh) Date: Wed, 15 May 2013 17:21:32 +0100 Subject: how to check whether the ssh tunnel is up In-Reply-To: References: <517B6EBA.2090903@fifthhorseman.net> <517BF349.8090004@fifthhorseman.net> <20130510093353.GB20843@greenie.muc.de> Message-ID: <565632B3-D515-4E86-8646-1AAADD751318@alex.org.uk> Vincent, On 15 May 2013, at 15:30, Vincent Lin wrote: > Is that mean the only way to > find tunnel status is to send data from server side and look forward to > receiving the reply just like autossh? My conclusion when I last looked at this was that the only way to reliably tell whether an ssh tunnel up is to send data through it in both directions. Using the trick autossh uses (whether you actually use autossh or not) of paired -L and -R seems like the easiest way to do this. I was going to code this myself and found using autossh was far easier. -- Alex Bligh From kenneth.schmidt at pnnl.gov Thu May 16 03:43:35 2013 From: kenneth.schmidt at pnnl.gov (Schmidt, Kenneth P) Date: Wed, 15 May 2013 10:43:35 -0700 Subject: [PATCH] Specify PAM Service name in sshd_config In-Reply-To: Message-ID: On 5/14/13 5:01 p.m., "Jan Pechanec" wrote: >On Mon, 13 May 2013, Iain Morgan wrote: > >>Please ignore what I said regarding extending submethod support in >>AuthenticationMethods. We would still need a mechanism to specify the >>alternative PAM service used by keyboard-interactive in cases where >>AuthenticationMethods is not used. > > Iain, aside from PAMServiceName, we have implemented >PAMServicePrefix in Solaris so that admins can use different PAM service >names for different auth methods: > > PAMServicePrefix > > Specifies the PAM service name prefix for service names > used for individual user authentication methods. The > default is sshd. The PAMServiceName and PAMServicePrefix > options are mutually exclusive and if both set, sshd > does not start. > > For example, if this option is set to admincli, the ser- > vice name for the keyboard-interactive authentication > method is admincli-kbdint instead of the default sshd- > kbdint. > > J. > >>However, I hsould note the following item which has been on the TODO >>list for many years. >> >>% grep 'PAM service' TODO >> - Use different PAM service name for kbdint vs regular auth (suggest >>from >> >> > >-- >Jan Pechanec Why not just use the PAMServiceName and use a Flag to indicate that the authentication method should be appended to the PAM service? So something like PAMServiceName admincli PAMAppendAuthMethod yes would be admincli-kbdint. That way both the pam service and the auth method could be specified without worrying about the options being mutually exclusive and preventing a possible invalid configuration to be specified. From imorgan at nas.nasa.gov Thu May 16 04:09:40 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Wed, 15 May 2013 11:09:40 -0700 Subject: [PATCH] Specify PAM Service name in sshd_config In-Reply-To: References: Message-ID: <20130515180940.GC5003@linux124.nas.nasa.gov> On Wed, May 15, 2013 at 12:43:35 -0500, Schmidt, Kenneth P wrote: > > > On 5/14/13 5:01 p.m., "Jan Pechanec" wrote: > > >On Mon, 13 May 2013, Iain Morgan wrote: > > > >>Please ignore what I said regarding extending submethod support in > >>AuthenticationMethods. We would still need a mechanism to specify the > >>alternative PAM service used by keyboard-interactive in cases where > >>AuthenticationMethods is not used. > > > > Iain, aside from PAMServiceName, we have implemented > >PAMServicePrefix in Solaris so that admins can use different PAM service > >names for different auth methods: > > > > PAMServicePrefix > > > > Specifies the PAM service name prefix for service names > > used for individual user authentication methods. The > > default is sshd. The PAMServiceName and PAMServicePrefix > > options are mutually exclusive and if both set, sshd > > does not start. > > > > For example, if this option is set to admincli, the ser- > > vice name for the keyboard-interactive authentication > > method is admincli-kbdint instead of the default sshd- > > kbdint. > > > > J. > > > >>However, I hsould note the following item which has been on the TODO > >>list for many years. > >> > >>% grep 'PAM service' TODO > >> - Use different PAM service name for kbdint vs regular auth (suggest > >>from > >> > >> > > > >-- > >Jan Pechanec > > Why not just use the PAMServiceName and use a Flag to indicate that the > authentication method should be appended to the PAM service? So something > like > > PAMServiceName admincli > PAMAppendAuthMethod yes > > would be admincli-kbdint. That way both the pam service and the auth > method could be specified without worrying about the options being > mutually exclusive and preventing a possible invalid configuration to be > specified. > Hmm, what if PAMServiceName supported some % macros? Some candidates would be %c for the executable, %m for the authentication method, and %p for the server port. This would allow something like: PAMServiceName %c-%m or PAMServiceName admincli-%m -- Iain Morgan From jan.pechanec at oracle.com Thu May 16 05:03:16 2013 From: jan.pechanec at oracle.com (Jan Pechanec) Date: Wed, 15 May 2013 12:03:16 -0700 (PDT) Subject: [PATCH] Specify PAM Service name in sshd_config In-Reply-To: References: Message-ID: On Wed, 15 May 2013, Schmidt, Kenneth P wrote: <...> >> PAMServicePrefix >> >> Specifies the PAM service name prefix for service names >> used for individual user authentication methods. The >> default is sshd. The PAMServiceName and PAMServicePrefix >> options are mutually exclusive and if both set, sshd >> does not start. >> >> For example, if this option is set to admincli, the ser- >> vice name for the keyboard-interactive authentication >> method is admincli-kbdint instead of the default sshd- >> kbdint. >> >> J. >> <...> >Why not just use the PAMServiceName and use a Flag to indicate that the >authentication method should be appended to the PAM service? So something >like > >PAMServiceName admincli >PAMAppendAuthMethod yes > >would be admincli-kbdint. That way both the pam service and the auth >method could be specified without worrying about the options being >mutually exclusive and preventing a possible invalid configuration to be >specified. I personally think it's more complicated since you'd always need both options' values to figure out what will be the PAM service name, either explicitly stated in the config file or their implicit default value(s). J. -- Jan Pechanec From mouring at eviladmin.org Thu May 16 05:36:28 2013 From: mouring at eviladmin.org (Ben Lindstrom) Date: Wed, 15 May 2013 14:36:28 -0500 Subject: [PATCH] Specify PAM Service name in sshd_config In-Reply-To: References: Message-ID: <23791DB7-7F68-4BD2-B811-9DF0B96C5F5B@eviladmin.org> On May 15, 2013, at 2:03 PM, Jan Pechanec wrote: > On Wed, 15 May 2013, Schmidt, Kenneth P wrote: [..] >> Why not just use the PAMServiceName and use a Flag to indicate that the >> authentication method should be appended to the PAM service? So something >> like >> >> PAMServiceName admincli >> PAMAppendAuthMethod yes >> >> would be admincli-kbdint. That way both the pam service and the auth >> method could be specified without worrying about the options being >> mutually exclusive and preventing a possible invalid configuration to be >> specified. > > I personally think it's more complicated since you'd always need > both options' values to figure out what will be the PAM service name, > either explicitly stated in the config file or their implicit default > value(s). J. Personally think Mr Morgan's solution is more elegant as there is a single configuration and no conflicting options. - Ben From nico-openssh-unix-dev at schottelius.org Thu May 16 07:45:23 2013 From: nico-openssh-unix-dev at schottelius.org (Nico Schottelius) Date: Wed, 15 May 2013 23:45:23 +0200 Subject: [PATCH] Expose remote forwarding ports as environment variable Message-ID: <20130515214523.GH12213@schottelius.org> Good evening gentlemen, the attached patch against openssh 6.2p1 exposes remote forwarding ports to the remote shell: targethost % ssh -R 1234:localhost:22 controlhost controlhost % echo $SSH_REMOTE_FORWARDING_PORTS 1234 targethost % ssh -R 0:localhost:22 controlhost controlhost % echo $SSH_REMOTE_FORWARDING_PORTS 54294 targethost % ssh -R 0:localhost:22 -R 1234:localhost:22 controlhost controlhost % echo $SSH_REMOTE_FORWARDING_PORTS 59056 1234 Detailled motivation can be found at http://www.nico.schottelius.org/blog/openssh-6.2-add-callback-functionality-using-dynamic-remote-port-forwarding/ The patch is attached. Please let me know what you think about it and whether you'd consider it for inclusion (with or without changes). Cheers, Nico -- PGP key: 7ED9 F7D3 6B10 81D7 0EC5 5C09 D7DC C8E4 3187 7DF0 -------------- next part -------------- diff -ru openssh-6.2p1/channels.c openssh-6.2p1.patched/channels.c --- openssh-6.2p1/channels.c 2012-12-02 23:50:55.000000000 +0100 +++ openssh-6.2p1.patched/channels.c 2013-05-15 23:26:17.119989982 +0200 @@ -2865,6 +2865,52 @@ return success; } +/* + * Write list of remote forwarding ports into an existing buffer + */ +void +channel_list_rport_listener(char *buf, size_t size) +{ + u_int i, j, num_ports = 0; + int offset = 0; + int *ports; + int skip; + + ports = xcalloc(channels_alloc, sizeof(int)); + + for (i = 0; i < channels_alloc; i++) { + skip = 0; + Channel *c = channels[i]; + if (c == NULL || c->type != SSH_CHANNEL_RPORT_LISTENER) + continue; + + /* Skip already added ports - IPv4 + IPv6 == same port twice */ + for(j = 0; j < num_ports; j++) { + if (ports[j] == c->listening_port) { + skip = 1; + break; + } + } + + if(skip) continue; + + ports[num_ports] = c->listening_port; + num_ports++; + + if(!offset) { + offset += snprintf(&buf[offset], size - offset, "%d", c->listening_port); + } else + offset += snprintf(&buf[offset], size - offset, " %d", c->listening_port); + + if(offset >= size) { + error("Exceeded buffer space for remote forwarding ports listing"); + break; + } + } + + xfree(ports); +} + int channel_cancel_rport_listener(const char *host, u_short port) { Only in openssh-6.2p1.patched/: .channels.c.swp diff -ru openssh-6.2p1/channels.h openssh-6.2p1.patched/channels.h --- openssh-6.2p1/channels.h 2012-04-22 03:21:10.000000000 +0200 +++ openssh-6.2p1.patched/channels.h 2013-05-09 23:21:37.385423623 +0200 @@ -222,6 +222,7 @@ void channel_cancel_cleanup(int); int channel_close_fd(int *); void channel_send_window_changes(void); +void channel_list_rport_listener(char *buf, size_t size); /* protocol handler */ diff -ru openssh-6.2p1/session.c openssh-6.2p1.patched/session.c --- openssh-6.2p1/session.c 2013-03-15 01:22:37.000000000 +0100 +++ openssh-6.2p1.patched/session.c 2013-05-15 23:27:12.459989713 +0200 @@ -1235,6 +1235,9 @@ xfree(laddr); child_set_env(&env, &envsize, "SSH_CONNECTION", buf); + channel_list_rport_listener(buf, sizeof buf); + child_set_env(&env, &envsize, "SSH_REMOTE_FORWARDING_PORTS", buf); + if (s->ttyfd != -1) child_set_env(&env, &envsize, "SSH_TTY", s->tty); if (s->term) Only in openssh-6.2p1.patched/: .session.c.swp From keisial at gmail.com Thu May 16 09:04:09 2013 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Thu, 16 May 2013 01:04:09 +0200 Subject: [PATCH] Specify PAM Service name in sshd_config In-Reply-To: <23791DB7-7F68-4BD2-B811-9DF0B96C5F5B@eviladmin.org> References: <23791DB7-7F68-4BD2-B811-9DF0B96C5F5B@eviladmin.org> Message-ID: <51941469.6020508@gmail.com> On 15/05/13 21:36, Ben Lindstrom wrote: > Personally think Mr Morgan's solution is more elegant as there is a single > configuration and no conflicting options. > > - Ben +1 Using a %macro in PAMServiceName is the way to go. From djm at cvs.openbsd.org Thu May 16 12:58:59 2013 From: djm at cvs.openbsd.org (Damien Miller) Date: Wed, 15 May 2013 20:58:59 -0600 (MDT) Subject: Announce: Portable OpenSSH 6.2p2 released Message-ID: <201305160258.r4G2wxmI022425@cvs.openbsd.org> This is a portable OpenSSH bugfix release. Changes since OpenSSH 6.2p1 =========================== Bugfixes: * ssh(1): Only warn for missing identity files that were explicitly specified. * Fix bug in contributed contrib/ssh-copy-id script that could result in "rm *" being called on mktemp failure. bz#2105 * sshd(8): Quiet disconnect notifications on the server from error() back to logit() from error() for normal, client-initiated disconnections. bz#2057 * Avoid conflicting definitions of __int64 on Cygwin Checksums: ========== - SHA1 (openssh-6.2p2.tar.gz) = c2b4909eba6f5ec6f9f75866c202db47f3b501ba Reporting Bugs: =============== - Please read http://www.openssh.com/report.html Security bugs should be reported directly to openssh at openssh.com OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and Ben Lindstrom. From dtucker at zip.com.au Thu May 16 16:16:01 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 16 May 2013 16:16:01 +1000 Subject: [PATCH] Expose remote forwarding ports as environment variable In-Reply-To: <20130515214523.GH12213@schottelius.org> References: <20130515214523.GH12213@schottelius.org> Message-ID: <20130516061601.GB416@gate.dtucker.net> On Wed, May 15, 2013 at 11:45:23PM +0200, Nico Schottelius wrote: > Good evening gentlemen, > > the attached patch against openssh 6.2p1 exposes remote > forwarding ports to the remote shell: That's not going to be entirely accurate because the environment is inherited at the time the shell is started, but port forwards can be added and deleted at any time (either via escape sequences or the control socket). Taking the example from your web page, you can already do what you want via the control socket: $ ssh -Nf -MS/tmp/ctl localhost $ p=`ssh -S/tmp/ctl -O forward -R 0:127.0.0.1:22 localhost` Allocated port 24647 for remote forward to 127.0.0.1:22 $ ssh -S/tmp/ctl localhost "echo do something with port $p" do something with port 24647 $ ssh -S/tmp/ctl -O exit localhost -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Thu May 16 17:08:53 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 16 May 2013 17:08:53 +1000 Subject: Session rekeying support in OpenSSH In-Reply-To: <20130515013750.GA7808@gate.dtucker.net> References: <20130513134043.GA21438@gate.dtucker.net> <20130515013750.GA7808@gate.dtucker.net> Message-ID: <20130516070853.GA7581@gate.dtucker.net> On Wed, May 15, 2013 at 11:37:50AM +1000, Darren Tucker wrote: > On Mon, May 13, 2013 at 11:40:43PM +1000, Darren Tucker wrote: > > Looks like it wouldn't be hard to add, but what problem are you trying > > to solve? > > As usual it wasn't quite as simple as I initially thought, but this adds > an optional second parameter to RekeyLimit in the client and adds > RekeyLimit to the server. Basically you should just be able to add > "RekeyLimit 1G 1h" to the config files on both the client and server. > > Patch is against -current but should apply to 6.2p1 with some fuzz. The changes to RekeyLimit have been committed and will be in the 6.3 release. Here's the same changes against the just-released 6.2p2. Index: clientloop.c =================================================================== RCS file: /var/cvs/openssh/clientloop.c,v retrieving revision 1.237 diff -u -p -r1.237 clientloop.c --- clientloop.c 9 Jan 2013 04:55:51 -0000 1.237 +++ clientloop.c 16 May 2013 06:46:59 -0000 @@ -583,7 +583,7 @@ client_wait_until_can_do_something(fd_se { struct timeval tv, *tvp; int timeout_secs; - time_t minwait_secs = 0; + time_t minwait_secs = 0, server_alive_time = 0, now = time(NULL); int ret; /* Add any selections by the channel mechanism. */ @@ -632,12 +632,16 @@ client_wait_until_can_do_something(fd_se */ timeout_secs = INT_MAX; /* we use INT_MAX to mean no timeout */ - if (options.server_alive_interval > 0 && compat20) + if (options.server_alive_interval > 0 && compat20) { timeout_secs = options.server_alive_interval; + server_alive_time = now + options.server_alive_interval; + } + if (options.rekey_interval > 0 && compat20 && !rekeying) + timeout_secs = MIN(timeout_secs, packet_get_rekey_timeout()); set_control_persist_exit_time(); if (control_persist_exit_time > 0) { timeout_secs = MIN(timeout_secs, - control_persist_exit_time - time(NULL)); + control_persist_exit_time - now); if (timeout_secs < 0) timeout_secs = 0; } @@ -669,8 +673,15 @@ client_wait_until_can_do_something(fd_se snprintf(buf, sizeof buf, "select: %s\r\n", strerror(errno)); buffer_append(&stderr_buffer, buf, strlen(buf)); quit_pending = 1; - } else if (ret == 0) - server_alive_check(); + } else if (ret == 0) { + /* + * Timeout. Could have been either keepalive or rekeying. + * Keepalive we check here, rekeying is checked in clientloop. + */ + if (server_alive_time != 0 && server_alive_time <= time(NULL)) + server_alive_check(); + } + } static void Index: monitor.c =================================================================== RCS file: /var/cvs/openssh/monitor.c,v retrieving revision 1.155 diff -u -p -r1.155 monitor.c --- monitor.c 11 Dec 2012 23:44:39 -0000 1.155 +++ monitor.c 16 May 2013 06:46:59 -0000 @@ -1799,6 +1799,10 @@ monitor_apply_keystate(struct monitor *p if (options.compression) mm_init_compression(pmonitor->m_zlib); + if (options.rekey_limit || options.rekey_interval) + packet_set_rekey_limits((u_int32_t)options.rekey_limit, + (time_t)options.rekey_interval); + /* Network I/O buffers */ /* XXX inefficient for large buffers, need: buffer_init_from_string */ buffer_clear(packet_get_input()); Index: packet.c =================================================================== RCS file: /var/cvs/openssh/packet.c,v retrieving revision 1.188.2.1 diff -u -p -r1.188.2.1 packet.c --- packet.c 10 May 2013 03:41:34 -0000 1.188.2.1 +++ packet.c 16 May 2013 06:46:59 -0000 @@ -58,6 +58,7 @@ #include #include #include +#include #include "xmalloc.h" #include "buffer.h" @@ -165,9 +166,14 @@ struct session_state { Newkeys *newkeys[MODE_MAX]; struct packet_state p_read, p_send; + /* Volume-based rekeying */ u_int64_t max_blocks_in, max_blocks_out; u_int32_t rekey_limit; + /* Time-based rekeying */ + time_t rekey_interval; /* how often in seconds */ + time_t rekey_time; /* time of last rekeying */ + /* Session key for protocol v1 */ u_char ssh1_key[SSH_SESSION_KEY_LENGTH]; u_int ssh1_keylen; @@ -1009,6 +1015,7 @@ packet_send2(void) /* after a NEWKEYS message we can send the complete queue */ if (type == SSH2_MSG_NEWKEYS) { active_state->rekeying = 0; + active_state->rekey_time = time(NULL); while ((p = TAILQ_FIRST(&active_state->outgoing))) { type = p->type; debug("dequeue packet: %u", type); @@ -1933,13 +1940,33 @@ packet_need_rekeying(void) (active_state->max_blocks_out && (active_state->p_send.blocks > active_state->max_blocks_out)) || (active_state->max_blocks_in && - (active_state->p_read.blocks > active_state->max_blocks_in)); + (active_state->p_read.blocks > active_state->max_blocks_in)) || + (active_state->rekey_interval != 0 && active_state->rekey_time + + active_state->rekey_interval <= time(NULL)); } void -packet_set_rekey_limit(u_int32_t bytes) +packet_set_rekey_limits(u_int32_t bytes, time_t seconds) { + debug3("rekey after %lld bytes, %d seconds", (long long)bytes, + (int)seconds); active_state->rekey_limit = bytes; + active_state->rekey_interval = seconds; + /* + * We set the time here so that in post-auth privsep slave we count + * from the completion of the authentication. + */ + active_state->rekey_time = time(NULL); +} + +time_t +packet_get_rekey_timeout(void) +{ + time_t seconds; + + seconds = active_state->rekey_time + active_state->rekey_interval - + time(NULL); + return (seconds <= 0 ? 1 : seconds); } void Index: packet.h =================================================================== RCS file: /var/cvs/openssh/packet.h,v retrieving revision 1.60 diff -u -p -r1.60 packet.h --- packet.h 10 Feb 2012 21:19:21 -0000 1.60 +++ packet.h 16 May 2013 06:46:59 -0000 @@ -115,7 +115,8 @@ do { \ } while (0) int packet_need_rekeying(void); -void packet_set_rekey_limit(u_int32_t); +void packet_set_rekey_limits(u_int32_t, time_t); +time_t packet_get_rekey_timeout(void); void packet_backup_state(void); void packet_restore_state(void); Index: readconf.c =================================================================== RCS file: /var/cvs/openssh/readconf.c,v retrieving revision 1.174.6.2 diff -u -p -r1.174.6.2 readconf.c --- readconf.c 5 Apr 2013 00:18:58 -0000 1.174.6.2 +++ readconf.c 16 May 2013 06:46:59 -0000 @@ -562,39 +562,54 @@ parse_yesnoask: case oRekeyLimit: arg = strdelim(&s); if (!arg || *arg == '\0') - fatal("%.200s line %d: Missing argument.", filename, linenum); - if (arg[0] < '0' || arg[0] > '9') - fatal("%.200s line %d: Bad number.", filename, linenum); - orig = val64 = strtoll(arg, &endofnumber, 10); - if (arg == endofnumber) - fatal("%.200s line %d: Bad number.", filename, linenum); - switch (toupper(*endofnumber)) { - case '\0': - scale = 1; - break; - case 'K': - scale = 1<<10; - break; - case 'M': - scale = 1<<20; - break; - case 'G': - scale = 1<<30; - break; - default: - fatal("%.200s line %d: Invalid RekeyLimit suffix", - filename, linenum); + fatal("%.200s line %d: Missing argument.", filename, + linenum); + if (strcmp(arg, "default") == 0) { + val64 = 0; + } else { + if (arg[0] < '0' || arg[0] > '9') + fatal("%.200s line %d: Bad number.", filename, + linenum); + orig = val64 = strtoll(arg, &endofnumber, 10); + if (arg == endofnumber) + fatal("%.200s line %d: Bad number.", filename, + linenum); + switch (toupper(*endofnumber)) { + case '\0': + scale = 1; + break; + case 'K': + scale = 1<<10; + break; + case 'M': + scale = 1<<20; + break; + case 'G': + scale = 1<<30; + break; + default: + fatal("%.200s line %d: Invalid RekeyLimit " + "suffix", filename, linenum); + } + val64 *= scale; + /* detect integer wrap and too-large limits */ + if ((val64 / scale) != orig || val64 > UINT_MAX) + fatal("%.200s line %d: RekeyLimit too large", + filename, linenum); + if (val64 != 0 && val64 < 16) + fatal("%.200s line %d: RekeyLimit too small", + filename, linenum); } - val64 *= scale; - /* detect integer wrap and too-large limits */ - if ((val64 / scale) != orig || val64 > UINT_MAX) - fatal("%.200s line %d: RekeyLimit too large", - filename, linenum); - if (val64 < 16) - fatal("%.200s line %d: RekeyLimit too small", - filename, linenum); if (*activep && options->rekey_limit == -1) options->rekey_limit = (u_int32_t)val64; + if (s != NULL) { /* optional rekey interval present */ + if (strcmp(s, "none") == 0) { + (void)strdelim(&s); /* discard */ + break; + } + intptr = &options->rekey_interval; + goto parse_time; + } break; case oIdentityFile: @@ -1202,6 +1217,7 @@ initialize_options(Options * options) options->no_host_authentication_for_localhost = - 1; options->identities_only = - 1; options->rekey_limit = - 1; + options->rekey_interval = -1; options->verify_host_key_dns = -1; options->server_alive_interval = -1; options->server_alive_count_max = -1; @@ -1339,6 +1355,8 @@ fill_default_options(Options * options) options->enable_ssh_keysign = 0; if (options->rekey_limit == -1) options->rekey_limit = 0; + if (options->rekey_interval == -1) + options->rekey_interval = 0; if (options->verify_host_key_dns == -1) options->verify_host_key_dns = 0; if (options->server_alive_interval == -1) Index: readconf.h =================================================================== RCS file: /var/cvs/openssh/readconf.h,v retrieving revision 1.83.6.2 diff -u -p -r1.83.6.2 readconf.h --- readconf.h 5 Apr 2013 00:18:58 -0000 1.83.6.2 +++ readconf.h 16 May 2013 06:46:59 -0000 @@ -110,6 +110,7 @@ typedef struct { int enable_ssh_keysign; int64_t rekey_limit; + int rekey_interval; int no_host_authentication_for_localhost; int identities_only; int server_alive_interval; Index: servconf.c =================================================================== RCS file: /var/cvs/openssh/servconf.c,v retrieving revision 1.231 diff -u -p -r1.231 servconf.c --- servconf.c 12 Feb 2013 00:02:08 -0000 1.231 +++ servconf.c 16 May 2013 06:46:59 -0000 @@ -20,6 +20,7 @@ #include #include +#include #include #include #include @@ -110,6 +111,8 @@ initialize_server_options(ServerOptions options->permit_user_env = -1; options->use_login = -1; options->compression = -1; + options->rekey_limit = -1; + options->rekey_interval = -1; options->allow_tcp_forwarding = -1; options->allow_agent_forwarding = -1; options->num_allow_users = 0; @@ -249,6 +252,10 @@ fill_default_server_options(ServerOption options->use_login = 0; if (options->compression == -1) options->compression = COMP_DELAYED; + if (options->rekey_limit == -1) + options->rekey_limit = 0; + if (options->rekey_interval == -1) + options->rekey_interval = 0; if (options->allow_tcp_forwarding == -1) options->allow_tcp_forwarding = FORWARD_ALLOW; if (options->allow_agent_forwarding == -1) @@ -320,7 +327,7 @@ typedef enum { sX11Forwarding, sX11DisplayOffset, sX11UseLocalhost, sStrictModes, sEmptyPasswd, sTCPKeepAlive, sPermitUserEnvironment, sUseLogin, sAllowTcpForwarding, sCompression, - sAllowUsers, sDenyUsers, sAllowGroups, sDenyGroups, + sRekeyLimit, sAllowUsers, sDenyUsers, sAllowGroups, sDenyGroups, sIgnoreUserKnownHosts, sCiphers, sMacs, sProtocol, sPidFile, sGatewayPorts, sPubkeyAuthentication, sXAuthLocation, sSubsystem, sMaxStartups, sMaxAuthTries, sMaxSessions, @@ -422,6 +429,7 @@ static struct { { "permituserenvironment", sPermitUserEnvironment, SSHCFG_GLOBAL }, { "uselogin", sUseLogin, SSHCFG_GLOBAL }, { "compression", sCompression, SSHCFG_GLOBAL }, + { "rekeylimit", sRekeyLimit, SSHCFG_ALL }, { "tcpkeepalive", sTCPKeepAlive, SSHCFG_GLOBAL }, { "keepalive", sTCPKeepAlive, SSHCFG_GLOBAL }, /* obsolete alias */ { "allowtcpforwarding", sAllowTcpForwarding, SSHCFG_ALL }, @@ -800,14 +808,14 @@ process_server_config_line(ServerOptions const char *filename, int linenum, int *activep, struct connection_info *connectinfo) { - char *cp, **charptr, *arg, *p; - int cmdline = 0, *intptr, value, value2, n; + char *cp, **charptr, *arg, *p, *endofnumber; + int cmdline = 0, *intptr, value, value2, n, port, scale; SyslogFacility *log_facility_ptr; LogLevel *log_level_ptr; ServerOpCodes opcode; - int port; u_int i, flags = 0; size_t len; + long long orig, val64; const struct multistate *multistate_ptr; cp = line; @@ -1118,6 +1126,59 @@ process_server_config_line(ServerOptions multistate_ptr = multistate_compression; goto parse_multistate; + case sRekeyLimit: + arg = strdelim(&cp); + if (!arg || *arg == '\0') + fatal("%.200s line %d: Missing argument.", filename, + linenum); + if (strcmp(arg, "default") == 0) { + val64 = 0; + } else { + if (arg[0] < '0' || arg[0] > '9') + fatal("%.200s line %d: Bad number.", filename, + linenum); + orig = val64 = strtoll(arg, &endofnumber, 10); + if (arg == endofnumber) + fatal("%.200s line %d: Bad number.", filename, + linenum); + switch (toupper(*endofnumber)) { + case '\0': + scale = 1; + break; + case 'K': + scale = 1<<10; + break; + case 'M': + scale = 1<<20; + break; + case 'G': + scale = 1<<30; + break; + default: + fatal("%.200s line %d: Invalid RekeyLimit " + "suffix", filename, linenum); + } + val64 *= scale; + /* detect integer wrap and too-large limits */ + if ((val64 / scale) != orig || val64 > UINT_MAX) + fatal("%.200s line %d: RekeyLimit too large", + filename, linenum); + if (val64 != 0 && val64 < 16) + fatal("%.200s line %d: RekeyLimit too small", + filename, linenum); + } + if (*activep && options->rekey_limit == -1) + options->rekey_limit = (u_int32_t)val64; + if (cp != NULL) { /* optional rekey interval present */ + if (strcmp(cp, "none") == 0) { + (void)strdelim(&cp); /* discard */ + break; + } + intptr = &options->rekey_interval; + goto parse_time; + } + break; + case sGatewayPorts: intptr = &options->gateway_ports; multistate_ptr = multistate_gatewayports; @@ -1718,6 +1779,8 @@ copy_set_server_options(ServerOptions *d M_CP_INTOPT(max_authtries); M_CP_INTOPT(ip_qos_interactive); M_CP_INTOPT(ip_qos_bulk); + M_CP_INTOPT(rekey_limit); + M_CP_INTOPT(rekey_interval); /* See comment in servconf.h */ COPY_MATCH_STRING_OPTS(); @@ -2005,6 +2068,8 @@ dump_config(ServerOptions *o) printf("ipqos %s ", iptos2str(o->ip_qos_interactive)); printf("%s\n", iptos2str(o->ip_qos_bulk)); + + printf("rekeylimit %lld %d\n", o->rekey_limit, o->rekey_interval); channel_print_adm_permitted_opens(); } Index: servconf.h =================================================================== RCS file: /var/cvs/openssh/servconf.h,v retrieving revision 1.99 diff -u -p -r1.99 servconf.h --- servconf.h 9 Jan 2013 04:56:45 -0000 1.99 +++ servconf.h 16 May 2013 06:46:59 -0000 @@ -176,6 +176,9 @@ typedef struct { char *authorized_keys_command; char *authorized_keys_command_user; + int64_t rekey_limit; + int rekey_interval; + char *version_addendum; /* Appended to SSH banner */ u_int num_auth_methods; Index: serverloop.c =================================================================== RCS file: /var/cvs/openssh/serverloop.c,v retrieving revision 1.173 diff -u -p -r1.173 serverloop.c --- serverloop.c 7 Dec 2012 02:07:47 -0000 1.173 +++ serverloop.c 16 May 2013 06:47:00 -0000 @@ -277,7 +277,7 @@ client_alive_check(void) */ static void wait_until_can_do_something(fd_set **readsetp, fd_set **writesetp, int *maxfdp, - u_int *nallocp, u_int max_time_milliseconds) + u_int *nallocp, u_int64_t max_time_milliseconds) { struct timeval tv, *tvp; int ret; @@ -563,7 +563,7 @@ server_loop(pid_t pid, int fdin_arg, int int wait_status; /* Status returned by wait(). */ pid_t wait_pid; /* pid returned by wait(). */ int waiting_termination = 0; /* Have displayed waiting close message. */ - u_int max_time_milliseconds; + u_int64_t max_time_milliseconds; u_int previous_stdout_buffer_bytes; u_int stdout_buffer_bytes; int type; @@ -826,6 +826,7 @@ server_loop2(Authctxt *authctxt) { fd_set *readset = NULL, *writeset = NULL; int rekeying = 0, max_fd, nalloc = 0; + u_int64_t rekey_timeout_ms = 0; debug("Entering interactive session for SSH2."); @@ -854,8 +855,13 @@ server_loop2(Authctxt *authctxt) if (!rekeying && packet_not_very_much_data_to_write()) channel_output_poll(); + if (options.rekey_interval > 0 && compat20 && !rekeying) + rekey_timeout_ms = packet_get_rekey_timeout() * 1000; + else + rekey_timeout_ms = 0; + wait_until_can_do_something(&readset, &writeset, &max_fd, - &nalloc, 0); + &nalloc, rekey_timeout_ms); if (received_sigterm) { logit("Exiting on signal %d", (int)received_sigterm); Index: ssh_config =================================================================== RCS file: /var/cvs/openssh/ssh_config,v retrieving revision 1.28 diff -u -p -r1.28 ssh_config --- ssh_config 12 Jan 2010 08:40:27 -0000 1.28 +++ ssh_config 16 May 2013 06:47:00 -0000 @@ -45,3 +45,4 @@ # PermitLocalCommand no # VisualHostKey no # ProxyCommand ssh -q -W %h:%p gateway.example.com +# RekeyLimit 1G 1h Index: ssh_config.5 =================================================================== RCS file: /var/cvs/openssh/ssh_config.5,v retrieving revision 1.161 diff -u -p -r1.161 ssh_config.5 --- ssh_config.5 9 Jan 2013 05:12:19 -0000 1.161 +++ ssh_config.5 16 May 2013 06:47:00 -0000 @@ -931,8 +931,9 @@ The default is This option applies to protocol version 2 only. .It Cm RekeyLimit Specifies the maximum amount of data that may be transmitted before the -session key is renegotiated. -The argument is the number of bytes, with an optional suffix of +session key is renegotiated, optionally followed a maximum amount of +time that may pass before the session key is renegotiated. +The first argument is specified in bytes and may have a suffix of .Sq K , .Sq M , or @@ -943,6 +944,17 @@ The default is between and .Sq 4G , depending on the cipher. +The optional second value is specified in seconds and may use any of the +units documented in the +.Sx TIME FORMATS +section of +.Xr sshd_config 5 . +The default value for +.Cm RekeyLimit +is +.Dq default none , +which means that rekeying is performed after the cipher's default amount +of data has been sent or received and no time based rekeying is done. This option applies to protocol version 2 only. .It Cm RemoteForward Specifies that a TCP port on the remote machine be forwarded over Index: sshconnect2.c =================================================================== RCS file: /var/cvs/openssh/sshconnect2.c,v retrieving revision 1.184.2.1 diff -u -p -r1.184.2.1 sshconnect2.c --- sshconnect2.c 5 Apr 2013 00:13:31 -0000 1.184.2.1 +++ sshconnect2.c 16 May 2013 06:47:00 -0000 @@ -197,8 +197,9 @@ ssh_kex2(char *host, struct sockaddr *ho if (options.kex_algorithms != NULL) myproposal[PROPOSAL_KEX_ALGS] = options.kex_algorithms; - if (options.rekey_limit) - packet_set_rekey_limit((u_int32_t)options.rekey_limit); + if (options.rekey_limit || options.rekey_interval) + packet_set_rekey_limits((u_int32_t)options.rekey_limit, + (time_t)options.rekey_interval); /* start key exchange */ kex = kex_setup(myproposal); Index: sshd.c =================================================================== RCS file: /var/cvs/openssh/sshd.c,v retrieving revision 1.420 diff -u -p -r1.420 sshd.c --- sshd.c 12 Feb 2013 00:04:48 -0000 1.420 +++ sshd.c 16 May 2013 06:47:00 -0000 @@ -2355,6 +2355,10 @@ do_ssh2_kex(void) if (options.kex_algorithms != NULL) myproposal[PROPOSAL_KEX_ALGS] = options.kex_algorithms; + if (options.rekey_limit || options.rekey_interval) + packet_set_rekey_limits((u_int32_t)options.rekey_limit, + (time_t)options.rekey_interval); + myproposal[PROPOSAL_SERVER_HOST_KEY_ALGS] = list_hostkey_types(); /* start key exchange */ Index: sshd_config =================================================================== RCS file: /var/cvs/openssh/sshd_config,v retrieving revision 1.91 diff -u -p -r1.91 sshd_config --- sshd_config 12 Feb 2013 00:02:09 -0000 1.91 +++ sshd_config 16 May 2013 06:47:00 -0000 @@ -29,6 +29,9 @@ #KeyRegenerationInterval 1h #ServerKeyBits 1024 +# Ciphers and keying +#RekeyLimit default none + # Logging # obsoletes QuietMode and FascistLogging #SyslogFacility AUTH Index: sshd_config.5 =================================================================== RCS file: /var/cvs/openssh/sshd_config.5,v retrieving revision 1.163 diff -u -p -r1.163 sshd_config.5 --- sshd_config.5 12 Feb 2013 00:02:09 -0000 1.163 +++ sshd_config.5 16 May 2013 06:47:00 -0000 @@ -799,6 +799,7 @@ Available keywords are .Cm PermitRootLogin , .Cm PermitTunnel , .Cm PubkeyAuthentication , +.Cm RekeyLimit , .Cm RhostsRSAAuthentication , .Cm RSAAuthentication , .Cm X11DisplayOffset , @@ -993,6 +994,33 @@ Specifies whether public key authenticat The default is .Dq yes . Note that this option applies to protocol version 2 only. +.It Cm RekeyLimit +Specifies the maximum amount of data that may be transmitted before the +session key is renegotiated, optionally followed a maximum amount of +time that may pass before the session key is renegotiated. +The first argument is specified in bytes and may have a suffix of +.Sq K , +.Sq M , +or +.Sq G +to indicate Kilobytes, Megabytes, or Gigabytes, respectively. +The default is between +.Sq 1G +and +.Sq 4G , +depending on the cipher. +The optional second value is specified in seconds and may use any of the +units documented in the +.Sx TIME FORMATS +section of +.Xr sshd_config 5 . +The default value for +.Cm RekeyLimit +is +.Dq default none , +which means that rekeying is performed after the cipher's default amount +of data has been sent or received and no time based rekeying is done. +This option applies to protocol version 2 only. .It Cm RevokedKeys Specifies revoked public keys. Keys listed in this file will be refused for public key authentication. -- 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 vintobe at gmail.com Thu May 16 18:15:07 2013 From: vintobe at gmail.com (Vincent Lin) Date: Thu, 16 May 2013 16:15:07 +0800 Subject: how to check whether the ssh tunnel is up In-Reply-To: <565632B3-D515-4E86-8646-1AAADD751318@alex.org.uk> References: <517B6EBA.2090903@fifthhorseman.net> <517BF349.8090004@fifthhorseman.net> <20130510093353.GB20843@greenie.muc.de> <565632B3-D515-4E86-8646-1AAADD751318@alex.org.uk> Message-ID: Alex, OK, I got it, all I want is to know the remote socket is ready so that the server side can wirte data. I will leave the rest part to the server side. I don't care whether the ssh tunnel is successful or not. And I can't know that. The server side should take care of that tunnel. Thanks Vincent On Thu, May 16, 2013 at 12:21 AM, Alex Bligh wrote: > Vincent, > > On 15 May 2013, at 15:30, Vincent Lin wrote: > > > Is that mean the only way to > > find tunnel status is to send data from server side and look forward to > > receiving the reply just like autossh? > > My conclusion when I last looked at this was that the only way to reliably > tell whether an ssh tunnel up is to send data through it in both > directions. > Using the trick autossh uses (whether you actually use autossh or not) of > paired -L and -R seems like the easiest way to do this. I was going to code > this myself and found using autossh was far easier. > > -- > Alex Bligh > > > > > From gert at greenie.muc.de Thu May 16 18:21:00 2013 From: gert at greenie.muc.de (Gert Doering) Date: Thu, 16 May 2013 10:21:00 +0200 Subject: how to check whether the ssh tunnel is up In-Reply-To: References: <517B6EBA.2090903@fifthhorseman.net> <517BF349.8090004@fifthhorseman.net> <20130510093353.GB20843@greenie.muc.de> <565632B3-D515-4E86-8646-1AAADD751318@alex.org.uk> Message-ID: <20130516082100.GO20843@greenie.muc.de> Hi, On Thu, May 16, 2013 at 04:15:07PM +0800, Vincent Lin wrote: > OK, I got it, all I want is to know the remote socket is ready so that the > server side can wirte data. I will leave the rest part to the server side. > I don't care whether the ssh tunnel is successful or not. And I can't know > that. The server side should take care of that tunnel. You actually can't know whether the remote socket is ready for *you* without checking the full path back to you - some other user on the remote machine might already have opened the specific remote forwarding port before... gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From kenneth.schmidt at pnnl.gov Fri May 17 01:52:42 2013 From: kenneth.schmidt at pnnl.gov (Schmidt, Kenneth P) Date: Thu, 16 May 2013 08:52:42 -0700 Subject: [PATCH] Specify PAM Service name in sshd_config In-Reply-To: <23791DB7-7F68-4BD2-B811-9DF0B96C5F5B@eviladmin.org> Message-ID: On 5/15/13 12:36 p.m., "Ben Lindstrom" wrote: > >On May 15, 2013, at 2:03 PM, Jan Pechanec wrote: > >> On Wed, 15 May 2013, Schmidt, Kenneth P wrote: >[..] >>> Why not just use the PAMServiceName and use a Flag to indicate that the >>> authentication method should be appended to the PAM service? So >>>something >>> like >>> >>> PAMServiceName admincli >>> PAMAppendAuthMethod yes >>> >>> would be admincli-kbdint. That way both the pam service and the auth >>> method could be specified without worrying about the options being >>> mutually exclusive and preventing a possible invalid configuration to >>>be >>> specified. >> >> I personally think it's more complicated since you'd always need >> both options' values to figure out what will be the PAM service name, >> either explicitly stated in the config file or their implicit default >> value(s). J. > > >Personally think Mr Morgan's solution is more elegant as there is a single >configuration and no conflicting options. > >- Ben >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev I agree. I will code something up and submit a new patch that allows macros. I don't know what values are available at the point of authentication, but it looks like anything in the authentication context and global options are easily available. I will start with the executable, the authentication method, and the server port initially and see if there are any other options we want to add later. From alex at alex.org.uk Fri May 17 03:11:33 2013 From: alex at alex.org.uk (Alex Bligh) Date: Thu, 16 May 2013 18:11:33 +0100 Subject: [PATCH] Expose remote forwarding ports as environment variable In-Reply-To: <20130516061601.GB416@gate.dtucker.net> References: <20130515214523.GH12213@schottelius.org> <20130516061601.GB416@gate.dtucker.net> Message-ID: <3A9FE87B-FEF9-449B-9815-F40AEDAA7F55@alex.org.uk> On 16 May 2013, at 07:16, Darren Tucker wrote: >> the attached patch against openssh 6.2p1 exposes remote >> forwarding ports to the remote shell: > > That's not going to be entirely accurate because the environment is > inherited at the time the shell is started, but port forwards can be > added and deleted at any time (either via escape sequences or the > control socket). > > Taking the example from your web page, you can already do what you want > via the control socket: Any ideas on how you can do this server side? EG, I have n people with different public keys, Alice, Bob, Charlie, who each ssh in with a forceCommand or similar to stop them doing anything except a -R port forwarding, using the same UID. At the server end, I want to connect to Alice's -R forwarding. I can't rely on Alice telling me which -R port she's connecting to, as she might tell me Bob's port. So I need to know which session is associated Alice using server side information only. I have a nasty hack which (in essence) involves making forceCommand run something server side which records the PID of sshd, looks at the table of listening sockets, sees what processes own them, and links up the two. This is pretty disgusting. -- Alex Bligh From nico-openssh-unix-dev at schottelius.org Fri May 17 05:53:44 2013 From: nico-openssh-unix-dev at schottelius.org (Nico Schottelius) Date: Thu, 16 May 2013 21:53:44 +0200 Subject: [PATCH] Expose remote forwarding ports as environment variable In-Reply-To: <20130516061601.GB416@gate.dtucker.net> References: <20130515214523.GH12213@schottelius.org> <20130516061601.GB416@gate.dtucker.net> Message-ID: <20130516195344.GD24264@schottelius.org> Darren Tucker [Thu, May 16, 2013 at 04:16:01PM +1000]: > On Wed, May 15, 2013 at 11:45:23PM +0200, Nico Schottelius wrote: > > Good evening gentlemen, > > > > the attached patch against openssh 6.2p1 exposes remote > > forwarding ports to the remote shell: > > That's not going to be entirely accurate because the environment is > inherited at the time the shell is started, but port forwards can be > added and deleted at any time (either via escape sequences or the > control socket). That's a very good point, although I believe that the majority of remote port forwardings is defined using -R and is never changed in almost any cases. That said, I'd propose to change the variable name to reflect this and/or add a hint to the manpage describing this behaviour. > Taking the example from your web page, you can already do what you want > via the control socket: > > $ ssh -Nf -MS/tmp/ctl localhost > $ p=`ssh -S/tmp/ctl -O forward -R 0:127.0.0.1:22 localhost` > Allocated port 24647 for remote forward to 127.0.0.1:22 > $ ssh -S/tmp/ctl localhost "echo do something with port $p" > do something with port 24647 > $ ssh -S/tmp/ctl -O exit localhost This is not exactly what I'm trying to accomplish. I am sorry, I may have not made my intention clear enough. My objective is to be able to connect back to the client directly after the connection has been established from the server, most likely using the authorized_keys file. Let me show you an example: controlhost:~cdist/.ssh/authorized_keys: command="cdist callback",no-pty ssh-dss... targethost% ssh -R 0:localhost:22 cdist at controlhost cdist callback cdist callback then uses the first value found in $SSH_REMOTE_FORWARDING_PORTS and connects to that port to configure the target host. As pointed out by Alex, the patch I've provided solves the problem to manage this for a possibly huge number of targethosts. Without this patch, it's a guess and hack to find out how to connect back. I do think that for most use cases it is sufficient to only consider the remote port forwardings as given on the command line. The extension to support multiple remote port forwardings is in my opinion already a nice to have. Hope this makes it more clear. Cheers, Nico -- PGP key: 7ED9 F7D3 6B10 81D7 0EC5 5C09 D7DC C8E4 3187 7DF0 From djm at mindrot.org Fri May 17 09:42:54 2013 From: djm at mindrot.org (Damien Miller) Date: Fri, 17 May 2013 09:42:54 +1000 (EST) Subject: [PATCH] Specify PAM Service name in sshd_config In-Reply-To: <20130515180940.GC5003@linux124.nas.nasa.gov> References: <20130515180940.GC5003@linux124.nas.nasa.gov> Message-ID: On Wed, 15 May 2013, Iain Morgan wrote: > Hmm, what if PAMServiceName supported some % macros? Some candidates > would be %c for the executable, %m for the authentication method, and %p > for the server port. > > This would allow something like: > > PAMServiceName %c-%m > > or > > PAMServiceName admincli-%m I think this approach is reasonable. Whomever implements it, please include host address too :) I'm not sure what changes will be necessary to support this - remember that we now offer multiple auth, so a user might run pubkey+kbdint or GSSAPI+password. Which auth, account and session stack should we run in these cases? -d From djm at mindrot.org Fri May 17 11:58:50 2013 From: djm at mindrot.org (Damien Miller) Date: Fri, 17 May 2013 11:58:50 +1000 (EST) Subject: [PATCH] Specify PAM Service name in sshd_config In-Reply-To: References: <20130515180940.GC5003@linux124.nas.nasa.gov> Message-ID: On Fri, 17 May 2013, Damien Miller wrote: > I think this approach is reasonable. Whomever implements it, please > include host address too :) Sorry, _local bind address_ From dtucker at zip.com.au Fri May 17 14:26:56 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 17 May 2013 14:26:56 +1000 Subject: [PATCH] Specify PAM Service name in sshd_config In-Reply-To: References: <20130515180940.GC5003@linux124.nas.nasa.gov> Message-ID: <20130517042656.GA9197@gate.dtucker.net> On Fri, May 17, 2013 at 11:58:50AM +1000, Damien Miller wrote: > On Fri, 17 May 2013, Damien Miller wrote: > > > I think this approach is reasonable. Whomever implements it, please > > include host address too :) > > Sorry, _local bind address_ Here's the existing values across all of the places they show up: http://www.dtucker.net/openssh/percent_expand_opts.html Please try not to make it any more inconsistent :-) -- 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 philipp.marek at linbit.com Fri May 17 15:19:16 2013 From: philipp.marek at linbit.com (Philipp Marek) Date: Fri, 17 May 2013 07:19:16 +0200 Subject: [PATCH] Expose remote forwarding ports as environment variable In-Reply-To: <3A9FE87B-FEF9-449B-9815-F40AEDAA7F55@alex.org.uk> References: <20130515214523.GH12213@schottelius.org> <20130516061601.GB416@gate.dtucker.net> <3A9FE87B-FEF9-449B-9815-F40AEDAA7F55@alex.org.uk> Message-ID: <7657053.38PeM2k2i6@cacao> > At the server end, I want to connect to Alice's -R forwarding. > I can't rely on Alice telling me which -R port she's connecting > to, as she might tell me Bob's port. So I need to know which > session is associated Alice using server side information only. > > I have a nasty hack which (in essence) involves making forceCommand > run something server side which records the PID of sshd, looks > at the table of listening sockets, sees what processes own them, > and links up the two. This is pretty disgusting. If you need a local TCP port, how about using socat to link it to SSH's stdin/stdout, and (if needed) do the reverse on the server side? Then there's no port actually forwarded (just the "normal" data flow), so there won't (and can't) be any collisions, and you can simply determine which port is _really_ in use. Regards, Phil From vintobe at gmail.com Fri May 17 16:30:41 2013 From: vintobe at gmail.com (Vincent Lin) Date: Fri, 17 May 2013 14:30:41 +0800 Subject: how to check whether the ssh tunnel is up In-Reply-To: <20130516082100.GO20843@greenie.muc.de> References: <517B6EBA.2090903@fifthhorseman.net> <517BF349.8090004@fifthhorseman.net> <20130510093353.GB20843@greenie.muc.de> <565632B3-D515-4E86-8646-1AAADD751318@alex.org.uk> <20130516082100.GO20843@greenie.muc.de> Message-ID: Hi Gert, But SSH knows. I have added some code in the openssh client part. If the remote socket is ready, the ssh server will send the result to the ssh client. Once the client receives the result, I can write to a file. And other process can read the status from the file. Thanks Vincent On Thu, May 16, 2013 at 4:21 PM, Gert Doering wrote: > Hi, > > On Thu, May 16, 2013 at 04:15:07PM +0800, Vincent Lin wrote: > > OK, I got it, all I want is to know the remote socket is ready so that > the > > server side can wirte data. I will leave the rest part to the server > side. > > I don't care whether the ssh tunnel is successful or not. And I can't > know > > that. The server side should take care of that tunnel. > > You actually can't know whether the remote socket is ready for *you* > without checking the full path back to you - some other user on the > remote machine might already have opened the specific remote forwarding > port before... > > gert > -- > USENET is *not* the non-clickable part of WWW! > // > www.muc.de/~gert/ > Gert Doering - Munich, Germany > gert at greenie.muc.de > fax: +49-89-35655025 > gert at net.informatik.tu-muenchen.de > From nico-openssh-unix-dev at schottelius.org Fri May 17 22:53:17 2013 From: nico-openssh-unix-dev at schottelius.org (Nico Schottelius) Date: Fri, 17 May 2013 14:53:17 +0200 Subject: [PATCH] Expose remote forwarding ports as environment variable In-Reply-To: <7657053.38PeM2k2i6@cacao> References: <20130515214523.GH12213@schottelius.org> <20130516061601.GB416@gate.dtucker.net> <3A9FE87B-FEF9-449B-9815-F40AEDAA7F55@alex.org.uk> <7657053.38PeM2k2i6@cacao> Message-ID: <20130517125317.GE24264@schottelius.org> Philipp Marek [Fri, May 17, 2013 at 07:19:16AM +0200]: > > [...] > > I have a nasty hack which (in essence) involves making forceCommand > > run something server side which records the PID of sshd, looks > > at the table of listening sockets, sees what processes own them, > > and links up the two. This is pretty disgusting. > If you need a local TCP port, how about using socat to link it to SSH's > stdin/stdout, and (if needed) do the reverse on the server side? I was actually considering this option before writing the patch. Unfortunately there are various problems with this approach, to name two: - It requires socat additionally on both sides - Socat only allows 1 (!) connection and exits afterwards, so it does not solve the problem of accessing the box multiple times (like required by cdist/ccollect) Furthermore, one of the biggest advantages of using ssh code is that robust code to handle the problem is already in place. OpenSSH just would need to expose this information. > Then there's no port actually forwarded (just the "normal" data flow), > so there won't (and can't) be any collisions, and you can simply > determine which port is _really_ in use. Yep, would have been nice if it worked easily and reliably. Cheers, Nico socat session: ~/.ssh/authorized_keys: command="socat - TCP-LISTEN:1234" ssh-rsa AAAAB3NzaC1yc [13:21] bento:~% socat TCP4:localhost:22,forever "EXEC:ssh nico-dev-vm-snr01" Pseudo-terminal will not be allocated because stdin is not a terminal. [root at nico-dev-vm-snr01 yum.repos.d]# ssh -p 1234 root at localhost exit [13:21] bento:~% socat TCP4:localhost:22,forever "EXEC:ssh nico-dev-vm-snr01" Pseudo-terminal will not be allocated because stdin is not a terminal. [13:32] bento:~% -----> socat exits after the ssh connection was closed -- PGP key: 7ED9 F7D3 6B10 81D7 0EC5 5C09 D7DC C8E4 3187 7DF0 From dtucker at zip.com.au Fri May 17 23:30:03 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 17 May 2013 23:30:03 +1000 Subject: [PATCH] Expose remote forwarding ports as environment variable In-Reply-To: <20130517125317.GE24264@schottelius.org> References: <20130515214523.GH12213@schottelius.org> <20130516061601.GB416@gate.dtucker.net> <3A9FE87B-FEF9-449B-9815-F40AEDAA7F55@alex.org.uk> <7657053.38PeM2k2i6@cacao> <20130517125317.GE24264@schottelius.org> Message-ID: On Fri, May 17, 2013 at 10:53 PM, Nico Schottelius < nico-openssh-unix-dev at schottelius.org> wrote: > Unfortunately there are various problems with this approach, > Markus actually added support to ProxyCommand to allow it to use stdin and stdout directly so you can make ssh talk back to an sshd on the "client" end via a pair of named pipes. It's a bit Rube Goldberg but knowing Markus I don't doubt it works. 1) on the client create a pair of named pipes 2) have ssh #1 on the client invoke a controlmaster ssh -N #2 on the server with the latter using "ProxyCommand=-". Redirect ssh #1's stdio to and from the named pipes and background it. client$ ssh tossh -T -y server ssh -y -N -T -MS/tmp/ctl -oProxyCommand=- client & 3) start and sshd on the client with its stdin connected to those named pipes: client$ /usr/sbin/sshd -i -f < $fromssh > $tossh 4) on the server, use the control socket to talk to the sshd running on the "client". server$ ssh -S /tmp/ctl client You could probably use socat on the machine to connect stdio on ssh and sshd on the client which might be cleaner. In either case there's no listening port for someone else to stumble apon. -- 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 rak at debian.org Sat May 18 00:06:31 2013 From: rak at debian.org (Ryan Kavanagh) Date: Fri, 17 May 2013 10:06:31 -0400 Subject: [PATCH] Allow matching HostName against Host entries In-Reply-To: <20130503030737.GG6176@nu.ryanak.ca> <20130503023215.GF6176@nu.ryanak.ca> Message-ID: <20130517140631.GA31084@nu.ryanak.ca> Hi all, On Thu, May 02, 2013 at 10:32:15PM -0400, Ryan Kavanagh wrote: > Please let me know if you have any questions/concerns/comments, and if > the patch below addresses the previously raised concerns. Again, I think this patch would be useful to have incorporated into OpenSSH. Is there anything I can do to help get it incorporated / reviewed? Does anybody have any remaining concerns, or is it mostly an issue of someone getting around to applying it? Best wishes, Ryan From nico-openssh-unix-dev at schottelius.org Sat May 18 00:09:32 2013 From: nico-openssh-unix-dev at schottelius.org (Nico Schottelius) Date: Fri, 17 May 2013 16:09:32 +0200 Subject: [PATCH] Expose remote forwarding ports as environment variable In-Reply-To: References: <20130515214523.GH12213@schottelius.org> <20130516061601.GB416@gate.dtucker.net> <3A9FE87B-FEF9-449B-9815-F40AEDAA7F55@alex.org.uk> <7657053.38PeM2k2i6@cacao> <20130517125317.GE24264@schottelius.org> Message-ID: <20130517140932.GT1515@schottelius.org> Darren Tucker [Fri, May 17, 2013 at 11:30:03PM +1000]: > On Fri, May 17, 2013 at 10:53 PM, Nico Schottelius < > nico-openssh-unix-dev at schottelius.org> wrote: > > > Unfortunately there are various problems with this approach, > > > > Markus actually added support to ProxyCommand to allow it to use stdin and > stdout directly so you can make ssh talk back to an sshd on the "client" > end via a pair of named pipes. It's a bit Rube Goldberg but knowing Markus > I don't doubt it works. > > 1) on the client create a pair of named pipes > 2) have ssh #1 on the client invoke a controlmaster ssh -N #2 on the server > with the latter using "ProxyCommand=-". Redirect ssh #1's stdio to and from > the named pipes and background it. > > client$ ssh tossh -T -y server ssh -y -N -T -MS/tmp/ctl > -oProxyCommand=- client & > > 3) start and sshd on the client with its stdin connected to those named > pipes: > > client$ /usr/sbin/sshd -i -f < $fromssh > $tossh > > 4) on the server, use the control socket to talk to the sshd running on the > "client". > server$ ssh -S /tmp/ctl client > > You could probably use socat on the machine to connect stdio on ssh and > sshd on the client which might be cleaner. In either case there's no > listening port for someone else to stumble apon. That is but a very cool solution. I must admit, I've not considered this approach beforehand. I must confess that I like this approach, not just because it's very advanced and creative usage, Independently of this, I was wondering, if my supplied patch could be applied anyhow, because I think it makes ssh callback easier to access. Cheers, Nico -- PGP key: 7ED9 F7D3 6B10 81D7 0EC5 5C09 D7DC C8E4 3187 7DF0 From alex at alex.org.uk Sat May 18 00:38:23 2013 From: alex at alex.org.uk (Alex Bligh) Date: Fri, 17 May 2013 15:38:23 +0100 Subject: [PATCH] Expose remote forwarding ports as environment variable In-Reply-To: References: <20130515214523.GH12213@schottelius.org> <20130516061601.GB416@gate.dtucker.net> <3A9FE87B-FEF9-449B-9815-F40AEDAA7F55@alex.org.uk> <7657053.38PeM2k2i6@cacao> <20130517125317.GE24264@schottelius.org> Message-ID: <33E6BA9B-B688-4FDB-ABD6-6A276934B3F6@alex.org.uk> On 17 May 2013, at 14:30, Darren Tucker wrote: > 1) on the client create a pair of named pipes > 2) have ssh #1 on the client invoke a controlmaster ssh -N #2 on the server > with the latter using "ProxyCommand=-". Redirect ssh #1's stdio to and from > the named pipes and background it. > > client$ ssh tossh -T -y server ssh -y -N -T -MS/tmp/ctl > -oProxyCommand=- client & The problem for me is at this step. You have to trust the client's command on the server. What happens if they don't pass the correct -MS command? In my application the clients are untrusted machines which may be behind NATs etc. -- Alex Bligh From dtucker at zip.com.au Sat May 18 08:07:54 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 18 May 2013 08:07:54 +1000 Subject: [PATCH] Expose remote forwarding ports as environment variable In-Reply-To: <33E6BA9B-B688-4FDB-ABD6-6A276934B3F6@alex.org.uk> References: <20130515214523.GH12213@schottelius.org> <20130516061601.GB416@gate.dtucker.net> <3A9FE87B-FEF9-449B-9815-F40AEDAA7F55@alex.org.uk> <7657053.38PeM2k2i6@cacao> <20130517125317.GE24264@schottelius.org> <33E6BA9B-B688-4FDB-ABD6-6A276934B3F6@alex.org.uk> Message-ID: On Sat, May 18, 2013 at 12:38 AM, Alex Bligh wrote: > > On 17 May 2013, at 14:30, Darren Tucker wrote: > [...] > > client$ ssh tossh -T -y server ssh -y -N -T -MS/tmp/ctl > > -oProxyCommand=- client & > > > The problem for me is at this step. You have to trust the client's command > on the server. What happens if they don't pass the correct -MS command? > Enforce it via ForceCommand? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From alex at alex.org.uk Sat May 18 19:02:54 2013 From: alex at alex.org.uk (Alex Bligh) Date: Sat, 18 May 2013 10:02:54 +0100 Subject: [PATCH] Expose remote forwarding ports as environment variable In-Reply-To: References: <20130515214523.GH12213@schottelius.org> <20130516061601.GB416@gate.dtucker.net> <3A9FE87B-FEF9-449B-9815-F40AEDAA7F55@alex.org.uk> <7657053.38PeM2k2i6@cacao> <20130517125317.GE24264@schottelius.org> <33E6BA9B-B688-4FDB-ABD6-6A276934B3F6@alex.org.uk> Message-ID: On 17 May 2013, at 23:07, Darren Tucker wrote: >> >> >> On 17 May 2013, at 14:30, Darren Tucker wrote: >> [...] >>> client$ ssh tossh -T -y server ssh -y -N -T -MS/tmp/ctl >>> -oProxyCommand=- client & >> >> >> The problem for me is at this step. You have to trust the client's command >> on the server. What happens if they don't pass the correct -MS command? >> > > Enforce it via ForceCommand? Doh - it's a parameter to the second ssh, not the first - sorry. -- Alex Bligh From tmartincpp at gmail.com Tue May 21 18:25:46 2013 From: tmartincpp at gmail.com (Thomas Martin) Date: Tue, 21 May 2013 10:25:46 +0200 Subject: SSH users authentication depending on their public key. Message-ID: Hi everyone. I'm looking for a way to identify my SSH's users according to their public key; I mean I would like to have their name logged in my bash session (in a shared unix account). I put this in my .profile: export HISTTIMEFORMAT="[%Y-%m-%d %H:%M:%S - $SSH_USER] " So now I'm trying to make OpenSSH fill the "SSH_USER" variable. First I have to exclude the PermitUserEnvironment possibility for securities reasons as said in the manual (and so I can't use the "environment" directive in authorized_keys). I saw the AcceptEnv and SendEnv directives but I don't want to depend on clients settings. So I did some tries with the "command" directive in authorized_keys and I'm able to manage interactive or non-interactive sessions but I don't know how to deal with sshfs/sftp use. Also according to me this is not an elegant solution but I wasn't able to find on other way until then. Here is my authorized_keys: command="sh -c 'SSH_KEY_USER=thomas /tmp/test.sh ${SSH_ORIGINAL_COMMAND:-}'" ssh-rsa publickey thomas at host.domain Here is the /tmp/test.sh script: #!/bin/bash # set -e # if [ ! -z $SSH_TTY ]; then /bin/bash -l elif [ ! -z $1 ]; then $* fi exit 0 Do you have any other solutions? Am I missing something ? Unfortunately I can't create one unix account by ssh key... Unix accounts are shared by two or more users; this is why I would love to know who did futures mistakes ;) Thanks in advance. Thanks. From djm at mindrot.org Tue May 21 19:43:29 2013 From: djm at mindrot.org (Damien Miller) Date: Tue, 21 May 2013 19:43:29 +1000 (EST) Subject: SSH users authentication depending on their public key. In-Reply-To: References: Message-ID: On Tue, 21 May 2013, Thomas Martin wrote: > Hi everyone. > > I'm looking for a way to identify my SSH's users according to their > public key; I mean I would like to have their name logged in my bash > session (in a shared unix account). > I put this in my .profile: > export HISTTIMEFORMAT="[%Y-%m-%d %H:%M:%S - $SSH_USER] " > > So now I'm trying to make OpenSSH fill the "SSH_USER" variable. Where SSH_USER is what, exactly? There are proposals to expose the key (or fingerprint thereof) used to authenticate a user under SSH_AUTH_KEY, but there are some corner cases to do with multiple authentication to be worked out. > First I have to exclude the PermitUserEnvironment possibility for > securities reasons as said in the manual (and so I can't use the > "environment" directive in authorized_keys). I think PermitUserEnvironment is safe if the users' shell is statically linked and it clears LD_* before doing anything else. Maybe we should make it a pattern-list of variables to accept though. I.e. PermitUserEnvironment BLAH*,LC_* Would allow any environment variable matching the wildcards. Alternately (and this is easier to do). You could move the AuthorizedKeysFile to be root-controlled (root-owned file and directory), comment out the parts of session.c that load ~/.ssh/environment and then turn PermitUserEnvironment back on. The user would have no way of setting arbitrary environment variables (assuming they don't have root) and you could use environment=... options in authorized_keys as much as you like. -d From keisial at gmail.com Tue May 21 20:27:52 2013 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Tue, 21 May 2013 12:27:52 +0200 Subject: SSH users authentication depending on their public key. In-Reply-To: References: Message-ID: <519B4C28.7010307@gmail.com> On 21/05/13 10:25, Thomas Martin wrote: > Hi everyone. > > I'm looking for a way to identify my SSH's users according to their > public key; I mean I would like to have their name logged in my bash > session (in a shared unix account). > I put this in my .profile: > export HISTTIMEFORMAT="[%Y-%m-%d %H:%M:%S - $SSH_USER] " > > So now I'm trying to make OpenSSH fill the "SSH_USER" variable. > (...) > Here is my authorized_keys: > command="sh -c 'SSH_KEY_USER=thomas /tmp/test.sh > ${SSH_ORIGINAL_COMMAND:-}'" ssh-rsa publickey thomas at host.domain It may be simpler to use /usr/bin/env SSH_KEY_USER=thomas ${SSH_ORIGINAL_COMMAND:-} ssh-rsa ... > Do you have any other solutions? Am I missing something ? > Unfortunately I can't create one unix account by ssh key... Unix > accounts are shared by two or more users; this is why I would love to > know who did futures mistakes ;) I guess you alreadu know this is just oportunistic logging, and any user could impersonate another one or even avoid that it gets registered. It's strange that you can't afford one account per user (even if they then eg. sudo to run the commands under the shared account). From tmartincpp at gmail.com Tue May 21 21:07:16 2013 From: tmartincpp at gmail.com (Thomas Martin) Date: Tue, 21 May 2013 13:07:16 +0200 Subject: SSH users authentication depending on their public key. In-Reply-To: References: Message-ID: 2013/5/21 Damien Miller : > Where SSH_USER is what, exactly? > SSH_USER is a string which represent a name (like "thomas" for example). > There are proposals to expose the key (or fingerprint thereof) used to > authenticate a user under SSH_AUTH_KEY, but there are some corner cases > to do with multiple authentication to be worked out. I saw the post which talk about SSH_AUTH_KEY, I think this is a good possibility. > I think PermitUserEnvironment is safe if the users' shell is statically > linked and it clears LD_* before doing anything else. Maybe we should > make it a pattern-list of variables to accept though. I.e. > > PermitUserEnvironment BLAH*,LC_* > > Would allow any environment variable matching the wildcards. According to me that would be a really really great feature which should improve a lot the security of the PermitUserEnvironment directive. Also you are probably right about the security of the shell itself, I don't know is this is the case for bash, I will take a look. > Alternately (and this is easier to do). You could move the > AuthorizedKeysFile to be root-controlled (root-owned file and directory), > comment out the parts of session.c that load ~/.ssh/environment and > then turn PermitUserEnvironment back on. The user would have no way of > setting arbitrary environment variables (assuming they don't have root) > and you could use environment=... options in authorized_keys as much > as you like. > > -d I already have authorized_keys files in a read-only directory so indeed this trick could do the job (actually I hoped to avoid to recompile OpenSSH but why not). Thanks. From tmartincpp at gmail.com Tue May 21 21:29:09 2013 From: tmartincpp at gmail.com (Thomas Martin) Date: Tue, 21 May 2013 13:29:09 +0200 Subject: SSH users authentication depending on their public key. In-Reply-To: <519B4C28.7010307@gmail.com> References: <519B4C28.7010307@gmail.com> Message-ID: 2013/5/21 ?ngel Gonz?lez : > It may be simpler to use /usr/bin/env SSH_KEY_USER=thomas > ${SSH_ORIGINAL_COMMAND:-} ssh-rsa ... > This solution will work with non-interactive sessions but not with shells as SSH will execute env as a login shell when I try to login: Authorized_keys: command="/usr/bin/env SSH_KEY_USER=maxime ${SSH_ORIGINAL_COMMAND:-}" ssh-rsa blablabla Tests: $ ssh server1 -l root "uptime" 13:15:06 up 19 days, 1:45, 4 users, load average: 1.93, 1.20, 0.89 $ ssh server1 -l root TERM=xterm SHELL=/bin/bash SSH_CLIENT=10.1.0.206 54241 22 SSH_TTY=/dev/pts/4 USER=root blablabla > I guess you alreadu know this is just oportunistic logging, and any user > could impersonate another one or even avoid that it gets registered. Indeed I'm aware of this, but you are right I should precise this. Actually I trust my end-users, I would like to add the username in the bash history only to know faster who did the change which breaks the production by mistake (I mean that kind of stuff). > > It's strange that you can't afford one account per user (even if they then > eg. sudo to run the commands under the shared account). Technically this is possible but that will make us change all of our process (so this is not a solution until a while). From jakob at kirei.se Wed May 22 21:36:28 2013 From: jakob at kirei.se (Jakob Schlyter) Date: Wed, 22 May 2013 13:36:28 +0200 Subject: SSHFP support for ssh-keyscan? Message-ID: <11923C87-C237-41AC-A74E-A7C2782BE9CE@kirei.se> Greetings, Has anyone looked at implementing SSHFP support for ssh-keyscan? It should be a rather easy task, but I would like to make sure no one else is doing this before I start. jakob From alexs at prol.etari.at Thu May 23 19:41:29 2013 From: alexs at prol.etari.at (alexs) Date: Thu, 23 May 2013 10:41:29 +0100 Subject: Time for key stretching in encrypted private =?UTF-8?Q?keys=3F?= Message-ID: In 0.9.7 the private key encryption was switched from 3DES to AES, (https://bugzilla.mindrot.org/show_bug.cgi?id=1550) the motivation for this being that 128-bits of security is better than the 112 or so you get from 3DES these days. Interestingly that bug is about upgrading to AES-256, but we ended up with AES-128. Presumably due to the Solaris crippling? However ssh-keygen still uses a relatively weak KDF of MD5(IV[:8] . PWORD) which makes dictionary attacks quite feasible and means you need a much longer password to mitigate them. Seems like it might be useful if OpenSSH at least had the option of using an encoding with some decent key stretching to me. Is there any good reason not to, and to not have it as the default? OpenSSH seems quite happy to accept PKCS8 keys with PBKDF2 currently, it just doesn't generate them. You just need to do it yourself e.g. http://martin.kleppmann.com/ssh-keys.html The keys generated in that article are also 3DES unfortunately but that's only because it's the default cipher here. From Geoff_Lowe at McAfee.com Fri May 24 01:19:10 2013 From: Geoff_Lowe at McAfee.com (Geoff_Lowe at McAfee.com) Date: Thu, 23 May 2013 15:19:10 +0000 Subject: =?windows-1255?Q?RE:_Support_for_"ssh-rsa-sha256"_and_"ssh-dss-sha256"_?= =?windows-1255?Q?=3F=FE?= In-Reply-To: References: Message-ID: <2B830C10D3A65B42856BB9DDF14806900E215C@MIVEXAMER1N2.corp.nai.org> I would like to add support for this request also. Thanks, Geoff "with a G" -----Original Message----- Sent: Tuesday, May 14, 2013 7:33 PM To: openssh-unix-dev at mindrot.org Subject: Support for "ssh-rsa-sha256" and "ssh-dss-sha256" ?? Functionality request for supporting Digital Signatures for RSA and DSS Public Key Algorithms in alignment with NIST SP800-131A. I assume this has been asked before, but I could not find in the archives. Support of "ssh-rsa-sha256" and "ssh-dss-sha256" public key algorithms for OpenSSH? I know Suite B Algorithms and x509 SSH Extension Algorithms are supported, but not a path some folks (us) want to take. Tectia supports similar algorithms via their own extensions in commercial SSH. Are these algorithms being worked on for OpenSSH or been previously rejected? Assuming not rejected, and no one working on it, if I were to do the work and create the patch set, would it be accepted into the mainline? Thanks, Jeff _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From tmartincpp at gmail.com Fri May 24 01:53:17 2013 From: tmartincpp at gmail.com (Thomas Martin) Date: Thu, 23 May 2013 17:53:17 +0200 Subject: SSH users authentication depending on their public key. In-Reply-To: References: Message-ID: >> Alternately (and this is easier to do). You could move the >> AuthorizedKeysFile to be root-controlled (root-owned file and directory), >> comment out the parts of session.c that load ~/.ssh/environment and >> then turn PermitUserEnvironment back on. The user would have no way of >> setting arbitrary environment variables (assuming they don't have root) >> and you could use environment=... options in authorized_keys as much >> as you like. >> >> -d > > I already have authorized_keys files in a read-only directory so > indeed this trick could do the job (actually I hoped to avoid to > recompile OpenSSH but why not). > I did what you suggested and it seems to work as expected. Here is the diff (based on Debian Squeeze OpenSSH sources): diff -rupN openssh-5.5p1/session.c openssh-5.5p1.new/session.c --- openssh-5.5p1/session.c 2010-03-26 01:04:09.000000000 +0100 +++ openssh-5.5p1.new/session.c 2013-05-23 16:44:49.000000000 +0200 @@ -1289,11 +1289,13 @@ do_setup_env(Session *s, const char *she auth_sock_name); /* read $HOME/.ssh/environment. */ + /* if (options.permit_user_env && !options.use_login) { snprintf(buf, sizeof buf, "%.200s/.ssh/environment", strcmp(pw->pw_dir, "/") ? pw->pw_dir : ""); read_environment_file(&env, &envsize, buf); } + */ if (debug_flag) { /* dump the environment */ fprintf(stderr, "Environment:\n"); Yes I just had to comment 5 lines :X (what a great first patch in C ;). Thanks again for the suggestion, I think it will do the job without adding potentials security issues. Thomas From no_spam_98 at yahoo.com Fri May 24 06:03:27 2013 From: no_spam_98 at yahoo.com (no_spam_98 at yahoo.com) Date: Thu, 23 May 2013 13:03:27 -0700 (PDT) Subject: Support for "ssh-rsa-sha256" and "ssh-dss-sha256" ? Message-ID: <1369339407.74770.YahooMailNeo@web140601.mail.bf1.yahoo.com> I completely support this request. ?My organization is interested in supporting these public key algorithms to comply with NIST SP 800-131A too. Jeff, it is my understanding that through RFC4419, OpenSSH can be support the Key Agreement Using Diffie-Hellman and MQV guidelines in SP 800-131A using the "diffie-hellman-group-exchange-sha256" method. ?Is that correct? Thanks. From danm at prime.gushi.org Fri May 24 10:19:52 2013 From: danm at prime.gushi.org (Dan Mahoney, System Admin) Date: Thu, 23 May 2013 17:19:52 -0700 (PDT) Subject: Utility to scan for unpassworded SSH privkeys? Message-ID: Hey all, Let's make an assumption: 1) I am a root user on a system. 2) I don't want said system being used as a jumping-off point if either a user account or the root account is compromised. Given an unencrypted private key, plus a known_hosts file, plus bash_history, it's a pretty easy avenue of attack once you're in the front door. And it's happened before*. Thus, what I'd like to do is (in the spirit of crack's "nastygram" script), trawl through user .ssh directories and warn users with insecure keys (or warn root). I'm shocked I can't find something that does this with a basic google search. Debian offers their ssh-vulnkey tool, but that checks for something different (weak RNG-seeded keys). Has anyone come across something like this? Better still, written it? It seems to me that something like this should be in /contrib, but that's just me. My ears are open. -Dan *(http://it.slashdot.org/story/12/11/17/143219/freebsd-project-discloses-security-breach-via-stolen-ssh-key) http://threatpost.com/apache-site-hacked-through-ssh-key-compromise-082809/ -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --------------------------- From dan at doxpara.com Fri May 24 10:39:56 2013 From: dan at doxpara.com (Dan Kaminsky) Date: Thu, 23 May 2013 17:39:56 -0700 Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: References: Message-ID: <0A51B1AF-EDAD-4867-BFCF-E6BFF504DE42@doxpara.com> Effectively nobody passphrases their ssh keys. They're used as a way to *suppress* password entry in the real world -- use this, and things just work rather than poking you each time. Sent from my iPhone On May 23, 2013, at 5:19 PM, "Dan Mahoney, System Admin" wrote: > Hey all, > > Let's make an assumption: > > 1) I am a root user on a system. > > 2) I don't want said system being used as a jumping-off point if either a user account or the root account is compromised. > > Given an unencrypted private key, plus a known_hosts file, plus bash_history, it's a pretty easy avenue of attack once you're in the front door. And it's happened before*. > > Thus, what I'd like to do is (in the spirit of crack's "nastygram" script), trawl through user .ssh directories and warn users with insecure keys (or warn root). > > I'm shocked I can't find something that does this with a basic google search. Debian offers their ssh-vulnkey tool, but that checks for something different (weak RNG-seeded keys). > > Has anyone come across something like this? Better still, written it? > > It seems to me that something like this should be in /contrib, but that's just me. > > My ears are open. > > -Dan > > *(http://it.slashdot.org/story/12/11/17/143219/freebsd-project-discloses-security-breach-via-stolen-ssh-key) > http://threatpost.com/apache-site-hacked-through-ssh-key-compromise-082809/ > > -- > > --------Dan Mahoney-------- > Techie, Sysadmin, WebGeek > Gushi on efnet/undernet IRC > ICQ: 13735144 AIM: LarpGM > Site: http://www.gushi.org > --------------------------- > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From danm at prime.gushi.org Fri May 24 11:21:20 2013 From: danm at prime.gushi.org (Dan Mahoney, System Admin) Date: Thu, 23 May 2013 18:21:20 -0700 (PDT) Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: <0A51B1AF-EDAD-4867-BFCF-E6BFF504DE42@doxpara.com> References: <0A51B1AF-EDAD-4867-BFCF-E6BFF504DE42@doxpara.com> Message-ID: On Thu, 23 May 2013, Dan Kaminsky wrote: > Effectively nobody passphrases their ssh keys. They're used as a way to > *suppress* password entry in the real world -- use this, and things just > work rather than poking you each time. I'm aware of this stigma, which is the current popular (and lazy) thinking. That's why I laid out assumptions #1 and #2. I can't make people use passwordless everywhere. However, if I'm giving you space in my garage, I want to know you're not storing rusting propane cylinders :) -Dan -- "You're a nomad billygoat!" -Juston, July 18th, 2002 --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --------------------------- From jamie.beverly at yahoo.com Fri May 24 11:23:42 2013 From: jamie.beverly at yahoo.com (Jamie Beverly) Date: Thu, 23 May 2013 18:23:42 -0700 Subject: Utility to scan for unpassworded SSH privkeys? Message-ID: <1828634178.815549.1369358638343.JavaMail.webspher@njbbicssmp03> I like to retain some semblance of optimism for humanity, and so I'm just going to hope that this assertion is false. I have to hope that there is at least a large minority of people who correctly use ssh-agent for the suppression of password prompting, and protect their private keys with passwords.? -------- Original message -------- From: Dan Kaminsky Date: 05/23/2013 5:39 PM (GMT-08:00) To: "Dan Mahoney, System Admin" Cc: openssh-unix-dev at mindrot.org Subject: Re: Utility to scan for unpassworded SSH privkeys? Effectively nobody passphrases their ssh keys.? They're used as a way to *suppress* password entry in the real world -- use this, and things just work rather than poking you each time. Sent from my iPhone On May 23, 2013, at 5:19 PM, "Dan Mahoney, System Admin" wrote: > Hey all, > > Let's make an assumption: > > 1) I am a root user on a system. > > 2) I don't want said system being used as a jumping-off point if either a user account or the root account is compromised. > > Given an unencrypted private key, plus a known_hosts file, plus bash_history, it's a pretty easy avenue of attack once you're in the front door.? And it's happened before*. > > Thus, what I'd like to do is (in the spirit of crack's "nastygram" script), trawl through user .ssh directories and warn users with insecure keys (or warn root). > > I'm shocked I can't find something that does this with a basic google search.? Debian offers their ssh-vulnkey tool, but that checks for something different (weak RNG-seeded keys). > > Has anyone come across something like this?? Better still, written it? > > It seems to me that something like this should be in /contrib, but that's just me. > > My ears are open. > > -Dan > > *(http://it.slashdot.org/story/12/11/17/143219/freebsd-project-discloses-security-breach-via-stolen-ssh-key) > http://threatpost.com/apache-site-hacked-through-ssh-key-compromise-082809/ > > -- > > --------Dan Mahoney-------- > Techie,? Sysadmin,? WebGeek > Gushi on efnet/undernet IRC > ICQ: 13735144?? AIM: LarpGM > Site:? http://www.gushi.org > --------------------------- > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Fri May 24 11:20:38 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 24 May 2013 11:20:38 +1000 Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: References: Message-ID: <20130524012038.GA20919@gate.dtucker.net> On Thu, May 23, 2013 at 05:19:52PM -0700, Dan Mahoney, System Admin wrote: > Thus, what I'd like to do is (in the spirit of crack's "nastygram" > script), trawl through user .ssh directories and warn users with > insecure keys (or warn root). The key files are PEM format PKCS#8 and you can use openssl to test whether or not the private keys need a passphrase: $ openssl rsa -in id_rsa_nopass -passin pass: -noout 2>/dev/null ; echo $? 0 $ openssl rsa -in id_rsa_pass -passin pass: -noout 2>/dev/null ; echo $? 1 You can't tell by inspection of the authorized_keys file (it wasn't clear if that's what you wanted). -- 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 danm at prime.gushi.org Fri May 24 11:31:10 2013 From: danm at prime.gushi.org (Dan Mahoney, System Admin) Date: Thu, 23 May 2013 18:31:10 -0700 (PDT) Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: <20130524012038.GA20919@gate.dtucker.net> References: <20130524012038.GA20919@gate.dtucker.net> Message-ID: On Fri, 24 May 2013, Darren Tucker wrote: > On Thu, May 23, 2013 at 05:19:52PM -0700, Dan Mahoney, System Admin wrote: >> Thus, what I'd like to do is (in the spirit of crack's "nastygram" >> script), trawl through user .ssh directories and warn users with >> insecure keys (or warn root). > > The key files are PEM format PKCS#8 and you can use openssl to test > whether or not the private keys need a passphrase: > > $ openssl rsa -in id_rsa_nopass -passin pass: -noout 2>/dev/null ; echo $? > 0 > > $ openssl rsa -in id_rsa_pass -passin pass: -noout 2>/dev/null ; echo $? > 1 > > You can't tell by inspection of the authorized_keys file (it wasn't > clear if that's what you wanted). No, I knew that and wanted what you specified. Thanks for this. This is workable into something basic. -Dan -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --------------------------- From dtucker at zip.com.au Fri May 24 11:32:01 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 24 May 2013 11:32:01 +1000 Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: <0A51B1AF-EDAD-4867-BFCF-E6BFF504DE42@doxpara.com> References: <0A51B1AF-EDAD-4867-BFCF-E6BFF504DE42@doxpara.com> Message-ID: <20130524013201.GB20919@gate.dtucker.net> On Thu, May 23, 2013 at 05:39:56PM -0700, Dan Kaminsky wrote: > Effectively nobody passphrases their ssh keys. They're used as a way > to *suppress* password entry in the real world -- use this, and things > just work rather than poking you each time. Well some people do use ssh-agent or equivalent so the key is at least encrypted on disk. -- 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 May 24 11:31:02 2013 From: dan at doxpara.com (Dan Kaminsky) Date: Thu, 23 May 2013 18:31:02 -0700 Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: References: <0A51B1AF-EDAD-4867-BFCF-E6BFF504DE42@doxpara.com> Message-ID: It's 2013. Time to start actually caring how users use our systems. On Thu, May 23, 2013 at 6:21 PM, Dan Mahoney, System Admin < danm at prime.gushi.org> wrote: > On Thu, 23 May 2013, Dan Kaminsky wrote: > > Effectively nobody passphrases their ssh keys. They're used as a way to >> *suppress* password entry in the real world -- use this, and things just >> work rather than poking you each time. >> > > I'm aware of this stigma, which is the current popular (and lazy) > thinking. That's why I laid out assumptions #1 and #2. I can't make > people use passwordless everywhere. > > However, if I'm giving you space in my garage, I want to know you're not > storing rusting propane cylinders :) > > -Dan > > -- > > "You're a nomad billygoat!" > > -Juston, July 18th, 2002 > > > --------Dan Mahoney-------- > Techie, Sysadmin, WebGeek > Gushi on efnet/undernet IRC > ICQ: 13735144 AIM: LarpGM > Site: http://www.gushi.org > --------------------------- > > From dan at doxpara.com Fri May 24 11:41:44 2013 From: dan at doxpara.com (Dan Kaminsky) Date: Thu, 23 May 2013 18:41:44 -0700 Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: <20130524013201.GB20919@gate.dtucker.net> References: <0A51B1AF-EDAD-4867-BFCF-E6BFF504DE42@doxpara.com> <20130524013201.GB20919@gate.dtucker.net> Message-ID: Some being the operative word. (And no, not crapping on good work. Prepping to do quite a bit *more* work.) On Thu, May 23, 2013 at 6:32 PM, Darren Tucker wrote: > On Thu, May 23, 2013 at 05:39:56PM -0700, Dan Kaminsky wrote: > > Effectively nobody passphrases their ssh keys. They're used as a way > > to *suppress* password entry in the real world -- use this, and things > > just work rather than poking you each time. > > Well some people do use ssh-agent or equivalent so the key is at least > encrypted on disk. > > -- > 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 djm at mindrot.org Fri May 24 13:27:27 2013 From: djm at mindrot.org (Damien Miller) Date: Fri, 24 May 2013 13:27:27 +1000 (EST) Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: <20130524012038.GA20919@gate.dtucker.net> References: <20130524012038.GA20919@gate.dtucker.net> Message-ID: On Fri, 24 May 2013, Darren Tucker wrote: > On Thu, May 23, 2013 at 05:19:52PM -0700, Dan Mahoney, System Admin wrote: > > Thus, what I'd like to do is (in the spirit of crack's "nastygram" > > script), trawl through user .ssh directories and warn users with > > insecure keys (or warn root). > > The key files are PEM format PKCS#8 and you can use openssl to test > whether or not the private keys need a passphrase: > > $ openssl rsa -in id_rsa_nopass -passin pass: -noout 2>/dev/null ; echo $? > 0 > > $ openssl rsa -in id_rsa_pass -passin pass: -noout 2>/dev/null ; echo $? > 1 more hacky but faster: grep for ^DEK-Info in the private keys files -d From djm at mindrot.org Fri May 24 13:32:16 2013 From: djm at mindrot.org (Damien Miller) Date: Fri, 24 May 2013 13:32:16 +1000 (EST) Subject: Time for key stretching in encrypted private keys? In-Reply-To: References: Message-ID: On Thu, 23 May 2013, alexs wrote: > In 0.9.7 the private key encryption was switched from 3DES to AES, > (https://bugzilla.mindrot.org/show_bug.cgi?id=1550) the motivation for this > being that 128-bits of security is better than the 112 or so you get from > 3DES these days. Interestingly that bug is about upgrading to AES-256, but > we ended up with AES-128. Presumably due to the Solaris crippling? Right :( > However ssh-keygen still uses a relatively weak KDF of MD5(IV[:8] . PWORD) > which makes dictionary attacks quite feasible and means you need a much > longer password to mitigate them. Seems like it might be useful if OpenSSH > at least had the option of using an encoding with some decent key > stretching to me. Is there any good reason not to, and to not have it as > the default? > > OpenSSH seems quite happy to accept PKCS8 keys with PBKDF2 currently, it > just doesn't generate them. You just need to do it yourself e.g. > http://martin.kleppmann.com/ssh-keys.html The keys generated in that > article are also 3DES unfortunately but that's only because it's the > default cipher here. Ideally OpenSSL would make some PEM extension that uses a good KDF. I don't include PBKDF2 with an inner hash of SHA* in this set :) Barring that We'll probably roll a simple key format that uses bcrypt as a KDF and includes some space to optionally bundle certificates. -d From mouring at eviladmin.org Fri May 24 13:34:15 2013 From: mouring at eviladmin.org (Ben Lindstrom) Date: Thu, 23 May 2013 22:34:15 -0500 Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: References: Message-ID: On May 23, 2013, at 7:19 PM, "Dan Mahoney, System Admin" wrote: > Hey all, > > Let's make an assumption: > > 1) I am a root user on a system. > > 2) I don't want said system being used as a jumping-off point if either a user account or the root account is compromised. > > Given an unencrypted private key, plus a known_hosts file, plus bash_history, it's a pretty easy avenue of attack once you're in the front door. And it's happened before*. > > Thus, what I'd like to do is (in the spirit of crack's "nastygram" script), trawl through user .ssh directories and warn users with insecure keys (or warn root). > > I'm shocked I can't find something that does this with a basic google search. Debian offers their ssh-vulnkey tool, but that checks for something different (weak RNG-seeded keys). > > Has anyone come across something like this? Better still, written it? > > It seems to me that something like this should be in /contrib, but that's just me. > > My ears are open. Three comments: 1. Set this in /etc/ssh/ssh_config and advocate people use it. HashKnownHosts Indicates that ssh(1) should hash host names and addresses when they are added to ~/.ssh/known_hosts. These hashed names may be used normally by ssh(1) and sshd(8), but they do not reveal iden- tifying information should the file's contents be disclosed. The default is ``no''. Note that existing names and addresses in known hosts files will not be converted automatically, but may be manually hashed using ssh-keygen(1). This stops your "known host" issues. 2. Discourage people from leaving PRIVATE KEYS on your server. The only place they should live is on the user's laptop (hopefully password protected) and encourage good ssh-agent usage (something I always advocate to my users and do myself). This stops people from breaking one ssh account, finding a local exploit and stealing other keys to other people's sites. 3. Encourage (disable offending accounts) people using in their ~/.ssh/authorized_keys files for *EACH* key they place. from="pattern-list" Specifies that in addition to public key authentication, either the canonical name of the remote host or its IP address must be present in the comma-separated list of patterns. See PATTERNS in ssh_config(5) for more information on patterns. In addition to the wildcard matching that may be applied to host- names or addresses, a from stanza may match IP addresses using CIDR address/masklen notation. The purpose of this option is to optionally increase security: public key authentication by itself does not trust the network or name servers or anything (but the key); however, if somebody somehow steals the key, the key permits an intruder to log in from anywhere in the world. This additional option makes using a stolen key more difficult (name servers and/or routers would have to be compromised in addition to just the key). This helps protect against "wandering private key syndrome." As it is locked down a bit more. Personally if I were going to allow my system to be a general shell server for even close friends. I'd have cron jobs disabling, deleting, or otherwise ensuring the the last two are respected. And it would be clearly posted. *shrug* But frankly, I advocate the above three items for years. - Ben From danm at prime.gushi.org Fri May 24 16:04:42 2013 From: danm at prime.gushi.org (Dan Mahoney, System Admin) Date: Thu, 23 May 2013 23:04:42 -0700 (PDT) Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: References: Message-ID: On Thu, 23 May 2013, Ben Lindstrom wrote: Note that my question was about how to build a specific tool, but as you've made some good points I'm interested in continuing the discussion on this. Apologies to anyone who finds this thread looking for the same sort of tool I was. > 1. Set this in /etc/ssh/ssh_config and advocate people use it. > HashKnownHosts > Indicates that ssh(1) should hash host names and addresses when > they are added to ~/.ssh/known_hosts. These hashed names may be > used normally by ssh(1) and sshd(8), but they do not reveal iden- > tifying information should the file's contents be disclosed. The > default is ``no''. Note that existing names and addresses in > known hosts files will not be converted automatically, but may be > manually hashed using ssh-keygen(1). > > This stops your "known host" issues. Right. Know of it and use it. I've asked on the development for this list in the past for a similar option for the "host" option in .ssh/config -- i.e. instead of "when logging into this host" set a line that says "when logging into a host that matches this hashed name", so instead of: "host foo" in ssh_config you'd have hosthash 4xqLy4bIRGoQjI/B+eaFwQtYHZ8=|apHjHU+VYNEqDkPKZpI8ZPIPraA= There's still the problem of shell histories, grepping headers of email, throwing a port into PROMISC mode, getting it from netflow, and the like. Bug: ssh-keygen -H doesn't let you specify a path to your known_hosts file. > 2. Discourage people from leaving PRIVATE KEYS on your server. The only > place they should live is on the user's laptop (hopefully password > protected) and encourage good ssh-agent usage (something I always > advocate to my users and do myself). In general, I try to advocate this. It's my feeling that if I say "hey, I've encrypted this key for you, you can do X in the future" that's enough for me. Some people trust my system (which lives behind locked doors) more than their laptops and use it for dev and jumping-off. (Insert different rant here about how I want screen and ssh-agent to play nicely together). ? > This stops people from breaking one ssh account, finding a local exploit > and stealing other keys to other people's sites. > 3. Encourage (disable offending accounts) people using in their > ~/.ssh/authorized_keys files for *EACH* key they place. > > from="pattern-list" (snip) And yet there's not yet a requirement that dnssec be present for that. Different rant. :) Also, as I *do* log in from many, many IP ranges (friends' houses, cellular networks, datacenters), a non-starter for me, and others. I have friends who travel to alaska and work in salmon canneries for six months. I'm not about to hunt down the IP range of whatever godawful spotty internet they have up there. I am a big fan of hostsentry for this issue tho. In some perfect world, PAM would also know about this stuff and would present additional challenges when logging in from new hosts/ranges. > This helps protect against "wandering private key syndrome." As it is > locked down a bit more. > > Personally if I were going to allow my system to be a general shell > server for even close friends. I'd have cron jobs disabling, deleting, > or otherwise ensuring the the last two are respected. And it would be > clearly posted. That would be why I asked. Also, I'd like to blog about this, put the scripts out there and tell people to use them. The fact that I couldn't find an easy tool to do so is at least a small part of the issue. :) -Dan -- --------Dan Mahoney-------- Techie, Sysadmin, WebGeek Gushi on efnet/undernet IRC ICQ: 13735144 AIM: LarpGM Site: http://www.gushi.org --------------------------- From alexs at prol.etari.at Fri May 24 18:57:04 2013 From: alexs at prol.etari.at (alexs) Date: Fri, 24 May 2013 09:57:04 +0100 Subject: Time for key stretching in encrypted private =?UTF-8?Q?keys=3F?= In-Reply-To: References: Message-ID: <5f5301bf96c6e07de85fbc69c205663c@prol.etari.at> On Fri, 24 May 2013 13:32:16 +1000 (EST), Damien Miller wrote: > On Thu, 23 May 2013, alexs wrote: >> However ssh-keygen still uses a relatively weak KDF of MD5(IV[:8] . >> PWORD) >> which makes dictionary attacks quite feasible and means you need a much >> longer password to mitigate them. Seems like it might be useful if >> OpenSSH >> at least had the option of using an encoding with some decent key >> stretching to me. Is there any good reason not to, and to not have it as >> the default? >> >> OpenSSH seems quite happy to accept PKCS8 keys with PBKDF2 currently, it >> just doesn't generate them. You just need to do it yourself e.g. >> http://martin.kleppmann.com/ssh-keys.html The keys generated in that >> article are also 3DES unfortunately but that's only because it's the >> default cipher here. > > Ideally OpenSSL would make some PEM extension that uses a good KDF. > I don't include PBKDF2 with an inner hash of SHA* in this set :) > > Barring that We'll probably roll a simple key format that uses bcrypt > as a KDF and includes some space to optionally bundle certificates. > It sounds like you have plans already :) Any idea what sort of time scale this might occur on? PBKDF2 seems like it has a better chance at being backward compatible with existing installs, even if it's a few factors of 10 worse than [sb]crypt et al. I assume the 3DES -> AES change didn't break backwards compat, presumably with bcrypt you'll have to delay setting it as the default for a few releases first? From djm at mindrot.org Fri May 24 21:44:30 2013 From: djm at mindrot.org (Damien Miller) Date: Fri, 24 May 2013 21:44:30 +1000 (EST) Subject: Time for key stretching in encrypted private keys? In-Reply-To: <5f5301bf96c6e07de85fbc69c205663c@prol.etari.at> References: <5f5301bf96c6e07de85fbc69c205663c@prol.etari.at> Message-ID: On Fri, 24 May 2013, alexs wrote: > > Ideally OpenSSL would make some PEM extension that uses a good KDF. > > I don't include PBKDF2 with an inner hash of SHA* in this set :) > > > > Barring that We'll probably roll a simple key format that uses bcrypt > > as a KDF and includes some space to optionally bundle certificates. > > It sounds like you have plans already :) Any idea what sort of time scale > this might occur on? > > PBKDF2 seems like it has a better chance at being backward compatible with > existing installs, even if it's a few factors of 10 worse than [sb]crypt et > al. I assume the 3DES -> AES change didn't break backwards compat, > presumably with bcrypt you'll have to delay setting it as the default for a > few releases first? Backwards compat isn't so important for private keys, since they are not widely copied between systems (hopefully). We just need some way to convert to/from the new format (whether is an update to PEM or something we do ourselves). -d From dtucker at zip.com.au Fri May 24 21:56:00 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 24 May 2013 21:56:00 +1000 Subject: Time for key stretching in encrypted private keys? In-Reply-To: References: <5f5301bf96c6e07de85fbc69c205663c@prol.etari.at> Message-ID: <20130524115600.GA26086@gate.dtucker.net> On Fri, May 24, 2013 at 09:44:30PM +1000, Damien Miller wrote: > Backwards compat isn't so important for private keys, since they are > not widely copied between systems (hopefully). Home directories that are shared between machines are not unknown, though. -- 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 djm at mindrot.org Fri May 24 22:08:06 2013 From: djm at mindrot.org (Damien Miller) Date: Fri, 24 May 2013 22:08:06 +1000 (EST) Subject: Support for "ssh-rsa-sha256" and "ssh-dss-sha256" ? In-Reply-To: <1369339407.74770.YahooMailNeo@web140601.mail.bf1.yahoo.com> References: <1369339407.74770.YahooMailNeo@web140601.mail.bf1.yahoo.com> Message-ID: On Thu, 23 May 2013, no_spam_98 at yahoo.com wrote: > Jeff, it is my understanding that through RFC4419, OpenSSH can be > support the Key Agreement Using Diffie-Hellman and MQV guidelines in > SP 800-131A using the "diffie-hellman-group-exchange-sha256" method. > Is that correct? I think any of the ECDH methods would fit the bill too. From djm at mindrot.org Fri May 24 22:17:52 2013 From: djm at mindrot.org (Damien Miller) Date: Fri, 24 May 2013 22:17:52 +1000 (EST) Subject: =?ISO-8859-8?Q?Re=3A_Support_for_=22ssh-rsa-sha256=22_and_=22ssh-dss-sha256=22_=3F=FE?= In-Reply-To: References: Message-ID: On Tue, 14 May 2013, Jeffrey Hawkins wrote: > Functionality request for supporting Digital Signatures for RSA and DSS > Public Key Algorithms in alignment with NIST SP800-131A. > > I > assume this has been asked before, but I could not find in the > archives. Support of "ssh-rsa-sha256" and "ssh-dss-sha256" public key > algorithms for OpenSSH? I know Suite B Algorithms and x509 SSH > Extension Algorithms are supported, but not a path some folks (us) want > to take. Tectia supports similar algorithms via their own extensions > in commercial SSH. Adding the signature code is easy (see below for a hacky diff - not for use), it's going through and duplicating all the ssh-rsa code to support ssh-rsa-sha256 and dealing with the corner cases that it tricky. E.g. when we find a PEM RSA key on disk, do we load it as a ssh-rsa key, a ssh-rsa-sha256 key or both? There are more difficulties to do with certificates too when they are signed with RSA keys - should the signature be ssh-rsa or ssh-rsa-sha256? There are probably some other traps that haven't occurred to me yet :( Please file a bug at https://bugzilla.mindrot.org/ so we can thrash this out. -d Index: compat.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/compat.c,v retrieving revision 1.81 diff -u -p -r1.81 compat.c --- compat.c 17 May 2013 00:13:13 -0000 1.81 +++ compat.c 24 May 2013 12:01:33 -0000 @@ -93,6 +93,7 @@ compat_datafellows(const char *version) { "Sun_SSH_1.0*", SSH_BUG_NOREKEY|SSH_BUG_EXTEOF}, { "OpenSSH_4*", 0 }, { "OpenSSH_5*", SSH_NEW_OPENSSH|SSH_BUG_DYNAMIC_RPORT}, + { "OpenSSH_6.2xxx*", SSH_NEW_OPENSSH|SSH_NEW_RSA_SHA2}, { "OpenSSH*", SSH_NEW_OPENSSH }, { "*MindTerm*", 0 }, { "2.1.0*", SSH_BUG_SIGBLOB|SSH_BUG_HMAC| Index: compat.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/compat.h,v retrieving revision 1.43 diff -u -p -r1.43 compat.h --- compat.h 23 Sep 2011 07:45:05 -0000 1.43 +++ compat.h 24 May 2013 12:01:33 -0000 @@ -59,6 +59,7 @@ #define SSH_BUG_RFWD_ADDR 0x02000000 #define SSH_NEW_OPENSSH 0x04000000 #define SSH_BUG_DYNAMIC_RPORT 0x08000000 +#define SSH_NEW_RSA_SHA2 0x10000000 void enable_compat13(void); void enable_compat20(void); Index: ssh-rsa.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/ssh-rsa.c,v retrieving revision 1.46 diff -u -p -r1.46 ssh-rsa.c --- ssh-rsa.c 17 May 2013 00:13:14 -0000 1.46 +++ ssh-rsa.c 24 May 2013 12:01:33 -0000 @@ -32,7 +32,7 @@ static int openssh_RSA_verify(int, u_char *, u_int, u_char *, u_int, RSA *); -/* RSASSA-PKCS1-v1_5 (PKCS #1 v2.0 signature) with SHA1 */ +/* RSASSA-PKCS1-v1_5 (PKCS #1 v2.0 signature) with SHA1 or SHA256 */ int ssh_rsa_sign(const Key *key, u_char **sigp, u_int *lenp, const u_char *data, u_int datalen) @@ -44,14 +44,28 @@ ssh_rsa_sign(const Key *key, u_char **si int ok, nid; Buffer b; - if (key == NULL || key->rsa == NULL || (key->type != KEY_RSA && - key->type != KEY_RSA_CERT && key->type != KEY_RSA_CERT_V00)) { - error("ssh_rsa_sign: no RSA key"); + if (key == NULL || key->rsa == NULL) { + error("%s: no RSA key", __func__); + return -1; + } + nid = NID_sha1; + if ((datafellows & SSH_BUG_RSASIGMD5) != 0) + nid = NID_md5; + else if ((datafellows & SSH_NEW_RSA_SHA2) != 0) { + nid = NID_sha256; + } + switch (key->type) { + case KEY_RSA: + case KEY_RSA_CERT: + case KEY_RSA_CERT_V00: + break; + default: + error("%s: wrong type key %s (%d)", + __func__, key_type(key), key->type); return -1; } - nid = (datafellows & SSH_BUG_RSASIGMD5) ? NID_md5 : NID_sha1; if ((evp_md = EVP_get_digestbynid(nid)) == NULL) { - error("ssh_rsa_sign: EVP_get_digestbynid %d failed", nid); + error("%s: EVP_get_digestbynid %d failed", __func__, nid); return -1; } EVP_DigestInit(&md, evp_md); @@ -67,7 +81,7 @@ ssh_rsa_sign(const Key *key, u_char **si if (ok != 1) { int ecode = ERR_get_error(); - error("ssh_rsa_sign: RSA_sign failed: %s", + error("%s: RSA_sign failed: %s", __func__, ERR_error_string(ecode, NULL)); free(sig); return -1; @@ -78,7 +92,7 @@ ssh_rsa_sign(const Key *key, u_char **si memmove(sig + diff, sig, len); memset(sig, 0, diff); } else if (len > slen) { - error("ssh_rsa_sign: slen %u slen2 %u", slen, len); + error("%s: slen %u slen2 %u", __func__, slen, len); free(sig); return -1; } @@ -112,21 +126,37 @@ ssh_rsa_verify(const Key *key, const u_c u_int len, dlen, modlen; int rlen, ret, nid; - if (key == NULL || key->rsa == NULL || (key->type != KEY_RSA && - key->type != KEY_RSA_CERT && key->type != KEY_RSA_CERT_V00)) { - error("ssh_rsa_verify: no RSA key"); + if (key == NULL || key->rsa == NULL) { + error("%s: no RSA key", __func__); + return -1; + } + nid = NID_sha1; + if ((datafellows & SSH_BUG_RSASIGMD5) != 0) + nid = NID_md5; + else if ((datafellows & SSH_NEW_RSA_SHA2) != 0) { + nid = NID_sha256; + } + switch (key->type) { + case KEY_RSA: + case KEY_RSA_CERT: + case KEY_RSA_CERT_V00: + break; + default: + error("%s: wrong type key %s (%d)", + __func__, key_type(key), key->type); return -1; } if (BN_num_bits(key->rsa->n) < SSH_RSA_MINIMUM_MODULUS_SIZE) { - error("ssh_rsa_verify: RSA modulus too small: %d < minimum %d bits", - BN_num_bits(key->rsa->n), SSH_RSA_MINIMUM_MODULUS_SIZE); + error("%s: RSA modulus too small: %d < minimum %d bits", + __func__, BN_num_bits(key->rsa->n), + SSH_RSA_MINIMUM_MODULUS_SIZE); return -1; } buffer_init(&b); buffer_append(&b, signature, signaturelen); ktype = buffer_get_cstring(&b, NULL); if (strcmp("ssh-rsa", ktype) != 0) { - error("ssh_rsa_verify: cannot handle type %s", ktype); + error("%s: cannot handle type %s", __func__, ktype); buffer_free(&b); free(ktype); return -1; @@ -136,28 +166,27 @@ ssh_rsa_verify(const Key *key, const u_c rlen = buffer_len(&b); buffer_free(&b); if (rlen != 0) { - error("ssh_rsa_verify: remaining bytes in signature %d", rlen); + error("%s: remaining bytes in signature %d", __func__, rlen); free(sigblob); return -1; } /* RSA_verify expects a signature of RSA_size */ modlen = RSA_size(key->rsa); if (len > modlen) { - error("ssh_rsa_verify: len %u > modlen %u", len, modlen); + error("%s: len %u > modlen %u", __func__, len, modlen); free(sigblob); return -1; } else if (len < modlen) { u_int diff = modlen - len; - debug("ssh_rsa_verify: add padding: modlen %u > len %u", - modlen, len); + debug("%s: add padding: modlen %u > len %u", + __func__, modlen, len); sigblob = xrealloc(sigblob, 1, modlen); memmove(sigblob + diff, sigblob, len); memset(sigblob, 0, diff); len = modlen; } - nid = (datafellows & SSH_BUG_RSASIGMD5) ? NID_md5 : NID_sha1; if ((evp_md = EVP_get_digestbynid(nid)) == NULL) { - error("ssh_rsa_verify: EVP_get_digestbynid %d failed", nid); + error("%s: EVP_get_digestbynid %d failed", __func__, nid); free(sigblob); return -1; } @@ -169,7 +198,7 @@ ssh_rsa_verify(const Key *key, const u_c memset(digest, 'd', sizeof(digest)); memset(sigblob, 's', len); free(sigblob); - debug("ssh_rsa_verify: signature %scorrect", (ret==0) ? "in" : ""); + debug("%s: signature %scorrect", __func__, (ret==0) ? "in" : ""); return ret; } @@ -196,12 +225,27 @@ static const u_char id_sha1[] = { */ static const u_char id_md5[] = { 0x30, 0x20, /* type Sequence, length 0x20 (32) */ - 0x30, 0x0c, /* type Sequence, length 0x09 */ - 0x06, 0x08, /* type OID, length 0x05 */ + 0x30, 0x0c, /* type Sequence, length 0x0c (12) */ + 0x06, 0x08, /* type OID, length 0x08 */ 0x2a, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, /* id-md5 */ 0x05, 0x00, /* NULL */ 0x04, 0x10 /* Octet string, length 0x10 (16), followed by md5 hash */ }; +/* + * See http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.html + * id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) + * organization(1) gov(101) csor(3) nistAlgorithm(4) hashAlgs(2) + * id-sha256(1) } + */ +static const u_char id_sha256[] = { + 0x30, 0x31, /* type Sequence, length 0x31 (49) */ + 0x30, 0x0d, /* type Sequence, length 0x0d (13) */ + 0x06, 0x09, /* type OID, length 0x09 */ + 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, /* id-sha256 */ + 0x05, 0x00, /* NULL */ + 0x04, 0x20 /* Octet string, length 0x20 (32), followed by sha256 hash */ +}; + static int openssh_RSA_verify(int type, u_char *hash, u_int hashlen, @@ -218,6 +262,11 @@ openssh_RSA_verify(int type, u_char *has oid = id_sha1; oidlen = sizeof(id_sha1); hlen = 20; + break; + case NID_sha256: + oid = id_sha256; + oidlen = sizeof(id_sha256); + hlen = 32; break; case NID_md5: oid = id_md5; Index: version.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/version.h,v retrieving revision 1.66 diff -u -p -r1.66 version.h --- version.h 10 Feb 2013 21:19:34 -0000 1.66 +++ version.h 24 May 2013 12:01:33 -0000 @@ -1,3 +1,3 @@ /* $OpenBSD: version.h,v 1.66 2013/02/10 21:19:34 markus Exp $ */ -#define SSH_VERSION "OpenSSH_6.2" +#define SSH_VERSION "OpenSSH_6.2xxx" From nkadel at gmail.com Fri May 24 22:43:24 2013 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Fri, 24 May 2013 07:43:24 -0500 Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: <1828634178.815549.1369358638343.JavaMail.webspher@njbbicssmp03> References: <1828634178.815549.1369358638343.JavaMail.webspher@njbbicssmp03> Message-ID: On Thu, May 23, 2013 at 8:23 PM, Jamie Beverly wrote: > I like to retain some semblance of optimism for humanity, and so I'm just going to hope that this assertion is false. I have to hope that there is at least a large minority of people who correctly use ssh-agent for the suppression of password prompting, and protect their private keys with passwords. This is not a new flaw. It dates right back to the original SSH-1 and SSH-2, which were forked to create OpenSSH. It's also why the highly vaunted security of OpenBSD is fairly pointless, when such gaping configuration holes are the *default* configuration. ssh-keygen creates passphrase frees by default if you simply hit "Enter" a few times, and there is no way I've ever seen for ssh_config to reject them by default when loading local keys or loading them into an ssh-agent. My repeated surveys of environments with NFS home directories show that at least 10% often far more, of SSH keys are not protected. And the people who are worst about their passphrase keys tend to be admins who "know better" and who follow the common security model of "if you don't trust the machine you're on, you shouldn't be working on it", and therefore refuse to follow even the most basic security practices. It's a big reason that I encourage migration to Kerberos based authentication wherever possible, but that doesn't work well for Subversion or git authentication. From sfrost at snowman.net Fri May 24 22:47:10 2013 From: sfrost at snowman.net (Stephen Frost) Date: Fri, 24 May 2013 08:47:10 -0400 Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: References: <1828634178.815549.1369358638343.JavaMail.webspher@njbbicssmp03> Message-ID: <20130524124710.GD6336@tamriel.snowman.net> * Nico Kadel-Garcia (nkadel at gmail.com) wrote: > It's a big reason that I encourage migration to Kerberos based > authentication wherever possible, but that doesn't work well for > Subversion or git authentication. ... it doesn't? Why not? Having a .k5login for the 'git' account is essentially the same as having an authorized_keys file for the same account.. I've not looked into it specifically, but the offhand comment above surprised me, so I'm curious what the specific issue there is. (I'm also a fan of encouraging Kerberos utilization whenever possible) Thanks, Stephen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 198 bytes Desc: Digital signature URL: From mouring at eviladmin.org Fri May 24 23:30:11 2013 From: mouring at eviladmin.org (Ben Lindstrom) Date: Fri, 24 May 2013 08:30:11 -0500 Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: References: <1828634178.815549.1369358638343.JavaMail.webspher@njbbicssmp03> Message-ID: On May 24, 2013, at 7:43 AM, Nico Kadel-Garcia wrote: [..] > It's a big reason that I encourage migration to Kerberos based > authentication wherever possible, but that doesn't work well for > Subversion or git authentication. Or cron.... =) Any solution that requires me to extract a keytab file and place it in a NFS mounted home directory so I can run a cron tab on one machine while still ensuring it is backed up (as random desktops aren't backed up normally) is just as major of failing as unencrypted private keys floating around. =) So honestly, Kerberos has its own little gotchas as well. BTW.. Kerberos works fine as an authentication method subversion. We do it all the time at work for the IT cfengine repositories. - Ben From nkadel at gmail.com Sat May 25 13:02:46 2013 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Fri, 24 May 2013 23:02:46 -0400 Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: <20130524124710.GD6336@tamriel.snowman.net> References: <1828634178.815549.1369358638343.JavaMail.webspher@njbbicssmp03> <20130524124710.GD6336@tamriel.snowman.net> Message-ID: On May 24, 2013, at 8:47, Stephen Frost wrote: > * Nico Kadel-Garcia (nkadel at gmail.com) wrote: >> It's a big reason that I encourage migration to Kerberos based >> authentication wherever possible, but that doesn't work well for >> Subversion or git authentication. > > ... it doesn't? Why not? Having a .k5login for the 'git' account is > essentially the same as having an authorized_keys file for the same > account.. I've not looked into it specifically, but the offhand comment > above surprised me, so I'm curious what the specific issue there is. This is the problem. Many people who've not actually tried it think "oh, that's easy, I'll just stitch together these bits I know". > (I'm also a fan of encouraging Kerberos utilization whenever possible) > > Thanks, > > Stephen From nkadel at gmail.com Sat May 25 13:32:18 2013 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Fri, 24 May 2013 23:32:18 -0400 Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: References: <1828634178.815549.1369358638343.JavaMail.webspher@njbbicssmp03> <20130524124710.GD6336@tamriel.snowman.net> Message-ID: <650640BE-23C0-4E88-B49C-A4E227837E81@gmail.com> On May 24, 2013, at 23:02, Nico Kadel-Garcia wrote: > > > On May 24, 2013, at 8:47, Stephen Frost wrote: > >> * Nico Kadel-Garcia (nkadel at gmail.com) wrote: >>> It's a big reason that I encourage migration to Kerberos based >>> authentication wherever possible, but that doesn't work well for >>> Subversion or git authentication. >> >> ... it doesn't? Why not? Having a .k5login for the 'git' account is >> essentially the same as having an authorized_keys file for the same >> account.. I've not looked into it specifically, but the offhand comment >> above surprised me, so I'm curious what the specific issue there is. > > This is the problem. Many people who've not actually tried it think "oh, that's easy, I'll just stitch together these bits I know". Sorry, got cut off. I did not mean to snark at you, but to explain it's far more awkward in practice. In this case, there seems not to be a good way with Kerberos to do a "forced command" to tie specific user authentication for subversion or git, to tie user specific authentication to a specific .klogin listed account. The result for Subversion is that all changes would be logged as coming from the common "svn" user. For git it gets a bit weirder due to "merge' operations and "pull requests" run on the server. But pull requests on the server will all be owned by the common "git" user with .klogin, and change tracking winds up in la-la land as it would for Subversion. It remains much easier to manage with the "gitosis" or "gitolite"similar SSH key management tools, that use different "forced commands" for each user for git. There is no published equivalent for Subversion, sadly. >> (I'm also a fan of encouraging Kerberos utilization whenever possible) Good! I've pursued this before and not gotten far due to the missing "forced command" feature. From djm at mindrot.org Sat May 25 14:36:10 2013 From: djm at mindrot.org (Damien Miller) Date: Sat, 25 May 2013 14:36:10 +1000 (EST) Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: References: <1828634178.815549.1369358638343.JavaMail.webspher@njbbicssmp03> Message-ID: On Fri, 24 May 2013, Nico Kadel-Garcia wrote: > This is not a new flaw. It dates right back to the original SSH-1 and > SSH-2, which were forked to create OpenSSH. It's also why the highly > vaunted security of OpenBSD is fairly pointless, when such gaping > configuration holes are the *default* configuration. ssh-keygen > creates passphrase frees by default if you simply hit "Enter" a few > times, and there is no way I've ever seen for ssh_config to reject > them by default when loading local keys or loading them into an > ssh-agent. If you think it through, what you are asking for is basically impossible outside of a hugely restricted enviornment (trivial evasion: upload a custom ssh client that ignores your proposed restriction), and if you happen to have a hugely restricted environment then you don't need it to begin with. -d From nkadel at gmail.com Sat May 25 15:33:41 2013 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sat, 25 May 2013 01:33:41 -0400 Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: References: <1828634178.815549.1369358638343.JavaMail.webspher@njbbicssmp03> Message-ID: On Sat, May 25, 2013 at 12:36 AM, Damien Miller wrote: > On Fri, 24 May 2013, Nico Kadel-Garcia wrote: > >> This is not a new flaw. It dates right back to the original SSH-1 and >> SSH-2, which were forked to create OpenSSH. It's also why the highly >> vaunted security of OpenBSD is fairly pointless, when such gaping >> configuration holes are the *default* configuration. ssh-keygen >> creates passphrase frees by default if you simply hit "Enter" a few >> times, and there is no way I've ever seen for ssh_config to reject >> them by default when loading local keys or loading them into an >> ssh-agent. > > If you think it through, what you are asking for is basically impossible > outside of a hugely restricted enviornment (trivial evasion: upload a > custom ssh client that ignores your proposed restriction), and if you > happen to have a hugely restricted environment then you don't need it > to begin with. Damien, I'm sorry, but this is *precisely* the "if you don't trust your environment, you shouldn't be using it" attitude that leads to grossly dangerous default security practices. It's the approach that leads to people having passphrase keys, by default. Even when someone has a secure local physical environment, I find they often model exactly this behavior for people in much less secure environments who have not been better educated. It's also still a dangerous approach for "secure" environments because the passphrase keys are on the local disk, on shared home directories, on backups, or on rooted systems. And I've encountered far, far, far too many admins who use passphrase free keys for remote access to *other* systems, including allegedly "secure" exposed external servers, without bothering with any of the filtering necessary to restrict such risks. I even keep catching Linux and yes, OpenBSD "architects" doing this kind of "keep passphrase free root keys to remote servers lying around" in NFS accessible homedirs, portable computes, backup tapes, and even sent via email. I've caught roughly..... 20 system admins doing this in the last couple of years, including entire *departments* who "trust the people the work with" and can't be bothered to protect their keys in NFS based envornments, and are *never educated* by their system architects. The attitude of "if I can break your window, you shouldn't be even bothered to lock your car" is an unfortunately common one in the security world. Security can be strongly improved by using layers: improving the defaults to use a m ore secure behavior is a simple step, much as an occasional audit of SSH keys in $HOME/.ssh/ in NFS or other shared environments is invaluable. From jamie.beverly at yahoo.com Sat May 25 16:02:00 2013 From: jamie.beverly at yahoo.com (Jamie Beverly) Date: Fri, 24 May 2013 23:02:00 -0700 Subject: Utility to scan for unpassworded SSH privkeys? Message-ID: I could be mistaken, but I think Damien was referring to the difficulty of attempting to require encryption on, and passphrases for keys. Regardless of what defaults keygen has, a user could easily decrypt the key, and store it insecurely. Not that this is okay, but that you can only enforce that a key is stored securely at the client, which you can never really trust. So you are always at the mercy of users doing the right thing. It's roughly the same issue as people putting passwords on post-it notes. Sent from my Verizon Wireless 4G LTE Smartphone -------- Original message -------- From: Nico Kadel-Garcia Date: 05/24/2013 10:33 PM (GMT-08:00) To: Damien Miller Cc: Jamie Beverly ,Dan Kaminsky ,"Dan Mahoney, System Admin" ,openssh-unix-dev at mindrot.org Subject: Re: Utility to scan for unpassworded SSH privkeys? On Sat, May 25, 2013 at 12:36 AM, Damien Miller wrote: > On Fri, 24 May 2013, Nico Kadel-Garcia wrote: > >> This is not a new flaw. It dates right back to the original SSH-1 and >> SSH-2, which were forked to create OpenSSH. It's also why the highly >> vaunted security of OpenBSD is fairly pointless, when such gaping >> configuration holes are the *default* configuration. ssh-keygen >> creates passphrase frees by default if you simply hit "Enter" a few >> times, and there is no way I've ever seen for ssh_config to reject >> them by default when loading local keys or loading them into an >> ssh-agent. > > If you think it through, what you are asking for is basically impossible > outside of a hugely restricted enviornment (trivial evasion: upload a > custom ssh client that ignores your proposed restriction), and if you > happen to have a hugely restricted environment then you don't need it > to begin with. Damien, I'm sorry, but this is *precisely* the "if you don't trust your environment, you shouldn't be using it" attitude that leads to grossly dangerous default security practices. It's the approach that leads to people having passphrase keys, by default. Even when someone has a secure local physical environment, I find they often model exactly this behavior for people in much less secure environments who have not been better educated. It's also still a dangerous approach for "secure" environments because the passphrase keys are on the local disk, on shared home directories, on backups, or on rooted systems. And I've encountered far, far, far too many admins who use passphrase free keys for remote access to *other* systems, including allegedly "secure" exposed external servers, without bothering with any of the filtering necessary to restrict such risks. I even keep catching Linux and yes, OpenBSD "architects" doing this kind of "keep passphrase free root keys to remote servers lying around"? in NFS accessible homedirs, portable computes, backup tapes, and even sent via email. I've caught roughly..... 20 system admins doing this in the last couple of years, including entire *departments* who "trust the people the work with" and can't be bothered to protect their keys in NFS based envornments, and are *never educated* by their system architects. The attitude of "if I can break your window, you shouldn't be even bothered to lock your car" is an unfortunately common one in the security world. Security can be strongly improved by using layers: improving the defaults to use a m ore secure behavior is a simple step, much as an occasional audit of SSH keys in $HOME/.ssh/ in NFS or other shared environments is invaluable. From martin at oneiros.de Sat May 25 19:35:08 2013 From: martin at oneiros.de (=?ISO-8859-1?Q?Martin_Schr=F6der?=) Date: Sat, 25 May 2013 11:35:08 +0200 Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: References: <1828634178.815549.1369358638343.JavaMail.webspher@njbbicssmp03> Message-ID: 2013/5/24 Nico Kadel-Garcia : > configuration holes are the *default* configuration. ssh-keygen > creates passphrase frees by default if you simply hit "Enter" a few > times, and there is no way I've ever seen for ssh_config to reject > them by default when loading local keys or loading them into an > ssh-agent. So where are your patches? Best Martin From djm at mindrot.org Sat May 25 21:33:06 2013 From: djm at mindrot.org (Damien Miller) Date: Sat, 25 May 2013 21:33:06 +1000 (EST) Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: References: <1828634178.815549.1369358638343.JavaMail.webspher@njbbicssmp03> Message-ID: On Sat, 25 May 2013, Nico Kadel-Garcia wrote: > The attitude of "if I can break your window, you shouldn't be even > bothered to lock your car" is an unfortunately common one in the > security world. Security can be strongly improved by using layers: Sure, but the layers have to actually offer some security and not just the theatre of "we have to do _something_!" Offering a control in ssh_config that is trivially bypassed is not giving out users security, it's selling them a lie. Scanning for passwordless keys on a filesystem is fortunately very simple, and does have a real benefit. -d From nkadel at gmail.com Sun May 26 00:42:01 2013 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sat, 25 May 2013 10:42:01 -0400 Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: References: <1828634178.815549.1369358638343.JavaMail.webspher@njbbicssmp03> Message-ID: On Sat, May 25, 2013 at 5:35 AM, Martin Schr?der wrote: > 2013/5/24 Nico Kadel-Garcia : >> configuration holes are the *default* configuration. ssh-keygen >> creates passphrase frees by default if you simply hit "Enter" a few >> times, and there is no way I've ever seen for ssh_config to reject >> them by default when loading local keys or loading them into an >> ssh-agent. > > So where are your patches? Excellent point. Let me see if I can unpry some tome this week to submit a patch. But I'm concerned it will run into the "but that would change people's workflow!!!!" world of rejected patches, even if the patch is clean. The "ssh-keygen should not accept blank passwords" looks a lot easier, I'll take a shot at that as low hanging fruit. But I've had useful security updates rejected before on the grounds that "if you don't trust the machine you're on, you shouldn't be using it" and "chroot is just security theater, people can get around it". From nkadel at gmail.com Sun May 26 01:06:47 2013 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sat, 25 May 2013 11:06:47 -0400 Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: References: <1828634178.815549.1369358638343.JavaMail.webspher@njbbicssmp03> Message-ID: On Sat, May 25, 2013 at 7:33 AM, Damien Miller wrote: > On Sat, 25 May 2013, Nico Kadel-Garcia wrote: > >> The attitude of "if I can break your window, you shouldn't be even >> bothered to lock your car" is an unfortunately common one in the >> security world. Security can be strongly improved by using layers: > > Sure, but the layers have to actually offer some security and not > just the theatre of "we have to do _something_!" Offering a control > in ssh_config that is trivially bypassed is not giving out users > security, it's selling them a lie. > > Scanning for passwordless keys on a filesystem is fortunately very > simple, and does have a real benefit. Except that it can't scan filesystems on people's disconnected laptops, or their local machines that they propage their keys from but are in the backup system, nor does it scale well for large environments, nor environments that use NFSv4 with Kerberized access, nor environments that auto-mount home directories, nor does it eliminate the old keys from the backup system, etc., etc. And note that a file system scan is next to useless for auto-mounted home directories in most NFS automount configurations, since the wildcard based mounting of home directories provides no direct hint of what the mountpoints might be. You get the idea. It's possible for users who are being cunning to work around many types of security audit or enforced security practice. That doesn't make the elementary security policy enforcement attempts useless, it just means that they help with the low hanging fruit of poor default security practices. From vinschen at redhat.com Sun May 26 04:14:30 2013 From: vinschen at redhat.com (Corinna Vinschen) Date: Sat, 25 May 2013 20:14:30 +0200 Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: References: <1828634178.815549.1369358638343.JavaMail.webspher@njbbicssmp03> Message-ID: <20130525181430.GE29494@calimero.vinschen.de> On May 25 10:42, Nico Kadel-Garcia wrote: > On Sat, May 25, 2013 at 5:35 AM, Martin Schr?der wrote: > > 2013/5/24 Nico Kadel-Garcia : > >> configuration holes are the *default* configuration. ssh-keygen > >> creates passphrase frees by default if you simply hit "Enter" a few > >> times, and there is no way I've ever seen for ssh_config to reject > >> them by default when loading local keys or loading them into an > >> ssh-agent. > > > > So where are your patches? > > Excellent point. Let me see if I can unpry some tome this week to > submit a patch. But I'm concerned it will run into the "but that would > change people's workflow!!!!" world of rejected patches, even if the > patch is clean. > > The "ssh-keygen should not accept blank passwords" looks a lot easier, So, how do you generate passphraseless keys in future? There's a legitimate scenario to use them, running cron-based automatic remote tasks from a secure control server. Do you really think it's the right thing to do to break this? If so, people will simply be annoyed and run a patched version of ssh-keygen which disables this check. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat From apb at cequrux.com Sun May 26 05:54:26 2013 From: apb at cequrux.com (Alan Barrett) Date: Sat, 25 May 2013 21:54:26 +0200 Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: References: <1828634178.815549.1369358638343.JavaMail.webspher@njbbicssmp03> Message-ID: <20130525195426.GK18834@apb-laptoy.apb.alt.za> On Sat, 25 May 2013, Damien Miller wrote: > Offering a control in ssh_config that is trivially bypassed is > not giving out users security, it's selling them a lie. No, it's neither security nor a lie, it's education, and it is beneficial. An error message of the form "I refuse to use that non-password-protected key" can certainly be bypassed by editing a config file or installing a different ssh client, but users won't always bypass the message, they will sometimes add a password to their key, which is the desired result. Editing the configuration or installing a different ssh client might be a violation of company policy, and the users will at least think about that before doing it. Even if it's a personal system with no company policy involved, the user will think at least a little about whether to edit the config option or to add a password. --apb (Alan Barrett) From carson at taltos.org Sun May 26 06:38:59 2013 From: carson at taltos.org (Carson Gaspar) Date: Sat, 25 May 2013 13:38:59 -0700 Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: References: <1828634178.815549.1369358638343.JavaMail.webspher@njbbicssmp03> Message-ID: <51A12163.4080007@taltos.org> On 5/25/13 4:33 AM, Damien Miller wrote: > Sure, but the layers have to actually offer some security and not > just the theatre of "we have to do _something_!" Offering a control > in ssh_config that is trivially bypassed is not giving out users > security, it's selling them a lie. I'm generally in your camp, Damien, but in this case there _is_ a real benefit: culpability, in a legal sense. "Forgetting" to encrypt a private key may be a policy violation. Circumventing the controls that prevent you from using an unencrypted private key shows malicious intent, which is a very different thing. (I Am Not A Lawyer, insert disclaimer here...) Note that I am not arguing in favour of the code change (I still lean slightly against it), just pointing out that there is a valid argument to be made for it. -- Carson From jhawk at MIT.EDU Sun May 26 06:56:43 2013 From: jhawk at MIT.EDU (John Hawkinson) Date: Sat, 25 May 2013 16:56:43 -0400 Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: <20130525195426.GK18834@apb-laptoy.apb.alt.za> References: <1828634178.815549.1369358638343.JavaMail.webspher@njbbicssmp03> <20130525195426.GK18834@apb-laptoy.apb.alt.za> Message-ID: <20130525205643.GV24674@ringworld.MIT.EDU> I kind of think the desirable thing would have been for the client to determine whether there is a server command= restriction in place, and if there is not, to warn or require the user to take special action. But this would presumably require a protocol change. Not to mention a transition path that might be difficult. (This assumes we could agree that the only "proper" use of un-passphrased keys is when they are restricted by a server-side command= restriction.) I do agree we need a way (command-line flag, please, well-documented) to generate passphraseless public keys. I use them, e.g. for server backups, but always with a command= restriction. I would not be averse to a paragraph-long message explaining the issues (e.g. summarizing this thread) so users so-inclined could actually understand the decision made. But I realie that might be unpopular. --jhawk at mit.edu John Hawkinson From nkadel at gmail.com Sun May 26 08:29:13 2013 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Sat, 25 May 2013 18:29:13 -0400 Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: <271708DF-2CB0-42CD-B89E-5064E7D6E4AF@prime.gushi.org> References: <1828634178.815549.1369358638343.JavaMail.webspher@njbbicssmp03> <271708DF-2CB0-42CD-B89E-5064E7D6E4AF@prime.gushi.org> Message-ID: On Sat, May 25, 2013 at 6:03 PM, Dan Mahoney wrote: > Responses inline. > > On May 25, 2013, at 8:06, Nico Kadel-Garcia wrote: > >> On Sat, May 25, 2013 at 7:33 AM, Damien Miller wrote: >>> On Sat, 25 May 2013, Nico Kadel-Garcia wrote: >>> >>> Scanning for passwordless keys on a filesystem is fortunately very >>> simple, and does have a real benefit. >> >> Except that it can't scan filesystems on people's disconnected >> laptops, or their local machines that they propage their keys from but >> are in the backup system, nor does it scale well for large >> environments, nor environments that use NFSv4 with Kerberized access, >> nor environments that auto-mount home directories, nor does it >> eliminate the old keys from the backup system, etc., etc. And note >> that a file system scan is next to useless for auto-mounted home >> directories in most NFS automount configurations, since the wildcard >> based mounting of home directories provides no direct hint of what the >> mountpoints might be. > > I'm pretty sure I can run over my NFS server with "find" and "exec" and do what I need to, for any number of users. Which is kind of what any potential person to compromise the system will do anyway. This works only if you have good command access to the NFS server itself. In EMC or NetApp or many larger environments, an admin running a security probe only *rarely* has such access. >> You get the idea. It's possible for users who are being cunning > > ...interesting term considering the problem I initially posited (users being ignorant). Being both cunning and ignorant is a rare occurrence. Or at least I used to think. I've been proven wrong before. It's an incredible education problem. > On the other hand, If you manage to have my machine be an attack vector, because your unencrypted key on your compromised/stolen laptop agent-forwarded through my system, I'll probably forgive you. And be impressed. Through yours? The risk would be mostly if I'm also an admin on your system. And shared admin environments are quite common in large conputing environments, and in univiersities and research environments. > For what it's worth, I'm not against a patch-set that enables ssh-keygen to NOT generate a passwordless key, period. (If you generate one elsewhere and upload it, I can't really help that, but I can scan for it). I'm not even against a patch-set that runs it through some sorts of quality-meters (cracklib? Is that still a thing?) > > On a more evil side, it would be cool if sshd could look for key-based logins that are happening too quickly (indicating no password is being typed), but which do not also attempt to forward an agent -- yes, it's still possible ssh-agent is being used, and just not forwarding, but that's half the point of the agent. There's a possible research paper there for someone, most likely. That.... oooohhh, i *like* it. Not necessarily fail, but simply sending a message to syslog would be helpful for security auditing. It would need to be optional: there are setups like git and Subversion where ssh-agent shouldn't really be forwarded. And forwarding is off by default in ssh_config, so it's of limited use in default environments. > At any rate, I've found what I'm interested in. When I get something nice written up, I may offer it up to stick in /contrib, because I feel such a thing is important. At the very least, I'll push it to a blog. > > All the best. > > -Dan If you can bundle it nicely, how about posting it to github.com ? From dtucker at zip.com.au Mon May 27 16:39:16 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 27 May 2013 16:39:16 +1000 Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: <20130525181430.GE29494@calimero.vinschen.de> References: <1828634178.815549.1369358638343.JavaMail.webspher@njbbicssmp03> <20130525181430.GE29494@calimero.vinschen.de> Message-ID: <20130527063916.GA17548@gate.dtucker.net> On Sat, May 25, 2013 at 08:14:30PM +0200, Corinna Vinschen wrote: > On May 25 10:42, Nico Kadel-Garcia wrote: > > The "ssh-keygen should not accept blank passwords" looks a lot easier, > > So, how do you generate passphraseless keys in future? There's a > legitimate scenario to use them, running cron-based automatic remote > tasks from a secure control server. Also: generating host keys. -- 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 no_spam_98 at yahoo.com Tue May 28 10:39:38 2013 From: no_spam_98 at yahoo.com (no_spam_98 at yahoo.com) Date: Mon, 27 May 2013 17:39:38 -0700 (PDT) Subject: =?utf-8?B?UmU6IFN1cHBvcnQgZm9yICJzc2gtcnNhLXNoYTI1NiIgYW5kICJzc2gtZHNz?= =?utf-8?B?LXNoYTI1NiIgP+KAjw==?= In-Reply-To: References: Message-ID: <1369701578.68914.YahooMailNeo@web140606.mail.bf1.yahoo.com> Done. ?Bug 2109. Thanks. >________________________________ > From: Damien Miller >To: Jeffrey Hawkins >Cc: "openssh-unix-dev at mindrot.org" >Sent: Friday, May 24, 2013 7:17 AM >Subject: Re: Support for "ssh-rsa-sha256" and "ssh-dss-sha256" ?? > > >On Tue, 14 May 2013, Jeffrey Hawkins wrote: > >> Functionality request for supporting Digital Signatures for RSA and DSS >> Public Key Algorithms in alignment with NIST SP800-131A. >> >> I >> assume this has been asked before, but I could not find in the >> archives.? Support of "ssh-rsa-sha256" and "ssh-dss-sha256" public key >> algorithms for OpenSSH?? I know Suite B Algorithms and x509 SSH >> Extension Algorithms are supported, but not a path some folks (us) want >> to take.? Tectia supports similar algorithms? via their own extensions >> in commercial SSH. > >Adding the signature code is easy (see below for a hacky diff - not for >use), it's going through and duplicating all the ssh-rsa code to support >ssh-rsa-sha256 and dealing with the corner cases that it tricky. E.g. >when we find a PEM RSA key on disk, do we load it as a ssh-rsa key, a >ssh-rsa-sha256 key or both? There are more difficulties to do with >certificates too when they are signed with RSA keys - should the >signature be ssh-rsa or ssh-rsa-sha256? > >There are probably some other traps that haven't occurred to me yet :( > >Please file a bug at https://bugzilla.mindrot.org/ so we can thrash this >out. > >-d > >Index: compat.c >=================================================================== >RCS file: /cvs/src/usr.bin/ssh/compat.c,v >retrieving revision 1.81 >diff -u -p -r1.81 compat.c >--- compat.c??? 17 May 2013 00:13:13 -0000??? 1.81 >+++ compat.c??? 24 May 2013 12:01:33 -0000 >@@ -93,6 +93,7 @@ compat_datafellows(const char *version) >??? ??? { "Sun_SSH_1.0*",??? SSH_BUG_NOREKEY|SSH_BUG_EXTEOF}, >??? ??? { "OpenSSH_4*",??? ??? 0 }, >??? ??? { "OpenSSH_5*",??? ??? SSH_NEW_OPENSSH|SSH_BUG_DYNAMIC_RPORT}, >+??? ??? { "OpenSSH_6.2xxx*",??? SSH_NEW_OPENSSH|SSH_NEW_RSA_SHA2}, >??? ??? { "OpenSSH*",??? ??? SSH_NEW_OPENSSH }, >??? ??? { "*MindTerm*",??? ??? 0 }, >??? ??? { "2.1.0*",??? ??? SSH_BUG_SIGBLOB|SSH_BUG_HMAC| >Index: compat.h >=================================================================== >RCS file: /cvs/src/usr.bin/ssh/compat.h,v >retrieving revision 1.43 >diff -u -p -r1.43 compat.h >--- compat.h??? 23 Sep 2011 07:45:05 -0000??? 1.43 >+++ compat.h??? 24 May 2013 12:01:33 -0000 >@@ -59,6 +59,7 @@ >#define SSH_BUG_RFWD_ADDR??? 0x02000000 >#define SSH_NEW_OPENSSH??? ??? 0x04000000 >#define SSH_BUG_DYNAMIC_RPORT??? 0x08000000 >+#define SSH_NEW_RSA_SHA2??? 0x10000000 > >void? ? enable_compat13(void); >void? ? enable_compat20(void); >Index: ssh-rsa.c >=================================================================== >RCS file: /cvs/src/usr.bin/ssh/ssh-rsa.c,v >retrieving revision 1.46 >diff -u -p -r1.46 ssh-rsa.c >--- ssh-rsa.c??? 17 May 2013 00:13:14 -0000??? 1.46 >+++ ssh-rsa.c??? 24 May 2013 12:01:33 -0000 >@@ -32,7 +32,7 @@ > >static int openssh_RSA_verify(int, u_char *, u_int, u_char *, u_int, RSA *); > >-/* RSASSA-PKCS1-v1_5 (PKCS #1 v2.0 signature) with SHA1 */ >+/* RSASSA-PKCS1-v1_5 (PKCS #1 v2.0 signature) with SHA1 or SHA256 */ >int >ssh_rsa_sign(const Key *key, u_char **sigp, u_int *lenp, >? ? const u_char *data, u_int datalen) >@@ -44,14 +44,28 @@ ssh_rsa_sign(const Key *key, u_char **si >??? int ok, nid; >??? Buffer b; > >-??? if (key == NULL || key->rsa == NULL || (key->type != KEY_RSA && >-??? ? ? key->type != KEY_RSA_CERT && key->type != KEY_RSA_CERT_V00)) { >-??? ??? error("ssh_rsa_sign: no RSA key"); >+??? if (key == NULL || key->rsa == NULL) { >+??? ??? error("%s: no RSA key", __func__); >+??? ??? return -1; >+??? } >+??? nid = NID_sha1; >+??? if ((datafellows & SSH_BUG_RSASIGMD5) != 0) >+??? ??? nid = NID_md5; >+??? else if ((datafellows & SSH_NEW_RSA_SHA2) != 0) { >+??? ??? nid = NID_sha256; >+??? } >+??? switch (key->type) { >+??? case KEY_RSA: >+??? case KEY_RSA_CERT: >+??? case KEY_RSA_CERT_V00: >+??? ??? break; >+??? default: >+??? ??? error("%s: wrong type key %s (%d)", >+??? ??? ? ? __func__, key_type(key), key->type); >??? ??? return -1; >??? } >-??? nid = (datafellows & SSH_BUG_RSASIGMD5) ? NID_md5 : NID_sha1; >??? if ((evp_md = EVP_get_digestbynid(nid)) == NULL) { >-??? ??? error("ssh_rsa_sign: EVP_get_digestbynid %d failed", nid); >+??? ??? error("%s: EVP_get_digestbynid %d failed", __func__, nid); >??? ??? return -1; >??? } >??? EVP_DigestInit(&md, evp_md); >@@ -67,7 +81,7 @@ ssh_rsa_sign(const Key *key, u_char **si >??? if (ok != 1) { >??? ??? int ecode = ERR_get_error(); > >-??? ??? error("ssh_rsa_sign: RSA_sign failed: %s", >+??? ??? error("%s: RSA_sign failed: %s", __func__, >??? ??? ? ? ERR_error_string(ecode, NULL)); >??? ??? free(sig); >??? ??? return -1; >@@ -78,7 +92,7 @@ ssh_rsa_sign(const Key *key, u_char **si >??? ??? memmove(sig + diff, sig, len); >??? ??? memset(sig, 0, diff); >??? } else if (len > slen) { >-??? ??? error("ssh_rsa_sign: slen %u slen2 %u", slen, len); >+??? ??? error("%s: slen %u slen2 %u", __func__, slen, len); >??? ??? free(sig); >??? ??? return -1; >??? } >@@ -112,21 +126,37 @@ ssh_rsa_verify(const Key *key, const u_c >??? u_int len, dlen, modlen; >??? int rlen, ret, nid; > >-??? if (key == NULL || key->rsa == NULL || (key->type != KEY_RSA && >-??? ? ? key->type != KEY_RSA_CERT && key->type != KEY_RSA_CERT_V00)) { >-??? ??? error("ssh_rsa_verify: no RSA key"); >+??? if (key == NULL || key->rsa == NULL) { >+??? ??? error("%s: no RSA key", __func__); >+??? ??? return -1; >+??? } >+??? nid = NID_sha1; >+??? if ((datafellows & SSH_BUG_RSASIGMD5) != 0) >+??? ??? nid = NID_md5; >+??? else if ((datafellows & SSH_NEW_RSA_SHA2) != 0) { >+??? ??? nid = NID_sha256; >+??? } >+??? switch (key->type) { >+??? case KEY_RSA: >+??? case KEY_RSA_CERT: >+??? case KEY_RSA_CERT_V00: >+??? ??? break; >+??? default: >+??? ??? error("%s: wrong type key %s (%d)", >+??? ??? ? ? __func__, key_type(key), key->type); >??? ??? return -1; >??? } >??? if (BN_num_bits(key->rsa->n) < SSH_RSA_MINIMUM_MODULUS_SIZE) { >-??? ??? error("ssh_rsa_verify: RSA modulus too small: %d < minimum %d bits", >-??? ??? ? ? BN_num_bits(key->rsa->n), SSH_RSA_MINIMUM_MODULUS_SIZE); >+??? ??? error("%s: RSA modulus too small: %d < minimum %d bits", >+??? ??? ? ? __func__, BN_num_bits(key->rsa->n), >+??? ??? ? ? SSH_RSA_MINIMUM_MODULUS_SIZE); >??? ??? return -1; >??? } >??? buffer_init(&b); >??? buffer_append(&b, signature, signaturelen); >??? ktype = buffer_get_cstring(&b, NULL); >??? if (strcmp("ssh-rsa", ktype) != 0) { >-??? ??? error("ssh_rsa_verify: cannot handle type %s", ktype); >+??? ??? error("%s: cannot handle type %s", __func__, ktype); >??? ??? buffer_free(&b); >??? ??? free(ktype); >??? ??? return -1; >@@ -136,28 +166,27 @@ ssh_rsa_verify(const Key *key, const u_c >??? rlen = buffer_len(&b); >??? buffer_free(&b); >??? if (rlen != 0) { >-??? ??? error("ssh_rsa_verify: remaining bytes in signature %d", rlen); >+??? ??? error("%s: remaining bytes in signature %d", __func__, rlen); >??? ??? free(sigblob); >??? ??? return -1; >??? } >??? /* RSA_verify expects a signature of RSA_size */ >??? modlen = RSA_size(key->rsa); >??? if (len > modlen) { >-??? ??? error("ssh_rsa_verify: len %u > modlen %u", len, modlen); >+??? ??? error("%s: len %u > modlen %u", __func__, len, modlen); >??? ??? free(sigblob); >??? ??? return -1; >??? } else if (len < modlen) { >??? ??? u_int diff = modlen - len; >-??? ??? debug("ssh_rsa_verify: add padding: modlen %u > len %u", >-??? ??? ? ? modlen, len); >+??? ??? debug("%s: add padding: modlen %u > len %u", >+??? ??? ? ? __func__, modlen, len); >??? ??? sigblob = xrealloc(sigblob, 1, modlen); >??? ??? memmove(sigblob + diff, sigblob, len); >??? ??? memset(sigblob, 0, diff); >??? ??? len = modlen; >??? } >-??? nid = (datafellows & SSH_BUG_RSASIGMD5) ? NID_md5 : NID_sha1; >??? if ((evp_md = EVP_get_digestbynid(nid)) == NULL) { >-??? ??? error("ssh_rsa_verify: EVP_get_digestbynid %d failed", nid); >+??? ??? error("%s: EVP_get_digestbynid %d failed", __func__, nid); >??? ??? free(sigblob); >??? ??? return -1; >??? } >@@ -169,7 +198,7 @@ ssh_rsa_verify(const Key *key, const u_c >??? memset(digest, 'd', sizeof(digest)); >??? memset(sigblob, 's', len); >??? free(sigblob); >-??? debug("ssh_rsa_verify: signature %scorrect", (ret==0) ? "in" : ""); >+??? debug("%s: signature %scorrect", __func__, (ret==0) ? "in" : ""); >??? return ret; >} > >@@ -196,12 +225,27 @@ static const u_char id_sha1[] = { >? */ >static const u_char id_md5[] = { >??? 0x30, 0x20, /* type Sequence, length 0x20 (32) */ >-??? 0x30, 0x0c, /* type Sequence, length 0x09 */ >-??? 0x06, 0x08, /* type OID, length 0x05 */ >+??? 0x30, 0x0c, /* type Sequence, length 0x0c (12) */ >+??? 0x06, 0x08, /* type OID, length 0x08 */ >??? 0x2a, 0x86, 0x48, 0x86, 0xF7, 0x0D, 0x02, 0x05, /* id-md5 */ >??? 0x05, 0x00, /* NULL */ >??? 0x04, 0x10? /* Octet string, length 0x10 (16), followed by md5 hash */ >}; >+/* >+ * See http://csrc.nist.gov/groups/ST/crypto_apps_infra/csor/algorithms.html >+ * id-sha256 OBJECT IDENTIFIER ::= { joint-iso-itu-t(2) country(16) us(840) >+ *? ? ? organization(1) gov(101) csor(3) nistAlgorithm(4) hashAlgs(2) >+ *? ? ? id-sha256(1) } >+ */ >+static const u_char id_sha256[] = { >+??? 0x30, 0x31, /* type Sequence, length 0x31 (49) */ >+??? 0x30, 0x0d, /* type Sequence, length 0x0d (13) */ >+??? 0x06, 0x09, /* type OID, length 0x09 */ >+??? 0x60, 0x86, 0x48, 0x01, 0x65, 0x03, 0x04, 0x02, 0x01, /* id-sha256 */ >+??? 0x05, 0x00, /* NULL */ >+??? 0x04, 0x20? /* Octet string, length 0x20 (32), followed by sha256 hash */ >+}; >+ > >static int >openssh_RSA_verify(int type, u_char *hash, u_int hashlen, >@@ -218,6 +262,11 @@ openssh_RSA_verify(int type, u_char *has >??? ??? oid = id_sha1; >??? ??? oidlen = sizeof(id_sha1); >??? ??? hlen = 20; >+??? ??? break; >+??? case NID_sha256: >+??? ??? oid = id_sha256; >+??? ??? oidlen = sizeof(id_sha256); >+??? ??? hlen = 32; >??? ??? break; >??? case NID_md5: >??? ??? oid = id_md5; >Index: version.h >=================================================================== >RCS file: /cvs/src/usr.bin/ssh/version.h,v >retrieving revision 1.66 >diff -u -p -r1.66 version.h >--- version.h??? 10 Feb 2013 21:19:34 -0000??? 1.66 >+++ version.h??? 24 May 2013 12:01:33 -0000 >@@ -1,3 +1,3 @@ >/* $OpenBSD: version.h,v 1.66 2013/02/10 21:19:34 markus Exp $ */ > >-#define SSH_VERSION??? "OpenSSH_6.2" >+#define SSH_VERSION??? "OpenSSH_6.2xxx" >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > > > From phil.pennock at globnix.org Tue May 28 12:10:38 2013 From: phil.pennock at globnix.org (Phil Pennock) Date: Mon, 27 May 2013 22:10:38 -0400 Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: <650640BE-23C0-4E88-B49C-A4E227837E81@gmail.com> References: <1828634178.815549.1369358638343.JavaMail.webspher@njbbicssmp03> <20130524124710.GD6336@tamriel.snowman.net> <650640BE-23C0-4E88-B49C-A4E227837E81@gmail.com> Message-ID: <20130528021038.GA46174@redoubt.spodhuis.org> On 2013-05-24 at 23:32 -0400, Nico Kadel-Garcia wrote: > Sorry, got cut off. I did not mean to snark at you, but to explain > it's far more awkward in practice. In this case, there seems not to > be a good way with Kerberos to do a "forced command" to tie specific > user authentication for subversion or git, to tie user specific > authentication to a specific .klogin listed account. The result for > Subversion is that all changes would be logged as coming from the > common "svn" user. For git it gets a bit weirder due to "merge' > operations and "pull requests" run on the server. But pull requests on > the server will all be owned by the common "git" user with .klogin, > and change tracking winds up in la-la land as it would for > Subversion. I use Kerberised Subversion and have done since 2006. The identifier that appears in "svn log" etc is my kerberos identity, with realm intact. I don't use the SSH transport to do so; https with Apache, the normal Subversion modules and mod_auth_kerb, pointing Krb5Keytab at a keytab with credentials for Apache; be sure to enable KrbMethodNegotiate. The client uses ra_neon which will happily use Kerberos, *provided* that you're on https not http. The ra_neon module doesn't do auth-layer wrap/unwrap, so Kerberos-negotiated protection layers from GSSAPI will break, so the client code hard-disables the WWW-Authenticate negotiate mechanism if only http. In the AuthzSVNAccessFile config, I define things like: [groups] foo = foo, foo at SPODHUIS.ORG and then use "@foo" for access controls where before I might have used just "foo". I prefer git these days, but do miss the Kerberised access. If I were going to invest time in setting it up, I'd add OpenSSH on a non-standard port, configure a ForceCommand in the system-wide sshd_config for that sshd and then enable Kerberos an auth mechanism for that. Add a hostname alias such as "kgit.example.org" and tell folks to add to ~/.ssh/config a block which sets Port for that hostname, so that nobody has to mess around trying to pass port specifications down through git command invocations and instead it comes via ssh(1) using a hostname alias. Heck, kgit doesn't need to exist in DNS if folks use Hostname in their ssh_config, but it eases debugging and support burden if it does exist. For myself, I'd avoid even that Port messing around and do for kgit exactly what I do for svn: dedicated IPv6 address, so that forward/reverse DNS can match exactly and the service is only accessible over IPv6. These days, that's not a problematic constraint. -Phil From djm at mindrot.org Tue May 28 12:17:36 2013 From: djm at mindrot.org (Damien Miller) Date: Tue, 28 May 2013 12:17:36 +1000 (EST) Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: <20130528021038.GA46174@redoubt.spodhuis.org> References: <1828634178.815549.1369358638343.JavaMail.webspher@njbbicssmp03> <20130524124710.GD6336@tamriel.snowman.net> <650640BE-23C0-4E88-B49C-A4E227837E81@gmail.com> <20130528021038.GA46174@redoubt.spodhuis.org> Message-ID: On Mon, 27 May 2013, Phil Pennock wrote: > I prefer git these days, but do miss the Kerberised access. If I were > going to invest time in setting it up, I'd add OpenSSH on a non-standard > port, configure a ForceCommand in the system-wide sshd_config for that > sshd and then enable Kerberos an auth mechanism for that. It's no longer necessary to run additional sshd instances to vary configuration by port. You can do something: Port 22 Port 2222 Match LocalPort 2222 ForceCommand something Darren added this in openssh-6.1. -d From nkadel at gmail.com Tue May 28 14:00:00 2013 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 28 May 2013 00:00:00 -0400 Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: <20130528021038.GA46174@redoubt.spodhuis.org> References: <1828634178.815549.1369358638343.JavaMail.webspher@njbbicssmp03> <20130524124710.GD6336@tamriel.snowman.net> <650640BE-23C0-4E88-B49C-A4E227837E81@gmail.com> <20130528021038.GA46174@redoubt.spodhuis.org> Message-ID: On Mon, May 27, 2013 at 10:10 PM, Phil Pennock wrote: > On 2013-05-24 at 23:32 -0400, Nico Kadel-Garcia wrote: >> Sorry, got cut off. I did not mean to snark at you, but to explain >> it's far more awkward in practice. In this case, there seems not to >> be a good way with Kerberos to do a "forced command" to tie specific >> user authentication for subversion or git, to tie user specific >> authentication to a specific .klogin listed account. The result for >> Subversion is that all changes would be logged as coming from the >> common "svn" user. For git it gets a bit weirder due to "merge' >> operations and "pull requests" run on the server. But pull requests on >> the server will all be owned by the common "git" user with .klogin, >> and change tracking winds up in la-la land as it would for >> Subversion. > > I use Kerberised Subversion and have done since 2006. The identifier > that appears in "svn log" etc is my kerberos identity, with realm > intact. > > I don't use the SSH transport to do so; https with Apache, the normal > Subversion modules and mod_auth_kerb, pointing Krb5Keytab at a keytab > with credentials for Apache; be sure to enable KrbMethodNegotiate. Oh. That is a very, very different technology, and quite distinct from the svn+ssh usage. > I prefer git these days, but do miss the Kerberised access. If I were > going to invest time in setting it up, I'd add OpenSSH on a non-standard > port, configure a ForceCommand in the system-wide sshd_config for that > sshd and then enable Kerberos an auth mechanism for that. Add a I'd be really fascinated to see this work. It's not clear to me that this actually forces people to use Kerberos tickets rather than handling a locally stored palintext password in Subversion's UNIX/Linux clients as currently occurs by default. From phil.pennock at globnix.org Tue May 28 16:22:03 2013 From: phil.pennock at globnix.org (Phil Pennock) Date: Tue, 28 May 2013 02:22:03 -0400 Subject: Utility to scan for unpassworded SSH privkeys? In-Reply-To: References: <1828634178.815549.1369358638343.JavaMail.webspher@njbbicssmp03> <20130524124710.GD6336@tamriel.snowman.net> <650640BE-23C0-4E88-B49C-A4E227837E81@gmail.com> <20130528021038.GA46174@redoubt.spodhuis.org> Message-ID: <20130528062202.GA15242@redoubt.spodhuis.org> On 2013-05-28 at 00:00 -0400, Nico Kadel-Garcia wrote: > > I prefer git these days, but do miss the Kerberised access. If I were > > going to invest time in setting it up, I'd add OpenSSH on a non-standard > > port, configure a ForceCommand in the system-wide sshd_config for that > > sshd and then enable Kerberos an auth mechanism for that. Add a > > I'd be really fascinated to see this work. It's not clear to me that > this actually forces people to use Kerberos tickets rather than > handling a locally stored palintext password in Subversion's > UNIX/Linux clients as currently occurs by default. Disable the authentication methods that take a password on the wire and instead require GSSAPI-based authentication, then use the normal Kerberos-based GSSAPI providers (MIT, Heimdal) which rely upon tickets and do not support passwords in the GSSAPI exchange. GSSAPIAuthentication yes PasswordAuthentication no ChallengeResponseAuthentication no KbdInteractiveAuthentication no AuthenticationMethods gssapi-with-mic # assuming very recent OpenSSH Checking sshd_config.0 from 6.2p1, ChallengeResponseAuthentication is not available in a Match conditional block, but my understanding is that with the new AuthenticationMethods option that shouldn't matter, since you can use it instead. (Also, KbdInteractiveAuthentication appears to only be documented by its presence in the Match documentation, but does still exist in source?) -Phil From jonathan.P.schaaf at ge.com Thu May 30 05:14:45 2013 From: jonathan.P.schaaf at ge.com (Schaaf, Jonathan P (GE Healthcare)) Date: Wed, 29 May 2013 19:14:45 +0000 Subject: Patch to discourage unencrypted key generation Message-ID: >>> configuration holes are the *default* configuration. ssh-keygen >>> creates passphrase frees by default if you simply hit "Enter" a few >>> times, and there is no way I've ever seen for ssh_config to reject >>> them by default when loading local keys or loading them into an >>> ssh-agent. >> >> So where are your patches? > > Excellent point. Let me see if I can unpry some tome this week to submit a patch. > But I'm concerned it will run into the "but that would change people's workflow!!!!" > world of rejected patches, even if the patch is clean. I hope I'm not submitting something while Martin is halfway through working on this, but as previously noted, the real complexities are in the change to people's workflow. Let the beatings commence. diff -ruN ssh-orig/ssh-keygen.c ssh/ssh-keygen.c --- ssh-orig/ssh-keygen.c 2013-02-10 17:32:10.000000000 -0600 +++ ssh/ssh-keygen.c 2013-05-29 13:57:50.555791814 -0500 @@ -2585,6 +2585,23 @@ printf("Passphrases do not match. Try again.\n"); goto passphrase_again; } + if (strcmp(passphrase1, "" ) == 0) { + char iknow[7]; + printf("Empty passphrases are a potential security risk. \n" ); + printf("Type \"I know\" to confirm that you want this: " ); + fflush(stdout); + + if (fgets(iknow, sizeof(iknow), stdin) == NULL) + exit(1); + if (strcmp("I know", iknow ) != 0) { + memset(passphrase1, 0, strlen(passphrase1)); + memset(passphrase2, 0, strlen(passphrase2)); + xfree(passphrase1); + xfree(passphrase2); + goto passphrase_again; + } + } + /* Clear the other copy of the passphrase. */ memset(passphrase2, 0, strlen(passphrase2)); xfree(passphrase2); From jhawk at MIT.EDU Thu May 30 11:24:56 2013 From: jhawk at MIT.EDU (John Hawkinson) Date: Wed, 29 May 2013 21:24:56 -0400 Subject: Patch to discourage unencrypted key generation In-Reply-To: References: Message-ID: <20130530012456.GW24674@ringworld.MIT.EDU> Schaaf, Jonathan P (GE Healthcare) wrote on Wed, 29 May 2013 at 19:14:45 +0000 in : > I hope I'm not submitting something while Martin is halfway through > working on this, but as previously noted, the real complexities are > in the change to people's workflow. Let the beatings commence. ... > + printf("Empty passphrases are a potential security risk. \n" ); > + printf("Type \"I know\" to confirm that you want this: " ); I don't think this is the way to go. Among other things, it precludes easy automation of this, which is bad (esp., as was noted, for host keys). Furthremore, it gives just enough information to not be helpful. WHY are they a security risk? WHERE can we find out more info? WHAT are the alternatives? --jhawk at mit.edu John Hawkinson From nkadel at gmail.com Thu May 30 11:24:02 2013 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Wed, 29 May 2013 21:24:02 -0400 Subject: Patch to discourage unencrypted key generation In-Reply-To: References: Message-ID: On Wed, May 29, 2013 at 3:14 PM, Schaaf, Jonathan P (GE Healthcare) wrote: >>>> configuration holes are the *default* configuration. ssh-keygen >>>> creates passphrase frees by default if you simply hit "Enter" a few >>>> times, and there is no way I've ever seen for ssh_config to reject >>>> them by default when loading local keys or loading them into an >>>> ssh-agent. >>> >>> So where are your patches? >> >> Excellent point. Let me see if I can unpry some tome this week to submit a patch. >> But I'm concerned it will run into the "but that would change people's workflow!!!!" >> world of rejected patches, even if the patch is clean. > > > I hope I'm not submitting something while Martin is halfway through working on this, but as previously noted, the real complexities are in the change to people's workflow. Let the beatings commence. That was me, not Martin. Adding a "you have to type the secret undocumented code phrase, without any manual page entry or documentation whatsoever" is, indeed cause for beatings with a rubber hammer. I was personally thinking "add a required '-z' command line argument for a zero-length passphrase", since the ssh-keygen is already using "-n" and "-e" for other options. From imorgan at nas.nasa.gov Fri May 31 03:13:09 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 30 May 2013 10:13:09 -0700 Subject: Patch to discourage unencrypted key generation In-Reply-To: <20130530012456.GW24674@ringworld.MIT.EDU> References: <20130530012456.GW24674@ringworld.MIT.EDU> Message-ID: <20130530171308.GB540@linux124.nas.nasa.gov> On Wed, May 29, 2013 at 20:24:56 -0500, John Hawkinson wrote: > Schaaf, Jonathan P (GE Healthcare) wrote on Wed, 29 May 2013 > at 19:14:45 +0000 in : > > > I hope I'm not submitting something while Martin is halfway through > > working on this, but as previously noted, the real complexities are > > in the change to people's workflow. Let the beatings commence. > ... > > + printf("Empty passphrases are a potential security risk. \n" ); > > + printf("Type \"I know\" to confirm that you want this: " ); > > I don't think this is the way to go. > Among other things, it precludes easy automation of this, which is bad > (esp., as was noted, for host keys). > > Furthremore, it gives just enough information to not be helpful. > WHY are they a security risk? WHERE can we find out more info? WHAT > are the alternatives? > What I would suggest is this: - Remove the "(empty for no passphrase)" part of the password prompt - Only allow empty passwords with -A or -N '' - When run as non-root and using an empty password, print a warning message and give a simple yes/no prompt to determine whether or not to continue. - Document the use of -N '' in ssh-keygen(1) - Possibly add a SECURITY section to ssh-keygen(1) to provide further details on the security implications of using empty passwords and how to mitigate them This avoids impacting the typical process of creating host keys and minimally ikpacts the process for non-root users. -- Iain Morgan From jhawk at MIT.EDU Fri May 31 03:15:46 2013 From: jhawk at MIT.EDU (John Hawkinson) Date: Thu, 30 May 2013 13:15:46 -0400 Subject: Patch to discourage unencrypted key generation In-Reply-To: <20130530171308.GB540@linux124.nas.nasa.gov> References: <20130530012456.GW24674@ringworld.MIT.EDU> <20130530171308.GB540@linux124.nas.nasa.gov> Message-ID: <20130530171546.GC24674@ringworld.MIT.EDU> Iain Morgan wrote on Thu, 30 May 2013 at 10:13:09 -0700 in <20130530171308.GB540 at linux124.nas.nasa.gov>: > - When run as non-root and using an empty password, print a > warning message and give a simple yes/no prompt to determine > whether or not to continue. Why is the user (root or not) of ssh-keygen relevant here? --jhawk at mit.edu John Hawkinson From imorgan at nas.nasa.gov Fri May 31 03:32:22 2013 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 30 May 2013 10:32:22 -0700 Subject: Patch to discourage unencrypted key generation In-Reply-To: <20130530171546.GC24674@ringworld.MIT.EDU> References: <20130530012456.GW24674@ringworld.MIT.EDU> <20130530171308.GB540@linux124.nas.nasa.gov> <20130530171546.GC24674@ringworld.MIT.EDU> Message-ID: <20130530173222.GF509@linux124.nas.nasa.gov> On Thu, May 30, 2013 at 12:15:46 -0500, John Hawkinson wrote: > Iain Morgan wrote on Thu, 30 May 2013 > at 10:13:09 -0700 in <20130530171308.GB540 at linux124.nas.nasa.gov>: > > > - When run as non-root and using an empty password, print a > > warning message and give a simple yes/no prompt to determine > > whether or not to continue. > > Why is the user (root or not) of ssh-keygen relevant here? > > --jhawk at mit.edu > John Hawkinson Host keys are generated as root and usually in a non-interactive manner. Presenting a warning message in this context would just create noise and prompting for confirmation would obviously be a problem. I suppose an alternative would be to test if stdin ia a tty. -- Iain Morgan From dan at doxpara.com Fri May 31 04:43:29 2013 From: dan at doxpara.com (Dan Kaminsky) Date: Thu, 30 May 2013 11:43:29 -0700 Subject: Patch to discourage unencrypted key generation In-Reply-To: <20130530171308.GB540@linux124.nas.nasa.gov> References: <20130530012456.GW24674@ringworld.MIT.EDU> <20130530171308.GB540@linux124.nas.nasa.gov> Message-ID: Unpassworded SSH private keys are the most successful mechanism in the last decade for getting real users to use public key cryptography, rather than passwords, to identify themselves. Everything else is a miserable failure. Don't mess with this one success. Proper API's for adding pubkeys to servers, that might be nice. We've let this authorized_keys situation kinda rot for a bit. Sent from my iPhone On May 30, 2013, at 10:13 AM, Iain Morgan wrote: > On Wed, May 29, 2013 at 20:24:56 -0500, John Hawkinson wrote: >> Schaaf, Jonathan P (GE Healthcare) wrote on Wed, 29 May 2013 >> at 19:14:45 +0000 in : >> >>> I hope I'm not submitting something while Martin is halfway through >>> working on this, but as previously noted, the real complexities are >>> in the change to people's workflow. Let the beatings commence. >> ... >>> + printf("Empty passphrases are a potential security risk. \n" ); >>> + printf("Type \"I know\" to confirm that you want this: " ); >> >> I don't think this is the way to go. >> Among other things, it precludes easy automation of this, which is bad >> (esp., as was noted, for host keys). >> >> Furthremore, it gives just enough information to not be helpful. >> WHY are they a security risk? WHERE can we find out more info? WHAT >> are the alternatives? > > What I would suggest is this: > > - Remove the "(empty for no passphrase)" part of the password > prompt > - Only allow empty passwords with -A or -N '' > - When run as non-root and using an empty password, print a > warning message and give a simple yes/no prompt to determine > whether or not to continue. > - Document the use of -N '' in ssh-keygen(1) > - Possibly add a SECURITY section to ssh-keygen(1) to provide > further details on the security implications of using empty > passwords and how to mitigate them > > This avoids impacting the typical process of creating host keys and > minimally ikpacts the process for non-root users. > > -- > Iain Morgan > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Fri May 31 05:25:17 2013 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 31 May 2013 05:25:17 +1000 Subject: Patch to discourage unencrypted key generation In-Reply-To: References: <20130530012456.GW24674@ringworld.MIT.EDU> <20130530171308.GB540@linux124.nas.nasa.gov> Message-ID: On Fri, May 31, 2013 at 4:43 AM, Dan Kaminsky wrote: > Proper API's for adding pubkeys to servers, that might be nice. There's an ietf draft spec for that: https://datatracker.ietf.org/doc/draft-ietf-secsh-publickey-subsystem/ There's also an implementation for openssh: http://www.vandyke.com/download/os/pks_ossh.html (I've not looked at in detail). -- 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 dkg at fifthhorseman.net Fri May 31 05:54:42 2013 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 30 May 2013 15:54:42 -0400 Subject: Patch to discourage unencrypted key generation In-Reply-To: References: <20130530012456.GW24674@ringworld.MIT.EDU> <20130530171308.GB540@linux124.nas.nasa.gov> Message-ID: <51A7AE82.9050802@fifthhorseman.net> On 05/30/2013 03:25 PM, Darren Tucker wrote: > On Fri, May 31, 2013 at 4:43 AM, Dan Kaminsky wrote: >> Proper API's for adding pubkeys to servers, that might be nice. > > There's an ietf draft spec for that: > https://datatracker.ietf.org/doc/draft-ietf-secsh-publickey-subsystem/ fwiw, it's no longer just a draft spec, it appears to have been formalized as RFC 4819: https://tools.ietf.org/html/rfc4819 Regards, --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 nickolay at antlogic.com.ua Fri May 31 23:37:32 2013 From: nickolay at antlogic.com.ua (Nickolay) Date: Fri, 31 May 2013 16:37:32 +0300 Subject: DH group selection for SHA2-512 bit HMAC. Message-ID: <51A8A79C.7050004@antlogic.com.ua> Hi. I've got the following problem with our SSH client library: - client connects to OpenSSH 5.9+ server and they choose hmac-sha2-512 with diffie-hellman-group-exchange-sha256. - client sends MSG_KEX_DH_GEX_REQUEST DH group request with parameters (1024, 1024, 8192). I.e. minimum and preferred group size is 1024-bit, - OpenSSH server in kexgexs.c:kexgex_server processes this message and selects 1024-bit group, sending it back to client. - however, later, when it goes to shared secret generation, in dh.c:dh_gen_key code checks group size to be 2 * need >= BN_num_bits(dh->p), where need is set to 512 bit (by the size of HMAC, i assume ), producing the error fatal("dh_gen_key: group too small: %d (2*need %d)". So, I think it would be more logical to check 'need' parameter somewhere during group selection. Or am I missing something? Thanks! -- Nickolay Olshevsky, AntLogic Email: nickolay at antlogic.com.ua http://antlogic.com.ua/ From nkadel at gmail.com Fri May 31 23:40:31 2013 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Fri, 31 May 2013 09:40:31 -0400 Subject: Patch to discourage unencrypted key generation In-Reply-To: <20130530171546.GC24674@ringworld.MIT.EDU> References: <20130530012456.GW24674@ringworld.MIT.EDU> <20130530171308.GB540@linux124.nas.nasa.gov> <20130530171546.GC24674@ringworld.MIT.EDU> Message-ID: <5B00EEF4-A27B-4D1B-B7F0-C1F2524E32AF@gmail.com> Generating host keys, which are normally passphrase free and done by root. That can be written into the init script, where such keys are usually generated, and complex test cases avoided. Nico Kadel-Garcia Email: nkadel at gmail.com Sent from iPhone On May 30, 2013, at 13:15, John Hawkinson wrote: > Iain Morgan wrote on Thu, 30 May 2013 > at 10:13:09 -0700 in <20130530171308.GB540 at linux124.nas.nasa.gov>: > >> - When run as non-root and using an empty password, print a >> warning message and give a simple yes/no prompt to determine >> whether or not to continue. > > Why is the user (root or not) of ssh-keygen relevant here? > > --jhawk at mit.edu > John Hawkinson > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev