From tim at multitalents.net Mon Oct 1 06:12:51 2007 From: tim at multitalents.net (Tim Rice) Date: Sun, 30 Sep 2007 13:12:51 -0700 (PDT) Subject: openssh v4.7p1: In-Reply-To: <46FF714E.53EB346D@gmx.de> References: <45322194.1B9F836F@gmx.de> <20061016095012.GA3330@gate.dtucker.net> <46FF714E.53EB346D@gmx.de> Message-ID: On Sun, 30 Sep 2007, ThMO wrote: > Hello Darren and others, > > I've appended a small, unified diff fixing a compilation > problem under Linux v2.0.35 using libc v5.4.46: > > ? atomicio.c: > ins't present, but is available. Already fixed in CVS .... 20070927 - (dtucker) [configure.ac atomicio.c] Fall back to including if we don't have (eq QNX). From bacon at cs nyu edu. .... -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From jos at catnook.com Mon Oct 1 09:08:23 2007 From: jos at catnook.com (Jos Backus) Date: Sun, 30 Sep 2007 16:08:23 -0700 Subject: Central principal->user@host management? Message-ID: <20070930230823.GB43927@lizzy.catnook.local> [Apologies if this is an off-topic question; please direct me to a more appropriate place if so.] Using Kerberos/GSSAPIAuthentication, is there a way to centrally control/manage (perhaps using LDAP?) which user principals can log into what hosts/accounts? -- Jos Backus jos at catnook.com From David.Leonard at quest.com Mon Oct 1 11:40:45 2007 From: David.Leonard at quest.com (David Leonard) Date: Mon, 01 Oct 2007 11:40:45 +1000 Subject: Central principal->user@host management? In-Reply-To: <20070930230823.GB43927@lizzy.catnook.local> References: <20070930230823.GB43927@lizzy.catnook.local> Message-ID: <4700501D.20501@quest.com> Jos Backus wrote: > [Apologies if this is an off-topic question; please direct me to a more > appropriate place if so.] > > Using Kerberos/GSSAPIAuthentication, is there a way to centrally > control/manage (perhaps using LDAP?) which user principals can log into what > hosts/accounts? > > I don't know about centrally managing, except by ensuring that user principal names align with unix accountnames, but for local account control, sshd calls krb5_kuserok(). This function looks for the file ~user/.k5login and if it exists, only allows access if the authenticated user principal is listed therein. d From hotz at jpl.nasa.gov Mon Oct 1 18:08:55 2007 From: hotz at jpl.nasa.gov (Henry B. Hotz) Date: Mon, 1 Oct 2007 01:08:55 -0700 Subject: GSSAPI Key Exchange Patch for OpenSSH 4.7p1 In-Reply-To: <46FD7176.3020108@anl.gov> References: <0DC5C238-7F48-41F5-A0DB-DEF62E0698D8@inf.ed.ac.uk> <46FD7176.3020108@anl.gov> Message-ID: That does sound interesting. Count me in. On Sep 28, 2007, at 2:26 PM, Douglas E. Engert wrote: > Sounds interesting. And yes, I would be interested in > the cascading credentials delegation code. Does the > delegation code depend on the key exchange code? > > What would it take to get both of these in to PuTTY? > > > Simon Wilkinson wrote: >> -----BEGIN PGP SIGNED MESSAGE----- >> Hash: SHA1 >> Hi, >> I'm pleased to (finally) announce the availability of my GSSAPI >> Key Exchange patch for OpenSSH 4.7p1. Whilst OpenSSH contains >> support for doing GSSAPI user authentication, this only allows >> the underlying security mechanism to authenticate the user to the >> server, and continues to use SSH host keys to authenticate the >> server to the user. For many sites who already have security >> infrastructures such as Kerberos deployed, managing large numbers >> of SSH host keys is an additional, unneccessary, burden. GSSAPI >> key exchange allows the use of security mechanisms such as >> Kerberos to authenticate the server to the user, removing the >> need for trusted ssh host keys, and allowing the use of a single >> security architecture. >> This patch adds support for the RFC4462 GSSAPI key exchange >> mechanisms to OpenSSH, along with adding some additional features >> to the GSSAPI code that is already in the tree. >> The patch implements: >> *) gss-group1-sha1-*, gss-group14-sha1-* and gss-gex-sha1-* >> key exchange mechanisms. (#1242) >> *) Support for the null host key type (#1242) >> *) Support for CCAPI credentials caches on Mac OS X (#1245) >> *) Support for better error handling when an authentication >> exchange fails due to server misconfiguration (#1244) >> *) Support for GSSAPI connections to hosts behind a round- >> robin load balancer (#1008) >> *) Support for GSSAPI connections to multi-homed hosts, where >> each interface has a unique name (#928) >> (bugzilla.mindrot.org bug numbers are in brackets) >> There are no code changes since the previous release. >> As usual, the code is available from >> http://www.sxw.org.uk/computing/patches/openssh.html >> I'm also interesting in hearing from people who might be >> interested in testing some new cascading credentials delegation >> code. When you renew your Kerberos credentials on the client, >> this code will automatically propagate these renewed credentials >> to the server, allowing the seamless renewal of credentials >> across ssh sessions distributed across many different machines. >> If you have an interest in testing this code in a non-production >> environment, please let me know! >> Cheers, >> Simon. ------------------------------------------------------------------------ The opinions expressed in this message are mine, not those of Caltech, JPL, NASA, or the US Government. Henry.B.Hotz at jpl.nasa.gov, or hbhotz at oxy.edu From jos at catnook.com Tue Oct 2 02:02:28 2007 From: jos at catnook.com (Jos Backus) Date: Mon, 1 Oct 2007 09:02:28 -0700 Subject: Central principal->user@host management? In-Reply-To: <4700501D.20501@quest.com> References: <20070930230823.GB43927@lizzy.catnook.local> <4700501D.20501@quest.com> Message-ID: <20071001160228.GA51999@lizzy.catnook.local> On Mon, Oct 01, 2007 at 11:40:45AM +1000, David Leonard wrote: > Jos Backus wrote: > > [Apologies if this is an off-topic question; please direct me to a more > > appropriate place if so.] > > > > Using Kerberos/GSSAPIAuthentication, is there a way to centrally > > control/manage (perhaps using LDAP?) which user principals can log into what > > hosts/accounts? > > > > > I don't know about centrally managing, except by ensuring that user > principal names align with unix accountnames, but for local account > control, sshd calls krb5_kuserok(). This function looks for the file > ~user/.k5login and if it exists, only allows access if the authenticated > user principal is listed therein. I'm aware of this. But I have a hard time justifying Kerberos (and the associated complexity it introduces) if it can't meet this requirement whereas distributing authorized_keys files using Puppet on all hosts can. -- Jos Backus jos at catnook.com From deengert at anl.gov Tue Oct 2 02:22:57 2007 From: deengert at anl.gov (Douglas E. Engert) Date: Mon, 01 Oct 2007 11:22:57 -0500 Subject: Central principal->user@host management? In-Reply-To: <20070930230823.GB43927@lizzy.catnook.local> References: <20070930230823.GB43927@lizzy.catnook.local> Message-ID: <47011EE1.3090706@anl.gov> Jos Backus wrote: > [Apologies if this is an off-topic question; please direct me to a more > appropriate place if so.] > > Using Kerberos/GSSAPIAuthentication, is there a way to centrally > control/manage (perhaps using LDAP?) which user principals can log into what > hosts/accounts? In addition to the ~.k5login, sounds like what you would like would be a krb5.conf [realm] auth_to_local=LDAP:.... option. But I don't know if one exists. (Would be nice if it did...) There is a auth_to_local=DB:... option that uses a local database. > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From jos at catnook.com Tue Oct 2 09:42:44 2007 From: jos at catnook.com (Jos Backus) Date: Mon, 1 Oct 2007 16:42:44 -0700 Subject: Central principal->user@host management? In-Reply-To: <47011EE1.3090706@anl.gov> References: <20070930230823.GB43927@lizzy.catnook.local> <47011EE1.3090706@anl.gov> Message-ID: <20071001234244.GA55790@lizzy.catnook.local> On Mon, Oct 01, 2007 at 11:22:57AM -0500, Douglas E. Engert wrote: > In addition to the ~.k5login, sounds like what you would like would be a > krb5.conf [realm] auth_to_local=LDAP:.... option. But I don't know > if one exists. (Would be nice if it did...) There is a auth_to_local=DB:... > option that uses a local database. Using a local db would be tantamount to managing .k5login files so that doesn't really help. Regarding LDAP support, one consideration is that sshd would have to be able to authenticate the LDAP server (using Kerberos) to prevent spoofing. This adds yet more complexity. So I am wondering if given the stated requirement, Kerberos is the right choice. Should I just be (securely) distributing authorized_keys files? What am I missing? Thanks, -- Jos Backus jos at catnook.com From deengert at anl.gov Tue Oct 2 23:45:33 2007 From: deengert at anl.gov (Douglas E. Engert) Date: Tue, 02 Oct 2007 08:45:33 -0500 Subject: Central principal->user@host management? In-Reply-To: <20071001234244.GA55790@lizzy.catnook.local> References: <20070930230823.GB43927@lizzy.catnook.local> <47011EE1.3090706@anl.gov> <20071001234244.GA55790@lizzy.catnook.local> Message-ID: <47024B7D.4030007@anl.gov> Jos Backus wrote: > On Mon, Oct 01, 2007 at 11:22:57AM -0500, Douglas E. Engert wrote: >> In addition to the ~.k5login, sounds like what you would like would be a >> krb5.conf [realm] auth_to_local=LDAP:.... option. But I don't know >> if one exists. (Would be nice if it did...) There is a auth_to_local=DB:... >> option that uses a local database. > > Using a local db would be tantamount to managing .k5login files so that > doesn't really help. The main differences are the ~/.k5login is under control of the user, and may be located in a NFS shared home directory. The db is under control of the admin. > Regarding LDAP support, one consideration is that sshd > would have to be able to authenticate the LDAP server (using Kerberos) to > prevent spoofing. I think you said you where using LDAP. This situation is no different from using nss-ldap, to replace the passwd and group files. The libnss-ldap has to authenticate the ldap server to avoid spoofing. The k5login could be just another nisMap with nisObjects table much like autofs can use ldap. This adds yet more complexity. The complexity should be in the krb5 libs under the krb5_kuserok routine, so sshd has no changes. But the code has not been written as far as I know. > > So I am wondering if given the stated requirement, Kerberos is the right > choice. Should I just be (securely) distributing authorized_keys files? What > am I missing? > > Thanks, -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From 1.41421 at gmail.com Wed Oct 3 02:24:45 2007 From: 1.41421 at gmail.com (JCA) Date: Tue, 2 Oct 2007 09:24:45 -0700 Subject: OpenSSH clients causing deadlocks Message-ID: OpenSSH clients (in all releases I have been able to test with, including 4.7p1) when talking protocol version 2 seem to be sending SSH_MSG_CHANNEL_REQUEST messages with the want_reply field set to 0. This leads to a problem when the server they interact with does not support the service being requested. If the channel request is for, say, command execution, and the server does not support such a capability, a standards-compliant server won't send anything back at that point - because the OpenSSH client has set the want_reply field to 0. However, the OpenSSH client seems to be assuming that this request will always be successful. That is, that servers will always support this capability. Because of this assumption, a deadlock ensues. This is a bug in the OpenSSH client. It is true that for some channel requests (e.g. things like, say, X11 and XON/XOFF requests) the client can proceed (and does proceed) without the server replying anything, but for others (most notably SHELL and EXEC) it can't. The OpenSSH client should always set want_reply to 1 when sending such requests, in order to prevent deadlocks like the one described above. From jos at catnook.com Wed Oct 3 02:43:34 2007 From: jos at catnook.com (Jos Backus) Date: Tue, 2 Oct 2007 09:43:34 -0700 Subject: Central principal->user@host management? In-Reply-To: <47024B7D.4030007@anl.gov> References: <20070930230823.GB43927@lizzy.catnook.local> <47011EE1.3090706@anl.gov> <20071001234244.GA55790@lizzy.catnook.local> <47024B7D.4030007@anl.gov> Message-ID: <20071002164334.GA64257@lizzy.catnook.local> On Tue, Oct 02, 2007 at 08:45:33AM -0500, Douglas E. Engert wrote: > Jos Backus wrote: > > On Mon, Oct 01, 2007 at 11:22:57AM -0500, Douglas E. Engert wrote: > >> In addition to the ~.k5login, sounds like what you would like would be a > >> krb5.conf [realm] auth_to_local=LDAP:.... option. But I don't know > >> if one exists. (Would be nice if it did...) There is a auth_to_local=DB:... > >> option that uses a local database. > > > > Using a local db would be tantamount to managing .k5login files so that > > doesn't really help. > > The main differences are the ~/.k5login is under control of the user, > and may be located in a NFS shared home directory. The db is under control > of the admin. Sure. But it's still something to be managed on the machine itself, rather than centrally. > > Regarding LDAP support, one consideration is that sshd > > would have to be able to authenticate the LDAP server (using Kerberos) to > > prevent spoofing. > > I think you said you where using LDAP. This situation is no different from > using nss-ldap, to replace the passwd and group files. The libnss-ldap has > to authenticate the ldap server to avoid spoofing. The k5login could be just > another nisMap with nisObjects table much like autofs can use ldap. We are using nss-ldap at present for that puprpose. And frankly I'm not that worried about the spoofing part since all this is on an internal network. So are you saying I could stick .k5login data in LDAP and thus not have to manage local .k5login files? That would be a reasonable soltion. Any pointers on how to set this up? > This adds yet more complexity. > > The complexity should be in the krb5 libs under the krb5_kuserok routine, > so sshd has no changes. But the code has not been written as far as I know. Agreed. Thanks for your response, Douglas. -- Jos Backus jos at catnook.com From questforkrishna at yahoo.com Wed Oct 3 05:16:59 2007 From: questforkrishna at yahoo.com (prashanth kodoth) Date: Tue, 2 Oct 2007 12:16:59 -0700 (PDT) Subject: i would like to subscribe Message-ID: <163736.7161.qm@web34701.mail.mud.yahoo.com> --------------------------------- Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase. From deengert at anl.gov Wed Oct 3 07:44:49 2007 From: deengert at anl.gov (Douglas E. Engert) Date: Tue, 02 Oct 2007 16:44:49 -0500 Subject: Central principal->user@host management? In-Reply-To: <20071002164334.GA64257@lizzy.catnook.local> References: <20070930230823.GB43927@lizzy.catnook.local> <47011EE1.3090706@anl.gov> <20071001234244.GA55790@lizzy.catnook.local> <47024B7D.4030007@anl.gov> <20071002164334.GA64257@lizzy.catnook.local> Message-ID: <4702BBD1.4090503@anl.gov> Jos Backus wrote: > On Tue, Oct 02, 2007 at 08:45:33AM -0500, Douglas E. Engert wrote: >> Jos Backus wrote: >>> On Mon, Oct 01, 2007 at 11:22:57AM -0500, Douglas E. Engert wrote: >>>> In addition to the ~.k5login, sounds like what you would like would be a >>>> krb5.conf [realm] auth_to_local=LDAP:.... option. But I don't know >>>> if one exists. (Would be nice if it did...) There is a auth_to_local=DB:... >>>> option that uses a local database. >>> Using a local db would be tantamount to managing .k5login files so that >>> doesn't really help. >> The main differences are the ~/.k5login is under control of the user, >> and may be located in a NFS shared home directory. The db is under control >> of the admin. > > Sure. But it's still something to be managed on the machine itself, rather > than centrally. > >>> Regarding LDAP support, one consideration is that sshd >>> would have to be able to authenticate the LDAP server (using Kerberos) to >>> prevent spoofing. >> I think you said you where using LDAP. This situation is no different from >> using nss-ldap, to replace the passwd and group files. The libnss-ldap has >> to authenticate the ldap server to avoid spoofing. The k5login could be just >> another nisMap with nisObjects table much like autofs can use ldap. > > We are using nss-ldap at present for that puprpose. And frankly I'm not that > worried about the spoofing part since all this is on an internal network. > > So are you saying I could stick .k5login data in LDAP and thus not have to > manage local .k5login files? That would be a reasonable soltion. Any pointers > on how to set this up? > But the code has not been written as far as I know. I would add it to the krb5 libs, and add another auth_to_local= option for LDAP... This should be moved to the kerberos at mit.edu list... >> This adds yet more complexity. >> >> The complexity should be in the krb5 libs under the krb5_kuserok routine, >> so sshd has no changes. But the code has not been written as far as I know. > > Agreed. > > Thanks for your response, Douglas. > -- Douglas E. Engert Argonne National Laboratory 9700 South Cass Avenue Argonne, Illinois 60439 (630) 252-5444 From guyverdh at hotmail.com Wed Oct 3 05:42:18 2007 From: guyverdh at hotmail.com (Larry Becke) Date: Tue, 2 Oct 2007 14:42:18 -0500 Subject: scp -t . - possible idea for additional parameter Message-ID: How difficult would it be to add an additional parameter to the -t that would *lock* the user at that directory level. say -T instead of -t... By locking, I mean translating /path/to/file as ./path/to/file, or ../../../path/../../../path/to/file as ./path/to/file. Basically set a root point as the current home directory, then build the pathing based on that, any "../" would become "./" if the "../" would go above that home directory. Just a thought... _________________________________________________________________ Peek-a-boo FREE Tricks & Treats for You! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us From bob at proulx.com Wed Oct 3 10:39:20 2007 From: bob at proulx.com (Bob Proulx) Date: Tue, 2 Oct 2007 18:39:20 -0600 Subject: scp -t . - possible idea for additional parameter In-Reply-To: References: Message-ID: <20071003003920.GA24628@dementia.proulx.com> Larry Becke wrote: > By locking, I mean translating /path/to/file as ./path/to/file, or > ../../../path/../../../path/to/file as ./path/to/file. > > Basically set a root point as the current home directory, then build > the pathing based on that, any "../" would become "./" if the "../" > would go above that home directory. Not sure this is what you want but look into the 'rsync --relative' option. http://rsync.samba.org/ http://rsync.samba.org/ftp/rsync/rsync.html Bob From guyverdh at hotmail.com Wed Oct 3 17:46:06 2007 From: guyverdh at hotmail.com (Larry Becke) Date: Wed, 3 Oct 2007 02:46:06 -0500 Subject: scp -t . - possible idea for additional parameter In-Reply-To: <20071003003920.GA24628@dementia.proulx.com> References: <20071003003920.GA24628@dementia.proulx.com> Message-ID: One of the minor issues we face as we tackle security issues is the idea that scp allows someone to navigate directory structures that aren't restricted to the user that is logging in. If we were to implement a switch that a) forced pathing to be relative to the startup directory parameter, and b) either filtered the client side scp command parameters to ensure that it remained relative, or errored out if "../" were used as part of the destination path parameter. How this is implemented is by tying keys to specific directories, so when you scp -i xyz_key filename.ext remhost: the remote server is configured to do command="/full/path/to/bin/scp -t /some/home/dir" It would copy the filename.ext file to the /some/home/dir directory on remhost. However, at this time, this does not *lock* the user into that directory. If they were to execute scp -i xyz_key filename.ext remhost:/tmp It would allow the user to copy filename.ext to the /tmp directory on remhost. If we implemented -T to force relative to startup path, then command="/full/path/to/bin/scp -T /some/home/dir" when the user used scp -i xyz_key filename.ext remhost:/tmp it would attempt to copy the file to /some/home/dir/tmp on remhost If /some/home/dir/tmp didn't exist on remhost, it would fail. That is what I am looking for, and am hoping would be trivial to implement. This would give a relatively simple way to control where a user went, and if configured as a startup parameter in sshd_config, could force *all* scp connections to be relative. > Date: Tue, 2 Oct 2007 18:39:20 -0600> To: guyverdh at hotmail.com> CC: openssh-unix-dev at mindrot.org> Subject: Re: scp -t . - possible idea for additional parameter> From: bob at proulx.com> > Larry Becke wrote:> > By locking, I mean translating /path/to/file as ./path/to/file, or> > ../../../path/../../../path/to/file as ./path/to/file.> > > > Basically set a root point as the current home directory, then build> > the pathing based on that, any "../" would become "./" if the "../"> > would go above that home directory.> > Not sure this is what you want but look into the 'rsync --relative'> option.> > http://rsync.samba.org/> http://rsync.samba.org/ftp/rsync/rsync.html> > Bob _________________________________________________________________ Help yourself to FREE treats served up daily at the Messenger Caf?. Stop by today. http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline From becasuno at orona.es Wed Oct 3 20:35:13 2007 From: becasuno at orona.es (BecaSuNo) Date: Wed, 3 Oct 2007 12:35:13 +0200 Subject: OpenSSH in an ARM Linux Board Message-ID: Hi all, I'm working in a project where I need to make a remoting control of Linux based ARM board (iMX1 from Freescale). I think OpenSSH would be a good solution, but I have a little problem. As you know, normally there's no X framework in an embedded device, and I work using DirectFB to make my graphical apps. The question is: is there any chance to work with OpenSSH but not using X framework? I know I can work by console, but I need to see what's happening in my TFT screen. Thanks in advance, best regards, Gorka Luarizayerdi From dtucker at zip.com.au Thu Oct 4 06:53:44 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 04 Oct 2007 06:53:44 +1000 Subject: OpenSSH in an ARM Linux Board In-Reply-To: References: Message-ID: <47040158.8040003@zip.com.au> BecaSuNo wrote: > Hi all, I'm working in a project where I need to make a remoting > control of Linux based ARM board (iMX1 from Freescale). I think > OpenSSH would be a good solution, but I have a little problem. > As you know, normally there's no X framework in an embedded device, > and I work using DirectFB to make my graphical apps. The question is: > is there any chance to work with OpenSSH but not using X framework? OpenSSH doesn't do much special for X other than provide a way for X clients and servers to talk over the encrypted channel. > I know I can work by console, but I need to see what's happening in my TFT screen. Have you considered something like VNC for your framebuffer? That can be tunneled over SSH pretty easily and would seem better suited to your requirements. -- 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 Thu Oct 4 12:20:06 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 4 Oct 2007 04:20:06 +0200 Subject: scp -t . - possible idea for additional parameter In-Reply-To: References: <20071003003920.GA24628@dementia.proulx.com> Message-ID: <20071004022006.9438.qmail@cdy.org> On Wed, Oct 03, 2007 at 02:46:06AM -0500, Larry Becke wrote: > One of the minor issues we face as we tackle security issues is the > idea that scp allows someone to navigate directory structures that > aren't restricted to the user that is logging in. That is not how scp works, that is how the server operating system works. scp does not allow or enable anything that has been disabled before or outside scp. OpenSSH uses the user's shell for any and all executions on behalf of a user, including scp and sftp-server. If you want to restrict users, the shell is a nice place to implement policy. //Peter From becasuno at orona.es Thu Oct 4 19:27:23 2007 From: becasuno at orona.es (BecaSuNo) Date: Thu, 4 Oct 2007 11:27:23 +0200 Subject: OpenSSH in an ARM Linux Board Message-ID: Darren Tucker wrote: > Have you considered something like VNC for your framebuffer? That can be tunneled over SSH pretty easily and would seem better suited to your requirements. Thanks for your replay, I was thinking in that option. I'll take a look at it. Best regards, Gorka Luarizayerdi From c.wesseling at googlemail.com Mon Oct 8 19:29:10 2007 From: c.wesseling at googlemail.com (Christofer Wesseling) Date: Mon, 8 Oct 2007 11:29:10 +0200 Subject: missing ssh.c - at ./configure Message-ID: Hi! I got the following error at ./configure: configure: error: cannot find sources (ssh.c) in . or .. Some Details around...: Code-Version: openssh-4.3p2 System: Ubuntu 7.04 * zlib und ssh-devel packages installed. I'm sure someone of you knows how i can fix that problem... :) greets! Christofer From c.wesseling at googlemail.com Tue Oct 9 19:25:42 2007 From: c.wesseling at googlemail.com (Christofer Wesseling) Date: Tue, 9 Oct 2007 11:25:42 +0200 Subject: missing ssh.c - at ./configure In-Reply-To: References: Message-ID: no one an idea? ---------- Forwarded message ---------- From: Christofer Wesseling Date: 08.10.2007 11:29 Subject: missing ssh.c - at ./configure To: openssh-unix-dev at mindrot.org Hi! I got the following error at ./configure: configure: error: cannot find sources (ssh.c) in . or .. Some Details around...: Code-Version: openssh-4.3p2 System: Ubuntu 7.04 * zlib und ssh-devel packages installed. I'm sure someone of you knows how i can fix that problem... :) greets! Christofer From gert at greenie.muc.de Tue Oct 9 19:51:32 2007 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 9 Oct 2007 11:51:32 +0200 Subject: missing ssh.c - at ./configure In-Reply-To: References: Message-ID: <20071009095131.GB101@greenie.muc.de> Hi, On Tue, Oct 09, 2007 at 11:25:42AM +0200, Christofer Wesseling wrote: > no one an idea? Wherever you got the sources from, the package is incomplete. Re-download the source tar package. gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From gert at greenie.muc.de Tue Oct 9 20:18:46 2007 From: gert at greenie.muc.de (Gert Doering) Date: Tue, 9 Oct 2007 12:18:46 +0200 Subject: missing ssh.c - at ./configure In-Reply-To: References: <20071009095131.GB101@greenie.muc.de> Message-ID: <20071009101845.GC101@greenie.muc.de> Hi, (please do not take mailing list discussions offline to private mail) On Tue, Oct 09, 2007 at 12:08:14PM +0200, Christofer Wesseling wrote: > thanks for your answer. i got the source from cvs and from a direct download > via website.. - are you sure that it must be incomplete? shouldn't the file > be in the CVS then? Well, your e-mail was a bit incomplete - do you *have* a "ssh.c" file, and configure isn't finding it? Or is the ssh.c file indeed missing? If you have a ssh.c file, posting a few more lines from the configure output might give advice why it's failing (maybe "no C compiler there" or some other tool missing). gert -- USENET is *not* the non-clickable part of WWW! //www.muc.de/~gert/ Gert Doering - Munich, Germany gert at greenie.muc.de fax: +49-89-35655025 gert at net.informatik.tu-muenchen.de From guyverdh at hotmail.com Wed Oct 10 05:29:37 2007 From: guyverdh at hotmail.com (Larry Becke) Date: Tue, 9 Oct 2007 14:29:37 -0500 Subject: No subject Message-ID: I understand that that is not how scp works today. I'm suggesting that we make a minor change to how it works. Here's the underlying reason why I think this is a good idea. The efforts required to lock down todays systems with their myriad of access features is not a trivial task. I'm not suggesting this will make it trivial to completely secure a system. I am suggesting this will make it trivial to secure one subset of the system. That subset being scp. Using chroot'd environments doesn't really work (or at least they were never intended to be used as a security tool) without tons of effort, and even then, they tend to break rapidly with simple system/software updates. sftp at the present time, gives access to too many additional commands / features that are unnecessary for a simple file transfer. scp would fit the bill nicely, with one minor change. Let's forget about translating ../ to something else. Given the "-T" instead of "-t" startup parameter, a simple walk through the parameters passed by the scp client spawning the scp server should do the following: Prefix the remote path with "./", so that remhost:/path/to/file becomes remhost:.//path/to/file. If the remote path contains "../" anywhere, error out. With this change, we can forget about scp-only or chroot'd environments and all the convoluted mess required to make that work. Either spawn scp with the "-T" via a public key authentication command entry, or the sshd_config file "UseSCPPathLock=Yes". Through this option, we get a secure method of transfering files without much effort. Combine this with pub-key authentication, and command= parameters, you can control where any user places their files if outside of their home directories. Simple user permissions on the remote server control whether or not writes are allowed, or just reads. A very simple change could open a whole lot of opportunity for usage expansion. If sftp-server had this same option, then that might work, however, I haven't seen that it does - yet there would seem to me to be a lot more changes required to implement the same idea within sftp-server as it would within scp. _________________________________________________________________ Windows Live Hotmail and Microsoft Office Outlook ? together at last. ?Get it now. http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=CL100626971033 From guyverdh at hotmail.com Wed Oct 10 05:30:51 2007 From: guyverdh at hotmail.com (Larry Becke) Date: Tue, 9 Oct 2007 14:30:51 -0500 Subject: scp -t . - possible idea for additional parameter Message-ID: I understand that that is not how scp works today. I'm suggesting that we make a minor change to how it works. Here's the underlying reason why I think this is a good idea. The efforts required to lock down todays systems with their myriad of access features is not a trivial task. I'm not suggesting this will make it trivial to completely secure a system. I am suggesting this will make it trivial to secure one subset of the system. That subset being scp. Using chroot'd environments doesn't really work (or at least they were never intended to be used as a security tool) without tons of effort, and even then, they tend to break rapidly with simple system/software updates. sftp at the present time, gives access to too many additional commands / features that are unnecessary for a simple file transfer. scp would fit the bill nicely, with one minor change. Let's forget about translating ../ to something else. Given the "-T" instead of "-t" startup parameter, a simple walk through the parameters passed by the scp client spawning the scp server should do the following:Prefix the remote path with "./", so that remhost:/path/to/file becomes remhost:.//path/to/file.If the remote path contains "../" anywhere, error out. With this change, we can forget about scp-only or chroot'd environments and all the convoluted mess required to make that work. Either spawn scp with the "-T" via a public key authentication command entry, or the sshd_config file "UseSCPPathLock=Yes". Through this option, we get a secure method of transfering files without much effort. Combine this with pub-key authentication, and command= parameters, you can control where any user places their files if outside of their home directories. Simple user permissions on the remote server control whether or not writes are allowed, or just reads. A very simple change could open a whole lot of opportunity for usage expansion. If sftp-server had this same option, then that might work, however, I haven't seen that it does - yet there would seem to me to be a lot more changes required to implement the same idea within sftp-server as it would within scp. _________________________________________________________________ Help yourself to FREE treats served up daily at the Messenger Caf?. Stop by today. http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline From stuge-openssh-unix-dev at cdy.org Wed Oct 10 14:12:38 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Wed, 10 Oct 2007 06:12:38 +0200 Subject: your mail In-Reply-To: References: Message-ID: <20071010041238.2211.qmail@cdy.org> On Tue, Oct 09, 2007 at 02:29:37PM -0500, Larry Becke wrote: > I understand that that is not how scp works today. And it will likely never change. > I'm suggesting that we make a minor change to how it works. scp is maintained for compatibility reasons only, as I've understood things. > I am suggesting this will make it trivial to secure one subset of > the system. That subset being scp. Moot point unless scp is the only way users can use the system, which I don't think is the case all too often. Either you're prepared to make an effort in order to make the system secure, or it doesn't matter. Hacking up scp is good for neither. :\ //Peter From rapier at psc.edu Thu Oct 11 01:15:39 2007 From: rapier at psc.edu (Chris Rapier) Date: Wed, 10 Oct 2007 11:15:39 -0400 Subject: your mail In-Reply-To: <20071010041238.2211.qmail@cdy.org> References: <20071010041238.2211.qmail@cdy.org> Message-ID: <470CEC9B.8070904@psc.edu> Peter Stuge wrote: > On Tue, Oct 09, 2007 at 02:29:37PM -0500, Larry Becke wrote: >> I understand that that is not how scp works today. > > And it will likely never change. Which is unfortunate because scp is, based on the logs I have access to, what most users are using to transfer files. As much as it might be nice if they moved to sftp I don't see it happening with any real rapidity. We can argue all we like that sftp is better or rsync is superior but unless the users agree it doesn't matter what we might happen to think. I'm not saying that to be snotty or confrontational - only as an observation of what I see around me. >> I am suggesting this will make it trivial to secure one subset of >> the system. That subset being scp. > > Moot point unless scp is the only way users can use the system, which > I don't think is the case all too often. No but unless you remove scp entirely many users, if not most, will keep using it. Now, its possible that through user education you may be able to tip the scales and get more of them to use sftp or some other method. Of course, if user education really worked well half of us would probably be out of work. > Either you're prepared to make an effort in order to make the system > secure, or it doesn't matter. Hacking up scp is good for neither. :\ Why not? I mean, we always hear people saying that scp is only in there for compatibility reasons but what, precisely, is wrong with scp? If there is something wrong with it then doesn't it makes sense to simply stop distributing it? If there is nothing wrong with it then doesn't it make sense to actually improve it to bring added functionality to users? Chris From guyverdh at hotmail.com Thu Oct 11 02:00:43 2007 From: guyverdh at hotmail.com (Larry Becke) Date: Wed, 10 Oct 2007 11:00:43 -0500 Subject: =?windows-1256?Q?Re:_scp_-t_._-_possible_idea_for_additional_parameter=FE?= Message-ID: >> I understand that that is not how scp works today.>And it will likely never change. Why not? Just because "That's how we've always not done it" doesn't sound like a very good reason to me. >> I'm suggesting that we make a minor change to how it works.>scp is maintained for compatibility reasons only, as I've understood>things. That's still not a valid reason to not implement a very simple change. >> I am suggesting this will make it trivial to secure one subset of>> the system. That subset being scp.>Moot point unless scp is the only way users can use the system, which>I don't think is the case all too often. In my specific case, it is the point. I'm using a public key authentication, where the parameter defined in the authorized_keys file is command="/usr/local/bin/scp -t /some/path/to/dir" ....remainder of key.... >Either you're prepared to make an effort in order to make the system>secure, or it doesn't matter. Hacking up scp is good for neither. :\ Why should *everyone else in the world* have to go through all the hassle of trying to make a "secure" product secure, when a very simple fix, would effectively lock scp so that it couldn't go anywhere above the directory specified in the startup with the -T (like -t) parameter. The simple change outlined would truly make scp *secure* from all perspectives, as opposed to only being secure via the transport. It could be a significant feather in the cap of the project. If the -T were configurable to be a selectable (either through the build process, or the sshd_config file) all scp transfers could be locked into the user's home directory, which wouldn't be a bad thing at all for those who would want it to be that way. Larry _________________________________________________________________ Help yourself to FREE treats served up daily at the Messenger Caf?. Stop by today. http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline From Jefferson.Ogata at noaa.gov Thu Oct 11 02:07:58 2007 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Wed, 10 Oct 2007 16:07:58 +0000 Subject: =?windows-1256?Q?Re=3A_scp_-t_=2E_-_possible_idea_?= =?windows-1256?Q?for_additional_parameter=FE?= In-Reply-To: References: Message-ID: <470CF8DE.4060306@noaa.gov> On 10/10/07 16:00, Larry Becke wrote: > Why should *everyone else in the world* have to go through all the hassle of trying to make a "secure" product secure, when a very simple fix, would effectively lock scp so that it couldn't go anywhere above the directory specified in the startup with the -T (like -t) parameter. 1. Why do you think this change provides effective security? 2. Have you ever tried to implement something like this, dealing with symbolic links, bind mounts, etc.? If you want to confine users effectively, chroot them. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From Jan.Pechanec at Sun.COM Thu Oct 11 02:08:11 2007 From: Jan.Pechanec at Sun.COM (Jan Pechanec) Date: Wed, 10 Oct 2007 18:08:11 +0200 (CEST) Subject: PATCH: incorrect behaviour of 'ssh-keygen -HF' Message-ID: hi, the corner case of '-HF' hashes the whole hostline and not just the host xor IP address which means that usually it will hash "HOST,IP". This will never be matched if manually included into the known_host file. Patch against 4.7p1 attached. J. -- Jan Pechanec -------------- next part -------------- --- openssh-4.7p1/ssh-keygen.c Mon Feb 19 12:10:25 2007 +++ openssh-4.7p1-patched/ssh-keygen.c Wed Oct 10 17:38:05 2007 @@ -598,7 +598,7 @@ } static void -print_host(FILE *f, char *name, Key *public, int hash) +print_host(FILE *f, const char *name, Key *public, int hash) { if (hash && (name = host_hash(name, NULL, 0)) == NULL) fatal("hash_host failed"); @@ -726,7 +726,7 @@ printf("# Host %s found: " "line %d type %s\n", name, num, key_type(public)); - print_host(out, cp, public, hash_hosts); + print_host(out, name, public, hash_hosts); } if (delete_host && !c) print_host(out, cp, public, 0); From rapier at psc.edu Thu Oct 11 02:32:17 2007 From: rapier at psc.edu (Chris Rapier) Date: Wed, 10 Oct 2007 12:32:17 -0400 Subject: =?windows-1252?Q?Re=3A_scp_-t_=2E_-_possible_idea_?= =?windows-1252?Q?for_additional_parameter=3F?= In-Reply-To: <470CF8DE.4060306@noaa.gov> References: <470CF8DE.4060306@noaa.gov> Message-ID: <470CFE91.9060409@psc.edu> Just as a note: http://kerneltrap.org/Linux/Abusing_chroot This isn't to say that chroot jails aren't useful. Only that they aren't a fix all. Further exploration of other methodologies seems like it would be an overall benefit to the community. Jefferson Ogata wrote: > On 10/10/07 16:00, Larry Becke wrote: >> Why should *everyone else in the world* have to go through all the hassle of trying to make a "secure" product secure, when a very simple fix, would effectively lock scp so that it couldn't go anywhere above the directory specified in the startup with the -T (like -t) parameter. > > 1. Why do you think this change provides effective security? > > 2. Have you ever tried to implement something like this, dealing with > symbolic links, bind mounts, etc.? > > If you want to confine users effectively, chroot them. > From Jefferson.Ogata at noaa.gov Thu Oct 11 03:04:41 2007 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Wed, 10 Oct 2007 17:04:41 +0000 Subject: scp -t . - possible idea for additional parameter? In-Reply-To: <470CFE91.9060409@psc.edu> References: <470CF8DE.4060306@noaa.gov> <470CFE91.9060409@psc.edu> Message-ID: <470D0629.1000605@noaa.gov> On 10/10/07 16:32, Chris Rapier wrote: > Just as a note: > http://kerneltrap.org/Linux/Abusing_chroot Of course chroot can be abused. You have to know what you're doing to set it up correctly. > This isn't to say that chroot jails aren't useful. Only that they aren't > a fix all. Further exploration of other methodologies seems like it > would be an overall benefit to the community. For me, ssh is so far from providing application security as to make it a non-starter. [Top-posting is a sign of fuzzy thinking.] -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From guyverdh at hotmail.com Thu Oct 11 02:30:14 2007 From: guyverdh at hotmail.com (Larry Becke) Date: Wed, 10 Oct 2007 11:30:14 -0500 Subject: scp -t . - possible idea for additional parameter Message-ID: >1. Why do you think this change provides effective security? Specifying the starting directory, and not allowing the user to navigate above it effectively locks the user within that directory. >2. Have you ever tried to implement something like this, dealing with>symbolic links, bind mounts, etc.? Since you cannot transfer symlinks directly via the scp command, there wouldn't be any in the directories we would be using on the remote system. >If you want to confine users effectively, chroot them. chroot'ing should not be used as a security method, that's been clearly stated time and again. _________________________________________________________________ Help yourself to FREE treats served up daily at the Messenger Caf?. Stop by today. http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline From william at 25thandClement.com Thu Oct 11 03:57:56 2007 From: william at 25thandClement.com (William Ahern) Date: Wed, 10 Oct 2007 10:57:56 -0700 Subject: scp -t . - possible idea for additional parameter In-Reply-To: References: Message-ID: <20071010175756.GD23125@wilbur.25thandClement.com> On Wed, Oct 10, 2007 at 11:30:14AM -0500, Larry Becke wrote: > chroot'ing should not be used as a security method, that's been clearly > stated time and again. oh boy. it's statement like these that i've spent half this past week rebutting people on LWN and LKML. chroot can and should be used WHERE PRACTICABLE, and with other methods. Just because root can break out of chroot, doesn't mean chroot cannot be used for security. It only means that use of chroot as a security measure is almost entirely useless WHEN THE PROCESS MUST HAVE root privileges. It's utility is also diminished by other circumstances, like kernel bugs and other extravagant (though often common) ways to circumvent a chroot jail. Like any security measure, chroot is not unique in this regard. And like almost _all_ security measures, the tool needn't have been intended primirily or even originally to be used that way. At the end of the day lack of security isn't about not using enough security devices, its about using regular tools insecurely. Period. How people can think that hacking up a user-land program to parse and normalize arbitary string paths from hostile users is more secure than intelligently employing chroot.... I cannot understand this.... The exposure that the instrumentalities of chroot to arbitrary input is so much restricted in comparison, because the kernel.... do I even need to explain.... Note I'm not arguing about the scp modification; this is more about the off-the-cuff remark about chroot. From Jefferson.Ogata at noaa.gov Thu Oct 11 04:07:49 2007 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Wed, 10 Oct 2007 18:07:49 +0000 Subject: scp -t . - possible idea for additional parameter In-Reply-To: References: Message-ID: <470D14F5.6000308@noaa.gov> On 10/10/07 16:30, Larry Becke wrote: >> 1. Why do you think this change provides effective security? > > Specifying the starting directory, and not allowing the user to navigate above it effectively locks the user within that directory. Yes, and...? What does that accomplish in terms of security, specifically? I.e. what is the specific threat you are trying to protect against? > chroot'ing should not be used as a security method, that's been clearly stated time and again. chroot *can* be used as a security method, if done correctly, just as virtualization *can* be used, along with any other mechanism that effectively confines the domain of a process's activity, preferably at the kernel level where there are fewer paths for circumvention. Combine chroot with segregated filesystems mounted with combinations of ro, nosuid, noexec, nodev and you can have very effective limits on user activity. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From guyverdh at hotmail.com Thu Oct 11 04:29:18 2007 From: guyverdh at hotmail.com (Larry Becke) Date: Wed, 10 Oct 2007 13:29:18 -0500 Subject: scp -t . - possible idea for additional parameter In-Reply-To: <20071010175756.GD23125@wilbur.25thandClement.com> References: <20071010175756.GD23125@wilbur.25thandClement.com> Message-ID: > Date: Wed, 10 Oct 2007 10:57:56 -0700> From: william at 25thandClement.com> To: guyverdh at hotmail.com> CC: openssh-unix-dev at mindrot.org> Subject: Re: scp -t . - possible idea for additional parameter> > On Wed, Oct 10, 2007 at 11:30:14AM -0500, Larry Becke wrote:> > chroot'ing should not be used as a security method, that's been clearly> > stated time and again.> > oh boy. it's statement like these that i've spent half this past week> rebutting people on LWN and LKML.> I'll stand by my comment as I intended it. chroot - by and of itself is not security function. To blindly, and off the cuff, throw "if you want it secure, chroot it" statements out there leads to more problems than it solves. staticly linking (and all the issues caused when library mis-match problems that can arise) vs dynamically linking and having to replicate the libraries for the chroot'd environment, and everything else that's involved with getting a process/application properly and securely chroot'd is not for the beginner. For an application to be properly chroot'd it either needs to be designed with chroot in mind by more experienced developers, or needs to be clearly and effectively documented so that the not so experienced can do it. The change that I am suggesting bypasses the inherit issues with chroot through simple means. The fact that scp is designed to just *copy* files either direction is itself a blessing. Simple file and directory management that anyone can do can make the remote directories secure by not using sym-links, mount point boundaries, etc... _________________________________________________________________ Climb to the top of the charts!? Play Star Shuffle:? the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_oct From guyverdh at hotmail.com Thu Oct 11 04:50:29 2007 From: guyverdh at hotmail.com (Larry Becke) Date: Wed, 10 Oct 2007 13:50:29 -0500 Subject: scp -t . - possible idea for additional parameter In-Reply-To: <20071010175756.GD23125@wilbur.25thandClement.com> References: <20071010175756.GD23125@wilbur.25thandClement.com> Message-ID: >Yes, and...? What does that accomplish in terms of security,>specifically? I.e. what is the specific threat you are trying to protect>against? It's pretty simple really, to not allow someone who is copying a file to go anywhere outside of the directory we started them in. Why should anyone have to build out a hugely convoluted chroot'd environment to simply disallow someone from writing / reading from anywhere but their starting directory? Especially if we can simply, and effectively disallow the use of "../" in the remote file path, as well as preface "./" to the remote path after the hostname. If this *feature* were able to be set system wide, users who were allowed to scp (ie, change their login shell to be "/usr/local/bin/scp -t .") only would never be able to write outside of their home directories, unless the systems admins had configured sym-links to point somewhere else. Using keys, you could potentially allow a user to scp files to/from another directory, without having to create additional userids. command="/usr/local/bin/scp -t /some/path/to/write/to" .....public key..... within the authorized keys file would do the trick nicely. We can use this functionality today, minus the ability to lock the user into the startup directory. A simple (I hope) change to modify the remote path params, would finish this and make it extremely easy to lock the file transfer to the start directory. _________________________________________________________________ Help yourself to FREE treats served up daily at the Messenger Caf?. Stop by today. http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline From shahid.shaikh at in.ibm.com Thu Oct 11 08:30:38 2007 From: shahid.shaikh at in.ibm.com (Shahid M Shaikh) Date: Thu, 11 Oct 2007 04:00:38 +0530 Subject: Shahid M Shaikh is out of the office. Message-ID: I will be out of the office starting 10/08/2007 and will not return until 10/17/2007. I will respond to your message when I return. If its necessary, please contact my Lead Trishali nayar (ntrishal at in.ibm.com) or my Manager Arun Anbalagan(arunprasath at in.ibm.com) From guyverdh at hotmail.com Thu Oct 11 11:38:38 2007 From: guyverdh at hotmail.com (Larry Becke) Date: Wed, 10 Oct 2007 20:38:38 -0500 Subject: scp -t . - possible idea for additional parameter In-Reply-To: <20071010175756.GD23125@wilbur.25thandClement.com> References: <20071010175756.GD23125@wilbur.25thandClement.com> Message-ID: let me rephrase the question then... How hard would it be to change scp, so that, if -T were used instead of -t, to do 2 things? #1 - If "../" were found in the remote path, error out. #2 - Preface "./" to the remote path, after the host name. Forget about whether or not it's what some might call the right thing to do or not. Could it be done? How trivial would it be? If it could be done with a minimum of fuss, what would it hurt to do so? I'm stating that there is a need for this option. I'm stating that I'm certainly not the only one who would end up making use of it. Thanks, Larry _________________________________________________________________ Windows Live Hotmail and Microsoft Office Outlook ? together at last. ?Get it now. http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=CL100626971033 From Jefferson.Ogata at noaa.gov Thu Oct 11 18:43:21 2007 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Thu, 11 Oct 2007 08:43:21 +0000 Subject: scp -t . - possible idea for additional parameter In-Reply-To: References: <20071010175756.GD23125@wilbur.25thandClement.com> Message-ID: <470DE229.6080500@noaa.gov> Larry Becke wrote: >> Yes, and...? What does that accomplish in terms of security,>specifically? I.e. what is the specific threat you are trying to protect>against? > > It's pretty simple really, to not allow someone who is copying a file to go anywhere outside of the directory we started them in. How does that stop them? So they scp it to somewhere under their home dir, then they ssh in and mv it wherever they want. Or they use sftp. > Why should anyone have to build out a hugely convoluted chroot'd environment to simply disallow someone from writing / reading from anywhere but their starting directory? Especially if we can simply, and effectively disallow the use of "../" in the remote file path, as well as preface "./" to the remote path after the hostname. First off, a chroot environment is not that hard to build. As to why, uh, because it's an effective way to do what you want that doesn't require modifying scp semantics. Another suggestion, however, is to use filesystem permissions, which should already be set to enforce what you want. They work regardless of any bugs in scp or whatever canonicalization code you add to scp. > If this *feature* were able to be set system wide, users who were allowed to scp (ie, change their login shell to be "/usr/local/bin/scp -t .") only would never be able to write outside of their home directories, unless the systems admins had configured sym-links to point somewhere else. Ah, so you want to use scp as a shell. Most peculiar. Would that even work? It seems to me you want to add constraints to scp's behavior that may be difficult to enforce, in order to implement something that is not really any of ssh's business. Have you tried WebDAV over SSL? -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From Jefferson.Ogata at noaa.gov Thu Oct 11 18:54:39 2007 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Thu, 11 Oct 2007 08:54:39 +0000 Subject: scp -t . - possible idea for additional parameter In-Reply-To: References: <20071010175756.GD23125@wilbur.25thandClement.com> Message-ID: <470DE4CF.3020608@noaa.gov> On 10/10/07 18:29, Larry Becke wrote: >> Date: Wed, 10 Oct 2007 10:57:56 -0700> From: william at 25thandClement.com> To: guyverdh at hotmail.com> CC: openssh-unix-dev at mindrot.org> Subject: Re: scp -t . - possible idea for additional parameter> > On Wed, Oct 10, 2007 at 11:30:14AM -0500, Larry Becke wrote:> > chroot'ing should not be used as a security method, that's been clearly> > stated time and again.> > oh boy. it's statement like these that i've spent half this past week> rebutting people on LWN and LKML.> > I'll stand by my comment as I intended it. chroot - by and of itself is not security function. What does that even mean? > To blindly, and off the cuff, throw "if you want it secure, chroot it" statements out there leads to more problems than it solves. No one threw out any such statements. What I said was "If you want to confine users effectively, chroot them." > staticly linking (and all the issues caused when library mis-match problems that can arise) vs dynamically linking and having to replicate the libraries for the chroot'd environment It's really not that big of a deal. You don't need to relink. What library mismatch problems are you referring to? > and everything else that's involved with getting a process/application properly and securely chroot'd is not for the beginner. Neither is trying to set up a protected filesystem hierarchy using a modified scp as a shell. > For an application to be properly chroot'd it either needs to be designed with chroot in mind by more experienced developers, or needs to be clearly and effectively documented so that the not so experienced can do it. Most reasonably advanced admins can chroot pretty much any service without special documentation. ldd and strace (or equivalent) are your friends. If you design your chroot properly it's trivial to maintain. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From guyverdh at hotmail.com Fri Oct 12 01:00:41 2007 From: guyverdh at hotmail.com (Larry Becke) Date: Thu, 11 Oct 2007 10:00:41 -0500 Subject: scp -t . - possible idea for additional parameter In-Reply-To: <20071010175756.GD23125@wilbur.25thandClement.com> References: <20071010175756.GD23125@wilbur.25thandClement.com> Message-ID: >How does that stop them? So they scp it to somewhere under their home>dir, then they ssh in and mv it wherever they want. Or they use sftp. Let's see.... The users that would be given this feature, wouldn't be given a password for their login. ie - they are required to use their key. Their login shell (in /etc/passwd) would be /usr/local/bin/scp -T ./data Their key would be locked via "command=" to running the same scp -T ./data command Their authorized_keys file would be read-only. Their .ssh directory would be read only. Their home directory would be read-only. There would be a "data" directory under their home directory that is the only thing writeable. >As to why, uh, because it's an effective way to do what you want that>doesn't require modifying scp semantics. Really? How is it effective if you have to copy libraries to every users' home directory structure in order to allow them to use chroot'd code? chroot cannot be run as anyone but root, so you cannot use it in the "command=" section (i've tried). >Ah, so you want to use scp as a shell. Most peculiar. Would that even work? Yes - it works very well, except that it doesn't restrict the user to their home directory. >It seems to me you want to add constraints to scp's behavior that may be >difficult to enforce, in order to implement something that is not really >any of ssh's business. Have you tried WebDAV over SSL? I want to add a simple parameter parse that errors out if "../" is in the remote path, and adds "./" between the host segment and path segment of the remote path. I'm not asking to *enforce* anything. I'm not asking for tons of changes to watchdog anything. I'm only asking for a very simple front end change that takes effect when scp is started with "-T" instead of "-t". Simple administrative tasks and permissions will take care of the rest. It's a very subtle change, one that won't impact anyone who uses scp in it's default manner, and would give admins a very simple and effective tool to restrict secure file transfers (ie production system transfers - not day to day users) to the directory we designate as the remote source/destination. Whether or not you can see the need for something like this, or agree with my reasoning for this, I'm asking simply, can it be done? What harm would there be in adding it? _________________________________________________________________ Climb to the top of the charts!? Play Star Shuffle:? the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_oct From dkg-openssh.com at fifthhorseman.net Fri Oct 12 02:34:23 2007 From: dkg-openssh.com at fifthhorseman.net (Daniel Kahn Gillmor) Date: Thu, 11 Oct 2007 12:34:23 -0400 Subject: scp -t . - possible idea for additional parameter In-Reply-To: (Larry Becke's message of "Thu\, 11 Oct 2007 10\:00\:41 -0500") References: <20071010175756.GD23125@wilbur.25thandClement.com> Message-ID: <87y7e9d300.fsf@squeak.fifthhorseman.net> 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/20071011/2d330e2a/attachment.bin From Jefferson.Ogata at noaa.gov Fri Oct 12 02:51:55 2007 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Thu, 11 Oct 2007 16:51:55 +0000 Subject: scp -t . - possible idea for additional parameter In-Reply-To: References: <20071010175756.GD23125@wilbur.25thandClement.com> Message-ID: <470E54AB.8030500@noaa.gov> On 10/11/07 15:00, Larry Becke wrote: [please do not remove attributions on your responses; attribution restored] > Jefferson Ogata wrote: >> How does that stop them? So they scp it to somewhere under their home>dir, then they ssh in and mv it wherever they want. Or they use sftp. > Let's see.... The users that would be given this feature, wouldn't be given a password for their login. ie - they are required to use their key. > Their login shell (in /etc/passwd) would be /usr/local/bin/scp -T ./data > Their key would be locked via "command=" to running the same scp -T ./data command > > Their authorized_keys file would be read-only. Their .ssh directory would be read only. > Their home directory would be read-only. > There would be a "data" directory under their home directory that is the only thing writeable. Do you not see how baroque this setup is, while not actually guaranteeing the particular result you want (e.g. if a symlink gets created somehow)? >> As to why, uh, because it's an effective way to do what you want that>doesn't require modifying scp semantics. > Really? How is it effective if you have to copy libraries to every users' home directory structure in order to allow them to use chroot'd code? You can create a common chroot area and place all the home directories under it. Permissions effectively prevent one user from writing to another user's area. Of course permissions already do that on a properly configured system, which is why I don't understand why you're bothering with all this. > chroot cannot be run as anyone but root, so you cannot use it in the "command=" section (i've tried). Yes; if chroot could be executed by non-root users, it wouldn't provide effective containment. >> Ah, so you want to use scp as a shell. Most peculiar. Would that even work? > > Yes - it works very well, except that it doesn't restrict the user to their home directory. By which you mean you've actually tested it? What happens to the sshd process's attempt to tell the user's shell to execute scp -t or scp -f? > I want to add a simple parameter parse that errors out if "../" is in the remote path, and adds "./" between the host segment and path segment of the remote path. Disregarding symlinks, are you sure those measures will effectively constrain the user's activity on every platform openssh runs on, including, for example, Cygwin, or a system with a Unicode filesystem? > I'm not asking to *enforce* anything. I'm not asking for tons of changes to watchdog anything. I'm only asking for a very simple front end change that takes effect when scp is started with "-T" instead of "-t". You certainly are asking to enforce something. Or look at it this way: 1. You could do this properly and make *sure* a user can't write outside the target directory. This requires examining every platform openssh runs on to make sure that the strategy you've chosen works in all cases, handling symbolic links, and thinking about any other escape vectors as well. It also requires auditing scp to make sure that it doesn't allow circumvention of these restrictions in *any* part of the protocol. 2. You could do it halfway, ignoring symbolic links and platforms other than the one you happen to be interested in, to just get it working the way you want. Any measure that does not address all platforms, or attempts to add application security to openssh in an obviously incomplete manner, may be rejected by the openssh maintainers. If you do 1, you give ssh users the expectation that their users really are confined to the target directory (in that particular configuration you've described above where they have no access to the system other than via scp, and authorized keys files have been effectively protected against tampering). A very few people may actually rely on this for system security, and if they set everything up correctly, their expectation will be fulfilled. On the downside, you're adding additional code to scp, and you're constraining future development not to break the semantics you've imposed. If you do 2 (i.e. don't do 1 properly), you give ssh users the *false* expectation that their users really are confined to the target directory. If they rely on this for security, this harms them. > Simple administrative tasks and permissions will take care of the rest. Indeed, these measures can take care of all of it reliably without any modification to scp. This is pretty much the reason that filesystem permissions were invented. > It's a very subtle change, one that won't impact anyone who uses scp in it's default manner, and would give admins a very simple and effective tool to restrict secure file transfers (ie production system transfers - not day to day users) to the directory we designate as the remote source/destination. It's that term "effective" that is in question. > Whether or not you can see the need for something like this, or agree with my reasoning for this, I'm asking simply, can it be done? What harm would there be in adding it? As to whether it can be done, why don't you give it a shot? As to harm, see above. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From guyverdh at hotmail.com Fri Oct 12 04:01:53 2007 From: guyverdh at hotmail.com (Larry Becke) Date: Thu, 11 Oct 2007 13:01:53 -0500 Subject: scp -t . - possible idea for additional parameter In-Reply-To: <20071010175756.GD23125@wilbur.25thandClement.com> References: <20071010175756.GD23125@wilbur.25thandClement.com> Message-ID: Look, I'm tired of arguing my reasons. Let's just agree to disagree on my reasoning. Answer the question. Can this be done? Is it so terribly hard to add the feature? Will it hurt anything to add the feature? I'd be happy to discuss offline the reasoning behind my request. It's valid, and if you'd bother to keep an open mind, you might actually understand where I'm coming from. _________________________________________________________________ Climb to the top of the charts!? Play Star Shuffle:? the word scramble challenge with star power. http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_oct From william at 25thandClement.com Fri Oct 12 04:40:07 2007 From: william at 25thandClement.com (William Ahern) Date: Thu, 11 Oct 2007 11:40:07 -0700 Subject: scp -t . - possible idea for additional parameter In-Reply-To: References: <20071010175756.GD23125@wilbur.25thandClement.com> Message-ID: <20071011184007.GA24112@wilbur.25thandClement.com> On Thu, Oct 11, 2007 at 01:01:53PM -0500, Larry Becke wrote: > > Look, I'm tired of arguing my reasons. Let's just agree to disagree on my > reasoning. > You're always free to implement this yourself, and submit a patch for discussion. Nobody is trying to persuade you from not implementing this yourself; on the contrary, you're trying to persuade others to do the work. If you're tired of arguing, then why not get to hacking? From Jefferson.Ogata at noaa.gov Fri Oct 12 04:47:13 2007 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Thu, 11 Oct 2007 18:47:13 +0000 Subject: scp -t . - possible idea for additional parameter In-Reply-To: References: <20071010175756.GD23125@wilbur.25thandClement.com> Message-ID: <470E6FB1.4020800@noaa.gov> On 2007-10-11 18:01, Larry Becke wrote: > Look, I'm tired of arguing my reasons. Let's just agree to disagree on my reasoning. That agreement is implicit. :^) > Answer the question. > Can this be done? Theoretically. See my previous message. > Is it so terribly hard to add the feature? It's not easy. See my previous message, and do a little research on path canonicalization and past directory traversal vulnerabilities in, e.g. IIS and Apache, to understand this better. > Will it hurt anything to add the feature? If it isn't done 100% correctly, yes. See my previous message. > I'd be happy to discuss offline the reasoning behind my request. > It's valid, and if you'd bother to keep an open mind, you might actually understand where I'm coming from. I think we're way ahead of where you're coming from, which is why I asked, "Have you tried WebDAV over SSL?" -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From guyverdh at hotmail.com Fri Oct 12 05:43:31 2007 From: guyverdh at hotmail.com (Larry Becke) Date: Thu, 11 Oct 2007 14:43:31 -0500 Subject: scp -t . - possible idea for additional parameter In-Reply-To: <20071010175756.GD23125@wilbur.25thandClement.com> References: <20071010175756.GD23125@wilbur.25thandClement.com> Message-ID: On 2007-10-11 18:01, Larry Becke wrote:>> Can this be done? >Theoretically. See my previous message.I must have missed it. > Is it so terribly hard to add the feature?>It's not easy. See my previous message, and do a little research on path>canonicalization and past directory traversal vulnerabilities in, e.g.>IIS and Apache, to understand this better. To throw an error and exit if "../" is in the remote path parameter? To add a "./" between hostname: and /path/to/dir in the remote path parameter? Just asking, as I know how to do this in the languages that I use. Unfortunately, I'm not a c/c++ developer myself, otherwise I would have just made a patch for it and submitted it for review. This is tempting me to break down and start learning c/c++. >> Will it hurt anything to add the feature?>If it isn't done 100% correctly, yes. See my previous message.If it only effects users who use the -T parameter, instead of the -t parameter, neither of which are documented? >> I'd be happy to discuss offline the reasoning behind my request.>> It's valid, and if you'd bother to keep an open mind, you might actually understand \>> where I'm coming from.>I think we're way ahead of where you're coming from, which is why I>asked, "Have you tried WebDAV over SSL?" Really, and I can use that as simply in a shell script as scp filename -i xfer_key user at remhost: Or do I have to use some convoluted strings and other commands as well as configure additional keys, keystores, ssl etc? This would be on systems with no web servers, no application servers. I'll look into it, however, the servers essentially have ssh/scp/sftp (and the requisite openssl, etc) for services, nothing else. _________________________________________________________________ Help yourself to FREE treats served up daily at the Messenger Caf?. Stop by today. http://www.cafemessenger.com/info/info_sweetstuff2.html?ocid=TXT_TAGLM_OctWLtagline From Jefferson.Ogata at noaa.gov Fri Oct 12 08:31:47 2007 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Thu, 11 Oct 2007 22:31:47 +0000 Subject: scp -t . - possible idea for additional parameter In-Reply-To: References: <20071010175756.GD23125@wilbur.25thandClement.com> Message-ID: <470EA453.6000708@noaa.gov> Larry Becke wrote: > On 2007-10-11 18:01, Larry Becke wrote:>> Can this be done? >Theoretically. See my previous message.I must have missed it. >> Is it so terribly hard to add the feature?>It's not easy. See my previous message, and do a little research on path>canonicalization and past directory traversal vulnerabilities in, e.g.>IIS and Apache, to understand this better. > > To throw an error and exit if "../" is in the remote path parameter? > To add a "./" between hostname: and /path/to/dir in the remote path parameter? Doing those things is trivial. What's not trivial is demonstrating that doing those things accomplishes what you want on every platform where openssh runs. And given that you're ignoring symlinks, let alone potential Unicode issues, you're not demonstrating even a moderate level of diligence in coming up with a reliable solution to your problem. If you do attempt to solve the problem properly, it becomes more difficult. Take a look at this, for example: http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-4131 > Just asking, as I know how to do this in the languages that I use. > Unfortunately, I'm not a c/c++ developer myself, otherwise I would have just made a patch for it and submitted it for review. This is tempting me to break down and start learning c/c++. That's a good idea. :^) >>> Will it hurt anything to add the feature?>If it isn't done 100% correctly, yes. See my previous message.If it only effects users who use the -T parameter, instead of the -t parameter, neither of which are documented? >>> I'd be happy to discuss offline the reasoning behind my request.>> It's valid, and if you'd bother to keep an open mind, you might actually understand \>> where I'm coming from.>I think we're way ahead of where you're coming from, which is why I>asked, "Have you tried WebDAV over SSL?" > > Really, and I can use that as simply in a shell script as > scp filename -i xfer_key user at remhost: No, but you can configure it to do what you want reliably, and a stray symlink won't break your authorization policy. > Or do I have to use some convoluted strings and other commands as well as configure additional keys, keystores, ssl etc? > This would be on systems with no web servers, no application servers. Yes, you would have to configure SSL. That's good exercise, if it's something you don't feel comfortable doing. cadaver is a decent command-line DAV client with FTP-like syntax. > I'll look into it, however, the servers essentially have ssh/scp/sftp (and the requisite openssl, etc) for services, nothing else. Presumably there's another service of some kind on the system, since you would have people copy files to it in a way that prevents file sharing between users, and I doubt it's supposed to be a black hole. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From djm at mindrot.org Fri Oct 12 09:19:35 2007 From: djm at mindrot.org (Damien Miller) Date: Fri, 12 Oct 2007 09:19:35 +1000 (EST) Subject: scp -t . - possible idea for additional parameter In-Reply-To: References: <20071010175756.GD23125@wilbur.25thandClement.com> Message-ID: On Thu, 11 Oct 2007, Larry Becke wrote: > > On 2007-10-11 18:01, Larry Becke wrote:>> Can this be done? >Theoretically. See my previous message.I must have missed it. > > Is it so terribly hard to add the feature?>It's not easy. See my previous message, and do a little research on path>canonicalization and past directory traversal vulnerabilities in, e.g.>IIS and Apache, to understand this better. > > To throw an error and exit if "../" is in the remote path parameter? > To add a "./" between hostname: and /path/to/dir in the remote path parameter? That is probably insufficient and likely to break some software that uses scp. You could use realpath(3) and compare the stem, but that has a downside too: it will break on traverse-only directories. Just to be clear, I have zero interest in making any feature additions to scp and I think most of the developers feel the same way. It is a difficult protocol to extend, and its use of a shell-expanded commandline to inform it of which files to transfer makes it very brittle. Given its very widespread use, I think it is best to leave it be and concentrate efforts on making sftp/sftp-server a compelling substitute. -d PS. I don't know what mail client you are using, but it is mangling the quoting in your replies into an unreadable mess. From guyverdh at hotmail.com Fri Oct 12 14:12:45 2007 From: guyverdh at hotmail.com (Larry Becke) Date: Thu, 11 Oct 2007 23:12:45 -0500 Subject: scp -t . - possible idea for additional parameter In-Reply-To: References: <20071010175756.GD23125@wilbur.25thandClement.com> Message-ID: > Date: Fri, 12 Oct 2007 09:19:35 +1000 > From: djm at mindrot.org > To: guyverdh at hotmail.com > CC: openssh-unix-dev at mindrot.org > Subject: RE: scp -t . - possible idea for additional parameter > > On Thu, 11 Oct 2007, Larry Becke wrote: > > > > > On 2007-10-11 18:01, Larry Becke wrote:>> Can this be done? >Theoretically. See my previous message.I must have missed it. > > > Is it so terribly hard to add the feature?>It's not easy. See my previous message, and do a little research on path>canonicalization and past directory traversal vulnerabilities in, e.g.>IIS and Apache, to understand this better. > > > > To throw an error and exit if "../" is in the remote path parameter? > > To add a "./" between hostname: and /path/to/dir in the remote path parameter? > > That is probably insufficient and likely to break some software that > uses scp. You could use realpath(3) and compare the stem, but that has a > downside too: it will break on traverse-only directories. Since the change I'm looking for is something that would have to be specifically selected - instead of using scp -t, using scp -T, this should (I won't say won't, because anything is possible) not break any normal use of scp. Given that we would not actually be changing that expansion in any way, but doing some very minor work up front, before passing the remote path on to the unchanged code, I'm still not sure that I see that it would break anything. Again, as part of a pre-processor, activated only if scp were started with the -T parameter, instead of the -t parameter, would do 2 things. Scan the remote path for "../", and if found - error out, don't do any kind of transfer. Give a simple error message like "Upstream directory traversal not allowed in this mode of operation." Insert "./" between the hostname and remote directory to make it relative to the startup directory. hostname:/some/path/to/dir becomes hostname:.//some/path/to/dir hostname: becomes hostname:./ I still don't see anything sinister here, however, I may be oversimplifying things. > > Just to be clear, I have zero interest in making any feature additions > to scp and I think most of the developers feel the same way. It is a > difficult protocol to extend, and its use of a shell-expanded commandline > to inform it of which files to transfer makes it very brittle. Given its > very widespread use, I think it is best to leave it be and concentrate > efforts on making sftp/sftp-server a compelling substitute. I understand that everyone that has worked on openssh past and present combined have spent a lot of time making a very nice, clean application that is widely used and respected in just about every area computer related. However, I feel it is unfortunate to freeze scp's features, as sftp/sftp-server can (to my knowledge) in no way substitute the simplicity that is scp. I don't see sftp being picked up as an scp replacement until sftp can be used like scp in a single line. example: sftp -f filename user at remotehost: sftp -f user at remotehost:filename . or sftp -f filename -i keyfile user at remotehost:/some/dir sftp -i keyfile -f user at remotehost:/some/dir/filename . The keyfile could be set to start sftp-server with the -T param (or whatever was chosen to mean, start here, lock upward traversal) and specify a starting directory. command="/usr/libexec/openssh/sftp-server -T /some/other/path/to/start/in" Then again, every command sent would have to be parsed to see if "../" were used and if so, error. It would also have to insert "./" into every source path for the get/mget commands, as well as insert "./" into every destination path for the put/mput commands. Yet, if it took this kind of command line input, then converted it to the appropriate sftp commands behind the scenes, that might work. It seems that more work would be involved in this, than scp, but again, I am not a C developer, so maybe I'm totally off base here. > > -d > > PS. I don't know what mail client you are using, but it is mangling > the quoting in your replies into an unreadable mess. hotmail, and very few people replying to myself as well as the mailing list, meaning that I had to cut-and-paste to reply to most people. my apologies for the mangling.... Maybe I'm just barking up the wrong tree here, as no one seems (to me anyway), to be willing to see things from someone else's perspective. So far I've received "use chroot, it's great and simple." or "use webdav and ssl - even though you have to work with keys, keystores, install a webserver, utilize wget and probably a whole plethora of things I've not found yet" or "use rsync" which unfortunately does not fit into the class of usable software for the types of scripts and transfers we are currently doing. It seems odd to me that everyone's suggestion is to "Use someone else's software, we don't want ours to work like that." However, being open-source, it is your software and you make the final decisions on what does and does not make it into the software as a feature. I've already been hit up by 2 commercial ssh vendors who are eager to implement the idea, one of which already has some of the functionality built in. I hate the idea of going that route, but may have no choice. My apologies for wasting everyone's time reading all my useless posts. _________________________________________________________________ Windows Live Hotmail and Microsoft Office Outlook ? together at last. ?Get it now. http://office.microsoft.com/en-us/outlook/HA102225181033.aspx?pid=CL100626971033 From Jefferson.Ogata at noaa.gov Fri Oct 12 16:31:05 2007 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Fri, 12 Oct 2007 06:31:05 +0000 Subject: scp -t . - possible idea for additional parameter In-Reply-To: References: <20071010175756.GD23125@wilbur.25thandClement.com> Message-ID: <470F14A9.3000802@noaa.gov> On 2007-10-12 04:12, Larry Becke wrote: > Maybe I'm just barking up the wrong tree here, as no one seems (to me anyway), to be willing to see things from someone else's perspective. No one has any trouble seeing things from your perspective. It's exactly the other way 'round. If you would take the time to understand why "erroring out" if "../" appears in a path and prepending "./" to the path will handle only a small fraction of the problem space, arguably creating more problems than it solves, then maybe there would be some perspective sharing going on. This advice is not meant merely to rebut your scp suggestion; it's important to understand how paths can lead you astray before you try to use simplistic analysis of their string representations to constrain user activity. > So far I've received "use chroot, it's great and simple." or "use webdav and ssl - even though you have to work with keys, keystores, install a webserver, utilize wget and probably a whole plethora of things I've not found yet" or "use rsync" which unfortunately does not fit into the class of usable software for the types of scripts and transfers we are currently doing. Given your tendency to employ biased, deliberate misquotation in an argumentative way, coupled with your unwillingness to accept the challenge of learning some fairly mundane sysadmin tasks (e.g. set up a WebDAV service, set up an SSL web service, set up a maintainable chroot hierarchy, learn how to use chown and chmod or even chattr), it's no wonder people aren't more supportive. Learning to do new things without flinching will improve your paycheck. Also, you left out "use filesystem permissions, they're sexy and drwx------." Sorry for wandering so far off topic. We now return you to your regularly scheduled programming. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From guyverdh at hotmail.com Fri Oct 12 23:15:59 2007 From: guyverdh at hotmail.com (Larry Becke) Date: Fri, 12 Oct 2007 08:15:59 -0500 Subject: scp -t . - possible idea for additional parameter In-Reply-To: References: <20071010175756.GD23125@wilbur.25thandClement.com> Message-ID: Yes, this is the same person who never replies back to me, so that I have to cut and paste their responses.... Thanks ever so much. On 2007-10-12 04:12, Larry Becke wrote:>> Maybe I'm just barking up the wrong tree here, as no one seems (to me anyway), to \>> be willing to see things from someone else's perspective.>No one has any trouble seeing things from your perspective. It's exactly>the other way 'round. If you would take the time to understand why>"erroring out" if "../" appears in a path and prepending "./" to the>path will handle only a small fraction of the problem space, arguably>creating more problems than it solves, then maybe there would be some>perspective sharing going on. This advice is not meant merely to rebut>your scp suggestion; it's important to understand how paths can lead you>astray before you try to use simplistic analysis of their string>representations to constrain user activity. Whoa here - a small fraction of the problem? What problem are you refering to? You keep repeating this like a mantra, yet share no example of problems this could cause. Again, controlled destination directories that are not mount points, don't have sym-links, permissions would be set appropriately. scp cannot copy sym-links as sym-links so none could magically appear in the directory, so that is moot. since we would not be able to navigate up the directory chain, any attempts to do so would error out, and all pathing is now relative to the starting directory, I really don't see the problem. Again, this would all be done before the rest of the parameter code is executed. I would assume that pathing problems are already accounted for in the code, and anything that could be a problem would be detected. >> So far I've received "use chroot, it's great and simple." or "use webdav and ssl - \>> even though you have to work with keys, keystores, install a webserver, utilize \>> wget and probably a whole plethora of things I've not found yet" or "use rsync" \>> which unfortunately does not fit into the class of usable software for the types of \>> scripts and transfers we are currently doing.>Given your tendency to employ biased, deliberate misquotation in an>argumentative way, coupled with your unwillingness to accept the>challenge of learning some fairly mundane sysadmin tasks (e.g. set up a>WebDAV service, set up an SSL web service, set up a maintainable chroot>hierarchy, learn how to use chown and chmod or even chattr), it's no>wonder people aren't more supportive. Learning to do new things without>flinching will improve your paycheck. In places where it would make sense to have a web server, we have web servers, use ssl, etc... chroots have there places, but using them solely to get around a given piece of software is not an ideal use of them. Implementing a web server just to do a file transfer is an exercise in futility when the client will not use it. Again, you keep trying to point me away from openssh. Is there some reason you keep trying to persuade me to go away from openssh? *(aside from nuisance factor)* I regularly make use of new technologies, in many cases, just to learn something new. However, not everyone shares that mind-set. Trying to force change upon corporate clients, as it would be the clients who would have to learn to work with the new tools and change all of their automated routines to make use of them, would only end up causing more challenges than they solve. It also has the problem of trying to work within corporate security, as it takes forever to get corporate clients and trading partners to change to different technologies. So when a client says that they use scp, and nothing else, what choices do you have? >Also, you left out "use filesystem permissions, they're sexy and>drwx------." I had stated that we already had permissions set appropriately. I apologize for not re-stating the obvious again.>Sorry for wandering so far off topic. We now return you to your>regularly scheduled programming. That's okay, I noticed that you seem to wander off topic regularly... So - given that scp is the client software of choice, and that chroot is out due to the limits on implementations (scp-only only works within a user's home directory, and doesn't allow different directories to be used for different keys), I guess I have little choice but to look to the commercial ssh vendors who have already expressed an interest in the changes outlined. Thanks again for your time. _________________________________________________________________ Peek-a-boo FREE Tricks & Treats for You! http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us From rapier at psc.edu Sat Oct 13 01:20:06 2007 From: rapier at psc.edu (Chris Rapier) Date: Fri, 12 Oct 2007 11:20:06 -0400 Subject: SCP protocol question and outstanding requests in SFTP In-Reply-To: References: <20071010175756.GD23125@wilbur.25thandClement.com> Message-ID: <470F90A6.8090807@psc.edu> Damien Miller wrote: > Just to be clear, I have zero interest in making any feature additions > to scp and I think most of the developers feel the same way. It is a > difficult protocol to extend, Could you explain this in more detail or point out some resources that might explain some of the nuances? The reason why I ask is that *many* of our users would like more functionality in scp. I do try to point them to sftp but they're generally unwilling due to perceived difficulties using SFTP in scripted situations (which has led me to think about patching SFTP to understand SCP style arguments eg sftp blah user at foo:~/bar but that is, at best, far down the line in things I want to work on). Also, just as a point of curiosity, was the number of default outstanding messages in SFTP increased in 4.7? I ask because the default window size was increased to 1MB outstanding but the previous default of 16 32KB messages would actually restrict the effective outstanding data size to 512KB in SFTP. It looks like its still at 16 but I haven't dug deep enough to see if this disparity was addressed in some other way. Chris From Jan.Pechanec at Sun.COM Sat Oct 13 01:38:09 2007 From: Jan.Pechanec at Sun.COM (Jan Pechanec) Date: Fri, 12 Oct 2007 17:38:09 +0200 (CEST) Subject: SCP protocol question and outstanding requests in SFTP In-Reply-To: <470F90A6.8090807@psc.edu> References: <20071010175756.GD23125@wilbur.25thandClement.com> <470F90A6.8090807@psc.edu> Message-ID: On Fri, 12 Oct 2007, Chris Rapier wrote: >Could you explain this in more detail or point out some resources that >might explain some of the nuances? something is here: http://blogs.sun.com/janp/entry/how_the_scp_protocol_works >SCP style arguments eg sftp blah user at foo:~/bar but that is, at best, >far down the line in things I want to work on). yeah, upload is missing (that's why I still use scp). This is mainly for command line since you can feed sftp through standard input in scripts. we plan to add command line upload for SSH OpenSolaris soon, if it's not in OpenSSH CVS till then I'll send our patch. -- Jan Pechanec From rapier at psc.edu Sat Oct 13 02:26:35 2007 From: rapier at psc.edu (Chris Rapier) Date: Fri, 12 Oct 2007 12:26:35 -0400 Subject: SCP protocol question and outstanding requests in SFTP In-Reply-To: References: <20071010175756.GD23125@wilbur.25thandClement.com> <470F90A6.8090807@psc.edu> Message-ID: <470FA03B.2060003@psc.edu> Jan Pechanec wrote: > On Fri, 12 Oct 2007, Chris Rapier wrote: > >> Could you explain this in more detail or point out some resources that >> might explain some of the nuances? > > something is here: > http://blogs.sun.com/janp/entry/how_the_scp_protocol_works Excellent, thank you. >> SCP style arguments eg sftp blah user at foo:~/bar but that is, at best, >> far down the line in things I want to work on). > > yeah, upload is missing (that's why I still use scp). This is mainly > for command line since you can feed sftp through standard input in scripts. This can get problematic in some scripting situations. Many of our users just find it easier to use scp rather. > we plan to add command line upload for SSH OpenSolaris soon, if it's > not in OpenSSH CVS till then I'll send our patch. Please do, I'd like to see how its done. From bob at proulx.com Sat Oct 13 02:42:53 2007 From: bob at proulx.com (Bob Proulx) Date: Fri, 12 Oct 2007 10:42:53 -0600 Subject: SCP protocol question and outstanding requests in SFTP In-Reply-To: <470F90A6.8090807@psc.edu> References: <20071010175756.GD23125@wilbur.25thandClement.com> <470F90A6.8090807@psc.edu> Message-ID: <20071012164253.GA1106@dementia.proulx.com> Chris Rapier wrote: > The reason why I ask is that *many* of our users would like more > functionality in scp. I do try to point them to sftp but they're > generally unwilling due to perceived difficulties using SFTP in scripted > situations ... I have experienced the same user pressure. Users have worked up the ranks through the rcommands having used rcp and now want to use scp because it is what they know and is comfortable. But when I point them to rsync this pressure on scp is usually mitigated. The rsync command works well both in scripted situations and on the command line. The rsync command from a user perspective is very similar to scp but has a kitchen sink of features. Plus from a technical standpoint rsync has many efficiency advantages. [Of course a part of me thinks rsync is has too many creeping features too. :-)] It seems wasteful to put a huge amount of effort into scp when rsync seems to fill the feature list quite well. I think if you were to push your users over to rsync that they would be very happy and productive to be using it. Bob From rapier at psc.edu Sat Oct 13 03:28:29 2007 From: rapier at psc.edu (Chris Rapier) Date: Fri, 12 Oct 2007 13:28:29 -0400 Subject: SCP protocol question and outstanding requests in SFTP In-Reply-To: <20071012164253.GA1106@dementia.proulx.com> References: <20071010175756.GD23125@wilbur.25thandClement.com> <470F90A6.8090807@psc.edu> <20071012164253.GA1106@dementia.proulx.com> Message-ID: <470FAEBD.4050701@psc.edu> Bob Proulx wrote: > It seems wasteful to put a huge amount of effort into scp when rsync > seems to fill the feature list quite well. I think if you were to > push your users over to rsync that they would be very happy and > productive to be using it. There are almost always better solutions. However, getting people to *use* those solutions can be painful, frustrating, and ultimately a waste of time and effort. So I agree with you entirely, but that doesn't seem to be enough. For example, I work at an HPC site known as the Pittsburgh Supercomputing Center. We have a huge 3k+ node processor, hundreds of terabytes of rotating media and petabytes of robot controlled tape storage. Getting data in and out of our center is *major* part of what we do here and its why we have multiple 10Gbps connections to the outside world. We have methods in place for the high speed transfer of data using secure authentication - gridFTP, kFTP, and a couple of home rolled solutions. These will give users throughput rates in the multi Gbps range. So what ends up happening? A good chunk of our users end up using SSH to transfer data and then, not knowing *why* using SSH to transfer bulk data is bad idea, come to us and say our networks are broken ("We have a 1Gb link why are we only getting 1.5Mbps? Whats wrong with your network?"). We put a lot of effort into getting gridFTP up and running and making sure kerberos works properly but the users just aren't using it. I would end up spending days in some cases trying to teach users that they can't get the performance they need out of SSH. I'd send them statically compiled binaries of kftp, we'd send people to their sites to get globus running, etc etc etc... 9 times out of 10 we'd stamp out one fire out to have 5 more pop up at the *same* site (generally because of a lack of communication between users, labs, admins, and managers). Eventually it ended up being easier and more cost effective to develop, distribute, and promote the HPN-SSH patches. The result of this is that its actually displacing gridFTP and kFTP as a primary bulk data transfer tool on HPNs. Its not that its better than either of those but its what the users know and constantly revert to given the preference. Personally, I believe that by working with the user desires it actually ends up being more secure because they aren't spending as much time trying to circumvent the 'problem' (we had users hacking iperf, netcat, and the like trying to turn them into transfer tools. Didn't make any sense to me). So while I think rsync would be a better solution (assuming its paired with the HPN-SSH patches) I can't get the users to agree with me. So I prefer to make the tools that users know and are comfortable with do what they need them to do. I'm not always happy about doing this but it makes our users happy and that helps keep our funding coming in. Of course, I end up doing more work but our users don't and its been made very clear to me which is more important :) Chris p.s. sorry to be wordy. i'm trying to avoid writing a paper for a conference (on SSH actually) and I get overly verbose during those times. No, I don't think that makes sense either. ;) From william at 25thandClement.com Sat Oct 13 03:40:17 2007 From: william at 25thandClement.com (William Ahern) Date: Fri, 12 Oct 2007 10:40:17 -0700 Subject: SCP protocol question and outstanding requests in SFTP In-Reply-To: <470FAEBD.4050701@psc.edu> References: <20071010175756.GD23125@wilbur.25thandClement.com> <470F90A6.8090807@psc.edu> <20071012164253.GA1106@dementia.proulx.com> <470FAEBD.4050701@psc.edu> Message-ID: <20071012174017.GB26976@wilbur.25thandClement.com> On Fri, Oct 12, 2007 at 01:28:29PM -0400, Chris Rapier wrote: > Bob Proulx wrote: > > It seems wasteful to put a huge amount of effort into scp when rsync > > seems to fill the feature list quite well. I think if you were to > > push your users over to rsync that they would be very happy and > > productive to be using it. > > There are almost always better solutions. However, getting people to > *use* those solutions can be painful, frustrating, and ultimately a > waste of time and effort. So I agree with you entirely, but that doesn't > seem to be enough. I had a similar problem, but in this case necessity demanded that scp be thrown out entirely. Instead, I wrote a wrapper script which _looked_ like scp, and worked like scp, but instead used sftp. The users never knew the difference. They weren't using esoteric features of scp, which most people don't. Most people use scp because it looks and feels like the cp(1) command. That's easy enough to imitate. There's a great degree of overlap between people who stubbornly refuse to use another tool, and those who use the tool in a most basic, straight-forward fashion. It's not fair (and I suspect this method of arguing is common, though I am not pointing fingers by any means), to hold up the great body of scp users to persuade why scp is important, but then dismiss alternatives because the alternatives don't meet the demands of a much smaller sub-group. Very likely the majority can be transparently migrated, more-or-less. From rapier at psc.edu Sat Oct 13 04:01:13 2007 From: rapier at psc.edu (Chris Rapier) Date: Fri, 12 Oct 2007 14:01:13 -0400 Subject: SCP protocol question and outstanding requests in SFTP In-Reply-To: <20071012174017.GB26976@wilbur.25thandClement.com> References: <20071010175756.GD23125@wilbur.25thandClement.com> <470F90A6.8090807@psc.edu> <20071012164253.GA1106@dementia.proulx.com> <470FAEBD.4050701@psc.edu> <20071012174017.GB26976@wilbur.25thandClement.com> Message-ID: <470FB669.4030802@psc.edu> William Ahern wrote: > I had a similar problem, but in this case necessity demanded that scp be > thrown out entirely. Instead, I wrote a wrapper script which _looked_ like > scp, and worked like scp, but instead used sftp. > > The users never knew the difference. They weren't using esoteric features of > scp, which most people don't. Most people use scp because it looks and feels > like the cp(1) command. That's easy enough to imitate. I agree and I've discussed this in the past with people here. Unfortunately, there isn't much I can do other than try to persuade people because we have no administrative control over the machiens they use to connect to us. If someone at say NCAR or SDSC or UIUC wants to transfer data to or from our machines they'll likely be using boxes administered by NCAR, SDSC or UIUC rather than a PSC box. So its simply impossible to impose the proper solution on them. All I can do is try to persuade them. How effective that is generally depends on the ability and local authority of the user. So while I've been able to get HPN-SSH to be a required component for Grid data transfer nodes I can't get Joe Admin at some lab to make sure his users make the best use of them. > There's a great degree of overlap between people who stubbornly refuse to > use another tool, and those who use the tool in a most basic, > straight-forward fashion. Exactly, but in my experience this tends to be the majority of the users. Or at least the users who have the ability to raise the biggest stink. Since we are dependent on external funding for our operations annoying these people tends to be a suboptimal solution for us. > It's not fair (and I suspect this method of > arguing is common, though I am not pointing fingers by any means), to hold > up the great body of scp users to persuade why scp is important, but then > dismiss alternatives because the alternatives don't meet the demands of a > much smaller sub-group. Very likely the majority can be transparently > migrated, more-or-less. Indeed. Except for those that can't and if this is more than some very small number of people it can end up being disastrous. From paul at innsoft.com Sat Oct 13 07:46:57 2007 From: paul at innsoft.com (Paul Sonoda) Date: Fri, 12 Oct 2007 14:46:57 -0700 Subject: openssh 4.2p1 "getnameinfo failed" port > 999 Message-ID: <470F88E1.10907.F481C1F@paul.innsoft.com> Dear Openssh Team, I am using openssh 4.2p1 on SuSE 10.2. When ever I run sshd with a port greater than 999 I receive an error on start of sshd of "error: getnameinfo failed". SSHD does seem to run properly it just throws the error. Is there a work-around for this problem or do I just ignore it? Thanks in advance! Paul From stuge-openssh-unix-dev at cdy.org Sun Oct 14 00:44:03 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sat, 13 Oct 2007 16:44:03 +0200 Subject: scp -t . - possible idea for additional parameter In-Reply-To: References: <20071010175756.GD23125@wilbur.25thandClement.com> Message-ID: <20071013144403.24005.qmail@cdy.org> Larry, On Fri, Oct 12, 2007 at 08:15:59AM -0500, Larry Becke wrote: > Yes, this is the same person who never replies back to me, so that > I have to cut and paste their responses.... > > Thanks ever so much. This happens because people are expected to be subscribed to mailing lists before they post to them. That way there is no need to send out multiple copies of the message on the poster side, when there is already a distribution mechanism which will handle the message. That said, sometimes people do what you do; post to lists without being subscribed. I've done so too on occasion. When you do that, it is fairly important to mention that you are not subscribed so that we know that we need to include a copy to you. Thank you. > So - given that scp is the client software of choice, and that > chroot is out due to the limits on implementations (scp-only only > works within a user's home directory, and doesn't allow different > directories to be used for different keys), I guess I have little > choice but to look to the commercial ssh vendors who have already > expressed an interest in the changes outlined. Because you are using open source software you of course also have the infinitely empowering option of modifying the code so that it fits your task - or hiring someone else to do it. Of course, to appreciate and leverage these quite revolutionary circumstances in the software industry, you would indeed have to know the programming language. I'd be surprised if you are an experienced unix admin and this was the first time you could have solved a problem if you only knew C. If you do not want to know however, then yes, you are in the market for commercial software. //Peter From alon.barlev at gmail.com Sun Oct 14 02:13:22 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sat, 13 Oct 2007 18:13:22 +0200 Subject: OpenSSH PKCS#11merge In-Reply-To: <200709292009.39873.alon.barlev@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> Message-ID: <9e0cf0bf0710130913q7ef26c55gf3d9e391beef3b33@mail.gmail.com> Hello Peter, I will be happy to continue working with you on this one... I hope you did not give up :) The major issue I need to know: a. Do you think the agent protocol should be modified, as per my explanation? b. Do you think the ssh-agent may read ssh_config file for options? c. Do you think the utility that shows available PKCS#11 ids be part of ssh-add or separate utility? d. I need allocation of options (short parameter names) for PKCS#11 options. Best Regard, Alon Bar-Lev. On 9/29/07, Alon Bar-Lev wrote: > On 9/29/07, Peter Stuge wrote: > > Some comments from a quick read of the patch. I did not look at what > > the code does in great detail. > > Thank you so much for your time! > > > * Upstream > > > > I don't know what OpenBSD thinks about PKCS#11 but unless they > > fiercely reject it, I think the patch should be worked into the > > OpenBSD version of OpenSSH first, instead of the portable tree. > > Oh... I will be glad to do so, but I don't have a test environment for this... > I don't think I've done anything that prevent it to work with the > OpenBSD version... :) > If this is a requirement to proceed I will setup my first OpenBSD machine :) > > > * X.509 > > > > I agree with your reasoning that PKCS#11 goes well with X.509. > > > > However, since the X.509 patch is not included in OpenSSH, I don't > > think there should be anything X.509-related in the p11 patch. > > I think this and everything else about X.509 should go into Roumen's > > X.509 patch instead. > > I agree. > I've talked to Roumen in the past regarding this, if PKCS#11 support > is merged then the X.509 patch will enable PKCS#11 X.509 features. > But as long as this is an external patch, it is comfortable to users > to have this packaged this way. > > But regardless the above, a self-signed X.509 certificate is needed in > the public area of the token, in order to extract the public key. This > is required as many providers stores only X.509 certificate and > private key objects. > > > * Related changes > > > > --8<-- pkcs11.c > > + * WARNING!!! > > + * There is no way to get log level, > > + * so set to minimum. > > + * After fix in log.c it can be fixed. > > -->8-- > > > > What fix is needed in log.c? Maybe you already have a patch? > > Oh... > Simple... > Just to be able to return current log level... :) > > Just return log_level from log.c, something like: > > LogLevel > get_log_level () > { > return log_level; > } > > > --8<-- ssh-add.c > > + * TEMP TEMP TEMP TEMP > > + * > > + * This should be fixed if another mechanism > > + * will be propsed. > > -->8-- > > > > I for one would like to avoid temporary solutions that are known to > > be incorrect but work well enough. You mentioned extending the agent > > protocol. Can you expand on that a little? Is it really neccessary? > > Can't the agent figure out when it needs help from the user just from > > how it is being used without actually being instructed by anyone? > > This is the major change all smartcard components requires, there are > some opened issues in bugzilla regarding this. > > Smartcards are dynamic in nature unlike file based keys, smartcards > can be removed and inserted by the users, also the session between the > application and the smartcard is sometime time limited. > > When smartcards are also used in order to open the door for your > office, it tends to become even more dynamic. > > There are two kinds of user prompts that an smartcard enabled > application needs to have: > > 1. Token prompt - When key should be used but the hardware device is > not available the application should prompt the user to insert his > token. This is very important when re-negotiation is performed, as > users don't expect session disconnect because their token is not > available. > > 2. Passphrase prompt - Private key is used first time on session, may > be triggered when: > a. A new session is created. > b. Card was removed and inserted, this actually forces application to > create a new session. > c. Provider forces session duration timeout, this also forces > application to create a new session. > > Because I did not wanted to touch more than I needed, I currently > implemented these callbacks using external program the ssh-agent > execute when needed. > > But a much cleaner solution would be modifying the ssh-agent protocol > so that it inform the forground application to perform the prompt. > > So basically SSH2_AGENTC_SIGN_REQUEST and SSH_AGENTC_PKCS11_ADD_ID > may return an error with indication that a user interactive prompt is > needed with the details for the prompt (for example a string and type > of required prompt), so that application may handle the user > interaction. > > There should be added some more command, such as introduce key > passphrase and optionally wait for token. > > > If, in your opinion, the p11 patch can do everything that the current > > OpenSC support can, I think the current code should be removed and > > replaced with a compatibility layer that uses p11 to do what direct > > OpenSC use does now, and maybe even removed completely some time long > > in the future. > > Yes, it does anything and much more, many OpenSC users already using > this patch as it support dynamic smartcard availability and adding > identities into the agent without card available. > > I think OpenSSH should support only PKCS#11 for hardware cryptography, > making the code much cleaner. > > I suggested this in the past but it was rejected by some OpenSC users, > as I only updated the agent, while current OpenSC support does not > require agent configuration. > I have implemented agent only configuration to minimize my > modification, but if we proceed in merging I will add this support. > One thing we need to discuss is if we add all keys (as in OpenSC case) > or only user requested ones. I don't like adding all keys... :) > > BTW: I don't understood why ssh does not execute ssh-agent internally > if one is not available... GnuPG does this and it seems to minimize > code duplication... > > > * Coding style > > > > The patch doesn't follow the OpenSSH coding style. pkcs11_show_ids() > > is pretty crazy. > > Is there any document I can read? > I will convert it to whatever style needed. > The pkcs11_show_ids is crazy as we need to discuss where you want to > put this one... It can be exported to a standalone executable... Or > stay within this one... Also we should discuss the output format that > looks right for you... > > > * Copyright > > > > > + * The ssh_from_x509 is dirived of Tatu and Markus work. > > > > Please put all copyright notices in a file at the top of the file. > > Will do. > > > * do_pkcs11() > > > > Implementing a (file-)local getopt_long() surely can't be a good > > idea? > > I don't follow you... Can you please explain... > > In the past I asked to allocate some BSD style short option letters > for this one... :) > > But I think most options should go into configuration file, but the > ssh-agent does not currently have configuration file, so in order to > minimize my changes I've added these long options. Maybe we can make > ssh-agent read the ssh_config and take some options from there? > > The ssh-add will only requires --pkcs11-add-id, --pkcs11-remove-id and > optionally --pkcs11-show-ids. > > Thanks for quick reviewing, > Alon Bar-Lev. > From stuge-openssh-unix-dev at cdy.org Sun Oct 14 13:55:28 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Sun, 14 Oct 2007 05:55:28 +0200 Subject: OpenSSH PKCS#11merge In-Reply-To: <9e0cf0bf0710130913q7ef26c55gf3d9e391beef3b33@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> Message-ID: <20071014035528.10383.qmail@cdy.org> 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. :\ > The major issue I need to know: > a. Do you think the agent protocol should be modified, as per my > explanation? Short answer: No > b. Do you think the ssh-agent may read ssh_config file for options? Short answer: No > 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? > 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. //Peter From alon.barlev at gmail.com Sun Oct 14 15:42:09 2007 From: alon.barlev at gmail.com (Alon Bar-Lev) Date: Sun, 14 Oct 2007 07:42:09 +0200 Subject: OpenSSH PKCS#11merge In-Reply-To: <20071014035528.10383.qmail@cdy.org> 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> Message-ID: <9e0cf0bf0710132242k2a84ea74x644fdee327b780a2@mail.gmail.com> 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 sridhar.seetharaman at lehman.com Wed Oct 17 05:47:28 2007 From: sridhar.seetharaman at lehman.com (Seetharaman, Sridhar (GAE)) Date: Tue, 16 Oct 2007 15:47:28 -0400 Subject: openssh question Message-ID: If I need to add a client session logging (into a file), can I develop a loadable module instead of messing with clientloop.c/ssh.c? Sridhar Seetharaman Sridhar Seetharaman - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. -------- IRS Circular 230 Disclosure: Please be advised that any discussion of U.S. tax matters contained within this communication (including any attachments) is not intended or written to be used and cannot be used for the purpose of (i) avoiding U.S. tax related penalties or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein. From djm at mindrot.org Wed Oct 17 08:51:23 2007 From: djm at mindrot.org (Damien Miller) Date: Wed, 17 Oct 2007 08:51:23 +1000 (EST) Subject: openssh question In-Reply-To: References: Message-ID: On Tue, 16 Oct 2007, Seetharaman, Sridhar (GAE) wrote: > If I need to add a client session logging (into a file), can I develop a > loadable module instead of messing with clientloop.c/ssh.c? The client has no loadable module support, and we don't have any interest in adding one. -d From sridhar.seetharaman at lehman.com Wed Oct 17 09:40:03 2007 From: sridhar.seetharaman at lehman.com (Seetharaman, Sridhar (GAE)) Date: Tue, 16 Oct 2007 19:40:03 -0400 Subject: openssh question Message-ID: Thank you for quick response. Any support for keystroke session logging? Sridhar Seetharaman GTS: Application Process and Engineering ----- Original Message ----- From: Damien Miller To: Seetharaman, Sridhar (GAE) Cc: openssh-unix-dev at mindrot.org Sent: Tue Oct 16 18:51:23 2007 Subject: Re: openssh question On Tue, 16 Oct 2007, Seetharaman, Sridhar (GAE) wrote: > If I need to add a client session logging (into a file), can I develop a > loadable module instead of messing with clientloop.c/ssh.c? The client has no loadable module support, and we don't have any interest in adding one. -d - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. -------- IRS Circular 230 Disclosure: Please be advised that any discussion of U.S. tax matters contained within this communication (including any attachments) is not intended or written to be used and cannot be used for the purpose of (i) avoiding U.S. tax related penalties or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein. From mthibaut at cisco.com Wed Oct 17 09:50:09 2007 From: mthibaut at cisco.com (Maarten Thibaut) Date: Wed, 17 Oct 2007 01:50:09 +0200 (CEST) Subject: ssh_config man page Message-ID: Hi, The ssh_config man page doesn't list the GlobalKnownHostsFile2 or UserKnownHostsFile2 keywords, only the older versions without the 2s. Would it be possible to update them? thanks! maarten From djm at mindrot.org Wed Oct 17 11:29:04 2007 From: djm at mindrot.org (Damien Miller) Date: Wed, 17 Oct 2007 11:29:04 +1000 (EST) Subject: openssh question In-Reply-To: References: Message-ID: On Tue, 16 Oct 2007, Seetharaman, Sridhar (GAE) wrote: > Thank you for quick response. > > Any support for keystroke session logging? No, and we probably wouldn't want to include it in OpenSSH mainline because of privacy/abuse risk. -d From djm at mindrot.org Wed Oct 17 11:30:09 2007 From: djm at mindrot.org (Damien Miller) Date: Wed, 17 Oct 2007 11:30:09 +1000 (EST) Subject: ssh_config man page In-Reply-To: References: Message-ID: On Wed, 17 Oct 2007, Maarten Thibaut wrote: > Hi, > > The ssh_config man page doesn't list the GlobalKnownHostsFile2 or > UserKnownHostsFile2 keywords, only the older versions without the 2s. > Would it be possible to update them? GlobalKnownHostsFile2 and UserKnownHostsFile2 are deprecated and are not even supported in recent versions. From toby at butzon.com Thu Oct 18 03:42:00 2007 From: toby at butzon.com (Toby Butzon) Date: Wed, 17 Oct 2007 10:42:00 -0700 Subject: [patch] ssh.c load_public_identity_files calls getpwuid twice without copy Message-ID: <489be1d0710171042y4cec3481tdfae6699b4cf8308@mail.gmail.com> Hi, getpwuid is called as seen in the patch, and is then called again indirectly by tilde_expand_filename without first copying off the results from the first call. This is fatal on MacOSX (and it would seem it should be fatal elsewhere, too). Please CC me in replies; I'm not a subscriber. --- openssh-4.4p1/ssh.c 2006-09-01 22:32:40.000000000 -0700 +++ openssh-4.4p1-fix/ssh.c 2007-10-17 10:23:07.000000000 -0700 @@ -1252,6 +1252,7 @@ #endif /* SMARTCARD */ if ((pw = getpwuid(original_real_uid)) == NULL) fatal("load_public_identity_files: getpwuid failed"); + pw = pwcopy(pw); if (gethostname(thishost, sizeof(thishost)) == -1) fatal("load_public_identity_files: gethostname: %s", strerror(errno)); -- Toby Butzon From parcher at masergy.com Fri Oct 19 07:19:18 2007 From: parcher at masergy.com (Paul Archer) Date: Thu, 18 Oct 2007 16:19:18 -0500 (CDT) Subject: intermittent ssh connect error Message-ID: We've got set of servers that use AFD (http://www.dwd.de/AFD) to scp files to a set of receiving servers. There are about 25 sending machines, and 12 receiving machines. All the servers are RHEL 4 and 5, with the senders running openssh 4.3p2, and the receivers running 3.9p1. Most files are sent without a problem, but on a pretty regular basis, we get "ssh_exchange_identification: Connection closed by remote host" in our log files on the senders. The odd/interesting thing is that while that error often shows up on a connection to one machine, we also get bursts, where the error happens on connections to several different machines at once. That leads us to think it's an issue on the sending side, rather than the receiving side. I've tried tuning various network paramaters, both on the senders and the receivers, but no joy. I wasn't really sure that would help anyway, as netstat only reports between 20 and 30 connections (established & time_wait) at any given time--although that is almost exclusively ssh. Any recommendations on where to go from here? What to look for, what diagnostics to try? Paul -------------------- Paul Archer Senior Unix SysAdmin Masergy, Inc. 214-442-8827 parcher at masergy.com -------------------- PS My apologies if this isn't the appropriate list for this. PPS This is a sample of the errors we're getting in our AFD log files: 18 21:09:19 hoard10 [0]: 4796416 Bytes send in 8 file(s). 18 21:09:19 hoard09 [2]: 2170880 Bytes send in 26 file(s). 18 21:09:19 hoard04 [2]: 2170880 Bytes send in 26 file(s). 18 21:09:36 hoard03 [0]: Protocol error. ssh is complaining, see next message. #28b9df9d (ssh_common.c 427) 18 21:09:36 hoard03 [0]: ssh_exchange_identification: Connection closed by remote host 18 21:09:36 hoard03 [0]: SCP connection to 64.47.61.180 at port 22 failed (-1). #28b9df9d (sf_scp.c 298) 18 21:09:36 hoard01 [0]: Protocol error. ssh is complaining, see next message. #ba53f3db (ssh_common.c 427) 18 21:09:36 hoard01 [0]: ssh_exchange_identification: Connection closed by remote host 18 21:09:36 hoard01 [0]: SCP connection to 64.47.61.178 at port 22 failed (-1). #ba53f3db (sf_scp.c 298) 18 21:09:36 hoard11 [0]: Protocol error. ssh is complaining, see next message. #1a3b49e6 (ssh_common.c 427) 18 21:09:36 hoard11 [0]: ssh_exchange_identification: Connection closed by remote host 18 21:09:36 hoard11 [0]: SCP connection to 64.47.61.132 at port 22 failed (-1). #1a3b49e6 (sf_scp.c 298) 18 21:09:36 hoard04 [2]: Protocol error. ssh is complaining, see next message. #d83bb35 (ssh_common.c 427) 18 21:09:36 hoard04 [2]: ssh_exchange_identification: Connection closed by remote host 18 21:09:36 hoard04 [2]: SCP connection to 64.47.61.157 at port 22 failed (-1). #d83bb35 (sf_scp.c 298) 18 21:09:36 hoard05 [0]: Protocol error. ssh is complaining, see next message. #44f6ad16 (ssh_common.c 427) 18 21:09:36 hoard05 [0]: ssh_exchange_identification: Connection closed by remote host 18 21:09:36 hoard05 [0]: SCP connection to 64.47.61.156 at port 22 failed (-1). #44f6ad16 (sf_scp.c 298) 18 21:09:38 hoard12 [0]: 16384 Bytes send in 4 file(s). 18 21:09:38 hoard06 [0]: 16384 Bytes send in 4 file(s). 18 21:09:38 hoard07 [0]: 16384 Bytes send in 4 file(s). 18 21:09:39 hoard08 [0]: 16384 Bytes send in 4 file(s). 18 21:09:39 hoard02 [0]: 16384 Bytes send in 4 file(s). 18 21:09:47 hoard09 [1]: 4812800 Bytes send in 100 file(s). From dtucker at zip.com.au Fri Oct 19 07:30:33 2007 From: dtucker at zip.com.au (Darren Tucker) Date: Thu, 18 Oct 2007 14:30:33 -0700 Subject: intermittent ssh connect error In-Reply-To: References: Message-ID: <4717D079.2050608@zip.com.au> Paul Archer wrote: > We've got set of servers that use AFD (http://www.dwd.de/AFD) to scp files > to a set of receiving servers. There are about 25 sending machines, and 12 > receiving machines. All the servers are RHEL 4 and 5, with the senders > running openssh 4.3p2, and the receivers running 3.9p1. > > Most files are sent without a problem, but on a pretty regular basis, we > get "ssh_exchange_identification: Connection closed by remote host" in our > log files on the senders. > The odd/interesting thing is that while that error often shows up on a > connection to one machine, we also get bursts, where the error happens on > connections to several different machines at once. That leads us to think > it's an issue on the sending side, rather than the receiving side. I suspect you're hitting the MaxStartups unauthenticated connection limit. It default is 10, try bumping it on the servers to, say, 30 or 40. -- 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 1.41421 at gmail.com Fri Oct 19 09:10:43 2007 From: 1.41421 at gmail.com (JCA) Date: Thu, 18 Oct 2007 16:10:43 -0700 Subject: Window computation Message-ID: I am trying to make sense of the way in which OpenSSH computes window size, so far without much success :-( My understanding is that when a client specifies a window size N at the beginning of a session, it is letting the server know that it (the server) can send, on a given channel, up to N bytes worth of data that consumes window space (essentially the payload of SSH_MSG_CHANNEL_DATA and one or two more packets.) If the server sends more data of that type than allowed by the window size in the channel, the client is free to ignore such data silently. Therefore, the server has to wait for the client to send a window size adjust packet before sending more data. Again, if I understand things correctly, a server has to keep track of the number of window-consuming bytes that it has sent, stopping sending data when the current window is exhausted. Now how does an OpenSSH client decide when to send a window adjust packet? Looking into the OpenSSH code, the decision seems to be made in channel_check_window(), but it is not clear how and why. The exact nature of the fields local_window, local_consumed is not explained anywhere (as far as I can tell) and the correspondence with what the server is sending is not obvious. Let me give an example to make it really confusing :-) The first set of traces corresponds to an OpenSSH client that has started a file transfer session against a (non-OpenSSH) server. The initial window size specified by the client is 131072 bytes. The server then sends five packets in one go, consuming 26, 32768, 32768, 32768 and 32742 bytes, respectively, thus consuming the whole of the current window space. I understand the meaning of the first line in the client's traces: The window starts at 131072 bytes, a packet consuming 26 bytes has been received, which implies that the window size is reduced to 131046 bytes. The remaining lines I just don't get. Obviously the second packet has been received, for the local window in the client has been decremented to 98278 bytes. Where is the size (32768 bytes) of that second packet recorded? Where are those 4122, 8218, etc. bytes coming from? The server has never sent packets consuming such a number of bytes. Then when the local window, according to the client, is 65510 bytes, it sends a window adjust packet. Why at 65510 bytes? Why not when the window size reaches zero? Why adjust by 36890 bytes? I understand that this is more than the maximum packet size (which seems to be 32768 bytes) but how is 36980 arrived at? Interestingly, the server does receive the window adjust packet just in time, right after it has consumed all the previously available window space. Can anybody throw some light on all this? I believe that my confusion stems from the local_window and local_consumed fields mentioned above. Does anybody know exactly what they mean? Client traces: local window 131046, local consumed 26, local window max 131072 local window 98278, local consumed 4122, local window max 131072 local window 98278, local consumed 8218, local window max 131072 local window 98278, local consumed 12314, local window max 131072 local window 98278, local consumed 16410, local window max 131072 local window 98278, local consumed 20506, local window max 131072 local window 98278, local consumed 24602, local window max 131072 local window 98278, local consumed 28698, local window max 131072 local window 98278, local consumed 32794, local window max 131072 local window 98278, local consumed 32794, local window max 131072 local window 65510, local consumed 36890, local window max 131072 window 65510 sent adjust 36890 Server traces: 131072 26 131046 131046 32768 98278 98278 32768 65510 65510 32768 32742 32742 32742 0 Received 36890 adjust From djm at mindrot.org Fri Oct 19 10:59:36 2007 From: djm at mindrot.org (Damien Miller) Date: Fri, 19 Oct 2007 10:59:36 +1000 (EST) Subject: [patch] ssh.c load_public_identity_files calls getpwuid twice without copy In-Reply-To: <489be1d0710171042y4cec3481tdfae6699b4cf8308@mail.gmail.com> References: <489be1d0710171042y4cec3481tdfae6699b4cf8308@mail.gmail.com> Message-ID: On Wed, 17 Oct 2007, Toby Butzon wrote: > Hi, > > getpwuid is called as seen in the patch, and is then called again > indirectly by tilde_expand_filename without first copying off the > results from the first call. > > This is fatal on MacOSX (and it would seem it should be fatal elsewhere, too). > > Please CC me in replies; I'm not a subscriber. Thanks for the report - could you please file this at http://bugzilla.mindrot.org ? Thanks, Damien > --- openssh-4.4p1/ssh.c 2006-09-01 22:32:40.000000000 -0700 > +++ openssh-4.4p1-fix/ssh.c 2007-10-17 10:23:07.000000000 -0700 > @@ -1252,6 +1252,7 @@ > #endif /* SMARTCARD */ > if ((pw = getpwuid(original_real_uid)) == NULL) > fatal("load_public_identity_files: getpwuid failed"); > + pw = pwcopy(pw); > if (gethostname(thishost, sizeof(thishost)) == -1) > fatal("load_public_identity_files: gethostname: %s", > strerror(errno)); > > > -- > Toby Butzon > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From parcher at masergy.com Sat Oct 20 00:37:47 2007 From: parcher at masergy.com (Paul Archer) Date: Fri, 19 Oct 2007 09:37:47 -0500 (CDT) Subject: intermittent ssh connect error In-Reply-To: <4717D079.2050608@zip.com.au> References: <4717D079.2050608@zip.com.au> Message-ID: As the kid in "The Incredibles" says: "That was totally wicked!" Thanks much for helping me to solve what had been a long-standing and very annoying problem. (That'll teach me to pay more attention to every config option at the application layer before I go blaming the network, too.) Thanks again, Paul -------------------- Paul Archer Senior Unix SysAdmin Masergy, Inc. 214-442-8827 parcher at masergy.com -------------------- On Thu, 18 Oct 2007, Darren Tucker wrote: > Paul Archer wrote: >> We've got set of servers that use AFD (http://www.dwd.de/AFD) to scp files >> to a set of receiving servers. There are about 25 sending machines, and 12 >> receiving machines. All the servers are RHEL 4 and 5, with the senders >> running openssh 4.3p2, and the receivers running 3.9p1. >> >> Most files are sent without a problem, but on a pretty regular basis, we >> get "ssh_exchange_identification: Connection closed by remote host" in our >> log files on the senders. >> The odd/interesting thing is that while that error often shows up on a >> connection to one machine, we also get bursts, where the error happens on >> connections to several different machines at once. That leads us to think >> it's an issue on the sending side, rather than the receiving side. > > I suspect you're hitting the MaxStartups unauthenticated connection limit. > It default is 10, try bumping it on the servers to, say, 30 or 40. > > -- > 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 sridhar.seetharaman at lehman.com Sat Oct 20 00:39:38 2007 From: sridhar.seetharaman at lehman.com (Seetharaman, Sridhar (GAE)) Date: Fri, 19 Oct 2007 10:39:38 -0400 Subject: openssh question In-Reply-To: <20071019132750.GA19472@ganymede> References: <20071019132750.GA19472@ganymede> Message-ID: Thank you. Appreciate that. Let me try Sridhar Seetharaman GTS: Application Process and Engineering -----Original Message----- From: openssh at p23q.org [mailto:openssh at p23q.org] Sent: Friday, October 19, 2007 9:28 AM To: Seetharaman, Sridhar (GAE); openssh-unix-dev at mindrot.org Subject: Re: openssh question use LD_PRELOAD and a library that overloads read/write, e.g. http://0null.net/software/ttywrapper/ actually i wrote this to wrap the SSHD, but it might work with the client as well. losTrace - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. -------- IRS Circular 230 Disclosure: Please be advised that any discussion of U.S. tax matters contained within this communication (including any attachments) is not intended or written to be used and cannot be used for the purpose of (i) avoiding U.S. tax related penalties or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein. From openssh at p23q.org Fri Oct 19 23:27:50 2007 From: openssh at p23q.org (openssh at p23q.org) Date: Fri, 19 Oct 2007 13:27:50 +0000 Subject: openssh question In-Reply-To: References: Message-ID: <20071019132750.GA19472@ganymede> use LD_PRELOAD and a library that overloads read/write, e.g. http://0null.net/software/ttywrapper/ actually i wrote this to wrap the SSHD, but it might work with the client as well. losTrace -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20071019/c250aebb/attachment.bin From sridhar.seetharaman at lehman.com Sat Oct 20 00:34:59 2007 From: sridhar.seetharaman at lehman.com (Seetharaman, Sridhar (GAE)) Date: Fri, 19 Oct 2007 10:34:59 -0400 Subject: openssh question In-Reply-To: <20071019132750.GA19472@ganymede> References: <20071019132750.GA19472@ganymede> Message-ID: Cool. How do I open this? What is tbz2 format? Gunzip does not work. Sridhar Seetharaman GTS: Application Process and Engineering -----Original Message----- From: openssh at p23q.org [mailto:openssh at p23q.org] Sent: Friday, October 19, 2007 9:28 AM To: Seetharaman, Sridhar (GAE); openssh-unix-dev at mindrot.org Subject: Re: openssh question use LD_PRELOAD and a library that overloads read/write, e.g. http://0null.net/software/ttywrapper/ actually i wrote this to wrap the SSHD, but it might work with the client as well. losTrace - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - This message is intended only for the personal and confidential use of the designated recipient(s) named above. If you are not the intended recipient of this message you are hereby notified that any review, dissemination, distribution or copying of this message is strictly prohibited. This communication is for information purposes only and should not be regarded as an offer to sell or as a solicitation of an offer to buy any financial product, an official confirmation of any transaction, or as an official statement of Lehman Brothers. Email transmission cannot be guaranteed to be secure or error-free. Therefore, we do not represent that this information is complete or accurate and it should not be relied upon as such. All information is subject to change without notice. -------- IRS Circular 230 Disclosure: Please be advised that any discussion of U.S. tax matters contained within this communication (including any attachments) is not intended or written to be used and cannot be used for the purpose of (i) avoiding U.S. tax related penalties or (ii) promoting, marketing or recommending to another party any transaction or matter addressed herein. From toby at butzon.com Sat Oct 20 14:21:04 2007 From: toby at butzon.com (Toby Butzon) Date: Fri, 19 Oct 2007 21:21:04 -0700 Subject: [patch] ssh.c load_public_identity_files calls getpwuid twice without copy In-Reply-To: References: <489be1d0710171042y4cec3481tdfae6699b4cf8308@mail.gmail.com> Message-ID: <489be1d0710192121o67584bb8g145f00d60a1daced@mail.gmail.com> Filed bug 1377. Thanks! -- Toby Butzon From davide_cosentino at it.ibm.com Tue Oct 23 02:15:49 2007 From: davide_cosentino at it.ibm.com (Davide Cosentino) Date: Mon, 22 Oct 2007 18:15:49 +0200 Subject: Fw: about the "locale" command Message-ID: hello everybody, I am writing to you since you (or some one in you team) surely have more experience than me with "locales". Thanks in advance if you can help me. I am doing a test with two Linux hosts running the bash: GNU bash, version 3.00.15(1)-release (i386-redhat-linux-gnu) Copyright (C) 2004 Free Software Foundation, Inc. Now, when I locally run the "locale" command, on both the two machines (say: "host1" and "host2") I get the following: LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= Now , if I run the "locale" command from remote by using openSSH (from another linux box more or from Cygwin), like this: ssh -p 22 root at host1 locale I get: LANG=en_US.UTF-8 LC_CTYPE="en_US.UTF-8" LC_NUMERIC="en_US.UTF-8" LC_TIME="en_US.UTF-8" LC_COLLATE="en_US.UTF-8" LC_MONETARY="en_US.UTF-8" LC_MESSAGES="en_US.UTF-8" LC_PAPER="en_US.UTF-8" LC_NAME="en_US.UTF-8" LC_ADDRESS="en_US.UTF-8" LC_TELEPHONE="en_US.UTF-8" LC_MEASUREMENT="en_US.UTF-8" LC_IDENTIFICATION="en_US.UTF-8" LC_ALL= from the host host1. On the opposite I get: LANG= LC_CTYPE="POSIX" LC_NUMERIC="POSIX" LC_TIME="POSIX" LC_COLLATE="POSIX" LC_MONETARY="POSIX" LC_MESSAGES="POSIX" LC_PAPER="POSIX" LC_NAME="POSIX" LC_ADDRESS="POSIX" LC_TELEPHONE="POSIX" LC_MEASUREMENT="POSIX" LC_IDENTIFICATION="POSIX" LC_ALL= from host2. The question is: why is this difference and how can I fix host2 in order to produce the "correct" locale output (i.e.: to produce the same locale as when I run from locally)? Thanks for helping, Davide. From svallet at genoscope.cns.fr Tue Oct 23 02:04:14 2007 From: svallet at genoscope.cns.fr (Simon Vallet) Date: Mon, 22 Oct 2007 18:04:14 +0200 Subject: Intermittently stalling PAM authentication children Message-ID: <20071022180414.2db8beb9@tx3.tx.local> Hi, we encounter a problem using PAM with privsep to manage OPIE authentication : in some -- not really reproducible -- cases, the child responsible of PAM authentication stalls and continues to run even if its parent has been closed. The server is the standard RHEL 4 install, which is a 3.9p1 with backported security patches As this children account for the 'MaxStartups' limit, new users then get "remote host closed the connection" messages when trying to connect. As an example, we have two such processes (30622 and 13328) still running at the moment -- and absolutely no logs about them : unix$ ps | grep sshd 30622 1 root sshd: user1 [pam] 13328 1 root sshd: user2 [pam] 7687 1 root /usr/sbin/sshd -f /etc/ssh/sshd_config.OPIE unix$ tracing reveals they are blocked on a read() to file descriptor 7, which is a unix domain socket according to lsof and this is what gdb has to say (no debug version, sorry): #0 0x0000002a968b1a92 in __read_nocancel () from /lib64/tls/libc.so.6 #1 0x000000552aadea26 in packet_get_int () from /usr/sbin/sshd #2 0x000000552aae3f75 in kex_input_kexinit () from /usr/sbin/sshd #3 0x000000552aacdb60 in kexgex_server () from /usr/sbin/sshd #4 0x0000002a96eb1c27 in converse () from /lib/security/pam_opie.so #5 0x0000002a96eb1d7a in pam_sm_authenticate () from /lib/security/pam_opie.so #6 0x0000002a957787aa in _pam_dispatch () from /lib64/libpam.so.0 #7 0x0000002a9577a182 in pam_authenticate () from /lib64/libpam.so.0 #8 0x000000552aace845 in kexgex_server () from /usr/sbin/sshd #9 0x000000552aace10b in kexgex_server () from /usr/sbin/sshd #10 0x000000552aac6404 in session_close_by_channel () from /usr/sbin/sshd #11 0x000000552aac58d2 in session_close_by_channel () from /usr/sbin/sshd #12 0x000000552aac85a5 in session_close_by_channel () from /usr/sbin/sshd #13 0x000000552aab5b39 in main () from /usr/sbin/sshd Any ideas on how this happens ? Simon -- Simon Vallet Ing?nieur Syst?mes/R?seaux CEA DSV IG / Genoscope T?l. : 01 60 87 36 06 E-mail : svallet at genoscope.cns.fr From stuge-openssh-unix-dev at cdy.org Thu Oct 25 11:14:31 2007 From: stuge-openssh-unix-dev at cdy.org (Peter Stuge) Date: Thu, 25 Oct 2007 03:14:31 +0200 Subject: Fw: about the "locale" command In-Reply-To: References: Message-ID: <20071025011431.24643.qmail@cdy.org> On Mon, Oct 22, 2007 at 06:15:49PM +0200, Davide Cosentino wrote: > Now , if I run the "locale" command from remote by using openSSH > (from another linux box more or from Cygwin), like this: .. > LC_CTYPE="POSIX" > > from host2. > > > The question is: why is this difference and how can I fix host2 in > order to produce the "correct" locale output (i.e.: to produce the > same locale as when I run from locally)? Maybe it just doesn't support utf8 locales. I would guess that's the case if host2 is the Cygwin system, but that's just a FUD guess. :p //Peter From bob at proulx.com Fri Oct 26 06:35:43 2007 From: bob at proulx.com (Bob Proulx) Date: Thu, 25 Oct 2007 14:35:43 -0600 Subject: Fw: about the "locale" command In-Reply-To: References: Message-ID: <20071025203543.GB7401@dementia.proulx.com> Davide Cosentino wrote: > ssh -p 22 root at host1 locale > LANG=en_US.UTF-8 > LC_CTYPE="en_US.UTF-8" > ... Notice that LANG is reported without quotes while the others are reported with quotes? This is a hint. When a variable is set the locale command does not report it with quotes. When the variable is inferred by the presence of a set variable then it is quoted. So here I can see that LANG is set to en_US.UTF-8. > On the opposite I get: > > LANG= > LC_CTYPE="POSIX" Here I can see that LANG is not set. > The question is: why is this difference and how can I fix host2 in order to > produce the "correct" locale output (i.e.: to produce the same locale as > when I run from locally)? I suspect that in the host1 ~root/.bashrc file that LANG is explicitly set to LANG=en_US.UTF-8 and on the other host that it is not. The bash shell tries to guess when it is being run by a remote shell non-interactively and sources ~/.bashrc in that case. Depending on how sshd is installed and configured on your system it may be setting LANG through /etc/environment or /etc/default/locale or /etc/default/ssh or other system specific location. It is usually installed with PAM and therefore PAM configuration applies too. Bob From openssh at roumenpetrov.info Sat Oct 27 08:07:34 2007 From: openssh at roumenpetrov.info (Roumen Petrov) Date: Sat, 27 Oct 2007 01:07:34 +0300 Subject: Announce: X.509 certificates support in OpenSSH (version 6.1-International) Message-ID: <47226526.1000103@roumenpetrov.info> Hi All, The version 6.1 of "X.509 certificates support in OpenSSH" is ready for download. On page http://www.roumenpetrov.info/openssh/download.html you can found diffs for OpenSSH versions 4.5p1,4.6p1 and 4.7p1. Details ( from http://www.roumenpetrov.info/openssh ): * distinguished name compare bug(security): The bug affect versions 6.0 and 6.0.1 only. The work around is to write in "authorized keys" or "known hosts" files certificates in "blob" format instead "distinguished name". * uniform format for distinguished name output: Distinguished name print use common uniform format so that the name is same in all debug messages. The change also overcome existing prior limitation to print only first 512 characters form name. * char to integer conversion bug: Problem with conversion of non-ascii characters to integers on some old systems is resolved. All versions prior 6.1 are affected. Work around is to write in "authorized keys" or "known hosts" files certificates in "blob" format. Linux is not affected and problem exist on some old Unix-es. * OCSP support enabled by default: Now the OCSP support is build by default and users could configure theirs system to perform additional OCSP validation. * use non-deprecated LDAP functions The "X509 store" (if ldap support is build and configured) can query directory services for certificates. This is implemented as OpenSSL X509_LOOKUP method. The implementation is changed to avoid use of functions marked as deprecated in OpenLDAP headers. As result of the change "X509 store" option CAldapURL should be escaped (see details in man pages). Roumen From karfi.nci at gmail.com Mon Oct 29 02:51:33 2007 From: karfi.nci at gmail.com (Arief Karfianto) Date: Sun, 28 Oct 2007 22:51:33 +0700 Subject: HelpMe: Modify OpenSSH with C Programming Language. Message-ID: I try to modify OpenSSH. I want to add random delay function for each interactive mode so that the transmission of packet from ssh server to ssh client when client asked for password , has random delay. I have download OpenSSH-4.7p1 and I'm familiar enough with C Programming Language and Linux. But I don't know , which part or which file that I have to modify. I hope for some reply . Thank you very much before. From maf at appgate.com Tue Oct 30 16:55:17 2007 From: maf at appgate.com (maf at appgate.com) Date: Tue, 30 Oct 2007 06:55:17 +0100 (CET) Subject: Patch: open port forwards from slave Message-ID: We run ssh from a program and needed to add port-forwards dynamically. The ~C method turns out to be very cumbersome to use since it reads from /dev/tty. But then I came to think of the master/slave functionality (which we already used) which seemed a perfect place for this functionality. Unfortunately it turned out not to be possible to set up new port forwards in a slave. So I patched openssh to make it possible to add port forwards via a slave process. This is done by creating a new command which can be sent over the control connection (SSHMUX_COMMAND_FORWARD). The patch against openssh current can be downloaded (13K) from: http://www.appgate.com/downloads/maf/slavepf-current.patch I would be happy if other people found it useful and if it could make it into the official distribution. /MaF -- Martin Forssen Development Manager Phone: +46 31 7744361 AppGate Network Security AB From djm at mindrot.org Tue Oct 30 17:52:51 2007 From: djm at mindrot.org (Damien Miller) Date: Tue, 30 Oct 2007 17:52:51 +1100 (EST) Subject: Patch: open port forwards from slave In-Reply-To: References: Message-ID: On Tue, 30 Oct 2007, maf at appgate.com wrote: > We run ssh from a program and needed to add port-forwards dynamically. > The ~C method turns out to be very cumbersome to use since it reads from > /dev/tty. But then I came to think of the master/slave functionality > (which we already used) which seemed a perfect place for this > functionality. Unfortunately it turned out not to be possible to set up > new port forwards in a slave. > > So I patched openssh to make it possible to add port forwards via a > slave process. This is done by creating a new command which can be sent > over the control connection (SSHMUX_COMMAND_FORWARD). The patch against > openssh current can be downloaded (13K) from: > > http://www.appgate.com/downloads/maf/slavepf-current.patch > > I would be happy if other people found it useful and if it could make it > into the official distribution. Hi, Thanks for this, it seems to implement the approach that I'd planned but haven't had time to do myself. I'll try to get it in for the 4.8 release. To make sure it doesn't get lost, could you please attach this patch to the bug at: https://bugzilla.mindrot.org/show_bug.cgi?id=993 Before you submit it, it would be best if you could review it in light of the style guide[1] - I noticed that it uses spaces instead of tabs and doesn't do indenting quite the same way as the existing code. Thanks, Damien [1] http://www.openbsd.org/cgi-bin/man.cgi?query=style&sektion=9 From Karl-Heinz.Delzeit at jet-software.com Wed Oct 31 22:41:31 2007 From: Karl-Heinz.Delzeit at jet-software.com (Karl-Heinz.Delzeit) Date: Wed, 31 Oct 2007 12:41:31 +0100 (CET) Subject: pam_close_session for ssh as root Message-ID: <34029961341044@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