From Rolf.Sponsel at kstr.lth.se Sat Jan 1 08:51:30 2005 From: Rolf.Sponsel at kstr.lth.se (Rolf Sponsel) Date: Fri, 31 Dec 2004 22:51:30 +0100 Subject: Suggestion for complementing ssh[d]_config man pages concerning syntax for comments Message-ID: <41D5C9E2.7080909@kstr.lth.se> Hello everybody on this list, First of all; I wish everyone entering a new year that the new year will be a better one and a very prosperous one. Whilest playing around with OpenSSH, in particular with the sshd_config file, I noticed that it seems to be possible to add a comment also at the end of lines with directives by prepending the comment with a hash (in common *nix fashion), in addition to the explicitly mentioned syntax for including comments in ssh(d)_config files as described in the man pages, e.g. like this: # sshd_config file for OpenSSH ... Protocol 2 # default is 2,1 (order not significant) ... Running sshd in test mode (i.e. '/.../sshd -t') doesn't seem to not complain either which makes me believe this is allowed, but not documented. IMHO, I believe this could be explicitly mentioned in the sshd_config man page (and in the ssh_config man page too) in order to avoid any doubts thereof. My comments refere to the documentation/man pages provided with OpenSSH 3.9(p1). Best Regards Rolf Sponsel BTW, I'm currently not subscribed to the mailing list thus, in case of any leaving comments in response to this my suggestion, please, if possible cc me. -- ---- ------ -------- Rolf Sponsel ___________________________________________e_n_d___o_f___m_e_s_s_a_g_e_ From yakiyama at lapis.plala.or.jp Mon Jan 3 05:25:11 2005 From: yakiyama at lapis.plala.or.jp (yakiyama) Date: Mon, 3 Jan 2005 03:25:11 +0900 Subject: (no subject) Message-ID: <000101c4f0f8$69bff540$dd01a8c0@thunder> From frederik at a5.repetae.net Tue Jan 4 22:06:52 2005 From: frederik at a5.repetae.net (Frederik Eaton) Date: Tue, 4 Jan 2005 03:06:52 -0800 Subject: trying to debug ssh-askpass problem Message-ID: <20050104110652.GA26488@a5.repetae.net> Hi all, I have a script which calls ssh-add at a certain point, and I'm getting the following error: ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory I don't see why it's doing this, since SSH_ASKPASS isn't set, and there should be a working terminal: SSH_ASKPASS If ssh needs a passphrase, it will read the passphrase from the current terminal if it was run from a terminal. If ssh does not have a terminal associated with it but DISPLAY and SSH_ASKPASS are set, it will execute the program specified by SSH_ASKPASS and open an X11 window to read the passphrase. This is particu- larly useful when calling ssh from a .Xsession or related script. (Note that on some machines it may be necessary to redirect the input from /dev/null to make this work.) How can I find out what is causing ssh-add to try to execute ssh-askpass? Thanks, Frederik From markus at openbsd.org Wed Jan 5 00:02:42 2005 From: markus at openbsd.org (Markus Friedl) Date: Tue, 4 Jan 2005 14:02:42 +0100 Subject: trying to debug ssh-askpass problem In-Reply-To: <20050104110652.GA26488@a5.repetae.net> References: <20050104110652.GA26488@a5.repetae.net> Message-ID: <20050104130242.GA11873@folly> SSH_ASKPASS just overrides the default, it does not enable this feature. On Tue, Jan 04, 2005 at 03:06:52AM -0800, Frederik Eaton wrote: > Hi all, > > I have a script which calls ssh-add at a certain point, and I'm > getting the following error: > > ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory > > I don't see why it's doing this, since SSH_ASKPASS isn't set, and > there should be a working terminal: > > SSH_ASKPASS > If ssh needs a passphrase, it will read the passphrase from the > current terminal if it was run from a terminal. If ssh does not > have a terminal associated with it but DISPLAY and SSH_ASKPASS > are set, it will execute the program specified by SSH_ASKPASS > and open an X11 window to read the passphrase. This is particu- > larly useful when calling ssh from a .Xsession or related > script. (Note that on some machines it may be necessary to > redirect the input from /dev/null to make this work.) > > How can I find out what is causing ssh-add to try to execute > ssh-askpass? > > Thanks, > > Frederik > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev From frederik at ofb.net Wed Jan 5 08:15:25 2005 From: frederik at ofb.net (Frederik Eaton) Date: Tue, 4 Jan 2005 13:15:25 -0800 Subject: trying to debug ssh-askpass problem In-Reply-To: <20050104130242.GA11873@folly> References: <20050104110652.GA26488@a5.repetae.net> <20050104130242.GA11873@folly> Message-ID: <20050104211525.GA26728@a5.repetae.net> Thanks, that's helpful. What is the default? Is it documented? Is what you just said documented? The man page seems to imply that SSH_ASKPASS enables that feature (there is no other mention of any 'askpass'), can it be changed to be clearer, e.g. to describe the default behavior without SSH_ASKPASS set? Thanks, Frederik On Tue, Jan 04, 2005 at 02:02:42PM +0100, Markus Friedl wrote: > SSH_ASKPASS just overrides the default, it does not > enable this feature. > > On Tue, Jan 04, 2005 at 03:06:52AM -0800, Frederik Eaton wrote: > > Hi all, > > > > I have a script which calls ssh-add at a certain point, and I'm > > getting the following error: > > > > ssh_askpass: exec(/usr/bin/ssh-askpass): No such file or directory > > > > I don't see why it's doing this, since SSH_ASKPASS isn't set, and > > there should be a working terminal: > > > > SSH_ASKPASS > > If ssh needs a passphrase, it will read the passphrase from the > > current terminal if it was run from a terminal. If ssh does not > > have a terminal associated with it but DISPLAY and SSH_ASKPASS > > are set, it will execute the program specified by SSH_ASKPASS > > and open an X11 window to read the passphrase. This is particu- > > larly useful when calling ssh from a .Xsession or related > > script. (Note that on some machines it may be necessary to > > redirect the input from /dev/null to make this work.) > > > > How can I find out what is causing ssh-add to try to execute > > ssh-askpass? > > > > Thanks, > > > > Frederik > > > > _______________________________________________ > > openssh-unix-dev mailing list > > openssh-unix-dev at mindrot.org > > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev > From senthilkumar_sen at hotpop.com Thu Jan 6 02:28:33 2005 From: senthilkumar_sen at hotpop.com (Senthil Kumar) Date: Wed, 5 Jan 2005 20:58:33 +0530 Subject: changing group for root Message-ID: <001a01c4f33b$3b7219d0$220110ac@sekco> Hello All, The changing of group for the root results in the following message with OpenSSH 3.9p1 "permanently_set_uid: was able to restore old [e]gid" The following change in uidswap.c fixes me the problem. /* Try restoration of GID if changed (test clearing of saved gid) */ - if (old_gid != pw->pw_gid && + if(getgid() != pw->pw_gid && (setgid(old_gid) != -1 || setegid(old_gid) != -1)) fatal("%s: was able to restore old [e]gid", __func__); Is there any problem with this approach? Thanks, Senthil Kumar. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.791 / Virus Database: 535 - Release Date: 11/8/2004 From dkg-openssh.com at fifthhorseman.net Thu Jan 6 06:39:00 2005 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 5 Jan 2005 14:39:00 -0500 Subject: Potential DoS against forwarded ssh-agent In-Reply-To: <16847.26916.280471.965643@pinhead.lair.fifthhorseman.net> References: <16847.26916.280471.965643@pinhead.lair.fifthhorseman.net> Message-ID: <16860.16980.608775.254684@pinhead.lair.fifthhorseman.net> Does anyone have any thoughts about this issue? What would it take to get this patch (or something like it) included in OpenSSH? Or am i barking up the wrong tree? Is this not really a potential DoS? Or does my proposed patch not resolve the problem? Thanks for any feedback you might have. Regards, --dkg On December 26, dkg-openssh.com at fifthhorseman.net said: > It appears there is an opportunity for a denial-of-service attack > against ssh-agent when using ForwardAgent. From djm at mindrot.org Thu Jan 6 09:28:21 2005 From: djm at mindrot.org (Damien Miller) Date: Thu, 06 Jan 2005 09:28:21 +1100 Subject: Potential DoS against forwarded ssh-agent In-Reply-To: <16860.16980.608775.254684@pinhead.lair.fifthhorseman.net> References: <16847.26916.280471.965643@pinhead.lair.fifthhorseman.net> <16860.16980.608775.254684@pinhead.lair.fifthhorseman.net> Message-ID: <41DC6A05.7060102@mindrot.org> Daniel Kahn Gillmor wrote: > Does anyone have any thoughts about this issue? What would it take to > get this patch (or something like it) included in OpenSSH? > > Or am i barking up the wrong tree? Is this not really a potential > DoS? Or does my proposed patch not resolve the problem? I don't really think that this is a problem - if an attacker has access to a ssh-agent socket, then clearing your keys or locking the agent are about the kindest things they can do for you. -d From djm at mindrot.org Thu Jan 6 09:29:02 2005 From: djm at mindrot.org (Damien Miller) Date: Thu, 06 Jan 2005 09:29:02 +1100 Subject: changing group for root In-Reply-To: <001a01c4f33b$3b7219d0$220110ac@sekco> References: <001a01c4f33b$3b7219d0$220110ac@sekco> Message-ID: <41DC6A2E.5020508@mindrot.org> Senthil Kumar wrote: > Hello All, > > The changing of group for the root results in the following message with > OpenSSH 3.9p1 > "permanently_set_uid: was able to restore old [e]gid" What platform is this? -d From dkg-openssh.com at fifthhorseman.net Thu Jan 6 15:10:08 2005 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Wed, 5 Jan 2005 23:10:08 -0500 Subject: Potential DoS against forwarded ssh-agent In-Reply-To: <41DC6A05.7060102@mindrot.org> References: <16847.26916.280471.965643@pinhead.lair.fifthhorseman.net> <16860.16980.608775.254684@pinhead.lair.fifthhorseman.net> <41DC6A05.7060102@mindrot.org> Message-ID: <16860.47648.8645.700258@pinhead.lair.fifthhorseman.net> Thanks for the followup, Damien! On January 6, djm at mindrot.org said: > I don't really think that this is a problem - if an attacker has access > to a ssh-agent socket, then clearing your keys or locking the agent are > about the kindest things they can do for you. I agree -- there are definitely worse things an attacker could do, like authenticating without your permission. But OpenSSH already has a defense against this kind of attack: use -c with ssh-add, and you will be protected by an ssh-askpass confirmation. The proposed patch attempts to add an analogous defense against a different (admittedly less severe) attack which is un-defendable in the current implementation. It seems like you ought to be able to be alerted about any form of remote tampering, even if the only thing it results in is a denial-of-service. Or am i overlooking some other form of attack in this analysis that swamps all other considerations? --dkg From senthilkumar_sen at hotpop.com Thu Jan 6 23:40:32 2005 From: senthilkumar_sen at hotpop.com (Senthil Kumar) Date: Thu, 6 Jan 2005 18:10:32 +0530 Subject: changing group for root References: <001a01c4f33b$3b7219d0$220110ac@sekco> <41DC6A2E.5020508@mindrot.org> Message-ID: <004f01c4f3ec$ec8c8500$220110ac@sekco> Damien wrote: >What platform is this? The problem occurs in hpux 11.11,11.23 but not in 11.00. To reproduce the problem login as root, change the group for root and try ssh. --Senthil Kumar. ----- Original Message ----- From: "Damien Miller" To: "Senthil Kumar" Cc: "OpenSSH Devel List" Sent: Thursday, January 06, 2005 3:59 AM Subject: Re: changing group for root > Senthil Kumar wrote: >> Hello All, >> >> The changing of group for the root results in the following message with >> OpenSSH 3.9p1 >> "permanently_set_uid: was able to restore old [e]gid" > > What platform is this? > > -d > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > http://www.mindrot.org/mailman/listinfo/openssh-unix-dev --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.791 / Virus Database: 535 - Release Date: 11/8/2004 From dtucker at zip.com.au Thu Jan 6 23:58:01 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 06 Jan 2005 23:58:01 +1100 Subject: changing group for root In-Reply-To: <004f01c4f3ec$ec8c8500$220110ac@sekco> References: <001a01c4f33b$3b7219d0$220110ac@sekco> <41DC6A2E.5020508@mindrot.org> <004f01c4f3ec$ec8c8500$220110ac@sekco> Message-ID: <41DD35D9.5020505@zip.com.au> Senthil Kumar wrote: > Damien wrote: >> What platform is this? > > The problem occurs in hpux 11.11,11.23 but not in 11.00. To reproduce > the problem login as root, change the group for root and try ssh. I think that's fixed in current. You can either try a snapshot or apply this patch to 3.9p1. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh-uidswap.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20050106/24836941/attachment.ksh From thomas at cs.wisc.edu Fri Jan 7 00:45:18 2005 From: thomas at cs.wisc.edu (David Thompson) Date: Thu, 06 Jan 2005 07:45:18 -0600 Subject: changing group for root In-Reply-To: Message from "Senthil Kumar" of "Thu, 06 Jan 2005 18:10:32 +0530." <004f01c4f3ec$ec8c8500$220110ac@sekco> Message-ID: <200501061345.j06DjInp007301@pongo.cs.wisc.edu> "Senthil Kumar" wrote: >Damien wrote: > >>What platform is this? > >The problem occurs in hpux 11.11,11.23 but not in 11.00. To reproduce the >problem login as root, change the group for root and try ssh. > Same problem on linux. If root's current gid doesn't match the group from /etc/passwd, ssh croaks (openssh-3.9p1/uidswap.c line 206). Dave Thompson UW-Madison From mtamizi at gmail.com Sat Jan 8 03:15:34 2005 From: mtamizi at gmail.com (Matin Tamizi) Date: Fri, 7 Jan 2005 11:15:34 -0500 Subject: Connection closed by remote host Message-ID: I'm having trouble with sshd accepting connections: $ ssh localhost Password: Read from remote host localhost: Connection reset by peer Connection to localhost closed. It used to work great, but when my copied my drive to another drive so I could swap to a larger drive, I started having problems. I copied the partitions one by one after booting with a LiveCD. It could be a permission problem, but I copied using `# cp -pRP`. I posted moreinformation on the problem at http://forums.gentoo.org/viewtopic.php?t=275380 I would appreciate any help. Many thanks, Matin From dtucker at zip.com.au Sat Jan 8 10:18:12 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 08 Jan 2005 10:18:12 +1100 Subject: Connection closed by remote host In-Reply-To: References: Message-ID: <41DF18B4.7010700@zip.com.au> Matin Tamizi wrote: > I'm having trouble with sshd accepting connections: > $ ssh localhost > Password: > Read from remote host localhost: Connection reset by peer > Connection to localhost closed. [...] > I posted moreinformation on the problem at > http://forums.gentoo.org/viewtopic.php?t=275380 The sshd log at that link has: [sshd] fatal: Failed to get default security context for matin. and I see that you have selinux enabled. Vanilla Portable OpenSSH doesn't generate that message, so your sshd has been modified. I would guess it's a problem with your selinux setup, but beyond that I can't help you. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From felix.schulte at gmail.com Sun Jan 9 04:28:20 2005 From: felix.schulte at gmail.com (Felix Schulte) Date: Sat, 8 Jan 2005 18:28:20 +0100 Subject: Automatic forwarding of Xprint server displays? In-Reply-To: <74f15d5f04121918264ff7e5d1@mail.gmail.com> References: <74f15d5f04121918264ff7e5d1@mail.gmail.com> Message-ID: <74f15d5f05010809285c3ca721@mail.gmail.com> On Mon, 20 Dec 2004 03:26:23 +0100, Felix Schulte wrote: > Is it possible to enable automatic forwarding of Xprint server > displays? The -X/-Y switches just forward the video Xserver display > but it seems there is no way to get the Xprint server displays > forwarded, too. Can anyone help, pls? -- _ Felix Schulte _|_|_ mailto:felix.schulte at gmail.com (0 0) ooO--(_)--Ooo From dtucker at zip.com.au Tue Jan 11 17:36:13 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 11 Jan 2005 17:36:13 +1100 Subject: OpenSSH 3.9p1 X11 forwarding In-Reply-To: References: Message-ID: <41E373DD.6050705@zip.com.au> kochera at postfinance.ch wrote: > We upgraded from 3.7.1p2 to 3.9p1. The behaviour of the X11 forwarding > changed significantly, it is much slower. See below the truss output > (server side which runs 3.7.1p2) an check for the timestamp (6 seconds > delay). Do you have any idea what may causes this behaviour? Platform is > Solaris 5.9 Generic_117171-05. One thing that changed was the use of untrusted xauth cookies. You can use the previous behaviour by putting "ForwardX11Trusted yes" in ssh_config. The other possibility I can think of is some kind of name resolution or IPv6 wackiness: you can try "UseDNS no" and "AddressFamily inet" in sshd_config and/or start sshd with the "-4" option to test those. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From senthilkumar_sen at hotpop.com Tue Jan 11 17:52:51 2005 From: senthilkumar_sen at hotpop.com (Senthil Kumar) Date: Tue, 11 Jan 2005 12:22:51 +0530 Subject: changing group for root References: <001a01c4f33b$3b7219d0$220110ac@sekco> <41DC6A2E.5020508@mindrot.org><004f01c4f3ec$ec8c8500$220110ac@sekco> <41DD35D9.5020505@zip.com.au> Message-ID: <04e401c4f7aa$2e2c4250$220110ac@sekco> Darren wrote, >I think that's fixed in current. You can either try a snapshot or apply >this patch to 3.9p1. Yes, it fixed me the problem. But why should we do the fix at this condition in uidswap.c? If the real id of the user is 0, why cant we skip this function `permanently_set_uid ` in ssh.c of OpenSSH 3.9p1? Thanks, Senthil Kumar --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.791 / Virus Database: 535 - Release Date: 11/12/2004 From dtucker at zip.com.au Tue Jan 11 18:05:17 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 11 Jan 2005 18:05:17 +1100 Subject: changing group for root In-Reply-To: <04e401c4f7aa$2e2c4250$220110ac@sekco> References: <001a01c4f33b$3b7219d0$220110ac@sekco> <41DC6A2E.5020508@mindrot.org><004f01c4f3ec$ec8c8500$220110ac@sekco> <41DD35D9.5020505@zip.com.au> <04e401c4f7aa$2e2c4250$220110ac@sekco> Message-ID: <41E37AAD.6070305@zip.com.au> Senthil Kumar wrote: > Darren wrote, > >> I think that's fixed in current. You can either try a snapshot or >> apply this patch to 3.9p1. > > Yes, it fixed me the problem. But why should we do the fix at this > condition in uidswap.c? If the real id of the user is 0, why cant we > skip this function `permanently_set_uid ` in ssh.c of OpenSSH 3.9p1? In some configurations, ssh can be made setuid, so the permanently_set_uid can't be removed. As for why fix it in uidwap.c and not elsewhere: the code in uidswap.c is called from multiple places. I'd rather see *all* of those places call permanently_set_uid(pw) and have it Just Work (with as much sanity checking as possible) rather than have the calls conditionalized all over the place for different reasons. -- 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 peter at pg-consultants.com Tue Jan 11 17:58:13 2005 From: peter at pg-consultants.com (Peter Gordon) Date: Tue, 11 Jan 2005 08:58:13 +0200 Subject: xterm crashes consistently Message-ID: <1105426693.4340.11.camel@win-antigen.commtouch.com> I am running Fedora 3 on a Dell 600. The version of OpenSSH is OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003 I am connect to a Sparc Solaris 9 uname -a SunOS mycomp 5.9 Generic_117171-07 sun4u sparc SUNW,Ultra-250 I use ssh to get from Fedora to the Sparc ssh -X root at mycomp mycomp password: And I am logged in. For this example I run xterm, but it also fails with xemacs Run xterm The terminal comes up and I can work with it - without the mouse. If I left click the mouse and highlight any text in the xterm, I get a fatal error and the xterm closes. The error is consistent and happens every time. xterm xterm: warning, error event received: X Error of failed request: BadAtom (invalid Atom parameter) Major opcode of failed request: 18 (X_ChangeProperty) Atom id in failed request: 0x185 Serial number of failed request: 218 Current serial number in output stream: 220 When I log in using telnet and doing the xhost thing, the window does not crash. I am not sure if the bug is an ssh bug or an X bug, but I hope you can help. Thanks Peter -- Peter Gordon Phone: +972 544 438029 Email: peter at pg-consultants.com Web: www.pg-consultants.com From dtucker at zip.com.au Tue Jan 11 22:39:05 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 11 Jan 2005 22:39:05 +1100 Subject: xterm crashes consistently In-Reply-To: <1105426693.4340.11.camel@win-antigen.commtouch.com> References: <1105426693.4340.11.camel@win-antigen.commtouch.com> Message-ID: <41E3BAD9.8060102@zip.com.au> Peter Gordon wrote: > I am running Fedora 3 on a Dell 600. The version of OpenSSH is > OpenSSH_3.9p1, OpenSSL 0.9.7a Feb 19 2003 [...] > The terminal comes up and I can work with it - without the mouse. > If I left click the mouse and highlight any text in the xterm, I get a > fatal error and the xterm closes. The error is consistent and happens > every time. > > xterm > xterm: warning, error event received: > X Error of failed request: BadAtom (invalid Atom parameter) > Major opcode of failed request: 18 (X_ChangeProperty) > Atom id in failed request: 0x185 > Serial number of failed request: 218 > Current serial number in output stream: 220 http://www.openssh.com/faq.html#3.13 3.13 - I upgraded to OpenSSH 3.8 and some X11 programs stopped working. As documented in the 3.8 release notes, ssh will now use untrusted X11 cookies by default. The previous behaviour can be restored by setting ForwardX11Trusted yes in ssh_config. Possible symptoms include: BadWindow (invalid Window parameter) BadAccess (attempt to access private resource denied) X Error of failed request: BadAtom (invalid Atom parameter) Major opcode of failed request: 20 (X_GetProperty) -- 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 scott at telesoft.com Wed Jan 12 11:36:42 2005 From: scott at telesoft.com (Scott Dudley) Date: Tue, 11 Jan 2005 17:36:42 -0700 Subject: Compiling openssh-3.9p1 Without Kerberos Message-ID: <41E4711A.8020402@telesoft.com> I'm trying to compile openssh-3.9p1 for an embedded Linux distro without kerberos support. I pass the flag --without-kerberos5 to configure and the script output indicates that I've chosen to not link against the kerberos libs: OpenSSH has been configured with the following options: User binaries: /usr/local/bin System binaries: /usr/local/sbin Configuration files: /usr/local/etc Askpass program: /usr/local/libexec/ssh-askpass Manual pages: /usr/local/man/manX PID file: /var/run Privilege separation chroot path: /var/empty sshd default user PATH: /usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin Manpage format: doc PAM support: no KerberosV support: no Smartcard support: no S/KEY support: no TCP Wrappers support: yes MD5 password support: no IP address in $DISPLAY hack: no Translate v4 in v6 hack: yes BSD Auth support: no Random number source: OpenSSL internal ONLY Host: i686-pc-linux-gnu Compiler: gcc Compiler flags: -g -O2 -Wall -Wpointer-arith -Wno-uninitialized Preprocessor flags: Linker flags: Libraries: -lwrap -lcrypto -lutil -lz -lnsl -lcrypt However, when built, it is linked against the kerberos libs: scottspc: /usr/local/src/openssh-3.9p1 # ldd ./sftp-server libcrypto.so.4 => /lib/libcrypto.so.4 (0x4002e000) libutil.so.1 => /lib/libutil.so.1 (0x4011f000) libz.so.1 => /usr/lib/libz.so.1 (0x40122000) libnsl.so.1 => /lib/libnsl.so.1 (0x40130000) libcrypt.so.1 => /lib/libcrypt.so.1 (0x40145000) libc.so.6 => /lib/i686/libc.so.6 (0x40172000) libgssapi_krb5.so.2 => /usr/kerberos/lib/libgssapi_krb5.so.2 (0x402ac000) libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0x402bf000) libcom_err.so.3 => /usr/kerberos/lib/libcom_err.so.3 (0x4031d000) libk5crypto.so.3 => /usr/kerberos/lib/libk5crypto.so.3 (0x4031f000) libresolv.so.2 => /lib/libresolv.so.2 (0x4032f000) libdl.so.2 => /lib/libdl.so.2 (0x40341000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x40000000) How do I disable kerberos support? Thanks. -- Regards, Scott Dudley From dtucker at zip.com.au Wed Jan 12 11:58:54 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 12 Jan 2005 11:58:54 +1100 Subject: Compiling openssh-3.9p1 Without Kerberos In-Reply-To: <41E4711A.8020402@telesoft.com> References: <41E4711A.8020402@telesoft.com> Message-ID: <41E4764E.1020605@zip.com.au> Scott Dudley wrote: > I'm trying to compile openssh-3.9p1 for an embedded Linux distro without > kerberos support. I pass the flag --without-kerberos5 to configure and > the script output indicates that I've chosen to not link against the > kerberos libs: [...] > However, when built, it is linked against the kerberos libs: Your system libcrypto is probably linked against the kerberos libs. This is from a redhat9 box: $ ldd /usr/lib/libcrypto.so |grep libkrb libkrb5.so.3 => /usr/kerberos/lib/libkrb5.so.3 (0x40120000) > How do I disable kerberos support? Download the OpenSSL source, build it, put it somewhere other than the system libcrypto (the default /usr/local/ssl is fine) then point OpenSSH's configure at it by with "--with-ssl-dir=/path/to/ssl" -- 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 robb at y42.net Wed Jan 12 22:46:09 2005 From: robb at y42.net (Robert Watson) Date: Wed, 12 Jan 2005 12:46:09 +0100 Subject: sshd runs with -R flag? Message-ID: <20050112114609.GB27485@bingo.y42.org> Hi All, Sorry to interrupt, but I recently downloaded and installed a pre-compiled package of OpenSSH 3.9p1 for Solaris. After installation everything seems to work well, but I notice that all of the child sshd daemons are running with a flag '-R' i.e. sh-3.00# ps -ef | grep sshd root 475 1 0 13:45:23 ? 0:00 /usr/local/sbin/sshd -4 root 643 475 0 14:10:55 ? 0:00 /usr/local/sbin/sshd -4 -R robb 645 643 0 14:11:02 ? 0:06 /usr/local/sbin/sshd -4 -R root 1015 475 0 15:09:25 ? 0:00 /usr/local/sbin/sshd -4 -R Why is that? (the -4 option I added myself, in the startup file). The -R doesn't seem to be documented anywhere and the archives of this list didn't reveal anything obvious. Have I mis-configured something? I wonder if there is a problem with privilege seperation - I wasn't expecting to see so many processes running as root. There is this code in sshd.c - But I cannot guess at its purpose: "sshd.c" line 1195 of 2021: ... if (rexec_flag) { rexec_argv = xmalloc(sizeof(char *) * (rexec_argc + 2)); for (i = 0; i < rexec_argc; i++) { debug("rexec_argv[%d]='%s'", i, saved_argv[i]); rexec_argv[i] = saved_argv[i]; } rexec_argv[rexec_argc] = "-R"; rexec_argv[rexec_argc + 1] = NULL; } ... I'm running this on Solaris 9, to be exact: bash-3.00# uname -a SunOS chamonix 5.9 Generic_117171-15 sun4u sparc SUNW,Ultra-5_10 bash-3.00# /usr/local/sbin/sshd -V sshd: illegal option -- V OpenSSH_3.9p1, OpenSSL 0.9.7e 25 Oct 2004 -- Yours, Robb. +-----------------------------------------------+ | "Tell me about windows." | | "Well it's only temporary, you understand." | | | | Wendolene & Wallace. | | A Close Shave. ? 1995 Wallace & Gromit Ltd. | +-----------------------------------------------+ From dtucker at zip.com.au Thu Jan 13 00:25:38 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 13 Jan 2005 00:25:38 +1100 Subject: sshd runs with -R flag? In-Reply-To: <20050112114609.GB27485@bingo.y42.org> References: <20050112114609.GB27485@bingo.y42.org> Message-ID: <41E52552.3060006@zip.com.au> Robert Watson wrote: > After installation everything seems to work well, but I notice that all > of the child sshd daemons are running with a flag '-R' i.e. [...] > Why is that? (the -4 option I added myself, in the startup file). > > The -R doesn't seem to be documented anywhere and the archives of this > list didn't reveal anything obvious. Starting with 3.9x, sshd will re-exec itself for every connection. This means that any exec-time process randomization (eg library offsets, propolice canaries) will be different for each connection. (For a thorough overview of what OpenBSD does, see [1]. Most platforms don't have these, however this will hopefully change over time, for example if the propolice patches get integrated into gcc). sshd needs to do some things a little differently after it's re-execed itself. -R is an internal flag that causes those changes in behaviour. > Have I mis-configured something? I wonder if there is a problem with > privilege seperation - I wasn't expecting to see so many processes > running as root. No, it looks normal. When PrivilegeSeparation is enabled, you will have two sshds per connected user (with the exception of root logins), one running as root (the "monitor") and one running as the logged-in user (the "slave"). [1] http://www.openbsd.org/papers/auug04/ -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From senthilkumar_sen at hotpop.com Thu Jan 13 01:23:29 2005 From: senthilkumar_sen at hotpop.com (Senthil Kumar) Date: Wed, 12 Jan 2005 19:53:29 +0530 Subject: OpenSSH-39 not sending syslog msges to proper files Message-ID: <07a101c4f8b2$4c017e90$220110ac@sekco> Hello All, My testing of OpenSSH-39 compiled with tcp_wrappers in hpux 11.11 and hpux 11.23 points that sshd is NOT sending the syslog details properly to specified files. This happens when I set the syslogfacility as local7 and Log Level as INFO for sshd. However OpenSSH -38 works correctly for the same setting. I denied a host in /etc/hosts.deny and sshd should send a message "refused connect from" to the /var/adm/syslog/sshd1.log as per my setting whenever a new ssh connection happens from the denied host to this sshd server. But this is not happening in OpenSSH-39. My testing also points that the problem is produced with Log Level INFO if sshd re-executes itself for new connection. When sshd runs with re-exec feature disabled with the help of -r option, it sends the messages to specified files. My sample syslog.conf local7.info /var/adm/syslog/sshd1.log ....... Thanks for help, Senthil Kumar. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.791 / Virus Database: 535 - Release Date: 11/13/2004 From selvesteen at gmail.com Thu Jan 13 21:23:29 2005 From: selvesteen at gmail.com (Michael Selvesteen) Date: Thu, 13 Jan 2005 15:53:29 +0530 Subject: Need OpenSSH to logs users bad login attempts Message-ID: Hello All, We have a sensitive network where users authenticates through SSH. We support multiple authentications with respective to their groups . As a security concern we continue to monitor failed or bad login attempts of every user using lastb command, but SSH never logs the bad login attempts of the user like telnet does . We would like to have this feature on SSH for every supported authentication including key based authentication like public key and host based authentications. We have a patch that logs bad login attempt through password based authentication but we like to have for key based authentication also. Kindly shed some light on this issue. We are using OpenSSH 3.9 on HP-UX 11.11 and HP-UX 11.23 servers. Advance thanks for all your help. Michael From djm at mindrot.org Thu Jan 13 21:36:51 2005 From: djm at mindrot.org (Damien Miller) Date: Thu, 13 Jan 2005 21:36:51 +1100 Subject: Need OpenSSH to logs users bad login attempts In-Reply-To: References: Message-ID: <41E64F43.6030001@mindrot.org> Michael Selvesteen wrote: > Hello All, > > We have a sensitive network where users authenticates through SSH. We > support multiple authentications with respective to their groups . As > a security concern we continue to monitor failed or bad login attempts > of every user using lastb command, but SSH never logs the bad login > attempts of the user like telnet does . We would like to have this > feature on SSH for every supported authentication including key based > authentication like public key and host based authentications. "LogLevel verbose" in sshd_config should do what you want. -d From ms at artcom-gmbh.de Thu Jan 13 22:05:29 2005 From: ms at artcom-gmbh.de (Martin =?iso-8859-1?Q?Schr=F6der?=) Date: Thu, 13 Jan 2005 12:05:29 +0100 Subject: logging hostnames (was: Need OpenSSH to logs users bad login attempts) In-Reply-To: <41E64F43.6030001@mindrot.org> References: <41E64F43.6030001@mindrot.org> Message-ID: <20050113110529.GD30066@blau.artcom-gmbh.de> On 2005-01-13 21:36:51 +1100, Damien Miller wrote: > "LogLevel verbose" in sshd_config should do what you want. BTW: Is it possible to add a hostname to the logged ip-address (maybe even with automatic reverse-lookup) if UseDNS is set? Best regards Martin -- Martin Schr?der, ms at artcom-gmbh.de ArtCom GmbH, Lise-Meitner-Str 5, 28359 Bremen, Germany Voice +49 421 20419-44 / Fax +49 421 20419-10 http://www.artcom-gmbh.de From selvesteen at gmail.com Thu Jan 13 22:30:03 2005 From: selvesteen at gmail.com (Michael Selvesteen) Date: Thu, 13 Jan 2005 17:00:03 +0530 Subject: Need OpenSSH to logs users bad login attempts In-Reply-To: <41E64F43.6030001@mindrot.org> References: <41E64F43.6030001@mindrot.org> Message-ID: Thanks Damien for your comments, We use a program that depends /var/adm/btmp(s) to monitor bad logins. But SSH is not updating this file after a bad login attempt. We seriously require the functionality. As I mentioned before we have a patch that makes SSH to do this but it fails to log bad attempts of key based authentication. Our program is similar to lastb command in HP_UX which returns bad login attempts. But lastb too fails to list bad login attempts by the SSH users. Thanks for your help, -- Michael On Thu, 13 Jan 2005 21:36:51 +1100, Damien Miller wrote: > Michael Selvesteen wrote: > > Hello All, > > > > We have a sensitive network where users authenticates through SSH. We > > support multiple authentications with respective to their groups . As > > a security concern we continue to monitor failed or bad login attempts > > of every user using lastb command, but SSH never logs the bad login > > attempts of the user like telnet does . We would like to have this > > feature on SSH for every supported authentication including key based > > authentication like public key and host based authentications. > > "LogLevel verbose" in sshd_config should do what you want. > > -d > From dtucker at zip.com.au Thu Jan 13 23:23:04 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 13 Jan 2005 23:23:04 +1100 Subject: Need OpenSSH to logs users bad login attempts In-Reply-To: References: <41E64F43.6030001@mindrot.org> Message-ID: <41E66828.1020009@zip.com.au> Michael Selvesteen wrote: > Thanks Damien for your comments, > > We use a program that depends /var/adm/btmp(s) to monitor bad logins. > But SSH is not updating this file after a bad login attempt. Is the patch you're using available? > We > seriously require the functionality. As I mentioned before we have a > patch that makes SSH to do this but it fails to log bad attempts of > key based authentication. If your patch uses the CUSTOM_FAILED_LOGIN hook then it's just a matter of finding this piece in auth.c: #ifdef CUSTOM_FAILED_LOGIN if (authenticated == 0 && strcmp(method, "password") == 0) record_failed_login(authctxt->user, "ssh"); #endif and removing the "&& strcmp(method, "password") == 0 part. Hmm on second thought you may want to change it to be: #ifdef CUSTOM_FAILED_LOGIN if (authenticated == 0 && strcmp(method, "none") != 0) record_failed_login(authctxt->user, "ssh"); #endif -- 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 code at pizzashack.org Sat Jan 15 16:24:26 2005 From: code at pizzashack.org (Derek Martin) Date: Sat, 15 Jan 2005 00:24:26 -0500 Subject: rssh and scponly arbitrary command execution In-Reply-To: <20041202135143.GA7105@xc.net> References: <20041202135143.GA7105@xc.net> Message-ID: <20050115052426.GG8855@sophic.org> I just released rssh version 2.2.3 to fix the problem detailed below. I haven't had time to update my website yet, and my Internet acess is quite limited these days (hence the terse announcement), so I probably won't get to that for a while. However, rssh 2.2.3 is available from the sourceforge.net site: http://sourceforge.net/projects/rssh All users of rssh should update to the latest release. The rssh homepage is here: http://www.pizzashack.org/rssh Sorry for the slow response; I've had other priorities lately. DM On Thu, Dec 02, 2004 at 01:51:43PM +0000, Jason Wies wrote: > Vulnerable applications: > > rssh > All versions > All operating systems > scponly > All versions > All operating systems > > Not vulnerable: > > Discussion: > > rssh and scponly are restricted shells that are designed to allow execution > only of certain preset programs. Both are used to grant a user the ability > to transfer files to and from a remote host without granting full shell > access. Due to the fact that most of the preset programs offer options that > execute other programs, arbitrary command execution on the remote host is > possible. > > rssh allows any of five predefined programs to be executed on the remote > host depending on the configuration. Those that are known to be vulnerable > in combination with the techniques described in this posting are marked with > an asterisk. > - scp* > - sftp-server > - cvs > - rdist* > - rsync* > > scponly allows a number of predefined programs to be executed on the remote > host depending on compile-time options. Those that are known to be > vulnerable when used with scponly: > - scp > - rsync > - unison (*untested) > > The program execution options that these programs offer: > > rdist -P > rsync -e > scp -S > unison -rshcmd > unison -sshcmd > > These options allow the user to specify the location of the shell to use > when connecting to the remote host. No restriction is placed on what > programs may be specified by these options, and rssh and scponly do not > filter these options out. The end result is that although a user may be > restricted by rssh or scponly to running e.g. only /usr/bin/scp, they can > in fact execute any program using /usr/bin/scp -S . > > The problem is compounded when you recognize that the main use of rssh and > scponly is to allow file transfers, which in turn allows a malicious user to > transfer and execute entire custom scripts on the remote machine. > > rssh with sftp-server does not appear to be vulnerable. rssh with cvs is > also not vulnerable using these techniques. However, it is quite probable > that a malicious user could check out a carefully crafted CVS repository and > execute arbitrary commands using CVS's hooks interface. > > Examples: > > ssh restricteduser at remotehost 'rsync -e "touch /tmp/example --" localhost:/dev/null /tmp' > > scp command.sh restricteduser at remotehost:/tmp/command.sh > ssh restricteduser at remotehost 'scp -S /tmp/command.sh localhost:/dev/null /tmp' > > Solution: > > There are no workarounds for this problem. > > I have talked with the author of rssh, Derek Martin. He is currently > indisposed for an indefinite period of time due to changing countries and > having no permanent home at the present moment. Moreover he has other > priorities and has lost interest in maintaining the program. He has offered > to assist anyone who would like to take over maintainership of rssh, but he > does not intend to provide a fix for the current problem. Given this fact, > I would strongly recommend against using rssh at this time. > > The author of scponly, Joe Boyle, has prepared a new release, version 4.0, > that addresses the current problem. > > Distributor updates have been coordinated with this posting and should be > available soon. > > I think the long-term solution for those needing a highly secure restricted > shell is to allow granular configuration by administrators of which options > and arguments, if any, are allowed to be specified for which programs. In > the most restricted case entire command lines would be stored on the remote > host and the client would be allowed only to select from the list of > available command lines. I'm not aware of any software that offers these > capabilities today. > > References: > http://www.pizzashack.org/rssh/index.shtml > http://www.sublimation.org/scponly/ > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > rssh-discuss mailing list > rssh-discuss at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/rssh-discuss -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D -------------- 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/20050115/7b95688e/attachment.bin From code at pizzashack.org Sat Jan 15 16:24:26 2005 From: code at pizzashack.org (Derek Martin) Date: Sat, 15 Jan 2005 00:24:26 -0500 Subject: rssh and scponly arbitrary command execution In-Reply-To: <20041202135143.GA7105@xc.net> References: <20041202135143.GA7105@xc.net> Message-ID: <20050115052426.GG8855@sophic.org> I just released rssh version 2.2.3 to fix the problem detailed below. I haven't had time to update my website yet, and my Internet acess is quite limited these days (hence the terse announcement), so I probably won't get to that for a while. However, rssh 2.2.3 is available from the sourceforge.net site: http://sourceforge.net/projects/rssh All users of rssh should update to the latest release. The rssh homepage is here: http://www.pizzashack.org/rssh Sorry for the slow response; I've had other priorities lately. DM On Thu, Dec 02, 2004 at 01:51:43PM +0000, Jason Wies wrote: > Vulnerable applications: > > rssh > All versions > All operating systems > scponly > All versions > All operating systems > > Not vulnerable: > > Discussion: > > rssh and scponly are restricted shells that are designed to allow execution > only of certain preset programs. Both are used to grant a user the ability > to transfer files to and from a remote host without granting full shell > access. Due to the fact that most of the preset programs offer options that > execute other programs, arbitrary command execution on the remote host is > possible. > > rssh allows any of five predefined programs to be executed on the remote > host depending on the configuration. Those that are known to be vulnerable > in combination with the techniques described in this posting are marked with > an asterisk. > - scp* > - sftp-server > - cvs > - rdist* > - rsync* > > scponly allows a number of predefined programs to be executed on the remote > host depending on compile-time options. Those that are known to be > vulnerable when used with scponly: > - scp > - rsync > - unison (*untested) > > The program execution options that these programs offer: > > rdist -P > rsync -e > scp -S > unison -rshcmd > unison -sshcmd > > These options allow the user to specify the location of the shell to use > when connecting to the remote host. No restriction is placed on what > programs may be specified by these options, and rssh and scponly do not > filter these options out. The end result is that although a user may be > restricted by rssh or scponly to running e.g. only /usr/bin/scp, they can > in fact execute any program using /usr/bin/scp -S . > > The problem is compounded when you recognize that the main use of rssh and > scponly is to allow file transfers, which in turn allows a malicious user to > transfer and execute entire custom scripts on the remote machine. > > rssh with sftp-server does not appear to be vulnerable. rssh with cvs is > also not vulnerable using these techniques. However, it is quite probable > that a malicious user could check out a carefully crafted CVS repository and > execute arbitrary commands using CVS's hooks interface. > > Examples: > > ssh restricteduser at remotehost 'rsync -e "touch /tmp/example --" localhost:/dev/null /tmp' > > scp command.sh restricteduser at remotehost:/tmp/command.sh > ssh restricteduser at remotehost 'scp -S /tmp/command.sh localhost:/dev/null /tmp' > > Solution: > > There are no workarounds for this problem. > > I have talked with the author of rssh, Derek Martin. He is currently > indisposed for an indefinite period of time due to changing countries and > having no permanent home at the present moment. Moreover he has other > priorities and has lost interest in maintaining the program. He has offered > to assist anyone who would like to take over maintainership of rssh, but he > does not intend to provide a fix for the current problem. Given this fact, > I would strongly recommend against using rssh at this time. > > The author of scponly, Joe Boyle, has prepared a new release, version 4.0, > that addresses the current problem. > > Distributor updates have been coordinated with this posting and should be > available soon. > > I think the long-term solution for those needing a highly secure restricted > shell is to allow granular configuration by administrators of which options > and arguments, if any, are allowed to be specified for which programs. In > the most restricted case entire command lines would be stored on the remote > host and the client would be allowed only to select from the list of > available command lines. I'm not aware of any software that offers these > capabilities today. > > References: > http://www.pizzashack.org/rssh/index.shtml > http://www.sublimation.org/scponly/ > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > rssh-discuss mailing list > rssh-discuss at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/rssh-discuss -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D -------------- 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/20050115/7b95688e/attachment-0001.bin From skissane at gmail.com Mon Jan 17 11:13:46 2005 From: skissane at gmail.com (Simon Kissane) Date: Mon, 17 Jan 2005 11:13:46 +1100 Subject: Feature requests for scp and ssh Message-ID: <82fa6638050116161345844edf@mail.gmail.com> Hi Would it be possible to add an option to the scp command, so that if a destination file already exists, rather than overwriting it, scp just skips the destination file, prints a message to stderr and returns an error (non-zero) exit? That would help me immensely. Also, you might want to think about providing a way to execute a series of ssh, scp and sftp commands through one authentication session, so if using password authentication you don't need to keep on re-keying the password. Maybe have some kind of background daemon, which holds the session open once authenticated, and then the ssh/scp/sftp clients connect to it to perform operations. (I know key authentication would work here, but sometimes server admins aren't so keen on key authentication, and would prefer you physically entering your password.) Cheers Simon Kissane From dtucker at zip.com.au Mon Jan 17 11:43:08 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 17 Jan 2005 11:43:08 +1100 Subject: Feature requests for scp and ssh In-Reply-To: <82fa6638050116161345844edf@mail.gmail.com> References: <82fa6638050116161345844edf@mail.gmail.com> Message-ID: <41EB0A1C.6020801@zip.com.au> Simon Kissane wrote: > Would it be possible to add an option to the scp command, so that if a > destination file already exists, rather than overwriting it, scp just > skips the destination file, prints a message to stderr and returns an > error (non-zero) exit? That would help me immensely. That would require another option to be passed to the remote scp process to enable that behaviour, which would be a potential interop problem. This means it's not likely to ever happen (see http://www.openssh.com/faq.html#2.10). You can use sftp in batch mode to do it with something like: $ echo "ls /tmp/foo" | sftp -b - localhost || \ echo "put foo /tmp/foo" | sftp -b - localhost This isn't going to save you from partial transfers, however. You may be better off using rsync-over-ssh. > Also, you might want to think about providing a way to execute a > series of ssh, scp and sftp commands through one authentication > session, so if using password authentication you don't need to keep on > re-keying the password. That already exists. Check out the ControlPath and ControlMaster options in 3.9x. -- 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 skissane at gmail.com Mon Jan 17 12:18:17 2005 From: skissane at gmail.com (Simon Kissane) Date: Mon, 17 Jan 2005 12:18:17 +1100 Subject: Feature requests for scp and ssh In-Reply-To: <41EB0A1C.6020801@zip.com.au> References: <82fa6638050116161345844edf@mail.gmail.com> <41EB0A1C.6020801@zip.com.au> Message-ID: <82fa6638050116171825a3c50f@mail.gmail.com> Hi, Thanks Darren for your prompt reply. On Mon, 17 Jan 2005 11:43:08 +1100, Darren Tucker wrote: > Simon Kissane wrote: > > Would it be possible to add an option to the scp command, so that if a > > destination file already exists, rather than overwriting it, scp just > > skips the destination file, prints a message to stderr and returns an > > error (non-zero) exit? That would help me immensely. > > That would require another option to be passed to the remote scp process > to enable that behaviour, which would be a potential interop problem. > This means it's not likely to ever happen (see > http://www.openssh.com/faq.html#2.10). [snip] Another proposal I might make then: enhance sftp's command line interface so it supports some of scp's syntax. So, at present it supports: sftp user at host:file file => similar to scp user at host:file file [get remote file] So, it could be extended to support the syntax: 1) sftp file user at host:file [put remote file, like scp file user at host:file] 2) sftp user1 at host1:file1 user2 at host2:file2 [transfer between remote hosts] (The second syntax might require extensions to the SFTP protocol, and in any case is not so important as the first.) Then, a command line argument could be given with syntax (1) not to overwrite the remote file. This wouldn't require any protocol changes (it would simply do behind the scenes what you suggested to do manually). So that solves my problem, is simpler for the user than the current solution you propose (one command, v.s. two commands plus shell control structures), and is possible with no changes to the sftp protocol (for syntax 1 at least). Although, using the two commands and the control structure you proposed, ie.: $ echo "ls /tmp/foo" | sftp -b - localhost || \ echo "put foo /tmp/foo" | sftp -b - localhost does yield a race condition (another user could have created file after ls but before put). It would be better if there was an extension to the SFTP protocol to provide an option on put to not open the file if it exists, so the server would open the file O_EXCL. Cheers Simon Kissane From dtucker at zip.com.au Mon Jan 17 16:40:27 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 17 Jan 2005 16:40:27 +1100 Subject: OpenSSH-39 not sending syslog msges to proper files In-Reply-To: <07a101c4f8b2$4c017e90$220110ac@sekco> References: <07a101c4f8b2$4c017e90$220110ac@sekco> Message-ID: <41EB4FCB.9000508@zip.com.au> Senthil Kumar wrote: > My testing of OpenSSH-39 compiled with tcp_wrappers in hpux 11.11 and > hpux 11.23 points that sshd is NOT sending the syslog details properly to > specified files. This happens when I set the syslogfacility as local7 > and Log Level as INFO for sshd. However OpenSSH -38 works correctly for > the same setting. It's possibly this: http://bugzilla.mindrot.org/show_bug.cgi?id=973 -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From senthilkumar_sen at hotpop.com Mon Jan 17 23:04:16 2005 From: senthilkumar_sen at hotpop.com (Senthil Kumar) Date: Mon, 17 Jan 2005 17:34:16 +0530 Subject: OpenSSH-39 not sending syslog msges to proper files References: <07a101c4f8b2$4c017e90$220110ac@sekco> <41EB4FCB.9000508@zip.com.au> Message-ID: <0dab01c4fc8c$af2d2950$220110ac@sekco> >Darren wrote: >It's possibly this: > http://bugzilla.mindrot.org/show_bug.cgi?id=973 Thanks for the pointer. But still the problem exists for me with the suggested patch in hpux 11.11 and 11.23. However, changing the Log level as Debug sends the syslog messages to proper files even with re-exec enabled and without patch. Thanks, Senthil Kumar. --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.791 / Virus Database: 535 - Release Date: 11/18/2004 From dtucker at zip.com.au Mon Jan 17 23:28:14 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 17 Jan 2005 23:28:14 +1100 Subject: OpenSSH-39 not sending syslog msges to proper files In-Reply-To: <0dab01c4fc8c$af2d2950$220110ac@sekco> References: <07a101c4f8b2$4c017e90$220110ac@sekco> <41EB4FCB.9000508@zip.com.au> <0dab01c4fc8c$af2d2950$220110ac@sekco> Message-ID: <41EBAF5E.2060001@zip.com.au> Senthil Kumar wrote: > Thanks for the pointer. But still the problem exists for me with the > suggested patch in hpux 11.11 and 11.23. However, changing the Log level > as Debug sends the syslog messages to proper files even with re-exec > enabled and without patch. Interesting. Does explicitly setting "LogLevel INFO" in sshd_config work 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 dtucker at zip.com.au Mon Jan 17 23:37:18 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 17 Jan 2005 23:37:18 +1100 Subject: OpenSSH-39 not sending syslog msges to proper files In-Reply-To: <0dab01c4fc8c$af2d2950$220110ac@sekco> References: <07a101c4f8b2$4c017e90$220110ac@sekco> <41EB4FCB.9000508@zip.com.au> <0dab01c4fc8c$af2d2950$220110ac@sekco> Message-ID: <41EBB17E.6020701@zip.com.au> Senthil Kumar wrote: > Thanks for the pointer. But still the problem exists for me with the > suggested patch in hpux 11.11 and 11.23. However, changing the Log level > as Debug sends the syslog messages to proper files even with re-exec > enabled and without patch. I suspect that you are seeing a different message at LogLevel=DEBUG. sshd logs "Connection refused by tcp wrapper" via debug. libwrap logs "refused connect from [ip address]" Anyway, I suspect it's libwrap that's being confused by the reexec not sshd itself. What version of libwrap did you use? For clarification: it's only the messages from libwrap that don't get logged, right? -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From senthilkumar_sen at hotpop.com Tue Jan 18 01:10:26 2005 From: senthilkumar_sen at hotpop.com (Senthil Kumar) Date: Mon, 17 Jan 2005 19:40:26 +0530 Subject: OpenSSH-39 not sending syslog msges to proper files References: <07a101c4f8b2$4c017e90$220110ac@sekco> <41EB4FCB.9000508@zip.com.au><0dab01c4fc8c$af2d2950$220110ac@sekco> <41EBB17E.6020701@zip.com.au> Message-ID: <0ddd01c4fc9e$4ee02040$220110ac@sekco> >Darren wrote: > I suspect that you are seeing a different message at LogLevel=DEBUG. > > sshd logs "Connection refused by tcp wrapper" via debug. > libwrap logs "refused connect from [ip address]" Im seeing both the messages for Log Level=Debug. >What version of libwrap did you use? I use version 7.6 of tcp_wrappers. > For clarification: it's only the messages from libwrap that don't get > logged, right? Yes. Thanks, Senthil Kumar --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.791 / Virus Database: 535 - Release Date: 11/18/2004 From bob at proulx.com Tue Jan 18 05:41:57 2005 From: bob at proulx.com (Bob Proulx) Date: Mon, 17 Jan 2005 11:41:57 -0700 Subject: Feature requests for scp and ssh In-Reply-To: <82fa6638050116161345844edf@mail.gmail.com> References: <82fa6638050116161345844edf@mail.gmail.com> Message-ID: <20050117184157.GB32613@dementia.proulx.com> Simon Kissane wrote: > Would it be possible to add an option to the scp command, so that if a > destination file already exists, rather than overwriting it, scp just > skips the destination file, prints a message to stderr and returns an > error (non-zero) exit? That would help me immensely. I suggest you use 'rsync' over 'ssh'. The rsync program has a many options. Look at the -u, --update option. http://rsync.samba.org Bob From code at pizzashack.org Sat Jan 15 16:24:26 2005 From: code at pizzashack.org (Derek Martin) Date: Sat, 15 Jan 2005 00:24:26 -0500 Subject: rssh and scponly arbitrary command execution In-Reply-To: <20041202135143.GA7105@xc.net> References: <20041202135143.GA7105@xc.net> Message-ID: <20050115052426.GG8855@sophic.org> I just released rssh version 2.2.3 to fix the problem detailed below. I haven't had time to update my website yet, and my Internet acess is quite limited these days (hence the terse announcement), so I probably won't get to that for a while. However, rssh 2.2.3 is available from the sourceforge.net site: http://sourceforge.net/projects/rssh All users of rssh should update to the latest release. The rssh homepage is here: http://www.pizzashack.org/rssh Sorry for the slow response; I've had other priorities lately. DM On Thu, Dec 02, 2004 at 01:51:43PM +0000, Jason Wies wrote: > Vulnerable applications: > > rssh > All versions > All operating systems > scponly > All versions > All operating systems > > Not vulnerable: > > Discussion: > > rssh and scponly are restricted shells that are designed to allow execution > only of certain preset programs. Both are used to grant a user the ability > to transfer files to and from a remote host without granting full shell > access. Due to the fact that most of the preset programs offer options that > execute other programs, arbitrary command execution on the remote host is > possible. > > rssh allows any of five predefined programs to be executed on the remote > host depending on the configuration. Those that are known to be vulnerable > in combination with the techniques described in this posting are marked with > an asterisk. > - scp* > - sftp-server > - cvs > - rdist* > - rsync* > > scponly allows a number of predefined programs to be executed on the remote > host depending on compile-time options. Those that are known to be > vulnerable when used with scponly: > - scp > - rsync > - unison (*untested) > > The program execution options that these programs offer: > > rdist -P > rsync -e > scp -S > unison -rshcmd > unison -sshcmd > > These options allow the user to specify the location of the shell to use > when connecting to the remote host. No restriction is placed on what > programs may be specified by these options, and rssh and scponly do not > filter these options out. The end result is that although a user may be > restricted by rssh or scponly to running e.g. only /usr/bin/scp, they can > in fact execute any program using /usr/bin/scp -S . > > The problem is compounded when you recognize that the main use of rssh and > scponly is to allow file transfers, which in turn allows a malicious user to > transfer and execute entire custom scripts on the remote machine. > > rssh with sftp-server does not appear to be vulnerable. rssh with cvs is > also not vulnerable using these techniques. However, it is quite probable > that a malicious user could check out a carefully crafted CVS repository and > execute arbitrary commands using CVS's hooks interface. > > Examples: > > ssh restricteduser at remotehost 'rsync -e "touch /tmp/example --" localhost:/dev/null /tmp' > > scp command.sh restricteduser at remotehost:/tmp/command.sh > ssh restricteduser at remotehost 'scp -S /tmp/command.sh localhost:/dev/null /tmp' > > Solution: > > There are no workarounds for this problem. > > I have talked with the author of rssh, Derek Martin. He is currently > indisposed for an indefinite period of time due to changing countries and > having no permanent home at the present moment. Moreover he has other > priorities and has lost interest in maintaining the program. He has offered > to assist anyone who would like to take over maintainership of rssh, but he > does not intend to provide a fix for the current problem. Given this fact, > I would strongly recommend against using rssh at this time. > > The author of scponly, Joe Boyle, has prepared a new release, version 4.0, > that addresses the current problem. > > Distributor updates have been coordinated with this posting and should be > available soon. > > I think the long-term solution for those needing a highly secure restricted > shell is to allow granular configuration by administrators of which options > and arguments, if any, are allowed to be specified for which programs. In > the most restricted case entire command lines would be stored on the remote > host and the client would be allowed only to select from the list of > available command lines. I'm not aware of any software that offers these > capabilities today. > > References: > http://www.pizzashack.org/rssh/index.shtml > http://www.sublimation.org/scponly/ > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://productguide.itmanagersjournal.com/ > _______________________________________________ > rssh-discuss mailing list > rssh-discuss at lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/rssh-discuss -- Derek D. Martin http://www.pizzashack.org/ GPG Key ID: 0x81CFE75D -------------- 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/20050115/7b95688e/attachment-0002.bin From senthilkumar_sen at hotpop.com Wed Jan 19 03:18:16 2005 From: senthilkumar_sen at hotpop.com (Senthil Kumar) Date: Tue, 18 Jan 2005 21:48:16 +0530 Subject: OpenSSH-39 not sending syslog msges to proper files References: <07a101c4f8b2$4c017e90$220110ac@sekco> <41EB4FCB.9000508@zip.com.au><0dab01c4fc8c$af2d2950$220110ac@sekco><41EBB17E.6020701@zip.com.au> <0ddd01c4fc9e$4ee02040$220110ac@sekco> Message-ID: <03d801c4fd79$545010e0$220110ac@sekco> Hi, Some more info on the problem: The syslog messages from tcp_wrappers are not directed to proper files even when I leave syslog facility to be the default value AUTH and Log level as INFO. However, when I use -r option with sshd, the log messages are directed to proper files. Thanks, Senthil Kumar --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.791 / Virus Database: 535 - Release Date: 11/9/2004 From djm at mindrot.org Wed Jan 19 13:10:22 2005 From: djm at mindrot.org (Damien Miller) Date: Wed, 19 Jan 2005 13:10:22 +1100 Subject: Bugzilla upgrade Message-ID: <41EDC18E.5020106@mindrot.org> Hi, Just a note to inform everyone that http://bugzilla.mindrot.org/ has been upgraded to the latest stable release of bugzilla (2.18). If you experience any problems as a result of this upgrade, please report them to me. Thanks, Damien Miller From martin.dudle at mgb.ch Thu Jan 20 03:29:50 2005 From: martin.dudle at mgb.ch (Martin Dudle) Date: Wed, 19 Jan 2005 17:29:50 +0100 Subject: sshd hangs Message-ID: <41EE8AFE.7040804@mgb.ch> using openssh-3.8.1p1 from sunfreeware.com on a SunOS XXX 5.8 Generic_117000-03 sun4u sparc SUNW,Sun-Fire-V240. sshd seems to ignore or miss SIGCLD. this is a rare behaviour we observe about once per week in a ssh intensive environment. the process hangs here: truss: 24453: poll(0xFFBEEF28, 2, -1) (sleeping...) gcore, mdb: libc.so.1`_poll+4(b, 0, 0, ffbeef38, 6fc40, ffbeef28) 0x20710(ffbef084, ffbef080, ffbef07c, ffbef078, 0, 1) server_loop2+0xd4(6a800, 0, 0, ff1e8000, 2151c, 1) do_authenticated+0x80(753b0, 6a400, f90, 1, 2151c, 6d800) main+0xbf4(2f, 6fc00, 6a800, 1ecc, 1, 6dbd0) _start+0x5c(0, 0, 0, 0, 0, 0) the corresponding c sources are: void server_loop2(Authctxt *authctxt) { [ ... ] for (;;) { process_buffered_input_packets(); rekeying = (xxx_kex != NULL && !xxx_kex->done); if (!rekeying && packet_not_very_much_data_to_write()) channel_output_poll(); wait_until_can_do_something(&readset, &writeset, &max_fd, &nalloc, 0); [ ...] and it hangs in the select() call in wait_until_can_do_something(). question: why is the wait time set to 0 (= wait forever) ? server_loop() (the interactive function) does not set it to 0. if the child exits without the parent noting it then we hung forever which is bad. i tried to send the process a SIGCLD by hand to see if it would 'unlock' itself. here's the result: # kill -CLD 24453 truss: 24453: Received signal #18, SIGCLD, in poll() [caught] 24453: poll(0xFFBEEF28, 2, -1) Err#4 EINTR 24453: sigaction(SIGCLD, 0x00000000, 0xFFBEEA90) = 0 24453: write(6, "\0", 1) = 1 24453: setcontext(0xFFBEEC10) 24453: sigprocmask(SIG_BLOCK, 0xFFBEEFE8, 0xFFBEEFF8) = 0 24453: waitid(P_ALL, 0, 0xFFBEEF00, WEXITED|WTRAPPED|WNOHANG) Err#10 ECHILD 24453: sigprocmask(SIG_SETMASK, 0xFFBEEFF8, 0x00000000) = 0 24453: poll(0xFFBEEF28, 2, -1) = 1 24453: read(4, "\0", 1) = 1 24453: read(4, 0xFFBEEF8F, 1) Err#11 EAGAIN 24453: sigprocmask(SIG_BLOCK, 0xFFBEEFE8, 0xFFBEEFF8) = 0 24453: sigprocmask(SIG_SETMASK, 0xFFBEEFF8, 0x00000000) = 0 24453: poll(0xFFBEEF28, 2, -1) (sleeping...) it seems there is another problem here with collect_children() not handling ECHILD: { pid_t pid; sigset_t oset, nset; int status; /* block SIGCHLD while we check for dead children */ sigemptyset(&nset); sigaddset(&nset, SIGCHLD); sigprocmask(SIG_BLOCK, &nset, &oset); if (child_terminated) { while ((pid = waitpid(-1, &status, WNOHANG)) > 0 || (pid < 0 && errno == EINTR)) if (pid > 0) session_close_by_pid(pid, status); child_terminated = 0; } sigprocmask(SIG_SETMASK, &oset, NULL); } waitpid returns -1 with errno == ECHILD. child_terminated is set to FALSE (why?) and that's it. the program returns to the endless loop (for (;;)) in server_loop2() and sleeps forever again. could anyone shed some light into this thoughts? thanks. regards, -martin dudle From dtucker at zip.com.au Thu Jan 20 08:52:29 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 20 Jan 2005 08:52:29 +1100 Subject: sshd hangs In-Reply-To: <41EE8AFE.7040804@mgb.ch> References: <41EE8AFE.7040804@mgb.ch> Message-ID: <41EED69D.3040506@zip.com.au> Martin Dudle wrote: > using openssh-3.8.1p1 from sunfreeware.com on a SunOS XXX 5.8 > Generic_117000-03 sun4u sparc SUNW,Sun-Fire-V240. > > sshd seems to ignore or miss SIGCLD. this is a rare behaviour we observe > about once per week in a ssh intensive environment. Try the patch attached to this bug: http://bugzilla.mindrot.org/show_bug.cgi?id=967 -- 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 tryponraj at gmail.com Thu Jan 20 20:23:33 2005 From: tryponraj at gmail.com (Ponraj Mathiazagan) Date: Thu, 20 Jan 2005 14:53:33 +0530 Subject: PermitRootLogin without-password functionality differs for UsePAM yes/no option Message-ID: Hi, I am using OpenSSH 3.9p1. For " UsePAM yes/no " option with " PermitRootLogin without-password", the server functionality differs. For " UsePAM yes ", the server allows authentication thru password, meanwhile " UsePAM no " does not. I have fixed that problem and the patch is given below. --------------------------------------------------------------------- File: auth.c In auth_root_allowed() function +if ((strcmp(method, "password") != 0 ) && (strcmp(method, "keyboard-interactive/pam") !=0)) + return 1; -if (strcmp(method, "password") != 0 ) --------------------------------------------------------------------- Please let me know whether this patch will produce any undesired effect. Thanks Ponraj M From dtucker at zip.com.au Thu Jan 20 20:43:53 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 20 Jan 2005 20:43:53 +1100 Subject: PermitRootLogin without-password functionality differs for UsePAM yes/no option In-Reply-To: References: Message-ID: <41EF7D59.30902@zip.com.au> Ponraj Mathiazagan wrote: > I am using OpenSSH 3.9p1. For " UsePAM yes/no " option with " > PermitRootLogin without-password", the server functionality differs. > For " UsePAM yes ", the server allows authentication thru password, > meanwhile " UsePAM no " does not. Strictly speaking it's keyboard-interactive authentication, not password. It's backended onto PAM, which in your case happens to authenticate via a simple password (it could have been S/Key or OPIE or mental telepathy but sshd has no way to know what PAM has in mind). You can prevent this by setting "PasswordAuthentication yes" and "ChallengeResponseAuthentication no" in sshd_config. > I have fixed that problem and the > patch is given below. [...] > Please let me know whether this patch will produce any undesired effect. If PAM inserts a delay on failed auth attempts, your patch will return faster when the auth attempt gets the root password right. Anyway, this particular problem was fixed earlier today in a way that (hopefully :-) won't do that. See http://bugzilla.mindrot.org/show_bug.cgi?id=971 and/or try tomorrow's snapshot. -- 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 mstone at mathom.us Thu Jan 20 23:50:48 2005 From: mstone at mathom.us (Michael Stone) Date: Thu, 20 Jan 2005 07:50:48 -0500 Subject: PermitRootLogin without-password functionality differs for UsePAM yes/no option In-Reply-To: <41EF7D59.30902@zip.com.au> References: <41EF7D59.30902@zip.com.au> Message-ID: <20050120125048.GF26791@mathom.us> On Thu, Jan 20, 2005 at 08:43:53PM +1100, you wrote: >Strictly speaking it's keyboard-interactive authentication, not >password. It's backended onto PAM, which in your case happens to >authenticate via a simple password (it could have been S/Key or OPIE or >mental telepathy but sshd has no way to know what PAM has in mind). > >You can prevent this by setting "PasswordAuthentication yes" and >"ChallengeResponseAuthentication no" in sshd_config. But that completely changes the authentication for all users. Let's try putting this a different way: it would be nifty if there were a way to allow root logins only with a key (which is what people thought they were getting when they set without-password) which is short of forced-command only. Mike Stone From dtucker at zip.com.au Fri Jan 21 00:42:04 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 21 Jan 2005 00:42:04 +1100 Subject: PermitRootLogin without-password functionality differs for UsePAM yes/no option In-Reply-To: <20050120125048.GF26791@mathom.us> References: <41EF7D59.30902@zip.com.au> <20050120125048.GF26791@mathom.us> Message-ID: <41EFB52C.2010002@zip.com.au> Michael Stone wrote: > On Thu, Jan 20, 2005 at 08:43:53PM +1100, you wrote: >> You can prevent this by setting "PasswordAuthentication yes" and >> "ChallengeResponseAuthentication no" in sshd_config. > > But that completely changes the authentication for all users. Let's try > putting this a different way: it would be nifty if there were a way to > allow root logins only with a key (which is what people thought they > were getting when they set without-password) which is short of > forced-command only. There is. It's in bug #971, already in the development tree and was described in the part of the message you snipped. -- 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 mstone at mathom.us Fri Jan 21 00:48:35 2005 From: mstone at mathom.us (Michael Stone) Date: Thu, 20 Jan 2005 08:48:35 -0500 Subject: PermitRootLogin without-password functionality differs for UsePAM yes/no option In-Reply-To: <41EFB52C.2010002@zip.com.au> References: <41EF7D59.30902@zip.com.au> <20050120125048.GF26791@mathom.us> <41EFB52C.2010002@zip.com.au> Message-ID: <20050120134835.GH26791@mathom.us> On Fri, Jan 21, 2005 at 12:42:04AM +1100, Darren Tucker wrote: >There is. It's in bug #971, already in the development tree and was >described in the part of the message you snipped. Hmm. I read the bug before I posted and didn't see the change buried under "Feed bogus input to PAM for invalid logins". Mike Stone From jpmg at eng.cam.ac.uk Thu Jan 20 21:27:17 2005 From: jpmg at eng.cam.ac.uk (Patrick Gosling) Date: Thu, 20 Jan 2005 10:27:17 +0000 Subject: AllowUsers - proposal for useful variations on the theme Message-ID: A short while ago, I looked at using the AllowUsers configuration option in openssh (v3.8p1 , but I believe this to be unchanged in 3.9p1) to restrict access such that only specific remote machines could access specific local accounts. I swiftly discovered that a) specifying wildcarded IP numbers to try to allow a useful IP range was pointless: if I specified AllowUsers joe at 192.0.34.* then an attacker who controlled their own DNS could trivially arrange to connect from 192.0.34.example.com (the openssh code only checks (and complains) if the reverse DNS lookup returns a purely numeric "hostname"). b) specifying hostnames was less useful than I might have hoped, since the code took only the canonical name obtained by DNS lookup of the connecting host's IP address and matched that against the (potentially wildcarded) host components of the AllowUsers entries. The problem here is that it will commonly be the case that the hostname that a user would like to specify that they'll connect from might be one provided by a "dynamic dns" provider, but the hostname that sshd will regard as theirs will be some random (regularly changing) thing generated by their ISP. I'll note here that I don't believe that AllowUsers (even if designed right) would provide robust security, but that it could be a useful component of a more complex security policy. So I'm aware that depending on the security and robustness of a service like dyndns.org as part of a local security policy is imperfect; but I also think that it provides non-trivial benefit in practice. The conclusion of this was that, having decided that modifying the specification/behaviour of the AllowUsers option to fix these observed difficulties was not acceptable (since it might break existing configurations), I've written a small patch to 3.8p1 that adds two new configuration options: AllowUsersFixedname which accepts the same arguments as AllowUsers, but which does not treat the HOST component of a USER at HOST entry as wildcarded. Instead it takes the IP number of the connecting host, and tests if it matches any of the IP numbers returned by a DNS lookup on the HOST component of the USER at HOST entry. AllowUsersIpaddr which accepts the same arguments as AllowUsers, allows wildcards, but which only does the IP matching test, not the hostname matching test. I would very much welcome feedback on the viability of this; it's clearly to my benefit to try to convince people that this would be a useful feature to incorporate in openssh, since I've had unpleasant experience in the past of having to reverse engineer local bodges into new releases at high speed after security issues have been publicised 8-) . Relevant diff against 3.9p1 appended below (although it should be noted that I've only tested this in anger against 3.8p1 ; however the changelog suggests that this is not an area where there's substantial change between 3.8 and 3.9 ...) Patrick Gosling, Department of Engineering, University of Cambridge. --------------------------------------------------------------------------- diff -r -U 8 openssh-3.9p1.orig/auth.c openssh-3.9p1.jpmg/auth.c --- openssh-3.9p1.orig/auth.c 2004-08-12 13:40:25.000000000 +0100 +++ openssh-3.9p1.jpmg/auth.c 2005-01-20 10:11:24.689070494 +0000 @@ -69,17 +69,17 @@ * Otherwise true is returned. */ int allowed_user(struct passwd * pw) { struct stat st; const char *hostname = NULL, *ipaddr = NULL, *passwd = NULL; char *shell; - int i; + int i, allowed; #ifdef USE_SHADOW struct spwd *spw = NULL; #endif /* Shouldn't be called if pw is NULL, but better safe than sorry... */ if (!pw || !pw->pw_name) return 0; @@ -138,44 +138,85 @@ } if (S_ISREG(st.st_mode) == 0 || (st.st_mode & (S_IXOTH|S_IXUSR|S_IXGRP)) == 0) { logit("User %.100s not allowed because shell %.100s is not executable", pw->pw_name, shell); return 0; } - if (options.num_deny_users > 0 || options.num_allow_users > 0) { + if (options.num_deny_users > 0 || options.num_allow_users > 0 || + options.num_allow_users_fixedname > 0 || + options.num_allow_users_ipaddr > 0 ) { hostname = get_canonical_hostname(options.use_dns); ipaddr = get_remote_ipaddr(); } /* Return false if user is listed in DenyUsers */ if (options.num_deny_users > 0) { for (i = 0; i < options.num_deny_users; i++) if (match_user(pw->pw_name, hostname, ipaddr, options.deny_users[i])) { logit("User %.100s not allowed because listed in DenyUsers", pw->pw_name); return 0; } } - /* Return false if AllowUsers isn't empty and user isn't listed there */ + /* Check all of AllowUsers, AllowUsersIpaddr and AllowUsersFixedname + If none of them set, allow. + If any set and user at host matches against any, allow. + Else return 0; */ + + if ((options.num_allow_users > 0) || + (options.num_allow_users_fixedname > 0) || + (options.num_allow_users_ipaddr > 0)) { + allowed = 0; + } else { + allowed = 1; + } + if (options.num_allow_users > 0) { for (i = 0; i < options.num_allow_users; i++) if (match_user(pw->pw_name, hostname, ipaddr, options.allow_users[i])) break; /* i < options.num_allow_users iff we break for loop */ - if (i >= options.num_allow_users) { - logit("User %.100s not allowed because not listed in AllowUsers", - pw->pw_name); - return 0; + if (i < options.num_allow_users) { + allowed = 1; + } + } + + if (options.num_allow_users_fixedname > 0) { + for (i = 0; i < options.num_allow_users_fixedname; i++) + if (match_user_fixedname(pw->pw_name, hostname, + options.allow_users[i])) + break; + /* i < options.num_allow_users_fixedname iff we break for loop */ + if (i < options.num_allow_users_fixedname) { + allowed = 1; } } + + if (options.num_allow_users_ipaddr > 0) { + for (i = 0; i < options.num_allow_users_ipaddr; i++) + if (match_user(pw->pw_name, NULL, ipaddr, + options.allow_users_ipaddr[i])) + break; + /* i < options.num_allow_users_ipaddr iff we break for loop */ + if (i < options.num_allow_users_ipaddr) { + allowed = 1; + } + } + + if (allowed == 0) { + logit("User %.100s not allowed because not listed in AllowUsers, AllowUsersFixedname or AllowUsersIpaddr", + pw->pw_name); + return 0; + } + if (options.num_deny_groups > 0 || options.num_allow_groups > 0) { /* Get the user's group access list (primary and supplementary) */ if (ga_init(pw->pw_name, pw->pw_gid) == 0) { logit("User %.100s not allowed because not in any group", pw->pw_name); return 0; } diff -r -U 8 openssh-3.9p1.orig/match.c openssh-3.9p1.jpmg/match.c --- openssh-3.9p1.orig/match.c 2002-03-05 01:42:43.000000000 +0000 +++ openssh-3.9p1.jpmg/match.c 2005-01-20 10:11:24.690070417 +0000 @@ -43,16 +43,19 @@ /* * Returns true if the given string matches the pattern (which may contain ? * and * as wildcards), and zero if it does not match. */ int match_pattern(const char *s, const char *pattern) { + if (s == NULL) + return 0; + for (;;) { /* If at end of pattern, accept if also at end of string. */ if (!*pattern) return !*s; if (*pattern == '*') { /* Skip the asterisk. */ pattern++; @@ -217,16 +220,58 @@ if ((ret = match_pattern(user, pat)) == 1) ret = match_host_and_ip(host, ipaddr, p); xfree(pat); return ret; } +int +match_user_fixedname(const char *user, const char *ipaddr, + const char *pattern) +{ + char *p, *pat; + int ret; + struct addrinfo hints, *ai, *aitop, ntop[NI_MAXHOST]; + + if ((p = strchr(pattern, '@')) == NULL) + return match_pattern(user, pattern); + + pat = xstrdup(pattern); + p = strchr(pat, '@'); + *p++ = '\0'; + + if ((ret = match_pattern(user, pat)) == 1) { + memset(&hints, 0, sizeof(hints)); + hints.ai_socktype = SOCK_DGRAM; /* dummy */ + if (getaddrinfo(p, NULL, &hints, &aitop) != 0) { + logit("checking getaddrinfo for %.700s failed - " + "check AllowUsersFixedname entry!", p); + ret = 0; + } else { + ret = 0; + for (ai = aitop; ai; ai = ai->ai_next) { + if (getnameinfo(ai->ai_addr, ai->ai_addrlen, + ntop, sizeof(ntop), NULL, 0, + NI_NUMERICHOST) == 0 && + (strcmp(ipaddr, ntop) == 0)) { + ret = 1; + break; + } + } + } + freeaddrinfo(aitop); + } + + xfree(pat); + + return ret; +} + /* * Returns first item from client-list that is also supported by server-list, * caller must xfree() returned string. */ #define MAX_PROP 40 #define SEP "," char * match_list(const char *client, const char *server, u_int *next) diff -r -U 8 openssh-3.9p1.orig/match.h openssh-3.9p1.jpmg/match.h --- openssh-3.9p1.orig/match.h 2002-03-05 01:42:43.000000000 +0000 +++ openssh-3.9p1.jpmg/match.h 2005-01-20 10:11:24.691070340 +0000 @@ -14,11 +14,12 @@ #ifndef MATCH_H #define MATCH_H int match_pattern(const char *, const char *); int match_pattern_list(const char *, const char *, u_int, int); int match_hostname(const char *, const char *, u_int); int match_host_and_ip(const char *, const char *, const char *); int match_user(const char *, const char *, const char *, const char *); +int match_user_fixedname(const char *, const char *, const char *); char *match_list(const char *, const char *, u_int *); #endif diff -r -U 8 openssh-3.9p1.orig/servconf.c openssh-3.9p1.jpmg/servconf.c --- openssh-3.9p1.orig/servconf.c 2004-08-13 12:30:24.000000000 +0100 +++ openssh-3.9p1.jpmg/servconf.c 2005-01-20 10:11:54.385791373 +0000 @@ -78,16 +78,17 @@ options->kbd_interactive_authentication = -1; options->challenge_response_authentication = -1; options->permit_empty_passwd = -1; options->permit_user_env = -1; options->use_login = -1; options->compression = -1; options->allow_tcp_forwarding = -1; options->num_allow_users = 0; + options->num_allow_users_fixedname = 0; options->num_deny_users = 0; options->num_allow_groups = 0; options->num_deny_groups = 0; options->ciphers = NULL; options->macs = NULL; options->protocol = SSH_PROTO_UNKNOWN; options->gateway_ports = -1; options->num_subsystems = 0; @@ -258,17 +259,17 @@ sKerberosAuthentication, sKerberosOrLocalPasswd, sKerberosTicketCleanup, sKerberosGetAFSToken, sKerberosTgtPassing, sChallengeResponseAuthentication, sPasswordAuthentication, sKbdInteractiveAuthentication, sListenAddress, sPrintMotd, sPrintLastLog, sIgnoreRhosts, sX11Forwarding, sX11DisplayOffset, sX11UseLocalhost, sStrictModes, sEmptyPasswd, sTCPKeepAlive, sPermitUserEnvironment, sUseLogin, sAllowTcpForwarding, sCompression, - sAllowUsers, sDenyUsers, sAllowGroups, sDenyGroups, + sAllowUsers, sAllowUsersFixedname, sAllowUsersIpaddr, sDenyUsers, sAllowGroups, sDenyGroups, sIgnoreUserKnownHosts, sCiphers, sMacs, sProtocol, sPidFile, sGatewayPorts, sPubkeyAuthentication, sXAuthLocation, sSubsystem, sMaxStartups, sMaxAuthTries, sBanner, sUseDNS, sHostbasedAuthentication, sHostbasedUsesNameFromPacketOnly, sClientAliveInterval, sClientAliveCountMax, sAuthorizedKeysFile, sAuthorizedKeysFile2, sGssAuthentication, sGssCleanupCreds, sAcceptEnv, sUsePrivilegeSeparation, @@ -347,16 +348,18 @@ { "permitemptypasswords", sEmptyPasswd }, { "permituserenvironment", sPermitUserEnvironment }, { "uselogin", sUseLogin }, { "compression", sCompression }, { "tcpkeepalive", sTCPKeepAlive }, { "keepalive", sTCPKeepAlive }, /* obsolete alias */ { "allowtcpforwarding", sAllowTcpForwarding }, { "allowusers", sAllowUsers }, + { "allowusersfixedname", sAllowUsersFixedname }, + { "allowusersipaddr", sAllowUsersIpaddr }, { "denyusers", sDenyUsers }, { "allowgroups", sAllowGroups }, { "denygroups", sDenyGroups }, { "ciphers", sCiphers }, { "macs", sMacs }, { "protocol", sProtocol }, { "gatewayports", sGatewayPorts }, { "subsystem", sSubsystem }, @@ -761,16 +764,36 @@ if (options->num_allow_users >= MAX_ALLOW_USERS) fatal("%s line %d: too many allow users.", filename, linenum); options->allow_users[options->num_allow_users++] = xstrdup(arg); } break; + case sAllowUsersFixedname: + while ((arg = strdelim(&cp)) && *arg != '\0') { + if (options->num_allow_users_fixedname >= MAX_ALLOW_USERS) + fatal("%s line %d: too many allow users (fixedname).", + filename, linenum); + options->allow_users_fixedname[options->num_allow_users_fixedname++] = + xstrdup(arg); + } + break; + + case sAllowUsersIpaddr: + while ((arg = strdelim(&cp)) && *arg != '\0') { + if (options->num_allow_users_ipaddr >= MAX_ALLOW_USERS) + fatal("%s line %d: too many allow users.", + filename, linenum); + options->allow_users_ipaddr[options->num_allow_users_ipaddr++] = + xstrdup(arg); + } + break; + case sDenyUsers: while ((arg = strdelim(&cp)) && *arg != '\0') { if (options->num_deny_users >= MAX_DENY_USERS) fatal( "%s line %d: too many deny users.", filename, linenum); options->deny_users[options->num_deny_users++] = xstrdup(arg); } diff -r -U 8 openssh-3.9p1.orig/servconf.h openssh-3.9p1.jpmg/servconf.h --- openssh-3.9p1.orig/servconf.h 2004-06-25 04:33:20.000000000 +0100 +++ openssh-3.9p1.jpmg/servconf.h 2005-01-20 10:11:24.696069956 +0000 @@ -95,16 +95,20 @@ int permit_empty_passwd; /* If false, do not permit empty * passwords. */ int permit_user_env; /* If true, read ~/.ssh/environment */ int use_login; /* If true, login(1) is used */ int compression; /* If true, compression is allowed */ int allow_tcp_forwarding; u_int num_allow_users; char *allow_users[MAX_ALLOW_USERS]; + u_int num_allow_users_fixedname; + char *allow_users_fixedname[MAX_ALLOW_USERS]; + u_int num_allow_users_ipaddr; + char *allow_users_ipaddr[MAX_ALLOW_USERS]; u_int num_deny_users; char *deny_users[MAX_DENY_USERS]; u_int num_allow_groups; char *allow_groups[MAX_ALLOW_GROUPS]; u_int num_deny_groups; char *deny_groups[MAX_DENY_GROUPS]; u_int num_subsystems; diff -r -U 8 openssh-3.9p1.orig/sshd.8 openssh-3.9p1.jpmg/sshd.8 --- openssh-3.9p1.orig/sshd.8 2004-05-02 13:15:08.000000000 +0100 +++ openssh-3.9p1.jpmg/sshd.8 2005-01-20 10:11:24.697069880 +0000 @@ -330,16 +330,18 @@ .Cm RhostsRSAAuthentication , .Cm HostbasedAuthentication and using a .Cm from="pattern-list" option in a key file. Configuration options that require DNS include using a USER at HOST pattern in .Cm AllowUsers +, +.Cm AllowUsersFixedname or .Cm DenyUsers . .El .Sh CONFIGURATION FILE .Nm reads configuration data from .Pa /etc/ssh/sshd_config (or the file specified with diff -r -U 8 openssh-3.9p1.orig/sshd_config.5 openssh-3.9p1.jpmg/sshd_config.5 --- openssh-3.9p1.orig/sshd_config.5 2004-06-30 13:39:34.000000000 +0100 +++ openssh-3.9p1.jpmg/sshd_config.5 2005-01-20 10:13:10.850922736 +0000 @@ -112,16 +112,48 @@ .Ql \&? can be used as wildcards in the patterns. Only user names are valid; a numerical user ID is not recognized. By default, login is allowed for all users. If the pattern takes the form USER at HOST then USER and HOST are separately checked, restricting logins to particular users from particular hosts. +.Pp +The HOST component is tested for a match against +the IP number and the hostname of the connecting host. It is +critically important to note that many wildcarded representations of +IP numbers can be trivially matched by an attacker with control of +their DNS (eg if the allowed HOST was specified as +.Ql 192.0.34.* +then an attacker controlling the zone example.com would merely need to +create an entry in the DNS for a host called +.Ql 192.0.34.example.com +to get past this restriction). The AllowUsersIpaddr option avoids this +problem. +.Pp +A further restriction on this option is that only the canonical name +of the connecting host is tested for a match against the HOST +component; if the allowed hostname is an cname alias of the connecting +host, connection will not be successful. The AllowUsersFixedname +option avoids this problem. +.Pp +.It Cm AllowUsersFixedname +This keyword can be followed by a list of user name patterns as for +AllowUsers. The behaviour is the same, excepting that the HOST component +of a pattern may not be wildcarded, and that the check made is whether +the IP address from which the connection is being made is one of the +DNS registered IP addresses of the specified HOST. +.Pp +.It Cm AllowUsersIpaddr +This keyword can be followed by a list of user name patterns as for +AllowUsers. The behaviour is the same, excepting that the HOST component +of a pattern, which may be wildcarded, is only tested for a match against +the IP address from which the connection is being made. +.Pp .It Cm AuthorizedKeysFile Specifies the file that contains the public keys that can be used for user authentication. .Cm AuthorizedKeysFile may contain tokens of the form %T which are substituted 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 --------------------------------------------------------------------------- From esp5 at pge.com Fri Jan 21 13:31:55 2005 From: esp5 at pge.com (Edward Peschko) Date: Thu, 20 Jan 2005 18:31:55 -0800 Subject: ftp over ssl via openssh Message-ID: <20050121023155.GC3518@venus> hey all, I was wondering if openssh did ftp via ssl connection - or if not - what unix package out there did this. I'd love to use sftp, but unfortunately the site I need to interface with only has ftp over ssl. Ed From djm at mindrot.org Fri Jan 21 14:26:02 2005 From: djm at mindrot.org (Damien Miller) Date: Fri, 21 Jan 2005 14:26:02 +1100 Subject: ftp over ssl via openssh In-Reply-To: <20050121023155.GC3518@venus> References: <20050121023155.GC3518@venus> Message-ID: <41F0764A.3020700@mindrot.org> Edward Peschko wrote: > hey all, > > I was wondering if openssh did ftp via ssl connection - or if not - what > unix package out there did this. No, OpenSSH doesn't do this. Unsurprisingly, Google has lots of information on ftp over ssl. -d From rapier at psc.edu Sat Jan 22 08:42:33 2005 From: rapier at psc.edu (Christopher Rapier) Date: Fri, 21 Jan 2005 16:42:33 -0500 Subject: Probably a dumb q about scp and buffers Message-ID: <41F17749.5070202@psc.edu> So I was running strace against sshd -D during an scp transfer. I noticed that the scp child was using a buffer size of 4k for its IO while the sshd notty was using a 16k buffer. Which seems to imply that scp is making 4 read/writes for every 1 read/write that sshd is making. If increase amount being read/wrote by scp to 16k then I seem to eliminate 6 system calls per 16k of data. By no means do I understand all the implications of making this change in terms of security which is why I'm asking here. Does this seem like a sensible change to make or should it make no noticable difference (using the time command seems to indicate that we spend 15% to 25% less time in the kernel though). Any thoughts? Feel free to shoot this down, I'm really just poking around at things and this popped into my head. Chris From Martin.Dudle at mgb.ch Tue Jan 25 02:22:06 2005 From: Martin.Dudle at mgb.ch (Martin.Dudle at mgb.ch) Date: Mon, 24 Jan 2005 16:22:06 +0100 Subject: AW: sshd hangs Message-ID: <3857728CF27E1747B9A1E2963FC0DCC403015545@MGBZS741.org.mgbads.mgb.ch> hello applied the patch described below - unfortunately we still experience rare hangs of the remote sshd. not surprising as the patch only changes a few lines in server_loop() - but not in server_loop2() which i used for non-interactive sessions. process id of hanging sshd: 26110 process is sleeping forever in poll (why does server_loop2() sleep forever?): root at XXX:~# truss -fp 26110 26110: poll(0xFFBEF268, 2, -1) (sleeping...) no child processes are around: root at XXX:~# ps -ef | grep 26110 root 26110 24012 0 14:50:11 ? 0:00 /usr/local/sbin/sshd root 8136 7433 0 15:15:34 pts/5 0:00 truss -fp 26110 root 8217 7433 0 15:15:55 pts/5 0:00 grep 26110 sending it a SIGCLD to see if ECHILD would have been handled fine (would not :-/). root at XXX:~# kill -CLD 26110 26110: Received signal #18, SIGCLD, in poll() [caught] 26110: poll(0xFFBEF268, 2, -1) Err#4 EINTR 26110: sigaction(SIGCLD, 0x00000000, 0xFFBEEDD0) = 0 26110: write(6, "\0", 1) = 1 26110: setcontext(0xFFBEEF50) 26110: sigprocmask(SIG_BLOCK, 0xFFBEF328, 0xFFBEF338) = 0 26110: waitid(P_ALL, 0, 0xFFBEF240, WEXITED|WTRAPPED|WNOHANG) Err#10 ECHILD 26110: sigprocmask(SIG_SETMASK, 0xFFBEF338, 0x00000000) = 0 26110: poll(0xFFBEF268, 2, -1) = 1 26110: read(4, "\0", 1) = 1 26110: read(4, 0xFFBEF2CF, 1) Err#11 EAGAIN 26110: sigprocmask(SIG_BLOCK, 0xFFBEF328, 0xFFBEF338) = 0 26110: sigprocmask(SIG_SETMASK, 0xFFBEF338, 0x00000000) = 0 26110: poll(0xFFBEF268, 2, -1) (sleeping...) stack: > $c libc.so.1`_poll+4(b, 0, 0, ffbef278, 68dc8, ffbef268) 0x1f278(ffbef3c4, ffbef3c0, ffbef3bc, ffbef3b8, 0, 1) server_loop2+0xe0(6e518, 0, 0, ff078000, 2151c, 1) do_authenticated+0x80(6e518, 6e518, 6e518, ffbef4c4, 2151c, 66000) main+0xc28(2e, 68d88, 64000, 1, 1ed0, 66674) _start+0x5c(0, 0, 0, 0, 0, 0) disassemble trace: server_loop2+0xe0: call -0x102c <0x1f118> 0x1f0f0: sethi %hi(0x46c00), %o0 ... 0x1f24c: add %fp, -0x18, %o4 0x1f250: sll %o0, 5, %g1 0x1f254: sub %g1, %o0, %g1 0x1f258: sll %g1, 2, %g1 0x1f25c: add %g1, %o0, %g1 0x1f260: sll %g1, 3, %g1 0x1f264: st %g1, [%fp - 0x14] 0x1f268: ld [%i2], %o0 0x1f26c: ld [%i0], %o1 0x1f270: ld [%i1], %o2 0x1f274: add %o0, 1, %o0 0x1f278: call +0x439b8 0x1f27c: clr %o3 c code (patched): static void collect_children(void) { pid_t pid; sigset_t oset, nset; int status; /* block SIGCHLD while we check for dead children */ sigemptyset(&nset); sigaddset(&nset, SIGCHLD); sigprocmask(SIG_BLOCK, &nset, &oset); if (child_terminated) { while ((pid = waitpid(-1, &status, WNOHANG)) > 0 || (pid < 0 && errno == EINTR)) if (pid > 0) session_close_by_pid(pid, status); child_terminated = 0; } sigprocmask(SIG_SETMASK, &oset, NULL); } while there could be code to remove the hang (have select() in server_loop2() not wait forever, have collect_children detect and handle ECHILD properly) i think that the child process should not die or terminate undetected by the parent in the first place. will try to find why this happens and let you know if i find something. regards, -martin Martin Dudle wrote: > using openssh-3.8.1p1 from sunfreeware.com on a SunOS XXX 5.8 > Generic_117000-03 sun4u sparc SUNW,Sun-Fire-V240. > > sshd seems to ignore or miss SIGCLD. this is a rare behaviour we > observe > about once per week in a ssh intensive environment. Try the patch attached to this bug: http://bugzilla.mindrot.org/show_bug.cgi?id=967 -- 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 Pantano.Salvatore at pennmutual.com Wed Jan 26 07:24:58 2005 From: Pantano.Salvatore at pennmutual.com (Pantano, Salvatore) Date: Tue, 25 Jan 2005 15:24:58 -0500 Subject: how to use xml, scp, ant 1.5 Message-ID: I am using ant version 1.5 I know that there is an scp command in ant 1.6 but our plans do not have us moving to 1.6 for a while ( not the only application on the box using ant / xml ). I am running in an IBM Unix environment. I am attempting to get scp to work within an xml file called by ant. Thank You for any support you may provide. Sal Pantano PLEASE NOTE -- SO THAT THE MAIL SYSTEM WOULD ACCEPT THIS MESSAGE -- In my question where you see XX it represents a < where you see YY it represents > xml sysntax. This scp works. The ${formatted_report} is a fully defined file name ( abcdef.xml ) within the local directory. SCP finds the file and copies it to the remote machine. XX!--##############################--YY XX!--### Copy report to wwwroot ###--YY XX!--##############################--YY XXproperty name="seccopy" location="/usr/bin/scp"/YY XXexec executable="${seccopy}"YY XXarg value="-rp"/YY XXarg path="${formatted_report}"/YY XXarg value="${ipname}:${publishReportsDir}"/YY XX/execYY Within the same xml file that is called by ant is this scp code. The problem I am having is "${basedir}/reports/*.xsl" No matter how I put this information scp puts out an error that there are no such file or directory *.xsl. The directory is correct and there are xsl files in it. If I try the scp command as a line command not within the xml file scp does find the *.xsl files and does the copy. Within this code I have put in a fully qualified file name ( abcdef.xsl ) and scp can find it and copy it. The problem is trying to get the right syntax for the wildcard. XX!--#################################--YY XX!--### Copy xsl files to wwwroot ###--YY XX!--#################################--YY XXproperty name="seccopy_a" location="/usr/bin/scp"/YY XXexec executable="${seccopy_a}"YY XXarg value="-rp"/YY XXarg file="${basedir}/reports/*.xsl"/YY XXarg value="${ipname}:${publishReportsDir}"/YY XX/execYY From stuge-openssh-unix-dev at cdy.org Wed Jan 26 08:04:10 2005 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Tue, 25 Jan 2005 22:04:10 +0100 Subject: how to use xml, scp, ant 1.5 In-Reply-To: References: Message-ID: <20050125210410.GA32075@foo.birdnet.se> On Tue, Jan 25, 2005 at 03:24:58PM -0500, Pantano, Salvatore wrote: > Within the same xml file that is called by ant is this scp code. > The problem I am having is "${basedir}/reports/*.xsl" No matter > how I put this information scp puts out an error that there are no > such file or directory *.xsl. I'm not familiar with ant, but this would happen if ant does not do globbing.. (expansion of wildcards matching multiple files) > The directory is correct and there are xsl files in it. If I try > the scp command as a line command not within the xml file scp does > find the *.xsl files and does the copy. ..whereas the shell does. There are several workarounds, one is; scp `find /dir/with/files -name '*.xsl' -print` user at remote:/dir/ //Peter From alex.bell at bt.com Thu Jan 27 00:17:33 2005 From: alex.bell at bt.com (alex.bell at bt.com) Date: Wed, 26 Jan 2005 13:17:33 -0000 Subject: OpenSSH and BSM Message-ID: <3D67CCA7D63E714B980D21A038EEA08E1081BCD7@i2km02-ukbr.domain1.systemhost.net> All, I've recently received a requirement to implement OpenSSH on a Solaris server with BSM enabled. Checking through the list archive suggests that the patch Darren's patch is almost ready but requires testing & perhaps fine-tuning. Can someone please let me know what the status is and if any assistance is required with testing I'm happy to offer an extra pair of hands. Thanks Alex From cblack at global-matrix.com Thu Jan 27 01:22:38 2005 From: cblack at global-matrix.com (Chris Black) Date: Wed, 26 Jan 2005 09:22:38 -0500 Subject: FW: connection refused Message-ID: Sun Solaris 9 client tries to connect to my AIX server running OpenSSH_3.8.1p1 and get "connection refused". e3db1:oracle:/apps/oracle>ssh -V SSH Version Sun_SSH_1.0, protocol versions 1.5/2.0. e3db1:oracle:/apps/oracle>ssh -l user1 aixserver Secure connection to aixserver refused. e3db1:oracle:/apps/oracle> Chris Black From d.holmes at f5.com Thu Jan 27 07:31:14 2005 From: d.holmes at f5.com (David Holmes) Date: Wed, 26 Jan 2005 12:31:14 -0800 Subject: Question about a recent change to uidswap.c in the portability snapshot Message-ID: A change was recently introduced into uidswap.c to cover the case where the user is root. The change is "&& pw->pw_uid != 0 &&". /* Try restoration of GID if changed (test clearing of saved gid) */ if (old_gid != pw->pw_gid && pw->pw_uid != 0 && (setgid(old_gid) != -1 || setegid(old_gid) != -1)) fatal("%s: was able to restore old [e]gid", __func__); My question is, should this change also be included in the setuid() call a few lines later? ... /* Try restoration of UID if changed (test clearing of saved uid) */ if (old_uid != pw->pw_uid && [should change be here also?] (setuid(old_uid) != -1 || seteuid(old_uid) != -1)) fatal("%s: was able to restore old [e]uid", __func__); David Holmes F5 Networks d.holmes at f5.com From dtucker at zip.com.au Thu Jan 27 09:36:16 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 27 Jan 2005 09:36:16 +1100 Subject: Question about a recent change to uidswap.c in the portability snapshot In-Reply-To: References: Message-ID: <41F81B60.1080306@zip.com.au> David Holmes wrote: > A change was recently introduced into uidswap.c to cover the case where > the user is root. The change is "&& pw->pw_uid != 0 &&". > > /* Try restoration of GID if changed (test clearing of saved > gid) */ > if (old_gid != pw->pw_gid && pw->pw_uid != 0 && > (setgid(old_gid) != -1 || setegid(old_gid) != -1)) > fatal("%s: was able to restore old [e]gid", __func__); > > My question is, should this change also be included in the setuid() call > a few lines later? > > /* Try restoration of UID if changed (test clearing of saved > uid) */ > if (old_uid != pw->pw_uid && [should change be here also?] > (setuid(old_uid) != -1 || seteuid(old_uid) != -1)) > fatal("%s: was able to restore old [e]uid", __func__); I don't think it's necessary. The gid test was put in to handle the case where the root user is running as their non-default group (ie they've run "newgrp"). In that case, because root can set its uid to whatever it wants, the group restore test will fail. For the second test, old_uid and pw_uid will be the same so the second test won't fail either. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Thu Jan 27 10:08:25 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 27 Jan 2005 10:08:25 +1100 Subject: FW: connection refused In-Reply-To: References: Message-ID: <41F822E9.3020504@zip.com.au> Chris Black wrote: > Sun Solaris 9 client tries to connect to my AIX server running > OpenSSH_3.8.1p1 and get "connection refused". Make sure that your AIX server has a SSH server and that it's running ("ps -eaf |grep sshd"), and that the sshd is listening on the IP address you're trying to connect to ("netstat -an" and look for something listening on port 22). You can also try connecting to the AIX server's sshd from the AIX server itself ("telnet aixserver 22" or "telnet localhost 22") If the server is running you'll get a banner starting with "SSH-". If those all check out, the start looking for a firewall between client and server that might be refusing the connections. -- 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 Jan 31 12:02:25 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 31 Jan 2005 12:02:25 +1100 Subject: OpenSSH and BSM In-Reply-To: <3D67CCA7D63E714B980D21A038EEA08E1081BCD7@i2km02-ukbr.domain1.systemhost.net> References: <3D67CCA7D63E714B980D21A038EEA08E1081BCD7@i2km02-ukbr.domain1.systemhost.net> Message-ID: <41FD83A1.3000406@zip.com.au> alex.bell at bt.com wrote: > I've recently received a requirement to implement OpenSSH on a Solaris > server with BSM enabled. Checking through the list archive suggests that > the patch Darren's patch is almost ready but requires testing & perhaps > fine-tuning. It's not my patch, it's really Sun's (and John R Jackson's who was caring for and feeding it for a good while). > Can someone please let me know what the status is and if any assistance > is required with testing I'm happy to offer an extra pair of hands. Current status is that the instrumentation in sshd is about ready to be committed (although I'd be happy if someone could look over the privsep bits in the current patch). As to the actual BSM part, I have a version that uses those hooks. It will write audit records (although whether or not those records are complete crap is another question :-). I can make what I have available for testing/review/improvement but it's currently incomplete. I have some queries about the BSM audit model and how to match it to the SSH2 protocol's world view (those are attached to bug [1]). If there are any folks that know BSM better than me (ie at all) then they could help by answering some of those questions. [1] http://bugzilla.mindrot.org/show_bug.cgi?id=125 -- 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 jengelh at linux01.gwdg.de Mon Jan 31 22:54:08 2005 From: jengelh at linux01.gwdg.de (Jan Engelhardt) Date: Mon, 31 Jan 2005 12:54:08 +0100 (MET) Subject: Dead proxy tunnel not cleared Message-ID: Hello, I have been observing the case where some part of the proxy connection(s) break/time out, and the "tunnelconnect" proxy (http://www.taiyo.co.jp/~gotoh/ssh/connect.html) exits. The problem is that the process turns into a zombie and _stays_ that way. SSH (OpenSSH-3.9p1) does not seem to wait() for it. Looks like a "deadwait". Jan Engelhardt -- If you knew the language, you'd know that: ?????????????? From dtucker at zip.com.au Mon Jan 31 23:20:28 2005 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 31 Jan 2005 23:20:28 +1100 Subject: Dead proxy tunnel not cleared In-Reply-To: References: Message-ID: <41FE228C.5080806@zip.com.au> Jan Engelhardt wrote: > I have been observing the case where some part of the proxy connection(s) > break/time out, and the "tunnelconnect" proxy > (http://www.taiyo.co.jp/~gotoh/ssh/connect.html) exits. > > The problem is that the process turns into a zombie and _stays_ that way. > SSH (OpenSSH-3.9p1) does not seem to wait() for it. Looks like a "deadwait". What platform is this on? I'm guessing a Linux 2.6 kernel? You can try the patch here: http://bugzilla.mindrot.org/show_bug.cgi?id=967 Someone reported that this doesn't fix ssh2 sessions but I haven't had time to look at it again. -- 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.