From hartmans at mit.edu Sun Feb 1 04:12:53 2004 From: hartmans at mit.edu (Sam Hartman) Date: Sat, 31 Jan 2004 12:12:53 -0500 Subject: Pending OpenSSH release: contains Kerberos/GSSAPI changes In-Reply-To: <20040130224824.GL18744@binky.central.sun.com> (Nicolas Williams's message of "Fri, 30 Jan 2004 16:48:25 -0600") References: <1448470000.1075499031@minbar.fac.cs.cmu.edu> <20040130224824.GL18744@binky.central.sun.com> Message-ID: <87ptd0m48a.fsf@luminous.mit.edu> I'd prefer client MAY mutual auth rather than client SHOULD NOT mutual auth. If the server does not implement gss-keyex then a sufficiently clever client can get some of the benefits of gss-keyex in some situations by requesting mutual. From nuffsaid at phreaker.net Sun Feb 1 08:43:18 2004 From: nuffsaid at phreaker.net (Nuff Said) Date: Sat, 31 Jan 2004 22:43:18 +0100 Subject: authorized_keys[2] Message-ID: <1075582821.2641.82.camel@enterprise.starfleet.hq> Hi! (I am not on this list; will not see any followups.) I had some problems using OpenSSH with RSA public/private key authentification until I realized, that the file in ~/.ssh on the remote machine must be called: authorized_keys2 The man-page (and my default /etc/ssh/sshd_config) says: authorized_keys (Moreover, OpenSSH seems to demand mode 700 for .ssh and mode 600 for authorized_keys2. Didn't read that in the man-page, either.) Is this a bug in the man-page? If so, could someone correct it, please? (There might be a lot of other users with exactly the same problem.) Systems: Fedora Core 1 & Red Hat 9; OpenSSH 3.6 (installed from the RPMs provided with the distribution, i.e. the packages: openssh, openssh-server, openssh-clients). Nuff From dean at av8.com Sun Feb 1 05:47:05 2004 From: dean at av8.com (Dean Anderson) Date: Sat, 31 Jan 2004 13:47:05 -0500 (EST) Subject: [OpenAFS-devel] Re: OpenSSH, OpenAFS, Heimdal Kerberos and MIT Kerberos In-Reply-To: <20040127204533.45130510.jfh@cise.ufl.edu> Message-ID: Putty 5.3 didn't work with the afs-supplied afs pam module. and 3.7.1p2... but maybe this can be fixed. Certainly, its a step. My point though, is that the openssh should use the system (pam) routines if it doesn't have any other method negotiated. Presently, it will only try to directly check the password file. --Dean On Tue, 27 Jan 2004, James F.Hranicky wrote: > On Tue, 27 Jan 2004 18:58:36 -0500 (EST) > Dean Anderson wrote: > > > Nope. OpenSSH 3.7.1p1 works for me with privsep turned off. When privsep > > is turned off, there is no subprocess. 3.7.1p1 has some additional > > breakage, in that if your ssh client doesn't support 'interactive/pam' as > > a method, then it won't send anything to pam. This means that only openssh > > clients work with pam on openssh servers. E.g., putty won't work. > > The latest version of putty (0.53b) does have keyboard int support, and I > have it working fine with PAM/krb5 . > > Jim > _______________________________________________ > OpenAFS-devel mailing list > OpenAFS-devel at openafs.org > https://lists.openafs.org/mailman/listinfo/openafs-devel > From smoogen at lanl.gov Sun Feb 1 15:24:40 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Sat, 31 Jan 2004 21:24:40 -0700 (MST) Subject: [OpenAFS-devel] Re: OpenSSH, OpenAFS, Heimdal Kerberos and MIT Kerberos In-Reply-To: References: Message-ID: While you may be from Missouri, you will either have to take their word for it.. or go off and test it yourself. Get the older versions of ssh onto a machine, and get one of the ssh-xploits from a hacker site. Turn on privsep... watch it segfault and exit. Turn off privsep.. get root. Sorry for feeding the trolls. On Tue, 27 Jan 2004, Dean Anderson wrote: >Really? Is there any links to what was avoided? I'd like to look at >these in detail before I concede that anything of values has been >demonstrated. I've heard these claims before, but I could not find any >substantiating details---the claims are dubious at best. > > --Dean > >On Tue, 27 Jan 2004, Damien Miller wrote: > >> Dean Anderson wrote: >> > Right. And there is an easy solution: Turn off Privsep. A process that >> > creates new user sessions needs root privileges, and those privileges >> > cannot be given away prematurely to "improve security". Privsep is just a >> > stupid idea for some programs. Probably for most programs... >> >> Privsep has avoided the last two real security problems found in >> portable OpenSSH, and others before that. The security gain has >> already been demonstrated. >> >> -d >> > >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From dtucker at zip.com.au Mon Feb 2 10:11:01 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 02 Feb 2004 10:11:01 +1100 Subject: [OpenAFS-devel] Re: OpenSSH, OpenAFS, Heimdal Kerberos and MIT Kerberos In-Reply-To: References: Message-ID: <401D8785.5030401@zip.com.au> (Reply-To set to openssh-unix-dev only) Dean Anderson wrote: > On Mon, 26 Jan 2004, Jeffrey Hutzelman wrote: >>Sadly, this doesn't make any difference. OpenSSH 3.7.1 and later run PAM >>session modules in a subprocess unrelated to the eventual user shell, That is not correct. Even with privsep, the session modules are run in the shell's immediate parent (as root). (This is trivial to test: add a debug call at the start of do_pam_session() to output its pid, then compare it with the ppid of the shell.) It is true that pam_authenticate() is called in a process that's not a direct ancestor of the shell, and because of that, sshd now (ie post-3.7.1p2) goes to some length to export the state set by that process. This is true with or without privsep. > Nope. OpenSSH 3.7.1p1 works for me with privsep turned off. When privsep > is turned off, there is no subprocess. There are other differences in behaviour which may be the cause of what you're seeing, eg pam_setcred will be called as non-root when privsep is off. See: http://bugzilla.mindrot.org/show_bug.cgi?id=789 > 3.7.1p1 has some additional > breakage, in that if your ssh client doesn't support 'interactive/pam' as > a method, then it won't send anything to pam. This means that only openssh > clients work with pam on openssh servers. E.g., putty won't work. That is not correct either. For SSHv2, PAM on 3.7p1 and up uses keyboard-interactive (which is an internet-draft, the same as the rest of SSHv2, see [1]) which is supported by most clients, including PuTTY. For SSHv1, PAM uses TIS challenge-response authentication, which is also supported by PuTTY, but is disabled by default. To enable it, click the little checkbox at Connection -> SSH -> Auth -> Attempt TIS or Cryptocard authentication (SSH1). If, however, you do not disable PasswordAuthentication as per the UsePAM man page entry then it's possible to authenticate without going through PAM. To fix this, set "PasswordAuthentication no" in sshd_config like the man page says. [1] http://www.ietf.org/internet-drafts/draft-ietf-secsh-auth-kbdinteract-05.txt -- 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 dean at av8.com Tue Feb 3 07:16:59 2004 From: dean at av8.com (Dean Anderson) Date: Mon, 2 Feb 2004 15:16:59 -0500 (EST) Subject: [OpenAFS-devel] Re: OpenSSH, OpenAFS, Heimdal Kerberos and MIT Kerberos In-Reply-To: Message-ID: On Sat, 31 Jan 2004, Stephen Smoogen wrote: > > While you may be from Missouri, you will either have to take their word > for it.. or go off and test it yourself. Get the older versions of ssh > onto a machine, and get one of the ssh-xploits from a hacker site. Turn > on privsep... watch it segfault and exit. Turn off privsep.. get root. This doesn't mean the privsep prevented an exploit. If it segfaulted, a little more fuzzing can get shell code to run. After that, you have at least non-root access, and you have sockets to the privsep processes that have root privilege. We know how to escalate non-root processes to root. So, the privsep didn't protect anything. --Dean > > Sorry for feeding the trolls. > > On Tue, 27 Jan 2004, Dean Anderson wrote: > > >Really? Is there any links to what was avoided? I'd like to look at > >these in detail before I concede that anything of values has been > >demonstrated. I've heard these claims before, but I could not find any > >substantiating details---the claims are dubious at best. > > > > --Dean > > > >On Tue, 27 Jan 2004, Damien Miller wrote: > > > >> Dean Anderson wrote: > >> > Right. And there is an easy solution: Turn off Privsep. A process that > >> > creates new user sessions needs root privileges, and those privileges > >> > cannot be given away prematurely to "improve security". Privsep is just a > >> > stupid idea for some programs. Probably for most programs... > >> > >> Privsep has avoided the last two real security problems found in > >> portable OpenSSH, and others before that. The security gain has > >> already been demonstrated. > >> > >> -d > >> > > > >_______________________________________________ > >openssh-unix-dev mailing list > >openssh-unix-dev at mindrot.org > >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > From dean at av8.com Tue Feb 3 07:16:59 2004 From: dean at av8.com (Dean Anderson) Date: Mon, 2 Feb 2004 15:16:59 -0500 (EST) Subject: [OpenAFS-devel] Re: OpenSSH, OpenAFS, Heimdal Kerberos and MIT Kerberos In-Reply-To: Message-ID: On Sat, 31 Jan 2004, Stephen Smoogen wrote: > > While you may be from Missouri, you will either have to take their word > for it.. or go off and test it yourself. Get the older versions of ssh > onto a machine, and get one of the ssh-xploits from a hacker site. Turn > on privsep... watch it segfault and exit. Turn off privsep.. get root. This doesn't mean the privsep prevented an exploit. If it segfaulted, a little more fuzzing can get shell code to run. After that, you have at least non-root access, and you have sockets to the privsep processes that have root privilege. We know how to escalate non-root processes to root. So, the privsep didn't protect anything. --Dean > > Sorry for feeding the trolls. > > On Tue, 27 Jan 2004, Dean Anderson wrote: > > >Really? Is there any links to what was avoided? I'd like to look at > >these in detail before I concede that anything of values has been > >demonstrated. I've heard these claims before, but I could not find any > >substantiating details---the claims are dubious at best. > > > > --Dean > > > >On Tue, 27 Jan 2004, Damien Miller wrote: > > > >> Dean Anderson wrote: > >> > Right. And there is an easy solution: Turn off Privsep. A process that > >> > creates new user sessions needs root privileges, and those privileges > >> > cannot be given away prematurely to "improve security". Privsep is just a > >> > stupid idea for some programs. Probably for most programs... > >> > >> Privsep has avoided the last two real security problems found in > >> portable OpenSSH, and others before that. The security gain has > >> already been demonstrated. > >> > >> -d > >> > > > >_______________________________________________ > >openssh-unix-dev mailing list > >openssh-unix-dev at mindrot.org > >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > From djm at mindrot.org Tue Feb 3 08:07:54 2004 From: djm at mindrot.org (Damien Miller) Date: Tue, 3 Feb 2004 08:07:54 +1100 (EST) Subject: [OpenAFS-devel] Re: OpenSSH, OpenAFS, Heimdal Kerberos and MIT Kerberos In-Reply-To: References: Message-ID: On Mon, 2 Feb 2004, Dean Anderson wrote: > This doesn't mean the privsep prevented an exploit. If it segfaulted, a > little more fuzzing can get shell code to run. After that, you have at > least non-root access, and you have sockets to the privsep processes that > have root privilege. > > We know how to escalate non-root processes to root. > > So, the privsep didn't protect anything. Get real. My deadbolt door locks don't stop thieves who smash windows, by your logic they "don't protect anything" either. There is a world of difference between a break in a process running with root privileges and a break in an unprivileged, chrooted process. It seems that this value is self-evident to everyone but you. Anyway, you are more than welcome to make your forked version which removes security features, but please stop trolling on our lists. -d From dean at av8.com Tue Feb 3 11:53:45 2004 From: dean at av8.com (Dean Anderson) Date: Mon, 2 Feb 2004 19:53:45 -0500 (EST) Subject: [OpenAFS-devel] Re: OpenSSH, OpenAFS, Heimdal Kerberos and MIT Kerberos In-Reply-To: Message-ID: On Tue, 3 Feb 2004, Damien Miller wrote: > On Mon, 2 Feb 2004, Dean Anderson wrote: > > > This doesn't mean the privsep prevented an exploit. If it segfaulted, a > > little more fuzzing can get shell code to run. After that, you have at > > least non-root access, and you have sockets to the privsep processes that > > have root privilege. > > > > We know how to escalate non-root processes to root. > > > > So, the privsep didn't protect anything. > > Get real. > > My deadbolt door locks don't stop thieves who smash windows, by your > logic they "don't protect anything" either. That wasn't my logic, but it makes no sense to put a deadbolt lock in a glass door. Nor will adding a second glass door improve your security. Basically, privsep is a second glass door. You have to exploit the non-privileged part, and then you have a choice to either exploit the privileged part, or use another method to escalate to root. No security improvement, just a gratuitous change that will break old exploit code that assumed it had root right away. > There is a world of difference between a break in a process running with > root privileges and a break in an unprivileged, chrooted process. It seems > that this value is self-evident to everyone but you. First, this is a loose, general principle. Sure, it is a good idea to remove privileges when a process doesn't need root privileges. But, the process that creates new user connections does need root privileges. It is a fundamental rule that you can't remove privileges that are necessary. You seem to have seized on the idea of privilege removal and have taken it to the extreme, mistakenly believing that you could obtain more security somehow. Second, there isn't much difference between a non-root breakin and a root breakin. You have to react the same way to both: You don't know if they didn't get root, or they did and you simply haven't found evidence of a root breakin. Perhaps they were very good about cleaning up their root activity, but lazy with their non-root crack. Privsep hasn't changed anything, but it added more (exploitable) complication. Not to mention that it broke a great many things. If the non-privileged openssh process is exploitable, then probably so are the "privsep" parts, since the lower privilege part still has sockets to the root parts. You haven't changed anything, even if there weren't easy ways to escalate to root. If you can't write code that isn't subject to stack overflow, etc, then your privsep scheme isn't going to fix that. Basically, you just broke a bunch of stuff, and called it a security enhancement. Getting old rootkit exploits to fail doesn't indicate improved security. You can do that in a number of other ways, which also don't change the security of the program, and could in fact reduce the security. For example, offering an immediate root shell to any connection will also cause the exploit code to fail, but doesn't improve security. > Anyway, you are more than welcome to make your forked version which > removes security features, but please stop trolling on our lists. Anyway, I didn't join your list. This discussion is from another list (openafs-devel), where we were discussing openssh brokenness with respect to obtaining afs credentials. Someone (not me) added the openssh list to the distribution. I didn't expect to convince you of the wrongness of your ways, either--I've looked at the code enough to know there couldn't be any cooperation. Its not just privsep. This is why we need a forked version. Sorry. --Dean From johnpell at mac.com Tue Feb 3 13:11:37 2004 From: johnpell at mac.com (John Davidorff Pell) Date: Mon, 2 Feb 2004 18:11:37 -0800 Subject: [OpenAFS-devel] OpenSSH, OpenAFS, Heimdal Kerberos and MIT Kerberos In-Reply-To: References: Message-ID: <4C665369-55EE-11D8-86E2-0003934F6406@mac.com> On 2 Feb 2004, at 16:53, Dean Anderson wrote: > This is why we need a forked version. Sorry. Its generally not a good idea to fork, unless absolutely necessary. If privsep does not reduce security (significantly, and I know that its debatable what "significantly" means), then ignore the people who think its great, and work on actually fixing the problems/exploits. If it is in itself a dramatic security risk, then demonstrate that and even those who like privsep will be able to understand (or be kicked off the project, I hope) and you've fixed the real project, not just a fork. Also, if one does not know how to fix a given exploit, and privsep makes that exploit more difficult, then it gives us time to figure it out and repair it before a real root exploit is achieved, whereas without privsep our response must be much quicker, which it often is not. Personally, I'm not a big fan of privsep, but "two glass doors" make more noise when broken, than just one, so I cna understand why many people like it. JP -- "The New York Times is read by the people who run the country. The Washington Post is read by the people who think they run the country. The National Enquirer is read by the people who think Elvis is alive and running the country ..." -- Robert J Woodhead From mouring at etoh.eviladmin.org Tue Feb 3 14:22:15 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 2 Feb 2004 21:22:15 -0600 (CST) Subject: [OpenAFS-devel] Re: OpenSSH, OpenAFS, Heimdal Kerberos and MIT Kerberos In-Reply-To: Message-ID: On Mon, 2 Feb 2004, Dean Anderson wrote: > On Tue, 3 Feb 2004, Damien Miller wrote: > > > On Mon, 2 Feb 2004, Dean Anderson wrote: > > > > > This doesn't mean the privsep prevented an exploit. If it segfaulted, a > > > little more fuzzing can get shell code to run. After that, you have at > > > least non-root access, and you have sockets to the privsep processes that > > > have root privilege. > > > > > > We know how to escalate non-root processes to root. > > > > > > So, the privsep didn't protect anything. > > > > Get real. > > > > My deadbolt door locks don't stop thieves who smash windows, by your > > logic they "don't protect anything" either. > > That wasn't my logic, but it makes no sense to put a deadbolt lock in a > glass door. Nor will adding a second glass door improve your security. > > Basically, privsep is a second glass door. You have to exploit the > non-privileged part, and then you have a choice to either exploit the > privileged part, or use another method to escalate to root. No security > improvement, just a gratuitous change that will break old exploit code > that assumed it had root right away. > Are we basing this on facts or just handwaving? I've seen better arguments against Privsep from the local cracking community which has shown proof that a kernel flaw can still be used in the unprived child. Best you've done is make an offhanded comment with nothing to back it up. Which shows me the cracking community have a better clue on this topic than you do. > > There is a world of difference between a break in a process running with > > root privileges and a break in an unprivileged, chrooted process. It seems > > that this value is self-evident to everyone but you. > > First, this is a loose, general principle. Sure, it is a good idea to > remove privileges when a process doesn't need root privileges. But, the > process that creates new user connections does need root privileges. It is > a fundamental rule that you can't remove privileges that are necessary. > You seem to have seized on the idea of privilege removal and have taken it > to the extreme, mistakenly believing that you could obtain more security > somehow. > Proof? Or handwaving? I assume you also find "trusted computing" and advanced ACLs to be the same "mistaken security belief". They use the same concept. Break the problem down into smaller security modules and firewall each module from each other in order to ensure a breach in one slows down the attacker. Do note.. "SLOW DOWN". Nothing we do besides fill a PC full of cement and put it at the bottom of the deepest part of the ocean will secure a machine. > Second, there isn't much difference between a non-root breakin and a root > breakin. You have to react the same way to both: You don't know if they > didn't get root, or they did and you simply haven't found evidence of a > root breakin. Perhaps they were very good about cleaning up their root > activity, but lazy with their non-root crack. > There is one difference, and from the owner's view point it is very serious difference. A non-root breakin limits the attack and local deployment of snooping. Where you may dismiss this, some of us don't. The slow down of the attacker gives the defender a little larger window to shut down and resecure the network in question. Privsep takes one gaping hole and forces the attacker to find a second or third hole (via kernel services or through the firewall separating prived from unprived code). > Privsep hasn't changed anything, but it added more (exploitable) > complication. Not to mention that it broke a great many things. If the > non-privileged openssh process is exploitable, then probably so are the > "privsep" parts, since the lower privilege part still has sockets to the > root parts. You haven't changed anything, even if there weren't easy ways Which can only be accessed (if even exposed) through a limited view unless you can expliot the underlying communications protocol. So it actually does change a lot. If you have constructive comments on improving that underlying protocol I'm sure we are all ears. [..] > > Anyway, you are more than welcome to make your forked version which > > removes security features, but please stop trolling on our lists. > > Anyway, I didn't join your list. This discussion is from another list > (openafs-devel), where we were discussing openssh brokenness with respect > to obtaining afs credentials. Someone (not me) added the openssh list to > the distribution. I didn't expect to convince you of the wrongness of > your ways, either--I've looked at the code enough to know there couldn't > be any cooperation. Its not just privsep. This is why we need a forked > version. Sorry. > Your lack of anything but handwaving has shown me that you have prejudged Privsep and have never bothered to understand it. I'm really sorry if you have done that. I had misgivings about privsep also and it took actually writing code and understanding how that puzzle piece fits before I felt the added complexity was justified. OpenSSH project has always been open to different views, and some nice additions had come because of it. However, we don't add features just to keep up with the Jones. Which is what a lot of people think we should. - Ben From xdavid at lib-eth.natur.cuni.cz Tue Feb 3 21:04:55 2004 From: xdavid at lib-eth.natur.cuni.cz (David Komanek) Date: Tue, 03 Feb 2004 11:04:55 +0100 Subject: ADDENDUM: Portable OpenSSH and GSSAPI In-Reply-To: References: Message-ID: <401F7247.5030403@lib-eth.natur.cuni.cz> Yes, Kerberos itself is working fine - I can get tickets etc. But I have no other app using gss api - only openssh. David >On Mon, 26 Jan 2004, David Komanek wrote: > > > >>to my previous post I have some additional info. I just erased all the >>krb5 data and set it up from scratch. Now the message in sshd debug >>changed to: >> >> > >Have you verified that Kerberos itself is working? Do other Kerberized >applications work correctly? > >Cheers, > >Simon. > > >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > From umar at drizzle.com Wed Feb 4 05:58:36 2004 From: umar at drizzle.com (Umar Cheema) Date: Tue, 3 Feb 2004 10:58:36 -0800 (PST) Subject: scp interactive Message-ID: I was just curious how come there is no interactive option available for scp? A -i option is available for cp and rm, etc which prompts you before overwriting existing files. Was there a special reason why a similar option was not made available for scp? Thanks, Umar From mouring at etoh.eviladmin.org Wed Feb 4 06:12:00 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Tue, 3 Feb 2004 13:12:00 -0600 (CST) Subject: scp interactive In-Reply-To: Message-ID: Because it was never implemented as part of rcp which is what scp is designed to mimic. since scp is around for legacy conversion I doubt it will be added either. - Ben On Tue, 3 Feb 2004, Umar Cheema wrote: > I was just curious how come there is no interactive option available for > scp? A -i option is available for cp and rm, etc which prompts you before > overwriting existing files. Was there a special reason why a similar > option was not made available for scp? > > Thanks, > Umar > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From wendyp at cray.com Wed Feb 4 06:12:08 2004 From: wendyp at cray.com (Wendy Palm) Date: Tue, 03 Feb 2004 13:12:08 -0600 Subject: scp interactive In-Reply-To: References: Message-ID: <401FF288.5040204@cray.com> because there's no such option in rcp (which scp models). Umar Cheema wrote: > I was just curious how come there is no interactive option available for > scp? A -i option is available for cp and rm, etc which prompts you before > overwriting existing files. Was there a special reason why a similar > option was not made available for scp? > > Thanks, > Umar > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev -- wendy palm Software Engineer Open Software Development, Cray Inc. wendyp at cray.com, 651-605-9154 From vanessa at oss.com Thu Feb 5 09:13:31 2004 From: vanessa at oss.com (Vanessa Vaz) Date: Wed, 4 Feb 2004 17:13:31 -0500 Subject: password expiration warning messages Message-ID: <018701c3eb6c$258033a0$9301a8c0@ZODIAC> Hi, I'm using openssh on Solaris. I noticed that the password expitation warning messages are no longer displayed in the login banner. Any idea how to correct this? Thanks, Vanessa Vaz OSS Nokalva, Inc. www.oss.com Tel: 732-302-9669 ext. 112 Fax: 732-302-0023 From lucas at cray.com Thu Feb 5 11:21:27 2004 From: lucas at cray.com (Lucas Standaert) Date: Wed, 4 Feb 2004 16:21:27 -0800 (PST) Subject: anyone else have a that DOESN'T #include ? Message-ID: I'm porting openssh 3.7.1p2 to a very BSD 4.4-ish system. My first hint of a problem was that configure said it couldn't find and that the sizes of char, int, etc were 0 (zero). It turned out that "confdefs.h" had HAVE_SYS_STAT_H defined, but not HAVE_SYS_TYPES_H, resulting in code such as the following to fail to compile on a system where sys/stat.h does NOT include sys/types.h: ac_includes_default="\ #include #if HAVE_SYS_TYPES_H # include #endif #if HAVE_SYS_STAT_H # include #endif ... I can't figure out where HAVE_SYS_STAT_H gets added to confdefs.h by configure, so I worked around the problem by adding this flag to the configure invocation: --with-cflags="-DHAVE_SYS_TYPES_H=1" I see that NetBSD added #include to sys/stat.h somewhere between releases 1.3 and 1.4. Anyone else out there using headers old enough to hit this problem? Thanks, Lucas From dtucker at zip.com.au Thu Feb 5 16:18:09 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 05 Feb 2004 16:18:09 +1100 Subject: anyone else have a that DOESN'T #include ? In-Reply-To: References: Message-ID: <4021D211.7080609@zip.com.au> Lucas Standaert wrote: > I'm porting openssh 3.7.1p2 to a very BSD 4.4-ish system. My first > hint of a problem was that configure said it couldn't find > and that the sizes of char, int, etc were 0 (zero). It turned > out that "confdefs.h" Do you mean config.h not confdefs.h? > had HAVE_SYS_STAT_H defined, but not HAVE_SYS_TYPES_H, > resulting in code such as the following to fail to compile on > a system where sys/stat.h does NOT include sys/types.h: > > ac_includes_default="\ > #include > #if HAVE_SYS_TYPES_H > # include > #endif > #if HAVE_SYS_STAT_H > # include > #endif You might also try regenerating configure with autoconf. Different versions of autoconf behave slightly differently on different platforms. OpenSSH currently uses 2.52 with a couple of mods (which is somewhat old, but it works properly on most of the platforms we know about). > I can't figure out where HAVE_SYS_STAT_H gets added to confdefs.h > by configure, so I worked around the problem by adding this > flag to the configure invocation: It's added by the part of configure generated by this fragment of configure.ac: # Checks for header files. AC_CHECK_HEADERS([...] sys/stat.h [...]) -- 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 Feb 5 18:17:51 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 05 Feb 2004 18:17:51 +1100 Subject: password expiration warning messages In-Reply-To: <018701c3eb6c$258033a0$9301a8c0@ZODIAC> References: <018701c3eb6c$258033a0$9301a8c0@ZODIAC> Message-ID: <4021EE1F.8050803@zip.com.au> Vanessa Vaz wrote: > I'm using openssh on Solaris. I noticed that the password expitation > warning messages are no longer displayed in the login banner. Any idea how > to correct this? Assuming you're using PAM, this should be fixed in the next release (there have been several fixes relating to messages from PAM modules). You can confirm this by trying a snapshot: ftp://ftp.ca.openbsd.org/pub/OpenBSD/OpenSSH/portable/snapshot/ Alternatively, there is a series of patches that add expiry handling (warnings and forced changes) to 3.7.1p2 here: http://www.zip.com.au/~dtucker/openssh/ -- 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 2le at 2le.net Thu Feb 5 23:58:38 2004 From: 2le at 2le.net (=?ISO-8859-1?Q?S=E9bastien_HEITZMANN?=) Date: Thu, 05 Feb 2004 13:58:38 +0100 Subject: connection sometime hand on start. Message-ID: <40223DFE.1000805@2le.net> Hi, I'm using a cygwin openssh 3.7.1p2, SSH protocols 1.5/2.0, OpenSSL 0.9.7c 30 Sep 2003 to connect to a sshd server : sshd version OpenSSH_3.4p1 Debian 1:3.4p1-1.woody.3 Sometime the connection hang. I've written a little batch script : set USER=u12 echo "start" > log.txt :begin time /T time /T >>log.txt c:\kiwi\bin\ssh.exe -F ssh_config -i .\keys\id_rsa %USER%@green.kiwi-backup.com ls /mnt/data1/%USER%/snapshot goto begin It work fine but sometime, the ssh ls hang for exactelly 2 hour. I think that it's the tcp timeout of the socket. I use this sort of connection in some automatic scripts and it's really annoyoing. Any idea ? S?bastien HEITZMANN From dtucker at zip.com.au Fri Feb 6 17:20:13 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 06 Feb 2004 17:20:13 +1100 Subject: Tru64 SIA authentication: can it be called after kerberos? Message-ID: <4023321D.70601@zip.com.au> Hi All. There have recently (well, today :-) been changes to OpenSSH Portable's auth-passwd.c from OpenBSD to accomodate forced changes of expired passwords. (Rabid password expirers shoulon't get excited yet, it's currently bsdauth only, but support for other platforms should start trickling in shortly). As part of that, some individual platforms have gained their own sys_auth_passwd functions. One that hasn't yet is SIA, because it would mean changing its behaviour to be called *after* Kerberos. Could someone confirm that this change (the patch attached) will work with SIA, or explain why it can't be called after Kerberos? (The patch will apply to snapshot 20040206 or later.) The next step is to banish the sys_auth_passwd functions to their respective platform files, which should clean things up somewhat. -- 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-sia-move.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040206/bd3839d2/attachment.ksh From cmadams at hiwaay.net Sat Feb 7 02:08:31 2004 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 6 Feb 2004 09:08:31 -0600 Subject: Tru64 SIA authentication: can it be called after kerberos? In-Reply-To: <4023321D.70601@zip.com.au> References: <4023321D.70601@zip.com.au> Message-ID: <20040206150830.GB1202506@hiwaay.net> Once upon a time, Darren Tucker said: > As part of that, some individual platforms have gained their own > sys_auth_passwd functions. One that hasn't yet is SIA, because it would > mean changing its behaviour to be called *after* Kerberos. > > Could someone confirm that this change (the patch attached) will > work with SIA, or explain why it can't be called after Kerberos? (The > patch will apply to snapshot 20040206 or later.) I'll give this a look this weekend (today is going to be way too busy). However, I'm guessing it won't make any difference in my testing, because I don't have a Kerberos setup. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From guyverdh at mchsi.com Sat Feb 7 03:08:48 2004 From: guyverdh at mchsi.com (guyverdh at mchsi.com) Date: Fri, 06 Feb 2004 16:08:48 +0000 Subject: OpenSSH -> PAM -> Password Prompt Message-ID: <20040206160844.07EC627C188@shitei.mindrot.org> I have been looking forward to the full PAM integration into OpenSSH for some time. I have been downloading many of the SNAP shots and testing them out on Solaris 5.8 and Solaris 5.9, and have been impressed with the improvements of late. One thing that I have noticed, however, is that when utilizing PAM -> UsePAM=Yes, that the password prompt reads Password: Now, I realize that this is more a PAM functionality, than anything to do with OpenSSH, however, I was curious to know whether or not something could be done to make PAM's password prompt read more like the known and liked OpenSSH password prompt User at System's Password: I'm probably just doing a bit of wishfull thinking, however, it never hurts to ask, does it? Thanks, Larry From djm at mindrot.org Sat Feb 7 08:24:35 2004 From: djm at mindrot.org (Damien Miller) Date: Sat, 7 Feb 2004 08:24:35 +1100 (EST) Subject: OpenSSH -> PAM -> Password Prompt In-Reply-To: <20040206160844.07EC627C188@shitei.mindrot.org> References: <20040206160844.07EC627C188@shitei.mindrot.org> Message-ID: On Fri, 6 Feb 2004 guyverdh at mchsi.com wrote: > Now, I realize that this is more a PAM functionality, than anything to do with > OpenSSH, however, I was curious to know whether or not something could be done > to make PAM's password prompt read more like the known and liked OpenSSH > password prompt > > User at System's Password: Not really, for sshd to change this would mean hiding the prompt as supplied by PAM, which could contain useful information. E.g. when using one time passwords or tokens. Your best bet would be to pester the PAM module author to add a flag to the PAM module to get it produce these prompts. -d From carson at taltos.org Sat Feb 7 08:34:04 2004 From: carson at taltos.org (Carson Gaspar) Date: Fri, 06 Feb 2004 16:34:04 -0500 Subject: OpenSSH -> PAM -> Password Prompt In-Reply-To: References: <20040206160844.07EC627C188@shitei.mindrot.org> Message-ID: <469240000.1076103244@taltos.ny.ficc.gs.com> --On Saturday, February 07, 2004 08:24:35 +1100 Damien Miller wrote: > Not really, for sshd to change this would mean hiding the prompt as > supplied by PAM, which could contain useful information. E.g. when using > one time passwords or tokens. OpenSSH could prefix all prompts with "user at host: " (not that I'm really advocating this, but it's an option). -- Carson From dtucker at zip.com.au Sat Feb 7 08:34:44 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 07 Feb 2004 08:34:44 +1100 Subject: OpenSSH -> PAM -> Password Prompt In-Reply-To: <20040206160844.07EC627C188@shitei.mindrot.org> References: <20040206160844.07EC627C188@shitei.mindrot.org> Message-ID: <40240874.8080501@zip.com.au> guyverdh at mchsi.com wrote: > I have been looking forward to the full PAM integration into OpenSSH for some > time. I have been downloading many of the SNAP shots and testing them out on > Solaris 5.8 and Solaris 5.9, and have been impressed with the improvements of late. I'm glad that things are improving for you. > One thing that I have noticed, however, is that when utilizing PAM -> > UsePAM=Yes, that the password prompt reads > > Password: That prompt is generated by PAM, sshd just sends it for display. If the prompt isn't how you like it then you need to arrange for PAM to send a different one. > Now, I realize that this is more a PAM functionality, than anything to do with > OpenSSH, however, I was curious to know whether or not something could be done > to make PAM's password prompt read more like the known and liked OpenSSH > password prompt > > User at System's Password: Nope, sorry. sshd isn't going to arbitarily change the prompts provided by PAM. You're welcome to patch your own sshd if you want it badly enough, though. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From mouring at etoh.eviladmin.org Sat Feb 7 09:57:38 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 6 Feb 2004 16:57:38 -0600 (CST) Subject: OpenSSH -> PAM -> Password Prompt In-Reply-To: <469240000.1076103244@taltos.ny.ficc.gs.com> Message-ID: On Fri, 6 Feb 2004, Carson Gaspar wrote: > --On Saturday, February 07, 2004 08:24:35 +1100 Damien Miller > wrote: > > > Not really, for sshd to change this would mean hiding the prompt as > > supplied by PAM, which could contain useful information. E.g. when using > > one time passwords or tokens. > > OpenSSH could prefix all prompts with "user at host: " (not that I'm really > advocating this, but it's an option). > I'd rather see see the change done at the PAM code level. I'm not thrilled about the idea of randomly appending/prefixing PAM chatter with stuff. - Ben From cr212 at ylenurme.ee Sat Feb 7 12:18:35 2004 From: cr212 at ylenurme.ee (cr212 at ylenurme.ee) Date: Sat, 07 Feb 2004 01:18:35 +0000 Subject: HYIP Investment vAXvt In-Reply-To: References: Message-ID: Dear member , We would like to introduce you our new project HYIPWEB.com It's a new HYIP rating site. Its rating based on how much return we received from each investment program, how long program is online, minimum investment amount . We have invested 200$-500$ in many Investment programs and give you oportunity to see how much return we got back from our investment in every investment program. Please visit HYIPWEB.com If you are admin of investment program you can e-mail us your program and we will consider to invest in it and put it in our rating. You don't have to pay anything. Best Regards, HYIPWEB Team HYIPWEB.com From phil at ipom.com Sat Feb 7 17:05:27 2004 From: phil at ipom.com (Phil Dibowitz) Date: Fri, 06 Feb 2004 22:05:27 -0800 Subject: TGT Passing in 3.7 Message-ID: <40248027.4060606@ipom.com> I noticed that it appears KerbV tgt passing seems to have disappeared in the 3.7 release. Was this dropped, or is it planned to come back? Was there a reason it disappeared? I looked through the archives but couldn't find much. Thanks, -- Phil Dibowitz phil at ipom.com Freeware and Technical Pages Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin, 1759 From postmaster at btconnect.com Sat Feb 7 21:29:32 2004 From: postmaster at btconnect.com (postmaster at btconnect.com) Date: Sat, 7 Feb 2004 10:29:32 +0000 Subject: Delivery Report (failure) for polymer@taiwan.com Message-ID: <"dswu26.btc:045791:20040207102924"@btconnect.com> A non-text attachment was scrubbed... Name: not available Type: text/rfc822-headers Size: 887 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040207/d3f6dd14/attachment.bin From andreas at schuldei.org Tue Feb 10 00:21:17 2004 From: andreas at schuldei.org (Andreas Schuldei) Date: Mon, 9 Feb 2004 14:21:17 +0100 Subject: miss-parsing id_rsa file Message-ID: <20040209132117.GA31558@lukas.schuldei.com> i get this error when connecting to hosts, using key exchange authentification: andreas at lukas:~$ ssh -2 -vvv andi at www.schuldei.org OpenSSH_3.6.1p2 Debian 1:3.6.1p2-11, SSH protocols 1.5/2.0, OpenSSL 0x0090703f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Rhosts Authentication disabled, originating port will not be trusted. debug2: ssh_connect: needpriv 0 debug1: Connecting to www.schuldei.org [195.37.106.41] port 22. debug1: Connection established. debug3: Not a RSA1 key file /home/andreas/.ssh/id_rsa. 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 /home/andreas/.ssh/id_rsa type 1 debug1: identity file /home/andreas/.ssh/id_dsa type -1 ssh_exchange_identification: Connection closed by remote host debug1: Calling cleanup 0x80623b0(0x0) andreas at lukas:~$ ls -al .ssh/id_rsa* -rw------- 1 andreas andreas 951 Aug 2 2003 .ssh/id_rsa -rw-r--r-- 1 andreas andreas 223 Aug 2 2003 .ssh/id_rsa.pub andreas at lukas:~$ head -n3 .ssh/id_rsa -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,483908A29B0FB1E5 first i believed in a subtily broken binary but i got the same error when deinstalling, purging and reinstalling a newly downloaded package. i have not found a similar error with google. please advice. From phil at ipom.com Tue Feb 10 08:51:13 2004 From: phil at ipom.com (Phil Dibowitz) Date: Mon, 9 Feb 2004 13:51:13 -0800 Subject: Some GSSAPI/Kerberos Questions Message-ID: <20040209215113.GB1306@ipom.com> After reading some more from the archives, a private email, and some general research, I see that KerbV support has been dropped in favor of GSSAPI. Which is fine, and wonderful, I support GSSAPI. But, erm, the announcement says, "This release contains some GSSAPI user authentication support to replace legacy KerberosV authentication support. At present this code is still considered experimental and SHOULD NOT BE USED." Confidence inspiring! =) At USC, we are currently using (patched) 3.6.1p2 which has TGT passing support in kerb1, which is kinda nice - but doesn't seem to work right with kerberos password authentication via pam. 3.7.1p2 seems to support the latter, but drops the former. For those who have used the GSSAPI stuf in 3.7.1 - have you found it stable? When is this code supposed to be considered stable? I don't seem to see a way to use/try this code at all. I don't see any docs on it anywhere... am I being blind? Thanks, -- Phil Dibowitz phil at ipom.com Freeware and Technical Pages Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin, 1759 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040209/191b42ef/attachment.bin From sxw at inf.ed.ac.uk Tue Feb 10 10:24:44 2004 From: sxw at inf.ed.ac.uk (sxw at inf.ed.ac.uk) Date: Mon, 9 Feb 2004 23:24:44 +0000 (GMT) Subject: Some GSSAPI/Kerberos Questions In-Reply-To: <20040209215113.GB1306@ipom.com> Message-ID: On Mon, 9 Feb 2004, Phil Dibowitz wrote: > But, erm, the announcement says, "This release contains some GSSAPI > user authentication support to replace legacy KerberosV authentication > support. At present this code is still considered experimental and > SHOULD NOT BE USED." The code drop of GSSAPI support into OpenSSH coincided with major revisions to the Internet-Draft on which it was based. These revisions were to address concerns about the lack of linking between the GSSAPI context and OpenSSH's session identifiers. These concerns applied equally to the Kerberos V code which was in early versions of OpenSSH. The GSSAPI code in 3.7.1 is based on the pre-revision protocol. CVS has an implementation of the newest I-D, which overcomes these issues. It should be noted that implementations based on the earlier I-Ds are _not_ compatible with those using the newest ones. If you can wait, wait for the 3.7.2 codebase. > For those who have used the GSSAPI stuf in 3.7.1 - have you found it > stable? I've been distributing patches implementing GSSAPI support for several years now, and they're fairly widely deployed. Unfortunately I don't believe they can be considered 'stable' until the I-D upon which they're based makes it through to an RFC. If you want to try out the code in 3.7.1 (and I'd really recommend waiting for 3.7.2 for production use), you need to turn on 'GSSAPIAuthentication' in both the client and the server. Cheers, Simon. From djm at mindrot.org Tue Feb 10 12:31:13 2004 From: djm at mindrot.org (Damien Miller) Date: Tue, 10 Feb 2004 12:31:13 +1100 Subject: Some GSSAPI/Kerberos Questions In-Reply-To: References: Message-ID: <40283461.5010009@mindrot.org> sxw at inf.ed.ac.uk wrote: > It should be noted that implementations based on the earlier I-Ds are > _not_ compatible with those using the newest ones. If you can wait, wait > for the 3.7.2 codebase. FYI It will probably be called 3.8 rather then 3.7.2. -d From phil at ipom.com Wed Feb 11 04:48:46 2004 From: phil at ipom.com (Phil Dibowitz) Date: Tue, 10 Feb 2004 09:48:46 -0800 Subject: Some GSSAPI/Kerberos Questions In-Reply-To: <40283461.5010009@mindrot.org> References: <40283461.5010009@mindrot.org> Message-ID: <4029197E.1040207@ipom.com> Damien Miller wrote: > > FYI It will probably be called 3.8 rather then 3.7.2. This might be a bad question to ask... but is there an _approximate_ ETA on 3.7.2/3.8 ? -- Phil Dibowitz phil at ipom.com Freeware and Technical Pages Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin, 1759 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 256 bytes Desc: OpenPGP digital signature Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040210/d6d54c9b/attachment.bin From djm at mindrot.org Wed Feb 11 10:38:08 2004 From: djm at mindrot.org (Damien Miller) Date: Wed, 11 Feb 2004 10:38:08 +1100 Subject: Some GSSAPI/Kerberos Questions In-Reply-To: <4029197E.1040207@ipom.com> References: <40283461.5010009@mindrot.org> <4029197E.1040207@ipom.com> Message-ID: <40296B60.30306@mindrot.org> Phil Dibowitz wrote: > Damien Miller wrote: > >>FYI It will probably be called 3.8 rather then 3.7.2. > > > This might be a bad question to ask... but is there an _approximate_ ETA > on 3.7.2/3.8 ? Very soon - by the end of the month, if not sooner. Please grab a snapshot and test - they are very stable. -d From phil at ipom.com Wed Feb 11 10:52:29 2004 From: phil at ipom.com (Phil Dibowitz) Date: Tue, 10 Feb 2004 15:52:29 -0800 Subject: Some GSSAPI/Kerberos Questions In-Reply-To: <40296B60.30306@mindrot.org> References: <40283461.5010009@mindrot.org> <4029197E.1040207@ipom.com> <40296B60.30306@mindrot.org> Message-ID: <20040210235229.GB6194@ipom.com> On Wed, Feb 11, 2004 at 10:38:08AM +1100, Damien Miller wrote: > Phil Dibowitz wrote: > > Damien Miller wrote: > > > >>FYI It will probably be called 3.8 rather then 3.7.2. > > > > > > This might be a bad question to ask... but is there an _approximate_ ETA > > on 3.7.2/3.8 ? > > Very soon - by the end of the month, if not sooner. > > Please grab a snapshot and test - they are very stable. > I will try and do that. In the mean time, I have one other question. In the 3.7.1 GSSAPI code that I was playing with -- it doesn't seem to forward your ticket even if it was forwardable. Is this feature not yet implimented? -- Phil Dibowitz phil at ipom.com Freeware and Technical Pages Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/ "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin, 1759 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040210/a00007ac/attachment.bin From esp5 at pge.com Wed Feb 11 18:30:48 2004 From: esp5 at pge.com (Edward S. Peschko) Date: Tue, 10 Feb 2004 23:30:48 -0800 Subject: /etc/default/login change from 3.6 to 3.7??? Message-ID: <20040211073048.GA1948@mdssdev05.comp.pge.com> hey, I just got an ugly, hard-to-fix surpirse when I upgraded from 3.6 to 3.7 for openssh - Now, in 3.7.1, /etc/default/login overrides --with-default-path! Before, it used to prefer --with-default-path (as configured). I'm hoping that this is a bug. It forces every user to have an appropriate .login,.cshrc, or whatever *or* to comment out the appropriate entries in / etc/default/login! Either that, or I'm missing something truly obvious... Ed From djm at mindrot.org Wed Feb 11 21:19:52 2004 From: djm at mindrot.org (Damien Miller) Date: Wed, 11 Feb 2004 21:19:52 +1100 (EST) Subject: /etc/default/login change from 3.6 to 3.7??? In-Reply-To: <20040211073048.GA1948@mdssdev05.comp.pge.com> References: <20040211073048.GA1948@mdssdev05.comp.pge.com> Message-ID: On Tue, 10 Feb 2004, Edward S. Peschko wrote: > hey, > > I just got an ugly, hard-to-fix surpirse when I upgraded from 3.6 to 3.7 for > openssh - Now, in 3.7.1, /etc/default/login overrides --with-default-path! Before, > it used to prefer --with-default-path (as configured). > > I'm hoping that this is a bug. It forces every user to have an appropriate > .login,.cshrc, or whatever *or* to comment out the appropriate entries in / > etc/default/login! > > Either that, or I'm missing something truly obvious... Change the entries in /etc/default/login? -d From dtucker at zip.com.au Wed Feb 11 21:36:51 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 11 Feb 2004 21:36:51 +1100 Subject: /etc/default/login change from 3.6 to 3.7??? In-Reply-To: <20040211073048.GA1948@mdssdev05.comp.pge.com> References: <20040211073048.GA1948@mdssdev05.comp.pge.com> Message-ID: <402A05C3.9020404@zip.com.au> Edward S. Peschko wrote: > I just got an ugly, hard-to-fix surpirse when I upgraded from 3.6 to 3.7 for > openssh - Now, in 3.7.1, /etc/default/login overrides --with-default-path! Before, > it used to prefer --with-default-path (as configured). The reasoning was: run-time configuration by the host's admin trumps compile-time configuration by the package builder. > I'm hoping that this is a bug. It forces every user to have an appropriate > .login,.cshrc, or whatever *or* to comment out the appropriate entries in / > etc/default/login! Or put the path to scp in /etc/default/login, or disable it at build time. $ ./configure --help |grep default-log --disable-etc-default-login Disable using PATH from /etc/default/login > Either that, or I'm missing something truly obvious... Well, there were some clues... $ ./configure [snip] checking for "/etc/default/login"... yes configure: WARNING: If PATH is defined in /etc/default/login, ensure the path to scp is included, otherwise scp will not work. Adding /usr/local/bin to USER_PATH so scp will work [snip] OpenSSH has been configured with the following options: [snip] sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin (If PATH is set in /etc/default/login it will be used instead. If used, ensure the path to scp is present, otherwise scp will not work.) The use of /etc/default/login was also mentioned in the 3.7 release notes (not the interaction with scp, though). FWIW, --with-etc-default-login probably should have defaulted to "no" (this is my fault), but it's too late to change it now. -- 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 Feb 11 23:26:58 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 11 Feb 2004 23:26:58 +1100 Subject: OpenSSH 3.8 and password expiry. Message-ID: <402A1F92.8090302@zip.com.au> Hi All. I'm pleased to report that as of yesterday, OpenSSH -current now supports forced changes of expired passwords on most platforms, and bug #14 is now closed. Specifically, AIX's native authentication, BSD Authentication and shadow passwords with the expiry field are supported. The password is changed by exec'ing /usr/bin/passwd in the session. Interested parties should grab a snapshot and try it. In addition, SSHv1 connections with UsePrivilegeSeparation=yes and UsePAM=yes will use the same /usr/bin/passwd mechanism. Some time ago, a patch to do SSHv2 password changes via keyboard-interactive was also merged, and that should work with or without privsep. For those who have been using my expiry patches, you should be aware that there are some differences in behaviour between them and -current: 1) password expiry is only checked for password authentication 2) after a change (successful or otherwise), the session is terminated and the user must log in again 3) AIX's loginsuccess() is not called for non-password authentications 4) There is no warning of pending account or password expirations for shadow passwords. 5) Last login times won't be displayed when lastlog is readable only be root. Most of the other authentication-related fixes have been merged into -current. 1) and 2) are how it will probably stay. 3) and 5) probably won't be fixed until after the 3.8 release. I'm hoping to have 4) fixed in the next couple of days (if anyone wants patches to test, let me know). For those used to my patches, I will do one more series against 3.8x with the same behaviour as present (including the not-yet-merged bits). Once those bits are merged post-3.8, I don't plan on any further patches. Thanks to all who contributed patches, fixes, bug reports and testing of the patches during the last 18 months or so[1]. Not all of those contributions ended up being used in the final solution but all were valuable in shaping it. Again, I encourage you to try a snapshot and report success or failure (or queries) to the list. -Daz. [1] Pablo Sor, Mark Pitt, Zdenek Tlusty, Kevin Cawlfield, Dan Oviatt, Ravinder Sekhon, Scott Burch and Andrew Elwell. Apologies to anyone I missed. -- 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 naddy at mips.inka.de Thu Feb 12 04:14:23 2004 From: naddy at mips.inka.de (Christian Weisgerber) Date: Wed, 11 Feb 2004 17:14:23 +0000 (UTC) Subject: Makefile.in: progressmeter.o has moved to libssh Message-ID: Since progressmeter.o has moved to libssh, we don't need to explicitly link it into scp and sftp any longer. Index: Makefile.in =================================================================== RCS file: /cvs/openssh/Makefile.in,v retrieving revision 1.255 diff -u -r1.255 Makefile.in --- Makefile.in 10 Feb 2004 02:01:14 -0000 1.255 +++ Makefile.in 11 Feb 2004 17:10:40 -0000 @@ -137,8 +137,8 @@ sshd$(EXEEXT): libssh.a $(LIBCOMPAT) $(SSHDOBJS) $(LD) -o $@ $(SSHDOBJS) $(LDFLAGS) -lssh -lopenbsd-compat $(LIBWRAP) $(LIBPAM) $(LIBS) -scp$(EXEEXT): $(LIBCOMPAT) libssh.a scp.o progressmeter.o - $(LD) -o $@ scp.o progressmeter.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) +scp$(EXEEXT): $(LIBCOMPAT) libssh.a scp.o + $(LD) -o $@ scp.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) ssh-add$(EXEEXT): $(LIBCOMPAT) libssh.a ssh-add.o $(LD) -o $@ ssh-add.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) @@ -158,8 +158,8 @@ sftp-server$(EXEEXT): $(LIBCOMPAT) libssh.a sftp.o sftp-common.o sftp-server.o $(LD) -o $@ sftp-server.o sftp-common.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) -sftp$(EXEEXT): $(LIBCOMPAT) libssh.a sftp.o sftp-client.o sftp-int.o sftp-common.o sftp-glob.o progressmeter.o - $(LD) -o $@ progressmeter.o sftp.o sftp-client.o sftp-common.o sftp-int.o sftp-glob.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) +sftp$(EXEEXT): $(LIBCOMPAT) libssh.a sftp.o sftp-client.o sftp-int.o sftp-common.o sftp-glob.o + $(LD) -o $@ sftp.o sftp-client.o sftp-common.o sftp-int.o sftp-glob.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) ssh-rand-helper${EXEEXT}: $(LIBCOMPAT) libssh.a ssh-rand-helper.o $(LD) -o $@ ssh-rand-helper.o $(LDFLAGS) -lssh -lopenbsd-compat $(LIBS) -- Christian "naddy" Weisgerber naddy at mips.inka.de From acbell at iastate.edu Thu Feb 12 06:51:17 2004 From: acbell at iastate.edu (Andrew Bell) Date: Wed, 11 Feb 2004 13:51:17 -0600 Subject: SSH Shutdown and CVS Message-ID: <6.0.1.1.2.20040211134736.02bf4978@acbell.mail.iastate.edu> Hi, I have a problem with using openssh and cvs. CVS on my client forks an ssh process, send stuff across the ssh connection to the CVS server. The CVS server process, forked by sshd, exits, but the CVS client hangs, waiting for the ssh process that it forked to die (CVS has closed the pipe that it uses to communicate to ssh). Can you tell me why the ssh process might hang if the remote command has exited? Can someone summarize the shutdown process so that I can schlep through the code and look for the bug. Thanks, -- Andrew Bell acbell at iastate.edu From daniel+mindrot at pelleg.org Thu Feb 12 11:30:58 2004 From: daniel+mindrot at pelleg.org (Dan Pelleg) Date: Wed, 11 Feb 2004 19:30:58 -0500 Subject: OpenSSH_3.7.1p2 Floating point exception on Opteron Message-ID: <16426.51522.616267.506644@lark.auton.cs.cmu.edu> I'm getting a floating point exception from ssh on an opteron running Linux (in 64 bit). It happens only when I ssh out to a server not supporting SSHv2 and when its public key is not already in the key file. Right after I answer "yes" to the "Are you sure?" prompt I get the exception. Here is the stack trace: Program received signal SIGFPE, Arithmetic exception 0x0000002a95a0d58c in bn_div_words () from /usr/lib/libcrypto.so.0.9.7 (gdb) bt #0 0x0000002a95a0d58c in bn_div_words () from /usr/lib/libcrypto.so.0.9.7 #1 0x0000002a95a0a905 in BN_div_word () from /usr/lib/libcrypto.so.0.9.7 #2 0x0000002a95a09a09 in BN_bn2dec () from /usr/lib/libcrypto.so.0.9.7 #3 0x000000000041ec59 in write_bignum (f=0x5567c0, num=0x8ac7230489e80000) at key.c:368 #4 0x000000000041f060 in key_write (key=0x556050, f=0x5567c0) at key.c:504 #5 0x0000000000418971 in add_host_to_hostfile ( I see a similar report at: http://www.mindrot.org/pipermail/openssh-unix-dev/2004-January/020326.html Is this the same issue? From dtucker at zip.com.au Thu Feb 12 13:06:34 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 12 Feb 2004 13:06:34 +1100 Subject: OpenSSH_3.7.1p2 Floating point exception on Opteron In-Reply-To: <16426.51522.616267.506644@lark.auton.cs.cmu.edu> References: <16426.51522.616267.506644@lark.auton.cs.cmu.edu> Message-ID: <402ADFAA.9020708@zip.com.au> Dan Pelleg wrote: > I'm getting a floating point exception from ssh on an opteron running Linux > (in 64 bit). It happens only when I ssh out to a server not supporting > SSHv2 and when its public key is not already in the key file. Right after I > answer "yes" to the "Are you sure?" prompt I get the exception. > > Here is the stack trace: > > Program received signal SIGFPE, Arithmetic exception > 0x0000002a95a0d58c in bn_div_words () from /usr/lib/libcrypto.so.0.9.7 > (gdb) bt > #0 0x0000002a95a0d58c in bn_div_words () from /usr/lib/libcrypto.so.0.9.7 > #1 0x0000002a95a0a905 in BN_div_word () from /usr/lib/libcrypto.so.0.9.7 > #2 0x0000002a95a09a09 in BN_bn2dec () from /usr/lib/libcrypto.so.0.9.7 > #3 0x000000000041ec59 in write_bignum (f=0x5567c0, num=0x8ac7230489e80000) at key.c:368 > #4 0x000000000041f060 in key_write (key=0x556050, f=0x5567c0) at key.c:504 > #5 0x0000000000418971 in add_host_to_hostfile ( This looks like an error inside OpenSSL. Does OpenSSL's self-test (ie "make test") pass? > I see a similar report at: > http://www.mindrot.org/pipermail/openssh-unix-dev/2004-January/020326.html > > Is this the same issue? No. -- 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 appro at fy.chalmers.se Thu Feb 12 19:51:18 2004 From: appro at fy.chalmers.se (Andy Polyakov) Date: Thu, 12 Feb 2004 09:51:18 +0100 Subject: OpenSSH_3.7.1p2 Floating point exception on Opteron References: <16426.51522.616267.506644@lark.auton.cs.cmu.edu> <402ADFAA.9020708@zip.com.au> Message-ID: <402B3E86.5082B09D@fy.chalmers.se> > > I'm getting a floating point exception from ssh on an opteron running Linux > > (in 64 bit). It happens only when I ssh out to a server not supporting > > SSHv2 and when its public key is not already in the key file. Right after I > > answer "yes" to the "Are you sure?" prompt I get the exception. > > > > Here is the stack trace: > > > > Program received signal SIGFPE, Arithmetic exception > > 0x0000002a95a0d58c in bn_div_words () from /usr/lib/libcrypto.so.0.9.7 > > (gdb) bt > > #0 0x0000002a95a0d58c in bn_div_words () from /usr/lib/libcrypto.so.0.9.7 > > #1 0x0000002a95a0a905 in BN_div_word () from /usr/lib/libcrypto.so.0.9.7 > > #2 0x0000002a95a09a09 in BN_bn2dec () from /usr/lib/libcrypto.so.0.9.7 > > #3 0x000000000041ec59 in write_bignum (f=0x5567c0, num=0x8ac7230489e80000) at key.c:368 > > #4 0x000000000041f060 in key_write (key=0x556050, f=0x5567c0) at key.c:504 > > #5 0x0000000000418971 in add_host_to_hostfile ( > > This looks like an error inside OpenSSL. Yes, it was brought to OpenSSL attention last week, see http://www.aet.tu-cottbus.de/rt2/Ticket/Display.html?id=821. It's typo in inline assembler line in bn_div_words() in crypto/bn/asm/x86_64-gcc.c, which should read "divq %4" and not "divq %3." My comment on the function never being called is obviously refuted... > Does OpenSSL's self-test (ie "make test") pass? ... so I have to refine it. The function in question is never called during 'make test', which is how the bug slipped through. A. From Lutz.Jaenicke at aet.TU-Cottbus.DE Thu Feb 12 20:18:27 2004 From: Lutz.Jaenicke at aet.TU-Cottbus.DE (Lutz Jaenicke) Date: Thu, 12 Feb 2004 10:18:27 +0100 Subject: Testing of recent commits In-Reply-To: <20031127133114.GA18382@serv01.aet.tu-cottbus.de> References: <1069155926.10951.61.camel@sakura.mindrot.org> <20031118144331.GA32723@cygbert.vinschen.de> <3FBABA33.A8DB4A64@zip.com.au> <20031119074148.GA29726@serv01.aet.tu-cottbus.de> <20031127133114.GA18382@serv01.aet.tu-cottbus.de> Message-ID: <20040212091827.GA27326@serv01.aet.tu-cottbus.de> On Thu, Nov 27, 2003 at 02:31:14PM +0100, Lutz Jaenicke wrote: > I have now installed the latest Bind 8.4.3, still having this issue. > After modifying the arpa/inet.h file provided as part of Bind 8 to include > the necessary macros, OpenSSH compiles and passes regression tests > (CVS as of 27 Nov 03). > I have filed a bug report againts Bind 8 on HP-UX 10.20, which has been > assigned [ISC-Bugs #10026]. FYI: This bug has been fixed in Bind 8.4.4. Best regards, Lutz -- Lutz Jaenicke Lutz.Jaenicke at aet.TU-Cottbus.DE http://www.aet.TU-Cottbus.DE/personen/jaenicke/ BTU Cottbus, Allgemeine Elektrotechnik Universitaetsplatz 3-4, D-03044 Cottbus From sxw at inf.ed.ac.uk Thu Feb 12 22:31:26 2004 From: sxw at inf.ed.ac.uk (sxw at inf.ed.ac.uk) Date: Thu, 12 Feb 2004 11:31:26 +0000 (GMT) Subject: Some GSSAPI/Kerberos Questions In-Reply-To: <20040210235229.GB6194@ipom.com> Message-ID: On Tue, 10 Feb 2004, Phil Dibowitz wrote: > On Wed, Feb 11, 2004 at 10:38:08AM +1100, Damien Miller wrote: > In the mean time, I have one other question. In the 3.7.1 GSSAPI code > that I was playing with -- it doesn't seem to forward your ticket even > if it was forwardable. Is this feature not yet implimented? It is implemented - you just need to set the relevant configuration options on client and server. From memory, I think its 'GSSAPIDelegateCredentials', but see the ssh.conf and sshd.conf manual pages for full details. Cheers, Simon. From deengert at anl.gov Sat Feb 14 07:53:06 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Fri, 13 Feb 2004 14:53:06 -0600 Subject: OpenSSH-snap-20040212 and the use of krb5-config Message-ID: <402D3932.A0CF44B4@anl.gov> With openssh-snap-20040212 the configure.ac when it finds a krb5-config file, does not call the AC_DEFINE(GSSAPI) or AC_CHECK_HEADER(gssapi.h...) This means that GSSAPI and HAVE_GSSAPI_H are not defined, and thus GSSAPI is not built. If I rename the kerberos provided krb5-config file and run configure, the old method of finding the Kerberos lib and include directories is used and OpenSSH builds with the GSSAPI. There is also a seperate issue with the MIT version of krb5-config with finding the location of gssapi.h. Its in thier .../include/gssapi which is not returned by the krb5-config --cflags. I have reported that to MIT as a seperate bug. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From dtucker at zip.com.au Sat Feb 14 19:20:08 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 14 Feb 2004 19:20:08 +1100 Subject: OpenSSH-snap-20040212 and the use of krb5-config In-Reply-To: <402D3932.A0CF44B4@anl.gov> References: <402D3932.A0CF44B4@anl.gov> Message-ID: <402DDA38.4020003@zip.com.au> Douglas E. Engert wrote: > With openssh-snap-20040212 the configure.ac when it finds a > krb5-config file, does not call the AC_DEFINE(GSSAPI) or > AC_CHECK_HEADER(gssapi.h...) This means that GSSAPI and HAVE_GSSAPI_H > are not defined, and thus GSSAPI is not built. Fair enough. How's this patch? > If I rename the kerberos provided krb5-config file and run configure, > the old method of finding the Kerberos lib and include directories > is used and OpenSSH builds with the GSSAPI. > > There is also a seperate issue with the MIT version of krb5-config with > finding the location of gssapi.h. Its in thier .../include/gssapi which > is not returned by the krb5-config --cflags. I have reported that to MIT as > a seperate bug. I'm wondering what (if anything) configure should do about this. Currently it searches for GSSAPI includes in /path/to/kerberos/include/gssapi. On the other hand, using krb5-config is supposed make things simpler, right :-? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-gssapi-conf.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040214/49b519fd/attachment.ksh From geos at epost.de Sun Feb 15 06:35:33 2004 From: geos at epost.de (Georg Schwarz) Date: Sat, 14 Feb 2004 20:35:33 +0100 Subject: OpenSSH 3.7.1p2 linked libs Message-ID: <1g95ui5.j5pjda1lysvwgM@geos.net.eu.org> OpenSSH (at least on IRIX) uses -lgen in LIBS. This is only needed (and thus should only be used) for linking sshd. Using -lgen elsewhere unnecessarily adds code and dependencies. Similarly, -lcrypto is not needed when linking scp. -- Georg Schwarz http://home.pages.de/~schwarz/ geos at epost.de +49 177 8811442 From djm at mindrot.org Sun Feb 15 15:51:47 2004 From: djm at mindrot.org (Damien Miller) Date: Sun, 15 Feb 2004 15:51:47 +1100 (EST) Subject: OpenSSH 3.7.1p2 linked libs In-Reply-To: <1g95ui5.j5pjda1lysvwgM@geos.net.eu.org> References: <1g95ui5.j5pjda1lysvwgM@geos.net.eu.org> Message-ID: On Sat, 14 Feb 2004, Georg Schwarz wrote: > OpenSSH (at least on IRIX) uses -lgen in LIBS. This is only needed (and > thus should only be used) for linking sshd. Using -lgen elsewhere > unnecessarily adds code and dependencies. > Similarly, -lcrypto is not needed when linking scp. The linker should ignore unnecessary dependancies, shouldn't it? -d From dtucker at zip.com.au Sun Feb 15 16:26:00 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 15 Feb 2004 16:26:00 +1100 Subject: OpenSSH 3.7.1p2 linked libs In-Reply-To: References: <1g95ui5.j5pjda1lysvwgM@geos.net.eu.org> Message-ID: <402F02E8.4000901@zip.com.au> Damien Miller wrote: > On Sat, 14 Feb 2004, Georg Schwarz wrote: >>OpenSSH (at least on IRIX) uses -lgen in LIBS. This is only needed (and >>thus should only be used) for linking sshd. Using -lgen elsewhere >>unnecessarily adds code and dependencies. >>Similarly, -lcrypto is not needed when linking scp. > > > The linker should ignore unnecessary dependancies, shouldn't it? It doesn't (on Linux anyway, I suspect it's the same on other systems). That said, it's already tricky to get the library path and link order right on all supported configurations, and I would not like to see it made harder by maintaing different ones for different binaries. Georg, does this cause an actual problem? libgen is part of the base OS, right? Also, there's no noticable difference in size on Linux. $ cat hello.c #include int main(void) { puts("Hello, world."); } $ gcc hello.c -lcrypto $ ldd a.out libcrypto.so.4 => /lib/libcrypto.so.4 (0x40028000) libc.so.6 => /lib/libc.so.6 (0x4011f000) libdl.so.2 => /lib/libdl.so.2 (0x40246000) libz.so.1 => /usr/lib/libz.so.1 (0x40249000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) -- 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 geos at epost.de Sun Feb 15 22:06:48 2004 From: geos at epost.de (Georg Schwarz) Date: Sun, 15 Feb 2004 12:06:48 +0100 (CET) Subject: OpenSSH 3.7.1p2 linked libs In-Reply-To: <402F02E8.4000901@zip.com.au> Message-ID: > > The linker should ignore unnecessary dependancies, shouldn't it? > > It doesn't (on Linux anyway, I suspect it's the same on other systems). it doesn't on IRIX 5.3 either > That said, it's already tricky to get the library path and link order > right on all supported configurations, and I would not like to see it > made harder by maintaing different ones for different binaries. in this particular case I guess it should not be that hard. Have -lgen not added to LIBS by configure but, say, to LIBGEN. LIBGEN is then either -lgen or empty. Have LIBGEN added to the sshd link line only (assuming this is the only place where you use basename, dirname; from my tests it is). Similarly for, say, LIBCRYPTO, which you add everywhehe ehere LIBS already is except for the scp link line. That way you gain a finer granularity for selecting which libs to actually use. > > Georg, does this cause an actual problem? libgen is part of the base well, things run nonetheless, but of course it is not optimum. libgen is part of the OS, libcrypto is not. In any case we get unnecessary dynamic library dependencies. I guess this will at least make binary startup a bit slower and could add to overall runtime memory consumption. > OS, right? Also, there's no noticable difference in size on Linux. > > $ cat hello.c > #include > int main(void) { puts("Hello, world."); } > $ gcc hello.c -lcrypto > $ ldd a.out > libcrypto.so.4 => /lib/libcrypto.so.4 (0x40028000) > libc.so.6 => /lib/libc.so.6 (0x4011f000) > libdl.so.2 => /lib/libdl.so.2 (0x40246000) > libz.so.1 => /usr/lib/libz.so.1 (0x40249000) > /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) > lorenz 15% cc hello.c -lgen lorenz 16% elfdump -Dl a.out a.out: ***LIBRARY LIST SECTION*** Name Time-Stamp CheckSum Flags Version .liblist libgen.so Nov 1 03:20:56 1994 0xe81f4ee2 NONE sgi1.0 libc.so.1 Nov 1 03:18:58 1994 0x47ba9926 NONE sgi1.0 lorenz 17% cc hello.c -L/usr/local/pkg/lib -lcrypto lorenz 18% elfdump -Dl a.out a.out: ***LIBRARY LIST SECTION*** Name Time-Stamp CheckSum Flags Version .liblist libcrypto.so.300.1 Feb 5 01:16:41 2004 0xb21379bb NONE libc.so.1 Nov 1 03:18:58 1994 0x47ba9926 NONE sgi1.0 a.out sizes: with no libs: 13020 with lgen: 13020 with lcrypto: 13116 with both: 13116 -- Georg Schwarz http://home.pages.de/~schwarz/ geos at epost.de +49 177 8811442 From geos at epost.de Sun Feb 15 22:15:42 2004 From: geos at epost.de (Georg Schwarz) Date: Sun, 15 Feb 2004 12:15:42 +0100 (CET) Subject: OpenSSH 3.7.1p2 linked libs In-Reply-To: <402F02E8.4000901@zip.com.au> Message-ID: > Georg, does this cause an actual problem? for an explanation from Sun on that topic, see "Remove Unused Material" at http://docs.sun.com/db/doc/816-7529/6mdhf5r36?a=view unfortunately it seems most linkers don't have an equivalent of Sun's -z ignore option, so programmers must take take which libs to include. -- Georg Schwarz http://home.pages.de/~schwarz/ geos at epost.de +49 177 8811442 From mouring at etoh.eviladmin.org Mon Feb 16 04:16:23 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sun, 15 Feb 2004 11:16:23 -0600 (CST) Subject: OpenSSH 3.7.1p2 linked libs In-Reply-To: Message-ID: On Sun, 15 Feb 2004, Georg Schwarz wrote: > > > The linker should ignore unnecessary dependancies, shouldn't it? > > > > It doesn't (on Linux anyway, I suspect it's the same on other systems). > > it doesn't on IRIX 5.3 either > > > That said, it's already tricky to get the library path and link order > > right on all supported configurations, and I would not like to see it > > made harder by maintaing different ones for different binaries. > > in this particular case I guess it should not be that hard. Have -lgen > not added to LIBS by configure but, say, to LIBGEN. LIBGEN is then either > -lgen or empty. Have LIBGEN added to the sshd link line only (assuming > this is the only place where you use basename, dirname; from my tests it > is). I think the point is if one is going to do this type of games. You should do it correct or not at all. And we decided not to play the game at all due to the diverse platform base. > Similarly for, say, LIBCRYPTO, which you add everywhehe ehere LIBS already > is except for the scp link line. That way you gain a finer granularity > for selecting which libs to actually use. > Umm.. Look back in the email archives about -lcrypto and -lcrypt combo and their bad interaction on some platforms. Anytime anyone suggests making changes near this part of the configuration scripts they are require to provide a written certified in thier own blood that it will not break any platforms. =) > > > > Georg, does this cause an actual problem? libgen is part of the base > > well, things run nonetheless, but of course it is not optimum. libgen > is part of the OS, libcrypto is not. In any case we get unnecessary > dynamic library dependencies. I guess this will at least make binary > startup a bit slower and could add to overall runtime memory consumption. > Not sure why "libcrypto is not" is an issue. scp won't work without ssh which requires libcrypto. We have proof on dramatic memory usage or speed degrade? I suspect they will be miminal for anything within the last five or so years due to lazy loading. - Ben From deengert at anl.gov Tue Feb 17 04:12:12 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Mon, 16 Feb 2004 11:12:12 -0600 Subject: OpenSSH-snap-20040212 and the use of krb5-config References: <402D3932.A0CF44B4@anl.gov> <402DDA38.4020003@zip.com.au> Message-ID: <4030F9EC.503AC026@anl.gov> Darren Tucker wrote: > > Douglas E. Engert wrote: > > With openssh-snap-20040212 the configure.ac when it finds a > > krb5-config file, does not call the AC_DEFINE(GSSAPI) or > > AC_CHECK_HEADER(gssapi.h...) This means that GSSAPI and HAVE_GSSAPI_H > > are not defined, and thus GSSAPI is not built. > > Fair enough. How's this patch? Attached is a modified version that will check for the gssapi.h and try to look in two places. This is similiar to the way it worked without the krb5-config. So it will work with or without an MIT fix in the future. > > > If I rename the kerberos provided krb5-config file and run configure, > > the old method of finding the Kerberos lib and include directories > > is used and OpenSSH builds with the GSSAPI. > > > > There is also a seperate issue with the MIT version of krb5-config with > > finding the location of gssapi.h. Its in thier .../include/gssapi which > > is not returned by the krb5-config --cflags. I have reported that to MIT as > > a seperate bug. > > I'm wondering what (if anything) configure should do about this. > Currently it searches for GSSAPI includes in > /path/to/kerberos/include/gssapi. On the other hand, using krb5-config > is supposed make things simpler, right :-? Yes that was the intent. The gssapi.h in Heimdal appears to be in /path/to/kerberos/include where as with MIT it is in /path/to/kerberos/include/gssapi, but the MIT krb5-config only returns /path/to/kerberos/include > > -- > 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: configure.ac > =================================================================== > RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/configure.ac,v > retrieving revision 1.198 > diff -u -p -r1.198 configure.ac > --- configure.ac 12 Feb 2004 17:27:21 -0000 1.198 > +++ configure.ac 14 Feb 2004 00:43:32 -0000 > @@ -2084,6 +2084,9 @@ AC_ARG_WITH(kerberos5, > AC_MSG_CHECKING(for gssapi support) > if $KRB5CONF | grep gssapi >/dev/null ; then > AC_MSG_RESULT(yes) > + AC_DEFINE(GSSAPI) > + AC_CHECK_HEADERS(gssapi.h, , > + AC_MSG_WARN([Cannot find any suitable gss-api header - build may fail]) > K5CFLAGS="`$KRB5CONF --cflags gssapi`" > dnl m4 quadragraphs: "sed 's/-l[^- ]*//g'" > K5LDFLAGS="`$KRB5CONF --libs gssapi | sed 's/-l@<:@^- @:>@*//g'`" > > --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 -------------- next part -------------- --- ,configure.ac Tue Feb 10 00:15:05 2004 +++ configure.ac Mon Feb 16 09:29:56 2004 @@ -2084,18 +2084,29 @@ AC_MSG_CHECKING(for gssapi support) if $KRB5CONF | grep gssapi >/dev/null ; then AC_MSG_RESULT(yes) + AC_DEFINE(GSSAPI) K5CFLAGS="`$KRB5CONF --cflags gssapi`" dnl m4 quadragraphs: "sed 's/-l[^- ]*//g'" K5LDFLAGS="`$KRB5CONF --libs gssapi | sed 's/-l@<:@^- @:>@*//g'`" K5LIBS="`$KRB5CONF --libs gssapi | sed 's/-L@<:@^- @:>@*//g'`" + CPPFLAGS="$CPPFLAGS $K5CFLAGS" + LDFLAGS="$LDFLAGS $K5LDFLAGS" + AC_CHECK_HEADER(gssapi.h, , + [ unset ac_cv_header_gssapi_h + CPPFLAGS="$CPPFLAGS ${K5CFLAGS}/gssapi" + AC_CHECK_HEADERS(gssapi.h, , + AC_MSG_WARN([Cannot find any suitable gss-api header - build may fail]) + ) + ] + ) else AC_MSG_RESULT(no) K5CFLAGS="`$KRB5CONF --cflags`" K5LDFLAGS="`$KRB5CONF --libs | sed 's/-l@<:@^- @:>@*//g'`" K5LIBS="`$KRB5CONF --libs | sed 's/-L@<:@^- @:>@*//g'`" + CPPFLAGS="$CPPFLAGS $K5CFLAGS" + LDFLAGS="$LDFLAGS $K5LDFLAGS" fi - CPPFLAGS="$CPPFLAGS $K5CFLAGS" - LDFLAGS="$LDFLAGS $K5LDFLAGS" AC_MSG_CHECKING(whether we are using Heimdal) AC_TRY_COMPILE([ #include ], [ char *tmp = heimdal_version; ], From euquintana at ing-coam.com.mx Tue Feb 17 12:32:19 2004 From: euquintana at ing-coam.com.mx (Quintana Alcantara Edgar Uriel) Date: Mon, 16 Feb 2004 19:32:19 -0600 Subject: OpenSSH with RSA authentication Server Message-ID: <3BD5FCC8AC38C340B18D727F50133F5947B59E@exchtlalpan.ing-coam.com.mx> Hello, in my company we want to implement a Two-Factor authentication in servers with Solaris(8 or 9) and HP-UX (11 or 11i). The authentication server will be a RSA. We want to use OpenSSH to ask for authorization twice, first with PAM, and then to the RSA server. I like to know if somebody already implemented. Thanks for your help Uriel Quintana La informaci?n contenida en este correo electr?nico es confidencial y est? legalmente protegida. Est? dirigido solamente a la direcci?n de correo se?alada. El acceso a este correo electr?nico por cualquier otra persona, No est? autorizado. Si Ud. no es el receptor deliberado de este correo electr?nico, cualquier difusi?n, copia o distribuci?n est? prohibida y puede ser ilegal.? Si lo ha recibido por error, por favor notifique al emisor e inmediatamente? b?rrelo de forma permanente y destruya cualquier copia impresa. En caso de que el correo est? dirigido a alguno de nuestros clientes, la opini?n o recomendaci?n contenida est? sujeta a las condiciones regulatorias de ING que resulten aplicables o a los acuerdos comerciales suscritos con el cliente. ? The information in this Internet e-mail is confidential and may be legally privileged. It is intended solely for the addressee(s). Access to this Internet e-mail by anyone else is unauthorized. If you are not the intended recipient of this e-mail, any disclosure, copying, or distribution of it is prohibited and may be unlawful. If you have received this e-mail in error, please notify the sender and immediately and permanently delete it and destroy any copies of it that were printed out.? When addressed to our clients any opinions or advice contained in this Internet e-mail is subject to the terms and conditions expressed in any applicable governing ING terms of business or client engagement letter. From djm at mindrot.org Tue Feb 17 13:06:45 2004 From: djm at mindrot.org (Damien Miller) Date: Tue, 17 Feb 2004 13:06:45 +1100 Subject: OpenSSH with RSA authentication Server In-Reply-To: <3BD5FCC8AC38C340B18D727F50133F5947B59E@exchtlalpan.ing-coam.com.mx> References: <3BD5FCC8AC38C340B18D727F50133F5947B59E@exchtlalpan.ing-coam.com.mx> Message-ID: <40317735.9040707@mindrot.org> Quintana Alcantara Edgar Uriel wrote: > Hello, > > in my company we want to implement a Two-Factor authentication in servers > with Solaris(8 or 9) and HP-UX (11 or 11i). The authentication server will > be a RSA. > > We want to use OpenSSH to ask for authorization twice, first with PAM, and > then to the RSA server. Why not just do it with PAM, using a pam.conf which uses both pam_unix.so and pam_securid.so? OpenSSH supports this already, current snapshots work best. -d From dtucker at zip.com.au Tue Feb 17 13:08:05 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 17 Feb 2004 13:08:05 +1100 Subject: OpenSSH with RSA authentication Server In-Reply-To: <3BD5FCC8AC38C340B18D727F50133F5947B59E@exchtlalpan.ing-coam.com.mx> References: <3BD5FCC8AC38C340B18D727F50133F5947B59E@exchtlalpan.ing-coam.com.mx> Message-ID: <40317785.6010401@zip.com.au> Quintana Alcantara Edgar Uriel wrote: [snip] > The information in this Internet e-mail is confidential and may be > legally privileged. It is intended solely for the addressee(s). Access > to this Internet e-mail by anyone else is unauthorized. If you are > not the intended recipient of this e-mail, any disclosure, copying, > or distribution of it is prohibited. I was going to suggest a PAM configuration that might be able to do what you want. However, since I'm not the addressee, I'm not authorized to access the message to compose a response (or, indeed, quote the parts that I'm responding to). In future, please don't post confidential information to a public mailing list. -- 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 atossava at cc.helsinki.fi Tue Feb 17 19:29:12 2004 From: atossava at cc.helsinki.fi (Atro Tossavainen) Date: Tue, 17 Feb 2004 10:29:12 +0200 (EET) Subject: OpenSSH 3.7 released (fwd) Message-ID: <200402170829.i1H8TCtW003514@kruuna.Helsinki.FI> Since there never was an answer on the secureshell at securityfocus.com list to this question, I thought I'd ask you guys on your own list and maybe I'll even get an answer. If the answer involves PAM in any way, then the most obvious question becomes "what about IRIX, Tru64, or any other platforms whose login procedure does not have PAM?". ----- Forwarded message from Atro Tossavainen ----- >From secureshell-return-5782-atro.tossavainen=helsinki.fi at securityfocus.com Thu Sep 18 03:04:25 2003 Received: from outgoing2.securityfocus.com (outgoing2.securityfocus.com [205.206.231.26]) by post.it.helsinki.fi (8.12.10/8.12.10) with ESMTP id h8I04LEE025921 for <-me->; Thu, 18 Sep 2003 03:04:22 +0300 (EEST) Received: from lists.securityfocus.com (lists.securityfocus.com [205.206.231.19]) by outgoing2.securityfocus.com (Postfix) with QMQP id 30DCE8F289; Wed, 17 Sep 2003 11:58:10 -0600 (MDT) Mailing-List: contact secureshell-help at securityfocus.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Delivered-To: mailing list secureshell at securityfocus.com Delivered-To: moderator for secureshell at securityfocus.com Received: (qmail 8307 invoked from network); 17 Sep 2003 00:44:36 -0000 From: Atro Tossavainen <-me-> Message-Id: <200309170653.h8H6rItX014017 at kruuna.Helsinki.FI> Subject: Re: OpenSSH 3.7 released In-Reply-To: <20030916120703.GA12349 at folly> from Markus Friedl at "Sep 16, 2003 02:07:03 pm" To: secureshell at securityfocus.com Date: Wed, 17 Sep 2003 09:53:18 +0300 (EEST) X-Mailer: ELM [version 2.4ME+ PL66 (25)] Hello Markus, others, > Changes since OpenSSH 3.6.1: > ============================ > > * Changes in Kerberos support: > ... > - KerberosIV and AFS support has been removed. I'm sure there's a well thought out reason behind this, but nonetheless, I'd like to ask what your suggestion to those who continue to need AFS login support in SSH is. -- Atro Tossavainen (Mr.) / The Institute of Biotechnology at Systems Analyst, Techno-Amish & / the University of Helsinki, Finland, +358-9-19158939 UNIX Dinosaur / employs me, but my opinions are my own. < URL : http : / / www . helsinki . fi / %7E atossava / > File attachments NOT welcome unless agreed to beforehand. ----- End of forwarded message from Atro Tossavainen ----- From bhuvana.ramachandran at motorola.com Tue Feb 17 22:59:27 2004 From: bhuvana.ramachandran at motorola.com (Ramachandran Bhuvana-A19643) Date: Tue, 17 Feb 2004 17:29:27 +0530 Subject: SSH disconnect issue after grace timer expiry Message-ID: <653138C25D8AD6118292000347080A3707D002B8@zin05exm02.corp.mot.com> Hi, I was just wondering if any of you would be able to help me with pointers to find a fix for the known problem in SSH2 that the server does not properly disconnect after the login grace time is reached. Thanks for your time ! Regards, Bhuvana From dtucker at zip.com.au Tue Feb 17 23:13:13 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 17 Feb 2004 23:13:13 +1100 Subject: SSH disconnect issue after grace timer expiry In-Reply-To: <653138C25D8AD6118292000347080A3707D002B8@zin05exm02.corp.mot.com> References: <653138C25D8AD6118292000347080A3707D002B8@zin05exm02.corp.mot.com> Message-ID: <40320559.3000308@zip.com.au> Ramachandran Bhuvana-A19643 wrote: > I was just wondering if any of you would be able to help me with > pointers to find a fix for the known problem in SSH2 that the server > does not properly disconnect after the login grace time is reached. It's in -current (both OpenBSD and -Portable). Attached is a version of the patch that will apply cleanly to 3.7.1p2. -- 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-3.7.1p2-logingracetime.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040217/549e19fa/attachment.ksh From Sergio.Gelato at astro.su.se Wed Feb 18 00:14:44 2004 From: Sergio.Gelato at astro.su.se (Sergio Gelato) Date: Tue, 17 Feb 2004 14:14:44 +0100 Subject: SNAP-20040216 configure mangles krb5-config output Message-ID: <20040217131443.GA3067@hanuman.astro.su.se> In the latest snapshot's configure file, there is a K5LIBS="`$KRB5CONF --libs gssapi | sed 's/-L[^- ]*//g'`" which doesn't work well on my system: $ krb5-config --libs gssapi -L/opt/heimdal-0.6/lib -lgssapi -lkrb5 -lasn1 -L/opt/lib -lcrypto -lroken Please consider changing it to K5LIBS="`$KRB5CONF --libs gssapi | sed 's/-L[^ ]*//g'`" if that won't break anything else. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040217/e9d0a778/attachment.bin From dtucker at zip.com.au Wed Feb 18 11:20:55 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 18 Feb 2004 11:20:55 +1100 Subject: OpenSSH-snap-20040212 and the use of krb5-config In-Reply-To: <4030F9EC.503AC026@anl.gov> References: <402D3932.A0CF44B4@anl.gov> <402DDA38.4020003@zip.com.au> <4030F9EC.503AC026@anl.gov> Message-ID: <4032AFE7.6070501@zip.com.au> Douglas E. Engert wrote: > Attached is a modified version that will check for the gssapi.h > and try to look in two places. This is similiar to the way it worked > without the krb5-config. So it will work with or without an MIT fix > in the future. [snip patch] That's more-or-less a copy of the existing gssapi.h header test inside the "else" part of the "if krb5-config", right? Would it make more sense to move the test outside of the "if" block rather than duplicate 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 Wed Feb 18 11:27:11 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 18 Feb 2004 11:27:11 +1100 Subject: SNAP-20040216 configure mangles krb5-config output In-Reply-To: <20040217131443.GA3067@hanuman.astro.su.se> References: <20040217131443.GA3067@hanuman.astro.su.se> Message-ID: <4032B15F.1000302@zip.com.au> Sergio Gelato wrote: > In the latest snapshot's configure file, there is a > K5LIBS="`$KRB5CONF --libs gssapi | sed 's/-L[^- ]*//g'`" > which doesn't work well on my system: > > $ krb5-config --libs gssapi > -L/opt/heimdal-0.6/lib -lgssapi -lkrb5 -lasn1 -L/opt/lib -lcrypto -lroken > > Please consider changing it to > K5LIBS="`$KRB5CONF --libs gssapi | sed 's/-L[^ ]*//g'`" > if that won't break anything else. That looks fine. I've changed it (I used 's/-L[^ ]* //g', which also works with the example you gave but doesn't leave a leading space). Thanks for that. -- 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 steelman at telmark.waw.pl Thu Feb 19 00:16:43 2004 From: steelman at telmark.waw.pl (Lukasz Stelmach) Date: Wed, 18 Feb 2004 14:16:43 +0100 Subject: forwarding Message-ID: <20040218141643.A1494@szpring.e.telmark.waw.pl> Greetings All. I wonder if it's possible to implement unix-domain-socket forwarding in opnessh. It might very useful since "namespace" for unix sockets is much bigger than for tcp ports and it would be easier to avoid any "name" clashes. In fact such implementation already exists as agent forwarding so what is my wish is to be able to specify local and remote socket name just like for remote and local tcp port forwarding. Best regards, -- |/ |_, _ .- --, 2:480/135 at fido do ko?ca epoki unixa zosta?o |__ |_|. | \ |_|. ._' /_. 101:1000/135 at unholy 1070373572 sekund. ... Akcja oraz kiwi nabieraj? tempa... From markus at openbsd.org Thu Feb 19 00:33:03 2004 From: markus at openbsd.org (Markus Friedl) Date: Wed, 18 Feb 2004 14:33:03 +0100 Subject: forwarding In-Reply-To: <20040218141643.A1494@szpring.e.telmark.waw.pl> References: <20040218141643.A1494@szpring.e.telmark.waw.pl> Message-ID: <20040218133302.GB22046@folly> On Wed, Feb 18, 2004 at 02:16:43PM +0100, Lukasz Stelmach wrote: > I wonder if it's possible to implement unix-domain-socket forwarding in > opnessh. It might very useful since "namespace" for unix sockets is > much bigger than for tcp ports and it would be easier to avoid any > "name" clashes. In fact such implementation already exists as agent > forwarding so what is my wish is to be able to specify local and remote > socket name just like for remote and local tcp port forwarding. yes, it's possible to implement. in fact early versions did support this with getaddrinfo returning unix domain sockets. From deengert at anl.gov Thu Feb 19 00:54:47 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Wed, 18 Feb 2004 07:54:47 -0600 Subject: OpenSSH-snap-20040212 and the use of krb5-config References: <402D3932.A0CF44B4@anl.gov> <402DDA38.4020003@zip.com.au> <4030F9EC.503AC026@anl.gov> <4032AFE7.6070501@zip.com.au> Message-ID: <40336EA7.9228A4FE@anl.gov> Darren Tucker wrote: > > Douglas E. Engert wrote: > > Attached is a modified version that will check for the gssapi.h > > and try to look in two places. This is similiar to the way it worked > > without the krb5-config. So it will work with or without an MIT fix > > in the future. > > [snip patch] > > That's more-or-less a copy of the existing gssapi.h header test inside > the "else" part of the "if krb5-config", right? Would it make more > sense to move the test outside of the "if" block rather than duplicate it? More or less, but the new code uses CPPFLAGS="$CPPFLAGS ${K5CFLAGS}/gssapi" Which uses the output of the krb5-config --cflag i.e. -I/some/location/include were as the original uses CPPFLAGS="$CPPFLAGS -I${KRB5ROOT}/include/gssapi" The $KRB5ROOT may not be the same location as the output of krb5-config. The extra check is only executed if gssapi is not found in the expected place, so when MIT fixes krb5-config so it finds the gssapi.h then the extra check could be eliminated, and the tests could be combined. > > -- > 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. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From dtucker at zip.com.au Thu Feb 19 10:25:04 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 19 Feb 2004 10:25:04 +1100 Subject: OpenSSH-snap-20040212 and the use of krb5-config In-Reply-To: <40336EA7.9228A4FE@anl.gov> References: <402D3932.A0CF44B4@anl.gov> <402DDA38.4020003@zip.com.au> <4030F9EC.503AC026@anl.gov> <4032AFE7.6070501@zip.com.au> <40336EA7.9228A4FE@anl.gov> Message-ID: <4033F450.5000806@zip.com.au> Douglas E. Engert wrote: > More or less, but the new code uses > CPPFLAGS="$CPPFLAGS ${K5CFLAGS}/gssapi" What guarantee is there that K5CFLAGS will contain only -I/path/to/includes?" What happens if it contains, eg, "-I/path/to/include -DSOME_FLAG"? > Which uses the output of the krb5-config --cflag i.e. -I/some/location/include > were as the original uses > CPPFLAGS="$CPPFLAGS -I${KRB5ROOT}/include/gssapi" > The $KRB5ROOT may not be the same location as the output of krb5-config. > > The extra check is only executed if gssapi is not found in the expected place, > so when MIT fixes krb5-config so it finds the gssapi.h then the > extra check could be eliminated, and the tests could be combined. -- 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 deengert at anl.gov Fri Feb 20 00:24:02 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Thu, 19 Feb 2004 07:24:02 -0600 Subject: OpenSSH-snap-20040212 and the use of krb5-config References: <402D3932.A0CF44B4@anl.gov> <402DDA38.4020003@zip.com.au> <4030F9EC.503AC026@anl.gov> <4032AFE7.6070501@zip.com.au> <40336EA7.9228A4FE@anl.gov> <4033F450.5000806@zip.com.au> Message-ID: <4034B8F2.75F03103@anl.gov> Darren Tucker wrote: > > Douglas E. Engert wrote: > > More or less, but the new code uses > > CPPFLAGS="$CPPFLAGS ${K5CFLAGS}/gssapi" > > What guarantee is there that K5CFLAGS will contain only > -I/path/to/includes?" What happens if it contains, eg, > "-I/path/to/include -DSOME_FLAG"? By the time MIT releases a new version of krb5-config, they should have gssapi.h in the path so the code in question to test for gssapi.h in the sub directory will not be executed. The Heimdal code (as I understand) does not have this problem, so does not execute this code. If they did changed the krb5-config to add some more flags, but did not fix the gssapi.h not in the path, this code would fail. But I believe that this is their bug, and they will fix it. This is bug 2240. This problem is a moving target, my patch was designed to work with past and future versions of krb5-config. > > > Which uses the output of the krb5-config --cflag i.e. -I/some/location/include > > were as the original uses > > CPPFLAGS="$CPPFLAGS -I${KRB5ROOT}/include/gssapi" > > The $KRB5ROOT may not be the same location as the output of krb5-config. > > > > The extra check is only executed if gssapi is not found in the expected place, > > so when MIT fixes krb5-config so it finds the gssapi.h then the > > extra check could be eliminated, and the tests could be combined. > > -- > 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. -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From thockin at sun.com Fri Feb 20 11:19:53 2004 From: thockin at sun.com (Tim Hockin) Date: Thu, 19 Feb 2004 16:19:53 -0800 Subject: NGROUPS_MAX on Linux Message-ID: <20040220001953.GF9155@sun.com> Linux has just raised the NGROUPS_MAX limit from 32 to 64k. In doing an audit of various tools, openssh turned up as having incorrect groups handling. Almost no user-space apps really care about NGROUPS_MAX. A proposed patch (untested, since the CVS build won't compile on my RH box.. :-/) : What think? Index: uidswap.c =================================================================== RCS file: /cvs/openssh/uidswap.c,v retrieving revision 1.42 diff -u -u -r1.42 uidswap.c --- uidswap.c 17 Dec 2003 07:53:26 -0000 1.42 +++ uidswap.c 19 Feb 2004 23:50:38 -0000 @@ -38,7 +38,7 @@ /* Saved effective uid. */ static int privileged = 0; static int temporarily_use_uid_effective = 0; -static gid_t saved_egroups[NGROUPS_MAX], user_groups[NGROUPS_MAX]; +static gid_t *saved_egroups, *user_groups; static int saved_egroupslen = -1, user_groupslen = -1; /* @@ -68,17 +68,27 @@ privileged = 1; temporarily_use_uid_effective = 1; - saved_egroupslen = getgroups(NGROUPS_MAX, saved_egroups); + + saved_egroupslen = getgroups(0, NULL); if (saved_egroupslen < 0) fatal("getgroups: %.100s", strerror(errno)); + saved_egroups = xrealloc(saved_egroups, + saved_egroupslen * sizeof(*saved_egroups)); + if (getgroups(saved_egroupslen, saved_egroups) < 0) + fatal("getgroups: %.100s", strerror(errno)); /* set and save the user's groups */ if (user_groupslen == -1) { if (initgroups(pw->pw_name, pw->pw_gid) < 0) fatal("initgroups: %s: %.100s", pw->pw_name, strerror(errno)); - user_groupslen = getgroups(NGROUPS_MAX, user_groups); + + user_groupslen = getgroups(0, NULL); if (user_groupslen < 0) + fatal("getgroups: %.100s", strerror(errno)); + user_groups = xrealloc(user_groups, + user_groupslena * sizeof(*user_groups)); + if (getgroups(user_groupslen, user_groups) < 0) fatal("getgroups: %.100s", strerror(errno)); } /* Set the effective uid to the given (unprivileged) uid. */ Index: groupaccess.c =================================================================== RCS file: /cvs/openssh/groupaccess.c,v retrieving revision 1.7 diff -u -u -r1.7 groupaccess.c --- groupaccess.c 14 May 2003 03:40:07 -0000 1.7 +++ groupaccess.c 19 Feb 2004 23:50:38 -0000 @@ -31,7 +31,7 @@ #include "log.h" static int ngroups; -static char *groups_byname[NGROUPS_MAX + 1]; /* +1 for base/primary group */ +static char **groups_byname; /* * Initialize group access list for user with primary (base) and @@ -40,20 +40,33 @@ int ga_init(const char *user, gid_t base) { - gid_t groups_bygid[NGROUPS_MAX + 1]; - int i, j; + gid_t *groups_bygid; + int i; struct group *gr; if (ngroups > 0) ga_free(); - ngroups = sizeof(groups_bygid) / sizeof(gid_t); + getgrouplist(user, base, NULL, &ngroups); + groups_bygid = xmalloc(ngroups * sizeof(*groups_bygid)); + groups_byname = xmalloc(ngroups * sizeof(*groups_byname)); + if (getgrouplist(user, base, groups_bygid, &ngroups) == -1) logit("getgrouplist: groups list too small"); - for (i = 0, j = 0; i < ngroups; i++) - if ((gr = getgrgid(groups_bygid[i])) != NULL) - groups_byname[j++] = xstrdup(gr->gr_name); - return (ngroups = j); + for (i = 0; i < ngroups; i++) { + if ((gr = getgrgid(groups_bygid[i])) != NULL) { + groups_byname[i] = xstrdup(gr->gr_name); + } else { + char gidstr[32]; + + logit("getgrgid: unknown group id: %d", + (int)groups_bygid[i]); + snprintf(gidstr, sizeof(gidstr), "%d", + (int)groups_bygid[i]); + groups_byname[i] = xstrdup(gidstr); + } + } + return ngroups; } /* @@ -84,5 +97,7 @@ for (i = 0; i < ngroups; i++) xfree(groups_byname[i]); ngroups = 0; + xfree(groups_byname); + xfree(groups_bygid); } } -- Tim Hockin Sun Microsystems, Linux Software Engineering thockin at sun.com All opinions are my own, not Sun's From dtucker at zip.com.au Fri Feb 20 11:35:29 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 20 Feb 2004 11:35:29 +1100 Subject: NGROUPS_MAX on Linux In-Reply-To: <20040220001953.GF9155@sun.com> References: <20040220001953.GF9155@sun.com> Message-ID: <40355651.1030502@zip.com.au> Tim Hockin wrote: > Linux has just raised the NGROUPS_MAX limit from 32 to 64k. In doing an > audit of various tools, openssh turned up as having incorrect groups > handling. Almost no user-space apps really care about NGROUPS_MAX. > > A proposed patch (untested, since the CVS build won't compile on my RH box.. > :-/) : This is an open bug: http://bugzilla.mindrot.org/show_bug.cgi?id=787 BTW, What's the build problem? It works for me (it gets tested automatically several times per day). -- 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 thockin at sun.com Fri Feb 20 11:47:18 2004 From: thockin at sun.com (Tim Hockin) Date: Thu, 19 Feb 2004 16:47:18 -0800 Subject: NGROUPS_MAX on Linux In-Reply-To: <40355651.1030502@zip.com.au> References: <20040220001953.GF9155@sun.com> <40355651.1030502@zip.com.au> Message-ID: <20040220004718.GJ9155@sun.com> On Fri, Feb 20, 2004 at 11:35:29AM +1100, Darren Tucker wrote: > Tim Hockin wrote: > >Linux has just raised the NGROUPS_MAX limit from 32 to 64k. In doing an > >audit of various tools, openssh turned up as having incorrect groups > >handling. Almost no user-space apps really care about NGROUPS_MAX. > > > >A proposed patch (untested, since the CVS build won't compile on my RH > >box.. > >:-/) : > > This is an open bug: > http://bugzilla.mindrot.org/show_bug.cgi?id=787 The proposed fixes are wrong. Even with sysconf() _SC_NGROUPS_MAX might be VERY large. I think my fix is righter. Can I add on to that bugzilla, or is it closed to the public? > BTW, What's the build problem? It works for me (it gets tested > automatically several times per day). Maybe I just don't know how to use the auto* tools. $ automake configure.ac:6: `automake requires `AM_CONFIG_HEADER', not `AC_CONFIG_HEADER' automake: configure.ac: `AM_INIT_AUTOMAKE' must be used automake: your implementation of AM_INIT_AUTOMAKE comes from an automake: old Automake version. You should recreate aclocal.m4 automake: with aclocal and run automake again. configure.ac: required file `./missing' not found automake: no `Makefile.am' found or specified From dtucker at zip.com.au Fri Feb 20 11:53:17 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 20 Feb 2004 11:53:17 +1100 Subject: NGROUPS_MAX on Linux In-Reply-To: <20040220004718.GJ9155@sun.com> References: <20040220001953.GF9155@sun.com> <40355651.1030502@zip.com.au> <20040220004718.GJ9155@sun.com> Message-ID: <40355A7D.40809@zip.com.au> Tim Hockin wrote: > On Fri, Feb 20, 2004 at 11:35:29AM +1100, Darren Tucker wrote: >>This is an open bug: >>http://bugzilla.mindrot.org/show_bug.cgi?id=787 > > The proposed fixes are wrong. Even with sysconf() _SC_NGROUPS_MAX might be > VERY large. I think my fix is righter. Can I add on to that bugzilla, or > is it closed to the public? Go right ahead, bugzilla is open to the public. You will have to register to get write access. >>BTW, What's the build problem? It works for me (it gets tested >>automatically several times per day). > > > Maybe I just don't know how to use the auto* tools. > > $ automake [snip] Try "autoconf" or "autoreconf" instead. -- 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 thockin at sun.com Fri Feb 20 13:17:04 2004 From: thockin at sun.com (Tim Hockin) Date: Thu, 19 Feb 2004 18:17:04 -0800 Subject: NGROUPS_MAX on Linux In-Reply-To: <40355A7D.40809@zip.com.au> References: <20040220001953.GF9155@sun.com> <40355651.1030502@zip.com.au> <20040220004718.GJ9155@sun.com> <40355A7D.40809@zip.com.au> Message-ID: <20040220021704.GM9155@sun.com> On Fri, Feb 20, 2004 at 11:53:17AM +1100, Darren Tucker wrote: > Go right ahead, bugzilla is open to the public. You will have to > register to get write access. Bug updated -- Tim Hockin Sun Microsystems, Linux Software Engineering thockin at sun.com All opinions are my own, not Sun's From mouring at etoh.eviladmin.org Fri Feb 20 14:16:56 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 19 Feb 2004 21:16:56 -0600 (CST) Subject: NGROUPS_MAX on Linux In-Reply-To: <20040220021704.GM9155@sun.com> Message-ID: Other than a few stylist things... It looks more correct than the other patch in bugzilla. Not done any compile tests, yet. - Ben On Thu, 19 Feb 2004, Tim Hockin wrote: > On Fri, Feb 20, 2004 at 11:53:17AM +1100, Darren Tucker wrote: > > Go right ahead, bugzilla is open to the public. You will have to > > register to get write access. > > Bug updated > > -- > Tim Hockin > Sun Microsystems, Linux Software Engineering > thockin at sun.com > All opinions are my own, not Sun's > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From dtucker at zip.com.au Fri Feb 20 14:36:18 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 20 Feb 2004 14:36:18 +1100 Subject: NGROUPS_MAX on Linux In-Reply-To: References: Message-ID: <403580B2.10900@zip.com.au> Ben Lindstrom wrote: > Other than a few stylist things... It looks more correct than the other > patch in bugzilla. Not done any compile tests, yet. I just added this to the bug but since I didn't know if Tim would see it: >diff -u -u -r1.42 uidswap.c >+ saved_egroups = xrealloc(saved_egroups, >+ saved_egroupslen * sizeof(*saved_egroups)); I get a fatal here during authentication: debug1: temporarily_use_uid: 500/500 (e=0/0) xrealloc: zero size -- 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 mouring at etoh.eviladmin.org Fri Feb 20 14:47:15 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 19 Feb 2004 21:47:15 -0600 (CST) Subject: NGROUPS_MAX on Linux In-Reply-To: <403580B2.10900@zip.com.au> Message-ID: On Fri, 20 Feb 2004, Darren Tucker wrote: > Ben Lindstrom wrote: > > Other than a few stylist things... It looks more correct than the other > > patch in bugzilla. Not done any compile tests, yet. > > I just added this to the bug but since I didn't know if Tim would see it: > > >diff -u -u -r1.42 uidswap.c > >+ saved_egroups = xrealloc(saved_egroups, > >+ saved_egroupslen * sizeof(*saved_egroups)); > I stared at that code for a while before I saw your message. I would have used sizeof(gid_t *) myself, but I was unsure if it was anything major. > I get a fatal here during authentication: > debug1: temporarily_use_uid: 500/500 (e=0/0) > xrealloc: zero size > What is the value of saved_egroupslen? - Ben From dtucker at zip.com.au Fri Feb 20 14:57:04 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 20 Feb 2004 14:57:04 +1100 Subject: NGROUPS_MAX on Linux In-Reply-To: References: Message-ID: <40358590.6020707@zip.com.au> Ben Lindstrom wrote: > On Fri, 20 Feb 2004, Darren Tucker wrote: >> >diff -u -u -r1.42 uidswap.c >> >+ saved_egroups = xrealloc(saved_egroups, >> >+ saved_egroupslen * sizeof(*saved_egroups)); > > I stared at that code for a while before I saw your message. I would have > used sizeof(gid_t *) myself, but I was unsure if it was anything major. I think it's fine, the issue is on my system, the master sshd daemon (started via sudo) is running with no supplemental gids... >>I get a fatal here during authentication: >>debug1: temporarily_use_uid: 500/500 (e=0/0) >>xrealloc: zero size > > What is the value of saved_egroupslen? zero. (gdb) bt #0 0x401a6da1 in kill () from /lib/libc.so.6 #1 0x401a6b6c in raise () from /lib/libc.so.6 #2 0x401a7d95 in abort () from /lib/libc.so.6 #3 0x08067c15 in fatal (fmt=0x80807e3 "xrealloc: zero size") at ../fatal.c:39 #4 0x0806cdd5 in xrealloc (ptr=0x0, new_size=0) at ../xmalloc.c:40 #5 0x0805313f in temporarily_use_uid (pw=0x0) at ../uidswap.c:76 #6 0x08059bc8 in user_key_allowed2 (pw=0x808ba10, key=0x8094740, file=0x80958c0 "/home/dtucker/.ssh/authorized_keys") at ../auth2-pubkey.c:179 #7 0x08059f29 in user_key_allowed (pw=0x808ba10, key=0x8094740) at ../auth2-pubkey.c:264 #8 0x0805ba49 in mm_answer_keyallowed (socket=9, m=0xbfffe9c0) at ../monitor.c:955 #9 0x0805b0ba in monitor_read (pmonitor=0x808dbc8, ent=0x8083ea8, pent=0xbfffea08) at ../monitor.c:414 #10 0x0805add6 in monitor_child_preauth (_authctxt=0xbfffea08, pmonitor=0x808dbc8) at ../monitor.c:302 #11 0x0804c91f in privsep_preauth (authctxt=0x808dcf8) at ../sshd.c:600 #12 0x0804d800 in main (ac=134798232, av=0x808dd28) at ../sshd.c:1473 #13 0x4019562d in __libc_start_main () from /lib/libc.so.6 (gdb) frame 5 #5 0x0805313f in temporarily_use_uid (pw=0x0) at ../uidswap.c:76 76 saved_egroups = xrealloc(saved_egroups, (gdb) print saved_egroupslen $1 = 0 -- 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 raysonho at eseenet.com Fri Feb 20 15:55:46 2004 From: raysonho at eseenet.com (Rayson Ho) Date: Thu, 19 Feb 2004 20:55:46 PST Subject: GridEngine-OpenSSH integration Message-ID: <40359352.2c4e.0@eseenet.com> Hi, GridEngine (http://gridengine.sunsource.net, aka. SGE) is an opensource batch system for clusters. They have an integration with SSH: http://gridengine.sunsource.net/project/gridengine/howto/qrsh_ssh.html The idea is that instead of using a modified rsh/rshd, they wanted to OpenSSH. However, in order to provide full job control, they need to add a few hooks in OpenSSH. Question: - Is it OK to add code in the offical cvs source that for non SGE users, it is not compiled in, but when configured with SGE, it provides the hooks?? Rayson --------------------------------------------------------- Get your FREE E-mail account at http://www.eseenet.com ! From mouring at etoh.eviladmin.org Fri Feb 20 16:29:49 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 19 Feb 2004 23:29:49 -0600 (CST) Subject: GridEngine-OpenSSH integration In-Reply-To: <40359352.2c4e.0@eseenet.com> Message-ID: On Thu, 19 Feb 2004, Rayson Ho wrote: > Hi, > > GridEngine (http://gridengine.sunsource.net, aka. SGE) is an opensource > batch system for clusters. They have an integration with SSH: > > http://gridengine.sunsource.net/project/gridengine/howto/qrsh_ssh.html > > The idea is that instead of using a modified rsh/rshd, they wanted to > OpenSSH. However, in order to provide full job control, they need to add a > few hooks in OpenSSH. Question: > > - Is it OK to add code in the offical cvs source that for non SGE users, it > is not compiled in, but when configured with SGE, it provides the hooks?? > I suspect the answer is "no"... However, without a clue as to what is being proposed it is impossible to know. - Ben From raysonho at eseenet.com Fri Feb 20 16:49:24 2004 From: raysonho at eseenet.com (Rayson Ho) Date: Thu, 19 Feb 2004 21:49:24 PST Subject: GridEngine-OpenSSH integration Message-ID: <40359fe4.33bd.0@eseenet.com> http://gridengine.sunsource.net/servlets/ReadMsg?msgId=9473&listName=dev (the part that Joachim's replied) They need to add: - code to read their config file - code to attach an additional gid to the sshd's process. They have those in their library, so the above changes should be around 20-30 lines. Rayson > However, without a clue as to what is > being proposed it is impossible to know. > >- Ben > > --------------------------------------------------------- Get your FREE E-mail account at http://www.eseenet.com ! From djm at mindrot.org Fri Feb 20 16:50:48 2004 From: djm at mindrot.org (Damien Miller) Date: Fri, 20 Feb 2004 16:50:48 +1100 Subject: GridEngine-OpenSSH integration In-Reply-To: <40359352.2c4e.0@eseenet.com> References: <40359352.2c4e.0@eseenet.com> Message-ID: <4035A038.7080905@mindrot.org> Rayson Ho wrote: > Hi, > > GridEngine (http://gridengine.sunsource.net, aka. SGE) is an opensource > batch system for clusters. They have an integration with SSH: > > http://gridengine.sunsource.net/project/gridengine/howto/qrsh_ssh.html > > The idea is that instead of using a modified rsh/rshd, they wanted to > OpenSSH. However, in order to provide full job control, they need to add a > few hooks in OpenSSH. What additional features do they need beyond signal transmission? -d From djm at mindrot.org Fri Feb 20 16:58:56 2004 From: djm at mindrot.org (Damien Miller) Date: Fri, 20 Feb 2004 16:58:56 +1100 Subject: GridEngine-OpenSSH integration In-Reply-To: <40359fe4.33bd.0@eseenet.com> References: <40359fe4.33bd.0@eseenet.com> Message-ID: <4035A220.2080406@mindrot.org> Rayson Ho wrote: > http://gridengine.sunsource.net/servlets/ReadMsg?msgId=9473&listName=dev > > (the part that Joachim's replied) > > They need to add: > > - code to read their config file > - code to attach an additional gid to the sshd's process. > > They have those in their library, so the above changes should be around > 20-30 lines. I someone could attach these to a Bugzilla bug (http://bugzilla.mindrot.org) with the changes as a unified diff, then we could review and discuss them. -d From raysonho at eseenet.com Fri Feb 20 17:03:25 2004 From: raysonho at eseenet.com (Rayson Ho) Date: Thu, 19 Feb 2004 22:03:25 PST Subject: GridEngine-OpenSSH integration Message-ID: <4035a32d.35b4.0@eseenet.com> http://gridengine.sunsource.net/servlets/ReadMsg?msgId=15891&listName=users They also need "online usage, resource control by execd"... Without the hooks, with the current OpenSSH integration: (copied from their HOWTO) - lack of complete accounting - lack of process control (reprioritization) Reprioritization -> the nice level of the job changes depending on how many "shares" the job owner has. The shares is calculated in realtime. Rayson >What additional features do they need beyond signal transmission? > >-d --------------------------------------------------------- Get your FREE E-mail account at http://www.eseenet.com ! From thockin at sun.com Fri Feb 20 17:29:47 2004 From: thockin at sun.com (Tim Hockin) Date: Thu, 19 Feb 2004 22:29:47 -0800 Subject: NGROUPS_MAX on Linux In-Reply-To: <403580B2.10900@zip.com.au> References: <403580B2.10900@zip.com.au> Message-ID: <20040220062947.GO9155@sun.com> On Fri, Feb 20, 2004 at 02:36:18PM +1100, Darren Tucker wrote: > Ben Lindstrom wrote: > >Other than a few stylist things... It looks more correct than the other > >patch in bugzilla. Not done any compile tests, yet. > > I just added this to the bug but since I didn't know if Tim would see it: > > >diff -u -u -r1.42 uidswap.c > >+ saved_egroups = xrealloc(saved_egroups, > >+ saved_egroupslen * sizeof(*saved_egroups)); > > I get a fatal here during authentication: > debug1: temporarily_use_uid: 500/500 (e=0/0) > xrealloc: zero size hrrm, simple enough to test for, I guess. if (saved_egroupslen > 0) ... I don't have an answer for why getgrouplist() with a 1 element 'fake' array barfs on Linux, either. -- Tim Hockin Sun Microsystems, Linux Software Engineering thockin at sun.com All opinions are my own, not Sun's From dtucker at zip.com.au Fri Feb 20 17:58:54 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 20 Feb 2004 17:58:54 +1100 Subject: NGROUPS_MAX on Linux In-Reply-To: <20040220062947.GO9155@sun.com> References: <403580B2.10900@zip.com.au> <20040220062947.GO9155@sun.com> Message-ID: <4035B02E.4040309@zip.com.au> Tim Hockin wrote: > I don't have an answer for why getgrouplist() with a 1 element 'fake' array > barfs on Linux, either. Seems to work OK here (RH9, current patches). Can you get a backtrace? -- 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 jag at techma.com Fri Feb 20 18:06:55 2004 From: jag at techma.com (John A Grahor) Date: Fri, 20 Feb 2004 02:06:55 -0500 Subject: ssh client auto rekey feature. Message-ID: <000501c3f780$205bfd80$cd6b16cf@cts.zai.com> I plan to use ssh as the secure transport of a VPN. (Yes I know there are other solutions but...) These tunnels may be up for a long time, days or weeks, and escape characters will be turned off because I'll be passing binary data so I can't force a rekey with that method. Since the ssh spec says one should rekey every hour, I plan to patch the ssh client to implement an auto-rekey option. Do any of the security/cipher gurus have any problem with automatically rekeying the connection at a specific interval. For simplicity's sake I just plan to implement a simple timer that goes off every user-specified-interval and rekeys the connection. If the developers are interested, I'll send the patch along when I'm done. Thanks, John From djm at mindrot.org Fri Feb 20 19:09:16 2004 From: djm at mindrot.org (Damien Miller) Date: Fri, 20 Feb 2004 19:09:16 +1100 (EST) Subject: ssh client auto rekey feature. In-Reply-To: <000501c3f780$205bfd80$cd6b16cf@cts.zai.com> References: <000501c3f780$205bfd80$cd6b16cf@cts.zai.com> Message-ID: On Fri, 20 Feb 2004, John A Grahor wrote: > Since the ssh spec says one should rekey every hour, I plan to patch the ssh > client to implement an auto-rekey option. We already auto-rekey, though I think it is based on data volume rather than time. I'll make a patch to enable time-based rekeying. You can set ReKeyLimit in ssh_config to control this. (This needs an entry in ssh_config). -d From djm at mindrot.org Fri Feb 20 19:29:00 2004 From: djm at mindrot.org (Damien Miller) Date: Fri, 20 Feb 2004 19:29:00 +1100 (EST) Subject: ssh client auto rekey feature. In-Reply-To: References: <000501c3f780$205bfd80$cd6b16cf@cts.zai.com> Message-ID: On Fri, 20 Feb 2004, Damien Miller wrote: > On Fri, 20 Feb 2004, John A Grahor wrote: > > > Since the ssh spec says one should rekey every hour, I plan to patch the ssh > > client to implement an auto-rekey option. > > We already auto-rekey, though I think it is based on data volume rather > than time. I'll make a patch to enable time-based rekeying. As promised. A couple of notes: - This deprecates the unadvertised RekeyLimit client configuation option, in favour of RekeyTimeLimit and RekeyDataLimit options (and it documents them) - Time-based rekeying won't actually happen until there is data to send over the connection. If this bothers you, just set ServerAliveInterval BTW I think the draft-ietf-secsh-transport recommended interval for time-based rekeying of 1 hour is complete overkill. -d Index: packet.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/packet.c,v retrieving revision 1.112 diff -u -r1.112 packet.c --- packet.c 23 Sep 2003 20:17:11 -0000 1.112 +++ packet.c 20 Feb 2004 08:26:18 -0000 @@ -125,7 +125,9 @@ } p_read, p_send; static u_int64_t max_blocks_in, max_blocks_out; -static u_int32_t rekey_limit; +static time_t rekey_time; +static time_t rekey_time_limit = 0; +static u_int32_t rekey_data_limit = 0; /* Session key for protocol v1 */ static u_char ssh1_key[SSH_SESSION_KEY_LENGTH]; @@ -636,8 +638,10 @@ *max_blocks = (u_int64_t)1 << (enc->block_size*2); else *max_blocks = ((u_int64_t)1 << 30) / enc->block_size; - if (rekey_limit) - *max_blocks = MIN(*max_blocks, rekey_limit / enc->block_size); + if (rekey_data_limit) + *max_blocks = MIN(*max_blocks, rekey_data_limit / enc->block_size); + + rekey_time = time(NULL); } /* @@ -1505,11 +1509,18 @@ (p_send.packets > MAX_PACKETS) || (p_read.packets > MAX_PACKETS) || (max_blocks_out && (p_send.blocks > max_blocks_out)) || - (max_blocks_in && (p_read.blocks > max_blocks_in)); + (max_blocks_in && (p_read.blocks > max_blocks_in)) || + (rekey_time_limit && (time(NULL) - rekey_time > rekey_time_limit)); +} + +void +packet_set_rekey_data_limit(u_int32_t bytes) +{ + rekey_data_limit = bytes; } void -packet_set_rekey_limit(u_int32_t bytes) +packet_set_rekey_time_limit(time_t seconds) { - rekey_limit = bytes; + rekey_time_limit = seconds; } Index: packet.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/packet.h,v retrieving revision 1.40 diff -u -r1.40 packet.h --- packet.h 24 Jun 2003 08:23:46 -0000 1.40 +++ packet.h 20 Feb 2004 08:26:18 -0000 @@ -97,6 +97,7 @@ } while (0) int packet_need_rekeying(void); -void packet_set_rekey_limit(u_int32_t); +void packet_set_rekey_data_limit(u_int32_t); +void packet_set_rekey_time_limit(time_t); #endif /* PACKET_H */ Index: readconf.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/readconf.c,v retrieving revision 1.127 diff -u -r1.127 readconf.c --- readconf.c 16 Dec 2003 15:49:51 -0000 1.127 +++ readconf.c 20 Feb 2004 08:26:19 -0000 @@ -103,9 +103,10 @@ oDynamicForward, oPreferredAuthentications, oHostbasedAuthentication, oHostKeyAlgorithms, oBindAddress, oSmartcardDevice, oClearAllForwardings, oNoHostAuthenticationForLocalhost, - oEnableSSHKeysign, oRekeyLimit, oVerifyHostKeyDNS, oConnectTimeout, - oAddressFamily, oGssAuthentication, oGssDelegateCreds, - oServerAliveInterval, oServerAliveCountMax, + oEnableSSHKeysign, oRekeyDataLimit, oRekeyTimeLimit, + oVerifyHostKeyDNS, oConnectTimeout, oAddressFamily, + oGssAuthentication, oGssDelegateCreds, oServerAliveInterval, + oServerAliveCountMax, oDeprecated, oUnsupported } OpCodes; @@ -187,7 +188,9 @@ { "enablesshkeysign", oEnableSSHKeysign }, { "verifyhostkeydns", oVerifyHostKeyDNS }, { "nohostauthenticationforlocalhost", oNoHostAuthenticationForLocalhost }, - { "rekeylimit", oRekeyLimit }, + { "rekeylimit", oDeprecated }, + { "rekeydatalimit", oRekeyDataLimit }, + { "rekeytimelimit", oRekeyTimeLimit }, { "connecttimeout", oConnectTimeout }, { "addressfamily", oAddressFamily }, { "serveraliveinterval", oServerAliveInterval }, @@ -445,8 +448,8 @@ intptr = &options->compression_level; goto parse_int; - case oRekeyLimit: - intptr = &options->rekey_limit; + case oRekeyDataLimit: + intptr = &options->rekey_data_limit; arg = strdelim(&s); if (!arg || *arg == '\0') fatal("%.200s line %d: Missing argument.", filename, linenum); @@ -470,6 +473,11 @@ *intptr = value; break; + case oRekeyTimeLimit: + intptr = &options->rekey_time_limit; + goto parse_time; + break; + case oIdentityFile: arg = strdelim(&s); if (!arg || *arg == '\0') @@ -867,7 +875,8 @@ options->smartcard_device = NULL; options->enable_ssh_keysign = - 1; options->no_host_authentication_for_localhost = - 1; - options->rekey_limit = - 1; + options->rekey_data_limit = - 1; + options->rekey_time_limit = - 1; options->verify_host_key_dns = -1; options->server_alive_interval = -1; options->server_alive_count_max = -1; @@ -981,8 +990,10 @@ options->no_host_authentication_for_localhost = 0; if (options->enable_ssh_keysign == -1) options->enable_ssh_keysign = 0; - if (options->rekey_limit == -1) - options->rekey_limit = 0; + if (options->rekey_data_limit == -1) + options->rekey_data_limit = 0; + if (options->rekey_time_limit == -1) + options->rekey_time_limit = 0; if (options->verify_host_key_dns == -1) options->verify_host_key_dns = 0; if (options->server_alive_interval == -1) Index: readconf.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/readconf.h,v retrieving revision 1.59 diff -u -r1.59 readconf.h --- readconf.h 16 Dec 2003 15:49:51 -0000 1.59 +++ readconf.h 20 Feb 2004 08:26:20 -0000 @@ -98,7 +98,8 @@ int clear_forwardings; int enable_ssh_keysign; - int rekey_limit; + int rekey_data_limit; + int rekey_time_limit; int no_host_authentication_for_localhost; int server_alive_interval; int server_alive_count_max; Index: ssh_config.5 =================================================================== RCS file: /cvs/src/usr.bin/ssh/ssh_config.5,v retrieving revision 1.28 diff -u -r1.28 ssh_config.5 --- ssh_config.5 16 Dec 2003 15:49:51 -0000 1.28 +++ ssh_config.5 20 Feb 2004 08:26:21 -0000 @@ -518,6 +518,13 @@ The default is .Dq yes . This option applies to protocol version 2 only. +.It Cm RekeyDataLimit +Specifies the number of maximum number of bytes transmitted or received +before the session encryption keys are renewed. +This option applies to protocol version 2 only. +.It Cm RekeyTimeLimit +Specifies the interval at which session encryption keys are renewed. +This option applies to protocol version 2 only. .It Cm RemoteForward Specifies that a TCP/IP port on the remote machine be forwarded over the secure channel to the specified host and port from the local machine. Index: sshconnect2.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/sshconnect2.c,v retrieving revision 1.134 diff -u -r1.134 sshconnect2.c --- sshconnect2.c 19 Jan 2004 21:25:15 -0000 1.134 +++ sshconnect2.c 20 Feb 2004 08:26:22 -0000 @@ -112,8 +112,10 @@ myproposal[PROPOSAL_SERVER_HOST_KEY_ALGS] = options.hostkeyalgorithms; - if (options.rekey_limit) - packet_set_rekey_limit(options.rekey_limit); + if (options.rekey_data_limit) + packet_set_rekey_data_limit(options.rekey_data_limit); + if (options.rekey_time_limit) + packet_set_rekey_time_limit(options.rekey_time_limit); /* start key exchange */ kex = kex_setup(myproposal); From lam.felix at bell.ca Sat Feb 21 04:22:26 2004 From: lam.felix at bell.ca (LAM, FELIX) Date: Fri, 20 Feb 2004 12:22:26 -0500 Subject: AIX reboot problem after SSH is installed Message-ID: <40364252.A1151431@bell.ca> Hi, I've installed OpenSSH 3.7.1 on AIX. After I've installed it, when I try to reboot the machine using shutdown -Fr command remotely, it doesn't reboot at all, and it hangs. If I'm doing it from its terminal (ie not thru ssh to the remote machine), the machine will reboot. Do you know how to fix this problem? Thanks in advance! Regards, Felix From john at repetae.net Sat Feb 21 11:40:47 2004 From: john at repetae.net (John Meacham) Date: Fri, 20 Feb 2004 16:40:47 -0800 Subject: a story of compromise and an idea Message-ID: <20040221004047.GC16466@momenergy.repetae.net> There is a cluster of machines which I have an account on which was recently compromised. the machines have thousands of users and the only access is via ssh. via some mechanism (probably a weak password) the attacker was able to compromise a single account and use a local-root exploit to hijack lots of ssh-agents and any unpassword protected keys. they next tried to repeat the process for every machine in the 'known_hosts' file for each compromised account. of course, all this was automated and they quickly built a nice spanning tree of cracked machines. (fortunately, I was paranoid enough to avoid being hit, but many others weren't). I was thinking that it would be a useful option to store a hash of the host/ip in known_hosts rather than the host/ip in plaintext so that there is not an immediate list of candidate machines to crack once an account is compromised. in the case of possible key-compromise, anything that slows down the attack long enough for you to hear about it and re-key is a good thing. Plus, as a privacy thing, one might not want a list of the machines they connect to so obviously logged. One might argue that this is security via obscurity, but a list of other machines you connect to and probably use the same ssh key or password on is real and very useful information to a cracker, and the idea is to slow down an automated attack long enough to avoid logging into the affected machine and rekey your other accounts before they find you. It should be an option, since some people use their known_hosts as a source of information for things like zsh completion, but for the extra-paranoid or privacy conscious I think it would be a very practical and simple change. please respond to both me and the list as I am not subscribed. John -- --------------------------------------------------------------------------- John Meacham - California Institute of Technology, Alum. - john at foo.net --------------------------------------------------------------------------- From dtucker at zip.com.au Sat Feb 21 12:26:41 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 21 Feb 2004 12:26:41 +1100 Subject: AIX reboot problem after SSH is installed In-Reply-To: <40364252.A1151431@bell.ca> References: <40364252.A1151431@bell.ca> Message-ID: <4036B3D1.3060809@zip.com.au> LAM, FELIX wrote: > I've installed OpenSSH 3.7.1 on AIX. Which version and an ML of AIX? > After I've installed it, when I > try to reboot the machine using shutdown -Fr command remotely, it > doesn't reboot at all, and it hangs. If I'm doing it from its terminal > (ie not thru ssh to the remote machine), the machine will reboot. Do > you know how to fix this problem? Thanks in advance! What output do you get in the SSH session before it hangs? Does it reboot if you disconnect the SSH session when it hangs? (ie hit CR ~ .) -- 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 mouring at etoh.eviladmin.org Sat Feb 21 17:54:50 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sat, 21 Feb 2004 00:54:50 -0600 (CST) Subject: a story of compromise and an idea In-Reply-To: <20040221004047.GC16466@momenergy.repetae.net> Message-ID: On Fri, 20 Feb 2004, John Meacham wrote: [..] > > I was thinking that it would be a useful option to store a hash of the > host/ip in known_hosts rather than the host/ip in plaintext so that > there is not an immediate list of candidate machines to crack once an > account is compromised. in the case of possible key-compromise, anything > that slows down the attack long enough for you to hear about it and > re-key is a good thing. Plus, as a privacy thing, one might not want a > list of the machines they connect to so obviously logged. > Sure there is.. commandline history and last login history. Both can be checked automaticly. None of which are affected by having some hashed known_host file and at least one is OUT of your control. To say nothing about existing sessions that are active. - Ben From djm at mindrot.org Sat Feb 21 18:23:50 2004 From: djm at mindrot.org (Damien Miller) Date: Sat, 21 Feb 2004 18:23:50 +1100 (EST) Subject: a story of compromise and an idea In-Reply-To: <20040221004047.GC16466@momenergy.repetae.net> References: <20040221004047.GC16466@momenergy.repetae.net> Message-ID: On Fri, 20 Feb 2004, John Meacham wrote: > I was thinking that it would be a useful option to store a hash of the > host/ip in known_hosts rather than the host/ip in plaintext so that > there is not an immediate list of candidate machines to crack once an > account is compromised. in the case of possible key-compromise, anything > that slows down the attack long enough for you to hear about it and > re-key is a good thing. Plus, as a privacy thing, one might not want a > list of the machines they connect to so obviously logged. I don't think that this would by you much - if an attacker has root on a machine, they can trawl lastlog, shell history files, netstat and ps to find this information pretty quickly. I'd instead recommend that you encourage the use of the "ssh-add -c" option for users. If they aren't running the agent on the compromised machine itself, then they should notice unauthorised use of the agent and out-of-hours key theft would be impossible. -d From mikulas at artax.karlin.mff.cuni.cz Sun Feb 22 10:02:45 2004 From: mikulas at artax.karlin.mff.cuni.cz (Mikulas Patocka) Date: Sun, 22 Feb 2004 00:02:45 +0100 (CET) Subject: overflow in buffer_put_bignum2 Message-ID: Hi When buffer_put_bugnum2 is called with zero bignum, it touches unallocated memory: BN_num_bytes returns 0, one byte is allocated and hasnohigh = (buf[1] & 0x80) ? 0 : 1; touches array out of bounds. Mikulas From ed at overminder.com Sun Feb 22 10:14:48 2004 From: ed at overminder.com (Ed White) Date: Sun, 22 Feb 2004 00:14:48 +0100 Subject: Key exchange Message-ID: <200402220014.48768.ed@overminder.com> Hi, I would like to know the order used by OpenSSH to choose the key exchange algorithm. I've used Ethereal to sniff a complete connection between my FreeBSD workstation and my OpenBSD laptop. I found that ssh used Diffie-Hellman. Why ? How can I use RSA or DSA keys created during the first boot by /etc/rc ? Please note that I'm not asking how to use keys to access a box, but how to choose a different algorithm to manage the key exchange process and protect my password on the wire... Thanks. Ed From djm at mindrot.org Sun Feb 22 22:33:47 2004 From: djm at mindrot.org (Damien Miller) Date: Sun, 22 Feb 2004 22:33:47 +1100 (EST) Subject: Key exchange In-Reply-To: <200402220014.48768.ed@overminder.com> References: <200402220014.48768.ed@overminder.com> Message-ID: On Sun, 22 Feb 2004, Ed White wrote: > Hi, > > I would like to know the order used by OpenSSH to choose the key exchange > algorithm. > > I've used Ethereal to sniff a complete connection between my FreeBSD > workstation and my OpenBSD laptop. I found that ssh used Diffie-Hellman. > Why ? > > How can I use RSA or DSA keys created during the first boot by /etc/rc ? I think you need to read the protocol spec: http://www.openssh.com/txt/draft-ietf-secsh-connect-15.txt -d From markus at openbsd.org Sun Feb 22 23:28:34 2004 From: markus at openbsd.org (Markus Friedl) Date: Sun, 22 Feb 2004 13:28:34 +0100 Subject: Key exchange In-Reply-To: <200402220014.48768.ed@overminder.com> References: <200402220014.48768.ed@overminder.com> Message-ID: <20040222122833.GB10047@folly> On Sun, Feb 22, 2004 at 12:14:48AM +0100, Ed White wrote: > I've used Ethereal to sniff a complete connection between my FreeBSD > workstation and my OpenBSD laptop. I found that ssh used Diffie-Hellman. > Why ? this is how ssh works. > How can I use RSA or DSA keys created during the first boot by /etc/rc ? they are. From janfrode at parallab.uib.no Mon Feb 23 00:32:30 2004 From: janfrode at parallab.uib.no (Jan-Frode Myklebust) Date: Sun, 22 Feb 2004 14:32:30 +0100 Subject: AIX reboot problem after SSH is installed In-Reply-To: <40364252.A1151431@bell.ca> References: <40364252.A1151431@bell.ca> Message-ID: <20040222133230.GA2222@ii.uib.no> On Fri, Feb 20, 2004 at 12:22:26PM -0500, LAM, FELIX wrote: > > I've installed OpenSSH 3.7.1 on AIX. After I've installed it, when I > try to reboot the machine using shutdown -Fr command remotely, it > doesn't reboot at all, and it hangs. I think I've seen this also.. What I do is to ssh as root into the box, then manually start bash as the shell. If I do 'shutdown -Fr' from within bash, the shutdown doesn't complete. If I exit bash, and start the shutdown from roots default korn shell, the shutdown works fine. So, my guess has been that shutdown kills bash and that that somehow blocks/signals shutdown. Maybe your problem is something similar? BTW: AIX 5.2 ml1 and AIX 5.1 ml5. -jf From binder at arago.de Mon Feb 23 09:24:30 2004 From: binder at arago.de (Thomas Binder) Date: Sun, 22 Feb 2004 23:24:30 +0100 Subject: AIX reboot problem after SSH is installed In-Reply-To: <40364252.A1151431@bell.ca> References: <40364252.A1151431@bell.ca> Message-ID: <20040222222429.GA13398717@ohm.arago.de> Hi! On Fri, Feb 20, 2004 at 12:22:26PM -0500, LAM, FELIX wrote: > I've installed OpenSSH 3.7.1 on AIX. After I've installed it, > when I try to reboot the machine using shutdown -Fr command > remotely, it doesn't reboot at all, and it hangs. Does exec shutdown -Fr make any difference? Ciao Thomas From andy.tompkins at autozone.com Tue Feb 24 01:46:39 2004 From: andy.tompkins at autozone.com (andy.tompkins at autozone.com) Date: Mon, 23 Feb 2004 08:46:39 -0600 Subject: AIX reboot problem after SSH is installed Message-ID: AIX is just weird like that... Try: echo "shutdown -Fr"|at now Andy ------------------------------------------------------------------------ The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. From lists1 at sonous.com Tue Feb 24 05:36:28 2004 From: lists1 at sonous.com (Lev Lvovsky) Date: Mon, 23 Feb 2004 10:36:28 -0800 Subject: ssh + ldap issues Message-ID: <3134C2CD-662F-11D8-868C-000A959DCC8C@sonous.com> In an effort to install cfengine (which requires 0.96b + of ssl), we've had to recompile all sorts of related packages on our RedHat 6.2 boxes. In addition, we're trying to implement an LDAP directory. Basically the source RPMS for RedHat 7.3 were installed and compiled on a 6.2 box to get this all to work. We're running into the following problem on the 6.2 boxes after having compiled/installed openssh-3.7.1p2 with the spec file in the contrib directory. Upon attempting to use an LDAP username with ssh, ssh, we get the following output in the logfile: ------ Feb 23 18:32:36 tsthvy1-did1 modprobe: modprobe: Can't locate module net-pf-10 Feb 23 18:32:40 tsthvy1-did1 sshd: PAM unable to dlopen(/lib/security/pam_ldap.so) Feb 23 18:32:40 tsthvy1-did1 sshd: PAM [dlerror: /lib/security/pam_ldap.so: symbol gethostbyname_r, version GLIBC_2.1.2 not defined in file libc.so.6 with link time reference] Feb 23 18:32:40 tsthvy1-did1 sshd: PAM adding faulty module: /lib/security/pam_ldap.so Feb 23 18:32:42 tsthvy1-did1 sshd(pam_unix)[17825]: check pass; user unknown Feb 23 18:32:42 tsthvy1-did1 sshd(pam_unix)[17825]: authentication failure; logname=root uid=0 euid=0 tty=ssh ruser= rhost=login-server ------ The above-referenced file pam_ldap.so does exist. All other LDAP related applications (su, ldapsearch, etc...) work, and are able to authenticate the user. Not sure if any more info is necessary to diagnose the problem, but any help would be appreciated. thanks, -lev From dtucker at zip.com.au Tue Feb 24 08:32:41 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 24 Feb 2004 08:32:41 +1100 Subject: AIX reboot problem after SSH is installed In-Reply-To: References: Message-ID: <403A7179.2000904@zip.com.au> andy.tompkins at autozone.com wrote: > AIX is just weird like that... AIX's shutdown command has some special behaviour to not terminate itself or any of its parent processes. Perhaps it's getting confused? I think it's a shell script, you can run it with "sh -x /sbin/shutdown" and see what it's doing... -- 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 lev at sonous.com Tue Feb 24 08:35:12 2004 From: lev at sonous.com (Lev Lvovsky) Date: Mon, 23 Feb 2004 13:35:12 -0800 Subject: ssh + ldap issues In-Reply-To: <3134C2CD-662F-11D8-868C-000A959DCC8C@sonous.com> References: <3134C2CD-662F-11D8-868C-000A959DCC8C@sonous.com> Message-ID: <2951A94B-6648-11D8-868C-000A959DCC8C@sonous.com> replying to my own post - please disregard the initial request - there were two packages providing pam_ldap.so, installing only the correct one fixed the problem thanks, -lev On Feb 23, 2004, at 10:36 AM, Lev Lvovsky wrote: > In an effort to install cfengine (which requires 0.96b + of ssl), > we've had to recompile all sorts of related packages on our RedHat 6.2 > boxes. In addition, we're trying to implement an LDAP directory. > Basically the source RPMS for RedHat 7.3 were installed and compiled > on a 6.2 box to get this all to work. > > We're running into the following problem on the 6.2 boxes after having > compiled/installed openssh-3.7.1p2 with the spec file in the contrib > directory. Upon attempting to use an LDAP username with ssh, ssh, we > get the following output in the logfile: > > ------ > Feb 23 18:32:36 tsthvy1-did1 modprobe: modprobe: Can't locate module > net-pf-10 > Feb 23 18:32:40 tsthvy1-did1 sshd: PAM unable to > dlopen(/lib/security/pam_ldap.so) > Feb 23 18:32:40 tsthvy1-did1 sshd: PAM [dlerror: > /lib/security/pam_ldap.so: symbol gethostbyname_r, version GLIBC_2.1.2 > not defined in file libc.so.6 with link time reference] > Feb 23 18:32:40 tsthvy1-did1 sshd: PAM adding faulty module: > /lib/security/pam_ldap.so > Feb 23 18:32:42 tsthvy1-did1 sshd(pam_unix)[17825]: check pass; user > unknown > Feb 23 18:32:42 tsthvy1-did1 sshd(pam_unix)[17825]: authentication > failure; logname=root uid=0 euid=0 tty=ssh ruser= rhost=login-server > ------ > > The above-referenced file pam_ldap.so does exist. All other LDAP > related applications (su, ldapsearch, etc...) work, and are able to > authenticate the user. > > Not sure if any more info is necessary to diagnose the problem, but > any help would be appreciated. > > thanks, > -lev > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From gss+ssh at cs.brown.edu Tue Feb 24 09:23:08 2004 From: gss+ssh at cs.brown.edu (Gregory Seidman) Date: Mon, 23 Feb 2004 17:23:08 -0500 Subject: PKI and SSH Message-ID: <20040223222308.GA10422@cs.brown.edu> Due to unpleasant (but arguably valid) policy changes at work, any SSH server within the work firewall must accept only PKI authentication. Unless we can convince the higher-ups otherwise, we will also have to use the commercial SSH server within the firewall. Of course, I should be able to use whatever client I like. Unfortunately, it is not clear that I can get OpenSSH to use PKI authentication. A bit of googling turns up a patch, but nothing too certain or clear. Does OpenSSH support PKI authentication? If so, how do I use it? --Greg From lam.felix at bell.ca Tue Feb 24 09:32:42 2004 From: lam.felix at bell.ca (LAM, FELIX) Date: Mon, 23 Feb 2004 17:32:42 -0500 Subject: AIX reboot problem after SSH is installed References: <403A7179.2000904@zip.com.au> Message-ID: <403A7F8A.829F9C9@bell.ca> /sbin/shutdown doesn't exists. The shutdown program is located /etc/shutdown. So when I run "sh -x /etc/shutdown -Fr", it can also reboot the machine. Felix Darren Tucker wrote: > andy.tompkins at autozone.com wrote: > > AIX is just weird like that... > > AIX's shutdown command has some special behaviour to not terminate > itself or any of its parent processes. Perhaps it's getting confused? > > I think it's a shell script, you can run it with "sh -x /sbin/shutdown" > and see what it's doing... > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From djm at mindrot.org Tue Feb 24 10:24:24 2004 From: djm at mindrot.org (Damien Miller) Date: Tue, 24 Feb 2004 10:24:24 +1100 Subject: PKI and SSH In-Reply-To: <20040223222308.GA10422@cs.brown.edu> References: <20040223222308.GA10422@cs.brown.edu> Message-ID: <403A8BA8.6030304@mindrot.org> Gregory Seidman wrote: > Due to unpleasant (but arguably valid) policy changes at work, any SSH > server within the work firewall must accept only PKI authentication. > Unless we can convince the higher-ups otherwise, we will also have to > use the commercial SSH server within the firewall. Of course, I should > be able to use whatever client I like. Unfortunately, it is not clear > that I can get OpenSSH to use PKI authentication. A bit of googling > turns up a patch, but nothing too certain or clear. Does OpenSSH support > PKI authentication? If so, how do I use it? There were patches sent to the list a while ago to add some basic PKI functionality, for host keys IIRC. They may still apply to current version. They stalled because of lack of demand and testing. Roumen Petrov had (has?) a set of patches too. -d From dtucker at zip.com.au Tue Feb 24 10:35:14 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 24 Feb 2004 10:35:14 +1100 Subject: PKI and SSH In-Reply-To: <403A8BA8.6030304@mindrot.org> References: <20040223222308.GA10422@cs.brown.edu> <403A8BA8.6030304@mindrot.org> Message-ID: <403A8E32.9080009@zip.com.au> Damien Miller wrote: > There were patches sent to the list a while ago to add some basic PKI > functionality, for host keys IIRC. They may still apply to current > version. They stalled because of lack of demand and testing. > > Roumen Petrov had (has?) a set of patches too. That's the X.509 patches, yes? Those are at http://www.roumenpetrov.info/openssh/ They look current. -- 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 libove at felines.org Wed Feb 25 00:58:46 2004 From: libove at felines.org (Jay Libove) Date: Tue, 24 Feb 2004 08:58:46 -0500 Subject: PKI and SSH Message-ID: Several people answered about the X.509 integration patches for OpenSSH. I wonder, do the policy changes affecting Greg require integration with a specific external PKI (e.g. MS, Verisign, Entrust), or would those policy changes be satisfied by simply using asymmetric cryptography, which is built right in to OpenSSH's ability to perform (require) authentication by pre-shared public / private key pairs? -Jay -----Original Message----- From: openssh-unix-dev-bounces+libove=felines.org at mindrot.org [mailto:openssh-unix-dev-bounces+libove=felines.org at mindrot.org] On Behalf Of Gregory Seidman Sent: Monday, February 23, 2004 5:23 PM To: OpenSSH development list Subject: PKI and SSH Due to unpleasant (but arguably valid) policy changes at work, any SSH server within the work firewall must accept only PKI authentication. Unless we can convince the higher-ups otherwise, we will also have to use the commercial SSH server within the firewall. Of course, I should be able to use whatever client I like. Unfortunately, it is not clear that I can get OpenSSH to use PKI authentication. A bit of googling turns up a patch, but nothing too certain or clear. Does OpenSSH support PKI authentication? If so, how do I use it? --Greg _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From markus at openbsd.org Wed Feb 25 03:29:38 2004 From: markus at openbsd.org (Markus Friedl) Date: Tue, 24 Feb 2004 17:29:38 +0100 Subject: OpenSSH 3.8 released Message-ID: <20040224162938.GA30003@folly> OpenSSH 3.8 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. We would like to thank the OpenSSH community for their continued support to the project, especially those who contributed source and bought T-shirts or posters. We have a new design of T-shirt available, more info on http://www.openbsd.org/tshirts.html#18 For international orders use http://https.openbsd.org/cgi-bin/order and for European orders, use http://https.openbsd.org/cgi-bin/order.eu Changes since OpenSSH 3.7.1: ============================ * sshd(8) now supports forced changes of expired passwords via /usr/bin/passwd or keyboard-interactive authentication. Note for AIX: sshd will now deny password access to accounts with passwords expired longer than their maxexpired attribute. For details, see the AIX section in README.platform. * ssh(1) now uses untrusted cookies for X11-Forwarding. Some X11 applications might need full access to the X11 server, see ForwardX11Trusted in ssh(1) and xauth(1) for more information. * ssh(1) now supports sending application layer keep-alive messages to the server. See ServerAliveInterval in ssh(1) for more information. * Improved sftp(1) batch file support. * New KerberosGetAFSToken option for sshd(8). * Updated /etc/moduli file and improved performance for protocol version 2. * Support for host keys in DNS (draft-ietf-secsh-dns-xx.txt). Please see README.dns in the source distribution for details. * Fix a number of memory leaks. * The experimental "gssapi" support has been replaced with the "gssapi-with-mic" to fix possible MITM attacks. The two versions are not compatible. Checksums: ========== - MD5 (openssh-3.8.tgz) = 7d5590a333d8f8aa1fa6f19e24938700 - MD5 (openssh-3.8p1.tar.gz) = 7861a4c0841ab69a6eec5c747daff6fb Reporting Bugs: =============== - please read http://www.openssh.com/report.html and http://bugzilla.mindrot.org/ OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Ben Lindstrom, Darren Tucker and Tim Rice. From ahze at ahze.net Wed Feb 25 05:32:03 2004 From: ahze at ahze.net (Mike Johnson) Date: Tue, 24 Feb 2004 13:32:03 -0500 Subject: ACSS question. In-Reply-To: References: <20040224181851.338FD9B9@vtel.rgv.net> Message-ID: Hi, I tried sending this to acss at openssh.org and acss at openbsd.org but I got "Returned mail: no such user" on both accounts. So I am sending here in hopes of an answer. >> Hi, >> Last night I was searching for ways to "decss" and when I was doing >> so I came across acss.c and acss.h in the openssh cvs tree. I read >> the man page for acss(3) and I am still not 100% clear on what acss >> does in ssh. Is it posable to stream an dvd with ssh and have the >> client decrypt it? Or what is the point of acss in ssh now? >> >> Thanks >> Michael Johnson >> > From dmouldin at enterasys.com Wed Feb 25 09:28:34 2004 From: dmouldin at enterasys.com (Moulding, Dan) Date: Tue, 24 Feb 2004 17:28:34 -0500 Subject: Updated moduli file in OpenSSH 3.8 Message-ID: Hi, Can anybody briefly explain the significance of the updated moduli file? Is this a critical update? Should all existing installations update their moduli file? Thanks in advance, -- Dan From dtucker at zip.com.au Wed Feb 25 10:22:38 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 25 Feb 2004 10:22:38 +1100 Subject: Updated moduli file in OpenSSH 3.8 In-Reply-To: References: Message-ID: <403BDCBE.3010908@zip.com.au> Moulding, Dan wrote: > Can anybody briefly explain the significance of the updated moduli file? > Is this a critical update? Should all existing installations update > their moduli file? Short Answer: No, it's not critical. If you've got a slow/overloaded server, it would be worth doing, though. Long Answer: There are 2 reasons it was updated. 1) The idea of Diffie-Hellman Group Exchange is (quoting from [1]): "The ability to propose new groups will reduce the incentive to use precomputation for more efficient calculation of the discrete loga- rithm." In OpenSSH, those DH groups are stored in the moduli file. If the moduli file was never updated, it might become worthwhile to do some kind of precomputation on the groups in the file. So, as a precaution, a new moduli file was generated for the release. (Anyone can generate their own, BTW, see [2] and look for "update-moduli", but be aware that it's several days worth of CPU time on a fast processor.) 2) sshd will search the moduli file for groups at least as big as the client requests. For some moduli sizes, the file contained moduli one bit smaller than the power-of-two sizes that the client would ask for, and as a result, sshd would end up using the next size up. This would result in a speed penalty that was especially noticable on systems with slowish CPUs. For comparison: Old moduli New moduli bits count bits count 1023 38 1023 33 1534 31 1535 43 2046 36 2047 36 3190 36 3071 39 4094 14 4095 32 (For some reason the "bits" column is stored as log2(n) rather than just the number of bits in it. Mentally add 1 to get the actual number of bits.) [1] http://www.ietf.org/internet-drafts/draft-ietf-secsh-dh-group-exchange-04.txt [2] http://www.openbsd.org/cgi-bin/cvsweb/src/etc/Makefile?rev=HEAD -- 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 Wed Feb 25 10:22:56 2004 From: djm at mindrot.org (Damien Miller) Date: Wed, 25 Feb 2004 10:22:56 +1100 Subject: Updated moduli file in OpenSSH 3.8 In-Reply-To: References: Message-ID: <403BDCD0.5050909@mindrot.org> Moulding, Dan wrote: > Hi, > > Can anybody briefly explain the significance of the updated moduli file? > Is this a critical update? Should all existing installations update > their moduli file? The purpose of the group-exchange KEX method is to make cryptographic attacks against well-known DH groups impractical, by providing a diversity of moduli. Obviously this works best if the moduli are recycled every now and then. So, the update isn't critical, but it is recommended. Note that recent versions of ssh-keygen allow you to generate moduli for yourself. Have a look at the "MODULI GENERATION" section of the ssh-keygen manpage for details on how to do this. Note that you will need to generate a range of group sizes for this to be effective. I'd recommend that you base these on the sizes of the shipped moduli file. Beware - the generation process is quite slow and CPU/memory intensive. -d From jason at devrandom.org Wed Feb 25 14:17:14 2004 From: jason at devrandom.org (Jason McCormick) Date: Tue, 24 Feb 2004 22:17:14 -0500 Subject: OpenSSH 3.8p1 RPMs Message-ID: <200402242217.14385.jason@devrandom.org> Hello all. I've posted some RPM builds of OpenSSH 3.8p1 for RedHat 7.2, 7.3, 9.0, 2.1AS and Fedora Core 1. These are available from http://bamboo.lexi.com/openssh . I've previously posted RedHat 7.1 but as I've upgraded the last 7.1 box, I no longer have a build platform for that release. People have found value in these builds in the past so I try to keep the page updated. -- Jason McCormick jason at devrandom.org GPG Key ID: 96D6CF63 From openssh at roumenpetrov.info Thu Feb 26 16:52:44 2004 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Thu, 26 Feb 2004 07:52:44 +0200 Subject: X.509v3 certificates support in OpenSSH-3.8p1 Message-ID: <403D89AC.4000305@roumenpetrov.info> X.509v3 certificates support in OpenSSH-3.8p1 is ready for download. More information on "http://roumenpetrov.info/openssh". From CTLarsen at lbl.gov Fri Feb 27 11:35:08 2004 From: CTLarsen at lbl.gov (Case Larsen) Date: Thu, 26 Feb 2004 16:35:08 -0800 Subject: PAM patch for openssh 3.7.1p2 Message-ID: SecureComputing's PAM library doesn't pass back the correct context to the pam_conversation function, i.e. it passes back NULL. So this patch works around this fact. likely you'll only want this hack if you expect to use pam_safeword.so in your authentication check, and only if you run sshd in privilege separation (separate process) mode so that the PAM conversation is single threaded. The second patch is for the solaris package builder to turn allow pam to be automatically turned on for install. --- auth-pam.c 2004/02/26 19:35:52 1.1.1.1 +++ auth-pam.c 2004/02/27 00:26:00 @@ -124,7 +124,10 @@ int pam_csock; int pam_done; }; +static struct pam_ctxt *sshpam_ctxt; /* hack for pam library not passing back + ctxt */ + static void sshpam_free_ctx(void *); /* @@ -142,6 +145,10 @@ *resp = NULL; ctxt = data; + if ( ctxt == NULL ) + { + ctxt = sshpam_ctxt; + } if (n <= 0 || n > PAM_MAX_NUM_MSG) return (PAM_CONV_ERR); @@ -221,6 +228,7 @@ sshpam_conv.conv = sshpam_thread_conv; sshpam_conv.appdata_ptr = ctxt; + sshpam_ctxt = ctxt; buffer_init(&buffer); sshpam_err = pam_set_item(sshpam_handle, PAM_CONV, --- contrib/solaris/buildpkg.sh 2004/02/26 19:35:55 1.1.1.1 +++ contrib/solaris/buildpkg.sh 2004/02/27 00:27:00 @@ -18,14 +18,15 @@ # with a real OpenSSH package on a system. This is not needed on systems # that support the -R option to pkgadd. #TEST_DIR=/var/tmp # leave commented out for production build PKGNAME=OpenSSH SYSVINIT_NAME=opensshd MAKE=${MAKE:="make"} SSHDUID=67 # Default privsep uid SSHDGID=67 # Default privsep gid # uncomment these next two as needed #PERMIT_ROOT_LOGIN=no #X11_FORWARDING=yes +#USEPAM=yes # list of system directories we do NOT want to change owner/group/perms # when installing our package SYSTEM_DIR="/etc \ @@ -143,6 +144,9 @@ $FAKE_ROOT/${sysconfdir}/sshd_config [ "${X11_FORWARDING}" = yes ] && \ perl -p -i -e "s/#X11Forwarding no/X11Forwarding yes/" \ + $FAKE_ROOT/${sysconfdir}/sshd_config +[ "${USEPAM}" = yes ] && \ + perl -p -i -e "s/#UsePAM yes/UsePAM yes/" \ $FAKE_ROOT/${sysconfdir}/sshd_config # fix PrintMotd perl -p -i -e "s/#PrintMotd yes/PrintMotd no/" \ From Sergio.Gelato at astro.su.se Fri Feb 27 11:35:48 2004 From: Sergio.Gelato at astro.su.se (Sergio Gelato) Date: Fri, 27 Feb 2004 01:35:48 +0100 Subject: __BIT_TYPES_DEFINED__ patch for 3.8p1 on Tru64 Message-ID: <20040227003547.GA14354@astro.su.se> I have found the following simple patch useful for building OpenSSH 3.8p1 on my Tru64 V4.0G boxes with Heimdal 0.6. The problem is that Heimdal defines the intXX_t types in and these then clash with OpenSSH's own definitions in "defines.h". The patch should be harmless on other platforms (at least if they are sane and don't define __BIT_TYPES_DEFINED__ without also declaring the corresponding datatypes). --- orig/defines.h +++ mod/defines.h @@ -143,6 +143,7 @@ typedef unsigned int u_int; #endif +#ifndef __BIT_TYPES_DEFINED__ #ifndef HAVE_INTXX_T # if (SIZEOF_CHAR == 1) typedef char int8_t; @@ -211,6 +212,7 @@ # endif #define __BIT_TYPES_DEFINED__ #endif +#endif /* ifndef __BIT_TYPES_DEFINED__ */ /* 64-bit types */ #ifndef HAVE_INT64_T From Sergio.Gelato at astro.su.se Fri Feb 27 11:59:32 2004 From: Sergio.Gelato at astro.su.se (Sergio Gelato) Date: Fri, 27 Feb 2004 01:59:32 +0100 Subject: [PATCH] Getting AFS tokens from a GSSAPI-delegated TGT Message-ID: <20040227005932.GB14354@astro.su.se> Here is a patch I just wrote and tested which may be of interest to those who wish to use KerberosGetAFSToken (currently requires Heimdal libkafs) in combination with GSSAPIDelegateCredentials. The patch is in the public domain and comes with no warranty whatsoever. Applies to pristine 3.8p1. Works for me on Solaris and Tru64. I'd probably have used Doug Engert's patch from 2004-01-30 if Heimdal's afslog command supported -setpag; although to be honest I don't really like the idea of children being able to change their parent's PAG. * modified files ./auth-krb5.c ./auth.h ./session.c * file diffs --- orig/auth-krb5.c +++ mod/auth-krb5.c @@ -199,6 +199,25 @@ return (1); } +/* + * Mainly useful with GSSAPI Kerberos 5 forwarded credentials. + * Called after we have setuid to the user. + */ +void +session_krb5_use_ccache(Authctxt *authctxt) +{ + char *ccname; + debug("session_krb5_use_ccache called"); + if (authctxt->krb5_fwd_ccache) + return; + ccname = getenv("KRB5CCNAME"); + if (!ccname) + return; + debug("using ccname=%.100s", ccname); + if (krb5_init(authctxt)) + return; + krb5_cc_resolve(authctxt->krb5_ctx, ccname, &authctxt->krb5_fwd_ccache);} + void krb5_cleanup_proc(Authctxt *authctxt) { --- orig/auth.h +++ mod/auth.h @@ -120,6 +120,7 @@ int auth_krb5_tgt(Authctxt *authctxt, krb5_data *tgt); int auth_krb5_password(Authctxt *authctxt, const char *password); void krb5_cleanup_proc(Authctxt *authctxt); +void session_krb5_use_ccache(Authctxt *authctxt); #endif /* KRB5 */ #if defined(USE_SHADOW) && defined(HAS_SHADOW_EXPIRE) --- orig/session.c +++ mod/session.c @@ -1462,20 +1462,22 @@ * home directory is in AFS and it's not world-readable. */ - if (options.kerberos_get_afs_token && k_hasafs() && - (s->authctxt->krb5_ctx != NULL)) { - char cell[64]; + if (options.kerberos_get_afs_token && k_hasafs()) { + session_krb5_use_ccache(s->authctxt); + if (s->authctxt->krb5_ctx != NULL) { + char cell[64]; - debug("Getting AFS token"); + debug("Getting AFS token"); - k_setpag(); + k_setpag(); - if (k_afs_cell_of_file(pw->pw_dir, cell, sizeof(cell)) == 0) - krb5_afslog(s->authctxt->krb5_ctx, - s->authctxt->krb5_fwd_ccache, cell, NULL); + if (k_afs_cell_of_file(pw->pw_dir, cell, sizeof(cell)) == 0) + krb5_afslog(s->authctxt->krb5_ctx, + s->authctxt->krb5_fwd_ccache, cell, NULL); - krb5_afslog_home(s->authctxt->krb5_ctx, - s->authctxt->krb5_fwd_ccache, NULL, NULL, pw->pw_dir); + krb5_afslog_home(s->authctxt->krb5_ctx, + s->authctxt->krb5_fwd_ccache, NULL, NULL, pw->pw_dir); + } } #endif From deengert at anl.gov Fri Feb 27 23:21:33 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Fri, 27 Feb 2004 06:21:33 -0600 Subject: [PATCH] Getting AFS tokens from a GSSAPI-delegated TGT References: <20040227005932.GB14354@astro.su.se> Message-ID: <403F364C.EA9A60D6@anl.gov> Sergio Gelato wrote: > > Here is a patch I just wrote and tested which may be of interest to > those who wish to use KerberosGetAFSToken (currently requires Heimdal > libkafs) in combination with GSSAPIDelegateCredentials. The patch is > in the public domain and comes with no warranty whatsoever. Applies > to pristine 3.8p1. Works for me on Solaris and Tru64. > > I'd probably have used Doug Engert's patch from 2004-01-30 if Heimdal's > afslog command supported -setpag; although to be honest I don't really > like the idea of children being able to change their parent's PAG. I have backed off on using the -setpag option, and added syscall(setpag...) code to the get_afs_token routine. I am also looking at making this a dynamic link, which would mean it could work with any Kerberos, does not require kafs, could always be compiled in and run on a system with or without AFS. > > * modified files > > ./auth-krb5.c > ./auth.h > ./session.c > > * file diffs > > --- orig/auth-krb5.c > +++ mod/auth-krb5.c > @@ -199,6 +199,25 @@ > return (1); > } > > +/* > + * Mainly useful with GSSAPI Kerberos 5 forwarded credentials. > + * Called after we have setuid to the user. > + */ > +void > +session_krb5_use_ccache(Authctxt *authctxt) > +{ > + char *ccname; > + debug("session_krb5_use_ccache called"); > + if (authctxt->krb5_fwd_ccache) > + return; > + ccname = getenv("KRB5CCNAME"); > + if (!ccname) > + return; > + debug("using ccname=%.100s", ccname); > + if (krb5_init(authctxt)) > + return; > + krb5_cc_resolve(authctxt->krb5_ctx, ccname, &authctxt->krb5_fwd_ccache);} > + > void > krb5_cleanup_proc(Authctxt *authctxt) > { > > --- orig/auth.h > +++ mod/auth.h > @@ -120,6 +120,7 @@ > int auth_krb5_tgt(Authctxt *authctxt, krb5_data *tgt); > int auth_krb5_password(Authctxt *authctxt, const char *password); > void krb5_cleanup_proc(Authctxt *authctxt); > +void session_krb5_use_ccache(Authctxt *authctxt); > #endif /* KRB5 */ > > #if defined(USE_SHADOW) && defined(HAS_SHADOW_EXPIRE) > > --- orig/session.c > +++ mod/session.c > @@ -1462,20 +1462,22 @@ > * home directory is in AFS and it's not world-readable. > */ > > - if (options.kerberos_get_afs_token && k_hasafs() && > - (s->authctxt->krb5_ctx != NULL)) { > - char cell[64]; > + if (options.kerberos_get_afs_token && k_hasafs()) { > + session_krb5_use_ccache(s->authctxt); > + if (s->authctxt->krb5_ctx != NULL) { > + char cell[64]; > > - debug("Getting AFS token"); > + debug("Getting AFS token"); > > - k_setpag(); > + k_setpag(); > > - if (k_afs_cell_of_file(pw->pw_dir, cell, sizeof(cell)) == 0) > - krb5_afslog(s->authctxt->krb5_ctx, > - s->authctxt->krb5_fwd_ccache, cell, NULL); > + if (k_afs_cell_of_file(pw->pw_dir, cell, sizeof(cell)) == 0) > + krb5_afslog(s->authctxt->krb5_ctx, > + s->authctxt->krb5_fwd_ccache, cell, NULL); > > - krb5_afslog_home(s->authctxt->krb5_ctx, > - s->authctxt->krb5_fwd_ccache, NULL, NULL, pw->pw_dir); > + krb5_afslog_home(s->authctxt->krb5_ctx, > + s->authctxt->krb5_fwd_ccache, NULL, NULL, pw->pw_dir); > + } > } > #endif > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From antoine.verheijen at ualberta.ca Sat Feb 28 07:20:33 2004 From: antoine.verheijen at ualberta.ca (Antoine Verheijen) Date: Fri, 27 Feb 2004 13:20:33 -0700 Subject: Minor Thread Bug In OpenSSH 3.8p1 Message-ID: <20040227202033.GA7078@reddwarf.ucs.ualberta.ca> There is a minor problem with the PAM support in OpenSSH 3.8p1. If you use POSIX threads (as specified by defining USE_POSIX_THREADS) in auth-pam.c, PAM authentication will fail in routine import_environments(). The purpose of this routine is to import variables returned by do_pam_account() in sshpam_thread(). However, those variable are only exported if USE_POSIX_THREADS is NOT set. Consequently, import_environments() get upset when there's nothing in the buffer when that macro IS set. I have chosen to comment out the guts of routine import_environments() if USE_POSIX_PTHREADS is not defined as a solution, reasoning that this will also work if that routine a called by other parts of the code in some later version. I could have just commented out the single call to that routine in sshpam_query() as an alternative. Either way will work. diff -r -c old/auth-pam.c new/auth-pam.c *** old/auth-pam.c Tue Feb 17 05:20:08 2004 --- new/auth-pam.c Thu Feb 26 23:18:05 2004 *************** *** 201,206 **** --- 201,207 ---- debug3("PAM: %s entering", __func__); + #ifndef USE_POSIX_THREADS /* Import variables set by do_pam_account */ sshpam_account_status = buffer_get_int(b); pam_password_change_required(buffer_get_int(b)); *************** *** 228,233 **** --- 229,235 ---- } #endif } + #endif } /* ----------------------------------------------------------------------- Antoine Verheijen Email: antoine.verheijen at ualberta.ca CNS Network Services Phone: (780) 492-9312 University of Alberta Fax: (780) 492-1729 From antoine.verheijen at ualberta.ca Sat Feb 28 07:21:42 2004 From: antoine.verheijen at ualberta.ca (Antoine Verheijen) Date: Fri, 27 Feb 2004 13:21:42 -0700 Subject: Change request For OpenSSH 3.8p1 Message-ID: <20040227202142.GB7078@reddwarf.ucs.ualberta.ca> NOTE: This patch requires a previously sent patch fixing a small problem in OpenSSH PAM support when POSIX threads are used. This is a small patch to the OpenSSH portable configuration process that I'd like to have considered for inclusion in the distributed version. It will set the use of (native) POSIX threads in Solaris if the header and library files are present on the system. At present, this will only affect PAM support on that OS. Here's my problem. We use AFS at the University of Alberta. On Solaris, authentication to AFS at login time is done via a PAM module. In versions of OpenSSH up to at least 3.4p1, this worked fine. However, sometime before version 3.8p1, the AFS PAM module stopped working properly with OpenSSH. I have tracked this down to the use of "threads" in the PAM support (auth-pam.c). With the approach now taken, a new "thread" is begun in the task to call pam_authenticate(). This "thread" terminates on completion of that call and the remaining PAM calls are done from the original "thread". Seems reasonable. (The reason for the quotes around the word thread is because of the next paragraph.) Now, if a system does not have POSIX thread support, it is simulated using processes (fork()). This works okay for the most part. Unfortunately, in the AFS PAM module, the pam_authenticate() routine saves some critical module-specific data (via the pam_set_data() routine) for use by the pam_setcred() routine later on. This is perfectly acceptable (in fact, it's provided for) in the PAM framework. When fork() is used to simulate threads, the data saved by pam_authenticate() is associated with the new process and is not available to the old process. Thus, the pam_setcred() call will always fail. When true POSIX threads are used, this is not an issue because all heap storage (which is where the saved data is placed) is accessible to all threads and the PAM module works. Solaris 8 and beyond (at least) has full POSIX thread support. OpenSSH never tries to use it, however, unless you do some magic with environment variables prior to the configure. The simple patch below checks for the existence of the POSIX threads header file and library on Solaris and includes them, along with the setting of USE_POSIX_THREADS, if they exist. The build of OpenSSH then uses true POSIX threads on Solaris and the problem goes away. Please give serious consideration to including this (or something similar) in the distributed version of portable OpenSSH. Note that this patch ONLY affects Solaris systems. A slightly different approach could, of course, be used for a more general solution (using something like HAVE_PTHREAD_H instead of USE_POSIX_THREADS) along with a possible flag such as --with-threads. If you prefer, I could put in this type of solution but this would require testing on various other platforms that I don't have access to (although that would only matter if the flag was set). diff -r -c old/configure.ac new/configure.ac *** old/configure.ac Mon Feb 23 22:47:04 2004 --- new/configure.ac Thu Feb 26 17:23:55 2004 *************** *** 273,278 **** --- 273,285 ---- AC_DEFINE(LOGIN_NEEDS_TERM) AC_DEFINE(PAM_TTY_KLUDGE) AC_DEFINE(LOCKED_PASSWD_STRING, "*LK*") + # Check for existence of POSIX threads. + AC_CHECK_HEADER(pthread.h, [ + AC_CHECK_LIB(pthread, pthread_create, [ + CPPFLAGS="$CPPFLAGS -DUSE_POSIX_THREADS" + LIBS="-lpthread $LIBS" + ]) + ]) # Pushing STREAMS modules will cause sshd to acquire a controlling tty. AC_DEFINE(SSHD_ACQUIRES_CTTY) external_path_file=/etc/default/login ----------------------------------------------------------------------- Antoine Verheijen Email: antoine.verheijen at ualberta.ca CNS Network Services Phone: (780) 492-9312 University of Alberta Fax: (780) 492-1729 From djm at mindrot.org Sat Feb 28 09:44:17 2004 From: djm at mindrot.org (Damien Miller) Date: Sat, 28 Feb 2004 09:44:17 +1100 (EST) Subject: Change request For OpenSSH 3.8p1 In-Reply-To: <20040227202142.GB7078@reddwarf.ucs.ualberta.ca> References: <20040227202142.GB7078@reddwarf.ucs.ualberta.ca> Message-ID: On Fri, 27 Feb 2004, Antoine Verheijen wrote: > NOTE: This patch requires a previously sent patch fixing a small problem in > OpenSSH PAM support when POSIX threads are used. > > This is a small patch to the OpenSSH portable configuration process that > I'd like to have considered for inclusion in the distributed version. It > will set the use of (native) POSIX threads in Solaris if the header and > library files are present on the system. At present, this will only affect > PAM support on that OS. No - we will not be making threads easy to use. Right now they are an option for people who a) really know what they are doing and b) need to fix the AFS PAG issue. If we make them easy to use, then idiots will turn them on thinking "cool, threads are supposed to be, like, fast and stuff". I consider threads to be evil complexity that should be used only as a last resort. As soon as we have a better fix for this particular problem, I think we should be removing thread support altogether. Possible fixes so far are: 1. Inverting the monitor/pam-child relationship (clever idea from Darren Tucker's, search the list archive for details). Problems with rekeying need to be solved. 2. Resurrecting the old PAM password hack (ugly, but less so than threads). Patches welcome. 3. Use of a separate setpag helper. 4. Obtaining a PAG properly as part of gssapi-with-mic (needs extra code for MIT Kerberos, I believe) 5. Utilising the async conversation function extensions that some PAM libs (Linux-PAM, at least) provide. Obviously this would only work with PAM libs that support these extensions, but hopefully that would provide some incentive for PAM implementors to renovate this horrid API. Patches welcome. -d From deengert at anl.gov Sat Feb 28 10:23:38 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Fri, 27 Feb 2004 17:23:38 -0600 Subject: OPenAFS and OpenSSH replacing kafs Message-ID: <403FD17A.C40794AF@anl.gov> Would OpenSSH be willing to accept a modification similar to the one below to replace the kafs modification to get an AFS PAG and token? The nice features of this are that it can be compiled in even if OpenAFS is not available. At runtime if the dynamic library is present, it can be loaded and called. A dynamic lib is used so the setpag is in the same process. It has been reported that the kafs code does not work with delegated gssapi credentials in OpenSSH-3.8. I have not had this problem as I used a different method which this mod is based on. This proposed change would replace the calls to kafs. OpenAFS could then distribute the dynamic library, that would get a PAG and fork/exec some program like aklog, or afslog to actually get the token. The aklog or afslog could be distributed by OpenAFS or some Kerberos vendor. The routine loaded is the get_afs_token routine that I proposed last week but without the -setpag "kernel hack". It would have setpag code added to it instead and this runs in the current process avoiding the need to set the PAG in the parent process. The following compiles but I have not tested it. I am looking for comments. Would OpenSSH be willing to add such a mod? Would OpenAFS be willing to distribute the dynamic library? ( I have sent this same message to the openafs-devel list yesterday but have not received and comments.) Would the Kerberos developers be willing to provide the aklog or afslog that accepted -p and an environment with the KRB5CCNAME in it? --- ,session.c Mon Feb 23 07:01:27 2004 +++ session.c Thu Feb 26 14:10:39 2004 @@ -58,9 +58,13 @@ #include "session.h" #include "monitor_wrap.h" +#ifdef ANL_AFS_PAG +#include +#else #if defined(KRB5) && defined(USE_AFS) #include #endif +#endif #ifdef GSSAPI #include "ssh-gss.h" @@ -1453,6 +1457,28 @@ */ environ = env; + +#ifdef ANL_AFS_PAG + /* Get PAG and AFS token using external program and KRB5CCNAME */ + if (options.kerberos_get_afs_token) { + void * handle; + int (*get_afs_token)(char * pgm, char ** env, + char *homedir, int setpag); + + debug("Getting AFS PAG and token"); + handle = dlopen("/usr/lib/afs_get_token.so",0); /* needs a better location */ + + if (handle) { + get_afs_token = dlsym(handle, "get_afs_token"); + if (get_afs_token) { + debug("calling get_afs_token"); + (*get_afs_token)(NULL, env, pw->pw_dir, 1); + } + dlclose(handle); + } + } +#else + #if defined(KRB5) && defined(USE_AFS) /* * At this point, we check to see if AFS is active and if we have @@ -1477,6 +1503,7 @@ krb5_afslog_home(s->authctxt->krb5_ctx, s->authctxt->krb5_fwd_ccache, NULL, NULL, pw->pw_dir); } +#endif #endif /* Change current directory to the user\'s home directory. */ From johnpell at mac.com Sat Feb 28 12:22:53 2004 From: johnpell at mac.com (John Davidorff Pell) Date: Fri, 27 Feb 2004 17:22:53 -0800 Subject: Change request For OpenSSH 3.8p1 In-Reply-To: References: <20040227202142.GB7078@reddwarf.ucs.ualberta.ca> Message-ID: Who are you, and why do you think you get to decide this? Why are you so against threads? Is there some good reason, or are you just afraid of them? JP On 27 Feb 2004, at 14:44, Damien Miller wrote: > No - we will not be making threads easy to use. -- "NOTICE: This E-mail (including attachments) is covered by the Electronic Communications Privacy Act, 18 U.S.C. 2510-2521, is confidential and may be legally privileged. If you are not the intended recipient, you are hereby notified that any retention, dissemination, distribution or copying of this communication is strictly prohibited, Please reply to the sender that you have received the message in error, then delete it. Thank you." -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2426 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040227/fdd1b6b9/attachment.bin From mouring at etoh.eviladmin.org Sat Feb 28 14:42:14 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 27 Feb 2004 21:42:14 -0600 (CST) Subject: Change request For OpenSSH 3.8p1 In-Reply-To: Message-ID: On Fri, 27 Feb 2004, John Davidorff Pell wrote: > Who are you, and why do you think you get to decide this? Why are you > so against threads? Is there some good reason, or are you just afraid > of them? > You definitely have never had any contact with OpenSSH team nor read any of the release notes. The more important question from our side of the fence is "Who the hell are you, and who says you get to force crap on us?" Let me give you an URL hint about how Damien Miller is: http://www.openssh.com/history.html As for your question about threads. It has been discussed before on this list. MARC will have the complete conversation, but if my memory serves me right it boils down to the fact a correct solution can be done without threads, and implementing threading in OpenSSH adds edge cases and more unpredictable library code. Threads add a whole new level of race conditions, and therefor should be avoided at all cost when it comes to 'retrofitting' applications. - Ben From markus at openbsd.org Sat Feb 28 19:28:47 2004 From: markus at openbsd.org (Markus Friedl) Date: Sat, 28 Feb 2004 09:28:47 +0100 Subject: OPenAFS and OpenSSH replacing kafs In-Reply-To: <403FD17A.C40794AF@anl.gov> References: <403FD17A.C40794AF@anl.gov> Message-ID: <20040228082847.GB21656@folly> On Fri, Feb 27, 2004 at 05:23:38PM -0600, Douglas E. Engert wrote: > Would OpenSSH be willing to add such a mod? i don't see why sshd should play a dynamic linking game. either the library has the symbol at compiletime or not. From markus at openbsd.org Sat Feb 28 19:30:01 2004 From: markus at openbsd.org (Markus Friedl) Date: Sat, 28 Feb 2004 09:30:01 +0100 Subject: Change request For OpenSSH 3.8p1 In-Reply-To: References: <20040227202142.GB7078@reddwarf.ucs.ualberta.ca> Message-ID: <20040228083001.GC21656@folly> On Fri, Feb 27, 2004 at 05:22:53PM -0800, John Davidorff Pell wrote: > Who are you, and why do you think you get to decide this? hello? From dtucker at zip.com.au Sun Feb 29 01:14:36 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 29 Feb 2004 01:14:36 +1100 Subject: Change request For OpenSSH 3.8p1 In-Reply-To: References: <20040227202142.GB7078@reddwarf.ucs.ualberta.ca> Message-ID: <4040A24C.10604@zip.com.au> John Davidorff Pell wrote: >On 27 Feb 2004, at 14:44, Damien Miller wrote: >> No - we will not be making threads easy to use. > Who are you, and why do you think you get to decide this? You're kidding, right? Damien's a modest guy, so let me say on his behalf that he: * (co?)founded of the Portable OpenSSH branch * is one of the lead developers on OpenSSH (both Portable + OpenBSD) * has done more work on Portable OpenSSH that any other individual (by a factor of about 3 if you count LOC) * makes and signs the the release tarballs, so literally has the last word on what goes into the releases. > Why are you so > against threads? Is there some good reason, or are you just afraid of them? http://www.google.com/search?q=pthreads+race Searched the web for pthreads race. Results 1 - 10 of about 7,730. Every function call of every PAM module on every platform is thread-safe, right? And any that aren't will never cause any problems, right? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From deengert at anl.gov Sun Feb 29 02:02:01 2004 From: deengert at anl.gov (Douglas E. Engert) Date: Sat, 28 Feb 2004 09:02:01 -0600 Subject: OPenAFS and OpenSSH replacing kafs References: <403FD17A.C40794AF@anl.gov> <20040228082847.GB21656@folly> Message-ID: <4040AD69.A3378BBB@anl.gov> Markus Friedl wrote: > > On Fri, Feb 27, 2004 at 05:23:38PM -0600, Douglas E. Engert wrote: > > Would OpenSSH be willing to add such a mod? > > i don't see why sshd should play a dynamic linking game. > > either the library has the symbol at compiletime > or not. If a vendor, like Red Hat, Apple, Sun, HP, IBM or OpenBSD builds OpenSSH for distribution, they can do it without having OpenAFS available at compile time. Yet when the end user uses OpenSSH on a system with OpenAFS they will work together because the hook in OpenSSH will already be in place by default. The use of the dynamic library gets the setpag code to run from the correct process. It might also be useable with PAGs for NFSv4. Two other approaches are: (1) Make the get_afs_token routine part of OpenSSH and compiled in. But this then has some dependencies on how the setpag is done and vendors may not compile in this option, especially if any OpenAFS libs are required at compile time. (2) PAM could be called when GSSAPI is used for authentication. A PAM session routine could do the setpag, as long as the PAM routine is run from the correct process. This opens up some other possibilities of moving some or all of the Heimdal vs MIT kerberos dependencies to PAM routines as well. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From markus at openbsd.org Sun Feb 29 03:30:17 2004 From: markus at openbsd.org (Markus Friedl) Date: Sat, 28 Feb 2004 17:30:17 +0100 Subject: OPenAFS and OpenSSH replacing kafs In-Reply-To: <4040AD69.A3378BBB@anl.gov> References: <403FD17A.C40794AF@anl.gov> <20040228082847.GB21656@folly> <4040AD69.A3378BBB@anl.gov> Message-ID: <20040228163017.GC23757@folly> On Sat, Feb 28, 2004 at 09:02:01AM -0600, Douglas E. Engert wrote: > > i don't see why sshd should play a dynamic linking game. > > > > either the library has the symbol at compiletime > > or not. > > If a vendor, like Red Hat, Apple, Sun, HP, IBM or OpenBSD builds > OpenSSH for distribution, they can do it without having OpenAFS > available at compile time. i think applications like sshd should not ramdomly dlopen() libraries an execute unknown future functions. > Yet when the end user uses OpenSSH on a system with OpenAFS > they will work together because the hook in OpenSSH will already be > in place by default. if a vendor wants that, then they can ship OpenAFS of a stub library. > (1) Make the get_afs_token routine part of OpenSSH and compiled in. > But this then has some dependencies on how the setpag is done > and vendors may not compile in this option, especially if any > OpenAFS libs are required at compile time. OpenSSH is not responsible for a common AFS API, the AFS vendors are. > (2) PAM could be called when GSSAPI is used for authentication. > A PAM session routine could do the setpag, as long as the PAM > routine is run from the correct process. if GSSAPI is the great generic security server API it claims to be, then it can hide all this stuff from sshd. -m From johnpell at mac.com Sun Feb 29 05:17:44 2004 From: johnpell at mac.com (John Davidorff Pell) Date: Sat, 28 Feb 2004 10:17:44 -0800 Subject: Change request For OpenSSH 3.8p1 In-Reply-To: <4040A24C.10604@zip.com.au> References: <20040227202142.GB7078@reddwarf.ucs.ualberta.ca> <4040A24C.10604@zip.com.au> Message-ID: <683AFC91-6A1A-11D8-8DFD-0003934F6406@mac.com> On 28 Feb 2004, at 06:14, Darren Tucker wrote: > John Davidorff Pell wrote: > >> On 27 Feb 2004, at 14:44, Damien Miller wrote: >>> No - we will not be making threads easy to use. >> Who are you, and why do you think you get to decide this? > > You're kidding, right? > > Damien's a modest guy, so let me say on his behalf that he: > * (co?)founded of the Portable OpenSSH branch > * is one of the lead developers on OpenSSH (both Portable + OpenBSD) > * has done more work on Portable OpenSSH that any other individual (by > a factor of about 3 if you count LOC) > * makes and signs the the release tarballs, so literally has the last > word on what goes into the releases. I realise that he is the Big Guy around here, but I assumed that since this is Free Software, that no one man can make this decision. This seems to be a theme that is becoming dangerous. XFree86 has a very small group (I'm not sure if its actually just one individual, though from what I read it seems to be) that do Bad Things, is OpenSSH following suit? >> Why are you so against threads? Is there some good reason, or are you >> just afraid of them? > > http://www.google.com/search?q=pthreads+race > Searched the web for pthreads race. Results 1 - 10 of about 7,730. > > Every function call of every PAM module on every platform is > thread-safe, right? And any that aren't will never cause any > problems, right? I couldn't care less if OpenSSH uses threads or not, that's not what I'm worrying about. I'm concerned that one man can say something that appears to be a personal bias without *any* explanation and get defended by several others! There are hundreds, if not more, of things in OpenSSH-portable that are extremely platform specific, why not limit pthreads support to platforms that have good implementations. Also, all the PAM stuff would be done in one thread, wouldn't it, so AFAIK it wouldn't need to be expressly thread-safe, since we'd be sure that it is never run in multiple threads. I don't care if threads are supported or not, I'm just wondering why this guy can tell the world that not only are they not supported, but that they will be removed just because he doesn't want put in the effort the thread safe the package. JP ---- It's all fun and games 'til someone writes to a NULL pointer! -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2426 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040228/13ef993c/attachment.bin From smoogen at lanl.gov Sun Feb 29 07:02:55 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Sat, 28 Feb 2004 13:02:55 -0700 (MST) Subject: Change request For OpenSSH 3.8p1 In-Reply-To: <683AFC91-6A1A-11D8-8DFD-0003934F6406@mac.com> References: <20040227202142.GB7078@reddwarf.ucs.ualberta.ca> <4040A24C.10604@zip.com.au> <683AFC91-6A1A-11D8-8DFD-0003934F6406@mac.com> Message-ID: A couple of things: 1) Openssh is 'BSD/Open Software' not 'Free Software'. There is a big difference (but probably not for this argument). 2) You are always free to fork it yourself if you dont like the decisions. 3) I know that this will probably irk the BSD people, but to use terms you might be familiar with.. Damien is equivalent to Linus.. if Linus doesnt want something into the mainstream kernel it doesnt go there... Markus, Theo, etc are all equivalent but Damien has commited the most code so he has a better say. I hope this makes things a bit clearer for other people who take the time to read archives before posting.. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From mouring at etoh.eviladmin.org Sun Feb 29 07:31:04 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sat, 28 Feb 2004 14:31:04 -0600 (CST) Subject: Change request For OpenSSH 3.8p1 In-Reply-To: Message-ID: On Sat, 28 Feb 2004, Stephen Smoogen wrote: [..] > 3) I know that this will probably irk the BSD people, but to use > terms you might be familiar with.. Damien is equivalent to Linus.. if > Linus doesnt want something into the mainstream kernel it doesnt go > there... > Well.. If you want to get Technical.. Markus == Linus Since it is Markus' project. Damien == Mr Cox Since he is the Portable project manager > Markus, Theo, etc are all equivalent > but Damien has commited the most code so he has a better say. > I think if you look upstream I think Markus and Damien are pretty well neck and neck in commits. However commits does not always means who is in charge. Just who is doing the grunt work. Anyways.. I have real work to do. =) - Ben From Sergio.Gelato at astro.su.se Sun Feb 29 09:40:05 2004 From: Sergio.Gelato at astro.su.se (Sergio Gelato) Date: Sat, 28 Feb 2004 23:40:05 +0100 Subject: OPenAFS and OpenSSH replacing kafs In-Reply-To: <4040AD69.A3378BBB@anl.gov> References: <403FD17A.C40794AF@anl.gov> <20040228082847.GB21656@folly> <4040AD69.A3378BBB@anl.gov> Message-ID: <20040228224005.GA5725@astro.su.se> * Douglas E. Engert [2004-02-28 09:02:01 -0600]: > Markus Friedl wrote: > > > > On Fri, Feb 27, 2004 at 05:23:38PM -0600, Douglas E. Engert wrote: > > > Would OpenSSH be willing to add such a mod? > > > > i don't see why sshd should play a dynamic linking game. Isn't PAM also a dynamic linking game? One level removed, but equally pluggable. > If a vendor, like Red Hat, Apple, Sun, HP, IBM or OpenBSD builds > OpenSSH for distribution, they can do it without having OpenAFS > available at compile time. I think that's a strong argument for some form of dynamic linking (at least on platforms where this is needed and available). One reason not to do it through PAM might be that some of the platforms of interest don't support PAM. One example is Tru64 UNIX: while this platform does have PAM-like SIA, it's considerably less flexible. An alternative is for the plug-in to be loaded by the Kerberos library. This seems to be a straightforward approach on Mac OS X, for example. (Not confirmed yet; OpenSSH 3.8p1 apparently needs some patching before it will build on OS X. Am looking into it with the help of Steven Michaud's earlier work.) > Yet when the end user uses OpenSSH on a system with OpenAFS ... or Arla ... > they will work together because the hook in OpenSSH will already be > in place by default. > The use of the dynamic library gets the setpag code to run from > the correct process. It might also be useable with PAGs for NFSv4. One would hope that NFSv4, being GSS-based, would be able to leverage the credentials cache without any explicit PAG support in OpenSSH. But we'll see; this stuff is rather hairy. > (1) Make the get_afs_token routine part of OpenSSH and compiled in. > But this then has some dependencies on how the setpag is done > and vendors may not compile in this option, especially if any > OpenAFS libs are required at compile time. Maybe one should provide compatibility code that only implements k_hasafs() and setpag() for the platforms supported by OpenSSH portable? The rest can be done by forking a child process. > (2) PAM could be called when GSSAPI is used for authentication. > A PAM session routine could do the setpag, as long as the PAM > routine is run from the correct process. > > This opens up some other possibilities of moving some or all > of the Heimdal vs MIT kerberos dependencies to PAM routines > as well. It's problematic on PAMless platforms. From johnpell at mac.com Sun Feb 29 10:32:30 2004 From: johnpell at mac.com (John Davidorff Pell) Date: Sat, 28 Feb 2004 15:32:30 -0800 Subject: Change request For OpenSSH 3.8p1 In-Reply-To: References: Message-ID: <6120CD44-6A46-11D8-9F3D-0003934F6406@mac.com> He's mentioned twice: he was apparently interested in the porting effort, and he started work on the sftp client. ;-) Ok, I get the point, he's done a whole lot more than most people. But my point wasn't that he's a nobody. As you pointed out, I have really no idea who he is. however, this being a Free Software package, I expected this kind of decision not to be made by one person, or is Damien the one we worship around here? I'm not terribly interested in having threads or not having threads, it was the This Will Never Happen Because I Say So And Am G-d attitude that shocked me. On 27 Feb 2004, at 19:42, Ben Lindstrom wrote: > Let me give you an URL hint about how Damien Miller is -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 2426 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20040228/2980c2e1/attachment.bin From mouring at etoh.eviladmin.org Sun Feb 29 11:36:03 2004 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sat, 28 Feb 2004 18:36:03 -0600 (CST) Subject: OPenAFS and OpenSSH replacing kafs In-Reply-To: <20040228224005.GA5725@astro.su.se> Message-ID: On Sat, 28 Feb 2004, Sergio Gelato wrote: [..] > An alternative is for the plug-in to be loaded by the Kerberos library. > This seems to be a straightforward approach on Mac OS X, for example. > (Not confirmed yet; OpenSSH 3.8p1 apparently needs some patching before > it will build on OS X. Am looking into it with the help of Steven > Michaud's earlier work.) > I have patches for OS/X to compile. I'll work on finalizing this because some of this needs to go upstream (I plan on gutting the krb5_init_ets() since it is a private API and is not needed on most systems). I need to track down why extactly zlib.h hates being where it is, but this at least is a workaround. - Ben Index: auth-krb5.c =================================================================== RCS file: /var/cvs/openssh/auth-krb5.c,v retrieving revision 1.21 diff -u -r1.21 auth-krb5.c --- auth-krb5.c 22 Nov 2003 01:11:06 -0000 1.21 +++ auth-krb5.c 24 Feb 2004 07:13:56 -0000 @@ -54,7 +54,9 @@ problem = krb5_init_context(&authctxt->krb5_ctx); if (problem) return (problem); +#ifndef __APPLE__ /* XXX OS/X claims to not need this */ krb5_init_ets(authctxt->krb5_ctx); +#endif } return (0); } Index: gss-serv-krb5.c =================================================================== RCS file: /var/cvs/openssh/gss-serv-krb5.c,v retrieving revision 1.5 diff -u -r1.5 gss-serv-krb5.c --- gss-serv-krb5.c 23 Feb 2004 23:37:33 -0000 1.5 +++ gss-serv-krb5.c 24 Feb 2004 07:13:59 -0000 @@ -65,7 +65,9 @@ logit("Cannot initialize krb5 context"); return 0; } +#ifndef __APPLE__ /* Apple Claims OS/X does not need it */ krb5_init_ets(krb_context); +#endif return 1; } Index: monitor.c =================================================================== RCS file: /var/cvs/openssh/monitor.c,v retrieving revision 1.64 diff -u -r1.64 monitor.c --- monitor.c 6 Feb 2004 05:40:27 -0000 1.64 +++ monitor.c 24 Feb 2004 07:14:01 -0000 @@ -33,11 +33,12 @@ #include #endif +#include "zlib.h" + #include "ssh.h" #include "auth.h" #include "kex.h" #include "dh.h" -#include "zlib.h" #include "packet.h" #include "auth-options.h" #include "sshpty.h" Index: monitor_wrap.c =================================================================== RCS file: /var/cvs/openssh/monitor_wrap.c,v retrieving revision 1.40 diff -u -r1.40 monitor_wrap.c --- monitor_wrap.c 21 Nov 2003 12:56:47 -0000 1.40 +++ monitor_wrap.c 24 Feb 2004 07:14:02 -0000 @@ -30,6 +30,8 @@ #include #include +#include "zlib.h" + #include "ssh.h" #include "dh.h" #include "kex.h" @@ -40,7 +42,6 @@ #include "packet.h" #include "mac.h" #include "log.h" -#include "zlib.h" #include "monitor.h" #include "monitor_wrap.h" #include "xmalloc.h" From smoogen at lanl.gov Sun Feb 29 11:45:51 2004 From: smoogen at lanl.gov (Stephen Smoogen) Date: Sat, 28 Feb 2004 17:45:51 -0700 (MST) Subject: Change request For OpenSSH 3.8p1 In-Reply-To: References: Message-ID: On Sat, 28 Feb 2004, Ben Lindstrom wrote: > > >On Sat, 28 Feb 2004, Stephen Smoogen wrote: > >[..] >> 3) I know that this will probably irk the BSD people, but to use >> terms you might be familiar with.. Damien is equivalent to Linus.. if >> Linus doesnt want something into the mainstream kernel it doesnt go >> there... >> > >Well.. If you want to get Technical.. > >Markus == Linus >Since it is Markus' project. > >Damien == Mr Cox >Since he is the Portable project manager > Ah ok.. my memory is getting foggy with old age. In any case, thansk to all the core maintainers -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Lab CCN-5 Sched 5/40 PH: 4-0645 Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From dtucker at zip.com.au Sun Feb 29 12:05:08 2004 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 29 Feb 2004 12:05:08 +1100 Subject: Change request For OpenSSH 3.8p1 In-Reply-To: <6120CD44-6A46-11D8-9F3D-0003934F6406@mac.com> References: <6120CD44-6A46-11D8-9F3D-0003934F6406@mac.com> Message-ID: <40413AC4.4010300@zip.com.au> John Davidorff Pell wrote: > Ok, I get the point, he's done a whole lot more than most people. But my > point wasn't that he's a nobody. As you pointed out, I have really no > idea who he is. however, this being a Free Software package, I expected > this kind of decision not to be made by one person, or is Damien the one > we worship around here? What makes you think the other OpenSSH developers don't agree with him on this? > I'm not terribly interested in having threads or not having threads, it > was the This Will Never Happen Because I Say So And Am G-d attitude that > shocked me. I think you're reading way more into it than was there. He said: "we will not be making threads easy to use." and "As soon as we have a better fix for this particular problem, I think we should be removing thread support altogether." The first is a simple statement of fact about something that's already been decided, the second is an opinion and statement of direction. And in a previous message, you also said: > XFree86 has a very small group (I'm not sure if its actually just one > individual, though from what I read it seems to be) that do Bad > Things, is OpenSSH following suit? No, and that's not a valid comparison. The XFree86 change was a unilateral licence change that added restrictions. (BTW OpenSSH recently underwent a license audit to ensure that all parts were 2-term BSD, and parts that weren't and could not be relicensed were replaced, to *ensure* that you can use it for *any* purpose without restriction.) What we are discussing here is a change for valid technical reasons (even if you may not agree with them or the change itself). > Also, all the PAM stuff would be done in one thread, wouldn't it, so > AFAIK it wouldn't need to be expressly thread-safe, since we'd be sure > that it is never run in multiple threads. It's not just the PAM functions themselves you need to worry about it's *any* function that *any* PAM module might call that's not thread safe (getpwent() and friends come immediately to mind). -- 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.