From oainikusama at gmail.com Fri Jan 2 12:41:00 2009 From: oainikusama at gmail.com (breno) Date: Thu, 1 Jan 2009 23:41:00 -0200 Subject: Set connection timeouts? In-Reply-To: <200812302124.41888.Karlis.Repsons@gmail.com> References: <200812302124.41888.Karlis.Repsons@gmail.com> Message-ID: On Tue, Dec 30, 2008 at 7:24 PM, K?rlis Repsons wrote: > Hello, > Perhaps you could give some information here or redirect me, because it was > not clear while reading manuals: how can connection timeout be set for sshd? > Problem is, when some system is hibernated and it resumes, connections are > dead. Mostly I made a successful workaround, but would be nice to know... Could you be a little more specific on what have you already tried? sshd_config's "ClientAliveInterval" and "ClientAliveCountMax" options should do the trick. You might also want to take a look at "TCPKeepAlive" http://www.openbsd.org/cgi-bin/man.cgi?query=sshd_config&sektion=5 > Also, which version of ssh(d) support df on sshfs? > I don't think this is related to OpenSSH - you might try http://fuse.sourceforge.net/sshfs.html This is what a simple lookup on their faq returned: --------------8<-------------- -Why does df return strange values on partitions mounted via sshfs? Because the SFTP protocol doesn't have a statfs operation. OpenSSH 5.1 added support for a statfs extension to the SFTP protocol, and from version 2.1 sshfs can make use of this extension. So df will work if your SFTP server is OpenSSH > 5.1 and your sshfs version is > 2.1. --------------8<-------------- Cheers, -b From tim at multitalents.net Sat Jan 3 11:51:57 2009 From: tim at multitalents.net (Tim Rice) Date: Fri, 2 Jan 2009 16:51:57 -0800 (PST) Subject: any HP-UX 10.26 out there? Message-ID: Anyone have access to a HP/UX 10.26 machine that could test a small patch? I want to commit a patch for OpenServer 6 that adds SECUREWARE support for the OpenServer 6 SVR5 ABI. The changes affect one platform I do not have access to (HP-UX 10.26). The change in question is ...... --- openssh/openbsd-compat/xcrypt.c.old 2007-03-26 08:42:45.624801002 -0700 +++ openssh/openbsd-compat/xcrypt.c 2008-12-29 17:30:51.460000000 -0800 @@ -28,7 +28,7 @@ #include #include -# ifdef HAVE_CRYPT_H +# if defined(HAVE_CRYPT_H) && !defined(HAVE_SECUREWARE) # include # endif ...... I looked through my collection of surveys and don't see any sent in for HP-UX 10.26 to see if they even define HAVE_CRYPT_H Thanks. -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From sim at netnation.com Sat Jan 3 13:12:39 2009 From: sim at netnation.com (Simon Kirby) Date: Fri, 2 Jan 2009 18:12:39 -0800 Subject: DSA harmful for remote authentication to compromised hosts? In-Reply-To: <20081209175505.A11693@chiba.halibut.com> References: <20081210000717.GA28487@hostway.ca> <20081209175505.A11693@chiba.halibut.com> Message-ID: <20090103021239.GD9995@hostway.ca> On Tue, Dec 09, 2008 at 05:55:05PM -0800, Joshua Hill wrote: > This is true for DSA because a DSA signature features a per-signature > random 'k' variable which is used in the signing calculation and then > discarded. >... > RSA does not suffer from this particular problem. There is no > non-deterministic element to the basic RSA signature generation (though > certain padding methods do feature non-deterministic elements) > > In either case the private key resides on the client, so a client > vulnerability can result in the private key being compromised. > An insecure RNG is just one sort of host vulnerability in this context. Just to confirm, the client (which has the private key) supplies this random 'k' variable, or does the server (running sshd) generate it? If the latter, then I'd better stop using DSA keys in authorized_keys; otherwise, it should be OK. Thanks for the explanation! Simon- From josh-lists at untruth.org Sat Jan 3 13:21:00 2009 From: josh-lists at untruth.org (Joshua Hill) Date: Fri, 2 Jan 2009 18:21:00 -0800 Subject: DSA harmful for remote authentication to compromised hosts? In-Reply-To: <20090103021239.GD9995@hostway.ca>; from sim@netnation.com on Fri, Jan 02, 2009 at 06:12:39PM -0800 References: <20081210000717.GA28487@hostway.ca> <20081209175505.A11693@chiba.halibut.com> <20090103021239.GD9995@hostway.ca> Message-ID: <20090102182100.A21076@chiba.halibut.com> On Fri, Jan 02, 2009 at 06:12:39PM -0800, Simon Kirby wrote: > Just to confirm, the client (which has the private key) supplies this > random 'k' variable, or does the server (running sshd) generate it? The 'k' value is provided by the entity producing the signature (i.e., the only entity with the private key), which for SSH user authentication is the client. (If the server could generate it for the client, then a malicious server could break the client's private key!) Josh From yaniv at aknin.name Mon Jan 5 21:12:04 2009 From: yaniv at aknin.name (Yaniv Aknin) Date: Mon, 5 Jan 2009 12:12:04 +0200 Subject: "Include" directive in ~/.ssh/config (reprise) Message-ID: <8FE979C8-D2E6-44A3-8F15-F02C1FF35B4C@aknin.name> Hi, About a year and a half ago, Hank Leininger posted a plea to this list for the inclusion of an Include directive in OpenSSH's configuration file. Hank's suggestion is detailed and thorough enough IMHO, so instead of repeating it I'll link it here http://marc.info/?l=openssh-unix-dev&m=118236823907002&w=2 . I'm also interested in this feature, and though my C skills aren't what they never used to be, I think this is well within the range of my ability to undertake, if people here have no objections. If I'll implement this feature, will it be integrated into the next release of OpenSSH? What's the process I should go through for that? Cheers, - Yaniv From richih.mailinglist at gmail.com Mon Jan 5 23:59:28 2009 From: richih.mailinglist at gmail.com (Richard Hartmann) Date: Mon, 5 Jan 2009 13:59:28 +0100 Subject: "Include" directive in ~/.ssh/config (reprise) In-Reply-To: <8FE979C8-D2E6-44A3-8F15-F02C1FF35B4C@aknin.name> References: <8FE979C8-D2E6-44A3-8F15-F02C1FF35B4C@aknin.name> Message-ID: <2d460de70901050459g53fea109g20e9ee68d474da44@mail.gmail.com> On Mon, Jan 5, 2009 at 11:12, Yaniv Aknin wrote: > If I'll implement this feature, will it be integrated into the next > release of OpenSSH? What's the process I should go through for that? I subscribed to this list yesterday so don't take this email as anything other than personal opinion, but I have been looking for just that feature recently. While I would not feel comfortable to apply third-party patches to something as central and important as OpenSSH, I would definitely use this feature if it made it into mainline. Hank Leininger made one important mistake in his example, though: OpenSSH resolves conflicts by looking at the last, not the first, config option. I.e. his localoverrides would need to come last. I might be a good idea to provide an authentication mechanism to the Include directive. The possible attack scenarios against a split-up Include files are a lot more and worse than if you had just /etc/whereever/ and ~/.ssh/ to care about. Richard From yanegomi at gmail.com Wed Jan 7 12:25:08 2009 From: yanegomi at gmail.com (Garrett Cooper) Date: Tue, 6 Jan 2009 17:25:08 -0800 Subject: Question about documentation for ConnectTimeout Message-ID: <364299f40901061725j70f7812fqf1b73b1b55603e12@mail.gmail.com> Hello OpenSSH folks, This was a really minor knit, but I noted while I was developing a pexpect module for ssh that setting ConnectTimeout to 0 in the options to ssh sets the login timeout to infinite time. I was wondering whether or not this was a documentation bug and/or potential clarification that could to be made, or if this was a software bug that needs to be fixed. I don't see much point behind infinite connect time, but then again, I'm just one end-user in a sea of many users. Thanks! -Garrett From dkg at fifthhorseman.net Wed Jan 7 13:03:27 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Tue, 06 Jan 2009 21:03:27 -0500 Subject: Question about documentation for ConnectTimeout In-Reply-To: <364299f40901061725j70f7812fqf1b73b1b55603e12@mail.gmail.com> References: <364299f40901061725j70f7812fqf1b73b1b55603e12@mail.gmail.com> Message-ID: <49640D6F.60101@fifthhorseman.net> On 01/06/2009 08:25 PM, Garrett Cooper wrote: > This was a really minor knit, but I noted while I was developing a > pexpect module for ssh that setting ConnectTimeout to 0 in the options > to ssh sets the login timeout to infinite time. > I was wondering whether or not this was a documentation bug and/or > potential clarification that could to be made, or if this was a > software bug that needs to be fixed. I don't see much point behind > infinite connect time, but then again, I'm just one end-user in a sea > of many users. I think the logic behind this choice is that while some people may reasonably want to never time out a connection, there is no one who would reasonably want to *always* have their connection time out (what "ConnectTimeout 0" would ordinarily imply). So since 0 is an effectively unused value for ConnectTimeout, it makes more sense to let people who want really long timeouts use have a clear way to specify it rather than expecting them to invent a fictitiously long (but arbitrary and unwanted) value, like "ConnectTimeout 99999". Another way to achieve the same thing would be to allow a special string (e.g. "ConnectTimeout never"), but it's easier for the config file parser to always expect a number, rather than having to deal with special cases. This all seems reasonable to me, anyway. I wasn't involved in the implementation. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20090106/c1646f5f/attachment.bin From dtucker at zip.com.au Wed Jan 7 14:32:21 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 07 Jan 2009 14:32:21 +1100 Subject: Question about documentation for ConnectTimeout In-Reply-To: <364299f40901061725j70f7812fqf1b73b1b55603e12@mail.gmail.com> References: <364299f40901061725j70f7812fqf1b73b1b55603e12@mail.gmail.com> Message-ID: <49642245.9000205@zip.com.au> Garrett Cooper wrote: > Hello OpenSSH folks, > This was a really minor knit, but I noted while I was developing a > pexpect module for ssh that setting ConnectTimeout to 0 in the options > to ssh sets the login timeout to infinite time. > I was wondering whether or not this was a documentation bug and/or > potential clarification that could to be made, or if this was a > software bug that needs to be fixed. I don't see much point behind > infinite connect time, but then again, I'm just one end-user in a sea > of many users. The code in question is in sshconnect.c:timeout_connect: if (*timeoutp <= 0) { result = connect(sockfd, serv_addr, addrlen); goto done; } so if ConnectTimeout=0 it doesn't explicitly make the timeout infinite, but merely falls back to whatever the operating system defaults to for connect(2). This should be constrained by the TCP maximum segment lifetime, and may be a couple of minutes (OpenBSD, for example, times out connects at 75 seconds, Linux at ~3 minutes). -- 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 jim at rfc1035.com Wed Jan 7 22:52:58 2009 From: jim at rfc1035.com (Jim Reid) Date: Wed, 7 Jan 2009 11:52:58 +0000 Subject: folding Apple tweaks into openssh Message-ID: <2CD77968-694E-4FC7-BC9D-6AA1D3164DE7@rfc1035.com> Hi. Apple have a bunch of patches to openssh that they have folded into the version that's shipped with MacOSX. Some of these are very convenient: like automagically starting an ssh-agent at login/boot time and the ability to have SSH passphrases stored and fetched from the Keychain. It would be nice if these could be considered for rolling in to a future release of openssh. FWIW the patches are at http://www.opensource.apple.com/darwinsource/10.5.6/OpenSSH-95.1.5/patches . As far as I'm aware they're open source and not encumbered by licensing nasties. From vgiffin at apple.com Thu Jan 8 05:42:24 2009 From: vgiffin at apple.com (Disco Vince Giffin) Date: Wed, 7 Jan 2009 10:42:24 -0800 Subject: folding Apple tweaks into openssh In-Reply-To: <2CD77968-694E-4FC7-BC9D-6AA1D3164DE7@rfc1035.com> References: <2CD77968-694E-4FC7-BC9D-6AA1D3164DE7@rfc1035.com> Message-ID: <6AD41813-230C-4946-B6B6-FAF88F4546BE@apple.com> Jim, Most of the Apple patches have been submitted (via https://bugzilla.mindrot.org/ ) and can be found by searching OpenSSH's Bugzilla. A number have been incorporated into the upstream OpenSSH. If there are any specific patches on Apple's open source site (http://www.opensource.apple.com ) that you feel should be taken into the upstream source, please comment in the corresponding Bugzilla bug. Thanks. - Disco Vince Giffin On Jan 7, 2009, at 3:52 AM, Jim Reid wrote: > Hi. Apple have a bunch of patches to openssh that they have folded > into the version that's shipped with MacOSX. Some of these are very > convenient: like automagically starting an ssh-agent at login/boot > time and the ability to have SSH passphrases stored and fetched from > the Keychain. It would be nice if these could be considered for > rolling in to a future release of openssh. > > FWIW the patches are at http://www.opensource.apple.com/darwinsource/10.5.6/OpenSSH-95.1.5/patches > . As far as I'm aware they're open source and not encumbered by > licensing nasties. > > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev From mouring at eviladmin.org Thu Jan 8 17:33:15 2009 From: mouring at eviladmin.org (Ben Lindstrom) Date: Thu, 8 Jan 2009 00:33:15 -0600 Subject: folding Apple tweaks into openssh In-Reply-To: <2CD77968-694E-4FC7-BC9D-6AA1D3164DE7@rfc1035.com> References: <2CD77968-694E-4FC7-BC9D-6AA1D3164DE7@rfc1035.com> Message-ID: <80EFCC0B-9C5E-4279-B048-4FEC3EA714DF@eviladmin.org> On Jan 7, 2009, at 5:52 AM, Jim Reid wrote: > Hi. Apple have a bunch of patches to openssh that they have folded > into the version that's shipped with MacOSX. Some of these are very > convenient: like automagically starting an ssh-agent at login/boot > time There is nothing to integrate for this. When you log in it starts "ssh-agent". I've done this for years under OpenBSD and Linux using gnome/kde. Apple just happens to do this via launchd instead of during X11 initrc scripts or other standard X startup processes (for good reason, since X isn't their GUI =). > and the ability to have SSH passphrases stored and fetched from > the Keychain. There is already 3rd party keychain software (e.g. http://www.sshkeychain.org/) . However, to me this more belongs with the OS provider (Redhat, Microsoft, SuSE, Apple, etc) than OpenSSH team. This is really more an integration issue than an OpenSSH issue. Apple's patches pretty much boil down to GSSAPI (which upstream version have been rejected due to complexity), launchd features (currently still very Apple centric), and Apple only patches. There are a few patches that would be interested to dig around to see why Apple applies them, but no real upstream features that would improve everyones' life. Interesting enough, not much has changed (other than Launchd) since the last time I looked at the patches. Just a bit less. - Ben From vgiffin at apple.com Fri Jan 9 03:55:05 2009 From: vgiffin at apple.com (Disco Vince Giffin) Date: Thu, 8 Jan 2009 08:55:05 -0800 Subject: folding Apple tweaks into openssh In-Reply-To: <80EFCC0B-9C5E-4279-B048-4FEC3EA714DF@eviladmin.org> References: <2CD77968-694E-4FC7-BC9D-6AA1D3164DE7@rfc1035.com> <80EFCC0B-9C5E-4279-B048-4FEC3EA714DF@eviladmin.org> Message-ID: <5E50C5D0-A90E-469D-BD30-6620AC1FDFA3@apple.com> Ben, > There are a few patches that would be interested to dig around to > see why Apple applies them If you have any questions (e.g. "What is this patch for?") about a specific patch, I'd be happy to answer them. - Disco Vince Giffin From will at ehawaii.gov Fri Jan 9 13:58:36 2009 From: will at ehawaii.gov (Will Johnston) Date: Thu, 08 Jan 2009 16:58:36 -1000 Subject: setting umask for internal-sftp users Message-ID: <4966BD5C.9070501@ehawaii.gov> I'm running OpenSSH 5.1p1 on openSUSE 10.3 (i586) and I want to setup chroot jails for certain SFTP-only users. I use the following lines in my sshd_config file: Match Group sftponly ChrootDirectory /home/chroot-%u ForceCommand internal-sftp It works great. The problem is that some of my users need umask 002 for their uploads. I tried a few ways to achieve this: * set umask in sshrc, .profile, etc... fails because no shell is used with internal-sftp * set the umask to 002 before launching sshd so the sftp server process will inherit it... fails because sshd resets umask to a minimum of 022 on startup (seems like a good idea) My solution was to add an option for internal-sftp that sets the umask. So, I can put this in my configuration: Match Group sftponly ChrootDirectory /home/chroot-%u ForceCommand internal-sftp -u 002 I've attached my patch. It's working with no problems for me. Please consider including this change or something similar in the next release. -- Will Johnston Hawaii Information Consortium, LLC -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: sftp-umask.patch Url: http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20090108/c5ef31cf/attachment-0001.ksh From samydelux at gmail.com Fri Jan 9 21:42:47 2009 From: samydelux at gmail.com (Samuel Vogel) Date: Fri, 09 Jan 2009 11:42:47 +0100 Subject: setting umask for internal-sftp users In-Reply-To: <4966BD5C.9070501@ehawaii.gov> References: <4966BD5C.9070501@ehawaii.gov> Message-ID: <49672A27.1000203@gmail.com> Will Johnston schrieb: > I'm running OpenSSH 5.1p1 on openSUSE 10.3 (i586) and I want to setup > chroot jails for certain SFTP-only users. I use the following lines > in my sshd_config file: > > Match Group sftponly > ChrootDirectory /home/chroot-%u > ForceCommand internal-sftp > > It works great. > > The problem is that some of my users need umask 002 for their > uploads. I tried a few ways to achieve this: > > * set umask in sshrc, .profile, etc... fails because no shell is used > with internal-sftp > > * set the umask to 002 before launching sshd so the sftp server > process will inherit it... > fails because sshd resets umask to a minimum of 022 on startup > (seems like a good idea) > > My solution was to add an option for internal-sftp that sets the > umask. So, I can put this in my configuration: > > Match Group sftponly > ChrootDirectory /home/chroot-%u > ForceCommand internal-sftp -u 002 > > I've attached my patch. It's working with no problems for me. > > Please consider including this change or something similar in the next > release. Hey, There also is the sftp file control patch, located here: http://sftpfilecontrol.sourceforge.net/ It also adds a configure parameter to the conf file, which lets you set the umask. In addition to that, you can forbid the use of chmod and chown for sftp connections. I really would like to see this integrated into openssh! Regards, Samy From dnaslave at gmail.com Fri Jan 16 16:03:46 2009 From: dnaslave at gmail.com (Danny Rice) Date: Fri, 16 Jan 2009 00:03:46 -0500 Subject: occasional ssh hang Message-ID: <49701532.60506@gmail.com> I am noticing the same problem with 'ssh host uptime' hanging. Did this ever get resolved? I am using OpenSSH on Redhat 6.2 (Intel) and Solaris 2.6 (Sparc). I have a job on the linux machine that ssh's to the Solaris machine every 20 seconds or so and runs uptime. The problem is that after many iterations of this, ssh will occasionally hang, and require a kill -9 to get rid of the process. The problem happens with both protocol version 1 and 2, but it seems to happened more often with version 2. I have noticed this problem with both 2.5.2p2 and 2.9p1. From djm at mindrot.org Fri Jan 16 21:20:21 2009 From: djm at mindrot.org (Damien Miller) Date: Fri, 16 Jan 2009 21:20:21 +1100 (EST) Subject: occasional ssh hang In-Reply-To: <49701532.60506@gmail.com> References: <49701532.60506@gmail.com> Message-ID: On Fri, 16 Jan 2009, Danny Rice wrote: > I am noticing the same problem with 'ssh host uptime' hanging. Did this ever get resolved? > > I am using OpenSSH on Redhat 6.2 (Intel) and Solaris 2.6 (Sparc). I have a > job on the linux machine that ssh's to the Solaris machine every 20 seconds > or so and runs uptime. The problem is that after many iterations of this, > ssh will occasionally hang, and require a kill -9 to get rid of the > process. The problem happens with both protocol version 1 and 2, but it > seems to happened more often with version 2. I have noticed this problem > with both 2.5.2p2 and 2.9p1. 2.5.2p2 -> 2001/03/22 2.9p1 -> 2001/04/29 Needless to say, there have been many bugfixes and improvements in the last eight years. Please try a recent version and see if you can reproduce the problem. -d From karlis.repsons at gmail.com Sat Jan 17 07:58:50 2009 From: karlis.repsons at gmail.com (=?utf-8?q?K=C4=81rlis_Repsons?=) Date: Fri, 16 Jan 2009 20:58:50 +0000 Subject: Bad ownership of /? Message-ID: <200901162058.50890.Karlis.Repsons@gmail.com> Hello, this is one more unfortunate case, when I run into problems with some non-standard configuration: if authorized keys file for user %u is /keys/%u or /keys/%u/.ssh/authorized_keys, I receive an error: sshd: Authentication refused: bad ownership or modes for directory / ! Whats the cure? I can't keep those files into /home easily... /Please let me know by cc to this mail address, because I am not subscribed/ k. From djm at mindrot.org Sat Jan 17 08:34:44 2009 From: djm at mindrot.org (Damien Miller) Date: Sat, 17 Jan 2009 08:34:44 +1100 (EST) Subject: Bad ownership of /? In-Reply-To: <200901162058.50890.Karlis.Repsons@gmail.com> References: <200901162058.50890.Karlis.Repsons@gmail.com> Message-ID: On Fri, 16 Jan 2009, K?rlis Repsons wrote: > Hello, > this is one more unfortunate case, when I run into problems with some > non-standard configuration: if authorized keys file for user %u is /keys/%u > or /keys/%u/.ssh/authorized_keys, I receive an error: > sshd: Authentication refused: bad ownership or modes for directory / > ! > > Whats the cure? I can't keep those files into /home easily... What *are* the permissions on /? From karlis.repsons at gmail.com Sat Jan 17 08:49:30 2009 From: karlis.repsons at gmail.com (=?utf-8?q?K=C4=81rlis_Repsons?=) Date: Fri, 16 Jan 2009 21:49:30 +0000 Subject: Bad ownership of /? In-Reply-To: References: <200901162058.50890.Karlis.Repsons@gmail.com> Message-ID: <200901162149.30409.Karlis.Repsons@gmail.com> On Friday 16 January 2009 21:34:44 you wrote: > On Fri, 16 Jan 2009, K?rlis Repsons wrote: > > Hello, > > this is one more unfortunate case, when I run into problems with some > > non-standard configuration: if authorized keys file for user %u is > > /keys/%u or /keys/%u/.ssh/authorized_keys, I receive an error: > > sshd: Authentication refused: bad ownership or modes for directory / > > ! > > > > Whats the cure? I can't keep those files into /home easily... > > What *are* the permissions on /? I should have taken it literally as it should be. My fault, I fixed. Sorry for a little "alert". Indeed I complained too soon. From dkg at fifthhorseman.net Sat Jan 17 08:20:08 2009 From: dkg at fifthhorseman.net (Daniel Kahn Gillmor) Date: Fri, 16 Jan 2009 16:20:08 -0500 Subject: Bad ownership of /? In-Reply-To: <200901162058.50890.Karlis.Repsons@gmail.com> References: <200901162058.50890.Karlis.Repsons@gmail.com> Message-ID: <4970FA08.4090506@fifthhorseman.net> Hi K?rlis -- On 01/16/2009 03:58 PM, K?rlis Repsons wrote: > this is one more unfortunate case, when I run into problems with some > non-standard configuration: if authorized keys file for user %u is /keys/%u > or /keys/%u/.ssh/authorized_keys, I receive an error: > sshd: Authentication refused: bad ownership or modes for directory / > ! > > Whats the cure? I can't keep those files into /home easily... > > /Please let me know by cc to this mail address, because I am not subscribed/ This sounds like a serious problem, but likely not ssh related. It's possible that the way your filesystem is set up makes it vulnerable to some pretty serious attacks by local users. Can you show the output of: ls -ld / That should show the ownership and permissions on the root of the filesystem, which is what sshd is complaining about. --dkg -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 890 bytes Desc: OpenPGP digital signature Url : http://lists.mindrot.org/pipermail/openssh-unix-dev/attachments/20090116/544849a2/attachment.bin From bruce.korb at gmail.com Mon Jan 19 10:05:20 2009 From: bruce.korb at gmail.com (Bruce Korb) Date: Sun, 18 Jan 2009 15:05:20 -0800 Subject: ssh tunneling suite Message-ID: <4973B5B0.40008@gmail.com> Hi, Over the past few years, I've needed to establish a robust tunnel from work to home, trying to make it as secure as I can. Ultimately, I wound up developing three programs of varying complexity. Basically, every time I learned some new thing that made it work better either for the sake of security or robustness, I glued it into this stuff. It took too much work and research to get all the parameters to play nice. Anyway, I'm offering it ups under a BSD license so it can be improved and so I don't have to maintain it just for myself. The three things are: 1. a daemon on the server that keeps trying to connect to a remote node/work station. It must invoke ssh with all those strange parameters to establish the tunnel. 2. a wont-do-anything-at-all login shell for the only user allowed to login on the work station. It parses it's "command" (the argument after the "-c") as some options, including a host name and port number. It journals its activities in /var/log/noopsh and creates a file in /var/run/noopsh/${hostname} containing the port number. This file is removed "atexit(3C)". 3. The tssh program (Tunneled-Secure-SHell) that resolves the host argument by looking for it in /var/run/noopsh and getting the correct port number from that file. Had I had such a thing, it would have saved me a lot of research and futzing around. So, if you-all have a place for such an addon, I'll polish it a bit and send it along. Cheers - Bruce p.s. they all come with man pages. From peter at stuge.se Mon Jan 19 11:38:05 2009 From: peter at stuge.se (Peter Stuge) Date: Mon, 19 Jan 2009 01:38:05 +0100 Subject: ssh tunneling suite In-Reply-To: <4973B5B0.40008@gmail.com> References: <4973B5B0.40008@gmail.com> Message-ID: <20090119003805.3263.qmail@stuge.se> Bruce Korb wrote: > The three things are: With the single drawback of being a distinct piece of software, OpenVPN takes care of all of that for you. //Peter From karthispeaks at gmail.com Tue Jan 20 04:42:30 2009 From: karthispeaks at gmail.com (karthikeyan S) Date: Mon, 19 Jan 2009 23:12:30 +0530 Subject: Bug CVE-2005-2797 Message-ID: <3bedf6ab0901190942t4dfe7324mbe064608c0a5b361@mail.gmail.com> Hi Everyone, I am using openssh 4.0 in a product, which is affected by CVE-2005-2797 (If DynamicForward option is activated, GatewayPorts is also unconditionally enabled). I am trying to backport the fix for this from 4.2 to 4.0. I have been finding the difference between 4.2 and 4.1 and the only change that looks relevant to this bug, to me is the changes made in the file readconf.c with the following change +fwd.listen_host = NULL; -fwd.listen_host = ""; Could you please tell me if this was indeed the fix made for this bug? Or if there is a patch for this, could you please point me that patch? Thanks in advance. -karthik From dtucker at zip.com.au Tue Jan 20 16:55:16 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Tue, 20 Jan 2009 16:55:16 +1100 Subject: Bug CVE-2005-2797 In-Reply-To: <3bedf6ab0901190942t4dfe7324mbe064608c0a5b361@mail.gmail.com> References: <3bedf6ab0901190942t4dfe7324mbe064608c0a5b361@mail.gmail.com> Message-ID: <49756744.6070500@zip.com.au> karthikeyan S wrote: > Hi Everyone, > > I am using openssh 4.0 in a product, which is affected by > CVE-2005-2797 (If DynamicForward option is activated, GatewayPorts is > also unconditionally enabled). I am trying to backport the fix for > this from 4.2 to 4.0. I have been finding the difference between 4.2 > and 4.1 and the only change that looks relevant to this bug, to me is > the changes made in the file readconf.c with the following change > > +fwd.listen_host = NULL; > -fwd.listen_host = ""; > > Could you please tell me if this was indeed the fix made for this bug? > Or if there is a patch for this, could you please point me that patch? > Thanks in advance. It was a while back but from the cvs history it looks like it was ssh.c rev 1.235 and readconf.c rev 1.118. http://anoncvs.mindrot.org/index.cgi/openssh/ssh.c?r1=1.234&r2=1.235 http://anoncvs.mindrot.org/index.cgi/openssh/readconf.c?r1=1.117&r2=1.118 -- 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 jmknoble at pobox.com Tue Jan 20 17:06:35 2009 From: jmknoble at pobox.com (Jim Knoble) Date: Tue, 20 Jan 2009 01:06:35 -0500 Subject: OpenSSH private key encryption: time for AES? Message-ID: <20090120060635.GA29074@crawfish.ais.com> Hi, all. So, in reviewing my OpenSSH keypairs and evaluating the size my RSA keys should be, i realized that, if i update my 2048-bit keypairs to 4096 bits, it really doesn't matter that much, because they're still only encrypted with 3DES, which provides an effective 112 bits of symmetric encryption strength: $ head -4 ~/.ssh/id_rsa -----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: DES-EDE3-CBC,XXXXXXXXXXXXXXXX $ According to NIST[1][2], a minimum of 112-bit symmetric / 2048-bit asymmetric keystrength is recommended for protection up until about 2030. For protection beyond 2030, or for the paranoid, larger keysizes are recommended. Other recommendations (e.g., those of ECRYPT) vary in how long 112/2048-bit encryption should last. With that in mind ... how can i encrypt my 4096-bit SSH RSA keypair with something like AES-128, AES-256, or Twofish instead of 3DES and still use it with OpenSSH? Can ssh-add read (unencrypted) key data from stdin? ____________________ [1] http://csrc.nist.gov/groups/ST/toolkit/key_management.html [2] http://csrc.nist.gov/groups/ST/toolkit/documents/SP800-57Part1_3-8-07.pdf -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: C6F31FFA >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA) +----------------------------------------------------------------------+ |[L]iberty, as we all know, cannot flourish in a country that is perma-| | nently on a war footing, or even a near-war footing. --Aldous Huxley| +----------------------------------------------------------------------+ From djm at mindrot.org Tue Jan 20 18:30:23 2009 From: djm at mindrot.org (Damien Miller) Date: Tue, 20 Jan 2009 18:30:23 +1100 (EST) Subject: OpenSSH private key encryption: time for AES? In-Reply-To: <20090120060635.GA29074@crawfish.ais.com> References: <20090120060635.GA29074@crawfish.ais.com> Message-ID: On Tue, 20 Jan 2009, Jim Knoble wrote: > Hi, all. > > So, in reviewing my OpenSSH keypairs and evaluating the size my RSA keys > should be, i realized that, if i update my 2048-bit keypairs to 4096 > bits, it really doesn't matter that much, because they're still > only encrypted with 3DES, which provides an effective 112 bits of > symmetric encryption strength: > > $ head -4 ~/.ssh/id_rsa > -----BEGIN RSA PRIVATE KEY----- > Proc-Type: 4,ENCRYPTED > DEK-Info: DES-EDE3-CBC,XXXXXXXXXXXXXXXX > > $ > > According to NIST[1][2], a minimum of 112-bit symmetric / 2048-bit > asymmetric keystrength is recommended for protection up until about > 2030. For protection beyond 2030, or for the paranoid, larger keysizes > are recommended. Other recommendations (e.g., those of ECRYPT) vary in > how long 112/2048-bit encryption should last. > > With that in mind ... how can i encrypt my 4096-bit SSH RSA keypair with > something like AES-128, AES-256, or Twofish instead of 3DES and still > use it with OpenSSH? Can ssh-add read (unencrypted) key data from stdin? If you want to change it then you can do something like this. It probably wouldn't hurt to change - new installations will still be able to read old keys Index: authfile.c =================================================================== RCS file: /cvs/src/usr.bin/ssh/authfile.c,v retrieving revision 1.76 diff -u -p -r1.76 authfile.c --- authfile.c 3 Aug 2006 03:34:41 -0000 1.76 +++ authfile.c 20 Jan 2009 07:22:48 -0000 @@ -182,7 +182,7 @@ key_save_private_pem(Key *key, const cha int success = 0; int len = strlen(_passphrase); u_char *passphrase = (len > 0) ? (u_char *)_passphrase : NULL; - const EVP_CIPHER *cipher = (len > 0) ? EVP_des_ede3_cbc() : NULL; + const EVP_CIPHER *cipher = (len > 0) ? EVP_aes_256_cbc() : NULL; if (len > 0 && len <= 4) { error("passphrase too short: have %d bytes, need > 4", len); From rbachwan at eden.rutgers.edu Tue Jan 20 21:34:00 2009 From: rbachwan at eden.rutgers.edu (Rekha Bachwani) Date: Tue, 20 Jan 2009 05:34:00 -0500 Subject: access to buggy openssh-3.x Message-ID: <4975A898.7040701@eden.rutgers.edu> Hi, I wanted to have access to the openssh-3.x source in which the bugs were reported. For instance, one of the problems reported in openssh-3.1 was *Bug 182* - ssh should still force SIGCHLD to be SIG_DFL when calling ssh-rand-helper When I download openssh-3.1p1, I see the bug fixed. I would like to reproduce some of the old openssh bugs (for my research), and therefore, need access to the source which actually had bugs or atleast against which the bugs were reported. Does anyone know how to get access to such an code? thanks, Rekha From djm at mindrot.org Tue Jan 20 22:55:36 2009 From: djm at mindrot.org (Damien Miller) Date: Tue, 20 Jan 2009 22:55:36 +1100 (EST) Subject: access to buggy openssh-3.x In-Reply-To: <4975A898.7040701@eden.rutgers.edu> References: <4975A898.7040701@eden.rutgers.edu> Message-ID: On Tue, 20 Jan 2009, Rekha Bachwani wrote: > Hi, > > I wanted to have access to the openssh-3.x source in which > the bugs were reported. For instance, one of the problems > reported in openssh-3.1 was > *Bug 182* - ssh > should still force SIGCHLD to be SIG_DFL when calling ssh-rand-helper > > When I download openssh-3.1p1, I see the bug fixed. I would > like to reproduce some of the old openssh bugs (for my research), > and therefore, need access to the source which actually had > bugs or atleast against which the bugs were reported. > > Does anyone know how to get access to such an code? You didn't say where you are downloading OpenSSH from. ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH and ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable are the canonical locations. That particular bug is not fixed in ftp://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-3.1p1.tar.gz (I just checked) so I'm not sure what you are looking at. Also, the entire project history is in CVS with releases tagged and branched, for example: cvs -d anoncvs at anoncvs.mindrot.org:/cvs rdiff \ -r V_3_1_P1 -r V_3_2_2_P1 openssh/entropy.c Clearly show the fix (along with an unrelated one). -d From vinschen at redhat.com Tue Jan 20 21:55:26 2009 From: vinschen at redhat.com (Corinna Vinschen) Date: Tue, 20 Jan 2009 11:55:26 +0100 Subject: access to buggy openssh-3.x In-Reply-To: <4975A898.7040701@eden.rutgers.edu> References: <4975A898.7040701@eden.rutgers.edu> Message-ID: <20090120105526.GA20104@calimero.vinschen.de> On Jan 20 05:34, Rekha Bachwani wrote: > Hi, > > I wanted to have access to the openssh-3.x source in which > the bugs were reported. For instance, one of the problems > reported in openssh-3.1 was > *Bug 182* - ssh > should still force SIGCHLD to be SIG_DFL when calling ssh-rand-helper > > When I download openssh-3.1p1, I see the bug fixed. I would > like to reproduce some of the old openssh bugs (for my research), > and therefore, need access to the source which actually had > bugs or atleast against which the bugs were reported. > > Does anyone know how to get access to such an code? CVS, see http://www.openssh.com/portable.html Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From jmknoble at pobox.com Wed Jan 21 12:42:38 2009 From: jmknoble at pobox.com (Jim Knoble) Date: Tue, 20 Jan 2009 20:42:38 -0500 Subject: OpenSSH private key encryption: time for AES? In-Reply-To: References: <20090120060635.GA29074@crawfish.ais.com> Message-ID: <20090121014237.GD29074@crawfish.ais.com> Circa 2009-01-20 02:30 dixit Damien Miller: : On Tue, 20 Jan 2009, Jim Knoble wrote: : : > [...]how can i encrypt my 4096-bit SSH RSA keypair with : > something like AES-128, AES-256, or Twofish instead of 3DES and still : > use it with OpenSSH? Can ssh-add read (unencrypted) key data from stdin? Experimentation has shown that the following will add a key to a running ssh-agent (OpenSSH_4.6p1, Ubuntu 7.10): $ cat id_rsa-unencrypted |ssh-add /dev/stdin $ ssh-add -l |fgrep /dev/stdin 2048 xx:xx:xx:...:xx:xx:xx /dev/stdin (RSA) $ However, the following will not remove the key from the agent: $ cat id_rsa-unencrypted |ssh-add -d /dev/stdin Bad key file /dev/stdin $ If both operations worked, then one could use an external encryption/decryption facility with one's private keys, e.g.: openssl enc -d -in ~/.ssh/id_rsa -aes-256-cbc |ssh-add /dev/stdin (although it would take a passphrase to remove a key from ssh-agent). : If you want to change it then you can do something like [a one-liner : change to authfile.c]. It probably wouldn't hurt to change - new : installations will still be able to read old keys It would be nice for newer OpenSSH to be able to produce private keys usable by older OpenSSH as well. Any chance of an option in ssh-keygen to specify the cipher? E.g.: # Use '-E' with any of: 3des-cbc, aes128-cbc, aes192-cbc, aes256-cbc ssh-keygen -t rsa -E aes256-cbc Alternatively: # Encrypt with AES-256: ssh-keygen -t rsa -A # Encrypt with 3DES: ssh-keygen -t rsa -3 # Use default encryption: ssh-keygen -t rsa Finally: # Encrypt with AES-256: ssh-keygen -t rsa # Encrypt with 3DES ('-O' for "old"): ssh-keygen -t rsa -O:1 Cheers, jim -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: C6F31FFA >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA) +----------------------------------------------------------------------+ |[L]iberty, as we all know, cannot flourish in a country that is perma-| | nently on a war footing, or even a near-war footing. --Aldous Huxley| +----------------------------------------------------------------------+ From peter at stuge.se Wed Jan 21 13:23:22 2009 From: peter at stuge.se (Peter Stuge) Date: Wed, 21 Jan 2009 03:23:22 +0100 Subject: OpenSSH private key encryption: time for AES? In-Reply-To: <20090121014237.GD29074@crawfish.ais.com> References: <20090120060635.GA29074@crawfish.ais.com> <20090121014237.GD29074@crawfish.ais.com> Message-ID: <20090121022323.26324.qmail@stuge.se> Jim Knoble wrote: > Alternatively: > > # Encrypt with AES-256: > ssh-keygen -t rsa -A > > # Encrypt with 3DES: > ssh-keygen -t rsa -3 > > # Use default encryption: > ssh-keygen -t rsa > > Finally: > > # Encrypt with AES-256: > ssh-keygen -t rsa > > # Encrypt with 3DES ('-O' for "old"): > ssh-keygen -t rsa -O:1 I like both these ideas. //Peter From djm at mindrot.org Wed Jan 21 15:16:31 2009 From: djm at mindrot.org (Damien Miller) Date: Wed, 21 Jan 2009 15:16:31 +1100 (EST) Subject: OpenSSH private key encryption: time for AES? In-Reply-To: <20090121014237.GD29074@crawfish.ais.com> References: <20090120060635.GA29074@crawfish.ais.com> <20090121014237.GD29074@crawfish.ais.com> Message-ID: On Tue, 20 Jan 2009, Jim Knoble wrote: > Circa 2009-01-20 02:30 dixit Damien Miller: > > : On Tue, 20 Jan 2009, Jim Knoble wrote: > : > : > [...]how can i encrypt my 4096-bit SSH RSA keypair with > : > something like AES-128, AES-256, or Twofish instead of 3DES and still > : > use it with OpenSSH? Can ssh-add read (unencrypted) key data from stdin? > > Experimentation has shown that the following will add a key to a running > ssh-agent (OpenSSH_4.6p1, Ubuntu 7.10): > > $ cat id_rsa-unencrypted |ssh-add /dev/stdin > $ ssh-add -l |fgrep /dev/stdin > 2048 xx:xx:xx:...:xx:xx:xx /dev/stdin (RSA) > $ > > However, the following will not remove the key from the agent: > > $ cat id_rsa-unencrypted |ssh-add -d /dev/stdin > Bad key file /dev/stdin > $ Does that work without the patch? I don't think it would even with the current cipher because it needs to reread the file IIRC. > If both operations worked, then one could use an external > encryption/decryption facility with one's private keys, e.g.: > > openssl enc -d -in ~/.ssh/id_rsa -aes-256-cbc |ssh-add /dev/stdin > > (although it would take a passphrase to remove a key from ssh-agent). Wouldn't this just require the former to work? You'd be passing keys to ssh-agent in unencrypted form always, no? > : If you want to change it then you can do something like [a one-liner > : change to authfile.c]. It probably wouldn't hurt to change - new > : installations will still be able to read old keys > > It would be nice for newer OpenSSH to be able to produce private keys > usable by older OpenSSH as well. The key encryption for SSH protocol 2 keys is done by OpenSSL's PEM functions, so AES should be supported by any OpenSSL version that supports AES in PEM. IIRC this has been supported for a number of years. > Any chance of an option in ssh-keygen to specify the cipher? E.g.: No, I think that would be a microknob that add little value, and ssh-add has waaaay to many buttons already. If we change then it should be to the best encryption that is supported by widely deployed SSL/OpenSSH versions. -d From dtucker at zip.com.au Wed Jan 21 15:39:40 2009 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 21 Jan 2009 15:39:40 +1100 Subject: OpenSSH private key encryption: time for AES? In-Reply-To: References: <20090120060635.GA29074@crawfish.ais.com> <20090121014237.GD29074@crawfish.ais.com> Message-ID: <4976A70C.2020305@zip.com.au> Damien Miller wrote: [...] > If we change then it should be to the best encryption that is supported by > widely deployed SSL/OpenSSH versions. Don't forget some versions of the Solaris 10 OpenSSL package cripple all ciphers with a key length >128 bits. We work around that for the SSH ciphers but that's not going to help for the OpenSSL PEM functions. -- 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 Wed Jan 21 16:01:35 2009 From: djm at mindrot.org (Damien Miller) Date: Wed, 21 Jan 2009 16:01:35 +1100 (EST) Subject: OpenSSH private key encryption: time for AES? In-Reply-To: <4976A70C.2020305@zip.com.au> References: <20090120060635.GA29074@crawfish.ais.com> <20090121014237.GD29074@crawfish.ais.com> <4976A70C.2020305@zip.com.au> Message-ID: On Wed, 21 Jan 2009, Darren Tucker wrote: > Damien Miller wrote: > [...] > > If we change then it should be to the best encryption that is supported by > > widely deployed SSL/OpenSSH versions. > > Don't forget some versions of the Solaris 10 OpenSSL package cripple all > ciphers with a key length >128 bits. We work around that for the SSH > ciphers but that's not going to help for the OpenSSL PEM functions. Shouldn't this Just Work with our replacement EVP_aes_256_cbc in cipher-aes.c? We already switch it on for the OPENSSL_LOBOTOMISED_AES case (Obviously it would need to be tested...) -d From grarpamp at gmail.com Thu Jan 22 11:46:23 2009 From: grarpamp at gmail.com (grarpamp) Date: Wed, 21 Jan 2009 19:46:23 -0500 Subject: Unintended key info disclosure via ForwardAgent? Message-ID: It seems that users may be disclosing unintended public key info when logging into remote hosts. Use of the words keypair/keyid/etc have been bastardized. Signature is likely better. Note also, the author may be without clue. Setup: [g] - refers to an administrative group of hosts [n] - refers to a host within that group ws[g][n] - management workstations [trusted] User ssh-add's keys for all local and remote host groups. ~/.ssh/config: Host locala* ForwardAgent yes IdentityFile ~/.ssh/id_dsa_locala Host remotea* IdentityFile ~/.ssh/id_dsa_remotea Host remoteb* IdentityFile ~/.ssh/id_dsa_remoteb ... Host * ForwardAgent no IdentitiesOnly yes local[g][n] - local hosts [generally trusted] ssh[d]_config are the installed default, ~/.ssh/config doesn't exist. Access is via ~/.ssh/authorized_keys only. remote[g][n] - remote internet hosts [generally untrusted] ssh[d]_config are the installed default, ~/.ssh/config doesn't exist. Access is via ~/.ssh/authorized_keys only. Policy prevents keypairs sitting on the disks of any host except for ws[g][n]. Therefore, they are not there to be selectable with: IdentityFile and IdentitiesOnly However, they are loaded in ws[g][n]'s agent. So hopping around like this works fine because ForwardAgent is set by default everywhere: wsa1 -> locala1 -> locala2 -> locala3 wsa1 -> remotea1 -> remotea2 -> remotea3 Assume for this instance that ForwardAgent was indeed set for remotea* in the above config. If the IdentityFile and IdentitiesOnly options above are not set for a host, keys are tested against the host in the order they are listed in ssh-add -l, starting from the top, until one key works. Here's the problem. If the keys are loaded in the following order: remotea locala remoteb remotec And the following login path is used: wsa1 -> locala1 locala1 has no knowledge of an attempt with remotea's keypair against locala1 because wsa[g][n] have their IdentityFile and IdentitiesOnly options set to present only the locala keypair to locala1. No problem. Similarly for the path: wsa1 -> remoteb1 The IdentityFile and IdentitiesOnly options restrict key presentation to remoteb1 to be the remoteb keypair. No problem. However, when using this login path: wsa1 -> locala1 -> remoteb1 The log below brings the idea that we have key info about remotea and locala being disclosed to remoteb1. Namely, failed attempts with the remotea and locala keypairs against remoteb1. ## from locala1 # client tries the first key against remoteb1 client debug1: Offering public key: .ssh/id_dsa_remotea server debug3: mm_answer_keyallowed: key_from_blob: 0x81db150 server debug3: mm_answer_keyallowed: key 0x81db150 is not allowed # client tries the second key against remoteb1 client debug1: Offering public key: .ssh/id_dsa_locala server debug3: mm_answer_keyallowed: key_from_blob: 0x81db170 server debug3: mm_answer_keyallowed: key 0x81db170 is not allowed Now, assuming that the server operator chooses to look only at what keys are coming in, their order and their quantity... there are a few levels of badness with this: 1 - Each attempt carries a unique key id with it. So long as at least one keypair failed, if any of the host groups are in communication with each other, they will know that the same user [or a user possessing the same key] is accessing their respective systems. 2 - The order in which keys are presented for testing may be viewed as a signature. 3 - The number of keys loaded [or failed key attempts before success] may be viewed as the signature of a particular user. Particularly of those users carrying many keys. 4 - Combining the first three items into a set provides a stronger signature for a given user. Ultimately, it would be better to have a way to specify which keys [by fingerprint] from the agent are to be forwarded over the connection to which hosts. Similar to how IdentityFile and IdentitiesOnly work for actually logging into each host. It may be that the user wishes this path to work: wsa1 -> locala1 -> remotea1 but not this path: wsa1 -> remotea1 -> locala1 by managing only agent identites as forwarded from wsa1. So the suggested solution is to add the following config options... ForwardAgent yes/no - Preserve the current function. All or no agent keys are forwarded. ForwardAgentDefault include/exclude - Set the sense of ForwardAgentFP. Useful if an agent has many keys loaded. Defaults to exclude. Alternatively, ForwardAgent's yes/no may be used for this: ForwardAgent yes -> ForwardAgentFP's are excluded. ForwardAgent no -> ForwardAgentFP's are included. ForwardAgentFP fp1 - include/exclude this one ForwardAgentFP fp2 - include/exclude this one This may mean that the host a user came from would deny use of that key, as if it were not loaded. Ref: the caution about this in ssh_config(1) ForwardAgent. Perhaps a form of separate agent instance would be created on the client based on the config stanza of the host being logged into. It may also be useful to add LoginAgent* options that work similarly to how IdentityFile and IdentitiesOnly work with files. For use when only agent keys are available as above [no file keys]. For example... once you've logged into a remote host [bringing with you access to a forwarded set of keys], select from those available which ones are to be used for the next hop. They would work, and be named, like ForwardAgent*. Note that the client host may not have keyfiles available. Either because they don't exist as per policy above or in an agent only environment. Along with mount/unmount, there is: ssh-agent -a ssh-add chroot SSH_AUTH_* variables From a28427 at ua.pt Fri Jan 23 04:32:28 2009 From: a28427 at ua.pt (Tiago Marques) Date: Thu, 22 Jan 2009 17:32:28 +0000 Subject: reverse mapping checking getaddrinfo failed - POSSIBLE BREAK-IN Message-ID: Hi, This is the full message that i'm getting: reverse mapping checking getaddrinfo for ***.***.***.*** failed - POSSIBLE BREAK-IN ATTEMPT I've searched google but didn't found any good answer about this. What exactly is happening? Best regards, Tiago Marques From cmadams at hiwaay.net Fri Jan 23 06:01:50 2009 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 22 Jan 2009 13:01:50 -0600 Subject: reverse mapping checking getaddrinfo failed - POSSIBLE BREAK-IN In-Reply-To: References: Message-ID: <20090122190150.GE1435149@hiwaay.net> Once upon a time, Tiago Marques said: > This is the full message that i'm getting: > > reverse mapping checking getaddrinfo for ***.***.***.*** failed - POSSIBLE > BREAK-IN ATTEMPT > > I've searched google but didn't found any good answer about this. What > exactly is happening? Your sshd was built with tcp_wrappers, which checks for matching forward and reverse DNS (and the connecting IP has reverse DNS that does not resolve in forward DNS). It is really mostly a nuisance message. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From jmknoble at pobox.com Fri Jan 23 06:49:01 2009 From: jmknoble at pobox.com (Jim Knoble) Date: Thu, 22 Jan 2009 14:49:01 -0500 Subject: OpenSSH private key encryption: time for AES? In-Reply-To: References: <20090120060635.GA29074@crawfish.ais.com> <20090121014237.GD29074@crawfish.ais.com> Message-ID: <20090122194901.GB22282@crawfish.ais.com> Circa 2009-01-20 23:16 dixit Damien Miller: : On Tue, 20 Jan 2009, Jim Knoble wrote: : : > $ cat id_rsa-unencrypted |ssh-add /dev/stdin : > $ ssh-add -l |fgrep /dev/stdin : > 2048 xx:xx:xx:...:xx:xx:xx /dev/stdin (RSA) : > $ : : Does that work without the patch? I don't think it would even with : the current cipher because it needs to reread the file IIRC. It's an unpatched ssh-keygen (OpenSSH_4.6p1 Debian-5ubuntu0.6, OpenSSL 0.9.8e 23 Feb 2007). : > If both operations worked, then one could use an external : > encryption/decryption facility with one's private keys, e.g.: : > : > openssl enc -d -in ~/.ssh/id_rsa -aes-256-cbc |ssh-add /dev/stdin : > : > (although it would take a passphrase to remove a key from ssh-agent). : : Wouldn't this just require the former to work? You'd be passing keys : to ssh-agent in unencrypted form always, no? Not sure i understand. The only decryption would happen in the 'openssl | ssh-add' pipeline. In order to know which key to remove, ssh-add would need to read the unencrypted key, which would only be available by decrypting it in the pipeline, supplying a passphrase to the 'openssl' command. Currently, 'ssh-add -d' doesn't require a passphrase for an OpenSSH-encrypted private key. I like the flexibility of being able to use stdin with ssh-add (and i would prefer 'ssh-add -' rather than 'ssh-add /dev/stdin', but whatever). However, all the above may be moot in light of the discussion further below. : The key encryption for SSH protocol 2 keys is done by OpenSSL's PEM : functions, so AES should be supported by any OpenSSL version that supports : AES in PEM. IIRC this has been supported for a number of years. If older OpenSSH (to a point) would "just work" reading private keys encrypted with AES-256, then that's fantastic, and no need for any further options to ssh-keygen. : If we change then it should be to the best encryption that is supported by : widely deployed SSL/OpenSSH versions. Agreed. Private keys are short, and even if decryption happens frequently, it takes much longer to enter a passphrase than to decrypt the key (and both decryption and passphrase can be mitigated via ssh-agent). -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: C6F31FFA >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA) +----------------------------------------------------------------------+ |[L]iberty, as we all know, cannot flourish in a country that is perma-| | nently on a war footing, or even a near-war footing. --Aldous Huxley| +----------------------------------------------------------------------+ From jmknoble at pobox.com Fri Jan 23 07:59:26 2009 From: jmknoble at pobox.com (Jim Knoble) Date: Thu, 22 Jan 2009 15:59:26 -0500 Subject: OpenSSH private key encryption: time for AES? In-Reply-To: <20090122194901.GB22282@crawfish.ais.com> References: <20090120060635.GA29074@crawfish.ais.com> <20090121014237.GD29074@crawfish.ais.com> <20090122194901.GB22282@crawfish.ais.com> Message-ID: <20090122205926.GC22282@crawfish.ais.com> Circa 2009-01-22 14:49 dixit Jim Knoble: : Circa 2009-01-20 23:16 dixit Damien Miller: : : The key encryption for SSH protocol 2 keys is done by OpenSSL's PEM : : functions, so AES should be supported by any OpenSSL version that supports : : AES in PEM. IIRC this has been supported for a number of years. : : If older OpenSSH (to a point) would "just work" reading private keys : encrypted with AES-256, then that's fantastic, and no need for any : further options to ssh-keygen. : : : If we change then it should be to the best encryption that is supported by : : widely deployed SSL/OpenSSH versions. : : Agreed. Private keys are short, and even if decryption happens : frequently, it takes much longer to enter a passphrase than to decrypt : the key (and both decryption and passphrase can be mitigated via : ssh-agent). I've moved this into Bugzilla bug #1550 for tracking, including Darren's comments about Solaris 10 and OpenSSL keylength limitations. -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: C6F31FFA >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA) +----------------------------------------------------------------------+ |[L]iberty, as we all know, cannot flourish in a country that is perma-| | nently on a war footing, or even a near-war footing. --Aldous Huxley| +----------------------------------------------------------------------+ From swatkins at fastmail.fm Fri Jan 23 20:05:33 2009 From: swatkins at fastmail.fm (Sam Watkins) Date: Fri, 23 Jan 2009 17:05:33 +0800 Subject: sshd exponential backoff patch Message-ID: <1232701533.29828.1296322611@webmail.messagingengine.com> hi, I wrote a patch to openssh sshd.c which enables "exponential backoff", so that an attacker cannot brute force your password by making hundreds of login attempts. here is the code: http://sam.nipl.net/sshd-backoff/ An attacker who fails to login is locked out (by IP address) for 1 minute, and the lockout period doubles for each failed login after that. Normally three logins are allowed before an ssh connection is terminated. This patch is "beta" software and might lock you out of your sshd, so be careful and make sure you are prepared for that. You can "test" the patch by attempting to break in to this server, nipl.net ssh is running on port 22 The patch creates and uses a db-4 database in /var/lib/ssh/backoff.db I think my code is written carefully, but it might have some bugs. Also I think this problem might be better solved outside of sshd (maybe in pam). I'd be very grateful for any constructive feedback. Thanks! Sam ( I wrote a similar hack in shell-script a while ago, to prevent pppd running up a huge phone bill in that case that a dialup connection fails. ) From kaizaad at sharcnet.ca Sat Jan 24 01:20:01 2009 From: kaizaad at sharcnet.ca (Kaizaad Bilimorya) Date: Fri, 23 Jan 2009 09:20:01 -0500 (EST) Subject: 5.0 vs 5.1 remote command execution In-Reply-To: References: Message-ID: For reference: An explanation of this behaviour. https://bugzilla.mindrot.org/show_bug.cgi?id=1549 -k On Fri, 19 Dec 2008, Kaizaad Bilimorya wrote: > Anybody have any ideas on how to revert to the 5.0p1 behaviour? > > On Thu, 11 Dec 2008, Kaizaad Bilimorya wrote: >> Hello, >> >> I am experiencing some strange behaviour that I am hoping someone can >> shed some light on. >> >> OS and kernel: >> Red Hat Enterprise Linux AS release 4 (Nahant Update 5) >> Linux host135 2.6.9-67.9hp.7sp.XCsmp #1 SMP Thu Jul 3 18:55:59 EDT 2008 x86_64 x86_64 x86_64 GNU/Linux >> >> >> built both openssh-5.0p1 and openssh-5.1p1 with the following options: >> ./configure --prefix=/usr --libexecdir=/usr/libexec/openssh --localstatedir=/var/empty/sshd \ >> --sysconfdir=/etc/ssh --with-pam --with-md5-passwords --with-zlib=/home/XXX/software/zlib-1.2.3 \ >> --with-tcp-wrappers >> >> >> With everything else being identical and just swapping the sshd binaries, >> I noticed the following: >> >> # ssh -v host135 >> debug1: match: OpenSSH_5.0 pat OpenSSH* >> ...snip >> # ssh host135 'echo $PATH' >> /opt/octave/current:/opt/mpiblast/current/bin:/opt/lammps/current/bin:/opt/dlpoly/current/execute: >> ...snip >> >> # ssh -v host135 >> debug1: match: OpenSSH_5.1 pat OpenSSH* >> ...snip >> # ssh host135 'echo $PATH' >> /usr/bin:/bin:/usr/sbin:/sbin >> >> >> According to the docs, the behaviour exhibited by v5.1 is correct, remote >> command execution should not process the user's login shell and env. But >> why was this happening in v5.0? I can't find anything in the 5.1 change >> log that explains this change in behaviour. >> >> thanks >> -k >> _______________________________________________ >> openssh-unix-dev mailing list >> openssh-unix-dev at mindrot.org >> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev >> > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From rob at nofocus.org Sat Jan 24 03:32:20 2009 From: rob at nofocus.org (Robert Banz) Date: Fri, 23 Jan 2009 08:32:20 -0800 Subject: sshd exponential backoff patch In-Reply-To: <1232701533.29828.1296322611@webmail.messagingengine.com> References: <1232701533.29828.1296322611@webmail.messagingengine.com> Message-ID: Hey Sam, This is a really nice idea. However, I'm not so hot on making a core utility such as OpenSSH reliant on a library that isn't by default available on most platforms. -rob On Jan 23, 2009, at 1:05 AM, Sam Watkins wrote: > hi, > > I wrote a patch to openssh sshd.c which enables "exponential backoff", > so that an attacker cannot brute force your password by making > hundreds > of login attempts. > > here is the code: > > http://sam.nipl.net/sshd-backoff/ > > An attacker who fails to login is locked out (by IP address) for 1 > minute, and the lockout period doubles for each failed login after > that. > Normally three logins are allowed before an ssh connection is > terminated. > > This patch is "beta" software and might lock you out of your sshd, > so be > careful and make sure you are prepared for that. > > You can "test" the patch by attempting to break in to this server, > nipl.net ssh is running on port 22 > > The patch creates and uses a db-4 database in /var/lib/ssh/backoff.db > > I think my code is written carefully, but it might have some bugs. > Also > I think this problem might be better solved outside of sshd (maybe in > pam). I'd be very grateful for any constructive feedback. > > Thanks! > > Sam > > > ( I wrote a similar hack in shell-script a while ago, to prevent > pppd running up a huge phone bill in that case that a dialup > connection fails. ) > _______________________________________________ > 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 Jan 24 12:45:26 2009 From: peter at stuge.se (Peter Stuge) Date: Sat, 24 Jan 2009 02:45:26 +0100 Subject: sshd exponential backoff patch In-Reply-To: <1232701533.29828.1296322611@webmail.messagingengine.com> References: <1232701533.29828.1296322611@webmail.messagingengine.com> Message-ID: <20090124014526.19278.qmail@stuge.se> Sam Watkins wrote: > I think this problem might be better solved outside of sshd I agree. For example by using the firewall. At most maybe sshd needs more to the point logging of failed attempts, but I think it's already possible to reliably distinguish those errors for external processing, or? //Peter From J.S.Peatfield at damtp.cam.ac.uk Sat Jan 24 14:55:11 2009 From: J.S.Peatfield at damtp.cam.ac.uk (Jon Peatfield) Date: Sat, 24 Jan 2009 03:55:11 +0000 (GMT) Subject: Match and AuthorizedKeysFile, was Re: sshd config parser In-Reply-To: <20060402024330.GA11219@gate.dtucker.net> References: <442A890C.9050003@zip.com.au> <20060401111919.GA6812@gate.dtucker.net> <20060401131024.GA8769@gate.dtucker.net> <20060402024330.GA11219@gate.dtucker.net> Message-ID: I hope no-one minds me replying to such an old message... :-) On Sun, 2 Apr 2006, Darren Tucker wrote: > Hi All. > > Here's an updated patch. It's not actually as big as it looks as nearly > half of it as adding a flag to the keyword struct and large comment. > > The supported Match directives are User, Group, Host and Address. > > The directives supported inside a Match block are: > > UsePAM, LoginGraceTime, PermitRootLogin, LogFacility, > LogLevel, RhostsRSAAuthentication, HostbasedAuthentication, > HostbasedUsesNameFromPacketOnly, RSAAuthentication, PubkeyAuthentication, > PubkeyAuthentication, KerberosAuthentication, KerberosOrLocalPasswd, > KerberosTicketCleanup, KerberosGetAFSToken, GssAuthentication, > GssCleanupCreds, PasswordAuthentication, KbdInteractiveAuthentication, > ChallengeResponseAuthentication, ChallengeResponseAuthentication, > PrintMotd, PrintLastLog, IgnoreRhosts, IgnoreUserKnownHosts, > X11Forwarding, X11DisplayOffset, X11UseLocalhost, XAuthLocation, > StrictModes, PermitEmptyPasswd, PermitUserEnvironment, UseLogin, > AllowTcpForwarding, GatewayPorts, MaxAuthTries, Banner, > ClientAliveInterval, ClientAliveCountMax, AuthorizedKeysFile, > AuthorizedKeysFile2, AcceptEnv, PermitTunnel > (not all of those are tested, though) I note AuthorizedKeysFile is listed. I was just doing some testing of a system using a fairly freshly built openssh-5.1p1 and started experimenting with Match options and found that AuthorizedKeysFile is not allowed in a Match block - the struct keywords[] entry for it contains SSHCFG_GLOBAL rather than SSHCFG_ALL so I didn't look much further into the code. Anyway I thought it *might* be useful to patch openssh to allow it to work in a Match so first I checked back through old mail to the list first - in case anyone had already suggested it - and found the info above from 2006. If Match was originally going to allow this was it dropped because it caused some problem or would adding it be lots of work? On a slightly different matter has anyone already suggested adding Match options to select on the address/hostname and/or port that the sshd accepted the connection on? I'm thinking of things like: # connection to addresses connected to trusted networks Match localaddress x.x.x.x x1.x1.x1.x1 127.0.0.1 HostbasedAuthentication yes # connection to a 'service' address Match localaddress y.y.y.y HostbasedAuthentication no ForceCommand .... of course one can run different sshds with different setting for these each listening on the relevant addresses/ports so it isn't exactly vital. -- Jon From swatkins at fastmail.fm Sun Jan 25 17:53:50 2009 From: swatkins at fastmail.fm (Sam Watkins) Date: Sun, 25 Jan 2009 14:53:50 +0800 Subject: Fwd: Re: sshd exponential backoff patch Message-ID: <1232866430.12562.1296597355@webmail.messagingengine.com> > This is a really nice idea. However, I'm not so hot on making a core > utility such as OpenSSH reliant on a library that isn't by default > available on most platforms. It could be done differently. I'm surprised that you think berkeley db would not be available on most platforms by default. Anyway it should be a compile-time (and run time) configurable option, so if the library is really not available the feature would not be included. Openssh packages for debian already rely on a variety of libraries. In Debian, libdb4.7 is marked with priority "required", so I guess it is an essential / core package at least for Debian. Well known packages that depend on it include libpam-modules, bind9, evolution, xemacs, squid, postfix. So it seems to be a pretty "core" package especially for a server. It is portable to at least "Linux, Windows, BSD UNIX, Solaris, Mac OS/X, VxWorks and any POSIX- compliant operating system". > > I think this problem might be better solved outside of sshd > > I agree. For example by using the firewall. I think the problem with running "tail" on the logs or whatever and then feeding that data to the firewall is that an attacker would have time for probably a couple hundred attacks before that system would notice what's going on. or maybe there's a better way to do that which I don't know about. Also it would be non standard and complicated to configure it. The fact that the vast majority of ssh servers do not have any such protection (I don't have a source for this but I'll bet it's true) suggests to me that some solution should be available within sshd, that doesn't require a week for an expert sysadmin to set it up and test it. I don't consider my code a very good solution, but it's better than no solution, so I am using it. If anyone else would come up with a better solution I'd like to see it or use it instead. Attackers can now only make 20 attacks per year per IP address on my server. Previously they could have made millions of attacks or more. I think this is a worthwhile improvement even though the implementation is not ideal yet. This is particularly suitable for my server which is a shell server, there might be some users with poor passwords. So this is one part of a solution for me. Sam From plambrechtsen at gmail.com Mon Jan 26 09:50:21 2009 From: plambrechtsen at gmail.com (Peter Lambrechtsen) Date: Mon, 26 Jan 2009 11:50:21 +1300 Subject: SCP Remote-To-Remote? Message-ID: I have seen discussion in 2005 around SCP Remote to Remote support. And wondering if there was any plans to add this into OpenSSH? Specifically I am talking about this e-mail: https://lists.mindrot.org/pipermail/openssh-unix-dev/2005-May/022953.html The situation I find myself in is I can SSH into two of our servers sitting in two different DMZs from out Bastion host, however the two servers are unable to contact each other, nor are they able to SSH back to the Bastion host. Of course since this is a BH, it has no locally writable space so I am unable to copy them locally. The "tar" solution in the above e-mail works, albeit a little ugly. Ideally I would like to be able to: scp -MITM user at host:/directory/files user at host2:/destinationdir And the traffic be routed via the local server, instead of trying to connect directly (as there are no routes between the two due to security and firewall restrictions). Ideas as to if this may be supported in SCP? Thanks Peter From peter at stuge.se Mon Jan 26 13:06:15 2009 From: peter at stuge.se (Peter Stuge) Date: Mon, 26 Jan 2009 03:06:15 +0100 Subject: SCP Remote-To-Remote? In-Reply-To: References: Message-ID: <20090126020615.10394.qmail@stuge.se> Peter Lambrechtsen wrote: > scp -MITM user at host:/directory/files user at host2:/destinationdir > > And the traffic be routed via the local server, instead of trying > to connect directly (as there are no routes between the two due to > security and firewall restrictions). > > Ideas as to if this may be supported in SCP? In theory this is easy, start a remote sink instead of sinking locally. However, scp is considered a legacy program, kept around only for backwards compatibility, so I doubt a new development like this would be included. //Peter From martin at oneiros.de Mon Jan 26 02:41:49 2009 From: martin at oneiros.de (=?ISO-8859-1?Q?Martin_Schr=F6der?=) Date: Sun, 25 Jan 2009 16:41:49 +0100 Subject: sshd exponential backoff patch In-Reply-To: <1232866430.12562.1296597355@webmail.messagingengine.com> References: <1232866430.12562.1296597355@webmail.messagingengine.com> Message-ID: <68c491a60901250741i2fe0f0bnc049f643faff068d@mail.gmail.com> 2009/1/25 Sam Watkins : >> > I think this problem might be better solved outside of sshd >> >> I agree. For example by using the firewall. > > I think the problem with running "tail" on the logs or whatever and then > feeding that data to the firewall is that an attacker would have time > for probably a couple hundred attacks before that system would notice > what's going on. or maybe there's a better way to do that which I don't > know about. Also it would be non standard and complicated to configure > it. It's trivial on OpenBSD (where it can be done by the firewall) and on Linux (e.g. install fail2ban). Since the OpenSSH devs also develope OpenBSD, the chances of getting what you wish into OpenSSH are close to nil (i.e. you have to convice Theo). And of course you should use keys instead of passwords. Best Martin From bob at proulx.com Tue Jan 27 03:32:43 2009 From: bob at proulx.com (Bob Proulx) Date: Mon, 26 Jan 2009 09:32:43 -0700 Subject: sshd exponential backoff patch In-Reply-To: <1232701533.29828.1296322611@webmail.messagingengine.com> References: <1232701533.29828.1296322611@webmail.messagingengine.com> Message-ID: <20090126163243.GA19304@dementia.proulx.com> Sam Watkins wrote: > I wrote a patch to openssh sshd.c which enables "exponential backoff", > so that an attacker cannot brute force your password by making hundreds > of login attempts. I read "hundreds of login attempts" in order to brute force a password. But it actually takes orders of magnitudes more to brute force attack a password. This is okay. You really do want the best attack available to be a brute force attack. The present safeguards will prevent the attack from succeeding before the end of time. Avoiding passwords entirely and using rsa pub keys instead also avoids the issue. That is a good security measure. I think it would be an interesting whitehat project to build an attack program against ssh using a password guesser. Then people who fear that ssh passwords can be guessed too easily can play with it and be assured that a successful brute force attack against ssh by password guessing is actually quite difficult. The advantage of your patch over an external process such as fail2ban is that fail2ban is quite large and hard to use on smaller systems due to resource constraints. A disadvantage of your patch is that I think exponential backoff creates too long of delays. A non-exponential backoff seems more desirable to me than an exponential backoff. Bob From swatkins at fastmail.fm Tue Jan 27 07:55:17 2009 From: swatkins at fastmail.fm (Sam Watkins) Date: Tue, 27 Jan 2009 04:55:17 +0800 Subject: sshd exponential backoff patch In-Reply-To: <20090126163243.GA19304@dementia.proulx.com> References: <1232701533.29828.1296322611@webmail.messagingengine.com> <20090126163243.GA19304@dementia.proulx.com> Message-ID: <1233003317.23161.1296848977@webmail.messagingengine.com> On Mon, 26 Jan 2009 09:32 -0700, "Bob Proulx" wrote: > I read "hundreds of login attempts" in order to brute force a > password. But it actually takes orders of magnitudes more to brute > force attack a password. Yes, I said "hundreds" because that is how many failed attempts you cannot possibly make. 2^100 * [inital lockout time] is a large time to wait. Actually you cannot make more than about 29 before you would die of old age. I've changed the initial lockout time to 5 seconds, I found 1 minute was too annoying. > I think it would be an interesting whitehat project to build an attack > program against ssh using a password guesser. Then people who fear > that ssh passwords can be guessed too easily can play with it and be > assured that a successful brute force attack against ssh by password > guessing is actually quite difficult. It's difficult to crack only if people have good passwords, and if the attacker does not have a clue to what your passwords might be. In reality a lot of people have weak passwords, and sysadmins have little control over their users' passwords, or don't bother to enforce strong passwords. In the case of a weak password it should be fairly easy for a powerful cracking program to crack the account within a few days, if sshd does not limit the number of attempts. Exponential backoff reduces the need for strong passwords. Suddenly "cat3" is a strong enough password. I think reducing the need for strong passwords is a good thing, as most people don't use strong passwords at all, and even many computer experts use weak passwords for accounts they consider unimportant. It would actually be more secure if a person would use a handful of weak passwords (with limited login attempts) than to use the same couple of strong passwords across multiple systems. > A disadvantage of your patch is that I think exponential backoff > creates too long of delays. A non-exponential backoff seems more > desirable to me than an exponential backoff. You could patch the patch to do what you want, that would be a trivial change. With NAT we can have multiple users behind a single IP address, so in that case we would not want to lock out a legitimate user for a long period. Such legitimate users with crippled Internet access might consider using key-based auth or another access method. I don't seriously expect Theo or anyone else to accept my patch into standard openssh, but I do think it is a useful feature, and I will continue to use it myself. I will use the same technique in other authentication systems that I might write, e.g. webapps. Perhaps if the patch were tidied up and configuration options added to control it, it might be more acceptable. Sam From Jefferson.Ogata at noaa.gov Wed Jan 28 12:01:37 2009 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Wed, 28 Jan 2009 01:01:37 +0000 Subject: sshd exponential backoff patch In-Reply-To: <497FAE00.4050704@noaa.gov> References: <1232701533.29828.1296322611@webmail.messagingengine.com> <20090126163243.GA19304@dementia.proulx.com> <497FAE00.4050704@noaa.gov> Message-ID: <497FAE71.1020207@noaa.gov> On 2009-01-28 00:59, Jefferson Ogata wrote: > If that were true, password guessing attacks against sshd wouldn't > happen all the freakin' time (q.v.). I should clarify: I'm really talking about dictionary attacks, not pure brute force. -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From plambrechtsen at gmail.com Wed Jan 28 14:28:03 2009 From: plambrechtsen at gmail.com (Peter Lambrechtsen) Date: Wed, 28 Jan 2009 16:28:03 +1300 Subject: sshd exponential backoff patch In-Reply-To: <497FAE71.1020207@noaa.gov> References: <1232701533.29828.1296322611@webmail.messagingengine.com> <20090126163243.GA19304@dementia.proulx.com> <497FAE00.4050704@noaa.gov> <497FAE71.1020207@noaa.gov> Message-ID: I find a very effective way to prevent attacks (or at least slow them down) is to run the following IPTables rule: iptables -I INPUT -p tcp -i eth+ --dport 22 -m state --state NEW -m recent --set iptables -I INPUT -p tcp -i eth+ --dport 22 -m state --state NEW -m recent --update --seconds 300 --hitcount 3 -j DROP iptables -A INPUT -p tcp -i eth+ --dport 22 -j ACCEPT This will mean that it will drop any third attempt to ssh into your box for 5 mins. Quite effective from experience. I also agree that keys are better than passwords. And this does pose problems if you have automated processed that connect repeatedly to your box as any connection is tagged by iptables, valid or not will be dropped on the third attempt if it is within the 5 min window. A nice and simple low tech solution IMHO ;) Peter On Wed, Jan 28, 2009 at 2:01 PM, Jefferson Ogata wrote: > On 2009-01-28 00:59, Jefferson Ogata wrote: >> If that were true, password guessing attacks against sshd wouldn't >> happen all the freakin' time (q.v.). > > I should clarify: I'm really talking about dictionary attacks, not pure > brute force. > > -- > Jefferson Ogata > NOAA Computer Incident Response Team (N-CIRT) > "Never try to retrieve anything from a bear."--National Park Service > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From Jefferson.Ogata at noaa.gov Wed Jan 28 11:59:44 2009 From: Jefferson.Ogata at noaa.gov (Jefferson Ogata) Date: Wed, 28 Jan 2009 00:59:44 +0000 Subject: sshd exponential backoff patch In-Reply-To: <20090126163243.GA19304@dementia.proulx.com> References: <1232701533.29828.1296322611@webmail.messagingengine.com> <20090126163243.GA19304@dementia.proulx.com> Message-ID: <497FAE00.4050704@noaa.gov> On 2009-01-26 16:32, Bob Proulx wrote: > I read "hundreds of login attempts" in order to brute force a > password. But it actually takes orders of magnitudes more to brute > force attack a password. This is okay. You really do want the best > attack available to be a brute force attack. The present safeguards > will prevent the attack from succeeding before the end of time. If that were true, password guessing attacks against sshd wouldn't happen all the freakin' time (q.v.). > Avoiding passwords entirely and using rsa pub keys instead also avoids > the issue. That is a good security measure. Yes it is. It would be nice if one could then also get sshd to shut up about all the password guessing attacks that write all over your logs, even when PasswordAuthentication is set to "no": Aug 9 15:57:41 brillig sshd[26058]: Failed password for illegal user aleb from xxx.xxx.xxx.xxx port yyyyy ssh2 Aug 9 15:57:41 brillig sshd[26058]: Failed password for illegal user bianca from xxx.xxx.xxx.xxx port yyyyy ssh2 Aug 9 15:57:41 brillig sshd[26058]: Failed password for illegal user bianca123 from xxx.xxx.xxx.xxx port yyyyy ssh2 Aug 9 15:57:41 brillig sshd[26058]: Failed password for illegal user bianca321 from xxx.xxx.xxx.xxx port yyyyy ssh2 Aug 9 15:57:41 brillig sshd[26058]: Failed password for illegal user abcde from xxx.xxx.xxx.xxx port yyyyy ssh2 Aug 9 15:57:41 brillig sshd[26058]: Failed password for illegal user abcd from xxx.xxx.xxx.xxx port yyyyy ssh2 ... etc, etc, etc. > I think it would be an interesting whitehat project to build an attack > program against ssh using a password guesser. Then people who fear There are already such programs in wide circulation. If you want one, just set up a box on the 'Net with an account oh, say, "bianca" with password "bianca", wait a couple of weeks, and then look around the filesystem until you find the ssh brute-force password guessing program your new friend is now running on your box. > that ssh passwords can be guessed too easily can play with it and be > assured that a successful brute force attack against ssh by password > guessing is actually quite difficult. Unfortunately, it isn't difficult at all. As another already pointed out, people commonly choose crappy passwords and in a lot of environments this is difficult for admins to prevent. Admins also set up temporary accounts with crappy passwords and then forget to disable them. It happens all the time. I'm not saying exponential backoff is necessarily a great solution. But this is a real problem, and there are other related problems that could be solved as well (e.g. the aforementioned log blathering). -- Jefferson Ogata NOAA Computer Incident Response Team (N-CIRT) "Never try to retrieve anything from a bear."--National Park Service From adrya1984 at gmail.com Wed Jan 28 22:22:17 2009 From: adrya1984 at gmail.com (Adriana Rodean) Date: Wed, 28 Jan 2009 13:22:17 +0200 Subject: Patch for OpenSSH for Windows to allow authentication through certificates In-Reply-To: <4950B162.6000107@roumenpetrov.info> References: <496c8fcc0812160132h4b1d2e5bm386cde105bd0cbbc@mail.gmail.com> <4950B162.6000107@roumenpetrov.info> Message-ID: <496c8fcc0901280322g1db0aa29j55dc77b638b97fda@mail.gmail.com> Hi, Thanks Roumen for the input. Can you or someone help me patch openssh with your X509 certificates patch and install it in Cygwin? I've searched on google haven't found any guide how to patch it in cygwin. I installed Cygwin with openssh. Don't know what to do further. Please help, i'm not a Linux user, and is first time i use Cygwin. Help please, Thanks, Adriana On Tue, Dec 23, 2008 at 11:37, Roumen Petrov wrote: > > Adriana Rodean wrote: >> >> Hi all, >> >> Does anyone know if it exists a patch for OpenSSH for Windows to allow >> authentication through certificates? >> Is it possible to make one if it doesn't exists? >> Using OpenSSH for Windows 3.8p1-1 20040709 Build. >> >> I know there is Roumen Petrov patch, but is for unix machines if i'm >> not mistaken. >> I need a similar one for Windows that work with the Roumen Petrov >> patch so i can have authentication through certificates between >> Windows machine and Linux machine. >> >> Any help greatly appreciated, >> Adriana > > Did you try the patch on cygwin platform ? The patch don't use specific > to the unix/posix methods(functions). > > Roumen > > > -- > Get X.509 certificates support in OpenSSH: > http://roumenpetrov.info/openssh/ From janfrode at tanso.net Thu Jan 29 01:54:35 2009 From: janfrode at tanso.net (Jan-Frode Myklebust) Date: Wed, 28 Jan 2009 15:54:35 +0100 Subject: sshd exponential backoff patch References: <1232701533.29828.1296322611@webmail.messagingengine.com> <20090126163243.GA19304@dementia.proulx.com> <497FAE00.4050704@noaa.gov> <497FAE71.1020207@noaa.gov> Message-ID: On 2009-01-28, Peter Lambrechtsen wrote: > I find a very effective way to prevent attacks (or at least slow them > down) is to run the following IPTables rule: > > iptables -I INPUT -p tcp -i eth+ --dport 22 -m state --state NEW -m recent --set > iptables -I INPUT -p tcp -i eth+ --dport 22 -m state --state NEW -m > recent --update --seconds 300 --hitcount 3 -j DROP > iptables -A INPUT -p tcp -i eth+ --dport 22 -j ACCEPT I was experimenting a bit with the ipt_recent module a while ago (on RHEL5). And it seemed I could quite easily trigger a kernel crash by cat'ing the recent tables under /proc/net/ipt_recent/. So, IMHO, that module might be quite dangerous to enable on a multiuser system... -jf From vinschen at redhat.com Thu Jan 29 04:40:08 2009 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 28 Jan 2009 18:40:08 +0100 Subject: [PATCH] Update Cygwin service installer script for new Cygwin release Message-ID: <20090128174008.GB16129@calimero.vinschen.de> Hi, the below patch is necessary for the contrib/cygwin/ssh-host-config script to work on Cygwin 1.5.x as well as on the new Cygwin 1.7.x. The information given for the setting of the CYGWIN environment variable is wrong for both releases so I just removed it, together with the unnecessary (Cygwin 1.5.x) or wrong (Cygwin 1.7.x) default setting. Could somebody with checkin rights please apply this patch? Thanks, Corinna Index: contrib/cygwin/ssh-host-config =================================================================== RCS file: /cvs/openssh/contrib/cygwin/ssh-host-config,v retrieving revision 1.23 diff -u -p -r1.23 ssh-host-config --- contrib/cygwin/ssh-host-config 1 Dec 2008 10:34:28 -0000 1.23 +++ contrib/cygwin/ssh-host-config 28 Jan 2009 17:39:21 -0000 @@ -25,7 +25,7 @@ source ${CSIH_SCRIPT} port_number=22 privsep_configured=no privsep_used=yes -cygwin_value="ntsec" +cygwin_value="" password_value= # ====================================================================== @@ -76,7 +76,7 @@ update_services_file() { fi _serv_tmp="${_my_etcdir}/srv.out.$$" - mount -t -f "${_win_etcdir}" "${_my_etcdir}" + mount -o text -f "${_win_etcdir}" "${_my_etcdir}" # Depends on the above mount _wservices=`cygpath -w "${_services}"` @@ -278,8 +278,6 @@ install_service() { echo -e "${_csih_QUERY_STR} Do you want to install sshd as a service?" if csih_request "(Say \"no\" if it is already installed as a service)" then - csih_inform "Note that the CYGWIN variable must contain at least \"ntsec\"" - csih_inform "for sshd to be able to change user context without password." csih_get_cygenv "${cygwin_value}" if ( csih_is_nt2003 || [ "$csih_FORCE_PRIVILEGED_USER" = "yes" ] ) -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From tim at multitalents.net Thu Jan 29 07:51:31 2009 From: tim at multitalents.net (Tim Rice) Date: Wed, 28 Jan 2009 12:51:31 -0800 (PST) Subject: [PATCH] Update Cygwin service installer script for new Cygwin release In-Reply-To: <20090128174008.GB16129@calimero.vinschen.de> References: <20090128174008.GB16129@calimero.vinschen.de> Message-ID: On Wed, 28 Jan 2009, Corinna Vinschen wrote: > Hi, > > the below patch is necessary for the contrib/cygwin/ssh-host-config script > to work on Cygwin 1.5.x as well as on the new Cygwin 1.7.x. The information > given for the setting of the CYGWIN environment variable is wrong for both > releases so I just removed it, together with the unnecessary (Cygwin 1.5.x) > or wrong (Cygwin 1.7.x) default setting. > > Could somebody with checkin rights please apply this patch? Done. > > Thanks, > Corinna [snip] -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From bob at proulx.com Thu Jan 29 08:52:01 2009 From: bob at proulx.com (Bob Proulx) Date: Wed, 28 Jan 2009 14:52:01 -0700 Subject: sshd exponential backoff patch In-Reply-To: <497FAE00.4050704@noaa.gov> References: <1232701533.29828.1296322611@webmail.messagingengine.com> <20090126163243.GA19304@dementia.proulx.com> <497FAE00.4050704@noaa.gov> Message-ID: <20090128215201.GA2192@dementia.proulx.com> Jefferson Ogata wrote: > Bob Proulx wrote: > > I read "hundreds of login attempts" in order to brute force a > > password. But it actually takes orders of magnitudes more to brute > > force attack a password. This is okay. You really do want the best > > attack available to be a brute force attack. The present safeguards > > will prevent the attack from succeeding before the end of time. > > If that were true, password guessing attacks against sshd wouldn't > happen all the freakin' time (q.v.). Yes they would. The cost structure is similar to the one for spam. It doesn't cost anything to be annoying. Script kiddies do it just to do it. As long as the appearance of anonymity exists and there is no punishment then it will continue. > It would be nice if one could then also get sshd to shut up about > all the password guessing attacks that write all over your logs, > even when PasswordAuthentication is set to "no": That sounds like a valid issue. A different separate issue but quite valid. I would bet something there could be improved. > > I think it would be an interesting whitehat project to build an attack > > program against ssh using a password guesser. Then people who fear > > There are already such programs in wide circulation. If you want one, > just set up a box on the 'Net with an account oh, say, "bianca" with > password "bianca", wait a couple of weeks, and then look around the > filesystem until you find the ssh brute-force password guessing program > your new friend is now running on your box. ...in the next mail... > I should clarify: I'm really talking about dictionary attacks, not > pure brute force. I am definitely talking about brute force password guessing attacks. If you have passwords that can be guessed from a dictionary attack then you have serious problems. But it is a different serious problem from the one we were talking about. Your example of a user with the same password might actually be guessed on the very first attempt! I know you were making an extreme example but again that is a different problem and although rate limit blocking will help it won't completely fix the problem. It is a white-wash at best. > Unfortunately, it isn't difficult at all. As another already pointed > out, people commonly choose crappy passwords and in a lot of > environments this is difficult for admins to prevent. Admins also set up > temporary accounts with crappy passwords and then forget to disable > them. It happens all the time. Of course you are correct. People are the problem. If we can remove them from the system then everything could be perfect. :-) Many sites run password strength checkers such as crack to test the strength of users passwords when they create them. Passwords that can be dictionary guessed easily are rejected. Passwords that pass the crack attempts are allowed. This is a very useful password policy. I am not inclined to try to add protection against admins. That seems counter productive. > I'm not saying exponential backoff is necessarily a great solution. But > this is a real problem, and there are other related problems that could > be solved as well (e.g. the aforementioned log blathering). The already existing 'fail2ban' solution is perfectly suited for your example case. Bob From chris at qwirx.com Thu Jan 29 09:07:36 2009 From: chris at qwirx.com (Chris Wilson) Date: Wed, 28 Jan 2009 22:07:36 +0000 (GMT) Subject: sshd exponential backoff patch In-Reply-To: <497FAE00.4050704@noaa.gov> References: <1232701533.29828.1296322611@webmail.messagingengine.com> <20090126163243.GA19304@dementia.proulx.com> <497FAE00.4050704@noaa.gov> Message-ID: Hi Jefferson, On Wed, 28 Jan 2009, Jefferson Ogata wrote: > On 2009-01-26 16:32, Bob Proulx wrote: >> I read "hundreds of login attempts" in order to brute force a >> password. But it actually takes orders of magnitudes more to brute >> force attack a password. This is okay. You really do want the best >> attack available to be a brute force attack. The present safeguards >> will prevent the attack from succeeding before the end of time. > > If that were true, password guessing attacks against sshd wouldn't > happen all the freakin' time (q.v.). > >> Avoiding passwords entirely and using rsa pub keys instead also avoids >> the issue. That is a good security measure. > > Yes it is. It would be nice if one could then also get sshd to shut up > about all the password guessing attacks that write all over your logs, > even when PasswordAuthentication is set to "no": > > Aug 9 15:57:41 brillig sshd[26058]: Failed password for illegal user > aleb from xxx.xxx.xxx.xxx port yyyyy ssh2 I always move public sshds to a non-standard port. Removes all the worm spam and automated brute-force attacks for me. Cheers, Chris. -- _____ __ _ \ __/ / ,__(_)_ | Chris Wilson <0000 at qwirx.com> - Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer | \__/_/_/_//_/___/ | We are GNU : free your mind & your software | From ppi at bulkemailing.co.za Thu Jan 29 07:00:04 2009 From: ppi at bulkemailing.co.za (Adel Botha) Date: Wed, 28 Jan 2009 22:00:04 +0200 Subject: Palm Terrace apartments launching - From R299K Cape Town Message-ID: <20090129022658.022F2C4AE4@natsu.mindrot.org> [top.jpg] [left_image.jpg] * Combination of retail and residential units making this ideal to live, work and play * Only 4km from Cape Town CBD * Delayed transfer: end of 2009 * Mix of bachelor,1 and 2 bedrooms * Large sun-deck and braai area * Enclosed sun-lounge * Small gym area * High rental demand and rental return * Only R5000 Deposit secures your investment [1][btn05.jpg] [2][web.jpg] [3][udz3.jpg] For further information contact: Adel Botha @ 080 33 33 33 3 Email: [4]adel at ppigroup.co.za This email was sent to openssh-unix-dev at mindrot.org It is not our intention to send you any unsolicited mail. If you receive this email in error please accept our apologies and unsubscribe by following the link below. To report any abuse please email [5]Abuse To unsubscribe please [6]Click Here [sendopen.php?MemberID=2123838&SendID=458&Type=Send] References Visible links 1. http://bulkemailing.co.za/email/users/link.php?UserID=2123838&Newsletter=239&List=116&LinkType=Send&LinkID=246 2. http://bulkemailing.co.za/email/users/link.php?UserID=2123838&Newsletter=239&List=116&LinkType=Send&LinkID=245 3. http://bulkemailing.co.za/email/users/link.php?UserID=2123838&Newsletter=239&List=116&LinkType=Send&LinkID=244 4. mailto:adel at ppigroup.co.za?subject=Palm%20Terrace 5. mailto:ppiabuse at bulkemailing.co.za?subject=Abuse%20by%20PPI%20Emails 6. http://bulkemailing.co.za/email/users/unsub.php?Mem=2123838&ConfirmCode=a7fdd3973ca34162bd68ad9ac01ae459 Hidden links: 7. mailto:wanitta at ppigroup.co.za From djm at mindrot.org Thu Jan 29 14:38:12 2009 From: djm at mindrot.org (Damien Miller) Date: Thu, 29 Jan 2009 14:38:12 +1100 (EST) Subject: spam Message-ID: I think I have closed the loophole that allowed that previous spam message through. Please report any breakage to me directly. Thanks & apologies, Damien Miller From vinschen at redhat.com Thu Jan 29 21:06:31 2009 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 29 Jan 2009 11:06:31 +0100 Subject: [PATCH] Update Cygwin service installer script for new Cygwin release In-Reply-To: References: <20090128174008.GB16129@calimero.vinschen.de> Message-ID: <20090129100631.GG16129@calimero.vinschen.de> On Jan 28 12:51, Tim Rice wrote: > On Wed, 28 Jan 2009, Corinna Vinschen wrote: > > > Hi, > > > > the below patch is necessary for the contrib/cygwin/ssh-host-config script > > to work on Cygwin 1.5.x as well as on the new Cygwin 1.7.x. The information > > given for the setting of the CYGWIN environment variable is wrong for both > > releases so I just removed it, together with the unnecessary (Cygwin 1.5.x) > > or wrong (Cygwin 1.7.x) default setting. > > > > Could somebody with checkin rights please apply this patch? > > Done. Thank you. I have a follow up patch. If the CYGWIN environment variable is empty, the installer script should not install the service with an empty CYGWIN variable, but rather without setting CYGWNI entirely. That's what the below patch does. Would you mind to apply it as well? Thank you, Corinna Index: contrib/cygwin/ssh-host-config =================================================================== RCS file: /cvs/openssh/contrib/cygwin/ssh-host-config,v retrieving revision 1.24 diff -u -p -r1.24 ssh-host-config --- contrib/cygwin/ssh-host-config 28 Jan 2009 20:50:05 -0000 1.24 +++ contrib/cygwin/ssh-host-config 29 Jan 2009 10:05:03 -0000 @@ -313,11 +313,15 @@ install_service() { # the two cases. csih_check_user "${run_service_as}" - + + if [ -n "${csih_cygenv}" ] + then + cygwin_env="-e CYGWIN=\"${csih_cygenv}\"" + fi if [ -z "${password}" ] then - if cygrunsrv -I sshd -d "CYGWIN sshd" -p /usr/sbin/sshd -a "-D" -y tcpip \ - -e CYGWIN="${csih_cygenv}" + if eval cygrunsrv -I sshd -d \"CYGWIN sshd\" -p /usr/sbin/sshd \ + -a "-D" -y tcpip ${cygwin_env} then echo csih_inform "The sshd service has been installed under the LocalSystem" @@ -326,8 +330,9 @@ install_service() { csih_inform "will start automatically after the next reboot." fi else - if cygrunsrv -I sshd -d "CYGWIN sshd" -p /usr/sbin/sshd -a "-D" -y tcpip \ - -e CYGWIN="${csih_cygenv}" -u "${run_service_as}" -w "${password}" + if eval cygrunsrv -I sshd -d \"CYGWIN sshd\" -p /usr/sbin/sshd \ + -a "-D" -y tcpip ${cygwin_env} \ + -u "${run_service_as}" -w "${password}" then echo csih_inform "The sshd service has been installed under the '${run_service_as}'" -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From tim at multitalents.net Fri Jan 30 08:27:25 2009 From: tim at multitalents.net (Tim Rice) Date: Thu, 29 Jan 2009 13:27:25 -0800 (PST) Subject: [PATCH] Update Cygwin service installer script for new Cygwin release In-Reply-To: <20090129100631.GG16129@calimero.vinschen.de> References: <20090128174008.GB16129@calimero.vinschen.de> <20090129100631.GG16129@calimero.vinschen.de> Message-ID: On Thu, 29 Jan 2009, Corinna Vinschen wrote: > Thank you. > > I have a follow up patch. If the CYGWIN environment variable is empty, > the installer script should not install the service with an empty CYGWIN > variable, but rather without setting CYGWNI entirely. That's what the > below patch does. Would you mind to apply it as well? I've applied your patch. And then I cleaned up the whitespace in that file and commited that. > > Thank you, > Corinna > [patch snipped] -- Tim Rice Multitalents (707) 887-1469 tim at multitalents.net From vinschen at redhat.com Fri Jan 30 20:35:40 2009 From: vinschen at redhat.com (Corinna Vinschen) Date: Fri, 30 Jan 2009 10:35:40 +0100 Subject: [PATCH] Update Cygwin service installer script for new Cygwin release In-Reply-To: References: <20090128174008.GB16129@calimero.vinschen.de> <20090129100631.GG16129@calimero.vinschen.de> Message-ID: <20090130093540.GL16129@calimero.vinschen.de> On Jan 29 13:27, Tim Rice wrote: > On Thu, 29 Jan 2009, Corinna Vinschen wrote: > > > Thank you. > > > > I have a follow up patch. If the CYGWIN environment variable is empty, > > the installer script should not install the service with an empty CYGWIN > > variable, but rather without setting CYGWNI entirely. That's what the > > below patch does. Would you mind to apply it as well? > > I've applied your patch. > And then I cleaned up the whitespace in that file and commited that. Thank you, Corinna -- Corinna Vinschen Cygwin Project Co-Leader Red Hat From jblaine at kickflop.net Sat Jan 31 06:21:56 2009 From: jblaine at kickflop.net (jblaine at kickflop.net) Date: Fri, 30 Jan 2009 11:21:56 -0800 (PST) Subject: Patch to log tunnel information Message-ID: First, all credit to Vladimir Parkhaev as this is his code. He may have submitted this before for all I know, but I for one definitely would like to see this end up in the codebase, so I'm submitting it. *** openssh-5.1p1/serverloop.c Fri Jul 4 09:10:49 2008 --- openssh-5.1p1-RCFHACKS/serverloop.c Thu Jan 29 08:56:11 2009 *************** *** 957,962 **** --- 957,968 ---- c = channel_connect_to(target, target_port, "direct-tcpip", "direct-tcpip"); + if (c == NULL){ + verbose("Tunnel denied: user '%s' from %s to %s:%d", the_authctxt->user, get_remote_ipaddr(), target, target_port); + } else { + verbose("Tunnel opened: user '%s' from %s to %s:%d", the_authctxt->user, get_remote_ipaddr(), target, target_port); + } + xfree(originator); xfree(target); From jmknoble at pobox.com Sat Jan 31 08:09:51 2009 From: jmknoble at pobox.com (Jim Knoble) Date: Fri, 30 Jan 2009 16:09:51 -0500 Subject: Patch to log tunnel information In-Reply-To: References: Message-ID: <20090130210951.GE24652@crawfish.ais.com> Circa 2009-01-30 14:21 dixit jblaine at kickflop.net: : First, all credit to Vladimir Parkhaev as this is his code. He may have : submitted this before for all I know, but I for one definitely would like : to see this end up in the codebase, so I'm submitting it. : : [snip: Patch to log tunnel information] Probably a good idea to put this in the OpenSSH Bugzilla: http://www.openssh.com/report.html http://bugzilla.mindrot.org/ --jim -- jim knoble | jmknoble at pobox.com | http://www.pobox.com/~jmknoble/ (GnuPG key ID: C6F31FFA >>>>>> http://www.pobox.com/~jmknoble/keys/ ) (GnuPG fingerprint: 99D8:1D89:8C66:08B5:5C34::5527:A543:8C33:C6F3:1FFA) +----------------------------------------------------------------------+ |[L]iberty, as we all know, cannot flourish in a country that is perma-| | nently on a war footing, or even a near-war footing. --Aldous Huxley| +----------------------------------------------------------------------+