From wim at livens.net Tue Jan 3 02:52:30 2006 From: wim at livens.net (Wim Livens) Date: Mon, 2 Jan 2006 16:52:30 +0100 Subject: Server allocating port number for -R ? Message-ID: <20060102155230.GA66838@hal.home.livens.net> I'm looking for a way to have the server allocate an available port number when using remote port forwarding. In draft-ietf-secsh-connect-25.txt such a feature is described but I fail to see if/how this is actually supported by openssh. Quote from the draft: If a client passes 0 as port number to bind and has 'want reply' TRUE then the server allocates the next available unprivileged port number and replies with the following message, otherwise there is no response specific data. Naively doing things like -R0:host:hostport fail with a "Bad forwarding port(s)" message. Thanks, Wim. From djm at mindrot.org Tue Jan 3 11:22:51 2006 From: djm at mindrot.org (Damien Miller) Date: Tue, 03 Jan 2006 11:22:51 +1100 Subject: Server allocating port number for -R ? In-Reply-To: <20060102155230.GA66838@hal.home.livens.net> References: <20060102155230.GA66838@hal.home.livens.net> Message-ID: <43B9C3DB.9040508@mindrot.org> Wim Livens wrote: > I'm looking for a way to have the server allocate an available port > number when using remote port forwarding. > > In draft-ietf-secsh-connect-25.txt such a feature is described but I > fail to see if/how this is actually supported by openssh. > > Quote from the draft: > > If a client passes 0 as port number to bind and has 'want reply' > TRUE then the server allocates the next available unprivileged port > number and replies with the following message, otherwise there is > no response specific data. > > Naively doing things like -R0:host:hostport fail with a "Bad > forwarding port(s)" message. This isn't supported at present, but there is a patch that we will probably look at in the next release cycle: http://bugzilla.mindrot.org/show_bug.cgi?id=1003 -d From alf at club-internet.fr Wed Jan 4 02:22:08 2006 From: alf at club-internet.fr (=?ISO-8859-1?Q?Fr=E9d=E9ric_Olivi=E9?=) Date: Tue, 03 Jan 2006 16:22:08 +0100 Subject: Bug ? on ssh-agent Message-ID: <43BA96A0.3080300@club-internet.fr> Hi, I fell on this using openssh on cygwin. Though it may be a cygwin related issue, I think it's may be a bug on the main openssh tree. Thus my posting here. I'm CC'ing to the public list for information. The part of code I'm refering to is : /* XXX might close listen socket */ (void)dup2(fd, STDIN_FILENO); (void)dup2(fd, STDOUT_FILENO); (void)dup2(fd, STDERR_FILENO); if (fd > 2) close(fd); I'm actually launching the ssh agent from a "run.exe" script launched at the start of my X server (Cygwin/X). Things used to work perfectly until my last update. Unfortunately, I don't know which version I used before :-( Something may have changed in the cygwin implementation. What happens is that the agent is apparently launched without any opened file descriptors (as far as I can see). So the auth socket gets the fd 0. We therefore fall on the "/* XXX might close listen socket */" case... I suggest a simple patch here : if ((fd = open(_PATH_DEVNULL, O_RDWR, 0)) != -1) { if (sock == 0) { dup2(sock, fd+1) ; close(sock) ; sock = fd+1 ; } (void)dup2(fd, STDIN_FILENO); (void)dup2(fd, STDOUT_FILENO); (void)dup2(fd, STDERR_FILENO); if (fd > 2) close(fd); } It would be possible to dup2 the socket a second time after the "close(fd)" so that it would use fd instead of fd+1, but I don't really see the point. Also, it might be cleaner to do a : if ((sock == STDIN_FILENO) || (sock == STDOUT_FILENO) || (sock == STDERR_FILENO)) Thanks for you feedback. Cheers, Fr?d?ric Olivi?. From rlynch at bway.net Wed Jan 4 03:19:27 2006 From: rlynch at bway.net (Ryan B. Lynch) Date: Tue, 03 Jan 2006 16:19:27 +0000 Subject: OpenSSL compile flags Message-ID: <43BAA40F.7080208@bway.net> When building OpenSSL version 0.9.7i (and all prior versions that I've seen) on Linux, the compiler flags passed to 'gcc' include: "-O3 -fomit-frame-pointer -mcpu=pentium" This occurs even when the output of `uname -m` and `arch` are "i486". I have a few machines with hacked 'uname' and 'arch' commands that will report "i486" even when the real arch is "i686", for use in compiling binaries for other i486 systems. Looking at the 'config' and 'Configure' scripts, it appears that the arch value is guessed based on 'uname', 'arch', and 'cat /proc/cpuinfo', in different cases. I guess I'm running into a situation where the configure script is looking at "/proc/cpuinfo", which I can't do a quick-and-easy hack to give false data. Is there an option that I'm missing to pass a particular arch value to compile OpenSSL for? Right now, I'm working around this by 'sed'ing the above-mentioned string out of the CCFLAGS variable in the Makefile and replacing it with "-O2 -march=i586 -pipe". Is this not proper, or should it work OK? (It seems to work fine, in running it, but there's a lot of things I wouldn't know about it.) Also, as a side-note, most of the literature I've seen regarding 'gcc' says that the "-mcpu=" flag is deprecated, and that "-march=" should be used instead. Is there a reason why OpenSSL uses "-mcpu="? Thanks for the time and help, here--OpenSSL and OpenSSH are wonderful tools, and I appreciate all of the effort that goes into them. Thanks, Ryan From imorgan at nas.nasa.gov Wed Jan 4 04:50:46 2006 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Tue, 3 Jan 2006 09:50:46 -0800 (PST) Subject: OpenSSL compile flags In-Reply-To: <43BAA40F.7080208@bway.net> from "Ryan B. Lynch" at Jan 03, 2006 04:19:27 PM Message-ID: <200601031750.k03HolHM018649@sun601.nas.nasa.gov> Perhaps you meant to send this to one of the OpenSSL mailing lists _not_ OpenSSH? On Tue Jan 3 08:19:27 2006, Ryan B. Lynch wrote: > > When building OpenSSL version 0.9.7i (and all prior versions that I've > seen) on Linux, the compiler flags passed to 'gcc' include: > > "-O3 -fomit-frame-pointer -mcpu=pentium" > > This occurs even when the output of `uname -m` and `arch` are "i486". I > have a few machines with hacked 'uname' and 'arch' commands that will > report "i486" even when the real arch is "i686", for use in compiling > binaries for other i486 systems. Looking at the 'config' and > 'Configure' scripts, it appears that the arch value is guessed based on > 'uname', 'arch', and 'cat /proc/cpuinfo', in different cases. I guess > I'm running into a situation where the configure script is looking at > "/proc/cpuinfo", which I can't do a quick-and-easy hack to give false data. > > Is there an option that I'm missing to pass a particular arch value to > compile OpenSSL for? Right now, I'm working around this by 'sed'ing the > above-mentioned string out of the CCFLAGS variable in the Makefile and > replacing it with "-O2 -march=i586 -pipe". Is this not proper, or > should it work OK? (It seems to work fine, in running it, but there's a > lot of things I wouldn't know about it.) > > Also, as a side-note, most of the literature I've seen regarding 'gcc' > says that the "-mcpu=" flag is deprecated, and that "-march=" should be > used instead. Is there a reason why OpenSSL uses "-mcpu="? > > Thanks for the time and help, here--OpenSSL and OpenSSH are wonderful > tools, and I appreciate all of the effort that goes into them. > > Thanks, > Ryan > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Iain Morgan From rlynch at bway.net Wed Jan 4 05:29:13 2006 From: rlynch at bway.net (Ryan B. Lynch) Date: Tue, 03 Jan 2006 18:29:13 +0000 Subject: OpenSSL compile flags In-Reply-To: <200601031750.k03HolHM018649@sun601.nas.nasa.gov> References: <200601031750.k03HolHM018649@sun601.nas.nasa.gov> Message-ID: <43BAC279.8000704@bway.net> Whoops, sorry--my bad. I'll repost it over there. Iain Morgan wrote: >Perhaps you meant to send this to one of the OpenSSL mailing lists _not_ >OpenSSH? > >On Tue Jan 3 08:19:27 2006, Ryan B. Lynch wrote: > > >>When building OpenSSL version 0.9.7i (and all prior versions that I've >>seen) on Linux, the compiler flags passed to 'gcc' include: >> >> "-O3 -fomit-frame-pointer -mcpu=pentium" >> >>This occurs even when the output of `uname -m` and `arch` are "i486". I >>have a few machines with hacked 'uname' and 'arch' commands that will >>report "i486" even when the real arch is "i686", for use in compiling >>binaries for other i486 systems. Looking at the 'config' and >>'Configure' scripts, it appears that the arch value is guessed based on >>'uname', 'arch', and 'cat /proc/cpuinfo', in different cases. I guess >>I'm running into a situation where the configure script is looking at >>"/proc/cpuinfo", which I can't do a quick-and-easy hack to give false data. >> >>Is there an option that I'm missing to pass a particular arch value to >>compile OpenSSL for? Right now, I'm working around this by 'sed'ing the >>above-mentioned string out of the CCFLAGS variable in the Makefile and >>replacing it with "-O2 -march=i586 -pipe". Is this not proper, or >>should it work OK? (It seems to work fine, in running it, but there's a >>lot of things I wouldn't know about it.) >> >>Also, as a side-note, most of the literature I've seen regarding 'gcc' >>says that the "-mcpu=" flag is deprecated, and that "-march=" should be >>used instead. Is there a reason why OpenSSL uses "-mcpu="? >> >>Thanks for the time and help, here--OpenSSL and OpenSSH are wonderful >>tools, and I appreciate all of the effort that goes into them. >> >>Thanks, >>Ryan >> >> >>_______________________________________________ >>openssh-unix-dev mailing list >>openssh-unix-dev at mindrot.org >>http://www.mindrot.org/mailman/listinfo/openssh-unix-dev >> >> >> > > >-- >Iain Morgan > >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > From djm at mindrot.org Wed Jan 4 11:19:09 2006 From: djm at mindrot.org (Damien Miller) Date: Wed, 04 Jan 2006 11:19:09 +1100 Subject: Bug ? on ssh-agent In-Reply-To: <43BA96A0.3080300@club-internet.fr> References: <43BA96A0.3080300@club-internet.fr> Message-ID: <43BB147D.2070205@mindrot.org> Fr?d?ric Olivi? wrote: > Hi, > > I fell on this using openssh on cygwin. Though it may be a cygwin > related issue, I think it's may be a bug on the main openssh tree. Thus > my posting here. I'm CC'ing to the public list for information. This is already fixed in -current. Please try a snapshot release. -d From godfryd at gmail.com Wed Jan 4 19:16:34 2006 From: godfryd at gmail.com (Michal Nowikowski) Date: Wed, 4 Jan 2006 09:16:34 +0100 Subject: ssh and pam-script Message-ID: <1687ed840601040016s13ab0e20m@mail.gmail.com> Hello I've got a problem with pam-script and ssh. pam-script is a module for PAM that enables execution of given script while pam session opens and/or closes. I try to use it with ssh while logging in and out: it is kind of login and logout scripts. PAM session creation is done in function do_pam_session which is invoked by do_setusercontext which is invoked by do_child. do_child function is invoked after fork. In a child process do_pam_session function sets global variable sshpam_session_open to remember that session was opened. After execution of do_setusercontext and do_pam_session function do_child does something and then invokes bash by execve. So in this moment child child process was destroyed by bash and sshpam_session_open variable was lost but it should be remembered elsewhere: in parent, than it would be possible to retrieve info that session was opened and must be closed what is checked in sshpam_cleanup. So in efect I am not able to use logout script because sshd never knows that pam session was created Could you help me with that? Maybe configuration of sshd should be different that fork is not executed. I use openssh 4.2p1-5 of Debian Sid. Regards Micha? Nowikowski From David.Levy at Sun.COM Wed Jan 4 19:58:13 2006 From: David.Levy at Sun.COM (David Levy) Date: Wed, 04 Jan 2006 08:58:13 +0000 Subject: Installing opensshd on Sun Cobalt Linux, shell interpreter issue Message-ID: <43BB8E25.6050707@Sun.COM> I have just installed openssh on my Sun Cobalt Qube, running Linux. The shell interpreter for the rc script forces /sbin/sh. This is defined in opensshd.init.in. This shell does not exist on this implementation of Linux. I have written about this in (much more) detail at http://blogs.sun.com/roller/page/DaveLevy/20060104. NB This would seem to me to be a common problem but I havn't found any references in the archives. The following bourne shell code would test for the requirement for a fix. if [ ! -x /sbin/sh ] && [ -x /bin/sh ] then # Change the shell interpreter # ....... fi I suggest that if [ ! -x /sbin/sh ]&& [ -x /bin/sh ] then # Change the shell interpreter script_ver=4_bin_sh cat ${opensshd_script_name} | sed -e "s?\#\!/sbin/sh?\#\!/bin/sh?g" \ >> ${opensshd_script_name}.${script_ver} fi would be one way of doing it. This would yield a file called opensshd.init.in.4_bin_sh. The "if shell exists" test would need to be repeated in the install script to ensure that the correct script was copied from the install directory to /etc/rc.d/init.d directory. The blog article http://blogs.sun.com/roller/page/DaveLevy/20060104 also discusses Linux's chkconfig. This would be simple to implement and on systems where it exists, make the install task simpler. (Is this an enhancement request?) This suggests that one script file for non chkconfig aware implementations and one for those that have it, although the opensshd.init.in only requires comment lines added. The install script would need to check for the existence of chkconfig and an implementation name scheme would need to be developed. NB I am considering writing a "status" branch for opensshd.init, let me know if anyone's interested. (I shall probably only browse the process table and test it on my Qube's Linux). -- Dave * David Levy * *Sun Microsystems Ltd.* 55, King William St., London EC4R 9ND United Kingdom Phone +44 (0) 20 7469 9908/x18308 Mobile +44 (0) 7710-360922 Blog http://blogs.sun.com/DaveLevy Email David.Levy at Sun.COM Sun Proprietary & Confidential . This e-mail message is for the sole use of the intended recipient(s) and may contain confidential and privilidged information. Any unauthorised review, use, disclosure or distribution is prohibited. If you are not the intended recepient, please contact the sender by reply e-mail and destroy all copies of the original message. From djm at mindrot.org Thu Jan 5 08:49:02 2006 From: djm at mindrot.org (Damien Miller) Date: Thu, 5 Jan 2006 08:49:02 +1100 (EST) Subject: Bug on ssh-agent (following my first report) In-Reply-To: <43BBF0EF.9020300@club-internet.fr> References: <43BA96A0.3080300@club-internet.fr> <43BB147D.2070205@mindrot.org> <43BBF0EF.9020300@club-internet.fr> Message-ID: Please don't send HTML mail. On Wed, 4 Jan 2006, Fr?d?ric Olivi? wrote: > Hi, > > I tested and reviewed the last CVS release. > > The patch which fixed this problem is wrong (sorry) for many reasons : > > 1) Doing a this sanitize_fd() like it is at the beginning of the main() is > plain wrong. What happens in this specific case is that fd 0 is closed at exec > time, but fd 1 and 2 are opened. And we definitely need one of them so that > ssh-agent can send it's environment vars on stdout. Please try this diff: Index: misc.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/misc.c,v retrieving revision 1.40 diff -u -p -r1.40 misc.c --- misc.c 2 Jan 2006 07:53:44 -0000 1.40 +++ misc.c 4 Jan 2006 21:45:34 -0000 @@ -601,18 +601,21 @@ tun_open(int tun, int mode) void sanitise_stdfd(void) { - int nullfd; + int nullfd, dupfd; - if ((nullfd = open(_PATH_DEVNULL, O_RDWR)) == -1) { + if ((nullfd = dupfd = open(_PATH_DEVNULL, O_RDWR)) == -1) { fprintf(stderr, "Couldn't open /dev/null: %s", strerror(errno)); exit(1); } - while (nullfd < 2) { - if (dup2(nullfd, nullfd + 1) == -1) { + while (dupfd < 2) { + /* Only clobber closed fds */ + if (fcntl(dupfd, F_GETFL, 0) >= 0) + continue; + if (dup2(nullfd, dupfd) == -1) { fprintf(stderr, "dup2: %s", strerror(errno)); exit(1); } - nullfd++; + dupfd++; } if (nullfd > 2) close(nullfd); From alf at club-internet.fr Thu Jan 5 11:58:14 2006 From: alf at club-internet.fr (=?ISO-8859-1?Q?Fr=E9d=E9ric_Olivi=E9?=) Date: Thu, 05 Jan 2006 01:58:14 +0100 Subject: Bug on ssh-agent (following my first report) In-Reply-To: References: <43BA96A0.3080300@club-internet.fr> <43BB147D.2070205@mindrot.org> <43BBF0EF.9020300@club-internet.fr> Message-ID: <43BC6F26.6010106@club-internet.fr> Damien Miller a ?crit : > Please don't send HTML mail. > Sorry. Hope this is better (I asked Thunderbird to send text-only on this list). > > Please try this diff: > It can't work. The "continue" statement causes "dupfd++" never to be evaluated thus resulting in an infinite loop. The following works better : /* Only clobber closed fds */ if (fcntl(dupfd, F_GETFL, 0) < 0) { if (dup2(nullfd, dupfd) == -1) { fprintf(stderr, "dup2: %s", strerror(errno)); exit(1); } } dupfd++; This solves the first problem. But not the second one though. FDs still get closed and re-duped to /dev/null (see the point 2) in my previous message). Thanks. > Index: misc.c > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/misc.c,v > retrieving revision 1.40 > diff -u -p -r1.40 misc.c > --- misc.c 2 Jan 2006 07:53:44 -0000 1.40 > +++ misc.c 4 Jan 2006 21:45:34 -0000 > @@ -601,18 +601,21 @@ tun_open(int tun, int mode) > void > sanitise_stdfd(void) > { > - int nullfd; > + int nullfd, dupfd; > > - if ((nullfd = open(_PATH_DEVNULL, O_RDWR)) == -1) { > + if ((nullfd = dupfd = open(_PATH_DEVNULL, O_RDWR)) == -1) { > fprintf(stderr, "Couldn't open /dev/null: %s", strerror(errno)); > exit(1); > } > - while (nullfd < 2) { > - if (dup2(nullfd, nullfd + 1) == -1) { > + while (dupfd < 2) { > + /* Only clobber closed fds */ > + if (fcntl(dupfd, F_GETFL, 0) >= 0) > + continue; > + if (dup2(nullfd, dupfd) == -1) { > fprintf(stderr, "dup2: %s", strerror(errno)); > exit(1); > } > - nullfd++; > + dupfd++; > } > if (nullfd > 2) > close(nullfd); > > From djm at mindrot.org Thu Jan 5 15:23:55 2006 From: djm at mindrot.org (Damien Miller) Date: Thu, 5 Jan 2006 15:23:55 +1100 (EST) Subject: Bug on ssh-agent (following my first report) In-Reply-To: <43BC6F26.6010106@club-internet.fr> References: <43BA96A0.3080300@club-internet.fr> <43BB147D.2070205@mindrot.org> <43BBF0EF.9020300@club-internet.fr> <43BC6F26.6010106@club-internet.fr> Message-ID: On Thu, 5 Jan 2006, Fr?d?ric Olivi? wrote: > Damien Miller a ?crit : > > Please don't send HTML mail. > > > Sorry. Hope this is better (I asked Thunderbird to send text-only on this > list). > > > > Please try this diff: > > > It can't work. The "continue" statement causes "dupfd++" never to be evaluated > thus resulting in an infinite loop. This is better: Index: misc.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/misc.c,v retrieving revision 1.40 diff -u -p -r1.40 misc.c --- misc.c 2 Jan 2006 07:53:44 -0000 1.40 +++ misc.c 5 Jan 2006 04:23:44 -0000 @@ -601,18 +601,20 @@ tun_open(int tun, int mode) void sanitise_stdfd(void) { - int nullfd; + int nullfd, dupfd; - if ((nullfd = open(_PATH_DEVNULL, O_RDWR)) == -1) { + if ((nullfd = dupfd = open(_PATH_DEVNULL, O_RDWR)) == -1) { fprintf(stderr, "Couldn't open /dev/null: %s", strerror(errno)); exit(1); } - while (nullfd < 2) { - if (dup2(nullfd, nullfd + 1) == -1) { + while (++dupfd <= 2) { + /* Only clobber closed fds */ + if (fcntl(dupfd, F_GETFL, 0) >= 0) + continue; + if (dup2(nullfd, dupfd) == -1) { fprintf(stderr, "dup2: %s", strerror(errno)); exit(1); } - nullfd++; } if (nullfd > 2) close(nullfd); From alf at club-internet.fr Fri Jan 6 01:41:37 2006 From: alf at club-internet.fr (=?ISO-8859-1?Q?Fr=E9d=E9ric_Olivi=E9?=) Date: Thu, 05 Jan 2006 15:41:37 +0100 Subject: Bug on ssh-agent (following my first report) In-Reply-To: References: <43BA96A0.3080300@club-internet.fr> <43BB147D.2070205@mindrot.org> <43BBF0EF.9020300@club-internet.fr> <43BC6F26.6010106@club-internet.fr> Message-ID: <43BD3021.9020306@club-internet.fr> Yes. It definitely is. And it actually also solves the second problem, contrary to what I said before. If the "standard" fds get "sanitised" this way, then nullfd gets the 0 fd and the socket can definitely not get it afterwards. I don't know what got mixed up in my mind :-( Please acccept my humble apologies. Nevertheless, this had to be corrected, and it now is. Thanks. > This is better: > > Index: misc.c > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/misc.c,v > retrieving revision 1.40 > diff -u -p -r1.40 misc.c > --- misc.c 2 Jan 2006 07:53:44 -0000 1.40 > +++ misc.c 5 Jan 2006 04:23:44 -0000 > @@ -601,18 +601,20 @@ tun_open(int tun, int mode) > void > sanitise_stdfd(void) > { > - int nullfd; > + int nullfd, dupfd; > > - if ((nullfd = open(_PATH_DEVNULL, O_RDWR)) == -1) { > + if ((nullfd = dupfd = open(_PATH_DEVNULL, O_RDWR)) == -1) { > fprintf(stderr, "Couldn't open /dev/null: %s", strerror(errno)); > exit(1); > } > - while (nullfd < 2) { > - if (dup2(nullfd, nullfd + 1) == -1) { > + while (++dupfd <= 2) { > + /* Only clobber closed fds */ > + if (fcntl(dupfd, F_GETFL, 0) >= 0) > + continue; > + if (dup2(nullfd, dupfd) == -1) { > fprintf(stderr, "dup2: %s", strerror(errno)); > exit(1); > } > - nullfd++; > } > if (nullfd > 2) > close(nullfd); From weigelt at metux.de Sat Jan 7 03:53:06 2006 From: weigelt at metux.de (Enrico Weigelt) Date: Fri, 6 Jan 2006 17:53:06 +0100 Subject: Automatic blacklist of IP-addresses. In-Reply-To: <20051218123540.31820.qmail@cdy.org> References: <43A47BAD.7030605@x3-c.com> <20051218123540.31820.qmail@cdy.org> Message-ID: <20060106165306.GA302@nibiru.local> * Peter Stuge schrieb: > This has been suggested before, but rejected. > > The recommended way to implement this is to monitor log output from > OpenSSH and make appropriate changes to the firewall settings. hmm. how could this be implemented ? We need a way to get the failed attemts to some other process. Some external event handler, which gets called on all noticable events with appropriate parameters, could help. ie. for login fail: $HANDLER login-failed ... succed login $HANDLER login-granted ... cu -- --------------------------------------------------------------------- Enrico Weigelt == metux IT service phone: +49 36207 519931 www: http://www.metux.de/ fax: +49 36207 519932 email: contact at metux.de cellphone: +49 174 7066481 --------------------------------------------------------------------- -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops -- --------------------------------------------------------------------- From stuge-openssh-unix-dev at cdy.org Sat Jan 7 04:14:16 2006 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 6 Jan 2006 18:14:16 +0100 Subject: Automatic blacklist of IP-addresses. In-Reply-To: <20060106165306.GA302@nibiru.local> References: <43A47BAD.7030605@x3-c.com> <20051218123540.31820.qmail@cdy.org> <20060106165306.GA302@nibiru.local> Message-ID: <20060106171416.25240.qmail@cdy.org> On Fri, Jan 06, 2006 at 05:53:06PM +0100, Enrico Weigelt wrote: > * Peter Stuge schrieb: > > The recommended way to implement this is to monitor log output > > from OpenSSH and make appropriate changes to the firewall > > settings. > > hmm. how could this be implemented ? I wasn't clear enough. The process that watches the log output from OpenSSH does the equivalent of your external event handler. What's important from OpenSSH's point of view is that one piece of information (failed and succeeded logins) should only be sent out through one data path (logging) rather than having redundancy within OpenSSH to send out same data multiple ways. > We need a way to get the failed attemts to some other process. > Some external event handler, which gets called on all noticable > events with appropriate parameters, could help. > > ie. for login fail: > > $HANDLER login-failed ... > > succed login > > $HANDLER login-granted Hook $HANDLER into the syslog system somehow and change (or wrap) it so that data can arrive on stdin instead of the command line. If you're running a syslogd that doesn't allow this perhaps syslog-ng could prove useful since it is quite configurable. //Peter From dwmw2 at infradead.org Sun Jan 8 12:00:59 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 08 Jan 2006 01:00:59 +0000 Subject: Allow --without-privsep build. Message-ID: <1136682059.30348.40.camel@pmac.infradead.org> I've been trying to cut down the size of openssh so I can run it on my Nokia 770. One thing which helps a fair amount (and will help even more when I get '-ffunction-sections -fdata-sections --gc-sections' working) is to have the option of compiling out privilege separation... Is it worth me tidying this up and trying to make it apply properly to the OpenBSD version? Does the openbsd version even use autocrap? --- openssh-4.2p1/auth-rhosts.c~ 2005-07-17 08:22:45.000000000 +0100 +++ openssh-4.2p1/auth-rhosts.c 2006-01-07 18:14:32.000000000 +0000 @@ -289,7 +289,9 @@ auth_rhosts2(struct passwd *pw, const ch auth_debug_reset(); ret = auth_rhosts2_raw(pw, client_user, hostname, ipaddr); +#ifdef USE_PRIVSEP if (!use_privsep) +#endif auth_debug_send(); return ret; } --- openssh-4.2p1/auth2.c~ 2005-07-17 08:26:44.000000000 +0100 +++ openssh-4.2p1/auth2.c 2006-01-07 18:52:24.000000000 +0000 @@ -175,8 +175,10 @@ input_userauth_request(int type, u_int32 use_privsep ? " [net]" : ""); authctxt->service = xstrdup(service); authctxt->style = style ? xstrdup(style) : NULL; +#ifdef USE_PRIVSEP if (use_privsep) mm_inform_authserv(service, style); +#endif } else if (strcmp(user, authctxt->user) != 0 || strcmp(service, authctxt->service) != 0) { packet_disconnect("Change of username or service not allowed: " --- openssh-4.2p1/config.h.in~ 2005-09-01 10:15:22.000000000 +0100 +++ openssh-4.2p1/config.h.in 2006-01-07 17:44:23.000000000 +0000 @@ -152,6 +152,9 @@ /* Builtin PRNG command timeout */ #undef ENTROPY_TIMEOUT_MSEC +/* Use privilege separation */ +#undef USE_PRIVSEP + /* non-privileged user for privilege separation */ #undef SSH_PRIVSEP_USER --- openssh-4.2p1/configure.ac~ 2005-08-31 17:59:49.000000000 +0100 +++ openssh-4.2p1/configure.ac 2006-01-07 18:41:38.000000000 +0000 @@ -1873,6 +1873,16 @@ AC_ARG_WITH(entropy-timeout, ) AC_DEFINE_UNQUOTED(ENTROPY_TIMEOUT_MSEC, $entropy_timeout) +use_privsep=1 + +AC_ARG_WITH(privsep, + [ --without-privsep Disable privilege separation], + [ + if test "x$withval" = "xno" ; then + use_privsep="" + fi + ] +) SSH_PRIVSEP_USER=sshd AC_ARG_WITH(privsep-user, [ --with-privsep-user=user Specify non-privileged user for privilege separation], @@ -1880,13 +1890,20 @@ AC_ARG_WITH(privsep-user, if test -n "$withval" && test "x$withval" != "xno" && \ test "x${withval}" != "xyes"; then SSH_PRIVSEP_USER=$withval + use_privsep=1 fi ] ) -AC_DEFINE_UNQUOTED(SSH_PRIVSEP_USER, "$SSH_PRIVSEP_USER") -AC_SUBST(SSH_PRIVSEP_USER) +if test ! -z "$use_privsep" ; then + AC_DEFINE(USE_PRIVSEP) + AC_DEFINE_UNQUOTED(SSH_PRIVSEP_USER, "$SSH_PRIVSEP_USER") + AC_SUBST(SSH_PRIVSEP_USER) + PRIVSEP_MSG=yes +else + PRIVSEP_MSG=no +fi -# We do this little dance with the search path to insure +# We do this little dance with the search path to ensure # that programs that we select for use by installed programs # (which may be run by the super-user) come from trusted # locations before they come from the user's private area. @@ -3434,7 +3451,10 @@ echo " Configuration files echo " Askpass program: $E" echo " Manual pages: $F" echo " PID file: $G" + +if test ! -z "$use_privsep" ; then echo " Privilege separation chroot path: $H" +fi if test "x$external_path_file" = "x/etc/login.conf" ; then echo " At runtime, sshd will use the path defined in $external_path_file" echo " Make sure the path to scp is present, otherwise scp will not work" --- openssh-4.2p1/monitor.c~ 2005-07-17 08:53:31.000000000 +0100 +++ openssh-4.2p1/monitor.c 2006-01-07 18:40:42.000000000 +0000 @@ -69,6 +69,8 @@ RCSID("$OpenBSD: monitor.c,v 1.63 2005/0 static Gssctxt *gsscontext = NULL; #endif +#ifdef USE_PRIVSEP + /* Imports */ extern ServerOptions options; extern u_int utmp_len; @@ -1916,3 +1918,5 @@ mm_answer_gss_userok(int sock, Buffer *m return (authenticated); } #endif /* GSSAPI */ + +#endif /* USE_PRIVSEP */ --- openssh-4.2p1/monitor_mm.c~ 2004-10-06 14:15:44.000000000 +0100 +++ openssh-4.2p1/monitor_mm.c 2006-01-07 18:39:36.000000000 +0000 @@ -35,6 +35,8 @@ RCSID("$OpenBSD: monitor_mm.c,v 1.9 2004 #include "log.h" #include "monitor_mm.h" +#ifdef USE_PRIVSEP + static int mm_compare(struct mm_share *a, struct mm_share *b) { @@ -343,3 +345,5 @@ mm_memvalid(struct mm_master *mm, void * if (end > (void *)((u_char *)mm->address + mm->size)) fatal("mm_memvalid: address too large: %p", address); } + +#endif --- openssh-4.2p1/monitor_wrap.c~ 2005-07-17 08:53:31.000000000 +0100 +++ openssh-4.2p1/monitor_wrap.c 2006-01-07 18:40:15.000000000 +0000 @@ -63,6 +63,8 @@ RCSID("$OpenBSD: monitor_wrap.c,v 1.40 2 #include "ssh-gss.h" #endif +#ifdef USE_PRIVSEP + /* Imports */ extern int compat20; extern Newkeys *newkeys[]; @@ -1217,3 +1219,5 @@ mm_ssh_gssapi_userok(char *user) return (authenticated); } #endif /* GSSAPI */ + +#endif /* USE_PRIVSEP */ --- openssh-4.2p1/monitor_wrap.h~ 2005-02-08 10:52:48.000000000 +0000 +++ openssh-4.2p1/monitor_wrap.h 2006-01-07 18:49:51.000000000 +0000 @@ -29,7 +29,12 @@ #define _MM_WRAP_H_ #include "key.h" #include "buffer.h" +#include "config.h" +#ifndef USE_PRIVSEP +#define use_privsep 0 +#define PRIVSEP(x) (x) +#else extern int use_privsep; #define PRIVSEP(x) (use_privsep ? mm_##x : x) @@ -111,4 +116,6 @@ void *mm_zalloc(struct mm_master *, u_in void mm_zfree(struct mm_master *, void *); void mm_init_compression(struct mm_master *); +#endif /* USE_PRIVSEP */ + #endif /* _MM_H_ */ --- openssh-4.2p1/servconf.c~ 2005-08-12 13:11:37.000000000 +0100 +++ openssh-4.2p1/servconf.c 2006-01-07 18:13:42.000000000 +0000 @@ -102,8 +102,10 @@ initialize_server_options(ServerOptions options->authorized_keys_file2 = NULL; options->num_accept_env = 0; +#ifdef USE_PRIVSEP /* Needs to be accessable in many places */ use_privsep = -1; +#endif } void @@ -230,10 +232,10 @@ fill_default_server_options(ServerOption if (options->authorized_keys_file == NULL) options->authorized_keys_file = _PATH_SSH_USER_PERMITTED_KEYS; +#ifdef USE_PRIVSEP /* Turn privilege separation on by default */ if (use_privsep == -1) use_privsep = 1; - #ifndef HAVE_MMAP if (use_privsep && options->compression == 1) { error("This platform does not support both privilege " @@ -242,6 +244,7 @@ fill_default_server_options(ServerOption options->compression = 0; } #endif +#endif } @@ -799,10 +802,11 @@ parse_flag: intptr = &options->allow_tcp_forwarding; goto parse_flag; +#ifdef USE_PRIVSEP case sUsePrivilegeSeparation: intptr = &use_privsep; goto parse_flag; - +#endif case sAllowUsers: while ((arg = strdelim(&cp)) && *arg != '\0') { if (options->num_allow_users >= MAX_ALLOW_USERS) --- openssh-4.2p1/sshd.c~ 2005-07-26 12:54:56.000000000 +0100 +++ openssh-4.2p1/sshd.c 2006-01-07 18:12:40.000000000 +0000 @@ -200,9 +200,11 @@ u_int utmp_len = MAXHOSTNAMELEN; int *startup_pipes = NULL; int startup_pipe; /* in child */ +#ifdef USE_PRIVSEP /* variables used for privilege separation */ int use_privsep; struct monitor *pmonitor = NULL; +#endif /* global authentication context */ Authctxt *the_authctxt = NULL; @@ -308,9 +310,10 @@ grace_alarm_handler(int sig) { /* XXX no idea how fix this signal handler */ +#ifdef USE_PRIVSEP if (use_privsep && pmonitor != NULL && pmonitor->m_pid > 0) kill(pmonitor->m_pid, SIGALRM); - +#endif /* Log error and exit. */ fatal("Timeout before authentication for %s", get_remote_ipaddr()); } @@ -536,6 +539,7 @@ demote_sensitive_data(void) /* We do not clear ssh1_host key and cookie. XXX - Okay Niels? */ } +#ifdef USE_PRIVSEP static void privsep_preauth_child(void) { @@ -678,6 +682,7 @@ privsep_postauth(Authctxt *authctxt) */ packet_set_authenticated(); } +#endif /* USE_PRIVSEP */ static char * list_hostkey_types(void) @@ -1691,10 +1696,11 @@ main(int ac, char **av) /* prepare buffer to collect messages to display to user after login */ buffer_init(&loginmsg); +#ifdef USE_PRIVSEP if (use_privsep) if (privsep_preauth(authctxt) == 1) goto authenticated; - +#endif /* perform the key exchange */ /* authenticate user and start session */ if (compat20) { @@ -1708,11 +1714,12 @@ main(int ac, char **av) * If we use privilege separation, the unprivileged child transfers * the current keystate and exits */ +#ifdef USE_PRIVSEP if (use_privsep) { mm_send_keystate(pmonitor); exit(0); } - +#endif authenticated: #ifdef SSH_AUDIT_EVENTS audit_event(SSH_AUTH_SUCCESS); -- dwmw2 From dwmw2 at infradead.org Sun Jan 8 12:05:07 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 08 Jan 2006 01:05:07 +0000 Subject: Allow --without-privsep build. In-Reply-To: <1136682059.30348.40.camel@pmac.infradead.org> References: <1136682059.30348.40.camel@pmac.infradead.org> Message-ID: <1136682307.30348.44.camel@pmac.infradead.org> On Sun, 2006-01-08 at 01:01 +0000, David Woodhouse wrote: > I've been trying to cut down the size of openssh so I can run it on my > Nokia 770. One thing which helps a fair amount (and will help even more > when I get '-ffunction-sections -fdata-sections --gc-sections' working) > is to have the option of compiling out privilege separation... When running without privsep I found that sshd was always closing stdin when starting a login shell. The first channel's ->ctl_fd and ->sock were both set to zero, rather than -1. I'm not sure if this is something I introduced myself with the previous patch, or something about the Nokia 770 environment... any ideas? The other thing I did to reduce the code size, btw, was to turn libssh into a shared library -- I assume there's no interest in merging any change along those lines? --- openssh-4.2p1/channels.c~ 2006-01-06 01:45:55.000000000 +0000 +++ openssh-4.2p1/channels.c 2006-01-06 04:05:47.000000000 +0000 @@ -183,6 +183,8 @@ channel_register_fds(Channel *c, int rfd c->rfd = rfd; c->wfd = wfd; c->efd = efd; + c->ctl_fd = -1; /* XXX: set elsewhere */ + c->sock = -1; channel_fds_changed = 1; if (rfd == -1 && wfd == -1 && efd == -1) @@ -196,7 +198,6 @@ channel_register_fds(Channel *c, int rfd /* XXX set close-on-exec -markus */ c->sock = (rfd == wfd) ? rfd : -1; - c->ctl_fd = -1; /* XXX: set elsewhere */ c->extended_usage = extusage; /* XXX ugly hack: nonblock is only set by the server */ @@ -332,8 +333,8 @@ channel_close_fd(int *fdp) static void channel_close_fds(Channel *c) { - debug3("channel %d: close_fds r %d w %d e %d c %d", - c->self, c->rfd, c->wfd, c->efd, c->ctl_fd); + debug3("channel %d: close_fds s %d r %d w %d e %d c %d", + c->self, c->sock, c->rfd, c->wfd, c->efd, c->ctl_fd); channel_close_fd(&c->sock); channel_close_fd(&c->ctl_fd); -- dwmw2 From djm at mindrot.org Sun Jan 8 12:15:19 2006 From: djm at mindrot.org (Damien Miller) Date: Sun, 08 Jan 2006 12:15:19 +1100 Subject: Allow --without-privsep build. In-Reply-To: <1136682059.30348.40.camel@pmac.infradead.org> References: <1136682059.30348.40.camel@pmac.infradead.org> Message-ID: <43C067A7.30809@mindrot.org> David Woodhouse wrote: > I've been trying to cut down the size of openssh so I can run it on my > Nokia 770. One thing which helps a fair amount (and will help even more > when I get '-ffunction-sections -fdata-sections --gc-sections' working) > is to have the option of compiling out privilege separation... > > Is it worth me tidying this up and trying to make it apply properly to > the OpenBSD version? Probably not, we aren't interested in removing security features for size benefits. Making things like compression, SSH1, X forwarding, etc. optional would stand a better chance though. > Does the openbsd version even use autocrap? No, it is an island of sanity. -d From djm at mindrot.org Sun Jan 8 12:27:34 2006 From: djm at mindrot.org (Damien Miller) Date: Sun, 08 Jan 2006 12:27:34 +1100 Subject: Allow --without-privsep build. In-Reply-To: <1136682307.30348.44.camel@pmac.infradead.org> References: <1136682059.30348.40.camel@pmac.infradead.org> <1136682307.30348.44.camel@pmac.infradead.org> Message-ID: <43C06A86.4010603@mindrot.org> David Woodhouse wrote: > On Sun, 2006-01-08 at 01:01 +0000, David Woodhouse wrote: > >>I've been trying to cut down the size of openssh so I can run it on my >>Nokia 770. One thing which helps a fair amount (and will help even more >>when I get '-ffunction-sections -fdata-sections --gc-sections' working) >>is to have the option of compiling out privilege separation... > > > When running without privsep I found that sshd was always closing stdin > when starting a login shell. The first channel's ->ctl_fd and ->sock > were both set to zero, rather than -1. I'm not sure if this is something > I introduced myself with the previous patch, or something about the > Nokia 770 environment... any ideas? See below. > The other thing I did to reduce the code size, btw, was to turn libssh > into a shared library -- I assume there's no interest in merging any > change along those lines? That is pretty much makefile changes. We don't do this because libssh.a is really just a compilation shortcut and isn't intended to be any sort of public API.. It would be very, very easy to hose your running sshd if you were misguided enough to make this shared and ever forget to update the library major number when the internals change. The internals change with every release, and more frequently if you are hacking ssh. > --- openssh-4.2p1/channels.c~ 2006-01-06 01:45:55.000000000 +0000 > +++ openssh-4.2p1/channels.c 2006-01-06 04:05:47.000000000 +0000 > @@ -183,6 +183,8 @@ channel_register_fds(Channel *c, int rfd > c->rfd = rfd; > c->wfd = wfd; > c->efd = efd; > + c->ctl_fd = -1; /* XXX: set elsewhere */ > + c->sock = -1; > channel_fds_changed = 1; This looks weird. My channel_register_fds() has this already: > c->rfd = rfd; > c->wfd = wfd; > c->sock = (rfd == wfd) ? rfd : -1; > c->ctl_fd = -1; /* XXX: set elsewhere */ > c->efd = efd; > c->extended_usage = extusage; From dwmw2 at infradead.org Sun Jan 8 12:46:55 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 08 Jan 2006 01:46:55 +0000 Subject: Allow --without-privsep build. In-Reply-To: <43C06A86.4010603@mindrot.org> References: <1136682059.30348.40.camel@pmac.infradead.org> <1136682307.30348.44.camel@pmac.infradead.org> <43C06A86.4010603@mindrot.org> Message-ID: <1136684815.30348.55.camel@pmac.infradead.org> On Sun, 2006-01-08 at 12:27 +1100, Damien Miller wrote: > Probably not, we aren't interested in removing security features for > size benefits. Making things like compression, SSH1, X forwarding, etc. > optional would stand a better chance though. Yeah, that figures. Of those, I'll probably have a look at removing SSH1 support. X forwarding doesn't take much code (not even with the hacks to handle multiple servers), and compression is actually a must-have feature for SSH on the machine in question, because it spends a lot of its active life doing IMAP over SSH over GPRS. > That is pretty much makefile changes. We don't do this because libssh.a > is really just a compilation shortcut and isn't intended to be any sort > of public API.. Yeah -- the dynamic library doesn't make much sense unless you care deeply about the amount of space you're taking up. Since I'm unlikely to spend much time actually hacking SSH on the toy, I'm happy enough with a dynamic library there, but I'll keep the patch local. > This looks weird. My channel_register_fds() has this already: My apologies; this is caused by the patch to support multiple displays over the ControlSocket, which does this... @@ -167,6 +180,14 @@ channel_register_fds(Channel *c, int rfd, int wfd, int efd, int extusage, int nonblock) { + c->rfd = rfd; + c->wfd = wfd; + c->efd = efd; + channel_fds_changed = 1; + + if (rfd == -1 && wfd == -1 && efd == -1) + return; + /* Update the maximum file descriptor value. */ channel_max_fd = MAX(channel_max_fd, rfd); channel_max_fd = MAX(channel_max_fd, wfd); @@ -174,11 +195,8 @@ /* XXX set close-on-exec -markus */ - c->rfd = rfd; - c->wfd = wfd; c->sock = (rfd == wfd) ? rfd : -1; c->ctl_fd = -1; /* XXX: set elsewhere */ - c->efd = efd; c->extended_usage = extusage; /* XXX ugly hack: nonblock is only set by the server */ -- dwmw2 From stuge-openssh-unix-dev at cdy.org Sun Jan 8 21:22:58 2006 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sun, 8 Jan 2006 11:22:58 +0100 Subject: Allow --without-privsep build. In-Reply-To: <1136682059.30348.40.camel@pmac.infradead.org> References: <1136682059.30348.40.camel@pmac.infradead.org> Message-ID: <20060108102258.32674.qmail@cdy.org> On Sun, Jan 08, 2006 at 01:00:59AM +0000, David Woodhouse wrote: > --- openssh-4.2p1/configure.ac~ 2005-08-31 17:59:49.000000000 +0100 > +++ openssh-4.2p1/configure.ac 2006-01-07 18:41:38.000000000 +0000 > @@ -1873,6 +1873,16 @@ AC_ARG_WITH(entropy-timeout, > ) > AC_DEFINE_UNQUOTED(ENTROPY_TIMEOUT_MSEC, $entropy_timeout) > > +use_privsep=1 > + > +AC_ARG_WITH(privsep, > + [ --without-privsep Disable privilege separation], > + [ > + if test "x$withval" = "xno" ; then > + use_privsep="" > + fi > + ] > +) The above logic looks backwards. It's as if the option was named --with-privsep rather than --without-privsep. //Peter From dwmw2 at infradead.org Mon Jan 9 01:25:52 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 08 Jan 2006 14:25:52 +0000 Subject: Allow --without-privsep build. In-Reply-To: <20060108102258.32674.qmail@cdy.org> References: <1136682059.30348.40.camel@pmac.infradead.org> <20060108102258.32674.qmail@cdy.org> Message-ID: <1136730352.30348.80.camel@pmac.infradead.org> On Sun, 2006-01-08 at 11:22 +0100, Peter Stuge wrote:= > The above logic looks backwards. It's as if the option was named > --with-privsep rather than --without-privsep. Empirically so. Yes, I was confused too -- but it's autocrap so I try not to think about it too hard. -- dwmw2 From ml at t-b-o-h.net Mon Jan 9 02:46:01 2006 From: ml at t-b-o-h.net (Tuc at T-B-O-H) Date: Sun, 8 Jan 2006 10:46:01 -0500 (EST) Subject: Stalls and closes Message-ID: <200601081546.k08Fk1D1027317@vjofn.tucs-beachin-obx-house.com> Hi, Trying to SSH to a server over an OPENVPN link, and it seems to be stalling , and then closing the connection. Can I do some command line magic to stop the stall, or get a password in before it closes? vjofn% ssh -v tuc at 10.2.0.2 OpenSSH_3.5p1 FreeBSD-20030924, SSH protocols 1.5/2.0, OpenSSL 0x0090704f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: ssh_connect: needpriv 0 debug1: Connecting to 10.2.0.2 [10.2.0.2] port 22. debug1: Connection established. debug1: identity file /home/tbohml/.ssh/identity type -1 debug1: identity file /home/tbohml/.ssh/id_rsa type -1 debug1: identity file /home/tbohml/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_3.8.1p1 FreeBSD-20040419 debug1: match: OpenSSH_3.8.1p1 FreeBSD-20040419 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.5p1 FreeBSD-20030924 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug1: kex: server->client aes128-cbc hmac-md5 none debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 122/256 debug1: bits set: 1021/2048 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY The authenticity of host '10.2.0.2 (10.2.0.2)' can't be established. DSA key fingerprint is 37:ed:f0:c8:ab:ec:fd:b9:69:6a:3f:a3:2a:70:90:b7. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added '10.2.0.2' (DSA) to the list of known hosts. debug1: bits set: 1027/2048 debug1: ssh_dss_verify: signature correct debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: done: ssh_kex2. debug1: send SSH2_MSG_SERVICE_REQUEST debug1: service_accept: ssh-userauth debug1: got SSH2_MSG_SERVICE_ACCEPT STALLS HERE debug1: authentications that can continue: publickey,keyboard-interactive debug1: next auth method to try is publickey debug1: try privkey: /home/tbohml/.ssh/identity debug1: try privkey: /home/tbohml/.ssh/id_rsa debug1: try privkey: /home/tbohml/.ssh/id_dsa debug1: next auth method to try is keyboard-interactive Connection closed by 10.2.0.2 debug1: Calling cleanup 0x804c158(0x0) vjofn% From djm at mindrot.org Mon Jan 9 08:06:59 2006 From: djm at mindrot.org (Damien Miller) Date: Mon, 09 Jan 2006 08:06:59 +1100 Subject: Stalls and closes In-Reply-To: <200601081546.k08Fk1D1027317@vjofn.tucs-beachin-obx-house.com> References: <200601081546.k08Fk1D1027317@vjofn.tucs-beachin-obx-house.com> Message-ID: <43C17EF3.7040106@mindrot.org> Tuc at T-B-O-H wrote: > Hi, > > Trying to SSH to a server over an OPENVPN link, and it seems to be > stalling , and then closing the connection. Can I do some command line magic > to stop the stall, or get a password in before it closes? if your transport is flakey, then no. On the other hand, both the client and the server are quite old versions, so you should consider updating. -d From ml at t-b-o-h.net Mon Jan 9 08:46:49 2006 From: ml at t-b-o-h.net (Tuc at T-B-O-H) Date: Sun, 8 Jan 2006 16:46:49 -0500 (EST) Subject: Stalls and closes In-Reply-To: <43C17EF3.7040106@mindrot.org> from "Damien Miller" at Jan 09, 2006 08:06:59 AM Message-ID: <200601082146.k08Lkndt035805@vjofn.tucs-beachin-obx-house.com> > > Tuc at T-B-O-H wrote: > > Hi, > > > > Trying to SSH to a server over an OPENVPN link, and it seems to be > > stalling , and then closing the connection. Can I do some command line magic > > to stop the stall, or get a password in before it closes? > > if your transport is flakey, then no. > Interesting... I didn't mention that the transport is... Not FLAKEY, but SLOW. (Satellite on the remote end). How did you come to that determination? (Just for the future so I can see it in debug others might send me). I don't have much packet loss : -bash-2.05b$ ping -c 10 10.2.0.2 PING 10.2.0.2 (10.2.0.2): 56 data bytes 64 bytes from 10.2.0.2: icmp_seq=0 ttl=64 time=837.061 ms 64 bytes from 10.2.0.2: icmp_seq=1 ttl=64 time=813.067 ms 64 bytes from 10.2.0.2: icmp_seq=2 ttl=64 time=840.012 ms 64 bytes from 10.2.0.2: icmp_seq=3 ttl=64 time=892.644 ms 64 bytes from 10.2.0.2: icmp_seq=4 ttl=64 time=863.727 ms 64 bytes from 10.2.0.2: icmp_seq=5 ttl=64 time=835.055 ms 64 bytes from 10.2.0.2: icmp_seq=6 ttl=64 time=776.231 ms 64 bytes from 10.2.0.2: icmp_seq=7 ttl=64 time=858.098 ms 64 bytes from 10.2.0.2: icmp_seq=8 ttl=64 time=838.773 ms 64 bytes from 10.2.0.2: icmp_seq=9 ttl=64 time=890.295 ms --- 10.2.0.2 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max/stddev = 776.231/844.496/892.644/32.887 ms > > On the other hand, both the client > and the server are quite old versions, so you should consider updating. > The client is old, admitted, FreeBSD 4.10, but the server was just installed, FreeBSD 5.4! I forgot to mention that it stalls after : debug1: next auth method to try is keyboard-interactive also..... I was hoping for a way to fix it, its a 9 hour drive to the beachhouse that that server is at... Thanks, Tuc/TBOH From djm at mindrot.org Mon Jan 9 09:33:30 2006 From: djm at mindrot.org (Damien Miller) Date: Mon, 9 Jan 2006 09:33:30 +1100 (EST) Subject: Stalls and closes In-Reply-To: <200601082146.k08Lkndt035805@vjofn.tucs-beachin-obx-house.com> References: <200601082146.k08Lkndt035805@vjofn.tucs-beachin-obx-house.com> Message-ID: On Sun, 8 Jan 2006, Tuc at T-B-O-H wrote: > Interesting... I didn't mention that the transport is... Not FLAKEY, > but SLOW. (Satellite on the remote end). How did you come to that > determination? (Just for the future so I can see it in debug others might > send me). I don't have much packet loss : I regularly run openssh over a GPRS link with around 1s latency and a couple of percent packet loss. It is slow, but it doesn't stall. You may be suffering from path MTU issues. -d From vinschen at redhat.com Mon Jan 9 23:49:41 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 9 Jan 2006 13:49:41 +0100 Subject: [PATCH] Add service dependency to network Message-ID: <20060109124941.GA5823@calimero.vinschen.de> Hi, Cygwin only: Under some circumstances, the sshd service gets accidentally started *before* the network service has been started up. The reason that this can happen is, that the sshd service gets installed without a dependency to the network service in contrib/cygwin/ssh-host-config so far. The below patch fixes that by adding a dependency to the "tcpip" Windows service. This should solve the problem sufficiently. Please apply. Thanks, Corinna Index: contrib/cygwin/ssh-host-config =================================================================== RCS file: /cvs/openssh_cvs/contrib/cygwin/ssh-host-config,v retrieving revision 1.17 diff -p -u -r1.17 ssh-host-config --- contrib/cygwin/ssh-host-config 9 May 2005 13:48:17 -0000 1.17 +++ contrib/cygwin/ssh-host-config 9 Jan 2006 12:45:45 -0000 @@ -551,14 +551,14 @@ then [ -z "${_cygwin}" ] && _cygwin="ntsec" if [ $_nt2003 -gt 0 -a "${sshd_server_in_sam}" = "yes" ] then - if cygrunsrv -I sshd -d "CYGWIN sshd" -p /usr/sbin/sshd -a -D -u sshd_server -w "${_password}" -e "CYGWIN=${_cygwin}" + if cygrunsrv -I sshd -d "CYGWIN sshd" -p /usr/sbin/sshd -a -D -u sshd_server -w "${_password}" -e "CYGWIN=${_cygwin}" -y tcpip then echo echo "The service has been installed under sshd_server account." echo "To start the service, call \`net start sshd' or \`cygrunsrv -S sshd'." fi else - if cygrunsrv -I sshd -d "CYGWIN sshd" -p /usr/sbin/sshd -a -D -e "CYGWIN=${_cygwin}" + if cygrunsrv -I sshd -d "CYGWIN sshd" -p /usr/sbin/sshd -a -D -e "CYGWIN=${_cygwin}" -y tcpip then echo echo "The service has been installed under LocalSystem account." -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From paul.moore at centrify.com Wed Jan 11 08:50:52 2006 From: paul.moore at centrify.com (Paul Moore) Date: Tue, 10 Jan 2006 13:50:52 -0800 Subject: PAM auth with disabled user Message-ID: Is it intentional that password auth using PAM continues trying to log on (giving password 3 prompts) in the case that a user is disabled (so that pam_account returns an error code). It can be argued both ways (saying 'you are disabled' is giving out too much information, making it look like you are entering the wrong password confuses and frustrates the user) From dtucker at zip.com.au Wed Jan 11 20:11:38 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 11 Jan 2006 20:11:38 +1100 Subject: PAM auth with disabled user In-Reply-To: References: Message-ID: <20060111091138.GA15517@gate.dtucker.net> On Tue, Jan 10, 2006 at 01:50:52PM -0800, Paul Moore wrote: > Is it intentional that password auth using PAM continues trying to log > on (giving password 3 prompts) in the case that a user is disabled (so > that pam_account returns an error code). > > It can be argued both ways (saying 'you are disabled' is giving out too > much information, making it look like you are entering the wrong > password confuses and frustrates the user) Which version are you looking at? The last couple of versions will send the output from PAM to the client under most conditions, and there are a couple of fixes in the current development version that should fix the remaining cases (those will be in the next release). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Wed Jan 11 21:18:19 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 11 Jan 2006 21:18:19 +1100 Subject: Stalls and closes In-Reply-To: <200601082146.k08Lkndt035805@vjofn.tucs-beachin-obx-house.com> References: <43C17EF3.7040106@mindrot.org> <200601082146.k08Lkndt035805@vjofn.tucs-beachin-obx-house.com> Message-ID: <20060111101819.GA16397@gate.dtucker.net> On Sun, Jan 08, 2006 at 04:46:49PM -0500, Tuc at T-B-O-H wrote: > Interesting... I didn't mention that the transport is... Not FLAKEY, > but SLOW. (Satellite on the remote end). How did you come to that > determination? (Just for the future so I can see it in debug others might > send me). I don't have much packet loss : > > -bash-2.05b$ ping -c 10 10.2.0.2 > PING 10.2.0.2 (10.2.0.2): 56 data bytes > 64 bytes from 10.2.0.2: icmp_seq=0 ttl=64 time=837.061 ms Try this again with a packet size equivalent to the path MTU. I think you'll need to use a ping packetsize of MTU - 28 bytes (but I might be wrong, use tcpdump to watch the outgoing packets to get it right). The thing that would really tell is if you could watch the SendQ sizes in netstat on the server but from the sound of it that might not be possible. It's worth checking on the client side (look for a non-zero and increasing queue size). > The client is old, admitted, FreeBSD 4.10, but the server was > just installed, FreeBSD 5.4! Don't FreeBSD still have their own mods to sshd? > I forgot to mention that it stalls after : > debug1: next auth method to try is keyboard-interactive > > also..... > > I was hoping for a way to fix it, its a 9 hour drive to the beachhouse > that that server is at... Try reducing the MTU on the client's network interface, or similarly limiting the TCP max segment size (ieg max-mss scrub option in pf, or clampmss on Linux). -- 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 ndbecker2 at gmail.com Thu Jan 12 01:52:05 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 11 Jan 2006 09:52:05 -0500 Subject: why not option to automatically add pub key? Message-ID: One of the annoyances of ssh is the need to transfer the public key from client machine to server machine, and append to authorized_keys. Although it's simple to do, it's annoying to have to do this manually. Why can't this be automated? ssh offers to add new machine to known_hosts. Why doesn't it offer to add the public key to authorized_keys? From darryl at netbauds.net Thu Jan 12 03:30:51 2006 From: darryl at netbauds.net (Darryl L. Miles) Date: Wed, 11 Jan 2006 16:30:51 +0000 Subject: Linux 4.2p1 crash during reverse name lookup Message-ID: <43C532BB.2080704@netbauds.net> 4.0p1 and 4.2p1 are affected for me, I'm using Linux based around a FC2 build (~2 years old). I'm trying to login with password authentication from psftp.exe (part of PuTTY) but it. Maybe this bug isn't with OpenSSH itself but a supporting library, I would appreciate your assistance in tracking down the problem. I have tried getting a 'core' file out of SSH with 'ulimit -c unlimited' before starting sshd, but I'm unable to find where the core file is. The procps listing indicates SSH's working directory is / in the root filesystem. The reason why I state the problem occurs reverse name lookup is a guess from the strace output, it looks like it is tring to load libnss_dns.so, I'm not sure if this is being looked at from within the normal outer root filesystem view or from a chroot ? $ psftp.exe -v dlm at ns1.netbauds.net -P 24 Server version: SSH-1.99-OpenSSH_4.2 We claim version: SSH-2.0-PuTTY-Release-0.56 Using SSH protocol version 2 Doing Diffie-Hellman group exchange Doing Diffie-Hellman key exchange Host key fingerprint is: ssh-rsa 1024 3e:77:d5:a0:ab:cd:ff:fd:ff:ef:e9:ec:13:1c:03:09 Initialised AES-256 client->server encryption Initialised AES-256 server->client encryption Initialised HMAC-SHA1 client->server MAC algorithm Initialised HMAC-SHA1 server->client MAC algorithm Using username "dlm". ssh_init: error during SSH connection setup $ Strace Linux side output: Process 4331 attached - interrupt to quit clone(Process 5967 attached child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7fcc0c8) = 5967 [...SNIP...] [pid 5967] execve("/opt/openssh/sbin/sshd", ["/opt/openssh/sbin/sshd", "-p", "24", "-R"], [/* 25 vars */]) = 0 [...SNIP...] [pid 5967] getpeername(3, {sa_family=AF_INET6, sin6_port=htons(4040), inet_pton(AF_INET6, "::ffff:82.36.183.26", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 [...SNIP...] [pid 5967] getpeername(3, {sa_family=AF_INET6, sin6_port=htons(4040), inet_pton(AF_INET6, "::ffff:82.36.183.26", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 [...SNIP...] [pid 5967] getpeername(3, {sa_family=AF_INET6, sin6_port=htons(4040), inet_pton(AF_INET6, "::ffff:82.36.183.26", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 [...SNIP...] [pid 5967] clone(Process 5968 attached child_stack=0, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0xb7fcc0c8) = 5968 [...SNIP...] [pid 4657] getpeername(3, {sa_family=AF_INET6, sin6_port=htons(4034), inet_pton(AF_INET6, "::ffff:www.xxx.yyy.zzz", &sin6_addr), sin6_flowinfo=0, sin6_scope_id=0}, [28]) = 0 [pid 4657] socket(PF_UNIX, SOCK_STREAM, 0) = 6 [pid 4657] connect(6, {sa_family=AF_UNIX, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) [pid 4657] close(6) = 0 [pid 4657] gettimeofday({1136994626, 380903}, NULL) = 0 [pid 4657] open("/etc/resolv.conf", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 4657] uname({sys="Linux", node="mail.netbauds.net", ...}) = 0 [pid 4657] open("/etc/host.conf", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 4657] open("/etc/hosts", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 4657] open("/etc/ld.so.cache", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 4657] open("/lib/tls/i686/sse2/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 4657] stat64("/lib/tls/i686/sse2", 0xbfffd4fc) = -1 ENOENT (No such file or directory) [pid 4657] open("/lib/tls/i686/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 4657] stat64("/lib/tls/i686", 0xbfffd4fc) = -1 ENOENT (No such file or directory) [pid 4657] open("/lib/tls/sse2/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 4657] stat64("/lib/tls/sse2", 0xbfffd4fc) = -1 ENOENT (No such file or directory) [pid 4657] open("/lib/tls/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 4657] stat64("/lib/tls", 0xbfffd4fc) = -1 ENOENT (No such file or directory) [pid 4657] open("/lib/i686/sse2/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 4657] stat64("/lib/i686/sse2", 0xbfffd4fc) = -1 ENOENT (No such file or directory) [pid 4657] open("/lib/i686/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 4657] stat64("/lib/i686", 0xbfffd4fc) = -1 ENOENT (No such file or directory) [pid 4657] open("/lib/sse2/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 4657] stat64("/lib/sse2", 0xbfffd4fc) = -1 ENOENT (No such file or directory) [pid 4657] open("/lib/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 4657] stat64("/lib", 0xbfffd4fc) = -1 ENOENT (No such file or directory) [pid 4657] open("/usr/lib/tls/i686/sse2/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 4657] stat64("/usr/lib/tls/i686/sse2", 0xbfffd4fc) = -1 ENOENT (No such file or directory) [pid 4657] open("/usr/lib/tls/i686/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 4657] stat64("/usr/lib/tls/i686", 0xbfffd4fc) = -1 ENOENT (No such file or directory) [pid 4657] open("/usr/lib/tls/sse2/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 4657] stat64("/usr/lib/tls/sse2", 0xbfffd4fc) = -1 ENOENT (No such file or directory) [pid 4657] open("/usr/lib/tls/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 4657] stat64("/usr/lib/tls", 0xbfffd4fc) = -1 ENOENT (No such file or directory) [pid 4657] open("/usr/lib/i686/sse2/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 4657] stat64("/usr/lib/i686/sse2", 0xbfffd4fc) = -1 ENOENT (No such file or directory) [pid 4657] open("/usr/lib/i686/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 4657] stat64("/usr/lib/i686", 0xbfffd4fc) = -1 ENOENT (No such file or directory) [pid 4657] open("/usr/lib/sse2/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 4657] stat64("/usr/lib/sse2", 0xbfffd4fc) = -1 ENOENT (No such file or directory) [pid 4657] open("/usr/lib/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 4657] stat64("/usr/lib", 0xbfffd4fc) = -1 ENOENT (No such file or directory) [pid 4657] --- SIGSEGV (Segmentation fault) @ 0 (0) --- Process 4657 detached [pid 4654] <... read resumed> 0xbffff018, 4) = ? ERESTARTSYS (To be restarted) [pid 4654] --- SIGCHLD (Child exited) @ 0 (0) --- [pid 4654] read(6, "", 4) = 0 [pid 4654] exit_group(255) = ? Process 4654 detached <... select resumed> ) = 1 (in [5]) --- SIGCHLD (Child exited) @ 0 (0) --- waitpid(-1, [{WIFEXITED(s) && WEXITSTATUS(s) == 255}], WNOHANG) = 4654 waitpid(-1, 0xbfffedc0, WNOHANG) = -1 ECHILD (No child processes) rt_sigaction(SIGCHLD, NULL, {0x804c3f0, [], 0}, 8) = 0 sigreturn() = ? (mask now []) close(5) = 0 select(6, [3], NULL, NULL, NULL Process 4331 detached From the SSH server system: $ locate libnss_dns /lib/libnss_dns-2.3.3.so /lib/libnss_dns.so.2 /lib/libnss_dns.so.1 /usr/lib/libnss_dns.so.1 /usr/lib/libnss_dns.so -- Darryl L. Miles From dkg-openssh.com at fifthhorseman.net Thu Jan 12 03:49:29 2006 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 11 Jan 2006 11:49:29 -0500 Subject: why not option to automatically add pub key? In-Reply-To: References: Message-ID: <17349.14105.509412.124246@localhost.localdomain> hi Neal-- On January 11, ndbecker2 at gmail.com said: > One of the annoyances of ssh is the need to transfer the public key from > client machine to server machine, and append to authorized_keys. Although > it's simple to do, it's annoying to have to do this manually. Why can't > this be automated? ssh offers to add new machine to known_hosts. Why > doesn't it offer to add the public key to authorized_keys? the debian distribution (at least) of openssh contains ssh-copy-id, which is a simple shell script to automate that operation. you can find the script in CVS here: http://www.chiark.greenend.org.uk/ucgi/~cjwatson/cvsweb/openssh/contrib/ssh-copy-id i think it's also in the openssh CVS, under contrib. Since i run with ControlMaster/ControlPath set up as autoask, when i've connected to a machine for the first time, i just run ssh-copy-id locally and it sets everything up for me over the existing connection for future use. hth, --dkg From darryl at netbauds.net Thu Jan 12 04:03:54 2006 From: darryl at netbauds.net (Darryl L. Miles) Date: Wed, 11 Jan 2006 17:03:54 +0000 Subject: Stalls and closes In-Reply-To: References: Message-ID: <43C53A7A.7070704@netbauds.net> Shot in the dark, does reverse DNS work for your 10.x.x.x addresses from the server back to the client. If you issue a: $ dig -x 10.x.x.x From the server system using the clients IP, how long does it take to return a response? If you have a delegation setup and they are not opertional or routable then the resolver will retransmit out the requests before failing and passing control back to SSHD to continue. -- Darryl L. Miles From stuge-openssh-unix-dev at cdy.org Thu Jan 12 05:41:11 2006 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Wed, 11 Jan 2006 19:41:11 +0100 Subject: why not option to automatically add pub key? In-Reply-To: References: Message-ID: <20060111184112.3620.qmail@cdy.org> On Wed, Jan 11, 2006 at 09:52:05AM -0500, Neal Becker wrote: > Why can't this be automated? Of course it can. But that doesn't mean it's a good idea. OpenSSH doesn't want to dictate (and thereby limit) your access control policy. Access control administration is left to the administrator, which I think makes a lot of sense. //Peter From stuge-openssh-unix-dev at cdy.org Thu Jan 12 05:45:28 2006 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Wed, 11 Jan 2006 19:45:28 +0100 Subject: Linux 4.2p1 crash during reverse name lookup In-Reply-To: <43C532BB.2080704@netbauds.net> References: <43C532BB.2080704@netbauds.net> Message-ID: <20060111184528.4318.qmail@cdy.org> On Wed, Jan 11, 2006 at 04:30:51PM +0000, Darryl L. Miles wrote: > 4.0p1 and 4.2p1 are affected for me, I'm using Linux based around a > FC2 build (~2 years old). Was OpenSSH build on/specifically for the target system? > Maybe this bug isn't with OpenSSH itself but a supporting library, > I would appreciate your assistance in tracking down the problem. It doesn't seem to be in OpenSSH, no. > [pid 4657] stat64("/usr/lib/sse2", 0xbfffd4fc) = -1 ENOENT (No such > file or directory) > [pid 4657] open("/usr/lib/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No > such file or directory) > [pid 4657] stat64("/usr/lib", 0xbfffd4fc) = -1 ENOENT (No such file or > directory) > [pid 4657] --- SIGSEGV (Segmentation fault) @ 0 (0) --- This crash is inside the glibc resolver, upgrade glibc would be my advice. //Peter From dkg-openssh.com at fifthhorseman.net Thu Jan 12 06:36:42 2006 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 11 Jan 2006 14:36:42 -0500 Subject: why not option to automatically add pub key? In-Reply-To: <20060111184112.3620.qmail@cdy.org> References: <20060111184112.3620.qmail@cdy.org> Message-ID: <17349.24138.865916.610581@localhost.localdomain> On January 11, stuge-openssh-unix-dev at cdy.org said: > On Wed, Jan 11, 2006 at 09:52:05AM -0500, Neal Becker wrote: > > Why can't this be automated? > > Of course it can. But that doesn't mean it's a good idea. i completely agree that making this mandatory behavior is not a good idea. However, i don't think Neal Becker was suggesting that. He asked if ssh could offer to add the client's public key to the remote account's authorized_keys upon first connection (presumably only when the keys stored in an agent aren't already present in the remote account). Again, i don't think even making the offer to the end user should be the default behavior (too many people don't understand the consequences of the known_hosts prompts as it is). But i could see how it might be nice to allow that as an option. However, it's probably implementable with some sort of fancy combination of ProxyCommand, ControlMaster/Path, and shell if ssh-copy-id isn't streamlined enough for you. For example: ProxyCommand could spawn two processes: process A runs netcat to remote port 22, and process B extracts your public keys from your current agent and watches the ControlPath location. Once the ControlMaster is established properly (and the ControlPath socket is set up), process B would check (over the socket) if the remote authorized_keys contains your agent's keys. If not, it would push them over via something like ssh-copy-id. > OpenSSH doesn't want to dictate (and thereby limit) your access > control policy. Access control administration is left to the > administrator, which I think makes a lot of sense. Unless i'm misunderstanding you, i have to disagree with this. if the administrator doesn't want the end user using pubkey auth at all, she should disable it in the sshd config file. If she's allowing pubkey auth, it's entirely reasonable to allow the end user to set up and manage his own keys. The initial proposal was one possible mechanism for a user to handle his own key management. --dkg From ndbecker2 at gmail.com Thu Jan 12 07:22:09 2006 From: ndbecker2 at gmail.com (Neal Becker) Date: Wed, 11 Jan 2006 15:22:09 -0500 Subject: why not option to automatically add pub key? References: <20060111184112.3620.qmail@cdy.org> <17349.24138.865916.610581@localhost.localdomain> Message-ID: Daniel Kahn Gillmor wrote: > On January 11, stuge-openssh-unix-dev at cdy.org said: > > > On Wed, Jan 11, 2006 at 09:52:05AM -0500, Neal Becker wrote: > > > Why can't this be automated? > > > > Of course it can. But that doesn't mean it's a good idea. > > i completely agree that making this mandatory behavior is not a good > idea. However, i don't think Neal Becker was suggesting that. He > asked if ssh could offer to add the client's public key to the remote > account's authorized_keys upon first connection (presumably only when > the keys stored in an agent aren't already present in the remote > account). > > Again, i don't think even making the offer to the end user should be > the default behavior (too many people don't understand the > consequences of the known_hosts prompts as it is). But i could see > how it might be nice to allow that as an option. > > However, it's probably implementable with some sort of fancy > combination of ProxyCommand, ControlMaster/Path, and shell if > ssh-copy-id isn't streamlined enough for you. > > For example: ProxyCommand could spawn two processes: process A runs > netcat to remote port 22, and process B extracts your public keys from > your current agent and watches the ControlPath location. Once the > ControlMaster is established properly (and the ControlPath socket is > set up), process B would check (over the socket) if the remote > authorized_keys contains your agent's keys. If not, it would push > them over via something like ssh-copy-id. > > > OpenSSH doesn't want to dictate (and thereby limit) your access > > control policy. Access control administration is left to the > > administrator, which I think makes a lot of sense. > > Unless i'm misunderstanding you, i have to disagree with this. if the > administrator doesn't want the end user using pubkey auth at all, she > should disable it in the sshd config file. If she's allowing pubkey > auth, it's entirely reasonable to allow the end user to set up and > manage his own keys. The initial proposal was one possible mechanism > for a user to handle his own key management. > > --dkg I'd like to add, that surely there's no security impact here. If you can do it manually, all this does is make it more convenient. From darryl at netbauds.net Thu Jan 12 09:15:08 2006 From: darryl at netbauds.net (Darryl L. Miles) Date: Wed, 11 Jan 2006 22:15:08 +0000 Subject: Linux 4.2p1 crash during reverse name lookup In-Reply-To: References: Message-ID: <43C5836C.4040701@netbauds.net> Peter wrote: > Was OpenSSH build on/specifically for the target system? I was building my own version into a location outside of the platforms standard packaging (RPM/YUM) functions and the platforms packages one is disabled. > It doesn't seem to be in OpenSSH, no. The problem system FedoraCore2 is using glibc 2.3.3, I have repeated the same thing on a CentOS4.2 based system using glibc 2.3.4 and > > [pid 4657] stat64("/usr/lib/sse2", 0xbfffd4fc) = -1 ENOENT (No such > > file or directory) > > [pid 4657] open("/usr/lib/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No > > such file or directory) > > [pid 4657] stat64("/usr/lib", 0xbfffd4fc) = -1 ENOENT (No such file or > > directory) > > [pid 4657] --- SIGSEGV (Segmentation fault) @ 0 (0) --- > > This crash is inside the glibc resolver, upgrade glibc would be my > advice. With glibc 2.3.4 not crash but: [pid 13660] stat64("/usr/lib/sse2", 0xbfffcb68) = -1 ENOENT (No such file or directory) [pid 13660] open("/usr/lib/libnss_dns.so.2", O_RDONLY) = -1 ENOENT (No such file or directory) [pid 13660] stat64("/usr/lib", 0xbfffcb68) = -1 ENOENT (No such file or directory) [pid 13660] geteuid32() = 74 [pid 13660] write(3, "\314\24\323b\272\1r]r\363\300\5\337\22\366\212\340\35*\260\25\361\214]\r\200@\37p6\336(!=\0176\250\261\37\0\367\303\207uv&2\n\0\215\337\311-\214-v\312\306\321\233\360\216\374\367\306\243vX\224[\260n4b\22C{\v \r\32\251\340o", 84) = 84 [pid 13660] select(4, [3], NULL, NULL, NULL Thanks for the pointers. -- Darryl L. Miles From ruylopez at engineer.com Wed Jan 11 18:02:56 2006 From: ruylopez at engineer.com (Ruy Lopez) Date: Tue, 10 Jan 2006 23:02:56 -0800 Subject: OpenSSH Installation in Win2k Platform Message-ID: <20060111070256.416B483C0A@ws1-1.us4.outblaze.com> Hi, How can I install the OpenSSH in Windows. When I downloaded the file, there is no .exe. Thanks for your advance help. -- ___________________________________________________ Play 100s of games for FREE! http://games.mail.com/ From jmknoble at pobox.com Thu Jan 12 16:22:48 2006 From: jmknoble at pobox.com (Jim Knoble) Date: Thu, 12 Jan 2006 00:22:48 -0500 Subject: OpenSSH Installation in Win2k Platform In-Reply-To: <20060111070256.416B483C0A@ws1-1.us4.outblaze.com> References: <20060111070256.416B483C0A@ws1-1.us4.outblaze.com> Message-ID: <20060112052248.GG30486@crawfish.ais.com> Circa 2006-01-11 02:02 dixit Ruy Lopez: : How can I install the OpenSSH in Windows. When I downloaded the file, : there is no .exe. You didn't read very far: http://www.openssh.com/windows.html -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 809F:09B9:9686:D035:4AB0::9455:124B:0A62:DD6A:76D6) ..................................................................... :"The methods now being used to merchandise the political candidate : : as though he were a deodorant positively guarantee the electorate : : against ever hearing the truth about anything." --Aldous Huxley : :...................................................................: From dtucker at zip.com.au Thu Jan 12 17:00:18 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 12 Jan 2006 17:00:18 +1100 Subject: Linux 4.2p1 crash during reverse name lookup In-Reply-To: <43C5836C.4040701@netbauds.net> References: <43C5836C.4040701@netbauds.net> Message-ID: <20060112060018.GA7488@gate.dtucker.net> On Wed, Jan 11, 2006 at 10:15:08PM +0000, Darryl L. Miles wrote: > The problem system FedoraCore2 is using glibc 2.3.3, I have repeated > the same thing on a CentOS4.2 based system using glibc 2.3.4 and [it > worked ok] Looks like you've got it sorted, but for the record: it's a bug in glibc that causes a crash when a name service lookup is done and /lib doesn't exist. Normally this isn't a problem but it causes problems when a chroot'ed process does a name lookup. The workaround is to create a /lib dir inside sshd's chroot (/var/empty by default). The real solution is of course to upgrade to a glibc that has the bug fixed. The previous discussion is here: http://marc.theaimsgroup.com/?l=openssh-unix-dev&m=111045930530623 -- 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 paul.moore at centrify.com Fri Jan 13 06:45:27 2006 From: paul.moore at centrify.com (Paul Moore) Date: Thu, 12 Jan 2006 11:45:27 -0800 Subject: PAM auth with disabled user Message-ID: Our test was with 4.1p1 I see that you display a message (if set). But then you proceed to repromt even though the pam module returned a disabled error code. I guess you are saying that the PAM module must tell the user they are disabled. -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: Wednesday, January 11, 2006 1:12 AM To: Paul Moore Cc: openssh-unix-dev at mindrot.org Subject: Re: PAM auth with disabled user On Tue, Jan 10, 2006 at 01:50:52PM -0800, Paul Moore wrote: > Is it intentional that password auth using PAM continues trying to log > on (giving password 3 prompts) in the case that a user is disabled (so > that pam_account returns an error code). > > It can be argued both ways (saying 'you are disabled' is giving out > too much information, making it look like you are entering the wrong > password confuses and frustrates the user) Which version are you looking at? The last couple of versions will send the output from PAM to the client under most conditions, and there are a couple of fixes in the current development version that should fix the remaining cases (those will be in the next release). -- 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 rapier at psc.edu Fri Jan 13 08:31:01 2006 From: rapier at psc.edu (Chris Rapier) Date: Thu, 12 Jan 2006 16:31:01 -0500 Subject: OpenSSH Installation in Win2k Platform In-Reply-To: <20060112052248.GG30486@crawfish.ais.com> References: <20060111070256.416B483C0A@ws1-1.us4.outblaze.com> <20060112052248.GG30486@crawfish.ais.com> Message-ID: <43C6CA95.4050808@psc.edu> If they are looking for an openssh port they should probably go for copssh http://itefix.no/copssh It does run on the cygwin dll but aside from that its 100% OpenSSH Jim Knoble wrote: > Circa 2006-01-11 02:02 dixit Ruy Lopez: > > : How can I install the OpenSSH in Windows. When I downloaded the file, > : there is no .exe. > > You didn't read very far: > > http://www.openssh.com/windows.html > From Bill.Fischer at qwest.com Sat Jan 14 03:32:30 2006 From: Bill.Fischer at qwest.com (Fischer, Bill) Date: Fri, 13 Jan 2006 10:32:30 -0600 Subject: LoginGraceTime Message-ID: <01B031F62986434EACE76AEC21640C23D87D49@QTOMAE2K3M01.AD.QINTRA.COM> Hello, We've found some undesirable behavior with respect to LoginGraceTime. A minor code change in session.c seems to clear it up, but now I'm asking for help in better understanding the problem and determining if there any unexpected side effects of the change. First, the code change: $ diff orig_session.c session.c 216c216,218 < alarm(0); --- > verbose("Clearing alarm in do_authenticated"); > /*alarm(0);*/ > signal(SIGALRM, SIG_IGN); So, I replaced "alarm(0);" in do_authenticated with a call to verbose and a "signal(SIGALRM, SIG_IGN);" Now, the problem description. We are running OpenSSH 4.2p1 on Solaris 8 (Sparc) that has a recent recommended patch cluster installed. When we connect to this server using a variety of ssh clients (including 4.2p1), we noticed that sessions were dropping after about 10 minutes. We changed the LoginGraceTime to 30 seconds and sure enough, sessions were dropping in 30 seconds. We were also seeing messages like: " Timeout before authentication" in /var/adm/messages when the sessions were dropping. Setting LoginGraceTime to 0 (or something like 12 hours) was the leading candidate for a work around. We noticed that if we removed/renamed the ~/.ssh/id_rsa and ~/.ssh/id_rsa files on the client side, the connections would stay up. Similarly, an ssh -i /dev/null allowed the connections to stay up, but that was an ugly solution at best. It didn't matter if the id_[rd]sa keys matched an entry in the authorized_keys2 file on the server. The connections dropped after the GraceLoginTime either way. We'd been working on the problem for 'long enough' (> 60 man hours) and couldn't find anything interesting on google or the archives, so I dug into the code and came up with the possible solution above. After digging into the code a while, I had tried putting "UsePrivilegeSeparation no" in the sshd_conf file and the problem persisted, so I don't think it has anything to do with the privsep code. I can't imagine this effects every Solaris 8 user that has id_[rd]sa files or we would have seen something in our archive/google searches. Perhaps a recent Solaris patch introduced a change in libc? ... but then why does it only break when id_[rs]da files are present on the client side. Questions for you: A) Do you think the code change is a viable solution? There may be well founded reasons to use alarm(0) instead and/or reasons to avoid using signal(SIGALRM, SIG_IGN). Early testing here shows it works (but we haven't tested extensively yet). ... if it appears to be viable, can we get it included in the code base at some point? B) Are any of you willing/able to help us pursue the root cause further? If so, I can provide more configuration in formation. -Bill. From openssh at roumenpetrov.info Sat Jan 14 08:07:27 2006 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Fri, 13 Jan 2006 23:07:27 +0200 Subject: recent(20060106) ssh.1 manual page Message-ID: <43C8168F.600@roumenpetrov.info> Now ssh.1 contain following statement: Public key authentication works as follows: The scheme is based on public-key cryptography, ... using either the RSA or DSA algorithms. Protocol 1 is restricted to using only RSA keys, but protocol 2 may use either. The HISTORY section of ssl(8) contains a brief discussion of the two algorithms. Manual page ssl(8) is OpenBSD specific. Any suggestion how to change ssh.1 in portable ? What about portable ssh.1 to contain a copy of ssl(8) HISTORY section ? Regards, Roumen Petrov From djm at mindrot.org Sat Jan 14 08:35:36 2006 From: djm at mindrot.org (Damien Miller) Date: Sat, 14 Jan 2006 08:35:36 +1100 Subject: LoginGraceTime In-Reply-To: <01B031F62986434EACE76AEC21640C23D87D49@QTOMAE2K3M01.AD.QINTRA.COM> References: <01B031F62986434EACE76AEC21640C23D87D49@QTOMAE2K3M01.AD.QINTRA.COM> Message-ID: <43C81D28.9020302@mindrot.org> Fischer, Bill wrote: > Hello, > > We've found some undesirable behavior with respect to LoginGraceTime. A > minor code change in session.c seems to clear it up, but now I'm asking > for help in better understanding the problem and determining if there > any unexpected side effects of the change. Hi Bill, There have been some changes in this area recently. Could you try one of the snapshot releases at: ftp://ftp3.usa.openbsd.org/pub/OpenBSD/OpenSSH/portable/snapshot an let us know if the problem is still evident? Thanks, Damien Miller From Bill.Fischer at qwest.com Sat Jan 14 09:45:41 2006 From: Bill.Fischer at qwest.com (Fischer, Bill) Date: Fri, 13 Jan 2006 16:45:41 -0600 Subject: LoginGraceTime Message-ID: <01B031F62986434EACE76AEC21640C23D87D65@QTOMAE2K3M01.AD.QINTRA.COM> The code certainly looks different (the line I changed last time is no longer there to change :), but the result seems to be the same. Here's the output from the server: $ /scratch2/openssh-exec/sbin/sshd -f /scratch2/openssh/etc/sshd_config -De Server listening on :: port 66. Server listening on 0.0.0.0 port 66. Generating 768 bit RSA key. RSA key generation complete. Connection from 10.1.1.1 port 33559 Failed none for root from 10.1.1.1 port 33559 ssh2 Found matching RSA key: a7:0d:cf:e0:8a:df:a6:7a:4d:2e:1b:5b:fa:34:b4:85 Postponed publickey for root from 10.1.1.1 port 33559 ssh2 Found matching RSA key: a7:0d:cf:e0:8a:df:a6:7a:4d:2e:1b:5b:fa:34:b4:85 Accepted publickey for root from 10.1.1.1 port 33559 ssh2 Accepted publickey for root from 10.1.1.1 port 33559 ssh2 Timeout before authentication for 10.1.1.1 That's VERBOSE level. The problem doesn't occur in any of the DEBUG levels since the login timer is disabled when in debug mode. If the debug output would be helpful, I could change the code to enable the timeout when in debug mode. The connection still works fine if I rename the id_[rd]sa* files in ~/.ssh on the client side. For what it's worth, adding a call to verbose in the authenticated: block of sshd.c shows that the authenticated: block is indeed getting executed. And adding a signal(SIGALRM, SIG_IGN) will cause the connection to remain up, but of course means all future SIGALRM's will be ignored, which may be less than desirable and if you ever need to set up another SIGALRM, that would almost certainly be bad news. Sure seems like the system is flat our ignoring the alarm(0) call. Not sure where else to look. -Bill. -----Original Message----- From: Damien Miller [mailto:djm at mindrot.org] Sent: Friday, January 13, 2006 3:36 PM To: Fischer, Bill Cc: openssh-unix-dev at mindrot.org Subject: Re: LoginGraceTime Fischer, Bill wrote: > Hello, > > We've found some undesirable behavior with respect to LoginGraceTime. > A minor code change in session.c seems to clear it up, but now I'm > asking for help in better understanding the problem and determining if > there any unexpected side effects of the change. Hi Bill, There have been some changes in this area recently. Could you try one of the snapshot releases at: ftp://ftp3.usa.openbsd.org/pub/OpenBSD/OpenSSH/portable/snapshot an let us know if the problem is still evident? Thanks, Damien Miller From dtucker at zip.com.au Sat Jan 14 12:18:08 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 14 Jan 2006 12:18:08 +1100 Subject: recent(20060106) ssh.1 manual page In-Reply-To: <43C8168F.600@roumenpetrov.info> References: <43C8168F.600@roumenpetrov.info> Message-ID: <20060114011808.GA13790@gate.dtucker.net> On Fri, Jan 13, 2006 at 11:07:27PM +0200, Roumen Petrov wrote: > Now ssh.1 contain following statement: > > Public key authentication works as follows: The scheme is based on > public-key cryptography, ... using either the RSA or DSA algorithms. > Protocol 1 is restricted to using only RSA keys, but protocol 2 may > use either. The HISTORY section of ssl(8) contains a brief discussion > of the two algorithms. > > Manual page ssl(8) is OpenBSD specific. > Any suggestion how to change ssh.1 in portable ? > What about portable ssh.1 to contain a copy of ssl(8) HISTORY section ? Maybe just a cut-down version of it? The discussion of SSL/TLS implementations doesn't add much value to ssh(1). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Sat Jan 14 12:26:25 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 14 Jan 2006 12:26:25 +1100 Subject: PAM auth with disabled user In-Reply-To: References: Message-ID: <20060114012625.GC13790@gate.dtucker.net> On Thu, Jan 12, 2006 at 11:45:27AM -0800, Paul Moore wrote: > Our test was with 4.1p1 > > I see that you display a message (if set). But then you proceed to > repromt even though the pam module returned a disabled error code. > > I guess you are saying that the PAM module must tell the user they are > disabled. Yes. As a general rule, sshd tries to give the client no indication as to why an authentication failed. If you want to PAM to provide some information to the client then you can, but you need to configure PAM to do so. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Sat Jan 14 13:47:30 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 14 Jan 2006 13:47:30 +1100 Subject: PAM auth with disabled user In-Reply-To: References: Message-ID: <20060114024730.GA14820@gate.dtucker.net> On Fri, Jan 13, 2006 at 05:47:22PM -0800, Paul Moore wrote: > BTW it is our PAM module. > > I guess you are saying that the PAM module should have a config choice > to say 'generate chatty failure messages'. > > We then end up with > > User: joe > Password :xxxxxxx > Your account is disabled please contact your system administrator > Password: Ah, I see what you're referring to now. That occurs because currently the kbdint code does not distinguish between "authentication failed" (which should be retryable) and "account check failed" (which shouldn't). The non-kbdint code will terminate the connection after the pam_acct_mgmt() fails. The kbdint code doesn't, since it can do pam_chauthtok() via keyboard-interactive, so it needs to learn to treat "account check failed" differently. If you use PasswordAuthentication instead (assuming your module can work with it) then I think you'll get the behaviour you want (although with 4.1p1 you may see the "missing PAM messages" thing I mentioned earlier, if you see that then try a snapshot). > It can of course be argued that sshd should have the config choice > 'explain rejection reasons'. Since the pam_account returns 'account > locked' status you know what to say. The nice things about doing it that > way is We're not going to add another knob to sshd for this but we can fix the kbdint thing above so it's consistent with the behaviour for the other auth types. It should then do what you want, right? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Sat Jan 14 14:15:18 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 14 Jan 2006 14:15:18 +1100 Subject: PAM auth with disabled user In-Reply-To: <20060114024730.GA14820@gate.dtucker.net> References: <20060114024730.GA14820@gate.dtucker.net> Message-ID: <20060114031518.GA25815@gate.dtucker.net> On Sat, Jan 14, 2006 at 01:47:30PM +1100, Darren Tucker wrote: [...] > We're not going to add another knob to sshd for this but we can fix the > kbdint thing above so it's consistent with the behaviour for the other > auth types. It should then do what you want, right? Please try this patch on top of a current snapshot. It's pretty ugly but seems to work. Hopefully there's a nicer way... Index: auth-pam.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth-pam.c,v retrieving revision 1.127 diff -u -p -r1.127 auth-pam.c --- auth-pam.c 28 Sep 2005 12:33:27 -0000 1.127 +++ auth-pam.c 14 Jan 2006 03:12:19 -0000 @@ -439,8 +439,8 @@ sshpam_thread(void *ctxtp) goto auth_fail; if (compat20) { - if (!do_pam_account()) - goto auth_fail; + do_pam_account(); + sshpam_err = PAM_SUCCESS; if (sshpam_authctxt->force_pwchange) { sshpam_err = pam_chauthtok(sshpam_handle, PAM_CHANGE_EXPIRED_AUTHTOK); -- 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 paul.moore at centrify.com Sat Jan 14 12:47:22 2006 From: paul.moore at centrify.com (Paul Moore) Date: Fri, 13 Jan 2006 17:47:22 -0800 Subject: PAM auth with disabled user Message-ID: BTW it is our PAM module. I guess you are saying that the PAM module should have a config choice to say 'generate chatty failure messages'. We then end up with User: joe Password :xxxxxxx Your account is disabled please contact your system administrator Password: Which just looks stupid It can of course be argued that sshd should have the config choice 'explain rejection reasons'. Since the pam_account returns 'account locked' status you know what to say. The nice things about doing it that way is A) I don't have to write any code B) You can be systematic about it (lets say you decide for some non PAM reason to bounce a user - like the user does not exist) C) For non retryable errors (like locked) you can stop prompting (so we don't get the stupidness above) -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: Friday, January 13, 2006 5:26 PM To: Paul Moore Cc: dtucker at zip.com.au; openssh-unix-dev at mindrot.org Subject: Re: PAM auth with disabled user On Thu, Jan 12, 2006 at 11:45:27AM -0800, Paul Moore wrote: > Our test was with 4.1p1 > > I see that you display a message (if set). But then you proceed to > repromt even though the pam module returned a disabled error code. > > I guess you are saying that the PAM module must tell the user they are > disabled. Yes. As a general rule, sshd tries to give the client no indication as to why an authentication failed. If you want to PAM to provide some information to the client then you can, but you need to configure PAM to do so. -- 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 ossi at kde.org Sun Jan 15 00:14:05 2006 From: ossi at kde.org (Oswald Buddenhagen) Date: Sat, 14 Jan 2006 14:14:05 +0100 Subject: SSO, *-agent & PAM Message-ID: <20060114131405.GA7257@ugly.local> moin *, sorry for the cross-post; follow-ups should go to xdg@ (the only one of those lists i'm subscribed to). i'm pondering with the idea to implement SingleSignOn based on an authentication agent like the ones employed by ssh and gnupg. the system would consist of the two main components: - fdo-keyagent, certainly a d-bus service - pam_keyagent. a PAM module that would authenticate users by unlocking their key(s) (which one(s), has to be preconfigured somehow - ~/.config/keyagent maybe?) and adding them to the agent's cache. - it might make sense to create libkeyagent that would provide functions for key retrieval, etc. i'm not sure whether it would be better to embed ssh-add's equivalent into the agent or into such a library. the key agent would send notifications when keys exceed their lifetime. in fact, this is a major missing component of PAM. in this context it might even make sense to create meta-entries for kerberos tokens and even unix passwords (with close relation to pam_time/pam_group). end-user/desktop applications (password managers, ssh, gpg, etc.) would use the keys stored in the agent - obviously. a buzz word that comes to mind is x.509 compliance, but i really have no idea what that would include. as far as security goes, i really need some input. possible concerns: - having a central agent for all users might be frowned upon. one could make the agent fork a sub-agent for each user, but this would require some elaborate IPC. plan b is to make fdo-keyagent a meta-agent that would spawn ssh-agents, gpg-agents, etc. on demand, ref-count them and do other housekeeping. even more "interesting" IPC. - apps using PAM traditionally have been bad at using mlock, and i wouldn't know how to fix this. what do the security experts think about this issue? - having the d-bus daemon in between doesn't exactly help, either. maybe it would make sense to use d-bus for the protocol only and setup dedicated connections for passphrase and key transfers. i'm interested in any kind of useful comments, including pointers to prior art in that area and papers worth reading. -- Hi! I'm a .signature virus! Copy me into your ~/.signature, please! -- Chaos, panic, and disorder - my work here is done. From martin.konold at erfrakon.de Tue Jan 17 01:07:26 2006 From: martin.konold at erfrakon.de (Martin Konold) Date: Mon, 16 Jan 2006 15:07:26 +0100 Subject: SSO, *-agent & PAM In-Reply-To: <20060114131405.GA7257@ugly.local> References: <20060114131405.GA7257@ugly.local> Message-ID: <200601161507.28921.martin.konold@erfrakon.de> Am Samstag, 14. Januar 2006 14:14 schrieb Oswald Buddenhagen: Hi, > i'm interested in any kind of useful comments, including pointers to > prior art in that area and papers worth reading. You may check kwallet and GPG pinentry. Sofar I was unable to convince the GPG developers to use a single SSO keyring application. Regards, -- martin -- http://www.erfrakon.com/ Erlewein, Frank, Konold & Partner - Beratende Ingenieure und Physiker From yusuke at cs.nyu.edu Tue Jan 17 05:03:39 2006 From: yusuke at cs.nyu.edu (Yusuke Shinyama) Date: Mon, 16 Jan 2006 13:03:39 -0500 Subject: LocalCommand problem for tunneling on Linux Message-ID: <20060116180339.23641.6714.yusuke@grape.cs.nyu.edu> I've been testing tunneling on Linux with openssh-SNAP-20060116.tar.gz and found a problem. When I use LocalCommand for doing ifconfig stuff, the command line was executed before a tunneling interface is opened. This causes errors on Linux and the interface is not automatically set up. This is not a problem on *BSD because you can do ifconfig for unopened tun/tap interfaces. But in Linux, you need to open it first. A possible solution seems to have ssh_local_cmd() executed in ssh_session2_setup(). Thank you, Yusuke From openssh at roumenpetrov.info Tue Jan 17 08:32:59 2006 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Mon, 16 Jan 2006 23:32:59 +0200 Subject: man pages (20060116) Message-ID: <43CC110B.4030602@roumenpetrov.info> Hi all, The file ~/.ssh/environment is used by ssh daemon. Since sshd sets up basic environment I guess that sentences in ssh(1) that reference the file ~/.ssh/environment and environment variables should be moved to sshd(8). Wim, could you check why anonymous CVS require password, please? Regards, Roumen Petrov From yusuke at cs.nyu.edu Tue Jan 17 11:26:20 2006 From: yusuke at cs.nyu.edu (Yusuke Shinyama) Date: Mon, 16 Jan 2006 19:26:20 -0500 Subject: [PATCH] Re: LocalCommand problem for tunneling on Linux In-Reply-To: <20060116180339.23641.6714.yusuke@grape.cs.nyu.edu> References: <20060116180339.23641.6714.yusuke@grape.cs.nyu.edu> Message-ID: <20060117002620.4540.39712.yusuke@mango.cs.nyu.edu> Yusuke Shinyama wrote: > I've been testing tunneling on Linux with openssh-SNAP-20060116.tar.gz > and found a problem. > > When I use LocalCommand for doing ifconfig stuff, the command line > was executed before a tunneling interface is opened. This causes > errors on Linux and the interface is not automatically set up. > > This is not a problem on *BSD because you can do ifconfig for > unopened tun/tap interfaces. But in Linux, you need to open it first. > > A possible solution seems to have ssh_local_cmd() executed > in ssh_session2_setup(). I made a quick patch for it. This is against openssh-SNAP-20060116.tar.gz. It is a bit ugly as the local command execution part is duplicated in another function. Thanks Yusuke ---------------------------------------------------------------- *** ssh.c.orig Mon Jan 16 19:19:10 2006 --- ssh.c Mon Jan 16 19:17:13 2006 *************** *** 1095,1100 **** --- 1095,1105 ---- } } + /* Execute a local command */ + if (options.local_command != NULL && + options.permit_local_command) + ssh_local_cmd(options.local_command); + client_session2_setup(id, tty_flag, subsystem_flag, getenv("TERM"), NULL, fileno(stdin), &command, environ, &ssh_subsystem_reply); *************** *** 1156,1167 **** ssh_init_forwarding(); ssh_control_listener(); if (!no_shell_flag || (datafellows & SSH_BUG_DUMMYCHAN)) id = ssh_session2_open(); ! ! /* Execute a local command */ ! if (options.local_command != NULL && ! options.permit_local_command) ssh_local_cmd(options.local_command); /* If requested, let ssh continue in the background. */ --- 1161,1173 ---- ssh_init_forwarding(); ssh_control_listener(); + /* If a session is going to open, a local command will be + * executed within it. */ if (!no_shell_flag || (datafellows & SSH_BUG_DUMMYCHAN)) id = ssh_session2_open(); ! /* Otherwise execute a local command now */ ! else if (options.local_command != NULL && ! options.permit_local_command) ssh_local_cmd(options.local_command); /* If requested, let ssh continue in the background. */ ---------------------------------------------------------------- From wim at kd85.com Tue Jan 17 10:15:41 2006 From: wim at kd85.com (Wim Vandeputte) Date: Tue, 17 Jan 2006 00:15:41 +0100 Subject: man pages (20060116) In-Reply-To: <43CC110B.4030602@roumenpetrov.info> References: <43CC110B.4030602@roumenpetrov.info> Message-ID: <20060116231541.GB18312@togetic.kd85.com> hey, I've temporarely disabled the ssh access until I'm able to upgrade the machine. This might take 2 more months Sorry On Mon, Jan 16, 2006 at 11:32:59PM +0200, Roumen Petrov wrote: > Hi all, > > The file ~/.ssh/environment is used by ssh daemon. > Since sshd sets up basic environment I guess that sentences > in ssh(1) that reference the file ~/.ssh/environment and > environment variables should be moved to sshd(8). > > > Wim, > could you check why anonymous CVS require password, please? > > > Regards, > Roumen Petrov -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= https://kd85.com/notforsale.html -- From pekkas at netcore.fi Tue Jan 17 21:03:22 2006 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 17 Jan 2006 12:03:22 +0200 (EET) Subject: openssh@anoncvs.at.openbsd.org asks for password Message-ID: Hi, The portable R/O CVS repository, openssh at anoncvs.at.openbsd.org, has started asking for password, and this has lasted for about 3-5 days at least. Is something wrong there? -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From Philippe.LeGal at emea.eu.int Wed Jan 18 01:44:12 2006 From: Philippe.LeGal at emea.eu.int (Le Gal Philippe) Date: Tue, 17 Jan 2006 14:44:12 -0000 Subject: OpenSSH, Radius, PAM & NOUSER issue Message-ID: Hi ! Sorry to bring back the infamous "NOUSER" in the conversation but I didn't get the workaround on that problem. Firstly, I'm using : - openssh-3.1p1-15 which is the version which comes by default with my Red Hat Linux Advanced Server release 2.1AS. - I'm using PAM, set up to use radius. Please find below the /etc/pam.d/sshd file : #%PAM-1.0 auth sufficient /lib/security/pam_radius_auth.so auth required /lib/security/pam_stack.so service=system-auth auth required /lib/security/pam_nologin.so account required /lib/security/pam_stack.so service=system-auth password required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_stack.so service=system-auth session required /lib/security/pam_limits.so session optional /lib/security/pam_console.so - I'm using the FreeRadius server. It is up and running in debug mode (see output below) I'm trying to connect to this server using ssh : ssh test at machine_of_the_test The login name I used is : test passwd : test - This is my var/log/messages : Jan 16 19:34:59 machine_of_the_test sshd(pam_unix)[17647]: check pass; user unknown Jan 16 19:34:59 machine_of_the_test sshd(pam_unix)[17647]: authentication failure; logname= uid=0 euid=0 tty=NODEVssh ruser= rhost=192.168.60.76 - This is the request coming to the radius server. As you can see Username is "NOUSER" rad_recv: Access-Request packet from host 172.16.zzz.xxx:18299, id=22, length=91 User-Name = "NOUSER" User-Password = "test" NAS-IP-Address = 127.0.0.1 NAS-Identifier = "sshd" NAS-Port = 17274 NAS-Port-Type = Virtual Service-Type = Authenticate-Only Calling-Station-Id = "192.168.xxx.xxx" How can I solve this ? I want sshd to pass on to PAM the real username if it is not found is /etc/passwd and not the fake username "NOUSER". How do I do that ? I have more than 100 servers to administrate. I need an (very) easy way to do it ! Merci for your help ! Philippe Email: Philippe.LeGal at emea.eu.int ________________________________________________________________________ This e-mail has been scanned for all known viruses by EMEA. ________________________________________________________________________ From fcusack at fcusack.com Wed Jan 18 14:24:17 2006 From: fcusack at fcusack.com (Frank Cusack) Date: Tue, 17 Jan 2006 19:24:17 -0800 Subject: OpenSSH, Radius, PAM & NOUSER issue In-Reply-To: References: Message-ID: <6357D0167CA2D85FF761E528@manatee.local> On January 17, 2006 2:44:12 PM +0000 Le Gal Philippe wrote: > How can I solve this ? Upgrade. -frank From Philippe.LeGal at emea.eu.int Wed Jan 18 22:32:35 2006 From: Philippe.LeGal at emea.eu.int (Le Gal Philippe) Date: Wed, 18 Jan 2006 11:32:35 -0000 Subject: OpenSSH, Radius, PAM & NOUSER issue Message-ID: Cheers Frank, Which OpenSsh version will solve that problem ? cheers Philippe -----Original Message----- From: Frank Cusack [mailto:fcusack at fcusack.com] Sent: 18 January 2006 03:24 To: Le Gal Philippe; openssh-unix-dev at mindrot.org Subject: RE: OpenSSH, Radius, PAM & NOUSER issue On January 17, 2006 2:44:12 PM +0000 Le Gal Philippe wrote: > How can I solve this ? Upgrade. -frank ________________________________________________________________________ This e-mail has been scanned for all known viruses by EMEA. ________________________________________________________________________ From senthilkumar_sen at hotpop.com Thu Jan 19 14:29:04 2006 From: senthilkumar_sen at hotpop.com (Senthil Kumar) Date: Thu, 19 Jan 2006 08:59:04 +0530 Subject: OpenSSH 4.0 p1 and zlib vulnerability Message-ID: Hi, Im using OpenSSH 4.0 p1 linked with zlib version less then 1.2.2 in a number of systems. These are all production systems where I can't upgrade the service. I have a question that if I disable the compression by setting "compression no" in sshd_config, will I be able to overcome the Buffer overflow vulnerability in zlib. I just glanced through the code and it seems sshd is not affected if "compression no" is set. I would like to get inputs from the list. Thanks, Senthil Kumar. From djm at mindrot.org Thu Jan 19 16:45:34 2006 From: djm at mindrot.org (Damien Miller) Date: Thu, 19 Jan 2006 16:45:34 +1100 (EST) Subject: OpenSSH 4.0 p1 and zlib vulnerability In-Reply-To: References: Message-ID: On Thu, 19 Jan 2006, Senthil Kumar wrote: > Hi, > > Im using OpenSSH 4.0 p1 linked with zlib version less then 1.2.2 in a number > of systems. These are all production systems where I can't upgrade the > service. I have a question that if I disable the compression by setting > "compression no" in sshd_config, will I be able to overcome the Buffer > overflow vulnerability in zlib. I just glanced through the code and it seems > sshd is not affected if "compression no" is set. I would like to get inputs > from the list. Yes, but you should disable compression for the clients too so they are not subject to attacks from hostile servers. OpenSSH 4.2 or greater supports the "zlib at openssh.com" method. This is safe against pre-authentication attacks on the zlib code and therefore (if used with privsep) means that even a valid but hostile user cannot use zlib bugs to escalate privilege. -d From vinschen at redhat.com Thu Jan 19 21:18:28 2006 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 19 Jan 2006 11:18:28 +0100 Subject: Question about d_ino used in scp.c Message-ID: <20060119101828.GL8318@calimero.vinschen.de> Hi, There's exactly one usage of the dirent.d_ino member in the whole project, which is in the readdir loop in scp.c, like this: while (readdir) { if (d_ino == 0) continue; [...] } This loop is basically taken from rcp.c as far as I can see. However, I have two problems here. - First, I have no idea why and when readdir should return an entry with a 0 inode number. Is that historically? - Second, POSIX does not demand the existence of the d_ino member in dirent. Only systems which claim to be X/Open compatible are required to have the d_ino member in dirent. See http://www.opengroup.org/onlinepubs/009695399/basedefs/dirent.h.html and http://www.opengroup.org/onlinepubs/009695399/basedefs/xbd_chap02.html#tag_02_01_04 Since it's fairly tricky and time consuming to generate the correct inode number when running the Windows equivalent of readdir, the d_ino entry was faked in Cygwin by using a name hash for a long time now. The problem is that this doesn't match the inode number returned by the Windows equivalent of the stat function, which can result in some applications creating dubious error messages. So, after some wailing and chattering we're now trying to get rid of the d_ino field entirely, since we're not trying to be X/Open compatible. We would already be happy to be POSIX compliant :-} The question now is this. Is the above test for a 0 inode number still required or is that something long gone? And, if it's still required, would it be ok to disable the test for system which are not X/Open compatible, either by using some define (_XOPEN_UNIX ?), or by adding a configure test for d_ino? Thanks in advance, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From Richard.Dickens at reuters.com Thu Jan 19 23:24:19 2006 From: Richard.Dickens at reuters.com (Richard Dickens) Date: Thu, 19 Jan 2006 12:24:19 +0000 Subject: Only one chance to enter a new password? Message-ID: Hello there, We are using OpenSSH_3.9p1, OpenSSL 0.9.7d 17 Mar 2004 on various Solaris boxes with PAM and an LDAP server back end. Recently we have added a requirement for users to have complex passwords. The problem is, if a user's password has expired, when they log in they are prompted for a new password (good) but if they enter a non-complex new password the session is closed rather than reprompting them for another try. With some PC clients they see nothing which is causing a lot of support calls... Here's the PAM configuration if that matters: sshd auth requisite pam_authtok_get.so.1 sshd auth required pam_dhkeys.so.1 sshd auth sufficient pam_unix_auth.so.1 server_policy sshd auth required pam_ldap.so.1 try_first_pass Is they any way to reprompt the user for another password? Regards, Richard Dickens To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. From han at mijncomputer.nl Fri Jan 20 03:06:11 2006 From: han at mijncomputer.nl (Han Boetes) Date: Thu, 19 Jan 2006 17:06:11 +0100 Subject: ownership of authorized_keys Message-ID: <20060119160634.GB22122@boetes.org> Hi, I would like to make it impossible for users to change the contents of the authorized_keys-file. I just found out about the sshd_config setting: AuthorizedKeysFile /etc/ssh/authorized_keys/%u But even in that case that file has to be owned by the user, unless I set ``StrictModes no'' which would allow other nastyness. I would like to request that that file could also be owned by root, so I can make that file immutable for the user, even on filesystems which don't support the immutable flag, for example jfs on GNU/Linux. # Han -- \ / The two things that can get you into trouble quicker than )\__/( anything else are fast women and slow horses. |(oO)| \||/ Ts (OO) +vVv------vVv----------------------------------------------------------+ From imorgan at nas.nasa.gov Fri Jan 20 04:09:26 2006 From: imorgan at nas.nasa.gov (Iain Morgan) Date: Thu, 19 Jan 2006 09:09:26 -0800 (PST) Subject: ownership of authorized_keys In-Reply-To: <20060119160634.GB22122@boetes.org> from "Han Boetes" at Jan 19, 2006 05:06:11 PM Message-ID: <200601191709.k0JH9RvK022835@sun601.nas.nasa.gov> On Thu Jan 19 08:06:11 2006, Han Boetes wrote: > > Hi, > > I would like to make it impossible for users to change the > contents of the authorized_keys-file. > > I just found out about the sshd_config setting: > > AuthorizedKeysFile /etc/ssh/authorized_keys/%u > > But even in that case that file has to be owned by the user, > unless I set ``StrictModes no'' which would allow other > nastyness. I would like to request that that file could also be > owned by root, so I can make that file immutable for the user, > even on filesystems which don't support the immutable flag, for > example jfs on GNU/Linux. > That's already the case. The files can be owned by root, but they must be readable by the user. Either use a per-user group or POSIX ACLs to allow the user to read the contents. -- Iain Morgan From f_mohr at yahoo.de Fri Jan 20 04:16:03 2006 From: f_mohr at yahoo.de (frank mohr) Date: Thu, 19 Jan 2006 09:16:03 -0800 (PST) Subject: ownership of authorized_keys In-Reply-To: <20060119160634.GB22122@boetes.org> Message-ID: <20060119171603.20301.qmail@web25704.mail.ukl.yahoo.com> Hi --- Han Boetes wrote: > But even in that case that file has to be owned by the user, > unless I set ``StrictModes no'' which would allow other > nastyness. I would like to request that that file could also be > owned by root, so I can make that file immutable for the user, > even on filesystems which don't support the immutable flag, for > example jfs on GNU/Linux. just checked the 4.1p1 source .. thats already there: auth.c(line 460): (st.st_uid != 0 && st.st_uid != uid) checks for root or user frank __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From sudhakar at motorola.com Fri Jan 20 04:53:35 2006 From: sudhakar at motorola.com (KRISHNAMURTHY SUDHAKAR-FSK031) Date: Thu, 19 Jan 2006 11:53:35 -0600 Subject: CopSSH changes directory permission Message-ID: Hi, I am seeing a strange behavior on windows XP pro with CopSSH installed. Every time I run the activate.sh and create a ssh account and subsequently when attempted to delete the folder or any files in the folder windows doesn't seem to allow any change to the directory. To fill in some background info here's what I am doing. I am changing the root directory for the SSH user by changing the registry key right after installation. Then I am activating a user using the activate.sh script. Running this script somehow seems to be changing the permissions of the directory and all the files in the directory. I even tried uninstalling and attempted to delete the folder/files but I keep getting this error message "Access denied" the standard windows error msg. In spite of being the administrator of the box I am unable to delete this. Has anyone seen this issue. It would be of great help if someone can tell me what is going on here and how can I avoid this in the future. TIA Sud From markus.r.friedl at arcor.de Fri Jan 20 04:25:50 2006 From: markus.r.friedl at arcor.de (Markus Friedl) Date: Thu, 19 Jan 2006 18:25:50 +0100 Subject: ownership of authorized_keys In-Reply-To: <20060119160634.GB22122@boetes.org> References: <20060119160634.GB22122@boetes.org> Message-ID: <20060119172550.GB31106@folly> no, it can be owned by root. On Thu, Jan 19, 2006 at 05:06:11PM +0100, Han Boetes wrote: > Hi, > > I would like to make it impossible for users to change the > contents of the authorized_keys-file. > > I just found out about the sshd_config setting: > > AuthorizedKeysFile /etc/ssh/authorized_keys/%u > > But even in that case that file has to be owned by the user, > unless I set ``StrictModes no'' which would allow other > nastyness. I would like to request that that file could also be > owned by root, so I can make that file immutable for the user, > even on filesystems which don't support the immutable flag, for > example jfs on GNU/Linux. > > > > > # Han > -- > \ / The two things that can get you into trouble quicker than > )\__/( anything else are fast women and slow horses. > |(oO)| > \||/ > Ts (OO) > +vVv------vVv----------------------------------------------------------+ > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From rapier at psc.edu Fri Jan 20 06:48:26 2006 From: rapier at psc.edu (Chris Rapier) Date: Thu, 19 Jan 2006 14:48:26 -0500 Subject: CopSSH changes directory permission In-Reply-To: References: Message-ID: <43CFED0A.3070003@psc.edu> I hate just passing people to other communities but this might not be the right forum for this question. The CopSSH discussion forum can be found at ssh at erdelynet.com. They might have a much better idea on the details of how SSH specifically interacts in the XP environment. Its probably best to rule out anything on that side of the fence first. Good luck KRISHNAMURTHY SUDHAKAR-FSK031 wrote: > Hi, > I am seeing a strange behavior on windows XP pro with CopSSH installed. > Every time I run > the activate.sh and create a ssh account and subsequently when attempted > to delete the folder or any files in the folder windows doesn't seem to > allow any change to the directory. > > To fill in some background info here's what I am doing. I am changing > the root directory for the SSH user by changing the registry key right > after installation. > Then I am activating a user using the activate.sh script. Running this > script somehow seems to be changing the permissions of the directory and > all the files in the directory. > > I even tried uninstalling and attempted to delete the folder/files but I > keep getting this error message "Access denied" the standard windows > error msg. In spite of being the administrator of the box I am unable to > delete this. > > Has anyone seen this issue. It would be of great help if someone can > tell me what is going on here and how can I avoid this in the future. > > > TIA > Sud > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From han at mijncomputer.nl Fri Jan 20 07:16:25 2006 From: han at mijncomputer.nl (Han Boetes) Date: Thu, 19 Jan 2006 21:16:25 +0100 Subject: ownership of authorized_keys In-Reply-To: <200601191709.k0JH9RvK022835@sun601.nas.nasa.gov> References: <20060119160634.GB22122@boetes.org> <200601191709.k0JH9RvK022835@sun601.nas.nasa.gov> Message-ID: <20060119201648.GG22122@boetes.org> Iain Morgan wrote: > On Thu Jan 19 08:06:11 2006, Han Boetes wrote: > > I would like to make it impossible for users to change the > > contents of the authorized_keys-file. > > > > I just found out about the sshd_config setting: > > > > AuthorizedKeysFile /etc/ssh/authorized_keys/%u > > > > But even in that case that file has to be owned by the user, > > unless I set ``StrictModes no'' which would allow other > > nastyness. I would like to request that that file could also > > be owned by root, so I can make that file immutable for the > > user, even on filesystems which don't support the immutable > > flag, for example jfs on GNU/Linux. > > That's already the case. The files can be owned by root, but > they must be readable by the user. Either use a per-user group > or POSIX ACLs to allow the user to read the contents. Thanks, that can be done. # Han -- _ Is this foreplay? No, this is Nuke Strike. Foreplay has lousy _V.-o graphics. Beat me again. -- Duckert, in Bad Rubber, Albedo #0 / |`-' (comics) (7_\\ From dtucker at zip.com.au Fri Jan 20 13:33:40 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 20 Jan 2006 13:33:40 +1100 Subject: Only one chance to enter a new password? In-Reply-To: References: Message-ID: <20060120023340.GA18063@gate.dtucker.net> On Thu, Jan 19, 2006 at 12:24:19PM +0000, Richard Dickens wrote: > We are using OpenSSH_3.9p1, OpenSSL 0.9.7d 17 Mar 2004 on various > Solaris boxes with PAM and an LDAP server back end. > > Recently we have added a requirement for users to have complex > passwords. The problem is, if a user's password has expired, when they > log in they are prompted for a new password (good) but if they enter a > non-complex new password the session is closed rather than reprompting > them for another try. With some PC clients they see nothing which is > causing a lot of support calls... How does 4.2p1 (or better, a current snapshot) behave with regard to this? There were several changes in that area since 3.9. > Is they any way to reprompt the user for another password? Depends on exactly what's going on. Can you post the output from the client while this is going on? (ssh -vvv yourserver) -- 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 august at chalmers.se Fri Jan 20 23:17:22 2006 From: august at chalmers.se (=?iso-8859-1?Q?Bj=F6rn?= Augustsson) Date: Fri, 20 Jan 2006 13:17:22 +0100 Subject: Bug: Copying several files to non-directory. Message-ID: <20060120121722.GD6245@chalmers.se> Dear openssh people, Here's something to try: $ echo a >a $ echo b >b $ echo c >c $ $ scp a b c $ $ echo $? 1 $ cat a b c a b b Ouch! Also, for comparison: $ cp a b c cp: copying multiple files, but last argument `c' is not a directory Try `cp --help' for more information. $ rcp a b c rcp: c: Not a directory. $ Note that the cp behavior is specified in SuSv2. (http://www.opengroup.org/onlinepubs/007908799/xcu/cp.html, "Second synopsis") Also, and this might be a separate bug, note how openssh exits with return code of 1. This was verified using various versions of scp from 3.6.1p2 to 4.2, on linux (various versions) and openbsd. /August. -- Bj?rn Augustsson Sysadmin IT Systems & Services Chalmers tekniska h?gskola Chalmers University of Technology "Damn spooky analog crap." -- John Carmack. From f_mohr at yahoo.de Sat Jan 21 00:43:57 2006 From: f_mohr at yahoo.de (Frank Mohr) Date: Fri, 20 Jan 2006 14:43:57 +0100 Subject: ownership of authorized_keys (different question) Message-ID: <43D0E91D.70303@yahoo.de> that "ownership of authorized_keys" question remembered be of a problem we had end of last year. we have some accounts where the user places files to process in the home directory (by scp/sftp), a process running as a diffent user processes those files and puts the results back to the users homedir. the homedir belongs to the user and the other users group with rw access for the user and the group and the sticky bit set. the current openssh versions complains about "bad ownership or modes for directory" for the group write bit. (had to turn off strict mode) i was thinking about changing auth.c to check for the sticky bit, if other/group write bits are set for the directory and allow that in strict mode. Would that open any security wholes i didn't think of ? frank ___________________________________________________________ Telefonate ohne weitere Kosten vom PC zum PC: http://messenger.yahoo.de From Philippe.LeGal at emea.eu.int Sat Jan 21 02:03:43 2006 From: Philippe.LeGal at emea.eu.int (Le Gal Philippe) Date: Fri, 20 Jan 2006 15:03:43 -0000 Subject: openssh-4.2p1 + Pam question ! Message-ID: Hi there ! I have an issue with my OpenSSH + PAM configuration on a RedHat Advanced server 2..1 I want to authenticate users connecting to a server using ssh against a radius server. The radius client/server part works ok when I test it with some utilities. I think I have a problem with my ssh which does not pass the username/password to my pam sshd module. I have upgraded to openssh-4.2p1. Please find thereafter the sshd_config as well as my pam conf file, I try to authenticate with user name which is NOT in my /etc/passwd (authentication will be made by the radius server), ie : ssh test at myserver. Jan 20 14:54:32 us067 sshd(pam_unix)[31601]: check pass; user unknown Jan 20 14:54:32 us067 sshd(pam_unix)[31601]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.60.76 Jan 20 14:54:34 us067 sshd[31599]: error: PAM: Authentication failure for illegal user test from 192.168.60.76 Jan 20 14:54:34 us067 sshd[31599]: Failed keyboard-interactive/pam for invalid user test from 192.168.60.76 port 4397 ssh2 is there a way of telling sshd to pass the username and password directly to PAm without interfering with it ? Thank you for your precious help ! Philippe less /etc/pam.d/sshd #%PAM-1.0 auth sufficient /lib/security/pam_radius_auth.so debug auth required /lib/security/pam_stack.so service=system-auth auth required /lib/security/pam_nologin.so account sufficient /lib/security/pam_radius_auth.so password sufficient /lib/security/pam_radius_auth.so session required /lib/security/pam_limits.so session optional /lib/security/pam_console.so # $OpenBSD: sshd_config,v 1.72 2005/07/25 11:59:40 markus Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options change a # default value. #Port 22 #Protocol 2,1 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: # HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_dsa_key # Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 1h #ServerKeyBits 768 # Logging # obsoletes QuietMode and FascistLogging #SyslogFacility AUTH #LogLevel INFO # Authentication: #LoginGraceTime 2m #PermitRootLogin yes #StrictModes yes #MaxAuthTries 6 #RSAAuthentication yes #PubkeyAuthentication yes #AuthorizedKeysFile .ssh/authorized_keys # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #RhostsRSAAuthentication no # similar for protocol version 2 #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # To disable tunneled clear text passwords, change to no here! PasswordAuthentication no #PermitEmptyPasswords no # Change to no to disable s/key passwords #ChallengeResponseAuthentication yes # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication mechanism. # Depending on your PAM configuration, this may bypass the setting of # PasswordAuthentication, PermitEmptyPasswords, and # "PermitRootLogin without-password". If you just want the PAM account and # session checks to run without PAM authentication, then enable this but set # ChallengeResponseAuthentication=no UsePAM yes #AllowTcpForwarding yes #GatewayPorts no #X11Forwarding no #X11DisplayOffset 10 #X11UseLocalhost yes #PrintMotd yes #PrintLastLog yes #TCPKeepAlive yes #UseLogin no #UsePrivilegeSeparation yes #PermitUserEnvironment no #Compression delayed #ClientAliveInterval 0 #ClientAliveCountMax 3 #UseDNS yes #PidFile /var/run/sshd.pid #MaxStartups 10 # no default banner path #Banner /some/path # override default of no subsystems Subsystem sftp /usr/libexec/sftp-server Philippe LE GAL Communications & Networking Unit European Medicines Agency (EMEA) 7 Westferry Circus, Canary Wharf, London E14 4HB, United Kingdom Tel: +44 (0)207 523 7023 Fax:+44 (0)207 418 8669 Email: Philippe.LeGal at emea.eu.int This message contains information which may be confidential. It is intended for the addressee(s) only. Unless you are a named addressee (or authorized by an addressee who received this message), access to this e-mail, or any disclosure or copying of its contents, or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you have received this e-mail in error, please inform the sender immediately. ________________________________________________________________________ This e-mail has been scanned for all known viruses by EMEA. ________________________________________________________________________ From openssh at roumenpetrov.info Mon Jan 23 02:21:54 2006 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Sun, 22 Jan 2006 17:21:54 +0200 Subject: Announce: X.509 certificates support in OpenSSH (version 5.3 from "Validator" series) Message-ID: <43D3A312.8080405@roumenpetrov.info> Hi All, The version 5.3 of "X.509 certificates support in OpenSSH" is published. This version adds preliminary support for "x509v3-sign-rsa-sha1" and "x509v3-sign-dss-sha1" key type names in conformance with "draft-ietf-secsh-x509-02.txt" and extends "x509v3-sign-dss key type with signatures in "ssh-dss" format. More details on page http://roumenpetrov.info/openssh/#news . Regards, Roumen Petrov From Richard.Dickens at reuters.com Mon Jan 23 21:01:09 2006 From: Richard.Dickens at reuters.com (Richard Dickens) Date: Mon, 23 Jan 2006 10:01:09 +0000 Subject: Only one chance to enter a new password? Message-ID: Darren, Here's the output from ssh -vvv. I will try and test the latest version today sometime... @isws8# ssh -l rr9rdic -vvv localhost OpenSSH_3.9p1, OpenSSL 0.9.7d 17 Mar 2004 debug1: Reading configuration data /usr/local/etc/ssh_config debug2: ssh_connect: needpriv 0 debug1: Connecting to localhost [::1] port 22. debug1: connect to address ::1 port 22: Network is unreachable debug1: Connecting to localhost [127.0.0.1] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/1 debug1: identity file /.ssh/identity type -1 debug1: identity file /.ssh/id_rsa type -1 debug3: Not a RSA1 key file /.ssh/id_dsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /.ssh/id_dsa type 2 debug1: Remote protocol version 2.0, remote software version OpenSSH_3.9p1 debug1: match: OpenSSH_3.9p1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_3.9p1 debug2: fd 7 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-he llman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c bc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c bc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 6,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 6,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-he llman-group1-sha1 debug2: kex_parse_kexinit: ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c bc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-c bc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 6,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 6,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 132/256 debug2: bits set: 525/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /.ssh/known_hosts2 debug3: check_host_in_hostfile: filename /usr/local/etc/ssh_known_hosts2 debug3: check_host_in_hostfile: filename /.ssh/known_hosts debug3: key_read: type mismatch debug3: check_host_in_hostfile: match line 32 debug1: Host 'localhost' is known and matches the DSA host key. debug1: Found key in /.ssh/known_hosts:32 debug2: bits set: 536/1024 debug1: ssh_dss_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /.ssh/identity (0) debug2: key: /.ssh/id_rsa (0) debug2: key: /.ssh/id_dsa (6c798) debug3: input_userauth_banner This is a proprietary system. No use is allowed without proper authorisation. Unauthorised use may be liable to prosecution under relevant legislation. debug1: Authentications that can continue: publickey,password debug3: start over, passed a different list publickey,password debug3: preferred publickey,keyboard-interactive,password debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Trying private key: /.ssh/identity debug3: no such identity: /.ssh/identity debug1: Trying private key: /.ssh/id_rsa debug3: no such identity: /.ssh/id_rsa debug1: Offering public key: /.ssh/id_dsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,password debug2: we did not send a packet, disable method debug3: authmethod_lookup password debug3: remaining preferred: ,password debug3: authmethod_is_enabled password debug1: Next authentication method: password rr9rdic at localhost's password: debug3: packet_send2: adding 64 (len 60 padlen 4 extra_pad 64) debug2: we sent a password packet, wait for reply debug1: Authentication succeeded (password). debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug2: channel 0: send open debug1: Entering interactive session. debug2: callback start debug2: client_session2_setup: id 0 debug2: channel 0: request pty-req confirm 0 debug3: tty_make_modes: ospeed 38400 debug3: tty_make_modes: ispeed 38400 debug3: tty_make_modes: 1 3 debug3: tty_make_modes: 2 28 debug3: tty_make_modes: 3 127 debug3: tty_make_modes: 4 21 debug3: tty_make_modes: 5 4 debug3: tty_make_modes: 6 0 debug3: tty_make_modes: 7 0 debug3: tty_make_modes: 8 17 debug3: tty_make_modes: 9 19 debug3: tty_make_modes: 10 26 debug3: tty_make_modes: 11 25 debug3: tty_make_modes: 12 18 debug3: tty_make_modes: 13 23 debug3: tty_make_modes: 14 22 debug3: tty_make_modes: 16 0 debug3: tty_make_modes: 18 15 debug3: tty_make_modes: 30 0 debug3: tty_make_modes: 31 0 debug3: tty_make_modes: 32 0 debug3: tty_make_modes: 33 0 debug3: tty_make_modes: 34 0 debug3: tty_make_modes: 35 0 debug3: tty_make_modes: 36 1 debug3: tty_make_modes: 37 0 debug3: tty_make_modes: 38 1 debug3: tty_make_modes: 39 0 debug3: tty_make_modes: 40 0 debug3: tty_make_modes: 41 1 debug3: tty_make_modes: 50 1 debug3: tty_make_modes: 51 1 debug3: tty_make_modes: 52 0 debug3: tty_make_modes: 53 1 debug3: tty_make_modes: 54 1 debug3: tty_make_modes: 55 1 debug3: tty_make_modes: 56 0 debug3: tty_make_modes: 57 0 debug3: tty_make_modes: 58 0 debug3: tty_make_modes: 59 1 debug3: tty_make_modes: 60 1 debug3: tty_make_modes: 61 1 debug3: tty_make_modes: 62 0 debug3: tty_make_modes: 70 1 debug3: tty_make_modes: 71 0 debug3: tty_make_modes: 72 1 debug3: tty_make_modes: 73 0 debug3: tty_make_modes: 74 0 debug3: tty_make_modes: 75 0 debug3: tty_make_modes: 90 1 debug3: tty_make_modes: 91 1 debug3: tty_make_modes: 92 0 debug3: tty_make_modes: 93 0 debug2: channel 0: request shell confirm 0 debug2: fd 7 setting TCP_NODELAY debug2: callback done debug2: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 Last login: Mon Jan 23 09:58:21 2006 from localhost New Password: sshd: Old and new passwords must differ by at least 3 positions. debug2: channel 0: rcvd eof debug2: channel 0: output open -> drain debug2: channel 0: obuf empty debug2: channel 0: close_write debug2: channel 0: output drain -> closed debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug2: channel 0: rcvd close debug2: channel 0: close_read debug2: channel 0: input open -> closed debug3: channel 0: will not send data after close debug2: channel 0: almost dead debug2: channel 0: gc: notify user debug2: channel 0: gc: user detached debug2: channel 0: send close debug2: channel 0: is dead debug2: channel 0: garbage collecting debug1: channel 0: free: client-session, nchannels 1 debug3: channel 0: status: The following connections are open: #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1 cfd -1) debug3: channel 0: close_fds r -1 w -1 e 10 c -1 Connection to localhost closed. debug1: Transferred: stdin 0, stdout 0, stderr 33 bytes in 3.9 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 8.4 debug1: Exit status 255 Regards, Richard Dickens -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: 20 January 2006 02:34 To: Richard Dickens Cc: openssh-unix-dev at mindrot.org Subject: Re: Only one chance to enter a new password? On Thu, Jan 19, 2006 at 12:24:19PM +0000, Richard Dickens wrote: > We are using OpenSSH_3.9p1, OpenSSL 0.9.7d 17 Mar 2004 on various > Solaris boxes with PAM and an LDAP server back end. > > Recently we have added a requirement for users to have complex > passwords. The problem is, if a user's password has expired, when they > log in they are prompted for a new password (good) but if they enter a > non-complex new password the session is closed rather than reprompting > them for another try. With some PC clients they see nothing which is > causing a lot of support calls... How does 4.2p1 (or better, a current snapshot) behave with regard to this? There were several changes in that area since 3.9. > Is they any way to reprompt the user for another password? Depends on exactly what's going on. Can you post the output from the client while this is going on? (ssh -vvv yourserver) -- 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. To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. From dtucker at zip.com.au Mon Jan 23 21:13:31 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 23 Jan 2006 21:13:31 +1100 Subject: Only one chance to enter a new password? In-Reply-To: References: Message-ID: <43D4AC4B.3020108@zip.com.au> Richard Dickens wrote: > Darren, > > Here's the output from ssh -vvv. I will try and test the latest version > today sometime... [...] One other question: what do you have UsePAM and UsePrivilegeSeparation set to ? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From Richard.Dickens at reuters.com Mon Jan 23 21:16:09 2006 From: Richard.Dickens at reuters.com (Richard Dickens) Date: Mon, 23 Jan 2006 10:16:09 +0000 Subject: Only one chance to enter a new password? Message-ID: <974FF25EED65144AB4F511A094BE1D3AE09215@LONSMSXM06.emea.ime.reuters.com> UsePAM yes UsePrivilegeSeparation no UsePrivilegeSeparation no is used to make sure messages get logged. Regards, Richard -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: 23 January 2006 10:14 To: Richard Dickens Cc: openssh-unix-dev at mindrot.org Subject: Re: Only one chance to enter a new password? Richard Dickens wrote: > Darren, > > Here's the output from ssh -vvv. I will try and test the latest > version today sometime... [...] One other question: what do you have UsePAM and UsePrivilegeSeparation set to ? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. From Richard.Dickens at reuters.com Mon Jan 23 22:08:28 2006 From: Richard.Dickens at reuters.com (Richard Dickens) Date: Mon, 23 Jan 2006 11:08:28 +0000 Subject: Only one chance to enter a new password? Message-ID: Darren, I have now tested with OpenSSH_4.2p1, OpenSSL 0.9.8a 11 Oct 2005 from sunfreeware and the problem still exists. Regards, Richard -----Original Message----- From: openssh-unix-dev-bounces+richard.dickens=reuters.com at mindrot.org [mailto:openssh-unix-dev-bounces+richard.dickens=reuters.com at mindrot.org ] On Behalf Of Richard Dickens Sent: 23 January 2006 10:16 To: Darren Tucker Cc: openssh-unix-dev at mindrot.org Subject: RE: Only one chance to enter a new password? UsePAM yes UsePrivilegeSeparation no UsePrivilegeSeparation no is used to make sure messages get logged. Regards, Richard -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: 23 January 2006 10:14 To: Richard Dickens Cc: openssh-unix-dev at mindrot.org Subject: Re: Only one chance to enter a new password? Richard Dickens wrote: > Darren, > > Here's the output from ssh -vvv. I will try and test the latest > version today sometime... [...] One other question: what do you have UsePAM and UsePrivilegeSeparation set to ? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://www.mindrot.org/mailman/listinfo/openssh-unix-dev To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. From dtucker at zip.com.au Mon Jan 23 22:22:02 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 23 Jan 2006 22:22:02 +1100 Subject: Only one chance to enter a new password? In-Reply-To: <974FF25EED65144AB4F511A094BE1D3AE09215@LONSMSXM06.emea.ime.reuters.com> References: <974FF25EED65144AB4F511A094BE1D3AE09215@LONSMSXM06.emea.ime.reuters.com> Message-ID: <20060123112202.GA14917@gate.dtucker.net> On Mon, Jan 23, 2006 at 10:16:09AM +0000, Richard Dickens wrote: > UsePAM yes > UsePrivilegeSeparation no OK, think I see what's going on. It's a non-issue for command line clients since the message will remain on the screen. Please try the attached 3-chance patch (against -current but should apply to 4.2p1 as well). > UsePrivilegeSeparation no is used to make sure messages get logged. Could you please elaborate on that? As far as possible, sshd should behave the same with or without privsep wrt PAM, so I want to figure out if it's a known issue or something new. Index: auth-pam.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth-pam.c,v retrieving revision 1.127 diff -u -p -r1.127 auth-pam.c --- auth-pam.c 28 Sep 2005 12:33:27 -0000 1.127 +++ auth-pam.c 23 Jan 2006 11:15:04 -0000 @@ -979,6 +979,8 @@ static struct pam_conv tty_conv = { sshp void do_pam_chauthtok(void) { + int count = 0; + if (use_privsep) fatal("Password expired (unable to change with privsep)"); sshpam_err = pam_set_item(sshpam_handle, PAM_CONV, @@ -987,10 +989,16 @@ do_pam_chauthtok(void) fatal("PAM: failed to set PAM_CONV: %s", pam_strerror(sshpam_handle, sshpam_err)); debug("PAM: changing password"); - sshpam_err = pam_chauthtok(sshpam_handle, PAM_CHANGE_EXPIRED_AUTHTOK); - if (sshpam_err != PAM_SUCCESS) - fatal("PAM: pam_chauthtok(): %s", - pam_strerror(sshpam_handle, sshpam_err)); + do { + sshpam_err = pam_chauthtok(sshpam_handle, + PAM_CHANGE_EXPIRED_AUTHTOK); + fprintf(stderr, "Password change: %s\n", + pam_strerror(sshpam_handle, sshpam_err)); + if (sshpam_err == PAM_SUCCESS) + return; + } while (count++ < 3); + fatal("PAM: pam_chauthtok(): %s", + pam_strerror(sshpam_handle, sshpam_err)); } void -- 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 Richard.Dickens at reuters.com Mon Jan 23 22:35:25 2006 From: Richard.Dickens at reuters.com (Richard Dickens) Date: Mon, 23 Jan 2006 11:35:25 +0000 Subject: Only one chance to enter a new password? Message-ID: <974FF25EED65144AB4F511A094BE1D3AE092A4@LONSMSXM06.emea.ime.reuters.com> Darren, The UsePrivilegeSeparation issue was one that I reported to this list in Nov 2004. It was to do with authorization messages not getting syslogged. Here's what you wrote at the time: >The reason it's not logged is privsep: the packet_disconnect and logit call happen in the unprivileged child >(which is chrooted and doesn't have access to /dev/log). Trying it with UsePrivilegeSeparation=no has the >messages logged OK. Not sure how to fix it for privsep=yes, other than adding a /dev/log to the chroot. Regarding the patch, it may take me a while to find somewhere to build the change. Stay tuned! Regards, Richard -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: 23 January 2006 11:22 To: Richard Dickens Cc: openssh-unix-dev at mindrot.org Subject: Re: Only one chance to enter a new password? On Mon, Jan 23, 2006 at 10:16:09AM +0000, Richard Dickens wrote: > UsePAM yes > UsePrivilegeSeparation no OK, think I see what's going on. It's a non-issue for command line clients since the message will remain on the screen. Please try the attached 3-chance patch (against -current but should apply to 4.2p1 as well). > UsePrivilegeSeparation no is used to make sure messages get logged. Could you please elaborate on that? As far as possible, sshd should behave the same with or without privsep wrt PAM, so I want to figure out if it's a known issue or something new. Index: auth-pam.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth-pam.c,v retrieving revision 1.127 diff -u -p -r1.127 auth-pam.c --- auth-pam.c 28 Sep 2005 12:33:27 -0000 1.127 +++ auth-pam.c 23 Jan 2006 11:15:04 -0000 @@ -979,6 +979,8 @@ static struct pam_conv tty_conv = { sshp void do_pam_chauthtok(void) { + int count = 0; + if (use_privsep) fatal("Password expired (unable to change with privsep)"); sshpam_err = pam_set_item(sshpam_handle, PAM_CONV, @@ -987,10 +989,16 @@ do_pam_chauthtok(void) fatal("PAM: failed to set PAM_CONV: %s", pam_strerror(sshpam_handle, sshpam_err)); debug("PAM: changing password"); - sshpam_err = pam_chauthtok(sshpam_handle, PAM_CHANGE_EXPIRED_AUTHTOK); - if (sshpam_err != PAM_SUCCESS) - fatal("PAM: pam_chauthtok(): %s", - pam_strerror(sshpam_handle, sshpam_err)); + do { + sshpam_err = pam_chauthtok(sshpam_handle, + PAM_CHANGE_EXPIRED_AUTHTOK); + fprintf(stderr, "Password change: %s\n", + pam_strerror(sshpam_handle, sshpam_err)); + if (sshpam_err == PAM_SUCCESS) + return; + } while (count++ < 3); + fatal("PAM: pam_chauthtok(): %s", + pam_strerror(sshpam_handle, sshpam_err)); } void -- 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. To find out more about Reuters visit www.about.reuters.com Any views expressed in this message are those of the individual sender, except where the sender specifically states them to be the views of Reuters Ltd. From august at chalmers.se Tue Jan 24 03:44:10 2006 From: august at chalmers.se (=?iso-8859-1?Q?Bj=F6rn?= Augustsson) Date: Mon, 23 Jan 2006 17:44:10 +0100 Subject: Bug: Copying several files to non-directory. In-Reply-To: <20060120121722.GD6245@chalmers.se> References: <20060120121722.GD6245@chalmers.se> Message-ID: <20060123164410.GK6245@chalmers.se> On Fri, Jan 20, 2006 at 01:17:22PM +0100, Bj?rn Augustsson wrote: > Dear openssh people, > > Here's something to try: > > $ echo a >a > $ echo b >b > $ echo c >c > $ > $ scp a b c > $ > $ echo $? > 1 > $ cat a b c > a > b > b > > Ouch! Also, for comparison: > > $ cp a b c > cp: copying multiple files, but last argument `c' is not a directory > Try `cp --help' for more information. > $ rcp a b c > rcp: c: Not a directory. > $ > > Note that the cp behavior is specified in SuSv2. > (http://www.opengroup.org/onlinepubs/007908799/xcu/cp.html, "Second synopsis") > > Also, and this might be a separate bug, note how openssh exits with > return code of 1. > > This was verified using various versions of scp from 3.6.1p2 to 4.2, on > linux (various versions) and openbsd. Here's a patch that seems to fix it. (Against 4.2p1) The first chunk fixed the eating of the innocent file, and is fairly obvoiusly correct. The second one fixes the fact that there's no error message. I'm less certain of that one not breaking anything else. (A colleague wrote that one... :) /August. diff -u openssh-4.2p1/scp.c openssh-4.2p1-hack/scp.c --- openssh-4.2p1/scp.c 2005-08-02 09:07:08.000000000 +0200 +++ openssh-4.2p1-hack/scp.c 2006-01-23 17:31:37.000000000 +0100 @@ -336,9 +336,10 @@ if ((targ = colon(argv[argc - 1]))) /* Dest is remote host. */ toremote(targ, argc, argv); else { - tolocal(argc, argv); /* Dest is local host. */ + /* Dest is local host. */ if (targetshouldbedirectory) verifydir(argv[argc - 1]); + tolocal(argc, argv); } /* * Finally check the exit status of the ssh process, if one was forked @@ -1045,16 +1046,15 @@ va_list ap; ++errs; - if (fp == NULL && !(fp = fdopen(remout, "w"))) - return; - (void) fprintf(fp, "%c", 0x01); - (void) fprintf(fp, "scp: "); - va_start(ap, fmt); - (void) vfprintf(fp, fmt, ap); - va_end(ap); - (void) fprintf(fp, "\n"); - (void) fflush(fp); - + if (fp != NULL || (fp = fdopen(remout, "w"))) { + (void) fprintf(fp, "%c", 0x01); + (void) fprintf(fp, "scp: "); + va_start(ap, fmt); + (void) vfprintf(fp, fmt, ap); + va_end(ap); + (void) fprintf(fp, "\n"); + (void) fflush(fp); + } if (!iamremote) { va_start(ap, fmt); vfprintf(stderr, fmt, ap); -- Bj?rn Augustsson Sysadmin IT Systems & Services Chalmers tekniska h?gskola Chalmers University of Technology "Damn spooky analog crap." -- John Carmack. From djm at mindrot.org Tue Jan 24 07:58:03 2006 From: djm at mindrot.org (Damien Miller) Date: Tue, 24 Jan 2006 07:58:03 +1100 Subject: Only one chance to enter a new password? In-Reply-To: <974FF25EED65144AB4F511A094BE1D3AE092A4@LONSMSXM06.emea.ime.reuters.com> References: <974FF25EED65144AB4F511A094BE1D3AE092A4@LONSMSXM06.emea.ime.reuters.com> Message-ID: <43D5435B.8090807@mindrot.org> Richard Dickens wrote: > Darren, > > The UsePrivilegeSeparation issue was one that I reported to this list in > Nov 2004. It was to do with authorization messages not getting > syslogged. Here's what you wrote at the time: > > >>The reason it's not logged is privsep: the packet_disconnect and logit > > call happen in the unprivileged child >(which is chrooted and doesn't > have access to /dev/log). Trying it with UsePrivilegeSeparation=no has > the You should arrange for your syslogd to listen at /var/empty/dev/log that is what OpenBSD does. -d From Philippe.LeGal at emea.eu.int Wed Jan 25 03:10:18 2006 From: Philippe.LeGal at emea.eu.int (Le Gal Philippe) Date: Tue, 24 Jan 2006 16:10:18 -0000 Subject: openssh-4.2p1 + Pam question ! Message-ID: Hi there ! I have an issue with my OpenSSH + PAM configuration on a RedHat Advanced server 2..1 I want to authenticate users connecting to a server using ssh against a radius server. The radius client/server part works ok when I test it with some utilities. I think I have a problem with my ssh which does not pass the username/password to my pam sshd module. I have upgraded to openssh-4.2p1. Please find thereafter the sshd_config as well as my pam conf file, I try to authenticate with user name which is NOT in my /etc/passwd (authentication will be made by the radius server), ie : ssh test at myserver. Jan 20 14:54:32 us067 sshd(pam_unix)[31601]: check pass; user unknown Jan 20 14:54:32 us067 sshd(pam_unix)[31601]: authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=192.168.60.76 Jan 20 14:54:34 us067 sshd[31599]: error: PAM: Authentication failure for illegal user test from 192.168.60.76 Jan 20 14:54:34 us067 sshd[31599]: Failed keyboard-interactive/pam for invalid user test from 192.168.60.76 port 4397 ssh2 is there a way of telling sshd to pass the username and password directly to PAm without interfering with it ? Thank you for your precious help ! Philippe less /etc/pam.d/sshd #%PAM-1.0 auth sufficient /lib/security/pam_radius_auth.so debug auth required /lib/security/pam_stack.so service=system-auth auth required /lib/security/pam_nologin.so account sufficient /lib/security/pam_radius_auth.so password sufficient /lib/security/pam_radius_auth.so session required /lib/security/pam_limits.so session optional /lib/security/pam_console.so # $OpenBSD: sshd_config,v 1.72 2005/07/25 11:59:40 markus Exp $ # This is the sshd server system-wide configuration file. See # sshd_config(5) for more information. # This sshd was compiled with PATH=/usr/bin:/bin:/usr/sbin:/sbin # The strategy used for options in the default sshd_config shipped with # OpenSSH is to specify options with their default value where # possible, but leave them commented. Uncommented options change a # default value. #Port 22 #Protocol 2,1 #AddressFamily any #ListenAddress 0.0.0.0 #ListenAddress :: # HostKey for protocol version 1 #HostKey /etc/ssh/ssh_host_key # HostKeys for protocol version 2 #HostKey /etc/ssh/ssh_host_rsa_key #HostKey /etc/ssh/ssh_host_dsa_key # Lifetime and size of ephemeral version 1 server key #KeyRegenerationInterval 1h #ServerKeyBits 768 # Logging # obsoletes QuietMode and FascistLogging #SyslogFacility AUTH #LogLevel INFO # Authentication: #LoginGraceTime 2m #PermitRootLogin yes #StrictModes yes #MaxAuthTries 6 #RSAAuthentication yes #PubkeyAuthentication yes #AuthorizedKeysFile .ssh/authorized_keys # For this to work you will also need host keys in /etc/ssh/ssh_known_hosts #RhostsRSAAuthentication no # similar for protocol version 2 #HostbasedAuthentication no # Change to yes if you don't trust ~/.ssh/known_hosts for # RhostsRSAAuthentication and HostbasedAuthentication #IgnoreUserKnownHosts no # Don't read the user's ~/.rhosts and ~/.shosts files #IgnoreRhosts yes # To disable tunneled clear text passwords, change to no here! PasswordAuthentication no #PermitEmptyPasswords no # Change to no to disable s/key passwords #ChallengeResponseAuthentication yes # Kerberos options #KerberosAuthentication no #KerberosOrLocalPasswd yes #KerberosTicketCleanup yes #KerberosGetAFSToken no # GSSAPI options #GSSAPIAuthentication no #GSSAPICleanupCredentials yes # Set this to 'yes' to enable PAM authentication, account processing, # and session processing. If this is enabled, PAM authentication will # be allowed through the ChallengeResponseAuthentication mechanism. # Depending on your PAM configuration, this may bypass the setting of # PasswordAuthentication, PermitEmptyPasswords, and # "PermitRootLogin without-password". If you just want the PAM account and # session checks to run without PAM authentication, then enable this but set # ChallengeResponseAuthentication=no UsePAM yes #AllowTcpForwarding yes #GatewayPorts no #X11Forwarding no #X11DisplayOffset 10 #X11UseLocalhost yes #PrintMotd yes #PrintLastLog yes #TCPKeepAlive yes #UseLogin no #UsePrivilegeSeparation yes #PermitUserEnvironment no #Compression delayed #ClientAliveInterval 0 #ClientAliveCountMax 3 #UseDNS yes #PidFile /var/run/sshd.pid #MaxStartups 10 # no default banner path #Banner /some/path # override default of no subsystems Subsystem sftp /usr/libexec/sftp-server Philippe LE GAL Communications & Networking Unit European Medicines Agency (EMEA) 7 Westferry Circus, Canary Wharf, London E14 4HB, United Kingdom Tel: +44 (0)207 523 7023 Fax:+44 (0)207 418 8669 Email: Philippe.LeGal at emea.eu.int This message contains information which may be confidential. It is intended for the addressee(s) only. Unless you are a named addressee (or authorized by an addressee who received this message), access to this e-mail, or any disclosure or copying of its contents, or any action taken (or not taken) in reliance on it is unauthorized and may be unlawful. If you have received this e-mail in error, please inform the sender immediately. ________________________________________________________________________ This e-mail has been scanned for all known viruses by EMEA. ________________________________________________________________________ From corsmith at gmail.com Wed Jan 25 04:52:05 2006 From: corsmith at gmail.com (Corey Smith) Date: Tue, 24 Jan 2006 12:52:05 -0500 Subject: Tunneling lock/hangs/unidirectional Message-ID: <8061fbee0601240952p448f3a46gf9b03e4841f54929@mail.gmail.com> I've setup a lab to test the new tunneling options in the latest openssh. Things work well... for a while... then the tunnel goes unidirectional. openssh-SNAP-20060122.tar.gz lab1 config: # uname -a FreeBSD lab1 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Fri Jan 13 13:01:17 EST 2006 root@:/usr/src/sys/i386/compile/SMP i386 # cat /etc/sysctl.conf | egrep -v '(^#|^$)' net.inet.ip.fastforwarding=1 # cat ~/.ssh/config Host 169.254.254.20 Tunnel yes TunnelDevice 0:any PermitLocalCommand yes LocalCommand sh /root/scripts/netstart tun0 # cat /root/scripts/netstart #!/bin/sh ifconfig $1 inet 169.254.253.10 169.254.253.20 netmask 255.255.255.0 && \ route add host2 169.254.253.20 lab 2 config: # uname -a FreeBSD lab2 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Fri Jan 13 12:00:56 EST 2006 root@:/usr/src/sys/i386/compile/SMP i386 # cat /etc/sysctl.conf | egrep -v '(^#|^$)' net.inet.ip.fastforwarding=1 # cat /etc/ssh/sshd_config | egrep -v '(^#|^$)' PermitTunnel point-to-point # cat ~/.ssh/authorized_keys2 tunnel="1",command="/root/scripts/netstart tun1" ssh-dss AAAA... # cat /root/scripts/netstart #!/bin/sh ifconfig $1 inet 169.254.253.20 169.254.253.10 netmask 255.255.255.0 && \ route add host1 169.254.253.10 The test consists of a single TCP stream operating at the maximum capacity of a FastEthernet connection 12.5MBps using the command: #setup the tunnel and routes lab1# ssh -fw 0:any 169.254.254.20 true host1$ cat /dev/zero | nc -l 2000 host2$ nc -o host1 2000 > /dev/zero This test usually runs between 4-5 seconds before the tunnel goes unidirectional: packets tunnelized between lab1 -> lab2 work but tunneled packets between lab2 -> lab1 do not. After changing the MTU of the test TCP stream to 1400 it ends up lasting around 2 minutes before going unidirectional. lab2# ping 169.254.253.10 PING 169.254.253.10 (169.254.253.10): 56 data bytes ping: sendto: No buffer space available Without the ssh tunnel the lab boxes easily route that much bandwidth indefinitely. Any ideas on how I can further diagnose the problem would be appreciated. -Corey Smith From miklos at szeredi.hu Wed Jan 25 02:22:37 2006 From: miklos at szeredi.hu (Miklos Szeredi) Date: Tue, 24 Jan 2006 16:22:37 +0100 Subject: sftp performance problem, cured by TCP_NODELAY Message-ID: In certain situations sftp download speed can be much less than that of scp. After many days of trying to find the cause finally I found it to be the tcp nagle algorithm, which if turned off with TCP_NODELAY eliminates the problem. Now I see it being discussed back in 2002, but it still unresolved in openssh-4.2 :( Simple solution would be to add a NoDelay option to ssh which sftp would set. The proprietary ssh seems to already have this option. Attached an LD_PRELOAD hack to set TCP_NODELAY. For me this hack doubles the download speed of a 100MB file over a 100Mbps network. Miklos ----------------------------------------------------------------------- /* gcc -Wall -W -o sshnodelay.so --shared -ldl sshnodelay.c */ #define _GNU_SOURCE #include #include #include #include int connect(int sock, const struct sockaddr *addr, socklen_t addrlen) { int (*next_connect)(int, const struct sockaddr *, socklen_t) = dlsym(RTLD_NEXT, "connect"); int res = next_connect(sock, addr, addrlen); if (addr->sa_family == AF_INET) { int opt = 1; setsockopt(sock, IPPROTO_TCP, TCP_NODELAY, &opt, sizeof(opt)); } return res; } ----------------------------------------------------------------------- $ time sftp -b /tmp/big100M.b server sftp> get big100M /dev/null Fetching /tmp/big100M to /dev/null real 0m18.231s user 0m6.248s sys 0m1.684s $ time LD_PRELOAD=/tmp/sshnodelay.so sftp -b /tmp/big100M.b server sftp> get big100M /dev/null Fetching /tmp/big100M to /dev/null real 0m9.001s user 0m6.320s sys 0m1.840s From rick.jones2 at hp.com Wed Jan 25 05:23:51 2006 From: rick.jones2 at hp.com (Rick Jones) Date: Tue, 24 Jan 2006 10:23:51 -0800 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: References: Message-ID: <43D670B7.80801@hp.com> Miklos Szeredi wrote: > In certain situations sftp download speed can be much less than that > of scp. > > After many days of trying to find the cause finally I found it to be > the tcp nagle algorithm, which if turned off with TCP_NODELAY > eliminates the problem. > > Now I see it being discussed back in 2002, but it still unresolved in > openssh-4.2 :( > > Simple solution would be to add a NoDelay option to ssh which sftp > would set. The proprietary ssh seems to already have this option. What sort of socket calling pattern was sftp making that had it running into issues with Nagle and delayed ACK? rick jones From Jason.C.Burns at wellsfargo.com Wed Jan 25 07:02:57 2006 From: Jason.C.Burns at wellsfargo.com (Jason.C.Burns at wellsfargo.com) Date: Tue, 24 Jan 2006 14:02:57 -0600 Subject: SCP logging and file validation Message-ID: Greetings list members, I have a quick question regarding scp. I'm looking to add logging and validation to all copied files on the source and the remote. Looking at the archives, I see some posts regarding logging from a few years back, which includes what looks like an acceptable patch. My question on this has there been any more recent discussion on this topic (just scp, not looking to open the sftp can of worms!), or has this pretty much been dead since the 2004 discussion? As for validation, I'm thinking about creating a hash on the source, sending that data over, and comparing it to a hash that's run on the copied file from the remote. This is just in the early design phase now, but wondering if anyone has ever mulled this idea over and had any suggestions/ideas. Thanks for any information you can provide! Jason From rick.jones2 at hp.com Wed Jan 25 07:52:18 2006 From: rick.jones2 at hp.com (Rick Jones) Date: Tue, 24 Jan 2006 12:52:18 -0800 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: References: <43D670B7.80801@hp.com> Message-ID: <43D69382.8080504@hp.com> Miklos Szeredi wrote: >>What sort of socket calling pattern was sftp making that had it >>running into issues with Nagle and delayed ACK? > > > Don't know exactly why Nagle kicks in, In broad handwaving terms, applications that try to do "write write read" can run afoul of interactions between Nagle and delayed ACK. > but it does so quite early, after just a couple of READ request/reply pairs. > I can send you tcpdump output tomorrow. Thanks. I would like to see it. rick From rick.jones2 at hp.com Wed Jan 25 08:36:22 2006 From: rick.jones2 at hp.com (Rick Jones) Date: Tue, 24 Jan 2006 13:36:22 -0800 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> Message-ID: <43D69DD6.70908@hp.com> Miklos Szeredi wrote: >>In broad handwaving terms, applications that try to do "write write >>read" can run afoul of interactions between Nagle and delayed ACK. > > > Which is exactly what sftp does. > > Excerpt from sftp(1): > > | -R num_requests > | Specify how many requests may be outstanding at any one time. > | Increasing this may slightly improve file transfer speed but > | will increase memory usage. The default is 16 outstanding > | requests. > > I also noticed, that -R 1 actually increases throughput in some cases, > which is nicely explained by the fact, that then it will always be > "write read" pairs. > > Of course -R 1 will still result in suboptimal throughput, so that is > not the solution. So, if the code knows it is going to inject N requests at one time, why not use writev() or sendmsg()? rick jones still interested in the packet trace though From gswallow at www.IN.gov Wed Jan 25 08:05:02 2006 From: gswallow at www.IN.gov (Greg Swallow) Date: Tue, 24 Jan 2006 16:05:02 -0500 Subject: weird issues with DH Group1 key exchange Message-ID: <43D6967E.4030904@www.IN.gov> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, We recently upgraded to OpenSSH 4.2p1 with the chroot patch supplied on sourceforge. Since then, we've noticed odd problems with random client failures. Today I wrote little scripts to keep restarting sshd with the - -ddd flag and finally captured what's going on, I believe. First, openssh is compiled as so: OpenSSH_4.2p1, OpenSSL 0.9.8a configured by ./configure, generated by GNU Autoconf 2.59, with options \"'--prefix=/usr/local' '--with-audit=bsm' '--with-md5-passwords' '--with-kerberos5=/opt/krb5' '--with-ssl-dir=/usr/local' '--with-zlib'\" Then we have Net::SSH and Eclipse failing on us randomly (although with alarming frequency). Net::SSH version 1.23; Eclipse I have no idea. What happens on the client side is: bart: Reading configuration data /web/etc/noaccess/.ssh/config bart: Reading configuration data /etc/ssh_config bart: Connecting to eliza.ai.org, port 22. bart: Remote protocol version 2.0, remote software version OpenSSH_4.2-chrootsshbart: Net::SSH::Perl Version 1.23, protocol version 2.0. bart: No compat match: OpenSSH_4.2-chrootssh. bart: Connection established. bart: Sent key-exchange init (KEXINIT), wait response. bart: Algorithms, c->s: 3des-cbc hmac-sha1 none bart: Algorithms, s->c: 3des-cbc hmac-sha1 none bart: Entering Diffie-Hellman Group 1 key exchange. bart: Sent DH public key, waiting for reply. Connection closed by remote host. at /usr1/local/lib/perl5/site_perl/5.6.1/Net/SSH/Perl/Kex/DH1.pm line 38 What happens on the server side is: debug2: load_server_config: filename /usr/local/etc/sshd_config.private debug2: load_server_config: done config len = 439 debug2: parse_server_config: config /usr/local/etc/sshd_config.private len 439 debug1: sshd version OpenSSH_4.2-chrootsshp1 debug3: Not a RSA1 key file /usr/local/etc/ssh_host_key. debug1: read PEM private key done: type RSA debug1: private host key: #0 type 1 RSA debug3: Not a RSA1 key file /usr/local/etc/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug3: Not a RSA1 key file /usr/local/etc/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA Disabling protocol version 1. Could not load host key debug1: rexec_argv[0]='/usr/local/sbin/sshd' debug1: rexec_argv[1]='-f' debug1: rexec_argv[2]='/usr/local/etc/sshd_config.private' debug1: rexec_argv[3]='-ddd' debug2: fd 4 setting O_NONBLOCK debug1: Bind to port 22 on 10.8.54.105. Server listening on 10.8.54.105 port 22. debug1: fd 5 clearing O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 10 config len 439 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 10 debug1: inetd sockets after dupping: 4, 4 Connection from 10.8.6.80 port 57334 debug1: Client protocol version 2.0; client software version 1.23 debug1: no match: 1.23 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_4.2-chrootssh debug2: fd 4 setting O_NONBLOCK debug3: privsep user:group 22:22 debug1: permanently_set_uid: 22/22 debug1: list_hostkey_types: ssh-rsa,ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug2: Network child is on pid 20240 debug3: preauth child monitor started debug3: mm_request_receive entering debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-dss,ssh-rsa debug2: kex_parse_kexinit: 3des-cbc,blowfish-cbc,arcfour debug2: kex_parse_kexinit: 3des-cbc,blowfish-cbc,arcfour debug2: kex_parse_kexinit: hmac-sha1,hmac-md5 debug2: kex_parse_kexinit: hmac-sha1,hmac-md5 debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-sha1 debug1: kex: client->server 3des-cbc hmac-sha1 none debug2: mac_init: found hmac-sha1 debug1: kex: server->client 3des-cbc hmac-sha1 none debug1: do_cleanup Sometimes the server continues, but sometimes it just hangs up on me here. When it works, it continues: debug2: dh_gen_key: priv key bits set: 178/384 debug2: bits set: 505/1024 debug1: expecting SSH2_MSG_KEXDH_INIT debug2: bits set: 505/1024 debug3: mm_key_sign entering debug3: mm_request_send entering: type 4 debug3: monitor_read: checking request 4 debug3: mm_answer_sign debug3: mm_answer_sign: signature 103580(55) debug3: mm_request_send entering: type 5 debug2: monitor_read: 4 used once, disabling now debug3: mm_request_receive entering debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN debug3: mm_request_receive_expect entering: type 5 debug3: mm_request_receive entering debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: KEX done ... Help would be greatly appreciated. - -- Greg Swallow System Administrator, CCNA, CCSA http://www.IN.gov 10 West Market St, Suite 600 Indianapolis, IN 46204 T. 317.233.2908 F. 317.233.2011 ********************************************************************** CONFIDENTIALITY NOTICE: This E-mail and any attachments are confidential. If you are not the intended recipient, you do not have permission to disclose, copy, distribute, or open any attachments. If you have received this E-mail in error, please notify us immediately by returning it to the sender and delete this copy from your system. Thank you. accessIndiana, MyLocal.IN.gov, CivicNet ********************************************************************** -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (Darwin) iD8DBQFD1pZ9Ch6zYRu0Fx8RAku+AKC3nOmFgSspJw317Z1fTxSgGuONvgCfSGnj x+/oP+Yd5VEZbF4uXaARsUY= =s95I -----END PGP SIGNATURE----- From dtucker at zip.com.au Wed Jan 25 11:55:56 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 25 Jan 2006 11:55:56 +1100 Subject: Tunneling lock/hangs/unidirectional In-Reply-To: <8061fbee0601240952p448f3a46gf9b03e4841f54929@mail.gmail.com> References: <8061fbee0601240952p448f3a46gf9b03e4841f54929@mail.gmail.com> Message-ID: <20060125005556.GB2466@gate.dtucker.net> On Tue, Jan 24, 2006 at 12:52:05PM -0500, Corey Smith wrote: > I've setup a lab to test the new tunneling options in the latest > openssh. Things work well... for a while... then the tunnel goes > unidirectional. [...] > PING 169.254.253.10 (169.254.253.10): 56 data bytes > ping: sendto: No buffer space available It looks like the buffer space in your tunnel device is full. Is the SSH stream still running? If you stop transmitting traffic does it come good again? Are other normal connections to that machine affected? You might also like to try picking a fast cipher (arcfour is usually fastest of the standard ones) and see if that makes a difference. -- 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 corsmith at gmail.com Thu Jan 26 01:30:05 2006 From: corsmith at gmail.com (Corey Smith) Date: Wed, 25 Jan 2006 09:30:05 -0500 Subject: Tunneling lock/hangs/unidirectional In-Reply-To: <20060125005556.GB2466@gate.dtucker.net> References: <8061fbee0601240952p448f3a46gf9b03e4841f54929@mail.gmail.com> <20060125005556.GB2466@gate.dtucker.net> Message-ID: <8061fbee0601250630k1e01d6e3j5a50ce00457db62c@mail.gmail.com> On 1/24/06, Darren Tucker wrote: > It looks like the buffer space in your tunnel device is full. Is the > SSH stream still running? If you stop transmitting traffic does it come > good again? Are other normal connections to that machine affected? > > You might also like to try picking a fast cipher (arcfour is usually > fastest of the standard ones) and see if that makes a difference. Thanks for the response. I think the buffer space exhaustion is a sympton and not a cause: the tunnel quits sending so its send buffers get full. The tunnel between lab2 -> lab1 fails. The only thing that would be going through the tunnel in this test is the ACK stream from the netcat. Other connections to lab[12] are not affected during the lock (even other ssh connections to the same daemon). AFAIK the tunnel never fixes itself. If I kill the ssh process that started the tunnel on lab1 and then restart it the tunnel works again... for a while. I will try using a faster encryption algorithm later today. -Corey Smith From miklos at szeredi.hu Wed Jan 25 23:49:04 2006 From: miklos at szeredi.hu (Miklos Szeredi) Date: Wed, 25 Jan 2006 13:49:04 +0100 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: <43D69DD6.70908@hp.com> (message from Rick Jones on Tue, 24 Jan 2006 13:36:22 -0800) References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> <43D69DD6.70908@hp.com> Message-ID: > So, if the code knows it is going to inject N requests at one time, > why not use writev() or sendmsg()? No, it keeps N requests outstanding all the time, meaning, that when a reply comes back, it sends out another request. I think this is causing the problem. However the problem is more general, in that ssh should be able to efficiently transport _any_ kind of protocol, no matter what I/O pattern it uses. Does Nagle make sense for anything other than interactive sessions? Maybe turning it off if input/output is not a terminal makes sense, no? Miklos From miklos at szeredi.hu Wed Jan 25 08:08:02 2006 From: miklos at szeredi.hu (Miklos Szeredi) Date: Tue, 24 Jan 2006 22:08:02 +0100 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: <43D69382.8080504@hp.com> (message from Rick Jones on Tue, 24 Jan 2006 12:52:18 -0800) References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> Message-ID: > In broad handwaving terms, applications that try to do "write write > read" can run afoul of interactions between Nagle and delayed ACK. Which is exactly what sftp does. Excerpt from sftp(1): | -R num_requests | Specify how many requests may be outstanding at any one time. | Increasing this may slightly improve file transfer speed but | will increase memory usage. The default is 16 outstanding | requests. I also noticed, that -R 1 actually increases throughput in some cases, which is nicely explained by the fact, that then it will always be "write read" pairs. Of course -R 1 will still result in suboptimal throughput, so that is not the solution. Miklos From miklos at szeredi.hu Wed Jan 25 06:46:50 2006 From: miklos at szeredi.hu (Miklos Szeredi) Date: Tue, 24 Jan 2006 20:46:50 +0100 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: <43D670B7.80801@hp.com> (message from Rick Jones on Tue, 24 Jan 2006 10:23:51 -0800) References: <43D670B7.80801@hp.com> Message-ID: > What sort of socket calling pattern was sftp making that had it > running into issues with Nagle and delayed ACK? Don't know exactly why Nagle kicks in, but it does so quite early, after just a couple of READ request/reply pairs. I can send you tcpdump output tomorrow. Or you can try to reproduce it, in my experience on high speed links sftp-get will usually be slower than scp, in which case you will see Nagle being the culprit. Strangely sftp-put is not affected. Again don't know why. Miklos From djm at mindrot.org Thu Jan 26 14:19:07 2006 From: djm at mindrot.org (Damien Miller) Date: Thu, 26 Jan 2006 14:19:07 +1100 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> <43D69DD6.70908@hp.com> Message-ID: <43D83FAB.2010807@mindrot.org> Miklos Szeredi wrote: >>So, if the code knows it is going to inject N requests at one time, >>why not use writev() or sendmsg()? > > > No, it keeps N requests outstanding all the time, meaning, that when a > reply comes back, it sends out another request. I think this is > causing the problem. > > However the problem is more general, in that ssh should be able to > efficiently transport _any_ kind of protocol, no matter what I/O > pattern it uses. > > Does Nagle make sense for anything other than interactive sessions? > > Maybe turning it off if input/output is not a terminal makes sense, no? http://bugzilla.mindrot.org/show_bug.cgi?id=556 has been there for a while, but nobody commented on it. From miklos at szeredi.hu Thu Jan 26 20:22:51 2006 From: miklos at szeredi.hu (Miklos Szeredi) Date: Thu, 26 Jan 2006 10:22:51 +0100 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: <43D83FAB.2010807@mindrot.org> (message from Damien Miller on Thu, 26 Jan 2006 14:19:07 +1100) References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> <43D69DD6.70908@hp.com> <43D83FAB.2010807@mindrot.org> Message-ID: > http://bugzilla.mindrot.org/show_bug.cgi?id=556 has been there for a > while, but nobody commented on it. Ah. So TCP_NODELAY is already set for interactive sessions. I hadn't noticed that. It's actually pretty stupid I think, as Nagle (TCP_NODELAY off) _only_ makes sense for _interactive_ sessions. So it should be the other way round as it is currently. But unconditionally setting TCP_NODELAY should at least cure the sftp performance problem. The patch in comment #9 looks fine. Longer term I think you should consider adding "NoDelay" and maybe "NoDelayInteractive" bool options, and _not_ setting nodelay on interactive sessions by default. Miklos From djm at mindrot.org Thu Jan 26 20:42:52 2006 From: djm at mindrot.org (Damien Miller) Date: Thu, 26 Jan 2006 20:42:52 +1100 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> <43D69DD6.70908@hp.com> <43D83FAB.2010807@mindrot.org> Message-ID: <43D8999C.7040900@mindrot.org> Miklos Szeredi wrote: > So TCP_NODELAY is already set for interactive sessions. I hadn't > noticed that. > > It's actually pretty stupid I think, as Nagle (TCP_NODELAY off) _only_ > makes sense for _interactive_ sessions. It makes zero sense for interactive sessions - do you really want your keystrokes delayed? > So it should be the other way round as it is currently. > > But unconditionally setting TCP_NODELAY should at least cure the sftp > performance problem. The patch in comment #9 looks fine. We can look at turning Nagle off unconditionally after we get 4.3 out the door. > Longer term I think you should consider adding "NoDelay" and maybe > "NoDelayInteractive" bool options, and _not_ setting nodelay on > interactive sessions by default. No, we won't be adding any stupid button for people to push. -d From miklos at szeredi.hu Thu Jan 26 20:56:29 2006 From: miklos at szeredi.hu (Miklos Szeredi) Date: Thu, 26 Jan 2006 10:56:29 +0100 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: <43D8999C.7040900@mindrot.org> (message from Damien Miller on Thu, 26 Jan 2006 20:42:52 +1100) References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> <43D69DD6.70908@hp.com> <43D83FAB.2010807@mindrot.org> <43D8999C.7040900@mindrot.org> Message-ID: > > So TCP_NODELAY is already set for interactive sessions. I hadn't > > noticed that. > > > > It's actually pretty stupid I think, as Nagle (TCP_NODELAY off) _only_ > > makes sense for _interactive_ sessions. > > It makes zero sense for interactive sessions - do you really want your > keystrokes delayed? Over really slow links yes, that is the correct thing to do. Just consider the immense overhead of sending a separate packet for each keystroke. However nowdays it probably doesn't make much difference either way. But I do think that Nagle was invented exactly for the interactive kind of traffic. > > So it should be the other way round as it is currently. > > > > But unconditionally setting TCP_NODELAY should at least cure the sftp > > performance problem. The patch in comment #9 looks fine. > > We can look at turning Nagle off unconditionally after we get 4.3 out > the door. Fine. But just delaying this problem for ever is not the solution. And I can see posts from 2002 discussing exactly the same problem with sftp performance. People will try sftp and see that it's performance sucks, than they will probably think it's because of the crypto overhead and never bother to report it. They'll just use ftp instead or live with the slower download speeds. And it's not just on slow machines. I have a Pentum-M 1.6 and sftp download speed is 50Mb/s over a 100Mb/s link, while scp can easily use the full capacity. > > Longer term I think you should consider adding "NoDelay" and maybe > > "NoDelayInteractive" bool options, and _not_ setting nodelay on > > interactive sessions by default. > > No, we won't be adding any stupid button for people to push. I don't agree with that, but it's your choice. Miklos From rapier at psc.edu Fri Jan 27 04:25:08 2006 From: rapier at psc.edu (Chris Rapier) Date: Thu, 26 Jan 2006 12:25:08 -0500 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> <43D69DD6.70908@hp.com> <43D83FAB.2010807@mindrot.org> <43D8999C.7040900@mindrot.org> Message-ID: <43D905F4.8020603@psc.edu> Miklos Szeredi wrote: >>> So TCP_NODELAY is already set for interactive sessions. I hadn't >>> noticed that. >>> >>> It's actually pretty stupid I think, as Nagle (TCP_NODELAY off) _only_ >>> makes sense for _interactive_ sessions. >> It makes zero sense for interactive sessions - do you really want your >> keystrokes delayed? > > Over really slow links yes, that is the correct thing to do. Just > consider the immense overhead of sending a separate packet for each > keystroke. > > However nowdays it probably doesn't make much difference either way. > > But I do think that Nagle was invented exactly for the interactive > kind of traffic. If you break out your copy of Stevens TCP/IP Illustrated you'll find that this is correct. However, its not really designed to address slow links as much as it was designed to address congested links. The Nagle algorithm helps reduce overhead (so you don't send a 40 byte packet with 1 byte of useful information) and can increase the perceived and real efficiency of a network. Maybe there is some security reason dealing with traffic analysis to not use it though. However, if its just a matter of "well, the network is fat enough so it will forgive our inefficiencies" then that doesn't make a lot of sense. You never know what the congestion of the network will be unless you assume it to have infinite capacity. >>> So it should be the other way round as it is currently. >>> >>> But unconditionally setting TCP_NODELAY should at least cure the sftp >>> performance problem. The patch in comment #9 looks fine. >> We can look at turning Nagle off unconditionally after we get 4.3 out >> the door. > > Fine. But just delaying this problem for ever is not the solution. > And I can see posts from 2002 discussing exactly the same problem with > sftp performance. Better logic to control NODELAY usage makes sense. I never looked closely at this portion of the code but perhaps it could be triggered by a request for remote TTY. >>> Longer term I think you should consider adding "NoDelay" and maybe >>> "NoDelayInteractive" bool options, and _not_ setting nodelay on >>> interactive sessions by default. >> No, we won't be adding any stupid button for people to push. > > I don't agree with that, but it's your choice. I actually agree with Damien on this point. There shouldn't be a user setting. The software should be able to determine when NODELAY should and shouldn't be set. While it might be more difficult to create a generalized solution because of port fowarding issue a more specific solution that will capture 95% of the common usage situations should be feasible. From rick.jones2 at hp.com Fri Jan 27 04:37:28 2006 From: rick.jones2 at hp.com (Rick Jones) Date: Thu, 26 Jan 2006 09:37:28 -0800 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> <43D69DD6.70908@hp.com> <43D83FAB.2010807@mindrot.org> <43D8999C.7040900@mindrot.org> Message-ID: <43D908D8.5030907@hp.com> I ran a version (likely somewhat old) of what ships with HP-UX under a system call trace tool. I'm not exactly sure what I was seeing, but I did see several instances of call flow like: write four bytes to the socket write lots of bytes to the socket (<= 8KB IIRC) which smells (an awful lot) like something writing a message length to a socket and then writing the rest of the message. I also saw a pattern of read four bytes from a socket (a different one) read lots of bytes from a socket Which seemed to support the header, data hypothesis Now, the latter (read four read lots) is really just a question of CPU overheads, it does not affect what goes-out onto the network. However, the former looks like a classic case of an "unfortuneate" (if being dimplomatic, "buggy" if not) coding practice that quite easily runs afoul of Nagle - writing "logically associated data" to the connection in separate calls. Assuming my brief syscall trace analysis is correct and if that behaviour is the same in the contemporary versions of sftp, it might be better to fix that before asking to do TCP_NODELAY. Writing the logically associated data to the transport will allow a smaller number of segments to be sent, saving CPU util, and still not run afoul of Nagle. Setting TCP_NODELAY will only optimize (if we can even call it that) for time, and still send more segments than warranted. rick jones From rapier at psc.edu Fri Jan 27 05:47:05 2006 From: rapier at psc.edu (Chris Rapier) Date: Thu, 26 Jan 2006 13:47:05 -0500 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> <43D69DD6.70908@hp.com> <43D83FAB.2010807@mindrot.org> <43D8999C.7040900@mindrot.org> <43D905F4.8020603@psc.edu> Message-ID: <43D91929.5000700@psc.edu> Miklos Szeredi wrote: >> Better logic to control NODELAY usage makes sense. I never looked >> closely at this portion of the code but perhaps it could be triggered by >> a request for remote TTY. > > That is what the current code does. And that is the source of the > bug, since NODELAY is needed for some non-interactive traffic, like > sftp. I'm sorry. I must have read the previous messages wrong. I was under the impression that Nagle was being disabled for interactive sessions. Which is silly. >> I actually agree with Damien on this point. There shouldn't be a user >> setting. The software should be able to determine when NODELAY should >> and shouldn't be set. While it might be more difficult to create a >> generalized solution because of port fowarding issue a more specific >> solution that will capture 95% of the common usage situations should be >> feasible. > > Well, currently the software is doing the wrong decision, and I'm not > entirely convinced, that there is any other valid heuristic than to > turn NODELAY on unconditionally. hurm... because the ssh code is basically unaware of what the client, in this case sftp, is actually doing, right? So unless a switch is passed you can't identify the specific needs of the client? From Nicolas.Williams at sun.com Fri Jan 27 05:51:53 2006 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Thu, 26 Jan 2006 12:51:53 -0600 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: <43D8999C.7040900@mindrot.org> Message-ID: <20060126185153.GB15045@binky.Central.Sun.COM> On Thu Jan 26, 2006, Damien Miller wrote: > Miklos Szeredi wrote: First off, how can Nagle be affecting SFTP when SFTP would be doing "write(lots), write(lots), ..., read()"? I thought Nagle should only come into effect whem the app does (in Rick's handwaving terms) "write(little), write(little), ..., read()." Unless the pipe between ssh/sshd and sftp/sftp-server is breaking up the read/write size Nagle should not affect sftp. > > So TCP_NODELAY is already set for interactive sessions. I hadn't > > noticed that. > > > > It's actually pretty stupid I think, as Nagle (TCP_NODELAY off) _only_ > > makes sense for _interactive_ sessions. > > It makes zero sense for interactive sessions - do you really want your > keystrokes delayed? Whether it does or not, it clearly doesn't make sense to have Nagle on at the TCP layer when SSHv2 has its own channel multiplexing facility. Instead SSHv2 clients and servers ought to implement Nagle at the channel level wherever it is desirable (assuming it is desirable at all) and keep it off at the TCP layer altogether. Unfortunately without feedback from TCP about congestion there's no way to make Nagle adaptive at the SSHv2 connection layer. Oh well. Or could ssh/sshd turn Nagle on/off around the writing of SSHv2 packets for interactive channels (channels with ptys)? Nico -- From rapier at psc.edu Fri Jan 27 06:13:28 2006 From: rapier at psc.edu (Chris Rapier) Date: Thu, 26 Jan 2006 14:13:28 -0500 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> <43D69DD6.70908@hp.com> <43D83FAB.2010807@mindrot.org> <43D8999C.7040900@mindrot.org> <43D905F4.8020603@psc.edu> <43D91929.5000700@psc.edu> Message-ID: <43D91F58.5040201@psc.edu> >>> Well, currently the software is doing the wrong decision, and I'm not >>> entirely convinced, that there is any other valid heuristic than to >>> turn NODELAY on unconditionally. >> hurm... because the ssh code is basically unaware of what the client, in >> this case sftp, is actually doing, right? So unless a switch is passed >> you can't identify the specific needs of the client? > > Yes. But setting NODELAY by default seems a good idea regardless. Well, since its basically made for interactive session and interactive session have it disabled as it is then why not? Its easy enough to implement but honestly, I don't think its a very elegant solution. From miklos at szeredi.hu Fri Jan 27 05:01:53 2006 From: miklos at szeredi.hu (Miklos Szeredi) Date: Thu, 26 Jan 2006 19:01:53 +0100 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: <43D905F4.8020603@psc.edu> (message from Chris Rapier on Thu, 26 Jan 2006 12:25:08 -0500) References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> <43D69DD6.70908@hp.com> <43D83FAB.2010807@mindrot.org> <43D8999C.7040900@mindrot.org> <43D905F4.8020603@psc.edu> Message-ID: > Better logic to control NODELAY usage makes sense. I never looked > closely at this portion of the code but perhaps it could be triggered by > a request for remote TTY. That is what the current code does. And that is the source of the bug, since NODELAY is needed for some non-interactive traffic, like sftp. > I actually agree with Damien on this point. There shouldn't be a user > setting. The software should be able to determine when NODELAY should > and shouldn't be set. While it might be more difficult to create a > generalized solution because of port fowarding issue a more specific > solution that will capture 95% of the common usage situations should be > feasible. Well, currently the software is doing the wrong decision, and I'm not entirely convinced, that there is any other valid heuristic than to turn NODELAY on unconditionally. Miklos From rick.jones2 at hp.com Fri Jan 27 06:52:41 2006 From: rick.jones2 at hp.com (Rick Jones) Date: Thu, 26 Jan 2006 11:52:41 -0800 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> <43D69DD6.70908@hp.com> <43D83FAB.2010807@mindrot.org> <43D8999C.7040900@mindrot.org> <43D908D8.5030907@hp.com> Message-ID: <43D92889.10702@hp.com> >>However, the former looks like a classic case of an "unfortuneate" >>(if being dimplomatic, "buggy" if not) coding practice that quite >>easily runs afoul of Nagle - writing "logically associated data" to >>the connection in separate calls. > > > Yes, this is unfortunate. But I fixed it (see patch below) and it > didn't help. I think this would have actually triggered multiple > writes only very rarely on UP, since ssh would need to be scheduled in > between the two writes to actually see the split message, otherwise > the pipe would merge the two writes before it gets to ssh. A wise old engineer once told me the proper spelling was ass-u-me :) (Not that I'm perfect in following that advice mind you...) > > On SMP this may be worse, and applying the patch is a good idea anyway. > > It seems that sftp-server is already doing the right thing. > > >>Assuming my brief syscall trace analysis is correct and if that >>behaviour is the same in the contemporary versions of sftp, it might >>be better to fix that before asking to do TCP_NODELAY. > > > Done. Can I now have my NODELAY please ;) Got a syscall and packet trace showing "the right thing" being done?-) rick From miklos at szeredi.hu Fri Jan 27 05:32:10 2006 From: miklos at szeredi.hu (Miklos Szeredi) Date: Thu, 26 Jan 2006 19:32:10 +0100 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: <43D908D8.5030907@hp.com> (message from Rick Jones on Thu, 26 Jan 2006 09:37:28 -0800) References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> <43D69DD6.70908@hp.com> <43D83FAB.2010807@mindrot.org> <43D8999C.7040900@mindrot.org> <43D908D8.5030907@hp.com> Message-ID: > I ran a version (likely somewhat old) of what ships with HP-UX under > a system call trace tool. I'm not exactly sure what I was seeing, > but I did see several instances of call flow like: > > write four bytes to the socket > write lots of bytes to the socket (<= 8KB IIRC) > > which smells (an awful lot) like something writing a message length > to a socket and then writing the rest of the message. Yup. > I also saw a pattern of > > read four bytes from a socket (a different one) > read lots of bytes from a socket > > Which seemed to support the header, data hypothesis > > Now, the latter (read four read lots) is really just a question of > CPU overheads, it does not affect what goes-out onto the network. > > However, the former looks like a classic case of an "unfortuneate" > (if being dimplomatic, "buggy" if not) coding practice that quite > easily runs afoul of Nagle - writing "logically associated data" to > the connection in separate calls. Yes, this is unfortunate. But I fixed it (see patch below) and it didn't help. I think this would have actually triggered multiple writes only very rarely on UP, since ssh would need to be scheduled in between the two writes to actually see the split message, otherwise the pipe would merge the two writes before it gets to ssh. On SMP this may be worse, and applying the patch is a good idea anyway. It seems that sftp-server is already doing the right thing. > Assuming my brief syscall trace analysis is correct and if that > behaviour is the same in the contemporary versions of sftp, it might > be better to fix that before asking to do TCP_NODELAY. Done. Can I now have my NODELAY please ;) Miklos --- openssh-4.2p1/sftp-client.c 2005-08-02 09:07:08.000000000 +0200 +++ openssh-4.2p1.new/sftp-client.c 2006-01-26 19:22:39.000000000 +0100 @@ -57,16 +57,11 @@ static void send_msg(int fd, Buffer *m) { - u_char mlen[4]; - - if (buffer_len(m) > MAX_MSG_LENGTH) - fatal("Outbound message too long %u", buffer_len(m)); + if (buffer_len(m) - 4 > MAX_MSG_LENGTH) + fatal("Outbound message too long %u", buffer_len(m) - 4); /* Send length first */ - PUT_32BIT(mlen, buffer_len(m)); - if (atomicio(vwrite, fd, mlen, sizeof(mlen)) != sizeof(mlen)) - fatal("Couldn't send packet: %s", strerror(errno)); - + PUT_32BIT((u_char *) buffer_ptr(m), buffer_len(m) - 4); if (atomicio(vwrite, fd, buffer_ptr(m), buffer_len(m)) != buffer_len(m)) fatal("Couldn't send packet: %s", strerror(errno)); @@ -106,6 +101,7 @@ Buffer msg; buffer_init(&msg); + buffer_put_int(&msg, 0); buffer_put_char(&msg, code); buffer_put_int(&msg, id); buffer_put_string(&msg, s, len); @@ -121,6 +117,7 @@ Buffer msg; buffer_init(&msg); + buffer_put_int(&msg, 0); buffer_put_char(&msg, code); buffer_put_int(&msg, id); buffer_put_string(&msg, s, len); @@ -229,6 +226,7 @@ struct sftp_conn *ret; buffer_init(&msg); + buffer_put_int(&msg, 0); buffer_put_char(&msg, SSH2_FXP_INIT); buffer_put_int(&msg, SSH2_FILEXFER_VERSION); send_msg(fd_out, &msg); @@ -288,6 +286,7 @@ Buffer msg; buffer_init(&msg); + buffer_put_int(&msg, 0); id = conn->msg_id++; buffer_put_char(&msg, SSH2_FXP_CLOSE); @@ -317,6 +316,7 @@ id = conn->msg_id++; buffer_init(&msg); + buffer_put_int(&msg, 0); buffer_put_char(&msg, SSH2_FXP_OPENDIR); buffer_put_int(&msg, id); buffer_put_cstring(&msg, path); @@ -340,6 +340,7 @@ debug3("Sending SSH2_FXP_READDIR I:%u", id); buffer_clear(&msg); + buffer_put_int(&msg, 0); buffer_put_char(&msg, SSH2_FXP_READDIR); buffer_put_int(&msg, id); buffer_put_string(&msg, handle, handle_len); @@ -619,6 +620,7 @@ u_int status, id; buffer_init(&msg); + buffer_put_int(&msg, 0); /* Send rename request */ id = conn->msg_id++; @@ -651,6 +653,7 @@ } buffer_init(&msg); + buffer_put_int(&msg, 0); /* Send symlink request */ id = conn->msg_id++; @@ -726,6 +729,7 @@ buffer_init(&msg); buffer_clear(&msg); + buffer_put_int(&msg, 0); buffer_put_char(&msg, SSH2_FXP_READ); buffer_put_int(&msg, id); buffer_put_string(&msg, handle, handle_len); @@ -781,6 +785,7 @@ buflen = conn->transfer_buflen; buffer_init(&msg); + buffer_put_int(&msg, 0); /* Send open request */ id = conn->msg_id++; @@ -1022,6 +1027,7 @@ a.flags &= ~SSH2_FILEXFER_ATTR_ACMODTIME; buffer_init(&msg); + buffer_put_int(&msg, 0); /* Send open request */ id = conn->msg_id++; @@ -1077,6 +1083,7 @@ TAILQ_INSERT_TAIL(&acks, ack, tq); buffer_clear(&msg); + buffer_put_int(&msg, 0); buffer_put_char(&msg, SSH2_FXP_WRITE); buffer_put_int(&msg, ack->id); buffer_put_string(&msg, handle, handle_len); From rick.jones2 at hp.com Fri Jan 27 07:10:39 2006 From: rick.jones2 at hp.com (Rick Jones) Date: Thu, 26 Jan 2006 12:10:39 -0800 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: <43D91929.5000700@psc.edu> References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> <43D69DD6.70908@hp.com> <43D83FAB.2010807@mindrot.org> <43D8999C.7040900@mindrot.org> <43D905F4.8020603@psc.edu> <43D91929.5000700@psc.edu> Message-ID: <43D92CBF.3070702@hp.com> Chris Rapier wrote: > > Miklos Szeredi wrote: > >>>Better logic to control NODELAY usage makes sense. I never looked >>>closely at this portion of the code but perhaps it could be triggered by >>>a request for remote TTY. >> >>That is what the current code does. And that is the source of the >>bug, since NODELAY is needed for some non-interactive traffic, like >>sftp. > > > I'm sorry. I must have read the previous messages wrong. I was under the > impression that Nagle was being disabled for interactive sessions. Which > is silly. Likely as not overwhelming presure from folks who have things feeding escape sequences in one byte at a time, who haven't been bitten then by applications doing byte-at-a-time whole screen updates. rick jones is on the list, no need to cc in reply From markus at openbsd.org Fri Jan 27 06:08:24 2006 From: markus at openbsd.org (Markus Friedl) Date: Thu, 26 Jan 2006 20:08:24 +0100 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> <43D69DD6.70908@hp.com> <43D83FAB.2010807@mindrot.org> Message-ID: <20060126190824.GA17415@folly> On Thu, Jan 26, 2006 at 10:22:51AM +0100, Miklos Szeredi wrote: > > http://bugzilla.mindrot.org/show_bug.cgi?id=556 has been there for a > > while, but nobody commented on it. > > Ah. > > So TCP_NODELAY is already set for interactive sessions. I hadn't > noticed that. > > It's actually pretty stupid I think, as Nagle (TCP_NODELAY off) _only_ > makes sense for _interactive_ sessions. but not for things that send messages around like ssh does. however, it probably makes sense to always disable nagle in ssh. From rick.jones2 at hp.com Fri Jan 27 09:14:29 2006 From: rick.jones2 at hp.com (Rick Jones) Date: Thu, 26 Jan 2006 14:14:29 -0800 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> <43D69DD6.70908@hp.com> <43D83FAB.2010807@mindrot.org> <43D8999C.7040900@mindrot.org> <43D908D8.5030907@hp.com> <43D92889.10702@hp.com> Message-ID: <43D949C5.9060404@hp.com> Miklos Szeredi wrote: >>>Done. Can I now have my NODELAY please ;) >> >>Got a syscall and packet trace showing "the right thing" being done?-) > > > Can send it tomorrow. But the best indication that it's right is that > the performance problem is gone. Ah then you misunderstood what I was getting at, sorry. Although seeing the traces with TCP_NODELAY set would be interesting, I meant traces showing sftp behaving properly and still getting hit with delays attributable to the Nagle algorithm. > I don't know how far 4.3 is in the freeze state, but unconditionally > setting NODELAY seems quite safe. It is bound to drastically improve > performance for many people, while any noticable performance > regression is highly unlikely. But anyway I leave that to you guys to > decide. HP-UX in 11.X decided to unconditionally disable Nagle in their telnetd. They then discovered a whole slew of folks with "slow" clients that were then getting swamped by the thousands of tiny packets per second from a screen dump...they started dropping packets and thngs were worse than before. So I'd say that I do not agree with your assesment that noticable performance regression is highly unlikely. rick jones on the list, no need to be cc'd From rick.jones2 at hp.com Fri Jan 27 09:17:02 2006 From: rick.jones2 at hp.com (Rick Jones) Date: Thu, 26 Jan 2006 14:17:02 -0800 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: <20060126190824.GA17415@folly> References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> <43D69DD6.70908@hp.com> <43D83FAB.2010807@mindrot.org> <20060126190824.GA17415@folly> Message-ID: <43D94A5E.7010705@hp.com> > but not for things that send messages around like > ssh does. however, it probably makes sense to > always disable nagle in ssh. Sending messages in and of themselves isn't an issue with Nagle. Sending messages in separate calls to send() is an issue that interacts with Nagle. rick j ones From miklos at szeredi.hu Fri Jan 27 06:01:31 2006 From: miklos at szeredi.hu (Miklos Szeredi) Date: Thu, 26 Jan 2006 20:01:31 +0100 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: <43D91929.5000700@psc.edu> (message from Chris Rapier on Thu, 26 Jan 2006 13:47:05 -0500) References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> <43D69DD6.70908@hp.com> <43D83FAB.2010807@mindrot.org> <43D8999C.7040900@mindrot.org> <43D905F4.8020603@psc.edu> <43D91929.5000700@psc.edu> Message-ID: > >> Better logic to control NODELAY usage makes sense. I never looked > >> closely at this portion of the code but perhaps it could be triggered by > >> a request for remote TTY. > > > > That is what the current code does. And that is the source of the > > bug, since NODELAY is needed for some non-interactive traffic, like > > sftp. > > I'm sorry. I must have read the previous messages wrong. I was under the > impression that Nagle was being disabled for interactive sessions. Which > is silly. Nagle _is_ disabled for interactive sessions. TCP_NODELAY disables Nagle and current ssh sets TCP_NODELAY iff session is interactive. > > Well, currently the software is doing the wrong decision, and I'm not > > entirely convinced, that there is any other valid heuristic than to > > turn NODELAY on unconditionally. > > hurm... because the ssh code is basically unaware of what the client, in > this case sftp, is actually doing, right? So unless a switch is passed > you can't identify the specific needs of the client? Yes. But setting NODELAY by default seems a good idea regardless. Miklos From miklos at szeredi.hu Fri Jan 27 08:01:43 2006 From: miklos at szeredi.hu (Miklos Szeredi) Date: Thu, 26 Jan 2006 22:01:43 +0100 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: <43D92889.10702@hp.com> (message from Rick Jones on Thu, 26 Jan 2006 11:52:41 -0800) References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> <43D69DD6.70908@hp.com> <43D83FAB.2010807@mindrot.org> <43D8999C.7040900@mindrot.org> <43D908D8.5030907@hp.com> <43D92889.10702@hp.com> Message-ID: > > Done. Can I now have my NODELAY please ;) > > Got a syscall and packet trace showing "the right thing" being done?-) Can send it tomorrow. But the best indication that it's right is that the performance problem is gone. I don't know how far 4.3 is in the freeze state, but unconditionally setting NODELAY seems quite safe. It is bound to drastically improve performance for many people, while any noticable performance regression is highly unlikely. But anyway I leave that to you guys to decide. Miklos From miklos at szeredi.hu Fri Jan 27 21:07:23 2006 From: miklos at szeredi.hu (Miklos Szeredi) Date: Fri, 27 Jan 2006 11:07:23 +0100 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: <43D949C5.9060404@hp.com> (message from Rick Jones on Thu, 26 Jan 2006 14:14:29 -0800) References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> <43D69DD6.70908@hp.com> <43D83FAB.2010807@mindrot.org> <43D8999C.7040900@mindrot.org> <43D908D8.5030907@hp.com> <43D92889.10702@hp.com> <43D949C5.9060404@hp.com> Message-ID: > >>>Done. Can I now have my NODELAY please ;) > >> > >>Got a syscall and packet trace showing "the right thing" being > >>done?-) > > > > > > Can send it tomorrow. But the best indication that it's right is > > that the performance problem is gone. > > Ah then you misunderstood what I was getting at, sorry. Although > seeing the traces with TCP_NODELAY set would be interesting, I meant > traces showing sftp behaving properly and still getting hit with > delays attributable to the Nagle algorithm. Sent off-list. > > I don't know how far 4.3 is in the freeze state, but unconditionally > > setting NODELAY seems quite safe. It is bound to drastically improve > > performance for many people, while any noticable performance > > regression is highly unlikely. But anyway I leave that to you guys to > > decide. > > HP-UX in 11.X decided to unconditionally disable Nagle in their > telnetd. They then discovered a whole slew of folks with "slow" > clients that were then getting swamped by the thousands of tiny > packets per second from a screen dump...they started dropping > packets and thngs were worse than before. So I'd say that I do not > agree with your assesment that noticable performance regression is > highly unlikely. Ah, but telnet generates interactive traffic, ssh is already broken for that case. Now the interesting problem is non-interative traffic, for which ssh is clearly broken in _some_ cases. Others it's not broken: e.g. for "scp" Nagle is totally irrelevant, because it only sends big packets in one direction. What else is there? Port forwarding? That is _usually_ done through an interactive session, so again no difference. I really can't imagine Nagle helping all that much, when it's already disabled (without people noticing) for the most important case of interactive traffic. Miklos From rapier at psc.edu Sat Jan 28 04:51:05 2006 From: rapier at psc.edu (Chris Rapier) Date: Fri, 27 Jan 2006 12:51:05 -0500 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> <43D69DD6.70908@hp.com> <43D83FAB.2010807@mindrot.org> <43D8999C.7040900@mindrot.org> <43D908D8.5030907@hp.com> <43D92889.10702@hp.com> <43D949C5.9060404@hp.com> Message-ID: <43DA5D89.9080105@psc.edu> Miklos Szeredi wrote: > > Ah, but telnet generates interactive traffic, ssh is already broken > for that case. > > Now the interesting problem is non-interative traffic, for which ssh > is clearly broken in _some_ cases. Others it's not broken: e.g. for > "scp" Nagle is totally irrelevant, because it only sends big packets > in one direction. > > What else is there? Port forwarding? That is _usually_ done through > an interactive session, so again no difference. > > I really can't imagine Nagle helping all that much, when it's already > disabled (without people noticing) for the most important case of > interactive traffic. I actually forgot about something which leads me to believe that disabling Nagle in all cases is appropriate appropriate at this time. Delayed ACK. Bad interactions. Also, I forgot, if you ever end up using multiple channels in SSH (it is multiplexed after all) I think you can only use Nagle on a per connection (not per channel) basis. That is what SFTP is doing isn't it? A data channel and control channel in the same connection? It would be nice to get a better mechanism in place because not having Nagle is inherently limiting. Being that ssh is multiplexed anyway you could probably just re-implement something like it on a per channel basis. From rick.jones2 at hp.com Sat Jan 28 06:44:17 2006 From: rick.jones2 at hp.com (Rick Jones) Date: Fri, 27 Jan 2006 11:44:17 -0800 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: <43DA5D89.9080105@psc.edu> References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> <43D69DD6.70908@hp.com> <43D83FAB.2010807@mindrot.org> <43D8999C.7040900@mindrot.org> <43D908D8.5030907@hp.com> <43D92889.10702@hp.com> <43D949C5.9060404@hp.com> <43DA5D89.9080105@psc.edu> Message-ID: <43DA7811.6050209@hp.com> > Also, I forgot, if you ever end up using > multiple channels in SSH (it is multiplexed after all) I think you can > only use Nagle on a per connection (not per channel) basis. That is correct - TCP_NODELAY is for the "whole" TCP connection, not slices of it created by anything above it. > That is what SFTP is doing isn't it? A data channel and control channel in > the same connection? That could be fun... if the sftp control vs data traffic mimmics that of FTP I'd think there wouldn't be all that much interleave though. rick jones still seeking cycles to look at traces :( From djm at mindrot.org Sat Jan 28 16:25:34 2006 From: djm at mindrot.org (Damien Miller) Date: Sat, 28 Jan 2006 16:25:34 +1100 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: <43DA7811.6050209@hp.com> References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> <43D69DD6.70908@hp.com> <43D83FAB.2010807@mindrot.org> <43D8999C.7040900@mindrot.org> <43D908D8.5030907@hp.com> <43D92889.10702@hp.com> <43D949C5.9060404@hp.com> <43DA5D89.9080105@psc.edu> <43DA7811.6050209@hp.com> Message-ID: <43DB004E.5020900@mindrot.org> Rick Jones wrote: >>That is what SFTP is doing isn't it? A data channel and control channel in >>the same connection? > > That could be fun... if the sftp control vs data traffic mimmics that of FTP > I'd think there wouldn't be all that much interleave though. sftp does its control in-band. -d From openssh at roumenpetrov.info Mon Jan 30 01:20:56 2006 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Sun, 29 Jan 2006 16:20:56 +0200 Subject: ssh.1(may be after 20060106) and .pub files Message-ID: <43DCCF48.5080609@roumenpetrov.info> Quote: ================================================== .... ~/.ssh/identity.pub ~/.ssh/id_dsa.pub ~/.ssh/id_rsa.pub Contains the public key for authentication. These files are not sensitive and can (but need not) be readable by anyone. They are never used automatically and are not necessary: they are only provided for the convenience of the user. .... ================================================== The phrase "They are never used automatically ..." is incorrect. The ssh client automatically read .pub file for specified identities, send public keys to server and when key is accepted then ssh read private key, might ask user for password and send signed user authentication request. If the .pub file don't exist ssh will read private key, might ask user for password, send it to the server and when key is accepted then ssh will use it in actual authentication. Test command: ssh -vvv -i id_dsa .... Remove the file id_dsa.pub and run command again. Compare output in both cases. The command ssh-add use pub file to delete key from agent. Test to delete key form agent with and wihtout pub file. Regards, Roumen From rapier at psc.edu Mon Jan 30 05:56:11 2006 From: rapier at psc.edu (Chris Rapier) Date: Sun, 29 Jan 2006 13:56:11 -0500 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> <43D69DD6.70908@hp.com> <43D83FAB.2010807@mindrot.org> <43D8999C.7040900@mindrot.org> <43D908D8.5030907@hp.com> <43D92889.10702@hp.com> <43D949C5.9060404@hp.com> <43DA5D89.9080105@psc.edu> Message-ID: <43DD0FCB.4060509@psc.edu> Miklos Szeredi wrote: >> It would be nice to get a better mechanism in place because not >> having Nagle is inherently limiting. Being that ssh is multiplexed >> anyway you could probably just re-implement something like it on a >> per channel basis. > > Ssh doesn't see it as two separate channels, just a single > bidirectional stream. Really? My understanding is that the application layer congestion control in ssh2 is occurring on a per channel basis. So something in there is aware of multiple channels and can act on them appropriately. > Also I'm not sure if it's possible to implement Nagle in the > application layer, without knowledge of network congestion state. Thats a good point. It would have to know what is happening with unacked outstanding data. This is more difficult with some OSes but some versions of linux 2.4 and all of 2.6 and the new windows Vista have a TCP MIB available for SNMP queries. So application layer awareness of the network layer is feasible in some instances. The question is if it would be worth the hassle. Of course, in this case its probably not worth it for what is probably going to be an ever decreasing number of edge cases vis a vis nagle. From Philippe.LeGal at emea.eu.int Mon Jan 30 20:37:55 2006 From: Philippe.LeGal at emea.eu.int (Le Gal Philippe) Date: Mon, 30 Jan 2006 09:37:55 -0000 Subject: badpw[] = "\b\n\r\177INCORRECT" Message-ID: Hi ! I'm trying to authenticate users on a Linux Red hat AS 2.1 against a radius server. I have upgraded my OpenSSHd to : OpenSSH_4.2p1, OpenSSL 0.9.6b [engine] 9 Jul 2001 The users accounts are NOT stored locally on the sever (no accounts in /etc/passwd ). Users ssh to the box : ssh test at testserver.com passwd: test I'm usign PAM to direct the authentication request to the radius server. That part works fine. But the request coming to the radius looks like : User-Name = "test" User-Password = "\010\n\INCORRECT" I found this in : auth-pam.c badpw[] = "\b\n\r\177INCORRECT"; - What is supposed to be the behaviour of ssh when it is used with PAM ? Shall SSh pass on to PAM the exact credentials entered at the prompt (username and passwd) without affecting them (by putting "INCORRECT" in the passwd : buffer_put_cstring(&buffer, badpw); auth-pam.c in sshpam_respond() )? (BTW, this is how I have installed ssh on my linux box : ./configure --with-pam --prefix=/usr --sysconfdir=/etc/ssh make make install) - I found that other OpenSSH user had a similar problem. Is there a workaround ? Thank you for your help. I'm really struggling with this... ! Philippe ________________________________________________________________________ This e-mail has been scanned for all known viruses by EMEA. ________________________________________________________________________ From dtucker at zip.com.au Mon Jan 30 20:55:39 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 30 Jan 2006 20:55:39 +1100 Subject: badpw[] = "\b\n\r\177INCORRECT" In-Reply-To: References: Message-ID: <20060130095539.GA9315@gate.dtucker.net> On Mon, Jan 30, 2006 at 09:37:55AM -0000, Le Gal Philippe wrote: > Hi ! > > I'm trying to authenticate users on a Linux Red hat AS 2.1 against a > radius server. > > I have upgraded my OpenSSHd to : > OpenSSH_4.2p1, OpenSSL 0.9.6b [engine] 9 Jul 2001 > The users accounts are NOT stored locally on the sever (no accounts in > /etc/passwd ). Users ssh to the box : ssh test at testserver.com passwd: > test I'm usign PAM to direct the authentication request to the radius > server. That part works fine. > But the request coming to the radius looks like : > > User-Name = "test" > User-Password = "\010\n\INCORRECT" sshd does that when the user doesn't exist or is otherwise prohibitted from logging on the the system in question (ie when they are flagged as "invalid" or "illegal" users). If it didn't do this then an attacker may be able to distinguish between valid and invalid accounts and/or the correct password for an account not permitted to log in at all via ssh (there's a CVE or two for these type of problems). > - I found that other OpenSSH user had a similar problem. Is there a > workaround ? Configure your name service (eg nsswitch.conf) to return passwd entries for your RADIUS users (eg with nss_radius). -- 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 jmc at kerhand.co.uk Tue Jan 31 00:37:05 2006 From: jmc at kerhand.co.uk (Jason McIntyre) Date: Mon, 30 Jan 2006 13:37:05 +0000 Subject: ssh.1(may be after 20060106) and .pub files In-Reply-To: <43DCCF48.5080609@roumenpetrov.info> References: <43DCCF48.5080609@roumenpetrov.info> Message-ID: <20060130133728.GB4188@tinker.kerhand.co.uk> On Sun, Jan 29, 2006 at 04:20:56PM +0200, Roumen Petrov wrote: > Quote: > ================================================== > .... > ~/.ssh/identity.pub > ~/.ssh/id_dsa.pub > ~/.ssh/id_rsa.pub > Contains the public key for authentication. These files are > not > sensitive and can (but need not) be readable by anyone. They > are > never used automatically and are not necessary: they are only > provided for the convenience of the user. > .... > ================================================== > > > The phrase "They are never used automatically ..." is incorrect. > the sentence has just been removed. thanks for the mail. jmc From dot at dotat.at Tue Jan 31 06:01:05 2006 From: dot at dotat.at (Tony Finch) Date: Mon, 30 Jan 2006 19:01:05 +0000 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> <43D69382.8080504@hp.com> Message-ID: Miklos Szeredi wrote: >> In broad handwaving terms, applications that try to do "write write >> read" can run afoul of interactions between Nagle and delayed ACK. > >Which is exactly what sftp does. > >Excerpt from sftp(1): > >| -R num_requests >| Specify how many requests may be outstanding at any one time. >| Increasing this may slightly improve file transfer speed but >| will increase memory usage. The default is 16 outstanding >| requests. > >I also noticed, that -R 1 actually increases throughput in some cases, >which is nicely explained by the fact, that then it will always be >"write read" pairs. > >Of course -R 1 will still result in suboptimal throughput, so that is >not the solution. Actually this part of the SFTP protocol is disastrous for links with large bandwith * delay products, and it's pointless given that the underlying TCP connection is already doing windowing. SFTP should just send data as fast as it can. http://www.cs.auckland.ac.nz/~pgut001/pubs/app_sec.pdf Tony. -- f.a.n.finch http://dotat.at/ BISCAY: EAST 4 OR 5 BECOMING VARIABLE 3 OR 4. MAINLY FAIR. MODERATE OR GOOD. From openssh-unix-dev at mlists.thewrittenword.com Tue Jan 31 06:27:55 2006 From: openssh-unix-dev at mlists.thewrittenword.com (Albert Chin) Date: Mon, 30 Jan 2006 13:27:55 -0600 Subject: CVE-2006-0225 Message-ID: <20060130192755.GA97432@mail1.thewrittenword.com> Any plans to incorporate the Fedora patch for CVE-2006-0225: http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0225 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168167 -- albert chin (china at thewrittenword.com) From rapier at psc.edu Tue Jan 31 06:50:30 2006 From: rapier at psc.edu (Chris Rapier) Date: Mon, 30 Jan 2006 14:50:30 -0500 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> <43D69382.8080504@hp.com> Message-ID: <43DE6E06.1000804@psc.edu> Tony Finch wrote: > Actually this part of the SFTP protocol is disastrous for links with large > bandwith * delay products, and it's pointless given that the underlying > TCP connection is already doing windowing. SFTP should just send data > as fast as it can. I think to do that it would have to bypass the channel layer congestion control that SSH uses. Has anyone with the SFTP problems tried it using SSHv1 (assuming that is possible)? Also, has anyone tried this with SFTP using the HPN patch? From dtucker at zip.com.au Tue Jan 31 07:40:17 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 31 Jan 2006 07:40:17 +1100 Subject: CVE-2006-0225 In-Reply-To: <20060130192755.GA97432@mail1.thewrittenword.com> References: <20060130192755.GA97432@mail1.thewrittenword.com> Message-ID: <20060130204017.GA16467@gate.dtucker.net> On Mon, Jan 30, 2006 at 01:27:55PM -0600, Albert Chin wrote: > Any plans to incorporate the Fedora patch for CVE-2006-0225: > http://www.cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-0225 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=168167 Yes, work is going on over at: http://bugzilla.mindrot.org/show_bug.cgi?id=1094 -- 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 Josh.Wyatt at hcssystems.com Tue Jan 31 07:42:08 2006 From: Josh.Wyatt at hcssystems.com (Josh Wyatt) Date: Mon, 30 Jan 2006 15:42:08 -0500 Subject: Compiling openssh statically? Message-ID: <43DE7A20.8060700@hcssystems.com> Greetings, [non-list member, here] I'm wondering if it's possible to compile openssh-4.2p1 (portable) statically. The platform is Linux 2.4 x86, openssl-0.9.7i, zlib-1.2.3, gcc-3.3.5. Thanks, Josh From dtucker at zip.com.au Tue Jan 31 08:33:11 2006 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 31 Jan 2006 08:33:11 +1100 Subject: Compiling openssh statically? In-Reply-To: <43DE7A20.8060700@hcssystems.com> References: <43DE7A20.8060700@hcssystems.com> Message-ID: <20060130213310.GA16836@gate.dtucker.net> On Mon, Jan 30, 2006 at 03:42:08PM -0500, Josh Wyatt wrote: > I'm wondering if it's possible to compile openssh-4.2p1 (portable) statically. > The platform is Linux 2.4 x86, openssl-0.9.7i, zlib-1.2.3, gcc-3.3.5. Sure, as long as you have static versions of all required libraries available (and they work, of course :-). Just do something like: ./configure --with-ldflags=-static The only thing to watch out for is OS components that load modules at runtime (eg nss or PAM modules). I'm not sure how those will behave. -- 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 dwmw2 at infradead.org Tue Jan 31 10:17:20 2006 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 31 Jan 2006 10:17:20 +1100 Subject: ownership of authorized_keys In-Reply-To: <200601191709.k0JH9RvK022835@sun601.nas.nasa.gov> References: <200601191709.k0JH9RvK022835@sun601.nas.nasa.gov> Message-ID: <1138663041.23965.52.camel@localhost.localdomain> On Thu, 2006-01-19 at 09:09 -0800, Iain Morgan wrote: > That's already the case. The files can be owned by root, but they must > be readable by the user. Either use a per-user group or POSIX ACLs to > allow the user to read the contents. Or just allow them to be world-readable, of course. These are _public_ keys we're talking about, after all. -- dwmw2 From miklos at szeredi.hu Sun Jan 29 22:03:41 2006 From: miklos at szeredi.hu (Miklos Szeredi) Date: Sun, 29 Jan 2006 12:03:41 +0100 Subject: sftp performance problem, cured by TCP_NODELAY In-Reply-To: <43DA5D89.9080105@psc.edu> (message from Chris Rapier on Fri, 27 Jan 2006 12:51:05 -0500) References: <43D670B7.80801@hp.com> <43D69382.8080504@hp.com> <43D69DD6.70908@hp.com> <43D83FAB.2010807@mindrot.org> <43D8999C.7040900@mindrot.org> <43D908D8.5030907@hp.com> <43D92889.10702@hp.com> <43D949C5.9060404@hp.com> <43DA5D89.9080105@psc.edu> Message-ID: > > I really can't imagine Nagle helping all that much, when it's already > > disabled (without people noticing) for the most important case of > > interactive traffic. > > I actually forgot about something which leads me to believe that > disabling Nagle in all cases is appropriate appropriate at this > time. Delayed ACK. Bad interactions. Also, I forgot, if you ever > end up using multiple channels in SSH (it is multiplexed after all) > I think you can only use Nagle on a per connection (not per channel) > basis. That is what SFTP is doing isn't it? A data channel and > control channel in the same connection? Yes. > It would be nice to get a better mechanism in place because not > having Nagle is inherently limiting. Being that ssh is multiplexed > anyway you could probably just re-implement something like it on a > per channel basis. Ssh doesn't see it as two separate channels, just a single bidirectional stream. Also I'm not sure if it's possible to implement Nagle in the application layer, without knowledge of network congestion state. Miklos From Philippe.LeGal at emea.eu.int Tue Jan 31 22:22:38 2006 From: Philippe.LeGal at emea.eu.int (Le Gal Philippe) Date: Tue, 31 Jan 2006 11:22:38 -0000 Subject: badpw[] = "\b\n\r\177INCORRECT" Message-ID: Thank you for your prompt answer Darren, Unfortunately, it seems that nss_radius project looks like a dead-end as I can't find any module already written for it. I'm failty new to all this and I don't want to spend my time writing a nss_radius module. Do you know if such a module exists somewhere ? Thank you Philippe -----Original Message----- From: Darren Tucker [mailto:dtucker at zip.com.au] Sent: 30 January 2006 09:56 To: Le Gal Philippe Cc: openssh-unix-dev at mindrot.org Subject: Re: badpw[] = "\b\n\r\177INCORRECT" On Mon, Jan 30, 2006 at 09:37:55AM -0000, Le Gal Philippe wrote: > Hi ! > > I'm trying to authenticate users on a Linux Red hat AS 2.1 against a > radius server. > > I have upgraded my OpenSSHd to : > OpenSSH_4.2p1, OpenSSL 0.9.6b [engine] 9 Jul 2001 > The users accounts are NOT stored locally on the sever (no accounts in > /etc/passwd ). Users ssh to the box : ssh test at testserver.com passwd: > test I'm usign PAM to direct the authentication request to the radius > server. That part works fine. > But the request coming to the radius looks like : > > User-Name = "test" > User-Password = "\010\n\INCORRECT" sshd does that when the user doesn't exist or is otherwise prohibitted from logging on the the system in question (ie when they are flagged as "invalid" or "illegal" users). If it didn't do this then an attacker may be able to distinguish between valid and invalid accounts and/or the correct password for an account not permitted to log in at all via ssh (there's a CVE or two for these type of problems). > - I found that other OpenSSH user had a similar problem. Is there a > workaround ? Configure your name service (eg nsswitch.conf) to return passwd entries for your RADIUS users (eg with nss_radius). -- 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. ________________________________________________________________________ This e-mail has been scanned for all known viruses by EMEA. ________________________________________________________________________