From dwd at bell-labs.com Tue Feb 1 01:29:41 2000 From: dwd at bell-labs.com (Dave Dykstra) Date: Mon, 31 Jan 2000 08:29:41 -0600 Subject: EGD requirement a show stopper for me In-Reply-To: <38956F93.CD1D028@dial.pipex.com>; from Andre Lucas on Mon, Jan 31, 2000 at 11:18:43AM +0000 References:

<20000131090134.L27654@itspc142.dur.ac.uk> <38955A20.CC3376EB@dial.pipex.com> <20000131100808.M27654@itspc142.dur.ac.uk> <38956F93.CD1D028@dial.pipex.com> Message-ID: <20000131082941.B24164@lucent.com> On Mon, Jan 31, 2000 at 11:18:43AM +0000, Andre Lucas wrote: > Andrew Stribblehill wrote: > 8< > > If we assume that sshd is around all the time, there is no way for > > local users to login to other machines whilst disallowing ssh > > logins to localhost. (A sort of runlevel-2 state.) If it's > > considered that this is of minority interest, perhaps PRNG stuff > > /should/ be compiled in. > > > Good point. The prng code would need to be linked into ssh as well as > sshd - as it is in ssh-1.2.27 - and the state would be picked up from a > file. The biggest problem I see with that would be that the ssh > executable would have to be setuid to access the seed and key > files if there was no other program running to manage this. > > IMHO the best way is indeed to have a standalone daemon. Reading output > from a pipe, it's as close to a portable random device as we're likely > to get. EGD is good, but because it's written in Perl it's slow and big. > With a C prng as a separate program it should be easier to maintain, and > it would be easier to protect the statefiles that Yarrow wants. I can't > think of a reason why it would have to run as root, either. In my case, I have many users who run a non-setuid ssh (1.2.27) client on machines that do not have sshd running. I do not understand why people seem to dislike the idea of generating the initial random number from an entropy source and from then on saving a seed in a file. That's what ssh 1.2.27 and PGP do; have they been criticized for that? Sure it's a problem if somebody is able to break into your machine and read the seed file, but if somebody can do that then all bets are off anyway. GnuPG also does not save anything in a seed file, so there must be something to it. Perhaps people are worried about physical seizing of hardware; I'm not worried about that, and besides I don't see how that would be an issue for OpenSSH because it has nothing to protect once the power has been turned off on a machine thus tearing down all SSH sessions. GnuPG is different in that respect because if somebody seized the seed file they may be able to guess what random key was used to encrypt data in a file. - Dave Dykstra From andre.lucas at dial.pipex.com Tue Feb 1 02:03:39 2000 From: andre.lucas at dial.pipex.com (Andre Lucas) Date: Mon, 31 Jan 2000 15:03:39 +0000 Subject: EGD requirement a show stopper for me References:

