From lagrangian at gmail.com Fri Dec 3 08:25:03 2010 From: lagrangian at gmail.com (Anders Langworthy) Date: Thu, 2 Dec 2010 16:25:03 -0500 Subject: [PATCH] ssh.1: Clarify remote bind_address usage Message-ID: Hi all, A server with [GatewayPorts "yes"] also ignores client's remote bind_address parameter, contrary to what is implied by the current description. Cheers! Index: src/usr.bin/ssh/ssh.1 =================================================================== RCS file: /cvs/src/usr.bin/ssh/ssh.1,v retrieving revision 1.316 diff -u src/usr.bin/ssh/ssh.1 --- src/usr.bin/ssh/ssh.1 18 Nov 2010 15:01:00 -0000 1.316 +++ src/usr.bin/ssh/ssh.1 2 Dec 2010 20:44:59 -0000 @@ -509,11 +509,11 @@ or the address .Ql * , indicates that the remote socket should listen on all interfaces. -Specifying a remote +The behavior of the .Ar bind_address -will only succeed if the server's +parameter is dependent on the value of the server's .Cm GatewayPorts -option is enabled (see +option (see .Xr sshd_config 5 ) . .Pp If the From rapier at psc.edu Tue Dec 7 09:03:56 2010 From: rapier at psc.edu (rapier) Date: Mon, 06 Dec 2010 17:03:56 -0500 Subject: File Offsets for SCP (patch revised yet again) In-Reply-To: <4CEAF2DA.9080507@psc.edu> References: <4CE6DDB6.8070908@psc.edu> <4CEACC79.3080407@psc.edu> <4CEAF2DA.9080507@psc.edu> Message-ID: <4CFD5DCC.80600@psc.edu> This version of the patch now does partial file transfers in both directions. -A specifies the start byte -L the length. As systems might have the patched scp running as a secondary server I have also include a method to provide a path to the desired scp executable using the -a option. Again, I don't know if this will be useful to anyone else. We're going to be using this to do parallelized transfers of large (250GB+) files (using the HPN patch set as well). We're basically trying to avoid the slow start penalties on very fast throughputs by splitting the transfer up. I know scp is no longer supported in anyway except to maintain the versioning. Unfortunately, a huge number of people still use scp in preference to scp. I'm an enabler. :\ chris rapier wrote: > Just a follow up patch. You now just specify the byte length you want to > transfer and a little more error checking. Again, don't know if this > would be useful to anyone but I thought I'd share just in case. Also, > just to make sure this is clear, this only works on the source side. > > --- ../canonical-openssh5.6/scp.c 2010-07-01 23:37:33.000000000 -0400 > +++ ./scp.c 2010-11-22 19:48:46.000000000 -0500 > @@ -302,6 +302,8 @@ struct passwd *pwd; > uid_t userid; > int errs, remin, remout; > int pflag, iamremote, iamrecursive, targetshouldbedirectory; > +// user requested file offset and amount of data to xfer > +double fd_offset, fd_length; > > #define CMDNEEDS 64 > char cmd[CMDNEEDS]; /* must hold "rcp -r -p -d\0" */ > @@ -324,6 +326,9 @@ main(int argc, char **argv) > extern char *optarg; > extern int optind; > > + fd_length = 0; > + fd_offset = 0; > + > /* Ensure that fds 0, 1 and 2 are open or directed to /dev/null */ > sanitise_stdfd(); > > @@ -344,7 +349,7 @@ main(int argc, char **argv) > addargs(&args, "-oClearAllForwardings yes"); > > fflag = tflag = 0; > - while ((ch = getopt(argc, argv, "dfl:prtvBCc:i:P:q1246S:o:F:")) != -1) > + while ((ch = getopt(argc, argv, "dfl:prtvBCc:i:P:q1246S:o:F:A:L:")) > != -1) > switch (ch) { > /* User-visible flags. */ > case '1': > @@ -407,6 +412,16 @@ main(int argc, char **argv) > setmode(0, O_BINARY); > #endif > break; > + case 'A': > + fd_offset = strtod(optarg, &endp); > + if (fd_offset < 0 || *endp != '\0') > + usage(); > + break; > + case 'L': > + fd_length = strtod(optarg, &endp); > + if (fd_length < 0 || *endp != '\0') > + usage(); > + break; > default: > usage(); > } > @@ -680,6 +695,34 @@ syserr: run_err("%s: %s", name, strerr > run_err("%s: %s", name, "Negative file size"); > goto next; > } > + > + // if the offset is greater than the file size > + // we can't do this > + if (fd_offset > stb.st_size) { > + run_err("Offset greater than file size"); > + goto next; > + } > + > + // if the offset plus the requested length are greater > + // than the file size then we have to quit > + if (fd_length + fd_offset > stb.st_size) { > + run_err("Length greater than file size"); > + goto next; > + } > + > + // if the user only has an offset then we reduce > + // the file size by the offset. if they have a length > + // then we use stb.st_size and the length > + // to determine the actual stopping point > + if (fd_length != 0) { > + stb.st_size -= (stb.st_size - fd_length); > + } else { > + stb.st_size -= fd_offset; > + } > + > + // seek to the position as requested by user > + lseek (fd, fd_offset, SEEK_SET); > + > unset_nonblock(fd); > switch (stb.st_mode & S_IFMT) { > case S_IFREG: > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From mouring at eviladmin.org Tue Dec 7 13:09:30 2010 From: mouring at eviladmin.org (Ben Lindstrom) Date: Mon, 6 Dec 2010 20:09:30 -0600 Subject: File Offsets for SCP (patch revised yet again) In-Reply-To: <4CFD5DCC.80600@psc.edu> References: <4CE6DDB6.8070908@psc.edu> <4CEACC79.3080407@psc.edu> <4CEAF2DA.9080507@psc.edu> <4CFD5DCC.80600@psc.edu> Message-ID: I knows it is on the list to teach sftp to act like scp (using sftp protocol) if ln -s sftp scp ... That may be a better investment. - Ben On Dec 6, 2010, at 4:03 PM, rapier wrote: > This version of the patch now does partial file transfers in both directions. -A specifies the start byte -L the length. As systems might have the patched scp running as a secondary server I have also include a method to provide a path to the desired scp executable using the -a option. > > Again, I don't know if this will be useful to anyone else. We're going to be using this to do parallelized transfers of large (250GB+) files (using the HPN patch set as well). We're basically trying to avoid the slow start penalties on very fast throughputs by splitting the transfer up. > > I know scp is no longer supported in anyway except to maintain the versioning. Unfortunately, a huge number of people still use scp in preference to scp. I'm an enabler. :\ > > chris > > > > rapier wrote: >> Just a follow up patch. You now just specify the byte length you want to transfer and a little more error checking. Again, don't know if this would be useful to anyone but I thought I'd share just in case. Also, just to make sure this is clear, this only works on the source side. >> --- ../canonical-openssh5.6/scp.c 2010-07-01 23:37:33.000000000 -0400 >> +++ ./scp.c 2010-11-22 19:48:46.000000000 -0500 >> @@ -302,6 +302,8 @@ struct passwd *pwd; >> uid_t userid; >> int errs, remin, remout; >> int pflag, iamremote, iamrecursive, targetshouldbedirectory; >> +// user requested file offset and amount of data to xfer >> +double fd_offset, fd_length; >> #define CMDNEEDS 64 >> char cmd[CMDNEEDS]; /* must hold "rcp -r -p -d\0" */ >> @@ -324,6 +326,9 @@ main(int argc, char **argv) >> extern char *optarg; >> extern int optind; >> + fd_length = 0; >> + fd_offset = 0; >> + >> /* Ensure that fds 0, 1 and 2 are open or directed to /dev/null */ >> sanitise_stdfd(); >> @@ -344,7 +349,7 @@ main(int argc, char **argv) >> addargs(&args, "-oClearAllForwardings yes"); >> fflag = tflag = 0; >> - while ((ch = getopt(argc, argv, "dfl:prtvBCc:i:P:q1246S:o:F:")) != -1) >> + while ((ch = getopt(argc, argv, "dfl:prtvBCc:i:P:q1246S:o:F:A:L:")) != -1) >> switch (ch) { >> /* User-visible flags. */ >> case '1': >> @@ -407,6 +412,16 @@ main(int argc, char **argv) >> setmode(0, O_BINARY); >> #endif >> break; >> + case 'A': >> + fd_offset = strtod(optarg, &endp); >> + if (fd_offset < 0 || *endp != '\0') >> + usage(); >> + break; >> + case 'L': >> + fd_length = strtod(optarg, &endp); >> + if (fd_length < 0 || *endp != '\0') >> + usage(); >> + break; >> default: >> usage(); >> } >> @@ -680,6 +695,34 @@ syserr: run_err("%s: %s", name, strerr >> run_err("%s: %s", name, "Negative file size"); >> goto next; >> } >> + >> + // if the offset is greater than the file size >> + // we can't do this >> + if (fd_offset > stb.st_size) { >> + run_err("Offset greater than file size"); >> + goto next; >> + } >> + + // if the offset plus the requested length are greater >> + // than the file size then we have to quit >> + if (fd_length + fd_offset > stb.st_size) { >> + run_err("Length greater than file size"); >> + goto next; >> + } >> + >> + // if the user only has an offset then we reduce >> + // the file size by the offset. if they have a length >> + // then we use stb.st_size and the length >> + // to determine the actual stopping point >> + if (fd_length != 0) { >> + stb.st_size -= (stb.st_size - fd_length); >> + } else { >> + stb.st_size -= fd_offset; >> + } >> + + // seek to the position as requested by user >> + lseek (fd, fd_offset, SEEK_SET); >> + >> unset_nonblock(fd); >> switch (stb.st_mode & S_IFMT) { >> case S_IFREG: >> _______________________________________________ >> 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 rapier at psc.edu Wed Dec 8 02:19:22 2010 From: rapier at psc.edu (rapier) Date: Tue, 07 Dec 2010 10:19:22 -0500 Subject: File Offsets for SCP (patch revised yet again) In-Reply-To: References: <4CE6DDB6.8070908@psc.edu> <4CEACC79.3080407@psc.edu> <4CEAF2DA.9080507@psc.edu> <4CFD5DCC.80600@psc.edu> Message-ID: <4CFE507A.4080403@psc.edu> I actually agree but have a couple of reservations. The first is the user issue. Getting users to do the right thing, especially after they've been doing something else for years and years, is always a challenge. If SFTP can be made to act like SCP then it's going to be critical to just get rid of SCP entirely and do the ln -s trick. The second is that the messaging window size is a limitation for the users I'm supporting (major research institutions usually connected via multiple gig or 10Ge connections). Anything that ends up impeding maximum performance is going to be problematic (that is why I developed the HPN-SSH patch). At some point it may make sense to dynamically grow the message window size (because expecting users to set it correctly is just not going to work (thats why we did the work on the auto-tuning receive buffers)). I may get the funding to do that but I just don't know at this point. So right now I'm going with the quick and dirty fix :) Basically, network performance is where my focus is rather than SSH in and of itself. Chris Ben Lindstrom wrote: > I knows it is on the list to teach sftp to act like scp (using sftp protocol) if ln -s sftp scp ... That may be a better investment. > > - Ben > > > On Dec 6, 2010, at 4:03 PM, rapier wrote: > >> This version of the patch now does partial file transfers in both directions. -A specifies the start byte -L the length. As systems might have the patched scp running as a secondary server I have also include a method to provide a path to the desired scp executable using the -a option. >> >> Again, I don't know if this will be useful to anyone else. We're going to be using this to do parallelized transfers of large (250GB+) files (using the HPN patch set as well). We're basically trying to avoid the slow start penalties on very fast throughputs by splitting the transfer up. >> >> I know scp is no longer supported in anyway except to maintain the versioning. Unfortunately, a huge number of people still use scp in preference to scp. I'm an enabler. :\ >> >> chris >> >> >> >> rapier wrote: >>> Just a follow up patch. You now just specify the byte length you want to transfer and a little more error checking. Again, don't know if this would be useful to anyone but I thought I'd share just in case. Also, just to make sure this is clear, this only works on the source side. >>> --- ../canonical-openssh5.6/scp.c 2010-07-01 23:37:33.000000000 -0400 >>> +++ ./scp.c 2010-11-22 19:48:46.000000000 -0500 >>> @@ -302,6 +302,8 @@ struct passwd *pwd; >>> uid_t userid; >>> int errs, remin, remout; >>> int pflag, iamremote, iamrecursive, targetshouldbedirectory; >>> +// user requested file offset and amount of data to xfer >>> +double fd_offset, fd_length; >>> #define CMDNEEDS 64 >>> char cmd[CMDNEEDS]; /* must hold "rcp -r -p -d\0" */ >>> @@ -324,6 +326,9 @@ main(int argc, char **argv) >>> extern char *optarg; >>> extern int optind; >>> + fd_length = 0; >>> + fd_offset = 0; >>> + >>> /* Ensure that fds 0, 1 and 2 are open or directed to /dev/null */ >>> sanitise_stdfd(); >>> @@ -344,7 +349,7 @@ main(int argc, char **argv) >>> addargs(&args, "-oClearAllForwardings yes"); >>> fflag = tflag = 0; >>> - while ((ch = getopt(argc, argv, "dfl:prtvBCc:i:P:q1246S:o:F:")) != -1) >>> + while ((ch = getopt(argc, argv, "dfl:prtvBCc:i:P:q1246S:o:F:A:L:")) != -1) >>> switch (ch) { >>> /* User-visible flags. */ >>> case '1': >>> @@ -407,6 +412,16 @@ main(int argc, char **argv) >>> setmode(0, O_BINARY); >>> #endif >>> break; >>> + case 'A': >>> + fd_offset = strtod(optarg, &endp); >>> + if (fd_offset < 0 || *endp != '\0') >>> + usage(); >>> + break; >>> + case 'L': >>> + fd_length = strtod(optarg, &endp); >>> + if (fd_length < 0 || *endp != '\0') >>> + usage(); >>> + break; >>> default: >>> usage(); >>> } >>> @@ -680,6 +695,34 @@ syserr: run_err("%s: %s", name, strerr >>> run_err("%s: %s", name, "Negative file size"); >>> goto next; >>> } >>> + >>> + // if the offset is greater than the file size >>> + // we can't do this >>> + if (fd_offset > stb.st_size) { >>> + run_err("Offset greater than file size"); >>> + goto next; >>> + } >>> + + // if the offset plus the requested length are greater >>> + // than the file size then we have to quit >>> + if (fd_length + fd_offset > stb.st_size) { >>> + run_err("Length greater than file size"); >>> + goto next; >>> + } >>> + >>> + // if the user only has an offset then we reduce >>> + // the file size by the offset. if they have a length >>> + // then we use stb.st_size and the length >>> + // to determine the actual stopping point >>> + if (fd_length != 0) { >>> + stb.st_size -= (stb.st_size - fd_length); >>> + } else { >>> + stb.st_size -= fd_offset; >>> + } >>> + + // seek to the position as requested by user >>> + lseek (fd, fd_offset, SEEK_SET); >>> + >>> unset_nonblock(fd); >>> switch (stb.st_mode & S_IFMT) { >>> case S_IFREG: >>> _______________________________________________ >>> 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 philipp.marek at linbit.com Wed Dec 8 02:49:11 2010 From: philipp.marek at linbit.com (Philipp Marek) Date: Tue, 7 Dec 2010 16:49:11 +0100 Subject: File Offsets for SCP (patch revised yet again) In-Reply-To: <4CFE507A.4080403@psc.edu> References: <4CE6DDB6.8070908@psc.edu> <4CFE507A.4080403@psc.edu> Message-ID: <201012071649.13523.philipp.marek@linbit.com> On Tuesday 07 December 2010, rapier wrote: > The second is that the messaging window size is a limitation for the > users I'm supporting (major research institutions usually connected via > multiple gig or 10Ge connections). Anything that ends up impeding > maximum performance is going to be problematic (that is why I developed > the HPN-SSH patch). At some point it may make sense to dynamically grow > the message window size (because expecting users to set it correctly is > just not going to work (thats why we did the work on the auto-tuning > receive buffers)). I may get the funding to do that but I just don't > know at this point. So right now I'm going with the quick and dirty fix > :) > > Basically, network performance is where my focus is rather than SSH in > and of itself. ... > >> Again, I don't know if this will be useful to anyone else. We're going > >> to be using this to do parallelized transfers of large (250GB+) files > >> (using the HPN patch set as well). We're basically trying to avoid > >> the slow start penalties on very fast throughputs by splitting the > >> transfer up. Reading all this I just don't know whether this is just the wrong solution... If you want faster startup, how about using a different TCP scheduling algorithm? http://www-iepm.slac.stanford.edu/bw/tcp-eval/ Having a config option to choose the scheduler might be useful to more people, I think - especially as it would do faster transfers automatically, without messing around with partial transmissions. BTW that would lower fragmentation on the destination, too. Regards, Phil From rapier at psc.edu Wed Dec 8 03:32:44 2010 From: rapier at psc.edu (rapier) Date: Tue, 07 Dec 2010 11:32:44 -0500 Subject: File Offsets for SCP (patch revised yet again) In-Reply-To: <201012071649.13523.philipp.marek@linbit.com> References: <4CE6DDB6.8070908@psc.edu> <4CFE507A.4080403@psc.edu> <201012071649.13523.philipp.marek@linbit.com> Message-ID: <4CFE61AC.8040503@psc.edu> We actually built a test platform (a live ubuntu cd they run on their local machine) to automatically run a series of tests (iperf, npad, ndt, etc) across a set of six or seven congestions control algorithms. This allows us to quickly determine the best algorithm for the particular users network path (along with diagnosing other performance issues). The problem is that we can't get all users to boot this ISO and, even with and aggressive algorithm we can't always spend as much time out of slow start as we want. I'm working on the math now to determine the optimal number of concurrent streams for various algorithms, bandwidth (1Gb, 10, 40, and 100), and so forth. At some point we end up running into CPU limits even when we switch the cipher to NONE. Of course, if we ever thread the HMAC routine maybe that will help. At that point we'd probably run into disk I/O issues... Anyway, we're actually planning on using clusters of machines to transfer data. One section of the file will be on machine A, one will be on B, and so forth. Philipp Marek wrote: > On Tuesday 07 December 2010, rapier wrote: >> The second is that the messaging window size is a limitation for the >> users I'm supporting (major research institutions usually connected via >> multiple gig or 10Ge connections). Anything that ends up impeding >> maximum performance is going to be problematic (that is why I developed >> the HPN-SSH patch). At some point it may make sense to dynamically grow >> the message window size (because expecting users to set it correctly is >> just not going to work (thats why we did the work on the auto-tuning >> receive buffers)). I may get the funding to do that but I just don't >> know at this point. So right now I'm going with the quick and dirty fix >> :) >> >> Basically, network performance is where my focus is rather than SSH in >> and of itself. > ... >>>> Again, I don't know if this will be useful to anyone else. We're going >>>> to be using this to do parallelized transfers of large (250GB+) files >>>> (using the HPN patch set as well). We're basically trying to avoid >>>> the slow start penalties on very fast throughputs by splitting the >>>> transfer up. > Reading all this I just don't know whether this is just the wrong > solution... If you want faster startup, how about using a different TCP > scheduling algorithm? > > http://www-iepm.slac.stanford.edu/bw/tcp-eval/ > > > Having a config option to choose the scheduler might be useful to more > people, I think - especially as it would do faster transfers automatically, > without messing around with partial transmissions. > BTW that would lower fragmentation on the destination, too. > > > Regards, > > Phil From ramyarangarajan86 at gmail.com Wed Dec 8 15:15:32 2010 From: ramyarangarajan86 at gmail.com (Ramya Rangarajan) Date: Wed, 8 Dec 2010 09:45:32 +0530 Subject: Query on sshpam_tty_conv Message-ID: Hi, I am facing issues with couple of cases during authentication using pam for openssh Case 1: When we get challenge response from pam radius module with Echo prompt ON or OFF, its not getting displayed in ssh prompt because currently * sshpam_tty_conv* do not support the display of plain text. Case 2: When any INFO or ERROR message is passed to *sshpam_tty_conv *from underlying pam module before authentication is successful, those messages are also not getting displayed since stdio is not connected. Can anyone please provide suggestions on this openssh behaviour From smoser at ubuntu.com Fri Dec 10 02:27:26 2010 From: smoser at ubuntu.com (Scott Moser) Date: Thu, 9 Dec 2010 10:27:26 -0500 (EST) Subject: [PATCH] mention ssh-keyscan in remote host fingerprint warning Message-ID: Hi, below is a patch to simply mention 'ssh-keygen' when a fingerprint does not match between the known_hosts file and the remote. I find that many people are unaware that ssh-keygen can do this for them. adding a copy-and-pasteable message in the warning will make users more aware. Description: Mention ssh-keygen in ssh fingerprint changed warning Author: Scott Moser Bug: https://launchpad.net/bugs/686607 Index: openssh/sshconnect.c =================================================================== --- openssh.orig/sshconnect.c 2010-12-09 10:21:33.889760054 -0500 +++ openssh/sshconnect.c 2010-12-09 10:22:02.139864915 -0500 @@ -908,14 +908,17 @@ error("%s. This could either mean that", key_msg); error("DNS SPOOFING is happening or the IP address for the host"); error("and its host key have changed at the same time."); - if (ip_status != HOST_NEW) + if (ip_status != HOST_NEW) { error("Offending key for IP in %s:%d", ip_file, ip_line); + error(" remove with: ssh-keygen -f \"%s\" -R %d", ip_file, ip_line); + } } /* The host key has changed. */ warn_changed_key(host_key); error("Add correct host key in %.100s to get rid of this message.", user_hostfile); error("Offending key in %s:%d", host_file, host_line); + error(" remove with: ssh-keygen -f \"%s\" -R %d", host_file, host_line); /* * If strict host key checking is in use, the user will have From djm at mindrot.org Fri Dec 10 14:33:11 2010 From: djm at mindrot.org (Damien Miller) Date: Fri, 10 Dec 2010 14:33:11 +1100 (EST) Subject: Query on sshpam_tty_conv In-Reply-To: References: Message-ID: On Wed, 8 Dec 2010, Ramya Rangarajan wrote: > Hi, > > I am facing issues with couple of cases during authentication using pam for > openssh > > Case 1: > > When we get challenge response from pam radius module with Echo prompt ON > or OFF, its not getting displayed in ssh prompt because currently * > sshpam_tty_conv* do not support the display of plain text. sshpam_tty_conv is never used to run PAM auth or account modules. It can only be used for session modules when changing the user's password after a TTY has been connected. If you need message echoing, then make sure you disable password authentication and enable challenge/response authentication. The PAM conversation function that is used for challenge/response authentication supports message echoing. > Case 2: > > When any INFO or ERROR message is passed to *sshpam_tty_conv *from > underlying pam module before authentication is successful, those messages > are also not getting displayed since stdio is not connected. same as above. -d From contact at setit.rnu.tn Fri Dec 10 13:31:34 2010 From: contact at setit.rnu.tn (Med Salim BOUHLEL) Date: Fri, 10 Dec 2010 03:31:34 +0100 Subject: Extended Deadline and Financial Support Message-ID: <261262400240126968910@salm-2db062c067> Dear, At the request of a number of potential contributors, we have decided to extend the deadline for receipt of papers to be presented to The 6th International Conference: Sciences of Electronics, Technologies of Information and Telecommunications SETIT 2011. This deadline is extended to December 31, 2010. This conference will be held in Tunisia, 23-26 March 2011. The paper submission is on-line at: http://www.setit.rnu.tn/?pg=submission In this conference; 300 participants will benefit from a financial support. This Financial support, of amount 250 euro, will be available to help participants from developing or emerging countries as well as young researchers to attend SETIT?2011. The financial support form is available on the web site http://www.setit.rnu.tn/FinancialSupport.dot. It should be filled in details and sent by e-mail to financialsupport.setit at gmail.com. The SETIT organization committee will examine on a case by case basis all requests and provide a reply in a one week period. Please note that financial support requests must be sent before 15 January 2011. Online registration can be found at: http://www.setit.rnu.tn/?main=1&pg=registration_aut . NB: As official carrier sponsor for the 6th International Conference SETIT 2011, TUNISAIR will offer to all participants and their accompanying people attending this Conference the following special offer: 50% discount on the excursion charge to Tunisia on Tunisair in economic class. To benefit from this very special offer, contact the Tunisair Representation Offices in your country carrying an official invitation delivred through e-mail by the conference chairman. You can find more details in: http://www.setit.rnu.tn/ Your propositions are welcome (they can be made either in French or in English). ================================================================== We are waiting for seeing you in Tunisia in SETIT 2011. Best Regards Mohamed Salim BOUHLEL General Co-Chair, SETIT 2011 Director of Sfax High Institute of Electronics and Communication Head of Research Unit:Sciences & Technologies of Image and Telecommunications ( Sfax University ) GSM +216 20 200005 Skype Name: UR-SETIT ============================================================================================== If you want to be removed from our database, please send an email to unsubscribe.setit at gmail.com with subject: Unsubscribe ============================================================================================== SETIT 2011 Sixth International Conference Sciences of Electronic, Technologies of Information and Telecommunications Sousse, Tunisia, March 23-26, 2011 http://www.setit.rnu.tn/ == SETIT 2011 PRESENTATION ============================================= SETIT 2011 has the ambition to promote a technological reference frame, to give answers and original innovating ideas and to contribute to a common language around the information processing and the telecommunications. This conference will allow, on one hand, to share experience, to make a state of the art of the theory, research, telecommunication applications and the Information processing. On the other hand, Setit will present future innovations. == TOPICS ============================================================== The topics of this conference are voluntarily opened in order to support the participation of many teams (researchers, teachers, engineers, industrialists and students). A broad place will be reserved for the new ideas, with not yet succeeded work, original work positioning clearly compared to what exists. Here a non exhaustive list of the topics: Electronic System Integration (SoC, MPSoC, Mixed-Signal) Electronic Integration RF and Wireless Circuits and Systems Circuits and Systems for Communications Advanced Technologies (Nano, MEMS) Image and Video Image and video Processing Technology Compression, Coding, and Implementation Cryptology and Watermarking Storage, Retrieval, and Authentication Multimedia Management and diffusion of Multimedia Applications Multimedia Data Base Documents Modelisation and Interpretation Telecommunication?s Computer Science Telecommunications and Networks Networks Protocols and Wireless Networks Next Generations Networks Security Quality of Service and Resource Management Wireless Communication Computer Science Interacting Humans with Computing Systems Algorithme and Theory Programming Languages Information Systems Management Intelligent e-Technology Signal Processing Non-stationary, non-linear and non-gaussian Signal Processing Audio/ Acoustic/speech / Biomedical Signal Processing Signal Detection, Estimation and Restoration Statistical Signal Processing Design and Implementation of Signal Processing Systems Information Processing Information Fusion Neuronal Networks and Fuzzy Logic Rationing Methods Data Mining == IMPORTANT DATES ========================================================= Extended Deadline : December 31, 2010 Notification of acceptance : January 31, 2011 Final manuscript due : Fabruary 15, 2011 Main conference : March 23-26, 2011 == CONFERENCE'S PLACE ====================================================== Sousse "the pearl of the Sahel" is located on the eastern coast of Tunisia, two hours from the capital Tunis in the central-east of the country, on the Gulf of Hammamet, which is a part of the Mediterranean Sea. The mildness of its climate, its calm and beautiful coast and the hospitality of its people have long captivated those who came to conquer. It is home to many resorts and fine sandy beaches backed by orchards and olive groves. It has a pleasant Mediterranean climate, with hot, dry summers and warm, mild wet winters. It also has a skilled population, and serves as a strategic geographic location. From akulov-aa at ya.ru Fri Dec 10 20:33:07 2010 From: akulov-aa at ya.ru (=?koi8-r?B?4cvVzM/XIOHMxcvTxco=?=) Date: Fri, 10 Dec 2010 12:33:07 +0300 Subject: Problem of updating openssh-4.4p1 to openssh-5.5p1 with MAX_ALLOW_USERS option Message-ID: <379461291973588@web29.yandex.ru> Hello! We have the server with RHEL 5.5 (64-bit) and need to connect many parallel users over ssh (OpenSSH). Usually we use openssh-4.4p1, builded from the sources with changed "servconf.h" file by this type: ???#define MAX_ALLOW_USERS ????????10000 ????/* Max # users on allow list. */ ???#define MAX_DENY_USERS ???????????10000 ????/* Max # users on deny list. */ ???#define MAX_ALLOW_GROUPS ?????10000 ????/* Max # groups on allow list. */ ???#define MAX_DENY_GROUPS ????????10000 ????/* Max # groups on deny list. */ and configured with this additional options: # ./configure --prefix=/usr --sysconfdir=/etc/ssh --with-ipv4-default --with-pam --without-4in6 --without-zlib-version-check # make # make install. After compiling and restarting service ssh (# service sshd condrestart) we had possibility to connect many parallel users to our server. Now we want to update a version of OpenSSH from openssh-4.4p1 to openssh-5.5p1 but have a problem with the maximum quantity of line "AllowUsers" in file "/etc/ssh/sshd_config" after such operations as we had done with openssh-4.4p1. # service sshd restart Stopping sshd: ?????????????????????????????????????????????????????????????????????????????????????????????????????[FAILED] Starting sshd: /etc/ssh/sshd_config line 622: too many allow users. ?????????????[FAILED] What we do incorrect? Thanks. With the best regards, Alex. From akulov-aa at ya.ru Sat Dec 11 08:17:08 2010 From: akulov-aa at ya.ru (=?koi8-r?B?4cvVzM/XIOHMxcvTxco=?=) Date: Sat, 11 Dec 2010 00:17:08 +0300 Subject: Fwd: Problem of updating openssh-4.4p1 to openssh-5.5p1 with MAX_ALLOW_USERS option Message-ID: <387991292015829@web38.yandex.ru> Hello! > Hello! > > We have the server with RHEL 5.5 (64-bit) and need to connect many parallel users over ssh (OpenSSH). > Usually we use openssh-4.4p1, builded from the sources with changed "servconf.h" file by this type: > #define MAX_ALLOW_USERS 10000 /* Max # users on allow list. */ > #define MAX_DENY_USERS 10000 /* Max # users on deny list. */ > #define MAX_ALLOW_GROUPS 10000 /* Max # groups on allow list. */ > #define MAX_DENY_GROUPS 10000 /* Max # groups on deny list. */ > > and configured with this additional options: > # ./configure --prefix=/usr --sysconfdir=/etc/ssh --with-ipv4-default --with-pam --without-4in6 --without-zlib-version-check > # make > # make install. > > After compiling and restarting service ssh (# service sshd condrestart) we had possibility to connect many parallel users to our server. > > Now we want to update a version of OpenSSH from openssh-4.4p1 to openssh-5.5p1 but have a problem with the maximum quantity of line "AllowUsers" in file "/etc/ssh/sshd_config" after such operations as we had done with openssh-4.4p1. > # service sshd restart > Stopping sshd: [FAILED] > Starting sshd: /etc/ssh/sshd_config line 622: too many allow users. [FAILED] > > What we do incorrect? > > Thanks. > > With the best regards, Alex. P.S. I duplicated this letter in UTF-8, at it was needed. -------- ???????????? ????????? -------- 10.12.10, 23:49, "Philip Prindeville" : Can you please post to english language mailing lists in UTF8 so you don't cause Spam filter False-Positive matches? Thanks. On 12/10/10 1:33 AM, ?????? ??????? wrote: > Hello! > > We have the server with RHEL 5.5 (64-bit) and need to connect many parallel users over ssh (OpenSSH). > Usually we use openssh-4.4p1, builded from the sources with changed "servconf.h" file by this type: > #define MAX_ALLOW_USERS 10000 /* Max # users on allow list. */ > #define MAX_DENY_USERS 10000 /* Max # users on deny list. */ > #define MAX_ALLOW_GROUPS 10000 /* Max # groups on allow list. */ > #define MAX_DENY_GROUPS 10000 /* Max # groups on deny list. */ > > and configured with this additional options: > # ./configure --prefix=/usr --sysconfdir=/etc/ssh --with-ipv4-default --with-pam --without-4in6 --without-zlib-version-check > # make > # make install. > > After compiling and restarting service ssh (# service sshd condrestart) we had possibility to connect many parallel users to our server. > > Now we want to update a version of OpenSSH from openssh-4.4p1 to openssh-5.5p1 but have a problem with the maximum quantity of line "AllowUsers" in file "/etc/ssh/sshd_config" after such operations as we had done with openssh-4.4p1. > # service sshd restart > Stopping sshd: [FAILED] > Starting sshd: /etc/ssh/sshd_config line 622: too many allow users. [FAILED] > > What we do incorrect? > > Thanks. > > With the best regards, Alex. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -------- ?????????? ????????????? ????????? -------- From djm at mindrot.org Sat Dec 11 09:57:11 2010 From: djm at mindrot.org (Damien Miller) Date: Sat, 11 Dec 2010 09:57:11 +1100 (EST) Subject: Problem of updating openssh-4.4p1 to openssh-5.5p1 with MAX_ALLOW_USERS option In-Reply-To: <379461291973588@web29.yandex.ru> References: <379461291973588@web29.yandex.ru> Message-ID: On Fri, 10 Dec 2010, ?????? ??????? wrote: > Hello! > > We have the server with RHEL 5.5 (64-bit) and need to connect many parallel users over ssh (OpenSSH). > Usually we use openssh-4.4p1, builded from the sources with changed "servconf.h" file by this type: > #define MAX_ALLOW_USERS 10000 /* Max # users on allow list. */ > #define MAX_DENY_USERS 10000 /* Max # users on deny list. */ > #define MAX_ALLOW_GROUPS 10000 /* Max # groups on allow list. */ > #define MAX_DENY_GROUPS 10000 /* Max # groups on deny list. */ Those definitions don't do what you think they do. They are the number of users that can appear in AllowUsers/DenyUsers/AllowGroups/DenyGroups statement and have no effect on the number of users that are allowed to concurrently log in. -d From akulov-aa at ya.ru Sat Dec 11 10:18:00 2010 From: akulov-aa at ya.ru (=?koi8-r?B?4cvVzM/XIOHMxcvTxco=?=) Date: Sat, 11 Dec 2010 02:18:00 +0300 Subject: Problem of updating openssh-4.4p1 to openssh-5.5p1 with MAX_ALLOW_USERS option In-Reply-To: References: <379461291973588@web29.yandex.ru> Message-ID: <472441292023080@web22.yandex.ru> Hello, Damien. I'm sory, may be I have told not exactly. I understand, that defined variable MAX_ALLOW_USERS sets the maximum possible strings of "AllowUsers"-type in file "/etc/ssh/sshd_config". In the version openssh-4.4p1 changing of this defined option makes possible to include big quality of "AllowUsers"-strings in file "/etc/ssh/sshd_config", but in the version openssh-5.5p1 this changes doesn't give similar results. Tell me, please, why it may be occurs in version 5.5p1? Thanks. With the best regards, Alex. 11.12.10, 01:57, "Damien Miller" : On Fri, 10 Dec 2010, ?????? ??????? wrote: > Hello! > > We have the server with RHEL 5.5 (64-bit) and need to connect many parallel users over ssh (OpenSSH). > Usually we use openssh-4.4p1, builded from the sources with changed "servconf.h" file by this type: > ????#define MAX_ALLOW_USERS ????????10000 ????/* Max # users on allow list. */ > ????#define MAX_DENY_USERS ???????????10000 ????/* Max # users on deny list. */ > ????#define MAX_ALLOW_GROUPS ?????10000 ????/* Max # groups on allow list. */ > ????#define MAX_DENY_GROUPS ????????10000 ????/* Max # groups on deny list. */ Those definitions don't do what you think they do. They are the number of users that can appear in AllowUsers/DenyUsers/AllowGroups/DenyGroups statement and have no effect on the number of users that are allowed to concurrently log in. -d From imorgan at nas.nasa.gov Tue Dec 14 05:31:24 2010 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 13 Dec 2010 10:31:24 -0800 Subject: Problem of updating openssh-4.4p1 to openssh-5.5p1 with MAX_ALLOW_USERS option In-Reply-To: <472441292023080@web22.yandex.ru> References: <379461291973588@web29.yandex.ru> <472441292023080@web22.yandex.ru> Message-ID: <20101213183124.GB6057@linux124.nas.nasa.gov> On Fri, Dec 10, 2010 at 17:18:00 -0600, ?????? ??????? wrote: > Hello, Damien. > > I'm sory, may be I have told not exactly. > I understand, that defined variable MAX_ALLOW_USERS sets the maximum possible strings of "AllowUsers"-type in file "/etc/ssh/sshd_config". > In the version openssh-4.4p1 changing of this defined option makes possible to include big quality of "AllowUsers"-strings in file "/etc/ssh/sshd_config", but in the version openssh-5.5p1 this changes doesn't give similar results. > Tell me, please, why it may be occurs in version 5.5p1? > > Thanks. > Hello, So, to be clear, the issue is that you want to have a large number of AllowUser statements rather than the need for a large number of concurrent logins. In that case, I'm not sure why increasing these constants does not have the same effect as with OpenSSH 4.4. Having said that, there may be alternative solutions to your issue. AllowGroups might be a better solution than AllowUsers. You could, for example, create a group that consists only of those users that are allowed to login to the system. Or, it that is not acceptable for some reason, you could create a number of groups. Besides the limit on the number of entries, AllowUsers has the disadvantage that you must restart sshd whenever a user is added or removed from the list of allowed users. There are PAM-based solutions, such as pam_access, that provide similar functionality but do not require a restart of sshd. I believe that you indicated you are using RHEL, which includes pam_access, so you may want to take a look at it. -- Iain Morgan From dkg at fifthhorseman.net Tue Dec 14 06:00:55 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 13 Dec 2010 14:00:55 -0500 Subject: Should Subsystem work in a Match block? Message-ID: <4D066D67.1010507@fifthhorseman.net> hi folks-- Can a Match block cover a Subsystem directive in sftp? https://bugzilla.mindrot.org/show_bug.cgi?id=1587#c1 suggests that Match can cover Subsystem, but sshd_config (at least, in 5.5p1) doesn't mention Subsystem within the description of Match. What should administrators expect? --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From imorgan at nas.nasa.gov Tue Dec 14 08:33:07 2010 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Mon, 13 Dec 2010 13:33:07 -0800 Subject: Should Subsystem work in a Match block? In-Reply-To: <4D066D67.1010507@fifthhorseman.net> References: <4D066D67.1010507@fifthhorseman.net> Message-ID: <20101213213307.GC6057@linux124.nas.nasa.gov> On Mon, Dec 13, 2010 at 13:00:55 -0600, Daniel Kahn Gillmor wrote: > hi folks-- > > Can a Match block cover a Subsystem directive in sftp? > > https://bugzilla.mindrot.org/show_bug.cgi?id=1587#c1 > > suggests that Match can cover Subsystem, but sshd_config (at least, in > 5.5p1) doesn't mention Subsystem within the description of Match. > > What should administrators expect? > > --dkg > No, the Subsystem directive is not supported under Match blocks. You can check this in servconf.c. Look for the definition of the keywords array. The third field in each entry indicates whether the option is supported in Match blocks or not. For those that are, you will normally see SSHCFG_ALL. In the case of Subsystem, it is SSHCFG_GLOBAL which means it is only supported in the global section. -- Iain Morgan From dtucker at zip.com.au Tue Dec 14 09:13:44 2010 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 14 Dec 2010 09:13:44 +1100 Subject: Should Subsystem work in a Match block? In-Reply-To: <4D066D67.1010507@fifthhorseman.net> References: <4D066D67.1010507@fifthhorseman.net> Message-ID: <4D069A98.60601@zip.com.au> On 14/12/10 6:00 AM, Daniel Kahn Gillmor wrote: > hi folks-- > > Can a Match block cover a Subsystem directive in sftp? > > https://bugzilla.mindrot.org/show_bug.cgi?id=1587#c1 > > suggests that Match can cover Subsystem, but sshd_config (at least, in > 5.5p1) doesn't mention Subsystem within the description of Match. Right now Subsystem is only allowed in global scope ie not in a Match block. We only implemented the things that had a plausible use case to keep the number of permutations down. Is there a plausible use case for this? > What should administrators expect? That the documentation is accurate :-) (and if it's not, that it's a reportable bug) -- 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 Tue Dec 14 09:21:29 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Mon, 13 Dec 2010 17:21:29 -0500 Subject: Should Subsystem work in a Match block? In-Reply-To: <4D069A98.60601@zip.com.au> References: <4D066D67.1010507@fifthhorseman.net> <4D069A98.60601@zip.com.au> Message-ID: <4D069C69.3010409@fifthhorseman.net> On 12/13/2010 05:13 PM, Darren Tucker wrote: > Right now Subsystem is only allowed in global scope ie not in a Match > block. > > We only implemented the things that had a plausible use case to keep the > number of permutations down. Is there a plausible use case for this? https://bugzilla.mindrot.org/show_bug.cgi?id=1587 suggests: Match Group nosftp Subsystem sftp /bin/false I started wondering about this thinking about how to support group SFTP access for a shared project, so marking certain users with something like: Subsystem sftp sftp-server -u 002 Maybe there's a preferred way to do something like this? > That the documentation is accurate :-) > (and if it's not, that it's a reportable bug) :) if the example in #1587 is wrong (and not expected to become right), maybe we should at least note it in that bug log (i know bug logs are not official documentation). Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From peter at stuge.se Tue Dec 14 09:32:14 2010 From: peter at stuge.se (Peter Stuge) Date: Mon, 13 Dec 2010 23:32:14 +0100 Subject: Problem of updating openssh-4.4p1 to openssh-5.5p1 with MAX_ALLOW_USERS option In-Reply-To: <20101213183124.GB6057@linux124.nas.nasa.gov> References: <379461291973588@web29.yandex.ru> <472441292023080@web22.yandex.ru> <20101213183124.GB6057@linux124.nas.nasa.gov> Message-ID: <20101213223214.5528.qmail@stuge.se> Iain Morgan wrote: > You could, for example, create a group that consists only of those > users that are allowed to login to the system. Or, it that is not > acceptable for some reason, you could create a number of groups. If it's an old kernel watch out for limits on the number of users that can be in each group. //Peter From dtucker at zip.com.au Tue Dec 14 12:30:41 2010 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 14 Dec 2010 12:30:41 +1100 Subject: Should Subsystem work in a Match block? In-Reply-To: <4D069A98.60601@zip.com.au> References: <4D066D67.1010507@fifthhorseman.net> <4D069A98.60601@zip.com.au> Message-ID: <4D06C8C1.6060603@zip.com.au> On 14/12/10 9:13 AM, Darren Tucker wrote: > On 14/12/10 6:00 AM, Daniel Kahn Gillmor wrote: >> Can a Match block cover a Subsystem directive in sftp? [...] > > Right now Subsystem is only allowed in global scope ie not in a Match > block. Also, since Subsystem is actually a list of name/executable pairs, it's not clear what the semantics of Match+Subsystem should be. Subsystem sftp foo Match User fred Subsystem sftp bar the intent here seems to be to replace the the "sftp" subsystem with "bar" for fred. Subsystem sftp foo Match User fred Subsystem bar baz The intent here isn't clear: is sftp supposed to work for fred or not? The way other list things work is that using "none" clears the list so something like this is feasible: Subsystem sftp foo Match User fred Subsystem none Subsystem bar baz although I suspect it's not obvious if you don't know the implementation. -- 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 robert at statelesssystems.com Tue Dec 14 17:31:49 2010 From: robert at statelesssystems.com (Robert Barnes) Date: Tue, 14 Dec 2010 17:31:49 +1100 Subject: Invite to Fundry.com Message-ID: Hi - I'm contacting you because I wanted to invite OpenSSH to join a new crowdfunding application we've just launched called Fundry.com. Fundry is designed around software projects, helping developers get paid for developing new features, and enabling your community to pledge to get the features they want. Win win. We hope that it will a lot more effective than simply having 'Donate' buttons. You can find out more about how it works here: http://fundry.com/about We just launched last week so are reaching out to a small group of open-source developers first before we approach the wider open-source community. Previous applications we've developed that you may have heard about include retailmenot, bugmenot, trendsmap, and CushyCMS. I hope you enjoy Fundry, and would be happy to help if you have any questions or feedback. Sincerely Robert Barnes Fundry From gert at greenie.muc.de Tue Dec 14 18:38:16 2010 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 14 Dec 2010 08:38:16 +0100 Subject: Problem of updating openssh-4.4p1 to openssh-5.5p1 with MAX_ALLOW_USERS option In-Reply-To: <20101213223214.5528.qmail@stuge.se> References: <379461291973588@web29.yandex.ru> <472441292023080@web22.yandex.ru> <20101213183124.GB6057@linux124.nas.nasa.gov> <20101213223214.5528.qmail@stuge.se> Message-ID: <20101214073815.GN12709@greenie.muc.de> Hi, On Mon, Dec 13, 2010 at 11:32:14PM +0100, Peter Stuge wrote: > Iain Morgan wrote: > > You could, for example, create a group that consists only of those > > users that are allowed to login to the system. Or, it that is not > > acceptable for some reason, you could create a number of groups. > > If it's an old kernel watch out for limits on the number of users > that can be in each group. There is no such limit. There is (used to be) a limit on the number of groups a given user can have (which makes sense, as *that* is stored in a struct of limited size). 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 akulov-aa at ya.ru Tue Dec 14 20:12:51 2010 From: akulov-aa at ya.ru (=?koi8-r?B?4cvVzM/XIOHMxcvTxco=?=) Date: Tue, 14 Dec 2010 12:12:51 +0300 Subject: Problem of updating openssh-4.4p1 to openssh-5.5p1 with MAX_ALLOW_USERS option In-Reply-To: <20101213183124.GB6057@linux124.nas.nasa.gov> References: <379461291973588@web29.yandex.ru> <472441292023080@web22.yandex.ru> <20101213183124.GB6057@linux124.nas.nasa.gov> Message-ID: <282201292317972@web80.yandex.ru> Hello, Iain. The most interesting fact is that openssh-5.5 had installed sucessfully (with large value of MAX_ALLOW_USERS defined), but at the connection any user can see the login prompt, but after entering the login ssh-terminal doesn't give a possibility to input password and exits with error. Also at this time in file /var/log/secure logs the following records: Dec 9 16:01:59 bankier3 sshd[3709]: fatal: mm_request_send: write: Broken pipe Dec 9 16:08:22 bankier3 sshd[14384]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8 Thanks. With best regards, Alex. 13.12.10, 21:31, "Iain Morgan" : On Fri, Dec 10, 2010 at 17:18:00 -0600, ?????? ??????? wrote: > Hello, Damien. > > I'm sory, may be I have told not exactly. > I understand, that defined variable MAX_ALLOW_USERS sets the maximum possible strings of "AllowUsers"-type in file "/etc/ssh/sshd_config". > In the version openssh-4.4p1 changing of this defined option makes possible to include big quality of "AllowUsers"-strings in file "/etc/ssh/sshd_config", but in the version openssh-5.5p1 this changes doesn't give similar results. > Tell me, please, why it may be occurs in version 5.5p1? > ? > Thanks. > Hello, So, to be clear, the issue is that you want to have a large number of AllowUser statements rather than the need for a large number of concurrent logins. In that case, I'm not sure why increasing these constants does not have the same effect as with OpenSSH 4.4. Having said that, there may be alternative solutions to your issue. AllowGroups might be a better solution than AllowUsers. You could, for example, create a group that consists only of those users that are allowed to login to the system. Or, it that is not acceptable for some reason, you could create a number of groups. Besides the limit on the number of entries, AllowUsers has the disadvantage that you must restart sshd whenever a user is added or removed from the list of allowed users. There are PAM-based solutions, such as pam_access, that provide similar functionality but do not require a restart of sshd. I believe that you indicated you are using RHEL, which includes pam_access, so you may want to take a look at it. From dan.colascione at gmail.com Wed Dec 15 10:32:58 2010 From: dan.colascione at gmail.com (Daniel Colascione) Date: Tue, 14 Dec 2010 15:32:58 -0800 Subject: Feature request: more information sent to ProxyCommand Message-ID: <4D07FEAA.1090604@gmail.com> I use ProxyCommand is connect to several servers, but the command executed doesn't know the difference between being called for ssh or scp; in the latter case, I'd like to set QoS bits so the traffic is flagged as bulk. Would it be possible to send additional information to the proxy command so it can make better decisions about how to relay its traffic? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From dkg at fifthhorseman.net Wed Dec 15 15:18:54 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 14 Dec 2010 23:18:54 -0500 Subject: Feature request: more information sent to ProxyCommand In-Reply-To: <4D07FEAA.1090604@gmail.com> References: <4D07FEAA.1090604@gmail.com> Message-ID: <4D0841AE.5040403@fifthhorseman.net> On 12/14/2010 06:32 PM, Daniel Colascione wrote: > I use ProxyCommand is connect to several servers, but the command > executed doesn't know the difference between being called for ssh or > scp; in the latter case, I'd like to set QoS bits so the traffic is > flagged as bulk. Would it be possible to send additional information to > the proxy command so it can make better decisions about how to relay its > traffic? I think this suggestion dovetails nicely with a feature request i opened several months ago: https://bugzilla.mindrot.org/show_bug.cgi?id=1766 Unfortunately, i haven't had a chance to implement it. If someone offers a patch, i'd be happy to review, test, and give feedback, though. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From dtucker at zip.com.au Wed Dec 15 18:57:03 2010 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 15 Dec 2010 18:57:03 +1100 Subject: Feature request: more information sent to ProxyCommand In-Reply-To: <4D0841AE.5040403@fifthhorseman.net> References: <4D07FEAA.1090604@gmail.com> <4D0841AE.5040403@fifthhorseman.net> Message-ID: <20101215075703.GA27157@gate.dtucker.net> On Tue, Dec 14, 2010 at 11:18:54PM -0500, Daniel Kahn Gillmor wrote: > On 12/14/2010 06:32 PM, Daniel Colascione wrote: > > I use ProxyCommand is connect to several servers, but the command > > executed doesn't know the difference between being called for ssh or > > scp; in the latter case, I'd like to set QoS bits so the traffic is > > flagged as bulk. Would it be possible to send additional information to > > the proxy command so it can make better decisions about how to relay its > > traffic? > > I think this suggestion dovetails nicely with a feature request i opened > several months ago: > > https://bugzilla.mindrot.org/show_bug.cgi?id=1766 > > Unfortunately, i haven't had a chance to implement it. If someone > offers a patch, i'd be happy to review, test, and give feedback, though. It's not as simple as it seems at first because currently ssh will change the qos based on SSH-protocol level things (eg "you've requested a pty or X11 forwarding) ssh doesn't know these things when the proxycommand is invoked. You could, however do an approximation. Here's a minimal implementation which uses %q to pass the (hex) qos to the proxycommand. Something like: Host foo ProxyCommand nc -T %q %h %p Expanding %q for ControlMaster is also potentially useful too (eg you could have one master for interactive sessions and one for copies) but this is not currently implemented. Index: readconf.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/readconf.h,v retrieving revision 1.88 diff -u -p -r1.88 readconf.h --- readconf.h 13 Nov 2010 23:27:50 -0000 1.88 +++ readconf.h 15 Dec 2010 05:47:19 -0000 @@ -61,6 +61,7 @@ typedef struct { int tcp_keep_alive; /* Set SO_KEEPALIVE. */ int ip_qos_interactive; /* IP ToS/DSCP/class for interactive */ int ip_qos_bulk; /* IP ToS/DSCP/class for bulk traffic */ + int ip_qos_effective; /* IP ToS/DSCP currently in use */ LogLevel log_level; /* Level for logging. */ int port; /* Port to connect. */ Index: ssh.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/ssh.c,v retrieving revision 1.355 diff -u -p -r1.355 ssh.c --- ssh.c 29 Nov 2010 23:45:51 -0000 1.355 +++ ssh.c 15 Dec 2010 07:48:49 -0000 @@ -678,6 +678,9 @@ main(int ac, char **av) options.port = sp ? ntohs(sp->s_port) : SSH_DEFAULT_PORT; } + options.ip_qos_effective = tty_flag ? options.ip_qos_interactive : + options.ip_qos_bulk; + if (options.hostname != NULL) { host = percent_expand(options.hostname, "h", host, (char *)NULL); Index: sshconnect.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/sshconnect.c,v retrieving revision 1.230 diff -u -p -r1.230 sshconnect.c --- sshconnect.c 14 Dec 2010 11:59:06 -0000 1.230 +++ sshconnect.c 15 Dec 2010 06:03:59 -0000 @@ -77,13 +77,14 @@ ssh_proxy_connect(const char *host, u_sh char *command_string, *tmp; int pin[2], pout[2]; pid_t pid; - char *shell, strport[NI_MAXSERV]; + char *shell, strport[NI_MAXSERV], strqos[16]; if ((shell = getenv("SHELL")) == NULL || *shell == '\0') shell = _PATH_BSHELL; - /* Convert the port number into a string. */ + /* Convert the port and qps number into a string. */ snprintf(strport, sizeof strport, "%hu", port); + snprintf(strqos, sizeof strqos, "0x%02x", options.ip_qos_effective); /* * Build the final command string in the buffer by making the @@ -94,7 +95,7 @@ ssh_proxy_connect(const char *host, u_sh */ xasprintf(&tmp, "exec %s", proxy_command); command_string = percent_expand(tmp, "h", host, "p", strport, - "r", options.user, (char *)NULL); + "r", options.user, "q", strqos, (char *)NULL); xfree(tmp); /* Create pipes for communicating with the proxy. */ -- 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 markdjones82 at gmail.com Thu Dec 16 01:42:37 2010 From: markdjones82 at gmail.com (mark Jones) Date: Wed, 15 Dec 2010 08:42:37 -0600 Subject: Building RPM for Openssh5.6p1 fails on RHEL 6.0 Message-ID: All, I am trying to build openssh-5.6p1 using the SPEC file on RHEL 6 and I am receiving this error: [root@**** SPECS]# rpmbuild -bb openssh.spec error: line 47: Unknown tag: Copyright : BSD Also, I read that the umask functionality in this one has issues. Does it work in the 5.5 source? Any help would be appreciated. From vdanen at redhat.com Thu Dec 16 02:19:46 2010 From: vdanen at redhat.com (Vincent Danen) Date: Wed, 15 Dec 2010 08:19:46 -0700 Subject: Building RPM for Openssh5.6p1 fails on RHEL 6.0 In-Reply-To: References: Message-ID: <20101215151946.GW17679@redhat.com> * [2010-12-15 08:42:37 -0600] mark Jones wrote: > I am trying to build openssh-5.6p1 using the SPEC file on RHEL 6 and I am >receiving this >error: > >[root@**** SPECS]# rpmbuild -bb openssh.spec >error: line 47: Unknown tag: Copyright : BSD That should be License, not Copyright. Is this spec file in the openssh tarball? If so, it should be updated as Copyright is really really old. >Also, > I read that the umask functionality in this one has issues. Does it >work in the 5.5 source? This I don't know. -- Vincent Danen / Red Hat Security Response Team From jrollins at finestructure.net Thu Dec 16 02:11:36 2010 From: jrollins at finestructure.net (Jameson Rollins) Date: Wed, 15 Dec 2010 10:11:36 -0500 Subject: Feature request: more information sent to ProxyCommand In-Reply-To: <20101215075703.GA27157@gate.dtucker.net> References: <4D07FEAA.1090604@gmail.com> <4D0841AE.5040403@fifthhorseman.net> <20101215075703.GA27157@gate.dtucker.net> Message-ID: <87oc8njck7.fsf@servo.finestructure.net> On Wed, 15 Dec 2010 18:57:03 +1100, Darren Tucker wrote: > It's not as simple as it seems at first because currently ssh will > change the qos based on SSH-protocol level things (eg "you've requested > a pty or X11 forwarding) ssh doesn't know these things when the > proxycommand is invoked. Really? I would have thought that ssh has already processed all the command line and config file options by the time it is launching the proxy command. If so, it seems like ssh *could* pass all of that information to the proxy command via the environment. jamie. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From kirkland at ubuntu.com Thu Dec 16 05:01:22 2010 From: kirkland at ubuntu.com (Dustin Kirkland) Date: Wed, 15 Dec 2010 12:01:22 -0600 Subject: ssh-import-id Message-ID: Howdy, We in the Ubuntu Server world have been using a handy little shell utility for a couple of releases now, called 'ssh-import-id' [1]. Whereas ssh-copy-id _pushes_ a public key from one system to another, ssh-import-id _pulls_ a public key from a secure key server and installs it. It takes one or more userid's as command line arguments, loops over them, sequentially attempts to retrieve public keys from a web api (using wget or curl), and can write to stdout or to file (~/.ssh/authorized_keys). We find this particularly handy in the cloud world, where systems are started from pristine images every time, and we need to a way to seed the system with credentials before the first authentication. Here, we can run something like 'ssh-import-id kirkland' during the boot process, and my public key will be installed by the time I log in. It's also really useful when and if you need to grant access to the system to others, or perhaps start a system in the cloud on behalf of someone else. Here, we can 'ssh-import-id kirkland smoser cjwatson', and each of these keys are retrieved and installed. We're using URL="https://launchpad.net/~%s/+sshkeys", where %s is a userid, but this URL could really be configurable and point to any public or private SSH public key server. An SSL connection to a https site with a valid certificate is, of course, essential to the security of the key retrieval. If there were a free/public SSH key server like pgp.mit.edu for PGP/GPG keys, that would probably make a good default (thought I haven't found anything like this). Seeing the ssh-copy-id utility in SSH's contrib/ directory, I'm hopeful you might consider this ssh-import-id tool for the project. Before we get into reviewing the code, can you tell me if this is something that would, or would not be interesting to openssh upstream? -- :-Dustin Dustin Kirkland Ubuntu Core Developer From alex at alex.org.uk Thu Dec 16 05:48:21 2010 From: alex at alex.org.uk (Alex Bligh) Date: Wed, 15 Dec 2010 18:48:21 +0000 Subject: ssh-import-id In-Reply-To: References: Message-ID: <636FCC32A77B50194EA244C7@nimrod.local> --On 15 December 2010 12:01:22 -0600 Dustin Kirkland wrote: > Seeing the ssh-copy-id utility in SSH's contrib/ directory, I'm > hopeful you might consider this ssh-import-id tool for the project. > Before we get into reviewing the code, can you tell me if this is > something that would, or would not be interesting to openssh upstream? We'd use this if it took a username too, for a similar purpose. Currently we pull keys out of xml and go through some convoluted perl to add them to the right authorized_keys file of the right users, set the permissions and ownerships right, etc., which is pretty fiddly, and not that safe when someone next changes the desired permissions on authorized_keys, or uses a different path specified by the config file, or whatever. -- Alex Bligh From joachim at joachimschipper.nl Thu Dec 16 06:07:39 2010 From: joachim at joachimschipper.nl (Joachim Schipper) Date: Wed, 15 Dec 2010 20:07:39 +0100 Subject: ssh-import-id In-Reply-To: References: Message-ID: <20101215190738.GB8153@polymnia.joachimschipper.nl> On Wed, Dec 15, 2010 at 12:01:22PM -0600, Dustin Kirkland wrote: > Howdy, > > We in the Ubuntu Server world have been using a handy little shell > utility for a couple of releases now, called 'ssh-import-id' [1]. > > Whereas ssh-copy-id _pushes_ a public key from one system to another, > ssh-import-id _pulls_ a public key from a secure key server and > installs it. > > It takes one or more userid's as command line arguments, loops over > them, sequentially attempts to retrieve public keys from a web api > (using wget or curl), and can write to stdout or to file > (~/.ssh/authorized_keys). > > We find this particularly handy in the cloud world, where systems are > started from pristine images every time, and we need to a way to seed > the system with credentials before the first authentication. Here, we > can run something like 'ssh-import-id kirkland' during the boot > process, and my public key will be installed by the time I log in. > > It's also really useful when and if you need to grant access to the > system to others, or perhaps start a system in the cloud on behalf of > someone else. Here, we can 'ssh-import-id kirkland smoser cjwatson', > and each of these keys are retrieved and installed. > > We're using URL="https://launchpad.net/~%s/+sshkeys", where %s is a > userid, but this URL could really be configurable and point to any > public or private SSH public key server. An SSL connection to a https > site with a valid certificate is, of course, essential to the security > of the key retrieval. If there were a free/public SSH key server like > pgp.mit.edu for PGP/GPG keys, that would probably make a good default > (thought I haven't found anything like this). > > Seeing the ssh-copy-id utility in SSH's contrib/ directory, I'm > hopeful you might consider this ssh-import-id tool for the project. > Before we get into reviewing the code, can you tell me if this is > something that would, or would not be interesting to openssh upstream? I'm not an OpenSSH developer, but: why not use SSH? Install *one* server's key, and pull the users' keys over that connection. This seems to have quite a few less moving parts, avoids a dependency on wget/libcurl/..., and doesn't crash and burn when another CA signs something it shouldn't. Joachim From dkg at fifthhorseman.net Thu Dec 16 06:27:39 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 15 Dec 2010 14:27:39 -0500 Subject: ssh-import-id In-Reply-To: References: Message-ID: <4D0916AB.8090107@fifthhorseman.net> On 12/15/2010 01:01 PM, Dustin Kirkland wrote: > If there were a free/public SSH key server like > pgp.mit.edu for PGP/GPG keys, that would probably make a good default > (thought I haven't found anything like this). You could use monkeysphere [0] on these hosts and use the HKP keyserver network (what i think you're referring to by pgp.mit.edu, above, though i recommend *not* using pgp.mit.edu until they fix their keyserver). If you know that your users' OpenPGP keys are going to all be signed by, say, your own OpenPGP key which has a fingerprint of $CA_FPR, you could put something like this in your preseed's late_command : aptitude install monkeysphere openssh-server monkeysphere-authentication add-identity-certifier "$CA_FPR" mkdir ~mary/.monkeysphere echo 'Mary Example ' >> \ ~mary/.monkeysphere/authorized_user_ids monkeysphere-authentication update-users echo 'AuthorizedKeysFile /var/lib/monkeysphere/authorized_keys/%u' \ >> /etc/ssh/sshd_config /etc/init.d/ssh restart This also has the advantage that future runs of monkeysphere-authentication update-users will cause revoked keys to be disabled without any additional work from the user. hope this is useful. i'm one of the monkeysphere developers; feel free to come ask questions on the project mailing list, or in #monkeysphere on irc.oftc.net. Regards, --dkg [0] http://web.monkeysphere.info -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From kirkland at ubuntu.com Thu Dec 16 06:37:10 2010 From: kirkland at ubuntu.com (Dustin Kirkland) Date: Wed, 15 Dec 2010 13:37:10 -0600 Subject: ssh-import-id In-Reply-To: <636FCC32A77B50194EA244C7@nimrod.local> References: <636FCC32A77B50194EA244C7@nimrod.local> Message-ID: On Wed, Dec 15, 2010 at 12:48 PM, Alex Bligh wrote: > --On 15 December 2010 12:01:22 -0600 Dustin Kirkland > wrote: > >> Seeing the ssh-copy-id utility in SSH's contrib/ directory, I'm >> hopeful you might consider this ssh-import-id tool for the project. >> Before we get into reviewing the code, can you tell me if this is >> something that would, or would not be interesting to openssh upstream? > > We'd use this if it took a username too, for a similar purpose. Currently > we pull keys out of xml and go through some convoluted perl to add them > to the right authorized_keys file of the right users, set the permissions > and ownerships right, etc., which is pretty fiddly, and not that safe when > someone next changes the desired permissions on authorized_keys, or uses > a different path specified by the config file, or whatever. Hi Alex, Right now, it works as the current user, on the current user's ~/.ssh/authorized_keys file. I'd use sudo and su to run ssh-import-id as another user, to operate on their authorized_keys file. -- :-Dustin Dustin Kirkland Ubuntu Core Developer From kirkland at ubuntu.com Thu Dec 16 06:44:18 2010 From: kirkland at ubuntu.com (Dustin Kirkland) Date: Wed, 15 Dec 2010 13:44:18 -0600 Subject: ssh-import-id In-Reply-To: <20101215190738.GB8153@polymnia.joachimschipper.nl> References: <20101215190738.GB8153@polymnia.joachimschipper.nl> Message-ID: On Wed, Dec 15, 2010 at 1:07 PM, Joachim Schipper wrote: > On Wed, Dec 15, 2010 at 12:01:22PM -0600, Dustin Kirkland wrote: >> Howdy, >> >> We in the Ubuntu Server world have been using a handy little shell >> utility for a couple of releases now, called 'ssh-import-id' [1]. >> >> Whereas ssh-copy-id _pushes_ a public key from one system to another, >> ssh-import-id _pulls_ a public key from a secure key server and >> installs it. >> >> It takes one or more userid's as command line arguments, loops over >> them, sequentially attempts to retrieve public keys from a web api >> (using wget or curl), and can write to stdout or to file >> (~/.ssh/authorized_keys). >> >> We find this particularly handy in the cloud world, where systems are >> started from pristine images every time, and we need to a way to seed >> the system with credentials before the first authentication. ?Here, we >> can run something like 'ssh-import-id kirkland' during the boot >> process, and my public key will be installed by the time I log in. >> >> It's also really useful when and if you need to grant access to the >> system to others, or perhaps start a system in the cloud on behalf of >> someone else. ?Here, we can 'ssh-import-id kirkland smoser cjwatson', >> and each of these keys are retrieved and installed. >> >> We're using URL="https://launchpad.net/~%s/+sshkeys", where %s is a >> userid, but this URL could really be configurable and point to any >> public or private SSH public key server. ?An SSL connection to a https >> site with a valid certificate is, of course, essential to the security >> of the key retrieval. ?If there were a free/public SSH key server like >> pgp.mit.edu for PGP/GPG keys, that would probably make a good default >> (thought I haven't found anything like this). >> >> Seeing the ssh-copy-id utility in SSH's contrib/ directory, I'm >> hopeful you might consider this ssh-import-id tool for the project. >> Before we get into reviewing the code, can you tell me if this is >> something that would, or would not be interesting to openssh upstream? > > I'm not an OpenSSH developer, but: why not use SSH? Install *one* > server's key, and pull the users' keys over that connection. This seems > to have quite a few less moving parts, avoids a dependency on > wget/libcurl/..., and doesn't crash and burn when another CA signs > something it shouldn't. Hi Joachim, It's a bootstrapping issue. How do you get that "one" server's key there? If you can retrieve a key securely over https from a trusted server with a valid SSL certificate, you could put something like this your unattended boot scripts: wget -O- https://example.com/~username/pub_ssh_key >> /home/username/.ssh/authorized_keys ssh-import-id is a wrapper around that wget above, with better error handling, key sanitation, etc. -- :-Dustin Dustin Kirkland Ubuntu Core Developer From kirkland at ubuntu.com Thu Dec 16 06:52:09 2010 From: kirkland at ubuntu.com (Dustin Kirkland) Date: Wed, 15 Dec 2010 13:52:09 -0600 Subject: ssh-import-id In-Reply-To: <4D0916AB.8090107@fifthhorseman.net> References: <4D0916AB.8090107@fifthhorseman.net> Message-ID: On Wed, Dec 15, 2010 at 1:27 PM, Daniel Kahn Gillmor wrote: > On 12/15/2010 01:01 PM, Dustin Kirkland wrote: >> If there were a free/public SSH key server like >> pgp.mit.edu for PGP/GPG keys, that would probably make a good default >> (thought I haven't found anything like this). > > You could use monkeysphere [0] on these hosts and use the HKP keyserver > network (what i think you're referring to by pgp.mit.edu, above, though > i recommend *not* using pgp.mit.edu until they fix their keyserver). Hi Daniel, Right, I simply meant that I wasn't aware of any HKP keyserver network specifically for public SSH keys. > If you know that your users' OpenPGP keys are going to all be signed by, > say, your own OpenPGP key which has a fingerprint of $CA_FPR, you could > put something like this in your preseed's late_command : > > ?aptitude install monkeysphere openssh-server > ?monkeysphere-authentication add-identity-certifier "$CA_FPR" > ?mkdir ~mary/.monkeysphere > ?echo 'Mary Example ' >> \ > ? ?~mary/.monkeysphere/authorized_user_ids > > ?monkeysphere-authentication update-users > ?echo 'AuthorizedKeysFile /var/lib/monkeysphere/authorized_keys/%u' \ > ? ? >> /etc/ssh/sshd_config > ?/etc/init.d/ssh restart > > This also has the advantage that future runs of > > ?monkeysphere-authentication update-users > > will cause revoked keys to be disabled without any additional work from > the user. > > hope this is useful. ?i'm one of the monkeysphere developers; feel free > to come ask questions on the project mailing list, or in #monkeysphere > on irc.oftc.net. Thanks for the pointers. I'll give monkeysphere a try. Still, it's not quite addressing the problem I think ssh-import-id solves for us -- dead simple, fast, secure retrieval of a public SSH keys by nothing more than a user name inserted into a URL. -- :-Dustin Dustin Kirkland Ubuntu Core Developer From dkg at fifthhorseman.net Thu Dec 16 07:42:41 2010 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 15 Dec 2010 15:42:41 -0500 Subject: ssh-import-id In-Reply-To: References: <4D0916AB.8090107@fifthhorseman.net> Message-ID: <4D092841.7080301@fifthhorseman.net> On 12/15/2010 02:52 PM, Dustin Kirkland wrote: > Right, I simply meant that I wasn't aware of any HKP keyserver network > specifically for public SSH keys. The trouble, as you say, is that you need some sort of cryptographic authentication that the key really does belong to the person in question. So you're left with a choice of either: a) running a single centrally-administered key distribution service (so you can verify the transport itself), or b) using a distributed keyserver network that handles material with cryptographic identity information directly attached (so you can verify the material that potentially-untrustworthy keyservers give you). The existing HKP keyserver network already supports SSH keys (ssh host keys as well as users), making it a reasonable candidate for (b) if that's the direction you want to go. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 900 bytes Desc: OpenPGP digital signature URL: From jrollins at finestructure.net Thu Dec 16 07:01:42 2010 From: jrollins at finestructure.net (Jameson Rollins) Date: Wed, 15 Dec 2010 15:01:42 -0500 Subject: ssh-import-id In-Reply-To: References: <4D0916AB.8090107@fifthhorseman.net> Message-ID: <87wrnaiz4p.fsf@servo.finestructure.net> On Wed, 15 Dec 2010 13:52:09 -0600, Dustin Kirkland wrote: > Still, it's not quite addressing the problem I think ssh-import-id > solves for us -- dead simple, fast, secure retrieval of a public SSH > keys by nothing more than a user name inserted into a URL. This is pretty much what monkeysphere-authentication does as well. The hard part is really not retrieval of the keys, it's how to distribute them. Using the OpenPGP keyservers leverages a robust PKI that already exists, rather than reinventing the wheel. jamie. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From alex at alex.org.uk Thu Dec 16 12:25:44 2010 From: alex at alex.org.uk (Alex Bligh) Date: Thu, 16 Dec 2010 01:25:44 +0000 Subject: ssh-import-id In-Reply-To: References: <636FCC32A77B50194EA244C7@nimrod.local> Message-ID: --On 15 December 2010 13:37:10 -0600 Dustin Kirkland wrote: > Right now, it works as the current user, on the current user's > ~/.ssh/authorized_keys file. > > I'd use sudo and su to run ssh-import-id as another user, to operate > on their authorized_keys file. Sure it's possible (hell, it's possible to do the entire thing in perl as we have demonstrated) but addition of a -u flag for root use would save a whole pile of hassle. -- Alex Bligh From candland at xmission.com Thu Dec 16 07:52:04 2010 From: candland at xmission.com (Rob C) Date: Wed, 15 Dec 2010 13:52:04 -0700 Subject: Building RPM for Openssh5.6p1 fails on RHEL 6.0 In-Reply-To: References: Message-ID: <20101215205204.GA14021@shell.xmission.com> On Thu, Dec 16, 2010 at 01:43:25AM +1100, mark jones wrote: > All, > I am trying to build openssh-5.6p1 using the SPEC file on RHEL 6 and I am > receiving this > error: > > [root@**** SPECS]# rpmbuild -bb openssh.spec > error: line 47: Unknown tag: Copyright : BSD > Also, > I read that the umask functionality in this one has issues. Does it > work in the 5.5 source? > Any help would be appreciated. The umask functionality in sftp-server.c ver 5.5 will not work as expected due to the -u argument being parsed as decimal. The fix (which will likely be in the next version) uses: mask = strtol(optarg, &cp, 8); where the 5.5 and 5.6 (and earlier) code incorrectly uses: mask = (mode_t)strtonum(optarg, 0, 0777, &errmsg); However, due to the "put -p" option in the sftp client, the sftp-server has to honor permissions (within reason) sent from the client. This is a nice feature if your users want to control permissions on files they upload. For me, it's not so great as I want to control permissions of a file received via sftp-server and the umask option does not provide sufficient fine-grained control of file permissions. (Understandably so.) The bottom line is that the fixed "-u " will do exactly what it is supposed to do - masks permission bits, you just can't count on what bits it will mask. End thread drift, hope this helps, -Rob Candland From peter at stuge.se Thu Dec 16 15:10:33 2010 From: peter at stuge.se (Peter Stuge) Date: Thu, 16 Dec 2010 05:10:33 +0100 Subject: Building RPM for Openssh5.6p1 fails on RHEL 6.0 In-Reply-To: <20101215205204.GA14021@shell.xmission.com> References: <20101215205204.GA14021@shell.xmission.com> Message-ID: <20101216041033.31574.qmail@stuge.se> Rob C wrote: > The umask functionality in sftp-server.c ver 5.5 will not work as > expected due to the -u argument being parsed as decimal. The fix (which > will likely be in the next version) uses: > mask = strtol(optarg, &cp, 8); I'd suggest setting 0 for the base, so that the standard way of parsing umask is used. (Ie. leading 0 means octal.) > For me, it's not so great as I want to control permissions of a file > received via sftp-server and the umask option does not provide > sufficient fine-grained control of file permissions. > (Understandably so.) Maybe use an ACL (if only for now). > The bottom line is that the fixed "-u " will do exactly what it > is supposed to do - masks permission bits, you just can't count on what > bits it will mask. $ echo $[022] 18 //Peter From peter at stuge.se Thu Dec 16 15:25:59 2010 From: peter at stuge.se (Peter Stuge) Date: Thu, 16 Dec 2010 05:25:59 +0100 Subject: ssh-import-id In-Reply-To: References: <20101215190738.GB8153@polymnia.joachimschipper.nl> Message-ID: <20101216042559.1565.qmail@stuge.se> Dustin Kirkland wrote: > > why not use SSH? Install *one* server's key, and pull the users' > > keys over that connection. .. > It's a bootstrapping issue. How do you get that "one" server's key > there? Same way you get the command in the boot script there. How do you do that by the way? I assume Ubuntu server .isos do not come with ssh-import-id kirkland in them. ;) //Peter From atul14.kumar at gmail.com Thu Dec 16 15:30:37 2010 From: atul14.kumar at gmail.com (Atul Gupta) Date: Wed, 15 Dec 2010 23:30:37 -0500 Subject: [Question]pam_radius_auth.so logging Message-ID: Hi, I am using pam_radius_auth.so to authenticate ssh sessions on my linux based box. I want to know on which file all the logs from radius go. some where i found that logs go in /var/log/auth.log, but i could not find any radius related logs there. Please help!! Regards, Atul. From kirkland at ubuntu.com Fri Dec 17 01:07:03 2010 From: kirkland at ubuntu.com (Dustin Kirkland) Date: Thu, 16 Dec 2010 08:07:03 -0600 Subject: ssh-import-id In-Reply-To: References: <636FCC32A77B50194EA244C7@nimrod.local> Message-ID: On Wed, Dec 15, 2010 at 7:25 PM, Alex Bligh wrote: > > > --On 15 December 2010 13:37:10 -0600 Dustin Kirkland > wrote: > >> Right now, it works as the current user, on the current user's >> ~/.ssh/authorized_keys file. >> >> I'd use sudo and su to run ssh-import-id as another user, to operate >> on their authorized_keys file. > > Sure it's possible (hell, it's possible to do the entire thing in > perl as we have demonstrated) but addition of a -u flag for root use > would save a whole pile of hassle. Fair enough ;-) If that's a blocker to getting this tool upstream into openssh, I'll gladly add a -u option. :-Dustin From alex at alex.org.uk Fri Dec 17 01:21:26 2010 From: alex at alex.org.uk (Alex Bligh) Date: Thu, 16 Dec 2010 14:21:26 +0000 Subject: ssh-import-id In-Reply-To: References: <636FCC32A77B50194EA244C7@nimrod.local> Message-ID: <74784B1598BF957048B32C9E@nimrod.local> --On 16 December 2010 08:07:03 -0600 Dustin Kirkland wrote: > If that's a blocker to getting this tool upstream into openssh, I'll > gladly add a -u option. To be clear, I have no commit rights and am a mere user, so am not in a position to say it's a blocker. I'm just saying the more widely useful it is, the better, and we'd need that for it to be useful. Out of interest, in Scott's cloud-init stuff, I am pretty sure you populate the ssh key for the ubuntu user whereas the script in cloudinit runs as root. Does that mean you currently do: su ubuntu ssh-import-id keyfile or similar. -- Alex Bligh From phil at hands.com Fri Dec 17 01:54:11 2010 From: phil at hands.com (Philip Hands) Date: Thu, 16 Dec 2010 14:54:11 +0000 Subject: ssh-copy-id Message-ID: <87y67pg44s.fsf@poker.hands.com> Hi Folks, Prompted by this talk of ssh-import-id, I am reminded that Eric Moret and I have collaborating on a new version of ssh-copy-id, available here: http://git.hands.com/ssh-copy-id Recently, Eric and I have been taking turns to be too busy to test the very latest stuff (mostly my fault), but I think it's now pretty much ready for a wider public, and if it's not your howls of protest seem much more likely to galvanise me into action than waiting for a gap in my diary. So, perhaps people will grab a copy and try it out, and tell me how they get on with it. ssh-copy-id has been allowed to go a bit rusty over the years since I first published it, so it would be nice to get a slightly better version into OpenSSH. Hopefully this one is not too far from the simple shell script that we started out with, and so will be portable and understandable enough to allow it to be adopted -- I know that an earlier attempt to replace ssh-copy-id got bogged down in featuritis, so I've tried to mostly avoid that -- using (hopefully portable) shell helps one resist adding too many features. ;-) Bug reports, patches, and general abuse welcomed with open arms :-) Cheers, Phil. P.S. I've attempted to track down all the people that contributed code to ssh-copy-id, and credit them -- please tell me if I've forgotten anyone. I have also have added a minimal license statement that hopefully reflects the intent of those authors. I'm open to persuasion that more is required, but you'll need to be very convincing, given that the only license wording I'm aware of being previously applied to ssh-copy-id would be the stuff I put in the Debian package about the packaging scripts (which is where ssh-copy-id started out) being under the GPL -- obviously, I didn't think then, and don't think now that it would be a good idea to throw a spanner in the works by declaring that ssh-copy-id is really under the GPL, so I thought I'd better make it explicit that the conditions were at least as liberal as a BSD license. I don't think there's much worth to language mentioning binary form for a shell script, which is why I left most of the BSD license out. -- |)| Philip Hands [+44 (0)20 8530 9560] http://www.hands.com/ |-| HANDS.COM Ltd. http://www.uk.debian.org/ |(| 10 Onslow Gardens, South Woodford, London E18 1NE ENGLAND -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 835 bytes Desc: not available URL: From smoser at ubuntu.com Fri Dec 17 05:36:34 2010 From: smoser at ubuntu.com (Scott Moser) Date: Thu, 16 Dec 2010 13:36:34 -0500 (EST) Subject: ssh-import-id In-Reply-To: <74784B1598BF957048B32C9E@nimrod.local> References: <636FCC32A77B50194EA244C7@nimrod.local> <74784B1598BF957048B32C9E@nimrod.local> Message-ID: On Thu, 16 Dec 2010, Alex Bligh wrote: > > > --On 16 December 2010 08:07:03 -0600 Dustin Kirkland > wrote: > > > If that's a blocker to getting this tool upstream into openssh, I'll > > gladly add a -u option. > > To be clear, I have no commit rights and am a mere user, so am not > in a position to say it's a blocker. I'm just saying the more widely > useful it is, the better, and we'd need that for it to be useful. > > Out of interest, in Scott's cloud-init stuff, I am pretty sure you > populate the ssh key for the ubuntu user whereas the script in > cloudinit runs as root. Does that mean you currently do: > su ubuntu ssh-import-id keyfile > or similar. Well, cloud-init has built in code that takes a authorized key from a metadata service and install that into a configured user's directory. (On ec2 it comes from http:// http://169.254.169.254/latest/metadata/public-keys). If you have additional keys that you need inserted, or you'd rather just not deal with launching instances with '--key ', then you can use "user-data" in ec2 to run a script that would include something like: #!/bin/sh sudo -Hu ubuntu ssh-import-id smoser I personally don't use the user data for this that much, but I do quite often use ssh-import-id to pull in another developers keys to an existing instance to show them something (ie failure/bug or just to share the resource with them). I agree that the following is possibly simpler: ssh-import-id -u ubuntu smoser But I really don't think terribly so. Also, I had a merge request that will dump the keys to a file or stdout also, rather than writing them to $HOME/.ssh/authorized_keys. Scott From smoser at ubuntu.com Fri Dec 17 05:44:53 2010 From: smoser at ubuntu.com (Scott Moser) Date: Thu, 16 Dec 2010 13:44:53 -0500 (EST) Subject: ssh-import-id In-Reply-To: <20101216042559.1565.qmail@stuge.se> References: <20101215190738.GB8153@polymnia.joachimschipper.nl> <20101216042559.1565.qmail@stuge.se> Message-ID: On Thu, 16 Dec 2010, Peter Stuge wrote: > Dustin Kirkland wrote: > > > why not use SSH? Install *one* server's key, and pull the users' > > > keys over that connection. > .. > > It's a bootstrapping issue. How do you get that "one" server's key > > there? > > Same way you get the command in the boot script there. > > How do you do that by the way? I assume Ubuntu server .isos do not > come with ssh-import-id kirkland in them. ;) I think that its hard to argue that getting your ssh keys to a server is not easier by - logging into a system at the console, and then typing: - ssh-import-id smoser than - logging into a system at the console, and then typing: - plugging a USB key in, copying a .ssh key file off ~/.ssh/authorized_keys and getting perms right ... (I guess some more elite than me might be able to type theirs from memory.) The thing that might be arguable is the trust in the system (depending on https and networking and launchpad ... ). And I think that is being argued also on this thread. Trust aside, I personally find the utility very useful, as I would one based on monkeysphere also. Scott From joachim at joachimschipper.nl Fri Dec 17 21:56:10 2010 From: joachim at joachimschipper.nl (Joachim Schipper) Date: Fri, 17 Dec 2010 11:56:10 +0100 Subject: ssh-import-id In-Reply-To: References: <20101215190738.GB8153@polymnia.joachimschipper.nl> <20101216042559.1565.qmail@stuge.se> Message-ID: <20101217105609.GB14182@polymnia.joachimschipper.nl> On Thu, Dec 16, 2010 at 01:44:53PM -0500, Scott Moser wrote: > On Thu, 16 Dec 2010, Peter Stuge wrote: > > Dustin Kirkland wrote: > > > Joachim Schipper wrote: > > > > why not use SSH? Install *one* server's key, and pull the users' > > > > keys over that connection. > > > It's a bootstrapping issue. How do you get that "one" server's key > > > there? > > Same way you get the command in the boot script there. > > > > How do you do that by the way? I assume Ubuntu server .isos do not > > come with ssh-import-id kirkland in them. ;) > I think that its hard to argue that getting your ssh keys to a server is > not easier by > - logging into a system at the console, and then typing: > - ssh-import-id smoser So where did ssh-import-id come from? > than > - logging into a system at the console, and then typing: > - plugging a USB key in, copying a .ssh key file off > ~/.ssh/authorized_keys and getting perms right ... > (I guess some more elite than me might be able to type theirs from > memory.) Just add the key to the base .iso. Joachim From amintab2001 at gmail.com Sat Dec 18 01:27:26 2010 From: amintab2001 at gmail.com (amin tabrizi) Date: Fri, 17 Dec 2010 17:57:26 +0330 Subject: how to us Message-ID: hi how to us ssh for proxy site ? From raubvogel at gmail.com Sat Dec 18 01:58:04 2010 From: raubvogel at gmail.com (Mauricio Tavares) Date: Fri, 17 Dec 2010 09:58:04 -0500 Subject: how to us In-Reply-To: References: Message-ID: <4D0B7A7C.9010209@gmail.com> On 12/17/2010 09:27 AM, amin tabrizi wrote: > hi how to us ssh for proxy site ? What do you mean? Maybe you could draw an ASCII diagram of what you are trying to do or something. From aris at 0xbadc0de.be Sat Dec 18 02:34:35 2010 From: aris at 0xbadc0de.be (Aris Adamantiadis) Date: Fri, 17 Dec 2010 16:34:35 +0100 Subject: how to us In-Reply-To: References: Message-ID: <4D0B830B.8060504@0xbadc0de.be> Le 17/12/10 15:27, amin tabrizi a ?crit : > hi how to us ssh for proxy site ? http://www.lmgt4u.com/?q=ssh+proxy From jari.aalto at cante.net Wed Dec 22 00:08:52 2010 From: jari.aalto at cante.net (Jari Aalto) Date: Tue, 21 Dec 2010 15:08:52 +0200 Subject: wishlist: [PATCH] sshd_config - reformat for easier reading Message-ID: <87ipynw9wb.fsf@picasso.cante.net> The following patch reformats sshd_config in sections. - Add section breaks to help finding visual cues. - Indent standard text to column 8 (position of tab) and leave configuration examples to the left. - Add new example: how to restrict root login only inside local LAN. Hope you find the changes helpful. The patch is against: CVS anoncvs at anoncvs.mindrot.org:/cvs 2010-12-21 12:59 UTC Files: 1. Patch 2. Plain text sshd_config (as it would appear after patch) Jari -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-sshd_config-Reformat-configuration-in-sections.patch Type: text/x-diff Size: 7078 bytes Desc: not available URL: From jari.aalto at cante.net Wed Dec 22 08:17:11 2010 From: jari.aalto at cante.net (Jari Aalto) Date: Tue, 21 Dec 2010 23:17:11 +0200 Subject: wishlist: [PATCH] sshd_config - reformat for easier reading Message-ID: <87bp4ex1uw.fsf@picasso.cante.net> The following patch reformats sshd_config in sections. - Add section breaks to help finding visual cues. - Indent standard text to column 8 (position of tab) and leave configuration examples to the left. - Add new example: how to restrict root login only inside local LAN. Hope you find the changes helpful. The patch is against: CVS anoncvs at anoncvs.mindrot.org:/cvs 2010-12-21 12:59 UTC Files: 1. Patch 2. Plain text sshd_config (as it would appear after patch) Jari -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-sshd_config-Reformat-configuration-in-sections.patch Type: text/x-diff Size: 7078 bytes Desc: not available URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sshd_config URL: From clausen at econ.upenn.edu Tue Dec 28 06:11:42 2010 From: clausen at econ.upenn.edu (Andrew Clausen) Date: Mon, 27 Dec 2010 14:11:42 -0500 Subject: openssh and keystroke timing attacks (again) Message-ID: Hi all, Over the past 10 years, there has been some discussion and several patches concerning keystroke timing being revealed by the timing of openssh packet network transmission. The issue is that keystroke timing is correlated with the plaintext, and openssh users expect their communications to be kept entirely secret. Despite some excellent ideas and patches, such as Jason Coit's http://marc.info/?l=openssh-unix-dev&m=100326089315915&w=2 there has been little done to address this problem. As far as I can tell, the only countermeasure implemented in OpenSSH is that the server will echo back dummy messages (rather than nothing) when users enter passwords. But users expect all of their communication to be secret... not just their passwords! (There is no project called "SecurePasswordShell"!) I think Jason's approach is spot on: * keystrokes should be only sent at predetermined intervals (eg: every 50ms, or 20 times a second) * cover traffic at these fixed transmission times should be sent even if no keystroke is pressed. This can be turned off whenever a user is idle for 3 seconds. The security of Jason's proposal is clear: no information is leaked, except the timing of when the user starts and stops a typing spurt. This is because the same traffic pattern is created, regardless of the timing of the keystrokes. Why is this feature not available in OpenSSH? Jason's patch is almost 10 years old and doesn't apply to modern OpenSSH. If I cleaned it up, would it be seriously considered for inclusion in a future release? Cheers, Andrew From dan at doxpara.com Tue Dec 28 08:26:28 2010 From: dan at doxpara.com (Dan Kaminsky) Date: Mon, 27 Dec 2010 22:26:28 +0100 Subject: openssh and keystroke timing attacks (again) In-Reply-To: References: Message-ID: <3FB0A2E9-73AB-4FA6-A6CB-3A73B56F53E3@doxpara.com> Isn't it difficult to predict the size of a legitimate response to a keystroke? Just because you send a dummy response doesn't mean you got the size right. If you don't get the size right it's easy to differentiate wheat from chaff. Sent from my iPhone On Dec 27, 2010, at 8:11 PM, Andrew Clausen wrote: > Hi all, > > Over the past 10 years, there has been some discussion and several > patches concerning keystroke timing being revealed by the timing of > openssh packet network transmission. The issue is that keystroke > timing is correlated with the plaintext, and openssh users expect > their communications to be kept entirely secret. > > Despite some excellent ideas and patches, such as Jason Coit's > > http://marc.info/?l=openssh-unix-dev&m=100326089315915&w=2 > > there has been little done to address this problem. As far as I can > tell, the only countermeasure implemented in OpenSSH is that the > server will echo back dummy messages (rather than nothing) when users > enter passwords. But users expect all of their communication to be > secret... not just their passwords! (There is no project called > "SecurePasswordShell"!) > > I think Jason's approach is spot on: > * keystrokes should be only sent at predetermined intervals (eg: > every 50ms, or 20 times a second) > * cover traffic at these fixed transmission times should be sent even > if no keystroke is pressed. This can be turned off whenever a user is > idle for 3 seconds. > > The security of Jason's proposal is clear: no information is leaked, > except the timing of when the user starts and stops a typing spurt. > This is because the same traffic pattern is created, regardless of the > timing of the keystrokes. > > Why is this feature not available in OpenSSH? Jason's patch is almost > 10 years old and doesn't apply to modern OpenSSH. If I cleaned it up, > would it be seriously considered for inclusion in a future release? > > Cheers, > Andrew > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From djm at mindrot.org Tue Dec 28 09:06:49 2010 From: djm at mindrot.org (Damien Miller) Date: Tue, 28 Dec 2010 09:06:49 +1100 (EST) Subject: openssh and keystroke timing attacks (again) In-Reply-To: References: Message-ID: I'd like to have better keystroke timing countermeasures in OpenSSH, but they are just too intrusive under the current mainloop design. I'd like to renovate the mainloop some time and this would make implementing things like this quite a bit more easy. -d On Mon, 27 Dec 2010, Andrew Clausen wrote: > Hi all, > > Over the past 10 years, there has been some discussion and several > patches concerning keystroke timing being revealed by the timing of > openssh packet network transmission. The issue is that keystroke > timing is correlated with the plaintext, and openssh users expect > their communications to be kept entirely secret. > > Despite some excellent ideas and patches, such as Jason Coit's > > http://marc.info/?l=openssh-unix-dev&m=100326089315915&w=2 > > there has been little done to address this problem. As far as I can > tell, the only countermeasure implemented in OpenSSH is that the > server will echo back dummy messages (rather than nothing) when users > enter passwords. But users expect all of their communication to be > secret... not just their passwords! (There is no project called > "SecurePasswordShell"!) > > I think Jason's approach is spot on: > * keystrokes should be only sent at predetermined intervals (eg: > every 50ms, or 20 times a second) > * cover traffic at these fixed transmission times should be sent even > if no keystroke is pressed. This can be turned off whenever a user is > idle for 3 seconds. > > The security of Jason's proposal is clear: no information is leaked, > except the timing of when the user starts and stops a typing spurt. > This is because the same traffic pattern is created, regardless of the > timing of the keystrokes. > > Why is this feature not available in OpenSSH? Jason's patch is almost > 10 years old and doesn't apply to modern OpenSSH. If I cleaned it up, > would it be seriously considered for inclusion in a future release? > > Cheers, > Andrew > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From clausen at econ.upenn.edu Tue Dec 28 09:07:15 2010 From: clausen at econ.upenn.edu (Andrew Clausen) Date: Mon, 27 Dec 2010 17:07:15 -0500 Subject: openssh and keystroke timing attacks (again) In-Reply-To: <3FB0A2E9-73AB-4FA6-A6CB-3A73B56F53E3@doxpara.com> References: <3FB0A2E9-73AB-4FA6-A6CB-3A73B56F53E3@doxpara.com> Message-ID: Hi Dan, On 27 December 2010 16:26, Dan Kaminsky wrote: > Isn't it difficult to predict the size of a legitimate response to a keystroke? ?Just because you send a dummy response doesn't mean you got the size right. If you don't get the size right it's easy to differentiate wheat from chaff. I presume you are referring to part of the proposal: if there is no keystroke queued up to send when the transmission time arrives, a dummy keystroke would be sent. Your question is: what should the reply to the dummy look like? In most use cases such as writing commands in a shell, editing text in vim/emacs, talking with talk(1), the server responds as follows: (1) In the middle of a stream of keystrokes, the server immediately replies back with a short message immediately. Typically, it just echoes back the character just typed, or gives simple terminal commands such as moving a cursor. (2) At the end of a (potentially short) stream of keystrokes, there might be a larger reply, such as the output of an "ls" command, or the result of a paste operation in a text editor. Assuming (1) to be the case, if the server simply sends an immediate short reply to the dummy messages, it will look like a real keystroke, and an eavesdropper would have a hard time telling the real and dummy keystrokes apart ("wheat from chaff"). I would like to add that ssh already pads messages, so that replies of say 3 and 5 characters appear indistinguishable to eavesdroppers. Cheers, Andrew From clausen at econ.upenn.edu Tue Dec 28 09:53:51 2010 From: clausen at econ.upenn.edu (Andrew Clausen) Date: Mon, 27 Dec 2010 17:53:51 -0500 Subject: openssh and keystroke timing attacks (again) In-Reply-To: References: Message-ID: Hi Damien, On 27 December 2010 17:06, Damien Miller wrote: > I'd like to have better keystroke timing countermeasures in OpenSSH, but > they are just too intrusive under the current mainloop design. I'd like > to renovate the mainloop some time and this would make implementing things > like this quite a bit more easy. Yes, I agree that the client_loop() could do with some renovation. What did you have in mind? For what it's worth, I actually implemented most of my proposal before finding Jason's patch from 10 years ago. I only implemented the idea of only checking for input at regular intervals... there are no dummy messages, but that is trivial to add. I attached my patch (against the source I lazily acquired via Ubuntu's 10.10 apt-get source command). The main structural ingredient in the patch is a wrapper to select(2). This allows the caller to specify a list of timing events to be woken up on, in addition to file activity events. This makes it easier to "multiplex" multiple timing events such as tcp_keep_alive and keystroke countermeasures along with the I/O events. The wrapper's prototype and commentary follow: /* This wrapper to select(2) allows the user to supply a list of sleep times * to be woken up on. The process is woken up either after activity on the * fds, or when the soonest sleep time arrives. In the latter case, the * index of the relevant sleep event is recorded in *active_time. */ static int select_times(int nfds, fd_set *readfds, fd_set *writefds, fd_set *exceptfds, int ntimes, struct timeval **times, int *active_time) I still think client_loop() and client_wait_until_can_do_something() are still a bit too complicated though. Cheers, Andrew -------------- next part -------------- A non-text attachment was scrubbed... Name: hideinputtiming.diff Type: text/x-patch Size: 8182 bytes Desc: not available URL: From apb at cequrux.com Tue Dec 28 17:39:56 2010 From: apb at cequrux.com (Alan Barrett) Date: Tue, 28 Dec 2010 08:39:56 +0200 Subject: openssh and keystroke timing attacks (again) In-Reply-To: References: Message-ID: <20101228063956.GB1223@apb-laptoy.apb.alt.za> On Mon, 27 Dec 2010, Andrew Clausen wrote: > I think Jason's approach is spot on: > * keystrokes should be only sent at predetermined intervals (eg: > every 50ms, or 20 times a second) > * cover traffic at these fixed transmission times should be sent even > if no keystroke is pressed. This can be turned off whenever a user is > idle for 3 seconds. This idea has merit, but please make it adapt to low bandwidth and high delay networks. For example, avoid sending dummy traffic if the transmit queue is not empty (which probably signifies a low bandwidth or high loss connection); or move the predetermined intervals further apart if the connection has high round trip time. --apb (Alan Barrett) From imorgan at nas.nasa.gov Fri Dec 31 03:19:09 2010 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 30 Dec 2010 08:19:09 -0800 Subject: Problem with anonymous CVS server Message-ID: <20101230161909.GE6057@linux124.nas.nasa.gov> Hi, I noticed the following problem while doing a CVS update from anoncvs.mindrot.org: $ cvs up cvs server: cannot open directory /cvs/openssh: Operation not permitted cvs server: skipping directory cvs server: cannot read directory .: Operation not permitted $ -- Iain Morgan