From openssh-unix-dev at thegeezer.net Thu May 1 19:21:16 2014 From: openssh-unix-dev at thegeezer.net (TheGezer) Date: Thu, 01 May 2014 10:21:16 +0100 Subject: public key authentication -- log invalid keys In-Reply-To: References: <535A5A9E.5090408@thegeezer.net> <20140425164122.GX8684@esk.usu.edu> <535A966B.3040701@thegeezer.net> <535EAF50.9080009@thegeezer.net> Message-ID: <5362120C.9030402@thegeezer.net> On 04/29/2014 05:30 AM, Damien Miller wrote: > On Mon, 28 Apr 2014, TheGezer wrote: > >> OK so i've been doing some digging and a bit more testing. seems i do >> get an error but only in verbose loglevel. >> but I have to increase LogLevel to verbose to only get >> " [sshd] Failed publickey for root " > OpenSSH since 6.3 logs the key for success and failure at LogLevel=verbose: > > Apr 29 14:27:35 fuyu sshd[11783]: Failed publickey for djm from 192.168.0.5 port 45142 ssh2: ECDSA c9:e8:d5:d6:ed:59:fe:10:52:e4:4f:95:13:e8:fd:01 > > > yeah that's kind of my point -- surely you should have lower loglevel in order to track bad keys attempts ? From djm at mindrot.org Thu May 1 22:49:34 2014 From: djm at mindrot.org (Damien Miller) Date: Thu, 1 May 2014 22:49:34 +1000 (EST) Subject: public key authentication -- log invalid keys In-Reply-To: <5362120C.9030402@thegeezer.net> References: <535A5A9E.5090408@thegeezer.net> <20140425164122.GX8684@esk.usu.edu> <535A966B.3040701@thegeezer.net> <535EAF50.9080009@thegeezer.net> <5362120C.9030402@thegeezer.net> Message-ID: On Thu, 1 May 2014, TheGezer wrote: > yeah that's kind of my point -- surely you should have lower loglevel in > order to track bad keys attempts ? Just for fun, calculate the probability of a "bad key attempt" succeeding. -d From busterb at gmail.com Fri May 2 14:13:53 2014 From: busterb at gmail.com (Brent Cook) Date: Thu, 1 May 2014 23:13:53 -0500 Subject: Regarding the optional OpenSSL integration for the portable version Message-ID: Hi, I have been working on a portable LibreSSL build tree for a little while to test the waters: http://github.com/busterb/libressl Someone noticed an issue with the arc4random implementation that I originally grabbed from libbsd https://github.com/busterb/libressl/issues/1 So, I looked at how OpenSSH handles it, and noticed that it uses the random functions from OpenSSL unconditionally to seed the state of its version of arc4random. Regarding the new ?build without OpenSSL? flag here: http://article.gmane.org/gmane.os.openbsd.cvs/130612 it would be nice to have some feedback on this modified version of the OpenSSH portable arc4random that I incorporated, which seeds itself in the same manner as libbsd?s version: libbsd?s version: http://cgit.freedesktop.org/libbsd/tree/src/arc4random.c modified version: https://github.com/busterb/libressl/blob/master/crypto/compat/arc4random.c If the seed function here doesn?t seem suitable, perhaps we could come up with a common arc4random implementation that works portably for LibreSSL and OpenSSH, which also does not depend on OpenSSL?s random number generation. - Brent From djm at mindrot.org Fri May 2 14:56:59 2014 From: djm at mindrot.org (Damien Miller) Date: Fri, 2 May 2014 14:56:59 +1000 (EST) Subject: Regarding the optional OpenSSL integration for the portable version In-Reply-To: References: Message-ID: On Thu, 1 May 2014, Brent Cook wrote: > Hi, > > I have been working on a portable LibreSSL build tree for a little > while to test the waters: http://github.com/busterb/libressl > > Someone noticed an issue with the arc4random > implementation that I originally grabbed from libbsd > https://github.com/busterb/libressl/issues/1 > > So, I looked at how OpenSSH handles it, and noticed that it uses the > random functions from OpenSSL unconditionally to seed the state of its > version of arc4random. I haven't ported the no-OpenSSL changes yet and haven't thought about how I'll handle arc4random. I'll probably make an explicit arc4random_stir() function that we can call in various places. OpenBSD has put some effort in to ensure that the kernel PRNG is available in pretty much any context (privileged, unprivileged, in chroot without devices, etc.) and AFAIK no other OS does this. IMO the libbsd code and yours both do one risky thing: for OpenSSH at least, the right response to not being able to read KEYSIZE bytes from /dev/urandom for the initial seeding is to fatal()/abort(). Obviously this isn't likely to be popular in a generic library, but it's the only safe thing to do. -d From openssh-unix-dev at thegeezer.net Fri May 2 17:56:03 2014 From: openssh-unix-dev at thegeezer.net (TheGezer) Date: Fri, 02 May 2014 08:56:03 +0100 Subject: public key authentication -- log invalid keys In-Reply-To: References: <535A5A9E.5090408@thegeezer.net> <20140425164122.GX8684@esk.usu.edu> <535A966B.3040701@thegeezer.net> <535EAF50.9080009@thegeezer.net> <5362120C.9030402@thegeezer.net> Message-ID: <53634F93.9040302@thegeezer.net> On 05/01/2014 01:49 PM, Damien Miller wrote: > On Thu, 1 May 2014, TheGezer wrote: > >> yeah that's kind of my point -- surely you should have lower loglevel in >> order to track bad keys attempts ? > Just for fun, calculate the probability of a "bad key attempt" succeeding. > > -d > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev yeah i know, but with increasing bandwidth online, and more and more folks using vps with just a public key a silent distributed attack could go on for a couple of years without anything more than just lots of mysterious connection attempts in the logs also consider internal breach attempts sitting inside the perimeter and consider that if most people lose their client public key through theft or other they would typically just delete the authkey on the server rather than put it in revoked keys so logging bad attempts would catch these guys too personally, i'm going to patch my sources to have bad attempts logged at a lower loglevel From djm at mindrot.org Fri May 2 18:23:16 2014 From: djm at mindrot.org (Damien Miller) Date: Fri, 2 May 2014 18:23:16 +1000 (EST) Subject: public key authentication -- log invalid keys In-Reply-To: <53634F93.9040302@thegeezer.net> References: <535A5A9E.5090408@thegeezer.net> <20140425164122.GX8684@esk.usu.edu> <535A966B.3040701@thegeezer.net> <535EAF50.9080009@thegeezer.net> <5362120C.9030402@thegeezer.net> <53634F93.9040302@thegeezer.net> Message-ID: On Fri, 2 May 2014, TheGezer wrote: > yeah i know, but with increasing bandwidth online, and more and more > folks using vps with just a public key a silent distributed attack could > go on for a couple of years without anything more than just lots of > mysterious connection attempts in the logs If you think that such an attack might only take "years" then you haven't done the math. > also consider internal breach attempts sitting inside the perimeter > > and consider that if most people lose their client public key through > theft or other they would typically just delete the authkey on the > server rather than put it in revoked keys so logging bad attempts would > catch these guys too > > personally, i'm going to patch my sources to have bad attempts logged at > a lower loglevel ... or you could make a one line config change. -d From ymartin1040 at gmail.com Fri May 2 20:18:05 2014 From: ymartin1040 at gmail.com (Yves Martin) Date: Fri, 2 May 2014 12:18:05 +0200 Subject: SSH command line behavior with explicit identity file In-Reply-To: References: Message-ID: Hello, Here is a test case to show the trouble I got: touch test chmod 000 test Now compare ssh -i test localhost and ssh -t -i test localhost I have checked behavior in both Debian Wheezy version: OpenSSH_6.0p1 Debian-4+deb7u1, OpenSSL 1.0.1e 11 Feb 2013 and Ubuntu LTS 14.04 version 6.6p1-2ubuntu1 Thanks to strace, I guess the "not accessible" warning is only produced when "stat" syscall is not possible on identity file. In my test case, "stat" returns 0 as the file exists and is accessible. But permission bits prevent me to read it so the "open" call fails. So when using an explicit identity file in options, I would expect ssh command outputs to stderr the "could not open key file '/path/to/my/id_dsa': Permission denied" message. Thank you for your attention Best regards -- Yves Martin From busterb at gmail.com Fri May 2 23:48:28 2014 From: busterb at gmail.com (Brent Cook) Date: Fri, 2 May 2014 08:48:28 -0500 Subject: Regarding the optional OpenSSL integration for the portable version In-Reply-To: References: Message-ID: <16855940-67CC-4EAE-8FA2-1DE44153133A@gmail.com> On May 1, 2014, at 11:56 PM, Damien Miller wrote: > On Thu, 1 May 2014, Brent Cook wrote: > >> Hi, >> >> I have been working on a portable LibreSSL build tree for a little >> while to test the waters: http://github.com/busterb/libressl >> >> Someone noticed an issue with the arc4random >> implementation that I originally grabbed from libbsd >> https://github.com/busterb/libressl/issues/1 >> >> So, I looked at how OpenSSH handles it, and noticed that it uses the >> random functions from OpenSSL unconditionally to seed the state of its >> version of arc4random. > > I haven't ported the no-OpenSSL changes yet and haven't thought about > how I'll handle arc4random. > > I'll probably make an explicit arc4random_stir() function that we can > call in various places. OpenBSD has put some effort in to ensure that > the kernel PRNG is available in pretty much any context (privileged, > unprivileged, in chroot without devices, etc.) and AFAIK no other OS > does this. > > IMO the libbsd code and yours both do one risky thing: for OpenSSH at > least, the right response to not being able to read KEYSIZE bytes from > /dev/urandom for the initial seeding is to fatal()/abort(). Obviously > this isn't likely to be popular in a generic library, but it's the > only safe thing to do. Thanks for the feedback. I certainly would not want anyone to generate certificates with entropy based only on random stack + PID + time, which would effectively be just stack + PID + short time range since certificates are timestamped. It looks like I need to connect up the state of the arc4random implementation to the RAND_poll()/status()/bytes() methods so they fail properly and return bad status if urandom could not be read. > -d From william at 25thandClement.com Sat May 3 05:40:00 2014 From: william at 25thandClement.com (William Ahern) Date: Fri, 2 May 2014 12:40:00 -0700 Subject: Regarding the optional OpenSSL integration for the portable version In-Reply-To: References: Message-ID: <20140502194000.GB24093@wilbur.25thandClement.com> On Fri, May 02, 2014 at 02:56:59PM +1000, Damien Miller wrote: > On Thu, 1 May 2014, Brent Cook wrote: > > > Hi, > > > > I have been working on a portable LibreSSL build tree for a little > > while to test the waters: http://github.com/busterb/libressl > > > > Someone noticed an issue with the arc4random > > implementation that I originally grabbed from libbsd > > https://github.com/busterb/libressl/issues/1 > > > > So, I looked at how OpenSSH handles it, and noticed that it uses the > > random functions from OpenSSL unconditionally to seed the state of its > > version of arc4random. > > I haven't ported the no-OpenSSL changes yet and haven't thought about > how I'll handle arc4random. > > I'll probably make an explicit arc4random_stir() function that we can > call in various places. OpenBSD has put some effort in to ensure that > the kernel PRNG is available in pretty much any context (privileged, > unprivileged, in chroot without devices, etc.) and AFAIK no other OS > does this. NetBSD and FreeBSD (as of 10.0) both use a sysctl, just like OpenBSD. Linux also has an obscure sysctl which pulls directly from the internal CSPRNG. So all of these will work in a jail without /dev or /proc. OS X still seeds itself from /dev/urandom in its arc4random implementation, as it inherited FreeBSD's old code. Solaris sadly only has /dev/urandom. For my Lua bindings to OpenSSL I use all of these different mechanisms to explicitly seed OpenSSL. The code is in randL_stir. Here's a direct link: https://github.com/wahern/luaossl/blob/dd0ad8dc1b0962fc80dbf680aadaaaba6536c96b/src/openssl.c#L4008 From scott_n at xypro.com Sat May 3 08:30:28 2014 From: scott_n at xypro.com (Scott Neugroschl) Date: Fri, 2 May 2014 22:30:28 +0000 Subject: Regarding the optional OpenSSL integration for the portable version In-Reply-To: <20140502194000.GB24093@wilbur.25thandClement.com> References: <20140502194000.GB24093@wilbur.25thandClement.com> Message-ID: >NetBSD and FreeBSD (as of 10.0) both use a sysctl, just like OpenBSD. Linux also has an obscure sysctl which pulls directly from the internal CSPRNG. So all of these will work in a jail without /dev or /proc. >OS X still seeds itself from /dev/urandom in its arc4random implementation, as it inherited FreeBSD's old code. Solaris sadly only has /dev/urandom. And then there are those implementations that have to use PRNGD because there's no built-in source of randomness. From d.s at daniel.shahaf.name Sat May 3 08:15:53 2014 From: d.s at daniel.shahaf.name (Daniel Shahaf) Date: Fri, 2 May 2014 22:15:53 +0000 Subject: [PATCH] 'ssh -A' / 'ssh-add -c' crossref Message-ID: <20140502221553.GB2134@tarsus.local2> Hello, The documentation of 'ssh -A' does not mention that the risks can be somewhat mitigated by using the '-c' option of 'ssh-add'. In my experience, people are unaware of the '-c' option, so I suggest to point to it from the documentation of '-A': Index: ssh.1 =================================================================== RCS file: /cvs/src/usr.bin/ssh/ssh.1,v retrieving revision 1.345 diff -u -r1.345 ssh.1 --- ssh.1 19 Apr 2014 18:42:19 -0000 1.345 +++ ssh.1 2 May 2014 20:14:18 -0000 @@ -121,6 +121,11 @@ An attacker cannot obtain key material from the agent, however they can perform operations on the keys that enable them to authenticate using the identities loaded into the agent. +Using the +.Fl c +flag of +.Xr ssh-add 1 +can reduce (but not eliminate) the risk. .It Fl a Disables forwarding of the authentication agent connection. .It Fl b Ar bind_address I'm not married to the specific text in the patch; I'd just like the documentation of -A to contain a crossref to -c. Cheers, Daniel From william at 25thandClement.com Sat May 3 08:43:09 2014 From: william at 25thandClement.com (William Ahern) Date: Fri, 2 May 2014 15:43:09 -0700 Subject: Regarding the optional OpenSSL integration for the portable version In-Reply-To: References: <20140502194000.GB24093@wilbur.25thandClement.com> Message-ID: <20140502224309.GA5371@wilbur.25thandClement.com> On Fri, May 02, 2014 at 10:30:28PM +0000, Scott Neugroschl wrote: > > >NetBSD and FreeBSD (as of 10.0) both use a sysctl, just like OpenBSD. > > Linux also has an obscure sysctl which pulls directly from the internal > > CSPRNG. So all of these will work in a jail without /dev or /proc. > > >OS X still seeds itself from /dev/urandom in its arc4random > > implementation, as it inherited FreeBSD's old code. Solaris sadly only > > has /dev/urandom. > > And then there are those implementations that have to use PRNGD because > there's no built-in source of randomness. > That's basically equivalent to /dev/urandom from the code's perspective. The reason why /dev/urandom sucks is two-fold: 1) as already mentioned you can't access it inside a chroot jail (unless explicitly created, but then you can't mount with the nodev option), but also 2) you may have hit a file descriptor limit and can't even open it. Along those same lines: I don't understand why Linux, glibc & Co. are so gung-ho about the /proc filesystem. Some glibc routines depend on it. /proc proponents wave away the chroot jail problem because they seem to believe complex, global configuration files are somehow preferable. Whatever. They can keep their opinion. But there's no excusing the file descriptor limit issue. From emailgrant at gmail.com Sun May 4 13:54:52 2014 From: emailgrant at gmail.com (Grant) Date: Sat, 3 May 2014 20:54:52 -0700 Subject: Pulling stalls before 52MB (works via netcat) Message-ID: I can push fine over ssh but pulling via rsync or scp always stalls at about the same point which must be between 26MB and 52MB. I can pull via netcat just fine. I've tried compiling HPN out of the install on both the client and server and I've tried -C on the client with the same result. I'm on Gentoo. Any ideas? - Grant From emailgrant at gmail.com Sun May 4 13:57:26 2014 From: emailgrant at gmail.com (Grant) Date: Sat, 3 May 2014 20:57:26 -0700 Subject: Pulling stalls before 52MB (works via netcat) In-Reply-To: References: Message-ID: > I can push fine over ssh but pulling via rsync or scp always stalls at > about the same point which must be between 26MB and 52MB. I can pull > via netcat just fine. I've tried compiling HPN out of the install on > both the client and server and I've tried -C on the client with the > same result. I'm on Gentoo. Any ideas? I should have said I'm on openssh-6.6_p1-r1. - Grant From mancha1 at zoho.com Sun May 4 14:14:01 2014 From: mancha1 at zoho.com (mancha) Date: Sun, 4 May 2014 04:14:01 +0000 Subject: Pulling stalls before 52MB (works via netcat) In-Reply-To: References: Message-ID: <20140504041401.GA8580@zoho.com> On Sat, May 03, 2014 at 08:57:26PM -0700, Grant wrote: > > I can push fine over ssh but pulling via rsync or scp always stalls > > at about the same point which must be between 26MB and 52MB. I can > > pull via netcat just fine. I've tried compiling HPN out of the > > install on both the client and server and I've tried -C on the > > client with the same result. I'm on Gentoo. Any ideas? > > I should have said I'm on openssh-6.6_p1-r1. > > - Grant Hi. First off, the HPN patches will not be supported here so I recommend doing all further debugging on this issue with a pristine OpenSSH. Now, you mentioned you backed out HPN and the problem remains, so I'll assume it's not HPN related. The first thing that comes to mind is you're over-taxing Linux's selective ack's. Try disabling with: # echo 0 > /proc/sys/net/ipv4/tcp_sack If that doesn't help, let's start getting more info, maybe some packet logs around hang time and client-side and server-side logs. --mancha -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From emailgrant at gmail.com Mon May 5 02:08:44 2014 From: emailgrant at gmail.com (Grant) Date: Sun, 4 May 2014 09:08:44 -0700 Subject: Pulling stalls before 52MB (works via netcat) In-Reply-To: <20140504041401.GA8580@zoho.com> References: <20140504041401.GA8580@zoho.com> Message-ID: >> > I can push fine over ssh but pulling via rsync or scp always stalls >> > at about the same point which must be between 26MB and 52MB. I can >> > pull via netcat just fine. I've tried compiling HPN out of the >> > install on both the client and server and I've tried -C on the >> > client with the same result. I'm on Gentoo. Any ideas? >> >> I should have said I'm on openssh-6.6_p1-r1. >> > The first thing that comes to mind is you're over-taxing Linux's > selective ack's. Try disabling with: > > # echo 0 > /proc/sys/net/ipv4/tcp_sack That didn't do it but switching to MTU 576 seems to have fixed it. I suspect the root of the problem is that I'm using an AT&T modem/router with the server. I've had trouble using a proxy server there before and I discovered that the attached modem/router doesn't send ICMP responses. The solution proposed by AT&T was to put the modem/router into bridged mode but it's remote so I haven't been able to do that. Could this MTU discovery also point to the modem/router and could putting it into bridged mode solve the problem? What can I do in the meantime? Is it strange that netcat works with MTU 1500 and openssh doesn't? - Grant From chris+pine at qwirx.com Mon May 5 03:33:58 2014 From: chris+pine at qwirx.com (Chris Wilson) Date: Sun, 4 May 2014 18:33:58 +0100 (BST) Subject: Pulling stalls before 52MB (works via netcat) In-Reply-To: References: <20140504041401.GA8580@zoho.com> Message-ID: Hi Grant, On Sun, 4 May 2014, Grant wrote: >> The first thing that comes to mind is you're over-taxing Linux's >> selective ack's. Try disabling with: >> >> # echo 0 > /proc/sys/net/ipv4/tcp_sack > > That didn't do it but switching to MTU 576 seems to have fixed it. I > suspect the root of the problem is that I'm using an AT&T modem/router > with the server. I've had trouble using a proxy server there before and > I discovered that the attached modem/router doesn't send ICMP responses. > The solution proposed by AT&T was to put the modem/router into bridged > mode but it's remote so I haven't been able to do that. > > Could this MTU discovery also point to the modem/router and could > putting it into bridged mode solve the problem? What can I do in the > meantime? > > Is it strange that netcat works with MTU 1500 and openssh doesn't? I don't know what model of modem/router you're using, but I have this problem with my home Technicolor TG582n. If I try to upload large amounts of data to a system with MTU < 1500 (e.g. my office on PPPoE), it stalls immediately, not after 52 MB. It seems like a bug in the router: it doesn't forward ICMP MTU-exceeded errors received from the Internet, or does it wrongly so they're ignored by the receiving host on my LAN (which is trying to upload the data). If I replace it with an older ST516 then the problem goes away, but that router doesn't have wireless so it's less convenient. There appears to be no way to contact Technicolor to report this issue to them. I have seen problems with corruption of packets based on certain patterns appearing in them, which are more likely to hit encrypted streams randomly, while an unencrypted stream that doesn't contain the trigger sequence will almost never hit the problem. If you put it into bridged mode, it may help you for two reasons: * It may reduce your MTU (if you're bridging PPPoA to PPPoE) so that the MTU discovery problem can't happen. * It may take the modem's (suspected faulty) NAT code out of the network path. However, it might make no difference, and without isolating the problem to a corrupt ICMP message or something that's worked around by reducing the MTU to 1492, I wouldn't bet on it. Cheers, Chris. -- _____ __ _ \ __/ / ,__(_)_ | Chris Wilson Cambs UK | / (_/ ,\/ _/ /_ \ | Security/C/C++/Java/Ruby/Perl/SQL Developer | \__/_/_/_//_/___/ | We are GNU : free your mind & your software | From openssh-unix-dev at thegeezer.net Mon May 5 05:51:18 2014 From: openssh-unix-dev at thegeezer.net (TheGezer) Date: Sun, 04 May 2014 20:51:18 +0100 Subject: public key authentication -- log invalid keys In-Reply-To: References: <535A5A9E.5090408@thegeezer.net> <20140425164122.GX8684@esk.usu.edu> <535A966B.3040701@thegeezer.net> <535EAF50.9080009@thegeezer.net> <5362120C.9030402@thegeezer.net> <53634F93.9040302@thegeezer.net> Message-ID: <53669A36.20705@thegeezer.net> On 05/02/2014 09:23 AM, Damien Miller wrote: > On Fri, 2 May 2014, TheGezer wrote: > >> yeah i know, but with increasing bandwidth online, and more and more >> folks using vps with just a public key a silent distributed attack could >> go on for a couple of years without anything more than just lots of >> mysterious connection attempts in the logs > If you think that such an attack might only take "years" then you > haven't done the math. i hear you, i really do, but [1] there is more than one way [2] to skin a cat, and it's a shame to have other's issues (in these two cases bad random number generators) go unseen due to insufficient logs -- verbose logging tends only to be turned on for troubleshooting reasons. [1]http://taint.org/2008/05/16/165301a.html [2]http://www.darkreading.com/vulnerabilities-and-threats/cryptographers-discover-public-key-infrastructure-flaw/d/d-id/1102851? > >> also consider internal breach attempts sitting inside the perimeter >> >> and consider that if most people lose their client public key through >> theft or other they would typically just delete the authkey on the >> server rather than put it in revoked keys so logging bad attempts would >> catch these guys too >> >> personally, i'm going to patch my sources to have bad attempts logged at >> a lower loglevel > ... or you could make a one line config change. yeah true. over many systems i'm wondering which would be the easier to do, but that's a seperate issue > > -d From namedylan at gmail.com Mon May 5 06:37:09 2014 From: namedylan at gmail.com (Fengwei Zhang) Date: Sun, 4 May 2014 16:37:09 -0400 Subject: Memory Forensics of OpenSSH Message-ID: Hello List, One of my project needs memory forensics of OpenSSH. Here is a brief description of the problem: I have a raw memory dump, and all of the kernel data structures (e.g., task_struct, mm_struct) have been figured out. Now, I want to retrieve the data structures (e.g., struct session_state) of an SSH process instance. Finding a session key (active_state->newkeys) could be an example. In order to find these information, I think I need a starting point (i.e., memory address) of the OpenSSH data structures. Does anyone know how to tackle this problem? Any comments and suggestions are much appreciated. Thanks, Fengwei From cal.leeming at simplicitymedialtd.co.uk Mon May 5 06:49:23 2014 From: cal.leeming at simplicitymedialtd.co.uk (Cal Leeming [Simplicity Media Ltd]) Date: Sun, 4 May 2014 21:49:23 +0100 Subject: Memory Forensics of OpenSSH In-Reply-To: References: Message-ID: Although I cannot speak with any authority on the data structures of SSH, I can at least point you in the right direction on tools already available. Looks like someone also wrote a tool already to do SSH key extraction from memory; https://github.com/kholia/passe-partout Have a look at volatility framework; https://code.google.com/p/volatility/wiki/VolatilityIntroduction?tm=6 http://www.forensicswiki.org/wiki/Volatility_Framework http://www.forensicswiki.org/wiki/List_of_Volatility_Plugins Also these; http://sneakygcr.tumblr.com/post/52514790216/how-to-extract-the-private-key-from-a-running-ssh http://c0decstuff.blogspot.co.uk/2011/01/in-memory-extraction-of-ssl-private.html http://www.vnsecurity.net/2009/10/how-to-recover-rsa-private-key-in-a-coredump-of-ssh-agent-sapheads-hackjam-2009-challenge-6/ Hope this helps Cal On Sun, May 4, 2014 at 9:37 PM, Fengwei Zhang wrote: > Hello List, > > One of my project needs memory forensics of OpenSSH. Here is a brief > description of the problem: > > I have a raw memory dump, and all of the kernel data structures (e.g., > task_struct, mm_struct) have been figured out. Now, I want to retrieve the > data structures (e.g., struct session_state) of an SSH process instance. > Finding a session key (active_state->newkeys) could be an example. In > order to find these information, I think I need a starting point (i.e., > memory address) of the OpenSSH data structures. > > Does anyone know how to tackle this problem? Any comments and suggestions > are much appreciated. > > Thanks, > Fengwei > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From keisial at gmail.com Mon May 5 06:56:03 2014 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Sun, 04 May 2014 22:56:03 +0200 Subject: Regarding the optional OpenSSL integration for the portable version In-Reply-To: <20140502194000.GB24093@wilbur.25thandClement.com> References: <20140502194000.GB24093@wilbur.25thandClement.com> Message-ID: <5366A963.7020603@gmail.com> On 02/05/14 21:40, William Ahern wrote: > Linux > also has an obscure sysctl which pulls directly from the internal CSPRNG. So > all of these will work in a jail without /dev or /proc. That's cool, but as stated on Linux sysctl(2): > NOTES > Glibc does not provide a wrapper for this system call; call it > using syscall(2). Or rather... don't call it: use of > this system call has long been discouraged, and it is so > unloved that it is likely to disappear in a future kernel > version. Since Linux 2.6.24, uses of this system call > result in warnings in the kernel log. Remove it from your > programs now; use the /proc/sys interface instead. > > This system call is available only if the kernel was configured > with the CONFIG_SYSCTL_SYSCALL option. And indeed, trying a test program calling CTL_KERN, KERN_RANDOM, RANDOM_UUID (from your code) prints > warning: process `sysctl-rand' used the deprecated sysctl system call > with 1.40.6. and returned with ENOSYS (the kernel was compiled without CONFIG_SYSCTL_SYSCALL). So I don't think it's a suitable primary mean to gather random data under Linux. :-( I encourage you to raise at lkml the need to have a dev-less random data source, though. From william at 25thandClement.com Mon May 5 09:08:35 2014 From: william at 25thandClement.com (William Ahern) Date: Sun, 4 May 2014 16:08:35 -0700 Subject: Regarding the optional OpenSSL integration for the portable version In-Reply-To: <5366A963.7020603@gmail.com> References: <20140502194000.GB24093@wilbur.25thandClement.com> <5366A963.7020603@gmail.com> Message-ID: <20140504230835.GA16590@wilbur.25thandClement.com> On Sun, May 04, 2014 at 10:56:03PM +0200, ?ngel Gonz?lez wrote: > On 02/05/14 21:40, William Ahern wrote: > >Linux > >also has an obscure sysctl which pulls directly from the internal CSPRNG. > >So > >all of these will work in a jail without /dev or /proc. > > That's cool, but as stated on Linux sysctl(2): > > This system call is available only if the kernel was configured > >with the CONFIG_SYSCTL_SYSCALL option. > > And indeed, trying a test program calling CTL_KERN, KERN_RANDOM, > RANDOM_UUID (from your code) prints > >warning: process `sysctl-rand' used the deprecated sysctl system call > >with 1.40.6. > > and returned with ENOSYS (the kernel was compiled without > CONFIG_SYSCTL_SYSCALL). > > So I don't think it's a suitable primary mean to gather random data > under Linux. :-( It still works on the latest Ubuntu, but I see now that Red Hat (Fedora Rawhide) has disabled it. So much for ABI stability. glibc says lots of stupid stuff in their manual pages, but I didn't think Linux would actually break it this way, given how much of a stink Linus makes about preserving userspace compatibility. In any event, it's still the only proper solution. Otherwise there is no reliable means and Linux can just be considered second-class in this regard, like Solaris, OS X, and others. Of course it's smart to always check the return value and have a fallback in case some people thoughtlessly turned it off. My sample code I linked to does fallback to /dev/urandom, as well as [somewhat ashamedly] collects junk data in a last ditch effort, including collecting bits from ASLR, getrusage, and uname. > I encourage you to raise at lkml the need to have a dev-less random data > source, though. They tend to ignore unknown people on LKML. I once submitted a bug report about datagram connect(2) behavior where you couldn't change the destination address if it was on another network, despite the manual pages (and POSIX) saying that it would work. I doubt anybody even bothered reading it, and of course nobody replied. I'll give it a try, though. I'll also try contacting Red Hat, and inquire with the Debian and Ubuntu folks to see if they intended to change their configuration. From peter at stuge.se Mon May 5 09:45:02 2014 From: peter at stuge.se (Peter Stuge) Date: Mon, 5 May 2014 01:45:02 +0200 Subject: Regarding the optional OpenSSL integration for the portable version In-Reply-To: <20140504230835.GA16590@wilbur.25thandClement.com> References: <20140502194000.GB24093@wilbur.25thandClement.com> <5366A963.7020603@gmail.com> <20140504230835.GA16590@wilbur.25thandClement.com> Message-ID: <20140504234502.30546.qmail@stuge.se> William Ahern wrote: > > I encourage you to raise at lkml the need to have a dev-less random data > > source, though. > > They tend to ignore unknown people on LKML. I once submitted a bug report So you sent a bug report to a mailing list (instead of the bug tracker) and from the lack of responses you infer that everyone who is unknown is ignored? That doesn't make any sense. Report bugs in bugzilla and discuss on the list. I'm sure you'll have a better experience that way. I too think it would make sense to discuss this issue on the list. I think you should also make sure to include the appropriate kernel-side maintainers in Cc, so that they will participate in the discussion from the start. > I'll also try contacting Red Hat, and inquire with the Debian and > Ubuntu folks to see if they intended to change their configuration. I'd suggest that you start by asking them how they view the situation, rather than starting by assuming that they should change anything. //Peter From busterb at gmail.com Mon May 5 12:48:15 2014 From: busterb at gmail.com (Brent Cook) Date: Sun, 4 May 2014 21:48:15 -0500 Subject: Regarding the optional OpenSSL integration for the portable version In-Reply-To: <5366A963.7020603@gmail.com> References: <20140502194000.GB24093@wilbur.25thandClement.com> <5366A963.7020603@gmail.com> Message-ID: <50F038BB-9823-4ED2-B7C3-953C49C2B9A0@gmail.com> On May 4, 2014, at 3:56 PM, ?ngel Gonz?lez wrote: > On 02/05/14 21:40, William Ahern wrote: >> Linux >> also has an obscure sysctl which pulls directly from the internal CSPRNG. So >> all of these will work in a jail without /dev or /proc. > > That's cool, but as stated on Linux sysctl(2): >> NOTES >> Glibc does not provide a wrapper for this system call; call it using syscall(2). Or rather... don't call it: use of >> this system call has long been discouraged, and it is so unloved that it is likely to disappear in a future kernel >> version. Since Linux 2.6.24, uses of this system call result in warnings in the kernel log. Remove it from your >> programs now; use the /proc/sys interface instead. >> >> This system call is available only if the kernel was configured with the CONFIG_SYSCTL_SYSCALL option. > > And indeed, trying a test program calling CTL_KERN, KERN_RANDOM, RANDOM_UUID (from your code) prints >> warning: process `sysctl-rand' used the deprecated sysctl system call with 1.40.6. > > and returned with ENOSYS (the kernel was compiled without CONFIG_SYSCTL_SYSCALL). > > > So I don't think it's a suitable primary mean to gather random data under Linux. :-( > > I encourage you to raise at lkml the need to have a dev-less random data source, though. > libevent?s RNG mentions similar issues: https://github.com/libevent/libevent/blob/master/arc4random.c#L340 Any opinion on HAVEGE as an additional entropy source? PolarSSL / XYSSL appear to use it as their primary source of entropy. I extracted the main bits from the last BSD release of XYSSL for testing: https://gist.github.com/busterb/631e2cf61a55de87d6b8 Seems like it might be better than concatenating a lot of ?junk? when all else fails, at least if you can trust the cycle counter to do the right thing (maybe not in a VM). Botan also has a few novel sources of entropy implemented like process walk times and running random processes (like PRNGD does): https://github.com/randombit/botan/tree/net.randombit.botan/src/lib/entropy I have to admit I?m surprised at the number of projects that have sort-of solved this problem independently. It seems like an entropy gathering library could live as a standalone project. From emailgrant at gmail.com Tue May 6 07:57:30 2014 From: emailgrant at gmail.com (Grant) Date: Mon, 5 May 2014 14:57:30 -0700 Subject: Pulling stalls before 52MB (works via netcat) In-Reply-To: References: <20140504041401.GA8580@zoho.com> Message-ID: >>> The first thing that comes to mind is you're over-taxing Linux's >>> selective ack's. Try disabling with: >>> >>> # echo 0 > /proc/sys/net/ipv4/tcp_sack >> >> >> That didn't do it but switching to MTU 576 seems to have fixed it. I >> suspect the root of the problem is that I'm using an AT&T modem/router with >> the server. I've had trouble using a proxy server there before and I >> discovered that the attached modem/router doesn't send ICMP responses. The >> solution proposed by AT&T was to put the modem/router into bridged mode but >> it's remote so I haven't been able to do that. >> >> Could this MTU discovery also point to the modem/router and could putting >> it into bridged mode solve the problem? What can I do in the meantime? >> >> Is it strange that netcat works with MTU 1500 and openssh doesn't? > > > I don't know what model of modem/router you're using, but I have this > problem with my home Technicolor TG582n. If I try to upload large amounts of > data to a system with MTU < 1500 (e.g. my office on PPPoE), it stalls > immediately, not after 52 MB. > > It seems like a bug in the router: it doesn't forward ICMP MTU-exceeded > errors received from the Internet, or does it wrongly so they're ignored by > the receiving host on my LAN (which is trying to upload the data). If I > replace it with an older ST516 then the problem goes away, but that router > doesn't have wireless so it's less convenient. There appears to be no way to > contact Technicolor to report this issue to them. > > I have seen problems with corruption of packets based on certain patterns > appearing in them, which are more likely to hit encrypted streams randomly, > while an unencrypted stream that doesn't contain the trigger sequence will > almost never hit the problem. > > If you put it into bridged mode, it may help you for two reasons: > > * It may reduce your MTU (if you're bridging PPPoA to PPPoE) so that the MTU > discovery problem can't happen. > > * It may take the modem's (suspected faulty) NAT code out of the network > path. > > However, it might make no difference, and without isolating the problem to a > corrupt ICMP message or something that's worked around by reducing the MTU > to 1492, I wouldn't bet on it. Since setting the MTU to 576 fixes the problem, what do I lose by leaving it there? Does that reduce bandwidth significantly? - Grant From mancha1 at zoho.com Tue May 6 08:03:19 2014 From: mancha1 at zoho.com (mancha) Date: Mon, 5 May 2014 22:03:19 +0000 Subject: Fwd: [oss-security] *Possible* ssh vulnerability Message-ID: <20140505220244.GA31347@zoho.com> FYI ----- Forwarded message from RbN ----- > Date: Mon, 05 May 2014 19:40:02 +0200 > From: RbN > To: oss-security at lists.openwall.com > Subject: [oss-security] *Possible* ssh vulnerability > User-Agent: mutt (compatible Hurd 3.11/Windows 0.5) > > Looks like a fake, but I prefer to post it here anyway: > http://pastebin.com/gjkivAf3 > > If anybody gets more info about it, please share ;) > > > -- > RbN > Archlinux CVE monitoring team ----- End forwarded message ----- -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From djm at mindrot.org Tue May 6 09:29:52 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 6 May 2014 09:29:52 +1000 (EST) Subject: Fwd: [oss-security] *Possible* ssh vulnerability In-Reply-To: <20140505220244.GA31347@zoho.com> References: <20140505220244.GA31347@zoho.com> Message-ID: yeah, looks like BS for a number of reasons but I'm going to poke around for it anyway. The memory dump seems in indicate a post-auth process (and possibly sftp-server/internal-sftp), so it's surprising it could see the password hash to begin with and it would be highly unlikely to see anything else that is sensitive. On Mon, 5 May 2014, mancha wrote: > FYI > > ----- Forwarded message from RbN ----- > > > Date: Mon, 05 May 2014 19:40:02 +0200 > > From: RbN > > To: oss-security at lists.openwall.com > > Subject: [oss-security] *Possible* ssh vulnerability > > User-Agent: mutt (compatible Hurd 3.11/Windows 0.5) > > > > Looks like a fake, but I prefer to post it here anyway: > > http://pastebin.com/gjkivAf3 > > > > If anybody gets more info about it, please share ;) > > > > > > -- > > RbN > > Archlinux CVE monitoring team > > ----- End forwarded message ----- > From dirkx at webweaving.org Tue May 6 21:15:02 2014 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Tue, 6 May 2014 13:15:02 +0200 Subject: Supporting smartcard readers with PIN entry keypads Message-ID: Folks, Find below a minor patch to allow the use of smartcards in readers that have their own PIN entry keypads (Secure PIN entry) such as the SPR332 and most german/medical chipcard devices. Tested on Solaris, FreeBSD and MacOSX against various cards and drivers. I?ve left the pkcs11_interactive check in place. Arguably - with some Secure PIN readers it may be better to move this just in front of the keyboard entry ONLY; as there are some secure PIN keypads that use means which are somewhat suitable to unattended operation. But I thought it better to let this wait until an actual use case warrants this and/or the need for a special flag/argument to control such. Thanks, Dw. diff -ur openssh-6.2p2.orig/ssh-pkcs11.c openssh-6.2p2/ssh-pkcs11.c --- openssh-6.2p2.orig/ssh-pkcs11.c 2011-09-04 11:59:26.000000000 +0200 +++ openssh-6.2p2/ssh-pkcs11.c 2014-05-06 13:03:15.000000000 +0200 @@ -256,21 +256,29 @@ si = &k11->provider->slotinfo[k11->slotidx]; if ((si->token.flags & CKF_LOGIN_REQUIRED) && !si->logged_in) { if (!pkcs11_interactive) { - error("need pin"); + error("need pin entry%s", + (si->token.flags & CKF_PROTECTED_AUTHENTICATION_PATH) ? " on reader keypad" : ""); return (-1); } - snprintf(prompt, sizeof(prompt), "Enter PIN for '%s': ", - si->token.label); - pin = read_passphrase(prompt, RP_ALLOW_EOF); - if (pin == NULL) - return (-1); /* bail out */ - if ((rv = f->C_Login(si->session, CKU_USER, pin, strlen(pin))) + if (si->token.flags & CKF_PROTECTED_AUTHENTICATION_PATH) { + verbose("Deferring PIN entry to keypad of chipcard reader."); + pin = NULL; + } else { + snprintf(prompt, sizeof(prompt), "Enter PIN for '%s': ", + si->token.label); + pin = read_passphrase(prompt, RP_ALLOW_EOF); + if (pin == NULL) + return (-1); /* bail out */ + }; + if ((rv = f->C_Login(si->session, CKU_USER, pin, pin ? strlen(pin): 0)) != CKR_OK) { - xfree(pin); + if (pin) + xfree(pin); error("C_Login failed: %lu", rv); return (-1); - } - xfree(pin); + } + if (pin) + xfree(pin); si->logged_in = 1; } key_filter[1].pValue = k11->keyid; Only in openssh-6.2p2: ssh-pkcs11.o From namedylan at gmail.com Wed May 7 08:01:26 2014 From: namedylan at gmail.com (Fengwei Zhang) Date: Tue, 6 May 2014 18:01:26 -0400 Subject: Memory Forensics of OpenSSH In-Reply-To: References: Message-ID: <73623B18-37FF-48C7-BA4E-36F6D405128D@gmail.com> Hello Cal, Thanks for sharing these great links. These articles use a characteristic of RSA/DSA structure, and search the structure in process memory to extract the private key. It verifies the structure by using the RSA/DSA algorithm. However, my goal is to find the session key (in the struct session_state), and the techniques from the articles won't work because we cannot validate the session_state (or the related) structures (i.e., no validating algorithm). So I am wondering if there is any SSH data structure with a fixed offset from somewhere (e.g., 0xdead from text_base). Or if there is any data structure with a characteristic that I can search? Thanks, Fengwei On May 4, 2014, at 4:49 PM, Cal Leeming [Simplicity Media Ltd] wrote: > Although I cannot speak with any authority on the data structures of SSH, I can at least point you in the right direction on tools already available. > > Looks like someone also wrote a tool already to do SSH key extraction from memory; > https://github.com/kholia/passe-partout > > Have a look at volatility framework; > https://code.google.com/p/volatility/wiki/VolatilityIntroduction?tm=6 > http://www.forensicswiki.org/wiki/Volatility_Framework > http://www.forensicswiki.org/wiki/List_of_Volatility_Plugins > > Also these; > http://sneakygcr.tumblr.com/post/52514790216/how-to-extract-the-private-key-from-a-running-ssh > http://c0decstuff.blogspot.co.uk/2011/01/in-memory-extraction-of-ssl-private.html > http://www.vnsecurity.net/2009/10/how-to-recover-rsa-private-key-in-a-coredump-of-ssh-agent-sapheads-hackjam-2009-challenge-6/ > > Hope this helps > > Cal > > > > On Sun, May 4, 2014 at 9:37 PM, Fengwei Zhang wrote: > Hello List, > > One of my project needs memory forensics of OpenSSH. Here is a brief description of the problem: > > I have a raw memory dump, and all of the kernel data structures (e.g., task_struct, mm_struct) have been figured out. Now, I want to retrieve the data structures (e.g., struct session_state) of an SSH process instance. Finding a session key (active_state->newkeys) could be an example. In order to find these information, I think I need a starting point (i.e., memory address) of the OpenSSH data structures. > > Does anyone know how to tackle this problem? Any comments and suggestions are much appreciated. > > Thanks, > Fengwei > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From aris at 0xbadc0de.be Thu May 8 02:17:03 2014 From: aris at 0xbadc0de.be (Aris Adamantiadis) Date: Wed, 07 May 2014 18:17:03 +0200 Subject: Memory Forensics of OpenSSH In-Reply-To: <73623B18-37FF-48C7-BA4E-36F6D405128D@gmail.com> References: <73623B18-37FF-48C7-BA4E-36F6D405128D@gmail.com> Message-ID: <536A5C7F.8040009@0xbadc0de.be> Hi Fengwei, I wouldn't want to do the work in your place myself, but it's pretty straightforward. It's relatively easy to open the openssh .h files that describe the data structures and scan for matching patterns in the memory. For instance, a pointer would point to either some mapped memory or 0, when it would be unlikely for an integer to be a valid pointer. Also, all cryptographic primitives (like AES) leave very distinct traces in the memory. "all" you have to do is to find pointers referencing them and scan the memory bottom-up. I also think many data structures are allocated on the bss. In that case it's not even needed to bruteforce the memory to find what you need. Regards, Aris Le 7/05/14 00:01, Fengwei Zhang a ?crit : > Hello Cal, > > Thanks for sharing these great links. These articles use a characteristic of RSA/DSA structure, and search the structure in process memory to extract the private key. > It verifies the structure by using the RSA/DSA algorithm. > > However, my goal is to find the session key (in the struct session_state), and the techniques from the articles won't work because we cannot validate the session_state (or the related) structures (i.e., no validating algorithm). > > So I am wondering if there is any SSH data structure with a fixed offset from somewhere (e.g., 0xdead from text_base). Or if there is any data structure with a characteristic that I can search? > > Thanks, > Fengwei > > On May 4, 2014, at 4:49 PM, Cal Leeming [Simplicity Media Ltd] wrote: > >> Although I cannot speak with any authority on the data structures of SSH, I can at least point you in the right direction on tools already available. >> >> Looks like someone also wrote a tool already to do SSH key extraction from memory; >> https://github.com/kholia/passe-partout >> >> Have a look at volatility framework; >> https://code.google.com/p/volatility/wiki/VolatilityIntroduction?tm=6 >> http://www.forensicswiki.org/wiki/Volatility_Framework >> http://www.forensicswiki.org/wiki/List_of_Volatility_Plugins >> >> Also these; >> http://sneakygcr.tumblr.com/post/52514790216/how-to-extract-the-private-key-from-a-running-ssh >> http://c0decstuff.blogspot.co.uk/2011/01/in-memory-extraction-of-ssl-private.html >> http://www.vnsecurity.net/2009/10/how-to-recover-rsa-private-key-in-a-coredump-of-ssh-agent-sapheads-hackjam-2009-challenge-6/ >> >> Hope this helps >> >> Cal >> >> >> >> On Sun, May 4, 2014 at 9:37 PM, Fengwei Zhang wrote: >> Hello List, >> >> One of my project needs memory forensics of OpenSSH. Here is a brief description of the problem: >> >> I have a raw memory dump, and all of the kernel data structures (e.g., task_struct, mm_struct) have been figured out. Now, I want to retrieve the data structures (e.g., struct session_state) of an SSH process instance. Finding a session key (active_state->newkeys) could be an example. In order to find these information, I think I need a starting point (i.e., memory address) of the OpenSSH data structures. >> >> Does anyone know how to tackle this problem? Any comments and suggestions are much appreciated. >> >> Thanks, >> Fengwei >> _______________________________________________ >> 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 mlindgren at runelind.net Thu May 8 10:50:25 2014 From: mlindgren at runelind.net (Mattias Lindgren) Date: Wed, 7 May 2014 18:50:25 -0600 Subject: bug or feature with ssh-keygen and user CAs? Message-ID: <9E2D0C93A68E426C809CBFEA382FE18A@runelind.net> I have confirmed this behavior from OpenSSH 6.6 in OS X (from MacPorts) and 6.6 in Ubuntu. I have set up a SSH Certificate authority, and as such I put in the following line at the top of my known_hosts file @cert-authority *.mydomain.com ssh-rsa Below this are all my hashed entries for various other hosts that I?ve contacted over the years. Every once in a while I?ll rebuild a box in my environment, and the ssh key will change. To clean up my known_hosts file to allow me to re-insert the new entry, I will do ssh-keygen -R . This has the unintended consequence of matching on the offending entry in the known_hosts file *and* my cert-authority entry: $ ssh-keygen -R 10.50.3.149 # Host 10.50.3.149 found: line 1 type RSA # Host 10.50.3.149 found: line 512 type ECDSA /Users/mlindgren/.ssh/known_hosts updated. Original contents retained as /Users/mlindgren/.ssh/known_hosts.old Am I missing something fundamental here? Thanks, Mattias From djm at mindrot.org Thu May 8 14:48:13 2014 From: djm at mindrot.org (Damien Miller) Date: Thu, 8 May 2014 14:48:13 +1000 (EST) Subject: bug or feature with ssh-keygen and user CAs? In-Reply-To: <9E2D0C93A68E426C809CBFEA382FE18A@runelind.net> References: <9E2D0C93A68E426C809CBFEA382FE18A@runelind.net> Message-ID: On Wed, 7 May 2014, Mattias Lindgren wrote: > Every once in a while I?ll rebuild a box in my environment, and the > ssh key will change. To clean up my known_hosts file to allow me to > re-insert the new entry, I will do ssh-keygen -R . This has the > unintended consequence of matching on the offending entry in the > known_hosts file *and* my cert-authority entry: > > $ ssh-keygen -R 10.50.3.149 > # Host 10.50.3.149 found: line 1 type RSA > # Host 10.50.3.149 found: line 512 type ECDSA > /Users/mlindgren/.ssh/known_hosts updated. > Original contents retained as /Users/mlindgren/.ssh/known_hosts.old > > Am I missing something fundamental here? No, that's a bug. Could you file it at https://bugzilla.mindrot.org/ ? -d From freq440 at gmail.com Thu May 8 22:17:22 2014 From: freq440 at gmail.com (f440) Date: Thu, 8 May 2014 21:17:22 +0900 Subject: Match directive can't recognize capital letters Message-ID: Hi, There seems to be an issue when using `Match` and `Hostname` directives including capital letters. e.g. # .ssh/config # # Match host remotehost # User alice # Host remotehost # User bob # ssh remotehost #=> Apply "User alice" # .ssh/config # # Match host RemoteHost # User alice # Host RemoteHost # User bob # ssh RemoteHost # => Apply "User bob" I'm using "OpenSSH_6.6p1, OpenSSL 0.9.8y 5 Feb 2013" from source. Thanks. From mloftis at wgops.com Fri May 9 01:26:51 2014 From: mloftis at wgops.com (Michael Loftis) Date: Thu, 8 May 2014 08:26:51 -0700 Subject: Match directive can't recognize capital letters In-Reply-To: References: Message-ID: On Thu, May 8, 2014 at 5:17 AM, f440 wrote: > Hi, > > There seems to be an issue when using `Match` and `Hostname` > directives including capital letters. I don't know where you are, but, on the internet, hostnames aren't case sensitive. -- "Genius might be described as a supreme capacity for getting its possessors into trouble of all kinds." -- Samuel Butler From mloftis at wgops.com Fri May 9 01:28:25 2014 From: mloftis at wgops.com (Michael Loftis) Date: Thu, 8 May 2014 08:28:25 -0700 Subject: Match directive can't recognize capital letters In-Reply-To: References: Message-ID: On Thu, May 8, 2014 at 8:26 AM, Michael Loftis wrote: > On Thu, May 8, 2014 at 5:17 AM, f440 wrote: >> Hi, >> >> There seems to be an issue when using `Match` and `Hostname` >> directives including capital letters. > > I don't know where you are, but, on the internet, hostnames aren't > case sensitive. Which, is to say, that what you're asking for appears to be ambiguous to me. SSH should probably stop on the first match in the file though is what you're asking for? From freq440 at gmail.com Fri May 9 03:28:37 2014 From: freq440 at gmail.com (f440) Date: Fri, 9 May 2014 02:28:37 +0900 Subject: Match directive can't recognize capital letters In-Reply-To: References: Message-ID: Hi, Michael. >> There seems to be an issue when using `Match` and `Hostname` >> directives including capital letters. > I don't know where you are, but, on the internet, hostnames aren't case sensitive. Sorry, it's my mistake. I'm concerned about `Match` and `Host` directives. Furthermore, example code was inappropriate. Revised version is here: # (1) # # Match host remotehost # User alice # Host remotehost # User bob # Hostname remotehost.example.com # ssh remotehost #=> Apply "User alice" # (2) # # Match host RemoteHost # User alice # Host RemoteHost # User bob # Hostname remotehost.example.com # ssh RemoteHost # => Apply "User bob" > Which, is to say, that what you're asking for appears to be ambiguous to me. SSH should probably stop on the first match in the file though is what you're asking for? yes. (2) is unexpected behavior for me. On Fri, May 9, 2014 at 12:28 AM, Michael Loftis wrote: > On Thu, May 8, 2014 at 8:26 AM, Michael Loftis wrote: >> On Thu, May 8, 2014 at 5:17 AM, f440 wrote: >>> Hi, >>> >>> There seems to be an issue when using `Match` and `Hostname` >>> directives including capital letters. >> >> I don't know where you are, but, on the internet, hostnames aren't >> case sensitive. > > Which, is to say, that what you're asking for appears to be ambiguous > to me. SSH should probably stop on the first match in the file though > is what you're asking for? From des at des.no Fri May 9 20:08:04 2014 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Fri, 09 May 2014 12:08:04 +0200 Subject: Fwd: [oss-security] *Possible* ssh vulnerability In-Reply-To: (Damien Miller's message of "Tue, 6 May 2014 09:29:52 +1000 (EST)") References: <20140505220244.GA31347@zoho.com> Message-ID: <86mwerjmd7.fsf@nine.des.no> Damien Miller writes: > The memory dump seems in indicate a post-auth process (and possibly > sftp-server/internal-sftp), so it's surprising it could see the > password hash to begin with and it would be highly unlikely to see > anything else that is sensitive. (caveat: my recollection of the privsep model is slightly hazy; is there a whitepaper somewhere?) The unprivileged parent can contain a copy of /etc/shadow from calling getpwnam() at some point before do_setusercontext(). This hypothesis is strengthened by the fact that the passwd line in the dump looks like it has been parsed for use in a struct passwd: the text fields are terminated by NULs instead of colons, but the numeric fields aren't because strtoul() doesn't require it. This passwd line seems to have overwritten a previous, longer passwd line for a user whose home directory (and presumably login) ends with "oe" and who uses zsh instead of bash. However, that process's /proc/*/mem is only readable by root since it started out with root credentials. The most intriguing thing about this dump is that it seems to contain a hex dump of a syslog message from Linux-PAM's pam_unix (starting at 002516d0). I wouldn't be surprised to see the message itself, since this is the same process that called pam_open_session(), but I really wouldn't expect a hex dump of that message. On the whole, I agree that it is most likely a hoax. DES -- Dag-Erling Sm?rgrav - des at des.no From pcerny at suse.cz Fri May 9 20:13:14 2014 From: pcerny at suse.cz (Petr Cerny) Date: Fri, 09 May 2014 12:13:14 +0200 Subject: Regarding the optional OpenSSL integration for the portable version In-Reply-To: <20140504234502.30546.qmail@stuge.se> References: <20140502194000.GB24093@wilbur.25thandClement.com> <5366A963.7020603@gmail.com> <20140504230835.GA16590@wilbur.25thandClement.com> <20140504234502.30546.qmail@stuge.se> Message-ID: <536CAA3A.4060406@suse.cz> Peter Stuge wrote: > William Ahern wrote: >> > I encourage you to raise at lkml the need to have a dev-less random data >> > source, though. >> >> They tend to ignore unknown people on LKML. I once submitted a bug report > > So you sent a bug report to a mailing list (instead of the bug tracker) and > from the lack of responses you infer that everyone who is unknown is ignored? > > That doesn't make any sense. Report bugs in bugzilla and discuss on the list. > > I'm sure you'll have a better experience that way. Actually, for the Linux kernel the right way to do it is through a mailing list indeed, although not the general LKML. See the MAINTAINERS file in kernel source tree. Cheers Petr From mfriedl at gmail.com Mon May 12 18:39:49 2014 From: mfriedl at gmail.com (Markus Friedl) Date: Mon, 12 May 2014 10:39:49 +0200 Subject: [oss-security] *Possible* ssh vulnerability In-Reply-To: <86mwerjmd7.fsf@nine.des.no> References: <20140505220244.GA31347@zoho.com> <86mwerjmd7.fsf@nine.des.no> Message-ID: <3F9D7361-2E9A-4F81-A6AB-7A82C52FC518@gmail.com> Am 09.05.2014 um 12:08 schrieb Dag-Erling Sm?rgrav : > Damien Miller writes: >> The memory dump seems in indicate a post-auth process (and possibly >> sftp-server/internal-sftp), so it's surprising it could see the >> password hash to begin with and it would be highly unlikely to see >> anything else that is sensitive. > > (caveat: my recollection of the privsep model is slightly hazy; is there > a whitepaper somewhere?) http://www.citi.umich.edu/u/provos/ssh/privsep.html -m From dirkx at webweaving.org Mon May 12 22:38:10 2014 From: dirkx at webweaving.org (Dirk-Willem van Gulik) Date: Mon, 12 May 2014 14:38:10 +0200 Subject: [patch] Supporting smartcard readers with PIN entry keypads (updated against -HEAD) Message-ID: <07093DD8-E2A1-4584-9A2E-C7365C251A39@webweaving.org> Repost; updated for HEAD and tested on ubuntu as well. Dw. Folks, Find below a minor patch to allow the use of smartcards in readers that have their own PIN entry keypads (Secure PIN entry) such as the SPR332 and most german/medical chipcard devices. Tested on Solaris, FreeBSD, Linux and MacOSX against various cards and drivers. I?ve left the pkcs11_interactive check in place. Arguably - with some Secure PIN readers it may be better to move this just in front of the keyboard entry ONLY; as there are some secure PIN keypads that use means which are somewhat suitable to unattended operation. But I thought it better to let this wait until an actual use case warrants this and/or the need for a special flag/argument to control such. Thanks, Dw. Index: ssh-pkcs11.c =================================================================== RCS file: /cvs/openssh/ssh-pkcs11.c,v retrieving revision 1.15 diff -u -w -r1.15 ssh-pkcs11.c --- ssh-pkcs11.c 20 Apr 2014 03:21:23 -0000 1.15 +++ ssh-pkcs11.c 12 May 2014 12:34:25 -0000 @@ -255,21 +255,29 @@ si = &k11->provider->slotinfo[k11->slotidx]; if ((si->token.flags & CKF_LOGIN_REQUIRED) && !si->logged_in) { if (!pkcs11_interactive) { - error("need pin"); + error("need pin entry%s", + (si->token.flags & CKF_PROTECTED_AUTHENTICATION_PATH) ? " on reader keypad" : ""); return (-1); } + if (si->token.flags & CKF_PROTECTED_AUTHENTICATION_PATH) { + verbose("Deferring PIN entry to keypad of chipcard reader."); + pin = NULL; + } else { snprintf(prompt, sizeof(prompt), "Enter PIN for '%s': ", si->token.label); pin = read_passphrase(prompt, RP_ALLOW_EOF); if (pin == NULL) return (-1); /* bail out */ - if ((rv = f->C_Login(si->session, CKU_USER, - (u_char *)pin, strlen(pin))) != CKR_OK) { - free(pin); + }; + if ((rv = f->C_Login(si->session, CKU_USER, pin, pin ? strlen(pin): 0)) + != CKR_OK) { + if (pin) + xfree(pin); error("C_Login failed: %lu", rv); return (-1); } - free(pin); + if (pin) + xfree(pin); si->logged_in = 1; } key_filter[1].pValue = k11->keyid; From imgx64 at gmail.com Thu May 15 02:20:05 2014 From: imgx64 at gmail.com (Ibrahim M. Ghazal) Date: Wed, 14 May 2014 19:20:05 +0300 Subject: Waiting until tunnel (ssh -w) is set up before running command Message-ID: When using VPN tunnelling (-w option), is there a way to know when the tunnel is actually up? I want to use this in a script that automatically sets up the tunnel by running ssh -w then running ifup [1]. The -f option doesn't help because it returns after connecting to the server but before the tunnel is up. Sleeping for a few seconds does work, but it just feels too hacky. The LocalCommand option seems to work, for example: ssh -w 0:1 "-oLocalCommand=ifup tun0" "-oPermitLocalCommand=yes" myserver.example.org true However, the man page says: "The command is run synchronously and does not have access to the session of the ssh(1) that spawned it." Is the above invocation guaranteed to work or was it just luck that LocalCommand was executed after the tunnel is set up? More importantly, is there a standard way for using ssh -w in scripts? [1] I'm on Fedora, ifup works because I've set up /etc/sysconfig/network-scripts/ifcfg-tun0 and /etc/sysconfig/network-scripts/route-tun0 From des at des.no Thu May 15 03:00:58 2014 From: des at des.no (=?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?=) Date: Wed, 14 May 2014 19:00:58 +0200 Subject: [oss-security] *Possible* ssh vulnerability In-Reply-To: <3F9D7361-2E9A-4F81-A6AB-7A82C52FC518@gmail.com> (Markus Friedl's message of "Mon, 12 May 2014 10:39:49 +0200") References: <20140505220244.GA31347@zoho.com> <86mwerjmd7.fsf@nine.des.no> <3F9D7361-2E9A-4F81-A6AB-7A82C52FC518@gmail.com> Message-ID: <864n0snvlh.fsf@nine.des.no> Markus Friedl writes: > http://www.citi.umich.edu/u/provos/ssh/privsep.html Thank you, that was very useful! DES -- Dag-Erling Sm?rgrav - des at des.no From cloos at jhcloos.com Thu May 15 04:13:19 2014 From: cloos at jhcloos.com (James Cloos) Date: Wed, 14 May 2014 14:13:19 -0400 Subject: Update on sshfp 4 Message-ID: The IANA has pre-allocated id 4 for ed25519. If waiting on the IANA were a reason to delay applying the SSHFP_KEY_ED25519 patch, it needn't be any longer. I've proposed un-reserving hash type 0 to be a "NULL hash", for those who'd rather publish the public key unhashed. Even if zero for unhashed fails to gain traction, I hope to see something allocated for that. But support for 4/1 ed25519/sha256 in the registry is a go. >From the xml: 4 ED25519 (TEMPORARY - expires 2015-05-09) That'll be updated once the draft is published as an rfc. -JimC -- James Cloos OpenPGP: 0x997A9F17ED7DAEA6 From mancha1 at zoho.com Thu May 15 05:13:03 2014 From: mancha1 at zoho.com (mancha) Date: Wed, 14 May 2014 19:13:03 +0000 Subject: Update on sshfp 4 In-Reply-To: References: Message-ID: <20140514191303.GA22782@zoho.com> On Wed, May 14, 2014 at 02:13:19PM -0400, James Cloos wrote: > The IANA has pre-allocated id 4 for ed25519. > > If waiting on the IANA were a reason to delay applying the > SSHFP_KEY_ED25519 patch, it needn't be any longer. Hi. Thanks for the update. I don't believe the plan was to wait for IANA any longer (e.g. http://www.openbsd.org/cgi-bin/cvsweb/src/usr.bin/ssh/dns.c.diff?r1=1.29;r2=1.30). So, it's probably safe to assume it'll be available on 6.7. --mancha -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From vinschen at redhat.com Thu May 15 18:58:01 2014 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 15 May 2014 10:58:01 +0200 Subject: [patch/cygwin] contrib/cygwin/ssh-host-config Message-ID: <20140515085801.GO2436@calimero.vinschen.de> Hi, would you mind to apply the below patch? It fixes Cygwin's ssh-host-config script in various ways: - Remove old code to remove the "sshd/22" entry from /etc/services. This code fixes a problem which only existed in installations which are more than 10 years old. - Handle the StrictMode setting interactively. - Fix regular expressions looking for white spaces. - Make the script independent of whether /etc/passwd exists or not. This allows to run ssh-host-config under the upcoming Cygwin release 1.7.30, which will introduce the passwd/group handling via the existing Windows account databases (SAM/AD). Thanks, Corinna Index: contrib/cygwin/ssh-host-config =================================================================== RCS file: /cvs/openssh/contrib/cygwin/ssh-host-config,v retrieving revision 1.34 diff -u -p -r1.34 ssh-host-config --- contrib/cygwin/ssh-host-config 8 Nov 2013 13:19:23 -0000 1.34 +++ contrib/cygwin/ssh-host-config 15 May 2014 08:46:20 -0000 @@ -34,6 +34,7 @@ declare -a csih_required_commands=( /usr/bin/mv coreutils /usr/bin/rm coreutils /usr/bin/cygpath cygwin + /usr/bin/mkpasswd cygwin /usr/bin/mount cygwin /usr/bin/ps cygwin /usr/bin/setfacl cygwin @@ -59,8 +60,9 @@ PREFIX=/usr SYSCONFDIR=/etc LOCALSTATEDIR=/var +sshd_config_configured=no port_number=22 -privsep_configured=no +strictmodes=yes privsep_used=yes cygwin_value="" user_account= @@ -89,28 +91,8 @@ update_services_file() { # Depends on the above mount _wservices=`cygpath -w "${_services}"` - # Remove sshd 22/port from services - if [ `/usr/bin/grep -q 'sshd[ \t][ \t]*22' "${_services}"; echo $?` -eq 0 ] - then - /usr/bin/grep -v 'sshd[ \t][ \t]*22' "${_services}" > "${_serv_tmp}" - if [ -f "${_serv_tmp}" ] - then - if /usr/bin/mv "${_serv_tmp}" "${_services}" - then - csih_inform "Removing sshd from ${_wservices}" - else - csih_warning "Removing sshd from ${_wservices} failed!" - let ++ret - fi - /usr/bin/rm -f "${_serv_tmp}" - else - csih_warning "Removing sshd from ${_wservices} failed!" - let ++ret - fi - fi - # Add ssh 22/tcp and ssh 22/udp to services - if [ `/usr/bin/grep -q 'ssh[ \t][ \t]*22' "${_services}"; echo $?` -ne 0 ] + if [ `/usr/bin/grep -q 'ssh[[:space:]][[:space:]]*22' "${_services}"; echo $?` -ne 0 ] then if /usr/bin/awk '{ if ( $2 ~ /^23\/tcp/ ) print "ssh 22/tcp'"${_spaces}"'SSH Remote Login Protocol\nssh 22/udp'"${_spaces}"'SSH Remote Login Protocol"; print $0; }' < "${_services}" > "${_serv_tmp}" then @@ -132,17 +114,45 @@ update_services_file() { } # --- End of update_services_file --- # # ====================================================================== +# Routine: sshd_strictmodes +# MODIFIES: strictmodes +# ====================================================================== +sshd_strictmodes() { + if [ "${sshd_config_configured}" != "yes" ] + then + echo + csih_inform "StrictModes is set to 'yes' by default." + csih_inform "This is the recommended setting, but it requires that the POSIX" + csih_inform "permissions of the user's home directory, the user's .ssh" + csih_inform "directory, and the user's ssh key files are tight so that" + csih_inform "only the user has write permissions." + csih_inform "On the other hand, StrictModes don't work well with default" + csih_inform "Windows permissions of a home directory mounted with the" + csih_inform "'noacl' option, and they don't work at all if the home" + csih_inform "directory is on a FAT or FAT32 partition." + if ! csih_request "Should StrictModes be used?" + then + strictmodes=no + fi + fi + return 0 +} + +# ====================================================================== # Routine: sshd_privsep -# MODIFIES: privsep_configured privsep_used +# MODIFIES: privsep_used # ====================================================================== sshd_privsep() { - local sshdconfig_tmp local ret=0 - if [ "${privsep_configured}" != "yes" ] + if [ "${sshd_config_configured}" != "yes" ] then - csih_inform "Privilege separation is set to yes by default since OpenSSH 3.3." - csih_inform "However, this requires a non-privileged account called 'sshd'." + echo + csih_inform "Privilege separation is set to 'sandbox' by default since" + csih_inform "OpenSSH 6.1. This is unsupported by Cygwin and has to be set" + csih_inform "to 'yes' or 'no'." + csih_inform "However, using privilege separation requires a non-privileged account" + csih_inform "called 'sshd'." csih_inform "For more info on privilege separation read /usr/share/doc/openssh/README.privsep." if csih_request "Should privilege separation be used?" then @@ -159,36 +169,53 @@ sshd_privsep() { privsep_used=no fi fi + return $ret +} # --- End of sshd_privsep --- # + +# ====================================================================== +# Routine: sshd_config_tweak +# ====================================================================== +sshd_config_tweak() { + local ret=0 - # Create default sshd_config from skeleton files in /etc/defaults/etc or - # modify to add the missing privsep configuration option - if /usr/bin/cmp "${SYSCONFDIR}/sshd_config" "${SYSCONFDIR}/defaults/${SYSCONFDIR}/sshd_config" >/dev/null 2>&1 - then - csih_inform "Updating ${SYSCONFDIR}/sshd_config file" - sshdconfig_tmp=${SYSCONFDIR}/sshd_config.$$ - /usr/bin/sed -e "s/^#UsePrivilegeSeparation yes/UsePrivilegeSeparation ${privsep_used}/ - s/^#Port 22/Port ${port_number}/ - s/^#StrictModes yes/StrictModes no/" \ - < ${SYSCONFDIR}/sshd_config \ - > "${sshdconfig_tmp}" - if ! /usr/bin/mv "${sshdconfig_tmp}" ${SYSCONFDIR}/sshd_config + # Modify sshd_config + csih_inform "Updating ${SYSCONFDIR}/sshd_config file" + if [ "${port_number}" -ne 22 ] + then + /usr/bin/sed -i -e "s/^#\?[[:space:]]*Port[[:space:]].*/Port ${port_number}/" \ + ${SYSCONFDIR}/sshd_config + if [ $? -ne 0 ] then - csih_warning "Setting privilege separation to 'yes' failed!" - csih_warning "Check your ${SYSCONFDIR}/sshd_config file!" - let ++ret + csih_warning "Setting listening port to ${port_number} failed!" + csih_warning "Check your ${SYSCONFDIR}/sshd_config file!" + let ++ret fi - elif [ "${privsep_configured}" != "yes" ] + fi + if [ "${strictmodes}" = "no" ] then - echo >> ${SYSCONFDIR}/sshd_config - if ! echo "UsePrivilegeSeparation ${privsep_used}" >> ${SYSCONFDIR}/sshd_config + /usr/bin/sed -i -e "s/^#\?[[:space:]]*StrictModes[[:space:]].*/StrictModes no/" \ + ${SYSCONFDIR}/sshd_config + if [ $? -ne 0 ] then - csih_warning "Setting privilege separation to 'yes' failed!" - csih_warning "Check your ${SYSCONFDIR}/sshd_config file!" - let ++ret + csih_warning "Setting StrictModes to 'no' failed!" + csih_warning "Check your ${SYSCONFDIR}/sshd_config file!" + let ++ret + fi + fi + if [ "${sshd_config_configured}" != "yes" ] + then + /usr/bin/sed -i -e " + s/^#\?UsePrivilegeSeparation .*/UsePrivilegeSeparation ${privsep_used}/" \ + ${SYSCONFDIR}/sshd_config + if [ $? -ne 0 ] + then + csih_warning "Setting privilege separation failed!" + csih_warning "Check your ${SYSCONFDIR}/sshd_config file!" + let ++ret fi fi return $ret -} # --- End of sshd_privsep --- # +} # --- End of sshd_config_tweak --- # # ====================================================================== # Routine: update_inetd_conf @@ -207,11 +234,11 @@ update_inetd_conf() { # we have inetutils-1.5 inetd.d support if [ -f "${_inetcnf}" ] then - /usr/bin/grep -q '^[ \t]*ssh' "${_inetcnf}" && _with_comment=0 + /usr/bin/grep -q '^[[:space:]]*ssh' "${_inetcnf}" && _with_comment=0 # check for sshd OR ssh in top-level inetd.conf file, and remove # will be replaced by a file in inetd.d/ - if [ `/usr/bin/grep -q '^[# \t]*ssh' "${_inetcnf}"; echo $?` -eq 0 ] + if [ $(/usr/bin/grep -q '^[# \t]*ssh' "${_inetcnf}"; echo $?) -eq 0 ] then /usr/bin/grep -v '^[# \t]*ssh' "${_inetcnf}" >> "${_inetcnf_tmp}" if [ -f "${_inetcnf_tmp}" ] @@ -236,9 +263,9 @@ update_inetd_conf() { then if [ "${_with_comment}" -eq 0 ] then - /usr/bin/sed -e 's/@COMMENT@[ \t]*//' < "${_sshd_inetd_conf}" > "${_sshd_inetd_conf_tmp}" + /usr/bin/sed -e 's/@COMMENT@[[:space:]]*//' < "${_sshd_inetd_conf}" > "${_sshd_inetd_conf_tmp}" else - /usr/bin/sed -e 's/@COMMENT@[ \t]*/# /' < "${_sshd_inetd_conf}" > "${_sshd_inetd_conf_tmp}" + /usr/bin/sed -e 's/@COMMENT@[[:space:]]*/# /' < "${_sshd_inetd_conf}" > "${_sshd_inetd_conf_tmp}" fi if /usr/bin/mv "${_sshd_inetd_conf_tmp}" "${_sshd_inetd_conf}" then @@ -251,13 +278,13 @@ update_inetd_conf() { elif [ -f "${_inetcnf}" ] then - /usr/bin/grep -q '^[ \t]*sshd' "${_inetcnf}" && _with_comment=0 + /usr/bin/grep -q '^[[:space:]]*sshd' "${_inetcnf}" && _with_comment=0 # check for sshd in top-level inetd.conf file, and remove # will be replaced by a file in inetd.d/ - if [ `/usr/bin/grep -q '^[# \t]*sshd' "${_inetcnf}"; echo $?` -eq 0 ] + if [ `/usr/bin/grep -q '^#\?[[:space:]]*sshd' "${_inetcnf}"; echo $?` -eq 0 ] then - /usr/bin/grep -v '^[# \t]*sshd' "${_inetcnf}" >> "${_inetcnf_tmp}" + /usr/bin/grep -v '^#\?[[:space:]]*sshd' "${_inetcnf}" >> "${_inetcnf_tmp}" if [ -f "${_inetcnf_tmp}" ] then if /usr/bin/mv "${_inetcnf_tmp}" "${_inetcnf}" @@ -305,17 +332,26 @@ check_service_files_ownership() { if [ -z "${run_service_as}" ] then - accnt_name=$(/usr/bin/cygrunsrv -VQ sshd | /usr/bin/sed -ne 's/^Account *: *//gp') + accnt_name=$(/usr/bin/cygrunsrv -VQ sshd | + /usr/bin/sed -ne 's/^Account *: *//gp') if [ "${accnt_name}" = "LocalSystem" ] then # Convert "LocalSystem" to "SYSTEM" as is the correct account name - accnt_name="SYSTEM:" - elif [[ "${accnt_name}" =~ ^\.\\ ]] - then - # Convert "." domain to local machine name - accnt_name="U-${COMPUTERNAME}${accnt_name#.}," + run_service_as="SYSTEM" + else + dom="${accnt_name%%\\*}" + accnt_name="${accnt_name#*\\}" + if [ "${dom}" = '.' ] + then + # Check local account + run_service_as=$(/usr/bin/mkpasswd -l -u "${accnt_name}" | + /usr/bin/awk -F: '{print $1;}') + else + # Check domain + run_service_as=$(/usr/bin/mkpasswd -d "${dom}" -u "${accnt_name}" | + /usr/bin/awk -F: '{print $1;}') + fi fi - run_service_as=$(/usr/bin/grep -Fi "${accnt_name}" /etc/passwd | /usr/bin/awk -F: '{print $1;}') if [ -z "${run_service_as}" ] then csih_warning "Couldn't determine name of user running sshd service from /etc/passwd!" @@ -672,6 +708,7 @@ then fi # generate missing host keys +csih_inform "Generating missing SSH host keys" /usr/bin/ssh-keygen -A || let warning_cnt+=$? # handle ssh_config @@ -690,10 +727,11 @@ fi csih_install_config "${SYSCONFDIR}/sshd_config" "${SYSCONFDIR}/defaults" || let ++warning_cnt if ! /usr/bin/cmp "${SYSCONFDIR}/sshd_config" "${SYSCONFDIR}/defaults/${SYSCONFDIR}/sshd_config" >/dev/null 2>&1 then - /usr/bin/grep -q UsePrivilegeSeparation ${SYSCONFDIR}/sshd_config && privsep_configured=yes + sshd_config_configured=yes fi +sshd_strictmodes || let warning_cnt+=$? sshd_privsep || let warning_cnt+=$? - +sshd_config_tweak || let warning_cnt+=$? update_services_file || let warning_cnt+=$? update_inetd_conf || let warning_cnt+=$? install_service || let warning_cnt+=$? -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From vinschen at redhat.com Thu May 15 21:28:14 2014 From: vinschen at redhat.com (Corinna Vinschen) Date: Thu, 15 May 2014 13:28:14 +0200 Subject: [patch/cygwin] SSH_PRIVSEP_USER as function (was Re: SSH_PRIVSEP_USER configurable at runtime?) In-Reply-To: <20140402124428.GT2508@calimero.vinschen.de> References: <20140331153243.GD2508@calimero.vinschen.de> <20140401085550.GA13510@calimero.vinschen.de> <20140401121529.GA16619@calimero.vinschen.de> <20140402113743.17700.qmail@stuge.se> <20140402124428.GT2508@calimero.vinschen.de> Message-ID: <20140515112814.GA26671@calimero.vinschen.de> On Apr 2 14:44, Corinna Vinschen wrote: > On Apr 2 13:37, Peter Stuge wrote: > > Corinna Vinschen wrote: > > > On non-domain machines the account > > > name will be "sshd", not "${machine}+sshd". Except if the admin > > > specifies that the domain is always prepended, which makes it > > > "${machine}+sshd" again. And if the admin specifies the separator char > > > to be not '+' but, for instance '#', the account name will be > > > "${machine}#sshd". > > > > > > All that knowledge would have to go into sshd.c. > > > > FWIW I think this is the right solution. > > Hmm. Come to think of it, SSH_PRIVSEP_USER could be defined as a macro > calling a function which returns the username. And configure.ac could > define SSH_PRIVSEP_USER as, say, cygwin_privsep_user() by default, when > built for Cygwin so the ugly details could be hidden in bsd-cygwin_util.c. > > The Cygwin changes are still in an early stage of testing, but I'll > come back to this. Ok, after some mulling about, I prepared the below patch. What it does is this: - The default replacement string for SSH_PRIVSEP_USER in configure.ac is now CYGWIN_SSH_PRIVSEP_USER, if the target is Cygwin. This can still be overridden with --with-privsep-user=FOO. - openbsd-compat/bsd-cygwin_util.h defines CYGWIN_SSH_PRIVSEP_USER as a function call cygwin_ssh_privsep_user(). - openbsd-compat/bsd-cygwin_util.c implements cygwin_ssh_privsep_user(). The function fills a static buffer with a username fetched by calling an internal Cygwin function. The function fills the buffer with the correct username, for instance "DOMAIN+sshd". If the function fails (non-0 return value), the function falls back to the username "sshd". I just applied the required functionality to Cygwin's repository: https://cygwin.com/viewvc/src/winsup/cygwin/external.cc?r1=1.137&r2=1.138 It will show up in the next official release 1.7.30. The below patch makes sure that the code also compiles and falls back to the username "sshd", if its getting built under an older version of Cygwin. Additionally, even if built for 1.7.30 and later it will still run under an older Cygwin version. I hope that patch is ok to support the discussed account mapping functionality. I tried to implement it as non-intrusive as possible. Thanks, Corinna Index: configure.ac =================================================================== RCS file: /cvs/openssh/configure.ac,v retrieving revision 1.573 diff -u -p -r1.573 configure.ac --- configure.ac 15 May 2014 04:58:08 -0000 1.573 +++ configure.ac 15 May 2014 11:26:21 -0000 @@ -2872,7 +2872,14 @@ if test "x$PAM_MSG" = "xyes" ; then ]) fi -SSH_PRIVSEP_USER=sshd +case "$host" in +*-*-cygwin*) + SSH_PRIVSEP_USER=CYGWIN_SSH_PRIVSEP_USER + ;; +*) + SSH_PRIVSEP_USER=sshd + ;; +esac AC_ARG_WITH([privsep-user], [ --with-privsep-user=user Specify non-privileged user for privilege separation], [ @@ -2882,8 +2889,13 @@ AC_ARG_WITH([privsep-user], fi ] ) -AC_DEFINE_UNQUOTED([SSH_PRIVSEP_USER], ["$SSH_PRIVSEP_USER"], - [non-privileged user for privilege separation]) +if test "x$SSH_PRIVSEP_USER" = "xCYGWIN_SSH_PRIVSEP_USER" ; then + AC_DEFINE_UNQUOTED([SSH_PRIVSEP_USER], [CYGWIN_SSH_PRIVSEP_USER], + [Cygwin function to fetch non-privileged user for privilege separation]) +else + AC_DEFINE_UNQUOTED([SSH_PRIVSEP_USER], ["$SSH_PRIVSEP_USER"], + [non-privileged user for privilege separation]) +fi AC_SUBST([SSH_PRIVSEP_USER]) if test "x$have_linux_no_new_privs" = "x1" ; then Index: openbsd-compat/bsd-cygwin_util.c =================================================================== RCS file: /cvs/openssh/openbsd-compat/bsd-cygwin_util.c,v retrieving revision 1.26 diff -u -p -r1.26 bsd-cygwin_util.c --- openbsd-compat/bsd-cygwin_util.c 1 Jun 2013 22:07:32 -0000 1.26 +++ openbsd-compat/bsd-cygwin_util.c 15 May 2014 11:26:22 -0000 @@ -57,6 +57,22 @@ check_ntsec(const char *filename) return (pathconf(filename, _PC_POSIX_PERMISSIONS)); } +const char * +cygwin_ssh_privsep_user() +{ + static char cyg_privsep_user[DNLEN + UNLEN + 2]; + + if (!cyg_privsep_user[0]) + { +#ifdef CW_CYGNAME_FROM_WINNAME + if (cygwin_internal (CW_CYGNAME_FROM_WINNAME, "sshd", cyg_privsep_user, + sizeof cyg_privsep_user) != 0) +#endif + strcpy (cyg_privsep_user, "sshd"); + } + return cyg_privsep_user; +} + #define NL(x) x, (sizeof (x) - 1) #define WENV_SIZ (sizeof (wenv_arr) / sizeof (wenv_arr[0])) Index: openbsd-compat/bsd-cygwin_util.h =================================================================== RCS file: /cvs/openssh/openbsd-compat/bsd-cygwin_util.h,v retrieving revision 1.17 diff -u -p -r1.17 bsd-cygwin_util.h --- openbsd-compat/bsd-cygwin_util.h 18 Jan 2014 10:04:00 -0000 1.17 +++ openbsd-compat/bsd-cygwin_util.h 15 May 2014 11:26:22 -0000 @@ -39,6 +39,8 @@ /* Avoid including windows headers. */ typedef void *HANDLE; #define INVALID_HANDLE_VALUE ((HANDLE) -1) +#define DNLEN 16 +#define UNLEN 256 /* Cygwin functions for which declarations are only available when including windows headers, so we have to define them here explicitely. */ @@ -48,6 +50,8 @@ extern void cygwin_set_impersonation_tok #include #include +#define CYGWIN_SSH_PRIVSEP_USER (cygwin_ssh_privsep_user()) +const char *cygwin_ssh_privsep_user(); int binary_open(const char *, int , ...); int check_ntsec(const char *); -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From kb at open.ch Thu May 15 22:42:22 2014 From: kb at open.ch (Konrad Bucheli) Date: Thu, 15 May 2014 14:42:22 +0200 Subject: ANNOUNCE: log-user-session (full SSH session auditing) Message-ID: <24231_1400157743_5374B62F_24231_2110_1_5374B62E.8000906@open.ch> log-user-session is shell-wrapper that can be used via ForceCommand to implement full logging of user sessions. It supports the following features: - Flexible directory structure for the shell output log files. - Support setuid-mode to write the files as another user. - Properly starts the user shell as login shell. - Optionally log only the command line of remote commands instead of the full output. It is open source and available here: https://github.com/open-ch/log-user-session -- konrad bucheli security engineer open systems ag raeffelstrasse 29 ch-8045 zurich t: +41 58 100 10 10 f: +41 58 100 10 11 kb at open.ch http://www.open.ch From bwalker at musings.com Sat May 17 08:11:49 2014 From: bwalker at musings.com (Brad Walker) Date: Fri, 16 May 2014 16:11:49 -0600 Subject: ? about portable version of sshd crashing Message-ID: I am porting over the portable version of openssh to our uCLinux implementation. Everything has worked with minimal effort and I appreciate all the work. But, I am having a problem whereby the sshd executable is crashing and I really could use some help on where to look at this in more details. Here is how I start up the sshd for testing. /usr/sbin/sshd -D -ddd -f /etc/ssh/sshd_config -p 65 Then I connect to it with the folloiwng command sshd -vvv admin@ -p 65 It connects with no problem. But, when I hit the return key I get a big fat error.. I've attached the debug output at the end of this email. Any advice on where to start debugging this is most appreciated. Thanks. -brad w. /bin # /usr/sbin/sshd -D -ddd -f /etc/ssh/sshd_config -p 65 debug2: load_server_config: filename /etc/ssh/sshd_config debug2: load_server_config: done config len = 852 debug2: parse_server_config: config /etc/ssh/sshd_config len 852 debug3: /etc/ssh/sshd_config:18 setting AddressFamily inet debug3: /etc/ssh/sshd_config:21 setting ListenAddress 192.168.0.2 debug3: /etc/ssh/sshd_config:27 setting HostKey /etc/ssh/ssh_host_key debug3: /etc/ssh/sshd_config:29 setting HostKey /etc/ssh/ssh_host_rsa_key debug3: /etc/ssh/sshd_config:30 setting HostKey /etc/ssh/ssh_host_dsa_key debug3: /etc/ssh/sshd_config:34 setting KeyRegenerationInterval 1h debug3: /etc/ssh/sshd_config:35 setting ServerKeyBits 1024 debug3: /etc/ssh/sshd_config:43 setting SyslogFacility AUTHPRIV debug3: /etc/ssh/sshd_config:54 setting RSAAuthentication yes debug3: /etc/ssh/sshd_config:55 setting PubkeyAuthentication yes debug3: /etc/ssh/sshd_config:72 setting IgnoreUserKnownHosts yes debug3: /etc/ssh/sshd_config:74 setting IgnoreRhosts yes debug3: /etc/ssh/sshd_config:77 setting PasswordAuthentication yes debug3: /etc/ssh/sshd_config:78 setting PermitEmptyPasswords yes debug3: /etc/ssh/sshd_config:79 setting PasswordAuthentication yes debug3: /etc/ssh/sshd_config:83 setting ChallengeResponseAuthentication no debug3: /etc/ssh/sshd_config:111 setting UsePAM no /etc/ssh/sshd_config line 111: Unsupported option UsePAM debug3: /etc/ssh/sshd_config:116 setting X11Forwarding no debug3: /etc/ssh/sshd_config:129 setting UseDNS no debug3: /etc/ssh/sshd_config:140 setting AcceptEnv LANG LC_CTYPE LC_NUMERIC LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES debug3: /etc/ssh/sshd_config:141 setting AcceptEnv LC_PAPER LC_NAME LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT debug3: /etc/ssh/sshd_config:142 setting AcceptEnv LC_IDENTIFICATION LC_ALL LANGUAGE debug3: /etc/ssh/sshd_config:143 setting AcceptEnv XMODIFIERS debug3: /etc/ssh/sshd_config:146 setting Subsystem sftp /usr/local/libexec/sftp-server debug1: sshd version OpenSSH_6.7, OpenSSL 1.0.1g 7 Apr 2014 debug1: private host key: #0 type 0 RSA1 debug3: Incorrect RSA1 identifier debug1: key_parse_private2: missing begin marker debug1: read PEM private key done: type RSA debug3: Incorrect RSA1 identifier debug3: Could not load "/etc/ssh/ssh_host_rsa_key" as a RSA1 public key debug1: private host key: #1 type 1 RSA debug3: Incorrect RSA1 identifier debug1: key_parse_private2: missing begin marker debug1: read PEM private key done: type DSA debug3: Incorrect RSA1 identifier debug3: Could not load "/etc/ssh/ssh_host_dsa_key" as a RSA1 public key debug1: private host key: #2 type 2 DSA debug1: rexec_argv[0]='/usr/sbin/sshd' debug1: rexec_argv[1]='-D' debug1: rexec_argv[2]='-ddd' debug1: rexec_argv[3]='-f' debug1: rexec_argv[4]='/etc/ssh/sshd_config' debug1: rexec_argv[5]='-p' debug1: rexec_argv[6]='65' debug2: fd 4 setting O_NONBLOCK debug1: Bind to port 65 on 192.168.0.2. Server listening on 192.168.0.2 port 65. debug3: fd 5 is not O_NONBLOCK debug1: Server will not fork when running in debugging mode. debug3: send_rexec_state: entering fd = 8 config len 852 debug3: ssh_msg_send: type 0 debug3: send_rexec_state: done debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 debug1: rexec_argv[0]: /usr/sbin/sshd debug1: inetd sockets after dupping: 4, 4 Connection from 192.168.0.65 port 59719 on 192.168.0.2 port 65 debug1: Client protocol version 2.0; client software version OpenSSH_6.4 debug1: match: OpenSSH_6.4 pat OpenSSH* compat 0x04000000 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.7 debug2: fd 4 setting O_NONBLOCK debug1: list_hostkey_types: ssh-rsa,ssh-dss debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: curve25519-sha256 at libssh.org ,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss .. .. debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: setup umac-64-etm at openssh.com debug1: kex: client->server aes128-ctr umac-64-etm at openssh.com none debug2: mac_setup: setup umac-64-etm at openssh.com debug1: kex: server->client aes128-ctr umac-64-etm at openssh.com none debug1: expecting SSH2_MSG_KEX_ECDH_INIT debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: KEX done debug1: userauth-request for user admin service ssh-connection method none debug1: attempt 0 failures 0 debug2: parse_server_config: config reprocess config len 852 debug3: auth_shadow_acctexpired: today 2 sp_expire -1 days left -3 debug3: account expiration disabled debug2: input_userauth_request: setting up authctxt for admin debug2: input_userauth_request: try method none debug3: auth_shadow_pwexpired: today 2 sp_lstchg -1 sp_max 99999 Failed none for admin from 192.168.0.65 port 59719 ssh2 debug3: userauth_finish: failure partial=0 next methods="publickey,password" debug1: userauth-request for user admin service ssh-connection method password debug1: attempt 1 failures 0 debug2: input_userauth_request: try method password Accepted password for admin from 192.168.0.65 port 59719 ssh2 debug1: Entering interactive session for SSH2. debug2: fd 5 setting O_NONBLOCK debug2: fd 6 setting O_NONBLOCK debug1: server_init_dispatch_20 debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max 16384 debug1: input_session_request debug1: channel 0: new [server-session] debug2: session_new: allocate (allocated 0 max 10) debug3: session_unused: session id 0 unused debug1: session_new: session 0 debug1: session_open: channel 0 debug1: session_open: session 0: link with channel 0 debug1: server_input_channel_open: confirm session debug1: server_input_global_request: rtype no-more-sessions at openssh.comwant_reply 0 debug1: server_input_channel_req: channel 0 request pty-req reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req pty-req debug1: Allocating pty. debug1: session_pty_req: session 0 alloc /dev/pts/1 debug1: server_input_channel_req: channel 0 request env reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req env debug2: Setting env 0: XMODIFIERS=@im=ibus debug1: server_input_channel_req: channel 0 request env reply 0 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req env debug2: Setting env 1: LANG=en_US.UTF-8 debug1: server_input_channel_req: channel 0 request shell reply 1 debug1: session_by_channel: session 0 channel 0 debug1: session_input_channel_req: session 0 req shell Starting session: shell on pts/1 for admin from 192.168.0.65 port 59719 debug1: Setting controlling tty using TIOCSCTTY. debug2: fd 4 setting TCP_NODELAY debug3: packet_set_tos: set IP_TOS 0x10 debug2: channel 0: rfd 9 isatty debug2: fd 9 setting O_NONBLOCK fcntl(7, F_GETFL, 0): Bad file descriptor select: Bad file descriptor select: Bad file descriptor select: Bad file descriptor .... and it just continues.. From loganaden at gmail.com Sat May 17 15:39:01 2014 From: loganaden at gmail.com (Loganaden Velvindron) Date: Sat, 17 May 2014 09:39:01 +0400 Subject: ? about portable version of sshd crashing In-Reply-To: References: Message-ID: I'm trying to reproduce the issue. On Sat, May 17, 2014 at 2:11 AM, Brad Walker wrote: > I am porting over the portable version of openssh to our uCLinux > implementation. Everything has worked with minimal effort and I appreciate > all the work. > > But, I am having a problem whereby the sshd executable is crashing and I > really could use some help on where to look at this in more details. > > Here is how I start up the sshd for testing. > > /usr/sbin/sshd -D -ddd -f /etc/ssh/sshd_config -p 65 > > Then I connect to it with the folloiwng command > > sshd -vvv admin@ -p 65 > > It connects with no problem. But, when I hit the return key I get a big fat > error.. > > I've attached the debug output at the end of this email. > > Any advice on where to start debugging this is most appreciated. > > Thanks. > > -brad w. > > /bin # /usr/sbin/sshd -D -ddd -f /etc/ssh/sshd_config -p 65 > debug2: load_server_config: filename /etc/ssh/sshd_config > debug2: load_server_config: done config len = 852 > debug2: parse_server_config: config /etc/ssh/sshd_config len 852 > debug3: /etc/ssh/sshd_config:18 setting AddressFamily inet > debug3: /etc/ssh/sshd_config:21 setting ListenAddress 192.168.0.2 > debug3: /etc/ssh/sshd_config:27 setting HostKey /etc/ssh/ssh_host_key > debug3: /etc/ssh/sshd_config:29 setting HostKey /etc/ssh/ssh_host_rsa_key > debug3: /etc/ssh/sshd_config:30 setting HostKey /etc/ssh/ssh_host_dsa_key > debug3: /etc/ssh/sshd_config:34 setting KeyRegenerationInterval 1h > debug3: /etc/ssh/sshd_config:35 setting ServerKeyBits 1024 > debug3: /etc/ssh/sshd_config:43 setting SyslogFacility AUTHPRIV > debug3: /etc/ssh/sshd_config:54 setting RSAAuthentication yes > debug3: /etc/ssh/sshd_config:55 setting PubkeyAuthentication yes > debug3: /etc/ssh/sshd_config:72 setting IgnoreUserKnownHosts yes > debug3: /etc/ssh/sshd_config:74 setting IgnoreRhosts yes > debug3: /etc/ssh/sshd_config:77 setting PasswordAuthentication yes > debug3: /etc/ssh/sshd_config:78 setting PermitEmptyPasswords yes > debug3: /etc/ssh/sshd_config:79 setting PasswordAuthentication yes > debug3: /etc/ssh/sshd_config:83 setting ChallengeResponseAuthentication no > debug3: /etc/ssh/sshd_config:111 setting UsePAM no > /etc/ssh/sshd_config line 111: Unsupported option UsePAM > debug3: /etc/ssh/sshd_config:116 setting X11Forwarding no > debug3: /etc/ssh/sshd_config:129 setting UseDNS no > debug3: /etc/ssh/sshd_config:140 setting AcceptEnv LANG LC_CTYPE LC_NUMERIC > LC_TIME LC_COLLATE LC_MONETARY LC_MESSAGES > debug3: /etc/ssh/sshd_config:141 setting AcceptEnv LC_PAPER LC_NAME > LC_ADDRESS LC_TELEPHONE LC_MEASUREMENT > debug3: /etc/ssh/sshd_config:142 setting AcceptEnv LC_IDENTIFICATION LC_ALL > LANGUAGE > debug3: /etc/ssh/sshd_config:143 setting AcceptEnv XMODIFIERS > debug3: /etc/ssh/sshd_config:146 setting Subsystem sftp > /usr/local/libexec/sftp-server > debug1: sshd version OpenSSH_6.7, OpenSSL 1.0.1g 7 Apr 2014 > > debug1: private host key: #0 type 0 RSA1 > debug3: Incorrect RSA1 identifier > debug1: key_parse_private2: missing begin marker > debug1: read PEM private key done: type RSA > debug3: Incorrect RSA1 identifier > debug3: Could not load "/etc/ssh/ssh_host_rsa_key" as a RSA1 public key > debug1: private host key: #1 type 1 RSA > debug3: Incorrect RSA1 identifier > debug1: key_parse_private2: missing begin marker > debug1: read PEM private key done: type DSA > debug3: Incorrect RSA1 identifier > debug3: Could not load "/etc/ssh/ssh_host_dsa_key" as a RSA1 public key > debug1: private host key: #2 type 2 DSA > debug1: rexec_argv[0]='/usr/sbin/sshd' > debug1: rexec_argv[1]='-D' > debug1: rexec_argv[2]='-ddd' > debug1: rexec_argv[3]='-f' > debug1: rexec_argv[4]='/etc/ssh/sshd_config' > debug1: rexec_argv[5]='-p' > debug1: rexec_argv[6]='65' > debug2: fd 4 setting O_NONBLOCK > debug1: Bind to port 65 on 192.168.0.2. > Server listening on 192.168.0.2 port 65. > debug3: fd 5 is not O_NONBLOCK > debug1: Server will not fork when running in debugging mode. > debug3: send_rexec_state: entering fd = 8 config len 852 > debug3: ssh_msg_send: type 0 > debug3: send_rexec_state: done > debug1: rexec start in 5 out 5 newsock 5 pipe -1 sock 8 > debug1: rexec_argv[0]: /usr/sbin/sshd > > debug1: inetd sockets after dupping: 4, 4 > Connection from 192.168.0.65 port 59719 on 192.168.0.2 port 65 > debug1: Client protocol version 2.0; client software version OpenSSH_6.4 > debug1: match: OpenSSH_6.4 pat OpenSSH* compat 0x04000000 > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_6.7 > debug2: fd 4 setting O_NONBLOCK > debug1: list_hostkey_types: ssh-rsa,ssh-dss > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug2: kex_parse_kexinit: curve25519-sha256 at libssh.org > ,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group14-sha1 > debug2: kex_parse_kexinit: ssh-rsa,ssh-dss > > .. > > .. > > debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib > debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: first_kex_follows 0 > debug2: kex_parse_kexinit: reserved 0 > debug2: mac_setup: setup umac-64-etm at openssh.com > debug1: kex: client->server aes128-ctr umac-64-etm at openssh.com none > debug2: mac_setup: setup umac-64-etm at openssh.com > debug1: kex: server->client aes128-ctr umac-64-etm at openssh.com none > debug1: expecting SSH2_MSG_KEX_ECDH_INIT > debug2: kex_derive_keys > debug2: set_newkeys: mode 1 > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug2: set_newkeys: mode 0 > debug1: SSH2_MSG_NEWKEYS received > debug1: KEX done > debug1: userauth-request for user admin service ssh-connection method none > debug1: attempt 0 failures 0 > debug2: parse_server_config: config reprocess config len 852 > debug3: auth_shadow_acctexpired: today 2 sp_expire -1 days left -3 > debug3: account expiration disabled > debug2: input_userauth_request: setting up authctxt for admin > debug2: input_userauth_request: try method none > debug3: auth_shadow_pwexpired: today 2 sp_lstchg -1 sp_max 99999 > Failed none for admin from 192.168.0.65 port 59719 ssh2 > debug3: userauth_finish: failure partial=0 next methods="publickey,password" > debug1: userauth-request for user admin service ssh-connection method > password > debug1: attempt 1 failures 0 > debug2: input_userauth_request: try method password > Accepted password for admin from 192.168.0.65 port 59719 ssh2 > debug1: Entering interactive session for SSH2. > debug2: fd 5 setting O_NONBLOCK > debug2: fd 6 setting O_NONBLOCK > debug1: server_init_dispatch_20 > debug1: server_input_channel_open: ctype session rchan 0 win 1048576 max > 16384 > debug1: input_session_request > debug1: channel 0: new [server-session] > debug2: session_new: allocate (allocated 0 max 10) > debug3: session_unused: session id 0 unused > debug1: session_new: session 0 > debug1: session_open: channel 0 > debug1: session_open: session 0: link with channel 0 > debug1: server_input_channel_open: confirm session > debug1: server_input_global_request: rtype > no-more-sessions at openssh.comwant_reply 0 > debug1: server_input_channel_req: channel 0 request pty-req reply 1 > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 req pty-req > debug1: Allocating pty. > debug1: session_pty_req: session 0 alloc /dev/pts/1 > debug1: server_input_channel_req: channel 0 request env reply 0 > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 req env > debug2: Setting env 0: XMODIFIERS=@im=ibus > debug1: server_input_channel_req: channel 0 request env reply 0 > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 req env > debug2: Setting env 1: LANG=en_US.UTF-8 > debug1: server_input_channel_req: channel 0 request shell reply 1 > debug1: session_by_channel: session 0 channel 0 > debug1: session_input_channel_req: session 0 req shell > Starting session: shell on pts/1 for admin from 192.168.0.65 port 59719 > debug1: Setting controlling tty using TIOCSCTTY. > debug2: fd 4 setting TCP_NODELAY > debug3: packet_set_tos: set IP_TOS 0x10 > debug2: channel 0: rfd 9 isatty > debug2: fd 9 setting O_NONBLOCK > fcntl(7, F_GETFL, 0): Bad file descriptor > select: Bad file descriptor > select: Bad file descriptor > select: Bad file descriptor > > .... > > and it just continues.. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- This message is strictly personal and the opinions expressed do not represent those of my employers, either past or present. From djm at mindrot.org Sun May 18 22:34:10 2014 From: djm at mindrot.org (Damien Miller) Date: Sun, 18 May 2014 22:34:10 +1000 (EST) Subject: ? about portable version of sshd crashing In-Reply-To: References: Message-ID: On Fri, 16 May 2014, Brad Walker wrote: > But, I am having a problem whereby the sshd executable is crashing and I > really could use some help on where to look at this in more details. ... > fcntl(7, F_GETFL, 0): Bad file descriptor > select: Bad file descriptor > select: Bad file descriptor > select: Bad file descriptor can you figure out what this tty is by looking at /proc/$pid/fd or using lsof or similar? You might also try and see if you can reproduce the problem without tty allocation enabled - i.e. "ssh -T hostname" -d From lists at y42.org Mon May 19 11:31:00 2014 From: lists at y42.org (IMAP List Administration) Date: Mon, 19 May 2014 03:31:00 +0200 Subject: using OpenSSH/SFTP to replace an FTP server securely Message-ID: <53795ED4.4060400@y42.org> Hello Folks, I'm trying to replace an FTP with several hundred users with something secure. My requirements: - transfers must be logged - users should not have any access to other users' directories - users should land in a writable directory - users should be chrooted I've been trying to get this working with OpenSSH and the internal SFTP server, but it does not seem possible.... If I chroot each user using "ChrootDirectory /home/%u", there are two problems: 1) the user lands in a directory to which he cannot write 2) I would need hundreds of syslog logging sockets, one in each user's chrooted environment if I chroot all users to the same top directory, for example "/home", which would solve the problem of avoiding hundreds of syslog logging sockets, I have found no method of having OpenSSH chdir into a user-specific subdirectory (I would be willing to rely on the standard UNIX security model to restrict users' access to their own directories). Have I missed something, or is what I'm trying to achieve simply not possible using OpenSSH? I do not really want to get into bind-mounting all sorts of crap from outside the chroot envonment to get stuff to work, particularly not for hundreds of users. If "sftp-server" solve the problem in conjunction with a single chroot top directory, I would be willing to bind-mount (or copy) what it needs, but I have not found any way of getting sftp-server to satisfy the above requirements. The platform is CentOS 6.5 (x86_64). "ssh -V" reports: OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 cheers, Rob From nkadel at gmail.com Mon May 19 20:06:15 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Mon, 19 May 2014 06:06:15 -0400 Subject: using OpenSSH/SFTP to replace an FTP server securely In-Reply-To: <53795ED4.4060400@y42.org> References: <53795ED4.4060400@y42.org> Message-ID: On Sun, May 18, 2014 at 9:31 PM, IMAP List Administration wrote: > Hello Folks, > > I'm trying to replace an FTP with several hundred users with something secure. > > My requirements: > - transfers must be logged > - users should not have any access to other users' directories > - users should land in a writable directory > - users should be chrooted > > I've been trying to get this working with OpenSSH and the internal SFTP server, > but it does not seem possible.... In general, don't bother. SFTP does not handle symlinks well, and the setups for chroot caged access via SFTP do not scale wall. They require certain non-user components in every chroot cage, which confuses some users. vsftpd, built into RHEL 5 and RHEL 6, works quite well in CentOS. It also scales well, and gives easily configured, legible configurations to an FTPS service without necessarily enabling FTP at all. > If I chroot each user using "ChrootDirectory /home/%u", there are two problems: > > 1) the user lands in a directory to which he cannot write > 2) I would need hundreds of syslog logging sockets, one in each user's > chrooted environment > > if I chroot all users to the same top directory, for example "/home", > which would solve the problem of avoiding hundreds of syslog logging sockets, I > have found no method of having OpenSSH chdir into a user-specific subdirectory > (I would be willing to rely on the standard UNIX security model to restrict > users' access to their own directories). > > Have I missed something, or is what I'm trying to achieve simply not possible > using OpenSSH? You've missed the setup directions at http://www.howtoforge.com/restricting-users-to-sftp-plus-setting-up-chrooted-ssh-sftp-debian-squeeze, which are pretty good. > I do not really want to get into bind-mounting all sorts of crap from outside > the chroot envonment to get stuff to work, particularly not for hundreds of > users. If "sftp-server" solve the problem in conjunction with a single chroot > top directory, I would be willing to bind-mount (or copy) what it needs, but I > have not found any way of getting sftp-server to satisfy the above requirements. > > The platform is CentOS 6.5 (x86_64). > > "ssh -V" reports: > > OpenSSH_5.3p1, OpenSSL 1.0.1e-fips 11 Feb 2013 I've recently done something like on CentOS 6.x, so it's feasible. But the base of each chroot cage needs to be owned by root, so it can't be "/home/[username]" and have that directory owned by [username]. The chroot directory is the *base* of the chroot cage. There's an old sript at http://www.fuschlberger.net/programs/ssh-scp-sftp-chroot-jail/make_chroot_jail.sh which is pretty useful for setting this up. Basically, you should not be treating ordinary user home directories as this kind of chroot target with SFTP based cages. It doesn't work well. If you want ordinary user directories, say the internally used ones, to be accessible with a chrooted access and no other work, use vsftpd for FTPS based access. From keisial at gmail.com Tue May 20 05:05:49 2014 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Mon, 19 May 2014 21:05:49 +0200 Subject: using OpenSSH/SFTP to replace an FTP server securely In-Reply-To: <53795ED4.4060400@y42.org> References: <53795ED4.4060400@y42.org> Message-ID: <537A560D.4090800@gmail.com> On 19/05/14 03:31, IMAP List Administration wrote: > Hello Folks, > > (...) > if I chroot all users to the same top directory, for example "/home", > which would solve the problem of avoiding hundreds of syslog logging sockets, I > have found no method of having OpenSSH chdir into a user-specific subdirectory > (I would be willing to rely on the standard UNIX security model to restrict > users' access to their own directories). > > Have I missed something, or is what I'm trying to achieve simply not possible > using OpenSSH? Suppose the user home is /home/foo, then if that path exists inside your chroot (eg. /chrooted-users/home/foo) then the user will be landed inside that folder (writable for him). If you want something different, like chrooting them at /chrooted-users/foo, you can use -d parameter in the ForceCommand, ie. ForceCommand internal-sftp -d /%u Regards From djm at mindrot.org Tue May 20 17:30:55 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 20 May 2014 17:30:55 +1000 (EST) Subject: using OpenSSH/SFTP to replace an FTP server securely In-Reply-To: <53795ED4.4060400@y42.org> References: <53795ED4.4060400@y42.org> Message-ID: On Mon, 19 May 2014, IMAP List Administration wrote: > Hello Folks, > > I'm trying to replace an FTP with several hundred users with something secure. > > My requirements: > - transfers must be logged > - users should not have any access to other users' directories > - users should land in a writable directory > - users should be chrooted > > I've been trying to get this working with OpenSSH and the internal SFTP server, > but it does not seem possible.... > > If I chroot each user using "ChrootDirectory /home/%u", there are two problems: > 1) the user lands in a directory to which he cannot write > 2) I would need hundreds of syslog logging sockets, one in each user's > chrooted environment The first problem is easily solved. You can specify a different starting directory on the sftp-server commandline using the '-d' option. E.g. Subsystem sftp internal-sftp -d sftp (and create 'sftp' directory under /home/$user) The syslog problem doesn't have a good solution right now. Maybe someone could write a patch to implement logging via the monitor, like what happens for the pre-auth process. -d From djm at mindrot.org Tue May 20 17:32:37 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 20 May 2014 17:32:37 +1000 (EST) Subject: using OpenSSH/SFTP to replace an FTP server securely In-Reply-To: <537A560D.4090800@gmail.com> References: <53795ED4.4060400@y42.org> <537A560D.4090800@gmail.com> Message-ID: On Mon, 19 May 2014, ?ngel Gonz?lez wrote: > If you want something different, like chrooting them at /chrooted-users/foo, > you > can use -d parameter in the ForceCommand, ie. > ForceCommand internal-sftp -d /%u If you're willing to live with a single chroot directory and file permissions to keep users from each others' files then this is a great solution. It only requires a single /chrooted-users/dev/log listener too. -d From nkadel at gmail.com Tue May 20 21:55:39 2014 From: nkadel at gmail.com (Nico Kadel-Garcia) Date: Tue, 20 May 2014 07:55:39 -0400 Subject: using OpenSSH/SFTP to replace an FTP server securely In-Reply-To: References: <53795ED4.4060400@y42.org> <537A560D.4090800@gmail.com> Message-ID: On Tue, May 20, 2014 at 3:32 AM, Damien Miller wrote: > On Mon, 19 May 2014, ?ngel Gonz?lez wrote: > >> If you want something different, like chrooting them at /chrooted-users/foo, >> you >> can use -d parameter in the ForceCommand, ie. >> ForceCommand internal-sftp -d /%u > > If you're willing to live with a single chroot directory and file > permissions to keep users from each others' files then this is a great > solution. It only requires a single /chrooted-users/dev/log listener > too. > > -d The necessity for additional arcanery, of having non-user owned contents inside each working chrooted directory, and this kind of 'make one chroot, but rely on the users to correctly set permissions and block access to each other's content, even though they can see each other's directories by default" is exactly why the sftp chroot setup is not ideal. If you *must* do this sort of thing, I'd urge running it on a separate sshd, with a separate sshd_config, running on another port, just to keep it away from your SSH logins for other users and other uses. If you're not compelled for other reasons to use this, vsftpd with FTPS is a *lot* easier to set up. From lists at y42.org Wed May 21 00:33:27 2014 From: lists at y42.org (IMAP List Administration) Date: Tue, 20 May 2014 16:33:27 +0200 Subject: using OpenSSH/SFTP to replace an FTP server securely In-Reply-To: References: <53795ED4.4060400@y42.org> <537A560D.4090800@gmail.com> Message-ID: <537B67B7.9040203@y42.org> I thank everyone for their helpful suggestions. On 05/20/2014 09:32 AM, Damien Miller wrote: > On Mon, 19 May 2014, ?ngel Gonz?lez wrote: > >> If you want something different, like chrooting them at /chrooted-users/foo, >> you >> can use -d parameter in the ForceCommand, ie. >> ForceCommand internal-sftp -d /%u > If you're willing to live with a single chroot directory and file > permissions to keep users from each others' files then this is a great > solution. It only requires a single /chrooted-users/dev/log listener > too. Indeed, I am willing. I was just pulling my hair out because sshd wasn't chdir'ing into the home directory, and the "-d" option didn't work either. Eventually it occurred to me that v5.3 might not have that stuff, so I had a look in the source, and indeed, it's not there. I got v6.6p1 and compiled/installed it, and now sshd changes to the home directory after doing the chroot. Much better. Thanks again for the help. cheers, Rob From kop at meme.com Wed May 21 01:38:51 2014 From: kop at meme.com (Karl O. Pinc) Date: Tue, 20 May 2014 10:38:51 -0500 Subject: using OpenSSH/SFTP to replace an FTP server securely In-Reply-To: (from nkadel@gmail.com on Tue May 20 06:55:39 2014) Message-ID: <1400600331.4010.3@slate> On 05/20/2014 06:55:39 AM, Nico Kadel-Garcia wrote: > If you *must* do this sort of thing, I'd urge running it on a > separate > sshd, with a separate sshd_config, running on another port, just to > keep it away from your SSH logins for other users and other uses. If > you're not compelled for other reasons to use this, vsftpd with FTPS > is a *lot* easier to set up. Firewalling excepted. Properly firewalling ftp is, grody. And, if you're serious (default-deny), requires a ftp proxy and passive-only ftp. Passive only ftp being yet another thing that the end-user can then do wrong. And passive ftp interferes with secure (default-deny) firewalling on the client end unless the reverse ftp-proxy hoop is jumped through there. You wind up spending nearly as much time configuring the ftp firewalling as you do all the rest of the firewall. Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein Karl Free Software: "You don't pay back, you pay forward." -- Robert A. Heinlein From james.m.carter at nasa.gov Wed May 21 06:57:17 2014 From: james.m.carter at nasa.gov (Carter, James M. (MSFC-ES31)) Date: Tue, 20 May 2014 20:57:17 +0000 Subject: wrong key directory Message-ID: <5077833AAECE8A45871004A2ABC9F2C20E24C96E@NDMSMBX301.ndc.nasa.gov> Sirs: Trying to update OpenSSH to version openssh-6.6p1 using openssl-1.0.1g and zlib-1.2.3. Updating both openssl and openssh at same time. Have been running openssh on Solaris 8 machines for years. Has occurred on 3 mahines: After "compiling" openssh, try to start: /opt/openssh/sbin/sshd Get error: Could not load host key: /opt/openssh-5.0p1/etc/ssh_host_rsa_key Could not load host key: /opt/openssh-5.0p1/etc/ssh_host_dsa_key Disabling protocol version 2. Could not find host key sshd: no host keys available -- exiting openssh-5.0.p1 is what I am replacing. How/where is software getting reference to software that I cannot find on machine? I am deleting installed zlib, openssl & openssh before I start new installation. My install script looks like zlib: configure make test make install prefix=/opt/zlib-1.2.3 openssl: config --prefix=/opt/openssl-1.0.1g make make test make install openssh: configure --prefix=/opt/openssh-6.6p1 --without-zlib-version-check --with-ssl-dir=/opt/openssl-1.0.1g make make install set ssh{d}_config files as I want them setup privsep attempt to start "sshd" which fails I have a script file which I use for these actions; have used script for years only updating version of software Your assistance/aid will be greatly appreciated. Thank you. James James M Carter, PhD ES31 / Sensors, Imaging & Optics Branch Optics Team/Team Lead Bldg 4487 Rm B-117 Marshall Space Flight Center, AL 35812 O- 256-544-3469 C- 256-783-8362 F-256-544-2659 From djm at mindrot.org Wed May 21 08:34:53 2014 From: djm at mindrot.org (Damien Miller) Date: Wed, 21 May 2014 08:34:53 +1000 (EST) Subject: wrong key directory In-Reply-To: <5077833AAECE8A45871004A2ABC9F2C20E24C96E@NDMSMBX301.ndc.nasa.gov> References: <5077833AAECE8A45871004A2ABC9F2C20E24C96E@NDMSMBX301.ndc.nasa.gov> Message-ID: On Tue, 20 May 2014, Carter, James M. (MSFC-ES31) wrote: > Sirs: There are more than a few 'madams' on this list too. > Trying to update OpenSSH to version openssh-6.6p1 using openssl-1.0.1g > and zlib-1.2.3. Updating both openssl and openssh at same time. Have > been running openssh on Solaris 8 machines for years. > > Has occurred on 3 mahines: > After "compiling" openssh, try to start: /opt/openssh/sbin/sshd > Get error: > Could not load host key: /opt/openssh-5.0p1/etc/ssh_host_rsa_key > Could not load host key: /opt/openssh-5.0p1/etc/ssh_host_dsa_key > Disabling protocol version 2. Could not find host key > sshd: no host keys available -- exiting > > openssh-5.0.p1 is what I am replacing. How/where is software getting > reference to software that I cannot find on machine? I am deleting > installed zlib, openssl & openssh before I start new installation. Three possibilities: 1) You are running the old sshd version instead of the new version. This is easily checked by running 'sshd -?' and looking at the version. E.g. sshd: unknown option -- ? OpenSSH_6.7, OpenSSL 1.0.1g 7 Apr 2014 [...] 2) You are running the correct version of sshd but it has been configured to use the wrong config path. You can check this by running 'sshd -rddd' and looking for the lines like this: debug2: load_server_config: filename /etc/ssh/sshd_config 3) You are running the correct version of sshd and it is finding the correct configuration file, but it has bad key paths in it. This will also be apparent from the debug output. E.g. debug3: /etc/ssh/sshd_config:22 setting HostKey /etc/ssh/ssh_host_key Hope this helps. -d From vinschen at redhat.com Wed May 21 18:13:30 2014 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 21 May 2014 10:13:30 +0200 Subject: [patch/cygwin] SSH_PRIVSEP_USER as function (was Re: SSH_PRIVSEP_USER configurable at runtime?) In-Reply-To: <20140515112814.GA26671@calimero.vinschen.de> References: <20140331153243.GD2508@calimero.vinschen.de> <20140401085550.GA13510@calimero.vinschen.de> <20140401121529.GA16619@calimero.vinschen.de> <20140402113743.17700.qmail@stuge.se> <20140402124428.GT2508@calimero.vinschen.de> <20140515112814.GA26671@calimero.vinschen.de> Message-ID: <20140521081330.GB24532@calimero.vinschen.de> Ping? It would be nice if we could discuss this patch further, if it's not ok for inclusion. Thanks, Corinna On May 15 13:28, Corinna Vinschen wrote: > On Apr 2 14:44, Corinna Vinschen wrote: > > On Apr 2 13:37, Peter Stuge wrote: > > > Corinna Vinschen wrote: > > > > On non-domain machines the account > > > > name will be "sshd", not "${machine}+sshd". Except if the admin > > > > specifies that the domain is always prepended, which makes it > > > > "${machine}+sshd" again. And if the admin specifies the separator char > > > > to be not '+' but, for instance '#', the account name will be > > > > "${machine}#sshd". > > > > > > > > All that knowledge would have to go into sshd.c. > > > > > > FWIW I think this is the right solution. > > > > Hmm. Come to think of it, SSH_PRIVSEP_USER could be defined as a macro > > calling a function which returns the username. And configure.ac could > > define SSH_PRIVSEP_USER as, say, cygwin_privsep_user() by default, when > > built for Cygwin so the ugly details could be hidden in bsd-cygwin_util.c. > > > > The Cygwin changes are still in an early stage of testing, but I'll > > come back to this. > > Ok, after some mulling about, I prepared the below patch. What it does > is this: > > - The default replacement string for SSH_PRIVSEP_USER in configure.ac > is now CYGWIN_SSH_PRIVSEP_USER, if the target is Cygwin. This can > still be overridden with --with-privsep-user=FOO. > > - openbsd-compat/bsd-cygwin_util.h defines CYGWIN_SSH_PRIVSEP_USER > as a function call cygwin_ssh_privsep_user(). > > - openbsd-compat/bsd-cygwin_util.c implements cygwin_ssh_privsep_user(). > The function fills a static buffer with a username fetched by calling > an internal Cygwin function. The function fills the buffer with the > correct username, for instance "DOMAIN+sshd". If the function fails > (non-0 return value), the function falls back to the username "sshd". > > I just applied the required functionality to Cygwin's repository: > https://cygwin.com/viewvc/src/winsup/cygwin/external.cc?r1=1.137&r2=1.138 > > It will show up in the next official release 1.7.30. The below > patch makes sure that the code also compiles and falls back to the > username "sshd", if its getting built under an older version of > Cygwin. Additionally, even if built for 1.7.30 and later it will > still run under an older Cygwin version. > > I hope that patch is ok to support the discussed account mapping > functionality. I tried to implement it as non-intrusive as possible. > > > Thanks, > Corinna > > > Index: configure.ac > =================================================================== > RCS file: /cvs/openssh/configure.ac,v > retrieving revision 1.573 > diff -u -p -r1.573 configure.ac > --- configure.ac 15 May 2014 04:58:08 -0000 1.573 > +++ configure.ac 15 May 2014 11:26:21 -0000 > @@ -2872,7 +2872,14 @@ if test "x$PAM_MSG" = "xyes" ; then > ]) > fi > > -SSH_PRIVSEP_USER=sshd > +case "$host" in > +*-*-cygwin*) > + SSH_PRIVSEP_USER=CYGWIN_SSH_PRIVSEP_USER > + ;; > +*) > + SSH_PRIVSEP_USER=sshd > + ;; > +esac > AC_ARG_WITH([privsep-user], > [ --with-privsep-user=user Specify non-privileged user for privilege separation], > [ > @@ -2882,8 +2889,13 @@ AC_ARG_WITH([privsep-user], > fi > ] > ) > -AC_DEFINE_UNQUOTED([SSH_PRIVSEP_USER], ["$SSH_PRIVSEP_USER"], > - [non-privileged user for privilege separation]) > +if test "x$SSH_PRIVSEP_USER" = "xCYGWIN_SSH_PRIVSEP_USER" ; then > + AC_DEFINE_UNQUOTED([SSH_PRIVSEP_USER], [CYGWIN_SSH_PRIVSEP_USER], > + [Cygwin function to fetch non-privileged user for privilege separation]) > +else > + AC_DEFINE_UNQUOTED([SSH_PRIVSEP_USER], ["$SSH_PRIVSEP_USER"], > + [non-privileged user for privilege separation]) > +fi > AC_SUBST([SSH_PRIVSEP_USER]) > > if test "x$have_linux_no_new_privs" = "x1" ; then > Index: openbsd-compat/bsd-cygwin_util.c > =================================================================== > RCS file: /cvs/openssh/openbsd-compat/bsd-cygwin_util.c,v > retrieving revision 1.26 > diff -u -p -r1.26 bsd-cygwin_util.c > --- openbsd-compat/bsd-cygwin_util.c 1 Jun 2013 22:07:32 -0000 1.26 > +++ openbsd-compat/bsd-cygwin_util.c 15 May 2014 11:26:22 -0000 > @@ -57,6 +57,22 @@ check_ntsec(const char *filename) > return (pathconf(filename, _PC_POSIX_PERMISSIONS)); > } > > +const char * > +cygwin_ssh_privsep_user() > +{ > + static char cyg_privsep_user[DNLEN + UNLEN + 2]; > + > + if (!cyg_privsep_user[0]) > + { > +#ifdef CW_CYGNAME_FROM_WINNAME > + if (cygwin_internal (CW_CYGNAME_FROM_WINNAME, "sshd", cyg_privsep_user, > + sizeof cyg_privsep_user) != 0) > +#endif > + strcpy (cyg_privsep_user, "sshd"); > + } > + return cyg_privsep_user; > +} > + > #define NL(x) x, (sizeof (x) - 1) > #define WENV_SIZ (sizeof (wenv_arr) / sizeof (wenv_arr[0])) > > Index: openbsd-compat/bsd-cygwin_util.h > =================================================================== > RCS file: /cvs/openssh/openbsd-compat/bsd-cygwin_util.h,v > retrieving revision 1.17 > diff -u -p -r1.17 bsd-cygwin_util.h > --- openbsd-compat/bsd-cygwin_util.h 18 Jan 2014 10:04:00 -0000 1.17 > +++ openbsd-compat/bsd-cygwin_util.h 15 May 2014 11:26:22 -0000 > @@ -39,6 +39,8 @@ > /* Avoid including windows headers. */ > typedef void *HANDLE; > #define INVALID_HANDLE_VALUE ((HANDLE) -1) > +#define DNLEN 16 > +#define UNLEN 256 > > /* Cygwin functions for which declarations are only available when including > windows headers, so we have to define them here explicitely. */ > @@ -48,6 +50,8 @@ extern void cygwin_set_impersonation_tok > #include > #include > > +#define CYGWIN_SSH_PRIVSEP_USER (cygwin_ssh_privsep_user()) > +const char *cygwin_ssh_privsep_user(); > > int binary_open(const char *, int , ...); > int check_ntsec(const char *); > > > -- > Corinna Vinschen > Cygwin Maintainer > Red Hat > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From vinschen at redhat.com Wed May 21 18:13:43 2014 From: vinschen at redhat.com (Corinna Vinschen) Date: Wed, 21 May 2014 10:13:43 +0200 Subject: [patch/cygwin] contrib/cygwin/ssh-host-config In-Reply-To: <20140515085801.GO2436@calimero.vinschen.de> References: <20140515085801.GO2436@calimero.vinschen.de> Message-ID: <20140521081343.GC24532@calimero.vinschen.de> Ping? Thanks, Corinna On May 15 10:58, Corinna Vinschen wrote: > Hi, > > would you mind to apply the below patch? It fixes Cygwin's > ssh-host-config script in various ways: > > - Remove old code to remove the "sshd/22" entry from /etc/services. > This code fixes a problem which only existed in installations which > are more than 10 years old. > > - Handle the StrictMode setting interactively. > > - Fix regular expressions looking for white spaces. > > - Make the script independent of whether /etc/passwd exists or not. > This allows to run ssh-host-config under the upcoming Cygwin > release 1.7.30, which will introduce the passwd/group handling > via the existing Windows account databases (SAM/AD). > > > Thanks, > Corinna > > > Index: contrib/cygwin/ssh-host-config > =================================================================== > RCS file: /cvs/openssh/contrib/cygwin/ssh-host-config,v > retrieving revision 1.34 > diff -u -p -r1.34 ssh-host-config > --- contrib/cygwin/ssh-host-config 8 Nov 2013 13:19:23 -0000 1.34 > +++ contrib/cygwin/ssh-host-config 15 May 2014 08:46:20 -0000 > @@ -34,6 +34,7 @@ declare -a csih_required_commands=( > /usr/bin/mv coreutils > /usr/bin/rm coreutils > /usr/bin/cygpath cygwin > + /usr/bin/mkpasswd cygwin > /usr/bin/mount cygwin > /usr/bin/ps cygwin > /usr/bin/setfacl cygwin > @@ -59,8 +60,9 @@ PREFIX=/usr > SYSCONFDIR=/etc > LOCALSTATEDIR=/var > > +sshd_config_configured=no > port_number=22 > -privsep_configured=no > +strictmodes=yes > privsep_used=yes > cygwin_value="" > user_account= > @@ -89,28 +91,8 @@ update_services_file() { > # Depends on the above mount > _wservices=`cygpath -w "${_services}"` > > - # Remove sshd 22/port from services > - if [ `/usr/bin/grep -q 'sshd[ \t][ \t]*22' "${_services}"; echo $?` -eq 0 ] > - then > - /usr/bin/grep -v 'sshd[ \t][ \t]*22' "${_services}" > "${_serv_tmp}" > - if [ -f "${_serv_tmp}" ] > - then > - if /usr/bin/mv "${_serv_tmp}" "${_services}" > - then > - csih_inform "Removing sshd from ${_wservices}" > - else > - csih_warning "Removing sshd from ${_wservices} failed!" > - let ++ret > - fi > - /usr/bin/rm -f "${_serv_tmp}" > - else > - csih_warning "Removing sshd from ${_wservices} failed!" > - let ++ret > - fi > - fi > - > # Add ssh 22/tcp and ssh 22/udp to services > - if [ `/usr/bin/grep -q 'ssh[ \t][ \t]*22' "${_services}"; echo $?` -ne 0 ] > + if [ `/usr/bin/grep -q 'ssh[[:space:]][[:space:]]*22' "${_services}"; echo $?` -ne 0 ] > then > if /usr/bin/awk '{ if ( $2 ~ /^23\/tcp/ ) print "ssh 22/tcp'"${_spaces}"'SSH Remote Login Protocol\nssh 22/udp'"${_spaces}"'SSH Remote Login Protocol"; print $0; }' < "${_services}" > "${_serv_tmp}" > then > @@ -132,17 +114,45 @@ update_services_file() { > } # --- End of update_services_file --- # > > # ====================================================================== > +# Routine: sshd_strictmodes > +# MODIFIES: strictmodes > +# ====================================================================== > +sshd_strictmodes() { > + if [ "${sshd_config_configured}" != "yes" ] > + then > + echo > + csih_inform "StrictModes is set to 'yes' by default." > + csih_inform "This is the recommended setting, but it requires that the POSIX" > + csih_inform "permissions of the user's home directory, the user's .ssh" > + csih_inform "directory, and the user's ssh key files are tight so that" > + csih_inform "only the user has write permissions." > + csih_inform "On the other hand, StrictModes don't work well with default" > + csih_inform "Windows permissions of a home directory mounted with the" > + csih_inform "'noacl' option, and they don't work at all if the home" > + csih_inform "directory is on a FAT or FAT32 partition." > + if ! csih_request "Should StrictModes be used?" > + then > + strictmodes=no > + fi > + fi > + return 0 > +} > + > +# ====================================================================== > # Routine: sshd_privsep > -# MODIFIES: privsep_configured privsep_used > +# MODIFIES: privsep_used > # ====================================================================== > sshd_privsep() { > - local sshdconfig_tmp > local ret=0 > > - if [ "${privsep_configured}" != "yes" ] > + if [ "${sshd_config_configured}" != "yes" ] > then > - csih_inform "Privilege separation is set to yes by default since OpenSSH 3.3." > - csih_inform "However, this requires a non-privileged account called 'sshd'." > + echo > + csih_inform "Privilege separation is set to 'sandbox' by default since" > + csih_inform "OpenSSH 6.1. This is unsupported by Cygwin and has to be set" > + csih_inform "to 'yes' or 'no'." > + csih_inform "However, using privilege separation requires a non-privileged account" > + csih_inform "called 'sshd'." > csih_inform "For more info on privilege separation read /usr/share/doc/openssh/README.privsep." > if csih_request "Should privilege separation be used?" > then > @@ -159,36 +169,53 @@ sshd_privsep() { > privsep_used=no > fi > fi > + return $ret > +} # --- End of sshd_privsep --- # > + > +# ====================================================================== > +# Routine: sshd_config_tweak > +# ====================================================================== > +sshd_config_tweak() { > + local ret=0 > > - # Create default sshd_config from skeleton files in /etc/defaults/etc or > - # modify to add the missing privsep configuration option > - if /usr/bin/cmp "${SYSCONFDIR}/sshd_config" "${SYSCONFDIR}/defaults/${SYSCONFDIR}/sshd_config" >/dev/null 2>&1 > - then > - csih_inform "Updating ${SYSCONFDIR}/sshd_config file" > - sshdconfig_tmp=${SYSCONFDIR}/sshd_config.$$ > - /usr/bin/sed -e "s/^#UsePrivilegeSeparation yes/UsePrivilegeSeparation ${privsep_used}/ > - s/^#Port 22/Port ${port_number}/ > - s/^#StrictModes yes/StrictModes no/" \ > - < ${SYSCONFDIR}/sshd_config \ > - > "${sshdconfig_tmp}" > - if ! /usr/bin/mv "${sshdconfig_tmp}" ${SYSCONFDIR}/sshd_config > + # Modify sshd_config > + csih_inform "Updating ${SYSCONFDIR}/sshd_config file" > + if [ "${port_number}" -ne 22 ] > + then > + /usr/bin/sed -i -e "s/^#\?[[:space:]]*Port[[:space:]].*/Port ${port_number}/" \ > + ${SYSCONFDIR}/sshd_config > + if [ $? -ne 0 ] > then > - csih_warning "Setting privilege separation to 'yes' failed!" > - csih_warning "Check your ${SYSCONFDIR}/sshd_config file!" > - let ++ret > + csih_warning "Setting listening port to ${port_number} failed!" > + csih_warning "Check your ${SYSCONFDIR}/sshd_config file!" > + let ++ret > fi > - elif [ "${privsep_configured}" != "yes" ] > + fi > + if [ "${strictmodes}" = "no" ] > then > - echo >> ${SYSCONFDIR}/sshd_config > - if ! echo "UsePrivilegeSeparation ${privsep_used}" >> ${SYSCONFDIR}/sshd_config > + /usr/bin/sed -i -e "s/^#\?[[:space:]]*StrictModes[[:space:]].*/StrictModes no/" \ > + ${SYSCONFDIR}/sshd_config > + if [ $? -ne 0 ] > then > - csih_warning "Setting privilege separation to 'yes' failed!" > - csih_warning "Check your ${SYSCONFDIR}/sshd_config file!" > - let ++ret > + csih_warning "Setting StrictModes to 'no' failed!" > + csih_warning "Check your ${SYSCONFDIR}/sshd_config file!" > + let ++ret > + fi > + fi > + if [ "${sshd_config_configured}" != "yes" ] > + then > + /usr/bin/sed -i -e " > + s/^#\?UsePrivilegeSeparation .*/UsePrivilegeSeparation ${privsep_used}/" \ > + ${SYSCONFDIR}/sshd_config > + if [ $? -ne 0 ] > + then > + csih_warning "Setting privilege separation failed!" > + csih_warning "Check your ${SYSCONFDIR}/sshd_config file!" > + let ++ret > fi > fi > return $ret > -} # --- End of sshd_privsep --- # > +} # --- End of sshd_config_tweak --- # > > # ====================================================================== > # Routine: update_inetd_conf > @@ -207,11 +234,11 @@ update_inetd_conf() { > # we have inetutils-1.5 inetd.d support > if [ -f "${_inetcnf}" ] > then > - /usr/bin/grep -q '^[ \t]*ssh' "${_inetcnf}" && _with_comment=0 > + /usr/bin/grep -q '^[[:space:]]*ssh' "${_inetcnf}" && _with_comment=0 > > # check for sshd OR ssh in top-level inetd.conf file, and remove > # will be replaced by a file in inetd.d/ > - if [ `/usr/bin/grep -q '^[# \t]*ssh' "${_inetcnf}"; echo $?` -eq 0 ] > + if [ $(/usr/bin/grep -q '^[# \t]*ssh' "${_inetcnf}"; echo $?) -eq 0 ] > then > /usr/bin/grep -v '^[# \t]*ssh' "${_inetcnf}" >> "${_inetcnf_tmp}" > if [ -f "${_inetcnf_tmp}" ] > @@ -236,9 +263,9 @@ update_inetd_conf() { > then > if [ "${_with_comment}" -eq 0 ] > then > - /usr/bin/sed -e 's/@COMMENT@[ \t]*//' < "${_sshd_inetd_conf}" > "${_sshd_inetd_conf_tmp}" > + /usr/bin/sed -e 's/@COMMENT@[[:space:]]*//' < "${_sshd_inetd_conf}" > "${_sshd_inetd_conf_tmp}" > else > - /usr/bin/sed -e 's/@COMMENT@[ \t]*/# /' < "${_sshd_inetd_conf}" > "${_sshd_inetd_conf_tmp}" > + /usr/bin/sed -e 's/@COMMENT@[[:space:]]*/# /' < "${_sshd_inetd_conf}" > "${_sshd_inetd_conf_tmp}" > fi > if /usr/bin/mv "${_sshd_inetd_conf_tmp}" "${_sshd_inetd_conf}" > then > @@ -251,13 +278,13 @@ update_inetd_conf() { > > elif [ -f "${_inetcnf}" ] > then > - /usr/bin/grep -q '^[ \t]*sshd' "${_inetcnf}" && _with_comment=0 > + /usr/bin/grep -q '^[[:space:]]*sshd' "${_inetcnf}" && _with_comment=0 > > # check for sshd in top-level inetd.conf file, and remove > # will be replaced by a file in inetd.d/ > - if [ `/usr/bin/grep -q '^[# \t]*sshd' "${_inetcnf}"; echo $?` -eq 0 ] > + if [ `/usr/bin/grep -q '^#\?[[:space:]]*sshd' "${_inetcnf}"; echo $?` -eq 0 ] > then > - /usr/bin/grep -v '^[# \t]*sshd' "${_inetcnf}" >> "${_inetcnf_tmp}" > + /usr/bin/grep -v '^#\?[[:space:]]*sshd' "${_inetcnf}" >> "${_inetcnf_tmp}" > if [ -f "${_inetcnf_tmp}" ] > then > if /usr/bin/mv "${_inetcnf_tmp}" "${_inetcnf}" > @@ -305,17 +332,26 @@ check_service_files_ownership() { > > if [ -z "${run_service_as}" ] > then > - accnt_name=$(/usr/bin/cygrunsrv -VQ sshd | /usr/bin/sed -ne 's/^Account *: *//gp') > + accnt_name=$(/usr/bin/cygrunsrv -VQ sshd | > + /usr/bin/sed -ne 's/^Account *: *//gp') > if [ "${accnt_name}" = "LocalSystem" ] > then > # Convert "LocalSystem" to "SYSTEM" as is the correct account name > - accnt_name="SYSTEM:" > - elif [[ "${accnt_name}" =~ ^\.\\ ]] > - then > - # Convert "." domain to local machine name > - accnt_name="U-${COMPUTERNAME}${accnt_name#.}," > + run_service_as="SYSTEM" > + else > + dom="${accnt_name%%\\*}" > + accnt_name="${accnt_name#*\\}" > + if [ "${dom}" = '.' ] > + then > + # Check local account > + run_service_as=$(/usr/bin/mkpasswd -l -u "${accnt_name}" | > + /usr/bin/awk -F: '{print $1;}') > + else > + # Check domain > + run_service_as=$(/usr/bin/mkpasswd -d "${dom}" -u "${accnt_name}" | > + /usr/bin/awk -F: '{print $1;}') > + fi > fi > - run_service_as=$(/usr/bin/grep -Fi "${accnt_name}" /etc/passwd | /usr/bin/awk -F: '{print $1;}') > if [ -z "${run_service_as}" ] > then > csih_warning "Couldn't determine name of user running sshd service from /etc/passwd!" > @@ -672,6 +708,7 @@ then > fi > > # generate missing host keys > +csih_inform "Generating missing SSH host keys" > /usr/bin/ssh-keygen -A || let warning_cnt+=$? > > # handle ssh_config > @@ -690,10 +727,11 @@ fi > csih_install_config "${SYSCONFDIR}/sshd_config" "${SYSCONFDIR}/defaults" || let ++warning_cnt > if ! /usr/bin/cmp "${SYSCONFDIR}/sshd_config" "${SYSCONFDIR}/defaults/${SYSCONFDIR}/sshd_config" >/dev/null 2>&1 > then > - /usr/bin/grep -q UsePrivilegeSeparation ${SYSCONFDIR}/sshd_config && privsep_configured=yes > + sshd_config_configured=yes > fi > +sshd_strictmodes || let warning_cnt+=$? > sshd_privsep || let warning_cnt+=$? > - > +sshd_config_tweak || let warning_cnt+=$? > update_services_file || let warning_cnt+=$? > update_inetd_conf || let warning_cnt+=$? > install_service || let warning_cnt+=$? > > -- > Corinna Vinschen > Cygwin Maintainer > Red Hat > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev -- Corinna Vinschen Cygwin Maintainer Red Hat -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 819 bytes Desc: not available URL: From keisial at gmail.com Thu May 22 09:40:24 2014 From: keisial at gmail.com (=?ISO-8859-1?Q?=C1ngel_Gonz=E1lez?=) Date: Thu, 22 May 2014 01:40:24 +0200 Subject: using OpenSSH/SFTP to replace an FTP server securely In-Reply-To: References: <53795ED4.4060400@y42.org> <537A560D.4090800@gmail.com> Message-ID: <537D3968.1070907@gmail.com> On 20/05/14 Damien Miller wrote: > On Mon, 19 May 2014, ?ngel Gonz?lez wrote: > >> If you want something different, like chrooting them at /chrooted-users/foo, >> you can use -d parameter in the ForceCommand, ie. >> ForceCommand internal-sftp -d /%u > If you're willing to live with a single chroot directory and file > permissions to keep users from each others' files then this is a great > solution. It only requires a single /chrooted-users/dev/log listener > too. > > -d He had stated it was acceptable ;) Nico Kadel wrote: > The necessity for additional arcanery, of having non-user owned > contents inside each working chrooted directory, and this kind of > 'make one chroot, but rely on the users to correctly set permissions > and block access to each other's content, even though they can see > each other's directories by default" is exactly why the sftp chroot > setup is not ideal. Remember they don'r need +r on /home but just +x. They can still confirm if a user exists, but puts the bar slightly higher. It isn't so extravagant to require properly set permissions on your folder (I think that by using posix acls you could forbid them to change the default) But yes, it's not ideal, which leads to: Damien Miller wrote: > The syslog problem doesn't have a good solution right now. Maybe someone > could write a patch to implement logging via the monitor, like what happens > for the pre-auth process. +1 Or it may be easier to leave open an fd to /dev/log. From rhack at redhat.com Thu May 22 23:36:41 2014 From: rhack at redhat.com (Robin Hack) Date: Thu, 22 May 2014 15:36:41 +0200 Subject: [PATCH] openssh - loginrec.c - Non-atomic file operations. Message-ID: <20140522133641.GB2669@bigoook.brq.redhat.com> Hi all. I rewrited lastlog_openseek function. Now is little more atomic when file operations on lastlog file happens. For more details why separate stat and open isn't so safe please take a look at: http://www.akkadia.org/drepper/defprogramming.pdf Have nice day Robin Hack -------------- next part -------------- diff --git a/loginrec.c b/loginrec.c index 4219b9a..281d650 100644 --- a/loginrec.c +++ b/loginrec.c @@ -163,6 +163,7 @@ #include #include #include +#include #include "xmalloc.h" #include "key.h" @@ -1476,41 +1477,65 @@ lastlog_openseek(struct logininfo *li, int *fd, int filemode) off_t offset; char lastlog_file[1024]; struct stat st; - - if (stat(LASTLOG_FILE, &st) != 0) { - logit("%s: Couldn't stat %s: %s", __func__, - LASTLOG_FILE, strerror(errno)); - return (0); - } - if (S_ISDIR(st.st_mode)) { - snprintf(lastlog_file, sizeof(lastlog_file), "%s/%s", - LASTLOG_FILE, li->username); - } else if (S_ISREG(st.st_mode)) { + DIR *lastlog_dir; + int dir_fd = -1; + + /* Try to open directory */ + lastlog_dir = opendir(lastlog_file); + if (lastlog_dir != NULL) { + /* So. We are directory. */ + dir_fd = dirfd(lastlog_dir); + snprintf(lastlog_file, sizeof(lastlog_file), "/dev/fd/%d/%s", + dir_fd, li->username); + } else if ((errno == ENOTDIR) || (errno == ENOENT)) { + /* Not directory. Try to open as file. */ strlcpy(lastlog_file, LASTLOG_FILE, sizeof(lastlog_file)); + } else if (errno == EACCES) { + logit("%s: %.100s permission denied!", __func__, + LASTLOG_FILE); + return (0); } else { - logit("%s: %.100s is not a file or directory!", __func__, - LASTLOG_FILE); + /* Few errnos left. Most of then should happen + because kernel limits... */ + logit("%s: %.100s is not accessible!", __func__, + LASTLOG_FILE); return (0); } + /* Here is place for possible race condition. */ *fd = open(lastlog_file, filemode, 0600); + if (dir_fd != -1) { + closedir(lastlog_dir); + } + if (*fd < 0) { debug("%s: Couldn't open %s: %s", __func__, - lastlog_file, strerror(errno)); + lastlog_file, strerror(errno)); return (0); } - if (S_ISREG(st.st_mode)) { - /* find this uid's offset in the lastlog file */ - offset = (off_t) ((u_long)li->uid * sizeof(struct lastlog)); + if (fstat(*fd, &st) != 0) { + close(*fd); + logit("%s: Couldn't stat %s: %s", __func__, + LASTLOG_FILE, strerror(errno)); + return (0); + } - if (lseek(*fd, offset, SEEK_SET) != offset) { - logit("%s: %s->lseek(): %s", __func__, - lastlog_file, strerror(errno)); - close(*fd); - return (0); - } + if (!S_ISREG(st.st_mode)) { + close(*fd); + logit("%s: %.100s is not a regular file!", __func__, + LASTLOG_FILE); + return (0); } + /* find this uid's offset in the lastlog file */ + offset = (off_t) ((u_long)li->uid * sizeof(struct lastlog)); + + if (lseek(*fd, offset, SEEK_SET) != offset) { + logit("%s: %s->lseek(): %s", __func__, + lastlog_file, strerror(errno)); + close(*fd); + return (0); + } return (1); } From opensshdev at r.paypc.com Sat May 24 10:41:19 2014 From: opensshdev at r.paypc.com (Morham) Date: Fri, 23 May 2014 17:41:19 -0700 Subject: Pulling stalls before 52MB (works via netcat) In-Reply-To: References: <20140504041401.GA8580@zoho.com> Message-ID: <537FEAAF.5040506@r.paypc.com> On 5/4/2014 9:08 AM, Grant wrote: > That didn't do it but switching to MTU 576 seems to have fixed it. I > suspect the root of the problem is that I'm using an AT&T modem/router > with the server. I've had trouble using a proxy server there before > and I discovered that the attached modem/router doesn't send ICMP > responses. The solution proposed by AT&T was to put the modem/router > into bridged mode but it's remote so I haven't been able to do that. You probably don't need to go that low. If the link is PPPoE, you lose a bit of the frame to PPP encapsulation. MTU=1460 should be a safe and conservative setting that won't unduly contribute overheads. (Theoretically, MTU=1492 should be all that's required.) If you used a PPPoE client/gateway that clamped MSS through the PPPoE default route automatically, you could leave the rest of your LAN's MTU settings at their default, while payloads will be automatically constrained when routed through the gateway to a safe value without requiring Path MTU Discovery (PMTUD). Look for ICMP firewalling settings on the AT&T Modem/Router. If you're blocking all ICMP out of the border, you've broken PMTUD. Of course, on the client node side, bad firewalling can break it there as well. Most (all?) operating systems support it by default these days. > Could this MTU discovery also point to the modem/router and could > putting it into bridged mode solve the problem? What can I do in the > meantime? Broken path MTU discovery is usually a firewalling problem. If your server is overly restrictive on ICMP messages, this is usually the cause. Bridging mode may simply allow you to duck the problem by placing firewalling decisions elsewhere in your network. > Is it strange that netcat works with MTU 1500 and openssh doesn't? Depending on the TCP_CORK/TCP_NODELAY related settings used by both, that could account for some differences in operation. Without a packet log looking at the actual payloads + sizes, you might just be assuming that netcat's generating 1500 byte payloads over the wire. =M= From djm at mindrot.org Tue May 27 14:35:15 2014 From: djm at mindrot.org (Damien Miller) Date: Tue, 27 May 2014 14:35:15 +1000 (EST) Subject: [patch/cygwin] contrib/cygwin/ssh-host-config In-Reply-To: <20140521081343.GC24532@calimero.vinschen.de> References: <20140515085801.GO2436@calimero.vinschen.de> <20140521081343.GC24532@calimero.vinschen.de> Message-ID: On Wed, 21 May 2014, Corinna Vinschen wrote: > Ping? Sorry, I haven't had much time to work on OpenSSH for the last few weeks. Both your patches are committed now. -d From daggs at gmx.com Thu May 29 04:16:51 2014 From: daggs at gmx.com (Dagg Stompler) Date: Wed, 28 May 2014 20:16:51 +0200 Subject: sftp session disconnects right after passwd enter Message-ID: Greetings All, I have a ssh server which allows sftp connections from the Internet while ssh connections from within the local net, here is the config: Code: Port 11111 Port 11113 Protocol 2 LogLevel DEBUG PasswordAuthentication no UsePAM yes PrintMotd no PrintLastLog no Subsystem sftp /usr/lib64/misc/sftp-server Match LocalPort 11113 Address *,!192.168.0.0/24 ChrootDirectory /home/%u AllowTCPForwarding no X11Forwarding no AllowUsers sftp_user ForceCommand /usr/lib/openssh/sftp-server AuthenticationMethods publickey,password publickey,keyboard-interactive RSAAuthentication yes PubkeyAuthentication yes AcceptEnv LANG LC_* now when I try to connect I from outside the net to test it I see this in the client: Code: dagg at NCC-5001-D ~/.ssh/sftp_keys $ sftp -oPort=11113 -oIdentityFile=id_rsa [1]sftp_user at 111.111.111.111 Authenticated with partial success. Password: Connection closed I'm sure the passwd is correct because su - sftp_user with that same passwd works and if I enter a worng passwd I'm prompted with another "Password: " line. the server logs are: Code: May 21 22:56:30 NCC-5001-D sshd[30467]: debug1: Forked child 30708. May 21 22:56:30 NCC-5001-D sshd[30708]: Set /proc/self/oom_score_adj to 0 May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: rexec start in 7 out 7 newsock 7 pipe 9 sock 10 May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: inetd sockets after dupping: 3, 3 May 21 22:56:30 NCC-5001-D sshd[30708]: Connection from 111.111.111.111 port 41017 on 192.168.0.1 port 11113 May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: HPN Disabled: 0, HPN Buffer Size: 87380 May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: Client protocol version 2.0; client software version OpenSSH_6.6p1-hpn14v4 May 21 22:56:30 NCC-5001-D sshd[30708]: SSH: Server;Ltype: Version;Remote: 111.111.111.111-41017;Protocol: 2.0;Client: OpenSSH_6.6p1-hpn14v4 May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: match: OpenSSH_6.6p1-hpn14v4 pat OpenSSH* compat 0x04000000 May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: Enabling compatibility mode for protocol 2.0 May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: Local version string SSH-2.0-OpenSSH_6.6p1-hpn14v4 May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: permanently_set_uid: 22/22 [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: list_hostkey_types: ssh-rsa,ssh-dss,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: SSH2_MSG_KEXINIT sent [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: SSH2_MSG_KEXINIT received [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: AUTH STATE IS 0 [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: REQUESTED ENC.NAME is 'aes128-ctr' [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: kex: client->server aes128-ctr [2]hmac-md5-etm at openssh.com none [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: SSH: Server;Ltype: Kex;Remote: 111.111.111.111-41017;Enc: aes128-ctr;MAC: [3]hmac-md5-etm at openssh.com;Comp: none [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: REQUESTED ENC.NAME is 'aes128-ctr' [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: kex: server->client aes128-ctr [4]hmac-md5-etm at openssh.com none [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: expecting SSH2_MSG_KEX_ECDH_INIT [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: SSH2_MSG_NEWKEYS sent [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: expecting SSH2_MSG_NEWKEYS [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: SSH2_MSG_NEWKEYS received [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: KEX done [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: userauth-request for user sftp_user service ssh-connection method none [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: SSH: Server;Ltype: Authname;Remote: 111.111.111.111-41017;Name: sftp_user [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: attempt 0 failures 0 [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: Config token is port May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: Config token is port May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: Config token is protocol May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: Config token is loglevel May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: Config token is passwordauthentication May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: Config token is usepam May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: Config token is printmotd May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: Config token is printlastlog May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: Config token is useprivilegeseparation May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: Config token is subsystem May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: Config token is match May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: connection from 192.168.0.1 matched 'LocalPort 11113' at line 176 May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: connection from 111.111.111.111 matched 'Address *,!192.168.0.0/24' at line 176 May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: Config token is chrootdirectory May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: Config token is allowtcpforwarding May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: Config token is x11forwarding May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: Config token is allowusers May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: Config token is forcecommand May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: Config token is authenticationmethods May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: Config token is rsaauthentication May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: Config token is pubkeyauthentication May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: Config token is acceptenv May 21 22:56:30 NCC-5001-D sshd[30708]: error: Disabled method "password" in AuthenticationMethods list "publickey,password" May 21 22:56:30 NCC-5001-D sshd[30708]: Authentication methods list "publickey,password" contains disabled method, skipping May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: authentication methods list 0: publickey,keyboard-interactive May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: PAM: initializing for "sftp_user" May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: PAM: setting PAM_RHOST to "red.unlimited.net" May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: PAM: setting PAM_TTY to "ssh" May 21 22:56:30 NCC-5001-D sshd[30708]: error: Disabled method "password" in AuthenticationMethods list "publickey,password" [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: Authentication methods list "publickey,password" contains disabled method, skipping [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: authentication methods list 0: publickey,keyboard-interactive [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: userauth-request for user sftp_user service ssh-connection method publickey [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: attempt 1 failures 0 [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: test whether pkalg/pkblob are acceptable [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: temporarily_use_uid: 1004/100 (e=0/0) May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: trying public key file /home/sftp_user/.ssh/authorized_keys May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: fd 4 clearing O_NONBLOCK May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: matching key found: file /home/sftp_user/.ssh/authorized_keys, line 1 RSA xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: restore_uid: 0/0 May 21 22:56:30 NCC-5001-D sshd[30708]: Postponed publickey for sftp_user from 111.111.111.111 port 41017 ssh2 [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: userauth-request for user sftp_user service ssh-connection method publickey [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: attempt 2 failures 0 [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: temporarily_use_uid: 1004/100 (e=0/0) May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: trying public key file /home/sftp_user/.ssh/authorized_keys May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: fd 4 clearing O_NONBLOCK May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: matching key found: file /home/sftp_user/.ssh/authorized_keys, line 1 RSA xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: restore_uid: 0/0 May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: ssh_rsa_verify: signature correct May 21 22:56:30 NCC-5001-D sshd[30708]: Partial publickey for sftp_user from 111.111.111.111 port 41017 ssh2: RSA xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: userauth-request for user sftp_user service ssh-connection method keyboard-interactive [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: attempt 3 failures 1 [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: keyboard-interactive devs [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: auth2_challenge: user=sftp_user devs= [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: kbdint_alloc: devices 'pam' [preauth] May 21 22:56:30 NCC-5001-D sshd[30708]: debug1: auth2_challenge_start: trying authentication method 'pam' [preauth] May 21 22:56:31 NCC-5001-D sshd[30708]: Postponed keyboard-interactive for sftp_user from 111.111.111.111 port 41017 ssh2: RSA xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx [preauth] May 21 22:56:34 NCC-5001-D sshd[30713]: debug1: do_pam_account: called May 21 22:56:34 NCC-5001-D sshd[30708]: debug1: PAM: num PAM env strings 0 May 21 22:56:34 NCC-5001-D sshd[30708]: Postponed keyboard-interactive/pam for sftp_user from 111.111.111.111 port 41017 ssh2 [preauth] May 21 22:56:34 NCC-5001-D sshd[30708]: debug1: do_pam_account: called May 21 22:56:34 NCC-5001-D sshd[30708]: Accepted keyboard-interactive/pam for sftp_user from 111.111.111.111 port 41017 ssh2 May 21 22:56:34 NCC-5001-D sshd[30708]: debug1: monitor_child_preauth: sftp_user has been authenticated by privileged process May 21 22:56:34 NCC-5001-D sshd[30708]: debug1: monitor_read_log: child log fd closed May 21 22:56:34 NCC-5001-D sshd[30708]: debug1: PAM: establishing credentials May 21 22:56:34 NCC-5001-D sshd[30708]: pam_unix(sshd:session): session opened for user sftp_user by (uid=0) May 21 22:56:34 NCC-5001-D sshd[30708]: User child is on pid 30721 May 21 22:56:34 NCC-5001-D sshd[30721]: debug1: PAM: establishing credentials May 21 22:56:34 NCC-5001-D sshd[30708]: debug1: do_cleanup May 21 22:56:34 NCC-5001-D sshd[30708]: debug1: PAM: cleanup May 21 22:56:34 NCC-5001-D sshd[30708]: debug1: PAM: closing session May 21 22:56:34 NCC-5001-D sshd[30708]: pam_unix(sshd:session): session closed for user sftp_user May 21 22:56:34 NCC-5001-D sshd[30708]: debug1: PAM: deleting credentials why I'm not able to get a ftp cli? Thanks. References 1. mailto:sftp_user at 111.111.111.111 2. mailto:hmac-md5-etm at openssh.com 3. mailto:hmac-md5-etm at openssh.com 4. mailto:hmac-md5-etm at openssh.com From dtucker at zip.com.au Thu May 29 06:53:19 2014 From: dtucker at zip.com.au (Darren Tucker) Date: Wed, 28 May 2014 16:53:19 -0400 Subject: sftp session disconnects right after passwd enter In-Reply-To: References: Message-ID: On Wed, May 28, 2014 at 2:16 PM, Dagg Stompler wrote: [...] > May 21 22:56:30 NCC-5001-D sshd[30708]: SSH: Server;Ltype: > Version;Remote: 111.111.111.111-41017;Protocol: 2.0;Client: > OpenSSH_6.6p1-hpn14v4 > This indicates that you are using a modified version of OpenSSH. Can you reproduce the problem with the stock version compiled from the code on openssh.com? May 21 22:56:34 NCC-5001-D sshd[30721]: debug1: PAM: establishing > credentials > May 21 22:56:34 NCC-5001-D sshd[30708]: debug1: do_cleanup > I would guess there's something in the PAM session stack that causes pam_setcred to fail. -- 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 daggs at gmx.com Thu May 29 15:46:16 2014 From: daggs at gmx.com (daggs) Date: Thu, 29 May 2014 07:46:16 +0200 Subject: sftp session disconnects right after passwd enter In-Reply-To: References: , Message-ID: Greetings Darren, > Sent: Wednesday, May 28, 2014 at 11:53 PM > From: "Darren Tucker" > To: "Dagg Stompler" > Cc: "OpenSSH Devel List" > Subject: Re: sftp session disconnects right after passwd enter > > On Wed, May 28, 2014 at 2:16 PM, Dagg Stompler wrote: > [...] > > > May 21 22:56:30 NCC-5001-D sshd[30708]: SSH: Server;Ltype: > > Version;Remote: 111.111.111.111-41017;Protocol: 2.0;Client: > > OpenSSH_6.6p1-hpn14v4 > > > > This indicates that you are using a modified version of OpenSSH. Can you > reproduce the problem with the stock version compiled from the code on > openssh.com? I'm running gentoo, no sure what patches get applied, will check. > > May 21 22:56:34 NCC-5001-D sshd[30721]: debug1: PAM: establishing > > credentials > > May 21 22:56:34 NCC-5001-D sshd[30708]: debug1: do_cleanup > > > > I would guess there's something in the PAM session stack that causes > pam_setcred to fail. anything specific I need to look at within pam_setcred? > > -- > 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. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From daggs at gmx.com Fri May 30 17:13:45 2014 From: daggs at gmx.com (daggs) Date: Fri, 30 May 2014 09:13:45 +0200 Subject: sftp session disconnects right after passwd enter In-Reply-To: References: , , Message-ID: Greetings Darren, > Sent: Thursday, May 29, 2014 at 8:46 AM > From: daggs > To: "Darren Tucker" > Cc: "OpenSSH Devel List" > Subject: Re: sftp session disconnects right after passwd enter > > Greetings Darren, > > > Sent: Wednesday, May 28, 2014 at 11:53 PM > > From: "Darren Tucker" > > To: "Dagg Stompler" > > Cc: "OpenSSH Devel List" > > Subject: Re: sftp session disconnects right after passwd enter > > > > On Wed, May 28, 2014 at 2:16 PM, Dagg Stompler wrote: > > [...] > > > > > May 21 22:56:30 NCC-5001-D sshd[30708]: SSH: Server;Ltype: > > > Version;Remote: 111.111.111.111-41017;Protocol: 2.0;Client: > > > OpenSSH_6.6p1-hpn14v4 > > > > > > > This indicates that you are using a modified version of OpenSSH. Can you > > reproduce the problem with the stock version compiled from the code on > > openssh.com? > I'm running gentoo, no sure what patches get applied, will check. afai can see, this is are the patches which gets applied but only the latter is used as I don't compile openssh with X509 flag set. http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-misc/openssh/files/openssh-6.6_p1-x509-hpn14v4-glue-p2.patch?view=markup http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-misc/openssh/files/openssh-6.6_p1-x509-glue.patch?view=markup http://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/net-misc/openssh/files/openssh-6.6_p1-openssl-ignore-status.patch?view=markup any ideas? > > > > > May 21 22:56:34 NCC-5001-D sshd[30721]: debug1: PAM: establishing > > > credentials > > > May 21 22:56:34 NCC-5001-D sshd[30708]: debug1: do_cleanup > > > > > > > I would guess there's something in the PAM session stack that causes > > pam_setcred to fail. > anything specific I need to look at within pam_setcred? > > > > > -- > > 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. > > _______________________________________________ > > 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 dtucker at zip.com.au Fri May 30 23:33:05 2014 From: dtucker at zip.com.au (Darren Tucker) Date: Fri, 30 May 2014 09:33:05 -0400 Subject: sftp session disconnects right after passwd enter In-Reply-To: References: Message-ID: On Fri, May 30, 2014 at 3:13 AM, daggs wrote: [...] > > > This indicates that you are using a modified version of OpenSSH. Can > you > > > reproduce the problem with the stock version compiled from the code on > > > openssh.com? > > I'm running gentoo, no sure what patches get applied, will check. > afai can see, this is are the patches which gets applied but only the > latter is used as I don't compile openssh with X509 flag set. > [snip links to patches] > any ideas? Yes, my idea was to actually try an unmodified version rather than just guess. Other than that, look at what PAM modules are in the sshd stack and check your system logs for errors from those at the time you try it. -- 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 mouring at offwriting.org Sat May 31 00:27:05 2014 From: mouring at offwriting.org (Ben Lindstrom) Date: Fri, 30 May 2014 09:27:05 -0500 Subject: sftp session disconnects right after passwd enter In-Reply-To: References: Message-ID: <99132C7D-AB3E-45F3-B8C0-38E1F35305AB@offwriting.org> On May 30, 2014, at 8:33 AM, Darren Tucker wrote: > On Fri, May 30, 2014 at 3:13 AM, daggs wrote: > [...] > >>>> This indicates that you are using a modified version of OpenSSH. Can >> you >>>> reproduce the problem with the stock version compiled from the code on >>>> openssh.com? >>> I'm running gentoo, no sure what patches get applied, will check. >> afai can see, this is are the patches which gets applied but only the >> latter is used as I don't compile openssh with X509 flag set. >> > [snip links to patches] > >> any ideas? > > > Yes, my idea was to actually try an unmodified version rather than just > guess. > > Other than that, look at what PAM modules are in the sshd stack and check > your system logs for errors from those at the time you try it. Since we were talking about this slightly earlier.. it may not be a bad idea to check who owns the directories on /home/%u and such. As I suspect it isn't root, and this will also cause you issues. - Ben From yves at zioup.com Sat May 31 00:40:15 2014 From: yves at zioup.com (Yves Dorfsman) Date: Fri, 30 May 2014 08:40:15 -0600 Subject: AuthorizedKeysCommand run as the user Message-ID: <5388984F.5010903@zioup.com> Is there any way to make the AuthorizedKeysCommand as the user which is trying to log in? Thanks. -- Yves. From sduckwo at clemson.edu Sat May 31 01:00:48 2014 From: sduckwo at clemson.edu (Scott Duckworth) Date: Fri, 30 May 2014 11:00:48 -0400 Subject: AuthorizedKeysCommand run as the user In-Reply-To: <5388984F.5010903@zioup.com> References: <5388984F.5010903@zioup.com> Message-ID: Point AuthorizedKeysCommand to a script that runs your desired command through sudo. The connecting user's name is available in the first argument. Just make sure that sudo is configured to allow AuthorizedKeysCommandUser to run the specified command as any user without a password. #!/bin/sh sudo -u "$1" /path/to/command On Fri, May 30, 2014 at 10:40 AM, Yves Dorfsman wrote: > > Is there any way to make the AuthorizedKeysCommand as the user which is > trying to log in? > > Thanks. > > -- > Yves. > _______________________________________________ > openssh-unix-dev mailing list > openssh-unix-dev at mindrot.org > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev > From djm at mindrot.org Sat May 31 08:45:53 2014 From: djm at mindrot.org (Damien Miller) Date: Sat, 31 May 2014 08:45:53 +1000 (EST) Subject: AuthorizedKeysCommand run as the user In-Reply-To: <5388984F.5010903@zioup.com> References: <5388984F.5010903@zioup.com> Message-ID: On Fri, 30 May 2014, Yves Dorfsman wrote: > > Is there any way to make the AuthorizedKeysCommand as the user which is trying > to log in? AuthorizedKeysCommandUser %u