From John.Cecere at Sun.COM Wed Dec 1 06:58:13 2004 From: John.Cecere at Sun.COM (John Cecere) Date: Tue, 30 Nov 2004 14:58:13 -0500 Subject: getpwuid vs. getpwnam Message-ID: <41ACD0D5.8020106@sun.com> This issue has probably been brought up before, but I'll mention it anyway. I just downloaded and built openssh 3.9p1 on Solaris 8. In my environment, I have two root accounts. The normal one and an alternate one (rjohn - uid 0) with it's own home directory (/export/home/rjohn). After building and installing openssh, I was having trouble getting my RSA authentication to work. In investigating it, I noticed that it was attempting to use /.ssh/id_rsa.pub as my public key file instead of /export/home/rjohn/.ssh/id_rsa.pub. Digging a little deeper, I found that, in the client modules ssh.c and tildexpand.c, it uses the call getpwuid(uid) as the basis for determining what the user's home directory is. In my case, this resolves to / instead of /export/home/rjohn. Wouldn't it be more appropriate to use something like getpwnam(getenv("LOGNAME")) instead ? Since the login program itself (in both Linux and Solaris) sets LOGNAME, it's a reasonably safe assumption that it will get set correctly. Even if it's not set, the program could check that there's a value in LOGNAME, and if there isn't, fall back to using getpwuid. The login program (in both Linux and Solaris) uses getpwnam and not getpwuid to retrieve the passwd information. The getpwuid call just looks at the first password entry that has that uid, which may not be the one you're looking for. Any thoughts ? Please respond directly. Thanks, John -- John Cecere Sun Microsystems 732-302-3922 / john.cecere at sun.com From mouring at etoh.eviladmin.org Wed Dec 1 07:29:40 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Tue, 30 Nov 2004 14:29:40 -0600 (CST) Subject: getpwuid vs. getpwnam In-Reply-To: <41ACD0D5.8020106@sun.com> Message-ID: On Tue, 30 Nov 2004, John Cecere wrote: > This issue has probably been brought up before, but I'll mention it anyway. > > I just downloaded and built openssh 3.9p1 on Solaris 8. In my > environment, I have two root accounts. The normal one and an alternate > one (rjohn - uid 0) with it's own home directory (/export/home/rjohn). > After building and installing openssh, I was having trouble getting my > RSA authentication to work. In investigating it, I noticed that it was > attempting to use /.ssh/id_rsa.pub as my public key file instead of > /export/home/rjohn/.ssh/id_rsa.pub. Digging a little deeper, I found > that, in the client modules ssh.c and tildexpand.c, it uses the call > getpwuid(uid) as the basis for determining what the user's home > directory is. In my case, this resolves to / instead of /export/home/rjohn. > > Wouldn't it be more appropriate to use something like > getpwnam(getenv("LOGNAME")) instead ? Since the login program itself (in > both Linux and Solaris) sets LOGNAME, it's a reasonably safe assumption > that it will get set correctly. Even if it's not set, the program could We don't call /sbin/login by default. Therefor who would set it? - Ben From John.Cecere at Sun.COM Wed Dec 1 08:43:04 2004 From: John.Cecere at Sun.COM (John Cecere) Date: Tue, 30 Nov 2004 16:43:04 -0500 Subject: getpwuid vs. getpwnam In-Reply-To: References: Message-ID: <41ACE968.8090902@sun.com> Ben Lindstrom wrote: >On Tue, 30 Nov 2004, John Cecere wrote: > > > >>This issue has probably been brought up before, but I'll mention it anyway. >> >>I just downloaded and built openssh 3.9p1 on Solaris 8. In my >>environment, I have two root accounts. The normal one and an alternate >>one (rjohn - uid 0) with it's own home directory (/export/home/rjohn). >>After building and installing openssh, I was having trouble getting my >>RSA authentication to work. In investigating it, I noticed that it was >>attempting to use /.ssh/id_rsa.pub as my public key file instead of >>/export/home/rjohn/.ssh/id_rsa.pub. Digging a little deeper, I found >>that, in the client modules ssh.c and tildexpand.c, it uses the call >>getpwuid(uid) as the basis for determining what the user's home >>directory is. In my case, this resolves to / instead of /export/home/rjohn. >> >>Wouldn't it be more appropriate to use something like >>getpwnam(getenv("LOGNAME")) instead ? Since the login program itself (in >>both Linux and Solaris) sets LOGNAME, it's a reasonably safe assumption >>that it will get set correctly. Even if it's not set, the program could >> >> > >We don't call /sbin/login by default. Therefor who would set it? > > - Ben > > > Ben, It appears that it's getting set by sshd. I ran a debug session on the server, and this is what the client tells me: scoobydoo# ssh -l rjohn saturn Last login: Tue Nov 30 16:18:14 2004 from scoobydoo pw->pw_name = rjohn Environment: USER=rjohn LOGNAME=rjohn HOME=/export/home/rjohn PATH=/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin MAIL=/var/mail//rjohn SHELL=/bin/ksh TZ=US/Eastern SSH_CLIENT=129.154.57.77 1023 22 SSH_CONNECTION=129.154.57.77 1023 129.154.57.49 22 SSH_TTY=/dev/pts/2 TERM=xterm Sun Microsystems Inc. SunOS 5.8 Generic Patch October 2001 saturn# I don't have UseLogin set in my config file here. It looks like the chunk of code below from session.c is setting LOGNAME. However, I'm not sure that this is totally related to what I'm talking about. I put a printf right before the line that references LOGNAME below (notice the line above that reads pw->pw_name = rjohn). The way it derives pw->pw_name below (session.c is a module of the server, not the client) seems to be different than the way it's derived from the client to determine what the user's home directory is for parsing the .ssh directory. I haven't traced back where the *pw structure is getting set for this module, but I'm going to guess that it wasn't a call to getpwuid if (!options.use_login) { /* Set basic environment. */ for (i = 0; i < s->num_env; i++) child_set_env(&env, &envsize, s->env[i].name, s->env[i].val); child_set_env(&env, &envsize, "USER", pw->pw_name); child_set_env(&env, &envsize, "LOGNAME", pw->pw_name); #ifdef _AIX child_set_env(&env, &envsize, "LOGIN", pw->pw_name); #endif child_set_env(&env, &envsize, "HOME", pw->pw_dir); #ifdef HAVE_LOGIN_CAP if (setusercontext(lc, pw, pw->pw_uid, LOGIN_SETPATH) < 0) child_set_env(&env, &envsize, "PATH", _PATH_STDPATH); else child_set_env(&env, &envsize, "PATH", getenv("PATH")); #else /* HAVE_LOGIN_CAP */ # ifndef HAVE_CYGWIN /* * There's no standard path on Windows. The path contains * important components pointing to the system directories, * needed for loading shared libraries. So the path better * remains intact here. */ # ifdef HAVE_ETC_DEFAULT_LOGIN read_etc_default_login(&env, &envsize, pw->pw_uid); path = child_get_env(env, "PATH"); # endif /* HAVE_ETC_DEFAULT_LOGIN */ if (path == NULL || *path == '\0') { child_set_env(&env, &envsize, "PATH", s->pw->pw_uid == 0 ? SUPERUSER_PATH : _PATH_STDPATH); } Thanks, John -- John Cecere Sun Microsystems 732-302-3922 / john.cecere at sun.com From kryza at medialogic.it Thu Dec 2 02:40:12 2004 From: kryza at medialogic.it (Grzegorz Kryza) Date: Wed, 01 Dec 2004 16:40:12 +0100 Subject: $HOME instead of pw->pw_dir question. Message-ID: <41ADE5DC.7090304@medialogic.it> Hello. I have one, small question. There are any security reasons to not use a getenv("HOME") instead of pw->pw_dir in ssh.c and tildexpand.c to find user home directory? -- Grzegorz Kryza mailto: kryza at nomachine.com http://grzegorz.kryza.net From frederik at a5.repetae.net Thu Dec 2 09:19:28 2004 From: frederik at a5.repetae.net (frederik at a5.repetae.net) Date: Wed, 1 Dec 2004 14:19:28 -0800 Subject: remote command word splitting Message-ID: <20041201221928.GA18434@a5.repetae.net> Hello, I have a suggestion about the way ssh does word splitting on commands which have been passed to it for remote execution. It appears that what is currently done is, if there are extra arguments on the ssh command line for a remote command, (1) split each of these arguments into a list (2) concatenate the resulting lists to get the command arguments. So we get behavior like $ perl -le 'die "hi"' hi at -e line 1. $ ssh some-host perl -le 'die "hi"' Died at -e line 1. (The remote perl program executed differently because ssh split the eval text into separate arguments) This is a gotcha that seems to come up a lot for me. Many commands require arguments with spaces in them. It's especially frustrating to try to operate through firewalls and such by nesting ssh commands. Granted, working around this isn't impossible - I just have to make sure that the command I run is only one argument on the ssh command line, and that it's appropriately quoted. But doing this is cumbersome and obscure, and I wonder why it's necessary. For instance, what if ssh had the following behavior: (1) if there is a single argument, split it into a list of words, and use this list as the remote command; (2) otherwise, leave the arguments as the user specified them. This would fix my problems, and it would only cause unintended consequences if the user wanted to run a remote executable with spaces in its name (and with no arguments), which is a situation that I've never encountered. Also, importantly, I think this suggestion would be mostly backwards compatible, although others might have a better sense of this. It might not be wise to make it the default, since it would surely cause *some* things to break, but I'm wondering if it would be worthwhile to allow users to enable such behavior through, say, a configuration variable. If people think it's a good idea, I can submit a patch. Frederik Eaton From djm at mindrot.org Thu Dec 2 09:39:23 2004 From: djm at mindrot.org (Damien Miller) Date: Thu, 02 Dec 2004 09:39:23 +1100 Subject: $HOME instead of pw->pw_dir question. In-Reply-To: <41ADE5DC.7090304@medialogic.it> References: <41ADE5DC.7090304@medialogic.it> Message-ID: <41AE481B.5060502@mindrot.org> Grzegorz Kryza wrote: > Hello. > I have one, small question. > > There are any security reasons to not use a getenv("HOME") > instead of pw->pw_dir in ssh.c and tildexpand.c to find > user home directory? I bet there are users out there who depend on the current behaviour. -d From djm at mindrot.org Thu Dec 2 09:48:22 2004 From: djm at mindrot.org (Damien Miller) Date: Thu, 02 Dec 2004 09:48:22 +1100 Subject: remote command word splitting In-Reply-To: <20041201221928.GA18434@a5.repetae.net> References: <20041201221928.GA18434@a5.repetae.net> Message-ID: <41AE4A36.3060308@mindrot.org> frederik at a5.repetae.net wrote: > Hello, > > I have a suggestion about the way ssh does word splitting on commands > which have been passed to it for remote execution. ssh doesn't do splitting. You local shell does it and ssh just passes the result to a remote shell, which may do its own splitting. > It appears that > what is currently done is, if there are extra arguments on the ssh > command line for a remote command, (1) split each of these arguments > into a list (2) concatenate the resulting lists to get the command > arguments. So we get behavior like > > $ perl -le 'die "hi"' > hi at -e line 1. > $ ssh some-host perl -le 'die "hi"' > Died at -e line 1. You local shell will be eating the outermost set of quotes before ssh touches it. If you explicitly quote your commandline, then you can avoid any problems: [djm at baragon djm]$ ssh djm@::1 "perl -le 'die \"hi\"'" hi at -e line 1. Maybe the way that ssh reconstructs the argument string to send to the server could be changed to insert quotes around arguments with spaces in them, but that would require ssh to examine the commands themselves. I don't think that this is acceptable because it means that ssh would magically muck with your command behind your back. I have no doubt that this would break people's scripts. > Also, importantly, I think this suggestion would be mostly backwards > compatible, although others might have a better sense of this. It > might not be wise to make it the default Sorry, but we won't be adding different "modes" to modify the commandline - that is a useless knob when you can just quote it explicitly. -d From dtucker at zip.com.au Thu Dec 2 10:02:03 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 02 Dec 2004 10:02:03 +1100 Subject: remote command word splitting In-Reply-To: <41AE4A36.3060308@mindrot.org> References: <20041201221928.GA18434@a5.repetae.net> <41AE4A36.3060308@mindrot.org> Message-ID: <41AE4D6B.7090103@zip.com.au> Damien Miller wrote: > Maybe the way that ssh reconstructs the argument string to send to the > server could be changed to insert quotes around arguments with spaces in > them, but that would require ssh to examine the commands themselves. There's no guarantee that the shell on the server is going to understand quotes the same way the client does, either. What are the quoting rules for Windows? VMS? OS/390? NetWare? etc... > I don't think that this is acceptable because it means that ssh would > magically muck with your command behind your back. I have no doubt that > this would break people's scripts. Agreed. -- 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 frederik at a5.repetae.net Thu Dec 2 14:14:50 2004 From: frederik at a5.repetae.net (Frederik Eaton) Date: Wed, 1 Dec 2004 19:14:50 -0800 Subject: remote command word splitting In-Reply-To: <41AE4D6B.7090103@zip.com.au> References: <20041201221928.GA18434@a5.repetae.net> <41AE4A36.3060308@mindrot.org> <41AE4D6B.7090103@zip.com.au> Message-ID: <20041202031450.GA1709@a5.repetae.net> Ah, I misunderstood where the splitting was done, sorry. Hmm. So, while I'm no longer as enthusiastic as I was about this idea, I still wonder if it wouldn't be cleaner if there were a way to get ssh to preserve the separation between remote command arguments itself, rather than asking the user to do protective quoting. How about an option to ask ssh to use 'execvp' rather than a shell? Then I could do Q=(-E sh -c '"$@"' --) ssh some-host $Q perl -le 'die "hi"' Anyway, just a suggestion. Thanks for the responses, Frederik On Thu, Dec 02, 2004 at 10:02:03AM +1100, Darren Tucker wrote: > Damien Miller wrote: > >Maybe the way that ssh reconstructs the argument string to send to the > >server could be changed to insert quotes around arguments with spaces in > >them, but that would require ssh to examine the commands themselves. > > There's no guarantee that the shell on the server is going to understand > quotes the same way the client does, either. What are the quoting rules > for Windows? VMS? OS/390? NetWare? etc... > > >I don't think that this is acceptable because it means that ssh would > >magically muck with your command behind your back. I have no doubt that > >this would break people's scripts. > > Agreed. > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > From dtucker at zip.com.au Thu Dec 2 14:31:59 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 02 Dec 2004 14:31:59 +1100 Subject: remote command word splitting In-Reply-To: <20041202031450.GA1709@a5.repetae.net> References: <20041201221928.GA18434@a5.repetae.net> <41AE4A36.3060308@mindrot.org> <41AE4D6B.7090103@zip.com.au> <20041202031450.GA1709@a5.repetae.net> Message-ID: <41AE8CAF.7040201@zip.com.au> Frederik Eaton wrote: > Hmm. So, while I'm no longer as enthusiastic as I was about this idea, > I still wonder if it wouldn't be cleaner if there were a way to get > ssh to preserve the separation between remote command arguments > itself, rather than asking the user to do protective quoting. How > about an option to ask ssh to use 'execvp' rather than a shell? Then I > could do The SSH protocol sends the command as a single string, so you'd still have to dequote somehow to create the argv list to pass to execvp(). You'd also have to set up the user's environment (PATH and whatnot), which probably involves parsing various startup files. Hey, that sounds a lot like what a shell does... -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From djm at mindrot.org Thu Dec 2 14:32:33 2004 From: djm at mindrot.org (Damien Miller) Date: Thu, 02 Dec 2004 14:32:33 +1100 Subject: remote command word splitting In-Reply-To: <20041202031450.GA1709@a5.repetae.net> References: <20041201221928.GA18434@a5.repetae.net> <41AE4A36.3060308@mindrot.org> <41AE4D6B.7090103@zip.com.au> <20041202031450.GA1709@a5.repetae.net> Message-ID: <41AE8CD1.5000706@mindrot.org> Frederik Eaton wrote: > Ah, I misunderstood where the splitting was done, sorry. > > Hmm. So, while I'm no longer as enthusiastic as I was about this idea, > I still wonder if it wouldn't be cleaner if there were a way to get > ssh to preserve the separation between remote command arguments > itself, rather than asking the user to do protective quoting. How > about an option to ask ssh to use 'execvp' rather than a shell? That would require a protocol extension: the protocol uses a single string to pass the command whereas execv wants a vector of arguments. This is possible to do, but it would be an openssh-only extension and would need a button to switch it on. We really don't want to add more buttons :) -d From frederik at a5.repetae.net Thu Dec 2 15:25:17 2004 From: frederik at a5.repetae.net (Frederik Eaton) Date: Wed, 1 Dec 2004 20:25:17 -0800 Subject: remote command word splitting In-Reply-To: <41AE8CAF.7040201@zip.com.au> References: <20041201221928.GA18434@a5.repetae.net> <41AE4A36.3060308@mindrot.org> <41AE4D6B.7090103@zip.com.au> <20041202031450.GA1709@a5.repetae.net> <41AE8CAF.7040201@zip.com.au> Message-ID: <20041202042517.GA30953@a5.repetae.net> > You'd also have to set up the user's environment (PATH and whatnot), > which probably involves parsing various startup files. Hey, that sounds > a lot like what a shell does... That's why I invoke a shell in my example... From joshua at iwsp.com Thu Dec 2 15:47:17 2004 From: joshua at iwsp.com (Joshua Jensen) Date: Wed, 1 Dec 2004 23:47:17 -0500 Subject: ssh graphics forwarding compression with NX ? Message-ID: <20041202044716.GB6179@iwsp.com> Hmmm, I just had a thought. Perhaps not an original one, but could ssh's compression of data be made to use the open source NX algorithms? This could really help remote graphics over the network. -- Joshua Jensen joshua at iwsp.com "If God didn't want us to eat animals, why did he make them out of meat?" From frederik at a5.repetae.net Thu Dec 2 15:48:24 2004 From: frederik at a5.repetae.net (Frederik Eaton) Date: Wed, 1 Dec 2004 20:48:24 -0800 Subject: remote command word splitting In-Reply-To: <41AE8CD1.5000706@mindrot.org> References: <20041201221928.GA18434@a5.repetae.net> <41AE4A36.3060308@mindrot.org> <41AE4D6B.7090103@zip.com.au> <20041202031450.GA1709@a5.repetae.net> <41AE8CD1.5000706@mindrot.org> Message-ID: <20041202044824.GB30953@a5.repetae.net> On Thu, Dec 02, 2004 at 02:32:33PM +1100, Damien Miller wrote: > Frederik Eaton wrote: > > Ah, I misunderstood where the splitting was done, sorry. > > > > Hmm. So, while I'm no longer as enthusiastic as I was about this idea, > > I still wonder if it wouldn't be cleaner if there were a way to get > > ssh to preserve the separation between remote command arguments > > itself, rather than asking the user to do protective quoting. How > > about an option to ask ssh to use 'execvp' rather than a shell? > > That would require a protocol extension: the protocol uses a single > string to pass the command whereas execv wants a vector of arguments. Oh, ick. > This is possible to do, but it would be an openssh-only extension and > would need a button to switch it on. We really don't want to add more > buttons :) Well, OK. I back down. I guess the only other thing is that the man page could mention the issues for newbies and include an example wrapper function in sh? But it's not a big deal to me. Best regards, Frederik From djm at mindrot.org Thu Dec 2 15:59:26 2004 From: djm at mindrot.org (Damien Miller) Date: Thu, 02 Dec 2004 15:59:26 +1100 Subject: ssh graphics forwarding compression with NX ? In-Reply-To: <20041202044716.GB6179@iwsp.com> References: <20041202044716.GB6179@iwsp.com> Message-ID: <41AEA12E.2070203@mindrot.org> Joshua Jensen wrote: > Hmmm, I just had a thought. Perhaps not an original one, but could > ssh's compression of data be made to use the open source NX algorithms? > This could really help remote graphics over the network. NX is GPL, so we can't link to it. OTOH If NX can act as a proxy, then it probably already works :) -d From dtucker at zip.com.au Thu Dec 2 23:22:40 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 02 Dec 2004 23:22:40 +1100 Subject: remote command word splitting In-Reply-To: <20041202042517.GA30953@a5.repetae.net> References: <20041201221928.GA18434@a5.repetae.net> <41AE4A36.3060308@mindrot.org> <41AE4D6B.7090103@zip.com.au> <20041202031450.GA1709@a5.repetae.net> <41AE8CAF.7040201@zip.com.au> <20041202042517.GA30953@a5.repetae.net> Message-ID: <41AF0910.1050802@zip.com.au> Frederik Eaton wrote: >>You'd also have to set up the user's environment (PATH and whatnot), >>which probably involves parsing various startup files. Hey, that sounds >>a lot like what a shell does... > > That's why I invoke a shell in my example... Sure (although your example doesn't seem to work in any shell I tried, which is it intended for?), but there's no guarantee that the user is always going to invoke a shell in the command line they send. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Thu Dec 2 23:31:32 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 02 Dec 2004 23:31:32 +1100 Subject: ssh graphics forwarding compression with NX ? In-Reply-To: <41AEA12E.2070203@mindrot.org> References: <20041202044716.GB6179@iwsp.com> <41AEA12E.2070203@mindrot.org> Message-ID: <41AF0B24.5060004@zip.com.au> Damien Miller wrote: > Joshua Jensen wrote: > >>Hmmm, I just had a thought. Perhaps not an original one, but could >>ssh's compression of data be made to use the open source NX algorithms? >>This could really help remote graphics over the network. [...] > OTOH If NX can act as a proxy, then it probably already works :) I seems that it is: http://www.nomachine.com/documentation/NX-XProtocolCompression.php "NX implements a client-server protocol between X agent and proxy to ensure that the narrow-band link between the proxy..." For an example of how to stack sshd X forwarding with a proxy and get xauth right, see this script (which uses the low-bandwidth X proxy, lbxproxy): http://www.zip.com.au/~dtucker/openssh/lbx.sh (remember to source the script with ". ./lbx.sh") -- 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 harry.kantor at navy.mil Fri Dec 3 01:10:16 2004 From: harry.kantor at navy.mil (Kantor, Harry S CIV NAVSURFWARCEN CSS, 376 / 110E) Date: Thu, 2 Dec 2004 09:10:16 -0500 Subject: Bug Report Message-ID: <2B42AAA74DDBC342A7F5C17250C0280E1194E3@naeanrfkez09.nadsusea.nads.navy.mil> To Whom It May Concern: I am running OpenSSH_3.7.1p2 on an HPUX 10.10 operating system. I recently converted my OS to a trusted system, which, among other things, shadows passwords in the /etc/passwd file. In order to shadow the user passwords, a '*' character is used. Unfortunately, the documentation for sshd states that, for HP operating systems, a '*' character in the /etc/passwd file is a sign that the user's account is locked out of ssh logins. In order to verify this, I shutdown my sshd, re-started it with the following command: "sshd -ddd -e" and perused the debugging info. Once I attempted to make an ssh connection from a remote system, a message stating that the user's account was locked came up. I hope that I have adequately described the situation. If you have any questions, need any clarification, or can tell me what I am doing wrong, please reply to this e-mail. Thank you in advance, Harry Kantor Computer Engineer NSWC PC From frederik at a5.repetae.net Fri Dec 3 06:50:38 2004 From: frederik at a5.repetae.net (Frederik Eaton) Date: Thu, 2 Dec 2004 11:50:38 -0800 Subject: remote command word splitting In-Reply-To: <41AF0910.1050802@zip.com.au> References: <20041201221928.GA18434@a5.repetae.net> <41AE4A36.3060308@mindrot.org> <41AE4D6B.7090103@zip.com.au> <20041202031450.GA1709@a5.repetae.net> <41AE8CAF.7040201@zip.com.au> <20041202042517.GA30953@a5.repetae.net> <41AF0910.1050802@zip.com.au> Message-ID: <20041202195038.GA18014@a5.repetae.net> On Thu, Dec 02, 2004 at 11:22:40PM +1100, Darren Tucker wrote: > Frederik Eaton wrote: > >>You'd also have to set up the user's environment (PATH and whatnot), > >>which probably involves parsing various startup files. Hey, that sounds > >>a lot like what a shell does... > > > >That's why I invoke a shell in my example... > > Sure (although your example doesn't seem to work in any shell I tried, > which is it intended for?), Hmm, zsh, I think, sorry. I wasn't sure about the right way to do it in other shells. > but there's no guarantee that the user is always going to invoke a > shell in the command line they send. True, the interface would be non-optimal. Presumably the documentation would provide examples of common usage patterns. But this is all moot since the protocol isn't going to be modified... Regards, Frederik From dtucker at zip.com.au Fri Dec 3 11:59:32 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 03 Dec 2004 11:59:32 +1100 Subject: Bug Report In-Reply-To: <2B42AAA74DDBC342A7F5C17250C0280E1194E3@naeanrfkez09.nadsusea.nads.navy.mil> References: <2B42AAA74DDBC342A7F5C17250C0280E1194E3@naeanrfkez09.nadsusea.nads.navy.mil> Message-ID: <41AFBA74.1050803@zip.com.au> Kantor, Harry S CIV NAVSURFWARCEN CSS, 376 / 110E wrote: > I am running OpenSSH_3.7.1p2 on an HPUX 10.10 operating system. Wow, I haven't seen that HP-UX version in a long time. > I recently converted my OS to a trusted system, which, among other things, > shadows passwords in the /etc/passwd file. In order to shadow the user > passwords, a '*' character is used. Unfortunately, the documentation for > sshd states that, for HP operating systems, a '*' character in the > /etc/passwd file is a sign that the user's account is locked out of ssh > logins. To work around the problem, comment out the LOCKED_PASSWD_STRING line in config.h after running configure but before running make. I think newer versions of OpenSSH will work OK: we changed sshd so it would always use the shadow functions on HP-UX if they're available, and getspnam() should return the correct password from /tcb/* rather than /etc/passwd, and thus won't have this problem. -- 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 bob at proulx.com Fri Dec 3 12:02:41 2004 From: bob at proulx.com (Bob Proulx) Date: Thu, 2 Dec 2004 18:02:41 -0700 Subject: remote command word splitting In-Reply-To: <20041201221928.GA18434@a5.repetae.net> References: <20041201221928.GA18434@a5.repetae.net> Message-ID: <20041203010241.GB23223@dementia.proulx.com> frederik at a5.repetae.net wrote: > $ perl -le 'die "hi"' > hi at -e line 1. > $ ssh some-host perl -le 'die "hi"' > Died at -e line 1. > > (The remote perl program executed differently because ssh split the > eval text into separate arguments) Not that this is really any help but seeing this discussion I thought I would throw this in. echo echo one two three | ssh some-host sh By using stdin to a shell I get two benefits. I always get the same shell regardless of the account's login shell. I have a more predictable, and to me easier to deal with, number of quoting layers that need to be done. YMMV and all of that. Bob From dlssh at leach.net.au Fri Dec 3 15:26:38 2004 From: dlssh at leach.net.au (David Leach) Date: Fri, 3 Dec 2004 12:26:38 +0800 (SGT) Subject: [PATCH] supporting a remote scp path option in scp In-Reply-To: <4620.192.168.0.3.1093973021.squirrel@www.leach.net.au> References: <4620.192.168.0.3.1093973021.squirrel@www.leach.net.au> Message-ID: <44617.203.126.142.231.1102047998.squirrel@www.leach.net.au> It's been a while now, and I haven't seen any response to my request below or any updates to the code reflecting acceptance. Have I worked outside a specific process for submitting patches? Has the patch been rejected for other reasons? Is it on a to do list? Thanks in advance. -dave > Hi there, > > I've written some enhancements to scp.c and pathnames.h to enable the scp > client to arbitrarily set the remote scp path. > (eg $ scp -e /usr/bin/scp foo user at bar:foo) > > I did read the "scp: command not found" FAQ entry but I'm not quite sure > why we can't do this, unless it's because enhancements to scp are no > longer a priority. Any other reason why it "is the way it is" other than > that? > > The patch is below, all I've really done is replaced char cmd[CMDNEEDS] > with char *rspcmd throughout. Forgive any dodgy coding, I'm not a > developer during the day :). I haven't been able to test the patch below > because I don't have a handy openbsd box, I have tested a patch under the > portable version that seems to work fine. Let me know if I'm better off > providing that. > > My reason for wanting is that it means server side scripts that wrap > around forced commands can tie scp down to the absolute path. > Incidentally, if there is a reason why anyone thinks this is a bad idea, > please let me know. > > Regards, > > David. > > --- pathnames.h Mon Jul 12 01:48:47 2004 > +++ pathnames.h Wed Sep 1 00:48:12 2004 > @@ -45,6 +45,8 @@ > */ > #define _PATH_SSH_DAEMON_PID_FILE _PATH_SSH_PIDDIR "/sshd.pid" > > +#define _PATH_SCP_REMOTE_PROGRAM "/usr/bin/scp" > + > /* > * The directory in user\'s home directory in which the files reside. The > * directory should be world-readable (though not all files are). > --- scp.c Thu Aug 12 05:44:32 2004 > +++ scp.c Wed Sep 1 00:48:51 2004 > @@ -102,6 +102,9 @@ > /* This is the program to execute for the secured connection. ("ssh" or > -S) */ > char *ssh_program = _PATH_SSH_PROGRAM; > > +/* This is the program to execute for the remote scp. ("scp" or -e) */ > +char *scp_remote_program = _PATH_SCP_REMOTE_PROGRAM; > + > /* This is used to store the pid of ssh_program */ > pid_t do_cmd_pid = -1; > > @@ -198,8 +201,8 @@ > int errs, remin, remout; > int pflag, iamremote, iamrecursive, targetshouldbedirectory; > > -#define CMDNEEDS 64 > -char cmd[CMDNEEDS]; /* must hold "rcp -r -p -d\0" */ > +char *rscpcmd; /* must hold scp_remote_program + "-r -p -d\0" > */ > + > > int response(void); > void rsource(char *, struct stat *); > @@ -212,12 +215,13 @@ > int > main(int argc, char **argv) > { > - int ch, fflag, tflag, status; > + int ch, fflag, tflag, status, rscpcmdlen; > double speed; > char *targ, *endp; > extern char *optarg; > extern int optind; > > + rscpcmdlen = 1; > args.list = NULL; > addargs(&args, "ssh"); /* overwritten with ssh_program */ > addargs(&args, "-x"); > @@ -225,7 +229,7 @@ > addargs(&args, "-oClearAllForwardings yes"); > > fflag = tflag = 0; > - while ((ch = getopt(argc, argv, "dfl:prtvBCc:i:P:q1246S:o:F:")) != > -1) > + while ((ch = getopt(argc, argv, "dfl:prtvBCc:i:P:q1246S:o:F:e:")) > != -1) > switch (ch) { > /* User-visible flags. */ > case '1': > @@ -255,9 +259,14 @@ > break; > case 'p': > pflag = 1; > + rscpcmdlen += 3; > break; > case 'r': > iamrecursive = 1; > + rscpcmdlen += 3; > + break; > + case 'e': > + scp_remote_program = xstrdup(optarg); > break; > case 'S': > ssh_program = xstrdup(optarg); > @@ -265,6 +274,7 @@ > case 'v': > addargs(&args, "-v"); > verbose_mode = 1; > + rscpcmdlen += 3; > break; > case 'q': > addargs(&args, "-q"); > @@ -274,6 +284,7 @@ > /* Server options. */ > case 'd': > targetshouldbedirectory = 1; > + rscpcmdlen += 3; > break; > case 'f': /* "from" */ > iamremote = 1; > @@ -316,8 +327,11 @@ > > remin = remout = -1; > do_cmd_pid = -1; > + rscpcmdlen += strlen(scp_remote_program); > + rscpcmd = xmalloc(rscpcmdlen); > /* Command to be executed on remote system using "ssh". */ > - (void) snprintf(cmd, sizeof cmd, "scp%s%s%s%s", > + (void) snprintf(rscpcmd, rscpcmdlen, "%s%s%s%s%s", > + scp_remote_program, > verbose_mode ? " -v" : "", > iamrecursive ? " -r" : "", pflag ? " -p" : "", > targetshouldbedirectory ? " -d" : ""); > @@ -347,6 +361,7 @@ > errs = 1; > } > } > + xfree(rscpcmd); > exit(errs != 0); > } > > @@ -383,7 +398,7 @@ > len = strlen(ssh_program) + strlen(argv[i]) + > strlen(src) + (tuser ? strlen(tuser) : 0) + > strlen(thost) + strlen(targ) + > - strlen(ssh_options) + CMDNEEDS + 20; > + strlen(ssh_options) + strlen(rscpcmd) + 20; > bp = xmalloc(len); > if (host) { > *host++ = 0; > @@ -403,7 +418,7 @@ > "%s%s %s -n " > "-l %s %s %s %s '%s%s%s:%s'", > ssh_program, verbose_mode ? " -v" : > "", > - ssh_options, suser, host, cmd, src, > + ssh_options, suser, host, rscpcmd, > src, > tuser ? tuser : "", tuser ? "@" : "", > thost, targ); > } else { > @@ -412,7 +427,7 @@ > "exec %s%s %s -n %s " > "%s %s '%s%s%s:%s'", > ssh_program, verbose_mode ? " -v" : > "", > - ssh_options, host, cmd, src, > + ssh_options, host, rscpcmd, src, > tuser ? tuser : "", tuser ? "@" : "", > thost, targ); > } > @@ -423,9 +438,9 @@ > (void) xfree(bp); > } else { /* local to remote */ > if (remin == -1) { > - len = strlen(targ) + CMDNEEDS + 20; > + len = strlen(targ) + strlen(rscpcmd) + 20; > bp = xmalloc(len); > - (void) snprintf(bp, len, "%s -t %s", cmd, > targ); > + (void) snprintf(bp, len, "%s -t %s", > rscpcmd, targ); > host = cleanhostname(thost); > if (do_cmd(host, tuser, bp, &remin, > &remout, argc) < 0) > @@ -473,9 +488,9 @@ > suser = pwd->pw_name; > } > host = cleanhostname(host); > - len = strlen(src) + CMDNEEDS + 20; > + len = strlen(src) + strlen(rscpcmd) + 20; > bp = xmalloc(len); > - (void) snprintf(bp, len, "%s -f %s", cmd, src); > + (void) snprintf(bp, len, "%s -f %s", rscpcmd, src); > if (do_cmd(host, suser, bp, &remin, &remout, argc) < 0) { > (void) xfree(bp); > ++errs; > @@ -1013,7 +1028,7 @@ > { > (void) fprintf(stderr, > "usage: scp [-1246BCpqrv] [-c cipher] [-F ssh_config] [-i > identity_file]\n" > - " [-l limit] [-o ssh_option] [-P port] [-S > program]\n" > + " [-l limit] [-o ssh_option] [-P port] [-S program] > [-e program]\n" > " [[user@]host1:]file1 [...] > [[user@]host2:]file2\n"); > exit(1); > } > > From dtucker at zip.com.au Fri Dec 3 16:38:16 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 03 Dec 2004 16:38:16 +1100 Subject: [PATCH] supporting a remote scp path option in scp In-Reply-To: <44617.203.126.142.231.1102047998.squirrel@www.leach.net.au> References: <4620.192.168.0.3.1093973021.squirrel@www.leach.net.au> <44617.203.126.142.231.1102047998.squirrel@www.leach.net.au> Message-ID: <41AFFBC8.9080806@zip.com.au> David Leach wrote: > It's been a while now, and I haven't seen any response to my request below > or any updates to the code reflecting acceptance. > > Have I worked outside a specific process for submitting patches? Has the > patch been rejected for other reasons? Is it on a to do list? [snip a patch to allow scp to specify the full path to scp on the other of the connection] I replied privately a while back, but for the public record: putting patches in bugzilla as an enhancement request is likely to be the most successful long-term strategy. Patches to the mailing list might be picked up quicker or they might slip through the cracks, depending on the timing. These days, enhancements to scp aren't a priority (see http://www.openssh.com/faq.html#2.10) I haven't looked at the patch much, but as long as it obeys the style rules, doesn't change the wire protocol or break backwards compatibility, I personally wouldn't object to it. I don't know what anyone else's opinion is. -- 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 jmknoble at pobox.com Sat Dec 4 01:00:28 2004 From: jmknoble at pobox.com (Jim Knoble) Date: Fri, 3 Dec 2004 09:00:28 -0500 Subject: [BUGTRAQ] rssh and scponly arbitrary command execution Message-ID: <20041203140027.GG14999@crawfish.ais.com> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [This came over BUGTRAQ this morning. Note the call for volunteers vis-a-vis rssh.] - ----- Forwarded message from Jason Wies ----- List-Id: List-Subscribe: To: bugtraq at securityfocus.com Cc: rssh-discuss at lists.sourceforge.net Subject: rssh and scponly arbitrary command execution Message-ID: <20041202135143.GA7105 at xc.net> From: Jason Wies Vulnerable applications: rssh All versions All operating systems scponly All versions All operating systems Not vulnerable: Discussion: rssh and scponly are restricted shells that are designed to allow execution only of certain preset programs. Both are used to grant a user the ability to transfer files to and from a remote host without granting full shell access. Due to the fact that most of the preset programs offer options that execute other programs, arbitrary command execution on the remote host is possible. rssh allows any of five predefined programs to be executed on the remote host depending on the configuration. Those that are known to be vulnerable in combination with the techniques described in this posting are marked with an asterisk. - - scp* - - sftp-server - - cvs - - rdist* - - rsync* scponly allows a number of predefined programs to be executed on the remote host depending on compile-time options. Those that are known to be vulnerable when used with scponly: - - scp - - rsync - - unison (*untested) The program execution options that these programs offer: rdist -P rsync -e scp -S unison -rshcmd unison -sshcmd These options allow the user to specify the location of the shell to use when connecting to the remote host. No restriction is placed on what programs may be specified by these options, and rssh and scponly do not filter these options out. The end result is that although a user may be restricted by rssh or scponly to running e.g. only /usr/bin/scp, they can in fact execute any program using /usr/bin/scp -S . The problem is compounded when you recognize that the main use of rssh and scponly is to allow file transfers, which in turn allows a malicious user to transfer and execute entire custom scripts on the remote machine. rssh with sftp-server does not appear to be vulnerable. rssh with cvs is also not vulnerable using these techniques. However, it is quite probable that a malicious user could check out a carefully crafted CVS repository and execute arbitrary commands using CVS's hooks interface. Examples: ssh restricteduser at remotehost 'rsync -e "touch /tmp/example --" localhost:/dev/null /tmp' scp command.sh restricteduser at remotehost:/tmp/command.sh ssh restricteduser at remotehost 'scp -S /tmp/command.sh localhost:/dev/null /tmp' Solution: There are no workarounds for this problem. I have talked with the author of rssh, Derek Martin. He is currently indisposed for an indefinite period of time due to changing countries and having no permanent home at the present moment. Moreover he has other priorities and has lost interest in maintaining the program. He has offered to assist anyone who would like to take over maintainership of rssh, but he does not intend to provide a fix for the current problem. Given this fact, I would strongly recommend against using rssh at this time. The author of scponly, Joe Boyle, has prepared a new release, version 4.0, that addresses the current problem. Distributor updates have been coordinated with this posting and should be available soon. I think the long-term solution for those needing a highly secure restricted shell is to allow granular configuration by administrators of which options and arguments, if any, are allowed to be specified for which programs. In the most restricted case entire command lines would be stored on the remote host and the client would be allowed only to select from the list of available command lines. I'm not aware of any software that offers these capabilities today. References: http://www.pizzashack.org/rssh/index.shtml http://www.sublimation.org/scponly/ - ----- End forwarded message ----- - -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) ..................................................................... :"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 : :...................................................................: -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.7 (OpenBSD) Comment: See http://www.pobox.com/~jmknoble/keys/ for my public key. iD8DBQFBsHFgKJ/qqBOBFJERAhcfAKCOBzMc9Pv2TDYZYZg6X2qVOOKw/wCeJAhe NkyuvLFsfJggMoEihuST+uo= =9alQ -----END PGP SIGNATURE----- From bob at proulx.com Sat Dec 4 02:41:12 2004 From: bob at proulx.com (Bob Proulx) Date: Fri, 3 Dec 2004 08:41:12 -0700 Subject: Bug Report In-Reply-To: <41AFBA74.1050803@zip.com.au> References: <2B42AAA74DDBC342A7F5C17250C0280E1194E3@naeanrfkez09.nadsusea.nads.navy.mil> <41AFBA74.1050803@zip.com.au> Message-ID: <20041203154112.GA27875@dementia.proulx.com> Darren Tucker wrote: > Kantor, Harry S CIV NAVSURFWARCEN CSS, 376 / 110E wrote: > >I am running OpenSSH_3.7.1p2 on an HPUX 10.10 operating system. > > Wow, I haven't seen that HP-UX version in a long time. Wow too. The first version of HP-UX 10.20 released in 1996. Bob From bob at proulx.com Sat Dec 4 02:50:10 2004 From: bob at proulx.com (Bob Proulx) Date: Fri, 3 Dec 2004 08:50:10 -0700 Subject: getpwuid vs. getpwnam In-Reply-To: <41ACD0D5.8020106@sun.com> References: <41ACD0D5.8020106@sun.com> Message-ID: <20041203155010.GB27875@dementia.proulx.com> John Cecere wrote: > Please respond directly. > [...] > After building and installing openssh, I was having trouble getting my > RSA authentication to work. In investigating it, I noticed that it was > attempting to use /.ssh/id_rsa.pub as my public key file instead of > /export/home/rjohn/.ssh/id_rsa.pub. Confused here. Do you mean id_rsa or id_rsa.pub? I would have expected you to say id_rsa here and not the .pub file. > Wouldn't it be more appropriate to use something like > getpwnam(getenv("LOGNAME")) instead ? That would definitely break a lot of my scripts. We also have multiple root users here. But we rely upon the fact that the file ~root/.ssh/id_rsa is the one and only root identify file. Wouldn't it be reasonable to use the -i option? ssh -i ~bob/.ssh/id_rsa somehost ... That allows you to use whatever identity file you wish to use. > Since the login program itself (in both Linux and Solaris) sets > LOGNAME, it's a reasonably safe assumption that it will get set > correctly. Some systems say LOGNAME. Some systems say USER. Bob From John.Cecere at Sun.COM Sat Dec 4 03:53:11 2004 From: John.Cecere at Sun.COM (John Cecere) Date: Fri, 03 Dec 2004 11:53:11 -0500 Subject: getpwuid vs. getpwnam In-Reply-To: <20041203155010.GB27875@dementia.proulx.com> References: <41ACD0D5.8020106@sun.com> <20041203155010.GB27875@dementia.proulx.com> Message-ID: <41B099F7.3090503@sun.com> Bob, Thanks for the response. See embedded comments. Bob Proulx wrote: >John Cecere wrote: > > >>Please respond directly. >>[...] >>After building and installing openssh, I was having trouble getting my >>RSA authentication to work. In investigating it, I noticed that it was >>attempting to use /.ssh/id_rsa.pub as my public key file instead of >>/export/home/rjohn/.ssh/id_rsa.pub. >> >> > >Confused here. Do you mean id_rsa or id_rsa.pub? I would have >expected you to say id_rsa here and not the .pub file. > > Yes. I meant the private key file. My mistake. My point was that it was looking in the wrong directory. > > >>Wouldn't it be more appropriate to use something like >>getpwnam(getenv("LOGNAME")) instead ? >> >> > >That would definitely break a lot of my scripts. We also have >multiple root users here. But we rely upon the fact that the file >~root/.ssh/id_rsa is the one and only root identify file. > >Wouldn't it be reasonable to use the -i option? > > ssh -i ~bob/.ssh/id_rsa somehost ... > >That allows you to use whatever identity file you wish to use. > > I would think that it would make more sense to use the home directory of the intended user. Using the user name (not the uid) as the basis of determining the home directory of the user is something that unix programs have done since I started working with unix 20 years ago. If you look at other commands in unix (e.g. telnet, rlogin, ftp, etc.), they all use the username as the basis for determining the home directory for their configuration files, which is why I've never had a problem with them. I'm actually a little surprised that ssh doesn't do this as well. Before encountering this issue, I just assumed it was a given that a program would use the logged in user's home directory, and not something else. I guess it all comes down to whether or not you consider an alternate root account to be a separate user from root itself. I think it should be treated this way for a few reasons. An alternate account for a specific uid is usually set up so that an alternate envirnment can be used. That environment is tied to the alternate account's home directory (.profile, .bash_profile, etc.). All the shells that I know of use the home directory listed in /etc/passwd for that user and not the home directory for the first uid associated with the account that it finds in /etc/passwd. Also, The fact that there is a separate /etc/passwd entry for it implies a separate user with a separate environment. There's another thing that puts a wrench into this. What would happen if you didn't list root as the first entry in /etc/passwd ? There's nothing that says that you have to. If your alternate root account was listed before root in /etc/passwd, ssh would always use the alternate root account's home directory, even if you logged in as root itself. So with the current scheme that ssh employs, order becomes important in /etc/passwd when it shouldn't be. Now granted, most people don't go around mixing up their /etc/passwd and moving the root entry elsewhere, but what about non-root alternate accounts ? Say you have several users with the same uid of (say) 500. ssh will always use the home directory of the first account it finds. An example of this would be Hylafax. It installs a fax user with the same uid as uucp, but with a separate home directory. >>Since the login program itself (in both Linux and Solaris) sets >>LOGNAME, it's a reasonably safe assumption that it will get set >>correctly. >> >> > >Some systems say LOGNAME. Some systems say USER. > > Most say LOGNAME. Some say both. The login program in Linux and Solaris use LOGNAME only to determine the home directory. >Bob > > Thanks, John -- John Cecere Sun Microsystems 732-302-3922 / john.cecere at sun.com From dan at doxpara.com Sat Dec 4 04:31:55 2004 From: dan at doxpara.com (Dan Kaminsky) Date: Fri, 03 Dec 2004 09:31:55 -0800 Subject: remote command word splitting In-Reply-To: <41AF0910.1050802@zip.com.au> References: <20041201221928.GA18434@a5.repetae.net> <41AE4A36.3060308@mindrot.org> <41AE4D6B.7090103@zip.com.au> <20041202031450.GA1709@a5.repetae.net> <41AE8CAF.7040201@zip.com.au> <20041202042517.GA30953@a5.repetae.net> <41AF0910.1050802@zip.com.au> Message-ID: <41B0A30B.6010200@doxpara.com> If I remember right, stunts like this were _much_ more stable: cat bigscript.sh | ssh user at host /bin/sh (Warning: If you do this on cygwin, you must dos2unix bigscript.sh, or it'll fail quite spectacularly.) --Dan From gert at greenie.muc.de Sat Dec 4 04:50:35 2004 From: gert at greenie.muc.de (Gert Doering) Date: Fri, 3 Dec 2004 18:50:35 +0100 Subject: getpwuid vs. getpwnam In-Reply-To: <41B099F7.3090503@sun.com>; from John.Cecere@Sun.COM on Fri, Dec 03, 2004 at 11:53:11AM -0500 References: <41ACD0D5.8020106@sun.com> <20041203155010.GB27875@dementia.proulx.com> <41B099F7.3090503@sun.com> Message-ID: <20041203185035.O779@greenie.muc.de> Hi, On Fri, Dec 03, 2004 at 11:53:11AM -0500, John Cecere wrote: > An example of this would be Hylafax. It installs a fax user with the > same uid as uucp, but with a separate home directory. That's a setup error. The whole point of a fax user is "have something with different *privileges* from other users on the system". On the original topic, I wonder why ssh isn't just using $HOME? The whole getpwnam()/getpwuid() approach sounds overly complicated to me (and I can't see any security issue if all file accesses are done with proper user permissions, which I assume to be the case). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From John.Cecere at Sun.COM Sat Dec 4 05:25:36 2004 From: John.Cecere at Sun.COM (John Cecere) Date: Fri, 03 Dec 2004 13:25:36 -0500 Subject: getpwuid vs. getpwnam In-Reply-To: <20041203185035.O779@greenie.muc.de> References: <41ACD0D5.8020106@sun.com> <20041203155010.GB27875@dementia.proulx.com> <41B099F7.3090503@sun.com> <20041203185035.O779@greenie.muc.de> Message-ID: <41B0AFA0.8030201@sun.com> Gert Doering wrote: >Hi, > >On Fri, Dec 03, 2004 at 11:53:11AM -0500, John Cecere wrote: > > >>An example of this would be Hylafax. It installs a fax user with the >>same uid as uucp, but with a separate home directory. >> >> > >That's a setup error. The whole point of a fax user is "have something >with different *privileges* from other users on the system". > > Most likely you're right. I was just trying to make the point that two user names with two separate home directories, even though they have the same uid, will have two different environments, and this separation exists because their home directories are different. > >On the original topic, I wonder why ssh isn't just using $HOME? The >whole getpwnam()/getpwuid() approach sounds overly complicated to me >(and I can't see any security issue if all file accesses are done >with proper user permissions, which I assume to be the case). > > Excellent point. I agree with this completely. >gert > > Thanks, John -- John Cecere Sun Microsystems 732-302-3922 / john.cecere at sun.com From stuge-openssh-unix-dev at cdy.org Sat Dec 4 05:23:04 2004 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 3 Dec 2004 19:23:04 +0100 Subject: [BUGTRAQ] rssh and scponly arbitrary command execution In-Reply-To: <20041203140027.GG14999@crawfish.ais.com> References: <20041203140027.GG14999@crawfish.ais.com> Message-ID: <20041203182304.GA3887@foo.birdnet.se> On Fri, Dec 03, 2004 at 09:00:28AM -0500, Jim Knoble wrote: > In the most restricted case entire command lines would be stored on > the remote host and the client would be allowed only to select from > the list of available command lines. I'm not aware of any software > that offers these capabilities today. You could do something like that with local subsystems, but IIRC sshd still uses the shell to start subsystems. //Peter From ThirdType+dev2 at sent.com Sat Dec 4 07:26:27 2004 From: ThirdType+dev2 at sent.com (Mike Thompson) Date: Fri, 03 Dec 2004 15:26:27 -0500 Subject: do_pwchange() is broken on SCO UnixWare 7 Message-ID: <1102105587.9709.210031271@webmail.messagingengine.com> The do_pwchange() function in session.c needs to pass the username as an argument to the passwd command. Without it, passwd always fails with something like "passwd: unknown user" as if its getting a blank user arg. It's strange but so are many other things in SCO, which BTW was NOT my OS of choice :( To make it work I simply changed line 1317 to this: execl(_PATH_PASSWD_PROG, "passwd", s->pw->pw_name, (char*)NULL); From dtucker at zip.com.au Sat Dec 4 10:19:04 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 04 Dec 2004 10:19:04 +1100 Subject: do_pwchange() is broken on SCO UnixWare 7 In-Reply-To: <1102105587.9709.210031271@webmail.messagingengine.com> References: <1102105587.9709.210031271@webmail.messagingengine.com> Message-ID: <41B0F468.3000402@zip.com.au> Mike Thompson wrote: > The do_pwchange() function in session.c needs to pass the username as an > argument to the passwd command. Without it, passwd always fails with > something like "passwd: unknown user" as if its getting a blank user > arg. It's strange but so are many other things in SCO, which BTW was NOT > my OS of choice :( > > To make it work I simply changed line 1317 to this: > execl(_PATH_PASSWD_PROG, "passwd", s->pw->pw_name, (char*)NULL); FWIW my old password expiry patches did this: permanently_set_uid(pw); if (geteuid() == 0) execl(PASSWD_PROGRAM_PATH, "passwd", pw->pw_name, (char *)NULL); else execl(PASSWD_PROGRAM_PATH, "passwd", (char *)NULL); so it only provided the user name when running as root. From memory, various platforms didn't like having the username supplied to passwd when run as a non-root user so it would need to be optional and enabled in configure only on the platforms that need it. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Sat Dec 4 10:21:12 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 04 Dec 2004 10:21:12 +1100 Subject: getpwuid vs. getpwnam In-Reply-To: <20041203185035.O779@greenie.muc.de> References: <41ACD0D5.8020106@sun.com> <20041203155010.GB27875@dementia.proulx.com> <41B099F7.3090503@sun.com> <20041203185035.O779@greenie.muc.de> Message-ID: <41B0F4E8.1050702@zip.com.au> Gert Doering wrote: > On the original topic, I wonder why ssh isn't just using $HOME? The > whole getpwnam()/getpwuid() approach sounds overly complicated to me > (and I can't see any security issue if all file accesses are done > with proper user permissions, which I assume to be the case). The expansion is done in tilde_expand_filename(), which is also used by sshd. $HOME may not be set when sshd use it (and sshd probably shouldn't trust an environment variable for that anyway). Personally, I can't see any security implications in using $HOME in the client only as long as it's checked *very* carefully (some configurations still require ssh to be setuid root). -- 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 bob at proulx.com Sat Dec 4 16:43:41 2004 From: bob at proulx.com (Bob Proulx) Date: Fri, 3 Dec 2004 22:43:41 -0700 Subject: getpwuid vs. getpwnam In-Reply-To: <41B099F7.3090503@sun.com> References: <41ACD0D5.8020106@sun.com> <20041203155010.GB27875@dementia.proulx.com> <41B099F7.3090503@sun.com> Message-ID: <20041204054341.GB31879@dementia.proulx.com> John Cecere wrote: > Please respond directly. > [...] > I would think that it would make more sense to use the home directory of > the intended user. Using the user name (not the uid) as the basis of > determining the home directory of the user is something that unix > programs have done since I started working with unix 20 years ago. Uhm... Actually unix systems don't really care about the name of the user account very much. Almost everything uses the user id number. > If you look at other commands in unix (e.g. telnet, rlogin, ftp, > etc.), they all use the username as the basis for determining the > home directory for their configuration files, which is why I've > never had a problem with them. After giving this more thought I won't object to the use of $HOME in the client side only use of finding the identity key files. I would have to change some things but it is not a huge deal as long as it was called out in the update notes. Conceptually it is no different than the following. alias ssh='ssh -i $HOME/.ssh/id_rsa' > There's another thing that puts a wrench into this. What would > happen if you didn't list root as the first entry in /etc/passwd ? > There's nothing that says that you have to. If your alternate root > account was listed before root in /etc/passwd, ssh would always use > the alternate root account's home directory, even if you logged in > as root itself. So with the current scheme that ssh employs, order > becomes important in /etc/passwd when it shouldn't be. This is not specific to ssh. Everything else uses that paradigm too. Think of what 'ls -l' will show you in that case too. Again there is no real significance to the name. It is the uid that the system cares about. 'ls -ln' will still show uid 0 as owning system files even if you make the account name something different. This is why we differentiate between the 'root' user as a name and the superuser as a concept. > Now granted, most people don't go around mixing up their /etc/passwd > and moving the root entry elsewhere, Sometimes they do and get confused by it. I just had an extended email exchange with someone who had done just that and was confused as to why 'ls -l' showed them an alternate superuser account over the 'root' account. Bob From dtucker at zip.com.au Mon Dec 6 13:47:49 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 06 Dec 2004 13:47:49 +1100 Subject: do_pwchange() is broken on SCO UnixWare 7 In-Reply-To: <1102105587.9709.210031271@webmail.messagingengine.com> References: <1102105587.9709.210031271@webmail.messagingengine.com> Message-ID: <41B3C855.7090105@zip.com.au> Mike Thompson wrote: > The do_pwchange() function in session.c needs to pass the username as an > argument to the passwd command. Without it, passwd always fails with > something like "passwd: unknown user" as if its getting a blank user > arg. It's strange but so are many other things in SCO, which BTW was NOT > my OS of choice :( > > To make it work I simply changed line 1317 to this: > execl(_PATH_PASSWD_PROG, "passwd", s->pw->pw_name, (char*)NULL); Does the attached patch fix it properly? (Note: you will need to run "autoreconf" to rebuild configure after applying the patch, the rerun ./configure && make). -- 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. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-sco-passwd.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041206/803c8961/attachment.ksh From djm at mindrot.org Mon Dec 6 16:48:43 2004 From: djm at mindrot.org (Damien Miller) Date: Mon, 06 Dec 2004 16:48:43 +1100 Subject: reget reput again... In-Reply-To: <418701B5.7060709@netbauds.net> References: <418701B5.7060709@netbauds.net> Message-ID: <41B3F2BB.7080502@mindrot.org> I think a better option is to have an extension to take a checksum over a file, or an arbitrary subset of one. re(get|put) could then validate the file before continuing with it. This would be quite easy to do using the draft-secsh-filexfer protocol's vendor extension mechanism, if someone want to try to beat in implementing it :) If anyone is interested, please discuss your proposed design on-list. -d Darryl L. Miles wrote: > Ben Lindstrom wrote (a very long time ago) : > > >The problem is in some cases the data being sent to you may be out of > >order (thankful no sftp server does this yet). So reget/reput without RFC > >clearifications can lead to bad file transfers. > > > >I'm trying to drag up in my mind which one was the problem... I believe > >reput is fine since the client has control over the ordering. reget is > >the troublesome some one without RFC clarifications stating out of order > >transfers are denied. > > > >if the RFC get clarified to disallow out of order transfers then a cleaned > >up version of this patch may not have a problem getting in. > > > It seems everyone body has a patch for this but it still can't quite > make it into any official distribution. Not wanting to stifle technical > progress down surely the standards body have mechanism to allow new > concepts to be experimentally deployed without affecting non-cooperating > parties ? > > Is it really necessary to get RFC clarification on this, maybe its > useful to leave as-is and have the option to execute out-of-order for in > uses. > > Would it be possible to extend the channel initialisation options to > negotiate a feature requesting "mandatory in-sequence execution of > commands within this channel". I'm not sure how these options are > created or assigned but maybe use some OpenSSH naming space until a > standard group either accepts or rejects the concept and assigns it a > standard option name. > > Non-conforming servers would not understand the option and the client > could then disable the reget/reput commands from use in that session. > > I do not know enough about the OpenSSH implementation to know if its > possible for it to ever execute commands out of sequence with respect to > the channel they are in nor the contraints this may pose to future > maintainace of OpenSSH. > > To confirm the scope of the option suggested, it says nothing about any > other channel nor the order in which channels are attended to within the > server, this stays as-is. > > > RFC ? Please Cc your reply Thanks. > > From darryl at netbauds.net Mon Dec 6 23:17:04 2004 From: darryl at netbauds.net (Darryl L. Miles) Date: Mon, 06 Dec 2004 12:17:04 +0000 Subject: reget reput again... In-Reply-To: <41B3F2BB.7080502@mindrot.org> References: <418701B5.7060709@netbauds.net> <41B3F2BB.7080502@mindrot.org> Message-ID: <41B44DC0.4000300@netbauds.net> I would be in favour of both mechanisms being in place, not wanting to stifle progress. reput/reget with and without checksuming. However RSYNC is a better tool for a checksumed file copy IMHO. When you start checksumming files, due to the huge IO overhead at both sides you are really talking about a background or batch filecopy/mirroring service. I regard SFTP usage as interactive and therefore the user is expected to understand factors affecting modification of the source and target files at the time of the operation. The user would not also want to have to wait the IO time for the file to be read while he is interactivly using his SFTP client program. A simple restarted transfers facility brings SFTP into line with FTP without being too over the top about it. Having a file checksum option that is generic would certainly be a useful feature which would allow the client to perform an inteligent file copy and also a checksumed file compare (between two files on the server system too). Your new checksumming mechanism should be a primitive building block to allow the more complex decisions to be made from it result. So a simple request from client to server of "Report checksum(s) for this file over this byte range" and maybe an abort of previous instruction, if the protocol permits this. The client to server instruction maybe composed of: File: the target file Offset: start point to checksum from Length: end point to checksum to (special EOF case) Blocksize: report checksum results every (special infinity case to mean 1 result for whole file) Accepted/Prefered list of checksum algos / digests and their usage options: (maybe MD4/MD5/SHA1 is LSB truncated etc...) dont recode this, maybe take a look as ASN.1 syntax and numbers. Maybe its suggested that a basic algo should exist (MD4 or MD5 ?) in all implementations but not a mandatory requirement. In the worse case scenario the server will report an error "No matching algo agreed between us". A suggestion for the checksum data coming back to the client should be in blocks possibiliy containing more than one checksum in each block, at the head of each block is the offset the first (in this block) checksum starts at. There should be a special block sent (with different status to denote, last checksum), the last block should indicate the exact length of the input data that went into it. Maybe some consideration wants to be given to how the offset and lengths are encoded ? Maybe a 64bit length should just be used and it forgotten about. Maybe some knowledge can be gained from researching how RSYNC -c option checksums files. We still have to argue over which method should be used by default reput implementation. Regards, Darryl Damien Miller wrote: >I think a better option is to have an extension to take a checksum over >a file, or an arbitrary subset of one. re(get|put) could then validate >the file before continuing with it. > >This would be quite easy to do using the draft-secsh-filexfer >protocol's vendor extension mechanism, if someone want to try to >beat in implementing it :) > >If anyone is interested, please discuss your proposed design on-list. > >-d > >Darryl L. Miles wrote: > > >>Ben Lindstrom wrote (a very long time ago) : >> >> >The problem is in some cases the data being sent to you may be out of >> >order (thankful no sftp server does this yet). So reget/reput without RFC >> >clearifications can lead to bad file transfers. >> > >> >I'm trying to drag up in my mind which one was the problem... I believe >> >reput is fine since the client has control over the ordering. reget is >> >the troublesome some one without RFC clarifications stating out of order >> >transfers are denied. >> > >> >if the RFC get clarified to disallow out of order transfers then a cleaned >> >up version of this patch may not have a problem getting in. >> >> >>It seems everyone body has a patch for this but it still can't quite >>make it into any official distribution. Not wanting to stifle technical >>progress down surely the standards body have mechanism to allow new >>concepts to be experimentally deployed without affecting non-cooperating >>parties ? >> >>Is it really necessary to get RFC clarification on this, maybe its >>useful to leave as-is and have the option to execute out-of-order for in >>uses. >> >>Would it be possible to extend the channel initialisation options to >>negotiate a feature requesting "mandatory in-sequence execution of >>commands within this channel". I'm not sure how these options are >>created or assigned but maybe use some OpenSSH naming space until a >>standard group either accepts or rejects the concept and assigns it a >>standard option name. >> >>Non-conforming servers would not understand the option and the client >>could then disable the reget/reput commands from use in that session. >> >>I do not know enough about the OpenSSH implementation to know if its >>possible for it to ever execute commands out of sequence with respect to >>the channel they are in nor the contraints this may pose to future >>maintainace of OpenSSH. >> >>To confirm the scope of the option suggested, it says nothing about any >>other channel nor the order in which channels are attended to within the >>server, this stays as-is. >> >> >>RFC ? Please Cc your reply Thanks. >> >> >> >> > > > > -- Darryl L. Miles M: 07968 320 114 From dan at doxpara.com Tue Dec 7 02:52:13 2004 From: dan at doxpara.com (Dan Kaminsky) Date: Mon, 06 Dec 2004 07:52:13 -0800 Subject: reget reput again... In-Reply-To: <41B3F2BB.7080502@mindrot.org> References: <418701B5.7060709@netbauds.net> <41B3F2BB.7080502@mindrot.org> Message-ID: <41B4802D.8040507@doxpara.com> Rsync does this (indeed, it's how I do reget/reput right now.) It's ungodly slow for large files. --Dan Damien Miller wrote: >I think a better option is to have an extension to take a checksum over >a file, or an arbitrary subset of one. re(get|put) could then validate >the file before continuing with it. > >This would be quite easy to do using the draft-secsh-filexfer >protocol's vendor extension mechanism, if someone want to try to >beat in implementing it :) > >If anyone is interested, please discuss your proposed design on-list. > >-d > >Darryl L. Miles wrote: > > >>Ben Lindstrom wrote (a very long time ago) : >> >> >The problem is in some cases the data being sent to you may be out of >> >order (thankful no sftp server does this yet). So reget/reput without RFC >> >clearifications can lead to bad file transfers. >> > >> >I'm trying to drag up in my mind which one was the problem... I believe >> >reput is fine since the client has control over the ordering. reget is >> >the troublesome some one without RFC clarifications stating out of order >> >transfers are denied. >> > >> >if the RFC get clarified to disallow out of order transfers then a cleaned >> >up version of this patch may not have a problem getting in. >> >> >>It seems everyone body has a patch for this but it still can't quite >>make it into any official distribution. Not wanting to stifle technical >>progress down surely the standards body have mechanism to allow new >>concepts to be experimentally deployed without affecting non-cooperating >>parties ? >> >>Is it really necessary to get RFC clarification on this, maybe its >>useful to leave as-is and have the option to execute out-of-order for in >>uses. >> >>Would it be possible to extend the channel initialisation options to >>negotiate a feature requesting "mandatory in-sequence execution of >>commands within this channel". I'm not sure how these options are >>created or assigned but maybe use some OpenSSH naming space until a >>standard group either accepts or rejects the concept and assigns it a >>standard option name. >> >>Non-conforming servers would not understand the option and the client >>could then disable the reget/reput commands from use in that session. >> >>I do not know enough about the OpenSSH implementation to know if its >>possible for it to ever execute commands out of sequence with respect to >>the channel they are in nor the contraints this may pose to future >>maintainace of OpenSSH. >> >>To confirm the scope of the option suggested, it says nothing about any >>other channel nor the order in which channels are attended to within the >>server, this stays as-is. >> >> >>RFC ? Please Cc your reply Thanks. >> >> >> >> > >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > From phil at usc.edu Tue Dec 7 09:50:59 2004 From: phil at usc.edu (Phil Dibowitz) Date: Mon, 6 Dec 2004 14:50:59 -0800 Subject: [Patch] Makefile.in, new install-nosysconf target Message-ID: <20041206225059.GF30996@usc.edu> For various reasons, it makes our life easier at USC to have a 'install-nosysconf' target much like the install-nokeys target that was added a while back. I mentioned this a few months back on this list and people seemed to think it wouldn't be a problem to get it into the mainline tree. I've attached the patch -- it should keep 100% backwards compatibility. Thanks. -- Phil Dibowitz Systems Architect and Administrator Enterprise Infrastructure / ISD / USC UCC 174 - 213-821-5427 -------------- next part -------------- --- Makefile.in.orig Mon Dec 6 14:02:13 2004 +++ Makefile.in Mon Dec 6 14:06:48 2004 @@ -228,8 +228,9 @@ -rm -rf autom4te.cache (cd scard && $(MAKE) -f Makefile.in distprep) -install: $(CONFIGFILES) ssh_prng_cmds.out $(MANPAGES) $(TARGETS) install-files host-key check-config -install-nokeys: $(CONFIGFILES) ssh_prng_cmds.out $(MANPAGES) $(TARGETS) install-files +install: $(CONFIGFILES) ssh_prng_cmds.out $(MANPAGES) $(TARGETS) install-files install-sysconf host-key check-config +install-nokeys: $(CONFIGFILES) ssh_prng_cmds.out $(MANPAGES) $(TARGETS) install-files install-sysconf +install-nosysconf: $(CONFIGFILES) ssh_prng_cmds.out $(MANPAGES) $(TARGETS) install-files check-config: -$(DESTDIR)$(sbindir)/sshd -t -f $(DESTDIR)$(sysconfdir)/sshd_config @@ -279,6 +280,8 @@ ln -s ./ssh$(EXEEXT) $(DESTDIR)$(bindir)/slogin -rm -f $(DESTDIR)$(mandir)/$(mansubdir)1/slogin.1 ln -s ./ssh.1 $(DESTDIR)$(mandir)/$(mansubdir)1/slogin.1 + +install-sysconf: if [ ! -d $(DESTDIR)$(sysconfdir) ]; then \ $(srcdir)/mkinstalldirs $(DESTDIR)$(sysconfdir); \ fi -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041206/6e9b3b9c/attachment.bin From dtucker at zip.com.au Tue Dec 7 11:07:14 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 07 Dec 2004 11:07:14 +1100 Subject: do_pwchange() is broken on SCO UnixWare 7 In-Reply-To: References: <1102105587.9709.210031271@webmail.messagingengine.com> <41B0F468.3000402@zip.com.au> Message-ID: <41B4F432.5070605@zip.com.au> Tim Rice wrote: > On Sat, 4 Dec 2004, Darren Tucker wrote: >> execl(PASSWD_PROGRAM_PATH, "passwd", (char *)NULL); > ^^^^^^^^^^^^^^^^^^^^^^ > Wouldn't that be equivilent to > $ passwd "" No, it's just the null termination that execl requires. The cast is to keep the compiler quiet. > UnixWare does complain anout this. > ... > UX:passwd: ERROR: Unknown logname: Perhaps it's complaining about something else? Missing $LOGNAME or something? > Running passwd with no args works and "passwd user_name" works too. BTW changing all users' passwords with "passwd user_name" as root can have other unpleasant side effects (eg on AIX it will set the ADMCHG flag which will force the user to change it again next login). -- 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 Tue Dec 7 12:44:24 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 07 Dec 2004 12:44:24 +1100 Subject: patch to fix non-echo tty on scp SIGINT In-Reply-To: <20041122110407.GA11596@dusk.org> References: <20041122110407.GA11596@dusk.org> Message-ID: <41B50AF8.5050208@zip.com.au> Adam Wiggins wrote: > A long-time missing feature (or bug, depending on how you look at it) is > that a Ctrl-C at the password prompt in scp does not restore the > terminal settings, thus dropping you to the command prompt without any > keyboard echo. (A "reset" command will fix it.) This is a pretty > regular occurance for me, and some others I've talked to - usually when > you realize that the scp command you typed has a typo and decide to > abort. Yeah, after a while "stty sane" gets old, doesn't it :-? > Strangely, ssh handles this correctly, but scp does not. The single > handler in scp.c is killchild(), which should pass the SIGINT along to > the ssh process, which would restore the terminal. However this doesn't > work for some reason I couldn't discern - perhaps the ssh process is > invoked in such a way that it doesn't have access to the terminal > settings? I think the problem is fundamentally a race. scp passes the signal to ssh then immediately exits. ssh will then get the passed signal (eg a SIGINT) plus a SIGPIPE (since the other end of its stdin/stdout descriptors have closed). Same applies to sftp too. I think that in many cases the SIGPIPE is killing ssh before the SIGINT handler has a chance to restore the terminal modes. The attached patch prevents this by waiting for ssh to exit before scp does. The problem doesn't seem to occur on OpenBSD, however I'm not sure if this is simply because the dice didn't come up right, or there's some mechanism which prevents it (eg process scheduling or a different signal delivery order). (I vaguely recall someone else mentioning this but a search of the archives failed to locate it. If anyone can point me to a reference I'll make sure it's credited appropriately). -- 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. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-scp-sftp-sigint.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041207/68359fcc/attachment.ksh From dtucker at zip.com.au Tue Dec 7 13:01:58 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 07 Dec 2004 13:01:58 +1100 Subject: [Patch] Makefile.in, new install-nosysconf target In-Reply-To: <20041206225059.GF30996@usc.edu> References: <20041206225059.GF30996@usc.edu> Message-ID: <41B50F16.4090501@zip.com.au> Phil Dibowitz wrote: > For various reasons, it makes our life easier at USC to have a > 'install-nosysconf' target much like the install-nokeys target that was added > a while back. > > I mentioned this a few months back on this list and people seemed to think it > wouldn't be a problem to get it into the mainline tree. > > I've attached the patch -- it should keep 100% backwards compatibility. Looks OK to me (tests OK too :-). -- 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 admorten at umich.edu Tue Dec 7 13:22:08 2004 From: admorten at umich.edu (Andrew Mortensen) Date: Mon, 6 Dec 2004 21:22:08 -0500 Subject: recursive operations in sftp Message-ID: Is there anyone actively working on adding recursive operations to sftp? I've got a recent snapshot of the source (Dec 6th), and I see extended options for ls and the inclusion of history, both of which are welcome, but there doesn't seem to be any hint of recursive operation support. If there are people working quietly on recursive op patches, I'd like to hear from you. I've been putting some things together for a patch, and it would be best if we can avoid duplication of effort. I'd also like to hear from the maintainers regarding what they would deem acceptable as a patch that adds recursive operations. In past discussions, fts has been recommended. I've written put -r code using fts. It's straightforward, as suggested by Ben Lidstrom in the comments for bug 520, but as far as I know, no work has been done on making fts capable of dealing with remote operations. Are recursive operations based on a modified form of fts the only sort of patch acceptable? I've got a patch for recursive rm, too, but it uses recursion to accomplish its task. (There may be some concern about the safety of rm -r, as well.) The logic in the rm -r patch could easily be applied to other cases, like chown/chmod -R, if those are interesting to people. If modified fts is required, I'm interested in at least hearing what those modifications would need to be. Regards, andrew From phil at usc.edu Tue Dec 7 13:23:18 2004 From: phil at usc.edu (Phil Dibowitz) Date: Mon, 6 Dec 2004 18:23:18 -0800 Subject: [Patch] Makefile.in, new install-nosysconf target In-Reply-To: <41B50F16.4090501@zip.com.au> References: <20041206225059.GF30996@usc.edu> <41B50F16.4090501@zip.com.au> Message-ID: <20041207022318.GL30996@usc.edu> On Tue, Dec 07, 2004 at 01:01:58PM +1100, Darren Tucker wrote: > Phil Dibowitz wrote: > >For various reasons, it makes our life easier at USC to have a > >'install-nosysconf' target much like the install-nokeys target that was > >added > >a while back. > > > >I mentioned this a few months back on this list and people seemed to think > >it > >wouldn't be a problem to get it into the mainline tree. > > > >I've attached the patch -- it should keep 100% backwards compatibility. > > Looks OK to me (tests OK too :-). Thanks. I have 3 patches we apply here at USC. I'm happy to send the others in if there's a chance to get them applied, but I don't know how much people would be interested in them: 1. The Makefile patch you just saw 2. Add two extra logit() calls to log the command when someone does "ssh host command" - our security guys requested this, as it makes their life easier. I figure there's a small chance you all may accept this. 3. Very, very basic BSM support (not nearly as robust as the support in current CVS, but we've had it around for 10 years or so since we used commercial SSH). I'm very excited for the BSM code you all have in CVS to make it into a release so I can drop this patch. So if 1 and 2 make it into a release and then the BSM code in CVS makes it into a release, USC won't have to patch openssh anymore ;) -- Phil Dibowitz Systems Architect and Administrator Enterprise Infrastructure / ISD / USC UCC 174 - 213-821-5427 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041206/57268b77/attachment.bin From cmp at uiuc.edu Tue Dec 7 14:12:38 2004 From: cmp at uiuc.edu (Chase Phillips) Date: Mon, 06 Dec 2004 19:12:38 -0800 Subject: recursive operations in sftp In-Reply-To: References: Message-ID: <41B51FA6.5090604@uiuc.edu> Andrew Mortensen wrote: > If modified fts is required, I'm interested in at least hearing what > those modifications would need to be. Maybe you're not suggesting this, but it's my understanding the best path to 'get -r' isn't to change the fts family of functions to receive a local call and then traverse a remote directory tree, but instead to port the fts family of calls into openbsd-compat and mirror the 'put -r' code for 'get -r' commands on the server-side. (That is, pass the fts system calls and arguments down the pipe from sftp to the sftp-server a la remote_glob.) This also has the benefit of giving fts functionality to more platforms. fts didn't work natively on some other OSs (eg RH9) last year. Has the availability of the functions changed in that time to be more widely supported? Though I've since lost the revision history (grrr), I have a similar 'put -r' patch that I stopped working on some time ago. I agree, it was straightforward to implement and the 'get' command is where things become tricky. I will try to dig my patch out of the snapshot I was working against at the time and attach it to bug 520. You may find it useful to compare against though I have my doubts that it will apply cleanly against a modern snapshot without some leg work. Chase From djm at mindrot.org Tue Dec 7 14:24:14 2004 From: djm at mindrot.org (Damien Miller) Date: Tue, 07 Dec 2004 14:24:14 +1100 Subject: recursive operations in sftp In-Reply-To: <41B51FA6.5090604@uiuc.edu> References: <41B51FA6.5090604@uiuc.edu> Message-ID: <41B5225E.6030409@mindrot.org> Chase Phillips wrote: > Andrew Mortensen wrote: > >>If modified fts is required, I'm interested in at least hearing what >>those modifications would need to be. > > > Maybe you're not suggesting this, but it's my understanding the best > path to 'get -r' isn't to change the fts family of functions to receive > a local call and then traverse a remote directory tree, but instead to > port the fts family of calls into openbsd-compat and mirror the 'put -r' > code for 'get -r' commands on the server-side. (That is, pass the fts > system calls and arguments down the pipe from sftp to the sftp-server a > la remote_glob.) I don't think that placing responsibility for globbing an recursion in the server is a good idea. For a start, it would be a protocol extension that no one else would have (initially at least). Secondly, it isn't necessary anyway. > This also has the benefit of giving fts functionality to more platforms. > fts didn't work natively on some other OSs (eg RH9) last year. Has > the availability of the functions changed in that time to be more widely > supported? My suggestion was to use a locally modified fts() function that had hooks to use caller-specified stat, opendir, readdir, etc. functions - much like the glob() extensions. Since I'm not aware of an extant, free fts() that has this, we would have to keep a local copy in OpenSSH - so you needn't worry about platform support. -d From djm at mindrot.org Tue Dec 7 14:29:03 2004 From: djm at mindrot.org (Damien Miller) Date: Tue, 07 Dec 2004 14:29:03 +1100 Subject: recursive operations in sftp In-Reply-To: References: Message-ID: <41B5237F.2090405@mindrot.org> Andrew Mortensen wrote: > Is there anyone actively working on adding recursive operations to > sftp? I'm not actively working on it, but I would really like to have it :) > If there are people working quietly on recursive op patches, I'd like > to hear from you. I've been putting some things together for a patch, > and it would be best if we can avoid duplication of effort. I'd also > like to hear from the maintainers regarding what they would deem > acceptable as a patch that adds recursive operations. In past > discussions, fts has been recommended. I've written put -r code using > fts. It's straightforward, as suggested by Ben Lidstrom in the comments > for bug 520, but as far as I know, no work has been done on making fts > capable of dealing with remote operations. Please send this to the list, or attach it to bugzilla. I don't think that we need to wait to have both get -r and put -r implemented before adding support for one of them. > Are recursive operations based on a modified form of fts the only sort > of patch acceptable? I've got a patch for recursive rm, too, but it > uses recursion to accomplish its task. Yeah, I'm quite wary of recursion to accomplish this - an attacker could mount a DoS against you by building a deep hierarchy. rm is also problematic because of race conditions in the protocol - it lacks a "moral equivalent" of O_NOFOLLOW. A modified fts() seems to be a fairly easy way to do this iteratively, but I'm certainly happy to hear other approaches. -d From hiro at dusk.org Tue Dec 7 19:23:30 2004 From: hiro at dusk.org (Adam Wiggins) Date: Tue, 7 Dec 2004 00:23:30 -0800 Subject: patch to fix non-echo tty on scp SIGINT In-Reply-To: <41B50AF8.5050208@zip.com.au> References: <20041122110407.GA11596@dusk.org> <41B50AF8.5050208@zip.com.au> Message-ID: <20041207082330.GA27316@dusk.org> On Tue, Dec 07, 2004 at 12:44:24PM +1100, Darren Tucker wrote: > Adam Wiggins wrote: > >A long-time missing feature (or bug, depending on how you look at it) is > >that a Ctrl-C at the password prompt in scp does not restore the > >terminal settings, thus dropping you to the command prompt without any > >keyboard echo. (A "reset" command will fix it.) This is a pretty > >regular occurance for me, and some others I've talked to - usually when > >you realize that the scp command you typed has a typo and decide to > >abort. > > Yeah, after a while "stty sane" gets old, doesn't it :-? Although having the benefit of saving your screen contents, my method gives a savings of N characters, where N is equal to: echo `echo -n stty sane | wc -c` - `echo -n reset | wc -c` | bc :) > scp passes the signal to ssh then immediately exits. ssh will then get > the passed signal (eg a SIGINT) plus a SIGPIPE (since the other end of > its stdin/stdout descriptors have closed). Same applies to sftp too. > > I think that in many cases the SIGPIPE is killing ssh before the SIGINT > handler has a chance to restore the terminal modes. The attached patch > prevents this by waiting for ssh to exit before scp does. All makes perfect sense, but the patch doesn't seem to change the behavior on my system (Linux, kernel 2.6, KDE 3.3 terminal). Just for kicks I tried it on other terminals (xterm, gnome-terminal) on the same system - all give the same result. > The problem doesn't seem to occur on OpenBSD, however I'm not sure if > this is simply because the dice didn't come up right, or there's some > mechanism which prevents it (eg process scheduling or a different signal > delivery order). Now, here's something: I just dropped back to the text console, and the problem does not appear there. The plot thickens: an "export TERM=linux" command (to make it match the text console) in my KDE terminal fixes it as well! (The default for the KDE terminal, and the others, is "xterm".) Darren, what's your term set to? Maybe this is a termcap settings problem rather than scp or the OS. Adam From dtucker at zip.com.au Tue Dec 7 19:20:31 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 07 Dec 2004 19:20:31 +1100 Subject: patch to fix non-echo tty on scp SIGINT In-Reply-To: <20041207082330.GA27316@dusk.org> References: <20041122110407.GA11596@dusk.org> <41B50AF8.5050208@zip.com.au> <20041207082330.GA27316@dusk.org> Message-ID: <41B567CF.9050503@zip.com.au> Adam Wiggins wrote: > Darren, what's your term set to? Maybe this is a termcap settings > problem rather than scp or the OS. It's PuTTY pretending to be an xterm. -- 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 Dec 8 19:18:54 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 08 Dec 2004 19:18:54 +1100 Subject: patch to fix non-echo tty on scp SIGINT In-Reply-To: <20041207082330.GA27316@dusk.org> References: <20041122110407.GA11596@dusk.org> <41B50AF8.5050208@zip.com.au> <20041207082330.GA27316@dusk.org> Message-ID: <41B6B8EE.7090000@zip.com.au> Adam Wiggins wrote: > All makes perfect sense, but the patch doesn't seem to change the > behavior on my system (Linux, kernel 2.6, KDE 3.3 terminal). Just for > kicks I tried it on other terminals (xterm, gnome-terminal) on the same > system - all give the same result. I'm not able to reproduce that behaviour with the patch applied: I tested PuTTY, xterm and gnome-terminal (Linux 2.4.x) and PuTTY and xterm (Linux 2.6.x) and they all correctly restored the terminal echo mode. Could you please re-test with, say, xterm, and if it still exhibits the problem, run the scp under strace -f and post the last 50 or so lines? (Incidentally, on Linux, strace isn't ideal for debugging this kind of parent-child interaction since strace will change the behaviour of the processes slightly. Don't ask how long it took to figure that out... ) -- 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 jacques.bouchard at onera.fr Wed Dec 8 22:21:17 2004 From: jacques.bouchard at onera.fr (Jacques Bouchard) Date: Wed, 08 Dec 2004 12:21:17 +0100 Subject: dangerous behaviour of scp Message-ID: <41B6E3AD.6040504@onera.fr> When you require a scp copy of more than 1 file to a destination that is not a directory, scp copy the last input file to the destination (version openssh-3.8.1p1). Thus if you forget to specify the destination, the last file is _silently destroyed_. I know that rcp exhibits the same behaviour but cp and rsync don't do anything in that case and _kindly_ warn you that you made a mistake: cp: copying multiple files, but last argument `' is not a directory Try `cp --help' for more information. ERROR: destination must be a directory when copying more than 1 file rsync error: errors selecting input/output files, dirs (code 3) at main.c(371) rsync: connection unexpectedly closed (8 bytes received so far) [sender] rsync error: error in rsync protocol data stream (code 12) at io.c(359) Why not that user-friendly behaviour for scp, which shouldn't make the same mistakes as rcp? A user who is sad to have lost data with a "secure" command. From djm at mindrot.org Thu Dec 9 10:22:28 2004 From: djm at mindrot.org (Damien Miller) Date: Thu, 09 Dec 2004 10:22:28 +1100 Subject: dangerous behaviour of scp In-Reply-To: <41B6E3AD.6040504@onera.fr> References: <41B6E3AD.6040504@onera.fr> Message-ID: <41B78CB4.6090809@mindrot.org> Jacques Bouchard wrote: > Why not that user-friendly behaviour for scp, which shouldn't make the > same mistakes as rcp? scp *is* rcp: same protocol, same code (with only minor changes) From johnpell at mac.com Thu Dec 9 10:43:29 2004 From: johnpell at mac.com (John Davidorff Pell) Date: Wed, 8 Dec 2004 15:43:29 -0800 Subject: dangerous behaviour of scp In-Reply-To: <41B78CB4.6090809@mindrot.org> References: <41B6E3AD.6040504@onera.fr> <41B78CB4.6090809@mindrot.org> Message-ID: Is scp ever sync'd with any updated, improved, bug-fixed rcp tree? I know that some that the version of rcp included with Mac OS X is a little diff, which I assume comes from freeBSD. Is it ever updated, or is it one of those things that you just really want to leave alone and never touch? Keeping scp almost identical to rcp is all well and good, but which version of rcp? What about actual not-functionality-changing-bug-fixes? JP On 8 Dec 2004, at 15:22, Damien Miller wrote: > Jacques Bouchard wrote: > > >> Why not that user-friendly behaviour for scp, which shouldn't make the >> same mistakes as rcp? >> > > scp *is* rcp: same protocol, same code (with only minor changes) > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- "Faith: Belief without evidence in what is told by one who speaks without knowledge, of things without parallel." - A.B. -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2545 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041208/98b3e8ff/attachment.bin From dtucker at zip.com.au Thu Dec 9 13:33:09 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 09 Dec 2004 13:33:09 +1100 Subject: dangerous behaviour of scp In-Reply-To: References: <41B6E3AD.6040504@onera.fr> <41B78CB4.6090809@mindrot.org> Message-ID: <41B7B965.7020000@zip.com.au> John Davidorff Pell wrote: > Is scp ever sync'd with any updated, improved, bug-fixed rcp tree? I > know that some that the version of rcp included with Mac OS X is a > little diff, which I assume comes from freeBSD. Is it ever updated, or > is it one of those things that you just really want to leave alone and > never touch? OpenSSH's scp is based on OpenBSD's rcp. Typically any fixes get applied to both. > Keeping scp almost identical to rcp is all well and good, but which > version of rcp? What about actual not-functionality-changing-bug-fixes? BTW I think the fairest criticism is that it behaves differently for local vs remote copies (see below). Anyway, it turns out that due to some work by Markus earlier this year, scp already knows if the destination should be a directory, so it's easy to fix, see attached patch. Without patch: $ touch a b $ echo test >c $ scp a b localhost:c scp: c: Not a directory $ scp -v a b c Executing: exec cp a c Executing: exec cp b c $ ls -l c -rw-rw-r-- 1 dtucker dtucker 0 Dec 9 12:54 c With patch: $ scp -v a b c scp: c: Not a directory -- 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. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-scp-dest-dir.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041209/1b30d4db/attachment.ksh From ThirdType+dev2 at sent.com Thu Dec 9 14:07:23 2004 From: ThirdType+dev2 at sent.com (ThirdType+dev2 at sent.com) Date: Wed, 08 Dec 2004 22:07:23 -0500 Subject: do_pwchange() is broken on SCO UnixWare 7 In-Reply-To: <41B3C855.7090105@zip.com.au> References: <1102105587.9709.210031271@webmail.messagingengine.com> <41B3C855.7090105@zip.com.au> Message-ID: <1102561643.23119.210402138@webmail.messagingengine.com> The patch worked, thanks. Gotta love open source! Curious that it needs the username. I do know that its running passwd as the user and I've never had trouble with execl()'s terminator ending up as "" on SCO. Like you say, it might be missing an environment variable at that point. I'll try to look into that possibility Friday. This might be related to some trouble I've had using Kermit95 (Windows ssh client) to run a command instead of getting a shell. Commands fail or, at best, have stair-stepped output. Seems like it has no tty? I first suspected Kermit95 was to blame for not giving me a -t option for ssh but maybe there is more to this. On Mon, 06 Dec 2004 13:47:49 +1100, "Darren Tucker" said: > Mike Thompson wrote: > > The do_pwchange() function in session.c needs to pass the username as an > > argument to the passwd command. Without it, passwd always fails with > > something like "passwd: unknown user" as if its getting a blank user > > arg. It's strange but so are many other things in SCO, which BTW was NOT > > my OS of choice :( > > > > To make it work I simply changed line 1317 to this: > > execl(_PATH_PASSWD_PROG, "passwd", s->pw->pw_name, (char*)NULL); > > Does the attached patch fix it properly? (Note: you will need to run > "autoreconf" to rebuild configure after applying the patch, the rerun > ./configure && make). > > -- > 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 jacques.bouchard at onera.fr Thu Dec 9 21:21:43 2004 From: jacques.bouchard at onera.fr (Jacques Bouchard) Date: Thu, 09 Dec 2004 11:21:43 +0100 Subject: dangerous behaviour of scp In-Reply-To: <41B7B965.7020000@zip.com.au> References: <41B6E3AD.6040504@onera.fr> <41B78CB4.6090809@mindrot.org> <41B7B965.7020000@zip.com.au> Message-ID: <41B82737.4090507@onera.fr> Darren Tucker wrote: > OpenSSH's scp is based on OpenBSD's rcp. Typically any fixes get > applied to both. > ... > BTW I think the fairest criticism is that it behaves differently for > local vs remote copies (see below). > > Anyway, it turns out that due to some work by Markus earlier this year, > scp already knows if the destination should be a directory, so it's easy > to fix, see attached patch. Thanks for your reply. I hope your patch will get applied to both rcp and scp. From mdb at juniper.net Fri Dec 10 20:05:55 2004 From: mdb at juniper.net (Mark D. Baushke) Date: Fri, 10 Dec 2004 01:05:55 -0800 Subject: [Bug 961] CVS annotate problems In-Reply-To: Mail from bugzilla-daemon@mindrot.org dated Fri, 10 Dec 2004 18:50:54 +1100 <20041210075054.E043827C187@shitei.mindrot.org> References: <20041210075054.E043827C187@shitei.mindrot.org> Message-ID: <55570.1102669555@juniper.net> bugzilla-daemon at mindrot.org writes: > http://bugzilla.mindrot.org/show_bug.cgi?id=961 > I had a problem that CVS annotate from emacs didn't work. Lines were > missing from the output. I was told on gnu.emacs.help, that this was > an SSH/CVS/libc interaction problem that also affected other tools > such as rsync, and was told to make the CVS_RSH enviroment variable > point to the following bourne shell script: > > #!/bin/sh > (ssh "$@" 2>&1 1>&3 | cat) 3>&1 1>&2 > > Using the script fixed the problem for me, but it would be nice not to > need it. FYI. Both cvs-1.11.18 (the stable branch release) and cvs-1.12.10 (the feature branch release) have a workaround for your problem. The difficulty is that SSH puts stdout into non-blocking mode via a redirection of stderr. In turn, this may lead to fwrite() and/or fflush() failing with EAGAIN which was not expected by previous versions of CVS (rsh does not exhibit this misbehavior). I agree that it would be nice if SSH did not make stdout non-blocking just because stderr has been redirected to it. -- Mark From touraine at users.sourceforge.net Fri Dec 10 20:32:15 2004 From: touraine at users.sourceforge.net (Damien Touraine) Date: Fri, 10 Dec 2004 10:32:15 +0100 Subject: openSSH default user ... Message-ID: <41B96D1F.9020804@users.sourceforge.net> Hello, I connect from my computer to several systems with one specific user login on each system. By default, openSSH use the current login name as default name to the remote host. As each login may have been generated randomly, I would like to don't have to specify the login for each computer. So Is there any way to include a configuration file that gives for each remote host, the default login name to use ? Damien From dtucker at zip.com.au Fri Dec 10 20:47:51 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 10 Dec 2004 20:47:51 +1100 Subject: openSSH default user ... In-Reply-To: <41B96D1F.9020804@users.sourceforge.net> References: <41B96D1F.9020804@users.sourceforge.net> Message-ID: <41B970C7.7010302@zip.com.au> Damien Touraine wrote: > I connect from my computer to several systems with one specific user > login on each system. By default, openSSH use the current login name as > default name to the remote host. As each login may have been generated > randomly, I would like to don't have to specify the login for each > computer. > > So Is there any way to include a configuration file that gives for each > remote host, the default login name to use ? Which part of the ssh_config(5) man page did you find unclear on this subject? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From djm at mindrot.org Fri Dec 10 20:56:57 2004 From: djm at mindrot.org (Damien Miller) Date: Fri, 10 Dec 2004 20:56:57 +1100 Subject: patch to fix non-echo tty on scp SIGINT In-Reply-To: <41B6B8EE.7090000@zip.com.au> References: <20041122110407.GA11596@dusk.org> <41B50AF8.5050208@zip.com.au> <20041207082330.GA27316@dusk.org> <41B6B8EE.7090000@zip.com.au> Message-ID: <41B972E9.9080706@mindrot.org> Darren Tucker wrote: > (Incidentally, on Linux, strace isn't ideal for debugging this kind of > parent-child interaction since strace will change the behaviour of the > processes slightly. Don't ask how long it took to figure that out... ) Worse, attaching and detaching strace to some processes will tickle things so that system calls may be interrupted - so tracing a long-running program to see what has happened can cause it to die. I also found this out the hard way... -d From touraine at users.sourceforge.net Fri Dec 10 22:05:23 2004 From: touraine at users.sourceforge.net (Damien Touraine) Date: Fri, 10 Dec 2004 12:05:23 +0100 Subject: openSSH default user ... In-Reply-To: <1102675657.2607.5.camel@localhost.localdomain> References: <41B96D1F.9020804@users.sourceforge.net> <1102675657.2607.5.camel@localhost.localdomain> Message-ID: <41B982F3.80205@users.sourceforge.net> Mark Janssen wrote: >On Fri, 2004-12-10 at 10:32 +0100, Damien Touraine wrote: > > >>Hello, >> >>I connect from my computer to several systems with one specific user >>login on each system. By default, openSSH use the current login name as >>default name to the remote host. As each login may have been generated >>randomly, I would like to don't have to specify the login for each computer. >> >>So Is there any way to include a configuration file that gives for each >>remote host, the default login name to use ? >> >> > >~/.ssh/config > >host host1 > Hostname host1 > User user1 > >host host2 > Hostname host2 > User user2 > >ad nausicum... > > > Thank you very much, and I promess that next time I will better read the documentation ... Sorry, Damien From maniac at maniac.nl Fri Dec 10 21:47:37 2004 From: maniac at maniac.nl (Mark Janssen) Date: Fri, 10 Dec 2004 11:47:37 +0100 Subject: openSSH default user ... In-Reply-To: <41B96D1F.9020804@users.sourceforge.net> References: <41B96D1F.9020804@users.sourceforge.net> Message-ID: <1102675657.2607.5.camel@localhost.localdomain> On Fri, 2004-12-10 at 10:32 +0100, Damien Touraine wrote: > Hello, > > I connect from my computer to several systems with one specific user > login on each system. By default, openSSH use the current login name as > default name to the remote host. As each login may have been generated > randomly, I would like to don't have to specify the login for each computer. > > So Is there any way to include a configuration file that gives for each > remote host, the default login name to use ? ~/.ssh/config host host1 Hostname host1 User user1 host host2 Hostname host2 User user2 ad nausicum... -- Mark Janssen -- maniac(at)maniac.nl Unix / Linux, Open-Source and Internet Consultant PGP: 0x357D2178 Skype: markmjanssen ICQ: 129696007 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041210/786e8430/attachment.bin From dtucker at zip.com.au Sat Dec 11 19:10:13 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 11 Dec 2004 19:10:13 +1100 Subject: patch to fix non-echo tty on scp SIGINT In-Reply-To: <41B50AF8.5050208@zip.com.au> References: <20041122110407.GA11596@dusk.org> <41B50AF8.5050208@zip.com.au> Message-ID: <41BAAB65.9080508@zip.com.au> Darren Tucker wrote: > (I vaguely recall someone else mentioning this but a search of the > archives failed to locate it. If anyone can point me to a reference > I'll make sure it's credited appropriately). I knew I'd seen this before, but I was looking in the wrong place: http://bugzilla.mindrot.org/show_bug.cgi?id=950 -- 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 Sun Dec 12 18:54:14 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 12 Dec 2004 18:54:14 +1100 Subject: AIX lssrc command error after installed OpenSSH In-Reply-To: <20041212074857.57272.qmail@web50701.mail.yahoo.com> References: <20041212074857.57272.qmail@web50701.mail.yahoo.com> Message-ID: <41BBF926.7040008@zip.com.au> lambert lau wrote: > I did try the chsys command and it worked, an lssrc > showed it subsystem as active for a while but the SRC > stopped responding a short while later. I then ran > chssys -s prngd -a '-D' which had no effect. I get a > message telling me that the System Resource Controller > daemon is not active. "-D" the option to prevent *sshd* from daemonizing and is not a valid option for prngd (you probably want "-d"). > The only way I am able to fix the SRC hang is to > deinstall SCBprngd.rte and SCBsshd.rte Take it up with whoever built those packages. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From phil at usc.edu Tue Dec 14 07:45:24 2004 From: phil at usc.edu (Phil Dibowitz) Date: Mon, 13 Dec 2004 12:45:24 -0800 Subject: Status of Sun BSM/Auditd Support ? Message-ID: <20041213204524.GX11161@usc.edu> Hey folks, About a year ago it was pointed out to me there was BSM support in CVS that would hopefully make it into a release soon. I had a look over it and it looks like it covers everything (it certainly covers more than the 3 or 4 things we do here at USC). So I'm wondering what the status of that is? Is it planned for a release soon? Are there issues with it? This is a really big feature we are waiting for at USC. Thanks. -- Phil Dibowitz Systems Architect and Administrator Enterprise Infrastructure / ISD / USC UCC 174 - 213-821-5427 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041213/ec8dfa4b/attachment.bin From hiro at dusk.org Wed Dec 15 20:40:20 2004 From: hiro at dusk.org (Adam Wiggins) Date: Wed, 15 Dec 2004 01:40:20 -0800 Subject: patch to fix non-echo tty on scp SIGINT In-Reply-To: <41B6B8EE.7090000@zip.com.au> References: <20041122110407.GA11596@dusk.org> <41B50AF8.5050208@zip.com.au> <20041207082330.GA27316@dusk.org> <41B6B8EE.7090000@zip.com.au> Message-ID: <20041215094020.GB24953@dusk.org> On Wed, Dec 08, 2004 at 07:18:54PM +1100, Darren Tucker wrote: > Adam Wiggins wrote: > >All makes perfect sense, but the patch doesn't seem to change the > >behavior on my system (Linux, kernel 2.6, KDE 3.3 terminal). Just for > >kicks I tried it on other terminals (xterm, gnome-terminal) on the same > >system - all give the same result. > > I'm not able to reproduce that behaviour with the patch applied: I > tested PuTTY, xterm and gnome-terminal (Linux 2.4.x) and PuTTY and xterm > (Linux 2.6.x) and they all correctly restored the terminal echo mode. Are they all TERM=xterm? > Could you please re-test with, say, xterm, and if it still exhibits the > problem, run the scp under strace -f and post the last 50 or so lines? Using strace with the -o option causes the echo to restore for some reason. So does TERM=linux. Problem shows only when running strace with no -o, cut-n-pasting the display into a file instead. Attached files for each situation: trace1.log: strace -o trace.log -f ./scp ... [echo restored] trace2.log: strace -f ./scp ... [echo not restored] trace3.log: TERM=linux strace -f ./scp ... [echo restored] -------------- next part -------------- 30237 select(4, [3], NULL, NULL, NULL) = 1 (in [3]) 30237 read(3, "\265\v\335\326\313\232]@N\245\274=\204\314\360\370\202"..., 8192) = 64 30237 write(3, "\32\f\311\373zn\360\316\231-J)_\251\34\344\242+\26|\212"..., 240) = 240 30237 select(4, [3], NULL, NULL, NULL) = 1 (in [3]) 30237 read(3, "\3J\300=Qr\236}\334\f\245\2015\367\316\4O\36\16af\235g"..., 8192) = 64 30237 stat64("/home/adam/.ssh/identity", 0xfef3e950) = -1 ENOENT (No such file or directory) 30237 stat64("/home/adam/.ssh/id_dsa", 0xfef3e950) = -1 ENOENT (No such file or directory) 30237 open("/dev/tty", O_RDWR|O_LARGEFILE) = 5 30237 close(5) = 0 30237 open("/dev/tty", O_RDWR|O_LARGEFILE) = 5 30237 rt_sigaction(SIGALRM, {0x806d334, [], SA_RESTORER, 0x45ca48}, {SIG_DFL}, 8) = 0 30237 rt_sigaction(SIGHUP, {0x806d334, [], SA_RESTORER, 0x45ca48}, {SIG_DFL}, 8) = 0 30237 rt_sigaction(SIGINT, {0x806d334, [], SA_RESTORER, 0x45ca48}, {SIG_DFL}, 8) = 0 30237 rt_sigaction(SIGPIPE, {0x806d334, [], SA_RESTORER, 0x45ca48}, {SIG_IGN}, 8) = 0 30237 rt_sigaction(SIGQUIT, {0x806d334, [], SA_RESTORER, 0x45ca48}, {SIG_DFL}, 8) = 0 30237 rt_sigaction(SIGTERM, {0x806d334, [], SA_RESTORER, 0x45ca48}, {SIG_DFL}, 8) = 0 30237 rt_sigaction(SIGTSTP, {0x806d334, [], SA_RESTORER, 0x45ca48}, {SIG_DFL}, 8) = 0 30237 rt_sigaction(SIGTTIN, {0x806d334, [], SA_RESTORER, 0x45ca48}, {SIG_DFL}, 8) = 0 30237 rt_sigaction(SIGTTOU, {0x806d334, [], SA_RESTORER, 0x45ca48}, {SIG_DFL}, 8) = 0 30237 ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 30237 ioctl(5, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost isig icanon -echo ...}) = 0 30237 write(5, "adam at main.oversee.net\'s password"..., 34) = 34 30237 read(5, 30236 <... read resumed> 0xfef30780, 1) = ? ERESTARTSYS (To be restarted) 30237 <... read resumed> 0xfef3dbcf, 1) = ? ERESTARTSYS (To be restarted) 30236 --- SIGINT (Interrupt) @ 0 (0) --- 30237 --- SIGINT (Interrupt) @ 0 (0) --- 30236 kill(30237, SIGINT 30237 sigreturn( 30236 <... kill resumed> ) = 0 30237 <... sigreturn resumed> ) = ? (mask now []) 30236 waitpid(30237, 30237 --- SIGINT (Interrupt) @ 0 (0) --- 30237 sigreturn() = ? (mask now []) 30237 write(5, "\n", 1) = 1 30237 ioctl(5, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost isig icanon echo ...}) = 0 30237 rt_sigaction(SIGALRM, {SIG_DFL}, NULL, 8) = 0 30237 rt_sigaction(SIGHUP, {SIG_DFL}, NULL, 8) = 0 30237 rt_sigaction(SIGINT, {SIG_DFL}, NULL, 8) = 0 30237 rt_sigaction(SIGQUIT, {SIG_DFL}, NULL, 8) = 0 30237 rt_sigaction(SIGPIPE, {SIG_IGN}, NULL, 8) = 0 30237 rt_sigaction(SIGTERM, {SIG_DFL}, NULL, 8) = 0 30237 rt_sigaction(SIGTSTP, {SIG_DFL}, NULL, 8) = 0 30237 rt_sigaction(SIGTTIN, {SIG_DFL}, NULL, 8) = 0 30237 close(5) = 0 30237 kill(30237, SIGINT) = 0 30237 --- SIGINT (Interrupt) @ 0 (0) --- 30236 <... waitpid resumed> NULL, 0) = 30237 30236 --- SIGCHLD (Child exited) @ 0 (0) --- 30236 exit_group(1) = ? -------------- next part -------------- [pid 30244] read(4, "orodruin,64.32.131.193 ssh-rsa A"..., 4096) = 4096 [pid 30244] read(4, "QBim8LWRK+hNRiwxrhqKPpc=\ntrancel"..., 4096) = 4096 [pid 30244] read(4, "zWszJkV+KGwvzYEMoU6/azqxXalLWxJK"..., 4096) = 4096 [pid 30244] read(4, "3wfLsEm88aDvosOetFNe/CsThU9Rqhn5"..., 4096) = 1023 [pid 30244] close(4) = 0 [pid 30244] munmap(0xf6fff000, 4096) = 0 [pid 30244] open("/home/adam/.ssh/known_hosts", O_RDONLY|O_LARGEFILE) = 4 [pid 30244] fstat64(4, {st_mode=S_IFREG|0644, st_size=13311, ...}) = 0 [pid 30244] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf6fff000 [pid 30244] read(4, "orodruin,64.32.131.193 ssh-rsa A"..., 4096) = 4096 [pid 30244] read(4, "QBim8LWRK+hNRiwxrhqKPpc=\ntrancel"..., 4096) = 4096 [pid 30244] read(4, "zWszJkV+KGwvzYEMoU6/azqxXalLWxJK"..., 4096) = 4096 [pid 30244] read(4, "3wfLsEm88aDvosOetFNe/CsThU9Rqhn5"..., 4096) = 1023 [pid 30244] close(4) = 0 [pid 30244] munmap(0xf6fff000, 4096) = 0 [pid 30244] write(3, "\0\0\0\f\n\25\0\0\0\0\0\0\0\0\0\0", 16) = 16 [pid 30244] write(3, "\34\\\366\303VJ\231\305\312\232\24~y\300\202\377\356N\224"..., 48) = 48 [pid 30244] select(4, [3], NULL, NULL, NULL) = 1 (in [3]) [pid 30244] read(3, "\373\236\7\304J\306\1\363x|`\340\206n\264+g\207\347\211"..., 8192) = 48 [pid 30244] socket(PF_FILE, SOCK_STREAM, 0) = 4 [pid 30244] fcntl64(4, F_SETFD, FD_CLOEXEC) = 0 [pid 30244] connect(4, {sa_family=AF_FILE, path="/tmp/ssh-cMKwdW3780/agent.3780"}, 110) = 0 [pid 30244] write(4, "\0\0\0\1", 4) = 4 [pid 30244] write(4, "\v", 1) = 1 [pid 30244] read(4, "\0\0\0\270", 4) = 4 [pid 30244] read(4, "\f\0\0\0\1\0\0\0\225\0\0\0\7ssh-rsa\0\0\0\1#\0\0\0\201"..., 184) = 184 [pid 30244] write(3, "\322\6If{\354\351M\275\322$\276\1\2442.]\r6\340\335\260"..., 64) = 64 [pid 30244] select(4, [3], NULL, NULL, NULL) = 1 (in [3]) [pid 30244] read(3, "\34\3578\305\330~JX\245q\35b\235\214\22!@\214pa\3419\253"..., 8192) = 64 [pid 30244] write(3, "\367\365\310\23Z\322\1\347\0210(\265\374^qj\301\221\264"..., 240) = 240 [pid 30244] select(4, [3], NULL, NULL, NULL) = 1 (in [3]) [pid 30244] read(3, "\321j\17\6#\341\377\247\273\24\341=\337`\304A\36\370\177"..., 8192) = 64 [pid 30244] stat64("/home/adam/.ssh/identity", 0xfeec4660) = -1 ENOENT (No such file or directory) [pid 30244] stat64("/home/adam/.ssh/id_dsa", 0xfeec4660) = -1 ENOENT (No such file or directory) [pid 30244] open("/dev/tty", O_RDWR|O_LARGEFILE) = 5 [pid 30244] close(5) = 0 [pid 30244] open("/dev/tty", O_RDWR|O_LARGEFILE) = 5 [pid 30244] rt_sigaction(SIGALRM, {0x806d334, [], SA_RESTORER, 0x45ca48}, {SIG_DFL}, 8) = 0 [pid 30244] rt_sigaction(SIGHUP, {0x806d334, [], SA_RESTORER, 0x45ca48}, {SIG_DFL}, 8) = 0 [pid 30244] rt_sigaction(SIGINT, {0x806d334, [], SA_RESTORER, 0x45ca48}, {SIG_DFL}, 8) = 0 [pid 30244] rt_sigaction(SIGPIPE, {0x806d334, [], SA_RESTORER, 0x45ca48}, {SIG_IGN}, 8) = 0 [pid 30244] rt_sigaction(SIGQUIT, {0x806d334, [], SA_RESTORER, 0x45ca48}, {SIG_DFL}, 8) = 0 [pid 30244] rt_sigaction(SIGTERM, {0x806d334, [], SA_RESTORER, 0x45ca48}, {SIG_DFL}, 8) = 0 [pid 30244] rt_sigaction(SIGTSTP, {0x806d334, [], SA_RESTORER, 0x45ca48}, {SIG_DFL}, 8) = 0 [pid 30244] rt_sigaction(SIGTTIN, {0x806d334, [], SA_RESTORER, 0x45ca48}, {SIG_DFL}, 8) = 0 [pid 30244] rt_sigaction(SIGTTOU, {0x806d334, [], SA_RESTORER, 0x45ca48}, {SIG_DFL}, 8) = 0 [pid 30244] ioctl(5, SNDCTL_TMR_TIMEBASE or TCGETS, {B38400 opost isig icanon echo ...}) = 0 [pid 30244] ioctl(5, SNDCTL_TMR_CONTINUE or TCSETSF, {B38400 opost isig icanon -echo ...}) = 0 [pid 30244] write(5, "adam at main.oversee.net\'s password"..., 34adam at main.oversee.net's password: ) = 34 [pid 30244] read(5, Process 30244 detached -------------- next part -------------- [pid 30254] read(4, "orodruin,64.32.131.193 ssh-rsa A"..., 4096) = 4096 [pid 30254] read(4, "QBim8LWRK+hNRiwxrhqKPpc=\ntrancel"..., 4096) = 4096 [pid 30254] read(4, "zWszJkV+KGwvzYEMoU6/azqxXalLWxJK"..., 4096) = 4096 [pid 30254] read(4, "3wfLsEm88aDvosOetFNe/CsThU9Rqhn5"..., 4096) = 1023 [pid 30254] close(4) = 0 [pid 30254] munmap(0xf6fff000, 4096) = 0 [pid 30254] open("/home/adam/.ssh/known_hosts", O_RDONLY|O_LARGEFILE) = 4 [pid 30254] fstat64(4, {st_mode=S_IFREG|0644, st_size=13311, ...}) = 0 [pid 30254] mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0xf6fff000 [pid 30254] read(4, "orodruin,64.32.131.193 ssh-rsa A"..., 4096) = 4096 [pid 30254] read(4, "QBim8LWRK+hNRiwxrhqKPpc=\ntrancel"..., 4096) = 4096 [pid 30254] read(4, "zWszJkV+KGwvzYEMoU6/azqxXalLWxJK"..., 4096) = 4096 [pid 30254] read(4, "3wfLsEm88aDvosOetFNe/CsThU9Rqhn5"..., 4096) = 1023 [pid 30254] close(4) = 0 [pid 30254] munmap(0xf6fff000, 4096) = 0 [pid 30254] write(3, "\0\0\0\f\n\25\0\0\0\0\0\0\0\0\0\0", 16) = 16 [pid 30254] write(3, "[\326\370\354\365 Process 30254 detached From libove at felines.org Wed Dec 15 23:42:54 2004 From: libove at felines.org (Jay Libove) Date: Wed, 15 Dec 2004 07:42:54 -0500 (EST) Subject: Time to add exponential backoff for SSH interactive login failures? In-Reply-To: References: Message-ID: With the growing number of username/password pairs being tried by the low level SSH attack which we've all seen in the past few months (I am now seeing some series of attempted logins through SSH which try fifty-plus different IDs, some with more than one password; I've seen 60 hits on "root" in a row), I propose that it is time to add exponential backoff for SSH interactive login failures. Configurably in 'sshd_config' and/or on the sshd command line, a new option would set the delay suffered after the first failed login on a given connection before the next prompt would appear, along with the multiplier for subsequent delays. e.g. 'sshd -eat_this_delay_you_attackers 5 2' .. would result in an SSH daemon running where an attacker would experience a five second delay after the first failed interactive login attempt before the next password prompt came up, then a ten second delay after the second, a twenty second delay after the third, &etc up until the existing authentication timeout value is reached and the connection is closed. This would reduce the effectiveness of any kind of brute force attack against SSH, and would reduce the impact on our systems by slowing the number of authentication attempts per unit time. Discussion, pros/cons? Thanks -Jay Libove, CISSP libove at felines.org Atlanta, GA, US From dtucker at zip.com.au Thu Dec 16 12:02:06 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 16 Dec 2004 12:02:06 +1100 Subject: patch to fix non-echo tty on scp SIGINT In-Reply-To: <20041215094020.GB24953@dusk.org> References: <20041122110407.GA11596@dusk.org> <41B50AF8.5050208@zip.com.au> <20041207082330.GA27316@dusk.org> <41B6B8EE.7090000@zip.com.au> <20041215094020.GB24953@dusk.org> Message-ID: <41C0DE8E.1000103@zip.com.au> Adam Wiggins wrote: > On Wed, Dec 08, 2004 at 07:18:54PM +1100, Darren Tucker wrote: >>I'm not able to reproduce that behaviour with the patch applied: I >>tested PuTTY, xterm and gnome-terminal (Linux 2.4.x) and PuTTY and xterm >>(Linux 2.6.x) and they all correctly restored the terminal echo mode. > > Are they all TERM=xterm? Yes (and I didn't change $TERM). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From djm at mindrot.org Thu Dec 16 16:23:25 2004 From: djm at mindrot.org (Damien Miller) Date: Thu, 16 Dec 2004 16:23:25 +1100 Subject: Time to add exponential backoff for SSH interactive login failures? In-Reply-To: References: Message-ID: <41C11BCD.9040706@mindrot.org> Jay Libove wrote: > With the growing number of username/password pairs being tried by the low > level SSH attack which we've all seen in the past few months (I am now > seeing some series of attempted logins through SSH which try fifty-plus > different IDs, some with more than one password; I've seen 60 hits on > "root" in a row), I propose that it is time to add exponential backoff for > SSH interactive login failures. If you raise the cost of subsequent password attempts much, then it will be cheaper for an attacker to make multiple connections instead. >From the victim's point of view, multiple connections are far more DoS-like than multiple brute-force attempts: each new connection requires a TCP PCB slot (persisting well after the connection is gone) and a key-exchange (including an expensive GEX) in addition to all the other accept-time processing, whereas multiple auth attempts are usually just additional crypt() calls. Maybe something like this would be useful in addition to a client-puzzle (e.g. finding a truncated hash collision before auth), but I think it has the potential to alter attacker behaviour in a way that is inimical to server operators. I am surprised that these trivial password guessing worms are working at all - it is amazing that people have learned so little in the last 20 years. -d From jmknoble at pobox.com Fri Dec 17 00:59:58 2004 From: jmknoble at pobox.com (Jim Knoble) Date: Thu, 16 Dec 2004 08:59:58 -0500 Subject: Time to add exponential backoff for SSH interactive login failures? In-Reply-To: <41C11BCD.9040706@mindrot.org> References: <41C11BCD.9040706@mindrot.org> Message-ID: <20041216135958.GZ14999@crawfish.ais.com> Circa 2004-12-16 16:23:25 +1100 dixit Damien Miller: : Jay Libove wrote: : > [...] I propose that it is time to add exponential backoff for : > SSH interactive login failures. : : If you raise the cost of subsequent password attempts much, then it : will be cheaper for an attacker to make multiple connections instead. Combining exponential backoff on login failures with tarpitting for hosts that have too many connections during a given interval could reduce the effectiveness of password guessing regardless of how many connections were made, unless the attacker performed a distributed attack (against which sshd is currently defenseless anyway). : I am surprised that these trivial password guessing worms are working : at all - it is amazing that people have learned so little in the last : 20 years. Folks still write passwords on sticky notes attached to their monitor, send them via cleartext email messages, and satisfy the "must contain at least on number" requirement with the string "123". I'm a little surprised that the worms aren't more effective than they are.... -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) ..................................................................... :"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 Anthony at Iano-Fletcher.org Fri Dec 17 01:07:36 2004 From: Anthony at Iano-Fletcher.org (Anthony Iano-Fletcher) Date: Thu, 16 Dec 2004 09:07:36 -0500 Subject: Time to add exponential backoff for SSH interactive login failures? In-Reply-To: References: Message-ID: <20041216140736.GA7881@cosy.cit.nih.gov> Hello Jay This sounds like an excellent idea. Anthony On 15 Dec 2004 at 07:42:54, Jay Libove wrote: > With the growing number of username/password pairs being tried by the low > level SSH attack which we've all seen in the past few months (I am now > seeing some series of attempted logins through SSH which try fifty-plus > different IDs, some with more than one password; I've seen 60 hits on > "root" in a row), I propose that it is time to add exponential backoff for > SSH interactive login failures. > > Configurably in 'sshd_config' and/or on the sshd command line, a new > option would set the delay suffered after the first failed login on a > given connection before the next prompt would appear, along with the > multiplier for subsequent delays. > > e.g. 'sshd -eat_this_delay_you_attackers 5 2' > > .. would result in an SSH daemon running where an attacker would > experience a five second delay after the first failed interactive login > attempt before the next password prompt came up, then a ten second delay > after the second, a twenty second delay after the third, &etc up until the > existing authentication timeout value is reached and the connection is > closed. > > This would reduce the effectiveness of any kind of brute force attack > against SSH, and would reduce the impact on our systems by slowing the > number of authentication attempts per unit time. > > Discussion, pros/cons? > > Thanks > -Jay Libove, CISSP > libove at felines.org > Atlanta, GA, US > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev -- Anthony R Iano-Fletcher Room 2033, Building 12A, http://dcb.cit.nih.gov/~arif National Institutes of Health, Anthony.Iano-Fletcher at nih.gov 12A South Drive, Bethesda, Phone: (+1) 301 402 1741. MD 20892-5624, USA. From Jefferson.Ogata at noaa.gov Fri Dec 17 01:54:08 2004 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Thu, 16 Dec 2004 09:54:08 -0500 Subject: Time to add exponential backoff for SSH interactive login failures? In-Reply-To: <20041216135958.GZ14999@crawfish.ais.com> References: <41C11BCD.9040706@mindrot.org> <20041216135958.GZ14999@crawfish.ais.com> Message-ID: <41C1A190.3060509@noaa.gov> Jim Knoble wrote: > Circa 2004-12-16 16:23:25 +1100 dixit Damien Miller: > : Jay Libove wrote: > : > [...] I propose that it is time to add exponential backoff for > : > SSH interactive login failures. > : > : If you raise the cost of subsequent password attempts much, then it > : will be cheaper for an attacker to make multiple connections instead. > > Combining exponential backoff on login failures with tarpitting for > hosts that have too many connections during a given interval could > reduce the effectiveness of password guessing regardless of how many > connections were made, unless the attacker performed a distributed > attack (against which sshd is currently defenseless anyway). Personally, I think the problem is pretty easily solved with a portsentry-type tool. Just watch the logs; when you see a bunch of failed logins with password auth, add a rule to hosts.allow, iptables, ipfw, etc. for the attacking IP. I don't think it's a good idea to try to add this code to sshd. It's complex enough as it is, and if the backoff code isn't carefully designed it creates a denial-of-service risk. > : I am surprised that these trivial password guessing worms are working > : at all - it is amazing that people have learned so little in the last > : 20 years. > > Folks still write passwords on sticky notes attached to their monitor, > send them via cleartext email messages, and satisfy the "must contain at > least on number" requirement with the string "123". I'm a little > surprised that the worms aren't more effective than they are.... A big issue remains default passwords for some operating systems... the silly IRIX demo logins spring to mind. People who switched away from telnet to ssh got a grace period of a couple of years, during which they forgot about the requirement to disable these types of accounts. Then they reinstall, install ssh, put the system back on the net, and eventually the automatic ssh scanners wander in nail them. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) From stuge-openssh-unix-dev at cdy.org Fri Dec 17 02:22:53 2004 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 16 Dec 2004 16:22:53 +0100 Subject: Time to add exponential backoff for SSH interactive login failures? In-Reply-To: <20041216135958.GZ14999@crawfish.ais.com> References: <41C11BCD.9040706@mindrot.org> <20041216135958.GZ14999@crawfish.ais.com> Message-ID: <20041216152253.GC5740@foo.birdnet.se> On Thu, Dec 16, 2004 at 08:59:58AM -0500, Jim Knoble wrote: > unless the attacker performed a distributed attack (against which > sshd is currently defenseless anyway). Only accepting public key authentication will at least increase time and cost for an attacker performing an exhaustive search, which makes the attack both easier to spot, and reduces the chance of success. Protocol backoff would be done in sshd, but is there really a point? Adjust MaxAuthTries and rely on TCP backoff instead. TCP backoff certainly shouldn't be done in sshd, IMHO. //Peter From libove at felines.org Fri Dec 17 13:01:53 2004 From: libove at felines.org (Jay Libove) Date: Thu, 16 Dec 2004 21:01:53 -0500 Subject: Time to add exponential backoff for SSH interactive login failures? Message-ID: I'm accustomed to systems where even the first failed login attempt incurs a 5 second delay. I don't think that's too harsh, but everyone has their own needs and considerations. This could be made configurable. -Jay -----Original Message----- From: Rick Jones [mailto:rick.jones2 at hp.com] Sent: Wednesday, December 15, 2004 8:09 PM To: Jay Libove Cc: openssh-unix-dev at mindrot.org Subject: Re: Time to add exponential backoff for SSH interactive login failures? > Discussion, pros/cons? I think it would be good to be a triffle more gentle on the honest but fumble-fingered and only start the backoff after say the third failed login attempt. rick jones From libove at felines.org Fri Dec 17 13:10:31 2004 From: libove at felines.org (Jay Libove) Date: Thu, 16 Dec 2004 21:10:31 -0500 Subject: Time to add exponential backoff for SSH interactive login failures? Message-ID: I'm looking at this from the point of view of the attacker who is trying to successfully break in, not deny service. The attacker doesn't mind if he causes a denial of service, but that's not his goal here. There are easier ways to do that than the current SSH Worm. Whatever is most expensive to the attacker, without causing a true denial of service, is a good thing. While multiple invocations of the SSH daemon are more expensive to the attacked as well as to the attacker, the goal is to make the attack less likely to succeed. Defense often has a cost. Actually, this makes me suggest yet another feature - a deliberate delay before even the FIRST interactive login password prompt, in addition to exponential backoff thereafter. Perhaps this really is not in scope of the SSH daemon itself .. it's just that I don't have a reactive IDS / IPS lying around which can detect abnormally high numbers of SSH connections from a particular IP address in a short period of time and create a temporary firewall filter for it... I am very open to other suggestions on how I can at once 1. allow myself to SSH in using a password from unpredictable locations, and 2. slow down anyone who would try to brute force (or even just run through a few hundred already-found-elsewhere-but-not-existing-on-my-machine user ID and password combinations) Were it not for #1 above, I could simply turn off access except from known locations, or only allow access using pubkey, or a variety of other things.. but I need this to be available from random places where I cannot necessarily copy in my private key. Thanks for the thoughts and suggestions. -Jay -----Original Message----- From: Damien Miller [mailto:djm at mindrot.org] Sent: Thursday, December 16, 2004 12:23 AM To: Jay Libove Cc: openssh-unix-dev at mindrot.org Subject: Re: Time to add exponential backoff for SSH interactive login failures? Jay Libove wrote: > With the growing number of username/password pairs being tried by the low > level SSH attack which we've all seen in the past few months (I am now > seeing some series of attempted logins through SSH which try fifty-plus > different IDs, some with more than one password; I've seen 60 hits on > "root" in a row), I propose that it is time to add exponential backoff for > SSH interactive login failures. If you raise the cost of subsequent password attempts much, then it will be cheaper for an attacker to make multiple connections instead. >From the victim's point of view, multiple connections are far more DoS-like than multiple brute-force attempts: each new connection requires a TCP PCB slot (persisting well after the connection is gone) and a key-exchange (including an expensive GEX) in addition to all the other accept-time processing, whereas multiple auth attempts are usually just additional crypt() calls. Maybe something like this would be useful in addition to a client-puzzle (e.g. finding a truncated hash collision before auth), but I think it has the potential to alter attacker behaviour in a way that is inimical to server operators. I am surprised that these trivial password guessing worms are working at all - it is amazing that people have learned so little in the last 20 years. -d From libove at felines.org Fri Dec 17 13:12:30 2004 From: libove at felines.org (Jay Libove) Date: Thu, 16 Dec 2004 21:12:30 -0500 Subject: Time to add exponential backoff for SSH interactive login failures? Message-ID: Ah - very fair. Point taken. Thanks. -Jay -----Original Message----- From: Rick Jones [mailto:rick.jones2 at hp.com] Sent: Thursday, December 16, 2004 9:11 PM To: Jay Libove Cc: openssh-unix-dev at mindrot.org Subject: Re: Time to add exponential backoff for SSH interactive login failures? Jay Libove wrote: > I'm accustomed to systems where even the first failed login attempt > incurs a 5 second delay. I don't think that's too harsh, but everyone > has their own needs and considerations. Just to be clear - I wasn't suggesting that there be no delay for the first three, just that it not increase exponentially for the first three. rick jones From djm at mindrot.org Fri Dec 17 13:36:48 2004 From: djm at mindrot.org (Damien Miller) Date: Fri, 17 Dec 2004 13:36:48 +1100 Subject: Time to add exponential backoff for SSH interactive login failures? In-Reply-To: References: Message-ID: <41C24640.9060104@mindrot.org> Jay Libove wrote: > Actually, this makes me suggest yet another feature - a deliberate delay > before even the FIRST interactive login password prompt, in addition to > exponential backoff thereafter. And this suggests another workaround for an attacker: speculatively open multiple parallel connections ahead of time to be used once they pass the initial delay. Attackers can trivially work around most of these delay-based techniques and it usually results in more server invocations. You might have more luck playing with sshd_config's MaxStartups or implementing restrictions at the TCP layer, e.g. rate-limiting connections. Again, you need to be careful here too - it is easy to make it easy for an attacker to DoS you out of your own system (though MaxStartups can be tuned to reduce this risk). > I am very open to other suggestions on how I can at once > 1. allow myself to SSH in using a password from unpredictable locations, Use s/key for this (this is exactly what it is intended for) or revive one of the pubkey-before-password patches. > 2. slow down anyone who would try to brute force (or even just run > through a few hundred > already-found-elsewhere-but-not-existing-on-my-machine user ID and > password combinations) Extra complexity in ssh won't save you if your passwords suck to begin with, so either 1) don't use passwords or 2) enforce complexity restrictions when the passwords are created or changed. I don't believe that it is sshd's role to compensate for bad basic management elsewhere. -d From logsnaath at gmx.net Fri Dec 17 14:51:38 2004 From: logsnaath at gmx.net (Logu) Date: Fri, 17 Dec 2004 09:21:38 +0530 Subject: why openssh tries `none` authentication method Message-ID: <00c001c4e3ec$6e6f9550$140110ac@loguco> Hi, I would like to know the significance of trying `none` method during authentication sequence. Is there any way to avoid unnecessary trying of this none authentication method first. We are writing a patch to log bad login into btmp for all traditional authentication methods supported by SSH. The `none` method increments the authctx-failures and we are facing problems with this. -logu From djm at mindrot.org Fri Dec 17 15:01:16 2004 From: djm at mindrot.org (Damien Miller) Date: Fri, 17 Dec 2004 15:01:16 +1100 Subject: why openssh tries `none` authentication method In-Reply-To: <00c001c4e3ec$6e6f9550$140110ac@loguco> References: <00c001c4e3ec$6e6f9550$140110ac@loguco> Message-ID: <41C25A0C.8050601@mindrot.org> Logu wrote: > Hi, > > I would like to know the significance of trying `none` method during > authentication sequence. Is there any way to avoid unnecessary trying of > this none authentication method first. The relevant section from draft-ietf-secsh-userauth explains this: > Authentication methods are identified by their name, as defined in > [SSH-ARCH]. The "none" method is reserved, and MUST NOT be listed as > supported. However, it MAY be sent by the client. The server MUST > always reject this request, unless the client is to be allowed in > without any authentication, in which case the server MUST accept this > request. The main purpose of sending this request is to get the list > of supported methods from the server. From penney at msu.edu Sat Dec 18 05:55:30 2004 From: penney at msu.edu (Christopher Craig Penney Jr) Date: Fri, 17 Dec 2004 13:55:30 -0500 Subject: ssh-keysign bug? Message-ID: I use ssh in a batch environment (www.pbspro.com) and am using host based authentication to allow sshes between some resources. When I converted from openssh 3.1 to newer versions (up to an including 3.8 where ssh-keysign was moved to a standalone binary) I had issues with ssh-keysign failing with the error "bad fd". A little exploring showed that this was happening because in the batch environment the ssh command did not have a STDIN opened and the socket used for IPC was being created as fd 0. You can see the difference here from a ls -l of /proc/pid/fd right after buffer_get_int(&b) is called in ssh-keysign's main(): --- Normal SSH: 0 -> /dev/pts/3 1 -> /dev/pts/3 2 -> /dev/pts/3 3 -> socket:[37629928] 5 -> pipe:[37629941] 6 -> pipe:[37629942] --- Normal SSH-KEYSIGN: 0 -> pipe:[37629941] 1 -> pipe:[37629942] 2 -> /dev/pts/3 3 -> socket:[37629928] --- Batch run SSH: 0 -> socket:[16485502] 1 -> /var/spool/pbs/spool/311683.batc.OU 2 -> /var/spool/pbs/spool/311683.batc.OU 4 -> pipe:[16485513] 5 -> pipe:[16485514] --- Batch run SSH-KEYSIGN: 0 -> pipe:[16485513] 1 -> pipe:[16485514] 2 -> /var/spool/pbs/spool/311683.batc.OU The problem is resolved if, in the batch script, you redirect /dev/null into the ssh command so the ssh command has a valid STDIN. I'm not sure if this is a bug or intended behavior. Chris From rapier at psc.edu Sat Dec 18 06:53:01 2004 From: rapier at psc.edu (Christopher Rapier) Date: Fri, 17 Dec 2004 14:53:01 -0500 Subject: Time to add exponential backoff for SSH interactive login failures? In-Reply-To: References: Message-ID: <41C3391D.4050506@psc.edu> Jay Libove wrote: > 2. slow down anyone who would try to brute force (or even just run > through a few hundred > already-found-elsewhere-but-not-existing-on-my-machine user ID and > password combinations) There are 86400 seconds in a day. Even with a 5 second delay that gives a patient intruder more than 17000 tries in one day. Admittedly, this is better than giving them several hundred thousand attempts per day but its still, in my view, not much of a deterrent. Especially given that it would be trivial to circumvent. Still, this seems to be one of those 'eh, why not?' things. It might help and only a few lines of code. I would only suggest that the default for the delay to be 0. From dtucker at zip.com.au Sun Dec 19 10:50:39 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 19 Dec 2004 10:50:39 +1100 Subject: Make ssh-rand-helper fall back to commands when configured with prngd Message-ID: <41C4C24F.2050703@zip.com.au> Hi. I recently snookered myself: I build OpenSSH on an old box that didn't have /dev/random, but happened to be running prngd at the time for other reasons. Because I wanted to use commands, I configured --with-rand-helper, however configure found the prngd socket and built ssh-rand-helper to use it exclusively. Next reboot: no prngd, no random seed, no sshd. Do not log in, do not pass "Go", do not collect $200. Can anyone see any reason why we shouldn't allow ssh-rand-helper to fall back to commands if egd/prngd is not available? This is what happens if both PRNGD_PORT and PRNGD_SOCKET are defined: $ ./ssh-rand-helper -v debug1: Seeded RNG with 1 bytes from system calls debug1: trying egd/prngd port 3333 Couldn't connect to PRNGD port 3333: Connection refused debug1: trying egd/prngd socket /var/run/egd-pool Couldn't connect to PRNGD socket "/var/run/egd-pool": Connection refused debug1: Loaded 52 entropy commands from /usr/local/etc/ssh_prng_cmds debug1: Seeded RNG with 373 bytes from programs 629[...]b2 -- 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. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-rand-helper.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041219/00227f78/attachment.ksh From dtucker at zip.com.au Sun Dec 19 11:36:00 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 19 Dec 2004 11:36:00 +1100 Subject: Status of Sun BSM/Auditd Support ? In-Reply-To: <20041213204524.GX11161@usc.edu> References: <20041213204524.GX11161@usc.edu> Message-ID: <41C4CCF0.5060604@zip.com.au> Phil Dibowitz wrote: > About a year ago it was pointed out to me there was BSM support in CVS that > would hopefully make it into a release soon. Right, but it's in Bugzilla, not CVS. > I had a look over it and it looks > like it covers everything (it certainly covers more than the 3 or 4 things we > do here at USC). > > So I'm wondering what the status of that is? Is it planned for a release soon? > Are there issues with it? This is a really big feature we are waiting for at > USC. I was working on it a while back, but I had trouble testing it (I enabled BSM on my SPARC but it didn't appear to be working, and I'm not sure if I'm doing something wrong) and got sidetracked. If someone wants to volunteer to test it (and possibly help me with BSM on my own box) I can update the patch to -current and hopefully get it over the line this time :-). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Mon Dec 20 11:33:25 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 20 Dec 2004 11:33:25 +1100 Subject: Status of Sun BSM/Auditd Support ? In-Reply-To: <41C4CCF0.5060604@zip.com.au> References: <20041213204524.GX11161@usc.edu> <41C4CCF0.5060604@zip.com.au> Message-ID: <41C61DD5.7030001@zip.com.au> Darren Tucker wrote: > I was working on it a while back, but I had trouble testing it (I > enabled BSM on my SPARC but it didn't appear to be working, and I'm not > sure if I'm doing something wrong) and got sidetracked. One unresolved question: where to put it? The original patch had it in openbsd-compat/bsd-solaris.c and I moved it to openbsd-compat/port-solaris.c, but since BSM appears to be used in OS X too, that probably isn't appropriate. I'm leaning toward a top-level audit-bsm.c to match the other Portable-only but non platform specific things (eg auth-pam.c, auth-shadow.c). -- 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 felix.schulte at gmail.com Mon Dec 20 13:26:23 2004 From: felix.schulte at gmail.com (Felix Schulte) Date: Mon, 20 Dec 2004 03:26:23 +0100 Subject: Automatic forwarding of Xprint server displays? Message-ID: <74f15d5f04121918264ff7e5d1@mail.gmail.com> Is it possible to enable automatic forwarding of Xprint server displays? The -X/-Y switches just forward the video Xserver display but it seems there is no way to get the Xprint server displays forwarded, too. Thanks... Felix Schulte -- _ Felix Schulte _|_|_ mailto:felix.schulte at gmail.com (0 0) ooO--(_)--Ooo From dtucker at zip.com.au Mon Dec 20 16:30:03 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 20 Dec 2004 16:30:03 +1100 Subject: Status of Sun BSM/Auditd Support ? In-Reply-To: <41C4CCF0.5060604@zip.com.au> References: <20041213204524.GX11161@usc.edu> <41C4CCF0.5060604@zip.com.au> Message-ID: <41C6635B.1080109@zip.com.au> Darren Tucker wrote: > I was working on it a while back, but I had trouble testing it (I > enabled BSM on my SPARC but it didn't appear to be working, and I'm not > sure if I'm doing something wrong) and got sidetracked. OK, I dusted off my old patch, fixed a few things and split it in two: openssh-audit-base.patch: adds the instrumentation to sshd and an example/debug audit module, and openssh-audit-bsm.patch: the BSM-specific bits. I make no guarantees other than it compiles on my boxes. (If you apply just the first you will need to fix Makefile.in by hand). I suggest we work on getting the hooks into sshd first (either in the form in the patch, or inside #ifdefs) then look at the BSM specific parts afterwards. We will also need to resolve the overlap between this and the existing sys_auth_allowed_user, sys_auth_record_login and record_failed_login functions. I'll also attach these to the bug: http://bugzilla.mindrot.org/show_bug.cgi?id=125 Anyone wanting to keep tabs on this may want to add themselves to the CC list of that bug. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-audit-base.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041220/2525dc15/attachment.ksh -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-audit-bsm.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041220/2525dc15/attachment-0001.ksh From phil at usc.edu Mon Dec 20 17:59:11 2004 From: phil at usc.edu (Phil Dibowitz) Date: Sun, 19 Dec 2004 22:59:11 -0800 Subject: Status of Sun BSM/Auditd Support ? In-Reply-To: <41C6635B.1080109@zip.com.au> References: <20041213204524.GX11161@usc.edu> <41C4CCF0.5060604@zip.com.au> <41C6635B.1080109@zip.com.au> Message-ID: <20041220065911.GR11161@usc.edu> On Mon, Dec 20, 2004 at 04:30:03PM +1100, Darren Tucker wrote: > Darren Tucker wrote: > >I was working on it a while back, but I had trouble testing it (I > >enabled BSM on my SPARC but it didn't appear to be working, and I'm not > >sure if I'm doing something wrong) and got sidetracked. > > OK, I dusted off my old patch, fixed a few things and split it in two: > > openssh-audit-base.patch: adds the instrumentation to sshd and an > example/debug audit module, and > > openssh-audit-bsm.patch: the BSM-specific bits. > > I make no guarantees other than it compiles on my boxes. (If you apply > just the first you will need to fix Makefile.in by hand). > > I suggest we work on getting the hooks into sshd first (either in the > form in the patch, or inside #ifdefs) then look at the BSM specific > parts afterwards. > > We will also need to resolve the overlap between this and the existing > sys_auth_allowed_user, sys_auth_record_login and record_failed_login > functions. > > I'll also attach these to the bug: > http://bugzilla.mindrot.org/show_bug.cgi?id=125 > > Anyone wanting to keep tabs on this may want to add themselves to the CC > list of that bug. I'll add myself to the CC in the morning when I get to work. Additionally, I'll apply the patch, compile a version, and install it on a testbox. I'll report back what I find. Thanks. -- Phil Dibowitz Systems Architect and Administrator Enterprise Infrastructure / ISD / USC UCC 174 - 213-821-5427 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041219/502a83ac/attachment.bin From dtucker at zip.com.au Mon Dec 20 18:11:24 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 20 Dec 2004 18:11:24 +1100 Subject: Status of Sun BSM/Auditd Support ? In-Reply-To: <20041220065911.GR11161@usc.edu> References: <20041213204524.GX11161@usc.edu> <41C4CCF0.5060604@zip.com.au> <41C6635B.1080109@zip.com.au> <20041220065911.GR11161@usc.edu> Message-ID: <41C67B1C.5050609@zip.com.au> Phil Dibowitz wrote: > I'll add myself to the CC in the morning when I get to work. Additionally, > I'll apply the patch, compile a version, and install it on a testbox. I'll > report back what I find. That version will need -DAUDIT_EVENTS added to CFLAGS, I missed it in the header file. I'll fix that shortly and attach the updated version to the bug. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From Hugh.Boyd at delta.com Sat Dec 18 08:25:41 2004 From: Hugh.Boyd at delta.com (Boyd, Hugh) Date: Fri, 17 Dec 2004 16:25:41 -0500 Subject: Compiler messages when building opsnssh 3.9pl for hp_ux 11.0 Message-ID: <94F0BEF87C790843BC6A3D96A3980012016F6FA4@satlrccdlmb05.delta.rl.delta.com> All, I have encountered an issue with builds for openssh 3.9pl on the hp_ux 11.0 platform. The compiler (gcc) generates about 380 warning message and the build fails because of excessive numbers of warnings. The warnings that I am receiving are as follows: /vobs/ecm_gcc/hp-ux-b-11-00/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.2/inc lude/arpa/nameser.h:94: warning: `/*' within comment Now this one is easy enough, since the nameser.h file is open source, I just removed the superfluous comment tag. That eliminated about 200 warning messages. However, the one that is a bit tougher are these: /usr/include/sys/xti.h:317: warning: `T_NULL' redefined /vobs/ecm_gcc/hp-ux-b-11-00/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.2/inc lude/arpa/nameser.h:130: warning: this is the location of the previous definition /usr/include/sys/xti.h:326: warning: `T_UNSPEC' redefined /vobs/ecm_gcc/hp-ux-b-11-00/lib/gcc-lib/hppa2.0n-hp-hpux11.00/2.95.2/inc lude/arpa/nameser.h:155: warning: this is the location of the previous definition /usr/include/sys/xti.h:488: warning: `TCP_NODELAY' redefined /usr/include/netinet/tcp.h:76: warning: this is the location of the previous definition /usr/include/sys/xti.h:489: warning: `TCP_MAXSEG' redefined /usr/include/netinet/tcp.h:77: warning: this is the location of the previous definition All of these comprise a total of about 160 of the warnings that I am seeing. It obviously is the result of constant re-definitions in the header files named above; however, our SA understandably does not want to go into these files an edit them to make the #defines conditional: That is, #ifndef T_NULL #define T_NULL 0 #endif While this appears to be a simple edit, I can understand the reluctance of the SA to do this. Is there a configuration option that I can set to suppress these warnings? Thanks, Hugh Boyd From phil at usc.edu Tue Dec 21 06:36:33 2004 From: phil at usc.edu (Phil Dibowitz) Date: Mon, 20 Dec 2004 11:36:33 -0800 Subject: Status of Sun BSM/Auditd Support ? In-Reply-To: <41C6635B.1080109@zip.com.au> References: <20041213204524.GX11161@usc.edu> <41C4CCF0.5060604@zip.com.au> <41C6635B.1080109@zip.com.au> Message-ID: <20041220193633.GJ11161@usc.edu> On Mon, Dec 20, 2004 at 04:30:03PM +1100, Darren Tucker wrote: > Darren Tucker wrote: > >I was working on it a while back, but I had trouble testing it (I > >enabled BSM on my SPARC but it didn't appear to be working, and I'm not > >sure if I'm doing something wrong) and got sidetracked. > > OK, I dusted off my old patch, fixed a few things and split it in two: > > openssh-audit-base.patch: adds the instrumentation to sshd and an > example/debug audit module, and Erm. FYI, it applies with a fari amount of fuz: patching file `Makefile.in' Hunk #1 succeeded at 84 (offset -1 lines). patching file `auth.c' patching file `auth.h' patching file `auth1.c' Hunk #1 succeeded at 245 (offset -2 lines). Hunk #2 succeeded at 270 (offset -15 lines). patching file `auth2.c' Hunk #1 succeeded at 165 (offset -2 lines). Hunk #2 succeeded at 215 with fuzz 1. Hunk #3 succeeded at 246 (offset -12 lines). patching file `configure.ac' Hunk #1 succeeded at 839 with fuzz 1 (offset -35 lines). Hunk #2 succeeded at 1752 (offset -38 lines). patching file `defines.h' patching file `loginrec.c' Hunk #1 succeeded at 157 with fuzz 2 (offset 26 lines). Hunk #2 succeeded at 204 with fuzz 2 (offset -2 lines). patching file `monitor.c' Hunk #4 succeeded at 1497 (offset -3 lines). patching file `monitor.h' patching file `monitor_wrap.c' Hunk #1 succeeded at 1098 (offset -5 lines). patching file `monitor_wrap.h' patching file `session.c' Hunk #2 succeeded at 1227 (offset -6 lines). patching file `sshd.c' patching file `audit.c' patching file `audit.h' That was to 3.9p1... the -bsm patch applies fine. Compiling now.. ;) -- Phil Dibowitz Systems Architect and Administrator Enterprise Infrastructure / ISD / USC UCC 174 - 213-821-5427 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041220/323cd1a3/attachment.bin From frank.beckmann at vodafone.com Tue Dec 21 18:23:38 2004 From: frank.beckmann at vodafone.com (Beckmann, Frank, VF-DE) Date: Tue, 21 Dec 2004 08:23:38 +0100 Subject: ssh-agent Message-ID: <8879E2295D4FE544A35E9C8A16D62BBE7F49@DEDUS-WICL01M01.vf-de.internal.vodafone.com> Hi :-) We use ssh-agent for batch jobs. The jobs get the key from the ssh-agent over the envoirment variables. When we start many jobs at the same time, the agent dont give the key to the job. We have tracet the our script an see the follow: ... 26918: 0.0004 so_socket(PF_UNIX, SOCK_STREAM, 0, "", 1) = 13 26918: 0.0001 fcntl(13, F_SETFD, 0x00000001) = 0 26918: 0.0003 connect(13, 0xFFBFEC60, 31, 1) Err#146 ECONNREFUSED 26918: 0.0001 close(13) = 0 ... The agent ist bussy when one client is connect to the stream socket. When we make small breaks in the script, the jobs runs fine. Is it an Error in the desing of the Agent ? Greetings Frank From logsnaath at gmx.net Tue Dec 21 21:35:22 2004 From: logsnaath at gmx.net (Logu) Date: Tue, 21 Dec 2004 16:05:22 +0530 Subject: Is there a fix available for CAN-2003-0190 Message-ID: <042d01c4e748$d06b96f0$140110ac@loguco> Hi, Is there a fix available from openssh for the reported vulnerability when pam is enabled. http://www.securityfocus.com/bid/11781 thanks -logu From dtucker at zip.com.au Tue Dec 21 22:28:23 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 21 Dec 2004 22:28:23 +1100 Subject: Is there a fix available for CAN-2003-0190 In-Reply-To: <042d01c4e748$d06b96f0$140110ac@loguco> References: <042d01c4e748$d06b96f0$140110ac@loguco> Message-ID: <41C808D7.10007@zip.com.au> Logu wrote: > Is there a fix available from openssh for the reported vulnerability > when pam is enabled. > http://www.securityfocus.com/bid/11781 You will need to apply both patches. The first patch (openbsd-sshd-kbdint-leak) affects more than PAM, it affects all other challenge-response authentications too so it needs wider testing. Alternatively, for 3.9p1 set "ChallengeResponseAuthentication no" and "PasswordAuthentication yes" in sshd_config (and restart sshd, obviously). -- 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. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openbsd-sshd-kbdint-leak.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041221/937fca15/attachment.ksh -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-pam-kbdint-leak.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041221/937fca15/attachment-0001.ksh From dtucker at zip.com.au Tue Dec 21 22:32:17 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 21 Dec 2004 22:32:17 +1100 Subject: ssh-agent In-Reply-To: <8879E2295D4FE544A35E9C8A16D62BBE7F49@DEDUS-WICL01M01.vf-de.internal.vodafone.com> References: <8879E2295D4FE544A35E9C8A16D62BBE7F49@DEDUS-WICL01M01.vf-de.internal.vodafone.com> Message-ID: <41C809C1.5090407@zip.com.au> Beckmann, Frank, VF-DE wrote: [...] > The agent ist bussy when one client is connect to the stream socket. > When we make small breaks in the script, the jobs runs fine. > > Is it an Error in the desing of the Agent ? More a limitation of named pipes on Unix. The agent client code could retry on failure. Does the attached patch help? -- 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. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-agent-retry.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041221/9af219f3/attachment.ksh From Jefferson.Ogata at noaa.gov Wed Dec 22 00:12:58 2004 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Tue, 21 Dec 2004 08:12:58 -0500 Subject: ssh-agent In-Reply-To: <41C809C1.5090407@zip.com.au> References: <8879E2295D4FE544A35E9C8A16D62BBE7F49@DEDUS-WICL01M01.vf-de.internal.vodafone.com> <41C809C1.5090407@zip.com.au> Message-ID: <41C8215A.5000308@noaa.gov> Darren Tucker wrote: > Beckmann, Frank, VF-DE wrote: > [...] > >> The agent ist bussy when one client is connect to the stream socket. >> When we make small breaks in the script, the jobs runs fine. >> Is it an Error in the desing of the Agent ? > > More a limitation of named pipes on Unix. Just to clarify: that would be a UNIX-domain socket, not a named pipe, hmm? -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) From djm at mindrot.org Wed Dec 22 14:48:13 2004 From: djm at mindrot.org (Damien Miller) Date: Wed, 22 Dec 2004 14:48:13 +1100 Subject: ssh-agent In-Reply-To: <8879E2295D4FE544A35E9C8A16D62BBE7F49@DEDUS-WICL01M01.vf-de.internal.vodafone.com> References: <8879E2295D4FE544A35E9C8A16D62BBE7F49@DEDUS-WICL01M01.vf-de.internal.vodafone.com> Message-ID: <41C8EE7D.1040104@mindrot.org> Beckmann, Frank, VF-DE wrote: > Hi :-) > > We use ssh-agent for batch jobs. > The jobs get the key from the ssh-agent over the envoirment variables. > When we start many jobs at the same time, the agent dont give the key to > the job. How many are you starting simultaneously? ssh-agent sets up a listen backlog of 128 connections by default. -d From senthilkumar_sen at hotpop.com Wed Dec 22 18:15:02 2004 From: senthilkumar_sen at hotpop.com (Senthil Kumar) Date: Wed, 22 Dec 2004 12:45:02 +0530 Subject: Is there a fix available for CAN-2003-0190 References: <042d01c4e748$d06b96f0$140110ac@loguco> <41C808D7.10007@zip.com.au> Message-ID: <059301c4e7f5$fb0eee40$220110ac@sekco> Darren wrote: >You will need to apply both patches. The first patch > (openbsd-sshd-kbdint-leak) affects more than PAM, it affects all other > challenge-response authentications too so it needs wider testing. > > Alternatively, for 3.9p1 set "ChallengeResponseAuthentication no" and > "PasswordAuthentication yes" in sshd_config (and restart sshd, obviously). I tested OpenSSH-3.9p1 with the following options in sshd configuration ChallengeResponseAuthentication `no` KerberosAuthentication `yes` passwordauthentication `yes` but it shows difference in time for the appearance of password prompts for both valid and invalid users. The code shows PAM-password Authentication is not attempted when KerberosAuthentication is enabled. So by disabling kerberosAuthentication there is no difference in time for the appearance of password prompts for both valid and invalid users (ie.both cases have considerable amount of delay). Thanks, Senthil Kumar. ----- Original Message ----- From: "Darren Tucker" To: "Logu" Cc: Sent: Tuesday, December 21, 2004 4:58 PM Subject: Re: Is there a fix available for CAN-2003-0190 > Logu wrote: >> Is there a fix available from openssh for the reported vulnerability >> when pam is enabled. >> http://www.securityfocus.com/bid/11781 > > You will need to apply both patches. The first patch > (openbsd-sshd-kbdint-leak) affects more than PAM, it affects all other > challenge-response authentications too so it needs wider testing. > > Alternatively, for 3.9p1 set "ChallengeResponseAuthentication no" and > "PasswordAuthentication yes" in sshd_config (and restart sshd, obviously). > > -- > 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. > -------------------------------------------------------------------------------- > Index: auth2-chall.c > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/auth2-chall.c,v > retrieving revision 1.21 > diff -u -p -r1.21 auth2-chall.c > --- auth2-chall.c 1 Jun 2004 14:20:45 -0000 1.21 > +++ auth2-chall.c 6 Jul 2004 12:13:10 -0000 > @@ -268,12 +268,9 @@ input_userauth_info_response(int type, u > } > packet_check_eom(); > > - if (authctxt->valid) { > - res = kbdintctxt->device->respond(kbdintctxt->ctxt, > - nresp, response); > - } else { > - res = -1; > - } > + res = kbdintctxt->device->respond(kbdintctxt->ctxt, nresp, response); > + if (!authctxt->valid) > + res = 1; /* keep going if login invalid */ > > for (i = 0; i < nresp; i++) { > memset(response[i], 'r', strlen(response[i])); > @@ -285,7 +282,7 @@ input_userauth_info_response(int type, u > switch (res) { > case 0: > /* Success! */ > - authenticated = 1; > + authenticated = authctxt->valid ? 1 : 0; > break; > case 1: > /* Authentication needs further interaction */ > -------------------------------------------------------------------------------- > Index: auth-pam.c > =================================================================== > RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth-pam.c,v > retrieving revision 1.118 > diff -u -p -r1.118 auth-pam.c > --- auth-pam.c 16 Oct 2004 08:52:44 -0000 1.118 > +++ auth-pam.c 21 Dec 2004 11:23:23 -0000 > @@ -186,6 +186,7 @@ static int sshpam_account_status = -1; > static char **sshpam_env = NULL; > static Authctxt *sshpam_authctxt = NULL; > static const char *sshpam_password = NULL; > +static char badpw[] = "\b\n\r\177INCORRECT"; > > /* Some PAM implementations don't implement this */ > #ifndef HAVE_PAM_GETENVLIST > @@ -746,7 +747,12 @@ sshpam_respond(void *ctx, u_int num, cha > return (-1); > } > buffer_init(&buffer); > - buffer_put_cstring(&buffer, *resp); > + if (sshpam_authctxt->valid && > + (sshpam_authctxt->pw->pw_uid != 0 || > + options.permit_root_login == PERMIT_YES)) > + buffer_put_cstring(&buffer, *resp); > + else > + buffer_put_cstring(&buffer, badpw); > if (ssh_msg_send(ctxt->pam_psock, PAM_AUTHTOK, &buffer) == -1) { > buffer_free(&buffer); > return (-1); > @@ -1093,7 +1099,6 @@ sshpam_auth_passwd(Authctxt *authctxt, c > { > int flags = (options.permit_empty_passwd == 0 ? > PAM_DISALLOW_NULL_AUTHTOK : 0); > - static char badpw[] = "\b\n\r\177INCORRECT"; > > if (!options.use_pam || sshpam_handle == NULL) > fatal("PAM: %s called when PAM disabled or failed to " > -------------------------------------------------------------------------------- > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.791 / Virus Database: 535 - Release Date: 11/13/2004 From senthilkumar_sen at hotpop.com Wed Dec 22 21:20:52 2004 From: senthilkumar_sen at hotpop.com (Senthil Kumar) Date: Wed, 22 Dec 2004 15:50:52 +0530 Subject: Is there a fix available for CAN-2003-0190 References: <042d01c4e748$d06b96f0$140110ac@loguco> <41C808D7.10007@zip.com.au> <059301c4e7f5$fb0eee40$220110ac@sekco> Message-ID: <05ea01c4e80f$ed6b1d30$220110ac@sekco> Hi, I tried the following workaround in auth-krb5.c to overcome the difference in appearance of delay in password prompts for valid and in valid users in OpenSSH-3.9p1. diff auth-krb5.c auth-krb5.c-fix 78,79d77 < if (!authctxt->valid) < return (0); 80a79,81 > if (!authctxt->valid) > ;; With this, there is no difference in time delay for appearance of password prompts for both valid and in valid users with the following options in sshd configuration. ChallengeResponseAuthentication `no` KerberosAuthentication `yes` passwordauthentication `yes` Will there be any problem with this approach? Is it necessary to have this invalid user checking or will there be any impact if I remove this check altogether? Thanks, Senthil Kumar. ----- Original Message ----- From: "Senthil Kumar" To: "Darren Tucker" Cc: Sent: Wednesday, December 22, 2004 12:45 PM Subject: Re: Is there a fix available for CAN-2003-0190 > Darren wrote: > >>You will need to apply both patches. The first patch >> (openbsd-sshd-kbdint-leak) affects more than PAM, it affects all other >> challenge-response authentications too so it needs wider testing. >> >> Alternatively, for 3.9p1 set "ChallengeResponseAuthentication no" and >> "PasswordAuthentication yes" in sshd_config (and restart sshd, >> obviously). > > > I tested OpenSSH-3.9p1 with the following options in sshd configuration > > ChallengeResponseAuthentication `no` > KerberosAuthentication `yes` > passwordauthentication `yes` > > but it shows difference in time for the appearance of password prompts for > both valid and invalid users. The code shows PAM-password Authentication > is not attempted when KerberosAuthentication is enabled. So by disabling > kerberosAuthentication there is no difference in time for the appearance > of password prompts for both valid and invalid users (ie.both cases have > considerable amount of delay). > > Thanks, > Senthil Kumar. > > > > > ----- Original Message ----- > From: "Darren Tucker" > To: "Logu" > Cc: > Sent: Tuesday, December 21, 2004 4:58 PM > Subject: Re: Is there a fix available for CAN-2003-0190 > > >> Logu wrote: >>> Is there a fix available from openssh for the reported vulnerability >>> when pam is enabled. >>> http://www.securityfocus.com/bid/11781 >> >> You will need to apply both patches. The first patch >> (openbsd-sshd-kbdint-leak) affects more than PAM, it affects all other >> challenge-response authentications too so it needs wider testing. >> >> Alternatively, for 3.9p1 set "ChallengeResponseAuthentication no" and >> "PasswordAuthentication yes" in sshd_config (and restart sshd, >> obviously). >> >> -- >> 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. >> > > > -------------------------------------------------------------------------------- > > >> Index: auth2-chall.c >> =================================================================== >> RCS file: /cvs/src/usr.bin/ssh/auth2-chall.c,v >> retrieving revision 1.21 >> diff -u -p -r1.21 auth2-chall.c >> --- auth2-chall.c 1 Jun 2004 14:20:45 -0000 1.21 >> +++ auth2-chall.c 6 Jul 2004 12:13:10 -0000 >> @@ -268,12 +268,9 @@ input_userauth_info_response(int type, u >> } >> packet_check_eom(); >> >> - if (authctxt->valid) { >> - res = kbdintctxt->device->respond(kbdintctxt->ctxt, >> - nresp, response); >> - } else { >> - res = -1; >> - } >> + res = kbdintctxt->device->respond(kbdintctxt->ctxt, nresp, response); >> + if (!authctxt->valid) >> + res = 1; /* keep going if login invalid */ >> >> for (i = 0; i < nresp; i++) { >> memset(response[i], 'r', strlen(response[i])); >> @@ -285,7 +282,7 @@ input_userauth_info_response(int type, u >> switch (res) { >> case 0: >> /* Success! */ >> - authenticated = 1; >> + authenticated = authctxt->valid ? 1 : 0; >> break; >> case 1: >> /* Authentication needs further interaction */ >> > > > -------------------------------------------------------------------------------- > > >> Index: auth-pam.c >> =================================================================== >> RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth-pam.c,v >> retrieving revision 1.118 >> diff -u -p -r1.118 auth-pam.c >> --- auth-pam.c 16 Oct 2004 08:52:44 -0000 1.118 >> +++ auth-pam.c 21 Dec 2004 11:23:23 -0000 >> @@ -186,6 +186,7 @@ static int sshpam_account_status = -1; >> static char **sshpam_env = NULL; >> static Authctxt *sshpam_authctxt = NULL; >> static const char *sshpam_password = NULL; >> +static char badpw[] = "\b\n\r\177INCORRECT"; >> >> /* Some PAM implementations don't implement this */ >> #ifndef HAVE_PAM_GETENVLIST >> @@ -746,7 +747,12 @@ sshpam_respond(void *ctx, u_int num, cha >> return (-1); >> } >> buffer_init(&buffer); >> - buffer_put_cstring(&buffer, *resp); >> + if (sshpam_authctxt->valid && >> + (sshpam_authctxt->pw->pw_uid != 0 || >> + options.permit_root_login == PERMIT_YES)) >> + buffer_put_cstring(&buffer, *resp); >> + else >> + buffer_put_cstring(&buffer, badpw); >> if (ssh_msg_send(ctxt->pam_psock, PAM_AUTHTOK, &buffer) == -1) { >> buffer_free(&buffer); >> return (-1); >> @@ -1093,7 +1099,6 @@ sshpam_auth_passwd(Authctxt *authctxt, c >> { >> int flags = (options.permit_empty_passwd == 0 ? >> PAM_DISALLOW_NULL_AUTHTOK : 0); >> - static char badpw[] = "\b\n\r\177INCORRECT"; >> >> if (!options.use_pam || sshpam_handle == NULL) >> fatal("PAM: %s called when PAM disabled or failed to " >> > > > -------------------------------------------------------------------------------- > > >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev >> > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.791 / Virus Database: 535 - Release Date: 11/13/2004 > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.791 / Virus Database: 535 - Release Date: 11/13/2004 From dtucker at zip.com.au Wed Dec 22 21:34:57 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 22 Dec 2004 21:34:57 +1100 Subject: Is there a fix available for CAN-2003-0190 In-Reply-To: <05ea01c4e80f$ed6b1d30$220110ac@sekco> References: <042d01c4e748$d06b96f0$140110ac@loguco> <41C808D7.10007@zip.com.au> <059301c4e7f5$fb0eee40$220110ac@sekco> <05ea01c4e80f$ed6b1d30$220110ac@sekco> Message-ID: <41C94DD1.1030202@zip.com.au> Senthil Kumar wrote: > I tried the following workaround in auth-krb5.c to overcome the > difference in appearance of delay in password prompts for valid and in > valid users in OpenSSH-3.9p1. [...] >> if (!authctxt->valid) >> ;; > > With this, there is no difference in time delay for appearance of > password prompts for both valid and in valid users with the following > options in sshd configuration. Sorry, I don't use Kerberos and I don't know. Perhaps someone who does could comment? -- 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 robertLinux at gmx.de Wed Dec 22 22:34:52 2004 From: robertLinux at gmx.de (Robert) Date: Wed, 22 Dec 2004 12:34:52 +0100 Subject: scp problem Message-ID: <7F06D757-540D-11D9-8342-0003936EF152@gmx.de> Hello. Since some days I cannot use scp anymore but ssh login work. Reinstall did not help. I do not exactly what has changed but I now it used to work. sshd runs on a firewall-bastion host (Linux SuSE 9.2). Firewall is open on port 22 for local network. Even tried all open (in and outgoing). Between the clent and the firewall-bastion is another nat-router. Works with ssh, though. The strange thing is that I can do a scp from Gutenberg (192.168.1.110) to 192.168.3.110 through the firewall-bastion (NIC eth1 routed to eth2) but not to the firewall itself. The firewall-bastion host has no dns entry, could that be a problem for scp but ssh keeps working? When I scp -vvv form the client "Gutenberg"(192.168.1.110) to 192.168.2.199 I get the following output: welz at Gutenberg:~ welz$ scp -vvv -i .ssh/id_rsa2Firewall welz at 192.168.2.199:ntp.conf test Executing: program /usr/bin/ssh host 192.168.2.199, user welz, command scp -v -f ntp.conf OpenSSH_3.6.1p1+CAN-2004-0175, SSH protocols 1.5/2.0, OpenSSL 0x0090702f debug1: Reading configuration data /etc/ssh_config debug1: Rhosts Authentication disabled, originating port will not be trusted. debug2: ssh_connect: needpriv 0 debug1: Connecting to 192.168.2.199 [192.168.2.199] port 22. debug1: Connection established. debug3: Not a RSA1 key file .ssh/id_rsa2Firewall. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'Proc-Type:' debug3: key_read: missing keytype debug2: key_type_from_name: unknown key type 'DEK-Info:' 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 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_rsa2Firewall type -1 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.6.1p1+CAN-2004-0175 debug3: Trying to reverse map address 192.168.2.199. debug1: An invalid name was supplied Cannot determine realm for numeric host address debug1: An invalid name was supplied A parameter was malformed Validation error debug1: An invalid name was supplied Cannot determine realm for numeric host address debug1: An invalid name was supplied A parameter was malformed Validation error debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-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- cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256- cbc,rijndael-cbc at lysator.liu.se 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 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- hellman-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- 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,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 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 sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 127/256 debug2: bits set: 1030/2048 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /Users/welz/.ssh/known_hosts debug3: check_host_in_hostfile: match line 2 debug1: Host '192.168.2.199' is known and matches the RSA host key. debug1: Found key in /Users/welz/.ssh/known_hosts:2 debug2: bits set: 1020/2048 debug1: ssh_rsa_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 debug3: input_userauth_banner .----------------------------------------------------------------------- ------------. . Welcome to my Music-Box. . . NO ACCESS IS GRANTED BEYOUND THIS POINT! . . Be aware that your connection attempt is logged and misuse will be prosecuted . . Valid law applies. . . . . Willkommen in meiner Musik-Box. . . AB HIER IST DER ZUGANG NICHT ERLAUBT! . . Beachten Sie bitte, das dieser Verbindungsversuch gespeichert wird und Missbrauch . . strafrechtlich und zivilrechtlich verfolgt wird. . .----------------------------------------------------------------------- ------------. debug1: Authentications that can continue: publickey,password,keyboard-interactive debug3: start over, passed a different list publickey,password,keyboard-interactive debug3: preferred external-keyx,gssapi,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/id_rsa2Firewall debug1: PEM_read_PrivateKey failed debug1: read PEM private key done: type Enter passphrase for key '.ssh/id_rsa2Firewall': debug1: read PEM private key done: type RSA debug3: sign_and_send_pubkey debug2: we sent a publickey packet, wait for reply debug1: Authentication succeeded (publickey). debug1: fd 4 setting O_NONBLOCK debug1: fd 5 setting O_NONBLOCK 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: ssh_session2_setup: id 0 debug1: Sending command: scp -v -f ntp.conf debug1: channel 0: request exec debug2: callback done debug1: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 Sink: welz at Gutenberg:~ welz$ debug1: channel 0: read<=0 rfd 4 len 0 debug1: channel 0: read failed debug1: channel 0: close_read debug1: channel 0: input open -> drain debug1: channel 0: ibuf empty debug1: channel 0: send eof debug1: channel 0: input drain -> closed debug2: channel 0: rcvd ext data 40 debug1: channel 0: write failed debug1: channel 0: close_write debug1: channel 0: output open -> closed Sending file modes: C0644 2053 ntp.conf debug2: channel 0: written 40 to efd 6 debug1: client_input_channel_req: channel 0 rtype exit-status reply 0 debug1: channel 0: rcvd eof debug1: channel 0: rcvd close debug3: channel 0: will not send data after close debug1: channel 0: almost dead debug1: channel 0: gc: notify user debug1: channel 0: gc: user detached debug1: channel 0: send close debug1: channel 0: is dead debug1: channel 0: garbage collecting debug1: channel_free: channel 0: client-session, nchannels 1 debug3: channel_free: status: The following connections are open:\015 #0 client-session (t4 r0 i3/0 o3/0 fd -1/-1)\015 debug3: channel_close_fds: channel 0: r -1 w -1 e 6 debug1: fd 0 clearing O_NONBLOCK debug1: fd 1 clearing O_NONBLOCK debug1: Transferred: stdin 0, stdout 0, stderr 0 bytes in 0.0 seconds debug1: Bytes per second: stdin 0.0, stdout 0.0, stderr 0.0 debug1: Exit status 1 From Sergio.Gelato at astro.su.se Thu Dec 23 00:28:53 2004 From: Sergio.Gelato at astro.su.se (Sergio Gelato) Date: Wed, 22 Dec 2004 14:28:53 +0100 Subject: Is there a fix available for CAN-2003-0190 In-Reply-To: <05ea01c4e80f$ed6b1d30$220110ac@sekco> References: <042d01c4e748$d06b96f0$140110ac@loguco> <41C808D7.10007@zip.com.au> <059301c4e7f5$fb0eee40$220110ac@sekco> <05ea01c4e80f$ed6b1d30$220110ac@sekco> Message-ID: <20041222132853.GC1083@hanuman.astro.su.se> * Senthil Kumar [2004-12-22 15:50:52 +0530]: > I tried the following workaround in auth-krb5.c to overcome the difference > in appearance of delay in password prompts for valid and in valid users in > OpenSSH-3.9p1. > > diff auth-krb5.c auth-krb5.c-fix > 78,79d77 > < if (!authctxt->valid) > < return (0); > 80a79,81 > > if (!authctxt->valid) > > ;; It looks to me like you're introducing a bug here. Looking at the code immediately after that test makes it obvious: temporarily_use_uid(authctxt->pw); If the authentication context is invalid, you shouldn't be passing it as an argument to anything. Garbage in, garbage out, the saying goes. In this case you're going to setuid() based on the invalid data... > With this, there is no difference in time delay for appearance of password > prompts for both valid and invalid users with the following options in > sshd configuration. I see that the rest of that function has an "if (problem) goto out;" after every krb5 library call. Doesn't that also introduce measurable time differences? Interesting. Maybe one should fill in a dummy, valid authctxt in such cases, and make a note to fail the authentication at the end of the process. From dtucker at zip.com.au Thu Dec 23 08:57:09 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 23 Dec 2004 08:57:09 +1100 Subject: Is there a fix available for CAN-2003-0190 In-Reply-To: <20041222132853.GC1083@hanuman.astro.su.se> References: <042d01c4e748$d06b96f0$140110ac@loguco> <41C808D7.10007@zip.com.au> <059301c4e7f5$fb0eee40$220110ac@sekco> <05ea01c4e80f$ed6b1d30$220110ac@sekco> <20041222132853.GC1083@hanuman.astro.su.se> Message-ID: <41C9EDB5.1080901@zip.com.au> Sergio Gelato wrote: > I see that the rest of that function has an "if (problem) goto out;" after > every krb5 library call. Doesn't that also introduce measurable time > differences? Interesting. Possibly, but if the latter calls can't be safely done if the earlier ones fail then there may be no way to solve that. > Maybe one should fill in a dummy, valid authctxt in such cases, and > make a note to fail the authentication at the end of the process. That's what authctxt->valid is. The dummy information is populated by auth.c:fakewpw(). -- 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 senthilkumar_sen at hotpop.com Thu Dec 23 22:48:58 2004 From: senthilkumar_sen at hotpop.com (Senthil Kumar) Date: Thu, 23 Dec 2004 17:18:58 +0530 Subject: Is there a fix available for CAN-2003-0190 References: <042d01c4e748$d06b96f0$140110ac@loguco> <41C808D7.10007@zip.com.au><059301c4e7f5$fb0eee40$220110ac@sekco><05ea01c4e80f$ed6b1d30$220110ac@sekco> <20041222132853.GC1083@hanuman.astro.su.se> Message-ID: <079b01c4e8e5$67a68e60$220110ac@sekco> Sergio Gelato wrote; > I see that the rest of that function has an "if (problem) goto out;" after > every krb5 library call. Doesn't that also introduce measurable time > differences? Interesting. I wrote a test case with expect to measure the time difference for valid and invalid user with the same workaround as said before. It seems to have same amount of delay. Logs: Bad user: spawn time /opt/ssh/bin/ssh -l hil 127.0.0.1 ls /usr/bin/sh hil at 127.0.0.1's password: Permission denied, please try again. hil at 127.0.0.1's password: Permission denied, please try again. hil at 127.0.0.1's password: Received disconnect from 127.0.0.1: 2: Too many authentication failures for hil real 6.4 user 0.0 sys 0.0 Good user: spawn time /opt/ssh/bin/ssh -l senthil 127.0.0.1 ls /usr/bin/sh senthil at 127.0.0.1's password: Permission denied, please try again. senthil at 127.0.0.1's password: Permission denied, please try again. senthil at 127.0.0.1's password: Received disconnect from 127.0.0.1: 2: Too many authentication failures for senthil real 6.4 user 0.0 sys 0.0 Also the `if (problem) goto out;` loop doesn't introduce a time difference, bcoz the krb5 library call krb5_get_init_creds_password() fails for both validuser+badpasswd and invaliduser+badpasswd. I hereby attach a test program which points that the above combinations have same fail sequence. However when the program is invoked with validuser+goodkerberospasswd, it will have different sequence. So I like to know whether the removal of authctxt->valid checking in auth-krb5.c have any other impact. Note: I dont know how HEIMDAL will treat it. I use only MIT kerberos. Thanks & regards, Senthil Kumar. ----- Original Message ----- From: "Sergio Gelato" To: "OpenSSH Devel List" Sent: Wednesday, December 22, 2004 6:58 PM Subject: Re: Is there a fix available for CAN-2003-0190 >* Senthil Kumar [2004-12-22 15:50:52 +0530]: >> I tried the following workaround in auth-krb5.c to overcome the >> difference >> in appearance of delay in password prompts for valid and in valid users >> in >> OpenSSH-3.9p1. >> >> diff auth-krb5.c auth-krb5.c-fix >> 78,79d77 >> < if (!authctxt->valid) >> < return (0); >> 80a79,81 >> > if (!authctxt->valid) >> > ;; > > It looks to me like you're introducing a bug here. Looking at the code > immediately after that test makes it obvious: > > temporarily_use_uid(authctxt->pw); > > If the authentication context is invalid, you shouldn't be passing it > as an argument to anything. Garbage in, garbage out, the saying goes. > In this case you're going to setuid() based on the invalid data... > >> With this, there is no difference in time delay for appearance of >> password >> prompts for both valid and invalid users with the following options in >> sshd configuration. > > I see that the rest of that function has an "if (problem) goto out;" after > every krb5 library call. Doesn't that also introduce measurable time > differences? Interesting. > > Maybe one should fill in a dummy, valid authctxt in such cases, and > make a note to fail the authentication at the end of the process. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.791 / Virus Database: 535 - Release Date: 11/14/2004 From senthilkumar_sen at hotpop.com Thu Dec 23 23:09:23 2004 From: senthilkumar_sen at hotpop.com (Senthil Kumar) Date: Thu, 23 Dec 2004 17:39:23 +0530 Subject: Is there a fix available for CAN-2003-0190(with test program) Message-ID: <07c201c4e8e8$41126dc0$220110ac@sekco> > Sergio Gelato wrote; >> I see that the rest of that function has an "if (problem) goto out;" >> after >> every krb5 library call. Doesn't that also introduce measurable time >> differences? Interesting. > I wrote a test case with expect to measure the time difference for valid and invalid user with the same workaround as said before. It seems to have same amount of delay. Logs: Bad user: spawn time /opt/ssh/bin/ssh -l hil 127.0.0.1 ls /usr/bin/sh hil at 127.0.0.1's password: Permission denied, please try again. hil at 127.0.0.1's password: Permission denied, please try again. hil at 127.0.0.1's password: Received disconnect from 127.0.0.1: 2: Too many authentication failures for hil real 6.4 user 0.0 sys 0.0 Good user: spawn time /opt/ssh/bin/ssh -l senthil 127.0.0.1 ls /usr/bin/sh senthil at 127.0.0.1's password: Permission denied, please try again. senthil at 127.0.0.1's password: Permission denied, please try again. senthil at 127.0.0.1's password: Received disconnect from 127.0.0.1: 2: Too many authentication failures for senthil real 6.4 user 0.0 sys 0.0 Also the `if (problem) goto out;` loop doesn't introduce a time difference, bcoz the krb5 library call krb5_get_init_creds_password() fails for both validuser+badpasswd and invaliduser+badpasswd. I hereby given a test program which points that the above combinations have same fail sequence. However when the program is invoked with validuser+goodkerberospasswd, it will have different sequence. So I like to know whether the removal of authctxt->valid checking in auth-krb5.c have any other impact. Note: I dont know how HEIMDAL will treat it. I use only MIT kerberos. Thanks & regards, Senthil Kumar. Test Program: /* Senthil test program for Kerberos */ /* To compile cc -o check_valid Test_krb5.c -lkrb5 */ /* To run ./check_valid */ #include #include int main(int argc,char **argv) { krb5_error_code problem; krb5_context context=NULL; krb5_principal client = NULL; krb5_creds creds; char *str=argv[1]; char *mypassword=NULL; if (context == NULL) { problem = krb5_init_context(&context); if(problem) { printf("\nproblem in initialization and krb5_init_context fails\n"); exit(0); } else printf("\nNo problem in initialization and krb5_init_context succeeds\n"); } problem=krb5_parse_name(context,str,&client); if(problem) { printf("\nproblem in parsing and krb5_parse_name fails\n"); exit(0); } else printf("\nNo problem in parsing and krb5_parse_name succeeds\n"); mypassword=argv[2]; problem=krb5_get_init_creds_password(context,&creds,client,(char *)mypassword,NULL,NULL,0,NULL,NULL); if(problem) { printf("\nProblem in initialization of credentials and krb5_get_init_creds_password fails\n"); exit(0); } else printf("\nNo problem in initialization of credentials and krb5_get_init_creds_password succeeds\n"); } > > ----- Original Message ----- > From: "Sergio Gelato" > To: "OpenSSH Devel List" > Sent: Wednesday, December 22, 2004 6:58 PM > Subject: Re: Is there a fix available for CAN-2003-0190 > > >>* Senthil Kumar [2004-12-22 15:50:52 +0530]: >>> I tried the following workaround in auth-krb5.c to overcome the >>> difference >>> in appearance of delay in password prompts for valid and in valid users >>> in >>> OpenSSH-3.9p1. >>> >>> diff auth-krb5.c auth-krb5.c-fix >>> 78,79d77 >>> < if (!authctxt->valid) >>> < return (0); >>> 80a79,81 >>> > if (!authctxt->valid) >>> > ;; >> >> It looks to me like you're introducing a bug here. Looking at the code >> immediately after that test makes it obvious: >> >> temporarily_use_uid(authctxt->pw); >> >> If the authentication context is invalid, you shouldn't be passing it >> as an argument to anything. Garbage in, garbage out, the saying goes. >> In this case you're going to setuid() based on the invalid data... >> >>> With this, there is no difference in time delay for appearance of >>> password >>> prompts for both valid and invalid users with the following options in >>> sshd configuration. >> >> I see that the rest of that function has an "if (problem) goto out;" >> after >> every krb5 library call. Doesn't that also introduce measurable time >> differences? Interesting. >> >> Maybe one should fill in a dummy, valid authctxt in such cases, and >> make a note to fail the authentication at the end of the process. >> >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > --- > Outgoing mail is certified Virus Free. > Checked by AVG anti-virus system (http://www.grisoft.com). > Version: 6.0.791 / Virus Database: 535 - Release Date: 11/14/2004 > --- File has not been scanned Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.791 / Virus Database: 535 - Release Date: 11/14/2004 From Sergio.Gelato at astro.su.se Thu Dec 23 23:28:10 2004 From: Sergio.Gelato at astro.su.se (Sergio Gelato) Date: Thu, 23 Dec 2004 13:28:10 +0100 Subject: Is there a fix available for CAN-2003-0190 In-Reply-To: <079b01c4e8e5$67a68e60$220110ac@sekco> References: <042d01c4e748$d06b96f0$140110ac@loguco> <20041222132853.GC1083@hanuman.astro.su.se> <079b01c4e8e5$67a68e60$220110ac@sekco> Message-ID: <20041223122809.GA2166@hanuman.astro.su.se> * Senthil Kumar [2004-12-23 17:18:58 +0530]: > Sergio Gelato wrote; > >I see that the rest of that function has an "if (problem) goto out;" after > >every krb5 library call. Doesn't that also introduce measurable time > >differences? Interesting. > > I wrote a test case with expect to measure the time difference for valid > and invalid user with the same workaround as said before. It seems to have > same amount of delay. I've been thinking a little more about this, and suspect (but haven't actually verified) that this may depend on how your realm is set up. > Also the `if (problem) goto out;` loop doesn't introduce a time > difference, bcoz the krb5 library call krb5_get_init_creds_password() > fails for both validuser+badpasswd and invaliduser+badpasswd. Yes, but in some setups the validuser+badpassword may involve an extra round-trip to the KDC. I'm thinking of situations in which the principal is marked "requires-preauth" and the client krb5 library doesn't take the initiative of sending the PA-DATA in the first request. Arguably this should be fixed by telling the client libkrb5 to always send PA-DATA, so it isn't necessarily something OpenSSH should concern itself with. [Note also that if the attacker knows that Kerberos is involved and can talk directly to the KDC, (s)he can find out which principals exist a lot more easily than through ssh.] > So I like to know whether the removal of authctxt->valid checking in > auth-krb5.c have any other impact. Well, Darren seems willing to vouch for the fact that authctxt->pw will contain safe data, now and in future versions. If that's the case, moving the authctxt->valid check to the out: block at the end of the function should be OK. I was going to suggest that the fake authctxt->pw be chosen to imply a valid Kerberos principal, but on second thought it's probably better to resolve any timing differences at the krb5.conf (library configuration) level so that other applications may also benefit. From bburke at berkeley.edu Thu Dec 23 17:36:02 2004 From: bburke at berkeley.edu (Brian C Burke) Date: Wed, 22 Dec 2004 22:36:02 -0800 Subject: openssh-3.9p1 for Mac OS X Message-ID: I attempted to setup openssh-3.9p1 on Mac OS X (10.3.7). The ./configure and make work fine but 'make install' fails with: computer:~/XDev/openssh-3.9p1 bcburke$ make install if test ! -z ""; then \ /usr/bin/perl ./fixprogs ssh_prng_cmds ; \ fi (cd openbsd-compat && make) make[1]: Nothing to be done for `all'. (cd scard && make DESTDIR= install) ../mkinstalldirs /usr/local/share make[1]: execvp: ../mkinstalldirs: Permission denied make[1]: *** [install] Error 127 make: *** [scard-install] Error 2 This error occurs even if done as root. Is this just a permission problem or is there more to it? Any pointers would be appreciated. Thanks, Brian From enrique.quintanilla at autosummit.com.mx Fri Dec 24 10:41:02 2004 From: enrique.quintanilla at autosummit.com.mx (Enrique Quintanilla) Date: Thu, 23 Dec 2004 17:41:02 -0600 Subject: RV: As root and as any user Message-ID: This is the first time i wrote you, i would like to know if you have any idea about my problem: ? I install and conigure the last version of openssh and it is working like a root user ? $ ssh root at server ? and it?s just fine, even i can use CVS software, but if a try to use it with other user it doesn`t work ? $ ssh any at server ? ask me for a password and it wrote me, ?have a lot of fun? and inmediatly ?connection to server closed? could you please help me. ? ? Enrique Quintanilla Gzz. Auto Summit Commercial Services, S.A. de C.V. Tel. (81) 88 65 73 89 ? ? From djm at mindrot.org Fri Dec 24 10:50:16 2004 From: djm at mindrot.org (Damien Miller) Date: Fri, 24 Dec 2004 10:50:16 +1100 Subject: RV: As root and as any user In-Reply-To: References: Message-ID: <41CB59B8.6070805@mindrot.org> Enrique Quintanilla wrote: > This is the first time i wrote you, i would like to know if you have any > idea about my problem: > > I install and conigure the last version of openssh and it is working > like a root user > > $ ssh root at server > > and it?s just fine, even i can use CVS software, but if a try to use it > with other user it doesn`t work > > $ ssh any at server > > ask me for a password and it wrote me, ?have a lot of fun? and > inmediatly ?connection to server closed? > could you please help me. You will need to provide some more details, in particular: 1. A verbose trace of a connection to your server ("ssh -vvv any at server") 2. A debug trace from the server when you connect to it. ("sshd -ddde") 3. What OS, version and configure options that you are using -d From venelin at fcolor.bg Sat Dec 25 03:58:30 2004 From: venelin at fcolor.bg (Venelin Mihaylov) Date: Fri, 24 Dec 2004 18:58:30 +0200 Subject: openssh authentication for non-system users Message-ID: <1103907510.8965.5.camel@localhost.localdomain> Hello, I am trying to write an PAM module for openssh, which should authenticate users using an MySQL database (it is based on pam_mysql). The problem is that I do not know what is necessary to authenticate successfully users, which do not have entries in /etc/passwd, for them I get invalid user :(. I will greatly appreciate any info on the matter. I have been pulling my hair out for almost two days on this, searched google numerous times, but without any success. I also tried to read the source code, but apparently I am not good enough to comprehend it. Thank you. Venelin Mihaylov From stuge-openssh-unix-dev at cdy.org Sat Dec 25 07:46:22 2004 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 24 Dec 2004 21:46:22 +0100 Subject: openssh authentication for non-system users In-Reply-To: <1103907510.8965.5.camel@localhost.localdomain> References: <1103907510.8965.5.camel@localhost.localdomain> Message-ID: <20041224204622.GA2521@foo.birdnet.se> On Fri, Dec 24, 2004 at 06:58:30PM +0200, Venelin Mihaylov wrote: > Hello, > I am trying to write an PAM module for openssh, which should > authenticate users using an MySQL database (it is based on > pam_mysql). > The problem is that I do not know what is necessary to authenticate > successfully users, which do not have entries in /etc/passwd, for > them I get invalid user :(. I think you need to make an NSS module as well, which will make getpwnam() and friends work properly with your user database. Check out nsswitch.conf(5) on Linux or Solaris for more info. //Peter From senthilkumar_sen at hotpop.com Fri Dec 24 21:16:07 2004 From: senthilkumar_sen at hotpop.com (Senthil Kumar) Date: Fri, 24 Dec 2004 15:46:07 +0530 Subject: Is there a fix available for CAN-2003-0190 References: <042d01c4e748$d06b96f0$140110ac@loguco><20041222132853.GC1083@hanuman.astro.su.se><079b01c4e8e5$67a68e60$220110ac@sekco> <20041223122809.GA2166@hanuman.astro.su.se> Message-ID: <090301c4e9a1$98e49460$220110ac@sekco> Hi, I moved the authctxt->valid check to the `out: ` block replacing the kerberosorlocalpasswd checking and the diff is given below. Now there is no difference in time delay for the appearance of prompts, in case of valid and invalid user in my setup. diff auth-krb5-openssh.c auth-krb5-fix.c 78,79d77 < if (!authctxt->valid) < return (0); 206,209c204,207 < if (options.kerberos_or_local_passwd) < return (-1); < else < return (0); --- > if((authctxt->valid && options.kerberos_or_local_passwd) + > options.kerberos_or_local_passwd) > return (-1); > else > return (0); Any comments?? Thanks, Senthil Kumar. ----- Original Message ----- From: "Sergio Gelato" To: "Senthil Kumar" Cc: "OpenSSH Devel List" Sent: Thursday, December 23, 2004 5:58 PM Subject: Re: Is there a fix available for CAN-2003-0190 >* Senthil Kumar [2004-12-23 17:18:58 +0530]: >> Sergio Gelato wrote; >> >I see that the rest of that function has an "if (problem) goto out;" >> >after >> >every krb5 library call. Doesn't that also introduce measurable time >> >differences? Interesting. >> >> I wrote a test case with expect to measure the time difference for valid >> and invalid user with the same workaround as said before. It seems to >> have >> same amount of delay. > > I've been thinking a little more about this, and suspect (but haven't > actually verified) that this may depend on how your realm is set up. > >> Also the `if (problem) goto out;` loop doesn't introduce a time >> difference, bcoz the krb5 library call krb5_get_init_creds_password() >> fails for both validuser+badpasswd and invaliduser+badpasswd. > > Yes, but in some setups the validuser+badpassword may involve an extra > round-trip to the KDC. I'm thinking of situations in which the principal > is marked "requires-preauth" and the client krb5 library doesn't take the > initiative of sending the PA-DATA in the first request. Arguably this > should be fixed by telling the client libkrb5 to always send PA-DATA, > so it isn't necessarily something OpenSSH should concern itself with. > > [Note also that if the attacker knows that Kerberos is involved and can > talk directly to the KDC, (s)he can find out which principals exist a lot > more easily than through ssh.] > >> So I like to know whether the removal of authctxt->valid checking in >> auth-krb5.c have any other impact. > > Well, Darren seems willing to vouch for the fact that authctxt->pw will > contain safe data, now and in future versions. If that's the case, > moving the authctxt->valid check to the out: block at the end of the > function should be OK. I was going to suggest that the fake authctxt->pw > be chosen to imply a valid Kerberos principal, but on second thought it's > probably better to resolve any timing differences at the krb5.conf > (library configuration) level so that other applications may also benefit. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.791 / Virus Database: 535 - Release Date: 11/15/2004 From robertLinux at gmx.de Sun Dec 26 04:11:34 2004 From: robertLinux at gmx.de (Robert) Date: Sat, 25 Dec 2004 18:11:34 +0100 Subject: openssh-3.9p1 for Mac OS X In-Reply-To: <20041223233729.899B927C354@shitei.mindrot.org> References: <20041223233729.899B927C354@shitei.mindrot.org> Message-ID: <079B57FE-5698-11D9-B164-0003936EF152@gmx.de> Am 24.12.2004 um 00:37 schrieb openssh-unix-dev-request at mindrot.org: > openssh-3.9p1 for Mac OS X (cd openbsd-compat && make) make[1]: Nothing to be done for `all'. (cd scard && make DESTDIR= install) ../mkinstalldirs /usr/local/share It should be a permission problem, since my compilation of openSSH39p1 did work out of the box;) ls -l /usr/local/share drwxr-xr-x 4 root svn 136 3 Dec 00:18 share ignore the group, it will be ignored when make is called as root. If that does not work start even the ./configure as root. Hope that work, Robert Welz From dkg-openssh.com at fifthhorseman.net Mon Dec 27 12:45:08 2004 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Sun, 26 Dec 2004 20:45:08 -0500 Subject: Potential DoS against forwarded ssh-agent Message-ID: <16847.26916.280471.965643@pinhead.lair.fifthhorseman.net> It appears there is an opportunity for a denial-of-service attack against ssh-agent when using ForwardAgent. This note describes the circumstances, and provides a patch. Background (not the vulnerability): If ssh-agent is forwarded to a compromised account, a remote attacker could use the connection to authenticate as the owner of the agent. "ssh-add -c" currently defends against this risk by requiring the owner of the agent to confirm each key access with $SSH_ASKPASS. This protects against unauthorized remote authentication, but leaves open other channels of attack. ssh-agent DoS vulnerability: The remote attacker controlling the compromised account can still launch a denial-of-service attack against the ssh-agent session itself by either (A) locking it ("ssh-add -x") or (B) deleting keys ("ssh-add -[dD]"). This attack effectively disables the agent, and the owner of the agent is unable to defend against it. Proposed Workaround: Add a -r ("require confirmation") flag to ssh-agent. When present, the agent will use $SSH_ASKPASS to confirm any request to delete keys or lock the agent. i've attached a patch (against the current CVS head: ssh-agent.c v1.122 and ssh-agent.1 v1.41) which works for me. i welcome any and all feedback. Is this the right way to go about resolving this problem? The likelihood of this type of attack on today's 'net is probably low, and the consequences are of a lower grade than, say, unauthorized authentication. And of course, ForwardAgent should be kept to a minimum in general for security. However, in the circumstances where ForwardAgent is warranted, i'd like to be able to rely on my local system to alert me to any tampering with the agent from remote hosts. Regards, --dkg -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ssh-agent-require-confirmation.diff Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20041226/415f2766/attachment.ksh From weigelt at metux.de Tue Dec 28 03:06:28 2004 From: weigelt at metux.de (Enrico Weigelt) Date: Mon, 27 Dec 2004 17:06:28 +0100 Subject: [patch] some buildsystem fixes for crosscompiling Message-ID: <20041227160628.GA24247@nibiru.borg.metux.de> Hi folks, here're some quick+dirty fixes to allow sysroot'ed crosscompiling. probably not yet very clean, but seems to work. 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 -- --------------------------------------------------------------------- -------------- next part -------------- --- openssh-3.7.1p2-orig/configure.ac Tue Sep 23 11:24:21 2003 +++ openssh-3.7.1p2/configure.ac Sun Oct 26 17:31:06 2003 @@ -467,6 +467,10 @@ [ AC_MSG_RESULT(no) AC_MSG_ERROR([*** compiler cannot create working executables, check config.log ***]) + ], + [ + AC_MSG_RESULT(yes) + AC_MSG_WARN([Cannot run test when crosscompiling, defaulted to yes.]) ] ) @@ -637,6 +641,9 @@ [ AC_MSG_RESULT(no) AC_DEFINE(BROKEN_ONE_BYTE_DIRENT_D_NAME) + ], + [AC_MSG_RESULT(yes) + AC_MSG_WARN([Cannot run test when crosscompiling, defaulted to yes.]) ] ) @@ -668,6 +675,9 @@ [ AC_MSG_RESULT(no) AC_MSG_ERROR([** Incomplete or missing s/key libraries.]) + ], + [AC_MSG_RESULT(yes) + AC_MSG_WARN([Cannot run test when crosscompiling, defaulted to yes.]) ]) fi ] @@ -803,6 +813,9 @@ AC_MSG_RESULT(no) AC_DEFINE(BROKEN_SNPRINTF) AC_MSG_WARN([****** Your snprintf() function is broken, complain to your vendor]) + ], + [AC_MSG_RESULT(yes) + AC_MSG_WARN([Cannot run test when crosscompiling, defaulted to yes.]) ] ) fi @@ -876,6 +889,10 @@ [ AC_MSG_RESULT(no) AC_DEFINE(SSHD_ACQUIRES_CTTY) + ], + [ + AC_MSG_RESULT(yes) + AC_MSG_WARN([Cannot run test when crosscompiling, defaulted to yes.]) ] ) fi @@ -1011,6 +1028,10 @@ [ AC_MSG_RESULT(not found) AC_MSG_ERROR(OpenSSL version header not found.) + ], + [ + ssl_header_ver="VERSION" + AC_MSG_WARN([Cannot run test when crosscompiling, defaulted to $ssl_header_ver]) ] ) @@ -1044,6 +1065,10 @@ [ AC_MSG_RESULT(not found) AC_MSG_ERROR(OpenSSL library not found.) + ], + [ + ssl_library_ver="VERSION" + AC_MSG_WARN([Cannot run test when crosscompiling, defaulted to $ssl_library_ver]) ] ) @@ -1063,7 +1088,12 @@ AC_MSG_ERROR([Your OpenSSL headers do not match your library. Check config.log for details. Also see contrib/findssl.sh for help identifying header/library mismatches.]) + ], + [ + AC_MSG_RESULT(yes) + AC_MSG_WARN([Cannot run test when crosscompiling, defaulted to yes.]) ] + ) # Some Linux systems (Slackware) need crypt() from libcrypt, *not* the @@ -1092,6 +1122,11 @@ # Default to use of the rand helper if OpenSSL doesn't # seed itself USE_RAND_HELPER=yes + ], + [ + OPENSSL_SEEDS_ITSELF=yes + AC_MSG_RESULT(yes) + AC_MSG_WARN([Cannot run test when crosscompiling, defaulted to yes.]) ] ) @@ -1682,7 +1717,8 @@ #else main() { exit(0); } #endif - ], [ true ], [ AC_DEFINE(BROKEN_SNPRINTF) ] + ], [ true ], [ AC_DEFINE(BROKEN_SNPRINTF) ], + [ true ] ) fi @@ -1802,6 +1838,7 @@ } ], [ ac_cv_have_accrights_in_msghdr="yes" ], + [ ac_cv_have_accrights_in_msghdr="no" ], [ ac_cv_have_accrights_in_msghdr="no" ] ) ]) @@ -1826,7 +1863,8 @@ } ], [ ac_cv_have_control_in_msghdr="yes" ], - [ ac_cv_have_control_in_msghdr="no" ] + [ ac_cv_have_control_in_msghdr="no" ], + [ ac_cv_have_control_in_msghdr="yes" ] ) ]) if test "x$ac_cv_have_control_in_msghdr" = "xyes" ; then @@ -2115,13 +2153,14 @@ ) fi fi +if test "$cross_compiling" != yes; then AC_CHECK_FILE("/dev/ptc", [ AC_DEFINE_UNQUOTED(HAVE_DEV_PTS_AND_PTC) have_dev_ptc=1 ] ) - +fi # Options from here on. Some of these are preset by platform above AC_ARG_WITH(mantype, [ --with-mantype=man|cat|doc Set man page type], @@ -2215,15 +2254,18 @@ fi # check for /etc/default/login and use it if present. +#if test "$cross_compiling" != yes; then AC_ARG_ENABLE(etc-default-login, [ --disable-etc-default-login Disable using PATH from /etc/default/login [no]],, [ -AC_CHECK_FILE("/etc/default/login", [ external_path_file=/etc/default/login ]) +AC_CHECK_FILE("/etc/default/login", [ external_path_file=/etc/default/login ],,) if test "x$external_path_file" = "x/etc/default/login"; then AC_DEFINE(HAVE_ETC_DEFAULT_LOGIN) fi -]) +] +) +#fi dnl BSD systems use /etc/login.conf so --with-default-path= has no effect if test $ac_cv_func_login_getcapbool = "yes" -a \ diff -ruN openssh-3.9p1.orig/configure openssh-3.9p1/configure --- openssh-3.9p1.orig/configure Wed Nov 24 11:21:15 2004 +++ openssh-3.9p1/configure Wed Nov 24 11:25:06 2004 @@ -4010,10 +4010,7 @@ fi -if test -z "$LD" ; then - LD=$CC -fi - +LD="$CC -s" echo "$as_me:$LINENO: checking for inline" >&5 echo $ECHO_N "checking for inline... $ECHO_C" >&6 diff -ruN openssh-3.9p1.orig/configure.ac openssh-3.9p1/configure.ac --- openssh-3.9p1.orig/configure.ac Wed Nov 24 11:21:15 2004 +++ openssh-3.9p1/configure.ac Wed Nov 24 11:25:40 2004 @@ -71,9 +71,8 @@ AC_DEFINE_UNQUOTED(_PATH_PASSWD_PROG, "$PATH_PASSWD_PROG") fi -if test -z "$LD" ; then - LD=$CC -fi +LD="$CC -s" + AC_SUBST(LD) AC_C_INLINE diff -ruN openssh-3.9p1.orig/configure.ac openssh-3.9p1/configure.ac --- openssh-3.9p1.orig/configure.ac Tue Dec 14 07:41:04 2004 +++ openssh-3.9p1/configure.ac Tue Dec 14 07:41:50 2004 @@ -642,34 +642,7 @@ ] ) -AC_MSG_CHECKING(for zlib 1.1.4 or greater) -AC_TRY_RUN([ -#include -int main() -{ - int a, b, c, v; - if (sscanf(ZLIB_VERSION, "%d.%d.%d", &a, &b, &c) != 3) - exit(1); - v = a*1000000 + b*1000 + c; - if (v >= 1001004) - exit(0); - exit(2); -} - ], - AC_MSG_RESULT(yes), - [ AC_MSG_RESULT(no) - if test -z "$zlib_check_nonfatal" ; then - AC_MSG_ERROR([*** zlib too old - check config.log *** -Your reported zlib version has known security problems. It's possible your -vendor has fixed these problems without changing the version number. If you -are sure this is the case, you can disable the check by running -"./configure --without-zlib-version-check". -If you are in doubt, upgrade zlib to version 1.1.4 or greater.]) - else - AC_MSG_WARN([zlib version may have security problems]) - fi - ] -) +AC_MSG_CHECKING(for zlib 1.1.4 or greater - disabled) dnl UnixWare 2.x AC_CHECK_FUNC(strcasecmp, diff -ruN openssh-3.9p1.orig/configure.ac openssh-3.9p1/configure.ac --- openssh-3.9p1.orig/configure.ac Tue Dec 14 07:43:36 2004 +++ openssh-3.9p1/configure.ac Tue Dec 14 07:44:15 2004 @@ -867,34 +867,6 @@ AC_CHECK_DECLS(h_errno, , ,[#include ]) -AC_CHECK_FUNCS(setresuid, [ - dnl Some platorms have setresuid that isn't implemented, test for this - AC_MSG_CHECKING(if setresuid seems to work) - AC_TRY_RUN([ -#include -#include -int main(){errno=0; setresuid(0,0,0); if (errno==ENOSYS) exit(1); else exit(0);} - ], - [AC_MSG_RESULT(yes)], - [AC_DEFINE(BROKEN_SETRESUID) - AC_MSG_RESULT(not implemented)] - ) -]) - -AC_CHECK_FUNCS(setresgid, [ - dnl Some platorms have setresgid that isn't implemented, test for this - AC_MSG_CHECKING(if setresgid seems to work) - AC_TRY_RUN([ -#include -#include -int main(){errno=0; setresgid(0,0,0); if (errno==ENOSYS) exit(1); else exit(0);} - ], - [AC_MSG_RESULT(yes)], - [AC_DEFINE(BROKEN_SETRESGID) - AC_MSG_RESULT(not implemented)] - ) -]) - dnl Checks for time functions AC_CHECK_FUNCS(gettimeofday time) dnl Checks for utmp functions diff -ruN openssh-3.9p1.orig/configure.ac openssh-3.9p1/configure.ac --- openssh-3.9p1.orig/configure.ac Tue Dec 14 07:53:10 2004 +++ openssh-3.9p1/configure.ac Tue Dec 14 07:53:42 2004 @@ -2359,12 +2359,6 @@ ) fi fi -AC_CHECK_FILE("/dev/ptc", - [ - AC_DEFINE_UNQUOTED(HAVE_DEV_PTS_AND_PTC) - have_dev_ptc=1 - ] -) # Options from here on. Some of these are preset by platform above AC_ARG_WITH(mantype, From kochera at postfinance.ch Tue Dec 28 20:18:08 2004 From: kochera at postfinance.ch (kochera at postfinance.ch) Date: Tue, 28 Dec 2004 10:18:08 +0100 Subject: OpenSSH 3.9p1 X11 forwarding Message-ID: Hi, We upgraded from 3.7.1p2 to 3.9p1. The behaviour of the X11 forwarding changed significantly, it is much slower. See below the truss output (server side which runs 3.7.1p2) an check for the timestamp (6 seconds delay). Do you have any idea what may causes this behaviour? Platform is Solaris 5.9 Generic_117171-05. Thanks in advance, Andy Kocher 19279: 9.5463 sigaction(SIGCLD, 0x00000000, 0xFFBFF1C0) = 0 19279: 9.5464 sigaction(SIGCLD, 0xFFBFF140, 0x00000000) = 0 19279: 9.5464 pipe() = 4 [5] 19279: 9.5465 fcntl(4, F_SETFD, 0x00000001) = 0 19279: 9.5465 fcntl(5, F_SETFD, 0x00000001) = 0 19279: 9.5466 fcntl(4, F_GETFL, 0x00000000) = 2 19279: 9.5466 fcntl(4, F_SETFL, 0x00000082) = 0 19279: 9.5467 fcntl(5, F_GETFL, 0x00000000) = 2 19279: 9.5467 fcntl(5, F_SETFL, 0x00000082) = 0 19279: 9.5468 poll(0xFFBFF150, 2, -1) = 1 19279: 9.5469 sigfillset(0xFF042940) = 0 19279: 9.5469 sigprocmask(SIG_BLOCK, 0xFFBFF1E0, 0xFFBFF1F0) = 0 19279: 9.5470 sigprocmask(SIG_SETMASK, 0xFFBFF1F0, 0x00000000) = 0 19279: 9.5471 read(6, " k RD0 - v82190390D8D8 `".., 16384) = 64 19279: 9.5474 ioctl(-1, TCGETA, 0xFFBFEFAC) Err#9 EBADF 19279: 9.5476 ioctl(-1, TCGETA, 0xFFBFEFAC) Err#9 EBADF 19279: 9.5478 poll(0xFFBFF150, 2, -1) = 1 19279: 9.5479 sigprocmask(SIG_BLOCK, 0xFFBFF1E0, 0xFFBFF1F0) = 0 19279: 9.5479 sigprocmask(SIG_SETMASK, 0xFFBFF1F0, 0x00000000) = 0 19279: 9.5480 write(6, "19B7 vFFFCBD `F7019A '8F".., 48) = 48 19275: read(5, 0xFFBFF188, 4) (sleeping...) 19016: poll(0xFFBFF2B0, 2, -1) (sleeping...) 19279: poll(0xFFBFF150, 2, -1) (sleeping...) 19279: 15.5926 poll(0xFFBFF150, 2, -1) = 1 19279: 15.5928 sigprocmask(SIG_BLOCK, 0xFFBFF1E0, 0xFFBFF1F0) = 0 19279: 15.5929 sigprocmask(SIG_SETMASK, 0xFFBFF1F0, 0x00000000) = 0 19279: 15.5930 read(6, " {9011 C82F0FE ZBFC8 .DC".., 16384) = 112 19279: 15.5934 stat64("/usr/openwin/bin/xauth", 0xFFBFEFA0) = 0 19279: 15.5938 so_socket(PF_INET6, SOCK_STREAM, IPPROTO_IP, "", 1) = 8 19279: 15.5940 bind(8, 0x00072238, 32, 3) Err#126 EADDRNOTAVAIL 19279: 15.5942 close(8) = 0 19279: 15.5944 so_socket(PF_INET, SOCK_STREAM, IPPROTO_IP, "", 1) = 8 19279: 15.5946 bind(8, 0x0007F108, 16, 3) Err#125 EADDRINUSE 19279: 15.5947 close(8) = 0 19279: 15.5948 so_socket(PF_INET6, SOCK_STREAM, IPPROTO_IP, "", 1) = 8 19279: 15.5949 bind(8, 0x00072238, 32, 3) Err#126 EADDRNOTAVAIL 19279: 15.5949 close(8) = 0 19279: 15.5950 so_socket(PF_INET, SOCK_STREAM, IPPROTO_IP, "", 1) = 8 19279: 15.5951 bind(8, 0x0007F108, 16, 3) Err#125 EADDRINUSE 19279: 15.5952 close(8) = 0 19279: 15.5952 so_socket(PF_INET6, SOCK_STREAM, IPPROTO_IP, "", 1) = 8 19279: 15.5953 bind(8, 0x00072238, 32, 3) Err#126 EADDRNOTAVAIL 19279: 15.5954 close(8) = 0 19279: 15.5955 so_socket(PF_INET, SOCK_STREAM, IPPROTO_IP, "", 1) = 8 19279: 15.5955 bind(8, 0x0007F108, 16, 3) = 0 19279: 15.5956 listen(8, 5, 1) = 0 19279: 15.5957 brk(0x00085B18) = 0 19279: 15.5957 brk(0x00087B18) = 0 19279: 15.5958 ioctl(8, TCGETA, 0xFFBFE85C) Err#22 EINVAL 19279: 15.5959 ioctl(8, TCGETA, 0xFFBFE85C) Err#22 EINVAL 19279: 15.5960 fcntl(8, F_GETFL, 0x00000000) = 2 19279: 15.5960 fcntl(8, F_SETFL, 0x00000082) = 0 19279: 15.5961 fcntl(8, F_GETFL, 0x00000000) = 130 19279: 15.5963 uname(0xFFBFE538) = 1 19279: 15.5965 poll(0xFFBFF140, 3, -1) = 1 19279: 15.5966 sigprocmask(SIG_BLOCK, 0xFFBFF1E0, 0xFFBFF1F0) = 0 19279: 15.5966 sigprocmask(SIG_SETMASK, 0xFFBFF1F0, 0x00000000) = 0 19279: 15.5967 read(6, "A0E9B6C5 \B6 g03 C\tC59E".., 16384) = 400 19279: 15.5969 door_info(3, 0xFFBFE7C8) = 0 19279: 15.5971 door_call(3, 0xFFBFE7B0) = 0 19279: 15.5972 stat64("/var/adm/lastlog", 0xFFBFE6D0) = 0 19279: 15.5974 open64("/var/adm/lastlog", O_RDONLY) = 9 19279: 15.5975 llseek(9, 2800, SEEK_SET) = 2800 19279: 15.5975 read(9, " AD119AE p t s / 4\0\0\0".., 28) = 28 19279: 15.5976 close(9) = 0 19279: 15.5977 brk(0x00087B18) = 0 19279: 15.5978 brk(0x00089B18) = 0 19279: 15.5979 write(7, "\0\0\00119", 5) = 5 19275: 15.5979 read(5, "\0\0\001", 4) = 4 19275: 15.5981 read(5, "19", 1) = 1 19275: 15.5984 open64("/dev/ptmx", O_RDWR|O_NOCTTY) = 4 19275: 15.5986 sigaction(SIGCLD, 0x00000000, 0xFFBFF070) = 0 19275: 15.5987 ioctl(4, I_STR, 0xFFBFEF90) = 0 19275: 15.5988 fstat64(4, 0xFFBFEEF8) = 0 19275: 15.5988 sigfillset(0xFF042940) = 0 19275: 15.5989 sigprocmask(SIG_BLOCK, 0xFFBFF04C, 0xFFBFF03C) = 0 19275: 15.5992 vfork() = 19281 19281: 15.5992 vfork() (returning as child ...) = 19275 19281: 15.6028 execve("/usr/lib/pt_chmod", 0xFFBFF014, 0xFFBFFD04) argc = 2 19281: 15.6034 resolvepath("/usr/lib/pt_chmod", "/usr/lib/pt_chmod", 1023) = 17 19281: 15.6035 resolvepath("/usr/lib/ld.so.1", "/usr/lib/ld.so.1", 1023) = 16 From dtucker at zip.com.au Wed Dec 29 04:39:26 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 28 Dec 2004 17:39:26 -0000 Subject: LinuxPAM and sshd: changing conversation function doesn't work but claims to. Message-ID: <40BE91BE.7000906@zip.com.au> Hi. I'm one of the OpenSSH developers, and I've done some of the work on sshd's PAM interface recently. I've discovered some behaviour peculiar to LinuxPAM that I can't explain: changing the conversation function does not appear to work, even though the pam_set_item() call claims to succeed. The previous conversation function is still called. Background: the PAM API is a poor fit for the SSH protocol, so the conversation function needs to do vastly different things at different points in the protocol. Instead of one enormous multi-mode function, sshd has what is probably a record number of different conversation functions (5, in the current development versions). One of these is a fairly generic "tty_conv" that interacts with the user directly on stdin/stdout and /dev/tty. Since the user doesn't get a pty until quite late in the login process, this function is only used for pam_chauthtok() in some cases, and always after sshd has forked to set up for the user's shell. The code for the chauthtok looks like this (from OpenSSH 3.8.1p1's do_pam_chauthtok() in auth-pam.c): static struct pam_conv tty_conv = { pam_tty_conv, NULL }; [...] sshpam_err = pam_set_item(sshpam_handle, PAM_CONV, (const void *)&tty_conv); if (sshpam_err != PAM_SUCCESS) 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); The conversation functions also have a debug() at the start announcing that they've been called and the number of messages passed. If I run the server[1] in debug mode with PAM enabled and privilege separation off, and connect with SSHv1 with an account that has an expired password, the code above will be called, and the debug messages will be sent to the client (since stdin/stdout is connected to the pty). Here's the output from the client: Password: Response: debug1: PAM: changing password debug3: PAM: sshpam_null_conv entering, 2 messages PAM: pam_chauthtok(): Authentication token manipulation error debug1: do_cleanup Connection to localhost closed. Despite pam_set_item claiming to succeed (it must have returned PAM_SUCCESS otherwise fatal() would have been called), tty_conv is *not* called by PAM, the previous conversation function is (which replies immediately with PAM_CONV_ERR and thus the pam_chauthtok fails). This is a Redhat 9 box with pam-0.75-48. Similar behaviour has also been observed on Debian. The same sshd code works OK on several other PAM platforms. I have not been able to replicate this behaviour in a minimal test case, but I'm hoping someone will be able to explain it. Thanks, -Daz. [1] To reproduce with OpenSSH 3.8.1p1 built with PAM enabled: # ./sshd -ddd -p 2022 -oUsePAM=yes -oUsePrivilegeSeparation=no # ssh -1 -p 2022 testuser at localhost -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. _______________________________________________ Pam-list mailing list Pam-list at redhat.com https://www.redhat.com/mailman/listinfo/pam-list From dtucker at zip.com.au Wed Dec 29 04:39:33 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 28 Dec 2004 17:39:33 -0000 Subject: LinuxPAM and sshd: changing conversation function doesn't work but claims to. In-Reply-To: <40BE91BE.7000906@zip.com.au> References: <40BE91BE.7000906@zip.com.au> Message-ID: <40BEBA6F.2090009@zip.com.au> Darren Tucker wrote: [about PAM calling the wrong conversation function] > I have not been able to replicate this behaviour in a minimal test > case, but I'm hoping someone will be able to explain it. OK, here's a smallish testcase that demonstrates the problem, run on Redhat 9 and Solaris 8. Note that on Redhat, the call to chauthtok (incorrectly) generates a second call to my_conv1, whereas on Solaris myconv2 is (correctly) called in the second case. Thanks, -Daz. $ uname -svr; rpm -q pam Linux 2.4.20-31.9 #1 Tue Apr 13 17:41:45 EDT 2004 pam-0.75-48 $ gcc wrong-conv-function.c -lpam $ sudo ./a.out [673]: pam_start result 0 (Success) [673]: my_conv1 called [673]: pam_acct_mgmt result 12 (Authentication token is no longer valid; new one required.) [674]: pam_set_item result 0 (Success) [674]: my_conv1 called [674]: pam_chauthtok result 20 (Authentication token manipulation error) For comparison, here is the same code run on Solaris 8: $ uname -svr SunOS 5.8 Generic_117350-02 $ sudo ./a.out [20837]: pam_start result 0 (Success) [20837]: pam_acct_mgmt result 9 (Authentication failed) [20838]: pam_set_item result 0 (Success) [20838]: my_conv2 called [20838]: pam_chauthtok result 6 (Conversation failure) -- 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. -------------- next part -------------- _______________________________________________ Pam-list mailing list Pam-list at redhat.com https://www.redhat.com/mailman/listinfo/pam-list