From swhatley at hal-pc.org Fri Aug 1 05:02:50 2003 From: swhatley at hal-pc.org (swhatley at hal-pc.org) Date: Thu, 31 Jul 2003 14:02:50 -0500 Subject: sshd takes 15 minutes to start Message-ID: Hi all, We are running OpenSSH v3.4p1 on three ES340 Alpha which run Tru64 v5.1A. The last couple of weeks, the system hangs at bootup for 15 minutes at the point where it is bring up sshd. When I manually stop and start sshd, it still takes 15 minutes. I manually ran sshd with the -ddd level 3 debug option. sshd hanges at the message which states it is creating a randomized seed. It also tkaes 15 minutes to run ssh_keygen. The only tings we have done lately is to upgrad the ES40's firmware in preporation to going to Tru64 5.1B. We have also added gigabit NICs to set up a private netowrk for use of NIS, NFS, and other intranetwork traffic. I have tried compiling OpenSSH v3.6.1p2 with the same results. OpenSSH was compiled with GCC v3.3. We are also running OpenSSL v0.6.9g and zlib v1.4. Does anyone here have any ideas what could be going on? Any info will be appreciated. Thanks, Steven -- ___ ____________ <<<((__O\ (__<>___<>__ \ ____ Don't get rattled by Steven Whatley \ \_(__<>___<>__)\O\_/O___>-< what I say. It's just swhatley at hal-pc.org \O__<>___<>___<>)\___/ my opinion. From mdione at grulic.org.ar Fri Aug 1 05:30:51 2003 From: mdione at grulic.org.ar (Marcos Dione) Date: Thu, 31 Jul 2003 16:30:51 -0300 Subject: smtp over ssh probs Message-ID: <20030731193051.GA8662@grulic.org.ar> before I start, two notes. I alredy sent this mail to the other mailing list, but no answer has came back. also, I'm not subscribed to this list, so please cc me the answers. now, to business. I have a problem but I don't know exactly what. Or why, better. The scheme is like this: I don't have a direct connection to the inet, except for ssh to certain range of ip's at a non-standar port (2222). This weird setup is due to the IT dept, so there is no other way for me now. So I try to use ssh as a tunnel to my machine @ home, where I can use any service I want, like smtp, imap, jabber and irc. The way I do it is like this: first, set empty passphrase key-pairs and put the public one on the authorized_keys on the other side (my home machine) so I can ssh w/ no passwd/passphrase questions. then I add a line like this: 8000 stream tcp nowait mdione.mdione /usr/bin/ssh ssh -T -C -p 2222 -i /home/mdione/.ssh/id_rsa vialibre.dyndns.org socket jabber.vialibre.org.ar 5222 [****] to the /etc/inetd.conf. basically makes it listen on port 8000 in the work's machine, and when sdome connection comes, it fires a ssh in my name to my home machine (vialibre.dyndns.og) w/ port 222 and compression. there the sshd will launch a socket connection to the port 5222 of jabber.vialibre.org.ar. this way, I point my jabber client to this machine's port 8000 and voila', I have jabber. what's impressive is that it *works*. then I have similar lines for imap, irc and smtp. but, the imap and the smtp ones don't work correctly. I don't know why, but seems like the data gets stuck somewhere. more precisely: in the work's machine I have set up a masqmail, which is a simple smtp server. its conf says to use localhost:8002 as smarthost, and in inted.conf I have: 8002 stream tcp nowait mdione.mdione /usr/bin/ssh ssh -T -e none -p 2222 -i /home/mdione/.ssh/id_rsa vialibre.dyndns.org socket carmen smtp carmen is another machine @ home that is the smtp server. if I telnet to localhost:8002, I get carmen's answer. fine. also, note that I tried disabling compression and disabling escape characters. then, if I use muut to send mails, and send a little one [*], the mails gets queued in the local masqmail, and then when masqmail flushes the queue, the connections are made. using strace at several stages, I realize the masqmail sends the data correctly, but carmen's smtp server does not get all of it. seems silly, but I don't know *what* could be the problem. I can see the data flowing thru inetd, thru local ssh client, thru other side's socket, and the data reaching carmen's stmp server. and I see that masqmails starts sendind the mail's data (if you know smtp, well, it sends the 'DATA' command and then the actual data with the line w/ only a period on it), the data seems[**] to go thru the local ssh client, but doesn't seem to reach the socket on the other side. and as data doesn't seem to reach the smtp @ carmen, it kicks me out saying that it timeout'ed, but in smtp ('421 carmen.fsl.org.ar SMTP incoming data timeout - closing connection.') and the carmen closes the socket. even more strange, if I 'just' do: ssh -C -L 8002:carmen:25 -p 2222 vialibre.dyndns.org and then I flush the masqmail's queue, it works![***] the problem w/ this way, and yes, it's only a matter of confort, is that I have to setup the tunnel manually, and that when my home machine's ip change (I don't have a fixed ip, that's why I use dyndns), the connections go down and I have to restablish them by hand. I also know that I could make some scripts to circumvent that, but I feel the inetd solution clean and, once set up, very transparent. does anyone have any clue? local ssh is 'OpenSSH_3.6.1p2 Debian 1:3.6.1p2-2, SSH protocols 1.5/2.0, OpenSSL 0x0090702f' (debian/testing) and remote's is 'OpenSSH_3.4p1 Debian 1:3.4p1-1, SSH protocols 1.5/2.0, OpenSSL 0x0090603f' (debian/stable). thanks in advance. [*] the definition of 'little one' seems to be 'less than 2k'. [**] I say seems 'cause I see the data reaching the ssh's stdin and some encripted data going thru the outgoing socket, but as long as it's encripted I can't see if it's the right data or not. (these notes where not in the original post) [***] further testing shows that some mails still have problems.I also added the -q option, and I even can do https over this kind of tunnels. [****] I realize that as the ssh is running as mdione, I don't need the -i option. PS: someone pointed to me that there's (or was) a bug w/ the KeepAlive option that could be biting me, buy I think not, as I don't need KeepAlive connections. I mention it just to add meme to the problem. -- #! /bin/bash echo mdione@{{grulic,vialibre}.org.ar,hal.famaf.unc.edu}.ar -- well-designed technology should allow people the luxury of ignorance -- Eric S. Raymond From dtucker at zip.com.au Fri Aug 1 09:45:34 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 01 Aug 2003 09:45:34 +1000 Subject: sshd takes 15 minutes to start References: Message-ID: <3F29AA1E.8623779E@zip.com.au> swhatley at hal-pc.org wrote: > We are running OpenSSH v3.4p1 on three ES340 Alpha which run Tru64 v5.1A. > The last couple of weeks, the system hangs at bootup for 15 minutes at the > point where it is bring up sshd. When I manually stop and start sshd, it still > takes 15 minutes. I manually ran sshd with the -ddd level 3 debug option. > sshd hanges at the message which states it is creating a randomized seed. It > also tkaes 15 minutes to run ssh_keygen. It sounds like one of the processes run by ssh-rand-helper is now hanging for some reason. This will most likely be one of the binaries replaced in your upgrade. The random helper is supposed to time out any command that takes too long (>100 ms from memory) but there was a problem in earlier versions of OpenSSH on some platforms where that did not occur. To identify the command that's hanging, run ssh-rand-helper on its own with a "-vv" argument. You will be able to see each command as it's run and identify the one that's hanging. Once you've found it (or them), comment those commands out of ssh_prngs_cmds. Upgrading sshd will also resolve the problem as the timeout bug has been fixed. -- 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 swhatley at hal-pc.org Fri Aug 1 13:34:18 2003 From: swhatley at hal-pc.org (Steven Whatley) Date: Thu, 31 Jul 2003 22:34:18 -0500 (CDT) Subject: [openssh] Re: sshd takes 15 minutes to start In-Reply-To: <3F29AA1E.8623779E@zip.com.au> References: <3F29AA1E.8623779E@zip.com.au> Message-ID: On Fri, 1 Aug 2003, Darren Tucker wrote: > swhatley at hal-pc.org wrote: > > We are running OpenSSH v3.4p1 on three ES340 Alpha which run Tru64 v5.1A. > > The last couple of weeks, the system hangs at bootup for 15 minutes at the > > point where it is bring up sshd. When I manually stop and start sshd, it still > > takes 15 minutes. I manually ran sshd with the -ddd level 3 debug option. > > sshd hanges at the message which states it is creating a randomized seed. It > > also tkaes 15 minutes to run ssh_keygen. > > It sounds like one of the processes run by ssh-rand-helper is now hanging > for some reason. This will most likely be one of the binaries replaced in > your upgrade. Found the problem. ssh-rand-helper was getting stuck on calling the ssh_prng_cmds line 'netstat -ia'. The netstat command has been locking up since we installed additional gigabit NICs to set up a private network for intranet traffic such as NIS, NFS, etc. By using the -vvv option, I did see that ssh-rand-helper did time-out on the previous 3 netstat calls but could not get past the 'netstat -ia' call until it timed out 15 minutes later. This still happened with OpenSSH v3.6.1p2. BTW, great product! Thanks! Steven From dtucker at zip.com.au Fri Aug 1 13:58:34 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 01 Aug 2003 13:58:34 +1000 Subject: [openssh] Re: sshd takes 15 minutes to start References: <3F29AA1E.8623779E@zip.com.au> Message-ID: <3F29E56A.7F6B36B2@zip.com.au> Steven Whatley wrote: > Found the problem. ssh-rand-helper was getting stuck on calling the > ssh_prng_cmds line 'netstat -ia'. The netstat command has been locking up > since we installed additional gigabit NICs to set up a private network for > intranet traffic such as NIS, NFS, etc. By using the -vvv option, I did > see that ssh-rand-helper did time-out on the previous 3 netstat calls but > could not get past the 'netstat -ia' call until it timed out 15 minutes > later. This still happened with OpenSSH v3.6.1p2. If netstat is ignoring SIGTERM or getting stuck in a syscall then ssh-rand-helper will not be able to kill it (and if it's the latter then nothing will help). You can verify that by running "netstat -ia" in one session then trying to kill it (first with -TERM, then with -KILL) from another session. I suspect neither will work. I don't know if ssh-rand-helper can do anything sane about this.... possibly set a timeout for a few seconds, kill -9 the errant command, then abandon it and let init clean it up if it exits? Comments/suggestions anyone? -- 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 stuge-openssh-unix-dev at cdy.org Sun Aug 3 05:29:03 2003 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sat, 2 Aug 2003 21:29:03 +0200 Subject: [openssh] Re: sshd takes 15 minutes to start In-Reply-To: <3F29E56A.7F6B36B2@zip.com.au> References: <3F29AA1E.8623779E@zip.com.au> <3F29E56A.7F6B36B2@zip.com.au> Message-ID: <20030802192903.GA10893@foo.birdnet.se> On Fri, Aug 01, 2003 at 01:58:34PM +1000, Darren Tucker wrote: > I don't know if ssh-rand-helper can do anything sane about this.... > possibly set a timeout for a few seconds, kill -9 the errant command, then > abandon it and let init clean it up if it exits? Comments/suggestions > anyone? This is a good idea. In order to catch this problem, I know I would want a notice of some sort. Otherwise it might lead to a lot of defunct processes that suddenly show up out of nowhere. (Or after a major update, when many things have changed at once..) An option to leaving the process to init is to fork() ssh-rand-helper to show more clearly what's going on, but the log or stderr message is now even more important, since this will obviously use up twice as many PIDs. The latter will probably result in more emails to the list too, unless the error message is good and very visible. I was thinking of doing something with resource limits to get kernel help, but the kernel doesn't always know about real time life of processes, and I don't expect the interface to be very well standardized either, so scratch that. //Peter From mouring at etoh.eviladmin.org Sun Aug 3 06:53:22 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sat, 2 Aug 2003 15:53:22 -0500 (CDT) Subject: [openssh] Re: sshd takes 15 minutes to start In-Reply-To: <20030802192903.GA10893@foo.birdnet.se> Message-ID: On Sat, 2 Aug 2003, Peter Stuge wrote: > On Fri, Aug 01, 2003 at 01:58:34PM +1000, Darren Tucker wrote: > > I don't know if ssh-rand-helper can do anything sane about this.... > > possibly set a timeout for a few seconds, kill -9 the errant command, then > > abandon it and let init clean it up if it exits? Comments/suggestions > > anyone? > > This is a good idea. kill -9ing may not be a bad idea for things that don't honor "please shut down now", but I don't like the idea of abandoning the child process. If an OS company is not coding things to be signal safe and it now becomes a zombie it may be out there until a reboot at worse. Quietly filling up the pid table. I'd be more concern about older UNIXes lacking a /dev/random to start with since coding quality for race conditions was.. well.. =) Not always on par. > In order to catch this problem, I know I would want a notice of some sort. > Otherwise it might lead to a lot of defunct processes that suddenly show up > out of nowhere. > (Or after a major update, when many things have changed at once..) > Agreed. However, keep in mind ssh-rand-helper was designed as a stop-gap measure. You really should be looking for a /dev/random kernel module or a longer standing entropy process like prngd. > An option to leaving the process to init is to fork() ssh-rand-helper to > show more clearly what's going on, but the log or stderr message is now even > more important, since this will obviously use up twice as many PIDs. > [..] >From here below I'm not following what your saying. - Ben From stuge-openssh-unix-dev at cdy.org Sun Aug 3 07:13:32 2003 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sat, 2 Aug 2003 23:13:32 +0200 Subject: [openssh] Re: sshd takes 15 minutes to start In-Reply-To: References: <20030802192903.GA10893@foo.birdnet.se> Message-ID: <20030802211332.GD10893@foo.birdnet.se> On Sat, Aug 02, 2003 at 03:53:22PM -0500, Ben Lindstrom wrote: > On Sat, 2 Aug 2003, Peter Stuge wrote: > > On Fri, Aug 01, 2003 at 01:58:34PM +1000, Darren Tucker wrote: > > > I don't know if ssh-rand-helper can do anything sane about this.... > > > possibly set a timeout for a few seconds, kill -9 the errant command, > > > then abandon it and let init clean it up if it exits? > > > Comments/suggestions anyone? > > > > This is a good idea. > > kill -9ing may not be a bad idea for things that don't honor "please shut > down now", but I don't like the idea of abandoning the child process. An alternative to that and the current hanging is to fork(), but maybe it's just best to leave it as is, see below. > If an OS company is not coding things to be signal safe and it now becomes > a zombie it may be out there until a reboot at worse. Quietly filling up > the pid table. Yes, this is really bad. Could the netstat process be expected to disappear if the parent process exits, or would it still be left? (Kill the shell in Darren's suggested test..) > I'd be more concern about older UNIXes lacking a /dev/random to start with > since coding quality for race conditions was.. well.. =) Not always on > par. > > > In order to catch this problem, I know I would want a notice of some sort. > > Otherwise it might lead to a lot of defunct processes that suddenly show up > > out of nowhere. > > (Or after a major update, when many things have changed at once..) > > Agreed. However, keep in mind ssh-rand-helper was designed as a stop-gap > measure. You really should be looking for a /dev/random kernel module or > a longer standing entropy process like prngd. Well, do people seem to do this? Myself, I have /dev/random, and would indeed get prngd otherwise. Maybe the question is how easy we want life with ssh-rand-helper to be? > > An option to leaving the process to init is to fork() ssh-rand-helper to > > show more clearly what's going on, but the log or stderr message is now even > > more important, since this will obviously use up twice as many PIDs. > > > [..] > > >From here below I'm not following what your saying. Sorry, I should've been more clear. OTOH, it was just wishful thinking. I was thinking that the kernel has ultimate ability to clean up processes, and that a usage limit set by ssh-rand-helper could be one way to use that ability. Not all kernels (any?) keep track of/have limits for real time though, only CPU time, so it doesn't work. And at least Linux sends SIGKILL when the hard CPU time limit is reached, that's another reason it doesn't work, although I'd hope that the kernel would really be able to remove a process when it wants to. Admittedly, I lack some pieces of the kernel/user puzzle, though. //Peter From stuge-openssh-unix-dev at cdy.org Sun Aug 3 07:26:03 2003 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sat, 2 Aug 2003 23:26:03 +0200 Subject: smtp over ssh probs In-Reply-To: <20030731193051.GA8662@grulic.org.ar> References: <20030731193051.GA8662@grulic.org.ar> Message-ID: <20030802212603.GE10893@foo.birdnet.se> On Thu, Jul 31, 2003 at 04:30:51PM -0300, Marcos Dione wrote: [..] > passwd/passphrase questions. then I add a line like this: > > 8000 stream tcp nowait mdione.mdione /usr/bin/ssh ssh -T -C -p 2222 -i \ > /home/mdione/.ssh/id_rsa vialibre.dyndns.org socket \ > jabber.vialibre.org.ar 5222 [****] > > to the /etc/inetd.conf. [..] > even more strange, if I 'just' do: > > ssh -C -L 8002:carmen:25 -p 2222 vialibre.dyndns.org > > and then I flush the masqmail's queue, it works![***] the problem w/ inetd isn't very good, for many reasons more or less relevant in a corporate network protected from the internet by an IT department. You've figured out a solution that works, my suggestion is that you stick with it and try to improve usability. Keep in mind that you can enable multiple port forwards with one ssh command. This will hopefully also make you set a passphrase on your key, so that anyone with access to your work storage do not automatically have access to your home system. For keeping services running permanently with much more control over things than possible with init, I heartily recommend DJB's supervise and friends. See http://cr.yp.to/daemontools.html //Peter From bijken at email.com Sun Aug 3 11:14:46 2003 From: bijken at email.com (bijken at email.com) Date: Sat, 2 Aug 2003 21:14:46 -0400 Subject: Outlook Message-ID: <20030803011351.BB48D27C188@shitei.mindrot.org> hmm, okay so you want to save some money. take a look.. not only that but you just owe it to yourself and your family, I hope your ready for lower mortgage repayments! http://r.aol.com/cgi/redir-complex?url=http://43289122 at buynow3sx.com/viewso65/index.asp?RefID=198478 From dtucker at zip.com.au Sun Aug 3 15:13:12 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 03 Aug 2003 15:13:12 +1000 Subject: [openssh] Re: sshd takes 15 minutes to start References: Message-ID: <3F2C99E8.EEF9C898@zip.com.au> Ben Lindstrom wrote: [about kill -9'ing hung rand helper subprocesses] > kill -9ing may not be a bad idea for things that don't honor "please shut > down now", but I don't like the idea of abandoning the child process. If it didn't respond to kill -9 then you're stuck with it no matter what you do, the only options you have are waiting (possibly forever) for it or abandoning it. > If an OS company is not coding things to be signal safe and it now becomes > a zombie it may be out there until a reboot at worse. Quietly filling up > the pid table. Are there platforms where init doesn't wait() for orphans? The biggest concern I have is that ssh-random-helper currently has a failure mode that will render a machine inaccessible via ssh (or worse, will prevent a it from booting properly). I'm thinking that ssh-rand-helper should wait, say, 10 seconds then kill -9 the subprocess, wait() for another couple of seconds then log it as a problem and abandon it. The delay and log will mean that it should be obvious there's a problem, but it will work eventually. At the moment there is no such guarantee. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Sun Aug 3 15:23:20 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 03 Aug 2003 15:23:20 +1000 Subject: [openssh] Re: [openssh] Re: sshd takes 15 minutes to start References: <3F29AA1E.8623779E@zip.com.au> <3F29E56A.7F6B36B2@zip.com.au> Message-ID: <3F2C9C48.989F4154@zip.com.au> Steven Whatley wrote: [snip detail] > Does any of this make any sense? Yes. Some of the netstats take a while but can be timed out by the random helper (which uses SIGINT, not SIGTERM as I previously said) but the one that hangs and can't be interrupted is netstat -ia ("Displays the state of configured interfaces") which means it's probably hung in an ioctl syscall and can't be interrupted even with a SIGKILL. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Sun Aug 3 19:15:19 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 03 Aug 2003 19:15:19 +1000 Subject: [PATCH] Fix minor breakage on Cygwin: auth-passwd.c and session.c Message-ID: <3F2CD2A7.14BEF5A4@zip.com.au> Hi All. I tried building -current on Cygwin but got a couple of minor errors. The first is in auth-passwd.c where it appears Ben got a bit over-enthusiastic cleaning up :-). The patch restores the relevant "#ifdef HAVE_CYGWIN" fragment. The second is in the send-break code in session.c, which won't compile because Cygwin apparently doesn't have TIOCSBRK and TIOCCBRK ioctls. With the patch session_break_req just returns 0 if TIOCSBRK and TIOCCBRK are not defined (which I think is the right thing to do, but I'm not sure). If either of these are wrong please let me know. -- 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 -------------- Index: auth-passwd.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth-passwd.c,v retrieving revision 1.58 diff -u -r1.58 auth-passwd.c --- auth-passwd.c 2 Aug 2003 12:24:49 -0000 1.58 +++ auth-passwd.c 2 Aug 2003 14:54:06 -0000 @@ -43,6 +43,14 @@ #include "servconf.h" #include "auth.h" #include "openbsd-compat/xcrypt.h" + +# ifdef HAVE_CYGWIN +# undef ERROR +# include +# include +# define is_winnt (GetVersion() < 0x80000000) +# endif + #ifdef WITH_AIXAUTHENTICATE # include "buffer.h" # include "canohost.h" Index: session.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/session.c,v retrieving revision 1.242 diff -u -r1.242 session.c --- session.c 2 Aug 2003 12:24:50 -0000 1.242 +++ session.c 2 Aug 2003 15:14:18 -0000 @@ -1702,6 +1702,7 @@ break_length = packet_get_int(); packet_check_eom(); +#if defined(TIOCSBRK) && defined(TIOCCBRK) if (s->ttyfd == -1) return 0; /* we will sleep from 500ms to 3000ms */ @@ -1712,6 +1713,9 @@ usleep(break_length * 1000); ioctl(s->ttyfd, TIOCCBRK, NULL); return 1; +#else + return 0; +#endif } static int From mouring at etoh.eviladmin.org Mon Aug 4 04:35:13 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Sun, 3 Aug 2003 13:35:13 -0500 (CDT) Subject: [PATCH] Fix minor breakage on Cygwin: auth-passwd.c and session.c In-Reply-To: <3F2CD2A7.14BEF5A4@zip.com.au> Message-ID: [..] +# ifdef HAVE_CYGWIN +# undef ERROR +# include +# include +# define is_winnt (GetVersion() < 0x80000000) +# endif There is enough of this junk laying around in different files it really should be put in an openbsd-compat/port-cygwin.h =) - Ven On Sun, 3 Aug 2003, Darren Tucker wrote: > Hi All. > I tried building -current on Cygwin but got a couple of minor errors. > The first is in auth-passwd.c where it appears Ben got a bit > over-enthusiastic cleaning up :-). The patch restores the relevant > "#ifdef HAVE_CYGWIN" fragment. > > The second is in the send-break code in session.c, which won't compile > because Cygwin apparently doesn't have TIOCSBRK and TIOCCBRK ioctls. With > the patch session_break_req just returns 0 if TIOCSBRK and TIOCCBRK are > not defined (which I think is the right thing to do, but I'm not sure). > > If either of these are wrong please let me know. > > -- > Darren Tucker (dtucker at zip.com.au) > GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 > Good judgement comes with experience. Unfortunately, the experience > usually comes from bad judgement. From dtucker at zip.com.au Mon Aug 4 11:44:43 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 04 Aug 2003 11:44:43 +1000 Subject: [PATCH] Fix minor breakage on Cygwin: auth-passwd.c and session.c References: Message-ID: <3F2DBA8B.109D7A1F@zip.com.au> Ben Lindstrom wrote: > [..] > +# ifdef HAVE_CYGWIN > +# undef ERROR > +# include > +# include > +# define is_winnt (GetVersion() < 0x80000000) > +# endif > > There is enough of this junk laying around in different files it really > should be put in an openbsd-compat/port-cygwin.h =) Good point, doing that works too. Did you really mean a new "port-cygwin.h" or the existing "bsd-cygwin_util.h"? The first "#ifdef CYGWIN" block in session.c could go too. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From mouring at etoh.eviladmin.org Mon Aug 4 15:32:36 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 4 Aug 2003 00:32:36 -0500 (CDT) Subject: [PATCH] Fix minor breakage on Cygwin: auth-passwd.c and session.c In-Reply-To: <3F2DBA8B.109D7A1F@zip.com.au> Message-ID: On Mon, 4 Aug 2003, Darren Tucker wrote: > Ben Lindstrom wrote: > > [..] > > +# ifdef HAVE_CYGWIN > > +# undef ERROR > > +# include > > +# include > > +# define is_winnt (GetVersion() < 0x80000000) > > +# endif > > > > There is enough of this junk laying around in different files it really > > should be put in an openbsd-compat/port-cygwin.h =) > > Good point, doing that works too. Did you really mean a new > "port-cygwin.h" or the existing "bsd-cygwin_util.h"? > Sooner or later bsd-cygwin_util.[ch], bsd-cray.[ch] and bsd-nextstep.[ch] should be changed to port-cygwin.[ch], port-cray.[ch] and port-nextstep.[ch] respectively. However, yes. The code should go to bsd-cygwin_util.h unless there is some overriding reason not to... Corinna is there a reason we shouldn't make this change? - Ben From dtucker at zip.com.au Tue Aug 5 20:23:00 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 05 Aug 2003 20:23:00 +1000 Subject: [PATCH] Fix minor breakage on Cygwin: auth-passwd.c and session.c References: Message-ID: <3F2F8584.401C1213@zip.com.au> Ben Lindstrom wrote: > However, yes. The code should go to bsd-cygwin_util.h unless there is > some overriding reason not to... Corinna is there a reason we shouldn't > make this change? Here's the current proposed patch, which works for me. No one has commented on the session_break_req() change... -- 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 -------------- Index: session.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/session.c,v retrieving revision 1.242 diff -u -r1.242 session.c --- session.c 2 Aug 2003 12:24:50 -0000 1.242 +++ session.c 4 Aug 2003 00:48:47 -0000 @@ -58,12 +58,6 @@ #include "session.h" #include "monitor_wrap.h" -#ifdef HAVE_CYGWIN -#include -#include -#define is_winnt (GetVersion() < 0x80000000) -#endif - /* func */ Session *session_new(void); @@ -1702,6 +1696,7 @@ break_length = packet_get_int(); packet_check_eom(); +#if defined(TIOCSBRK) && defined(TIOCCBRK) if (s->ttyfd == -1) return 0; /* we will sleep from 500ms to 3000ms */ @@ -1712,6 +1707,9 @@ usleep(break_length * 1000); ioctl(s->ttyfd, TIOCCBRK, NULL); return 1; +#else + return 0; +#endif } static int Index: openbsd-compat/bsd-cygwin_util.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/bsd-cygwin_util.h,v retrieving revision 1.8 diff -u -r1.8 bsd-cygwin_util.h --- openbsd-compat/bsd-cygwin_util.h 18 May 2003 14:13:39 -0000 1.8 +++ openbsd-compat/bsd-cygwin_util.h 4 Aug 2003 11:20:02 -0000 @@ -36,6 +36,11 @@ #ifdef HAVE_CYGWIN +#undef ERROR +#define is_winnt (GetVersion() < 0x80000000) + +#include +#include #include int binary_open(const char *, int , ...); From ymnk at jcraft.com Wed Aug 6 16:43:55 2003 From: ymnk at jcraft.com (Atsuhiko Yamanaka) Date: Wed, 6 Aug 2003 15:43:55 +0900 Subject: 'cancel-tcpip-forward' is not supported. Message-ID: <200308060643.PAA00978@jcraft.com> Hi there, I'm developing ssh client in pure java and, recently, I'm trying to improve the port forwarding support on that stuff. However, it seems to me that sshd of OpenSSH has not supported 'cancel-tcpip-forward' request. http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-17.txt says that | A port forwarding can be cancelled with the following message. | Note that channel open requests may be received until a reply to | this message is received. | | byte SSH_MSG_GLOBAL_REQUEST | string "cancel-tcpip-forward" | boolean want reply | string address_to_bind (e.g. "127.0.0.1") | uint32 port number to bind Is there a plan to support that request? Without that, ssh clients can not cancel '-R' port forwardings dynamically. Thanks, -- ymnk From chkbrian at hongkong.com Wed Aug 6 17:16:27 2003 From: chkbrian at hongkong.com (chkbrian) Date: Wed, 06 Aug 2003 15:16:27 +0800 (CST) Subject: ssh_exchange_identification: Connection closed by remote host Message-ID: <1060154187.5168.chkbrian@hongkong.com> Hello, I encountered the following problem while I typing "ssh -v " " hkmarmmspd:/export/home/hkcheung> ssh -v hkmauat OpenSSH_3.6.1p1, SSH protocols 1.5/2.0, OpenSSL 0x0090701f debug1: Reading configuration data /usr/local/etc/ssh_config debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: Connecting to hkmauat [172.28.68.52] port 22. debug1: Connection established. debug1: identity file /export/home/hkcheung/.ssh/identity type -1 debug1: identity file /export/home/hkcheung/.ssh/id_rsa type -1 debug1: identity file /export/home/hkcheung/.ssh/id_dsa type -1 ssh_exchange_identification: Connection closed by remote host debug1: Calling cleanup 0x2c95c(0x0) hkmarmmspd:/export/home/hkcheung> ". Strangly, sometime the problem is not occurred. Can someone give me some advices. Thanks! From dtucker at zip.com.au Wed Aug 6 17:33:44 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 06 Aug 2003 17:33:44 +1000 Subject: ssh_exchange_identification: Connection closed by remote host References: <1060154187.5168.chkbrian@hongkong.com> Message-ID: <3F30AF58.78CD877B@zip.com.au> chkbrian wrote: > I encountered the following problem while I typing "ssh -v " [snip] > ssh_exchange_identification: Connection closed by remote host You should specify your platform and OpenSSH version, but this is almost certainly due to tcpwrappers configuration. Add the following line to hosts.allow: sshd: ALL It may be in /etc or /usr/local/etc. Alternatively you could rebuild sshd without "--with-tcp-wrappers". -- 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 dan at doxpara.com Wed Aug 6 18:45:32 2003 From: dan at doxpara.com (Dan Kaminsky) Date: Wed, 06 Aug 2003 01:45:32 -0700 Subject: 'cancel-tcpip-forward' is not supported. In-Reply-To: <200308060643.PAA00978@jcraft.com> References: <200308060643.PAA00978@jcraft.com> Message-ID: <3F30C02C.8010609@doxpara.com> >Is there a plan to support that request? Without that, >ssh clients can not cancel '-R' port forwardings dynamically. > > Atsuhiko-- Back in the SSHv1 days, common ssh daemons couldn't declare remote port forwards after a shell was opened. I never checked what happened with SSHv2; it sounds like we allow on-demand opens but not closes...guys, what do you think? It's in the spec, and it's pretty clearly a useful feature... --Dan From markus at openbsd.org Wed Aug 6 19:22:56 2003 From: markus at openbsd.org (Markus Friedl) Date: Wed, 6 Aug 2003 11:22:56 +0200 Subject: 'cancel-tcpip-forward' is not supported. In-Reply-To: <200308060643.PAA00978@jcraft.com> References: <200308060643.PAA00978@jcraft.com> Message-ID: <20030806092256.GA28062@folly> our client does not support it, so our server does not, but you can send patches. On Wed, Aug 06, 2003 at 03:43:55PM +0900, Atsuhiko Yamanaka wrote: > Hi there, > > I'm developing ssh client in pure java and, recently, I'm trying > to improve the port forwarding support on that stuff. > > However, it seems to me that sshd of OpenSSH has not supported > 'cancel-tcpip-forward' request. > > http://www.ietf.org/internet-drafts/draft-ietf-secsh-connect-17.txt > says that > > | A port forwarding can be cancelled with the following message. > | Note that channel open requests may be received until a reply to > | this message is received. > | > | byte SSH_MSG_GLOBAL_REQUEST > | string "cancel-tcpip-forward" > | boolean want reply > | string address_to_bind (e.g. "127.0.0.1") > | uint32 port number to bind > > Is there a plan to support that request? Without that, > ssh clients can not cancel '-R' port forwardings dynamically. > > > Thanks, > -- > ymnk > > _______________________________________________ > 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 Thu Aug 7 01:44:42 2003 From: markus at openbsd.org (Markus Friedl) Date: Wed, 6 Aug 2003 17:44:42 +0200 Subject: sftp (fwd) Message-ID: <20030806154441.GA32320@folly> -------------- next part -------------- An embedded message was scrubbed... From: Omayle.Rondon at movilnet.com.ve Subject: sftp Date: Tue, 5 Aug 2003 18:01:47 -0400 Size: 3494 Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030806/50dbdc11/attachment.mht -------------- next part -------------- An embedded message was scrubbed... From: Omayle.Rondon at movilnet.com.ve Subject: sftp Date: Wed, 6 Aug 2003 07:58:06 -0400 Size: 3526 Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030806/50dbdc11/attachment-0001.mht From shashank at mia.ece.uic.edu Thu Aug 7 03:09:05 2003 From: shashank at mia.ece.uic.edu (Shashank Khanvilkar) Date: Wed, 6 Aug 2003 12:09:05 -0500 (CDT) Subject: Reg. openssh-3.51p1/packet.c (function packet_send2()) Message-ID: Hi, Will really appreciate for any comments on the below: 1. According to draft-ietf-secsh-transport-16.txt (section 4), each packet must be of the following format: uint32 packet_length byte padding_length byte[n1] payload; n1 = packet_length - padding_length - 1 byte[n2] random padding; n2 = padding_length byte[m] mac (message authentication code); m = mac_length However, since i wanted to verify this, I put some debugging code in openssh-3.51p1/packet.c (function packet_send2()), which can be accessed at http://mia.ece.uic.edu/cgi-bin/lxr/http/source/packet.c?v=openssh-3.5p1#L619. I conducted some tests by sending PPP packets and found out that the tranport layer (i think) just appends an extra 14 bytes to the begining of the PPP frame. The first 4 bytes of these are used to put in the packet_length and the next 1 byte is used to put in the padding_length. However the rest 9 bytes remain unused.. Question: 1. Is this observation correct? Or am i missiing a point here. 2. If it is correct, then is there a new ietf draft that reflects this change. 3. Any comments are welcome. Thanks shashank Below is an example output: 1. The PPP frame (len = 136) in the below example starts and ends on character "0x7e". (No character stuffing is in effect). You can see that the packet is appended with the first 14 bytes. plain: 0000 0000 005e 0000 0000 0000 0088 7eff 0300 2145 0000 8000 0040 0040 11bb 89c0 a8fe c8c0 a8fe c994 7194 7000 6cf5 4000 0000 02c6 2e31 3f11 4d07 0053 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 53c6 8c7e 2. To calculate padding bytes, the code uses the length of the above packet (i.e. 136 + 14 = 150) and calculates (8 - (150 % 8) = 2). Since this is less than 4 bytes, it adds another 8 bytes of padding to allow 10 bytes of pading. 2. The packet length is correctly calculated as 0x9c (=156), and the padding length is correctly calculated as 0x0a (=10) in the below output. send: len 160 (includes padlen 10) 0000 009c 0a5e 0000 0000 0000 0088 7eff 0300 2145 0000 8000 0040 0040 11bb 89c0 a8fe c8c0 a8fe c994 7194 7000 6cf5 4000 0000 02c6 2e31 3f11 4d07 0053 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 5353 53c6 8c7e 7e24 ef79 f0fe 1a95 a450 From markus at openbsd.org Thu Aug 7 07:20:08 2003 From: markus at openbsd.org (Markus Friedl) Date: Wed, 6 Aug 2003 23:20:08 +0200 Subject: Reg. openssh-3.51p1/packet.c (function packet_send2()) In-Reply-To: References: Message-ID: <20030806212008.GA5101@folly> hi, what is all this ppp talk about? why don't you just recompile packet.c with PACKET_DEBUG? what exactly is the problem? From shashank at mia.ece.uic.edu Thu Aug 7 09:16:17 2003 From: shashank at mia.ece.uic.edu (Shashank Khanvilkar) Date: Wed, 6 Aug 2003 18:16:17 -0500 (CDT) Subject: Reg. openssh-3.51p1/packet.c (function packet_send2()) In-Reply-To: <20030806212008.GA5101@folly> Message-ID: On Wed, 6 Aug 2003, Markus Friedl wrote: > hi, what is all this ppp talk about? PPP was only used to create a serial SSH link (for VPN). For example: the following command was used: pppd pty 'ssh -t -t zidler pppd 192.168.254.201:192.168.254.200' (some options were spevifed to PPPd to disable compression and authentication) For all practical purpses you can assume that the PPP frame is something which needs to be transmitted to the other end over SSH. > > why don't you just recompile packet.c > with PACKET_DEBUG? what exactly is the problem? I did recompile the whole package using -DPACKET_DEBUG flag. The problem is that i want to see how much extra overhead is introduced by SSH for transmitting a packet of say, 100 Bytes. (Assume, blowfish_cbc, hmac_md5. no compression in both directions) HTH SHashank > > _______________________________________________ > 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 Aug 8 12:15:53 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 08 Aug 2003 12:15:53 +1000 Subject: Problem with -current on Solaris 8 + PAM? Message-ID: <3F3307D9.7E27C90F@zip.com.au> Hi All. Has anyone else tried the current tree on Solaris 8? I installed a recommended patch cluster and now I get PAM errors, but only on a non-interactive (ie no TTY) login. I think this behaviour was introduced with the patch cluster. First thing is that in debug mode, the debug at auth-pam.c:534 derefs tty which is null, and segfaults. This occurs in debug mode only and is easy to fix. The next problem is that pam_open_session now seems to fail when PAM_TTY is set to NULL. debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req exec debug1: PAM: setting PAM_TTY to "(null)" PAM: pam_open_session(): Can not make/remove entry for session The code from 3.6.1p2 is doesn't set PAM_TTY at all when tty is NULL. Doing that fixes -current for me. Should it be changed to do the same thing, ie --- auth-pam.c 3 Jun 2003 00:25:48 -0000 1.64 +++ auth-pam.c 8 Aug 2003 02:13:34 -0000 @@ -531,11 +531,13 @@ if (sshpam_err != PAM_SUCCESS) fatal("PAM: failed to set PAM_CONV: %s", pam_strerror(sshpam_handle, sshpam_err)); - debug("PAM: setting PAM_TTY to \"%s\"", tty); - sshpam_err = pam_set_item(sshpam_handle, PAM_TTY, tty); - if (sshpam_err != PAM_SUCCESS) - fatal("PAM: failed to set PAM_TTY: %s", - pam_strerror(sshpam_handle, sshpam_err)); + if (tty != NULL) { + debug("PAM: setting PAM_TTY to \"%s\"", tty); + sshpam_err = pam_set_item(sshpam_handle, PAM_TTY, tty); + if (sshpam_err != PAM_SUCCESS) + fatal("PAM: failed to set PAM_TTY: %s", + pam_strerror(sshpam_handle, sshpam_err)); + } sshpam_err = pam_open_session(sshpam_handle, 0); if (sshpam_err != PAM_SUCCESS) fatal("PAM: pam_open_session(): %s", -- 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 Fri Aug 8 13:53:04 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 08 Aug 2003 13:53:04 +1000 Subject: Help request: merging OpenBSD Kerberos change into Portable. Message-ID: <3F331EA0.5F704686@zip.com.au> Hi All. I'm looking for some help to merge an outstanding Kerberos credential cache change from OpenBSD into Portable. I don't know enough about Kerberos to figure out how that change should be applied for the non-Heimdal(?) code path. The outstanding diff is attached. Any volunteers? -- 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 -------------- revision 1.11 date: 2003/07/16 15:02:06; author: markus; state: Exp; lines: +23 -6 mcc -> fcc; from Love H?rnquist ?strand otherwise the kerberos credentinal is stored in a memory cache in the privileged sshd. ok jabob@, hin@ (some time ago) ============================================================================= Index: auth-krb5.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/auth-krb5.c,v retrieving revision 1.10 retrieving revision 1.11 diff -u -p -u -r1.10 -r1.11 --- auth-krb5.c 2002/11/21 23:03:51 1.10 +++ auth-krb5.c 2003/07/16 15:02:06 1.11 @@ -28,7 +28,7 @@ */ #include "includes.h" -RCSID("$OpenBSD: auth-krb5.c,v 1.10 2002/11/21 23:03:51 deraadt Exp $"); +RCSID("$OpenBSD: auth-krb5.c,v 1.11 2003/07/16 15:02:06 markus Exp $"); #include "ssh.h" #include "ssh1.h" @@ -208,6 +208,7 @@ int auth_krb5_password(Authctxt *authctxt, const char *password) { krb5_error_code problem; + krb5_ccache ccache = NULL; if (authctxt->pw == NULL) return (0); @@ -223,30 +224,46 @@ auth_krb5_password(Authctxt *authctxt, c if (problem) goto out; - problem = krb5_cc_gen_new(authctxt->krb5_ctx, &krb5_mcc_ops, - &authctxt->krb5_fwd_ccache); + problem = krb5_cc_gen_new(authctxt->krb5_ctx, &krb5_mcc_ops, &ccache); if (problem) goto out; - problem = krb5_cc_initialize(authctxt->krb5_ctx, - authctxt->krb5_fwd_ccache, authctxt->krb5_user); + problem = krb5_cc_initialize(authctxt->krb5_ctx, ccache, + authctxt->krb5_user); if (problem) goto out; restore_uid(); + problem = krb5_verify_user(authctxt->krb5_ctx, authctxt->krb5_user, - authctxt->krb5_fwd_ccache, password, 1, NULL); + ccache, password, 1, NULL); + temporarily_use_uid(authctxt->pw); if (problem) goto out; + problem = krb5_cc_gen_new(authctxt->krb5_ctx, &krb5_fcc_ops, + &authctxt->krb5_fwd_ccache); + if (problem) + goto out; + + problem = krb5_cc_copy_cache(authctxt->krb5_ctx, ccache, + authctxt->krb5_fwd_ccache); + krb5_cc_destroy(authctxt->krb5_ctx, ccache); + ccache = NULL; + if (problem) + goto out; + authctxt->krb5_ticket_file = (char *)krb5_cc_get_name(authctxt->krb5_ctx, authctxt->krb5_fwd_ccache); out: restore_uid(); if (problem) { + if (ccache) + krb5_cc_destroy(authctxt->krb5_ctx, ccache); + if (authctxt->krb5_ctx != NULL) debug("Kerberos password authentication failed: %s", krb5_get_err_text(authctxt->krb5_ctx, problem)); From sxw at inf.ed.ac.uk Fri Aug 8 19:36:38 2003 From: sxw at inf.ed.ac.uk (sxw at inf.ed.ac.uk) Date: Fri, 8 Aug 2003 10:36:38 +0100 (BST) Subject: Help request: merging OpenBSD Kerberos change into Portable. In-Reply-To: <3F331EA0.5F704686@zip.com.au> Message-ID: On Fri, 8 Aug 2003, Darren Tucker wrote: > Hi All. > I'm looking for some help to merge an outstanding Kerberos > credential cache change from OpenBSD into Portable. I don't know enough > about Kerberos to figure out how that change should be applied for the > non-Heimdal(?) code path. There aren't any changes necessary in the non-Heimdal path. The change moves the Heimdal code from using a memory based ccache to store user credentials, to using a file based one. The non-Heimdal code has always used a file based ccache. [Aside: It would be significantly nicer architecturaly to store a users credentials in memory until the last minute, and then have one location in which they are written out, rather than the current situation where the store credentials code is duplicated.] Cheers, Simon From dtucker at zip.com.au Fri Aug 8 20:09:33 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 08 Aug 2003 20:09:33 +1000 Subject: Help request: merging OpenBSD Kerberos change into Portable. References: Message-ID: <3F3376DC.C0EC9CD7@zip.com.au> sxw at inf.ed.ac.uk wrote: > On Fri, 8 Aug 2003, Darren Tucker wrote: [krb5 merge] > There aren't any changes necessary in the non-Heimdal path. The change > moves the Heimdal code from using a memory based ccache to store user > credentials, to using a file based one. The non-Heimdal code has > always used a file based ccache. Thanks! I've merged the changes into the portable tree and compiled it --with-kerberos5, which compiled OK. I've double-checked it against the OpenBSD diff and I think its OK, but please let me know if I've missed anything. -- 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 -------------- Index: auth-krb5.c =================================================================== RCS file: /var/cvs/openssh/auth-krb5.c,v retrieving revision 1.13 diff -u -p -r1.13 auth-krb5.c --- auth-krb5.c 14 May 2003 04:31:11 -0000 1.13 +++ auth-krb5.c 8 Aug 2003 09:44:16 -0000 @@ -28,7 +28,7 @@ */ #include "includes.h" -RCSID("$OpenBSD: auth-krb5.c,v 1.10 2002/11/21 23:03:51 deraadt Exp $"); +RCSID("$OpenBSD: auth-krb5.c,v 1.11 2003/07/16 15:02:06 markus Exp $"); #include "ssh.h" #include "ssh1.h" @@ -265,6 +265,7 @@ auth_krb5_password(Authctxt *authctxt, c int tmpfd; #endif krb5_error_code problem; + krb5_ccache ccache = NULL; if (authctxt->pw == NULL) return (0); @@ -281,23 +282,35 @@ auth_krb5_password(Authctxt *authctxt, c goto out; #ifdef HEIMDAL - problem = krb5_cc_gen_new(authctxt->krb5_ctx, &krb5_mcc_ops, - &authctxt->krb5_fwd_ccache); + problem = krb5_cc_gen_new(authctxt->krb5_ctx, &krb5_mcc_ops, &ccache); if (problem) goto out; - problem = krb5_cc_initialize(authctxt->krb5_ctx, - authctxt->krb5_fwd_ccache, authctxt->krb5_user); + problem = krb5_cc_initialize(authctxt->krb5_ctx, ccache, + authctxt->krb5_user); if (problem) goto out; restore_uid(); + problem = krb5_verify_user(authctxt->krb5_ctx, authctxt->krb5_user, - authctxt->krb5_fwd_ccache, password, 1, NULL); + ccache, password, 1, NULL); + temporarily_use_uid(authctxt->pw); if (problem) goto out; + problem = krb5_cc_gen_new(authctxt->krb5_ctx, &krb5_fcc_ops, + &authctxt->krb5_fwd_ccache); + if (problem) + goto out; + + problem = krb5_cc_copy_cache(authctxt->krb5_ctx, ccache, + authctxt->krb5_fwd_ccache); + krb5_cc_destroy(authctxt->krb5_ctx, ccache); + ccache = NULL; + if (problem) + goto out; #else problem = krb5_get_init_creds_password(authctxt->krb5_ctx, &creds, @@ -361,6 +374,9 @@ auth_krb5_password(Authctxt *authctxt, c restore_uid(); if (problem) { + if (ccache) + krb5_cc_destroy(authctxt->krb5_ctx, ccache); + if (authctxt->krb5_ctx != NULL && problem!=-1) debug("Kerberos password authentication failed: %s", krb5_get_err_text(authctxt->krb5_ctx, problem)); From pekkas at netcore.fi Wed Aug 6 07:01:23 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Wed, 6 Aug 2003 00:01:23 +0300 (EEST) Subject: a problem in snapshot generation? Message-ID: Hi, It appears the openssh snapshots and the ChangeLog file have not been updated in about a week in ftp.openbsd.org. Could this problem be fixed? Thanks. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From dtucker at zip.com.au Fri Aug 8 22:23:39 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 08 Aug 2003 22:23:39 +1000 Subject: a problem in snapshot generation? References: Message-ID: <3F33964B.94D42B76@zip.com.au> Pekka Savola wrote: > It appears the openssh snapshots and the ChangeLog file have not been > updated in about a week in ftp.openbsd.org. Could this problem be fixed? Your message was delayed (mail server problems apparently) but the snapshots are working as of 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 Sat Aug 9 15:12:45 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 09 Aug 2003 15:12:45 +1000 Subject: Timing attacks and owl-always-auth Message-ID: <3F3482CD.71289ABE@zip.com.au> Hi All. Attached is a patch against OpenBSD, based in part on the owl-always-auth patch. The idea is that the only way out of auth_passwd for the failure case is the "return 0" at the bottom. I don't know if this is a good way to do it or not, it's presented for discussion. Also, I don't think 3.6.1p2 is quite right WRT these timing issues (eg, you get a fast failure if you get the root password right and PermitRootLogin=no, and there's the infamous delay due to the "none" authentication). -- 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 -------------- Index: auth-passwd.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/auth-passwd.c,v retrieving revision 1.28 diff -u -p -r1.28 auth-passwd.c --- auth-passwd.c 2003/07/22 13:35:22 1.28 +++ auth-passwd.c 2003/08/09 04:45:13 @@ -43,9 +43,17 @@ RCSID("$OpenBSD: auth-passwd.c,v 1.28 20 #include "servconf.h" #include "auth.h" - extern ServerOptions options; +int auth_ok; +int +auth_result(int result) +{ + if (result == 0) + auth_ok = 0; + return auth_ok; +} + /* * Tries to authenticate the user using password. Returns true if * authentication succeeds. @@ -54,42 +62,52 @@ int auth_password(Authctxt *authctxt, const char *password) { struct passwd * pw = authctxt->pw; + char *user = authctxt->user; + int success; + + auth_ok = authctxt->valid; /* deny if no user. */ if (pw == NULL) - return 0; + auth_result(0); if (pw->pw_uid == 0 && options.permit_root_login != PERMIT_YES) - return 0; + auth_result(0); if (*password == '\0' && options.permit_empty_passwd == 0) - return 0; + auth_result(0); #ifdef KRB5 if (options.kerberos_authentication == 1) { - int ret = auth_krb5_password(authctxt, password); - if (ret == 1 || ret == 0) - return ret; + success = auth_krb5_password(authctxt, password); + if (success == 1 || success == 0) + if (auth_result(success) == 1) + return 1; /* Fall back to ordinary passwd authentication. */ } #endif #ifdef BSD_AUTH - if (auth_userokay(pw->pw_name, authctxt->style, "auth-ssh", - (char *)password) == 0) - return 0; - else + success = (auth_userokay(user, authctxt->style, "auth-ssh", + (char *)password) == 0); + if (auth_result(success) == 1) return 1; #else /* Check for users with no password. */ - if (strcmp(password, "") == 0 && strcmp(pw->pw_passwd, "") == 0) + success = (strcmp(password, "") == 0 && strcmp(pw->pw_passwd, "") == 0) + if (auth_result(success) == 1) return 1; else { /* Encrypt the candidate password using the proper salt. */ char *encrypted_password = crypt(password, - (pw->pw_passwd[0] && pw->pw_passwd[1]) ? + (pw && pw->pw_passwd[0] && pw->pw_passwd[1]) ? pw->pw_passwd : "xx"); /* * Authentication is accepted if the encrypted passwords * are identical. */ - return (strcmp(encrypted_password, pw->pw_passwd) == 0); + if (pw) { + success = (strcmp(encrypted_password, pw->pw_passwd) == 0); + if (auth_result(success) == 1) + return 1; + } } + return 0; #endif } Index: auth2-none.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/auth2-none.c,v retrieving revision 1.5 diff -u -p -r1.5 auth2-none.c --- auth2-none.c 2003/07/31 09:21:02 1.5 +++ auth2-none.c 2003/08/09 04:45:13 @@ -96,7 +96,7 @@ userauth_none(Authctxt *authctxt) none_enabled = 0; packet_check_eom(); userauth_banner(); - if (options.password_authentication && authctxt->valid) + if (options.password_authentication && options.permit_empty_passwd) return (PRIVSEP(auth_password(authctxt, ""))); return (0); } From abartlet at samba.org Sat Aug 9 16:00:25 2003 From: abartlet at samba.org (Andrew Bartlett) Date: Sat, 09 Aug 2003 06:00:25 -0000 Subject: 'cancel-tcpip-forward' is not supported. In-Reply-To: <20030806092256.GA28062@folly> References: <200308060643.PAA00978@jcraft.com> <20030806092256.GA28062@folly> Message-ID: <1060408929.9422.127.camel@piglett.bartlett.house> On Wed, 2003-08-06 at 19:22, Markus Friedl wrote: > our client does not support it, so our server does not, > but you can send patches. I have almost no clue what I'm talking about here, but would the SOCKS support benefit from this? Ie, after the connection from the socks client is closed, we don't need to keep the server-side state for that connection any more, as it is likely it will never be re-used (SOCKS client having gone on to other things). Andrew Bartlett -- Andrew Bartlett abartlet at pcug.org.au Manager, Authentication Subsystems, Samba Team abartlet at samba.org Student Network Administrator, Hawker College abartlet at hawkerc.net http://samba.org http://build.samba.org http://hawkerc.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030809/8ecc9b0c/attachment.bin From markus at openbsd.org Sun Aug 10 03:21:41 2003 From: markus at openbsd.org (Markus Friedl) Date: Sat, 9 Aug 2003 19:21:41 +0200 Subject: 'cancel-tcpip-forward' is not supported. In-Reply-To: <1060408929.9422.127.camel@piglett.bartlett.house> References: <200308060643.PAA00978@jcraft.com> <20030806092256.GA28062@folly> <1060408929.9422.127.camel@piglett.bartlett.house> Message-ID: <20030809172138.GA32335@folly> i don't see how this is related to -D. -D is like -L and -R has nothing todo with -L or -D. On Sat, Aug 09, 2003 at 04:02:11PM +1000, Andrew Bartlett wrote: > On Wed, 2003-08-06 at 19:22, Markus Friedl wrote: > > our client does not support it, so our server does not, > > but you can send patches. > > I have almost no clue what I'm talking about here, but would the SOCKS > support benefit from this? Ie, after the connection from the socks > client is closed, we don't need to keep the server-side state for that > connection any more, as it is likely it will never be re-used (SOCKS > client having gone on to other things). > > Andrew Bartlett > > -- > Andrew Bartlett abartlet at pcug.org.au > Manager, Authentication Subsystems, Samba Team abartlet at samba.org > Student Network Administrator, Hawker College abartlet at hawkerc.net > http://samba.org http://build.samba.org http://hawkerc.net From jakob at openbsd.org Mon Aug 11 00:43:52 2003 From: jakob at openbsd.org (Jakob Schlyter) Date: Sun, 10 Aug 2003 16:43:52 +0200 (CEST) Subject: updated gssapi diff Message-ID: this is the proposed gssapi diff against OpenSSH-current (non-portable). note: if this goes in, the old krb5 auth (ssh.com compatible) will be removed. please comment. jakob Index: auth.h =================================================================== RCS file: /home/hack/jakob/mycvs/sshgss/auth.h,v retrieving revision 1.1.1.2 retrieving revision 1.3 diff -u -r1.1.1.2 -r1.3 --- auth.h 10 Aug 2003 14:06:43 -0000 1.1.1.2 +++ auth.h 10 Aug 2003 14:25:01 -0000 1.3 @@ -67,6 +67,7 @@ krb5_principal krb5_user; char *krb5_ticket_file; #endif + void *methoddata; }; /* * Every authentication method has to handle authentication requests for Index: auth2-gss.c =================================================================== RCS file: auth2-gss.c diff -N auth2-gss.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ auth2-gss.c 18 May 2003 16:51:43 -0000 1.13 @@ -0,0 +1,243 @@ +/* $OpenBSD$ */ + +/* + * Copyright (c) 2001-2003 Simon Wilkinson. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +#include "includes.h" + +#ifdef GSSAPI + +#include "auth.h" +#include "ssh2.h" +#include "xmalloc.h" +#include "log.h" +#include "dispatch.h" +#include "servconf.h" +#include "compat.h" +#include "packet.h" +#include "monitor_wrap.h" + +#include "ssh-gss.h" + +extern ServerOptions options; + +static void input_gssapi_token(int type, u_int32_t plen, void *ctxt); +static void input_gssapi_exchange_complete(int type, u_int32_t plen, void *ctxt); +static void input_gssapi_errtok(int, u_int32_t, void *); + +/* + * We only support those mechanisms that we know about (ie ones that we know + * how to check local user kuserok and the like + */ +static int +userauth_gssapi(Authctxt *authctxt) +{ + gss_OID_desc oid = {0, NULL}; + Gssctxt *ctxt = NULL; + int mechs; + gss_OID_set supported; + int present; + OM_uint32 ms; + u_int len; + char *doid = NULL; + + if (!authctxt->valid || authctxt->user == NULL) + return (0); + + mechs = packet_get_int(); + if (mechs == 0) { + debug("Mechanism negotiation is not supported"); + return (0); + } + + ssh_gssapi_supported_oids(&supported); + do { + mechs--; + + if (doid) + xfree(doid); + + doid = packet_get_string(&len); + + if (doid[0] != SSH_GSS_OIDTYPE || doid[1] != len-2) { + logit("Mechanism OID received using the old encoding form"); + oid.elements = doid; + oid.length = len; + } else { + oid.elements = doid + 2; + oid.length = len - 2; + } + gss_test_oid_set_member(&ms, &oid, supported, &present); + } while (mechs > 0 && !present); + + gss_release_oid_set(&ms, &supported); + + if (!present) { + xfree(doid); + return (0); + } + + if (GSS_ERROR(PRIVSEP(ssh_gssapi_server_ctx(&ctxt, &oid)))) + return (0); + + authctxt->methoddata=(void *)ctxt; + + packet_start(SSH2_MSG_USERAUTH_GSSAPI_RESPONSE); + + /* Return OID in same format as we received it*/ + packet_put_string(doid, len); + + packet_send(); + xfree(doid); + + dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_TOKEN, &input_gssapi_token); + dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_ERRTOK, &input_gssapi_errtok); + authctxt->postponed = 1; + + return (0); +} + +static void +input_gssapi_token(int type, u_int32_t plen, void *ctxt) +{ + Authctxt *authctxt = ctxt; + Gssctxt *gssctxt; + gss_buffer_desc send_tok = GSS_C_EMPTY_BUFFER; + gss_buffer_desc recv_tok; + OM_uint32 maj_status, min_status; + u_int len; + + if (authctxt == NULL || (authctxt->methoddata == NULL && !use_privsep)) + fatal("No authentication or GSSAPI context"); + + gssctxt = authctxt->methoddata; + recv_tok.value = packet_get_string(&len); + recv_tok.length = len; /* u_int vs. size_t */ + + packet_check_eom(); + + maj_status = PRIVSEP(ssh_gssapi_accept_ctx(gssctxt, &recv_tok, + &send_tok, NULL)); + + xfree(recv_tok.value); + + if (GSS_ERROR(maj_status)) { + if (send_tok.length != 0) { + packet_start(SSH2_MSG_USERAUTH_GSSAPI_ERRTOK); + packet_put_string(send_tok.value, send_tok.length); + packet_send(); + } + authctxt->postponed = 0; + dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_TOKEN, NULL); + userauth_finish(authctxt, 0, "gssapi"); + } else { + if (send_tok.length != 0) { + packet_start(SSH2_MSG_USERAUTH_GSSAPI_TOKEN); + packet_put_string(send_tok.value, send_tok.length); + packet_send(); + } + if (maj_status == GSS_S_COMPLETE) { + dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_TOKEN, NULL); + dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE, + &input_gssapi_exchange_complete); + } + } + + gss_release_buffer(&min_status, &send_tok); +} + +static void +input_gssapi_errtok(int type, u_int32_t plen, void *ctxt) +{ + Authctxt *authctxt = ctxt; + Gssctxt *gssctxt; + gss_buffer_desc send_tok = GSS_C_EMPTY_BUFFER; + gss_buffer_desc recv_tok; + OM_uint32 maj_status; + + if (authctxt == NULL || (authctxt->methoddata == NULL && !use_privsep)) + fatal("No authentication or GSSAPI context"); + + gssctxt = authctxt->methoddata; + recv_tok.value = packet_get_string(&recv_tok.length); + + packet_check_eom(); + + /* Push the error token into GSSAPI to see what it says */ + maj_status = PRIVSEP(ssh_gssapi_accept_ctx(gssctxt, &recv_tok, + &send_tok, NULL)); + + xfree(recv_tok.value); + + /* We can't return anything to the client, even if we wanted to */ + dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_TOKEN, NULL); + dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_ERRTOK, NULL); + + /* The client will have already moved on to the next auth */ + + gss_release_buffer(&maj_status, &send_tok); +} + +/* + * This is called when the client thinks we've completed authentication. + * It should only be enabled in the dispatch handler by the function above, + * which only enables it once the GSSAPI exchange is complete. + */ + +static void +input_gssapi_exchange_complete(int type, u_int32_t plen, void *ctxt) +{ + Authctxt *authctxt = ctxt; + Gssctxt *gssctxt; + int authenticated; + + if (authctxt == NULL || (authctxt->methoddata == NULL && !use_privsep)) + fatal("No authentication or GSSAPI context"); + + gssctxt = authctxt->methoddata; + + /* + * We don't need to check the status, because the stored credentials + * which userok uses are only populated once the context init step + * has returned complete. + */ + + packet_check_eom(); + + authenticated = PRIVSEP(ssh_gssapi_userok(authctxt->user)); + + authctxt->postponed = 0; + dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_TOKEN, NULL); + dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_ERRTOK, NULL); + dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE, NULL); + userauth_finish(authctxt, authenticated, "gssapi"); +} + +Authmethod method_gssapi = { + "gssapi", + userauth_gssapi, + &options.gss_authentication +}; + +#endif /* GSSAPI */ Index: auth2.c =================================================================== RCS file: /home/hack/jakob/mycvs/sshgss/auth2.c,v retrieving revision 1.1.1.2 retrieving revision 1.5 diff -u -r1.1.1.2 -r1.5 --- auth2.c 10 Aug 2003 14:06:43 -0000 1.1.1.2 +++ auth2.c 10 Aug 2003 14:25:01 -0000 1.5 @@ -36,6 +36,10 @@ #include "pathnames.h" #include "monitor_wrap.h" +#ifdef GSSAPI +#include "ssh-gss.h" +#endif + /* import */ extern ServerOptions options; extern u_char *session_id2; @@ -53,10 +57,16 @@ #ifdef KRB5 extern Authmethod method_kerberos; #endif +#ifdef GSSAPI +extern Authmethod method_gssapi; +#endif Authmethod *authmethods[] = { &method_none, &method_pubkey, +#ifdef GSSAPI + &method_gssapi, +#endif &method_passwd, &method_kbdint, &method_hostbased, @@ -176,6 +186,12 @@ } /* reset state */ auth2_challenge_stop(authctxt); + +#ifdef GSSAPI + dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_TOKEN, NULL); + dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE, NULL); +#endif + authctxt->postponed = 0; /* try to authenticate user */ Index: compat.c =================================================================== RCS file: /home/hack/jakob/mycvs/sshgss/compat.c,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- compat.c 17 May 2003 03:34:10 -0000 1.1.1.1 +++ compat.c 17 May 2003 03:49:36 -0000 1.2 @@ -79,7 +79,11 @@ { "OpenSSH_2.5.3*", SSH_BUG_NOREKEY|SSH_BUG_EXTEOF}, { "OpenSSH_2.*," "OpenSSH_3.0*," - "OpenSSH_3.1*", SSH_BUG_EXTEOF}, + "OpenSSH_3.1*", SSH_BUG_EXTEOF|SSH_BUG_GSSAPI_BER}, + { "OpenSSH_3.2*," + "OpenSSH_3.3*," + "OpenSSH_3.4*," + "OpenSSH_3.5*", SSH_BUG_GSSAPI_BER}, { "Sun_SSH_1.0*", SSH_BUG_NOREKEY|SSH_BUG_EXTEOF}, { "OpenSSH*", 0 }, { "*MindTerm*", 0 }, Index: compat.h =================================================================== RCS file: /home/hack/jakob/mycvs/sshgss/compat.h,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- compat.h 17 May 2003 03:34:10 -0000 1.1.1.1 +++ compat.h 17 May 2003 03:49:36 -0000 1.2 @@ -56,6 +56,7 @@ #define SSH_BUG_K5USER 0x00400000 #define SSH_BUG_PROBE 0x00800000 #define SSH_BUG_FIRSTKEX 0x01000000 +#define SSH_BUG_GSSAPI_BER 0x02000000 void enable_compat13(void); void enable_compat20(void); Index: gss-genr.c =================================================================== RCS file: gss-genr.c diff -N gss-genr.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gss-genr.c 18 May 2003 16:56:30 -0000 1.8 @@ -0,0 +1,255 @@ +/* $OpenBSD$ */ + +/* + * Copyright (c) 2001-2003 Simon Wilkinson. All rights reserved. * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR `AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +#include "includes.h" + +#ifdef GSSAPI + +#include "xmalloc.h" +#include "bufaux.h" +#include "compat.h" +#include "log.h" +#include "monitor_wrap.h" + +#include "ssh-gss.h" + + +/* Check that the OID in a data stream matches that in the context */ +int +ssh_gssapi_check_oid(Gssctxt *ctx, void *data, size_t len) +{ + return (ctx != NULL && ctx->oid != GSS_C_NO_OID && + ctx->oid->length == len && + memcmp(ctx->oid->elements, data, len) == 0); +} + +/* Set the contexts OID from a data stream */ +void +ssh_gssapi_set_oid_data(Gssctxt *ctx, void *data, size_t len) +{ + if (ctx->oid != GSS_C_NO_OID) { + xfree(ctx->oid->elements); + xfree(ctx->oid); + } + ctx->oid = xmalloc(sizeof(gss_OID_desc)); + ctx->oid->length = len; + ctx->oid->elements = xmalloc(len); + memcpy(ctx->oid->elements, data, len); +} + +/* Set the contexts OID */ +void +ssh_gssapi_set_oid(Gssctxt *ctx, gss_OID oid) +{ + ssh_gssapi_set_oid_data(ctx, oid->elements, oid->length); +} + +/* All this effort to report an error ... */ +void +ssh_gssapi_error(Gssctxt *ctxt) +{ + debug("%s", ssh_gssapi_last_error(ctxt, NULL, NULL)); +} + +char * +ssh_gssapi_last_error(Gssctxt *ctxt, + OM_uint32 *major_status, OM_uint32 *minor_status) +{ + OM_uint32 lmin; + gss_buffer_desc msg = GSS_C_EMPTY_BUFFER; + OM_uint32 ctx; + Buffer b; + char *ret; + + buffer_init(&b); + + if (major_status != NULL) + *major_status = ctxt->major; + if (minor_status != NULL) + *minor_status = ctxt->minor; + + ctx = 0; + /* The GSSAPI error */ + do { + gss_display_status(&lmin, ctxt->major, + GSS_C_GSS_CODE, GSS_C_NULL_OID, &ctx, &msg); + + buffer_append(&b, msg.value, msg.length); + buffer_put_char(&b, '\n'); + + gss_release_buffer(&lmin, &msg); + } while (ctx != 0); + + /* The mechanism specific error */ + do { + gss_display_status(&lmin, ctxt->minor, + GSS_C_MECH_CODE, GSS_C_NULL_OID, &ctx, &msg); + + buffer_append(&b, msg.value, msg.length); + buffer_put_char(&b, '\n'); + + gss_release_buffer(&lmin, &msg); + } while (ctx != 0); + + buffer_put_char(&b, '\0'); + ret = xmalloc(buffer_len(&b)); + buffer_get(&b, ret, buffer_len(&b)); + buffer_free(&b); + return (ret); +} + +/* + * Initialise our GSSAPI context. We use this opaque structure to contain all + * of the data which both the client and server need to persist across + * {accept,init}_sec_context calls, so that when we do it from the userauth + * stuff life is a little easier + */ +void +ssh_gssapi_build_ctx(Gssctxt **ctx) +{ + *ctx = xmalloc(sizeof (Gssctxt)); + (*ctx)->major = 0; + (*ctx)->minor = 0; + (*ctx)->context = GSS_C_NO_CONTEXT; + (*ctx)->name = GSS_C_NO_NAME; + (*ctx)->oid = GSS_C_NO_OID; + (*ctx)->creds = GSS_C_NO_CREDENTIAL; + (*ctx)->client = GSS_C_NO_NAME; + (*ctx)->client_creds = GSS_C_NO_CREDENTIAL; +} + +/* Delete our context, providing it has been built correctly */ +void +ssh_gssapi_delete_ctx(Gssctxt **ctx) +{ + OM_uint32 ms; + + if ((*ctx) == NULL) + return; + if ((*ctx)->context != GSS_C_NO_CONTEXT) + gss_delete_sec_context(&ms, &(*ctx)->context, GSS_C_NO_BUFFER); + if ((*ctx)->name != GSS_C_NO_NAME) + gss_release_name(&ms, &(*ctx)->name); + if ((*ctx)->oid != GSS_C_NO_OID) { + xfree((*ctx)->oid->elements); + xfree((*ctx)->oid); + (*ctx)->oid = GSS_C_NO_OID; + } + if ((*ctx)->creds != GSS_C_NO_CREDENTIAL) + gss_release_cred(&ms, &(*ctx)->creds); + if ((*ctx)->client != GSS_C_NO_NAME) + gss_release_name(&ms, &(*ctx)->client); + if ((*ctx)->client_creds != GSS_C_NO_CREDENTIAL) + gss_release_cred(&ms, &(*ctx)->client_creds); + + xfree(*ctx); + *ctx = NULL; +} + +/* + * Wrapper to init_sec_context + * Requires that the context contains: + * oid + * server name (from ssh_gssapi_import_name) + */ +OM_uint32 +ssh_gssapi_init_ctx(Gssctxt *ctx, int deleg_creds, gss_buffer_desc *recv_tok, + gss_buffer_desc* send_tok, OM_uint32 *flags) +{ + int deleg_flag = 0; + + if (deleg_creds) { + deleg_flag = GSS_C_DELEG_FLAG; + debug("Delegating credentials"); + } + + ctx->major = gss_init_sec_context(&ctx->minor, + GSS_C_NO_CREDENTIAL, &ctx->context, ctx->name, ctx->oid, + GSS_C_MUTUAL_FLAG | GSS_C_INTEG_FLAG | deleg_flag, + 0, NULL, recv_tok, NULL, send_tok, flags, NULL); + + if (GSS_ERROR(ctx->major)) + ssh_gssapi_error(ctx); + + return (ctx->major); +} + +/* Create a service name for the given host */ +OM_uint32 +ssh_gssapi_import_name(Gssctxt *ctx, const char *host) +{ + gss_buffer_desc gssbuf; + + gssbuf.length = sizeof("host@") + strlen(host); + gssbuf.value = xmalloc(gssbuf.length); + snprintf(gssbuf.value, gssbuf.length, "host@%s", host); + + if ((ctx->major = gss_import_name(&ctx->minor, + &gssbuf, GSS_C_NT_HOSTBASED_SERVICE, &ctx->name))) + ssh_gssapi_error(ctx); + + xfree(gssbuf.value); + return (ctx->major); +} + +/* Acquire credentials for a server running on the current host. + * Requires that the context structure contains a valid OID + */ + +/* Returns a GSSAPI error code */ +OM_uint32 +ssh_gssapi_acquire_cred(Gssctxt *ctx) +{ + OM_uint32 status; + char lname[MAXHOSTNAMELEN]; + gss_OID_set oidset; + + gss_create_empty_oid_set(&status, &oidset); + gss_add_oid_set_member(&status, ctx->oid, &oidset); + + if (gethostname(lname, MAXHOSTNAMELEN)) + return (-1); + + if (GSS_ERROR(ssh_gssapi_import_name(ctx, lname))) + return (ctx->major); + + if ((ctx->major = gss_acquire_cred(&ctx->minor, + ctx->name, 0, oidset, GSS_C_ACCEPT, &ctx->creds, NULL, NULL))) + ssh_gssapi_error(ctx); + + gss_release_oid_set(&status, &oidset); + return (ctx->major); +} + +OM_uint32 +ssh_gssapi_server_ctx(Gssctxt **ctx, gss_OID oid) { + if (*ctx) + ssh_gssapi_delete_ctx(ctx); + ssh_gssapi_build_ctx(ctx); + ssh_gssapi_set_oid(*ctx, oid); + return (ssh_gssapi_acquire_cred(*ctx)); +} + +#endif /* GSSAPI */ Index: gss-serv-krb5.c =================================================================== RCS file: gss-serv-krb5.c diff -N gss-serv-krb5.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gss-serv-krb5.c 2 Jun 2003 18:23:49 -0000 1.9 @@ -0,0 +1,168 @@ +/* $OpenBSD$ */ + +/* + * Copyright (c) 2001-2003 Simon Wilkinson. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR `AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +#include "includes.h" + +#ifdef GSSAPI +#ifdef KRB5 + +#include "auth.h" +#include "xmalloc.h" +#include "log.h" +#include "servconf.h" + +#include "ssh-gss.h" + +extern ServerOptions options; + +#include + +static krb5_context krb_context = NULL; + +/* Initialise the krb5 library, for the stuff that GSSAPI won't do */ + +static int +ssh_gssapi_krb5_init() +{ + krb5_error_code problem; + + if (krb_context != NULL) + return 1; + + problem = krb5_init_context(&krb_context); + if (problem) { + logit("Cannot initialize krb5 context"); + return 0; + } + krb5_init_ets(krb_context); + + return 1; +} + +/* Check if this user is OK to login. This only works with krb5 - other + * GSSAPI mechanisms will need their own. + * Returns true if the user is OK to log in, otherwise returns 0 + */ + +static int +ssh_gssapi_krb5_userok(ssh_gssapi_client *client, char *name) +{ + krb5_principal princ; + int retval; + + if (ssh_gssapi_krb5_init() == 0) + return 0; + + if ((retval = krb5_parse_name(krb_context, client->exportedname.value, + &princ))) { + logit("krb5_parse_name(): %.100s", + krb5_get_err_text(krb_context, retval)); + return 0; + } + if (krb5_kuserok(krb_context, princ, name)) { + retval = 1; + logit("Authorized to %s, krb5 principal %s (krb5_kuserok)", + name, (char *)client->displayname.value); + } else + retval = 0; + + krb5_free_principal(krb_context, princ); + return retval; +} + + +/* This writes out any forwarded credentials from the structure populated + * during userauth. Called after we have setuid to the user */ + +static void +ssh_gssapi_krb5_storecreds(ssh_gssapi_client *client) +{ + krb5_ccache ccache; + krb5_error_code problem; + krb5_principal princ; + OM_uint32 maj_status, min_status; + + if (client->creds == NULL) { + debug("No credentials stored"); + return; + } + + if (ssh_gssapi_krb5_init() == 0) + return; + + if ((problem = krb5_cc_gen_new(krb_context, &krb5_fcc_ops, &ccache))) { + logit("krb5_cc_gen_new(): %.100s", + krb5_get_err_text(krb_context, problem)); + return; + } + + if ((problem = krb5_parse_name(krb_context, + client->exportedname.value, &princ))) { + logit("krb5_parse_name(): %.100s", + krb5_get_err_text(krb_context, problem)); + krb5_cc_destroy(krb_context, ccache); + return; + } + + if ((problem = krb5_cc_initialize(krb_context, ccache, princ))) { + logit("krb5_cc_initialize(): %.100s", + krb5_get_err_text(krb_context, problem)); + krb5_free_principal(krb_context, princ); + krb5_cc_destroy(krb_context, ccache); + return; + } + + krb5_free_principal(krb_context, princ); + + if ((maj_status = gss_krb5_copy_ccache(&min_status, + client->creds, ccache))) { + logit("gss_krb5_copy_ccache() failed"); + krb5_cc_destroy(krb_context, ccache); + return; + } + + client->store.filename = xstrdup(krb5_cc_get_name(krb_context, ccache)); + client->store.envvar = "KRB5CCNAME"; + client->store.envval = xstrdup(client->store.filename); + + krb5_cc_close(krb_context, ccache); + + return; +} + +ssh_gssapi_mech gssapi_kerberos_mech = { + "toWM5Slw5Ew8Mqkay+al2g==", + "Kerberos", + {9, "\x2A\x86\x48\x86\xF7\x12\x01\x02\x02"}, + NULL, + &ssh_gssapi_krb5_userok, + NULL, + &ssh_gssapi_krb5_storecreds +}; + +#endif /* KRB5 */ + +#endif /* GSSAPI */ Index: gss-serv.c =================================================================== RCS file: gss-serv.c diff -N gss-serv.c --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ gss-serv.c 2 Jun 2003 18:23:49 -0000 1.11 @@ -0,0 +1,292 @@ +/* $OpenBSD$ */ + +/* + * Copyright (c) 2001-2003 Simon Wilkinson. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR `AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +#include "includes.h" + +#ifdef GSSAPI + +#include "bufaux.h" +#include "compat.h" +#include "auth.h" +#include "log.h" +#include "channels.h" +#include "session.h" +#include "servconf.h" +#include "monitor_wrap.h" +#include "xmalloc.h" + +#include "ssh-gss.h" + +extern ServerOptions options; + +static ssh_gssapi_client gssapi_client = + { GSS_C_EMPTY_BUFFER, GSS_C_EMPTY_BUFFER, + GSS_C_NO_CREDENTIAL, NULL, {NULL, NULL, NULL}}; + +ssh_gssapi_mech gssapi_null_mech = + { NULL, NULL, {0, NULL}, NULL, NULL, NULL, NULL}; + +#ifdef KRB5 +extern ssh_gssapi_mech gssapi_kerberos_mech; +#endif + +ssh_gssapi_mech* supported_mechs[]= { +#ifdef KRB5 + &gssapi_kerberos_mech, +#endif + &gssapi_null_mech, +}; + +/* Unpriviledged */ +void +ssh_gssapi_supported_oids(gss_OID_set *oidset) +{ + int i = 0; + OM_uint32 min_status; + int present; + gss_OID_set supported; + + gss_create_empty_oid_set(&min_status, oidset); + gss_indicate_mechs(&min_status, &supported); + + while (supported_mechs[i]->name != NULL) { + if (GSS_ERROR(gss_test_oid_set_member(&min_status, + &supported_mechs[i]->oid, supported, &present))) + present = 0; + if (present) + gss_add_oid_set_member(&min_status, + &supported_mechs[i]->oid, oidset); + i++; + } +} + + +/* Wrapper around accept_sec_context + * Requires that the context contains: + * oid + * credentials (from ssh_gssapi_acquire_cred) + */ +/* Priviledged */ +OM_uint32 +ssh_gssapi_accept_ctx(Gssctxt *ctx, gss_buffer_desc *recv_tok, + gss_buffer_desc *send_tok, OM_uint32 *flags) +{ + OM_uint32 status; + gss_OID mech; + + ctx->major = gss_accept_sec_context(&ctx->minor, + &ctx->context, ctx->creds, recv_tok, + GSS_C_NO_CHANNEL_BINDINGS, &ctx->client, &mech, + send_tok, flags, NULL, &ctx->client_creds); + + if (GSS_ERROR(ctx->major)) + ssh_gssapi_error(ctx); + + if (ctx->client_creds) + debug("Received some client credentials"); + else + debug("Got no client credentials"); + + status = ctx->major; + + /* Now, if we're complete and we have the right flags, then + * we flag the user as also having been authenticated + */ + + if (((flags == NULL) || ((*flags & GSS_C_MUTUAL_FLAG) && + (*flags & GSS_C_INTEG_FLAG))) && (ctx->major == GSS_S_COMPLETE)) { + if (ssh_gssapi_getclient(ctx, &gssapi_client)) + fatal("Couldn't convert client name"); + } + + return (status); +} + +/* + * This parses an exported name, extracting the mechanism specific portion + * to use for ACL checking. It verifies that the name belongs the mechanism + * originally selected. + */ +OM_uint32 +ssh_gssapi_parse_ename(Gssctxt *ctx, gss_buffer_t ename, gss_buffer_t name) +{ + char *tok; + OM_uint32 offset; + OM_uint32 oidl; + + tok=ename->value; + + /* + * Check that ename is long enough for all of the fixed length + * header, and that the initial ID bytes are correct + */ + + if (ename->length<6 || memcmp(tok,"\x04\x01", 2)!=0) + return GSS_S_FAILURE; + + /* + * Extract the OID, and check it. Here GSSAPI breaks with tradition + * and does use the OID type and length bytes. To confuse things + * there are two lengths - the first including these, and the + * second without. + */ + + oidl = (tok[2] << 8) + tok[3]; /* length including next two bytes */ + oidl = oidl-2; /* turn it into the _real_ length of the variable OID */ + + /* + * Check the BER encoding for correct type and length, that the + * string is long enough and that the OID matches that in our context + */ + if (tok[4] != 0x06 || tok[5] != oidl || + ename->length < oidl+6 || + !ssh_gssapi_check_oid(ctx,tok+6,oidl)) + return GSS_S_FAILURE; + + offset = oidl+6; + + if (ename->length < offset+4) + return GSS_S_FAILURE; + + name->length = (tok[offset] << 24) + (tok[offset+1] << 16) + + (tok[offset+2]<<8) + (tok[offset+3]); + + offset += 4; + + if (ename->length < offset+name->length) + return GSS_S_FAILURE; + + name->value = xmalloc(name->length); + memcpy(name->value,tok+offset,name->length); + + return GSS_S_COMPLETE; +} + +/* Extract the client details from a given context. This can only reliably + * be called once for a context */ + +/* Priviledged (called from accept_secure_ctx) */ +OM_uint32 +ssh_gssapi_getclient(Gssctxt *ctx, ssh_gssapi_client *client) +{ + int i = 0; + + gss_buffer_desc ename; + + client->mech = NULL; + + while (supported_mechs[i]->name != NULL) { + if (supported_mechs[i]->oid.length == ctx->oid->length && + (memcmp(supported_mechs[i]->oid.elements, + ctx->oid->elements, ctx->oid->length) == 0)) + client->mech = supported_mechs[i]; + i++; + } + + if (client->mech == NULL) + return GSS_S_FAILURE; + + if ((ctx->major = gss_display_name(&ctx->minor, ctx->client, + &client->displayname, NULL))) { + ssh_gssapi_error(ctx); + return (ctx->major); + } + + if ((ctx->major = gss_export_name(&ctx->minor, ctx->client, + &ename))) { + ssh_gssapi_error(ctx); + return (ctx->major); + } + + if ((ctx->major = ssh_gssapi_parse_ename(ctx,&ename, + &client->exportedname))) { + return (ctx->major); + } + + /* We can't copy this structure, so we just move the pointer to it */ + client->creds = ctx->client_creds; + ctx->client_creds = GSS_C_NO_CREDENTIAL; + return (ctx->major); +} + +/* As user - called through fatal cleanup hook */ +void +ssh_gssapi_cleanup_creds(void *ignored) +{ + if (gssapi_client.store.filename != NULL) { + /* Unlink probably isn't sufficient */ + debug("removing gssapi cred file\"%s\"", gssapi_client.store.filename); + unlink(gssapi_client.store.filename); + } +} + +/* As user */ +void +ssh_gssapi_storecreds(void) +{ + if (gssapi_client.mech && gssapi_client.mech->storecreds) { + (*gssapi_client.mech->storecreds)(&gssapi_client); + if (options.gss_cleanup_creds) + fatal_add_cleanup(ssh_gssapi_cleanup_creds, NULL); + } else + debug("ssh_gssapi_storecreds: Not a GSSAPI mechanism"); +} + +/* This allows GSSAPI methods to do things to the childs environment based + * on the passed authentication process and credentials. + */ +/* As user */ +void +ssh_gssapi_do_child(char ***envp, u_int *envsizep) +{ + + if (gssapi_client.store.envvar != NULL && + gssapi_client.store.envval != NULL) { + + debug("Setting %s to %s", gssapi_client.store.envvar, + gssapi_client.store.envval); + child_set_env(envp, envsizep, gssapi_client.store.envvar, + gssapi_client.store.envval); + } +} + +/* Priviledged */ +int +ssh_gssapi_userok(char *user) +{ + if (gssapi_client.exportedname.length == 0 || + gssapi_client.exportedname.value == NULL) { + debug("No suitable client data"); + return 0; + } + if (gssapi_client.mech && gssapi_client.mech->userok) + return ((*gssapi_client.mech->userok)(&gssapi_client, user)); + else + debug("ssh_gssapi_userok: Unknown GSSAPI mechanism"); + return (0); +} + +#endif Index: monitor.c =================================================================== RCS file: /home/hack/jakob/mycvs/sshgss/monitor.c,v retrieving revision 1.1.1.2 retrieving revision 1.10 diff -u -r1.1.1.2 -r1.10 --- monitor.c 10 Aug 2003 14:06:48 -0000 1.1.1.2 +++ monitor.c 10 Aug 2003 14:25:01 -0000 1.10 @@ -59,6 +59,11 @@ #include "ssh2.h" #include "mpaux.h" +#ifdef GSSAPI +#include "ssh-gss.h" +static Gssctxt *gsscontext = NULL; +#endif + /* Imports */ extern ServerOptions options; extern u_int utmp_len; @@ -119,6 +124,11 @@ #ifdef KRB5 int mm_answer_krb5(int, Buffer *); #endif +#ifdef GSSAPI +int mm_answer_gss_setup_ctx(int, Buffer *); +int mm_answer_gss_accept_ctx(int, Buffer *); +int mm_answer_gss_userok(int, Buffer *); +#endif static Authctxt *authctxt; static BIGNUM *ssh1_challenge = NULL; /* used for ssh1 rsa auth */ @@ -168,6 +178,11 @@ #ifdef KRB5 {MONITOR_REQ_KRB5, MON_ONCE|MON_AUTH, mm_answer_krb5}, #endif +#ifdef GSSAPI + {MONITOR_REQ_GSSSETUP, MON_ISAUTH, mm_answer_gss_setup_ctx}, + {MONITOR_REQ_GSSSTEP, MON_ISAUTH, mm_answer_gss_accept_ctx}, + {MONITOR_REQ_GSSUSEROK, MON_AUTH, mm_answer_gss_userok}, +#endif {0, 0, NULL} }; @@ -320,7 +335,6 @@ monitor_permit(mon_dispatch, MONITOR_REQ_MODULI, 1); monitor_permit(mon_dispatch, MONITOR_REQ_SIGN, 1); monitor_permit(mon_dispatch, MONITOR_REQ_TERM, 1); - } else { mon_dispatch = mon_dispatch_postauth15; monitor_permit(mon_dispatch, MONITOR_REQ_TERM, 1); @@ -1586,3 +1600,77 @@ mon->m_recvfd = pair[0]; mon->m_sendfd = pair[1]; } + +#ifdef GSSAPI +int +mm_answer_gss_setup_ctx(int socket, Buffer *m) +{ + gss_OID_desc oid; + OM_uint32 major; + u_int len; + + oid.elements = buffer_get_string(m, &len); + oid.length = len; + + major = ssh_gssapi_server_ctx(&gsscontext, &oid); + + xfree(oid.elements); + + buffer_clear(m); + buffer_put_int(m, major); + + mm_request_send(socket,MONITOR_ANS_GSSSETUP, m); + + /* Now we have a context, enable the step */ + monitor_permit(mon_dispatch, MONITOR_REQ_GSSSTEP, 1); + + return (0); +} + +int +mm_answer_gss_accept_ctx(int socket, Buffer *m) +{ + gss_buffer_desc in; + gss_buffer_desc out = GSS_C_EMPTY_BUFFER; + OM_uint32 major,minor; + OM_uint32 flags = 0; /* GSI needs this */ + + in.value = buffer_get_string(m, &in.length); + major = ssh_gssapi_accept_ctx(gsscontext, &in, &out, &flags); + xfree(in.value); + + buffer_clear(m); + buffer_put_int(m, major); + buffer_put_string(m, out.value, out.length); + buffer_put_int(m, flags); + mm_request_send(socket, MONITOR_ANS_GSSSTEP, m); + + gss_release_buffer(&minor, &out); + + /* Complete - now we can do signing */ + if (major==GSS_S_COMPLETE) { + monitor_permit(mon_dispatch, MONITOR_REQ_GSSSTEP, 0); + monitor_permit(mon_dispatch, MONITOR_REQ_GSSUSEROK, 1); + } + return (0); +} + +int +mm_answer_gss_userok(int socket, Buffer *m) +{ + int authenticated; + + authenticated = authctxt->valid && ssh_gssapi_userok(authctxt->user); + + buffer_clear(m); + buffer_put_int(m, authenticated); + + debug3("%s: sending result %d", __func__, authenticated); + mm_request_send(socket, MONITOR_ANS_GSSUSEROK, m); + + auth_method="gssapi"; + + /* Monitor loop will terminate if authenticated */ + return (authenticated); +} +#endif /* GSSAPI */ Index: monitor.h =================================================================== RCS file: /home/hack/jakob/mycvs/sshgss/monitor.h,v retrieving revision 1.1.1.2 retrieving revision 1.5 diff -u -r1.1.1.2 -r1.5 --- monitor.h 10 Aug 2003 14:06:48 -0000 1.1.1.2 +++ monitor.h 10 Aug 2003 14:25:01 -0000 1.5 @@ -50,6 +50,9 @@ MONITOR_REQ_RSACHALLENGE, MONITOR_ANS_RSACHALLENGE, MONITOR_REQ_RSARESPONSE, MONITOR_ANS_RSARESPONSE, MONITOR_REQ_KRB5, MONITOR_ANS_KRB5, + MONITOR_REQ_GSSSETUP, MONITOR_ANS_GSSSETUP, + MONITOR_REQ_GSSSTEP, MONITOR_ANS_GSSSTEP, + MONITOR_REQ_GSSUSEROK, MONITOR_ANS_GSSUSEROK, MONITOR_REQ_TERM }; Index: monitor_wrap.c =================================================================== RCS file: /home/hack/jakob/mycvs/sshgss/monitor_wrap.c,v retrieving revision 1.1.1.2 retrieving revision 1.7 diff -u -r1.1.1.2 -r1.7 --- monitor_wrap.c 10 Aug 2003 14:06:49 -0000 1.1.1.2 +++ monitor_wrap.c 10 Aug 2003 14:25:01 -0000 1.7 @@ -52,6 +52,10 @@ #include "channels.h" #include "session.h" +#ifdef GSSAPI +#include "ssh-gss.h" +#endif + /* Imports */ extern int compat20; extern Newkeys *newkeys[]; @@ -971,4 +975,69 @@ buffer_free(&m); return (success); } -#endif +#endif /* KRB5 */ + +#ifdef GSSAPI +OM_uint32 +mm_ssh_gssapi_server_ctx(Gssctxt **ctx, gss_OID oid) +{ + Buffer m; + OM_uint32 major; + + /* Client doesn't get to see the context */ + *ctx = NULL; + + buffer_init(&m); + buffer_put_string(&m, oid->elements, oid->length); + + mm_request_send(pmonitor->m_recvfd, MONITOR_REQ_GSSSETUP, &m); + mm_request_receive_expect(pmonitor->m_recvfd, MONITOR_ANS_GSSSETUP, &m); + + major = buffer_get_int(&m); + + buffer_free(&m); + return (major); +} + +OM_uint32 +mm_ssh_gssapi_accept_ctx(Gssctxt *ctx, gss_buffer_desc *in, + gss_buffer_desc *out, OM_uint32 *flags) +{ + Buffer m; + OM_uint32 major; + + buffer_init(&m); + buffer_put_string(&m, in->value, in->length); + + mm_request_send(pmonitor->m_recvfd, MONITOR_REQ_GSSSTEP, &m); + mm_request_receive_expect(pmonitor->m_recvfd, MONITOR_ANS_GSSSTEP, &m); + + major = buffer_get_int(&m); + out->value = buffer_get_string(&m, &out->length); + if (flags) + *flags = buffer_get_int(&m); + + buffer_free(&m); + + return (major); +} + +int +mm_ssh_gssapi_userok(char *user) +{ + Buffer m; + int authenticated = 0; + + buffer_init(&m); + + mm_request_send(pmonitor->m_recvfd, MONITOR_REQ_GSSUSEROK, &m); + mm_request_receive_expect(pmonitor->m_recvfd, MONITOR_ANS_GSSUSEROK, + &m); + + authenticated = buffer_get_int(&m); + + buffer_free(&m); + debug3("%s: user %sauthenticated",__func__, authenticated ? "" : "not "); + return (authenticated); +} +#endif /* GSSAPI */ Index: monitor_wrap.h =================================================================== RCS file: /home/hack/jakob/mycvs/sshgss/monitor_wrap.h,v retrieving revision 1.1.1.2 retrieving revision 1.5 diff -u -r1.1.1.2 -r1.5 --- monitor_wrap.h 10 Aug 2003 14:06:49 -0000 1.1.1.2 +++ monitor_wrap.h 10 Aug 2003 14:25:01 -0000 1.5 @@ -55,6 +55,14 @@ int mm_auth_rsa_verify_response(Key *, BIGNUM *, u_char *); BIGNUM *mm_auth_rsa_generate_challenge(Key *); +#ifdef GSSAPI +#include "ssh-gss.h" +OM_uint32 mm_ssh_gssapi_server_ctx(Gssctxt **ctxt, gss_OID oid); +OM_uint32 mm_ssh_gssapi_accept_ctx(Gssctxt *ctxt, + gss_buffer_desc *recv, gss_buffer_desc *send, OM_uint32 *flags); +int mm_ssh_gssapi_userok(char *user); +#endif + void mm_terminate(void); int mm_pty_allocate(int *, int *, char *, int); void mm_session_pty_cleanup2(void *); Index: readconf.c =================================================================== RCS file: /home/hack/jakob/mycvs/sshgss/readconf.c,v retrieving revision 1.1.1.2 retrieving revision 1.3 diff -u -r1.1.1.2 -r1.3 --- readconf.c 10 Aug 2003 14:06:50 -0000 1.1.1.2 +++ readconf.c 10 Aug 2003 14:25:01 -0000 1.3 @@ -107,7 +107,7 @@ oHostKeyAlgorithms, oBindAddress, oSmartcardDevice, oClearAllForwardings, oNoHostAuthenticationForLocalhost, oEnableSSHKeysign, oRekeyLimit, oVerifyHostKeyDNS, oConnectTimeout, - oAddressFamily, + oAddressFamily, oGssAuthentication, oGssDelegateCreds, oDeprecated, oUnsupported } OpCodes; @@ -142,6 +142,13 @@ { "kerberostgtpassing", oUnsupported }, #endif { "afstokenpassing", oUnsupported }, +#if defined(GSSAPI) + { "gssapiauthentication", oGssAuthentication }, + { "gssapidelegatecredentials", oGssDelegateCreds }, +#else + { "gssapiauthentication", oUnsupported }, + { "gssapidelegatecredentials", oUnsupported }, +#endif { "fallbacktorsh", oDeprecated }, { "usersh", oDeprecated }, { "identityfile", oIdentityFile }, @@ -393,6 +400,14 @@ intptr = &options->kerberos_tgt_passing; goto parse_flag; + case oGssAuthentication: + intptr = &options->gss_authentication; + goto parse_flag; + + case oGssDelegateCreds: + intptr = &options->gss_deleg_creds; + goto parse_flag; + case oBatchMode: intptr = &options->batch_mode; goto parse_flag; @@ -818,6 +833,8 @@ options->challenge_response_authentication = -1; options->kerberos_authentication = -1; options->kerberos_tgt_passing = -1; + options->gss_authentication = -1; + options->gss_deleg_creds = -1; options->password_authentication = -1; options->kbd_interactive_authentication = -1; options->kbd_interactive_devices = NULL; @@ -894,6 +911,10 @@ options->kerberos_authentication = 1; if (options->kerberos_tgt_passing == -1) options->kerberos_tgt_passing = 1; + if (options->gss_authentication == -1) + options->gss_authentication = 1; + if (options->gss_deleg_creds == -1) + options->gss_deleg_creds = 0; if (options->password_authentication == -1) options->password_authentication = 1; if (options->kbd_interactive_authentication == -1) Index: readconf.h =================================================================== RCS file: /home/hack/jakob/mycvs/sshgss/readconf.h,v retrieving revision 1.1.1.2 retrieving revision 1.3 diff -u -r1.1.1.2 -r1.3 --- readconf.h 10 Aug 2003 14:06:50 -0000 1.1.1.2 +++ readconf.h 10 Aug 2003 14:25:01 -0000 1.3 @@ -43,6 +43,9 @@ /* Try S/Key or TIS, authentication. */ int kerberos_authentication; /* Try Kerberos authentication. */ int kerberos_tgt_passing; /* Try Kerberos TGT passing. */ + int afs_token_passing; /* Try AFS token passing. */ + int gss_authentication; /* Try GSS authentication */ + int gss_deleg_creds; /* Delegate GSS credentials */ int password_authentication; /* Try password * authentication. */ int kbd_interactive_authentication; /* Try keyboard-interactive auth. */ Index: servconf.c =================================================================== RCS file: /home/hack/jakob/mycvs/sshgss/servconf.c,v retrieving revision 1.1.1.2 retrieving revision 1.5 diff -u -r1.1.1.2 -r1.5 --- servconf.c 10 Aug 2003 14:06:52 -0000 1.1.1.2 +++ servconf.c 10 Aug 2003 14:25:01 -0000 1.5 @@ -69,6 +69,9 @@ options->kerberos_or_local_passwd = -1; options->kerberos_ticket_cleanup = -1; options->kerberos_tgt_passing = -1; + options->afs_token_passing = -1; + options->gss_authentication=-1; + options->gss_cleanup_creds = -1; options->password_authentication = -1; options->kbd_interactive_authentication = -1; options->challenge_response_authentication = -1; @@ -175,6 +178,12 @@ options->kerberos_ticket_cleanup = 1; if (options->kerberos_tgt_passing == -1) options->kerberos_tgt_passing = 0; + if (options->afs_token_passing == -1) + options->afs_token_passing = 0; + if (options->gss_authentication == -1) + options->gss_authentication = 0; + if (options->gss_cleanup_creds == -1) + options->gss_cleanup_creds = 1; if (options->password_authentication == -1) options->password_authentication = 1; if (options->kbd_interactive_authentication == -1) @@ -239,6 +248,7 @@ sBanner, sUseDNS, sHostbasedAuthentication, sHostbasedUsesNameFromPacketOnly, sClientAliveInterval, sClientAliveCountMax, sAuthorizedKeysFile, sAuthorizedKeysFile2, + sGssAuthentication, sGssCleanupCreds, sUsePrivilegeSeparation, sDeprecated, sUnsupported } ServerOpCodes; @@ -277,6 +287,13 @@ { "kerberostgtpassing", sUnsupported }, #endif { "afstokenpassing", sUnsupported }, +#ifdef GSSAPI + { "gssapiauthentication", sGssAuthentication }, + { "gssapicleanupcreds", sGssCleanupCreds }, +#else + { "gssapiauthentication", sUnsupported }, + { "gssapicleanupcreds", sUnsupported }, +#endif { "passwordauthentication", sPasswordAuthentication }, { "kbdinteractiveauthentication", sKbdInteractiveAuthentication }, { "challengeresponseauthentication", sChallengeResponseAuthentication }, @@ -591,6 +608,14 @@ case sKerberosTgtPassing: intptr = &options->kerberos_tgt_passing; + goto parse_flag; + + case sGssAuthentication: + intptr = &options->gss_authentication; + goto parse_flag; + + case sGssCleanupCreds: + intptr = &options->gss_cleanup_creds; goto parse_flag; case sPasswordAuthentication: Index: servconf.h =================================================================== RCS file: /home/hack/jakob/mycvs/sshgss/servconf.h,v retrieving revision 1.1.1.2 retrieving revision 1.4 diff -u -r1.1.1.2 -r1.4 --- servconf.h 10 Aug 2003 14:06:52 -0000 1.1.1.2 +++ servconf.h 10 Aug 2003 14:25:01 -0000 1.4 @@ -84,6 +84,9 @@ * file on logout. */ int kerberos_tgt_passing; /* If true, permit Kerberos TGT * passing. */ + int afs_token_passing; /* If true, permit AFS token passing. */ + int gss_authentication; /* If true, permit GSSAPI authentication */ + int gss_cleanup_creds; /* If true, destroy cred cache on logout */ int password_authentication; /* If true, permit password * authentication. */ int kbd_interactive_authentication; /* If true, permit */ Index: session.c =================================================================== RCS file: /home/hack/jakob/mycvs/sshgss/session.c,v retrieving revision 1.1.1.2 retrieving revision 1.4 diff -u -r1.1.1.2 -r1.4 --- session.c 10 Aug 2003 14:06:53 -0000 1.1.1.2 +++ session.c 10 Aug 2003 14:25:01 -0000 1.4 @@ -58,6 +58,10 @@ #include "session.h" #include "monitor_wrap.h" +#ifdef GSSAPI +#include "ssh-gss.h" +#endif + /* func */ Session *session_new(void); @@ -409,6 +413,12 @@ session_proctitle(s); +#ifdef GSSAPI + temporarily_use_uid(s->pw); + ssh_gssapi_storecreds(); + restore_uid(); +#endif + /* Fork the child. */ if ((pid = fork()) == 0) { fatal_remove_all_cleanups(); @@ -517,6 +527,12 @@ ptyfd = s->ptyfd; ttyfd = s->ttyfd; +#ifdef GSSAPI + temporarily_use_uid(s->pw); + ssh_gssapi_storecreds(); + restore_uid(); +#endif + /* Fork the child. */ if ((pid = fork()) == 0) { fatal_remove_all_cleanups(); @@ -703,7 +719,7 @@ * Sets the value of the given variable in the environment. If the variable * already exists, its value is overriden. */ -static void +void child_set_env(char ***envp, u_int *envsizep, const char *name, const char *value) { @@ -799,6 +815,13 @@ env = xmalloc(envsize * sizeof(char *)); env[0] = NULL; +#ifdef GSSAPI + /* Allow any GSSAPI methods that we've used to alter + * the childs environment as they see fit + */ + ssh_gssapi_do_child(&env, &envsize); +#endif + if (!options.use_login) { /* Set basic environment. */ child_set_env(&env, &envsize, "USER", pw->pw_name); @@ -1832,4 +1855,7 @@ do_authenticated2(Authctxt *authctxt) { server_loop2(authctxt); +#if defined(GSSAPI) + ssh_gssapi_cleanup_creds(NULL); +#endif } Index: session.h =================================================================== RCS file: /home/hack/jakob/mycvs/sshgss/session.h,v retrieving revision 1.1.1.1 retrieving revision 1.2 diff -u -r1.1.1.1 -r1.2 --- session.h 17 May 2003 03:34:18 -0000 1.1.1.1 +++ session.h 17 May 2003 03:43:28 -0000 1.2 @@ -68,4 +68,7 @@ Session *session_by_tty(char *); void session_close(Session *); void do_setusercontext(struct passwd *); +void child_set_env(char ***envp, u_int *envsizep, const char *name, + const char *value); + #endif Index: ssh-gss.h =================================================================== RCS file: ssh-gss.h diff -N ssh-gss.h --- /dev/null 1 Jan 1970 00:00:00 -0000 +++ ssh-gss.h 2 Jun 2003 18:23:49 -0000 1.8 @@ -0,0 +1,109 @@ +/* + * Copyright (c) 2001-2003 Simon Wilkinson. All rights reserved. + * + * Redistribution and use in source and binary forms, with or without + * modification, are permitted provided that the following conditions + * are met: + * 1. Redistributions of source code must retain the above copyright + * notice, this list of conditions and the following disclaimer. + * 2. Redistributions in binary form must reproduce the above copyright + * notice, this list of conditions and the following disclaimer in the + * documentation and/or other materials provided with the distribution. + * + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR `AS IS'' AND ANY EXPRESS OR + * IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES + * OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. + * IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, + * DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY + * THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + */ + +#ifndef _SSH_GSS_H +#define _SSH_GSS_H + +#ifdef GSSAPI + +#include "buffer.h" + +#include + +/* draft-ietf-secsh-gsskeyex-06 */ +#define SSH2_MSG_USERAUTH_GSSAPI_RESPONSE 60 +#define SSH2_MSG_USERAUTH_GSSAPI_TOKEN 61 +#define SSH2_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE 63 +#define SSH2_MSG_USERAUTH_GSSAPI_ERROR 64 +#define SSH2_MSG_USERAUTH_GSSAPI_ERRTOK 65 + +#define SSH_GSS_OIDTYPE 0x06 + +typedef struct { + char *filename; + char *envvar; + char *envval; + void *data; +} ssh_gssapi_ccache; + +typedef struct { + gss_buffer_desc displayname; + gss_buffer_desc exportedname; + gss_cred_id_t creds; + struct ssh_gssapi_mech_struct *mech; + ssh_gssapi_ccache store; +} ssh_gssapi_client; + +typedef struct ssh_gssapi_mech_struct { + char *enc_name; + char *name; + gss_OID_desc oid; + int (*dochild) (ssh_gssapi_client *); + int (*userok) (ssh_gssapi_client *, char *); + int (*localname) (ssh_gssapi_client *, char **); + void (*storecreds) (ssh_gssapi_client *); +} ssh_gssapi_mech; + +typedef struct { + OM_uint32 major; /* both */ + OM_uint32 minor; /* both */ + gss_ctx_id_t context; /* both */ + gss_name_t name; /* both */ + gss_OID oid; /* client */ + gss_cred_id_t creds; /* server */ + gss_name_t client; /* server */ + gss_cred_id_t client_creds; /* server */ +} Gssctxt; + +extern ssh_gssapi_mech *supported_mechs[]; + +int ssh_gssapi_check_oid(Gssctxt *ctx, void *data, size_t len); +void ssh_gssapi_set_oid_data(Gssctxt *ctx, void *data, size_t len); +void ssh_gssapi_set_oid(Gssctxt *ctx, gss_OID oid); +void ssh_gssapi_supported_oids(gss_OID_set *oidset); +ssh_gssapi_mech *ssh_gssapi_get_ctype(Gssctxt *ctxt); + +OM_uint32 ssh_gssapi_import_name(Gssctxt *ctx, const char *host); +OM_uint32 ssh_gssapi_acquire_cred(Gssctxt *ctx); +OM_uint32 ssh_gssapi_init_ctx(Gssctxt *ctx, int deleg_creds, + gss_buffer_desc *recv_tok, gss_buffer_desc *send_tok, OM_uint32 *flags); +OM_uint32 ssh_gssapi_accept_ctx(Gssctxt *ctx, + gss_buffer_desc *recv_tok, gss_buffer_desc *send_tok, OM_uint32 *flags); +OM_uint32 ssh_gssapi_getclient(Gssctxt *ctx, ssh_gssapi_client *); +void ssh_gssapi_error(Gssctxt *ctx); +char *ssh_gssapi_last_error(Gssctxt *ctxt, OM_uint32 *maj, OM_uint32 *min); +void ssh_gssapi_build_ctx(Gssctxt **ctx); +void ssh_gssapi_delete_ctx(Gssctxt **ctx); +OM_uint32 ssh_gssapi_server_ctx(Gssctxt **ctx, gss_OID oid); + +/* In the server */ +int ssh_gssapi_userok(char *name); + +void ssh_gssapi_do_child(char ***envp, u_int *envsizep); +void ssh_gssapi_cleanup_creds(void *ignored); +void ssh_gssapi_storecreds(void); + +#endif /* GSSAPI */ + +#endif /* _SSH_GSS_H */ Index: ssh_config.5 =================================================================== RCS file: /home/hack/jakob/mycvs/sshgss/ssh_config.5,v retrieving revision 1.1.1.2 retrieving revision 1.3 diff -u -r1.1.1.2 -r1.3 --- ssh_config.5 10 Aug 2003 14:06:57 -0000 1.1.1.2 +++ ssh_config.5 10 Aug 2003 14:25:01 -0000 1.3 @@ -331,6 +331,18 @@ Specifies a file to use for the global host key database instead of .Pa /etc/ssh/ssh_known_hosts . +.It Cm GSSAPIAuthentication +Specifies whether authentication based on GSSAPI may be used, either using +the result of a successful key exchange, or using GSSAPI user +authentication. +The default is +.Dq yes . +Note that this option applies to protocol version 2 only. +.It Cm GSSAPIDelegateCredentials +Forward (delegate) credentials to the server. +The default is +.Dq no . +Note that this option applies to protocol version 2 only. .It Cm HostbasedAuthentication Specifies whether to try rhosts based authentication with public key authentication. Index: sshconnect2.c =================================================================== RCS file: /home/hack/jakob/mycvs/sshgss/sshconnect2.c,v retrieving revision 1.1.1.2 retrieving revision 1.10 diff -u -r1.1.1.2 -r1.10 --- sshconnect2.c 10 Aug 2003 14:06:59 -0000 1.1.1.2 +++ sshconnect2.c 10 Aug 2003 14:25:01 -0000 1.10 @@ -52,6 +52,10 @@ #include "msg.h" #include "pathnames.h" +#ifdef GSSAPI +#include "ssh-gss.h" +#endif + /* import */ extern char *client_version_string; extern char *server_version_string; @@ -173,6 +177,8 @@ Sensitive *sensitive; /* kbd-interactive */ int info_req_seen; + /* generic */ + void *methoddata; }; struct Authmethod { char *name; /* string to compare against server's list */ @@ -196,6 +202,15 @@ int userauth_hostbased(Authctxt *); int userauth_kerberos(Authctxt *); +#ifdef GSSAPI +int userauth_gssapi(Authctxt *authctxt); +void input_gssapi_response(int type, u_int32_t, void *); +void input_gssapi_token(int type, u_int32_t, void *); +void input_gssapi_hash(int type, u_int32_t, void *); +void input_gssapi_error(int, u_int32_t, void *); +void input_gssapi_errtok(int, u_int32_t, void *); +#endif + void userauth(Authctxt *, char *); static int sign_and_send_pubkey(Authctxt *, Identity *); @@ -208,6 +223,12 @@ static char *authmethods_get(void); Authmethod authmethods[] = { +#ifdef GSSAPI + {"gssapi", + userauth_gssapi, + &options.gss_authentication, + NULL}, +#endif {"hostbased", userauth_hostbased, &options.hostbased_authentication, @@ -278,6 +299,7 @@ authctxt.success = 0; authctxt.method = authmethod_lookup("none"); authctxt.authlist = NULL; + authctxt.methoddata = NULL; authctxt.sensitive = sensitive; authctxt.info_req_seen = 0; if (authctxt.method == NULL) @@ -301,6 +323,10 @@ void userauth(Authctxt *authctxt, char *authlist) { + if (authctxt->methoddata) { + xfree(authctxt->methoddata); + authctxt->methoddata = NULL; + } if (authlist == NULL) { authlist = authctxt->authlist; } else { @@ -356,6 +382,8 @@ fatal("input_userauth_success: no authentication context"); if (authctxt->authlist) xfree(authctxt->authlist); + if (authctxt->methoddata) + xfree(authctxt->methoddata); authctxt->success = 1; /* break out */ } @@ -444,6 +472,229 @@ userauth(authctxt, NULL); } +#ifdef GSSAPI +int +userauth_gssapi(Authctxt *authctxt) +{ + Gssctxt *gssctxt = NULL; + static gss_OID_set supported = NULL; + static int mech = 0; + OM_uint32 min; + int ok = 0; + + /* Try one GSSAPI method at a time, rather than sending them all at + * once. */ + + if (supported == NULL) + gss_indicate_mechs(&min, &supported); + + /* Check to see if the mechanism is usable before we offer it */ + while (mechcount && !ok) { + if (gssctxt) + ssh_gssapi_delete_ctx(&gssctxt); + ssh_gssapi_build_ctx(&gssctxt); + ssh_gssapi_set_oid(gssctxt, &supported->elements[mech]); + + /* My DER encoding requires length<128 */ + if (supported->elements[mech].length < 128 && + !GSS_ERROR(ssh_gssapi_import_name(gssctxt, + authctxt->host))) { + ok = 1; /* Mechanism works */ + } else { + mech++; + } + } + + if (!ok) return 0; + + authctxt->methoddata=(void *)gssctxt; + + packet_start(SSH2_MSG_USERAUTH_REQUEST); + packet_put_cstring(authctxt->server_user); + packet_put_cstring(authctxt->service); + packet_put_cstring(authctxt->method->name); + + packet_put_int(1); + + /* Some servers encode the OID incorrectly (as we used to) */ + if (datafellows & SSH_BUG_GSSAPI_BER) { + packet_put_string(supported->elements[mech].elements, + supported->elements[mech].length); + } else { + packet_put_int((supported->elements[mech].length)+2); + packet_put_char(SSH_GSS_OIDTYPE); + packet_put_char(supported->elements[mech].length); + packet_put_raw(supported->elements[mech].elements, + supported->elements[mech].length); + } + + packet_send(); + + dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_RESPONSE, &input_gssapi_response); + dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_TOKEN, &input_gssapi_token); + dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_ERROR, &input_gssapi_error); + dispatch_set(SSH2_MSG_USERAUTH_GSSAPI_ERRTOK, &input_gssapi_errtok); + + mech++; /* Move along to next candidate */ + + return 1; +} + +void +input_gssapi_response(int type, u_int32_t plen, void *ctxt) +{ + Authctxt *authctxt = ctxt; + Gssctxt *gssctxt; + OM_uint32 status, ms; + int oidlen; + char *oidv; + gss_buffer_desc send_tok = GSS_C_EMPTY_BUFFER; + + if (authctxt == NULL) + fatal("input_gssapi_response: no authentication context"); + gssctxt = authctxt->methoddata; + + /* Setup our OID */ + oidv = packet_get_string(&oidlen); + + if (datafellows & SSH_BUG_GSSAPI_BER) { + if (!ssh_gssapi_check_oid(gssctxt, oidv, oidlen)) + fatal("Server returned different OID than expected"); + } else { + if(oidv[0] != SSH_GSS_OIDTYPE || oidv[1] != oidlen-2) { + debug("Badly encoded mechanism OID received"); + userauth(authctxt, NULL); + xfree(oidv); + return; + } + if (!ssh_gssapi_check_oid(gssctxt, oidv+2, oidlen-2)) + fatal("Server returned different OID than expected"); + } + + packet_check_eom(); + + xfree(oidv); + + status = ssh_gssapi_init_ctx(gssctxt, options.gss_deleg_creds, + GSS_C_NO_BUFFER, &send_tok, NULL); + if (GSS_ERROR(status)) { + if (send_tok.length > 0) { + packet_start(SSH2_MSG_USERAUTH_GSSAPI_ERRTOK); + packet_put_string(send_tok.value, send_tok.length); + packet_send(); + gss_release_buffer(&ms, &send_tok); + } + /* Start again with next method on list */ + debug("Trying to start again"); + userauth(authctxt, NULL); + return; + } + + /* We must have data to send */ + packet_start(SSH2_MSG_USERAUTH_GSSAPI_TOKEN); + packet_put_string(send_tok.value, send_tok.length); + packet_send(); + gss_release_buffer(&ms, &send_tok); +} + +void +input_gssapi_token(int type, u_int32_t plen, void *ctxt) +{ + Authctxt *authctxt = ctxt; + Gssctxt *gssctxt; + gss_buffer_desc send_tok = GSS_C_EMPTY_BUFFER; + gss_buffer_desc recv_tok; + OM_uint32 status, ms; + u_int slen; + + if (authctxt == NULL) + fatal("input_gssapi_response: no authentication context"); + gssctxt = authctxt->methoddata; + + recv_tok.value = packet_get_string(&slen); + recv_tok.length = slen; /* safe typecast */ + + packet_check_eom(); + + status=ssh_gssapi_init_ctx(gssctxt, options.gss_deleg_creds, + &recv_tok, &send_tok, NULL); + + xfree(recv_tok.value); + + if (GSS_ERROR(status)) { + if (send_tok.length > 0) { + packet_start(SSH2_MSG_USERAUTH_GSSAPI_ERRTOK); + packet_put_string(send_tok.value, send_tok.length); + packet_send(); + gss_release_buffer(&ms, &send_tok); + } + /* Start again with the next method in the list */ + userauth(authctxt, NULL); + return; + } + + if (send_tok.length > 0) { + packet_start(SSH2_MSG_USERAUTH_GSSAPI_TOKEN); + packet_put_string(send_tok.value, send_tok.length); + packet_send(); + gss_release_buffer(&ms, &send_tok); + } + + if (status == GSS_S_COMPLETE) { + /* If that succeeded, send a exchange complete message */ + packet_start(SSH2_MSG_USERAUTH_GSSAPI_EXCHANGE_COMPLETE); + packet_send(); + } +} + +void +input_gssapi_errtok(int type, u_int32_t plen, void *ctxt) +{ + Authctxt *authctxt = ctxt; + Gssctxt *gssctxt; + gss_buffer_desc send_tok = GSS_C_EMPTY_BUFFER; + gss_buffer_desc recv_tok; + OM_uint32 status, ms; + + if (authctxt == NULL) + fatal("input_gssapi_response: no authentication context"); + gssctxt = authctxt->methoddata; + + recv_tok.value = packet_get_string(&recv_tok.length); + + packet_check_eom(); + + /* Stick it into GSSAPI and see what it says */ + status = ssh_gssapi_init_ctx(gssctxt, options.gss_deleg_creds, + &recv_tok, &send_tok, NULL); + + xfree(recv_tok.value); + gss_release_buffer(&ms, &send_tok); + + /* Server will be returning a failed packet after this one */ +} + +void +input_gssapi_error(int type, u_int32_t plen, void *ctxt) +{ + OM_uint32 maj, min; + char *msg; + char *lang; + + maj=packet_get_int(); + min=packet_get_int(); + msg=packet_get_string(NULL); + lang=packet_get_string(NULL); + + packet_check_eom(); + + fprintf(stderr, "Server GSSAPI Error:\n%s\n", msg); + xfree(msg); + xfree(lang); +} + +#endif /* GSSAPI */ + int userauth_none(Authctxt *authctxt) { @@ -454,6 +705,7 @@ packet_put_cstring(authctxt->method->name); packet_send(); return 1; + } int Index: sshd_config =================================================================== RCS file: /home/hack/jakob/mycvs/sshgss/sshd_config,v retrieving revision 1.1.1.2 retrieving revision 1.5 diff -u -r1.1.1.2 -r1.5 --- sshd_config 10 Aug 2003 14:07:00 -0000 1.1.1.2 +++ sshd_config 10 Aug 2003 14:40:31 -0000 1.5 @@ -63,6 +63,10 @@ #KerberosTicketCleanup yes #KerberosTgtPassing no +# GSSAPI options +#GSSAPIAuthentication no +#GSSAPICleanupCreds yes + #AllowTcpForwarding yes #GatewayPorts no #X11Forwarding no Index: sshd_config.5 =================================================================== RCS file: /home/hack/jakob/mycvs/sshgss/sshd_config.5,v retrieving revision 1.1.1.2 retrieving revision 1.7 diff -u -r1.1.1.2 -r1.7 --- sshd_config.5 10 Aug 2003 14:07:00 -0000 1.1.1.2 +++ sshd_config.5 10 Aug 2003 14:25:01 -0000 1.7 @@ -225,6 +225,19 @@ .Dq no . The default is .Dq no . +.It Cm GSSAPIAuthentication +Specifies whether authentication based on GSSAPI may be used, either using +the result of a successful key exchange, or using GSSAPI user +authentication. +The default is +.Dq no . +Note that this option applies to protocol version 2 only. +.It Cm GSSAPICleanupCredentials +Specifies whether to automatically destroy the user's credentials cache +on logout. +The default is +.Dq yes . +Note that this option applies to protocol version 2 only. .It Cm HostbasedAuthentication Specifies whether rhosts or /etc/hosts.equiv authentication together with successful public key client host authentication is allowed Index: lib/Makefile =================================================================== RCS file: /home/hack/jakob/mycvs/sshgss/lib/Makefile,v retrieving revision 1.1.1.2 retrieving revision 1.3 diff -u -r1.1.1.2 -r1.3 --- lib/Makefile 10 Aug 2003 14:07:00 -0000 1.1.1.2 +++ lib/Makefile 10 Aug 2003 14:25:02 -0000 1.3 @@ -23,6 +23,9 @@ .if (${KERBEROS5:L} == "yes") CFLAGS+= -DKRB5 -I${DESTDIR}/usr/include/kerberosV + +SRCS+= gss-genr.c +CFLAGS+= -DGSSAPI .endif # KERBEROS5 .include Index: ssh/Makefile =================================================================== RCS file: /home/hack/jakob/mycvs/sshgss/ssh/Makefile,v retrieving revision 1.1.1.2 retrieving revision 1.3 diff -u -r1.1.1.2 -r1.3 --- ssh/Makefile 10 Aug 2003 14:07:00 -0000 1.1.1.2 +++ ssh/Makefile 10 Aug 2003 14:25:02 -0000 1.3 @@ -19,8 +19,13 @@ .if (${KERBEROS5:L} == "yes") CFLAGS+= -DKRB5 -I${DESTDIR}/usr/include/kerberosV -DPADD+= ${LIBKRB5} ${LIBASN1} -LDADD+= -lkrb5 -lasn1 + +LDADD+= -lkrb5 +DPADD+= ${LIBKRB5} + +CFLAGS+= -DGSSAPI +LDADD+= -lgssapi +DPADD+= ${LIBGSSAPI} .endif # KERBEROS5 .include Index: sshd/Makefile =================================================================== RCS file: /home/hack/jakob/mycvs/sshgss/sshd/Makefile,v retrieving revision 1.1.1.2 retrieving revision 1.3 diff -u -r1.1.1.2 -r1.3 --- sshd/Makefile 10 Aug 2003 14:07:01 -0000 1.1.1.2 +++ sshd/Makefile 10 Aug 2003 14:25:02 -0000 1.3 @@ -23,8 +23,14 @@ .if (${KERBEROS5:L} == "yes") CFLAGS+=-DKRB5 -I${DESTDIR}/usr/include/kerberosV SRCS+= auth-krb5.c auth2-krb5.c -DPADD+= ${LIBKRB5} ${LIBASN1} -LDADD+= -lkrb5 -lasn1 + +LDADD+= -lkrb5 +DPADD+= ${LIBKRB5} + +SRCS+= auth2-gss.c gss-serv.c gss-serv-krb5.c +CFLAGS+= -DGSSAPI +LDADD+= -lgssapi +DPADD+= ${LIBGSSAPI} .endif # KERBEROS5 .include From fcusack at fcusack.com Mon Aug 11 15:55:20 2003 From: fcusack at fcusack.com (Frank Cusack) Date: Sun, 10 Aug 2003 22:55:20 -0700 Subject: updated gssapi diff In-Reply-To: ; from jakob@openbsd.org on Sun, Aug 10, 2003 at 04:43:52PM +0200 References: Message-ID: <20030810225520.A11520@google.com> On Sun, Aug 10, 2003 at 04:43:52PM +0200, Jakob Schlyter wrote: > please comment. No gsskeyex? blah! No per-session ccache option? blah. I can't say for sure whether or not gss_indicate_mechs() needs to be in the monitor, but I will note that you've changed this from Simon's implementation. Seems OK to me. session.c needs to test options.gss_cleanup_creds before unconditionally cleaning up, here: --- session.c 10 Aug 2003 14:06:53 -0000 1.1.1.2 +++ session.c 10 Aug 2003 14:25:01 -0000 1.4 @@ -1832,4 +1855,7 @@ do_authenticated2(Authctxt *authctxt) { server_loop2(authctxt); +#if defined(GSSAPI) + ssh_gssapi_cleanup_creds(NULL); +#endif } should be: if (options.gss_cleanup_creds) ssh_gssapi_cleanup_creds(NULL); It needs docs as well: 8<--- --- openssh.orig/sshd_config.5 2003-06-08 17:20:47.000000000 -0700 +++ openssh/sshd_config.5 2003-06-08 17:19:39.000000000 -0700 @@ -273,7 +273,11 @@ The default is .Dq yes . Note that this option applies to protocol version 2 only. - +.It Cm GSSAPICleanUpCreds +Specifies whether ssh with gssapi will delete the ccache when the session exits, fatal or otherwise. +The default is +.Dq yes . +Note that this option applies to protocol version 2 only. .It Cm IgnoreRhosts Specifies that .Pa .rhosts 8<--- sshconnect2.c:input_gssapi_error() is too noisy. 8<--- --- openssh.orig/sshconnect2.c 2003-07-09 20:57:32.000000000 -0700 +++ openssh/sshconnect2.c 2003-07-09 21:02:50.000000000 -0700 @@ -723,7 +723,7 @@ input_gssapi_error(int type, u_int32_t p packet_check_eom(); - fprintf(stderr, "Server GSSAPI Error:\n%s\n", msg); + debug("Server GSSAPI Error:\n%s\n", msg); xfree(msg); xfree(lang); } 8<--- /fc From markus at openbsd.org Mon Aug 11 17:48:23 2003 From: markus at openbsd.org (Markus Friedl) Date: Mon, 11 Aug 2003 09:48:23 +0200 Subject: updated gssapi diff In-Reply-To: <20030810225520.A11520@google.com> References: <20030810225520.A11520@google.com> Message-ID: <20030811074823.GC16987@folly> On Sun, Aug 10, 2003 at 10:55:20PM -0700, Frank Cusack wrote: > On Sun, Aug 10, 2003 at 04:43:52PM +0200, Jakob Schlyter wrote: > > please comment. > > No gsskeyex? blah! you're going to simplify the code? > No per-session ccache option? blah. options are bad. From markus at openbsd.org Mon Aug 11 17:50:50 2003 From: markus at openbsd.org (Markus Friedl) Date: Mon, 11 Aug 2003 09:50:50 +0200 Subject: updated gssapi diff In-Reply-To: References: Message-ID: <20030811075050.GD16987@folly> On Sun, Aug 10, 2003 at 04:43:52PM +0200, Jakob Schlyter wrote: > this is the proposed gssapi diff against OpenSSH-current (non-portable). > > note: if this goes in, the old krb5 auth (ssh.com compatible) will be > removed. > > please comment. how can i disallow gssapi based authentication if the underlying kerberos uses DES for example? -m From fcusack at fcusack.com Mon Aug 11 19:54:29 2003 From: fcusack at fcusack.com (Frank Cusack) Date: Mon, 11 Aug 2003 02:54:29 -0700 Subject: updated gssapi diff In-Reply-To: <20030811075050.GD16987@folly>; from markus@openbsd.org on Mon, Aug 11, 2003 at 09:50:50AM +0200 References: <20030811075050.GD16987@folly> Message-ID: <20030811025429.A12670@google.com> On Mon, Aug 11, 2003 at 09:50:50AM +0200, Markus Friedl wrote: > On Sun, Aug 10, 2003 at 04:43:52PM +0200, Jakob Schlyter wrote: > > this is the proposed gssapi diff against OpenSSH-current (non-portable). > > > > note: if this goes in, the old krb5 auth (ssh.com compatible) will be > > removed. > > > > please comment. > > how can i disallow gssapi based authentication if the underlying > kerberos uses DES for example? You could prevent the underlying kerberos from using DES. If you don't have a DES host/HOSTNAME key (or ssh/HOSTNAME key) you prevent the use of DES. Doing it within gssapi is also possible, but more complex. /fc From vinschen at redhat.com Mon Aug 11 19:55:28 2003 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 11 Aug 2003 11:55:28 +0200 Subject: [PATCH] Fix minor breakage on Cygwin: auth-passwd.c and session.c In-Reply-To: References: <3F2DBA8B.109D7A1F@zip.com.au> Message-ID: <20030811095528.GA11080@cygbert.vinschen.de> Sorry for the late response, I was on vacation. On Mon, Aug 04, 2003 at 12:32:36AM -0500, Ben Lindstrom wrote: > On Mon, 4 Aug 2003, Darren Tucker wrote: > > Ben Lindstrom wrote: > > > [..] > > > +# ifdef HAVE_CYGWIN > > > +# undef ERROR > > > +# include > > > +# include > > > +# define is_winnt (GetVersion() < 0x80000000) > > > +# endif > > > > > > There is enough of this junk laying around in different files it really > > > should be put in an openbsd-compat/port-cygwin.h =) Well, this isn't more "junk" than the extra stuff necessary for any other OS. > However, yes. The code should go to bsd-cygwin_util.h unless there is > some overriding reason not to... Corinna is there a reason we shouldn't > make this change? No. But why is it still in xcrypt.c? It's in xcrypt.c just because it doesn't include openbsd-compat.h. Is there any good reason not to do that? Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From vinschen at redhat.com Mon Aug 11 20:11:28 2003 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 11 Aug 2003 12:11:28 +0200 Subject: [PATCH] Fix minor breakage on Cygwin: auth-passwd.c and session.c In-Reply-To: <3F2F8584.401C1213@zip.com.au> References: <3F2F8584.401C1213@zip.com.au> Message-ID: <20030811101128.GB11080@cygbert.vinschen.de> On Tue, Aug 05, 2003 at 08:23:00PM +1000, Darren Tucker wrote: > Ben Lindstrom wrote: > > However, yes. The code should go to bsd-cygwin_util.h unless there is > > some overriding reason not to... Corinna is there a reason we shouldn't > > make this change? > > Here's the current proposed patch, which works for me. > > No one has commented on the session_break_req() change... That's not the right way to do it, AFAICS. Wouldn't it be better to use the tcflow() system call as described in SUSv3 and which should be available on all systems? Index: session.c =================================================================== RCS file: /cvs/openssh_cvs/session.c,v retrieving revision 1.244 diff -p -u -r1.244 session.c --- session.c 7 Aug 2003 06:28:16 -0000 1.244 +++ session.c 11 Aug 2003 10:07:39 -0000 @@ -1696,20 +1696,16 @@ session_break_req(Session *s) break_length = packet_get_int(); packet_check_eom(); -#if defined(TIOCSBRK) && defined(TIOCCBRK) if (s->ttyfd == -1) return 0; /* we will sleep from 500ms to 3000ms */ break_length = MIN(break_length, 3000); break_length = MAX(break_length, 500); - ioctl(s->ttyfd, TIOCSBRK, NULL); + tcflow(s->ttyfd,TCOOFF); /* should we care about EINTR? */ usleep(break_length * 1000); - ioctl(s->ttyfd, TIOCCBRK, NULL); + tcflow(s->ttyfd,TCOON); return 1; -#else - return 0; -#endif } static int Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From sxw at inf.ed.ac.uk Mon Aug 11 20:36:53 2003 From: sxw at inf.ed.ac.uk (sxw at inf.ed.ac.uk) Date: Mon, 11 Aug 2003 11:36:53 +0100 (BST) Subject: updated gssapi diff In-Reply-To: <20030810225520.A11520@google.com> Message-ID: On Sun, 10 Aug 2003, Frank Cusack wrote: > On Sun, Aug 10, 2003 at 04:43:52PM +0200, Jakob Schlyter wrote: > No gsskeyex? blah! > No per-session ccache option? blah. With the Heimdal codebase, krb5_cc_gen_new() should generate a session specific ccache, the difference here is that you're not being given an option not to. > I can't say for sure whether or not gss_indicate_mechs() needs > to be in the monitor, but I will note that you've changed this from > Simon's implementation. Seems OK to me. I changed this. indicate_mechs only needs to be in the monitor if you're linking against a GSSAPI library that uses mechglue (or a similar way of handling multiple GSSAPI mechanisms). It isn't required for vanilla MIT Kerberos, or for Heimdal. Removing it reduces the amount of priviledged code. > session.c needs to test options.gss_cleanup_creds before unconditionally > cleaning up, here: Indeed. I take it this call is needed as well as the call that comes through the fatal_add_cleanup() handler. Cheers, Simon From dtucker at zip.com.au Mon Aug 11 21:25:44 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 11 Aug 2003 21:25:44 +1000 Subject: [PATCH] Fix minor breakage on Cygwin: auth-passwd.c andsession.c References: <3F2DBA8B.109D7A1F@zip.com.au> <20030811095528.GA11080@cygbert.vinschen.de> Message-ID: <3F377D38.F4BD40@zip.com.au> Corinna Vinschen wrote: > On Mon, Aug 04, 2003 at 12:32:36AM -0500, Ben Lindstrom wrote: > > > > There is enough of this junk laying around in different files it really > > > > should be put in an openbsd-compat/port-cygwin.h =) > > Well, this isn't more "junk" than the extra stuff necessary for any > other OS. Er, I think the smiley at the end implied that "junk" meant "unnecessary platform specific code". As auth-passwd.c must be periodically synced with the OpenBSD tree, keeping platform specific code out of it where possible makes that easier. Compare auth-passwd.c from 3.6.1p2, OpenBSD and -current (after Ben's cleanup). > > However, yes. The code should go to bsd-cygwin_util.h unless there is > > some overriding reason not to... Corinna is there a reason we shouldn't > > make this change? > > No. But why is it still in xcrypt.c? It's in xcrypt.c just because it > doesn't include openbsd-compat.h. Is there any good reason not to do that? It's included indirectly: xcrypt.c -> includes.h -> openbsd-compat.h -> bsd-cygwin_util.h Now the code in question is in bsd-cygwin_util.h it doesn't need to be in xcrypt.c any more either. I'll take it out. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Mon Aug 11 21:52:33 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 11 Aug 2003 21:52:33 +1000 Subject: [PATCH] Fix minor breakage on Cygwin: auth-passwd.c andsession.c References: <3F2F8584.401C1213@zip.com.au> <20030811101128.GB11080@cygbert.vinschen.de> Message-ID: <3F378381.7F34CE20@zip.com.au> Corinna Vinschen wrote: > On Tue, Aug 05, 2003 at 08:23:00PM +1000, Darren Tucker wrote: > > No one has commented on the session_break_req() change... > > That's not the right way to do it, AFAICS. Wouldn't it be better to > use the tcflow() system call as described in SUSv3 and which should be > available on all systems? You mean tcsendbreak? Maybe, although implementations don't seem to provide much granualarity for the length of the break (OpenBSD uses a hard-coded 0.25 to 0.5 sec, Linux uses 0.25 - 0.5 sec blocks, and it's not clear from the man page what Solaris does). Does the duration of the break matter that much? The code already truncates it to 0.5 to 3 sec. -- 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 vinschen at redhat.com Mon Aug 11 22:44:57 2003 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 11 Aug 2003 14:44:57 +0200 Subject: [PATCH] Fix minor breakage on Cygwin: auth-passwd.c and session.c In-Reply-To: <20030811101128.GB11080@cygbert.vinschen.de> References: <3F2F8584.401C1213@zip.com.au> <20030811101128.GB11080@cygbert.vinschen.de> Message-ID: <20030811124457.GD24303@cygbert.vinschen.de> > On Mon, Aug 11, 2003 at 11:52:00PM +1000, Darren Tucker wrote: > Corinna Vinschen wrote: > > On Tue, Aug 05, 2003 at 08:23:00PM +1000, Darren Tucker wrote: > > > No one has commented on the session_break_req() change... > > > > That's not the right way to do it, AFAICS. Wouldn't it be better to > > use the tcflow() system call as described in SUSv3 and which should be > > available on all systems? > > You mean tcsendbreak? No, I meant tcflow(), but I'm not sure if it shoudn't be TCIOFF/TCION instead of TCOOFF/TCOON. But I guess a call to tcsendbreak() should be ok, too. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From dtucker at zip.com.au Mon Aug 11 23:17:16 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 11 Aug 2003 23:17:16 +1000 Subject: [PATCH] Fix minor breakage on Cygwin: auth-passwd.c andsession.c References: <3F2F8584.401C1213@zip.com.au> <20030811101128.GB11080@cygbert.vinschen.de> <20030811124457.GD24303@cygbert.vinschen.de> Message-ID: <3F37975C.B4DA0784@zip.com.au> Corinna Vinschen wrote: > > On Mon, Aug 11, 2003 at 11:52:00PM +1000, Darren Tucker wrote: > > You mean tcsendbreak? > > No, I meant tcflow(), but I'm not sure if it shoudn't be TCIOFF/TCION > instead of TCOOFF/TCOON. Either way, won't that just stop sending data (or send an XOFF/XON) rather than than a real break (ie continuous +12V)? > But I guess a call to tcsendbreak() should be ok, too. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From vinschen at redhat.com Tue Aug 12 00:55:17 2003 From: vinschen at redhat.com (Corinna Vinschen) Date: Mon, 11 Aug 2003 16:55:17 +0200 Subject: [PATCH] Fix minor breakage on Cygwin: auth-passwd.c andsession.c In-Reply-To: <3F37975C.B4DA0784@zip.com.au> References: <3F2F8584.401C1213@zip.com.au> <20030811101128.GB11080@cygbert.vinschen.de> <20030811124457.GD24303@cygbert.vinschen.de> <3F37975C.B4DA0784@zip.com.au> Message-ID: <20030811145517.GE24303@cygbert.vinschen.de> On Mon, Aug 11, 2003 at 11:17:16PM +1000, Darren Tucker wrote: > Corinna Vinschen wrote: > > > On Mon, Aug 11, 2003 at 11:52:00PM +1000, Darren Tucker wrote: > > > You mean tcsendbreak? > > > > No, I meant tcflow(), but I'm not sure if it shoudn't be TCIOFF/TCION > > instead of TCOOFF/TCOON. > > Either way, won't that just stop sending data (or send an XOFF/XON) rather > than than a real break (ie continuous +12V)? I'm not sure what you mean. tcsendbreak() might send data as well (from SUSv3): "If the terminal is using asynchronous serial data transmission, tcsendbreak() shall cause transmission of a continuous stream of zero-valued bits for a specific duration." so it's not always a break in the sense of not sending data at all. Even on synchronous IO: "If the terminal is not using asynchronous serial data transmission, it is implementation-defined whether tcsendbreak() sends data to generate a break condition or returns without taking any action." Perhaps I don't sufficiently understand serial IO? Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From gert at greenie.muc.de Tue Aug 12 03:04:05 2003 From: gert at greenie.muc.de (Gert Doering) Date: Mon, 11 Aug 2003 19:04:05 +0200 Subject: [PATCH] Fix minor breakage on Cygwin: auth-passwd.c andsession.c In-Reply-To: <20030811145517.GE24303@cygbert.vinschen.de>; from vinschen@redhat.com on Mon, Aug 11, 2003 at 04:55:17PM +0200 References: <3F2F8584.401C1213@zip.com.au> <20030811101128.GB11080@cygbert.vinschen.de> <20030811124457.GD24303@cygbert.vinschen.de> <3F37975C.B4DA0784@zip.com.au> <20030811145517.GE24303@cygbert.vinschen.de> Message-ID: <20030811190404.I20907@greenie.muc.de> Hi, On Mon, Aug 11, 2003 at 04:55:17PM +0200, Corinna Vinschen wrote: > > Either way, won't that just stop sending data (or send an XOFF/XON) rather > > than than a real break (ie continuous +12V)? > > I'm not sure what you mean. tcsendbreak() might send data as well (from > SUSv3): > > "If the terminal is using asynchronous serial data transmission, > tcsendbreak() shall cause transmission of a continuous stream of > zero-valued bits for a specific duration." > > so it's not always a break in the sense of not sending data at all. Well, it's not a "break" but a "BREAK" signal. The thing about async serial data is that there is a start bit, a number of data bits (usually 8, but 5-7 are also possible), maybe a parity bit, and 1 or 2 stop bits. Either the start or the stop bit has to be "1", to give the async receiver a chance to synchronize. (I think the idle level on the serial port is logical "1", the start bit is "0", and the stop bit is "1" again - which transfers to "-12V", "+12V" and "-12V" again). A BREAK signal is "sending more than 10 0-bits in sequence". This is a line code violation (normally that would be the time for a stop bit) so the receiver can detect "this is a special signal and it is NOT any of the characters encodeable by the data bits in use". So the minimum time for a BREAK signal (on a serial port) is determined by the actual port speed... a BREAK at 38400 can be much shorter than at 2400 bps :-) - but 0.3 seconds is a value that's "long enough" for just about anything (even for 50 bps). > Even > on synchronous IO: > > "If the terminal is not using asynchronous serial data transmission, > it is implementation-defined whether tcsendbreak() sends data to > generate a break condition or returns without taking any action." Synch serial ports don't have a clear concept of a BREAK - one could transmit an AIS signal or some other error signal, but BREAK is something very much asynchronous. > Perhaps I don't sufficiently understand serial IO? Be happy that you don't need to know all this cruft :-) gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From fcusack at fcusack.com Tue Aug 12 03:14:36 2003 From: fcusack at fcusack.com (Frank Cusack) Date: Mon, 11 Aug 2003 10:14:36 -0700 Subject: updated gssapi diff In-Reply-To: ; from jakob@openbsd.org on Sun, Aug 10, 2003 at 04:43:52PM +0200 References: Message-ID: <20030811101436.A13224@google.com> I forgot, one minor nit. How did the afs_token_passing bits sneak in? They are tiny, but really that should be it's own commit. /fc From jakob at openbsd.org Tue Aug 12 03:29:27 2003 From: jakob at openbsd.org (Jakob Schlyter) Date: Mon, 11 Aug 2003 19:29:27 +0200 (CEST) Subject: updated gssapi diff In-Reply-To: <20030811101436.A13224@google.com> References: <20030811101436.A13224@google.com> Message-ID: On Mon, 11 Aug 2003, Frank Cusack wrote: > I forgot, one minor nit. How did the afs_token_passing bits sneak in? > They are tiny, but really that should be it's own commit. my bad, they have been removed and came back due to a cvs import in my repo. I will fix. jakob From alfred.hovdestad at usask.ca Tue Aug 12 04:28:26 2003 From: alfred.hovdestad at usask.ca (Alfred Hovdestad) Date: Mon, 11 Aug 2003 12:28:26 -0600 Subject: ssh_exchange_identification: Connection closed by remote host Message-ID: <3F37E04A.7050004@usask.ca> Earlier, it was said: chkbrian wrote: >> I encountered the following problem while I typing "ssh -v >>" >>[snip] >> ssh_exchange_identification: Connection closed by remote host >You should specify your platform and OpenSSH version, but this is > almost certainly due to tcpwrappers configuration. > >Add the following line to hosts.allow: >sshd: ALL > >It may be in /etc or /usr/local/etc. > >Alternatively you could rebuild sshd without "--with-tcp-wrappers". I think I am experiencing the same problem. I found the following error in my logs: Cannot release PAM authentication I found a report from October 2002 with a similar problem. The solution there was to re-create the user accounts. I tried adding an account to my server and I can ssh to the new account, but not to my existing account. I am running RedHat 9.0 with openssh 3.5. I have tried connecting from a RedHat 8.0 box running openshh 3.4 and a tru64 box also with openssh 3.4, with the same results: I can login to the new account, but not to my existing account. The problem is not with tcp wrappers, as I can login to one account, but not another. I have tried deleting my ssh keys, my host keys, and rebooting my system, none of which has made any difference. Is there anything else I can check? I can send any log information that you need. Alfred Hovdestad System Administrator University of Saskatchewan From deengert at anl.gov Tue Aug 12 07:25:19 2003 From: deengert at anl.gov (Douglas E. Engert) Date: Mon, 11 Aug 2003 16:25:19 -0500 Subject: updated gssapi diff References: Message-ID: <3F3809BF.4081648B@anl.gov> Jakob Schlyter wrote: > > this is the proposed gssapi diff against OpenSSH-current (non-portable). > > note: if this goes in, the old krb5 auth (ssh.com compatible) will be > removed. > > please comment. > > jakob Looks good! I took the patch, and applied it against Portable OpenSSH-3.6.1p2. This took some minor tweaking, as the source is slightly different. I hand edited the Makefile to compile the extra source files, and used the CPPFLAGS and LDFLAGS to point at the MIT 1.2.8 Kerberos GSSAPI. Initial testing against the 3.6.1p2 with Simon's previous patch, and SecureCRT indicates that it works. I did need to add this additional code which was in Simon's original patch to get it to work with MIT. This will also allow for the session caches. I would ask you to consider adding this MIT support. The "logit" needed to be changed to "log" as well, I assume this is an upcoming change. *** ,gss-serv-krb5.c Mon Aug 11 13:06:29 2003 --- gss-serv-krb5.c Mon Aug 11 16:11:48 2003 *************** *** 40,45 **** --- 40,50 ---- #include + #ifndef HEIMDAL + #include + #define krb5_get_err_text(context,code) error_message(code) + #endif + static krb5_context krb_context = NULL; /* Initialise the krb5 library, for the stuff that GSSAPI won't do */ *************** *** 54,60 **** problem = krb5_init_context(&krb_context); if (problem) { ! logit("Cannot initialize krb5 context"); return 0; } krb5_init_ets(krb_context); --- 59,65 ---- problem = krb5_init_context(&krb_context); if (problem) { ! log("Cannot initialize krb5 context"); return 0; } krb5_init_ets(krb_context); *************** *** 78,90 **** if ((retval = krb5_parse_name(krb_context, client->exportedname.value, &princ))) { ! logit("krb5_parse_name(): %.100s", krb5_get_err_text(krb_context, retval)); return 0; } if (krb5_kuserok(krb_context, princ, name)) { retval = 1; ! logit("Authorized to %s, krb5 principal %s (krb5_kuserok)", name, (char *)client->displayname.value); } else retval = 0; --- 83,95 ---- if ((retval = krb5_parse_name(krb_context, client->exportedname.value, &princ))) { ! log("krb5_parse_name(): %.100s", krb5_get_err_text(krb_context, retval)); return 0; } if (krb5_kuserok(krb_context, princ, name)) { retval = 1; ! log("Authorized to %s, krb5 principal %s (krb5_kuserok)", name, (char *)client->displayname.value); } else retval = 0; *************** *** 113,134 **** if (ssh_gssapi_krb5_init() == 0) return; ! if ((problem = krb5_cc_gen_new(krb_context, &krb5_fcc_ops, &ccache))) { ! logit("krb5_cc_gen_new(): %.100s", krb5_get_err_text(krb_context, problem)); return; } if ((problem = krb5_parse_name(krb_context, client->exportedname.value, &princ))) { ! logit("krb5_parse_name(): %.100s", krb5_get_err_text(krb_context, problem)); krb5_cc_destroy(krb_context, ccache); return; } if ((problem = krb5_cc_initialize(krb_context, ccache, princ))) { ! logit("krb5_cc_initialize(): %.100s", krb5_get_err_text(krb_context, problem)); krb5_free_principal(krb_context, princ); krb5_cc_destroy(krb_context, ccache); --- 118,164 ---- if (ssh_gssapi_krb5_init() == 0) return; ! #ifdef HEIMDAL ! problem = krb5_cc_gen_new(krb_context, &krb5_fcc_ops, &ccache); ! #else ! { ! char ccname[40]; ! int tmpfd; ! ! snprintf(ccname,sizeof(ccname),"FILE:/tmp/krb5cc_%d_XXXXXX",geteuid()); ! ! if ((tmpfd = mkstemp(ccname+strlen("FILE:")))==-1) { ! log("mkstemp(): %.100s", strerror(errno)); ! problem = errno; ! return; ! } ! if (fchmod(tmpfd,S_IRUSR | S_IWUSR) == -1) { ! log("fchmod(): %.100s", strerror(errno)); ! close(tmpfd); ! problem = errno; ! return; ! } ! close(tmpfd); ! problem = krb5_cc_resolve(krb_context, ccname, &ccache); ! } ! #endif ! ! if (problem) { ! log("krb5_cc_gen_new(): %.100s", krb5_get_err_text(krb_context, problem)); return; } if ((problem = krb5_parse_name(krb_context, client->exportedname.value, &princ))) { ! log("krb5_parse_name(): %.100s", krb5_get_err_text(krb_context, problem)); krb5_cc_destroy(krb_context, ccache); return; } if ((problem = krb5_cc_initialize(krb_context, ccache, princ))) { ! log("krb5_cc_initialize(): %.100s", krb5_get_err_text(krb_context, problem)); krb5_free_principal(krb_context, princ); krb5_cc_destroy(krb_context, ccache); *************** *** 139,145 **** if ((maj_status = gss_krb5_copy_ccache(&min_status, client->creds, ccache))) { ! logit("gss_krb5_copy_ccache() failed"); krb5_cc_destroy(krb_context, ccache); return; } --- 169,175 ---- if ((maj_status = gss_krb5_copy_ccache(&min_status, client->creds, ccache))) { ! log("gss_krb5_copy_ccache() failed"); krb5_cc_destroy(krb_context, ccache); return; } -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From mouring at etoh.eviladmin.org Tue Aug 12 08:12:58 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 11 Aug 2003 17:12:58 -0500 (CDT) Subject: updated gssapi diff In-Reply-To: <3F3809BF.4081648B@anl.gov> Message-ID: Please actually test again --current instead of 3.6.1pX tree. log() was changed to logit() to avoid the clash with log() from -lm. - Ben On Mon, 11 Aug 2003, Douglas E. Engert wrote: > > > Jakob Schlyter wrote: > > > > this is the proposed gssapi diff against OpenSSH-current (non-portable). > > > > note: if this goes in, the old krb5 auth (ssh.com compatible) will be > > removed. > > > > please comment. > > > > jakob > > Looks good! > > I took the patch, and applied it against Portable OpenSSH-3.6.1p2. This > took some minor tweaking, as the source is slightly different. I hand > edited the Makefile to compile the extra source files, and used the > CPPFLAGS and LDFLAGS to point at the MIT 1.2.8 Kerberos GSSAPI. > > Initial testing against the 3.6.1p2 with Simon's previous patch, and > SecureCRT indicates that it works. > > > I did need to add this additional code which was in Simon's original patch > to get it to work with MIT. This will also allow for the session caches. > I would ask you to consider adding this MIT support. > > The "logit" needed to be changed to "log" as well, I assume this is an > upcoming change. > > > > > *** ,gss-serv-krb5.c Mon Aug 11 13:06:29 2003 > --- gss-serv-krb5.c Mon Aug 11 16:11:48 2003 > *************** > *** 40,45 **** > --- 40,50 ---- > > #include > > + #ifndef HEIMDAL > + #include > + #define krb5_get_err_text(context,code) error_message(code) > + #endif > + > static krb5_context krb_context = NULL; > > /* Initialise the krb5 library, for the stuff that GSSAPI won't do */ > *************** > *** 54,60 **** > > problem = krb5_init_context(&krb_context); > if (problem) { > ! logit("Cannot initialize krb5 context"); > return 0; > } > krb5_init_ets(krb_context); > --- 59,65 ---- > > problem = krb5_init_context(&krb_context); > if (problem) { > ! log("Cannot initialize krb5 context"); > return 0; > } > krb5_init_ets(krb_context); > *************** > *** 78,90 **** > > if ((retval = krb5_parse_name(krb_context, client->exportedname.value, > &princ))) { > ! logit("krb5_parse_name(): %.100s", > krb5_get_err_text(krb_context, retval)); > return 0; > } > if (krb5_kuserok(krb_context, princ, name)) { > retval = 1; > ! logit("Authorized to %s, krb5 principal %s (krb5_kuserok)", > name, (char *)client->displayname.value); > } else > retval = 0; > --- 83,95 ---- > > if ((retval = krb5_parse_name(krb_context, client->exportedname.value, > &princ))) { > ! log("krb5_parse_name(): %.100s", > krb5_get_err_text(krb_context, retval)); > return 0; > } > if (krb5_kuserok(krb_context, princ, name)) { > retval = 1; > ! log("Authorized to %s, krb5 principal %s (krb5_kuserok)", > name, (char *)client->displayname.value); > } else > retval = 0; > *************** > *** 113,134 **** > if (ssh_gssapi_krb5_init() == 0) > return; > > ! if ((problem = krb5_cc_gen_new(krb_context, &krb5_fcc_ops, &ccache))) { > ! logit("krb5_cc_gen_new(): %.100s", > krb5_get_err_text(krb_context, problem)); > return; > } > > if ((problem = krb5_parse_name(krb_context, > client->exportedname.value, &princ))) { > ! logit("krb5_parse_name(): %.100s", > krb5_get_err_text(krb_context, problem)); > krb5_cc_destroy(krb_context, ccache); > return; > } > > if ((problem = krb5_cc_initialize(krb_context, ccache, princ))) { > ! logit("krb5_cc_initialize(): %.100s", > krb5_get_err_text(krb_context, problem)); > krb5_free_principal(krb_context, princ); > krb5_cc_destroy(krb_context, ccache); > --- 118,164 ---- > if (ssh_gssapi_krb5_init() == 0) > return; > > ! #ifdef HEIMDAL > ! problem = krb5_cc_gen_new(krb_context, &krb5_fcc_ops, &ccache); > ! #else > ! { > ! char ccname[40]; > ! int tmpfd; > ! > ! snprintf(ccname,sizeof(ccname),"FILE:/tmp/krb5cc_%d_XXXXXX",geteuid()); > ! > ! if ((tmpfd = mkstemp(ccname+strlen("FILE:")))==-1) { > ! log("mkstemp(): %.100s", strerror(errno)); > ! problem = errno; > ! return; > ! } > ! if (fchmod(tmpfd,S_IRUSR | S_IWUSR) == -1) { > ! log("fchmod(): %.100s", strerror(errno)); > ! close(tmpfd); > ! problem = errno; > ! return; > ! } > ! close(tmpfd); > ! problem = krb5_cc_resolve(krb_context, ccname, &ccache); > ! } > ! #endif > ! > ! if (problem) { > ! log("krb5_cc_gen_new(): %.100s", > krb5_get_err_text(krb_context, problem)); > return; > } > > if ((problem = krb5_parse_name(krb_context, > client->exportedname.value, &princ))) { > ! log("krb5_parse_name(): %.100s", > krb5_get_err_text(krb_context, problem)); > krb5_cc_destroy(krb_context, ccache); > return; > } > > if ((problem = krb5_cc_initialize(krb_context, ccache, princ))) { > ! log("krb5_cc_initialize(): %.100s", > krb5_get_err_text(krb_context, problem)); > krb5_free_principal(krb_context, princ); > krb5_cc_destroy(krb_context, ccache); > *************** > *** 139,145 **** > > if ((maj_status = gss_krb5_copy_ccache(&min_status, > client->creds, ccache))) { > ! logit("gss_krb5_copy_ccache() failed"); > krb5_cc_destroy(krb_context, ccache); > return; > } > --- 169,175 ---- > > if ((maj_status = gss_krb5_copy_ccache(&min_status, > client->creds, ccache))) { > ! log("gss_krb5_copy_ccache() failed"); > krb5_cc_destroy(krb_context, ccache); > return; > } > > > -- > > Douglas E. Engert > Argonne National Laboratory > 9700 South Cass Avenue > Argonne, Illinois 60439 > (630) 252-5444 > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From chkbrian at hongkong.com Tue Aug 12 12:37:48 2003 From: chkbrian at hongkong.com (chkbrian) Date: Tue, 12 Aug 2003 10:37:48 +0800 (CST) Subject: ssh_exchange_identification: Connection closed by remote host Message-ID: <1060655868.9903.chkbrian@hongkong.com> The problem was occurred due to incorrect setting of hosts.allow for tcpwrapper. We have two interface with different Ip address. Only one interface/ ip address was granted access right via hosts.allow. However, always while we want to ssh to hkmauat, the interface/ip address not in hosts.allow was used. So the access was not successful. If the granted interface/ip address was in used, the access was okay. So, the problem is not occurred sometime. Now, we have modify the hosts.allow in hkmauat to include two interface/ip address and the problem is resolved. Thanks. -----Original message----- From:Darren Tucker To:chkbrian at hongkong.com Cc:openssh-unix-dev at mindrot.org Date:Wed, 06 Aug 2003 17:33:44 +1000 Subject:Re: ssh_exchange_identification: Connection closed by remote host chkbrian wrote: > I encountered the following problem while I typing "ssh -v " [snip] > ssh_exchange_identification: Connection closed by remote host You should specify your platform and OpenSSH version, but this is almost certainly due to tcpwrappers configuration. Add the following line to hosts.allow: sshd: ALL It may be in /etc or /usr/local/etc. Alternatively you could rebuild sshd without "--with-tcp-wrappers". -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Tue Aug 12 17:34:54 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 12 Aug 2003 17:34:54 +1000 Subject: [PATCH] Minor nit: -D is now "socks" not "socks4" Message-ID: <3F38989E.1245ED23@zip.com.au> Hi all. I was getting something working over socks5 and was trying to figure out why it kept using socks4. It wasn't, it was just a misleading debug message.... Patch applies to either OpenBSD or Portable. -- 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 -------------- Index: readconf.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/readconf.c,v retrieving revision 1.90 diff -u -p -r1.90 readconf.c --- readconf.c 2 Aug 2003 12:24:49 -0000 1.90 +++ readconf.c 12 Aug 2003 07:21:16 -0000 @@ -676,7 +676,7 @@ parse_int: fatal("%.200s line %d: Badly formatted port number.", filename, linenum); if (*activep) - add_local_forward(options, fwd_port, "socks4", 0); + add_local_forward(options, fwd_port, "socks", 0); break; case oClearAllForwardings: Index: ssh.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/ssh.c,v retrieving revision 1.177 diff -u -p -r1.177 ssh.c --- ssh.c 2 Aug 2003 12:24:50 -0000 1.177 +++ ssh.c 12 Aug 2003 07:20:54 -0000 @@ -445,7 +445,7 @@ again: optarg); exit(1); } - add_local_forward(&options, fwd_port, "socks4", 0); + add_local_forward(&options, fwd_port, "socks", 0); break; case 'C': From dtucker at zip.com.au Tue Aug 12 17:40:40 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 12 Aug 2003 17:40:40 +1000 Subject: ssh_exchange_identification: Connection closed by remote host References: <3F37E04A.7050004@usask.ca> Message-ID: <3F3899F8.9F88E86D@zip.com.au> Alfred Hovdestad wrote: > I am running RedHat 9.0 with openssh 3.5. I have tried connecting from > a RedHat 8.0 box running openshh 3.4 and a tru64 box also with openssh > 3.4, with the same results: I can login to the new account, but not to > my existing account. Perhaps your password are expiring? > The problem is not with tcp wrappers, as I can login to one account, but > not another. I have tried deleting my ssh keys, my host keys, and > rebooting my system, none of which has made any difference. > > Is there anything else I can check? I can send any log information that > you need. Yes, you need to post the *server* side debugging, ie: /path/to/sshd -ddd -p 2022 then in another window: ssh -p 2022 servername -- 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 markus at openbsd.org Tue Aug 12 17:47:27 2003 From: markus at openbsd.org (Markus Friedl) Date: Tue, 12 Aug 2003 09:47:27 +0200 Subject: updated gssapi diff In-Reply-To: References: Message-ID: <20030812074727.GA18572@folly> On Sun, Aug 10, 2003 at 04:43:52PM +0200, Jakob Schlyter wrote: > this is the proposed gssapi diff against OpenSSH-current (non-portable). > > note: if this goes in, the old krb5 auth (ssh.com compatible) will be > removed. > > please comment. i'm surprised by the amount for comments (read: "none") from the people complaining about our kerberos support. From dan at doxpara.com Tue Aug 12 19:43:43 2003 From: dan at doxpara.com (Dan Kaminsky) Date: Tue, 12 Aug 2003 02:43:43 -0700 Subject: [PATCH] Minor nit: -D is now "socks" not "socks4" In-Reply-To: <3F38989E.1245ED23@zip.com.au> References: <3F38989E.1245ED23@zip.com.au> Message-ID: <3F38B6CF.7030902@doxpara.com> Darren Tucker wrote: >Hi all. > I was getting something working over socks5 and was trying to figure out >why it kept using socks4. It wasn't, it was just a misleading debug >message.... > > Patch applies to either OpenBSD or Portable. > > We should be able to trivially support both SOCKS4 and SOCKS5, based on the value in the version field of the incoming request. It's important to support both, since there's alot of systems that only support 4 or 5. There's an interesting argument that we should have, as a long option, a mode that rejects all forwards of the non-DNS forwarding type, for those who intend to use the code for VPN-style uses. This obviously restricts the system to a subset of SOCKS5. --Dan From dan at doxpara.com Tue Aug 12 19:45:14 2003 From: dan at doxpara.com (Dan Kaminsky) Date: Tue, 12 Aug 2003 02:45:14 -0700 Subject: updated gssapi diff In-Reply-To: <20030812074727.GA18572@folly> References: <20030812074727.GA18572@folly> Message-ID: <3F38B72A.8030307@doxpara.com> >i'm surprised by the amount for comments (read: "none") >from the people complaining about our kerberos support. > > They're probably not on the developer's list :-) --Dan From markus at openbsd.org Tue Aug 12 20:00:54 2003 From: markus at openbsd.org (Markus Friedl) Date: Tue, 12 Aug 2003 12:00:54 +0200 Subject: updated gssapi diff In-Reply-To: <3F38B72A.8030307@doxpara.com> References: <20030812074727.GA18572@folly> <3F38B72A.8030307@doxpara.com> Message-ID: <20030812100054.GA23573@folly> On Tue, Aug 12, 2003 at 02:45:14AM -0700, Dan Kaminsky wrote: > They're probably not on the developer's list :-) oh, i'm not subscribed to openssh-unix-whine@ From markus at openbsd.org Tue Aug 12 20:07:36 2003 From: markus at openbsd.org (Markus Friedl) Date: Tue, 12 Aug 2003 12:07:36 +0200 Subject: [PATCH] Minor nit: -D is now "socks" not "socks4" In-Reply-To: <3F38B6CF.7030902@doxpara.com> References: <3F38989E.1245ED23@zip.com.au> <3F38B6CF.7030902@doxpara.com> Message-ID: <20030812100735.GA21600@folly> On Tue, Aug 12, 2003 at 02:43:43AM -0700, Dan Kaminsky wrote: > Darren Tucker wrote: > > >Hi all. > > I was getting something working over socks5 and was trying to figure > > out > >why it kept using socks4. It wasn't, it was just a misleading debug > >message.... > > > > Patch applies to either OpenBSD or Portable. > > > > > We should be able to trivially support both SOCKS4 and SOCKS5, based on > the value in the version field of the incoming request. we already do. > It's important to support both, since there's alot of systems that only > support 4 or 5. we already do. From vinschen at redhat.com Tue Aug 12 21:22:30 2003 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 12 Aug 2003 13:22:30 +0200 Subject: [PATCH] Fix minor breakage on Cygwin: auth-passwd.c andsession.c In-Reply-To: <20030811190404.I20907@greenie.muc.de> References: <3F2F8584.401C1213@zip.com.au> <20030811101128.GB11080@cygbert.vinschen.de> <20030811124457.GD24303@cygbert.vinschen.de> <3F37975C.B4DA0784@zip.com.au> <20030811145517.GE24303@cygbert.vinschen.de> <20030811190404.I20907@greenie.muc.de> Message-ID: <20030812112230.GA17051@cygbert.vinschen.de> On Mon, Aug 11, 2003 at 07:04:05PM +0200, Gert Doering wrote: > Well, it's not a "break" but a "BREAK" signal. > [...] Ok, but which functionality is ioctl(TIOCSBRK/TIOCCBRK)? Does it reflect tcflow(TCOOFF/TCOON), tcflow(TCIOFF/TCION) or tcsendbreak()? Either way, it would be helpful to substitute the ioctl() by a more portable call instead of just ignoring it entirely if the ioctl() code isn't available. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From dtucker at zip.com.au Tue Aug 12 22:26:39 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 12 Aug 2003 22:26:39 +1000 Subject: [PATCH] Fix minor breakage on Cygwin: auth-passwd.c andsession.c References: <3F2F8584.401C1213@zip.com.au> <20030811101128.GB11080@cygbert.vinschen.de> <20030811124457.GD24303@cygbert.vinschen.de> <3F37975C.B4DA0784@zip.com.au> <20030811145517.GE24303@cygbert.vinschen.de> <20030811190404.I20907@greenie.muc.de> <20030812112230.GA17051@cygbert.vinschen.de> Message-ID: <3F38DCFF.1C9F0B13@zip.com.au> Corinna Vinschen wrote: > On Mon, Aug 11, 2003 at 07:04:05PM +0200, Gert Doering wrote: > > Well, it's not a "break" but a "BREAK" signal. > > [...] > > Ok, but which functionality is ioctl(TIOCSBRK/TIOCCBRK)? Does > it reflect tcflow(TCOOFF/TCOON), tcflow(TCIOFF/TCION) or tcsendbreak()? tcsendbreak. I had assumed (and this seems to be the case) that TIOCSBRK/TIOCCBRK are "set break flag" and "clear break flag". I'll bet UARTs have a corresponding flag in a register somewhere. So: ioctl(TIOCSBRK) and the TD line on the port goes to +12V and stays there until ioctl(TIOCCBRK) is called. > Either way, it would be helpful to substitute the ioctl() by a more > portable call instead of just ignoring it entirely if the ioctl() > code isn't available. The catch is the tcsendbreak can't (generally? portably?) specify the duration of the break, you get a hard-coded delay. So, we could do: #if defined(TIOCSBRK) && defined(TIOCCBRK) /* use ioctls */ #else # if defined(HAVE_TCSENDBREAK) /* use tcsendbreak */ # else return 0; # endif #endif If you forget about specifying duration and just use tcsendbreak, it'd be cleaner. You can build a compatibility function using the ioctls where necessary. Also, tcsendbreak doesn't seem to block. -- 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 vinschen at redhat.com Tue Aug 12 23:17:57 2003 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 12 Aug 2003 15:17:57 +0200 Subject: [PATCH] Fix minor breakage on Cygwin: auth-passwd.c andsession.c In-Reply-To: <3F38DCFF.1C9F0B13@zip.com.au> References: <3F2F8584.401C1213@zip.com.au> <20030811101128.GB11080@cygbert.vinschen.de> <20030811124457.GD24303@cygbert.vinschen.de> <3F37975C.B4DA0784@zip.com.au> <20030811145517.GE24303@cygbert.vinschen.de> <20030811190404.I20907@greenie.muc.de> <20030812112230.GA17051@cygbert.vinschen.de> <3F38DCFF.1C9F0B13@zip.com.au> Message-ID: <20030812131757.GB17051@cygbert.vinschen.de> On Tue, Aug 12, 2003 at 10:26:39PM +1000, Darren Tucker wrote: > > Either way, it would be helpful to substitute the ioctl() by a more > > portable call instead of just ignoring it entirely if the ioctl() > > code isn't available. > > The catch is the tcsendbreak can't (generally? portably?) specify the > duration of the break, you get a hard-coded delay. That's right but it doesn't matter, I guess. According to SUSv3, tcsendbreak(fd, 0) sends a break for "at least 0.25 seconds, and not more than 0.5 seconds". Since the sleep period is between 0.5 and 3 secs anyway, the function could just reduce the maximum sleep value to 2.5 secs in which case the total sleep time is somewhere between 0.5 and 3 secs, dependent of the incoming break_length and whether this implementation of tcsendbreak itself blocks or not: /* we will sleep from 500ms to 2500ms */ break_length = MIN(break_length, 2500); break_length = MAX(break_length, 500); tcsendbreak(s->ttyfd, 0); /* should we care about EINTR? */ usleep(break_length * 1000); return 1; Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From markus at openbsd.org Tue Aug 12 23:42:08 2003 From: markus at openbsd.org (Markus Friedl) Date: Tue, 12 Aug 2003 15:42:08 +0200 Subject: [PATCH] Fix minor breakage on Cygwin: auth-passwd.c andsession.c In-Reply-To: <20030812131757.GB17051@cygbert.vinschen.de> References: <3F2F8584.401C1213@zip.com.au> <20030811101128.GB11080@cygbert.vinschen.de> <20030811124457.GD24303@cygbert.vinschen.de> <3F37975C.B4DA0784@zip.com.au> <20030811145517.GE24303@cygbert.vinschen.de> <20030811190404.I20907@greenie.muc.de> <20030812112230.GA17051@cygbert.vinschen.de> <3F38DCFF.1C9F0B13@zip.com.au> <20030812131757.GB17051@cygbert.vinschen.de> Message-ID: <20030812134208.GB16757@folly> On Tue, Aug 12, 2003 at 03:17:57PM +0200, Corinna Vinschen wrote: > /* we will sleep from 500ms to 2500ms */ > break_length = MIN(break_length, 2500); > break_length = MAX(break_length, 500); > tcsendbreak(s->ttyfd, 0); > /* should we care about EINTR? */ > usleep(break_length * 1000); > return 1; i really don't want to sleep. there reason we sleep in the original code is that the draft specifies the duration of the break, if we just use tcsendbreak() then we ignore the specified duration, so no additional sleep is necessary. on the otherhand, i don't see a need for the break length, this should be tcsendbreak()'s job. From deengert at anl.gov Tue Aug 12 23:51:57 2003 From: deengert at anl.gov (Douglas E. Engert) Date: Tue, 12 Aug 2003 08:51:57 -0500 Subject: updated gssapi diff References: <20030812074727.GA18572@folly> Message-ID: <3F38F0FD.3C2E2986@anl.gov> Markus Friedl wrote: > > On Sun, Aug 10, 2003 at 04:43:52PM +0200, Jakob Schlyter wrote: > > this is the proposed gssapi diff against OpenSSH-current (non-portable). > > > > note: if this goes in, the old krb5 auth (ssh.com compatible) will be > > removed. > > > > please comment. > > i'm surprised by the amount for comments (read: "none") > from the people complaining about our kerberos support. No, read at least "one". I am one of those people, and have sent in comments yesterday and a diff to get the mod to work with the MIT GSSAPI. > > _______________________________________________ > 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 dtucker at zip.com.au Wed Aug 13 00:11:18 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 13 Aug 2003 00:11:18 +1000 Subject: [PATCH] Fix minor breakage on Cygwin: auth-passwd.c andsession.c References: <3F2F8584.401C1213@zip.com.au> <20030811101128.GB11080@cygbert.vinschen.de> <20030811124457.GD24303@cygbert.vinschen.de> <3F37975C.B4DA0784@zip.com.au> <20030811145517.GE24303@cygbert.vinschen.de> <20030811190404.I20907@greenie.muc.de> <20030812112230.GA17051@cygbert.vinschen.de> <3F38DCFF.1C9F0B13@zip.com.au> <20030812131757.GB17051@cygbert.vinschen.de> <20030812134208.GB16757@folly> Message-ID: <3F38F586.272B4D1F@zip.com.au> Markus Friedl wrote: > On Tue, Aug 12, 2003 at 03:17:57PM +0200, Corinna Vinschen wrote: > > tcsendbreak(s->ttyfd, 0); [snip] > i really don't want to sleep. Yeah, you'll hang all the sessions. > there reason we sleep in the original code is > that the draft specifies the duration of the > break, if we just use tcsendbreak() then we > ignore the specified duration, so no additional sleep > is necessary. The treatment of tcsendbreak withh a duration != 0 is "implementation defined" which appears to mean "amazingly inconsistent". > on the otherhand, i don't see a need for the break length, > this should be tcsendbreak()'s job. Agreed. I vote for ignoring the duration and using tcsendbreak everywhere including OpenBSD. -- 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 -------------- Index: configure.ac =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/configure.ac,v retrieving revision 1.138 diff -u -p -r1.138 configure.ac --- configure.ac 2 Aug 2003 12:24:49 -0000 1.138 +++ configure.ac 12 Aug 2003 13:51:41 -0000 @@ -695,8 +695,8 @@ AC_CHECK_FUNCS(\ setdtablesize setegid setenv seteuid setgroups setlogin setpcred \ setproctitle setregid setresgid setresuid setreuid setrlimit \ setsid setvbuf sigaction sigvec snprintf socketpair strerror \ - strlcat strlcpy strmode strnvis sysconf tcgetpgrp truncate utimes \ - vhangup vsnprintf waitpid \ + strlcat strlcpy strmode strnvis sysconf tcgetpgrp tcsendbreak \ + truncate utimes vhangup vsnprintf waitpid \ ) AC_SEARCH_LIBS(nanosleep, rt posix4, AC_DEFINE(HAVE_NANOSLEEP)) Index: session.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/session.c,v retrieving revision 1.244 diff -u -p -r1.244 session.c --- session.c 7 Aug 2003 06:28:16 -0000 1.244 +++ session.c 12 Aug 2003 13:55:45 -0000 @@ -1696,20 +1696,11 @@ session_break_req(Session *s) break_length = packet_get_int(); packet_check_eom(); -#if defined(TIOCSBRK) && defined(TIOCCBRK) if (s->ttyfd == -1) return 0; - /* we will sleep from 500ms to 3000ms */ - break_length = MIN(break_length, 3000); - break_length = MAX(break_length, 500); - ioctl(s->ttyfd, TIOCSBRK, NULL); - /* should we care about EINTR? */ - usleep(break_length * 1000); - ioctl(s->ttyfd, TIOCCBRK, NULL); - return 1; -#else + if (tcsendbreak(s->ttyfd, 0) == 0) + return 1; return 0; -#endif } static int Index: openbsd-compat/bsd-misc.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/bsd-misc.c,v retrieving revision 1.16 diff -u -p -r1.16 bsd-misc.c --- openbsd-compat/bsd-misc.c 2 Aug 2003 14:36:16 -0000 1.16 +++ openbsd-compat/bsd-misc.c 12 Aug 2003 13:50:21 -0000 @@ -180,3 +180,17 @@ tcgetpgrp(int fd) } #endif /* HAVE_TCGETPGRP */ +#ifndef HAVE_TCSENDBREAK +int +tcsendbreak(int fd, int duration) +{ +# if defined(TIOCSBRK) && defined(TIOCCBRK) + if (ioctl(fd, TIOCSBRK, NULL) == -1) + return -1; + usleep(500 * 1000); + return ioctl(fd, TIOCCBRK, NULL); +# else + return -1; +# endif +} +#endif /* HAVE_TCSENDBREAK */ Index: openbsd-compat/bsd-misc.h =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/openbsd-compat/bsd-misc.h,v retrieving revision 1.9 diff -u -p -r1.9 bsd-misc.h --- openbsd-compat/bsd-misc.h 2 Aug 2003 13:31:42 -0000 1.9 +++ openbsd-compat/bsd-misc.h 12 Aug 2003 13:55:25 -0000 @@ -91,6 +91,10 @@ int nanosleep(const struct timespec *, s #ifndef HAVE_TCGETPGRP pid_t tcgetpgrp(int); -#endif /* HAVE_TCGETPGRP */ +#endif + +#ifndef HAVE_TCSENDBREAK +int tcsendbreak(int, int); +#endif #endif /* _BSD_MISC_H */ From markus at openbsd.org Wed Aug 13 00:13:09 2003 From: markus at openbsd.org (Markus Friedl) Date: Tue, 12 Aug 2003 16:13:09 +0200 Subject: updated gssapi diff In-Reply-To: <3F38F0FD.3C2E2986@anl.gov> References: <20030812074727.GA18572@folly> <3F38F0FD.3C2E2986@anl.gov> Message-ID: <20030812141309.GA12363@folly> On Tue, Aug 12, 2003 at 08:51:57AM -0500, Douglas E. Engert wrote: > No, read at least "one". I am one of those people, and have sent in > comments yesterday and a diff to get the mod to work with the MIT > GSSAPI. thanks, but if it's only one, then it's seems that not too many care..... From deengert at anl.gov Wed Aug 13 00:23:44 2003 From: deengert at anl.gov (Douglas E. Engert) Date: Tue, 12 Aug 2003 09:23:44 -0500 Subject: updated gssapi diff References: Message-ID: <3F38F86F.79C3388A@anl.gov> Ben Lindstrom wrote: > > Please actually test again --current instead of 3.6.1pX tree. I was testing on Solaris 5.7. I was under the impression that the mods where for the OpenBSD version and that "current" was OpenBSD only. So I used what I thought was the most recent portable version. If there is a newer portable version, let me know. The mods also did not include any changes to Makefile.in or configure.ac I figured these would come later. So I made no attempt to update these but edited the Makefile after configuring. > > log() was changed to logit() to avoid the clash with log() from -lm. I assume that the OpenBSD source is more up to date then the portable 3.6.1 and that we will see "logit" in the portable version in the future. > > - Ben > > On Mon, 11 Aug 2003, Douglas E. Engert wrote: > > > > > > > Jakob Schlyter wrote: > > > > > > this is the proposed gssapi diff against OpenSSH-current (non-portable). > > > > > > note: if this goes in, the old krb5 auth (ssh.com compatible) will be > > > removed. > > > > > > please comment. > > > > > > jakob > > > > Looks good! > > > > I took the patch, and applied it against Portable OpenSSH-3.6.1p2. This > > took some minor tweaking, as the source is slightly different. I hand > > edited the Makefile to compile the extra source files, and used the > > CPPFLAGS and LDFLAGS to point at the MIT 1.2.8 Kerberos GSSAPI. > > > > Initial testing against the 3.6.1p2 with Simon's previous patch, and > > SecureCRT indicates that it works. > > > > > > I did need to add this additional code which was in Simon's original patch > > to get it to work with MIT. This will also allow for the session caches. > > I would ask you to consider adding this MIT support. > > > > The "logit" needed to be changed to "log" as well, I assume this is an > > upcoming change. > > > > > > > > > > *** ,gss-serv-krb5.c Mon Aug 11 13:06:29 2003 > > --- gss-serv-krb5.c Mon Aug 11 16:11:48 2003 > > *************** > > *** 40,45 **** > > --- 40,50 ---- > > > > #include > > > > + #ifndef HEIMDAL > > + #include > > + #define krb5_get_err_text(context,code) error_message(code) > > + #endif > > + > > static krb5_context krb_context = NULL; > > > > /* Initialise the krb5 library, for the stuff that GSSAPI won't do */ > > *************** > > *** 54,60 **** > > > > problem = krb5_init_context(&krb_context); > > if (problem) { > > ! logit("Cannot initialize krb5 context"); > > return 0; > > } > > krb5_init_ets(krb_context); > > --- 59,65 ---- > > > > problem = krb5_init_context(&krb_context); > > if (problem) { > > ! log("Cannot initialize krb5 context"); > > return 0; > > } > > krb5_init_ets(krb_context); > > *************** > > *** 78,90 **** > > > > if ((retval = krb5_parse_name(krb_context, client->exportedname.value, > > &princ))) { > > ! logit("krb5_parse_name(): %.100s", > > krb5_get_err_text(krb_context, retval)); > > return 0; > > } > > if (krb5_kuserok(krb_context, princ, name)) { > > retval = 1; > > ! logit("Authorized to %s, krb5 principal %s (krb5_kuserok)", > > name, (char *)client->displayname.value); > > } else > > retval = 0; > > --- 83,95 ---- > > > > if ((retval = krb5_parse_name(krb_context, client->exportedname.value, > > &princ))) { > > ! log("krb5_parse_name(): %.100s", > > krb5_get_err_text(krb_context, retval)); > > return 0; > > } > > if (krb5_kuserok(krb_context, princ, name)) { > > retval = 1; > > ! log("Authorized to %s, krb5 principal %s (krb5_kuserok)", > > name, (char *)client->displayname.value); > > } else > > retval = 0; > > *************** > > *** 113,134 **** > > if (ssh_gssapi_krb5_init() == 0) > > return; > > > > ! if ((problem = krb5_cc_gen_new(krb_context, &krb5_fcc_ops, &ccache))) { > > ! logit("krb5_cc_gen_new(): %.100s", > > krb5_get_err_text(krb_context, problem)); > > return; > > } > > > > if ((problem = krb5_parse_name(krb_context, > > client->exportedname.value, &princ))) { > > ! logit("krb5_parse_name(): %.100s", > > krb5_get_err_text(krb_context, problem)); > > krb5_cc_destroy(krb_context, ccache); > > return; > > } > > > > if ((problem = krb5_cc_initialize(krb_context, ccache, princ))) { > > ! logit("krb5_cc_initialize(): %.100s", > > krb5_get_err_text(krb_context, problem)); > > krb5_free_principal(krb_context, princ); > > krb5_cc_destroy(krb_context, ccache); > > --- 118,164 ---- > > if (ssh_gssapi_krb5_init() == 0) > > return; > > > > ! #ifdef HEIMDAL > > ! problem = krb5_cc_gen_new(krb_context, &krb5_fcc_ops, &ccache); > > ! #else > > ! { > > ! char ccname[40]; > > ! int tmpfd; > > ! > > ! snprintf(ccname,sizeof(ccname),"FILE:/tmp/krb5cc_%d_XXXXXX",geteuid()); > > ! > > ! if ((tmpfd = mkstemp(ccname+strlen("FILE:")))==-1) { > > ! log("mkstemp(): %.100s", strerror(errno)); > > ! problem = errno; > > ! return; > > ! } > > ! if (fchmod(tmpfd,S_IRUSR | S_IWUSR) == -1) { > > ! log("fchmod(): %.100s", strerror(errno)); > > ! close(tmpfd); > > ! problem = errno; > > ! return; > > ! } > > ! close(tmpfd); > > ! problem = krb5_cc_resolve(krb_context, ccname, &ccache); > > ! } > > ! #endif > > ! > > ! if (problem) { > > ! log("krb5_cc_gen_new(): %.100s", > > krb5_get_err_text(krb_context, problem)); > > return; > > } > > > > if ((problem = krb5_parse_name(krb_context, > > client->exportedname.value, &princ))) { > > ! log("krb5_parse_name(): %.100s", > > krb5_get_err_text(krb_context, problem)); > > krb5_cc_destroy(krb_context, ccache); > > return; > > } > > > > if ((problem = krb5_cc_initialize(krb_context, ccache, princ))) { > > ! log("krb5_cc_initialize(): %.100s", > > krb5_get_err_text(krb_context, problem)); > > krb5_free_principal(krb_context, princ); > > krb5_cc_destroy(krb_context, ccache); > > *************** > > *** 139,145 **** > > > > if ((maj_status = gss_krb5_copy_ccache(&min_status, > > client->creds, ccache))) { > > ! logit("gss_krb5_copy_ccache() failed"); > > krb5_cc_destroy(krb_context, ccache); > > return; > > } > > --- 169,175 ---- > > > > if ((maj_status = gss_krb5_copy_ccache(&min_status, > > client->creds, ccache))) { > > ! log("gss_krb5_copy_ccache() failed"); > > krb5_cc_destroy(krb_context, ccache); > > return; > > } > > > > > > -- > > > > Douglas E. Engert > > Argonne National Laboratory > > 9700 South Cass Avenue > > Argonne, Illinois 60439 > > (630) 252-5444 > > > > _______________________________________________ > > 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 deengert at anl.gov Wed Aug 13 00:30:59 2003 From: deengert at anl.gov (Douglas E. Engert) Date: Tue, 12 Aug 2003 09:30:59 -0500 Subject: updated gssapi diff References: <20030812074727.GA18572@folly> <3F38F0FD.3C2E2986@anl.gov> <20030812141309.GA12363@folly> Message-ID: <3F38FA23.5D7CF203@anl.gov> Markus Friedl wrote: > > On Tue, Aug 12, 2003 at 08:51:57AM -0500, Douglas E. Engert wrote: > > No, read at least "one". I am one of those people, and have sent in > > comments yesterday and a diff to get the mod to work with the MIT > > GSSAPI. > > thanks, but if it's only one, then it's seems that not too many care..... Please take this lightly, have you ever seen the Sienfeld TV episode called the "Soup Nazi"? I think poeple are reacting like that. You have the best "Soup" in town, but based on passed e-mails people don't want to upset you, so they shy away from any contact. The Soup Nazi A new soup restaurant opens around the corner and it seems no one can get enough of the soup. The owner of the restaurant is a bit eccentric and insists that customers follow a very stringent ordering procedure. He is known as the soup nazi. One day Jerry and his girlfriend go to purchase some soup. After his girlfriend makes a mistake during the ordering, Jerry pretends he does not know her so that he may purchase some more soup. Elaine latter makes a similar mistake and is outraged. Elaine prepares to move a piece of furniture into her apartment but it is quickly stolen but two "hoods" after Kramer who was supposed to watch the piece decides to give it up rather than fight for it. Kramer talks with the Soup Nazi and the Soup Nazi agrees to give a piece of furniture to Kramer so that he may give it to his friend whose furniture was stolen. Elaine is delighted to receive the furniture as a gift and soon discovers its source, the Soup Nazi. After further examination of the furniture she discovers recipes for all of the famous soups that everyone so enjoys. She arrives at the Soup Nazi's restaurant and reads the recipes aloud and finishes by quoting the Soup Nazi and stating there will be "No more soup for you, Next.!" -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From vinschen at redhat.com Wed Aug 13 00:31:58 2003 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 12 Aug 2003 16:31:58 +0200 Subject: [PATCH] Fix minor breakage on Cygwin: auth-passwd.c andsession.c In-Reply-To: <3F38F586.272B4D1F@zip.com.au> References: <20030811101128.GB11080@cygbert.vinschen.de> <20030811124457.GD24303@cygbert.vinschen.de> <3F37975C.B4DA0784@zip.com.au> <20030811145517.GE24303@cygbert.vinschen.de> <20030811190404.I20907@greenie.muc.de> <20030812112230.GA17051@cygbert.vinschen.de> <3F38DCFF.1C9F0B13@zip.com.au> <20030812131757.GB17051@cygbert.vinschen.de> <20030812134208.GB16757@folly> <3F38F586.272B4D1F@zip.com.au> Message-ID: <20030812143158.GE17051@cygbert.vinschen.de> On Wed, Aug 13, 2003 at 12:11:18AM +1000, Darren Tucker wrote: > Markus Friedl wrote: > > on the otherhand, i don't see a need for the break length, > > this should be tcsendbreak()'s job. > > Agreed. I vote for ignoring the duration and using tcsendbreak everywhere > including OpenBSD. I agree, tcsendbreak(s->ttyfd, 0) should be the way to go. Corinna -- Corinna Vinschen Cygwin Developer Red Hat, Inc. mailto:vinschen at redhat.com From mouring at etoh.eviladmin.org Wed Aug 13 00:34:28 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Tue, 12 Aug 2003 09:34:28 -0500 (CDT) Subject: updated gssapi diff In-Reply-To: <3F38F86F.79C3388A@anl.gov> Message-ID: On Tue, 12 Aug 2003, Douglas E. Engert wrote: > > > Ben Lindstrom wrote: > > > > Please actually test again --current instead of 3.6.1pX tree. > > I was testing on Solaris 5.7. I was under the impression that the > mods where for the OpenBSD version and that "current" was OpenBSD only. > So I used what I thought was the most recent portable version. If there > is a newer portable version, let me know. > > The mods also did not include any changes to Makefile.in or configure.ac > I figured these would come later. So I made no attempt to update these but > edited the Makefile after configuring. > > > > > log() was changed to logit() to avoid the clash with log() from -lm. > > I assume that the OpenBSD source is more up to date then the portable 3.6.1 > and that we will see "logit" in the portable version in the future. > There are snapshots from the OpenSSH portable here: ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/snapshot/ Or from your favorite server list on: http://www.openssh.com/portable.html OpenSSH Portable lags behind OpenBSD's mainline tree, but it normally is not too horrible (unless all three of us are busy). Also on the portable.html page is the public CVS tree if you wish that. And I run a CVSWeb at: http://www.eviladmin.org/cvs/cvsweb.cgi/ - Ben From smoogen at lanl.gov Wed Aug 13 02:43:01 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Tue, 12 Aug 2003 10:43:01 -0600 Subject: updated gssapi diff In-Reply-To: <20030812141309.GA12363@folly> References: <20030812074727.GA18572@folly> <3F38F0FD.3C2E2986@anl.gov> <20030812141309.GA12363@folly> Message-ID: <1060706581.7222.26.camel@smoogen1.lanl.gov> I think the list is much longer, but since we have been told to shut up if we didnt have code... it makes a quiet list. On Tue, 2003-08-12 at 08:13, Markus Friedl wrote: > On Tue, Aug 12, 2003 at 08:51:57AM -0500, Douglas E. Engert wrote: > > No, read at least "one". I am one of those people, and have sent in > > comments yesterday and a diff to get the mod to work with the MIT > > GSSAPI. > > thanks, but if it's only one, then it's seems that not too many care..... > > _______________________________________________ > 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 Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #) Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From sxw at inf.ed.ac.uk Wed Aug 13 03:00:56 2003 From: sxw at inf.ed.ac.uk (sxw at inf.ed.ac.uk) Date: Tue, 12 Aug 2003 18:00:56 +0100 (BST) Subject: updated gssapi diff In-Reply-To: <1060706581.7222.26.camel@smoogen1.lanl.gov> Message-ID: On Tue, 12 Aug 2003, Stephen Smoogen wrote: > I think the list is much longer, but since we have been told to shut up > if we didnt have code... it makes a quiet list. Now that there is a reduced patch it would be good if everyone who's interested in getting Kerberos support in OpenSSH could take a look it it. At this point, code reviews would be most useful. If you've already reviewed my GSSAPI patches, take a look at this one and check that none of the changes have broken anything. If you're familiar with GSSAPI, and you've not reviewed the patches, please do so. Once you've reviewed the code, please let the list know, even if its just to say that it looks OK. Please also give the code a go. Test it against your existing GSSAPI OpenSSHes. Try other clients against it (bare in mind that those that only do gssapi keyexchange won't currently work). I'm planning on producing patches to add MIT, and portable, support in the next couple of days. Thanks, Simon. From jakob at openbsd.org Wed Aug 13 04:05:11 2003 From: jakob at openbsd.org (Jakob Schlyter) Date: Tue, 12 Aug 2003 20:05:11 +0200 (CEST) Subject: updated gssapi diff In-Reply-To: <20030810225520.A11520@google.com> References: <20030810225520.A11520@google.com> Message-ID: On Sun, 10 Aug 2003, Frank Cusack wrote: > session.c needs to test options.gss_cleanup_creds before unconditionally > cleaning up, here: > > --- session.c 10 Aug 2003 14:06:53 -0000 1.1.1.2 > +++ session.c 10 Aug 2003 14:25:01 -0000 1.4 > @@ -1832,4 +1855,7 @@ > do_authenticated2(Authctxt *authctxt) > { > server_loop2(authctxt); > +#if defined(GSSAPI) > + ssh_gssapi_cleanup_creds(NULL); > +#endif > } > > should be: > > if (options.gss_cleanup_creds) > ssh_gssapi_cleanup_creds(NULL); fixed. > It needs docs as well: > > 8<--- > --- openssh.orig/sshd_config.5 2003-06-08 17:20:47.000000000 -0700 > +++ openssh/sshd_config.5 2003-06-08 17:19:39.000000000 -0700 > @@ -273,7 +273,11 @@ > The default is > .Dq yes . > Note that this option applies to protocol version 2 only. > - > +.It Cm GSSAPICleanUpCreds > +Specifies whether ssh with gssapi will delete the ccache when the session exits, fatal or otherwise. > +The default is > +.Dq yes . > +Note that this option applies to protocol version 2 only. > .It Cm IgnoreRhosts > Specifies that > .Pa .rhosts this was already in the manpage. > sshconnect2.c:input_gssapi_error() is too noisy. > > 8<--- > --- openssh.orig/sshconnect2.c 2003-07-09 20:57:32.000000000 -0700 > +++ openssh/sshconnect2.c 2003-07-09 21:02:50.000000000 -0700 > @@ -723,7 +723,7 @@ input_gssapi_error(int type, u_int32_t p > > packet_check_eom(); > > - fprintf(stderr, "Server GSSAPI Error:\n%s\n", msg); > + debug("Server GSSAPI Error:\n%s\n", msg); > xfree(msg); > xfree(lang); > } > 8<--- fixed. jakob From wendyp at cray.com Wed Aug 13 04:13:43 2003 From: wendyp at cray.com (Wendy Palm) Date: Tue, 12 Aug 2003 13:13:43 -0500 Subject: updated gssapi diff References: <20030812074727.GA18572@folly> <3F38B72A.8030307@doxpara.com> Message-ID: <3F392E57.5050208@cray.com> no, i just haven't had access to a kerberos machine to test anything out yet. Dan Kaminsky wrote: > >> i'm surprised by the amount for comments (read: "none") >> from the people complaining about our kerberos support. >> >> > They're probably not on the developer's list :-) > > --Dan > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev -- wendy palm Cray Open Software Development, Cray Inc. wendyp at cray.com, 651-605-9154 From gert at greenie.muc.de Wed Aug 13 04:20:26 2003 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 12 Aug 2003 20:20:26 +0200 Subject: [PATCH] Fix minor breakage on Cygwin: auth-passwd.c andsession.c In-Reply-To: <20030812112230.GA17051@cygbert.vinschen.de>; from vinschen@redhat.com on Tue, Aug 12, 2003 at 01:22:30PM +0200 References: <3F2F8584.401C1213@zip.com.au> <20030811101128.GB11080@cygbert.vinschen.de> <20030811124457.GD24303@cygbert.vinschen.de> <3F37975C.B4DA0784@zip.com.au> <20030811145517.GE24303@cygbert.vinschen.de> <20030811190404.I20907@greenie.muc.de> <20030812112230.GA17051@cygbert.vinschen.de> Message-ID: <20030812202026.C20907@greenie.muc.de> Hi, On Tue, Aug 12, 2003 at 01:22:30PM +0200, Corinna Vinschen wrote: > On Mon, Aug 11, 2003 at 07:04:05PM +0200, Gert Doering wrote: > > Well, it's not a "break" but a "BREAK" signal. > > [...] > > Ok, but which functionality is ioctl(TIOCSBRK/TIOCCBRK)? Does > it reflect tcflow(TCOOFF/TCOON), tcflow(TCIOFF/TCION) or tcsendbreak()? tcsendbreak() > Either way, it would be helpful to substitute the ioctl() by a more > portable call instead of just ignoring it entirely if the ioctl() > code isn't available. Yes. TIOCSBRK/TIOCCBRK is "very old BSD code". gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From deengert at anl.gov Wed Aug 13 04:55:30 2003 From: deengert at anl.gov (Douglas E. Engert) Date: Tue, 12 Aug 2003 13:55:30 -0500 Subject: updated gssapi diff Message-ID: <3F393822.E890E4F2@anl.gov> Here is the updated diff for the gss-serv-krb5.c as applied against the openssh-SNAP-20030809 so it will work with the MIT GSSAPI. The code is substantially the same code as found in auth-krb5.c The patch applied smoothly accept with monitor.h. which was easily corrected by hand.) This was compiled and tested on Solaris 5.7. with MIT krb5-1.2.8. Simple tests using this ssh and sshd against OpenSSH-3.6.1p2 with Simon's full mods and the sshd with the SecureCRT Windows client appear to work as expected. --- ,gss-serv-krb5.c Tue Aug 12 11:32:35 2003 +++ gss-serv-krb5.c Tue Aug 12 13:03:47 2003 @@ -40,6 +40,11 @@ #include +#ifndef HEIMDAL +#include +#define krb5_get_err_text(context,code) error_message(code) +#endif + static krb5_context krb_context = NULL; /* Initialise the krb5 library, for the stuff that GSSAPI won't do */ @@ -113,7 +118,32 @@ if (ssh_gssapi_krb5_init() == 0) return; - if ((problem = krb5_cc_gen_new(krb_context, &krb5_fcc_ops, &ccache))) { +#ifdef HEIMDAL + problem = krb5_cc_gen_new(krb_context, &krb5_fcc_ops, &ccache); +#else +{ + char ccname[40]; + int tmpfd; + + snprintf(ccname,sizeof(ccname),"FILE:/tmp/krb5cc_%d_XXXXXX",geteuid()); + + if ((tmpfd = mkstemp(ccname+strlen("FILE:")))==-1) { + logit("mkstemp(): %.100s", strerror(errno)); + problem = errno; + return; + } + if (fchmod(tmpfd,S_IRUSR | S_IWUSR) == -1) { + logit("fchmod(): %.100s", strerror(errno)); + close(tmpfd); + problem = errno; + return; + } + close(tmpfd); + problem = krb5_cc_resolve(krb_context, ccname, &ccache); +} +#endif + + if (problem) { logit("krb5_cc_gen_new(): %.100s", krb5_get_err_text(krb_context, problem)); return; From fcusack at fcusack.com Wed Aug 13 04:56:26 2003 From: fcusack at fcusack.com (Frank Cusack) Date: Tue, 12 Aug 2003 11:56:26 -0700 Subject: updated gssapi diff In-Reply-To: <20030812074727.GA18572@folly>; from markus@openbsd.org on Tue, Aug 12, 2003 at 09:47:27AM +0200 References: <20030812074727.GA18572@folly> Message-ID: <20030812115626.A17399@google.com> On Tue, Aug 12, 2003 at 09:47:27AM +0200, Markus Friedl wrote: > On Sun, Aug 10, 2003 at 04:43:52PM +0200, Jakob Schlyter wrote: > > this is the proposed gssapi diff against OpenSSH-current (non-portable). > > > > note: if this goes in, the old krb5 auth (ssh.com compatible) will be > > removed. > > > > please comment. > > i'm surprised by the amount for comments (read: "none") > from the people complaining about our kerberos support. Myself and Doug E. don't count? We both commented AND provided additional fixes. Your selective memory is finely tuned. Then again, I'm a critic not a complainer. I wouldn't expect complainers to respond, you've shut down their complaint. It really sucks the way you (plural) solicit review (this and other examples in the past). Making people feel guilty for not looking at code they don't have time to look at. You push regular users away and attract zealots. If openssh is for openssh' sake that's fine. But otherwise, people don't want the abuse and go off and do their own thing. If folks don't review it to your satisfaction, a simply don't include the code! (Hopefully with warning, though.) No need to be mean about it. Also, it's not like everyone is available at a whim. geez, you gave it one business day? How many reviewers do you want anyway? The code looks great. sans the missing parts of course -- per session ccache control and gsskeyex. I understand you're going to harangue over gsskeyex for awhile, but I don't understand the reason for losing the per-session ccache controls. It's a small amount of easy-to-understand code. /fc From markus at openbsd.org Wed Aug 13 05:20:31 2003 From: markus at openbsd.org (Markus Friedl) Date: Tue, 12 Aug 2003 21:20:31 +0200 Subject: updated gssapi diff In-Reply-To: <20030812115626.A17399@google.com> References: <20030812074727.GA18572@folly> <20030812115626.A17399@google.com> Message-ID: <20030812192031.GA20431@folly> On Tue, Aug 12, 2003 at 11:56:26AM -0700, Frank Cusack wrote: > On Tue, Aug 12, 2003 at 09:47:27AM +0200, Markus Friedl wrote: > > On Sun, Aug 10, 2003 at 04:43:52PM +0200, Jakob Schlyter wrote: > > > this is the proposed gssapi diff against OpenSSH-current (non-portable). > > > > > > note: if this goes in, the old krb5 auth (ssh.com compatible) will be > > > removed. > > > > > > please comment. > > > > i'm surprised by the amount for comments (read: "none") > > from the people complaining about our kerberos support. > > Myself and Doug E. don't count? We both commented AND provided additional > fixes. Your selective memory is finely tuned. Still you're the only one's that seem to care. > Then again, I'm a critic not a complainer. I wouldn't expect complainers > to respond, you've shut down their complaint. > > It really sucks the way you (plural) solicit review (this and other > examples in the past). Making people feel guilty for not looking at > code they don't have time to look at. If the people who are intersted don't have time to look into this, why should the people who are not interested look into this? From fcusack at fcusack.com Wed Aug 13 05:58:13 2003 From: fcusack at fcusack.com (Frank Cusack) Date: Tue, 12 Aug 2003 12:58:13 -0700 Subject: updated gssapi diff In-Reply-To: <20030812192031.GA20431@folly>; from markus@openbsd.org on Tue, Aug 12, 2003 at 09:20:31PM +0200 References: <20030812074727.GA18572@folly> <20030812115626.A17399@google.com> <20030812192031.GA20431@folly> Message-ID: <20030812125813.A17461@google.com> On Tue, Aug 12, 2003 at 09:20:31PM +0200, Markus Friedl wrote: > If the people who are intersted don't have time to look into this, > why should the people who are not interested look into this? Agreed. /fc From smoogen at lanl.gov Wed Aug 13 06:40:13 2003 From: smoogen at lanl.gov (Stephen Smoogen) Date: Tue, 12 Aug 2003 14:40:13 -0600 Subject: updated gssapi diff In-Reply-To: <20030812192031.GA20431@folly> References: <20030812074727.GA18572@folly> <20030812115626.A17399@google.com> <20030812192031.GA20431@folly> Message-ID: <1060720813.7222.36.camel@smoogen1.lanl.gov> On Tue, 2003-08-12 at 13:20, Markus Friedl wrote: > On Tue, Aug 12, 2003 at 11:56:26AM -0700, Frank Cusack wrote: > > On Tue, Aug 12, 2003 at 09:47:27AM +0200, Markus Friedl wrote: > > > On Sun, Aug 10, 2003 at 04:43:52PM +0200, Jakob Schlyter wrote: > > > > this is the proposed gssapi diff against OpenSSH-current (non-portable). > > > > > > > > note: if this goes in, the old krb5 auth (ssh.com compatible) will be > > > > removed. > > > > > > > > please comment. > > > > > > i'm surprised by the amount for comments (read: "none") > > > from the people complaining about our kerberos support. > > > > Myself and Doug E. don't count? We both commented AND provided additional > > fixes. Your selective memory is finely tuned. > > Still you're the only one's that seem to care. > I am doing a review over the weekend when I can dedicate 6-12 hours to it. I don't know if it will be useful or not.. but that is the plan. -- Stephen John Smoogen smoogen at lanl.gov Los Alamos National Labrador CCN-5 Sched 5/40 PH: 4-0645 (note new #) Ta-03 SM-1498 MailStop B255 DP 10S Los Alamos, NM 87545 -- So shines a good deed in a weary world. = Willy Wonka -- From kerry at crypt.gen.nz Wed Aug 13 07:04:04 2003 From: kerry at crypt.gen.nz (Kerry Thompson) Date: Wed, 13 Aug 2003 09:04:04 +1200 (NZST) Subject: updated gssapi diff In-Reply-To: <20030812141309.GA12363@folly> References: <20030812074727.GA18572@folly> <3F38F0FD.3C2E2986@anl.gov> <20030812141309.GA12363@folly> Message-ID: <1658.202.27.185.71.1060722244.squirrel@www.crypt.gen.nz> Markus Friedl said: > On Tue, Aug 12, 2003 at 08:51:57AM -0500, Douglas E. Engert wrote: >> No, read at least "one". I am one of those people, and have sent in >> comments yesterday and a diff to get the mod to work with the MIT >> GSSAPI. > > thanks, but if it's only one, then it's seems that not too many care..... I'll be looking at it over the next couple of days, but I would kindly request the maintainers not to put a strict time limit on this review. It takes time to perform a security review even for simple systems, and it takes longer to do it properly. Kerry -- Kerry Thompson, CCNA CISSP Information Systems Security Consultant http://www.crypt.gen.nz kerry at crypt.gen.nz From djm at mindrot.org Wed Aug 13 08:29:46 2003 From: djm at mindrot.org (Damien Miller) Date: Wed, 13 Aug 2003 08:29:46 +1000 Subject: excellently In-Reply-To: <20030812115442.1D3CA27C1AC@shitei.mindrot.org> References: <20030812115442.1D3CA27C1AC@shitei.mindrot.org> Message-ID: <3F396A5A.6050902@mindrot.org> Wow. dada spam. Antranig Alfaro wrote: > humans bouts scrupulously taxied annette methacrylate exert crouching > exclude hubris meteorite aides acronym exogenous boater plead savoring > tapestries courtrooms taunter bodyweight poultry pokes brandishes > poems ama mightiness assam countless actinolite merges crave technic > accomplishers bombast creation bonaparte savors portion menaced scroll > teethe thawing adumbrating icicle bergland memorized practise > acoustically explanatory sanest audrey humbler polyhedral exclaimer > memorization barnard sculpt hypocrisy mends estimation corrigible > pleasantness examination teared terminology exclusion boats alfred > scoops exegesis tensed telecommunicate bonus hotbed theirs tattooed > hot hotelman exposes horrid scheme evens > > [1][ra.gif] > pompon expectancy householders crazes middles hypodermics hysterectomy > sawfly pouted mealy bonanza alvin bond bonder melted poked evicts crow > hospitalizing bellini aitken testability hostesses boundless > microcomputer bombards illuminate boiler brass boggled melts > accomplishes asher screen exemplar creep mentors crept televised poems > exponent tempestuously accruing immaculate exchequer tattler > exhilarate accessibility countries 4th sclerosis hospice blvd > hypothalamic tappet acronyms talkativeness meridional botches allstate > bodybuilding exceeding powder boyishness breaches hydrology satanic > breaching cringe tall bowdlerize excretion boomerangs illustrations > ampex maybe bonaventure icings temperance portulaca militarily > accordions blaine > > References > > 1. http://srd.yahoo.com/drst/bowed/*http://www.med12z.com/sh/index.html > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From ecnfvtbydvto at msn.com Wed Aug 13 14:10:06 2003 From: ecnfvtbydvto at msn.com (ecnfvtbydvto at msn.com) Date: Wed, 13 Aug 2003 13:10:06 +0900 Subject: .. Debt stopping you from getting ahead? Read NOWik9dpsa Message-ID: <20030813041227.3867527C18A@shitei.mindrot.org> Okay heres the deal, Debt sucks. So does lining your bank managers pockets! We are going to help you save a TON of money by paying off your debts for you! - Save you a lot of money by eliminating late fees - Settle your accounts for a substantially reduced amount - Stop creditors calling you on the phone - Avoid bankruptcy ... and more! Why keep dealing with the stress, and headaches? Combine your debt into a low interest repayment and get on with your life today!! Come here and take a look at how we can help. http://btrack.iwon.com/r.pl?redir=http://bobby at www.slashmonthlypayments.com/index.php?N=g stop more of these http://btrack.iwon.com/r.pl?redir=http://bb2 at www.slashmonthlypayments.com/r.php From dtucker at zip.com.au Wed Aug 13 15:35:49 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 13 Aug 2003 15:35:49 +1000 Subject: [PATCH] Minor nit: -D is now "socks" not "socks4" References: <3F38989E.1245ED23@zip.com.au> <3F38B6CF.7030902@doxpara.com> <20030812100735.GA21600@folly> Message-ID: <3F39CE35.77FD53C5@zip.com.au> Markus Friedl wrote: > On Tue, Aug 12, 2003 at 02:43:43AM -0700, Dan Kaminsky wrote: > > It's important to support both, since there's alot of systems that only > > support 4 or 5. > > we already do. The debug still says "socks4", though, hence the patch. -- 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 alfred.hovdestad at usask.ca Thu Aug 14 02:45:13 2003 From: alfred.hovdestad at usask.ca (Alfred Hovdestad) Date: Wed, 13 Aug 2003 10:45:13 -0600 Subject: ssh_exchange_identification: Connection closed by remote host In-Reply-To: <3F3899F8.9F88E86D@zip.com.au> References: <3F37E04A.7050004@usask.ca> <3F3899F8.9F88E86D@zip.com.au> Message-ID: <3F3A6B19.1070308@usask.ca> There appears to be a problem interacting with our kerberos server. We are using PAM with Kerberos authentication. Everything was working with the previous version of openssh, but logins with the latest version of openssh started failing. I tried turning off kerberos authentication in PAM, and that worked. I then tried pointing to a test kerberos server, and that also worked. The only difference is that our main kerberos server is a Windows Domain Controller, and our test kerberos server is a Sun. I don't know how the interaction between openssh and kerberos changed in the current version, but I have a workaround. If you would like a dump of the logs, please let me know. Alfred Hovdestad Darren Tucker wrote: > Alfred Hovdestad wrote: > >>I am running RedHat 9.0 with openssh 3.5. I have tried connecting from >>a RedHat 8.0 box running openshh 3.4 and a tru64 box also with openssh >>3.4, with the same results: I can login to the new account, but not to >>my existing account. > > > Perhaps your password are expiring? > > >>The problem is not with tcp wrappers, as I can login to one account, but >>not another. I have tried deleting my ssh keys, my host keys, and >>rebooting my system, none of which has made any difference. >> >>Is there anything else I can check? I can send any log information that >>you need. > > > Yes, you need to post the *server* side debugging, ie: > > /path/to/sshd -ddd -p 2022 > > then in another window: > > ssh -p 2022 servername > From jodo710 at hotmail.com Fri Aug 15 06:25:18 2003 From: jodo710 at hotmail.com (Joey Doughly) Date: Thu, 14 Aug 2003 20:25:18 +0000 Subject: Monitor Modules Message-ID: Hello Everyone, I am porting ssh IBM's AS400 and am having a hard time with the monitor modules (monitor.c, monitor_fdpass.c, monitor_mml.c, monitor_wrap.c) I first of all don't understand what these modules are doing, and the parts I do understand don't make sense to me. So if anyone out there could be soo kind to help me out with this issue I would be greatly appreciative. Thank you, Joey Doughly _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus From mouring at etoh.eviladmin.org Fri Aug 15 06:36:58 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 14 Aug 2003 15:36:58 -0500 (CDT) Subject: Monitor Modules In-Reply-To: Message-ID: They are part of Privilege Seperation code. The original site: http://www.citi.umich.edu/u/provos/ssh/privsep.html It seems off-line so check out the Google cache: http://216.239.57.104/search?q=cache:k-DwHPg0_iYJ:www.citi.umich.edu/u/provos/ssh/privsep.html+privilege+separation&hl=en&ie=UTF-8 - Ben On Thu, 14 Aug 2003, Joey Doughly wrote: > Hello Everyone, > I am porting ssh IBM's AS400 and am having a hard time with the monitor > modules (monitor.c, monitor_fdpass.c, monitor_mml.c, monitor_wrap.c) I first > of all don't understand what these modules are doing, and the parts I do > understand don't make sense to me. So if anyone out there could be soo kind > to help me out with this issue I would be greatly appreciative. > Thank you, > Joey Doughly > > _________________________________________________________________ > MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. > http://join.msn.com/?page=features/virus > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From pekkas at netcore.fi Fri Aug 15 06:46:51 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Thu, 14 Aug 2003 23:46:51 +0300 (EEST) Subject: setres[gu]id implicit decl warning on Linux glibc Message-ID: Hi, With recent snapshots, I noted a warning in compilation on Red Hat Linux 7.3 system with glibc 2.2.5: uidswap.c: In function `permanently_set_uid': uidswap.c:155: warning: implicit declaration of function `setresgid' uidswap.c:168: warning: implicit declaration of function `setresuid' The problem appears to be that these should be prototyped in unistd.h, but aren't. There are no prototype for these anywhere at all. The man page gives a hint that this is a long-standing bug/feature. On the other hand, the definitions seem to exist in glibc 2.3. I looked a bit how to fix this in openssh, but couldn't quickly figure a nice way to do it. It may not be worth a fix anyway. Just letting you folks know, if someone has a nice autoconf trick handy (for example) or is bothered by this warning.. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From dtucker at zip.com.au Fri Aug 15 09:39:58 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 15 Aug 2003 09:39:58 +1000 Subject: setres[gu]id implicit decl warning on Linux glibc References: Message-ID: <3F3C1DCE.CB8C721E@zip.com.au> Pekka Savola wrote: [snip] > uidswap.c: In function `permanently_set_uid': > uidswap.c:155: warning: implicit declaration of function `setresgid' > uidswap.c:168: warning: implicit declaration of function `setresuid' [snip] > Just letting you folks know, if someone has a nice autoconf trick handy > (for example) or is bothered by this warning.. You can check check the declaration before searching libraries for the function, eg: AC_CHECK_DECL(strsep, [AC_CHECK_FUNCS(strsep)]) I don't think it's worth the hassle to just suppress a warning as it will prevent the function from being used. (The strsep check is there because it resolves an actual problem on AIX). -- 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 pekkas at netcore.fi Fri Aug 15 16:49:31 2003 From: pekkas at netcore.fi (Pekka Savola) Date: Fri, 15 Aug 2003 09:49:31 +0300 (EEST) Subject: setres[gu]id implicit decl warning on Linux glibc In-Reply-To: <3F3C1DCE.CB8C721E@zip.com.au> Message-ID: On Fri, 15 Aug 2003, Darren Tucker wrote: > Pekka Savola wrote: > [snip] > > uidswap.c: In function `permanently_set_uid': > > uidswap.c:155: warning: implicit declaration of function `setresgid' > > uidswap.c:168: warning: implicit declaration of function `setresuid' > [snip] > > Just letting you folks know, if someone has a nice autoconf trick handy > > (for example) or is bothered by this warning.. > > You can check check the declaration before searching libraries for the > function, eg: > > AC_CHECK_DECL(strsep, [AC_CHECK_FUNCS(strsep)]) > > I don't think it's worth the hassle to just suppress a warning as it will > prevent the function from being used. Ok, thanks for the pointer. What I was looking for, though, was a slightly more advanced version of that; that is, "if declaration is not found but the function is, insert the declaration FOO in an includes file." > -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From dtucker at zip.com.au Fri Aug 15 17:07:18 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 15 Aug 2003 17:07:18 +1000 Subject: setres[gu]id implicit decl warning on Linux glibc References: Message-ID: <3F3C86A6.AAF8392@zip.com.au> Pekka Savola wrote: > What I was looking for, though, was a slightly more advanced version of > that; that is, "if declaration is not found but the function is, insert > the declaration FOO in an includes file." > You could probably do that but it's solving the symptom not the problem. Problem: Redhat libc has setresuid/setresgid but includes don't. Symptom: warnings compiling OpenSSH (and anything else using them). Solution: get Redhat to fix their headers (which apparently they have). OpenSSH has to bend over backwards in places to even compile or work around various vendor brokenness. I don't think bending further to suppress (valid!) warnings is something we should do. -- 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 jodo710 at hotmail.com Sat Aug 16 06:23:16 2003 From: jodo710 at hotmail.com (Joey Doughly) Date: Fri, 15 Aug 2003 20:23:16 +0000 Subject: Question about struct lastlog Message-ID: Hello everyone, I have run into a problem with struct lastlog and finding information about it, I don't know anything about this struct, the contents of this struct, which header it comes from. Can anyone direct me in to the right place to find more information about this struct. Thank you, Joey _________________________________________________________________ Tired of spam? Get advanced junk mail protection with MSN 8. http://join.msn.com/?page=features/junkmail From okir at suse.de Sat Aug 16 07:14:39 2003 From: okir at suse.de (Olaf Kirch) Date: Fri, 15 Aug 2003 23:14:39 +0200 Subject: OpenSC 0.8.0 Released Message-ID: <20030815211439.GA26640@suse.de> OpenSC Release 0.8.0 ==================== We are pleased to announce the availability of OpenSC 0.8.0. OpenSC provides a set of libraries and utilities to access smart cards. Its main focus is on cards that support cryptographic operations, and facilitate their use in security applications such as mail encryption, authentication, and digital signature. OpenSC can be used with the following applications and libraries: - Netscape Communicator and Mozilla (through its PKCS#11 module), for secure email (SMIME) and SSL authentication - OpenSSH, for user authentication - FreeSWAN, for authentication and key management - OpenSSL, for key and certificate storage, key generation and signing of certificate requests - GNUpg 1.9 (experimental), for key storage - Smart card login, through a PAM module - Using the included utilities, to perform RSA decryption and digitial signing OpenSC is capable of personalizing various types of smart cards, but also works with personalized cards such as the Finnish FINEID. OpenSC can currently be used on Linux, Windows and MacOS X. It supports PC/SC, CTAPI and OpenCT to talk to card terminals. Supported Hardware ================== The following card operating systems are supported at the moment (where read-only means that personalized cards can be used, but OpenSC does not provide personalization support for these). - Gemplus GPK cards (except Gemsafe) - Schlumberger Cryptoflex - CardOS/M4 (Aladdin eToken PRO, etc) - Starcos SPK (read-only) - Micardo (read-only) - MioCOS (read-only) - Setcos (read-only) - TCOS (read-only) Note that Java cards are not supported at the moment. Download ======== Source code is available from http://www.opensc.org/ A binary package for Windows is available as well. Mailing List ============ There is a mailing list (opensc-devel) for users and developers of OpenSC. For subscription instructions, please visit http://www.opensc.org. From magnus at mandarin.nu Sun Aug 17 01:45:10 2003 From: magnus at mandarin.nu (Magnus F) Date: Sat, 16 Aug 2003 17:45:10 +0200 Subject: sftp-server (secure) chroot patch? Message-ID: <000e01c3640d$621e2100$0201a8c0@black> Hello, I know this chroot issue has been brought up many times before on this list. I saw that the contribibuted chroot-patch was removed from the contrib directory because it always was out of date. The main reason was of course was that sftp-server has to be run as root to be able to do the chroot() call? Most of you are against chroot (since it isnt in the src) but I believe a lot of users have use for it. I dont think the solution is to use SSH Corps version. There are several chroot-patches available, like the chrootssh project and rssh (restricted shell sftp) and scponly. To make a long story short, none of these provide the ability to chroot sftp users in their homedir. That is, in these projects you are able to wonder around the chroot-tree /dev /bin /usr etc. I have found rssh to be usable because it ables you to restrict the user to sftp or scp, and shutdown ssh-access, however the user still can wonder around the chroot-tree. I did a bit of research and came to the conclusion that the chroot-call needed to be done in the src of sftp-server.c I found three patches that does it: http://www.alt219.com/software/sftp-server-chroot/ http://www.coding-zone.com/chroot+sftp-server.patch http://groups.google.com/groups?hl=sv&lr=&ie=UTF-8&oe=UTF-8&frame=right&th=45c783aa0a25801a&seekm=arc304%241v5l%241%40FreeBSD.csie.NCTU.edu.tw#link1 Problem one seems to be that setuid(getuid()); is reversable. Also better sanity checking before chroot is required. I have written a patch that (probably) is more secure than the ones I found. It uses uidswap functions to change uid & gid. Someone said the point behind subsystems was all the configuration for that subsystem are contained in the subsystem proper and not in sshd_config. Thats why I didnt add any config-changes to this patch. So if someone feels like it, maybe /etc/ssh/sftp-server.conf is a good place to config chroot. Since I don't have much C-knowledge, there might be errors in this patch (it works for me though). Please reply with the correct code. Thanks to Ben Lindstrom for helping me with this... I use this patch together with rssh, and I put the sftp-binary in the rssh chroot /ftproot/usr/local/libexec and its called by rssh-chroot-helper. When a user logins with sftp he will get chrooted to /ftproot/home/user. I shutdown access to scp and ssh, only sftp is allowed, so the user will never see the files in /ftproot To apply this patch on OpenSSH 3.6.1p2: - patch -p0 < sftp-server.patch - edit Makefile and include uidswap.o in sftp-server - make sftp-server - copy sftp-server into your chroot and set +s Regards Magnus "sftp-server.patch" 103 lines, 2521 characters --- openssh-3.6.1p2/sftp-server.c.org 2003-08-11 22:07:47.098650000 +0200 +++ openssh-3.6.1p2/sftp-server.c 2003-08-16 16:43:11.884356000 +0200 @@ -24,15 +24,24 @@ #include "includes.h" RCSID("$OpenBSD: sftp-server.c,v 1.41 2003/03/26 04:02:51 deraadt Exp $"); +#define CHROOT #include "buffer.h" #include "bufaux.h" #include "getput.h" #include "log.h" #include "xmalloc.h" - #include "sftp.h" #include "sftp-common.h" +#ifdef CHROOT +#include "uidswap.h" +#include +#include +#include +#include +#include +#endif /* CHROOT */ + /* helper */ #define get_int64() buffer_get_int64(&iqueue); #define get_int() buffer_get_int(&iqueue); @@ -62,6 +71,51 @@ Attrib attrib; }; +#ifdef CHROOT +static void +chroot_init(void) +{ + gid_t gidset[1]; + struct passwd *pw; + struct stat st; + + /* Sanity checking before chroot */ + if ((pw = getpwuid(getuid())) == NULL) + fatal("getpwuid failed for %u", (u_int)pw->pw_uid ); + + /* Sets passwd pointer to null */ + memset(pw->pw_passwd, 0, strlen(pw->pw_passwd)); + endpwent(); + + if (geteuid() != 0) + fatal("must be SUID root to use chroot feature"); + + if ((stat(pw->pw_dir, &st)) == -1) + fatal("cannot stat chroot directory %s: %s", pw->pw_dir, strerror(errno)); + + if (!S_ISDIR(st.st_mode)) + fatal("%s is not a directory: %s", pw->pw_dir, strerror(errno)); + + /* Drop our privileges */ + debug3("chroot user:group %u:%u", (u_int)pw->pw_uid, (u_int)pw->pw_gid); + + /* Change our root directory */ + if (chroot(pw->pw_dir) == -1) + fatal("chroot(\"%s\"): %s", pw->pw_dir, strerror(errno)); + + /* Change dir to prevent chroot break */ + if (chdir("/") == -1) + fatal("chdir(\"/\"): %s", strerror(errno)); + + gidset[0] = pw->pw_gid; + if (setgid(pw->pw_gid) < 0) + fatal("setgid failed for %u", (u_int)pw->pw_gid ); + if (setgroups(1, gidset) < 0) + fatal("setgroups: %.100s", strerror(errno)); + permanently_set_uid(pw); +} +#endif /* CHROOT */ + static int errno_to_portable(int unixerrno) { @@ -1028,15 +1082,17 @@ int in, out, max; ssize_t len, olen, set_size; - /* XXX should use getopt */ +#ifdef DEBUG_SFTP-SERVER + log_init("sftp-server", SYSLOG_LEVEL_DEBUG3, SYSLOG_FACILITY_AUTH, 0); +#endif + +#ifdef CHROOT + chroot_init(); +#endif __progname = get_progname(av[0]); handle_init(); -#ifdef DEBUG_SFTP_SERVER - log_init("sftp-server", SYSLOG_LEVEL_DEBUG1, SYSLOG_FACILITY_AUTH, 0); -#endif - in = dup(STDIN_FILENO); out = dup(STDOUT_FILENO); From magnus at mandarin.nu Sun Aug 17 03:40:37 2003 From: magnus at mandarin.nu (Magnus F) Date: Sat, 16 Aug 2003 19:40:37 +0200 Subject: sftp-server (secure) chroot patch, comment fix Message-ID: <005f01c3641d$82ae0e20$0201a8c0@black> Accidently removed XXX comment. New patch below. Regards Magnus --- openssh-3.6.1p2/sftp-server.c.org 2003-08-11 22:07:47.098650000 +0200 +++ openssh-3.6.1p2/sftp-server.c 2003-08-16 19:07:14.273582000 +0200 @@ -24,15 +24,24 @@ #include "includes.h" RCSID("$OpenBSD: sftp-server.c,v 1.41 2003/03/26 04:02:51 deraadt Exp $"); +#define CHROOT #include "buffer.h" #include "bufaux.h" #include "getput.h" #include "log.h" #include "xmalloc.h" - #include "sftp.h" #include "sftp-common.h" +#ifdef CHROOT +#include "uidswap.h" +#include +#include +#include +#include +#include +#endif /* CHROOT */ + /* helper */ #define get_int64() buffer_get_int64(&iqueue); #define get_int() buffer_get_int(&iqueue); @@ -62,6 +71,51 @@ Attrib attrib; }; +#ifdef CHROOT +static void +chroot_init(void) +{ + gid_t gidset[1]; + struct passwd *pw; + struct stat st; + + /* Sanity checking before chroot */ + if ((pw = getpwuid(getuid())) == NULL) + fatal("getpwuid failed for %u", (u_int)pw->pw_uid ); + + /* Sets passwd pointer to null */ + memset(pw->pw_passwd, 0, strlen(pw->pw_passwd)); + endpwent(); + + if (geteuid() != 0) + fatal("must be SUID root to use chroot feature"); + + if ((stat(pw->pw_dir, &st)) == -1) + fatal("cannot stat chroot directory %s: %s", pw->pw_dir, strerror(errno)); + + if (!S_ISDIR(st.st_mode)) + fatal("%s is not a directory: %s", pw->pw_dir, strerror(errno)); + + /* Drop our privileges */ + debug3("chroot user:group %u:%u", (u_int)pw->pw_uid, (u_int)pw->pw_gid); + + /* Change our root directory */ + if (chroot(pw->pw_dir) == -1) + fatal("chroot(\"%s\"): %s", pw->pw_dir, strerror(errno)); + + /* Change dir to prevent chroot break */ + if (chdir("/") == -1) + fatal("chdir(\"/\"): %s", strerror(errno)); + + gidset[0] = pw->pw_gid; + if (setgid(pw->pw_gid) < 0) + fatal("setgid failed for %u", (u_int)pw->pw_gid ); + if (setgroups(1, gidset) < 0) + fatal("setgroups: %.100s", strerror(errno)); + permanently_set_uid(pw); +} +#endif /* CHROOT */ + static int errno_to_portable(int unixerrno) { @@ -1028,15 +1082,19 @@ int in, out, max; ssize_t len, olen, set_size; +#ifdef DEBUG_SFTP-SERVER + log_init("sftp-server", SYSLOG_LEVEL_DEBUG3, SYSLOG_FACILITY_AUTH, 0); +#endif + +#ifdef CHROOT + chroot_init(); +#endif + /* XXX should use getopt */ __progname = get_progname(av[0]); handle_init(); -#ifdef DEBUG_SFTP_SERVER - log_init("sftp-server", SYSLOG_LEVEL_DEBUG1, SYSLOG_FACILITY_AUTH, 0); -#endif - in = dup(STDIN_FILENO); out = dup(STDOUT_FILENO); From dominique.fournier at grenoble.cnrs.fr Mon Aug 18 19:46:05 2003 From: dominique.fournier at grenoble.cnrs.fr (Dominique Fournier) Date: Mon, 18 Aug 2003 11:46:05 +0200 Subject: SFTP Logging in openssh-3.6.1p2 Message-ID: <3F40A05D.50605@grenoble.cnrs.fr> Hello, I try to log the file transferts, connections, errors on sftp server with openssh-3.6.1p2. I have seen some patches, but not for this release. Is it possible to put the logging facility in the standard code ? Where can I find the patch for the last version ? Thanks for your help and your good work. Dominique From markus at openbsd.org Tue Aug 19 01:05:37 2003 From: markus at openbsd.org (Markus Friedl) Date: Mon, 18 Aug 2003 17:05:37 +0200 Subject: SFTP Logging in openssh-3.6.1p2 In-Reply-To: <3F40A05D.50605@grenoble.cnrs.fr> References: <3F40A05D.50605@grenoble.cnrs.fr> Message-ID: <20030818150537.GB17347@folly> On Mon, Aug 18, 2003 at 11:46:05AM +0200, Dominique Fournier wrote: > Is it possible to put the logging facility in the standard code ? no. From markus at openbsd.org Tue Aug 19 01:06:12 2003 From: markus at openbsd.org (Markus Friedl) Date: Mon, 18 Aug 2003 17:06:12 +0200 Subject: SFTP Logging in openssh-3.6.1p2 In-Reply-To: <3F40A05D.50605@grenoble.cnrs.fr> References: <3F40A05D.50605@grenoble.cnrs.fr> Message-ID: <20030818150612.GC17347@folly> On Mon, Aug 18, 2003 at 11:46:05AM +0200, Dominique Fournier wrote: > Is it possible to put the logging facility in the standard code ? no, the patches are incomplete, like my last email. From v_t_m at seznam.cz Tue Aug 19 05:10:27 2003 From: v_t_m at seznam.cz (=?iso-8859-2?Q?V=E1clav=20Tomec?=) Date: Mon, 18 Aug 2003 21:10:27 +0200 (CEST) Subject: PATCH: Auth selection Message-ID: <51760.51906-22970-977267982-1061234529@seznam.cz> Hello all, on website http://sweb.cz/v_t_m/ the Auth selection patch is available. This patch allows to specify AllowUsers, DenyUsers for individual authentications (hostbased, publickey, password, keyboard-interactive, kerberos, kerberos_or_local, gss, securid-1 at ssh.com). By this you can define authentication methods for each user. All configuration options are mentioned in file sshd_config. Their usage is the same like with AllowUsers, DenyUsers. The patch is designed for SSH2. Vaclav ____________________________________________________________ Sexy leto naplno! Jednodenni kontaktn? cocky Focus Dailies. Akcni nabidka! http://ad2.seznam.cz/redir.cgi?instance=57292%26url=http://www.cz.cibavision.com/ From Frank.Beckmann at vodafone.com Tue Aug 19 05:33:08 2003 From: Frank.Beckmann at vodafone.com (Frank Beckmann) Date: Mon, 18 Aug 2003 21:33:08 +0200 Subject: wrong return codes Message-ID: <3F4129F4.5020304@vodafone.com> Hello we have a Problem with wrong Return Codes in some SSH Relases (3.1p1 and 3.6.1p2) under Solaris (6 and 8) Example: ssh system ls /xy echo $? The file exist or not ... Somtimes the ssh give a wrong return code Is the SSH compiled with the SUN WS Compiler (Versions 6 and 7) the supply more wrong return codes The problem is not so strong when we use the gnu-gcc compiler. the error comes sporadic (not so many errors as a sun ws compiled version). A Developer say to me that can be a Timing Problem... He says somthing with Race (Time!?) Conditons or so... The Problem is strong on Maschine with high load (Multi CPU Sparc Systems) Im not a Programmer :-) In the /var/adm/messages we have many errors Jun 22 03:14:31 d2cred2 sshd[20557]: error: Strange, wait returned pid 20648, expected 20762 Jun 22 03:14:33 d2cred2 sshd[21044]: error: session_by_pid: unknown pid 21190 Jun 22 03:14:38 d2cred2 sshd[15969]: error: Strange, wait returned pid 16649, expected 18111 Is this a seperate Problem ? We want to replace the rsh commands in scripts, but we dont can do this with this problem. Sorry for my bad bad English ;-) Greetings from Germany Frank From xy12 at rock.com Tue Aug 19 10:12:12 2003 From: xy12 at rock.com (767568751775541) Date: Mon, 18 Aug 2003 20:12:12 -0400 Subject: Press release Message-ID: <20030819000946.E577E27C18B@shitei.mindrot.org> CANADA BOOKS 36 Felix Renaud Aylmer Qc Canada J9H 7C1 (819) 682-7983 PRESS RELEASE CANADIAN SUBSIDY DIRECTORY YEAR 2003 EDITION Legal Deposit-National Library of Canada ISBN 2-922870-05-7 The new revised edition of the Canadian Subsidy Directory 2003 is now available. The new edition is the most complete and affordable reference for anyone looking for financial support. It is deemed to be the perfect tool for new or existing businesses, individual ventures, foundations and associations. This Publication contains more than 2000 direct and indirect financial subsidies, grants and loans offered by government departments and agencies, foundations, associations and organisations. In this new 2003 edition all programs are well described. The Canadian Subsidy Directory is the most comprehensive tool to start up a business, improve existent activities, set up a business plan, or obtain assistance from experts in fields such as: Industry, transport, agriculture, communications, municipal infrastructure, education, import-export, labor, construction and renovation, the service sector, hi-tech industries, research and development, joint ventures, arts, cinema, theatre, music and recording industry, the self employed, contests, and new talents. Assistance from and for foundations and associations, guidance to prepare a business plan, market surveys, computers, and much more! The Canadian Subsidy Directory is sold $ 69.95, to obtain a copy please call: Canada Books (819) 682-7983 From erikvcl at silcom.com Tue Aug 19 10:22:00 2003 From: erikvcl at silcom.com (erikvcl at silcom.com) Date: Mon, 18 Aug 2003 17:22:00 -0700 (PDT) Subject: Partial Authentication in OpenSSH Message-ID: Hi, Pardon me if this has been discussed recently, I'm new to the list. I am interested in partial authentication in OpenSSH. I have modified Maciej Bogucki's patch that was based on a patch by Carson Gaspar for a pre-privilege separation version of SSH. My modifications have resulted in a basically working partial authentication system, but my patch is quite a hack. As I have not developed on SSH before, I am not familiar with all of the security ramifications that my patch can have. And even beyond security, there are some limitations of my patch compared to the original patch for pre-privilege separation OpenSSH. So my question is whether or not partial authentication is being actively developed, whether or not any developers on this list would be interested in seeing my patch and helping to mold it into something that can be used in a future OpenSSH version, and if there is any interest in partial authentication in general. Thanks in advance. Erik. From markus at openbsd.org Tue Aug 19 17:39:14 2003 From: markus at openbsd.org (Markus Friedl) Date: Tue, 19 Aug 2003 09:39:14 +0200 Subject: wrong return codes In-Reply-To: <3F4129F4.5020304@vodafone.com> References: <3F4129F4.5020304@vodafone.com> Message-ID: <20030819073914.GA20444@folly> On Mon, Aug 18, 2003 at 09:33:08PM +0200, Frank Beckmann wrote: > Hello > > we have a Problem with wrong Return Codes in some SSH Relases (3.1p1 and > 3.6.1p2) under Solaris (6 and 8) > Example: > > ssh system ls /xy > echo $? > The file exist or not ... > Somtimes the ssh give a wrong return code can you reproduce this? > Jun 22 03:14:31 d2cred2 sshd[20557]: error: Strange, wait returned pid > 20648, expected 20762 > Jun 22 03:14:33 d2cred2 sshd[21044]: error: session_by_pid: unknown pid > 21190 > Jun 22 03:14:38 d2cred2 sshd[15969]: error: Strange, wait returned pid > 16649, expected 18111 does this always happen when a wrong return code is given? can you trace the pids? what process is 20648? and 20762? From philipp.marek at bmlv.gv.at Tue Aug 19 18:14:35 2003 From: philipp.marek at bmlv.gv.at (Ph. Marek) Date: Tue, 19 Aug 2003 10:14:35 +0200 Subject: splitting big authorized_keys files Message-ID: <200308191014.36449.philipp.marek@bmlv.gv.at> Hello everybody, I have a problem. You may have the answer :-) I'd like to use openssh for an authentication service. But that gives me a user, whose ~/.ssh/authorized_keys file has about 15000 entries. With about 300 characters per line I'd get 4,5 MB of data. I believe that this length of file could lead to performance issues; so I'm looking for solutions. I already saw the possibility of using "%u" or "%h" in sshd_conf/AuthorizedKeysFile; but that's system-wide and not for this one user. And %u wouldn't differentiate between my users, as the target-user is always the same. One solution would be to have a %2p, which would take 2 characters of the public-key (preferably the last two - the first two won't differ much :-) and use that in a AuthorizedKeysFile-statement, and leaving AuthorizedKeys2File as-is - so the normal login procedure would go and use ~/.ssh/authorized_keys2 as usual, but it would try and use eg for "%h/.ssh/authorized_keys_%2p" a file ~/.ssh/authorized_keys_A2 or whatever and find there only the matching subset of keys. So the authorized_keys-file could be split along multiples of 16 (ie., one hex-character); so /16, /256, /4096, ... This way I could split my user-list in 256 files of about 60 entries each; that could be handled, I think. Or, another, possibly better, solution: have sshd generate an index for authorized_keys automatically (based on file-date). So sshd looks for the public key in the index, reads the index for the authorized_keys file, seeks there, and uses the key. If sshd detects that the index is older than the file (or has another mtime stored), the index gets regenerated. Can you please share your experiences regarding big authorized_keys-files with me? Any hints, tips or patches (:-) welcome. Regards, Phil From markus at openbsd.org Tue Aug 19 18:30:19 2003 From: markus at openbsd.org (Markus Friedl) Date: Tue, 19 Aug 2003 10:30:19 +0200 Subject: splitting big authorized_keys files In-Reply-To: <200308191014.36449.philipp.marek@bmlv.gv.at> References: <200308191014.36449.philipp.marek@bmlv.gv.at> Message-ID: <20030819083019.GA16717@folly> On Tue, Aug 19, 2003 at 10:14:35AM +0200, Ph. Marek wrote: > But that gives me a user, whose ~/.ssh/authorized_keys file has about 15000 > entries. the current scheme was not intented for 15000 entries, you should try to switch some database... From Stephan.Hendl at lds.brandenburg.de Tue Aug 19 20:00:28 2003 From: Stephan.Hendl at lds.brandenburg.de (Stephan Hendl) Date: Tue, 19 Aug 2003 12:00:28 +0200 Subject: chroot-patch for 3.6.1p1? Message-ID: Hi all, I am looking for a chroot-patch like it was available for the 3.5p1 version. Does anybody has such a patch? Because chroot doesn't work with 3.6.1p1 under Reliant Unix 5.45 from Fujitsu-Siemens. regards Stephan Dr. Stephan Hendl Systemmanagement ----------------------------------- Landesbetrieb f?r Datenverarbeitung und Statistik Land Brandenburg Adresse: 14467 Potsdam, Dortustr. 46 Telefon: +49-(0)331 39-471 Fax:: +49-(0)331 27548-1187 Mobil: +49-(0)160 90 645 893 EMail: Stephan.Hendl at lds.brandenburg.de Internet: http://www.lds-bb.de From des at des.no Tue Aug 19 21:07:03 2003 From: des at des.no (Dag-Erling =?iso-8859-1?q?Sm=F8rgrav?=) Date: Tue, 19 Aug 2003 13:07:03 +0200 Subject: man page nits Message-ID: The attached patch quotes question marks in "Ql ?" in the man pages to avoid stuff like "`*' and `'? serve as wildcards" (note the misplaced single quote). DES -- Dag-Erling Sm?rgrav - des at des.no -------------- next part -------------- A non-text attachment was scrubbed... Name: sshman.diff Type: text/x-patch Size: 2011 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030819/2f8b8fd7/attachment.bin From smichaud at pobox.com Wed Aug 20 04:51:02 2003 From: smichaud at pobox.com (Steven Michaud) Date: Tue, 19 Aug 2003 13:51:02 -0500 (CDT) Subject: updated gssapi diff Message-ID: I've been testing the code posted by Jakob Schlyter (2003-08-10 14:43:52), as amended by Frank Cusack (2003-08-12 18:05:11) and Douglas Engert (2003-08-12 18:55:30). The code worked fine, but raised some issues that people who are used to Simon Wilkinson's patch will need to be aware of. (I didn't bother to test without Douglas Engert's patch. Without it MIT support is broken and the code won't even compile (krb5_cc_gen_new() has a different number of parameters in the MIT libraries than in the Heimdal ones). And it just adds support for per-session caches that's already provided for those who use the Heimdal libraries.) (I tested on Solaris 8, so I ended up patching against one of the portable snapshots -- openssh-SNAP-20030814.tar.gz. To make sure all the code went to the right place, I did my patch by hand. I also patched in a few other places (notably configure.ac) that aren't, strictly speaking, relevant to the code posted by Jakob Schlyter. In all my tests I linked against either the MIT 1.3.1 libraries (the shared ones) or the Heimdal 0.6 libraries. None of my tests used PAM. My KDC is MIT 1.3.1, also running on Solaris 8.) Basically, I tested that the ssh client compiled with Jakob Schlyter's code (as described above) and linked against either the MIT libraries or the Heimdal libraries, worked with sshd from each of the following "packages", linked against either the MIT libraries or the Heimdal libraries: 1) openssh-SNAP-20030814, patched as I have described 2) OpenSSH 3.6.1p2 patched with Simon Wilkinson's patch 3) OpenSSH 3.5p1 patched with Simon Wilkinson's patch (to make this I'd hand-upgraded Simon's patch from 3.4p1) And I tested that the ssh client from each of these packages (linked against either the MIT libraries or the Heimdal libraries) worked with the sshd from the first of them (linked against either the MIT libraries or the Heimdal libraries). The functionality I tested was the following: 1) GSSAPI authentication 2) "Kerberos password" authentication 3) "Unix password" authentication As I've said, everything worked fine -- including (where applicable) credential forwarding and per-session caches. But I lost a couple hours discovering that GSSAPIAuthentication (in sshd_config) and GSSAPIDelegateCredentials (in ssh_config) are no longer on by default. And I noticed that you need a host key even when doing GSSAPI authentication -- I guess the ability to do without one was lost with the GSSAPI key exchange code. The other things I noticed aren't really relevant to a test of Jakob Schlyter's code, but I think two are worth mentioning. I had to make the following change to get the snapshot to link against the Heimdal libraries: diff -u -r -N --exclude configure --exclude config.h.in src.old/openbsd-compat/bsd-misc.h src/openbsd-compat/bsd-misc.h --- src.old/openbsd-compat/bsd-misc.h Mon Aug 18 19:53:59 2003 +++ src/openbsd-compat/bsd-misc.h Mon Aug 18 19:53:51 2003 @@ -29,6 +29,11 @@ #include "config.h" +/* Resolve name conflict with libroken */ +#ifdef HEIMDAL +#define get_progname get_progname_x +#endif + char *get_progname(char *); #ifndef HAVE_SETSID And I discovered that part of the SSH2 KRB5 auth code is badly broken. (I experienced crashes when KerberosAuthentication was enabled, no Kerberos credentials were present, and I used the snapshot's ssh. Apparently this ssh falls back to KRB5 auth when GSSAPI auth fails.) Jakob's message says that the KRB5 auth code will be removed if the GSSAPI code goes in. But perhaps it's still worth mentioning how I fixed this problem: diff -u -r -N --exclude configure --exclude config.h.in src.old/sshconnect2.c src/sshconnect2.c --- src.old/sshconnect2.c Mon Aug 18 19:55:19 2003 +++ src/sshconnect2.c Mon Aug 18 19:55:10 2003 @@ -1378,7 +1378,6 @@ static int ssh_krb5_helper(krb5_data *ap, krb5_context *context) { - krb5_context xcontext = NULL; /* XXX share with ssh1 */ krb5_auth_context xauth_context = NULL; krb5_auth_context *auth_context; krb5_error_code problem; @@ -1389,8 +1388,8 @@ int ret; memset(ap, 0, sizeof(*ap)); + *context = NULL; - context = &xcontext; auth_context = &xauth_context; problem = krb5_init_context(context); @@ -1401,13 +1400,13 @@ } tkfile = krb5_cc_default_name(*context); - if (strncmp(tkfile, "FILE:", 5) == 0) + if (strncmp(tkfile, "FILE:", 5) == 0) { tkfile += 5; - - if (stat(tkfile, &buf) == 0 && getuid() != buf.st_uid) { - debug("Kerberos v5: could not get default ccache (permission denied)."); - ret = 0; - goto out; + if (stat(tkfile, &buf) == 0 && getuid() != buf.st_uid) { + debug("Kerberos v5: could not get default ccache (permission denied)."); + ret = 0; + goto out; + } } problem = krb5_cc_default(*context, &ccache); @@ -1442,10 +1441,10 @@ userauth_kerberos(Authctxt *authctxt) { krb5_data ap; - krb5_context *context; + krb5_context context; int ret = 0; - if (ssh_krb5_helper(&ap, context) == 0) + if (ssh_krb5_helper(&ap, &context) == 0) goto out; packet_start(SSH2_MSG_USERAUTH_REQUEST); @@ -1458,13 +1457,13 @@ #ifdef HEIMDAL krb5_data_free(&ap); #else - krb5_free_data_contents(*context, &ap); + krb5_free_data_contents(context, &ap); #endif ret = 1; out: - if (*context) - krb5_free_context(*context); + if (context) + krb5_free_context(context); return ret; } #endif From jmknoble at pobox.com Wed Aug 20 05:25:44 2003 From: jmknoble at pobox.com (Jim Knoble) Date: Tue, 19 Aug 2003 15:25:44 -0400 Subject: splitting big authorized_keys files In-Reply-To: <20030819083019.GA16717@folly> References: <200308191014.36449.philipp.marek@bmlv.gv.at> <20030819083019.GA16717@folly> Message-ID: <20030819192543.GL6982@crawfish.ais.com> Circa 2003-08-19 10:30:19 +0200 dixit Markus Friedl: : On Tue, Aug 19, 2003 at 10:14:35AM +0200, Ph. Marek wrote: : > But that gives me a user, whose ~/.ssh/authorized_keys file has about 15000 : > entries. : : the current scheme was not intented for 15000 entries, you : should try to switch some database... For example: http://cr.yp.to/cdb.html The CDB API is very simple and relatively lightweight, and it's designed for situations where the database doesn't change very frequently, which i imagine is the case for your 15000 pubkeys. Additionally, the CDB tools allow you to maintain your keys via a text file can easily be put under revision control. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) "We have guided missiles and misguided men." --Martin Luther King, Jr. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 256 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030819/049ea203/attachment.bin From Kiran.Rao at idt.com Wed Aug 20 09:58:00 2003 From: Kiran.Rao at idt.com (Rao, Kiran) Date: Tue, 19 Aug 2003 16:58:00 -0700 Subject: seed_rng Message-ID: Hello, I am trying to port Openssh to MIPS platform. I am facing some problems with the function seed_rng(). I get a segmentation fault when this function is executed. Any suggestion will be appreciated. Kiran. ******************************************************* Kiran R Rao Software Engineer Integrated Device Technology,Inc. (408)-330-1835 ******************************************************** From mouring at etoh.eviladmin.org Wed Aug 20 10:52:19 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Tue, 19 Aug 2003 19:52:19 -0500 (CDT) Subject: seed_rng In-Reply-To: Message-ID: Based on this little information I suggest asking a fortune teller. =) Maybe a backtrace or a ssh -vvv (or sshd -ddd since you are not stating client or server). Maybe knowledge if your OS supports /dev/random, or your using the build-in entropy help or prngd/egd. We need a lot more information to even start to help. - Ben On Tue, 19 Aug 2003, Rao, Kiran wrote: > Hello, > > I am trying to port Openssh to MIPS platform. I am facing some problems > with the function seed_rng(). I get a segmentation fault when this function > is executed. > Any suggestion will be appreciated. > > Kiran. > > ******************************************************* > Kiran R Rao > Software Engineer > Integrated Device Technology,Inc. > (408)-330-1835 > ******************************************************** > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From philipp.marek at bmlv.gv.at Thu Aug 21 15:36:49 2003 From: philipp.marek at bmlv.gv.at (Ph. Marek) Date: Thu, 21 Aug 2003 07:36:49 +0200 Subject: splitting big authorized_keys files In-Reply-To: <20030819083019.GA16717@folly> References: <200308191014.36449.philipp.marek@bmlv.gv.at> <20030819083019.GA16717@folly> Message-ID: <200308210736.49568.philipp.marek@bmlv.gv.at> > > But that gives me a user, whose ~/.ssh/authorized_keys file has about > > 15000 entries. > > the current scheme was not intented for 15000 entries, you > should try to switch some database... That's what I asked for - an index for that file. That could be useful for the known_hosts too, I believe. From markus at openbsd.org Thu Aug 21 17:59:39 2003 From: markus at openbsd.org (Markus Friedl) Date: Thu, 21 Aug 2003 09:59:39 +0200 Subject: updated gssapi diff In-Reply-To: References: Message-ID: <20030821075939.GA3065@folly> thanks for the feedback, and just as a FYI for other readers on this list: if these patches don't go into openssh within 1 week, then they'll miss the next release and there won't be gss support for another half year. From mario.Ohnewald at gmx.de Thu Aug 21 18:04:02 2003 From: mario.Ohnewald at gmx.de (Mario Ohnewald) Date: Thu, 21 Aug 2003 10:04:02 +0200 (MEST) Subject: Smartcard: sectok compiler error Message-ID: <22610.1061453042@www18.gmx.net> Hello list! I am trying to get my chipdrive micro smartcard working with openssh. I read the README.smartcard, but i got stuck with sectok. It might be a little offtopic but i am totally stuck! After it compiled libsectok without the -Bforcearchive flag i tried to compile sectok: [root at box sectok-20020524]# make gcc -o sectok main.o cmds.o cyberflex.o ../libsectok/libsectok.a -lcrypto cmds.o: In function `reset': /home/mohnewald/sectok-20020524/cmds.c:158: undefined reference to `optreset' cmds.o: In function `apdu': /home/mohnewald/sectok-20020524/cmds.c:233: undefined reference to `optreset' cmds.o: In function `selfid': /home/mohnewald/sectok-20020524/cmds.c:277: undefined reference to `optreset' cmds.o: In function `dread': /home/mohnewald/sectok-20020524/cmds.c:387: undefined reference to `optreset' cmds.o: In function `vfypin': /home/mohnewald/sectok-20020524/cmds.c:528: undefined reference to `optreset' cmds.o:/home/mohnewald/sectok-20020524/cmds.c:565: more undefined references to `optreset' follow collect2: ld returned 1 exit status make: *** [sectok] Error 1 My Makefile: ------------------------------------- # Standard installation: #INCLUDES= #LIBS= -lsectok -lcrypto # For building locally (libsectok not installed) #INCLUDES= -I../libsectok LIBS= ../libsectok/libsectok.a -lcrypto # If crypto is included with openssl you might need this #INCLUDES= -I/usr/include/openssl # You shouldn't have to change anything below this line TARGETS= sectok SRC= main.c cmds.c cyberflex.c OBJ= $(SRC:.c=.o) CC= gcc CFLAGS= -g -Wall -I../libsectok/ INSTALL= install PREFIX= /usr/local RELEASE= sectok-`date "+%Y%m%d"` ...snip... any ideas why i get the error? Cheers, Mario -- COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test -------------------------------------------------- 1. GMX TopMail - Platz 1 und Testsieger! 2. GMX ProMail - Platz 2 und Preis-Qualit?tssieger! 3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post From markus at openbsd.org Thu Aug 21 18:30:22 2003 From: markus at openbsd.org (Markus Friedl) Date: Thu, 21 Aug 2003 10:30:22 +0200 Subject: Smartcard: sectok compiler error In-Reply-To: <22610.1061453042@www18.gmx.net> References: <22610.1061453042@www18.gmx.net> Message-ID: <20030821083022.GA30612@folly> On Thu, Aug 21, 2003 at 10:04:02AM +0200, Mario Ohnewald wrote: > Hello list! > I am trying to get my chipdrive micro smartcard working with openssh. > I read the README.smartcard, but i got stuck with sectok. > It might be a little offtopic but i am totally stuck! > > After it compiled libsectok without the -Bforcearchive flag i tried to > compile sectok: > > [root at box sectok-20020524]# make > gcc -o sectok main.o cmds.o cyberflex.o ../libsectok/libsectok.a -lcrypto > cmds.o: In function `reset': > /home/mohnewald/sectok-20020524/cmds.c:158: undefined reference to > `optreset' your getopt does not support optreset, check the getopt from openssh's compat dir. From mario.Ohnewald at gmx.de Thu Aug 21 20:53:22 2003 From: mario.Ohnewald at gmx.de (Mario Ohnewald) Date: Thu, 21 Aug 2003 12:53:22 +0200 (MEST) Subject: OT: smartcard sectok - 0608 error loading driver Message-ID: <32314.1061463202@www39.gmx.net> Hello! I know this is a bit off topic but its hard to get some help in this case. the driver for my Towitoko Chipdrive USB works: Aug 21 12:33:12 idefix pcscd: eventhandler.c:380 EHSpawnEventHandler: Card Removed From Towitoko Chipdrive USB 0 0 Aug 21 12:33:16 idefix pcscd: eventhandler.c:468 EHSpawnEventHandler: Card inserted into Towitoko Chipdrive USB 0 0 Aug 21 12:33:16 idefix pcscd: EHSpawnEventHandler: Card ATR: 3B 95 15 40 FF 68 01 02 02 04 now i am trying to do point 3 from the README.smartcard (3) load the Java Cardlet to the Cyberflex card: $ sectok sectok> login -d sectok> jload /usr/libdata/ssh/Ssh.bin sectok> quit thats what i get: # sectok sectok> login -d 0608 error loading driver sectok -0 till -3 did not work either. Can anyone give me a tip/hint why it wont load the driver? the card is currently empty, but i guess that?s not the problem. Thanks a lot! Mario -- COMPUTERBILD 15/03: Premium-e-mail-Dienste im Test -------------------------------------------------- 1. GMX TopMail - Platz 1 und Testsieger! 2. GMX ProMail - Platz 2 und Preis-Qualit?tssieger! 3. Arcor - 4. web.de - 5. T-Online - 6. freenet.de - 7. daybyday - 8. e-Post From deengert at anl.gov Fri Aug 22 00:34:01 2003 From: deengert at anl.gov (Douglas E. Engert) Date: Thu, 21 Aug 2003 09:34:01 -0500 Subject: updated gssapi diff References: <20030821075939.GA3065@folly> Message-ID: <3F44D859.449A0A9F@anl.gov> Markus Friedl wrote: > > thanks for the feedback, and just as a FYI for other readers > on this list: if these patches don't go into openssh within 1 week, > then they'll miss the next release and there won't be gss support > for another half year. Jakob Schlyter appears to be driving the process, is there something else standing in the way? I sent in the patch to allow the gssapi to use the MIT GSSAPI, I assume Jakob is including it as well. The rest of the patches as provided by Jakob looked good to me. > > _______________________________________________ > 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 Fri Aug 22 00:50:12 2003 From: markus at openbsd.org (Markus Friedl) Date: Thu, 21 Aug 2003 16:50:12 +0200 Subject: updated gssapi diff In-Reply-To: <3F44D859.449A0A9F@anl.gov> References: <20030821075939.GA3065@folly> <3F44D859.449A0A9F@anl.gov> Message-ID: <20030821145011.GA11804@folly> On Thu, Aug 21, 2003 at 09:34:01AM -0500, Douglas E. Engert wrote: > Jakob Schlyter appears to be driving the process, he's away, so I'm driving the process. > is there something > else standing in the way? lack of feedback. > I sent in the patch to allow the gssapi to use the MIT GSSAPI, > I assume Jakob is including it as well. The rest of the patches as > provided by Jakob looked good to me. thanks. From smichaud at pobox.com Fri Aug 22 02:30:49 2003 From: smichaud at pobox.com (Steven Michaud) Date: Thu, 21 Aug 2003 11:30:49 -0500 (CDT) Subject: updated gssapi diff Message-ID: > lack of feedback. Are there specific tests/tasks you'd like to see done before the code is released, or would you just like to hear from more sysadmins/developers who use Simon Wilkinson's patch? On Thu, Aug 21, 2003 at 14:50:12 GMT Markus Friedl wrote: > On Thu, Aug 21, 2003 at 09:34:01AM -0500, Douglas E. Engert wrote: > > Jakob Schlyter appears to be driving the process, > > he's away, so I'm driving the process. > > > is there something > > else standing in the way? > > lack of feedback. > > > I sent in the patch to allow the gssapi to use the MIT GSSAPI, > > I assume Jakob is including it as well. The rest of the patches as > > provided by Jakob looked good to me. > > thanks. From erikvcl at silcom.com Fri Aug 22 10:33:32 2003 From: erikvcl at silcom.com (erikvcl at silcom.com) Date: Thu, 21 Aug 2003 17:33:32 -0700 (PDT) Subject: No interest in partial auth? Message-ID: Hi, I don't mean to be annoying, but it seems like there isn't any interest in partial authentication. Is this true? It's not a future plan for OpenSSH to have this feature? I'd just like to know if I'm on my own or not. Thanks Erik. From mouring at etoh.eviladmin.org Fri Aug 22 10:50:52 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 21 Aug 2003 19:50:52 -0500 (CDT) Subject: No interest in partial auth? In-Reply-To: Message-ID: No plans for it in the 3.7 release no. - Ben On Thu, 21 Aug 2003 erikvcl at silcom.com wrote: > Hi, > > I don't mean to be annoying, but it seems like there isn't any interest in > partial authentication. Is this true? It's not a future plan for OpenSSH > to have this feature? > > I'd just like to know if I'm on my own or not. > > Thanks > > Erik. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From carson at taltos.org Fri Aug 22 11:10:10 2003 From: carson at taltos.org (Carson Gaspar) Date: Thu, 21 Aug 2003 21:10:10 -0400 Subject: No interest in partial auth? In-Reply-To: References: Message-ID: <262731328.1061500210@[192.168.20.2]> --On Thursday, August 21, 2003 5:33 PM -0700 erikvcl at silcom.com wrote: > I don't mean to be annoying, but it seems like there isn't any interest > in partial authentication. Is this true? It's not a future plan for > OpenSSH to have this feature? > > I'd just like to know if I'm on my own or not. I was told that the functionality I added was "too complex", and that the most they'd accept was a bitfield (as opposed to my ordered list). As that was useless for my needs, I gave up on it ever being added to the mainline OpenSSH code. Once I left the employer that I had developed it for, I stopped maintaining the code. Good luck convincing the Cabal that it serves a useful purpose - I couldn't, and I'm unwilling to take on the burden of maintaining a forked project. -- Carson From openssh-dev at joelweber.com Fri Aug 22 12:54:33 2003 From: openssh-dev at joelweber.com (Joel N. Weber II) Date: Thu, 21 Aug 2003 22:54:33 -0400 Subject: No interest in partial auth? In-Reply-To: <262731328.1061500210@[192.168.20.2]> (message from Carson Gaspar on Thu, 21 Aug 2003 21:10:10 -0400) References: <262731328.1061500210@[192.168.20.2]> Message-ID: > I was told that the functionality I added was "too complex", and that the > most they'd accept was a bitfield (as opposed to my ordered list). As that > was useless for my needs, I gave up on it ever being added to the mainline > OpenSSH code. Once I left the employer that I had developed it for, I > stopped maintaining the code. If that code has a reasonable license, I'd be interested in taking a look at it. > Good luck convincing the Cabal that it serves a useful purpose - I > couldn't, and I'm unwilling to take on the burden of maintaining a forked > project. I have some interest in this sort of thing, because I'd like to be able to use s/key logins that are also protected by a password, so that I can carry around a list of s/key passwords and still have some minimal protection against a stolen wallet. However, I'm not entirely convinced that a smartcard wouldn't be just as good a solution, if I can get all the bits for that to work. Given the openbsd folk's unwillingness to merge the gss key exchange stuff, it's obvious that there's always going to be a certain amount of forkedness to openssh. From fcusack at fcusack.com Fri Aug 22 14:10:13 2003 From: fcusack at fcusack.com (Frank Cusack) Date: Thu, 21 Aug 2003 21:10:13 -0700 Subject: Re-using RSA1 keys as RSA Message-ID: <20030821211013.B25360@google.com> Is there a security issue with turning an RSA1 key into an RSA key? One might want to do this, e.g., to move to protocol 2 without having to update authorized_keys files. I thought there was a problem with this, but Google doesn't find anything. thanks /fc From dan at doxpara.com Fri Aug 22 15:34:12 2003 From: dan at doxpara.com (Dan Kaminsky) Date: Thu, 21 Aug 2003 23:34:12 -0600 Subject: No interest in partial auth? In-Reply-To: References: Message-ID: <3F45AB54.1030703@doxpara.com> erikvcl at silcom.com wrote: >Hi, > >I don't mean to be annoying, but it seems like there isn't any interest in >partial authentication. Is this true? It's not a future plan for OpenSSH >to have this feature? > >I'd just like to know if I'm on my own or not. > > Erik-- Well, even _I'm_ having trouble coming up with situations where partial auth is useful, and I'm always breaking ssh :-) But I imagine you've got some creative uses...perhaps we can simultaneously satisfy your needs for functionality, the "cabal"'s need for simplicity, and my enjoyment of doing things that I can't entirely predict the consequence of. All, why don't we create a new environment variable, $SSH_AUTHTYPE, that contains the method by which the user logged into the server? We already allow users to enable or disable certain types of auth; why not allow the shell to make its own decisions based on what the user selected? Instead of hardcoding a few decision types, hand something like: SSH_AUTHTYPE=password or SSH_AUTHTYPE=pubkey SSH_AUTHKEY=ssh-dss AAAAB3NzaC1kc3MAAACBAOaR3q/NFbHKzr2p7Pv0twMzhfgvor0l2JVYY4sIzO14+5rdudV8M0aUis4/+w07AL8OQy413xdyppHqBLxgj3gCCXOOjGbhSyCFaQbC6xTIClQISNA5X9JkO4OuaqJUD65qvD5ArsXyjRVWMHWjPtVVF6uzBSjnVN50IDJoCKl9AAAAFQDDXmMMBXvJophSgrqOVezFvpTQ5wAAAIEA0gcZsNVOsn6nSG+r0wD5mlloz5S7YL+ePCAJI6qY/0lOoV50uSIZoK5iWMgVLNrOLTkIv0MkYpt93HzY3zAvH7iSnbWHXdD+j+XTP6xN9ImnePlXFx8whe3kEduqitY41baGiFZq8zSCNfErp/GuzYcGH13O4Cb1zYyvD0mzxvgAAACABHFilqR7fRHbKrTN93cYJ8B+0zKeYx0Ov5L/02ZqwOWSKttRS3AiW1Imxg5af3AUyP6fyMpy8LzvianxzC/uQKcr3KfM9RXm99LOv9/yjr00v8LudwkThkUAOD9HzeMvOQooxk+pOm+sAx1MW7qUuadYHQL8usf8nY7VqDjqeUA= to shells for their own use -- a little like $SSH_CLIENT. This should be just a small patch, and would enable others to elegantly use their preferred method of partial (not multimode, though) authentication. Speaking of shells -- it would be useful, so as to not excessively impact other services, to have a sshd_config entry for a preshell -- a shell that is used to execute the user's shell of choice. This maps well to the different goals of users and admins. Thoughts? --Dan From dan at doxpara.com Fri Aug 22 15:39:07 2003 From: dan at doxpara.com (Dan Kaminsky) Date: Thu, 21 Aug 2003 23:39:07 -0600 Subject: Re-using RSA1 keys as RSA In-Reply-To: <20030821211013.B25360@google.com> References: <20030821211013.B25360@google.com> Message-ID: <3F45AC7B.40808@doxpara.com> Frank Cusack wrote: >Is there a security issue with turning an RSA1 key into an RSA key? One >might want to do this, e.g., to move to protocol 2 without having to >update authorized_keys files. > >I thought there was a problem with this, but Google doesn't find anything. > >thanks >/fc > >_______________________________________________ >openssh-unix-dev mailing list >openssh-unix-dev at mindrot.org >http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > It's been a while since I went over this, but I believe the reason you can't do this is: SSHv1 uses RSA keys for encryption -- I send you data encrypted with your pubkey, you send it back to me decrypted. SSHv2 uses RSA keys for verification -- I send you data, you send it back to me signed, I test to see if the data was signed correctly. There are potential attacks involving the use of one mode against the other. They're not as simple as what I once thought they were; i.e. the private key for decrypting is the public key for verifying -- but I think it was a problem nonetheless. That being said, there really needs to be a mode to check all known host key types for one that matches. This is a _real_ security requirement, people! If we checked the SSHv1 key before accepting a new SSHv2 key, we'd be _alot_ better off for the migrators. --Dan From spaceacademy at hotmail.com Fri Aug 22 15:45:09 2003 From: spaceacademy at hotmail.com (s c o t t) Date: Thu, 21 Aug 2003 22:45:09 -0700 Subject: [PATCH] memory leaked leaving scope Message-ID: Index: openssh/deattack.c =================================================================== RCS file: /cvs/openssh/deattack.c,v retrieving revision 1.15 diff -u -r1.15 deattack.c --- openssh/deattack.c 5 Mar 2002 01:53:05 -0000 1.15 +++ openssh/deattack.c 22 Aug 2003 05:34:05 -0000 @@ -112,20 +112,26 @@ if (len <= HASH_MINBLOCKS) { for (c = buf; c < buf + len; c += SSH_BLOCKSIZE) { if (IV && (!CMP(c, IV))) { - if ((check_crc(c, buf, len, IV))) + if ((check_crc(c, buf, len, IV))) { + if (h) + xfree(h); return (DEATTACK_DETECTED); - else + } else break; } for (d = buf; d < c; d += SSH_BLOCKSIZE) { if (!CMP(c, d)) { - if ((check_crc(c, buf, len, IV))) + if ((check_crc(c, buf, len, IV))) { + if (h) + xfree(h); return (DEATTACK_DETECTED); - else + } else break; } } } + if (h) + xfree(h); return (DEATTACK_OK); } memset(h, HASH_UNUSEDCHAR, n * HASH_ENTRYSIZE); @@ -138,19 +144,25 @@ i = (i + 1) & (n - 1)) { if (h[i] == HASH_IV) { if (!CMP(c, IV)) { - if (check_crc(c, buf, len, IV)) + if (check_crc(c, buf, len, IV)) { + if (h) + xfree(h); return (DEATTACK_DETECTED); - else + } else break; } } else if (!CMP(c, buf + h[i] * SSH_BLOCKSIZE)) { - if (check_crc(c, buf, len, IV)) + if (check_crc(c, buf, len, IV)) { + if (h) + xfree(h); return (DEATTACK_DETECTED); - else + } else break; } } h[i] = j; } + if (h) + xfree(h); return (DEATTACK_OK); } cheers, scott rankin _________________________________________________________________ Get MSN 8 and enjoy automatic e-mail virus protection. http://join.msn.com/?page=features/virus From vinschen at redhat.com Fri Aug 22 18:13:53 2003 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 22 Aug 2003 10:13:53 +0200 Subject: [PATCH] Small tweak to contrib/cygwin/ssh-user-config Message-ID: <20030822081353.GA1021@cygbert.vinschen.de> Hi, could somebody with checkin rights please apply the following patch to contrib/cygwin/ssh-user-config? It just appends the RSA2 and DSA keys to .ssh/authorized_keys instead of .ssh/authorized_keys2. TIA, Corinna Index: contrib/cygwin/ssh-user-config =================================================================== RCS file: /cvs/openssh_cvs/contrib/cygwin/ssh-user-config,v retrieving revision 1.1 diff -p -u -r1.1 ssh-user-config --- contrib/cygwin/ssh-user-config 19 Jan 2001 05:37:32 -0000 1.1 +++ contrib/cygwin/ssh-user-config 22 Aug 2003 08:10:46 -0000 @@ -171,8 +171,8 @@ then fi if request "Do you want to use this identity to login to this machine?" then - echo "Adding to ${pwdhome}/.ssh/authorized_keys2" - cat "${pwdhome}/.ssh/id_rsa.pub" >> "${pwdhome}/.ssh/authorized_keys2" + echo "Adding to ${pwdhome}/.ssh/authorized_keys" + cat "${pwdhome}/.ssh/id_rsa.pub" >> "${pwdhome}/.ssh/authorized_keys" fi fi fi @@ -190,8 +190,8 @@ then fi if request "Do you want to use this identity to login to this machine?" then - echo "Adding to ${pwdhome}/.ssh/authorized_keys2" - cat "${pwdhome}/.ssh/id_dsa.pub" >> "${pwdhome}/.ssh/authorized_keys2" + echo "Adding to ${pwdhome}/.ssh/authorized_keys" + cat "${pwdhome}/.ssh/id_dsa.pub" >> "${pwdhome}/.ssh/authorized_keys" fi fi fi -- Corinna Vinschen Cygwin Developer Red Hat, Inc. From dtucker at zip.com.au Sat Aug 23 00:52:20 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 23 Aug 2003 00:52:20 +1000 Subject: GSSAPI patch sync from OpenBSD to Portable Message-ID: <3F462E24.733008DD@zip.com.au> Hi All. Markus has commited the long-awaited GSSAPI patch to OpenBSD's ssh. There are patches. The first [1] is a straightforward port of the OpenBSD code to Portable. The second [2] contains the parts I've stolen from Simon Wilkinson's portable GSSAPI patch in an attempt to make it build. It is incomplete and doesn't currently work. The PAM support is not there and gss-serv-krb5.c is broken somehow ("macro "krb5_cc_gen_new" passed 3 arguments, but takes just 2"). I know approximately zero Kerberos and I'm hoping someone who knows what they're doing can help sort this out. Any takers? One other thing: shouldn't Simon now be listed as a copyright holder in OpenSSH's LICENCE? -Daz. [1] http://www.zip.com.au/~dtucker/openssh/openssh-gssapi.patch [2] http://www.zip.com.au/~dtucker/openssh/openssh-gssapi-port.patch -- 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 gostl at argoscomp.com Sat Aug 23 02:49:29 2003 From: gostl at argoscomp.com (Jack Gostl) Date: Fri, 22 Aug 2003 12:49:29 -0400 (EDT) Subject: AIX problem Message-ID: We are running 3.4p1. After upgrading to AIX 5.1, the "w" function (in ksh) stopped showing ssh logins. We upgraded to 3.6p1, no luck. Any thoughts? --- Jack Gostl gostl at argoscomp.com From ietf-secsh at joelweber.com Sat Aug 23 02:59:26 2003 From: ietf-secsh at joelweber.com (Joel N. Weber II) Date: Fri, 22 Aug 2003 12:59:26 -0400 Subject: Re-using RSA1 keys as RSA In-Reply-To: <3F45AC7B.40808@doxpara.com> (message from Dan Kaminsky on Thu, 21 Aug 2003 23:39:07 -0600) References: <20030821211013.B25360@google.com> <3F45AC7B.40808@doxpara.com> Message-ID: > That being said, there really needs to be a mode to check all known host > key types for one that matches. This is a _real_ security requirement, > people! If we checked the SSHv1 key before accepting a new SSHv2 key, > we'd be _alot_ better off for the migrators. 1) That's only really true if most people haven't already migrated. I think it's been a year since I was really making significant use of sshv1; everything that really matters to me has already migrated to sshv2. 2) That's only really true if you have a fix for the habit people develop of reacting to the MitM attack warning by deleting the relevant known_hosts entries. (To some extent, there is also a sysadmin behavior problem; if I remember correctly, the sysadmins of one machine I use decided six or eight months ago to change the host key as a result of migrating to a new machine, and didn't send pgp signed mail with the new key when I asked. They also broke my authorized_keys entry, such that I couldn't even do a login that would prevent a man in the middle from forwarding my login to the real machine. But they didn't break my password.) 3) That said, having a mechanism to roll over sshv2 keys to other sshv2 keys more cleanly may well be worth having. I'm thinking something where a client lists the keys it trusts, and if the server has its old private keys, it can sign the session with an old host key, and then use SSH_MSG_HOSTKEYS (once we have that defined; I have a mostly written draft that I should submit real soon now) to send the new host key. From mailinglistaddie at yahoo.com Sat Aug 23 05:08:15 2003 From: mailinglistaddie at yahoo.com (Mr. Mailing List) Date: Fri, 22 Aug 2003 12:08:15 -0700 (PDT) Subject: watchdog firebox has blocked ssh out Message-ID: <20030822190815.42969.qmail@web20703.mail.yahoo.com> I'm behind a watchdog firebox, which has recently blocked ssh out. I have it to where i can use port 21(the server forwards 21 to 22 that i am trying to connect to), but somehow the watchdog firewall is also blocking by protocol type? the only way i can connect is if i choose raw protocol in putty... and this is what i get SSH-1.99-OpenSSH_3.5p1 test Protocol mismatch. and then close. can i still use raw and somehow start using ssh after this, or something? Or is there some way to identify self as http protocol to the firewall? __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From smichaud at pobox.com Sat Aug 23 05:37:30 2003 From: smichaud at pobox.com (Steven Michaud) Date: Fri, 22 Aug 2003 14:37:30 -0500 Subject: GSSAPI patch sync from OpenBSD to Portable Message-ID: <3F4670FA.7010309@pobox.com> See my note to this list "Re: updated gssapi diff" dated "2003-08-19 18:51:02". In order for MIT support not to be broken, you need the patch from Douglas Engert mentioned in my note. Also, in session.c the calls to ssh_gssapi_storecreds() need to come before the calls to do_pam_session(), so that PAM can make use of any gssapi credentials that may get stored in a per-session cache. With these two changes, your openssh-gssapi-port.patch will look something like what I've attached below. Finally, I notice that you _did_ include one bit of PAM support from Simon Wilkinson's patch -- on line 825 of configure.ac you add the line "AC_CHECK_FUNCS(pam_putenv)". If you're willing to go that far, why not go all the way? The only additional work is to copy Simon's do_pam_putenv() to auth-pam.c, put a definition of this function into auth-pam.h, and copy Simon's call to do_pam_putenv() to ssh_gssapi_krb5_storecreds() in gss-serv-krb5.c. > The PAM support is not there and gss-serv-krb5.c is broken somehow > ("macro "krb5_cc_gen_new" passed 3 arguments, but takes just 2"). I know > approximately zero Kerberos and I'm hoping someone who knows what they're > doing can help sort this out. Any takers? -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-gssapi-port.fixed.txt Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030822/33b8ab82/attachment.txt From mouring at etoh.eviladmin.org Sat Aug 23 05:58:54 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 22 Aug 2003 14:58:54 -0500 (CDT) Subject: GSSAPI patch sync from OpenBSD to Portable In-Reply-To: <3F4670FA.7010309@pobox.com> Message-ID: KNF the gss_serv_krb5.c code please before you commit it. Missing a license for makegssname.pl Also, any reason why this is not included in the OpenBSD tree? If it is important it should be included upstream. - Ben On Fri, 22 Aug 2003, Steven Michaud wrote: > See my note to this list "Re: updated gssapi diff" dated "2003-08-19 > 18:51:02". In order for MIT support not to be broken, you need the > patch from Douglas Engert mentioned in my note. > > Also, in session.c the calls to ssh_gssapi_storecreds() need to come > before the calls to do_pam_session(), so that PAM can make use of any > gssapi credentials that may get stored in a per-session cache. > > With these two changes, your openssh-gssapi-port.patch will look > something like what I've attached below. > > Finally, I notice that you _did_ include one bit of PAM support from > Simon Wilkinson's patch -- on line 825 of configure.ac you add the line > "AC_CHECK_FUNCS(pam_putenv)". If you're willing to go that far, why not > go all the way? The only additional work is to copy Simon's > do_pam_putenv() to auth-pam.c, put a definition of this function into > auth-pam.h, and copy Simon's call to do_pam_putenv() to > ssh_gssapi_krb5_storecreds() in gss-serv-krb5.c. > > > The PAM support is not there and gss-serv-krb5.c is broken somehow > > ("macro "krb5_cc_gen_new" passed 3 arguments, but takes just 2"). I know > > approximately zero Kerberos and I'm hoping someone who knows what they're > > doing can help sort this out. Any takers? > > From erikvcl at silcom.com Sat Aug 23 06:10:38 2003 From: erikvcl at silcom.com (Erik Lotspeich) Date: Fri, 22 Aug 2003 13:10:38 -0700 (PDT) Subject: No interest in partial auth? In-Reply-To: <3F45AB54.1030703@doxpara.com> Message-ID: > Well, even _I'm_ having trouble coming up with situations where > partial auth is useful, and I'm always breaking ssh :-) > > But I imagine you've got some creative uses...perhaps we can Dan, If I understand correctly, the commercial version of SSH2 does support partial authentication. And the OpenSSH client supports this feature also (I assume for the purpose of interacting wth commercial SSH2 servers that require partial authentication). In the particular application that I am considering, there is a need both for a "login" password with the capability of authenticating against a remote server (NIS, LDAP, Radius, etc.) and for requiring a public key. In this application, the private key will be stored on a biometric authentication device with memory. The end result will be two-levels of security: biometric (i.e. publickey), and traditional (i.e. password). I understand that my application seems quite unique, but I can imagine that any high-security application would want two levels of authentication to protect against a stolen key and/or password. As external authentication methods become more prevalent (biometric and otherwise), the need for this will increase. In the future, the implementation in my application may use the keyboard-interactive method and have a closer software/hardware interaction with the biometric device for increased security, but even at that point, we would need both password and keyboard-interactive methods. > simultaneously satisfy your needs for functionality, the "cabal"'s need > for simplicity, and my enjoyment of doing things that I can't entirely > predict the consequence of. All, why don't we create a new environment > variable, $SSH_AUTHTYPE, that contains the method by which the user > logged into the server? We already allow users to enable or disable > certain types of auth; why not allow the shell to make its own decisions > based on what the user selected? Instead of hardcoding a few decision > types, hand something like: > > SSH_AUTHTYPE=password > > or > > SSH_AUTHTYPE=pubkey > SSH_AUTHKEY=ssh-dss > AAAAB3NzaC1kc3MAAACBAOaR3q/NFbHKzr2p7Pv0twMzhfgvor0l2JVYY4sIzO14+5rdudV8M0aUis4/+w07AL8OQy413xdyppHqBLxgj3gCCXOOjGbhSyCFaQbC6xTIClQISNA5X9JkO4OuaqJUD65qvD5ArsXyjRVWMHWjPtVVF6uzBSjnVN50IDJoCKl9AAAAFQDDXmMMBXvJophSgrqOVezFvpTQ5wAAAIEA0gcZsNVOsn6nSG+r0wD5mlloz5S7YL+ePCAJI6qY/0lOoV50uSIZoK5iWMgVLNrOLTkIv0MkYpt93HzY3zAvH7iSnbWHXdD+j+XTP6xN9ImnePlXFx8whe3kEduqitY41baGiFZq8zSCNfErp/GuzYcGH13O4Cb1zYyvD0mzxvgAAACABHFilqR7fRHbKrTN93cYJ8B+0zKeYx0Ov5L/02ZqwOWSKttRS3AiW1Imxg5af3AUyP6fyMpy8LzvianxzC/uQKcr3KfM9RXm99LOv9/yjr00v8LudwkThkUAOD9HzeMvOQooxk+pOm+sAx1MW7qUuadYHQL8usf8nY7VqDjqeUA= > > to shells for their own use -- a little like $SSH_CLIENT. This should > be just a small patch, and would enable others to elegantly use their > preferred method of partial (not multimode, though) authentication. > > Speaking of shells -- it would be useful, so as to not excessively > impact other services, to have a sshd_config entry for a preshell -- a > shell that is used to execute the user's shell of choice. This maps > well to the different goals of users and admins. Although I am no security expert, I would argue for functionality that works like the commercial SSH2 version. This would ensure compatibility and lessen the burden for those coming from the commercial version to OpenSSH. Erik. From sxw at inf.ed.ac.uk Sat Aug 23 06:35:23 2003 From: sxw at inf.ed.ac.uk (sxw at inf.ed.ac.uk) Date: Fri, 22 Aug 2003 21:35:23 +0100 (BST) Subject: GSSAPI patch sync from OpenBSD to Portable In-Reply-To: Message-ID: On Fri, 22 Aug 2003, Ben Lindstrom wrote: > > KNF the gss_serv_krb5.c code please before you commit it. I'm working on a forward port of my portable stuff, just testing ATM. It covers a couple of areas missing from Steven's one (PAM support, some header file inclusion). I've KNF'd the code as much as I can see ... > Missing a license for makegssname.pl Also, any reason why this is not > included in the OpenBSD tree? If it is important it should be included > upstream. No, its not important - it can be dropped. Cheers, Simon. From smichaud at pobox.com Sat Aug 23 06:41:02 2003 From: smichaud at pobox.com (Steven Michaud) Date: Fri, 22 Aug 2003 15:41:02 -0500 (CDT) Subject: GSSAPI patch sync from OpenBSD to Portable In-Reply-To: References: Message-ID: > Missing a license for makegssname.pl I don't know what this is used for, nothing else in Simon Wilkinson's patch refers to it, and Google doesn't find any references to it except as part of OpenSSH with Simon's patch. My guess is you can drop it. But if I'm wrong, someone else do please chime up. > Also, any reason why this is not included in the OpenBSD tree? If > it is important it should be included upstream. Douglas Engert's patch (to ssh_gssapi_krb5_storecreds() in gss-serv-krb5.c) only has any effect when you compile against the MIT libraries. It's not needed in "non-portable", which just assumes the Heimdal libraries are present if you define KRB5. On Fri, 22 Aug 2003, Ben Lindstrom wrote: > > KNF the gss_serv_krb5.c code please before you commit it. > > Missing a license for makegssname.pl Also, any reason why this is not > included in the OpenBSD tree? If it is important it should be included > upstream. > > - Ben > > On Fri, 22 Aug 2003, Steven Michaud wrote: > > > See my note to this list "Re: updated gssapi diff" dated "2003-08-19 > > 18:51:02". In order for MIT support not to be broken, you need the > > patch from Douglas Engert mentioned in my note. > > > > Also, in session.c the calls to ssh_gssapi_storecreds() need to come > > before the calls to do_pam_session(), so that PAM can make use of any > > gssapi credentials that may get stored in a per-session cache. > > > > With these two changes, your openssh-gssapi-port.patch will look > > something like what I've attached below. > > > > Finally, I notice that you _did_ include one bit of PAM support from > > Simon Wilkinson's patch -- on line 825 of configure.ac you add the line > > "AC_CHECK_FUNCS(pam_putenv)". If you're willing to go that far, why not > > go all the way? The only additional work is to copy Simon's > > do_pam_putenv() to auth-pam.c, put a definition of this function into > > auth-pam.h, and copy Simon's call to do_pam_putenv() to > > ssh_gssapi_krb5_storecreds() in gss-serv-krb5.c. > > > > > The PAM support is not there and gss-serv-krb5.c is broken somehow > > > ("macro "krb5_cc_gen_new" passed 3 arguments, but takes just 2"). I know > > > approximately zero Kerberos and I'm hoping someone who knows what they're > > > doing can help sort this out. Any takers? > > > > > > > From markus at openbsd.org Sat Aug 23 07:03:07 2003 From: markus at openbsd.org (Markus Friedl) Date: Fri, 22 Aug 2003 23:03:07 +0200 Subject: Re-using RSA1 keys as RSA In-Reply-To: <20030821211013.B25360@google.com> References: <20030821211013.B25360@google.com> Message-ID: <20030822210307.GA25939@folly> On Thu, Aug 21, 2003 at 09:10:13PM -0700, Frank Cusack wrote: > Is there a security issue with turning an RSA1 key into an RSA key? One > might want to do this, e.g., to move to protocol 2 without having to > update authorized_keys files. in protocol 1 rsa keys are used for encryption, in protocol 2 they are used for signatures. From markus at openbsd.org Sat Aug 23 07:14:23 2003 From: markus at openbsd.org (Markus Friedl) Date: Fri, 22 Aug 2003 23:14:23 +0200 Subject: gss userauth (fwd) Message-ID: <20030822211423.GB25939@folly> what about this? can we do about this if we break the protocol? -------------- next part -------------- An embedded message was scrubbed... From: Love Subject: gss userauth Date: Fri, 22 Aug 2003 16:06:27 +0200 Size: 2878 Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030822/f7bb85a0/attachment.mht From sxw at inf.ed.ac.uk Sat Aug 23 07:23:00 2003 From: sxw at inf.ed.ac.uk (sxw at inf.ed.ac.uk) Date: Fri, 22 Aug 2003 22:23:00 +0100 (BST) Subject: GSSAPI patch sync from OpenBSD to Portable In-Reply-To: Message-ID: > I'm working on a forward port of my portable stuff, just testing ATM. It > covers a couple of areas missing from Steven's one (PAM support, some > header file inclusion). I've KNF'd the code as much as I can see ... Replying to my own mail. Attached is a patch to add MIT/portable support to the GSSAPI code. Tested against both my 3.6.1 patches, and a current snapshot running the OpenBSD code. The patch adds PAM support by moving credentials storage before PAM execution, and by adding pam_putenv calls. It factors out the definition of krb5_err_text() to one location, adds support for MIT style credentials cache creation, and includes some MIT specific header files if we're not using HEIMDAL. Hope this is of use! Cheers, Simon. -------------- next part -------------- Index: Makefile.in =================================================================== RCS file: /disk/cvs/dice/openssh/Makefile.in,v retrieving revision 1.1.1.2 diff -u -r1.1.1.2 Makefile.in --- Makefile.in 22 Aug 2003 18:17:03 -0000 1.1.1.2 +++ Makefile.in 22 Aug 2003 21:13:52 -0000 @@ -68,7 +68,7 @@ key.o dispatch.o kex.o mac.o uuencode.o misc.o \ rijndael.o ssh-dss.o ssh-rsa.o dh.o kexdh.o kexgex.o \ kexdhc.o kexgexc.o scard.o msg.o progressmeter.o dns.o \ - entropy.o scard-opensc.o + entropy.o scard-opensc.o gss-genr.o SSHOBJS= ssh.o readconf.o clientloop.o sshtty.o \ sshconnect.o sshconnect1.o sshconnect2.o @@ -82,6 +82,7 @@ monitor_mm.o monitor.o monitor_wrap.o monitor_fdpass.o \ kexdhs.o kexgexs.o \ auth-krb5.o auth2-krb5.o \ + auth2-gss.o gss-serv.o gss-serv-krb5.o \ loginrec.o auth-pam.o auth-sia.o md5crypt.o MANPAGES = scp.1.out ssh-add.1.out ssh-agent.1.out ssh-keygen.1.out ssh-keyscan.1.out ssh.1.out sshd.8.out sftp-server.8.out sftp.1.out ssh-rand-helper.8.out ssh-keysign.8.out sshd_config.5.out ssh_config.5.out Index: acconfig.h =================================================================== RCS file: /disk/cvs/dice/openssh/acconfig.h,v retrieving revision 1.1.1.2 diff -u -r1.1.1.2 acconfig.h --- acconfig.h 22 Aug 2003 18:17:03 -0000 1.1.1.2 +++ acconfig.h 22 Aug 2003 21:13:52 -0000 @@ -232,6 +232,9 @@ /* Define if compiler implements __func__ */ #undef HAVE___func__ +/* Define this is you want GSSAPI support in the version 2 protocol */ +#undef GSSAPI + /* Define if you want Kerberos 5 support */ #undef KRB5 Index: auth-krb5.c =================================================================== RCS file: /disk/cvs/dice/openssh/auth-krb5.c,v retrieving revision 1.1.1.2 diff -u -r1.1.1.2 auth-krb5.c --- auth-krb5.c 22 Aug 2003 18:17:03 -0000 1.1.1.2 +++ auth-krb5.c 22 Aug 2003 21:13:52 -0000 @@ -42,9 +42,6 @@ #ifdef KRB5 #include -#ifndef HEIMDAL -#define krb5_get_err_text(context,code) error_message(code) -#endif /* !HEIMDAL */ extern ServerOptions options; Index: auth-pam.c =================================================================== RCS file: /disk/cvs/dice/openssh/auth-pam.c,v retrieving revision 1.1.1.2 diff -u -r1.1.1.2 auth-pam.c --- auth-pam.c 22 Aug 2003 18:17:03 -0000 1.1.1.2 +++ auth-pam.c 22 Aug 2003 21:13:52 -0000 @@ -648,6 +648,29 @@ pam_strerror(sshpam_handle, sshpam_err)); } +/* + * Set a PAM environment string. We need to do this so that the session + * modules can handle things like Kerberos/GSI credentials that appear + * during the ssh authentication process. + */ + +int +do_pam_putenv(char *name, char *value) +{ + char *compound; + int ret = 1; + +#ifdef HAVE_PAM_PUTENV + compound = xmalloc(strlen(name)+strlen(value)+2); + if (compound) { + sprintf(compound,"%s=%s",name,value); + ret = pam_putenv(sshpam_handle,compound); + xfree(compound); + } +#endif + return (ret); +} + void print_pam_messages(void) { Index: auth-pam.h =================================================================== RCS file: /disk/cvs/dice/openssh/auth-pam.h,v retrieving revision 1.1.1.1 diff -u -r1.1.1.1 auth-pam.h --- auth-pam.h 29 May 2003 20:11:14 -0000 1.1.1.1 +++ auth-pam.h 22 Aug 2003 21:13:52 -0000 @@ -38,6 +38,7 @@ void do_pam_setcred(int ); int is_pam_password_change_required(void); void do_pam_chauthtok(void); +int do_pam_putenv(char *, char *); void print_pam_messages(void); char ** fetch_pam_environment(void); void free_pam_environment(char **); Index: configure.ac =================================================================== RCS file: /disk/cvs/dice/openssh/configure.ac,v retrieving revision 1.1.1.2 diff -u -r1.1.1.2 configure.ac --- configure.ac 22 Aug 2003 18:17:03 -0000 1.1.1.2 +++ configure.ac 22 Aug 2003 21:13:52 -0000 @@ -820,6 +820,7 @@ AC_CHECK_LIB(dl, dlopen, , ) AC_CHECK_LIB(pam, pam_set_item, , AC_MSG_ERROR([*** libpam missing])) AC_CHECK_FUNCS(pam_getenvlist) + AC_CHECK_FUNCS(pam_putenv) disable_shadow=yes PAM_MSG="yes" @@ -1934,6 +1935,31 @@ blibpath="$blibpath:${KRB5ROOT}/lib" fi AC_SEARCH_LIBS(dn_expand, resolv) + + AC_CHECK_LIB(gssapi,gss_init_sec_context, + [ AC_DEFINE(GSSAPI) + K5LIBS="-lgssapi $K5LIBS" ], + [ AC_CHECK_LIB(gssapi_krb5,gss_init_sec_context, + [ AC_DEFINE(GSSAPI) + K5LIBS="-lgssapi_krb5 $K5LIBS" ], + AC_MSG_WARN([Cannot find any suitable gss-api library - build may fail]), + $K5LIBS) + ], + $K5LIBS) + + AC_CHECK_HEADER(gssapi.h, , + [ unset ac_cv_header_gssapi_h + CPPFLAGS="$CPPFLAGS -I${KRB5ROOT}/include/gssapi" + AC_CHECK_HEADERS(gssapi.h, , + AC_MSG_WARN([Cannot find any suitable gss-api header - build may fail]) + ) + ] + ) + + oldCPP="$CPPFLAGS" + CPPFLAGS="$CPPFLAGS -I${KRB5ROOT}/include/gssapi" + AC_CHECK_HEADER(gssapi_krb5.h, , + [ CPPFLAGS="$oldCPP" ]) KRB5=yes fi Index: defines.h =================================================================== RCS file: /disk/cvs/dice/openssh/defines.h,v retrieving revision 1.1.1.2 diff -u -r1.1.1.2 defines.h --- defines.h 22 Aug 2003 18:17:03 -0000 1.1.1.2 +++ defines.h 22 Aug 2003 21:13:52 -0000 @@ -504,6 +504,10 @@ # define __func__ "" #endif +#if defined(KRB5) && !defined(HEIMDAL) +# define krb5_get_err_text(context,code) error_message(code) +#endif + /* * Define this to use pipes instead of socketpairs for communicating with the * client program. Socketpairs do not seem to work on all systems. Index: gss-serv-krb5.c =================================================================== RCS file: /disk/cvs/dice/openssh/gss-serv-krb5.c,v retrieving revision 1.2 diff -u -r1.2 gss-serv-krb5.c --- gss-serv-krb5.c 22 Aug 2003 20:00:49 -0000 1.2 +++ gss-serv-krb5.c 22 Aug 2003 21:13:52 -0000 @@ -38,7 +38,11 @@ extern ServerOptions options; +#ifdef HEIMDAL #include +#else +#include +#endif static krb5_context krb_context = NULL; @@ -113,11 +117,39 @@ if (ssh_gssapi_krb5_init() == 0) return; +#ifdef HEIMDAL if ((problem = krb5_cc_gen_new(krb_context, &krb5_fcc_ops, &ccache))) { logit("krb5_cc_gen_new(): %.100s", krb5_get_err_text(krb_context, problem)); return; } +#else +{ + int tmpfd; + char ccname[40]; + + snprintf(ccname, sizeof(ccname), + "FILE:/tmp/krb5cc_%d_XXXXXX", geteuid()); + + if ((tmpfd = mkstemp(ccname + strlen("FILE:"))) == -1) { + logit("mkstemp(): %.100s", strerror(errno)); + problem = errno; + return; + } + if (fchmod(tmpfd, S_IRUSR | S_IWUSR) == -1) { + logit("fchmod(): %.100s", strerror(errno)); + close(tmpfd); + problem = errno; + return; + } + close(tmpfd); + if ((problem = krb5_cc_resolve(krb_context, ccname, &ccache))) { + logit("krb5_cc_resolve(): %.100s", + krb5_get_err_text(krb_context, problem)); + return; + } +} +#endif /* #ifdef HEIMDAL */ if ((problem = krb5_parse_name(krb_context, client->exportedname.value, &princ))) { @@ -147,6 +179,10 @@ client->store.filename = xstrdup(krb5_cc_get_name(krb_context, ccache)); client->store.envvar = "KRB5CCNAME"; client->store.envval = xstrdup(client->store.filename); + +#ifdef USE_PAM + do_pam_putenv(client->store.envvar,client->store.envval); +#endif krb5_cc_close(krb_context, ccache); Index: session.c =================================================================== RCS file: /disk/cvs/dice/openssh/session.c,v retrieving revision 1.2 diff -u -r1.2 session.c --- session.c 22 Aug 2003 19:45:36 -0000 1.2 +++ session.c 22 Aug 2003 21:13:52 -0000 @@ -418,6 +418,12 @@ session_proctitle(s); +#ifdef GSSAPI + temporarily_use_uid(s->pw); + ssh_gssapi_storecreds(); + restore_uid(); +#endif + #if defined(USE_PAM) if (options.use_pam) { do_pam_session(s->pw->pw_name, NULL); @@ -428,12 +434,6 @@ } #endif /* USE_PAM */ -#ifdef GSSAPI - temporarily_use_uid(s->pw); - ssh_gssapi_storecreds(); - restore_uid(); -#endif - /* Fork the child. */ if ((pid = fork()) == 0) { fatal_remove_all_cleanups(); @@ -553,17 +553,17 @@ ptyfd = s->ptyfd; ttyfd = s->ttyfd; +#ifdef GSSAPI + temporarily_use_uid(s->pw); + ssh_gssapi_storecreds(); + restore_uid(); +#endif + #if defined(USE_PAM) if (options.use_pam) { do_pam_session(s->pw->pw_name, s->tty); do_pam_setcred(1); } -#endif - -#ifdef GSSAPI - temporarily_use_uid(s->pw); - ssh_gssapi_storecreds(); - restore_uid(); #endif /* Fork the child. */ Index: ssh-gss.h =================================================================== RCS file: /disk/cvs/dice/openssh/ssh-gss.h,v retrieving revision 1.2 diff -u -r1.2 ssh-gss.h --- ssh-gss.h 22 Aug 2003 20:00:49 -0000 1.2 +++ ssh-gss.h 22 Aug 2003 21:13:52 -0000 @@ -31,6 +31,18 @@ #include +#ifdef KRB5 +#ifndef HEIMDAL +#include + +/* MIT Kerberos doesn't seem to define GSS_NT_HOSTBASED_SERVICE */ +/* It seems to be defined in gssapi_krb5.h -dtucker */ +#ifndef GSS_C_NT_HOSTBASED_SERVICE +#define GSS_C_NT_HOSTBASED_SERVICE gss_nt_service_name +#endif /* GSS_C_NT_... */ +#endif /* !HEIMDAL */ +#endif /* KRB5 */ + /* draft-ietf-secsh-gsskeyex-06 */ #define SSH2_MSG_USERAUTH_GSSAPI_RESPONSE 60 #define SSH2_MSG_USERAUTH_GSSAPI_TOKEN 61 Index: sshconnect1.c =================================================================== RCS file: /disk/cvs/dice/openssh/sshconnect1.c,v retrieving revision 1.1.1.2 diff -u -r1.1.1.2 sshconnect1.c --- sshconnect1.c 22 Aug 2003 18:17:03 -0000 1.1.1.2 +++ sshconnect1.c 22 Aug 2003 21:13:52 -0000 @@ -20,9 +20,6 @@ #ifdef KRB5 #include -#ifndef HEIMDAL -#define krb5_get_err_text(context,code) error_message(code) -#endif /* !HEIMDAL */ #endif #include "ssh.h" Index: sshconnect2.c =================================================================== RCS file: /disk/cvs/dice/openssh/sshconnect2.c,v retrieving revision 1.2 diff -u -r1.2 sshconnect2.c --- sshconnect2.c 22 Aug 2003 19:45:36 -0000 1.2 +++ sshconnect2.c 22 Aug 2003 21:13:52 -0000 @@ -27,9 +27,6 @@ #ifdef KRB5 #include -#ifndef HEIMDAL -#define krb5_get_err_text(context,code) error_message(code) -#endif /* !HEIMDAL */ #endif #include "openbsd-compat/sys-queue.h" From brugolsky at telemetry-investments.com Sat Aug 23 07:24:17 2003 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Fri, 22 Aug 2003 17:24:17 -0400 Subject: Client does not propagate EPIPE write error to server. Message-ID: <20030822212417.GK15700@ti19> Hi, I'm experiencing the bug reported in: http://bugzilla.mindrot.org/show_bug.cgi?id=85 Bugzilla Bug 85 ssh -2 localhost od /bin/ls | true ignore SIGPIPE Perhaps a slightly more realistic example: rugolsky at mercury: ssh -vvv -x -n -2 localhost cat /dev/zero | dd count=1 ... debug1: fd 4 setting O_NONBLOCK debug1: fd 5 setting O_NONBLOCK debug1: channel 0: new [client-session] debug3: ssh_session2_open: channel_new: 0 debug1: send channel open 0 debug1: Entering interactive session. debug2: callback start debug1: ssh_session2_setup: id 0 debug1: Sending command: cat /dev/zero debug1: channel request 0: exec debug2: callback done debug1: channel 0: open confirm rwindow 0 rmax 32768 debug2: channel 0: rcvd adjust 131072 debug1: channel 0: read<=0 rfd 4 len 0 debug1: channel 0: read failed debug1: channel 0: close_read debug1: channel 0: input open -> drain debug1: channel 0: ibuf empty debug1: channel 0: send eof debug1: channel 0: input drain -> closed 1+0 records in 1+0 records out debug1: channel 0: write failed debug1: channel 0: close_write debug1: channel 0: output open -> closed and hangs ... It seems that with v2, EOF on input descriptors are propagated to the peer as EOF, but there is no corresponding protocol mechanism in the v2 protocol for indicating that an output file descriptor is closed? Is this correct? If so, it seems horribly broken. The v1 code sets quit_pending=1, and exits the select loop. I have a hack that does something equally ugly for v2 by creating a channel state notifier callback, and only registering it for the session_ident in the clientloop setup. Any better ideas? Please CC me, as I'm not subscribed. Regards, Bill Rugolsky From dan at doxpara.com Sat Aug 23 07:27:21 2003 From: dan at doxpara.com (Dan Kaminsky) Date: Fri, 22 Aug 2003 15:27:21 -0600 Subject: Re-using RSA1 keys as RSA In-Reply-To: <20030822210307.GA25939@folly> References: <20030821211013.B25360@google.com> <20030822210307.GA25939@folly> Message-ID: <3F468AB9.2060108@doxpara.com> Markus Friedl wrote: >On Thu, Aug 21, 2003 at 09:10:13PM -0700, Frank Cusack wrote: > > >>Is there a security issue with turning an RSA1 key into an RSA key? One >>might want to do this, e.g., to move to protocol 2 without having to >>update authorized_keys files. >> >> > >in protocol 1 rsa keys are used for encryption, >in protocol 2 they are used for signatures. > > Markus-- In protocol 2, the RSA public key verifies a signature, as in protocol 1, a RSA public key encrypts a token. I'm not sure, but the only difference between the two may very well be the source of the token being operated upon -- SSHv1 has the client generate random data; SSHv2 has the server generate and hash it. Either way, client + pubkey authenticates server + privkey. I'm not saying it's safe to dual-purpose RSA; I'm just not entirely sure I've seen evidence it's dangerous to multipurpose the same RSA key. Have you seen any evidence to the contrary? --Dan From mouring at etoh.eviladmin.org Sat Aug 23 07:39:22 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Fri, 22 Aug 2003 16:39:22 -0500 (CDT) Subject: GSSAPI patch sync from OpenBSD to Portable In-Reply-To: Message-ID: Outside of ensure the #else clause gets formated right (It is off by a tab). Which is no biggy. I don't see anything to complain about. Damien will have to look a bit closer at the PAM stuff, but it looks reasonable. +#ifdef HEIMDAL if ((problem = krb5_cc_gen_new(krb_context, &krb5_fcc_ops, &ccache))) { logit("krb5_cc_gen_new(): %.100s", krb5_get_err_text(krb_context, problem)); return; } +#else +{ + int tmpfd; + char ccname[40]; + + snprintf(ccname, sizeof(ccname), - Ben On Fri, 22 Aug 2003 sxw at inf.ed.ac.uk wrote: > > > I'm working on a forward port of my portable stuff, just testing ATM. It > > covers a couple of areas missing from Steven's one (PAM support, some > > header file inclusion). I've KNF'd the code as much as I can see ... > > Replying to my own mail. Attached is a patch to add MIT/portable support > to the GSSAPI code. Tested against both my 3.6.1 patches, and a current > snapshot running the OpenBSD code. > > The patch adds PAM support by moving credentials storage before PAM > execution, and by adding pam_putenv calls. It factors out the definition > of krb5_err_text() to one location, adds support for MIT style > credentials cache creation, and includes some MIT specific header files if > we're not using HEIMDAL. > > Hope this is of use! > > Cheers, > > Simon. > > > From smichaud at pobox.com Sat Aug 23 08:21:30 2003 From: smichaud at pobox.com (Steven Michaud) Date: Fri, 22 Aug 2003 17:21:30 -0500 (CDT) Subject: GSSAPI patch sync from OpenBSD to Portable In-Reply-To: References: Message-ID: One really minor nit: Shouldn't the last hunk of gss-serv-krb5.c be this: @@ -147,6 +179,11 @@ client->store.filename = xstrdup(krb5_cc_get_name(krb_context, ccache)); client->store.envvar = "KRB5CCNAME"; client->store.envval = xstrdup(client->store.filename); + +#ifdef USE_PAM + if (options.use_pam) + do_pam_putenv(client->store.envvar, client->store.envval); +#endif krb5_cc_close(krb_context, ccache); instead of this? @@ -147,6 +179,10 @@ client->store.filename = xstrdup(krb5_cc_get_name(krb_context, ccache)); client->store.envvar = "KRB5CCNAME"; client->store.envval = xstrdup(client->store.filename); + +#ifdef USE_PAM + do_pam_putenv(client->store.envvar,client->store.envval); +#endif krb5_cc_close(krb_context, ccache); On Fri, 22 Aug 2003 sxw at inf.ed.ac.uk wrote: > > > I'm working on a forward port of my portable stuff, just testing ATM. It > > covers a couple of areas missing from Steven's one (PAM support, some > > header file inclusion). I've KNF'd the code as much as I can see ... > > Replying to my own mail. Attached is a patch to add MIT/portable support > to the GSSAPI code. Tested against both my 3.6.1 patches, and a current > snapshot running the OpenBSD code. > > The patch adds PAM support by moving credentials storage before PAM > execution, and by adding pam_putenv calls. It factors out the definition > of krb5_err_text() to one location, adds support for MIT style > credentials cache creation, and includes some MIT specific header files if > we're not using HEIMDAL. > > Hope this is of use! > > Cheers, > > Simon. > > > From dtucker at zip.com.au Sat Aug 23 09:25:20 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 23 Aug 2003 09:25:20 +1000 Subject: AIX problem References: Message-ID: <3F46A660.4FBFE753@zip.com.au> Jack Gostl wrote: > We are running 3.4p1. After upgrading to AIX 5.1, the "w" function (in > ksh) stopped showing ssh logins. We upgraded to 3.6p1, no luck. > > Any thoughts? Recompile your sshd on AIX 5.1, or obtain one that was. The wtmp (or is that utmp, I always forget) structures changed between AIX 4.x and AIX 5.x. Prebuilt packages can be found: http://oss.software.ibm.com/developerworks/projects/opensshi/ 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 gostl at argoscomp.com Sat Aug 23 10:05:58 2003 From: gostl at argoscomp.com (Jack Gostl) Date: Fri, 22 Aug 2003 20:05:58 -0400 (EDT) Subject: AIX problem In-Reply-To: <3F46A660.4FBFE753@zip.com.au> Message-ID: I can buy that. I have no trouble doing the rebuild. The problem is that the remote systems are only accessible through ssh. So I either figure out a smart way to shut it down, reinstall and restart through a batch file or I throw myself on the mercy of the firewall guys. (A pitifully small target.) thanks. On Sat, 23 Aug 2003, Darren Tucker wrote: > Jack Gostl wrote: > > We are running 3.4p1. After upgrading to AIX 5.1, the "w" function (in > > ksh) stopped showing ssh logins. We upgraded to 3.6p1, no luck. > > > > Any thoughts? > > Recompile your sshd on AIX 5.1, or obtain one that was. > > The wtmp (or is that utmp, I always forget) structures changed between AIX > 4.x and AIX 5.x. > > Prebuilt packages can be found: > http://oss.software.ibm.com/developerworks/projects/opensshi/ > http://www.zip.com.au/~dtucker/openssh/ > > -- Jack Gostl gostl at argoscomp.com From dtucker at zip.com.au Sat Aug 23 10:24:03 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 23 Aug 2003 10:24:03 +1000 Subject: AIX problem References: Message-ID: <3F46B423.385F7F12@zip.com.au> Jack Gostl wrote: > I can buy that. I have no trouble doing the rebuild. The problem is that > the remote systems are only accessible through ssh. So I either figure out > a smart way to shut it down, reinstall and restart through a batch file or > I throw myself on the mercy of the firewall guys. (A pitifully small > target.) Killing the listening sshd will not kill the running sessions, they'll just end up with a ppid of 1. You can also do a couple of things to cut down the risk of snookering yourself: 1) use "./sshd -t" to test your config after building. 2) start an sshd on another port, then connect from the host itself: $ ./sshd -p 2022 -o PidFile=/tmp/sshd.pid $ ssh -p 2022 localhost 3) When doing a "make install", keep a couple of spare sessions running, then connect to the new sshd in a new window. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Sat Aug 23 10:25:57 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 23 Aug 2003 10:25:57 +1000 Subject: watchdog firebox has blocked ssh out References: <20030822190815.42969.qmail@web20703.mail.yahoo.com> Message-ID: <3F46B495.60466A7C@zip.com.au> "Mr. Mailing List" wrote: > I'm behind a watchdog firebox, which has recently > blocked ssh out. I have it to where i can use port > 21(the server forwards 21 to 22 that i am trying to > connect to), but somehow the watchdog firewall is also > blocking by protocol type? Many state-based firewalls "peek" into the application layer in order to handle some protocols. FTP (port 21) is probably the best-known example of one where you must do this in order to correctly firewall (or NAT) it. > can i still use raw and somehow start using ssh after > this, or something? Or is there some way to identify > self as http protocol to the firewall? Use another port or talk to your firewall admin. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Sat Aug 23 10:37:05 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 23 Aug 2003 10:37:05 +1000 Subject: GSSAPI patch sync from OpenBSD to Portable References: Message-ID: <3F46B731.130D4189@zip.com.au> Steven Michaud wrote: > Shouldn't the last hunk of gss-serv-krb5.c be this: > +#ifdef USE_PAM > + if (options.use_pam) > + do_pam_putenv(client->store.envvar, client->store.envval); > +#endif Yes. Patch attached is based on Simon's, with that and the retabbifying Ben mentioned. -- 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 -------------- diff -ru --new-file --exclude=CVS --exclude=configure --exclude=linux --exclude=autom4te-2.53.cache --exclude=config.h.in --exclude='config.h.in~' ../openssh-gssapi/Makefile.in ./Makefile.in --- ../openssh-gssapi/Makefile.in 2003-08-20 23:23:34.000000000 +1000 +++ ./Makefile.in 2003-08-23 09:51:41.000000000 +1000 @@ -68,7 +68,7 @@ key.o dispatch.o kex.o mac.o uuencode.o misc.o \ rijndael.o ssh-dss.o ssh-rsa.o dh.o kexdh.o kexgex.o \ kexdhc.o kexgexc.o scard.o msg.o progressmeter.o dns.o \ - entropy.o scard-opensc.o + entropy.o scard-opensc.o gss-genr.o SSHOBJS= ssh.o readconf.o clientloop.o sshtty.o \ sshconnect.o sshconnect1.o sshconnect2.o @@ -82,6 +82,7 @@ monitor_mm.o monitor.o monitor_wrap.o monitor_fdpass.o \ kexdhs.o kexgexs.o \ auth-krb5.o auth2-krb5.o \ + auth2-gss.o gss-serv.o gss-serv-krb5.o \ loginrec.o auth-pam.o auth-sia.o md5crypt.o MANPAGES = scp.1.out ssh-add.1.out ssh-agent.1.out ssh-keygen.1.out ssh-keyscan.1.out ssh.1.out sshd.8.out sftp-server.8.out sftp.1.out ssh-rand-helper.8.out ssh-keysign.8.out sshd_config.5.out ssh_config.5.out diff -ru --new-file --exclude=CVS --exclude=configure --exclude=linux --exclude=autom4te-2.53.cache --exclude=config.h.in --exclude='config.h.in~' ../openssh-gssapi/acconfig.h ./acconfig.h --- ../openssh-gssapi/acconfig.h 2003-08-20 23:23:34.000000000 +1000 +++ ./acconfig.h 2003-08-23 09:51:41.000000000 +1000 @@ -232,6 +232,9 @@ /* Define if compiler implements __func__ */ #undef HAVE___func__ +/* Define this is you want GSSAPI support in the version 2 protocol */ +#undef GSSAPI + /* Define if you want Kerberos 5 support */ #undef KRB5 diff -ru --new-file --exclude=CVS --exclude=configure --exclude=linux --exclude=autom4te-2.53.cache --exclude=config.h.in --exclude='config.h.in~' ../openssh-gssapi/auth-krb5.c ./auth-krb5.c --- ../openssh-gssapi/auth-krb5.c 2003-08-20 23:23:34.000000000 +1000 +++ ./auth-krb5.c 2003-08-23 09:51:41.000000000 +1000 @@ -42,9 +42,6 @@ #ifdef KRB5 #include -#ifndef HEIMDAL -#define krb5_get_err_text(context,code) error_message(code) -#endif /* !HEIMDAL */ extern ServerOptions options; diff -ru --new-file --exclude=CVS --exclude=configure --exclude=linux --exclude=autom4te-2.53.cache --exclude=config.h.in --exclude='config.h.in~' ../openssh-gssapi/auth-pam.c ./auth-pam.c --- ../openssh-gssapi/auth-pam.c 2003-08-20 23:23:34.000000000 +1000 +++ ./auth-pam.c 2003-08-23 09:51:41.000000000 +1000 @@ -648,6 +648,29 @@ pam_strerror(sshpam_handle, sshpam_err)); } +/* + * Set a PAM environment string. We need to do this so that the session + * modules can handle things like Kerberos/GSI credentials that appear + * during the ssh authentication process. + */ + +int +do_pam_putenv(char *name, char *value) +{ + char *compound; + int ret = 1; + +#ifdef HAVE_PAM_PUTENV + compound = xmalloc(strlen(name)+strlen(value)+2); + if (compound) { + sprintf(compound,"%s=%s",name,value); + ret = pam_putenv(sshpam_handle,compound); + xfree(compound); + } +#endif + return (ret); +} + void print_pam_messages(void) { diff -ru --new-file --exclude=CVS --exclude=configure --exclude=linux --exclude=autom4te-2.53.cache --exclude=config.h.in --exclude='config.h.in~' ../openssh-gssapi/auth-pam.h ./auth-pam.h --- ../openssh-gssapi/auth-pam.h 2003-08-20 23:23:34.000000000 +1000 +++ ./auth-pam.h 2003-08-23 09:51:41.000000000 +1000 @@ -38,6 +38,7 @@ void do_pam_setcred(int ); int is_pam_password_change_required(void); void do_pam_chauthtok(void); +int do_pam_putenv(char *, char *); void print_pam_messages(void); char ** fetch_pam_environment(void); void free_pam_environment(char **); diff -ru --new-file --exclude=CVS --exclude=configure --exclude=linux --exclude=autom4te-2.53.cache --exclude=config.h.in --exclude='config.h.in~' ../openssh-gssapi/configure.ac ./configure.ac --- ../openssh-gssapi/configure.ac 2003-08-21 18:01:42.000000000 +1000 +++ ./configure.ac 2003-08-23 09:51:41.000000000 +1000 @@ -822,6 +822,7 @@ AC_CHECK_LIB(dl, dlopen, , ) AC_CHECK_LIB(pam, pam_set_item, , AC_MSG_ERROR([*** libpam missing])) AC_CHECK_FUNCS(pam_getenvlist) + AC_CHECK_FUNCS(pam_putenv) disable_shadow=yes PAM_MSG="yes" @@ -1937,6 +1938,31 @@ fi AC_SEARCH_LIBS(dn_expand, resolv) + AC_CHECK_LIB(gssapi,gss_init_sec_context, + [ AC_DEFINE(GSSAPI) + K5LIBS="-lgssapi $K5LIBS" ], + [ AC_CHECK_LIB(gssapi_krb5,gss_init_sec_context, + [ AC_DEFINE(GSSAPI) + K5LIBS="-lgssapi_krb5 $K5LIBS" ], + AC_MSG_WARN([Cannot find any suitable gss-api library - build may fail]), + $K5LIBS) + ], + $K5LIBS) + + AC_CHECK_HEADER(gssapi.h, , + [ unset ac_cv_header_gssapi_h + CPPFLAGS="$CPPFLAGS -I${KRB5ROOT}/include/gssapi" + AC_CHECK_HEADERS(gssapi.h, , + AC_MSG_WARN([Cannot find any suitable gss-api header - build may fail]) + ) + ] + ) + + oldCPP="$CPPFLAGS" + CPPFLAGS="$CPPFLAGS -I${KRB5ROOT}/include/gssapi" + AC_CHECK_HEADER(gssapi_krb5.h, , + [ CPPFLAGS="$oldCPP" ]) + KRB5=yes fi ] diff -ru --new-file --exclude=CVS --exclude=configure --exclude=linux --exclude=autom4te-2.53.cache --exclude=config.h.in --exclude='config.h.in~' ../openssh-gssapi/defines.h ./defines.h --- ../openssh-gssapi/defines.h 2003-08-21 17:32:50.000000000 +1000 +++ ./defines.h 2003-08-23 09:51:41.000000000 +1000 @@ -521,6 +521,10 @@ # define __func__ "" #endif +#if defined(KRB5) && !defined(HEIMDAL) +# define krb5_get_err_text(context,code) error_message(code) +#endif + /* * Define this to use pipes instead of socketpairs for communicating with the * client program. Socketpairs do not seem to work on all systems. diff -ru --new-file --exclude=CVS --exclude=configure --exclude=linux --exclude=autom4te-2.53.cache --exclude=config.h.in --exclude='config.h.in~' ../openssh-gssapi/gss-serv-krb5.c ./gss-serv-krb5.c --- ../openssh-gssapi/gss-serv-krb5.c 2003-08-23 09:48:10.000000000 +1000 +++ ./gss-serv-krb5.c 2003-08-23 10:03:18.000000000 +1000 @@ -38,7 +38,11 @@ extern ServerOptions options; +#ifdef HEIMDAL #include +#else +#include +#endif static krb5_context krb_context = NULL; @@ -113,11 +117,39 @@ if (ssh_gssapi_krb5_init() == 0) return; +#ifdef HEIMDAL if ((problem = krb5_cc_gen_new(krb_context, &krb5_fcc_ops, &ccache))) { logit("krb5_cc_gen_new(): %.100s", krb5_get_err_text(krb_context, problem)); return; } +#else + { + int tmpfd; + char ccname[40]; + + snprintf(ccname, sizeof(ccname), + "FILE:/tmp/krb5cc_%d_XXXXXX", geteuid()); + + if ((tmpfd = mkstemp(ccname + strlen("FILE:"))) == -1) { + logit("mkstemp(): %.100s", strerror(errno)); + problem = errno; + return; + } + if (fchmod(tmpfd, S_IRUSR | S_IWUSR) == -1) { + logit("fchmod(): %.100s", strerror(errno)); + close(tmpfd); + problem = errno; + return; + } + close(tmpfd); + if ((problem = krb5_cc_resolve(krb_context, ccname, &ccache))) { + logit("krb5_cc_resolve(): %.100s", + krb5_get_err_text(krb_context, problem)); + return; + } + } +#endif /* #ifdef HEIMDAL */ if ((problem = krb5_parse_name(krb_context, client->exportedname.value, &princ))) { @@ -148,6 +180,11 @@ client->store.envvar = "KRB5CCNAME"; client->store.envval = xstrdup(client->store.filename); +#ifdef USE_PAM + if (options.use_pam) + do_pam_putenv(client->store.envvar,client->store.envval); +#endif + krb5_cc_close(krb_context, ccache); return; diff -ru --new-file --exclude=CVS --exclude=configure --exclude=linux --exclude=autom4te-2.53.cache --exclude=config.h.in --exclude='config.h.in~' ../openssh-gssapi/session.c ./session.c --- ../openssh-gssapi/session.c 2003-08-23 09:48:10.000000000 +1000 +++ ./session.c 2003-08-23 09:51:41.000000000 +1000 @@ -418,6 +418,12 @@ session_proctitle(s); +#ifdef GSSAPI + temporarily_use_uid(s->pw); + ssh_gssapi_storecreds(); + restore_uid(); +#endif + #if defined(USE_PAM) if (options.use_pam) { do_pam_session(s->pw->pw_name, NULL); @@ -428,12 +434,6 @@ } #endif /* USE_PAM */ -#ifdef GSSAPI - temporarily_use_uid(s->pw); - ssh_gssapi_storecreds(); - restore_uid(); -#endif - /* Fork the child. */ if ((pid = fork()) == 0) { fatal_remove_all_cleanups(); @@ -553,6 +553,12 @@ ptyfd = s->ptyfd; ttyfd = s->ttyfd; +#ifdef GSSAPI + temporarily_use_uid(s->pw); + ssh_gssapi_storecreds(); + restore_uid(); +#endif + #if defined(USE_PAM) if (options.use_pam) { do_pam_session(s->pw->pw_name, s->tty); @@ -560,12 +566,6 @@ } #endif -#ifdef GSSAPI - temporarily_use_uid(s->pw); - ssh_gssapi_storecreds(); - restore_uid(); -#endif - /* Fork the child. */ if ((pid = fork()) == 0) { fatal_remove_all_cleanups(); diff -ru --new-file --exclude=CVS --exclude=configure --exclude=linux --exclude=autom4te-2.53.cache --exclude=config.h.in --exclude='config.h.in~' ../openssh-gssapi/ssh-gss.h ./ssh-gss.h --- ../openssh-gssapi/ssh-gss.h 2003-08-23 09:48:10.000000000 +1000 +++ ./ssh-gss.h 2003-08-23 10:09:44.000000000 +1000 @@ -31,6 +31,18 @@ #include +#ifdef KRB5 +#ifndef HEIMDAL +#include + +/* MIT Kerberos doesn't seem to define GSS_NT_HOSTBASED_SERVICE */ + +#ifndef GSS_C_NT_HOSTBASED_SERVICE +#define GSS_C_NT_HOSTBASED_SERVICE gss_nt_service_name +#endif /* GSS_C_NT_... */ +#endif /* !HEIMDAL */ +#endif /* KRB5 */ + /* draft-ietf-secsh-gsskeyex-06 */ #define SSH2_MSG_USERAUTH_GSSAPI_RESPONSE 60 #define SSH2_MSG_USERAUTH_GSSAPI_TOKEN 61 diff -ru --new-file --exclude=CVS --exclude=configure --exclude=linux --exclude=autom4te-2.53.cache --exclude=config.h.in --exclude='config.h.in~' ../openssh-gssapi/sshconnect1.c ./sshconnect1.c --- ../openssh-gssapi/sshconnect1.c 2003-08-20 23:23:35.000000000 +1000 +++ ./sshconnect1.c 2003-08-23 09:51:41.000000000 +1000 @@ -20,9 +20,6 @@ #ifdef KRB5 #include -#ifndef HEIMDAL -#define krb5_get_err_text(context,code) error_message(code) -#endif /* !HEIMDAL */ #endif #include "ssh.h" diff -ru --new-file --exclude=CVS --exclude=configure --exclude=linux --exclude=autom4te-2.53.cache --exclude=config.h.in --exclude='config.h.in~' ../openssh-gssapi/sshconnect2.c ./sshconnect2.c --- ../openssh-gssapi/sshconnect2.c 2003-08-23 09:48:10.000000000 +1000 +++ ./sshconnect2.c 2003-08-23 09:51:41.000000000 +1000 @@ -27,9 +27,6 @@ #ifdef KRB5 #include -#ifndef HEIMDAL -#define krb5_get_err_text(context,code) error_message(code) -#endif /* !HEIMDAL */ #endif #include "openbsd-compat/sys-queue.h" From gostl at argoscomp.com Sat Aug 23 10:56:53 2003 From: gostl at argoscomp.com (Jack Gostl) Date: Fri, 22 Aug 2003 20:56:53 -0400 (EDT) Subject: AIX problem In-Reply-To: <3F46B423.385F7F12@zip.com.au> Message-ID: Most excellent! The first suggestion worked like a champ. (I tried it in a controlled environment.) Thanks. On Sat, 23 Aug 2003, Darren Tucker wrote: > Jack Gostl wrote: > > I can buy that. I have no trouble doing the rebuild. The problem is that > > the remote systems are only accessible through ssh. So I either figure out > > a smart way to shut it down, reinstall and restart through a batch file or > > I throw myself on the mercy of the firewall guys. (A pitifully small > > target.) > > Killing the listening sshd will not kill the running sessions, they'll > just end up with a ppid of 1. > > You can also do a couple of things to cut down the risk of snookering > yourself: > > 1) use "./sshd -t" to test your config after building. > > 2) start an sshd on another port, then connect from the host itself: > $ ./sshd -p 2022 -o PidFile=/tmp/sshd.pid > $ ssh -p 2022 localhost > > 3) When doing a "make install", keep a couple of spare sessions running, > then connect to the new sshd in a new window. > > -- Jack Gostl gostl at argoscomp.com From smichaud at pobox.com Sat Aug 23 13:48:19 2003 From: smichaud at pobox.com (Steven Michaud) Date: Fri, 22 Aug 2003 22:48:19 -0500 (CDT) Subject: GSSAPI patch sync from OpenBSD to Portable In-Reply-To: <3F46B731.130D4189@zip.com.au> References: <3F46B731.130D4189@zip.com.au> Message-ID: I compiled and tested with this patch, and had no trouble. I repeated a subset of the tests I talked about in my message of 8-19, this time using a very simple PAM setup (no PAM Kerberos or anything fancy) for some of them. I worked with these three "packages": 1) openssh-SNAP-20030814, patched with Darren's openssh-gssapi-port2.patch 2) OpenSSH 3.6.1p2 patched with Simon Wilkinson's patch 3) OpenSSH 3.5p1 patched with Simon Wilkinson's patch I used ssh from each of these three packages (compiled against either the MIT libraries or the Heimdal ones) to connect to the sshd from the first (compiled against the MIT libraries or the Heimdal ones, using or not using a simple PAM setup). GSSAPI, "Kerberos password" and "UNIX password" authentication all worked (though my simple PAM setup prevented "Kerberos password" authentication from working when I used PAM). Credential forwarding and per-session caches worked where applicable. On Sat, 23 Aug 2003, Darren Tucker wrote: > Steven Michaud wrote: > > Shouldn't the last hunk of gss-serv-krb5.c be this: > > > +#ifdef USE_PAM > > + if (options.use_pam) > > + do_pam_putenv(client->store.envvar, client->store.envval); > > +#endif > > Yes. > > Patch attached is based on Simon's, with that and the retabbifying Ben > mentioned. > > -- > 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 Sat Aug 23 14:15:30 2003 From: djm at mindrot.org (Damien Miller) Date: Sat, 23 Aug 2003 14:15:30 +1000 Subject: Re-using RSA1 keys as RSA In-Reply-To: <3F468AB9.2060108@doxpara.com> References: <20030821211013.B25360@google.com> <20030822210307.GA25939@folly> <3F468AB9.2060108@doxpara.com> Message-ID: <3F46EA62.4040905@mindrot.org> Dan Kaminsky wrote: > I'm not saying it's safe to dual-purpose RSA; I'm just not entirely > sure I've seen evidence it's dangerous to multipurpose the same RSA > key. Have you seen any evidence to the contrary? You have this backwards, we need evidence that this is safe. -d From mailinglistaddie at yahoo.com Sat Aug 23 15:32:47 2003 From: mailinglistaddie at yahoo.com (Mr. Mailing List) Date: Fri, 22 Aug 2003 22:32:47 -0700 (PDT) Subject: watchdog firebox has blocked ssh out In-Reply-To: <3F46B495.60466A7C@zip.com.au> Message-ID: <20030823053247.62754.qmail@web20703.mail.yahoo.com> i used another port, i have port 21 on server forwarding to port 22, but it seems to still block it, unless, in putty, i choose "raw" as protocol. i believe the ssh protocol itself is being blocked? is it possible to somehow come across as using http protocol? --- Darren Tucker wrote: > "Mr. Mailing List" wrote: > > I'm behind a watchdog firebox, which has recently > > blocked ssh out. I have it to where i can use > port > > 21(the server forwards 21 to 22 that i am trying > to > > connect to), but somehow the watchdog firewall is > also > > blocking by protocol type? > > Many state-based firewalls "peek" into the > application layer in order to > handle some protocols. FTP (port 21) is probably > the best-known example > of one where you must do this in order to correctly > firewall (or NAT) it. > > > can i still use raw and somehow start using ssh > after > > this, or something? Or is there some way to > identify > > self as http protocol to the firewall? > > Use another port or talk to your firewall admin. > > -- > 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 __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From dtucker at zip.com.au Sat Aug 23 15:53:10 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 23 Aug 2003 15:53:10 +1000 Subject: watchdog firebox has blocked ssh out References: <20030823053247.62754.qmail@web20703.mail.yahoo.com> Message-ID: <3F470146.3040DC81@zip.com.au> "Mr. Mailing List" wrote: > i used another port, i have port 21 on server > forwarding to port 22, but it seems to still block it, > unless, in putty, i choose "raw" as protocol. i > believe the ssh protocol itself is being blocked? > > is it possible to somehow come across as using http > protocol? Kind of. You can use a HTTP proxy to CONNECT (I think that's in PuTTY 0.53) but after that it's still speaking the SSH protocol. It sounds like you need to use another port through your firewall (ie *not* 21). Talk to your firewall admin. -- 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 gert at greenie.muc.de Sat Aug 23 18:03:53 2003 From: gert at greenie.muc.de (Gert Doering) Date: Sat, 23 Aug 2003 10:03:53 +0200 Subject: AIX problem In-Reply-To: ; from gostl@argoscomp.com on Fri, Aug 22, 2003 at 08:05:58PM -0400 References: <3F46A660.4FBFE753@zip.com.au> Message-ID: <20030823100350.Q20027@greenie.muc.de> Hi, On Fri, Aug 22, 2003 at 08:05:58PM -0400, Jack Gostl wrote: > I can buy that. I have no trouble doing the rebuild. The problem is that > the remote systems are only accessible through ssh. So I either figure out > a smart way to shut it down, reinstall and restart through a batch file or > I throw myself on the mercy of the firewall guys. (A pitifully small > target.) Huh? Just log in, recompile, move the old sshd to "sshd.old", "make install", then kill the old *master* sshd (the one parented by "1") and restart it. Your session will stay up if you do it that way. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From gostl at argoscomp.com Sat Aug 23 18:07:18 2003 From: gostl at argoscomp.com (Jack Gostl) Date: Sat, 23 Aug 2003 04:07:18 -0400 (EDT) Subject: AIX problem In-Reply-To: <20030823100350.Q20027@greenie.muc.de> Message-ID: Thanks. It works. On Sat, 23 Aug 2003, Gert Doering wrote: > Hi, > > On Fri, Aug 22, 2003 at 08:05:58PM -0400, Jack Gostl wrote: > > I can buy that. I have no trouble doing the rebuild. The problem is that > > the remote systems are only accessible through ssh. So I either figure out > > a smart way to shut it down, reinstall and restart through a batch file or > > I throw myself on the mercy of the firewall guys. (A pitifully small > > target.) > > Huh? Just log in, recompile, move the old sshd to "sshd.old", "make > install", then kill the old *master* sshd (the one parented by "1") and > restart it. > > Your session will stay up if you do it that way. > > gert > -- Jack Gostl gostl at argoscomp.com From mailinglistaddie at yahoo.com Sun Aug 24 05:42:56 2003 From: mailinglistaddie at yahoo.com (Mr. Mailing List) Date: Sat, 23 Aug 2003 12:42:56 -0700 (PDT) Subject: watchdog firebox has blocked ssh out In-Reply-To: <3F470146.3040DC81@zip.com.au> Message-ID: <20030823194256.20151.qmail@web20708.mail.yahoo.com> http://www.jfranken.de/homepages/johannes/vortraege/ssh3.en.html it seems as though this is the solution, but how can i do this from an xp machine, with putty? i'd rather not have to install perl and stuff. --- Darren Tucker wrote: > "Mr. Mailing List" wrote: > > i used another port, i have port 21 on server > > forwarding to port 22, but it seems to still block > it, > > unless, in putty, i choose "raw" as protocol. i > > believe the ssh protocol itself is being blocked? > > > > is it possible to somehow come across as using > http > > protocol? > > Kind of. You can use a HTTP proxy to CONNECT (I > think that's in PuTTY > 0.53) but after that it's still speaking the SSH > protocol. > > It sounds like you need to use another port through > your firewall (ie > *not* 21). Talk to your firewall admin. > > -- > 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 __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From dtucker at zip.com.au Sun Aug 24 10:56:02 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 24 Aug 2003 10:56:02 +1000 Subject: [Bug 627] [RELENG] Bugs blocking 3.7p1 References: <20030824003843.CAF9527C1B7@shitei.mindrot.org> Message-ID: <3F480D22.B50B71C7@zip.com.au> bugzilla-daemon at mindrot.org wrote: > This is a tracking bug to group together all the real bugs that we would like to > fix before the release of portable OpenSSH 3.7p1. Would it be a good idea to have a similar record for non-portable SSH and have it as a dependancy to this? Some of the outstanding things apply to it rather than Portable directly. -- 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 mailinglistaddie at yahoo.com Sun Aug 24 12:54:49 2003 From: mailinglistaddie at yahoo.com (Mr. Mailing List) Date: Sat, 23 Aug 2003 19:54:49 -0700 (PDT) Subject: watchdog firebox has blocked ssh out In-Reply-To: <3F470146.3040DC81@zip.com.au> Message-ID: <20030824025449.37336.qmail@web20702.mail.yahoo.com> http://www.jfranken.de/homepages/johannes/vortraege/ssh3.en.html --- Darren Tucker wrote: > "Mr. Mailing List" wrote: > > i used another port, i have port 21 on server > > forwarding to port 22, but it seems to still block > it, > > unless, in putty, i choose "raw" as protocol. i > > believe the ssh protocol itself is being blocked? > > > > is it possible to somehow come across as using > http > > protocol? > > Kind of. You can use a HTTP proxy to CONNECT (I > think that's in PuTTY > 0.53) but after that it's still speaking the SSH > protocol. > > It sounds like you need to use another port through > your firewall (ie > *not* 21). Talk to your firewall admin. > > -- > 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 __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From smichaud at pobox.com Mon Aug 25 02:58:43 2003 From: smichaud at pobox.com (Steven Michaud) Date: Sun, 24 Aug 2003 11:58:43 -0500 (CDT) Subject: gss userauth (fwd) Message-ID: > I've pointed out this to the authors privatly, so I'll repeat this > publicly. I consider gss userauth to be broken since it doesn't > verify the session id (using either mic or a channel bindings (like > in CCM)). > > Love This is currently being discussed on the ietf-ssh mailing list (ietf-ssh at netbsd.org, archives at ftp://ftp.ietf.org/ietf-mail-archive/secsh/), to which Love posted his message on 8-22. (For those who don't know it, Love is one of the Heimdal Kerberos developers (and recently the most active one) -- http://www.pdc.kth.se/heimdal/) Even in the most recent "GSSAPI Authentication and Key Exchange for the Secure Shell Protocol" draft (http://www.ietf.org/internet-drafts/draft-ietf-secsh-gsskeyex-06.txt), "gss userauth" doesn't "verify the session id". Nor does Simon Wilkinson's implementation of it. Gss key exchange already does "verify the session id" (in the IETF draft and in Simon's implementation), and there seems to be a consensus that gss userauth should also -- possibly by using the same method as gss key exchange (an extra message, which in the case of gss userauth could be sent from the client to the server, and need not require an extra round trip). The public is already using an implementation of the current IETF draft -- OpenSSH with Simon Wilkinson's patch. So whatever changes the IETF Secure Shell working group makes need to be backwards compatible -- on which there also seems to be a consensus. Finally, despite what Love says, the gssapi protocol as used by gss userauth already does provide mutual authentication between the client and the server. It's just doesn't do it as neatly as gss key exchange, and a copy of the server's public key still needs to be stored on the client side. Yes, gss key exchange handles mutual authentication better (though not more securely) than gss userauth currently does. And OpenSSH should eventually implement gss key exchange (and the new-and-improved gss userauth, whenever that gets finalized). But I don't see any reason why Darren Tucker's openssh-gssapi-port2.patch shouldn't go into OpenSSH 3.7 as is. Let's not make the best the enemy of the good :-) From smichaud at pobox.com Mon Aug 25 04:31:36 2003 From: smichaud at pobox.com (Steven Michaud) Date: Sun, 24 Aug 2003 13:31:36 -0500 (CDT) Subject: gss userauth (fwd) In-Reply-To: References: Message-ID: On Sun, 24 Aug 2003, Steven Michaud wrote: > Finally, despite what Love says, the gssapi protocol as used by gss > userauth already does provide mutual authentication between the > client and the server. It's just doesn't do it as neatly as gss key > exchange, and a copy of the server's public key still needs to be > stored on the client side. > > Yes, gss key exchange handles mutual authentication better (though > not more securely) than gss userauth currently does. And OpenSSH > should eventually implement gss key exchange (and the > new-and-improved gss userauth, whenever that gets finalized). But I > don't see any reason why Darren Tucker's openssh-gssapi-port2.patch > shouldn't go into OpenSSH 3.7 as is. I need to clarify a bit: As best I can tell, making gss userauth "verify the session id" won't fix the problem of forcing the client to store a copy of the server's public key. Though I'll post a message to ietf-ssh asking if it's reasonable to change gss userauth to solve this problem, too. And it's true that, in general, relying on the client to store the server's public key can weaken security -- think of how many people react to server-key error messages by deleting the client-side server-key cache. But this behavior _doesn't_ weaken gss userauth's security (even in the current standard) -- it can't override the gssapi protocol's mutual (client-server) authentication. From dtucker at zip.com.au Mon Aug 25 12:23:22 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 25 Aug 2003 12:23:22 +1000 Subject: GSSAPI patch sync from OpenBSD to Portable References: <3F46B731.130D4189@zip.com.au> Message-ID: <3F49731A.B7B3E7D9@zip.com.au> Steven Michaud wrote > I compiled and tested with this patch, and had no trouble. > > I repeated a subset of the tests I talked about in my message of 8-19, > this time using a very simple PAM setup (no PAM Kerberos or anything > fancy) for some of them. > > I worked with these three "packages": > > 1) openssh-SNAP-20030814, patched with Darren's > openssh-gssapi-port2.patch Just to be clear: this is still Simon's work, not mine. > 2) OpenSSH 3.6.1p2 patched with Simon Wilkinson's patch > 3) OpenSSH 3.5p1 patched with Simon Wilkinson's patch Thanks for the testing. Barring further changes or objections I'll commit both the OpenBSD sync patch and this modified Portable patch tomorrow (with [BEFORE|AFTER]_KRB5_GSSAPI_MERGE tags). -- 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 philipp.marek at bmlv.gv.at Mon Aug 25 16:47:58 2003 From: philipp.marek at bmlv.gv.at (Ph. Marek) Date: Mon, 25 Aug 2003 08:47:58 +0200 Subject: splitting big authorized_keys files In-Reply-To: <20030819083019.GA16717@folly> References: <200308191014.36449.philipp.marek@bmlv.gv.at> <20030819083019.GA16717@folly> Message-ID: <200308250847.58916.philipp.marek@bmlv.gv.at> > > But that gives me a user, whose ~/.ssh/authorized_keys file has about > > 15000 entries. > > the current scheme was not intented for 15000 entries, you > should try to switch some database... "man 5 nsswitch" shows that even /etc/passwd and shadow can be done through a db backend. Is anyone opposed to having an index for ~/.ssh/authorized_keys? Regards, Phil From STrujillo at BudgetTruck.com Tue Aug 26 01:53:22 2003 From: STrujillo at BudgetTruck.com (STrujillo at BudgetTruck.com) Date: Mon, 25 Aug 2003 09:53:22 -0600 Subject: Open SSH question Message-ID: Hello, I had a few questions about the Open SSH. If we download a copy of this software to a business machine for internal business usage only will we need to purchase licenses for each individual that will be accessing this application. How do you protect your downloads from viruses when they are downloaded to keep my computer from getting infected? Is Binary coding for compiling available for us to use? I hope I explained this questions clear enough to answer. If not please contact me and we can discuss my questions. Thank you, Sil Trujillo Procurement 303-376-7007 From bfrantzdale at hmc.edu Tue Aug 26 02:13:23 2003 From: bfrantzdale at hmc.edu (Ben FrantzDale) Date: Mon, 25 Aug 2003 09:13:23 -0700 Subject: Key authenticity warning suggestion Message-ID: <1061828002.552.172.camel@en-dash> Until recently I was unaware of how to get the key fingerprint of a host using ssh-keygen. Finding that out took asking several security-minded people. In other words, I don't think it's public knowledge. This made me think that the warning could be changed to something along these lines: The authenticity of host '192.168.0.123' can't be established. RSA key fingerprint in md5 is: 59:94:5a:d7:2b:1f:ad:6e:ef:24:4c:71:1d:3c:3b:4a If you have access to '192.168.0.123' you can run ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub on it to verify this key fingerprint. Are you sure you want to continue connecting(yes/no)?yes Warning: Permanently added '192.168.0.123' (RSA) to the list of known hosts. What do you think? --Ben From dberezin at acs.rutgers.edu Tue Aug 26 02:16:43 2003 From: dberezin at acs.rutgers.edu (Dmitry Berezin) Date: Mon, 25 Aug 2003 12:16:43 -0400 Subject: No interest in partial auth? Message-ID: <3F4A366B.7080805@acs.rutgers.edu> Hi, I just want to add that I agree with Erik about having a need for partial authentication in OpenSSH. We use SecurID cards in addition to password authentication for all users and the way this has to be setup breaks scp and sftp since we have to use interactive shell (sdshell) for SecurID authentication. Now, there is a patch for OpenSSH that enables support for SecurID, but then I'd have to choose between password and SecurID authentication, not both. Indeed, commercial versions of SSH allow to specify a list of valid auth methods and how many of them must succeed. This would be a very useful addition to OpenSSH functionality. -Dmitry. > Erik-- > > Well, even _I'm_ having trouble coming up with situations where >partial auth is useful, and I'm always breaking ssh :-) > > But I imagine you've got some creative uses...perhaps we can >simultaneously satisfy your needs for functionality, the "cabal"'s need >for simplicity, and my enjoyment of doing things that I can't entirely >predict the consequence of. All, why don't we create a new environment >variable, $SSH_AUTHTYPE, that contains the method by which the user >logged into the server? We already allow users to enable or disable >certain types of auth; why not allow the shell to make its own >decisions >based on what the user selected? Instead of hardcoding a few decision >types, hand something like: > >SSH_AUTHTYPE=password > >or > >SSH_AUTHTYPE=pubkey >SSH_AUTHKEY=ssh-dss >AAAAB3NzaC1kc3MAAACBAOaR3q/NFbHKzr2p7Pv0twMzhfgvor0l2JVYY4sIzO14+5rdudV8M0aUis4/+w07AL8OQy413xdyppHqBLxgj3gCCXOOjGbhSyCFaQbC6xTIClQISNA5X9JkO4OuaqJUD65qvD5ArsXyjRVWMHWjPtVVF6uzBSjnVN50IDJoCKl9AAAAFQDDXmMMBXvJophSgrqOVezFvpTQ5wAAAIEA0gcZsNVOsn6nSG+r0wD5mlloz5S7YL+ePCAJI6qY/0lOoV50uSIZoK5iWMgVLNrOLTkIv0MkYpt93HzY3zAvH7iSnbWHXdD+j+XTP6xN9ImnePlXFx8whe3kEduqitY41baGiFZq8zSCNfErp/GuzYcGH13O4Cb1zYyvD0mzxvgAAACABHFilqR7fRHbKrTN93cYJ8B+0zKeYx0Ov5L/02ZqwOWSKttRS3AiW1Imxg5af3AUyP6fyMpy8LzvianxzC/uQKcr3KfM9RXm99LOv9/yjr00v8LudwkThkUAOD9HzeMvOQooxk+pOm+sAx1MW7qUuadYHQL8usf8nY7VqDjqeUA= > >to shells for their own use -- a little like $SSH_CLIENT. This should >be just a small patch, and would enable others to elegantly use their >preferred method of partial (not multimode, though) authentication. > > Speaking of shells -- it would be useful, so as to not excessively >impact other services, to have a sshd_config entry for a preshell -- a >shell that is used to execute the user's shell of choice. This maps >well to the different goals of users and admins. > > Thoughts? > >--Dan From Darren.Moffat at Sun.COM Tue Aug 26 02:26:41 2003 From: Darren.Moffat at Sun.COM (Darren J Moffat) Date: Mon, 25 Aug 2003 09:26:41 -0700 (PDT) Subject: Key authenticity warning suggestion In-Reply-To: <1061828002.552.172.camel@en-dash> Message-ID: On Mon, 25 Aug 2003, Ben FrantzDale wrote: > Until recently I was unaware of how to get the key fingerprint of a host > using ssh-keygen. Finding that out took asking several security-minded > people. In other words, I don't think it's public knowledge. > > This made me think that the warning could be changed to something along > these lines: > > The authenticity of host '192.168.0.123' can't be established. > RSA key fingerprint in md5 is: 59:94:5a:d7:2b:1f:ad:6e:ef:24:4c:71:1d:3c:3b:4a > If you have access to '192.168.0.123' you can run > ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key.pub > on it to verify this key fingerprint. > Are you sure you want to continue connecting(yes/no)?yes > Warning: Permanently added '192.168.0.123' (RSA) to the list of known hosts. > > What do you think? That assumes that the remote machine is also running OpenSSH, which may not be the case. It is also making assumptions about the location and name of the host key (which is configurable in OpenSSH and other implementations). -- Darren J Moffat From bfrantzdale at hmc.edu Tue Aug 26 02:56:54 2003 From: bfrantzdale at hmc.edu (Ben FrantzDale) Date: Mon, 25 Aug 2003 09:56:54 -0700 Subject: Key authenticity warning suggestion In-Reply-To: References: Message-ID: <1061830611.552.191.camel@en-dash> On Mon, 2003-08-25 at 09:26, Darren J Moffat wrote: > On Mon, 25 Aug 2003, Ben FrantzDale wrote: > > ... > > What do you think? > > That assumes that the remote machine is also running OpenSSH, which may > not be the case. It is also making assumptions about the location and > name of the host key (which is configurable in OpenSSH and other > implementations). That is true. I would guess that the people who would bother checking would probably be able to figure it out. In the interest of correctness, the message could say If you have access to '192.168.0.123' and it runs OpenSSH, you may be able to run ssh-keygen -l -f /etc/ssh/ssh_host_rsa_key on it to verify this key fingerprint. However it might be phrased, even the clue that ssh-keygen -l -f is a likely way to check would be extremely helpful. --Ben From stuge-openssh-unix-dev at cdy.org Tue Aug 26 03:37:36 2003 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Mon, 25 Aug 2003 19:37:36 +0200 Subject: splitting big authorized_keys files In-Reply-To: <200308250847.58916.philipp.marek@bmlv.gv.at> References: <200308191014.36449.philipp.marek@bmlv.gv.at> <20030819083019.GA16717@folly> <200308250847.58916.philipp.marek@bmlv.gv.at> Message-ID: <20030825173735.GA26181@foo.birdnet.se> On Mon, Aug 25, 2003 at 08:47:58AM +0200, Ph. Marek wrote: > > > But that gives me a user, whose ~/.ssh/authorized_keys file has about > > > 15000 entries. > > > > the current scheme was not intented for 15000 entries, you > > should try to switch some database... > > "man 5 nsswitch" shows that even /etc/passwd and shadow can be done > through a db backend. > > Is anyone opposed to having an index for ~/.ssh/authorized_keys? I think most of the developers are opposed to implementing a database system in OpenSSH. It is certainly outside the scope of the program. Further, I don't think nsswitch is quite as portable as OpenSSH-portable, meaning it's not something we want to rely on. I suggest you modify a version of OpenSSH so that it works reliably and performs well for you, or hire someone to do so, and then present the changes, preferably in diff -U format, to this mailing list. I believe someone suggested using cdb by Dan J. Berstein, my experiences with that database, although somewhat shallow, tells me it's well-suited for the job. Please do check license and portability status of whatever package you decide to use, "You may distribute unmodified copies of the cdb package. Packages that need to read cdb files should incorporate the necessary portions of the cdb library rather than relying on an external cdb library." and "cdb works only under UNIX." applies to cdb, e.g. I would guess that the wording in the license will be a problem, should you want your changes included in mainstream OpenBSD OpenSSH, and probably in -portable, too. For a different (and more UNIX-like) way of solving your problem, OpenSSH could be made to use an external command for it's databases, like the client currently uses external commands for proxy handling. (man ssh_config, look for ProxyCommand) That way, you could use your favorite database for the job, as long as simple commands can be created for reading and writing. I'm not sure how this latter addition would be received by the group, but I am sure that it's better than creating an OpenSSH database system. Although I personally wouldn't have anything against the feature, except of course that it is yet another feature, the implementation could turn out to be messy. Please investigate, though. //Peter From STrujillo at BudgetTruck.com Tue Aug 26 05:25:28 2003 From: STrujillo at BudgetTruck.com (STrujillo at BudgetTruck.com) Date: Mon, 25 Aug 2003 13:25:28 -0600 Subject: Open SSH question Message-ID: Sil Trujillo Procurement 303-376-7007 ----- Forwarded by Sil D Trujillo/OU/BudgetTruck on 08/25/03 01:25 PM ----- Sil D Trujillo 08/25/03 09:53 AM To: openssh-unix-dev at mindrot.org cc: Subject: Open SSH question Hello, I had a few questions about the Open SSH. If we download a copy of this software to a business machine for internal business usage only will we need to purchase licenses for each individual that will be accessing this application. How do you protect your downloads from viruses when they are downloaded to keep my computer from getting infected? Is Binary coding for compiling available for us to use? I hope I explained this questions clear enough to answer. If not please contact me and we can discuss my questions. Thank you, Sil Trujillo Procurement 303-376-7007 From mailinglistaddie at yahoo.com Tue Aug 26 05:48:19 2003 From: mailinglistaddie at yahoo.com (Mr. Mailing List) Date: Mon, 25 Aug 2003 12:48:19 -0700 (PDT) Subject: watchdog firebox has blocked ssh out In-Reply-To: <3F470146.3040DC81@zip.com.au> Message-ID: <20030825194819.42727.qmail@web20708.mail.yahoo.com> what is further confusing is, i can telnet through port 21 to sshd, and i get "openssh" stuff, but i cannot ssh to that same port(get nothing) is it possible, then, to somehow mask the ssh as telnet or something? --- Darren Tucker wrote: > "Mr. Mailing List" wrote: > > i used another port, i have port 21 on server > > forwarding to port 22, but it seems to still block > it, > > unless, in putty, i choose "raw" as protocol. i > > believe the ssh protocol itself is being blocked? > > > > is it possible to somehow come across as using > http > > protocol? > > Kind of. You can use a HTTP proxy to CONNECT (I > think that's in PuTTY > 0.53) but after that it's still speaking the SSH > protocol. > > It sounds like you need to use another port through > your firewall (ie > *not* 21). Talk to your firewall admin. > > -- > 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 __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From markus at openbsd.org Tue Aug 26 05:55:25 2003 From: markus at openbsd.org (Markus Friedl) Date: Mon, 25 Aug 2003 21:55:25 +0200 Subject: No interest in partial auth? In-Reply-To: <3F4A366B.7080805@acs.rutgers.edu> References: <3F4A366B.7080805@acs.rutgers.edu> Message-ID: <20030825195525.GB28131@folly> On Mon, Aug 25, 2003 at 12:16:43PM -0400, Dmitry Berezin wrote: > I just want to add that I agree with Erik about having a need for > partial authentication in OpenSSH. We use SecurID cards in addition to > password authentication for all users and the way this has to be setup > breaks scp and sftp since we have to use interactive shell (sdshell) for > SecurID authentication. Now, there is a patch for OpenSSH that enables > support for SecurID, but then I'd have to choose between password and > SecurID authentication, not both. Indeed, commercial versions of SSH > allow to specify a list of valid auth methods and how many of them must this feature but be useful, but the implementation has to be simple. From mouring at etoh.eviladmin.org Tue Aug 26 05:55:28 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Mon, 25 Aug 2003 14:55:28 -0500 (CDT) Subject: watchdog firebox has blocked ssh out In-Reply-To: <20030825194819.42727.qmail@web20708.mail.yahoo.com> Message-ID: The answer is no. Discuss the issue with your Firewall admin. This is starting to be off-topic. - Ben On Mon, 25 Aug 2003, Mr. Mailing List wrote: > what is further confusing is, i can telnet through > port 21 to sshd, and i get "openssh" stuff, but i > cannot ssh to that same port(get nothing) > > is it possible, then, to somehow mask the ssh as > telnet or something? > > > --- Darren Tucker wrote: > > "Mr. Mailing List" wrote: > > > i used another port, i have port 21 on server > > > forwarding to port 22, but it seems to still block > > it, > > > unless, in putty, i choose "raw" as protocol. i > > > believe the ssh protocol itself is being blocked? > > > > > > is it possible to somehow come across as using > > http > > > protocol? > > > > Kind of. You can use a HTTP proxy to CONNECT (I > > think that's in PuTTY > > 0.53) but after that it's still speaking the SSH > > protocol. > > > > It sounds like you need to use another port through > > your firewall (ie > > *not* 21). Talk to your firewall admin. > > > > -- > > 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 > > > __________________________________ > Do you Yahoo!? > Yahoo! SiteBuilder - Free, easy-to-use web site design software > http://sitebuilder.yahoo.com > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From mailinglistaddie at yahoo.com Tue Aug 26 07:04:38 2003 From: mailinglistaddie at yahoo.com (Mr. Mailing List) Date: Mon, 25 Aug 2003 14:04:38 -0700 (PDT) Subject: watchdog firebox has blocked ssh out In-Reply-To: Message-ID: <20030825210438.29876.qmail@web20701.mail.yahoo.com> i'm not sure how this is offtopic when there is a howto regarding it on the openssh site. --- Ben Lindstrom wrote: > > The answer is no. Discuss the issue with your > Firewall admin. This is > starting to be off-topic. > > - Ben > > On Mon, 25 Aug 2003, Mr. Mailing List wrote: > > > what is further confusing is, i can telnet through > > port 21 to sshd, and i get "openssh" stuff, but i > > cannot ssh to that same port(get nothing) > > > > is it possible, then, to somehow mask the ssh as > > telnet or something? > > > > > > --- Darren Tucker wrote: > > > "Mr. Mailing List" wrote: > > > > i used another port, i have port 21 on server > > > > forwarding to port 22, but it seems to still > block > > > it, > > > > unless, in putty, i choose "raw" as protocol. > i > > > > believe the ssh protocol itself is being > blocked? > > > > > > > > is it possible to somehow come across as using > > > http > > > > protocol? > > > > > > Kind of. You can use a HTTP proxy to CONNECT (I > > > think that's in PuTTY > > > 0.53) but after that it's still speaking the SSH > > > protocol. > > > > > > It sounds like you need to use another port > through > > > your firewall (ie > > > *not* 21). Talk to your firewall admin. > > > > > > -- > > > 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 > > > > > > __________________________________ > > Do you Yahoo!? > > Yahoo! SiteBuilder - Free, easy-to-use web site > design software > > http://sitebuilder.yahoo.com > > > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev __________________________________ Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software http://sitebuilder.yahoo.com From jmknoble at pobox.com Tue Aug 26 08:37:05 2003 From: jmknoble at pobox.com (Jim Knoble) Date: Mon, 25 Aug 2003 18:37:05 -0400 Subject: Open SSH question In-Reply-To: References: Message-ID: <20030825223705.GE7312@crawfish.ais.com> Circa 2003-08-25 09:53:22 -0600 dixit STrujillo at BudgetTruck.com: : If we download a copy of this software to a business machine for : internal business usage only will we need to purchase licenses for : each individual that will be accessing this application. [1] : : How do you protect your downloads from viruses when they are : downloaded to keep my computer from getting infected? [2] : : Is Binary coding for compiling available for us to use? [3] Circa 2003-08-25 13:25:28 -0600 dixit STrujillo at BudgetTruck.com: [the same thing] I've numbered your questions above, and my answers are numbered the same way. (1) OpenSSH is free software. You don't need to purchase any licenses to use it. In fact, you can copy it, modify it, sell it, distribute it, or hang it on your wall---the only requirement is that you preserve the copyright notices included with the software. By the same token, OpenSSH comes with no warranty. You can do whatever you want with it, but there is no one to blame if something goes wrong or if it does not meet your expectations. (2) OpenSSH is generally distributed as "source code" which must be configured, compiled, and installed onto a target system before it is usable. The OpenSSH source code is available from the locations listed on the OpenSSH website ( http://www.openssh.com/portable.html ). Detached cryptographic signatures are available from the same locations. You can use the (freely available) GnuPG tool ( http://www.gnupg.org/ ) to verify the signature against the archive containing the source code. The public key necessary to validate the signatures is also available from the same locations as the source code, but it's not a good idea to trust that key; it's better to get the necessary key from a public keyserver (or, even better, from someone you trust). Various kinds of pre-compiled packages of OpenSSH are available; you should only use these if you trust their source and can verify the integrity of the packages yourself. (3) See answer number 2 above. Good luck. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG fingerprint: 31C4:8AAC:F24E:A70C:4000::BBF4:289F:EAA8:1381:1491) "We have guided missiles and misguided men." --Martin Luther King, Jr. -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 256 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030825/7f49bc34/attachment.bin From djm at mindrot.org Tue Aug 26 08:41:54 2003 From: djm at mindrot.org (Damien Miller) Date: Mon, 25 Aug 2003 22:41:54 -0000 Subject: watchdog firebox has blocked ssh out In-Reply-To: <20030825210438.29876.qmail@web20701.mail.yahoo.com> References: <20030825210438.29876.qmail@web20701.mail.yahoo.com> Message-ID: <1061851130.7645.10.camel@sakura.mindrot.org> On Tue, 2003-08-26 at 07:04, Mr. Mailing List wrote: > i'm not sure how this is offtopic when there is a > howto regarding it on the openssh site. We are here to improve OpenSSH, not to debug your firewall. -d From dtucker at zip.com.au Tue Aug 26 10:50:30 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 26 Aug 2003 10:50:30 +1000 Subject: Locked account checks and PAM Message-ID: <3F4AAED6.F442EC42@zip.com.au> Hi All. I (actually the tinderbox[1]) found a problem with the fix for bug #422: when PAM is enabled on a platform that uses /etc/shadow, the variable "passwd" in auth.c is used uninitialized. There's a simple patch attached to fix this. The question is: should the locked account test be done when PAM is enabled or should we rely on PAM to do the right thing? In theory they should behave the same way, but ISTR that in some patchlevels of Solaris PAM did not check for this. [1] http://dodgynet.dyndns.org/tinderbox/OpenSSH_Portable/status.html -- 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 -------------- Index: auth.c =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh_cvs/auth.c,v retrieving revision 1.75 diff -u -p -r1.75 auth.c --- auth.c 25 Aug 2003 01:51:19 -0000 1.75 +++ auth.c 25 Aug 2003 13:56:25 -0000 @@ -73,7 +73,7 @@ int allowed_user(struct passwd * pw) { struct stat st; - const char *hostname = NULL, *ipaddr = NULL, *passwd; + const char *hostname = NULL, *ipaddr = NULL, *passwd = NULL; char *shell; int i; #if defined(HAVE_SHADOW_H) && !defined(DISABLE_SHADOW) @@ -85,8 +85,7 @@ allowed_user(struct passwd * pw) return 0; #if defined(HAVE_SHADOW_H) && !defined(DISABLE_SHADOW) - if (!options.use_pam) - spw = getspnam(pw->pw_name); + spw = getspnam(pw->pw_name); #ifdef HAS_SHADOW_EXPIRE #define DAY (24L * 60 * 60) /* 1 day in seconds */ if (!options.use_pam && spw != NULL) { From hari at isofttech.com Tue Aug 26 11:25:28 2003 From: hari at isofttech.com (Hari (E-mail)) Date: Mon, 25 Aug 2003 21:25:28 -0400 Subject: Bad packet length error Message-ID: <04ef01c36b70$f1625b50$66fe10ac@axiowave.com> Hi, I am running sshd (openssh-2.9p2) on a power-pc LynxOS box, and am connecting from a ssh client (openssh-2.9p2) on an x86 Linux box. This works fine for ssh protocol version 1, but am getting the below error for ssh v2: Disconnecting: Bad packet length -857542839. I am also attaching the complete debug traces from sshd & ssh below. I am not sure if this is an "endian" issue. Could anyone help me out in debugging this. Thanks in advance, Hari ======================================================= server trace: ./sshd -d -d -d debug1: Seeding random number generator debug1: sshd version OpenSSH_2.9p2 debug1: private host key: #0 type 0 RSA1 debug3: No RSA1 key file /usr/etc/ssh/ssh_host_rsa_key. debug1: read PEM private key done: type RSA debug1: private host key: #1 type 1 RSA debug3: No RSA1 key file /usr/etc/ssh/ssh_host_dsa_key. debug1: read PEM private key done: type DSA debug1: private host key: #2 type 2 DSA debug1: Bind to port 22 on 0.0.0.0. Server listening on 0.0.0.0 port 22. Generating 768 bit RSA key. RSA key generation complete. debug1: Server will not fork when running in debugging mode. Connection from 192.168.0.3 port 3795 debug1: Client protocol version 2.0; client software version OpenSSH_2.9p2 debug1: match: OpenSSH_2.9p2 pat ^OpenSSH Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-1.99-OpenSSH_2.9p2 debug1: Rhosts Authentication disabled, originating port not trusted. debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,r ijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,r ijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm ac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm ac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,r ijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,r ijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm ac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm ac-md5-96 debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent debug1: dh_gen_key: priv key bits set: 128/256 debug1: bits set: 1013/2049 debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT debug1: bits set: 1035/2049 debug2: ssh_rsa_sign: done debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: KEX done cce2 ef49 0301 2989 12ca ba7f ccf1 72e8 Disconnecting: Bad packet length -857542839. debug1: Calling cleanup 0x2000d39c(0x0) ============================================ client trace: ssh -v -v -v -2 root at 192.168.0.27 OpenSSH_2.9p2, SSH protocols 1.5/2.0, OpenSSL 0x0090581f debug1: Reading configuration data /etc/ssh/ssh_config debug1: Seeding random number generator debug1: Rhosts Authentication disabled, originating port will not be trusted. debug1: restore_uid debug1: ssh_connect: getuid 516 geteuid 0 anon 1 debug1: Connecting to 192.168.0.27 [192.168.0.27] port 22. debug1: temporarily_use_uid: 516/106 (e=0) debug1: restore_uid debug1: temporarily_use_uid: 516/106 (e=0) debug1: restore_uid debug1: Connection established. debug1: read PEM private key done: type DSA debug1: read PEM private key done: type RSA debug3: No RSA1 key file /home/hari/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: no key found debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: no key found debug1: identity file /home/hari/.ssh/id_rsa type 1 debug3: No RSA1 key file /home/hari/.ssh/id_dsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: no key found debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug3: key_read: no space debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: no key found debug1: identity file /home/hari/.ssh/id_dsa type 2 debug1: Remote protocol version 1.99, remote software version OpenSSH_2.9p2 debug1: match: OpenSSH_2.9p2 pat ^OpenSSH Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_2.9p2 debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,r ijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,r ijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm ac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm ac-md5-96 debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: none debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,r ijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour,aes192-cbc,aes256-cbc,r ijndael128-cbc,rijndael192-cbc,rijndael256-cbc,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm ac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hm ac-md5-96 debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: none,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_init: found hmac-md5 debug1: kex: server->client aes128-cbc hmac-md5 none debug2: mac_init: found hmac-md5 debug1: kex: client->server aes128-cbc hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug1: dh_gen_key: priv key bits set: 124/256 debug1: bits set: 1035/2049 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /home/hari/.ssh/known_hosts2 debug3: check_host_in_hostfile: match line 12 debug1: Host '192.168.0.27' is known and matches the RSA host key. debug1: Found key in /home/hari/.ssh/known_hosts2:12 debug1: bits set: 1013/2049 debug1: ssh_rsa_verify: signature correct debug1: kex_derive_keys debug1: newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: waiting for SSH2_MSG_NEWKEYS debug1: newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: done: ssh_kex2. debug1: send SSH2_MSG_SERVICE_REQUEST 36a6 9c0c d787 4182 fc82 114e 8d37 0d3b Disconnecting: Bad packet length 916888588. debug1: Calling cleanup 0x8063510(0x0) ====================================================== From jason at devrandom.org Tue Aug 26 12:16:39 2003 From: jason at devrandom.org (Jason McCormick) Date: Mon, 25 Aug 2003 22:16:39 -0400 Subject: Bad packet length error In-Reply-To: <04ef01c36b70$f1625b50$66fe10ac@axiowave.com> References: <04ef01c36b70$f1625b50$66fe10ac@axiowave.com> Message-ID: <200308252216.39405.jason@devrandom.org> > I am running sshd (openssh-2.9p2) on a power-pc LynxOS box, and am > connecting from a ssh client (openssh-2.9p2) on an x86 Linux box. Please try upgrading to a current version. The current version is OpenSSH 3.6p1. Many bugs of this sort have been fixed long ago. -- Jason McCormick jason at devrandom.org GPG Key: http://www.devrandom.org/gpgkey.php GPG Fingerprint: 66C5 2B15 3E34 2B5E 5321 6147 303A DCE6 0A74 A19C From yoshfuji at linux-ipv6.org Tue Aug 26 12:25:22 2003 From: yoshfuji at linux-ipv6.org (YOSHIFUJI Hideaki / =?iso-2022-jp?B?GyRCNUhGIzFRTEAbKEI=?=) Date: Tue, 26 Aug 2003 11:25:22 +0900 (JST) Subject: Bad packet length error In-Reply-To: <200308252216.39405.jason@devrandom.org> References: <04ef01c36b70$f1625b50$66fe10ac@axiowave.com> <200308252216.39405.jason@devrandom.org> Message-ID: <20030826.112522.93622006.yoshfuji@linux-ipv6.org> In article <200308252216.39405.jason at devrandom.org> (at Mon, 25 Aug 2003 22:16:39 -0400), Jason McCormick says: > > I am running sshd (openssh-2.9p2) on a power-pc LynxOS box, and am > > connecting from a ssh client (openssh-2.9p2) on an x86 Linux box. > > Please try upgrading to a current version. The current version is > OpenSSH 3.6p1. Many bugs of this sort have been fixed long ago. 3.6.1p2 -- Hideaki YOSHIFUJI @ USAGI Project GPG FP: 9022 65EB 1ECF 3AD1 0BDF 80D8 4807 F894 E062 0EEA From jason at devrandom.org Tue Aug 26 12:27:43 2003 From: jason at devrandom.org (Jason McCormick) Date: Mon, 25 Aug 2003 22:27:43 -0400 Subject: Bad packet length error In-Reply-To: <04ef01c36b70$f1625b50$66fe10ac@axiowave.com> References: <04ef01c36b70$f1625b50$66fe10ac@axiowave.com> Message-ID: <200308252227.43056.jason@devrandom.org> Actually meant that to be 3.6.1p2..... -- Jason McCormick jason at devrandom.org GPG Key: http://www.devrandom.org/gpgkey.php GPG Fingerprint: 66C5 2B15 3E34 2B5E 5321 6147 303A DCE6 0A74 A19C From dtucker at zip.com.au Tue Aug 26 12:33:54 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 26 Aug 2003 12:33:54 +1000 Subject: Bad packet length error References: <04ef01c36b70$f1625b50$66fe10ac@axiowave.com> Message-ID: <3F4AC712.172912F7@zip.com.au> "Hari (E-mail)" wrote: > I am running sshd (openssh-2.9p2) on a power-pc LynxOS box, and am > connecting from a ssh client (openssh-2.9p2) on an x86 Linux box. > This works fine for ssh protocol version 1, but am getting the below error > for ssh v2: > > Disconnecting: Bad packet length -857542839. There has been a history of "bad packet length" errors that were fixed by upgrading the version of zlib used. What version are you using, and does the problem go away if you recompile openssh with zlib 1.4? -- 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 hari at isofttech.com Tue Aug 26 13:32:49 2003 From: hari at isofttech.com (Hari) Date: Mon, 25 Aug 2003 23:32:49 -0400 Subject: Bad packet length error In-Reply-To: <3F4AC609.9020906@icon-labs.com> Message-ID: <04f101c36b82$baff4d40$66fe10ac@axiowave.com> Thanks Pete, I just tried with WORDS_BIGENDIAN defined and it helped solve this issue. Apparently this is what happened: I am using a cross-compiler for building openssh and I could not run configure on the cross-compiler environment. I have initially run the configure on an x86 box and used the thus created config.h and Makefile for building in the cross-compiler env. At some point when I moved to power-pc, I failed to modify/obtain new config.h and Makefile. How do we handle this for different platforms when using a cross-compiler ? Right now, I am doing an #ifdef __ in config.h Thanks, Hari -----Original Message----- From: Pete Flugstad [mailto:pete.flugstad at icon-labs.com] Sent: Monday, August 25, 2003 10:29 PM To: hari at isofttech.com Subject: Re: Bad packet length error I've seen this before, and at that time, it was an endian problem. In OpenSSH 2.9, the aes/rijndael code needed an extra #define for little vs big endian, WORDS_BIGENDIAN. Obviously this needs to be set on a big endian system and not set on little endian. Default is to NOT set it (i.e. default is for little endian systems). The configure script normally figures this out, but it might have failed on your target system. Try setting this or unsetting it, then rebuilding rijndael.o. No guarantee this is correct (:-) but I hope this helps, Pete Flugstad Icon Labs From djm at mindrot.org Tue Aug 26 14:04:11 2003 From: djm at mindrot.org (Damien Miller) Date: Tue, 26 Aug 2003 14:04:11 +1000 Subject: Locked account checks and PAM In-Reply-To: <3F4AAED6.F442EC42@zip.com.au> References: <3F4AAED6.F442EC42@zip.com.au> Message-ID: <3F4ADC3B.3050503@mindrot.org> Darren Tucker wrote: > Hi All. > I (actually the tinderbox[1]) found a problem with the fix for bug #422: > when PAM is enabled on a platform that uses /etc/shadow, the variable > "passwd" in auth.c is used uninitialized. > > There's a simple patch attached to fix this. > > The question is: should the locked account test be done when PAM is > enabled or should we rely on PAM to do the right thing? In theory they > should behave the same way, but ISTR that in some patchlevels of Solaris > PAM did not check for this. If PAM is enabled, it is PAM's responsability. -d From pete.flugstad at icon-labs.com Tue Aug 26 13:59:44 2003 From: pete.flugstad at icon-labs.com (Pete Flugstad) Date: Mon, 25 Aug 2003 22:59:44 -0500 Subject: Bad packet length error In-Reply-To: <04f101c36b82$baff4d40$66fe10ac@axiowave.com> References: <04f101c36b82$baff4d40$66fe10ac@axiowave.com> Message-ID: <3F4ADB30.9040002@icon-labs.com> Hari wrote: > I just tried with WORDS_BIGENDIAN defined and it helped solve this issue. > Apparently this is what happened: > I am using a cross-compiler for building openssh and I could not run > configure on the cross-compiler environment. > I have initially run the > configure on an x86 box and used the thus created config.h and Makefile for > building in the cross-compiler env. At some point when I moved to power-pc, > I failed to modify/obtain new config.h and Makefile. Yup, same thing happened to me. The only thing I found that mattered was the WORDS_BIGENDIAN issue. I had more issues with OpenSSL for PPC as I'd left some RC4 defines turned on (they were in X86 code) I should not have (PPC860 doesn't like RC4_INDEX). > How do we handle this for different platforms when using a cross-compiler ? > Right now, I am doing an #ifdef __ in config.h The proper solution is to use the newer code - it appears to be endian independant. That eliminates this issue entirely. So I would expect that with 3.6 you can run the configure script on the X86 host and the generated config.h, etc will probably be OK for the PPC system (since the endian issues will have been taken care of), assuming similar/same OS. You may need to edit config.h for LynxOS to more accurately reflect what features it has defined vs what Linux has defined, but I'd guess it'd be pretty close. Pete Flugstad Icon Labs PS: Note that the 3.6.1p2 configure script still seems to setup WORDS_BIGENDIAN, even though nothing appears to use that #define or any other endian releated define that I can find. From stevev at darkwing.uoregon.edu Tue Aug 26 15:07:25 2003 From: stevev at darkwing.uoregon.edu (Steve VanDevender) Date: Mon, 25 Aug 2003 22:07:25 -0700 Subject: Bad packet length error In-Reply-To: <3F4AC712.172912F7@zip.com.au> References: <04ef01c36b70$f1625b50$66fe10ac@axiowave.com> <3F4AC712.172912F7@zip.com.au> Message-ID: <16202.60173.977002.332447@darkwing.uoregon.edu> Darren Tucker writes: > "Hari (E-mail)" wrote: > > I am running sshd (openssh-2.9p2) on a power-pc LynxOS box, and am > > connecting from a ssh client (openssh-2.9p2) on an x86 Linux box. > > This works fine for ssh protocol version 1, but am getting the below error > > for ssh v2: > > > > Disconnecting: Bad packet length -857542839. > > There has been a history of "bad packet length" errors that were fixed by > upgrading the version of zlib used. What version are you using, and does > the problem go away if you recompile openssh with zlib 1.4? Version number confusion seems to be the order of the day. The most recent version of zlib is 1.1.4, which also fixes some security issues in 1.1.3. From carson at taltos.org Wed Aug 27 02:45:14 2003 From: carson at taltos.org (Carson Gaspar) Date: Tue, 26 Aug 2003 12:45:14 -0400 Subject: No interest in partial auth? In-Reply-To: <20030825195525.GB28131@folly> References: <3F4A366B.7080805@acs.rutgers.edu> <20030825195525.GB28131@folly> Message-ID: <205090000.1061916314@taltos.ny.ficc.gs.com> --On Monday, August 25, 2003 21:55:25 +0200 Markus Friedl wrote: [ Re: partial auth ] > > this feature but be useful, but the implementation has to be simple. Please elaborate. I was told that auth vectors (ordered lists of authentication methods, all of which must succeed) were too complex a concept, not that the code was too complex. If that opinion has changed, I'll re-implement auth vectors against the current code base. -- Carson From smichaud at pobox.com Wed Aug 27 09:33:16 2003 From: smichaud at pobox.com (Steven Michaud) Date: Tue, 26 Aug 2003 18:33:16 -0500 (CDT) Subject: gss userauth (fwd) In-Reply-To: References: Message-ID: On Sun, 24 Aug 2003, Steven Michaud wrote: > Finally, despite what Love says, the gssapi protocol as used by gss > userauth already does provide mutual authentication between the > client and the server. Alas, I need to take back this statement. See the ongoing discussion on the ietf-ssh mailing list (ietf-ssh at netbsd.org, archives at ftp://ftp.ietf.org/ietf-mail-archive/secsh/), particularly Sam Hartman's message of 3:22 EST, 8-26-2003. From dtucker at zip.com.au Wed Aug 27 12:41:28 2003 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 27 Aug 2003 12:41:28 +1000 Subject: SSH-2.0-OpenSSH_3.6.1p2 - Bug #442 References: <95C9664AA1B83E4EAB1C08A66415482E016CEBA3@usushssap015.udh.unistudios.com> Message-ID: <3F4C1A58.752F34E3@zip.com.au> "DiNisco, Jeff" wrote: > I read in the change log that you fixed a bug that denies access to > accounts with locked passwords. My environment is dependent on public > key authentication. The account used does not have a person associated > with it but rather a service. I want to keep the password locked. Is > there a way to turn this fix off? What platform are we talking about? Depending on that you can set the password entry to something that doesn't mean "locked" to your system (on Solaris, for example, the system accounts use "NP" or "*NP*" to denote "no password authentication"). This will still allow the public-key authentication but not passwords. I tried to cover this in the man page changes. Apart from that you could undo the patch. (cc'ed the list, others might have similar issues). -- 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 Nicolas.Williams at sun.com Thu Aug 28 02:23:51 2003 From: Nicolas.Williams at sun.com (Nicolas Williams) Date: Wed, 27 Aug 2003 09:23:51 -0700 Subject: No interest in partial auth? Message-ID: <20030827162351.GH1319@binky.central.sun.com> A simple way to implement partial userauth would be for the the server to disable the userauth that partially succeeded/failed and require that one of the remaining methods be used. (For pubkey one might want to record the key that was used rather than disable the method, so one could force the use of two pubkeys). This approach would require some way to flag the need for more userauth, which is easy to do on a per-key basis for pubkey, but hard to do on a per-user basis for the other userauth methods. Partial userauth can also be used to force keyboard-interactive userauth when a user's password is expired, say. This is easy to implement, but not necessarily reliable (e.g., how can you tell if a user's Kerberos password is expired while doing pubkey userauth? You can't - you have to actually try to get an initial ticket for the user in order to determine if the Kerberos password is expired, which means you have to know the user's password). These two uses of partial userauth are somewhat simple to implement. Cheers, Nico -- From mike808 at users.sourceforge.net Thu Aug 28 05:48:07 2003 From: mike808 at users.sourceforge.net (mike808) Date: Wed, 27 Aug 2003 14:48:07 -0500 (CDT) Subject: splitting big authorized_keys files Message-ID: <14078.12.22.157.254.1062013687.squirrel@mail3411.b0.com> What about this: 1. Break up your current file into mutliple files containing only keys based on the first two letters of the user name, as you suggested earlier. 2. Put them into a directory 3. Create symbolic (or hard) links for each username to their respective authorized_keys file. 4. Specifying the path to your authorized_keys "forest" in the server configuration value AuthorizedKeysFile and use the %u token as a suffix. The server uses the authorized_keys file selected by the user name. This file is actually a link to the (smaller) chunk of the old authorized_keys file. This effectively uses the filesystem as your "database", and the only "index" available is the username, unfortunately. Whether the filesystem finding the username "entry" in a directory of 1500 "files", and then performing the key lookup (albeit in a smaller file), is faster than SSH looking up the key in the larger authorized_keys file, only you can decide. It's not a "great" way to do this, but it could work. The authorized_keys files get more manageable, but then the directory you put them in gets more unmanagable with all of the user links in it. HTH, Mike/ From Darren.Moffat at Sun.COM Thu Aug 28 04:45:50 2003 From: Darren.Moffat at Sun.COM (Darren J Moffat) Date: Wed, 27 Aug 2003 11:45:50 -0700 (PDT) Subject: SSH-2.0-OpenSSH_3.6.1p2 - Bug #442 In-Reply-To: <3F4C1A58.752F34E3@zip.com.au> Message-ID: On Wed, 27 Aug 2003, Darren Tucker wrote: > What platform are we talking about? > > Depending on that you can set the password entry to something that doesn't > mean "locked" to your system (on Solaris, for example, the system accounts > use "NP" or "*NP*" to denote "no password authentication"). This will > still allow the public-key authentication but not passwords. NP yes. If you see *NP* it means that the NIS+ passwd.org_dir table permissions or the ACIs on the LDAP object were to restrictive for you to read the entry. Or that nscd choose to block it (NIS+ only). Or it means that someone manually put *NP* into the field will not understanding what it is really used for ;-) -- Darren J Moffat From glemtp at yahoo.com Thu Aug 28 04:53:02 2003 From: glemtp at yahoo.com (Greg Lambert) Date: Wed, 27 Aug 2003 11:53:02 -0700 (PDT) Subject: Private key too open but ssh-add still prompts for passphrase Message-ID: <20030827185302.9795.qmail@web12203.mail.yahoo.com> I am working on a port of openssh-3.5p1 and ran across a case where we were trying to load a private key with 0644 permissions into the agent. The agent responds with: @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: UNPROTECTED PRIVATE KEY FILE! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ Permissions 0644 for '/home/greg/.ssh/id_dsa' are too open. It is recommended that your private key files are NOT accessible by others. This private key will be ignored. bad permissions: ignore key: /home/greg/.ssh/id_dsa Enter passphrase for /home/greg/.ssh/id_dsa: Which is fine except why is it prompting for the passphrase if the key is being ignored? And if I put in the correct passphrase for that key it prints the warning again then says "Bad passphrase, try again" It keeps prompting repeatedly until no passphrase is entered or I ctrl-C out. I looked in the archives and in bugzilla but I can't seem to find this problem. Can someone shed some light on this. Is this a known bug? Greg Lambert --------------------------------- Do you Yahoo!? Yahoo! SiteBuilder - Free, easy-to-use web site design software From markus at openbsd.org Thu Aug 28 05:10:44 2003 From: markus at openbsd.org (Markus Friedl) Date: Wed, 27 Aug 2003 21:10:44 +0200 Subject: splitting big authorized_keys files In-Reply-To: <14078.12.22.157.254.1062013687.squirrel@mail3411.b0.com> References: <14078.12.22.157.254.1062013687.squirrel@mail3411.b0.com> Message-ID: <20030827191044.GA16112@folly> sorry, but the authorized_keys file handling won't be changed in the near future. From mike808 at users.sourceforge.net Thu Aug 28 08:46:22 2003 From: mike808 at users.sourceforge.net (mike808) Date: Wed, 27 Aug 2003 17:46:22 -0500 (CDT) Subject: splitting big authorized_keys files In-Reply-To: <20030827191044.GA16112@folly> References: <20030827191044.GA16112@folly> Message-ID: <54775.12.22.157.254.1062024382.squirrel@mail3411.b0.com> > sorry, but the authorized_keys file handling won't be changed in > the near future. I'm confused. The proposal I suggested did not require any changes in the authorized_keys file handling. It's actually just an unusual configuration trick. Whether it is faster than the single-large-file approach, I cannot say. >From the manpage: AuthorizedKeysFile Specifies the file that contains the public keys that can be used for user authentication. AuthorizedKeys- File may contain tokens of the form %T which are sub- stituted during connection set-up. The following tokens are defined: %% is replaced by a literal '%', %h is replaced by the home directory of the user being authenticated and %u is replaced by the username of that user. After expansion, AuthorizedKeysFile is taken to be an absolute path or one relative to the user's home directory. The default is ``.ssh/authorized_keys''. I take that to mean that something like the following is possible: In the sshd_config, we have something like: AuthorizedKeysFile /usr/local/etc/authorized_keys/%u And in that /usr/local/etc/authorized_keys directory, we have something like the following, where we've split up the monolithic authorized_keys file, grouping the keys by username into each file: -rw-r--r-- ... Authkeys_A_to_E -rw-r--r-- ... Authkeys_F_to_J -rw-r--r-- ... Authkeys_K_to_O -rw-r--r-- ... Authkeys_P_to_T -rw-r--r-- ... Authkeys_U_to_Z Then, in the same directory, we create symbolic links for each user to the respective authorized_keys file. lrwxrwxrwx ... adam -> Authkeys_A_to_E lrwxrwxrwx ... jane -> Authkeys_F_to_J lrwxrwxrwx ... mike -> Authkeys_K_to_O lrwxrwxrwx ... sarah -> Authkeys_P_to_T lrwxrwxrwx ... thomas -> Authkeys_P_to_T lrwxrwxrwx ... wendy -> Authkeys_U_to_Z If the code doesn't follow symbolic links, then just use hard links. Thus, when user 'mike' connects, the server applies the '%u' expansion to the AuthorizedKeysFile value and will look in the file '/usr/local/etc/authorized_keys/mike', and, following the symbolic link, actually opens 'Authkeys_K_to_O', which would contain the key for the user 'mike'. And fewer keys to search through than the monolithic authorized_keys file. As I said, I don't know if directory searches will be any faster than key searches. YMMV. That said, it does solve the OP's problem of breaking up a monolithic authorized keys file. Then again, you could just use separate authorized_keys files for each user and the username is the index key and the filesystem is the "database". Either way, I don't see how that would require any changes to OpenSSH. Or am I missing something here? Mike/ From stuge-openssh-unix-dev at cdy.org Thu Aug 28 09:31:49 2003 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 28 Aug 2003 01:31:49 +0200 Subject: splitting big authorized_keys files In-Reply-To: <54775.12.22.157.254.1062024382.squirrel@mail3411.b0.com> References: <20030827191044.GA16112@folly> <54775.12.22.157.254.1062024382.squirrel@mail3411.b0.com> Message-ID: <20030827233149.GA29181@foo.birdnet.se> On Wed, Aug 27, 2003 at 05:46:22PM -0500, mike808 wrote: > > sorry, but the authorized_keys file handling won't be changed in > > the near future. [..snip..] > Either way, I don't see how that would require any changes to OpenSSH. > Or am I missing something here? I believe the original poster had a setup with thousands of remote clients logging in as the same (single) system user. A horrible hack I just thought of is to add all 15000 users to /etc/passwd with the same uid, dunno if it will actually work, and it's off-topic for this list, anyway. //Peter From markus at openbsd.org Thu Aug 28 16:10:26 2003 From: markus at openbsd.org (Markus Friedl) Date: Thu, 28 Aug 2003 08:10:26 +0200 Subject: splitting big authorized_keys files In-Reply-To: <54775.12.22.157.254.1062024382.squirrel@mail3411.b0.com> References: <20030827191044.GA16112@folly> <54775.12.22.157.254.1062024382.squirrel@mail3411.b0.com> Message-ID: <20030828061026.GA9130@folly> On Wed, Aug 27, 2003 at 05:46:22PM -0500, mike808 wrote: > lrwxrwxrwx ... sarah -> Authkeys_P_to_T > lrwxrwxrwx ... thomas -> Authkeys_P_to_T you want to have sarah login as thomas? From mike808 at users.sourceforge.net Fri Aug 29 03:51:03 2003 From: mike808 at users.sourceforge.net (mike808) Date: Thu, 28 Aug 2003 12:51:03 -0500 (CDT) Subject: splitting big authorized_keys files In-Reply-To: <20030828061026.GA9130@folly> References: <20030828061026.GA9130@folly> Message-ID: <25623.12.22.157.254.1062093063.squirrel@mail3411.b0.com> > On Wed, Aug 27, 2003 at 05:46:22PM -0500, mike808 wrote: >> lrwxrwxrwx ... sarah -> Authkeys_P_to_T >> lrwxrwxrwx ... thomas -> Authkeys_P_to_T > > you want to have sarah login as thomas? No. That won't happen. Authkeys_P_to_T (in the example) will contain _all_ of the authorized keys for all user names beginning with the letter "P" through the letter "T". That means that both Sarah's key and Thomas' key will both be found in this file. The idea is that it will be faster (supposedly, and unproven) to find the supplied key in a smaller file (with fewer keys) than in a larger file (with more keys). Think of it as a hash function with only five buckets, in this example. The trickery with the symlinks is what "implements" the hash function on the user's name to determine which bag of authkeys to look in. This technique is about as old as dirt, and is used in other areas, like client-based automatic proxy server load-balancing. That works by taking a hash of the URL that is then used to pick which proxy server to use. Presto, all clients asking for a specific URL are always routed to the same proxy server, which makes each proxy server's cache very, very efficient. The function of "picking" the proxy server to use is where you can add in arbitrary logic and weightings. In the SSH case, the function of "picking" which authorized_keys file to use is limited to a single file, a per-host file, or a per-user file. In the OP's request, a per-host file is the same case as the single file, so the per-user file choice is the only real option (without changing SSH to add new "picking" functions (i.e. new tokens in AuthorizedKeysFile). The symlinks just provide the "load-balancing" or "hash" function and instead of operating on a URL, operate on the user name. I hope that explains how my suggestion works. Mike/ From markus at openbsd.org Fri Aug 29 05:02:31 2003 From: markus at openbsd.org (Markus Friedl) Date: Thu, 28 Aug 2003 21:02:31 +0200 Subject: splitting big authorized_keys files In-Reply-To: <25623.12.22.157.254.1062093063.squirrel@mail3411.b0.com> References: <20030828061026.GA9130@folly> <25623.12.22.157.254.1062093063.squirrel@mail3411.b0.com> Message-ID: <20030828190231.GB22472@folly> On Thu, Aug 28, 2003 at 12:51:03PM -0500, mike808 wrote: > > On Wed, Aug 27, 2003 at 05:46:22PM -0500, mike808 wrote: > >> lrwxrwxrwx ... sarah -> Authkeys_P_to_T > >> lrwxrwxrwx ... thomas -> Authkeys_P_to_T > > > > you want to have sarah login as thomas? > > No. That won't happen. but it will happen since thomas' public key is in sarah's file. From mouring at etoh.eviladmin.org Fri Aug 29 05:06:52 2003 From: mouring at etoh.eviladmin.org (Ben Lindstrom) Date: Thu, 28 Aug 2003 14:06:52 -0500 (CDT) Subject: splitting big authorized_keys files In-Reply-To: <25623.12.22.157.254.1062093063.squirrel@mail3411.b0.com> Message-ID: So in other words Yes.. markus is right.. If you are Sarah you could log in as Thomas. I still don't see what this buys you that the follow does not do better in your scheme: AuthorizedKeysFile /etc/keys/%u_keys Or in ~/.ssh/authorized_keys by default. My understand was the user himself has 15000+ keys. Which is an insane amount of public keys to be managing for one user.=) - Ben On Thu, 28 Aug 2003, mike808 wrote: > > On Wed, Aug 27, 2003 at 05:46:22PM -0500, mike808 wrote: > >> lrwxrwxrwx ... sarah -> Authkeys_P_to_T > >> lrwxrwxrwx ... thomas -> Authkeys_P_to_T > > > > you want to have sarah login as thomas? > > No. That won't happen. > > Authkeys_P_to_T (in the example) will contain _all_ of the authorized > keys for all user names beginning with the letter "P" through the > letter "T". > > That means that both Sarah's key and Thomas' key will both be > found in this file. The idea is that it will be faster (supposedly, > and unproven) to find the supplied key in a smaller file (with fewer keys) > than in a larger file (with more keys). > > Think of it as a hash function with only five buckets, in this example. > The trickery with the symlinks is what "implements" the hash function > on the user's name to determine which bag of authkeys to look in. > > This technique is about as old as dirt, and is used in other areas, > like client-based automatic proxy server load-balancing. That works > by taking a hash of the URL that is then used to pick which proxy server > to use. > > Presto, all clients asking for a specific URL are always routed to > the same proxy server, which makes each proxy server's cache very, very > efficient. The function of "picking" the proxy server to use is where > you can add in arbitrary logic and weightings. > > In the SSH case, the function of "picking" which authorized_keys file > to use is limited to a single file, a per-host file, or a per-user file. > In the OP's request, a per-host file is the same case as the single file, > so the per-user file choice is the only real option (without changing > SSH to add new "picking" functions (i.e. new tokens in AuthorizedKeysFile). > The symlinks just provide the "load-balancing" or "hash" function and > instead of operating on a URL, operate on the user name. > > I hope that explains how my suggestion works. > > Mike/ > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From mike808 at users.sourceforge.net Fri Aug 29 09:37:07 2003 From: mike808 at users.sourceforge.net (mike808) Date: Thu, 28 Aug 2003 18:37:07 -0500 (CDT) Subject: splitting big authorized_keys files In-Reply-To: References: Message-ID: <36725.12.22.157.254.1062113827.squirrel@mail3411.b0.com> > So in other words Yes.. markus is right.. If you are Sarah you could > log in as Thomas. I see now. Yes. Sarah could issue an 'ssh thomas at server' and be in like Flynn. Actually like Thomas. :=) But I thought he had a monster keys file he wanted to break up, no? > My understand was the user himself has 15000+ keys. Which is an insane > amount of public keys to be managing for one user.=) Hmm. Now I see (even better). In that case, figuring out a way to manage the authorized_keys file really *is* the wrong answer. Surely he should be learning instead, quite a bit more about forwarding and ssh-agent, no? If he really, really does have the problem of 15000+ systems that cannot possibly trust each other and require their own unique keys, then he's got even bigger problems trying to keep straight all of those passphrases. And if the passphrases are _not_ unique, then there is no requirement that the keys they protect be, no? He should work on consolidating keys, enable forwarding, and using agents. Sorry about the diversion on solving a different problem... :=) Mike/ From themel at iwoars.net Fri Aug 29 22:06:02 2003 From: themel at iwoars.net (Thomas Themel) Date: Fri, 29 Aug 2003 14:06:02 +0200 Subject: authorized_keys options for remote forwarding Message-ID: <20030829120602.GG11415@iwoars.net> Hi, I've recently run into a situation where it I want clients (or certain keys) to connect to an OpenSSH server and set up a remote port forwarding channel (-R) without allowing them to do anything else. It seems that current OpenSSH doesn't support this. I would like to suggest the following changes to the options for authorized_keys: * add a no-local-forwarding option that denies setup of -L channels * add a no-remote-forwarding option that denies setup of -R channels * make no-tcp-forwarding act like no-local-forwarding + no-remote-forwarding And, not required for me, but for completeness: * add a permitremote that defines ports that the connection may try to listen on All these changes are seemingly trivial, but I haven't had anything to do with the OpenSSH source code previously, so I'm probably not a good judge of these matters. Are there any principal arguments against implementing this changes? If not, what's the best way to proceed, code up a patch and submit it to this list? ciao, -- [*Thomas Themel*] Purely in the interests of science, I have [extended contact] replaced the word "wand" with "wang" in the first Harry [info provided in] Potter Book. Let's see the results... [*message header*] -> http://bash.org/?111338 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20030829/0f439491/attachment.bin From markus at openbsd.org Fri Aug 29 22:44:10 2003 From: markus at openbsd.org (Markus Friedl) Date: Fri, 29 Aug 2003 14:44:10 +0200 Subject: authorized_keys options for remote forwarding In-Reply-To: <20030829120602.GG11415@iwoars.net> References: <20030829120602.GG11415@iwoars.net> Message-ID: <20030829124410.GA21254@folly> On Fri, Aug 29, 2003 at 02:06:02PM +0200, Thomas Themel wrote: > Are there any principal arguments against implementing this changes? If > not, what's the best way to proceed, code up a patch and submit it to > this list? write a patch and use openssh's bugzilla :) From mjt at tls.msk.ru Sun Aug 31 00:26:51 2003 From: mjt at tls.msk.ru (Michael Tokarev) Date: Sat, 30 Aug 2003 18:26:51 +0400 Subject: splitting big authorized_keys files In-Reply-To: <20030825173735.GA26181@foo.birdnet.se> References: <200308191014.36449.philipp.marek@bmlv.gv.at> <20030819083019.GA16717@folly> <200308250847.58916.philipp.marek@bmlv.gv.at> <20030825173735.GA26181@foo.birdnet.se> Message-ID: <3F50B42B.2050407@tls.msk.ru> Peter Stuge wrote: [] > I believe someone suggested using cdb by Dan J. Berstein, my experiences > with that database, although somewhat shallow, tells me it's well-suited for > the job. > > Please do check license and portability status of whatever package you > decide to use, "You may distribute unmodified copies of the cdb package. > Packages that need to read cdb files should incorporate the necessary > portions of the cdb library rather than relying on an external cdb library." > and "cdb works only under UNIX." applies to cdb, e.g. I would guess that the > wording in the license will be a problem, should you want your changes > included in mainstream OpenBSD OpenSSH, and probably in -portable, too. For the free cdb packages, one may take a look at freecdb (repackage of older cdb code for Debian), or my tinycdb package (this is an independent implementation, written from scratch) - http://www.corpit.ru/mjt/tinycdb.html Reportedly, it does work under win32 (in cygwin environment). /mjt From InterScan_VirusWall_Notes at sp.gov.br Sun Aug 31 02:57:40 2003 From: InterScan_VirusWall_Notes at sp.gov.br (InterScan_VirusWall_Notes at sp.gov.br) Date: Sat, 30 Aug 2003 13:57:40 -0300 (E. South America Standard Time) Subject: InterScan NT Alert Message-ID: <0a42f2658161e83RAS2@ras2.sp.gov.br> Caro remetente, uma mensagem enviada por voce continha virus e o nosso sistema de antivirus limpou/removeu automaticamente. Por favor verifique o seu microcomputador. - Administracao Internet Palacio Date: Sat, 30 Aug 2003 13:57:40 -0300 (E. South America Standard Time) Method: Mail From: To: File: document_9446.pif Action: clean failed - deleted Virus: WORM_SOBIG.F From POSTMASTER at smtpd.sp.gov.br Sun Aug 31 03:00:09 2003 From: POSTMASTER at smtpd.sp.gov.br (POSTMASTER at smtpd.sp.gov.br) Date: Sat, 30 Aug 2003 14:00:09 -0300 Subject: Undeliverable message Message-ID: <0a5035958161e83RAS2@ras2.sp.gov.br> ------- Failure Reasons -------- User not listed in public Name & Address Book pedreira.dpm at policia-civ.sp.gov.br ------- Returned Message -------- Received: from dns1.sp.gov.br ([192.168.20.52]) by smtpd.sp.gov.br (Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) with SMTP id 03256D92.005D5418; Sat, 30 Aug 2003 13:59:23 -0300 Received: from TIAGO ([200.144.31.37]) by smtpin0.sp.gov.br (Lotus Domino Release 5.0.9a) with ESMTP id 2003083013550146:10466 ; Sat, 30 Aug 2003 13:55:01 -0300 From: To: Subject: Your details Date: Sat, 30 Aug 2003 13:56:57 --0300 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on GATEWAY_INTERNET2/EXECUTIVO/BR(Release 5.0.9a |January 7, 2002) at 30/08/2003 13:55:04, Serialize by Router on GATEWAY_INTERNET2/EXECUTIVO/BR(Release 5.0.9a |January 7, 2002) at 30/08/2003 13:55:04 Message-ID: Content-Type: multipart/mixed; boundary="_NextPart_000_0085CF77" --_NextPart_000_0085CF77 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Please see the attached file for details. --_NextPart_000_0085CF77 Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" ****** Message from InterScan E-Mail VirusWall NT ****** ** WARNING! Attached file document_9446.pif contains: WORM_SOBIG.F virus Attempted to clean the file but it is not cleanable. It has been deleted. ***************** End of message *************** --_NextPart_000_0085CF77-- From POSTMASTER at smtpd.sp.gov.br Sun Aug 31 03:54:41 2003 From: POSTMASTER at smtpd.sp.gov.br (POSTMASTER at smtpd.sp.gov.br) Date: Sat, 30 Aug 2003 14:54:41 -0300 Subject: Undeliverable message Message-ID: <0a9d53553171e83RAS2@ras2.sp.gov.br> ------- Failure Reasons -------- User not listed in public Name & Address Book spaulo.ddm09 at policia-civ.sp.gov.br ------- Returned Message -------- Received: from dns1.sp.gov.br ([192.168.20.52]) by smtpd.sp.gov.br (Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) with SMTP id 03256D92.00624D20; Sat, 30 Aug 2003 14:53:42 -0300 Received: from TIAGO ([200.144.31.37]) by smtpin0.sp.gov.br (Lotus Domino Release 5.0.9a) with ESMTP id 2003083014491649:12521 ; Sat, 30 Aug 2003 14:49:16 -0300 From: To: Subject: Re: Details Date: Sat, 30 Aug 2003 14:51:14 --0300 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on GATEWAY_INTERNET2/EXECUTIVO/BR(Release 5.0.9a |January 7, 2002) at 30/08/2003 14:49:21, Serialize by Router on GATEWAY_INTERNET2/EXECUTIVO/BR(Release 5.0.9a |January 7, 2002) at 30/08/2003 14:49:23 Message-ID: Content-Type: multipart/mixed; boundary="_NextPart_000_00B77AE6" --_NextPart_000_00B77AE6 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Please see the attached file for details. --_NextPart_000_00B77AE6 Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" ****** Message from InterScan E-Mail VirusWall NT ****** ** WARNING! Attached file application.pif contains: WORM_SOBIG.F virus Attempted to clean the file but it is not cleanable. It has been deleted. ***************** End of message *************** --_NextPart_000_00B77AE6-- From InterScan_VirusWall_Notes at sp.gov.br Sun Aug 31 04:02:20 2003 From: InterScan_VirusWall_Notes at sp.gov.br (InterScan_VirusWall_Notes at sp.gov.br) Date: Sat, 30 Aug 2003 15:02:20 -0300 (E. South America Standard Time) Subject: InterScan NT Alert Message-ID: <0ac430403181e83RAS2@ras2.sp.gov.br> Caro remetente, uma mensagem enviada por voce continha virus e o nosso sistema de antivirus limpou/removeu automaticamente. Por favor verifique o seu microcomputador. - Administracao Internet Palacio Date: Sat, 30 Aug 2003 15:02:20 -0300 (E. South America Standard Time) Method: Mail From: To: File: document_9446.pif Action: clean failed - deleted Virus: WORM_SOBIG.F From POSTMASTER at smtpd.sp.gov.br Sun Aug 31 04:04:38 2003 From: POSTMASTER at smtpd.sp.gov.br (POSTMASTER at smtpd.sp.gov.br) Date: Sat, 30 Aug 2003 15:04:38 -0300 Subject: Undeliverable message Message-ID: <0aa8e3203181e83RAS2@ras2.sp.gov.br> ------- Failure Reasons -------- User not listed in public Name & Address Book deic at policia-civ.sp.gov.br ------- Returned Message -------- Received: from dns1.sp.gov.br ([192.168.20.52]) by smtpd.sp.gov.br (Lotus SMTP MTA v4.6.6 (890.1 7-16-1999)) with SMTP id 03256D92.0063405A; Sat, 30 Aug 2003 15:04:05 -0300 Received: from TIAGO ([200.144.31.37]) by smtpin0.sp.gov.br (Lotus Domino Release 5.0.9a) with ESMTP id 2003083014594007:13080 ; Sat, 30 Aug 2003 14:59:40 -0300 From: To: Subject: Re: Thank you! Date: Sat, 30 Aug 2003 15:01:31 --0300 X-MailScanner: Found to be clean Importance: Normal X-Mailer: Microsoft Outlook Express 6.00.2600.0000 X-MSMail-Priority: Normal X-Priority: 3 (Normal) MIME-Version: 1.0 X-MIMETrack: Itemize by SMTP Server on GATEWAY_INTERNET2/EXECUTIVO/BR(Release 5.0.9a |January 7, 2002) at 30/08/2003 14:59:45, Serialize by Router on GATEWAY_INTERNET2/EXECUTIVO/BR(Release 5.0.9a |January 7, 2002) at 30/08/2003 14:59:45 Message-ID: Content-Type: multipart/mixed; boundary="_NextPart_000_00C0FEDD" --_NextPart_000_00C0FEDD Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="iso-8859-1" Please see the attached file for details. --_NextPart_000_00C0FEDD Content-Type: text/plain; name="InterScan_Disclaimer.txt" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="InterScan_Disclaimer.txt" ****** Message from InterScan E-Mail VirusWall NT ****** ** WARNING! Attached file document_9446.pif contains: WORM_SOBIG.F virus Attempted to clean the file but it is not cleanable. It has been deleted. ***************** End of message *************** --_NextPart_000_00C0FEDD-- From InterScan_VirusWall_Notes at sp.gov.br Sun Aug 31 03:51:58 2003 From: InterScan_VirusWall_Notes at sp.gov.br (InterScan_VirusWall_Notes at sp.gov.br) Date: Sat, 30 Aug 2003 14:51:58 -0300 (E. South America Standard Time) Subject: InterScan NT Alert Message-ID: <0a8934352171e83RAS2@ras2.sp.gov.br> Caro remetente, uma mensagem enviada por voce continha virus e o nosso sistema de antivirus limpou/removeu automaticamente. Por favor verifique o seu microcomputador. - Administracao Internet Palacio Date: Sat, 30 Aug 2003 14:51:58 -0300 (E. South America Standard Time) Method: Mail From: To: File: application.pif Action: clean failed - deleted Virus: WORM_SOBIG.F From AlphaLN1/GrupoOrsa at grupoorsa.com.br Sun Aug 31 06:03:13 2003 From: AlphaLN1/GrupoOrsa at grupoorsa.com.br (AlphaLN1/GrupoOrsa at grupoorsa.com.br) Date: Sat, 30 Aug 2003 17:03:13 -0300 Subject: Report to Sender Message-ID: Incident Information:- Database: d:/lotus/domino/data/mail2.box Originator: Recipients: Subject: Re: Wicked screensaver Date/Time: 08/30/2003 05:03:08 PM The file attachment movie0045.pif you sent to the recipients listed above was infected with the W32/Sobig.f at MM virus and was successfully cleaned. From erikvcl at silcom.com Sun Aug 31 15:04:21 2003 From: erikvcl at silcom.com (Erik Lotspeich) Date: Sat, 30 Aug 2003 22:04:21 -0700 (PDT) Subject: No interest in partial auth? In-Reply-To: <205090000.1061916314@taltos.ny.ficc.gs.com> Message-ID: Carson, If it would be helpful, I can pass along to you the version of your patch that I have implemented. I believe that your implementation is very clean, however, partial authentication complicates matters, and it would be good to get an opinion on what I have done. Let me know if you are interested. Erik. On Tue, 26 Aug 2003, Carson Gaspar wrote: > > > --On Monday, August 25, 2003 21:55:25 +0200 Markus Friedl > wrote: > > [ Re: partial auth ] > > > > this feature but be useful, but the implementation has to be simple. > > Please elaborate. I was told that auth vectors (ordered lists of > authentication methods, all of which must succeed) were too complex a > concept, not that the code was too complex. If that opinion has changed, > I'll re-implement auth vectors against the current code base. > >