From the.omprakash at gmail.com Tue Jul 3 16:57:19 2007 From: the.omprakash at gmail.com (om prakash) Date: Tue, 3 Jul 2007 12:27:19 +0530 Subject: No subject Message-ID: From dwmw2 at infradead.org Thu Jul 5 07:11:18 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 04 Jul 2007 17:11:18 -0400 Subject: RFE: idle timeout/auto-daemonize combo In-Reply-To: References: Message-ID: <1183583479.29081.113.camel@shinybook.infradead.org> On Fri, 2007-06-22 at 12:33 +0200, Wout Mertens wrote: > My second RFE is to make the script unnecessary, having an > option to automatically create a daemonized master on first > connect. I implemented that a long time ago and posted patches here. http://david.woodhou.se/openssh-control.html -- dwmw2 From djm at mindrot.org Thu Jul 5 09:13:38 2007 From: djm at mindrot.org (Damien Miller) Date: Thu, 5 Jul 2007 09:13:38 +1000 (EST) Subject: RFE: idle timeout/auto-daemonize combo In-Reply-To: <1183583479.29081.113.camel@shinybook.infradead.org> References: <1183583479.29081.113.camel@shinybook.infradead.org> Message-ID: On Wed, 4 Jul 2007, David Woodhouse wrote: > On Fri, 2007-06-22 at 12:33 +0200, Wout Mertens wrote: > > My second RFE is to make the script unnecessary, having an > > option to automatically create a daemonized master on first > > connect. > > I implemented that a long time ago and posted patches here. > http://david.woodhou.se/openssh-control.html Please file bugs for these on https://bugzilla.mindrot.org/ so I don't forget about them again. -d From apb at cequrux.com Thu Jul 5 21:12:05 2007 From: apb at cequrux.com (Alan Barrett) Date: Thu, 5 Jul 2007 13:12:05 +0200 Subject: RFE: idle timeout/auto-daemonize combo In-Reply-To: <1183583479.29081.113.camel@shinybook.infradead.org> References: <1183583479.29081.113.camel@shinybook.infradead.org> Message-ID: <20070705111205.GN9160@apb-laptoy.apb.alt.za> On Wed, 04 Jul 2007, David Woodhouse wrote: > > option to automatically create a daemonized master on first > > connect. > > I implemented that a long time ago and posted patches here. > http://david.woodhou.se/openssh-control.html That looks very useful, but I'd like the background master to exit after remaining unused for a configurable time. --apb (Alan Barrett) From dwmw2 at infradead.org Fri Jul 6 01:33:31 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 05 Jul 2007 11:33:31 -0400 Subject: RFE: idle timeout/auto-daemonize combo In-Reply-To: References: <1183583479.29081.113.camel@shinybook.infradead.org> Message-ID: <1183649612.2797.39.camel@shinybook.infradead.org> On Thu, 2007-07-05 at 09:13 +1000, Damien Miller wrote: > Please file bugs for these on https://bugzilla.mindrot.org/ so > I don't forget about them again. https://bugzilla.mindrot.org/show_bug.cgi?id=1328 - multiple $DISPLAY https://bugzilla.mindrot.org/show_bug.cgi?id=1329 - stale sockets https://bugzilla.mindrot.org/show_bug.cgi?id=1330 - ControlPersist Sorry, I haven't updated the patches and made sure they build and work with the current CVS tree. And my multi-display patch contains some other fixes which I think came from you in the first place so I haven't tried to explain them in detail. But it's basically there. We need to have the argument about multiple agent support again, but I need to win it this time. And we need to sort out the escape handling -- stuff like ~. doesn't work for a ControlClient. That's filed as #1331. At some point when I have a little more time, I'll adjust my ControlPersist patch to close stdin/stdout/stderr. I keep finding that cvs waits for ssh to finish, and when I log out of ssh sessions I've started a d?mon from, they hang too. -- dwmw2 From dwmw2 at infradead.org Fri Jul 6 02:07:29 2007 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 05 Jul 2007 12:07:29 -0400 Subject: RFE: idle timeout/auto-daemonize combo In-Reply-To: <20070705111205.GN9160@apb-laptoy.apb.alt.za> References: <1183583479.29081.113.camel@shinybook.infradead.org> <20070705111205.GN9160@apb-laptoy.apb.alt.za> Message-ID: <1183651650.2797.51.camel@shinybook.infradead.org> On Thu, 2007-07-05 at 13:12 +0200, Alan Barrett wrote: > That looks very useful, but I'd like the background master to exit > after remaining unused for a configurable time. That's a reasonable idea. Why not go ahead and implement it and update the patch in bugzilla? -- dwmw2 From yanagisawa at csg.is.titech.ac.jp Mon Jul 9 20:26:51 2007 From: yanagisawa at csg.is.titech.ac.jp (Yoshisato YANAGISAWA) Date: Mon, 9 Jul 2007 19:26:51 +0900 Subject: The Camellia block cipher for OpenSSH 4.6p1. Message-ID: <20070709192651.22d48a9c.yanagisawa@csg.is.titech.ac.jp> Hi, I implemented a patch for porting the Camellia block cipher to one of the OpenSSH-usable cipher. Camellia is one of the approved encryption methods of NESSIE and has specified in several RFCs. I put the patch at: http://www.is.titech.ac.jp/~yanagis0/text/camellia/openssh-4.6p1-0.2.patch in http://www.is.titech.ac.jp/~yanagis0/text/camellia-e.html. I hope you will enjoy this patch and OpenSSH will use it. Thank you, Yoshisato YANAGISAWA. -- ------------------------------------------------------- Yoshisato YANAGISAWA Dept. of Mathematical and Computing Sciences, Graduate School of Information Science and Engineering, Tokyo Institute of Technology. /* If you are an *BSD user, let's join http://bsdstats.org/ */ From wmertens at cisco.com Tue Jul 10 06:24:10 2007 From: wmertens at cisco.com (Wout Mertens) Date: Mon, 9 Jul 2007 22:24:10 +0200 Subject: RFE: idle timeout/auto-daemonize combo In-Reply-To: <1183649612.2797.39.camel@shinybook.infradead.org> References: <1183583479.29081.113.camel@shinybook.infradead.org> <1183649612.2797.39.camel@shinybook.infradead.org> Message-ID: <76C07493-B649-4EA1-B97A-92C5F6E0F1BF@cisco.com> On Jul 5, 2007, at 5:33 PM, David Woodhouse wrote: > On Thu, 2007-07-05 at 09:13 +1000, Damien Miller wrote: >> Please file bugs for these on https://bugzilla.mindrot.org/ so >> I don't forget about them again. > > https://bugzilla.mindrot.org/show_bug.cgi?id=1328 - multiple $DISPLAY > https://bugzilla.mindrot.org/show_bug.cgi?id=1329 - stale sockets > https://bugzilla.mindrot.org/show_bug.cgi?id=1330 - ControlPersist > > Sorry, I haven't updated the patches and made sure they build and work > with the current CVS tree. And my multi-display patch contains some > other fixes which I think came from you in the first place so I > haven't > tried to explain them in detail. But it's basically there. Well I patched a 4.6p1 without rejects and it compiled fine. One thing I notice is that it enables controlpersist by default. You don't initialize control_persist in readconf.c, is that not necessary? Another thing I noticed is that I can't specify the controlpersist value on the command line, it probably only parses the one in config files. I'm not totally up to speed with the code yet, so I don't know why that is. > We need to have the argument about multiple agent support again, but I > need to win it this time. I've been trying to think of a use case for this... Would a workaround not be to have a master per $DISPLAY? > And we need to sort out the escape handling -- > stuff like ~. doesn't work for a ControlClient. That's filed as #1331. Good point! > At some point when I have a little more time, I'll adjust my > ControlPersist patch to close stdin/stdout/stderr. I keep finding that > cvs waits for ssh to finish, and when I log out of ssh sessions I've > started a d?mon from, they hang too. Why don't you replace the daemonizing bit with a call to daemon(0,0)? I did that and it seems to work just fine, and it behaves better cross-platform to boot. Right now I'm experimenting, trying to get the IdleTimeout patch for sshd ported to the latest versions and getting it to do the same thing with ssh. Together with ControlPersist that will be an awesome combo for scripting. Cheers, Wout. From wmertens at cisco.com Tue Jul 10 22:23:01 2007 From: wmertens at cisco.com (Wout Mertens) Date: Tue, 10 Jul 2007 14:23:01 +0200 Subject: RFE: idle timeout/auto-daemonize combo In-Reply-To: <76C07493-B649-4EA1-B97A-92C5F6E0F1BF@cisco.com> References: <1183583479.29081.113.camel@shinybook.infradead.org> <1183649612.2797.39.camel@shinybook.infradead.org> <76C07493-B649-4EA1-B97A-92C5F6E0F1BF@cisco.com> Message-ID: <5D4F3CD1-5CC6-49EB-A596-7756DE902B98@cisco.com> Heya, On Jul 9, 2007, at 10:24 PM, Wout Mertens wrote: > Well I patched a 4.6p1 without rejects and it compiled fine. One > thing I notice is that it enables controlpersist by default. You > don't initialize control_persist in readconf.c, is that not necessary? > > Another thing I noticed is that I can't specify the controlpersist > value on the command line, it probably only parses the one in > config files. I'm not totally up to speed with the code yet, so I > don't know why that is. > >> At some point when I have a little more time, I'll adjust my >> ControlPersist patch to close stdin/stdout/stderr. I keep finding >> that >> cvs waits for ssh to finish, and when I log out of ssh sessions I've >> started a d?mon from, they hang too. > > Why don't you replace the daemonizing bit with a call to daemon > (0,0)? I did that and it seems to work just fine, and it behaves > better cross-platform to boot. I attached a new patch to https://bugzilla.mindrot.org/show_bug.cgi? id=1330 that incorporates these changes. Works great so far! Wout. From hiaftab at hotmail.com Tue Jul 10 23:00:20 2007 From: hiaftab at hotmail.com (Aftab Ahamed) Date: Tue, 10 Jul 2007 13:00:20 +0000 Subject: No password prompt for ssh from perl script Message-ID: Hi, I need some help from you guys for one issue I am facing with my script. While logging into localhost using ssh from command prompt it works: It works from command prompt --> ssh loginid at localhost But when we try to login to localhost using ssh from perl script using pseudo terminal, I am getting the following without any password prompt. We are getting following instead of password prompt: Permission denied, please try again. Permission denied, please try again. Permission denied (publickey,password,keyboard-interactive) We are using OpenSSH in AIX 5.3 and Perl 5.8.2 Any one has any idea on this why this issue might have occured. If anyone wants to see the code, I can send it. It would be great help if anyone can help in this regard Thanks Aftab _________________________________________________________________ Wedding bells are ringing. When's your time to walk the aisle? http://ad.in.doubleclick.net/clk;112111293;17571293;v?http://www.simplymarry.com/timesmatri/faces/jsp/UserTrackLandingPage.jsp?origin=hotmail_taglines_ros_june07 From dtucker at zip.com.au Tue Jul 10 23:04:04 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 10 Jul 2007 23:04:04 +1000 Subject: No password prompt for ssh from perl script In-Reply-To: References: Message-ID: <469383C4.1040300@zip.com.au> Aftab Ahamed wrote: > Hi, > I need some help from you guys for one issue I am facing with my script. > While logging into localhost using ssh from command prompt it works: > It works from command prompt --> ssh loginid at localhost > > But when we try to login to localhost using ssh from perl script using > pseudo terminal, I am getting the following without any password prompt. > > We are getting following instead of password prompt: > Permission denied, please try again. > Permission denied, please try again. > Permission denied (publickey,password,keyboard-interactive) > > We are using OpenSSH in AIX 5.3 and Perl 5.8.2 > > Any one has any idea on this why this issue might have occured. If anyone > wants to see the code, I can send it. It would be great help if anyone can > help in this regard This can happen if /dev/tty has the wrong permissions (should be mode 666). -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From dtucker at zip.com.au Tue Jul 10 23:49:45 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 10 Jul 2007 23:49:45 +1000 Subject: No password prompt for ssh from perl script In-Reply-To: References: Message-ID: <46938E79.4070609@zip.com.au> Aftab Ahamed wrote: > Hi, > I need some help from you guys for one issue I am facing with my script. > While logging into localhost using ssh from command prompt it works: > It works from command prompt --> ssh loginid at localhost > > But when we try to login to localhost using ssh from perl script using > pseudo terminal, I am getting the following without any password prompt. > > We are getting following instead of password prompt: > Permission denied, please try again. > Permission denied, please try again. > Permission denied (publickey,password,keyboard-interactive) You can also set the SSH_ASKPASS environment variable to point to a program that supplies the password and do away with the pty. > We are using OpenSSH in AIX 5.3 and Perl 5.8.2 > > Any one has any idea on this why this issue might have occured. If anyone > wants to see the code, I can send it. It would be great help if anyone can > help in this regard Perhaps the permissions and/or ownership on the pty slave aren't set correctly? -- 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 wmertens at cisco.com Wed Jul 11 03:10:33 2007 From: wmertens at cisco.com (Wout Mertens) Date: Tue, 10 Jul 2007 19:10:33 +0200 Subject: [openssh-unix-dev] Re: RFE: idle timeout/auto-daemonize combo In-Reply-To: <1183651650.2797.51.camel@shinybook.infradead.org> References: <1183583479.29081.113.camel@shinybook.infradead.org> <20070705111205.GN9160@apb-laptoy.apb.alt.za> <1183651650.2797.51.camel@shinybook.infradead.org> Message-ID: <473D8024-6C50-4B58-8B75-F4216741087A@cisco.com> On Jul 5, 2007, at 6:07 PM, David Woodhouse wrote: > On Thu, 2007-07-05 at 13:12 +0200, Alan Barrett wrote: >> That looks very useful, but I'd like the background master to exit >> after remaining unused for a configurable time. > > That's a reasonable idea. Why not go ahead and implement it and update > the patch in bugzilla? http://bugzilla.mindrot.org/show_bug.cgi?id=1338 :-D Wout. From jmknoble at pobox.com Wed Jul 11 03:40:21 2007 From: jmknoble at pobox.com (Jim Knoble) Date: Tue, 10 Jul 2007 13:40:21 -0400 Subject: No password prompt for ssh from perl script In-Reply-To: <46938E79.4070609@zip.com.au> References: <46938E79.4070609@zip.com.au> Message-ID: <20070710174020.GY30492@crawfish.ais.com> Circa 2007-07-10 09:49 dixit Darren Tucker: : Aftab Ahamed wrote: : > I need some help from you guys for one issue I am facing with my script. : > [...] : > But when we try to login to localhost using ssh from perl script using : > pseudo terminal, I am getting the following without any password prompt. : > : > Permission denied, please try again. : > Permission denied, please try again. : > Permission denied (publickey,password,keyboard-interactive) : : You can also set the SSH_ASKPASS environment variable to point to a : program that supplies the password and do away with the pty. Unless things have changed recently, you'll also need to detach from the controlling terminal using setsid(2) or an equivalent. Under Linux, the setsid(1) command can do this for you: setsid ssh someone at somwhere ... You may also need to ensure the DISPLAY environment variable is set. Good luck. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: 6F39C2CC >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 5024:D578:7CF4:5660:7269::F6F3:B919:9307:6F39:C2CC) +----------------------------------------------------------------------+ |[L]iberty, as we all know, cannot flourish in a country that is perma-| | nently on a war footing, or even a near-war footing. --Aldous Huxley| +----------------------------------------------------------------------+ From hiaftab at hotmail.com Wed Jul 11 17:28:15 2007 From: hiaftab at hotmail.com (Aftab Ahamed) Date: Wed, 11 Jul 2007 07:28:15 +0000 Subject: No password prompt for ssh from perl script In-Reply-To: <469383C4.1040300@zip.com.au> Message-ID: It didnt work out. I have given below the permissions for /dev/pty* and /dev/tty*. I have also given logs from syslog which I forgot to give in my earlier email. Its still getting same error. Any idea? ****************** SYSLOG *********************************************** Jul 11 03:22:10 auth|security:info sshd[667870]: Failed password for <> from 127.0.0.1 port 62545 ssh2 Jul 11 03:22:10 auth|security:info syslog: ssh: failed login attempt for <>from loopback Jul 11 03:22:10 auth|security:info sshd[667870]: Failed password for <> from 127.0.0.1 port 62545 ssh2 Jul 11 03:22:10 rscase03 auth|security:info syslog: ssh: failed login attempt for <> from loopback Jul 11 03:22:10 rscase03 auth|security:info sshd[667870]: Failed password for <> from 127.0.0.1 port 62545 ssh2 Jul 11 03:22:10 rscase03 auth|security:info syslog: ssh: failed login attempt for <> from loopback ****************************************************************************** [/dev]$ ls -l /dev/tty* crw-rw-rw- 1 root system 1, 0 Jul 11 02:23 /dev/tty crw-rw-rw- 1 root system 22, 0 Feb 15 13:16 /dev/ttyp0 crw-rw-rw- 1 root system 22, 1 Feb 15 13:16 /dev/ttyp1 crw-rw-rw- 1 root system 22, 2 Feb 15 13:16 /dev/ttyp2 crw-rw-rw- 1 root system 22, 3 Feb 15 13:16 /dev/ttyp3 crw-rw-rw- 1 root system 22, 4 Feb 15 13:16 /dev/ttyp4 crw-rw-rw- 1 root system 22, 5 Feb 15 13:16 /dev/ttyp5 crw-rw-rw- 1 root system 22, 6 Feb 15 13:16 /dev/ttyp6 crw-rw-rw- 1 root system 22, 7 Feb 15 13:16 /dev/ttyp7 crw-rw-rw- 1 root system 22, 8 Feb 15 13:16 /dev/ttyp8 crw-rw-rw- 1 root system 22, 9 Feb 15 13:16 /dev/ttyp9 crw-rw-rw- 1 root system 22, 10 Feb 15 13:16 /dev/ttypa crw-rw-rw- 1 root system 22, 11 Feb 15 13:16 /dev/ttypb crw-rw-rw- 1 root system 22, 12 Feb 15 13:16 /dev/ttypc crw-rw-rw- 1 root system 22, 13 Feb 15 13:16 /dev/ttypd crw-rw-rw- 1 root system 22, 14 Feb 15 13:16 /dev/ttype crw-rw-rw- 1 root system 22, 15 Feb 15 13:16 /dev/ttypf [/dev]$ ls -l /dev/pty* crw-rw-rw- 1 root system 21, 0 Feb 15 13:16 /dev/ptyp0 crw-rw-rw- 1 root system 21, 1 Feb 15 13:16 /dev/ptyp1 crw-rw-rw- 1 root system 21, 2 Feb 15 13:16 /dev/ptyp2 crw-rw-rw- 1 root system 21, 3 Feb 15 13:16 /dev/ptyp3 crw-rw-rw- 1 root system 21, 4 Feb 15 13:16 /dev/ptyp4 crw-rw-rw- 1 root system 21, 5 Feb 15 13:16 /dev/ptyp5 crw-rw-rw- 1 root system 21, 6 Feb 15 13:16 /dev/ptyp6 crw-rw-rw- 1 root system 21, 7 Feb 15 13:16 /dev/ptyp7 crw-rw-rw- 1 root system 21, 8 Feb 15 13:16 /dev/ptyp8 crw-rw-rw- 1 root system 21, 9 Feb 15 13:16 /dev/ptyp9 crw-rw-rw- 1 root system 21, 10 Feb 15 13:16 /dev/ptypa crw-rw-rw- 1 root system 21, 11 Feb 15 13:16 /dev/ptypb crw-rw-rw- 1 root system 21, 12 Feb 15 13:16 /dev/ptypc crw-rw-rw- 1 root system 21, 13 Feb 15 13:16 /dev/ptypd crw-rw-rw- 1 root system 21, 14 Feb 15 13:16 /dev/ptype crw-rw-rw- 1 root system 21, 15 Feb 15 13:16 /dev/ptypf Thanks Aftab From: Darren Tucker To: Aftab Ahamed CC: openssh-unix-dev at mindrot.org Subject: Re: No password prompt for ssh from perl script Date: Tue, 10 Jul 2007 23:04:04 +1000 MIME-Version: 1.0 Received: from mailout1.pacific.net.au ([61.8.2.210]) by bay0-mc1-f13.bay0.hotmail.com with Microsoft SMTPSVC(6.0.3790.2668); Tue, 10 Jul 2007 06:04:06 -0700 Received: from mail0.dtucker.net (203-217-17-96.perm.iinet.net.au [203.217.17.96])by mailout1.pacific.net.au (Postfix) with ESMTP id B25143841AFfor ; Tue, 10 Jul 2007 23:04:05 +1000 (EST) Received: from chimera.dtucker.net (localhost.localdomain [127.0.0.1])by mail0.dtucker.net (8.13.8/8.13.4) with ESMTP id l6AD44ZR001379;Tue, 10 Jul 2007 23:04:05 +1000 X-Message-Info: LsUYwwHHNt3igTN6QK+bgGhKoXI0JcsPCdALPmEXtiLrSWr30Qr515ad6S6+M01K User-Agent: Thunderbird 2.0.0.0 (X11/20070620) References: Return-Path: dtucker at zip.com.au X-OriginalArrivalTime: 10 Jul 2007 13:04:06.0774 (UTC) FILETIME=[CC3C8160:01C7C2F2] Aftab Ahamed wrote: >Hi, >I need some help from you guys for one issue I am facing with my script. >While logging into localhost using ssh from command prompt it works: > It works from command prompt --> ssh loginid at localhost > >But when we try to login to localhost using ssh from perl script using >pseudo terminal, I am getting the following without any password prompt. > >We are getting following instead of password prompt: >Permission denied, please try again. >Permission denied, please try again. >Permission denied (publickey,password,keyboard-interactive) > >We are using OpenSSH in AIX 5.3 and Perl 5.8.2 > >Any one has any idea on this why this issue might have occured. If anyone >wants to see the code, I can send it. It would be great help if anyone can >help in this regard This can happen if /dev/tty has the wrong permissions (should be mode 666). -- 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. _________________________________________________________________ Spice up your IM conversations. New, colorful and animated emoticons. Get chatting! http://server1.msn.co.in/SP05/emoticons/ From dtucker at zip.com.au Wed Jul 11 22:11:19 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 11 Jul 2007 22:11:19 +1000 Subject: No password prompt for ssh from perl script In-Reply-To: References: <469383C4.1040300@zip.com.au> Message-ID: <20070711121119.GA25054@gate.dtucker.net> On Wed, Jul 11, 2007 at 07:28:15AM +0000, Aftab Ahamed wrote: > It didnt work out. I have given below the permissions for /dev/pty* and > /dev/tty*. I have also given logs from syslog which I forgot to give in my > earlier email. Its still getting same error. Any idea? The only other suggesting I have is to run ssh in that environment with full debugging ("ssh -vvv ...") and see if the output sheds any light on what's going on. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From stuge-openssh-unix-dev at cdy.org Fri Jul 13 04:31:33 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 12 Jul 2007 20:31:33 +0200 Subject: The Camellia block cipher for OpenSSH 4.6p1. In-Reply-To: <20070709192651.22d48a9c.yanagisawa@csg.is.titech.ac.jp> References: <20070709192651.22d48a9c.yanagisawa@csg.is.titech.ac.jp> Message-ID: <20070712183133.19444.qmail@cdy.org> Hello Yoshisato, On Mon, Jul 09, 2007 at 07:26:51PM +0900, Yoshisato YANAGISAWA wrote: > I implemented a patch for porting the Camellia block cipher to > one of the OpenSSH-usable cipher. Camellia is one of the approved > encryption methods of NESSIE and has specified in several RFCs. > I put the patch at: > http://www.is.titech.ac.jp/~yanagis0/text/camellia/openssh-4.6p1-0.2.patch > in http://www.is.titech.ac.jp/~yanagis0/text/camellia-e.html. I must say I find it truly inspiring to see this open attitude in national organizations and big companies. :) > I hope you will enjoy this patch and OpenSSH will use it. Since there was not much immediate interest I would suggest opening a bug in the OpenSSH bug tracker at https://bugzilla.mindrot.org/ so that the patch is not forgotten in the mailing list archives. Actually, it may be more appropriate to get a patch into the upstream OpenBSD OpenSSH bug tracker so that not only -portable gets the new cipher. The cipher seems to be license-compatible with OpenBSD, right? Thank you! //Peter From harald at CoWare.com Fri Jul 13 17:17:47 2007 From: harald at CoWare.com (Harald Dunkel) Date: Fri, 13 Jul 2007 09:17:47 +0200 Subject: Cygwin: store authorized_keys in /etc/ssh/user/authorized_keys? Message-ID: <4697271B.8030900@coware.com> Hi folks, If I try to login on a Cygwin host via ssh, then my .ssh on a network drive is unaccessible until I login. I have to enter my password, even if my authorized_keys would allow me to login without. This is fatal, since it forces me to use an interactive session for working on a Windows host. Unusable for automatic builds and tests managed from a central machine, for example. There is no such restriction if I create local accounts on every Cygwin PC, using local disks for $HOME/.ssh. Highly inefficient and troublesome, I have to rsync my data again and again, but it works. Would it be possible to extend auth2-pubkey.c to look in /cde/ssh/$LOGNAME/authorized_keys for the public key, in addtition to the user's .ssh directory? Of course the usual access restrictions should be checked. And it should be made a configure option for the ssh server. I don't want to change the default behavior. This would be a rough patch, just to give you an idea: --- auth2-pubkey.c~ 2006-08-05 04:39:39.000000000 +0200 +++ auth2-pubkey.c 2007-07-13 09:07:40.000000000 +0200 @@ -282,6 +282,17 @@ file = authorized_keys_file2(pw); success = user_key_allowed2(pw, key, file); xfree(file); + if (success) + return success; + +#if SUPPORT_LOCAL_AUTHORIZED_KEYS + /* look in system ssh directory for authorized keys */ + file = xmalloc(4096); + snprintf(file, 4096, "/etc/ssh/allowed_users/%s/authorized_keys", pw->pw_name); + success = user_key_allowed2(pw, key, file); + xfree(file); +#endif + return success; } Please keep me on CC:, since I am not subscibed to this list. Regards Harri -- CoWare, Inc. | Barbarus hic ergo sum, quia non Harald Dunkel | intellegor ulli. Gr?ner Weg 1 | 52070 Aachen, Germany | Ovid (+49) 241 943 788 107 | From dtucker at zip.com.au Fri Jul 13 22:10:07 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 13 Jul 2007 22:10:07 +1000 Subject: Cygwin: store authorized_keys in /etc/ssh/user/authorized_keys? In-Reply-To: <4697271B.8030900@coware.com> References: <4697271B.8030900@coware.com> Message-ID: <46976B9F.6050908@zip.com.au> Harald Dunkel wrote: > Hi folks, > > If I try to login on a Cygwin host via ssh, then my > .ssh on a network drive is unaccessible until I login. > I have to enter my password, even if my authorized_keys > would allow me to login without. This is fatal, since it > forces me to use an interactive session for working on a > Windows host. Unusable for automatic builds and tests > managed from a central machine, for example. > > There is no such restriction if I create local > accounts on every Cygwin PC, using local disks for > $HOME/.ssh. Highly inefficient and troublesome, I have > to rsync my data again and again, but it works. > > Would it be possible to extend auth2-pubkey.c to > look in /cde/ssh/$LOGNAME/authorized_keys for the > public key, in addtition to the user's .ssh directory? > Of course the usual access restrictions should be > checked. And it should be made a configure option > for the ssh server. I don't want to change the default > behavior. Any reason you don't use the existing AuthorizedKeysFile knob in sshd_config? eg "AuthorizedKeysFile /etc/ssh/keys/%u" -- 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 harald at CoWare.com Fri Jul 13 23:33:50 2007 From: harald at CoWare.com (Harald Dunkel) Date: Fri, 13 Jul 2007 15:33:50 +0200 Subject: Cygwin: store authorized_keys in /etc/ssh/user/authorized_keys? In-Reply-To: <46976B9F.6050908@zip.com.au> References: <4697271B.8030900@coware.com> <46976B9F.6050908@zip.com.au> Message-ID: <46977F3E.8050006@coware.com> Darren Tucker wrote: > Harald Dunkel wrote: >> Hi folks, >> > > Any reason you don't use the existing AuthorizedKeysFile knob in > sshd_config? eg "AuthorizedKeysFile /etc/ssh/keys/%u" > I have to admit I missed this one. I will try. Many thanx Harri From selassid at carleton.edu Sat Jul 14 08:04:51 2007 From: selassid at carleton.edu (David Selassie) Date: Fri, 13 Jul 2007 17:04:51 -0500 Subject: SFTP statfs / df patch Message-ID: <82D5AEDC-C8A7-4A1D-82AF-EF60E0035F84@carleton.edu> Here is a patch that adds to sftp a simple df command and to sftp- server a way to transfer a simple statfs structure. I followed the recommendations that were talked about in this message: http:// marc.info/?l=openssh-unix-dev&m=117193182718030 and want this feature for the same reason. Have a nice day. - David Selassie From yanagisawa at csg.is.titech.ac.jp Sat Jul 14 21:52:02 2007 From: yanagisawa at csg.is.titech.ac.jp (Yoshisato YANAGISAWA) Date: Sat, 14 Jul 2007 20:52:02 +0900 Subject: The Camellia block cipher for OpenSSH 4.6p1. In-Reply-To: <20070712183133.19444.qmail@cdy.org> References: <20070709192651.22d48a9c.yanagisawa@csg.is.titech.ac.jp> <20070712183133.19444.qmail@cdy.org> Message-ID: <4698B8E2.5050505@csg.is.titech.ac.jp> Hello Peter, Thank you for interested in my patch. On Thu, 12 Jul 2007 20:31:33 +0200 Peter Stuge wrote: > I must say I find it truly inspiring to see this open attitude > in national organizations and big companies. :) Thank you :-) > > I hope you will enjoy this patch and OpenSSH will use it. > > Since there was not much immediate interest I would suggest opening a > bug in the OpenSSH bug tracker at https://bugzilla.mindrot.org/ so > that the patch is not forgotten in the mailing list archives. I followed your suggestion and opened a bug at: https://bugzilla.mindrot.org/show_bug.cgi?id=1340 > Actually, it may be more appropriate to get a patch into the upstream > OpenBSD OpenSSH bug tracker so that not only -portable gets the new > cipher. The cipher seems to be license-compatible with OpenBSD, > right? I agreed that point but it might be a hard work to do. That is because OpenSSL in OpenBSD is now 0.9.7j, which doesn't support Camellia. However, I will try to port Camellia block cipher to OpenSSL and OpenSSH in OpenBSD. I think it is compatible since there is Camellia source code distributed under BSDL and FreeBSD-current has Camellia library inside OS kernel for IPsec. http://info.isl.ntt.co.jp/crypt/eng/camellia/engine.html http://www.emediawire.com/releases/2007/6/emw531216.htm Thank you. -- ------------------------------------------------------- Yoshisato YANAGISAWA Dept. of Mathematical and Computing Sciences, Graduate School of Information Science and Engineering, Tokyo Institute of Technology. /* If you are an *BSD user, let's join http://bsdstats.org/ */ From djm at mindrot.org Sun Jul 15 08:13:17 2007 From: djm at mindrot.org (Damien Miller) Date: Sun, 15 Jul 2007 08:13:17 +1000 (EST) Subject: The Camellia block cipher for OpenSSH 4.6p1. In-Reply-To: <4698B8E2.5050505@csg.is.titech.ac.jp> References: <20070709192651.22d48a9c.yanagisawa@csg.is.titech.ac.jp> <20070712183133.19444.qmail@cdy.org> <4698B8E2.5050505@csg.is.titech.ac.jp> Message-ID: On Sat, 14 Jul 2007, Yoshisato YANAGISAWA wrote: > I agreed that point but it might be a hard work to do. That is because > OpenSSL in OpenBSD is now 0.9.7j, which doesn't support Camellia. > However, I will try to port Camellia block cipher to OpenSSL and OpenSSH > in OpenBSD. I wouldn't worry about patching OpenBSD's OpenSSL to support Camellia, it is likely to be upgraded to a more recent version in the near future, probably after the 4.2 release. -d From yanagisawa at csg.is.titech.ac.jp Sun Jul 15 21:24:50 2007 From: yanagisawa at csg.is.titech.ac.jp (Yoshisato YANAGISAWA) Date: Sun, 15 Jul 2007 20:24:50 +0900 Subject: The Camellia block cipher for OpenSSH 4.6p1. In-Reply-To: References: <20070709192651.22d48a9c.yanagisawa@csg.is.titech.ac.jp> <20070712183133.19444.qmail@cdy.org> <4698B8E2.5050505@csg.is.titech.ac.jp> Message-ID: <20070715202450.bac928dc.yanagisawa@csg.is.titech.ac.jp> On Sun, 15 Jul 2007 08:13:17 +1000 (EST) Damien Miller wrote: > I wouldn't worry about patching OpenBSD's OpenSSL to support Camellia, > it is likely to be upgraded to a more recent version in the near > future, probably after the 4.2 release. Thank you. I was afraid that OpenBSD will not upgrade their OpenSSL version because Theo said, "i think it is time to fork OpenSSL." in 2002. http://monkey.org/openbsd/archive2/misc/200209/msg00583.html I will wait for the upgrade. Thank you in advance. -- ------------------------------------------------------- Yoshisato YANAGISAWA Dept. of Mathematical and Computing Sciences, Graduate School of Information Science and Engineering, Tokyo Institute of Technology. /* If you are an *BSD user, let's join http://bsdstats.org/ */ From 1.41421 at gmail.com Mon Jul 16 23:08:42 2007 From: 1.41421 at gmail.com (JCA) Date: Mon, 16 Jul 2007 14:08:42 +0100 Subject: Computing window sizes and adjustments Message-ID: In SSHv2, the data that consumes window space is that sent in the channel data and channel data extended messages. My question is, how is the data that consumes window space reckoned? One would have thought that it is the total length of the message itself, but the standard seems to imply that only the data contained in the data string field in the messages above is to be taken into account. That is, things like eg the padding and HMAC fields do not consume window space. What is it that OpenSSH does in this respect? From katterjohn at gmail.com Tue Jul 17 05:29:57 2007 From: katterjohn at gmail.com (Kris Katterjohn) Date: Mon, 16 Jul 2007 14:29:57 -0500 Subject: [PATCH] __func__ and __FUNCTION__ in configure script Message-ID: <469BC735.2090006@gmail.com> Hi everybody, I'm Kris. A little background: I've been contributing to Nmap for over a year, and am an SoC student for it this summer. But on to the patch.. Currently: __func__ and __FUNCTION__ are checked for in the configure script, but if one or the other doesn't exist, it is changed in defines.h. Patched: They are both still checked for in configure, but this is done in the configure script as well: 1) If __func__ exists, it's used 2) If not, but __FUNCTION__ exists, define __func__ to __FUNCTION__ 3) If neither exist, define __func__ to __FILE__ So this eliminates the need for the HAVE___func__ and HAVE___FUNCTION__ defines, the checking/modifying in defines.h, and it's all done in one spot in configure. I implemented pretty much the same thing in Nmap, and I thought it'd be helpful here as well I didn't run autoconf before I diff'd it because it probably would've made the patch huge. Please CC me on any replies, as I'm not subscribed. Thanks, Kris Katterjohn -------------- next part -------------- A non-text attachment was scrubbed... Name: func.patch Type: text/x-patch Size: 2718 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070716/94f64cac/attachment.bin From djm at mindrot.org Tue Jul 17 08:17:26 2007 From: djm at mindrot.org (Damien Miller) Date: Tue, 17 Jul 2007 08:17:26 +1000 (EST) Subject: Computing window sizes and adjustments In-Reply-To: References: Message-ID: On Mon, 16 Jul 2007, JCA wrote: > In SSHv2, the data that consumes window space is that sent in the > channel data and channel data extended messages. My question is, how > is the data that consumes window space reckoned? One would have > thought that it is the total length of the message itself, but the > standard seems to imply that only the data contained in the data > string field in the messages above is to be taken into account. That > is, things like eg the padding and HMAC fields do not consume window > space. Windows in the SSH protocol are per-channel, so it only makes sense to use the data that is sent over a channel. This does not include MAC and padding as these are protocol-level, not channel level. > What is it that OpenSSH does in this respect? OpenSSH counts the data sent over a channel against the window, not including the protocol-level framing used to send it. -d From 1.41421 at gmail.com Tue Jul 17 18:16:49 2007 From: 1.41421 at gmail.com (JCA) Date: Tue, 17 Jul 2007 09:16:49 +0100 Subject: Computing window sizes and adjustments In-Reply-To: References: Message-ID: On 7/16/07, Damien Miller wrote: > On Mon, 16 Jul 2007, JCA wrote: > > > In SSHv2, the data that consumes window space is that sent in the > > channel data and channel data extended messages. My question is, how > > is the data that consumes window space reckoned? One would have > > thought that it is the total length of the message itself, but the > > standard seems to imply that only the data contained in the data > > string field in the messages above is to be taken into account. That > > is, things like eg the padding and HMAC fields do not consume window > > space. > > Windows in the SSH protocol are per-channel, so it only makes sense to use > the data that is sent over a channel. This does not include MAC and padding > as these are protocol-level, not channel level. > > > What is it that OpenSSH does in this respect? > > OpenSSH counts the data sent over a channel against the window, not > including the protocol-level framing used to send it. Thanks for the feedback. Let me see if I can pin things down. The structure of an SSHv2 packet is laid down in section 6 of RFC 4253: uint32 packet_length byte padding_length byte[n1] payload; n1 = packet_length - padding_length - 1 byte[n2] random padding; n2 = padding_length byte[m] mac (Message Authentication Code - MAC); m = mac_length If I understand you correctly, the only field that is to be taken into account when adjusting the window size is the payload. Now only two packet types, namely, SSH_MSG_CHANNEL_DATA and SSH_MSG_CHANNEL_DATA_EXTENDED, consume window space. The structures of these packets are byte SSH_MSG_CHANNEL_DATA uint32 recipient channel string data and byte SSH_MSG_CHANNEL_EXTENDED_DATA uint32 recipient channel uint32 data_type_code string data Are all the fields in the packets to be reckoned with for window space consumption purposes, or only the data string? I mean, both the packet ID and recipient channel can be considered to be protocol data; probably the data_type_code as well; therefore, they should be left out. Is this the case? From djm at mindrot.org Tue Jul 17 19:22:01 2007 From: djm at mindrot.org (Damien Miller) Date: Tue, 17 Jul 2007 19:22:01 +1000 (EST) Subject: Computing window sizes and adjustments In-Reply-To: References: Message-ID: On Tue, 17 Jul 2007, JCA wrote: > On 7/16/07, Damien Miller wrote: > > > OpenSSH counts the data sent over a channel against the window, not > > including the protocol-level framing used to send it. > > Thanks for the feedback. Let me see if I can pin things down. > > The structure of an SSHv2 packet is laid down in section 6 of RFC 4253: > > uint32 packet_length > byte padding_length > byte[n1] payload; n1 = packet_length - padding_length - 1 > byte[n2] random padding; n2 = padding_length > byte[m] mac (Message Authentication Code - MAC); m = mac_length This isn't included > If I understand you correctly, the only field that is to be taken into > account when adjusting the window size is the payload. Now only two > packet types, namely, SSH_MSG_CHANNEL_DATA and > SSH_MSG_CHANNEL_DATA_EXTENDED, consume window space. The structures of > these packets are > > byte SSH_MSG_CHANNEL_DATA > uint32 recipient channel This isn't included > string data This is > and > > byte SSH_MSG_CHANNEL_EXTENDED_DATA > uint32 recipient channel > uint32 data_type_code This isn't included > string data This is You can see the exact calculations by grepping for "window" in channels.c -d From 1.41421 at gmail.com Wed Jul 18 01:21:24 2007 From: 1.41421 at gmail.com (JCA) Date: Tue, 17 Jul 2007 16:21:24 +0100 Subject: Deciding when to adjust the window size Message-ID: What is the algorithm adopted by OpenSSH when it comes to deciding when to adjust the size of window? I would have thought that one'd better adjust the window size as soon as it has fallen below the maximum packet size. What worries me is a potential deadlock, in which one party does not send anything, because the window is too small for its next window space-consuming packet, while the other does not adjust the window on the grounds that it reckons it size still is large enough. How are such situations avoided? From djm at mindrot.org Wed Jul 18 12:32:36 2007 From: djm at mindrot.org (Damien Miller) Date: Wed, 18 Jul 2007 12:32:36 +1000 (EST) Subject: Deciding when to adjust the window size In-Reply-To: References: Message-ID: On Tue, 17 Jul 2007, JCA wrote: > What is the algorithm adopted by OpenSSH when it comes to deciding > when to adjust the size of window? I would have thought that one'd > better adjust the window size as soon as it has fallen below the > maximum packet size. What worries me is a potential deadlock, in which > one party does not send anything, because the window is too small for > its next window space-consuming packet, while the other does not > adjust the window on the grounds that it reckons it size still is > large enough. How are such situations avoided? channels.c::channel_check_window() contains this logic. -d From vqunjian at 163.com Thu Jul 19 17:57:49 2007 From: vqunjian at 163.com (=?GBK?B?0KTIur2h?=) Date: Thu, 19 Jul 2007 15:57:49 +0800 (CST) Subject: a new patch to set the umask for the AF_UNIX socket Message-ID: <33228172.752191184831869862.JavaMail.coremail@bj163app71.163.com> Hi, Attached is a new patch, which introduces an option(SockUmask) for sshd and ssh and a command line argument(-m) for ssh-agent. Those options are used to specify the umask for the AF_UNIX socket. Currently, ssh-agent, ssh and sshd use the system umask for the AF_UNIX socket, however, this is lack of flexibility in some cases for security considerations, that's why I provide the patch. Would you please take a look and see if it could be used in the next openssh release? Thanks Xiao -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openssh4.5_sock_umask.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070719/5d9a67b1/attachment.ksh From wmertens at cisco.com Mon Jul 23 13:22:50 2007 From: wmertens at cisco.com (Wout Mertens) Date: Mon, 23 Jul 2007 05:22:50 +0200 Subject: ControlPersist + IdleTimeout Message-ID: Hi there, So I created a patch that makes ssh behave more like sudo. You connect to a host typing your password, you quit, you connect again and you are let in immediately. If you wait for too long you have to type your password again. It works if you have a ControlPath, ControlMaster is auto, ControlPersist is yes and ControlTimeout is for example 5m. This will make a master when you quit your shell, and it will exit if no data has passed through for 5 minutes. You can find it here: https://bugzilla.mindrot.org/show_bug.cgi?id=1330#c5 It works really well as long as you exit by closing your shell. If you exit by ~. or closing your terminal window, the daemonizing code doesn't run. Can someone please explain to me how client_channel_closed() is called upon normal termination? I have a hard time gleaning it from the code. I'm thinking to let the connection be daemonized when quit_pending is true in the client loop, but I'm also not sure if that catches all non-fatal exits that happen to ssh. Any comments? Note that in the bug Damien proposes to fork the master first, before running the real session. However, that means that if creating a master connection fails, the whole ssh connection fails and it is no longer a drop-in script speedup. I also just realized that I want the master connection to idle for 5 minutes, but wait forever when a client is connected. That means setting the timeout to 0 when a client connects and resetting it to the control_timeout when the last client leaves. Right? Thanks for any comments and pointers, Wout. From jiayingz at google.com Wed Jul 25 08:33:09 2007 From: jiayingz at google.com (Jiaying Zhang) Date: Tue, 24 Jul 2007 15:33:09 -0700 Subject: ssh client does not timeout if the network fails after ssh_connect but before ssh_exchange_identification, even with Alive options set Message-ID: <5df78e1d0707241533l211ca11awa554acf229802acc@mail.gmail.com> Hello, I am testing ssh with occasional network disconnection between server and client during these days. I found ssh sometimes hangs if the disconnection happens after the connection is established but before ssh_exchange_identification completes. The ssh configuration files show that both client and server alive options are set. In /etc/ssh/ssh_config: # Send keepalive messages to the server. Disconnect after 90 seconds. ServerAliveInterval 30 ServerAliveCountMax 3 In /etc/ssh/sshd_config: # ClientAlive is more flexible and secure than TCPKeepAlive. (ssh2) # Send an alive messages every 30 seconds, and disconnect after 90 seconds. ClientAliveInterval 30 ClientAliveCountMax 3 The ssh client kept hanging even after the network was resumed. It finally timed out after about 2 hours because the tcp_keepalive_time is set as 2 hours in sysctl. I looked at the ssh code downloaded from your website and found the Alive options are only used to setup timeout after ssh_session starts. So my question is why we do not start monitoring the liveness of ssh server right after a connection is established. It is annoying when an application relies on ssh to do periodic work but an occasional network failure causes the application to miss several service circles due to ssh hanging. Thanks a lot! Jiaying From jan.alphenaar at bearingpoint.com Wed Jul 25 18:12:16 2007 From: jan.alphenaar at bearingpoint.com (Alphenaar, Jan) Date: Wed, 25 Jul 2007 09:12:16 +0100 Subject: No subject Message-ID: <02A523FAF108FF4DB3713879E1DDAE554FC3C3@becxoex04.corp.kpmgconsulting.com> *************************************************************************************************** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *************************************************************************************************** BearingPoint B.V. statutaire zetel: 's-Gravenhage Dossiernummer: 30142784 Kamer van Koophandel Amsterdam From jan.alphenaar at bearingpoint.com Wed Jul 25 18:27:46 2007 From: jan.alphenaar at bearingpoint.com (Alphenaar, Jan) Date: Wed, 25 Jul 2007 09:27:46 +0100 Subject: openssh ssh_askpass problem / question Message-ID: <02A523FAF108FF4DB3713879E1DDAE554FC3C8@becxoex04.corp.kpmgconsulting.com> Dear list, I have set up SSH with the SSH_ASKPASS and DISPLAY variable set. Everything works perfectly. When ssh is used without a tty, the askpass program is executed, providing the password. But when I change the location of the askpass program, so it contains a space in the absolute path name (for example "c:\My Documents\askpass") the askpass program cannot be found. I get a "c:\My is not recognized as an internal or external command, operable program or batch file" error message back. This indicates that openssh executes the askpass program with an absolute path, without decently quoting the string. I am using the cygwin implementation of openssh, currently version 4.6p1. If anybody can give me some help or directions with this issue, I would greatly appreciate it. Warm regards, Jan *************************************************************************************************** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *************************************************************************************************** BearingPoint B.V. statutaire zetel: 's-Gravenhage Dossiernummer: 30142784 Kamer van Koophandel Amsterdam From stuge-openssh-unix-dev at cdy.org Wed Jul 25 22:42:06 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Wed, 25 Jul 2007 14:42:06 +0200 Subject: openssh ssh_askpass problem / question In-Reply-To: <02A523FAF108FF4DB3713879E1DDAE554FC3C8@becxoex04.corp.kpmgconsulting.com> References: <02A523FAF108FF4DB3713879E1DDAE554FC3C8@becxoex04.corp.kpmgconsulting.com> Message-ID: <20070725124207.1825.qmail@cdy.org> On Wed, Jul 25, 2007 at 09:27:46AM +0100, Alphenaar, Jan wrote: > This indicates that openssh executes the askpass program with an > absolute path, without decently quoting the string. I am using the > cygwin implementation of openssh, currently version 4.6p1. Try adding quotes to SSH_ASKPASS yourself. I don't know if this is a problem in OpenSSH or Cygwin. //Peter From jan.alphenaar at bearingpoint.com Wed Jul 25 22:52:19 2007 From: jan.alphenaar at bearingpoint.com (Alphenaar, Jan) Date: Wed, 25 Jul 2007 13:52:19 +0100 Subject: openssh ssh_askpass problem / question In-Reply-To: <20070725124207.1825.qmail@cdy.org> Message-ID: <02A523FAF108FF4DB3713879E1DDAE554FC3D6@becxoex04.corp.kpmgconsulting.com> Peter, I have tried both options SSH_ASKPASS= SSH_ASKPASS="" But each of them is giving me the same error message, as indicated in my original email. Warm Regards, Jan -----Original Message----- From: openssh-unix-dev-bounces+jan.alphenaar=bearingpoint.com at mindrot.org [mailto:openssh-unix-dev-bounces+jan.alphenaar=bearingpoint.com at mindrot. org] On Behalf Of Peter Stuge Sent: Wednesday, July 25, 2007 2:42 PM To: openssh-unix-dev at mindrot.org Subject: Re: openssh ssh_askpass problem / question On Wed, Jul 25, 2007 at 09:27:46AM +0100, Alphenaar, Jan wrote: > This indicates that openssh executes the askpass program with an > absolute path, without decently quoting the string. I am using the > cygwin implementation of openssh, currently version 4.6p1. Try adding quotes to SSH_ASKPASS yourself. I don't know if this is a problem in OpenSSH or Cygwin. //Peter _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev *************************************************************************************************** The information in this email is confidential and may be legally privileged. Access to this email by anyone other than the intended addressee is unauthorized. If you are not the intended recipient of this message, any review, disclosure, copying, distribution, retention, or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you are not the intended recipient, please reply to or forward a copy of this message to the sender and delete the message, any attachments, and any copies thereof from your system. *************************************************************************************************** BearingPoint B.V. statutaire zetel: 's-Gravenhage Dossiernummer: 30142784 Kamer van Koophandel Amsterdam From maniac.nl at gmail.com Wed Jul 25 22:56:40 2007 From: maniac.nl at gmail.com (Mark Janssen) Date: Wed, 25 Jul 2007 14:56:40 +0200 Subject: openssh ssh_askpass problem / question In-Reply-To: <02A523FAF108FF4DB3713879E1DDAE554FC3D6@becxoex04.corp.kpmgconsulting.com> References: <20070725124207.1825.qmail@cdy.org> <02A523FAF108FF4DB3713879E1DDAE554FC3D6@becxoex04.corp.kpmgconsulting.com> Message-ID: <531e3e4c0707250556x33ed4bb1t1fdfb23d7ef646b7@mail.gmail.com> On 7/25/07, Alphenaar, Jan wrote: > SSH_ASKPASS= > SSH_ASKPASS="" > > But each of them is giving me the same error message, as indicated in my > original email. Try either escaping the space '\ ' or using the short-name (dos-name) for the directory Usually something involving ~1 "progra~1" etc... -- Mark Janssen -- maniac(at)maniac.nl -- pgp: 0x357D2178 | ,''`. | Unix / Linux Open-Source and Internet Consultant @ Snow.nl | : :' : | Maniac.nl MarkJanssen.nl NerdNet.nl Unix.nl | `. `' | Skype: markmjanssen ICQ: 129696007 irc: FooBar on undernet | `- | From jiayingz at google.com Thu Jul 26 08:12:24 2007 From: jiayingz at google.com (Jiaying Zhang) Date: Wed, 25 Jul 2007 15:12:24 -0700 Subject: ssh client does not timeout if the network fails after ssh_connect but before ssh_exchange_identification, even with Alive options set In-Reply-To: <5df78e1d0707241533l211ca11awa554acf229802acc@mail.gmail.com> References: <5df78e1d0707241533l211ca11awa554acf229802acc@mail.gmail.com> Message-ID: <5df78e1d0707251512w16f34237rd134d21ac6a6af44@mail.gmail.com> Hello again, Here is the patch I came up with to prevent the hanging in ssh_exchange_identification. I tested it a little bit and it seems to have solved the problem. Could anyone help to have a look at the patch? Thanks a lot! --- sshconnect.c~old 2007-07-25 10:44:26.000000000 -0700 +++ sshconnect.c 2007-07-25 14:45:57.000000000 -0700 @@ -404,9 +404,26 @@ ssh_exchange_identification(void) int minor1 = PROTOCOL_MINOR_1; u_int i, n; + if (options.server_alive_interval) { + fd_set rfds; + struct timeval timeo = { .tv_usec=0 }; + int read_timeouts, ret; + + FD_SET(connection_in, &rfds); + for (read_timeouts = 0;;) { + timeo.tv_sec = options.server_alive_interval; + ret = select(connection_in+1, &rfds, NULL, NULL, &timeo); + if (ret < 0) { + fatal("ssh_exchange_identification: select read error: %.100s", strerror(errno)); + } else if (ret == 0) { + if (++read_timeouts >= options.server_alive_count_max) + fatal("ssh_exchange_identification: Timeout, server not responding"); + } else + break; + } + + } /* Read other side's version identification. */ - struct timeval timeo = { .tv_sec=10, .tv_usec=0 }; - setsockopt(connection_in, SOL_SOCKET, SO_SNDTIMEO, &timeo, sizeof(timeo)); for (n = 0;;) { for (i = 0; i < sizeof(buf) - 1; i++) { size_t len = atomicio(read, connection_in, &buf[i], 1); @@ -490,6 +507,25 @@ ssh_exchange_identification(void) compat20 ? PROTOCOL_MAJOR_2 : PROTOCOL_MAJOR_1, compat20 ? PROTOCOL_MINOR_2 : minor1, SSH_VERSION); + if (options.server_alive_interval) { + fd_set wfds; + struct timeval timeo = { .tv_usec=0 }; + int write_timeouts, ret; + + FD_SET(connection_out, &wfds); + for (write_timeouts = 0;;) { + timeo.tv_sec = options.server_alive_interval; + ret = select(connection_out+1, NULL, &wfds, NULL, &timeo); + if (ret < 0) { + fatal("ssh_exchange_identification: select write error: %.100s", strerror(errno)); + } else if (ret == 0) { + if (++write_timeouts >= options.server_alive_count_max) + fatal("ssh_exchange_identification: Timeout, server not responding"); + } else + break; + } + + } if (atomicio(vwrite, connection_out, buf, strlen(buf)) != strlen(buf)) fatal("write: %.100s", strerror(errno)); client_version_string = xstrdup(buf); Jiaying On 7/24/07, Jiaying Zhang wrote: > > Hello, > > I am testing ssh with occasional network disconnection between server and > client during these days. I found ssh sometimes hangs if the disconnection > happens after the connection is established but before > ssh_exchange_identification completes. The ssh configuration files show that > both client and server alive options are set. > In /etc/ssh/ssh_config: > # Send keepalive messages to the server. Disconnect after 90 seconds. > ServerAliveInterval 30 > ServerAliveCountMax 3 > In /etc/ssh/sshd_config: > # ClientAlive is more flexible and secure than TCPKeepAlive. (ssh2) > # Send an alive messages every 30 seconds, and disconnect after 90 > seconds. > ClientAliveInterval 30 > ClientAliveCountMax 3 > > The ssh client kept hanging even after the network was resumed. It finally > timed out after about 2 hours because the tcp_keepalive_time is set as 2 > hours in sysctl. > I looked at the ssh code downloaded from your website and found the Alive > options are only used to setup timeout after ssh_session starts. So my > question is why we do not start monitoring the liveness of ssh server right > after a connection is established. It is annoying when an application relies > on ssh to do periodic work but an occasional network failure causes the > application to miss several service circles due to ssh hanging. > > Thanks a lot! > > Jiaying > > From valerio.balbi at gmail.com Thu Jul 26 19:25:38 2007 From: valerio.balbi at gmail.com (valerio balbi) Date: Thu, 26 Jul 2007 11:25:38 +0200 Subject: [PATCH] triggering SFTP process on close Message-ID: this is the stable revision of the previous patch for trigger an action using SFTP for detail http://www.imolug.org/index.php?option=com_openwiki&Itemid=5&id=wiki:opensshpvb265 -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-4.6p1-pvb265Trigger.patch Type: text/x-patch Size: 26911 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070726/3f4f62b9/attachment-0001.bin From dan at D00M.lightwave.net.ru Thu Jul 26 21:52:11 2007 From: dan at D00M.lightwave.net.ru (Dan Yefimov) Date: Thu, 26 Jul 2007 15:52:11 +0400 (MSD) Subject: ssh client does not timeout if the network fails after ssh_connect but before ssh_exchange_identification, even with Alive options set In-Reply-To: <5df78e1d0707251512w16f34237rd134d21ac6a6af44@mail.gmail.com> Message-ID: On Wed, 25 Jul 2007, Jiaying Zhang wrote: > Hello again, > > Here is the patch I came up with to prevent the hanging in > ssh_exchange_identification. I tested it a little bit and it seems to have > solved the problem. Could anyone help to have a look at the patch? Thanks a > lot! > > --- sshconnect.c~old 2007-07-25 10:44:26.000000000 -0700 > +++ sshconnect.c 2007-07-25 14:45:57.000000000 -0700 > @@ -404,9 +404,26 @@ ssh_exchange_identification(void) > int minor1 = PROTOCOL_MINOR_1; > u_int i, n; > > + if (options.server_alive_interval) { > + fd_set rfds; > + struct timeval timeo = { .tv_usec=0 }; > + int read_timeouts, ret; > + > + FD_SET(connection_in, &rfds); > + for (read_timeouts = 0;;) { > + timeo.tv_sec = options.server_alive_interval; > + ret = select(connection_in+1, &rfds, NULL, NULL, > &timeo); > + if (ret < 0) { I think you should handle errno == EINTR case here restarting select(), otherwise any arriving signal would make ssh fail here. > + fatal("ssh_exchange_identification: select > read error: %.100s", strerror(errno)); > + } else if (ret == 0) { > + if (++read_timeouts >= > options.server_alive_count_max) > + fatal("ssh_exchange_identification: > Timeout, server not responding"); > + } else > + break; > + } > + > + } > /* Read other side's version identification. */ > - struct timeval timeo = { .tv_sec=10, .tv_usec=0 }; > - setsockopt(connection_in, SOL_SOCKET, SO_SNDTIMEO, &timeo, > sizeof(timeo)); > for (n = 0;;) { > for (i = 0; i < sizeof(buf) - 1; i++) { > size_t len = atomicio(read, connection_in, &buf[i], > 1); > @@ -490,6 +507,25 @@ ssh_exchange_identification(void) > compat20 ? PROTOCOL_MAJOR_2 : PROTOCOL_MAJOR_1, > compat20 ? PROTOCOL_MINOR_2 : minor1, > SSH_VERSION); > + if (options.server_alive_interval) { > + fd_set wfds; > + struct timeval timeo = { .tv_usec=0 }; > + int write_timeouts, ret; > + > + FD_SET(connection_out, &wfds); > + for (write_timeouts = 0;;) { > + timeo.tv_sec = options.server_alive_interval; > + ret = select(connection_out+1, NULL, &wfds, NULL, > &timeo); > + if (ret < 0) { The same notice as above here. > + fatal("ssh_exchange_identification: select > write error: %.100s", strerror(errno)); > + } else if (ret == 0) { > + if (++write_timeouts >= > options.server_alive_count_max) > + fatal("ssh_exchange_identification: > Timeout, server not responding"); > + } else > + break; > + } > + > + } > if (atomicio(vwrite, connection_out, buf, strlen(buf)) != > strlen(buf)) > fatal("write: %.100s", strerror(errno)); > client_version_string = xstrdup(buf); > -- Sincerely Your, Dan. From jiayingz at google.com Fri Jul 27 04:56:34 2007 From: jiayingz at google.com (Jiaying Zhang) Date: Thu, 26 Jul 2007 11:56:34 -0700 Subject: ssh client does not timeout if the network fails after ssh_connect but before ssh_exchange_identification, even with Alive options set In-Reply-To: References: <5df78e1d0707251512w16f34237rd134d21ac6a6af44@mail.gmail.com> Message-ID: <5df78e1d0707261156j43887635h687a456f832ea3ce@mail.gmail.com> Hi Dan, Thanks for looking at the patch. I changed the code as you suggested. The new patch is attached below. I have a little concern about restarting select() in case of EINTR, because it can postpone timeout. It may cause some problem if people schedule their jobs based on the expected ssh timeout. I also noticed that in server_alive_check() function, we check if (++server_alive_timeouts > options.server_alive_count_max). Should it be >=? According to the comment in ssh_config, if ServerAliveInterval equals to 30 and ServerAliveCountMax equals to 3, ssh disconnects after 90 seconds. But with the current server_alive_check, we actually disconnects after 120 seconds. diff -puN sshconnect.c~old sshconnect.c --- sshconnect.c~old 2007-07-25 16:59:36.000000000 -0700 +++ sshconnect.c 2007-07-26 11:46:48.000000000 -0700 @@ -404,6 +404,28 @@ ssh_exchange_identification(void) int minor1 = PROTOCOL_MINOR_1; u_int i, n; + if (options.server_alive_interval) { + fd_set rfds; + struct timeval timeo; + int read_timeouts, ret; + + FD_SET(connection_in, &rfds); + for (read_timeouts = 0;;) { + timeo.tv_sec = options.server_alive_interval; + timeo.tv_usec = 0; + ret = select(connection_in+1, &rfds, NULL, NULL, &timeo); + if (ret < 0) { + if (errno == EINTR) + continue; + fatal("ssh_exchange_identification: select read error: %.100s", strerror(errno)); + } else if (ret == 0) { + if (++read_timeouts >= options.server_alive_count_max) + fatal("ssh_exchange_identification: Timeout, server not responding"); + } else + break; + } + + } /* Read other side's version identification. */ for (n = 0;;) { for (i = 0; i < sizeof(buf) - 1; i++) { @@ -488,6 +510,27 @@ ssh_exchange_identification(void) compat20 ? PROTOCOL_MAJOR_2 : PROTOCOL_MAJOR_1, compat20 ? PROTOCOL_MINOR_2 : minor1, SSH_VERSION); + if (options.server_alive_interval) { + fd_set wfds; + struct timeval timeo = { .tv_usec=0 }; + int write_timeouts, ret; + + FD_SET(connection_out, &wfds); + for (write_timeouts = 0;;) { + timeo.tv_sec = options.server_alive_interval; + ret = select(connection_out+1, NULL, &wfds, NULL, &timeo); + if (ret < 0) { + if (errno == EINTR) + continue; + fatal("ssh_exchange_identification: select write error: %.100s", strerror(errno)); + } else if (ret == 0) { + if (++write_timeouts >= options.server_alive_count_max) + fatal("ssh_exchange_identification: Timeout, server not responding"); + } else + break; + } + + } if (atomicio(vwrite, connection_out, buf, strlen(buf)) != strlen(buf)) fatal("write: %.100s", strerror(errno)); client_version_string = xstrdup(buf); Jiaying On 7/26/07, Dan Yefimov wrote: > > On Wed, 25 Jul 2007, Jiaying Zhang wrote: > > > Hello again, > > > > Here is the patch I came up with to prevent the hanging in > > ssh_exchange_identification. I tested it a little bit and it seems to > have > > solved the problem. Could anyone help to have a look at the patch? > Thanks a > > lot! > > > > --- sshconnect.c~old 2007-07-25 10:44:26.000000000 -0700 > > +++ sshconnect.c 2007-07-25 14:45:57.000000000 -0700 > > @@ -404,9 +404,26 @@ ssh_exchange_identification(void) > > int minor1 = PROTOCOL_MINOR_1; > > u_int i, n; > > > > + if (options.server_alive_interval) { > > + fd_set rfds; > > + struct timeval timeo = { .tv_usec=0 }; > > + int read_timeouts, ret; > > + > > + FD_SET(connection_in, &rfds); > > + for (read_timeouts = 0;;) { > > + timeo.tv_sec = options.server_alive_interval; > > + ret = select(connection_in+1, &rfds, NULL, NULL, > > &timeo); > > + if (ret < 0) { > > I think you should handle errno == EINTR case here restarting select(), > otherwise any arriving signal would make ssh fail here. > > > + fatal("ssh_exchange_identification: > select > > read error: %.100s", strerror(errno)); > > + } else if (ret == 0) { > > + if (++read_timeouts >= > > options.server_alive_count_max) > > + > fatal("ssh_exchange_identification: > > Timeout, server not responding"); > > + } else > > + break; > > + } > > + > > + } > > /* Read other side's version identification. */ > > - struct timeval timeo = { .tv_sec=10, .tv_usec=0 }; > > - setsockopt(connection_in, SOL_SOCKET, SO_SNDTIMEO, &timeo, > > sizeof(timeo)); > > for (n = 0;;) { > > for (i = 0; i < sizeof(buf) - 1; i++) { > > size_t len = atomicio(read, connection_in, > &buf[i], > > 1); > > @@ -490,6 +507,25 @@ ssh_exchange_identification(void) > > compat20 ? PROTOCOL_MAJOR_2 : PROTOCOL_MAJOR_1, > > compat20 ? PROTOCOL_MINOR_2 : minor1, > > SSH_VERSION); > > + if (options.server_alive_interval) { > > + fd_set wfds; > > + struct timeval timeo = { .tv_usec=0 }; > > + int write_timeouts, ret; > > + > > + FD_SET(connection_out, &wfds); > > + for (write_timeouts = 0;;) { > > + timeo.tv_sec = options.server_alive_interval; > > + ret = select(connection_out+1, NULL, &wfds, > NULL, > > &timeo); > > + if (ret < 0) { > > The same notice as above here. > > > + fatal("ssh_exchange_identification: > select > > write error: %.100s", strerror(errno)); > > + } else if (ret == 0) { > > + if (++write_timeouts >= > > options.server_alive_count_max) > > + > fatal("ssh_exchange_identification: > > Timeout, server not responding"); > > + } else > > + break; > > + } > > + > > + } > > if (atomicio(vwrite, connection_out, buf, strlen(buf)) != > > strlen(buf)) > > fatal("write: %.100s", strerror(errno)); > > client_version_string = xstrdup(buf); > > > -- > > Sincerely Your, Dan. > > From rapier at psc.edu Fri Jul 27 07:34:06 2007 From: rapier at psc.edu (Chris Rapier) Date: Thu, 26 Jul 2007 17:34:06 -0400 Subject: Channel Handling Patch Message-ID: <46A9134E.8050807@psc.edu> The current code for channel.c creates an array of Channel structs (initially set to NULL) which is then iterated through, in full, every time a channel needs to be dealt with. If only one channel is in use, which is relatively common, the code still loops through the entire array. This patch creates a linked list of pointers to these structs and the code steps through the linked list. Since the linked list is only as long as the number of active channels the amount of time spent looping is reduced - in some cases considerably. I've included the first 15 lines of an oprofile report comparing multiple data transfers using the standard code and the patched code as follows. Standard: samples cum. samples % cum. % symbol name 15360 15360 11.4140 11.4140 client_loop 13277 28637 9.8661 21.2801 packet_send2_wrapped 11017 39654 8.1867 29.4668 channel_output_poll 8070 47724 5.9968 35.4635 buffer_append_space 7914 55638 5.8809 41.3444 channel_handler 5970 61608 4.4363 45.7807 arc4random 5346 66954 3.9726 49.7533 channel_pre_open 5159 72113 3.8336 53.5869 packet_read_poll_seqnr 4253 76366 3.1604 56.7473 channel_post_open 3864 80230 2.8713 59.6186 cipher_crypt 3849 84079 2.8602 62.4788 buffer_len 3541 87620 2.6313 65.1101 channel_prepare_select 3267 90887 2.4277 67.5378 client_wait_until_can... 2557 93444 1.9001 69.4379 buffer_append Patched: samples cum. samples % cum. % symbol name 15832 15832 11.4148 11.4148 client_loop 15059 30891 10.8575 22.2723 packet_send2_wrapped 9635 40526 6.9468 29.2191 channel_output_poll 7486 48012 5.3974 34.6165 buffer_append_space 7087 55099 5.1097 39.7262 arc4random 6130 61229 4.4197 44.1459 channel_post_open 5388 66617 3.8847 48.0306 channel_pre_open 4875 71492 3.5149 51.5455 packet_read_poll_seqnr 4729 76221 3.4096 54.9550 channel_handler 4394 80615 3.1681 58.1231 cipher_crypt 4179 84794 3.0130 61.1361 channel_prepare_select 4044 88838 2.9157 64.0519 buffer_len 3388 92226 2.4427 66.4946 client_wait_until_can... 2812 95038 2.0274 68.5220 buffer_append As you can see less time is spent in some of the channel routines. I am *not* sure that at this time I can prove that this translates into increased performance. Now can I prove at this time that this will remain true in all usage situations. However, my gut instinct is that in multiuser environments this may prove to have some benefit. I was hoping some people could take a look at the attached patches, try them out, see what they think, and let me know if they feel there is any merit to them. They did pass all regression tests under linux, NetBSD, and OS X. Thank you for your time. Chris Rapier -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: channels.h.diff Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070726/4c1c7d54/attachment-0002.ksh -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: channels.c.diff Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070726/4c1c7d54/attachment-0003.ksh From dan at ns15.lightwave.net.ru Fri Jul 27 08:13:38 2007 From: dan at ns15.lightwave.net.ru (Dan Yefimov) Date: Fri, 27 Jul 2007 02:13:38 +0400 (MSD) Subject: ssh client does not timeout if the network fails after ssh_connect but before ssh_exchange_identification, even with Alive options set In-Reply-To: <5df78e1d0707261156j43887635h687a456f832ea3ce@mail.gmail.com> Message-ID: On Thu, 26 Jul 2007, Jiaying Zhang wrote: > Hi Dan, > > Thanks for looking at the patch. I changed the code as you suggested. The > new patch is attached below. I have a little concern about restarting > select() in case of EINTR, because it can postpone timeout. Yes, it can, but there is nothing to do with that (except for at least Linux, which always returns remaining timeout in the select() timeout parameter). Fortunately signals are relatively rare, so the timeout deviation is IMHO not essential. There are also other possible reasons for deviation, for example sending the packet to another end while network is down. > It may cause > some problem if people schedule their jobs based on the expected ssh > timeout. I would rather believe people take some actions on ssh returning failure, rather than schedule actions after exact timeout intervals. > I also noticed that in server_alive_check() function, we check > if (++server_alive_timeouts > options.server_alive_count_max). Should it be > >=? According to the comment in ssh_config, if ServerAliveInterval equals to > 30 and ServerAliveCountMax equals to 3, ssh disconnects after 90 seconds. > But with the current server_alive_check, we actually disconnects after 120 > seconds. > Not right. Pay attention at '++server_alive_timeouts > options.server_alive_count_max' expression. server_alive_timeouts is pre-incremented there, that is it's incremented value is used while evaluating the expression, so the count begins with 1 rather than 0 there. Some notices I (unfortunately) forgot to meantion previously: > diff -puN sshconnect.c~old sshconnect.c > --- sshconnect.c~old 2007-07-25 16:59:36.000000000 -0700 > +++ sshconnect.c 2007-07-26 11:46:48.000000000 -0700 > @@ -404,6 +404,28 @@ ssh_exchange_identification(void) > int minor1 = PROTOCOL_MINOR_1; > u_int i, n; > > + if (options.server_alive_interval) { > + fd_set rfds; > + struct timeval timeo; > + int read_timeouts, ret; > + > + FD_SET(connection_in, &rfds); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (1) This should be placed inside the cycle before select() since on error (even EINTR) rfds along with timeo becomes undefined according to spec. > + for (read_timeouts = 0;;) { > + timeo.tv_sec = options.server_alive_interval; > + timeo.tv_usec = 0; > + ret = select(connection_in+1, &rfds, NULL, NULL, &timeo); > + if (ret < 0) { > + if (errno == EINTR) > + continue; > + fatal("ssh_exchange_identification: select read error: %.100s", strerror(errno)); > + } else if (ret == 0) { > + if (++read_timeouts >= options.server_alive_count_max) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ (2) Replace '>=' with '>' here because of discussion above. > + fatal("ssh_exchange_identification: Timeout, server not responding"); > + } else > + break; > + } > + > + } > /* Read other side's version identification. */ > for (n = 0;;) { > for (i = 0; i < sizeof(buf) - 1; i++) { > @@ -488,6 +510,27 @@ ssh_exchange_identification(void) > compat20 ? PROTOCOL_MAJOR_2 : PROTOCOL_MAJOR_1, > compat20 ? PROTOCOL_MINOR_2 : minor1, > SSH_VERSION); > + if (options.server_alive_interval) { > + fd_set wfds; > + struct timeval timeo = { .tv_usec=0 }; > + int write_timeouts, ret; > + > + FD_SET(connection_out, &wfds); ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The same notice here as notice (1) above. > + for (write_timeouts = 0;;) { > + timeo.tv_sec = options.server_alive_interval; > + ret = select(connection_out+1, NULL, &wfds, NULL, &timeo); > + if (ret < 0) { > + if (errno == EINTR) > + continue; > + fatal("ssh_exchange_identification: select write error: %.100s", strerror(errno)); > + } else if (ret == 0) { > + if (++write_timeouts >= options.server_alive_count_max) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ The same notice here as notice (2) above. > + fatal("ssh_exchange_identification: Timeout, server not responding"); > + } else > + break; > + } > + > + } > if (atomicio(vwrite, connection_out, buf, strlen(buf)) != strlen(buf)) > fatal("write: %.100s", strerror(errno)); > client_version_string = xstrdup(buf); > -- Sincerely Your, Dan. From dan at ns15.lightwave.net.ru Fri Jul 27 08:30:42 2007 From: dan at ns15.lightwave.net.ru (Dan Yefimov) Date: Fri, 27 Jul 2007 02:30:42 +0400 (MSD) Subject: Channel Handling Patch In-Reply-To: <46A9134E.8050807@psc.edu> Message-ID: On Thu, 26 Jul 2007, Chris Rapier wrote: May be you mean xmalloc() instead of malloc() in the channel_add_node() ? -- Sincerely Your, Dan. From jiayingz at google.com Fri Jul 27 08:32:01 2007 From: jiayingz at google.com (Jiaying Zhang) Date: Thu, 26 Jul 2007 15:32:01 -0700 Subject: ssh client does not timeout if the network fails after ssh_connect but before ssh_exchange_identification, even with Alive options set In-Reply-To: References: <5df78e1d0707261156j43887635h687a456f832ea3ce@mail.gmail.com> Message-ID: <5df78e1d0707261532g627af86em32b5db2faef48c9b@mail.gmail.com> Hi Dan, Thanks for your reply. Yes, it can, but there is nothing to do with that (except for at least > Linux, > which always returns remaining timeout in the select() timeout parameter). > Fortunately signals are relatively rare, so the timeout deviation is IMHO > not > essential. There are also other possible reasons for deviation, for > example > sending the packet to another end while network is down. Agree. I was thinking to record the start time and subtract the elapsed time when an interrupt happens. But I guess we can save that trouble since signals are rare. > > I also noticed that in server_alive_check() function, we check > > if (++server_alive_timeouts > options.server_alive_count_max). Should it > be > > >=? According to the comment in ssh_config, if ServerAliveInterval > equals to > > 30 and ServerAliveCountMax equals to 3, ssh disconnects after 90 > seconds. > > But with the current server_alive_check, we actually disconnects after > 120 > > seconds. > > > Not right. Pay attention at '++server_alive_timeouts > > options.server_alive_count_max' expression. server_alive_timeouts is > pre-incremented there, that is it's incremented value is used while > evaluating > the expression, so the count begins with 1 rather than 0 there. But still, when options.server_alive_count_max=1, we should exit after the first timeout. Some notices I (unfortunately) forgot to meantion previously: > > > diff -puN sshconnect.c~old sshconnect.c > > --- sshconnect.c~old 2007-07-25 16:59:36.000000000 -0700 > > +++ sshconnect.c 2007-07-26 11:46:48.000000000 -0700 > > @@ -404,6 +404,28 @@ ssh_exchange_identification(void) > > int minor1 = PROTOCOL_MINOR_1; > > u_int i, n; > > > > + if (options.server_alive_interval) { > > + fd_set rfds; > > + struct timeval timeo; > > + int read_timeouts, ret; > > + > > + FD_SET(connection_in, &rfds); > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > (1) This should be placed inside the cycle before select() since on error > (even > EINTR) rfds along with timeo becomes undefined according to spec. Thanks for catching this. Jiaying From dan at ns15.lightwave.net.ru Fri Jul 27 08:46:35 2007 From: dan at ns15.lightwave.net.ru (Dan Yefimov) Date: Fri, 27 Jul 2007 02:46:35 +0400 (MSD) Subject: ssh client does not timeout if the network fails after ssh_connect but before ssh_exchange_identification, even with Alive options set In-Reply-To: <5df78e1d0707261532g627af86em32b5db2faef48c9b@mail.gmail.com> Message-ID: On Thu, 26 Jul 2007, Jiaying Zhang wrote: > I was thinking to record the start time and subtract the elapsed time > when an interrupt happens. > How were you going to determine the elapsed time? Only Linux, AFAIK, returns the remaining timeout (correct me if I'm wrong). > But still, when options.server_alive_count_max=1, we should exit after the > first timeout. > Yes, we should since, as you pointed out, options.server_alive_count_max=1 :-) -- Sincerely Your, Dan. From brandon.m.simmons at gmail.com Fri Jul 27 08:30:03 2007 From: brandon.m.simmons at gmail.com (Brandon Simmons) Date: Thu, 26 Jul 2007 18:30:03 -0400 Subject: BUG?: Assigning a Perl script as user shell + sending commands on ssh connect Message-ID: Hi, This is sort of a strange issue. But I am experimenting with ways to have a user log in and be presented with a perl script to interact with. When I do either or both of the following: 1) set the user's shell to /usr/bin/myperlscript 2) specify ForceCommand /usr/bin/myperlscript, applied to my user ...I get strange behavior when a command is appended to the client connect command in this way: ssh -l user 192.168.1.2 ls /etc The output from the perl script is not printed immediately but waits for a carriage return from the user before it is printed to the screen> Here is an example using a test perl script: me at computer:~$ ssh -l user 192.168.1.2 /bin/bash user at 192.168.1.2's password: echo "I'm typing this line while the script seems not to be running" here we go! enter something: YOU SAID: echo "I'm typing this line while the script seems not to be running" You can see that what I type is taken as by the script, so I guess the output is stuck in a buffer somewhere. not sure if this is a bug in OpenSSH or a perl oddity. Or maybe I really shouldn't be setting my user's shell to be a script. From dtucker at zip.com.au Fri Jul 27 09:56:13 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 27 Jul 2007 09:56:13 +1000 Subject: BUG?: Assigning a Perl script as user shell + sending commands on ssh connect In-Reply-To: References: Message-ID: <20070726235613.GA6354@gate.dtucker.net> On Thu, Jul 26, 2007 at 06:30:03PM -0400, Brandon Simmons wrote: > Hi, > This is sort of a strange issue. But I am experimenting with ways to > have a user log in and be presented with a perl script to interact > with. When I do either or both of the following: > > 1) set the user's shell to /usr/bin/myperlscript > > 2) specify ForceCommand /usr/bin/myperlscript, applied to my user > > ...I get strange behavior when a command is appended to the client > connect command in this way: > > ssh -l user 192.168.1.2 ls /etc > > The output from the perl script is not printed immediately but waits > for a carriage return from the user before it is printed to the > screen> Here is an example using a test perl script: [...] > You can see that what I type is taken as by the script, so I > guess the output is stuck in a buffer somewhere. not sure if this is a > bug in OpenSSH or a perl oddity. Or maybe I really shouldn't be > setting my user's shell to be a script. Try setting stdin/out to unbuffered in your perl script: select STDERR; $| = 1; select STDOUT; $| = 1; -- 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 jiayingz at google.com Fri Jul 27 10:03:53 2007 From: jiayingz at google.com (Jiaying Zhang) Date: Thu, 26 Jul 2007 17:03:53 -0700 Subject: ssh client does not timeout if the network fails after ssh_connect but before ssh_exchange_identification, even with Alive options set In-Reply-To: References: <5df78e1d0707261532g627af86em32b5db2faef48c9b@mail.gmail.com> Message-ID: <5df78e1d0707261703l56072506qc309fd96540aad93@mail.gmail.com> On 7/26/07, Dan Yefimov wrote: > > On Thu, 26 Jul 2007, Jiaying Zhang wrote: > > > I was thinking to record the start time and subtract the elapsed time > > when an interrupt happens. > > > How were you going to determine the elapsed time? Only Linux, AFAIK, > returns > the remaining timeout (correct me if I'm wrong). I was thinking to record the start time with gettimeofday and check the current time with it when we set the select timer. If server_alive_interval * server_alive_count_max - (current_time - start_time) is shorter than server_alive_interval, we set timer to that value instead. But since we do not expect the timeout to be very accurate, we can save that trouble. Jiaying > But still, when options.server_alive_count_max=1, we should exit after the > > first timeout. > > > Yes, we should since, as you pointed out, options.server_alive_count_max=1:-) > -- > > Sincerely Your, Dan. > > From djm at mindrot.org Fri Jul 27 12:15:20 2007 From: djm at mindrot.org (Damien Miller) Date: Fri, 27 Jul 2007 12:15:20 +1000 (EST) Subject: ssh client does not timeout if the network fails after ssh_connect but before ssh_exchange_identification, even with Alive options set In-Reply-To: <5df78e1d0707251512w16f34237rd134d21ac6a6af44@mail.gmail.com> References: <5df78e1d0707241533l211ca11awa554acf229802acc@mail.gmail.com> <5df78e1d0707251512w16f34237rd134d21ac6a6af44@mail.gmail.com> Message-ID: On Wed, 25 Jul 2007, Jiaying Zhang wrote: > Hello again, > > Here is the patch I came up with to prevent the hanging in > ssh_exchange_identification. I tested it a little bit and it seems to have > solved the problem. Could anyone help to have a look at the patch? Thanks a > lot! Here is a patch that I did a while ago to make ConnectTimeout apply to banner exchange too (updated to -current): Index: ssh.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/ssh.c,v retrieving revision 1.300 diff -u -p -r1.300 ssh.c --- ssh.c 14 Jun 2007 22:48:05 -0000 1.300 +++ ssh.c 27 Jul 2007 02:14:11 -0000 @@ -202,7 +202,7 @@ main(int ac, char **av) char *p, *cp, *line, buf[256]; struct stat st; struct passwd *pw; - int dummy; + int dummy, timeout_ms; extern int optind, optreset; extern char *optarg; struct servent *sp; @@ -666,13 +666,19 @@ main(int ac, char **av) if (options.control_path != NULL) control_client(options.control_path); + timeout_ms = options.connection_timeout * 1000; + /* Open a connection to the remote host. */ if (ssh_connect(host, &hostaddr, options.port, - options.address_family, options.connection_attempts, + options.address_family, options.connection_attempts, &timeout_ms, + options.tcp_keep_alive, original_effective_uid == 0 && options.use_privileged_port, options.proxy_command) != 0) exit(255); + if (timeout_ms > 0) + debug3("timeout: %d ms remain after connect", timeout_ms); + /* * If we successfully made the connection, load the host private key * in case we will need it later for combined rsa-rhosts @@ -748,7 +754,8 @@ main(int ac, char **av) signal(SIGPIPE, SIG_IGN); /* ignore SIGPIPE early */ /* Log into the remote system. This never returns if the login fails. */ - ssh_login(&sensitive_data, host, (struct sockaddr *)&hostaddr, pw); + ssh_login(&sensitive_data, host, (struct sockaddr *)&hostaddr, + pw, timeout_ms); /* We no longer need the private host keys. Clear them now. */ if (sensitive_data.nkeys != 0) { Index: sshconnect.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/sshconnect.c,v retrieving revision 1.200 diff -u -p -r1.200 sshconnect.c --- sshconnect.c 10 Oct 2006 10:12:45 -0000 1.200 +++ sshconnect.c 27 Jul 2007 02:14:11 -0000 @@ -64,6 +64,23 @@ extern pid_t proxy_command_pid; static int show_other_keys(const char *, Key *); static void warn_changed_key(Key *); +static void +ms_subtract_time(struct timeval *start, int *ms) +{ + struct timeval diff, finish; + + gettimeofday(&finish, NULL); + timersub(&finish, start, &diff); + *ms -= (diff.tv_sec * 1000) + (diff.tv_usec / 1000); +} + +static void +ms_to_timeval(struct timeval *tv, int ms) +{ + tv->tv_sec = ms / 1000; + tv->tv_usec = (ms % 1000) * 1000; +} + /* * Connect to the given ssh server using a proxy command. */ @@ -207,30 +224,36 @@ ssh_create_socket(int privileged, struct static int timeout_connect(int sockfd, const struct sockaddr *serv_addr, - socklen_t addrlen, int timeout) + socklen_t addrlen, int *timeoutp) { fd_set *fdset; - struct timeval tv; + struct timeval tv, t_start; socklen_t optlen; int optval, rc, result = -1; - if (timeout <= 0) - return (connect(sockfd, serv_addr, addrlen)); + gettimeofday(&t_start, NULL); + + if (*timeoutp <= 0) { + result = connect(sockfd, serv_addr, addrlen); + goto done; + } set_nonblock(sockfd); rc = connect(sockfd, serv_addr, addrlen); if (rc == 0) { unset_nonblock(sockfd); - return (0); + result = 0; + goto done; + } + if (errno != EINPROGRESS) { + result = -1; + goto done; } - if (errno != EINPROGRESS) - return (-1); fdset = (fd_set *)xcalloc(howmany(sockfd + 1, NFDBITS), sizeof(fd_mask)); FD_SET(sockfd, fdset); - tv.tv_sec = timeout; - tv.tv_usec = 0; + ms_to_timeval(&tv, *timeoutp); for (;;) { rc = select(sockfd + 1, NULL, fdset, NULL, &tv); @@ -269,6 +292,11 @@ timeout_connect(int sockfd, const struct } xfree(fdset); + + done: + if (result == 0 && *timeoutp > 0) + ms_subtract_time(&t_start, timeoutp); + return (result); } @@ -285,8 +313,8 @@ timeout_connect(int sockfd, const struct */ int ssh_connect(const char *host, struct sockaddr_storage * hostaddr, - u_short port, int family, int connection_attempts, - int needpriv, const char *proxy_command) + u_short port, int family, int connection_attempts, int *timeout_ms, + int want_keepalive, int needpriv, const char *proxy_command) { int gaierr; int on = 1; @@ -339,7 +367,7 @@ ssh_connect(const char *host, struct soc continue; if (timeout_connect(sock, ai->ai_addr, ai->ai_addrlen, - options.connection_timeout) >= 0) { + timeout_ms) >= 0) { /* Successful connection. */ memcpy(hostaddr, ai->ai_addr, ai->ai_addrlen); break; @@ -366,7 +394,7 @@ ssh_connect(const char *host, struct soc debug("Connection established."); /* Set SO_KEEPALIVE if requested. */ - if (options.tcp_keep_alive && + if (want_keepalive && setsockopt(sock, SOL_SOCKET, SO_KEEPALIVE, (void *)&on, sizeof(on)) < 0) error("setsockopt SO_KEEPALIVE: %.100s", strerror(errno)); @@ -382,7 +410,7 @@ ssh_connect(const char *host, struct soc * identification string. */ static void -ssh_exchange_identification(void) +ssh_exchange_identification(int timeout_ms) { char buf[256], remote_version[256]; /* must be same size! */ int remote_major, remote_minor, mismatch; @@ -390,16 +418,44 @@ ssh_exchange_identification(void) int connection_out = packet_get_connection_out(); int minor1 = PROTOCOL_MINOR_1; u_int i, n; + size_t len; + int fdsetsz, remaining, rc; + struct timeval t_start, t_remaining; + fd_set *fdset; + + fdsetsz = howmany(connection_in + 1, NFDBITS) * sizeof(fd_mask); + fdset = xcalloc(1, fdsetsz); /* Read other side's version identification. */ + remaining = timeout_ms; for (n = 0;;) { for (i = 0; i < sizeof(buf) - 1; i++) { - size_t len = atomicio(read, connection_in, &buf[i], 1); + if (timeout_ms > 0) { + gettimeofday(&t_start, NULL); + ms_to_timeval(&t_remaining, remaining); + FD_SET(connection_in, fdset); + rc = select(connection_in + 1, fdset, NULL, + fdset, &t_remaining); + ms_subtract_time(&t_start, &remaining); + if (rc == 0 || remaining <= 0) + fatal("Connection timed out during " + "banner exchange"); + if (rc == -1) { + if (errno == EINTR) + continue; + fatal("ssh_exchange_identification: " + "select: %s", strerror(errno)); + } + } + + len = atomicio(read, connection_in, &buf[i], 1); if (len != 1 && errno == EPIPE) - fatal("ssh_exchange_identification: Connection closed by remote host"); + fatal("ssh_exchange_identification: " + "Connection closed by remote host"); else if (len != 1) - fatal("ssh_exchange_identification: read: %.100s", strerror(errno)); + fatal("ssh_exchange_identification: " + "read: %.100s", strerror(errno)); if (buf[i] == '\r') { buf[i] = '\n'; buf[i + 1] = 0; @@ -410,7 +466,8 @@ ssh_exchange_identification(void) break; } if (++n > 65536) - fatal("ssh_exchange_identification: No banner received"); + fatal("ssh_exchange_identification: " + "No banner received"); } buf[sizeof(buf) - 1] = 0; if (strncmp(buf, "SSH-", 4) == 0) @@ -418,6 +475,7 @@ ssh_exchange_identification(void) debug("ssh_exchange_identification: %s", buf); } server_version_string = xstrdup(buf); + xfree(fdset); /* * Check that the versions match. In future this might accept @@ -926,7 +984,7 @@ verify_host_key(char *host, struct socka */ void ssh_login(Sensitive *sensitive, const char *orighost, - struct sockaddr *hostaddr, struct passwd *pw) + struct sockaddr *hostaddr, struct passwd *pw, int timeout_ms) { char *host, *cp; char *server_user, *local_user; @@ -941,7 +999,7 @@ ssh_login(Sensitive *sensitive, const ch *cp = (char)tolower(*cp); /* Exchange protocol version identification strings with the server. */ - ssh_exchange_identification(); + ssh_exchange_identification(timeout_ms); /* Put the connection into non-blocking mode. */ packet_set_nonblocking(); Index: sshconnect.h =================================================================== RCS file: /cvs/src/usr.bin/ssh/sshconnect.h,v retrieving revision 1.23 diff -u -p -r1.23 sshconnect.h --- sshconnect.h 3 Aug 2006 03:34:42 -0000 1.23 +++ sshconnect.h 27 Jul 2007 02:14:11 -0000 @@ -33,10 +33,10 @@ struct Sensitive { int ssh_connect(const char *, struct sockaddr_storage *, u_short, int, int, - int, const char *); + int *, int, int, const char *); void -ssh_login(Sensitive *, const char *, struct sockaddr *, struct passwd *); +ssh_login(Sensitive *, const char *, struct sockaddr *, struct passwd *, int); int verify_host_key(char *, struct sockaddr *, Key *); From Jefferson.Ogata at noaa.gov Fri Jul 27 09:47:24 2007 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Thu, 26 Jul 2007 23:47:24 +0000 Subject: BUG?: Assigning a Perl script as user shell + sending commands on ssh connect In-Reply-To: References: Message-ID: <46A9328C.9010707@noaa.gov> On 2007-07-26 22:30, Brandon Simmons wrote: > You can see that what I type is taken as by the script, so I > guess the output is stuck in a buffer somewhere. not sure if this is a > bug in OpenSSH or a perl oddity. Or maybe I really shouldn't be > setting my user's shell to be a script. Have you tried setting autoflush on the output stream from your Perl script? -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From jiayingz at google.com Fri Jul 27 12:51:42 2007 From: jiayingz at google.com (Jiaying Zhang) Date: Thu, 26 Jul 2007 19:51:42 -0700 Subject: ssh client does not timeout if the network fails after ssh_connect but before ssh_exchange_identification, even with Alive options set In-Reply-To: References: <5df78e1d0707241533l211ca11awa554acf229802acc@mail.gmail.com> <5df78e1d0707251512w16f34237rd134d21ac6a6af44@mail.gmail.com> Message-ID: <5df78e1d0707261951p27a95820hee8736be9094b1db@mail.gmail.com> Thanks for the updates. Jiaying On 7/26/07, Damien Miller wrote: > > On Wed, 25 Jul 2007, Jiaying Zhang wrote: > > > Hello again, > > > > Here is the patch I came up with to prevent the hanging in > > ssh_exchange_identification. I tested it a little bit and it seems to > have > > solved the problem. Could anyone help to have a look at the patch? > Thanks a > > lot! > > Here is a patch that I did a while ago to make ConnectTimeout apply > to banner exchange too (updated to -current): > > Index: ssh.c > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/ssh.c,v > retrieving revision 1.300 > diff -u -p -r1.300 ssh.c > --- ssh.c 14 Jun 2007 22:48:05 -0000 1.300 > +++ ssh.c 27 Jul 2007 02:14:11 -0000 > @@ -202,7 +202,7 @@ main(int ac, char **av) > char *p, *cp, *line, buf[256]; > struct stat st; > struct passwd *pw; > - int dummy; > + int dummy, timeout_ms; > extern int optind, optreset; > extern char *optarg; > struct servent *sp; > @@ -666,13 +666,19 @@ main(int ac, char **av) > if (options.control_path != NULL) > control_client(options.control_path); > > + timeout_ms = options.connection_timeout * 1000; > + > /* Open a connection to the remote host. */ > if (ssh_connect(host, &hostaddr, options.port, > - options.address_family, options.connection_attempts, > + options.address_family, options.connection_attempts, > &timeout_ms, > + options.tcp_keep_alive, > original_effective_uid == 0 && options.use_privileged_port, > options.proxy_command) != 0) > exit(255); > > + if (timeout_ms > 0) > + debug3("timeout: %d ms remain after connect", timeout_ms); > + > /* > * If we successfully made the connection, load the host private > key > * in case we will need it later for combined rsa-rhosts > @@ -748,7 +754,8 @@ main(int ac, char **av) > signal(SIGPIPE, SIG_IGN); /* ignore SIGPIPE early */ > > /* Log into the remote system. This never returns if the login > fails. */ > - ssh_login(&sensitive_data, host, (struct sockaddr *)&hostaddr, > pw); > + ssh_login(&sensitive_data, host, (struct sockaddr *)&hostaddr, > + pw, timeout_ms); > > /* We no longer need the private host keys. Clear them now. */ > if (sensitive_data.nkeys != 0) { > Index: sshconnect.c > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/sshconnect.c,v > retrieving revision 1.200 > diff -u -p -r1.200 sshconnect.c > --- sshconnect.c 10 Oct 2006 10:12:45 -0000 1.200 > +++ sshconnect.c 27 Jul 2007 02:14:11 -0000 > @@ -64,6 +64,23 @@ extern pid_t proxy_command_pid; > static int show_other_keys(const char *, Key *); > static void warn_changed_key(Key *); > > +static void > +ms_subtract_time(struct timeval *start, int *ms) > +{ > + struct timeval diff, finish; > + > + gettimeofday(&finish, NULL); > + timersub(&finish, start, &diff); > + *ms -= (diff.tv_sec * 1000) + (diff.tv_usec / 1000); > +} > + > +static void > +ms_to_timeval(struct timeval *tv, int ms) > +{ > + tv->tv_sec = ms / 1000; > + tv->tv_usec = (ms % 1000) * 1000; > +} > + > /* > * Connect to the given ssh server using a proxy command. > */ > @@ -207,30 +224,36 @@ ssh_create_socket(int privileged, struct > > static int > timeout_connect(int sockfd, const struct sockaddr *serv_addr, > - socklen_t addrlen, int timeout) > + socklen_t addrlen, int *timeoutp) > { > fd_set *fdset; > - struct timeval tv; > + struct timeval tv, t_start; > socklen_t optlen; > int optval, rc, result = -1; > > - if (timeout <= 0) > - return (connect(sockfd, serv_addr, addrlen)); > + gettimeofday(&t_start, NULL); > + > + if (*timeoutp <= 0) { > + result = connect(sockfd, serv_addr, addrlen); > + goto done; > + } > > set_nonblock(sockfd); > rc = connect(sockfd, serv_addr, addrlen); > if (rc == 0) { > unset_nonblock(sockfd); > - return (0); > + result = 0; > + goto done; > + } > + if (errno != EINPROGRESS) { > + result = -1; > + goto done; > } > - if (errno != EINPROGRESS) > - return (-1); > > fdset = (fd_set *)xcalloc(howmany(sockfd + 1, NFDBITS), > sizeof(fd_mask)); > FD_SET(sockfd, fdset); > - tv.tv_sec = timeout; > - tv.tv_usec = 0; > + ms_to_timeval(&tv, *timeoutp); > > for (;;) { > rc = select(sockfd + 1, NULL, fdset, NULL, &tv); > @@ -269,6 +292,11 @@ timeout_connect(int sockfd, const struct > } > > xfree(fdset); > + > + done: > + if (result == 0 && *timeoutp > 0) > + ms_subtract_time(&t_start, timeoutp); > + > return (result); > } > > @@ -285,8 +313,8 @@ timeout_connect(int sockfd, const struct > */ > int > ssh_connect(const char *host, struct sockaddr_storage * hostaddr, > - u_short port, int family, int connection_attempts, > - int needpriv, const char *proxy_command) > + u_short port, int family, int connection_attempts, int *timeout_ms, > + int want_keepalive, int needpriv, const char *proxy_command) > { > int gaierr; > int on = 1; > @@ -339,7 +367,7 @@ ssh_connect(const char *host, struct soc > continue; > > if (timeout_connect(sock, ai->ai_addr, > ai->ai_addrlen, > - options.connection_timeout) >= 0) { > + timeout_ms) >= 0) { > /* Successful connection. */ > memcpy(hostaddr, ai->ai_addr, > ai->ai_addrlen); > break; > @@ -366,7 +394,7 @@ ssh_connect(const char *host, struct soc > debug("Connection established."); > > /* Set SO_KEEPALIVE if requested. */ > - if (options.tcp_keep_alive && > + if (want_keepalive && > setsockopt(sock, SOL_SOCKET, SO_KEEPALIVE, (void *)&on, > sizeof(on)) < 0) > error("setsockopt SO_KEEPALIVE: %.100s", strerror(errno)); > @@ -382,7 +410,7 @@ ssh_connect(const char *host, struct soc > * identification string. > */ > static void > -ssh_exchange_identification(void) > +ssh_exchange_identification(int timeout_ms) > { > char buf[256], remote_version[256]; /* must be same size! */ > int remote_major, remote_minor, mismatch; > @@ -390,16 +418,44 @@ ssh_exchange_identification(void) > int connection_out = packet_get_connection_out(); > int minor1 = PROTOCOL_MINOR_1; > u_int i, n; > + size_t len; > + int fdsetsz, remaining, rc; > + struct timeval t_start, t_remaining; > + fd_set *fdset; > + > + fdsetsz = howmany(connection_in + 1, NFDBITS) * sizeof(fd_mask); > + fdset = xcalloc(1, fdsetsz); > > /* Read other side's version identification. */ > + remaining = timeout_ms; > for (n = 0;;) { > for (i = 0; i < sizeof(buf) - 1; i++) { > - size_t len = atomicio(read, connection_in, > &buf[i], 1); > + if (timeout_ms > 0) { > + gettimeofday(&t_start, NULL); > + ms_to_timeval(&t_remaining, remaining); > + FD_SET(connection_in, fdset); > + rc = select(connection_in + 1, fdset, > NULL, > + fdset, &t_remaining); > + ms_subtract_time(&t_start, &remaining); > + if (rc == 0 || remaining <= 0) > + fatal("Connection timed out during > " > + "banner exchange"); > + if (rc == -1) { > + if (errno == EINTR) > + continue; > + > fatal("ssh_exchange_identification: " > + "select: %s", > strerror(errno)); > + } > + } > + > + len = atomicio(read, connection_in, &buf[i], 1); > > if (len != 1 && errno == EPIPE) > - fatal("ssh_exchange_identification: > Connection closed by remote host"); > + fatal("ssh_exchange_identification: " > + "Connection closed by remote host"); > else if (len != 1) > - fatal("ssh_exchange_identification: read: > %.100s", strerror(errno)); > + fatal("ssh_exchange_identification: " > + "read: %.100s", strerror(errno)); > if (buf[i] == '\r') { > buf[i] = '\n'; > buf[i + 1] = 0; > @@ -410,7 +466,8 @@ ssh_exchange_identification(void) > break; > } > if (++n > 65536) > - fatal("ssh_exchange_identification: No > banner received"); > + fatal("ssh_exchange_identification: " > + "No banner received"); > } > buf[sizeof(buf) - 1] = 0; > if (strncmp(buf, "SSH-", 4) == 0) > @@ -418,6 +475,7 @@ ssh_exchange_identification(void) > debug("ssh_exchange_identification: %s", buf); > } > server_version_string = xstrdup(buf); > + xfree(fdset); > > /* > * Check that the versions match. In future this might accept > @@ -926,7 +984,7 @@ verify_host_key(char *host, struct socka > */ > void > ssh_login(Sensitive *sensitive, const char *orighost, > - struct sockaddr *hostaddr, struct passwd *pw) > + struct sockaddr *hostaddr, struct passwd *pw, int timeout_ms) > { > char *host, *cp; > char *server_user, *local_user; > @@ -941,7 +999,7 @@ ssh_login(Sensitive *sensitive, const ch > *cp = (char)tolower(*cp); > > /* Exchange protocol version identification strings with the > server. */ > - ssh_exchange_identification(); > + ssh_exchange_identification(timeout_ms); > > /* Put the connection into non-blocking mode. */ > packet_set_nonblocking(); > Index: sshconnect.h > =================================================================== > RCS file: /cvs/src/usr.bin/ssh/sshconnect.h,v > retrieving revision 1.23 > diff -u -p -r1.23 sshconnect.h > --- sshconnect.h 3 Aug 2006 03:34:42 -0000 1.23 > +++ sshconnect.h 27 Jul 2007 02:14:11 -0000 > @@ -33,10 +33,10 @@ struct Sensitive { > > int > ssh_connect(const char *, struct sockaddr_storage *, u_short, int, int, > - int, const char *); > + int *, int, int, const char *); > > void > -ssh_login(Sensitive *, const char *, struct sockaddr *, struct passwd *); > +ssh_login(Sensitive *, const char *, struct sockaddr *, struct passwd *, > int); > > int verify_host_key(char *, struct sockaddr *, Key *); > > From rapier at psc.edu Fri Jul 27 13:45:08 2007 From: rapier at psc.edu (chris rapier) Date: Thu, 26 Jul 2007 23:45:08 -0400 Subject: Channel Handling Patch In-Reply-To: References: Message-ID: <46A96A44.7060903@psc.edu> Indeed I did. I'll make that change tomorrow. Also, I do want to point out that this patch could have been done in different ways. Essentially, all its doing is replacing one type of loop with another - which is all I wanted to address at this point. More generally, I don't look at this as a production level patch but more of an idea for people to consider. If people think its worthwhile I'll be spending some more time on it. Dan Yefimov wrote: > On Thu, 26 Jul 2007, Chris Rapier wrote: > > May be you mean xmalloc() instead of malloc() in the channel_add_node() ? From brandon.m.simmons at gmail.com Fri Jul 27 13:46:37 2007 From: brandon.m.simmons at gmail.com (Brandon Simmons) Date: Thu, 26 Jul 2007 23:46:37 -0400 Subject: BUG?: Assigning a Perl script as user shell + sending commands on ssh connect In-Reply-To: <20070726235613.GA6354@gate.dtucker.net> References: <20070726235613.GA6354@gate.dtucker.net> Message-ID: On 7/26/07, Darren Tucker wrote: > On Thu, Jul 26, 2007 at 06:30:03PM -0400, Brandon Simmons wrote: > > Hi, > > This is sort of a strange issue. But I am experimenting with ways to > > have a user log in and be presented with a perl script to interact > > with. When I do either or both of the following: > > > > 1) set the user's shell to /usr/bin/myperlscript > > > > 2) specify ForceCommand /usr/bin/myperlscript, applied to my user > > > > ...I get strange behavior when a command is appended to the client > > connect command in this way: > > > > ssh -l user 192.168.1.2 ls /etc > > > > The output from the perl script is not printed immediately but waits > > for a carriage return from the user before it is printed to the > > screen> Here is an example using a test perl script: > [...] > > You can see that what I type is taken as by the script, so I > > guess the output is stuck in a buffer somewhere. not sure if this is a > > bug in OpenSSH or a perl oddity. Or maybe I really shouldn't be > > setting my user's shell to be a script. > > Try setting stdin/out to unbuffered in your perl script: > > select STDERR; $| = 1; > select STDOUT; $| = 1; > > -- > 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. > Thanks, that did it. While we're on the subject, is what I'm doing with setting a user's shell to a perl script a kosher thing to do. Are there any security problems that you know of? I've been trying to break it, but haven't been able to at this point. thanks From stuge-openssh-unix-dev at cdy.org Fri Jul 27 23:11:47 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 27 Jul 2007 15:11:47 +0200 Subject: BUG?: Assigning a Perl script as user shell + sending commands on ssh connect In-Reply-To: References: <20070726235613.GA6354@gate.dtucker.net> Message-ID: <20070727131147.21066.qmail@cdy.org> On Thu, Jul 26, 2007 at 11:46:37PM -0400, Brandon Simmons wrote: > is what I'm doing with setting a user's shell to a perl script a > kosher thing to do. Are there any security problems that you know > of? You are trusting perl then. It is the software running with user privileges after all. //Peter From storm.richard at gmail.com Sat Jul 28 06:47:49 2007 From: storm.richard at gmail.com (Richard Storm) Date: Fri, 27 Jul 2007 23:47:49 +0300 Subject: secure user restriction Message-ID: <6ac10b630707271347x2c9c0421jb0eaaaee428115c4@mail.gmail.com> I am using sftp-server chroot patch: http://marc.info/?l=openssh-unix-dev&m=116043792120525&w=2 Works fine, except user is able to ssh in box. I could change users shell to /usr/libexec/sftp-server, but then chrooting wouldn't work. What is secure way to accomplish this, so that I could give friend ssh access, so that he could upload/download stuff, but not compromise my system or reveal any sensitive information? From stuge-openssh-unix-dev at cdy.org Sat Jul 28 07:32:50 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Fri, 27 Jul 2007 23:32:50 +0200 Subject: secure user restriction In-Reply-To: <6ac10b630707271347x2c9c0421jb0eaaaee428115c4@mail.gmail.com> References: <6ac10b630707271347x2c9c0421jb0eaaaee428115c4@mail.gmail.com> Message-ID: <20070727213250.1386.qmail@cdy.org> On Fri, Jul 27, 2007 at 11:47:49PM +0300, Richard Storm wrote: > I am using sftp-server chroot patch: [..] > What is secure way to accomplish this http://pizzashack.org/rssh/ //Peter From 1.41421 at gmail.com Sat Jul 28 20:13:08 2007 From: 1.41421 at gmail.com (JCA) Date: Sat, 28 Jul 2007 11:13:08 +0100 Subject: Still confused about window adjustments Message-ID: Let's say, for concreteness, that I have a box A running an OpenSSH client, and a box B running an SSH server, which may or may not be OpenSSH. Looking in the OpenSSH code, I got the impression (this may be wrong; please let me know if it is) that on receiving a packet that consumes window space, A would check out whether or not its current window has to be adjusted. If it does then it immediately sends a window adjust packet to B. Now what happens if B has sent, say, three packets (1, 2 and 3) that consume window space space in the same network frame? B may have constructed the packets in such a way that they consume all the window space available at the time. However, if A examines 1 and determines that it needs to send a window adjust packet immediately (which may well happen) before examining 2 and 3, would it not be the case that, from that point onwards, A and B will have a different idea of the current window size? I am assuming that, when sending a window adjust packet, A changes the value of its internal window size counter correspondingly. If that is the case, when processing packets 2 and 3 A will be using a different measure of the window size than that used by B when it constructed them - which might well lead to a en eventual deadlock in the conversation between A and B. Is there anything to this, or am I totally off the mark here? Feedback from OpenSSH developers would be much appreciated. From storm.richard at gmail.com Sun Jul 29 07:46:13 2007 From: storm.richard at gmail.com (Richard Storm) Date: Sun, 29 Jul 2007 00:46:13 +0300 Subject: chroot'd SFTP In-Reply-To: <46AB9379.7030904@minstrel.org.uk> References: <46AB9379.7030904@minstrel.org.uk> Message-ID: <6ac10b630707281446x21919299jacb50ee6cc3917d6@mail.gmail.com> Thanks for these 3rd party hacks! I don't trust them. There must be such feature in openssh out of box. So the most secure/easyer method of giving sftp access to porn collection is: Damiens sftp-server chroot patch, which I hope to see in openssh one day :) http://marc.info/?l=openssh-unix-dev&m=116043792120525&w=2 # useradd -d /data/p0rn -m share /etc/ssh/sshd_config: Match user share X11Forwarding no AllowTCPForwarding no ForceCommand /usr/libexec/sftp-server -C %d pkill sshd; /usr/sbin/sshd and done :) On 7/28/07, Peter SJF Bance wrote: > Hi, > > I noticed your post at: > > http://www.gossamer-threads.com/lists/openssh/dev/40355 > > I don't subscribe to the list, so can't reply there, but this may help: > > http://www.minstrel.org.uk/papers/sftp/ > > This discusses how to set up chroot'd SFTP only (no shell). > > -- > Peter SJF Bance > http://www.minstrel.org.uk/ > From stuge-openssh-unix-dev at cdy.org Sun Jul 29 13:12:10 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sun, 29 Jul 2007 05:12:10 +0200 Subject: chroot'd SFTP In-Reply-To: <6ac10b630707281446x21919299jacb50ee6cc3917d6@mail.gmail.com> References: <46AB9379.7030904@minstrel.org.uk> <6ac10b630707281446x21919299jacb50ee6cc3917d6@mail.gmail.com> Message-ID: <20070729031210.9910.qmail@cdy.org> On Sun, Jul 29, 2007 at 12:46:13AM +0300, Richard Storm wrote: > There must be such feature in openssh out of box. I'm not so sure.. > # useradd -d /data/p0rn -m share > > /etc/ssh/sshd_config: > Match user share > X11Forwarding no > AllowTCPForwarding no > ForceCommand /usr/libexec/sftp-server -C %d > > pkill sshd; /usr/sbin/sshd > and done :) Couldn't one just use a wrapper script doing the equivalent of the patch and then exec:ing sftp-server ? //Peter From dtucker at zip.com.au Sun Jul 29 13:28:11 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 29 Jul 2007 13:28:11 +1000 Subject: chroot'd SFTP In-Reply-To: <20070729031210.9910.qmail@cdy.org> References: <46AB9379.7030904@minstrel.org.uk> <6ac10b630707281446x21919299jacb50ee6cc3917d6@mail.gmail.com> <20070729031210.9910.qmail@cdy.org> Message-ID: <46AC094B.2030803@zip.com.au> Peter Stuge wrote: > On Sun, Jul 29, 2007 at 12:46:13AM +0300, Richard Storm wrote: >> /etc/ssh/sshd_config: >> Match user share >> X11Forwarding no >> AllowTCPForwarding no >> ForceCommand /usr/libexec/sftp-server -C %d >> >> pkill sshd; /usr/sbin/sshd >> and done :) > > Couldn't one just use a wrapper script doing the equivalent of the > patch and then exec:ing sftp-server ? You could, but if you do the chroot before exec'ing sftp-server then you would need to put all of the libraries used by sftp-server (and /dev entries, and whatever else it wants at startup) inside each chroot. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From djm at mindrot.org Mon Jul 30 20:48:55 2007 From: djm at mindrot.org (Damien Miller) Date: Mon, 30 Jul 2007 20:48:55 +1000 (EST) Subject: chroot'd SFTP In-Reply-To: <6ac10b630707281446x21919299jacb50ee6cc3917d6@mail.gmail.com> References: <46AB9379.7030904@minstrel.org.uk> <6ac10b630707281446x21919299jacb50ee6cc3917d6@mail.gmail.com> Message-ID: On Sun, 29 Jul 2007, Richard Storm wrote: > Thanks for these 3rd party hacks! I don't trust them. > There must be such feature in openssh out of box. > > So the most secure/easyer method of giving sftp access to porn collection is: > Damiens sftp-server chroot patch, which I hope to see in openssh one day :) > http://marc.info/?l=openssh-unix-dev&m=116043792120525&w=2 The big problem with that patch is that it effectively allows non-root users to chroot to a directory of their choice. The only way I have come up with to get around this problems is to arrange sshd to execute subsystems with an additional supplementary group (say "_sshd_subsys") and to make the setuid sftp-server mode 0710, but I haven't properly thought through whether this will actually solve all the problems yet. In the meantime please treat my patch is unsupported, potentially dangerous code. -d From storm.richard at gmail.com Tue Jul 31 00:18:49 2007 From: storm.richard at gmail.com (Richard Storm) Date: Mon, 30 Jul 2007 17:18:49 +0300 Subject: chroot'd SFTP In-Reply-To: <46ADC6EE.40503@minstrel.org.uk> References: <46AB9379.7030904@minstrel.org.uk> <6ac10b630707281446x21919299jacb50ee6cc3917d6@mail.gmail.com> <46ADC6EE.40503@minstrel.org.uk> Message-ID: <6ac10b630707300718x552ce136x45520c8c41ce04fa@mail.gmail.com> > >> http://marc.info/?l=openssh-unix-dev&m=116043792120525&w=2 > > > > The big problem with that patch is that it effectively allows non-root > > users to chroot to a directory of their choice. How!? Doesn't sftp-server respect received "-C %d" args which are hardcoded in ForceCommand, to chroot user in HIS home directory? > > -- > Peter SJF Bance > http://www.minstrel.org.uk/ > From MMcBride at ohsers.org Mon Jul 30 23:16:33 2007 From: MMcBride at ohsers.org (Mark McBride) Date: Mon, 30 Jul 2007 09:16:33 -0400 Subject: SFTP seems to ignore permissions Message-ID: <0AF6E66304D7CE47BC7BDB792124617CAB7166@orion.ohsers.local> I am trying to use sftp for a drop box type of application. Using a common userid and password, allow known entities to PUT files on my server. But not allow them get GET the files that are there, not to overwrite on the files. However, sftp seems to ignore that file permissions that are on the files! I change the permissions to 000 and a client can still GET the file and overwrite it with a new file! What can I do to configure the sftp-server to behave the way I need? Thanks mark CONFIDENTIALITY NOTICE: The School Employees Retirement System of Ohio intends this e-mail message, and any attachments, to be used only by the person(s) or entity to which it is addressed. This message may contain confidential and/or legally privileged information. If the reader is not the intended recipient of this message or an employee or agent responsible for delivering the message to the intended recipient, you are hereby notified that you are prohibited from printing, copying, storing, disseminating or distributing this communication. If you received this communication in error, please delete it from your computer and notify the sender by reply e-mail. From newacct at ugcs.caltech.edu Tue Jul 31 07:26:45 2007 From: newacct at ugcs.caltech.edu (foo) Date: Mon, 30 Jul 2007 14:26:45 -0700 Subject: VPN in Windows? Message-ID: <1F37F03F67DB4B5FBFA6B2495B9E0D7F@dabney.caltech.edu> Is there any chance that the VPN feature of the client can be ported to Windows (such that even non-Cygwin Windows programs would be able to use it) any time in the near future? It seems like many people would find this feature useful on Windows. If not, is there any other way to accomplish the OpenSSH VPN thing with other free tools? Thanks, From stuge-openssh-unix-dev at cdy.org Tue Jul 31 07:22:34 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Mon, 30 Jul 2007 23:22:34 +0200 Subject: chroot'd SFTP In-Reply-To: <6ac10b630707300718x552ce136x45520c8c41ce04fa@mail.gmail.com> References: <46AB9379.7030904@minstrel.org.uk> <6ac10b630707281446x21919299jacb50ee6cc3917d6@mail.gmail.com> <46ADC6EE.40503@minstrel.org.uk> <6ac10b630707300718x552ce136x45520c8c41ce04fa@mail.gmail.com> Message-ID: <20070730212234.16969.qmail@cdy.org> On Mon, Jul 30, 2007 at 05:18:49PM +0300, Richard Storm wrote: > > >> http://marc.info/?l=openssh-unix-dev&m=116043792120525&w=2 > > > > > > The big problem with that patch is that it effectively allows non-root > > > users to chroot to a directory of their choice. > How!? sftp-server has to be setuid root and invokable by all users that should have SFTP access. Granted, it could be argued that this is unimportant if there are no users who can execute arbitrary commands in the system. //Peter From djm at mindrot.org Tue Jul 31 07:58:31 2007 From: djm at mindrot.org (Damien Miller) Date: Tue, 31 Jul 2007 07:58:31 +1000 (EST) Subject: chroot'd SFTP In-Reply-To: <6ac10b630707300718x552ce136x45520c8c41ce04fa@mail.gmail.com> References: <46AB9379.7030904@minstrel.org.uk> <6ac10b630707281446x21919299jacb50ee6cc3917d6@mail.gmail.com> <46ADC6EE.40503@minstrel.org.uk> <6ac10b630707300718x552ce136x45520c8c41ce04fa@mail.gmail.com> Message-ID: On Mon, 30 Jul 2007, Richard Storm wrote: > > >> http://marc.info/?l=openssh-unix-dev&m=116043792120525&w=2 > > > > > > The big problem with that patch is that it effectively allows non-root > > > users to chroot to a directory of their choice. > How!? Doesn't sftp-server respect received "-C %d" args which are > hardcoded in ForceCommand, to chroot user in HIS home directory? by running sftp-server with a -C option of their choice From stuge-openssh-unix-dev at cdy.org Tue Jul 31 07:52:38 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Mon, 30 Jul 2007 23:52:38 +0200 Subject: VPN in Windows? In-Reply-To: <1F37F03F67DB4B5FBFA6B2495B9E0D7F@dabney.caltech.edu> References: <1F37F03F67DB4B5FBFA6B2495B9E0D7F@dabney.caltech.edu> Message-ID: <20070730215238.21745.qmail@cdy.org> On Mon, Jul 30, 2007 at 02:26:45PM -0700, foo wrote: > Is there any chance that the VPN feature of the client can be > ported to Windows (such that even non-Cygwin Windows programs would > be able to use it) any time in the near future? I doubt it. OpenSSH is not easily portable to Win32. > It seems like many people would find this feature useful on > Windows. If not, is there any other way to accomplish the OpenSSH > VPN thing with other free tools? I would suggest looking into the free software tool OpenVPN at http://openvpn.net/ and the Win32 tool OpenVPNGUI at http://openvpn.se/ for a VPN software that works well on Win32. OpenVPNGUI even distribute an installer with everything needed for Win32. //Peter From jon at cybus.co.uk Tue Jul 31 18:23:55 2007 From: jon at cybus.co.uk (Jonathan Miles) Date: Tue, 31 Jul 2007 09:23:55 +0100 Subject: chroot'd SFTP In-Reply-To: References: <46AB9379.7030904@minstrel.org.uk> <6ac10b630707281446x21919299jacb50ee6cc3917d6@mail.gmail.com> <46ADC6EE.40503@minstrel.org.uk> <6ac10b630707300718x552ce136x45520c8c41ce04fa@mail.gmail.com> Message-ID: <46AEF19B.4020908@cybus.co.uk> Damien Miller wrote: > On Mon, 30 Jul 2007, Richard Storm wrote: > >>>>> http://marc.info/?l=openssh-unix-dev&m=116043792120525&w=2 >>>> The big problem with that patch is that it effectively allows non-root >>>> users to chroot to a directory of their choice. >> How!? Doesn't sftp-server respect received "-C %d" args which are >> hardcoded in ForceCommand, to chroot user in HIS home directory? > > by running sftp-server with a -C option of their choice Is it really necessary to pass the chroot path to sftp-server? I wrote a patch a while back which jails to the target user's home directory and also prevents access to the shell/exec channels, amongst other things. So my config looks like this... # Prevent users in restricted group from using shell and exec channels Match Group restricted ChannelReqDeny shell ChannelReqDeny exec Subsystem sftp /usr/lib/openssh/sftp-server --chroot -l VERBOSE The attached diff is against portable CVS from back in April and I've been using it on a dev server since then without problems. It could do with a little tidying up (debug stuff), a sync with latest CVS and perhaps making the commands a bit more user-friendly. If there's any interest, I'll do so... Jon -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: chroot-portable.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20070731/20ae166f/attachment-0001.ksh From storm.richard at gmail.com Tue Jul 31 22:00:30 2007 From: storm.richard at gmail.com (Richard Storm) Date: Tue, 31 Jul 2007 15:00:30 +0300 Subject: chroot'd SFTP In-Reply-To: References: <46AB9379.7030904@minstrel.org.uk> <6ac10b630707281446x21919299jacb50ee6cc3917d6@mail.gmail.com> <46ADC6EE.40503@minstrel.org.uk> <6ac10b630707300718x552ce136x45520c8c41ce04fa@mail.gmail.com> Message-ID: <6ac10b630707310500q6a1fee9cj45e77ac8f95d47f8@mail.gmail.com> On 7/31/07, Damien Miller wrote: > On Mon, 30 Jul 2007, Richard Storm wrote: > > > > >> http://marc.info/?l=openssh-unix-dev&m=116043792120525&w=2 > > > > > > > > The big problem with that patch is that it effectively allows non-root > > > > users to chroot to a directory of their choice. > > How!? Doesn't sftp-server respect received "-C %d" args which are > > hardcoded in ForceCommand, to chroot user in HIS home directory? > > by running sftp-server with a -C option of their choice > Thanks, I got now. Local/remote users with shell access can chroot in any dir they want. However, is this security problem, since after that privs are dropped and unix permissions are in effect...