From dave.wright at construx.com Sat Nov 3 10:18:42 2007 From: dave.wright at construx.com (Dave Wright) Date: Fri, 2 Nov 2007 16:18:42 -0700 Subject: [Patch, enh] Permit host and IP addresses in (Allow|Deny)Groups Message-ID: <323BB51CE8D82A4089160BB42356AA5B050C1505@cxexchange.construx.com> Hi, I ran across a case in which my server maintenance was simplified by using SSHD configuration options like this in sshd_config: AllowGroups admin at 192.168.0.* sshuser in much the same fashion as (Allow|Deny)Users. In this case, the goal is to provide access to administrators only from the local network, while allowing SSH users to login from anywhere. This (IMHO) simplifies access management by leveraging group membership more effectively. Anyway, I've attached a patch in case anyone feels it's useful enough to put into a future release. -- Dave Wright -------------- diff -r -u -N openssh-4.7p1/auth.c osshGroupHostIP-4.7p1/auth.c --- openssh-4.7p1/auth.c 2007-03-26 09:35:28.000000000 -0700 +++ osshGroupHostIP-4.7p1/auth.c 2007-11-02 14:52:58.000000000 -0700 @@ -210,8 +210,13 @@ /* Return false if one of user's groups is listed in DenyGroups */ if (options.num_deny_groups > 0) +#ifndef GROUP_MATCH_HOST_AND_IP if (ga_match(options.deny_groups, options.num_deny_groups)) { +#else /* GROUP_MATCH_HOST_AND_IP */ + if (ga_match_host_and_ip(options.deny_groups, + options.num_deny_groups, hostname, ipaddr)) { +#endif /* GROUP_MATCH_HOST_AND_IP */ ga_free(); logit("User %.100s from %.100s not allowed " "because a group is listed in DenyGroups", @@ -223,8 +228,13 @@ * isn't listed there */ if (options.num_allow_groups > 0) +#ifndef GROUP_MATCH_HOST_AND_IP if (!ga_match(options.allow_groups, options.num_allow_groups)) { +#else /* GROUP_MATCH_HOST_AND_IP */ + if (!ga_match_host_and_ip(options.allow_groups, + options.num_allow_groups, hostname, ipaddr)) { +#endif /* GROUP_MATCH_HOST_AND_IP */ ga_free(); logit("User %.100s from %.100s not allowed " "because none of user's groups are listed " diff -r -u -N openssh-4.7p1/groupaccess.c osshGroupHostIP-4.7p1/groupaccess.c --- openssh-4.7p1/groupaccess.c 2006-08-04 19:39:40.000000000 -0700 +++ osshGroupHostIP-4.7p1/groupaccess.c 2007-11-02 14:46:08.000000000 -0700 @@ -37,6 +37,10 @@ #include "match.h" #include "log.h" +#ifdef GROUP_MATCH_HOST_AND_IP +#include +#endif /* GROUP_MATCH_HOST_AND_IP */ + static int ngroups; static char **groups_byname; @@ -86,6 +90,40 @@ return 1; return 0; } +#ifdef GROUP_MATCH_HOST_AND_IP + +/* + * Permit the 'user at host' configuration file syntax (AllowUsers, ...) + * to be used for 'group at host' as well. (AllowGroups, ...). + * + * Return 1 if one of user's groups is matched by a group pattern AND + * (access allowed from anywhere OR access is from allowed host / network). + * Return 0 otherwise. + */ +int +ga_match_host_and_ip(char * const *patterns, int npatterns, + const char *hostname, const char *ipaddr) +{ + char *host_pattern; + char *name_pattern; + int found; + int i, j; + + found = 0; + for (i = 0; !found && i < npatterns; i++) { + name_pattern = xstrdup(patterns[i]); + host_pattern = strchr(name_pattern, '@'); + if (host_pattern) + *host_pattern++ = '\0'; + for (j = 0; !found && j < ngroups; j++) + if (match_pattern(groups_byname[j], name_pattern)) + found = !host_pattern || + match_host_and_ip(hostname, ipaddr, host_pattern); + xfree(name_pattern); + } + return found; +} +#endif /* GROUP_MATCH_HOST_AND_IP */ /* * Free memory allocated for group access list. diff -r -u -N openssh-4.7p1/groupaccess.h osshGroupHostIP-4.7p1/groupaccess.h --- openssh-4.7p1/groupaccess.h 2006-08-04 19:39:40.000000000 -0700 +++ osshGroupHostIP-4.7p1/groupaccess.h 2007-11-02 14:46:08.000000000 -0700 @@ -27,8 +27,15 @@ #ifndef GROUPACCESS_H #define GROUPACCESS_H +/* Permit group at host style {Allow|Deny}Groups directive. */ +#define GROUP_MATCH_HOST_AND_IP + int ga_init(const char *, gid_t); int ga_match(char * const *, int); void ga_free(void); +#ifdef GROUP_MATCH_HOST_AND_IP +int ga_match_host_and_ip(char * const *, int, const char *, const char *); +#endif /* GROUP_MATCH_HOST_AND_IP */ + #endif From stuge-openssh-unix-dev at cdy.org Sat Nov 3 13:01:08 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sat, 3 Nov 2007 03:01:08 +0100 Subject: [Patch, enh] Permit host and IP addresses in (Allow|Deny)Groups In-Reply-To: <323BB51CE8D82A4089160BB42356AA5B050C1505@cxexchange.construx.com> References: <323BB51CE8D82A4089160BB42356AA5B050C1505@cxexchange.construx.com> Message-ID: <20071103020108.28453.qmail@cdy.org> On Fri, Nov 02, 2007 at 04:18:42PM -0700, Dave Wright wrote: > AllowGroups admin at 192.168.0.* sshuser Maybe Match could be used to do the same thing? //Peter From 1.41421 at gmail.com Sun Nov 4 08:12:40 2007 From: 1.41421 at gmail.com (JCA) Date: Sat, 3 Nov 2007 14:12:40 -0700 Subject: Yet another question on window computations Message-ID: A couple of weeks ago I made an inquiry on window computation details that has so far gone unanswered - unsurprisingly so, I now realize, for it was way too involved. Let me try again with a simplified version, in the hope that some nice OpenSSH developer could please provide an answer. What is the rationale underpinning the sending of a window adjust packet, as implemented in channels.c? Until recently, the condition c->local_window < c->local_window_max/2 && c->local_consumed > 0 where, if I understand it correctly, local_window is the current size of the window, local_window_max is the maximum window size initially agreed on by client and server, and local_consumed is number of bytes already consumed in the current window at a given time. That is, local_window + local_consumed = local_window_max; it would seem that every time a window adjust packet is sent, the size of the window gets reset to local_window_max. Why local_window < local_window_max/2? Why not local_window == 0, or even local_window <= 0? Also why local_consumed > 0? Isn't local_consumed reset to 0 whenever a window adjust packet is sent (I am looking at this from the point of view of the client), and incremented afterwards? In the latest OpenSSH release the condition is changed to ((c->local_window_max - c->local_window > c->local_maxpacket*3) || c->local_window < c->local_window_max/2) && c->local_consumed > 0 Why the new conditional? What issues does it address that are not addressed by the older, simpler version? My apologies if these are trivial questions. I am trying to understand why OpenSSH does things the way it does, and as far as the windowing code is concerned, although the C code is simple enough, the motivation behind it is not at all clear to me - hence me appeal to the OpenSSH developers for clarification. From milon at wq.cz Sun Nov 4 23:39:29 2007 From: milon at wq.cz (Milan Kocian) Date: Sun, 4 Nov 2007 13:39:29 +0100 Subject: problem with sftp & huawei switches Message-ID: <20071104123929.GA9023@wq.cz> hello, I have the problem with sftp, I can't read files and dirs from huawei switches. I see: mm:/home/milon# sftp 10.1.1.30:vrpcfg.cfg . Connecting to 10.1.1.30... root at 10.1.1.30's password: Couldn't stat remote file: Operation unsupported File "flash:/flash:/vrpcfg.cfg" not found. Received disconnect from 10.1.1.30: 2: The connection is closed by SSH Server Current FSM is SSH_Main_Disconnect Or interactive session: sftp> ls Couldn't stat remote file: Operation unsupported Can't ls: "flash:/" not found sftp> cd / Couldn't stat remote file: Operation unsupported sftp> get vrpcfg.cfg Couldn't stat remote file: Operation unsupported File "flash:/vrpcfg.cfg" not found. Hovewer mkdir, rmdir, put and rm operations are working. Winscp program is working too. Any suggestions ? Or workaround ? openssh version 4.6p1, switch huawei quidway 5600; reading file of course exists Thanks for any reply. (Please cc) regards, -- Milan Kocian From stuge-openssh-unix-dev at cdy.org Mon Nov 5 03:37:07 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sun, 4 Nov 2007 17:37:07 +0100 Subject: problem with sftp & huawei switches In-Reply-To: <20071104123929.GA9023@wq.cz> References: <20071104123929.GA9023@wq.cz> Message-ID: <20071104163707.19882.qmail@cdy.org> On Sun, Nov 04, 2007 at 01:39:29PM +0100, Milan Kocian wrote: > Or interactive session: > > sftp> ls > Couldn't stat remote file: Operation unsupported > Can't ls: "flash:/" not found Does the pwd command work? //Peter From milon at wq.cz Mon Nov 5 03:52:16 2007 From: milon at wq.cz (Milan Kocian) Date: Sun, 4 Nov 2007 17:52:16 +0100 Subject: problem with sftp & huawei switches In-Reply-To: <20071104163707.19882.qmail@cdy.org> References: <20071104123929.GA9023@wq.cz> <20071104163707.19882.qmail@cdy.org> Message-ID: <20071104165216.GA8380@wq.cz> On Sun, Nov 04, 2007 at 05:37:07PM +0100, Peter Stuge wrote: > On Sun, Nov 04, 2007 at 01:39:29PM +0100, Milan Kocian wrote: > > Or interactive session: > > > > sftp> ls > > Couldn't stat remote file: Operation unsupported > > Can't ls: "flash:/" not found > > Does the pwd command work? > Yes, it works: sftp> pwd Remote working directory: flash:/ sftp> -- Milan Kocian From stuge-openssh-unix-dev at cdy.org Mon Nov 5 04:27:22 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sun, 4 Nov 2007 18:27:22 +0100 Subject: problem with sftp & huawei switches In-Reply-To: <20071104165216.GA8380@wq.cz> References: <20071104123929.GA9023@wq.cz> <20071104163707.19882.qmail@cdy.org> <20071104165216.GA8380@wq.cz> Message-ID: <20071104172722.30094.qmail@cdy.org> On Sun, Nov 04, 2007 at 05:52:16PM +0100, Milan Kocian wrote: > > > sftp> ls > > > Couldn't stat remote file: Operation unsupported > > > Can't ls: "flash:/" not found > > > > Does the pwd command work? > > Yes, it works: > > sftp> pwd > Remote working directory: flash:/ How about "ls ." and "ls /" ? The problem is that the path to the top of the filesystem does not start with '/' but with 'f' (flash:) - I don't know if this is a problem with OpenSSH or huawei software or maybe the filexfer drafts. //Peter From dtucker at zip.com.au Mon Nov 5 05:44:54 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 4 Nov 2007 10:44:54 -0800 Subject: problem with sftp & huawei switches In-Reply-To: <20071104123929.GA9023@wq.cz> References: <20071104123929.GA9023@wq.cz> Message-ID: (resend, my previous reply was from a non-subscribed address) On Nov 4, 2007 4:39 AM, Milan Kocian wrote: > I have the problem with sftp, I can't read files and dirs from huawei > switches. I see: > > mm:/home/milon# sftp 10.1.1.30:vrpcfg.cfg . > Connecting to 10.1.1.30... > root at 10.1.1.30's password: > Couldn't stat remote file: Operation unsupported > File "flash:/flash:/vrpcfg.cfg" not found. > Received disconnect from 10.1.1.30: 2: The connection is closed by > SSH Server > Current FSM is SSH_Main_Disconnect Looks like your switch doesn't support the stat() operation, which sftp(1) uses before the download and will abort the download if the stat fails. You can try this patch, which is against OpenBSD's -current but should apply to 4.7 and 4.6 as well (and yeah, I know "goto" is bad, this is the minimum change to test the theory.) -- 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 Mon Nov 5 05:48:02 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sun, 4 Nov 2007 19:48:02 +0100 Subject: problem with sftp & huawei switches In-Reply-To: References: <20071104123929.GA9023@wq.cz> Message-ID: <20071104184803.15246.qmail@cdy.org> On Sun, Nov 04, 2007 at 10:44:54AM -0800, Darren Tucker wrote: > You can try this patch ..no patch. Please resend it for the archive. //Peter From milon at wq.cz Mon Nov 5 08:11:30 2007 From: milon at wq.cz (Milan Kocian) Date: Sun, 4 Nov 2007 22:11:30 +0100 Subject: problem with sftp & huawei switches In-Reply-To: References: <20071104123929.GA9023@wq.cz> Message-ID: <20071104211130.GC8380@wq.cz> On Sun, Nov 04, 2007 at 09:49:55AM -0700, Darren Tucker wrote: > Looks like your switch doesn't support the stat() operation, which > sftp(1) uses before the download and will abort the download if the > stat fails. probably yes. > > You can try this patch, which is against OpenBSD's -current but should > apply to 4.7 and 4.6 as well (and yeah, I know "goto" is bad, this is > the minimum change to test the theory.) > I tested it but the patch has no effect. (openssh version 4.6p1). regards, -- Milan Kocian From milon at wq.cz Mon Nov 5 08:27:44 2007 From: milon at wq.cz (Milan Kocian) Date: Sun, 4 Nov 2007 22:27:44 +0100 Subject: problem with sftp & huawei switches In-Reply-To: <20071104172722.30094.qmail@cdy.org> References: <20071104123929.GA9023@wq.cz> <20071104163707.19882.qmail@cdy.org> <20071104165216.GA8380@wq.cz> <20071104172722.30094.qmail@cdy.org> Message-ID: <20071104212744.GD8380@wq.cz> On Sun, Nov 04, 2007 at 06:27:22PM +0100, Peter Stuge wrote: > How about "ls ." and "ls /" ? > > The problem is that the path to the top of the filesystem does not > start with '/' but with 'f' (flash:) - I don't know if this is a > problem with OpenSSH or huawei software or maybe the filexfer drafts. > I don't know it too. But winscp (in wine) works (probably it's not so strict). Here are commands (openssh 4.6p1): sftp> ls . Couldn't stat remote file: Operation unsupported Can't ls: "flash:/." not found sftp> ls / Couldn't stat remote file: Operation unsupported Can't ls: "/" not found But 'ls *' is interesting ! (number of stat lines is equal to number of files in switch): sftp> ls * Couldn't stat remote file: Operation unsupported Couldn't stat remote file: Operation unsupported Couldn't stat remote file: Operation unsupported Couldn't stat remote file: Operation unsupported Couldn't stat remote file: Operation unsupported Couldn't stat remote file: Operation unsupported Couldn't stat remote file: Operation unsupported Can't ls: "flash:/*" not found sftp> mkdir aaa sftp> ls * Couldn't stat remote file: Operation unsupported Couldn't stat remote file: Operation unsupported Couldn't stat remote file: Operation unsupported Couldn't stat remote file: Operation unsupported Couldn't stat remote file: Operation unsupported Couldn't stat remote file: Operation unsupported Couldn't stat remote file: Operation unsupported Couldn't stat remote file: Operation unsupported Can't ls: "flash:/*" not found ON switch: dir Directory of unit1>flash:/ 1 -rw- 2450 Mar 09 2007 18:05:25 vrpcfg.def 2 (*) -rw- 2554 Nov 02 2007 23:11:43 vrpcfg.cfg 3 (b) -rw- 4833881 Feb 12 2007 17:57:46 s5600-vrp310-r1510p06.bin 4 (b) -rw- 801434 Feb 12 2007 18:00:02 hw-http3.1.5-0043.web 5 -rw- 337072 Mar 09 2007 17:55:09 s5600_v408.btm 6 (*) -rw- 4866775 Mar 09 2007 18:01:18 s5600-vrp310-r1510p12.bin 7 (*) -rw- 804260 Mar 09 2007 18:02:34 hw-http3.1.5-0049.web 15367 KB total (3982 KB free) AFTER mkdir: dir Directory of unit1>flash:/ 1 -rw- 2450 Mar 09 2007 18:05:25 vrpcfg.def 2 (*) -rw- 2554 Nov 02 2007 23:11:43 vrpcfg.cfg 3 (b) -rw- 4833881 Feb 12 2007 17:57:46 s5600-vrp310-r1510p06.bin 4 (b) -rw- 801434 Feb 12 2007 18:00:02 hw-http3.1.5-0043.web 5 -rw- 337072 Mar 09 2007 17:55:09 s5600_v408.btm 6 (*) -rw- 4866775 Mar 09 2007 18:01:18 s5600-vrp310-r1510p12.bin 7 (*) -rw- 804260 Mar 09 2007 18:02:34 hw-http3.1.5-0049.web 8 drw- - Nov 05 2007 04:53:34 aaa regards, -- Milan Kocian From dtucker at zip.com.au Mon Nov 5 06:18:50 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 4 Nov 2007 11:18:50 -0800 Subject: problem with sftp & huawei switches In-Reply-To: References: <20071104123929.GA9023@wq.cz> Message-ID: On Nov 4, 2007 10:44 AM, Darren Tucker wrote: > (resend, my previous reply was from a non-subscribed address) > > On Nov 4, 2007 4:39 AM, Milan Kocian wrote: > > I have the problem with sftp, I can't read files and dirs from huawei > > switches. I see: > > > > mm:/home/milon# sftp 10.1.1.30:vrpcfg.cfg . > > Connecting to 10.1.1.30... > > root at 10.1.1.30's password: > > Couldn't stat remote file: Operation unsupported > > File "flash:/flash:/vrpcfg.cfg" not found. > > Received disconnect from 10.1.1.30: 2: The connection is closed by > > SSH Server > > Current FSM is SSH_Main_Disconnect > > > Looks like your switch doesn't support the stat() operation, which > sftp(1) uses before the download and will abort the download if the > stat fails. > > You can try this patch, which is against OpenBSD's -current but should > apply to 4.7 and 4.6 as well (and yeah, I know "goto" is bad, this is > the minimum change to test the theory.) Oops, now with patch. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: openbsd-sftp-statxfer.patch.txt Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20071104/f4ce86e5/attachment.txt From arrummzen at gmail.com Mon Nov 5 13:58:50 2007 From: arrummzen at gmail.com (James Supancic) Date: Sun, 4 Nov 2007 18:58:50 -0800 Subject: Programs run over ssh aren't getting real ttys. Message-ID: <4eb2ea800711041858q34d8f4eenaa39d86e71b8b12e@mail.gmail.com> I use OpenSSH on a number of machines. If I connect to most of my machines and open a bash shell the first three file descriptors of bash are something like /dev/pts/6. On these machines OpenSSH is as good as a "real" terminal. However, I am putting together an embedded system and I must minimize the size of the installed system. I have OpenSSH working on this system but, when I connect and run bash the first three file descriptors are something like socket: [460]. The issue on this system is a number of tty related functions fail, greatly impairing my ability to use all but the simplest terminal programs. What is wrong? What must I do to enable programs run over ssh (such as bash) to get real pseudo-ttys and not simple sockets? Thank you for your time, James Steven Supancic III From bob at proulx.com Mon Nov 5 16:07:59 2007 From: bob at proulx.com (Bob Proulx) Date: Sun, 4 Nov 2007 22:07:59 -0700 Subject: Programs run over ssh aren't getting real ttys. In-Reply-To: <4eb2ea800711041858q34d8f4eenaa39d86e71b8b12e@mail.gmail.com> References: <4eb2ea800711041858q34d8f4eenaa39d86e71b8b12e@mail.gmail.com> Message-ID: <20071105050759.GA27652@dementia.proulx.com> James Supancic wrote: > I use OpenSSH on a number of machines. If I connect to most of my > machines and open a bash shell the first three file descriptors of > bash are something like /dev/pts/6. On these machines OpenSSH is as > good as a "real" terminal. On those machines ssh is allocated a pty device. A pty is a pseudo terminal emulating a classic serial port terminal. So your statement as good as a real terminal is pretty close to the truth if one considers a serial port to be a real terminal. Today however serial port terminals are quite rare and most people consider pty devices to be real terminals. > However, I am putting together an embedded system and I must minimize > the size of the installed system. I have OpenSSH working on this > system but, when I connect and run bash the first three file > descriptors are something like socket: [460]. In the case that you describe the input and output is being attached to a socket device and not a pty device. These are different types of device drivers in the kernel. pty devices support tty types of operations while sockets support a more limited set of operations. > The issue on this system is a number of tty related functions fail, > greatly impairing my ability to use all but the simplest terminal > programs. Yes. In that case 'ed' would be the editor of choice. :-) > What is wrong? What must I do to enable programs run over ssh (such as > bash) to get real pseudo-ttys and not simple sockets? This is really not an ssh question but a system question. In order to have tty/pty devices your system must support them. If the system does not support them then ssh can't create them magically. If you are working on an embedded system and this feature has been traded off to save space then there is really nothing that can be done in ssh about it. What is in your /dev/pty* and /dev/tty* files and directories? Is the system providing support for pty devices? When your sshd was build for the system was it built with support for ttys? Of course I have to make sure that you are running ssh in what would be an interactive mode. When running ssh with a command (e.g. ssh example.com somecommand) then no pty is allocated. You can specifically request ssh to allocate a pty with the -t option. That does not sound like your issue but it might be. Ensure that you are running ssh in a mode that would allocate a tty device. Bob From arrummzen at gmail.com Mon Nov 5 17:02:32 2007 From: arrummzen at gmail.com (James Supancic) Date: Sun, 4 Nov 2007 22:02:32 -0800 Subject: Programs run over ssh aren't getting real ttys. In-Reply-To: <20071105050759.GA27652@dementia.proulx.com> References: <4eb2ea800711041858q34d8f4eenaa39d86e71b8b12e@mail.gmail.com> <20071105050759.GA27652@dementia.proulx.com> Message-ID: <4eb2ea800711042202n1bee82eas6a806ba42ed4b664@mail.gmail.com> This embedded system is almost like a normal system (The only real difference is that it has no hard disk, and / is mounted on /dev/ram0). I'm using the same kernel as I use on several other systems as well as the same build of openssh. About /dev, it contains everything that the working systems do (I created it with cp -a /dev/* ./initird_mnt/dev/).... all the other systems use udev (rather than static nodes), is udev needed for pty support? Is there anyway to get openssh to use pttys when udev is not in use? Thank you for your time, Arrummzen From Karl-Heinz.Delzeit at jet-software.com Mon Nov 5 20:44:10 2007 From: Karl-Heinz.Delzeit at jet-software.com (Karl-Heinz.Delzeit) Date: Mon, 05 Nov 2007 10:44:10 +0100 (CET) Subject: pam_close_session for ssh as root Message-ID: <34034211601044@jet-software> Hello, I have a question. Why do I have pam_close_session with every user but not with root? Can I configure this in sshd_conf? Best regards Karl-Heinz Delzeit From milon at wq.cz Mon Nov 5 21:47:55 2007 From: milon at wq.cz (Milan Kocian) Date: Mon, 5 Nov 2007 11:47:55 +0100 Subject: Problem in mailing list ?! Message-ID: <20071105104755.GA4828@wq.cz> This is bug or feature ?! For all reply I got this message. ----- Forwarded message from Mail Delivery System ----- To: milon at wq.cz Subject: Mail delivery failed: returning message to sender From: Mail Delivery System Date: Sun, 4 Nov 2007 22:29:14 +0100 The original message was received at Sun, 4 Nov 2007 22:29:14 +0100 from milon at wq.cz by Acampo.net Error: No space left in the mailbox. >From openssh-unix-dev-bounces+snuggles=acampo.net at mindrot.org Sun Nov 4 22:28:53 2007 Return-Path: X-Envelope-To: Received: from natsu.mindrot.org (natsu.mindrot.org [203.209.195.154]) by mail.acampo.net (8.13.1/8.11.6) with ESMTP id lA4LSpQT011955 for ; Sun, 4 Nov 2007 22:28:52 +0100 Received: from natsu.mindrot.org (localhost [127.0.0.1]) by natsu.mindrot.org (Postfix) with ESMTP id 334C069C3E for ; Mon, 5 Nov 2007 08:28:51 +1100 (EST) X-Original-To: openssh-unix-dev-tmda Delivered-To: openssh-unix-dev-tmda at mindrot.org Received: by natsu.mindrot.org (Postfix, from userid 1001) id 5C7CB69B67; Mon, 5 Nov 2007 08:27:57 +1100 (EST) X-Original-To: openssh-unix-dev at mindrot.org Delivered-To: openssh-unix-dev at mindrot.org Received: by natsu.mindrot.org (Postfix, from userid 1002) id 2B73969AB4; Mon, 5 Nov 2007 08:27:56 +1100 (EST) X-Spam-Checker-Version: SpamAssassin 3.2.2 (2007-07-23) on natsu.mindrot.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.2 Received: from nt.wq.cz (fw.wq.cz [82.202.95.52]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by natsu.mindrot.org (Postfix) with ESMTP id EABDE69A8A for ; Mon, 5 Nov 2007 08:27:52 +1100 (EST) Received: from milon by nt.wq.cz with local (Exim 4.68) (envelope-from ) id 1Ion0S-0005sb-HN; Sun, 04 Nov 2007 22:27:44 +0100 Date: Sun, 4 Nov 2007 22:27:44 +0100 From: Milan Kocian To: openssh-unix-dev at mindrot.org Subject: Re: problem with sftp & huawei switches Message-ID: <20071104212744.GD8380 at wq.cz> References: <20071104123929.GA9023 at wq.cz> <20071104163707.19882.qmail at cdy.org> <20071104165216.GA8380 at wq.cz> <20071104172722.30094.qmail at cdy.org> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20071104172722.30094.qmail at cdy.org> User-Agent: Mutt/1.5.16 (2007-06-11) Cc: stuge-openssh-unix-dev at cdy.org X-BeenThere: openssh-unix-dev at mindrot.org X-Mailman-Version: 2.1.9 Precedence: list List-Id: Development of portable OpenSSH List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Sender: openssh-unix-dev-bounces+snuggles=acampo.net at mindrot.org Errors-To: openssh-unix-dev-bounces+snuggles=acampo.net at mindrot.org On Sun, Nov 04, 2007 at 06:27:22PM +0100, Peter Stuge wrote: > How about "ls ." and "ls /" ? > > The problem is that the path to the top of the filesystem does not > start with '/' but with 'f' (flash:) - I don't know if this is a > problem with OpenSSH or huawei software or maybe the filexfer drafts. > I don't know it too. But winscp (in wine) works (probably it's not so strict). Here are commands (openssh 4.6p1): sftp> ls . Couldn't stat remote file: Operation unsupported Can't ls: "flash:/." not found sftp> ls / Couldn't stat remote file: Operation unsupported Can't ls: "/" not found But 'ls *' is interesting ! (number of stat lines is equal to number of files in switch): sftp> ls * Couldn't stat remote file: Operation unsupported Couldn't stat remote file: Operation unsupported Couldn't stat remote file: Operation unsupported Couldn't stat remote file: Operation unsupported Couldn't stat remote file: Operation unsupported Couldn't stat remote file: Operation unsupported Couldn't stat remote file: Operation unsupported Can't ls: "flash:/*" not found sftp> mkdir aaa sftp> ls * Couldn't stat remote file: Operation unsupported Couldn't stat remote file: Operation unsupported Couldn't stat remote file: Operation unsupported Couldn't stat remote file: Operation unsupported Couldn't stat remote file: Operation unsupported Couldn't stat remote file: Operation unsupported Couldn't stat remote file: Operation unsupported Couldn't stat remote file: Operation unsupported Can't ls: "flash:/*" not found ON switch: dir Directory of unit1>flash:/ 1 -rw- 2450 Mar 09 2007 18:05:25 vrpcfg.def 2 (*) -rw- 2554 Nov 02 2007 23:11:43 vrpcfg.cfg 3 (b) -rw- 4833881 Feb 12 2007 17:57:46 s5600-vrp310-r1510p06.bin 4 (b) -rw- 801434 Feb 12 2007 18:00:02 hw-http3.1.5-0043.web 5 -rw- 337072 Mar 09 2007 17:55:09 s5600_v408.btm 6 (*) -rw- 4866775 Mar 09 2007 18:01:18 s5600-vrp310-r1510p12.bin 7 (*) -rw- 804260 Mar 09 2007 18:02:34 hw-http3.1.5-0049.web 15367 KB total (3982 KB free) AFTER mkdir: dir Directory of unit1>flash:/ 1 -rw- 2450 Mar 09 2007 18:05:25 vrpcfg.def 2 (*) -rw- 2554 Nov 02 2007 23:11:43 vrpcfg.cfg 3 (b) -rw- 4833881 Feb 12 2007 17:57:46 s5600-vrp310-r1510p06.bin 4 (b) -rw- 801434 Feb 12 2007 18:00:02 hw-http3.1.5-0043.web 5 -rw- 337072 Mar 09 2007 17:55:09 s5600_v408.btm 6 (*) -rw- 4866775 Mar 09 2007 18:01:18 s5600-vrp310-r1510p12.bin 7 (*) -rw- 804260 Mar 09 2007 18:02:34 hw-http3.1.5-0049.web 8 drw- - Nov 05 2007 04:53:34 aaa regards, -- Milan Kocian _______________________________________________ openssh-unix-dev mailing list openssh-unix-dev at mindrot.org https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev ----- End forwarded message ----- -- Milan Kocian From bob at proulx.com Tue Nov 6 03:44:01 2007 From: bob at proulx.com (Bob Proulx) Date: Mon, 5 Nov 2007 09:44:01 -0700 Subject: Problem in mailing list ?! In-Reply-To: <20071105104755.GA4828@wq.cz> References: <20071105104755.GA4828@wq.cz> Message-ID: <20071105164400.GA22338@dementia.proulx.com> Milan Kocian wrote: > This is bug or feature ?! For all reply I got this message. I assume that everyone who is posting a message is getting these bounces back. I get one to every one of my postings. This has been going on for quite a while now. It is annoying. This is not something that you as a subscriber can affect. It is an issue that can only be resolved by the mailing list owner by unsubscribing that address. There is a user subscribed to the mailing list that has two problems. Of course one is that their address is bouncing messages. But more importantly their MTA is incorrectly bouncing messages back to the message author and not the message sender. The MTA is ignoring the mail headers 'Precedence: list' which should discard any such notices and also ignoring the Errors-To: redirecting any such errors back to the mailing list management software should they be incorrectly generated. The MTA is so misconfigured that I would consider blacklisting it until it is fixed. I also assume that there is a problem with identifying the actual subscriber or the mailing list owner would already have removed them. I have reported this problem to the mailing list owner a couple of times previously but so far there has only been silence in return about the issue. Without VERP[1] and other techniques these problems have plagued mailing lists for years. I have seen people resort to sending an individual message to every subscriber in order to track down the offending address. Bob [1] http://en.wikipedia.org/wiki/Variable_envelope_return_path http://cr.yp.to/proto/verp.txt http://www.python.org/cgi-bin/faqw-mm.py?req=show&file=faq02.002.htp From Jefferson.Ogata at noaa.gov Tue Nov 6 06:28:00 2007 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Mon, 05 Nov 2007 19:28:00 +0000 Subject: Programs run over ssh aren't getting real ttys. In-Reply-To: <4eb2ea800711042202n1bee82eas6a806ba42ed4b664@mail.gmail.com> References: <4eb2ea800711041858q34d8f4eenaa39d86e71b8b12e@mail.gmail.com> <20071105050759.GA27652@dementia.proulx.com> <4eb2ea800711042202n1bee82eas6a806ba42ed4b664@mail.gmail.com> Message-ID: <472F6EC0.8030003@noaa.gov> On 2007-11-05 06:02, James Supancic wrote: > About /dev, it contains everything that the working systems do (I > created it with cp -a /dev/* ./initird_mnt/dev/).... all the other > systems use udev (rather than static nodes), is udev needed for pty > support? Is there anyway to get openssh to use pttys when udev is not > in use? It would help if you would state what operating system you are using. >From what you said earlier, I'm guessing you need to have the /dev/ptmx device present and mount the devpts filesystem on /dev/pts. Have you done both of these things? Maybe running sshd in the foreground with verbose logging would give you some additional information, or [sk]tracing it and watching for access to pty-related devices, including /dev/ptmx. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From dtucker at zip.com.au Tue Nov 6 03:39:28 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 5 Nov 2007 08:39:28 -0800 Subject: Programs run over ssh aren't getting real ttys. In-Reply-To: <4eb2ea800711042202n1bee82eas6a806ba42ed4b664@mail.gmail.com> References: <4eb2ea800711041858q34d8f4eenaa39d86e71b8b12e@mail.gmail.com> <20071105050759.GA27652@dementia.proulx.com> <4eb2ea800711042202n1bee82eas6a806ba42ed4b664@mail.gmail.com> Message-ID: On Nov 4, 2007 10:02 PM, James Supancic wrote: > This embedded system is almost like a normal system (The only real > difference is that it has no hard disk, and / is mounted on > /dev/ram0). I'm using the same kernel as I use on several other > systems as well as the same build of openssh. > > About /dev, it contains everything that the working systems do (I > created it with cp -a /dev/* ./initird_mnt/dev/).... all the other > systems use udev (rather than static nodes), is udev needed for pty > support? Is there anyway to get openssh to use pttys when udev is not > in use? Did you mount /dev/pts ? -- 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 rapier at psc.edu Tue Nov 6 08:50:10 2007 From: rapier at psc.edu (Chris Rapier) Date: Mon, 05 Nov 2007 16:50:10 -0500 Subject: Logit function problems Message-ID: <472F9012.2060400@psc.edu> I'm trying to collect some additional user information from the server using the 'logit' function. For example, I'm trying to get the cipher, mac, and compression status from kex.c in kex_chose_conf() with logit("SSH: %s;Ltype: Kex;Enc: %s;MAC: %s:Comp: %s", ctos ? "Server" : "Client", newkeys->enc.name, newkeys->mac.name, newkeys->comp.name); right after the similar debug statement. When I'm running the server in debug mode this line works fine. However, when I use it in normal mode this information doesn't print out at all. I'm assuming this has something to do with privilege separation as it works when its disabled. Is there, or can anyone think of, a way around this? As to why we are doing this: we need to get a handle on how people are using SSH. We're trying to get the version information, the ciphers used, and the bytes transferred. All of which are functioning just not in a useful way :) Chris From rapier at psc.edu Tue Nov 6 09:12:13 2007 From: rapier at psc.edu (Chris Rapier) Date: Mon, 05 Nov 2007 17:12:13 -0500 Subject: Logit function problems In-Reply-To: References: <472F9012.2060400@psc.edu> Message-ID: <472F953D.6090200@psc.edu> Darren Tucker wrote: >> Is there, or can anyone think of, a way around this? > > Make a /dev/log inside the privsep chroot and tell your syslogd to > listen on it in addition to the regular one (this is usually the -a > option to syslogd, but check your platform's doco). Wonderful! Thank you. From arrummzen at gmail.com Tue Nov 6 21:52:24 2007 From: arrummzen at gmail.com (James Supancic) Date: Tue, 6 Nov 2007 02:52:24 -0800 Subject: Programs run over ssh aren't getting real ttys. In-Reply-To: <472F6EC0.8030003@noaa.gov> References: <4eb2ea800711041858q34d8f4eenaa39d86e71b8b12e@mail.gmail.com> <20071105050759.GA27652@dementia.proulx.com> <4eb2ea800711042202n1bee82eas6a806ba42ed4b664@mail.gmail.com> <472F6EC0.8030003@noaa.gov> Message-ID: <4eb2ea800711060252n4a22e9caq8614704fc4eb917c@mail.gmail.com> I did some strace'ing and found that sshd was using the BSD style method for creating a pty. After adding support for that to my Linux kernel (LEGACY_PTYS=y) it started working (I guess I took a version of sshd that used BSD style ptys and put it on a kernel that didn't support them... bad combination). Thank you for your time, James Steven Supancic III From dtucker at zip.com.au Tue Nov 6 09:09:47 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 5 Nov 2007 14:09:47 -0800 Subject: Logit function problems In-Reply-To: <472F9012.2060400@psc.edu> References: <472F9012.2060400@psc.edu> Message-ID: On Nov 5, 2007 1:50 PM, Chris Rapier wrote: > I'm trying to collect some additional user information from the server > using the 'logit' function. For example, I'm trying to get the cipher, > mac, and compression status from kex.c in kex_chose_conf() with > logit("SSH: %s;Ltype: Kex;Enc: %s;MAC: %s:Comp: %s", > ctos ? "Server" : "Client", > newkeys->enc.name, > newkeys->mac.name, > newkeys->comp.name); > > right after the similar debug statement. When I'm running the server in > debug mode this line works fine. However, when I use it in normal mode > this information doesn't print out at all. I'm assuming this has > something to do with privilege separation as it works when its disabled. Right, your code is being run by the preauth privsep slave which is chrooted and thus does not have access to the syslog socket. > Is there, or can anyone think of, a way around this? Make a /dev/log inside the privsep chroot and tell your syslogd to listen on it in addition to the regular one (this is usually the -a option to syslogd, but check your platform's doco). -- 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 hamish at gmail.com Thu Nov 8 05:23:48 2007 From: hamish at gmail.com (Hamish Allan) Date: Wed, 7 Nov 2007 18:23:48 +0000 Subject: Patch: open port forwards from slave Message-ID: <597e7edb0711071023s52a875d8wddaf4ec0595b02d2@mail.gmail.com> On Oct 30, 5:57 am, Martin Forssen wrote: > So I patched openssh to make it possible to add port forwards via a slave process. Hi Martin, Thank you very much -- I've recently been meaning to write something like this myself (but then my firstborn arrived!) I was also wondering about making it "fully transparent", i.e., when the slave exits it would send a message to the master to remove the forwarding -- that is to say, the behaviour a user sees is the same whether or not they're using a ControlMaster. For this, "ssh -NL ..." would not exit straight away as per your patch, but block waiting for interrupts (although it wouldn't actually be fully transparent, because if the slave were SIGKILLed the forwarding would remain. Also it would maybe be kind of weird if a slave "ssh -fNL" left a blocking process). I would also find it useful to have a behaviour like your patch in which the slave adding the forwarding returns immediately, but I wonder if this might best be served using "-O" control messages as per Torsten's original patch, with commands for removing and listing forwardings too. Finally, I was thinking it might be nice if commands passed using "-O" and commands typed at the ~C "ssh>" prompt were the same commands. Do you have any opinion on interface best practice in this respect? Damien, did you have any thoughts on removing or listing forwardings in your planned approach? Best wishes, Hamish From djm at mindrot.org Thu Nov 8 10:54:54 2007 From: djm at mindrot.org (Damien Miller) Date: Thu, 8 Nov 2007 10:54:54 +1100 (EST) Subject: Programs run over ssh aren't getting real ttys. In-Reply-To: <4eb2ea800711060252n4a22e9caq8614704fc4eb917c@mail.gmail.com> References: <4eb2ea800711041858q34d8f4eenaa39d86e71b8b12e@mail.gmail.com> <20071105050759.GA27652@dementia.proulx.com> <4eb2ea800711042202n1bee82eas6a806ba42ed4b664@mail.gmail.com> <472F6EC0.8030003@noaa.gov> <4eb2ea800711060252n4a22e9caq8614704fc4eb917c@mail.gmail.com> Message-ID: On Tue, 6 Nov 2007, James Supancic wrote: > I did some strace'ing and found that sshd was using the BSD style > method for creating a pty. After adding support for that to my Linux > kernel (LEGACY_PTYS=y) it started working (I guess I took a version of > sshd that used BSD style ptys and put it on a kernel that didn't > support them... bad combination). OpenSSH prefers to use the openpty(3) function to allocate PTYs, so assuming this is being picked up on your system (check config.log) then it is your libc that is using the legacy method underneath. -d From djm at mindrot.org Thu Nov 8 11:01:37 2007 From: djm at mindrot.org (Damien Miller) Date: Thu, 8 Nov 2007 11:01:37 +1100 (EST) Subject: Problem in mailing list ?! In-Reply-To: <20071105104755.GA4828@wq.cz> References: <20071105104755.GA4828@wq.cz> Message-ID: I have unsubscribed this user. On Mon, 5 Nov 2007, Milan Kocian wrote: > This is bug or feature ?! For all reply I got this message. > > ----- Forwarded message from Mail Delivery System ----- > > To: milon at wq.cz > Subject: Mail delivery failed: returning message to sender > From: Mail Delivery System > Date: Sun, 4 Nov 2007 22:29:14 +0100 > > The original message was received at Sun, 4 Nov 2007 22:29:14 +0100 from milon at wq.cz by Acampo.net > > Error: No space left in the mailbox. From milon at wq.cz Thu Nov 8 21:07:29 2007 From: milon at wq.cz (Milan Kocian) Date: Thu, 8 Nov 2007 11:07:29 +0100 Subject: problem with sftp & huawei switches In-Reply-To: References: <20071104123929.GA9023@wq.cz> Message-ID: <20071108100729.GB10054@wq.cz> On Sun, Nov 04, 2007 at 09:49:55AM -0700, Darren Tucker wrote: > [...] > > Looks like your switch doesn't support the stat() operation, which > sftp(1) uses before the download and will abort the download if the > stat fails. > > You can try this patch, which is against OpenBSD's -current but should > apply to 4.7 and 4.6 as well (and yeah, I know "goto" is bad, this is > the minimum change to test the theory.) > Hello again, I tried to look at this in more detail. And here is ugly patch that works for me (in combination with yours). Here is log from sesssion: sftp> ls sftp> ls * aaa hw-http3.1.5-0043.web hw-http3.1.5-0049.web s5600-vrp310-r1510p06.bin s5600-vrp310-r1510p12.bin s5600_v408.btm vrpcfg.cfg vrpcfg.def sftp> get vrpcfg.cfg Fetching flash:/vrpcfg.cfg to vrpcfg.cfg Couldn't stat remote file: Operation unsupported flash:/vrpcfg.cfg 0% 2554 2.5KB/s 14948:06:54 sftp> So it seems to problem in glob. BTW. sftp client has a problem with names that contain spaces. --- openssh-4.3p2/openbsd-compat/glob.c 2005-11-10 07:02:22.000000000 +0100 +++ openssh-4.3p2.new/openbsd-compat/glob.c 2007-11-08 10:20:07.991115714 +0100 @@ -521,8 +521,8 @@ for (anymeta = 0;;) { if (*pattern == EOS) { /* End of pattern? */ *pathend = EOS; - if (g_lstat(pathbuf, &sb, pglob)) - return(0); + //if (g_lstat(pathbuf, &sb, pglob)) + // return(0); if (((pglob->gl_flags & GLOB_MARK) && pathend[-1] != SEP) && (S_ISDIR(sb.st_mode) || Regards, -- Milan Kocian From pwo at qimonda.com Sat Nov 10 03:37:47 2007 From: pwo at qimonda.com (Peter W. Osel) Date: Fri, 9 Nov 2007 11:37:47 -0500 Subject: HPN SSH Message-ID: <20071109163747.GG19269@rdusxi00.muc.infineon.com> Hello, I know that this has been asked before, just wanted to mention that I, too, would like to see the HPN SSH functionality incorporated in the standard OpenSSH. Would there be technical disadvantages integrating the changes? I know we are all pretty busy, but I would certainly spend time to help, e.g. with testing, documentation, etc. Cheers --pwo -- Peter W. Osel - http://pwo.de/ - pwo at pwo.de From rapier at psc.edu Sat Nov 10 04:31:53 2007 From: rapier at psc.edu (Chris Rapier) Date: Fri, 09 Nov 2007 12:31:53 -0500 Subject: HPN SSH In-Reply-To: <20071109163747.GG19269@rdusxi00.muc.infineon.com> References: <20071109163747.GG19269@rdusxi00.muc.infineon.com> Message-ID: <47349989.1090008@psc.edu> Peter W. Osel wrote: > Hello, > > I know that this has been asked before, just wanted to mention that I, > too, would like to see the HPN SSH functionality incorporated in the > standard OpenSSH. As the developer of the HPN-SSH patch I'd like to say that for *most* people the new version of OpenSSH will probably meet most of their needs. The developers increased in the internal window size to 2MB (which from what I can tell leads to a 1MB effective size in BDP equations). This *significantly* increases performance over the previous size. However, for people on faster networks this is still a bit small and HPN-SSH still has a role there (ex. On a patch between Switzerland and the US OpenSSH4.6 peaked at 0.69MB/s, OpenSSH peaked at 17.7MB/s and HPN-SSH at 58.3 MB/s(though it was CPU bound at this point)) > Would there be technical disadvantages integrating the changes? Initially there were performance problems with LAN transfers between two HPN enabled hosts. I think the latest version of the code (hpn12v19) has dealt with that. The larger issue is that for the majority of users - who tend to be poorly connected - the patch is probably overkill. That and the integration of the NONE cipher switch likely makes it dead in the water. Also, the HPN patch code is a bit of a moving target at this point. HPN13 is undergoing testing now and represents a more fundamental departure from the code base than even HPN12 did. I believe we've reached the limit of what buffer tuning can provide and we've been exploring other directions for optimization. Hopefully we'll have something available for a public test by January. > I know we are all pretty busy, but I would certainly spend time to help, > e.g. with testing, documentation, etc. I'll be continuing development on the HPN patch for sometime. I've brought on a couple more people. We have some interesting plans for the next couple of years but I believe, and I think the OpenSSH developers agree with me on this, that there probably won't be a wholesale integration in the foreseeable future. Honestly, this is likely for the best. It gives me a bit more freedom to try out different techniques which the devel team, if they find any of them useful, can integrate when they can. Chris Rapier http://www.psc.edu/networking/projects/hpn-ssh From rapier at psc.edu Sat Nov 10 07:18:48 2007 From: rapier at psc.edu (Chris Rapier) Date: Fri, 09 Nov 2007 15:18:48 -0500 Subject: Patch for progressmeter.c Message-ID: <4734C0A8.2020603@psc.edu> This is a small patch to progressmeter.c that provides peak throughput information. It adds a new field on the progress bar line that displays the 1sec throughput for the connection. At the end of the transfer it spits out the peak throughput seen. I found it useful in some testing situations and maybe someone else might find it handy. --- ../openssh-4.7p1.logging_features/progressmeter.c 2006-08-04 22:39:40.000000000 -0400 +++ progressmeter.c 2007-10-22 13:19:11.000000000 -0400 @@ -68,7 +68,9 @@ static time_t last_update; /* last progr static char *file; /* name of the file being transferred */ static off_t end_pos; /* ending position of transfer */ static off_t cur_pos; /* transfer position as of last refresh */ -static volatile off_t *counter; /* progress counter */ +static off_t last_pos; +static off_t max_delta_pos = 0; +static volatile off_t *counter; /* progress counter */ static long stalled; /* how long we have been stalled */ static int bytes_per_second; /* current speed in bytes per second */ static int win_size; /* terminal window size */ @@ -128,11 +130,16 @@ refresh_progress_meter(void) int hours, minutes, seconds; int i, len; int file_len; + off_t delta_pos; transferred = *counter - cur_pos; cur_pos = *counter; now = time(NULL); bytes_left = end_pos - cur_pos; + + delta_pos = cur_pos - last_pos; + if (delta_pos > max_delta_pos) + max_delta_pos = delta_pos; if (bytes_left > 0) elapsed = now - last_update; @@ -158,7 +165,7 @@ refresh_progress_meter(void) /* filename */ buf[0] = '\0'; - file_len = win_size - 35; + file_len = win_size - 45; if (file_len > 0) { len = snprintf(buf, file_len + 1, "\r%s", file); if (len < 0) @@ -175,7 +182,8 @@ refresh_progress_meter(void) percent = ((float)cur_pos / end_pos) * 100; else percent = 100; - snprintf(buf + strlen(buf), win_size - strlen(buf), + + snprintf(buf + strlen(buf), win_size - strlen(buf-8), " %3d%% ", percent); /* amount transferred */ @@ -188,6 +196,11 @@ refresh_progress_meter(void) (off_t)bytes_per_second); strlcat(buf, "/s ", win_size); + /* instantaneous rate */ + format_rate(buf + strlen(buf), win_size - strlen(buf), + delta_pos); + strlcat(buf, "/s ", win_size); + /* ETA */ if (!transferred) stalled += elapsed; @@ -224,6 +237,7 @@ refresh_progress_meter(void) atomicio(vwrite, STDOUT_FILENO, buf, win_size - 1); last_update = now; + last_pos = cur_pos; } /*ARGSUSED*/ @@ -270,6 +284,7 @@ void stop_progress_meter(void) { alarm(0); + char lbuf[10]; if (!can_output()) return; @@ -277,7 +292,9 @@ stop_progress_meter(void) /* Ensure we complete the progress */ if (cur_pos != end_pos) refresh_progress_meter(); - + + format_rate(lbuf, sizeof(lbuf), max_delta_pos); + printf("\nMax throughput: %s/s\n", lbuf); atomicio(vwrite, STDOUT_FILENO, "\n", 1); } From stuge-openssh-unix-dev at cdy.org Sun Nov 11 07:26:07 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sat, 10 Nov 2007 21:26:07 +0100 Subject: Patch for progressmeter.c In-Reply-To: <4734C0A8.2020603@psc.edu> References: <4734C0A8.2020603@psc.edu> Message-ID: <20071110202607.7301.qmail@cdy.org> On Fri, Nov 09, 2007 at 03:18:48PM -0500, Chris Rapier wrote: > This is a small patch to progressmeter.c that provides peak > throughput information. Maybe make a bug out of it - or it will probably be lost in the archives forever. :) //Peter From alon.barlev at gmail.com Sun Nov 11 06:43:52 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 10 Nov 2007 21:43:52 +0200 Subject: OpenSSH PKCS#11merge In-Reply-To: <9e0cf0bf0710132242k2a84ea74x644fdee327b780a2@mail.gmail.com> References: <200709250733.47491.alon.barlev@gmail.com> <9e0cf0bf0709290108h1a4be251t5943454f1c510adc@mail.gmail.com> <9e0cf0bf0709290636q5c87566fk5fa4107dad1fb8db@mail.gmail.com> <20070929142628.13104.qmail@cdy.org> <200709292009.39873.alon.barlev@gmail.com> <9e0cf0bf0710130913q7ef26c55gf3d9e391beef3b33@mail.gmail.com> <20071014035528.10383.qmail@cdy.org> <9e0cf0bf0710132242k2a84ea74x644fdee327b780a2@mail.gmail.com> Message-ID: <9e0cf0bf0711101143u943b32m88c8035f70942dea@mail.gmail.com> Peter, I am looking forward to continue working with you... Best Regards, Alon Bar-Lev. On 10/14/07, Alon Bar-Lev wrote: > On 10/14/07, Peter Stuge wrote: > > Hi, > > > > On Sat, Oct 13, 2007 at 06:13:22PM +0200, Alon Bar-Lev wrote: > > > I will be happy to continue working with you on this one... I hope > > > you did not give up :) > > > > Not given up, just no free time. Your previous message is still in my > > inbox, waiting for a reply. :\ > > Oh! > That's good. > > > > The major issue I need to know: > > > a. Do you think the agent protocol should be modified, as per my > > > explanation? > > > > Short answer: No > > Well... I will wait for your long answer, as this is the most > important issue and we need to make sure we understand how to > continue... > > > > c. Do you think the utility that shows available PKCS#11 ids be > > > part of ssh-add or separate utility? > > > > Hm, maybe separate? But I read between the lines that you weren't > > planning on implementing p11 support in ssh without the agent? > > I haven't done this because it is harder to maintain an external patch > with too much upstream modifications. If we going to merge it should > agentless mode should also be supported (The same as current OpenSC > specific implementation). > > > > d. I need allocation of options (short parameter names) for PKCS#11 > > > options. > > > > This is another good reason to investigate upstream attitude towards > > p11. After all, portable OpenSSH is just a derivative. > > OK. I will wait for a reply regarding this. > > I will have some more patience... :) > > Best Regards, > Alon Bar-Lev. > From addw at phcomp.co.uk Mon Nov 12 04:41:02 2007 From: addw at phcomp.co.uk (Alain Williams) Date: Sun, 11 Nov 2007 17:41:02 +0000 Subject: Patch to sshd match Message-ID: <20071111174102.GO7740@mint.phcomp.co.uk> Please find attached a patch against openssh-4.7p1 It extends the Match in sshd_config. The point is that it is sometimes easier (and more secure) to match on NOT something. A criterium may be preceded by ! which inverts the condition, thus: Match !Group sysadmins ForceCommand /usr/bin/sftp forces use of sftp on any user who is not a system administrator. A !! has the same effect as no ! - but I didn't document that. I am looking at sftp, extend it: * read a config file - optionally * commands to restrict a user to their $HOME. -- Alain Williams Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Chairman of UKUUG: http://www.ukuug.org/ #include -------------- next part -------------- --- servconf.c.orig 2007-05-20 06:03:16.000000000 +0100 +++ servconf.c 2007-11-11 17:21:38.000000000 +0000 @@ -498,13 +498,21 @@ * PermittedChannelRequests session,forwarded-tcpip */ +/* Check if user is in the comma separated group list grps. Invert condition if not. + * line is the config file line. + * Return: + * 1 match + * 0 not match + * -1 error + */ static int -match_cfg_line_group(const char *grps, int line, const char *user) +match_cfg_line_group(const char *grps, int line, const char *user, int not) { int result = 0; u_int ngrps = 0; char *arg, *p, *cp, *grplist[MAX_MATCH_GROUPS]; struct passwd *pw; + char* notstr = not ? "!" : ""; /* * Even if we do not have a user yet, we still need to check for @@ -529,12 +537,12 @@ } else if (ga_init(pw->pw_name, pw->pw_gid) == 0) { debug("Can't Match group because user %.100s not in any group " "at line %d", user, line); - } else if (ga_match(grplist, ngrps) != 1) { - debug("user %.100s does not match group %.100s at line %d", - user, arg, line); + } else if (ga_match(grplist, ngrps) == not) { + debug("user %.100s does not match %sgroup %.100s at line %d", + user, notstr, arg, line); } else { - debug("user %.100s matched group %.100s at line %d", user, - arg, line); + debug("user %.100s matched %sgroup %.100s at line %d", user, + notstr, arg, line); result = 1; } out: @@ -550,6 +558,8 @@ int result = 1; char *arg, *attrib, *cp = *condition; size_t len; + int not = 0; + char* notstr; if (user == NULL) debug3("checking syntax for 'Match %s'", cp); @@ -559,6 +569,13 @@ address ? address : "(null)"); while ((attrib = strdelim(&cp)) && *attrib != '\0') { + while(*attrib == '!') { /* Parse a '!' to mean invert the condition */ + not ^= 1; + attrib++; + } + if(*attrib == '\0') /* Maybe a ! was followed by white space */ + continue; + notstr = not ? "!" : ""; /* For debug */ if ((arg = strdelim(&cp)) == NULL || *arg == '\0') { error("Missing Match criteria for %s", attrib); return -1; @@ -567,15 +584,16 @@ if (strcasecmp(attrib, "user") == 0) { if (!user) { result = 0; + not = 0; continue; } - if (match_pattern_list(user, arg, len, 0) != 1) + if (match_pattern_list(user, arg, len, 0) == not) result = 0; else - debug("user %.100s matched 'User %.100s' at " - "line %d", user, arg, line); + debug("user %.100s matched '%sUser %.100s' at " + "line %d", user, notstr, arg, line); } else if (strcasecmp(attrib, "group") == 0) { - switch (match_cfg_line_group(arg, line, user)) { + switch (match_cfg_line_group(arg, line, user, not)) { case -1: return -1; case 0: @@ -584,27 +602,30 @@ } else if (strcasecmp(attrib, "host") == 0) { if (!host) { result = 0; + not = 0; continue; } - if (match_hostname(host, arg, len) != 1) + if (match_hostname(host, arg, len) == not) result = 0; else - debug("connection from %.100s matched 'Host " - "%.100s' at line %d", host, arg, line); + debug("connection from %.100s matched '%sHost " + "%.100s' at line %d", host, notstr, arg, line); } else if (strcasecmp(attrib, "address") == 0) { if (!address) { result = 0; + not = 0; continue; } - if (match_hostname(address, arg, len) != 1) + if (match_hostname(address, arg, len) == not) result = 0; else - debug("connection from %.100s matched 'Address " - "%.100s' at line %d", address, arg, line); + debug("connection from %.100s matched '%sAddress " + "%.100s' at line %d", address, notstr, arg, line); } else { error("Unsupported Match attribute %s", attrib); return -1; } + not = 0; /* Reset for next condition */ } if (user != NULL) debug3("match %sfound", result ? "" : "not "); --- sshd_config.5.orig 2007-06-11 05:07:13.000000000 +0100 +++ sshd_config.5 2007-11-11 17:17:16.000000000 +0000 @@ -529,6 +529,16 @@ .Cm X11Forwarding , and .Cm X11UseLocalHost . +.Pp +A criterium may be preceded by +.Cm ! +which inverts the condition, thus: +.pP +.Bl -tag -width Ds -compact -offset indent +.It Match !Group sysadmins +.It ForceCommand /usr/bin/sftp +.El +forces use of sftp on any user who is not a system administrator. .It Cm MaxAuthTries Specifies the maximum number of authentication attempts permitted per connection. From addw at phcomp.co.uk Mon Nov 12 10:29:53 2007 From: addw at phcomp.co.uk (Alain Williams) Date: Sun, 11 Nov 2007 23:29:53 +0000 Subject: ftp-server patch - restrict user to directory Message-ID: <20071111232953.GP7740@mint.phcomp.co.uk> Hi, please find a patch against openssh-4.7p1 This patch: 1) Allows for an optional configuration file 2) Allows a user to be restricted to a directory and it's children. Enjoy -- Alain Williams Linux Consultant - Mail systems, Web sites, Networking, Programmer, IT Lecturer. +44 (0) 787 668 0256 http://www.phcomp.co.uk/ Parliament Hill Computers Ltd. Registration Information: http://www.phcomp.co.uk/contact.php Chairman of UKUUG: http://www.ukuug.org/ #include -------------- next part -------------- --- sftp-server.c.orig 2007-05-20 06:09:05.000000000 +0100 +++ sftp-server.c 2007-11-11 23:25:29.000000000 +0000 @@ -31,7 +31,6 @@ #include #include #include -#include #include #include #include @@ -44,6 +43,7 @@ #include "sftp.h" #include "sftp-common.h" +#include "pathnames.h" /* helper */ #define get_int64() buffer_get_int64(&iqueue); @@ -74,6 +74,141 @@ Attrib attrib; }; +/* Name of the server configuration file. */ +char *config_file_name = _PATH_SFTP_CONFIG_FILE; + +/* If not NULL restrict the user to under this directory */ +char* RestrictDirectory; + +/* **** Start parsing config file code **** */ + +/* Read the optional config file. If mandatory the file must exist. + * Exit on error. + */ +static void +load_sftp_config(char* file_name, int mandatory) +{ + char line[1024], *cp, *arg, *opt; + FILE *f; + int lineno = 0; + + debug2("%s: filename %s mandatory %d", __func__, file_name, mandatory); + if ((f = fopen(file_name, "r")) == NULL) { + if( ! mandatory) /* config file may be optional */ + return; + + perror(file_name); + exit(1); + } + + /* Read a line at a time */ + while(fgets(line, sizeof(line), f)) { + lineno++; + cp = line + strspn(line, " \t"); + if(*cp == '#' || *cp == '\0' || *cp == '\n') /* Ignore comments and empty lines */ + continue; + if( ! (arg = strchr(cp, '\n'))) + fatal("Line %d in file %.100s too long", lineno, file_name); + *arg = '\0'; + + opt = strdelim(&cp); /* Get directive */ + debug3("opt='%s' rest='%s'\n", opt, cp); + + /* Find what argument we have */ + if( ! strcmp(opt, "RestrictDirectory")) { + RestrictDirectory = xstrdup(strdelim(&cp)); /* Get pathname */ + if(cp) + fatal("Line %d in file %.100s: too many arguments to %s", lineno, file_name, opt); + } else + fatal("Line %d in file %.100s: unknown directive: %.100s", lineno, file_name, opt); + } + + /* All done */ + fclose(f); + debug2("%s: done config, lines %d", __func__, lineno); +} + +/* **** End parsing config file code **** */ + +/* Set up options once we know who the user is. + * Look at pw for details. + */ +static void +set_user_opts(void) +{ + /* Does the restict directory start "~/xxx" or have the value "~" ? + * If so relace with the user's home directory. + * Don't attempt to expand arbitrary "~user/". + * If a directory has a trailing "/" then listings of that directory will not be allowed. + */ + if(RestrictDirectory && RestrictDirectory[0] == '~' && + (RestrictDirectory[1] == '/' || RestrictDirectory[1] == '\0')) { + char* tmp = xmalloc(strlen(RestrictDirectory) + strlen(pw->pw_dir)); + strcat(strcpy(tmp, pw->pw_dir), RestrictDirectory + 1); + free(RestrictDirectory); + RestrictDirectory = tmp; + } + + /* It is possible, if unlikely, that the restricted directory will have been specified with + * a symlink or .. in it. That will totally blow comparisions in allowed_access(). Resolve this. + */ + if(RestrictDirectory) { + char resolvedname[MAXPATHLEN]; + char* tmp; + + if( ! realpath(RestrictDirectory, resolvedname)) + fatal("Can't get realpath on %.100s as: %s", RestrictDirectory, strerror(errno)); + + tmp = xstrdup(resolvedname); + free(RestrictDirectory); + RestrictDirectory = tmp; + } +} + +/* Check that the user is allowed to access the path for the purpose reason. + * This implements the RestrictDirectory option. + * Return true if allowed. + * Log failed access attempts. + */ +static int +allowed_access(char* path, char* reason) +{ + char resolvedname[MAXPATHLEN]; + int restlen; + + if( ! RestrictDirectory) /* No restriction, allow */ + return(1); + + /* If we can't convert the name - deem it an error */ + if( ! realpath(path, resolvedname)) { + error("Can't get realpath on %.100s as: %s", path, strerror(errno)); + return(0); + } + + restlen = strlen(RestrictDirectory); + + /* Allow the directory itself. + * Trap where the canny user with a '~/' restriction tries to list '/home/joe/' - ie adds the '/'. + */ + if( ! strcmp(resolvedname, RestrictDirectory) && RestrictDirectory[restlen - 1] != '/') + return(1); + + /* Find length before '/' of restricting directory */ + if(RestrictDirectory[restlen - 1] == '/') + restlen--; + + /* If the first bit matches it is acceptable. + * Check for a '/' else ~fred will allow access to ~freddy. + */ + if( ! strncmp(resolvedname, RestrictDirectory, restlen) && + resolvedname[restlen] == '/') + return(1); + + error("Restricted access, %s disallowed for %.100s", reason, path); + + return(0); +} + static int errno_to_portable(int unixerrno) { @@ -813,20 +948,24 @@ id = get_int(); path = get_string(NULL); debug3("request %u: opendir", id); - logit("opendir \"%s\"", path); - dirp = opendir(path); - if (dirp == NULL) { - status = errno_to_portable(errno); - } else { - handle = handle_new(HANDLE_DIR, path, 0, dirp); - if (handle < 0) { - closedir(dirp); + + if(allowed_access(path, "opendir")) { /* RestrictDirectory ? */ + logit("opendir \"%s\"", path); + dirp = opendir(path); + if (dirp == NULL) { + status = errno_to_portable(errno); } else { - send_handle(id, handle); - status = SSH2_FX_OK; + handle = handle_new(HANDLE_DIR, path, 0, dirp); + if (handle < 0) { + closedir(dirp); + } else { + send_handle(id, handle); + status = SSH2_FX_OK; + } } + } else + status = errno_to_portable(EPERM); - } if (status != SSH2_FX_OK) send_status(id, status); xfree(path); @@ -899,9 +1038,14 @@ id = get_int(); name = get_string(NULL); debug3("request %u: remove", id); - logit("remove name \"%s\"", name); - ret = unlink(name); - status = (ret == -1) ? errno_to_portable(errno) : SSH2_FX_OK; + + if(allowed_access(name, "remove")) { /* RestrictDirectory ? */ + logit("remove name \"%s\"", name); + ret = unlink(name); + status = (ret == -1) ? errno_to_portable(errno) : SSH2_FX_OK; + } else + status = errno_to_portable(EPERM); + send_status(id, status); xfree(name); } @@ -920,9 +1064,13 @@ mode = (a->flags & SSH2_FILEXFER_ATTR_PERMISSIONS) ? a->perm & 0777 : 0777; debug3("request %u: mkdir", id); - logit("mkdir name \"%s\" mode 0%o", name, mode); - ret = mkdir(name, mode); - status = (ret == -1) ? errno_to_portable(errno) : SSH2_FX_OK; + if(allowed_access(name, "mkdir")) { /* RestrictDirectory ? */ + logit("mkdir name \"%s\" mode 0%o", name, mode); + ret = mkdir(name, mode); + status = (ret == -1) ? errno_to_portable(errno) : SSH2_FX_OK; + } else + status = errno_to_portable(EPERM); + send_status(id, status); xfree(name); } @@ -937,9 +1085,13 @@ id = get_int(); name = get_string(NULL); debug3("request %u: rmdir", id); - logit("rmdir name \"%s\"", name); - ret = rmdir(name); - status = (ret == -1) ? errno_to_portable(errno) : SSH2_FX_OK; + if(allowed_access(name, "rmdir")) { /* RestrictDirectory ? */ + logit("rmdir name \"%s\"", name); + ret = rmdir(name); + status = (ret == -1) ? errno_to_portable(errno) : SSH2_FX_OK; + } else + status = errno_to_portable(EPERM); + send_status(id, status); xfree(name); } @@ -950,6 +1102,7 @@ char resolvedname[MAXPATHLEN]; u_int32_t id; char *path; + static int num_realpaths = 0; id = get_int(); path = get_string(NULL); @@ -958,15 +1111,24 @@ path = xstrdup("."); } debug3("request %u: realpath", id); - verbose("realpath \"%s\"", path); - if (realpath(path, resolvedname) == NULL) { - send_status(id, errno_to_portable(errno)); - } else { - Stat s; - attrib_clear(&s.attrib); - s.name = s.long_name = resolvedname; - send_names(id, 1, &s); - } + + /* RestrictDirectory ? - could be used to probe the file system. + * Need to allow on realpath since that is done automatically to get the $HOME. + * The user must then cd before s/he can do anything else. + */ + if(num_realpaths++ == 0 || allowed_access(path, "realpath")) { + verbose("realpath \"%s\"", path); + if (realpath(path, resolvedname) == NULL) { + send_status(id, errno_to_portable(errno)); + } else { + Stat s; + attrib_clear(&s.attrib); + s.name = s.long_name = resolvedname; + send_names(id, 1, &s); + } + } else + send_status(id, errno_to_portable(EPERM)); + xfree(path); } @@ -982,6 +1144,14 @@ oldpath = get_string(NULL); newpath = get_string(NULL); debug3("request %u: rename", id); + + if( ! allowed_access(oldpath, "rename") || ! allowed_access(newpath, "rename")) { /* RestrictDirectory ? */ + send_status(id, errno_to_portable(EPERM)); + xfree(oldpath); + xfree(newpath); + return; + } + logit("rename old \"%s\" new \"%s\"", oldpath, newpath); status = SSH2_FX_FAILURE; if (lstat(oldpath, &sb) == -1) @@ -1038,17 +1208,22 @@ id = get_int(); path = get_string(NULL); debug3("request %u: readlink", id); - verbose("readlink \"%s\"", path); - if ((len = readlink(path, buf, sizeof(buf) - 1)) == -1) - send_status(id, errno_to_portable(errno)); - else { - Stat s; - - buf[len] = '\0'; - attrib_clear(&s.attrib); - s.name = s.long_name = buf; - send_names(id, 1, &s); - } + + if(allowed_access(path, "readlink")) { /* RestrictDirectory ? */ + verbose("readlink \"%s\"", path); + if ((len = readlink(path, buf, sizeof(buf) - 1)) == -1) + send_status(id, errno_to_portable(errno)); + else { + Stat s; + + buf[len] = '\0'; + attrib_clear(&s.attrib); + s.name = s.long_name = buf; + send_names(id, 1, &s); + } + } else + send_status(id, errno_to_portable(EPERM)); + xfree(path); } @@ -1063,10 +1238,15 @@ oldpath = get_string(NULL); newpath = get_string(NULL); debug3("request %u: symlink", id); - logit("symlink old \"%s\" new \"%s\"", oldpath, newpath); - /* this will fail if 'newpath' exists */ - ret = symlink(oldpath, newpath); - status = (ret == -1) ? errno_to_portable(errno) : SSH2_FX_OK; + + if( ! allowed_access(oldpath, "symlink") || ! allowed_access(newpath, "symlink")) { /* RestrictDirectory ? */ + logit("symlink old \"%s\" new \"%s\"", oldpath, newpath); + /* this will fail if 'newpath' exists */ + ret = symlink(oldpath, newpath); + status = (ret == -1) ? errno_to_portable(errno) : SSH2_FX_OK; + } else + status = errno_to_portable(EPERM); + send_status(id, status); xfree(oldpath); xfree(newpath); @@ -1203,7 +1383,7 @@ extern char *__progname; fprintf(stderr, - "usage: %s [-he] [-l log_level] [-f log_facility]\n", __progname); + "usage: %s [-he] [-l log_level] [-F config_file] [-f log_facility]\n", __progname); exit(1); } @@ -1215,6 +1395,7 @@ ssize_t len, olen, set_size; SyslogFacility log_facility = SYSLOG_FACILITY_AUTH; char *cp, buf[4*4096]; + int config_file_mandatory = 0; extern char *optarg; extern char *__progname; @@ -1225,7 +1406,7 @@ __progname = ssh_get_progname(argv[0]); log_init(__progname, log_level, log_facility, log_stderr); - while (!skipargs && (ch = getopt(argc, argv, "C:f:l:che")) != -1) { + while (!skipargs && (ch = getopt(argc, argv, "C:f:F:l:che")) != -1) { switch (ch) { case 'c': /* @@ -1247,12 +1428,18 @@ if (log_level == SYSLOG_FACILITY_NOT_SET) error("Invalid log facility \"%s\"", optarg); break; + case 'F': + config_file_name = optarg; + config_file_mandatory = 1; /* Since it is specified, it is a must */ + break; case 'h': default: usage(); } } + load_sftp_config(config_file_name, config_file_mandatory); + log_init(__progname, log_level, log_facility, log_stderr); if ((cp = getenv("SSH_CONNECTION")) != NULL) { @@ -1271,6 +1458,8 @@ logit("session opened for local user %s from [%s]", pw->pw_name, client_addr); + set_user_opts(); + handle_init(); in = dup(STDIN_FILENO); --- sftp-server.8.orig 2007-06-05 09:27:13.000000000 +0100 +++ sftp-server.8 2007-11-11 23:15:51.000000000 +0000 @@ -60,6 +60,12 @@ The possible values are: DAEMON, USER, AUTH, LOCAL0, LOCAL1, LOCAL2, LOCAL3, LOCAL4, LOCAL5, LOCAL6, LOCAL7. The default is AUTH. +.It Fl F Ar configfile +Specifies a configuration file that shall be used, if this file is not found +a fatal error is generated. +The defualt file is +.Xr /etc/ssh/sftp_config +if this file is not found no error is generated. .It Fl l Ar log_level Specifies which messages will be logged by .Nm . @@ -72,6 +78,27 @@ DEBUG2 and DEBUG3 each specify higher levels of debugging output. The default is ERROR. .El +.Sh CONFIGURATION FILE FORMAT +The file contains keyword-argument pairs, one per line. +Lines starting with +.Ql # +and empty lines are interpreted as comments. +Arguments may optionally be enclosed in double quotes +.Pq \&" +in order to represent arguments containing spaces. +.Bl -tag -width Ds +.It Cm RestrictDirectory +Restrict the user's activities to the argument directory and the directories below it. +If the directory is +.Ql ~ +the user's home directory is used. +Expansion of arbitrary +.Ql ~user/ +is not done. +If a directory has a trailing +.Ql / +then listings of that directory will not be allowed. +.El .Sh SEE ALSO .Xr sftp 1 , .Xr ssh 1 , From Jefferson.Ogata at noaa.gov Mon Nov 12 10:52:59 2007 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Sun, 11 Nov 2007 23:52:59 +0000 Subject: ftp-server patch - restrict user to directory In-Reply-To: <20071111232953.GP7740@mint.phcomp.co.uk> References: <20071111232953.GP7740@mint.phcomp.co.uk> Message-ID: <473795DB.7060800@noaa.gov> On 2007-11-11 23:29, Alain Williams wrote: > /* It is possible, if unlikely, that the restricted directory will have been specified with > * a symlink or .. in it. That will totally blow comparisions in allowed_access(). Resolve this. > */ The likelihood that the restricted directory path will contain a symlink or .. is completely unknown to your patch. In some organizations, the likelihood may be as high as 1. realpath() requires readability on all parent directories, which is also not guaranteed. You could get closer to your desired behavior by doing a stat on the restricted directory, then iteratively calling stat(2) the directory containing the resolved name and checking for identity (device+inode) with the restricted directory, working your way back directory components until either identity is found (allow) or the resolved path is empty (disallow). This emulates what realpath(3) does without having to generate the actual return path, and works because you can stat(2) a directory you can traverse but not read. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From rapier at psc.edu Mon Nov 12 14:09:03 2007 From: rapier at psc.edu (chris rapier) Date: Sun, 11 Nov 2007 22:09:03 -0500 Subject: Patch for progressmeter.c In-Reply-To: <20071110202607.7301.qmail@cdy.org> References: <4734C0A8.2020603@psc.edu> <20071110202607.7301.qmail@cdy.org> Message-ID: <4737C3CF.4070207@psc.edu> Good point. Mostly I'm not sure it needs inclusion in the base but I will say it was useful a couple of situations I was dealing with. Peter Stuge wrote: > On Fri, Nov 09, 2007 at 03:18:48PM -0500, Chris Rapier wrote: > >>This is a small patch to progressmeter.c that provides peak >>throughput information. > > > Maybe make a bug out of it - or it will probably be lost in the > archives forever. :) > > > //Peter > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From hramrach at centrum.cz Tue Nov 13 06:13:42 2007 From: hramrach at centrum.cz (Michal Suchanek) Date: Mon, 12 Nov 2007 20:13:42 +0100 Subject: Bug#447153: /usr/bin/scp: Fails to notice write errors In-Reply-To: <20071112183354.GF13244@riva.ucam.org> References: <20071018133227.32321.90343.reportbug@nc4010.nodomain> <20071018135937.GN13244@riva.ucam.org> <20071112183354.GF13244@riva.ucam.org> Message-ID: Hello On 12/11/2007, Colin Watson wrote: Thanks for looking into this. > Here's a reduced test program that exhibits the same problem as scp when > run with a filename on a CIFS mount of a full filesystem: > > #include > #include > #include > #include > #include > #include > > int main(int argc, char **argv) > { > int fd; > if (argc <= 1) { > fprintf(stderr, "Usage: %s filename\n", argv[0]); > return 1; > } > fd = open(argv[1], O_CREAT | O_WRONLY, 0644); > if (fd < 0) { > perror("open"); > return 1; > } > while (write(fd, "x", 1) < 1) { > if (errno == EINTR) > continue; > perror("write"); > return 1; > } > if (ftruncate(fd, 1) < 0) { > perror("ftruncate"); > return 1; > } > if (close(fd) < 0) { > perror("close"); > return 1; > } > return 0; > } > > No error, but you end up with a one-byte hole rather than either (a) "x" > or (b) an error. If you leave out the ftruncate, then close returns > ENOSPC. In either case, you get "CIFS VFS: Write2 ret -28, written = 0" > in syslog, but the error code doesn't make it to userspace if there's an > ftruncate between write and close. Is this a CIFS bug? I can't find > anything in the ftruncate documentation that suggests it is allowed to > do this; I think that if write claims to have written all the bytes then > userspace ought to be able to assume that ftruncate(fd, st_size) is a > no-op. > > > To openssh-unix-dev: does anyone think this is worth a workaround? The > ftruncate seems rather unnecessary if we've already written out the > required number of bytes anyway. I've attached a patch which only does > it if that isn't the case (although I have some trouble seeing how we > could ever get to the ftruncate without either writing the required > number of bytes or encountering a write error). If people think it's a > good idea I'll file it in Bugzilla. > I do not know the scp code so I might be missing something. However, truncating the file might be necessary when there is already a file, and it was originally longer. It looks like a bug either in the kernel or in ftruncate documentation. It is certainly true that the write error should get reported at some point if it occurs, and a filesystem that chooses to not return it on write() should save the errors for close(). However, using ftruncate() on the file does, in some sense, successfully extend the file to the desired length. It looks like such mixing of calls was not expected by the fs driver, and may not be well defined in general. I would suggest closing the file, and if it needs truncating, reopen and truncate it (or do some voodoo with duplicated fds if possible). The file could also be truncated in advance, but that would make dealing with files that change during transfer even harder. Although one cannot guarantee any sane results in that case anyway. Thanks Michal From cjwatson at debian.org Tue Nov 13 05:33:54 2007 From: cjwatson at debian.org (Colin Watson) Date: Mon, 12 Nov 2007 18:33:54 +0000 Subject: Bug#447153: /usr/bin/scp: Fails to notice write errors In-Reply-To: References: <20071018133227.32321.90343.reportbug@nc4010.nodomain> <20071018135937.GN13244@riva.ucam.org> Message-ID: <20071112183354.GF13244@riva.ucam.org> # For linux-cifs-client: this paragraph is for the Debian bug tracking # system control robot. Please ignore it. reassign 447153 linux-2.6 thanks On Fri, Oct 19, 2007 at 12:03:01AM +0200, Michal Suchanek wrote: > On 18/10/2007, Colin Watson wrote: > > On Thu, Oct 18, 2007 at 03:32:27PM +0200, Hramrach wrote: > > > When copying to a cifs share scp fails to notice write errors and > > > happily continues copying when there is no disk space. > > > Note that cifs probably only reports these errors on close(), not > > > write(). > > cp reports the error: > > cp firefox-2.0.0.4.tar.gz /mnt/ > cp: closing `/mnt/firefox-2.0.0.4.tar.gz': No space left on device > > scp produces files of the same size with different content for small > files and truncated (although not always zero) files for larger files, > and notices no problem. I've reproduced this locally and I believe it's a kernel bug. Here's an strace excerpt: [pid 25301] <... read resumed> "C", 1) = 1 [pid 25301] read(0, "0", 1) = 1 [pid 25301] read(0, "6", 1) = 1 [pid 25301] read(0, "4", 1) = 1 [pid 25301] read(0, "4", 1) = 1 [pid 25301] read(0, " ", 1) = 1 [pid 25301] read(0, "1", 1) = 1 [pid 25301] read(0, "4", 1) = 1 [pid 25301] read(0, "1", 1) = 1 [pid 25301] read(0, " ", 1) = 1 [pid 25301] read(0, "t", 1) = 1 [pid 25301] read(0, ".", 1) = 1 [pid 25301] read(0, "p", 1) = 1 [pid 25301] read(0, "y", 1) = 1 [pid 25301] read(0, "\n", 1) = 1 [pid 25301] stat64("cifstest-mount//t.py", {st_mode=S_IFREG|0744, st_size=141, ...}) = 0 [pid 25301] open("cifstest-mount//t.py", O_WRONLY|O_CREAT|O_LARGEFILE, 0644) = 3 [pid 25301] write(1, "\0", 1) = 1 [pid 25301] fstat64(3, [pid 25301] <... fstat64 resumed> {st_mode=S_IFREG|0744, st_size=141, ...}) = 0 [pid 25301] read(0, [pid 25301] <... read resumed> "import gtk\nimport locale\nlocale."..., 141) = 141 [pid 25301] write(3, "import gtk\nimport locale\nlocale."..., 141) = 141 [pid 25301] ftruncate64(3, 141) = 0 [pid 25301] close(3) = 0 [pid 25301] read(0, "\0", 1) = 1 [pid 25301] write(1, "\0", 1) = 1 [pid 25301] read(0, [pid 25301] <... read resumed> "", 1) = 0 [pid 25301] exit_group(0) = ? As you can see, it simply isn't getting any error back from the kernel. Here's a reduced test program that exhibits the same problem as scp when run with a filename on a CIFS mount of a full filesystem: #include #include #include #include #include #include int main(int argc, char **argv) { int fd; if (argc <= 1) { fprintf(stderr, "Usage: %s filename\n", argv[0]); return 1; } fd = open(argv[1], O_CREAT | O_WRONLY, 0644); if (fd < 0) { perror("open"); return 1; } while (write(fd, "x", 1) < 1) { if (errno == EINTR) continue; perror("write"); return 1; } if (ftruncate(fd, 1) < 0) { perror("ftruncate"); return 1; } if (close(fd) < 0) { perror("close"); return 1; } return 0; } No error, but you end up with a one-byte hole rather than either (a) "x" or (b) an error. If you leave out the ftruncate, then close returns ENOSPC. In either case, you get "CIFS VFS: Write2 ret -28, written = 0" in syslog, but the error code doesn't make it to userspace if there's an ftruncate between write and close. Is this a CIFS bug? I can't find anything in the ftruncate documentation that suggests it is allowed to do this; I think that if write claims to have written all the bytes then userspace ought to be able to assume that ftruncate(fd, st_size) is a no-op. To openssh-unix-dev: does anyone think this is worth a workaround? The ftruncate seems rather unnecessary if we've already written out the required number of bytes anyway. I've attached a patch which only does it if that isn't the case (although I have some trouble seeing how we could ever get to the ftruncate without either writing the required number of bytes or encountering a write error). If people think it's a good idea I'll file it in Bugzilla. Thanks, -- Colin Watson [cjwatson at debian.org] -------------- next part -------------- A non-text attachment was scrubbed... Name: scp-ftruncate.patch Type: text/x-diff Size: 1443 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20071112/28e8e46a/attachment.bin From cjwatson at debian.org Tue Nov 13 07:01:54 2007 From: cjwatson at debian.org (Colin Watson) Date: Mon, 12 Nov 2007 20:01:54 +0000 Subject: Bug#447153: /usr/bin/scp: Fails to notice write errors In-Reply-To: References: <20071018133227.32321.90343.reportbug@nc4010.nodomain> <20071018135937.GN13244@riva.ucam.org> <20071112183354.GF13244@riva.ucam.org> Message-ID: <20071112200154.GN13244@riva.ucam.org> On Mon, Nov 12, 2007 at 08:13:42PM +0100, Michal Suchanek wrote: > On 12/11/2007, Colin Watson wrote: > > To openssh-unix-dev: does anyone think this is worth a workaround? The > > ftruncate seems rather unnecessary if we've already written out the > > required number of bytes anyway. I've attached a patch which only does > > it if that isn't the case (although I have some trouble seeing how we > > could ever get to the ftruncate without either writing the required > > number of bytes or encountering a write error). If people think it's a > > good idea I'll file it in Bugzilla. > > I do not know the scp code so I might be missing something. However, > truncating the file might be necessary when there is already a file, > and it was originally longer. Whoops! You're quite right; I blame the jetlag. (Though, since current portable CVS checks whether the file exists before trying to ftruncate it, simply changing '!exists || S_ISREG(stb.st_mode)' to 'exists && S_ISREG(stb.st_mode) && (new file shorter than old file)' would be another possibility; I can't see why you would want to truncate if it didn't previously exist, and the only way you can run into this bug if you're shortening an existing file is if you're copying over the top of an existing sparse file, which is even more of a crazy corner case than this already is. > It looks like a bug either in the kernel or in ftruncate > documentation. It is certainly true that the write error should get > reported at some point if it occurs, and a filesystem that chooses to > not return it on write() should save the errors for close(). > > However, using ftruncate() on the file does, in some sense, > successfully extend the file to the desired length. It looks like such > mixing of calls was not expected by the fs driver, and may not be well > defined in general. I understand your point, and I spent a little while pondering it before sending my mail. I think that if the write syscall doesn't actually write the bytes out to the filesystem then that's its own problem. If the write returns a non-zero number of bytes, ftruncate should behave in all cases *as if* those bytes have been written to the filesystem, even if they haven't actually quite been written yet. POSIX is pretty consistent in this; implementation details of buffering shouldn't be exposed except where they're explicitly defined to be exposed. (However, we should be having this debate on the linux-cifs-client list, not openssh-unix-dev ...) > I would suggest closing the file, and if it needs > truncating, reopen and truncate it (or do some voodoo with duplicated > fds if possible). Something like that would be another reasonable workaround, yes. Truncating only if the file already exists and the new one is shorter seems simpler to me, but I'm not all that bothered about the exact approach. Cheers, -- Colin Watson [cjwatson at debian.org] From wroach at lqc.com Tue Nov 13 07:58:15 2007 From: wroach at lqc.com (Warren Roach) Date: Mon, 12 Nov 2007 13:58:15 -0700 Subject: Using OpenSSH with Rsync Message-ID: <022201c8256e$d0aedc50$020aa8c0@p424> This question is perhaps one you have seen before but I have not found an answer to as yet. Rsync uses cygwin1.dll as does openssh. Is there a more current compilation of openssh that uses a more current cygwin1.dll such that both rsync and openssh can function on the same version? This is important because of improvements made to cygwin1 that affect rsync speed. Thanks for your thoughts and help. ---Warren Roach From stuge-openssh-unix-dev at cdy.org Tue Nov 13 10:02:25 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Tue, 13 Nov 2007 00:02:25 +0100 Subject: Bug#447153: /usr/bin/scp: Fails to notice write errors In-Reply-To: <20071112183354.GF13244@riva.ucam.org> References: <20071018133227.32321.90343.reportbug@nc4010.nodomain> <20071018135937.GN13244@riva.ucam.org> <20071112183354.GF13244@riva.ucam.org> Message-ID: <20071112230225.28647.qmail@cdy.org> On Mon, Nov 12, 2007 at 06:33:54PM +0000, Colin Watson wrote: > To openssh-unix-dev: does anyone think this is worth a workaround? Gut feeling is that it should be fixed wherever the problem is. > The ftruncate seems rather unnecessary if we've already written out > the required number of bytes anyway. Not neccessarily, we may be overwriting a larger file with the same name. //Peter From cjwatson at debian.org Tue Nov 13 11:33:24 2007 From: cjwatson at debian.org (Colin Watson) Date: Tue, 13 Nov 2007 00:33:24 +0000 Subject: Bug#447153: /usr/bin/scp: Fails to notice write errors In-Reply-To: <20071112230225.28647.qmail@cdy.org> References: <20071018133227.32321.90343.reportbug@nc4010.nodomain> <20071018135937.GN13244@riva.ucam.org> <20071112183354.GF13244@riva.ucam.org> <20071112230225.28647.qmail@cdy.org> Message-ID: <20071113003324.GO13244@riva.ucam.org> On Tue, Nov 13, 2007 at 12:02:25AM +0100, Peter Stuge wrote: > On Mon, Nov 12, 2007 at 06:33:54PM +0000, Colin Watson wrote: > > To openssh-unix-dev: does anyone think this is worth a workaround? > > Gut feeling is that it should be fixed wherever the problem is. Yeah, that's why I sent my mail to the CIFS list as well. Kernels won't get upgraded instantly even if it gets fixed right away though, so OpenSSH might want to regard it as a portability fix ... > > The ftruncate seems rather unnecessary if we've already written out > > the required number of bytes anyway. > > Not neccessarily, we may be overwriting a larger file with the same > name. Indeed; see the other part of this thread. -- Colin Watson [cjwatson at debian.org] From juri_mian at yahoo.com Tue Nov 13 09:47:39 2007 From: juri_mian at yahoo.com (Juri Mianovich) Date: Mon, 12 Nov 2007 14:47:39 -0800 (PST) Subject: inability to connect with netware OpenSSH 3.7.1 to FreeBSD 4.5p1 Message-ID: <386691.54114.qm@web45612.mail.sp1.yahoo.com> (I'm sorry - the securityfocus mailing list is dead and there are no other SSH resources on the net) Hello, Client is (some netware installation) running: Local version string SSH-2.0-OpenSSH_3.7.1p2 Server is plain old FreeBSD 6.2-RELEASE running: OpenSSH_4.5p1 FreeBSD-20061110, OpenSSL 0.9.7e-p1 When I attempt to connect from client (netware) to server (freebsd) I see: ssh -vvv user at host <0> debug1: kex: client->server aes128-cbc hmac-md5 none <0> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST sent <0> debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP <0> debug2: bits set: 1049/2048 <0> debug1: SSH2_MSG_KEX_DH_GEX_INIT sent <0> debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY <0> debug3: check_host_in_hostfile: filename /etc/ssh/known_hosts <0> debug3: check_host_in_hostfile: match line 1 <0> debug3: check_host_in_hostfile: filename /etc/ssh/known_hosts <0> debug3: check_host_in_hostfile: match line 1 <0> debug1: Host 'host' is known and matches the DSA host key. <0> debug1: Found key in /etc/ssh/known_hosts:1 <0> debug2: bits set: 1010/2048 <0> debug1: ssh_dss_verify: signature error <0> fatal: key_verify failed for server_host_key <0> debug1: Calling cleanup 0xa69a0ec0(0x0) <0> debug1: Calling cleanup 0xa6994630(0x0) <0> debug3: DecrementThreadCount() Thread count is now 1 <0> debug1: SSH_NWExit(0) calling SSH_NetWareExit() The key pieces of the error being: <0> debug1: ssh_dss_verify: signature error <0> fatal: key_verify failed for server_host_key So then I connect forcing version 1: ssh -vvv -1 user at host and I get: <0> fatal: Selected cipher type not supported by server. So if I specify DES: ssh -vvv -1 -c des user at host <0> fatal: Selected cipher type des not supported by server. Finally, I specify 3des, and I get no output at all: ssh -vvv -1 -c 3des user at host the command just completes and I get no output - as if I did not run it at all. Any suggestions ? Has anyone connected from netware to a recent OpenSSH 4.5.x server ? This is one of the newest, if not the very newest release distros of OpenSSH for netware, so we are fairly up to date... Thanks. ____________________________________________________________________________________ Never miss a thing. Make Yahoo your home page. http://www.yahoo.com/r/hs From njleanne at hotmail.com Tue Nov 13 14:04:10 2007 From: njleanne at hotmail.com (leanne) Date: Tue, 13 Nov 2007 03:04:10 +0000 Subject: compile error in hp-ux 11.23PA system with OpenSSH4.7p1 Message-ID: Hi all, I am compiling the OpenSSH4.7p1 on hp-ux PA11.23 system, however, it gives the following bug: cc +DD64 -I. -I. -I../include/openssl -I../include/tcpwrap -I../include/zlib -D_HPUX_SOURCE -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED=1 -I/usr/local/include -I../include/gssapi -DSSHDIR=\"/opt/ssh/etc\" -D_PATH_SSH_PROGRAM=\"/opt/ssh/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/opt/ssh/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/opt/ssh/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/opt/ssh/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\"/opt/ssh/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -D__HP1123PA -DHP1123PA -c gss-serv-krb5.ccpp: "/usr/include/sys/xti.h", line 332: warning 2001: Redefinition of macro T_NULL.cpp: "/usr/include/sys/xti.h", line 341: warning 2001: Redefinition of macro T_UNSPEC.cc: "/usr/include/gssapi_krb5.h", line 54: error 1000: Unexpected symbol: "OM_uint32".cc: "/usr/include/gssapi_krb5.h", line 54: warning 557: Missing declaration specifiers, "int" assumed.cc: "/usr/include/gssapi_krb5.h", line 59: error 1000: Unexpected symbol: "OM_uint32".cc: "/usr/include/gssapi_krb5.h", line 59: warning 557: Missing declaration specifiers, "int" assumed.cc: "/usr/include/gssapi_krb5.h", line 64: error 1000: Unexpected symbol: "OM_uint32".cc: "/usr/include/gssapi_krb5.h", line 64: warning 557: Missing declaration specifiers, "int" assumed. I checked the krb5client verison is: # what /usr/lib/libkrb5.sl/usr/lib/libkrb5.sl: $Revision: jazz @ 20070615.13:01:57IST; jmkvw -proj commands -RW -c Task: krbclnt_NCF_1.3.5.07 shuklahi_krbclnt_NCF_1.3.5.07 r11.23(R11.23_BL2007_0610) eso3_shuklahi_krbclnt_ncf_1.3.5.07(auto) ; HP Kerberos V5 1.3.5.07 Module: libkrb5.sl Date: Jun 15 2007 13:02:00 Although it says that gssapi_krb5.h has an unexpected symbol, but at last, I compile successfully by adding a line in the gss-serv-krb5.c: --- gss-serv-krb5.c.bak 2007-11-08 11:25:34 +0800+++ gss-serv-krb5.c 2007-11-07 15:05:26 +0800@@ -28,6 +28,7 @@ #ifdef GSSAPI #ifdef KRB5+#define GSS_DLLIMP #include So is it a OpenSSH bug or a kerberos bug? If it's a OpenSSH bug, can you research it? Thanks!! Best Regards Lv Liangying _________________________________________________________________ Windows Live Spaces ???????? http://miaomiaogarden2007.spaces.live.com/ From rejithomas.d at gmail.com Tue Nov 13 17:20:39 2007 From: rejithomas.d at gmail.com (Reji Thomas) Date: Tue, 13 Nov 2007 11:50:39 +0530 Subject: Help with openssh: ssh application writing data > 131071 to socket causing message too long error Message-ID: <9f0739d0711122220l1d8593c8vd1925dddfcd980c2@mail.gmail.com> Hi, I am facing an issue with openssh-4.5p1. I am not sure whether its an openssh issue or a tcp stack issue since I am using a simulated tcp/ip stack. While copying a file of around 1GB using sftp/scp I am getting a send:Message too long error. I did a bit of debugging and found that ssh code was sending packet of size greater than 131072 bytes from the application level to the socket and hence the issue. On going through the code In client_loop( in clientloop.c) if (packet_not_very_much_data_to_write()) channel_output_poll(); In packet.c packet_not_very_much_data_to_write(void) { if (interactive_mode) { fprintf(stderr,"interactive mode buffer len %d\n", buffer_len(&output)); return buffer_len(&output) < 16384; } else { fprintf(stderr,"non interactive mode buffer len %d\n", buffer_len(&output)); return buffer_len(&output) < 128 * 1024; } } which allows more data to be buffered if buffersize is less than 128*1024 ie 131072 bytes. ie data size can be greater (excluding headers, mac,padding fields etc) than 131072 bytes. Now my issue is my socket library will reject anything greater than 131071 bytes. As to my understanding this is true with a linux networking stack also (on my system the max system value allowed is 131071).Please correct me if I am wrong. In channel_output_poll(void) in channels.c if (compat20) { if (len > c->remote_window) len = c->remote_window; if (len > c->remote_maxpacket) len = c->remote_maxpacket; fprintf(stderr,"Remote window size %d Remote max packet %d\n",c->remote_window,c->remote_maxpacket); } else { if (packet_is_interactive()) { if (len > 1024) len = 512; } else { /* Keep the packets at reasonable size. */ if (len > packet_get_maxsize()/ 2) len = packet_get_maxsize()/2; } } if (len > 0) { packet_start(compat20 ? SSH2_MSG_CHANNEL_DATA : SSH_MSG_CHANNEL_DATA); packet_put_int(c->remote_id); packet_put_string(buffer_ptr(&c- >input), len); packet_send(); buffer_consume(&c->input, len); c->remote_window -= len; The issue starts happening when the server side sends a window size of 131072. As seen from the above code ,the length of data only (and excludes padding,mac,headers etc)is reduced from the remote window and hence the window size is effectively the data size and doesnt include headers etc. In packet_send() in packet.c we add padding ,mac and other headers which increase the packet size (another 48 bytes as I see ) and hence the buffer_len(&output) increases by datalength+48. and hence I feel the total packet size written to socket buffer can go more than 131071 Please correct me if I am wrong.Also where my understanding is wrong.Wheres the issue . Is it with the networking stack ??. Debug data (I have inserted) Remote window size 131072 Remote max packet 32768 send: len 16416 ( padding length 18) non interactive mode buffer len 16432 Remote window size 114688 Remote max packet 32768 send: len 16416 (includes payload, padding and padding length 18) non interactive mode buffer len 32864 Remote window size 98304 Remote max packet 32768 send: len 16416 (includes payload, padding and padding length 18) non interactive mode buffer len 49296 Remote window size 81920 Remote max packet 32768 send: len 16416 (includes payload, padding and padding length 18) non interactive mode buffer len 65728 Remote window size 65536 Remote max packet 32768 send: len 16416 (includes payload, padding and padding length 18) non interactive mode buffer len 82160 Remote window size 49152 Remote max packet 32768 send: len 16416 (includes payload, padding and padding length 18) non interactive mode buffer len 98592 Remote window size 32768 Remote max packet 32768 send: len 16304 (includes payload, padding and padding length 11) non interactive mode buffer len 114912 Remote window size 16489 Remote max packet 32768 send: len 16416 (includes payload, padding and padding length 18) non interactive mode buffer len 131344 Before packet_write_poll length before calling systemcall write 131344 Write failed: Message too long Couldn't send packet: Broken pipe Thanks Reji Thomas From stuge-openssh-unix-dev at cdy.org Tue Nov 13 23:36:19 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Tue, 13 Nov 2007 13:36:19 +0100 Subject: Help with openssh: ssh application writing data > 131071 to socket causing message too long error In-Reply-To: <9f0739d0711122220l1d8593c8vd1925dddfcd980c2@mail.gmail.com> References: <9f0739d0711122220l1d8593c8vd1925dddfcd980c2@mail.gmail.com> Message-ID: <20071113123619.3172.qmail@cdy.org> On Tue, Nov 13, 2007 at 11:50:39AM +0530, Reji Thomas wrote: > length before calling systemcall write 131344 > Write failed: Message too long Would it be OK for your write() implementation to just take what bytes it can and return those as successfully written? That happens in real life all the time, and is documented. //Peter From deengert at anl.gov Wed Nov 14 00:44:32 2007 From: deengert at anl.gov (Douglas E. Engert) Date: Tue, 13 Nov 2007 07:44:32 -0600 Subject: compile error in hp-ux 11.23PA system with OpenSSH4.7p1 In-Reply-To: References: Message-ID: <4739AA40.2070809@anl.gov> leanne wrote: > > Hi all, > > I am compiling the OpenSSH4.7p1 on hp-ux PA11.23 system, however, it gives the following bug: > cc +DD64 -I. -I. -I../include/openssl -I../include/tcpwrap -I../include/zlib -D_HPUX_SOURCE -D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED=1 -I/usr/local/include -I../include/gssapi -DSSHDIR=\"/opt/ssh/etc\" -D_PATH_SSH_PROGRAM=\"/opt/ssh/bin/ssh\" -D_PATH_SSH_ASKPASS_DEFAULT=\"/opt/ssh/libexec/ssh-askpass\" -D_PATH_SFTP_SERVER=\"/opt/ssh/libexec/sftp-server\" -D_PATH_SSH_KEY_SIGN=\"/opt/ssh/libexec/ssh-keysign\" -D_PATH_SSH_PIDDIR=\"/var/run\" -D_PATH_PRIVSEP_CHROOT_DIR=\"/var/empty\" -DSSH_RAND_HELPER=\"/opt/ssh/libexec/ssh-rand-helper\" -DHAVE_CONFIG_H -D__HP1123PA -DHP1123PA -c gss-serv-krb5.ccpp: "/usr/include/sys/xti.h", line 332: warning 2001: Redefinition of macro T_NULL.cpp: "/usr/include/sys/xti.h", line 341: warning 2001: Redefinition of macro T_UNSPEC.cc: "/usr/include/gssapi_krb5.h", line 54: error 1000: Unexpected symbol: "OM_uint32".cc: "/usr/include/gssapi_krb5.h", line 54: warning 557: Missing declaration specifiers, "int" assumed.cc: "/usr/include/gssap i_krb5.h", line 59: error 1000: Unexpected symbol: "OM_uint32".cc: "/usr/include/gssapi_krb5.h", line 59: warning 557: Missing declaration specifiers, "int" assumed.cc: "/usr/include/gssapi_krb5.h", line 64: error 1000: Unexpected symbol: "OM_uint32".cc: "/usr/include/gssapi_krb5.h", line 64: warning 557: Missing declaration specifiers, "int" assumed. > > I checked the krb5client verison is: > # what /usr/lib/libkrb5.sl/usr/lib/libkrb5.sl: $Revision: jazz @ 20070615.13:01:57IST; jmkvw -proj commands -RW -c Task: krbclnt_NCF_1.3.5.07 shuklahi_krbclnt_NCF_1.3.5.07 r11.23(R11.23_BL2007_0610) eso3_shuklahi_krbclnt_ncf_1.3.5.07(auto) ; HP Kerberos V5 1.3.5.07 Module: libkrb5.sl Date: Jun 15 2007 13:02:00 > > Although it says that gssapi_krb5.h has an unexpected symbol, but at last, I compile successfully by adding a line in the gss-serv-krb5.c: > --- gss-serv-krb5.c.bak 2007-11-08 11:25:34 +0800+++ gss-serv-krb5.c 2007-11-07 15:05:26 +0800@@ -28,6 +28,7 @@ #ifdef GSSAPI #ifdef KRB5+#define GSS_DLLIMP #include > So is it a OpenSSH bug or a kerberos bug? If it's a OpenSSH bug, can you research it? > I would say its a HP bug, related to gss using OM_unint32 from xom.h as required by RFC. We don't have any HPs anymore, but when we did we used OpenSSH-4.1 and used to add these flags for 11.22 and 11.23: ia64_hpux112*) MYLDFLAGS="$MYLDFLAGS -Wl,+vnocompatwarnings,+b,/krb5/lib -Wl,+cdp,$MYSSL/lib:/krb5/lib,+cdp,$MYK5/lib:/krb5/lib" MYWRAPPER="no" MYRAND="--with-prngd-socket=yes" # hpux 11.23 had xom.h, used to need to fix rpcsec_gss.h # MYCPPFLAGS="$MYCPPFLAGS -DUSE_POSIX_THREADS -D__hpux -Dgss_OID_desc_struct=OM_object_identifier" MYCPPFLAGS="$MYCPPFLAGS -DUNSUPPORTED_POSIX_THREADS_HACK -D__hpux" ;; So try adding the -D__hpux > Thanks!! > > > Best Regards > Lv Liangying > > > _________________________________________________________________ > Windows Live Spaces ???????? > http://miaomiaogarden2007.spaces.live.com/ > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From dtucker at zip.com.au Wed Nov 14 06:40:53 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 13 Nov 2007 11:40:53 -0800 Subject: Using OpenSSH with Rsync In-Reply-To: <022201c8256e$d0aedc50$020aa8c0@p424> References: <022201c8256e$d0aedc50$020aa8c0@p424> Message-ID: <4739FDC5.4080401@zip.com.au> Warren Roach wrote: > This question is perhaps one you have seen before but I have not > found an answer to as yet. > > Rsync uses cygwin1.dll as does openssh. Is there a more current > compilation of openssh that uses a more current cygwin1.dll such that > both rsync and openssh can function on the same version? This is > important because of improvements made to cygwin1 that affect rsync > speed. Thanks for your thoughts and help. The OpenSSH and rsync binaries that ship with Cygwin itself will use the same version of the cygwin DLL. If you're not using those then you're pretty much on your own. I think that recent versions of Windows now allow per-process private DLLs these days, so if you must use different versions then that might help. -- 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 hramrach at centrum.cz Wed Nov 14 10:03:12 2007 From: hramrach at centrum.cz (Michal Suchanek) Date: Wed, 14 Nov 2007 00:03:12 +0100 Subject: Bug#447153: /usr/bin/scp: Fails to notice write errors In-Reply-To: <20071113003324.GO13244@riva.ucam.org> References: <20071018133227.32321.90343.reportbug@nc4010.nodomain> <20071018135937.GN13244@riva.ucam.org> <20071112183354.GF13244@riva.ucam.org> <20071112230225.28647.qmail@cdy.org> <20071113003324.GO13244@riva.ucam.org> Message-ID: On 13/11/2007, Colin Watson wrote: > On Tue, Nov 13, 2007 at 12:02:25AM +0100, Peter Stuge wrote: > > On Mon, Nov 12, 2007 at 06:33:54PM +0000, Colin Watson wrote: > > > To openssh-unix-dev: does anyone think this is worth a workaround? > > > > Gut feeling is that it should be fixed wherever the problem is. > > Yeah, that's why I sent my mail to the CIFS list as well. Kernels won't > get upgraded instantly even if it gets fixed right away though, so > OpenSSH might want to regard it as a portability fix ... > > > > The ftruncate seems rather unnecessary if we've already written out > > > the required number of bytes anyway. > > > > Not neccessarily, we may be overwriting a larger file with the same > > name. > > Indeed; see the other part of this thread. > I tried a few experiments, and I was not able to reproduce the problem a) against a Windows XP share which points in the direction of Samba server or Samba <-> Samba incompatibility b) in my favourite scripting language because it puts a sync before the truncate This could be used in scp as well, it is minimal change to the code: open: Success write: Success ftruncate: Success close: Success open: Success write: Success fsync: No space left on device ftruncate: No space left on device close: No space left on device Duplication voodoo also works: open: Success write: Success dup: Success close dup: No space left on device ftruncate: No space left on device close: No space left on device Thanks Michal From m.cretu at iu-bremen.de Thu Nov 15 06:35:49 2007 From: m.cretu at iu-bremen.de (mihai) Date: Wed, 14 Nov 2007 20:35:49 +0100 Subject: openssh transport layer Message-ID: <473B4E15.8060407@iu-bremen.de> Dear all, I would be very grateful if somebody could tell me where(in which files) is the ssh transport layer implemented in OpenSSH. Yours, normancboy From rapier at psc.edu Fri Nov 16 06:33:09 2007 From: rapier at psc.edu (Chris Rapier) Date: Thu, 15 Nov 2007 14:33:09 -0500 Subject: Extended Server Logging Patch Message-ID: <473C9EF5.1010509@psc.edu> On the request of a coworker looking for more information about our SSH users I developed a patch that provides extended logging capability for SSHD. Its been written with an eye towards machine parsing. This patch will write the following information to the standard system log: remote ip, remote port, & remote user name protocol number and client version information Encryption method, MAC method and compression Bytes transferred including packet headers and messages (I think I'm collecting most of it) Duration of connection, throughput in both directions. So far they've found it useful with no reported problems. Its a bit on the larger side (15k) so I'll just provide a link to the patch. If anyone has any comments or suggestions please let me know. http://www.psc.edu/networking/projects/hpn-ssh/openssh4.7-server-logging.diff Sample log data can be found here http://www.psc.edu/networking/projects/hpn-ssh/logging-sample-output.html This patch is made against the mainline code base but it does patch cleanly against hpn12v19. This patch and the previously mentioned progress bar patch can both be found at http://www.psc.edu/networking/projects/hpn-ssh Chris Rapier From petesea at bigfoot.com Fri Nov 16 08:33:40 2007 From: petesea at bigfoot.com (petesea at bigfoot.com) Date: Thu, 15 Nov 2007 13:33:40 -0800 (PST) Subject: GSSAPI Key Exchange Patch Message-ID: Will Simon Wilkinson's GSSAPI Key Exchange patch ever be incorporated into the OpenSSH source? http://www.sxw.org.uk/computing/patches/openssh.html I'm sure I'm not the only one that uses it and would like to see it become part of the OpenSSH source. Is there something missing or is there some technical/philosophical reason for not including it? From djm at mindrot.org Fri Nov 16 19:25:04 2007 From: djm at mindrot.org (Damien Miller) Date: Fri, 16 Nov 2007 19:25:04 +1100 (EST) Subject: GSSAPI Key Exchange Patch In-Reply-To: References: Message-ID: On Thu, 15 Nov 2007, petesea at bigfoot.com wrote: > Will Simon Wilkinson's GSSAPI Key Exchange patch ever be incorporated into > the OpenSSH source? As far as I know, none of the current core OpenSSH developers are in favour of adding it. > http://www.sxw.org.uk/computing/patches/openssh.html > > I'm sure I'm not the only one that uses it and would like to see it become > part of the OpenSSH source. Is there something missing or is there some > technical/philosophical reason for not including it? Yes - we are very scared of adding features that lead to more pre-authentication attack surface, especially when they delegate to complex libraries with patchy security histories. -d From sfrost at snowman.net Fri Nov 16 12:39:26 2007 From: sfrost at snowman.net (Stephen Frost) Date: Thu, 15 Nov 2007 20:39:26 -0500 Subject: GSSAPI Key Exchange Patch In-Reply-To: References: Message-ID: <20071116013926.GF5031@tamriel.snowman.net> All, * petesea at bigfoot.com (petesea at bigfoot.com) wrote: > http://www.sxw.org.uk/computing/patches/openssh.html > > I'm sure I'm not the only one that uses it and would like to see it become > part of the OpenSSH source. Is there something missing or is there some > technical/philosophical reason for not including it? We'd also like to see it incorporated. It's unfortunate that it continues to be an ordeal to get proper GSSAPI support for OpenSSH even with all of Simon's hard work. I havn't been following the IETF/RFC draft process lately but I thought getting that finalized, including GSSAPI server auth, was the remaining hoop GSSAPI and Kerberos supporters had to jump through to get this incorporated upstream (and I thought people were working on it, but it does seem like it's been quite a while now..). Certainly one thing we're thankful for is that Debian has Simon's patch incorporated, and has for quite some time now. I suppose, sadly, that it's probably one of the reasons people havn't been more vocal about getting it incorporated upstream. In fact, looking back, it was incorporated in the September 14th, 2005 upload to Debian of version 1:4.2p1-2, and Colin credited me for asking for it in the changelog. :) Thanks, Stephen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20071115/8326abb4/attachment.bin From carson at taltos.org Fri Nov 16 14:09:16 2007 From: carson at taltos.org (Carson Gaspar) Date: Thu, 15 Nov 2007 21:09:16 -0600 Subject: GSSAPI Key Exchange Patch In-Reply-To: References: Message-ID: <473D09DC.6090509@taltos.org> Damien Miller wrote: > Yes - we are very scared of adding features that lead to more > pre-authentication attack surface, especially when they delegate to > complex libraries with patchy security histories. The risk of a pre-auth GSSAPI bug is far less than the nearly _impossible_ key management problem without it. Sun has integrated the patch. My employer is rolling it out, and is asking Red Hat to include it. At this point, _not_ incorporating it upstream is just leading to a de facto source code fork. I strongly suggest the maintainers reconsider their position. -- Carson From sfrost at snowman.net Fri Nov 16 14:24:11 2007 From: sfrost at snowman.net (Stephen Frost) Date: Thu, 15 Nov 2007 22:24:11 -0500 Subject: GSSAPI Key Exchange Patch In-Reply-To: <473D09DC.6090509@taltos.org> References: <473D09DC.6090509@taltos.org> Message-ID: <20071116032411.GL5031@tamriel.snowman.net> * Carson Gaspar (carson at taltos.org) wrote: > Damien Miller wrote: > > Yes - we are very scared of adding features that lead to more > > pre-authentication attack surface, especially when they delegate to > > complex libraries with patchy security histories. > > The risk of a pre-auth GSSAPI bug is far less than the nearly > _impossible_ key management problem without it. Sun has integrated the > patch. My employer is rolling it out, and is asking Red Hat to include > it. At this point, _not_ incorporating it upstream is just leading to a > de facto source code fork. I strongly suggest the maintainers reconsider > their position. I would tend to agree. The patch is also in Debian, and as such I suspect a number of other places (Ubuntu, etc). Certainly if you're aware of specific security issues with the patch there are alot of people who would benefit from knowing what they are. If there aren't, it would be great to have it included to minimize the risk of an issue being found in the future and not being patched everywhere, or other issues related to forking. Thanks, Stephen -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: Digital signature Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20071115/60d3f7f2/attachment.bin From deengert at anl.gov Sat Nov 17 06:20:09 2007 From: deengert at anl.gov (Douglas E. Engert) Date: Fri, 16 Nov 2007 13:20:09 -0600 Subject: GSSAPI Key Exchange Patch In-Reply-To: <20071116032411.GL5031@tamriel.snowman.net> References: <473D09DC.6090509@taltos.org> <20071116032411.GL5031@tamriel.snowman.net> Message-ID: <473DED69.6060301@anl.gov> Stephen Frost wrote: > * Carson Gaspar (carson at taltos.org) wrote: >> Damien Miller wrote: >>> Yes - we are very scared of adding features that lead to more >>> pre-authentication attack surface, especially when they delegate to >>> complex libraries with patchy security histories. >> The risk of a pre-auth GSSAPI bug is far less than the nearly >> _impossible_ key management problem without it. Sun has integrated the >> patch. My employer is rolling it out, and is asking Red Hat to include >> it. At this point, _not_ incorporating it upstream is just leading to a >> de facto source code fork. I strongly suggest the maintainers reconsider >> their position. > I too agree with the previous responses. We have gotten away from building OpenSSH in favor of using the vendor's versions. Solaris 10 and Ubuntu are used widely here and both have gssapi-keyex and work well togther. The option is on be default in Solaris 10 so anyone uses Kerberos and ssh on Solaris 10 is using gssapi-keyex. Looks like you already have a de facto source split. It would be nice to get things back in sync. > > Thanks, > > Stephen > > > ------------------------------------------------------------------------ > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From sxw at inf.ed.ac.uk Sat Nov 17 06:45:40 2007 From: sxw at inf.ed.ac.uk (Simon Wilkinson) Date: Fri, 16 Nov 2007 19:45:40 +0000 Subject: GSSAPI Key Exchange Patch In-Reply-To: References: Message-ID: <9A1043FC-5439-4625-9984-9EBF728BE359@inf.ed.ac.uk> On 16 Nov 2007, at 08:25, Damien Miller wrote: > Yes - we are very scared of adding features that lead to more > pre-authentication attack surface, especially when they delegate to > complex libraries with patchy security histories. I'm not convinced that adding key-exchange actually increases the pre- authentication attack surface. At the end of the day the same payloads are getting passed through to the same privileged process (and onwards to the same complex library) as happens when doing GSSAPI user authentication. The only difference is that one happens after the key exchange step has been performed, and the other happens as part of it. However, I don't want to start telling people what they should and shouldn't include in software they maintain in their own time, and of their own free will. My site (School of Informatics at the University of Edinburgh) obviously finds GSSAPI key exchange hugely useful - and having support for it included upstream would greatly ease my task of forward porting the patch with every release. That said, out of all of the platforms we support, there's only one that we care about that doesn't ship with GSSAPI key exchange support included in their packages, so its absence in the upstream distribution isn't actually a great loss to us. If you've got Kerberos deployed, and used the key-exchange stuff to solve the ssh host key management problem, doing anything else for a site with a large number of machines seems unthinkable. If your focus is on small deployments, where there's no need to achieve these kind of economies in order to scale your system management, I guess it's easy to regard the key management code as overkill. Simon. From David.Love at securitybenefit.com Sat Nov 17 07:32:47 2007 From: David.Love at securitybenefit.com (Love, David) Date: Fri, 16 Nov 2007 14:32:47 -0600 Subject: SCP bug on OpenSSH 3.6p1 Message-ID: <7AF2C7C2672F204998D9F6A9EDE0D860016E5281@exchange2003.sbl.com> I apologize if this has been reported already - my company has blocked the reporting site so I cannot see if it has or what the solution is. I have also reported this to AT&T as a UWIN issue too. Ok - so I am running UWIN 4.1 (the latest version of this) on a Windows XP SP2 system. UWIN 4.1 bundles with it OpenSSH 3.6p1. I have setup and tested SSH and it works fine. I can run an ssh command to one of my unix servers and it works and reports exactly as I expect it to. But when I run "scp @:/etc/ssh/ssh_config ." I get the following error: ssh: :/etc/ssh/sshd_config: no address associated with hostname. It is not extracting the HOSTNAME properly in order to do its IP lookup on it. If I change this to use the IP address - it still fails and the error is the same - just substitute the IP for the HOSTNAME. It seems to be an SCP issue in the way it is extracting the name. if I add an entry in my /etc/hosts file for the entire entry above (with colon and path) it will then try to establish the scp connection (and it fails for other reasons obviously then). My question is - is there a simple fix for this version of OpenSSH - or do I have to upgrade. I have a question out to UWIN to find out how I would do that though since it is a packaged application for them. Thank you in advance for any support. __________________________________ David E. Love Unix System Admin / Oracle DBA Security Benefit One Security Benefit Place Topeka, KS 66636 P - 785.438.6359 C - 785.213.8452 E - David.Love at SecurityBenefit.com From ed at bsd.it Mon Nov 19 01:31:20 2007 From: ed at bsd.it (Ed) Date: Sun, 18 Nov 2007 15:31:20 +0100 Subject: party for 8th OpenSSH birthday Message-ID: <200711181531.21467.ed@bsd.it> Hello everyone, I would like to inform you that on Saturday 1st December there will be a party to celebrate the 8th OpenSSH birthday. Location is Venice, Italy. The event will be held during OpenCON, a conference fully dedicated to OpenBSD, so we expect to see a lot of developers :) You can have more information looking here: http://www.opencon.org/ Thanks. From rapier at psc.edu Tue Nov 20 02:36:35 2007 From: rapier at psc.edu (Chris Rapier) Date: Mon, 19 Nov 2007 10:36:35 -0500 Subject: GSSAPI Key Exchange Patch In-Reply-To: <9A1043FC-5439-4625-9984-9EBF728BE359@inf.ed.ac.uk> References: <9A1043FC-5439-4625-9984-9EBF728BE359@inf.ed.ac.uk> Message-ID: <4741AD83.6060102@psc.edu> Simon Wilkinson wrote: > On 16 Nov 2007, at 08:25, Damien Miller wrote: > >> Yes - we are very scared of adding features that lead to more >> pre-authentication attack surface, especially when they delegate to >> complex libraries with patchy security histories. > > I'm not convinced that adding key-exchange actually increases the pre- > authentication attack surface. At the end of the day the same > payloads are getting passed through to the same privileged process > (and onwards to the same complex library) as happens when doing > GSSAPI user authentication. The only difference is that one happens > after the key exchange step has been performed, and the other happens > as part of it. Part of the problem, at least as far as I can see is it, is maintaining any patch that is incorporated. Any time something like this is included there is the strong possibility that the responsibility for keeping the included features up to date will fall onto the shoulders of an already overworked development team. Even if it's just included as a compile time option this can become a bit of a burden. The more integral the patch is to a critical aspect of the code base the more likely this becomes. That being said, I've occasionally wondered if there is a solution for all of this that would make things easier for the end users without overwhelming the developers. Perhaps a pre-configure utility that can be used to fetch well known patches from a maintained canonical repository and automagically incorporate them. Obviously, that can be problematic in its own right (conflicting patches, who maintains the patch repository, what gets included, etc). Chris From Jefferson.Ogata at noaa.gov Tue Nov 20 02:43:30 2007 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Mon, 19 Nov 2007 15:43:30 +0000 Subject: GSSAPI Key Exchange Patch In-Reply-To: <4741AD83.6060102@psc.edu> References: <9A1043FC-5439-4625-9984-9EBF728BE359@inf.ed.ac.uk> <4741AD83.6060102@psc.edu> Message-ID: <4741AF22.5010703@noaa.gov> On 2007-11-19 15:36, Chris Rapier wrote: > Perhaps a > pre-configure utility that can be used to fetch well known patches from > a maintained canonical repository and automagically incorporate them. ... or an API architecture allowing authentication strategies to be packaged as modules, and ideally even abstracted as independent shared libraries, a la NSS or sasl2. > Obviously, that can be problematic in its own right (conflicting > patches, who maintains the patch repository, what gets included, etc). See above. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From warren.m.smith at gmail.com Wed Nov 21 03:37:17 2007 From: warren.m.smith at gmail.com (warren smith) Date: Tue, 20 Nov 2007 10:37:17 -0600 Subject: Incorporating code from sftp-glob.c into lftp Message-ID: As you might know, LFTP is a popular FTP/SFTP command-line client for most systems. One feature that is lacking from this tool is the ability to do a globbed ls via sftp. I have a patch ready for LFTP that incorporates some of the knowledge [like oddball systems glob() handling] and some of the code from sftp-glob.c for this tool to add this capability. I do, however, have some questions about license issues before I submit the patch to the lftp developers. LFTP is GPL licensed, and openssh is BSD licensed. Is it kosher to incorporate the code into lftp or should I start over from a clean room implementation? Any help is appreciated, -Warren From mark.glemboski at verizonbusiness.com Wed Nov 21 07:44:39 2007 From: mark.glemboski at verizonbusiness.com (Glemboski, Mark A) Date: Tue, 20 Nov 2007 20:44:39 +0000 Subject: interrupt remote command bug? Message-ID: <36B8E28A6DA27D4A9309815056643088057550A4@ASHEVS010.mcilink.com> Env: Solaris 8/10, openssh-4.2p1 If I invoke the following remote command: ssh remoteHost "tail -f /var/adm/messages" then interrupt the command locally via Ctrl-C, the local ssh is terminated, but the signaled interrupt is not propagated to the remote command. The remote sshd abandons the spawned program, leaving the 'tail' running forever. I know I can workaround this behavior by using 'ssh -t' to invoke the remote command, forcing the creation of a controlling terminal. Shouldn't the default behavior of ssh be to terminate the remote command when it's terminated locally? Please point me to a rational for this behavior. Mark Glemboski From stuge-openssh-unix-dev at cdy.org Wed Nov 21 15:59:35 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Wed, 21 Nov 2007 05:59:35 +0100 Subject: Incorporating code from sftp-glob.c into lftp In-Reply-To: References: Message-ID: <20071121045935.28008.qmail@cdy.org> On Tue, Nov 20, 2007 at 10:37:17AM -0600, warren smith wrote: > LFTP is GPL licensed, and openssh is BSD licensed. Is it kosher to > incorporate the code into lftp or should I start over from a clean > room implementation? > > Any help is appreciated, Thanks for asking! The BSD license that applies to sftp-glob.c permits you to include code in another product, GPL or other license, as long as certain conditions are met. Please see the top of the file sftp-glob.c for the full statement that gives you permission to use, copy modify and distribute the software. //Peter From djm at mindrot.org Wed Nov 21 17:14:17 2007 From: djm at mindrot.org (Damien Miller) Date: Wed, 21 Nov 2007 17:14:17 +1100 (EST) Subject: Incorporating code from sftp-glob.c into lftp In-Reply-To: References: Message-ID: On Tue, 20 Nov 2007, warren smith wrote: > As you might know, LFTP is a popular FTP/SFTP command-line client for > most systems. One feature that is lacking from this tool is the > ability to do a globbed ls via sftp. I have a patch ready for LFTP > that incorporates some of the knowledge [like oddball systems glob() > handling] and some of the code from sftp-glob.c for this tool to add > this capability. I do, however, have some questions about license > issues before I submit the patch to the lftp developers. LFTP is GPL > licensed, and openssh is BSD licensed. Is it kosher to incorporate the > code into lftp or should I start over from a clean room > implementation? The license (MIT) that the sftp client code is released under does not prohibit incorporation into a GPL project and does not contain any terms that are incompatible with the GPL, so there is no reason to reimplement. You just need to make sure that you follow the terms of the license by preserving the license & copyright notice in whichever files you incorporate code to. -d From pgsery at swcp.com Thu Nov 22 16:59:46 2007 From: pgsery at swcp.com (paul sery) Date: Wed, 21 Nov 2007 22:59:46 -0700 Subject: [PATCH] one-time ssh-agent confirmation password Message-ID: <47451AD2.106@swcp.com> The patch (against 4.7p1) modifies gnome-ssh-askpass to optionally generate a one-time password and transmits it to the user via an out-of-band communication channel. If you can read the password and enter it back into the gnome-ssh-askpass dialog, ssh-agent is allowed to continue with the authentication process. There are two ways to use the modified gnome-ssh-askpass. The first incrementally increases the security provided by the traditional ssh-agent/gnome-ssh-askpass combination. The second allows you to create two fully separated authentication factors - the private key and one-time password - without using a specialized hardware token. Both are described in the attached README. -------------- next part -------------- A non-text attachment was scrubbed... Name: gnome-ssh-askpass2.c.patch Type: text/x-patch Size: 3886 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20071121/58c326ea/attachment.bin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: README Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20071121/58c326ea/attachment.ksh -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: ssh-otac-fifo Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20071121/58c326ea/attachment-0001.ksh From dkg-openssh.com at fifthhorseman.net Fri Nov 23 07:44:45 2007 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 22 Nov 2007 15:44:45 -0500 Subject: [PATCH] one-time ssh-agent confirmation password In-Reply-To: <47451AD2.106@swcp.com> (paul sery's message of "Wed\, 21 Nov 2007 22\:59\:46 -0700") References: <47451AD2.106@swcp.com> Message-ID: <87lk8qm2ma.fsf@squeak.fifthhorseman.net> On Thu 2007-11-22 00:59:46 -0500, paul sery wrote: > The patch (against 4.7p1) modifies gnome-ssh-askpass to optionally > generate a one-time password and transmits it to the user via an > out-of-band communication channel. If you can read the password and > enter it back into the gnome-ssh-askpass dialog, ssh-agent is > allowed to continue with the authentication process. This is an interesting idea. Thanks for publishing! I haven't had time to digest it enough to know if the general framework is something i want, but here's a couple quick notes about the diff: > --- gnome-ssh-askpass2.c.orig 2003-11-21 05:48:56.000000000 -0700 > +++ gnome-ssh-askpass2.c 2007-11-01 10:54:11.000000000 -0600 > @@ -38,6 +38,9 @@ > > #define GRAB_TRIES 16 > #define GRAB_WAIT 250 /* milliseconds */ > +#define OTAC_LEN 4 /* number of characters in otac passphrase */ > +#define OTAC_FIFO_LEN 128 /* number of characters in otac passphrase */ Both constants have the same comment, but have different values. I suspect one of the comments is wrong. > + Why add the blank line? > -passphrase_dialog(char *message) > +passphrase_dialog(char *message, char *otac_passphrase, char *otac_fifo) Your additions to this function (and elsewhere) seem to use spaces for indentation. Previous code in this file uses tabs for indentation. Sticking to the coding convention will make your patch more appealing to the original author. > +/* generate the one-time agent confirm password */ > +char * > +gen_otac_passphrase(int otac_length) > +{ spaces v. tabs in this function, as well. > + int i,ran,nchars=52; > + char cpool[52]="abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ"; > + char *otac_passphrase; > + > + /* use random # to select characters > + to build one-time passphrase with them */ > + > + srandom(time(0)); Seeding with the time (in seconds since the UNIX epoch) means that every one of these one-time-passwords that happens in a given second is going to use the same random password. So that password will be predictable -- probably not a property you intend the one time passwords to have. > + otac_passphrase=malloc(otac_length+1); > + for (i=0;i + ran = random(); > + otac_passphrase[i]=cpool[ran%nchars]; > + } > + strncat(otac_passphrase,"",1); Why not just: otac_passphrase[otac_length] = 0; > + > + return(otac_passphrase); > +} There's some memory management weirdness going on here. You allocate the otac_passphrase buffer in one function, pass it around through at least two others, and rely on the others to free it. While it looks like you've cleared this one up properly, it's probably not best practices. > int > main(int argc, char **argv) > { > - char *message; > - int result; > + char *message,*passphrase,*otac_passphrase,*otac_fifo; > + int result,otac_length=OTAC_LEN; > + > + otac_fifo=malloc(otac_length); Does this ever get freed? > + otac_fifo=getenv("SSH_OTAC_FIFO"); This looks like it overwrites the pointer to the buffer allocated immediately above. > + if (otac_fifo) { > + otac_passphrase=malloc(otac_length+1); > + otac_passphrase=gen_otac_passphrase(otac_length); > + write_to_fifo(otac_passphrase,otac_fifo); > + } > > gtk_init(&argc, &argv); > > @@ -213,8 +275,7 @@ > } > > setvbuf(stdout, 0, _IONBF, 0); > - result = passphrase_dialog(message); > + result = passphrase_dialog(message,otac_passphrase,otac_fifo); if (!otac_fifo), then what is otac_passphrase set to when you pass it in this function? Passing uninitialized pointers is dangerous. > g_free(message); > - Why make a whitespace change here? Thanks again for publishing this idea. For patches that you want people to consider against OpenSSH, you probably want to post them to the OpenSSH bugzilla (not just this mailing list): https://bugzilla.mindrot.org/ That makes your work easier to find for people looking for it later. Regards, --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 826 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20071122/226294ae/attachment-0001.bin From pgsery at swcp.com Sat Nov 24 15:12:12 2007 From: pgsery at swcp.com (paul sery) Date: Fri, 23 Nov 2007 21:12:12 -0700 Subject: [PATCH] one-time ssh-agent confirmation password Message-ID: <4747A49C.9020903@swcp.com> Daniel Kahn Gillmor wrote: >Paul Sery (pgsery-swcp.com> wrote: >> The patch (against 4.7p1) modifies gnome-ssh-askpass to optionally >> generate a one-time password and transmits it to the user via an >> out-of-band communication channel. If you can read the password and >> enter it back into the gnome-ssh-askpass dialog, ssh-agent is >> allowed to continue with the authentication process. >This is an interesting idea. Thanks for publishing! I haven't had >time to digest it enough to know if the general framework is something >i want, but here's a couple quick notes about the diff: I've cleaned up most of the clutter and tightened it up in general. >Seeding with the time (in seconds since the UNIX epoch) means that >every one of these one-time-passwords that happens in a given second >is going to use the same random password. So that password will be >predictable -- probably not a property you intend the one time >passwords to have. Yes, my current implementation is a place-holder. I'd like guidance on whether to use arc4random_stir or something else. >Thanks again for publishing this idea. For patches that you want >people to consider against OpenSSH, you probably want to post them to >the OpenSSH bugzilla (not just this mailing list): > https://bugzilla.mindrot.org/ > That makes your work easier to find for people looking for it later. Bug 1393. Thanks for the advice and help! I hope it proves useful. -Paul From pekkas at netcore.fi Sun Nov 25 04:17:31 2007 From: pekkas at netcore.fi (Pekka Savola) Date: Sat, 24 Nov 2007 19:17:31 +0200 (EET) Subject: undocumented scp server-side arguments -dft Message-ID: Hi, When implementing forced-commands using authorized-keys, I realized that scp (when run at the server end) arguments -d, -f and -t are not documented on the man page. scp.c: ... /* Server options. */ case 'd': targetshouldbedirectory = 1; break; case 'f': /* "from" */ iamremote = 1; fflag = 1; break; case 't': /* "to" */ iamremote = 1; tflag = 1; ... -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From m.cretu at iu-bremen.de Sun Nov 25 06:01:11 2007 From: m.cretu at iu-bremen.de (mihai) Date: Sat, 24 Nov 2007 20:01:11 +0100 Subject: enable none cipher Message-ID: <474874F7.8050803@iu-bremen.de> Hello, Does anybody know how cam I enable the usage of the 'none' cipher in OpenSSH 4.7 yours, Mihai From pgsery at swcp.com Sun Nov 25 13:40:42 2007 From: pgsery at swcp.com (paul sery) Date: Sat, 24 Nov 2007 19:40:42 -0700 Subject: [PATCH] one-time ssh-agent confirmation password In-Reply-To: <4747A49C.9020903@swcp.com> References: <4747A49C.9020903@swcp.com> Message-ID: <4748E0AA.2040304@swcp.com> -------------- next part -------------- A non-text attachment was scrubbed... Name: gnome-ssh-askpass2.c.patch Type: text/x-patch Size: 3158 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20071124/3702c644/attachment-0002.bin -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: README Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20071124/3702c644/attachment-0001.ksh -------------- next part -------------- A non-text attachment was scrubbed... Name: ssh-otac-fifo.pl Type: application/x-perl Size: 2756 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20071124/3702c644/attachment-0003.bin From chris at qwirx.com Mon Nov 26 03:12:48 2007 From: chris at qwirx.com (Chris Wilson) Date: Sun, 25 Nov 2007 16:12:48 +0000 (GMT) Subject: Request for LPK patch to be merged Message-ID: Hi all, At my organisation we have an LDAP infrastructure built on OpenLDAP, between Unix boxes running OpenSSH at multiple sites. It works well but the SSH key management is something of an inconvenience, especially as we would like to implement SSO with ssh-agent and passphrased keys. There is an OpenSSH patch called LPK which can allow the authorized_keys to be stored in LDAP, and that would be really useful in our environment. However we don't really want to maintain our own packages, and our default distro doesn't want to supply packages with the LPK patch as long as it's not supported upstream. So I'd like to request that you consider the LPK patch for merging into OpenSSH. You can find it here: http://dev.inversepath.com/trac/openssh-lpk Here is the description of what specifically we are trying to achieve: http://dev.inversepath.com/openssh-lpk/ldap_fosdem_2006.pdf In particular: "The final goal is cross-platform authentication, being able to manage users globally on the LDAP server, without performing any action on the server pool (scalability for add/revoke a user to N servers scenarios)" And here is another page giving another good reason for using LPK: http://blog.fupps.com/2006/03/02/ssh-public-keys-from-ldap/ "What happens when you have dozens or more [machines]? You have to maintain your public keys on all those systems, ensuring they are kept up to date. God forbid that you loose your private key, or that it becomes compromised: you'd have to quickly change all the authorized_keys files on all machines!" I'm not the developer of the patch, but if there are specific issues that need to be addressed then I'd be happy to coordinate with the maintainer and/or lend a hand to see them addressed. Cheers, Chris. -- _____ __ _ \ __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Perl/SQL/HTML Developer | \ _/_/_/_//_/___/ | We are GNU-free your mind-and your software | From dtucker at zip.com.au Tue Nov 27 04:30:04 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 27 Nov 2007 04:30:04 +1100 Subject: Enable gcc's -fstack-protector-all by default? Message-ID: <20071126173004.GA2139@gate.dtucker.net> Hi all. For a while, gcc has supported a stack protection mechanism (-fstack-protector and friends, available in gcc 4.1.2 and up). Can anyone think of a good reason not to enable it if the compiler supports it? A quick test here shows minimal difference in runtime over a full regress pass (~10sec over 8.5 minutes, and since the machine is not entirely idle that could be experimental error). Index: configure.ac =================================================================== RCS file: /usr/local/src/security/openssh/cvs/openssh/configure.ac,v retrieving revision 1.386 diff -u -p -r1.386 configure.ac --- configure.ac 26 Sep 2007 21:03:20 -0000 1.386 +++ configure.ac 26 Nov 2007 09:30:15 -0000 @@ -105,6 +105,15 @@ if test "$GCC" = "yes" || test "$GCC" = *) ;; esac + AC_MSG_CHECKING(if $GCC understands -fstack-protector-all) + saved_CFLAGS="$CFLAGS" + CFLAGS="$CFLAGS -fstack-protector-all" + AC_TRY_COMPILE([], [ int main(void){return 0;} ], + [ AC_MSG_RESULT(yes) ], + [ AC_MSG_RESULT(no) + CFLAGS="$saved_CFLAGS" ] + ) + if test -z "$have_llong_max"; then # retry LLONG_MAX with -std=gnu99, needed on some Linuxes unset ac_cv_have_decl_LLONG_MAX -- 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 rapier at psc.edu Tue Nov 27 05:28:21 2007 From: rapier at psc.edu (Chris Rapier) Date: Mon, 26 Nov 2007 13:28:21 -0500 Subject: enable none cipher In-Reply-To: <474874F7.8050803@iu-bremen.de> References: <474874F7.8050803@iu-bremen.de> Message-ID: <474B1045.70706@psc.edu> mihai wrote: > Hello, > Does anybody know how cam I enable the usage of the 'none' cipher in > OpenSSH 4.7 You should not enable the none cipher in the base OpenSSH code as it is a serious security problem. The data you are sending might not be worth encrypting but your authentication should *always* be encrypted. If you do want to use the none cipher in a safer way you should get the HPN-SSH patch from http://www.psc.edu/networking/projects/hpn-ssh. This patch, in addition to some other things, re-implements the none cipher but maintains secure authentication. There is a caveat in that you cannot use the none cipher in interactive sessions - its only for bulk data transfers. You'll need to read the HPN12-README file to learn how to use it. Chris From archer at eskimo.com Tue Nov 27 05:45:00 2007 From: archer at eskimo.com (Curt, WE7U) Date: Mon, 26 Nov 2007 10:45:00 -0800 (PST) Subject: enable none cipher In-Reply-To: <474B1045.70706@psc.edu> References: <474874F7.8050803@iu-bremen.de> <474B1045.70706@psc.edu> Message-ID: On Mon, 26 Nov 2007, Chris Rapier wrote: > You should not enable the none cipher in the base OpenSSH code as it is > a serious security problem. The data you are sending might not be worth > encrypting but your authentication should *always* be encrypted. If you > do want to use the none cipher in a safer way you should get the HPN-SSH > patch from http://www.psc.edu/networking/projects/hpn-ssh. This patch, > in addition to some other things, re-implements the none cipher but > maintains secure authentication. There is a caveat in that you cannot > use the none cipher in interactive sessions - its only for bulk data > transfers. > > You'll need to read the HPN12-README file to learn how to use it. I wish the above mentioned patch could be added to the normal distribution. Ham-radio people that want to use SSH over the air cannot encrypt data communications in the U.S. by FCC regulation, but we are allowed to do authentication. If the regular distribution of openssh had this capability in it again, we could use the standard package off Linux CD's rather than requiring each user to compile the package from sources. For a few of us it isn't a big problem, but for the community as a whole, it is. Any chance of rolling this patch into the main distribution? I asked this some months ago and received zero responses. Pretty please? -- Curt, WE7U: XASTIR: "Lotto: A tax on people who are bad at math." -- unknown "Windows: Microsoft's tax on computer illiterates." -- WE7U The world DOES revolve around me: I picked the coordinate system! From rick.jones2 at hp.com Tue Nov 27 05:14:04 2007 From: rick.jones2 at hp.com (Rick Jones) Date: Mon, 26 Nov 2007 10:14:04 -0800 Subject: Enable gcc's -fstack-protector-all by default? In-Reply-To: <20071126173004.GA2139@gate.dtucker.net> References: <20071126173004.GA2139@gate.dtucker.net> Message-ID: <474B0CEC.6050809@hp.com> Darren Tucker wrote: > Hi all. > > For a while, gcc has supported a stack protection mechanism > (-fstack-protector and friends, available in gcc 4.1.2 and up). > > Can anyone think of a good reason not to enable it if the compiler > supports it? A quick test here shows minimal difference in runtime over > a full regress pass (~10sec over 8.5 minutes, and since the machine is > not entirely idle that could be experimental error). Is this stack protection architecture neutral? rick jones > > Index: configure.ac > =================================================================== > RCS file: /usr/local/src/security/openssh/cvs/openssh/configure.ac,v > retrieving revision 1.386 > diff -u -p -r1.386 configure.ac > --- configure.ac 26 Sep 2007 21:03:20 -0000 1.386 > +++ configure.ac 26 Nov 2007 09:30:15 -0000 > @@ -105,6 +105,15 @@ if test "$GCC" = "yes" || test "$GCC" = > *) ;; > esac > > + AC_MSG_CHECKING(if $GCC understands -fstack-protector-all) > + saved_CFLAGS="$CFLAGS" > + CFLAGS="$CFLAGS -fstack-protector-all" > + AC_TRY_COMPILE([], [ int main(void){return 0;} ], > + [ AC_MSG_RESULT(yes) ], > + [ AC_MSG_RESULT(no) > + CFLAGS="$saved_CFLAGS" ] > + ) > + > if test -z "$have_llong_max"; then > # retry LLONG_MAX with -std=gnu99, needed on some Linuxes > unset ac_cv_have_decl_LLONG_MAX > From dtucker at zip.com.au Tue Nov 27 07:30:09 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 26 Nov 2007 21:30:09 +0100 Subject: Enable gcc's -fstack-protector-all by default? In-Reply-To: <474B0CEC.6050809@hp.com> References: <20071126173004.GA2139@gate.dtucker.net> <474B0CEC.6050809@hp.com> Message-ID: <474B2CD1.4000202@zip.com.au> Rick Jones wrote: > Darren Tucker wrote: [...] >> Can anyone think of a good reason not to enable it if the compiler >> supports it? A quick test here shows minimal difference in runtime over >> a full regress pass (~10sec over 8.5 minutes, and since the machine is >> not entirely idle that could be experimental error). > > Is this stack protection architecture neutral? I'm not sure but I suspect that it is given that HPPA was (last time I looked) one of the main development platforms for gcc and that the documentation doesn't say anything about it being platforms specific. That said I haven't actually tried it on a stack-grows-up architecture like HPPA (and can't at the moment). WRT to the cookie entropy source, it uses a /dev/urandom if you have it, but failing that it will fall back to a static cookie, so it's weaker but not quite worthless if you don't have kernel random support. -- 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 Nov 27 08:51:13 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 26 Nov 2007 22:51:13 +0100 Subject: Enable gcc's -fstack-protector-all by default? In-Reply-To: <474B3784.7080200@hp.com> References: <20071126173004.GA2139@gate.dtucker.net> <474B0CEC.6050809@hp.com> <474B2CD1.4000202@zip.com.au> <474B3784.7080200@hp.com> Message-ID: <474B3FD1.2030305@zip.com.au> Rick Jones wrote: [...] > Just general conservativeness would seem to suggest that until a broader > number of platforms can be covered, it might not be time to become the > default. I should have said "enabled by default if the compiler supports it". If the compiler doesn't, configure continues to behave as before. -- 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 rick.jones2 at hp.com Tue Nov 27 09:25:53 2007 From: rick.jones2 at hp.com (Rick Jones) Date: Mon, 26 Nov 2007 14:25:53 -0800 Subject: Enable gcc's -fstack-protector-all by default? In-Reply-To: <474B3FD1.2030305@zip.com.au> References: <20071126173004.GA2139@gate.dtucker.net> <474B0CEC.6050809@hp.com> <474B2CD1.4000202@zip.com.au> <474B3784.7080200@hp.com> <474B3FD1.2030305@zip.com.au> Message-ID: <474B47F1.9020200@hp.com> Darren Tucker wrote: > Rick Jones wrote: > [...] > >> Just general conservativeness would seem to suggest that until a >> broader number of platforms can be covered, it might not be time to >> become the default. > > > I should have said "enabled by default if the compiler supports it". If > the compiler doesn't, configure continues to behave as before. I inferred that. I'm just thinking that if there isn't certainty of it being sufficiently neutral on a broad swath of platforms, even if the compiler supports it it might be best to leave things be for the moment. rick jones ever the paranoid luddite :) From rick.jones2 at hp.com Tue Nov 27 08:15:48 2007 From: rick.jones2 at hp.com (Rick Jones) Date: Mon, 26 Nov 2007 13:15:48 -0800 Subject: Enable gcc's -fstack-protector-all by default? In-Reply-To: <474B2CD1.4000202@zip.com.au> References: <20071126173004.GA2139@gate.dtucker.net> <474B0CEC.6050809@hp.com> <474B2CD1.4000202@zip.com.au> Message-ID: <474B3784.7080200@hp.com> Darren Tucker wrote: > Rick Jones wrote: > >> Darren Tucker wrote: > > [...] > >>> Can anyone think of a good reason not to enable it if the compiler >>> supports it? A quick test here shows minimal difference in runtime over >>> a full regress pass (~10sec over 8.5 minutes, and since the machine is >>> not entirely idle that could be experimental error). >> >> >> Is this stack protection architecture neutral? > > > I'm not sure but I suspect that it is given that HPPA was (last time I > looked) one of the main development platforms for gcc and that the > documentation doesn't say anything about it being platforms specific. > That said I haven't actually tried it on a stack-grows-up architecture > like HPPA (and can't at the moment). I had IA64 at the back of my mind more than HPPA :) Just general conservativeness would seem to suggest that until a broader number of platforms can be covered, it might not be time to become the default. > > WRT to the cookie entropy source, it uses a /dev/urandom if you have it, > but failing that it will fall back to a static cookie, so it's weaker > but not quite worthless if you don't have kernel random support. > From stuge-openssh-unix-dev at cdy.org Tue Nov 27 15:17:19 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Tue, 27 Nov 2007 05:17:19 +0100 Subject: enable none cipher In-Reply-To: References: <474874F7.8050803@iu-bremen.de> <474B1045.70706@psc.edu> Message-ID: <20071127041719.28868.qmail@cdy.org> On Mon, Nov 26, 2007 at 10:45:00AM -0800, Curt, WE7U wrote: > > the HPN-SSH patch > > I wish the above mentioned patch could be added to the normal > distribution. .. > Any chance of rolling this patch into the main distribution? I > asked this some months ago and received zero responses. Pretty > please? I doubt the full HPN patch will be included anytime soon. But perhaps this specific part of it could be included as a configure option? //Peter From stuge-openssh-unix-dev at cdy.org Tue Nov 27 16:04:52 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Tue, 27 Nov 2007 06:04:52 +0100 Subject: undocumented scp server-side arguments -dft In-Reply-To: References: Message-ID: <20071127050452.6446.qmail@cdy.org> On Sat, Nov 24, 2007 at 07:17:31PM +0200, Pekka Savola wrote: > When implementing forced-commands using authorized-keys, I realized > that scp (when run at the server end) arguments -d, -f and -t are > not documented on the man page. That's because they're internal parts of the scp protocol. //Peter From pekkas at netcore.fi Tue Nov 27 17:10:15 2007 From: pekkas at netcore.fi (Pekka Savola) Date: Tue, 27 Nov 2007 08:10:15 +0200 (EET) Subject: undocumented scp server-side arguments -dft In-Reply-To: <20071127050452.6446.qmail@cdy.org> References: <20071127050452.6446.qmail@cdy.org> Message-ID: On Tue, 27 Nov 2007, Peter Stuge wrote: > On Sat, Nov 24, 2007 at 07:17:31PM +0200, Pekka Savola wrote: >> When implementing forced-commands using authorized-keys, I realized >> that scp (when run at the server end) arguments -d, -f and -t are >> not documented on the man page. > > That's because they're internal parts of the scp protocol. And that's why those need not be documented them because...? End users use these options. -- Pekka Savola "You each name yourselves king, yet the Netcore Oy kingdom bleeds." Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings From rapier at psc.edu Wed Nov 28 03:59:57 2007 From: rapier at psc.edu (Chris Rapier) Date: Tue, 27 Nov 2007 11:59:57 -0500 Subject: enable none cipher In-Reply-To: <20071127041719.28868.qmail@cdy.org> References: <474874F7.8050803@iu-bremen.de> <474B1045.70706@psc.edu> <20071127041719.28868.qmail@cdy.org> Message-ID: <474C4D0D.9050500@psc.edu> Peter Stuge wrote: > On Mon, Nov 26, 2007 at 10:45:00AM -0800, Curt, WE7U wrote: >>> the HPN-SSH patch >> I wish the above mentioned patch could be added to the normal >> distribution. > .. > >> Any chance of rolling this patch into the main distribution? I >> asked this some months ago and received zero responses. Pretty >> please? > > I doubt the full HPN patch will be included anytime soon. No, probably not :) The increase in the buffer size to 2MB will be suitable for most people for the next few years. While I don't think statically defining things is the optimal solution it is a lot easier and avoids problems with the large buffer bug in older revs. > But perhaps this specific part of it could be included as a configure > option? Well... If they're willing I can work on a patch to do this. However, there are really only two important aspects to it - understanding that there is no reason why you can't switch from one cipher to another when you rekey and locking the usage of the none cipher down properly. From bob at proulx.com Wed Nov 28 04:12:13 2007 From: bob at proulx.com (Bob Proulx) Date: Tue, 27 Nov 2007 10:12:13 -0700 Subject: undocumented scp server-side arguments -dft In-Reply-To: References: <20071127050452.6446.qmail@cdy.org> Message-ID: <20071127171213.GA22173@dementia.proulx.com> Pekka Savola wrote: > Peter Stuge wrote: > > That's because they're internal parts of the scp protocol. > > And that's why those need not be documented them because...? Usually undocumented server side options are not for command line use by users. That is the reason they are undocumented. It does not prevent someone from finding out about them and using them anyway but it does discourage it. > End users use these options. End users probably should not be using undocumented options. Using undocumented options should be an alarm that something is wrong. It is better to use the documented interface. I don't know why you are wishing to use those options but I am sure that better and more standard ways exist to accomplish the task without using undocumented options. Bob From lindysandiego at yahoo.com Wed Nov 28 04:52:39 2007 From: lindysandiego at yahoo.com (Thomas Baden) Date: Tue, 27 Nov 2007 09:52:39 -0800 (PST) Subject: undocumented scp server-side arguments -dft In-Reply-To: <20071127171213.GA22173@dementia.proulx.com> Message-ID: <670471.5511.qm@web51708.mail.re2.yahoo.com> Hi Bob, --- Bob Proulx wrote: > I don't know why you are wishing to use those > options but I am sure > that better and more standard ways exist to > accomplish the task > without using undocumented options. I have an example. a shell script executes the following: scp -i magickey somefile someuser at somehost:something 2>someotherfile the .authorized_keys file for someuser on somehost has a command override to execute a script file. the script file on somehost creates a temporary directory (using $$ perhaps) then executes scp -t thatdirectory. When the scp -t finishes, the script does some processing on the received files, perhaps even sending error messages to stderr. Cheers, -Thomas ____________________________________________________________________________________ Be a better pen pal. Text or chat with friends inside Yahoo! Mail. See how. http://overview.mail.yahoo.com/ From dtucker at zip.com.au Wed Nov 28 08:13:36 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 27 Nov 2007 22:13:36 +0100 Subject: Enable gcc's -fstack-protector-all by default? In-Reply-To: <474B47F1.9020200@hp.com> References: <20071126173004.GA2139@gate.dtucker.net> <474B0CEC.6050809@hp.com> <474B2CD1.4000202@zip.com.au> <474B3784.7080200@hp.com> <474B3FD1.2030305@zip.com.au> <474B47F1.9020200@hp.com> Message-ID: <474C8880.4070900@zip.com.au> Rick Jones wrote: > Darren Tucker wrote: >> Rick Jones wrote: >> [...] >> >>> Just general conservativeness would seem to suggest that until a >>> broader number of platforms can be covered, it might not be time to >>> become the default. >> >> >> I should have said "enabled by default if the compiler supports it". >> If the compiler doesn't, configure continues to behave as before. > > I inferred that. I'm just thinking that if there isn't certainty of it > being sufficiently neutral on a broad swath of platforms, even if the > compiler supports it it might be best to leave things be for the moment. Is there any evidence or documentation indicating that it actually causes breakage anywhere? If not I would tend to enable for the compilers that support it. I have built my AIX packages with the flag for the last couple of years without problems, so it's certainly not i386-only. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From deengert at anl.gov Thu Nov 29 04:06:52 2007 From: deengert at anl.gov (Douglas E. Engert) Date: Wed, 28 Nov 2007 11:06:52 -0600 Subject: GSSAPI Key Exchange Patch In-Reply-To: <473DED69.6060301@anl.gov> References: <473D09DC.6090509@taltos.org> <20071116032411.GL5031@tamriel.snowman.net> <473DED69.6060301@anl.gov> Message-ID: <474DA02C.2060803@anl.gov> One final more on de facto source splits. Not only does Solaris 10 and Debian have gss key exchange, there is at least one version of PuTTY with it too: http://rc.quest.com/topics/putty This is listed on http://www.chiark.greenend.org.uk/~sgtatham/putty/links.html It comes with source and the diffs against PuTTY 0.60. But it looks like it uses the SSPI rather then the MIT KfW or either. Douglas E. Engert wrote: > > Stephen Frost wrote: >> * Carson Gaspar (carson at taltos.org) wrote: >>> Damien Miller wrote: >>>> Yes - we are very scared of adding features that lead to more >>>> pre-authentication attack surface, especially when they delegate to >>>> complex libraries with patchy security histories. >>> The risk of a pre-auth GSSAPI bug is far less than the nearly >>> _impossible_ key management problem without it. Sun has integrated the >>> patch. My employer is rolling it out, and is asking Red Hat to include >>> it. At this point, _not_ incorporating it upstream is just leading to a >>> de facto source code fork. I strongly suggest the maintainers reconsider >>> their position. > > > I too agree with the previous responses. We have gotten away from > building OpenSSH in favor of using the vendor's versions. Solaris 10 > and Ubuntu are used widely here and both have gssapi-keyex and work well > togther. The option is on be default in Solaris 10 so anyone > uses Kerberos and ssh on Solaris 10 is using gssapi-keyex. > > Looks like you already have a de facto source split. It would be nice > to get things back in sync. > >> Thanks, >> >> Stephen >> >> >> ------------------------------------------------------------------------ >> >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444