<20000131090134.L27654@itspc142.dur.ac.uk> <38955A20.CC3376EB@dial.pipex.com> <20000131100808.M27654@itspc142.dur.ac.uk> <38956F93.CD1D028@dial.pipex.com> <20000131082941.B24164@lucent.com> Message-ID: <3895A44B.7FB4B62D@dial.pipex.com> Dave Dykstra wrote: 8< > I do not understand why people seem to dislike the idea of generating the > initial random number from an entropy source and from then on saving a seed > in a file. That's what ssh 1.2.27 and PGP do; have they been criticized > for that? Sure it's a problem if somebody is able to break into your I don't have the slightest concern about saving the PRNG state. Sorry if it came across that way. I do think that there's no need for the randseed to be exposed if you don't have to, as it's part of the PRNG's state and so Its Disclosure Is Probably A Bad Thing. Even though it is immediately stirred into the real-time entropy pool, if it wasn't an important component of the PRNG state there would be no point in saving it. All the Counterpane PRNG lit suggests that state compromise attacks are truly bad, and even if Yarrow is resistant to them I don't see the need to risk it. 8< > has been turned off on a machine thus tearing down all SSH sessions. GnuPG > is different in that respect because if somebody seized the seed file they > may be able to guess what random key was used to encrypt data in a file. I'm no authority of any kind on PRNG implementations or the software you've listed. So this is just a barely educated opinion. I think it's a good thing to save the random seed, as if you have confidence in your PRNG it's a good random value with which to initialise the generator. Since my understanding is that good entropy is hard to find(tm), why waste it? Ta, -Andre > > - Dave Dykstra From O.Stahl at lsw.uni-heidelberg.de Tue Feb 1 02:16:52 2000 From: O.Stahl at lsw.uni-heidelberg.de (Otmar Stahl) Date: Mon, 31 Jan 2000 16:16:52 +0100 Subject: Problem building OpenSSH-1.2.2 on HP-UX Message-ID: <20000131161652.A21653@fors.lsw.uni-heidelberg.de> Hi, Just wanted to let you know, that I had a small problem when compiling OpenSSH-1.2.2 on a HP-UX 10.20 trusted system. I used gcc-2.95.2 as compiler. I finally could compile it, but I had to comment two lines in login.c. (I am using openssl-0.9.4 and egd-0.6, if this matters.) line 236: login(&u, &utx); and the closing brace in line 272. Commenting these two lines it compiled ok and also seems to run fine. Kind regards, Otmar Stahl From andre.lucas at dial.pipex.com Tue Feb 1 02:37:30 2000 From: andre.lucas at dial.pipex.com (Andre Lucas) Date: Mon, 31 Jan 2000 15:37:30 +0000 Subject: Problem building OpenSSH-1.2.2 on HP-UX References: <20000131161652.A21653@fors.lsw.uni-heidelberg.de> Message-ID: <3895AC3A.26788B1E@dial.pipex.com> Is it possible you could send the compiler errors for the unedited OpenSSH 1.2.2, and the contents of config.h after running configure? Ta, -Andre Otmar Stahl wrote: > > Hi, > > Just wanted to let you know, that I had a small problem when compiling > OpenSSH-1.2.2 on a HP-UX 10.20 trusted system. I used gcc-2.95.2 as > compiler. I finally could compile it, but I had to comment two lines in > login.c. (I am using openssl-0.9.4 and egd-0.6, if this matters.) > > line 236: > > login(&u, &utx); > > and the closing brace in line 272. > > Commenting these two lines it compiled ok and also seems to run fine. > > Kind regards, > Otmar Stahl From O.Stahl at lsw.uni-heidelberg.de Tue Feb 1 02:45:41 2000 From: O.Stahl at lsw.uni-heidelberg.de (Otmar Stahl) Date: Mon, 31 Jan 2000 16:45:41 +0100 Subject: Problem building OpenSSH-1.2.2 on HP-UX In-Reply-To: <3895AC3A.26788B1E@dial.pipex.com> References: <20000131161652.A21653@fors.lsw.uni-heidelberg.de> <3895AC3A.26788B1E@dial.pipex.com> Message-ID: <20000131164541.A21826@fors.lsw.uni-heidelberg.de> On Mon, Jan 31, 2000 at 03:37:30PM +0000, Andre Lucas wrote: > Is it possible you could send the compiler errors for the unedited > OpenSSH 1.2.2, and the contents of config.h after running configure? Thank you for the fast reply! I attach config.h The first compiler error is: gcc -g -O2 -Wall -I/usr/local/ssl/include -D_HPUX_SOURCE -DETCDIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh/ssh-askpass\" -DHAVE_CONFIG_H -c login.c login.c:236: parse error before &' login.c:236: warning: type defaults to int' in declaration of login' login.c:236: conflicting types for login' bsd-login.h:12: previous declaration of login' login.c:236: warning: data definition has no type or storage class *** Error exit code 1 Stop. After commenting line 236, I get: gcc -g -O2 -Wall -I/usr/local/ssl/include -D_HPUX_SOURCE -DETCDIR=\"/usr/local/etc\" -DSSH_PROGRAM=\"/usr/local/bin/ssh\" -DSSH_ASKPASS_DEFAULT=\"/usr/local/libexec/ssh/ssh-askpass\" -DHAVE_CONFIG_H -c login.c login.c:272: parse error before }' *** Error exit code 1 Stop. Kind regards, Otmar > Ta, > -Andre > > Otmar Stahl wrote: > > > > Hi, > > > > Just wanted to let you know, that I had a small problem when compiling > > OpenSSH-1.2.2 on a HP-UX 10.20 trusted system. I used gcc-2.95.2 as > > compiler. I finally could compile it, but I had to comment two lines in > > login.c. (I am using openssl-0.9.4 and egd-0.6, if this matters.) > > > > line 236: > > > > login(&u, &utx); > > > > and the closing brace in line 272. > > > > Commenting these two lines it compiled ok and also seems to run fine. > > > > Kind regards, > > Otmar Stahl -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: config.h Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20000131/68c8e065/attachment.h From O.Stahl at lsw.uni-heidelberg.de Tue Feb 1 02:48:35 2000 From: O.Stahl at lsw.uni-heidelberg.de (Otmar Stahl) Date: Mon, 31 Jan 2000 16:48:35 +0100 Subject: Problem building OpenSSH-1.2.2 on HP-UX In-Reply-To: <3895AC3A.26788B1E@dial.pipex.com> References: <20000131161652.A21653@fors.lsw.uni-heidelberg.de> <3895AC3A.26788B1E@dial.pipex.com> Message-ID: <20000131164835.A21868@fors.lsw.uni-heidelberg.de> Hello again, I forgot to mention that I see error messages in the syslog of the form: Jan 31 16:34:13 hp3 sshd[5320]: error: ioctl I_PUSH ttcompat: Invalid argument Nevertheless, everything seems to work ok. Kind regards, Otmar On Mon, Jan 31, 2000 at 03:37:30PM +0000, Andre Lucas wrote: > Is it possible you could send the compiler errors for the unedited > OpenSSH 1.2.2, and the contents of config.h after running configure? > > Ta, > -Andre > > Otmar Stahl wrote: > > > > Hi, > > > > Just wanted to let you know, that I had a small problem when compiling > > OpenSSH-1.2.2 on a HP-UX 10.20 trusted system. I used gcc-2.95.2 as > > compiler. I finally could compile it, but I had to comment two lines in > > login.c. (I am using openssl-0.9.4 and egd-0.6, if this matters.) > > > > line 236: > > > > login(&u, &utx); > > > > and the closing brace in line 272. > > > > Commenting these two lines it compiled ok and also seems to run fine. > > > > Kind regards, > > Otmar Stahl From ishikawa at yk.rim.or.jp Tue Feb 1 04:39:57 2000 From: ishikawa at yk.rim.or.jp (Ishikawa) Date: Tue, 01 Feb 2000 02:39:57 +0900 Subject: 1.2.2 : transport endpoint is not connected. Message-ID: <3895C8ED.E63CBB16@yk.rim.or.jp> Hi, Thank you for the great OpenSSH package. I obtained 1.2.2 and tried it on linux 2.2.14. I had reported earlier that I saw "Transport endpoint is not connected" warning messages were observed on the linux 2.2.14 kernel with earlier release of openssh. The same happens when I used the port-forwarded HTTP connection. But this time, after accessing such http connections, I noticed that there are now cases of "[i1 o16] " as opposed to [i1 o128]" in the warning messages. Following is a copy of real warning message I collected a few minutes ago. [o128 meant the connection was closed. But o16 seems to suggest that output was open. from nchan.h: #define CHAN_OUTPUT_OPEN 0x10 #define CHAN_OUTPUT_WAIT_DRAIN 0x20 #define CHAN_OUTPUT_WAIT_IEOF 0x40 #define CHAN_OUTPUT_CLOSED 0x80 So something seems to be wrong.] chan_shutdown_read failed for #12/fd16 [i1 o16]: Transport endpoint is not connected chan_shutdown_read failed for #9/fd13 [i1 o128]: Transport endpoint is not connected chan_shutdown_read failed for #13/fd17 [i1 o128]: Transport endpoint is not connected chan_shutdown_read failed for #8/fd12 [i1 o128]: Transport endpoint is not connected chan_shutdown_read failed for #12/fd16 [i1 o128]: Transport endpoint is not connected chan_shutdown_read failed for #13/fd17 [i1 o128]: Transport endpoint is not connected chan_shutdown_read failed for #15/fd19 [i1 o128]: Transport endpoint is not connected chan_shutdown_read failed for #14/fd18 [i1 o128]: Transport endpoint is not connected chan_shutdown_read failed for #8/fd12 [i1 o128]: Transport endpoint is not connected chan_shutdown_read failed for #8/fd12 [i1 o128]: Transport endpoint is not connected chan_shutdown_read failed for #10/fd14 [i1 o128]: Transport endpoint is not connected chan_shutdown_read failed for #12/fd16 [i1 o16]: Transport endpoint is not connected chan_shutdown_read failed for #9/fd13 [i1 o128]: Transport endpoint is not connected chan_shutdown_read failed for #8/fd12 [i1 o16]: Transport endpoint is not connected chan_shutdown_read failed for #13/fd17 [i1 o128]: Transport endpoint is not connected The gateway that runs sshd is Solaris 2.5.1. But the port-forwarded http server beyond that sshd host is sunos 4.1.4 if memory serves. Thak you again for the package. Happy Hacking From andre.lucas at dial.pipex.com Tue Feb 1 09:06:36 2000 From: andre.lucas at dial.pipex.com (Andre Lucas) Date: Mon, 31 Jan 2000 22:06:36 +0000 Subject: New liblogin 0.3alpha Message-ID: <20000131220636.A689@internal.domain> FYI a new version of liblogin, 0.3alpha, is up on my website at http://dspace.dial.pipex.com/andre.lucas/liblogin.html This version fixes a few bugs and has implementations for the full API, including 'get last login time' support, even for systems without lastlog. New OpenSSH patches against 1.2.2 are also available, to enable the last login time features. Again, the function (in this case get_last_login_time() ) reduces to four lines as the busy-work is shipped out of openssh-main and into the library. It's tested and running well on Linux, OpenBSD, HPUX10.20 and Solaris. Please check it out, and let me know how you get on. I'm particularly keen to see how it does on other platforms. The main todo right now is to add support for systems that don't define _PATH_UTMP etc. This will probably require file checks, which is a shame because I then lose the ability to cross-compile easily. Oh, well. Ta, -Andre -- Andre Lucas http://dspace.dial.pipex.com/andre.lucas/ From rlm at pricegrabber.com Tue Feb 1 16:17:59 2000 From: rlm at pricegrabber.com (Rob McMillin) Date: Mon, 31 Jan 2000 21:17:59 -0800 Subject: Making root equivalence work Message-ID: <38966C87.670FC194@pricegrabber.com> I have several machines that must have trusted root accounts, that is, I need to be able to run "ssh targethost command" on each by each, for the root user. I have had no success thus far doing so. Normally for the non-root users, all I have to do is set the /etc/ssh/known_hosts, build up the users' ~/.ssh/known_hosts, and the users will work without requiring passwords. (I'm using method 2 authentication.) All run openssh-1.2.1. What files do I need to configure? I already have PermitRootLogin yes RhostsRSAAuthentication yes in /etc/ssh/sshd_config. What am I missing? I still get prompted for a password every time I try to log in as root. -- http://www.pricegrabber.com | The best deals, all the time. From djm at mindrot.org Tue Feb 1 23:14:21 2000 From: djm at mindrot.org (Damien Miller) Date: Tue, 1 Feb 2000 23:14:21 +1100 (EST) Subject: rsync over ssh - lockups with pipe() In-Reply-To: <20000129123333Z13356428-11511+45588@samba.anu.edu.au> Message-ID: On Sat, 29 Jan 2000 tridge at linuxcare.com wrote: > For a couple of years people have been reporting intermittent problems > with rsync over ssh freezing during a large transfer (typically > several GB). I have now gotten to the bottom of these problems, and > have written a small test program which demonstrates a deadlock in > sshd when doing large bi-directional transfers. Luckily the problem is > easily solved by modifying sshd to use socketpair() instead of > pipe(). Just remove "#define USE_PIPES 1" from near the bottom of > includes.h does the trick. Behaviour (and fix) verified under Linux 2.2.12. OpenBSD 2.6 + errata seems not be affected. Can anyone detect any problems when using socket pairs? If not, I shall make it the default. Regards, Damien -- | "Bombay is 250ms from New York in the new world order" - Alan Cox | Damien Miller - http://www.mindrot.org/ | Email: djm at mindrot.org (home) -or- djm at ibs.com.au (work) From djm at mindrot.org Tue Feb 1 23:15:39 2000 From: djm at mindrot.org (Damien Miller) Date: Tue, 1 Feb 2000 23:15:39 +1100 (EST) Subject: problems logging in from 1.2.2 client to 1.2.1pre24 server In-Reply-To: Message-ID: On Sat, 29 Jan 2000, Marc Haber wrote: > Hi! > > On my personal workstation, I have installed openssh 1.2.2. I > have two server machines, one (A) running a self-compiled openssh > 1.2.1pre24, and a different one (B) running an openssh1.2.1pre24 > compiled by someone else. What Platform & OS? what options was OpenSSH complied with? Damien -- | "Bombay is 250ms from New York in the new world order" - Alan Cox | Damien Miller - http://www.mindrot.org/ | Email: djm at mindrot.org (home) -or- djm at ibs.com.au (work) From djm at mindrot.org Tue Feb 1 23:17:23 2000 From: djm at mindrot.org (Damien Miller) Date: Tue, 1 Feb 2000 23:17:23 +1100 (EST) Subject: ssh-1.2.2 freeze under Linux In-Reply-To: <200001292300.SAA11461@styx.net.copi> Message-ID: On Sat, 29 Jan 2000, Craig J Copi wrote: > After compiling and installing ssh-1.2.2 at home whenever I try to ssh > to a host ssh freezes and never actually tries to establish a > connection. Actually it depends on whether I'm dialed in or not > (it has to do with dns lookups, I'm not sure exactly what it is > doing). The problem seems to be caused by getaddrinfo in ssh.c, > line 511. If I strace the process it keeps trying to connect to my > dns server to resolve the name. If I use the full host name (or > if I'm dialed in) it claims > Secure connection to full.host.name refused. > However, no connection attempt is logged on the remote machine. Try the --with-ipv4-default option. Damien -- | "Bombay is 250ms from New York in the new world order" - Alan Cox | Damien Miller - http://www.mindrot.org/ | Email: djm at mindrot.org (home) -or- djm at ibs.com.au (work) From cjc5 at po.cwru.edu Wed Feb 2 02:10:06 2000 From: cjc5 at po.cwru.edu (Craig J Copi) Date: Tue, 01 Feb 2000 10:10:06 -0500 Subject: ssh-1.2.2 freeze under Linux In-Reply-To: Your message of "Tue, 01 Feb 2000 23:17:23 +1100." Message-ID: <200002011510.KAA30997@boss.phys.cwru.edu> Damien Miller writes: >On Sat, 29 Jan 2000, Craig J Copi wrote: > >> After compiling and installing ssh-1.2.2 at home whenever I try to ssh >> to a host ssh freezes and never actually tries to establish a >> connection. Actually it depends on whether I'm dialed in or not >> (it has to do with dns lookups, I'm not sure exactly what it is >> doing). The problem seems to be caused by getaddrinfo in ssh.c, >> line 511. If I strace the process it keeps trying to connect to my >> dns server to resolve the name. If I use the full host name (or >> if I'm dialed in) it claims >> Secure connection to full.host.name refused. >> However, no connection attempt is logged on the remote machine. > >Try the --with-ipv4-default option. > >Damien I did. I used the RH spec file that comes with with the distribution. Craig From dwd at bell-labs.com Wed Feb 2 05:11:41 2000 From: dwd at bell-labs.com (Dave Dykstra) Date: Tue, 1 Feb 2000 12:11:41 -0600 Subject: looking for commercial supporters of openssh Message-ID: <20000201121141.A4405@lucent.com> The organization that sets standards for Unix software in my company is in the process of seeking a replacement for an internally-written remote command execution tool (essentially an rsh with extra features such as pseudo-tty support), and I'm trying to pursuade them to use ssh and ultimately openssh. Since we're Bell Labs, we have a lot of Unix machines. One of the things that organization requires is somebody to supply them with binaries for several different unix platforms and to promise them 7x24 hotline support. Of course they are willing to pay for that support. I could provide them binaries (I already provide ssh 1.2.27 to a non-privileged area on the bulk of the unix machines) but they're not comfortable with relying on one of their own employees for the round-the-clock support. I know that the license on ssh 1.2.27 prevents any company but f-secure from supporting that tool, but I'm looking forward to the time when openssh will be ready for them. If any of you have good suggestions for companies that will do a good job of this for openssh, please let me know right away. - Dave Dykstra From jmd at aoe.vt.edu Wed Feb 2 07:20:39 2000 From: jmd at aoe.vt.edu (Josh Durham) Date: Tue, 1 Feb 2000 15:20:39 -0500 Subject: login.c error Message-ID: I had a compile-time error in login.c .. It looks like someone was copying and pasting code and didn't check the variable names. Here's the diff: diff login.c.orig login.c 258c258 < snprintf(buf, sizeof(buf), "%s/%s", lastlog, logname); --- > snprintf(buf, sizeof(buf), "%s/%s", lastlog, user); - Josh * Josh Durham | AOE at Virginia Tech | (540) 231-9061 jdurham at vt.edu * From gem at rellim.com Wed Feb 2 08:08:06 2000 From: gem at rellim.com (Gary E. Miller) Date: Tue, 1 Feb 2000 13:08:06 -0800 (PST) Subject: EGD requirement a show stopper for me In-Reply-To: <3895A44B.7FB4B62D@dial.pipex.com> Message-ID: Yo All! A archive of the discussions on /dev/random from the linux-ipsec and coderpunks mailing lists is at: http://www.openpgp.net/random/index.html They have already covered this territory at length. There is also the source to a linux kernel /dev/random on that website and in it's doc the recommendation is made to save the entropy. I think the end result was that it was best to save what entropy that you had between sessions. Since this saved entropy should just be stirred in with whatever new entropy you can find, then you should never be worse off even if the old entropy is compromised. RGDS GARY On Mon, 31 Jan 2000, Andre Lucas wrote: > I'm no authority of any kind on PRNG implementations or the software > you've listed. So this is just a barely educated opinion. I think it's a > good thing to save the random seed, as if you have confidence in your > PRNG it's a good random value with which to initialise the generator. > Since my understanding is that good entropy is hard to find(tm), why > waste it? --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676 From karn at ka9q.ampr.org Wed Feb 2 08:48:33 2000 From: karn at ka9q.ampr.org (Phil Karn) Date: Tue, 1 Feb 2000 13:48:33 -0800 Subject: rsync over ssh - lockups with pipe() In-Reply-To: (message from Damien Miller on Tue, 1 Feb 2000 23:14:21 +1100 (EST)) References: Message-ID: <200002012148.NAA29502@homer.ka9q.ampr.org> >Can anyone detect any problems when using socket pairs? If not, I >shall make it the default. I'd still been noticing some occasional hangups in 1.2.2 while websurfing over a forwarded TCP connection. Both ends run Linux 2.2.14. I just commented out USE_PIPES in my builds and I'll see how this goes over the next couple of days. Phil From dwd at bell-labs.com Wed Feb 2 08:55:40 2000 From: dwd at bell-labs.com (Dave Dykstra) Date: Tue, 1 Feb 2000 15:55:40 -0600 Subject: EGD requirement a show stopper for me In-Reply-To: ; from Gary E. Miller on Tue, Feb 01, 2000 at 01:08:06PM -0800 References: <3895A44B.7FB4B62D@dial.pipex.com> Message-ID: <20000201155539.A13302@lucent.com> On Tue, Feb 01, 2000 at 01:08:06PM -0800, Gary E. Miller wrote: > Yo All! > > A archive of the discussions on /dev/random from the linux-ipsec > and coderpunks mailing lists is at: > http://www.openpgp.net/random/index.html > > They have already covered this territory at length. The access to the archive is kind of slow so I haven't seen it all, but I haven't spotted where they're talking about avoiding the use of /dev/random. Ipsec is a different situation because by its nature it will not be portable and, unlike ssh, they can make operating system changes. > There is also the source to a linux kernel /dev/random on that > website and in it's doc the recommendation is made to save the entropy. > > I think the end result was that it was best to save what entropy > that you had between sessions. Since this saved entropy should > just be stirred in with whatever new entropy you can find, then > you should never be worse off even if the old entropy is compromised. > > RGDS > GARY > > On Mon, 31 Jan 2000, Andre Lucas wrote: > > > I'm no authority of any kind on PRNG implementations or the software > > you've listed. So this is just a barely educated opinion. I think it's a > > good thing to save the random seed, as if you have confidence in your > > PRNG it's a good random value with which to initialise the generator. > > Since my understanding is that good entropy is hard to find(tm), why > > waste it? Ok, maybe I'm missing something. If you have a good initial seed to your PRNG and you save it in a protected file the way ssh 1.2.27 does, is there any problem with not using the EGD (or /dev/random because it's not available)? We could take some of the code from the EGD (ported to C) or from some other open source package to get the initial seed, when we don't mind spending a little extra time, and from then on do things more quickly without the aid of an external program or driver. Right? - Dave Dykstra From karn at ka9q.ampr.org Wed Feb 2 08:57:05 2000 From: karn at ka9q.ampr.org (Phil Karn) Date: Tue, 1 Feb 2000 13:57:05 -0800 Subject: logging RSA key IDs Message-ID: <200002012157.NAA29530@homer.ka9q.ampr.org> Hi. To compartmentalize things a bit (e.g., to help limit the damage should one of my machines be hacked and my private RSA keys stolen) I use different RSA key pairs on my different client machines. So it occurs to me that it would be nice if ssh could log which key was used when logging in to a particular account that has more than one entry in .ssh/authorized_keys. Right now it simply says "Accepted rsa for karn from " without saying which key was used. You obviously don't want to log the whole public key, just the comment field from the appropriate line in .ssh/authorized_keys would do. Phil From Marc.Haber-lists at gmx.de Wed Feb 2 09:32:57 2000 From: Marc.Haber-lists at gmx.de (Marc Haber) Date: Tue, 01 Feb 2000 22:32:57 GMT Subject: problems logging in from 1.2.2 client to 1.2.1pre24 server In-Reply-To: References: Message-ID: On Tue, 1 Feb 2000 23:15:39 +1100 (EST), you wrote: >On Sat, 29 Jan 2000, Marc Haber wrote: >> On my personal workstation, I have installed openssh 1.2.2. I >> have two server machines, one (A) running a self-compiled openssh >> 1.2.1pre24, and a different one (B) running an openssh1.2.1pre24 >> compiled by someone else. > >What Platform & OS? All three boxes are running Debian Linux on i386 type machines, fairly standard PC hardware. My personal machine is running the frozen beta version of Debian, potato, and the two servers run the stable released version of debian, slink. >what options was OpenSSH complied with? Can't say about the server boxes, on my client box I did a plain configure. I found out today that I can log in to both boxes using RSA authentication, but login to one of the servers still fails when I try to do plain password authentication. The error message is somewhat strange. Greetings Marc -- -------------------------------------- !! No courtesy copies, please !! ----- Marc Haber | " Questions are the | Mailadresse im Header Karlsruhe, Germany | Beginning of Wisdom " | Fon: *49 721 966 32 15 Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fax: *49 721 966 31 29 From karn at ka9q.ampr.org Wed Feb 2 09:44:27 2000 From: karn at ka9q.ampr.org (Phil Karn) Date: Tue, 1 Feb 2000 14:44:27 -0800 Subject: problems logging in from 1.2.2 client to 1.2.1pre24 server In-Reply-To: (Marc.Haber-lists@gmx.de) References:

Message-ID: <200002012244.OAA29609@homer.ka9q.ampr.org> >I found out today that I can log in to both boxes using RSA >authentication, but login to one of the servers still fails when I try >to do plain password authentication. The error message is somewhat >strange. Try enabling shadow passwords. I had the same problem on my debian linux systems a while back, and enabling shadow passwords made the problem go away. Phil From gem at rellim.com Wed Feb 2 10:00:20 2000 From: gem at rellim.com (Gary E. Miller) Date: Tue, 1 Feb 2000 15:00:20 -0800 (PST) Subject: EGD requirement a show stopper for me In-Reply-To: <20000201155539.A13302@lucent.com> Message-ID: Yo Dave! The whole point of /dev/random is to add entropy to PNRG. The problem with a PNRG is that once you figure out the internal state of the PNRG you can recover past states and predict future states. Once you can predict states, even if the prediction is slightly off, then you have seriously reduced the strength of the encryption. This is the basis of the cracks for S/Key and some other crypto. The solution to this problem is to add entropy to your PNRG to make it more truly random. That is why openssh wants to use /dev/random or EGD at regular intervals. EGD is to much of a pig and /dev/random requires kernel patching. So I agree with you that porting something like EGD to C is the way to go. FreeS/WAN struggled with this issue for a while and then decided to just go with /dev/random. open-ssh does not have that option. RGDS GARY On Tue, 1 Feb 2000, Dave Dykstra wrote: > Date: Tue, 1 Feb 2000 15:55:40 -0600 > From: Dave Dykstra > To: Gary E. Miller > Cc: openssh-unix-dev at mindrot.org > Subject: Re: EGD requirement a show stopper for me > > On Tue, Feb 01, 2000 at 01:08:06PM -0800, Gary E. Miller wrote: > > Yo All! > > > > A archive of the discussions on /dev/random from the linux-ipsec > > and coderpunks mailing lists is at: > > http://www.openpgp.net/random/index.html > > > > They have already covered this territory at length. > > The access to the archive is kind of slow so I haven't seen it all, but I > haven't spotted where they're talking about avoiding the use of > /dev/random. Ipsec is a different situation because by its nature it will > not be portable and, unlike ssh, they can make operating system changes. > > > There is also the source to a linux kernel /dev/random on that > > website and in it's doc the recommendation is made to save the entropy. > > > > I think the end result was that it was best to save what entropy > > that you had between sessions. Since this saved entropy should > > just be stirred in with whatever new entropy you can find, then > > you should never be worse off even if the old entropy is compromised. > > > > RGDS > > GARY > > > > On Mon, 31 Jan 2000, Andre Lucas wrote: > > > > > I'm no authority of any kind on PRNG implementations or the software > > > you've listed. So this is just a barely educated opinion. I think it's a > > > good thing to save the random seed, as if you have confidence in your > > > PRNG it's a good random value with which to initialise the generator. > > > Since my understanding is that good entropy is hard to find(tm), why > > > waste it? > > > Ok, maybe I'm missing something. If you have a good initial seed to your > PRNG and you save it in a protected file the way ssh 1.2.27 does, is there > any problem with not using the EGD (or /dev/random because it's not > available)? We could take some of the code from the EGD (ported to C) or > from some other open source package to get the initial seed, when we don't > mind spending a little extra time, and from then on do things more quickly > without the aid of an external program or driver. Right? > > - Dave Dykstra > --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676 From djm at mindrot.org Wed Feb 2 19:17:37 2000 From: djm at mindrot.org (Damien Miller) Date: Wed, 2 Feb 2000 19:17:37 +1100 (EST) Subject: login.c error In-Reply-To: Message-ID: On Tue, 1 Feb 2000, Josh Durham wrote: > I had a compile-time error in login.c .. It looks like someone > was copying and pasting code and didn't check the variable names. > Here's the diff: Thanks, applied. -d -- | "Bombay is 250ms from New York in the new world order" - Alan Cox | Damien Miller - http://www.mindrot.org/ | Email: djm at mindrot.org (home) -or- djm at ibs.com.au (work) From Marc.Haber-lists at gmx.de Wed Feb 2 19:21:48 2000 From: Marc.Haber-lists at gmx.de (Marc Haber) Date: Wed, 02 Feb 2000 08:21:48 GMT Subject: problems logging in from 1.2.2 client to 1.2.1pre24 server In-Reply-To: <200002012244.OAA29609@homer.ka9q.ampr.org> References:

winterlions' page From ache at nagual.pp.ru Sun Feb 27 11:01:49 2000 From: ache at nagual.pp.ru (Andrey A. Chernov) Date: Sun, 27 Feb 2000 03:01:49 +0300 Subject: [PATCH] Fix login.conf, expiration, BSD compatibility in OpenSSH Message-ID: <20000227030149.A6864@nagual.pp.ru> This patch revive almost all login.conf and password/account expiration features, makes OpenSSH more FreeBSD login compatible and fix non-critical memory leak. Please review and commit. --- sshd.c.old Fri Feb 25 08:23:45 2000 +++ sshd.c Sun Feb 27 02:53:33 2000 @@ -37,9 +37,8 @@ #endif /* LIBWRAP */ #ifdef __FreeBSD__ -#include -#include #define LOGIN_CAP +#define _PATH_CHPASS "/usr/bin/passwd" #endif /* __FreeBSD__ */ #ifdef LOGIN_CAP @@ -1246,6 +1245,7 @@ return 0; } } +#ifndef __FreeBSD__ /* FreeBSD handle it later */ /* Fail if the account's expiration time has passed. */ if (pw->pw_expire != 0) { struct timeval tv; @@ -1254,6 +1254,7 @@ if (tv.tv_sec >= pw->pw_expire) return 0; } +#endif /* !__FreeBSD__ */ /* We found no reason not to let this user try to log on... */ return 1; } @@ -1268,6 +1269,12 @@ struct passwd *pw, pwcopy; int plen, ulen; char *user; +#ifdef LOGIN_CAP + login_cap_t *lc; + char *hosts; + const char *from_host, *from_ip; + int denied; +#endif /* LOGIN_CAP */ /* Get the name of the user that we wish to log in as. */ packet_read_expect(&plen, SSH_CMSG_USER); @@ -1338,6 +1345,38 @@ packet_disconnect("ROOT LOGIN REFUSED FROM %.200s", get_canonical_hostname()); } + +#ifdef LOGIN_CAP + lc = login_getpwclass(pw); + if (lc == NULL) + lc = login_getclassbyname(NULL, pw); + from_host = get_canonical_hostname(); + from_ip = get_remote_ipaddr(); + + denied = 0; + if ((hosts = login_getcapstr(lc, "host.deny", NULL, NULL)) != NULL) { + denied = match_hostname(from_host, hosts, strlen(hosts)); + if (!denied) + denied = match_hostname(from_ip, hosts, strlen(hosts)); + } + if (!denied && + (hosts = login_getcapstr(lc, "host.allow", NULL, NULL)) != NULL) { + denied = !match_hostname(from_host, hosts, strlen(hosts)); + if (denied) + denied = !match_hostname(from_ip, hosts, strlen(hosts)); + } + login_close(lc); + if (denied) { + log("Denied connection for %.200s from %.200s [%.200s].", + pw->pw_name, from_host, from_ip); + packet_disconnect("Sorry, you are not allowed to connect."); + } +#endif /* LOGIN_CAP */ + + if (pw->pw_uid == 0) + log("ROOT LOGIN as '%.100s' from %.100s", + pw->pw_name, get_canonical_hostname()); + /* The user has been authenticated and accepted. */ packet_start(SSH_SMSG_SUCCESS); packet_send(); @@ -2086,6 +2125,11 @@ login_cap_t *lc; char *fname; #endif /* LOGIN_CAP */ +#ifdef __FreeBSD__ +#define DEFAULT_WARN (2L * 7L * 86400L) /* Two weeks */ + struct timeval tv; + time_t warntime = DEFAULT_WARN; +#endif /* __FreeBSD__ */ /* Get remote host name. */ hostname = get_canonical_hostname(); @@ -2157,6 +2201,50 @@ quiet_login = login_getcapbool(lc, "hushlogin", quiet_login); #endif /* LOGIN_CAP */ +#ifdef __FreeBSD__ + if (pw->pw_change || pw->pw_expire) + (void)gettimeofday(&tv, NULL); +#ifdef LOGIN_CAP + warntime = login_getcaptime(lc, "warnpassword", + DEFAULT_WARN, DEFAULT_WARN); +#endif /* LOGIN_CAP */ + /* + * If the password change time is set and has passed, give the + * user a password expiry notice and chance to change it. + */ + if (pw->pw_change != 0) { + if (tv.tv_sec >= pw->pw_change) { + (void)printf( + "Sorry -- your password has expired.\n"); + log("%s Password expired - forcing change", + pw->pw_name); + command = _PATH_CHPASS; + } else if (pw->pw_change - tv.tv_sec < warntime && + !quiet_login) + (void)printf( + "Warning: your password expires on %s", + ctime(&pw->pw_change)); + } +#ifdef LOGIN_CAP + warntime = login_getcaptime(lc, "warnexpire", + DEFAULT_WARN, DEFAULT_WARN); +#endif /* LOGIN_CAP */ + if (pw->pw_expire) { + if (tv.tv_sec >= pw->pw_expire) { + (void)printf( + "Sorry -- your account has expired.\n"); + log( + "LOGIN %.200s REFUSED (EXPIRED) FROM %.200s ON TTY %.200s", + pw->pw_name, hostname, ttyname); + exit(254); + } else if (pw->pw_expire - tv.tv_sec < warntime && + !quiet_login) + (void)printf( + "Warning: your account expires on %s", + ctime(&pw->pw_expire)); + } +#endif /* __FreeBSD__ */ + /* * If the user has logged in before, display the time of last * login. However, don't display anything extra if a command @@ -2203,10 +2291,9 @@ !options.use_login) { #ifdef LOGIN_CAP fname = login_getcapstr(lc, "welcome", NULL, NULL); - login_close(lc); if (fname == NULL || (f = fopen(fname, "r")) == NULL) f = fopen("/etc/motd", "r"); -#else /* LOGIN_CAP */ +#else /* !LOGIN_CAP */ f = fopen("/etc/motd", "r"); #endif /* LOGIN_CAP */ /* Print /etc/motd if it exists. */ @@ -2216,6 +2303,9 @@ fclose(f); } } +#ifdef LOGIN_CAP + login_close(lc); +#endif /* LOGIN_CAP */ /* Do common processing for the child, such as execing the command. */ do_child(command, pw, term, display, auth_proto, auth_data, ttyname); @@ -2363,7 +2453,7 @@ char buf[256]; FILE *f; unsigned int envsize, i; - char **env; + char **env = NULL; extern char **environ; struct stat st; char *argv[10]; @@ -2373,29 +2463,24 @@ lc = login_getpwclass(pw); if (lc == NULL) lc = login_getclassbyname(NULL, pw); -#endif /* LOGIN_CAP */ - + if (pw->pw_uid != 0) + auth_checknologin(lc); +#else /* !LOGIN_CAP */ f = fopen("/etc/nologin", "r"); -#ifdef __FreeBSD__ - if (f == NULL) - f = fopen("/var/run/nologin", "r"); -#endif /* __FreeBSD__ */ if (f) { /* /etc/nologin exists. Print its contents and exit. */ -#ifdef LOGIN_CAP - /* On FreeBSD, etc., allow overriding nologin via login.conf. */ - if (!login_getcapbool(lc, "ignorenologin", 0)) { -#else /* LOGIN_CAP */ - if (1) { -#endif /* LOGIN_CAP */ - while (fgets(buf, sizeof(buf), f)) - fputs(buf, stderr); - fclose(f); - if (pw->pw_uid != 0) - exit(254); - } + while (fgets(buf, sizeof(buf), f)) + fputs(buf, stderr); + fclose(f); + if (pw->pw_uid != 0) + exit(254); } +#endif /* LOGIN_CAP */ + +#ifdef LOGIN_CAP + if (options.use_login) +#endif /* LOGIN_CAP */ /* Set login name in the kernel. */ if (setlogin(pw->pw_name) < 0) error("setlogin failed: %s", strerror(errno)); @@ -2405,12 +2490,42 @@ switch, so we let login(1) to this for us. */ if (!options.use_login) { #ifdef LOGIN_CAP - if (setclasscontext(pw->pw_class, LOGIN_SETPRIORITY | - LOGIN_SETRESOURCES | LOGIN_SETUMASK) == -1) { - perror("setclasscontext"); - exit(1); - } -#endif /* LOGIN_CAP */ + char **tmpenv; + + /* Initialize temp environment */ + envsize = 64; + env = xmalloc(envsize * sizeof(char *)); + env[0] = NULL; + + child_set_env(&env, &envsize, "PATH", + (pw->pw_uid == 0) ? + _PATH_STDPATH : _PATH_DEFPATH); + + snprintf(buf, sizeof buf, "%.200s/%.50s", + _PATH_MAILDIR, pw->pw_name); + child_set_env(&env, &envsize, "MAIL", buf); + + if (getenv("TZ")) + child_set_env(&env, &envsize, "TZ", getenv("TZ")); + + /* Save parent environment */ + tmpenv = environ; + environ = env; + + if (setusercontext(lc, pw, pw->pw_uid, LOGIN_SETALL) < 0) + fatal("setusercontext failed: %s", strerror(errno)); + + /* Restore parent environment */ + env = environ; + environ = tmpenv; + + for (envsize = 0; env[envsize] != NULL; ++envsize) + ; + envsize = (envsize < 100) ? 100 : envsize + 16; + env = xrealloc(env, envsize * sizeof(char *)); + +#else /* !LOGIN_CAP */ + if (getuid() == 0 || geteuid() == 0) { if (setgid(pw->pw_gid) < 0) { perror("setgid"); @@ -2428,18 +2543,15 @@ } if (getuid() != pw->pw_uid || geteuid() != pw->pw_uid) fatal("Failed to set uids to %d.", (int) pw->pw_uid); +#endif /* LOGIN_CAP */ } /* * Get the shell from the password data. An empty shell field is * legal, and means /bin/sh. */ + shell = (pw->pw_shell[0] == '\0') ? _PATH_BSHELL : pw->pw_shell; #ifdef LOGIN_CAP - shell = pw->pw_shell; shell = login_getcapstr(lc, "shell", shell, shell); - if (shell[0] == '\0') - shell = _PATH_BSHELL; -#else /* LOGIN_CAP */ - shell = (pw->pw_shell[0] == '\0') ? _PATH_BSHELL : pw->pw_shell; #endif /* LOGIN_CAP */ #ifdef AFS @@ -2455,29 +2567,31 @@ #endif /* AFS */ /* Initialize the environment. */ - envsize = 100; - env = xmalloc(envsize * sizeof(char *)); - env[0] = NULL; + if (env == NULL) { + envsize = 100; + env = xmalloc(envsize * sizeof(char *)); + env[0] = NULL; + } if (!options.use_login) { /* Set basic environment. */ child_set_env(&env, &envsize, "USER", pw->pw_name); child_set_env(&env, &envsize, "LOGNAME", pw->pw_name); child_set_env(&env, &envsize, "HOME", pw->pw_dir); -#ifdef LOGIN_CAP - child_set_env(&env, &envsize, "PATH", - login_getpath(lc, "path", _PATH_STDPATH)); -#else /* LOGIN_CAP */ +#ifndef LOGIN_CAP child_set_env(&env, &envsize, "PATH", _PATH_STDPATH); -#endif /* LOGIN_CAP */ snprintf(buf, sizeof buf, "%.200s/%.50s", _PATH_MAILDIR, pw->pw_name); child_set_env(&env, &envsize, "MAIL", buf); +#endif /* !LOGIN_CAP */ /* Normal systems set SHELL by default. */ child_set_env(&env, &envsize, "SHELL", shell); } +#ifdef LOGIN_CAP + if (options.use_login) +#endif /* LOGIN_CAP */ if (getenv("TZ")) child_set_env(&env, &envsize, "TZ", getenv("TZ")); @@ -2559,10 +2673,6 @@ */ endpwent(); -#ifdef LOGIN_CAP - login_close(lc); -#endif /* LOGIN_CAP */ - /* * Close any extra open file descriptors so that we don\'t have them * hanging around in clients. Note that we want to do this after @@ -2573,9 +2683,46 @@ close(i); /* Change current directory to the user\'s home directory. */ - if (chdir(pw->pw_dir) < 0) + if ( +#ifdef __FreeBSD__ + !*pw->pw_dir || +#endif /* __FreeBSD__ */ + chdir(pw->pw_dir) < 0 + ) { +#ifdef __FreeBSD__ + int quiet_login = 0; +#endif /* __FreeBSD__ */ +#ifdef LOGIN_CAP + if (login_getcapbool(lc, "requirehome", 0)) { + (void)printf("Home directory not available\n"); + log("LOGIN %.200s REFUSED (HOMEDIR) ON TTY %.200s", + pw->pw_name, ttyname); + exit(254); + } +#endif /* LOGIN_CAP */ +#ifdef __FreeBSD__ + if (chdir("/") < 0) { + (void)printf("Cannot find root directory\n"); + log("LOGIN %.200s REFUSED (ROOTDIR) ON TTY %.200s", + pw->pw_name, ttyname); + exit(254); + } +#ifdef LOGIN_CAP + quiet_login = login_getcapbool(lc, "hushlogin", 0); +#endif /* LOGIN_CAP */ + if (!quiet_login || *pw->pw_dir) + (void)printf( + "No home directory.\nLogging in with home = \"/\".\n"); + +#else /* !__FreeBSD__ */ + fprintf(stderr, "Could not chdir to home directory %s: %s\n", pw->pw_dir, strerror(errno)); +#endif /* __FreeBSD__ */ + } +#ifdef LOGIN_CAP + login_close(lc); +#endif /* LOGIN_CAP */ /* * Must take new environment into use so that .ssh/rc, /etc/sshrc and @@ -2588,26 +2735,6 @@ * in this order). */ if (!options.use_login) { -#ifdef __FreeBSD__ - /* - * If the password change time is set and has passed, give the - * user a password expiry notice and chance to change it. - */ - if (pw->pw_change != 0) { - struct timeval tv; - - (void)gettimeofday(&tv, NULL); - if (tv.tv_sec >= pw->pw_change) { - (void)printf( - "Sorry -- your password has expired.\n"); - syslog(LOG_INFO, - "%s Password expired - forcing change", - pw->pw_name); - if (system("/usr/bin/passwd") != 0) - perror("/usr/bin/passwd"); - } - } -#endif /* __FreeBSD__ */ if (stat(SSH_USER_RC, &st) >= 0) { if (debug_flag) fprintf(stderr, "Running /bin/sh %s\n", SSH_USER_RC); @@ -2675,7 +2802,11 @@ mailbox = getenv("MAIL"); if (mailbox != NULL) { if (stat(mailbox, &mailstat) != 0 || mailstat.st_size == 0) +#ifdef __FreeBSD__ + ; +#else /* !__FreeBSD__ */ printf("No mail.\n"); +#endif /* __FreeBSD__ */ else if (mailstat.st_mtime < mailstat.st_atime) printf("You have mail.\n"); else -- Andrey A. Chernov http://nagual.pp.ru/~ache/ To Unsubscribe: send mail to majordomo at FreeBSD.org with "unsubscribe freebsd-current" in the body of the message From gem at rellim.com Tue Feb 29 05:56:00 2000 From: gem at rellim.com (Gary E. Miller) Date: Mon, 28 Feb 2000 10:56:00 -0800 (PST) Subject: SSH & xauth (fwd) Message-ID: YO All! Have you guys been following the SSH discussion on Bugtraq lately? I like their idea the X forwarding should be OFF by default on the client. RGDS GARY --------------------------------------------------------------------------- Gary E. Miller Rellim 20340 Empire Ave, Suite E-3, Bend, OR 97701 gem at rellim.com Tel:+1(541)382-8588 Fax: +1(541)382-8676 ---------- Forwarded message ---------- Date: Fri, 25 Feb 2000 21:52:15 -0500 From: Robert Watson Reply-To: Robert Watson To: BUGTRAQ at SECURITYFOCUS.COM Subject: Re: SSH & xauth This is a very round-about way of observing that allowing X11 forwarding from a client to any untrusted server (by any means -- sshd, xauth, common accounts, poor file permissions, compromised kernel, etc, etc) with the current SSH clients results in security problems (which you observe). What's more curious is that in OpenSSH, which I observed some time ago, the default configuration is to enable X11 forwarding in the client and disable it in the server. This is, of course, backwards, as the client is the one accepting risk by forwarding X11, not the server. :-) If you search back a few years in the bugtraq archives, you'll see that one suggestion for dealing with this, and still allowing X11 forwarding from untrusted clients, is to use the Xnest server, limiting access by the ssh client to that DISPLAY. As I observed at the time, Xnest was probably not designed with this use in mind, and as such is probably ``breakable,'' meaning that a pursuaded party might be able to gain access to the proper display through exploiting weaknesses in the Xnest server. I have not audited the Xnest code to verify that this is or is not the case. I believe at the time, Alan Cox responded with information about using the Broadway extensions to limit access by specific applications to other X11 applications, the X event queue, etc. These messages were circa 1997, and should appear in bugtraq archives. Presumably the correct configuration is for clients to disable X11 by default, and only have it enabled specifically by the user via appropriate flags to ssh, or via the config file. You could imagine a more comprehensive interface to new host key adoption that also inquired as to a trust level for X11 forwarding using Broadway, etc. In this manner, the user could specify ``limited'' access that would be sandboxed, not allowing access to screen data, X event queue access, etc, ``full,'' or ``none.'' With a little imagination, you could even imagine it spawning an Xnest to generate a sandbox for remote access. I would conclude by observing that this is *very* old news--the only new news is that it has not yet been ``fixed.'' Of course, there's a decent argument that many consumers of SSH are the kind of people who also blindly accept new hostkeys without verifying fingerprints or using a PKI, so this kind of default won't help them at all, just causing frustration. :-) If you want another puzzling OpenSSH tidbit, it's that the CheckIP option is enabled by default in the base implementation. It has recently been turned off in the FreeBSD version for the following reason (which was rejected by OpenSSH developers shortly after OpenSSH was released). The CheckHostIP feature introduces automatic modification of the known hosts key file to include the IP address of the host after connecting by name. This option introduces unnecessary modifications of keying material entries, and can cause spurious keying errors following IP address changes, especially in a dynamic DNS/IP allocation environment. When a user requests a connection by-name, the key storage should be by-name, as SSH is not aware of whether or not the name/key binding is persistent. Presumably, just as the user is responsible for performing by-name key verification and management, the user should also be responsible for managing by-number key verification and management. This also causes management problems for hosts employing centralized ssh_known_hosts entries--SSH replicates the key from the central file into the user's personal key file using the IP address to index the key. If the IP of the host is a variable IP, putting the IP into the centralized file makes no sense, but SSH will take the liberty of?replicating the keying material unnecessarily. If a host key now changes, and the centralized file is updated to reflect it, SSH will now generate warnings as its spuriously replicated key no longer matches up. You can even imagine DNS-based spoofing causing some problems, if combined with IP spoofing, as ssh-by-ip to a spoofed host would not generate an unknown key warning, instead, it would connect with full trust. This attack is a little of a stretch on convenience for the attacker, but is feasible. The end conclusion is really that key introduction for key indexes (names, IPs) should only occur when specifically authorized by the user and following a fingerprint display, never automatically. Robert N M Watson robert at fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services On Thu, 24 Feb 2000, Brian Caswell wrote: > The default SSH configuration for SSH1 and SSH2 allow for remote > controlling of X sessions through X forwarding. > > All children of the SSH connection are able to tunnel X11 sessions > through the X tunnel to the client X11 session. This is accomplished > by running xauth upon logging in. > > If xauth is replaced on the server by a malicious program that does > both of the following: > - runs xauth, adding in the "correct" information allowing the > children of the session to tunnel X11 programs through the SSH > session > - runs xauth, adding in the "malicious" information, allowing a > malicious source to tunnel X11 programs through the SSH session. > > With the added data in .Xauthority, a malicious source can fully control > the client X session. The malicious source can then do most anything to > the X session, from logging keystrokes of the X session, to taking > screen captures, to typing in commands to open terminals. > > The only thing that is required for the client system to be compromised > is for the client to remotely log via ssh (with X11 forwarding enabled) > into a compromised server. > > Allowing X forwarding seems to be turned on by default in SSH1, SSH2, > and OpenSSH. > > To fix this "issue" add the following lines to the SSH client > configuration. ($HOME/.ssh/config or ssh_config) > > > Host * > ForwardX11 no > > > Discussions of security flaws within X11 have been going on for years. > The "issue" in SSH X11 forwarding is not new. SSH has added to the > security of X11, but by no means does the use of SSH secure X11. > > -- > Brian Caswell > If I could load the world into vi, the first command I would use is: > %s/Windows NT//gi From djm at mindrot.org Tue Feb 29 08:17:52 2000 From: djm at mindrot.org (Damien Miller) Date: Tue, 29 Feb 2000 08:17:52 +1100 (EST) Subject: SSH & xauth (fwd) In-Reply-To: Message-ID: On Mon, 28 Feb 2000, Gary E. Miller wrote: > YO All! > > Have you guys been following the SSH discussion on Bugtraq lately? > > I like their idea the X forwarding should be OFF by default on the > client. In the default config which ships with 1.2.2 it is. -d -- | "Bombay is 250ms from New York in the new world order" - Alan Cox | Damien Miller - http://www.mindrot.org/ | Email: djm at mindrot.org (home) -or- djm at ibs.com.au (work) From chrismcc at netus.com Tue Feb 29 12:58:16 2000 From: chrismcc at netus.com (Christopher McCrory) Date: Mon, 28 Feb 2000 17:58:16 -0800 Subject: openssh-1.2.2 with openssl-0.9.5 rsa problem Message-ID: <38BB27B8.40627717@netus.com> Hello... to openssh-unix-dev at mindrot.org cc djm at ibs.com.au devel platform: linux intel redhat 6.2beta http://violet.ibs.com.au/openssh/files/openssh-1.2.2.tar.gz from rpm at same. I am NOT subscribed to the openssh-unix-dev list. I ran into a problem using openssh-1.2.2 with openssl-0.9.5. With openssl 0.9.5 you can now compile shared libraries without idea, rc5 and rsa. openssl compiled with: ./config no-rc5 no-idea -DRSA_NULL results in libraries without rc5 and idea and (AFAIK) with the patented parts of rsa removed. compiled and installed this way openssh compiles and installs fine. When run there are errors though. specifically: rsa_public_encrypt() failed on the client side or rsa_private_decrypt() failed on the server side ------------------actual sample------------- ( squid is known working version from violet rpms, wednesday is new test version) [squid at chrismcc]$ slogin -v wednesday SSH Version OpenSSH-1.2.2, protocol version 1.5. Compiled with SSL. debug: Reading configuration data /etc/ssh/ssh_config debug: ssh_connect: getuid 114 geteuid 0 anon 0 debug: Connecting to wednesday.netus.com [209.95.208.9] port 22. debug: Allocated local port 621. debug: Connection established. debug: Remote protocol version 1.5, remote software version OpenSSH-1.2.2 debug: Waiting for server public key. debug: Received server public key (768 bits) and host key (1024 bits). debug: Host 'wednesday.netus.com' is known and matches the host key. debug: Encryption type: 3des debug: Sent encrypted session key. Connection closed by 209.95.208.9 debug: Calling cleanup 0x80560b0(0x0) user chrismcc Mon Feb 28 on squid in ~ ------------------------ server syslog says: Feb 28 17:02:04 wednesday sshd[15363]: fatal: rsa_private_decrypt() failed [squid at chrismcc]$ rpm -qa | grep openss openssh-1.2.2-1 openssh-askpass-1.2.2-1 openssh-clients-1.2.2-1 openssh-server-1.2.2-1 openssl-0.9.4-3 ( rpms are from violet ) ----another [wednesday at chrismcc]$ slogin wednesday rsa_public_encrypt() failed user chrismcc Mon Feb 28 on wednesday in ~ [wednesday at chrismcc]$ server says: Feb 28 17:05:19 wednesday sshd[17036]: Connection closed by 209.95.208.9 after looking at the openssh source code (I am not a programer though) it seems that an the keyexchange point if rsa fails it should, IMHO, fall through to dsa(?) or something else. -- Christopher McCrory Lead Bithead, Netus Inc. chrismcc at netus.com admin at netus.com "Linux: Because rebooting is for adding new hardware" From markus.friedl at informatik.uni-erlangen.de Tue Feb 29 19:22:48 2000 From: markus.friedl at informatik.uni-erlangen.de (Markus Friedl) Date: Tue, 29 Feb 2000 09:22:48 +0100 Subject: openssh-1.2.2 with openssl-0.9.5 rsa problem In-Reply-To: <38BB27B8.40627717@netus.com>; from chrismcc@netus.com on Mon, Feb 28, 2000 at 05:58:16PM -0800 References: <38BB27B8.40627717@netus.com> Message-ID: <20000229092248.A15550@folly.informatik.uni-erlangen.de> On Mon, Feb 28, 2000 at 05:58:16PM -0800, Christopher McCrory wrote: > after looking at the openssh source code (I am not a programer though) > it seems that an the keyexchange point if rsa fails it should, IMHO, > fall through to dsa(?) or something else. no. for OpenSSH-1.2.2 you need RSA in openssl. version 2 of the SSH protocol supports DSA, but OpenSSH-1.2.2 implements SSH1 only.