From petfire85 at yahoo.fr Thu Oct 1 07:40:14 2009 From: petfire85 at yahoo.fr (Steeve BARBEAU) Date: Wed, 30 Sep 2009 23:40:14 +0200 Subject: Question about Server Authentication In-Reply-To: References: <324763.44539.qm@web24710.mail.ird.yahoo.com> Message-ID: @Dan : Yes a little because if you want to automate SSH connection in a script, your are obliged to known which algorithm the server is using (RSA, DSA or both). The only "solution" i see, is to configure all servers in the same way, but if OpenSSH developers can correct this in a future version it will be very nice. @Damien : "HostKeyAlgorithms ssh-dss, ssh-rsa" is just to change which key use, isn't it ? With this ("HostKeyAlgorithms ssh-dss, ssh-rsa") , you are obliged to have the DSA server key in your known_hosts file. If you have no key or the RSA, it ask you to add the DSA. So the ideal for me will be, in the case where both RSA and DSA are enabled, that ssh client checks the known_hosts file for both RSA and DSA keys, actually i don't think that OpenSSH can do this. Actually, OpenSSH (client-side) searchs for the prefer algorithm and if it doesn't found it, it wants to add this key without try server authentication with the other key (if another is present) From djm at mindrot.org Thu Oct 1 18:35:04 2009 From: djm at mindrot.org (Damien Miller) Date: Thu, 1 Oct 2009 18:35:04 +1000 (EST) Subject: Question about Server Authentication In-Reply-To: References: <324763.44539.qm@web24710.mail.ird.yahoo.com> Message-ID: On Wed, 30 Sep 2009, Steeve BARBEAU wrote: > @Dan : Yes a little because if you want to automate SSH connection in a > script, your are obliged to known which algorithm the server is using (RSA, > DSA or both). The only "solution" i see, is to configure all servers in the > same way, but if OpenSSH developers can correct this in a future version it > will be very nice. > @Damien : "HostKeyAlgorithms ssh-dss, ssh-rsa" is just to change which key > use, isn't it ? With this ("HostKeyAlgorithms ssh-dss, ssh-rsa") , you are > obliged to have the DSA server key in your known_hosts file. If you have no > key or the RSA, it ask you to add the DSA. > > So the ideal for me will be, in the case where both RSA and DSA are enabled, > that ssh client checks the known_hosts file for both RSA and DSA keys, > actually i don't think that OpenSSH can do this. Actually, OpenSSH > (client-side) searchs for the prefer algorithm and if it doesn't found it, > it wants to add this key without try server authentication with the other > key (if another is present) Please file a request at https://bugzilla.mindrot.org/ to track this, though I have to say it will be pretty far down the priority queue - most people just pick a key type (almost always the default) and accept that. I think that very few users would have the client/server keys ever change type. -d From dan at doxpara.com Thu Oct 1 18:58:02 2009 From: dan at doxpara.com (Dan Kaminsky) Date: Thu, 1 Oct 2009 10:58:02 +0200 Subject: Question about Server Authentication In-Reply-To: References: <324763.44539.qm@web24710.mail.ird.yahoo.com> Message-ID: On Thu, Oct 1, 2009 at 10:35 AM, Damien Miller wrote: > On Wed, 30 Sep 2009, Steeve BARBEAU wrote: > >> @Dan : Yes a little because if you want to automate SSH connection in a >> script, your are obliged to known which algorithm the server is using (RSA, >> DSA or both). The only "solution" i see, is to configure all servers in the >> same way, but if OpenSSH developers can correct this in a future version it >> will be very nice. >> @Damien : "HostKeyAlgorithms ssh-dss, ssh-rsa" is just to change which key >> use, isn't it ? With this ("HostKeyAlgorithms ssh-dss, ssh-rsa") , you are >> obliged to have the DSA server key in your known_hosts file. If you have no >> key or the RSA, it ask you to add the DSA. >> >> So the ideal for me will be, in the case where both RSA and DSA are enabled, >> that ssh client checks the known_hosts file for both RSA and DSA keys, >> actually i don't think that OpenSSH can do this. Actually, OpenSSH >> (client-side) searchs for the prefer algorithm and if it doesn't found it, >> it wants to add this key without try server authentication with the other >> key (if another is present) > > Please file a request at https://bugzilla.mindrot.org/ to track this, though > I have to say it will be pretty far down the priority queue - most people > just pick a key type (almost always the default) and accept that. I think > that very few users would have the client/server keys ever change type. > > -d > Poked around on this a little. I'm curious, looks like the codepath is: check_key_in_hostfiles -> check_host_in_hostfile -> check_host_in_hostfile_by_key_or_type. Also looks like *key contains the actual type of the key being tested. Could we put this a little bit after hostfile_read_key in check_host_in_hostfile_by_key_or_type and call it a day? if(key != NULL && found != NULL && key->type != found->type) { continue; } From djm at cvs.openbsd.org Thu Oct 1 23:46:17 2009 From: djm at cvs.openbsd.org (Damien Miller) Date: Thu, 1 Oct 2009 07:46:17 -0600 (MDT) Subject: Announce: OpenSSH 5.3 released Message-ID: <200910011346.n91DkHhw017843@cvs.openbsd.org> OpenSSH 5.3 has just been released. It will be available from the mirrors listed at http://www.openssh.com/ shortly. OpenSSH is a 100% complete SSH protocol version 1.3, 1.5 and 2.0 implementation and includes sftp client and server support. This release marks the 10th anniversary of the OpenSSH project. We would like to thank the OpenSSH community for their support, especially those who will continue to contribute code or patches, report bugs, test snapshots or donate to the project during the next 10 years. More information on donations may be found at: http://www.openssh.com/donations.html This is a bugfix release, no new features have been added. Changes since OpenSSH 5.2 ========================= General Bugfixes: * Do not limit home directory paths to 256 characters. bz#1615 * Several minor documentation and correctness fixes. Portable OpenSSH Bugfixes: * This release removes for support for very old versions of Cygwin and for Windows 95/98/ME * Move the deletion of PAM credentials on logout to after the session close. bz#1534 * Make PrintLastLog work on AIX. bz#1595 * Avoid compile errors on FreeBSD from conflicts in glob.h. bz#1634 * Delay dropping of root privileges on AIX so chroot and pam_open_session work correctly. bz#1249 and bz#1567 * Increase client IO buffer on Cygwin to 64K, realising a significant performance improvement. * Roll back bz#1241 (better handling for expired passwords on Tru64). The change broke password logins on some configurations. * Accept ENOSYS as a fallback error when attempting atomic rename(). bz#1535 * Fix passing of variables to recursive make(1) invocations on Solaris. bz#1505 * Skip the tcgetattr call on the pty master on Solaris, since it never succeeds and can hang if large amounts of data is sent to the slave (eg a copy-paste). bz#1528 * Fix detection of krb5-config. bz#1639 * Fix test for server-assigned remote forwarding port for non-root users. bz#1578 * Fix detection of libresolv on OSX 10.6. Checksums: ========== - SHA1 (openssh-5.3.tar.gz) = f1b9a280565e916c1f84fd4d944313ec926242a2 - SHA1 (openssh-5.3p1.tar.gz) = d411fde2584ef6022187f565360b2c63a05602b5 Reporting Bugs: =============== - Please read http://www.openssh.com/report.html Security bugs should be reported directly to openssh at openssh.com OpenSSH is brought to you by Markus Friedl, Niels Provos, Theo de Raadt, Kevin Steves, Damien Miller, Darren Tucker, Jason McIntyre, Tim Rice and Ben Lindstrom. From petfire85 at yahoo.fr Fri Oct 2 08:25:35 2009 From: petfire85 at yahoo.fr (Steeve BARBEAU) Date: Fri, 2 Oct 2009 00:25:35 +0200 Subject: Question about Server Authentication In-Reply-To: References: <324763.44539.qm@web24710.mail.ird.yahoo.com> Message-ID: I've describe the bug on bugzilla. The url : https://bugzilla.mindrot.org/show_bug.cgi?id=1657 From john.marshall at riverwillow.com.au Fri Oct 2 17:24:00 2009 From: john.marshall at riverwillow.com.au (John Marshall) Date: Fri, 2 Oct 2009 17:24:00 +1000 Subject: How to generate additional debug messages for sshd gssapi failures? In-Reply-To: <4AB931B2.4060105@ncsa.uiuc.edu> References: <20090921070514.GD1001@rwpc12.mby.riverwillow.net.au> <4AB931B2.4060105@ncsa.uiuc.edu> Message-ID: <20091002072359.GL37304@rwpc12.mby.riverwillow.net.au> On Tue, 22 Sep 2009, 15:21 -0500, Jim Basney wrote: > Maybe this will help with troubleshooting. It may require setting > UsePrivilegeSeparation no in sshd_config to get a useful error message. > > Index: auth2-gss.c > =================================================================== > RCS file: /cvs/openssh/auth2-gss.c,v > retrieving revision 1.19 > diff -u -r1.19 auth2-gss.c Thank you Jim, That provided me with enough clues to do the troubleshooting I needed to do. The problem ended up being a gssapi-with-mic compatibility issue between Kerberos implementations on the client and server. -- John Marshall -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From john.marshall at riverwillow.com.au Fri Oct 2 17:29:29 2009 From: john.marshall at riverwillow.com.au (John Marshall) Date: Fri, 2 Oct 2009 17:29:29 +1000 Subject: GSSAPI Kerberos Differences between 5.1p1 and 5.2p1? In-Reply-To: <20090717065705.GJ17677@rwpc12.mby.riverwillow.net.au> References: <20090717065705.GJ17677@rwpc12.mby.riverwillow.net.au> Message-ID: <20091002072928.GM37304@rwpc12.mby.riverwillow.net.au> On Fri, 17 Jul 2009, 16:57 +1000, John Marshall wrote: > I'm trying to find clues on what may have changed for GSSAPI (Kerberos) > authentication between OpenSSH 5.1p1 and 5.2p1. We have been using > GSSAPI authentication for ssh for about 18 months with no problem with > the OpenSSH build that is bundled with the FreeBSD operating system. > All of those machines have OpenSSH 5.1p1. Last week I upgraded one of > the servers to FreeBSD 8.0-BETA1 (yes, I know, BETA) which includes > OpenSSH 5.2p1. > > GSSAPI authentication no longer works properly for access to the OpenSSH > 5.2p1 server. I think I've narrowed this down to OpenSSH 5.2p1 because > if I install the FreeBSD OpenSSH port (5.2p1) on one of our FreeBSD > 7.2-RELEASE servers, I am seeing the same symptoms. This turned out to be a gssapi-with-mic compatibility issue between different versions of Heimdal. My misplaced implication of OpenSSH 5.2p1 was due to the fact that I had linked it against a newer version of Heimdal. -- John Marshall -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 196 bytes Desc: not available URL: From petfire85 at yahoo.fr Sat Oct 3 07:06:17 2009 From: petfire85 at yahoo.fr (Steeve BARBEAU) Date: Fri, 2 Oct 2009 23:06:17 +0200 Subject: Question about Server Authentication In-Reply-To: References: <324763.44539.qm@web24710.mail.ird.yahoo.com> <8B0EEA23-FB1B-4B94-A383-0F4D9D5D8194@doxpara.com> Message-ID: So, I've tried your modification but it doesn't work, I'll search and I hope I'll find the solution. Thanks for your help Dan and Damien On Fri, Oct 2, 2009 at 8:36 AM, Dan Kaminsky wrote: > Go into your OpenSSH source, hostfile.c. > > Find the line: > > if (!hostfile_check_key(kbits, found, host, filename, > linenum)) > continue; > > Right before it, add: > > if(key != NULL && > found != NULL && > key->type != found->type) { continue; } > > Alternatively I'll gin you up a patch file if you tell me what build > you want me to make one against. > > NO IDEA if this'll work but I think it hits what you're talking about. > > On Fri, Oct 2, 2009 at 8:24 AM, Steeve BARBEAU wrote: > > Yes of course. > > > > > From dan at doxpara.com Sat Oct 3 08:06:00 2009 From: dan at doxpara.com (Dan Kaminsky) Date: Fri, 2 Oct 2009 15:06:00 -0700 Subject: Question about Server Authentication In-Reply-To: References: <324763.44539.qm@web24710.mail.ird.yahoo.com> <8B0EEA23-FB1B-4B94-A383-0F4D9D5D8194@doxpara.com> Message-ID: <7AEED653-6ECF-41C7-93E6-BF2E8F0F9484@doxpara.com> Oh don't give up so quick :). I was just seeing if a really stupid fix would work. Give me a precise client/server config that repros your bug? On Oct 2, 2009, at 2:06 PM, Steeve BARBEAU wrote: > So, I've tried your modification but it doesn't work, I'll search > and I hope I'll find the solution. Thanks for your help Dan and Damien > > On Fri, Oct 2, 2009 at 8:36 AM, Dan Kaminsky wrote: > Go into your OpenSSH source, hostfile.c. > > Find the line: > > if (!hostfile_check_key(kbits, found, host, filename, > linenum)) > continue; > > Right before it, add: > > if(key != NULL && > found != NULL && > key->type != found->type) { continue; } > > Alternatively I'll gin you up a patch file if you tell me what build > you want me to make one against. > > NO IDEA if this'll work but I think it hits what you're talking about. > > On Fri, Oct 2, 2009 at 8:24 AM, Steeve BARBEAU > wrote: > > Yes of course. > > > > > From petfire85 at yahoo.fr Sat Oct 3 20:49:55 2009 From: petfire85 at yahoo.fr (Steeve BARBEAU) Date: Sat, 3 Oct 2009 12:49:55 +0200 Subject: Question about Server Authentication In-Reply-To: <7AEED653-6ECF-41C7-93E6-BF2E8F0F9484@doxpara.com> References: <324763.44539.qm@web24710.mail.ird.yahoo.com> <8B0EEA23-FB1B-4B94-A383-0F4D9D5D8194@doxpara.com> <7AEED653-6ECF-41C7-93E6-BF2E8F0F9484@doxpara.com> Message-ID: To try, you need the DSA key in the known_hosts file of the client and enable both RSA and DSA in the server (normally it's this by default) Is it possible that an OpenSSH developer which functions are used and in which order ? Perhaps you have some documentation ? I don't find wich function is called after check_host_in_hostfile_by_key_or_type() returns HOST_FOUND or HOST_OK From saku at ytti.fi Mon Oct 5 00:37:13 2009 From: saku at ytti.fi (Saku Ytti) Date: Sun, 4 Oct 2009 16:37:13 +0300 Subject: ControlMaster and packet stuffing Message-ID: <20091004133713.GA29224@mx.ytti.net> When I'm running interactive ssh session which is ControlMaster and I run scp or sftp to same host, creating another channel, it seems that ssh is stuffing the packets together exceeding MTU. I've for years ran QoS where I prioritize small packets, as it is clean and easy way to guarantee low latency to pretty much all you care for. Unfortunately ControlMaster packet stuffing breaks this, my interactive packets are not small anymore for the duration of scp/sftp and receive best effort treatment making my interactive session extremely laggy. Is there particular need to combine interactive packets with MTU sized data packets? In what type of situation is the current behaviour desired? Thanks, -- ++ytti From saku at ytti.fi Mon Oct 5 01:24:13 2009 From: saku at ytti.fi (Saku Ytti) Date: Sun, 4 Oct 2009 17:24:13 +0300 Subject: ControlMaster and packet stuffing In-Reply-To: <20091004133713.GA29224@mx.ytti.net> References: <20091004133713.GA29224@mx.ytti.net> Message-ID: <20091004142413.GA29474@mx.ytti.net> > When I'm running interactive ssh session which is ControlMaster and I run scp > or sftp to same host, creating another channel, it seems that ssh is stuffing > the packets together exceeding MTU. It seems likely that I got confused by looking tshark, seeing box sending bigger packets than MTU, but that was likely due to XEN NIC offering large-segment-offload. So this may be expected behaviour with no obvious workaround, other than not using ControlMaster when doing both interactive and sftp/scp to same host. -- ++ytti From gert at greenie.muc.de Mon Oct 5 04:58:54 2009 From: gert at greenie.muc.de (Gert Doering) Date: Sun, 4 Oct 2009 19:58:54 +0200 Subject: ControlMaster and packet stuffing In-Reply-To: <20091004142413.GA29474@mx.ytti.net> References: <20091004133713.GA29224@mx.ytti.net> <20091004142413.GA29474@mx.ytti.net> Message-ID: <20091004175854.GE1508@greenie.muc.de> Hi, On Sun, Oct 04, 2009 at 05:24:13PM +0300, Saku Ytti wrote: > So this may be expected behaviour with no obvious workaround, other than > not using ControlMaster when doing both interactive and sftp/scp to same > host. I'd say "this is expected behaviour" - the large packets (full of sftp/scp data) will be in the same TCP data stream as your interactive packets. So if the sftp packet gets delayed, the interactive typing will also get delayed, as TCP will have to wait for all data to arrive to put it back into proper sequence. So - "don't do interactive and bulk transfers over the same TCP session". gert (I've seen a presentation by someone at 2007's SIGCOMM working on a protocol to replace TCP, UDP, and SCTP that would permit this - have multiple streams with different requirements inside one "data connection" in parallel, but since then, I've never heard of this again...) -- 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 yaniv at aknin.name Tue Oct 6 05:27:09 2009 From: yaniv at aknin.name (Yaniv Aknin) Date: Mon, 5 Oct 2009 20:27:09 +0200 Subject: Authenticating users from proprietary user databases Message-ID: Hi, I work for a company which develops a rather complicated Linux-based grid-technology appliance. The appliance is made of several Linux hosts, exposing its functionality over a proprietary CLI-like protocol. This protocol currently works by running a proprietary client executable on a host, sending the command via TCP/IP to one of the appliance's hosts and receiving the response. The client handles authentication, compression, etc. In addition, it is possible to access the various hosts of the clustered appliance as a regular Linux host using plain SSH for technician maintenance (not exposed to customers). I'm a big proponent of exposing our CLI over SSH as well and doing away with the proprietary "cli executable". Already the CLI executable can run inside the appliance itself, and I'd very much like it to be possible to run a single CLI command by running: $ ssh user at appliance command parameter=value ...and also to make it possible to run a readline based appliance-CLI interactive "shell" (we already have something like that) by running: $ ssh user at appliance We can easily separate (at least, at the transport layer) between the "maintenance" SSH shell and the "CLI" SSH shell by running two sshd instances and binding them to different ports (or addresses). I'm thinking that the CLI-SSH instance have a sshd_config global ForceCommand that will read SSH_ORIGINAL_COMMAND and run the CLI command or the 'CLI interactive shell' accordingly. Also, I think I realize the security implications insofar as our CLI executable is concerned, as well as the importance of sanitizing the SSH connection (no sftp, no forwarding, etc). I'd much rather not direct the discussion in that direction, unless you think this is totally imperative and I missed something gargantuan. I know exploiting our CLI can easily mean exploiting our box and I'll take that into account as best I can (I'm not sure the current implementation is any better, either). The issue I'm not sure how to tackle is how to make SSH 'natively' authenticate the appliance's built-in users. Our appliance has its own user directory with credentials, unrelated to the passwd/shadow directory of nsswitch. The 'obvious' solution is to write an nsswitch module which will fake all users from the appliance's proprietary directory as passwd:shadow entries (we store the passwords in a way that is shadow compatible), and give all users a uniform passwd entry with only the username/shadow hash changing. This entry will have a fixed UID, GID, shell and homedir, and this fixed homedir will contain an authorized_keys file that will dynamically contain keys as set for our appliance's users (I'll add the CLI command "user_add_ssh_key" or something). While the above solution is, like I said, obvious, it has a very severe drawback I'm not sure how to tackle, and that's the fact that nsswitch modules are system global. I don't want our hosts' Linux users (root, nobody, daemon, etc) to collide with the appliance's users and vice versa, and I'd definitely not want to jeopardize the stability of core Linux services in any way by adding something as complex as looking up our clustered database for users from within all processes in the system. I'm not sure how to further handle this. Should I patch OpenSSH itself (oh god, please, no...)? Should I use some dynamic LD_PRELOAD concoction to 'rewrite' nsswitch.conf only for this sshd instance? Should I give up on OpenSSH entirely and use an SSH implementation which is less focused on letting system-users run shell-commands (like twisted.conch, or maybe others)? All these options are... well, doable, but all seem like a lot of (fragile) work. I'd appreciate comments and ideas. Sincerely, - Yaniv From dtucker at zip.com.au Tue Oct 6 06:23:23 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 06 Oct 2009 06:23:23 +1100 Subject: Authenticating users from proprietary user databases In-Reply-To: References: Message-ID: <4ACA47AB.60900@zip.com.au> Yaniv Aknin wrote: [...] > I'm not sure how to further handle this. Should I patch OpenSSH itself (oh > god, please, no...)? Should I use some dynamic LD_PRELOAD concoction to > 'rewrite' nsswitch.conf only for this sshd instance? You could write those replacement functions for getpwnam() and friends and just statically link them into application sshd. This is what we already do with libopenbsd-compat when there's a broken native function for which we have compat code (eg snprintf). As long as the replacement functions provide the system-level accounts that sshd expects (all I can think of is root and the privsep user) then it should work, and should not require any patching (just feed configure "--with-ldflags=-lyourlib"). -- 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 yaniv at aknin.name Tue Oct 6 06:35:20 2009 From: yaniv at aknin.name (Yaniv Aknin) Date: Mon, 5 Oct 2009 21:35:20 +0200 Subject: Authenticating users from proprietary user databases In-Reply-To: <4ACA47AB.60900@zip.com.au> References: <4ACA47AB.60900@zip.com.au> Message-ID: Hrmf, how simple, I didn't think about patching getpwnam() et al themselves, I was somehow locked on patching the nsswitch circuitry. But in this case, why not use LD_PRELOAD and avoid the need to build my own OpenSSH and have two different OpenSSH builds? Thanks, - Yaniv On Mon, Oct 5, 2009 at 9:23 PM, Darren Tucker wrote: > Yaniv Aknin wrote: > [...] > >> I'm not sure how to further handle this. Should I patch OpenSSH itself (oh >> god, please, no...)? Should I use some dynamic LD_PRELOAD concoction to >> 'rewrite' nsswitch.conf only for this sshd instance? >> > > You could write those replacement functions for getpwnam() and friends and > just statically link them into application sshd. This is what we already do > with libopenbsd-compat when there's a broken native function for which we > have compat code (eg snprintf). > > As long as the replacement functions provide the system-level accounts that > sshd expects (all I can think of is root and the privsep user) then it > should work, and should not require any patching (just feed configure > "--with-ldflags=-lyourlib"). > > -- > 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 chrivers at iversen-net.dk Tue Oct 6 07:31:23 2009 From: chrivers at iversen-net.dk (Christian Iversen) Date: Mon, 05 Oct 2009 22:31:23 +0200 Subject: Authenticating users from proprietary user databases In-Reply-To: References: Message-ID: <4ACA579B.2060203@iversen-net.dk> On 2009-10-05 20:27, Yaniv Aknin wrote: > Hi, > > I work for a company which develops a rather complicated Linux-based > grid-technology appliance. The appliance is made of several Linux hosts, > exposing its functionality over a proprietary CLI-like protocol. This > protocol currently works by running a proprietary client executable on a > host, sending the command via TCP/IP to one of the appliance's hosts and > receiving the response. The client handles authentication, compression, etc. > In addition, it is possible to access the various hosts of the clustered > appliance as a regular Linux host using plain SSH for technician maintenance > (not exposed to customers). > > I'm a big proponent of exposing our CLI over SSH as well and doing away with > the proprietary "cli executable". Already the CLI executable can run inside > the appliance itself, and I'd very much like it to be possible to run a > single CLI command by running: > $ ssh user at appliance command parameter=value > ...and also to make it possible to run a readline based appliance-CLI > interactive "shell" (we already have something like that) by running: > $ ssh user at appliance > > We can easily separate (at least, at the transport layer) between the > "maintenance" SSH shell and the "CLI" SSH shell by running two sshd > instances and binding them to different ports (or addresses). Does this mean that you want every user to be able to log on in either "CLI" or "maintenance" mode? Otherwise, just set the shell of the specific users to the right shell. > The issue I'm not sure how to tackle is how to make SSH 'natively' > authenticate the appliance's built-in users. Our appliance has its own user > directory with credentials, unrelated to the passwd/shadow directory of > nsswitch. The 'obvious' solution is to write an nsswitch module which will > fake all users from the appliance's proprietary directory as passwd:shadow > entries (we store the passwords in a way that is shadow compatible), and > give all users a uniform passwd entry with only the username/shadow hash > changing. This entry will have a fixed UID, GID, shell and homedir, and this > fixed homedir will contain an authorized_keys file that will dynamically > contain keys as set for our appliance's users (I'll add the CLI command > "user_add_ssh_key" or something). > > While the above solution is, like I said, obvious, it has a very severe > drawback I'm not sure how to tackle, and that's the fact that nsswitch > modules are system global. I don't want our hosts' Linux users (root, > nobody, daemon, etc) to collide with the appliance's users and vice versa, > and I'd definitely not want to jeopardize the stability of core Linux > services in any way by adding something as complex as looking up our > clustered database for users from within all processes in the system. > > I'm not sure how to further handle this. Should I patch OpenSSH itself (oh > god, please, no...)? Should I use some dynamic LD_PRELOAD concoction to > 'rewrite' nsswitch.conf only for this sshd instance? Should I give up on > OpenSSH entirely and use an SSH implementation which is less focused on > letting system-users run shell-commands (like twisted.conch, or maybe > others)? All these options are... well, doable, but all seem like a lot of > (fragile) work. I'd appreciate comments and ideas. I have worked with authentication solutions before (specifically with NSS), and as far as I can see, you have a few options. I'll let you decide which one suit your needs better, if any: 1a) Make an NSS plugin (as you suggested) 1b) Make an NSS plugin with virtual usernames As 1a, but prefix all usernames with a common prefix, such as "cli_" That way, the names cannot clash. 2) Actually export CLI users into system users in passwd and shadow Doesn't seem very nice, but it could work 3) Use libnss-extrausers This existing plugin allows you to have an entirely seperate set of passwd/group/shadow files, that are not related to the usual ones in /etc. This way, you can safely make an export of all your users into the files in /var/lib/extrausers, without risking anything. Worst case, only your CLI users are affected by any problems. 4) Use a common database for all users If you can export your current users (and change your existing tools) to use something like PostgreSQL or LDAP for storing users, you'd be able to use existing NSS plugins to connect to them. Out of these options, I'd recommend that you look at number 3, since it's so dead simple to use, while still (I believe) solving your problem. -- Med venlig hilsen Christian Iversen From bert at bertenselena.net Tue Oct 6 01:49:19 2009 From: bert at bertenselena.net (Bert Haverkamp) Date: Mon, 5 Oct 2009 16:49:19 +0200 Subject: Hardlink patches for sftp In-Reply-To: <1e68a10b0909280429s7ae24be0uf1e24d821f8f5b68@mail.gmail.com> References: <1e68a10b0909201015kfe5a8bexe9ffd84791216ce1@mail.gmail.com> <1e68a10b0909280429s7ae24be0uf1e24d821f8f5b68@mail.gmail.com> Message-ID: <1e68a10b0910050749l43401f01rb385d072c56f284@mail.gmail.com> Sorry for the repeat again, but a week has gone by and I have not been able to find the information. Anyone please! Regards, Bert Haverkamp On Mon, Sep 28, 2009 at 1:29 PM, Bert Haverkamp wrote: > Hello, > > Sorry for the repeat, but I didn't see any response yet. > Damien, could you maybe let us know the status? > You were the one reacting to Miklos patches. (positively, it seemed) > What are your plans with it? > > Regards, > > Bert Haverkamp > > On Sun, Sep 20, 2009 at 7:15 PM, Bert Haverkamp wrote: >> Dear all, >> >> I am looking for the status on the hardlink patches that were >> published on this list last february by Miklos Szeredi? >> I'd really like to have hardlink support in sftp. This would in turn >> enable hardlinks in sshfs and make incremental rsync backups to remote >> filesystems possible. >> >> can someone tell me if these patches will be incorporated in openssh? >> The patches can be found under >> https://bugzilla.mindrot.org/show_bug.cgi?id=1555 >> >> Regards, >> >> Bert Haverkamp >> >> -- >> ----------------------------------------------------- >> 38 is NOT a random number!!!! >> > > > > -- > ----------------------------------------------------- > 38 is NOT a random number!!!! > -- ----------------------------------------------------- 38 is NOT a random number!!!! From dtucker at zip.com.au Tue Oct 6 09:33:05 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 06 Oct 2009 09:33:05 +1100 Subject: Authenticating users from proprietary user databases In-Reply-To: References: <4ACA47AB.60900@zip.com.au> Message-ID: <4ACA7421.8070905@zip.com.au> Yaniv Aknin wrote: > Hrmf, how simple, I didn't think about patching getpwnam() et al > themselves, I was somehow locked on patching the nsswitch circuitry. > But in this case, why not use LD_PRELOAD and avoid the need to build my > own OpenSSH and have two different OpenSSH builds? Yeah that should work too. Personally I prefer that daemons don't change their behaviour if you happen to restart them without some environment variable, but it sounds like it would be fine for your appliance environment. -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From peter at stuge.se Tue Oct 6 11:21:34 2009 From: peter at stuge.se (Peter Stuge) Date: Tue, 6 Oct 2009 02:21:34 +0200 Subject: Hardlink patches for sftp In-Reply-To: <1e68a10b0910050749l43401f01rb385d072c56f284@mail.gmail.com> References: <1e68a10b0909201015kfe5a8bexe9ffd84791216ce1@mail.gmail.com> <1e68a10b0909280429s7ae24be0uf1e24d821f8f5b68@mail.gmail.com> <1e68a10b0910050749l43401f01rb385d072c56f284@mail.gmail.com> Message-ID: <20091006002134.24413.qmail@stuge.se> Bert, Bert Haverkamp wrote: > Sorry for the repeat again, No, I don't think so. You did send it after all. > but a week has gone by and I have not been able to find the > information. Then there is probably no information to find. > >> can someone tell me if these patches will be incorporated in > >> openssh? I guess noone can, since you haven't gotten a response. > >> The patches can be found under > >> https://bugzilla.mindrot.org/show_bug.cgi?id=1555 Since the bug has not been closed as invalid or similar dismissive status I would assume that there is a chance for patches to be incorporated. I don't know how or if you can help make it happen sooner rather than later somehow, but sending an email once a week is annoying at best and directly counterproductive at worst. Maybe you could provide more data. Testing, numbers on the optimizations, anything useful.. //Peter From yaniv at aknin.name Tue Oct 6 15:05:09 2009 From: yaniv at aknin.name (Yaniv Aknin) Date: Tue, 6 Oct 2009 06:05:09 +0200 Subject: Authenticating users from proprietary user databases In-Reply-To: <4ACA579B.2060203@iversen-net.dk> References: <4ACA579B.2060203@iversen-net.dk> Message-ID: Thank you very much for your prompt and interesting replies. To make sure I'm perfectly clear, I'd like complete separation between the "CLI" users and "maintenance" users. Not every CLI user is a maintenance user, nor is every maintenance user a CLI user. Maintenance users are regular Linux users (/etc/passwd) and CLI users are defined by the users of the appliance, who should be 100% abstracted from the fact this is actually a bunch of Linux boxes. I'd like the separation to be complete enough that it would be possible to create a user in the CLI called, say, "root", and have that user be completely unrelated to Linuxes /etc/passwd UID-0 user root we all know. Christian, from your suggestions, I'm indeed most interested in (3) and maybe (1b), but the issue which still remains is how to make the NSS plugin I'll use specific to the OpenSSH process (and its only child, the CLI executable), so that not all processes in my system would be affected by this change. From my cursory look at nss-extrausers, I can't see a way to limit it to a specific process, but please enlighten me if I'm wrong. I'm willing to go with "override getpwnam()" method suggested by Darren (either statically as Darren stated or indeed with LD_PRELOAD), but I'd be happy to hear another suggestion, if you have any. Thanks again, - Yaniv On Mon, Oct 5, 2009 at 10:31 PM, Christian Iversen wrote: > On 2009-10-05 20:27, Yaniv Aknin wrote: > >> Hi, >> >> I work for a company which develops a rather complicated Linux-based >> grid-technology appliance. The appliance is made of several Linux hosts, >> exposing its functionality over a proprietary CLI-like protocol. This >> protocol currently works by running a proprietary client executable on a >> host, sending the command via TCP/IP to one of the appliance's hosts and >> receiving the response. The client handles authentication, compression, >> etc. >> In addition, it is possible to access the various hosts of the clustered >> appliance as a regular Linux host using plain SSH for technician >> maintenance >> (not exposed to customers). >> >> I'm a big proponent of exposing our CLI over SSH as well and doing away >> with >> the proprietary "cli executable". Already the CLI executable can run >> inside >> the appliance itself, and I'd very much like it to be possible to run a >> single CLI command by running: >> $ ssh user at appliance command parameter=value >> ...and also to make it possible to run a readline based appliance-CLI >> interactive "shell" (we already have something like that) by running: >> $ ssh user at appliance >> >> We can easily separate (at least, at the transport layer) between the >> "maintenance" SSH shell and the "CLI" SSH shell by running two sshd >> instances and binding them to different ports (or addresses). >> > > Does this mean that you want every user to be able to log on in either > "CLI" or "maintenance" mode? Otherwise, just set the shell of the specific > users to the right shell. > > > The issue I'm not sure how to tackle is how to make SSH 'natively' >> authenticate the appliance's built-in users. Our appliance has its own >> user >> directory with credentials, unrelated to the passwd/shadow directory of >> nsswitch. The 'obvious' solution is to write an nsswitch module which will >> fake all users from the appliance's proprietary directory as passwd:shadow >> entries (we store the passwords in a way that is shadow compatible), and >> give all users a uniform passwd entry with only the username/shadow hash >> changing. This entry will have a fixed UID, GID, shell and homedir, and >> this >> fixed homedir will contain an authorized_keys file that will dynamically >> contain keys as set for our appliance's users (I'll add the CLI command >> "user_add_ssh_key" or something). >> >> While the above solution is, like I said, obvious, it has a very severe >> drawback I'm not sure how to tackle, and that's the fact that nsswitch >> modules are system global. I don't want our hosts' Linux users (root, >> nobody, daemon, etc) to collide with the appliance's users and vice versa, >> and I'd definitely not want to jeopardize the stability of core Linux >> services in any way by adding something as complex as looking up our >> clustered database for users from within all processes in the system. >> >> I'm not sure how to further handle this. Should I patch OpenSSH itself (oh >> god, please, no...)? Should I use some dynamic LD_PRELOAD concoction to >> 'rewrite' nsswitch.conf only for this sshd instance? Should I give up on >> OpenSSH entirely and use an SSH implementation which is less focused on >> letting system-users run shell-commands (like twisted.conch, or maybe >> others)? All these options are... well, doable, but all seem like a lot of >> (fragile) work. I'd appreciate comments and ideas. >> > > I have worked with authentication solutions before (specifically with NSS), > and as far as I can see, you have a few options. I'll let you decide which > one suit your needs better, if any: > > 1a) Make an NSS plugin > > (as you suggested) > > 1b) Make an NSS plugin with virtual usernames > > As 1a, but prefix all usernames with a common prefix, such as "cli_" > > That way, the names cannot clash. > > 2) Actually export CLI users into system users in passwd and shadow > > Doesn't seem very nice, but it could work > > 3) Use libnss-extrausers > > This existing plugin allows you to have an entirely seperate set of > passwd/group/shadow files, that are not related to the usual ones in /etc. > This way, you can safely make an export of all your users into the files in > /var/lib/extrausers, without risking anything. Worst case, only your CLI > users are affected by any problems. > > 4) Use a common database for all users > > If you can export your current users (and change your existing tools) to > use something like PostgreSQL or LDAP for storing users, you'd be able to > use existing NSS plugins to connect to them. > > Out of these options, I'd recommend that you look at number 3, since it's > so dead simple to use, while still (I believe) solving your problem. > > -- > Med venlig hilsen > Christian Iversen > From djm at mindrot.org Tue Oct 6 16:25:08 2009 From: djm at mindrot.org (Damien Miller) Date: Tue, 6 Oct 2009 15:25:08 +1000 (EST) Subject: Hardlink patches for sftp In-Reply-To: <1e68a10b0910050749l43401f01rb385d072c56f284@mail.gmail.com> References: <1e68a10b0909201015kfe5a8bexe9ffd84791216ce1@mail.gmail.com> <1e68a10b0909280429s7ae24be0uf1e24d821f8f5b68@mail.gmail.com> <1e68a10b0910050749l43401f01rb385d072c56f284@mail.gmail.com> Message-ID: We'll get to the bug when we get to it, hopefully in time for openssh-5.4. You can add yourself as a Cc on the bug to watch progress on it or, if you are really interested, you can subscribe to openssh-bugs and watch us work through the backlog of bugs before this one. -d On Mon, 5 Oct 2009, Bert Haverkamp wrote: > Sorry for the repeat again, but a week has gone by and I have not been > able to find the information. > Anyone please! > > Regards, > > Bert Haverkamp > > > On Mon, Sep 28, 2009 at 1:29 PM, Bert Haverkamp wrote: > > Hello, > > > > Sorry for the repeat, but I didn't see any response yet. > > Damien, could you maybe let us know the status? > > You were the one reacting to Miklos patches. (positively, it seemed) > > What are your plans with it? > > > > Regards, > > > > Bert Haverkamp > > > > On Sun, Sep 20, 2009 at 7:15 PM, Bert Haverkamp wrote: > >> Dear all, > >> > >> I am looking for the status on the hardlink patches that were > >> published on this list last february by Miklos Szeredi? > >> I'd really like to have hardlink support in sftp. This would in turn > >> enable hardlinks in sshfs and make incremental rsync backups to remote > >> filesystems possible. > >> > >> can someone tell me if these patches will be incorporated in openssh? > >> The patches can be found under > >> https://bugzilla.mindrot.org/show_bug.cgi?id=1555 > >> > >> Regards, > >> > >> Bert Haverkamp > >> > >> -- > >> ----------------------------------------------------- > >> 38 is NOT a random number!!!! > >> > > > > > > > > -- > > ----------------------------------------------------- > > 38 is NOT a random number!!!! > > > > > > -- > ----------------------------------------------------- > 38 is NOT a random number!!!! > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From peter at stuge.se Tue Oct 6 16:36:01 2009 From: peter at stuge.se (Peter Stuge) Date: Tue, 6 Oct 2009 07:36:01 +0200 Subject: Authenticating users from proprietary user databases In-Reply-To: References: <4ACA579B.2060203@iversen-net.dk> Message-ID: <20091006053601.10231.qmail@stuge.se> Yaniv Aknin wrote: > I'd like the separation to be complete enough that it would be > possible to create a user in the CLI called, say, "root", and have > that user be completely unrelated to Linuxes /etc/passwd UID-0 user > root we all know. You want a new namespace so you can not use nss. And you will need one sshd for each namespace. > I'm willing to go with "override getpwnam()" method suggested by > Darren I think it's the easiest way. //Peter From christian.pfaffel-janser at siemens.com Tue Oct 6 23:10:46 2009 From: christian.pfaffel-janser at siemens.com (Christian Pfaffel-Janser) Date: Tue, 06 Oct 2009 14:10:46 +0200 Subject: Authenticating users from proprietary user databases In-Reply-To: References: <4ACA579B.2060203@iversen-net.dk> Message-ID: <4ACB33C6.1080301@siemens.com> Yaniv Aknin wrote: > Thank you very much for your prompt and interesting replies. > > To make sure I'm perfectly clear, I'd like complete separation between the > "CLI" users and "maintenance" users. Not every CLI user is a maintenance > user, nor is every maintenance user a CLI user. Maintenance users are > regular Linux users (/etc/passwd) and CLI users are defined by the users of > the appliance, who should be 100% abstracted from the fact this is actually > a bunch of Linux boxes. I'd like the separation to be complete enough that > it would be possible to create a user in the CLI called, say, "root", and > have that user be completely unrelated to Linuxes /etc/passwd UID-0 user > root we all know. > > Christian, from your suggestions, I'm indeed most interested in (3) and > maybe (1b), but the issue which still remains is how to make the NSS plugin > I'll use specific to the OpenSSH process (and its only child, the CLI > executable), so that not all processes in my system would be affected by > this change. From my cursory look at nss-extrausers, I can't see a way to > limit it to a specific process, but please enlighten me if I'm wrong. > > I'm willing to go with "override getpwnam()" method suggested by Darren > (either statically as Darren stated or indeed with LD_PRELOAD), but I'd be > happy to hear another suggestion, if you have any. > Hi Yaniv, how about using the PAM stack to do the work for You? You get all the flexibility You need. Regards, Christian -- From yaniv at aknin.name Tue Oct 6 23:16:10 2009 From: yaniv at aknin.name (Yaniv Aknin) Date: Tue, 6 Oct 2009 14:16:10 +0200 Subject: Authenticating users from proprietary user databases In-Reply-To: <4ACB33C6.1080301@siemens.com> References: <4ACA579B.2060203@iversen-net.dk> <4ACB33C6.1080301@siemens.com> Message-ID: Uhm, I'm not sure how that would work. I think because my users don't "exist" in the sense the getpwnam et al won't work on them, I must either override getpwnam or write an NSS module. Otherwise, how would sshd know (for example) what's the UID of user foo when foo tries to log in? (same goes for homedir, gid, etc). Anyway, I'm already doing pretty well with LD_PRELOAD, I think I'll have a working solution rather soon, and it wasn't even half as hard as I feared, too. - Yaniv On Tue, Oct 6, 2009 at 2:10 PM, Christian Pfaffel-Janser < christian.pfaffel-janser at siemens.com> wrote: > Yaniv Aknin wrote: > > > Thank you very much for your prompt and interesting replies. > > > > To make sure I'm perfectly clear, I'd like complete separation between > the > > "CLI" users and "maintenance" users. Not every CLI user is a maintenance > > user, nor is every maintenance user a CLI user. Maintenance users are > > regular Linux users (/etc/passwd) and CLI users are defined by the users > of > > the appliance, who should be 100% abstracted from the fact this is > actually > > a bunch of Linux boxes. I'd like the separation to be complete enough > that > > it would be possible to create a user in the CLI called, say, "root", and > > have that user be completely unrelated to Linuxes /etc/passwd UID-0 user > > root we all know. > > > > Christian, from your suggestions, I'm indeed most interested in (3) and > > maybe (1b), but the issue which still remains is how to make the NSS > plugin > > I'll use specific to the OpenSSH process (and its only child, the CLI > > executable), so that not all processes in my system would be affected by > > this change. From my cursory look at nss-extrausers, I can't see a way to > > limit it to a specific process, but please enlighten me if I'm wrong. > > > > I'm willing to go with "override getpwnam()" method suggested by Darren > > (either statically as Darren stated or indeed with LD_PRELOAD), but I'd > be > > happy to hear another suggestion, if you have any. > > > > Hi Yaniv, > > how about using the PAM stack to do the work for You? You get all the > flexibility You need. > > Regards, > Christian > > -- > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From rees at umich.edu Thu Oct 15 04:30:54 2009 From: rees at umich.edu (Jim Rees) Date: Wed, 14 Oct 2009 13:30:54 -0400 Subject: getaddrinfo() and SRV records Message-ID: <20091014173054.GA21020@merit.edu> Ssh calls getaddrinfo() to get the server address when it makes a connection, but ignores the port, which I think is bad. Instead it calls getservbyname(), which is redundant, as getaddrinfo() normally does that for you. Among other things, this makes it impossible to use SRV records (rfc2782) on the server end to point the client at a different port. Yes, I know that getaddrinfo() does not use SRV records in the default linux implementation. But that's no reason to ignore the port. I have attached a patch for your consideration. I am not advocating that this be committed as-is, just submitting it for discussion. Does this seem like a good idea? Bad idea? Good idea poorly implemented? -------------- next part -------------- A non-text attachment was scrubbed... Name: openssh-5.3p1-getaddrinfo.patch Type: text/x-diff Size: 2278 bytes Desc: not available URL: From scott_n at xypro.com Sat Oct 17 10:40:18 2009 From: scott_n at xypro.com (Scott Neugroschl) Date: Fri, 16 Oct 2009 16:40:18 -0700 Subject: AES CTR mode Message-ID: <78DD71C304F38B41885A242996B96F7301F85E49@xyservd.XYPRO-23.LOCAL> I'm looking at replacing some algorithms with different implementations, and I'm having some problems with the AES CTR mode algorithms. I can see where encryption is done, but I can't figure out where decryption occurs. I'm looking at cipher-ctr.c ---- Scott Neugroschl XYPRO Technology Corporation scott_n at xypro.com 805-583-2874 From bitpoet at linux-config.de Sat Oct 17 17:50:43 2009 From: bitpoet at linux-config.de (Christian Winter) Date: Sat, 17 Oct 2009 08:50:43 +0200 Subject: Authenticating users from proprietary user databases In-Reply-To: References: <4ACA579B.2060203@iversen-net.dk> <4ACB33C6.1080301@siemens.com> Message-ID: <4AD96943.6050300@linux-config.de> Yaniv Aknin wrote: [using pam to authenticate 'virtual' users] > Uhm, I'm not sure how that would work. I think because my users don't > "exist" in the sense the getpwnam et al won't work on them, I must either > override getpwnam or write an NSS module. Otherwise, how would sshd know > (for example) what's the UID of user foo when foo tries to log in? (same > goes for homedir, gid, etc). > > Anyway, I'm already doing pretty well with LD_PRELOAD, I think I'll have a > working solution rather soon, and it wasn't even half as hard as I feared, > too. > I just want to point out that something similar to your problem has already been approached using pam and its possiblity to override PAM_USER and map it to another built-in account, so maybe you can find something helpful there: https://bugzilla.mindrot.org/show_bug.cgi?id=1215 -Chris From jmwoo2 at yahoo.com Sun Oct 18 19:07:02 2009 From: jmwoo2 at yahoo.com (John W) Date: Sun, 18 Oct 2009 01:07:02 -0700 (PDT) Subject: OpenSSH client for non-jailbroken iPhone Message-ID: <341580.80896.qm@web56006.mail.re3.yahoo.com> Hello, I was wondering if there are any legal problems with porting the OpenSSH client code to the iPhone, and then distributing the app on the Apple iPhone App store for free. Since it's open source, I don't think I would charge anything for it. (On second thought, I would accept donations solely to pay for my apple developer license). I was just considering doing this since there currently is not a free version of a SSH client for non-jailbroken phones. Any thoughts? Thanks, John From dan at doxpara.com Sun Oct 18 20:09:19 2009 From: dan at doxpara.com (Dan Kaminsky) Date: Sun, 18 Oct 2009 05:09:19 -0400 Subject: OpenSSH client for non-jailbroken iPhone In-Reply-To: <341580.80896.qm@web56006.mail.re3.yahoo.com> References: <341580.80896.qm@web56006.mail.re3.yahoo.com> Message-ID: No legal issues, given the BSD license, but there *are* SSH clients for the iPhone. Note that you have to port both SSH and a VT100 client, which is more than a bit of work. On Sun, Oct 18, 2009 at 4:07 AM, John W wrote: > Hello, > > I was wondering if there are any legal problems with porting the OpenSSH > client code to the iPhone, and then distributing the app on the Apple iPhone > App store for free. Since it's open source, I don't think I would charge > anything for it. (On second thought, I would accept donations solely to pay > for my apple developer license). I was just considering doing this since > there currently is not a free version of a SSH client for non-jailbroken > phones. Any thoughts? > > Thanks, > > John > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From Dave at Yost.com Mon Oct 19 11:58:55 2009 From: Dave at Yost.com (Dave Yost) Date: Sun, 18 Oct 2009 17:58:55 -0700 Subject: there should be an authorized_keys(5) man page In-Reply-To: <20090617203812.GA29390@linux55.nas.nasa.gov> References: <20090617203812.GA29390@linux55.nas.nasa.gov> Message-ID: This is still a good idea... and known_hosts, too. Dave At 1:38 PM -0700 2009-06-17, Iain Morgan wrote: >On Tue, Jun 16, 2009 at 17:32:59 -0500, Dave Yost wrote: >> Hi. >> >> On >> http://openssh.org/manual.html >> I think there should be >> authorized_keys(5) >> known_hosts(5) > >I agree that an authorized_keys(5) man page would be nice. I was going >to file it as an enhancement request and then got distracted. > >> >> Can an authorized_keys entry say something like >> >> from=192.168.1.32,192.168.1.33 command=/bin/foo ... > >Your almost have the right syntax: > >from="192.168.1.32,192.168.1.33",command="/bin/foo" ... > >> >> or do I need to make a separate entry for each IP address? >> >> Thanks >> >> Dave > >-- >Iain Morgan From c.baumann at ppc-ag.de Mon Oct 19 23:20:42 2009 From: c.baumann at ppc-ag.de (Christoph Baumann) Date: Mon, 19 Oct 2009 14:20:42 +0200 Subject: Problems porting to an ARM platform Message-ID: <4ADC599A.5020309@ppc-ag.de> Hello, currently I'm working on getting ssh and sshd running on an ARM platform. The OS is Linux 2.6.10 with busybox. I can run "ssh -v" to see the program version. But as soon as I try to connect to a server I get a segmentation fault (SIGSEGV). The sshd seems to work. Are there any known issues concerning ARM platforms? Or any hints about compiler options (GCC)? Regards, Christoph Baumann -- Dipl.-Phys. Christoph Baumann Power PLUS Communications AG Am Exerzierplatz 2 68167 Mannheim Germany phone: +49(621)40165-??? fax: +49(621)40165-??? mailto://c.baumann at ppc-ag.de http://www.ppc-ag.de Handelsregister-Nr.: HRB 8853 Sitz und Registergericht: Mannheim Vorstand: Ingo Sch?nberg (Vorsitzender), Eugen Mayer Vorsitzender des Aufsichtsrates Univ.-Prof. Dr. Torsten Gerpott From dtucker at zip.com.au Mon Oct 19 23:29:05 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Mon, 19 Oct 2009 23:29:05 +1100 Subject: Problems porting to an ARM platform In-Reply-To: <4ADC599A.5020309@ppc-ag.de> References: <4ADC599A.5020309@ppc-ag.de> Message-ID: <4ADC5B91.1060306@zip.com.au> Christoph Baumann wrote: > Hello, > > currently I'm working on getting ssh and sshd running on an ARM > platform. The OS is Linux 2.6.10 with busybox. > I can run "ssh -v" to see the program version. But as soon as I try to > connect to a server I get a segmentation fault (SIGSEGV). The sshd seems > to work. Are there any known issues concerning ARM platforms? None that I'm aware of. > Or any hints about compiler options (GCC)? What point in the connection does it crash at? ("ssh -vvv server"). Can you run it under a debugger? If so what does the backtrace say? The first thing I'd check is that OpenSSL passes its self-test "make tests" and/or compile it without assembler optimizations (./Configure no-asm). Failing that, I'd compile OpenSSL, zlib and OpenSSH without compiler optimizations (gcc -O0). -- 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 adrya1984 at gmail.com Mon Oct 19 23:31:39 2009 From: adrya1984 at gmail.com (Adriana Rodean) Date: Mon, 19 Oct 2009 15:31:39 +0300 Subject: remote port forwarding unstable Message-ID: <496c8fcc0910190531p4d02db92maa3a1d9642402122@mail.gmail.com> Hi, I'm not sure if this is a bug or not, maybe someone noticed it also... I always do a remote port forwarding with openssh on 1026 port let's say ( ssh -R 1026:localhost:55555 ). Most times the port is opened on remote machine. But sometimes i notice that ssh can't do remote port forwarding to that port 1026. I looked on the remote machine (netstat -an) and no one is using that port, so the port is free. Only way to fix this is do a remote port forwarding to another port lets say 1056, successfully done, then try again and do it for 1026, this time remote port forwarding successfully works... Sometimes it works if i try again with 1026, but other times i need to open another port then try again with 1026 port... What can cause this instability to remote port forwarding? Is there another command than "netstat -an" to see if that port is really free or something is using it? If is a bug can it be fixed? I use version of OpenSSH 5.1p1 on remote machine and the client is OpenSSH for Windows 3.8.1p1 Thanks in advance, Adriana From c.baumann at ppc-ag.de Mon Oct 19 23:44:27 2009 From: c.baumann at ppc-ag.de (Christoph Baumann) Date: Mon, 19 Oct 2009 14:44:27 +0200 Subject: Problems porting to an ARM platform In-Reply-To: <4ADC5B91.1060306@zip.com.au> References: <4ADC599A.5020309@ppc-ag.de> <4ADC5B91.1060306@zip.com.au> Message-ID: <4ADC5F2B.1020506@ppc-ag.de> On 19.10.2009 14:29, Darren Tucker wrote: > What point in the connection does it crash at? ("ssh -vvv server"). Can > you run it under a debugger? If so what does the backtrace say? " $ ssh -vvv 192.168.2.10 OpenSSH_4.3p2, OpenSSL 0.9.7j-dev XX xxx XXXX SIGSEGV " I also tried the latest version of SSH with the same results. > The first thing I'd check is that OpenSSL passes its self-test "make > tests" and/or compile it without assembler optimizations (./Configure > no-asm). Failing that, I'd compile OpenSSL, zlib and OpenSSH without > compiler optimizations (gcc -O0). Well maybe it's OpenSSL. In all cases I used the same (binary) version of it. -- Dipl.-Phys. Christoph Baumann Power PLUS Communications AG Am Exerzierplatz 2 68167 Mannheim Germany phone: +49(621)40165-??? fax: +49(621)40165-??? mailto://c.baumann at ppc-ag.de http://www.ppc-ag.de Handelsregister-Nr.: HRB 8853 Sitz und Registergericht: Mannheim Vorstand: Ingo Sch?nberg (Vorsitzender), Eugen Mayer Vorsitzender des Aufsichtsrates Univ.-Prof. Dr. Torsten Gerpott From c.baumann at ppc-ag.de Tue Oct 20 01:40:04 2009 From: c.baumann at ppc-ag.de (Christoph Baumann) Date: Mon, 19 Oct 2009 16:40:04 +0200 Subject: Problems compiling against OpenSSL-0.9.8k Message-ID: <4ADC7A44.6030601@ppc-ag.de> Hello, after upgrading the OpenSSL version from 0.9.7j to 0.9.8k which I used to compile OpenSSH-5.2, I get conflicting type definitions for authfile.c: ../openssl/include/openssl/sha.h:138: error: conflicting types for 'SHA256_CTX' openbsd-compat/sha2.h:66: error: previous declaration of 'SHA256_CTX' was here ../openssl/include/openssl/sha.h:145: error: conflicting types for 'SHA256_Init' openbsd-compat/sha2.h:77: error: previous declaration of 'SHA256_Init' was here ../openssl/include/openssl/sha.h:145: error: conflicting types for 'SHA256_Init' openbsd-compat/sha2.h:77: error: previous declaration of 'SHA256_Init' was here ../openssl/include/openssl/sha.h:146: error: conflicting types for 'SHA256_Update' openbsd-compat/sha2.h:80: error: previous declaration of 'SHA256_Update' was here ../openssl/include/openssl/sha.h:146: error: conflicting types for 'SHA256_Update' openbsd-compat/sha2.h:80: error: previous declaration of 'SHA256_Update' was here ../openssl/include/openssl/sha.h:147: error: conflicting types for 'SHA256_Final' openbsd-compat/sha2.h:83: error: previous declaration of 'SHA256_Final' was here ../openssl/include/openssl/sha.h:147: error: conflicting types for 'SHA256_Final' openbsd-compat/sha2.h:83: error: previous declaration of 'SHA256_Final' was here ../openssl/include/openssl/sha.h:149: error: conflicting types for 'SHA256_Transform' openbsd-compat/sha2.h:78: error: previous declaration of 'SHA256_Transform' was here ../openssl/include/openssl/sha.h:149: error: conflicting types for 'SHA256_Transform' openbsd-compat/sha2.h:78: error: previous declaration of 'SHA256_Transform' was here ../openssl/include/openssl/sha.h:184: error: conflicting types for 'SHA512_CTX' openbsd-compat/sha2.h:71: error: previous declaration of 'SHA512_CTX' was here ../openssl/include/openssl/sha.h:192: error: conflicting types for 'SHA512_Init' openbsd-compat/sha2.h:113: error: previous declaration of 'SHA512_Init' was here ../openssl/include/openssl/sha.h:192: error: conflicting types for 'SHA512_Init' openbsd-compat/sha2.h:113: error: previous declaration of 'SHA512_Init' was here ../openssl/include/openssl/sha.h:193: error: conflicting types for 'SHA512_Update' openbsd-compat/sha2.h:116: error: previous declaration of 'SHA512_Update' was here ../openssl/include/openssl/sha.h:193: error: conflicting types for 'SHA512_Update' openbsd-compat/sha2.h:116: error: previous declaration of 'SHA512_Update' was here ../openssl/include/openssl/sha.h:194: error: conflicting types for 'SHA512_Final' openbsd-compat/sha2.h:119: error: previous declaration of 'SHA512_Final' was here ../openssl/include/openssl/sha.h:194: error: conflicting types for 'SHA512_Final' openbsd-compat/sha2.h:119: error: previous declaration of 'SHA512_Final' was here ../openssl/include/openssl/sha.h:196: error: conflicting types for 'SHA512_Transform' openbsd-compat/sha2.h:114: error: previous declaration of 'SHA512_Transform' was here ../openssl/include/openssl/sha.h:196: error: conflicting types for 'SHA512_Transform' openbsd-compat/sha2.h:114: error: previous declaration of 'SHA512_Transform' was here Setting -DOPENSSL_NO_SHA512 -DOPENSSL_NO_SHA256 reduces the number of errors to one complaining about SHA256_CTX. Regards, Christoph Baumann -- Dipl.-Phys. Christoph Baumann Power PLUS Communications AG Am Exerzierplatz 2 68167 Mannheim Germany phone: +49(621)40165-??? fax: +49(621)40165-??? mailto://c.baumann at ppc-ag.de http://www.ppc-ag.de Handelsregister-Nr.: HRB 8853 Sitz und Registergericht: Mannheim Vorstand: Ingo Sch?nberg (Vorsitzender), Eugen Mayer Vorsitzender des Aufsichtsrates Univ.-Prof. Dr. Torsten Gerpott THE INFORMATION CONTAINED IN THIS ELECTRONIC MAIL TRANSMISSION IS CONFIDENTIAL AND MAY ALSO CONTAIN PRIVILEGED INFORMATION OR WORK PRODUCT. THE INFORMATION IS INTENDED ONLY FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHOM IT IS ADDRESSED. IF YOU ARE NOT THE INTENDED RECIPIENT, YOU ARE HEREBY NOTIFIED THAT ANY USE, DISSEMINATION, DISTRIBUTION OR COPYING OF THIS COMMUNICATION IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS ELECTRONIC MAIL TRANSMISSION IN ERROR, PLEASE IMMEDIATELY ERASE AND DELETE THE ORIGINAL MESSAGE FROM YOUR DATABASE From plambrechtsen at gmail.com Tue Oct 20 04:52:58 2009 From: plambrechtsen at gmail.com (Peter Lambrechtsen) Date: Tue, 20 Oct 2009 06:52:58 +1300 Subject: remote port forwarding unstable In-Reply-To: <496c8fcc0910190531p4d02db92maa3a1d9642402122@mail.gmail.com> References: <496c8fcc0910190531p4d02db92maa3a1d9642402122@mail.gmail.com> Message-ID: <805A7DF6-89CC-48D9-AFE5-457A916964D6@gmail.com> Perhaps it is something wrong with your ssh client. I have had remote ssh port forwarding sessions open for weeks and in frequent use when using putty on the client and openssh 5.1 on the server. I have also had remote upon remote sessions going, which works, albiet a little slowly. IE Session1 client -> server1 -ssh -R 1080:server2:1080 -> server2 And Session2 client -putty remote port forwarding 1080 on server1 This allows me to access a web mgmt port for an app on server 2 which is sitting behind two firewalls that do not allowed to have web traffic in there. Very round about way of doing things. But it works Thanks Peter On 20/10/2009, at 1:31 AM, Adriana Rodean wrote: > Hi, > > I'm not sure if this is a bug or not, maybe someone noticed it also... > > I always do a remote port forwarding with openssh on 1026 port let's > say ( ssh -R 1026:localhost:55555 ). Most times the port is opened on > remote machine. But sometimes i notice that ssh can't do remote port > forwarding to that port 1026. I looked on the remote machine (netstat > -an) and no one is using that port, so the port is free. > Only way to fix this is do a remote port forwarding to another port > lets say 1056, successfully done, then try again and do it for 1026, > this time remote port forwarding successfully works... Sometimes it > works if i try again with 1026, but other times i need to open another > port then try again with 1026 port... > > What can cause this instability to remote port forwarding? > Is there another command than "netstat -an" to see if that port is > really free or something is using it? > If is a bug can it be fixed? > > I use version of OpenSSH 5.1p1 on remote machine and the client is > OpenSSH for Windows 3.8.1p1 > > Thanks in advance, > Adriana > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From dtucker at zip.com.au Tue Oct 20 06:20:55 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 20 Oct 2009 06:20:55 +1100 Subject: Problems compiling against OpenSSL-0.9.8k In-Reply-To: <4ADC7A44.6030601@ppc-ag.de> References: <4ADC7A44.6030601@ppc-ag.de> Message-ID: <4ADCBC17.9050205@zip.com.au> Christoph Baumann wrote: > Hello, > > after upgrading the OpenSSL version from 0.9.7j to 0.9.8k which I used > to compile OpenSSH-5.2, I get conflicting type definitions for authfile.c: > ../openssl/include/openssl/sha.h:138: error: conflicting types for > 'SHA256_CTX' > openbsd-compat/sha2.h:66: error: previous declaration of 'SHA256_CTX' > was here > ../openssl/include/openssl/sha.h:145: error: conflicting types for > 'SHA256_Init' You've got a "config.h" with the old settings somewhere in your compiler's search path. You probably just need to do a "make distclean" (or delete the openssh directory and unpack the tarball again) and then rerun configure. -- 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 adrya1984 at gmail.com Tue Oct 20 16:53:49 2009 From: adrya1984 at gmail.com (Adriana Rodean) Date: Tue, 20 Oct 2009 08:53:49 +0300 Subject: remote port forwarding unstable In-Reply-To: <1f3854d50910191138l2000ca9v8f070d98ef6fefc6@mail.gmail.com> References: <496c8fcc0910190531p4d02db92maa3a1d9642402122@mail.gmail.com> <1f3854d50910191138l2000ca9v8f070d98ef6fefc6@mail.gmail.com> Message-ID: <496c8fcc0910192253o712607f8x29f8cf970d2df4d7@mail.gmail.com> Hi, Here is some more info after little investigation :) Message i get is: "Warning: remote port forwarding failed for listen port 1026" SSH makes connection but port isn't opened and in server logs i see: IPP-Linux:~# cat /var/log/auth.log | grep 18722 Oct 19 13:37:20 IPP-Linux sshd[18722]: error: bind: Address already in use Oct 19 13:37:20 IPP-Linux sshd[18722]: error: channel_setup_fwd_listener: cannot listen to port: 1026 IPP-Linux:~# cat /var/log/auth.log | grep 18737 Oct 19 13:37:47 IPP-Linux sshd[18737]: error: bind: Address already in use Oct 19 13:37:47 IPP-Linux sshd[18737]: error: channel_setup_fwd_listener: cannot listen to port: 1026 But i closed the previous console with ssh listening to that port, and is no ssh process on client when i want to connect again on the same port. So how come it still says that port is in use on server? This happens in only 2% of the cases, very rare, i change nothing in the way i connect or close the client, but somehow it seems that port still hangs on server after closing ssh console ... or at least that's what sshd says because with "netstat -an" i don't see that port busy Thank you Rabbi for that command, next time when it happens i'll use it :) Thanks, Adriana From rees at umich.edu Tue Oct 20 23:12:39 2009 From: rees at umich.edu (Jim Rees) Date: Tue, 20 Oct 2009 08:12:39 -0400 Subject: remote port forwarding unstable In-Reply-To: <496c8fcc0910192253o712607f8x29f8cf970d2df4d7@mail.gmail.com> References: <496c8fcc0910190531p4d02db92maa3a1d9642402122@mail.gmail.com> <1f3854d50910191138l2000ca9v8f070d98ef6fefc6@mail.gmail.com> <496c8fcc0910192253o712607f8x29f8cf970d2df4d7@mail.gmail.com> Message-ID: <20091020121239.GB11536@merit.edu> Are you sure the connection is fully closed? When you close a tcp connection, it stays in time_wait and fin_wait for a while, during which time the port can't be reused. You said netstat doesn't show anything on that port? From wooledg at eeg.ccf.org Wed Oct 21 04:15:08 2009 From: wooledg at eeg.ccf.org (Greg Wooledge) Date: Tue, 20 Oct 2009 13:15:08 -0400 Subject: remote port forwarding unstable In-Reply-To: <496c8fcc0910192253o712607f8x29f8cf970d2df4d7@mail.gmail.com> References: <496c8fcc0910190531p4d02db92maa3a1d9642402122@mail.gmail.com> <1f3854d50910191138l2000ca9v8f070d98ef6fefc6@mail.gmail.com> <496c8fcc0910192253o712607f8x29f8cf970d2df4d7@mail.gmail.com> Message-ID: <20091020171508.GH1486@eeg.ccf.org> On Tue, Oct 20, 2009 at 08:53:49AM +0300, Adriana Rodean wrote: > IPP-Linux:~# cat /var/log/auth.log | grep 18737 > Oct 19 13:37:47 IPP-Linux sshd[18737]: error: bind: Address already in use > Oct 19 13:37:47 IPP-Linux sshd[18737]: error: > channel_setup_fwd_listener: cannot listen to port: 1026 > > But i closed the previous console with ssh listening to that port, and > is no ssh process on client when i want to connect again on the same > port. So how come it still says that port is in use on server? Use "lsof -i :1026" (lsof is not standard, but it's very common) or "netstat -antp | grep :1026" (netstat -p is Linux only) to see what is listening on port 1026. From bert.wesarg at googlemail.com Wed Oct 21 06:43:03 2009 From: bert.wesarg at googlemail.com (Bert Wesarg) Date: Tue, 20 Oct 2009 21:43:03 +0200 Subject: Integration of streamlocal patch In-Reply-To: <1285cde60909060853l536afd1h560871e0a6cd617b@mail.gmail.com> References: <1285cde60909030103p68dacb2bl62998590d8f806ab@mail.gmail.com> <1285cde60909060853l536afd1h560871e0a6cd617b@mail.gmail.com> Message-ID: <36ca99e90910201243p446a4b6fqef89e48dc8f6ec8@mail.gmail.com> On Sun, Sep 6, 2009 at 17:53, lauri wrote: > Hello, Hello, > http://v6sa.itcollege.ee/shared/patches/openssh-4.7p1-streamlocal-20090831-v6sa-for-ubuntu-8.04.patch I just found a vary old bug in this patch (since original version): In the keywords array from readconf.c for the "controlallowgroups" entry there is the wrong enum assigned, namely oControlAllowUsers not oControlAllowGroups. Regards, Bert From adrya1984 at gmail.com Wed Oct 21 17:16:19 2009 From: adrya1984 at gmail.com (Adriana Rodean) Date: Wed, 21 Oct 2009 09:16:19 +0300 Subject: remote port forwarding unstable In-Reply-To: <02E1B8EE8977724CA107E006B690CF7F181E7B32C4@VFIWVEXMB3.verifone.com> References: <496c8fcc0910190531p4d02db92maa3a1d9642402122@mail.gmail.com> <1f3854d50910191138l2000ca9v8f070d98ef6fefc6@mail.gmail.com> <496c8fcc0910192253o712607f8x29f8cf970d2df4d7@mail.gmail.com> <02E1B8EE8977724CA107E006B690CF7F181E7B32C4@VFIWVEXMB3.verifone.com> Message-ID: <496c8fcc0910202316l691fb521w8b4bca367ee02567@mail.gmail.com> Thank you all for your replies :) This is the command i use: ssh -L 30300:localhost:8080 -R 1026:localhost:55555 -F ssh_config -N ipp at 10.55.40.120 And i close the ssh process by closing the windows console, or by killing the ssh process from another application. Either way when i look in processes list after closing ssh process is gone when i try to reconnect again. I guess that's the explanation suggested above why sometimes it doesn't allow me to reconnect with same port, TCP connection staying in a wait state even after previous ssh client process terminates and it keeps that remote port busy. Maybe that's why it didn't showed with "netstat -an" command. Next time i will use the other commands suggested :) Thank you again, Adriana From ari.hyttinen at gmail.com Wed Oct 21 19:01:34 2009 From: ari.hyttinen at gmail.com (Ari Hyttinen) Date: Wed, 21 Oct 2009 11:01:34 +0300 Subject: Patch to fix dynamic -R forwarding when not root Message-ID: <50b039e60910210101u339281dci6b5b2cd1a5fe630@mail.gmail.com> Hi! Sorry if this has already been reported or even fixed, I didn't search very thoroughly. Here's a patch to make dynamic -R remote port allocation work even when not connecting as root. Without the patch I got that "Server has disabled port forwarding." message visible in the patch. OpenSSH version I'm using is openssh-5.2p1, compiled from official source package, configured without any configure options, on Ubuntu Linux platform. PS. If this patch isn't necessary, and I did something else wrong when trying to 'ssh -R 0:localhost:22 user at remote', please let me know! --- serverloop.c.original 2009-10-21 10:45:13.000000000 +0300 +++ serverloop.c 2009-10-21 10:53:09.000000000 +0300 @@ -1119,9 +1119,9 @@ if (!options.allow_tcp_forwarding || no_port_forwarding_flag || (!want_reply && listen_port == 0) #ifndef NO_IPPORT_RESERVED_CONCEPT - || (listen_port < IPPORT_RESERVED && pw->pw_uid != 0) + || (listen_port !=0 && listen_port < IPPORT_RESERVED && pw->pw_uid != 0) #endif ) { success = 0; packet_send_debug("Server has disabled port forwarding."); -- Ari Hyttinen From ari.hyttinen at gmail.com Wed Oct 21 19:34:17 2009 From: ari.hyttinen at gmail.com (Ari Hyttinen) Date: Wed, 21 Oct 2009 11:34:17 +0300 Subject: Patch to fix dynamic -R forwarding when not root In-Reply-To: <50b039e60910210101u339281dci6b5b2cd1a5fe630@mail.gmail.com> References: <50b039e60910210101u339281dci6b5b2cd1a5fe630@mail.gmail.com> Message-ID: <50b039e60910210134t3b360055uddbd22ce3057ffad@mail.gmail.com> And yes, it's indeed been fixed in 5.3p1. For some reason the mirror I got the "latest" source from didn't yet have 5.3. So just ignore this, sorry for the noise. 2009/10/21 Ari Hyttinen : > Hi! > > Sorry if this has already been reported or even fixed, I didn't search > very thoroughly. Here's a patch to make dynamic -R remote port > allocation work even when not connecting as root. Without the patch I > got that "Server has disabled port forwarding." message visible in the > patch. > > OpenSSH version I'm using is openssh-5.2p1, compiled from official > source package, configured without any configure options, on Ubuntu > Linux platform. > > PS. If this patch isn't necessary, and I did something else wrong when > trying to 'ssh -R 0:localhost:22 user at remote', please let me know! > > > --- serverloop.c.original ? ? ? 2009-10-21 10:45:13.000000000 +0300 > +++ serverloop.c ? ? ? ?2009-10-21 10:53:09.000000000 +0300 > @@ -1119,9 +1119,9 @@ > ? ? ? ? ? ? ? ?if (!options.allow_tcp_forwarding || > ? ? ? ? ? ? ? ? ? ?no_port_forwarding_flag || > ? ? ? ? ? ? ? ? ? ?(!want_reply && listen_port == 0) > ?#ifndef NO_IPPORT_RESERVED_CONCEPT > - ? ? ? ? ? ? ? ? ? || (listen_port < IPPORT_RESERVED && pw->pw_uid != 0) > + ? ? ? ? ? ? ? ? ? || (listen_port !=0 && listen_port < IPPORT_RESERVED && pw->pw_uid != 0) > ?#endif > ? ? ? ? ? ? ? ? ? ?) { > ? ? ? ? ? ? ? ? ? ? ? ?success = 0; > ? ? ? ? ? ? ? ? ? ? ? ?packet_send_debug("Server has disabled port forwarding."); > > > -- > Ari Hyttinen > From c.baumann at ppc-ag.de Wed Oct 21 20:55:58 2009 From: c.baumann at ppc-ag.de (Christoph Baumann) Date: Wed, 21 Oct 2009 11:55:58 +0200 Subject: Problems porting to an ARM platform In-Reply-To: <4ADC5B91.1060306@zip.com.au> References: <4ADC599A.5020309@ppc-ag.de> <4ADC5B91.1060306@zip.com.au> Message-ID: <4ADEDAAE.4070809@ppc-ag.de> On 19.10.2009 14:29, Darren Tucker wrote: > What point in the connection does it crash at? ("ssh -vvv server"). Can > you run it under a debugger? If so what does the backtrace say? I now compiled against OpenSSL 0.9.8k. This made the ssh client getting a bit further. $ ssh -vvv 192.168.2.10 OpenSSH_5.2p1, OpenSSL 0.9.8k 25 Mar 2009 debug1: Reading configuration data /etc/ssh/ssh_config debug1: Applying options for * /etc/ssh/ssh_config line 50: Unsupported option "GSSAPIAuthentication" /etc/ssh/ssh_config line 51: Unsupported option "GSSAPIDelegateCredentials" debug2: ssh_connect: needpriv 0 debug1: Connecting to 192.168.2.10 [192.168.2.10] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug1: identity file /root/.ssh/identity type -1 debug3: Not a RSA1 key file /root/.ssh/id_rsa. debug2: key_type_from_name: unknown key type '-----BEGIN' debug3: key_read: missing keytype debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug3: key_read: missing whitespace debug2: key_type_from_name: unknown key type '-----END' debug3: key_read: missing keytype debug1: identity file /root/.ssh/id_rsa type 1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.1p1 Debian-5ubuntu1 debug1: match: OpenSSH_5.1p1 Debian-5ubuntu1 pat OpenSSH* debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_5.2 debug2: fd 4 setting O_NONBLOCK debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,rijndael-cbc at lysator.liu.se,aes128-ctr,aes192-ctr,aes256-ctr debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: found hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_setup: found hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<1024<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: dh_gen_key: priv key bits set: 133/256 debug2: bits set: 514/1024 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug3: check_host_in_hostfile: filename /root/.ssh/known_hosts debug3: check_host_in_hostfile: match line 1 debug1: Host '192.168.2.10' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:1 debug2: bits set: 500/1024 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received SIGSEGV Regards Christoph Baumann -- Dipl.-Phys. Christoph Baumann Power PLUS Communications AG Am Exerzierplatz 2 68167 Mannheim Germany phone: +49(621)40165-??? fax: +49(621)40165-??? mailto://c.baumann at ppc-ag.de http://www.ppc-ag.de Handelsregister-Nr.: HRB 8853 Sitz und Registergericht: Mannheim Vorstand: Ingo Sch?nberg (Vorsitzender), Eugen Mayer Vorsitzender des Aufsichtsrates Univ.-Prof. Dr. Torsten Gerpott THE INFORMATION CONTAINED IN THIS ELECTRONIC MAIL TRANSMISSION IS CONFIDENTIAL AND MAY ALSO CONTAIN PRIVILEGED INFORMATION OR WORK PRODUCT. THE INFORMATION IS INTENDED ONLY FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHOM IT IS ADDRESSED. IF YOU ARE NOT THE INTENDED RECIPIENT, YOU ARE HEREBY NOTIFIED THAT ANY USE, DISSEMINATION, DISTRIBUTION OR COPYING OF THIS COMMUNICATION IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS ELECTRONIC MAIL TRANSMISSION IN ERROR, PLEASE IMMEDIATELY ERASE AND DELETE THE ORIGINAL MESSAGE FROM YOUR DATABASE From dtucker at zip.com.au Wed Oct 21 21:38:19 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 21 Oct 2009 21:38:19 +1100 Subject: Problems porting to an ARM platform In-Reply-To: <4ADEDAAE.4070809@ppc-ag.de> References: <4ADC599A.5020309@ppc-ag.de> <4ADC5B91.1060306@zip.com.au> <4ADEDAAE.4070809@ppc-ag.de> Message-ID: <4ADEE49B.6040609@zip.com.au> Christoph Baumann wrote: > On 19.10.2009 14:29, Darren Tucker wrote: >> What point in the connection does it crash at? ("ssh -vvv server"). Can >> you run it under a debugger? If so what does the backtrace say? > > I now compiled against OpenSSL 0.9.8k. This made the ssh client getting > a bit further. > > $ ssh -vvv 192.168.2.10 [...] > debug2: service_accept: ssh-userauth > debug1: SSH2_MSG_SERVICE_ACCEPT received > SIGSEGV It's not obvious where it's crashing, but the next step is authentication, and if you have any public keys it might be crashing trying to load them. How did you configure and compile OpenSSL? What compile options did you use? I'll ask the questions I asked previously that you haven't answered: - does openssl's "make test" pass? - can you run ssh under a debugger? if so what does the backtrace show? -- 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 c.baumann at ppc-ag.de Thu Oct 22 01:49:53 2009 From: c.baumann at ppc-ag.de (Christoph Baumann) Date: Wed, 21 Oct 2009 16:49:53 +0200 Subject: Problems porting to an ARM platform In-Reply-To: <4ADEE49B.6040609@zip.com.au> References: <4ADC599A.5020309@ppc-ag.de> <4ADC5B91.1060306@zip.com.au> <4ADEDAAE.4070809@ppc-ag.de> <4ADEE49B.6040609@zip.com.au> Message-ID: <4ADF1F91.6080803@ppc-ag.de> On 21.10.2009 12:38, Darren Tucker wrote: > It's not obvious where it's crashing, but the next step is > authentication, and if you have any public keys it might be crashing > trying to load them. This is odd, as sshd runs stable with public key authentication. > > How did you configure and compile OpenSSL? What compile options did you > use? My configuration/build script for OpenSSL looks like this: export CC=arm-uclinux-gcc export LD=arm-uclinux-ld make clean ./Configure linux-generic32 no-asm no-hw no-krb5 no-shared \ no-dso no-threads zlib -I../../../zlib -L../zlib \ -march=armv5 -msoft-float -mtune=arm926ejs -D_FILE_OFFSET_BITS=32 make -j2 build_libs The script for OpenSSH is attached. > I'll ask the questions I asked previously that you haven't answered: > - does openssl's "make test" pass? No. The test programs use the option "-ldl" to compile which is not supported by our embedded platform (only static executables). > - can you run ssh under a debugger? if so what does the backtrace show? Currently I don't have a gdb suitable for running on the target (it uses the bflt executable format). Regards Christoph Baumann -- Dipl.-Phys. Christoph Baumann Power PLUS Communications AG Am Exerzierplatz 2 68167 Mannheim Germany phone: +49(621)40165-??? fax: +49(621)40165-??? mailto://c.baumann at ppc-ag.de http://www.ppc-ag.de Handelsregister-Nr.: HRB 8853 Sitz und Registergericht: Mannheim Vorstand: Ingo Sch?nberg (Vorsitzender), Eugen Mayer Vorsitzender des Aufsichtsrates Univ.-Prof. Dr. Torsten Gerpott THE INFORMATION CONTAINED IN THIS ELECTRONIC MAIL TRANSMISSION IS CONFIDENTIAL AND MAY ALSO CONTAIN PRIVILEGED INFORMATION OR WORK PRODUCT. THE INFORMATION IS INTENDED ONLY FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHOM IT IS ADDRESSED. IF YOU ARE NOT THE INTENDED RECIPIENT, YOU ARE HEREBY NOTIFIED THAT ANY USE, DISSEMINATION, DISTRIBUTION OR COPYING OF THIS COMMUNICATION IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS ELECTRONIC MAIL TRANSMISSION IN ERROR, PLEASE IMMEDIATELY ERASE AND DELETE THE ORIGINAL MESSAGE FROM YOUR DATABASE -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: config.ppc URL: From alex at alex.org.uk Thu Oct 22 04:00:02 2009 From: alex at alex.org.uk (Alex Bligh) Date: Wed, 21 Oct 2009 18:00:02 +0100 Subject: Problems porting to an ARM platform In-Reply-To: <4ADF1F91.6080803@ppc-ag.de> References: <4ADC599A.5020309@ppc-ag.de> <4ADC5B91.1060306@zip.com.au> <4ADEDAAE.4070809@ppc-ag.de> <4ADEE49B.6040609@zip.com.au> <4ADF1F91.6080803@ppc-ag.de> Message-ID: <7CD85EAA7B18A3CF304B34C4@Ximines.local> --On 21 October 2009 16:49:53 +0200 Christoph Baumann wrote: >> - can you run ssh under a debugger? if so what does the backtrace show? > > Currently I don't have a gdb suitable for running on the target (it uses > the bflt executable format). strace / ltrace might be your friends. Crashes really early on are sometimes the result of a dynamically linked library not loading. You might check using your preferred library tool that the executable really is entirely static (as you suggest that's all your platform supports). Sometimes configure options don't do everything you expect them to (not a specific reference to openssh). You could also try compiling for the local platform with all the same options except the arm specific ones and see if it crashes in the same way. -- Alex Bligh From lists at spuddy.org Fri Oct 23 03:07:43 2009 From: lists at spuddy.org (Stephen Harris) Date: Thu, 22 Oct 2009 12:07:43 -0400 Subject: Disabling $HOME/.ssh/rc Message-ID: <20091022160743.GA22233@mercury.spuddy.org> Sorry if this is a silly question, but I couldn't see how to stop this. I'm concerned with the use of ~/.ssh/rc and similar files. The problem is that if $HOME is on an NFS server then this essentially means user accounts can be compromised due to ssh activity, or a locked down account (command= restrictions) may be able to exceed it's expected access rights. We already put authorized_keys into /etc (painful; means every host needs touching) and would like to be able to prevent other types of non-approved execution. Ideas? Thanks! -- rgds Stephen From scott_n at xypro.com Fri Oct 23 05:25:07 2009 From: scott_n at xypro.com (Scott Neugroschl) Date: Thu, 22 Oct 2009 11:25:07 -0700 Subject: Disabling $HOME/.ssh/rc In-Reply-To: <20091022160743.GA22233@mercury.spuddy.org> References: <20091022160743.GA22233@mercury.spuddy.org> Message-ID: <78DD71C304F38B41885A242996B96F7301FE735F@xyservd.XYPRO-23.LOCAL> > Sorry if this is a silly question, but I couldn't see how to stop this. > > I'm concerned with the use of ~/.ssh/rc and similar files. The > problem is that if $HOME is on an NFS server then this essentially > means user accounts can be compromised due to ssh activity, or a > locked down account (command= restrictions) may be able to exceed it's > expected access rights. > > We already put authorized_keys into /etc (painful; means every host > needs > touching) and would like to be able to prevent other types of non- > approved execution. > Guess what? You get to edit and distribute authorized_keys again. If you look at the man for sshd, in the authorized_keys section, you see that you can add no-user-rc as a comment on any particular key. From lists at spuddy.org Fri Oct 23 06:19:10 2009 From: lists at spuddy.org (Stephen Harris) Date: Thu, 22 Oct 2009 15:19:10 -0400 Subject: Disabling $HOME/.ssh/rc In-Reply-To: <78DD71C304F38B41885A242996B96F7301FE735F@xyservd.XYPRO-23.LOCAL> References: <20091022160743.GA22233@mercury.spuddy.org> <78DD71C304F38B41885A242996B96F7301FE735F@xyservd.XYPRO-23.LOCAL> Message-ID: <20091022191910.GA22905@mercury.spuddy.org> On Thu, Oct 22, 2009 at 11:25:07AM -0700, Scott Neugroschl wrote: > > I'm concerned with the use of ~/.ssh/rc and similar files. The > > problem is that if $HOME is on an NFS server then this essentially > > means user accounts can be compromised due to ssh activity, or a > > locked down account (command= restrictions) may be able to exceed it's > > expected access rights. > Guess what? You get to edit and distribute authorized_keys again. If > you look at the man for sshd, in the authorized_keys section, you see > that you can add no-user-rc as a comment on any particular key. *google**google* Hmm, that came in with 4.9p1 ? Unfortunately the product we're using (which I believe runs a modified sshd) uses 4.3p2. Hmm. Maybe we should push the vendor to upgrade! Thanks. Rgds Stephen From karlis.repsons at gmail.com Fri Oct 23 06:44:32 2009 From: karlis.repsons at gmail.com (=?utf-8?q?K=C4=81rlis_Repsons?=) Date: Thu, 22 Oct 2009 19:44:32 +0000 Subject: chroot to dir per user? Message-ID: <200910221944.32971.Karlis.Repsons@gmail.com> Hi there, let me just ask if you know some good way to set up user chrooting in such a way, that each sftp user has its chroot directory entry somewhere (whatever path) and gets chrooted there upon its login? Maybe such feature is planned? Thanks... K. From djm at mindrot.org Fri Oct 23 07:39:56 2009 From: djm at mindrot.org (Damien Miller) Date: Fri, 23 Oct 2009 06:39:56 +1000 (EST) Subject: chroot to dir per user? In-Reply-To: <200910221944.32971.Karlis.Repsons@gmail.com> References: <200910221944.32971.Karlis.Repsons@gmail.com> Message-ID: On Thu, 22 Oct 2009, K?rlis Repsons wrote: > Hi there, > > let me just ask if you know some good way to set up user chrooting in such a > way, that each sftp user has its chroot directory entry somewhere (whatever > path) and gets chrooted there upon its login? Maybe such feature is planned? > Thanks... Yes, read the sshd_config(5) manpage and search for ChrootDirectory. -d From karlis.repsons at gmail.com Fri Oct 23 08:01:01 2009 From: karlis.repsons at gmail.com (=?utf-8?q?K=C4=81rlis_Repsons?=) Date: Thu, 22 Oct 2009 21:01:01 +0000 Subject: chroot to dir per user? In-Reply-To: References: <200910221944.32971.Karlis.Repsons@gmail.com> Message-ID: <200910222101.01356.Karlis.Repsons@gmail.com> On Thursday 22 October 2009 20:39:56 Damien Miller wrote: > On Thu, 22 Oct 2009, K?rlis Repsons wrote: > > Hi there, > > > > let me just ask if you know some good way to set up user chrooting in > > such a way, that each sftp user has its chroot directory entry somewhere > > (whatever path) and gets chrooted there upon its login? Maybe such > > feature is planned? Thanks... > > Yes, read the sshd_config(5) manpage and search for ChrootDirectory. ChrootDirectory together with Match, right? Perhaps awfully wrong for some reason, but what would happen, if chroot target directory/its contents wouldn't be root owned? For allowing some users/groups sftp access only to their content it seems logical and usable, that they own those directories... Is it then a dead end? From djm at mindrot.org Fri Oct 23 08:32:39 2009 From: djm at mindrot.org (Damien Miller) Date: Fri, 23 Oct 2009 07:32:39 +1000 (EST) Subject: chroot to dir per user? In-Reply-To: <200910222101.01356.Karlis.Repsons@gmail.com> References: <200910221944.32971.Karlis.Repsons@gmail.com> <200910222101.01356.Karlis.Repsons@gmail.com> Message-ID: On Thu, 22 Oct 2009, K?rlis Repsons wrote: > On Thursday 22 October 2009 20:39:56 Damien Miller wrote: > > On Thu, 22 Oct 2009, K?rlis Repsons wrote: > > > Hi there, > > > > > > let me just ask if you know some good way to set up user chrooting in > > > such a way, that each sftp user has its chroot directory entry somewhere > > > (whatever path) and gets chrooted there upon its login? Maybe such > > > feature is planned? Thanks... > > > > Yes, read the sshd_config(5) manpage and search for ChrootDirectory. > > ChrootDirectory together with Match, right? Perhaps awfully wrong for some > reason, but what would happen, if chroot target directory/its contents > wouldn't be root owned? For allowing some users/groups sftp access only to > their content it seems logical and usable, that they own those directories... > Is it then a dead end? https://bugzilla.redhat.com/show_bug.cgi?id=522141 is what happens when this restriction is relaxed. -d From surgpm at gmail.com Fri Oct 23 23:55:05 2009 From: surgpm at gmail.com (Paul Surgeon) Date: Fri, 23 Oct 2009 14:55:05 +0200 Subject: internal-sftp only without ssh and scp hanging Message-ID: <6d98c5450910230555n1aa8f62dxec9b2d905191c5ba@mail.gmail.com> I've configured OpenSSH_5.3p1 to only allow sftp connections (openssh chroot functionality). i.e. Subsystem sftp internal-sftp Match group sftpusers ChrootDirectory /chroot/%u X11Forwarding no AllowTcpForwarding no ForceCommand internal-sftp So far everything works correctly with sftp but when a user ssh's or scp's to the box the login hangs after authentication. Is there anyway to get sshd to close the connection instead of just hanging? My question is the same as this post which was never answered: http://marc.info/?l=openssh-unix-dev&m=124492525712723&w=2 Thanks From aris.adamantiadis at belnet.be Sat Oct 24 00:07:59 2009 From: aris.adamantiadis at belnet.be (Aris Adamantiadis) Date: Fri, 23 Oct 2009 15:07:59 +0200 Subject: internal-sftp only without ssh and scp hanging In-Reply-To: <6d98c5450910230555n1aa8f62dxec9b2d905191c5ba@mail.gmail.com> References: <6d98c5450910230555n1aa8f62dxec9b2d905191c5ba@mail.gmail.com> Message-ID: <4AE1AAAF.8000508@belnet.be> Hello, I suggest Subsystem sftp internal-sftp Match group sftpusers ChrootDirectory /chroot/%u X11Forwarding no AllowTcpForwarding no ForceCommand "echo no external login allowed" Subsystem sftp internal-sftp Since I don't see an obvious way of denying a request-shell or a request-exec query. I'm not 100% sure it's going to work. Don't forget AllowTcpForwarding no if this is relevant. Aris Paul Surgeon a ?crit : > I've configured OpenSSH_5.3p1 to only allow sftp connections (openssh > chroot functionality). > > i.e. > Subsystem sftp internal-sftp > Match group sftpusers > ChrootDirectory /chroot/%u > X11Forwarding no > AllowTcpForwarding no > ForceCommand internal-sftp > > So far everything works correctly with sftp but when a user ssh's or > scp's to the box the login hangs after authentication. > Is there anyway to get sshd to close the connection instead of just hanging? > > My question is the same as this post which was never answered: > http://marc.info/?l=openssh-unix-dev&m=124492525712723&w=2 > > Thanks > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From peter at stuge.se Sat Oct 24 04:07:10 2009 From: peter at stuge.se (Peter Stuge) Date: Fri, 23 Oct 2009 19:07:10 +0200 Subject: internal-sftp only without ssh and scp hanging In-Reply-To: <6d98c5450910230555n1aa8f62dxec9b2d905191c5ba@mail.gmail.com> References: <6d98c5450910230555n1aa8f62dxec9b2d905191c5ba@mail.gmail.com> Message-ID: <20091023170710.14540.qmail@stuge.se> Paul Surgeon wrote: > i.e. > Subsystem sftp internal-sftp > Match group sftpusers > ChrootDirectory /chroot/%u > X11Forwarding no > AllowTcpForwarding no > ForceCommand internal-sftp > > So far everything works correctly with sftp but when a user ssh's > or scp's to the box the login hangs after authentication. Hm. I guess internal-sftp is used as shell for whatever ssh and scp want to execute. Maybe that looks just like a legitimate start of internal-sftp, then I think the forcecommand echo idea is better. //Peter From dtucker at zip.com.au Sat Oct 24 06:28:54 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Sat, 24 Oct 2009 06:28:54 +1100 Subject: internal-sftp only without ssh and scp hanging In-Reply-To: <6d98c5450910230555n1aa8f62dxec9b2d905191c5ba@mail.gmail.com> References: <6d98c5450910230555n1aa8f62dxec9b2d905191c5ba@mail.gmail.com> Message-ID: <4AE203F6.7080004@zip.com.au> Paul Surgeon wrote: > I've configured OpenSSH_5.3p1 to only allow sftp connections (openssh > chroot functionality). [...] > So far everything works correctly with sftp but when a user ssh's or > scp's to the box the login hangs after authentication. > Is there anyway to get sshd to close the connection instead of just hanging? Funny you should ask that. Damien wrote a patch for that yesterday: https://bugzilla.mindrot.org/show_bug.cgi?id=1606 -- 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 Dave at Yost.com Sun Oct 25 10:15:05 2009 From: Dave at Yost.com (Dave Yost) Date: Sat, 24 Oct 2009 16:15:05 -0700 Subject: known_hosts(5) man page Message-ID: Here's our situation. Two hosts, s1, s2, each with its own key. Domain name foo is aliased to either s1 or s2 (each with its own fixed IP address), depending on which is working correctly at any given time. The known_hosts(5) man page, when it comes into existence, should explain how I would express that the ip-address/key pair from either s1 or s2 is acceptable when connecting to foo. I can't find any documentation that suggests if this is possible or if so, how to do it. Thanks Dave Ref: http://openssh.org/manual.html From rees at umich.edu Sun Oct 25 11:41:48 2009 From: rees at umich.edu (Jim Rees) Date: Sat, 24 Oct 2009 20:41:48 -0400 Subject: known_hosts(5) man page In-Reply-To: References: Message-ID: <20091025004148.GA4060@merit.edu> Given that the hosts are interchangeable from the client's point of view, shouldn't they both have the same host key? From bob at proulx.com Sun Oct 25 17:08:21 2009 From: bob at proulx.com (Bob Proulx) Date: Sun, 25 Oct 2009 00:08:21 -0600 Subject: known_hosts(5) man page In-Reply-To: <20091025004148.GA4060@merit.edu> References: <20091025004148.GA4060@merit.edu> Message-ID: <20091025060820.GA7306@discord.proulx.com> Jim Rees wrote: > Given that the hosts are interchangeable from the client's point of view, > shouldn't they both have the same host key? Let me second that. A pool of failover servers should have the same host key. They aren't individual machines at that point. Like mirrored disks they are logically mirrors of each other. Bob From Dave at Yost.com Sun Oct 25 17:44:53 2009 From: Dave at Yost.com (Dave Yost) Date: Sat, 24 Oct 2009 23:44:53 -0700 Subject: known_hosts(5) man page In-Reply-To: <20091025060820.GA7306@discord.proulx.com> References: <20091025004148.GA4060@merit.edu> <20091025060820.GA7306@discord.proulx.com> Message-ID: At 12:08 AM -0600 2009-10-25, Bob Proulx wrote: >Jim Rees wrote: >> Given that the hosts are interchangeable from the client's point of view, >> shouldn't they both have the same host key? > >Let me second that. A pool of failover servers should have the same >host key. They aren't individual machines at that point. Like >mirrored disks they are logically mirrors of each other. Hard to say. These aren't really a failover or a load-balanced group. It's more like a server plus other machines that can be pressed into service to fill in for the server in a pinch, in addition to the other stuff they do. From postbus111 at gmail.com Sun Oct 25 20:33:33 2009 From: postbus111 at gmail.com (Hans) Date: Sun, 25 Oct 2009 10:33:33 +0100 Subject: alternate output for progressmeter In-Reply-To: <990134e20910241434g695a4d51m1bc624f0d13a94f2@mail.gmail.com> References: <990134e20910241434g695a4d51m1bc624f0d13a94f2@mail.gmail.com> Message-ID: <990134e20910250233l65a6e406i60488ebd91fcb398@mail.gmail.com> Hi, I used scp in some background process for transferring large files which took some hours. For this I needed a less fancy output, preferable parseble by a script, so I could regularly see how far the transfer was The adaptions I made to progressmeter.c and .h are underneath my mail as a patch Some sample output how it looks now: :~/src/openssh-5.3p1$ ./scp -l 60000 test.bin hans at localhost:. progress test.bin : ? 0% ? ?0 ? ? 0.0KB/s ? --:-- ETA progress test.bin : ? 7% 7488KB ? 7.3MB/s ? 00:12 ETA progress test.bin : ?15% ? 14MB ? 7.3MB/s ? 00:11 ETA .. progress test.bin : ?98% ? 94MB ? 7.3MB/s ? 00:00 ETA progress test.bin : 100% ? 95MB ? 7.3MB/s ? 00:13 done With a simple script you can now easily control the output and save the progress somewhere: #!/bin/bash # --- only update status every 10 seconds statfn=scp1.status refresh=10 no=0 ./scp -l 60000 test.bin hans at localhost:. 2>&1|while read id fn sep perc size speed estim eta do ?((state=no % refresh)) ?[[ "$eta" = "done" || $state -eq 0 ]] && echo "`date +"%Y-%m-%d %H:%M:%S"` $fn $perc $size $speed $estim $eta" >$statfn ?((no=no+1)) done The patch only adds this functionality as an option, default the original layout is used. Only when variable progresstype is set to nonzero this alternate output is selected. For selecting the alternate output it would only require some commandline option in scp.c and do the isatty check only when progresstype==0 Let me know your comments... Hans --- progressmeter.h ? ? 2006-03-26 05:30:02.000000000 +0200 +++ progressmeter_new.h 2009-10-24 20:35:35.168288539 +0200 @@ -23,5 +23,7 @@ ?* THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. ?*/ +extern int ? ? progresstype; + ?void ? start_progress_meter(char *, off_t, off_t *); ?void ? stop_progress_meter(void); --- progressmeter.c ? ? 2006-08-05 04:39:40.000000000 +0200 +++ progressmeter_new.c 2009-10-24 20:32:45.455788330 +0200 @@ -74,12 +74,15 @@ ?static int win_size; ? ? ? ? ? /* terminal window size */ ?static volatile sig_atomic_t win_resized; /* for window resizing */ +int ? ?progresstype = 0; ? ? ? /* use default tty progress reporting */ + ?/* units for format_size */ ?static const char unit[] = " KMGT"; ?static int ?can_output(void) ?{ + ? ? ? if (progresstype) return 1; ? ? ? ?return (getpgrp() == tcgetpgrp(STDOUT_FILENO)); ?} @@ -158,9 +161,9 @@ ? ? ? ?/* filename */ ? ? ? ?buf[0] = '\0'; - ? ? ? file_len = win_size - 35; + ? ? ? file_len = (progresstype)?(strlen(file)+11):(win_size - 35); ? ? ? ?if (file_len > 0) { - ? ? ? ? ? ? ? len = snprintf(buf, file_len + 1, "\r%s", file); + ? ? ? ? ? ? ? len = snprintf(buf, file_len + 1, (progresstype)?"progress %s :":"\r%s", file); ? ? ? ? ? ? ? ?if (len < 0) ? ? ? ? ? ? ? ? ? ? ? ?len = 0; ? ? ? ? ? ? ? ?if (len >= file_len + 1) @@ -195,7 +198,7 @@ ? ? ? ? ? ? ? ?stalled = 0; ? ? ? ?if (stalled >= STALL_TIME) - ? ? ? ? ? ? ? strlcat(buf, "- stalled -", win_size); + ? ? ? ? ? ? ? strlcat(buf, (progresstype)?"-stalled-":"- stalled -", win_size); ? ? ? ?else if (bytes_per_second == 0 && bytes_left) ? ? ? ? ? ? ? ?strlcat(buf, " ?--:-- ETA", win_size); ? ? ? ?else { @@ -219,10 +222,14 @@ ? ? ? ? ? ? ? ?if (bytes_left > 0) ? ? ? ? ? ? ? ? ? ? ? ?strlcat(buf, " ETA", win_size); ? ? ? ? ? ? ? ?else - ? ? ? ? ? ? ? ? ? ? ? strlcat(buf, " ? ?", win_size); + ? ? ? ? ? ? ? ? ? ? ? strlcat(buf, (progresstype)?" done":" ? ?", win_size); ? ? ? ?} - ? ? ? atomicio(vwrite, STDOUT_FILENO, buf, win_size - 1); + ? ? ? if (progresstype) { + ? ? ? ? ? ? ? strlcat(buf,"\n",win_size); + ? ? ? ? ? ? ? atomicio(vwrite, STDOUT_FILENO, buf, strlen(buf)); + ? ? ? } else + ? ? ? ? ? ? ? atomicio(vwrite, STDOUT_FILENO, buf, win_size - 1); ? ? ? ?last_update = now; ?} @@ -234,7 +241,7 @@ ? ? ? ?save_errno = errno; - ? ? ? if (win_resized) { + ? ? ? if (progresstype==0 && win_resized) { ? ? ? ? ? ? ? ?setscreensize(); ? ? ? ? ? ? ? ?win_resized = 0; ? ? ? ?} @@ -257,12 +264,16 @@ ? ? ? ?stalled = 0; ? ? ? ?bytes_per_second = 0; - ? ? ? setscreensize(); + ? ? ? if (progresstype) + ? ? ? ? ? ? ? win_size=MAX_WINSIZE; + ? ? ? else { + ? ? ? ? ? ? ? setscreensize(); + ? ? ? ? ? ? ? signal(SIGWINCH, sig_winch); + ? ? ? } ? ? ? ?if (can_output()) ? ? ? ? ? ? ? ?refresh_progress_meter(); ? ? ? ?signal(SIGALRM, update_progress_meter); - ? ? ? signal(SIGWINCH, sig_winch); ? ? ? ?alarm(UPDATE_INTERVAL); ?} @@ -278,7 +289,8 @@ ? ? ? ?if (cur_pos != end_pos) ? ? ? ? ? ? ? ?refresh_progress_meter(); - ? ? ? atomicio(vwrite, STDOUT_FILENO, "\n", 1); + ? ? ? if (progresstype==0) + ? ? ? ? ? ? ? atomicio(vwrite, STDOUT_FILENO, "\n", 1); ?} ?/*ARGSUSED*/ From l.gautrot at free.fr Sun Oct 25 19:20:30 2009 From: l.gautrot at free.fr (Laurent GAUTROT) Date: Sun, 25 Oct 2009 09:20:30 +0100 Subject: openssh-unix-dev Digest, Vol 78, Issue 8 In-Reply-To: References: Message-ID: <4AE40A4E.8040403@free.fr> Le 25/10/2009 01:23, openssh-unix-dev-request at mindrot.org a ?crit : > Date: Sat, 24 Oct 2009 16:15:05 -0700 > From: Dave Yost > To:"openssh-unix-dev at mindrot.org" > Subject: known_hosts(5) man page > Message-ID: > Content-Type: text/plain; charset="us-ascii" ; format="flowed" > > Here's our situation. Two hosts, s1, s2, each with its own key. > Domain name foo is aliased to either s1 or s2 (each with its own > fixed IP address), depending on which is working correctly at any > given time. > The known_hosts(5) man page, when it comes into existence, should > explain how I would express that the ip-address/key pair from either > s1 or s2 is acceptable when connecting to foo. > I can't find any documentation that suggests if this is possible or > if so, how to do it. Hello, Let's consider 2 options. Either those hosts are "somewhat the same", and you may find it useful to stick the same host keys to both, then use something like a *Hostname* directive ssh_config(5). Or they actually are different, and you should refer to each host with a specific name, that is, using a different hostname and a key. Regards From dtucker at zip.com.au Sun Oct 25 21:08:38 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Sun, 25 Oct 2009 21:08:38 +1100 Subject: known_hosts(5) man page In-Reply-To: References: <20091025004148.GA4060@merit.edu> <20091025060820.GA7306@discord.proulx.com> Message-ID: <4AE423A6.6010006@zip.com.au> Dave Yost wrote: > At 12:08 AM -0600 2009-10-25, Bob Proulx wrote: >> Jim Rees wrote: >>> Given that the hosts are interchangeable from the client's point of view, >>> shouldn't they both have the same host key? >> Let me second that. A pool of failover servers should have the same >> host key. They aren't individual machines at that point. Like >> mirrored disks they are logically mirrors of each other. > > Hard to say. These aren't really a failover or a load-balanced group. > It's more like a server plus other machines that can be pressed into > service to fill in for the server in a pinch, in addition to the > other stuff they do. The main question is: are they under the same administrative control? The host key protects you against MITM, but by definition the server's administrator can already conduct a MITM (since the server has access to the decrypted traffic and the admins have access to the host keys). If the machines are run by the same admins then you're not giving up much by using the same host keys. The other option for clusters (no applicable in this case from your description) is to have "cluster package" that has a sshd bound to the floating cluster address with its own host keys and have this sshd move with the ddress. -- 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 jchadima at redhat.com Mon Oct 26 21:49:02 2009 From: jchadima at redhat.com (Jan Chadima) Date: Mon, 26 Oct 2009 06:49:02 -0400 (EDT) Subject: Support for merging LPK into mainline openssh? In-Reply-To: <544264819.698741256553745195.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Message-ID: <1313750859.698941256554142076.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> Hello I've created patch to the openssh which allows to use an agent for obtaining the public keys. It may be the first step towards the implementation of something similar lpk. The solution is independent on the agent, so it may be used with ldap based agent or with any other technology. May be that patch acceptable as the first aproach to the lpk replacement? It is placet in mindrot's bugzilla #1663. -- JFCh From scott_n at xypro.com Tue Oct 27 02:21:10 2009 From: scott_n at xypro.com (Scott Neugroschl) Date: Mon, 26 Oct 2009 08:21:10 -0700 Subject: SCP Message-ID: <78DD71C304F38B41885A242996B96F7301FE7551@xyservd.XYPRO-23.LOCAL> I'm using 5.0p1 (Yeah, yeah. I know.). For various reasons, I am unable to upgrade to the latest and greatest, which probably would solve my problem. Here's my question. When doing an scp from remote to local (e.g.: scp user at host:remote localfile), is there any way to specify the path to the remote scp? Or do I have to patch the code to allow it? ---- Scott Neugroschl XYPRO Technology Corporation scott_n at xypro.com 805-583-2874 From c.baumann at ppc-ag.de Tue Oct 27 02:31:09 2009 From: c.baumann at ppc-ag.de (Christoph Baumann) Date: Mon, 26 Oct 2009 16:31:09 +0100 Subject: Problems porting to an ARM platform In-Reply-To: <7CD85EAA7B18A3CF304B34C4@Ximines.local> References: <4ADC599A.5020309@ppc-ag.de> <4ADC5B91.1060306@zip.com.au> <4ADEDAAE.4070809@ppc-ag.de> <4ADEE49B.6040609@zip.com.au> <4ADF1F91.6080803@ppc-ag.de> <7CD85EAA7B18A3CF304B34C4@Ximines.local> Message-ID: <4AE5C0BD.6090505@ppc-ag.de> Hello all, using 'debug3' for debugging I traced the problem to 'getenv'. This call crashes on my platform. To avoid this I inserted a wrapper to getenv that returns some default values for 'TERM' and 'SSH_AUTH_SOCK'. Now ssh runs until the output: "debug1: Sending environment." Here again the environment variables are accessed. The parameter 'env' of 'client_session2_setup' has the value 0x58585858, which looks like a rather improbable value for a pointer. Currently I try to track this further down. Dipl.-Phys. Christoph Baumann Power PLUS Communications AG Am Exerzierplatz 2 68167 Mannheim Germany phone: +49(621)40165-??? fax: +49(621)40165-??? mailto://c.baumann at ppc-ag.de http://www.ppc-ag.de Handelsregister-Nr.: HRB 8853 Sitz und Registergericht: Mannheim Vorstand: Ingo Sch?nberg (Vorsitzender), Eugen Mayer Vorsitzender des Aufsichtsrates Univ.-Prof. Dr. Torsten Gerpott THE INFORMATION CONTAINED IN THIS ELECTRONIC MAIL TRANSMISSION IS CONFIDENTIAL AND MAY ALSO CONTAIN PRIVILEGED INFORMATION OR WORK PRODUCT. THE INFORMATION IS INTENDED ONLY FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHOM IT IS ADDRESSED. IF YOU ARE NOT THE INTENDED RECIPIENT, YOU ARE HEREBY NOTIFIED THAT ANY USE, DISSEMINATION, DISTRIBUTION OR COPYING OF THIS COMMUNICATION IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS ELECTRONIC MAIL TRANSMISSION IN ERROR, PLEASE IMMEDIATELY ERASE AND DELETE THE ORIGINAL MESSAGE FROM YOUR DATABASE From jchadima at redhat.com Tue Oct 27 02:34:20 2009 From: jchadima at redhat.com (Jan Chadima) Date: Mon, 26 Oct 2009 11:34:20 -0400 (EDT) Subject: Support for merging LPK into mainline openssh? In-Reply-To: Message-ID: <1603189137.728961256571260022.JavaMail.root@zmail04.collab.prod.int.phx2.redhat.com> ----- "Peter Lambrechtsen" wrote: > I like it. > > One thing that would be good is having some sort of signing mechnanism > on the Agent. As I see you check to make sure the ownership of the > file is ok. > > How about another approach is to sign the Agent with the servers > private key (if that's possible??). Maybe may be included SHA hash of agent program in the config file and it may be checked before running the agent. But it is necessary? and who will check all the shared libraies used? > > That way if the servers private key was compromised then you have a > problem, otherwise the other checking on the file isn't necessary. > > Otherwise I really like it, and it would be great to see this sort of > feature make its way into mainline. > > > On Mon, Oct 26, 2009 at 11:49 PM, Jan Chadima < jchadima at redhat.com > > wrote: > > > Hello > I've created patch to the openssh which allows to use an agent for > obtaining the public keys. > It may be the first step towards the implementation of something > similar lpk. The solution is independent on the agent, so it may be > used with ldap based agent or with any other technology. > May be that patch acceptable as the first aproach to the lpk > replacement? > It is placet in mindrot's bugzilla #1663. > > -- > JFCh > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- JFCh From mouring at eviladmin.org Tue Oct 27 02:39:24 2009 From: mouring at eviladmin.org (Ben Lindstrom) Date: Mon, 26 Oct 2009 10:39:24 -0500 Subject: SCP In-Reply-To: <78DD71C304F38B41885A242996B96F7301FE7551@xyservd.XYPRO-23.LOCAL> References: <78DD71C304F38B41885A242996B96F7301FE7551@xyservd.XYPRO-23.LOCAL> Message-ID: <8BC2C36C-59FB-4C10-9AD2-39B30298657E@eviladmin.org> I believe you are looking for: -S program Name of program to use for the encrypted connection. The program must understand ssh(1) options. This has existed since for a long time. e.g. scp -S /path/to/scp remote:file localname - Ben On Oct 26, 2009, at 10:21 AM, Scott Neugroschl wrote: > I'm using 5.0p1 (Yeah, yeah. I know.). For various reasons, I am > unable > to upgrade to the latest and greatest, which probably would solve my > problem. > > > > Here's my question. > > > > When doing an scp from remote to local (e.g.: scp user at host:remote > localfile), is there any way to specify the path to the remote scp? > Or > do I have to patch the code to allow it? > > > > > > > > ---- > > Scott Neugroschl > > XYPRO Technology Corporation > > scott_n at xypro.com > > 805-583-2874 > > > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From Sergio.Gelato at astro.su.se Tue Oct 27 03:38:24 2009 From: Sergio.Gelato at astro.su.se (Sergio Gelato) Date: Mon, 26 Oct 2009 17:38:24 +0100 Subject: known_hosts(5) man page In-Reply-To: <4AE423A6.6010006@zip.com.au> References: <20091025004148.GA4060@merit.edu> <20091025060820.GA7306@discord.proulx.com> <4AE423A6.6010006@zip.com.au> Message-ID: <20091026163824.GC16052@astro.su.se> * Darren Tucker [2009-10-25 21:08:38 +1100]: > Dave Yost wrote: >> At 12:08 AM -0600 2009-10-25, Bob Proulx wrote: >>> Jim Rees wrote: >>>> Given that the hosts are interchangeable from the client's point of view, >>>> shouldn't they both have the same host key? >>> Let me second that. A pool of failover servers should have the same >>> host key. They aren't individual machines at that point. Like >>> mirrored disks they are logically mirrors of each other. >> >> Hard to say. These aren't really a failover or a load-balanced group. >> It's more like a server plus other machines that can be pressed into >> service to fill in for the server in a pinch, in addition to the >> other stuff they do. > > The main question is: are they under the same administrative control? > The host key protects you against MITM, but by definition the server's > administrator can already conduct a MITM (since the server has access to > the decrypted traffic and the admins have access to the host keys). If > the machines are run by the same admins then you're not giving up much > by using the same host keys. If they are under the same administrative control but at different security levels (say, physically accessible workstations vs. a server in a secure room) sharing the host key may be riskier than you describe. > The other option for clusters (no applicable in this case from your > description) is to have "cluster package" that has a sshd bound to the > floating cluster address with its own host keys and have this sshd move > with the ddress. I see that with GSS key exchange (which unfortunately isn't a standard part of OpenSSH yet, only a popular and widely-deployed patch) and a DNS CNAME RR the GSSAPI library (MIT 1.6 in my test) resolves the CNAME before it asks the KDC for a ticket. Then everything is fine, since the RSA/DSA host keys are ignored and the server is authenticated by GSS instead. (I suppose one could likewise make OpenSSH traverse CNAMEs before the known_hosts lookup, but somehow I don't think you'll find the added complexity worthwhile.) From zaq21wsx at rediffmail.com Fri Oct 30 01:27:52 2009 From: zaq21wsx at rediffmail.com (qqq ) Date: 29 Oct 2009 14:27:52 -0000 Subject: =?utf-8?B?c3NoX2Z4cF9uYW1l?= Message-ID: <20091029142752.8133.qmail@f6mail-144-199.rediffmail.com> Hello, I have a very basic sftp client which is able to successfully intialize the transport layer, password authenticate, and start the sftp subsystem. Now, I am stuck with an issue when I try to retrieve the directory listing. Sometimes I get a transport packet in which the sftp packet length field registers a length greater than the enclosing transport packet. In othet words sometimes I get a transport packet whose lenght is less than what the sftp packet length field registers. This happens only sometimes. That is, if I give SSH_FXP_READDIR commands say 30 times on the same directory, then I get this packet after around 25-30 iterations. I tried to check the readability of the socket when this happens but the server does not send anything after this and select just hangs. I am not able to think of why this is happening and would apprecaite pointers in the right direction. thanks Ajoy good case packet header: 00 00 07 4c 0f 5e 00 00 00 00 00 00 07 33 00 00 07 2f 68 00 00 00 02 00 00 00 11 00 00 00 01 2e 00 00 00 ... bad case packet header: 00 00 04 9c 07 5e 00 00 00 00 00 00 04 8b 00 00 07 2f 68 00 00 00 52 00 00 00 11 00 00 00 01 2e 00 00 00 ... From pepper at cbio.mskcc.org Fri Oct 30 03:01:59 2009 From: pepper at cbio.mskcc.org (Chris Pepper) Date: Thu, 29 Oct 2009 12:01:59 -0400 Subject: Match vs. ChallengeResponseAuthentication? Message-ID: <4AE9BC77.6090309@cbio.mskcc.org> Hello, We'd like to allow passwords only from the local network, and allow public key auth from on-campus or off-campus. The server runs SuSE Linux, and we might do the same on RHEL/CentOS & Mac OS X if we can get it to work. Unfortunately, Match allows PasswordAuthentication but not ChallengeResponseAuthentication. Is there any reason ChallengeResponseAuthentication cannot be supported in this context? Plan B is to run 2 different sshd servers on different ports, and direct users to the appropriate one via iptables, but that's much more complicated. Thanks, Chris -- Chris Pepper: From djm at mindrot.org Fri Oct 30 11:11:00 2009 From: djm at mindrot.org (Damien Miller) Date: Fri, 30 Oct 2009 11:11:00 +1100 (EST) Subject: ssh_fxp_name In-Reply-To: <20091029142752.8133.qmail@f6mail-144-199.rediffmail.com> References: <20091029142752.8133.qmail@f6mail-144-199.rediffmail.com> Message-ID: On Fri, 29 Oct 2009, qqq wrote: > Hello, > > I have a very basic sftp client which is able to successfully > intialize the transport layer, password authenticate, and start the > sftp subsystem. Now, I am stuck with an issue when I try to retrieve > the directory listing. Sometimes I get a transport packet in which the > sftp packet length field registers a length greater than the enclosing > transport packet. In othet words sometimes I get a transport packet > whose lenght is less than what the sftp packet length field registers. > This happens only sometimes. That is, if I give SSH_FXP_READDIR > commands say 30 times on the same directory, then I get this packet > after around 25-30 iterations. I tried to check the readability of the > socket when this happens but the server does not send anything after > this and select just hangs. I am not able to think of why this is > happening and would apprecaite pointers in the right direction. thanks sftp operates at a protocol layer above the SSH transport, so the size of sftp's packets may exceed the maximum allowed by the ssh connection. In these cases, a sftp packet may span multiple transport packets. -d From djm at mindrot.org Fri Oct 30 11:15:08 2009 From: djm at mindrot.org (Damien Miller) Date: Fri, 30 Oct 2009 11:15:08 +1100 (EST) Subject: Match vs. ChallengeResponseAuthentication? In-Reply-To: <4AE9BC77.6090309@cbio.mskcc.org> References: <4AE9BC77.6090309@cbio.mskcc.org> Message-ID: On Thu, 29 Oct 2009, Chris Pepper wrote: > Hello, > > We'd like to allow passwords only from the local network, and allow > public key auth from on-campus or off-campus. The server runs SuSE Linux, and > we might do the same on RHEL/CentOS & Mac OS X if we can get it to work. > > Unfortunately, Match allows PasswordAuthentication but not > ChallengeResponseAuthentication. Is there any reason > ChallengeResponseAuthentication cannot be supported in this context? If you are using SSH protocol 2 only, then you can turn off KbdInteractiveAuthentication inside match. Otherwise, try this diff: Index: servconf.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/servconf.c,v retrieving revision 1.196 diff -u -p -r1.196 servconf.c --- servconf.c 8 Oct 2009 14:03:41 -0000 1.196 +++ servconf.c 30 Oct 2009 00:13:25 -0000 @@ -333,8 +333,8 @@ static struct { #endif { "passwordauthentication", sPasswordAuthentication, SSHCFG_ALL }, { "kbdinteractiveauthentication", sKbdInteractiveAuthentication, SSHCFG_ALL }, - { "challengeresponseauthentication", sChallengeResponseAuthentication, SSHCFG_GLOBAL }, - { "skeyauthentication", sChallengeResponseAuthentication, SSHCFG_GLOBAL }, /* alias */ + { "challengeresponseauthentication", sChallengeResponseAuthentication, SSHCFG_ALL }, + { "skeyauthentication", sChallengeResponseAuthentication, SSHCFG_ALL }, /* alias */ #ifdef JPAKE { "zeroknowledgepasswordauthentication", sZeroKnowledgePasswordAuthentication, SSHCFG_ALL }, #else @@ -1347,6 +1347,7 @@ copy_set_server_options(ServerOptions *d M_CP_INTOPT(kerberos_authentication); M_CP_INTOPT(hostbased_authentication); M_CP_INTOPT(kbd_interactive_authentication); + M_CP_INTOPT(challenge_response_authentication); M_CP_INTOPT(zero_knowledge_password_authentication); M_CP_INTOPT(permit_root_login); M_CP_INTOPT(permit_empty_passwd); Index: sshd_config.5 =================================================================== RCS file: /cvs/src/usr.bin/ssh/sshd_config.5,v retrieving revision 1.109 diff -u -p -r1.109 sshd_config.5 --- sshd_config.5 8 Oct 2009 20:42:13 -0000 1.109 +++ sshd_config.5 30 Oct 2009 00:13:25 -0000 @@ -602,6 +602,7 @@ Available keywords are .Cm AllowAgentForwarding , .Cm AllowTcpForwarding , .Cm Banner , +.Cm ChallengeResponseAuthentication , .Cm ChrootDirectory , .Cm ForceCommand , .Cm GatewayPorts , From dtucker at zip.com.au Fri Oct 30 11:55:49 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 30 Oct 2009 11:55:49 +1100 Subject: Match vs. ChallengeResponseAuthentication? In-Reply-To: References: <4AE9BC77.6090309@cbio.mskcc.org> Message-ID: <4AEA3995.3030708@zip.com.au> Damien Miller wrote: > On Thu, 29 Oct 2009, Chris Pepper wrote: > >> Hello, >> >> We'd like to allow passwords only from the local network, and allow >> public key auth from on-campus or off-campus. The server runs SuSE Linux, and >> we might do the same on RHEL/CentOS & Mac OS X if we can get it to work. >> >> Unfortunately, Match allows PasswordAuthentication but not >> ChallengeResponseAuthentication. Is there any reason >> ChallengeResponseAuthentication cannot be supported in this context? > > If you are using SSH protocol 2 only, then you can turn off > KbdInteractiveAuthentication inside match. Otherwise, try this diff: Conversely, if you're willing to require SSHv2 clients for CR-based authentication you can turn off ChallengeResponseAuthentication globally and enable KbdInteractiveAuthentication for v2 clients your local networks, eg ChallengeResponseAuthentication no KbdInteractiveAuthentication no Match Address 10.0.0.0/8 KbdInteractiveAuthentication yes Originally ChallengeResponseAuthentication was omitted because it has slightly odd semantics. In sshd.c: /* Fill in default values for those options not explicitly set. */ fill_default_server_options(&options); /* challenge-response is implemented via keyboard interactive */ if (options.challenge_response_authentication) options.kbd_interactive_authentication = 1; If we're going to enable it we need to think through the use cases and make sure it adheres the principle of least surprise :-) -- Darren Tucker (dtucker at zip.com.au) GPG key 8FF4FA69 / D9A3 86E9 7EEE AF4B B2D4 37C9 C982 80C7 8FF4 FA69 Good judgement comes with experience. Unfortunately, the experience usually comes from bad judgement. From djm at mindrot.org Fri Oct 30 12:13:29 2009 From: djm at mindrot.org (Damien Miller) Date: Fri, 30 Oct 2009 12:13:29 +1100 (EST) Subject: Match vs. ChallengeResponseAuthentication? In-Reply-To: <4AEA3995.3030708@zip.com.au> References: <4AE9BC77.6090309@cbio.mskcc.org> <4AEA3995.3030708@zip.com.au> Message-ID: On Fri, 30 Oct 2009, Darren Tucker wrote: > ChallengeResponseAuthentication no > KbdInteractiveAuthentication no > Match Address 10.0.0.0/8 > KbdInteractiveAuthentication yes > > > Originally ChallengeResponseAuthentication was omitted because it has slightly > odd semantics. In sshd.c: > > /* Fill in default values for those options not explicitly set. */ > fill_default_server_options(&options); > > /* challenge-response is implemented via keyboard interactive */ > if (options.challenge_response_authentication) > options.kbd_interactive_authentication = 1; > > If we're going to enable it we need to think through the use cases and make > sure it adheres the principle of least surprise :-) Good point. I just noticed that we don't document KbdInteractiveAuthentication in sshd_config(5). Maybe we should deprecate it by making it a pointer to ChallengeResponseAutentication like SkeyAuthentication already is? -d From peter at stuge.se Fri Oct 30 13:41:03 2009 From: peter at stuge.se (Peter Stuge) Date: Fri, 30 Oct 2009 03:41:03 +0100 Subject: Problems porting to an ARM platform In-Reply-To: <4AE5C0BD.6090505@ppc-ag.de> References: <4ADC599A.5020309@ppc-ag.de> <4ADC5B91.1060306@zip.com.au> <4ADEDAAE.4070809@ppc-ag.de> <4ADEE49B.6040609@zip.com.au> <4ADF1F91.6080803@ppc-ag.de> <7CD85EAA7B18A3CF304B34C4@Ximines.local> <4AE5C0BD.6090505@ppc-ag.de> Message-ID: <20091030024103.12404.qmail@stuge.se> Christoph Baumann wrote: > Here again the environment variables are accessed. The parameter 'env' > of 'client_session2_setup' has the value 0x58585858, which looks like > a rather improbable value for a pointer. 0x58 == 'X' > Currently I try to track this further down. See if you can use valgrind on the target. //Peter From c.baumann at ppc-ag.de Sat Oct 31 00:25:41 2009 From: c.baumann at ppc-ag.de (Christoph Baumann) Date: Fri, 30 Oct 2009 14:25:41 +0100 Subject: Problems porting to an ARM platform In-Reply-To: <20091030024103.12404.qmail@stuge.se> References: <4ADC599A.5020309@ppc-ag.de> <4ADC5B91.1060306@zip.com.au> <4ADEDAAE.4070809@ppc-ag.de> <4ADEE49B.6040609@zip.com.au> <4ADF1F91.6080803@ppc-ag.de> <7CD85EAA7B18A3CF304B34C4@Ximines.local> <4AE5C0BD.6090505@ppc-ag.de> <20091030024103.12404.qmail@stuge.se> Message-ID: <4AEAE955.2060001@ppc-ag.de> On 30.10.2009 03:41, Peter Stuge wrote: > Christoph Baumann wrote: >> Here again the environment variables are accessed. The parameter 'env' >> of 'client_session2_setup' has the value 0x58585858, which looks like >> a rather improbable value for a pointer. > > 0x58 == 'X' That's a good point! I searched for the values 0x58585858 and 'X' in the sources and added more trace output. At the moment it looks like the function "initialize_options" in readconf.c is the culprit. It uses a "memset(options, 'X', sizeof(* options));" right at the start. After calling this function the "environ" is overwritten with 'X'. But I can't see why this happens. -- Dipl.-Phys. Christoph Baumann Power PLUS Communications AG Am Exerzierplatz 2 68167 Mannheim Germany phone: +49(621)40165-??? fax: +49(621)40165-??? mailto://c.baumann at ppc-ag.de http://www.ppc-ag.de Handelsregister-Nr.: HRB 8853 Sitz und Registergericht: Mannheim Vorstand: Ingo Sch?nberg (Vorsitzender), Eugen Mayer Vorsitzender des Aufsichtsrates Univ.-Prof. Dr. Torsten Gerpott THE INFORMATION CONTAINED IN THIS ELECTRONIC MAIL TRANSMISSION IS CONFIDENTIAL AND MAY ALSO CONTAIN PRIVILEGED INFORMATION OR WORK PRODUCT. THE INFORMATION IS INTENDED ONLY FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHOM IT IS ADDRESSED. IF YOU ARE NOT THE INTENDED RECIPIENT, YOU ARE HEREBY NOTIFIED THAT ANY USE, DISSEMINATION, DISTRIBUTION OR COPYING OF THIS COMMUNICATION IS STRICTLY PROHIBITED. IF YOU HAVE RECEIVED THIS ELECTRONIC MAIL TRANSMISSION IN ERROR, PLEASE IMMEDIATELY ERASE AND DELETE THE ORIGINAL MESSAGE FROM YOUR DATABASE From peter at stuge.se Sat Oct 31 02:27:20 2009 From: peter at stuge.se (Peter Stuge) Date: Fri, 30 Oct 2009 16:27:20 +0100 Subject: Problems porting to an ARM platform In-Reply-To: <4AEAE955.2060001@ppc-ag.de> References: <4ADC599A.5020309@ppc-ag.de> <4ADC5B91.1060306@zip.com.au> <4ADEDAAE.4070809@ppc-ag.de> <4ADEE49B.6040609@zip.com.au> <4ADF1F91.6080803@ppc-ag.de> <7CD85EAA7B18A3CF304B34C4@Ximines.local> <4AE5C0BD.6090505@ppc-ag.de> <20091030024103.12404.qmail@stuge.se> <4AEAE955.2060001@ppc-ag.de> Message-ID: <20091030152720.27761.qmail@stuge.se> Christoph Baumann wrote: > "initialize_options" in readconf.c is the culprit. It uses a > "memset(options, 'X', sizeof(* options));" right at the start. > After calling this function the "environ" is overwritten with 'X'. > But I can't see why this happens. Add debugging: fprintf(stderr, "options=%p sizeof(* options)=%d 0x%x\n", options, sizeof(* options), sizeof(* options)); Also check what type options is? //Peter From c.baumann at ppc-ag.de Sat Oct 31 02:32:45 2009 From: c.baumann at ppc-ag.de (Christoph Baumann) Date: Fri, 30 Oct 2009 16:32:45 +0100 Subject: Problems porting to an ARM platform In-Reply-To: <20091030152720.27761.qmail@stuge.se> References: <4ADC599A.5020309@ppc-ag.de> <4ADC5B91.1060306@zip.com.au> <4ADEDAAE.4070809@ppc-ag.de> <4ADEE49B.6040609@zip.com.au> <4ADF1F91.6080803@ppc-ag.de> <7CD85EAA7B18A3CF304B34C4@Ximines.local> <4AE5C0BD.6090505@ppc-ag.de> <20091030024103.12404.qmail@stuge.se> <4AEAE955.2060001@ppc-ag.de> <20091030152720.27761.qmail@stuge.se> Message-ID: <4AEB071D.5060903@ppc-ag.de> On 30.10.2009 16:27, Peter Stuge wrote: > Add debugging: > > fprintf(stderr, "options=%p sizeof(* options)=%d 0x%x\n", > options, sizeof(* options), sizeof(* options)); > > Also check what type options is? The type of the global variable options is "Options" (note capital O). My trace output of the interesting addresses is this: &environ: 0x70cfb69c &options: 0x70cfa218 &options.forward_agent: 0x70cfa218 &options.visual_host_key: 0x70cfb6c8 sizeof(Options): 5300 'forward_agent' is the first and 'visual_host_key' the last element of the Options structure. As you can see the addresses overlap with 'environ'. This looks like a compiler problem. Any hints to fix that? -- Dipl.-Phys. Christoph Baumann Power PLUS Communications AG Am Exerzierplatz 2 68167 Mannheim Germany phone: +49(621)40165-??? fax: +49(621)40165-??? mailto://c.baumann at ppc-ag.de http://www.ppc-ag.de Handelsregister-Nr.: HRB 8853 Sitz und Registergericht: Mannheim Vorstand: Ingo Sch?nberg (Vorsitzender), Eugen Mayer Vorsitzender des Aufsichtsrates Univ.-Prof. Dr. Torsten Gerpott From peter at stuge.se Sat Oct 31 03:27:22 2009 From: peter at stuge.se (Peter Stuge) Date: Fri, 30 Oct 2009 17:27:22 +0100 Subject: Problems porting to an ARM platform In-Reply-To: <4AEB071D.5060903@ppc-ag.de> References: <4ADC5B91.1060306@zip.com.au> <4ADEDAAE.4070809@ppc-ag.de> <4ADEE49B.6040609@zip.com.au> <4ADF1F91.6080803@ppc-ag.de> <7CD85EAA7B18A3CF304B34C4@Ximines.local> <4AE5C0BD.6090505@ppc-ag.de> <20091030024103.12404.qmail@stuge.se> <4AEAE955.2060001@ppc-ag.de> <20091030152720.27761.qmail@stuge.se> <4AEB071D.5060903@ppc-ag.de> Message-ID: <20091030162722.5647.qmail@stuge.se> Christoph Baumann wrote: > This looks like a compiler problem. Any hints to fix that? Umm.. Use another toolchain? //Peter From scott_n at xypro.com Sat Oct 31 04:41:27 2009 From: scott_n at xypro.com (Scott Neugroschl) Date: Fri, 30 Oct 2009 10:41:27 -0700 Subject: Problems porting to an ARM platform In-Reply-To: <20091030162722.5647.qmail@stuge.se> References: <4ADC5B91.1060306@zip.com.au> <4ADEDAAE.4070809@ppc-ag.de><4ADEE49B.6040609@zip.com.au> <4ADF1F91.6080803@ppc-ag.de><7CD85EAA7B18A3CF304B34C4@Ximines.local><4AE5C0BD.6090505@ppc-ag.de> <20091030024103.12404.qmail@stuge.se><4AEAE955.2060001@ppc-ag.de> <20091030152720.27761.qmail@stuge.se><4AEB071D.5060903@ppc-ag.de> <20091030162722.5647.qmail@stuge.se> Message-ID: <78DD71C304F38B41885A242996B96F7301FE79DE@xyservd.XYPRO-23.LOCAL> > Christoph Baumann wrote: > > This looks like a compiler problem. Any hints to fix that? > > Umm.. Use another toolchain? > This is going to sound incredibly stupid and obvious. Any chance that a complete "make clean" and rebuild will clean it up? Sounds almost like something is defined in multiple places with different sizes.